Progress towards next release.

[Kilo11]

This is not a thread asking when it will come out, what I am wondering is what you guys are working on and what is to come as far as the next official release for ZSNES. Just asking.

[Palin]

As far as I know, they're pretty much rewriting the ZSNES core and doing a code audit to get rid of all the trash that's been piling up over the last several years. I think their goal is to remove the need to use timing hacks and game-specific fixes. Aside from that, from what I've read, they're rewriting some of the x86 bits in C++ and implementing some new features like the video export.

Someone can correct me if I'm wrong, but I think they've said that they want to rewrite netcode from scratch as well?

[creaothceann]

C afaik, not C++.

[Nihad]

As far as I know, they're pretty much rewriting the ZSNES core and doing a code audit to get rid of all the trash that's been piling up over the last several years.

This sounds to me like ZSNES has really got slower and slower during the last couple of years. And to be honest, that is the impresson I've got while using it during that time (maybe I'm wrong).


I would like to know, is the outcome of that code rewriting going to be faster code or slower code? Since I mostly "install" ZSNES on vintage PCs (P1s-P2s), I really appreciate any speed optimisations.

[Agozer]

You are not going to get full speed with 16-bit video modes on a Pentium. Pentium II might be another matter, but still on the fringe. Certain users should start to get comfortable with the fact that ZSNES will never be as fast as it used to be. Furthermore, there is an even larger ssytem requirements gap between the Windows and the DOS port.

Granted, the new core pagefault has been working on for a good while now will be a lot better than the current one.

[Deathlike2]

This is not a thread asking when it will come out, what I am wondering is what you guys are working on and what is to come as far as the next official release for ZSNES. Just asking.

A next official release requires that the core randomness dies... pagefault believes he has isolated the location in the code, but at the moment it is not clear what/where exactly the problem lies.

As far as I know, they're pretty much rewriting the ZSNES core and doing a code audit to get rid of all the trash that's been piling up over the last several years. I think their goal is to remove the need to use timing hacks and game-specific fixes. Aside from that, from what I've read, they're rewriting some of the x86 bits in C++ and implementing some new features like the video export.

There is behind the scenes porting some the ASM to C... to rid of the older code (that shouldn't be in ASM). The code being ported is not emulation related.

Someone can correct me if I'm wrong, but I think they've said that they want to rewrite netcode from scratch as well?

Yes, but the core randomness must be removed first. If you've noticed any of the netplay threads, there has been a lot of inconsistancies in netplay (like Player 1 winning on his screen whereas Player 2 is winning in his screen). The core randomness is responsible for that. Until that is resolved, don't even think about it.

This sounds to me like ZSNES has really got slower and slower during the last couple of years. And to be honest, that is the impresson I've got while using it during that time (maybe I'm wrong).

Not really, it's the non-emulation parts being affected. However, improving emulation (accuracy) in the end will slow down the emulater further. It is the way things are.

I would like to know, is the outcome of that code rewriting going to be faster code or slower code? Since I mostly "install" ZSNES on vintage PCs (P1s-P2s), I really appreciate any speed optimisations.

Core rewrite, probably slower. Internal ZSNES code rewrite, probably slower for non-emulation specific stuff.

Zget is the Windows solution for getting more speed (compiler optimizations) at the expense of taking a really really long time to compile ZSNES.

[Nach]

Internal ZSNES code rewrite, probably slower for non-emulation specific stuff.

Probably faster. We're replacing brain damaged code with smaller solutions. And stuff like the GUI load menu is going to be switched from bubble sorting to quick sorting.