What do you want from ZSNES (alternate thread)

[pagefault]

I think it's quite obvious what should be worked on. Look at the massive amount of bugs we all went through the trouble to find and verify to add to that bug tracker awhile back. It may be a good idea we don't shove them under the carpet and forget about them and start knocking some of them down?

I don't want to see 'games' fixed. I want to see EMULATION fixed. ZSNES is an SNES emulator last time I looked.

I want to see 65c816 code written for ZSNES actually work on the SNES!

I want to see sprite priority bugs fixed.

I want to see VRAM writes ONLY allowed during vblank or forced blank.

I want to see improved SPC700 communication timings.

I want to see all the research that's been done in the dev forum lately to be put to good use!

Some of these bugs have been in ZSNES for years and years.

In closing.. I think it's obvious that features should take a back seat. ZSNES reminds me of a microsoft product lately with a 'Let's forget about the bugs and just make more features' attitude.

Feel the same way, especially when you say

I don't want to see 'games' fixed. I want to see EMULATION fixed

But from what I gathered, Zsnes has probably reach a dead end as far as emulation accuracy goes. Not sure if it's caused by the fact that there's no one that have the skills or desire to make a massive rewrite of the core...or simply because rewritting the core timing engine is pretty much impossible without making a completely new emu.

What I see right now is that Zsnes is going in circles:
New version fixes game A but break game B and C... Game B and C used to work in wip2004x...Spend some time trying what caused the game to "break"...Now B and C work but A and D don't...and the cycle or rather the 'circle' goes on.
So basically, the devs are trying very hard to come up with a build of Zsnes that "fixes" games that used to work at one point or another in Zsnes history, while keeping the games that get "broke" to a minimum.

Problem with this, is that's it's not only extremely tedious, but it never answer the main issues anyway...



I found the whole: Game "fix"/"broken" fishy...It does make it sound like you have a "game-centric" emulator, has opposed to "hardware-centric" one to use someone else's words (Mkendora?)


In any cases, I hope the great reasearch done by anomie, byuusan and others are implemented in a emulator one day...even if it's not in zsnes.

First of all, let me make something clear to you. This is how emulation is, one fix ultimately has the chance of breaking something else. You can ask any emulator author this and he will tell you the same thing. That's just the way it is. It can be from either human error, bad research, bad implementation of new research or any combination of these. This isn't always a black and white solution so a fix may not be the best fix but it's the best fix we can do at this point without knowing anything else. When we find out a game has broke because of some fix then we learn from this and find out why. This is how accuracy is increased, because we learn from our mistakes. Also many valid fixes from research may expose another bug somewhere else in a totally unrelated section of code, we have no control over this and can only fix it when we find out it doesn't work.

Yes some information can be obtained by running tests on the real hardware but this is hardly an answer to everything since it doesn't test real world situations. Thats why we fix games, because they are what people are using, so when a game doesn't work we go fix it. As we fix the games we learn new things about the SNES and end up fixing more games in the process. Also the SNES isn't exactly a simple piece of hardware. SNES emulation is extremely sensitive to minor changes so one wrong value somewhere in the emulation code can break a lot of things. Also you mention that WIP's break games. Well thats why they are called WIP's (Work In Progress) and really ZSNES is a huge work in progress all the time. We don't guarantee ZSNES will work for you, and you use it at your own risk.

[clovis15]

I think it's quite obvious what should be worked on. Look at the massive amount of bugs we all went through the trouble to find and verify to add to that bug tracker awhile back. It may be a good idea we don't shove them under the carpet and forget about them and start knocking some of them down?

I don't want to see 'games' fixed. I want to see EMULATION fixed. ZSNES is an SNES emulator last time I looked.

I want to see 65c816 code written for ZSNES actually work on the SNES!

I want to see sprite priority bugs fixed.

I want to see VRAM writes ONLY allowed during vblank or forced blank.

I want to see improved SPC700 communication timings.

I want to see all the research that's been done in the dev forum lately to be put to good use!

Some of these bugs have been in ZSNES for years and years.

In closing.. I think it's obvious that features should take a back seat. ZSNES reminds me of a microsoft product lately with a 'Let's forget about the bugs and just make more features' attitude.

Feel the same way, especially when you say

I don't want to see 'games' fixed. I want to see EMULATION fixed

But from what I gathered, Zsnes has probably reach a dead end as far as emulation accuracy goes. Not sure if it's caused by the fact that there's no one that have the skills or desire to make a massive rewrite of the core...or simply because rewritting the core timing engine is pretty much impossible without making a completely new emu.

What I see right now is that Zsnes is going in circles:
New version fixes game A but break game B and C... Game B and C used to work in wip2004x...Spend some time trying what caused the game to "break"...Now B and C work but A and D don't...and the cycle or rather the 'circle' goes on.
So basically, the devs are trying very hard to come up with a build of Zsnes that "fixes" games that used to work at one point or another in Zsnes history, while keeping the games that get "broke" to a minimum.

Problem with this, is that's it's not only extremely tedious, but it never answer the main issues anyway...



