Current Status FAQ

Deathlike2 · Post by **Deathlike2** » Mon Sep 03, 2007 2:38 am

Read this: http://zsnes.game-host.org/faq.txt

DancemasterGlenn · Post by **DancemasterGlenn** » Mon Sep 03, 2007 5:28 am

Interesting.

Not that it matters, but in my opinion take as much time as you all need. I'll still be waiting around for what will be the very excellent final product.

Not to re-start a war, but will the new gui look like the old (current) one? Because I really like it. Just curious.

creaothceann · Post by **creaothceann** » Mon Sep 03, 2007 7:37 am

Thanks for the update.

With a new core, I guess ZSNES won't be able to support old savestates? In that case you might think about relocating the save/reload position to the start of the frame, before any HDMA operations have taken place.

Would make the job of certain external tools easier.

Nightcrawler · Post by **Nightcrawler** » Tue Sep 04, 2007 2:49 pm

Sounds well enough to me. It's quit obvious such a large overhaul like the ones currently being undertaken takes a substantial amount of time. It's no surprise to me it's going to take quite awhile longer and for good reasons.

I would certainly hold it off as long as necessary to deliver the next generation of ZSNES in the best state possible. It's such a departure from the old versions, it's practically an entirely new product.

snkcube · Post by **snkcube** » Tue Sep 04, 2007 11:49 pm

Thanks for posting that up. It's good to take your time on something like this.

LiquidAcid · Post by **LiquidAcid** » Wed Sep 05, 2007 10:04 am

Audiere? Is this actually still maintained? I see some activity in the SVN but the last release is from february 2006. Seems a bit old to me.

Also Audiere features a full music playback engine. I don't think you're going to use that apart from the basic audio I/O functionality. Why don't you consider something like libao or portaudio (or OpenAL)?

And rethink your choice of Qt for the GUI. In my opinion a lighter GUI toolkit would fit zsnes better, or even no toolkit at all (I really like the current style of the GUI).

snkcube · Post by **snkcube** » Wed Sep 05, 2007 2:36 pm

No updates to SVN doesn't mean it's not being maintained. The developers could be doing this in private builds.

DataPath · Post by **DataPath** » Wed Sep 05, 2007 2:45 pm

LiquidAcid wrote:Why don't you consider something like libao or portaudio (or OpenAL)?

I think the devs are quite familiar with the different audio toolkits. There've been many discussions about them, and about the ways in which they all suck.

LiquidAcid wrote:And rethink your choice of Qt for the GUI. In my opinion a lighter GUI toolkit would fit zsnes better, or even no toolkit at all (I really like the current style of the GUI).

You give such thought-provoking suggestions and compelling reasoning that I don't see how they can do anything BUT go back to the classic zsnes gui.

funkyass · Post by **funkyass** » Wed Sep 05, 2007 3:28 pm

except the current GUI is several hundred lines of pure ASM.

byuu · Post by **byuu** » Wed Sep 05, 2007 10:50 pm

It'll be very interesting to see what happens when v2.0 is released.

ZSNES will have an entirely new UI (theming Qt only gets you so far), almost entirely new core emulation, many new/broken features, much higher system requirements (especially for SA-1/SuperFX) and much more accuracy. It will seem like an entirely new emulator, aside from the name. Too bad blargg isn't interested in emulating the S-PPU, or it could be renamed QuickSNES ;)

I'm guessing the people who love the old lowres raster UI and insanely low system requirements will stick with v1.51, or possibly even fork the project; and that most of the remaining SNES9x users will abandon ship to ZSNES v2.0.

With such a large cut in SNES9x' userbase and developers, I wonder if it'll survive. I also wonder if a forked ZSNES v1.51 could become more popular than the official v2.0+ project, since it's very clear the majority only care about playing games, sadly. Personally, I think brand loyalty, accuracy improvements and SNES9x converts combined will allow v2.0+ to remain the dominant emulator of choice.

Best of luck to all the devs working on v2.0!

Jipcy · Post by **Jipcy** » Thu Sep 06, 2007 2:22 am

Stick with the name you know and trust for all your emulation needs: ZSNES!

