bsnes board
bsnes and other SNES related stuff

FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Aug 31, 2005 4:13 am Post subject: bsnes thread

bsnes is a super-accurate, cross-platform SNES emulator by byuu. You can read all about it and download new versions at: http://byuu.org. The title of this thread will change to reflect new releases.

All commercially released games have been tested (~3000) and it is currently believed that 99.9% of games without special chips play with 100% perceived accuracy. The emulator contains no game-specific hacks and makes almost no compromises to compatibility for speed gains. This means that bsnes has very high minimum requirements: at least a 1.8ghz Core 2 Duo to achieve 60fps without frameskipping.

bsnes' PPU is scanline-based rather than dot-based. A scanline-based renderer is technically a general hack that most emulators use to simplify the PPU and achieve massive speed gains with virtually no sacrifice to compatibility. Without it, bsnes wouldn't even come close to reaching 60fps on modern CPUs. That said, only a few obscure games have issues with a scanline-based renderer, and the issue is usually very minor and takes the form of an incorrectly displayed horizontal line on a menu screen (thus the .1% deduction above). Several advanced options have been created to make the scanline-based renderer behave closer to a dot-based one, improving accuracy without resorting to game-specific hacks. byuu has stated that he may in the future begin writing a dot-based renderer out of a desire to document the SNES' PPU.


ORIGINAL POST:
As some of us may or not know, byuu released a new version of his snes emulator last week. byuu, although I'm sure the resources for help are better today than in the past, you ARE a code monster. Seriously, the level your emu is at now from when you started is crazy. I am also pleasantly surprised by how often you post updates, and the detail with which you blog. It's interesting to see your train of thought in the progress of your emu. So yeah, just wanted to let you know that you rock since I've never seen anyone post a bsnes update here yet.

I read your recent log and... until now I had no idea that you knew next to nothing about sound. Naturally, my hopes for a 1-2 punch emu were once again somewhat dashed. As an outsider who knows not much at all about code, I can only be so critical and frustrated with the stagnance in snes sound emulation right now. A lot of great, accurate emus out there, but the same ol "sound is a real bitch" issue that just puts a grinding halt to the possibility of snes ultimacy. I've pretty much given up hope of zsnes ever getting the sound issues fixed. We're lucky to get a gamefix at all anymore in the wips. Understandably, but true.

Anyways, I'm sure TRAC knows how godlike his sound code is, and probably has his reasons for not wanting to entrust it to other emulators. Additionally, he probably knows that if he doesn't, any hope of snes ultimacy will continue to be snuffed out. I guess what I'm getting at here is: WHO IS THIS TRAC!? Very Happy: Why is he so good and what will it take to get him to team up with someone like you?


Last edited by FitzRoy on Fri Mar 21, 2008 4:32 am; edited 272 times in total
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Wed Aug 31, 2005 4:16 am Post subject:

TRAC writes SnEeSe. I'm sure he's willing to share info, but I doubt he'd want to merge the two emus.
_________________
#577451
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Aug 31, 2005 4:19 am Post subject:

The Giver wrote:
TRAC writes SnEeSe. I'm sure he's willing to share info, but I doubt he'd want to merge the two emus.


I know, I mean, besides that... That's all I know, seriously. He's very mysterious.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Aug 31, 2005 5:05 am Post subject:

Thanks for the kind words, much appreciated.

TRAC is more than willing to help, and I've been nagging him the past couple of days on IRC for info. He's an awesome guy. I just hope I can keep from annoying him too much while I'm catching up to speed. I'm sure he wouldn't mind me using his sound code, the problem is that our emulators are very different, and it isn't exactly trivial to just merge his work into my emulator. Not to mention, it would be disrespectful to TRAC to do that. And, more importantly, I'm writing this so that I can understand the system. We won't get anywhere by cutting and pasting misc. emulators together.

Quote:
Seriously, the level your emu is at now from when you started is crazy.

Hm, you think so? I always thought development was kind of slow, especially given that old saying, "The road is always quicker for the second traveller"...

Anyway, everyone else is still making a lot of great progress too (anomie, TRAC, Overload, pagefault, Nach, etc), they just don't talk about it as much as I do. They deserve more props than I do.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Wed Aug 31, 2005 12:32 pm Post subject:

Byuu, you are doing some seriously crazy work in making sense of the hardware. I think you've brought new life to the research into the dark corners of the SNES's inner workings.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Aug 31, 2005 4:56 pm Post subject:

byuusan wrote:
Thanks for the kind words, much appreciated.

TRAC is more than willing to help, and I've been nagging him the past couple of days on IRC for info. He's an awesome guy. I just hope I can keep from annoying him too much while I'm catching up to speed. I'm sure he wouldn't mind me using his sound code, the problem is that our emulators are very different, and it isn't exactly trivial to just merge his work into my emulator. Not to mention, it would be disrespectful to TRAC to do that. And, more importantly, I'm writing this so that I can understand the system. We won't get anywhere by cutting and pasting misc. emulators together.


True, true. I guess I assumed video and sound were so seperate that it would take only minor adjustments to port it over assuming it was the same language (and of course, TRAC would be credited as a co-author or something so as not disrespect him by just taking it). It's probably much more complicated than that, and I once again underestimate your willingness to learn what sounds like you're biggest challenge yet. Good luck to you.

(PS. If you get to a point where you think it might help, I have an snes with digital output. If you have optical input on your computer, you can record bitperfect snes waveforms for comparison, analysis, whatever. Alternatively, I could send you recordings.)
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Aug 31, 2005 5:38 pm Post subject:

FitzRoy: If you would see what goes on in IRC for a while, it won't seem so mysterious.

And we are teaming up in ways, although I won't give out any details on that at the moment.

Regarding using TRAC's sound core, he gave permission for it to be put into ZSNES. pagefault is supposed to be working on that, and I'm waiting for that to be completed before I tackle any of the major things I wanted to do to ZSNES.

byuusan wrote:

Anyway, everyone else is still making a lot of great progress too (anomie, TRAC, Overload, pagefault, Nach, etc), they just don't talk about it as much as I do. They deserve more props than I do.


Oh please, what progress am I making? Yes I can spice up an emulator, but make progress on emulation? I barely know anything about emulation. I do for emulation what ipher does for the GUI.

It's anomie, TRAC, Overload, you, and formerly people such as zsKnight, Gary, _Demo_, pagefault that do all the real progress.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Sep 02, 2005 5:51 pm Post subject:

Nach wrote:

And we are teaming up in ways, although I won't give out any details on that at the moment.

Regarding using TRAC's sound core, he gave permission for it to be put into ZSNES. pagefault is supposed to be working on that, and I'm waiting for that to be completed before I tackle any of the major things I wanted to do to ZSNES.


Whoa, that's awesome news!
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Sep 02, 2005 9:01 pm Post subject:

Quote:
And we are teaming up in ways, although I won't give out any details on that at the moment.

How mysterious.

Quote:
Oh please, what progress am I making?

You've contributed direct fixes to my emulator, such that Mega Man X is now playable. You also fixed the RAM initialization stuff in ZSNES such that reset is now possible (me pointing it out is irrelevant, it wouldn't be fixed without you). Hopefully your work on NSRT will eventually result in us having a standardized emulator header for ROM images. Give yourself more credit :D
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Sep 04, 2005 1:09 am Post subject:

Sure I gave you some patches and did some stuff for other emulators, but I haven't really done any emulation progress.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
badinsults
"Your thread will be crushed."


Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg

Posted: Sun Sep 04, 2005 1:33 am Post subject:

I have a question. Where would one start to learn to make a snes emulator? This is assuming that one has no knowledge on anything about the internal workings of the snes.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Sun Sep 04, 2005 9:07 am Post subject:

GOATSnEs wrote:
I have a question. Where would one start to learn to make a snes emulator? This is assuming that one has no knowledge on anything about the internal workings of the snes.

No knowledge at all ? One must be lucky enough to be entrusted with docs, read them in their entirety, then read them again with some aspirin ready nearby.

After that it's "just" a matter of defining how precise you want to emulate stuff.

A copier and a real snes to run test programs don't hurt. Trial and error fill in the blanks where docs aren't explicit.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
badinsults
"Your thread will be crushed."


Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg

Posted: Sun Sep 04, 2005 5:55 pm Post subject:

grinvader wrote:
GOATSnEs wrote:
I have a question. Where would one start to learn to make a snes emulator? This is assuming that one has no knowledge on anything about the internal workings of the snes.

No knowledge at all ? One must be lucky enough to be entrusted with docs, read them in their entirety, then read them again with some aspirin ready nearby.

After that it's "just" a matter of defining how precise you want to emulate stuff.

A copier and a real snes to run test programs don't hurt. Trial and error fill in the blanks where docs aren't explicit.


Once I get a copier, the pieces will be set.
anomie
Lurker


Joined: 07 Dec 2004
Posts: 168

Posted: Sun Sep 04, 2005 9:30 pm Post subject:

grinvader wrote:
Trial and error fill in the blanks where docs aren't explicit.

... or are wrong.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Sun Sep 04, 2005 10:06 pm Post subject:

anomie wrote:
grinvader wrote:
Trial and error fill in the blanks where docs aren't explicit.

... or are wrong.

Exact. I always (stupidly) assume docs are right.

That's why we need to clean the garbage and only keep the real stuff. And by 'we', I actually mean you, byuu, and whoever is actually doing something about it ^^; .
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
lockharte
Zealot


Joined: 02 Feb 2005
Posts: 1045

Posted: Sun Sep 04, 2005 11:06 pm Post subject:

we should see a whole new sleuth of snes emulators once his documentation is complete.

btw, what other snes are out there besides snes9x, bsnes, and snese, and zsnes, of course.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Sun Sep 04, 2005 11:08 pm Post subject:

SNEeSe, Super Sleuth, and I've heard of NLKE, but I've never used it.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Sun Sep 04, 2005 11:13 pm Post subject:

SNEmul.
_________________
#577451
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Sun Sep 04, 2005 11:19 pm Post subject:

Here's a few more I just thought of:
UOSnes, SnesGT, Snes9k (which is Snes9X, but it uses the Kailerra netplay client), and xSnes9x (Snes9X for the XBox Razz)
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Mon Sep 05, 2005 12:12 am Post subject:

There was an old SNES emulator called CHAMPI that I liked for a long time (well, several months at the most). It was fast, and the GUI was entirely in Spanish. Of course this emulator doesn't compare to ZSNES now. Razz

I believe it's available for download at emuxhaven.
lockharte
Zealot


Joined: 02 Feb 2005
Posts: 1045

Posted: Mon Sep 05, 2005 2:42 am Post subject:

is zsnes currently compatible with XBOX?
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Sep 05, 2005 2:50 am Post subject:

http://board.zsnes.com/phpBB2/viewtopic.php?t=4352
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Sep 05, 2005 4:41 am Post subject:

IIRC pagefault will be porting ZSnes to XBox, if and when he gets one
You'll have to have it modded though, nothing we can do about that -_-
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Sep 06, 2005 8:31 am Post subject: Re: bsnes appreciation thread, sound woes

Quote:
I read your recent log and... until now I had no idea that you knew next to nothing about sound. Naturally, my hopes for a 1-2 punch emu were once again somewhat dashed.

Hmm, perhaps this, or possibly this will help...

All your thanks are belong to anomie for the above.
Zuzma
Guest





Posted: Wed Sep 07, 2005 2:42 am Post subject:

Okay now I'm impressed. How do other games that are real trouble makers like earth worm jim 2 sound? Even SNEeSe is kinda shaky on that game. I mean the music is fine but the sound fx for it is weird.

Edit: Embarassed Nevermind I just checked your homepage. That still doesn't change the fact that bsnes kicks ass. Good job.
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Wed Sep 07, 2005 3:44 am Post subject:

Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache.
_________________
#577451
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Sep 07, 2005 4:55 am Post subject:

