Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #851  
Old 2nd July 2014, 04:26 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

a'ight, *now* we're getting somewhere.

As it turns out, glViewport DOES report a GL error in the state machine error flag if I invoke ChangeWindow thru Mupen64, but not Project64 1.6 ... meaning Project64 1.6 is somehow suppressing the OpenGL error state during this particular time (but not others, since i've seen GL errors for other code before running on pj64 1.6). Great, more shit caused by dealing with winapi.

I got a GL_INVALID_OPERATION, which according to MSDN:
Code:
GL_INVALID_OPERATION

	

The function was called between a call to glBegin and the corresponding call to glEnd.
seriously...no way, the names "glEnd" and "glBegin" only exist 1 time in my entire source tree and that's in a compact separate function that isn't even ever called in software-blitting mode. Something else must be going on.

And according to this:
https://www.khronos.org/opengles/sdk...glViewport.xml

GL_INVALID_OPERATION isn't even a known associated error with glViewport.

Damn does Windows have to suck this much ass.
Reply With Quote
  #852  
Old 2nd July 2014, 05:15 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Alright, so before I can release this version of the plugin, here's where I'm at.

Code:
test = glGetError();
glViewport(0, 0, 1024, 768);
test = glGetError();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
DisplayGLError("test", test);
This returns GL_INVALID_ERROR in Mupen64, and GL_NO_ERROR in pj64 1.6, Nemu64, and 1964 1.1 (while itmay return GL_NO_ERROR in the other emulators, the fact is it still was a null operation and made no changes to the viewport like it should have).

It DOES work, when glViewport is called within the VI main screen updating loop, but when invoked through the full-screen window changing function in zilmar spec, it somehow fails??

It's very specific info, but it's still confusing. Time to sleep haha
Reply With Quote
  #853  
Old 2nd July 2014, 07:04 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

Ok, so let me get this straight. Given the RDP always scales the image, does this mean that while the rendered image looks like this:



In reality, what the VI spits out to the TV (before encoding to whatever analog signal you're using, of course) is actually this?

Reply With Quote
  #854  
Old 2nd July 2014, 01:39 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Fixed the problem by synchronizing GL context calls to UpdateScreen.

Seems the plugin specifications are bound in a threading fashion, so UpdateScreen, ProcessDList, ProcessRDPList and other zilmar-spec methods intended for continuous and indefinite invocation will permit calls to the OpenGL context state and other video card interfaces. If however, I put any OpenGL function at the top of other spec functions, like CaptureScreen, ChangeWindow, ... there is an inevitable GL_INVALID_OPERATION which only Mupen64 will report to me.

I was wrong that glViewport itself caused GL_INVALID_OPERATION; actually it was glGetError that did, which meant that at the time the plugin spec was requesting full screen mode, it was in some multi-threaded fashion that forgot I had already created an OpenGL render context over InitiateGFX and RomOpen.

Quote:
Originally Posted by GPDP View Post
Ok, so let me get this straight. Given the RDP always scales the image, does this mean that while the rendered image looks like this:
http://i.imgur.com/XFmtVXh.png

In reality, what the VI spits out to the TV (before encoding to whatever analog signal you're using, of course) is actually this?

The RDP only renders the image like our NVIDIA/ATI video cards do; it doesn't do any scaling.

And I said that the VI can output only one single resolution, and that's 640x480. Neither dragonminded nor angrylion have acknowledged a different output resolution for PAL as opposed to NTSC; it is simply said that this resolution is native to the VI regardless of the game's FB setup or the TV type.

The VI isn't actually "scaling" the 320x237 FB to 640x237, because delta_x = x2 - x1 of H_VIDEO_REG, and the difference of the end points happens to be 640 and not 320, causing a width of 640 pixels in Mario64. There is no OpenGL scaling being done at this point; it just reads in each pixel twice to double the width due to the way the VI registers are laid out. Only the vertical scaling is handled by OpenGL driver on a 640-px-wide viewport.
Reply With Quote
  #855  
Old 2nd July 2014, 02:18 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

I read Dragonminded's document, and while I found the part that the N64 supposedly only outputs 640x480, he then outlines several video modes, including 320x240, 640x240, and 640x480, which appears to contradict this statement. Gonetz, in his latest blogpost about VI emulation, then talks about non-interlaced (i.e. 240p) and interlaced outputs (480i), as well as an extra mode (320x640).

I am simply trying to make sense of how the VI's native resolution can be 640x480, when most games demonstrate otherwise. Is the output line-halved down to 640x237 somewhere later down the line?

Also, it would make sense that there is some horizontal interpolation going on when the width is doubled. It might be why Perfect Dark looks way blurrier in its normal-res 320x218 mode as compared to its 640x218 hi-res mode, which is quite sharp, as there would be no need for interpolation then. SNES and PS1 games, despite outputting resolutions just as low as or lower than 320x240, do not appear to look blurry.
Reply With Quote
  #856  
Old 2nd July 2014, 02:38 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

No it does not contradict the original statement. These video modes you are seeing are discussions about N64 frame buffer. Also, the games do not "demonstrate otherwise" because RCP::VI hardware is manufacturer-defined, not game-defined, so there is no such thing as games demonstrating otherwise what the native VI resolution is, because software doesn't redefine hardware.

All of what you saw in dragonminded's document about the alternate possibilities for video modes (640x480, 320x240, 640x240, ...) are defined by VI_X_SCALE_REG and VI_Y_SCALE_REG (and technically VI_WIDTH_REG as well), which control how the native MxN frame buffer picture is scaled into the 640x480 VI resolution which must be sent to the TV.
Reply With Quote
  #857  
Old 2nd July 2014, 02:41 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

I have a question of personal preference.

In full screen mode should I automatically fit the entire screen with the GL viewport so that the video output fills up your monitor? (This means ignoring whatever config setting you have for VI/DP/user-defined resolutions as relevant only to windowed mode.) Or should I expect the user to switch their monitor to 640x480 display desktop resolution in Windows, or use a user-defined resolution of 1024x768 on a 1024x768 monitor if they would rather force stretching? (If they do neither, the rendering canvas is just at the bottom-left of your monitor in full-screen mode.)

I'm starting to sort of prefer the former, but the latter does help enforce the active application of dsx's interesting monitor-defined scaling idea.
Reply With Quote
  #858  
Old 2nd July 2014, 03:39 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
The RDP ... doesn't do any scaling.
Agree. The RDP just generates framebuffers of arbitary dimensions and the VI scales them accordingly. Heck, even the CPU can just render images of whatever size it wants and tell the VI to output them.

Quote:
Originally Posted by HatCat View Post
And I said that the VI can output only one single resolution, and that's 640x480.
I guess... technically. It was my understanding the N64 outputs an interlaced (240p) or non-interlaced (480i) NTSC signal. For 240p images, the VI just doubles each pixel... I think. NTSC is confusing. Side note: PAL consoles definitely did 288p/576i. LoZ:OoT ran somewhere around ~20FPS internally for NTSC, ~18FPS on PAL.

I'm not sure what you were getting at with your last paragraph, but the VI certainly scales the image. The RDP can technically has a limitless number of framebuffers of various sizes, and the VI just scales them and outputs them to the TV.

EDIT: okay, the last post clarified things.

Last edited by MarathonMan; 2nd July 2014 at 03:51 PM.
Reply With Quote
  #859  
Old 2nd July 2014, 03:52 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

What I was saying about doubling each pixel was because the frame buffer was 320px wide, yet VI_H_START_REG end minus start was equal to 640, so formal line interval calculations wrote the same pixel twice, through a very big VI algorithm which I myself didn't finish reading. It came from angrylion's interpretation of the SGI simulator database and the Verilog tree, so it certainly wasn't made up. Not to mention, it evidently works and does the job! And conforms to what dragonminded also found out about the RCP.

A game like Resident Evil 2, xend - xstart would not be 320, nor would the pixels be doubled to an hres of 640...fucked up game.

In this sense, the VI ultimately has a "scaling" effect, yeah. The RDP as a rasterizer could potentially do rectangle scaling, but for the purposes of what was meant in this conversation, the RDP does not scale FB.

and edit while posting, yay you got what the last post meant

Last edited by HatCat; 2nd July 2014 at 03:56 PM.
Reply With Quote
  #860  
Old 2nd July 2014, 03:59 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
A game like Resident Evil 2, xend - xstart would not be 320, nor would the pixels be doubled to an hres of 640...fucked up game.
A couple posts back, when somebody posted the TV capture image, the hues on the two images were vastly different. Was that just capture card related, or

http://forum.pj64-emu.com/showpost.p...&postcount=695
http://forum.pj64-emu.com/showpost.p...&postcount=699

Also, I like octuple-edited that post.

Last edited by MarathonMan; 2nd July 2014 at 04:02 PM.
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:03 AM.


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