Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1721  
Old 23rd March 2015, 02:46 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

About Cruis'n Exotica, which is supposed to be the correct behavior?

I'm going to assume that your plugin should be correct, but with Jabo's it looks so different that I don't know if maybe there's something missing somewhere. And a video on youtube also shows something different. I believe the youtube video is a recording from a real N64.

Anyway, when you finish the game, the credits are displayed while your car is racing in a level, but the textures are transparent and completely crazy.
This is actually a mode you unlock after finishing the game.

On you plugin everything looks red and yellow. On the youtube video, it looks blue. On jabo's, it looks white.

Here are three saves, one after beating the last race, another in the middle of the credits, and the last one at the option screen where you can turn on/off the "Exotic Mode".
https://www.sendspace.com/file/qvk63m

And here's the youtube video (skip to the end):
https://www.youtube.com/watch?v=Q_2o7QrPT_Y


*edit*
Okay, forget it. Your plugin is correct. The level shown on the credits on the youtube video was different from the one I got. I tested each level and I found the one on the youtube video and it looks exactly the same.

Last edited by ReyVGM; 23rd March 2015 at 02:55 AM.
Reply With Quote
  #1722  
Old 25th March 2015, 11:09 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

I started debugging the black screen issue. I think the main issue is that these emulators are doing weird things.

When I loaded up Pj64 1.4, it calls InitiateGFX. Then when I boot up a game, it calls InitiateGFX twice, then calls RomOpen. The problem has something to do with those 2 calls to InitiateGFX. When I skipped init_GL_context in the 2 calls to InitiateGFX, I was able to see the screen. I don't understand why it's unloading the dll twice, each time you boot up a game. It seems error prone.

I'll need to examine the code in pj64 1.4 to see what is going on.
Reply With Quote
  #1723  
Old 25th March 2015, 04:27 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

ftr , I'm still on that tex_rect rewrite. Been trying to experiment with the legacy commit for that the past few days, taking a lot longer actually than I thought it would.

Quote:
Originally Posted by RPGMaster View Post
I started debugging the black screen issue. I think the main issue is that these emulators are doing weird things.

When I loaded up Pj64 1.4, it calls InitiateGFX. Then when I boot up a game, it calls InitiateGFX twice, then calls RomOpen. The problem has something to do with those 2 calls to InitiateGFX. When I skipped init_GL_context in the 2 calls to InitiateGFX, I was able to see the screen. I don't understand why it's unloading the dll twice, each time you boot up a game. It seems error prone.
Though init_GL_context only gets called from InitiateGFX #ifdef _DEBUG I think? So normally in release builds the OpenGL context doesn't get initialized until RomOpen which is when the emulation starts with a ROM open.

So I think it's a thread-sharing issue where the thread calling RomOpen is not the same as the one calling UpdateScreen and such.
Reply With Quote
  #1724  
Old 26th March 2015, 08:32 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
Though init_GL_context only gets called from InitiateGFX #ifdef _DEBUG I think? So normally in release builds the OpenGL context doesn't get initialized until RomOpen which is when the emulation starts with a ROM open.

So I think it's a thread-sharing issue where the thread calling RomOpen is not the same as the one calling UpdateScreen and such.
Yes, I temporarily changed it to experiment with calling init_GL_context in InitiateGFX. I tried seeing if I could find any leads, but no luck ;/ . All I know is that PJ64 2.x, 1964, and Apollo handle that stuff better . I figure I'm better off fixing the problem on the emulator's side, so I'll worry about this black screen issue if/when I decide to work on an emulator.

Time to read up on functions and practice .
Reply With Quote
  #1725  
Old 30th March 2015, 07:22 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Major League Baseball featuring Ken Griffey Jr

The score numbers are horizontal for some reason.



Save
https://www.sendspace.com/file/q3h8fj
Reply With Quote
  #1726  
Old 30th March 2015, 10:37 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

By the way, I was wondering if this could be implemented in the future. It's about the screenshot function. Right now if you take screenshots with F3, and close the emu for some reason, if you resume the screenshot taking task after starting the emu again, it will not continue with the file number you left off, instead, it will overwrite the images you just took.

I found that out the hard way today

Last edited by ReyVGM; 30th March 2015 at 10:52 PM.
Reply With Quote
  #1727  
Old 31st March 2015, 02: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

Quote:
Originally Posted by ReyVGM View Post
By the way, I was wondering if this could be implemented in the future. It's about the screenshot function. Right now if you take screenshots with F3, and close the emu for some reason, if you resume the screenshot taking task after starting the emu again, it will not continue with the file number you left off, instead, it will overwrite the images you just took.

I found that out the hard way today
It's a good idea to keep the window open, not close it and re-open it to play the game again. Otherwise the screen-shot capture resets back to 0000 and starts back from the beginning and runs the risk of overwriting old screenshots, unless you have backed them up which should be a good idea.

Like 2 years ago when I was doing the RDP directly off of MAME with SDL I think I had it set up to try to open the file name experimentally and report if the file name already existed or not. For the sake of simplicity it seemed tedious on algorithm to have this implemented since it's a bit of extra code to attempt disk file system access more times just to check whether I'd be overwriting a file yet or not.
Reply With Quote
  #1728  
Old 31st March 2015, 03:07 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Well, unfortunately, things happen that force you to shut down the computer, or the emulator might crash (which is often the case with PJ64).

Having to move hundreds of images to another directory and then having to rename the new set of hundred of images to match the old one, is well, really cumbersome.

But if you don't feel comfortable adding the lines of code to prevent that issue, then that's ok.
Reply With Quote
  #1729  
Old 31st March 2015, 03:41 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by ReyVGM View Post
Well, unfortunately, things happen that force you to shut down the computer, or the emulator might crash (which is often the case with PJ64).

Having to move hundreds of images to another directory and then having to rename the new set of hundred of images to match the old one, is well, really cumbersome.

But if you don't feel comfortable adding the lines of code to prevent that issue, then that's ok.
I think it would be easier to solve some of the other issues / using a workaround.

You say the emulator crashes. That shouldn't happen too often with PJ64. So something is likely wrong with your setup.

As for a work around, you can use a file renaming tool. I actually ended up doing that, when I dumped microcode, because that was much more convenient than having to write the extra code.
Reply With Quote
  #1730  
Old 31st March 2015, 03:42 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

maybe, I will try to remember to think about it before releasing.

Quote:
Originally Posted by ReyVGM View Post
Having to move hundreds of images to another directory and then having to rename the new set of hundred of images to match the old one, is well, really cumbersome.
Since you brought it up though, what would you think about having screenshots all logged to their own subfolder?

Occasionally I find I keep having to cut and paste consecutive screenshot files to their own folder organized out of the rest of the generic screenshot folder. Like if I want to do a sprite rip from animated screen dumps.

Like instead of hitting F3 and all the BMP/DIB screenshots going directly to the screen-shot folder configured in pj64, have a subfolder for each ROM? I was thinking just name it after the two-character cartridge code for brevity/conciseness though I imagine you would say that would confuse some users.

Last edited by HatCat; 31st March 2015 at 03:44 AM.
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 11:19 AM.


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