I found the whole: Game "fix"/"broken" fishy...It does make it sound like you have a "game-centric" emulator, has opposed to "hardware-centric" one to use someone else's words (Mkendora?)


In any cases, I hope the great reasearch done by anomie, byuusan and others are implemented in a emulator one day...even if it's not in zsnes.

First of all, let me make something clear to you. This is how emulation is, one fix ultimately has the chance of breaking something else. You can ask any emulator author this and he will tell you the same thing. That's just the way it is. It can be from either human error, bad research, bad implementation of new research or any combination of these. This isn't always a black and white solution so a fix may not be the best fix but it's the best fix we can do at this point without knowing anything else. When we find out a game has broke because of some fix then we learn from this and find out why. This is how accuracy is increased, because we learn from our mistakes. Also many valid fixes from research may expose another bug somewhere else in a totally unrelated section of code, we have no control over this and can only fix it when we find out it doesn't work.

Yes some information can be obtained by running tests on the real hardware but this is hardly an answer to everything since it doesn't test real world situations. Thats why we fix games, because they are what people are using, so when a game doesn't work we go fix it. As we fix the games we learn new things about the SNES and end up fixing more games in the process. Also the SNES isn't exactly a simple piece of hardware. SNES emulation is extremely sensitive to minor changes so one wrong value somewhere in the emulation code can break a lot of things. Also you mention that WIP's break games. Well thats why they are called WIP's (Work In Progress) and really ZSNES is a huge work in progress all the time. We don't guarantee ZSNES will work for you, and you use it at your own risk.

Watching you tell off the 'Only I know the Truth" jackass made me smile.

[Dmog]

I think it's quite obvious what should be worked on. Look at the massive amount of bugs we all went through the trouble to find and verify to add to that bug tracker awhile back. It may be a good idea we don't shove them under the carpet and forget about them and start knocking some of them down?

I don't want to see 'games' fixed. I want to see EMULATION fixed. ZSNES is an SNES emulator last time I looked.

I want to see 65c816 code written for ZSNES actually work on the SNES!

I want to see sprite priority bugs fixed.

I want to see VRAM writes ONLY allowed during vblank or forced blank.

I want to see improved SPC700 communication timings.

I want to see all the research that's been done in the dev forum lately to be put to good use!

Some of these bugs have been in ZSNES for years and years.

In closing.. I think it's obvious that features should take a back seat. ZSNES reminds me of a microsoft product lately with a 'Let's forget about the bugs and just make more features' attitude.

Feel the same way, especially when you say

I don't want to see 'games' fixed. I want to see EMULATION fixed

But from what I gathered, Zsnes has probably reach a dead end as far as emulation accuracy goes. Not sure if it's caused by the fact that there's no one that have the skills or desire to make a massive rewrite of the core...or simply because rewritting the core timing engine is pretty much impossible without making a completely new emu.

What I see right now is that Zsnes is going in circles:
New version fixes game A but break game B and C... Game B and C used to work in wip2004x...Spend some time trying what caused the game to "break"...Now B and C work but A and D don't...and the cycle or rather the 'circle' goes on.
So basically, the devs are trying very hard to come up with a build of Zsnes that "fixes" games that used to work at one point or another in Zsnes history, while keeping the games that get "broke" to a minimum.

Problem with this, is that's it's not only extremely tedious, but it never answer the main issues anyway...



I found the whole: Game "fix"/"broken" fishy...It does make it sound like you have a "game-centric" emulator, has opposed to "hardware-centric" one to use someone else's words (Mkendora?)


In any cases, I hope the great reasearch done by anomie, byuusan and others are implemented in a emulator one day...even if it's not in zsnes.

First of all, let me make something clear to you. This is how emulation is, one fix ultimately has the chance of breaking something else. You can ask any emulator author this and he will tell you the same thing. That's just the way it is. It can be from either human error, bad research, bad implementation of new research or any combination of these. This isn't always a black and white solution so a fix may not be the best fix but it's the best fix we can do at this point without knowing anything else. When we find out a game has broke because of some fix then we learn from this and find out why. This is how accuracy is increased, because we learn from our mistakes. Also many valid fixes from research may expose another bug somewhere else in a totally unrelated section of code, we have no control over this and can only fix it when we find out it doesn't work.

Yes some information can be obtained by running tests on the real hardware but this is hardly an answer to everything since it doesn't test real world situations. Thats why we fix games, because they are what people are using, so when a game doesn't work we go fix it. As we fix the games we learn new things about the SNES and end up fixing more games in the process. Also the SNES isn't exactly a simple piece of hardware. SNES emulation is extremely sensitive to minor changes so one wrong value somewhere in the emulation code can break a lot of things. Also you mention that WIP's break games. Well thats why they are called WIP's (Work In Progress) and really ZSNES is a huge work in progress all the time. We don't guarantee ZSNES will work for you, and you use it at your own risk.

Watching you tell off the 'Only I know the Truth" jackass made me smile.

