Current Status FAQ

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Current Status FAQ

Post by Deathlike2 »

Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
DancemasterGlenn
Veteran
Posts: 637
Joined: Sat Apr 21, 2007 8:05 pm

Post by DancemasterGlenn »

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
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

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. :wink:
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

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.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
snkcube
Hero of Time
Posts: 2646
Joined: Fri Jul 30, 2004 2:49 am
Location: In front of the monitor
Contact:

Post by snkcube »

Thanks for posting that up. It's good to take your time on something like this.
Try out CCleaner and other free software at Piriform
Image
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

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
Hero of Time
Posts: 2646
Joined: Fri Jul 30, 2004 2:49 am
Location: In front of the monitor
Contact:

Post by snkcube »

No updates to SVN doesn't mean it's not being maintained. The developers could be doing this in private builds.
Try out CCleaner and other free software at Piriform
Image
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

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
"God"
Posts: 1128
Joined: Tue Jul 27, 2004 11:24 pm

Post by funkyass »

except the current GUI is several hundred lines of pure ASM.
Does [Kevin] Smith masturbate with steel wool too?

- Yes, but don’t change the subject.
byuu

Post by byuu »

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
Veteran
Posts: 768
Joined: Thu Feb 03, 2005 8:18 pm
Contact:

Post by Jipcy »

Stick with the name you know and trust for all your emulation needs: ZSNES!
[url=http://zsnes-docs.sf.net]Official ZSNES Docs[/url] | [url=http://zsnes-docs.sf.net/nsrt]NSRT Guide[/url] | [url=http://endoftransmission.net/phpBB3/viewtopic.php?t=394]Using a Wiimote w/ emulators[/url]
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

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.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

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!
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

someone wrote:Always write code as if the maintenance programmer were an axe murderer who knows where you live.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
amano
Rookie
Posts: 11
Joined: Thu Apr 27, 2006 12:04 am

Post by amano »

Will that require to have all the trolltech libraries installed? On GNOME, XFcE and on windows?
Aaron
Lurker
Posts: 157
Joined: Sat Dec 31, 2005 7:26 am

Post by Aaron »

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
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

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.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
andyqkw
Rookie
Posts: 12
Joined: Tue Mar 13, 2007 2:20 am

Post by andyqkw »

Thanks for the update, can't wait for ZSNES v2 to be released.
12th&saturn
Rookie
Posts: 11
Joined: Tue Apr 25, 2006 4:30 am

Post by 12th&saturn »

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_
New Member
Posts: 8
Joined: Sun Oct 21, 2007 4:24 am

Post by syntax_ »

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
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

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

Besides, ASM is not portable between different CPU architectures.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

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.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

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.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
byuu

Post by byuu »

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.
Post Reply