Language…
6 users online: cletus_deletus,  Donut, masl, playagmes169, Skewer, toady - Guests: 227 - Bots: 317
Users: 64,795 (2,375 active)
Latest user: mathew

.

Link Thread Closed
I think a ZSNES disabling patch is only appropriate when the hack is actually incompatible with it or at least has major issues when played on ZSNES. Applying such a patch to a hack that is compatible on ZSNES simply because you want to force its demise sounds rather unnecessary and asinine.


I'm completely against preventing players from using ZSNES unless if the hack/game itself doesn't work (ie crashes) with ZSNES.

ZSNES indeed has many and many emulating issues that makes certain advanced features don't work properly. Still it is not an excuse to make it unplayable with it if it's still 99% playable.

Naturally, if ZSNES don't ever get any update in next years, ZSNES will start disappearing due of incompatibilities with future operating systems and hardware. For example I can't run ZSNES on full screen with my laptop and a couple of people aren't able to open ZSNES at all because of the CPU architecture, GPU compatibility, etc. Microsoft probably will get rid of DirectDraw soon so I wouldn't get surprised if ZSNES stop working totally on future Windows versions.

Soon or later people will know about ZSNES limitations and will naturally switch to Snes9x, which in my opinion is the best emulator right now in terms of performance x user interface x compatibility. And we mustn't force the switch by making hacks simply refuse ZSNES or otherwise the users will end switching your hack instead...!