Oh, w00t city! Course, the real test is the heavy SPCrape sound fx... things like: Chrono Trigger opening screen shifts, bats and lightning in Castlevania IV, and the Star Fox background engine sound (that'll have to wait). Regardless - good work and sooner than expected!
Pepper
New Member


Joined: 08 Sep 2005
Posts: 6

Posted: Thu Sep 08, 2005 5:31 pm Post subject: wow

Looks like you already know what you are doing. Blargg has a pretty good snes sound emu and has some good resources.

http://www.slack.net/~ant/nes-emu/
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Sep 15, 2005 6:58 pm Post subject:

More news: http://byuu.cinnamonpirate.com/?page=bsnes_news
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Sep 16, 2005 5:29 am Post subject:

Some of it bad news, too. My 2.4ghz works hard to get ~50fps in bsnes as it is right now. I guess it goes to show how difficult it is to have fast and accurate code. Help the BYUU!!!

By the way, it must be pretty exciting for byuu to see his emu almost becoming fully playable with sound and everything. *waits patiently for new versions*
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Fri Sep 16, 2005 7:42 am Post subject:

FitzRoy wrote:
Some of it bad news, too. My 2.4ghz works hard to get ~50fps in bsnes as it is right now. I guess it goes to show how difficult it is to have fast and accurate code. Help the BYUU!!!


byuu and I just sped it up quite a bit. I might also add in *nix I have no trouble getting sound Wink
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Sep 16, 2005 9:28 am Post subject:

Yes, many many thanks to Nach for profiling the code for me. It's about 15-20% faster with only one function improved and one slightly touched a little. The slowest function right now is a MONSTER of a routine that handles ~80% of all rendering. Not an easy one to mess with without breaking lots of stuff.

Sound on Linux is /better/ than on Windows because the program that sends the sound to the soundcard automatically does resampling stuff that I don't know how to do yet... but it has terrible latency compared to the Windows port.

Quote:
My 2.4ghz works hard to get ~50fps in bsnes as it is right now.

Must be an Intel. My 1.67ghz /got/ about that on v0.011...
I agree with everyone that the speed is deplorable for an SNES emulator. I'd doubt that I'd ever see more than a 100% speed increase from v0.011 ever. But you never know.

Quote:
Looks like you already know what you are doing. Blargg has a pretty good snes sound emu and has some good resources.

I looked briefly at it. It looks mostly like libopenspc with improvements + the BOOST library for a few tiny things. Nothing I couldn't rewrite, but eh. From what I've seen of libopenspc, it isn't very good compared to modern emulators. It chokes pretty badly on Der Langrisser music.
It was easier to go with anomie's work. And we can share bugfixes and such as he is actively developing his code still.

Quote:
Chrono Trigger opening screen shifts

They sound fine to me. I don't have the other games.

---

BTW, I tend to post updates once a week or so... just sayin'.
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Fri Sep 16, 2005 9:52 am Post subject:

The speed with v0.11 is great for me, in fact the emulator runs too fast with most games.

With frameskip off and any Window size (does not make a difference which) and running Aladdin, I get 80fps in menus and 66fps when playing the game.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Sep 16, 2005 8:22 pm Post subject:

Yes, but it still takes a really fast cpu to do that, and the cpu usage is like 60% for me, sometimes spiking to 75%. Comparitively, other emus use 15% or less to get 60fps. Like byuu said, though, there is some rendering code that is doing that and it takes time to make make faster without breaking stuff.

Small request, byuu: can we get the .SFC extension added to the "open rom image" list? That's what all my headerless snes files are called and it's what NSRT renames them to.
Pepper
New Member


Joined: 08 Sep 2005
Posts: 6

Posted: Fri Sep 16, 2005 10:13 pm Post subject:

byuusan wrote:

I looked briefly at it. It looks mostly like libopenspc with improvements + the BOOST library for a few tiny things. Nothing I couldn't rewrite, but eh. From what I've seen of libopenspc, it isn't very good compared to modern emulators. It chokes pretty badly on Der Langrisser music.
It was easier to go with anomie's work. And we can share bugfixes and such as he is actively developing his code still.


cool. Awesome emu, I can play Apocalypse II (Beta), which snes9x does not. The only bug (I think it is a bug as I don't know what the real hardware does) I have even seen is graphics corruption on the character select screen of Seiken Densetsu 3 with Corlett's translation.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Sep 18, 2005 10:09 pm Post subject:

Yeah I'd also like to congradulate Byuu for his awesome progress. I do think Bsnes has progressed very quickly,and in a extremely promising direction.(edit*)

No offense to anyone but I think it's way too early to ask for feature request in Bsnes. I mean,even though it's showing great promises, it's still in development after all.


*Credit also goes to all who've contributed to Snes emulation of course.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Sep 18, 2005 10:36 pm Post subject:

Dmog wrote:

No offense to anyone but I think it's way too early to ask for feature request in Bsnes. I mean,even though it's showing great promises, it's still in development after all.


Wasn't really a "feature" request though, and I agree with you.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Sep 18, 2005 11:54 pm Post subject:

Quote:
Small request, byuu: can we get the .SFC extension added to the "open rom image" list?


Done. Slight oversight, I had .sfc in there before I rewrote the thing around April... :/

Been thinking about making one of those kawaks/snes9x-style ROM loaders, and obviously leaving the regular one there as well, but that won't be any time soon...

Quote:
The only bug (I think it is a bug as I don't know what the real hardware does) I have even seen is graphics corruption on the character select screen of Seiken Densetsu 3 with Corlett's translation.

I'll look into it, thank you. There's actually quite a few games with graphical bugs (Energy Breaker, Contra 3 first boss, Chrono Trigger hi-res screens, ...)
Most of them are offset-per-tile mode related.
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Mon Sep 19, 2005 11:58 am Post subject:

byuu's homepage wrote:
I've also been trying to fix up the offset-per-tile code, but for the life of me, I can't even reproduce a bug in my own code; and all the games that it screws up in (Chrono Trigger intro, Contra 3 first boss, etc), I have to play several minutes to get to that part. It's too hard to debug stuff so far into the games without savestates.

Uh... implement savestates then, at least partially? Question
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Tue Sep 20, 2005 2:48 am Post subject:

I'm excited to try out your next release.

Can you highlight some games that your emulator runs better than ZSNES/snes9x/SNEESE?
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Sep 20, 2005 10:31 am Post subject:

No savestates for now, for reasons I won't discuss just yet. They'll be there eventually, though.

Quote:
Can you highlight some games that your emulator runs better than ZSNES/snes9x/SNEESE?

Better than ZSNES?
Final Fantasy 5 title isn't misaligned
Final Fantasy 6 cursor doesn't vanish randomly
Star Ocean battles don't run too fast
Madara 2 intro isn't chaotic
Metroid 3 top status panel looks correct
Goodbye, Anthrox mode7 zoom looks correct
SNES test program passes
Modes 3,4,7 direct color, Mode 7 mosaic + EXTBG work
Interlaced sprites work (really only used in Blues Brothers)
Anything that relies on open bus working correctly

I don't test with SNES9x/SNEeSe enough to know any of its bugs, but I imagine they're far less common.

Now as for games it runs worse... probably everything else not listed above.
No support for DSP1-4, SA-1, Super FX/2, Toaster, BSX, ST, OBC, ST-01n, peripherals, lots of CPU/PPU/APU/DSP bugs to be found, sound buffering is non-existant...
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Tue Sep 20, 2005 12:00 pm Post subject:

byuusan wrote:
No savestates for now, for reasons I won't discuss just yet.

You don't have to. Smile

byuusan wrote:
They'll be there eventually, though.

Great! Razz
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Tue Sep 20, 2005 10:11 pm Post subject:

What games used Toaster now, or did I miss something ?
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Sep 21, 2005 2:25 am Post subject:

adventure_of_link wrote:
What games used Toaster now, or did I miss something ?


He was referring to the fact that ZSNES has Toaster support, but he doesn't ever plan on adding it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Wed Sep 21, 2005 2:28 am Post subject:

Oh ok, thanks Nach.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Metatron
Deus ex Machina


Joined: 28 Jul 2004
Posts: 1323

Posted: Wed Sep 21, 2005 2:44 am Post subject:

Nach wrote:
adventure_of_link wrote:
What games used Toaster now, or did I miss something ?


He was referring to the fact that ZSNES has Toaster support, but he doesn't ever plan on adding it.


I demand that you add the option of adding cheese between two slices of toast! I also demand that you include multiple types of bread, such as white, whole wheat, potato, etc.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Sep 21, 2005 4:55 am Post subject:

Demand denied.
However you are welcome to search for the other easter egg I snuck in recently.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Oct 02, 2005 12:42 am Post subject:

Weee, an update! More accuracy goodness.

Edit: And no sooner do I post this than does byuu release version .012! I was very eagerly awaiting this new version, just to see what the sound was like - and my friends - IT IS GOOD! Very Happy Even though the issues are there with the speed and cutting out of things, I immediately tested out Chrono Trigger and Super Castlevania IV to see if SPC Rape was correctly emulated - it is! Hearing all the wonderful sound effects in their true form was a real treat, much like sneese. I can't wait for this emu to reach full form. It's only a matter of time before snes ultimacy is achieved. Good job!
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Oct 02, 2005 8:29 am Post subject:

Damn you guys are quick to notice my updates o_O

Be sure to use Misc > Log Audio Data if you want to hear what the sound should be like... it'll record to audioNNN.wav in the same folder as bsnes or the ROM you loaded (in that order). That way you won't get any distortion / crackling due to the samples not being updated at exactly 32000hz during emulation, as my code lacks any and all buffering / resampling support at present. I don't know how to do that.

Linux users can play the sound a lot better already with this (thanks to Nach):
Code:
mkfifo output.wav
bsnes_sdl <rom.smc> & mplayer output.wav


Glad it's working though... you're all basically my beta testers... muwahahahaha...

Also, do me a favor and don't try Der Langrisser. That game has some screwy sound code...
PFUNK
Lurker


Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA

Posted: Sun Oct 02, 2005 8:37 pm Post subject:

FitzRoy wrote:
I can't wait for this emu to reach full form. It's only a matter of time before snes ultimacy is achieved. Good job!


Ha ha ha.

I seriously doubt it will only be a "matter of time" before perfect emulation is achieved. No offense to byuu (you're progress in emulation and in your emulator in general are both impressive and awesome), but I'm under the impression it will take a much longer time to achieve. Heck, the emulator doesn't touch some of the more advanced chips and whatnot, but hats off to you developers/reverse-engineer types.

All in all, I hope byuu continues his great work and isn't assaulted by "I WANT SUPER HQ2X EAGLE 2X FILTER SUPPORT NOW." Leave that shit to (frontends?) like other emulators leave rerecording to other programmers. Oh, and on a tangent, my only real qualms with bsnes are its speed (too fast on my laptop) and CPU usage. Those two problems will probably be settled all in good time however, and I believe byuu is already aware of them.
_________________
I'm hot for you and you're hot for me ooka dooka dicka dee.
kode54
Veteran


Joined: 28 Jul 2004
Posts: 789

Posted: Sun Oct 02, 2005 9:25 pm Post subject:

Regulating emulation speed by sound output is also a good solution. That way, you also don't have to worry about systems having high resolution timers. You just have to worry about having a nice way to defer execution while sound output runs.

With SDL, you have a nice callback to notify you when it needs samples.

In native Win32, you can do the following:

With WaveOut, send whole frames worth of audio per WAVEHDR, use either the callback mechanism, window messages, or events to defer execution according to audio playback.

With DirectSound, you can try an exact sized SOFTWARE (IMPORTANT: never use hardware when you want to use event notifications) buffer with an event map tied to buffer offsets, OR you can use Sleep(1) until there's room for a frame worth of audio. But then, you only get context switching and time slices as fine as 10ms, or 1ms if you use timeBeginPeriod(1) on startup.

With Kernel Streaming, you can send arbitrary packets similar to WaveOut, and you get to defer execution on synchronization Events just like with overlapped file I/O operations. You lose kmixer software mixing and resampling, so you only get sample rates supported by the hardware, and you completely take over the device if it doesn't do hardware mixing. There's also no easy way to associate an output device with a given WaveOut/Dsound device, or even select the correct default, and you could even BSOD the system if there's flaky drivers and you select a bad output filter. This API is also not future-proof.

For the cleanest and safest for arbitrary sized block output with exact event notification, I would consider trying WaveOut on Win32, using the callbacks, and your own Event synchronization to defer execution in your sound output function. The general idea is you have a fixed circular array of WAVEHDRs and Events, all in set state on init, so your write block function prepares/outputs all of them at first. The queue function resets the Event as it sends that header. The waveout callback then sets it again as that header is finished, so the write function will continue.

I will write a nice simple class that does this with WaveOut, preference on the ability to defer execution for up to one frame worth of sound, for regulating the remaining stages of the playback thread to the sound output. I already have such a class for Kernel Streaming, but you already know the drawbacks to that.

I'd be interested to know how easy it is to have a low latency OSS file session open to /dev/dsp or similar, writing a frame worth of sound at a time, using the natural blocking behavior to regulate the emulaton thread, and how well it works in practice.

I will share my simple sound output class and the waveout implementation as soon as I write it, which should be tomorrow. I was going to do that today, but my whole day seems to have gone by too fast. Blah, need sleep soonish.

Tomorrow. Yes, tomorrow....
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Oct 02, 2005 9:53 pm Post subject:

PFUNK wrote:
FitzRoy wrote:
I can't wait for this emu to reach full form. It's only a matter of time before snes ultimacy is achieved. Good job!


Ha ha ha.

I seriously doubt it will only be a "matter of time" before perfect emulation is achieved.


Ha? Have you even tried this thing? The accuracy is insane. bsnes handles every non-special chip game I've thrown at it to perfection. Only one of the wierd graphics bugs I'm aware of in zsnes happens in this version. The sound is as amazing as sneese. It emulates spc rape correctly, literally a bug that afflicts nearly the entire library of games in other emus. And special chip games, while most unsupported at this time represent an incredibly small fraction of snes games (and it's not like these won't get supported at some point). It sounds silly because we've been living with the same video/sound bugs in current emus for years, but bsnes is a lot closer than you think. Instead of being so pessimistic, maybe you should become a rabid fan like me. Laughing
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Oct 03, 2005 2:58 am Post subject:

kode54 wrote:

With Kernel Streaming, you can send arbitrary packets similar to WaveOut, and you get to defer execution on synchronization Events just like with overlapped file I/O operations. You lose kmixer software mixing and resampling, so you only get sample rates supported by the hardware, and you completely take over the device if it doesn't do hardware mixing. There's also no easy way to associate an output device with a given WaveOut/Dsound device, or even select the correct default, and you could even BSOD the system if there's flaky drivers and you select a bad output filter. This API is also not future-proof.


Kernel streaming in an snes emulator? Probably not the most practical choice, but I think I would shit my pants if that happened. Shocked
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Mon Oct 03, 2005 3:01 am Post subject:

Why wouldn't it be a practical choice?
_________________
#577451
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Oct 03, 2005 4:11 am Post subject:

PFUNK wrote:
Ha ha ha.

I seriously doubt it will only be a "matter of time" before perfect emulation is achieved.


You're half right. Perfect emulation will never be achieved, but that doesn't mean I can't get damn close. I'm mostly finished with the CPU timing (sans HDMA and conflicting events like DMA overlapping an NMI). Then there's really only APU and PPU. The APU doesn't have anything special in it (no DMA or interrupts), and the PPU will probably never be finished because it requires a pixel-based renderer.

I have no interest in emulating add-on chips. They have nothing to do with the SNES hardware. You could stick a PS2 on an SNES cart if you wanted. However, I have no objections to adding all of them sans SuperFX/2 and SA-1, at some point in the future. Hell, maybe even those if they're easy enough.

Quote:
All in all, I hope byuu continues his great work and isn't assaulted by "I WANT SUPER HQ2X EAGLE 2X FILTER SUPPORT NOW." ... Oh, and on a tangent, my only real qualms with bsnes are its speed (too fast on my laptop) and CPU usage.


Don't worry. I'm not planning on adding bells and whistles until the core stuff is finished.

I'm used to hearing it runs too slow, especially on laptops. Speed throttling isn't added yet (because I can't get >=60fps to test it on my machine...), but when it is -- if you're getting over 60fps then it won't consume all of your idle CPU time anymore. But it'll still consume probably 5-10x the CPU usage that ZSNES does. ZSNES really is a better choice if you're using a mobile processor and want to preserve your battery power.
As far as it requiring so much more power than ZSNES... there's little I can do about that. I don't write code in x86 assembler, and I have to do things the hard way in a lot of cases. My processor emulators run cycle-to-cycle, my NMI / IRQ timing happens between bus cycles within an opcode, my H/DMA timing requires being able to cycle-step, and I actually time my SPC700 instructions. I even have CPU timing events happen in the middle of individual bus cycles. All of these things take a huge toll on speed. I'm also not a very good code optimizer. Super Sleuth is a good example. Overload does much of what I do but manages about 1.5-2x the speed. That's probably a best case scenario for me.

BTW, hi PFUNK. Haven't spoken to you in years now. Good to see you're still around :)

kode54 wrote:
I will write a nice simple class that does this with WaveOut, preference on the ability to defer execution for up to one frame worth of sound, for regulating the remaining stages of the playback thread to the sound output.


Awesome, thanks for the help!

As long as it works, WaveOut is fine. Basically, in src/snes/snes_audio.cpp, look at SNES::audio_update(uint32 data). That is called once per sample (pref. 32,000 times a second for 32khz). data = the right channel in the upper 16 bits, left in the lower 16 bits.
sound_run() is a virtual function for platform-specific stuff.
Problem is that you never know how long it'll take to get there. If the last tick was between a screen redraw, it could be as much as 50ms later or somesuch... now, what I was thinking was keeping 3 buffers, when one gets full, see how long it took to fill and then stretch that buffer to that amount of time (shorten or lengthen). But what I don't understand is that since that time has already passed, what bearing does the length of the last sample have on future samples? You needed sound to run that slow during that sample that's already finished...
I also don't know how to resize the buffers without the sound being totally awful.
As for buffer size, 1/60th of a second is fine. I prefer a buffer that holds 2,000 samples or less. But because sound is so choppy, it's at 8,000 samples (1/4th second) right now >_<

Quote:
Ha? Have you even tried this thing? The accuracy is insane. bsnes handles every non-special chip game I've thrown at it to perfection.


Wild Guns is the only game I know of that fails solely to CPU emulation. As far as games with video bugs: Energy Breaker, CT black omen, Contra 3 first boss, ToP opening battle does something odd to the gradient menu when that one dude casts that sealing spell, probably more... I haven't done anything with PPU accuracy, though. That's next.
Star Trek: Deep Sleep Nine fails because that game is evil and stores a fake valid checksum where a HiROM header would usually go to screw with copiers.

I say give it another year and see where I'm at then...
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Oct 03, 2005 5:39 am Post subject:

Noxious Ninja wrote:
Why wouldn't it be a practical choice?


I think it would be a cool option as it bypasses the kmixer, and anything that does that is much appreciated by audiophiles. There are probably other advantages besides that... But, IIRC, kernel streaming has issues with certain audio cards' drivers, and isn't even supported by some. That would be a problem if it's the only output method...

byuusan wrote:

Wild Guns is the only game I know of that fails solely to CPU emulation. As far as games with video bugs: Energy Breaker, CT black omen, Contra 3 first boss, ToP opening battle does something odd to the gradient menu when that one dude casts that sealing spell, probably more... I haven't done anything with PPU accuracy, though. That's next.
Star Trek: Deep Sleep Nine fails because that game is evil and stores a fake valid checksum where a HiROM header would usually go to screw with copiers.


That black omen bug - was the one I noticed Smile That's still very good for a known buglist. I also like how simple you implimented the sound. IMO, I can't think of a reason why some emus have volume control (this is better to control via speaker knobs or system tray), filters (what use are these? they sound worse than default), and frequency changes (non-32khz doesn't make it sound any better. It only complicates things.) The useful thing is to mute/disable it altogether, which you've got. w00t for simplicity.

Boy does that logged audio data sound good. *salivates*
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Mon Oct 03, 2005 6:34 am Post subject:

byuusan wrote:
Also, do me a favor and don't try Der Langrisser. That game has some screwy sound code...


If you change the first block of code in bDSP::run to the code below, it should fix the problems with Der Langrisser. Also, you should remove the extra 'kon' variable in the Status struct and only use the real 'KON' register variable.

Code:

if(!(dsp_counter++ & 1) && status.key_flag) {
for(v=0;v<8;v++) {
uint8 vmask = 1 << v;
if(status.soft_reset()) {
if(voice[v].env_state != SILENCE) {
voice[v].env_state = SILENCE;
voice[v].AdjustEnvelope();
}
} else if(status.KOFF & vmask) {
if(voice[v].env_state != SILENCE && voice[v].env_state != RELEASE) {
voice[v].env_state = RELEASE;
voice[v].AdjustEnvelope();
}
} else if(status.KON & vmask) {
status.KON &= ~vmask;
status.ENDX &= ~vmask;
voice[v].brr_ptr = read_16((status.DIR << 8) + (voice[v].SRCN << 2));
voice[v].brr_index = -9;
voice[v].brr_looped = false;
voice[v].brr_data[0] = 0;
voice[v].brr_data[1] = 0;
voice[v].brr_data[2] = 0;
voice[v].brr_data[3] = 0;
voice[v].envx = 0;
voice[v].env_state = ATTACK;
voice[v].AdjustEnvelope();
}
}
status.key_flag = false;
}
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Oct 03, 2005 9:36 am Post subject:

I found kon odd, too. I asked anomie about this (remember, my DSP code is a port of his)... he said that he clears kon but leaves KON with the old value because the DSP will read back the last value written to KON, but internally the key on flag is cleared so that the channel doesn't continuously get keyed on...

Still, if it fixes Der Langrisser, then that's awesome! I really appreciate the help :D
I'll try and direct anomie here.

EDIT: Indeed, it fixes it perfectly. And breaks no other games at that. Awesome. DL is my second favorite game, and now it fully works!
http://byuu.cinnamonpirate.com/audio/bs04_dl.ogg
Sorry for the lowest quality setting on the ogg encoding.
Thanks again for the help!
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Mon Oct 03, 2005 11:09 am Post subject:

byuusan wrote:
As far as games with video bugs: Energy Breaker, CT black omen, Contra 3 first boss, ToP opening battle does something odd to the gradient menu when that one dude casts that sealing spell, probably more... I haven't done anything with PPU accuracy, though. That's next.

*whispers: "Super Aleste !!"*

No, really. Stage 5 must be some kind of hellcode.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
anomie
Lurker


Joined: 07 Dec 2004
Posts: 168

Posted: Mon Oct 03, 2005 12:41 pm Post subject:

FitzRoy wrote:
and frequency changes (non-32khz doesn't make it sound any better. It only complicates things.)

OTOH, some systems don't support 32000Hz (actually, based on our tests ~32060Hz is more likely). Frequency change is actually pretty simple compared to the calculations needed to handle over or underrun.

DMV27 wrote:
If you change the first block of code in bDSP::run to the code below, it should fix the problems with Der Langrisser. Also, you should remove the extra 'kon' variable in the Status struct and only use the real 'KON' register variable.

The thing is, when you read $4C (KON) you always get back the last value written. I've just re-verified this, in case i had been mistaken, and it still holds true.

Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Code:
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0


Can you show me the code in Der Langrisser that is 'fixed' by this behavior?
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Oct 03, 2005 5:06 pm Post subject:

grinvader wrote:

*whispers: "Super Aleste !!"*

No, really. Stage 5 must be some kind of hellcode.


I love that game. I remember that stage, too. I think it's the one with the planets that change sizes to destroy you. Lemme guess - they're invisible? Laughing That's the way it was on zsnes last time I played it. Had to disable a few layers to pass the stage. Ahh, memories...
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Mon Oct 03, 2005 5:19 pm Post subject:

byuusan wrote:
Sorry for the lowest quality setting on the ogg encoding.


Noxious Ninja wrote:
Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache.

_________________
#577451
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Mon Oct 03, 2005 8:29 pm Post subject:

FitzRoy wrote:
grinvader wrote:

*whispers: "Super Aleste !!"*

No, really. Stage 5 must be some kind of hellcode.


I love that game. I remember that stage, too. I think it's the one with the planets that change sizes to destroy you. Lemme guess - they're invisible? :lol: That's the way it was on zsnes last time I played it. Had to disable a few layers to pass the stage. Ahh, memories...

RONG - that's stage 4, and neither bsnes nor zsnes have any trouble with the warped transforming green background or the growing rocks.

Stage 5 is the cavern with the underground river flowing using weird-ass scrolling code.
bsnes is very close to it, the effect is just off by a couple tiles on the left but always on.
zsnes... well, it does it right for 2 seconds, then it stops scrolling, then it resumes... and so on.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Oct 03, 2005 9:17 pm Post subject:

anomie wrote:
Can you show me the code in Der Langrisser that is 'fixed' by this behavior?


I hope DMV27 can, because I sure can't... the problem is that the code runs fine either way, it just sounds like notes are being missed / keyed off too quickly in-game.

The best I can probably do... is set a breakpoint for the intro for the first $4C read, and just log a bunch of code. Then do the same with the old code, and see what comes up.

Actually... now that I'm looking at it... I think I see the problem.

Right now, it's an if(soft_reset)/else if(KOFF)/else if(KON){} kon=0;
So kon can get cleared if a KOFF bit was set.
I would imagine kon should only be cleared inside the else if(KON){...} block. Of course, if the KOFF bit were set, that would still release the channel, but after KOFF was cleared, it would then process the KON event, right?
Clearing the ENDX bits was also moved inside the if(KON){...} block, but I doubt that would matter much...

"Konnnnnnnnnnnnnnnn!!! ..... Konnnnnnnnnnnnnn!!"

Quote:
Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache.


Meh... I doubt they'd want to host a 21MB wav, and I don't mind hosting a 1mb OGG... eh. I'll look into it eventually. Thanks.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Oct 03, 2005 10:27 pm Post subject:

grinvader wrote:

RONG - that's stage 4, and neither bsnes nor zsnes have any trouble with the warped transforming green background or the growing rocks.


Gruuuu... snes knowledge... failing....
PFUNK
Lurker


Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA

Posted: Mon Oct 03, 2005 10:50 pm Post subject:

byuusan wrote:

I'm used to hearing it runs too slow, especially on laptops. Speed throttling isn't added yet (because I can't get >=60fps to test it on my machine...), but when it is -- if you're getting over 60fps then it won't consume all of your idle CPU time anymore. But it'll still consume probably 5-10x the CPU usage that ZSNES does.


If it's of any relevance, I'm running bsnes on a new laptop:

Centrino, 2.13 gHz
1.0 GB RAM
XP SP2
ATI X700 Mobility

In Super Mario World, I get around 76 FPS, in Megaman X around 79. If you need any more info. like that, just PM me.
_________________
I'm hot for you and you're hot for me ooka dooka dicka dee.
anomie
Lurker


Joined: 07 Dec 2004
Posts: 168

Posted: Mon Oct 03, 2005 10:57 pm Post subject:

byuusan wrote:
The best I can probably do... is set a breakpoint for the intro for the first $4C read, and just log a bunch of code. Then do the same with the old code, and see what comes up.

That could work. Or if you can get an SPC that does the same thing (for me to plug into my SPC player), that would be even better.

Quote:
Right now, it's an if(soft_reset)/else if(KOFF)/else if(KON){} kon=0;
So kon can get cleared if a KOFF bit was set.
I would imagine kon should only be cleared inside the else if(KON){...} block. Of course, if the KOFF bit were set, that would still release the channel, but after KOFF was cleared, it would then process the KON event, right?


anomie wrote:
Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Code:
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0

I've just re-verified this. Note that if the wait is less than 2 samples, the KOFF=0 could happen before the KON=1 is processed and therefore actually play a sound (there's at least one game that does this).
kode54
Veteran


Joined: 28 Jul 2004
Posts: 789

Posted: Tue Oct 04, 2005 1:33 am Post subject:

Resampling may be a necessity for Linux systems, if their hardware doesn't support 32000Hz, and if the user isn't running a transparent mixer/resampler output, such as OSS.

On the other hand, on Windows systems, you won't need to worry about that as long as the user is either running Windows NT (2000/XP/2003) or using Windows 98 SE or newer with WDM sound drivers. In that case, you get free software mixing and resampling, thanks to the kernel mixer.

Ideally, you can use both SDL display and sound output, regulating your emulation to the demands of the sound callback. Then to smooth out the frame display, you also synchronize frame display to the vertical refresh. The problem with that, at least on Windows, is that the IDIRECTDRAW7::WaitForVerticalRefresh function appears to do polling in most cases, hogging the CPU a great deal.

I found a nice solution which I may be able to port into SDL, so you'll get the best of both worlds without having to worry about portability issues, unless vertical refresh handling is just as bad everywhere else... Although, ultimately, native frontends with platform specialization will probably be a more optimal solution, assuming you can find porters who want to do even more work, and you'd still be stuck if they ever quit updating.

I have added my speed-regulating WaveOut sound code and modified the DirectDraw video code to use multimedia timer polling and event trigger locking for the vertical refresh synchronization, since DDraw seems to be using disgusting CPU hogging busy wait polling even now.

I will also add my own input configuration system, which features full key and game controller binding, with each game controller event tied to the DirectInput device instance GUID. It will require a bit of modification to work nicely with a text-based configuration file, though. I will also need to write a function to build my dialog, since it is currently a dialog template, normally built into a window at runtime with DialogBoxParam.

Here you go. [binary] [source patch] [Last updated: 2005-10-03 20:28 PDT]

The above noted accuracy changes have not been integrated, yet. I will wait for a version which integrates the above before making another source patch, unless my changes are integrated into the main sources.

Notes:
  • I see no cleanup code to delete so many random class instances on program shutdown, will that be handled eventually? Razz
  • I modified the Makefile for MSVC 8 LTCG, last used in the optimize stage. Just remove the LDFlags bits, or use the Visual Studio 2005 Express compiler toolkit to do the building. ( Express doesn't include the resource compiler, though, but you only use that for the controller art. )
  • Sound output was moved to the video_run function, so output may be used for frame rate regulation. An extra function was added to snes_audio to reset the buffer position.
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Tue Oct 04, 2005 5:54 am Post subject:

anomie wrote:
That could work. Or if you can get an SPC that does the same thing (for me to plug into my SPC player), that would be even better.

Der Langrisser SPC Soundtrack

Quote:
Can you show me the code in Der Langrisser that is 'fixed' by this behavior?

I only traced writes to KON and KOFF. BSNES crashes on my computer, so I couldn't use it to do any code tracing.

Quote:
anomie wrote:
Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Code:
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0

I've just re-verified this. Note that if the wait is less than 2 samples, the KOFF=0 could happen before the KON=1 is processed and therefore actually play a sound (there's at least one game that does this).


Der Langrisser does this (also see the event log below):
KOFF = 1
(wait until ENVX is zero)
(wait about 42 more samples)
KON = 1
KOFF = 0

Maybe the SNES allows voices stuck in RELEASE mode + BRR loop to be keyed on? Or maybe Der Langrisser requires cycle accurate DSP timing?

Code:
// Format
event: voice, sample number
info: voice, envx, release time (samples)

// Intro Music
write koff: 08, 236922
run koff: 08, 236924
koff envx: 08, 0.425989, 109.00
write kon : 08, 237074
write koff: 00, 237074
run kon : 08, 237076
kon envx: 08, 0.000000

write koff: 02, 243372
run koff: 02, 243374
koff envx: 02, 0.372252, 95.25
write kon : 02, 243510
write koff: 00, 243510
run kon : 02, 243512
kon envx: 02, 0.000000

write koff: 40, 243540
run koff: 40, 243542
koff envx: 40, 0.422081, 108.00
write kon : 40, 243691
write koff: 00, 243692
run kon : 40, 243694
kon envx: 40, 0.000000

// Player Setup Music
write koff: 04, 513509
run koff: 04, 513510
koff envx: 04, 0.941378, 240.88
write kon : 04, 513792
write koff: 00, 513792
run kon : 04, 513794
kon envx: 04, 0.000000

write koff: 01, 516018
run koff: 01, 516020
koff envx: 01, 0.980459, 250.88
write kon : 01, 516311
write koff: 00, 516312
run kon : 01, 516314
kon envx: 01, 0.000000

write koff: 08, 517860
run koff: 08, 517862
koff envx: 08, 0.980459, 250.88
write kon : 08, 518154
write koff: 00, 518154
run kon : 08, 518156
kon envx: 08, 0.000000
kode54
Veteran


Joined: 28 Jul 2004
Posts: 789

Posted: Tue Oct 04, 2005 6:50 am Post subject:

Blah @ DirectDraw vsync. I can't get consistent synchronization results relative to sound output. Triple buffering would solve everything, but the limitations suck:
  • DirectDraw: Requires fullscreen mode.
  • Direct3D: Requires D3D9 interface for vertical refresh synchronization in a window.


I'll update with a Direct3D 9 interface in a bit, and eventually work in configurable support for both renderers.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Oct 04, 2005 11:29 am Post subject:

Hm, the EXE you posted tends to crackle when it drops below 60fps, but it sounds fantastic at exactly 60fps though. Definitely a big improvement.

As for the DirectInput and D3D9... the former I've been planning to get to when I have time (I don't even have a gamepad to test with), the latter I didn't feel was necessary (and requires more recent software), but if you really think triple buffering would help, I already have a library for D3D9 that provides a DDraw-like abstraction layer I could throw in.

Again, many thanks for your help, but please keep in mind I am really busy this week and next (training for a new job), so I won't be able to really merge many of your changes until then... :/


Last edited by byuu on Tue Oct 04, 2005 11:30 am; edited 1 time in total
anomie
Lurker


Joined: 07 Dec 2004
Posts: 168

Posted: Tue Oct 04, 2005 12:18 pm Post subject:

DMV27 wrote:
Der Langrisser SPC Soundtrack

Nifty, which track is the problem?
kode54
Veteran


Joined: 28 Jul 2004
Posts: 789

Posted: Tue Oct 04, 2005 12:48 pm Post subject:

I find that even with Direct3D9, I either get cracking sound, or I get a picture that doesn't sync perfectly all of the time. There seems to be an issue with the number of samples generated and the sound output. ( Taking a running average, with NTSC, it seems to average ~31947.3 samples per second, assuming 60 frames per second. )

Needs more work...

( PS. You should be able to delete your own posts, if you check the "Delete this post." box. If that box is not present, somebody shoot the phpBB devs for allowing regular users to edit their own posts, but not delete them. )
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Tue Oct 04, 2005 1:10 pm Post subject:

kode54 wrote:
( PS. You should be able to delete your own posts, if you check the "Delete this post." box. If that box is not present, somebody shoot the phpBB devs for allowing regular users to edit their own posts, but not delete them. )


Regular users can't delete their own posts. It sucks.
_________________
#577451
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Tue Oct 04, 2005 6:33 pm Post subject:

Besides, there is no "Delete this post" box. It's a nice little letter X box next to the word "EDIT."

Editing/deleting posts is adjusted through the permissions by the admin(s), right ?
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Oct 04, 2005 9:35 pm Post subject:

Quote:
Nifty, which track is the problem?


All of them? >_<
Leon, Story, Opening 1... they all seem to be missing some of the notes in the songs.

Oh, and sorry anomie. I wasn't trying to nag you to fix this, I just thought we had the right fix for it already and all... it's definitely not a priority or anything.

Quote:
( Taking a running average, with NTSC, it seems to average ~31947.3 samples per second, assuming 60 frames per second. )


Yeah. The NTSC SNES runs at (315 / 88 * 6000000) / (1364 * 524 - 4) * 2 fps. Interlace is (315 / 88 * 6000000) / (1364 * 525) * 2 fps. Or ~60.09fps and ~59.98fps.
The SNES APU tends to vary between 32000hz (spec) and 32100hz (realistically). anomie says he gets 32060hz.
There's no way to run at 60.09 / 59.98 fps without tearing, so the only option is to resize the audio sample lengths (or change the APU speed depending on region AND interlace enable, which is extremely sloppy)...
PAL then also has to be handled. That's just 50fps.
The NTSC CPU is ~21477272hz, PAL CPU is ~21281370, APU is ~24576000hz. DSP is APU / 768 -> ~32000hz. All three CPU speeds tend to have slight variance in the real world.

Anyway, I have no checkbox for "delete this post", and no X next to edit. So yeah... I have no rights to delete my own posts. Smart.
AOL> The "delete this post" box is usually inside the edit window next to the notify on reply / disable smilies options.
Magus`
Cap'n Gin | Admin


Joined: 27 Jul 2004
Posts: 748
Location: Missouri

Posted: Tue Oct 04, 2005 10:13 pm Post subject:

adventure_of_link wrote:
Besides, there is no "Delete this post" box. It's a nice little letter X box next to the word "EDIT."

Editing/deleting posts is adjusted through the permissions by the admin(s), right ?


Yes.
anomie
Lurker


Joined: 07 Dec 2004
Posts: 168

Posted: Tue Oct 04, 2005 11:07 pm Post subject:

byuusan wrote:
All of them? >_<
Leon, Story, Opening 1... they all seem to be missing some of the notes in the songs.

Hrm... I can set the program to tell me when a KON is missed (15-30%!), but i can't actually hear many missing notes in the songs...
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Wed Oct 05, 2005 3:33 am Post subject:

That's what I thought, thanks Magus`.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Oct 07, 2005 6:03 am Post subject:

I've been super busy or I would've posted sooner, but I wanted to comment on Kode's post. Basically, replace the .012 exe with the one he patched, and bsnes will become fully playable (if your comp is fast enough)! The fps will cap at 60fps and the sound no longer cuts out. I enjoyed some games tonight on bsnes for the first time. Nice job on the buffering! Very Happy
kode54
Veteran


Joined: 28 Jul 2004
Posts: 789

Posted: Sat Oct 08, 2005 12:20 pm Post subject:

It buffered all the same before, but now it only outputs sound every frame, so it can regulate emulation by sound output more smoothly. If that's not enough, there's also vsync, so you can see how much the sound / vsync regulation needs more work... ( Adjusting the sample rate, resampling, full frame rate conversion, whatever... Hmm... )
kieran_
Mugwump


Joined: 30 Jul 2004
Posts: 2966

Posted: Tue Oct 11, 2005 1:33 pm Post subject:

Congrats on the emu, byuu.
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Mon Oct 17, 2005 8:45 am Post subject:

After playing some time in the 1024x768 mode, 4:3 is now my preferred ratio. Smile

Well, on systems that don't produce scaling artefacts.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Oct 19, 2005 4:59 am Post subject:

Ooo, more updates from byuu. Squashing some more bugs, I see. Did you ever figure out those "kon" issues with der langrisser btw?
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Oct 20, 2005 8:04 pm Post subject:

FitzRoy wrote:
Ooo, more updates from byuu.


Yes, more Bsnes goodness:



Quote:
Lastly, I finally feel that the accuracy of the emulator is good enough to block VRAM writes outside of vblank. This means a few fan-translated games that won't run on hardware will no longer work in bsnes.


Nice to see Bsnes won't compromise on accuracy. Screw the translations that depends on emulator innacuracies (my opinion)
taezou
New Member


Joined: 13 Oct 2004
Posts: 4

Posted: Sat Oct 22, 2005 8:13 pm Post subject:

I was playing with bsnes, and I noticed a somewhat minor graphical error in Tetris Attack. As the blocks scroll, the top graphic that forms the top border around the block area moves up with the blocks. It is more noticable if you use L/R to make the blocks scroll up faster.

It is not that important; I just thought I would mention it.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Oct 23, 2005 5:14 am Post subject:

Byuu said he was planning to work on PPU accuracy soon, so I'd wait for that.

On another note, I hooked up my usb gamepad finally today. Couldn't get it to work in bsnes, though Sad
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Oct 23, 2005 12:23 pm Post subject:

Quote:
4:3 is now my preferred ratio.

The best example I've seen to date is in the Chrono Trigger intro. The top of (Magus'?) tower has that big moon. It looks terrible at 16:15, but actually looks circular at 4:3.
Langrisser's character portraits also improve a lot. They become square rather than rectangles.

Quote:
Did you ever figure out those "kon" issues with der langrisser btw?

Nope.

Quote:
I was playing with bsnes, and I noticed a somewhat minor graphical error in Tetris Attack.

It's probably more offset-per-tile problems. Those are really getting on my nerves. I can't reproduce them myself no matter what I do, so they're difficult to fix.

Quote:
On another note, I hooked up my usb gamepad finally today. Couldn't get it to work in bsnes, though

No joypad support. Use a joypad -> windows key mapping program. I don't know the names of any, but they do exist.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Oct 23, 2005 10:06 pm Post subject:

Ah, sweet thanks. After some searching, I found a simple program called JoystickCursorTool that does the job fine at under 100kb. I had to mess with the timings a bit (changed to 15/500/15) to get my hadoukens to work in street fighter, but all is well now.

Still can't use bsnes when a friend comes over, though. Wink
Metatron
Deus ex Machina


Joined: 28 Jul 2004
Posts: 1323

Posted: Sun Oct 23, 2005 10:33 pm Post subject:

byuusan wrote:

No joypad support. Use a joypad -> windows key mapping program. I don't know the names of any, but they do exist.


Will there ever be joypad support? I tend to shy away from an emulator that doesn't do it by itself...
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Oct 24, 2005 12:47 am Post subject:

Sure, as soon as someone buys me a gamepad to test with.
(Seriously, I don't accept donations for a hobby. Wait a month or two until I can afford to throw money away on one.)
badinsults
"Your thread will be crushed."


Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg

Posted: Mon Oct 24, 2005 1:23 am Post subject:

byuusan wrote:
Sure, as soon as someone buys me a gamepad to test with.
(Seriously, I don't accept donations for a hobby. Wait a month or two until I can afford to throw money away on one.)


Just ask Lik Sang for a Super Smartjoy. Considering you are a snes emulator author, I'm sure they will give you one for free. Hell, they even gave one to me.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Oct 24, 2005 5:43 pm Post subject:

.013 is out! More accuracy changes, and joystick 2 is now present (thanks)! Kode's fps capping has not made it into this version, however, so I guess stick with .012 if you want to play games. Or just start winking at kode for a patched exe.

Wink
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Oct 24, 2005 8:24 pm Post subject:

No, the new version doesn't have kode54's changes, sorry. I've been putting a lot of work into other things (see changelog) and haven't had the time.
It'll probably be in there by the next release.
GIGO shared the code he uses to buffer sound through DirectSound, so I'll probably come up with a happy medium between the two. I don't know... I'm considering rewriting the Win32 specific code, just because it's a mess.

Oh, and I really need to get MSVC8 or whatever. kode's build is a good 30% faster than mine...
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Oct 24, 2005 8:31 pm Post subject:

If you don't plan on asking Lik-Sang for the Super SmartJoy, I could order you a gamepad of your choice. Let me know.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
p00f
Lurker


Joined: 17 Sep 2005
Posts: 186

Posted: Mon Oct 24, 2005 8:32 pm Post subject:

I'll donate you a gamepad if needed as well.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Oct 26, 2005 12:43 pm Post subject:

taezou wrote:
I was playing with bsnes, and I noticed a somewhat minor graphical error in Tetris Attack. As the blocks scroll, the top graphic that forms the top border around the block area moves up with the blocks. It is more noticable if you use L/R to make the blocks scroll up faster.

It is not that important; I just thought I would mention it.


Thanks, this is fixed now. It was due to offset per tile mode being incorrect. It'll be in the next public release.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Oct 26, 2005 5:01 pm Post subject:

sweetsweetsweetsweetsweet

Next version is gonna rock.
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Wed Oct 26, 2005 11:15 pm Post subject:

Now all this emulator needs is zip file support. Though I can understand if that's not a priority now. Smile

It's just that when I use bsnes with my QuickPlay frontend, zip files won't work. Confused

Excellent work on the emulator so far. Smile
kieran_
Mugwump


Joined: 30 Jul 2004
Posts: 2966

Posted: Thu Oct 27, 2005 10:26 am Post subject:

Holy Shit... your emu really kills my pc! I have a Sempron 2800, 512mb ram, with a Radeon 9200. FFVI was only getting about 30 or 40 frames per second! Has anyone achieved full speed at any setting?
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Thu Oct 27, 2005 11:10 am Post subject:

Kieran wrote:
Holy Shit... your emu really kills my pc! I have a Sempron 2800, 512mb ram, with a Radeon 9200. FFVI was only getting about 30 or 40 frames per second! Has anyone achieved full speed at any setting?

Some crazy dude runs bsnes 60/60 with hq4x... on a MAC.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Thu Oct 27, 2005 12:38 pm Post subject:

Kieran wrote:
Holy Shit... your emu really kills my pc! I have a Sempron 2800, 512mb ram, with a Radeon 9200. FFVI was only getting about 30 or 40 frames per second! Has anyone achieved full speed at any setting?


Yep, I have, using bsnes 0.12 with my home PC using either windowed or 10x7 fullscreen (4:3) stretch. With kode54's changes, it remains at fairly steady 60fps for most games.

I've yet to try the very latest bsnes at home, but on the [P4 2.4GHz+Intel Extreme2 graphics] workstation I'm on now with the 0.13 version, it achieves ~55fps with most games. I'm getting much higher numbers with FFVI (ie. 60fps or greater) with this workstation than 30-40. I would have thought that a Sempron would achieve higher numbers than this P4.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Oct 27, 2005 12:57 pm Post subject:

kode54's build is 20+% faster than mine because he used profile guided optimizations in his build. A feature my compiler lacks.
The difference is very noticeable when your PC can't reach 60fps to begin with. Anyway, v0.014 will likely be a good bit faster than v0.013... hopefully.
I'm planning to rewrite the Win32 UI and make separate builds for the debugger-enabled and non-debugger-enabled, non-virtual class versions (the latter would run faster).
I also plan to add P4 + Athlon (/G7) optimizations. It'll make it run a bit slower on older processors, but hell, not like they're getting playable framerates anyway. A good 5+% there as well.

I get ~50fps on a 1.67ghz Athlon, myself.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Thu Oct 27, 2005 1:14 pm Post subject:

30 FPS on first-gen p4 1.8GHz.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Fri Oct 28, 2005 4:27 am Post subject:

It would be nice to have an option to play at 256x240 with fullscreen. ; )
SquareHead
Seen it all


Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box

Posted: Fri Oct 28, 2005 4:42 am Post subject:

grinvader wrote:
Kieran wrote:
Holy Shit... your emu really kills my pc! I have a Sempron 2800, 512mb ram, with a Radeon 9200. FFVI was only getting about 30 or 40 frames per second! Has anyone achieved full speed at any setting?

Some crazy dude runs bsnes 60/60 with hq4x... on a MAC.


Most Mac's have 64 bit CPU's in em since the power pc days. Would that have anything to do with it?
_________________
My boring Site
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Oct 28, 2005 12:05 pm Post subject:

Having a second 2.5ghz CPU dedicated to performing the HQ4x scaling and an OpenGL hardware accelerated video card to perform the bilinear filtering / TV curve effect would.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Oct 28, 2005 1:30 pm Post subject:

Quote:
It would be nice to have an option to play at 256x240 with fullscreen. ; )


Ugh.. your obesession with adding a resolution/feature which inheritedly limits certain games to display properly and in which case you will most likely never use is.. stupidifying...
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Fri Oct 28, 2005 3:17 pm Post subject:

vigi_lante wrote:
It would be nice to have an option to play at 256x240 with fullscreen. ; )


vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Fri Oct 28, 2005 3:18 pm Post subject:

Quote:
Ugh.. your obesession with adding a resolution/feature which inheritedly limits certain games to display properly and in which case you will most likely never use is.. stupidifying...


If 256x240 is the original SNES hardware resolution, I think it's a valid suggestion. This and 512x480 for hi-res games.

Btw, since I bought an ArcadeVGA (www.ultimarc.com), finally I dont need to mess with a lot of unstable solutions to get a working 15khz picture. So, everything is working for me now.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Fri Oct 28, 2005 3:37 pm Post subject:

vigi_lante wrote:
If 256x240 is the original SNES hardware resolution, I think it's a valid suggestion. This and 512x480 for hi-res games.

256x224 for lowres NTSC, x238 for lowres PAL. Twice for each hires mode (Hx2 / Vx2 / Hx2+Vx2).

Since games suddenly start using a hires bg layer (and all the rest still lowres - see SD3 and similar), you cannot try and adjust the res on the fly, that would just make your screen flash back and fro.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Oct 28, 2005 3:43 pm Post subject:



It's nice to see some text look like a blur.

Speaking of hires, why doesn't ZSNES take "bigger pics" (512x480) when hires is used?
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Fri Oct 28, 2005 3:48 pm Post subject:

Text blurrienss in that one is partially due to the fact that Woolsey is an idiot.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Fri Oct 28, 2005 3:48 pm Post subject:

The screenshot code doesn't check for it and uses the lowres (old graphic engine) buffer.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
Metatron
Deus ex Machina


Joined: 28 Jul 2004
Posts: 1323

Posted: Fri Oct 28, 2005 4:02 pm Post subject:

Aerdan wrote:
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot.


I doubt he programmed that screen or picked out the font... Unless you're talking about something else.

I never had problems reading it, and my vision is terrible. So eh.

PS: Hating Woolsey is not cool.
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Fri Oct 28, 2005 4:06 pm Post subject:

Metatron wrote:
Aerdan wrote:
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot.


I doubt he programmed that screen or picked out the font... Unless you're talking about something else.

PS: Hating Woolsey is not cool.
He hardly deserves the title 'translator', particularly given he was simply 'head translator' at the time and didn't actually do much in the way of translation, I'm told.

I'll hate on him if I want to. And don't listen to Tomato, he's an elitist asshole if ever there were elitist assholes. :p
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Fri Oct 28, 2005 4:07 pm Post subject:

Quote:
256x224 for lowres NTSC, x238 for lowres PAL. Twice for each hires mode (Hx2 / Vx2 / Hx2+Vx2).


Taking NTSC as a example...

A normal SNES runs at 256x240. People usually say 224 because the remaining lines are often not visible on a TV screen.

224 comes from the fact that you can usually only see about 224 lines on your TV, but the SNES is really drawing 240 lines every frame. (the same goes for any NTSC device)
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Oct 28, 2005 4:30 pm Post subject:

vigi_lante wrote:
A normal SNES runs at 256x240. People usually say 224 because the remaining lines are often not visible on a TV screen.

224 comes from the fact that you can usually only see about 224 lines on your TV, but the SNES is really drawing 240 lines every frame. (the same goes for any NTSC device)

Are you actually ARGUING with the people who emulate this piece of hardware?

If the SNES really rendered 240 vertical lines (with stuff on them), I imagine they'd be emulated and viewable in at least some emulators.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Metatron
Deus ex Machina


Joined: 28 Jul 2004
Posts: 1323

Posted: Fri Oct 28, 2005 4:31 pm Post subject:

Aerdan wrote:
Metatron wrote:
Aerdan wrote:
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot.


I doubt he programmed that screen or picked out the font... Unless you're talking about something else.

PS: Hating Woolsey is not cool.
He hardly deserves the title 'translator', particularly given he was simply 'head translator' at the time and didn't actually do much in the way of translation, I'm told.

I'll hate on him if I want to. And don't listen to Tomato, he's an elitist asshole if ever there were elitist assholes. :p


1: So I ask... What does the screen have to do with Woolsey?

2: There's no real reason to attribute relevance to anything you have to say without contextual evidence...
Tomato
Hazed


Joined: 10 Aug 2004
Posts: 73

Posted: Fri Oct 28, 2005 4:46 pm Post subject:

I don't really wanna turn this thread into an argument about Woolsey (which has nothing to do with bsnes) but I felt I should at least post this link:

http://smc.smallcave.net/woolsey/mcgrath.php

If translating something doesn't make one a translator, then bleh :/
Metatron
Deus ex Machina


Joined: 28 Jul 2004
Posts: 1323

Posted: Fri Oct 28, 2005 4:47 pm Post subject:

Disclaimer: I did not mention this thread to Tomato. Just a note.
Tomato
Hazed


Joined: 10 Aug 2004
Posts: 73

Posted: Fri Oct 28, 2005 4:54 pm Post subject:

Nah, I watch this thread all the time and the dev board all the time. byuu's work is awesome Very Happy
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Oct 28, 2005 6:38 pm Post subject:

Quote:
If the SNES really rendered 240 vertical lines (with stuff on them), I imagine they'd be emulated and viewable in at least some emulators.


That's not even the point.. if there even was stuff rendered there and not viewable by the TV.. then why even render it? (I'm not saying it wouldn't be interesting to see what could be there, but the majority of people wouldn't want it because it wasn't what they normally saw)

Quote:
Are you actually ARGUING with the people who emulate this piece of hardware?


He's completely lost... there's almost no hope for reasoning at this point..

Quote:
The screenshot code doesn't check for it and uses the lowres (old graphic engine) buffer.


Well, wouldn't it be an idea to change that to support hires? I forgot to suggest it in my reply.

I wasn't trying to derail this thread further... but in any case.. it's a very different emulator.. hopefully this will lead to a more perfect emulation that we currently have...
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Oct 28, 2005 7:02 pm Post subject:

Yes, the SNES is 256x224. You can make it 256x239 (not x240), but the scanlines are only visible on PAL televisions (possibly? I don't have a PAL TV so I can't tell). On NTSC, half the scanlines get chopped from the top and half from the bottom in this mode.

I doubt many video cards support bizarre resolutions such as 512x448. Basically, I'm planning to add a custom video mode option eventually where the user can type in any resolution they want. If the hardware supports it, they can use it. The image will then use bilinear filtering to scale to either 8:7 or 4:3, and center the image for the former.

Quote:
Since games suddenly start using a hires bg layer (and all the rest still lowres - see SD3 and similar), you cannot try and adjust the res on the fly, that would just make your screen flash back and fro.

Yep. Huge problem, no easy solution.

Quote:
Speaking of hires, why doesn't ZSNES take "bigger pics" (512x480) when hires is used?

How would you take a picture of just interlace or just hires? (256x448 or 512x224) -- keep in mind things like video filter, etc. The image sent to the card could very well be 512x224, and stretched in hardware.
The image would look skewed to hell if you dumped just like that (and that's what I do). I figure, the user can just resize the image to whatever they like from there.

Quote:
Nah, I watch this thread all the time and the dev board all the time. byuu's work is awesome

' 'è'ª'Æ'¤'²'´'¢'Ü'·Aƒgƒ}ƒg'³'ñ :D
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Oct 28, 2005 7:30 pm Post subject:

Quote:
How would you take a picture of just interlace or just hires?


I just meant the game in hires (isn't interlace just a TV/old monitor thing?). It seems kinda pointless to take a picture that is in hires mode to only come out lowres.. (I'm not talking about printscreen and resolution, I'm talking about the internal screenshot feature in ZSNES as rendered w/o filters).

In other words.. when I take a snapshot (using the snapshot feature within ZSNES and not printscreen) of a hires game (such as Secret of Mana).. I should get a picture (whatever the size it should be) that matches what I get on the screen (w/o the filters).
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Sat Oct 29, 2005 4:14 pm Post subject:

I thought that with SNES, like MegaDrive, the x224 modes are configured with top-bottom borders to add to the total number of lines. This is necessary to keep below the 60Hz vertical scan limit.

Quote:
That's not even the point.. if there even was stuff rendered there and not viewable by the TV.. then why even render it?


This is true with NES. The not viewable part is usually screen garbage. Since playing NES and SNES, with the same resolution (256x240 - using Snes9x), I get a 100% fullscreen picture on my TV, with no stretch, I thought both shared almost the same way to output video.

But then, there is another question: Why fullscreen with SNES, using 256x240, with no stretch ? The same thing happens using SNES emulator for PS2: since PS2 support 256x240, you have a perfect fullscreen picture, no stretched, just like a real SNES (I know this emulator sux, but I'm just talking about the picture).

Quote:
Basically, I'm planning to add a custom video mode option eventually where the user can type in any resolution they want. If the hardware supports it, they can use it.


You could do something exactly like Snes9x: if the resolution is available, you can select it.


Last edited by vigi_lante on Sat Oct 29, 2005 5:16 pm; edited 2 times in total
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Sat Oct 29, 2005 4:25 pm Post subject:

More recent video cards support custom resolution input, which allows for 512x448--I was able to get 512x448 in Windows once this way. Unfortunately, however, it didn't want to let me use that resolution for ZSNES. *sigh*
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Sat Oct 29, 2005 6:46 pm Post subject:

I just tried bsnes. It's looking good so far. You've come a long way byuu, congrats.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 01, 2005 4:11 am Post subject:

Quote:
More recent video cards support custom resolution input, which allows for 512x448


I guarantee it's just the video card scaling the image automatically, and selecting the next highest resolution. I've always wondered why older cards didn't allow that for gaming modes (DDraw, etc., not the Win desktop).
I don't see the point, but I guess you could do that. Try with 640x479, it will either double up a line, or more likely, blur the image despite only missing one line of pixels.

Quote:
I just tried bsnes. It's looking good so far. You've come a long way byuu, congrats.


Thank you, your opinion means a lot.
Nightcrawler
Romhacking God


Joined: 28 Jul 2004
Posts: 1899

Posted: Tue Nov 01, 2005 2:01 pm Post subject:

Too bad there weren't alot of girls interested in emulation, Byuu would be a chick magnet! He'd be getting all the girls! They'd want to try out his Procreation Emulation techniques! Laughing
_________________
TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
ROMhacking.net - The central hub of the ROM hacking community.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Tue Nov 01, 2005 4:52 pm Post subject:

Maybe he already HAS a girl, who DOES dig his l33t skillz.

Hey byuu, get your girlfriend to sign up on the board!
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Wed Nov 02, 2005 12:03 am Post subject:

ArcadeVGA does (true) 512x448.

I think the best way would do something like Snake did with Kega Fusion...

http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=40418&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1121281319

You just write what kind of resolution you want to use for each game that have a specific resolution, and it will automatically change your resolution, according to what the game displays. And the resolution change process also is very smooth.

By the way, the vertical x224 resolution of SNES output signal are actually still 240 lines, with blank borders which make up the difference from, for example 224 lines to 240. This is because TVs cannot display resolutions lower than 240 lines.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Nov 02, 2005 1:57 am Post subject:

I'm confused by this whole resolution thing. If the higher one were to be implimented, and it were stretched to fill a 4:3 screen, would we then have black bars around the whole image? Or is there actual picture data that bsnes could gain from this "more accurate" res?
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Nov 02, 2005 2:35 am Post subject:

No, not around the whole thing. Just on the top and bottom. Apparently, the difference is (240-224)=16. So, I assume 16 split between the top and bottom, so a whopping total of 8 lines above and below the image.

Apparently some PAL games have output on 15 of those 16 lines? I get the sense that there would be no additional output for any NTSC games.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Wed Nov 02, 2005 9:43 am Post subject:

vigi_lante wrote:
By the way, the vertical x224 resolution of SNES output signal are actually still 240 lines, with blank borders which make up the difference from, for example 224 lines to 240. This is because TVs cannot display resolutions lower than 240 lines.

This is the last thing I'll say to you, since you're camping on your stupid.

ANALOG STRETCH

Moron.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Wed Nov 02, 2005 2:10 pm Post subject:

A took a look at what wikipedia has to say

http://en.wikipedia.org/wiki/Super_Famicom

I guess this is more or less correct:

Quote:
Resolution: between 256x224 and 512x448. Most games used 256x224, 320x224, 512x224 pixels since higher resoulutions caused slowdown, flicker, and/or had increased limitations on layers and colors (due to memory bandwidth constraints); the higher resolutions were used for less processor-intensive games, in-game menus, text, and high resolution images.


In any case, I don't seem to understand vigi_lante's obsession with his "info" especially when even as little I know about TVs.. I know they stretch the image.. for sure on my REAL SNES (which, perhaps vigi_lante has never owned one).
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Wed Nov 02, 2005 6:55 pm Post subject:

Of course SNES stretch the picture, that's because SNES resolution is not 4:3. But the aspect ratio would still be correct, since developers made their games thinking about that.

What I'm saying is that doesnt matter if you run with 256x224 or x240 because in the end you gonna still have the samething.


And it's not necessary to be so rude. I'm treating everyone with respect. If you cant control yourself, just ignore me.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Wed Nov 02, 2005 8:07 pm Post subject:

Quote:
And it's not necessary to be so rude. I'm treating everyone with respect. If you cant control yourself, just ignore me.


I wouldn't be testing grinvader.. he has control - ignoring you to him could just be a ban for all that matters. You might want to rethink that.
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Wed Nov 02, 2005 10:11 pm Post subject:

At this point, I dont care...

Everytime I post something, that "Aerdan" appears, saying "shut the fuck up, it's stupid etc" (at least he deleted a post on kode54 topic). But this kind of people I just ignore, it's not even worth...

"grinvader", in contrast, looks a nice person. That's why I didnt expected this from him.

But, if things here are really like this. It would be a favour for both of us.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Wed Nov 02, 2005 10:49 pm Post subject:

Quote:
Everytime I post something, that "Aerdan" appears, saying "shut the fuck up, it's stupid etc" (at least he deleted a post on kode54 topic). But this kind of people I just ignore, it's not even worth...


Well, one important factor is that Aerdan is a dev.

Quote:
But, if things here are really like this. It would be a favour for both of us.


I'm just pretty annoyed that for the majority of your posts are in the same direction.

Let me show what you are posting:

"Please, add these resolutions that are not part of the the SNES resolutions."

256x240 doesn't make sense, since the minimum SNES res is 256x224, which is already implemented in the major SNES emulators.

"Please, add the option to select color depth."

This is not really important to the functionality of the emulator, since the requirement is at least 16-bit color depth (for transparancies).

"Please implement specific feature so my 3rd party application will work properly/better"

It is always up to the devs to want to do. Frankly it is not of particular importance to implement something for another app unless the dev has a stake in that application. (In other words, if a dev preferred using that app, he would assist in coding ZSNES or whatever emu to make it work for that app).

Well people AND the DEVS tell you that your feature is NOT important/useful/a priority/whatever, and continue this track of mind when posting to the other emu authors (especially on this board), you're going to be flamed. If you stop this track of mind, perhaps people wouldn't go out of their way to tell you to shut up.

I'm being nice to you about this. Just consider what I'm talking about.
vigi_lante
Hazed


Joined: 15 Nov 2004
Posts: 65

Posted: Thu Nov 03, 2005 12:00 am Post subject:

Those things were just suggestions. There is a forum just for this, you can't expect to agree with all suggestions.

Quote:
256x240 doesn't make sense, since the minimum SNES res is 256x224, which is already implemented in the major SNES emulators.


Today, the only way you can play a emulator on your TV, with a picture just like the real SNES, is through a video card called ArcadeVGA. It's becoming widespread, a few developers already support it, so I thought it would be nice to suggest an option to select 256x240, since people here are concerned about emulation accuracy, maybe "picture accuracy" would be a good idea. By the way, 256x240 is a built resolution for ArcadeVGA, so you cant use it with 256x224.

Actually, it's not something I really really want. I just suggested this because I saw a few people asking if it was possible to use ZSNES with ArcadeVGA, for example.

Right now I'm using Snes9x, and I can't tell the difference between ZSNES. The only problem I have with Snes9x is because I cant use it with Mamewah front-end. That's all.

It was just a suggestion. You guys are making a scandal for nothing.


Last edited by vigi_lante on Thu Nov 03, 2005 12:08 am; edited 3 times in total
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Thu Nov 03, 2005 12:04 am Post subject:

Deathlike2, quit feeding the troll.

vigi_lante: Go to jail. Go directly to jail. Do not pass Go, do not collect $200.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Nov 03, 2005 1:04 am Post subject:

Now, don't go and start fighting again and getting a good thread locked. Major changes shouldn't even be requested at this point anyway.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Thu Nov 03, 2005 1:30 am Post subject:

Quote:
Now, don't go and start fighting again and getting a good thread locked.


I'll just play the ignorance is bliss card. It's not worth seeing what he says.

Quote:
Major changes shouldn't even be requested at this point anyway.


Yea.. especially when a game like Castlevania: Dracula X has so many issues with BSNES that it needs work... like transparacy, proper layering syncing sound, less sound garbage.. it would be great Wink

But in seriousness, it is something to watch as it develops.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Nov 03, 2005 1:35 am Post subject:

vigi_lante wrote:
Today, the only way you can play a emulator on your TV, with a picture just like the real SNES, is through a video card called ArcadeVGA.

I can use the S-Video out on my laptop.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Reznor007
Regular


Joined: 30 Jul 2004
Posts: 229

Posted: Thu Nov 03, 2005 2:06 am Post subject:

Jipcy wrote:
vigi_lante wrote:
Today, the only way you can play a emulator on your TV, with a picture just like the real SNES, is through a video card called ArcadeVGA.

I can use the S-Video out on my laptop.


That's not the same though. That's whatever your computer resolution is processed through a TV encoder chip. The ArcadeVGA actually recreates the exact resolution/refresh used by older consoles and arcade boards. This is what it was designed for.

So yes, you can use TV out to get emulated SNES on TV, but it's not exactly the same as the SNES.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Nov 03, 2005 2:12 am Post subject:

Quote:
Yea.. especially when a game like Castlevania: Dracula X has so many issues with BSNES that it needs work... like transparacy, proper layering syncing sound, less sound garbage.. it would be great


I'm not aware of transparency or layering problems in this game.
The sound problems have been explained a few times. When I can actually get a solid 60fps to test with, I'll merge kode54's changes to bsnes.

Edit: Well, nevermind. Yeah, the first level... huh. I'll look into it.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Nov 03, 2005 10:46 pm Post subject:

I'm looking forward to a new release, especially knowing the following:

byuu wrote:
Most importantly, I received my copy of Visual Studio 2005 Pro, so now I can use profile guided optimizations on bsnes. This will give the emulator a 10-20% speed increase, depending on the game. I'll only be using this feature on final builds, and not WIP versions, as it takes significantly longer to compile this way.

Next, to speed things up some more, I added #ifdefs around all of the debugging functions inside the core. That means a Windows port can now be compiled with no debugging extensions, which gives a nominal ~10% speed increase as well.

_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Fri Nov 04, 2005 4:31 am Post subject:

Might as well give this thread sticky status. Smile
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Fri Nov 04, 2005 5:26 am Post subject:

Why not just spawn a new thread and sticky that instead?

This thread's been full of stupid lately, thanks to the undying efforts of vigi_lante to get his retarded-ass TV-out adapter supported.
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Fri Nov 04, 2005 6:07 am Post subject:

should have mentioned something. i could have sent you a copy of visual studio. my university gives it away for free. oddly enough, it's a self-extracting zip.
_________________
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Nov 06, 2005 5:59 pm Post subject:

Just curious, are game specific hacks prudent for copy protected games? Or is there some hardware accurate way to handle these?
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Mon Nov 07, 2005 10:53 am Post subject:

There's always a hardware-accurate way to handle everything. That's the point of emulation.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Nov 07, 2005 6:49 pm Post subject:

I guess I don't understand how copy protection works on snes games. The snes hardware didn't have any protection, right? And how many roms do this?

All I remember are:
Megaman x3?
Star Trek Deep Space Nine
Demon's Crest?

They must do some kind of self-diagnostic to make sure it's a cart and not a rom. Whatever it is, it sounds wierd.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Nov 07, 2005 6:50 pm Post subject:

iirc Megaman X v1.0 has copy protection in it.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Noxious Ninja
Dark Wind


Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs

Posted: Mon Nov 07, 2005 7:02 pm Post subject:

FitzRoy wrote:
They must do some kind of self-diagnostic to make sure it's a cart and not a rom.


As long as you emulate it accurately enough, there will be no problems. The trick is to figure out how the copy protection works.
_________________
#577451
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Mon Nov 07, 2005 7:58 pm Post subject:

FitzRoy wrote:
They must do some kind of self-diagnostic to make sure it's a cart and not a rom.
(...)
I guess I don't understand how copy protection works on snes games.

Yeah.

It's not a diagnostic. It has to do with how the snes sees a ROM. Mainly mirroring.
Let's say you have 24 slots available, but it only fills 16, like this:
Code:
ABCDEFGHIJKLMNOP00000000

Now what happens in the real snes ? It wraps and restarts from a certain point:
Code:
ABCDEFGHIJKLMNOPABCDEFGH

Now make your game read A-H from the late area instead of the first area whenever you want...
If the emulator doesn't emulate the mirroring, it will not return the correct value. So make your game react accordingly, like reset (mmx 1.1), make a boss invincible (aladdin, demon's crest), or other stuff.
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Nov 09, 2005 3:12 am Post subject:

I'm greatly looking forward to v0.014.

byuu.org wrote:
Thanks to ideas and help from kode54, GIGO, and Richard Bannister, I finally added speed regulation to bsnes. It synchronizes via sound, as I feel one lost frame of audio is far more noticeable than one lost frame of video every 10 seconds or so (the former would cause a loud popping noise each time). I took everything I could think of into account, as well. It adjusts the regulation based on NTSC (32khz / 60 samples/frame) or PAL (32khz / 50 samples / frame), clears the sound buffer whenever a modal event occurs (such as entering the menubar), etc.

I also (finally) fixed a longstanding issue where pressing enter to select a menu option would cause the keypress to go through to the emulator, causing an unwanted keypress to occur in-game.

I don't plan on supporting vsync in windowed mode, as the video would be extremely choppy unless the desktop were ran at 50/60hz, which I can't imagine anyone sane doing, at least on a CRT. For fullscreen, I plan on setting the refresh rate to 60hz and then using triple buffering, and dropping the occasional extra frame when needed (as the SNES does not run at exactly 60fps). This should allow fluid audio and video output at nearly the exact speed of a true SNES. No idea what I want to do about PAL, yet.

I'm putting off the vsync code until the next version, as well as the possible Windows port GUI rewrite. v0.014 should hopefully be released by next week.

_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Wed Nov 09, 2005 1:43 pm Post subject:

byuu.org wrote:
I don't plan on supporting vsync in windowed mode, as the video would be extremely choppy unless the desktop were ran at 50/60hz

What if the desktop runs at 100/120 Hz? Would that help anything?

Jipcy wrote:
I'm greatly looking forward to v0.014.

Me too. Razz
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.


Last edited by creaothceann on Wed Nov 09, 2005 5:48 pm; edited 1 time in total
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Wed Nov 09, 2005 4:00 pm Post subject:

Yeah, running at 100/120Hz would help preserve your eyes much longer Very Happy
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Nov 12, 2005 10:25 pm Post subject:

I'll beat everyone to it this time.

Quote:
11/12/2005 - bsnes v0.014 released
This version adds speed regulation, greatly improves PPU rendering, and increases speed by ~30% over the previous version.

Changelog:

* Rewrote offset-per-tile mode emulation, should be correct now. Fixes Chrono Trigger, Contra III, Tetris Attack, etc.
* Fixed a bug with HDMA occuring during interrupts. Fixes Tales of Phantasia souond test screen
* Updated compiler to Visual Studio 2005, and enabled profile guided optimizations
* Added conditional compilation of debugging functions (faster without them)
* Added conditional compilation of core classes as pointers (allowing polymorphism) or objects (allowing inlining). The latter results in a speed increase
* Small fixes to BG and OAM rendering routines
* Corrected sprite tile bounds wrapping
* Corrected sprite rendering in hires video modes
* Rewrote color add/sub routines, should be correct now. Fixes Illusion of Gaia menu, etc.
* Optimized video blitting routines, will temporarilly break mixed video mode screenshots
* Prevented selecting menu options via return key from being recognized as keypresses by the emulator
* Added system speed regulation (60hz/NTSC or 50hz/PAL)! Many thanks to kode54, GIGO, and Richard Bannister for their assistance


Get it here.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Nov 13, 2005 12:18 am Post subject:

Awesome work, byuu and contributers. I'd be really excited right now, however the audio for me is crackling badly, not at all like the old kode54 patch which seemed to work fine. Not sure what's happening, but is anyone else getting this?

I'm going to guess this is happening because of my fps, which shows 45-55 on every game I've tried and never 60. This makes no sense though, because when I turn off regulation, it goes up to 80-100. So it's not as though my computer is too slow...
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Nov 13, 2005 12:37 am Post subject:

If you're getting below 60fps, then you may as well turn the sound off. It will sound horrible.

It sounds like your sound card drivers are fucked. I've tested on three computers, and for whatever reason, its faster with the regulation on. Don't ask me why, but it's definitely not half the speed.
Are you sure vsync isn't on? Hmm... are you on Win2k or above? Win9x without WDM sound drivers might not handle 32khz audio resampling... that could be the problem.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Nov 13, 2005 1:33 am Post subject:

Well, here are my specs:

Intel 2.4c (northwood with HT)
Windows XP SP2 slipstreamed (fairly new reformat)
ati 9600xt catalyst 5.9
Egosys Juli@ sound card, latest drivers.

My sound card and its drivers are awesome (500kb total package. Bloat free and nary an issue with anything). I run scores of different emus and apps without problems. And kode's old .012 build ran at 60fps without any audio abnomolies whatsoever.

I did do some more troubleshooting, however, and seem to have hit something important. My sound card's control panel has latency settings that you can change from default. It's a list that looks like this:

48 sample
64 sample
128 sample
256 sample (default)
512 sample
1024 sample
2048 sample

I was messing with those and found that doing so changed the frequency with which the crackling occured. 128 reduced the anomoly, 64 reduced it even more (crackling in equal intervals of 5 seconds), and 48 sample removed the cracking completely (awesome, now I can enjoy .014!). Increasing from 256 did the opposite and made the fps even lower. So you were right, the problem was on my end and rectifiable. And using the 48 sample seems to be working on all my other apps just the same. I guess the question now is, why does bsnes mess up at anything higher than that where other programs do not?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Nov 13, 2005 1:54 am Post subject:

I've no idea... I've never heard of your sound card before.
It's pretty much Creative or Santa Cruz here, or onboard AC'97 / Digital MAX.

My sound buffer is relatively small, 8 frames worth of audio. I made it so short to prevent the sound from being TOO bad when its running too slow or too fast. The more samples, the more echo / repeat there is. I only really need three for the ring buffer effect.

If anyone wants to shed some light on this issue, please do.

And since this is the "official bsnes" thread... help with Dracula X would be nice, too, if anyone is familiar with emulation of the game. That game is just... weird. It has to be a CPU bug or something. The flame is on BG1 priority 1 with BG3 priority bit set and main screen with no color window clipping, so it can't possibly be behind BG1/2 as it is in other emus...
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Nov 13, 2005 2:13 am Post subject:

The most promising emu just keeps on getting better.

Quote:

I'd be really excited right now, however the audio for me is crackling badly, not at all like the old kode54 patch which seemed to work fine. Not sure what's happening, but is anyone else getting this?


I don't experience any cracking with the sound.
Here's my result on average:

- 40fps with no frameskip.
- Can achieve constant fullspeed 60fps (20frame) with 2 frameskip while getting clear audio. (speed regulation on)

Specs: P4 (don't really know which generation) at 2.4ghz running on XP.



(Btw, not that it matters much: Bsnes crashes on startup on windows98.I have a dual booting system)


Last edited by Dmog on Sun Nov 13, 2005 2:24 am; edited 2 times in total
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Nov 13, 2005 2:22 am Post subject:

The hell... you must have other programs sapping your CPU power. I've only got a 1.67ghz and easily manage 60fps in nearly all games with zero frameskipping. Only Star Ocean manages to drop below 60 to about 56fps, probably due to the S-DD1 among other things.
Fitz' 2.4ghz is pushing 80+ fps, D-BOYs mobile 2ghz is pushing 80-100fps.

Don't know how to fix it for Win98, but lord is that OS old...

You might try turning off the speed regulation under settings, if it jumps up to 80+fps, then I clearly have a problem here that needs to be fixed :/
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Nov 13, 2005 2:46 am Post subject:

byuusan wrote:
The hell... you must have other programs sapping your CPU power.I've only got a 1.67ghz and easily manage 60fps in nearly all games with zero frameskipping.


edit: *Disregard* everything below. My results aren't constant. The cause probably comes from my end rather than being caused by Bsnes.


















[disregard]Just done some more testing:

It seem with Video surface Off I get 30fps (0-fskip, no speed reg)
With Video Surface On I get 100-110fps Confused (again, 0-fskip no speed reg)

(I made the change between On-Off then restarted B. Just to be sure.)

Weird thing is: With Vid surface off, it start at 100fps, then it progressively drops to 30fps in a matter of seconds.

I'm going to do a reboot. Just to confirm.[/disregard]


Last edited by Dmog on Sun Nov 13, 2005 3:13 am; edited 1 time in total
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Nov 13, 2005 2:50 am Post subject:

Yeah, I'm not surprised you haven't heard of it. It's one of those audiophile cards with higher end DACs. Not terribly common because you need really nice speakers/headphones to take advantage difference (and they're not usually marketed to gamers even though they work with such just fine).

I should have also said that lowering the sample to 48 did not just clear up the crackle, it improved the fps as well to a steady 60 (which, in effect, cleared up the crackle...) So I wasn't getting 45-55 with no crackle.

Carry on.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Nov 13, 2005 3:21 am Post subject:

Quote:
edit: *Disregard* everything below. My results aren't constant. The cause probably comes from my end rather than being caused by Bsnes.


It's cool, I appreciate the feedback.

Video memory surface on makes things a lot faster on most systems, but some systems throw a fit when I transfer the rendered image directly to VRAM. If things run faster with video memory surface off, then you definitely want to use 256x224 windowed mode. The video surface will perform hardware scaling to the window size, but the system surface will not. Hence, you're transferring a lot more data. You have no choice but to use a video surface for 32bpp desktops, as that does auto 16bpp->32bpp upgrading (which halves the data needed to be transferred to the card).
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Nov 13, 2005 3:22 am Post subject:

(Edited my previous post)


Btw I notice that when I delete Bsnes's folder and re-extract it somewhere else it still remembers the last rom folder (in my case D:\emulation\snesroms). Does Bsnes adds a key to the registry? (not that I would care about a harmless registy change)
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Sun Nov 13, 2005 3:51 am Post subject:

I find that v0.14 works perfectly, and at fullspeed (at least on my laptop).

Only really major bugs I noticed were with the MK series:

Mortal Kombat (U) - flashing static when in-game
Mortal Kombat II (U) - music is messed up
Mortal Kombat 3 (U) - music is messed up
Ultimate Mortal Kombat 3 (U) - music is messed up
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
ThunderClaw
I know where you live.


Joined: 19 Aug 2004
Posts: 744

Posted: Sun Nov 13, 2005 7:28 am Post subject:

Decided to give bsnes a stab on a lower-end computer, this is what I got. I'm honestly not sure how much input you have on these sorts, so forgive me if this is redundant.

Processor: 800Mhz P3
RAM: 256 MB
Video Card: GeForce 4 Ti4200
Game: Romance of the Three Kingdoms 4, Wall of Fire.

Completely unplayable on these specs. WIth or without limit speed, I get 25-30 FPS (sound gets muted, obviously). I'll try it on my better computer back at my apartment tomorrow and update.
_________________
FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that.

phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin.

I smell spray paint.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Nov 13, 2005 5:41 pm Post subject:

Clements wrote:

Only really major bugs I noticed were with the MK series:

Mortal Kombat (U) - flashing static when in-game
Mortal Kombat II (U) - music is messed up
Mortal Kombat 3 (U) - music is messed up
Ultimate Mortal Kombat 3 (U) - music is messed up


That's funny. ZSNES used to have all those problems but were fixed. Well except for MK, ZSNES uses a hack around that. pagefault has been working on removing the MK hack recently but it seems to be breaking other stuff.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
taezou
New Member


Joined: 13 Oct 2004
Posts: 4

Posted: Sun Nov 13, 2005 8:33 pm Post subject:

In kode54's previous build of bsnes, I was able to get 60fps sustained in Tetris Attack (of course, this was with the drawing error at the top)
In the new version, the FPS is fine until I get to the area where the drawing error occured in the previous version, and I start getting like 51 FPS... I guess this is a side-effect of

Quote:
* Rewrote offset-per-tile mode emulation, should be correct now. Fixes Chrono Trigger, Contra III, Tetris Attack, etc.


?

I have a P4 3ghz and can get 60fps on every single other game I try.

Actally, it seems that the titlescreen of Chrono Trigger (where the wavy "Trigger" text scrolls over from the right) takes me down to 55fps, whereas with kode's build I would keep 60fps. Is this also affected by the new code?
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Nov 13, 2005 10:22 pm Post subject:

I just checked and the same thing happens to me, taezou. The emu slows down to ~50fps the instant that text starts scrolling (and the sound starts crackling because of it). There seems to be an issue here as we both have very fast computers and this particular render is making the fps dive.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sun Nov 13, 2005 11:24 pm Post subject:

FitzRoy, have you been able to get JoystickCursorTool to work with the latest bSNES? It's no longer working for me. Perhaps the changes about keyboard input makes JoystickCursorTool not work...
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Sun Nov 13, 2005 11:37 pm Post subject:

The Trigger text slows my framerate down from 123fps to 67fps when it appears onscreen on my laptop, so with regulate speed on I don't experience a slowdown. Smile
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Nov 14, 2005 12:04 am Post subject:

Hmm... I didn't run the PGO against any games that use offset-per-tile mode, so that's probably why. Sorry, I'll fix it in the next release. I noticed the CT slowdown, too. It's quite interesting.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Nov 14, 2005 3:20 am Post subject:

Jipcy wrote:
FitzRoy, have you been able to get JoystickCursorTool to work with the latest bSNES? It's no longer working for me. Perhaps the changes about keyboard input makes JoystickCursorTool not work...


Yeah, it still works for me. I dunno what could be wrong for you... You know how to use it right? You bind to the keyboard in bsnes, and then use the program to bind keyboard keys to the joystick. Maybe mess with the timings?

byuusan wrote:
Hmm... I didn't run the PGO against any games that use offset-per-tile mode, so that's probably why. Sorry, I'll fix it in the next release. I noticed the CT slowdown, too. It's quite interesting.


Awesome. And while I'm posting, I've noticed one bug that hasn't been mentioned - Super Double Dragon (U) - doesn't work at all.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Nov 14, 2005 3:56 am Post subject:

FitzRoy wrote:
You know how to use it right?

Yeah, it was working for me in 0.013. I'll reconfigure everything and try again.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Pepper
New Member


Joined: 08 Sep 2005
Posts: 6

Posted: Mon Nov 14, 2005 4:54 pm Post subject:

Hmmm.... The game from the following thread doesn't seem to work past the start screen.
http://board.zsnes.com/phpBB2/viewtopic.php?t=5407
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Nov 14, 2005 6:01 pm Post subject:

It may be a special-chip game that is not (yet?) emulated in bsnes.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Nov 14, 2005 6:50 pm Post subject:

Rendering Ranger R2 isn't a special chip game, but it is one of those "special timing" games. It was broken in zsnes for a really long time as I recall. Super Double Dragon is more of a mystery. I always thought that was one of the earlier games for the system. I guess it does something wierd as well.
ThunderClaw
I know where you live.


Joined: 19 Aug 2004
Posts: 744

Posted: Mon Nov 14, 2005 11:13 pm Post subject:

OK, I tried it out on my newer computer; the extra guts did indeed fix the framerate problem. (Athlon XP 2500+, Radeon 9700 PRO, nForce2 integrated sound)

I have two bugs to report.

1) Really fucking weird; the Y button appears to be nonfunctional in Romance of the Three Kingdoms 4, Wall of Fire. On creating a ruler, the Y button is used to deduct 10 stat points from a certain area; it completely fails to register. I know the button is mapped correctly, because I immediately loaded up Megaman 7, and I could fire just fine.

2) As a direct result of 1, I realized that MM7's sound crackles even when the framerate is at a constant 60. I'll continue to look into this to see if it could be my end.
_________________
FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that.

phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin.

I smell spray paint.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 15, 2005 12:25 am Post subject:

1 does indeed sound weird. This is another good game to try and track down the bug in -- the NMI is likely what reads the joypad polling, so a possible CPU bug might exist here.

I do not experience 2. MM7's graphics aren't the most intensive I've seen, but with a frameskip of 1 on my 1.4ghz laptop, I experience no sound breakup. Another thing to try is the capture audio data option. If you're positive you're maintaining a full framerate (60fps for 9 of 10 frames, 61fps for the other), then the audioNNN.wav file will almost definitely have crackling in it too (emulation problem), otherwise it's your sound card.

I may as well add my own bug reports here, too. Right now, a lot of games sometimes miss single short sound samples. I believe this is due to me using DMV27's KON register changes. Zelda 3's intro (the part where its raining outside) will miss certain song notes when Link's sword is charging and released), for example.

Some games don't work due to my simplistic header detection. Star Trek: Deep Sleep Nine is one such game. Some will fail due to using non-standard memory mapping. Y's 3 SRAM is likely one such game.

The regulate speed option does not return idle CPU time back to the system, so bsnes always consumes 99% of speed. I tried adding Sleep(1) into the speed regulation loop (I realize it takes longer than 1ms to return), but it causes the emu to drop below 60fps even when there are no other non-system processes running, no matter what. Ideas welcome here.

SPC700 ADDW/SUBW opcodes set the flags wrong. Someone mentioned this to me, but I can't fix it with their explanation of what was wrong. I need really detailed info on what I'm doing wrong to correct it.
ThunderClaw
I know where you live.


Joined: 19 Aug 2004
Posts: 744

Posted: Tue Nov 15, 2005 3:10 am Post subject:

Yeah, after a few different tests, I'm somewhat sure that it's my sound hardware that's to fault for 2. I get it even through a frameskip of 1, but my headphones make a similar crackling noise when I throw them through a Goldwave sample I found for testing them.
_________________
FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that.

phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin.

I smell spray paint.
PFUNK
Lurker


Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA

Posted: Tue Nov 15, 2005 3:23 am Post subject:

Question byuu, do you have a bugtracker to keep track of the reports you're getting here?

As an aside, I was also getting crackling with bsnes 0.014 (my laptop was able to run bsnes >100 FPS prior so it wasn't a speed issue). I messed with my sound card's sampling rate, which changed the results but didn't rid the crackiling. The audio log in bsnes came out fine too. Then I updated my card's drivers and voila, problem solved.

I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu.
_________________
I'm hot for you and you're hot for me ooka dooka dicka dee.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 15, 2005 4:42 am Post subject:

Quote:
Question byuu, do you have a bugtracker to keep track of the reports you're getting here?

No, I really don't have time to set up and maintain these things. A message board wouldn't hurt either, but this thread seems to be working fine anyway.

Quote:
I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu.

Thanks. Since everyone can get working sound after fiddling, I'm going to pass it off as a systems-issue and not worry about it, then.
Win9x users... sorry, the OS is almost (and in some cases, is) a decade old. I'm not supporting OS/2 and RedHat 3 (please don't argue on date semantics), so I'm not supporting 9x, regardless of userbase. If someone else wants to fix it, awesome -- I'll merge the changes.

Ok, I just got done merging Nach's gzip, zip, and jma support, and added my own stuff to it to make it a compile-time option. JMA is broken, as msvc is complaining about undefined virtual inline functions. I'll talk to Nach when we're both awake. I also can't test gzip, but see absolutely no reason why it shouldn't work. Thanks again, Nach.
Now to bug him about DSP and C4 support... hehe.

Edit: JMA makefile wasn't linking against winout.cpp's object file. Now I'm damn curious how Nach managed to compile this, but anyway -- here's the log for Nach when he gets on: http://byuu.cinnamonpirate.com/temp/jma_errors.txt


Last edited by byuu on Tue Nov 15, 2005 5:17 am; edited 1 time in total
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Tue Nov 15, 2005 5:00 am Post subject:

byuusan wrote:
Ok, I just got done merging Nach's gzip, zip, and jma support, and added my own stuff to it to make it a compile-time option. ... Now to bug him about DSP and C4 support...

Freakin' sweet!
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Tue Nov 15, 2005 5:33 am Post subject:

byuusan wrote:
Ok, I just got done merging Nach's gzip, zip, and jma support, and added my own stuff to it to make it a compile-time option. JMA is broken, as msvc is complaining about undefined virtual inline functions. I'll talk to Nach when we're both awake. I also can't test gzip, but see absolutely no reason why it shouldn't work.
That's good news, now I can more easily test my ROMs without worrying about uncompressing them first. Smile
Quote:
No, I really don't have time to set up and maintain these things. A message board wouldn't hurt either, but this thread seems to be working fine anyway.
Just a thought, but maybe the admins would be kind enough to make a bsnes board here at the ZSNES board? DeJap is already hosted here, so why not bsnes? Wink
LDAWG
Lurker


Joined: 06 Aug 2004
Posts: 166

Posted: Tue Nov 15, 2005 6:31 am Post subject:

I tested a couple of games with lots of digitized sounds (I think).

On one hand, Mortal Kombat II sounds atrocious and hurt my ears really bad Smile
...but on the other hand, Donkey Kong Country 2 sounds pretty freaking rad!!

In-fact the sound is really awesome in bsnes... good job!
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Tue Nov 15, 2005 3:09 pm Post subject:

byuusan wrote:
Quote:
Question byuu, do you have a bugtracker to keep track of the reports you're getting here?

No, I really don't have time to set up and maintain these things. A message board wouldn't hurt either, but this thread seems to be working fine anyway.

Quote:
I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu.

Thanks. Since everyone can get working sound after fiddling, I'm going to pass it off as a systems-issue and not worry about it, then.
Win9x users... sorry, the OS is almost (and in some cases, is) a decade old. I'm not supporting OS/2 and RedHat 3 (please don't argue on date semantics), so I'm not supporting 9x, regardless of userbase.


No problem with me :-P
I agree win9x is terribly old and outdated. I mainly keep a dual boot XP/98 system because there are a few apps that just doesn't run properly on XP. Running Bsnes on XP or 98 makes no difference for me.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Tue Nov 15, 2005 4:06 pm Post subject:

I'd dedicate a part of my board to you byuusan, but, as you all have probably seen, my board won't install on PHP 5.x.x >.>
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Tue Nov 15, 2005 4:13 pm Post subject:

byuusan wrote:
I also can't test gzip, but see absolutely no reason why it shouldn't work.

I see every reason why it shouldn't work, you completely killed it several times over Crying or Very sad

As for bsnes board. It would have to be _Demo_'s decision wether we do that here, this is his server, and it's up to him what projects he wants to support on it.

However I have no problem making a bsnes section on my forum.

Although if if byuu has the server power and the throughput required, I don't see why he can't just install some decent BB software on his own server.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Tue Nov 15, 2005 6:03 pm Post subject:

bsnes already has a forum on my board, so...
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Thu Nov 17, 2005 11:33 pm Post subject:

Finally got home and tested bsnes with my CRT and the colour curve option. In short: colours look pretty much identical to how it looks on a real TV. Great job with that.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Nov 17, 2005 11:49 pm Post subject:

I can't take credit for the color curve. Thank Overload for that.

However, I am planning to add a special filter mode for (pseudo-)hires games to more closely match how they look on hardware, specifically due to color bleeding.

On the subject of color effects... I know how to convert an RGB color to grayscale, but does anyone know how to convert the grayscale color to other tones, such as sepia, or maybe a gameboy monochrome look? I want to add those to my special color filters list.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Fri Nov 18, 2005 2:16 am Post subject:

HSB or YUV is probably a more natural representation of color for the types of transformations that you're describing.

http://en.wikipedia.org/wiki/Color_space
-_pentium5.1_-
Lurker


Joined: 04 Sep 2004
Posts: 193
Location: USA

Posted: Sat Nov 19, 2005 5:34 am Post subject:

BTW byuu, when will the news of this release make it to the major emulation news sites? I don't mean to be pushy, but I still haven't figured out why my computer can't correctly download bsnes from your site.
_________________
This signature intentionally contains no text other than this sentence.
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Sat Nov 19, 2005 12:48 pm Post subject:

-_pentium5.1_- wrote:
BTW byuu, when will the news of this release make it to the major emulation news sites? I don't mean to be pushy, but I still haven't figured out why my computer can't correctly download bsnes from your site.


The latest bsnes is mirrored at Emulation64 as always:

http://www.emulation64.com/files/info/489/
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Nov 21, 2005 1:43 am Post subject:

byuusan: If you still need a forum, I've got one:

http://linksadventure.no-ip.org/phpbb2/viewforum.php?f=8
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Mon Nov 21, 2005 8:33 am Post subject:

-_pentium5.1_- wrote:
BTW byuu, when will the news of this release make it to the major emulation news sites? I don't mean to be pushy, but I still haven't figured out why my computer can't correctly download bsnes from your site.

What about AEP?
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Nov 21, 2005 1:20 pm Post subject:

I appreciate the forum requests. I don't have SQL access, and I don't want to consume a lot of bandwidth is why I don't stick phpBB or whatever on my site. Anyway, I'll worry more about it later.
I still don't know what's wrong with my host's downloads, and I probably never will :/
I've never once had a problem with it myself, either.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Nov 21, 2005 5:50 pm Post subject:

Fixed mosaic, tile mode pgo, better header detection.... nice. And Mega Man x2 and x3 will be supported in the next version!

.015 - keepin the dream alive!
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Mon Nov 21, 2005 5:54 pm Post subject:

FitzRoy wrote:
And Mega Man x2 and x3 will be supported in the next version!


Well, for some reason I can't seem to get op 0 subop 5 to work right, everything else works though. Although that one op is only used in X2 intro AFAIK.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
LDAWG
Lurker


Joined: 06 Aug 2004
Posts: 166

Posted: Mon Nov 21, 2005 6:17 pm Post subject:

byuu wrote:
I appreciate the forum requests. I don't have SQL access, and I don't want to consume a lot of bandwidth is why I don't stick phpBB or whatever on my site. Anyway, I'll worry more about it later.
I still don't know what's wrong with my host's downloads, and I probably never will :/
I've never once had a problem with it myself, either.


It's kind of ridiculous that your host wont give you access to your SQL Server and Database, for your site Sad
If you ever do get SQL access, and if you're into the whole M$ thing (i.e. Visual Studio / SQL / .NET / .ASP)...
then I recommend DotNetNuke for your Forums/Website!

http://www.dotnetnuke.com

DotNetNuke is an Open Source Framework ideal for creating and maintaining professional Web Applications.

I have been playing with it lately, and I kind of like it.
With DotNetNuke 4.0, you can install the "Starter Kit" with a Visual Studio 2005 .VSI file.
Your host does have to have .ASP2 and .NET2 to run 4.0 though (SQL 2005 is also preferred)

Kick your host in the ass, and give bsnes a better home !! Smile
I can't wait until you release the next version!
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Mon Nov 21, 2005 6:45 pm Post subject:

LDAWG wrote:
byuu wrote:
I appreciate the forum requests. I don't have SQL access, and I don't want to consume a lot of bandwidth is why I don't stick phpBB or whatever on my site. Anyway, I'll worry more about it later.
I still don't know what's wrong with my host's downloads, and I probably never will :/
I've never once had a problem with it myself, either.


It's kind of ridiculous that your host wont give you access to your SQL Server and Database, for your site Sad
If you ever do get SQL access, and if you're into the whole M$ thing (i.e. Visual Studio / SQL / .NET / .ASP)...
then I recommend DotNetNuke for your Forums/Website!


His server is not running on Microsoft software, he's running Linux 2.4.

Apache httpd 1.3.33 ((Unix) mod_ssl/2.8.22 OpenSSL/0.9.7e)
MySQL 4.1.13-standard
Sendmail 8.12.11/8.12.11
OpenSSH 3.6.1p2 (protocol 2.0)

Now they do have MySQL, but I guess byuu doesn't want to pay the extra fee to use it (or convince his friend as the case may be).
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding


Last edited by Nach on Mon Nov 21, 2005 10:32 pm; edited 1 time in total
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Nov 21, 2005 6:57 pm Post subject:

Nach: I use Apache 2.0.54 for the HTTPd.
I use MySQL 4.x, since I've been familiar with it for some time.
The OS is kubuntu Linux 5.1.

And LDAWG: Remember this: REAL men host their own servers. Cool

I think I oughta add that as another sig quote...
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
LDAWG
Lurker


Joined: 06 Aug 2004
Posts: 166

Posted: Mon Nov 21, 2005 7:59 pm Post subject:

adventure_of_link wrote:
And LDAWG: Remember this: REAL men host their own servers. Cool

I think I oughta add that as another sig quote...


That's not a very nice thing to say about byuu Crying or Very sad
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Nov 21, 2005 8:53 pm Post subject:

I made that post not paying to attention about anything, I assumed Nach and you were discussing my server, and when I finally looked at it, it made the post even more useless than it originally was... Embarassed
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Mon Nov 21, 2005 10:16 pm Post subject:

adventure_of_link wrote:
Nach: I use Apache 2.0.54 for the HTTPd.
I use MySQL 4.x, since I've been familiar with it for some time.
The OS is kubuntu Linux 5.1.

I made that post not paying to attention about anything, I assumed Nach and you were discussing my server.


If I was discussing your server I would have said you're running:
Apache httpd 2.0.54 ((Ubuntu) PHP/5.0.5-2ubuntu1 mod_perl/2.0.1 Perl/v5.8.7)
Postfix smtpd
OpenSSH 4.1p1 Debian-7ubuntu4 (protocol 2.0)
Unreal ircd
And other stuff.

You also don't seem to have rebooted since Tue Nov 15 18:03:59 2005.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Tue Nov 22, 2005 1:36 am Post subject:

How do you know about my computer Nach

Tell me, please
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 22, 2005 5:53 am Post subject:

Quote:
Well, for some reason I can't seem to get op 0 subop 5 to work right, everything else works though. Although that one op is only used in X2 intro AFAIK.


...and even that's working now, whee. I must admit, the C4 can do some pretty cool stuff. It would be nice to emulate the opcodes that the MMX games don't use. I can only imagine what the other ops do, and what kind of cool demo ROMs could be produced.

Not sure how I feel about the emulation quality, though. Code isn't bit-accurate and is quite... messy, to say the least. Not that I could've done any better. I'd love to get my hands on a rig to run my own tests on that chip. And hell, all of the chips for that matter...
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Tue Nov 22, 2005 9:06 am Post subject:

byuu wrote:
Win9x users... sorry, the OS is almost (and in some cases, is) a decade old. I'm not supporting OS/2 and RedHat 3 (please don't argue on date semantics), so I'm not supporting 9x, regardless of userbase. If someone else wants to fix it, awesome -- I'll merge the changes.

