"Non bug" bug in Zsnes...

A forum for admins and moderators to move verified bug posts to. Only move topics here if they are indeed verified bugs.

Moderator: ZSNES Mods

Post Reply
Snark
Trooper
Posts: 376
Joined: Tue Oct 31, 2006 7:17 pm

"Non bug" bug in Zsnes...

Post by Snark »

I posted this two months ago but I figured I might as well make a proper bug report. I realise this might be the most unsual bug report in Zsnes's history though, but strickly speaking, it's an emulator bug.

Basically, a SMW hack plays fine in Zsnes but doesn't work on real hardware (or bsnes). On hardware/bsnes, the game crashes/freeze after you die, also there is no music playing. The game plays fines with music in Zsnes...I figured this is because the hack was made with Zsnes in mind and relies on some of it's behavior. So basically the hack isn't "supposed" to work.

I'm not sure what's the philosophy of the Zsnes team on this: if you ever get to a point where it becomes more accurate, would you make special exceptions to "allow" some hacks/translation to work "properly"? Note I do not want in any way to start an emulator war or bash Zsnes.

I realise there's nothing wrong, from a gameplay perspective to have those hacks work on your emulator, but fixing these "non bugs" might ultimately help fixing other commercial games.


Anyway, here are both the hard patched and original NSRT reports: tested with 1.51
---------------------Internal ROM Info----------------------
File: SUPER MARIO WORLD.SMC
Name: Bowser's StrikeBack Company: Nintendo
Header: Exists (type?) Bank: LoROM
Interleaved: None SRAM: 16 Kb
Type: Normal + Batt ROM: 32 Mb
Country: USA Video: NTSC
ROM Speed: 200ns (SlowROM) Revision: 1.5
Checksum: Good 0xA0DA Game Code:
---------------------------Hashes---------------------------
CRC32: 3EFB7FCC
MD5: 24E2EFC5F19589CA15EB7BF6C5C7C125
--------------------------Database--------------------------
ROM wasn't found in the database (possible bad dump).
You can try using -fix or -findover to see if the
file has been slightly altered in a rectifiable way.
---------------------Internal ROM Info----------------------
File: SUPER MARIO WORLD.SMC
Name: SUPER MARIOWORLD Company: Nintendo
Header: Exists (type?) Bank: LoROM
Interleaved: None SRAM: 16 Kb
Type: Normal + Batt ROM: 4 Mb
Country: USA Video: NTSC
ROM Speed: 200ns (SlowROM) Revision: 1.0
Checksum: Good 0xA0DA Game Code:
---------------------------Hashes---------------------------
CRC32: B19ED489
MD5: CDD3C8C37322978CA8669B34BC89C804
--------------------------Database--------------------------
Name: Super Mario World
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Side Scrolling
edit: link to ips http://www.smwcentral.net/?p=showhack&id=56
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

I don't think there will be exceptions, once these romhacks/translations fail due to better emulation.
Last edited by creaothceann on Sun Jun 17, 2007 2:24 pm, edited 1 time in total.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
franpa
Gecko snack
Posts: 2374
Joined: Sun Aug 21, 2005 11:06 am
Location: Australia, QLD
Contact:

Post by franpa »

well the they could have hacks and have them be enabled/disabled via a option in the config file... in fact they already have that option, but i think only 1 hack remains >.>

maybe they could add more? not likely.
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Re: "Non bug" bug in Zsnes...

Post by Deathlike2 »

Snark wrote:I posted this two months ago but I figured I might as well make a proper bug report. I realise this might be the most unsual bug report in Zsnes's history though, but strickly speaking, it's an emulator bug.
It isn't really.
Basically, a SMW hack plays fine in Zsnes but doesn't work on real hardware (or bsnes). On hardware/bsnes, the game crashes/freeze after you die, also there is no music playing. The game plays fines with music in Zsnes...I figured this is because the hack was made with Zsnes in mind and relies on some of it's behavior. So basically the hack isn't "supposed" to work.
Blame the author of the hack.
I'm not sure what's the philosophy of the Zsnes team on this: if you ever get to a point where it becomes more accurate, would you make special exceptions to "allow" some hacks/translation to work "properly"? Note I do not want in any way to start an emulator war or bash Zsnes.
Doubt that would happen. If doesn't work on a cart (or on those flash carts), then it makes no sense to support broken behavior.
I realise there's nothing wrong, from a gameplay perspective to have those hacks work on your emulator, but fixing these "non bugs" might ultimately help fixing other commercial games.
That's the wrong way at looking how commerical games get fixed. Keeping this behavior is more likely to induce bugs in commericial games, not the other way around.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

There is no hack for the game only an emulator error which should be fixed but it's on my plate of things to do.
Watering ur plants.
byuu

Post by byuu »

creaothceann wrote:I don't think there will be exceptions, once these romhacks/translations fail due to better emulation.
The only one I've been seriously anticipating is blocking VRAM writes outside of vblank. That one causes so many fan programmers problems:
- Ys 4 dialogue text (though Gideon Zhi recently fixed this)
- Dual Orb 2 yes/no box
- Dragon Quest 1&2 Reprise title screen

Even official games benefit from blocking VRAM writes during vblank, eg Peter Pan / Hook, or whatever. The opening shows garbled characters if allowed.

It hit me back in 2001 with Der Langrisser, too ... though I knew about vblank, I was actually hitting the tail end of a really long NMI that wasn't giving me enough vblank time.

I'd say at least make it an option. It will need to be accessible from the GUI for a while. If you're worried about timing, might I suggest starting off relatively lax? Block VRAM writes from V=8-216, rather than V=0-224. Of course, only when the display disabled flag is clear. That shouldn't hurt any current games.

The rest of the differences are relatively minor. Blocking OAM and CGRAM writes outside hblank+vblank would be nice, too, but would require much sharper timing. Might not be a good idea to try it just yet.
randal
Rookie
Posts: 23
Joined: Sat Feb 23, 2008 9:15 pm

Post by randal »

Those hacks look amazing!


Edit: Figured it out
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Since this topic has been resurrected, I'll toss in this:

I certainly don't mind if any of my hacks don't play right due to improving accuracy of the emulator such as that Dual Orb 2 issue. That might even persuade me to dust off the cobwebs and fix it. :)

The real matter is the old stuff that would break where the author is no longer around and there's 0 chance of it ever being fixed. However, I think we've talked this circle out already. An older version of the emulator would always be available or something like that. The only downside is people probably won't be immediately aware that they need to try an old version with a potential broken patch, and might mistake it for a bug in ZSNES. It's education of the users and avoiding confusion and unnecessary reports which is the largest problem. :D
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
Post Reply