For who want to know, here is the list of issues I found with ZSNES so far:

  • Emulating issues:
    • Sound issues:
      • Poor pitch emulation, many songs and sound effects ends getting a bit distorted, for example Mario's spin jump.
      • Poor pitch modulation emulation
      • Inaccurate echo emulation, where most songs ends sounding with a stronger echo.
      • No echo buffer support, the guilty of previous Addmusic incompatibilities.
      • The sound core runs desynchronized from SNES CPU, which makes impossible to make more timing precise operations, like faster data transfer which includes sample streaming (high quality music and sfx voices)
    • Visual issues:
      • Poor windowing (HDMA) support (often works glitchly and doesn't support some window modes).
      • Poor offset-per-tile support (mode 2, 4 and 6).
      • No hi-res support (which allows 512px width screen or a more "true" transparency).
      • No intercalate support.
      • No mode 5 and 6 support (known as "high resolution mode", since it can emulate a 512x448 screen).
    • (SNES) CPU issues:
      • Poor decimal mode support (which allows to identify ZSNES with a few lines of code using this issue)
      • No open-bus support
      • Poor or no timing at all with other chips, like the sound system I said earlier
      • Allows accessing f/v/h-blank only registers at any time, including VRAM, CGRAM, etc.
      • Instant hardware multiplication and division.
    • SA-1 issues:
      • Lower CPU speed (ZSNES makes SA-1 run around 5 MHz, while it should be 10.74 MHz)
      • Neither SNES or SA-1 can execute code on I-RAM or BW-RAM.
      • Unstable emulation (any SA-1 game can crash at any time, including it can wipe all your saved progress or ZSNES can even quit suddenly).
      • Very poor character conversion DMA support (as far I know, ZSNES only added a hack to emulate the one used in SMRPG, the rest of character conversion DMA modes won't work and will either make the game look glitchly or will freeze the game instead.
      • Doesn't support SA-1 NMI and a few SA-1 IRQs.
      • Makes some SNES registers stop working when SA-1 is present (for example h-blank register).
      • SA-1 can access everything, including stuff that not even SNES is supposed to access (any time VRAM access!)
      • No 8MB support (that includes any game actually).
    • Other:
      • Rewinds can desync your current recording movie.
      • Rewinds also kills echo effects.
  • OS issues:
    • Often kills other applications that has any audio playing, like Winamp
    • Uses obsolete drawing methods, making some GPUs simply refuse ZSNES, specially full screen mode.
    • 99% written in pure x86 ASM, making impossible to port it for example to phones and it may stop working on future hardware and operating systems.

And much more issues that I don't know or I forgot. Feel free to complete this table if someone found more issues.
Originally posted by Vitor Vilela
      • Poor tile-per-offset support (mode 2, 4 and 6).

Do you mean the X position got shifted by 16 pixels for one frame when the screen moves? Unless it's not that it's actually more the fault of the newer GFX engine. ZSNES has got two of them and the older one is compatable with OPT-BGMs. Press 8 to see that.
Yeah, I know about that, still it should work normally without changing settings.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by VitorVilela
  • No hi-res support (which allows 512px width screen or a more "true" transparency).
  • No intercalate support.
  • No mode 5 and 6 support (known as "high resolution mode", since it can emulate a 512x448 screen).

these are incorrect; zsnes supports them. maybe not completely, but it definitely supports them to a considerable extent (probably up to s9x levels, except for pseudo-hires)

also, windowing is not that broken; just a bit wonky in terms of the edges of the window

one you should add is stuff related to color math; it acts weird with certain settings (see smwcp2 credits, the colored pencil section)

another you should add is slightly-off color display (if you have LM open on level 105 and have zsnes overlayed playing on 105, you can see the difference in the bg color)
If I ever release my hack I may add that warning screen despite not knowing of any incompatibilities. I do a lot of wacky crap and don't test it thoroughly on ZSNES; it's very possible something will break.
Originally posted by Kaijyuu
If I ever release my hack I may add that warning screen despite not knowing of any incompatibilities. I do a lot of wacky crap and don't test it thoroughly on ZSNES; it's very possible something will break.

That's kind of my feeling about it. I have no patience to test my hack in a crappy emulator, so I just go with a "buyer beware" setup. I probably won't ever add that warning screen, normally I just say that I don't support zsnes and won't fix any issues regarding it. I add a disclaimer in every readme I make, though.
Scratch that; I remembered at least one thing that doesn't work properly on ZSNES in my hack:

http://www.smwcentral.net/?p=viewthread&t=25093

Totally worth a warning screen. ;D
OK, I'm just a little unclear as to why exactly you think ZSNES should cease to be used. Do you think that it is outdated? Does it have the potential for many severe or gamebreaking issues when playing SMW hacks? Are a lot of hacks broken on ZSNES? Know that I do not object to your statement in any way.

I agree that ol' ZSNES does have a few down sides, such as lack of a frame speed control function for slowing down the game. (I know about the slowdown function, though)

If anything, I always thought the bane of SMW hacking with regards to emulator choice by players was how so many hacks contain custom music that breaks on accurate emulators. That, of course, is by no fault in any of the emulators, as it springs from mistakes on the part of the hack's creators, as far as I know. But anyways, I just wanted a better understanding.

Originally posted by WhatTheHack
That, of course, is by no fault in any of the emulators, as it springs from mistakes on the part of the hack's creators, as far as I know.

It's entirely ZSNES' fault for having horrible emulation.

Early addmusics like Carol's and Romi's exploited bugs in ZSNES' emulation which meant that the echo buffer overflowing (which breaks pretty obviously in accurate emulators) didn't break, which led to massive controversy when people found out.
ZSNES has been the emulator for a long while, but it's always been a fact that it's very inaccurate in many aspects to the original SNES "emulation". The new gripe is that some people have grown tired of making their hacks for it, since many people wanted to play hacks on the real hardware and a lot of stuff that worked for ZSNES did not work on a real SNES - at some point, any hack that used AddMusic would break on the real hardware.

We shouldn't force people to not use it in any way, but they still should be aware that hacks are not being made for ZSNES anymore, and for that reason, they may not work on it since it's not accurate to the real SNES, so things that are actually made for the original SNES are bond to not work perfectly on it. This is just the case for the SA-1 patch.

E: ninja'd.
It's easily the best thing I've done
So why the empty numb?
Even here on SMWC, people whine about hacks not functioning properly on ZSNES, and putting some kind of warning in the actual game itself should become common practice immediately.

It is not, and should not be, anyone's job to secure compatibility with an outdated emulator which barely even functions(both in terms of emulation and in breaking on certain modern hardware) and hasn't been touched on the development end in over eight years.
I've become very grumpy these last few years, and have been biting my tongue here in SMWC's forums quite a bit. I just want to let you all know that if ever I come off as harsh, I still care about you all. You guys are great.

(Avatar by http://reyleias.tumblr.com/, butchered by me)
Originally posted by WhatTheHack
OK, I'm just a little unclear as to why exactly you think ZSNES should cease to be used.

Originally it's because it causes people who create resources/tools to make them not work on real hardware. The canonical case is Addmusic, but another example was an old NPC patch that used the palette to decide which message to show, and tried to read from CGRAM during draw. Thesewere created and tested on only zsnes/snes9x 1.43, which had the same problems as zsnes. In fact, back then, almost all of the emulators did that poorly, and bsnes was still mostly unknown in our community (and, in fact, in general), and while the coders could look at the documentation and find out that the things they were doing was impossible, but I think that we are at a high enough level that we shouldn't have to care too much about, and instead our tools should explode on us to teach us a lesson, so it's not so much the coders' faults.

Eventually we found out that emulators had this compatibility, I believe when smkdan showed us all bsnes and realized that everything exploded and why. Sometime in here, blargg created a new spc engine that emulated music things correctly, and snes9x fixed the problem where it let you read CGRAM during draw and replaced their spc engine with blargg's, fixing most of the major emulation problems (these fixes were probably prompted by byuu's general dickishness, but as is probably not surprising to anyone, I'm ok with that).

So why does that mean we want people to stop using zsnes? While some people have other complaints, like the UI being generally shit *chough*HuFlungDu*cough*, the real problem is that I fixed addmusic in 2011, so we knew about this since at least 2010, and we've complained during that entire time, and zsnes hasn't gotten an update to fix it in the intervening 5 years. It's a dead emulator and an artifact of a bygone era.

The other interesting thing that's happened is we've gotten a lot better at SNES programming, and as we get better, we create more and more things the zsnes can't handle anymore, and that's also pretty cool. I actually find these days that my hacks don't work in zsnes totally by accident, just because zsnes is created specifically to play as many known games as it can, not to emulate a SNES.

It's actually very strange to me that the majority opinion has switched to this, given the response in 2011 when I released the updated addmusic. Not that I mind, I'm glad it's got to the point where it's cool to be accurate and people care about hardware compatibility. Times have really changed.
Originally posted by HuFlungDu
and snes9x fixed the problem where it let you read CGRAM during draw

No, it didn't, you're mixing up VRAM with CGRAM.
Invalid VRAM access is blocked in all major emulators, even ZSNES. However, some emus have a config option to unblock it, and guess which one sets it to 'allow' by default...
Invalid CGRAM access works in everything up to and including bsnes-compat. Only bsnes-accuracy rejects it.
In fact, we still have a few broken things in the sections.

Quote
like the UI being generally shit

I hate the ZSNES UI too. Kinda ironic.

It's an extremely polarizing thing... hate it or love it, but I've never seen anyone with any weaker opinion.

Quote
It's actually very strange to me that the majority opinion has switched to this

Three years ago, the emulator usage shares were 65/25/10%.
I believe it's time to hold that poll again. With ZMZ and all the ZSNES-is-outdated campaigns, the ZSNES usage share can no longer be that high.
<blm> zsnes users are the flatearthers of emulation
Originally posted by MercuryPenny

It's entirely ZSNES' fault for having horrible emulation.


OK, which emulator would you recommend I use instead? Again, I am not saying this out of argument.

FYI, the reason I keep disclaiming that I am not trying to argue or disagree is because it can difficult to tell the intention of what someone says through text alone.

Originally posted by WhatTheHack
OK, which emulator would you recommend I use instead?

ZMZ - ZSNES interface with the accurate emulation of other SNES emulators

Or if you don't like the ZSNES interface:
Snes9x
Higan (formely known as bsnes)

Originally posted by WhatTheHack
FYI, the reason I keep disclaiming that I am not trying to argue or disagree is because it can difficult to tell the intention of what someone says through text alone.

Very true...but I guess emoticons only kind of are a solution for that.


Originally posted by Alcaro
Quote
like the UI being generally shit

I hate the ZSNES UI too. Kinda ironic.

It's an extremely polarizing thing... hate it or love it, but I've never seen anyone with any weaker opinion.

That's one of the reasons why I didn't switch to Higan (bsnes) or Snes9X. I really like the UI ZSNES has, which is weird because I hated it a long time ago, but I actually think it fits the emulator (no, not in a bad way, like, it works alongside the emulator very well).

Also, I switched to ZMZ recently because I saw how badly ZSNES was compared to other emulators. I still consider it almost finished, but not quite, because of a few missing features (recorder not included, I really don't care about that thing).

Originally posted by Alcaro
Three years ago, the emulator usage shares were 65/25/10%.
I believe it's time to hold that poll again. With ZMZ and all the ZSNES-is-outdated campaigns, the ZSNES usage share can no longer be that high.

Yep. Might I suggest Straw Poll (the website), so that people who aren't in here still can vote? (...it does have a "no multi-voting" thing too)
Originally posted by Vissova
Could someone educate me on why ZSNES is looked down upon by so many users? Does it have an effect on your hack during development, or is it just buggy?
I've stuck with it since I began hacking and it's worked without many issues.


1. Its outdated and old emulator with much better alternatives(snes9x, higan-accuracy, bizhawk....) out there.

2. It doesn't do anything that any other snes emulator cant do(I think rewind was mentioned, but bizhawk can do that).

3. Its buggy with SA-1, with some HDMA effects(in my experience, and they do work correctly in snes9x, higan-accuracy and bizhawk), and it also handles slowdown/lag poorly, in comparison when theres many enemies/sprites on screen, zsnes tends to slowdown more than other emulators, sometimes there doesn't even need to be that many enemies.

4. And zsnes likes to crash rom rarely, but I've seen it do that for no reason(again, no problems with other emulators).
Originally posted by Alcaro
Originally posted by HuFlungDu
and snes9x fixed the problem where it let you read CGRAM during draw

No, it didn't, you're mixing up VRAM with CGRAM.

I'm not mixing up anything, I genuinely thought that they fixed the CGRAM access during draw, I can't think why they wouldn't. Is there more to it than I'm thinking? Seems odd that up to bsnes-compat would still let you do that.
Originally posted by HuFlungDu
Is there more to it than I'm thinking?

Accessing VRAM while the screen is active discards the write (not sure what happens during read, bsnes says zero).

Accessing CGRAM while the screen is active accesses the color currently being drawn.

This is impossible to emulate with a scanline-based renderer, and bsnes-acc is the only one that's not scanline-based (except some ancient emus that draw even larger things at once, but they're all dead or upgraded by now).

Unfortunately, according to byuu, there are a few games that rely on this quirk (while writing the correct index to $2121).

Since it's so hard to emulate correctly, and nobody likes broken games, only the unfortunate solution remains.
<blm> zsnes users are the flatearthers of emulation
To add my two cents. I would recommend only showing this message if you know for sure that the game has problems or won't play in ZSNES. But I'd let them continue and see for themselves anyway if they really wanted.

Anything else is just going to polarize people against you. And trust me, I know all about polarizing people:

> these fixes were probably prompted by byuu's general dickishness

Happy I could help :D

> I'm glad it's got to the point where it's cool to be accurate and people care about hardware compatibility. Times have really changed.

Indeed. I hadn't even realized this was the case. Probably has a lot to do with me not being around offending everyone all the time anymore.

> zsnes hasn't gotten an update to fix it in the intervening 5 years. It's a dead emulator and an artifact of a bygone era.

Yep, eight and a half years and counting since v1.51.

They keep saying they're working on v2.0, but from what I've read, it's a total rewrite, so it's really just misappropriating the name. And they're using blargg's SMP core, so it's still going to be a buggy mess. (blargg's DSP core is great; his SMP core is why Snes9X v1.53 has over 40+ APU timing hacks in it.)

> Invalid VRAM access is blocked in all major emulators, even ZSNES. However, some emus have a config option to unblock it, and guess which one sets it to 'allow' by default...

Is there really an option to block it? I never knew about that.

I sent them a patch to block it, and even made it have a grace period of a few scanlines on each end of Vblank to account for the generally poor CPU timing, but it was rejected.

(as was my variable-width UI font patch that would have let the game selection dialog actually show you the full titles of games. So you can kinda see why I decided to go it alone instead of working with them ...)

> Three years ago, the emulator usage shares were 65/25/10%. I believe it's time to hold that poll again. With ZMZ and all the ZSNES-is-outdated campaigns, the ZSNES usage share can no longer be that high.

I'm sure mine is even lower than before, since I went nuts with the UI and game folders and all.

I peaked around 100,000 official site downloads a release; which has dropped to around 10,000-20,000 as of late. Not having a new release in a year and a half as thrown off the counting, though.

> not sure what happens during read, bsnes says zero

That is what the real thing does, yes.

> Unfortunately, according to byuu, there are a few games that rely on this quirk

It was mainly a wrestling game's splash screen. It changed the background color a few lines into the frame. If you were to shunt all CGRAM writes to palette color 0, it would "work" for that title at least.

My implementation's far from timing perfect here, but it's at least better than nothing.

...

Also, since you guys seem to be working on SA-1 stuff now, I really should warn you ... all emulators have absolutely shitty SA-1 emulation, bsnes included.

It's an extremely difficult problem. Doing the SA-1's bus handler the right way would make even bsnes run probably five times slower than it does now. So obviously, I can't do that.

There's also a dozen features in that chip that no commercial games have ever used. So all of that code is untested.

If we ever get a flash cart capable of using the official SA-1, I suspect a lot of SA-1 homebrew won't work on it. So, be forewarned.
Link Thread Closed