http://rapidshare.de/files/7982508/bsnes_win9x.zip.html

bsnes.exe is compiled with mingw/gcc 3.4.4
ui_memory.patch contains the one line win9x fix.
src_win.patch contains the win9x fix plus some other fixes (mostly DirectSound, some fixes for mingw/gcc).

Some other things that need to be fixed:

Classes with virtual functions should have virtual dtors
The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests
65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h)
bMemBus::read uses a static variable
bDsp::run doesn't use noise_sample properly (uint15 -> int32; check the Dual Orb 2 opening). The code should be

Code:

if(status.NON & (1 << v)) {
// sample = status.noise_sample;
sample = int16(status.noise_sample << 1) >> 1;
} else {
d = voice[v].pitch_ctr >> 4; //-256 <= d <= -1
sample = ((GaussTable[ -1-d] * S(-3)) >> 11);
sample += ((GaussTable[255-d] * S(-2)) >> 11);
sample += ((GaussTable[512+d] * S(-1)) >> 11);
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1;
sample += ((GaussTable[256+d] * S( 0)) >> 11);
sample = clamp(15, sample);
}
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 22, 2005 2:01 pm Post subject:

Code:
- dsbd.dwFlags = DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_CTRLFREQUENCY |
- DSBCAPS_GLOBALFOCUS | DSBCAPS_LOCSOFTWARE;
+ dsbd.dwFlags = DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_GLOBALFOCUS;


