View unanswered posts | View active topics It is currently Wed Jul 17, 2019 6:30 am



Reply to topic  [ 120 posts ]  Go to page 1, 2, 3, 4, 5  Next
Current Status FAQ 
Author Message
ZSNES Developer
ZSNES Developer

Joined: Tue Dec 28, 2004 6:47 am
Posts: 6747
Reply with quote
Post Current Status FAQ
Read this: http://zsnes.game-host.org/faq.txt

_________________
Continuing FF4 Research...


Mon Sep 03, 2007 2:38 am
Profile
Veteran
User avatar

Joined: Sat Apr 21, 2007 8:05 pm
Posts: 637
Reply with quote
Post 
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.


Mon Sep 03, 2007 5:28 am
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
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


Mon Sep 03, 2007 7:37 am
Profile WWW
Romhacking God

Joined: Wed Jul 28, 2004 11:27 pm
Posts: 922
Reply with quote
Post 
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.


Tue Sep 04, 2007 2:49 pm
Profile WWW
Hero of Time
User avatar

Joined: Fri Jul 30, 2004 2:49 am
Posts: 2646
Location: In front of the monitor
Reply with quote
Post 
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


Tue Sep 04, 2007 11:49 pm
Profile WWW
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
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).


Wed Sep 05, 2007 10:04 am
Profile
Hero of Time
User avatar

Joined: Fri Jul 30, 2004 2:49 am
Posts: 2646
Location: In front of the monitor
Reply with quote
Post 
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


Wed Sep 05, 2007 2:36 pm
Profile WWW
Lurker

Joined: Wed Jul 28, 2004 1:35 am
Posts: 128
Reply with quote
Post 
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.


Wed Sep 05, 2007 2:45 pm
Profile ICQ YIM
"God"

Joined: Tue Jul 27, 2004 11:24 pm
Posts: 1128
Reply with quote
Post 
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.


Wed Sep 05, 2007 3:28 pm
Profile
Reply with quote
Post 
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!


Wed Sep 05, 2007 10:50 pm
Veteran
User avatar

Joined: Thu Feb 03, 2005 8:18 pm
Posts: 768
Reply with quote
Post 
Stick with the name you know and trust for all your emulation needs: ZSNES!

_________________
Official ZSNES Docs | NSRT Guide | Using a Wiimote w/ emulators


Thu Sep 06, 2007 2:22 am
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
funkyass wrote:
except the current GUI is several hundred lines of pure ASM.

Hundred ? haha oh wow
Code:
$ 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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sun Sep 09, 2007 12:59 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
grinvader wrote:
funkyass wrote:
except the current GUI is several hundred lines of pure ASM.

Hundred ? haha oh wow
Code:
$ 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


Sun Sep 09, 2007 1:49 pm
Profile WWW
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
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


Sun Sep 09, 2007 2:42 pm
Profile WWW
Rookie

Joined: Thu Apr 27, 2006 12:04 am
Posts: 11
Reply with quote
Post 
Will that require to have all the trolltech libraries installed? On GNOME, XFcE and on windows?


Thu Sep 13, 2007 8:31 pm
Profile
Lurker
User avatar

Joined: Sat Dec 31, 2005 7:26 am
Posts: 157
Reply with quote
Post 
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.


Sun Sep 16, 2007 12:51 am
Profile
Inmate

Joined: Thu Jan 11, 2007 4:28 am
Posts: 1485
Location: Salem, Oregon
Reply with quote
Post 
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.

_________________
byuu wrote:
Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? >:(


Fri Sep 21, 2007 3:10 am
Profile WWW
Rookie

Joined: Tue Mar 13, 2007 2:20 am
Posts: 12
Reply with quote
Post 
Thanks for the update, can't wait for ZSNES v2 to be released.


Sat Sep 29, 2007 5:25 am
Profile
Rookie

Joined: Tue Apr 25, 2006 4:30 am
Posts: 11
Reply with quote
Post 
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.


Fri Oct 12, 2007 5:05 am
Profile
New Member
User avatar

Joined: Sun Oct 21, 2007 4:24 am
Posts: 8
Reply with quote
Post 
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.

Quote:
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).


Sun Oct 21, 2007 4:39 am
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
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


Sun Oct 21, 2007 10:24 am
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
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


Sun Oct 21, 2007 3:52 pm
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sun Oct 21, 2007 4:23 pm
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
Just saw a related link on reddit:

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

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


Mon Oct 22, 2007 1:02 am
Profile WWW
Reply with quote
Post 
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.


Mon Oct 22, 2007 2:16 am
Display posts from previous:  Sort by  
Reply to topic   [ 120 posts ]  Go to page 1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.