Current Status FAQ
Moderator: ZSNES Mods
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Current Status FAQ
Read this: http://zsnes.game-host.org/faq.txt
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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 :wink:](./images/smilies/icon_wink.gif)
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 :wink:](./images/smilies/icon_wink.gif)
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
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. ![Smile :)](./images/smilies/icon_smile.gif)
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.
![Smile :)](./images/smilies/icon_smile.gif)
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.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
-
- Rookie
- Posts: 20
- Joined: Thu Mar 01, 2007 6:47 pm
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).
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).
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:Why don't you consider something like libao or portaudio (or OpenAL)?
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.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).
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!
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!
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Hundred ? haha oh wowfunkyass wrote:except the current GUI is several hundred lines of pure ASM.
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
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Lets also not forget the massive amounts of code we ripped out for v1.5 and rewrote from scratch in C.grinvader wrote:Hundred ? haha oh wowfunkyass wrote:except the current GUI is several hundred lines of pure ASM.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).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
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
_____________
Insane Coding
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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
bsnes launcher with recent files list
On Windows, ZSNES, like NSRT, would probably come with a DLL that the .exe will link to...amano wrote:Will that require to have all the trolltech libraries installed? On GNOME, XFcE and on windows?
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.
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]
-
- Rookie
- Posts: 11
- Joined: Tue Apr 25, 2006 4:30 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.
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).
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
![Question :?:](./images/smilies/icon_question.gif)
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).
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
ASM is faster if you're better than the compiler. And that's very rare.
Besides, ASM is not portable between different CPU architectures.
Besides, ASM is not portable between different CPU architectures.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Actually, for small functions, that's pretty common. For large functions it's rare.creaothceann wrote:ASM is faster if you're better than the compiler. And that's very rare.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
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.
Yet, portability is the issue.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Just saw a related link on reddit:
http://www.azillionmonkeys.com/qed/asmexample.html
http://programming.reddit.com/info/5yrk1/comments/
http://www.azillionmonkeys.com/qed/asmexample.html
http://programming.reddit.com/info/5yrk1/comments/
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
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.
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.