Pixel-Accurate N64 Software Video Plugin

[mudlord_]

yeh, BGRA pixel formats were added to OGL 1.2

[HatCat]

If they're going to add new byte orders to the spec they could at least use their time adding non-redundant ones.

Take RABG or GABR, for example. They're not already reachable by GL_UNPACK_SWAP_BYTES.

[HatCat]

Looks like reading the FB with GL_RGB instead of GL_RGBA bumps Absolute Crap 2 from 215 VI/s to 265 VI/s.

I know the specs say that GL_RGB is supposed to be faster than GL_RGBA; I just wasn't sure whether to believe that since copying 24 bits at a time seems weirder than 32.

[HatCat]

I have to convert it back from GL_RGB to GL_RGBA to fix pixel offset issues with Resident Evil 2.





The GL_UNPACK_ALIGNMENT state of the render context optimizes the frame buffer read and scale through the GPU bus more effectively when working in 32-bit RGBA mode. I don't like 24-bit RGB mode, so while it may be faster for ROMs with no RDP emulation (demos like sp crap), it hinders glReadPixels from taking 32-bit screenshots for people interested in alpha transparency and causes pixel offset bugs.

Besides, once I implement proper OpenGL scaling to fix what DirectDraw cannot supplement for us in accurate emulation of VI DAC, whether I use GL_RGB or GL_RGBA will be rendered impertinent to the matter as textured quads will be GPU-accelerated and not so graceless as to go through the bus like glDrawPixels does. I'm merely stabilizing the latter as an alternative, non-default option of filtering, perhaps more interesting on some cards than others.

[HatCat]

Seems my hunch was correct.

A few simple but thoughtful accommodations for using GL_RGBA and RE2 is fixed:


The pixels to the full left are not a frame reset bug. They should show up on a real N64.

                if (plim < addr)
                    continue;
                pix = *(GLushort *)(DRAM + addr);
                rgba[0] = (pix & 0xF800) >> (11 - 3);
                rgba[1] = (pix & 0x07C0) >> (6 - 3);
                rgba[2] = (pix & 0x003E) << 2 >> (1 - 1);
             /* rgba[3] = (pix & 0x0001) ? ~0x00 : 0x00; */
                scanline[i] = *(GLuint *)(rgba);

no_frame_buffer:
    if (dst.left < dst.right && dst.top < dst.bottom)
    {
        GLfloat scale_x, scale_y;
        GLenum error;
        const GLsizei VI_width = *GET_GFX_INFO(VI_WIDTH_REG) & 0x00000FFF;

        scale_x = ispal ? +640.0f : +640.0f;
        scale_y = ispal ? -568.0f : -474.0f; /* ispal ? 576 : 480 */
        scale_x = scale_x / (GLfloat)(hres);
        scale_y = scale_y / (GLfloat)(vres);

        scale_y *= (line_shifter & 1) ? 1.0f : 0.5f;
        glPixelZoom(scale_x, scale_y);

        glDrawPixels(PRESCALE_WIDTH, vres, GL_RGBA, GL_UNSIGNED_BYTE, PreScale);
        error = glGetError();
        if (error != GL_NO_ERROR)
            DisplayGLError("Problem scaling the frame drawing.", error);
    }

Did I ever tell anyone how much this game. Scares the SHIT out of me??? I have zombie apocalypse nightmares in my dreams when I wake up every now and then, because of this blasted game.

[RPGMaster]

Lol those are some weird colors. I've become more interested in accurate graphics after realizing how good it looks without the blur from the UB. Not to mention I'm getting sick of seeing major flaws. That being said, I decided to read through your source and compile to read the ASM output.

I honestly think you should either take advantage of MSVC's unique features, or use a different compiler. The reason why is because the performance is suboptimal. I noticed you had quite a few switch statements where you & a number that's a power of 2 - 1. Here's what MSVC typically does

 switch (code & 0xf)
0C832250 8B 44 24 08          mov         eax,dword ptr [esp+8]  
0C832254 83 E0 0F             and         eax,0Fh  
0C832257 83 F8 0F             cmp         eax,0Fh  
0C83225A 0F 87 D5 00 00 00    ja          $LN9+0CEh (0C832335h)  
0C832260 FF 24 85 38 23 83 0C jmp         dword ptr [eax*4+0C832338h]

That cmp and ja are useless. Even if you think that switch overhead wouldn't matter at all, I know for sure MSVC is doing a worse job than other compilers. I compiled your plugin with Clang and usually got ~2-3 more VI/s, but I only tested it briefly. For some reason I wasn't able to compile with Clang until I commented out USE_MMX_DECODES. Me and my bad habits lol. For some reason I just insist on using MSVC as an IDE. Just something about it that I really like. I really need to get used to using MinGW.

I know you probably don't like the idea of using compiler specific features, but it's worth it if you insist on sticking with MSVC. I personally just use #ifdef so that I can easily disable it when I want to use a different compiler.

So for the switch, all you'd need to do is copy paste something like

#ifdef MSVC_FEATURE_ENABLED
default:    __assume(0);    break;
#endif

into the switch statements where specific ranges are guaranteed. The only hassle imo is writing out all the cases. So I typed all case numbers in notepad, copy it and paste into the code, then erase the ones that are duplicates since the IDE will let you know.

I believe GCC's way of getting rid of default case is __builtin_unreachable, but I don't think I ever got that working. Perhaps I was using an outdated GCC at the time. You probably wouldn't need to use it anyway with GCC since it does switches properly regardless.

In your next update will there be any other significant code changes besides the API change? Just curious whether I should wait for you, or continue debugging and tweaking your code. I must say man, good work so far! Idk if you cleaned up the code a lot or if I just got smarter since the last time I read through it. I can understand more code now!

[MarathonMan]

Originally Posted by HatCat

Besides, once I implement proper OpenGL scaling to fix what DirectDraw cannot supplement for us in accurate emulation of VI DAC, whether I use GL_RGB or GL_RGBA will be rendered impertinent to the matter as textured quads will be GPU-accelerated and not so graceless as to go through the bus like glDrawPixels does.

I've been curious about this. As you know, I've been using OpenGL and using the canned scaling methods (currently NN, but perhaps I should switch to bilinear?). Do you know which algorithm the VI actually uses to scale the image?

[HatCat]

Whatever it is, it isn't nearest-neighbor. I don't know if you saw, but when angrylion posted this on #n64dev:
http://higgs.rghost.ru/54765047/image.png

marshall said it was correct. Here you see a 640x474 frame buffer up-scaled to a 1024x768 drawing screen.
In addition to that both Gonetz and marshallh have made references to bi-linear filtering of texture elements.

Anyway, you're asking what you "should" switch to. In your case I'd probably be half-and-half about it since last I tested you didn't emulate per-pixel VI filters anyway, so maybe use bilinear, maybe you see the pixels better with NN...whatever you prefer.

[run of the mill twat]

actual n64 for comparison

[ReyVGM]

So the game is enclosed in black bars and the garbled pixels on the left do not show?