Was I scolded or what! Boy, he showed me! lol Whatever. I don't recall "truth" being the reason of argument here. Different views that's all.

[Dmog]

First of all, let me make something clear to you. This is how emulation is, one fix ultimately has the chance of breaking something else. You can ask any emulator author this and he will tell you the same thing. That's just the way it is. It can be from either human error, bad research, bad implementation of new research or any combination of these. This isn't always a black and white solution so a fix may not be the best fix but it's the best fix we can do at this point without knowing anything else. When we find out a game has broke because of some fix then we learn from this and find out why. This is how accuracy is increased, because we learn from our mistakes. Also many valid fixes from research may expose another bug somewhere else in a totally unrelated section of code, we have no control over this and can only fix it when we find out it doesn't work.

Yes some information can be obtained by running tests on the real hardware but this is hardly an answer to everything since it doesn't test real world situations. Thats why we fix games, because they are what people are using, so when a game doesn't work we go fix it. As we fix the games we learn new things about the SNES and end up fixing more games in the process. Also the SNES isn't exactly a simple piece of hardware. SNES emulation is extremely sensitive to minor changes so one wrong value somewhere in the emulation code can break a lot of things. Also you mention that WIP's break games. Well thats why they are called WIP's (Work In Progress) and really ZSNES is a huge work in progress all the time. We don't guarantee ZSNES will work for you, and you use it at your own risk.

I mentionned WIP as an example. It could also have been a "stable" version. For example, a game that got "broke" in 1.36 that used to work in 1.0 or whatever. The "broke,fix,broke,fix,broke,fix" thing has started well before the WIPs afaik.

And unless someone planted a virus in Zsnes, I've never considered there's any risk associated with it


Now about the rest. Of course, you being a coder, you will alway have the upper hand, "I'm the coder here, so I think I know what I'm talking about". Now I'm not gonna dispute the fact that you're a coder and I'm not.

Yet, emulation coder or not, what I see is that Zsnes is at it's core "game-centric". Nach has come forth and state his position pretty clearly, he believes emulation is first and foremost about the games(or softwares). I disagree with him but fine... You on the other hand haven't really commented on "your position". But I have a vague idea that on a scale of 1 to 10...or rather: on a scale of Nach to MKendora, you're closer to Nach.

Thing is, if you see the Snes as a piece of -hardware- as opposed to some vague machine that play games, you'll emulate/simulate every basic component of that hardware...and logically, games should run without hiccups. And only 'after' you've think you've completed your emulator will you test the games. (ok that's idealizing things a bit).
But if you see the snes as some vague machinery that plays games, you'll rush to make the game playables from the early beginning, and inevitably, there's loads and loads of crap that's going to pop out... Craps that would have not appeared if you had a better "plan" for your emulator and if you were more "hardware-centric" to begin with.



Anyway, you mentionned research... Well speaking of research, would you mind then telling us what are the odds that the research that's been done in the development forum gets implemented in zsnes (I left my brains in the womb)? If it's not possible, it's not possible. But at least it's going to be clear.

[Kagerato]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

[Oblivion]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

[Tallgeese]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

[Dmog]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

Whatever. That's your opinion. I'll continue to believe that Zsnes has become archaic, due to the way it was originally coded.
And I'll continue to believe it has reached a dead end. All the stuff that Nightcrawler mentionned will probably never see the light of the day in Z precisely because there's some important part of the program you really cannot change.Other than small "fixes" here and there, you're not gonna see any major changes. We have more knowledge about the workings of the Snes than we used to, but we can't implement such knowledge.


Good arguments though.

[Clements]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

Whatever. That's your opinion. I'll continue to believe that Zsnes has become archaic, due to the way it was originally coded.
And I'll continue to believe it has reached a dead end. All the stuff that Nightcrawler mentionned will probably never see the light of the day in Z precisely because you really can't add any significant change to the whole thing.

So large chunks of ZSNES are being ported to C for shits and giggles?

[Dmog]

That last post, Dmog, is the biggest heap of garbage I've read in a while. Well done.

Whatever. That's your opinion. I'll continue to believe that Zsnes has become archaic, due to the way it was originally coded.
And I'll continue to believe it has reached a dead end. All the stuff that Nightcrawler mentionned will probably never see the light of the day in Z precisely because you really can't add any significant change to the whole thing.

So large chunks of ZSNES are being ported to C for shits and giggles?

I've read the GUI was being ported to C.. Would be pretty sweet for those Mac users (and every non x86 based machine) if every last remains of ASM was ported to C though.

[grinvader]

So large chunks of ZSNES are being ported to C for shits and giggles?

I sure shat and giggled a frigging LOT to port the few things I did.

BTW, rewind + state save/load code is now ported to C and hopefully fully functionnal. Neither PF nor I could make it crash.
Booze and drunkiness is my reward. omgcheers2u.

[Tallgeese]

Why don't we ask dear grinvader, who reportedly ported some save state code to another programming language... At least according to Nach.

EDIT: LOL. Grin beat me to it by like three seconds.