Home Page Forums MAME MAME The SNES WIP topic

I see no problem in Legend of Zelda and Super Mario World has sound for what I can hear (but my eeepc run it at around 20%, so it's really cracking)

would you both mind to be more specific in what's wrong and possibly tell when the regressions appeared?

here everything works as berfore

This is really weird. Yesterday, Tafoid reported that he was getting a black screen in Mario Kart when trying to go in-game, and massive graphics problems in HyperZone and Joe & Mac. All three games worked fine for me after syncing up to the latest SVN tree and doing a clean build, and maliehmut confirmed what I was seeing. However, this morning, Kale reported the same HyperZone graphics corruption problems.

Now, some people are seeing problems in other games, but etabeta isn't seeing them. I don't have access to SVN, so I can't test on my own.

It can't be a 32-bit versus 64-bit issue, since both Tafoid and I use 32-bit builds. It can't be an MSVC versus GCC issue, because both Tafoid and I use GCC. All I can come up with is somehow he and I are using different versions of GCC - I'll post the output from gcc -v when I get home from work.

the difference may be in the game image used. it seems that Harmony's changes to add spc7110 support contained a line which broke loading of carts with an header

please try again with svn 5837 and post if you still have issues (or use nsrt to remove headers )

A clean 64-bit Linux build of SVN 5835 is playable in-game for Mario Kart, Mario World has sound, and Rock n' Roll Racing plays fine (these are all headerless images).

Kale has confirmed that rev 5837 fixes the problem for headered images as well.

adding the fact that the removed line was wrong, I think we are back to working state on every computer around

I am not sure if you saw my notes on IRC. The Mario Kart is not a recent regression. It has been there since at least August 12th. See my post with screenshot (bottom)

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=52543#Post52543

It only happens if you quit while in gameplay and start another session. If you quit during any of the menus or clear your .nv it works fine the next start. And it is not really black it is just shifted to the left. You can see a single pixel of the screen on the far left. So I don't know if that is a mode 7 bug, a nvram bug, multisession bug or a compile bug (or all!)

Tafoid - Does that describe what you were seeing?

Just in case: I am using GCC, 32 bit on XP SP3 standard build with no fancy switches.

The only regression I have seen is that controls stopped working in "Super Star Wars - Empire Strikes back" just get stuck at start screen. no response. It worked release 133 and at lest part way into the SNES party of v134. I have not had time to narrow when it broke.

Edit: Better screen shot in Shideravan's Posrt

No, it's not that regression. It's a new one. But i think they already fixed it with latest svn.



This annoying bug is still present in all games of the Super Star Wars series.

ht1848: the DSP-1 didn't work on August 12 so it was not possible to get a working Mario Kart screenshot in that version. Would you care to share what you're smoking?

yeah true true - "working" was probably a bad way of saying it. "In-game" would be a better way of stating it. Back then it had the DSP-1 issue that etabeta later fixed (all the drivers hit invisible walls) and it did the black screen upon restart after quiting from gameplay. 1 of those behaviors is now fixed (gameplay).

I'll check tonight on that last update (svn 5837), sounds like it worked for guigongas.

On the multi-session bug. I found a slight variation...

As you have seen in previous screenshots if you exit emulation while in the driving game play you get this all black except for sliver on left side.

Just found that if you quit from game play portion of the attract/demo you get a different black bar. By attract I mean, start game and wait until it goes into the driving demo with Mario. This is with svn5839, clean build.

Not sure if that 2nd behavior helps track down the issue.