Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1181  
Old 19th July 2014, 03:48 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

Never mind, it turns out there is ONE way I can fix the 1964 Reset (F1) issue.
Fortunately they do call RomClosed() when you hit F1, just never RomOpen, InitiateGFX, or CloseDLL().

So I used RomClosed to call CloseDLL, which forces render_context and device_context both to NULL, to signify that emulation has ended.

[It is still incredibly unintuitive that they call RomClosed, but not RomOpen. I guess they tried to use the stuff done in InitiateGFX to preserve API contexts, but again, this is rather counter-intuitive and I don't agree with it.]

Then, I added this to ViWidthChanged() AND UpdateScreen():
Code:
    if (device_context == NULL || render_context == NULL)
    {
        DisplayWarning(
            "You're using 1964's reset feature, aren't you?\n"\
            "That doesn't look good! :)");
        RomOpen(); /* 1964 should have called this when doing reset. */
        return;
    }
The warning is partly to be a smartass.
It's also there because it's required...popping up a message box to stall the emulation thread long enough to fix the timing imbalance.

Also I pushed another commit which allows you to click the X / close the emulator window, even if there is an error message box blocking the way. This way if you're in an infinite loop of error messages from some process, you don't have to Ctrl+Alt+Del. So try pulling these changes in and testing black-screen/reset problems with emulators now.
Reply With Quote
  #1182  
Old 19th July 2014, 04:33 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

I downloaded your latest commit.

Hmm well, I never saw the messagebox for "You're using 1964's reset feature, aren't you?\n" pop up when using 1964. Resetting still doesn't work, but it must just be my computer .

I tried seeing if loading z64gl first fixes 1964's issue, but now not even that can repair it lol. pj64 1.4 kept crashing on me, so i couldn't do much testing with it. PJ64 1.6's functionality didn't seem to change.

So then I tried mupen64. If I loaded z64gl first, then switched to your plugin, i got a bunch of messagebox errors and I wasn't able to exit. Could that exiting problem during infinite messagebox popups be because the emulator is set to pause when not the active window?

If this latest one hasn't improved anything on your end, I'd like you to revert some of the changes ;/ .

As long as I'm able to fix the reset problem with z64gl, it's not a big issue. I will continue seeing if there's another solution though.

I might as well try to learn the plugin spec better. Since I want to fix up other plugins too.

I guess I'll start testing out Nemu too lol. I totally forgot about demo games not using the RCP.
Reply With Quote
  #1183  
Old 19th July 2014, 04:55 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

Quote:
Originally Posted by RPGMaster View Post
Hmm well, I never saw the messagebox for "You're using 1964's reset feature, aren't you?\n" pop up when using 1964.
Onl happens sometimes, like I said whether or not the problem happens in 1964 is random due to its bad timing. It probably won't happen near as often for full games like Mario where the speed is weighed down by doing the RCP in software.

Quote:
Originally Posted by RPGMaster View Post
Resetting still doesn't work, but it must just be my computer .
Doesn't work in what way?
That you're getting a black screen, or that you're still getting all those errors?
Because I'm still not talking about the black screen, just the errors.

Notice how I never said anything about me ever getting a black screen on any emulator. There was a slew of OpenGL errors caused by 1964 skipping right over initializing the OpenGL context when resetting the ROM; that's what this was about.

Quote:
Originally Posted by RPGMaster View Post
I tried seeing if loading z64gl first fixes 1964's issue, but now not even that can repair it lol.
Because z64gl appears to do the same thing as me now...uses RomOpen to start graphics emulation context instead of InitiateGFX. Perhaps try a plugin that does the opposite this time and then switch away from that.

Quote:
Originally Posted by RPGMaster View Post
Could that exiting problem during infinite messagebox popups be because the emulator is set to pause when not the active window?
Are you talking about what I just fixed in my commit? :/

It wasn't a problem; it just wouldn't let you click on or select any parent windows if I specified a hwnd to the message box. I've known that for quite some time; I just preferred it that way on purpose, at first. Until I noticed how easy it is to run into these errors.

Quote:
Originally Posted by RPGMaster View Post
If this latest one hasn't improved anything on your end,
You're still talking about the black screen then?
I guess it's hard to have it both ways, isn't it? Some emulators preserve the DirectX/OpenGL state via InitiateGFX, others do it via RomOpen. There's no magic way to balance it out. I don't have your hardware, so I can't test. It would be much quicker if you just learned wgl and some basic OpenGL and could play around with it yourself.

Quote:
Originally Posted by RPGMaster View Post
As long as I'm able to fix the reset problem with z64gl, it's not a big issue. I will continue seeing if there's another solution though.
Only reset issue I was fixing was 1964's heap of error messages.
Reply With Quote
  #1184  
Old 19th July 2014, 05:06 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Ah makes sense now. Sorry for the confusion then. I stopped getting those error messages a while back. That's why i was confused.

Sorry for all the frustration I may have caused. I guess it can't be helped .

I will just have to learn wgl and play around with it myself as you suggest.

At this point, just continue doing w/e you wish to do. I don't want you to spend too much time trying to fix a problem that seemingly only applies to me. I'll just have to figure out how to fix it on my end, just like Rice Video and its stack hash errors ;/ .

I still find it weird I have yet to see the "You're using 1964's reset feature, aren't you?\n" messagebox. I'll keep testing though.

Edit: In 1964 0.85, i get infinite loop messageboxes when reseting.

Last edited by RPGMaster; 19th July 2014 at 05:10 AM.
Reply With Quote
  #1185  
Old 19th July 2014, 05:15 AM
hellbringer616 hellbringer616 is offline
Junior Member
 
Join Date: Jul 2012
Posts: 20
Default

silly question, But i see a lot of OGL stuff mentioned, is this plugin transforming into a hardware plugin? Will my dreams finally come true with bugless n64 emulation and HD glory?
Reply With Quote
  #1186  
Old 19th July 2014, 05:45 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by hellbringer616 View Post
silly question, But i see a lot of OGL stuff mentioned, is this plugin transforming into a hardware plugin? Will my dreams finally come true with bugless n64 emulation and HD glory?
The plugin is certainly a step in the right direction, but is definitely not a means of be-all-end-all N64 emulation woes.

Quote:
Originally Posted by HatCat View Post
It's a multi-threading issue. 1964 seems to guarantee success with the Reset feature better when all/most initialization was done in InitiateGFX and not RomOpen. If you do it in RomOpen instead of InitiateGFX then well it uses a separate thread to handle that.
It's not well-documented that any wgl* functions have to be executed from within the same thread, lest you like pulling hairs out. Probably doesn't help you at all, but...

Next! --> Use Loonix!
Reply With Quote
  #1187  
Old 19th July 2014, 02:12 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

Nah, it does help, because Windows sucks, but I figured you'd suggest even earlier: Don't use plugin spec!

Because that's partly what's causing this...differnet emulators having different ways of trying to implement zilmar's open-to-interpretation, loosely defined plugin spec. He hasn't spent much time fixating its definitions for clarity over the years, so much as making new revisions that only function on Project64 (e.g. 1.7 donationware plugins that can't be used elsewhere) and promoting vendor lock-in. Not exactly the best example to go on, but for cross-emulator testing, it's all I have to work with.

RPGMaster: I'll try making a new separate function to initialize OpenGL, rather than just putting the whole thing in RomOpen/InitiateGFX/other functions. This way we'll be able to move the entire initialization/WGL handling across different zilmar-spec functions so you can debug which thread you need to have it done in faster.
Code:
static BOOL init_GL_context(HWND hWnd);
edit: still a black screen when exiting/re-loading rom in mupen for you right?
Reply With Quote
  #1188  
Old 19th July 2014, 05:11 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

welp!
release tiem.

I wanted to do more features first, but I quickly realized how many speed-ups/fixes I've already done by now since the 4th attachment.

Now to make this thread less confusing, let's talk about what everyone can see. What should be done? Any fixes left to nag me with before I resume optimizing the RDP?

Well, thanks to RPGMaster's GUI there are 2 speed options: skip triangles (RDP command list functions) and vertical interrupts/UpdateScreen. So if you're playing Zelda Majora's Mask and Mupen64 tells you the game runs at 20 FPS, what do you do? You config the DLL by setting "Skip UpdateScreen" every 2 calls.
call -- skip -- skip -- call -- skip -- skip -- call -- skip -- skip
... this is 60 / (2+1) or 20 FPS you get triple the VI emulation speed from this plugin now.

Try playing with the other config options as well I guess in the GUI from "Configure Graphics Plugin". I'm in a very easy position to add new options...like RGBA channel mixing (swap Red coloration with Green, for example) or masking (each pixel is only 15, 25, 33, 3.14ass% game's full red/green/blue color), or maybe other ideas if people want.

Last edited by HatCat; 19th July 2014 at 05:15 PM.
Reply With Quote
  #1189  
Old 19th July 2014, 08:58 PM
zuzma zuzma is offline
Junior Member
 
Join Date: Jan 2013
Posts: 28
Default

Wait are those options in release five of your alternate reality drawan plugin? I don't see them : (

Edited==--=-

Last edited by zuzma; 19th July 2014 at 09:01 PM.
Reply With Quote
  #1190  
Old 19th July 2014, 09:07 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Maybe now would be a good time to add some filter/shader support? Just saiyan.

Also, the "DP frame buffer" screen resolution option has issues, at least on PJ64 2.1. On OoT, it appears to set the screen size to 320x237, but as you can see on this image, this results in some pixels being lost, most visible on the C-button items:



Setting it to 320x240 manually appears to deliver a proper image with no lost pixels.

Also, the frameskip option does not appear to deliver any appreciable speedup. I set it to 2 for 20FPS games as you suggested, and didn't get more than a VI or two out of it.
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 10:04 AM.


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