I had this like this for a reason. First, I want to change the frequency. For a slowdown key, I need only swap the frequency to 16000hz, for a speedup key, 48000hz. Maybe 64000hz since Win9x+WDM/Win2k+ will remix it anyway, since I doubt many cards can handle that sampling rate. And the benefit there is that the audio is still crisp.
The buffer needs to be in software, because older cards have problem with accuracy when getting the buffer playback position.

I also don't know why you define and undefine my dsbufferdesc variable. Why can't it be in the body of the DSSound class?

Quote:
Classes with virtual functions should have virtual dtors

I was wondering why I needed to delete classes through static casts to the derived class type to call the right dtors, thanks.

Quote:
The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests

And yet with 'kon', it breaks DL. I'll change it back when we find out why that is.

Quote:
65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h)

Mine came from there. What did I copy wrong?

Quote:
bMemBus::read uses a static variable

For? And why is this a problem?

Quote:
bDsp::run doesn't use noise_sample properly (uint15 -> int32; check the Dual Orb 2 opening). The code should be

Neat, thanks.

Appreciated as always, I'll add your fixes when I get home tonight.
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Tue Nov 22, 2005 9:00 pm Post subject:

byuu wrote:
I also don't know why you define and undefine my dsbufferdesc variable. Why can't it be in the body of the DSSound class?

I tend to over-optimize sometimes, so you can just ignore most of the DSSound changes (except the ctor, that is needed).

Quote:
Quote:
The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests

And yet with 'kon', it breaks DL. I'll change it back when we find out why that is.

I meant that you should still use the fix, but just change the 'KON' to 'kon' so that the KON register bits don't get cleared.
Code:
} else if(status.kon & mask) {
status.kon &= ~mask; //new code
status.ENDX &= ~mask; //new code


Quote:
Quote:
65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h)

Mine came from there. What did I copy wrong?

You only check for decimal overflow after doing an 8/16-bit add/sub, but for proper BCD math you need to add/sub and check for every 4-bits. For example, your code does not pass this test:
Code:
// 0x00 + 0x10 = 0x10 == 10
// 0x09 + 0x07 = 0x10 != 16


Quote:
Quote:
bMemBus::read uses a static variable

For? And why is this a problem?

It uses 'static uint32 r' for the return value, but it should be 'uint8 r'. It's not a problem, just a very minor optimization.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Nov 23, 2005 3:16 am Post subject:

Quote:
I meant that you should still use the fix, but just change the 'KON' to 'kon' so that the KON register bits don't get cleared.

Wasn't that the exact thing that was causing the problem before? What should I change here?
Code:
// status.ENDX &= ~status.kon;
// status.kon = 0;
status.key_flag = false;


And how about on KON register read/write?

Quote:
You only check for decimal overflow after doing an 8/16-bit add/sub, but for proper BCD math you need to add/sub and check for every 4-bits.


Code:
inline void bCPU::op_adc_w() {
int32 r = regs.a.w + rd.w + regs.p.c;
//bcd
if(regs.p.d) {
if(((r ) & 15) > 9)r += 6;
if(((r >> 4) & 15) > 9)r += 6 << 4;
if(((r >> 8) & 15) > 9)r += 6 << 8;
if(((r >> 12) & 15) > 9)r += 6 << 12;
}

That seems to be exactly what I'm doing... what exact spot is failing in SimEarth?

Quote:
It uses 'static uint32 r' for the return value, but it should be 'uint8 r'. It's not a problem, just a very minor optimization.

Alright then, I'll take a look at it. I have a habit of using static on classes that don't need to be ctor/dtor'ed on each function call, so I do that to variables needlessly sometimes. I guess that prevents the variable from being a register or whatever, then...

Quote:
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1;

Is there something wrong with the clip function? I know it isn't as fast, but the functionality should be identical. I use clip because it makes it clearer whats happening when you clip at different bit sizes.
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Wed Nov 23, 2005 6:38 am Post subject:

byuu wrote:
Quote:
I meant that you should still use the fix, but just change the 'KON' to 'kon' so that the KON register bits don't get cleared.

Wasn't that the exact thing that was causing the problem before? What should I change here?
Code:
// status.ENDX &= ~status.kon;
// status.kon = 0;
status.key_flag = false;


And how about on KON register read/write?

The problem was being caused by 'status.kon = 0' and not by the use of the kon variable. My fix took care of that problem, but it also wrongly used KON instead of kon. Here is the correct patch:

Code:

diff -dr src_old/dsp/bdsp/bdsp.cpp src/dsp/bdsp/bdsp.cpp
148c148
< // status.kon = data;
---
> status.kon = data;
224c224
< //status.kon = 0x00;
---
> status.kon = 0x00;
304,305c304,305
< } else if(status.KON & mask) { //status.kon
< status.KON &= ~mask; //new code
---
> } else if(status.kon & mask) {
> status.kon &= ~mask; //new code
diff -dr src_old/dsp/bdsp/bdsp.h src/dsp/bdsp/bdsp.h
66c66
< //uint8 kon;
---
> uint8 kon;


Quote:
Code:
inline void bCPU::op_adc_w() {
int32 r = regs.a.w + rd.w + regs.p.c;
//bcd
if(regs.p.d) {
if(((r ) & 15) > 9)r += 6;
if(((r >> 4) & 15) > 9)r += 6 << 4;
if(((r >> 8) & 15) > 9)r += 6 << 8;
if(((r >> 12) & 15) > 9)r += 6 << 12;
}

That seems to be exactly what I'm doing... what exact spot is failing in SimEarth?

This:


The numbers in this picture are completely wrong. They should be 3,000,250,000Ys. and 50/3000. The problem is that you check for decimal overflow after a 8/16-bit add/sub, but you need to individually check after each 4-bit add/sub. Taking your op_adc_w as an example, if

regs.a.w = 0x09
rd.w = 0x07
regs.p.c = 0
regs.p.d = 1

then r = 0x10. After your BCD math checks, r will still be equal to 0x10, but the correct result would be 0x16. 9+7 is 16, not 10.

Quote:
Quote:
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1;

Is there something wrong with the clip function? I know it isn't as fast, but the functionality should be identical. I use clip because it makes it clearer whats happening when you clip at different bit sizes.

It's just an optimization.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Nov 23, 2005 6:53 am Post subject:

Quote:
The problem was being caused by 'status.kon = 0' and not by the use of the kon variable. My fix took care of that problem, but it also wrongly used KON instead of kon.


Yeah, after actually looking at it for five minutes I figured it out :/
I did some tests and if either the ENDX mask or KON clear is outside of the } else if(status.kon) { part, it will break sounds in DL (for kon) or SFA2 (for endx).

I know that contradicts anomie's research. Writing KOFF=1, KON=1, wait... KOFF=0 supposedly won't play sounds, but that's exactly the problem games are having -- they are playing the sounds when you clear KOFF, for whatever reason... not emulating that causes many dropped samples. So that suggests writes to KOFF won't clear the kon bits.

I also modified some other things to TRAC's research. Specifically, I made writes to VxSRCN not restart the sample, and just update the value for the next brr with end bit set block to reload the brr address.
That fixed the horrible sound problems in Mortal Kombat 2+.

Then I also changed the kon/koff checks to happen for each sample instead of every other. I don't know what's right here, but TRAC thinks its the former, so until I test it myself or hear otherwise...

Quote:
The problem is that you check for decimal overflow after a 8/16-bit add/sub, but you need to individually check after each 4-bit add/sub.

Ugh. Well, luckily I just had to split the 16-bit addw op in the SPC into two 8-bit adds to pass Overload's SPC test, so I should be able to use the exact same method to make an add_nybble function and call that four times.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Nov 28, 2005 6:23 pm Post subject:

mmm, post-thanksgiving update. Go have a look y'all. Shaping up to be a big release. Shocked
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Nov 28, 2005 11:24 pm Post subject:

I could use some help with the triple buffering code... such an amazingly simple concept yet I can't manage to maintain smooth video even with High priority, 60hz video mode, and 2x the CPU power to spare.
ZSNES manages, so I know it's possible...
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Tue Nov 29, 2005 5:44 am Post subject:

Hey Byuu, any chance you would want to use this snes pad for your mapping image instead? It's even 1/4 the size.

http://home.mchsi.com/~s.daystrom/snespad.bmp
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Nov 29, 2005 6:56 am Post subject:

Don't like it :/


0kb. Ugly, but eh. Lots of bandwidth saving. It lets you map a keyboard button AND joypad button to the same controller button, too.
SquareHead
Seen it all


Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box

Posted: Tue Nov 29, 2005 2:49 pm Post subject:

Kick ass. Is there a link to the current build of bsnes?
_________________
My boring Site
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Tue Nov 29, 2005 4:43 pm Post subject:

Dude, that's even better. That was probably more work and you were using an image before, so I didn't suggest it. Kazaam.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Dec 03, 2005 2:46 am Post subject:

I just noticed something of a minor inaccuracy. Shouldn't 640x480 be listed as 4:3? Just thought I'd let you know if you hadn't noticed already.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 03, 2005 4:11 am Post subject:

The output is actually 512x446 centered in fullscreen mode 640x480.

The new version takes care of this anyway. There are ten video modes, selectable through CTRL+[1-0], the first five are windowed modes, the last are fullscreen modes. All ten can be configured via bsnes.cfg
Format for windowed modes is just "WIDTHxHEIGHT"
Format for fullscreen modes is "RESXxRESY@REFRESHRATE:WIDTHxHEIGHT", with the latter being the size of the image, automatically being centered.
So it should be trivial to create a 4:3 pixel mode even on 16:9 and 3:4 monitors.
I also made 640x480 stretch to the full screen by default. It actually doesn't look half as bad as I thought it would.

So yay me, I'll never have to deal with hundreds of requests for crazy weird resolutions. End users can use whatever the hell they want now.

Oh, and for a sneak peek: +/- adjust frameskip rate, PAUSE/BREAK which is self-explanatory, CTRL+[+/-] to control base emulator speed. There are five speed modes, all user definable. By default there's 50%, 67%, 100%, 150%, and 200% modes. I don't even think there's a computer out there that can use the last one with no frameskipping, but eh. The option is there anyway.
The audio frequency is actually adjusted, too, so the audio stays smooth and crisp, with only a change in tempo / pitch.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Dec 03, 2005 4:46 am Post subject:

Nice! Thanks for the info.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Sat Dec 03, 2005 5:02 am Post subject:

That's amazing work you've been doing, byuu

Anything the bsnes community can do to help you out?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 03, 2005 7:31 am Post subject:

Sure! In order: help fix the problem with my triple buffering code (since the SNES runs at 60.09 fps, it should skip one frame every ten seconds, but it seems like it gets jittery for 2-3 seconds every 10 seconds instead), rewrite the Linux port to not suck royally, and add support for any special chips I don't currently support.
Hehe, you asked :D
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 04, 2005 3:01 am Post subject:

v0.015 is up. Enjoy.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Dec 04, 2005 6:48 am Post subject:

I saw it first. It's mine, mine, mine, mine, mine. Twisted Evil

Thanks again to byuu and company.
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Sun Dec 04, 2005 6:48 pm Post subject:

This is a fantastic release! bsnes seems like it is well on its way to eventually outdo ZSNES! (and it already has accuracy-wise).

Problem: I can't map the keys to the directional buttons on my Saitek P880 gamepad. I can map A, B, X, Y, L, R, Select, and Start just fine, but not U/D/L/R. Sad
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Dec 04, 2005 6:56 pm Post subject:

xamenus wrote:
This is a fantastic release! bsnes seems like it is well on its way to eventually outdo ZSNES!

I kind of doubt that at least for a long while.
Until bsnes gets save state support, we won't see it remotely close to ZSNES featurewise.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 04, 2005 7:10 pm Post subject:

Quote:
Problem: I can't map the keys to the directional buttons on my Saitek P880 gamepad.


Please make sure your controller is in digital mode before mapping the keys. It works with analog for me too, but eh. That's probably the cause.

Quote:
I kind of doubt that at least for a long while.
Until bsnes gets save state support, we won't see it remotely close to ZSNES featurewise.


Seconded, and I don't ever plan on adding most of ZSNES' features. And the only way I'll be beating ZSNES on speed is when quantum processors come out that aren't backwards-compatible with x86's, and ZSNES can't be recompiled due to the large amounts of x86 assembler.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Dec 04, 2005 7:17 pm Post subject:

byuu wrote:

Quote:
I kind of doubt that at least for a long while.
Until bsnes gets save state support, we won't see it remotely close to ZSNES featurewise.


Seconded, and I don't ever plan on adding most of ZSNES' features.

Well, others do plan on adding features eventually, but a lot depends on save states. bsnes isn't even worth looking at for various things till it has save states.
Rewind and Movie features depend on save states. Now take the nesvideos crew, they go around finding good emulators and adding a lot of features to it to make it nicer to work with and use, but only if it seems feasable for making movies with, and that absolutely depends on having good save state support.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 04, 2005 7:39 pm Post subject:

Well, I guess I can start on savestate support now. Just add one core part at a time. I did want to wait for anomie so that we could create that generalized SNES savestate format, but he seems MIA at the moment... :(

I would hardly say it isn't worth looking at, but eh. Also, my licensing probably isn't very friendly to the nesvideos crew. Although I'm always willing to import others' code into my trunk.

Speaking of rewind, I'd love to add something like blargg's rewind idea, where you actually emulate forwards but play backwards, but bsnes is hardly the emulator to be trying something that CPU expensive on... it would be cool as hell, though.
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Sun Dec 04, 2005 8:03 pm Post subject:

byuu wrote:
Please make sure your controller is in digital mode before mapping the keys. It works with analog for me too, but eh. That's probably the cause.
You're right. Smile Thanks.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Dec 04, 2005 8:41 pm Post subject:

byuu wrote:

I would hardly say it isn't worth looking at, but eh. Also, my licensing probably isn't very friendly to the nesvideos crew.

I don't think they'll have an issue with your licensing. Their basic requirements these days seem to be that they can modify it for their own use and it runs on Linux.
The biggest problem they have regarding this is: "No publically-released derivative works of this source code are permitted without my permission."
But it's just a hop over from #nesvideos to ask permission which you'll probably grant, right?
byuu wrote:

I'd love to add something like blargg's rewind idea, where you actually emulate forwards but play backwards, but bsnes is hardly the emulator to be trying something that CPU expensive on... it would be cool as hell, though.

It's not CPU exspensive at all. Although depending on what method you use exactly, it could be memory exspensive.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 04, 2005 9:19 pm Post subject:

Quote:
But it's just a hop over from #nesvideos to ask permission which you'll probably grant, right?

I granted this permission to Richard Bannister because I never plan on releasing a mac port, nor buying a mac, for that matter.
I basically don't want to fork the hell out of my userbase like the SNES9x project has. There are what, 15 separate builds of that emulator now? And then you go and fix bugs and add new features, but the other build maintainer is now gone, so you get people complaining about something you fixed half a year ago in the official release. And then you get certain people who rename your emulator and try and take all the credit. Plus it's wasteful. People should work together on the same codebase and improve that, instead of making a new version because one or two small features aren't in the main build. And the main thing that really upsets me are things like that one multi-platform emulator that's for sale, but takes 95% of its emulation code from free projects like 9x.
Of course, anyone can break my license, but then I can just start releasing the source three versions behind like 1964 does, too.

To answer your question, I might grant permission. Just video capture features alone probably won't matter much to me. I'll talk more about that when I get savestates, though.

Quote:
It's not CPU expensive at all.

It isn't the way ZSNES implements it. What blargg does is take periodic savestates, and then when the user hits rewind, he goes back one savestate, then emulates everything up to the present and stores it in a buffer. And then he plays that buffer backwards. So the audio sounds like it's reversed, and the video is smooth. e.g. it looks like a real rewind instead of like loading a savestate.
Now, given it takes 1.8ghz or better for bsnes to reach 60fps in all games, you won't be able to generate more than one or two frames going backwards in real-time without there being pause delays, which ruins the effect.
ZSNES might be able to pull it off, because it runs ten times faster. NES emulators can easily pull it off, because they run thirty times faster.
FirebrandX
Lurker


Joined: 19 Apr 2005
Posts: 128

Posted: Sun Dec 04, 2005 9:37 pm Post subject:

Fantastic work on bsnes thus far! I have a few suggestions/requests/questions if you wouldn't mind giving them some consideration.

1. One of the advantages I can make use of in ZSNES is that it does not have a window tab border in window mode. I am able to have it fill the screen in window mode using a custom monitor res with my video card (512x448x60hz). I tried it out with bsnes, and it worked pretty close, except there was a visble window tab. If possible, the best would be a 512x448 window mode with no tab border.

2. There seems to be some interpolation going on with the graphics. I'm not sure how this works or if its fully being done by my video card, but I can't stand interpolated graphics. In ZSNES, there is minimal interpolation at 512x448, and I use 25% scanlines to give it a sharp, yet unblocky look. I'd love to see some scanline options and a way to turn off interpolation if possible at all.

3. This is most important to me. Its about smooth scrolling. While triple buffering does a decent job of smoothing out the scrolling, I much prefer timing based on vsync. Again, I program in my own custom timing modes on my card using power strip, which allows me to run ZSNES liquid-smooth.

Ok, thanks a bunch for the great work so far!
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sun Dec 04, 2005 9:59 pm Post subject:

byuu wrote:
Just video capture features alone probably won't matter much to me.

You must be out of the loop... You haven't seen what they did with Snes9x Improvement or their versions of famtasia, FCEU, and VBA have you? It is much much more than video features. This is a completely different crowd than your emulation scene and they demand very different features to be available.

byuu wrote:

Quote:
It's not CPU expensive at all.

It isn't the way ZSNES implements it. What blargg does is take periodic savestates

I was and am fully aware what blargg does. It doesn't have to be CPU exspensive at all, I see right off the bat 3 different way it could be implemented.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 04, 2005 10:05 pm Post subject:

Quote:
1. One of the advantages I can make use of in ZSNES is that it does not have a window tab border in window mode. I am able to have it fill the screen in window mode using a custom monitor res with my video card (512x448x60hz).

...that's what fullscreen mode is for. Edit bsnes.cfg and add a 512x448 video mode, and switch to that :/
No window border was one of the most annoying GUI things with ZSNES to me. If there's sufficient demand, I could add it, though.

Quote:
2. There seems to be some interpolation going on with the graphics. I'm not sure how this works or if its fully being done by my video card

It's your video card. ZSNES is way the hell faster, so it can handle copying 512x448 worth of video data to the card every frame. bsnes cannot, so by default it uses video RAM so it only has to copy 256x224 usually.
One option is for me to add a D3D renderer, but those don't do fullscreen + menus. But it lets you turn off the interpolation, unlike DirectDraw.
The other is for you to disable the "use video memory" under video options. Beware, you will lose a lot of speed.
I'm not at a point to start adding video filters (scanlines, HQnX, etc), but I will eventually.

Quote:
While triple buffering does a decent job of smoothing out the scrolling, I much prefer timing based on vsync.

Triple buffering is identical to vsync, but requires no CPU stall time. Both wait until the start of the vertical blanking period, and then blit the current image to the screen. The difference, and this is very important, is that vsync means you need to wait until the retrace period begins. This will prevent the sound system from receiving new samples and being updated, and it will align the refresh to your monitor instead of the emulator speed. The result is choppy audio. The solution is to resample the audio and lose sound quality, which I'm not willing to do.
Triple buffering just blits the most recent image, if any, to the screen at this time.

Also, the SNES video in non-interlace runs at 60.09fps, and in interlace mode at 59.97fps. All other emulators run at 60.0fps, which is not correct according to the SNES stock specs. Triple buffering is the only way to handle that "extra" frame every ~11 seconds properly (basically, by skipping it). Plus, my triple buffering support has a bug that I can't find. When that's fixed, I'm certain the video will be just as smooth for you.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Dec 05, 2005 5:14 am Post subject:

Thank you, byuu, for this emulator. I just had one of the most enjoyable Earthworm Jim 2 experiences I've had on my computer.

Your emulator is definitely the go-to choice for games that need a highly accurate emulator, and, recently, people who need custom video modes.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Dec 05, 2005 6:35 am Post subject:

After having byuu explain the difference, I'm all for triple buffering over vsync if it can be done. Wish list for .016:

Working Triple buffering
DirectInput Pad2

Game Fixes
-------------
Mortal Kombat
Super Double Dragon
Dracula X
Death Brade
Ace wo Nerae!
RPM Racing
Wild Guns (ok, so I heard this was a bitch)

By the way, way to go on Rendering Ranger R2. That apparently works now.
Marty
Nestopia Developer
Nestopia Developer


Joined: 05 Dec 2005
Posts: 24

Posted: Mon Dec 05, 2005 1:33 pm Post subject:

byuu wrote:

One option is for me to add a D3D renderer, but those don't do fullscreen + menus.

Actually, they do support it if you tell them to. IDirect3DDevice9::SetDialogBoxMode(..) was added into D3D9 for this, which is essentially GDI support in fullscreen.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Dec 05, 2005 10:35 pm Post subject:

I didn't fix any CPU errors in the last release (that I remember), so Rendering Ranger R2 is still broken. And I just confirmed, it freezes at the start of a new level. Ace is a DSP-1 game.

Marty, thank you. I suppose I can start on a D3D interface, now. The big problem is that all of my old D3D code is for D3D8... minor differences, I'm sure, but I always hate having to redo all of that stuff v_v'
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Dec 05, 2005 11:24 pm Post subject:

Stupid question, but would D3D8 code work with Direct X 9.0c ?
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Mon Dec 05, 2005 11:32 pm Post subject:

Yes.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Mon Dec 05, 2005 11:46 pm Post subject:

That's what I thought, thanks Clements.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Dec 05, 2005 11:46 pm Post subject:

byuu wrote:
I didn't fix any CPU errors in the last release (that I remember), so Rendering Ranger R2 is still broken. And I just confirmed, it freezes at the start of a new level. Ace is a DSP-1 game.'


Thank you for taking the time to prove that I'm retarded. "SuPAr NinTeNdO derrrrr..."

I stand firmly behind the rest of my bug list... I think.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Dec 06, 2005 10:33 am Post subject:

Quote:
DirectInput Pad2

It can now poll the first 256 joypads in your system, and 128 buttons on each one (+4 for directional pad). So you can have up to 32k joypad buttons, plus your keyboard, to map to all 12*2 SNES buttons. Now I just need to add support for my PCTV Pro remote control (serial device with an IR sensor), and we're good.

Also lowered the strength on the x/y axes for the d-pad, makes doing combo moves in fighters a hell of a lot easier when using the thumb stick.

Also mapped the POV hat to the d-pad, so now digital and analog mode both work fine.

Genjuu Ryodan is another game that doesn't work right. HDMA problems.
Shinrin
Hazed


Joined: 19 Jan 2005
Posts: 73
Location: 127.0.0.1

Posted: Wed Dec 07, 2005 4:15 pm Post subject:

byuu wrote:
Quote:
DirectInput Pad2

It can now poll the first 256 joypads in your system, and 128 buttons on each one (+4 for directional pad). So you can have up to 32k joypad buttons, plus your keyboard, to map to all 12*2 SNES buttons. Now I just need to add support for my PCTV Pro remote control (serial device with an IR sensor), and we're good.


What the hell, is a hell of a lotta buttons you can use..

This emulator is getting on par with zsnes.
_________________

Get Fire Fox now! If not, get ready to put up with spy-ware and ad-ware! Surprised
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Fri Dec 09, 2005 1:07 am Post subject:

Tiny problem I've had with the Input (which may or may not be fixed with your recent post 0.15 changes but I'll post it anyway). I can't bind the Spacebar as a key.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Dec 09, 2005 3:46 am Post subject:

Seems to be working fine for me, but it triggers the button again right away. The variable is updated, though, so just select another button or close the window.
I'll see if I can make it wait a moment for the spacebar to be released when setting that button for the next release, thanks.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Dec 09, 2005 8:48 pm Post subject:

I thought I remembered reading somewhere that bsnes polled the joypads thousands of times a second for input. Is this right or wrong? How many times per second does bsnes poll the joypads for input.

My reason for asking is that bsnes feels more responsive than ZSNES while playing Donkey Kong Country 1. I feel my jump sequences and stuff are more precise and accurate in bsnes than in ZSNES.

I'd also like to note that DKC is perfectly playable at 30hz (the output for 1 frameskip), and bsnes is much more able to keep a steady speed with 1 frameskip.

Additionally, how much does output resolution affect speed for bsnes? Most of the time, I can get a fairly steady 60hz, but when bsnes does slow down, resolution doesn't seem to affect it. At least, 256x223 seems no faster than 1024x768. (I haven't experimented with resolutions above 1024x768).
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Dec 09, 2005 9:24 pm Post subject:

The input is polled whenever the SNES requests it, at exactly that time. All buttons are polled then. So it's usually 60 times a second, but it could be a lot more than that.

The video is scaled by hardware, so any resolution runs at the same speed, unless you turn off the video memory surface.

It may play fine with a frameskip of 1, but that's hardly an acceptable speed, especially in games where blinking animation is done by turning the sprites on and off after each frame :/
It shall have to be made faster, somehow...
Shinrin
Hazed


Joined: 19 Jan 2005
Posts: 73
Location: 127.0.0.1

Posted: Fri Dec 09, 2005 11:27 pm Post subject:

After here the ToP theme song being played over Zsnes and Bsnes.

The winner is: Bsnes.

The reason is that it's much clearer than it is with Zsnes, i guess because of the spc code they are using. some things do sound the same but. I can here some diffrents.
_________________

Get Fire Fox now! If not, get ready to put up with spy-ware and ad-ware! Surprised
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sat Dec 10, 2005 12:32 am Post subject:

byuu wrote:
But it lets you turn off the interpolation, unlike DirectDraw.
The other is for you to disable the "use video memory" under video options. Beware, you will lose a lot of speed.

So, is anything that is DirectDrawn interpolated? Or is this a video-card specific feature. As in, some cards interpolate all DirectDrawn stuff, some don't?

Also, whenever I uncheck "Use Video Memory Surface" in windowed mode, the video becomes very messed up. Is this normal?

byuu wrote:
the problem with my triple buffering code (since the SNES runs at 60.09 fps, it should skip one frame every ten seconds, but it seems like it gets jittery for 2-3 seconds every 10 seconds instead)

I haven't really noticed this problem. Does it occur during any time Triple Buffering is enabled, or only in combination with certain other conditions? What exactly are the symptoms?
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FirebrandX
Lurker


Joined: 19 Apr 2005
Posts: 128

Posted: Sat Dec 10, 2005 9:14 am Post subject:

[quote="byuu"]
Quote:

...that's what fullscreen mode is for. Edit bsnes.cfg and add a 512x448 video mode, and switch to that :/
No window border was one of the most annoying GUI things with ZSNES to me. If there's sufficient demand, I could add it, though.


Actually your suggestion to edit the cfg worked great! Thanks! I like being able to customize the cfg like that.

Quote:

It's your video card. ZSNES is way the hell faster, so it can handle copying 512x448 worth of video data to the card every frame. bsnes cannot, so by default it uses video RAM so it only has to copy 256x224 usually.
One option is for me to add a D3D renderer, but those don't do fullscreen + menus. But it lets you turn off the interpolation, unlike DirectDraw.
The other is for you to disable the "use video memory" under video options. Beware, you will lose a lot of speed.
I'm not at a point to start adding video filters (scanlines, HQnX, etc), but I will eventually.


That's what I was afraid of. I cannot stand interpolation. Maybe there's a way I can turn it off from my card's drivers (I have a Radeon 9800XT). I forget that in ZSNES, I use scanlines, which significantly reduces the look of interpolation from my card. However, if I go to a higher res, the interpolation becomes much worse on ZSNES as well. I admit I'm no fan of other video filters like "supersai" and "HQ2X" or whatever that stuff is called, but that's just because I prefer what reminds me of what I used to play from years back, hence the scan lines.


Quote:

Triple buffering is identical to vsync, but requires no CPU stall time. Both wait until the start of the vertical blanking period, and then blit the current image to the screen. The difference, and this is very important, is that vsync means you need to wait until the retrace period begins. This will prevent the sound system from receiving new samples and being updated, and it will align the refresh to your monitor instead of the emulator speed. The result is choppy audio. The solution is to resample the audio and lose sound quality, which I'm not willing to do.
Triple buffering just blits the most recent image, if any, to the screen at this time.


Ah I see. I had noticed in Gens, turning off auto frame rate and using strictly vsync caused the audio to become choppy at a ten-second interval. If I turned auto-frame rate back on, the sound would smooth out, but it caused a one-frame jump every ten seconds... Makes sense.

Quote:

Also, the SNES video in non-interlace runs at 60.09fps, and in interlace mode at 59.97fps. All other emulators run at 60.0fps, which is not correct according to the SNES stock specs. Triple buffering is the only way to handle that "extra" frame every ~11 seconds properly (basically, by skipping it). Plus, my triple buffering support has a bug that I can't find. When that's fixed, I'm certain the video will be just as smooth for you.


Cool. Maybe I should try programming in a 59.97 refresh rate mode with Power Strip. Or would that have any effect on the Gens example I gave?

Thanks for the info on how all this stuff works. Makes a lot of previous annoying problems I've dealt with make a lot more sense now.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 10, 2005 10:32 am Post subject:

Quote:
ToP intro ... The winner is: Bsnes.

Hell yeah it is. I remember the first time I heard the song in ZSNES, I thought it was supposed to be inaudible, heheh. It helps a lot now that ZSNES defaults to 32khz gaussian stereo. That wasn't always the case.

Quote:
So, is anything that is DirectDrawn interpolated? Or is this a video-card specific feature. As in, some cards interpolate all DirectDrawn stuff, some don't?

Also, whenever I uncheck "Use Video Memory Surface" in windowed mode, the video becomes very messed up. Is this normal?


I've already answered the first question. Scaling a video surface causes interpolation to be applied. Scaling a software surface does not because scaling is done by the CPU instead.

Yes, the messed up video is normal. I never re-added support for 32-bit software mode after the rewrite (v0.006+). bsnes always renders a 15/16-bit image to video RAM, and the hardware auto-converts it to 32-bit before drawing to the screen. This cuts the bandwidth in half. Solution? Set your desktop to 16-bit or use a hardware surface, or wait for the D3D renderer. Sorry about that.

Quote:
That's what I was afraid of. I cannot stand interpolation.


I'm currently trying to add Direct3D support, but I'm taking a major speed hit with the current code. And it's very well optimized, too. It's just... slower... than DirectDraw. Must be something I'm doing wrong...

Anyway, that gives you the option of using point filtering (e.g. what you want), bilinear filtering (yes, its always bilinear on a 2D image), some triangular thing, and gaussian quad filtering. Gaussian gives me a serious headache, and my nVidia card doesn't support it so it only works with the reference driver (e.g. < 1fps glory). Fun. Maybe a Matrox or a $600 nVidia or something would support it in hardware?
And all are nice and fast. I'm trying to think of a way to pull of true TV-style scanlines fully in hardware, but the D3D rendering style isn't very intuitive to doing that. I don't know how to say, blit a texture somewhere, then blit a scanline mask onto that, and then scale that image to fill the whole screen... D3D seems to want to draw all textures directly onto the backbuffer, or to surfaces which lack alpha blending capabilities (e.g. they're completely worthless).

Quote:
Cool. Maybe I should try programming in a 59.97 refresh rate mode with Power Strip.

60.09fps is non-interlace mode, 59.97fps is interlace mode. The former is more common, the SNES can swap between the two... even mid-frame, crazy and impossible as that may be. And I seriously doubt your monitor will have that kind of fidelity to control floating point-based refresh rates. If so, go for it, and good luck with that.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sat Dec 10, 2005 4:22 pm Post subject:

Quote:
This emulator is getting on par with zsnes.


Not to offend anyone here,but for me it allready surpasses it (though of course, it's all a matter of opinions)

I just tried 0.15 and it's just A-freakin'-mazing.

Someone mentionned that the input is more responsive than Z. Don't know the exact reason but it's true! With Bsnes the input react "au poil de cul" (with perfect accuracy iow) it react instantly with no delay at all.
. With Zsnes, there's a slight delay for some reason (with or without Triple buffering), no more than a frame or two but it's there. I never really noticed before because I had nothing to compare it to I guess.

I'm sure in time, Bsnes will have the recognition it deserve.





Btw, small request Byuu: Could you add a keyboard hotkey for the load rom dialog,reset and hardreset? Something like alt-o,alt-r,alt-h or something?


Last edited by Dmog on Sat Dec 10, 2005 5:30 pm; edited 1 time in total
aminalshmu
Hazed


Joined: 21 Jan 2005
Posts: 70
Location: America's Penis

Posted: Sat Dec 10, 2005 7:13 pm Post subject:

i'm looking for how to enable frameskip in the SDL port. this is the only reference i could find, and it's commented out:

from sdl/bsnes.cpp
Code:
void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
// if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
// if(w_main->frameskip != 0) {
// sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
// strcat(s, t);
// }
SDL_WM_SetCaption(s, 0);
// }
}


