Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #691  
Old 22nd June 2014, 09:46 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 381
Default

yeh, BGRA pixel formats were added to OGL 1.2
Reply With Quote
  #692  
Old 22nd June 2014, 02:59 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.
Reply With Quote
  #693  
Old 22nd June 2014, 03:08 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.
Reply With Quote
  #694  
Old 23rd June 2014, 04:04 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.
Reply With Quote
  #695  
Old 23rd June 2014, 05:11 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.

Code:
                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);
Code:
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.
Reply With Quote
  #696  
Old 23rd June 2014, 11:07 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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

Code:
 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
Code:
#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!
Reply With Quote
  #697  
Old 23rd June 2014, 01:43 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by HatCat View Post
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?
Reply With Quote
  #698  
Old 23rd June 2014, 05:25 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.

Last edited by HatCat; 23rd June 2014 at 05:27 PM.
Reply With Quote
  #699  
Old 24th June 2014, 11:56 AM
run of the mill twat run of the mill twat is offline
Member
 
Join Date: Apr 2014
Posts: 38
Default



actual n64 for comparison
Reply With Quote
  #700  
Old 24th June 2014, 02:36 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

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

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 05:47 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.