Supermodel Forum

I may need to send you more builds. A table of which works and which doesn’t will be needed. I can’t replicate this bug over here and I have no explanation for how it could happen looking at the changes. There was a crosshair refactor and earlier there was a change to how input focus is handled but neither explain this.

In addition to the other builds, please try these. I realize ae5af4c is on the web site but I built this myself manually to rule out any bizarre issue with the build bot picking the wrong commit.

Supermodel 188bb5 -- make sure to use the included Games.xml
Supermodel ae5af4 -- make sure to use the included Games.xml

Thank you. If we can get this down to the exact pair of git commits where it breaks, we can solve this.

WAIT A MINUTE. I think I know what's going on but it would have been git f7dcc1c that broke things for you. Did you test ae5af4 with oceanhun? I bet it doesn't work for you.

Here's what probably happened: The ROM set changed. There was an Ocean Hunter redump and what used to be known as "oceanhun" is now "oceanhuna". As you know, Supermodel loads files based on CRCs. So what happened is that your oceanhun.zip is actually being identified as oceanhuna, which is its new name in MAME. I'm guessing you did not have NVRAM settings for oceanhuna, so it created new ones. I noticed that the .7z archive you sent had oceanhun and oceanhuna NVRAM files. You are presumably dropping these builds into the same directory so by now, you've got both NVRAMs. But you want to play with your old oceanhun.nv.

What I *cannot* explain is the middle mouse button not working. It works for me. Are you sure that the credit settings are not different in oceanhuna and you're forgetting to insert enough coins? By default it takes 2.

How to test this hypothesis quickly
Download a really old Games.xml. For example, grab the one from here and run it with the latest build on the Download page (95fc08e). Does it work again? If yes, we've found the problem and then all you just need to rename your oceanhun.nv to oceanhuna.nv to use the new Games.xml file going forward.

Bart wrote:WAIT A MINUTE. I think I know what's going on but it would have been git f7dcc1c that broke things for you. Did you test ae5af4 with oceanhun? I bet it doesn't work for you.

Here's what probably happened: The ROM set changed. There was an Ocean Hunter redump and what used to be known as "oceanhun" is now "oceanhuna". As you know, Supermodel loads files based on CRCs. So what happened is that your oceanhun.zip is actually being identified as oceanhuna, which is its new name in MAME. I'm guessing you did not have NVRAM settings for oceanhuna, so it created new ones. I noticed that the .7z archive you sent had oceanhun and oceanhuna NVRAM files. You are presumably dropping these builds into the same directory so by now, you've got both NVRAMs. But you want to play with your old oceanhun.nv.

THAT'S IT! I was able to zero in on oceanhun but I couldn't pinpoint exactly what it was doing wrong. I have since rolled back to ffc3209 for my main LaunchBox build while we were troubleshooting this as I'd suspected something changed with the Mar-2023 builds.

Bart wrote:What I *cannot* explain is the middle mouse button not working. It works for me. Are you sure that the credit settings are not different in oceanhuna and you're forgetting to insert enough coins? By default it takes 2.

Which leads us to this. The middle mouse button/start wasn't responding (the keybind wasn't actually lost) because the game was picking up the oceanhuna.nv that was just created with the default 2 credits and thus didn't have the Free Play settings or all my other Test Mode changes.

Bart wrote:How to test this hypothesis quickly
Download a really old Games.xml. For example, grab the one from here and run it with the latest build on the Download page (95fc08e). Does it work again? If yes, we've found the problem and then all you just need to rename your oceanhun.nv to oceanhuna.nv to use the new Games.xml file going forward.

I went directly to renaming my original oceanhun.nv to oceanhuna.nv and it worked! For lostwsga, I simply re-calibrated the gun in lieu of the DPI awareness changes previously mentioned.

TL;DR: There was a change, but it wasn't the Supermodel.ini. It was the Games.xml all along (which I always overwrote every update).

Thanks Bart for Sherlocking this with me. I am now running 95fc08e with no issues. SOLVED!

Excellent. THE WORLD MAKES SENSE AGAIN. I love when that suddenly happens. Thanks for your patience. Yeah, these ROM set changes are frustrating but they are rare and will probably only get even rarer with time, so I can't think of any obvious mitigations (other than breaking with the MAME naming convention) that are worth doing.

We make a good troubleshooting team. My LaunchBox build is happy again.

Bart wrote:Excellent. THE WORLD MAKES SENSE AGAIN. I love when that suddenly happens. Thanks for your patience. Yeah, these ROM set changes are frustrating but they are rare and will probably only get even rarer with time, so I can't think of any obvious mitigations (other than breaking with the MAME naming convention) that are worth doing.

Hahaha, THE GLORY! Yes, it can happen once a while and will be increasingly rare. Perplexing at first yes, but pretty low risk overall. Probably a good addition to your README.md/FAQ if you ever get to it in the future.

RE: lostwsga Calibration off.

I think there's a change in behaviour with the Lost World crosshair now?

It seems the crosshair alignment is now tied to the model3 native aspect ratio.
You have to play in a native aspect window, or use -stretch on a widescreen monitor to get alignment.
If you don't -stretch, and play with vertical black bars in widescreen, the x co-ord rises too quickly.

Try using a funky window resolution to demonstrate,

Code: Select all

Supermodel.exe Roms\lostwsga.zip -res=800,400

If you reverse the x,y numbers so the y res is larger,

Code: Select all

Supermodel.exe Roms\lostwsga.zip -res=400,800

the y co-ord will rise too quickly.

If you add -stretch to either of the above examples, all is fine.

Before the refactor the crosshair would track across the rendered area correctly regardless of window res.

Not sure if that's intentional/inevitable.

Was it the refactor or DPI awareness that caused this?

Ah yeah, you know what, it is messed up. In Main.cpp, xRes and yRes actually refer to the visible renderer output resolution, which can be smaller than the viewport. The crosshairs refactor takes what the user passed in directly, which is completely wrong. xRes and yRes are also readjusted when going into full screen mode (I don't think this adjustment does anything because the resolution will still be the same unless for some reason SDL picks a different one). The fix is probably to just avoid having CCrosshair read the config and instead get the resolution each frame as a parameter.

I'll make a branch. Would be helpful if you could help me test because I'm about to leave for SF for the Game Developer Conference and won't have my PC. Should be able to throw something up in about 10 mins.