and as a total C++ noob, this function doesn't make much sense to me. any help?
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Sun Dec 11, 2005 4:42 am Post subject:

the stuff that's commented out looks to me like it just makes it so that it always displays fps and doesn't display the frameskip. It doesn't affect the operation of the emulation at all.

Code:
void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
// if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
// if(w_main->frameskip != 0) {
// sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
// strcat(s, t);
// }
SDL_WM_SetCaption(s, 0);
// }
}
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 11, 2005 5:02 am Post subject:

The SDL port has no GUI to toggle the frameskip rate, so you'd have to recompile it to change the frameskipping rate.

Still looking for a Linux-savvy programmer to write a basic GUI consisting of a menu bar, load ROM dialog, and a video output buffer. Preferrably one that can be scaled in hardware. Until then, I know nothing about Linux coding so that port will remain lousy. Using bsnes through WINE is a much better option.
aminalshmu
Hazed


Joined: 21 Jan 2005
Posts: 70
Location: America's Penis

Posted: Sun Dec 11, 2005 5:03 pm Post subject:

byuu wrote:
The SDL port has no GUI to toggle the frameskip rate, so you'd have to recompile it to change the frameskipping rate.

this is what i was getting at... I was looking for what to change so I could recompile with a frameskip. I only found that one reference to "frameskip" in the source though...
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Dec 12, 2005 12:19 am Post subject:

Try this:

Code:
int g_frameskip = 1; //2, 3, ...
int g_frakeskip_pos = 0;

void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
if(g_frameskip != 0) {
sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
strcat(s, t);
}
SDL_WM_SetCaption(s, 0);
}
}

g_frameskip_pos++;
g_frameskip_pos %= (g_frameskip + 1);
if(r_ppu->renderer_enabled())dd_renderer->update();
r_ppu->enable_renderer(g_frameskip_pos == 0);
}
aminalshmu
Hazed


Joined: 21 Jan 2005
Posts: 70
Location: America's Penis

Posted: Mon Dec 12, 2005 1:27 am Post subject:

Sad
Code:
c++ -O3 -fomit-frame-pointer -ffast-math -march=prescott -pipe -fno-rtti -c sdlmain.cpp `sdl-config --cflags`
sdlmain.h:17: warning: non-local variable '<anonymous struct> screen_info' uses anonymous type
bsnes.cpp: In member function 'virtual void bSNES::video_run()':
bsnes.cpp:21: error: 'gui' is not a member of 'config'
bsnes.cpp:31: error: 'g_frameskip_pos' was not declared in this scope
bsnes.cpp:33: error: 'dd_renderer' was not declared in this scope
../snes/snes.h: At global scope:
../snes/snes.h:23: warning: inline function 'virtual void SNES::runtoframe()' used but never defined
make: *** [sdlmain.o] Error 1

I hope to soon learn enough C++ to at least understand how to fix something like this... it seems pretty trivial.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Dec 14, 2005 6:57 pm Post subject:

Sweet, an update!
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Thu Dec 15, 2005 8:07 am Post subject:

Shinrin Alex Cole wrote:
After here the ToP theme song being played over Zsnes and Bsnes.

The winner is: Bsnes.

The reason is that it's much clearer than it is with Zsnes, i guess because of the spc code they are using. some things do sound the same but. I can here some diffrents.


You haven't heard anything yet...
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Thu Dec 15, 2005 8:26 am Post subject:

pagefault wrote:
Shinrin Alex Cole wrote:
After here the ToP theme song being played over Zsnes and Bsnes.

The winner is: Bsnes.

The reason is that it's much clearer than it is with Zsnes, i guess because of the spc code they are using. some things do sound the same but. I can here some diffrents.


You haven't heard anything yet...

How about this? http://nsrt.edgeemu.com/topintro.rar
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Dec 15, 2005 8:57 am Post subject:

byuu, in your eventual implementation of save states, do you have any interest in doing something like this?

grinvader wrote:
1- Easiest case once the binary 94-char packing is done in parsegen would be to use it to generate states. Each var would get assigned and read independently, any extra variable wouldn't be read and if a var was missing we could add an auto-initializer for those.
Big advantage: states would now be plain text and extremely easily editable for hacking or debugging, at the expense of a fair size increase.

_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Dec 15, 2005 9:05 am Post subject:

Nach wrote:
pagefault wrote:

You haven't heard anything yet...

How about this? http://nsrt.edgeemu.com/topintro.rar


Well, bsnes still sounds better in my opinion. But that's probably mostly due to the fact that your avi has lossy audio. Even with the lossy audio though, it's sounding a lot better than it old ZSNES builds. Great work, pagefault!
The only way we're going to be able to prove who the victor is now is by capturing the raw digital sound output from a real SNES and comparing :)
<evil> Now let's compare sounds in Earthworm Jim 2 ... </evil>

Quote:
byuu, in your eventual implementation of save states, do you have any interest in doing something like this?

Not really, but I don't think it'd be that hard to do...
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Thu Dec 15, 2005 10:23 am Post subject:

byuu wrote:
Nach wrote:
pagefault wrote:

You haven't heard anything yet...

How about this? http://nsrt.edgeemu.com/topintro.rar


Well, bsnes still sounds better in my opinion. But that's probably mostly due to the fact that your avi has lossy audio. Even with the lossy audio though, it's sounding a lot better than it old ZSNES builds. Great work, pagefault!
The only way we're going to be able to prove who the victor is now is by capturing the raw digital sound output from a real SNES and comparing Smile
<evil> Now let's compare sounds in Earthworm Jim 2 ... </evil>

Quote:
byuu, in your eventual implementation of save states, do you have any interest in doing something like this?

Not really, but I don't think it'd be that hard to do...



LOL, Give all the credit to Nach. We currently only have this sound working on movie writing. The entire realtime sound code is being rewritten turospeed now that we have this fixed properly. I still have yet to put my SPC noise fixes in as well.

Hopefully when everything is done we will have mirror copies of eachother in various things. I mean you could only do it that way if you want to emulate things accurately. But we (ZSNES) still have a long way to go on some things. Good luck with your continued work on bsnes, it's a great project.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Dec 15, 2005 10:37 am Post subject:

Quote:
LOL, Give all the credit to Nach. We currently only have this sound working on movie writing.

So that's an entirely rewritten sound core? If so, is it using anomie's DSP emulation code?

Quote:
Hopefully when everything is done we will have mirror copies of eachother in various things.

Agreed. And with all of the accuracy improvements in the new ZSNES builds... that's getting closer to a reality. As you know, you're welcome to use any and all of my code in ZSNES for however you see fit. BTW, that color add/sub code is mostly done if you wanted to look at it. Still need to run more tests on hires add/sub, though.

Quote:
Good luck with your continued work on bsnes, it's a great project.