Post by **grinvader** » Sun Sep 09, 2007 12:59 pm

funkyass wrote:except the current GUI is several hundred lines of pure ASM.

Hundred ? haha oh wow

Code: Select all

$ wc -l ~/zsnes/src/gui/*.[ai]*
  3138 /home/grin/zsnes/src/gui/gui.asm
  1165 /home/grin/zsnes/src/gui/guicheat.inc
   193 /home/grin/zsnes/src/gui/guicombo.inc
  2800 /home/grin/zsnes/src/gui/guikeys.inc
   302 /home/grin/zsnes/src/gui/guimisc.inc
  3437 /home/grin/zsnes/src/gui/guimouse.inc
   829 /home/grin/zsnes/src/gui/guitools.inc
  5128 /home/grin/zsnes/src/gui/guiwindp.inc
   565 /home/grin/zsnes/src/gui/menu.asm
 17557 total

And that after ipher's major macro use (which cut lots of redundant lines) and legacy code cleanup. Also note a good 30% of that is unmaintainable, another 20% is hardcoded to all hell, and roughly 10% had to cope with older NASM deep-nested macro bugs and could be replaced with simpler code (but hell will melt over before someone pulls that :p).

For similar reasons I don't think it'll get forked, heh. Anyone skilled enough to work out the current issues without a major upheaval (like what we're doing) would probably find it easier/better to start their own project. Most of zsnes' codebase is unusable in other programs.

Post by **Nach** » Sun Sep 09, 2007 1:49 pm

grinvader wrote:
funkyass wrote:except the current GUI is several hundred lines of pure ASM.
Hundred ? haha oh wow
Code: Select all
$ wc -l ~/zsnes/src/gui/*.[ai]*
  3138 /home/grin/zsnes/src/gui/gui.asm
  1165 /home/grin/zsnes/src/gui/guicheat.inc
   193 /home/grin/zsnes/src/gui/guicombo.inc
  2800 /home/grin/zsnes/src/gui/guikeys.inc
   302 /home/grin/zsnes/src/gui/guimisc.inc
  3437 /home/grin/zsnes/src/gui/guimouse.inc
   829 /home/grin/zsnes/src/gui/guitools.inc
  5128 /home/grin/zsnes/src/gui/guiwindp.inc
   565 /home/grin/zsnes/src/gui/menu.asm
 17557 total
And that after ipher's major macro use (which cut lots of redundant lines) and legacy code cleanup. Also note a good 30% of that is unmaintainable, another 20% is hardcoded to all hell, and roughly 10% had to cope with older NASM deep-nested macro bugs and could be replaced with simpler code (but hell will melt over before someone pulls that :p).

Lets also not forget the massive amounts of code we ripped out for v1.5 and rewrote from scratch in C.

Before I joined the project, I'm pretty sure we were close to 30,000 lines of code for the GUI assembly.

Hundreds? Hahahaha!

creaothceann · Post by **creaothceann** » Sun Sep 09, 2007 2:42 pm

someone wrote:Always write code as if the maintenance programmer were an axe murderer who knows where you live.

amano · Post by **amano** » Thu Sep 13, 2007 8:31 pm

Will that require to have all the trolltech libraries installed? On GNOME, XFcE and on windows?

Aaron · Post by **Aaron** » Sun Sep 16, 2007 12:51 am

amano wrote:Will that require to have all the trolltech libraries installed? On GNOME, XFcE and on windows?

On Windows, ZSNES, like NSRT, would probably come with a DLL that the .exe will link to...

On Linux, they can also locally/hard-link Qt into the build, but most of the packages/source will probably default to linking libraries already on your computer.

Panzer88 · Post by **Panzer88** » Fri Sep 21, 2007 3:10 am

huh, I missed this memo for awhile, I had no idea the extent of the rewrite but this explains it all and makes it totally worth it. It is going to be one heck of a party and revival when it is released, take your time to make it great.

andyqkw · Post by **andyqkw** » Sat Sep 29, 2007 5:25 am

Thanks for the update, can't wait for ZSNES v2 to be released.

12th&saturn · Post by **12th&saturn** » Fri Oct 12, 2007 5:05 am

Regarding sound output, I'd suggest again looking at Mednafen's sound output layer in src/sexyal. It handles OSS, ALSA, Jack, SDL, DirectSound, and OS X's CoreAudio. Works wonderfully for me and many others with quite low latencies.

syntax_ · Post by **syntax_** » Sun Oct 21, 2007 4:39 am

I'm just curious but I have been reading various emulator author view points on C vs ASM and no one seems to agree; some say programming in ASM improves speeds others disagree and state its how the code is written. one example that stands out is kega being written almost entirely in asm (besides the gui). here is a quote from steve snake in the readme from Klive.

Klive is (hopefully) pretty accurate. It attempts to update each pixel of the screen at the exact
time that the real hardware does. For this reason, Klive will not be the fastest Spectrum emulator
available - however, it has been written from scratch, using 100% custom code, 99% of which is in
x86 ASM. This means that Klive is still pretty fast

ok, so wouldnt programming the co-processor chip/s (FX,SA,DPS...ect) code in ASM reduce system requirements for emulating these chips? porting is something else but linux shouldnt be a problem.

thanks

btw I'm really looking forward to the new core; hopefully the FX
emulation will be improved. especially with dirt trax fx; that and the timing problem in the SA emulation (mario rpg..freeze).

creaothceann · Post by **creaothceann** » Sun Oct 21, 2007 10:24 am

ASM is faster if you're better than the compiler. And that's very rare.

Besides, ASM is not portable between different CPU architectures.

Post by **Nach** » Sun Oct 21, 2007 3:52 pm

creaothceann wrote:ASM is faster if you're better than the compiler. And that's very rare.

Actually, for small functions, that's pretty common. For large functions it's rare.

Post by **grinvader** » Sun Oct 21, 2007 4:23 pm

For heavy bit/byte manips that use specific offsets/values/shifts, custom ASM often trounces compilers' since they can't see the big picture as well as the coder.
Yet, portability is the issue.

creaothceann · Post by **creaothceann** » Mon Oct 22, 2007 1:02 am

Just saw a related link on reddit:

http://www.azillionmonkeys.com/qed/asmexample.html
http://programming.reddit.com/info/5yrk1/comments/

byuu · Post by **byuu** » Mon Oct 22, 2007 2:16 am

People who have never programmed in assembler love to eschew that "a compiler is a better optimizer than a person," which is very foolish. It's mostly their attempts to justify not learning a more powerful language. It's the same thing you see VB/Java programmers saying about C/C++ programmers. To boot, people who can't program at all act as glorified phonographs and repeat these mantras.

An expert ASM programmer can get roughly 50% speedup per function compared to an expert C programmer, in my experience (mostly porting gradient fade screenfills, alpha blending routines, and video scalers -- the exact gain amount obviously varies based on what you are doing). I have ten years experience with both languages.

To put it another way, there are things a human can do that a compiler can't do, but there is nothing a compiler can do that a human cannot also do. Worst case scenario, if a compiler generates faster code ... disassemble it, learn from it, and then improve upon it even moreso.

However, there are some advantages compilers have over humans. They can optimize and generate different assembly code for different processors, something extremely tedious in ASM. This also safeguards you if processors move an older, silicon native opcode to microcode. Using xchg, while fast on a 486, would really really hurt you on an Athlon 64, for example. And they can also now create usage profiles to further optimize based on the most common code flows. But overall, a well versed ASM programmer can almost always beat out an expert C programmer. Emulators are a great example of that. ZSNES? NESticle? Project Unreality (vs other N64 interpreters, not HLE/Dynarec emulators)? KGen?

But ultimately, I don't believe the speed gain is worth the lack of portability. Especially not for these older consoles like the Genesis and SNES. They were at the time the aforementioned emulators came out, but not now as we have much more processing power at our disposal.

However, it can be very advantageous to optimize merely the most critical portions of the program, and leave the trivial / lesser used stuff in C++, ala SNES9x (or at least their older versions). Rewrite them in C++ as well for other targets, and you have a win-win situation.