Official Bug Topic

[hydr0x]

You got a DQ6 cart?

yeah, why not, what's so special about that, i have ToP, SD3, Langrisser, FE, THG, FFV, DQ5 and others too, they are not THAT expensive on ebay, are they?

Anyway, just because the gfx appears less messed up (from the user's pov) while disabling new gfx engine doesn't prove that there is an emulation bug in the first place. Disabling the new gfx could inadvertanly "fix" so to speak a bug that happened on the original console. Improbable, but not impossible.

There's many things that programmers "didn't intended"...but it happened anyway. Some games had bugs. Because of that, the importance of testing things on real hardware.

you're right, tell me how far this is into the game and maybe i'll check it out...

[Lorddamien]

you're right, tell me how far this is into the game and maybe i'll check it out...

you didn't read my previous post did you? anyway I'll give more details. It's in the shrine of Dhama where you change classes, but it's the destroyed version in the real world. There are swamps in there with a layer of mist. You can first get there right after you are sent to get the mirror of Ra (Lar's mirror I think in the japanese version). It's not that far into the game, I guess around the time the characters are level 10-11.

[hydr0x]

lorddamien of course i read your post, problem is, i don't know the game, haven't played it AT ALL, so saying yeah it's after you defeat bla blah and bla doesnt help me... i need to know how much time i have to spend (in the japanese version without jap knowledge!!) to get there... i don't have any cheat devices to get there either...

[Bent]

Game name: Super Mario World 2 - Yoshi's Island

Type of bug: graphical


In stage 2-4, when entering the room with the lava and moving blocks, the lava is displayed when the screen is supposed to be black, during the fade-in effect (for lack of a better name) when you go through the pipe. it is as if the background is displayed in the foreground.

Code: Select all

---------------------Internal ROM Info----------------------
       File: Super Mario World 2 - Yoshi's Island (U) (V1.1).sfc
       Name: YOSHI'S ISLAND        Company: Nintendo
     Header: None                     Bank: LoROM
Interleaved: No                       SRAM: 256 Kb
       Type: Super FX2 + Batt          ROM: 16 Mb
    Country: USA                     Video: NTSC
  ROM Speed: 200ns (SlowROM)       Version: 1.1
   Checksum: Good 0x5E32             CRC32: CF98DDAA
--------------------------Database--------------------------
   Name: Super Mario World 2 - Yoshi's Island
Country: USA                    Version: 1.1
 Port 1: Gamepad                 Port 2: Gamepad

Here's a savestate of what he's talking about (of the european version though). It's the same bug I mentioned earlier. The intro effect letting the background shine through where it shouldn't, and also the flickering/stuttering where the effect is used with the displacing vertical segments of the foreground. It looks like the same function is used for the moving stones, the lava, and the "dizzy" effect in other levels.

Hmm, sorry, i scanned through the reports to make sure it hadn't been mentioned and I must have missed it. Oh well, doesn't hurt I guess.

EDIT: I have a little more info about the Super Metroid bug I posted. First of all, entering Norfair confimed my guess about the moving background being the cause. What's more interesting is the heat shimmer makes the bottom line of the map scroll as you are walking as if it is part of the play field instead of the status. Check out the screenshot or the savestate , which should show you.

Save state

Screenshot

[blackmyst]

Hmm, sorry, i scanned through the reports to make sure it hadn't been mentioned and I must have missed it. Oh well, doesn't hurt I guess.

Well now we know that it's not just the "dizzy" levels that have the "fade-in" bug, but also other levels with up and down moving foreground segments. And also, the flickering problem in the same levels is more clear in the lava section you mentioned. So it's good that you posted.

[Lorddamien]

lorddamien of course i read your post, problem is, i don't know the game, haven't played it AT ALL, so saying yeah it's after you defeat bla blah and bla doesnt help me... i need to know how much time i have to spend (in the japanese version without jap knowledge!!) to get there... i don't have any cheat devices to get there either...

Oh you haven't played it before. Well it's a bit hard to tell since DQ6 doesn't keep track of hours played but If I had to guess I'd say anywhere from 5-8 hours into the game if you follow a walkthrough. For the Japanese version Ian Kelly's walkthrough on Gamefaqs is your best bet.

Sorry I can't be more precise but it's been a while since I played the beginning of the game. It is fairly early on though.

[hydr0x]

5-8h is far too much for a bug test, sorry

you should find someone who was already finished the game on the real snes, a lot of people have, there must be someone out there :p

[jdratlif]

Some bugs I've noticed under Linux zsnes...

zsnes linux 10/24
compiled under gentoo
zlib 1.2.1, libpng 1.2.7, SDL 1.2.7

P4 2.0 GHz 1 GB RAM
nVidia GeForce2 MX 64 MB
Intel Corp. 82801BA/BAM AC'97 Audio (rev 05)
2.6.9 kernel
ALSA with OSS emulation

If you switch stereo sound off during a game, it crashes.
(segfault - SDL parachute deployed)

----------------------------------------------------------

Sound is HORRIBLE under Linux. I don't know if it's my settings, or the drivers or what. What I do know is that sound in Windows is good. (I know, this is vague -- Sorry)

I can't explain just what's wrong with it. But if someone could play Super Mario World (just 5 minutes into the game) on both Linux and Windows, you should notice the same things I do. It just doesn't sound right under Linux.

Here is what I have enabled.

No Stereo Sound (stereo makes it sound worse)
22050 sample rate (this seems to be best -- I've tried others, but it's usually worse)
Sound Buffering
Gaussian Interpolation

I don't know what my optimal sound rate is. I've heard about the card providing one thing and then the OS needing to change it if it's different, which can be bad for some reason. Anyone know how I can determine what rate my card wants to sample at?

I don't know what all those interpolation and low-pass settings are. I've played with them, but generally to no avail. Changing almost any sound setting mid-game is likely to cause a crash.

--------------------------------------------------------

Enabling an OGL video mode when you don't have the GLX extention loaded will crash ZSNES.

[illegal eagle]

First of all, entering Norfair confimed my guess about the moving background being the cause. What's more interesting is the heat shimmer makes the bottom line of the map scroll as you are walking as if it is part of the play field instead of the status. Check out the screenshot or the savestate , which should show you.

Save state, Screenshot

Seems like the HDMA channel that sets the horizontal BG scroll value starts too early.
This bug will probably vanish when the timing gets better... which could take some time.

[Lorddamien]

5-8h is far too much for a bug test, sorry

you should find someone who was already finished the game on the real snes, a lot of people have, there must be someone out there :p

I kinda figured you'd think this takes too long. Anything over 15 minutes is probably too long unless you intend on doing the whole game anyway. No biggie.

[jdratlif]

zsnes linux bug
WIP 10/24

zsnes will not start a rom passed on the command line.

e.g.

$ zsnes mario.smc

bings up the GUI, ignoring the fact you passed the ROM.

I noticed this at http://bugs.gentoo.org/show_bug.cgi?id=69196 and I get the same result. He says he submitted it upstream, but I don't see anything on sf bugtracker or in the forums when I do a search.

[funkyass]

what happens if you pass an argument before the rom?

This is a bug in libc IIRC.

[jdratlif]

what happens if you pass an argument before the rom?

This is a bug in libc IIRC.

No change if I do something like
$ zsnes -z /mnt/e/ROMs/Super\ Nintendo/Super\ Mario\ World\ \(U\)\ \[\!\].zip

I'm using glibc-2.3.4.20040808

[Nach]

It is a bug in libc. 2.1 and possibly 2.2 work, 2.3 is definitly broken.

[FistOfFury]

All games
Type of bug: Netplay desync bug
ZSNES Version that you tested it on(port): ZSNESW 10/24 WIP
Your OS, and any other info you can get on your system:
Windows98SE
512 MB SDRAM (pc133)
32MB TNT2 Riva M64
Pentium 4 @ 1.6ghz
Cable modem
AC'97 on-board audio

[jdratlif]

It is a bug in libc. 2.1 and possibly 2.2 work, 2.3 is definitly broken.

Question. If this is a bug in glibc, why can I change the zsnes source using the patch found here and get it to work?

Or more importantly, even if it is glibc's fault, why not apply this patch (at least in the interim)?

[Nach]

It is a bug in libc. 2.1 and possibly 2.2 work, 2.3 is definitly broken.

Question. If this is a bug in glibc, why can I change the zsnes source using the patch found here and get it to work?

Or more importantly, even if it is glibc's fault, why not apply this patch (at least in the interim)?

Instead of asking questions that you already know the answer to, why not just point out that you know of a work around?

[jdratlif]

It is a bug in libc. 2.1 and possibly 2.2 work, 2.3 is definitly broken.

Question. If this is a bug in glibc, why can I change the zsnes source using the patch found here and get it to work?

Or more importantly, even if it is glibc's fault, why not apply this patch (at least in the interim)?

Instead of asking questions that you already know the answer to, why not just point out that you know of a work around?

I don't know the answer to this. I am asking a question about it. I realize now my response sounded terse. Sorry. That wasn't intentional.

Here is what I know. You told me it is a bug in glibc. This may or may not be contradicted by the fact there is an apparent (though I didn't test beyond a single game, or use any other cmd line opts) patch to zsnes which may fix this. This was sent to some list called zsnes-devel which I assume is official. It is part of the zsnes sf project, it looks. I have never heard of it though.

In my original question, I posted the link to the bug with that patch and talked about upstream submission. I realize now this didn't imply the existence of a patch as I intended it to. Nor did I test the patch originally. I only thought about doing this after I was told it is a glibc bug.

Apologies if my response seemed rude. It really intended to be a question, not a snide or derisive comment which I do see now that it appeared to be.

[Nach]

I don't know the answer to this.

I said it was glibc as it worked in the stable versions of glibc. If someone makes a workaround which changes the source, it can work, and there is still a problem with glibc.

This may or may not be contradicted by the fact there is an apparent (though I didn't test beyond a single game, or use any other cmd line opts) patch to zsnes which may fix this.

As soon as I saw it, I tried it and tested it. It still works for me, but then again it always did since I'm on Debian and they don't use any new packages unless thoroughly tested. Since I see no harm and it works around bugs supposedly, I commited it immediatly. In the future, just mention there is a patch somewhere and the results of your tests.

This was sent to some list called zsnes-devel which I assume is official. It is part of the zsnes sf project, it looks. I have never heard of it though.

First I've heard of it as well. Who are these people? Howcome I've never seen them in the IRC channel or on the forum?
My guess is ZSNES has stuff on SF just like all other projects, and people who are used to doing things the SF way use that list.

[jdratlif]

I said it was glibc as it worked in the stable versions of glibc. If someone makes a workaround which changes the source, it can work, and there is still a problem with glibc.

Could you help me along the thought process for stating that it is a glibc bug? I don't understand how you have arrived at that conclusion.

Is there a possibility the code was always wrong and it just happened to work in glibc 2.1, e.g. the bug was in old glibc, not new glibc. I have no evidence to support this your realize. Just playing devil's advocate.

As soon as I saw it, I tried it and tested it. It still works for me, but then again it always did since I'm on Debian and they don't use any new packages unless thoroughly tested. Since I see no harm and it works around bugs supposedly, I commited it immediatly. In the future, just mention there is a patch somewhere and the results of your tests.

Sorry. Will do that in the future. I had incorrectly assumed you knew of the patch.

First I've heard of it as well. Who are these people? Howcome I've never seen them in the IRC channel or on the forum?
My guess is ZSNES has stuff on SF just like all other projects, and people who are used to doing things the SF way use that list.

Another bad assumption on my part it would seem.

I wonder who set these up. Maybe in the pre-forum days by Demo or pagefault? Maybe it was just after the gpl adoption.

Maybe we should encourage these people to abandon these lists for the forums. I hate mailing lists though, so I'm a bit biased. Also hate to think there are multiple points of discussion for problems in zsnes. I like this system as it feels centralized and well monitored by the devs (especially you Nach).

[Nach]

I said it was glibc as it worked in the stable versions of glibc. If someone makes a workaround which changes the source, it can work, and there is still a problem with glibc.

Could you help me along the thought process for stating that it is a glibc bug? I don't understand how you have arrived at that conclusion.

Is there a possibility the code was always wrong and it just happened to work in glibc 2.1, e.g. the bug was in old glibc, not new glibc. I have no evidence to support this your realize. Just playing devil's advocate.

Yes, maybe the new behavior is correct.
Here's what I know.

There's this thing many projects have for any version with an odd number after the first decimal point being unstable. Since the 2.3 line started this problem you could question, is it stable?

My next piece of evidence is that the Debian project doesn't use packages that they find unstable. Debian has a few branches being worked on called stable, unstable and testing. I personally use unstable because I like the cutting edge stuff that's in there. Debian unstable no longer has any glibc past the 2.2 line because they found it too unstable for Debian unstable, gee I wonder why.

3rd, after I first heard of the bug, I searched some GNU websites, and saw several complaints about getopt() in recent versions.

4th talking to the other developers in #zsnes they say it's a problem with getopt().

Maybe I'm wrong, but from the evidence I've gathered, glibc has a problem.

First I've heard of it as well. Who are these people? Howcome I've never seen them in the IRC channel or on the forum?
My guess is ZSNES has stuff on SF just like all other projects, and people who are used to doing things the SF way use that list.

Another bad assumption on my part it would seem.

I wonder who set these up. Maybe in the pre-forum days by Demo or pagefault? Maybe it was just after the gpl adoption.

teuf who setup the SF stuff for zsKnight probably just checked off everything. We had a forum prior to going open source.

Maybe we should encourage these people to abandon these lists for the forums. I hate mailing lists though, so I'm a bit biased. Also hate to think there are multiple points of discussion for problems in zsnes. I like this system as it feels centralized and well monitored by the devs (especially you Nach).

I prefer the forum to mailing lists as well.
Looking at the mailing list, doesn't look like it's really used.

My monitering is that if there's only a few new posts in the ZSNES sections I'll have a look. If a thread starts to go nuts, I usually don't bother anymore. If I was away for a while and there's a load of new posts, I'll only look at threads that have a title that seems worthwhile.

Also, despite me hearing about bugs, unforunetly a lot of them are out of the scope of what I work on.

Sorry to be the only somewhat usually active dev around but can't do much to help

[Overload]

IIRC, you used to be able to subscribe to the mailing list from the ZSNES home page. I was on the mailing list up to about a year ago.

http://sourceforge.net/mailarchive/mess ... id=1680487

[BlackJack]

Game Name: Super Mario All-Stars (E) [!]
Happens also with: Super Mario All-Stars + Super Mario World (E)[!]
and with: Super Mario World (E) (V1.1) [!].zip

Type of bug:Graphic/Scaling error

ZSNES Version that I tested it on(port): 1.36 CVS 10/24 Windows

My OS and graphic card: Windows XP SP2, ATI Radeon 9600XT (Catalyst 4.10 drivers)

Description of the bug: Note the fact that this bug only happens with the Europe version of these games, and NOT with the US one (Japan version not tested).

There seems to be a scaling/display error with these games, that starts at the beginning of the game. For whatever reason, you can see more graphics at the top and at the bottom of the screen than you get in any other game (or in the US version of this game). For example, you can see more sky and more ground.
To make a further test, try to use any resolution that keeps the ratio setting while beeing in a window (the bug appears also with the other settings, but the R proves there is a glitch). When you are in the game, hit escape to get the GUI of ZSNESw to appear: the scaling changes (and gets back to normal).
Last note: if you try the Europe version of the game, then the US version just after, ZsnesW will reduce the draw surface before launching the game (read: the scaling will be corrected).
Apparently, the bugs makes the emulator show more sprites than the game originally allows.

Here are 2 screenshots:
(the first one is from the US version, the 2nd one is from the Europe version)



Notice how you can see much more ground in the Europe version.

NSRT output:

---------------------Internal ROM Info----------------------
File: Super Mario All-Stars (E) [!].smc
Name: SUPER MARIO ALL_STARS Company: Nintendo
Header: None Bank: LoROM
Interleaved: No SRAM: 64 Kb
Type: Normal + Batt ROM: 16 Mb
Country: Euro/Asia/Oceania Video: PAL
ROM Speed: 200ns (SlowROM) Version: 1.0
Checksum: Good 0xA9A9 CRC32: 925FFA69
--------------------------Database--------------------------
Name: Super Mario All-Stars
Country: Europe Version: 1.0
Port 1: Gamepad Port 2: Gamepad



-------------------------------------------------------------------------------------
I got another possible bug (not related with the one I just described) : when I launch ZsnesW (and even when no game is loaded), the CPU usage jumps from 0% to 50% -- yep, it takes half of the CPU resources). Since I have a P4 2.8, 1 Gig of RAM and that all my drivers are up-to-day I highly doubt it comes from my computer.
-------------------------------------------------------------------------------------
And, last (but not least) bug: ZsnesW doesn't accept paths such as .\SAVE for savegames directory (the same goes for the GAME directory).

[Noxious Ninja]

I got another possible bug (not related with the one I just described) : when I launch ZsnesW (and even when no game is loaded), the CPU usage jumps from 0% to 50% -- yep, it takes half of the CPU resources). Since I have a P4 2.8, 1 Gig of RAM and that all my drivers are up-to-day I highly doubt it comes from my computer.

That is a known bug in ZSNES.

[BlackJack]

That is a known bug in ZSNES.

Thanks for letting me know; I only did searches through the forum about the main bug I describe, but not about the 2 others (there were added as bonus ).