Thanks. I am starting to wear out a little (mostly because I've been focusing on adding features instead of core emulation), but eh. Motivation comes and goes, I'll be fine.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Thu Dec 15, 2005 11:48 am Post subject:

byuu, you're missing the point. That AVI (aside from the lossy audio) demonstrates how ZSNES *really* sounds.
Unforunetly ZSNES doesn't send it's audio to the sound card properly, but I got it being sent to AVI properly, which you can hear good in any movie player which sends audio properly.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Dec 15, 2005 2:01 pm Post subject:

Ah, that's... odd.
Thanks for the clarification.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Thu Dec 15, 2005 2:56 pm Post subject:

byuu wrote:
Ah, that's... odd.

Not really, the sound code was deisgned for Sound Blaster 16. The Windows audio isn't great but okay, and the SDL thing is hack upon hack.

All I did was get the actual raw samples ZSNES generates and put then in the movie, ZSNES won't let you hear that on your speakers unless you have a nice PC with SB16 ISA on MS-DOS.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Dec 15, 2005 10:49 pm Post subject:

byuu wrote:
Thanks. I am starting to wear out a little (mostly because I've been focusing on adding features instead of core emulation), but eh. Motivation comes and goes, I'll be fine.

Please let your fanbase know if there's anything we can do to maintain/improve your motivation. Mr. Green
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Dec 16, 2005 12:31 am Post subject:

Jipcy wrote:
byuu wrote:
Thanks. I am starting to wear out a little (mostly because I've been focusing on adding features instead of core emulation), but eh. Motivation comes and goes, I'll be fine.

Please let your fanbase know if there's anything we can do to maintain/improve your motivation. Mr. Green


How about more bug reports? lol

Honestly though, you work so quickly as it is, and the amazing thing is you're fixing stuff without breaking other crap. If you keep this pace, I shudder to think of what we'll have in 6 months. Shocked

I also think it's nice to see sound getting some emphasis. The spc700 was such an amazing chip for its day... still is! And it was looking pretty hopeless for a while there... until bsnes came. woot!


Last edited by FitzRoy on Fri Dec 16, 2005 12:41 am; edited 1 time in total
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Fri Dec 16, 2005 12:34 am Post subject:

We could just temporarily lock this thread, until byuu catches up on what he wants to do with bsnes. Laughing That might slow down requests. Wink
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Fri Dec 16, 2005 2:23 am Post subject:

FitzRoy wrote:
Jipcy wrote:
byuu wrote:
Thanks. I am starting to wear out a little (mostly because I've been focusing on adding features instead of core emulation), but eh. Motivation comes and goes, I'll be fine.

Please let your fanbase know if there's anything we can do to maintain/improve your motivation. Mr. Green


How about more bug reports? lol

Honestly though, you work so quickly as it is, and the amazing thing is you're fixing stuff without breaking other crap. If you keep this pace, I shudder to think of what we'll have in 6 months. Shocked

I also think it's nice to see sound getting some emphasis. The spc700 was such an amazing chip for its day... still is! And it was looking pretty hopeless for a while there... until bsnes came. woot!


Hopeless? Things getting broken is not something anyone does on purpose. It is bound to happen to every emulator at some point.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Dec 16, 2005 4:57 am Post subject:

Actually I was referring to the sound with that. It was a new paragraph, after all.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Dec 16, 2005 11:40 am Post subject:

Quote:
Honestly though, you work so quickly as it is, and the amazing thing is you're fixing stuff without breaking other crap.

Part of it due to fixing things the "right way", part of it because it's a newer project. As it gets closer to perfection, the number of games broken by each fix will undoubtedly increase.

Quote:
I also think it's nice to see sound getting some emphasis.

Thank anomie, he wrote the sound core. I've just been fixing bugs in his code. As has DMV27.

Speaking of which, I really need to write that revised about dialog to give proper credits... and the advanced config dialog... and restructure the CPU core to be more modular... and write that readme file... and start on savestate support (don't expect that in the next 6 months).... and... ugh.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Dec 16, 2005 7:07 pm Post subject:

I personally don't use savestates that much, so I'm not too disappointed by that. Probably because I never used them on a real snes Wink

And yes, super thanks to anomie for his research and sound code. People helping each other = better emulators all around. Cool
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sat Dec 17, 2005 7:06 pm Post subject:

About your new updates, what is "raster size"?

Why is (7x * 21x/4) the best resolution?

Are the interlace/non-interlace modes standard for SNES emulators? Or is this a relatively uncommon emulation? I've just never heard about it before you started talking about it. I'm interested, because my only experience with interlacing is the interlaced/progressive-scan modes on TVs.

About the responsiveness stuff at the end, are you saying you just made a change that makes bsnes even more responsive?

Two (humble?) feature requests: 1. Do you think you could make an option to allow bsnes to remember its window position? It appears bsnes centers itself on screen every time you open it. 2. Is it possible you could put the loaded ROM name in the window title bar (and on the taskbar)?

Now, a possible bug report: Occasionally, when playing a game, the audio will start to get scratchy. This does not appear to be a result of sub-60 FPS. I will be maintaining 59-61 FPS, yet it sounds like sound samples are getting dropped. Turning up frameskip does not fix the problem. After several minutes of this scratchy sound, it will return to normal.

Oh, and finally, do you think you could have a pubicly accessible archive of your past news posts (about bsnes)? I really would like to read through them all, and it might interest other emulator developers about the process and SNES emulation in general.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Dec 18, 2005 4:42 am Post subject:

Raster size is video output. Say, at 640x480 resolution, you can specify the screen itself be drawn at 512x448 centered. 512x448 is the raster size. I sort of made the word up there, so don't feel too bad :P
Raster traditionally refers to the CRT beam cannon position, though.

1792x1344... the SNES resolutions are from 256x224 to 512x448. TV scanlines show approximately 70% luminance to 30% darkness. The best way to emulate that is to draw two solid scanlines to every one black line. That gives you 67% to 33%. Throw in some luminance on that black line (10% or so) and you're golden. Now for interlace, you darken the previous field by 30% each field. So for the former, your new resolution has to be a multiple of 3, and for the latter, it has to be a multiple of 2. That said, the only way you can do both cleanly with no stretching is to use a multiple of 6 (3*2). 224*6 = .... 1344! Also, notice that the height evenly divides into 1344. That means the scanlines won't get distorted when stretching to fix the aspect ratio. Speaking of aspect ratio... (4/3)*(224*6) = ... 1792! A perfect fit!

It's also a huge resolution, so you can even get away with point filtering to fix the aspect ratio and still have a good image.

I have tricks for other resolutions, too, but this one is just perfect. No other resolution is an even multiple of 224's height with no black borders on the top or bottom.

Yes, bsnes is infinitesmially more responsive to input vs. video updates. I doubt it's even noticeable, but hey.

Window position? Maybe. I kinda like it always centering, but it's doable.

Title in the window? I'd rather not... but another thing that's doable.

I don't know why your sound is skipping. Mine does that RARELY with the D3D renderer, but never with the directdraw renderer, even with triple buffering enabled. Don't know what to tell you :/
Anyone else having this problem?

Previous posts... I don't have any of the old ones archived, but it's doable in the future. I'm too lazy to write the archiving PHP code, and I don't want to move it all over manually :/
Not to mention, I don't always post when I find out my old information was wrong. I hate to make other developers go through the same process of bug tracking as I did. That's happened to me a lot reading over the 9x forums.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Tue Dec 20, 2005 10:45 pm Post subject:

byuu wrote:

I don't know why your sound is skipping. Mine does that RARELY with the D3D renderer, but never with the directdraw renderer, even with triple buffering enabled. Don't know what to tell you :/
Anyone else having this problem?


I played through Earthword Jim 1 the other night and noticed nothing of the sort. I do remember while playing King of Dragons, that almost on every sound effect there would be a crackling sound. Pretty annoying, but this could be normal behavior. I would need to hook up my digisnes to make sure. What makes me also think that this is normal is that sneese exhibits the same thing, and the Japanese version exhibits more pronounced crackling. I've seen this type of wierdness before between regions of roms. Super Aleste had more crackling in its music than Space Megaforce did. It's just bad, early sound code in the rom I think.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Dec 23, 2005 11:57 pm Post subject:

With the latest version of BSNES... I'm very impressed with the audio quality (albeit a little quiet, but whatever)... unlike .13, it syncs very well. Now only if ZSNES had it implemented (I'll definately be waiting until the newest WIP with the SPC fixes comes along).

As Nach said.. it does need savestate support.. what would really be nice is at the very least.. a definable save (.srm) location and some patching (.ips) support.

As for another bug I found:
Run Secret of Mana through its intro... to the text "and history repeats..." it then shows the overworld... and it is messed up.
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 24, 2005 12:08 am Post subject:

I don't touch the volume level, I use whatever the default is. Try adjusting your volume in the control panel, or turn up your speakers :/
Maybe a quick sound level option wouldn't hurt.

It has support for bpf patches now (see my homepage). I will not support IPS, because the format is irreversibly broken. I'm not going to play guessing games as to whether or not the IPS was created with a headered ROM or not. bpf always ignores the header in SNES games, among several other features.

I'll look at SoM, thanks.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Dec 24, 2005 1:10 am Post subject:

Here's a pic of the overworld from the Secret of Mana intro (as rendered in BSNES):


It seems like a transparancy/Mode 7/layering prob (I have no idea what exactly is the cause, but it looks to be a combination of the 3)

I hadn't given the obligatory screenshot in the Castlevania - Dracula X problem (as rendered in the current version of BSNES):


It seems like a transparancy/layering problem.

(Though, I myself am not able to figure out which are color addition/subtraction probs.. oh well.)
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 24, 2005 1:41 am Post subject:

Yeah, I saw it, thanks.

I don't know what's up with either of them. The odd thing about Dracula X is that the flame is on BG3 priority 1, and the bg3 priority bit is set. So by definition, nothing can come in front of it, and yet that seems to be the case in all other emulators. So somehow, the priorities are getting screwed. I'm thinking the game is adding in weird bugs when it detects a copier (or inaccurate emulation in this case), but eh. I really don't know.
Too bad none of the other emulators let you toggle specific priorities within background layers, or it would be trivial to find out what was going on here.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Dec 24, 2005 3:21 am Post subject:

Another bug, this time in Final Fantasy Mystic Quest:


As you can see, the damage number appears behind the character.. It is supposed to be in front of the character.
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 24, 2005 2:29 pm Post subject:

This is a sprite priority bug. Both the number and the character sprite appear on OAM priority 3.

Funny, I implemented anomie's notes on range-time over and sprite priorities verbatim. The only thing I haven't added was firstsprite+y priorities, because it doesn't make a damn bit of sense. And I seriously doubt that's what's causing this bug.

Ah well, I'll have to do my own tests to figure out what's wrong here. It's possible it's a bug in my implementation of his notes.
PiCiJi
Rookie


Joined: 30 Dec 2005
Posts: 15

Posted: Fri Dec 30, 2005 10:53 pm Post subject:

I have problems with the scrolling in bsnes. I am using Powerstrip to force 60 Hz. In Zsnes (with vsync) the scrolling is smooth all the time. In Bsnes (triple buffer) the scrolling is smooth too but each 5-10 seconds there are a few short annoying hicups in scrolling. Changing the sync rate to 59,94 (I wonder if this is the correct sync rate for ntsc TV consoles?) improves the hicup behaviour a little bit but the problem is still there.
xamenus
Zealot


Joined: 29 Jul 2004
Posts: 1218

Posted: Fri Dec 30, 2005 11:03 pm Post subject:

PiCiJi wrote:
I have problems with the scrolling in bsnes. I am using Powerstrip to force 60 Hz. In Zsnes (with vsync) the scrolling is smooth all the time. In Bsnes (triple buffer) the scrolling is smooth too but each 5-10 seconds there are a few short annoying hicups in scrolling. Changing the sync rate to 59,94 (I wonder if this is the correct sync rate for ntsc TV consoles?) improves the hicup behaviour a little bit but the problem is still there.
If you would read the bsnes changelogs or website, you'd know that the triple buffering code is buggy in .015.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Dec 31, 2005 2:12 am Post subject:

Triple buffering is fixed in v0.016, which has not been released yet. But with it on, the menubar does not render either in the DirectDraw or Direct3D renderer.

I'm sorry, but I don't have an estimate of when this version will be out. I haven't changed nearly enough to justify another release yet. This will probably end up being the second longest wait for a new release since the project began :(

For most games (that use non-interlace mode), 60.09fps is the correct speed. For games that use interlace (I can't think of any off the top of my head), 59.97fps would be the correct speed.

The next version of bsnes will simply drop one frame every ten seconds, which is nearly unnoticeable.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Dec 31, 2005 6:16 am Post subject:

Cool. So one question: are you saying that the menu bar will be rendered now that youre dropping 1 frame every 10 seconds, or was that just to make triple buffering work?
PiCiJi
Rookie


Joined: 30 Dec 2005
Posts: 15

Posted: Sun Jan 01, 2006 10:33 am Post subject:

thankyou for the info. I have used 60,090 Hz in Powerstrip for 800 x 600.
The hicup problem in scrolling has decreased. (almost perfect)
keep up the good work. This emu looks very promising.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Jan 04, 2006 6:51 am Post subject:

Argh, disappointing news regarding bsnes.

Ah well, money's good too. I myself feel the need to upgrade. I'll probably wait for the new socket AM2. Not that it'll perform better or anything...
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Jan 04, 2006 9:57 pm Post subject:

Well, I'm rather satisfied with the current release. It seems many future releases would be more about feature additions rather than the minute improvements in emulation accuracy.

byuu, don't let bsnes die! Let us know if there's anything we can do to help.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Jan 05, 2006 3:04 am Post subject:

As am I. Most of what I want is already implimented, and when .016 comes it will be even moreso. But it seems the remaining game bugs are going to be pretty tough to figure out. Where'd that dmv guy go? He seemed awfully comfortable with the code and even fixed a few things.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Jan 05, 2006 3:30 am Post subject:

Menubar either won't render or will flicker like mad with triple buffering enabled. It's fixable with D3D at least by changing the presentation settings when the menubar is toggled on and off, but I haven't gotten around to it.

No reason to wait for the AM2, really. Unless you can afford a $1000 processor for it. I'm just planning on buying an FX-59 or X2 4800+ when they are on the low end of the price spectrum.

A big help would be matching my 55+ hour/week salary, hell, I'd throw in a good 30+ hours for free :D
...of course, the only way that's hapening is if a certain console maker would hire me to develop an SNES emulator for their certain upcoming system (which might coincidentally advertise supporting the SNES) *cough*

Anyway, fixing the bugs is (even more) difficult because I haven't had a functioning debugger since v0.013. With the win32 rewrite, it's going to take a ton of code to get that thing up again.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Thu Jan 05, 2006 4:39 am Post subject:

I'm willing to do some profiling work to see where we could slim things down to try to improve performance.

Already built bsnes for linux with profiling and code coverage logging, and looked at some preliminary data.

Granted, the problem of profiling bsnes is made more difficult by the fact that different games will have (I'm guessing) wildly different time-intensive code paths.

So I guess what I should do is take suggestions for games that have sections that are slow, and probably shouldn't be, or games that don't use any extra chips or do any strange things, but get poor framerates.

Any ideas what games to start with?
Nightcrawler
Romhacking God


Joined: 28 Jul 2004
Posts: 1899

Posted: Thu Jan 05, 2006 2:50 pm Post subject:

I just built a new rig with a X2 3800+ running beyond 4800+ speeds at 2.5Ghz(didn't even get the chance to really push it beyond that yet.)

I've been meaning to give BSNES a try on it.
_________________
TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
ROMhacking.net - The central hub of the ROM hacking community.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Jan 05, 2006 5:00 pm Post subject:

byuu wrote:

...of course, the only way that's hapening is if a certain console maker would hire me to develop an SNES emulator for their certain upcoming system (which might coincidentally advertise supporting the SNES) *cough*


But then, that would mean the death of bsnes no? I'm pretty sure if you were to work as a programmer for Nintendo they would prohibit you from making an open source,free Snes emulator.

After all, it is Their (dead) console, and only They can make an emulator for it Rolling Eyes Rolling Eyes You all know how the big N is..

"All your emus are belongs to Nintendo"
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Fri Jan 06, 2006 3:03 am Post subject:

byuu -

I've done an early round of performance tests using different optimizations.

Test setup:
Athlon64 3000+ socket 939 processor
256MB of RAM
Gentoo Linux 64-bit
gcc version 3.4.5
glibc version 2.3.5

Modified sdlmain.cpp loop to only run 400 frames
Build bsnes_sdl using -O2 and -O3
Timed running first 400 frames of Secret of Mana 6 times in a row, and kept the times for the last 3 executions
Timed running first 1000 frames of Secret of Mana 6 times in a row, and kept the times for the last 3 executions

Results:
Compiled with -O2
400 loops total time for the three runs: 0m13.154s
1000 loops total time for the three runs: 0m32.625s
Compiled with -O3
400 loops total time for the three runs: 0m13.576s
1000 loops total time for the three runs: 0m33.804s

I repeated the same tests, but adding things like -funroll-loops, generating profiling data, etc

I consistently came up with about a 3.2-3.6% speed improvement by using -O2
I consistently had worse performance with -funroll-loops

Conclusions:
I went into this guessing that O3 would give slightly worse performance because this has been noted before with many other software packages on Linux. I expect this to be the case across the board with gcc < 4.0. I'm not willing to make any guesses as to how gcc4 does with O2 vs. O3.
Jagasian
Rookie


Joined: 15 Oct 2004
Posts: 24

Posted: Wed Jan 18, 2006 6:31 pm Post subject:

Cycle accurate SNES emulation? I wish I knew about this earlier. I had given up on SNES emulators, which are notorious for being inaccurate. NES emulation has Nintendulator and Nestopia, which are both cycle accurate, and I just assumed that the popularity of SNES9x and ZSNES would prevent any revolutionary progress in SNES emulation (such as cycle accuracy). The sad thing is that the casual gamer doesn't care very much about cycle accuracy, unless they notice the lack of it, such as their game doesn't run or doesn't run correctly or it looks like ass, sounds like ass, etc.

I am bookmarking the bsnes page. http://byuu.cinnamonpirate.com/?page=bsnes
Please keep the project alive. Once bsnes reaches a critical mass (of users, features, and game compatibility), hopefully it will become the new base standard for SNES emulation and get ported to every platform under the sun as is the case with SNES9x and ZSNES.

I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable?
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Jan 18, 2006 6:55 pm Post subject:

Jagasian wrote:
and get ported to every platform under the sun as is the case with SNES9x and ZSNES.

Uh, what? ZSNES has three ports. Windows, DOS, SDL. Just fyi, ZSNES is incapable of running on a non-x86 CPU.

Jagasian wrote:
I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable?

I have a feeling there needs to be a lot more work on getting ANY homebrew app to run on the 360, before bsnes is ported.

But, seeing as how it is written entirely in C++, it should be less hard than other more poorly programmed emulators.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Wed Jan 18, 2006 8:23 pm Post subject:

Jagasian wrote:
Cycle accurate SNES emulation? I wish I knew about this earlier. I had given up on SNES emulators, which are notorious for being inaccurate. NES emulation has Nintendulator and Nestopia, which are both cycle accurate, and I just assumed that the popularity of SNES9x and ZSNES would prevent any revolutionary progress in SNES emulation (such as cycle accuracy). The sad thing is that the casual gamer doesn't care very much about cycle accuracy, unless they notice the lack of it, such as their game doesn't run or doesn't run correctly or it looks like ass, sounds like ass, etc.

I am bookmarking the bsnes page. http://byuu.cinnamonpirate.com/?page=bsnes
Please keep the project alive. Once bsnes reaches a critical mass (of users, features, and game compatibility), hopefully it will become the new base standard for SNES emulation and get ported to every platform under the sun as is the case with SNES9x and ZSNES.


SING IT BROTHA'! (Seriously though, totally agree)

To be fair Zsnes is becoming more accurate. But it's a long,long process I guess. The project (Z I mean,or rather, all who worked on it) has done a lot for Snes emulation.

Quote:
I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable?


Don't own a 360 but judging by the spec I'd say probably. Though the "Three symmetrical cores running at 3.2 GHz each" (there's three cpu@ 3.2Ghz inside?) would probably be useless for such a program.
I doubt bsnes could take advantage of the other two core, the same way Mame cannot really take advantage of dual core PCs.

And I have no idea how difficult it would be to port it to the 360


Last edited by Dmog on Wed Jan 18, 2006 9:23 pm; edited 2 times in total
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Jan 18, 2006 8:45 pm Post subject:

On the other hand, SNES emulators may be uniquely positioned to take advantage of hyper-threading / dual processors. Since SNES emulators already have to emulate multiple CPUs simultaneously, there might be significant speed gains if you could emulate each SNES cpu on its own PC cpu.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Wed Jan 18, 2006 9:10 pm Post subject:

Jipcy wrote:
On the other hand, SNES emulators may be uniquely positioned to take advantage of hyper-threading / dual processors. Since SNES emulators already have to emulate multiple CPUs simultaneously, there might be significant speed gains if you could emulate each SNES cpu on its own PC cpu.


That's been (overly) discussed in the Mame forum.
There's no speed to be gain even with arcades that uses multiple Cpus. I don't see why this would be different for Snes emulation.

I think there's an article in Aaron Giles's blog somewhere that explains in great details why this is so.

Some of this stuff is a bit beyond me, but basically: I think even if you emulate multiples (virtual) Cpus on multiples (real) Cpus you still have to sync them so that they communicate with each other (if you care even a tiny bit about accuracy at least). And this process of syncing them defeats the speed gain you just obtain. The multiple Cpus end up running as only one Cpu so to speak,but their power is not combined.




Dual cores works well with stuff that doesn't need real syncing. If you're trying to brute force some algorithm for example,or encoding a video or heck, running an OS.


edit:
Oh No! I actually noticed that this is my 256th posts! I'm becoming a nerd! Guarhh!
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Jan 18, 2006 9:40 pm Post subject:

There's no disrespect to ZSNES in saying that bsnes represents the new breed of snes emulators. As cpu power increases, cycle based for the snes becomes feasible from an enjoyment standpoint. We can play at full speed with what is considered budget today in tech. ZSNES will still have a larger userbase for some time yet, despite the fact that a fast computer costs a fraction of what it did 5 years ago.
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Thu Jan 19, 2006 1:51 am Post subject:

that's been an excuse for lazy coding for a long time. the fact that faster processors will still be able to spit out 60 fps, even though they're code is a steaming mess.

nothing against anyone here, i just hate hearing that as any kind of feasible reason for anything it shouldn't be.
_________________
Jagasian
Rookie


Joined: 15 Oct 2004
Posts: 24

Posted: Thu Jan 19, 2006 2:39 am Post subject:

I realize it is restricted to x86, thanks for stating the obvious. ZSNES is ported to far more platforms than many other emulators, which are Windows-only. That was my point. As a Linux user, having a Linux and Windows port is just about every platform I'd care for. Though a console port (I have no bias), is also nice for an inexpensive solution for playing the games on a big screen TV.

Anyway, cycle accuracy is the next step. You can't fault ZSNES for lacking it because ZSNES was first coded many many years ago, when hardware could barely run it at full speed. It is nice to see SNES emulators following the progression that NES emulators have taken. Fast, but inaccurate (Nesticle, etc). Later followed by more resource intensive yet cycle accurate emulators (Nestopia, Nintendulator).

Those that say you can't tell the difference between cycle accurate and not cycle accurate simply having compared emulation side-by-side with a real console. For some games that I have played for years on a real SNES, I don't even need a side-by-side comparison. For example, Super Mario Kart in SNES9x or ZSNES... I can tell the difference in a blind (can't see the hardware) "taste test".

I hope that bsnes soon becomes the standard for SNES emulation. ZSNES vs SNES9x flamewars will be a thing of the past.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Jan 19, 2006 2:46 am Post subject:

sweener2001 wrote:
that's been an excuse for lazy coding for a long time. the fact that faster processors will still be able to spit out 60 fps, even though they're code is a steaming mess.

nothing against anyone here, i just hate hearing that as any kind of feasible reason for anything it shouldn't be.


True, but with bsnes (I'm not saying you were talking about bsnes but FitzRoy's comments were refering to it) that's not the case.

It's slow because it's extremely accurate and because it's not written in assembler. A cycle-accurate Snes emu is simply not gonna run full speed on a PII 500Mhz even if you optimize the shit out of it (that's my non-programmer impression at least).
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Thu Jan 19, 2006 5:15 am Post subject:

This I realize. That comment is just one of my hot-buttons, and I couldn't stop myself.

I've tried bsnes, and I enjoy it, but I currently prefer zsnes, for feature and speed reasons.
_________________
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Jan 19, 2006 6:26 am Post subject:

Lots of replies... neat.

Thanks DataPath. I'll be sure to use -O2 for the gcc port.

The only thing more than one CPU would do for bsnes is allow me to use the other(s) for software video filtering.

bsnes most certainly isn't as optimized as it could be. I was going more for readable code, but I definitely could've made better choices even with that in mind. I'd say 1.2ghz for fullspeed would be the best I could manage in pure c++ with no reduced accuracy, probably around half that or a little more with assembler thrown in. And that's just guessing. Who knows.
This is of course assuming I were to keep the crap inaccurate scanline renderer in there now.

And I appreciate the complements, but bsnes still really isn't that hardware accurate. We can call it accurate when/if I write the dot-based PPU renderer.

IF bsnes gets as popular as zsnes / snes9x, then you'll just have ZSNES vs SNES9x vs bsnes flamewars. I doubt that will ever happen, though.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Thu Jan 19, 2006 3:07 pm Post subject:

Byuu - when I get some time (hopefully this weekend) I intend to go through and clean up the arrangement of the source code - i.e. make it so that .cpp files aren't included in .cpp files, be consistent about variable types throughout the code (uint, uint32, etc will be changed to a more standard uint32_t type throughout the code. IIRC, msvc doesn't define these, even though it should in <stdint.h>, so I'll have an ifdef for MSVC and define them properly).

There's some crazy inlining going on that I'd like to fix up, but it's hard to track everything down to make sure that it gets fixed properly, thus the source code cleanup.

Inlining should be used carefully, because used improperly it CAN slow down code, so I will probably also profile the speed with inlining turned off.
Jagasian
Rookie


Joined: 15 Oct 2004
Posts: 24

Posted: Thu Jan 19, 2006 5:41 pm Post subject:

byuu wrote:

And I appreciate the complements, but bsnes still really isn't that hardware accurate. We can call it accurate when/if I write the dot-based PPU renderer.


I say go for it. As of now, most people will continue to use ZSNES anyway because the average user has a shite PC and likes feature-bloat. What is needed is a new emulation core for the future of SNES emulation. You might as well go all the way with regards to accuracy, readability, and portability, even if that means today's top of the line PC can't even run it at full speed. PC hardware will eventually catch up, and when it does, the portable bsnes core can be used in whatever feature-bloated SNES emulator somebody decides to make. Kind of like the Gecko HTML core used in Mozilla, Firefox, Netscape, etc. The GUI, networking, pixel filters, peripherial supprt, etc, can be included by 3rd party emulators that use the bsnes core, and that way bsnes core can concentrate on being 100% cycle accurate and not waste its time with feature-bloat.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Jan 19, 2006 6:27 pm Post subject:

Byuu might be getting burned out of that kind of thing, but yes, there is still some emulation stuff. New debugger->game fixes, dot-based render, dsp1234. You can do whatever you want though, I'm just being a whiny fanboy. Wink
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Sat Jan 21, 2006 8:52 pm Post subject:

all features are not bloat. holy cow.
_________________
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Jan 21, 2006 10:40 pm Post subject:

Certainly not. Triple buffering, savestates = gold.

I'm not entirely sure what Jagasian wants, but I doubt byuu is going to let a bunch of third party spinoffs come out. Doesn't really sound like there's much of a purpose to that there. Seems better to just let people contribute to bsnes for things byuu does not plan to add.
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Sun Jan 22, 2006 11:09 pm Post subject:

One thing I'd to know is why it takes [I'm exaggerating here] years for bsnes to actually get to doing anything overt.

After about a minute or so, FFV [unpatched] gets around to playing, but I haven't gotten Super Mario RPG to play yet.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Sun Jan 22, 2006 11:56 pm Post subject:

iirc the SA-1 chip isn't emulated yet

at least not in bsnes anyway
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Mon Jan 23, 2006 12:27 am Post subject:

The problem with implementing certain special chips (SA-1, SuperFX in particular) is that exist code for emulating them is currently horribly buggy and imperfect in all the emulators that have support for it.

Byuu's aim is to make the emulator as perfect as possible, and not implement the imperfect code that exists right now for the sake of getting some games working. The S-DD1 had accuate code for it already well documented, so adding this chip wasn't as big of a problem.

Byuu is also coding the emulator mainly for himself, and probably does not want to code a bunch of features which detract him from the whole purpose of this emulator - accurate emulation above everything else. It is a privilege that he has shared his work with us. If you desperately want a certain feature to be added, then it will need to be coded by yourself.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Mon Jan 23, 2006 1:50 am Post subject:

Aerdan wrote:
One thing I'd to know is why it takes [I'm exaggerating here] years for bsnes to actually get to doing anything overt.

After about a minute or so, FFV [unpatched] gets around to playing, but I haven't gotten Super Mario RPG to play yet.


Your post was not particularly coherent but I think I got the gist of it.

The reason "it takes [you're exaggerating here] years for bsnes to actually get to doing anything overt" is because your computer is not fast enough.

Currently,bsnes needs something like a P4 2.0ghz up to 2.8ghz to achieve full speed with 0 frameskip.

Sa-1 isn't implemented, so you'll have a hard time playing SM Rpg.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Jan 23, 2006 7:47 am Post subject:

I'm also too lazy and time-constrained to add SA-1 emulation. I doubt I could pull off cycle-stepping with an ~11mhz 65c816 in addition to everything else, too.

Hm, there could be a bug that causes it to take several minutes (or whatever) for games to start for you. Anyone else notice this?
Things start quickly even on this 600mhz laptop, they just don't run quickly once they do ;)
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Mon Jan 23, 2006 8:41 am Post subject:

Aerdan:
The second-to-last section of this page has more info about the speed problem.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Mon Jan 23, 2006 8:59 am Post subject:

What special chips are well documented? DSP project, I'm assuming, is near perfect by now, yes?
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Mon Jan 23, 2006 7:31 pm Post subject:

Okay, well, I figured I'd ask, since Seiken Densetsu II/Secret of Mana loads almost immediately, while FFV [as I mentioned before] does not. I'd need to do some more testing with other SNES roms, but the ones I've mentioned thus far [and Super Metroid] are currently the only ones I have on this machine.

[EDIT: And yeah, I forgot Super Mario RPG uses the SA-1. Oops.

I think I'll start working on a compatibility list for bSNES, then, if that's okay; mainly so everyone knows what does and doesn't work.]

[EDIT 2: If it matters any, my current system specs are:

Sempron 2400+ [currently manually clocked at 1.52GHz [as otherwise my mobo'd have clocked it at 1GHz O.o]
GeForce FX5200
768MB RAM [1x 256MB, 1x 512MB]

Emulation is steady at 60fps once ROMs load, so I think your estimate about minimum/recommand processor speed is a bit high.]
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Tue Jan 24, 2006 1:28 am Post subject:

A compatibility list would be appreciated.

The specs are high due to games like Star Ocean and Mega Man X2 which require additional processing power. And then there are games that use hires, e.g. SD3's name entry screen.
I can just barely hold ~70fps with full optimizations on an Athlon 64 3500+ that isn't overclocked in hires games...
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Tue Jan 24, 2006 7:38 pm Post subject:

Aerdan wrote:

I think I'll start working on a compatibility list for bSNES, then, if that's okay; mainly so everyone knows what does and doesn't work.]


Hopefully, you mean a list of what doesn't work, from which we can infer what does work. A list of what does work would be really dang long.
PiCiJi
Rookie


Joined: 30 Dec 2005
Posts: 15

Posted: Sat Jan 28, 2006 8:39 pm Post subject:

only for interest. Are there books how a Snes works? Where do you get the basics for understanding how a Snes works? I don't mean the knowledge what a cpu register does or what a opcode is and so on, only snes specific.
sorry english isn't my first language.
Nightcrawler
Romhacking God


Joined: 28 Jul 2004
Posts: 1899

Posted: Mon Jan 30, 2006 1:44 pm Post subject:

PiCiJi wrote:
only for interest. Are there books how a Snes works? Where do you get the basics for understanding how a Snes works? I don't mean the knowledge what a cpu register does or what a opcode is and so on, only snes specific.
sorry english isn't my first language.


There are lots of SNES hardware specific docs on the net. Here are several good ones.

ROMhacking.net SNES Hardware Docs
_________________
TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
ROMhacking.net - The central hub of the ROM hacking community.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Wed Feb 01, 2006 12:01 am Post subject:

Slighly OT, there was some talk of console emulation in general in the Mame forum (R. Belmont apparently is a big fan of bsnes)

Anyway, there was a mention about how poor apparently the current Snes Rom format was...anyone (Nach,Pagefault,Byuu,Grinvader or any knowledgable person) care to explain/have a thought on this?
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Feb 01, 2006 12:19 am Post subject:

MK has been saying the same thing for years.
We really lose some hardware info when we only have the ROM image.

MK wrote up a spec for a new format, which got some people ticked off. I have his spec still, and perhaps byuu and I can actually do something along those lines one of these days.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Feb 01, 2006 2:33 am Post subject:

I would absolutely love to.

Overload has a great idea and is documenting all of the cart PCBs. If we could merge that info into NSRT and generate a set of ROMs with that info in it, it would do a lot for ROM detection and handling special mappers such as Ys III's SRAM.

Of course, we could also use an external database with a crc32 lookup too, if inserting into ROMs isn't good.

Nach, if you'll add the new spec to ZSNES and/or SNES9x, I'll add it to bsnes.
Reznor007
Regular


Joined: 30 Jul 2004
Posts: 229

Posted: Wed Feb 01, 2006 2:56 am Post subject:

I still like the idea of a dedicated ROM database like MAME has where the ROM file names match stamps/labels on the actual ROM chips, and each game is clearly setup with all needed information. There is no need for any kind of header this way, and special things like extra CPU's or special SRAM setups are easy to detect.

You could still have a special load option for homebrew/test roms/hacks/etc., but for the commercial stuff have a fully documented list.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Feb 01, 2006 2:58 am Post subject:

If we can agree on a ROM spec, and have some DB info, I'll add it to NSRT for mass conversion, and make a lib for ZSNES and Snes9x, possibly SNEeSe too.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Feb 01, 2006 4:21 am Post subject:

Sounds good. I'll start on the basics tomorrow. I would like to allow it to define the entire ROM map, but in 512 bytes that'd be pretty hard unless we include arbitrary numbers (e.g. a 32-bit mapper number) to pull that info from a database with.
Then again, no reason we have to limit the header to that size.

Nach, can we meet up this weekend? I'd like to finalize the patching thing, if possible.

Also, I need to start on getting the synchronization more accurate than it currently is. I need to allow the PPU to run every 4 CPU clocks to prepare for the dot-based renderer, and break CPU / APU opcodes into "half-cycles" to emulate the bus hold times for read/write operations. That's going to take an insane amount of planning to pull off without doubling the system requirements :/
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Feb 01, 2006 5:25 am Post subject:

byuu wrote:
to prepare for the dot-based renderer

Sweet Jesus! (Now with more sodium!)
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Wed Feb 01, 2006 11:20 am Post subject:

byuu wrote:
Sounds good. I'll start on the basics tomorrow. I would like to allow it to define the entire ROM map, but in 512 bytes that'd be pretty hard unless we include arbitrary numbers (e.g. a 32-bit mapper number) to pull that info from a database with.
Then again, no reason we have to limit the header to that size.

Did I ever pass you MK's spec?

byuu wrote:

Nach, can we meet up this weekend? I'd like to finalize the patching thing, if possible.

I should be around Sunday.
_________________
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


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Wed Feb 01, 2006 1:11 pm Post subject:

byuu wrote:
[...] That's going to take an insane amount of planning to pull off without doubling the system requirements :/

Maybe you could keep both renderers, via two builds or even switchable at runtime? You really shouldn't worry about system requirements.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
oxid
New Member


Joined: 01 Feb 2006
Posts: 2

Posted: Wed Feb 01, 2006 8:48 pm Post subject:

For reference, here are the posts on MAME forums about roms formats and console emulation state-art:

Mame thread #1

Mame thread #2

byuu wrote:
I would like to allow it to define the entire ROM map, but in 512 bytes that'd be pretty hard unless we include arbitrary numbers (e.g. a 32-bit mapper number) to pull that info from a database with.Then again, no reason we have to limit the header to that size.


I think the problem is not about head limitation but head itself. We need an independent database file with the info needed by the emulator to be able to execute the rom. We don't need rom heads , like Renzor007 told some posts above. Rom is only rom data found in the cartridge chips... no more no less. The head is extra information needed/added by copiers. If we add extra info in form of head: what's up if we change the head format or some rom info? massive conversion of all/some roms every time? Let roms rest in peace... headless Wink. We only need to update the database file when change the spec or rom info, but the rom itself must rest intact. I think NSRT team (Nach et al) and emulators authors like Byuu, Overload,... must define this database spec and the NSRT Team mantain the info needed for each commercial rom.

The database file must be in a separated file (like Overload database) and the emulator only need to read this info to know the extra rom info needed to executed the game. The emulator don't need to determine 'every time' all this rom info when the rom is perfectly known. The format of the file could be a simple ini file (like Haze points on mame forum) or something more interesting like an XML file with an associated XSD schema.

The problem of the rom names exposed by Reznor or Haze (mamedev), that is to say, to have separated files for each chip with its name associated is perhaps a little more difficult to solve since dumps of snes roms has been made from copiers, that linearly reads all the memory map. Re-dump all the cartridges one by one to obtain the data of each chip again separately is a serious & tedious problem Wink. Although perhaps it's possible to rebuild that information from present dumps and cartridge pcb-number. In any case I see it somewhat unnecessary.


That's my 2 cent about the subject
Sorry for my poor 'engrish'

PD: Completely off-topic: big thanks anomie for your superbs snes docs.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Feb 01, 2006 11:42 pm Post subject:

Agreed. No headers, then.

Breaking carts into individual ROM files is stupid if we also have an ini. We can just document what each region of the whole binary file points to.

Example: Game X contains 1x8mbit ROM, 1x4mbit ROM, 1x1mbit SRAM

game_x.ini =
Code:

crc32=0xdeadbeef
title="Game X"
publisher="Nintendo"
region="US"
language="EN"
genre="Action"

;below is a linear breakdown of the file
[rom]
size=8mbit
;do we need ranges in case some ROMs get clipped?
map="$c00000-$cfffff"
map="$e00000-$efffff"

[rom]
size=4mbit
speed=120ns ;overkill?
map="$d00000-$d7ffff"
map="$d80000-$dfffff"
;how about implied mirroring when map size > rom size? e.g.
map="$f00000-$ffffff"

[sram] ;not actually stored in cart, although we could change that... ;)
size=1mbit
map="$700000-$701fff"
map="$702000-$703fff"
...

[dsp1b]
dr="$006000-$006fff"
sr="$007000-$007fff"



Obviously, better ways to represent mapping could work, too. Perhaps store pinout information to the address lines for each ROM? Perhaps use regex style ranges? e.g. map="[$00-$3f]:$6000-$7fff"
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Thu Feb 02, 2006 12:51 am Post subject:

Those that don't learn from history are destined to repeat it.

byuu, come online we'll talk, there's been interesting info on this subject that's been documented.
_________________
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


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Wed Feb 08, 2006 12:26 pm Post subject:

Update!
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 09, 2006 6:30 am Post subject:

Yeah I don't like these new updates. I can understand them Laughing

Killed me when he talked code all the time. Nice to see you got a new card, byuu. Dig the gaia shot, too. Game rocks. Don't tell me it was random now, cuz I'll cry.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 09, 2006 6:44 am Post subject:

It's because I'm too busy mucking with GUI features instead of working on the core like I should be... :/

I wanted v0.016 to be a mostly cosmetic upgrade. After that's out, it's back to the internals. Planning to split the CPU (and possibly APU) core down into half-cycles so I can synchronize bus hold times between the two. It'll also be needed for a dot-based PPU renderer to be able to dot-step, so to speak.
Not looking forward to all the shit that's invariably going to break...
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Feb 12, 2006 1:40 am Post subject:

This might sound stupid, but if dot-based is making things more accurate, why would the smaller breakdowns result in more bugs?
error999
New Member


Joined: 07 Feb 2006
Posts: 5

Posted: Sun Feb 12, 2006 3:17 am Post subject:

Are you gona add filters like HQ2X or openGL. also, save states? love the emu great work!
_________________
The 2 cowboys have emerged.
beware of forum trolls.

Joined: 28 Dec 2004
Posts: 605 <------


Last edited by error999 on Sun Feb 12, 2006 7:32 am; edited 1 time in total
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sun Feb 12, 2006 4:09 am Post subject:

Leave your puerile feature requests out of this thread.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
error999
New Member


Joined: 07 Feb 2006
Posts: 5

Posted: Sun Feb 12, 2006 4:20 am Post subject:

Jipcy wrote:
Leave your puerile feature requests out of this thread.


Maybe you have a reading problem, let me quote my self. "Are you gona add filters like HQ2X or openGL. also, save states? love the emu great work!" key word ARE!.

Pointing out the obvious....


I can bash you all day long, but i have no time for little forum trolls.
_________________
The 2 cowboys have emerged.
beware of forum trolls.

Joined: 28 Dec 2004
Posts: 605 <------


Last edited by error999 on Sun Feb 12, 2006 7:29 am; edited 1 time in total
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Sun Feb 12, 2006 4:35 am Post subject:

Error - just to update you - the main goal of bsnes isn't to have a fancy, pretty emulator to take the place of Snes9x or ZSNES, but to have an extremely accurate emulator with good debugging facilities.

In concept, bsnes is aimed at romhackers.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sun Feb 12, 2006 5:00 am Post subject:

In an pathetic attempt to be amusing by overlaying an image over an existing avatar, you have failed.

Seriously though.. BSNES's primary goal is for accurate emulation at this point.. not adding features most other emulators already have (I do agree the savestates are probably the most lacking feature at the moment) but don't expect anything fancy just yet.
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Feb 12, 2006 6:09 am Post subject:

More bugs because I have to rewrite everything. You never get things right on your first try.

The emulator can't handle HQ2X at full speed, at least not on my computer, so probably not. But maybe, it would be good to at least get a single filter in there so others can contribute the code for other filters for me.

I'll add savestates when I finish the core to 99% certainty. e.g. new pretty much everything :/
Otherwise, I'd have to keep changing the spec.

Anyway, v0.015 is basically about adding GUI features, unfortunately. I need time to plan out how I want to rewrite everything, and when I start it'll be a long time before I can release a new version after that. That said, I have pretty much everything I want done for v0.016. The one I want that would be a royal pain would be to allow GUI key configurations for everything that also worked with joypad mappings. Just a lot of annoying recoding involved to pull that one off.
error999
New Member


Joined: 07 Feb 2006
Posts: 5

Posted: Sun Feb 12, 2006 7:40 am Post subject:

befour Deathlike2 and the other troll turn this into a flame topic.

Wouldent bilinear filtering be easy to add into directdraw, corect me if im wrong. becouse ddw could do this as defalt no? _<(still new to this kind of stuff). i like how clean the source is it's not to hard to find what you need, im tryen to add in some stuff that i wont with my copy, wich gives reason for my asking if you where befour i atemped to even try to add.
_________________
The 2 cowboys have emerged.
beware of forum trolls.

Joined: 28 Dec 2004
Posts: 605 <------
Agozer
16-bit Corpse | Nyoron
<b>16-bit Corpse | Nyoron</b>


Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land

Posted: Sun Feb 12, 2006 12:54 pm Post subject:

"ok"
_________________
My site with random stuff

whicker: franpa is grammatically correct, and he still gets ripped on?
sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sun Feb 12, 2006 2:55 pm Post subject:

error999, you are sounding more like the troll.. I've contributed some towards this topic.. and frankly you're acting very much like you are holier than everyone... the lame avatar and the lame sig pretty much shows that.

byuu wrote:
I'll add savestates when I finish the core to 99% certainty. e.g. new pretty much everything :/
Otherwise, I'd have to keep changing the spec.


Well, seeing as the savestate spec in ZSNES has changed quite a bit post-1.42, I guess I can't blame you there.

Quote:
The emulator can't handle HQ2X at full speed, at least not on my computer, so probably not. But maybe, it would be good to at least get a single filter in there so others can contribute the code for other filters for me.


Really? That really does suck.. I'm sure at some point you might spend time optimizing (though, I don't see that happening anytime soon) and make this a more reasonable possibility. Bilinear filtering is still better than nothing I suppose. Getting HQ4x enabled all the time does spoil me a bit.
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Feb 15, 2006 1:34 pm Post subject:

Alright, please take a look at the following diagram:
Diagram

(This also makes a good reference to show more what I'm referring to when I say that bsnes is a cycle-based emulator.)

And read this for a more thorough explanation:
http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods

I'd like to get some feedback on which CPU emulation method I should implement into bsnes. The subcycle one or the clockcycle one?
The big advantage of the clockcycle one is the decreased code complexity (and thus, greater readability), especially in updating all of the H/V counter information, and triggering NMI/IRQs.
But it doesn't add any additional "accuracy" per se, and is quite a bit slower.

One or the other is necessary if I ever hope to get a highly accurate dot-based PPU renderer.
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Wed Feb 15, 2006 2:59 pm Post subject:

I'd say, if you think you can write a "perfect" clockcycle emulator, and it's more readable, then do that. It would be the perfect platform for researching more into nitpicky details of SNES operation, and it would provide a perfect reference implementation for ANYONE to write their own SNES emulator. They could even just start by writing their own core class, and plugging it into your emulator, taking advantage of the object-oriented scaffolding you have.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Feb 15, 2006 8:52 pm Post subject:

I'd say go all the way to clockcycle-based interpretation. There's nothing "more" accurate than that is there?

Don't give in to the Need for Speed. You can perfect the emulator now, even if it can't run full-speed. Hell, maybe the overclockers will start using it for benchmarks.

Would the simpler code of a clockycle vs. subsycle interpretation mean it would be easier to optimize it in the future?
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Feb 15, 2006 9:52 pm Post subject:

I don't know squat about code, but after reading that I have to vote for subcycle. You said it yourself - clockcyle is no more accurate than subcycle, and is a lot slower. Code readability doesn't seem like a worthwhile tradeoff for that. In this way, I see subcycle as being a huge optimization in and of itself.

Also, on the subject of changing anything at all. The buglist we've compiled is interesting to me in that it shows mostly bugs which do not exist in other emus. This alone tells me that these bugs are possible to fix in the method you have already, because other emus (besides sleuth) use a more simplified method of emulation. As such, it is even worth considering a change at all when the current state seems so hopeful?

Again, I can only offer logic. There is probably more to it than that.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Wed Feb 15, 2006 11:00 pm Post subject:

Well, due to the nature of bus hold delays being variable, I have a way to implement the core using the subcycle approach, but I'm going to increment the clock counters and such one cycle at a time. This should turn a lot of multiplication statements into addition.
Maybe I'll optimize it a bit and keep executing cycles until a non-I/O cycle is needed, if I can think of a nice way to do that.

The bugs that exist in bsnes but not other emulators are mostly results of simple bugs that are non-obvious to myself. I'm not the best at hunting these things down.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Feb 16, 2006 12:28 am Post subject:

Jipcy wrote:
I'd say go all the way to clockcycle-based interpretation. There's nothing "more" accurate than that is there?

Don't give in to the Need for Speed. You can perfect the emulator now, even if it can't run full-speed. Hell, maybe the overclockers will start using it for benchmarks.


Word. I agree completely. bsnes is allready -the- most accurate Snes emu,might as well go all the way with regard to accuracy. Even if that result in a loss of speed,it shouldn't be a concern. Faster computer will arive in the future anyway*.


*I'm aware of the apparent stall in the speed of today's Cpus and the shift toward multi-Cpus approach (which is,sadly, mostly useless for accurate emus like Mame or bsnes)


edit: Also

http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods

is a great read. Those who'd like to know how different emulators operate at different levels (and how this ultimately affect the end results) should definitely have a look at it.
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Thu Feb 16, 2006 2:45 am Post subject:

after a quick look at your emulator (i played zelda alttp) i could swear that thats how the game was meant to be, on zsnes it just feels a little weird, maybe even fakeish, but on bsnes it is just awesomness, keep up the excellent work and i also agree with keeping stuff accurate over speed.
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 16, 2006 4:30 am Post subject:

The only really obvious difference I've noticed in the NTSC Zelda 3 is how fast the triangles reach the front of the screen. Some emulators are way off here, especially on the PAL versions.

The only problem with speed is that I want to be able to actually use the emulator, too :/
I think I'll go for the "more correct" approach of clock cycle stepping (what I explained earlier), and if the result is just too slow, then I'll add in another CPU core that is opcode-based. Not a total waste because even with an opcode-based core, I still know more about simulating these timing quirks that other top emulators don't do. And on the bright side, that version would be way faster than even the current bsnes. But I'm not too big on the idea of maintaining two CPU cores, so who knows what'll happen.
Like DataPath said, bsnes would respond well with its OOP interface.
Savestates, if ever added, would not be compatible between the two versions, though.

As for CPUs, yeah. I do see the processor speeds still going up slightly, at least for a while. Think about when you have eight CPU cores. A bump of 200mhz is a PR advertisement of being "1.6ghz faster". It's even more fake than the current mhz speed increases are.
But ultimately, I expect the speed of each individual core to become less and less of a priority. And scarily, they may even slow them down to reduce heat and power consumption in the future when most software is multithreaded.
Multithreading will probably just be one more hurdle that makes software development one step harder for the hobbyist to pull off, compared to the big fortune 500 companies with gobs of BS programmers. There are far too many tasks I can think of that just can't be run in parallel without so many mutexes and locks that the benefits of the multicores are eliminated anyway.
Here's to hoping I just don't know what I'm talking about or something.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Feb 16, 2006 5:59 am Post subject:

byuu wrote:
The only really obvious difference I've noticed in the NTSC Zelda 3 is how fast the triangles reach the front of the screen. Some emulators are way off here, especially on the PAL versions.


That's something that changed a lot in Zsnes,the speed of the triangles I mean. One version/wip it's correct,the next version it's too fast. I wouldn't have a clue as to the reason of this,but it shouldn't be too hard to figure out for someone that can understand Z's sourcecode and has access to a debugger of course.

Quote:
The only problem with speed is that I want to be able to actually use the emulator, too :/
I think I'll go for the "more correct" approach of clock cycle stepping (what I explained earlier), and if the result is just too slow, then I'll add in another CPU core that is opcode-based. Not a total waste because even with an opcode-based core, I still know more about simulating these timing quirks that other top emulators don't do. And on the bright side, that version would be way faster than even the current bsnes. But I'm not too big on the idea of maintaining two CPU cores, so who knows what'll happen.
Like DataPath said, bsnes would respond well with its OOP interface.
Savestates, if ever added, would not be compatible between the two versions, though.


Having an optional selectable opcode-based core (for those who haven't paid attention, emulators like Zsnes and Snes9x are opcode-based) in addition to the clock cycle stepping one would be awesome imo.

Quote:
As for CPUs, yeah. I do see the processor speeds still going up slightly, at least for a while. Think about when you have eight CPU cores. A bump of 200mhz is a PR advertisement of being "1.6ghz faster". It's even more fake than the current mhz speed increases are.
But ultimately, I expect the speed of each individual core to become less and less of a priority. And scarily, they may even slow them down to reduce heat and power consumption in the future when most software is multithreaded.
Multithreading will probably just be one more hurdle that makes software development one step harder for the hobbyist to pull off, compared to the big fortune 500 companies with gobs of BS programmers. There are far too many tasks I can think of that just can't be run in parallel without so many mutexes and locks that the benefits of the multicores are eliminated anyway.
Here's to hoping I just don't know what I'm talking about or something.


Ya, unfortunately it looks like muti-Cpus machines (take a look at the 360) is the direction the industry is taking for now...It MAY be a while (maybe even a 'long' while) before we see a real,significant speed increase in single Cpu.

I know a few Mame "omgIwannaplayCruiseInUSA-but-it-said-I-Need-a-20GHZ machine" users that are in for a long wait...
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Thu Feb 16, 2006 11:42 am Post subject:

byuu wrote:

Multithreading will probably just be one more hurdle that makes software development one step harder for the hobbyist to pull off, compared to the big fortune 500 companies with gobs of BS programmers. There are far too many tasks I can think of that just can't be run in parallel without so many mutexes and locks that the benefits of the multicores are eliminated anyway.
Here's to hoping I just don't know what I'm talking about or something.


I think most people are missing the point about multiple cores and multiple CPUs for the average user.

The point is to boost what most average users do - MULTITASKING.
I want to be able to have one CPU ripping+encoding a DVD, while the other plays some fancy game, not having one program dominate all the available CPU power. Multithreaded should be reserved for OSs, server software, an optional setting for apps that need a ton of power, or used in the cases where it just makes more sense to use threads.

Therefore, I think most apps should not be multithreaded, so I don't have to play with priority settings and other nonsense just to do something exspensive and still multitask. And I kind of doubt a lot of the devs out there can even write the apps in a multithreaded way where the costs don't negate the gains.

Those making gaming systems with multiple cores, just "don't get it". It's added complexity for no reason, if you need more CPU power, boost the power of the one you have.
And contrary to what a lot of people believe, you don't need a fraction of the power that some of these games use today if they would have been written properly in the first place.
Unless someone somehow prevents all these developers from accessing fast machines, programs are just going to become bloatware that has it's own bloatware. I shudder to think what development attrocities developers will commit when they're told they have access to 25GB media for the PS3.

It's funny to realize that some games were made for the PSX, and took up 350MB on the CD, and after a lot of work, they ported the game flawlessly to the N64 and it's only 16MB there.

On the subject of bloatware, bad programming and such in games, I was talking to a Longhorn developer a while back, and he had some interesting info. He was testing a new memory access security feature, and found a bunch of games from one company were no longer working. He did some debugging, and seems they all shared a routine which allocated a lot of RAM, and then accessed it via a bad pointer. The problem here being twofold, whoever the developer was of that routine probably got random crashing, and instead of finding the bad pointer and fixing it, he enlarged the RAM, and it's usage was such that the bad pointer happened to be working within allocated RAM when there was a lot of it. So the games used way more memory than they needed, and they broke when the memory allocation style changed. After patching the bad pointer and setting the RAM allocation size properly, the games started working, and magically had a much smaller footprint, imagine that.

On the flipside today, we also have developers who never bother learning what good stable libraries are out there, and pass of their ignorance as slandering the library as being bloatware. They then proceed to recreate the library in a way that seems good to them, which from an algorithmic standpoint is highly inferior, and sometimes introduce bugs; which in itself is the cause of the bloatware. An example of such was one such "wise" developer which ignored std::set and instead created his own class which was some clever array manipulation to contain a list of unique data. His array manipulation was much slower and more CPU exspensive than the Red & Black Tree most std::set implementations use.

With Microsoft promoting 6 core game development, and Sony massive media, and both trying to push raw horsepower through the roof, the future doesn't look good.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Feb 16, 2006 12:53 pm Post subject:

Nach wrote:
It's funny to realize that some games were made for the PSX, and took up 350MB on the CD, and after a lot of work, they ported the game flawlessly to the N64 and it's only 16MB there.


Er I think that's simply because of the Psx using cd-quality audio (Wav tracks and/or Xa), which takes most of the space.
grinvader
ZSNES Plasma Prinny
ZSNES <b>Plasma Prinny</b>


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50

Posted: Thu Feb 16, 2006 1:14 pm Post subject:

Dmog wrote:
Nach wrote:
It's funny to realize that some games were made for the PSX, and took up 350MB on the CD, and after a lot of work, they ported the game flawlessly to the N64 and it's only 16MB there.


Er I think that's simply because of the Psx using cd-quality audio (Wav tracks and/or Xa), which takes most of the space.

Yes, that's often the case (SotN for one).
_________________
皆黙って俺について来い!!
Code:
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments

Pantheon: Gideon Zhi | CaitSith2 | Nach
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 16, 2006 1:34 pm Post subject:

I agree with your points about what multi-core CPUs are for, although I doubt the need to perform four or more processes that all peg out the CPU will be needed anytime soon. I don't ever even see myself playing a huge game and saying, "You know, I wish I could rip this DVD while I'm playing and encode it to DivX, but only if I can then also burn this other DVD I already ripped, render these huge 3D images in a high quality rendering program, AND compress my 60gb collection of images, all at the same time with no slowdown. Darn, if only my CPU had more cores..."
I think two, maybe four would be the most ever needed. But I'd bet money we'll be hearing about eight core processors shortly after the new four core ones get released publically.

And like you said, regardless of whether or not most applications should be single threaded, the hardware vendors will all be pushing for everything to be multithreaded, and those applications that are will be placed higher than single threaded apps when done right.

Quote:
we also have developers who never bother learning what good stable libraries are out there, and pass of their ignorance as slandering the library as being bloatware. They then proceed to recreate the library in a way that seems good to them, which from an algorithmic standpoint is highly inferior, and sometimes introduce bugs; which in itself is the cause of the bloatware.


Perhaps it's easier and more fun to write your own library than learn another new syntax. Especially when you spent the last ten years using functional programming and don't want to jump into object-oriented programming for one of the most basic tasks in the language, e.g. string manipulation, to name a wild example :P
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Thu Feb 16, 2006 1:42 pm Post subject:

im pretty sure that what i was talking about was related to your colour system. also if you add a opcode based cpu will it be a sorta switch where you switch between which cpu core you want to use?

also bs zelda renders your emulator unable to load other roms without closing and reopening your emulator where as in zsnes it just freezes the emulation. (meaning in zsnes you can still load other roms without the need to close and reopen zsnes)

also do you plan on adding a feature to disable the sound core like zsnes does? (disable spc emulation)

and lastly don't change how your colouring sytem works unless you absoloutly need to because it makes it look awesome!
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Thu Feb 16, 2006 1:47 pm Post subject:

franpa_9 wrote:
also do you plan on adding a feature to disable the sound core like zsnes does? (disable spc emulation)

What would be the point of that? Many games depend on it.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Thu Feb 16, 2006 2:09 pm Post subject:

if you havn't noticed disabiling the sound core in zsnes allows the patched version of bs zelda to work.

(patched so that it is english and beatable)
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
PiCiJi
Rookie


Joined: 30 Dec 2005
Posts: 15

Posted: Sun Feb 19, 2006 9:13 am Post subject:

Why clockcycle or subcycle based emulation? It is only for the sake of perfect emulation or are there snes games which doesn't run correctly with cycle based emulation? I mean, can the human eye and ear notice differences between cycle based and clockcycle based emulation?
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Sun Feb 19, 2006 9:30 am Post subject:

its for the sake of accuracy and bsnes goal i think is to be the most accurate snes emulator.
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Feb 19, 2006 3:24 pm Post subject:

PiCiJi wrote:
Why clockcycle or subcycle based emulation? It is only for the sake of perfect emulation or are there snes games which doesn't run correctly with cycle based emulation? I mean, can the human eye and ear notice differences between cycle based and clockcycle based emulation?


The human eyes and ears are limited and most people only notice the most God-obvious bugs and not the small stuff anyway.So when you have an accurate emu you know the games are emulated correctly.

And using your above logic,we should just hack away all the games that are problematic. I mean,if most can't tell the difference anyway.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Feb 19, 2006 8:45 pm Post subject:

Compared to an opcode-based CPU emulator, it will fix a few bugs, especially in the area of really sensitive NMI/IRQ/HDMA games. Compared to a cycle based one, you probably won't notice the difference.
The difference is only really noticeable for the dot-based PPU renderer. In a sense, I need to use a subcycle or clock based core in order to accurately time when writes to video registers mid-scanline actually take effect. Although I'll never get close to getting the PPU renderer perfect, it'll be nice to actually try to emulate mid-scanline effects to an extent.
And no, no game actually uses mid-scanline effects to my knowledge. They'd be unbelievably difficult to pull off in real-time.
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Mon Feb 20, 2006 2:27 am Post subject:

franpa_9 wrote:
its for the sake of accuracy and bsnes goal i think is to be the most accurate snes emulator.


Yep, that's the idea...To create the most accurate SNES emulator. Think of it this way, bsnes will basically be the SNES equivalent of what Kega is to the Sega Genesis. Wink
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Mon Feb 20, 2006 2:30 am Post subject:

i would think that gens is better then kega but since ive never used kega i cant compare. now back on topic people.
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Feb 20, 2006 2:42 am Post subject:

franpa_9 wrote:
i would think that gens is better then kega but since ive never used kega i cant compare.
Well, you're wrong.

franpa_9 wrote:
now back on topic people.
What's off topic? The brief mention of a Sega emulator?
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Mon Feb 20, 2006 2:44 am Post subject:

franpa_9 wrote:
i would think that gens is better then kega but since ive never used kega i cant compare.


Errr, No.

Again think of it this way, the goal for bsnes is accuracy. With Kega it is the exact same thing (And it's allready almost there). Kega is better than Gens in many aspects (Just like I think bsnes is better than ZSNES/SNES9x, in my own opinion of course). Wink


Last edited by King Of Chaos on Mon Feb 20, 2006 2:52 am; edited 1 time in total
franpa
Inmate


Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane

Posted: Mon Feb 20, 2006 2:52 am Post subject:

ah ok i must have been asleep sorry... it now makes sense.
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply.
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Mon Feb 20, 2006 2:59 am Post subject:

Anyways, keep up the good work byuu. Very Happy

P.S. Thanks for restoring my faith in SNES emulation. Wink
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Feb 20, 2006 4:33 am Post subject:

King Of Chaos wrote:
With Kega it is the exact same thing (And it's allready almost there). Kega is better than Gens in many aspects (Just like I think bsnes is better than ZSNES/SNES9x, in my own opinion of course). Wink

Although Kega does have a large number of features, unlike bsnes.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Mon Feb 20, 2006 4:53 am Post subject:

Jipcy wrote:
King Of Chaos wrote:
With Kega it is the exact same thing (And it's allready almost there). Kega is better than Gens in many aspects (Just like I think bsnes is better than ZSNES/SNES9x, in my own opinion of course). Wink

Although Kega does have a large number of features, unlike bsnes.


Yes, that's because Kega has matured over a long amount of time. bsnes is still growing up...And it will, someday. Wink
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 23, 2006 3:56 am Post subject:

byuu wrote:
I would estimate that bsnes would run 2-3x faster if it used the typical approach of emulating processors opcode-by-opcode. But this would be less hardware-accurate, and that's simply unacceptable to me.


byuu wrote:
So the cycle-based CPU core is 4-8x more synchronized than the opcode-based core. Now think of splitting each cycle into 3-6 separate functions. That's what I'm working on now. And yes, it is very, very slow. About 27x slower. Good thing the CPU isn't the major bottleneck to speed. Or at least, it wasn't.
But fear not, those of you with slower processors! I'm also planning to make another CPU core that will be opcode-based. Much as the clock-stepping core lowers speed by 30%, the new opcode-stepping core should increase speed by 30% over v0.015.
The current cycle-based CPU core I may or may not continue to maintain. I don't really even want to maintain two CPU cores, let alone three, but I don't really have a choice.


Alright, I'm a little confused by the direction bsnes is heading. Cycle-based was the perfect accuracy/performance hybrid. So, now let me get this straight... it's being ditched for less accurate opcode and a method that is unusably slow? Wha...?
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Feb 23, 2006 4:30 am Post subject:

He's gonna do both. One's going to be very accurate and very slow, the other is going to be much faster, and playably accurate.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
DataPath
Lurker


Joined: 28 Jul 2004
Posts: 144

Posted: Thu Feb 23, 2006 4:52 am Post subject:

And being able to swap one CPU core out for another, keeping the APU and PPU units the same should make it possible to debugging and tweaking an opcode-based emulator pretty effective
Starman Ghost
Veteran


Joined: 28 Jul 2004
Posts: 991

Posted: Thu Feb 23, 2006 4:59 am Post subject:

Would it be stupid to code Clockcycle based emulator in basic?
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 23, 2006 5:59 am Post subject:

I change my mind a lot. Basically, I want more accuracy than I currently have. But unfortunately, making things more accurate than they currently are would render the emulator unusable on most hardware.
So, I get my way and have more accuracy, and throw in an opcode-based core as well, so it runs fast on older hardware. It's a compromise. More people use bsnes, more people submit bugfixes, everyone wins.
I'll mostly be focusing on the clockcycle-based core, of course.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 23, 2006 7:04 am Post subject:

I'm not at all surprised by the clockcycle endeavor. That sounds cool, even though no one will actually be able to use it for about 10 years... and no actual games will gain accuracy... The opcode thing struck me as strange, though.

I think it's nice to consider people with older hardware, but to some extent that niche has already been filled by older emus (which will still be much faster anyway). And that 30% speed increase you speak of: could that or near that not be gained from optimization of current code?

Additionally, the advantage of having more people able to submit bugfixes isn't really an advantage when you consider that going opcode is going to be introducing those bugs. As for wanting to gain users in general, I gaurantee that savestates will probably have more a say in gaining users at this point than a 30% speed increase. You'd be amazed by how alluring this convenience and semi-cheat feature is. I'd even go as far to say that the average joe is not using your emu over others for this feature alone. He doesn't want to be faced with the prospect of losing and starting over! Accuracy and sound quality be damned!

You also said that opcode is inherently flawed and cannot achieve perfect synch without hacks. Sounds like a good idea for starting an emu 7 years ago. Sounds like a lost cause today. With as few bugs as you have now (debugger hopefuls, too), I see this switch as strange and untimely.

Something tells me there is more to all this than meets the eye...
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Thu Feb 23, 2006 7:53 am Post subject:

This might come off as ignorant, but I'm just not sure about the answer.

Is it really not possible for a 3000+ MHz machine to accurately emulate a 5 MHz machine at full speed? While I realize that there's a lot more to it than clockspeeeds, I'm just imagining that a decent pc by today's standards should be able to flawlessly run a accurate snes emulator without speed issues. I also realize that the emulator is in it's early stages, so I guess my question is more of a future thing. Will bsnes be optimized once the main core is done, or can it even be optimized enough to matter?

I guess why i ask is because i would like to use it. it sounds FABULOUS, and the controls don't lag in it like they do with zsnes, whatever the reason may be. however, my aging 1.4 athlon isn't beefy enough to handle it.
_________________
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Thu Feb 23, 2006 11:25 am Post subject:

sweener2001:
Have you read the text at the end of this page?

byuu wrote:
Now then, anyone up for writing some filters? :)

You could add HQ?x... Wink

Starman Ghost wrote:
Would it be stupid to code Clockcycle based emulator in basic?

Depends on your compiler. Some people are saying that FreeBasic is a good one.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 23, 2006 1:08 pm Post subject:

One of the rules of programming is to write clean, complete code first, and optimize later. Yes, I'm sure I can increase the speed some later on when everything's working fine, but I'm generally opposed to using ugly hackish code to speed things up.

The speed problem has little to do with the clock rate of the SNES CPU. It has to do with keeping four separate chips in perfect synchronization. CPU, PPU, APU and DSP. The overhead increases exponentially as you get closer to hardware.
So take the CPU, which executes 2-8 cycles/opcode, and 3-6 clocks/cycle.
At 21.477mhz (internal clock rate), you get:
10,738,636 calls a second to synchronize from the CPU alone for clockcycle-stepping
2,386,363 for cycle stepping
477,272 for opcode stepping

And given that sync overhead is way greater than the actual CPU logic emulation, it's easily well above 22x more processor intensive to do things this way. Which is why it's never been done before by any emulator I'm aware of.

Quote:
Something tells me there is more to all this than meets the eye...

For one, I'd like to actually be able to play the emulator myself. Sorry that it bothers you so much, but accuracy is still the main priority by and large.

Quote:
You could add HQ?x...

I was suggesting others do this :P
I just wanted the filter ability there for the SNES NTSC filter.
Nightcrawler
Romhacking God


Joined: 28 Jul 2004
Posts: 1899

Posted: Thu Feb 23, 2006 1:45 pm Post subject:

sweener2001 wrote:
This might come off as ignorant, but I'm just not sure about the answer.

Is it really not possible for a 3000+ MHz machine to accurately emulate a 5 MHz machine at full speed? While I realize that there's a lot more to it than clockspeeeds, I'm just imagining that a decent pc by today's standards should be able to flawlessly run a accurate snes emulator without speed issues. I also realize that the emulator is in it's early stages, so I guess my question is more of a future thing. Will bsnes be optimized once the main core is done, or can it even be optimized enough to matter?

I guess why i ask is because i would like to use it. it sounds FABULOUS, and the controls don't lag in it like they do with zsnes, whatever the reason may be. however, my aging 1.4 athlon isn't beefy enough to handle it.


That's just it, emulating the 3Mhz CPU is basically NOTHING. You can do that with a Pentium 1. The enormous amount of extra power comes from emulating and synchronizing the rest of the system.

When you need to syncronize the system, that in turn makes you have to use some MUCH more expensive methods to emulate the CPU as Byuu has been talking about and as he said, that's probably still NOT the speed bottleneck.

Things become even more complex because the SNES, while truly and technically by nature renders by scanline, it is capable of changes mid scanline which requires you to do dot by dot rendering in your emulation if you want to be really accurate and catch all this.

The complexity just grows exponentially. So get the CPU and CPU speeds out of your head because they don't mean much of anything. It's all in the syncronization and techniques needed to emulate the rest of the system.

Hope that helps.
_________________
TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
ROMhacking.net - The central hub of the ROM hacking community.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Feb 23, 2006 7:18 pm Post subject:

FitzRoy wrote:
I'm not at all surprised by the clockcycle endeavor. That sounds cool, even though no one will actually be able to use it for about 10 years... and no actual games will gain accuracy... The opcode thing struck me as strange, though.


It doesn't seem strange to me at all. If I *had* to choose one core, then of course I'd choose the accurate clockcycle one. Even if it turn out to be too demanding to run fullspeed on a 3.0Ghz cpu.

But having the option available to the user, that's the best of both worlds.
I'm against innacurate 'emulation'. But I'm not against an 'option' for less accurate but faster emulation because I could always use the accurate core. I don't find it contradictory. I just call it "choice is good".





Quote:
I think it's nice to consider people with older hardware, but to some extent that niche has already been filled by older emus (which will still be much faster anyway).


My guess is that even when bsnes would run with the opcode base core it would still exhibit 'way' less issues than Zsnes or Snes9x.



Quote:
Additionally, the advantage of having more people able to submit bugfixes isn't really an advantage when you consider that going opcode is going to be introducing those bugs.


You could just say "don't report bugs when using the opcode core".

Quote:
As for wanting to gain users in general, I gaurantee that savestates will probably have more a say in gaining users at this point than a 30% speed increase. You'd be amazed by how alluring this convenience and semi-cheat feature is. I'd even go as far to say that the average joe is not using your emu over others for this feature alone. He doesn't want to be faced with the prospect of losing and starting over! Accuracy and sound quality be damned!


Quote:
You also said that opcode is inherently flawed and cannot achieve perfect synch without hacks. Sounds like a good idea for starting an emu 7 years ago. Sounds like a lost cause today. With as few bugs as you have now (debugger hopefuls, too), I see this switch as strange and untimely.


Allright just to make sure: You DID understand that it will only be an 'option' and that the accurate core 'will' remain,right? In fact,the reason why Byuu is considering a second,opcode based core is because bsnes is gonna be even 'more' accurate in the future (and thus, even slower)
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 23, 2006 9:21 pm Post subject:

byuu wrote:

Quote:
Something tells me there is more to all this than meets the eye...

For one, I'd like to actually be able to play the emulator myself. Sorry that it bothers you so much, but accuracy is still the main priority by and large.


Actually... I was thinking that going opcode would make it easier for someone else to fix things, add things, and that you might have been in talks with that person. I never would have assumed that with your recent upgrade, you wouldn't be able to play your emu fullspeed. Obviously, that isn't bothersome to me. But my god, your comp is more powerful than mine... what's wrong?
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 23, 2006 9:48 pm Post subject:

Dmog wrote:

It doesn't seem strange to me at all. If I *had* to choose one core, then of course I'd choose the accurate clockcycle one. Even if it turn out to be too demanding to run fullspeed on a 3.0Ghz cpu.

But having the option available to the user, that's the best of both worlds.
I'm against innacurate 'emulation'. But I'm not against an 'option' for less accurate but faster emulation because I could always use the accurate core. I don't find it contradictory. I just call it "choice is good".


Somehow, my point eludes you. Best of both worlds? The best of both worlds is a cycle core and a clockcycle core, not an opcode and a clockcycle. And "too demanding for a 3.0ghz cpu? Try too demanding for a 10ghz cpu, and with the multi-core fad taking off, you might not see that for another 15 years.

Quote:

My guess is that even when bsnes would run with the opcode base core it would still exhibit 'way' less issues than Zsnes or Snes9x.


I don't doubt this. But I can't presume to know what the actual result will be. Those emus have been in development for years, and timing bugs that existed then still exist today. Byuu says he's not too great at tracking things like this down, so the first result could seem great, but the bugs could become a nightmare. But perhaps byuu will surprise us yet again.

Quote:

You could just say "don't report bugs when using the opcode core".


I'm not entirely sure what you mean by this. Please re-read my statement. Bugfix is not a bug report.

Quote:

Allright just to make sure: You DID understand that it will only be an 'option' and that the accurate core 'will' remain,right? In fact,the reason why Byuu is considering a second,opcode based core is because bsnes is gonna be even 'more' accurate in the future (and thus, even slower)


The accurate core will not remain, if you're referring to the cycle core being used today. Cycle is being discontinued for an unusable clockcycle core and an opcode core that is inherently inferior to cycle. It's a double loss. I'm not sure you're fully informed about the "more accurate" future either. Clockcyle will not bring any additional accuracy over cycle, because no games perform the things that clockcycle will enable.

Feel free to disagree, it is the bsnes thread.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Feb 23, 2006 10:06 pm Post subject:

FitzRoy wrote:
I don't doubt this. But I can't presume to know what the actual result will be. Those emus have been in development for years, and timing bugs that existed then still exist today. Byuu says he's not too great at tracking things like this down, so the first result could seem great, but the bugs could become a nightmare. But perhaps byuu will surprise us yet again.

Yes but those emulators were started long ago when much less was known about the SNES. And some of those bugs are really hard to fix just becuase of the long, incremental development of those emulators. Byuu could probably make a quite nice opcode-based emulator.

Why would byuu forsake the cylce-based core for a clock-cycle core? Because he wants to push the limits of SNES emulation accuracy. Speed is a secondary/tertiary concern.

Here's an idea: perhaps the cycle-based core can remain as-is in bsnes. We shouldn't lose the progress made with the cycle core.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Thu Feb 23, 2006 10:19 pm Post subject:

Jipcy wrote:
FitzRoy wrote:
I don't doubt this. But I can't presume to know what the actual result will be. Those emus have been in development for years, and timing bugs that existed then still exist today. Byuu says he's not too great at tracking things like this down, so the first result could seem great, but the bugs could become a nightmare. But perhaps byuu will surprise us yet again.

Yes but those emulators were started long ago when much less was known about the SNES. And some of those bugs are really hard to fix just becuase of the long, incremental development of those emulators. Byuu could probably make a quite nice opcode-based emulator.

Why would byuu forsake the cylce-based core for a clock-cycle core? Because he wants to push the limits of SNES emulation accuracy. Speed is a secondary/tertiary concern.


Ok, before I hear this argument again, think about how ludicrous it sounds. We have a list of ~25 known inaccuracies that actually afflict games on the first page of this thread. Clockcycle will fix none of these. Instead, it will enable the performance of an operation that does not exist in any game. Are we done defending clockcyle with "accuracy" now? Is there a soul on this planet that will use this option, even 15 years from now, with the knowledge that it will do nothing but increase your energy consumption?
sweener2001
Inmate


Joined: 06 Dec 2004
Posts: 1571
Location: WA

Posted: Thu Feb 23, 2006 10:43 pm Post subject:

Alright, that makes perfect sense to me now. Thanks for the great answers, and thanks for a fantastic emulator.
_________________
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Feb 23, 2006 10:45 pm Post subject:

Well, perhaps it's more of a theoretical exercise for byuu, not about playing games.

Perhaps we can convince him to maintain the clock-based core, and not introduce an opcode core, since the clock-based core isn't too horribly bad. And then he can do what he wants with the clockcycle core.

Or, maybe we'll see an opcode core that is still very compatible.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Feb 23, 2006 11:56 pm Post subject:

Quote:
Instead, it will enable the performance of an operation that does not exist in any game. Are we done defending clockcyle with "accuracy" now? Is there a soul on this planet that will use this option, even 15 years from now, with the knowledge that it will do nothing but increase your energy consumption?

It will affect every game, actually. The order of executed operations will change quite a lot. Whether or not that's visible on screen, I thought I've made abundantly clear by now that I could care less. I've said right from the beginning that I'm more interested in emulating the hardware. But yes, every now and then I like to fire up Mega Man X2 and play through a few levels on bsnes. So occasionally I'll add some frivilous GUI stuff here, some special chip there, little things. I haven't really done much since v0.015, I've just not had much time to program as of late :(

You make a good point, though. I could keep the current cycle-based core instead of the opcode-based core. My opinion was that if it wasn't all the way accurate, why not just go for speed? No point in striking middle grounds. But if everyone disagrees with me, that's fine. System requirements will remain the same for the current breed, and much higher for the new breed of core components (going to do this for the PPU, and possibly the APU, even though no information is known on APU bus hold times). It'd save me time anyway to not have to write an opcode core.
If I do this, I'm at least removing the pseudo-hold delays on reads and writes. They slow things down a lot and since they don't actually sync the chips, all they do is correct latch counter reads, which "affects nothing" as you put it. And as I said, I don't like hacks, which is exactly what the cycle core is doing now. This will be an easy 10% speedup, and the clock core will do it the right way. Also, 10ghz is a bit sarcastic. 5-7ghz will do just fine :P
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Thu Feb 23, 2006 11:58 pm Post subject:

FitzRoy wrote:
Somehow, my point eludes you. Best of both worlds? The best of both worlds is a cycle core and a clockcycle core, not an opcode and a clockcycle.


Ok sorry, I misunderstood you. So your main "beef" is with the future clockcycle core as opposed to the curent cylce-based core.I could understand your reaction if it was a 'downgrade' in term of accuracy...but unless I missed something it IS even more accurate than the current cycle-based core.

edit:More specifically, you'd prefer a cycle+clockcycle instead of a opcode+clockcycle.

And Byuu said he needs this core in order to achive his new dot-based renderer:

quote
Quote:
The difference is only really noticeable for the dot-based PPU renderer. In a sense, I need to use a subcycle or clock based core in order to accurately time when writes to video registers mid-scanline actually take effect


Quote:
And "too demanding for a 3.0ghz cpu? Try too demanding for a 10ghz cpu, and with the multi-core fad taking off, you might not see that for another 15 years.


Ok, too demanding for a 10ghz (i.e: anyone's computer) then. For me that's a non-issue. Like I mentionned before,Mame has some drivers that demands 20Ghz machines and I still believe it's a non issue.

Bottom line: With the clockcycle core Bsnes would reach an incredible level of accuracy = what matters most
AND as an added bonus it would give the users the choice of an opcode based core that's playable on a 1.5ghz (or less?) and much mores solid then the current opcode based emulator like Z and 9x (i.e: the only thing we had before b* 'anyway')

So yeah, I'm not gonna complain!



Perhaps Byuu could go triple core (opcode,cycle,clockcycle) if he felt really generous but personally I feel there's no need for it.


* Imo, bsnes deserve a Upper case 'B'! Laughing
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Feb 24, 2006 12:21 am Post subject:

byuu wrote:
No point in striking middle grounds. But if everyone disagrees with me, that's fine


Unless of course your mind is allready made up, but if you really don't have a strong preference between Opcode/Clockcycle or Cycle/Clockcycle then we could perhaps do some sort of poll maybe?
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Feb 24, 2006 12:43 am Post subject:

I have a question about SNES emulation in general.

Is this kinda how SNES emulation works right now:

CPU - APU - PPU - DSP: Execute freely, independant of each other, until next sync.

CPU - APU - PPU - DSP: SYNCHRONIZE

CPU - APU - PPU - DSP: Execute

CPU - APU - PPU - DSP: SYNCHRONIZE

?

Is it possible to kind of, combine all four processing units, so they are constantly executing in sync with each other?

Just a random thought that I had. Probably not worth anything.

EDIT: Nevermind. The processors all run at different clock speeds right? That would prevent any "combination" of the processors, probably.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/


Last edited by Jipcy on Fri Feb 24, 2006 3:04 am; edited 1 time in total
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Feb 24, 2006 2:10 am Post subject:

I haven't posted here in a long time.
Been very busy with C64 & Genesis stuff since Kega & Vice were the only accurate emus of 8-16 bit systems that I own.
I heard abt this new emu called Bsnes so finally decided to give it a try...
When trying it for the first time, it totally blew me away.
Finally a Snes emu which main goal is total accuracy like Kega. Very Happy

Byuu, I'm totally impressed with your work and became an instant fan.
The quality of it is on par with that of SteveSnake's Kega only you still need more time coz Bsnes is still fairly new but quality always shines through.

From now on Bsnes is my primary choice for Snes emulation and thanks to it I'll be more in the mood again for playing snes games.
Keep up the great work! Cool

@KingOfChaos: nice to find you here as well, hehe. Wink
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Fri Feb 24, 2006 2:26 am Post subject:

Accuracy is a must. I can run basically any game at full speed with it only using 50% of my overall system resources (3.2Ghz P4, 1 Gig RAM).

In my opinion, hacks are a big NO NO.

Besides, it won't be long till we see 4-5Ghz processers. Rolling Eyes

*waves at Sith*
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Feb 24, 2006 6:46 am Post subject:

byuu wrote:

It will affect every game, actually. The order of executed operations will change quite a lot. Whether or not that's visible on screen, I thought I've made abundantly clear by now that I could care less. I've said right from the beginning that I'm more interested in emulating the hardware. But yes, every now and then I like to fire up Mega Man X2 and play through a few levels on bsnes. So occasionally I'll add some frivilous GUI stuff here, some special chip there, little things. I haven't really done much since v0.015, I've just not had much time to program as of late Sad


I always understood your rationale for clockcyle. You're a perfectionist. For the same reason, I didn't quite understand dropping a perfectly wonderful cycle core for opcode.

byuu wrote:
You make a good point, though. I could keep the curren
cycle-based core instead of the opcode-based core. My opinion was that if it wasn't all the way accurate, why not just go for speed? No point in striking middle grounds. But if everyone disagrees with me, that's fine.


If you think you can pull it off without introducing many new bugs, then I'm of the same opinion as you. However, the cycle core is plenty fast for 2ghz and higher, it's more accurate, and it's already been written. That saves time for you, and possible future headaches trying to work with a more finicky core. I don't agree with dmog's optimism. I don't think it's worth the effort or the risk for 30%. Especially when computers have never been cheaper, and 2ghz has been low end for over a year.

byuu wrote:
System requirements will remain the same for the current breed, and much higher for the new breed of core components (going to do this for the PPU, and possibly the APU, even though no information is known on APU bus hold times). It'd save me time anyway to not have to write an opcode core.


Absolutely.

byuu wrote:
If I do this, I'm at least removing the pseudo-hold delays on reads and writes. They slow things down a lot and since they don't actually sync the chips, all they do is correct latch counter reads, which "affects nothing" as you put it. And as I said, I don't like hacks, which is exactly what the cycle core is doing now. This will be an easy 10% speedup, and the clock core will do it the right way.


Nice! I had no idea there was something like this present. So long as it has no effect on games, what an easy optimization. I like to see you thinking like this.

In the end, you can always do as you will. I have always been aware that bsnes was a quest for hardware accuracy and not a program for us lowly gamers. But in doing this, and making it playable, you've inevitably garnered yourself a userbase that is as enthusiastic about experiencing accuracy as you are seeking it. And yet you haven't ignored our discussions or the community that you never intended to create... you've given and you've gained. I honestly believe that.

byuu wrote:
Also, 10ghz is a bit sarcastic. 5-7ghz will do just fine Razz


Laughing
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Feb 24, 2006 7:32 am Post subject:

Quote:
Is this kinda how SNES emulation works right now:

The SNES runs all chips at the exact same time. What I do is see which of the four chips are the farthest behind in being run, and then run that chip as little as I possibly can, update its clocks (updating the CPU clock is the #1 most intensive function as revealed by code profiling), rinse, repeat.

Quote:
I can run basically any game at full speed with it only using 50% of my overall system resources (3.2Ghz P4, 1 Gig RAM).

Really? It doesn't even sleep, so it should be eating 99% and sitting idle anyway. That's cool, so you can probably run 2x mode (120fps) with no sound breakup. ToP's intro sounds awesome like that. I have to use frameskipping for that.

Quote:
The quality of it is on par with that of SteveSnake's Kega only you still need more time coz Bsnes is still fairly new but quality always shines through.

Thanks, I've always been a big fan of Steve's work since the original KGen for DOS.

Quote:
I always understood your rationale for clockcyle. You're a perfectionist.

Goes with the territory of being obsessive compulsive.
So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead? :)

Quote:
For the same reason, I didn't quite understand dropping a perfectly wonderful cycle core for opcode.

Well, you were just commenting on accuracy gains that won't be "visible". The differences between opcode and cycle aren't "visible" in most games. Surely they will be in Earthworm Jim 2 and such, but not in the majority of games. It's mostly all the speed hacks and stuff that cause the problems in the top SNES emulators, I think. For example, a certain emulator doesn't even count clock cycles for the APU emulator, you know? Every APU opcode is treated as being equally as long. Absolute genius for the time it was made, and that it works so well even to this day. I'd have never thought of that myself.

Before bsnes, xkas was the most widely used program of mine. It had a userbase of six people. With so many users, I feel kind of obligated to make it a little more user friendly than I usually make my programs. Speed is a major concern for a lot of people, even though I agree that 2ghz isn't that big of a deal since they typically cost less than $100 new, half that used.

As always, thanks for the kind words all. I'll likely be posting a WIP build this weekend or next.
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Fri Feb 24, 2006 11:28 am Post subject:

byuu wrote:
So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead? Smile

Shocked

Erm, more than 10 GHz... ?


EDIT: Just wanted to add that speedrunners don't need 100% real-time speed... Wink
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.


Last edited by creaothceann on Fri Feb 24, 2006 12:50 pm; edited 1 time in total
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Feb 24, 2006 12:22 pm Post subject:

FitzRoy wrote:
So long as it has no effect on games


I hope you didn't meant that literally...It sounds a bit like "I only care about the speed and playability of bsnes as it has (way) less bugs and issues then Zsnes"

creaothceann wrote:
byuu wrote:
So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead? Smile

Shocked

Erm, more than 10 GHz... ?


No idea either Shocked

A wild guess would be: Future M.e.s.s Saturn emulation 3X requirements = so yes more than 10ghz.

Quote:

The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam


Nestopia also deserve a mention! Smile unless you really,truly hate Nes
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Feb 24, 2006 6:50 pm Post subject:

byuu.org wrote:
In preparation, I went ahead and rewrote a bunch of the video rendering code, so that software filters can be used. So far, so good. I've added a Scale2x filter for now. It's actually not as slow as I thought it would be, especially for being completely unoptimized.

Sweet Jesus, thank you!
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Feb 24, 2006 7:05 pm Post subject:

Dmog wrote:
Quote:

The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam

Nestopia also deserve a mention! Smile unless you really,truly hate Nes
I don't hate NES, just never had one. Anyways, there's no more room left in my sig.

creaothceann wrote:
byuu wrote:
So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead?
Erm, more than 10 GHz... ?
Not according to Steve, accurate Saturn emulation can be achieved with less than 5GHz
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Feb 24, 2006 9:13 pm Post subject:

Sith-Smasher wrote:
Dmog wrote:
Quote:

The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam

Nestopia also deserve a mention! Smile unless you really,truly hate Nes
I don't hate NES, just never had one. Anyways, there's no more room left in my sig.

creaothceann wrote:
byuu wrote:
So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead?
Erm, more than 10 GHz... ?
Not according to Steve, accurate Saturn emulation can be achieved with less than 5GHz


Someone wrote on wikipedia, I dunno how valid that info is, that Steve Snake hinted that he may consider emulating the Saturn. (thus emulating every Sega console before the Dreamcast).

Did you heard something to that effect?
Knowing what an emulation God Steve is, that 'would' seriously rocks..
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Feb 24, 2006 9:51 pm Post subject:

Dmog wrote:
FitzRoy wrote:
So long as it has no effect on games


I hope you didn't meant that literally...It sounds a bit like "I only care about the speed and playability of bsnes as it has (way) less bugs and issues then Zsnes"


I'm a little confused by your accusation. I think I'll need an elaboration before I even attempt to defend myself.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Feb 24, 2006 10:03 pm Post subject:

Dmog wrote:
Someone wrote on wikipedia, I dunno how valid that info is, that Steve Snake hinted that he may consider emulating the Saturn. (thus emulating every Sega console before the Dreamcast).

Did you heard something to that effect?
Knowing what an emulation God Steve is, that 'would' seriously rock..
Yes, he hinted abt that in Sega Emulation Forums so he might at least be considering it.
Actually it was on a post by me that he responded, hehe.
I said sth like "We need at least 5GHz for decent Saturn emulation"
...and Steve replied with "Nah, just a better emulator Wink "

I would think that's a good teaser that he's at least considering it. Smile
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Feb 24, 2006 10:13 pm Post subject:

FitzRoy wrote:
Dmog wrote:
FitzRoy wrote:
So long as it has no effect on games


I hope you didn't meant that literally...It sounds a bit like "I only care about the speed and playability of bsnes as it has (way) less bugs and issues then Zsnes"


I'm a little confused by your accusation. I think I'll need an elaboration before I even attempt to defend myself.


Ok,exageration on my part perhaps.

You did express concern over bsnes's future speed though:

Quote:
Cycle-based was the perfect accuracy/performance hybrid


Quote:
Cycle is being discontinued for an unusable clockcycle core


Quote:
Are we done defending clockcyle with "accuracy" now? Is there a soul on this planet that will use this option, even 15 years from now, with the knowledge that it will do nothing but increase your energy consumption



No "accusations" I just think speed shouldn't be a big concern.
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Fri Feb 24, 2006 10:35 pm Post subject:

byuu wrote:
Quote:
I can run basically any game at full speed with it only using 50% of my overall system resources (3.2Ghz P4, 1 Gig RAM).

Really? It doesn't even sleep, so it should be eating 99% and sitting idle anyway. That's cool, so you can probably run 2x mode (120fps) with no sound breakup. ToP's intro sounds awesome like that. I have to use frameskipping for that.



Yep, using 2x mode (120fps) only uses 61% system resources with no sound breakup. Wink (That's with multiple programs open, including iTunes and MSN messenger).
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Feb 24, 2006 11:45 pm Post subject:

Jipcy wrote:
byuu.org wrote:
In preparation, I went ahead and rewrote a bunch of the video rendering code, so that software filters can be used. So far, so good. I've added a Scale2x filter for now. It's actually not as slow as I thought it would be, especially for being completely unoptimized.

Sweet Jesus, thank you!


As for me I'm excited by Blargg's NTSC filter! It's allready been implememted in Nestopia and it's 'amazing'. A-ma-zing seriously. It's the closest thing to a TV display you'll find on a Pc monitor. Can't wait it being implement in bsnes.Blargg did an amazing job.

Oh and here's the complete bsnes news. I hope there's no problem copy-pasting it here:

Quote:
So blargg is working on an absolutely stunning SNES NTSC video filter. And lucky me, he's going to let me use his code in bsnes. If he's able to figure out hires color blending, then we should finally have proper pseudo-hires emulation at long last. Whether you like his NTSC filter or not, this is the only accurate way you'll ever be able to view pseudo-hires, and for that matter all hires color math the way it was intended. I can't wait.
In preparation, I went ahead and rewrote a bunch of the video rendering code, so that software filters can be used. So far, so good. I've added a Scale2x filter for now. It's actually not as slow as I thought it would be, especially for being completely unoptimized. It only drops the framerate from 80 to 74 on my Athlon 3500+. But of course, the extra translation layer needed for the renderer drops the original renderer by 6fps as well. But that can't be helped. I can't expect the filters to accomodate the potential variable width of each SNES scanline (e.g. hires can be toggled mid-frame). So as of now, the PPU renders each line into a buffer, and each line has information on whether hires and/or interlace is enabled. Then at the end of the frame, an internal function is called to "normalize" the PPU buffer. Or in other words, make the width even for all scanlines and double scanlines where needed if interlace is toggled mid-frame. Then that buffer is passed to the software renderer, which performs its magic on the raw BGR555 data, and outputs the resulting data directly into video memory, which is then scaled and blitted to the screen.
For now, the filter system can be viewed here, and a screenshot of the Scale2x filter in action can be viewed here. Now then, anyone up for writing some filters? Smile

02/21/2006 - aCPU
Short for accurate CPU. Basically, for future plans and increased accuracy, it's neccesary for me to move bsnes to a new clock-stepping CPU core. Think of an opcode-based CPU core where one opcode is executed at a time. Then think of a cycle-based CPU core that splits each opcode into 4-8 separate functions, and after each cycle, everything is synchronized. So the cycle-based CPU core is 4-8x more synchronized than the opcode-based core. Now think of splitting each cycle into 3-6 separate functions. That's what I'm working on now. And yes, it is very, very slow. About 27x slower. Good thing the CPU isn't the major bottleneck to speed. Or at least, it wasn't.
But fear not, those of you with slower processors! I'm also planning to make another CPU core that will be opcode-based. Much as the clock-stepping core lowers speed by 30%, the new opcode-stepping core should increase speed by 30% over v0.015.
The current cycle-based CPU core I may or may not continue to maintain. I don't really even want to maintain two CPU cores, let alone three, but I don't really have a choice. And just to say this now: savestates (when I finally add them) between the two CPU cores won't be compatible, sorry.
Now as far as finishing these things, I've actually been moving through the new clock-based core surprisingly fast. It'll probably be 2-3 months before it's ready. The hard part is going to be porting all of the NMI/IRQ/(H)DMA stuff over, and especially breaking those down enough to step by individual clock cycles.

In other news, I've added two new filter options to control both the non-interlace and interlace scanline intensities. 0% being disabled, 100% being solid black, adjustable by increments of 1% at a time. I removed the "Enable scanlines" checkbox as it's redundant. 0% can be used to disable scanlines now. Hopefully that won't confuse anyone.

You can take a peek at the source code to the new aCPU here. I'd love to get some feedback from programmers on this new design, specifically for timing/timing.cpp:aCPU::run_clock(). Any optimizations here would be a huge help.


By now,I guess it's getting redundant to say 'bsnes is getting more amazing each new update' but I can't think of another of way saying it Confused
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Feb 24, 2006 11:58 pm Post subject:

So Bsnes will have a plugin system like Kega? Cool! Very Happy
And yes, you'll always find ppl willing & able to write plugins.
Kega currently has 20.
Because Bsnes is damn good too, response for that should be quick. Wink
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sat Feb 25, 2006 12:04 am Post subject:

Quote:
So as of now, the PPU renders each line into a buffer, and each line has information on whether hires and/or interlace is enabled. Then at the end of the frame, an internal function is called to "normalize" the PPU buffer


Ot question, but do you think there's any chance that this might cause input delay? I know what everyone is thinking: "What does rendering has anything to do with input responsiveness?" Well I'm not sure how it works either, but from what I gathered it can have an impact.

I'm asking because bsnes is one of those emu completely free of any lags even when triple buffering is on.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Feb 25, 2006 2:30 am Post subject:

You can maybe get SNES9x-level saturn accuracy with 5ghz. Which, really, is good enough for that system. The faster the system, the less critical perfect timing is.

Quote:
Sweet Jesus, thank you!

Heh, I was under the impression everyone wanted me to avoid filters as they aren't needed. I only added the Scale2x filter in <10 minutes to test out the system for blargg's awesome SNES NTSC filter. I can make more if people want them. I have some ideas for my own filters at this point.

Quote:
Yep, using 2x mode (120fps) only uses 61% system resources with no sound breakup.

Amazing. My 3500+ gets 80-100fps -tops-. I realize that's 1ghz slower, but everyone always remarks how slower Athlons match faster Pentiums... looks like I might just have to buy Intel (and a higher wattage PSU) next time I upgrade :(

Quote:
So Bsnes will have a plugin system like Kega? Cool!

Internal only, but yes. Anyone is free to submit drivers and I'll add them in.

Quote:
Ot question, but do you think there's any chance that this might cause input delay?

Nah, it'll be equally as responsive. This new code is inserted between two parts where the SNES is technically completely paused.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sat Feb 25, 2006 3:15 am Post subject:

byuu wrote:
Quote:
Sweet Jesus, thank you!

Heh, I was under the impression everyone wanted me to avoid filters as they aren't needed. I only added the Scale2x filter in <10 minutes to test out the system for blargg's awesome SNES NTSC filter. I can make more if people want them. I have some ideas for my own filters at this point.

Well, I like the ScaleXx filters in particular. I like the way they look better than HQXx filters.

Although I have noticed that the ScaleXx filters create some odd artifacts where HQXx does not.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Feb 25, 2006 10:14 am Post subject:

I saw the scale2x screenie. It looks stunning. As for wanting more filter Ideas, I'm sure someone will register soon to tell you their dying wish is vertical scanlines.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Sat Feb 25, 2006 4:18 pm Post subject:

I love filters coz they make images less blocky.
Filters are very usefull with 8-16bit systems coz of their blocky resolutions.

Byuu, I hope you will include 2xSaI. It's my favourite.
On a different note, could you include an 'assign path' feature for .srm files coz I like to have them in a seperate folder.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Sat Feb 25, 2006 4:38 pm Post subject:

byuu, can you add faster settings? I wanna push this thing to the max. Rolling Eyes
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sat Feb 25, 2006 7:45 pm Post subject:

byuu wrote:

Heh, I was under the impression everyone wanted me to avoid filters as they aren't needed. I only added the Scale2x filter in <10 minutes to test out the system for blargg's awesome SNES NTSC filter. I can make more if people want them. I have some ideas for my own filters at this point.

You can't add Scale2x without breaking the license, sorry.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Feb 25, 2006 8:32 pm Post subject:

What exactly is different with the Scale2x license than with most of the others?

I presume it is literally the reason that it was not implemented on ZSNES.
_________________
FF4 research never ends for me.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sat Feb 25, 2006 8:47 pm Post subject:

Well, Scale2x appears to be licensed under the GNU GPL. I don't know what specific incompatibilities exist between it and bsnes's license.

I don't think that's why Scale2x isn't in ZSNES, though. Seeing as ZSNES also is licensed under the GPL. I think it's really just no one has bothered adding it.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sat Feb 25, 2006 8:51 pm Post subject:

Deathlike2 wrote:
What exactly is different with the Scale2x license than with most of the others?

Most of the other what? bsnes doesn't implement any other filters.
Deathlike2 wrote:

I presume it is literally the reason that it was not implemented on ZSNES.

Scale2x license is compatible with ZSNES'
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Feb 25, 2006 8:58 pm Post subject:

Nach wrote:
Deathlike2 wrote:
What exactly is different with the Scale2x license than with most of the others?

Most of the other what? bsnes doesn't implement any other filters.
Deathlike2 wrote:

I presume it is literally the reason that it was not implemented on ZSNES.

Scale2x license is compatible with ZSNES'


I meant the other filters. I thought there was a reason as to why Scale2x was not implemented on ZSNES, but that's not the case apparently. Is there any reason why Scale2x isn't implemented in ZSNES then?
_________________
FF4 research never ends for me.
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sat Feb 25, 2006 9:00 pm Post subject:

Deathlike2 wrote:
Is there any reason why Scale2x isn't implemented in ZSNES then?

Because no one implemented it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Feb 25, 2006 9:33 pm Post subject:

I did not use Scale2x' source code. I wrote my own implementation of it. The algorithm itself is trivial, and as far as I know, was initially created by a programmer at a game company (LucasFilm?).

I actually read the algorithm off of a web forum post somewhere. Of course, now I can't find a damn bit of information on it anywhere. It's as if the post vanished from existance, but it has both the algorithm and link to the history of the filter effect, which was supposedly made before scale2x.

Anyway, there's also this on the main sourceforge page:
Quote:
It is also used in some closed source projects (which use rewritten implementations due the license restrictions) :

* Nebula
* Kawaks (with the name KScale)
* Pocket RPG Maker 2005/10

My source is open, too. And anyone is free to use it for personal reasons. It is not compatible with the GPL because I don't "allow" (note that I can't stop anybody) forks of my emulator. Sorry, call me egotistical or hating of freedom or whatever you want, but I've spent nearly two years on bsnes and I don't want some nobody to come along, add one important missing feature, and rename the emulator and do what he wants with it, as has happened countless times to SNES9x. Sorry, I just don't agree with forking. If you don't like my work, great! Make your own, and feel free to look at the code to mine when you get stuck on something. Or better yet, fix the shortcoming in my work, and send me the change. There's a 99% chance that if it isn't a retarded idea, I'll add your code in.

Back to scale2x -- it consists of turning one pixel into four. For each of the four pixels, check the two pixels by its side (for the top left, that'd be the top pixel and left pixel, etc), if they match, make that the new topleft pixel; otherwise, use what's already there. Being able to hold rights to an idea that can be expressed in a single sentence is a horrible precedent.

However, if the scale2x author wants me to remove scale2x from bsnes, I'll be happy to comply.
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Sat Feb 25, 2006 9:42 pm Post subject:

Do you guys just want a forum for bsnes so we can avoid this 1000000 page thread business?
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328

Posted: Sat Feb 25, 2006 9:46 pm Post subject:

byuu wrote:
I did not use Scale2x' source code. I wrote my own implementation of it.

Then you have nothing to worry about.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Sat Feb 25, 2006 9:52 pm Post subject:

pagefault wrote:
Do you guys just want a forum for bsnes so we can avoid this 1000000 page thread business?
Yes, please.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
kevman
Redneck Gamer-Mod


Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh

Posted: Sat Feb 25, 2006 10:40 pm Post subject:

I agree, IF you don't think _Demo_ would mind.

Not that I think he would.
_________________
SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!!

Steelers no longer officially own your ass. Pittsburgh will miss The Bus.
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Sat Feb 25, 2006 11:15 pm Post subject:

Yea, A seperate forum is a good idea.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Feb 26, 2006 2:23 am Post subject:

Sorry pagefault, I've been meaning to address this for a while now.
No need to make bsnes' message board here, since this board is supposed to be for another SNES emulator :)

I'll talk to Derrick (my web host) about setting me up a canned message board ala phpBB. I've been meaning to write my own for a while now, but I just don't have the time.

I appreciate the hospitality in the mean time very much. Give me until next week and it should be up.
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Sun Feb 26, 2006 10:43 am Post subject: Cheat thing.

Is there going to be a cheat thingy on the bsnes?

Have you thought about adding one on it?

The ZSNES and some others have one already built in.

Btw: I think scanners will be great to see on the bsnes. Please continue working on the scanners built in. Very Happy

Oh how about adding a roms scanner instead having it open a folder path. (There too many snes roms and open a path is a slowdown to me.) After it scan all the roms, you can click on it to play. Very nice and better this way. Look at ZSNES for exsample.
pagefault
ZSNES Developer
ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden

Posted: Sun Feb 26, 2006 2:09 pm Post subject:

byuu wrote:
Sorry pagefault, I've been meaning to address this for a while now.
No need to make bsnes' message board here, since this board is supposed to be for another SNES emulator Smile

I'll talk to Derrick (my web host) about setting me up a canned message board ala phpBB. I've been meaning to write my own for a while now, but I just don't have the time.

I appreciate the hospitality in the mean time very much. Give me until next week and it should be up.


Ah it's no problem. I just thought it would make it easier for everyone.
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Sun Feb 26, 2006 4:02 pm Post subject: Re: Cheat thing.

KingHanco wrote:
Is there going to be a cheat thingy on the bsnes?

Have you thought about adding one on it?

The ZSNES and some others have one already built in.


Probably. But you'll probably need a powerful machine to run it. Very Happy
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Sun Feb 26, 2006 5:18 pm Post subject:

There's still a lot of stuff Byuu needs to do, so don't expect everything to be implemented at once.
Rome wasn't built in one day either, you know... Wink
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Sun Feb 26, 2006 8:07 pm Post subject: ...

Where is a bugs report area for the bsnes.

I found 3 bugs on the bsnes v0.015.

byuu, check your pm please. I send you the bugs report.
Agozer
16-bit Corpse | Nyoron
<b>16-bit Corpse | Nyoron</b>


Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land

Posted: Sun Feb 26, 2006 8:31 pm Post subject: Re: ...

KingHanco wrote:
Where is a bugs report area for the bsnes.

I found 3 bugs on the bsnes v0.015.

byuu, check your pm please. I send you the bugs report.

There will be one when bSNES gts its own forum section.
_________________
My site with random stuff

whicker: franpa is grammatically correct, and he still gets ripped on?
sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really.
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Sun Feb 26, 2006 9:44 pm Post subject: Re: ...

KingHanco wrote:
Where is a bugs report area for the bsnes.

I found 3 bugs on the bsnes v0.015.

byuu, check your pm please. I send you the bugs report.


You can post them here for now I suppose. Though please don't tell me one of those bugs have anything to do with 'Mario Kart'... (or any special chip not implemented)
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Mon Feb 27, 2006 12:36 am Post subject: Re: ...

Dmog wrote:
KingHanco wrote:
Where is a bugs report area for the bsnes.

I found 3 bugs on the bsnes v0.015.

byuu, check your pm please. I send you the bugs report.


You can post them here for now I suppose. Though please don't tell me one of those bugs have anything to do with 'Mario Kart'... (or any special chip not implemented)
You can run games on Zsnes to verify use of special chips since it displays any special chips used in the rom info.
That's much better than bugging Byuu all the time abt things he already knows...
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Aerdan
A. Lagopus
A. Lagopus


Joined: 16 Aug 2004
Posts: 702

Posted: Mon Feb 27, 2006 2:49 am Post subject:

Or, you could just go use NSRT, which gives more information than ZSNES does and tells you if your ROM is corrupt.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Tue Feb 28, 2006 5:48 pm Post subject:

Aerdan wrote:
Or, you could just go use NSRT, which gives more information than ZSNES does and tells you if your ROM is corrupt.
Oh, yes. Thanks for that info. Very Happy
I didn't know what NSRT was before and didn't bother to find out but now that I have, I can't be without it any more.
Nach really did a great job with this. Cool


Edit 03/02: Nice 'About box' art Byuu. Cool
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam


Last edited by Sith on Thu Mar 02, 2006 11:29 pm; edited 1 time in total
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Thu Mar 02, 2006 11:13 pm Post subject: Yep.

bsnes_030206.jpg shown on his website look nice. Smile
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Mar 03, 2006 4:15 am Post subject:

Thanks, hope I'm not forgetting anyone on the about screen this time.

The art makes the program bigger, but it makes it feel less stiff to have some visual style in there, so what can you do right?

Gotta figure out how to add little icons to the menu options, that would look good.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Mar 03, 2006 5:53 am Post subject:

I see you added the controller image back in, despite your awesome idea to position buttons in the shape of one. Why?

On the subject of style, SNESGT has great icons. The program icon of the super famicom console is really well done. Maybe you can mooch some of them off him. Okay, so maybe that won't happen officially, but I always have the ability to rip and replace icons from exe's with iconcooleditor for my own tastes. Twisted Evil
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Fri Mar 03, 2006 7:19 am Post subject:

FitzRoy wrote:
I see you added the controller image back in, despite your awesome idea to position buttons in the shape of one. Why?

On the subject of style, SNESGT has great icons. The program icon of the super famicom console is really well done. Maybe you can mooch some of them off him. Okay, so maybe that won't happen officially, but I always have the ability to rip and replace icons from exe's with iconcooleditor for my own tastes. Twisted Evil

Unfortunately the lower right edge looks a bit dark on the gray that is the default menu background - fixable though.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Mar 03, 2006 4:37 pm Post subject:

FitzRoy wrote:
..., despite your awesome idea to position buttons in the shape of one. Why?

Agreed, that is a great setup, plz don't ditch it Byuu...
Maybe you could place a controller image fitted behind this setup?
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam


Last edited by Sith on Fri Mar 10, 2006 7:30 pm; edited 1 time in total
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Fri Mar 03, 2006 5:19 pm Post subject:

No, it's still in there, it's just that now a controller image accompanies it. I guess I just saw it as redundant. Plus, I only see that window once every... ever.

I think it would be cool if the images were pointed to outside the exe. That way, the user could customize the art, or remove it entirely. Maybe I'm asking too much. I'll shut up now Smile
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Fri Mar 03, 2006 5:33 pm Post subject:

I did that with vSNES... turned out to be not so great (since they're not visible at design-time).

The user can always exchange the EXE ressources, or recompile the source if s|he has the compiler.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
tetsuo55
Regular


Joined: 04 Mar 2006
Posts: 301

Posted: Sun Mar 05, 2006 9:03 am Post subject: unified rom database

Any updates on the rom database?? i would like to help out get this off the ground!
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Sun Mar 05, 2006 4:28 pm Post subject: Re: unified rom database

tetsuo55 wrote:
Any updates on the rom database?? i would like to help out get this off the ground!

Huh? Wrong thread, man.
That's NSRT stuff.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam


Last edited by Sith on Fri Mar 10, 2006 7:31 pm; edited 1 time in total
tetsuo55
Regular


Joined: 04 Mar 2006
Posts: 301

Posted: Sun Mar 05, 2006 4:45 pm Post subject: Re: unified rom database

Sith-Smasher wrote:
tetsuo55 wrote:
Any updates on the rom database?? i would like to help out get this off the ground!
Huh? Wrong thread, man.
That's NSRT stuff.


Actually nash and byuu where working toghether to create a new database that will be included in both NSRT and bsnes/zsnes
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sun Mar 05, 2006 7:35 pm Post subject:

SNESGT has one awesome configuration screen, wish I knew how to make that control he uses where you have a list with expandable entries and listboxes / radioboxes inside. I could greatly simplify the UI and add a ton more functions to an "advanced" section. Anyone know if that control is part of the common controls? :/

Someone wanted the controller art back in there after I took it out, so I shrunk it and stuck it on there. Wouldn't look good behind the buttons.

Don't want the art outside the EXE because it adds extra files. I'd like to keep the requirement of there only being one file necessary to run bsnes, the main exe. It auto generates the config and still works even if that fails.
I guess I could just make an art/ folder and make it just skip drawing if the image doesn't exist.

I don't think anything's happened with the ROM database.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sun Mar 05, 2006 9:04 pm Post subject:

Yeah, it is pretty cool. You might lose convenience with some things, but it's neat to do it that way since many settings require a new window to open anyway (video filters, controller cfg, save paths). With this, you have one window opening for all.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Sun Mar 05, 2006 9:17 pm Post subject:

Thanks for the info Byuu, keep us posted.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Fri Mar 10, 2006 2:47 pm Post subject:

http://rapidshare.de/files/15154041/bsnes-patch-2006-03-10.zip.html

bcpu_mmio.patch fixes Castlevania - Dracula X
bdsp.patch fixes the sounds in Earthworm Jim 2
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code
dinput.patch and ui_ppucfg.patch both fix macros for GCC
Makefile.mingw can be used to compile bsnes with msys/mingw/gcc
bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer. A config file option for this would be useful.

byuu wrote:
SNESGT has one awesome configuration screen, wish I knew how to make that control he uses where you have a list with expandable entries and listboxes / radioboxes inside. I could greatly simplify the UI and add a ton more functions to an "advanced" section. Anyone know if that control is part of the common controls? :/

TreeView
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Fri Mar 10, 2006 6:16 pm Post subject: Re:

Edit. Everymine it my computer problem. Anyway thanks for the fixs on the games.
_________________
"Zsnes is the best one there is." Smile
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Mar 10, 2006 11:23 pm Post subject:

Awesome!!! You so totally rule! Thanks a million, as always :D

Quote:
bcpu_mmio.patch fixes Castlevania - Dracula X

Hell! I've been trying to fix that one for weeks. Grah, I've been meaning to test what happens when you start a DMA transfer with HDMA active for a long time, too. I just assumed it'd kill the HDMA. So I wonder what happens if a DMA is in progress on a given channel and then the HDMA transfer starts ...

Quote:
bdsp.patch fixes the sounds in Earthworm Jim 2

... there was a problem with them before?

Quote:
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code

I don't see the Sprite+Y priority code. This fix I really don't follow, other than that I see now that anomie's document was assuming OAMaddr was a word index and not a byte index.
What's up with y-1 when oamaddr&3=3? I thought sprite+y was when oamaddr&0xf=0xa? And firstsprite is reset on each scanline? anomie's doc says it's done once per frame... guess not :/

Quote:
dinput.patch and ui_ppucfg.patch both fix macros for GCC

Oh, I forgot to add that last time, sorry.

Quote:
bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer. A config file option for this would be useful.

I'll do just that, thanks. I didn't think that would be an issue with only 128kb/s of data.
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Sat Mar 11, 2006 3:21 am Post subject:

DMV27 wrote:
http://rapidshare.de/files/15154041/bsnes-patch-2006-03-10.zip.html
[list]
bcpu_mmio.patch fixes Castlevania - Dracula X
bdsp.patch fixes the sounds in Earthworm Jim 2
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code
dinput.patch and ui_ppucfg.patch both fix macros for GCC
Makefile.mingw can be used to compile bsnes with msys/mingw/gcc
bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer. A config file option for this would be useful.


OH MY FUCKING GAWD! LEFT FIELD!

Twisted Evil
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Mar 11, 2006 7:04 am Post subject:

Quote:
bcpu_mmio.patch fixes Castlevania - Dracula X

Added. Works exactly as stated.

Quote:
bdsp.patch fixes the sounds in Earthworm Jim 2

So it does, so it does... when an enemy hits you there was some minor crackling sounds, now it's crystal clear. Awesome. No other intensive APU game is affected, as far as I can tell. Chrono Trigger, Tales of Phantasia, Star Ocean, Final Fantasy VI and Dai Kaijuu Monogatari all sound find.
Might I ask where you got your bugfix information from? Just want to make sure it's definitely sound (hehe) before I remove the old code entirely (it's commented out for now).

Quote:
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code

I see what you mean by the Sprite+Y code. Hmm, wonder if there's even a single game out there to test this with :/
Still not sure I totally follow the code, or if its definitely supposed to update every scanline instead of every frame.
Went ahead and moved OAM address reset to 225/240, that's probably how it should be like you were commenting.

Quote:
dinput.patch and ui_ppucfg.patch both fix macros for GCC

Added.

Quote:
Makefile.mingw can be used to compile bsnes with msys/mingw/gcc

I'll include it with the release, but I can't maintain it as I don't have MinGW.

Quote:
bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer.

The program crashes immediately (can't create DSound device) when I set DSBCAPS_LOCHARDWARE, and if I don't set either, it just uses software mode anyway. Darn, I was hoping this might fix the sound skipping that occurs when triple buffering is enabled in fullscreen mode. Ah well.

And for the bad news, I only found one other bug that was fixed by these changes. The SNES Test Program correctly doesn't show the middle sprite when sprite interlace is enabled during the character test. Before it was hiding a sprite near the right of the screen, which was wrong.
Tested RPM Racing, Genjuu Ryodan, Mortal Kombat, and SNES Test 0x70 (it passes 1 in 3 tries, I have no idea what changed or when to break this, not even sure which test it is without my debugger) to no avail. Don't have the other games that aren't working.
And for some good news on top of that, nothing new broke that I could find :D

At any rate, absolutely awesome. This is exactly what I needed for a new release, some real bug fixes instead of just GUI fluff. Thanks again, DMV27! I'll have to start listing you as a main developer here soon ;)

On a semi-related note, I guess now's a good time to mention that I added Game Genie / Pro Action Replay support. It saves to a config file, and that config file saves in your save_path with your SRAM files. One for each game. No GUI interface yet, and I'm also planning to make a cheat.db file to include with bsnes that stores CRC32 identifiers for games, along with lists of known cheat codes. The GUI will have an option to import all cheats it can find with the press of one button so you don't have to look all the cheats up online all the time. Might want a volunteer to maintain that, but let me wait till I get it in there first.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Mar 11, 2006 7:16 am Post subject:

byuu wrote:
And for the bad news, I only found one other bug that was fixed by these changes. The SNES Test Program correctly doesn't show the middle sprite when sprite interlace is enabled during the character test. Before it was hiding a sprite near the right of the screen, which was wrong.
Tested RPM Racing, Genjuu Ryodan, Mortal Kombat, and SNES Test 0x70 (it passes 1 in 3 tries, I have no idea what changed or when to break this, not even sure which test it is without my debugger) to no avail. Don't have the other games that aren't working.
And for some good news on top of that, nothing new broke that I could find Very Happy


And you call that bad... Razz

Quote:
At any rate, absolutely awesome. This is exactly what I needed for a new release, some real bug fixes instead of just GUI fluff. Thanks again, DMV27! I'll have to start listing you as a main developer here soon Wink

On a semi-related note, I guess now's a good time to mention that I added Game Genie / Pro Action Replay support. It saves to a config file, and that config file saves in your save_path with your SRAM files. One for each game. No GUI interface yet, and I'm also planning to make a cheat.db file to include with bsnes that stores CRC32 identifiers for games, along with lists of known cheat codes. The GUI will have an option to import all cheats it can find with the press of one button so you don't have to look all the cheats up online all the time. Might want a volunteer to maintain that, but let me wait till I get it in there first.


Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support.
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Mar 11, 2006 7:21 am Post subject:

Quote:
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support.

No. Goldfinger codes are bullshit. If someone writes the encoder/decoder for me, I might add it in. If it requires even one bit of information about the ROM to work (e.g. LoROM/HiROM), then I won't bother.
Does anyone even use these worthless codes for anything? Pro Action Replay are the only sensible ones. They work on RAM addresses, address the entire 16mb memory map, and are in plain text with no drunken lunatic encoding ala Game Genie, so anyone can easily play around with them to make their own code variations.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Sat Mar 11, 2006 7:27 am Post subject:

byuu wrote:
Quote:
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support.

No. Goldfinger codes are bullshit. If someone writes the encoder/decoder for me, I might add it in. If it requires even one bit of information about the ROM to work (e.g. LoROM/HiROM), then I won't bother.
Does anyone even use these worthless codes for anything? Pro Action Replay are the only sensible ones. They work on RAM addresses, address the entire 16mb memory map, and are in plain text with no drunken lunatic encoding ala Game Genie, so anyone can easily play around with them to make their own code variations.


Hmm..

I'm not overly concerned.. I've never really gotten a total explanation of the cheat devices. Pro Action Replay is more powerful eh?

I've never seen the Pro Action Replay stuff... (let alone the Goldfinger stuff)... I have seen two Game Genies.. and boy... it is kinda funky.

I remember seeing the Game Genie for the NES and SNES.. the code system for the NES looked pretty fucked up. The SNES version seemed slightly more sensible.. as the codes seemed to resemble hex, but I'm no genius as to how it actually works.
_________________
FF4 research never ends for me.


Last edited by Deathlike2 on Sat Mar 11, 2006 7:40 am; edited 1 time in total
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Sat Mar 11, 2006 7:36 am Post subject:

Hm, SNES test 0x70 is due to my overscan changes. I made it not take effect until the start of the next frame, like interlace. The test doesn't like that.

I need to just run my damn tests on overscan already and get that out of the way :/
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Sat Mar 11, 2006 4:49 pm Post subject:

Deathlike2 wrote:
I have seen two Game Genies.. and boy... it is kinda funky.

I remember seeing the Game Genie for the NES and SNES.

I had a Game Genie for the original Gameboy. That was one heavy combination.

You can see what it looks like: http://en.wikipedia.org/wiki/Image:Game_Genies.jpg
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
DMV27
Rookie


Joined: 27 Jan 2005
Posts: 32

Posted: Mon Mar 13, 2006 10:42 am Post subject:

byuu wrote:
I don't see the Sprite+Y priority code. This fix I really don't follow, other than that I see now that anomie's document was assuming OAMaddr was a word index and not a byte index.
What's up with y-1 when oamaddr&3=3? I thought sprite+y was when oamaddr&0xf=0xa? And firstsprite is reset on each scanline? anomie's doc says it's done once per frame... guess not :/

The y-1 is used instead of just y because sprite RTO is calculated one scanline before it is rendered. For example, bsnes will render sprites on line 1 that were setup on line 0 (bsnes will actually setup the sprites on line 1, so the y-1 is basically a hack). The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'. "oamaddr&3==3" is used because regs.txt says "e.g. so the next byte written would go to the last byte in the 4-byte sprite record". Firstsprite must be reset on each line, otherwise sprite+y priority wouldn't do anything (y would always be zero). Also, Uniracers 2-player mode updates oam mid-frame.

Quote:
So it does, so it does... when an enemy hits you there was some minor crackling sounds, now it's crystal clear. Awesome. No other intensive APU game is affected, as far as I can tell. Chrono Trigger, Tales of Phantasia, Star Ocean, Final Fantasy VI and Dai Kaijuu Monogatari all sound find.
Might I ask where you got your bugfix information from? Just want to make sure it's definitely sound (hehe) before I remove the old code entirely (it's commented out for now).

I can't test anything on a real SNES, but I got the info from sfsound.txt. In the ENDX section it says "When BRR decode of the block having the Source end flag is completed, the DSP section sets up a "1" 00-7 correspond to Voice0-7." This means that ENDX is only set when the BRR decoding for an end block is finished. For non-looping end blocks decoding stops immediately, so ENDX gets set as soon as the block header is read. For looping end blocks decoding does not stop until the block is fully decoded, so ENDX must wait until the end of the block before it gets set.

I should have more patches for you soon. I have been going through the 65816 code and have found quite a few minor timing and open bus bugs. I also noticed that you do not handle stack overflow properly for 65816-only opcodes (see anomie's ob-wrap.txt). I can fix that too if you want, although it will require many changes to the cpu code.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Mar 13, 2006 1:13 pm Post subject:

Quote:
The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'.

Ah, I see. Also, I don't think Uniracers would quie work yet, doesn't that actually expect the OAM address to be updated by the PPU while the line is rendering? I recall we don't know how that address updating works.

Quote:
I should have more patches for you soon. I have been going through the 65816 code and have found quite a few minor timing and open bus bugs. I also noticed that you do not handle stack overflow properly for 65816-only opcodes (see anomie's ob-wrap.txt). I can fix that too if you want, although it will require many changes to the cpu code.

Sounds awesome, thanks! If you want to just explain what's wrong with my stack overflow I can try and correct it, or if you prefer to patch it instead that's fine too.
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Mon Mar 13, 2006 2:44 pm Post subject:

DMV27 wrote:
Also, Uniracers 2-player mode updates oam mid-frame.

Almost all split-screen games should do that (e.g. Contra 3) ...
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Wed Mar 15, 2006 12:09 am Post subject:

The new update looks great byuu! I can't wait to try out the next release.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
FitzRoy
Zealot


Joined: 04 Aug 2004
Posts: 1078

Posted: Wed Mar 15, 2006 1:33 pm Post subject:

Indeed, and DMV27 = bughunter extraordinaire. Eternal thanks. Keep up the great progress, everyone.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Wed Mar 15, 2006 3:43 pm Post subject:

I've just read the 'Bsnes news' update. This is only getting more awsome. Cool
Great stuff, Byuu & thx to DMV27 for the bugs as well.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
King Of Chaos
Regular


Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA

Posted: Wed Mar 15, 2006 7:18 pm Post subject:

YESSSSSS!!! Thanks man, I owe ya one for the PAR/GG support. Very Happy Wink
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Mar 16, 2006 8:46 am Post subject:

How's this for the video mode configuration screen?



You still have all ten video modes, but you can control everything below the first separator for each mode now. By default, it tries to auto-calculate the screen size for you, but you can of course opt to manually input any size you want.

I actually forgot to put the screen size multiplier on there (1x-5x or so), so pretend that's in there somewhere. Oh, and pretend there's an overscan combo box on there for selecting NTSC mode (always render x224 height, clip x239 mode to fit in window), PAL mode (render at x239 height with x224 modes at the top of the screen -- e.g. as SNES9x does it now with the black bar), and PAL centered mode (render at x239 height with x224 modes centered). Grr, and also pretend there's a refresh rate box to the right of the fullscreen resolution.
tetsuo55
Regular


Joined: 04 Mar 2006
Posts: 301

Posted: Thu Mar 16, 2006 8:51 am Post subject:

Looks great byuu!

your next version is probably going to look awesome on my TFT, i cant wait till blargg's ntsc filter is completely done and he makes a pal filter too (still hoping for the pal filter, fingers crossed)

BTW my monitor supposedly supports 70hz refreshrate (Samsung Syncmaster 710t) any point in using 70hz?
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Thu Mar 16, 2006 9:00 am Post subject:

tetsuo55 wrote:
BTW my monitor supposedly supports 70hz refreshrate (Samsung Syncmaster 710t) any point in using 70hz?

No. Only a multiple of the base frequency (60/50 Hz should be close enough for emulation) would be useable.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.


Last edited by creaothceann on Thu Mar 16, 2006 10:44 am; edited 1 time in total
tetsuo55
Regular


Joined: 04 Mar 2006
Posts: 301

Posted: Thu Mar 16, 2006 10:18 am Post subject:

crappy thing about tft is you have to use 60hz, thats why im hoping for a pal60 filter
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Thu Mar 16, 2006 2:23 pm Post subject:

Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
kieran_
Mugwump


Joined: 30 Jul 2004
Posts: 2966

Posted: Thu Mar 16, 2006 2:31 pm Post subject:

Clements wrote:
Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz.

Why?
I know nothing of these things, other than anythng less than 85Hz kills my eyes.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Mar 16, 2006 2:49 pm Post subject:

@byuu: On the video settings page, where you have "Select video mode to configure: Mode 0", this is the 10 customizable resolution modes? This seems *kinda* like a misnomer, since there is also the SNES-internal Modes 0-7. Maybe you can think of a different word to use? I know it confused me at first glance.



herzog wrote:
Clements wrote:
Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz.

Why?
I know nothing of these things, other than anythng less than 85Hz kills my eyes.

Because LCDs don't flicker, no matter what the refresh rate. The screen still updates at only 60Hz, whereas a CRT would update at 120Hz if you had the resolution set to that. But LCDs don't flicker even if the refresh rate was 1Hz. You would just have mouse trails. Smile

Here's an excellent, and funny article on the subject: http://www.dansdata.com/gz021.htm
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/


Last edited by Jipcy on Thu Mar 16, 2006 6:09 pm; edited 1 time in total
Clements
Randomness


Joined: 28 Jul 2004
Posts: 2313
Location: Britain

Posted: Thu Mar 16, 2006 2:51 pm Post subject:

LCD monitors do not flicker by design, whereas CRT's do. The flickering of CRT tech can cause considerable eye strain, especially at low refresh rates.

Edit: Yep, Jipcy beat me to it. Laughing
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Thu Mar 16, 2006 4:46 pm Post subject:

Jipcy wrote:
... since there is also the SNES-internal Modes 1-7.

Actually it's 0-7.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Thu Mar 16, 2006 5:10 pm Post subject: Here is my screen setting.

1280 by 1024 pixels

Screen refresh rate - 180 Hertz - It speed up and alot better than setting on 60 Hertz. My mouse point is fast when I move it. Btw: I uncheck the Hide modes that this monitor cannot display.

I have Sony Display TFT LCD 5:4.

Works fine here using a ATI Radeon 9550 graphics card. Very Happy
_________________
"Zsnes is the best one there is." Smile
kieran_
Mugwump


Joined: 30 Jul 2004
Posts: 2966

Posted: Thu Mar 16, 2006 5:29 pm Post subject:

Thank you for asking my question. And thanks for that link.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Thu Mar 16, 2006 6:10 pm Post subject:

creaothceann wrote:
Jipcy wrote:
... since there is also the SNES-internal Modes 1-7.

Actually it's 0-7.

Whoops. I think the intention of my words were clear, though.

KingHanco wrote:
1280 by 1024 pixels

Screen refresh rate - 180 Hertz - It speed up and alot better than setting on 60 Hertz. My mouse point is fast when I move it. Btw: I uncheck the Hide modes that this monitor cannot display.

I have Sony Display TFT LCD 5:4.

Works fine here using a ATI Radeon 9550 graphics card. Very Happy

Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Thu Mar 16, 2006 7:36 pm Post subject:

Jipcy wrote:
creaothceann wrote:
Jipcy wrote:
... since there is also the SNES-internal Modes 1-7.

Actually it's 0-7.

Whoops. I think the intention of my words were clear, though.

Yeah. I was wondering about it as well.

Jipcy wrote:
KingHanco wrote:
1280 by 1024 pixels

Screen refresh rate - 180 Hertz - It speed up and alot better than setting on 60 Hertz. My mouse point is fast when I move it. Btw: I uncheck the Hide modes that this monitor cannot display.

I have Sony Display TFT LCD 5:4.

Works fine here using a ATI Radeon 9550 graphics card. Very Happy

Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.

Is the TFT actually fast enough that it makes a difference? Neutral
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Thu Mar 16, 2006 7:48 pm Post subject:

creaothceann wrote:
Jipcy wrote:
creaothceann wrote:
Jipcy wrote:
... since there is also the SNES-internal Modes 1-7.

Actually it's 0-7.

Whoops. I think the intention of my words were clear, though.

Yeah. I was wondering about it as well.

Jipcy wrote:
KingHanco wrote:
1280 by 1024 pixels

Screen refresh rate - 180 Hertz - It speed up and alot better than setting on 60 Hertz. My mouse point is fast when I move it. Btw: I uncheck the Hide modes that this monitor cannot display.

I have Sony Display TFT LCD 5:4.

Works fine here using a ATI Radeon 9550 graphics card. Very Happy

Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.

Is the TFT actually fast enough that it makes a difference? Neutral


Refresh rates shouldn't really affect LCDs, but rather the game it is running on...
_________________
FF4 research never ends for me.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Thu Mar 16, 2006 11:20 pm Post subject:

LCDs still have to have refresh rates, which is how the video data gets from the video card to the LCD. They may not make a difference because the pixel response time is lower than the refresh rate, but it does still control how fast pixels are pumped through your VGA/DVI cable. So at the very least, a faster refresh rate lets the pixel know to start changing sooner...

I wish the damn things weren't so overpriced. I desperately want a widescreen monitor. CRT or LCD, I could care less. I just want a true, 16:9 widescreen monitor. I'd even settle with those bastardized 16:10 ones so long as the pixels were still square (I could just crop some borders on the top and bottom for movies, etc). My 19" CRT cost me $130 new and is a high quality viewsonic with excellent color response. A 17"-19" widescreen CRT shouldn't cost more than $200. The cheapest widescreen CRT I've found is $999, and the cheapest LCD is $350, whereas the 4:3 (which ironically has more actual pixels) ones go for $200 easily.
</rant>

By the way, does anyone know for certain why some LCD monitors look exactly like plasma (yet definitely aren't plasma) with ultra vivid glossy picture-like images, whereas other LCD monitors look like the old DTSN laptop displays?
Ichinisan
Zealot


Joined: 28 Jul 2004
Posts: 1336

Posted: Thu Mar 16, 2006 11:31 pm Post subject:

The Dell 2005FPW was recently going for less than $350 shipped. I purchased mine when MSRP was $1,200 and I paid about $580

I could not be more pleased with the performance of the display. It's is the best performing panel on the market in terms of colors and pixel response. It was worth every penny that I paid and Dell continually releases coupon codes that make me want to buy a bundle of them.

Flaws? No component input, 16x10 aspect.
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Fri Mar 17, 2006 8:55 am Post subject:

Alright, I dropped the line 224 toggle. Too confusing for the average user. I'll probably add the option back later on an advanced screen or something. I think I should make the render width/height boxes gray out if the manual render screen size box is unchecked. Same for fullscreen mode settings.

I also added in all the back-end code, so this is now completely functional. If anyone has a better name for the video mode thing at the top (so that it's less confusing), let me know.

The ten video modes can be cycled via ctrl+[1-0] or Menu->Settings->Video Mode->[1-0]



Also, what's everyone's opinion on this?


I then make the filter config screen always on top, so you can adjust the screen size settings while still being able to see the screen itself. Obviously only works on Win2k and above. No idea what Win98 would do, but I could always encapsulate the call to SetLayeredWindowAttributes to safely fail or something I suppose.
Deathlike2
ZSNES Developer
ZSNES Developer


Joined: 28 Dec 2004
Posts: 5599

Posted: Fri Mar 17, 2006 9:11 am Post subject:

Looks nice.

As for the transparancy.. some Win9x user has test it to comment on it... I think you're using a Windows specific function or something? If it is, it will probably just not work at all. Then again, I don't know what would happen.
_________________
FF4 research never ends for me.
Sith
Trooper


Joined: 19 Jul 2005
Posts: 358
Location: Belgium

Posted: Fri Mar 17, 2006 3:52 pm Post subject:

AWESOME! Shocked
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Mar 17, 2006 3:54 pm Post subject:

I am definitely in favor of a transparent options windows.
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Mar 17, 2006 6:07 pm Post subject:

Awesome indeed.

So much control over the display settings...Custom resolution...'per Snes display mode configuration' (KegaFusion has something similar actually) plenty of filters,Blargg's amazing NTSC filter..

And the transparent windows effect is great imo.
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Fri Mar 17, 2006 6:32 pm Post subject:

Dmog wrote:
'per Snes display mode configuration'

What?
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
Dmog
Trooper


Joined: 31 Aug 2004
Posts: 417

Posted: Fri Mar 17, 2006 6:46 pm Post subject:

Jipcy wrote:
Dmog wrote:
'per Snes display mode configuration'

What?


...The Snes has many display modes. And it looks like you can configure them individually in bsnes. In the display settings it says: Select video mode to configure.

Unless I misunderstood something that means for example that you could apply a filter to say mode 7 and not mode 1.
adventure_of_link
Locksmith of Hyrule


Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255

Posted: Fri Mar 17, 2006 6:49 pm Post subject:

Hey Byuu, that's pretty cool.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2324
Location: Germany

Posted: Fri Mar 17, 2006 7:32 pm Post subject:

Dmog wrote:
...The Snes has many display modes. And it looks like you can configure them individually in bsnes. In the display settings it says: Select video mode to configure.

Read again:

byuu wrote:
The ten video modes can be cycled via ctrl+[1-0] or Menu->Settings->Video Mode->[1-0]


SNES has only 8 modes.
_________________
savestate editor: vSNES latest public version

FitzRoy wrote:
Seriously, people need to stop arguing with me on this.
MajereDB8
Rookie


Joined: 08 Oct 2005
Posts: 18

Posted: Fri Mar 17, 2006 10:40 pm Post subject:

byuu wrote:
I also added in all the back-end code, so this is now completely functional. If anyone has a better name for the video mode thing at the top (so that it's less confusing), let me know.


I'd suggest the label "Video Preset," with each combobox items called "Preset n." If possible, it might also be a good idea to add a tool tip when you put the mouse over the label stating that bsnes allows users to store up to 10 video configurations that can be cycled during use. This would likely cut down on questions from people who don't RTFM.

It's a bit wonky I admit, but most people have probably used a media player that uses the "preset" nomenclature. Back to minding my own business now... Smile
KingHanco
Lurker


Joined: 26 Feb 2006
Posts: 152

Posted: Sat Mar 18, 2006 12:41 am Post subject: ...

byuu, you getting me closer to it everytime I look at your wip screenshots. Cool

Now that is what I call a bsnes. Wink
_________________
"Zsnes is the best one there is." Smile
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414

Posted: Mon Mar 20, 2006 6:10 am Post subject:

I went with profile. I was actually meaning to go with your suggestion, MajereDB8, but I guess I got it mixed up in my head or something. Ah well.

In other news, I added DSP-2 support so everyone can play the Atari E.T. equivalent for the SNES.


Finalized video config screen:
Jipcy
Inmate


Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley

Posted: Mon Mar 20, 2006 6:31 am Post subject:

You're going to have to start writing documentation for your emulator now that you have all these complicated options. Mr. Green
_________________
Official ZSNES Docs

http://www.flickr.com/photos/jipcy/
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2414