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!? : 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

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


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

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


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


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


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 )
_________________

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

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: 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
|
|
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


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 
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu 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

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? 
_________________
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
|
|
byuu 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. 
byuusan wrote: |
They'll be there eventually, though. |
Great! 
_________________
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


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


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!
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

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

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
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

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


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? 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


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

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?

- 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

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: |
|
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

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!  |
|
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. 
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  |
|
byuu 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.  |
|
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

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.
 |
|
byuu 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
|
|
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

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. 
It's just that when I use bsnes with my QuickPlay frontend, zip files won't work. 
Excellent work on the emulator so far.  |
|
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


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

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


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

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

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


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


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

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


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


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


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  |
|
Deathlike2 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

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

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


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


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

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! 
_________________
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
|
|
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


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

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

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

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


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

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 
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

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.  |
|
Aerdan 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


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


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. 
_________________
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 
_________________

<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

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

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

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

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 (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

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


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. 
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
byuu 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
|
|
Pepper New Member
Joined: 08 Sep 2005
Posts: 6
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
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

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

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. 
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?
|
|
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 
...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


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 
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


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

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
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
|
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

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


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 
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 !! 
I can't wait until you release the next version!
|
|
Nach 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 
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. 
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. 
I think I oughta add that as another sig quote... |
That's not a very nice thing to say about byuu
|
|
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... 
_________________

<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


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

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

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

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

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.  |
|
byuu 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
|
|
byuu 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

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

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

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. 
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.  |
|
Nach 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

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


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

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. Thanks.
|
|
Nach 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

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


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

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

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

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
|
|
|
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 06, 2005 10:33 am Post subject: |
|
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: |
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!
|
|
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

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

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!  |
|
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

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

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

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: |
|

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


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


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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 15, 2005 9:05 am Post subject: |
|
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


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Dec 15, 2005 10:23 am Post subject: |
|
byuu wrote: |
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...
|
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

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


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

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


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. 
_________________
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.
|
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. 
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. That might slow down requests.  |
|
pagefault 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.
|
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. 
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

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 
And yes, super thanks to anomie for his research and sound code. People
helping each other = better emulators all around.  |
|
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

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

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

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

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

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

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

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

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

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 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

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


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

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


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

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


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

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


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

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
|
|
Nach 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 .
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 .
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

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


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 
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

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
|
|
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

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

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


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

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

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

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

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


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


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

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

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.
|
|
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). 
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. 
P.S. Thanks for restoring my faith in SNES emulation.  |
|
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).  |
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).  |
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.
|
|
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
|
|
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

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

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

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'!
|
|
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. 
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! 
@KingOfChaos: nice to find you here as well, hehe. 
_________________
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. 
*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  |
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  |
|
|
byuu 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?  |

Erm, more than 10 GHz... ?
EDIT: Just wanted to add that speedrunners don't need 100% real-time speed... 
_________________
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?  |

Erm, more than 10 GHz... ?
|
No idea either 
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! 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! 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! 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 "
I would think that's a good teaser that he's at least considering it. 
_________________
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. (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? 
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
|
|
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! 
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. 
_________________
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

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 s, 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.  |
|
Nach 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

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


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

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


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

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


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


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

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


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 
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.
|
|
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... 
_________________
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


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


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. 
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. 
Edit 03/02: Nice 'About box' art Byuu. 
_________________
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.  |
|
byuu 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.  |
|
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.  |
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  |
|
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

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."  |
|
byuu 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!
|
|
byuu 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

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  |
And you call that bad... 
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 
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

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

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

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
|
|
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

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
|
|
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. 
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.  |
|
byuu 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
|
|
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. 
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. 
_________________

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. 
_________________
"Zsnes is the best one there is."  |
|
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.  |
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.  |
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? 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Deathlike2 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.  |
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?
|
Refresh rates shouldn't really affect LCDs, but rather the game it is running on...
_________________
FF4 research never ends for me.
|
|
byuu 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

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

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
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
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
|
|
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...
|
|
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. 
Now that is what I call a bsnes. 
_________________
"Zsnes is the best one there is."  |
|
byuu 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
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 20, 2006 8:53 am Post subject: |
|
One
thing I've been throwing around is a simple and advanced mode switch.
One takes the KDE approach of throwing a trillion features at you to
configure to your liking. The other like GNOME, keeps things as simple
as possible, options only where you'd need them.
I'll think about it more tomorrow. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 20, 2006 10:34 am Post subject: |
|
Ha, brilliant! Gotta love the "Hall of Champions" theme song, at least. 
Here is my first recording from the digisnes. It is the full initial
intro loop of Super Castlevania IV, from konami logo, to title, to
intro, to game demo, ending before next konami logo (3.5 minutes). This
particular recording is great for analysis because it contains lots of
different sound rape effects, music, and some sound effects alone
without music. Since it is all automated and not gameplay, logging the
same sequence of sound on bsnes was a piece of cake. I removed the
silence at the beginning and end with a cooledit option to match the
two wavs up as exactly as possible. The lengths are not exactly the
same though, probably due to the timing discrepencies brought up
earlier in the dev forum. A couple of things I've noticed after noob
analyzing the two wavs: bsnes emulates the sound effects correctly, but
the overall amplitude is higher and the distortion on the lightning
effect seems more pronounced.
http://rapidshare.de/files/15960765/castlevania4-real.rar.html
http://rapidshare.de/files/15960372/castlevania4-bsnes.rar.html
http://rapidshare.de/files/16055697/castlevania4-sneese.rar.html
http://rapidshare.de/files/16044291/castlevania4-zsnes.rar.html
http://rapidshare.de/files/16045306/castlevania4-snes9x.rar.html
EDIT: Just thought I'd mention that data from the real should be
objectively taken with a grain of salt. I've taken several more
recordings of each to make sure the times are right. Turns out, I get
differences (to the ms) from the real source, but bsnes always cuts to
the same exact length. The analysis numbers seem to change for the real
as well. Don't really know if this is my fault, or just something wierd
the snes is doing that I have no control over. I also don't know if
kmixer has any role in any of this. Bsnes does appear extremely close
if not perfect with sound.
Last edited by FitzRoy on Tue Mar 21, 2006 1:49 pm; edited 4 times in total |
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Mon Mar 20, 2006 5:21 pm Post subject: |
|
byuu wrote: |
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. |
No worries. "Profile" is a more neutral and appropriate term anyway,
since the video modes aren't really "preset" but must be configured by
the user.
Can't wait to see what good stuff is coming in the future. I've gotten
into a habit of hitting this thread and the board in general just to
find out what interesting research is being done on the SNES.
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Mon Mar 20, 2006 11:45 pm Post subject: |
|
This new Bsnes-stuff just makes me drool. Byuu, you da man. 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 21, 2006 6:48 am Post subject: |
|
Quote: |
bsnes
emulates the sound effects correctly, but the overall amplitude is
higher and the distortion on the lightning effect seems more pronounced. |
Thanks for making these! It's very close, but work still needs to be done :)
Once I get a digital SNES, and a high-paying part-time job
(hahahahahahahahahaha), I'll probably start working on SPC700 emulation
directly, instead of solely relying on anomie's (absolutely awesome)
DSP core.
I believe the real SNES one sounds better, not by much, but definitely
better. The lightning is still kind of choppy on the real one, but much
less so than bsnes. I wonder if you could get a sound rip from e.g.
ZSNES / SNES9x to compare further? I've missed some rather obvious bugs
in the past (eg Mortal Kombat 2 SRCn bug), so maybe those emus get the
lightning better.
BTW if you do others, Earthworm Jim 2 would be a good one (though
impossible to line up, we could see if the sound effects cut out as
frequently as they do in emulation), as would the ToP vocal intro
(which could be lined up). I wouldn't do any just yet though,
especially not EWJ2. DMV27 fixed some new bugs in the DSP that greatly
improve at least EWJ2.
The real SNES will always be different because of fluctuations in the
timing crystals. So you'll get somewhere between 32,000hz - 32,100hz or
so in realtime. I think it's most often ~32,040hz.
The output on the SNES would be exactly the same every time if only the
SPC700 was used by itself (though it may actually play faster or
slower, the digital output would be bit-for-bit the same). But since
there is communication between the CPU and APU, and they are running at
slightly different speeds each time, you end up with minor timing
differences every time.
With a PC, the same fluctuations exist, but they don't affect the
underlying output because all of the "SNES chips" are ran off the same
CPU clock, so your output is always identical. I could emulate this
fluctuation easily enough by emulating random "fractions" of opcodes
(say, +/- 0.001%), but eh, why bother? I'd rather use the reference
"stock" speeds of 21.477mhz and 24.576mhz instead. If a game can't run
with that, it will very realistically die on the real console as well.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 21, 2006 11:03 am Post subject: |
|
No
prob! Yeah, that info about the snes clocks really explains the length
discrepencies. Regarding the zsnes and snes9x samples you requested - I
made those tonight and edited my post with the links. I used a digital
loopback for both recordings. ZSNES is with latest wip and default
sound settings. Snes9x 1.43 needed to be set from 22khz (default) to
32khz.
I'm not sure if you were hoping for zsnes
or snes9x to show you something, but prepare to be disappointed. Things
to look for:
-konami logo fade gets cut off
-bats and lightning very wrong (should we call this "konami rape" now?)
-some sfx from "game demo" part are affected.
As far as making new ones, I mentioned in another thread that I am
without a copier these days and my cart selection is dwindling as well.
Looks like EWJ2 and ToP will have to wait till you get yours up and
running. I'll probably do the chrono trigger beginning sequence next,
but these c4 wavs seem to satisfy much for comparison. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 21, 2006 1:11 pm Post subject: |
|
Ah, no copier :/
Yeah, so no luck with those two. Lastly, how about SNEeSe? Does TRAC
get the lightning effect right at least? If not, this is a good example
of why emulation needs to keep improving, heh.
CT sequence could be cool. I'd still wait for that new version just in
case, though I don't think the ENDX changes would affect CT. Eh, you
never know. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 21, 2006 1:56 pm Post subject: |
|
Link of sneese now added. And yes, sneese gets it right. In fact, the sneese and bsnes wavs are indistinguishable to me.
I'll wait to see if .016 changes anything before ct.
Kind of was thinking today about something I saw on the alpha ii guy's site:
"If you see only one chip under the heatsink, then you have the last revision of the APU."
Hmm, could these revisions have had any effects on the quality of the
system's sound? Important to know if we are to determine absolutely
what is reference and what is wrong, since my console could be an
earlier revision.
Last edited by FitzRoy on Tue Mar 21, 2006 2:06 pm; edited 1 time in total |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Mar 21, 2006 2:06 pm Post subject: |
|
FitzRoy wrote: |
No
prob! Yeah, that info about the snes clocks really explains the length
discrepencies. Regarding the zsnes and snes9x samples you requested - I
made those tonight and edited my post with the links. I used a digital
loopback for both recordings. |
No good. You can't get proper audio output with ZSNESW. Use the wav
writer, and then do whatever digital recording you want of that if
needed.
_________________
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: Tue Mar 21, 2006 2:21 pm Post subject: |
|
Nach wrote: |
FitzRoy wrote: |
No
prob! Yeah, that info about the snes clocks really explains the length
discrepencies. Regarding the zsnes and snes9x samples you requested - I
made those tonight and edited my post with the links. I used a digital
loopback for both recordings. |
No good. You can't get proper audio output with ZSNESW. Use the wav
writer, and then do whatever digital recording you want of that if
needed.
|
Not sure I understand. Is this a bug? If it's a bug, then the
comparison stands. I can't be doing special commands to get it right if
we can't play it that way. I can't seem to get any audio out of the dos
version, anyhow. It's enabled, too. :/
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Mar 21, 2006 2:44 pm Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
FitzRoy wrote: |
No
prob! Yeah, that info about the snes clocks really explains the length
discrepencies. Regarding the zsnes and snes9x samples you requested - I
made those tonight and edited my post with the links. I used a digital
loopback for both recordings. |
No good. You can't get proper audio output with ZSNESW. Use the wav
writer, and then do whatever digital recording you want of that if
needed.
|
Not sure I understand. Is this a bug? If it's a bug, then the
comparison stands. I can't be doing special commands to get it right if
we can't play it that way. I can't seem to get any audio out of the dos
version, anyhow. It's enabled, too. :/
|
ZSNESW does not output sound to your sound card properly, I mentioned
this I think in two other threads and this one as well. ZSNES DOS, and
now ZSNES SDL do output correctly.
If you want to compare what ZSNES generates, instead of output which
could be affected by CPU load and a bunch of other things, use the
movie recording option and only output the audio.
_________________
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: Tue Mar 21, 2006 5:09 pm Post subject: |
|
To
be honest I don't really see a diference in regards to the lighting
effect. All I hear is a difference between volume and maybe slight
pitch difference or something but what do I know. Are you sure whatever
method you use to rip the audio is not responsible for those slight
differences?
FitzRoy wrote: |
EDIT:
Just thought I'd mention that data from the real should be objectively
taken with a grain of salt. I've taken several more recordings of each
to make sure the times are right. Turns out, I get differences (to the
ms) from the real source, but bsnes always cuts to the same exact length |
That's interesting...Soooo...the real Snes is actually 'less' accurate
than bsnes!! Seriously though, basically those slight variation
(imperceptible to the naked eye/hear) are due to physical,real world
variation in the timing crystal right?
Byuu wrote: |
With
a PC, the same fluctuations exist, but they don't affect the underlying
output because all of the "SNES chips" are ran off the same CPU clock,
so your output is always identical. I could emulate this fluctuation
easily enough by emulating random "fractions" of opcodes (say, +/-
0.001%), but eh, why bother? I'd rather use the reference "stock"
speeds of 21.477mhz and 24.576mhz instead. If a game can't run with
that, it will very realistically die on the real console as well. |
Well, you probably guess what I'm gonna say but: Most of us "Just like
on the real thing!" fanboys would probably enjoy such an addition.
Now I realise this is not directly emulation related and that it could
be argued that those fluctuations are in fact nothing more than slight
inperfections of the original hardware, but (assuming it would be
trivial to add in bsnes) it would be a neat addition nonetheless. Just
like simulating the quirks of an Ntsc TV I guess.
|
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 21, 2006 5:54 pm Post subject: |
|
Dmog wrote: |
Byuu wrote: |
With
a PC, the same fluctuations exist, but they don't affect the underlying
output because all of the "SNES chips" are ran off the same CPU clock,
so your output is always identical. I could emulate this fluctuation
easily enough by emulating random "fractions" of opcodes (say, +/-
0.001%), but eh, why bother? I'd rather use the reference "stock"
speeds of 21.477mhz and 24.576mhz instead. If a game can't run with
that, it will very realistically die on the real console as well. |
Well, you probably guess what I'm gonna say but: Most of us "Just like
on the real thing!" fanboys would probably enjoy such an addition.
Now I realise this is not directly emulation related and that it could
be argued that those fluctuations are in fact nothing more than slight
inperfections of the original hardware, but (assuming it would be
trivial to add in bsnes) it would be a neat addition nonetheless. Just
like simulating the quirks of an Ntsc TV I guess.
|
- you won't note a difference though
- it makes the emulator slower
- it's additional work
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Mar 21, 2006 6:21 pm Post subject: |
|
creaothceann wrote: |
- you won't note a difference though |
True, but then we've allready talked about how there's more than meet
the eyes when it comes to emulation. In many games, many people
wouldn't notice a difference between b and Z, yet the underlying
emulation is fundamentally different (well you know..more accurate in b)
Quote: |
- it makes the emulator slower |
Possibly.But the question is: by how much? If it's so insignificant
that you couldn't even measure the impact than I guess it doesn't
really count.
Quote: |
- it's additional work |
True again. But I did say "provided it's trivial to add". There's work:
"Five minutes worth of coding" and then there's work: "Hours or even
days worth of coding"
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 21, 2006 6:42 pm Post subject: |
|
Dmog wrote: |
creaothceann wrote: |
- you won't note a difference though |
True, but then we've allready talked about how there's more than meet
the eyes when it comes to emulation. In many games, many people
wouldn't notice a difference between b and Z, yet the underlying
emulation is fundamentally different (well you know..more accurate in b)
|
I meant you won't see a difference because the games will behave exactly the same as on the real console.
bsnes emulates a "perfect" SNES that does not differ from the
specifications. Emulating these slight real-world differences is not
necessary because the games will ignore them anyway. They have to, or
they would not run on all real-world SNES.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Mar 21, 2006 8:23 pm Post subject: |
|
creaothceann wrote: |
Dmog wrote: |
creaothceann wrote: |
- you won't note a difference though |
True, but then we've allready talked about how there's more than meet
the eyes when it comes to emulation. In many games, many people
wouldn't notice a difference between b and Z, yet the underlying
emulation is fundamentally different (well you know..more accurate in b)
|
I meant you won't see a difference because the games will behave exactly the same as on the real console.
bsnes emulates a "perfect" SNES that does not differ from the
specifications. Emulating these slight real-world differences is not
necessary because the games will ignore them anyway. They have to, or
they would not run on all real-world SNES.
|
My point was: On the real Snes ('any' Snes no matter how "perfect") you
can't replicate the same exact results everytime because of
fluctuations in the timing crystals like Byuu said.
On bsnes (and probably every other Snes emu for that matter) if you do
a test like FitzRoy did you WILL achieve the same exact results every
time. That's not totally hardware accurate technically. It's not just
about "Whether the games care or not"
Now,before anyone starts exagerating... I obviously realise it's
impossible to replicate every physical,real world details that could
potentially affect the console (I wouldn't want to anyway). Unless of
course you intend to create a program that virtually replicate the
physical components of the console to the atomic level...and that's
insane by an order of magnitude.
But this particular hardware quirk (slight variations in the timing
crystal) is quite possible to simulate. And it does have a (random)
impact on the game, no matter how insignificant. Like I said, it's
something that probably happened on 'all' Snes in 'any' condition.It's
part of the hardware in a way. We're far from "simulate random
earthquake" or "simulate little brother pounding on the console" here.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 21, 2006 9:23 pm Post subject: |
|
Dmog wrote: |
To
be honest I don't really see a diference in regards to the lighting
effect. All I hear is a difference between volume and maybe slight
pitch difference or something but what do I know. Are you sure whatever
method you use to rip the audio is not responsible for those slight
differences? |
I'm assuming you mean the bsnes/real comparison, because zsnes and
snes9x are really quite off for sfx. And yes, I had to listen many
times with my high end headphones very closely to spot any difference
other than the amplitude. It's hard to put my finger on it, but the
real snes is just a tad "smoother" sounding. It's really, really close.
In fact, I could see some preferring the bsnes/sneese sound as it is.
Unless kmixer did something, the digital input recording should be
clean for the real.
Dmog wrote: |
Well, you probably guess what I'm gonna say but: Most of us "Just like
on the real thing!" fanboys would probably enjoy such an addition.
Now I realise this is not directly emulation related and that it could
be argued that those fluctuations are in fact nothing more than slight
inperfections of the original hardware, but (assuming it would be
trivial to add in bsnes) it would be a neat addition nonetheless. Just
like simulating the quirks of an Ntsc TV I guess. |
I think byuu already gave a good reason not to. In fact, you did a
pretty good job yourself. When I said length discrepencies, we're
talking milliseconds to minutes. Really, really small and humanly
impossible to detect, i.e.:
3m 28.452s file
3m 28.660s file
Edit: omg I'm a math tard. It was late 
Last edited by FitzRoy on Wed Mar 22, 2006 2:43 am; edited 2 times in total
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Mar 21, 2006 9:54 pm Post subject: |
|
FitzRoy wrote: |
Dmog wrote: |
To
be honest I don't really see a diference in regards to the lighting
effect. All I hear is a difference between volume and maybe slight
pitch difference or something but what do I know. Are you sure whatever
method you use to rip the audio is not responsible for those slight
differences? |
I'm assuming you mean the bsnes/real comparison,
|
Yes. Don't have to check Z and 9x to guess they sound way off. 9x in
particular is probably the worst of them all I think.
Quote: |
because
zsnes and snes9x are really quite off for sfx. And yes, I had to listen
many times with my high end headphones very closely to spot any
difference other than the amplitude. It's hard to put my finger on it,
but the real snes is just a tad "smoother" sounding. It's really,
really close. In fact, I could see some preferring the bsnes/sneese
sound as it is. Unless kmixer did something, the digital input
recording should be clean for the real. |
FitzRoy wrote: |
Dmog wrote: |
Well, you probably guess what I'm gonna say but: Most of us "Just like
on the real thing!" fanboys would probably enjoy such an addition.
Now I realise this is not directly emulation related and that it could
be argued that those fluctuations are in fact nothing more than slight
inperfections of the original hardware, but (assuming it would be
trivial to add in bsnes) it would be a neat addition nonetheless. Just
like simulating the quirks of an Ntsc TV I guess. |
I think byuu already gave a good reason not to. In fact, you did a
pretty good job yourself. When I said length discrepencies, we're
talking milliseconds to minutes. Really, really small and humanly
impossible to detect, i.e.:
3m 28s 452ms file
3m 28s 660ms file
|
Yes I understand that. And I understand the games don't care either.
It's just something you could say: "The original ran like that and so does the emulator".
Now that being said can't say I care too much about it (yes,I actually
argue over points I don't really care about, go figure).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 21, 2006 11:22 pm Post subject: |
|
Well,
I could allow adjustment of the CPU<>APU clock speeds with no
slowdown to emulation whatosoever. In fact, it's trivial and I should
have already done it. That said, this will stay a config file option only and will not appear in the emulation interface.
I could add a special flag in there for variance as well, e.g.
cpu.clock_speed = 21477272
cpu.variance = 6000
Then at power on, cpu.clock_speed = cpu.clock_speed + (bool(rand()) ? 1 : -1) * rand(cpu.variance);
This would result in different CPU<>APU ratios upon each power
on. Just enough to give subtle differences like a real SNES. However,
this variance occurs during each clock cycle to an absolutely
infinitesimal degree, and not at system power up. To emulate that would
cause an absolutely brutal performance penalty, so I won't be adding
that unless there's a real demand, or until the day when someone
mentions they only have a 2.0ghz and everyone tells them to put that
shit in a museum ;)
Anyway, the variance would be 0 and clock_speed would be stock speeds
by default, and I would refuse bug reports if these options were
changed. It would also make debugging and fixing CPU<>APU sync
problems a lesson in pain if variance was used. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Mar 21, 2006 11:52 pm Post subject: |
|
byuu wrote: |
Well,
I could allow adjustment of the CPU<>APU clock speeds with no
slowdown to emulation whatosoever. In fact, it's trivial and I should
have already done it. That said, this will stay a config file option only and will not appear in the emulation interface.
I could add a special flag in there for variance as well, e.g.
cpu.clock_speed = 21477272
cpu.variance = 6000
Then at power on, cpu.clock_speed = cpu.clock_speed + (bool(rand()) ? 1 : -1) * rand(cpu.variance);
This would result in different CPU<>APU ratios upon each power
on. Just enough to give subtle differences like a real SNES. However,
this variance occurs during each clock cycle to an absolutely
infinitesimal degree, and not at system power up. To emulate that would
cause an absolutely brutal performance penalty, so I won't be adding
that unless there's a real demand, or until the day when someone
mentions they only have a 2.0ghz and everyone tells them to put that
shit in a museum 
Anyway, the variance would be 0 and clock_speed would be stock speeds
by default, and I would refuse bug reports if these options were
changed. It would also make debugging and fixing CPU<>APU sync
problems a lesson in pain if variance was used. |
Awesome 
Don't worry, I won't pester ya to make the variance occur during each clock cycle like on the real Snes 
And a .cfg option is definitely the best solution, so people that don't
know what this option is for don't even have to know it exist or modify
it, and most people would probably want it off by default anyway I
guess.
Last edited by Dmog on Wed Mar 22, 2006 2:27 am; edited 1 time in total
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Sun Mar 26, 2006 3:12 pm Post subject: |
|
OBC1 added. I know you don't like all those special chips Byuu, but looks great anyway. 
You won't hear anyone complaining abt increasing Bsnes' compatibility list.
Nice job. 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 28, 2006 11:47 am Post subject: |
|
byuu wrote: |
List
view controls are a pain in the ass to use. Try and find the equivalent
of LB_GETCURSEL for list view controls. Oh wait, there is none! Why
would Microsoft go and add a useful window message like that? Of
course, there's ListView_GetSelectedColumn, but not
ListView_GetSelected(Row|Item). Fortunately, I was able to create my
own function using a little hackery. |
Do you just want to get the currently selected item? I think that's
different because in a listview, several items can be selected. You
probably could use the index of the currently focused item.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 28, 2006 1:13 pm Post subject: |
|
That's
what I did. There's no API to do that so you have to reiterate through
all items to find the currently focused item. I also have
LVS_SINGLESELALWAYS set, so it shouldn't allow multiple selections at a
time.
Anyway, I've written get+set. I actually
just started last night on a new object-oriented wrapper for the win32
API because the difference between the generic windows control APIs and
the common control APIs is just ridiculous and I can't keep up with all
these new messages and helper functions. Going to try and completely
hide the win32 API 100% with it. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 28, 2006 2:00 pm Post subject: |
|
byuu wrote: |
That's
what I did. There's no API to do that so you have to reiterate through
all items to find the currently focused item. I also have
LVS_SINGLESELALWAYS set, so it shouldn't allow multiple selections at a
time. |
Ah, didn't know that... Delphi just provides the property 'ItemFocused' and "hides the win32 API 100%".
EDIT: Just looked at the source... they also iterate through the list.
_________________
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: Tue Mar 28, 2006 5:31 pm Post subject: |
|
Now also a cheat code editor? Oh man, I can't wait for v0.16 
Byuu is the Snes-God! 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Mar 31, 2006 2:13 am Post subject: |
|
'm
aware of the rescaling bug, it will be corrected probably in the next
WIP. DirectX is trying to stretch the 600x446 surface to fit onto the
screen so I will have to rewrite the code to not use hw filtering and
it should be good after that. We had the same problem with scanline a
long time ago. The entire code base is converted to Direct3D so that
should also clear up a lot of problems. As for the framecounter it's
working properly. I will take a look to see what was changed, perhaps a
bug was created. We are making a lot of changes to the video code
lately after we overhauled the sound, input, video was the next thing
on the list. I didn't really had a lot of time to test the NTSC filter
on Windows as Linux is my main development environment but I will see
to it that he filter is working properly later on.
I was wondering since the NTSC filter doesn't output a buffer that is
compatible with most 4:3 screens, I guess using a letterbox effect here
would be best. |
|
KingHanco Lurker

Joined: 26 Feb 2006
Posts: 152
|
Posted: Fri Mar 31, 2006 2:40 am Post subject: |
|
pagefault wrote: |
I
was wondering since the NTSC filter doesn't output a buffer that is
compatible with most 4:3 screens, I guess using a letterbox effect here
would be best. |
How about an option to change the 4:3 to anything. For exsample here,
my screen is a Sony TFT LCD 5:4 not a regular 4:3 screen. Many people
doesn't have a regular 4:3 screen when they use a TFT LCD or what ever
they use beside of regular 4:3 screen. I know Mame got this option in
the Mame.ini and I set it to 5:4 for the screen correction on full
screen. But if it doesn't matter then don't bother messing with it.
_________________
"Zsnes is the best one there is."
|
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Fri Mar 31, 2006 3:39 am Post subject: |
|
We don't need to support people too stupid to request a proper 4:3 or 16:9 screen.
Really, we don't.
5:4 and 3:2 and the rest of the nonstandard ones were made to make money off fucking morons. |
|
KingHanco Lurker

Joined: 26 Feb 2006
Posts: 152
|
Posted: Fri Mar 31, 2006 4:04 am Post subject: |
|
Aerdan wrote: |
We don't need to support people too stupid to request a proper 4:3 or 16:9 screen.
Really, we don't.
5:4 and 3:2 and the rest of the nonstandard ones were made to make money off fucking morons. |
So you saying that pagefault need to remove the 4:3 support then? Not
going to happen. Your not using your head wise.
_________________
"Zsnes is the best one there is."
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 31, 2006 4:15 am Post subject: |
|
Thanks pagefault.
What I do is scale the image horizontally only. This leaves the scanlines intact but lets me get perfect scanlines.
For example, 512x448 -> 448 * 4 / 3 = abs(597.333) = 597 x 448.
Perfect. I do this for all filters, and use bilinear resampling for it.
And capture cards seem to output at 582x448, so I need to look into this. I'll let you know when I do.
As far as fixing the aspect ratio, the thing to keep in mind here is
not the aspect of the monitor being used, but the pixel aspect on the
real SNES vs the monitor pixel size.
If your monitor is 4:3 or if its 16:9, and you still have square
pixels, then you would use the same output size for the actual video
content for correct aspect ratio. The only thing that changes is the
size of the screen in fullscreen mode (eg more blackspace is added for
16:9).
I'll try and get code for this correction up as well if I ever get around to it :/ |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sat Apr 01, 2006 12:22 am Post subject: |
|
Aerdan wrote: |
We don't need to support people too stupid to request a proper 4:3 or 16:9 screen.
Really, we don't.
5:4 and 3:2 and the rest of the nonstandard ones were made to make money off fucking morons. |
Not every one uses a computer to play games and watch videos. A 5:4
monitor is better for desktop useage. Like coding, word processing,
viewing webpages or whatever. It's slightly wider and taller then a 4:3
one, plus the cost is cheaper then getting a 16:9 LCD monitor. They'd
only look silly if they brought one just for multimedia use.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Apr 03, 2006 1:36 pm Post subject: |
|
Byuu,
I recently bought an XBox 360 Controller. I noticed that bsnes does not
detect all button presses from the controller. For example, it doesn't
detect the d-pad at all. Furthermore, it does detect left, right, and down on the left analog stick, but not up.
So I'm wondering if there's any way you can look into this issue for
the next release. I can possibly provide you with more details in the
near future.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 03, 2006 8:35 pm Post subject: |
|
I
think that's one of the things I've fixed since v0.015. The RC1 release
would have that fix if you were able to run that build... |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
KingHanco Lurker

Joined: 26 Feb 2006
Posts: 152
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Apr 05, 2006 1:11 pm Post subject: |
|
too bad that build is for SSE2 only  |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Apr 05, 2006 4:01 pm Post subject: |
|
byuu wrote: |
I
think that's one of the things I've fixed since v0.015. The RC1 release
would have that fix if you were able to run that build... |
Yes, its fixed.
I'm also absolutely stunned! I haven't experienced Scale2x on an SNES game before, and I love it!
I also like bilinear filtering at those higher internal resolutions
(resolutions that the video card doesn't have to scale as much, and
thus less bilinear filtering). I would use that as a filter/option by
itself.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 14, 2006 8:22 pm Post subject: |
|
Fantastic! I finally figured out how to truly play videos on SNES hardware!
I'm so stupid for not realizing this immediately... FORCE BLANK. Damn.
There's no reason to limit VRAM transfer times to just standard vblank
if you're not rendering to the top and bottom of the screen.
Techno-babble:
Code: |
262-225=37*1364=50468/8=6308
150x128=19200
160x120=19200
262-128=134*1364=182776/8=22847
262-120=142*1364=193688/8=24211
19.2kb*30=576kb/s /2 = 288kb/s
8-16 seconds / 4mb ROM
256*224=1.142 aspect |

The white border is additional room that my example image couldn't fill.
I could run an image of this size and quality (150x128, or 160x120) at
30 frames per second on stock SNES hardware.
And I have every other frame entirely free for things like video
decompression, audio transfer (potentially ToP intro quality audio,
though something like Wild Arms intro music would be fine too I guess),
etc.
Now, problems? You betcha. 150x128 or 160x120 at 8bpp RGB332 would be
576kb/s. Youch. I'd fill a 4mb ROM in <8 seconds. Compression could
easily halve that, as could lowering the framerate. Or, my next idea, a
bit more radical...
How does everyone feel about "emulating" an MPEG decompression "chip"?
It'd basically act just like the S-DD1. You ask it to decode a frame,
wait a bit, and then DMA transfer right off the cart. Maybe use MPEG2
for higher compression rates, but not MPEG4, as that isn't standardized
enough yet...
The ROM size is still a problem. So I'm thinking, combine the PCM
"chip", the MPEG "chip", and a large ROM chip (128-256 megabytes is
feasible) on the cart, call it something like the "S-AV chip". The
emulation code would be 100% ANSI-C++ and cross-platform portable, so
other emulators could use it if they wished.
It would allow redbook audio, and MPEG1/2 quarter-screen video at
30fps. It could allow for some absolutely amazing ROM hacks if people
were interested enough in hacking games. And it would be designed with
wait delays in mind, and absolutely nothing would be "impossible" to do
on a real SNES cart if a talented FPGA programmer were to come along ;)
I'd require something like the .smc file and .rom file (and hopefully a
.ups patch file so we aren't distributing hacked ROMs), the .rom being
the contents of the special chip's ROM. Being any size up to 256/512mb.
It'd just be completely optional,
and I'd use it myself for Der Langrisser to make the SNES port rival
the quality of the PC-FX port. I really think this is the winning
strategy for my SNES-enhancement ideas. Opinions?
|
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Fri Apr 14, 2006 9:42 pm Post subject: |
|
I think you have a great money-making idea, Byuu.
If it was 8 years ago and the Super Nintendo was still popular. Well,
you could get a custom SNES flash cart with the chip (that has the
extra flash memory like you said)... that decompresses the video on the
fly? It'd probably cost quite a bit... but, it'd still be cool. Too bad
I don't have an electrical degree and a lot of time/money or I'd do it. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Apr 14, 2006 9:45 pm Post subject: |
|
It's a little over my head, but it definitely looks impressive.
Is this all ROM-side stuff we're talking about? Or is any part
dependent on the emulator? Give that you said this could theoretically
be run on a stock SNES console, I assume it's all ROM-side.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 14, 2006 10:03 pm Post subject: |
|
Quote: |
I think you have a great money-making idea, Byuu. If it was 8 years ago and the Super Nintendo was still popular. |
Eight years ago a 512mb ROM chip would be psychotically expensive. If I
wanted to make money, I'd make my own version of the Windows XP Media
Center applications that was highly and easily themeable and extensible
and charge $10-$20 for it. Anyone wanting to use their existing WinXP
disks could use that instead of buying another copy of XP, or hacking the MCE apps to work on vanilla XP.
Quote: |
Is this all ROM-side stuff we're talking about? |
The audio would require a special cart+chip, so that the audio output
lines could be written to. These lines exist on the SNES, but only the
BS-X makes use of them for its streaming satellite audio. The video can
be done entirely in the ROM, but there isn't enough space for even a
single full-length video. You could add on 512mb easily enough by
putting the ROM chip on the PCB, and throwing a special memory mapper
on the cart, similar to the S-DD1.
However, I want to add video and audio data compression so that the
"extended" ROM space is kept small. MPEG decoder cards were very tiny
even in the Sega Saturn days. Nowadays, all of this stuff could easily
fit on an SNES PCB. The cart would probably run for $100 in parts at
mass production, but of course, no real carts will ever exist. The chip
will only exist in emulated form in certain emulators.
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Apr 14, 2006 10:12 pm Post subject: |
|
I don't understand the techno-babble but your credentials with Bsnes already speak for themselves.
Do what you think is best. Go for it Byuu!
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 15, 2006 3:56 am Post subject: |
|
Woo, this place was all crickets for a while there 
Although I don't understand the practical applications of this, I think
it's pretty impressive. Let's say someone wanted to modify the psx
chrono trigger rom to include the videos as well, and make it playable
in bsnes. Would this then make that possible? It's too bad Dracula X
was such a cut-up job compared to the PC-Engine version, or people may
also have something to work with there. In the end, it seems like a lot
of work to pull these things off in light of the alternative which is
to simply play the better version on its respective emulator. Though
for Der Langrisser, I don't know shit about PC-FX emulators or iso
rarity. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 15, 2006 5:18 am Post subject: |
|
Quote: |
Let's
say someone wanted to modify the psx chrono trigger rom to include the
videos as well, and make it playable in bsnes. Would this then make
that possible? |
One would modify the SNES ROM. No reason to mess with the PSX one. But
yes, you could add in the MPEG movies (maybe a little smaller though)
and the accompanying audio with this.
There's only one PC-FX emulator and it's by the Magic Engine team. Not
sure if it's been released yet, but I'm sure they'll want money for it,
so I could care less. There's also the fact that you'd have to hack the
game to English. Hence, it's easier to just extend DL SNES instead.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Apr 16, 2006 2:33 am Post subject: |
|
byuu wrote: |
It'd
just be completely optional, and I'd use it myself for Der Langrisser
to make the SNES port rival the quality of the PC-FX port. I really
think this is the winning strategy for my SNES-enhancement ideas.
Opinions? |
If I understand, this could be actually achived on real hardware using
few, relatively simple physical modifications, right?
Even so, I think it's a bad idea (just my impressions).
I'm not too enthusiast on the idea on "improving" a console/game media
via emulation. It kinda defeats the purpose of emulating a system
which, from a technical standpoint,is completely outdated and
outclassed by today standards (again, speaking from a pure technical
specifications pov. Compare the Snes to the PS3 and you get the idea)
. Why not just create/translate a game on the system which is allready
capable of achiving what you want to go for?
Yeah some probably say I'm going overboard but I fear that, in 100
years from now, every Snes games will have Cd audio quality and have
PS4-quality graphics [/slight exageration] but you get the idea.(edit:
and yes, I understand the idea proposed would only be optional)
Wasn't it you Byuu that said that you could play PS2 games on the Snes?
All one would need (in theory) is to insert all the PS2 hardware in one
giant Snes cartridge.
Anyway, that being said,if Byuu wants to go with it, then by all means, ignore my ramblings. 
Last edited by Dmog on Sun Apr 16, 2006 2:57 am; edited 2 times in total
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun Apr 16, 2006 2:49 am Post subject: |
|
Well,
I imagine that sometime in the indefinite future, when SNES emulation
is perfect, and, should the console manufacturers be so inclined, we
are allowed to execute homebrew code on said consoles, then we can just
burn a Blu-Ray Disc with an SNES->PS4 emulator and all our roms.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Apr 16, 2006 2:53 am Post subject: |
|
Jipcy wrote: |
Well,
I imagine that sometime in the indefinite future, when SNES emulation
is perfect, and, should the console manufacturers be so inclined, we
are allowed to execute homebrew code on said consoles, then we can just
burn a Blu-Ray Disc with an SNES->PS4 emulator and all our roms. |
I'm willing to bet said emu will be called "PS4SNES" (PS4/for-Snes) get it? )
Edit: Just to make things clear, I really did meant: A PS4 Emulator
that would run on (modified) Snes hardware, and not vice-versa.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 16, 2006 5:39 am Post subject: |
|
Dmog wrote: |
If I understand, this could be actually achived on real hardware using few, relatively simple physical modifications, right? |
Yes. If one were to use standard SPC music, it could be done with no
modifications at all, other than a larger ROM and an MMC. The S-DD1 MMC
would probably even be sufficient. The only problem with the video is
space, and the two problems with audio are space and lack of any carts
that utilize the audio out pins that truly exist on the system.
In fact, Nach says hardware exists that can play CD audio on the SNES,
but I've never heard of it nor seen it. The BS-X plays CD-quality audio
streamed over satellite, so this is obviously all doable.
Quote: |
I'm
not too enthusiast on the idea on "improving" a console/game media via
emulation. It kinda defeats the purpose of emulating a system which,
from a technical standpoint,is completely outdated and outclassed by
today standards (again, speaking from a pure technical specifications
pov. Compare the Snes to the PS3 and you get the idea) . Why not
just create/translate a game on the system which is allready capable of
achiving what you want to go for? |
I understand your point and this is why I wanted opinions on the matter, thank you.
You see, I realize I could port Der Langrisser to the PC, and blow all
of the other ports the hell out of the water. The problem is now I have
to worry about it working on 50,000 different hardware combinations,
and it only runs on Win98-XP. Probably won't even work on Vista. Nor
Mac, nor linux, nor PS4SNES. And instead of hacking a game to English,
I'd have to program the entire thing. The game engine, the AI, the
maps, everything. Months, nay, years of work. Whereas, with a tiny
modification to the SNES hardware, and very little programming work on
my part, I can easily match Der Langrisser FX, and enjoy platform
independence.
It's really the same thing as those Zelda 64 texture expansion packs
(only possible on hardware). It hurts nothing, and in theory could turn
out some really cool stuff.
Quote: |
Yeah
some probably say I'm going overboard but I fear that, in 100 years
from now, every Snes games will have Cd audio quality and have
PS4-quality graphics ... Wasn't it you Byuu that said that you could
play PS2 games on the Snes? All one would need (in theory) is to insert
all the PS2 hardware in one giant Snes cartridge. |
Yes. But there's one key thing I also mentioned. The video hardware in
the SNES cannot be enhanced. The best you could do would be to have all
of the PS2 hardware running inside a cart (and it would need an
external power supply), and have it transfer the PS2-generated video at
150x128x256 colors@60hz non-interlace with audio at 32khz 16-bit
stereo. You'd also probably need external input (eg on the cart) for
the controller, for things like the analog sticks and rumble pack
support. And at this point why not just stick component + SPDIF out on
the cart as well? Because now you're not even using the cartridge
connector to the SNES, so there's no point. It's just a waste of power
for the SNES to sit there idly doing nothing. The point was just that
you can put whatever the hell you want on an SNES cart. So long as it
has enough power, it'd run fine. There's just very little the SNES can
do with the output. And my ideas on this page are within those limits
of the SNES. I'm not blatantly making shit up like adding DVD
720x480x24bpp progressive video playback with 5.1 dolby digital
surround sound or anything.
But anyway, if no one wants this then I won't add it. There's no point if no one will use it.
|
|
SquareHead Seen it all

Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box
|
Posted: Sun Apr 16, 2006 5:58 am Post subject: |
|
byuu wrote: |
But anyway, if no one wants this then I won't add it. There's no point if no one will use it. |
It all depends on what you want to do, not what everyone else wants isnt it?
_________________
My boring Site
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun Apr 16, 2006 6:05 am Post subject: |
|
byuu wrote: |
But anyway, if no one wants this then I won't add it. There's no point if no one will use it. |
Given that you say it would take relatively little work, I say go
ahead. And show us a proof-of-concept or something. End-users
(non-programmers) seem to have relatively little use for it. Romhackers
and other types can do the rom creation. End-users, however, would
certainly enjoy some very cool "ports" and such, and new PD roms or
something.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 16, 2006 11:30 am Post subject: |
|
Well,
obviously Der Langrisser is one of your favorite games. I personally
understand what you're trying to do after listening to the difference
in some DL videos on a PC-FX site. In fact, I may even relate a little
bit. I love the Ultima series of games and one day I hope to track down
the "FM Towns" version of Ultima VI which includes speech fx. Nuvie, a
U6 game engine for windows, now supports this fx. It's friggin cool and
I want it.
But the problem you face with this
feature is, who else has the drive to hack this stuff into a rom? Only
time will tell if other people use the feature for other games. Der
Langrisser is a strange circumstance and there may not be many
comparable ones to warrant this as a popular feature. Pop it in though,
see what happens.
P.S. Have you given any further thought on putting a forum on your
site? New feature announcements like this really deserve their own
thread if you're looking for feedback. It's also more organized than
the hodge podge we've got going on in here. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Apr 16, 2006 2:39 pm Post subject: |
|
byuu wrote: |
And
my ideas on this page are within those limits of the SNES. I'm not
blatantly making shit up like adding DVD 720x480x24bpp progressive
video playback with 5.1 dolby digital surround sound or anything. |
Never thought you were. Your explanations above help me understand how this could be achieved on real hardware.
. Once,someone suggested emulating the Snes cd-rom add-on that never was released...Now that was bullshit. What you suggested though is perfectly achievable in real life.
Quote: |
But anyway, if no one wants this then I won't add it. There's no point if no one will use it. |
By all mean if you want to do it then go for it. I'm pretty sure plenty of people would like it actually
I agree with Jipcy:
Quote: |
Given that you say it would take relatively little work, I say go ahead. And show us a proof-of-concept or something |
Agree. If someone first shows it running on real hardware, then it's perfecty legitimate in my book.
Last edited by Dmog on Sun Apr 16, 2006 2:56 pm; edited 1 time in total
|
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Apr 17, 2006 2:18 am Post subject: |
|
Yes,
it is easy to understand that extending the SNES like this is a lot
easier than learning how to translate one of those other ports of the
game which has all the fancy music and videos built-in. It's not like
you won't provide Portable ANSI C (TM) source code so all emulators can
support it, and eventually the encoding so anyone can buy their own
FPGA to turn into this coprocessor chip, the necessary extra logic
chips in the event that you can't cram that alongside the decoder in
the FPGA, and a handy dandy printed circuit board. Or, on the cheap, a
template pattern which can be printed onto a transparency for the
do-it-yourself-ers who have their own PCB kits. For extra manlitude,
you can even try cutting the board out in the dark before you etch it. |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Mon Apr 17, 2006 3:15 am Post subject: |
|
kode54 wrote: |
Yes,
it is easy to understand that extending the SNES like this is a lot
easier than learning how to translate one of those other ports of the
game which has all the fancy music and videos built-in. It's not like
you won't provide Portable ANSI C (TM) source code so all emulators can
support it, and eventually the encoding so anyone can buy their own
FPGA to turn into this coprocessor chip, the necessary extra logic
chips in the event that you can't cram that alongside the decoder in
the FPGA, and a handy dandy printed circuit board. Or, on the cheap, a
template pattern which can be printed onto a transparency for the
do-it-yourself-ers who have their own PCB kits. For extra manlitude,
you can even try cutting the board out in the dark before you etch it. |
Seemed feasible, until I got to that last sentence...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 17, 2006 3:24 am Post subject: |
|
I'm in the process of working on the forum thing.
I can't make this idea run on real hardware. I know next-to-nothing about hardware design :(
With the help of the SA-1, it might be possible to write a decent,
low-quality video decoder to get some 20-30+ second videos on a single
cart. Using just the 2.68mhz main processor would be incredibly
difficult. LZSS+keyframes would probably be my best bet. I do have
1-1/2 frames (~516,000 master cycles) for decoding, though.
I also don't really see a problem with just using a fake MMC to address
512mb of space either, though. That'd give me ~15 minutes of lossless
video, way more than enough for most games. And that would be an
absolutely trivial task to design.
And it really depends on the video, too. Something like Lunar: TSS's
slideshow videos could probably easily fit in much less space. In fact,
that whole game fits in 7mb of space, sans redbook audio.
And kode, I can't understand if you're being supportive of the idea or sarcastic >_< |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Mon Apr 17, 2006 4:07 am Post subject: |
|
oh.
I forgot to mention. Since the snes has 8-bit display mode, how are you
going to handle more than 256 colors in the video?
Dithering is doable, but kind of fugly (I've seen it first-hand. I've
had to get video clips to play on a 256-color Siemens WinCE 3.0
touchpanel).
I just had another thought. You could, for starters, not even need a
decoder chip. Just put the raw footage on a CF card, and use its simple
ATA mode to read out the data. |
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Mon Apr 17, 2006 4:21 am Post subject: |
|
Byuu: Do you think that you could write a program that converts MPEG files to SNES roms? In the way that Avi2GBA does. |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Mon Apr 17, 2006 5:19 am Post subject: |
|
this
would be interesting. square games come to my mind as games that will
get hacked. the FF's with their cutscenes, CT with its cutscenes. but
the 256 color question is a good one, i think.
_________________
 |
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Mon Apr 17, 2006 5:28 am Post subject: |
|
Er, what?
The SNES supports 32767 colours max. Whoever told you there was a 256-colour limit, whicker, is a dumbass. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 17, 2006 6:01 am Post subject: |
|
32,768.
And you can only hold 256 colors in the palette at once. You can get
more colors onscreen by changing the palette mid-frame, or by using
color add/sub effects.
I suppose it's technically possible
to pull off 150x128@15bpp video. But wow, that would require some true
evil, as well as mid-scanline palette changes. You would even need to
be writing to the palette while the scanline in question was rendering.
I could probably pull it off with some unbelievable timing tricks.
Unfortunately, no SNES emulator even supports dot-by-dot PPU rendering,
so it wouldn't work through emulation, nor on actual hardware.
I figured 8bpp would be fine for cartoon animation sequences :/
The only other option is to just ignore the SNES and play a real video
inside the window at full 256x224@24bpp. It would make rom hacks easier
as you don't have to worry about the video playback nuking your VRAM,
having to change video modes, and all that jazz. But... that's just not
as cool :( |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Mon Apr 17, 2006 6:39 am Post subject: |
|
i
was referring to the pallette thing. but the switching is interesting.
i think that this would make for some very interesting hacks. gundam
games would also benefit, i imagine. or any game that had some sort of
cartoon going for it.
_________________
 |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 17, 2006 10:47 am Post subject: |
|
EDIT:
Errr, I was just about to entertain the thought of having bsnes play
back spc files until I found out that the Der Langrisser spc set from
zophar is a bad rip. Thought it was the player's fault. Good thing I'm
a google expert, though. Carry on. |
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Mon Apr 17, 2006 12:48 pm Post subject: |
|
FitzRoy wrote: |
EDIT:
Errr, I was just about to entertain the thought of having bsnes play
back spc files until I found out that the Der Langrisser spc set from
zophar is a bad rip. Thought it was the player's fault. Good thing I'm
a google expert, though. Carry on. |
SNES Music owns you, bitch.
And I've yet to come across a bad rip there.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 17, 2006 6:51 pm Post subject: |
|
Alright, thanks for the feedback with the S-AV chip ideas.
Next up, one change "for the worse" in the new version (no, not out yet) I wanted to go over: fullscreen mode.
The current problems with fullscreen mode: page flipping and the
Windows GDI are incompatible. This means eg double and triple buffering
cannot be enabled with the menu. Vsync is not an option, bsnes isn't
fast enough even on an FX-57 to run with vsync and experience zero
tearing. Even ZSNES tears for me with only vsync on. To switch from
triple buffering to standard mode is semi-doable with D3D, but requires
me to kill DDraw and reinitialize it, thusly you get lots of monitor
resolution switching when entering and exiting the menu. There's also
the problem of the UI inside fullscreen mode. Since the main emulator
window must be always on top for fullscreen mode, it conflicts with the
UI. You cannot keep the UI windows always on top of the emulator
window, and if page flipping is on, they flicker like mad. Last problem
is toggling the menu bar in fullscreen mode crushes the image slightly,
ruining the aspect ratio correction.
I've basically decided that for the time being,
it's easier to just disable the UI all together in fullscreen mode and
switch back to windowed mode for this. I've added default profile
selections for windowed and fullscreen mode, so you can hit F11 to
switch between the two, or esc to exit fullscreen mode, and the esc key
toggles the menu in windowed mode.
I'm planning on
adding an overlay mode (see Winamp AVS for an example of this) and/or a
"quick" fullscreen mode, so you can just double click the window to
quickly swap back and forth with no resolution change necessary. I
realize it'll be a little inconvenient, especially for switching games.
Is this going to be a show-stopper for anyone? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Mon Apr 17, 2006 7:41 pm Post subject: |
|
byuu wrote: |
I've basically decided that for the time being,
it's easier to just disable the UI all together in fullscreen mode and
switch back to windowed mode for this. I've added default profile
selections for windowed and fullscreen mode, so you can hit F11 to
switch between the two, or esc to exit fullscreen mode, and the esc key
toggles the menu in windowed mode. |
Not a showstopper really. Although is there a chance that within the
profile menu, the user could have options to a) choose whether to start
the emulator in windowed mode or full-screen mode, and b) if the user
chooses to start in windowed mode, a second option that switches to
full screen mode when a game is loaded?
That seems to me at least to be a logical workaround, with the added
bonus of giving the user added choice. Keep up the good work!
|
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Mon Apr 17, 2006 7:57 pm Post subject: |
|
The dongle was an emmitter, correct? Or was it a receiver? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 17, 2006 8:18 pm Post subject: |
|
Not
a problem for me, although I've gotten used to having that "line
refresh" since triple buffering never worked right for me. If I were to
guess, it probably has something to do with the fact that I have to use
the lowest latency setting on my soundcard to get the emu's sound
static free. We never did figure out why that was on your
implimentation as opposed to kode54's. Maybe I'll ask him to look at
your source. I should probably offer him $25 if he fixes it since it
appears to be a rare affliction. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 17, 2006 9:18 pm Post subject: |
|
Nach>
The pages you link to describe Voicer (-kun... ugh... so dirty) as a
remote control adapter. I can't exactly picture how this would work,
but it almost definitely is not playing CD audio directly through the
SNES. Perhaps it intercepts your commands to your actual CD receiver to
know when to skip to a new lesson in-game, maybe? That, or there's a
special CD player that communicates with this device, which then
communicates with the game itself. Very clever design to eliminate the
need for any kind of special SNES hardware (eg special chip), that
Nintendo would no doubt charge a fortune for.
A
true CD player would either hook into the SNES and run carts via
"passthru", or it would connect to the extension port, and listen on
the 8-bit address bus (A or B, I can never remember which is which) --
$2100-$21ff. Either would require either special 32khz CDs, or a
resampling mechanism to downgrade the 44khz redbook audio.
123> It was both, according to one of those websites. Funny, I wasn't aware the SNES controller ports could receive
more than one bit of data at a time. Shows how much I know. So perhaps
the force feedback controller is possible after all. And this would be
by far and large, the easiest thing of all to make for real :D
FitzRoy> I know kode used waveout instead of directsound. However, I
do not know why my audio is choppy with triple buffering enabled. It is
my understanding that triple buffering does not in any way at all lock
the system while calling ->Flip(), but it has to be doing this
anyway. It's the only explanation. Essentially, it should just be
flipping, and eventually every 600 frames, skipping a frame because two
Flips() were called. However, more likely it's probably waiting for
vblank each time it does a page flip, so every 600 frames it lags out
the audio buffer causing skipping to occur. So then, if anyone knows
how to make DDraw/D3D ->Flip() not lock the system when called, I
can fix the choppy audio. And I'd be very grateful, as this would give
me perfectly fluid audio and video, and along with NTSC mode sans merge
fields, would look absolutely fantastic. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Mon Apr 17, 2006 11:05 pm Post subject: |
|
Bsnes does have a screen tear that seems to appear once every 10 secs going from bottom to top when there's scrolling activity.
At least this is so on my PC.
Anyway, I'm not complaining since Bsnes aims for accuracy like Fusion.
Keep up the good work, Byuu. 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
Last edited by Sith on Mon Apr 17, 2006 11:07 pm; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 17, 2006 11:07 pm Post subject: |
|
byuu wrote: |
FitzRoy> I know kode used waveout instead of directsound. However, I
do not know why my audio is choppy with triple buffering enabled. |
Ah, thank you. Well, the two issues could be related I suppose. Is it
out of the question to impliment a WaveOut solution as well, with an
option to use WaveOut or Directsound a la Foobar2k? It could clear up
one or both issues for certain people (if it is in fact my card's
drivers which are inadequate for directsound).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 17, 2006 11:11 pm Post subject: |
|
Sith-Smasher>
The tear every ten seconds is because the SNES runs at 60.09fps, and
your monitor runs at 60fps. So the screen is being redrawn during
display and it overlaps once every ten seconds. The tearing is usually
less obvious when timing isn't as precise as in bsnes.
FitzRoy> It's more to do with my video rendering than it is DSound
vs WaveOut. kode had some interesting tricks to polling the scanline
position for vblanking. It works ok, but still desyncs the video due to
the audio absolutely requiring a perfect rate of 32khz to prevent
choppy audio. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 19, 2006 1:50 am Post subject: |
|
K, well if he was doing something less accurate, then I guess I'll stop clamoring for it.
In other news, I've added a few games to the buglist. I've discovered
something odd happening at the beginnings of the Super Star Wars games.
They all use similar introductions. The demos of gameplay just end as
they start, and any buttons pressed to start the game are ignored. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 19, 2006 2:05 am Post subject: |
|
There's
something seriously wrong with my input system, or something. Lots and
lots of games do this, and I have no idea why. The input system is
implemented exactly as all technical docs explain it, so I must be
overlooking something simple.
I'm guessing the games are thinking the keys are permanently pressed down or something.
:: flashes the DMV signal into the sky ::  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 19, 2006 5:16 am Post subject: |
|
byuu wrote: |
:: flashes the DMV signal into the sky ::  |
Bahahaha
Well said. I take it you haven't heard from him since he revealed that
he knew about certain inaccuracies. Hopefully he's still in the shadows
working his magic.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 19, 2006 6:35 am Post subject: |
|
Yay! Fixed two myself!
Code: |
//JOYSER0
uint8 bCPU::mmio_r4016() {
uint8 r;
r = regs.mdr & 0xfc;
if(status.joypad1_strobe_value == 1) {
r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_B);
} else {
switch(status.joypad1_read_pos) {
case 0: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_B); break;
case 1: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_Y); break;
case 2: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_SELECT); break;
case 3: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_START); break;
case 4: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_UP); break;
case 5: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_DOWN); break;
case 6: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_LEFT); break;
case 7: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_RIGHT); break;
case 8: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_A); break;
case 9: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_X); break;
case 10: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_L); break;
case 11: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_R); break;
case 12: break;
case 13: break;
case 14: break;
case 15: break; //bits 12-15 return 0
case 16: r |= 1; break; //joypad connected bit
default: r |= 1; break; //after 16th read, all subsequent reads return 1
}
if(++status.joypad1_read_pos > 17)status.joypad1_read_pos = 17;
}
return r;
} |
See case 12-15? Those weren't there before, so it was hitting default:
and returning 1 instead of 0. The games were reading $4016/$4017
sixteen times, and testing if any buttons at all were pressed. If any
were pressed, it took it as a key being held down and skipped the
intro. Nevermind the fact that there aren't any buttons mapped to bits
12-15... still, my mistake, and corrected.
This should fix all of the games that skip over the intros now.
Super Double Dragon:
Code: |
//JOYSER0
void bCPU::mmio_w4016(uint8 value) {
status.joypad1_strobe_value = !!(value & 1);
if(status.joypad1_strobe_value == 1) {
snes->poll_input(SNES::DEV_JOYPAD1);
status.joypad1_read_pos = 0;
}
} |
Before, I was testing if(value == 1). However, Super Double Dragon was
writing 0x07 to $4016, so no latch was occurring.
Both of these bugs are fixed for both $4016 and $4017. This should hopefully eliminate all joypad input bugs.
Anyone interested in beta testing v0.015 rc2 for me? Don't want to
release it publically, as v0.016 should be out soon enough.
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Wed Apr 19, 2006 7:25 am Post subject: |
|
Code: |
//JOYSER0
uint8 bCPU::mmio_r4016() {
uint8 r;
r = regs.mdr & 0xfc;
if(status.joypad1_strobe_value == 1) {
r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_B);
} else {
switch(status.joypad1_read_pos) {
case 0: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_B); break;
case 1: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_Y); break;
case 2: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_SELECT); break;
case 3: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_START); break;
case 4: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_UP); break;
case 5: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_DOWN); break;
case 6: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_LEFT); break;
case 7: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_RIGHT); break;
case 8: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_A); break;
case 9: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_X); break;
case 10: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_L); break;
case 11: r |= (uint8)snes->get_input_status(SNES::DEV_JOYPAD1, SNES::JOYPAD_R); break;
case 15: status.joypad1_strobe_value = 0; break;
}
status.joypad1_read_pos++;
}
return r;
} |
I not sure whether this would work but it is more technically correct.
The joypad continually returns the connection status unless the device
has been strobed in which case the device will output a set number of
data bits. The device will then continue outputing the connection
status. Reallistically, there is no 16th or 17th bit (this information
is technically incorrect).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 19, 2006 7:54 am Post subject: |
|
Quote: |
I not sure whether this would work but it is more technically correct.
The joypad continually returns the connection status unless the device
has been strobed in which case the device will output a set number of
data bits. The device will then continue outputing the connection
status. Reallistically, there is no 16th or 17th bit (this information
is technically incorrect). |
Code: |
//JOYSER0
//7-2 = MDR
//1-0 = Joypad serial data
/* The joypad contains a small bit shifter that has 16 bits.
* Reading from 4016 reads one bit from this buffer, then moves
* the buffer left one, and adds a '1' to the rightmost bit.
* Writing a one to $4016 will fill the buffer with the current
* joypad button states, and lock the bit shifter at position
* zero. All reads will be the first buffer state, or 'B'.
* A zero must be written back to $4016 to unlock the buffer,
* so that reads will increment the bit shifting position.
*/ |
snestech.txt
Code: |
----------------------------------------------------------------------------
SNES joypad
----------------------------------------------------------------------------
The SNES joypad uses two 4021 ICs, which are 8-stage static shift registers.
They are cascaded together to form a 16-bit shift register that stores the
state of the directional pad and buttons, allowing the SNES to read out
the state of the joypad serially.
The button states will be loaded into the shift register when bit 0 of
$4016 is set to 1 and then 0. This happens to both control pads as they
share a common pin. Each time $4016 or $4017 is read, the shift register
for the 1P or 2P pad advances by one, outputting a bit which can be read
in bit 0 of $4016 or $4017 respectively.
The tail end of the shift register is filled with a one on each shift. After
the sixteenth time $4016 or $4017 has been read, all consecutive reads will
return one due to the shift register being completely filled with ones.
This will go on forever until the shift register is loaded again by writing
1 then 0 to $4016.
If at any time $4016 is left at 1, reading either joypad will always return
the state of the first input, which is the 'B' button. This won't stop until
$4016 is set to zero again.
Here is the order of button states read out through $4016 or $4017:
Read 1 - Button B Read 9 - Button A
Read 2 - Button Y Read 10 - Button X
Read 3 - Button Select Read 11 - Button L
Read 4 - Button Start Read 12 - Button R
Read 5 - Up Read 13 - '0'
Read 6 - Down Read 14 - '0'
Read 7 - Left Read 15 - '0'
Read 8 - Right Read 16 - '0'
All reads after read 16 will return 1.
All buttons are 1= pressed, 0= released.
If no joypad is plugged in, then zero is always read from $4016 or $4017.
A game can check if a joypad is connected by seeing if any reads beyond
the 16th one return '1', otherwise there is no joypad.
As far as I can tell, the joypad does not return any data through pin 5
(which always returns zero) and any setting of pin 6 will not affect the
joypad operation. |
I'm trying to implement the shift buffer he describes. The only
inconsistency in his document is what happens when a controller is
unplugged after read 16. He says 1 is always returned here, then goes
on to say that unplugged gamepads always turn 0's. Which is it? I'd
strongly believe it was 0, leading me to believe that $4016 stops at
the joypad connected bit and continues returning that until strobed
again.
I don't now what your code is doing exactly. The strobe value already
has to be 0 to reach the case 15 condition. And you never return the
controller connected bit (which is the 17th read after strobing $4016),
nor stop the joypad read pos from overflowing back to zero.
I'm going to kill the "seventeenth bit", and instead use a fake
"sixteenth" bit to return the status of whether or not a joypad is
connected. Sound good?
-----
EDIT: Ok, OAM sprite list caching removed, raised speed by ~1.5% in most cases, heh.
I have the same bug in Super Conflict as Super Sleuth :(
Fixed joypad support, and in such a way as to still allow a key +
joypad button to be mapped to a single SNES key, so you can switch
between the two at will without having to remap everything.
For v0.017, I'll add an option to swap controller ports 1 and 2.
So that leaves beta testing for the new features, and this release
should be ready to go. 9-10 of 26 bugs should be fixed. Not too bad, I
suppose ;)
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 19, 2006 10:45 am Post subject: |
|
Woohoo! Great news!
I volunteer to beta test. PM me at your convenience.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 19, 2006 11:29 am Post subject: |
|
Alright, hopefully tomorrow. It'll be non-SSE2, possibly non-PGO. Not sure yet. I'll let you know when it's ready. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Wed Apr 19, 2006 2:00 pm Post subject: |
|
FitzRoy wrote: |
I volunteer to beta test. PM me at your convenience.  |
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Wed Apr 19, 2006 2:09 pm Post subject: |
|
Sith-Smasher wrote: |
FitzRoy wrote: |
I volunteer to beta test. PM me at your convenience.  |
|
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed Apr 19, 2006 4:31 pm Post subject: |
|
adventure_of_link wrote: |
Sith-Smasher wrote: |
FitzRoy wrote: |
I volunteer to beta test. PM me at your convenience.  |
|
|
|
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Wed Apr 19, 2006 4:57 pm Post subject: |
|
I
just tried BSNES on my superfast dual-core laptop and I'm very
impressed. One thing annoys me though. Do I need to configure my video
drivers to get rid of the annoying interpolated blurriness? I want my
clean pixels dammit! VisualBoyAdvance did the same thing...EXTREMELY
ANNOYING. I hate to complain...but why do emulator authors allow
interpolation to be enabled by default and not have a way to disable it? |
|
Agozer 16-bit Corpse | Nyoron


Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
|
Posted: Wed Apr 19, 2006 5:13 pm Post subject: |
|
Ichinisan wrote: |
I
just tried BSNES on my superfast dual-core laptop and I'm very
impressed. One thing annoys me though. Do I need to configure my video
drivers to get rid of the annoying interpolated blurriness? I want my
clean pixels dammit! |
What happens if you disable DirectDraw Acceleration?
_________________
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.
|
|
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Wed Apr 19, 2006 5:15 pm Post subject: |
|
Agozer wrote: |
Ichinisan wrote: |
I
just tried BSNES on my superfast dual-core laptop and I'm very
impressed. One thing annoys me though. Do I need to configure my video
drivers to get rid of the annoying interpolated blurriness? I want my
clean pixels dammit! |
What happens if you disable DirectDraw Acceleration?
|
BSNES refuses to open.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Apr 19, 2006 7:29 pm Post subject: |
|
Ichinisan wrote: |
I hate to complain...but why do emulator authors allow interpolation to be enabled by default and not have a way to disable it? |
As has been mentioned before, it's just how DirectDraw works. No way
around it. Something along the lines of: if requested output resolution
is different (and larger) than source resolution, use bilinear
interpolation.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 19, 2006 7:38 pm Post subject: |
|
Ichinisan wrote: |
I
just tried BSNES on my superfast dual-core laptop and I'm very
impressed. One thing annoys me though. Do I need to configure my video
drivers to get rid of the annoying interpolated blurriness? I want my
clean pixels dammit! VisualBoyAdvance did the same thing...EXTREMELY
ANNOYING. I hate to complain...but why do emulator authors allow
interpolation to be enabled by default and not have a way to disable it? |
Are you using the RC1 version? That particular version has a "pixel
filter" and "bilinear filter" that you can choose between.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 19, 2006 11:28 pm Post subject: |
|
I'll
just post RC2 here later on. I do need actual testing, though. I redid
a lot of stuff, especially in the GUI. The important things are trying
to add a bunch of game genie / PAR codes, and then editing and deleting
them and hoping it doesn't botch anything in the process, making sure
no UI elements that aren't disabled do nothing, verify all the
different joypads+keys work ok, and of course looking out for crashes.
The new version uses Direct3D (you need DX9 installed), and that lets
you turn off the bilinear filtering. Though you'll hate the way
anything looks when you enable aspect ratio correction without it, even
at massive resolutions like 1600x1200. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Apr 20, 2006 12:01 am Post subject: |
|
Oh, the GameGenie / PAR code stuff I can do.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 20, 2006 4:44 am Post subject: |
|
You must copy and paste these links into your address bar, as I disable offsite linking.
Please post any and all feedback you can. What you think of the new
configuration system (how the UI works for you. Is it too complex now?
Is it better to have more power? Is anything not clear enough?), how
the new cheat system works for you, how the Direct3D9 interface works
for you, how the new input system works for your digital and/or analog
controllers, what you think of the adjustable axis tolerance setting
for analog joysticks ... whatever you can give me.
You can edit the config file by hand and modify video.renderer to "dd"
if you want to use the old DirectDraw7 renderer (in case the Direct3D9
renderer isn't working too well for you).
There's some new changes since the last post. I reverted the windowing
code back to my old for loop, I kept finding crashing bugs with the
direct memset method, and it makes no difference in speed, so screw it.
Code is cleaner this way, anyway.
I also tried to fix up the SRAM memory mapping at the request of Jonas
Quinn. It's really difficult, because I basically have to simulate all
40 or so different PCB layouts using only two generic templates. See
src/memory/bmemory/bmemory_mapper_generic.cpp for more details on the
new SRAM mapping.
SSE(1 or 2) is not required, since that was a big problem last time.
bsnes v0.015 rc2 :
byuu.cinnamonpirate.com/files/bsnes_v015_rc2.zip
bsnes v0.015 rc2 source code :
byuu.cinnamonpirate.com/files/bsnes_v015_rc2_src.zip
Let's keep a list of issues. So far, I've noticed I left "use triple
buffering" in the video options menu, despite it being configured on a
per-video-profile basis now. Ignore that option, please. |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 20, 2006 6:34 am Post subject: |
|
Fixed :
captain novolin
castlevania - dracula x
earthworm jim 2
final fantasy - mystic quest
krusty's super fun house
super conflict
super double dragon
super empire strikes back
super return of the jedi - controls worked in v0.015 too, though...
---
Still broken :
battletoads in battlemaniacs
captain america & the avengers
mighty morphin power ranges - the movie
mortal kombat
genjuu ryodan
RPM racing
wild guns
/new game/ jurassic park 2 - hangs before intro if you don't press start first
---
The rest are untested, as I don't have the European or Japanese sets,
sadly. SoM would take too long to get the world map up, so I didn't
bother testing that. I didn't fix anything that would fix SoM anyway. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Apr 20, 2006 6:38 am Post subject: |
|
byuu wrote: |
Fixed :
captain novolin
castlevania - dracula x
earthworm jim 2
final fantasy - mystic quest
krusty's super fun house
super conflict
super double dragon
super empire strikes back
super return of the jedi - controls worked in v0.015 too, though...
---
Still broken :
battletoads in battlemaniacs
captain america & the avengers
mighty morphin power ranges - the movie
mortal kombat
genjuu ryodan
RPM racing
wild guns
/new game/ jurassic park 2 - hangs before intro if you don't press start first
---
The rest are untested, as I don't have the European or Japanese sets,
sadly. SoM would take too long to get the world map up, so I didn't
bother testing that. I didn't fix anything that would fix SoM anyway. |
I'll probably check the games that are fixed.. (though that'll be many many hours from now).
As for the SOM comment, I don't exactly follow what you mean by getting
the world map up (you mean the intro takes too long or something? I
have a working SRM you can use so you can see the overworld with
Flammie)... although I do know you haven't fixed it yet.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 20, 2006 7:16 am Post subject: |
|
Don't bother, I fully intended to update the buglist with this release. It did clean it up quite a bit 
First though, commentary on the new config system as requested: I like
it a lot. However, things I recommend to make it better.
a. I don't really like the transparent window idea. I can't really see
what's behind it very well, and I don't know why I would need to
anyway. It's kind of hurting my eyes to look at. I'd go solid, even if
you can't figure out a way to make windows overlap each other on
clicking.
b. It would be nice if the config menu pauses the emulation while it's
up. As it is, the menu coming up slows my games 80%, which results in
the sound crackling and becoming super annoying.
c. Most emulators come with a filtered image off by default. I think
bsnes should follow suit and have things like scanlines and
interpolation off to start with.
Now on to the bugs. For some reason, the games with the "interlace
issue" as I thought it was are working now, and no longer crash the
emulator. Did this get addressed silently, or was this hi-res, not
interlace?
Secondly, one of the bugs seems to have changed since last release.
Rendering Ranger R2 will always get to the title menu if you do fresh
"load rom." However, if you reset the game, it has a chance of hanging
after either of the two company logos.
Welp, off to sleep...  |
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Thu Apr 20, 2006 1:54 pm Post subject: |
|
Cannot get it to run comes up with the message user32.dll error and it is already in my windows/system directory |
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Thu Apr 20, 2006 4:23 pm Post subject: |
|
djohnson wrote: |
Cannot get it to run comes up with the message user32.dll error and it is already in my windows/system directory |
That is only if you are running it on Win9x.
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Thu Apr 20, 2006 4:37 pm Post subject: |
|
I
only wish that the input configuration interface would actually show
which keys have been assigned to the controller. Other than that, it's
excellent. :D |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Apr 20, 2006 5:05 pm Post subject: |
|
Blah, why do I get Direct3D9 errors when I have the latest DirectX installed?
EDIT: I got it to work by changing the settings from Direct3D9 to DirectDraw7...
But the configuration flashes and lags the emulator whenever you open
it. Also is there anyway to get a link from File or Settings menu to
open the GameGenie / PAR cheat console?
Otherwise, good work! I'll be testing the Cheats in a couple minutes... |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Thu Apr 20, 2006 5:26 pm Post subject: |
|
I got Firefox this time to dl the file as it doesn't like IE. Smooth sailing. 
I'll give it a go and report anything unusual.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Apr 20, 2006 5:33 pm Post subject: |
|
byuu wrote: |
Is
it too complex now? Is it better to have more power? Is anything not
clear enough?), how the new cheat system works for you, how the
Direct3D9 interface works for you, how the new input system works for
your digital and/or analog controllers, what you think of the
adjustable axis tolerance setting for analog joysticks ... whatever you
can give me. |
Direct3D9 is used for everything now, by default, correct? Works fine for me, here.
My thoughts:
Under "Video Options," should you maybe make "Use Video Memory Surface"
and config-only setting? This seems like a pretty advanced setting that
end-users should not need to see. Triple buffering, as you said, is
moving to the Video Configuration page. Can you eliminate the Video
Options menu and just put "Show FPS" on the top-level of the Settings
menu?
"Mute Sound Output" might be shortened to just "Mute Sound." "Output"
is just another word that could confuse end-users.
Under "Speed Regulation," you might want to make Enabling/Disabling it
a config-file only option. Some people might be screwing around,
disable it, then freak out. It seems like you would want to have it
enabled pretty much all the time. Also, having the audio sample rates
on that list is also confusing. It seems to me most end-users would
only be confused by that.
It would be nice for the About box to have a title bar and an X button
(just to make it a more "standard" window, to fit in with the rest of
the dialogs in the emulator).
Settings-> Configration
It definitely needs configurable transparency and always-on-top (if even only on/off).
Video Settings:
The default windowed/fullscreen profile choosers should be the first
thing on this page. As they are now, underneath "Profile to configure,"
it makes them seem that they could be a setting dependent on the
current profile. Perhaps you can move these default choosers out of the
Configuration page and into the Settings menu.
The video settings page is somewhat confusing to me. I realize that an
SNES emulator does require this level of complexity for accurate and
highly configurable video settings. But the video configurations are
not very apparent. Two suggestions:
1) Perhaps you can visually order the settings like a schematic,
showing the order in which each setting is applied to the native SNES
video output. This would increase clarity somewhat.
2) Maybe create mouseover tooltips with expanded explanations of each
setting. I'm particularly confused about: The relationship between
Multiplier, Render width/height, and Resolution width/height. And how
those interact with the software filters. And "Correct aspect ratio."
There's just a lot of settings that aren't very apparent as to what
they do, for someone unfamiliar with how it all works.
Should the "Direct" software filter be re-named to "None"? Also, which
of Pixel and Bilinear is nearer to "No" Hardware filter? Ideally, there
should be a "None" for both software and hardware filter.
Color Adjust: Maybe rename it to "Color Adjustment" in keeping with the
noun phrases you use to label the other pages?
Raster Settings: Needs a restore defaults.
Input Configuration:
I concur with Xamenus, we need to see what the current assignments for
the keys are. Also, it might be good to have a "Restore Defaults"
button on the Input page, to automatically but Resistance back to 75%.
Also, are there any default key mappings? It might be good to create
some, for both P1 and P2, so people can play right out of the box. And
make sure the buttons don't conflict between P1 and P2 (I think the
default mappings for ZSNES conflict between P1 and P2).
Nestopia has a nice controller set up page, as does PSX Emulator (for
examples). Because you plan on supporting mutliple input keys for a
single SNES button, how are you going to show this? Completely
free-form, so that each SNES button could have an infinite number of
input keys? Or, only one keyboard key and one joystick/gamepad key per
SNES button?
If you move away from the input screen using the SNES controller
schematic, it might be nice to use a simplified image of the SNES
controller, as you had before. People may not be intimately familiar
with these emulated systems as the systems get older and the people
using the emulator get younger. 
Finally, why do you release your emulator with the config file? This is
somewhat confusing, seeing as how the released package should probably
use the "default" settings, which are the settings used with no
pre-existing configuration file, correct? Also, it might be good to
create a few pre-existing video settings, so that people have more
ability to use your emulator right out of the box. Few people would
probably be satisfied with the default video settings.
At the very least, it may be time to start including documentation with your emulator.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 20, 2006 7:08 pm Post subject: |
|
Quote: |
Cannot get it to run comes up with the message user32.dll error and it is already in my windows/system directory |
The joys of supporting 8-10 year old software... I swear I can't keep Win9x working to save my life :(
This is likely due to the layering settings for translucent config box.
Quote: |
I
only wish that the input configuration interface would actually show
which keys have been assigned to the controller. Other than that, it's
excellent. :D |
Will do.
Quote: |
I got Firefox this time to dl the file as it doesn't like IE. |
What can I say, my web server has discerning tastes :)
Quote: |
Can you eliminate the Video Options menu and just put "Show FPS" on the top-level of the Settings menu? |
Sure.
Quote: |
"Mute Sound Output" might be shortened to just "Mute Sound." "Output" is just another word that could confuse end-users. |
Sure.
Quote: |
Under
"Speed Regulation," you might want to make Enabling/Disabling it a
config-file only option. Some people might be screwing around, disable
it, then freak out. It seems like you would want to have it enabled
pretty much all the time. Also, having the audio sample rates on that
list is also confusing. It seems to me most end-users would only be
confused by that. |
No. I like turning it on and off, it's the best way to find out the raw
speed of the emulator. Perhaps I'll change it to a title you don't want
to uncheck, eg:
Speed Regulation ->
<checked> (I am not a dumbass / I always read software documentation)
---
Slowest
Slow
Normal
Fast
Fastest
Sound good? :)
I might drop the audio sample rates and turn it into a % of speed,
that's good enough. The reason it's there is because your sound card
must support that sampling rate on really shitty sound cards, even with
kmixer. But since most users won't be modifying the defaults, it should
be fine.
Quote: |
It
would be nice for the About box to have a title bar and an X button
(just to make it a more "standard" window, to fit in with the rest of
the dialogs in the emulator). |
How many about boxes have you seen that look like win32 forms? That's
kind of the idea. You can move the main emulator window and the about
box by right clicking and dragging on the forms. I realize that isn't
documented anywhere. You can also switch video modes with
Ctrl+<numpad number> (not with ctrl+<number> because they
aren't in order, they are 1-0 and not 0-9), adjust frameskip with +/-,
adjust speed regulation with ctrl+[+/-], pause with F12, toggle the
menubar with esc, and swap fullscreen mode with F11.
Eventually there will be a config page to adjust these options and more.
Quote: |
It definitely needs configurable transparency and always-on-top (if even only on/off). |
For now, look at bsnes.cfg last option, misc.config_window_alpha_level.
Quote: |
The
default windowed/fullscreen profile choosers should be the first thing
on this page. As they are now, underneath "Profile to configure," it
makes them seem that they could be a setting dependent on the current
profile. |
I'll swap them. I want the menu as clean as possible.
Quote: |
< explanation of video settings complexity > |
I thought it would be too tough for most to use. I'll just make a
simple mode for the emulator. It will run in simple mode unless you
read the documentation to learn how to enable advanced mode.
Quote: |
Should
the "Direct" software filter be re-named to "None"? Also, which of
Pixel and Bilinear is nearer to "No" Hardware filter? Ideally, there
should be a "None" for both software and hardware filter. |
Direct to none is fine. Pixel is none. I thought that was obvious, guess not.
Quote: |
Color Adjust: Maybe rename it to "Color Adjustment" in keeping with the noun phrases you use to label the other pages?
Raster Settings: Needs a restore defaults. |
Color adjust, sure. Raster settings, why? There's only two sliders there.
Quote: |
Also, it might be good to have a "Restore Defaults" button on the Input page, to automatically but Resistance back to 75%. |
I explain this option in detail using that scrollbox thing. It lists the default right inside the box.
Quote: |
Finally, why do you release your emulator with the config file? |
So that smart people can edit hidden options, and because I have to
save your configuration settings somewhere. I'd rather store it in a
plain english text file than in the windows registry (hello, SNES9x
"delete your registry keys" problems) or in gibberish binary (hello,
older pre-PSR ZSNES "delete your config files" releases).
Quote: |
Also,
it might be good to create a few pre-existing video settings, so that
people have more ability to use your emulator right out of the box. Few
people would probably be satisfied with the default video settings. |
There are pre existing settings. Five of ten are currently configured.
I guess I'll just remove the filtered modes. How's this?
1x scale windowed
2x scale windowed
2x scale + aspect correct windowed <default>
3x scale + aspect correct windowed
4x scale + aspect correct windowed
2x scale 640x480 fullscreen
2x scale + aspect correct 640x480 fullscreen <default>
2x scale + aspect correct 800x600 fullscreen
3x scale + aspect correct 1024x768
4x scale + aspect correct 1280x960
Good? Triple buffering will be off until I can fix the crackling audio problems I get with it.
Quote: |
At the very least, it may be time to start including documentation with your emulator. |
Apathy.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Apr 20, 2006 7:28 pm Post subject: |
|
In
summary: I think that for best "portability", there should be a very
compatible, useable set of default settings stored in the bsnes
executable, so that the first time a user runs the bsnes executable
(without config files), bsnes generates a config file with those
defaults. The defaults should have everything required for play,
including default key settings.
byuu wrote: |
Quote: |
Finally, why do you release your emulator with the config file? |
So
that smart people can edit hidden options, and because I have to save
your configuration settings somewhere. I'd rather store it in a plain
english text file than in the windows registry (hello, SNES9x "delete
your registry keys" problems) or in gibberish binary (hello, older
pre-PSR ZSNES "delete your config files" releases).
|
What I meant here is, why do you release the emulator with an already
pre-configured config file along with the executable? I don't want
registry settings either. What I meant is that I'm used to the behavior
of ZSNES, where there is no configuration file included in the archive.
It generates the config files on first run of ZSNES. So ZSNES stores
all the default behavior in the executable (or something). But I
noticed that the settings you have in the config file that you release
with bsnes is not the same settings as are generated after I delete the
config file.
byuu wrote: |
Quote: |
Also,
it might be good to create a few pre-existing video settings, so that
people have more ability to use your emulator right out of the box. Few
people would probably be satisfied with the default video settings. |
There are pre existing settings. Five of ten are currently configured. I guess I'll just remove the filtered modes. How's this?
|
See above. I personally don't care what the default video settings are. I'm just saying it might be nice for users to have some simple pre-defined ones.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 20, 2006 7:32 pm Post subject: |
|
Jipcy had many good suggestions, but I will say that:
-I don't like the tool-tips idea. Tool-tips and pop-ups in general suck, IMO.
-most things did not appear "too complex" for me. If anything, adding a
simple and advanced mode in addition to everything makes it even more
complex.
-and I agree with byuu about documentation. Chances are people won't
read it anyway. Everything seems self-explanatory. Documentation
increases download size and is a total mess to deal with. Look at ZSNES.
And yes, D3D9 works for me, too. Get with the times people, it's nothing new. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Apr 20, 2006 7:37 pm Post subject: |
|
FitzRoy wrote: |
-most
things did not appear "too complex" for me. If anything, adding a
simple and advanced mode in addition to everything makes it even more
complex. |
I think byuu was suggesting that simple mode would be on by default.
Complex mode would not be visible to the user at all (initially), and
the only way to enable complex mode would be to set a switch in the
configuration file.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 20, 2006 7:41 pm Post subject: |
|
Yes,
but is it really worth the trouble to do that? There aren't that many
settings, and where's the line between simple and complex? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 21, 2006 3:08 am Post subject: |
|
FitzRoy wrote: |
Secondly, one of the bugs seems to have changed since last release.
Rendering Ranger R2 will always get to the title menu if you do fresh
"load rom." However, if you reset the game, it has a chance of hanging
after either of the two company logos. |
I'm renegging on this report. What happened was I recalled trying it,
but only once, on .015, and it got into the level. So I thought it
worked better, but I actually just got randomly lucky. I dled .015
again to see if I could reproduce what's happening now, and sure enough
it is the same behavior. The game will make it to the title screen if
you do a fresh load, but if you reset the game, it has a chance of
hanging before that. If memory serves, zsnes used to have reset issues
where memory wasn't getting flushed properly or something. I'm foggy on
it, and it might be unrelated.
I think I'll mention while I'm at it, that for Mortal Kombat, the (E)
version curiously does not exhibit the wierd bug in battles. Maybe that
info will be of use.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 8:10 am Post subject: |
|

How's this? Ideally, I'd like the SNES joypad image stuck on there
somewhere, but the screen is pretty cramped as it is, and I hate to
increase EXE size with another bitmap :/
EDIT: Or how's this?
 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 21, 2006 8:55 am Post subject: |
|
I
really like that. It addresses the issue of knowing what's bound to
what. The loss of the image or controller layout only has one drawback
for me, and that is remembering that B comes before A on the
controller. Am I just crazy or does anyone else think this way? If so,
I would suggest placing B before A, Y before X on the list.
Edit:
Aww, wierd you edited as I posted. Ok, I still prefer the first one,
and I think you can get away without an image by just ordering the
buttons as above. Furthermore, it looks like if you got rid of the top
title for each config window (i.e. "Input Configuration"), you may have
the space available to do away with that scrollbar completely and just
have a full-view list window.
But yeah, what do other people think?
Last edited by FitzRoy on Fri Apr 21, 2006 9:04 am; edited 1 time in total |
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Fri Apr 21, 2006 8:56 am Post subject: |
|
Jonas Quinn wrote: |
djohnson wrote: |
Cannot get it to run comes up with the message user32.dll error and it is already in my windows/system directory |
That is only if you are running it on Win9x.
|
Yes i am running win98
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 9:22 am Post subject: |
|
Third try: <third try removed, too similar to fourth>
Edit: or fourth. With FitzRoy's suggestion for key ordering. Helps a lot for quickly configuring the controllers.

Look good? Heheh, just kidding 

Ok, unless someone doesn't like this, this'll probably be what goes
into v0.016. I'll go ahead and share my ideas for v0.017 now, however.
Also, you can click update or just double click the line you want to update.
I'm going to remove the joypad axis resistance setting from this page
and rename it to "joypad configuration". I'm going to add controllers
(renamed to joypads) 1-5 (or 1-8?), and you can configure whichever
ones you want.
Then, there will be a new input configuration page. This page will give
you two combo boxes, one to select what connects to SNES controller
port 1 (left port), and what connects to controller port 2 (right
port). I'll try and draw a bitmap demonstrating this for the page, as
well.
You can select "None" for no controller, or any of the 5 (8?)
controllers to be plugged into either port. Eventually, there will be a
multitap option here, and there will be a multitap screen to configure
what controllers are connected to which multitap ports. Hopefully one
day there will also be SNES mouse, super scope 6, and 1-2x justifier
options as well.
Last edited by byuu on Fri Apr 21, 2006 10:20 am; edited 1 time in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Apr 21, 2006 10:14 am Post subject: |
|
Jipcy wrote: |
Finally, why do you release your emulator with the config file? |
Well, some emulators crash on certain machines if you use the default
settings. Happened to me with a build of SNES9x that has "use video
memory" enabled.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Apr 21, 2006 2:34 pm Post subject: |
|
See this post: http://board.zsnes.com/phpBB2/viewtopic.php?p=108720#108720
I'm sorry, but byuu got out of hand, I banned him.
Guys, you'll have to take your emulator affection somewhere else.
Besides less face it, no one really likes bsnes, no developer in their
right mind would add a single line of code for it except for byuu, so
why are we keeping up this facade of making believe we like bsnes?
I doubt anyone really likes that thing, so slow, has an awful website, no mirrors for binaries...
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Fri Apr 21, 2006 2:40 pm Post subject: |
|
Great, I hate that emulator, good riddance. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Apr 21, 2006 5:21 pm Post subject: |
|
edit by dmog
edit
edit
edit
edit
edit
Last edited by Dmog on Sat Apr 22, 2006 1:51 am; edited 1 time in total |
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Fri Apr 21, 2006 5:30 pm Post subject: |
|
My post was edited by a moderator to say that. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Fri Apr 21, 2006 5:42 pm Post subject: |
|
byuu wrote: |
http://byuu.cinnamonpirate.com/temp/bsnes_inputconfig4.png |
Yes, that looks good with the SNES controller bitmap. Thanks for making it show the key assignments, too. :)
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Fri Apr 21, 2006 5:48 pm Post subject: |
|
For some reason this whole occurance seems like something out of "This is Spinal Tap." |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Apr 21, 2006 5:55 pm Post subject: |
|
edit
edit
edit
edit
edit
edit
edit
(so we all saw the 'edit')
Yeah ok. Great joke I guess (rolleyes). Would have actually been funny if it was around April 1st though...
I did find it weird that Nach said that "no one would want to
contribute one line of code", seeing as he did contributed himself but
heh...
Last edited by Dmog on Sat Apr 22, 2006 1:50 am; edited 2 times in total |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Apr 21, 2006 6:03 pm Post subject: |
|
I LOVE BSNES.
_________________
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 Apr 21, 2006 6:04 pm Post subject: |
|
Oh my, I leave for 12 hours and the shit hits the fan...
Dmog is right too, and I'd like to also point out the fact that byuu's
SNES emulation information is quite true (in fact, SteveSnake himself
has said the exact same stuff, and nobody took him seriously).
bsnes will be the Kega of the SNES emulators (In fact, it allready is).
Last edited by King Of Chaos on Fri Apr 21, 2006 11:07 pm; edited 3 times in total |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Fri Apr 21, 2006 6:13 pm Post subject: |
|
Posting in shitty thread.
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU
DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU |
|
Jyunichi Rookie
Joined: 10 Sep 2004
Posts: 32
|
Posted: Fri Apr 21, 2006 6:14 pm Post subject: |
|
This is so ridiculous that it must be a joke. Sad thing is I can only see one person laughing. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 10:25 pm Post subject: |
|
I'm not banned. It was a joke by Nach, in response to my post on "Nice Board". Apparently in bad taste :/
He probably shouldn't have posted in this thread as well, but he did leave plenty of hints.
Quote: |
no developer in their right mind would add a single line of code for it except for byuu |
Nach himself has contributed 250kb of code to bsnes thus far, adding ZIP, GZ, JMA and Cx4 support.
Quote: |
no mirrors for binaries... |
http://nsrt.edgeemu.com/forum/viewtopic.php?t=490
Anyway, you have my apologies. Especially to Joe. I would've replied
much sooner before anyone got upset, but I was asleep and just woke up.
And as per IRC, Nach is gone for the next ~16 hours or so. Please don't
be upset with either of us, Nach has contributed an unbelievable amount
of work to bsnes, and will be hosting my next release for me, and I'm
very grateful.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Apr 21, 2006 10:33 pm Post subject: |
|
Sarcasm translates badly on forums. See the responses...
_________________
FF4 research never ends for me. |
|
themewin Lack of Imagination

Joined: 31 Jul 2004
Posts: 379
Location: In your closet!!!!
|
Posted: Fri Apr 21, 2006 11:00 pm Post subject: |
|
HoLY SHEEP SHIT
COCKS
AND BALLS
tis what you suck
yea you
no not you
that guy right there |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 21, 2006 11:05 pm Post subject: |
|
Yeah,
a little too elaborate for me, bad timing in the middle of an RC test,
and sarcasm is indeed very hard to detect from text alone, even with
hypocritical statements.
What was funny, though, were the people who were ready to start an emulator war over it 
Last edited by FitzRoy on Fri Apr 21, 2006 11:06 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 11:05 pm Post subject: |
|
themewin, please die.
Quote: |
Sarcasm translates badly on forums. See the responses... |
Or more generally, on the internet as a whole. Such a shame, I grew up
around sarcasm and satire. It's second nature to me.
Quote: |
bad timing in the middle of an RC test |
You're not kidding... :/
Again my apologies (my name is the
embodiment of internet drama), and I hate to seem insensitive but can
we please move on with the beta testing? I'd like to keep this thread
from getting derailed as it is "THE bsnes board" for the time being :/
I want to get v0.016 out very soon. I've added all of Jipcy's suggested
changes. Is the fourth input config screen adequate? Any other
suggestions before release? I'm frankly sick and tired of supporting
Win9x, but should I revert the translucency settings to support
pre-2000 Windows?
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Apr 21, 2006 11:12 pm Post subject: |
|
Yea, I have one quick suggestion...
Add a menu item for the Cheat Code Editor to either the "File" or "Settings" menu.
Either that or hotkeys to open it quickly.
One more thing, how hard would it be to have the emulation pause
anytime you get in the Configuration? Because it get's a little
annoying to have the config dialog open while the game is still running.
Other than that, it's good to go. 
About the Win9x support, I say dump it completely as there isn't many people out there anymore with ME and below.
Oh yes, I forgot to add the File History request. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
Last edited by King Of Chaos on Fri Apr 21, 2006 11:24 pm; edited 1 time in total |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Apr 21, 2006 11:15 pm Post subject: |
|
byuu wrote: |
I'm frankly sick and tired of supporting Win9x, but should I revert the translucency settings to support pre-2000 Windows? |
I think I said something about this earlier.
Frankly you should support Win9x.. remember that the translucency is a
neat thing, but nothing required for the operation of the emulator...
it makes no sense to break Win9x compatibility based on this feature.
I wonder whether it is make sense to dump Win9x... considering that
BSNES needs a hefty processor in the first place to run it.
_________________
FF4 research never ends for me.
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Apr 21, 2006 11:21 pm Post subject: |
|
Since this was all a joke, I owe Nach an apology.
He still has my respect. Oh well he had me completely fooled. Kudos to him.
_________________
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 Apr 21, 2006 11:22 pm Post subject: |
|
Deathlike2 wrote: |
I wonder whether it is make sense to dump Win9x... considering that BSNES needs a hefty processor in the first place to run it. |
Exactly. It makes more sense to dump pre-Win2000 compatibility.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 11:25 pm Post subject: |
|
Quote: |
Add a menu item for the Cheat Code Editor to either the "File" or "Settings" menu. |
File is for ROM manipulation, Settings is for emulation manipulation.
I'll add a quick link that takes you to the cheat code screen under
Misc, ok?
Quote: |
One more thing, how hard would it be to have the emulation pause anytime you get in the Configuration? |
That's doable. I'm going to leave this setting off by default, and add
it to the config file for now. The reason I leave it on is because the
raster settings do not take effect until the next frame is rendered,
thusly you won't see your changes if emulation is paused.
Eventually, I'll add another panel for config screen configuration,
heheh. Throw in options to toggle always on top and pause emulation on
show.
Quote: |
Frankly
you should support Win9x.. remember that the translucency is a neat
thing, but nothing required for the operation of the emulator... it
makes no sense to break Win9x compatibility based on this feature. |
Fine, I'll remove it. I'll have to post another build for people on
Win9x to test, as I won't be able to see if it works myself.
Quote: |
Exactly. It makes more sense to dump pre-Win2000 compatibility. |
Grah. Do we need a poll for this? You either get win2k+ features, or winME- compatibility :/
Maybe I can add Win2k+ detection and call the
SetLayeredWindowAttributes function via LoadLibrary/GetProcAddress, so
it works on WinME-, just without any translucency.
I know DMV27 uses WinME-, and his assistance is always invaluable, so I
should probably just support it for him alone.
|
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Apr 21, 2006 11:33 pm Post subject: |
|
Thank you. 
And yes, a poll seems like the logical solution.
EDIT: It seems I might of found 2 bugs...
1. The cheat code editor dosen't ignore the : in PAR codes (Example: 7E045B:00 for War Of The Gems).
2. Under the Windows XP theme, the Configuration looks messed up (white
on grey) Although this won't probably happen if you're using the
Windows Classic theme.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 21, 2006 11:40 pm Post subject: |
|
PAR codes do not contain a :
Try 7e045b00. Do you know of a lot of codes that have : there? I'll try and support it if so.
The main cheat issue I was worried about was manipulating a list of
like 20+ codes for a single game. Are weird corruption issues occurring
when you add/remove codes, or no?
I'll include a manifest file so XP themes are enabled, but I'm unable
to bit twiddle the interface to perfection as I like with XP themes :/ |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Apr 21, 2006 11:43 pm Post subject: |
|
Yes,
almost all PAR codes I've ever seen include the : (Infact all that are
made in Kega and Gens, and the majority of the SNES ones made on
gscentral.org include the : )
Well, to fully test that for ya, I'll load up SMW and input about....40 codes and see what happens. 
EDIT: Ok, I have 25 codes in SMW right now, and I'm testing combos of
turning some on and some off, and there are no crashes yet...
EDIT 2: Ok, I'm finding some PAR codes don't work in bsnes (GameGenie
seems to work fine), but they do work in ZSNES/Snes9x...
Code: |
Super Mario World:
7E001903 Always Fire Mario
7E001902 Always Caped Mario
7E1497FF Invincibility (Uneffected)
7E1490FF Invincibility (Star Effect) |
I've also found that X-Men - Mutant Apocalypse's PAR codes don't work
either... But those codes *should* work. Ehh, I just hope they're not
incorrectly made codes...
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
Last edited by King Of Chaos on Sat Apr 22, 2006 12:27 am; edited 3 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 22, 2006 12:23 am Post subject: |
|
It's
doesn't hurt convenience much to not have translucency, and if it
breaks win9x support completely... well... I think it's beyond saving.
You also previously expressed that you didn't want to add unnecessary
space to the emu. With the Y/X B/A thing, I wonder if a reference image
is further needed. I know you want .016 out soon, but so far I'm the
only one commenting on this stuff :/ We need more input. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 22, 2006 1:46 am Post subject: |
|
Quote: |
EDIT 2: Ok, I'm finding some PAR codes don't work in bsnes (GameGenie seems to work fine), but they do work in ZSNES/Snes9x...
7E1490FF Invincibility (Star Effect) |
Oh, fuck me :(
It mirrors addresses. Just wonderful. Use the code 001490FF and it
works fine. Sigh, this is going to add a lot of overhead. I hope
mirroring RAM alone is good enough. I'd really hate to have to mirror
RAM+ROM+SRAM...
Anyone have more technical info on this?
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Apr 22, 2006 2:00 am Post subject: |
|
byuu wrote: |
Quote: |
EDIT 2: Ok, I'm finding some PAR codes don't work in bsnes (GameGenie seems to work fine), but they do work in ZSNES/Snes9x...
7E1490FF Invincibility (Star Effect) |
Oh, fuck me 
It mirrors addresses. Just wonderful. Use the code 001490FF and it
works fine. Sigh, this is going to add a lot of overhead. I hope
mirroring RAM alone is good enough. I'd really hate to have to mirror
RAM+ROM+SRAM...
Anyone have more technical info on this?
|
I'll try to get some information about this... In the meantime, I'll just reverse the addresses...
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Sat Apr 22, 2006 2:51 am Post subject: |
|
Anyone else have no sound at all in the new release candidates? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 22, 2006 5:09 am Post subject: |
|
Ok, to try and make up for all the trouble this morning...
byuu.cinnamonpirate.com/files/bsnes_v015_rc3.zip
byuu.cinnamonpirate.com/files/bsnes_v015_rc3_src.zip
Please download the source only if you intend to do something with it.
Changelog:
- Added ten default video modes
- Removed bsnes.cfg with archive
- Removed audio frequency from speed regulation menu for simplicity
- Removed Video Options submenu and placed Show FPS under main settings menu
- Updated video settings panel to be more clear
- Completely rewrote input configuration screen, now shows currently assigned key
- Added support for PAR codes in "aaaaaa:dd" format
- Added mirroring to GG/PAR codes for WRAM addresses only
- Fixed bugs in GG/PAR support when two codes shared the same address, but had different override values
- Turned off transparency on configuration panel by default
Errata:
- Still does not run on WinME or below
- Still did not add Cheat Code Editor quick link to misc menu
- Still uses .cht extension, which may/may not cause horrible problems
with ZSNES' completely different binary .cht file format
I decided to stick with "mute sound output", looks too empty next to
speed regulation without it, and I really don't want to cater to that low a denominator -- "output? what that thar sapposed ta meen! geez teh ZNES izznt so kanfuzzalin!" :/ |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Sat Apr 22, 2006 5:25 am Post subject: |
|
http://rapidshare.de/files/18518397/bsnes-patch-2006-03-18.zip.html
Some of these fixes are redundant now, but the timing changes should be
accurate. I don't know if they fix any games though.
bcpu_dma.cpp.patch initializes the dma regs to 0xff on reset. Ignore this patch if that is incorrect.
bcpu.cpp.patch updates the open bus value in mem_write. It also has changes for irq/nmi/power/reset.
bcpu_int.cpp.patch adds support for emulation mode irq/nmi, and makes nmi have a higher priority than irq.
bcpu_mmio.cpp.patch fixes joypad strobing for $4016/17, which fixes
Super Double Dragon. Also, (H)DMA is now blocked from accessing $420B,
$420C, and $43xx. I know that writing 0 -> 1 to $4016 will latch the
joypad state, but does writing 1 -> 1 also latch the state, or does
the previously latched state persist?
cart.cpp.patch changes the checksum scoring to allow Choujikuu Yousai
Macross to work. If the graphics are corrupted, deinterleave the rom
with NSRT.
op_misc.b.patch fixes brk/cop timing, txs flags, and wai timing. With
the wai timing fix, bsnes now passes your original timing test:
Code: |
Slow Fast
Base: 002f 002d
Full: 0129 0103
Diff: 00fa 00d6 |
op_pc.b.patch fixes the timing of rti.
Also, there are some things I did not fix:
Reading from OAM should not update the oam latch.
Writing to CGRAM should update the cgram latch (regs.txt).
Stack over/underflow in emulation mode.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 22, 2006 5:52 am Post subject: |
|
Yay! Always a delight to see a new post from you.
Quote: |
bcpu_dma.cpp.patch initializes the dma regs to 0xff on reset. Ignore this patch if that is incorrect. |
It happens on power-on for sure. I don't know what happens during
reset. A lot of registers are reset at power-on only. I've been
avoiding this area as my copier is bad test for power-on register
states.
Quote: |
bcpu.cpp.patch updates the open bus value in mem_write. It also has changes for irq/nmi/power/reset. |
Ah, maybe that'll fix Captain America. I can't wait to get that fixed so I can delete it. Bad, bad game.
Quote: |
bcpu_int.cpp.patch adds support for emulation mode irq/nmi, and makes nmi have a higher priority than irq. |
I thought it already had a higher priority. It always tests for NMI
first, and when NMI is invoked, it sets I, meaning IRQ can no longer
trigger. I'll look at the patch, I guess.
Quote: |
bcpu_mmio.cpp.patch
fixes joypad strobing for $4016/17, which fixes Super Double Dragon.
Also, (H)DMA is now blocked from accessing $420B, $420C, and $43xx. I
know that writing 0 -> 1 to $4016 will latch the joypad state, but
does writing 1 -> 1 also latch the state, or does the previously
latched state persist? |
Yep, found that one. And two other input bugs. See the rc3 source above.
Good question about 0->1 or 1->1. For now, I latch during both cases.
Also, $4017 has no strobing logic. Only $4016, and it affects both
controllers (shared pin). Again according to Charles MacDonald. Weird,
hm?
Got the (H)DMA stuff. Not sure I fixed $2180 transfers right. I know
there are some ways you can use $2180 and have it work, I don't know if
I've inadvertedly blocked some of those methods. I will need to test on
my copier.
Quote: |
cart.cpp.patch
changes the checksum scoring to allow Choujikuu Yousai Macross to work.
If the graphics are corrupted, deinterleave the rom with NSRT. |
Holy crap, the graphics were corrupted because I was detecting the
header from the wrong place?! Geez, that's absolutely wild that it
worked at all. I take it the game mirrors its header to both $7fc0 and
$ffc0?
Quote: |
op_misc.b.patch
fixes brk/cop timing, txs flags, and wai timing. With the wai timing
fix, bsnes now passes your original timing test: |
Wow, the first CPU core fixes in forever.
Quote: |
op_pc.b.patch fixes the timing of rti. |
I've tested this extensively. I'll have to look very closely at your timing fixes.
Quote: |
Reading from OAM should not update the oam latch.
Writing to CGRAM should update the cgram latch (regs.txt).
Stack over/underflow in emulation mode. |
I'll see what I can do, thanks for the heads up. I'm holding off on the
stack over/underflow cases, as they are quite bizarre and will take
some effort.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 22, 2006 6:43 am Post subject: |
|
Wow, nice DMV!
Any chance we could see this stuff in by .016, byuu? |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sat Apr 22, 2006 9:39 am Post subject: |
|
byuu wrote: |
Quote: |
cart.cpp.patch
changes the checksum scoring to allow Choujikuu Yousai Macross to work.
If the graphics are corrupted, deinterleave the rom with NSRT. |
Holy crap, the graphics were corrupted because I was detecting the
header from the wrong place?! Geez, that's absolutely wild that it
worked at all. I take it the game mirrors its header to both $7fc0 and
$ffc0?
|
Woah, so the problem was just that? I dunno if you remeber, but I pmed
you awhile back about the game not working. That's great that you have
a fix for it now.
I know what I'll be playing when bsnes 0.016 comes around. Hmm I guess
that's also the reason why I have to force high rom detection to play
it in SNEeSe.
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Sat Apr 22, 2006 10:20 am Post subject: |
|
byuu wrote: |
Quote: |
cart.cpp.patch
changes the checksum scoring to allow Choujikuu Yousai Macross to work.
If the graphics are corrupted, deinterleave the rom with NSRT. |
Holy crap, the graphics were corrupted because I was detecting the
header from the wrong place?! Geez, that's absolutely wild that it
worked at all. I take it the game mirrors its header to both $7fc0 and
$ffc0?
|
You should always check the reset vector before you look at checksums. Obviously a reset vector of $0000 is bad.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Apr 22, 2006 1:59 pm Post subject: |
|
Byuu..
Please do not Remove the Tripple buffering
On my radeon 9600se connected to my Samsung 710T 1280x1024@32bbp 60hz,
i get a constant tear, it only gets fixed by enabling tripple buffering.
Also my sound does not seem to get corrupted?
can you describe the soundproblem you are having as i do not seem to have any problems with this setting enabled
bsnes is unplayable without this setting on my tft monitor.
also it seems that Front Mission v1.0 J with the english patch does not work, it doesnt load at all. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Apr 22, 2006 2:13 pm Post subject: |
|
Major prop goes to DMV. Good to see others Snes gurus/knowlegable people lending a helping hand 
tetsuo55 wrote: |
also it seems that Front Mission v1.0 J with the english patch does not work, it doesnt load at all. |
If the original game work, then it's maybe just a faulty patch...or
worse, a translation that doesn't actually work on the real
hardware.According to byuu there are a lot of them out there.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Apr 22, 2006 3:06 pm Post subject: |
|
byuu wrote: |
- Added support for PAR codes in "aaaaaa:dd" format
- Added mirroring to GG/PAR codes for WRAM addresses only
- Fixed bugs in GG/PAR support when two codes shared the same address, but had different override values |
Yep, that fixed those mirroring problems. All codes now work perfectly 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Apr 22, 2006 3:30 pm Post subject: |
|
King Of Chaos wrote: |
Thank you. 
And yes, a poll seems like the logical solution. |
My vote goes for transparency in menues.
The way I see it: if you have a PC fast enough to handle bsnes, why
would you only have win98 installed? (instead of a dual-boot 98/XP for
example)
The only reason to have win98 installed anyway is to be able to run
some very old program that XP doesn't like. In fact, that's the reason
I had a dual boot system, but I'm ditching 98 in favor of Linux.
|
|
themewin Lack of Imagination

Joined: 31 Jul 2004
Posts: 379
Location: In your closet!!!!
|
Posted: Sat Apr 22, 2006 4:04 pm Post subject: |
|
AHAHAHAHAHAHA
o helo internets |
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Sat Apr 22, 2006 7:20 pm Post subject: |
|
Is
there any way bsnes can butter my toast? Forget this transparency
business, let's worry about the most important features first . |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Sat Apr 22, 2006 7:30 pm Post subject: |
|
Dmog wrote: |
Major prop goes to DMV. Good to see others Snes gurus/knowlegable people lending a helping hand 
tetsuo55 wrote: |
also it seems that Front Mission v1.0 J with the english patch does not work, it doesnt load at all. |
If the original game work, then it's maybe just a faulty patch...or
worse, a translation that doesn't actually work on the real
hardware.According to byuu there are a lot of them out there.
|
I have tried the translation on a GDSF7 copier, and it does work.
tetsuo55, are you sure you correctly patched your ROM? Make sure you
patched a headerless version 1.0 ROM, using version 1.0b of the patch.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 22, 2006 8:14 pm Post subject: |
|
Dmog wrote: |
King Of Chaos wrote: |
Thank you. 
And yes, a poll seems like the logical solution. |
My vote goes for transparency in menues.
The way I see it: if you have a PC fast enough to handle bsnes, why
would you only have win98 installed? (instead of a dual-boot 98/XP for
example)
The only reason to have win98 installed anyway is to be able to run
some very old program that XP doesn't like. In fact, that's the reason
I had a dual boot system, but I'm ditching 98 in favor of Linux.
|
I don't think it's too farfetched to think that some people with slower
cpus would happily run bsnes with frame-skipping in a win98 environment.
Besides, it's so much easier on the eyes to read things in the config
without the transparency. And since it only works in windowed mode,
it's quite easy to move it out of the way and see the game image
regardless of whether it's transparent.
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Sat Apr 22, 2006 8:25 pm Post subject: |
|
Silly
bug report: Attempting to do either a hard reset or a soft reset while
no game is loaded will crash bsnes, at least under Windows XP Pro SP2.
Maybe you'll want to grey out those options while no game is loaded. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 22, 2006 9:19 pm Post subject: |
|
Quote: |
Please do not Remove the Tripple buffering |
It's still there, I just removed the menu option as it's set on a per-video-profile basis now.
Quote: |
Also my sound does not seem to get corrupted? |
Wow, good to know. It messes up badly for me :(
Quote: |
If
the original game work, then it's maybe just a faulty patch...or worse,
a translation that doesn't actually work on the real hardware.According
to byuu there are a lot of them out there. |
There are, but FH is very attentive to details like this, I believe he
has the ability to test his code on real hardware. Is anyone else
having a problem with Front Mission?
Quote: |
My vote goes for transparency in menues. |
Ok, I think I can satisfy both. I'll add another config page and add an
slider to adjust window luminance that will only show up on 2k+, and an
always on top option for all OSes.
Quote: |
I
don't think it's too farfetched to think that some people with slower
cpus would happily run bsnes with frame-skipping in a win98 environment. |
I often run it on my 600MHz Pentium III at 50% speed. Great for puzzle
games like Wordtris. The music in that game is so bad it actually
sounds better at half tempo :)
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Apr 23, 2006 5:06 am Post subject: |
|
FitzRoy wrote: |
Dmog wrote: |
King Of Chaos wrote: |
Thank you. 
And yes, a poll seems like the logical solution. |
My vote goes for transparency in menues.
The way I see it: if you have a PC fast enough to handle bsnes, why
would you only have win98 installed? (instead of a dual-boot 98/XP for
example)
The only reason to have win98 installed anyway is to be able to run
some very old program that XP doesn't like. In fact, that's the reason
I had a dual boot system, but I'm ditching 98 in favor of Linux.
|
I don't think it's too farfetched to think that some people with slower
cpus would happily run bsnes with frame-skipping in a win98 environment.
|
Yeah,on second thought, I suppose having support for an additional OS
might be more useful. Basically, it's pretty equal to me one way or
another.
Quote: |
Besides,
it's so much easier on the eyes to read things in the config without
the transparency. And since it only works in windowed mode, it's quite
easy to move it out of the way and see the game image regardless of
whether it's transparent. |
byuu wrote: |
OK,
I think I can satisfy both. I'll add another config page and add an
slider to adjust window luminance that will only show up on 2k+, and an
always on top option for all OSes. |
Sounds good
|
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Sun Apr 23, 2006 7:00 am Post subject: |
|
King Of Chaos wrote: |
MajereDB8 wrote: |
Is there any way bsnes can butter my toast? |
Please die.
|
My God, it's full of sarcasm. Apparently, all disbelief is suspended automatically when it comes to this topic.
Reach for the stars, young prince. One day soon, your computer shall butter your toast, and brew your coffee.
Getting back on topic, there really is no sensible way to make
translucent menus, short of hacks, or rendering your own menus.
Although I'm sure figuring a way around that is almost as constructive
as turning the SNES into a Sega Saturn without actually shoving a
couple of SH2s inside, because I hear programming for those things is a
real bitch anyway. Maybe hotwire a couple of P4s into a cartridge
instead... Now we're talking. :D
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Apr 23, 2006 8:59 am Post subject: |
|
zidanax wrote: |
Dmog wrote: |
Major prop goes to DMV. Good to see others Snes gurus/knowlegable people lending a helping hand 
tetsuo55 wrote: |
also it seems that Front Mission v1.0 J with the english patch does not
work, it doesnt load at all. |
If the original game work, then it's maybe just a faulty patch...or
worse, a translation that doesn't actually work on the real
hardware.According to byuu there are a lot of them out there.
|
I have tried the translation on a GDSF7 copier, and it does work.
tetsuo55, are you sure you correctly patched your ROM? Make sure you
patched a headerless version 1.0 ROM, using version 1.0b of the patch.
|
The one i am using is from a goodsnes set, i did not patch it myself, i
need to get my snes to see if it actually works on that, the game does
work in snes9x and zsnes though also in zsnesxbox
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Apr 23, 2006 10:56 am Post subject: |
|
It's quite simple really. The rom in goodsnes is a dud. This was taken directly from the readme for the patch:
"The unpatched file size should be 3146240 bytes. The patched file size
should be 3441152 bytes. Any variation in the patched file size would
be down to your patching utility and not the IPS file; it would also
cause problems with running the ROM image."
Goodsnes prepatched rom: 3,440,640 bytes
My patched rom: 3,441,152 bytes
Also you need to apply the 4MB fix patch to run the game in bsnes.
However it wont work with the prepatched rom in goodsnes for obvious
reasons. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Apr 23, 2006 2:51 pm Post subject: |
|
NSRT > GoodSNES at this point
_________________
FF4 research never ends for me. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Sun Apr 23, 2006 2:53 pm Post subject: |
|
Bah, currently I'm drowning in work, not much time to test the new RC of Bsnes. 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Apr 23, 2006 8:04 pm Post subject: |
|
Hmm... nice job.. all the filters run beautifully.. close to 60fps on my system...
A list of stuff to look into:
1) The config file BSNES generates needs to be cleaned up a bit and
there's a few descriptions missing. (If you need a list, I can probably
put one up.)
2) Using Video RAM needs an actual menu option or maybe a profile option.
3) Setting the default ROM directory should be like what ZSNES does currently..
ZSNES sets the ROM directory when you load a ROM... though you might
want a switch to stop changing the ROM directory to use.
4) For the save path, it should be definable via the GUI (or configuration screen).
Edit: Updated this post for clarity and because it might not have been obvious...
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Tue Apr 25, 2006 9:19 pm; edited 2 times in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Apr 23, 2006 8:57 pm Post subject: |
|
powerspike wrote: |
It's quite simple really. The rom in goodsnes is a dud. This was taken directly from the readme for the patch:
"The unpatched file size should be 3146240 bytes. The patched file size
should be 3441152 bytes. Any variation in the patched file size would
be down to your patching utility and not the IPS file; it would also
cause problems with running the ROM image."
Goodsnes prepatched rom: 3,440,640 bytes
My patched rom: 3,441,152 bytes
Also you need to apply the 4MB fix patch to run the game in bsnes.
However it wont work with the prepatched rom in goodsnes for obvious
reasons. |
wow thanks for clearing that up, ill patch the original rom myself then.
Would it be at all possible to store savegames in a completely different path from the roms??
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Apr 23, 2006 9:02 pm Post subject: |
|
tetsuo55 wrote: |
powerspike wrote: |
It's quite simple really. The rom in goodsnes is a dud. This was taken directly from the readme for the patch:
"The unpatched file size should be 3146240 bytes. The patched file size
should be 3441152 bytes. Any variation in the patched file size would
be down to your patching utility and not the IPS file; it would also
cause problems with running the ROM image."
Goodsnes prepatched rom: 3,440,640 bytes
My patched rom: 3,441,152 bytes
Also you need to apply the 4MB fix patch to run the game in bsnes.
However it wont work with the prepatched rom in goodsnes for obvious
reasons. |
wow thanks for clearing that up, ill patch the original rom myself then.
Would it be at all possible to store savegames in a completely different path from the roms??
|
Um.. you can already do that in BSNES RC3 version byuu released... look
in the config file after running BSNES for the first time.
_________________
FF4 research never ends for me.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Apr 23, 2006 10:20 pm Post subject: |
|
english translation of bs zelda works fine... unlike in zsnes where it just fails to load.
_________________
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. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Apr 23, 2006 10:37 pm Post subject: |
|
tetsuo55 wrote: |
wow thanks for clearing that up, ill patch the original rom myself then. |
Sure no problem. Oh and you need to convert the rom if it doesn't have
a super magicom header. One I found in the goodsnes set had it's header
stripped off. Use ucon64 to convert it to the proper size.
http://ucon64.sourceforge.net/
here's the two patches if you need them:
http://romhacking.net/?page=translations&transpage=362
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Apr 23, 2006 10:45 pm Post subject: |
|
Well I finally updated directx to the latest version, so I finally had the chance to tried RC1 and RC3.
At the risk of sounding repetitive, Blargg's filter is indeed amazing.
The new video configurations are great too. Imo, the mutiple profiles
could be a bit more intuitive,but it works well once you're used to it.
One thing I noticed in RC3 is that if you enable the NTSC filter and
you set the frameskip to something above 0 (like frameskip2) the image
becomes quite "shaky". This doesn't occur in RC1 even with frameskip
enabled.
edit: I guess this is related to how merged fields work in the NTSC filters.
edit2: I was going to suggest to change "allow invalid input" to "allow
opposite axis" but it looks like you allready did. It's something that
could be done on the real hardware anyway (provided you actually
removed the d-pad cross thing) so they are not really "invalid" per-se
(unless I missed something) |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Apr 24, 2006 12:13 am Post subject: |
|
Well, perhaps an appropriate time to stop supporting pre-Win2k would be the same time Microsoft stops: http://support.microsoft.com/gp/lifean18.
xamenus wrote: |
Silly
bug report: Attempting to do either a hard reset or a soft reset while
no game is loaded will crash bsnes, at least under Windows XP Pro SP2.
Maybe you'll want to grey out those options while no game is loaded. |
Confirmed here.
Is it possible to display the chosen resolution of a given Video
Profile on the profile select menu? This may help users remember what
each of their profiles is.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Mon Apr 24, 2006 1:33 am Post subject: |
|
byuu wrote: |
Quote: |
bcpu.cpp.patch updates the open bus value in mem_write. It also has changes for irq/nmi/power/reset. |
Ah, maybe that'll fix Captain America. I can't wait to get that fixed so I can delete it. Bad, bad game.
|
The game still did not work the last time I tried it.
Quote: |
Quote: |
cart.cpp.patch
changes the checksum scoring to allow Choujikuu Yousai Macross to work.
If the graphics are corrupted, deinterleave the rom with NSRT. |
Holy crap, the graphics were corrupted because I was detecting the
header from the wrong place?! Geez, that's absolutely wild that it
worked at all. I take it the game mirrors its header to both $7fc0 and
$ffc0?
|
The corruption is caused by having an interleaved rom. The header is
not mirrored, but the lorom header has a checksum of 0000/FFFF. The
patch causes checksum values of zero to be treated as invalid.
Quote: |
Quote: |
op_pc.b.patch fixes the timing of rti. |
I've tested this extensively. I'll have to look very closely at your timing fixes.
|
The rti code was not calling last_cycle() in emulation mode, so I fixed it.
Quote: |
I'll
see what I can do, thanks for the heads up. I'm holding off on the
stack over/underflow cases, as they are quite bizarre and will take
some effort. |
They are actually fairly simple once you understand them. You will need four new stack functions:
Code: |
uint8 bCPU::stack_read() {
if(regs.e) {
regs.s.l++;
} else {
regs.s.w++;
}
return mem_read(regs.s);
}
uint8 bCPU::stack_read_new() {
regs.s.w++;
return mem_read(regs.s);
}
uint8 bCPU::stack_read_new_end() {
regs.s.w++;
uint8 r = mem_read(regs.s);
if(regs.e) regs.s.h = 1;
return r;
}
void bCPU::stack_write(uint8 value) {
mem_write(regs.s, value);
if(regs.e) {
regs.s.l--;
} else {
regs.s.w--;
}
}
void bCPU::stack_write_new(uint8 value) {
mem_write(regs.s, value);
regs.s.w--;
}
void bCPU::stack_write_new_end(uint8 value) {
mem_write(regs.s, value);
if(regs.e) {
regs.s.l--;
regs.s.h = 1;
} else {
regs.s.w--;
}
}
|
Use the "new" functions for each stack access, and the "new_end"
functions for the last stack access of each opcode. If there is only
one stack access in the opcode, just use the "new_end" function. Only
opcodes that are new to the 65816 (not 6502 or 65C02) need to be fixed:
JSL; JSR (a,x); PEA; PEI; PER; PHD; PLD; RTL. PHB, PHK, PLB are not in
ob-wrap.txt, but they are 65816-only so they should also be fixed. The
stack relative mem modes are already correct in bsnes.
Also:
Win9x support: http://www.catch22.net/source/files/TransparentWindow.c
D3DX9 problems: http://www.toymaker.info/Games/html/d3dx_dlls.html
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Apr 24, 2006 5:20 am Post subject: |
|
King Of Chaos wrote: |
Jipcy wrote: |
You can also get it from Microsoft here.
|
Unfortunally I've done all that, and I still can't use D3DX9 for this...
|
What video card are you using? If you are using integrated graphics...
then don't expect DX9 to help you much... if anything.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 24, 2006 5:37 am Post subject: |
|
Thank you all for helping me beta test.
I'll let you all be the first to try the final build of bsnes v0.016.
[files deleted]
I ask that no emulation news sites post links to these files, please. I
am waiting on the files to be mirrored by Nach, at that time I will
update my website with a changelog and links to the files.
The immediate changes are that I corrected the crash on reset/power,
added most of DMV27's changes (the interrupt-related ones I want to
test myself on hardware before committing), added DMV27's notes on
CGRAM/OAM latches, and added a quick menu link to the cheat code editor.
I wasn't able to find anything that all of the emulation-level changes
fixed. Only newly fixed game is Chou Jikuu Yousai Macross, due to the
header detection fix. Please let me know if the new changes break (or
fix) anything.
Edit by Nach:
Download bsnes 0.16 from http://nsrt.edgeemu.com |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 24, 2006 7:40 am Post subject: |
|
No, thank YOU! This turned out to be a monster release over .015!
One thing that did get "fixed" that I never commented on, was that
removing the transparency also cured the massive slowdown during
emulation while the config menu was up. Guess that thing was pretty
intensive Yay.
Semi-bug report (more aesthetic than anything): using the cheat code
editor quick link will bring up the config menu, but the highlighted
section will be where it last was, possibly not cheat editor.
I've updated the buglist a little to note strange regional findings. I
did this after discovering two more since Mortal Kombat: RPM Racing (J)
actually draws the track correctly, and Earthworm Jim 2 (E) still
exhibits sound issues despite DMV27s recent sound fixes that seem to
have fixed the (U) version. Wierdness.
But now I'm off to enjoy this.  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Apr 24, 2006 9:33 am Post subject: |
|
Hi, bsnes released on my site, have fun.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Mon Apr 24, 2006 11:59 am Post subject: |
|
Does it work in Win98 yet ???? |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 24, 2006 2:46 pm Post subject: |
|
It should work with win98. Let me know if it doesn't.
I built against the win95 APIs and dynamically mapped the translucency
call, it will fail safely if on WinME or older. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Apr 24, 2006 4:05 pm Post subject: |
|
Is there any case when using system RAM would be faster than video RAM? What are the RAM requirements for bsnes?
"Correct aspect ratio" makes the render width be 4/3 the render height,
right? Not the render height be 3/4 the render width?
"Bug" reports:
1. Requesting a manual render height of 22 pixels or less will give an
error "Failed to create Direct3D9 device". If a game is loaded when you
request this render height, or you load a game after setting it, bsnes
will crash.
44 pixels is the smallest render height that will display video. bsnes
can render any requested render width, without crashing.
2. Requesting an invalid (or unsupported) fullscreen refresh rate and/or resolution:
- While a game is not loaded: You can go into and out of full screen
without a crash, however, you can only use ESC to leave full screen.
Pressing F11 does nothing.
- While a game is loaded: bsnes will enter full screen, but will not
render anything. Pressing ESC will crash bsnes. Pressing F11 has no
effect.
3. Full screen resolution of 320x240 works for me, although the
rendered video is somewhat messed up. This resolution is not listed as
a supported resolution for my video card. Few modern video cards
support full screen 320x240 resolution, as far as I know.
4. Setting a multiplier that causes the rendered screen size to be
larger than the full screen resolution results in no video (but sound
continues).
5. Some very weird things happen if you set the default windowed and
full screen profiles to the same profile, then check the Fullscreen
box, then Apply Settings. For example, it's impossible to escape full
screen at that point. You can alt-tab out, then go back to the Config
dialog, uncheck Fullscreen, then click Apply Settings, but then you get
"Failed to create Direct3D9 device".
6. Select Misc->Cheat Code Editor. Close the Config dialog. Select
Settings->Configuration. Configuration page is still Cheat Code
Editor. Furthermore, as mentioned above, the highlighted page on the
left side of the Config dialog does not correctly reflect the displayed
Config page.
7. In the config file, are the video.filter.software and
video.filter.hardware variables depracated? Or are these used for
DirectDraw rendering?
"Feature" requests:
1. Can you set a tab order so that you can tab between fields in the configuration screen?
2. You will probably already be taking care of this if/when you do the
simple/advanced configuration modes, but should you grey-out (ghost,
make unselectable) the Render width and height fields while "Manual
render screen size" is unchecked? And, when checked, should the
multiplier and correct aspect ratio boxes be greyed-out?
3. I don't think there should be default windowed/fullscreen profile
selections. I know it confuses me, and probably confuses others. If I
want to use different settings for windowed vs. fullscreen, I'll just
configure two different video profiles, then switch between profiles as
desired. F11 should attempt to use the current active
profile settings for full screen, NOT the settings of the default full
screen profile. Pressing ESC should return the user to the windowed
settings of the current active profile, NOT the settings of the default
windowed profile.
4. Alt+Enter is a much more
common key combination for entering/exiting full screen than F11. Is it
possible you can add this?
5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active.
6. If "Half Gamma Adjust" is in fact less accurate to a real SNES, can you please not enable it by default?
(Edited for correctness, after further research.)
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Mon Apr 24, 2006 9:38 pm Post subject: |
|
Ah v0.16 is out. Dl now, I'll test it as soon as I've got the time for it.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Tue Apr 25, 2006 1:27 am Post subject: |
|
King Of Chaos wrote: |
djohnson wrote: |
Does it work in Win98 yet ???? |
Get with the times.
|
I ask a simple question and all the trolls come out to play
I am up with the times but i don't like XP i prefer Win98 so no problem
|
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Apr 25, 2006 1:54 am Post subject: |
|
djohnson wrote: |
King Of Chaos wrote: |
djohnson wrote: |
Does it work in Win98 yet ???? |
Get with the times.
|
I ask a simple question and all the trolls come out to play
I am up with the times but i don't like XP i prefer Win98 so no problem
|
The question, rather, is, does it work in Windows 98? If you are using
Windows 98, please try out the program, and tell us if it works.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 25, 2006 2:18 am Post subject: |
|
Quote: |
Is there any case when using system RAM would be faster than video RAM? What are the RAM requirements for bsnes? |
It's a bad idea, and causes failure when on a 32-bpp desktop. It's
almost always much slower, especially when scaling video.
Quote: |
"Correct aspect ratio" makes the render width be 4/3 the render height, right? Not the render height be 3/4 the render width? |
Yes. Height is kept at a multiple of 224 to keep scanlines looking decent.
Quote: |
1.
Requesting a manual render height of 22 pixels or less will give an
error "Failed to create Direct3D9 device". If a game is loaded when you
request this render height, or you load a game after setting it, bsnes
will crash.
44 pixels is the smallest render
height that will display video. bsnes can render any requested render
width, without crashing.
2. Requesting an invalid (or unsupported) fullscreen refresh rate and/or resolution:
- While a game is not loaded: You can go into and out of full screen
without a crash, however, you can only use ESC to leave full screen.
Pressing F11 does nothing.
- While a game is loaded: bsnes will enter full screen, but will not
render anything. Pressing ESC will crash bsnes. Pressing F11 has no
effect.
3. Full screen resolution of 320x240 works for me, although the
rendered video is somewhat messed up. This resolution is not listed as
a supported resolution for my video card. Few modern video cards
support full screen 320x240 resolution, as far as I know.
4. Setting a multiplier that causes the rendered screen size to be
larger than the full screen resolution results in no video (but sound
continues).
5. Some very weird things happen if you set the default windowed and
full screen profiles to the same profile, then check the Fullscreen
box, then Apply Settings. For example, it's impossible to escape full
screen at that point. You can alt-tab out, then go back to the Config
dialog, uncheck Fullscreen, then click Apply Settings, but then you get
"Failed to create Direct3D9 device". |
Do I really need to stupid-proof the emulator? I assume most of these
issues won't affect anyone half intelligent. I guess I can work at it.
Quote: |
6.
Select Misc->Cheat Code Editor. Close the Config dialog. Select
Settings->Configuration. Configuration page is still Cheat Code
Editor. Furthermore, as mentioned above, the highlighted page on the
left side of the Config dialog does not correctly reflect the displayed
Config page. |
It's designed to save the last page you were on. Closing the window in
reality only hides it. I didn't think making it select the right list
option was important enough to hold up a release, but it'll get fixed.
Quote: |
7.
In the config file, are the video.filter.software and
video.filter.hardware variables depracated? Or are these used for
DirectDraw rendering? |
I should be able to remove those now, thanks for mentioning them.
Quote: |
1. Can you set a tab order so that you can tab between fields in the configuration screen? |
If I knew how I would. I set WS_TABSTOP and all the required flags, but tabs never work for me.
Quote: |
2.
You will probably already be taking care of this if/when you do the
simple/advanced configuration modes, but should you grey-out (ghost,
make unselectable) the Render width and height fields while "Manual
render screen size" is unchecked? And, when checked, should the
multiplier and correct aspect ratio boxes be greyed-out? |
Yep, in due time.
Quote: |
3.
I don't think there should be default windowed/fullscreen profile
selections. I know it confuses me, and probably confuses others. If I
want to use different settings for windowed vs. fullscreen, I'll just
configure two different video profiles, then switch between profiles as
desired. F11 should attempt to use the current active
profile settings for full screen, NOT the settings of the default full
screen profile. Pressing ESC should return the user to the windowed
settings of the current active profile, NOT the settings of the default
windowed profile. |
Well I disagree, but I'll think about it.
Quote: |
4. Alt+Enter is a much more common key combination for entering/exiting full screen than F11. Is it possible you can add this? |
Nope, windows is a bitch about letting the application see when the alt
key was pressed. With the new key input detection being tied to
DirectInput, I can't get the state of the alt key, and still let the
menu bar function normally.
Quote: |
5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active. |
And why would it?
Quote: |
6. If "Half Gamma Adjust" is in fact less accurate to a real SNES, can you please not enable it by default? |
It's a gamma adjustment, it depends on your monitor if it's more or
less accurate to an SNES game on your television. Personally, I like
the way it looks, so it stays on. Takes a few seconds to uncheck.
Thanks for the feedback, I'll improve what I can.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Apr 25, 2006 2:42 am Post subject: |
|
Thumb up on the 0.16 release 
Just a question: I tried various settings but I can't seem to achieve
the same display as I get with 0.15 RC1. (that I absolutely love)
edit: Never mind,problem solved.
Last edited by Dmog on Tue Apr 25, 2006 3:31 am; edited 3 times in total |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Apr 25, 2006 3:03 am Post subject: |
|
byuu wrote: |
Do
I really need to stupid-proof the emulator? I assume most of these
issues won't affect anyone half intelligent. I guess I can work at it. |
Depends. Do you want bsnes to be a general-purpose SNES emulator (with
the obvious caveats of not including special chip support)?
Then you probably need to check for (close to) edge cases that can
crash the emulator. Nobody likes a program that crashes as a result of
normal user input.
Some of these crash-inducing conditions could be avoided with fewer
options. For example, enumerating resolution and refresh rate choices
with only those reported as supported by the video card.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
Last edited by Jipcy on Tue Apr 25, 2006 3:08 am; edited 1 time in total
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Apr 25, 2006 3:03 am Post subject: |
|
Double post sorry. Doh again...Wanted to edit my previous post. |
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Tue Apr 25, 2006 3:11 am Post subject: |
|
Thank
you it works on Win98 and a quick bug Adventures of Dr. Franken, The
(E) on the title screen there is a glitchy line through the middle of
the screen
does not happen in the (U) version |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Apr 25, 2006 3:24 am Post subject: |
|
Sorry if this is a known issue.
I know triple buffering is considered "buggy" for now, but I still
experience tearing even when it's set to 'true'. Does anyone else
experience that? edit: Works for me in window mode but not fullscreen
for some reason.. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Apr 25, 2006 5:22 am Post subject: Donkey Kong Country bug report |
|
Question:
Are software filters applied before or after Aspect Correct? I would
suspect after, since I guess both Multiplier and Aspect Correction are
easy options for changing the render size, and that software filters
need to have a minimum of 2x render size to be effective. Anyway, I was
just wondering if there is perhaps any merit (visible difference) in
applying software filters before aspect correction?
Also, is there any chance of a Recent Files list being added to the File menu?
Bug report:
I'm not sure if this has been reported before, but the Nintendo logo on
the startup screen for Donkey Kong Country is only half-width when
using the Scale2x filter and 2x multiplier. It also affects DKC 2. No
other software filters have this problem.
byuu wrote: |
Quote: |
5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active. |
And why would it?
|
Semi-standard dialog behavior.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Apr 25, 2006 12:38 pm Post subject: |
|
byuu wrote: |
Quote: |
4. Alt+Enter is a much more common key combination for entering/exiting full screen than F11. Is it possible you can add this? |
Nope, windows is a bitch about letting the application see when the alt
key was pressed. With the new key input detection being tied to
DirectInput, I can't get the state of the alt key, and still let the
menu bar function normally.
|
Care to elaborate? I don't follow. I've written D3D/DirectInput
applications before that use Alt-Enter to switch between fullscreen and
window mode.
_________________
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.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Apr 25, 2006 12:50 pm Post subject: |
|
Just a heads up:
I updated the source archive on my site.
The SDL Makefile can now be used to compile on BSD, or on Linux if you change sdl11-config to sdl-config.
I also compressed the source archive better.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 25, 2006 3:15 pm Post subject: |
|
Thanks. So then it builds ok? Neat.
Do you know an easy way to use a single define that will toggle the
inclusion of entire object files in the Makefile, and still work in the
C source files, that works with both windows make and gcc make?
If so, I'll make all of the video/audio/input renderers optional in
preparation for merging the src/win port with the src/sdl port. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Apr 25, 2006 3:34 pm Post subject: |
|
byuu wrote: |
Thanks. So then it builds ok? Neat.
|
Now it does, yes.
byuu wrote: |
Do you know an easy way to use a single define that will toggle the
inclusion of entire object files in the Makefile, and still work in the
C source files, that works with both windows make and gcc make?
|
Elaborate.
BTW, I spend today making you a new unified Makefile.
It has the following options:
linux
freebsd
win-msvc
win-msvc-sdl
win-mingw
win-cross
It's not quite working yet, but it's getting there.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Ichinisan Zealot

Joined: 28 Jul 2004
Posts: 1336
|
Posted: Tue Apr 25, 2006 6:27 pm Post subject: Re: Donkey Kong Country bug report |
|
Jipcy wrote: |
byuu wrote: |
Quote: |
5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active. |
And why would it?
|
Semi-standard dialog behavior.
|
VERY established standard dialog behavior.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Apr 25, 2006 6:43 pm Post subject: Re: Donkey Kong Country bug report |
|
Ichinisan wrote: |
Jipcy wrote: |
byuu wrote: |
Quote: |
5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active. |
And why would it?
|
Semi-standard dialog behavior.
|
VERY established standard dialog behavior.
|
Yup. Standard message dialogs have that feature built-in, and other windows (forms) need just a few lines of code.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Tue Apr 25, 2006 8:13 pm Post subject: |
|
Hey,
does anyone here have all the older versions of bsnes and its source
code available online for download? Since I haven't been a bsnes user
since the very beginning, I was just a little curious about bsnes'
history and how much it has progressed since the first version.
BTW, how is BPF coming along? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Apr 25, 2006 9:08 pm Post subject: |
|
Update on unified makefile.
I had to add some #defines in a few places to keep MinGW happy.
So far I tested:
linux
win-cross
Works like a charm.
I'm guessing:
freebsd
win-mingw
Would work great too.
These:
win-msvc
win-msvc-sdl
Definitly need testing.
I want to clean these up a bit though.
byuu, I can also make a batch file menu to pass all the various options if you want.
_________________
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 Tue Apr 25, 2006 9:47 pm; edited 1 time in total |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Apr 25, 2006 9:09 pm Post subject: |
|
Did any of my earlier input reach deaf's ears or something? 
_________________
FF4 research never ends for me. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue Apr 25, 2006 10:42 pm Post subject: |
|
Dmog wrote: |
Sorry if this is a known issue.
I know triple buffering is considered "buggy" for now, but I still
experience tearing even when it's set to 'true'. Does anyone else
experience that? edit: Works for me in window mode but not fullscreen
for some reason.. |
Probably because the SNES runs at 60.09FPS and your monitor runs at 60.00FPS. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Apr 26, 2006 12:05 am Post subject: |
|
Okay got new unified makefile cleaned up, it seems to work nicely in my tests. 
_________________
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: Wed Apr 26, 2006 4:41 am Post subject: |
|
King Of Chaos wrote: |
Dmog wrote: |
Sorry if this is a known issue.
I know triple buffering is considered "buggy" for now, but I still
experience tearing even when it's set to 'true'. Does anyone else
experience that? edit: Works for me in window mode but not fullscreen
for some reason.. |
Probably because the SNES runs at 60.09FPS and your monitor runs at 60.00FPS.
|
So it does work for you in full screen? (i.e no tearing)
I think byuu mention it's actually variable, it doesn't always run at
60.09FPS..but that's not the point.Afaik, triple buffering doesn't need
to be matched with an exact refresh to remove potential screen tearing.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Apr 26, 2006 11:56 am Post subject: |
|
Dmog, try setting frameskip to 1, seems to help for me
Byuu, are you using the latest NTSC filter?? it doesnt seem like it,
the newest version is a lot faster and offers several options of quality
http://www.slack.net/~ant/libs/ntsc.html#snes_ntsc
Also, when the configuration screen is open, and i switch to
fullscreen, i get stuck the only thing that i can do is ALT+F4 or
ALT+TAB and then kill the application |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 26, 2006 3:21 pm Post subject: |
|
Deathlike2, not ignoring you, just horribly limited for time. I like the set ROM path on ROM load idea.
NTSC filter is the latest version. If you aren't running at 60hz, edit
the config file and changes snes.filter.ntsc.merge_fields (or whatever
it is, just search for merge_fields) from false to true, and it won't
bounce around. That should've been left as true for an official
release, oh well.
Quote: |
Also,
when the configuration screen is open, and i switch to fullscreen, i
get stuck the only thing that i can do is ALT+F4 or ALT+TAB and then
kill the application |
No idea why. I'll close it when you go fullscreen, then.
I have as old as bsnes v0.0.002 ir11 stored away somewhere.
BPF became UPS. It's waiting on libraries and utilities to go live. The
spec is pretty much finalized in src/libbpf.cpp, but the source needs
to be rewritten as libups.cpp, and the code needs to be cleaned up.
Quote: |
Yup. Standard message dialogs have that feature built-in, and other windows (forms) need just a few lines of code. |
Fine, fine.
Quote: |
Care
to elaborate? I don't follow. I've written D3D/DirectInput applications
before that use Alt-Enter to switch between fullscreen and window mode. |
Sure, alt+<key> combinations are sent as WM_SYSKEY(UP|DOWN)
messages. I use a 50ms timer that polls the keyboard and joypad, and
looks for keys that weren't down but now are, or that were down but now
aren't, and sends the appropriate message to my window event handler.
It does receive alt, when pressed, but it does not detect when enter is
pressed once alt is down.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Wed Apr 26, 2006 8:54 pm Post subject: |
|
Bug report (I don't see it on the first page)
In Tales of Phantasia (J)


After you win the battle:notice the purple in the second pic, it's
looks like the dark green in the forest is replaced by this color
Used bsnes 0.16. I'm pretty sure this doesn't happen on Z. Someone
could probably check if it happens or not on real hardware.
edit: crap...The image doesn't show up anymore..I guess imageshack is overloaded or something.
Last edited by Dmog on Wed Apr 26, 2006 10:15 pm; edited 3 times in total |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Wed Apr 26, 2006 9:01 pm Post subject: |
|
tetsuo55 wrote: |
Dmog, try setting frameskip to 1, seems to help for me |
tetsuo, I started to experience some really weird issues after I
updated directx, so I'm pretty sure that's the cause of the problem
actually.
Just another example: Since I updated directx, Nestopia has been running like three times the normal speed (and I haven't played with the settings or anything like that) Weird.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Thu Apr 27, 2006 2:01 am Post subject: |
|
Here are a few minor fixes which fix at least one game.
65816:
In emulation mode, the IRQ/NMI vectors are not correct (native mode
vectors are always being used). They should be 0xfffe/0xffee and
0xfffa/0xffea.
PPU:
In "bPPU::is_sprite_on_scanline", the first line of code is
"if(spr->x > 256 && (spr->x + spr->width) <
512)return false;". The last part should be "<= 512" because an 8
width sprite at x=504 is still off-screen.
In bppu_mmio.cpp, r213e updates ppu1_mdr and r213f updates ppu2_mdr. Is
this correct? ob-wrap.txt does not list these regs as updating the ppu
mdr.
SPC700:
"mov_sp_x(0xbd, sp, x)" should not be setting the N/Z flags.
SDSP:
In "bDSP::read", the PITCH is being returned wrong (the low/high bytes
are swapped). Fixing this will fix Battletoads in Battlemaniacs. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 27, 2006 7:11 am Post subject: |
|
DMV27 wrote: |
Here are a few minor fixes which fix at least one game. |
Hooray, thank you! :D
Quote: |
65816:
In emulation mode, the IRQ/NMI vectors are not correct (native mode
vectors are always being used). They should be 0xfffe/0xffee and
0xfffa/0xffea. |
I noticed that, just apathy on my part... fixed.
Quote: |
PPU:
In "bPPU::is_sprite_on_scanline", the first line of code is
"if(spr->x > 256 && (spr->x + spr->width) <
512)return false;". The last part should be "<= 512" because an 8
width sprite at x=504 is still off-screen. |
Nice catch. Fixed.
Quote: |
In
bppu_mmio.cpp, r213e updates ppu1_mdr and r213f updates ppu2_mdr. Is
this correct? ob-wrap.txt does not list these regs as updating the ppu
mdr. |
Yes, it is. It was extremely difficult to test, too. $213e is STAT77,
which reports the status and version number of the PPU1 chip, $213f is
STAT78, which reports the status and version number of the PPU2 chip.
I forget how I tested $213e (only that I did), but I remember $213f because it was particularly difficult.
Here's what I did: CGRAM entries are 15-bits, when you read the low
value, you get all 8 bits, but when you read the high value, you only
get the low 7 bits. The top bit is PPU2 open bus. Therefore, what I did
was set $2121, then read from $213b, so the next CGRAM read would have
the high bit as open bus. I then read from $213f until bit 7
transistioned from 1 to 0 ($213f.d7 is the interlace field bit). I then
loaded A with #$ff, and read from $213b. I got the low 7 bits of the
palette, and the top bit was clear.
I did the reverse, waited for $213f.d7 to transistion from 0->1, set
a to #$00, then read from $213b. Yep, now the top bit was set. The
CGRAM entry was #$7fff for both tests.
It seems easy when you know how to test for it, but it was quite difficult to think that test up :/
Now what I'm curious about is what happens for PPU1/2 writes to
$2100-$2133? Do they update the PPU MDRs like CPU writes do?
Quote: |
SPC700:
"mov_sp_x(0xbd, sp, x)" should not be setting the N/Z flags. |
Whoops, same thing in the CPU core, too. Fixed.
Quote: |
SDSP:
In "bDSP::read", the PITCH is being returned wrong (the low/high bytes
are swapped). Fixing this will fix Battletoads in Battlemaniacs. |
Hahah, how'd that go unnoticed for so long by myself? Fixed. Battletoads sounds great now.
The source was getting kind of cramped with all of anomie's old S-DSP
code commented out and replaced. Since he hasn't been around for so
long, I finally caved and pulled all of the old dummied out code from
the core, and cleaned things up while I was at it. Hopefully I didn't
mess anything up in the process :)
We still have v0.016 as a reference, and I'm going to make a text
document for when/if he gets back of all changes we make in the mean
time.
As always, thanks a million. Your help is absolutely invaluable. Please
let me know if there's any way I can return the favor.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 28, 2006 6:55 am Post subject: |
|
New stuff.
Optimized the PPU BG renderer a tad. I literally stared at the ~5 pages
of code for over 8 hours and only found three or four spots to
optimize. Not much of a speed difference, but eh.
Went ahead and enforced render width/height to be no less than 256x224.
Now accept 0x0 resolution width/height as "use current screen size",
much like how a resolution of 0 results in using the current refresh
rate.
Removed two profiles to give 8 total profiles. I did this so there is
no profile 0-9 / 1-0 confusion (thank you, jackass who invented QWERTY
for placing the 0 after the 9, instead of before the 1). Now there are
profiles 1-8, and CTRL+[1-8] sets each mode.
By suggestion, there's no longer a fullscreen checkbox, nor default
windowed/fullscreen mode selections. You now just specify the
resolution info for each mode and hit F11 to go fullscreen. When you
exit and restart, you always begin in windowed mode with the last used
profile.
I think I'll make left ctrl+[1-8] set profile [1-8] windowed, and right
ctrl+[1-8] set profile [1-8] fullscreen. Sound good? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Apr 28, 2006 7:16 am Post subject: |
|
byuu wrote: |
Went ahead and enforced render width/height to be no less than 256x224. |
It's
probably better that way. But, a few people may have legitimate reasons
for running at LESS than native resolution. I am interested to know why
bsnes could successfully render video all the way down to 0 horizontal
resolution, but failed at less than 22 vertical resolution?
For example, I would like to be able to render video at less than
native resolution to see what it might theoretically look like to play
an emulated SNES game full screen on a Gameboy Advance or Nintendo DS.
Quote: |
Now
accept 0x0 resolution width/height as "use current screen size", much
like how a resolution of 0 results in using the current refresh rate. |
Constistency is always good.
Quote: |
Now there are profiles 1-8, and CTRL+[1-8] sets each mode. |
Why remove 9? It's sequential with the rest of them. 0 is the only one out of place.
Quote: |
By
suggestion, there's no longer a fullscreen checkbox, nor default
windowed/fullscreen mode selections. You now just specify the
resolution info for each mode and hit F11 to go fullscreen. When you
exit and restart, you always begin in windowed mode with the last used
profile. |
Thank
you very much for this! It's a much more intuitive behavior in my
opinion, and is more consistent with the behavior of other
emulators/programs.
Quote: |
I think I'll make left ctrl+[1-8] set profile [1-8] windowed, and right ctrl+[1-8] set profile [1-8] fullscreen. Sound good? |
As long as it's documented. Perhaps you can start including a small file listing the default keyboard shortucts?
If you don't want to write it yourself, I could write some simple
documentation for your emulator. Do prefer a specific format? I can do
plaintext and html.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 28, 2006 7:26 am Post subject: |
|
Quote: |
It's
probably better that way. But, a few people may have legitimate reasons
for running at LESS than native resolution. I am interested to know why
bsnes could successfully render video all the way down to 0 horizontal
resolution, but failed at less than 22 vertical resolution? |
I don't know. Maybe something to do with the titlebar. I'll see if I
can get it working at < 256x224. It stuck at 256x224 even when I
tried 64x56, so meh.
To emulate the SNES as though it were on a GBA I'd need something like
screen border clipping. It'd be good to simulate the ~16 or so pixels
on all sides that TVs chop off, so maybe I'll add that in sometime.
Quote: |
Why remove 9? It's sequential with the rest of them. 0 is the only one out of place. |
Because I like even numbers.
Quote: |
If you don't want to write it yourself, I could write some simple documentation for your emulator. |
Thanks, but I'll make a readme file shortly.
---------------------------
Ok, can anyone with programming experience and familiarity with the
concept of cooperative multithreading and coroutines take a look at
this?
http://byuu.cinnamonpirate.com/temp/state.txt
This is a mockup of the state machine wrapper I'm thinking of using for
bsnes to remove the current switch/case tables all over the place, and
to allow r_cpu->run() to be "reentrant", without requiring true
platform-specific reentrant code. It doesn't really simulate
coroutines, it instead simulates a stack (which is just a FILO buffer
of states), and the thread suspend function really just sets a new
state to occur immediately after the return that is added before it.
The entirity of the fine details have not been worked out, hence the
mockup. I'll probably have to use global/static variables, and
something a little different for any for loops. Real subroutine calls
should be fine, so long as suspend() isn't called within any actual
subroutines.
In the actual implementation, I'd either use a precompiler to add some
clarity that #define macros simply can't handle (such as generating the
case numbers), or use some really evil tricky macros (eg with __LINE__
thrown all around and such) to avoid the use of a precompiler.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Apr 28, 2006 7:56 am Post subject: |
|
byuu wrote: |
To
emulate the SNES as though it were on a GBA I'd need something like
screen border clipping. It'd be good to simulate the ~16 or so pixels
on all sides that TVs chop off, so maybe I'll add that in sometime. |
With v0.016 as it is, I already CAN see what it might look like on a
GBA or DS screen. I hadn't really thought D3D capabale of scaling to
less than the original resolution, but apparently it can. The scaling
would be 240x160 (3:2) for the GBA, and 256x192 (4:3) for the DS.
EDIT: I was going to mention, do you think there is any way we can give
custom names to the profiles and have them show up in the seleciton
menu(s)? Obviously, they could be character-limited. It would really
help to remember what each profile was.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Apr 28, 2006 4:54 pm Post subject: |
|
byuu,
(or someone with a real ToP cart or a copier) could you confirm if the
Tales of Phantasia bug I posted on page29 happens on real hardware?
It's about two to three minutes from the beginning. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 29, 2006 1:42 am Post subject: |
|
Yeah,
I think byuu only has a super UFO, which is 32mbit IIRC. Someone else
will have to test, because it's too slight of an anomaly to assume it's
an emulator bug. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Apr 29, 2006 7:50 am Post subject: |
|
i cannot test TOP either, only 32mbit, we would need to find someone with a super wildcard DX2 with the 64 mbit upgrade |
|
snkcube Hero of Time

Joined: 30 Jul 2004
Posts: 3592
Location: In front of the monitor
|
Posted: Sat Apr 29, 2006 8:26 am Post subject: |
|
Grinvader has ToP on the real hardware. Maybe he can confirm the bug.
_________________
Try CCleaner
 |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Apr 29, 2006 9:56 am Post subject: |
|
Let me hook it up. I didn't notice anything like it, but checking twice is always good.
After all I saw that this...

... was in the real thing after spending several hours in the game (had
to grab origin to trigger it... - also I'm not talking about the
garbage on the first line, just all the weird 8x8 tiles).
Edit: this purplish background seems to be a bug. At least I couldn't make it appear after a dozen battles.
_________________
皆黙って俺について来い!!
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: Sat Apr 29, 2006 8:04 pm Post subject: |
|
K, I've added it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 29, 2006 9:27 pm Post subject: |
|
I
have the actual ToP cartridge. I'll compare the two later on. No idea
what could be causing that, and it would be quite hard to track
something like that down.
Jurassic Park 2 is
another game that needs to be added. It freezes before the intro starts
playing, unless you press start quickly.
I don't know if Super Conflict was tested on hardware before or not,
but I'm missing the same tile that Overload is (the smaller 's') on the
title screen.
We also might want to sort the bugs based on their severity, too. Maybe
come up with two or three categories for bugs. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 30, 2006 2:41 am Post subject: |
|
Wow,
you're right. Didn't notice that small c was screwed up. I've added it
for now, since it seems to be a genuine bug (zsnes screws up on the
same text, but worse. It chops off the sides.) Added Jurassic Park II
also. I do hope more people start reporting bugs for bsnes if they find
them. I'm more than happy to maintain an accurate list. As for the
severity classifications - I dunno, that might be kind of hard. For
example, the Jurassic II bug is a show-stopper, but it can be easily
prevented and doesn't affect gameplay. Kind of subjective to determine
the severity. |
|
Narf New Member
Joined: 30 Apr 2006
Posts: 2
|
Posted: Sun Apr 30, 2006 7:39 am Post subject: Some Bugs |
|
Here are some bugs I have come across thus far (using bsnes 0.016):
All names are taken from GoodSNES.
Games that have a black sreen at startup and go no further:
Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J)
Chou Aniki - Bakuretsu Rantouden (J)
Derby Stallion 96 (J)
Destructive (J)
Final Stretch (J) [!]
Gamars Puzzle (Unl)
Habu Meijin no Omoshiro Shougi (J) [!]
Hashiriya Tamashii - Rider's Spirits (J)
Hayashi Kaihou Kudan no Igo Oodou (J)
Killer Instinct (Beta 8MB)
Killer Instinct (Beta)
Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J)
Other Bugs:
Ballz 3D (U) [!] - When gets to PF Magic Screen at start up stops with different colored lines flickering on screen.
Battle Racers (J) - Black Screen after initial Banpresto screen. Goes no further.
Corn Buster (E) - When you first start the game and are on map screen, as soon as you move it freezes.
Death Brade (J) - When you start a fight it says time over straight
away and you lose. Does not happen in ZSNES V1.41.
Hope this helps.
I'll report more as I find them. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 30, 2006 9:15 am Post subject: Re: Some Bugs |
|
Narf wrote: |
Here are some bugs I have come across thus far (using bsnes 0.016):
All names are taken from GoodSNES.
Games that have a black sreen at startup and go no further:
Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J)
Chou Aniki - Bakuretsu Rantouden (J)
Derby Stallion 96 (J)
Destructive (J)
Final Stretch (J) [!]
Gamars Puzzle (Unl)
Habu Meijin no Omoshiro Shougi (J) [!]
Hashiriya Tamashii - Rider's Spirits (J)
Hayashi Kaihou Kudan no Igo Oodou (J)
Killer Instinct (Beta 8MB)
Killer Instinct (Beta)
Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J)
Other Bugs:
Ballz 3D (U) [!] - When gets to PF Magic Screen at start up stops with
different colored lines flickering on screen.
Battle Racers (J) - Black Screen after initial Banpresto screen. Goes no further.
Corn Buster (E) - When you first start the game and are on map screen, as soon as you move it freezes.
Death Brade (J) - When you start a fight it says time over straight
away and you lose. Does not happen in ZSNES V1.41.
Hope this helps.
I'll report more as I find them. |
Thanks, but maybe I should have been more specific. If you guys want to
report bugs, please use NSRT for its more accurate names and database
and make sure that under "type" the game does not utilize a special
chip. You'll see that most of these games are not bugs, but unsupported
hardware.
Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J) - SA-1
Chou Aniki - Bakuretsu Rantouden (J) - confirmed
Derby Stallion 96 (J) - confirmed
Destructive (J) - works for me
Final Stretch (J) - DSP-1
Gamars Puzzle (Unl) - no idea what this is
Habu Meijin no Omoshiro Shougi (J) - SA-1
Hashiriya Tamashii - Rider's Spirits (J) - DSP-1
Hayashi Kaihou Kudan no Igo Oodou (J) - SA-1
Killer Instinct (Beta 8MB) - not in NSRT
Killer Instinct (Beta) - confirmed
Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J) - SA-1
Ballz 3D (U) - DSP-1
Battle Racers (J) - DSP-1
Corn Buster (E) - confirmed
Death Brade (J) - already in the list on page 1 of this thread
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Apr 30, 2006 9:21 am Post subject: Re: Some Bugs |
|
FitzRoy wrote: |
Killer Instinct (Beta 8MB) - not in NSRT
|
It's an underdump, it shouldn't work.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 30, 2006 9:22 am Post subject: |
|
KI beta 8mb is a useless underdump that only someone as special as Cowering would index. Hey, gotta collect 'em all, right?
Derby Stallion '96 is one of those fun carts with the BS-X flashcart
ports on top of the cartridge. It probably fails due to the generic
memory mapper I use, but I could be wrong.
Thanks for the other reports. I'll try and make v0.017 and above give
error messages when unsupported special chip games are loaded. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon May 01, 2006 5:46 am Post subject: |
|
byuu wrote: |
Derby Stallion '96 is one of those fun carts with the BS-X flashcart
ports on top of the cartridge. It probably fails due to the generic
memory mapper I use, but I could be wrong. |
Wierd. So I should remove it?
byuu wrote: |
Thanks for the other reports. I'll try and make v0.017 and above give
error messages when unsupported special chip games are loaded. |
A splendid idea.
|
|
Narf New Member
Joined: 30 Apr 2006
Posts: 2
|
Posted: Mon May 01, 2006 12:10 pm Post subject: |
|
Using Bsnes V0.016 with no graphical filters applied.
Small graphical bug in Bugs Bunny - Rabit Rampage (E) (Also appears in (J))
On the first level on the first screen there are several white tiles
that seem to be out of place, hard to miss (I tried to capture
screenshots but it wouldn't work for some reason ).
Does not show up in Zsnesw141.
File: Bugs Bunny - Rabbit Rampage (E).smc Header: No
BUGS BUNNY TYPE:NORMAL
INTERLEAVED:No BANK:Lo CHKSUM:OK
VIDEO:PAL CRC32:91B3DB54 |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon May 01, 2006 12:42 pm Post subject: |
|
version
16 is coming along awesomely! My only dilemma is with the d3d mode
fullscreen. If I select triple buffer, I get smooth scrolling but the
sound goes crackling every few secs. If I turn it off to fix the sound,
then the scrolling looks bad. If there was some way to get both at the
same time, that would kick some serious ass! |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon May 01, 2006 12:57 pm Post subject: |
|
Yes I know, but its still my dilemma. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 01, 2006 3:03 pm Post subject: |
|
Quote: |
Wierd. So I should remove it? |
Nah, it should probably still work anyway; and it is technically "broken".
Quote: |
If
I select triple buffer, I get smooth scrolling but the sound goes
crackling every few secs. If I turn it off to fix the sound, then the
scrolling looks bad. If there was some way to get both at the same
time, that would kick some serious ass! |
I completely agree. Perfect audio and smooth scrolling would be
awesome. However, I don't know how to fix it. I've spent hours trying
to.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 02, 2006 4:56 am Post subject: |
|
Narf wrote: |
Using Bsnes V0.016 with no graphical filters applied.
Small graphical bug in Bugs Bunny - Rabit Rampage (E) (Also appears in (J))
On the first level on the first screen there are several white tiles
that seem to be out of place, hard to miss (I tried to capture
screenshots but it wouldn't work for some reason ).
Does not show up in Zsnesw141.
File: Bugs Bunny - Rabbit Rampage (E).smc Header: No
BUGS BUNNY TYPE:NORMAL
INTERLEAVED:No BANK:Lo CHKSUM:OK
VIDEO:PAL CRC32:91B3DB54 |
Confirmed and added. Also reminded me about another NSRT naming
problem. Some games include the subtitles, some don't, even though Nach
is against them. Many have forced him to make exceptions to what is
already a flawed rule, but he hasn't fully given in. Example: Legend of
Zelda, The - A Link to the Past, when shortened, then would have shared
the same name as one of its prequels. Basically the equivalent of
calling "The Godfather, Part 3" "The Godfather."
So yeah, the exceptions fix that, but they
1. prevent a standard
2. mean extra work for rom researchers who have to then find out if
prequels/sequels existed for every other system.
So here comes this game which is named "Bugs Bunny" in NSRT. Let's say
this "no-subtitles" standard spanned every system, as it would if NSRT
grew. Now let's take the following roms: Bugs Bunny - Double Trouble
(genesis) and Bugs Bunny - Rabbit Rampage (snes). Under NSRT, they
would both be named "Bugs Bunny." You would then think they're the same
game, but they aren't ... at all. Then if you zipped them up, you
wouldn't be able to have them in the same folder without renaming them
manually... and they're different games on different systems!
So, what are the negatives to having subtitles, you might ask? Well... they... uhhh.... make the filename longer.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 02, 2006 5:28 am Post subject: |
|
Yeah, I should take it to nsrt forums actually. Kind of got on a spiel, as usual. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 02, 2006 8:02 am Post subject: |
|
Merry Christmas.

99% of this code comes from Overload's website. Thank you, Overload!
Adding the last opcode, op06, will fix sprite placement and mostly
finish the job. It's just a pain the ass thanks to the SNES9x code
mess. Not that I'm not grateful for their source to use as a reference,
of course... 
Ah well, hopefully I can figure out the DSP-1 command interface a
little better, and release a much cleaner (complete) source
implementation for DSP-1 emulation, and actually use ::gasp:: comments while I'm at it! |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 02, 2006 10:22 am Post subject: |
|
A surprise! Thank you thank you! SMK and Pilotwings rock. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue May 02, 2006 2:24 pm Post subject: |
|
Goodness. Thanks indeed to byuu and Overload.
It's nice to see an implementation of an add-on chip that doesn't just try to be playable but accurate too. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue May 02, 2006 7:49 pm Post subject: |
|
Dmog wrote: |
It's nice to see an implementation [...] that doesn't just try to be playable but accurate too. |
SNES9x' implementation may not be perfect, but I wouldn't go that far.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue May 02, 2006 8:55 pm Post subject: |
|
Dmog wrote: |
Goodness. Thanks indeed to byuu and Overload.
It's nice to see an implementation of an add-on chip that doesn't just try to be playable but accurate too. |
Obviously you have no idea what you are talking about. Everyone is using the same DSP-1 source at this point.
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Tue May 02, 2006 9:59 pm Post subject: |
|
Delicious. Thx Byuu & Overload. 
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue May 02, 2006 10:28 pm Post subject: |
|
pagefault wrote: |
Dmog wrote: |
Goodness. Thanks indeed to byuu and Overload.
It's nice to see an implementation of an add-on chip that doesn't just
try to be playable but accurate too. |
Obviously you have no idea what you are talking about. Everyone is
using the same DSP-1 source at this point.
|
Ok ok,I take back what I said. But some add-on chips implementations
(in Zsnes or 9x) like the SuperFX and SA1 are indeed very inaccurate
and not very complete, are they not?
Last edited by Dmog on Tue May 02, 2006 10:30 pm; edited 1 time in total
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Tue May 02, 2006 10:29 pm Post subject: |
|
pagefault wrote: |
Obviously you have no idea what you are talking about. Everyone is using the same DSP-1 source at this point. |
How far has the emulation progressed at this point, accuracy-wise?
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue May 02, 2006 10:47 pm Post subject: |
|
Dmog wrote: |
pagefault wrote: |
Dmog wrote: |
Goodness. Thanks indeed to byuu and Overload.
It's nice to see an implementation of an add-on chip that doesn't just
try to be playable but accurate too. |
Obviously you have no idea what you are talking about. Everyone is
using the same DSP-1 source at this point.
|
Ok ok,I take back what I said. But some add-on chips implementations
(in Zsnes or 9x) like the SuperFX and SA1 are indeed very inaccurate
and not very complete, are they not?
|
I have no idea on what the status for SuperFX (probably the second
version of the chip is still yet to be emulated fully).
However... the discussion on SA-1 was already made.
http://board.zsnes.com/phpBB2/viewtopic.php?t=6919&highlight=
pagefault wrote: |
I
have a build of ZSNES that runs them perfectly but it will require a
4ghz+ PC to run it properly because of the timing needed to keep it
running accurately without using speed hacks to speed up the emulation. |
So.. adding this to BSNES would have a performance problems far greater
than can be currently imagined. The requirement is slightly exaggerated
for ZSNES, but it can give you a decent idea of what would be needed if
you did accurate SA-1 emulation+filters.
_________________
FF4 research never ends for me.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue May 02, 2006 11:13 pm Post subject: |
|
Deathlike2 wrote: |
Dmog wrote: |
pagefault wrote: |
Dmog wrote: |
Goodness. Thanks indeed to byuu and Overload.
It's nice to see an implementation of an add-on chip that doesn't just
try to be playable but accurate too. |
Obviously you have no idea what you are talking about. Everyone is
using the same DSP-1 source at this point.
|
Ok ok,I take back what I said. But some add-on chips implementations
(in Zsnes or 9x) like the SuperFX and SA1 are indeed very inaccurate
and not very complete, are they not?
|
I have no idea on what the status for SuperFX (probably the second
version of the chip is still yet to be emulated fully).
However... the discussion on SA-1 was already made.
http://board.zsnes.com/phpBB2/viewtopic.php?t=6919&highlight=
pagefault wrote: |
I
have a build of ZSNES that runs them perfectly but it will require a
4ghz+ PC to run it properly because of the timing needed to keep it
running accurately without using speed hacks to speed up the emulation. |
|
Good stuff! (and yes, I read the high requirments correctly)
Quote: |
So..
adding this to BSNES would have a performance problems far greater than
can be currently imagined. The requirement is slightly exaggerated for
ZSNES, but it can give you a decent idea of what would be needed if you
did accurate SA-1 emulation+filters. |
At that level, I think the filters wouldn't make a difference honestly.
I wouldn't mind having SA-1 in bsnes actually, even if it would
require a 20GHZ computer or something. But of course, it all depends if
you want to have constant performance in bsnes with all games or not.
So I would understand if byuu don't want to add it for now.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed May 03, 2006 1:25 am Post subject: |
|
Dmog wrote: |
At that level, I think the filters wouldn't make a difference honestly. |
You haven't really used any of the HQx modes to know how CPU demanding they are.
Quote: |
I wouldn't mind having SA-1 in bsnes actually, even if it would
require a 20GHZ computer or something. But of course, it all depends if
you want to have constant performance in bsnes with all games or not.
So I would understand if byuu don't want to add it for now. |
For the record.. SA-1 research is still not complete. What is currently
implemented is pagefault's build is only the SA-1 knowledge that is
KNOWN by all SNES devs/documentation at this time. Whatever is not
known is not emulated yet. So... it won't happen anytime soon
unfortunately.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 03, 2006 1:37 am Post subject: |
|
pagefault wrote: |
Obviously you have no idea what you are talking about. Everyone is using the same DSP-1 source at this point. |
Seriously? Look at SNES9x' DSP-1 code sometime. Their status register
emulation consists of always returning "ready" (0x80), and nothing
more. It ignores all known information (bit 2 is the transfer size
indicator, for example). Not emulated since the known DSP-1 games don't
rely on it.
Look at their chip interface. It uses buffers that the real chip
doesn't have and has hacks all over for ops 06, 1f, and especially 0a.
None of which are documented to explain what the hell is going on.
I think I can do a better job, but we'll see. The actual ops, yeah.
We're all using the same code there. One single op away from being
totally bit perfect. Why we're using true floating point for it when we
know the chip isn't that accurate, however, is beyond me. At least it
isn't as bad as the 50/50 split of integer vs fp for the C4 opcodes.
Quote: |
For
the record.. SA-1 research is still not complete. What is currently
implemented is pagefault's build is only the SA-1 knowledge that is
KNOWN by all SNES devs/documentation at this time. Whatever is not
known is not emulated yet. So... it won't happen anytime soon
unfortunately. |
I don't want to say I'm not emulating that chip (because you never know), but... I'm not
emulating that chip. Anyone else is free to, but if I have to add hacks
all over the place to support it, then I won't bother. There's far too
much left with the main system itself to worry about an obscenely
complex chip that has maybe four good games that use it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 03, 2006 8:37 am Post subject: |
|
I
just received my Super Smary Joy in the mail today (usb adapter for
snes pad). I thought I'd wait until I got it before making the
following suggestion. On the subject of presets this week, I thought
you might be interested in setting the preset for bsnes' joypad buttons
to the actual snes controller.
Here's what I got
after assignment. It's different than what the default is now (don't
know what you used for reference):
Up > up
Down > down
Left > left
Right > right
Y > button3
X > button0
B > button2
A > button1
L > button6
R > button7
Select > button4
Start > button5
I might be assuming that a parallel adapter would map the same way, so
if someone with one of those would confirm sameness, I'd appreciate it. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Wed May 03, 2006 8:51 am Post subject: |
|
FitzRoy wrote: |
Here's what I got after assignment. It's different than what the default is now (don't know what you used for reference):
Up > up
Down > down
Left > left
Right > right
Y > button3
X > button0
B > button2
A > button1
L > button6
R > button7
Select > button4
Start > button5 |
I have 2 kinds of 10-buttons gamepads and they map out as:
- 4 faces, 4 shoulders, 2 extras
up/down/left/right
Y = 2
X = 3
B = 0
A = 1
L = 4
R = 5
Select = 8
Start = 9
- 6 faces, 2 shoulders, 2 extras
up/down/left/right
Y = 3
X = 4
B = 0
A = 1
L = 6
R = 7
Select = 8
Start = 9
The fact some pads have 'B' (the lowest-leftmost button) as anything
but 0 - like yours - proves it's useless to make any preset follow any
kind of logic.
_________________
皆黙って俺について来い!!
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: Wed May 03, 2006 9:14 am Post subject: |
|
I
knew that every controller would map differently, but I just thought,
if you're going to have a preset, it may as well be the real deal, yes?

Still, all for naught if the parallel adapter maps differently. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun May 07, 2006 9:13 am Post subject: |
|
Ok, I've solved this problem. Aaron Giles was very helpful.
http://byuu.cinnamonpirate.com/temp/libco_v03.zip
Now, time for another poll. This time, it's really important.
I've managed to implement cooperative multithreading in c++ that is
only 6x slower than a standard function call. However, I will no longer
need a state machine (or multiple nested state machines like bsnes uses
now) to resume where I left off from a given function call, or to
return in the middle of a function call.
What this means is that I can implement an opcode like this :
Code: |
switch(opcode) {
case 0xa9:
regs.a.l = op_read();
regs.a.h = op_read();
set_flags();
break;
} |
Instead of like this :
Code: |
case OP_EXEC:
switch(opcode) {
case 0:
op_bus_read_delay();
break;
case 1:
regs.a.l = op_read();
break;
case 2:
op_bus_read_delay();
break;
case 3:
regs.a.h = op_read();
set_flags();
break;
}
break; |
The difference? A significant speed improvement, a step closer to
dual/quad core CPU support (preemptive multitasking), much cleaner
code, and more accurate than bsnes v0.016. These are the goals of bsnes.
And now, the problem. Save states. I can't save the execution context
of each cooperative thread and restore it on the fly in a
platform-independant way (or worst case, even per-execution-run).
So... I either give up savestates (or possibly have really hackish
savestates that only work on one computer, or one OS), or I give up
huge benefits to coding clarity, speed, and accuracy...
But there's more to it than just save states, bsnes will never catch on
mainstream without savestates. Which could affect code contributions in
the future, etc.
Geez, such a tough decision :(
---------
Hmm, epiphany! What if I were split this up? Keep one core that has
savestates and is semi-accurate, and one core that does not have save
states, and is dead-on accurate? More work for me, but it's the only
way everyone will be happy :/
Perhaps with some tricky defines I could make opcode vs bus synchronizations an option?
I'd basically be turning bsnes into two SNES emulators, though.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun May 07, 2006 11:29 am Post subject: |
|
Wow, you're not kidding. That's tough.
I know I've already expressed my feelings about savestates. A lot of
people like them and can't live without them. I try not to use them
unless I have to. It's a nice feature to have, but from the impressive
list of benefits you claim to gain from libco, it would be ridiculous
to choose savestates over that. The question is whether or not you
should maintain two cores. That's a last resort option in my mind. You
work hard enough, I can't see any user in his right mind asking you to
upkeep two versions for the sake of savestates. I see one sensible
suggestion: go for the multi-threading and think about adding
savestates as an afterthought. If you can one day hack them in for
windows users only as you say, that would probably be sufficient to get
the larger audience you seek. Big deal if they're not perfect. I like
the sound of those improvements and you working less. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun May 07, 2006 11:42 am Post subject: |
|
Could
you save the state only at those points in time where all the
subthreads are at the same "position"? Sorry if this is a stupid
question.
Anyway, I'd say "hackish" savestates are still better than no savestates at all.
Like FitzRoy said, two cores seems like too much work just for that feature.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun May 07, 2006 2:02 pm Post subject: |
|
Goob job on the recent progress, w00t.
Personally, I don't use save states,even when they're supported. But I
know a few users can't live ("Can't LIIIIIIIIIIIIIIIIIIIVE!!!!!")
ahem.. without them. They're a good way to quickly test bugs though.
So yeah,I'd say go for libco support. |
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Sun May 07, 2006 5:34 pm Post subject: |
|
Like
the other people have said, the list of benefits of libco sounds
impressive enough that if it means no savestates, so be it. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Sun May 07, 2006 6:46 pm Post subject: |
|
Dmog wrote: |
Personally, I don't use save states. |
Same here.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun May 07, 2006 7:16 pm Post subject: |
|
Your
goals include accurate SNES emulation. Save states weren't a feature of
the original SNES, and they seem to be somewhat "hackish" in all SNES
emulators.
Screw em'. Maybe you can figure out a
way to do them later. Maybe you can wean people of save states. Don't
do two cores either.
"Save states are for pussies."
I do realize, however, that the speed-run communities won't be able to
use your emulator very well. But maybe those guys can come up with a
crazy way of implementing save states that would work for them.
Maybe Nach can figure something out.
Anyway, no need to give up one of your stated goals just for save states.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun May 07, 2006 8:02 pm Post subject: |
|
Jipcy wrote: |
I do realize, however, that the speed-run communities won't be able to
use your emulator very well. But maybe those guys can come up with a
crazy way of implementing save states that would work for them.
|
It's not just them, save states are good for bug reports too.
And Bisqwit's community needs save states which can be saved every frame.
Jipcy wrote: |
Maybe Nach can figure something out.
|
This is a very tricky subject.
First glance says no way no how.
However more thought tells me we might be able to be tricky using
normal relocation ideas coupled with tracking all allocated stacks to
give frame accurate save states. However these save states would be per
platform, and save state capable builds will probably be slower.
Overall the whole thing will be quite annoying, and it'll be hard to
say until I see the final product and study it. And getting it to work
across platforms seems quite difficult, unless we come up with some
sort of stack description format which is cross platform, but that's
much easier said than done.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon May 08, 2006 12:46 pm Post subject: |
|
Here's the irony many of you don't see with savestates:
The most accurate SNES emulator we have available is less than useful
for any actual reverse engineering of existing games or or new homebrew
code because of not having not save states.
If you can't get to it in the first few seconds of gameplay or
immediate after a natural savepoint, you can't test or look at that
portion of code without painstaking annoyances of playing to that point
EVERYTIME which could be 2 minutes, or an hour. Certainly not practical
in any case.
It just seems like a travesty to have an active, accurate, SNES
emulator but have it be useless for many tasks that would be much
better off with a more accurate emulator.
Of course, none of this even matters right now since the current version of BSNES has no debugger either anymore.
_________________
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. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue May 09, 2006 1:13 am Post subject: |
|
Time
permitting, try making two versions. One optimised code without save
states, and the other a feature-flush version with save states. One can
be used to bug-shoot, while the other would be an accurate alternative. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 10, 2006 5:45 pm Post subject: |
|
So ideas I have now...
1) Opcode-based cores that support savestates and bus-accurate cores
that don't. Possibly use tricky #defines to turn this into a
compile-time option.
2) Elaborate #define system to obfuscate the state machine needed for
bus-accuracy + savestates, take the 2-3x speedhit and be unusable on
any PC.
3) Give up on any semblance of code readability and come up with some sort of complex timestamping system.
4) Master-slave implementation that will ruin debugging capabilities for everything but the main CPU.
What you need to realize is that the original SNES hardware had separate
ICs for each component of the system. The S-CPU, the S-PPU, the S-SMP,
and the S-DSP. With c++ and no threading, this all gets bunched
together, along with a new GUI component. It's simply not possible to
cleanly design around the reentrancy problems of c++ without taking
either a massive speed hit for using a sloppy state machine, or using
multithreading which eliminates save states.
It
only makes sense from an emulation perspective to simulate the original
hardware by breaking each component into its' own unique context
(lightweight-process). Of course, we have to simulate parallelism that
truly is impossible on modern hardware by running to bus accesses and
synchronizing, however this isn't very difficult and results in no
accuracy loss, other than emulating bus conflicts.
Quote: |
This is a very tricky subject.
First glance says no way no how. |
Agreed. Changing anything in the program code will result in addresses
moving all around. So even a tiny code modification would break context
save states.
Quote: |
The
most accurate SNES emulator we have available is less than useful for
any actual reverse engineering of existing games or or new homebrew
code because of not having not save states. |
Pretty much. It's most(ly) useful for emulating the original hardware, and not much else.
Quote: |
If
you can't get to it in the first few seconds of gameplay or immediate
after a natural savepoint, you can't test or look at that portion of
code without painstaking annoyances of playing to that point EVERYTIME
which could be 2 minutes, or an hour. Certainly not practical in any
case ... Of course, none of this even matters right now since the
current version of BSNES has no debugger either anymore. |
Yep, hence why I can't fix many of the bug reports. Believe me, I'd
love to get the debugger up and running again, but at this point I
don't even know what to do with the CPU and APU cores that are
absolutely pivotal to the debugging interface.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed May 10, 2006 6:42 pm Post subject: |
|
byuu wrote: |
3) Give up on any semblance of code readability and come up with some sort of complex timestamping system. |
Can you elaborate on this option?
I don't pretend to know much about save states, but just for the sake
of argument, how might someone, hypothetically, make a save state on a
real SNES?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Carnivol Regular
Joined: 09 Aug 2004
Posts: 221
Location: Confirmed
|
Posted: Wed May 10, 2006 7:15 pm Post subject: |
|
Quote: |
I
don't pretend to know much about save states, but just for the sake of
argument, how might someone, hypothetically, make a save state on a
real SNES? |
there is a device called a "game saver" (By Nakitek) which came out for
the SNES that allows you to "freeze/save" a moment and then load it up
later.
Similiar devices has been sold for the Gameboys too, guess Genesis/MegaDrive got one too.
_________________
~empty zig space for rent~
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed May 10, 2006 7:29 pm Post subject: |
|
Jipcy wrote: |
how might someone, hypothetically, make a save state on a real SNES? |
By using a device that dumps the content of the RAM chips into its own
ones, and saves the status of the other components.
I don't know how that could work though... some of that info is very difficult to get and set.
EDIT: Apparently there's also this device: link
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Thu May 11, 2006 6:33 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 10, 2006 10:37 pm Post subject: |
|
As
far as the potential for perfect game accuracy goes, you are on the
correct core right now. I remember the last time you wanted opcode, you
were considering compromising that feat for a speed increase. This
time, it's savestates. Savestates has more of an argument for that this
time, but it still falls short to me. The stuff Nightcrawler mentioned
is all good and dandy, but you have to remember that zsnes is
constantly improving as well, and would likely satisfy any
developmental savestate needs as an opcode core. As for bug report
easiness? bsnes has a shortlist. Big deal if a few games have to be
played into a bit from the srm to see the bug.
You
saw the post by the guy in zsnestalk who cast aside bsnes because of
its lack of savestates. For every one of those guys, there is a guy who
feels the opposite. You question whether or not bsnes will become
mainstream, but if you look at the numbers it already has. On AEP-EMU,
bsnes has 8000 downloads to zsnes' 20000 and snes9x' 18000. People
might not be registering left and right to express their support or
satisfaction, but there are a lot of people using your emulator as
well. That's just how most people are. Silently appreciative. Heck, if
you think about how many regular posters this board has, it's probably
around 150. People only bother to register to get help, report a bug or
ask for something. You don't see many "thank you thank you thank you"
posts anymore, but that doesn't mean shitloads of people don't love
zsnes.
So to summarize, I think you're on the right course to achieving both a
super accurate emulator and a large userbase. It might not seem
blatantly obvious, but it's true. So savestates = meh. Carry on with
your work, loads of people have been and will still use bsnes without
them, and even more people with the speed and accuracy improvments from
libco. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 11, 2006 12:45 am Post subject: |
|
Quote: |
As far as the potential for perfect game accuracy goes, you are on the correct core right now. |
Hmm? The current core is cycle-accurate, but fakes bus-accuracy by
incrementing the H/V counters and triggering NMI/IRQs correctly, but
not synchronizing the APU (meaning there's an infinitesimal desync
between CPU<>APU communications). The new core using libco would
be truly bus-accurate.
At present, I'm thinking this weekend I'll port the APU core (since
it's just an opcode emulator with no interrupts or DMA to worry about)
to use libco, and post a version for people to compare, or something.
Then we can worry about coming up with macro and preprocessing tricks
for a /much/ slower (or slightly less accurate) savestate-enabled
version. Preferrably in a way that I don't have to maintain >1
CPU+APU core.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu May 11, 2006 1:29 am Post subject: |
|
(taken from another thread)
herzog wrote: |
I
hope you will not get too frustrated with these people and become
dis-illusioned with the scene. bsnes is an exciting emulator and I look
forward to future releases. Keep up the great work. |
herzog is right on target,byuu. Obviously you can't please everyone and
some folks only knows how to demand and complain...that's part of the
emulation scene unfortunately. Heck, the great and venerable MAME has
seen countless of "OMG teh mAMe s0cks, m8ke it faster,I want KaillERA sppoRT!! Give me teh r0mz!! Yo MAME iz s0 fat!!"
.
"Lamerz" come and goes but MAME stayed.
And speaking of MAME,I believe there are plenty of MAME drivers that do not support savestates.
Anyway, if you allready decided what to do next then simply ignore
this, but I agree with Fitzroy and others that savestates is not that
big of a deal for now. Basically, it's very possible that there are
'more' people that do not care about savestates. But naturally,only
those who care about it will manifest themselves, which can give a
false representation...Fitzroy is right when he says:
Quote: |
That's just how most people are. Silently appreciative |
The complain(ers) tend to be louder,unfortunately.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Thu May 11, 2006 6:29 am Post subject: |
|
only noisy people make noise, while the content remain quiet.
..except when they make pseudophilosophical sounding posts like this 
anyway, i'd say go for pure accuracy. there's enough of a following
that for any bug that has noise made about it, at least *someone* will
probably break their neck looking to prove it.
if not, so what? it is YOUR emulator, byuu, not bsnes9x or bzsnes or
bSNEeSe etc. there will always be another emulator to fill any
shortcomings (perceived or otherwise) in bsnes, just as there is snes9x
and bsnes and SNEeSe which fill each other's shortcomings now.
and as for any potential "massive performance hits"... i remember back
in '98 or so when snes9x was around .20 and zsnes had just started, and
someone threw out that "there's no way a snes can be emulated on
anything less than a 2GHz cpu"... well, you know what? worst case, in a
few years, that hardware limit will be passed. and more than likely,
other architectural improvements will make that limit lower than
expected.
do it whatever way you see fit, as long as you're satisfied.
satisfaction with your emulator is what will keep you working on it,
the same satisfaction that i presume keeps nach, pagefault, anomie,
kode54, fx3, steve snake etc working on theirs! |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Thu May 11, 2006 7:37 am Post subject: |
|
For
me, when I first got into emulation, savestates were a fun new way to
play with the games I'd finished a long time ago. But now, they're in
no way essential to me, really. In fact, they make some games a lot
more boring, IMO. If a perfectly accurate SNES emulator came out today
without savestates, rewind, speedup or slowdown, it would be my first
choice (provided it would run full speed on my PC, which is really the
only reason I don't use Bsnes as much).
Oh, and perfectly accurate TV output would be nice too, but I guess that's just a pipe dream. :p
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu May 11, 2006 8:25 am Post subject: |
|
byuu wrote: |
Quote: |
As far as the potential for perfect game accuracy goes, you are on the correct core right now. |
Hmm? The current core is cycle-accurate, but fakes bus-accuracy by
incrementing the H/V counters and triggering NMI/IRQs correctly, but
not synchronizing the APU (meaning there's an infinitesimal desync
between CPU<>APU communications). The new core using libco would
be truly bus-accurate.
|
Sorry, I forgot that you simulated subcycle in that regard. All I had
on my mind when saying that was "moving to opcode would be less
accurate, which is not a good tradeoff." So what kind of core will
bsnes be when libco is used?
byuu wrote: |
At present, I'm thinking this weekend I'll port the APU core (since
it's just an opcode emulator with no interrupts or DMA to worry about)
to use libco, and post a version for people to compare, or something.
Then we can worry about coming up with macro and preprocessing tricks
for a /much/ slower (or slightly less accurate) savestate-enabled
version. Preferrably in a way that I don't have to maintain >1
CPU+APU core. |
Cool, looking forward to it.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 11, 2006 9:13 am Post subject: |
|
Quote: |
So what kind of core will bsnes be when libco is used? |
The code will be identical to an opcode-based core, with the exception
of 2-4 cleverly placed yield() commands that will freeze the CPU
context during bus accesses. But the difference will be that the main
CPU run routine is a neverending loop.
So before one would have:
cpu_run() { execute_opcode(); return; }
And now it will look like:
cpu_run() { for(;;) { execute_opcode(); yield(); } }
Now that I think about it, in that regard, an opcode-based CPU core and
bus-accurate core can use identical code. The differences will all be
above the actual opcode implementations, eg I'd need different
DMA/IRQ/NMI handlers, and not much else. Coolness.
And then I'll be able to stick the CPU core into a potential SA-1
emulator, should hell freeze over and I decide to work on that in the
future.
Thanks for all the positive feedback. I believe I will go with my cooperative multithreading library after all :)
I made a more intensive test today that verified local function
variables, nested for loops, etc all work fine with the library. I also
cleaned it up a tad more, which should make Linux compilation easier.
My benchmarks indicate the context switching is 6x as intensive as a
function call on an Athlon, and 10-12x as intensive on a P4 (which is
because P4's have way more pipelines that get thrased when you switch
contexts).
Let's all pray that this doesn't turn out to slow things to a crawl
when I actually do add it into the emulator, like my switch/case define
trick did.
|
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Thu May 11, 2006 11:54 am Post subject: |
|
Re
savestates: Use a text-based format [a la PSR] and bzip2-compress it.
ZSNES will be moving to PSR-based savestates eventually, anyway, so...
:p |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Thu May 11, 2006 1:13 pm Post subject: |
|
Jipcy wrote: |
blackmyst wrote: |
speedup or slowdown |
I don't think those are dependent on save sates.
|
I know. Just listing things I don't really care for in an emulator. ;)
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu May 11, 2006 4:36 pm Post subject: |
|
byuu wrote: |
My
benchmarks indicate the context switching is 6x as intensive as a
function call on an Athlon, and 10-12x as intensive on a P4 (which is
because P4's have way more pipelines that get thrased when you switch
contexts). |
What does this mean?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 11, 2006 5:12 pm Post subject: |
|
It means that :
is 6-12x times faster than :
Code: |
push dword cpu_context_handle : call co_call |
depending on what type of processor you have. Athlons are twice as
efficient because they aren't pipelined to all hell with 20x
multipliers like P4 chips.
However, you make up for a good deal of that by avoiding the
switch/case tables to get from the beginning of cpu_run() to the small
part of the code you need to execute (eg a cycle of an opcode).
So,
Code: |
cpu_run()
-> switch(state) -> case OPCODE_EXEC: -> exec_opcode() ->
switch(opcode) -> opa9() -> switch(opcode_cycle) -> case 2: |
becomes :
Code: |
co_call(cpu_context_handle) -> /* already at case 2: */ |
However, we'll see how fast/slow it ends up this weekend, I suppose. It should be way faster, and it will
be much cleaner code-wise. And yet, I wouldn't be surprised if things
ended up as slow / slower with this approach, as that's just my luck.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu May 11, 2006 8:40 pm Post subject: |
|
byuu wrote: |
The
code will be identical to an opcode-based core, with the exception of
2-4 cleverly placed yield() commands that will freeze the CPU context
during bus accesses. But the difference will be that the main CPU run
routine is a neverending loop.
So before one would have:
cpu_run() { execute_opcode(); return; }
And now it will look like:
cpu_run() { for(;;) { execute_opcode(); yield(); } } |
byuu, just so I get things right: basically bsnes won't be cycle-based
(or even subcycle or clockcycle based) anymore, correct? And yet it
will remain as accurate (if not more) as it is today while
(theorically) gaining a big performance boost? :shock:
Basically,what I'm asking is: the emulation method you're gonna use
does not really figure within the ones you mentionned here,right?
http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods
Again, if I get things right, it will be functionally similar to an
opcode based method,but without the tradional limitations and
innacuracies that normally goes with it?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 11, 2006 9:15 pm Post subject: |
|
Well,
basically I had to differentiate between opcode/cycle/subcycle accuracy
before, because I had to break the CPU down to parts small enough that
could be returned after each part.
But now, thanks
to cooperative multithreading, I can return right in the middle of the
CPU core, so there's no reason to break anything down. The code will
look just like an opcode-based core, but with yield() stuck in there in
2-4 places. I'll even get to pull off syncs between each HDMA write
now, something v0.016 can't quite do. Should help even more with games
like EWJ2 that use HDMA<>SPC700 spooling.
So then, if you enable cothreading, you lose savestates and get even
more accuracy than bsnes currently has. If you disable cothreading,
then you get massive speed gains over v0.016 (easily 30+%),
(eventually) savestates, and only a moderate hit to overall accuracy
(it would be on par with SNES9x then, basically). |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri May 12, 2006 5:01 am Post subject: |
|
Wow, cothread will be uber awesome if there's no speed hit over .016. If there is, it will just be awesome  |
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri May 12, 2006 8:08 am Post subject: |
|
Getting
back to the triple buffer/ choppy sound issue, I noticed that the
megadrive emulator "Gens" gets around this by occasionally skipping a
frame to keep the action synced to the sound properly. If I turn the
auto-framw adjust feature off, Gens sound also will intermittently
become choppy. So while the scrolling is liquid-smooth most of the
time, it will skip a frame only when needed to stay in sync with sound.
Might want to see if this is a viable option for bsnes too. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri May 12, 2006 2:48 pm Post subject: |
|
FitzRoy wrote: |
Wow, cothread will be uber awesome if there's no speed hit over .016. If there is, it will just be awesome  |
Agree. Seems to me Snes9x-level accuracy would be like a big step backward for bsnes in term of accracy...(not to bash on 9x or anything)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri May 12, 2006 4:17 pm Post subject: |
|
Dmog wrote: |
FitzRoy wrote: |
Wow, cothread will be uber awesome if there's no speed hit over .016. If there is, it will just be awesome  |
Agree. Seems to me Snes9x-level accuracy would be like a big step backward for bsnes in term of accracy...(not to bash on 9x or anything)
|
It's only a step backward if it were the only option. With the presence
of opcode+cothread, it's apparently more accurate than cycle based.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 12, 2006 4:20 pm Post subject: |
|
Quote: |
Agree. Seems to me Snes9x-level accuracy would be like a big step backward for bsnes in term of accracy... |
I agree. The thing is, the difference between an opcode-core and a
bus-accurate core is a #ifdef around all 2-4 calls to co_return(). The
CPU might be a little trickier than the APU, but still very little
actual work.
So I'll make it a compile-time option, and with that I can release two
separate versions. One for low-end machines, say 800-1600mhz or so, not
sure yet. And the more accurate one for high-end machines. I figure
it's better to have something playable, rather than nothing at all.
And it will be a requirement for the G5 version of Mac OS X, unless
someone kind can port libco to the G5 architecture.
Quote: |
Getting
back to the triple buffer/ choppy sound issue, I noticed that the
megadrive emulator "Gens" gets around this by occasionally skipping a
frame to keep the action synced to the sound properly. |
My code is supposed to do exactly that. But for some reason, the Flip()
command is forcibly waiting for the next vsync anyway. Ideally, this
function would accept the two writes in one frame that happen once
every 10 seconds and end up discarding one of the frames. But I guess
that would mean writes could update the pointer mid-frame and cause
tearing... well, that gives me an idea, at least. I'll create a
function wrapper for Flip() and set a high performance timer to copy it
over sometime near the end of vblank each frame.
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Fri May 12, 2006 5:24 pm Post subject: |
|
Would
it really need ifdefs? An "if(bus_accurate) co_return();" would add
just a few processor cycles* of overhead versus ifdef, and doing so
would allow you to change at run-time, which could allow you to have
per-game settings very easily.
* OK, back of the
envelope, on a cold cache you're probably looking at ~80cycles for the
memory load, 2 cycles for the test/branch, and a max of 20 cycles for
backing out the pipeline because of a branch misprediction, 100 cycles.
But in the bus_accurate == true case, the overhead is negligible
compared to a context switch anyway, and in the bus_accurate == false
case, if you give the compiler a hint that it's likely to be false,
then you cut the branch misprediction overhead, and you're down to
basically just the load time for bus_accurate. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri May 12, 2006 7:11 pm Post subject: |
|
FitzRoy wrote: |
Dmog wrote: |
FitzRoy wrote: |
Wow, cothread will be uber awesome if there's no speed hit over .016. If there is, it will just be awesome  |
Agree. Seems to me Snes9x-level accuracy would be like a big step backward for bsnes in term of accracy...(not to bash on 9x or anything)
|
It's only a step backward if it were the only option.
|
Yes,that's what I meant. If making two separate builds is only a matter
of changing a few lines of code before compile then I'm all for it.
Quote: |
With the presence of opcode+cothread, it's apparently more accurate than cycle based. |
That's what I understood.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 12, 2006 7:19 pm Post subject: |
|
Quote: |
Would
it really need ifdefs? An "if(bus_accurate) co_return();" would add
just a few processor cycles* of overhead versus ifdef, and doing so
would allow you to change at run-time, which could allow you to have
per-game settings very easily. |
It would work there, but I would have to redo the core, at least for the CPU, probably not for the APU.
With the CPU, hmmm... I might be able to work something else out.
Essentially, an opcode-based core will need to have DMA implemented so
that it can return after each byte transfer, whereas the bus-accurate
one with cothreading will not need to do this. And I don't intend to do
it either, as it will make the code more readable. And there's all the
magical fun of DMA synchronization timing... I don't intend on adding
that in the opcode core since nothing relies on it, and that core won't
be cycle accurate anyway, so why bother?
So... the main SNES timing routine will call r_cpu->run every time
it needs to have the CPU catch up to the APU. If I add a check for
"bus_accurate" there, or whatever, the overhead could be quite severe.
I know I took a ~5fps frame hit simply for adding an add+bitmask in the
add_cycles function, and a ~3-5fps speed hit for a boolean
if(cheat.enabled) inside the memory bus *read* (not write) function...
I'd take a speed hit of ~1-3 million boolean comparisons per second by
adding if(bus_accurate)co_return() into op_read/op_write, as well.
I could always just enable polymorphism for r_cpu if I wanted a build
that could swap between the two on-the-fly. That takes a performance
hit of ~10%, though.
Quote: |
> With the presence of opcode+cothread, it's apparently more accurate than cycle based.
That's what I understood. |
Yep, my explanantions must be lousy, but let me try again... because
the CPU is running in a separate thread, I can stop right in the middle
of a function, whenever I want, wherever I want, and go to another core
to synchronize back up. So I essentialy now have infinite precision,
but the code is written just like an opcode based core. Without the
cothreading, I would have no choice but to split the core up by
breaking the opcode apart into 6-8 subopcodes, or "cycles". For bus
accuracy, I would have to split each one of those in half. That would
be so that I could return from the CPU core and run the APU/PPU/DSP/etc
to catch those up when necessary. Does that explain things better?
GRAH, I can't wait to get off of work today so I can start on this already >:D
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri May 12, 2006 7:36 pm Post subject: |
|
byuu wrote: |
Quote: |
Would
it really need ifdefs? An "if(bus_accurate) co_return();" would add
just a few processor cycles* of overhead versus ifdef, and doing so
would allow you to change at run-time, which could allow you to have
per-game settings very easily. |
It would work there, but I would have to redo the core, at least for the CPU, probably not for the APU.
With the CPU, hmmm... I might be able to work something else out.
Essentially, an opcode-based core will need to have DMA implemented so
that it can return after each byte transfer, whereas the bus-accurate
one with cothreading will not need to do this. And I don't intend to do
it either, as it will make the code more readable. And there's all the
magical fun of DMA synchronization timing... I don't intend on adding
that in the opcode core since nothing relies on it, and that core won't
be cycle accurate anyway, so why bother?
So... the main SNES timing routine will call r_cpu->run every time
it needs to have the CPU catch up to the APU. If I add a check for
"bus_accurate" there, or whatever, the overhead could be quite severe.
I know I took a ~5fps frame hit simply for adding an add+bitmask in the
add_cycles function, and a ~3-5fps speed hit for a boolean
if(cheat.enabled) inside the memory bus *read* (not write) function...
I'd take a speed hit of ~1-3 million boolean comparisons per second by
adding if(bus_accurate)co_return() into op_read/op_write, as well.
I could always just enable polymorphism for r_cpu if I wanted a build
that could swap between the two on-the-fly. That takes a performance
hit of ~10%, though.
Quote: |
> With the presence of opcode+cothread, it's apparently more accurate than cycle based.
That's what I understood. |
Yep, my explanantions must be lousy, but let me try again... because
the CPU is running in a separate thread, I can stop right in the middle
of a function, whenever I want, wherever I want, and go to another core
to synchronize back up. So I essentialy now have infinite precision,
but the code is written just like an opcode based core. Without the
cothreading, I would have no choice but to split the core up by
breaking the opcode apart into 6-8 subopcodes, or "cycles". For bus
accuracy, I would have to split each one of those in half. That would
be so that I could return from the CPU core and run the APU/PPU/DSP/etc
to catch those up when necessary. Does that explain things better?
|
Yes, I got the gist of it thanks. edit: Although, I think for most non
programmers, it will remains a bit theoretical (even though they can
understand the general idea without too much problems)
edit: Obviously meant: "For most NON-programmers" of course
Quote: |
GRAH, I can't wait to get off of work today so I can start on this already >:D |
|
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Sat May 13, 2006 8:16 am Post subject: |
|
Regarding savestates: Why not use PSR for it? That way, changing stuff won't break the format. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat May 13, 2006 8:59 am Post subject: |
|
This context-switching sync method will probably require more than simply 'PSR'.
PSR is great to work on set variables, but doesn't do anything about stacks.
To restore everything, a save state should hold all the context stacks,
along with something telling which thread was active when the state was
saved.
Tricky.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
-_pentium5.1_- Lurker
Joined: 04 Sep 2004
Posts: 193
Location: USA
|
Posted: Sat May 13, 2006 7:36 pm Post subject: |
|
Quick
question: How do you suggest resolving the issue where there is a
slight tearing/desync of bsnes' image between the two triangles created
by D3D? See this screenshot (link).
I had to take the picture using a digital camera since I found it
essentially impossible to capture the proper frame using the Print
Screen key. The camera used a shutter speed of 1/10 or 1/13 (can't
remember which). The ROM in the photo is Memblers' NSF player for SNES
with the 32Mbit library patch, after pressing Start to select one of
the built-in NSFs.
_________________
This signature intentionally contains no text other than this sentence. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sat May 13, 2006 8:03 pm Post subject: |
|
tripods for the win. could you also provide proof this affects things outside of that NSF player?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 15, 2006 8:22 am Post subject: |
|
Ok, didn't get much time this weekend to work on anything, sadly.
Me and my roommate "came across" a nice 36" television for only free
ninety-nine this weekend, so obviously we had a lot of cabling to buy
and movie watching to do :)
While small to most I'm sure, the thing is absolutely massive compared to any TV I've ever owned.
Anyway, I really wanted to try out libco this weekend, so I managed to
rewrite the APU core in less than three hours, whee. Sadly, performance
went from ~80-82fps to ~75-77fps. Now, there's still plenty I can
optimize. I can reduce the number of synchronizations when accessing
certain areas of RAM easily enough, for example. I should also be able
to eliminate the virtual derived class function calls to
r_apu->run() all the time now. It will only need to be called once
since when I switch contexts the class instance handle is still on the
stack anyway. But I need to think about it for a few days to come up
with a clean way of doing it, that will still allow the old method to
work. I suspect I can probably match the old framerate, but not exceed
it by much. The benefit, however, is that the APU core is now much
cleaner. I really like it. And I can make those quick checks to swap
between an opcode-core and bus-accurate core.
So, everything worked out exactly as I had planned, excepting that the speed benefit didn't work out like I wanted.
One interesting side note is that I get the same 80-82fps with a purely
opcode-based core. Not too surprising, really. The APU was never really
that processor-intensive to begin with.
And actually, now that I'm thinking about it... I had to add a new
function call (op_io) to each APU cycle that didn't have a read/write
operation, which is probably where the speed loss came in. I also moved
from 256 functions inside a jump table to a switch/case for the opcode
table (eh, it's easier, code size is smaller, and compile time is
faster, so why not take a small speed hit?). Not much I can do about
the call to op_io... since I no longer split each cycle apart, I have
no other way to count I/O cycles.
I'll also split up the read/write cycles to simulate bus hold times
here soon. That will affect speed by a little, but not much.
So, too early to say. Still need to implement the CPU core, but that's
going to be a several week project since it's far more complicated with
its interrupts, H/DMA, etc than the APU core was. And I'm less hopeful
that a quick hack will allow opcode<>bus accuracy swapping.
However, the 256 opcodes should be compatible between the two, at least. |
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Mon May 15, 2006 7:21 pm Post subject: |
|
I have some info about Captain America.
The graphics should be fixed by returning 0x00 or 0x80 in some invalid memory areas on read.
I think it needs to be done in banks 00-3f 4900 - 5fff and 80-bf 4900 - 5fff.
And in some membank0 stuff that I don't understand.
For further reference look here. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 15, 2006 8:15 pm Post subject: |
|
I'm
not so sure. Foremost is that $[00-3f|80-bf]:[2000-5fff] is supposedly
all mapped to open bus, with the obvious exception of registers mapped
there (most notably $21xx and $42xx/$43xx, but also special chips like
the S-RTC, S-DD1 and SPC7110).
Next, the code you
referenced has the xor removed. Not that it matters since al is
overwritten on the next opcode anyway.
All versions (v1.45, v1.46 and v1.84) return the upper byte of the
address ($4920 would return $49, $52ff would return $52, etc), which is
essentially another inaccurate speedhack to simulate open bus, rather
than keeping a true MDR. It would return the incorrect value if you
used any indirect addressing mode, for example. To fix it, you need to
add a new CPU register that is set upon each read, and return that
value here instead. But I imagine you'll take a good speed hit for ~1-2
million additional copies a second in your CPU core, especially for the
SA-1.
Thank you for looking for a fix though, I appreciate it very much. |
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Mon May 15, 2006 9:09 pm Post subject: |
|
You
might also look at Snes9x' source code or ask some of the Snes9x
developers about it since it was fixed in Snes9x 1.37 to behave
correctly.
Edit:
More information that might be of use: http://snes9x.com/forum/topic.asp?TOPIC_ID=7293 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 17, 2006 9:16 am Post subject: |
|
Geez,
implemented a speedup to libco that helped P4s by 20%, but I get home
and it hurts my Athlon by 15%. Apparently, mov dword[eax+16],ebp is
faster than push ebp on Athlon processors. Oh well, it's still a better
processor since it isn't pipelined to all hell and back.
Anyway, cleaned up the CPU<>APU synchronization a -tad-. I'm
pretty sure my dividing of the CPU/APU clocks by eight was causing
infinitesimal sync misses, so I went ahead and removed that and cast
the counter to a 64-bit variable so that it won't overflow anymore when
using the full clock amount. Surprisingly enough, this resulted in no
speed loss whatsoever.
I also added bus synchronization to the APU core. So yay, the first
emulated SNES processor to ever have true bus synchronization is now in
bsnes. No speed hit. In fact, it's faster now at 76-78fps.
I don't know of any games that will ever benefit from this, but hey... it's there, right? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed May 17, 2006 9:54 am Post subject: |
|
byuu wrote: |
Geez,
implemented a speedup to libco that helped P4s by 20%, but I get home
and it hurts my Athlon by 15%. Apparently, mov dword[eax+16],ebp is
faster than push ebp on Athlon processors. |
You can put in an ifdef based on processor.
And I have code to pretty much detect all the main processors for you 
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 17, 2006 10:14 pm Post subject: |
|
Quote: |
You can put in an ifdef based on processor. |
1) I don't have the time nor resources to profile the code on every x86-compatible processor architecture.
2) A compile-time compare will only be fast if the end user compiles it, or I release separate builds. And I need
to avoid separate builds. So far, I want a debugger build (10% speed
hit for having it), an accurate (bus-accurate) build, a fast
(opcode-based) build, and maybe SSE2 builds. So many options... :(
3) A runtime compare will slow things down everywhere. The compare
alone would make performance worse on the A64 build, regardless of
which I use. I'd rather optimize for one processor or the other.
Here are the comparison results so far. I'm at work so I can't post
accurate A64 timings until I get home. The numbers below are pretty
accurate, though.
Code: |
context -> memory vs stack
---------------------------
p4 call = 17.44x vs 10.97x
p4 jump = 12.44x vs 11.62x
a64 call = 6.50x vs 7.50x
a64 jump = 6.50x vs 7.50x |
The x is the number of times slower it is to use co_call(newproc) +
co_return() or co_jump(newproc) + co_jump(oldproc) than it is to call
newproc() + return() (eg standard subroutine calling and returning).
P4 stack method :
Code: |
_co_jump:
;backup current context
mov eax,dword[__co_active_context]
push ebp
push esi
push edi
push ebx
mov dword[eax],esp
;get handle to new thread heap space
mov eax,dword[esp+20] ;+4(co_jump)+16(regs)
;set new active context
mov dword[__co_active_context],eax
;restore context for new active thread
mov esp,dword[eax]
pop ebx
pop edi
pop esi
pop ebp
;invoke new active thread
ret |
A64 memory method :
Code: |
_co_jump:
;backup current context
mov eax,dword[__co_active_context]
mov dword[eax],esp
mov dword[eax+4],ebp
mov dword[eax+8],esi
mov dword[eax+12],edi
mov dword[eax+16],ebx
;get handle to new thread heap space
mov eax,dword[esp+4] ;+4(co_jump)
;set new active context
mov dword[__co_active_context],eax
;restore context for new active thread
mov esp,dword[eax]
mov ebp,dword[eax+4]
mov esi,dword[eax+8]
mov edi,dword[eax+12]
mov ebx,dword[eax+16]
;invoke new active thread
ret |
co_call and co_return are identical. The only differences are that
co_call saves the old context in the new context stack heap, and
co_return lacks an argument and reads the new context to jump to from
the stack heap (which is the old context).
I have absolutely no idea why co_call / co_return is so much slower
than co_jump in the A64-optimized memory-based method. I really, really
don't.
Also note that bsnes uses co_call / co_return so that I can nest context switches as needed.
That said... should I just use the P4 optimized code in all versions? The P4 gains a lot more than the A64 code loses. But dammit, I personally use an A64 and I don't want my version running slower :(
Last edited by byuu on Wed May 17, 2006 10:49 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed May 17, 2006 10:34 pm Post subject: |
|
byuu wrote: |
Quote: |
You can put in an ifdef based on processor. |
1) I don't have the time nor resources to profile the code on every x86-compatible processor architecture.
|
Don't. Just do it for the few that can basically run bsnes. Athlon XP, K8, Pentium M and 4.
byuu wrote: |
2) A compile-time compare will only be fast if the end user compiles it, or I release separate builds. And I need
to avoid separate builds. So far, I want a debugger build (10% speed
hit for having it), an accurate (bus-accurate) build, a fast
(opcode-based) build, and maybe SSE2 builds. So many options... 
|
(someone bring on the grasshopper quote)
You can make libco have multiple versions of the functions that matter,
use a pointer which at run time is set based on CPU detection to the
propper function, the libco function(s) is only accessed via this/these
pointer(s).
With this method you don't even need to compile multiple times.
Also if you don't want the pointer (which AFAIK is the same as direct
on modern x86 processors), you can use objcopy magic to make binaries
twice the size, but contain two archs in one.
byuu wrote: |
3) A runtime compare will slow things down everywhere. The compare
alone would make performance worse on the A64 build, regardless of
which I use. I'd rather optimize for one processor or the other.
|
As stated above the trick is to do it once, not every time. Long live pointers, or multiarch.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 17, 2006 11:05 pm Post subject: |
|
I
have serious doubts that indirect memory accesses are equally as fast
as direct memory accesses, pipelines be damned. Maybe even simply
better for cache or something. And if they are, then the direct
accesses are woefully underoptimized. But anyway, the direct accesses
for the stack push/pops are faster than the memory accesses for
saving/restoring regs in the code above. At least on P4s...
I prefer to not use pointer magic. But if it really is the same speed
on every system... then what choice do I have? :/
I'm only targeting an AMD and Intel version. To hell with their variants.
The only way you can compile two versions and be as fast as only having
one non-virtual/pointer function is to manually overwrite all
references to the function call address with the new function address
in the actual program code. Otherwise, you're making a sacrifice
somewhere. This of course assuming indirect is slower than direct
accesses. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed May 17, 2006 11:22 pm Post subject: |
|
Reading
the AMD manual I interpret it this way. There is no speed reduction
using near indirect jumps as long as the data is aligned properly, in
the case of a far jump the processor adds 1 cycle. So there really
isn't any difference on a modern CPU. I would assume gcc or MSVC,
whatever you are using would align the data properly so this wouldn't
be a problem. Also pushing/pop from stack and memory, at least on an
Athlon 64 has the same cycle count of 3 cycles so it wouldn't matter
what you did. I will look up what it is on an Athlon XP but I would
expect it is about the same or perhaps 1 cycle difference. It's not
really something I would worry about unless I was trying to make code
to run in a P5. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 18, 2006 12:01 am Post subject: |
|
Well,
you can see from my code timing that the indirect memory writes are
significantly faster than the stack push/pops. I'd love to get the same
speed on both, as the manual says I should. Then I would only need one
version. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 18, 2006 12:02 am Post subject: |
|
byuu wrote: |
Well,
you can see from my code timing that the indirect memory writes are
significantly faster than the stack push/pops. I'd love to get the same
speed on both, as the manual says I should. Then I would only need one
version. |
If it's not the same, use two versions, run time detect, and a pointer,
you really have no reason not to, and it's not a big deal.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 18, 2006 12:59 am Post subject: |
|
Quote: |
If
it's not the same, use two versions, run time detect, and a pointer,
you really have no reason not to, and it's not a big deal. |
Well, it is to me. I prefer simplicity above all else. I would have to
change the implementation details to allow for a profiler to determine
which to use, and something to swap all of the function variables with.
Quote: |
Also
pushing/pop from stack and memory, at least on an Athlon 64 has the
same cycle count of 3 cycles so it wouldn't matter what you did. |
Directly to memory, you are right, however...
mov mem32,reg32 -- 3 cycles
mov reg32,mem32 -- 3 cycles
mov mreg32,reg32 -- 1 cycle
mov reg32,mreg32 -- 1 cycle
push reg -- 3 cycles
pop reg -- 3 cycles
pushad -- 6 cycles
popad -- 6 cycles
It doesn't say if the 1 cycle rule applies to mov mem32+index,reg32 and
mov reg32,mem32+index, but it probably does. That or the addition makes
it 2 cycles, most likely.
pushad and popad are obviously no good since there's only four registers we're saving and restoring.
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 18, 2006 2:10 am Post subject: |
|
byuu wrote: |
Quote: |
If
it's not the same, use two versions, run time detect, and a pointer,
you really have no reason not to, and it's not a big deal. |
Well, it is to me. I prefer simplicity above all else. I would have to
change the implementation details to allow for a profiler to determine
which to use, and something to swap all of the function variables with.
|
I must be misunderstanding what you're doing, because you shouldn't
have to change the implementation or function variables in any way.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Thu May 18, 2006 3:32 am Post subject: |
|
I'm
sorry if this is a common problem, but whenever I start bSNES, I get an
error box that reads, "Failed to create Direct3D9 device". I have the
correct Direct X drivers installed, and I have the latest driver for my
video card installed. I am using bSNES version 0.016.
Thank you in advance. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu May 18, 2006 3:43 am Post subject: |
|
Yeah, I've gotten that in Vista (5342 and 5365, iirc) as well as when I nuked and reformatted my XP.
You can deal with the vista at your leasure, just giving you a heads up
for when, oh say, you know, it gets released.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu May 18, 2006 5:04 am Post subject: |
|
Aaron wrote: |
I'm
sorry if this is a common problem, but whenever I start bSNES, I get an
error box that reads, "Failed to create Direct3D9 device". I have the
correct Direct X drivers installed, and I have the latest driver for my
video card installed. I am using bSNES version 0.016.
Thank you in advance. |
Set the video setting in the .cfg file from D3D to DD.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 18, 2006 5:29 am Post subject: |
|
I
need to add reasons for errors. Most likely you don't have enough VRAM.
You need more than 4MB, which lots of onboard video cards lack.
Otherwise, I don't know why it's failing.
I'll try and lower VRAM requirements for the next release. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu May 18, 2006 9:49 pm Post subject: |
|
Yea, I just ran this Windows Vista tool for Win XP, and it told me I need a little more VRAM for Vista.
My question is, how do you increase the VRAM in Windows?
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu May 18, 2006 10:15 pm Post subject: |
|
You don't.
If you have onboard video, see if there's an option to
increase/decrease your vram in the BIOS, or buy a new video card.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu May 18, 2006 10:28 pm Post subject: |
|
adventure_of_link wrote: |
You don't.
If you have onboard video, see if there's an option to
increase/decrease your vram in the BIOS, or buy a new video card. |
Thanks. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu May 18, 2006 10:29 pm Post subject: |
|
No problem man. 
_________________

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


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Fri May 19, 2006 1:02 am Post subject: |
|
Nach wrote: |
you shouldn't have to change the implementation or function variables in any way. |
Example time !
Code: |
rtype1 stuff_ati(ptype param)
{
stuff_1();
i++; // this is hypothetically faster for ati
stuff_2();
return ((rtype1)exit_code);
}
rtype1 stuff_intel(ptype param)
{
stuff_1();
i+=1; // this is hypothetically faster for intel
stuff_2();
return ((rtype1)exit_code);
}
int get_cpuinfo();
// grabs cpu info if possible and returns the cpu arch type
void (*stuff)();
int main()
{
int arch = get_cpuinfo();
switch(arch)
{
default: // default uses ati-profiled functions
case 0: // not found, same as above
case 1: // opteron
case 2: // athlon64
// several cases skipped
case 11: // k6
stuff = stuff_ati;
break;
case 12: // nocona
case 13: // prescott
// more cases skipped
case 22: // pentium
stuff = stuff_intel;
break;
}
// more code skipped here
}
rtype2 random_func(<random params/param types>)
{
// code skipped...
stuff();
// more code skipped...
} |
Hopefully this example makes it clearer and not worse.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 19, 2006 1:56 am Post subject: |
|
Thank
you for trying to help, but I learned how to program in C ten years
ago. By the way, since when has ATI been developing x86 processors? :)
I'd rather just aim for the best tradeoff between the two and leave it
at that, than add all of this extra complexity. Even at +20 cycles for
the originally ~20 cycle function, overhead only increased from 6.5x to
7.5x on the A64 processor. So clearly the real bottleneck is the
unavoidable pipeline stall and cache invalidation of switching contexts.
Oh, by the way... today I thought that for the call/return functions I
could just use xchg [eax+index],ebp etc to swap registers out, rather
than mov [eax+index],ebp + mov ebp,[ecx+index]. The result was
___102x___ slower than normal function calls. An order of magnitude
slower than the 2x mov approach. Holy shit am I ever seriously
concerned about the future of processor development. Clock speeds
really don't
matter anymore with things like this thrown in there. This was on the
P4, by the way. On the Athlon, xchg mreg,reg takes 2 clock cycles
compared to mov mreg,reg's 1. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri May 19, 2006 6:59 am Post subject: |
|
byuu wrote: |
Oh,
by the way... today I thought that for the call/return functions I
could just use xchg [eax+index],ebp etc to swap registers out, rather
than mov [eax+index],ebp + mov ebp,[ecx+index]. The result was
___102x___ slower than normal function calls. An order of magnitude
slower than the 2x mov approach. Holy shit am I ever seriously
concerned about the future of processor development. Clock speeds
really don't matter anymore
with things like this thrown in there. This was on the P4, by the way.
On the Athlon, xchg mreg,reg takes 2 clock cycles compared to mov
mreg,reg's 1. |
Those special purpose opcodes are a "relict" from the CISC era. Newer
RISC-based processors often sacrifice their speed in favor of the
opcodes that are used more often by compilers.
EDIT: link
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri May 19, 2006 12:23 pm Post subject: |
|
creaothceann wrote: |
Those special purpose opcodes are a "relict" from the CISC era. Newer
RISC-based processors often sacrifice their speed in favor of the
opcodes that are used more often by compilers.
|
Yeah these opcodes are often emulated in microcode rather than implemented in silicon.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 19, 2006 5:17 pm Post subject: |
|
Quote: |
Yeah these opcodes are often emulated in microcode rather than implemented in silicon. |
That's how I figured obscure MOVZQRIIWNP mreg16,reg16 (move
double-precision floating point integer in hyperspace into precached
single-precision doublequad phase inducing capacitor-space memory)
opcodes would be implemented, but not a basic opcode like xchg. And
wow, what an amazing performance hit for silicon->microcode. They
should really
have manuals out there indicating for each chip what is silicon and
what is microcode, so that the latter can be avoided like the plague.
Well for now, push + pop method wins. The memory-method stalls out the
P4 co_call + co_return functions badly. Probably because it has two
unavoidable switches between mem->reg and reg->mem, whereas the
push + pop method only has one. As a result, push + pop does not stall
out either processor on either method.
Edit: ok, optimized the memory read vs write and address accesses as
much as possible, and aligned all code+variable accesses, and I now
have :
Code: |
%define ptrOld eax
%define ptrNew ecx
align 4
_co_jump:
mov ptrNew,dword[esp+4] ;get handle to new thread heap space
mov ptrOld,dword[__co_active_context] ;backup current context
mov dword[__co_active_context],ptrNew ;set new active context
push ebp
push esi
push edi
push ebx
mov dword[ptrOld],esp
mov esp,dword[ptrNew]
pop ebx
pop edi
pop esi
pop ebp
ret |
co_call and co_return are identical, but co_call has one extra opcode
to save the current context inside [ptrNew+4], co_return accesses
[ptrOld+4] instead of [esp+4].
-- all tests below on Pentium IV 1.7ghz processor --
windows fibers method :
co_call = 9562 clocks, 21.88x overhead
co_jump = 7422 clocks, 16.98x overhead
subroutines = 437 clocks
memory method :
co_call = 7359 clocks, 16.84x overhead
co_jump = 5141 clocks, 11.76x overhead
subroutines = 437 clocks
stack method :
co_call = 4594 clocks, 10.49x overhead
co_jump = 3656 clocks, 8.35x overhead
subroutines = 438 clocks
Basically there's a ~64% speed increase for co_call method and a ~41%
speed increase for co_jump method using the stack approach vs memory
approach. Whereas on the Athlons, 7.5x / 6.5x = ~15% speed hit for both
methods. That plus the greater dominance of P4s (sadly), means the best
choice is clear.
But compared to windows fibers, writing the library myself has gained
me ~108% speed increase for co_call method, and ~103% over co_jump
method. Both more than twice as fast.
It's too bad the windows fiber code pretty much had
to be written in assembler. This would make a great argument for my
case that hand-optimized x86 assembler written by a talented programmer
can easily beat out optimized c++ code by 50-100% or more, at least on
the x86 architecture. Although I now believe that claim is heavily
dependant on the exact processor + memory configuration in use :/
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Fri May 19, 2006 8:40 pm Post subject: |
|
Out of curiosity, have you tested this bad boy on both XP-32 and XP-x64? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 19, 2006 8:57 pm Post subject: |
|
I
do not have WinXP 64-bit edition, nor access to a computer with it
installed. However, the x86 version will not work with the processor. I
can port the soruce code (and know exactly how to already), but I have
no idea how I'll be able to assemble it. It will be slower. It has
to push twice as much data per register, and two additional registers
onto the stack, and then pop the same amount.
32-bit { ebx, esi, edi, ebp, esp } -> 64-bit { rbx, r8, r9, r10,
r11, rbp, rsp }. 160*2 bits -> 448*2 bits, 2.8x more information.
I'm going to wait until 64-bit stuff is a bit more common, or wait
until someone ports my existing code for me and gets it to build :) |
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Fri May 19, 2006 9:21 pm Post subject: |
|
byuu wrote: |
However,
the x86 version will not work with the processor. I can port the soruce
code (and know exactly how to already), but I have no idea how I'll be
able to assemble it. It will be slower. It has to push twice as
much data per register, and two additional registers onto the stack,
and then pop the same amount.
32-bit { ebx, esi, edi, ebp, esp } -> 64-bit { rbx, r8, r9, r10,
r11, rbp, rsp }. 160*2 bits -> 448*2 bits, 2.8x more information. |
Figured so much, but it was worth asking. My Athlon64 runs xp-x64 and
it's a mixed bag, but utterly unstable due to pretty bad nforce3
chipset drivers.
Be happy you're stuck with 32-bit stuff for now .
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri May 19, 2006 9:58 pm Post subject: |
|
byuu wrote: |
I
do not have WinXP 64-bit edition, nor access to a computer with it
installed. However, the x86 version will not work with the processor. I
can port the soruce code (and know exactly how to already), but I have
no idea how I'll be able to assemble it. It will be slower. It has
to push twice as much data per register, and two additional registers
onto the stack, and then pop the same amount.
32-bit { ebx, esi, edi, ebp, esp } -> 64-bit { rbx, r8, r9, r10,
r11, rbp, rsp }. 160*2 bits -> 448*2 bits, 2.8x more information. |
Um, while is this is logically correct, it is incorrect at the same
time. 64-bit CPU's also move more data per clock than 32-bit so the
difference is hardly noticable. We wouldn't be using 64-bit code if it
was going to be that much slower.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 19, 2006 10:38 pm Post subject: |
|
I
realize moving 64-bits of data at once on a 64-bit processor is faster
than moving 64-bits of data as two separate operations on a 32-bit
processor. But we can both agree the 64-bit context switching code will
be slower. By how much, I've no idea. |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Sat May 20, 2006 12:12 am Post subject: |
|
pagefault wrote: |
creaothceann wrote: |
Those special purpose opcodes are a "relict" from the CISC era. Newer
RISC-based processors often sacrifice their speed in favor of the
opcodes that are used more often by compilers.
|
Yeah these opcodes are often emulated in microcode rather than implemented in silicon.
|
I don't think XCHG is emulated, but this is the real reason it is so slow:
Quote: |
The
XCHG register,memory instruction is dangerous. By default this
instruction has an implicit LOCK prefix which prevents it from using
the cache. The instruction is therefore very time consuming, and should
always be avoided. |
byuu wrote: |
ok, optimized the memory read vs write and address accesses as much as possible, and aligned all code+variable accesses |
"Align 16" would be better for functions. "__fastcall" can also be used
to speed up function calls by using ecx/edx to pass args instead of the
stack. Also, "co_delete" randomly leaks memory because MOV does not set
any flags on x86. "_free" checks for null anyway, so the entire
_co_delete function can simply be replaced by "jmp _free".
Code: |
;extern "C" void __fastcall co_jump(thread_t cothread);
align 16
@co_jump@4:
mov eax, dword[__co_active_context] ;backup current context
mov dword[__co_active_context], ecx ;set new active context
...
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat May 20, 2006 12:46 am Post subject: |
|
Quote: |
I don't think XCHG is emulated, but this is the real reason it is so slow: |
Ah, that definitely explains why it's so slow... thanks.
Quote: |
"Align 16" would be better for functions. |
Just noticed that NASM defaults to align 16 for code sections. I'll use align 16.
Quote: |
Also, "co_delete" randomly leaks memory because MOV does not set any flags on x86. |
Hahahah, oops. Nice catch. You can tell I'm used to the SNES
processors. I've read though that the behavior of calling free on an
invalid (null) memory address is undefined. Are you absolutely certain
that is not the case? I even see most programmers writing code like :
Code: |
if(ptr) { free(ptr); ptr = 0; } |
EDIT:
Quote: |
free() frees the memory space pointed to by ptr, which must have been
returned by a previous call to malloc(), calloc() or realloc(). Other-
wise, or if(3,n) free(ptr) has already been called before, undefined behav-
iour occurs. If ptr is NULL, no operation is performed. |
Hmmm, it would be nice to avoid calling free twice resulting in
undefined behavior, but there's no way I could account for that anyway.
Quote: |
"__fastcall" can also be used to speed up function calls by using ecx/edx to pass args instead of the stack. |
I was actually just talking about __fastcall on the mameworld.info
forums. I was saying I didn't want to use it because of the name
decorations that result from it. I decided to go ahead and give it a
try anyway, and got surprising results :
co_call as a __fastcall went from 4562 clocks to 4516 clocks, an improvement.
co_jump as a __fastcall went from 3610 clocks to 4469 clocks, a major speed hit.
Apparently, the Pentium IV is one stupid, stupid processor. That, or MSVC is a bad compiler. Or both ;)
The __fastcall co_jump function :
Code: |
align 16
@co_call@4:
; mov ecx,dword[esp+4] ;get handle to new thread heap space
mov eax,dword[__co_active_context] ;backup current context
mov dword[__co_active_context],ecx ;set new active context
mov dword[ecx+4],eax ;backup pre-call context
push ebp
push esi
push edi
push ebx
mov dword[eax],esp
mov esp,dword[ecx]
pop ebx
pop edi
pop esi
pop ebp
ret |
The only
difference between the two functions is the one stack access at the top
being enabled/disabled. Same for co_call. co_return was left as a
normal function since it doesn't take any arguments anyway.
The only other thing changed was the c++ define from :
extern "C" void co_jump(thread_t cothread);
to :
extern "C" void __fastcall co_jump(thread_t cothread);
Absolutely bizarre. This should definitely be faster, but isn't. I have
no idea why. If this helps, here is the CPUID output :
Code: |
CPUID Output
------------------------------------------------------------------------------
Number of CPUs 1
APIC ID 0
Name Intel Pentium 4
Code name Willamette
Specification Intel(R) Pentium(R) 4 CPU 1.70GHz
Family/Model/Stepping F12
Extended Family/Model 0/0
Brand ID 8
Package mPGA-478 (2h)
Core Stepping D0
Technology 0.18um
Instructions Sets MMX, SSE, SSE2
Features
Clock Speed 1695.0 MHz
Clock multiplier x17.0
Front Side Bus Frequency 99.7 MHz
Bus Speed 398.8 MHz
Stock frequency 1700 MHz
L1 Data Cache 8 KBytes, 4-way set associative, 64 Bytes line size
L1 Trace Cache 12 Kuops, 8-way set associative
L2 Cache 256 KBytes, 8-way set associative, 64 Bytes line size
L2 Speed 1695.0 MHz (Full)
L2 Location On Chip
L2 Data Prefetch Logic yes
L2 Bus Width 256 bits |
This should be faster on my Athlon64. Should I use the __fastcall
convention anyway, and just ignore the P4 stupidity?
EDIT: I think I might know what it is :
Code: |
start = clock();
for(i = 0, global_i = 0; i < 50000000; i++) {
co_jump(sub_thread);
}
end = clock();
//
void sub_timingtest() {
global_i++;
} |
It's probably using ecx for i, and the fastcall is causing that
register to save / restore itself. So the compiler is just being
stupid. So then, what do I optimize for? Though uncommon, it's possible
my libco will be used in loops just like that, after all. And it's the
only way I presently have to profile the code speed.
Still, if it used ecx for i, then it would have to push / pop it either
way, since callees are not required to save ecx. Eh, I'll disassemble
the code when I get home tonight.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 23, 2006 9:23 am Post subject: |
|
Eh, I think I have it now.
Page is here: http://byuu.org/?page=libco
Has a general description of the library (basically a rehash of what's
already been said here, on the NESdev forum, and the mameworld forum)
and download.
If anyone has any obscure processors (VIA processors, older 486's,
etc), I'd appreciate if you were to run the included two programs
(main_x86 and main_win32) and post the output you get here. My theory
is that we'll get a bell curve in performance between the processors.
80386 will have poor performance, Pentium (maybe 2) or AMD K6-2 will
have the best performance, and Pentium IV will have the worst. We'll
see, though :)
And better yet, if anyone wants to port the library to their favorite
OS cothreading API, or write their own implementation in assembler
(even better!), please do! I'm not going to make a sourceforge page for
this, but I would like to help create a fast, simple, general purpose
cothreading library that is as platform-independant as possible. And
presently, the Mac OS X version of bsnes cannot be compiled with the
new APU core due to not having a library available for that processor /
OS.
---
I also tried reducing the VRAM requirements in Direct3D, and modified
an option or two, in hopes of solving the "failed to create direct3d9
device". If anyone is receiving this error and wants to see if its
fixed now, please PM me and I'll send you a link to a WIP build. Don't
ask for it if you aren't having the problem. This build isn't optimized
at all and runs ~40% slower than release versions. I just want to know
if the problem is fixed or not now. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 23, 2006 10:25 am Post subject: |
|
Good writeup on libco, sounds like it's coming along nicely. It's pretty ingenious, really, if it works out.
I'm upgrading to a core 2 duo this summer. Should be good for bsnes Both AMD and Intel are now going to be using short pipeline strategies from here on out I'm guessing.
Last edited by FitzRoy on Tue May 23, 2006 10:28 am; edited 1 time in total |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue May 23, 2006 10:27 am Post subject: |
|
Yeah
the preformance on my P4 2Ghz really isn't that different between the
exes. I'd test it on my P 100Mhz, but I think I need something higher
then windows 95 to test it with. Atleast the kernel doesn't support
those functions it needs. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 23, 2006 12:00 pm Post subject: |
|
byuu:
"Any code submitted to this library must fall under this same library,
and be submitted to me as public domain for inclusion."
Doesn't sound right.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue May 23, 2006 12:47 pm Post subject: |
|
main-win32
clocks per second = 1000
4109 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2516 clocks / 100,000,000 co_jump calls (50000000 iterations)
265 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.505660x
co_jump skew = 9.494340x
main-x86
clocks per second = 1000
1625 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1516 clocks / 100,000,000 co_jump calls (50000000 iterations)
265 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.132075x
co_jump skew = 5.720755x
done |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 23, 2006 3:19 pm Post subject: |
|
Quote: |
byuu:
"Any code submitted to this library must fall under this same library,
and be submitted to me as public domain for inclusion."
Doesn't sound right. |
Basically, any code submitted must be license-free, that way it can be
included. Obviously, BSD-license would be fine, too, since that's what
I'm using. I should clarify that when I get home tonight.
---
Quote: |
co_call skew = 6.132075x
co_jump skew = 5.720755x |
Great scores, thanks pagefault! Definitely can tell that's an AMD processor, heheh.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 23, 2006 3:22 pm Post subject: |
|
byuu wrote: |
Quote: |
byuu:
"Any code submitted to this library must fall under this same library,
and be submitted to me as public domain for inclusion."
Doesn't sound right. |
Basically, any code submitted must be license-free, that way it can be
included. Obviously, BSD-license would be fine, too, since that's what
I'm using. I should clarify that when I get home tonight.
|
Well, remove the "must fall under this same library" clause, and replace with something more readable 
_________________
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: Tue May 23, 2006 4:16 pm Post subject: |
|
Not sure if this relevant as I have a P4 @ 2.4ghz Prescott but here's my result:
main_win32
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
6562 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
4594 clocks / 100,000,000 co_jump calls (50000000 iterations)
250 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 26.248000x
co_jump skew = 18.376000x
done
main_x86
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
2687 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2625 clocks / 100,000,000 co_jump calls (50000000 iterations)
250 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 10.748000x
co_jump skew = 10.500000x
done |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue May 23, 2006 4:34 pm Post subject: |
|
For the fun of it, here's my P4 at 3.2ghz...
main-win32
clocks per second = 1000
4109 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2516 clocks / 100,000,000 co_jump calls (50000000 iterations)
265 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 26.611872x
co_jump skew = 18.264840x
done
main-x86
clocks per second = 1000
1625 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1516 clocks / 100,000,000 co_jump calls (50000000 iterations)
265 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 11.083744x
co_jump skew = 9.926108x
done
Oh, and I sent you a PM byuu about the D3D thing.  |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Tue May 23, 2006 6:04 pm Post subject: |
|
Results on linux (debian etch) with gcc 4.1:
P4 NW 2.26@2.6 GHz
unoptimized:
clocks per second = 1000000
3070000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2860000 clocks / 100,000,000 co_jump calls (50000000 iterations)
300000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 10.233333x
co_jump skew = 9.533333x
optimized with "-O3 -fno-inline-functions -fomit-frame-pointer" (still valid I think):
clocks per second = 1000000
3000000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2850000 clocks / 100,000,000 co_jump calls (50000000 iterations)
200000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.000000x
co_jump skew = 14.250000x
K6-III 450 MHz
unoptimized:
clocks per second = 1000000
6580000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
6360000 clocks / 100,000,000 co_jump calls (50000000 iterations)
1130000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 5.823009x
co_jump skew = 5.628319x
optimized with "-O3 -fno-inline-functions -fomit-frame-pointer" (still valid I think):
clocks per second = 1000000
6690000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
6230000 clocks / 100,000,000 co_jump calls (50000000 iterations)
570000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 11.736842x
co_jump skew = 10.929825x |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue May 23, 2006 6:48 pm Post subject: |
|
tonight I'll post results on my a64 x2 using debian sid x86_64.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue May 23, 2006 6:51 pm Post subject: |
|
Nach wrote: |
byuu wrote: |
Quote: |
byuu:
"Any code submitted to this library must fall under this same library,
and be submitted to me as public domain for inclusion."
Doesn't sound right. |
Basically, any code submitted must be license-free, that way it can be
included. Obviously, BSD-license would be fine, too, since that's what
I'm using. I should clarify that when I get home tonight.
|
Well, remove the "must fall under this same library" clause, and replace with something more readable
|
Any code submitted to this library must be submitted under the libco license.
or something to that effect.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 23, 2006 7:29 pm Post subject: |
|
Anyone without P4s or Athlon K8s? :)
sinimas, glad to see it works on linux. I imagine you had to change
_malloc and _free to malloc and free. Need to add some define magic to
it.
Optimizing is a bad idea (for timing code, at least), and will break
the test. Compiler optimizations turn code like:
Code: |
void myproc() {}
void main() {
for(int i = 0; i < 1000000; i++)myproc();
printf("%d", i);
} |
into
Code: |
str db "%d",0
_main:
push 1000000
push str
call _printf
add esp,8 |
Not exactly ideal when you're trying to benchmark the speed of calling myproc, hm?
So far, results are consistent as I'd imagine. The older K3 with less
pipelining than modern processors performs better. My last prediction
is that the oldest processors (386, maybe 486) will perform even worse,
due to the extremely limited pipelining not being able to cache the
opcode instructions quickly enough / completely. So due to there being
so many more opcodes than a simple call, overhead will go up to ~15x or
so. It's a good thing the processor speeds are increasing so rapidly to
counter the speed loss of thread switching. With a multitasking OS, or
a true pre-emptive database server, I imagine this overhead can make a
serious impact on performance.
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Tue May 23, 2006 7:54 pm Post subject: |
|
Will test on the following tonight or tomorrow at the latest:
Athlon-XP with xp-x64
AMD Duron 800 with FreeBSD
Pentium-M laptop with xp-32
Edit: I think I also have a 1GHz first-gen Athlon to test on, running win2k3. That too. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Tue May 23, 2006 8:29 pm Post subject: |
|
byuu wrote: |
Anyone without P4s or Athlon K8s? 
sinimas, glad to see it works on linux. I imagine you had to change
_malloc and _free to malloc and free. Need to add some define magic to
it.
Optimizing is a bad idea (for timing code, at least), and will break
the test. Compiler optimizations turn code like:
Code: |
void myproc() {}
void main() {
for(int i = 0; i < 1000000; i++)myproc();
printf("%d", i);
} |
into
Code: |
str db "%d",0
_main:
push 1000000
push str
call _printf
add esp,8 |
Not exactly ideal when you're trying to benchmark the speed of calling myproc, hm?.
|
I commented the linker macros from libco_x86.asm, defined __fastcall
__attribute__((fastcall)) in libco_x86.h, and replaced <conio.h>
with <curses.h> in main.cpp.
I don't think the optimizations invalidated the test, since I defined
global_i volatile and disabled inlining. If I allow function inlining
and don't mark global_i volatile, number of clocks for the subroutine
calls becomes 0, since it's all optimized away.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 23, 2006 9:19 pm Post subject: |
|
funkyass wrote: |
Nach wrote: |
byuu wrote: |
Quote: |
byuu:
"Any code submitted to this library must fall under this same library,
and be submitted to me as public domain for inclusion."
Doesn't sound right. |
Basically, any code submitted must be license-free, that way it can be
included. Obviously, BSD-license would be fine, too, since that's what
I'm using. I should clarify that when I get home tonight.
|
Well, remove the "must fall under this same library" clause, and replace with something more readable
|
Any code submitted to this library must be submitted under the libco license.
or something to that effect.
|
However there isn't a "libco license" but there is the BSD license which is what libco is curerently using.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Tue May 23, 2006 10:33 pm Post subject: |
|
Probably late, but scores are almost the same as pagefaults. I have an X2 @2.4GHz.
main_win32:
Code: |
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
3640 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2297 clocks / 100,000,000 co_jump calls (50000000 iterations)
234 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.555556x
co_jump skew = 9.816239x
done |
main_x86:
Code: |
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
1484 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1391 clocks / 100,000,000 co_jump calls (50000000 iterations)
234 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.341880x
co_jump skew = 5.944444x
done |
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
Last edited by Clements on Tue May 23, 2006 11:56 pm; edited 1 time in total
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Tue May 23, 2006 10:34 pm Post subject: |
|
Pentium-M 1.5GHz, xp-32, tested using binaries from byuu.org:
main-x86
clocks per second = 1000
2613 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2324 clocks / 100,000,000 co_jump calls (50000000 iterations)
310 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 8.429032x
co_jump skew = 7.496774x
done
main-win32
clocks per second = 1000
6329 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
4085 clocks / 100,000,000 co_jump calls (50000000 iterations)
311 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 20.350482x
co_jump skew = 13.135048x
done |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue May 23, 2006 10:38 pm Post subject: |
|
Sorry byuu, I should of posted my scores before.
main_win32:
test should return '1234567'
1234567
clocks per second = 1000
7046 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
4985 clocks / 100,000,000 co_jump calls (50000000 iterations)
375 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 18.789333x
co_jump skew = 13.293333x
main_x86:
test should return '1234567'
1234567
clocks per second = 1000
4875 clocks / 50,000,000 co_call + co_return calls (50000000 iterations
4484 clocks / 100,000,000 co_jump calls (50000000 iterations)
375 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 13.000000x
co_jump skew = 11.957333x
Edit: Pentium IV Northwood 2Ghz @ 100Mhz FSB
Last edited by powerspike on Wed May 24, 2006 2:04 am; edited 4 times in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 23, 2006 11:40 pm Post subject: |
|
I
need to know the processor type. And there's no need to test the same
processor again (eg Pentium IV) if it's already been tested. Though I
guess it's good to know this is stable on all systems tested so far, at
least.
I'm very glad to see that the Pentium M
performs better than the Pentium IV. That's definitely a good trend.
Faster clocks through faster busses, with less multipliers and less
pipelines. More cores for multitasking. The future looks good :) |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed May 24, 2006 12:26 am Post subject: |
|
For the record mine is currently an Athlon XP 2400+ o/ced to 2.2ghz at 182mhz FSB. |
|
Starman Ghost Veteran

Joined: 28 Jul 2004
Posts: 991
|
Posted: Wed May 24, 2006 12:57 am Post subject: |
|
On my Athlon XP 3000+ Barton @ 2.154ghz
main_win32
Code: |
clocks per second = 1000
4203 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2609 clocks / 100,000,000 co_jump calls (50000000 iterations)
281 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 14.957295x
co_jump skew = 9.284698x
|
main_x86
Code: |
clocks per second = 1000
1671 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1547 clocks / 100,000,000 co_jump calls (50000000 iterations)
266 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.281955x
co_jump skew = 5.815789x
|
_________________
Code: |
<Ranbert> someone shoot me please....
<tele> o \O_ Arrgh!!
<tele> <\==- - - - - - - --- __/
<tele> / \ \
|
θάνατος
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed May 24, 2006 1:20 am Post subject: |
|
byuu, I'm kinda interested in knowing how well the tests did on your system... |
|
kevman Redneck Gamer-Mod

Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
|
Posted: Wed May 24, 2006 1:32 am Post subject: |
|
byuu wrote: |
If anyone has any obscure processors ...
|
Righto, on it.
486, k6-2+, and MediaGX coming up. Check this post.
EDIT1: Whoops, not Win95 supported! What OS does this need?
its linked to missing export KERNEL32.DLL:ConvertThreadToFiber and IsDebuggerPresent.
If you require 2k/xp, there's nothing I can do.
_________________
SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!!
Steelers no longer officially own your ass. Pittsburgh will miss The Bus.
Last edited by kevman on Wed May 24, 2006 1:44 am; edited 1 time in total
|
|
Que saskatchewanite
Joined: 26 Apr 2006
Posts: 317
|
Posted: Wed May 24, 2006 1:37 am Post subject: |
|
I have access to athlon xp barton 3200+ and k8 4000+ machines. would those be of any use?
_________________
everything i say is a lie
the above line is true |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 24, 2006 1:42 am Post subject: |
|
MediaGX?? o_O
I get maybe 5% better scores than pagefault's Athlon 2400+ with my 3500+, however mine isn't overclocked.
Quote: |
I have access to athlon xp barton 3200+ and k8 4000+ machines. would those be of any use? |
Nope. K7 and K8 already tested, thanks anyway.
|
|
kevman Redneck Gamer-Mod

Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
|
Posted: Wed May 24, 2006 1:47 am Post subject: |
|
Yeah, the MediaGX runs 98, though. Will the build work with it?
So does the k6-2+. The 486 is 95.
_________________
SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!!
Steelers no longer officially own your ass. Pittsburgh will miss The Bus. |
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Wed May 24, 2006 11:04 pm Post subject: |
|
Follow-up: the following are results are from an Athlon64 2800+ running Windows XP-x64.
main_win32.exe
clocks per second = 1000
5234 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
3329 clocks / 100,000,000 co_jump calls (50000000 iterations)
312 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 16.775641x
co_jump skew = 10.669872x
done
main_x86.exe
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
1937 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1875 clocks / 100,000,000 co_jump calls (50000000 iterations)
328 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 5.905488x
co_jump skew = 5.716463x
done
Conclusion: your library works just fine in 64-bit Windows.
I think I've got a beta copy of the 64-bit Vista so in a few days I'll test on that as well once I get it installed.
Last edited by MajereDB8 on Thu May 25, 2006 2:06 am; edited 3 times in total |
|
Magus` Cap'n Gin | Admin

Joined: 27 Jul 2004
Posts: 748
Location: Missouri
|
Posted: Thu May 25, 2006 3:26 am Post subject: |
|
Athlon 64 3200 X2
X86 -
clocks per second = 1000
1750 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1656 clocks / 100,000,000 co_jump calls (50000000 iterations)
265 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.603774x
co_jump skew = 6.249057x
Win32 -
clocks per second = 1000
4343 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2766 clocks / 100,000,000 co_jump calls (50000000 iterations)
281 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.455516x
co_jump skew = 9.843416x |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 25, 2006 10:09 am Post subject: |
|
Doesn't the X2 line start at 3800+? A 3200+ dual core would be really
nice, though. As it is, sub $200 dual core processing requires going
back to Intel. Which isn't going to happen.
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Thu May 25, 2006 11:57 am Post subject: |
|
main_win32:
Code: |
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
8350 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
5160 clocks / 100,000,000 co_jump calls (50000000 iterations)
550 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.181818x
co_jump skew = 9.381818x
done
|
main_x86:
Code: |
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
3790 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
3130 clocks / 100,000,000 co_jump calls (50000000 iterations)
550 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.890909x
co_jump skew = 5.690909x
done
|
Athlon Thunderbird 1 ghz
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 25, 2006 4:49 pm Post subject: |
|
Ok,
I just thought about this: my debugger. I haven't rewritten it so I
can't just test this. I mainly only plan to allow changes when one is
between opcodes. Now, would there ever be a chance with any compilers that variables would be on the stack, instead of inside their respective variables? eg :
Code: |
//we're in thread_cpu now, regs.pc = 0x8000
...
regs.pc += 2;
co_return(); //this function will at least never be inlined
//the co_return takes us back to thread_main, now
printf("%0.4x", ++regs.pc); //should print 0x8003
co_call(thread_main);
//...and go back to thread_cpu
regs.pc += 2;
... |
Now, see I basically increment regs.pc before switching contexts, and
then increment regs.pc again afterwards. My question is, will all
(and all is very important here) c++ compilers recognize that the
non-inlined function may access the variable regs.pc and appropriately
NOT try and leave the new regs.pc on the stack, eg
Code: |
;in thread_cpu
mov eax,[regs.pc]
add eax,2
call co_return
;now we're at thread_main
inc [regs.pc]
push [regs.pc]
push dword ptr "%0.4x"
call printf
mov ecx,thread_cpu
call co_call
;back to thread_cpu
add eax,2
mov [regs.pc],2 |
The above would result in printf writing out 0x8001, and regs.pc
becoming 0x8004. Whereas the c++ should end up printing 0x8003, and the
code would end with regs.pc = 0x8005. Can I be certain that this is
always the case?
It seems like the answer is obvious, but since I am messing with
stack-related stuff now, which is supposed to be hidden to the
programmer, and since I know c++ has a penchant for evil optimizations
(replacing entire loops with function calls into single mov
instructions, etc)... is this something to worry about? If it is, then
I won't be able to use a debugger with the cothreaded code. And if I
can't use a runtime debugger, then this entire approach will have very
little value to me :/
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu May 25, 2006 6:12 pm Post subject: |
|
p3 1000 @ 750(don't ask) coppermine
win32:
clocks per second = 1000
12850 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
7850 clocks / 100,000,000 co_jump calls (50000000 iterations)
830 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 15.481928x
co_jump skew = 9.457831x
x86:
clocks per second = 1000
5220 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
5160 clocks / 100,000,000 co_jump calls (50000000 iterations)
830 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.289157x
co_jump skew = 6.216867x
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
Last edited by funkyass on Thu May 25, 2006 6:38 pm; edited 1 time in total |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu May 25, 2006 6:17 pm Post subject: |
|
main_x86
clocks per second = 1000
2843 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
2532 clocks / 100,000,000 co_jump calls (50000000 iterations)
281 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 10.117438x
co_jump skew = 9.010676x
main_win32
clocks per second = 1000
8953 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
7390 clocks / 100,000,000 co_jump calls (50000000 iterations)
313 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 28.603834x
co_jump skew = 23.610224x
From the 2.8 ghz Xeon we have here at work. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 25, 2006 6:48 pm Post subject: |
|
pagefault wrote: |
co_call skew = 28.603834x
co_jump skew = 23.610224x
From the 2.8 ghz Xeon we have here at work. |
Hoooooooooly crap thats slow. Man, I bet my library would allow for a huge
speedup on Xeon servers using the cothreaded versions of SQL server /
etc, as they use the exact same Fiber API that I use in that test.
Maybe I should make a #define list to clone / drop-in replace Windows Fiber implementations.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu May 25, 2006 7:02 pm Post subject: |
|
P4 1500 Williamette:
win32:
clocks per second = 1000
9673 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
6940 clocks / 100,000,000 co_jump calls (50000000 iterations)
481 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 20.110187x
co_jump skew = 14.428274x
x86:
clocks per second = 1000
5848 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
5047 clocks / 100,000,000 co_jump calls (50000000 iterations)
471 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 12.416136x
co_jump skew = 10.715499x
whats the cache info on that xeon PF?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 25, 2006 10:22 pm Post subject: |
|
First under WINE:
Code: |
/tmp> wine main_win32.exe
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
60631 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
59609 clocks / 100,000,000 co_jump calls (50000000 iterations)
288 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 210.524306x
co_jump skew = 206.975694x
done
/tmp> wine main_x86.exe
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
1953 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1776 clocks / 100,000,000 co_jump calls (50000000 iterations)
287 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.804878x
co_jump skew = 6.188153x
done
|
Now under 32 bit Linux:
Code: |
/tmp/2> ./test
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000000
1790000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1700000 clocks / 100,000,000 co_jump calls (50000000 iterations)
320000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 5.593750x
co_jump skew = 5.312500x
done
|
Now 32 bit Linux linked against Google allocator:
Code: |
/tmp/2> ./test
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000000
1790000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
1670000 clocks / 100,000,000 co_jump calls (50000000 iterations)
380000 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 4.710526x
co_jump skew = 4.394737x
done
|
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 25, 2006 11:48 pm Post subject: |
|
I don't know what Google Allocator is, but it looks like it just slows things down. Now WINE, on the other hand ...
Code: |
clocks per second = 1000
60631 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
59609 clocks / 100,000,000 co_jump calls (50000000 iterations)
288 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 210.524306x
co_jump skew = 206.975694x |
Hooooooooooooooooooooooooooooly fucking Moses. What in the hell is WINE doing for these functions? o.O
Wow. Perhaps I should submit my code to the WINE team, as well. Only
problem is mine doesn't break apart the global stack heap into
subsections, it allocates new memory and uses that for each stack heap.
I can't imagine that being too much of a problem, but who knows.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 25, 2006 11:59 pm Post subject: |
|
byuu wrote: |
I don't know what Google Allocator is, but it looks like it just slows things down. |
Why do you say that?
Aren't lower scores better?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri May 26, 2006 12:27 am Post subject: |
|
byuu wrote: |
Anyway, lower skew numbers are better, but you're only getting a better
score because it took longer for the standard subroutine calls to
complete. |
And you're sure that's the only reason?
You're using malloc and free inside your x86 code, and the Google
allocater is supposed to run those functions in 1/6 the time. And that
AFAIK, is the only changes it makes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 26, 2006 1:30 am Post subject: |
|
I only use them to create the threads, the malloc / free time is not counted in the actual timing tests, so yes. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri May 26, 2006 2:09 pm Post subject: |
|
Code: |
win32:
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
10915 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
7331 clocks / 100,000,000 co_jump calls (50000000 iterations)
761 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 14.342970x
co_jump skew = 9.633377x |
Code: |
x86:
cooperative multithreading test
test should return '1234567'
1234567
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 1000
4857 clocks / 50,000,000 co_call + co_return calls (50000000 iterations)
4776 clocks / 100,000,000 co_jump calls (50000000 iterations)
752 clocks / 50,000,000 subroutine calls (50000000 iterations)
co_call skew = 6.458777x
co_jump skew = 6.351064x |
CPU info
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
-_pentium5.1_- Lurker
Joined: 04 Sep 2004
Posts: 193
Location: USA
|
Posted: Sat May 27, 2006 8:04 pm Post subject: |
|
Quick
question: "Goodbye, Anthrox (PD)" no longer seems to run in bsnes
0.016. (It's the ROM that was used to demonstrate the 16-bit accuracy
limitation of the Mode 7 hardware.) Does anyone know why?
Should someone create a separate thread for bsnes bug reports?
_________________
This signature intentionally contains no text other than this sentence. |
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat May 27, 2006 8:35 pm Post subject: |
|
-_pentium5.1_- wrote: |
Quick
question: "Goodbye, Anthrox (PD)" no longer seems to run in bsnes
0.016. (It's the ROM that was used to demonstrate the 16-bit accuracy
limitation of the Mode 7 hardware.) Does anyone know why?
Should someone create a separate thread for bsnes bug reports? |
It works here.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Mon May 29, 2006 7:39 am Post subject: |
|
Feature request for byuu: and well it's actually a "please emulate X hardware" request (yes I should held my head in shame )
Anyway, a recent post on the zsnes talk ("piggyback rom" or something)
made me remember that I made the same request long ago.Suprisingly
enough that request has appeared a few times actually, so I wouldn't
actually be the only one to enjoy it, if that's any convincing argument.
Basically the user is asking to emulate the Snes Game-Genie. Not just
GG code support but the actual hardware support. So basically the GG
bios would be executed, enter the codes,press start (or whatever that
was) and then rom is executed with loaded codes. edit Of course, I do realise it's more complicated than just "piggyback" the Snes rom on top of the GG bios...
And yes,it's only real use would be a pure nostalgic one. Anyway, if
it's something hard to implement,or if there's not enough info or if
you feel hardware GG support aren't worth the effort then never mind my
request. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 30, 2006 10:07 pm Post subject: |
|
Ok, I've logged reads+writes to all unmapped registers for Captain America. It isn't accessing anything it shouldn't.
It isn't touching any unmapped regs anywhere from $2000-$5fff. I've
even made sure to check inside the CPU and PPU regions that have some
read or write only registers.
So, let's try some other things. The corrupted tiles are on BG1.
Super Sleuth state inspector says that :
BG1 NBA = 0000
BG1 TD = 5900 (eg 0xb000 VRAM addr)
BG1 HSCROLL = 0
BG1 VSCROLL = 255
BG1 char size = 8x8
BG1 map size = 32x64
Verified all of this is the same with bsnes :
2105 = 09 <BG Mode 1, 8x8 BG1 tiles, BG3 pri>
2107 = 59 <b000, 1 - 32x64 scsize>
210b = 40 <0000 tdaddr>
210d = 0 (0 hscroll)
210e = 00ff (255 vscroll)
Ok, check VRAM dump. Hmm, problem. VRAM for BG1 NBA (tiledata) is all
0x0000 up to VRAM offset 0xc00. ZSNES has lots of data for this region.
Everything after 0xc00+ is different, too. So corrupted tiles? Check.
Tilemap, tilemap... identical from b000-b77f, b780+ is different.
Shouldn't affect the first screen of data, at least not the top part.
Gotta track down tile corruption, which is likely a DMA. Ugh, I hate this game so much.
---
Quote: |
Basically
the user is asking to emulate the Snes Game-Genie. Not just GG code
support but the actual hardware support. So basically the GG bios would
be executed, enter the codes,press start (or whatever that was) and
then rom is executed with loaded codes. edit Of course, I do realise
it's more complicated than just "piggyback" the Snes rom on top of the
GG bios... |
Pretty stupid. You can't save your codes, you're limited to five codes,
you get to input them manually, and at least in software there's no
code enable / disable toggle. Oh well, doesn't seem too difficult to do.
ROM completes and jumps into RAM execution code :
Code: |
00FCE6 LDA #$80 A:00FF X:00B0 Y:0006 S:01F6 DB:00 D:0000 P:B5 e
00FCE8 STA $2100 [002100] A:0080 X:00B0 Y:0006 S:01F6 DB:00 D:0000 P:B5 e
00FCEB PLP A:0080 X:00B0 Y:0006 S:01F6 DB:00 D:0000 P:B5 e
00FCEC PLY A:0080 X:00B0 Y:0006 S:01F7 DB:00 D:0000 P:05 e
00FCED PLX A:0080 X:00B0 Y:0006 S:01F9 DB:00 D:0000 P:05 e
00FCEE PLA A:0080 X:00B0 Y:0006 S:01FB DB:00 D:0000 P:05 e
00FCEF RTS A:0010 X:00B0 Y:0006 S:01FD DB:00 D:0000 P:05 e
00815A JMP $FE16 [00FE16] A:0010 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e
00FE16 REP #$30 A:0010 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e
00FE18 LDA #$01FF A:0010 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e
00FE1B TCS A:01FF X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e
00FE1C JMP $001E00 A:01FF X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e
001E00 SEP #$20 A:01FF X:00B0 Y:0006 S:01FF DB:00 D:0000 P:05 e |
RAM completes and jumps to the reset vector :
Code: |
001E7E JMP ($FFFC) [008000] A:0000 X:0000 Y:0000 S:01FF DB:00 D:0000 P:36 E
008065 SEI A:0000 X:0000 Y:0000 S:01FF DB:00 D:0000 P:36 E
008066 CLC A:0000 X:0000 Y:0000 S:01FF DB:00 D:0000 P:36 E
008067 XCE A:0000 X:0000 Y:0000 S:01FF DB:00 D:0000 P:36 E
008068 REP #$30 A:0000 X:0000 Y:0000 S:01FF DB:00 D:0000 P:37 e |
This is where the BIOS loops forever because it's jumping right back to the regular BIOS ROM.
The GG hardware is communicating via writes to ROM in the range of $00:8000-$00:8016 :
Code: |
001E02 LDA #$02 A:01FF X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E04 STA $8000 [008000] A:0102 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E07 LDA #$03 A:0102 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E09 STA $43 [000043] A:0103 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E0B LDA #$80 A:0103 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E0D STA $44 [000044] A:0180 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:A5 e
001E0F LDA #$05 A:0180 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:A5 e
001E11 LDX #$0000 A:0105 X:00B0 Y:0006 S:01FF DB:00 D:0000 P:25 e
001E14 PHA A:0105 X:0000 Y:0006 S:01FF DB:00 D:0000 P:27 e
001E15 LDA $1CEE,X [001CEE] A:0105 X:0000 Y:0006 S:01FE DB:00 D:0000 P:27 e
001E18 INX A:014D X:0000 Y:0006 S:01FE DB:00 D:0000 P:25 e
001E19 LDY #$0003 A:014D X:0001 Y:0006 S:01FE DB:00 D:0000 P:25 e
001E1C STA ($43),Y [008006] A:014D X:0001 Y:0003 S:01FE DB:00 D:0000 P:25 e |
... etc.
I haven't bothered to decode the writes yet. It will require
modification to bsnes since by default ROM writes are ignored, but I at
least already separate read / write handlers, so it won't be too bad.
Not sure if I'm going to bother adding support for this or not.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue May 30, 2006 10:56 pm Post subject: |
|
I
personally don't think it's worth the time and effort to support when
built in cheating facilities are far superior. If it were up to me I
would spend more time on stuff that was actually important. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 30, 2006 11:10 pm Post subject: |
|
Agreed. Well, it was only 20 lines of code, so :
Code: |
Game Genie v2.0 BIOS Interface :
$8000 w ????????
- $02 = begin transfer
- $07 = end transfer
$8001 w ???edcba
- a = enable code 1
- b = enable code 2
- c = enable code 3
- d = enable code 4
- e = enable code 5
$8002 ? ????????
- unknown, not used?
$8006 w dddddddd <code 1>
$800a w dddddddd <code 2>
$800e w dddddddd <code 3>
$8012 w dddddddd <code 4>
$8016 w dddddddd <code 5>
- d = override data
$8003 w bbbbbbbb <code 1>
$8007 w bbbbbbbb <code 2>
$800b w bbbbbbbb <code 3>
$800f w bbbbbbbb <code 4>
$8013 w bbbbbbbb <code 5>
- b = bank data
$8005 w hhhhhhhh <code 1>
$8009 w hhhhhhhh <code 2>
$800d w hhhhhhhh <code 3>
$8011 w hhhhhhhh <code 4>
$8015 w hhhhhhhh <code 5>
- h = high data
$8004 w llllllll <code 1>
$8008 w llllllll <code 2>
$800c w llllllll <code 3>
$8010 w llllllll <code 4>
$8014 w llllllll <code 5>
- l = low data
Note: Codes written to registers above are pre-decoded by the GG BIOS
eg BIOS will write $1a,$49,$ff,$ff ($49ffff=#$1a) for code 'FCEE-2735' |
This would be trivial to add. Just saying ... dumber features have been added in the past.
So, emulation approach :
Load ROM normally. Right after loading the ROM and mapping all
registers, add check for GG ROM enable. If enabled, bypass loading .cht
file and load GG ROM. Map GG ROM. Accept input codes and when #$07 is
written to $008000 by mapping each code as though they were read from
.cht file. Main GUI interface can now be used to toggle cheat codes on
and off, as would be the case on the original hardware with that little
toggle switch on the side. Then map original ROM instead, and free the
GG ROM from memory (or keep it aside for reset, possibly?). Once the
ROM is unloaded, do not save .cht file if GG ROM is enabled. Done.
There. Captain America is fixed.
Top log is ZSNES, bottom is bsnes v0.013, which also has the CA bug.
Code: |
0081EA JSR $ED41 [00ED41] A:1E80 X:6FE0 Y:8E00 S:01FF DB:00 D:0000 P:E0 e
00ED41 LDA #$80 A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E0 e
00ED43 STA $2100 [002100] A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E0 e
00ED46 STZ $09F1 [0009F1] A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E0 e
00ED49 LDA #$01 A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E0 e
00ED4B STA $4200 [004200] A:1E01 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:60 e
00ED4E SEI A:1E01 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:60 e
00ED4F LDA #$80 A:1E01 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:64 e
00ED51 STA $2115 [002115] A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E4 e
00ED54 REP #$20 A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:E4 e
00ED56 LDA $0010,X [006FF0] A:1E80 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:C4 e
00ED59 STA $66 [000066] A:0000 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:46 e
00ED5B LDA $000034 A:0000 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:46 e
00ED5F STA $69 [000069] A:6120 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:44 e
00ED61 LDA $000031 A:6120 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:44 e
00ED65 TAX A:0EC0 X:6FE0 Y:8E00 S:01FD DB:00 D:0000 P:44 e
00ED66 SEP #$20 A:0EC0 X:0EC0 Y:8E00 S:01FD DB:00 D:0000 P:44 e
00ED68 LDA $000033 A:0EC0 X:0EC0 Y:8E00 S:01FD DB:00 D:0000 P:64 e
00ED6C JSR $BFA9 [00BFA9] A:0E7F X:0EC0 Y:8E00 S:01FD DB:00 D:0000 P:64 e
00BFA9 STA $4304 [004304] A:0E7F X:0EC0 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFAC STX $4302 [004302] A:0E7F X:0EC0 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFAF LDX $69 [000069] A:0E7F X:0EC0 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFB1 STX $4305 [004305] A:0E7F X:6120 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFB4 LDA #$18 A:0E7F X:6120 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFB6 STA $4301 [004301] A:0E18 X:6120 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFB9 LDX $66 [000066] A:0E18 X:6120 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFBB STX $2116 [002116] A:0E18 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:66 e
00BFBE LDA #$01 A:0E18 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:66 e
00BFC0 STA $4300 [004300] A:0E01 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFC3 LDA #$01 A:0E01 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFC5 STA $420B [00420B] A:0E01 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00BFC8 RTS A:0E01 X:0000 Y:8E00 S:01FB DB:00 D:0000 P:64 e
00ED6F JSR $EF37 [00EF37] A:0E01 X:0000 Y:8E00 S:01FD DB:00 D:0000 P:64 e
WRAM: $7f0ec0 -> VRAM: $0000, LEN: 6120
* Breakpoint 0 hit (CPU exec)
00ed41 lda #$80 A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdizc
00ed43 sta $2100 [$002100] A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdizc
00ed46 stz $09f1 [$0009f1] A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdizc
00ed49 lda #$01 A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdizc
00ed4b sta $4200 [$004200] A:1e01 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVMxdizc
00ed4e sei A:1e01 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVMxdizc
00ed4f lda #$80 A:1e01 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVMxdIzc
00ed51 sta $2115 [$002115] A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdIzc
00ed54 rep #$20 A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVMxdIzc
00ed56 lda $0010,x [$006ff0] A:1e80 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVmxdIzc
00ed59 sta $66 [$000066] A:8887 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVmxdIzc
00ed5b lda $000034 [$000034] A:8887 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 NVmxdIzc
00ed5f sta $69 [$000069] A:6120 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVmxdIzc
00ed61 lda $000031 [$000031] A:6120 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVmxdIzc
00ed65 tax A:0ec0 X:6fe0 Y:8e00 S:01fd D:0000 DB:00 nVmxdIzc
00ed66 sep #$20 A:0ec0 X:0ec0 Y:8e00 S:01fd D:0000 DB:00 nVmxdIzc
00ed68 lda $000033 [$000033] A:0ec0 X:0ec0 Y:8e00 S:01fd D:0000 DB:00 nVMxdIzc
00ed6c jsr $bfa9 [$00bfa9] A:0e7f X:0ec0 Y:8e00 S:01fd D:0000 DB:00 nVMxdIzc
00bfa9 sta $4304 [$004304] A:0e7f X:0ec0 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfac stx $4302 [$004302] A:0e7f X:0ec0 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfaf ldx $69 [$000069] A:0e7f X:0ec0 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfb1 stx $4305 [$004305] A:0e7f X:6120 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfb4 lda #$18 A:0e7f X:6120 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfb6 sta $4301 [$004301] A:0e18 X:6120 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfb9 ldx $66 [$000066] A:0e18 X:6120 Y:8e00 S:01fb D:0000 DB:00 nVMxdIzc
00bfbb stx $2116 [$002116] A:0e18 X:8887 Y:8e00 S:01fb D:0000 DB:00 NVMxdIzc |
It's reading the VRAM transfer address from $006ff0,$006ff1; which is
unmapped in this case since there is no SRAM chip in this game.
I've unfortunately not accounted for this space (instead using only
$[20-3f]:[6000-7fff]) and bsnes as a result fell back on mapping this
space to ROM. Reading from ROM at this space was returning different
data, making it transfer the tiledata to the wrong offset.
Ok, so what happens when you read $[00-1f]:[6000-7fff]? Return open
bus. In this case, lda $0010,x just happens to have the last byte be
0x00 [ad 10 00], so open bus will return 0x00, 0x00 in this case. Which
just happens to be the correct offset to transfer tile data to.
Boy, isn't the SNES a fun little system?
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Wed May 31, 2006 4:51 am Post subject: |
|
byuu wrote: |
I
haven't bothered to decode the writes yet. It will require modification
to bsnes since by default ROM writes are ignored, but I at least
already separate read / write handlers, so it won't be too bad.
Not sure if I'm going to bother adding support for this or not. |
Ether way thanks for considering it.
I'm not gonna try to convince anyone that hardware GG support is
superior in term of pure functionality. Just something to recreate the
old interface (primitive and limited as it was) that many people used
back then.
edit:
Quote: |
Agreed. Well, it was only 20 lines of code, so :
Quote: |
Code:
Game Genie v2.0 BIOS Interface :
$8000 w ????????
- $02 = begin transfer
- $07 = end transfer
$8001 w ???edcba
- a = enable code 1
- b = enable code 2
- c = enable code 3
- d = enable code 4
- e = enable code 5
$8002 ? ????????
- unknown, not used?
$8006 w dddddddd <code 1>
$800a w dddddddd <code 2>
$800e w dddddddd <code 3>
$8012 w dddddddd <code 4>
$8016 w dddddddd <code 5>
- d = override data
$8003 w bbbbbbbb <code 1>
$8007 w bbbbbbbb <code 2>
$800b w bbbbbbbb <code 3>
$800f w bbbbbbbb <code 4>
$8013 w bbbbbbbb <code 5>
- b = bank data
$8005 w hhhhhhhh <code 1>
$8009 w hhhhhhhh <code 2>
$800d w hhhhhhhh <code 3>
$8011 w hhhhhhhh <code 4>
$8015 w hhhhhhhh <code 5>
- h = high data
$8004 w llllllll <code 1>
$8008 w llllllll <code 2>
$800c w llllllll <code 3>
$8010 w llllllll <code 4>
$8014 w llllllll <code 5>
- l = low data
Note: Codes written to registers above are pre-decoded by the GG BIOS
eg BIOS will write $1a,$49,$ff,$ff ($49ffff=#$1a) for code 'FCEE-2735'[color=green] |
This would be trivial to add. Just saying ... dumber features have been added in the past.
So, emulation approach :
Load ROM normally. Right after loading the ROM and mapping all
registers, add check for GG ROM enable. If enabled, bypass loading .cht
file and load GG ROM. Map GG ROM. Accept input codes and when #$07 is
written to $008000 by mapping each code as though they were read from
.cht file. Main GUI interface can now be used to toggle cheat codes on
and off, as would be the case on the original hardware with that little
toggle switch on the side. Then map original ROM instead, and free the
GG ROM from memory (or keep it aside for reset, possibly?). Once the
ROM is unloaded, do not save .cht file if GG ROM is enabled. Done.
|
Awesomeness. Anyway, even if you do decide not to implement it thanks again for looking into it.
Ideally, the little GG on/off toggle switch could be mapped on the
keyboard instead of going through the GUI every time, but at this point
I'll just shut up
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 31, 2006 5:22 am Post subject: |
|
Congratulations on the Captain America fix.
Strangely, I was reading an old comic book yesterday and there was an
advertisement inside for the game's release on SNES. One of the pitches
was "plays just like the arcade version!" Got a good chuckle from that
one. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 31, 2006 5:36 am Post subject: |
|
NTSC filter fix :

The textbox is hires, whereas the background is lores. Even when the
textbox disappears, the lores part of the screen looks the same. There
is no sharpness difference as in the normal direct filter.
Captain America fix :

To hell with this game D:< |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed May 31, 2006 5:47 am Post subject: |
|
Is it just me, or does Captain America look really goofy in that icon by his health? |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed May 31, 2006 12:33 pm Post subject: |
|
So,
from what I understand, the Captain America bug was because the
programmers had a bug in Captain America code which coincedentally
happened to return the desired value anyway via open bus?
Congrats on that one. Those kinds of issues are a real bitch to track
down. But, in the end it was worth it because you have one more
additional piece of the SNES emulated accurately. 
_________________
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. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 31, 2006 4:13 pm Post subject: |
|
Yes.
I generally consider open bus as reads from write-only registers (eg
$4210), but of course it even applies to unmapped cart regions as well.
Quote: |
But, in the end it was worth it because you have one more additional piece of the SNES emulated accurately. |
One down... 21 to go :(
The bug list seems to grow faster than I fix things ...
Edit: Rendering Ranger R2 (J) - hangs sometimes at new game start, earlier random hangs with "reset"
I can no longer reproduce this bug. I can on v0.016 official. No idea
what fixed it, or if I've just been very lucky in it not occuring after
~15 tests. Looking at Jurassic Park 2 now ...
Getting stuck waiting on an IRQ to occur at V=167,H=130. Hmm ...
suppose I'll wait until I redo the CPU core to fix this one. The NMI /
IRQ code is a mess in the current version.
Ok, Tales of Phantasia, CGRAM dump :
Code: |
000000: 00 00 ff 7f f7 66 00 00 80 24 00 00 4c 1d f9 52 ; 0- 7
000010: 00 50 df 01 1f 01 00 00 00 50 e0 02 e0 03 00 00 ; 8-15
000020: 2a 29 00 08 43 41 85 7a 00 00 ff 7f 00 00 ff 7f ; 16-23
000030: 26 12 3d 06 53 7e 6a 72 81 6a 98 5e af 56 c6 4a ; 24-31
000040: 00 7c e1 20 64 25 a6 29 e8 2d ae 3a f4 3a 76 43 ; 32-39
000050: 81 1c e4 28 49 2d cb 45 51 4e b2 62 17 67 78 7b ; 40-47
000060: ff 7f[31 31|31 31|31 31]23 1d 44 1d 85 21 c5 25 ; 48-55 -- 49,50,51 corrupt
000070: 05 2a 48 2e 8b 36 ae 3e 11 4b 54 57 97 63 da 6f ; 56-63 |
Colors 49-51 (CGRAM 0x62-0x67) is being corrupted somehow. Palette colors are being overwritten with 0x31's.
Code: |
c10449 ldx $0755 [$000755] A:ff00 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdiZc
c1044c stx $4372 [$004372] A:ff00 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
* Breakpoint 0 hit (write)
c1044f lda #$01 A:ff00 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c10451 trb $b8 [$0000b8] A:ff01 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
V:221 H:306 HC:1224 I:0 IF:1 O:0 -- CPU[$00,$00,$01,$2c]<>APU[$89,$03,$0b,$00]
V:223 H:306 HC:1224 I:0 IF:1 O:0 -- CPU[$00,$00,$01,$2c]<>APU[$89,$03,$0b,$00] |
Happening during HDMA. Fun, more HDMA bugs.
Code: |
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
221,1176 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
221,1184 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62be, iaddr ffffff
222,1172 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62be, iaddr ffffff
222,1180 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c0, iaddr ffffff
223,1176 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c0, iaddr ffffff
223,1184 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c2, iaddr ffffff
224,1196 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c2, iaddr ffffff
224,1204 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
221,1172 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
221,1180 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62be, iaddr ffffff
222,1176 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62be, iaddr ffffff
222,1184 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c0, iaddr ffffff
223,1172 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c0, iaddr ffffff
223,1180 mode 3 readindex 3 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c2, iaddr ffffff
224,1184 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0064, HDMAi 0, addr 7e62c2, iaddr ffffff
224,1192 mode 3 readindex 3 destaddr 21 |
Added a hack to fix Tales of Phantasia.
In bCPU::hdma_run() ...
Code: |
//Tales of Phantasia battle palette fix hack
if(hdma_mmio(i) == 0x2122 && static_cast<bPPU*>(r_ppu)->regs.cgram_addr >= 0x60 &&
static_cast<bPPU*>(r_ppu)->regs.cgram_addr <= 0x68) {
} else {
dma_transfer_byte(channel[i].direction, hdma_mmio(i),
channel[i].hdma_indirect ? hdma_iaddr(i) : hdma_addr(i));
} |
... hahah, just kidding. That got the log above. No hacks :)
Still working on it ... this is going to be a pain because all the other emulators suck at debugging HDMA.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed May 31, 2006 10:40 pm Post subject: |
|
Man, you almost shocked me there when mentioning a hack to fix that game.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 01, 2006 12:09 am Post subject: |
|
Heheh. Well, that code above does fix the problem ... ;)
But yeah, just using it for logging data.
Code: |
//
* w4350: 03 (pc=c3b162)
* w4351: 21 (pc=c3b167)
* w4352: 80 (pc=c3b16d)
* w4353: 61 (pc=c3b16d)
* w4354: 7e (pc=c3b172)
//
C3B15D LDA #$03 A:FF11 X:0947 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B15F STA $4350 [004350] A:FF03 X:0947 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B162 LDA #$21 A:FF03 X:0947 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B164 STA $4351 [004351] A:FF21 X:0947 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B167 LDX #$6180 A:FF21 X:0947 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B16A STX $4352 [004352] A:FF21 X:6180 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B16D LDA #$7E A:FF21 X:6180 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B16F STA $4354 [004354] A:FF7E X:6180 Y:0970 S:01DF DB:00 D:0000 P:20 e
C3B172 JSL $C3DF81 A:FF7E X:6180 Y:0970 S:01DF DB:00 D:0000 P:20 e
//
c13+6180=6d93 -> 7e6180
00 00 F1 F5 56 48 01 42 00 00 00 A8 58 DA 40 00
42 48 01 42 00 00 00 A8 58 DA 05 9A 52 00 00 4C
60 46 53 58 D0 56 87 E3 56 90 0D 42 00 00 00 02
00 02 00 02 00 02 01 4C 53 00 08 01 50 01 00 A0
//
c3b15d lda #$03 A:ff11 X:0947 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b15f sta $4350 [$004350] A:ff03 X:0947 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b162 lda #$21 A:ff03 X:0947 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b164 sta $4351 [$004351] A:ff21 X:0947 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b167 ldx #$6180 A:ff21 X:0947 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b16a stx $4352 [$004352] A:ff21 X:6180 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b16d lda #$7e A:ff21 X:6180 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b16f sta $4354 [$004354] A:ff7e X:6180 Y:0970 S:01df D:0000 DB:00 nvMxdizc
c3b172 jsl $c3df81 [$c3df81] A:ff7e X:6180 Y:0970 S:01df D:0000 DB:00 nvMxdizc
//
7e6180: 00 00 f1 f5 56 48 01 42 00 00 00 a8 58 da 40 00
7e6190: 42 48 01 42 00 00 00 a8 58 da 05 9a 52 00 00 4c
7e61a0: 60 46 53 58 d0 56 87 e3 56 90 0d 42 00 00 00 02
7e61b0: 00 02 00 02 00 02 01 4c 53 00 08 01 50 01 00 a0
//
* w420c: 00 (pc=c3b1c1)
* w420c: 02 (pc=c3b1d0)
...
* w420c: 00 (pc=c101c6)
//e2 = 11100010
* w420c: e2 (pc=c10216)
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
222,1176 mode 3 readindex 2 destaddr 21
* HDMA 5, CGRAM 0062, HDMAi 0, addr 7e62bc, iaddr ffffff
222,1184 mode 3 readindex 3 destaddr 21
... |
That's the best I can do. Both ZSNES and bsnes are using HDMA channel 5
to draw the gradient window effect in ToP battles. However, bsnes for
some reason keeps on going and ends up writing into the background
colors. I don't have any idea why. The HDMA table hex code is identical
between the two emulators. I won't be able to compare HDMA processing
code between any other emulator to find the bug so I don't think I'll
be able to fix this bug either :(
At least I know it's an HDMA bug, probably similar to the one in Genjuo Ryodan.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Jun 01, 2006 12:57 am Post subject: |
|
I
am not very familiar with HDMA, what address is it writing to when it
does this writing to the background. It sounds like it might be
something timing related, but that would surprise me since ZSNES HDMA
timing is almost non-existant right now. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 01, 2006 1:11 am Post subject: |
|
I've tracked this bug a bit further back.
Code: |
* HDMA[5] line_counter = 00 addr=7e62ba
* HDMA[5] v=222 read=7e62ba[00] write=2121[addr=0002]
* HDMA[5] v=222 read=7e62bb[00] write=2121[addr=0000]
* HDMA[5] v=222 read=7e62bc[00] write=2122[addr=0000]
* HDMA[5] v=222 read=7e62bd[00] write=2122[addr=0001]
* HDMA[5] v=223 read=7e62be[00] write=2121[addr=0002]
* HDMA[5] v=223 read=7e62bf[00] write=2121[addr=0000]
* HDMA[5] v=223 read=7e62c0[00] write=2122[addr=0000]
* HDMA[5] v=223 read=7e62c1[00] write=2122[addr=0001]
* HDMA[5] v=224 read=7e62c2[00] write=2121[addr=0002]
* HDMA[5] v=224 read=7e62c3[00] write=2121[addr=0000]
* HDMA[5] v=224 read=7e62c4[00] write=2122[addr=0000]
* HDMA[5] v=224 read=7e62c5[00] write=2122[addr=0001]
* HDMA[5] line_counter = 17 addr=7e6181
* HDMA[5] v= 0 read=7e6181[00] write=2121[addr=0002]
* HDMA[5] v= 0 read=7e6182[00] write=2121[addr=0000]
* HDMA[5] v= 0 read=7e6183[00] write=2122[addr=0000]
* HDMA[5] v= 0 read=7e6184[00] write=2122[addr=0001] |
Code: |
* HDMA[5] line_counter = 00 addr=7e62ba
* HDMA[5] v=221 read=7e62ba[00] write=2121[addr=0002]
* HDMA[5] v=221 read=7e62bb[31] write=2121[addr=0000]
* HDMA[5] v=221 read=7e62bc[31] write=2122[addr=0062]
* HDMA[5] v=221 read=7e62bd[31] write=2122[addr=0063]
* HDMA[5] v=222 read=7e62be[31] write=2121[addr=0064]
* HDMA[5] v=222 read=7e62bf[32] write=2121[addr=0062]
* HDMA[5] v=222 read=7e62c0[31] write=2122[addr=0064]
* HDMA[5] v=222 read=7e62c1[32] write=2122[addr=0065]
* HDMA[5] v=223 read=7e62c2[31] write=2121[addr=0066]
* HDMA[5] v=223 read=7e62c3[31] write=2121[addr=0062]
* HDMA[5] v=223 read=7e62c4[31] write=2122[addr=0062]
* HDMA[5] v=223 read=7e62c5[31] write=2122[addr=0063]
* HDMA[5] v=224 read=7e62c6[31] write=2121[addr=0064]
* HDMA[5] v=224 read=7e62c7[32] write=2121[addr=0062]
* HDMA[5] v=224 read=7e62c8[31] write=2122[addr=0064]
* HDMA[5] v=224 read=7e62c9[31] write=2122[addr=0065]
* HDMA[5] line_counter = 17 addr=7e6181 |
Look at address $7e62bb. It goes from 0x00 to 0x31. So the HDMA table
is being overwritten with this data somewhere...
Code: |
c10461 mvn $7e,$7e A:02d4 X:f8bb Y:62bb S:01dd D:0000 DB:7e nvmxdizc |
Fun.
Code: |
c10449 ldx $0755 [$000755] A:ff00 X:0493 Y:0533 S:01de D:0000 DB:00 nvMxdiZc
c1044c stx $4372 [$004372] A:ff00 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c1044f lda #$01 A:ff00 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c10451 trb $b8 [$0000b8] A:ff01 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c10453 beq $0467 [$000467] A:ff01 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c10455 rep #$20 A:ff01 X:03a4 Y:0533 S:01de D:0000 DB:00 nvMxdizc
c10457 phb A:ff01 X:03a4 Y:0533 S:01de D:0000 DB:00 nvmxdizc
c10458 ldx #$f780 A:ff01 X:03a4 Y:0533 S:01dd D:0000 DB:00 nvmxdizc
c1045b ldy #$6180 A:ff01 X:f780 Y:0533 S:01dd D:0000 DB:00 Nvmxdizc
c1045e lda #$040f A:ff01 X:f780 Y:6180 S:01dd D:0000 DB:00 nvmxdizc
c10461 mvn $7e,$7e A:040f X:f780 Y:6180 S:01dd D:0000 DB:00 nvmxdizc |
Hmm. The trb / beq branch is not taken, causing an mvn to occur that
overwrites it. In ZSNES, it is always true until a bit after the
corruption occurs in bsnes.
I have tried and tried to track the code backwards, but every damned
code point I try has different variables in A, X or Y between the two
trace logs. The further I go back, the more differences I find. I can't
keep up with this.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jun 01, 2006 7:16 am Post subject: |
|
byuu on his website wrote: |
05/31/2006 - Updates
libco has been a success. I've managed to rewrite the APU processor
emulation to use the new core. So, as of now, bsnes is the first
emulator to support bus-accurate processor emulation. And with only a
nominal ~3% speed decrease. While the code is slower for the APU, I'm
hoping it will be faster for the much more complex CPU core, where
cothreading will be far more useful.
Next up, I've fixed a bug in the NTSC filter. A pointer calculation for
video data was casting the pitch addition to type char*, which along
with halving the pitch already for word->byte conversion, was
causing the pointer index to be off by 1/2. Or in plain English,
split-screen games looked wrong. And this is now fixed.
Lastly, I've finally fixed Captain America and the Avengers. The game
was reading a 16-bit value from memory address $006ff0. This of course
being unmapped memory. My memory mapper was mapping
$[20-3f]:[6000-7fff] to SRAM, but allowing $[00-1f]:[6000-7fff] to fall
through, which ended up mapping that region to ROM instead. So this
game was reading in a ROM offset to set the VRAM pointer to transfer
tiledata to. This has now been corrected. Essentially, the opcode
performing this read was lda $0010,x. The last opcode byte fetch just
happened to be $00, so the two indexed reads from the unmapped memory
region end up returning $00,$00. And $0000 just happens to be the BG1
NBA (tiledata) address. Fun.
Oh, and a correction from earlier: the DSP-1 opcode emulation was a
joint venture between Andreas Naive, Neviksti, Overload and The Dumper.
My apologies for only mentioning Overload previously. And speaking of
which, no new progress to report on DSP-1 support as of yet. |
Nice. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 01, 2006 8:20 am Post subject: |
|
Ok, so today I spent all day trying to fix Tales and failed miserably.
At home, I went ahead and cleaned up the CPU disassembler (still need
to do the same for the APU disassembler). I then added in tracing (no
masking) and a better debug message system and the option to enable /
disable debug, cpu and apu messages individually to the debug interface.
Of course, this does no good since I don't actually have the debugger
at all functional yet. But it's one step closer to getting the v0.013
debugger back.
Also tried once again to turn the fullscreen surface into an overlay
for either Direct3D or DirectDraw, and failed. Is it even possible to
make an overlay surface with D3D? Whatever Winamp AVS does, its overlay
support seems to work fantastically. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Jun 01, 2006 9:15 pm Post subject: |
|
byuu wrote: |
libco
has been a success. I've managed to rewrite the APU processor emulation
to use the new core. So, as of now, bsnes is the first emulator to
support bus-accurate processor emulation. And with only a nominal ~3%
speed decrease. While the code is slower for the APU, I'm hoping it
will be faster for the much more complex CPU core, where cothreading
will be far more useful.
Next up, I've fixed
a bug in the NTSC filter. A pointer calculation for video data was
casting the pitch addition to type char*, which along with halving the
pitch already for word->byte conversion, was causing the pointer
index to be off by 1/2. Or in plain English, split-screen games looked
wrong. And this is now fixed.
Lastly, I've finally fixed Captain America and the Avengers. The game
was reading a 16-bit value from memory address $006ff0. This of course
being unmapped memory. My memory mapper was mapping
$[20-3f]:[6000-7fff] to SRAM, but allowing $[00-1f]:[6000-7fff] to fall
through, which ended up mapping that region to ROM instead. So this
game was reading in a ROM offset to set the VRAM pointer to transfer
tiledata to. This has now been corrected. Essentially, the opcode
performing this read was lda $0010,x. The last opcode byte fetch just
happened to be $00, so the two indexed reads from the unmapped memory
region end up returning $00,$00. And $0000 just happens to be the BG1
NBA (tiledata) address. Fun.
Oh, and a correction from earlier: the DSP-1 opcode emulation was a
joint venture between Andreas Naive, Neviksti, Overload and The Dumper.
My apologies for only mentioning Overload previously. And speaking of
which, no new progress to report on DSP-1 support as of yet. |
Nice work with the libco implementation and the recent emulation fixes,woot 
But now I kinda feel bad about the ToP bug I reported seeing as this bug seem to be a bitch to track down... Though sooner or later someone else would have reported it I guess
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 01, 2006 9:59 pm Post subject: |
|
No, it's a serious problem. It's corrupting an HDMA table which in turn corrupts CGRAM data. Thusly screwing up palette colors.
It needs to be fixed, but I'm at a loss for how to track down where the error starts.
It's basically CGRAM write error due to HDMA error due to overwrite
error due to ... ad infinitum. Where I'm at now, it's just a million
conditional branches for all kinds of random memory address values and
other emulator logs are completely different from mine, so I have no
point of comparison of where things go wrong. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Jun 01, 2006 10:42 pm Post subject: |
|
Many
cards do not support RGB overlays, ATI and nVidia cards included. You
will have to convert to YUV to use the overlay. Since you have to most
likely do this in software it almost defeats any advantage overlays
would give you. I looked into this a while ago and decided it wasn't a
viable solution. Funny thing is that in linux RGB overlays are
supported by Xv. So it must be a driver thing. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 01, 2006 11:22 pm Post subject: |
|
I
managed to get the DirectDraw overlay up. Supposedly overlays with GDI
and D3D are impossible. You can rig up a hybrid by creating the
surfaces through DD and attaching them via D3D, though.
Anyway, overlays have their advantages :
- No overhead in switching to fullscreen mode
- Surfaces can be flipped for smooth triple buffering even in windowed mode
- Nothing can appear on top of the overlay, so pseudo-fullscreen no
longer will have issues with the damn taskbars and other always-on-top
apps popping up on top of your emulator window
- Dual monitors will automatically pop the overlays onto the second
monitor. Great for debugging with a fullscreen video display on the
second monitor
So, I of course can't get an RGB overlay because video card manufacturers are lazy assholes D:<
Supposedly UYVY is supported on every card under the sun now. But it's
near impossible to render a UYVY image in DirectDraw :/
The format is supposedly :
byte[U] byte[Y] , byte[V] byte[Y]. The idea is you get a full 8-bit Y
sample every pixel, and one U or V sample every other byte. The video
card just shares the U+V between the two pixels.
Already unusable to me. But I can't even get anything to display using
only the Y channel. The video should be grayscale, but instead is
completely psychotic colors. I know my Y calculation is correct, and
I've tried putting the Y on the low byte and high byte of each pixel to
no avail.
Now then, take a look at Winamp and it's advanced visualization studio.
Enable the overlay option and it works fantastically. I'm certain they
aren't actually rendering in UYVY or whatever. Somehow, it has
to be possible to blit an RGB565 image to a UYVY overlay surface and
have the hardware do the conversion for you, but damned if I can figure
out how to do so :(
Failing all of that, it would
at least be nice if there were a way to prevent other always on top
apps from screwing with your fullscreen mode DD / D3D video modes
without being forced to redraw 100% of the screen every single page
flip.
The lack of code / documentation on the internet for RGB<>UYVY
conversion, or just using overlays in general is astounding. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jun 02, 2006 12:18 am Post subject: |
|
Nice try on the ToP bug. Don't get too discouraged, I'm sure some of the others on the list are less psychotic.
As for Rendering Render, perhaps your bus accurate APU core fixed it Battletoads, of course, is fixed (thx dmv), which leaves Earthworm Jim 2 (E) as the only known remaining sound issue. |
|
Reznor007 Regular
Joined: 30 Jul 2004
Posts: 229
|
Posted: Fri Jun 02, 2006 12:47 am Post subject: |
|
Byuu,
check into using VMR9(video mixing renderer 9). It is used by Media
Player Classic(on Sourceforge), and allows it to operate like an
overlay with no video mode switches, but it uses D3D. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jun 05, 2006 3:29 am Post subject: |
|
byuu,if you need help with the overlay,you could ask Justin,the creator of Winamp himself He will probably help you. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 05, 2006 6:16 am Post subject: |
|
Ok,
2 hours and 300mL of 80 proof vodka later ... got the CPU core
rewritten and created a working implementation using libco (called
sCPU). So far, it only emulates the main CPU and has the most generic
h/v counters possible (1364/scanline, 262/frame, nothing more). No
(H)DMA, no NMI/IRQ, no WAI (o rly?), no MMIO and really nothing else.
So, it's enough to run a quick demo that sets the BG color and hangs.
Gets 135 fps, compared to 120 fps with the old core. So, probably going
to end up with a slowdown with the new CPU core, too. Damn. At least I
can make opcode-based cores for slow computers (an emulator with some
accuracy is better than no emulator at all, right?). And no worries,
the old bAPU + bCPU pair is there as well.
From here on, I plan to just rebuild the CPU core piece by piece,
little by little. Maybe I can come up with some new tricks for NMI /
IRQ trigger detection and such to speed things up, who knows.
So yeah, first emulator to support true bus accuracy for both the CPU
and APU cores, ftw. Now I just need to release it before Overload or
TRAC catch up :)
Quote: |
byuu,if you need help with the overlay,you could ask Justin,the creator of Winamp himself. He will probably help you. |
I strongly doubt I'm that well revered in the programming world to ask someone of his stature for help.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Jun 05, 2006 10:35 am Post subject: |
|
byuu wrote: |
Quote: |
byuu,if you need help with the overlay,you could ask Justin,the creator of Winamp himself. He will probably help you. |
I strongly doubt I'm that well revered in the programming world to ask someone of his stature for help.
|
lol asking justin frankel about video overlays. let's see, most of
those videos will definitely be YUV, and probably color key (some
hardware even requires this, I think).
Oh, and lol holding him in high regard. Yeah, I suppose he was the king
of hacks. Now he's the king of selling his shit out, and now a minimal
gang of idiots maintain it and fix critical bugs.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 05, 2006 2:11 pm Post subject: |
|
Quote: |
lol asking justin frankel about video overlays. |
I try and be polite :)
Quote: |
let's see, most of those videos will definitely be YUV, and probably color key (some hardware even requires this, I think). |
Have you seen the AVS? They're not really videos (more like cheap math
tricks that look cool when you're anything but sober), and the overlay
output looks identical to the RGB standard output. So either they have
working RGB->UYVY conversion, or they have a trick to blit RGB
surfaces to overlays and let the hardware do the conversion for them.
Quote: |
Oh,
and lol holding him in high regard. Yeah, I suppose he was the king of
hacks. Now he's the king of selling his shit out, and now a minimal
gang of idiots maintain it and fix critical bugs. |
And bundle his software with as much AOL adware as possible, but even
still. My point was that someone of his popularity would not waste
their time talking to relative nobodies in the programming world, let
alone help them. Hell, I
wouldn't help someone who e-mailed me out of the blue asking for help
on a subject almost completely unrelated to what I am known for.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jun 05, 2006 2:46 pm Post subject: |
|
kode & byuu: He doesn't develop Winamp anymore.He quit his job at AOL a long time ago.Now he does this:
http://www.reaper.fm

and his previous projects: http://www.cockos.com/
He's still the king (not of hacks,lol). |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 06, 2006 4:56 am Post subject: |
|
Finlandia Lime, if you're interested. Tastes like lime kool-aid. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue Jun 06, 2006 5:20 am Post subject: |
|
byuu wrote: |
Finlandia Lime, if you're interested. Tastes like lime kool-aid. |
Yuck. Personally, I hate lime kool-aid. Now if it came in an orange flavor, I'd drink it.
|
|
Joe Camacho Devil's Advocate

Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
|
Posted: Tue Jun 06, 2006 5:44 am Post subject: |
|
byuu wrote: |
Finlandia Lime, if you're interested. Tastes like lime kool-aid. |
My father bought me a bottle when I graduated from Junior High School.
Although it was the regular one. Good Stuff.
Now carry on with your thread.. I can't contribute even if my life depended on it.
_________________
*Sometimes I edit my posts just to correct mistakes.
I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Jun 06, 2006 10:41 am Post subject: |
|
AVS does not appear to use overlays. Or at least, not on my system. Maybe that lack of RGB overlay support is preventing it.
I know when something is using overlays, such as Media Player Classic
forced to use the overlay mixer for output, PrintScreen grabs a big
empty colorkey nothing. Not so with AVS in a window, and I doubt it
would matter much what it uses fullscreen. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 06, 2006 3:20 pm Post subject: |
|
Winamp AVS Editor->Settings->Fullscreen->Use fullscreen overlay mode (current bpp is used)
I know it is using an overlay on my system. And I want the overlay
support for fullscreen. Why? Because non-fullscreen causes other
always-on-top windows to flicker on top of my emulator on occasion.
Plus the automatic monitor redirection most video card drivers have for
dual head displays would be a nice copout for true multi-monitor
awareness. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 07, 2006 8:45 am Post subject: |
|
Horray!
While working on the CPU core rewrite, I stumbled across a rather
obvious HDMA bug in mmio_w420c() that fixes (most likely) about half of
all known bsnes bugs! At least, it fixes three of the five bugged games
I have copies of. I'm sure it fixes many more, too.

No wonder I couldn't find this bug...

No more epilepsy vision!

Hooray, the HDMA code is in fact hardware-accurate after all! GIGO's
assumption that this bug was a result of my HDMA line counter loading
code was in fact incorrect.
I wrote: |
06/07/2006 - sCPU, major HDMA bugfix
Started on the rewrite of the CPU core, sCPU. This will be the
cooperatively multithreaded version of my CPU emulation. So far, it's
going ok. It runs at 135fps (compared to 120fps) for a blank screen on
my PC. But since it lacks accurate H/V counters, interrupts and H/DMA
processing, that number will probably go down a good deal. How much
remains to be seen. So far, I've only rewritten the opcode emulation
(all 256 opcodes) and most MMIO registers. A lot of the MMIO registers
have no functionality (such as the interrupt ones, waiting on new core
interrupt support), but it's a start. Little by little, I'll rewrite
all of it.
In the process of rewriting mmio_w420c(), however, I noticed a major
bug. Blatantly obvious to me, too. The routine either enables or
disables the HDMA channel based on each bit written to the byte in this
register. However, it also does the exact same thing for the active
flag I was using. The active flag means that the HDMA line counter has
not hit a zero to terminate the transfer yet, so an HDMA transfer
should occur on this line. I'm guessing my old logic was that this was
needed so that disabling an HDMA channel will turn off the active flag.
However, I failed to account for the fact that this would turn an HDMA
channel that should have already been turned off for this frame back on
again! Oops. I modified the behavior to leave the active flag alone,
unless the HDMA channel was being turned off, in which case it clears
the active flag. This fixes a lot of games. Tales of Phantasia's
palette bug after some battles, Genjuu Ryodan's status window when text
is onscreen, Mortal Kombat's epilepsy mode, etc.
In fact, I wouldn't be too surprised if this bugfix accounted for
nearly half of all known bsnes bugs. It fixed three of the five games
with known bugs I tested. |
|
|
|
sephir0th Rookie

Joined: 04 Jun 2006
Posts: 24
Location: kansas
|
Posted: Wed Jun 07, 2006 2:22 pm Post subject: |
|
I didn't mean to push this awesome achievement off the page...
byuu wrote: |
Horray! While working on the CPU core rewrite, I stumbled across a
rather obvious HDMA bug in mmio_w420c() that fixes (most likely) about
half of all known bsnes bugs! At least, it fixes three of the five
bugged games I have copies of. I'm sure it fixes many more, too.

No wonder I couldn't find this bug...

No more epilepsy vision!

Hooray, the HDMA code is in fact hardware-accurate after all! GIGO's
assumption that this bug was a result of my HDMA line counter loading
code was in fact incorrect.
I wrote: |
06/07/2006 - sCPU, major HDMA bugfix
Started on the rewrite of the CPU core, sCPU. This will be the
cooperatively multithreaded version of my CPU emulation. So far, it's
going ok. It runs at 135fps (compared to 120fps) for a blank screen on
my PC. But since it lacks accurate H/V counters, interrupts and H/DMA
processing, that number will probably go down a good deal. How much
remains to be seen. So far, I've only rewritten the opcode emulation
(all 256 opcodes) and most MMIO registers. A lot of the MMIO registers
have no functionality (such as the interrupt ones, waiting on new core
interrupt support), but it's a start. Little by little, I'll rewrite
all of it.
In the process of rewriting mmio_w420c(), however, I noticed a major
bug. Blatantly obvious to me, too. The routine either enables or
disables the HDMA channel based on each bit written to the byte in this
register. However, it also does the exact same thing for the active
flag I was using. The active flag means that the HDMA line counter has
not hit a zero to terminate the transfer yet, so an HDMA transfer
should occur on this line. I'm guessing my old logic was that this was
needed so that disabling an HDMA channel will turn off the active flag.
However, I failed to account for the fact that this would turn an HDMA
channel that should have already been turned off for this frame back on
again! Oops. I modified the behavior to leave the active flag alone,
unless the HDMA channel was being turned off, in which case it clears
the active flag. This fixes a lot of games. Tales of Phantasia's
palette bug after some battles, Genjuu Ryodan's status window when text
is onscreen, Mortal Kombat's epilepsy mode, etc.
In fact, I wouldn't be too surprised if this bugfix accounted for
nearly half of all known bsnes bugs. It fixed three of the five games
with known bugs I tested. |
|
Byuu vs Bugs
Byuu=Winnar!
Buggs wrote: |
You have beaten us THIS time, Byuu! We WILL be back! Your children will fear th-*BZZZTI*sizzle*POP
... |
[edit]
Wrong account...doh!
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed Jun 07, 2006 3:55 pm Post subject: |
|
Wow, nice catch. Good work byuu!  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 07, 2006 4:58 pm Post subject: Re: bsnes thread (v.016 & updated buglist) |
|
Awesome!!! Edited buglist to reflect your findings. |
|
Agozer 16-bit Corpse | Nyoron


Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
|
Posted: Wed Jun 07, 2006 5:04 pm Post subject: |
|
Wht exactly was wrong with these games before the bugfix?
_________________
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. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Wed Jun 07, 2006 5:29 pm Post subject: |
|
According to byuu's post that Ichinisan quoted, it was something to do with HDMA.
or so that's what I gathered.
_________________

<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: Wed Jun 07, 2006 5:30 pm Post subject: |
|
Graphical
stuff. In ToP, a background behind the trees would turn purple instead
of green. In Mortal Kombat, the screen would start showing static and
flipping out during battles. In GR, I dunno. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 07, 2006 5:41 pm Post subject: |
|
I said what the problem was under each screenshot. GR was corrupting the bottom statusbox when text would appear onscreen.
Eh, numbers aren't looking as good anymore. This doesn't fix SoM's
intro, JP2 intro, RPM racing tracks nor EWJ2's audio.
So that's three fixes to four nonfixes. Still, there's plenty of other
games and surely this fixes at least one more of the bugs. I hope. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 07, 2006 6:19 pm Post subject: |
|
I think Accele Brid and Death Brade are prime candidates for a checkup.
The important thing is, even if it isn't fixing a bunch more on the
list, the fixes that have been made thus far haven't been breaking
other things. So accuracy is actually improving, not just shifting
around. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 07, 2006 8:23 pm Post subject: |
|
Quote: |
The
important thing is, even if it isn't fixing a bunch more on the list,
the fixes that have been made thus far haven't been breaking other
things. So accuracy is actually improving, not just shifting around. |
Exactly. It's possible that I might fix something which breaks
something else by understanding the matter incorrectly. But given I'm
willing to spend as much time as needed, to implement even the tiniest
hardware quirk I know about, even if it means rewriting the entire
emulator in the process (and I've done this multiple times); the
accuracy will only continue to improve. And eventually, we'll be able
to run every last known game, with zero game-specific hacks :)
Either that, or I'll burn out and hopefully other emulator authors will follow and reach this goal one day.
The good news is that all of my fixes thus far have been simple
oversights. It's a strong sign that the actual cores, eg the really
important parts, are mostly correct.
EDIT :

Ignore the version number, it's my work build that's behind my home
build. No idea what fixed it, probably the same thing that fixed the
lockups in Rendering Ranger R2. Seems to get a lot further (it did not
lock up at all on me). I'd like someone who can actually play the game
to verify it's fixed. Along with other bugs such as Rendering Ranger
R2, etc.
The lockup issues in games seems to be mostly resolved overall, though.
Excepting the IRQ not firing issues, of course.
Deathbrade still does the same thing. That's a pretty hillarious bug,
actually. "Ready? Set? TIME OVER, YOU LOSE!" Heh, consider that one a
"feature" :)
Hmm, going into the options screen shows the counter starts at 00, and
you can change it and get time to play the game with. The bug still
needs to be fixed, of course. Probably an invalid memory read somewhere.
And as for the game itself, are you actually supposed to be able to do
anything in it, or is the game basically just to get grabbed by the
opponent and thrown. And then have the opponent walk on top of you when
you're on the ground and repeat the process over and over until you're
dead? There's not many fighters where my first ever round ends without
me damaging the opponent at all. Hmm...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 07, 2006 11:11 pm Post subject: |
|
Both
games are pretty awful in terms of gameplay. Although, for Death Brade,
you can tell it's going to suck from the moment it starts.
Good to hear that Accele Brid appears to work now. It would hang about
7 seconds into gameplay. If you got farther than that and noticed
nothing odd, there's a good chance it's also fixed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 12:37 am Post subject: |
|
Looks like I was a bit overzealous with the HDMA fix.
Bugs Bunny - Rabbit Rampage (E, U, J) - gfx tile issue during gameplay
- Still there
BETA Corn Buster (NL) - intro gfx garbled, sound issues, hangs during gameplay
- Still there, great test ROM with immediate problem to look at
BETA Killer Instinct () - fails to play
- Didn't test
Chou Aniki - Bakuretsu Rantou Hen (J) - fails to play
- Refuse to test :P
Death Brade (J) - fight ends as it starts
- Still there
Derby Stallion 96 (J) - fails to play
- Didn't test
Earthworm Jim 2 (E) - sound issues (U region does not exhibit)
- Still there
Hungry Dinosaurs (E) - small gfx issue on transition change
- VERY subtle, I think it's still there. It looks the same as v0.016
Jurassic Park II (E, U) - hangs after ocean logo is allowed to play.
- Still there
Mighty Morphin Power Rangers - The Movie (E, U) - garbled/missing sprites
- Still there. Odd one, looks like sprite wrapping problem, but thats
not the case as I've verified my sprite wrapping is very accurate with
lots of complex test ROMs :/
Has to be something else, most likely.
Power Drive (E) - letters garbled at namescreen, can't drive car
- Still there
Radical Psycho Machine Racing (U) - track draw issues (J region does not exhibit)
- Still there
Secret of Mana (E, Fr, G, J, U) - mode7 overworld issues
- Still there (MAYBE a color add/sub bug? an odd one for sure)
Super Conflict (E, U) - small gfx issue on title screen
- Still there, not much hope on this one. Both me and Overload are stuck on this one.
Wild Guns (E, J, U) - hangs before level starts
- Still there, not much hope on this one either. NMI+DMA timing required, no idea how ZSNES9x play this game.
World Class Rugby (E) - garbled gfx during gameplay
- Can't even get in-game on either v0.016 or v0.016.17. The game completely dies before starting.
---
I'm kind of interested to know what my compatibility rate is at this point.
Also, I forgot. Are we not listing special chip game bugs because they
could be bugs in the special chips and not the core emulation itself?
I'm honestly not sure where the two small problems in MMX2 come from. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 08, 2006 1:01 am Post subject: |
|
Aerdan
had that Mega Man bug on his list, but I never noticed anything odd
when I played it, so I didn't list it. I don't really know what it is.
Anyone care to post screenshots and describe the problem? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 1:29 am Post subject: |
|
There's
two problems. The first one is during the opening stage. When you get
past the three things in the start, you go down and there's a rail line
that's assembling these flying robot things. However, the robots start
off fully assembled, rather than being pieced together at each "stop"
on the rail. Hard to explain, you'd have to see it in ZSNES to follow
it.
Second, the alligator stage has some graphical
corruption on the swap / poison / lava / whatever the hell liquid stuff
it is. I don't know if this one has been fixed. I haven't played that
far into the game since I first saw it when Nach and I first added C4
support. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Jun 08, 2006 2:54 am Post subject: |
|
byuu wrote: |
BETA Corn Buster (NL) - intro gfx garbled, sound issues, hangs during gameplay
- Still there, great test ROM with immediate problem to look at
|
Perhaps the odds side is throwing off your memory mapping?
A quick "nsrt -pad" should be good enough to see if that's your problem.
byuu wrote: |
BETA Killer Instinct () - fails to play
- Didn't test
|
And which is this? Could be it's a bad ROM.
byuu wrote: |
Derby Stallion 96 (J) - fails to play
- Didn't test
|
Requires special memory map. This game uses special BS-X carts.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 3:28 am Post subject: |
|
Quote: |
Perhaps the odds side is throwing off your memory mapping? |
Yep, that would be the problem. Thank you, Nach :)
What the hell kind of size is 15mbit? Does the cart really have
8+4+2+1mb ROM chips, or is Cowering just being a dumbass as always?
Quote: |
Requires special memory map. This game uses special BS-X carts. |
Ah, I'll probably count it off to the side then along with Y's III
SRAM, until I get in a CRC32 ROM database and custom cart mappers.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 08, 2006 6:01 am Post subject: |
|
K,
I've added MMX2. As for the BETA Killer Instinct rom, it's in the NSRT
database and it works in zsnes, so I'm thinking it's a bug. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 7:01 am Post subject: |
|
You can nuke Corn Buster, if you like. Padding to 16mb solves all three issues. Interesting game. Stupid, but interesting.
Fascinating. Before writing an SNES emulator, I never realized just how
many truly awful games there really were for this platform. Lucky me ;)
I'll take care of this and other odd ROM sizes by allocating blank
memory up on the "second" chip. Getting tired of this hacking around
memory mapping issues, though. Need to get started on that mapper
database already. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Jun 08, 2006 8:55 am Post subject: |
|
FitzRoy wrote: |
I think Accele Brid and Death Brade are prime candidates for a checkup.
The important thing is, even if it isn't fixing a bunch more on the
list, the fixes that have been made thus far haven't been breaking
other things. So accuracy is actually improving, not just shifting
around. |
Errr...ya,agree. Not that I'm thinking about another (very well known)
Snes emulator or anything like that...but I should just shut up at this
point.
Anyway,nice work to byuu for finding out what was wrong, even if was a simple oversight.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 08, 2006 1:57 pm Post subject: |
|
byuu wrote: |
You can nuke Corn Buster, if you like. Padding to 16mb solves all three issues. Interesting game. Stupid, but interesting.
Fascinating. Before writing an SNES emulator, I never realized just how
many truly awful games there really were for this platform. Lucky me 
I'll take care of this and other odd ROM sizes by allocating blank
memory up on the "second" chip. Getting tired of this hacking around
memory mapping issues, though. Need to get started on that mapper
database already. |
Is there any way i can help you getting the database together
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 3:17 pm Post subject: |
|
Sure, buy every SNES game ever made and submit the PCB strings to Overload and myself ;) |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Thu Jun 08, 2006 4:11 pm Post subject: |
|
byuu wrote: |
Fascinating.
Before writing an SNES emulator, I never realized just how many truly
awful games there really were for this platform. Lucky me ;) |
Haha. Even the "Great Golden Console" has its flops. :p
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 08, 2006 6:07 pm Post subject: |
|
Killer Instinct (Beta) problem :
Code: |
* Image Name : "G"
* Region : NTSC
* Address Decoder : 20
* SRAM Size : 2kb
* Coprocessor(s) : None
* Reset:00a0 NMI[n]:0000 IRQ[n]:0207 BRK[n]:2800 COP[n]:0007
* NMI[e]:312a IRQ[e]:5000 BRK[e]:5000 COP[e]:4552 |
Header detection is failing. I think I'll start outputting the scoring
info to make debugging these problems easier.
The game still has some graphical glitches (ones ZSNES doesn't have)
and the real KI has some in battles still. Again, ZSNES doesn't have
these.
I might as well test all the "doesn't load" games for header detection problems.
Well, that leaves the worst game ever made (Aniki) and the dumbest
(Derby Stallion 96). The former is getting stuck waiting for an NMI to
trigger that never does (haven't bothered to research why, rewriting
the NMI / IRQ stuff for the new CPU core anyway, same thing with
Jurassic Park 2), the latter needs BS-X mapping stuff, even though it's
an actual cartridge (I know, it has a slot for BS-X memory carts on the
top, I've owned the cartridge in the past).
Also, you might want to add Uniracers, which needs a hack or something
nobody knows how to emulate (mid-frame OAM address writes require PPU
emulation to update the address as it processes, but we don't know how
this address gets incremented by hardware just yet).
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 08, 2006 9:34 pm Post subject: |
|
K, I added Killer Instict, Uniracers, and Ys III. |
|
cout New Member
Joined: 19 Jun 2006
Posts: 1
|
Posted: Mon Jun 19, 2006 10:53 pm Post subject: |
|
pagefault wrote: |
Many
cards do not support RGB overlays, ATI and nVidia cards included. You
will have to convert to YUV to use the overlay. Since you have to most
likely do this in software it almost defeats any advantage overlays
would give you. I looked into this a while ago and decided it wasn't a
viable solution. Funny thing is that in linux RGB overlays are
supported by Xv. So it must be a driver thing. |
I actually implemented overlay support on linux for fceu and found the
performance benefits to be significant. I was lucky enough to develop
on a box that supports RGB overlays (this made development easier);
without overlay support the CPU was pegged when drawing at 3x scale,
and with it the CPU sat at a nice 20%. I ported the code to a box that
supports only YV12 overlays and found performance wasn't that much
better than without overlays, until I pre-calculated the RGB-to-YUV
conversions (one nice thing about 8-bit graphics is your color lookup
tables stay small). I was able to get fullscreen 640x480 at 30fps with
overlay support, whereas I couldn't get half that before the changes.
I'd rather run at 320x240 and get a higher framerate, but the linux X
drivers don't support 320x240 on my epia when I'm using TV out (oddly
this does work on windows, iirc).
As for whether overlays would have benefit an snes emulator,
pre-calculating the YUV conversions might work, but I suspect that
might also have negative implications for cache performance. The only
way to know is to try, and I think it's at least worth a shot.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 20, 2006 12:06 am Post subject: |
|
I
cache BGR->RGB transformations already. While I could do this prior,
I'd then have to hardcode RGB555<>RGB565<>RGB888
transformations directly into the PPU core rendering routines, and I'm
willing to sacrifice speed to isolate all components of base emulation
from the platform-specific implementations. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 26, 2006 9:03 am Post subject: |
|
My webserver won't let me upload files without instantly terminating the connection so I can't update my site.
So I'll just post here for anyone who cares. I have most of sCPU
working now. Sadly, I simply can't find any ways to improve the way
add_cycles() and poll_interrupts() work, so it's pretty much just going
to be implemented the exact same way.
I have NMI, IRQ and WAI support in there now, and most games run fine.
But all of the really intensive ROMs (my NMI and IRQ timing tests, EWJ2
sound effects, ToP vocals) fail still. Just need to track down the
differences between the two (bCPU and sCPU) to find out what's going
on. It'll probably be another week or two, but then sCPU should be
ready excepting perfect DMA+HDMA timing (it'll be within 6 clock cycles
of accuracy).
Oh well, nice to see this cothreading idea is most likely going to
work, and at least the CPU core is cleaner. But all of the more
important timing stuff (interrupts, H/DMA sync timing, etc) are going
to be just as ugly as ever. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Jun 26, 2006 10:50 pm Post subject: |
|
Good work man, thanks for the update.  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jun 27, 2006 7:35 am Post subject: |
|
Mmm, can't wait for sCPU. If it ends up being more accurate and as fast/faster, I take it you plan to drop bcpu entirely? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 27, 2006 8:46 am Post subject: |
|
Not anytime soon. It's the only way to compile on PPC Macs, for one. Or really, any non-x86 architecture.
Since it's faster than bCPU anyway, and "twice" as accurate between
CPU<>APU communications (or more accurately, as accurate as is
necessary for 100% accuracy), I don't see any reason not to replace
bCPU with something like an opcode-based core that runs for speed and
has savestates and all that jazz sometime far into the future.
The real question is how to go between the two. Enabling polymorphism
(the ability to switch between bCPU and sCPU during runtime) takes a
10% speedhit. And I really don't feel like making separate builds for
all the different compile-time options and core combinations. Then more
for with and without debugger. Etc, etc. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 06, 2006 1:53 pm Post subject: |
|
Alright,
I can upload to my site again. sCPU is completed. Runs all the fun
stuff fine. My exact clock position timing tests, ToP, EWJ2, etc, and
passes the infamous electronics test.
Any, quick
question. Nach brought up an interesting point the other day on IRC
about bsnes' memory usage. I haven't really been paying attention to it
and it has nearly doubled since v0.013. It has gone up because I've
been adding more memory lookup tables to speed things up. I figure,
bsnes already requires a powerful PC, so I might as well equalize RAM
requirements vs CPU requirements. But would you guys prefer speed or
RAM conservation? For about a 5-10% speed hit, I can cut the RAM usage
back in half again. Right now, it needs up to 22mb for the largest 6mb
ROMs to run, and 13mb for the smallest. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 06, 2006 2:17 pm Post subject: |
|
Pff. 20mb is nothing. I'll take the speed.
Good job on sCPU btw. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Thu Jul 06, 2006 2:28 pm Post subject: |
|
Firefox
can easily sop up 90+MB of RAM, and people frequently have a web
browser running at the same time as other programs (Word Processing,
Solitaire, whatever). None of which are really thought of as being
terribly intensive tasks.
So I agree with FitzRoy - 20MB is nothing. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jul 06, 2006 6:17 pm Post subject: |
|
You can start to worry when it hits 200 MB. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 06, 2006 6:48 pm Post subject: |
|
I doubt (read: hope) it will never need more than 64mb, unless I decide to get really extravagent.
So ok then, I won't worry about it so much. And now Nach is advising
his concerns are over memory leaks and not memory usage. I don't see
any active leaks, in that I can load and unload games, and play them
for several hours without the memory usage going up any, but apparently
Valgrind goes crazy when you run bsnes in it. I'm guessing it's all
stuff that's only called at program start/exit, such as the
configuration file parser. The actual emulation code is pretty good
about not allocating memory except when absolutely needed.
I'll either need someone to give me Valgrind logs so I can fix the
problems, or install Linux one of these years and do it myself :/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 06, 2006 7:13 pm Post subject: |
|
Linux, eh? Cat out of the bag?  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 08, 2006 9:12 am Post subject: |
|
New news has nothing to do with Linux.
Some really good news though that I'd like to share: I was messing
around with some #defines to swap between the CPU and APU cores. I made
a FAVOR_ACCURACY / FAVOR_SPEED switch. The difference is that
FAVOR_ACCURACY will sync in between each opcode cycle for both the CPU
and the APU. Whereas FAVOR_SPEED will sync between each opcode.
However, I was thinking about it... right now I have a CPU, APU and PPU
that runs the system. There's no need to sync against the memory bus as
the processors emulate bus hold times themselves. And right now, the
PPU is a scanline-based renderer, meaning bus accuracy does it
absolutely no good whatsoever.
So really, all I need to do to get the same degree of CPU<>APU
communication accuracy is to call co_return() when polling the
CPU<>APU bridge ports ($2140-$217f<>$f4-$f7) -- similarly,
CPU<>PPU syncs with a dot based renderer could be done by syncing
on CPU accesses to $2100-$213f (shared bridge). This way, the
communication between these two is now bus-accurate, which is as
accurate as I can possibly imagine code being. However, all of the
stuff that isn't visible outside the respective core now runs as if it
were an opcode based core.
So the true magic of sCPU and sAPU show off now.
The result?
[ FAVOR_ACCURACY ]
DL title: 101fps
Zelda 3 save select: 80fps
[ FAVOR_SPEED ]
DL title: 120fps
Zelda 3 save select: 96fps
[ FAVOR_SPEED + PGO - debugger ]
DL title: 174fps
Zelda 3 save select: 137fps
Hmm, 75% faster than a straight build of bsnes v0.016. Impressive enough for you? :)
Of course the official v0.016 has PGO enabled, so this is really only ~20-25% faster than the last release.
Now, the question is... should I distribute release builds using
FAVOR_ACCURACY, or FAVOR_SPEED? Please keep in mind, the two perform
identical to every last little bit / clock. The input and output is
100% bit-identical, as can be compared by logging APU data and checking
PPU latch counter positions. However, there's a 20% speed boost for
FAVOR_SPEED.
There's another advantage, too. By lowering the CPU and APU
requirements by so much, the bottleneck is shifted far more towards the
PPU. This means frameskip becomes much more effective. For example,
FAVOR_ACCURACY from frameskip 0 to 9 results in a ~62.5% speedup.
FAVOR_SPEED from frameskip 0 to 9 results in a ~87.5% speedup.
Meaning with the simple mode3 DL title screen, I can push a blistering
324fps on a 3500+ with maxed out optimizations, and no accuracy loss!
And in case you think I'm exaggerating...

Frameskip = 0

Frameskip = 9 |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Jul 08, 2006 10:12 am Post subject: |
|
Awesome news! 
So FAVOR_ACCURACY is not needed any more? Or are there still cases left where it is required?
_________________
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: Sat Jul 08, 2006 10:25 am Post subject: |
|
It's nice to guess wrong this time. That's plain AMAZING! This should get a lot more people playing full 50/60fps. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 08, 2006 11:11 am Post subject: |
|
creaothceann wrote: |
So FAVOR_ACCURACY is not needed any more? |
Technically, no, it isn't. I want to leave it as a compile-time option.
It will be useful for seeing CPU<>APU intermixing when debugging
code. Technically, the current code could execute the opcode cycles out
of order. But it doesn't matter since accesses between each other are
synced to bus accuracy still. Which is pretty much as accurate as is
possible through emulation, so there's zero room for timing/accuracy
improvements over the CPU<>APU bridge at this point. It is
technically impossible
for the actual bytes transferred across the CPU<>APU bridge to
differ between these two implementations. And thusly, the user
experience is 100% identical. I played the entire ToP intro in both
modes and hex compared the PCM dumps of each. Bit-perfect match.
Now, the thing is... by not truly running them in perfect parallelism,
it deviates from the true SNES hardware... the inputs and outputs are
identical, but they aren't truly being emulated as parallel tasks, but
rather as slaves to each other, running until they need input from the
other. So, that's why I wanted to know what everyone would prefer me to
use as the default
when I compile new public release builds. The truly pedantic could
argue this differs from my stated academic programming approach to the
emulator. grinvader and Bisqwit recommended the speed mode on IRC so
far.
Anyway, I'd like some beta testers for
v0.017. I plan to make a release soon. I wanted to get that "news item"
thing taken care of, but that ran into some snags, sadly, and I see no
reason to hold things up any longer. Ideally, I want to release
tomorrow. But maybe next week if I run short on time.
Quote: |
It's nice to guess wrong this time. |
Agreed. I took a hell of a longshot in the dark with this whole
cothreading thing from the beginning. I believe it's an emulation
first. Lucky for me, it paid off in the end :D
Heh, so I wonder if I can "persuade" some other emu authors to look at
libco now. Twice the accuracy, 30% faster and way
more readable code than a cycle-based core. I even have a trick for
savestates now (which I won't be adding anytime soon to bsnes, so don't
bug me about it :P ).
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jul 08, 2006 11:22 am Post subject: |
|
If
the output is the same as an snes, then I would consider that an
optimization. It's a good one, too. You can always make a note of real
hardware discrepencies, but for releases people are going to take the
speed if it comes at no cost of accuracy. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Jul 08, 2006 11:53 am Post subject: |
|
byuu wrote: |
I wanted to know what everyone would prefer me to use as the default
when I compile new public release builds. The truly pedantic could
argue this differs from my stated academic programming approach to the
emulator. grinvader and Bisqwit recommended the speed mode on IRC so
far. |
If someone is pedantic enough to insist on theoretic
aspects that have no effect on the final quality... then they're
probably nerdy enough to compile the source by themselves with the
changed #defines. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Jul 08, 2006 4:11 pm Post subject: |
|
Wow
this is awesome news. Personally, I think it should be FAVOR_SPEED
that's used. Gee, I can't wait to let this new version rip on my
system.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 09, 2006 1:38 am Post subject: |
|
Here's a WIP to try out, it's 20-40% slower than it should be, due to PGO crashing the compiler*.
Please copy and paste link, and do not post this on emulation news sites or I will remove the file.
byuu.org/files/bsnes_v016_wip27.zip
Even though it's slower, could I get some people to try running through
a bunch of games and look for new bugs? Given I rewrote the entire
CPU+APU, it's possible some new bugs crept in.
* No release this weekend. Please be sure to thank Microsoft personally for the delay.
Code: |
rc /r /fobsnes.res bsnes.rc
cl /Febsnes.exe /nologo /O2 /GL /EHsc main.obj libco.obj libstring.obj
libconfig.obj libbpf.obj reader.obj cart.obj cheat.obj memory.obj bmemory.obj
cpu.obj scpu.obj bcpu.obj apu.obj sapu.obj bapu.obj bdsp.obj ppu.obj bppu.ob
j snes.obj srtc.obj sdd1.obj c4.obj dsp1.obj dsp2.obj obc1.obj adler32.obj co
mpress.obj crc32.obj deflate.obj gzio.obj inffast.obj inflate.obj inftrees.obj
ioapi.obj trees.obj unzip.obj zip.obj zutil.obj jma.obj jcrc32.obj lzmadec.obj
7zlzma.obj iiostrm.obj inbyte.obj lzma.obj winout.obj bsnes.res kernel32.lib use
r32.lib gdi32.lib comdlg32.lib comctl32.lib d3d9.lib d3dx9.lib ddraw.lib dsound
.lib dinput8.lib dxguid.lib /link /PGD:bsnes.pgd /LTCG:PGOPTIMIZE
Merging bsnes!1.pgc
Generating code
\bsnes\src\apu\sapu\core\core.cpp(16) : fatal error C1001: An internal er
ror has occurred in the compiler.
(compiler file 'f:\rtm\vctools\compiler\utc\src\P2\main.c[0x10CB9ABB:0x00000025]
', line 182)
To work around this problem, try simplifying or changing the program near the l
ocations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage |
What is on sapu\core\core.cpp(16) that's too complex for Visual c++ to handle?
Code: |
status.in_opcode = false; |
Please, if anyone can simplify that for me, let me know.
Seriously, though, if anyone can take a look at the source and fix this
compiler error I'd really appreciate it, and I'll get a release out
this weekend. I'm using Visual C++ 2005 Professional. Otherwise I'll
have to set it aside because I don't have time.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Jul 09, 2006 2:30 am Post subject: |
|
byuu wrote: |
creaothceann wrote: |
So FAVOR_ACCURACY is not needed any more? |
Technically, no, it isn't. I want to leave it as a compile-time option.
It will be useful for seeing CPU<>APU intermixing when debugging
code. Technically, the current code could execute the opcode cycles out
of order. But it doesn't matter since accesses between each other are
synced to bus accuracy still. Which is pretty much as accurate as is
possible through emulation, so there's zero room for timing/accuracy
improvements over the CPU<>APU bridge at this point. It is
technically impossible
for the actual bytes transferred across the CPU<>APU bridge to
differ between these two implementations. And thusly, the user
experience is 100% identical. I played the entire ToP intro in both
modes and hex compared the PCM dumps of each. Bit-perfect match.
Now, the thing is... by not truly running them in perfect parallelism,
it deviates from the true SNES hardware... the inputs and outputs are
identical, but they aren't truly being emulated as parallel tasks, but
rather as slaves to each other, running until they need input from the
other. So, that's why I wanted to know what everyone would prefer me to
use as the default
when I compile new public release builds. The truly pedantic could
argue this differs from my stated academic programming approach to the
emulator. grinvader and Bisqwit recommended the speed mode on IRC so
far.
Anyway, I'd like some beta testers
for v0.017. I plan to make a release soon. I wanted to get that "news
item" thing taken care of, but that ran into some snags, sadly, and I
see no reason to hold things up any longer. Ideally, I want to release
tomorrow. But maybe next week if I run short on time.
|
I understand that the actual emulation would not be more accurate with
FAVOR_ACCURACY enabled ( clearly,you took the time to explain this in a
way that even the thickest of us would understand ) but like you said the Snes hardware technically didn't ran this way (even if the end result is unaffected)
FAVOR_SPEED is probably a better default option for most I guess, but
at least I hope you'll always keep Favor_accuracy in the source
code...ya know, for us pedantic folks lol
Anyway, I'm going to test wip27 right now!
Quote: |
Quote: |
It's nice to guess wrong this time. |
Agreed. I took a hell of a longshot in the dark with this whole
cothreading thing from the beginning. I believe it's an emulation
first. Lucky for me, it paid off in the end 
Heh, so I wonder if I can "persuade" some other emu authors to look at
libco now. Twice the accuracy, 30% faster and way
more readable code than a cycle-based core. I even have a trick for
savestates now (which I won't be adding anytime soon to bsnes, so don't
bug me about it ).
|
Last edited by Dmog on Sun Jul 09, 2006 2:47 am; edited 1 time in total
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Jul 09, 2006 2:48 am Post subject: |
|
I
found a quick bug. The scrolling text at the beginning of Memblers nsf
player is all messed up. Though I guess it's kind of iffy since I don't
know what it looks like on the real hardware.
bsnes v0.016 27

bsnes v0.016

Edit: Battle toads and double dragon seem to have a similer problem.

 |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Jul 09, 2006 3:20 am Post subject: |
|
Secret of Mana Mode 7 overworld looks correct now.
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 09, 2006 4:11 am Post subject: Re: bsnes thread (v.016 & updated buglist) |
|
Ok,
went through the list on the new core version. Several bugs are now
fixed. Secret of Mana bug is gone, Jurassic Park II no longer hangs,
Mighty Morphin Power Rangers - The Movie gfx are now unscrambled, and
Wild Guns now gets ingame, but the gfx are screwed up.
As for new bugs: Battletoads bug confirmed on both regions. Also,
high-res/interlace/whatever the hell it's called doesn't look right
anymore. Just go through the starting menus on RPM Racing to see what I
mean.
DSP1 is now supported, but not completely just yet, so I'll leave that
as is. I also noticed the infamous fitzroy exclusive sound crackling
bug has resurfaced where it wasn't on 016 official. I want to wait
before PGO optimizations are in before I officially complain about this
one. 
PS: You said to nix Corn Buster from the list, but it's still
exhibiting the same stuff as before. What's the status on this one?
Also, something new I just noticed. Should frameskip settings be saved
on emulator exit? Because right now, they're not. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jul 09, 2006 5:46 am Post subject: |
|
Looks good but I get lots of graphical corruption in KI whenever the player sprites move. I can also verify the Battletoads bug. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 09, 2006 8:13 am Post subject: |
|
I'll
look into NSF + Battletoads and compare them against bCPU. It's either
the recent HDMA fix or the replacement CPU core. Damn, I was hoping
bsnes wouldn't end up reverting working games to broken status :(
I guess that's what happens when you rewrite the entire core.
Yay, three bugs gone! Wild Guns I know about. HDMA sync delay timing is
what breaks it completely. It can be fixed by swapping the order of two
opcodes, but I'm not willing to do that, so... oh well.
I don't know what's up with sound crackling. I've sort of noticed it
myself, but the sound output code hasn't changed.
RPM racing looks fine to me. All hires+interlace games do. I'm not sure what you mean.
Corn Buster and KI beta need some memory map tricks. I'm waiting until
I add all of the "true" memory mappers before I fix them properly. In
the mean time my fix was to just pad the games to their proper size.
They're very likely underdumped simply because the end of the ROM was
all 00s.
DSP-1 was the "surprise", but as you can see, there's a bug with sprites not displaying.
KI graphics bug is already known and on the bug list. Thanks for verifying Battletoads. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 09, 2006 9:10 am Post subject: |
|
Oops.
Ok, for the hires/int thing... I had frameskipping on, and that was
screwing up the gfx in RPM Racing. Is that normal behavior for these
types of games?
And regarding DSP1: if you didn't
know, it seems to go beyond sprites not showing up. Ace wo Nerae! for
example, hangs at start. Might be unrelated to chip support, though. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 09, 2006 9:34 am Post subject: |
|
Ok,
I tried converting the switch/case table to a jump table for both
CPU+APU cores. Results? EXE is 70kb larger, compile time is 5-10%
slower, and speed is identical. Needless to say I reverted that change
back. I then tried narrowing down the cause of the PGO error. Found out
it was Dai Kaijuu Monogatari. If I don't run that, I can build with
PGO. Unfortunately, this is the ROM I use to stress optimize color
add/sub. So as a result, this game will run a little slowly now (sort
of like how Chrono Trigger's OPT title screen effects were before).
But, better one game than all, right?
byuu.org/files/bsnes_v016_wip27a.zip
Once again, please do not submit news about this to an emulation site.
The file will be removed if I notice anyone mentioning it anywhere.
That will be 20-25% faster than wip27, but otherwise everything is identical.
DSP1: there's either a bug in op02, op06, or in the getSr/getDr/setDr
functions. We have so far been unable to spot the error and correct it.
Help is always welcome, as always. Please consider DSP-1 support as not
being there at all. I doubt any games will work right with it right now
:(
This is how interlace works :
I call each frame a "field", meaning even or odd fields on your television / monitor.
When interlace is off, I draw to the even fields every time, so you don't notice anything.
However, when interlace is on, I alternate between which one I draw to
each field. So depending on your frameskip, this can cause serious
problems for interlace mode. I also only physically draw to "half" the
resolution each field, much like a real TV would. This makes 512x448
mode just as fast as 512x224 mode.
I can't think of an easy way to cheat the system with frameskipping.
Luckily, very very few games use interlace at all. Most use hires
512x224 and that's it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 09, 2006 10:37 am Post subject: |
|
I
suspected that was normal behavior with skipping frames on interlaced
games. Thus the oops. I've only a basic understanding of
interlace/progressive, but thanks for explaining it better. Better to
ask though and be certain it wasn't a bug or anything...
The sound crackling every 10 second interval thing is still there for
this version. I'm going to see if I can test it on my friend's computer
tomorrow. He has a different sound card than me. I'm at the lowest
latency setting on my card (48 sample) and setting it higher only makes
it worse. Are you guys certain you aren't getting this stuff on your
comps?
Did Kode54 do something inaccurate, like drop a frame in order to fix
this, that you weren't willing to impliment? I recall that on his
build, every sample setting worked on my setup. Maybe we can compromise
with an option or something. I really don't want to downgrade my sound
card  |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sun Jul 09, 2006 11:17 am Post subject: |
|
Sorry
in advance as I haven't followed the conversation, but is Super Mario
Kart supposed to have so many sprites missing ? In fact, you can only
see your own driver... |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Jul 09, 2006 1:00 pm Post subject: |
|
stifu:
Read byuu's last post; SMK is a DSP1 game.
<offtopic>
re: http://byuu.cinnamonpirate.com/images/bs_225.png
Is "englisch version" the real original spelling?
Because the proper german form would be "englische version".
</offtopic>
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sun Jul 09, 2006 2:29 pm Post subject: |
|
creaothceann wrote: |
stifu:
Read byuu's last post; SMK is a DSP1 game. |
Heh okay, I didn't realize. I'm not very familiar with chip names
either, although I knew SMK used a special chip, I had forgotten it was
the DSP1...
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 2:06 am Post subject: |
|
Latest bsnes 016.27a WIP testing report and some questions:
- All Donkey Kong Country games are broken,only the top half or quarter screen is visible.
- Black Screen in Killer Instinct battles
- SNES Test Cartridge Electronics test - FAILED! when Frameskip is enabled,otherwise it passes
- The Screen Width and Screen Refresh are swapped (mixed up) in the Options Menu
- Why there's no "Pause when Inactive" option? Even if the emu is minimized to taskbar,it still runs
- Why there's no "sleep" (use less CPU) option? It uses 100% CPU all
the time and makes the OS extremely sluggish while bsnes is running
(even if I need only 1/3 of that 100% CPU time to get 60fps)
- Is bsnes using the latest version of the NTSC filter? (because it's
*much* more CPU intensive than HQ2x,but I don't notice such a slowdown
with the newer versions of NEStopia or ZSNES WIP)
- Why there's no TURBO button in bsnes,just for skipping long intros while testing?
- I would like to see a mode that downgrades 60fps(Hz) NTSC-U / J games
to 50Hz(fps),so I can simulate the NTSC-to-PAL converter I use in my
PAL SNES.It slows down 60fps NTSC games to 50fps.
- Sound pops for me only when framerate drops below 60fps (at 32kHz/100% speed setting) At 60fps sound is OK. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 2:10 am Post subject: |
|
I'll do even more testing later. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 10, 2006 3:07 am Post subject: |
|
- All Donkey Kong Country games are broken,only the top half or quarter screen is visible.
Same bug as Battletoads. Ok, this has to be fixed before a new release.
- Black Screen in Killer Instinct battles
Odd.
- SNES Test Cartridge Electronics test - FAILED! when Frameskip is enabled,otherwise it passes
Very odd. Nice catch.
- The Screen Width and Screen Refresh are swapped (mixed up) in the Options Menu
I don't seem to have a problem there... will double check code though.
- Why there's no "Pause when Inactive" option? Even if the emu is minimized to taskbar,it still runs
I added it as "f12" to pause. "f11" is fullscreen toggle. I like having
bsnes run in the background, especially when I'm building PGO releases
as the framerate is 5-15fps when I do that. I'll see about making it an
option.
-
Why there's no "sleep" (use less CPU) option? It uses 100% CPU all the
time and makes the OS extremely sluggish while bsnes is running (even
if I need only 1/3 of that 100% CPU time to get 60fps)
Because even if I add the tiniest micro sleep function when something
is running at 180fps uncapped, the emulator will no longer run at 60fps
and sound pops :(
-
Is bsnes using the latest version of the NTSC filter? (because it's
*much* more CPU intensive than HQ2x,but I don't notice such a slowdown
with the newer versions of NEStopia or ZSNES WIP)
Yes. I don't know, maybe because HQ2x was optimized by blargg?
- Why there's no TURBO button in bsnes,just for skipping long intros while testing?
Use ctrl+ and ctrl- to adjust speed. I prefer it sticking like that so
that I can play games like MMX2 I would otherwise be left out in the
cold on. My reflexes aren't good enough anymore to beat games like that
without slowing the games down :(
-
I would like to see a mode that downgrades 60fps(Hz) NTSC-U / J games
to 50Hz(fps),so I can simulate the NTSC-to-PAL converter I use in my
PAL SNES.It slows down 60fps NTSC games to 50fps.
Well, you can change the region code in the ROM to do that. I can't
think of any legitimate reasons for doing this. I will however see
about adding "force" ROM load options in there somehow in the future.
Thanks for the feedback. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 3:25 am Post subject: |
|
Quote: |
- The Screen Width and Screen Refresh are swapped (mixed up) in the Options Menu
I don't seem to have a problem there... will double check code though. |
I mean the values in the input boxes.
There's now 0 in the screen width box and 480 in the refresh rate one.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jul 10, 2006 9:04 am Post subject: |
|
DKC's
are RARE developed games. Battletoads in Battlemaniacs hasn't been
mentioned and also has the issue. Killer Instinct is RARE. I checked
Ken Griffey Jr for shits, but its problem free. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 10, 2006 2:26 pm Post subject: |
|
Quote: |
I mean the values in the input boxes.
There's now 0 in the screen width box and 480 in the refresh rate one. |
Hmm, did you delete your old config file and replace it with the new
one? I can't reproduce this problem... anyone else noticing this?
Quote: |
DKC's
are RARE developed games. Battletoads in Battlemaniacs hasn't been
mentioned and also has the issue. Killer Instinct is RARE. I checked
Ken Griffey Jr for shits, but its problem free. |
Indeed, they're both RARE games. Either way, the problem is now fixed.
I moved the line render check code from cycle_edge() to opcode_edge()
since it didn't require perfect time, and opcode_edge() was called less
often. However, DMA+HDMA were only calling cycle_edge(), so DMA and
HDMA were not rendering scanlines when they should have been.
This is now corrected, with screenshots on my homepage. DKC1-3+both Battletoads should be safe to remove.
The only problem left then that wasn't in v0.016 is that the SNES test
program fails with frameskipping on. I wouldn't add that one to the bug
list though, it's not a problem with the core emulation. I'll hopefully
have a fix here for it soon anyway. bCPU+bAPU fail the test too, so
compatibility appears to be the same between the two cores once again.
But if anyone has a problem with not adding it, then feel free to stick it in the list anyway.
|
|
Marty Nestopia Developer

Joined: 05 Dec 2005
Posts: 24
|
Posted: Mon Jul 10, 2006 4:11 pm Post subject: |
|
byuu wrote: |
Because
even if I add the tiniest micro sleep function when something is
running at 180fps uncapped, the emulator will no longer run at 60fps
and sound pops 
|
Ah, the unreliable Sleep(). Had a few battles with that one too. The
solution I came up with for my emulator was to maintain a variable that
keeps record of how long it's safe to Sleep() without overflow. It
starts at zero and increases in small doses until it stabilizes. In
case it becomes greater than the full frame wait time, Sleep() gets
skipped completely.
Here's a simplified code example of how I do it:
Code: |
void Timer_Reset()
{
safe_from_oversleep = 0;
coffee = 0;
}
void Timer_Wait()
{
if (sleep_time > smallest_period_returned_by_timeGetCaps + safe_from_oversleep)
{
::Sleep( sleep_time - safe_from_oversleep );
if (GetCurrentTime() > target_time)
{
safe_from_oversleep += coffee;
coffee ^= 1; // alternate to give it another chance in case of a win32 fluke
return;
}
}
// busy wait loop for the remaining time
BusyWaitUntil( target_time );
}
|
I usually reset the threshold variables on each emulation pause.
Oh, and another important step to make sure Sleep() has the best
granularity is to call timeBeginPeriod( min_period ) before use, e.g
app-startup, and timeEndPeriod( min_period ) when done. Have you tried
that?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 10, 2006 4:56 pm Post subject: |
|
Hmm,
didn't know about timeBegin/EndPeriod, thank you. It makes CPU usage
spike up quite a bit, but that's better than crackling sound. Doesn't appear to lose too much frames per second, but I can't fully test it since it's only called with speed regulation enabled.
I don't have a calculation to tell how many ms I need to sleep for, I
base it on the playback position of the DirectSound buffer. I suppose I
could work something out to do that, but I'm happy just calling
Sleep(1) for now. |
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Mon Jul 10, 2006 6:55 pm Post subject: |
|
byuu wrote: |
DSP1:
there's either a bug in op02, op06, or in the getSr/getDr/setDr
functions. We have so far been unable to spot the error and correct it.
Help is always welcome, as always. Please consider DSP-1 support as not
being there at all. I doubt any games will work right with it right now
 |
What seems to be the problem and what game(s) does it affect?
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 7:10 pm Post subject: |
|
I did some more testing today.
It's not only the RARE games having this bug,but a good deal of other games are also affected.
Here's some more issues and interesting bits I found:
- Spectre (U) - black screen instead of the intro and the options menu is garbled.
- Porno Manga (PD) doesn't work - Black screen Getting this rom working
is sort of a requirement for any good SNES emulator, *LOL*
- Rock'n'Roll Racing (U) - Music in the settings menu between races
gets muted after a random number of races.Sometimes it even mutes at
the character select before you start the first race! This also happens
in ZSNES.
- Realm (U) - This is interesting : the music in bsnes sounds *great*
,ZSNES has a problem of several sound channels cut/missing.They
reappear only when shooting like mad 
Indeed,it was the old .cfg that was causing the problem:
If you just overwrite the old .exe with the new WIP and keep the old config file,you get this issue
If you delete the old config,there are no problems.
Last edited by kick on Mon Jul 10, 2006 7:30 pm; edited 6 times in total |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 7:13 pm Post subject: |
|
Oh,I remember now:
HDMA Fish Demo (PD) and HDMA demo (PD) also weren't working,so it's definitely an HDMA issue 
Last edited by kick on Mon Jul 10, 2006 7:16 pm; edited 3 times in total |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Jul 10, 2006 7:14 pm Post subject: |
|
Yup...
timeBeginPeriod/timeEndPeriod... And if for whatever reason you feel
like checking the minimum supported resolution before setting it:
Code: |
MMRESULT result;
TIMECAPS tc;
if ( TIMERR_NOERROR == timeGetDevCaps( & tc, sizeof( TIMECAPS ) ) )
{
wait_timerres = min( max( tc.wPeriodMin, 1 /* or whatever */ ), tc.wPeriodMax );
timeBeginPeriod( wait_timerres );
} |
Oh yeah, and what about using DirectSound buffer position events and
WaitForSingleObject instead of polling for the current buffer position?
Of course, this only works reliably with software buffers. And then
you'd size the whole buffer to N frames in length, and events on every
frame interval.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 10, 2006 7:42 pm Post subject: |
|
Overload wrote: |
What seems to be the problem and what game(s) does it affect? |
I don't know of any DSP-1 games that work properly. I only have Super
Mario Kart, and the problem there is that no sprites ever show up other
than your own character on the top half of the screen. No other sprites
on the top or bottom.
Quote: |
It's not only the RARE games having this bug,but a good deal of other games are also affected. |
Yeah, H/DMA should hopefully be fixed now. Don't know about rocknroll
racing. Was this verified to not happen on real hardware?
Quote: |
Oh
yeah, and what about using DirectSound buffer position events and
WaitForSingleObject instead of polling for the current buffer position?
Of course, this only works reliably with software buffers. And then
you'd size the whole buffer to N frames in length, and events on every
frame interval. |
Sounds way more complicated. Any serious advantages to doing things this way?
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 7:42 pm Post subject: |
|
byuu wrote: |
Lastly,
some bug fixes. Secret of Mana's mode7 intro now works, Jurassic Park 2
no longer freezes during the opening sequence, and Wild Arms gets
in-game, but still has flickering issues. |
Wild Arms?
Was there a Wild Arms game for the SNES? LOL
Maybe it was some unreleased beta by SONY Imagesoft
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Mon Jul 10, 2006 8:36 pm Post subject: |
|
byuu wrote: |
Overload wrote: |
What seems to be the problem and what game(s) does it affect? |
I don't know of any DSP-1 games that work properly. I only have Super
Mario Kart, and the problem there is that no sprites ever show up other
than your own character on the top half of the screen. No other sprites
on the top or bottom.
|
Super Mario Kart PAL doesn't start either.
|
|
jezze New Member
Joined: 20 Jan 2005
Posts: 3
|
Posted: Mon Jul 10, 2006 8:59 pm Post subject: |
|
I think he means Wild Guns. 
I don't know if it was already mentioned, but the following screenshot of Seiken Densetsu 3 doesn't look right.

The second screenshot was captured with ZSNES, where it looks correct.

Maybe there is something wrong with the hi-res rendering?
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Jul 10, 2006 9:02 pm Post subject: |
|
byuu wrote: |
kode54 wrote: |
Oh
yeah, and what about using DirectSound buffer position events and
WaitForSingleObject instead of polling for the current buffer position?
Of course, this only works reliably with software buffers. And then
you'd size the whole buffer to N frames in length, and events on every
frame interval. |
Sounds way more complicated. Any serious advantages to doing things this way?
|
For one thing, the process is suspended for the duration of the
WaitForSingleObject call, until the buffer reaches one of the indicated
positions. Or, if you specify a delay, it can also fail if the event
was never signaled. VisualBoyAdvance already uses this method for its
speed regulation.
Anything which doesn't peg the CPU at 100% is better, especially for
laptops, where that eats your battery faster and fries your nuts.
jezze wrote: |
I think he means Wild Guns. 
I don't know if it was already mentioned, but the following screenshot
of Seiken Densetsu 3 doesn't look right.
image
The second screenshot was captured with ZSNES, where it looks correct.
image
Maybe there is something wrong with the hi-res rendering?
|
That would be the new pixel blending for high res modes, where every
pixel along the scanline is blended 50% with the pixel to the left of
it. The result is similar to a real video signal and display.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jul 10, 2006 9:35 pm Post subject: |
|
Quote: |
Anything
which doesn't peg the CPU at 100% is better, especially for laptops,
where that eats your battery faster and fries your nuts. |
Not to mention getting BSODs when your CPU overheats in these hot
summer days by running at 100% all the time,when you only need 1/3 of
that 'juice' to get bsnes at full framerate anyway.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jul 10, 2006 10:45 pm Post subject: |
|
Yay, the wierd screen draw bugs are fixed.
Thank you in advance kode54, if indeed your suggestions end up fixing my wierd sound crackling issues.
And thanks kick for testing more games. I'll verify your other bugs
with a new version, but I don't know what effects byuu's DKC fix might
have.
Find those bugs, people! |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Jul 11, 2006 12:10 am Post subject: |
|
Say
I'd like to compile bsnes with FAVOR_ACCURACY enabled.. what do I need
installed? (running XP) And what command line need to be entered? |
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Jul 11, 2006 6:38 am Post subject: |
|
jezze wrote: |
I don't know if it was already mentioned, but the following screenshot of Seiken Densetsu 3 doesn't look right.
image
The second screenshot was captured with ZSNES, where it looks correct.
image
Maybe there is something wrong with the hi-res rendering? |
There might even be some games that use that feature. Jurassic Park 1
maybe (unless that's another effect), Kirby Superstar 3 (water?), ...
_________________
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: Tue Jul 11, 2006 9:20 am Post subject: |
|
creaothceann has the 1000th thread reply! YOU WIN A NEW CAR!  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Jul 11, 2006 12:24 pm Post subject: |
|

_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 11, 2006 3:28 pm Post subject: |
|
Quote: |
- SNES Test Cartridge Electronics test - FAILED! when Frameskip is enabled,otherwise it passes |
This has actually been a bug from v0.015 onward, possibly even further
back. When I separated PPU::render_scanline() from PPU::scanline() (to
render a few dots into the scanline to fix some line flickering issues)
and rewrote some OAM rendering stuff, I ended up causing the OAM RTO
testing to only happen when the frame was not being skipped. So, this
is now fixed.
However, calculating the RTO status bits is expensive. I have to
traverse all sprites on every scanline and do lots of calculations. As
a result, frameskipping effectiveness drops from 70% speedup (at
frameskip 9) to 42.5% ... a 27.5% loss.
This only affects $213e reads. RTO sprite clipping still applies either
way. The only known game that checks these bits is the SNES Test
Program, and checking them really doesn't do a game a lot of good
anyway.
Further, one would fathom that nobody uses frameskipping unless they
had to for the game to be playable. So I'm thinking I should add this
to FAVOR_SPEED mode, and only calculate the RTO status flags *with
frameskip on* when FAVOR_ACCURACY is defined. The flags would be
calculated either way with frameskipping off. Anyone disagree with this?
Quote: |
There
might even be some games that use that feature. Jurassic Park 1 maybe
(unless that's another effect), Kirby Superstar 3 (water?), ... |
They require it to display the effects correctly. Hires and
Pseudo-hires blending work exactly the same way for both. It may not
look as pretty in an emulator, but it's more technically correct. I may
eventually make this an option, but it isn't a priority for me right
now.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 11, 2006 9:39 pm Post subject: |
|
I agree with your logic. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Jul 12, 2006 6:59 am Post subject: |
|
jezze wrote: |
 |
Take a look at the yellow flowers. I've always wondered why they have
those darker pixels in them (see ZSNES' output), and thought that the
rendering code might not be correct.
Now it turns out that the devs used them to make those flowers a bit darker! 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 12, 2006 12:53 pm Post subject: |
|
Quote: |
I also noticed the infamous fitzroy exclusive sound crackling bug has resurfaced where it wasn't on 016 official. |
I sort of noticed this in EWJ2, myself. Nach pointed out that Super
Bomberman 4 was hanging, and that turned out to be because I wasn't
syncing the DSP with the APU on accesses to ($f0-$f3)+($f8-$ff). It's
rather unbelievable that this is needed, since approximately eight APU
opcodes execute between each DSP cycle, but whatever. After correcting
this for SB4, I went back and played through EWJ2 again. I wasn't able
to notice a single crackling sound after beating the entire first
level, so I think this will resolve the issue for you as well.
Let's see... I also added Marty's timeBeginPeriod / timeEndPeriod
suggestion and made the emulator return unused CPU time back to the
system, so if you get >60fps and enable speed regulation, the
emulator won't eat 99% CPU time anymore.
Modified frameskipping with FAVOR_ACCURACY to calculate RTO status
flags even on unrendered frames. Takes a major speed hit, and is
bypassed with FAVOR_SPEED defined instead.
Started merging src/sdl and src/ui ports, while Nach has been helping
create a unified Makefile. This should make compiling for other
platforms far easier in the future.
Let's hope someone steps up with some GTK+/QT wizardry once I'm
finished so we can get a true UI into the Linux port.
Added PLATFORM_, COMPILER_ and PROCESSOR_ defines that are specified by
the makefile to control non-portable code usage inside the emulator.
|
|
jezze New Member
Joined: 20 Jan 2005
Posts: 3
|
Posted: Wed Jul 12, 2006 10:17 pm Post subject: |
|
Quote: |
Quote: |
There
might even be some games that use that feature. Jurassic Park 1 maybe
(unless that's another effect), Kirby Superstar 3 (water?), ... |
They require it to display the effects correctly. Hires and
Pseudo-hires blending work exactly the same way for both. It may not
look as pretty in an emulator, but it's more technically correct. I may
eventually make this an option, but it isn't a priority for me right
now.
|
Thanks for your explanation. I don't think that an additional option is necessary.
By the way, I found a bug that wasn't in v0.016.
The game "R-Type III - The Third Lightning" freeze after a certain
time, but it's dependent on which version of the game you're using.
(E) (5711) after about 40 seconds
(E) (21451) after about 100 seconds
(U) [!] after about 35 seconds
(J) after about 35 secons
I tryed it several times with a clean config file, but the game freezed
every time after the specified seconds. Can someone confirm this
problem?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 12, 2006 11:03 pm Post subject: |
|
I have confirmed your bug report jezze. And I've also confirmed that it does not happen in .016 official.
As for the Rock N Roll Racing report earlier from kick: this is normal
behavior for the game, I believe. There's not supposed to be any music
between races. I've logged countless hours on this game as a kid on the
real cart, so I'm pretty darn sure.
Spectre (U): Seems to have been fixed.
All the PD roms: god knows because I don't have any. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 12, 2006 11:20 pm Post subject: |
|
R-Type III confirmed. It never ends. It breaks when sCPU is used, but works with bCPU. FAVOR_ setting doesn't affect it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 13, 2006 6:11 am Post subject: |
|
Found
a new bug for you. In Fatal Fury Special, a few of the characters have
scrambled gfx. Same on .016, so no worries there. (E) region seems to
not have the problem. (U) has 3 bad characters, (J) has 2/3 of the (U)
ones.
ZSNES has similar problems, just not the
same characters. What's funny is it has more, but not the 3 you have.
Super Sleuth does not exhibit this in any region. Hope that helps.
PS: Game is known as Garou-something in (J) region. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Thu Jul 13, 2006 6:47 am Post subject: |
|
FitzRoy wrote: |
PS: Game is known as Garou-something in (J) region. |
Garou Densetsu Special...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 13, 2006 3:02 pm Post subject: |
|
Wild Guns is fixed, and KI beta now loads.
Should we merge the KI+KI beta bugs since they are basically the same game and suffer the exact same problem, or no? |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Jul 13, 2006 4:37 pm Post subject: |
|
byuu wrote: |
Should we merge the KI+KI beta bugs since they are basically the same game and suffer the exact same problem, or no? |
Yes.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 13, 2006 6:46 pm Post subject: |
|
Done. And yay for Wild Guns. Fun ass game. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 13, 2006 7:28 pm Post subject: |
|
Ok, DSP-1 works now.
From http://users.tpg.com.au/advlink/dsp/dsp1.html
Code: |
21H 4Mbit ~ 32Mbit 00H ~ 1FH 6000H ~ 6FFFH 7000H ~ 7FFFH |
This indicates that the DSP-1 maps to: [00-1f]:[6000-7fff]. It does not, however, suggest that it also maps to [80-9f]:[6000-7fff].
I had assumed since most games worked 95% correctly that I had the
mapping right. Ah well, I'm glad it's fixed now. You can remove DSP-1
from the list of unsupported chips now if you like.
EDIT: here's a pic. Ignore the version number.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Jul 13, 2006 9:53 pm Post subject: |
|
Good work man.  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 13, 2006 10:10 pm Post subject: |
|
Hooray! I was hoping that would get in before .017. Well done. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Thu Jul 13, 2006 11:07 pm Post subject: |
|
So all DSP-1 games work now? Some of them wouldn't work at all in WIP 27a. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Jul 13, 2006 11:13 pm Post subject: |
|
xamenus wrote: |
So all DSP-1 games work now? |
I would have to assume so.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 13, 2006 11:22 pm Post subject: |
|
FitzRoy wrote: |
Well done. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 13, 2006 11:41 pm Post subject: |
|
Oh my god, you got cow-mapping working?! What CAN'T you do?  |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Jul 13, 2006 11:46 pm Post subject: |
|
byuu wrote: |
FitzRoy wrote: |
Well done. |
|
Indeed.
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Fri Jul 14, 2006 5:20 pm Post subject: |
|
byuu wrote: |
Ok, DSP-1 works now.
From http://users.tpg.com.au/advlink/dsp/dsp1.html
Code: |
21H 4Mbit ~ 32Mbit 00H ~ 1FH 6000H ~ 6FFFH 7000H ~ 7FFFH |
This indicates that the DSP-1 maps to: [00-1f]:[6000-7fff]. It does not, however, suggest that it also maps to [80-9f]:[6000-7fff].
|
Technically, what I have is correct as address line A23 is not
connected in Mode 21H. The decoder would never see an address higher
than $7f:ffff.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 14, 2006 6:00 pm Post subject: |
|
HiROM
ignores A23? I thought LoROM ignored A23... hmm. Or maybe they both do,
and it's just ExHiROM and/or ExLoROM that use them.
Well, might make a nice note to mention your addresses assume A23 is ignored for idiots like me :/ |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jul 15, 2006 8:48 am Post subject: |
|
xamenus wrote: |
So all DSP-1 games work now? Some of them wouldn't work at all in WIP 27a. |
I've gone 5 minutes into all the dsp1 games and it does appear to be fully functional now.
Byuu: The only oddity I came across was Super Mario Kart (E). There's a
discrepency between bsnes and zsnes. While playing, zsnes enlargens the
view area and displays more info on the top and bottom. I don't know
which is right and which is wrong. What's wierder is that when you go
to the menu in zsnes, it reverts back to the height that yours is. It's
256x224 vs 256x239.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 15, 2006 10:22 am Post subject: |
|
That's
overscan. In PAL mode, it really should show the extra lines, ZSNES is
correct. My overscan emulation however is correct for NTSC, whereas
ZSNES gets that wrong. I would like to get PAL overscan working
correctly one day, but right now I don't want to deal with window
resizing issues such as those you experience when entering the GUI in
ZSNES.
By the way, does Corn Buster work correctly now? I hopefully fixed
those incorrectly sized games with some new cart loading code. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jul 15, 2006 10:47 am Post subject: |
|
Ah, well that explains that.
Corn Buster is working. Forgot about that one since you made me take it off the list. 
So the story on that and Killer Instinct BETA are that they're
under/overdumps? If that's the case, should they even be in NSRT? Do
they work on a copier? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 15, 2006 12:05 pm Post subject: |
|
Let's make that bug list a little smaller, shall we?

Code: |
//$[00-1f]:[8000-ffff] ROM
//$[70-7f]:[0000-ffff] RAM
//$[80-9f]:[8000-ffff] ROM (mirror)
//$[f0-ff]:[0000-ffff] RAM (mirror)
mapper(shvc_1a3b_12) {
map(0x00, 0x1f, 0x80, 0xff, MAP_ROM);
map(0x70, 0x7f, 0x00, 0xff, MAP_RAM);
map(0x80, 0x9f, 0x80, 0xff, MAP_ROM);
map(0xf0, 0xff, 0x00, 0xff, MAP_RAM);
} |
Friends, this is why you should all support Overload and submit your SNES cartridge PCBs to him.
I still need to create a database lookup (I forced memory mapping to
use that mapper), but that shouldn't take too long.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Jul 15, 2006 5:37 pm Post subject: |
|
Good work as always man. 
FitzRoy, how well does Pilotwings work? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Jul 15, 2006 9:59 pm Post subject: |
|

Linux, native AMD64, excellent sound output, constant 60FPS, 60-80% CPU usage depending on game and stuff.
_________________
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: Sat Jul 15, 2006 10:38 pm Post subject: |
|
King Of Chaos wrote: |
Good work as always man. 
FitzRoy, how well does Pilotwings work? |
I said I tested all games, yes? It works fine. You guys can test them
much farther when its unleashed, but everything I've seen is flawless.
Nach wrote: |

Linux, native AMD64, excellent sound output, constant 60FPS, 60-80% CPU usage depending on game and stuff. |
Whoa, Linux version. Very nice.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 15, 2006 10:57 pm Post subject: |
|
Ok,
I have a textual database for now, but I'm going to make a
text->binary convertor, as I imagine eventually parsing 4,000+ text
DB entries at startup would be a bit of a pain. I'll include source for
the convertor and everything, of course.
I look forward to supporting NSRT headers in the future, as an alternative to the DB lookup.
Quote: |
Linux, native AMD64, excellent sound output, constant 60FPS, 60-80% CPU usage depending on game and stuff. |
Very cool, indeed. Have to go to bed now, but I look forward to implementing these improvements shortly.
Did you port libco to AMD64 for that, or did you fall back on
bCPU/bAPU? I'd be very interested in an x64 port of libco.
As for sound output, does that now tie into src/ui/audio?
Lastly, what's your processor speed again? I usually get ~40-70% CPU usage on my 3500+ at 60fps.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Jul 15, 2006 11:04 pm Post subject: |
|
byuu wrote: |
Did you port libco to AMD64 for that, or did you fall back on
bCPU/bAPU? I'd be very interested in an x64 port of libco.
|
Bisqwit wrote libco_amd64.asm, I did everything else.
byuu wrote: |
As for sound output, does that now tie into src/ui/audio?
|
No, I'd like to discuss source changes with you later.
byuu wrote: |
Lastly, what's your processor speed again? I usually get ~40-70% CPU usage on my 3500+ at 60fps. |
3800.
Note I did not attempt to optimize my build at all. I can do that later and let you know if you like.
BTW errors and memory leaks are way down with last source you passed
me. However there is still a signifigant amount of problems. I have it
logged.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Jul 15, 2006 11:26 pm Post subject: |
|
Okay more testing done.
SSF2 missing sprites which I reported last week is still a problem.

And SFA2 flat out freezes, that was not a problem in .27.
I recompiled bsnes with optimizations.
Code: |
-O3 -fomit-frame-pointer -ffast-math -march=athlon64 -msse3 -ftree-vectorize -fprofile-use
|
bsnes now uses ~20%-50% CPU normally, but it creeps up a bit towards 60% on a really demanding game.
_________________
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: Sat Jul 15, 2006 11:53 pm Post subject: |
|
Super
Street Fighter II now added to the list. Happens in .016 as well. zsnes
had similar problems with that very gfx in the past, IIRC. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Jul 15, 2006 11:57 pm Post subject: |
|
FitzRoy wrote: |
Super
Street Fighter II now added to the list. Happens in .016 as well. zsnes
had similar problems with that very gfx in the past, IIRC. |
I don't recall ZSNES having a bug like that...
I do recall though ZSNES having garbage on that screen, which was a compile time misalignment problem.
And it's just not that graphic which I snapped, it's the entire game in bsnes is missing sprites.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 12:12 am Post subject: |
|
Tested more.
MK 3 freezes at start.
UMK3 has screwed up graphics, and then freezes shortly after.
Edit:
DKC3 is missing notes at the beginning.
Edit:
Actually not just the beginning, throughout the game...
Bleak doesn't laugh anymore.
_________________
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 Sun Jul 16, 2006 12:25 am; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 16, 2006 12:24 am Post subject: |
|
Nach wrote: |
FitzRoy wrote: |
Super
Street Fighter II now added to the list. Happens in .016 as well. zsnes
had similar problems with that very gfx in the past, IIRC. |
I don't recall ZSNES having a bug like that...
I do recall though ZSNES having garbage on that screen, which was a compile time misalignment problem.
And it's just not that graphic which I snapped, it's the entire game in bsnes is missing sprites.
|
K, maybe I don't RC. I thought it was just the arms and head that used
to mess up in zsnes. If there's even the slightest chance that they're
related, I thought it was worth mentioning.
And indeed, the character gfx are messed up ingame as well. Looks a lot
like the Killer Instinct effect, actually. Quite a few fighting games
now with problems, not forgetting Mortal Kombat which was fixed.
Byuu's not gonna like waking up to more bugs.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 12:28 am Post subject: |
|
PAL detection is screwed up, Korean Leauge won't start.
_________________
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 Jul 16, 2006 1:07 am Post subject: |
|
Both
South Korea games don't work. They're added. Mortal Kombat 3 and
Ultimate added. I couldn't get SFA2 to hang, and I don't know what to
look for in DKC3. I never played through it before. It seemed like
everything was okay. Is it possible that some of these bugs are
specific to the linux build? |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Jul 16, 2006 1:11 am Post subject: |
|
FitzRoy wrote: |
Byuu's not gonna like waking up to more bugs. |
Well, the way I see it, better finding them now, than later.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 16, 2006 1:15 am Post subject: |
|
Of course, but he's still not going to like it.  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 1:25 am Post subject: |
|
FitzRoy wrote: |
Both South Korea games don't work. They're added. |
And they're fixed in my tree.
So Korean Leauge and that Dragonball game should be off the list.
FitzRoy wrote: |
I couldn't get SFA2 to hang, and I don't know what to look for in DKC3.
I never played through it before. It seemed like everything was okay.
Is it possible that some of these bugs are specific to the linux build? |
I kind of doubt it, I can make a Windows build and report back.
As for DKC3, sound notes are missing, I don't know how much you'd
realize it if you don't know the game. I didn't find any graphical bugs
in DKC3 though (yet).
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 1:55 am Post subject: |
|
Yes SFA2 is screwing up for me in Windows, Linux x86 and Linux AMD64.
But only the U version. E is fine. (or perhaps it's level related and I
only tested some levels and that was different between U and E).
If it's not screwing up for you, then I'd wager a guess we're not
running off the same source. I'm using source byuu passed me Friday
afternoon, not sure what you're testing with.
As for DKC3, it seems to lack sound when I use profiling in AMD64, but
not otherwise, odd to say the least. I'm thinking perhaps the profiler
doesn't like libco AMD64 so much...
Edit:
I'd have to double check, but I think my profile problem was using a
profile from older source compiling a newer one, so some code which
shouldn't have been was optimized out.
Edit:
Korean Leauge snapshot:

_________________
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 Jul 16, 2006 4:13 am Post subject: |
|
Must
be a brand new bug then, because I get nothing with the (U) version on
.016.30. Played Ken and beat it after about 12 stages... must've been
on easy mode. As for Korean League, I get a cart error message and then
a button press will go to that title screen. But if I try to start a
game, it goes right back to the error message. Dragon Ball just gets a
black and red error message. This is all on .016.30 of course... so I
took it off the list. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 16, 2006 10:06 am Post subject: |
|
Korean
games don't work because I didn't even know what one was to test it. I
never added Korean region as an NTSC region, so it runs in PAL mode. I
don't even know what region code is for Korea.
If
SFA2 is freezing because of sCPU, then I'm going to stop enabling it.
I've made bCPU and sCPU identical and can't find the R-Type bug
anywhere.
Apparantly, all fighters on the SNES use some special OAM code that
doesn't render at all on bsnes. I'll have to go dig over SNES9x sources
and their OAM code again since it affects 25+ games.
At any rate, I'm sick and tired of fixing bugs mostly alone, so I'm
going to keep working on my database and PCB memory mappers. I'll just
not release v0.017, then. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 16, 2006 11:11 am Post subject: |
|
Yeah, SK is apparently NTSC. I didn't run the fps counter on zsnes 
Hey, sCPU fixed a lot of bugs, too. I'd hardly want bcpu just because
r-type iii is screwing up. SFA2 isn't screwing up for me on scpu,
either. I don't know why Nach is getting problems. None of the fighter
game problems are reversions. They've always been there, we just didn't
know it.
So unless Wild Guns, Jurassic Park 2, Power Rangers, and Secret of Mana
now work in bcpu, I still think scpu is going in the right direction.
Nobody expects you to figure out all these bugs before .017. Some of us
just can't help you in any other way other than finding them.
As for getting help, I have no advice because I'm not a coder. I don't
know the skill levels of all the people you correspond with. Everyone
who's learned enough seems to be heading their own project, and I
couldn't understand the snes9x revival project enough to even comment
on it. Is it time to use the DMV27 signal?  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 12:19 pm Post subject: |
|
byuu wrote: |
Korean
games don't work because I didn't even know what one was to test it. I
never added Korean region as an NTSC region, so it runs in PAL mode. I
don't even know what region code is for Korea.
|
Not good to miss out on data everyone has known for years 
FitzRoy wrote: |
They've always been there, we just didn't know it. |
You guys really need to test more games... 
FitzRoy wrote: |
I couldn't understand the snes9x revival project enough to even comment on it. |
What revival?
We've been working on it steadily since the prior release.
Just because we don't have a WIP release every other month doesn't mean we're dead.
_________________
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: Sun Jul 16, 2006 12:55 pm Post subject: |
|
byuu wrote: |
I never added Korean region as an NTSC region, so it runs in PAL mode. |
Wouldn't it be better to default to NTSC mode?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 1:25 pm Post subject: |
|
creaothceann wrote: |
byuu wrote: |
I never added Korean region as an NTSC region, so it runs in PAL mode. |
Wouldn't it be better to default to NTSC mode?
|
I added code to my tree to handle it, it fixes Korean games and some pesky betas.
_________________
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 Jul 16, 2006 1:31 pm Post subject: |
|
Nach wrote: |
You guys really need to test more games...  |
I try to test about 15 a day. But everything seems to work and I get discouraged 
Really, though, there aren't that many out there. 3 of your 5 were
legit, and even then, MK3 and UMK3 are pretty much the same bug. I
personally held off testing .016 knowing that it would be pointless
with the new core coming. Others may be thinking the same way. With all
the changes since .016, there's a good chance anything one would find
is already fixed. And wip27a was only up for a day.
Nach wrote: |
What revival?
We've been working on it steadily since the prior release.
Just because we don't have a WIP release every other month doesn't mean we're dead. |
Well portions of it were so bad and outdated that they were
unsalvagable, yes? Is it really worth the effort with only the hope
that someone comes along and rewrites it all? Even if they do, then
what?
Last edited by FitzRoy on Sun Jul 16, 2006 1:39 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 1:39 pm Post subject: |
|
FitzRoy wrote: |
Really, though, there aren't that many out there. 2 of your 4 were legit,
|
I found more than 4, and they are legit. byuu has the SFA2 bug too.
FitzRoy wrote: |
Well portions of it were so bad and outdated that they were
unsalvagable, yes? Is it really worth the effort with only the hope
that someone comes along and rewrites it all? |
anomie rewrote mose of Snes9x prior to the v1.43 release. We didn't
release the new code in v1.43 since we didn't fully test it in time,
and we didn't feel like breaking Windows just yet.
We don't wait for people to come and rewrite the core, we do that our selves.
_________________
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 Jul 16, 2006 1:41 pm Post subject: |
|
Damn you refuted me before I could edit it to 3 of 5! Well, that SFA2 bug must be on a newer build than 16.30 then. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 1:47 pm Post subject: |
|
FitzRoy wrote: |
Damn you refuted me before I could edit it to 3 of 5! Well, that SFA2 bug must be on a newer build than 16.30 then. |
Actually it's not.
It's a run time bug because bsnes uses unitilized variables.
Edit:
Found bsnes does not calculate CRC32 correctly.
_________________
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 Jul 16, 2006 1:56 pm Post subject: |
|
Well, you're already over my head. I'll leave you both to it then  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 2:03 pm Post subject: |
|
FitzRoy wrote: |
Well, you're already over my head. I'll leave you both to it then  |
To put it simply. You can run bsnes today, and it would seem fine, yet
you can run it tomorrow and run into various errors, even if it's the
exact same build and everything.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 16, 2006 4:06 pm Post subject: |
|



There. All or most of these third-rate fighters are now fixed.
Another problem thanks to the wonders of using hacker maps. I'm going
to do everything in my power to wipe the terms HiROM and LoROM off of
the internet.
Quote: |
To
put it simply. You can run bsnes today, and it would seem fine, yet you
can run it tomorrow and run into various errors, even if it's the exact
same build and everything. |
Yes, yes. We get it. Everything has to be perfectly initialized and
freed or my emulator is shit. I really wish I could catch them all, but
given I have at least 4,000 variables in my emulator, I make mistakes
sometimes. I'll work with your Valgrind logs and eliminate as many
uninitialized variables as I can.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Jul 16, 2006 4:47 pm Post subject: |
|
byuu wrote: |
Another
problem thanks to the wonders of using hacker maps. I'm going to do
everything in my power to wipe the terms HiROM and LoROM off of the
internet. |
Hopefully you're being sarcastic, but this is very unlikely since these
terms have been used for a long time. You are always welcomed to try
and change the norm though...
_________________
FF4 research never ends for me.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Jul 16, 2006 5:21 pm Post subject: |
|
byuu wrote: |
Another
problem thanks to the wonders of using hacker maps. I'm going to do
everything in my power to wipe the terms HiROM and LoROM off of the
internet. |
What would you suggest then?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 5:23 pm Post subject: |
|
byuu wrote: |
Yes, yes. We get it. Everything has to be perfectly initialized and freed or my emulator is shit.
|
It's not just your emulator, it's all applications.
byuu wrote: |
I really wish I could catch them all, but given I have at least 4,000
variables in my emulator, I make mistakes sometimes.
|
It is inexcusable to not use debugging tools to catch this stuff.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 5:25 pm Post subject: |
|
creaothceann wrote: |
byuu wrote: |
Another
problem thanks to the wonders of using hacker maps. I'm going to do
everything in my power to wipe the terms HiROM and LoROM off of the
internet. |
What would you suggest then?
|
I would suggest waiting for me to add hardware info to NSRT headers, so
when you get a ROM, it's like getting it in a cart, with all the
included hardware, instead of just one chip and scratching your head
about the rest.
_________________
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: Sun Jul 16, 2006 5:29 pm Post subject: |
|
... and then refuse* to load any ROMs that have no NSRT header? 
*unless the emulator is started with a secret cmdline switch
_________________
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: Sun Jul 16, 2006 5:44 pm Post subject: |
|
Exactly, the header idea seems a little less practical than the database. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 6:02 pm Post subject: |
|
FitzRoy wrote: |
Exactly, the header idea seems a little less practical than the database. |
How is a database practical? The SNES didn't use a database.
Should we need a new emulator release for every ROM dumped when anyone
can edit the header with a hex editor or a tool desiged for that
purpose for a moment?
_________________
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: Sun Jul 16, 2006 6:24 pm Post subject: |
|
byuu wrote: |
[img]http://byuu.cinnamonpirate.com/images/bs_232.png[/img[img]http://byuu.cinnamonpirate.com/images/bs_233.png[/img
[img]http://byuu.cinnamonpirate.com/images/bs_234.png[/img
[img]http://byuu.cinnamonpirate.com/images/bs_235.png[/img
[img]http://byuu.cinnamonpirate.com/images/bs_236.png[/img
[img]http://byuu.cinnamonpirate.com/images/bs_237.png[/img
There. All or most of these third-rate fighters are now fixed. |
Nice work. I think the vast majority of Snes fighters were pretty crappy. Just wasn't the console strong suit.
So those problems were actually caused by incorrect ROM format detection?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 16, 2006 6:27 pm Post subject: |
|
There won't be any new carts officially released, and yes we will have to update the database for any new dumps that do appear.
I'd like to make the database public and possible to share between all
emulators. The format is open and as simple as possible.
Dmog, no it was caused by me "fixing" Dezaemon and Tokimeki Memorial,
which map SRAM to [f0-ff]:[8000-ffff]. This then broke all of the
fighters because they don't. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 16, 2006 7:13 pm Post subject: |
|
Nach wrote: |
FitzRoy wrote: |
Exactly, the header idea seems a little less practical than the database. |
How is a database practical? The SNES didn't use a database.
Should we need a new emulator release for every ROM dumped when anyone
can edit the header with a hex editor or a tool desiged for that
purpose for a moment?
|
True, but it doesn't seem like nsrt is in a popularity position to pull
that off. Now everyone who downloads roms is going to stream into the
forums and report xxx doesn't work because goodsnes is the standard of
the site they obtained their roms from. Most emulator users are
clueless. It's simply asking too much of them to use your program when
a database can do it automatically for them.
And can someone please explain to me why emulators need a complete db,
and not just the carts that do strange shit? Would it be too hackish or
something?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 7:22 pm Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
FitzRoy wrote: |
Exactly, the header idea seems a little less practical than the database. |
How is a database practical? The SNES didn't use a database.
Should we need a new emulator release for every ROM dumped when anyone
can edit the header with a hex editor or a tool desiged for that
purpose for a moment?
|
True, but it doesn't seem like nsrt is in a popularity position to pull
that off. Now everyone who downloads roms is going to stream into the
forums and report xxx doesn't work because goodsnes is the standard of
the site they obtained their roms from. Most emulator users are
clueless. It's simply asking too much of them to use your program when
a database can do it automatically for them.
|
Most of the clueless won't use bsnes anyway.
And considering bsnes doesn't have any real forum associated with it,
they really don't have anywhere to complain to.
FitzRoy wrote: |
And can someone please explain to me why emulators need a complete db,
and not just the carts that do strange shit? Would it be too hackish or
something? |
I disagree with a DB at all. But using a full DB means one system for everything that's proper coding.
_________________
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 Jul 16, 2006 7:31 pm Post subject: |
|
Well,
I thought other emus besides bsnes were planning to do this. And I only
asked about the necessity of it because it seems like a LOT of friggin
work to get that cart info. Most games seem to be working just fine
without one, so if there's a way to get around that, by all means...
get around it. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 16, 2006 8:19 pm Post subject: |
|
FitzRoy wrote: |
Well,
I thought other emus besides bsnes were planning to do this. And I only
asked about the necessity of it because it seems like a LOT of friggin
work to get that cart info. Most games seem to be working just fine
without one, so if there's a way to get around that, by all means...
get around it. |
Well, I plan to add the data to NSRT, then have ZSNES and Snes9x parse the header and follow it.
If it doesn't exist, just fall back on the old code which works 95% of the time.
I do not plan on adding a database to other emulators.
_________________
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 Jul 16, 2006 11:18 pm Post subject: |
|
Updated
the buglist after confirming the fighters work and ran through the
rest. There doesn't appear to be any further fixes, but at least it's
looking rather short again 
PS: I did not check Megaman X2 |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jul 17, 2006 7:09 am Post subject: |
|
Nach wrote: |
I disagree with a DB at all. |
If you distribute it with an emulator, people'd just have to download a
new version and wouldn't have to modify their ROM files.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jul 17, 2006 11:19 am Post subject: |
|
creaothceann wrote: |
Nach wrote: |
I disagree with a DB at all. |
If you distribute it with an emulator, people'd just have to download a
new version and wouldn't have to modify their ROM files.
|
And how often do we have official emulator releases?
Setting up the header can be done immediatly.
And regardless, having an emulator database driven is just wrong, any
time a game gives you trouble you can start using special settings for
that game, it's evil.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 17, 2006 12:06 pm Post subject: |
|
Well, my database contains four fields.
Name (region) (revision) (verified good dump?), PCB ID, ROM size, RAM size.
I use name to display in the emulator, looks way better than internal
ROM names. I use PCB to select the appropriate memory mapper. ROM size
and RAM size for underdumped/overdumped games. The last two I could
probably even remove.
I pull the rest from the SNES cart header. Region, vectors, etc.
The use of the DB is optional, just delete cart.db and it'll run fine
without it and use the old hacker memory maps.
Anyway, it's mainly only needed for problem games like Ys 3 and such.
I'll probably add it for games like MMX because they have evil copy
protection checks galore. Once your NSRT header spec is finished, I
will default to using that. If no NSRT header, then I will fall back on
the database. If that fails as well, then as a last resort I will use
hacker mapping (HiROM and LoROM), and display a popup each time with a
settings box to let the user override the sticky points of these maps.
Quote: |
any time a game gives you trouble you can start using special settings for that game, it's evil. |
I hope you know I would never do that. Though I can't speak for others.
Even still, it'd be better to do that than to turn on hacks based on
the internal ROM name, wouldn't it?
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jul 17, 2006 12:15 pm Post subject: |
|
byuu wrote: |
Quote: |
any time a game gives you trouble you can start using special settings for that game, it's evil. |
I hope you know I would never do that. Though I can't speak for others.
Even still, it'd be better to do that than to turn on hacks based on
the internal ROM name, wouldn't it?
|
Why? First of all, hacks are hacks, if you now have a system for a per
game thing it's just going to enourage extension.
Second of all if you did happen to hack and based in on the internal
name, it would be one hack for all revisions and probably regions since
they share internal name, with a per DB setup you're going to make that
hack per ROM edition for a game.
I would also like to point out your whole DB would need to add enteries for every translation and what not.
A header would not have this problem.
_________________
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: Mon Jul 17, 2006 12:55 pm Post subject: |
|
Nach wrote: |
creaothceann wrote: |
Nach wrote: |
I disagree with a DB at all. |
If you distribute it with an emulator, people'd just have to download a
new version and wouldn't have to modify their ROM files.
|
And how often do we have official emulator releases?
|
I didn't say official. WIP versions could do the same.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jul 17, 2006 1:03 pm Post subject: |
|
creaothceann wrote: |
Nach wrote: |
creaothceann wrote: |
Nach wrote: |
I disagree with a DB at all. |
If you distribute it with an emulator, people'd just have to download a
new version and wouldn't have to modify their ROM files.
|
And how often do we have official emulator releases?
|
I didn't say official. WIP versions could do the same.
|
So the emulator should be considered broken because we don't do WIPs?
And we should start catalogging every translation?
_________________
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: Mon Jul 17, 2006 1:13 pm Post subject: |
|
Nach wrote: |
So the emulator should be considered broken because we don't do WIPs?
And we should start catalogging every translation? |
1. ZSNES does WIPs, and every other emulator could also have them, even
if only the DB is changed. Even better if the same DB can be used by
all participating emulators.
2. Nope. The selection could be done before an IPS/NINJA/... is
applied. Hardpatched ROMs would of course not be supported.
Anyway, it's your decision guys. I'm just pointing out some things.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 17, 2006 1:15 pm Post subject: |
|
Quote: |
Why? First of all, hacks are hacks, if you now have a system for a per game thing it's just going to enourage extension. |
My license disallows derivative works and I won't be adding any hacks,
ever. So for me at least, you really don't have to worry about that.
I don't consider the DB a hack, I consider it adding back information that was lost with the ROM dump.
Quote: |
Second
of all if you did happen to hack and based in on the internal name, it
would be one hack for all revisions and probably regions since they
share internal name, with a per DB setup you're going to make that hack
per ROM edition for a game. |
Exactly my point, and that's a good thing. You shouldn't apply a hack
to all revisions of a game unless you know how each revision works.
Once you do, you can just as easily add two or three entries for each
revision. But I'm not even talking about using my DB for hacks.
Quote: |
I would also like to point out your whole DB would need to add enteries for every translation and what not. |
I'm not planning on doing that. Both because translations aren't
official carts and shouldn't be in an official database, and to respect
the translator and prevent ROM hoarders from seeking pre-patched ROMs
for the purpose of having a "complete database".
Quote: |
A header would not have this problem. |
And by all means, as soon as such a header exists, I will use it. Until
then, Ys 3 now works*, whereas it didn't before.
* Still need to add J/E releases when I have time.
Speaking of which, before I forget... we need to work on UPS::SNES
format some more. It would be a good thing to somehow include an
optional header so that translators can take advantage of soft-patching
and still enjoy the benefits of NSRT headers.
I say we include both, since neither contain copyrighted information,
and it's possible the source ROM could have a different copier header
yet still be the same ROM. If one of the ROMs patched (or both) lack a
header, then store the header as all 0x00s. This way, it would only add
1k extra per SNES patch. We can use one of those bits for flags to
specify whether or not a header exists.
Quote: |
1.
ZSNES does WIPs, and every other emulator could also have them, even if
only the DB is changed. Even better if the same DB can be used by all
participating emulators. |
That's what I was going for, an open source, open tool database to be
used by all emulators. My format is pointlessly simple.
Quote: |
2. Nope. The selection could be done before an IPS/NINJA/... is applied. Hardpatched ROMs would of course not be supported. |
Oh wow, I love
this idea. It's perfect. It makes total sense. If they want to hard
patch for a copier, it won't matter that emulators don't detect proper
memory mapping. If they want to use it in an emulator properly, they
soft-patch. The ROM hacker can then detect the correct PCB mapping as a
way to verify the ROM was soft-patched and alert the user that the ROM
was hard patched, and thusly might be a) missing readme files and b)
mirrored incorrectly, causing possible unknown bugs.
I say we support it both ways, pre-patch and post-patch CRC DB checks, with pre-patch CRC taking precedence.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jul 17, 2006 1:28 pm Post subject: |
|
creaothceann wrote: |
Nach wrote: |
So the emulator should be considered broken because we don't do WIPs?
And we should start catalogging every translation? |
1. ZSNES does WIPs, and every other emulator could also have them, even
if only the DB is changed. Even better if the same DB can be used by
all participating emulators.
|
ZSNES does WIPs, sometimes. Snes9x doesn't. And most people don't use WIPs.
creaothceann wrote: |
2. Nope. The selection could be done before an IPS/NINJA/... is
applied. Hardpatched ROMs would of course not be supported.
|
So break hard patching...
And if a patch changes the mapper requirements (and several do, Front
Mission patch IIRC, among others), this breaks soft patching too.
byuu wrote: |
Quote: |
Why? First of all, hacks are hacks, if you now have a system for a per game thing it's just going to enourage extension. |
My license disallows derivative works and I won't be adding any hacks,
ever. So for me at least, you really don't have to worry about that.
|
Well, you're encouring it in other emulators.
byuu wrote: |
I don't consider the DB a hack, I consider it adding back information that was lost with the ROM dump.
|
How isn't it a hack? You're putting the missing PCB info into the
emulator instead of the ROM dump where it belongs.
byuu wrote: |
Quote: |
Second
of all if you did happen to hack and based in on the internal name, it
would be one hack for all revisions and probably regions since they
share internal name, with a per DB setup you're going to make that hack
per ROM edition for a game. |
Exactly my point, and that's a good thing. You shouldn't apply a hack
to all revisions of a game unless you know how each revision works.
Once you do, you can just as easily add two or three entries for each
revision. But I'm not even talking about using my DB for hacks.
|
Check all the times we had hacks added in the past and people
complained because we made it specific to a particular version. You
should apply to all revisions unless you know it's only needed for one.
It's rarely the case a particular hack is only for one revision. (and
I'm talking from experience here in seeing many many hacks in SNES
emulators and watched how many of them were elliminated)
byuu wrote: |
Quote: |
I would also like to point out your whole DB would need to add enteries for every translation and what not. |
I'm not planning on doing that. Both because translations aren't
official carts and shouldn't be in an official database, and to respect
the translator and prevent ROM hoarders from seeking pre-patched ROMs
for the purpose of having a "complete database".
|
So basically you're going to make the patch scene even more confusing with this setup.
byuu wrote: |
Quote: |
A header would not have this problem. |
And by all means, as soon as such a header exists, I will use it. Until
then, Ys 3 now works*, whereas it didn't before.
* Still need to add J/E releases when I have time.
|
Add J/E? Oh so you needed a hack for all 3 versions now, and not just one of them, proving my point above.
And I hardly see as what you currently have implemented as any proof as
to which method is superior one way or the other.
byuu wrote: |
Speaking of which, before I forget... we need to work on UPS::SNES
format some more. It would be a good thing to somehow include an
optional header so that translators can take advantage of soft-patching
and still enjoy the benefits of NSRT headers.
I say we include both, since neither contain copyrighted information,
and it's possible the source ROM could have a different copier header
yet still be the same ROM. If one of the ROMs patched (or both) lack a
header, then store the header as all 0x00s. This way, it would only add
1k extra per SNES patch. We can use one of those bits for flags to
specify whether or not a header exists. |
I'd like to discuss this online with you.
_________________
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: Mon Jul 17, 2006 3:18 pm Post subject: |
|
Nach wrote: |
ZSNES does WIPs, sometimes. Snes9x doesn't. And most people don't use WIPs. |
Like I said, emulators could start releasing WIPs as soon as the database changes.
EDIT: If people come complaining we can just tell them to download the current WIP.
Nach wrote: |
So break hard patching...
And if a patch changes the mapper requirements (and several do, Front
Mission patch IIRC, among others), this breaks soft patching too. |
IMO hardpatching doesn't have to be supported.
For the other issue there could be a second database that handles these
special cases. (Yes I'm aware that's not a perfect solution...)
Nach wrote: |
How isn't it a hack? You're putting the missing PCB info into the emulator instead of the ROM dump where it belongs. |
That's a very good point. I'd also prefer it if all the required info
was in a *.sfc file. But fact is that since ROM dumping started, people
used only the [copier header + ROM] files. The copier header doesn't
contain the required info (or does it?), hence it's useless for
emulators. Therefore I always thought of *.smc, *.sfc etc. purely as
files containing the ROM, and nothing else.
These simple file formats can't store all info that is available about
a game. Some emulators (eg. MAME) might want to display cover art, the
manual etc. This info has to be stored elsewhere. To include this in
the "cartridge dump file" you'd need a chunk-based format, which
probably won't happen soon. So if you store all that info in other
files, then why not the PCB info as well?
PS: There are enough tools already that can't handle
headerless/headered ROMs. *eyeroll* IMO it's better to get rid of it at
last.
EDIT @ byuu:
Weren't Lo/HiROM the official Nintendo terms?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Tue Jul 18, 2006 6:44 am; edited 2 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 17, 2006 3:36 pm Post subject: |
|
From
what I know, HiROM and LoROM were generic representations by Nintendo,
yes. The emulation scene took them and applied them to every game. But
the reality is that there are >20 memory mappers that map images
differently. And HiROM+LoROM combined cannot cover all games, just a
large majority of them. We need more detail than just these two.
Now then, if we include all the info in an NSRT header, what happens if
that information turns out to be incorrect? I think a database with a
version number would be a lot easier for people to deal with upgrading
than downloading the latest NSRT and running it on all of their ROMS,
getting those seeded out to all users again, etc.
By using a database with a problem, we just fix it. We require the DB
version number be included with the bug report, and if it's older, we
tell them to upgrade. We could even add a Firefox-style "check for DB
updates" option to our emulators that goes online and retrieves updates
on the fly.
We make a page that allows user submissions and bug reports, and it turns into something like freedb for audio CDs. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Mon Jul 17, 2006 5:32 pm Post subject: |
|
A
wild idea would be to get bsnes to use this database to actually write
the info to the ROM's NSRT header, so that you can get the benefits in
other SNES emulators that won't use the database. Sort of like how you
can make Nestopia write its database info to a NES ROM's header if you
wish. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Mon Jul 17, 2006 5:42 pm Post subject: |
|
Xamenus
has an interesting, although unintended, point - someone might decide
at some point to make their own NSRT-header writing tool, and you could
have ROMs with NSRT headers, but with incorrect information.
It represents a decision that any emu author would have to make -
accept the header info as gospel, or do validation to some degree or
another. Byuu already has to do validation for non-NSRT headed ROMs,
why not just do it for every ROM? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jul 17, 2006 5:58 pm Post subject: |
|
To clueless people:
NSRT updates older headers automatically.
Other tools already write NSRT headers.
NSRT headers contain version numbers.
I'd appreciate if people actually look into things before spewing, thanks.
_________________
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: Mon Jul 17, 2006 6:07 pm Post subject: |
|
I'm
not buying the header argument. A real snes wouldn't read the memory
map from a header, that's something copiers use. So having a db with
that info apart from the rom isn't really much different what you're
doing.
And as for emulator updates being a
problem- that's just ridiculous. How often do new games get dumped
these days? A few every year, with a 99.9% chance they'd work perfect
on the fallback map.
And the end-user confusion issue still stands. It's simply WAY harder
with the state of distribution to do what you're proposing every time
someone downloads a rom.
edit: removed "hackish" because it's not
Last edited by FitzRoy on Tue Jul 18, 2006 5:59 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 18, 2006 2:46 am Post subject: |
|
EDIT: no reason for this to be here, either.
Last edited by byuu on Tue Jul 18, 2006 1:27 pm; edited 2 times in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Jul 18, 2006 6:45 am Post subject: |
|
I think this should be kept here...
byuu wrote: |
Quote: |
A real Snes wouldn't read this information from an internal database either. |
Right, either.
The real SNES doesn't know what a ROM is. It polls connector pins and
the memory mapper on the chip returns the correct data. We can't dump
the memory mapper, so we record the PCB that does. No matter how we do
this, it's technically not how the real SNES works.
Here are my reasons for being pro DB :
- An emu can have an option to automatically check weekly for updates
and automatically download new DBs, eliminating the need for the user
to even care about this. The DBs would generally be much smaller than a
new version of NSRT.
- This works in the background. The user doesn't need to rescan all of
their ROMs with an external tool, doesn't need to modify their ROM
images, ROM sites don't need to update their files, we don't have to
worry if an NSRT header doesn't exist, and we don't have to worry if a
user has an older version of NSRT that has an incorrect header. A
database update would push down in a week.
- All emulators can easily use it with a very, very small library I
wrote for the DB (~1.1kb). The NSRT library may end up being just as
small, but definitely not smaller. Size really isn't very important,
just that it's easy to use the DB.
- Emulators that use hacks are going to use hacks. I don't think having
a DB to identify the ROMs is going to make much of a difference. They'd
just match the $ffc0 cart name instead without the DB. We should as a
community discourage use of emulators that rely on hacks, and eliminate
them from those that do instead of worrying about newcomers that might
be tempted to cheat.
- The per-entry space is unlimited, whereas a header is always limited
to 512 bytes. I know 512 bytes will always be enough, but just saying...
As for translations, I say we handle them like this :
By default, we don't add any translations to the database. If someone
completes a translation, they can request we add it to the DB.
Otherwise, we fall back on HiROM/LoROM for them. We will advise anyone
submitting their translation for inclusion of the potential problems
(ROM sites indexing them for the sake of having "complete database!"
clauses). We could also add a special flag to the DB to prohibit hard
patching, which will be toggled at the translators' request, and up to
emulators to enforce.
|
byuu wrote: |
Please
don't put money on my emulator. If someone wants to fix it for free,
great. I'd really appreciate it. If not, I'll do it myself. Eventually.
There's some difference between the way src/cpu/bcpu and src/cpu/scpu
works that's causing the bug, and I can't find it. I've tried modifying
bcpu to be a clone of scpu sans cothreading and it still fails. Shame
too, I actually really like that game now that I finally tried it. I
wasn't even aware it existed, I thought Super R-type was the only
R-type on the SNES.
As for the timing crystal differences, not in there yet. It's on my
list of 20 million things to eventually do. I don't really care if it's
"going too far with accuracy" or not. I've long since accepted my
ideals are far from the norm of the emulation community. Emulating the
stock clock speeds is ideal if not for the sake of eliminating runtime
randomness, but if anything it would be useful if someone makes their
own homebrew and wants to take that one extra step to ensure it will
work on all SNES hardware units. |
byuu wrote: |
Furthermore,
apparently neither side is listening nor willing to compromise on the
database issue. So let's agree to disagree. bsnes and Super Sleuth will
use a database. ZSNES and SNES9x will not. Hopefully all will support
NSRT PCB headers once they exist.
But if you
would please allow me to take the last inflammatory cheap shot:
pagefault and Nach oppose the use of a database because it "encourages
adding game-specific hacks to correct emulation bugs". And yet, the
emulators that do use databases are bsnes, Super Sleuth and Nestopia; written by me, Overload and Marty. The emulators that don't support databases are ZSNES, SNES9x and NESticle. You tell me what's wrong with that. |
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Fri Jul 21, 2006 1:01 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 19, 2006 12:07 am Post subject: |
|
Thanks for getting the thread back on track guys, and I'm glad bsnes will share a db with super sleuth. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 19, 2006 12:34 am Post subject: |
|
We
don't currently share the same database, just the idea of using one.
Although with Overload's permission, I could add support for bsnes to
read his database if it exists in the bsnes base directory. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 19, 2006 12:46 am Post subject: |
|
Oh, well that would be cool if they did (and future emus), but you guys will probably want different formats.
byuu wrote: |
As
for the timing crystal differences, not in there yet. It's on my list
of 20 million things to eventually do. I don't really care if it's
"going too far with accuracy" or not. I've long since accepted my
ideals are far from the norm of the emulation community. Emulating the
stock clock speeds is ideal if not for the sake of eliminating runtime
randomness, but if anything it would be useful if someone makes their
own homebrew and wants to take that one extra step to ensure it will
work on all SNES hardware units. |
Just to clarify something. As I understood it months ago when this even
came up, I got the impression that this quirk of randomness could not
be emulated, only simulated. As such, you said that you were going to
add a compile time option or something for people who were interested,
not a full blown implimentation. I put this in the same category as
having an snes emulator running progressive on a pc monitor despite the
original system's incapability of such. There are some things that you
just naturally overcome in the conversion from console to pc. I didn't
think it was too much accuracy, I just thought it was impossible do in
the same manner on a pc, thus unnecessary. Hopefully that explains some
things.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 19, 2006 8:03 pm Post subject: |
|
Hm,
I can fix Death Brade and both bugs in Power Drive (and possibly fix
others, and possibly break others) by initializing WRAM to 0x55/0xff on
power-on. Right now, I initialize it to 0x00. The question is, should
I? There is no officially defined value that WRAM is initialized to on
power on, and it's technically a bug in the game, reading uninitialized
memory and relying on those values.
Also, The
bug in Hungry Dinosaurs occurs in Super Sleuth and ZSNES. Are you sure
this doesn't happen on the real SNES? It would be good to test it,
because as it stands I have no idea how to fix that. I can barely even
see it.
Also, say hello to my little friend, infinite mirror recursion.
Code: |
uint mirror_realloc(char *s, uint size) {
for(int i = 31; i >=0; i--) {
if(size & (1 << i)) {
if(!(size & ~(1 << i))) { return 1 << i; }
realloc(s, 2 << i);
return 2 << i;
}
}
return 0;
}
uint mirror(char *s, uint size) {
uint r = mirror_realloc(s, size);
while(size < r) {
uint i = 0;
for(; i < 32; i++) { if(size & (1 << i))break; }
uint masklo = 1 << i++;
for(; i < 32; i++) { if(size & (1 << i))break; }
uint maskhi = 1 << i;
if(i > 31)break; //no mirroring necessary
while(masklo < maskhi) {
uint start = size - masklo;
memcpy(s + size, s + start, masklo);
size += masklo;
masklo <<= 1;
}
}
return r;
} |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 19, 2006 10:28 pm Post subject: |
|
The
Death Brade and Power Drive bugs look like a similar situation to
Krusty's Super Fun House, where the game code is doing something that
goes against what makes sense, but nevertheless avoids issue on the
real console. Those have got to be some of the hardest for you to
figure out 
I don't think we're seeing the same thing on the Hungry Dinosaurs bug.
After you start a game, a weird transition effect happens. On bsnes, it
almost seems as though a whole vertical part of the right side is
erroneously ending up on the left part of the screen, which does not
happen in zsnes or super sleuth. Here are some caps pointing it out.
imgs removed, issue resolved
Last edited by FitzRoy on Sat Jul 22, 2006 3:21 am; edited 1 time in total |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Wed Jul 19, 2006 11:14 pm Post subject: |
|
byuu wrote: |
Also, say hello to my little friend, infinite mirror recursion.
Code: |
uint mirror_realloc(char *s, uint size) {
for(int i = 31; i >=0; i--) {
if(size & (1 << i)) {
if(!(size & ~(1 << i))) { return 1 << i; }
realloc(s, 2 << i);
return 2 << i;
}
}
return 0;
}
uint mirror(char *s, uint size) {
uint r = mirror_realloc(s, size);
while(size < r) {
uint i = 0;
for(; i < 32; i++) { if(size & (1 << i))break; }
uint masklo = 1 << i++;
for(; i < 32; i++) { if(size & (1 << i))break; }
uint maskhi = 1 << i;
if(i > 31)break; //no mirroring necessary
while(masklo < maskhi) {
uint start = size - masklo;
memcpy(s + size, s + start, masklo);
size += masklo;
masklo <<= 1;
}
}
return r;
} |
|
Hmm. I feel like I'm gonna sound like an ass, so sorry in advance. This
post is not intended to be offensive. I want to criticize your
algorithms constructively so that you get a better, more logical
approach to functions like that.
Let me explain: your realloc logic looks overcomplicated: a loop with
several exit points depending on apparently complex checks.
Proposed replacement:
Code: |
uint mirror_realloc(char *s, uint size, uint mask = 0x1000000)
{
while (!(mask&size)) { mask >>= 1; }
if (size-mask)
{
mask += mask;
realloc(s, mask);
}
return (mask);
} |
Why store an index, then use it as a shift-mask in a check, then do
additional checks, when you can flatten the logic and put it simply ?
Next, your rom mirroring code. It's not recursive. This means that you have to handle all the cases in a go.
Those who're used to recursive algos can skip the next paragraph + code blocks rant.
Recursive algos dive in themselves until they meet their special case,
then process the data along the way back out of the recursion ladder.
That makes it easy to support all sorts of wicked inputs, as long as
you find the way to reduce them all to the special case. On the other
hand, non-recursive algos have to deal with ALL the cases in a single
go. This is simple for some, much less for others. Simple example:
factorial x:
Recursive:
Code: |
uint fact(uint x)
{
if (x) { return (x*fact(x-1)); } // default process
else { return (1); } // special case
} |
Straight:
Code: |
uint fact(uint x)
{
uint ret = 1;
while (x) { ret *= x--; }
return (ret);
} |
Minimal difference. Processing 'any case' seems to be as easy if not
easier than splitting into 'special' and 'default' cases. I didn't try
to see which was faster, but I'm gonna guess the latter, since it's
gonna skip all the call overheads.
** resume reading if you're not byuu.
So, you imbricate 2 loops, the inner one stores the first 2 memory
blocks of size = power-of-2 (called 'blocks' from now on)
bottom-to-top, then mirrors the last block, updating size on the fly.
the outer loop repeats the inner one as long as the rom is made of
several blocks.
** byuu can skip up to here :)
It's a perfectly valid 'any case' implementation, no issues about that, it'll work correctly with anything. Good.
Now... of course mirroring is trivial, since it's only done once per
rom load... but if you need a complex algorithm like that in a
speed-critical segment, you want to be able to write fast code.
I found several places where you can improve speed at no cost:
- you run a bottom-to top loop starting over from 0 every outer loop.
You can make it instantly aware of the next block by simply setting i
to maskhi*2 before looping.
- the " if(i > 31)break; //no mirroring necessary " line is
superfluous. If no mirroring is needed, the outer loop won't run at
all. No need for extra checks within the inner loop.
- again, you use i++ in your loops, then test against 1<<i for
each iteration, it wastes time. Make the loops use directly the mask
and update it with <<= 1
- you can save a relatively negligeable amount of time per (masklo < maskhi) loop if you do:
Code: |
while(masklo != maskhi) {
uint end = s + size;
memcpy(end, end - masklo, masklo);
size += masklo;
masklo <<= 1;
} |
Sorry about that last one, I'm just being silly, but it *would* save some time, honest. ^_^
Anyway, that would make a better 'any-case' implementation in my opinion. I hope it also does in yours.
Now if you want the latest zsnes recursive algo... I refined Nach's code a bit, to reach:
Code: |
unsigned int mirror_rom(unsigned char *start, unsigned int length)
{
unsigned int mask = 0x1000000;
while (!(length & mask)) { mask >>= 1; } // not optimized, roofle
length -= mask;
if (length)
{
start += mask;
length = mirror_rom(start, length);
while (length != mask)
{
memcpy(start+length, start, length);
length += length;
}
}
return(length+mask);
} |
The realloc happens outside (uses the code I pasted earlier).
And for kicks, the sickhead version
Code: |
NEWSYM mirror_rom
push ebx
mov ebx,[esp+12] ; length: 12 = 4(second param)+4(call)+4(push ebx)
push esi
mov esi,[esp+12] ; start: 12 = 0(first param)+4(call)+4(push ebx)+4(push esi)
push ecx
push edx ; backup regs so only eax is trashed
push edi ; (eax == return value)
mov eax,1000000h ; mask
xor cl,cl ; depth
.downloop
test ebx,eax
jnz .ready
shr eax,1
jmp .downloop
.ready
inc cl
sub ebx,eax ; next length
jz .done
add esi,eax ; next start
push esi
push eax
jmp .downloop ; depth++
.uploop
pop eax
pop esi
mov edi,esi
add edi,ebx
.rep
cmp ebx,eax
je .done
mov edx,ebx
.copy
mov ch,[esi]
mov [edi],ch
inc esi
inc edi
dec edx
jnz .copy
sub esi,ebx
shl ebx,1
jmp .rep
.done
add ebx,eax
mov eax,ebx ; return value
dec cl
jnz .uploop ; depth--
pop edi
pop edx
pop ecx
pop esi
pop ebx
ret |
Oh, almost forgot: The code snippets from zsnes are under GPL2, so
don't forget to give credit if the awesome gives you inspiration. ;)
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
Last edited by grinvader on Wed Jul 19, 2006 11:29 pm; edited 3 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 19, 2006 11:15 pm Post subject: |
|
Ah, that's a generic mosaic problem. I've implemented mosaic according to spec, though :/
It affects a lot of games that use heavy mosaic. I thought you meant
that color change that happens after you beat a level. I'll see what
can be done, then.
So should I commit the "fix" for DB and PD? Kind of sucky since the
games are technically "broken" from a programming standpoint by
requiring certain values in undefined variables. Sort of like a certain
emulator sometimes does, right Nach? But, that's two less bugs if I add
it.
Quote: |
Oh,
almost forgot: The code snippets from zsnes are under GPL2, so don't
forget to give credit if the awesome gives you inspiration. ;) |
And that's why I'll continue to use my own :)
Richard Stallman and his horde of hippie lawyers can suck it.
Thanks for the optimization ideas, but I wasn't going for speed since
this function's only called once. You do have some points about some
things, and technically the while(r < size) isn't needed because of the if(i > 31)break, but I added it because it looks nicer than an "infinite loop" ala for(;;).
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 19, 2006 11:39 pm Post subject: |
|
Maybe
I'm just not getting this, but if DB and PD only work in your emulator
by accessing undefined variables, how did they work on a real system
unless the real thing allowed this as well? |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Jul 20, 2006 12:09 am Post subject: |
|
The 'real thing', being an electronical device, has init values set by noise.
It just happened that these games work with FF, or 55 (or maybe AA).
Basically, those games are not programmed right, and only work due to
the 'imperfect' behaviour of the original hardware.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Thu Jul 20, 2006 3:08 am Post subject: |
|
byuu wrote: |
Ah, that's a generic mosaic problem. I've implemented mosaic according to spec, though :/
It affects a lot of games that use heavy mosaic. I thought you meant
that color change that happens after you beat a level. I'll see what
can be done, then. |
In bppu_render_bg.cpp, it looks like hoffset is affecting the starting
position of the mosaic pixel blocks. This is not correct; the first
block should always start on pixel 0 of the scanline, not xpos = 0 of
the bg. From regs.txt:
Quote: |
Note
that mosaic is applied after scrolling, but before any clip windows,
color windows, or math. So the XxX block can be partially clipped, and
it can be mathed as normal with a non-mosaiced BG. But scrolling can't
make it partially one color and partially another. |
Also, I don't think the mosaic_countdown code in bppu.cpp will work with this test:
Quote: |
if
even scanlines are completely red and odd scanlines are completely
blue, setting the xxxx=1 mid-frame will make the rest of the screen
either completely red or completely blue depending on whether you set
xxxx on an even or an odd scanline. |
I think writing to $2106 has to reset mosaic_countdown in order for this to work.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jul 20, 2006 7:08 am Post subject: |
|
byuu wrote: |
So
should I commit the "fix" for DB and PD? Kind of sucky since the games
are technically "broken" from a programming standpoint by requiring
certain values in undefined variables. Sort of like a certain emulator
sometimes does, right Nach? But, that's two less bugs if I add it. |
Well, correct emulation would be to fill the WRAM (and maybe VRAM?
nah...) with a pattern that comes close to the real one. Unless the
cartridge affects these values somehow, they should always be the same
- or at least some regions.
You could test the WRAM a couple of times and note which regions change
and which don't. I think blargg or somebody else already did that...
_________________
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 Jul 20, 2006 7:59 am Post subject: |
|
And
in case you weren't aware of this (you probably are), Derby Stallion 96
is verified on Overload's cartlist. You previously suspected this
game's failure had to do with the generic memory mapper you were using.
Now that you have a db, you might be able to get this one off the list,
too  |
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Thu Jul 20, 2006 11:23 am Post subject: |
|
FitzRoy wrote: |
And
in case you weren't aware of this (you probably are), Derby Stallion 96
is verified on Overload's cartlist. You previously suspected this
game's failure had to do with the generic memory mapper you were using.
Now that you have a db, you might be able to get this one off the list,
too  |
Derby Stallion '96 uses a Broadcast Satellaview Cartridge. There is no
way of detecting BS Carts using the ROM header. The mapping is not a
standard 24mbit mode 20H mapping. If you break the ROM into 8mbit
chunks it goes $00-$1F (A), $20-$3F (B), $80-$9F (A), $A0-$BF (C). The
BS cartridge also allows a flash cartridge to be mapped in the $C0-$EF
region.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 20, 2006 3:23 pm Post subject: |
|
Quote: |
In
bppu_render_bg.cpp, it looks like hoffset is affecting the starting
position of the mosaic pixel blocks. This is not correct; the first
block should always start on pixel 0 of the scanline, not xpos = 0 of
the bg. |
Correct, thank you for pointing that out. I haven't found a good way of
doing this correctly just yet, and it's causing up to one tile to spill
over from the right to the left of the screen as a result.
Quote: |
Also, I don't think the mosaic_countdown code in bppu.cpp will work with this test: |
IIRC, I implemented just enough of TRAC's notes on mosaic to support
Sim Earth. I don't currently do anything on writes to MOSAIC, mostly
because SNES9x uses a count-up counter that doesn't directly work the
way mine does. I need to fix this, yes.
Quote: |
Well,
correct emulation would be to fill the WRAM (and maybe VRAM? nah...)
with a pattern that comes close to the real one. Unless the cartridge
affects these values somehow, they should always be the same - or at
least some regions. |
Ok, as most of the CPU regs are power-on to 0xff, I'll use that for
now. If that causes bugs in those two lame games, I will turn it back
to 0x55 as a last resort. So I guess consider those two games "fixed",
now. Even though they are fundamentally broken to begin with.
Quote: |
Derby Stallion '96 uses a Broadcast Satellaview Cartridge. |
Indeed, I actually used to have this game. I smashed it apart to take a
look at the connector, heh (really need to buy a bit already). It has
the little cart connector on the top for the BS-X flash cart. Very
interesting that it has a BSC- PCB prefix. I don't recall seeing that
in the list before, and certainly not on the PDF file. I will add
support for this mapper as soon as possible, thanks Overload!
EDIT: not having any luck... the game still blackscreens upon load.
Verified it was loading as it should. I'm treating the game as a LoROM
in that all banks are mapped to $8000-$ffff and not $0000-$ffff...
Format is map(bank_lo, bank_hi, page_lo, page_hi, type, start = 0);
Code: |
mapper(bsc_1a5m_01) {
map(0x00, 0x1f, 0x80, 0xff, MAP_ROM, 0x000000); //A 8mbits
map(0x20, 0x3f, 0x80, 0xff, MAP_ROM, 0x100000); //B 8mbits
map(0x70, 0x7f, 0x00, 0x7f, MAP_RAM); //32kb RAM (mirrored)
map(0x80, 0x9f, 0x80, 0xff, MAP_ROM, 0x000000); //A 8mbits
map(0xa0, 0xbf, 0x80, 0xff, MAP_ROM, 0x200000); //C 8mbits
} |
Any ideas? :/
Also, even though I'm sure we don't have any BS-X flash cart dumps for
this game, I'd like to go ahead and add support for them anyway. I
assume the BS-X flash cart works just like SRAM? eg I should map a
24mbit file to $[c0-ef]:[0000-ffff], say <romname>.bsx, and then
allow the cart to freely read/write to this memory area? Or does it
require special control registers to access this memory in write mode
similar to the BS-X base unit?
EDIT 2:
$00-$1F (A), $20-$3F (B), $80-$9F (A), $A0-$BF (C)
should be
$00-$1F (A), $20-$3F (B), $80-$9F (C), $A0-$BF (B)

Hooray, database!
Ok, that's three down. Death Brade, Power Drive and Derby Stallion '96.
Now, onto Hungry Dinosaurs...
Quote: |
"Note
that mosaic is applied after scrolling, but before any clip windows,
color windows, or math. So the XxX block can be partially clipped, and
it can be mathed as normal with a non-mosaiced BG. But scrolling can't
make it partially one color and partially another." |
Code: |
for(x = 0; x < line.width; x++) {
hoffset = x + hscroll;
voffset = y + vscroll;
...
mosaic_x = mtable[hoffset & mask_x];
mosaic_y = voffset & mask_y;
...
} |
And for reference :
Code: |
for(int32 l = 0; l < 16; l++) {
mosaic_table[l] = (uint16*)malloc(4096 * 2);
for(int32 i = 0; i < 4096; i++) {
mosaic_table[l][i] = (i / (l + 1)) * (l + 1);
}
} |
To me, it looks like that code does apply after scrolling but before clip windows, color windows or math.
I'm not sure how to correct this problem :/
Quote: |
(12:32:22) TRAC: ahh.
(12:32:39) TRAC: well, as I understand it, mosaic only affects the currently addressed dot, not scrolling |
In that case...
Code: |
for(x = 0; x < line.width; x++) {
mosaic_x = mtable[x];
mosaic_y = y;
hoffset = mosaic_x + hscroll;
voffset = mosaic_y + vscroll;
...
mosaic_x = hoffset & mask_x;
mosaic_y = voffset & mask_y;
...
} |
Obviously, I will adjust the code at home to use hoffset and voffset
instead of copying the values back to mosaic_x and mosaic_y. But for
now...

Can we consider this bug fixed as well?
Next issue: most emulators do this. Super Sleuth, ZSNES, and bsnes v0.016.32+.

This is the title screen for Energy Breaker. It flickers for two frames
with just the top half of the display visible. In bsnes v0.016 and
SNES9x v1.5, this does not happen. We need to verify the correct
behavior on hardware. It's possible this is the correct behavior, though.
Note: this appears to be another difference between bCPU and sCPU, as
the flickering does not occur with bCPU in the latest WIP. So that's
two differences now :/
I will try my best to track down these differences this weekend. I see
no reason to list this as a bug until we verify the correct behavior on
hardware.
Next, here's a comparison of the mosaic effect when going between "screens" in Energy Breaker.

I imagine ZSNES has the bug here, but it would be good to go ahead and
verify this while checking for the title screen flicker issue. It will
be necessary to use a TV capture card to see the edges, most likely.
That, or mess with the flyback transformer or somesuch to force your TV
to show the left-most edge of the display.
Last edited by byuu on Thu Jul 20, 2006 5:50 pm; edited 2 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jul 20, 2006 5:26 pm Post subject: |
|
byuu wrote: |
Quote: |
Well,
correct emulation would be to fill the WRAM (and maybe VRAM? nah...)
with a pattern that comes close to the real one. Unless the cartridge
affects these values somehow, they should always be the same - or at
least some regions. |
Ok, as most of the CPU regs are power-on to 0xff, I'll use that for
now. If that causes bugs in those two lame games, I will turn it back
to 0x55 as a last resort. So I guess consider those two games "fixed",
now. Even though they are fundamentally broken to begin with.
|
Are you filling the entire area with FFh or 55h? If the game starts every time then I'd say that the referenced memory locations contain always the expected value.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 20, 2006 5:57 pm Post subject: |
|
I'm
filling all 128k of WRAM with 0xff for now. It works for Death Brade as
well as Power Drive. I know this will break a couple demoscene games
that rely on WRAM starting at 0x00. They do this because copiers often
clear this memory to 0x00 for them before starting their demos. Qwertie
in particular was bad about relying on this behavior in his demos.
Also, as far as I know, some BS-X games (Zelda remake) rely on WRAM
being 0x00 on power-on. I will worry about this when I start adding
support for the BS-X hardware. I will likely initialize WRAM
differently for these games. The games themselves aren't technically
supposed to load directly anyway, as far as I know. I'd bet the BS-X
BIOS sets WRAM before starting the games. |
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Thu Jul 20, 2006 7:24 pm Post subject: |
|
byuu wrote: |
Indeed,
I actually used to have this game. I smashed it apart to take a look at
the connector, heh (really need to buy a bit already). It has the
little cart connector on the top for the BS-X flash cart. Very
interesting that it has a BSC- PCB prefix. I don't recall seeing that
in the list before, and certainly not on the PDF file. I will add
support for this mapper as soon as possible, thanks Overload! |
Yeah, I own the cart too. Sound Novel Tsukuru (BSC-1A7M) is another that maps this way. I will add it to the pdf.
byuu wrote: |
Also,
even though I'm sure we don't have any BS-X flash cart dumps for this
game, I'd like to go ahead and add support for them anyway. I assume
the BS-X flash cart works just like SRAM? eg I should map a 24mbit file
to $[c0-ef]:[0000-ffff], say <romname>.bsx, and then allow the
cart to freely read/write to this memory area? Or does it require
special control registers to access this memory in write mode similar
to the BS-X base unit? |
The flash cart has a special sequence of reads/writes to enable writing
to flash ram. The flash cart is identical to the cart used with the
BS-X cartridge.
byuu wrote: |
$00-$1F (A), $20-$3F (B), $80-$9F (C), $A0-$BF (B) |
You are correct, my mistake.
byuu wrote: |
Next, here's a comparison of the mosaic effect when going between "screens" in Energy Breaker.

I imagine ZSNES has the bug here, but it would be good to go ahead and
verify this while checking for the title screen flicker issue. It will
be necessary to use a TV capture card to see the edges, most likely.
That, or mess with the flyback transformer or somesuch to force your TV
to show the left-most edge of the display. |
I also think ZSNES is incorrect in this case (window effects).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 20, 2006 9:00 pm Post subject: |
|
Ok
then, I will try and find the difference between bCPU and sCPU causing
the EB title screen to flicker, and test the behavior on my copier this
weekend and let you know the results. Looks like it's going to be a
tough one to track down. My first guess is an IRQ not firing in sCPU.
Overload wrote: |
Yeah, I own the cart too. Sound Novel Tsukuru (BSC-1A7M) is another that maps this way. I will add it to the pdf. |
Hmm, fun.
Sound Novel Tsukuru (Japan) [!] ZSNJ BSC-1A7M-10
Derby Stallion '96 (Japan) [!] ZDBJ BSC-1A5M-01
Are these two identical, mapping wise? I can get Sound Novel working
using BSC-1A5M-01, but I prefer not to add PCB mappers without
verifying they are correct first :/
Also, if you wouldn't mind linking to your latest PCB PDF, I'd appreciate it. That thing is extremely useful.
Quote: |
The
flash cart has a special sequence of reads/writes to enable writing to
flash ram. The flash cart is identical to the cart used with the BS-X
cartridge. |
I don't suppose you have more detailed information on this? If it works
the same for the BS-X BIOS as it does for Super Derby '96, I might as
well add support for that as well.
If not, I can probably RE the info by logging reads+writes to banks
$c0-$ef. The Game Genie was particularly easy to decode like this.
Implementing a cart passthru in software, however, turned out to be a
good deal more difficult (hence why I haven't added support for it, nor
currently plan to).
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Fri Jul 21, 2006 4:42 pm Post subject: |
|
byuu wrote: |
Ok
then, I will try and find the difference between bCPU and sCPU causing
the EB title screen to flicker, and test the behavior on my copier this
weekend and let you know the results. Looks like it's going to be a
tough one to track down. My first guess is an IRQ not firing in sCPU. |
It's always been in Super Sleuth. I had a look at it last night and it
seems to be a windowing problem but I am not sure what is causing it.
The HDMA data looks fine.
byuu wrote: |
Are
these two identical, mapping wise? I can get Sound Novel working using
BSC-1A5M-01, but I prefer not to add PCB mappers without verifying they
are correct first :/ |
The only difference is the amout of sram on the PCB.
byuu wrote: |
Also, if you wouldn't mind linking to your latest PCB PDF, I'd appreciate it. That thing is extremely useful. |
I normally keep a copy at http://users.tpg.com.au/advlink/temp/pcb.pdf
byuu wrote: |
I
don't suppose you have more detailed information on this? If it works
the same for the BS-X BIOS as it does for Super Derby '96, I might as
well add support for that as well. If not, I can probably RE the
info by logging reads+writes to banks $c0-$ef. The Game Genie was
particularly easy to decode like this. Implementing a cart passthru in
software, however, turned out to be a good deal more difficult (hence
why I haven't added support for it, nor currently plan to). |
I don't have any more detailed information. I would like to add support
for the flash cart too. I might take a look at it next week.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 21, 2006 4:54 pm Post subject: |
|
Quote: |
It's
always been in Super Sleuth. I had a look at it last night and it seems
to be a windowing problem but I am not sure what is causing it. The
HDMA data looks fine. |
I don't believe it's a windowing problem. Since replacing my CPU cores
whilst leaving my PPU core alone corrects the problem, it's isolated to
the CPU.
I will do my best to find the fix for this, but you might have an
easier time tracking it down than me since I lack a debugger.
Quote: |
The only difference is the amout of sram on the PCB. |
Perfect, thank you.
Awesome!
Quote: |
I
don't have any more detailed information. I would like to add support
for the flash cart too. I might take a look at it next week. |
Then I'll do the same and let you know what I find, thanks.
I imagine we won't be so lucky and the flashcarts will require certain
data to already be on them in order to work. But you never know until
you try, right?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 21, 2006 5:36 pm Post subject: |
|
Well
that sucks. When I remove HDMA bus sync timing from bCPU, EB title
starts flickering. I know for a fact SNES9x does not implement bus sync
timing (it can't), so we probably need a better compromise between the
two.
EDIT: dug into this a little more, the
title screen never calls HDMA init, only HDMA run. I tried adding a
simple "wait a cycle or two before running HDMA" delay, but that didn't
work too well. Nor did I think it would. Also tried adjusting when HDMA
triggers, moving it forward and backward, again no avail. I tried
logging the differences between bCPU and sCPU and all of the writes are
the same, they just tend to happen ~30-40 clocks later in bCPU. So,
move sCPU forward 40 clocks for the hell of it ... no go. Still broken.
Very annoying.
EDIT2: problem solved. Timing issue.
bcpu.cpp :
Code: |
case HDMASTATE_DMASYNC3:
if(channel[z].hdma_line_counter) {
add_cycles(8); //magic line that allows EB title to work
status.hdma_cycle_count += 8;
}
if(++z < 8)break;
status.hdma_state = HDMASTATE_RUN;
break; |
scpu.cpp :
Code: |
void sCPU::hdma_run() {
if(hdma_active_channels() == 0)return;
add_clocks(18);
static uint8 hdma_xferlen[8] = { 1, 2, 2, 4, 4, 4, 2, 4 };
for(int i = 0; i < 8; i++) {
if(hdma_active(i) == false)continue;
add_clocks(8); //new line here fixes the bug in Energy Breaker
if(channel[i].hdma_do_transfer) {
int xferlen = hdma_xferlen[channel[i].xfermode];
for(int index = 0; index < xferlen; index++) {
if(bool(config::cpu.hdma_enable) == true) {
dma_transfer(channel[i].direction, dma_bbus(i, index),
!channel[i].hdma_indirect ? hdma_addr(i) : hdma_iaddr(i));
} else {
add_clocks(8);
co_return();
cycle_edge();
}
}
}
channel[i].hdma_line_counter--;
channel[i].hdma_do_transfer = bool(channel[i].hdma_line_counter & 0x80);
if((channel[i].hdma_line_counter & 0x7f) == 0) {
hdma_update(i);
}
}
status.dma_irq_delay = 2;
} |
By the way Overload, that last line could be used in Super Sleuth to
fix Wild Guns if you wanted. Change it to a cycle count of ~20-24 or so
if you want to be more accurate, mine is just an opcode counter for now
:/
It needs to go into dma_run() and hdma_init() as well.
I knew this already, too. It was an oversight on my part porting the old code to the new version.
From anomie's SNES timing document :
Quote: |
The actual HDMA transfer begins at dot 278 of the scanline (or just after, the
current CPU cycle is completed before pausing), for every visible scanline
(0-224 or 0-239, depending on $2133 bit 3). For each scanline during which HDMA
is active (i.e. at least one channel has not yet terminated for the frame),
there are ~18 master cycles overhead. Each active channel incurs another 8
master cycles overhead for every scanline, whether or not a transfer actually
occurs. If a new indirect address is required, 16 master cycles are taken to
load it. Then 8 cycles per byte transferred are used. |
Specifically, "Each active channel incurs another 8 master cycles
overhead for every scanline, whether or not a transfer actually occurs".
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 21, 2006 9:05 pm Post subject: |
|
Good work! Discovered and fixed before I could even add it to the list Any chance this fixes r-type as well?
edit: new bug discovery regarding your recent wip, which may have to do
with your WRAM changes: in Radical Psycho Machine Racing, the car gfx
are now corrupt. Some look like tiles from the title screen  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 21, 2006 10:37 pm Post subject: |
|
That's
because Interact hired mentally retarded chimpanzees to peck out the
code for RPM Racing. Games that bad should not be allowed to exist in a
just and fair world. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 21, 2006 10:43 pm Post subject: |
|
It's
a truly shitty game, and the port looks like it fixed some things.
Wasn't RPM Racing followed up by Rock N Roll Racing by the same team
(silicon & synapse a.ka. Blizzard). If so, you may have to eat your
words 
On another note, Super Sleuth handles DB and PD fine (does it do anything to WRAM?), as well as RPM Racing. |
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Fri Jul 21, 2006 10:53 pm Post subject: |
|
FitzRoy wrote: |
Wasn't
RPM Racing followed up by Rock N Roll Racing by the same team (silicon
& synapse a.ka. Blizzard). If so, you may have to eat your words  |
Yep
Blizzard is not known by their great coding anyway. WC3 scripting
language (JASS) has a lot of bugs, and Diablo 2 has many performance
issues.
_________________
_-|-_
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 21, 2006 11:01 pm Post subject: |
|
Strange story, really. "If at first you utterly suck, try again... and end up with the best racing game on the system." |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 21, 2006 11:06 pm Post subject: |
|
Quote: |
If so, you may have to eat your words |
I don't see what having the worst racing game on the SNES (a true honor
given some of the shit Nintendo let through quality control) has to do
with what the company did later on.
I didn't change anything that would break RPM racing, but whatever. I
even backported the one change that's different into my work WIP and
the game still runs fine. Sigh.
EDIT: alright, seems to happen every other time you play the game. I'm
not worried about it right now since the game's a piece of shit and
already has other bugs anyway.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 21, 2006 11:34 pm Post subject: |
|
Semi-joking
with that, but to the matter at hand: yeah, I just realized that the
bug is somewhat spontaneous. Sometimes the sprites will all start
garbled and stay that way, and sometimes only 1 will start garbled and
it will go back to normal when it moves...
I'll
just add this info to the current symptoms, no big deal. I just hope
it's the only new bug added from this. It's good to take notice when
things pop up that weren't there before, lest it get buried in wips and
becomes harder to track down.
byuu wrote: |
I
don't see what having the worst racing game on the SNES (a true honor
given some of the shit Nintendo let through quality control) has to do
with what the company did later on. |
Alright, I have time to elaborate on this now. If it was indeed the
same team, then it shows a level of improvement that you have to
admire. It goes beyond a retarded chimp. If I remember correctly on
this bit of history as well, RPM Racing was one of the first games for
the system. As such, despite the fact that it was a noob effort, it
probably got rushed to release also, to take advantage of sales from
lack of competition. Might explain why the game not only sucks, but is
full of bugs (and the J version free of them).
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sat Jul 22, 2006 6:45 pm Post subject: |
|
byuu wrote: |
It
will be necessary to use a TV capture card to see the edges, most
likely. That, or mess with the flyback transformer or somesuch to force
your TV to show the left-most edge of the display. |
Byuu,
What brand and model of television set are you connecting your SNES to?
Most TV's manufactured within this decade have a secret service menu
that brings up controls similar to a computer monitor (trapezoid,
h-size, v-size, rotation, whatever).
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Sat Jul 22, 2006 10:12 pm Post subject: |
|
RPM
Racing from Silicon & Synapse/Interplay/Blizzard has bugs that
happen after a random number of plays.Do you see a pattern here?
Rock'N'Roll Racing has a similar issue,but with the sound.It mutes after a random number of plays.
The game is also by S&S...hmmm....
Speaking of Silicon & Synapse,you forgot an even better game they
made for the SNES than Rock'N'Roll Racing - anyone remember the
legendary "Lost Vikings"?
This was an awesome game for the SNES...and surprisingly,it comes with no bugs at all 
Sadly,the second part of the LV series was not that great as the first one.
I had loads of fun with this game back in the days. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 23, 2006 2:07 am Post subject: |
|
Fixed
a bug no one noticed. Super Conflict was showing the logo before
zooming in because I was clipping m7[abcd] with sclip<15>(n) and
not sclip<16>(n). Might fix some other unnoticed mode7 glitches,
too.
I wrote a litmus test to run through all 64k
possible values for m7[abcd]+center[xy] just to be safe. Identical to
the old code now and Super Conflict doesn't glitch out at that part
anymore. But the missing 's' is still there.
whicker> I have a Magnavox TV, I don't know what model it is. Looks
to be 21" or so, silver. I'd be interested in a test menu. My TV's
alignment is terrible. It would make testing some PPU edge cases
easier, too. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 23, 2006 2:31 am Post subject: |
|
byuu wrote: |
Fixed
a bug no one noticed. Super Conflict was showing the logo before
zooming in because I was clipping m7[abcd] with sclip<15>(n) and
not sclip<16>(n). Might fix some other unnoticed mode7 glitches,
too.
|
Cool.
Kick, can you be more specific about that RNRR bug? Is the music
stopping altogether, races and all? I'll give it a try tonight.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 23, 2006 2:38 am Post subject: |
|
And is that a bug in bsnes or on the real game? Or are you not sure? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jul 23, 2006 3:27 am Post subject: |
|
Well,
now I'm really not sure what he means. I played the whole first planet
and noticed nothing out of the ordinary. The only game bug I ever came
across on the real cart (and I played this game for 200+ hours), was
that sometimes at the end of the game, when they start showing all the
fake clips from your season, sometimes it would hang at the black
screen between transitions. It was very rare though, and completely
random. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 23, 2006 8:21 pm Post subject: |
|
Ok, horrible things happen when HDMA occurs on the same channel as an active DMA transfer.
The behavior is currently too complex for me to decode using only a
copier and probing known registers. Suffice to say it is not any kind
of standard behavior: the real hardware goes "nuts" when this happens.
Now, I can fix Bugs Bunny by blocking HDMA transfers when a DMA
transfer is active. This is not correct, but neither is my old behavior
of allowing them and making them act normal.
I don't think I'll be able to figure this one out alone. So then, what
should I do? Leave the code alone, or "fix" Bugs Bunny, albeit
improperly? Even if the game looks correct, it will still not behave
like hardware either way.
This only applies to DMA+HDMA on the same channel, if they're on
different channels they act properly, so my other tests and Dracula X
still work fine either way. Bugs Bunny is the only known game to
exhibit this bug. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Jul 23, 2006 8:59 pm Post subject: |
|
byuu wrote: |
Ok, horrible things happen when HDMA occurs on the same channel as an active DMA transfer.
The behavior is currently too complex for me to decode using only a
copier and probing known registers. Suffice to say it is not any kind
of standard behavior: the real hardware goes "nuts" when this happens.
Now, I can fix Bugs Bunny by blocking HDMA transfers when a DMA
transfer is active. This is not correct, but neither is my old behavior
of allowing them and making them act normal.
I don't think I'll be able to figure this one out alone. So then, what
should I do? Leave the code alone, or "fix" Bugs Bunny, albeit
improperly? |
Since both method are technically incorrect,I guess it doesn't really
matter one way or another. I would probably leave it alone since the
new method could give the false impression that this issue was
accurately "fixed".
I've wondered before about the limitations of RE through software-only
(in this case: running your own custom programs with the help of a
copier) Do you think this is one such case where the aforementionned
method cannot give you new information? Or could it still be
theorically possible but just incredibly complex?
Anyway,nice job on the recent reduction of the bug list. Your (and Overload)'s database is showing great promises.
Quote: |
Even if the game looks correct, it will still not behave like hardware either way.
This only applies to DMA+HDMA on the same channel, if they're on
different channels they act properly, so my other tests and Dracula X
still work fine either way. Bugs Bunny is the only known game to
exhibit this bug. |
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 23, 2006 10:58 pm Post subject: |
|
Quote: |
Anyway,nice job on the recent reduction of the bug list. Your (and Overload)'s database is showing great promises. |
The work is all Overload's, so please direct all credit towards him.
Anyway... back to DMA+HDMA... I accidentally left force blank off, hence the wild results.

If DMA + HDMA is enabled on the same channel, DMA runs, and then HDMA
triggers on that same channel during the transfer, the HDMA transfer
will kill the remaining part of the DMA transfer. This means $43x5 != 0
after the DMA transfer, and $43x2 is similarly $43x5 bytes shorter than
what it should be (or greater for backwards transfer).
Both Bugs Bunny: Rabbit Rampage (U) and World Class Rugby (E) rely on this behavior to work correctly.
I have tested this in all emulators, none implement this behavior. So
if they run either of these two games correctly, it is due to another
bug in emulation that just happens to make it right. eg they block HDMA
VRAM writes during force blank, or block HDMA when DMA is transferring
on the same channel.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jul 24, 2006 2:38 am Post subject: |
|
So are you saying you've fixed them now, properly? I can take them off the list? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 24, 2006 2:26 pm Post subject: |
|
Yes, they are fixed properly now and can be removed, thanks to help from TRAC and zones.
Still battling R-Type III and RPM racing. Those, Chou Aniki and EWJ2e
are probably the only ones I'll be able to fix. Uniracers and Super
Conflict probably require some currently unknown PPU dot rendering
information to fix properly, and I really don't even know where to
begin with Mega Man X2. It's such a weird bug. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 24, 2006 9:34 pm Post subject: |
|
Overload, a little logging on the BS-X flash cart :
Code: |
Derby Stallion '96 :
* write c08000 = 38
* write c08000 = d0
* write c08000 = 71
* read c08004
* write c08000 = 72
* write c08000 = 75
* read c1ff00
* read c1ff02
* read c1ff04
* read c1ff06
* read c1ff08
* read c1ff0a
* read c1ff0c
* read c1ff0e
* read c1ff10
* read c1ff12
Sound Novel Tsukuru :
* write c08000 = 38
* write c08000 = d0
* write c08000 = 71
* read c08004
* write c08000 = 72
* write c08000 = 75
* read c1ff00
* read c1ff02
* read c1ff04
* read c1ff06
* read c1ff08
* read c1ff0a
* read c1ff0c
* read c1ff0e
* read c1ff10
* read c1ff12 |
$c080xx appear to be control registers, I think the first six enable
the cart, and $c1ffxx is information about the cart, seemingly $14
bytes, possibly more. Games then start accessing $dfxxxx regions. I'd
take a wild guess the 8mbits is mapped to $d0-df and mirrored to
$e0-$ef.
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Jul 25, 2006 12:03 am Post subject: Re: bsnes appreciation thread, sound woes |
|
I'm
sure this isn't important, but when frameskip 1 is enable while in game
in R-Type 3 (U) it'll pause the game before it locks up. Ah I was using
016.32 by the way and no one gave it to me. You just happen to have it
using the same link as the beta you posted before. =o |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 12:52 am Post subject: |
|
Yeah,
I noticed it made the pause sound before crashing. The R-Type bug is
seriously kicking my ass, and holding up a new release as well. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Jul 25, 2006 2:51 am Post subject: |
|
That's
a shame about the release. Atleast R-Type III is a game worth fixing.
It seems to be one of the better shooters for snes. I'm surprised I
never brought the game when it was released. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 3:42 am Post subject: |
|
Well this is embarassing ...
Code: |
uint8 sCPU::mmio_r4212() {
...
uint16 vs = !overscan() ? 225 : 240;
//auto joypad polling
if(status.hclock >= vs && status.hclock <= (vs + 2))r |= 0x01;
...
return r;
} |
It would be good to test vertical scanline positions against vcounter
instead of the horizontal clock counter. Makes it a lot easier to stop
games from getting stuck in infinite loops waiting for that bit to be
set.

Also added DMA per-channel initialization delay.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 5:10 am Post subject: |
|
http://byuu.cinnamonpirate.com/temp/aniki.txt
That's the problem with Chou Aniki. The game is turning NMI off and
then immediately turning it on. Since the read pin is low and the line
pin is high, this causes an NMI to trigger. Because the Aniki
programmers are writing in 16-bit mode to $4200 (screwing up PIO in the
process), bsnes triggers the NMI at the end of the sta $4200. The Aniki
programmers chose to save the updated $0201 variable with the bit that
says "yes, keep NMIs enabled" after the write to $4200. And then during
the NMI, it reads $0201 and writes it into $4200 again, killing all
future NMIs forever.
I've tried a few solutions, and at least two got Chou Aniki working,
but broke my test_nmi.smc file. Therefore, these won't be added. I must
be missing some obscure NMI quirk, but it eludes me at the moment.
For the record, ZSNES and Super Sleuth work by not triggering an NMI at
all, as if the $01 write to $4200 clears the pending NMI. That's not
the case on real hardware according to my test programs. I suspect the
reality is that if NMI is enabled immediately before the opcode's last
cycle, it's not lowering the NMI pin, delaying the NMI for one more
opcode. That would also allow Chou Aniki to work.
I shall have to run a lot more NMI tests to fix this one :( |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 25, 2006 8:40 am Post subject: |
|
Good good good. And then there were 3. |
|
chipzoller Rookie
Joined: 27 Jan 2005
Posts: 16
|
Posted: Tue Jul 25, 2006 2:51 pm Post subject: |
|
I'm
not sure if this is actually a bug or merely the consequence of high
cpu usage while running the emulator. I've noticed in Tales of
Phantasia that some sound studder is present when walking on the world
map, almost like the sound is degrading due to frame drops or something.
Also noticed that Far East of Eden Zero won't run. Even without the
graphics packs you should still get an error message on screen. These
may have been reported, but I couldn't search this thread for them. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 3:06 pm Post subject: |
|
Next
version will be faster. The emulator must run at full speed to prevent
choppy sound, as I lack the skill to dynamically resample audio on the
fly.
FEoEZ lacks all support, including for its
memory mapper. I wouldn't expect anything from the game until I get
hardware to start running my own tests and start emulating the chip.
An update to aniki :
Code: |
* w4200: 00 at 008011 read=1,line=1,transition=0,pending=0,enabled=0,vcounter= 0,hclock= 428
* w4200: 00 at 808300 read=1,line=1,transition=0,pending=0,enabled=0,vcounter= 34,hclock= 982
* w4200: 01 at 808b60 read=1,line=1,transition=0,pending=0,enabled=0,vcounter=156,hclock= 514
* w4200: 01 at 808476 read=0,line=1,transition=0,pending=0,enabled=0,vcounter=258,hclock=1228
* w4200: 81 at 808482 read=0,line=1,transition=0,pending=0,enabled=0,vcounter=258,hclock=1344
* w4200: 01 at 80878d read=1,line=0,transition=0,pending=0,enabled=1,vcounter=260,hclock= 756 |
From what I know, you can continually trigger NMI interrupts by not
reading $4210, and continuously writing 0, then 1 to NMI enable bit in
$4200. The game appears to be doing just that...
|
|
Schism New Member
Joined: 07 Dec 2005
Posts: 4
|
Posted: Tue Jul 25, 2006 5:24 pm Post subject: |
|
FFVI
(J): During the opening demo, the smoke effect from the smokestack
seems wrong. Is it a bug? I've never seen it on a real cart. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 5:53 pm Post subject: |
|
It
happens in the real game, from what I've read elsewhere. Something to
do with the game trying to perform more effects than it has HDMA
channels for, and subsequently when text is onscreen you lose the
translucent smoke effect, or something like that. I forgot the exact
details. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 25, 2006 9:38 pm Post subject: |
|
chipzoller wrote: |
I'm
not sure if this is actually a bug or merely the consequence of high
cpu usage while running the emulator. I've noticed in Tales of
Phantasia that some sound studder is present when walking on the world
map, almost like the sound is degrading due to frame drops or something. |
If you're on the fringe of getting full speed, as I am, it's possible
your fps is dipping to 58/59 in parts of games that have more intensive
renders. I wouldn't worry about it in the wip versions. The official
will likely clear this up. Then again, that ToP stuff could be normal.
Didn't the game use tricks to get more sound channels? If you're
getting crackling, it's probably an fps issue.
chipzoller wrote: |
Also
noticed that Far East of Eden Zero won't run. Even without the graphics
packs you should still get an error message on screen. These may have
been reported, but I couldn't search this thread for them. |
Thanks for mentioning this. I forgot all about SPC7110. It's a data
decompressor chip. The following games use it: Far East of Eden Zero,
Momotarou Dentetsu Happy, and Super Power League 4
|
|
chipzoller Rookie
Joined: 27 Jan 2005
Posts: 16
|
Posted: Tue Jul 25, 2006 10:09 pm Post subject: |
|
Quote: |
I wouldn't worry about it in the wip versions. |
Is v0.016 posted on Byuu's site considered WIP? I don't know if other
versions/builds are out there, but I used this version from his site.
And v0.017 is supposed to have massive speed-ups, then?
Quote: |
Then again, that ToP stuff could be normal |
I think you're right in that it's a slow-down issue that's causing the
crackling. ZSNES doesn't have this problem so I think it's a
speed-related issue.
On another note, are there plans on implementing some sort of save state function?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 25, 2006 10:23 pm Post subject: |
|
Sorry,
I thought you were using the 27a wip that got posted. In any case, you
should be getting more speed in the next version which may resolve it
for you.
What byuu has revealed thus far about
savestates is that they might be possible with the new core, but they
were thought to be a tradeoff for improved accuracy, and everyone voted
for accuracy. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 25, 2006 10:43 pm Post subject: |
|
I
can implement savestates, but I can only capture them when all units
are at a suitable stopping point. The more "safe" savestate points I
have, the slower emulation gets. The less I have, the longer it will
take to capture a savestate.
I'm thinking of
making a tradeoff where I disable synchronization and run each
component to a safe sync spot. The worst case is that your savestate
has one opcode that is opcode-accurate instead of bus-accurate, but
savestates are as finely grained as in ZSNES and SNES9x. But I don't
know just yet... I'm not interested in adding savestates right now.
And FitzRoy, you're also missing the ST010, ST011 and ST018 special
chips that I don't support. I also don't support the BS-X flashcart, or
any input devices other than the joypad. Quite a lot of progress, but
at the same time quite a ways to go, heh. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 25, 2006 11:22 pm Post subject: |
|
Yeah,
I'll just group all the BS stuff together for now, and I've added the
seta chips. I'm sure you're aware of peripherals like the mouse,
multitap as well. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 3:01 am Post subject: |
|
Fans of homosexual fighters the world over rejoice.

This game uses some truly evil code.
Code: |
;V>=225,$4210.d7=1
rep #$20
lda #$0080
sta $4200
sta $0201 |
The write to $4200 enables NMI during the second to last cycle
(technically at the very end of it), and NMI tests to see if it should
be fired at the very start of the last cycle, so thusly an NMI triggers
before sta $0201, and then the game reads $0201 and updates $4200 with
it, and then jumps into an infinite loop. On hardware, there is a
slight delay between writing to $4200 and when NMIs can trigger.
Figuring out how long this delay really is is nigh impossible, sadly. I
was able to use a delay of 2 clocks (the smallest time measurement
possible) which should always account for this edge case, and it's the
only way to execute this edge case that I'm aware of. As a result, Chou
Aniki is now playable. As well, all of my NMI and IRQ tests plus timing
tests still pass, so this is a correct hardware pass with no inaccurate
reversions.
An interesting side note, other emulators manage to play this game
because they do not properly trigger the NMI after the write to $4200.
On a real SNES, it is possible to repeatedly trigger NMIs by strobing
$4200.d7, so long as V>=225, and $4210 was not read once it was set
at V=225.
Other emulators thusly skip right over the interrupt, and get stuck for
a frame until NMI triggers, and then emulation continues.
This code required clock-fine IRQ delay timing, so I thusly modified
the Wild Guns fix to use the same code. Very surprisingly, there was no
speed loss! But now the "Wild Guns fix" is much more hardware accurate.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 26, 2006 3:24 am Post subject: |
|
Good stuff. And then there were 2. Should be interesting to hear what EWJ2 is doing. |
|
chipzoller Rookie
Joined: 27 Jan 2005
Posts: 16
|
Posted: Wed Jul 26, 2006 3:26 am Post subject: |
|
Just
tested the new NINJA beta prog. by hard-patching my star ocean ROM with
the dejap release. ZSNES renders it fine but this is what bsnes shows
at the title screen:
 |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jul 26, 2006 3:53 am Post subject: |
|
FitzRoy wrote: |
And then there were 2. |
Two what? How are you sub-dividing the buglist so that there are only "two" left?
chipzoller wrote: |
by hard-patching ... ZSNES renders it fine but this is what bsnes shows at the title screen |
I don't think byuu gives a shit about hard-patched ROM translations.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 4:04 am Post subject: |
|
Another fix. If HDMA or
HDMA init trigger on a channel while a DMA is active on that same
channel, the DMA transfer will be stopped. The new finding was that
this also applied to HDMA init. It doesn't fix any games. It's another
one of those "nobody will ever notice" fixes that just give me a bit
more hardware accuracy.
For emulator authors only :
byuu.cinnamonpirate.com/files/snestest_072506.zip
Copy and paste link. test_dma.smc will verify this behavior. It does
not require H/DMA bus sync timing and is pretty flexible to non-exact
timing. But it's still too strict for ZSNES since that emu runs an
extra scanline per frame, making the test miss HDMA init.
Quote: |
Two what? How are you sub-dividing the buglist so that there are only "two" left? |
I think he means two left that I can likely fix. There are five known confirmed bugs at this point.
Quote: |
I don't think byuu gives a shit about hard-patched ROM translations. |
You thought correctly. If someone makes an SO cart and verifies this
doesn't happen, I might look into it. Most likely the translation is
abusing an inaccurate memory map or writing to VRAM outside of vblank,
probably the latter. My suspicions are likely confirmed by the fact
that the original Japanese game plays just fine.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jul 26, 2006 10:30 am Post subject: |
|
Well,
after going through plenty of roms, I think I've finally found some
more bugs to report. They do not occur in zsnes or super sleuth, and
are also present in .016.
Cosmo Police Galivan II (J) - hangs at stage start.
G.O.D - Mezameyo to Yobu Koe ga Kikoe (J) - upper part of screen flickers in character menu transitions.
Kessen! Dokapon Oukoku IV - Densetsu no Yuusha-tachi (J) - hangs at king's throne after first character selection.
La Wares (J) - hangs right after title screen.
If I've erred on any of these, let me know. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 2:20 pm Post subject: |
|
I'd like verification that GOD doesn't do that on hardware if possible. Which it's probably not. |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Jul 26, 2006 4:54 pm Post subject: |
|
Actually,
I do see some sort of flicker on menu transitions on the top half of
the screen in G.O.D. on my SF7. This may or may not be irrelevant, but
on the real snes, the flicker was solid, while it looked like a bunch
of bars on bsnes. (NOTE: only some of the menu transitions exhibit the
sort of flicker that shows up as a bunch of bars in bsnes.) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 5:28 pm Post subject: |
|
Thank
you zidanax, the black area is solid on my latest WIP. At least I think
they all are. I've only tested a few menus. Some don't flicker at all,
some show a ~40-80 pixel black box at the top for a single frame.
If wip37 is still exhibiting the scattered black bars, then we still have a problem possibly.
So then this exists on real hardware. Thanks a million for confirming this for me.
Also, good news. anomie fixed Super Conflict because he is the ubercoder :D
Hats are off to him on this one. Full credit to anomie.
When OBJ is exactly
at 256 (and only 256), it's a special case and all the tiles of the
sprite still count for time over (of the 34 possible tiles loaded),
even though none of them are visible.
So, at least one, possibly two bugs to safely remove. |
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Wed Jul 26, 2006 6:00 pm Post subject: |
|
byuu wrote: |
For
the record, ZSNES and Super Sleuth work by not triggering an NMI at
all, as if the $01 write to $4200 clears the pending NMI. That's not
the case on real hardware according to my test programs. I suspect the
reality is that if NMI is enabled immediately before the opcode's last
cycle, it's not lowering the NMI pin, delaying the NMI for one more
opcode. That would also allow Chou Aniki to work. |
That's not correct for Super Sleuth. The only time a pending NMI is
cleared is when $4210 is read and at the start of scanline 0.
Last edited by Overload on Wed Jul 26, 2006 6:25 pm; edited 2 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 6:09 pm Post subject: |
|
http://byuu.cinnamonpirate.com/temp/aniki.txt
Code: |
;assume V>=225, $4210 not read since V=225 or earlier
80847C LDA $0201 [000201] A:0001 X:0300 Y:0000 S:0139 DB:00 D:0000 P:04 e
80847F ORA #$0080 A:0001 X:0300 Y:0000 S:0139 DB:00 D:0000 P:04 e
808482 STA $4200 [004200] A:0081 X:0300 Y:0000 S:0139 DB:00 D:0000 P:04 e
808485 STA $0201 [000201] A:0081 X:0300 Y:0000 S:0139 DB:00 D:0000 P:04 e |
Super Sleuth v1.04.5 does not trigger an NMI, it keeps running until it
gets stuck in a loop waiting for NMI, that waits until presumably the
next frame, but well after the sta $0201 where it should fire.
Also, my apologieis if I appear condescending about this. I'm just
trying to share my findings and help get these bugs fixed in all
emulators.
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Wed Jul 26, 2006 6:24 pm Post subject: |
|
byuu wrote: |
Super
Sleuth v1.04.5 does not trigger an NMI, it keeps running until it gets
stuck in a loop waiting for NMI, that waits until presumably the next
frame, but well after the sta $0201 where it should fire. |
Sleuth doesn't trigger an nmi because the code is executed on scanline 82, well before the nmi trigger point.
Code: |
CPU Trace Started @ Frame:00000032 HCT:0056 VCT:0052
80847c lda $0201 [00:0201] A:0001 X:0300 Y:0000 S:0139 D:0000 DBR:00 P:04 E-
80847f ora #$0080 A:0001 X:0300 Y:0000 S:0139 D:0000 DBR:00 P:04 E-
808482 sta NMITIMEN [00:4200] A:0081 X:0300 Y:0000 S:0139 D:0000 DBR:00 P:04 E-
808485 sta $0201 [00:0201] A:0081 X:0300 Y:0000 S:0139 D:0000 DBR:00 P:04 E-
808488 pld A:0081 X:0300 Y:0000 S:0139 D:0000 DBR:00 P:04 E-
808489 plb A:0081 X:0300 Y:0000 S:013b D:0000 DBR:00 P:06 E-
CPU Trace Stopped. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 7:28 pm Post subject: |
|
Quote: |
Sleuth doesn't trigger an nmi because the code is executed on scanline 82, well before the nmi trigger point. |
o.O well then one of us has some serious timing issues :P
Code: |
* vcounter=258,hclock=1320
808482 sta $4200 [$004200] A:0081 X:0300 Y:0000 S:0139 D:0000 DB:00 nvmxdIzc |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jul 26, 2006 10:56 pm Post subject: |
|
FitzRoy wrote: |
Kessen! Dokapon Oukoku IV - Densetsu no Yuusha-tachi (J) - hangs at
king's throne after first character selection. |
It won't *hang* if when asked do you want Human or CPU, you answer CPU
for the controllers you don't have plugged in. If you answer Human,
make sure to press A on the appropriate controller. It's not a hang, as
it's just waiting for you to press A, and you are not.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 26, 2006 11:11 pm Post subject: |
|
So then, GOD was not a bug.

This is not a bug. Player 2 has to select a character, and then Player
1 has to select a player for Player 3. The game is expecting a Super
Multitap 5, but you can botch your way through it if you can read the
menus.

Input bug. When auto joypad polling is off ($4200.d0 = 0), you can
still read the last values updated to $4218-$421f. These two games turn
that off, and bsnes was returning 0x00 in that case. Both are now fixed.
As always, ignore the version number. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 27, 2006 2:25 am Post subject: |
|
Thanks,
I can not read Japanese. Nice to know that two of those were not bugs,
and it's cool that the other two were the same one. I'll have to find a
list of multi-tap (j) games sometime. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Jul 27, 2006 2:44 am Post subject: |
|
FitzRoy wrote: |
I'll have to find a list of multi-tap (j) games sometime. |
Isn't it funny that NSRT has this option to printout a list of multitap games?
_________________
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: Thu Jul 27, 2006 4:43 am Post subject: |
|
Not really, because I just spent the last ten minutes trying to find it. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Jul 27, 2006 4:51 am Post subject: |
|
Right clicking is your friend (this is a huge hint).
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 27, 2006 5:04 am Post subject: |
|
Oh, so it's front-end specific. I was looking in the readme files and found nothing.
Turns out Kessen is not among those listed anyway, so it wouldn't have helped any. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Jul 27, 2006 5:09 am Post subject: |
|
FitzRoy wrote: |
Oh, so it's front-end specific. I was looking in the readme files and found nothing. |
nsrt.txt wrote: |
-control Makes NSRT list all ROMs in the database that use any sort of special controller (e.g. Mouse, Super Scope). |
Multitap is considered a special controller. This feature is not frontend specific anyways.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 27, 2006 5:32 am Post subject: |
|
Yeah, I just didn't see it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 27, 2006 8:06 pm Post subject: |
|
Eh,
little harm done. Wasted 5 minutes of time I'd otherwise be listening
to music and chatting on IRC testing them. And you did find a valid
input bug that affected at least two games, so yay for that.
Now then, I found a fix for Earthworm Jim 2 (E). If I bump the clocks
per scanline up from 1364 to 1366 or above, the sound is identical to
EWJ2 (U). The only problem is I can't test this on real hardware since
I lack a PAL SNES + copier + TV + adapters - whatever of that stuff I
don't need. Point being, I can't verify it's correct. But it's a good
indication it is since the game works now. The fix would only apply to
the PAL region, and not the verified NTSC region. Should I add the fix,
or can anyone confirm/deny how many clocks there are per scanline on
PAL systems?
I could make a test ROM to determine this if anyone can run it on a PAL copier for me.
EDIT: I can also fix this by underclocking the CPU. Since we don't
definitively know the CPU speed of PAL SNES units, I think that might
be a better option. The CPU then operates at the same clock/scanline
rate as NTSC, but technically since the CPU is running a little slower,
the CPU gets APU updates quicker, and it also fixes the problem.
So now I need to decide between increasing the clock/scanline ratio,
underclocking the CPU, or doing neither since they cannot be verified
on hardware by myself.
Last edited by byuu on Thu Jul 27, 2006 8:32 pm; edited 1 time in total |
|
PHoNyMiKe Retrosexual

Joined: 28 Jul 2004
Posts: 1534
Location: the tug boat
|
Posted: Thu Jul 27, 2006 8:27 pm Post subject: |
|
I could run it on my copier, and set the snes to pal timing. should fully simulate a PAL snes.
_________________
ultimate immortality
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 28, 2006 4:09 am Post subject: |
|
Ok,
this WIP rewrites the input code and modifies the PAL clock speed.
Fairly major changes. Ideally, this will wipe out four bugs without
causing any new ones since wip37.
Bug fixes :
Earthworm Jim 2 (E) - adjusted PAL CPU clock speed. Please test for *new* sound problems in PAL games
La Wares (J) + Galivan 2 (J) - no longer return 0 when auto joypad is off for polling $4218-$421f
Super Conflict (J) - added anomie's new OAM RTO findings to fix title screen
The input code was almost completely rewritten to simulate real
hardware more. As such, it's very possible there are new input bugs.
Ok, so then byuu.cinnamonpirate.com/files/bsnes_v016_wip38.zip
Please only download if you intend to test games and report feedback.
This version is slower than normal, lacks ZIP+JMA loading, and has the
debugger enabled (that is only useful to me, it lacks a functional user
interface) which slows down emulation even more. eg you're better off
with v0.016 official if you just want to run games.
As always, please don't post this link anywhere else, or I will be forced to remove the file to conserve bandwidth.
If anyone posts bugs that hasn't tested against wip37, can I please
have someone with wip37 verify/deny the bug presence in wip37 as well
as in 016 official? wip37 isn't on my website because I don't have a
lot of web space to spare.
Thank you to everyone in advance for helping. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Jul 28, 2006 4:51 am Post subject: |
|
Bsnes
doesn't seem to like ufo headers. The Mortal Kombat 3 (U) rom I have
doesn't seem to load up at all unless I strip it or change it to a
different one. You could just have it ignore them I suppose.
Edit: I took a peek at the info in the debugger and it's detecting it
as a lo-rom for some reason. Ucon64 said it was a Hi-rom though so
something isn't right. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 28, 2006 5:36 am Post subject: |
|
Seems to work fine for me.
Code: |
* CRC32 : 4e6af725
* Name : "MORTAL KOMBAT 3 R2.1 "
* PCB : UNL-HIROM
* ROM Size : 32mbit
* RAM Size : 0kbit
* Region : NTSC
* Coprocessor(s) : None |
bsnes ignores headers. The only thing that will throw it off is if the
ROM size is not an even multiple of 32k (or multiple of 32k + 512-byte
header), so eg a 32,769 byte file would make bsnes unable to determine if the image has a header or not.
Anyway, now that I have a database and support for various PCB mappers,
I've no intentions of continuing these header detection games. If a
game fails my detection code at this point, that game will get added to
my database so that it will no longer fail. My time is too limited to
play games with.
---
Didn't mention this before, but aside from a hackish Uniracers fix I
won't be adding to the emulator, I can't fix any of the remaining bugs
myself. Hopefully they will resolve themselves somewhat with time. But
I think 3 known bugs is the shortest you're ever going to see my bug
list. And I expect it to grow quite a bit as more people get to try out
the newer builds with more games.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 28, 2006 7:16 am Post subject: |
|
Good
job squashing all those bugs this past week, byuu. Kudos to anomie for
fixing Super Conflict. I think for "shared" bugs like that and
Uniracers, it's only a matter of time. I also hope someone steps up and
helps you verify those PAL mysteries. There HAVE to be people on this
forum who live in Europe and have copier setup, but you might want to
ask on your website as well.
So far on the new
wip, I haven't run into any new issues. I'll be on vacation for the
next 3 days, though, so let's hope people are seriously going through
lots of games, and not just playing the ones they like.
Just a few things I want to mention in case you're close to a release:
1. In windowed mode, bsnes does not suppress the windows screen saver,
so it pops up annoyingly while you're playing if you use gamepad.
2. In windowed mode, if you mouse over something like the windows clock
while a game is playing, the emu slows to a crawl (similar to what was
happening when you had the transparent config menu). If this is
unfixable, I understand. Just being thorough.
3. I'm wondering why the frameskip setting does not save on exit. If
there's a reason for this, I'd like to know. I think users would like
this feature. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Jul 28, 2006 7:41 am Post subject: |
|
God
I'm such a fucking dope. It was because the rom was interleaved. Ho ho
sorry for the false bug report byuu. Anyway as far as reporting bugs I
really have no more to report. I only play a hand full of snes games
and don't want to go through thousands of awful games. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jul 28, 2006 3:21 pm Post subject: |
|
That's cool. Someone will eventually test the obscure ones and find problems.
So long as everyone's favorite games are all working though, the WIPs are at least at a release-grade quality now.
If everyone's input controls are working fine in games, then likely my
controller changes are safe. I'd actually be pleasantly surprised if
that turned out to be the case. I completely rewrote the way it works
to truly use a bitshifter on $4016/$4017, and buffered registers for
$4218-$421f.
Quote: |
1.
In windowed mode, bsnes does not suppress the windows screen saver, so
it pops up annoyingly while you're playing if you use gamepad. |
Don't know how to do this.
Quote: |
2.
In windowed mode, if you mouse over something like the windows clock
while a game is playing, the emu slows to a crawl (similar to what was
happening when you had the transparent config menu). If this is
unfixable, I understand. Just being thorough. |
Maybe setting bsnes priority to high would fix it? I wouldn't want to
do that for the default, because it would make other apps sluggish on
slower systems.
Quote: |
3.
I'm wondering why the frameskip setting does not save on exit. If
there's a reason for this, I'd like to know. I think users would like
this feature. |
It was intentionally not saved on exit. Though it's a one word change
to make it save. I've been meaning to tie a default frameskip rate for
speed regulation modes, such that say 2x speed would raise the
frameskip for you, whereas 0.5x would not. Perhaps I'll tie in
frameskip saving at that time.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jul 28, 2006 7:00 pm Post subject: |
|
Someone on the zsnes team might know about the screensaver thing, since it behaves that way.
As for the frameskip - only reason I mention is that for a person using
a 1ghz computer with bsnes, they're likely going to want a frameskip
setting of 1, always. Currently, though, they have to set it back every
time they start the program. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Jul 29, 2006 12:42 am Post subject: |
|
Nice
to see the degugger is back in(even if it's not fully functional for
regular users). Will it stay in the next major release?
Anyway, the speed by which you've been recently fixing emulation
accuracies/game bugs issues is nothing short of amazing.( not
forgetting everyone who has helped either of course)
I'll try to test a number of games (mostly obscure japanese games). |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Jul 29, 2006 3:13 am Post subject: |
|
Dmog wrote: |
Will it stay in the next major release? |
Probably not, since I think it decreases speed slightly, and I think
byuu puts a high priority on speed, right now.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jul 29, 2006 4:07 am Post subject: |
|
It incurs a 10% speed hit and is only useful to me. It makes no sense to enable it in official releases in its current form.
I'm thinking about a two-way communication between the core and UI
(probably through the SNES base class) to allow toggling of tracing
features directly from the core. This would bring bsnes up to par with
say, SNES9x LT, and work on Unix platforms as well. That might be
something I can squeeze in before v0.017 is released, but don't count
on it :/ |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Jul 29, 2006 12:00 pm Post subject: |
|
Byuu, i actually do have a pal snes, with a pal WildcardDX and a pal tv.
if you host your test roms somewhere i can run them on my snes and send you the results
my wildcard can run upto 32mbit
I also have an extremely sucky tv capture card, but as there is so much
static on it its not really usefull for extracting information |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jul 30, 2006 10:03 am Post subject: |
|
Thanks, I'll try and think up some tests and then send them your way :D
Side note: rewrote the UI-side input system so that my ui/input class
is platform-independent. As a result of the rewrite, there is now
primary+secondary button mappings instead of key+joy mappings. So you
can now map say the start button to keyboard.q + joypad0.button1,
keyboard.q + keyboard.p, or joypad0.button1 + joypad1.button1.
You can also use the secondary input to make key pairs, such as up+down
both mapped to q, and left+right both mapped to w.
Not very practical, but it's there. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Jul 31, 2006 8:04 am Post subject: |
|
By
chance were you able to resolve the crackling sound issue with tripple
buffering? That would be spectacular to have smooth scrolling and
sound. Also would be awesome is a resharping dial for bilinear
filtering. I've seen this function in other programs and it really
helps get rid of the blurring effect caused by bilinear filtering,
while still retaining the advantage of non-warped looking pixels. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 31, 2006 12:44 pm Post subject: |
|
Nope, not been able to resolve triple buffering issues. I agree, smooth video+audio would be awesome.
My idea for bilinear filtering was to make a hybrid system where draw a
pixel filtered image to the screen, then a translucent bilinear
filtered image on top of it. You have a slider to control the luminance
of the bilinear filtered image. The only problem is it looks terrible
when you're at a non-native multiple of the SNES internal resolution of
256x224. So I was thinking, scale the image to 512x448 in this manner,
and then use bilinear to get it up to 1024x768, etc. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 04, 2006 5:33 am Post subject: |
|
Ok, one semi-large change if anyone wants to test.
byuu.cinnamonpirate.com/files/bsnes_v016_wip42.zip
This is built for maximum speed. No debugger, PGO enabled, favor speed,
no c++ EH (so no ZIP/JMA), and a new addition: links against msvcrt
instead of libcmt.
By using msvcrt and some evil linker hacks I was finally able to build
the SDL port again on Windows. So now I just need to focus on cleaning
that up so the next release will build on Linux out of the box. Anyway,
I tried it on the non-SDL port for the hell of it, and noticed not only
a 20% drop in EXE size, but a ~10-11% speedup as well. Only problem is
it requires msvcr80.dll, and I have no idea how common that file is.
So, that's what this wip is for. Does this version work for you, and if
it does, does it run faster? A direct FPS comparison between v0.016 and
v0.016.42 would be helpful if you're not sure. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 04, 2006 6:32 am Post subject: |
|
Hmm,
won't run for me. Says: this application has failed to start because
the application configuration is incorrect. Reinstalling the
application may fix this problem. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Aug 04, 2006 6:34 am Post subject: |
|
Do you have that DLL?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Aug 04, 2006 6:38 am Post subject: |
|
I get the same error, so I guess I'm missing the DLL.
edit: Dled the dll (or what is supposed the be the DLL anyway), copied
it to the windows system directory but I get the same error. I suppose
the dll need to be registered or something.
Last edited by Dmog on Fri Aug 04, 2006 6:45 am; edited 1 time in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Aug 04, 2006 6:41 am Post subject: |
|
Dmog wrote: |
I get the same error, so I guess I'm missing the DLL. |
Don't guess, do a search. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Fri Aug 04, 2006 1:48 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 04, 2006 8:30 am Post subject: |
|
I had the dll in my system and system32 directories. No go. File won't register either. Loaded but no entry point found. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Aug 04, 2006 9:18 am Post subject: |
|
Hrm
on my xp system it loaded msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fd8b3b9b1e18e3b_8.0.50727.42_x-ww_0df06bcd\
Instead of the C:\windows\system32 folder. It's probably something with
the registry, but I haven't looked that closely at it yet.
Edit: Ah it needs special policies and whatnot. I think it was either
installed with the .net 2.0 framework or when I installed visual C++
2005.
Edit2: I changed the directory name just incase those numbers
specifically identify the file I have. I haven't a clue how this
actually works. I don't mess around with windows enough, sorry. |
|
OutrightOwnage Rookie
Joined: 30 Jul 2006
Posts: 29
|
Posted: Fri Aug 04, 2006 12:35 pm Post subject: |
|
Dmog wrote: |
I get the same error, so I guess I'm missing the DLL.
edit: Dled the dll (or what is supposed the be the DLL anyway), copied
it to the windows system directory but I get the same error. I suppose
the dll need to be registered or something. |
yeah, winsxs is confusing. you need to find the manifest for the dll
and stick both it and the dll in the apps folder.
if im not too busy doing your mom tonight, i'll upload it for you.
_________________
abusing your punk ass since 2006
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Fri Aug 04, 2006 12:46 pm Post subject: |
|
powerspike wrote: |
Hrm
on my xp system it loaded msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fd8b3b9b1e18e3b_8.0.50727.42_x-ww_0df06bcd\
Instead of the C:\windows\system32 folder. It's probably something with
the registry, but I haven't looked that closely at it yet.
Edit: Ah it needs special policies and whatnot. I think it was either
installed with the .net 2.0 framework or when I installed visual C++
2005.
Edit2: I changed the directory name just incase those numbers
specifically identify the file I have. I haven't a clue how this
actually works. I don't mess around with windows enough, sorry. |
That is because you already have the correct runtime installed. You
really shouldn't mess with anything inside the WinSxS folder.
Read this.
Also the post about an installed binding redirect policy here. This file should be installed with Visual Studio 2005 RTM, or the redistributable package.
The older version number in the manifest would seem to indicate that it
was either compiled with beta 2, or an older manifest file was left
over and not regenerated by the newer compiler/linker.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 04, 2006 2:23 pm Post subject: |
|
It's
too bad Microsoft can't get their shit together anymore. I'm not adding
another DLL hell to my app. If this doesn't work out of the box for you
guys, then I'll just take out /MD. Thanks for testing. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Aug 04, 2006 3:54 pm Post subject: |
|
byuu wrote: |
It's
too bad Microsoft can't get their shit together anymore. I'm not adding
another DLL hell to my app. If this doesn't work out of the box for you
guys, then I'll just take out /MD. Thanks for testing. |
Oh well. When you said a 10% speed gain, you meant compared to 0.016?
OutrightOwnage, please don't stink up the thread with your gettho crap. Thank you.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 04, 2006 4:02 pm Post subject: |
|
A
10-11% speed gain from v0.016.38. In other words, adding /MD causes DLL
hell and gains 11% speed. Removing it increases EXE by 200kb, lowers
speed by 11%, and removes Microsoft-incompetence hell. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Fri Aug 04, 2006 4:33 pm Post subject: |
|
Works well out of the box for me too. Framerate is well in excess of 100fps, so you have done an excellent job on speed here.
The single issue I do have is that I am having problems forcing a fully
stretched fullscreen resolution that corresponds to the native
resolution of my LCD. Going out of fullscreen causes the emu to be
permanently minimised to the taskbar.
So, you have to use multipliers to get a larger image to avoid this
issue. I have found that
"0;1;0;3;true;false;false;256;224;1280;1024;60;false" works pretty well
for me (but with borders all around the image).
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
Last edited by Clements on Fri Aug 04, 2006 5:50 pm; edited 2 times in total |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Aug 04, 2006 5:11 pm Post subject: |
|
kode54 wrote: |
That is because you already have the correct runtime installed. You
really shouldn't mess with anything inside the WinSxS folder.
|
Oh I wasn't about to change anything around. I was just trying to
figure out how it was installed. I know enough not to screw up my
system thankfully. Ah, thanks for that link by the way.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Fri Aug 04, 2006 6:17 pm Post subject: |
|
powerspike wrote: |
kode54 wrote: |
That is because you already have the correct runtime installed. You
really shouldn't mess with anything inside the WinSxS folder.
|
Oh I wasn't about to change anything around. I was just trying to
figure out how it was installed. I know enough not to screw up my
system thankfully. Ah, thanks for that link by the way.
|
Well, you did say you installed Visual Studio 2005, which includes the
CRT/STL/ATL/MFC debug and release runtime modules in WinSxS, and the
.NET 2.0 Framework.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 04, 2006 6:53 pm Post subject: |
|
Quote: |
The
single issue I do have is that I am having problems forcing a fully
stretched fullscreen resolution that corresponds to the native
resolution of my LCD. Going out of fullscreen causes the emu to be
permanently minimised to the taskbar. |
Yes, that is a problem. I tried reducing the render size to the current
screen size, but this still fails. If I force the window size to be
even smaller to accomodate for the window borders, it works. But that
seems sloppy.
Honestly, I liked my old system more, with allowing the user to select
a default windowed and default fullscreen mode, and have each mode give
you the option to set it as a windowed or fullscreen mode.
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Aug 04, 2006 6:55 pm Post subject: |
|
Haha
l I spend more time drinking then chatting with people so I tend to
screw up alot. Er if I'm talking all weird just ignore me I guess. |
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Aug 04, 2006 8:03 pm Post subject: |
|
msvcr80.dll is very common.You can find it in your Mozilla Firefox folder 
Just copy this one and paste to your bsnes folder and you'll be doing great.No need to put it in System32 (DLL hell)
...at least it's included in the Bon Echo (2.x) and Minefield (3.x) builds,not sure about 1.5.0.6 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 04, 2006 9:48 pm Post subject: |
|
I
don't have that dll in my firefox 1506 folder, nor does bsnes work when
I put the dll in my bsnes directory. I'd be surprised if byuu changed
his stance. Too much of a hassle and too much to ask if it requires
installing Visual Studio. If the required file(s) could somehow be
bundled with bsnes to work, then I can see it being used. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 04, 2006 10:11 pm Post subject: |
|
Quote: |
I'd be surprised if byuu changed his stance. |
I'm going to make it a compile-time option, much like SSE2 support is
now. If you compile it yourself, and add in SSE2 and MSVCRT linking,
you'll gain a 20% speedup. Or if someone wants to be generous and host
the binaries, we could do that as well.
I'm also considering either runtime checking for d3dx9*.dll, or just
making screenshot capture with D3D a compile-time option as well. No
more DLL hell for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 04, 2006 10:36 pm Post subject: |
|
Good
stuff. That way, not even the least savvy xp user will be hit with a
missing dll message. Bsnes will just work for everyone out of the box.
Although when SP3 comes out, you might be able to stick that screenshot
one in again.
PS: Anyone running a vista beta know how well bsnes works with it? |
|
OutrightOwnage Rookie
Joined: 30 Jul 2006
Posts: 29
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 04, 2006 11:14 pm Post subject: |
|
Yep,
that works. Thank you. It was the manifest file I was missing. It's too
bad all these files can't be bundled with the exe, then the choice
would be simple. |
|
Mr. Business New Member

Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
|
Posted: Sat Aug 05, 2006 3:49 am Post subject: |
|
Hi there!
I may or may not have two bugs to report with bsnes v0.016, depending
on whether Secret of Mana and Secret of Evermore use any sort of
special chipsets. Is there a place that I can get information on which
chipsets went into which cartridges? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 05, 2006 4:01 am Post subject: |
|
Hi Mr. Business. Download NSRT 3.3 for windows from here: http://nsrt.edgeemu.com/forum/viewtopic.php?t=602
In the front end program, browse to the folder containing your roms and
scan them. Under "type", if it says anything other than normal, that's
a special chip. SoM and SoE do not use special chips. However, there's
a good chance the bugs you're referring to have already been fixed
since .016. If you're using .016.42 though, we would be interested to
hear about them. |
|
Mr. Business New Member

Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
|
Posted: Sat Aug 05, 2006 4:18 am Post subject: |
|
I'm
dreadfully sorry to follow a question with another question, but where
can I download the current working version of bsnes from? I've only
managed to find 0.016 links. Is it somewhere in the thread here? I
could definitely determine whether or not the bugs occur in the latest
version, were I in possession of the latest version.
Again, I apologize for my ignorance. The thread is very large, and so
finding these things out is slightly difficult. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 05, 2006 5:19 am Post subject: |
|
It's on the previous page: byuu.cinnamonpirate.com/files/bsnes_v016_wip42.zip
Make sure you download the files from the link 5 posts up and put them in your bsnes folder. |
|
Mr. Business New Member

Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
|
Posted: Sat Aug 05, 2006 5:45 am Post subject: |
|
Does this new version not read roms from inside of zip and rar files?
Well, whatever the case:
1. The bug that I found in Secret of Mana has been resolved in the latest version.
2. The Secret of Evermore bug appears to still linger.

Any games saved under bsnes become corrupted like so, and the saves
cannot be reloaded at a later date. So, if one utilizes the game's save
feature while running the game in bsnes, the save will be corrupted.
Hopefully that second one hasn't already been reported. If it has, I apologize. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Aug 05, 2006 6:07 am Post subject: |
|
Mr. Business wrote: |
Does this new version not read roms from inside of zip and rar files?
Well, whatever the case:
1. The bug that I found in Secret of Mana has been resolved in the latest version.
2. The Secret of Evermore bug appears to still linger.

Any games saved under bsnes become corrupted like so, and the saves
cannot be reloaded at a later date. So, if one utilizes the game's save
feature while running the game in bsnes, the save will be corrupted.
Hopefully that second one hasn't already been reported. If it has, I apologize. |
No zipped file support in this wip build
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 05, 2006 6:58 am Post subject: |
|
Thanks for your input, I've confirmed the bug. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Aug 05, 2006 7:38 am Post subject: |
|
byuu wrote: |
I'm
going to make it a compile-time option, much like SSE2 support is now.
If you compile it yourself, and add in SSE2 and MSVCRT linking, you'll
gain a 20% speedup. Or if someone wants to be generous and host the
binaries, we could do that as well. |
ipher?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Aug 05, 2006 12:14 pm Post subject: |
|
Speed regulation doesn't seem to work for me in wip42. I get 75+ fps in most games |
|
OutrightOwnage Rookie
Joined: 30 Jul 2006
Posts: 29
|
Posted: Sat Aug 05, 2006 12:21 pm Post subject: |
|
FitzRoy wrote: |
It's too bad all these files can't be bundled with the exe, then the choice would be simple. |
why couldn't they be? bandwidth issues?
_________________
abusing your punk ass since 2006
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat Aug 05, 2006 1:36 pm Post subject: |
|
Dmog wrote: |
Speed regulation doesn't seem to work for me in wip42. I get 75+ fps in most games |
You shouldn't use the .cfg that byuu provided because it's disabled there.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Aug 05, 2006 2:02 pm Post subject: |
|
Jonas Quinn wrote: |
Dmog wrote: |
Speed regulation doesn't seem to work for me in wip42. I get 75+ fps in most games |
You shouldn't use the .cfg that byuu provided because it's disabled there.
|
Ah. My bad. It does make more sense for speed testing purposes obviously 
I'll report the results later on.
|
|
Kazuma New Member
Joined: 24 Jul 2006
Posts: 3
|
Posted: Sat Aug 05, 2006 2:42 pm Post subject: |
|
FitzRoy wrote: |
Good
stuff. That way, not even the least savvy xp user will be hit with a
missing dll message. Bsnes will just work for everyone out of the box.
Although when SP3 comes out, you might be able to stick that screenshot
one in again.
PS: Anyone running a vista beta know how well bsnes works with it? |
Running Vista 5472 build here. bsnes WIP42 works pretty good, but the
sound is ultra crappy. This could be the beta Creative drivers, but I
kind of doubt it. Sounds just like it would on XP if frames dropped
below 60fps ... except on Vista it is CONSTANT.
Edit: Found a problem however... If you shrink bsnes, then restore it,
video is lost, black screen. Got to restart emulator to get video back.
Last edited by Kazuma on Sat Aug 05, 2006 2:54 pm; edited 2 times in total
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat Aug 05, 2006 2:47 pm Post subject: |
|
The
.srm created by bsnes for Secret of Evermore isn't loaded in ZSNES
either. After comparing it to a .srm created by ZSNES most of the empty
space was filled with 0x00 in bsnes where it was filled with 0xFF in
ZSNES.
Edit: I just changed this
and it's still not fixed. There is probably some problem in the SRAM
access functions. Big Sky Trooper seems to have similar issues.
Edit 2:
Big Sky Trooper is fixed by actually mapping SRAM to banks F0-FF for
LoROMs and by initally filling the SRAM with 0xFF. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Aug 05, 2006 4:49 pm Post subject: |
|
Mr. Business wrote: |
Does this new version not read roms from inside of zip and rar files? |
Please don't expect RAR support in any of the major SNES emulators..
JMA is the compression of choice if you need the space.
Kazuma wrote: |
FitzRoy wrote: |
Good
stuff. That way, not even the least savvy xp user will be hit with a
missing dll message. Bsnes will just work for everyone out of the box.
Although when SP3 comes out, you might be able to stick that screenshot
one in again.
PS: Anyone running a vista beta know how well bsnes works with it? |
|
Worry about Vista being out first before worrying about Vista compatibility.
Quote: |
Running
Vista 5472 build here. bsnes WIP42 works pretty good, but the sound is
ultra crappy. This could be the beta Creative drivers, but I kind of
doubt it. Sounds just like it would on XP if frames dropped below 60fps
... except on Vista it is CONSTANT. |
Make sure triple buffering is NOT enabled. Any sensitive frame drops
will always cause choppy sound. It is because that is how the original
system (and also emu) works
Quote: |
Edit:
Found a problem however... If you shrink bsnes, then restore it, video
is lost, black screen. Got to restart emulator to get video back. |
byuu is already aware of this and it will probably be corrected soon.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 05, 2006 5:00 pm Post subject: |
|
I will add a PCB mapper to Secret of Evermore and see if it helps. I'll also set SRAM to 0xff, then.
Overload's PCB list wrote: |
Secret of Evermore (USA) [!] AEOE SHVC-1J3M-20
Secret of Evermore (Europe) [!] AEOP SHVC-1J3M-20 |
Mirrors SRAM to $[20-3f|a0-bf]:[6000-7fff]. Fairly typical HiROM game.
Might be failing due to overmapping instead, as I map HiROM and LoROM
SRAM into the generic "FuckROM" map used for PCB-less carts.
Quote: |
Big Sky Trooper is fixed by actually mapping SRAM to banks F0-FF for LoROMs and by initally filling the SRAM with 0xFF. |
Nobody has volunteered the PCB code for this cart. I will have to
either hackishly add f0-ff always for LoROM only, or leave it as is
until we get PCB info.
Quote: |
byuu is already aware of this and it will probably be corrected soon. |
kode54 gave me a fix for it. I forgot to e-mail it to myself, though,
so it isn't on my home PC. But it should be easy enough to find.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Sat Aug 05, 2006 6:17 pm Post subject: |
|
Oh wait, what's this? Did you just RAR up and upload something that Microsoft provides their own redistributable installer package for, which I just linked to a few posts ago? And uploaded it to RapidShare no less? You fail.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 05, 2006 8:43 pm Post subject: |
|
OutrightOwnage wrote: |
FitzRoy wrote: |
It's too bad all these files can't be bundled with the exe, then the choice would be simple. |
why couldn't they be? bandwidth issues?
|
Legal issues, I'm thinking.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Sat Aug 05, 2006 10:30 pm Post subject: |
|
I think the EULA only forbids redistributing VC++ debug builds, but I don't feel like digging out the DVD and digging through the EULA to find the exact terms. |
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Aug 06, 2006 12:33 am Post subject: |
|
Deathlike2 wrote: |
Worry about Vista being out first before worrying about Vista compatibility. |
Well, it's best to get out the word that there's possible bugs in their
software when ran in vista, that way you can expect the possible zomg
it doesn't werk in vista posts they'd get. 
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
OutrightOwnage Rookie
Joined: 30 Jul 2006
Posts: 29
|
Posted: Sun Aug 06, 2006 12:35 am Post subject: |
|
kode54 wrote: |
Oh wait, what's this? Did you just RAR up and upload something that Microsoft provides their own redistributable installer package for, which I just linked to a few posts ago? And uploaded it to RapidShare no less? You fail.
|
hmm, 434 kb vs 2.6 mb. maybe it makes no difference to you, but some people still care.
_________________
abusing your punk ass since 2006
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Sun Aug 06, 2006 1:24 am Post subject: |
|
Haha, dialup. I had no trouble pulling CD images over 56k years ago, so what's a few megabytes?
It's still better to point people to the official download, especially
since it can stick the files in the correct place if users are running
Windows XP or newer. Plus, the link is likely to last a lot longer than
an anonymous RapidShare download. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 06, 2006 2:22 am Post subject: |
|
Secret of Evermore is fixed. Thank you for the bug report, Mr Business.
Game is performing a DMA from $2180 to SRAM. I'm pretty sure I read
somewhere that this wasn't possible. But apparently, it is. The game
has actually been broken since the Krusty Super Funhouse fix. This may
or may not fix other games.
Code: |
8db36d sta $420b [$30420b] A:6002 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvMxdizc
* DMA[1] 3060f2 80 0065
8db370 rep #$20 A:6002 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvMxdizc
8db372 txa A:6002 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvmxdizc
8db373 clc A:6002 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvmxdizc
8db374 adc #$0155 A:6002 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvmxdizc
8db377 sta $4312 [$304312] A:6157 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvmxdizc
8db37a sep #$20 A:6157 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvmxdizc
8db37c lda #$30 A:6157 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvMxdizc
8db37e sta $4314 [$304314] A:6130 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvMxdizc
8db381 lda #$80 A:6130 X:6002 Y:0aba S:1fe5 D:0000 DB:30 nvMxdizc
8db383 sta $4311 [$304311] A:6180 X:6002 Y:0aba S:1fe5 D:0000 DB:30 NvMxdizc
8db386 ldy #$00a2 A:6180 X:6002 Y:0aba S:1fe5 D:0000 DB:30 NvMxdizc
8db389 sty $4315 [$304315] A:6180 X:6002 Y:00a2 S:1fe5 D:0000 DB:30 nvMxdizc
8db38c ldy #$2f52 A:6180 X:6002 Y:00a2 S:1fe5 D:0000 DB:30 nvMxdizc
8db38f sty $2181 [$302181] A:6180 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc
8db392 lda #$7e A:6180 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc
8db394 sta $2183 [$302183] A:617e X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc
8db397 lda #$80 A:617e X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc
8db399 sta $4310 [$304310] A:6180 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 NvMxdizc
8db39c lda #$02 A:6180 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 NvMxdizc
8db39e sta $420b [$30420b] A:6102 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc
* DMA[1] 306157 80 00a2
8db3a1 rep #$20 A:6102 X:6002 Y:2f52 S:1fe5 D:0000 DB:30 nvMxdizc |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 06, 2006 9:03 am Post subject: |
|
Great Work on fixing Secret of Evermore
Bsnes gets better every day! |
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Sun Aug 06, 2006 4:03 pm Post subject: |
|
byuu wrote: |
Game
is performing a DMA from $2180 to SRAM. I'm pretty sure I read
somewhere that this wasn't possible. But apparently, it is. The game
has actually been broken since the Krusty Super Funhouse fix. This may
or may not fix other games. |
You can't transfer from WRAM to WRAM using dma. There is nothing wrong
with transferring from WRAM to SRAM. WRAM to WRAM doesn't work because
dma is trying to read and write to WRAM in the same cycle which
obviously isn't going to work.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 06, 2006 6:03 pm Post subject: |
|
I
see, thank you. TRAC was very helpful explaining this to me as well.
Though I'm still fuzzy why the WRAM chip has pins for A0-A16+A22...
very weird, specifically the A22 pin. Anyway, since $2180 reads always
end up accessing WRAM, we can just check AAddress. Something like...
read = bbus == 0x80 && ((abus & 0xfe0000) == 0x7e0000 ||
(abus & 0x40e000) == 0x000000)) ? regs.mdr : bus->read(abus);
Obviously, other checks go in there as well. Such that DMA/HDMA regs
are blocked this way, and A bus accesses to the B bus range go to open
bus, as only carts could possibly respond to an A bus access of
$0021xx, but none do to our knowledge.
Also, I have a question Overload... in your PCB documentation you describe HiROM boards such as SHVC-1J3M-20 as :
$[00-3f]:[8000-ffff] ROM (mirror)
$[80-bf]:[0000-ffff] ROM (mirror)
Is that a mistake, where both should only map to 0x8000+?
I know 0x0000-0x1fff would be overasserted by WRAM, and 0x2000-0x5fff would be MMIO, but this is saying that:
$006000 = open bus
$806000 = ROM $006000
Is that correct? |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Mon Aug 07, 2006 12:55 pm Post subject: |
|
byuu wrote: |
Secret of Evermore is fixed. |
Another bug bites the dust.
Btw, after performing a few speed tests I've concluded speed testing bsnes would not be very useful on my system.
I set frameskip to 0 and disable speed regulation, but what happens is
that I get a steady fps decrease that doesn't have anything to do with
the game itself.
Example:
wip42 1st try with the above settings: Super Puyo Puyo 2 selection screen. Start at 80 drop progressively at 55.
2nd try Close and restart wip42 load same game. Start at 60 drop to 45...
3rd try: start at 50 drop to 35...
And then it pretty much stays there no matter how long I wait or how
often I restart b. I experience that with wip30 and 0.016 too...
Basic PC specs are 2.4ghz P4 512ram. Not sure what's causing this.
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Mon Aug 07, 2006 7:56 pm Post subject: |
|
byuu wrote: |
Also, I have a question Overload... in your PCB documentation you
describe HiROM boards such as SHVC-1J3M-20 as :
$[00-3f]:[8000-ffff] ROM (mirror)
$[80-bf]:[0000-ffff] ROM (mirror)
Is that a mistake, where both should only map to 0x8000+?
I know 0x0000-0x1fff would be overasserted by WRAM, and 0x2000-0x5fff would be MMIO, but this is saying that:
$006000 = open bus
$806000 = ROM $006000
Is that correct? |
Definately a mistake, I don't know how I missed those.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 07, 2006 9:09 pm Post subject: |
|
Ah, so it's supposed to be $[00-3f]:[8000-ffff] and $[80-bf]:[8000-ffff], right?
I assume that's pretty obvious, but just in case.
This also throws off my whole "simple memory mapper" approach. I was just mapping as:
map(bank_lo, bank_hi, page_lo, page_hi, type, start = 0);
map(0xc0, 0xff, 0x00, 0xff, ROM); //map &ROM[0] to $[c0-ff]:[0000-ffff], mirror ROM as needed
But now with the way the ROM is actually half-mirrored, I'll be forced to loop for each bank ala :
for(int i=0x00;i<=0x3f;i++) { map(i, i, 0x80, 0xff, ROM, 0x8000 + (i * 65536)); }
Which is much less... language friendly. Was trying to design all of
the memory maps using define wrappers so that any language with decent
macro capabilities could easily use them.
If it's just this one thing that uses this, I guess I could make a
special mapping mode like ROM_SHADOW or something stupid like that for
it. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Aug 08, 2006 1:20 pm Post subject: |
|
Hmm
whenever I download the wips and try to open them in winrar, I get an
unexpected end of archive error. Just checked with the latest wip link
byuu.cinnamonpirate.com/files/bsnes_v016_wip44.zip and still getting
the archive error. Am I doing something wrong?
Edit: Found a solution. Instead of downloading the zip, I can have it
opened instead and it will fully download the files that way. Very
strange error there. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 08, 2006 2:35 pm Post subject: |
|
FirebrandX wrote: |
Edit:
Found a solution. Instead of downloading the zip, I can have it opened
instead and it will fully download the files that way. Very strange
error there. |
I tried now, and I could download and decompress it just fine. I use
WinRAR as well, but there might be something wrong with your version...
Anyway, keep up the good work byuu.
Edit: Weird stuff... I was testing the wip44 with Super Mario Kart, and
I couldn't drive forward. It seems like the B button doesn't work right
during tracks (it just does during the start, but not after).
Edit 2: Looks like it's a joypad-related problem... The game works fine using the keyboard.
|
|
Kazuma New Member
Joined: 24 Jul 2006
Posts: 3
|
Posted: Tue Aug 08, 2006 3:00 pm Post subject: |
|
Stifu wrote: |
FirebrandX wrote: |
Edit:
Found a solution. Instead of downloading the zip, I can have it opened
instead and it will fully download the files that way. Very strange
error there. |
I tried now, and I could download and decompress it just fine. I use
WinRAR as well, but there might be something wrong with your version...
Anyway, keep up the good work byuu.
Edit: Weird stuff... I was testing the wip44 with Super Mario Kart, and
I couldn't drive forward. It seems like the B button doesn't work right
during tracks (it just does during the start, but not after).
Edit 2: Looks like it's a joypad-related problem... The game works fine using the keyboard.
|
WIP44 works fine here joypad or keyboard on XP. I'll test it on Vista later.
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 08, 2006 4:46 pm Post subject: |
|
I've got XP and a Saturn USB joypad. The pad has never given me any problem with any other emulator or game.
The bug happens 100% of the time. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 08, 2006 7:47 pm Post subject: |
|
Does it recognize your keypresses if you go into the input configuration screen and try and assign the button to it there? |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 08, 2006 8:01 pm Post subject: |
|
byuu wrote: |
Does it recognize your keypresses if you go into the input configuration screen and try and assign the button to it there? |
Yes. The B button also works in the menus of the game and all, as I
need to press B a couple of times before getting in a track. Then, once
in the track, I can get a super boost if I get the right timing, but
then it stops recognizing the B button no matter what.
Sorry I wasn't clear.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 08, 2006 9:22 pm Post subject: |
|
No issues with controls here. You're saying this doesn't happen on previous wips?
PS: I've noticed that it is possible to assign the same key to the same
button on both primary and secondary. It's harmless, but should proper
behavior should be to clear the other side? What about multiple key
assignments?
Last edited by FitzRoy on Tue Aug 08, 2006 9:38 pm; edited 1 time in total |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 08, 2006 9:38 pm Post subject: |
|
FitzRoy wrote: |
No issues with controls here. You're saying this doesn't happen on previous wips? |
Huh well, I dunno... The previous wip I checked didn't support SMK
properly (no DSP1 emulation). I guess the bug has always been there. I
don't even know whether that bug also occurs in other games...
I can check older wips if that could help.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 08, 2006 10:08 pm Post subject: |
|
FitzRoy wrote: |
No issues with controls here. You're saying this doesn't happen on previous wips?
PS: I've noticed that it is possible to assign the same key to the same
button on both primary and secondary. It's harmless, but should proper
behavior should be to clear the other side? What about multiple key
assignments? |
I'm not worried about assigning the same key to both buttons. It doesn't hurt anything :/
Anyway, I wanted primary and secondary so that I didn't need
overcomplicated key+joy mapping combinations packed into the same key
assignment value. Mostly to simplify SDL input support that will be
added in eventually. And I needed two so that you could use both
controller or keyboard and switch between the two without reinputting
all of your controls.
Lastly, you can make diagonals and stuff if you're clever. Eg assign q
to up+down on secondary, or w to left+right. Not quite enough to make
complicated combos, but at least enough to use the secondary inputs to
map out things like CT's "press up+left+r+start to proceed" for
keyboards, and you can map them all to the same key.
Of course, I'll probably still get hundreds of bug reports that the input is broken anyway, heh.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 09, 2006 3:16 am Post subject: |
|
You're
right, it should probably stay the way it is. I've checked other
emulators and they behave the same way. Initially, I thought it would
be harder to see a configuration mistake if you allowed duplicate
assignments.
I've been doing a lot more "5 minutes
in" tests the past two weeks, but haven't noticed any more bugs yet.
Good sign. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 09, 2006 4:32 am Post subject: |
|
Clements
had a good point about the video settings. I too had the same problem
with the fullscreen toggle not working very well when
windowed+fullscreen modes shared the same video profile when the
fullscreen video filled the entire screen.
So, I
readded the fullscreen checkbox, and now F11 checks the current video
mode, and then scans for the first video profile (0-7) that is the
opposite of the current fullscreen setting (fullscreen->windowed or
windowed->fullscreen), and sets that mode. Failing that, it just
reinitializes the current video mode again to let you know something
happened.
I'm hesitant to readd default modes again, then you run into the issue
of the default mode not being the right fullscreen setting and
confusing idiots. I figure, just make the first windowed video mode
your favorite windowed setting, and the first fullscreen the same, or
stick to Ctrl+n to switch to your video mode of choice.
Also, created InputSDL class. Now SDL port has video+input support. No
joypad support just yet, but it should be easy to add now. I just need
someone to create a unix audio wrapper for src/ui/audio, and the unix
port will have sound and speed regulation, and thus, actually be quite
useable :) |
|
Mr. Business New Member

Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
|
Posted: Wed Aug 09, 2006 7:18 am Post subject: |
|
Well,
I had a small problem in WIP42 with my buttons being assigned
conflictingly so that my start button didn't register presses, but
clearing the secondary button configuration fixed it. Conflicts appear
to be possible, to some extent. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Wed Aug 09, 2006 7:43 am Post subject: |
|
By the way, I don't know if this is a known problem, but...
ZSNES:

Snes9x:

Bsnes:

Colors are too bright and a bit off with bsnes, it seems... I'm
sensitive to this issue as I'm working on a SMK hack, and I can see the
colors I chose for my new sprites look wrong with bsnes.
SNESGT displays about the same colors as ZSNES and Snes9x, but since it
doesn't give a very clear picture (too blurry), I didn't take a
screenshot. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 09, 2006 8:15 am Post subject: |
|
I've been thinking pretty hard about how you could simplify the video settings tonight. Here's what I mocked up:
-Consider removing profiles for simplicity's sake. What kinds of users would benefit from having this feature?
-I moved aspect ratio up to a drop down box after video standard.
-I also created a separate multiplier for full screen, which then pairs
beside the windowed mode multiplier. This is because someone's full
screen setting might be higher than their desktop.
-I added resolution information after the multiplier numbers. This not
only gives the native snes res at the 1 setting, it also serves as a
nifty reference for getting things to correspond to your full screen
mode res.
-The scanline enabler checkbox was removed because I feel it is
redundant as well as strange that you would have to enable something in
one area, and set them up in another. 0% can serve as "off" and any
other setting can serve as "on"
-I reordered and reworded some things. There should probably be a
hotkey section at some point for things like F11 to be looked up.
-This can't be expressed in the mock-up, but "non-desktop" and "manual
screen render size" should be grayed out when unchecked. When "manual
screen render" is checked, it should gray out the following areas:
Multipler (Win), Multiplier (Full), and Aspect Ratio. This implies that
the two cannot coexist and makes all the interconnecting settings
easier to "take in" and think about.
Here's the mockup (visualize the drop downs paired, I just can't express it):
Video Settings
Software Filter [None, NTSC, HQ2x, Scale2x]
Hardware Filter [None, Bilinear]
Video Standard [NTSC, PAL]
Aspect Ratio [4:3, 8:7]
Multiplier (Win) [1 (256x224), 2 (512x448), 3 (768x672), 4 (1024x896),
5 (1280x1120), 6 (1536x1344), 7 (1792x1568), 8 (2048x1792)]
Multiplier (Full) [1 (256x224), 2 (512x448), 3 (768x672), 4 (1024x896),
5 (1280x1120), 6 (1536x1344), 7 (1792x1568), 8 (2048x1792)
[checkbox] Use manually defined screen render size: [597 ]x[448 ]
[checkbox] Use non-desktop resolution for full screen mode: [0 ]x[0 ]@[0 ]hz
[checkbox] Enable triple buffering (buggy, causes sound desync)
|Apply Settings|
EDIT: Apparently, I didn't understand Clement's problem as much as I
thought. That would be really cool if you could fix that.
Last edited by FitzRoy on Wed Aug 09, 2006 9:43 pm; edited 7 times in total |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 09, 2006 9:32 am Post subject: |
|
Stifu wrote: |
By the way, I don't know if this is a known problem, but...
|
It's a known problem.
In video settings disable the color curve thing.
_________________
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 Aug 09, 2006 1:26 pm Post subject: |
|
Stifu wrote: |
By the way, I don't know if this is a known problem, but...
Colors are too bright and a bit off with bsnes, it seems... I'm
sensitive to this issue as I'm working on a SMK hack, and I can see the
colors I chose for my new sprites look wrong with bsnes.
SNESGT displays about the same colors as ZSNES and Snes9x, but since it
doesn't give a very clear picture (too blurry), I didn't take a
screenshot. |
It's not a bug, it's a feature. A filter, to be precise.
The SNES uses 5 bits per color channel (Red, Green, Blue) and the PC
uses 8 bits*. ZSNES and SNES9x just fill the lowest bits with zeroes,
but the "color curve" uses the first 3 top bits again, afaik.
So "SNES white" will be "PC white" and "SNES black" will be "PC black".
Of course this doesn't take into account how your TV is set up, so it
might be still different to what you see there.
*6 bits in the old "DOS" video mode 13h.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 09, 2006 1:49 pm Post subject: |
|
creaothceann wrote: |
It's not a bug, it's a feature. A filter, to be precise.
|
Nah it's a bug 
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 09, 2006 2:28 pm Post subject: |
|
It
actually doesn't fill in the lower three bits, that relies on your
video card to do that in hardware, most do. See, it's much faster to
blit a 16-bit surface to the screen than a 24-bit one. It does fill in
the missing green bit correctly in RGB565, at least. It also filters
the lower half of the colors with a bent curve, courtesy of Overload
for the algorithm. People complained the image was too dark, so I
lowered gamma by 20% to increase brightness.
Set gamma to 1.0 and turn off the color curve if you want dull colors that don't look anything like your TV. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 09, 2006 2:47 pm Post subject: |
|
byuu wrote: |
Set gamma to 1.0 and turn off the color curve if you want dull colors that don't look anything like your TV. |
With the color curve, it doesn't look like the TV I had my SNES connected to either.
_________________
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 Aug 09, 2006 3:07 pm Post subject: |
|
byuu wrote: |
It
actually doesn't fill in the lower three bits, that relies on your
video card to do that in hardware, most do. [...] It does fill in the
missing green bit correctly in RGB565, at least. |
So you're just specifying the number of bits of the source, and the hardware does the rest?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 09, 2006 3:32 pm Post subject: |
|
Quote: |
With the color curve, it doesn't look like the TV I had my SNES connected to either. |
It looks just like my Magnavox 27" TV. If you'd like to donate your TV
to me for testing, I'll be glad to make a color profile for it as well.
Quote: |
So you're just specifying the number of bits of the source, and the hardware does the rest? |
Pretty much. It is supposed to upscale to RGB888. I'm pretty sure it does on nVidia / ATI hardware at least.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 09, 2006 4:00 pm Post subject: |
|
byuu wrote: |
Quote: |
With the color curve, it doesn't look like the TV I had my SNES connected to either. |
It looks just like my Magnavox 27" TV. If you'd like to donate your TV
to me for testing, I'll be glad to make a color profile for it as well.
|
So now we're going to have 500 TV emulation options?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Silensho Eternal Witness

Joined: 02 Aug 2004
Posts: 223
Location: I am and am not here.
|
Posted: Wed Aug 09, 2006 5:20 pm Post subject: |
|
I think byuu's proposal would be more precisely defined as "an assload of TV emulation option projects".
They wouldn't have to necessarily be succesful, as long as he gets
assloads of donated TV's. I assume he'd prefer big LCD's or similar. 
_________________
What? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 09, 2006 6:03 pm Post subject: |
|
Nah,
just two really big LCDs would be fine. Must be HDTV and do 1080p. No
projection or plasma displays, those suck and burn in.
I shall continue to fight for my color filtering support enabled by
default, rawr! It looks good, dammit, ::sobs to self::, it, looks...
good ;_;
Maybe I'll make a big popup, "Do you like washed out colors? [Yes]
[No]" when you first start the emu and no config file exists. Agreed? |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Wed Aug 09, 2006 6:50 pm Post subject: |
|
Screw
LCDs. I personally am waiting for SED TVs to come out. They're supposed
to hit end of next year, giving "the slim form factor of LCDs and
Plasma displays with the high contrast ratios, refresh rates and
overall better picture quality of CRTs. Canon also claims that SEDs
consume less power than LCD displays." (Wikipedia.org)
They also don't suffer the lamp-life problems of LCDs, or the burn-in
of plasmas and projection screens. Get a nice one, keep it for a long
time. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 09, 2006 10:05 pm Post subject: |
|
I
want an SED as well, I just hope when they release it that it doesn't
emit a whine like old tubes, or is stuck at 60hz. 120hz out of the box
would be nice. Unfortunately, I don't think there are any immediate
plans for pc monitors in this tech. It's going straight to big screens.
Probably be late 2008 at best before we see anything in America. They
keep delaying it in Japan.
More recommendations, this for the input configuration (in case anyone still cares):
-take out the "select button to update" and the horizontal divider
above it. This would look better and they're not necessary in light of
the new buttons + the next addition: make it so that the primary or
secondary text is red (possibly flashing?) when waiting for a press.
Now instead of having to read something, you understand with color.
-Add "Clear Primary" and "Clear Secondary" fields if you don't want to
clear the whole line. This would also make it more aesthetically
pleasing by having no extra space beneath the controller image.
Minor recommendation for Color settings: make "Half Gamma Adjust" "Half
gamma adjust." Making all the options follow the same capitalization
schemes looks better. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Wed Aug 09, 2006 10:17 pm Post subject: |
|
The color filtering definitely does look nice. I'd actually like to see it added to other SNES emulators.
Last edited by xamenus on Wed Aug 09, 2006 10:36 pm; edited 1 time in total |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Wed Aug 09, 2006 10:34 pm Post subject: |
|
The
color filter doesn't look that bad, but it's a bit too special, I
think. As you know, many of us didn't have such colors on TV back then.
From my personal experience, it looks almost like the scart is badly
plugged. :p |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 09, 2006 10:38 pm Post subject: |
|
Quote: |
-Consider removing profiles for simplicity's sake. What kinds of users would benefit from having this feature? |
Me, for one. I like running at 2x+aspect correct by default, but
2x-aspect is good for hires bugtracking. It's also good for making
separate modes for NTSC and PAL that work based on your own monitor
speeds. I'd rather not set refresh rate based on your currently loaded
ROM and have to "guess" what works well.
Filter modes is another good one. Do you want to go into the config
mode all the time to toggle filters? I toggle pixel and NTSC all the
time.
The only other thing I could think of would be a bunch of other
hotkeys, ctrl+n to set multiplier, ctrl+tab to toggle aspect ratio
correction, etc.
Then have both NTSC + PAL mode settings and have the emulator
reconfigure itself each time a ROM is loaded, or perhaps only if the
region changed.
-The scanline enabler checkbox was removed because I feel it is
redundant as well as strange that you would have to enable something in
one area, and set them up in another. 0% can serve as "off" and any
other setting can serve as "on"
What if you want scanlines in some modes and not in others? Another keyboard shortcut? :/
-I reordered and reworded some things. There should probably be a
hotkey section at some point for things like F11 to be looked up.
In the future, yes. And it should allow key+joy mapping to all hotkeys...
-This can't be expressed in the mock-up, but "non-desktop" and "manual
screen render size" should be grayed out when unchecked. When "manual
screen render" is checked, it should gray out the following areas:
Multipler (Win), Multiplier (Full), and Aspect Ratio. This implies that
the two cannot coexist and makes all the interconnecting settings
easier to "take in" and think about.
I can't seem to disable textboxes. When I do, it does block input, but
the boxes stay white and not gray. If they aren't gray, they don't look disabled, which is a bad thing :/
As of now, I set WS_DISABLED and call InvalidateRect(hwnd, 0, TRUE) on
the control. It works for checkboxes, but not editboxes.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 09, 2006 11:10 pm Post subject: |
|
Yeah,
definitely the scanline recommendation was dependent on profiles being
removed. The way I see it, the average user simply isn't going to need
them. Most people will set up their preferences once and keep them
there, and it is rare that they will feel like switching between ten
different resolutions and settings often enough to justify adding
profile selection, scanline checkbox, "activate this profile", etc. If
you're still intent on keeping them because you and testers personally
find them convenient, so be it. But for releases, I think "power
features" like this add a bit of unneeded confusion. I'm trying to go
against anything that could resemble a nuclear switchboard.
If you do
end up keeping them for releases, I suggest the following solution for
the scanline dilemma. Leave the checkbox out, but move the scanline
adjustment sliders to the middle of my previous "video settings"
mockup. Like this:
Progressive scanline intensity: % [slider]
Interlace scanline intensity: % [slider]
In fact, that sounds like a good idea even if you do remove profiles.
As for the not being able to gray out certain boxes- that is really
unfortunate. What about the drop drown boxes? If only those could be
grayed out, I think that would be sufficient. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Aug 10, 2006 3:47 am Post subject: |
|
On
the other hand, most users can probably just ignore the profile
feature, and set up the default profile how they want it. Works the
same as not having profiles.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 10, 2006 5:28 am Post subject: |
|
byuu
pretty much confirmed it is convenient for one kind of person: a heavy
tester who uses a filtered image for fun, but unfiltered while testing.
Not even I fall into that category, I use unfiltered all the time.
The video settings area is complicated enough as it is. Joe isn't going
to ignore it, he's going to wonder what the hell it is, and why he's on
the third one. Then he's going to dick with it needlessly until he
either figures out he doesn't need it, thinks it does something it
doesn't, or suspects it is responsible for something else not working. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Aug 10, 2006 5:38 am Post subject: |
|
byuu wrote: |
-This
can't be expressed in the mock-up, but "non-desktop" and "manual screen
render size" should be grayed out when unchecked. When "manual screen
render" is checked, it should gray out the following areas: Multipler
(Win), Multiplier (Full), and Aspect Ratio. This implies that the two
cannot coexist and makes all the interconnecting settings easier to
"take in" and think about.
I can't seem to
disable textboxes. When I do, it does block input, but the boxes stay
white and not gray. If they aren't gray, they don't look disabled, which is a bad thing :/
As of now, I set WS_DISABLED and call InvalidateRect(hwnd, 0, TRUE) on
the control. It works for checkboxes, but not editboxes. |
In vSNES I only set the color of a textbox to gray* if it contains no
text, since that's more important to me. Disabled textboxes don't look
different to enabled ones.
You could disable labels though. Normally they're black, but disabled ones are gray.
*Actually I set the "ParentColor" property to true.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 10, 2006 2:25 pm Post subject: |
|
I found the correct API call to disable textboxes, EnableWindow(HWND, BOOL);
Nice and easy. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 11, 2006 6:59 am Post subject: |
|
wip46 up. Adds all kinds of things, please test.
First, no more d3dx9_27.dll requirement to run the application, but
screenshots still work if you have any d3dx9_nn.dll files.
I specifically want to know if any of the other versions (24, 30, etc)
cause the emulator to crash when use. I'm pretty sure the function is
backwards-compatible, but we should probably make sure before I make
the next release and start getting bugreports about screenshots
crashing the program.
Note: there is no error message for failed screen captures, I'll add that in eventually.
Next, the video options finally enable/disable controls depending on
certain settings. Should make using the video options a little easier.
Next, to enable SDL audio on Windows and remove the win32 port's
wMain.hwnd reference, I now pass GetDesktopWindow() to DirectSound's
SetCooperativeLevel function, since no sound comes out if you pass a
null handle. This is because I don't know how to get the window handle
from SDL, and I prefer to keep port-specific code out of there if
possible.
Note: SDL is not a windows port, but it builds on windows, and thus needs DirectSound to output audio on windows.
I'm hoping this doesn't cause audio problems for anyone else, but
honestly I have no idea what DSound uses the window handle with
DSSCL_PRIORITY for anyway.
The $2100 luminance stuff was improved by adding rounding support to
the double-to-int casts, so fades should appear a little smoother now
in games.
Possibly fixed a bug where RTO wasn't being calculated when
brightness=0 and the screen is enabled. Didn't see any improvements in
the three known bugged games. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Aug 11, 2006 7:54 am Post subject: |
|
Wow,
this is great. I'm really glad you got those gray-outs working, it
definitely helps. There's only one thing I still voice my support for:
1. The resolutions in the multipliers- if only to avoid accidentally
going over the desktop res. Because if you set the multiplier too high,
the video window disappears and there's no way to revert back other
than deleting the cfg. Course, if bsnes could sense what your desktop
res is and prevent you from doing it at all, that would be even better.
I've already noticed what might be a possible bug: going into
fullscreen and back out again results in bsnes reverting back to
Profile 1. It didn't behave this way for me in 44.
Thanks and keep up the good work!
EDIT: Ok, I think I just realized what's going on. The fullscreen option does
go to fullscreen when you enable and apply it. And when you exit, it
reverts to the first windowed profile. So in essence, this encourages
using different profiles for full screen and windowed modes. So if
you've got windowed on profile 1 and full screen on profile 2, the
problem clements described no longer exists. This is not without
problem though. For example, if the first three profiles are full
screen enabled, the minimization bug happens. When you restart, you're
on Profile 4 where you should be.
*phew* So if I'm
understanding this now, and I think it's awesome once you do, I would
suggest halving the number of profiles and renaming them to:
Windowed 1
Full Screen 1
Windowed 2
Full Screen 2
Stupid proof, and 2 different for each would be sufficient for testers
and users, wouldn't it? And of course, the video settings would be
changed accordingly to remove the full screen option, triple buffering
from windowed modes, etc.
Any of this worth a damn?  |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Fri Aug 11, 2006 9:18 am Post subject: |
|
byuu wrote: |
wip46 up. Adds all kinds of things, please test.
First, no more d3dx9_27.dll requirement to run the application, but
screenshots still work if you have any d3dx9_nn.dll files.
I specifically want to know if any of the other versions (24, 30, etc)
cause the emulator to crash when use. I'm pretty sure the function is
backwards-compatible, but we should probably make sure before I make
the next release and start getting bugreports about screenshots
crashing the program. |
I'm using xp pro sp2. It seems to work fine with d3dx9_24 to d3dx9_30.
I swapped them out of the system32 directory and made sure to take more
then one shot with each one. Then just for the heck of it I tried
taking them all out and it still didn't crash.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 12, 2006 6:49 am Post subject: |
|
The
bug in Megaman X2's Wheelgator boss screen was due to a bug in the C4
bitplane wave opcode. Every other tile was generating gibberish. The
problem was due to incorrect loop nesting, interestingly enough.

Unfortunately, the last three bugs appear to be far more insidious than
this one. Though perhaps the most complex to fix, at least I have a
clue what's going on with Uniracers. I'm at a complete loss with MMX2
intro and RPM Racing (U). Especially since RPM Racing (J) runs just
fine.
EDIT: ok, RPM Racing, the problem with the sprites showing up as
corrupted graphics is due to initializing WRAM to 0xff. If I initialize
it to 0x55, the cars work every time. Likewise, if I initialize ZSNES
WRAM to 0xff, the car sprite bug appears there as well. I will not be "fixing" this "bug".
The game is fundamentally broken from a programming standpoint, relying
on uninitialized memory to function properly. This game is in the same
league as Death Brade and Power Drive. If you want to trip this bug on
real hardware, try turning the power on and off in rapid succession,
and you will eventually encounter errors in all three of these games.
I've no need to fake emulation to allow these games to work properly.
The official SNES documentation explains this just as I have in the
past. The WRAM values at poweron vary per console manufactured for a
variety of uncontrollable and unpredictable reasons. Furthermore, if
you turn power off, the WRAM data slowly decays over time, but only
parts of it at a time. If you turn the unit back on quickly enough,
WRAM will be mostly the same as it was when you turned the unit off.
Thus, any game relying on uninitialized WRAM can and will fail on real
hardware.
What I might be willing to do is add a special WRAM initialization
value to the cart database to allow games such as these to function.
Does anyone agree/disagree with this idea? My other idea would be to
create UPS patches for each game that overrides the reset vector with a
WRAM initialization routine, and host them on my site as bugfix patches.
The track draw problem still remains, regardless of WRAM init value. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 12, 2006 7:49 am Post subject: |
|
I agree with the special case fix idea. DB and PD as well if they apply. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sat Aug 12, 2006 8:47 am Post subject: |
|
byuu wrote: |
What
I might be willing to do is add a special WRAM initialization value to
the cart database to allow games such as these to function. Does anyone
agree/disagree with this idea? |
I do.
I wouldn't go for the patch idea.
|
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Aug 12, 2006 9:12 am Post subject: |
|
Maybe
those special cases could also show a little popup on screen or in the
screen stating that this game has bugs that happen on the real console,
but is patched through the database so the game works.
This way we will know that the game has a fix in the database,
The ips on your site would also be a good idea, but less easy to use
I'm Wondering if this will be possible:
2 directories
1 for roms
1 for ips
if the ips and rom name match, bsnes automatically applies the ips file
to the rom, if no ips is found bsnes runs the clean rom |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Aug 12, 2006 9:24 am Post subject: |
|
I'm also for patches. And I think initialising all the RAM areas to random values would help the PD scene. 
EDIT: Unless they use it as a random generator. 
_________________
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: Sat Aug 12, 2006 11:01 am Post subject: |
|
I
just read on Haze's blog that there are some plans to redump genesis
and maybe also other systems like snes. The plans are to dump each
individual chip instead of a romdump via the pins on the cart, this
could also result in a full dump of the dsp's removing the need for
fully emulating them
intersting |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Aug 12, 2006 12:05 pm Post subject: |
|
byuu wrote: |
The
bug in Megaman X2's Wheelgator boss screen was due to a bug in the C4
bitplane wave opcode. Every other tile was generating gibberish. The
problem was due to incorrect loop nesting, interestingly enough.
Unfortunately, the last three bugs appear to be far more insidious than
this one. Though perhaps the most complex to fix, at least I have a
clue what's going on with Uniracers. I'm at a complete loss with MMX2
intro and RPM Racing (U). Especially since RPM Racing (J) runs just
fine.
EDIT: ok, RPM Racing, the problem with the sprites showing up as
corrupted graphics is due to initializing WRAM to 0xff. If I initialize
it to 0x55, the cars work every time. Likewise, if I initialize ZSNES
WRAM to 0xff, the car sprite bug appears there as well. I will not be "fixing" this "bug".
The game is fundamentally broken from a programming standpoint, relying
on uninitialized memory to function properly. This game is in the same
league as Death Brade and Power Drive. If you want to trip this bug on
real hardware, try turning the power on and off in rapid succession,
and you will eventually encounter errors in all three of these games.
I've no need to fake emulation to allow these games to work properly.
The official SNES documentation explains this just as I have in the
past. The WRAM values at poweron vary per console manufactured for a
variety of uncontrollable and unpredictable reasons. Furthermore, if
you turn power off, the WRAM data slowly decays over time, but only
parts of it at a time. If you turn the unit back on quickly enough,
WRAM will be mostly the same as it was when you turned the unit off.
Thus, any game relying on uninitialized WRAM can and will fail on real
hardware.
What I might be willing to do is add a special WRAM initialization
value to the cart database to allow games such as these to function.
Does anyone agree/disagree with this idea? My other idea would be to
create UPS patches for each game that overrides the reset vector with a
WRAM initialization routine, and host them on my site as bugfix patches.
The track draw problem still remains, regardless of WRAM init value. |
At the risk of exasperating some people... I don't get it: What are the
initial WRAM values of a real Snes, and wouldn't it be simpler to just
go along with these in bsnes?
Are you saying the values differ between each Snes units, or at each new power on?
edit: Of course, I do think that bugs that appeared on the real console
should appear in emulators as well. But I didn't quite get if the RPM
racing bug does or not.
Last edited by Dmog on Sat Aug 12, 2006 2:52 pm; edited 3 times in total
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Aug 12, 2006 12:19 pm Post subject: |
|
tetsuo55 wrote: |
I
just read on Haze's blog that there are some plans to redump genesis
and maybe also other systems like snes. The plans are to dump each
individual chip instead of a romdump via the pins on the cart, this
could also result in a full dump of the dsp's removing the need for
fully emulating them
intersting |
Where is that? Browsing his blog I didn't see any mention of it.
He just released a Megadrive only Mame derivative. Looks to be progressing pretty well.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Aug 12, 2006 1:39 pm Post subject: |
|
http://haze.mameworld.info/2006/08/11/hazemd-001a/
Quote: |
here
has been talk on the MESS list of using fixed sets in MESS, so this
could very well end up in MESS directly (although Guru wants to redump
things one file per chip).
Posted by: almightyjustin at August 12, 2006 7:25 am |
http://haze.mameworld.info/2006/08/11/hazemd-002a/
Quote: |
referring to your last comment in the previous post (about the fixed roms): we agree that this is a pain in the ass!
snes emus developer has the help from nsrt (a wonderful tool nach
developed) to single out verified dumps, but other console has no such
a tool…
this reflect in thousands of false bug reports due to corrupted roms used (and this is true for nes, md etc.)
well, maybe this could be the right moment to solve this issue!
the maintainer of genesiscollective has a huge cart collection for
genesis, and cowering has an almost complete USA NES collection… would
it maybe be possible to convince them to re-dump things as they should?
with different chips in different roms, all zipped up?
starting from such huges collections, it would be possible to start
with good base sets (two complete US game collections for two of the
more popular consoles) and it would be easier to convince emu developer
to support it!
the big failure of a format as UNIF (on the nes side) was that nobody
tried to convert old dumps from iNES format and hence the new (not
perfect but better than the previous) format never had success…
well, maybe i'm only dreaming…
anyway many thanks, i'll try the emu as soon as possible!
Posted by: etabeta at August 12, 2006 7:29 am |
And yeah his megadrive/genesis driver rewrite is simply awesome.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sat Aug 12, 2006 5:06 pm Post subject: |
|
Dmog wrote: |
At the risk of exasperating some people... I don't get it: What are the
initial WRAM values of a real Snes, and wouldn't it be simpler to just
go along with these in bsnes?
Are you saying the values differ between each Snes units, or at each new power on?
edit: Of course, I do think that bugs that appeared on the real console
should appear in emulators as well. But I didn't quite get if the RPM
racing bug does or not. |
...Are you incapable of reading (this wouldn't surprise me AT ALL)? He says it right there!
byuu wrote: |
The WRAM values at poweron vary per console manufactured for a variety of uncontrollable and unpredictable reasons.
Furthermore, if you turn power off, the WRAM data slowly decays over
time, but only parts of it at a time. If you turn the unit back on
quickly enough, WRAM will be mostly the same as it was when you turned
the unit off. Thus, any game relying on uninitialized WRAM can and will fail on real hardware. |
Go back to school please, Dmog.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Sat Aug 12, 2006 8:47 pm Post subject: |
|
Metatron wrote: |
Go back to school please, Dmog. |
Don't get him started.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Aug 12, 2006 9:09 pm Post subject: |
|
xamenus wrote: |
Metatron wrote: |
Go back to school please, Dmog. |
Don't get him started.
|
_________________
FF4 research never ends for me.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sat Aug 12, 2006 11:58 pm Post subject: |
|
-quote of dmog heer-
It should stay deleted
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 13, 2006 1:02 am Post subject: |
|
I don't have the game so I can't determine how often it happens on the real system, but I'm certain the bug can be triggered.
Anyway, the point is this. In an emulator, the WRAM init value is
always going to be the same. I'd love to make it initialize to rand(),
but then you have a problem with games that rely on those anyway. Sort
of the same reason ZSNES can't do netplay and has some sporadic movie
recording issues: you don't want randomness in an emulator. I'm going
to stick with 0xff. I don't see much difference between 0x00 and 0xff
initialization values, but always using 0x55 because it just so happens
to work with all of the commercial games we're aware of (excluding BS-X
games), is, quite simply, a hack.
And adding this to the database is a hack as well. I'll just include a
readme from now on with bsnes v0.017+ explaining that these three games
have problems and why, and that it has nothing to do with emulation
accuracy. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Aug 13, 2006 2:01 am Post subject: |
|
Not
too sure if you'd like this idea byuu, but it's only a suggestion.
Maybe add an option in the gui or a command line switch to change the
wram to 0x55. Then since you'd probably never use it, just leave it off
by default. It keeps your database clean and you don't have to make any
specific game patches. Eh though I guess if you wanted it to be user
friendly the database idea would probably work better. Either way
they're all hacks I guess. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Aug 13, 2006 4:00 am Post subject: |
|
funkyass wrote: |
It should stay deleted |
I concur.
_________________

<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: Sun Aug 13, 2006 5:29 am Post subject: |
|
tetsuo55 wrote: |
Maybe
those special cases could also show a little popup on screen or in the
screen stating that this game has bugs that happen on the real console,
but is patched through the database so the game works.
This way we will know that the game has a fix in the database,
The ips on your site would also be a good idea, but less easy to use
I'm Wondering if this will be possible:
2 directories
1 for roms
1 for ips
if the ips and rom name match, bsnes automatically applies the ips file
to the rom, if no ips is found bsnes runs the clean rom |
I'm sure eventually bsnes will get a "Paths" area in the configuration
for people to define their own destinations for saves, patches, roms,
special bios', etc.
As for patches vs discreetly "fixing" them, I'm not opposed to either.
I don't like an option, because it doesn't fit with any current
configuration area, and a popup is annoying compared to just saying
something in a readme file. My rationale is that whenever there is an
attribute of randomness at work, one should always take the optimum
case and emulate that. If that means hacks, so be it. I think the word
itself is scaring people from believing that this could be an
appropriate use for them.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 13, 2006 6:03 am Post subject: |
|
May
I request the car sprite graphics bug in RPM Racing be removed from the
buglist since it is due to the game relying on uninitialized WRAM
variables? If everyone else prefers, I will go against my personal
judgment and initialize WRAM to 0x55, though I really don't want to.
That brings us down to three issues:
1) Mega Man X2 - Jonas Quinn recently noticed the same assembly line
bug exists in SNES9x' C port of the Cx4 code. Appears to be a bug with
op00-00 OAM table building code. When this is corrected, I can backport
the changes into bsnes and MMX2 should no longer have any known bugs.
2) Uniracers - Will require me to start deciphering mid-frame OAM
address invalidation. A very involved and complicated process. This
requires use of my copier, so I can only work on this one with my
extremely limited free time at home. Don't expect this bug to be fixed
any time soon.
3) RPM Racing - Track draw issues. This is the only known bug now where
I have absolutely no idea what the hell is going on. My plan of attack
is going to be dumping logs of register values between the U and J
versions of the game. Perhaps the U version is relying on uninitialized
registers being a certain value as well? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Aug 13, 2006 6:13 am Post subject: |
|
Done.
Did you and kick ever do those PAL tests btw? |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sun Aug 13, 2006 6:22 am Post subject: |
|
byuu wrote: |
If everyone else prefers, I will go against my personal judgment and initialize WRAM to 0x55, though I really don't want to. |
Honestly, I'd think an option would be the best solution. Default it to
whatever you want, but add a checkbox option to initialize it to 0x55.
That should make everybody happy except super-hardcore zealots on both
sides. Besides whatever GUI changes you'd need to make (which I imagine
is WAY easier to do in bsnes than in ZSNES), it sounds like a simple
'if/else' statement the way it's been put (I'm getting the strong
implication you just need to change one setting to go from 0xff to
0x55). Think of it as a filter if that helps.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 13, 2006 7:23 am Post subject: |
|
Byuu
if you make an ips patch, does that mean the game will work normally on
all emulators(excluding those maybe that have a special hack for the
game) and on the real snes every time? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 13, 2006 7:45 am Post subject: |
|
Thanks :)
Quote: |
Did you and kick ever do those PAL tests btw? |
Nope, I forgot about writing them. Maybe I can dig up anomie's dot
timing test, that would be a great start at least.
Quote: |
Besides whatever GUI changes you'd need to make (which I imagine is WAY easier to do in bsnes than in ZSNES |
Definitely :)
I guess I can hide it in the config file to let you specify anything
from 0x00 to 0xff. Perhaps I'll even add some supersecret options to
initialize WRAM to rand() [all the same byte] or rand() [every byte
random], for the purposes of homebrew development.
Quote: |
Byuu
if you make an ips patch, does that mean the game will work normally on
all emulators(excluding those maybe that have a special hack for the
game) and on the real snes every time? |
Yes, a patch would make the game work on all emulators regardless of
WRAM init value. However, every other SNES emu just initializes WRAM to
0x55. On the bright side, it would make triggering the bug impossible
when played on a copier, at least.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 13, 2006 7:48 am Post subject: |
|
In
that case i say go for the IPS patch, and state it in the documentation
and on your site, you could even include the IPS in the bsnes zip.
That would solve the whole problem once and for all
When you get those pal tests ready ill pop them in to my snes and send you the results |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Aug 13, 2006 8:20 am Post subject: |
|
Oops, wasn't kick, it was tetsuo.  |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Aug 13, 2006 7:48 pm Post subject: |
|
I
don't claim responsibility because I don't have the power, but the
reason for the posts being deleted is probably because of excessive
stupidity due to byuu already explaining his point.
After all, being stupid on any internet forum is just never tolerated in the first place...
_________________
FF4 research never ends for me. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Aug 13, 2006 8:33 pm Post subject: |
|
-quote of x-user-d/Dmog deleted-
"ok"
I would have loved to be responsible for removing those posts. Alas, I am not.
_________________
FF4 research never ends for me. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Aug 13, 2006 8:43 pm Post subject: |
|
and yes that was me deleting the posts
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Aug 14, 2006 12:39 pm Post subject: |
|
byuu wrote: |
I don't have the game so I can't determine how often it happens on the real system, but I'm certain the bug can be triggered.
Anyway, the point is this. In an emulator, the WRAM init value is
always going to be the same. I'd love to make it initialize to rand(),
but then you have a problem with games that rely on those anyway. Sort
of the same reason ZSNES can't do netplay and has some sporadic movie
recording issues: you don't want randomness in an emulator. I'm going
to stick with 0xff. I don't see much difference between 0x00 and 0xff
initialization values, but always using 0x55 because it just so happens
to work with all of the commercial games we're aware of (excluding BS-X
games), is, quite simply, a hack.
And adding this to the database is a hack as well. I'll just include a
readme from now on with bsnes v0.017+ explaining that these three games
have problems and why, and that it has nothing to do with emulation
accuracy. |
I disagree here. I don't think it's a hack at all. Yes, these games
have poor programming practices, however they rely on the fact that
GENERALLY, WRAM is 0x55 in MOST cases. Wouldn't it be more closely
emulating the system by using 0x55? That is the value WRAM initializes
to the MOST.
It sounds dumb to me use another value and then call the value most
frequently found on the actual hardware to be a hack. That defies my
logic.
Even if you DID use Rand(), to be REALLY accurate, you'd want to make
it so 0x55 came up MORE times than other values because that's what
seems to effectively happen on the real hardware.
These games work the majority of the time on the real hardware. If they
NEVER work on BSNES, you have failed to meet that goal in my opinion.
Those are overly strong words for such a minor issue, but you get the point.
_________________
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.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 14, 2006 2:14 pm Post subject: |
|
I'd
love to see proof that the default WRAM value is more frequently 0x55
than any other value. As I said though, I'll go against my better
judgment and use 0x55 if that's what everyone else prefers. |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Mon Aug 14, 2006 2:37 pm Post subject: |
|
Well, is there a tangible benefit to making it anything but 0x55? I.E., does setting this value to 0x55 break anything?
If not, and there's a benefit with no penalty, logic clearly dictates that it should be 0x55.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Aug 14, 2006 2:54 pm Post subject: |
|
It
seems to me that the only real way to get proof of that is starting RPM
Racing a thousand times and seeing how often it works.. but that might
not be very realistic. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Aug 14, 2006 4:33 pm Post subject: |
|
Another
brilliant idea would be to write a test program that samples the
contents of WRAM on startup, then power cycle repeatedly to see if you
can get any other results. Preferrably an automated system where the
test program can report results to an external device, and the external
device power cycles the system for a random duration upon test
completion. Have fun with that. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Aug 14, 2006 9:17 pm Post subject: |
|
Yes. I forgot for a moment that you could. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Aug 14, 2006 9:52 pm Post subject: |
|
Although
it seems that it would require a flash cartridge or other custom setup,
as most copiers erase the WRAM on startup. I wouldn't be surprised if
there were copiers that also mess with the SPC to play sound effects
and/or music. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 15, 2006 6:20 am Post subject: |
|
As soon as someone donates a flash cart to me, I will verify this, as well as PPU/APU/etc power/reset values, once and for all.
FreeBSD apparently treats malloc differently than Win32/Linux. FreeBSD
modifies the size argument on the stack. Example:
Code: |
mov edx,65536
push edx
call malloc
pop edx
;edx != 65536 |
Solution :
Code: |
mov edx,65536
push edx
push edx
call malloc
add esp,4
pop edx
;edx == 65536 |
Result :
http://byuu.cinnamonpirate.com/images/desktop081506.jpg
Linux/FreeBSD port is working. Lots of warnings to work out, though.
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Aug 15, 2006 7:54 am Post subject: |
|
Is
that video in mplayer dnagel? That was an okay series. Er anyway thanks
for making a linux/bsd port of it. I don't use it nearly as much as I
do windows, but it'll be nice to have. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Aug 15, 2006 12:23 pm Post subject: |
|
byuu wrote: |
I'd
love to see proof that the default WRAM value is more frequently 0x55
than any other value. As I said though, I'll go against my better
judgment and use 0x55 if that's what everyone else prefers. |
I assume the proof to be the fact that this commercial game was 1.)
released and 2.) people played it without issue as there is nothing
that says otherwise.
I wouldn't imagine a company would release a game it didn't test to at least work when they tested it.
Number 2 is weak and could use confirmation though.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 15, 2006 2:29 pm Post subject: |
|
Quote: |
Is that video in mplayer dnagel? That was an okay series. |
Yes. I was going to use a screenshot from Condor Heroes, but I figured
it just wouldn't be a Linux mplayer screenshot without anime playing.
Ok series. Cute, but not too great on plot. I've found two series I've
really liked thus far. Fushigi Yuugi and Houshin Engi.
Quote: |
I
assume the proof to be the fact that this commercial game was 1.)
released and 2.) people played it without issue as there is nothing
that says otherwise. |
Many games are released with sporadic bugs. The biggest problem with
using 0x55 is it makes these games work every time you power on the
system. I don't believe that is correct behavior. Even if 0x55 happens
90% of the time, that's not correct emulation to have the game work
100% of the time.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 15, 2006 4:32 pm Post subject: |
|
Team neo is working on a new flash card, that will run any rom, it should act like a regular game |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 15, 2006 5:23 pm Post subject: |
|
tetsuo55 wrote: |
that will run any rom |
Apart from special chip ROMs, heh ? :\
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 15, 2006 7:49 pm Post subject: |
|
they claim it runs everthing except FX |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Aug 15, 2006 8:37 pm Post subject: |
|
tetsuo55 wrote: |
they claim it runs everthing except FX |
If FX is not possible, I'm pretty sure SA-1 won't work either.. and
that's the only chip that demands lots of power.
_________________
FF4 research never ends for me.
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Aug 15, 2006 9:48 pm Post subject: |
|
byuu wrote: |
but I figured it just wouldn't be a Linux mplayer screenshot without anime playing. |
Haha, how true. You should of made it Evangelion just because.
byuu wrote: |
Yes.
I was going to use a screenshot from Condor Heroes, but I figured it
just wouldn't be a Linux mplayer screenshot without anime playing. Ok
series. Cute, but not too great on plot. I've found two series I've
really liked thus far. Fushigi Yuugi and Houshin Engi.
|
Who doesn't like Fushigi Yuugi. That was a great series if you ask me.
It was neat because I'd never seen any anime that used a setting in
ancient china at the time. The whole idea of the book reminded me of
the movie the neverending story in way. I'm not too big on folklore so
that's the only thing I could think of to comapre it to. Ah I wasn't
really expecting the two friends to be enemies either.. that kind of
sucked since I liked both of the characters. Oh do you watch anything
else? Like mecha anime or horror?
Edit: I shouldn't derail your bsnes topic. Sorry, I'll chat about this some other time.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Aug 16, 2006 3:16 pm Post subject: |
|
byuu wrote: |
Quote: |
I
assume the proof to be the fact that this commercial game was 1.)
released and 2.) people played it without issue as there is nothing
that says otherwise. |
Many games are released with sporadic bugs. The biggest problem with
using 0x55 is it makes these games work every time you power on the
system. I don't believe that is correct behavior. Even if 0x55 happens
90% of the time, that's not correct emulation to have the game work
100% of the time.
|
Yeah, but how far do you intend to take it? Are you going to turn your
unit on and off 1000 times, record the values and precentages of
frequency values come up and make your emulator mimic that? That sounds
a little mad/obsessive to me. However, that just may be you. 
I suppose the best idea is to gather some data before making a decision
about this. At this point, it's just speculation until we can see what
does happen.
Also, when you do your power cycling, I would do tests with quick
cycling and slow cycling ie 30 seconds or 1 minute apart. I'd imagine
the values in WRAM will differ with allowing the SNES substantial time
to discharge. Since WRAM requires such little voltage and power to
maintain it's data, it may not lose it's data for several seconds or it
may still retain SOME of the bits if the cycle is turned back on too
quickly.
Manufacturers generally claim an UNKNOWN state at startup(which you'd
expect), but in practice with systems I've worked with at work, I have
observed the values of RAM tend to generally see the same numbers many
times at startup. It's absolutely foolish to rely on this no doubt, but
it seems to be an interesting anomoly that occurs.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 16, 2006 4:30 pm Post subject: |
|
I
agree, there's definitely precedence for there being general proximity
values at startup. The biggest problem is if every emulator initializes
to 0x55, and then some homebrew programs rely on WRAM being 0x55 (eg to
determine if the emulator was powered on or reset, rather than using a
WRAM key). We're basically saying, "WRAM is always
0x55 on poweron", which isn't the case. I've tried pretty hard up until
recently to not add speculative changes just to fix games, but this is
one thing I cannot test personally.
But then,
supposedly this has been somewhat tested and the value is usually 0x5n
(n being anything). And I have to use a fixed value every time or I
make movies impossible due to "randomness" issues.
Quote: |
Yeah,
but how far do you intend to take it? Are you going to turn your unit
on and off 1000 times, record the values and precentages of frequency
values come up and make your emulator mimic that? |
While theoretically possible (log timestamps of accesses to games and
decay WRAM based on how recently you used poweron), I think that's a
bit too extreme even for me. We do have to realize we're working with
computers and make some concessions sometimes. But that works both
ways, so I need to keep trying to emulate every detail I can, while
conceding only when necessary.
But, for now, the newest WIPs initialize WRAM to 0x55, SRAM to 0xff. I
might as well add the SPCRAM patterned-init while I'm at it...
everything else does 0x00 for VRAM, OAM and CGRAM, so unless I hear
otherwise, that should cover every significant memory init.
Quote: |
Oh do you watch anything else? Like mecha anime or horror? |
Definitely not those two genres. I watch maybe one series every 3-6
months. Mostly a matter of being too busy doing other things to watch
TV. I kind of wish they'd subtitle the Chinese stuff too for us
monolinguals. The Condor series looks awesome as hell :/
(obligatory mplayer condor heroes screenshot here)
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 16, 2006 7:48 pm Post subject: |
|
Yeah all TVB releases should be english subbed  |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Thu Aug 17, 2006 12:18 am Post subject: |
|
byuu wrote: |
Definitely not those two genres. I watch maybe one series every 3-6
months. Mostly a matter of being too busy doing other things to watch
TV. I kind of wish they'd subtitle the Chinese stuff too for us
monolinguals. The Condor series looks awesome as hell :/
(obligatory mplayer condor heroes screenshot here) |
Nice. My friend said he wanted to show me the 1990ish version of condor
heroes. He liked that version better since the actors were better
looking. Lol I don't know about the acting quality, but I guess the
whole story is still there. It's going to be a pain having him
translate while it's going on though. I saw some parts of the book were
translated so I might just go ahead and read those before hand. What I
should really do is learn some cantonese so I can watch all those
kung-fu dramas that he likes. I'm sure he'd be more willing to show me
other stuff too.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 17, 2006 5:37 am Post subject: |
|
New
mirror function. This one mirrors an offset, rather than mirroring the
entire ROM. Before, I was having reallocate a 40mbit ROM (Dai Kaijuu
Monogatari II for instance) to a 64mbit ROM, losing 3MB of RAM. Now I
take advantage of my page table lookup, and use the below routine. Same
speed, but less RAM usage.
Code: |
uint mirror(uint size, uint pos) {
if(size == 0)return 0;
if(pos < size)return pos;
uint mask = 1 << 31;
while(!(pos & mask))mask >>= 1;
if(size <= (pos & mask)) {
return mirror(size, pos - mask);
} else {
return mask + mirror(size - mask, pos - mask);
}
} |
Code is public domain if anyone wants it.
Example:
for(int i = 0; i < 32; i++) { printf("%x", mirror(11, i)); }
Output:
0123456789aa89aa0123456789aa89aa
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Thu Aug 17, 2006 5:55 am Post subject: |
|
byuu wrote: |
But then, supposedly this has been somewhat tested and the value is usually 0x5n (n being anything). |
Rather, n being any combination where bits 0 and 1 are not equal, and
bits 2 and 3 are also not equal. 5, 6, 9, and A all fit that
requirement.
byuu wrote: |
And I have to use a fixed value every time or I make movies impossible due to "randomness" issues. |
Or, like, you can record the initial state in the movie, and then not
worry about future changes to the emulator which affect power on state
breaking existing movies, or possibly playing the movie in another
emulator which has its own inconsistent power on state.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 17, 2006 6:24 am Post subject: |
|
Before anyone reports this and annoys me :

This is not a bug in bsnes. The line of "gibberish tiles" under the
text line is due to initializing WRAM to 0x55. ZSNES has the same
"problem". Copiers almost always initialize WRAM to 0x00, which is why
the demo works there.
Quote: |
or possibly playing the movie in another emulator which has its own inconsistent power on state. |
A movie would never play between two emulators, unless both were
virtually bit-accurate to a real SNES. Otherwise, the movies would
desync.
Yes, I could just record the initial state. I suppose I'll put off
movies until I have savestate support, then. That way I can just save
the poweron state into the movie, or allow the move to start recording
anywhere.
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Thu Aug 17, 2006 7:00 pm Post subject: |
|
byuu wrote: |
I
managed to get the DirectDraw overlay up. Supposedly overlays with GDI
and D3D are impossible. You can rig up a hybrid by creating the
surfaces through DD and attaching them via D3D, though.
So, I of course can't get an RGB overlay because video card manufacturers are lazy assholes D:<
Supposedly UYVY is supported on every card under the sun now. But it's
near impossible to render a UYVY image in DirectDraw :/
The format is supposedly :
byte[U] byte[Y] , byte[V] byte[Y]. The idea is you get a full 8-bit Y
sample every pixel, and one U or V sample every other byte. The video
card just shares the U+V between the two pixels.
Already unusable to me. But I can't even get anything to display using
only the Y channel. The video should be grayscale, but instead is
completely psychotic colors. I know my Y calculation is correct, and
I've tried putting the Y on the low byte and high byte of each pixel to
no avail.
Now then, take a look at Winamp and it's advanced visualization studio.
Enable the overlay option and it works fantastically. I'm certain they
aren't actually rendering in UYVY or whatever. Somehow, it has
to be possible to blit an RGB565 image to a UYVY overlay surface and
have the hardware do the conversion for you, but damned if I can figure
out how to do so 
Failing all of that, it would at least be nice if there were a way to
prevent other always on top apps from screwing with your fullscreen
mode DD / D3D video modes without being forced to redraw 100% of the
screen every single page flip.
The lack of code / documentation on the internet for RGB<>UYVY
conversion, or just using overlays in general is astounding. |
Maybe you can get some help from the guy that made VirtualDub. He seems
to *really* know his way around the ins and outs of D3D and video cards
and RGB<>UYVY... http://www.virtualdub.org/oldnews
From his contact page...
http://www.virtualdub.org/contact
Quote: |
Things you SHOULD contact me about:
Coding problems. If you have a programming question related to
VirtualDub, ask. Please keep discussions to either abstract algorithms,
assembly, or C/C++; I have little interest in Visual Basic. Feel free
to request dual-licensing of select pieces of code; I will, however, be
free to say no if I feel your request is unfair.
|
While what you want to do isn't related to VirtualDub per-se, it's
something he happens to know a lot about and maybe he'd be inclined to
help out.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 17, 2006 9:16 pm Post subject: |
|
His
software is far more valuable than mine, I'd prefer not to waste his
time with my boring questions. Luckily, non-overlays work good enough
99% of the time, I just need to find a better way to keep the black
borders of the display clear is all. Maybe a "clear entire window every
60 frames" option. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 18, 2006 6:44 am Post subject: |
|
Ok, I was finally able to get an output buffer to render on with unix.
This uses GTK+, and also has a menubar. Problem is, it's slow. The
pixel fill loop gets ~1950 fps, whereas when blitting the pixelbuffer
to the screen, performance drops sharply to ~480 fps. I think part of
the problem is that GDK pixbufs are forced to be 24bpp, and there's
conversion from GdkPixbuf to GtkImage, and then GtkImage to the video
card. Too many costly translations involved.
If anyone knows more about GTK+ (specifically using gtkglext or
gtkgllib), I'd appreciate help in speeding this up. If I can get a
superfast blitter working, especially with scaling, I'll make a
full-fledged unix port, complete with working menu options, UI, etc.
http://byuu.cinnamonpirate.com/temp/test.cpp
(compiles with g++ test.cpp -o test `pkg-config --cflags --libs gtk+-2.0`) |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Aug 18, 2006 7:27 pm Post subject: |
|
Be
aware that GDK is also using software scaling. If you want to do
hardware scaling you will have to go with something like Xv overlays,
it's pretty much the only option for hardware scaling besides OpenGL. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 18, 2006 9:06 pm Post subject: |
|
I'm
going to implement this very modularly. I'll create a generic
GtkDrawingArea box for the video output, and have multiple hooks to it.
I think I know how to hook SDL to the DrawingArea now (set SDL_WINDOWID
environment variable), and it looks like I can save a step and use
GtkDrawingArea + GdkRGB to get a little closer to hardware. Probably
won't help much. Then later I can add SDL-GL support.
I'm very interested in Xv. Do you know where I can find a tutorial /
minimial example to get an Xv display up? I intend to use
GDK_WINDOW_XWINDOW(mydrawingarea)->window (native X window handle)
to draw Xv data on.
EDIT: hmm, supposedly I can use overlays in SDL and have it fall back
on Xv / XVideo... works on Windows, too. Imagine that, SDL actually can
do hardware scaling, you just have to convert your video from RGB to
YUV first.
pagefault, I don't suppose you ever figured out an efficient algorithm
for doing that? It's always eluded me in the past, despite
understanding how to convert RGB<>YUV, and how the packed format
works. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Aug 20, 2006 8:51 am Post subject: |
|
byuu wrote: |
Linux/FreeBSD users will like this 
|
Not if that file open menu is the buggy GTK one.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 20, 2006 6:13 pm Post subject: |
|
It
has its issues, but it isn't buggy AFAIK. I fixed the dialog when you
hit ok or cancel to merely hide rather than destroying itself, so that
it remembers what folder you were in. But clicking on the X kills the
window even if you override the destroy event. Meaning you get to start
back at your startup path the next time you open the box. I'm not
aware of any alternative GTK+ file open dialogs included with the base
library. Though I suppose I could always write my own with enough
patience and stick the folders and files in the same window like they
should be.
Personally, I like QT's more, with the exception of the default
one-click-activation thing. But I don't know how to program for QT.
I should revise my statement: half of Linux/FreeBSD users will be happy
with the new interface, and the other half can compile the GTK+-free
pure SDL port with no UI at all. Still, broken or not, I think an ugly
file open dialog box beats out no file open dialog box at all. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Sun Aug 20, 2006 7:29 pm Post subject: |
|
If
you can actually get it going fast in an all-in-one window like that
it'd be cool. I normally just punt and have the GUI separate from the
emulator output (GTK or Qt for the UI, SDL for the output) but it'd be
nice for my NEStopia port if I could make it "one piece" like the Win32
original 
BTW, it's confirmed by 20+ years of GUI studies that files and folders
should be in separate windows and that it's much faster to navigate
that way. Changing that in Win95 remains Microsoft's biggest crime
against usability
I haven't actually tried making it remember the path yet, but doing a
getcwd() in the destroy handler for the requester and a chdir() to that
value before you start it should help it's memory. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Aug 20, 2006 7:41 pm Post subject: |
|
byuu wrote: |
Personally, I like QT's more, with the exception of the default one-click-activation thing.
|
It defaults to your KDE settings. So if it's single click for you, you
have KDE (or KDE some libs) set to single click. When I installed KDE I
told the install Wizard I like Redmond GUI style and it's all double
click for me.
byuu wrote: |
I should revise my statement: half of Linux/FreeBSD users will be happy
with the new interface, and the other half can compile the GTK+-free
pure SDL port with no UI at all. Still, broken or not, I think an ugly
file open dialog box beats out no file open dialog box at all. |
I'll be happy if I can easily type in the directory. So if you still have loading via command line great.
Arbee wrote: |
BTW, it's confirmed by 20+ years of GUI studies that files and folders
should be in separate windows and that it's much faster to navigate
that way. Changing that in Win95 remains Microsoft's biggest crime
against usability |
My 12+ years of GUI using has proven that the fastest navigation (for
me anyway) is typing in the directory and having a good auto complete.
I love the Windows one because it allows me to type it in, same reason
why I love the Qt one, and the auto complete is excellent.
The GTK one just seems horribly broken, as I'm typing it in, the
autocomplete when it uses it seems to just screw it all up.
_________________
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 Aug 20, 2006 10:11 pm Post subject: |
|
I
may have finally found a new bug. Space Football (U) is crashing the
emulator after starting a new game. The game works in .016 official.
Will wait for confirmation.
Regarding the folder
navigations... they're both ridiculously easy. And you can type the
start of the rom name in both. I will say this though... spaces between
entries on the list? Sorry, but score 1 for Redmond on that one. It
does not make things easier to see, and it needlessly decreases the
effectiveness of the scrollbar. A list of files is not a term paper. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 2:29 am Post subject: |
|
FitzRoy wrote: |
I
may have finally found a new bug. Space Football (U) is crashing the
emulator after starting a new game. The game works in .016 official.
Will wait for confirmation. |
Wow. That was a really hard one to fix. The initial reason this bug
appeared was because I started rendering when display_disabled == false
&& display_brightness == 0. It was crashing because
bg_tiledata_state[COLORDEPTH_256] was being overwritten. This variable
was being overwritten because I set regs.hires = (regs.bg_mode == 5 ||
regs.bg_mode == 6) immediately when the MMIO reg $2105 is written to. I
set line.width according to (regs.bg_mode == 5 || regs.bg_mode == 6) ?
512 : 256 during PPU::scanline(), and then rely on that variable during
PPU::render_scanline(), which is of course called later on. This game
was changing regs.bg_mode from 5/6 to 0 between these two points, and
the BG renderer was then rendering 512 pixels to the pixel_cache
buffer. Problem was that since regs.hires was now false, but line.width
was 512, it was writing past the end of the pixel_cache by 256 pixels,
screwing up all of the memory after pixel_cache[256] { ... }. If
regs.hires were true, it would've halved x before writing to the cache
(and alternated between updating the main pixel cache and sub pixel
cache instead). Took forever to track down this bug because MSVC's
debugger was giving me all kinds of useless information, crashing at
completely different code parts, etc.
I fixed this by removing the transient variables line.width and
regs.hires, and instead hardcoded their calculations into the routines
that need them, so that their values are always current.
Anyway.

Also, thank anomie for this bugfix, and Nach for telling me where to
get the codefix from. I had no hand in fixing this bug.

RPM Racing continues to elude me. The J version does not use hires(!!),
which is why it works fine. The U/E versions look fine. VRAM is the
same for BG1 tiledata + tilemap as in ZSNES, and all PPU registers are
identical to Super Sleuth. I've tried modifying all of the masks and
ranges for scroll registers, SC masks, screen masks, etc, even setting
them by hand, to no avail.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 4:46 am Post subject: |
|
bsnes now builds with no warnings on Linux:
http://byuu.cinnamonpirate.com/images/desktop082106.png
However, input is not working unless you build the non-GTK+ port (see below for more info).
I'm planning on releasing next weekend. This will likely be the last
public WIP, unless something major is found before the weekend:
byuu.cinnamonpirate.com/files/bsnes_v016_wip52.zip <- copy/paste link
Arbee wrote: |
If
you can actually get it going fast in an all-in-one window like that
it'd be cool. I normally just punt and have the GUI separate from the
emulator output (GTK or Qt for the UI, SDL for the output) but it'd be
nice for my NEStopia port if I could make it "one piece" like the Win32
original |
I can. Please take a look at my above sourcecode, and check your
private messages for another note. Specifically, src/ui/video/sdl.cpp
and src/ui/gtk/gtk_mainwindow.cpp. I am able to merge the SDL output
into the GTK+ window by setting the environment variable
"SDL_WINDOWID=%ld", GDK_WINDOW_XWINDOW(mydrawingbox->window).
One important thing to note is that you must not initialize SDL video
until the render window has been realized. Simply showing the window is
not enough. You need to also clear all pending events in GTK+ after
showing the window before calling SDL video init, or it will die.
You can do that with this code:
Code: |
gtk_widget_show(mainwindow);
while(gtk_events_pending() == true) {
gtk_main_iteration_do(false);
} |
However, one problem I am having is that by calling
gtk_main_iteration_do(), it steals all SDL input, and I'm not able to
poll any keypresses. This happens whether I embed the SDL video output
into the GTK+ window or not. The only way to get SDL input is to ignore
all GTK+ events, effectively freezing the window completely.
I don't suppose you'd mind sharing how you got SDL input working with GTK+ with me?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 9:25 am Post subject: |
|
Good news,
Front Mission (J) (V1.0) [T+Eng1.0b_FH].smc works in the latest WIP, where it doesnt boot at all in .16
Also none of the problems that zsnes have show up. it looks just like on the snes!
Edit:
started testing games backwords starting at Z, games where tested up to
halfway though a level or 1 fight in a fighting game, RPG's where
tested up to the point where i got control of the character.
All tested games are verified from Goodsnes, and are supposed to be the correct clean dumps.
Yuujin - Janjuu Gakuen 2 (J).smc > there is random garbage errors in
the bottom right corner of the textboxin the intro story, i was unable
to capture a screenshot or test on my snes if its a game problem.
Yuujin - Janjuu Gakuen (J).smc >> no matter what characters i
unput at the seemingly "name" screen i cannot get passed this screen,
maybe someone who can read japanese can confirm
Zan III Spirits (J).smc > Dots show up in the lower right corner,
the dots are sometimes red and sometimes black, they are not visable in
zsnes, i have made screens of this behaviour.
Zenkoku Koukou Soccer Senshuken '96 (J).smc > after setting all the
settings the game goes black instead of starting the soccer match, game
works in zsnes
Yuu Yuu Hakusho Final - Makai Saikyou Retsuden (J).smc, game seems to
work but the screen stays black, only menu and story text is shown, the
rest is black, works in zsnes |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Mon Aug 21, 2006 12:46 pm Post subject: |
|
Waaay
back in Modeler I got that to work by running the actual emulation
entirely in a separate thread from the GTK+ stuff, but I don't know how
well that would work with it all in one window.
You might need to just make the drawing area a custom GTK widget and
get the keyboard & mouse input through GTK (and then use SDL for
joysticks). |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 1:31 pm Post subject: |
|
More bugs found, please forgive me if any of these games use special chips, i didnt find them in the lists i found.
Yogi Bear (J).smc and Yogi Bear (U) [!].smc > crackling noises seem
to come from nowhere, doesnt happen in the E version
X-Terminator 2 Sauke (J) [!].smc > Doesnt boot, doesnt work in Zsnes either, maybe this is a special chip game?
WWF WrestleMania - The Arcade Game (J).smc and WWF WrestleMania - The
Arcade Game (U) [!].smc > crackling noises seem to come from
nowhere, doesnt happen in the E version
Maybe we could make a list of non working games? non working due to
missing emulation of the needed chip or accessorie? the list shouldnt
be too long right?
Yoshi's Safari All versions > needs Lightgun, unemulated
X Zone All versions > needs Lightgun, unemulated
BS*, all games starting with BS > Needs BS emulation, unemulated |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 2:27 pm Post subject: |
|
Well then, give me some time to verify these.
I'd like the non-obvious ones tested on hardware first if possible, especially the one with the dots.
Ah well, it was a good run while it lasted. Looks like two is the
lowest number of known bugs an SNES emu is ever going to see :P
Quote: |
You
might need to just make the drawing area a custom GTK widget and get
the keyboard & mouse input through GTK (and then use SDL for
joysticks). |
That's what I was afraid of, having to use GTK+ input for keyboardsas well as SDL input for joypads :/
Why the custom widget, though? Can't I capture keypresses in a
GtkDrawingArea, if I tell GTK to capture keypress+release events?
Quote: |
X-Terminator 2 Sauke (J) [!].smc > Doesnt boot, doesnt work in Zsnes either, maybe this is a special chip game? |
A copier BIOS, actually. Cowering strikes again. It should still
probably show a menu. Perhaps I can find an emulation-mode CPU bug in
it.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 2:33 pm Post subject: |
|
i expect you to fix em all!! lol
thats only 68 games tested of the 1870 7zips in the dir, and most of
those contain games for multiple regions, as i have to test all regions.
Im planning on going through the entire list 
that will give a realistic view of all "obvious" bugs in the first 5 mins of every game.
Edit.
i left out the X-Band Modem BIOS which shows black screen because its a
bios. too bad i wasted my time with X-Terminator 2 Sauke (J) [!].smc if
its only a bios
dang...
Funny thing is i found a mame bug too 
About testing on a real snes, my guess is those games will have to be
tested on a J or U snes, as mine is E and might not give accurate
results, or am i wrong? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 3:15 pm Post subject: |
|
It
very likely would not give correct results. Probably fairly close in
most cases, but I'm pretty sure, special board mods or not, the CPU
still runs at a slightly different speed. Different physical timing
crystals in each CPU core.
Quote: |
thats
only 68 games tested of the 1870 7zips in the dir, and most of those
contain games for multiple regions, as i have to test all regions. |
Well, you weren't able to save in Secret of Evermore for over 4+
months, and nobody noticed. I suspect there are many bugs remaining in
bsnes that simply have not been discovered, and the majority appear to
be with obscure Japanese games coded on a serious budget.
If you were able to test all 1,870 of your 7zips, that'd be pretty
cool. I could make a fairly accurate compatibility percentage rate that
way. Of course, then we would need to classify what defines
not-compatible (completely broken, minor dots on the screen, or
somewhere in the middle?).
EDIT: Looking at X-Terminator first.
Code: |
00d84a lda #$2dff A:0080 X:0000 Y:0000 S:01ff D:0000 DB:00 NvmxdIzC
00d84d tcs A:2dff X:0000 Y:0000 S:01ff D:0000 DB:00 nvmxdIzC
00d84e sep #$20 A:2dff X:0000 Y:0000 S:2dff D:0000 DB:00 nvmxdIzC
...
00a555 plp A:2c8f X:0000 Y:0000 S:2df9 D:2c00 DB:ab NvMXdIzC
00a556 rts A:2c8f X:0000 Y:0000 S:2dfa D:2c00 DB:ab nvMxDizc
006061 rts A:2c8f X:0000 Y:0000 S:2dfc D:2c00 DB:ab nvMxDizc |
O__O
It sets the stack pointer to the MMIO region (open bus), and then pops
values from it. Somehow, Super Sleuth works with this. I've no idea
how. Perhaps Overload has partial support for this BIOS and maps WRAM
here?
As far as I know, SP >= $1fff does go to MMIO, and some games use
this to write PPU registers via pushes to the stack...
Unless I hear otherwise, I'm considering using $2dff as some sort of
RAM area related to using special hardware (the copier). So I'm
crossing this one off the list (again, unless I hear otherwise), and
moving on.
Last edited by byuu on Mon Aug 21, 2006 3:35 pm; edited 1 time in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 3:30 pm Post subject: |
|
Well
following mame, everything that doesnt happen on the real console is a
bug, but none of the bugs i submitted bar one make the game unplayable,
they are just graphical and sound problems.
I say
list it as is Game XX, has bug xx, you dont have to say if it makes the
game unplayable or not per se, and its up to you to decide if a bug is
worth fixing
another one
Winter Olympic Games - Lillehammer '94 (E) (M .smc and Winter Olympic Games - Lillehammer '94
(U) (M .smc > black line appears after the selected event starts to move and load, the black
line stays visable as the background fades out. screenshot will be uploaded, possible ingame
bug, also happens in Zsnes.
Its probaly also a good idea to compile a list of bugs, that are gamebugs and not emulation bugs
Last edited by tetsuo55 on Mon Aug 21, 2006 3:42 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 3:41 pm Post subject: |
|
Ok, you might want to slow down just a little. Let me classify these reported games first.
Not base SNES emulation bugs:
X-Terminator 2 Sauke (J) [!] - BIOS, uses unemulated copier hardware
Yuujin - Janjuu Gakuen (J)
- The screen you're stuck at is asking for a password, not a name. Heh,
rule of thumb: if the game doesn't crash, but you can't get it to go
past a certain screen, and you can't speak Japanese -- it's probably
not a bug. If you do speak Japanese, it probably is.
Yogi Bear (J/U)
- I cannot hear any sound corruption or crackling. This is likely due
to you dropping slightly below 60fps, or maybe bad sound drivers. Try
using log audio data and listen to the resulting WAV. 1 minute into the
game with no errors on BGM or SFX.
WWF WrestleMania - The Arcade Game (J/U)
- Same as Yogi Bear. Played a full match (>1 minute), no BGM or SFX
errors. Again, try making a wav log and play that back, you shouldn't
hear any crackling.
Confirmed in emulation, needs testing on copier:
Yuujin - Janjuu Gakuen 2 (J) - single tile shows a tiny corrupt box at bottom right of window. This is due to writing outside of vblank, very likely to be a bug on the real SNES.
Zan III Spirits (J)
- Has little red dots on the title screen, could be due to mode7
algorithm, could be due to bug, could be anything. Very bizarre. Very
minor detail, definitely needs hardware verification. This is also due
to writing outside of vblank, very likely to be a bug on the real SNES.
Winter Olympic Games - Lillehammer '94 (E/U)
- does show black line, happens with ZSNES, SNES9x and bsnes. Super
Sleuth corrupts most of the screen at this point (and then recovers),
SNEeSe does not play this game at all. I'm betting the line appears on
hardware, will need to confirm this one on hardware. Possibly an
emulation issue we all share, but unlikely.
Confirmed in emulation, almost certainly is a bug not present on hardware:
Zenkoku Koukou Soccer Senshuken '96 (J)
- does indeed crash. I have a hard time believing the game is supposed
to crash on hardware. Happens way too far into the game, will have to
extend debugger to trace error.
Yuu Yuu Hakusho Final - Makai Saikyou Retsuden (J) - appears confirmed. I'll look into it.
You won't see bugs with Yuujin2 or Zan3 on any other emulators (except
maybe SNEeSe), because no other emus block VRAM writes outside of
vblank.
Edit notes:
Yuujin issue previously mentioned was due to bad incremental link when I was testing. Game works fine in .52.
Last edited by byuu on Mon Aug 21, 2006 5:39 pm; edited 10 times in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 3:43 pm Post subject: |
|
Shall
i compile a full list and submit when ive gone trough the entire list,
only submitting those that bugs that make a game unplayable before
submitting the full list?
i wonder what is causing the audio problem in those ntsc games
Edit:
ive started making an excel sheet with more information so its easyer to read and confirm
ill post it when i finish testing, i will not be able to check these
bugs on my pal snes till i get it here at my new house, which will
hopefully be in a week or 2.
More good news Guru has already started re-dumping console games, i
guess for a fixed mess set in the future? who knows
good news is here: http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=83736&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1156115844
The problem is that little white blocks appear in the lower right
corner of the testbox lines, the garbage begins to happen when the girl
in the screenshot starts talking
During this second test at the fountain the characters and text started to flicker.
whats the CRC of the rom you are using?
* Loading "E:\Emulation\Nintendo\SNES\Bsnes\wip\test\Yuujin - Janjuu Gakuen 2...
* CRC32 : 70fbff3b
* Name : "JANJYU GAKUEN 2 "
* PCB : UNL-LOROM
* ROM Size : 2mbit
* RAM Size : 0bit
* Region : NTSC
* Coprocessor(s) : None
* Reset:803a NMI[n]:f000 IRQ[n]:f8d1 BRK[n]:ffa4 COP[n]:ffa0
* NMI[e]:f000 IRQ[e]:f8d1 BRK[e]:f8d1 COP[e]:ffac |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 4:51 pm Post subject: |
|
Same checksum, I'm not getting any flashing, though. Tried five times, can't get the characters to flash.
I see the box, quite a ways into the game, actually. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Aug 21, 2006 5:24 pm Post subject: |
|
tetsuo55 wrote: |
Its probaly also a good idea to compile a list of bugs, that are gamebugs and not emulation bugs |
There's been a known bugs list on the first page for months now. It's
even referenced in the title. All are free to report new bugs. I'll
take a look at some of these reports when I get home tonight from
class. You'll want to scan the roms with NSRT to make sure the games
aren't using unemulated hardware. I suppose I should add peripherals,
but I don't think a list of games is necessary. If you notice something
wrong, scan it and see if it corresponds to unemulated hardware. If it
does, the list has served its purpose and you need not report it.
PS: NSRT can also output lists of games that require special hardware. I just recently was told of this.
PPS: Regarding the sound crackling you experienced with certain games.
Here's another suggestion to confirm for yourself whether or not this
is legitimate: enable frameskipping to "1." That should clear up any
distortion due to fps drops and verify whether or not it's the game or
your computer.
Last edited by FitzRoy on Mon Aug 21, 2006 5:49 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 5:44 pm Post subject: |
|
Also,
please don't add bugs until I can confirm them. Too many false bug
reports. Please dont misunderstand: I'm glad to get the feedback, I
just don't want non-bugs to get added is all.
Zenkoku Koukou Soccer Senshuken '96 (J) and Yuu Yuu Hakusho Final -
Makai Saikyou Retsuden (J) do appear to be verified.
And we need someone with a copier to test Yuujin - Janjuu Gakuen 2 (J),
Zan III Spirits (J) and Winter Olympic Games - Lillehammer '94 (E/U). I
suspect at least two of these happen on real hardware, but I could
always be wrong.
As for the sound bugs, I don't experience them. If someone else wants
to test, that'd be cool. I can always overclock the APU a little, as
other people have reported the DSP frequency at >=32040hz, and not
32000hz as I use now. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Aug 21, 2006 5:53 pm Post subject: |
|
No,
I wasn't going to. I learned my lesson the last time I did that. And
you know it's getting harder to find stuff when you're reporting
possible bugs in bsnes that actually turn out to be game bugs that are
inaccurately fixed in all the other emulators (G.O.D.). |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 6:00 pm Post subject: |
|
thats why i suggested the games buglist, i dont see a link to a know games buglist in the first post though?
from now on i will confirm sound bugs by checking framerate and recording the audio.
Finished W X Y and Z, about 250 games tested, about 12 skipped for unsoported hardware.
Compatibility is awesome!!!
1 more bug to report
World Heroes 2 (J).smc Blackscreen when starting game, game does seem to work though, works in zsnes
World Heroes 2 (U) [!].smc Blackscreen when starting game, game does seem to work though, works in zsnes
Last edited by tetsuo55 on Mon Aug 21, 2006 6:57 pm; edited 4 times in total |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Aug 21, 2006 6:15 pm Post subject: |
|
Oh,
I see what you're saying. I won't be interested in that myself, but you
can feel free to make one. The thing is, most emulator bugs are
blatantly obvious not to be game bugs or glitches. When they aren't,
it's usually just a matter of testing on the real snes via a copier. So
compiling a massive list of game bugs and glitches isn't really a good
use of time. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 6:20 pm Post subject: |
|
Ill
keep the list mostly to myself then, although in a finished state it
would be of great help to other emulator authors and mess. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 6:51 pm Post subject: |
|
Confirmed that World Heroes 2 is not working.
Man, 120 unsupported special chip games in W-Z alone?? x.x |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 6:58 pm Post subject: |
|
Doh!! how did that zero get there
i ment to type 12

Actually a lot of the BS games worked partially, so did the superscope
games, only 1 superfx game there and that didnt do a thing  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Aug 21, 2006 7:30 pm Post subject: |
|
Offtopic, but...
tetsuo55 wrote: |
* CRC32 : 70fbff3b
* Reset:803a NMI[n]:f000 IRQ[n]:f8d1 BRK[n]:ffa4 COP[n]:ffa0
* NMI[e]:f000 IRQ[e]:f8d1 BRK[e]:f8d1 COP[e]:ffac |
Is there a special reason that causes hex. digits to be converted to
lowercase? It's just that personally, I prefer uppercase...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 7:46 pm Post subject: |
|
Yes, because I prefer lowercase :)
I use %x, you use %X.
So then, 100 - 3 / (250 - 12) = ~98.75% compatibility rate. Eh, not too shabby. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 8:28 pm Post subject: |
|
Actually
Tested W-Z
exactly 122 7zips, all containing several regions
Exactly 193 Roms
Non working
5 x bs
2 x SuperScope
2 x bios
1 x FX chip
3 x Bug that makes game unplayable
total non working in Bsnes, excluding baddumps(2 untested baddumps not counted in above list) and bios
11
Total working in Bsnes
183
100-3/(193-8 ) = 99.98 % compatibilty rate for W-Z (excluding 2 games which are known bad dumps)
And are those bioses even supposed to do anything on a emulator?
Last edited by tetsuo55 on Mon Aug 21, 2006 8:32 pm; edited 1 time in total |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Aug 21, 2006 8:31 pm Post subject: |
|
tetsuo55 wrote: |
Non working
5 x bs
2 x SuperScope
2 x bios
3 x Bug that makes game unplayable
|
BS-X? Not surprising. I don't know what exactly that falls under (special chip?)
Lack of Super Scope (mouse) obviously will have problems.
BIOSes generally don't matter at this point.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 8:37 pm Post subject: |
|
The
BIOS I looked at was setting the stack pointer into the memory mapped
IO region. Therefore, it requires emulation of special copier hardware
to display anything at all. Super Sleuth does emulate it (at least to
some extent), but I do not.
Oh wow, my compatibility math was wrong, heh. 99.98%... nice :)
byuu.org wrote: |
The compatibility is now (probably) around 80+%. |
Will have to update that ;)
Thanks for testing so many games, tetsuo.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Mon Aug 21, 2006 10:10 pm Post subject: |
|
Stack in MMIO? I guess it makes sense that copiers would want to disturb WRAM as little as possible.
BTW, Aaron Giles added a new raster timing system to the MAME/MESS
core. I pointed him to your SNES Doc Project dot timing page so he'd
understand "necessary additional features" 
And Nach: yeah, there's no substitute for good auto-complete, that's for sure. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 21, 2006 10:16 pm Post subject: |
|
I will say this one time and one time only.
Don't mess with my compatibility list, or suffer this fate :P



Apparently, you should mask the upper seven bits of VTIME and HTIME.
Same bug in all three games. tetsuo, thanks very much for reporting
these bugs, this is a fairly important fix just in time for the next
release.
tetsuo, would you mind recalculating your algorithm, now?
100 - 0/(193-8) = ? :D |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Mon Aug 21, 2006 10:43 pm Post subject: |
|
Congrats
on your fixes, byuu... Keep up the good work. I don't post much in this
thread but enjoy seeing you improve your emulator.  |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Aug 21, 2006 10:54 pm Post subject: |
|
Byuu you truly are awesome!, i knew youd fix those quickly.
Could i get the current version where this bug is fixed for further
testing? just in case any other games have this bug in the buildi have |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Aug 21, 2006 11:53 pm Post subject: |
|
Damn, fixed before I could add them again. 
And wow, what are the chances all three in W-Z shared the same bug? If
it's that prevalent, I can't help but agree with tetsuo's request. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Aug 22, 2006 12:11 am Post subject: |
|
And
what if we split the testing,so one can start from A-Z and Tetsuo can
continue from Z to A? It would speed up the testing and make it twice
as reliable as a bonus? 
Great work,byuu.This is the best thing since MAME and NEStopia  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 22, 2006 8:10 am Post subject: |
|
I
can do all of the US and E region games since I've gone through most of
them already. I've done 1/3 of the J games, but it was mostly random.
Someone with an NTSC system and copier needs to step up and confirm the
Zan III and Lilehammer anomolies, as well as future discoveries. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 9:34 am Post subject: |
|
Working toghether on this would be quicker
if everyone follows these guidelines i can add the information to my database
Count all tested games for each letter of the alphabet, make a list of
all games that did not work for whatever reason, and keep an eye open
for graphics bugs
once the list is complete we will have to test them against a real snes
so i can finish the list of snes game bugs vs bsnes bugs and then byuu
can fix them all, and maybe add a comment in his database for those
games that have gamebugs., after that maybe byuu can start adding more
of those unsopported peripherals and chips  
After that all the bugs are fixed well have to do another run to check for any regressions.
Edit:
I was thinking maybe if we give byuu a list of all the non working
games, bsnes could give some kind of warning when someone is trying to
play a superFX game or something like that. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 22, 2006 11:37 am Post subject: |
|
Unless
byuu expresses uncertainty on a certain bugfix, I would say regression
testing is unnecessary on anything but major rewrites. Usually, he or
someone else finds out exactly what was wrong and corrects it. That's
why I thought those PAL tests with you were important, because that was
one that he wasn't sure about. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 11:59 am Post subject: |
|
cool
i hope i get those pal tests soon then
maybe blargg could make some ?
i blieve his tests are ment for ntsc right?
EDIT:
V
Untested > none
Tested > 12 roms
Problems found:
Verne World (J).smc > shows a green bar at the bottom of the screen, doesnt happen in zsnes,
music sounds a lot different from zsnes, needs hardware verification.
Vortex (E/J/U) [!].smc > black screen, SuperFX game
U
Untested > Undercover Cops, no good dump known
Tested > 47 roms
Problems found:
Super Daikoukai Jidai (J).smc > this game looks cropped at the top, looks normal in zsnes.
Uchuu Race - Astro Go! Go! (J).smc > audio real low, needs verification on real hardware
UFO Super Drive PRO 3 BIOS.smc > black screen, because its a bios! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 22, 2006 3:34 pm Post subject: |
|
tetsuo55 wrote: |
Could
i get the current version where this bug is fixed for further testing?
just in case any other games have this bug in the buildi have |
I didn't have a chance to get on my main PC and build another WIP. If
you can compile the source, edit src/cpu/scpu/mmio/mmio.cpp and change
mmio_w420[7-a] functions to mask status.[vh]irq with 0x1ff after
updating it. Otherwise, I might be able to get one up Wednesday night.
Got a lot of real life stuff going on, so I'm quite busy as of late.
Hopefully not too busy to miss this weekend for a release date. If I
can't get the SDL input working before the weekend on Linux, I'm just
going to release it and let people use the pure-SDL / non-GTK version.
Quote: |
And wow, what are the chances all three in W-Z shared the same bug? |
Quite lucky indeed.
Quote: |
Someone
with an NTSC system and copier needs to step up and confirm the Zan III
and Lilehammer anomolies, as well as future discoveries. |
Agreed. And that dating sim one, too. Someone will need a damn good TV
to see that one, though. I'm pretty sure Zan and the dating one will
happen on hardware, but I could be wrong. Winter Olympics I'm not so
sure about.
Quote: |
Unless
byuu expresses uncertainty on a certain bugfix, I would say regression
testing is unnecessary on anything but major rewrites. |
I do break things on occasion. Most of the time it seems to be memory
map modifications that cause it. But I usually test all of the major
memory map offenders before releasing a new WIP. I know Dezaemon and
Tokimeki saves might be a little screwy right now, but eventually
those'll get added to the DB. Their issues have nothing to do with core
SNES emulation.
Quote: |
i hope i get those pal tests soon then |
Soon as I have free time ;)
Which means probably 3+ months from now, heh.
-----
Quote: |
Verne World (J).smc > shows a green bar at the bottom of the screen, doesnt happen in zsnes, |
I show line 224, ZSNES does not. Lots of games don't bother setting the
data there, but some do. I asked about this and most people wanted me
to show line 224, so I did. I can add cropping options for it if demand
is there.
Quote: |
music sounds a lot different from zsnes, needs hardware verification. |
Try it in SNEeSe. If SNEeSe sounds like bsnes, it's likely correct. If
it sounds like ZSNES, bsnes likely has a bug.
Quote: |
Vortex (E/J/U) [!].smc > black screen, SuperFX game |
Guilty, fairly obvious. SA-1 games are far more insidious, most people
know which games used the SFX chip, but few know which ones actually
used the SA-1. Lots of obscure golf games and such use the chip.
Detection and warnings in the emu would be good, another issue of time.
Quote: |
Super Daikoukai Jidai (J).smc > this game looks cropped at the top, looks normal in zsnes. |
Uses overscan mode, despite being an NTSC game. Set video standard to PAL and it looks just like ZSNES.
Quote: |
Uchuu Race - Astro Go! Go! (J).smc > audio real low, needs verification on real hardware |
Same thing, compare to ZSNES and SNEeSe.
Quote: |
UFO Super Drive PRO 3 BIOS.smc > black screen, because its a bios! |
Indeed :)
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 4:10 pm Post subject: |
|
I'm going to test all those buggy games on my pal snes at least, but someone with an ntsc snes needs to step up and help out.
Well the good news then is that none of the problems in V and U seem to be caused by bsnes. awesome!
although it would be nice if uncharted waters autoselected pal display
mode hehe, as its strange for a ntsc game to need that.
sorry to hear your so busy, but as always real life comes first 
I removed all my compiling tools so i will have to wait till you have time to compile a wip then.
The option to disable that last line would be nice though. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 22, 2006 4:19 pm Post subject: |
|
I'm
thinking about getting one of those tototek flash carts. Anyone here
have experience with one of these? Any drawbacks vs a standard copier?
I'm leery because they are less expensive... seems like they might have
some limitations. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 4:31 pm Post subject: |
|
Hmmm,
i have started retesting BS games, and a lot of them work completely,
so i will be retesting these and adding them to the bug reports
the handfull that dont work can probably be fixed
EDIT:
BS testrun:
BS Wai Wai Check 3-7 (J).smc > Game seems to work but there is no audio and the graphics are garbage
BS Wario no Mori (J).smc > seems 100% working
BS Yung Hakase no Shinsatsu Shitsu 1 (J).smc > seems to work completely, but fonts are garbage
BS Yung Hakase no Shinsatsu Shitsu 1 (J).smc > seems to work completely, but fonts are garbage
BS Zootto Mahjong! Event Version (J).smc > seems 100% working
BS Zootto Mahjong! Preview Version (J).smc > seems 100% working
BS Panel de Pon - Event '98 (J).smc > seems 100% working
BS Tantei Club - Yuki ni Kieta Kako 1 (J).smc > Black screen
BS Tantei Club - Yuki ni Kieta Kako 2 (J).smc > Black screen
BS Tantei Club - Yuki ni Kieta Kako 3 (J).smc > Black screen
BS Tora no Maki 5-17 (J).smc > Black screen
BS Tora no Maki 5-31 (J).smc > Black screen
BS Treasure Conflix (J).smc > game works but fonts and some spirtes are messed up
BS Yoshi no Panepon (J).smc > seems 100% working
PS, FitzRoy could you make that list of special chip/add-on games from
NSRT??, and i have never heard about those carts before sorry. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 22, 2006 5:03 pm Post subject: |
|
Quote: |
I'm
thinking about getting one of those tototek flash carts. Anyone here
have experience with one of these? Any drawbacks vs a standard copier?
I'm leery because they are less expensive... seems like they might have
some limitations. |
The biggest one is that it has a BIOS on-cart. Even if you only have
one game, the BIOS runs and ruins your chances at getting a clean
power-on state to test with, which is what I desperately need at this
point.
Other than that, it probably works fine. The price does seem pretty
high though, but I guess the Tototek guy does not have volume pricing
on his side.
I can't hear sound that well with these shoddy headphones at work. Can
someone please compare audio from Verne World and Unchuu Race in
ZSNES<>SNEeSe<>bsnes and post results?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 22, 2006 5:57 pm Post subject: |
|
Well,
that's cool. Maybe I'll pick one up. Then we'll finally have someone
with a copier, a tv input card, and a prompt willingness to help 
I'd test those roms but I'm at work for another 4 hours. |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 6:22 pm Post subject: |
|
Verne
World and Unchuu Race sound the same on SNEeSe as on Bsnes, Unchuu Race
however sounds a bit less loud on SNEeSe, but so does Verne World
So those can both be removed
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 22, 2006 6:36 pm Post subject: |
|
Thanks for confirming. Much as I'd hate to add a bug that isn't really one to my list, it'd be worse to skip over a real bug.
We should report this potential audio bug in Verne World to the ZSNES
dev team, then. Of course, ZSNES may have it right, but probably not
since SNEeSe is well regarded as having the best S-DSP emulation of
them all.
Uchuu Race is probably just different default volume levels between
emulators... volume knob fixes that easily enough :)
So yay, U-Z sans special hardware = perfect :D |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 22, 2006 6:49 pm Post subject: |
|
audio sounds different to real snes in a lot of games in zsnes though..
Were goin for 100% compatibility here 
Why do you think those bs games have messed up fonts? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 22, 2006 10:54 pm Post subject: |
|
Apparently,
BGnVOFS is not doubled for interlace. Even though it is for hires. This
took a really, really, really long time to figure out.


Now then, if you want to make my ultimate dream come true... help me
find a bugfix for Uniracers (that isn't a hack) before another bug I'm
unable to fix is reported. Even if other bugs pop up in the future,
that's fine. But just knowing I was able to reach zero known bugs...
even for one brief moment in time... would really mean a lot to me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 22, 2006 11:21 pm Post subject: |
|
Here is a log of Uniracers OAM accesses:
Legend:
w21nn - MMIO port written to
<vcounter, hclock>
vcounter - scanline when action occurred
hclock - exact clock position on scanline, divide by 4 for estimated hcounter
addr - absolute OAM address where write will go (for $2104), or new OAM
address after write (for $2102,$2103). Note that this is 2 * value
written to $2102-$2103
data - data written to MMIO register
OAMreset - known OAM address reset after start of vblank
Code: |
* w2103: <226, 256> addr=0180,data=00
* w2104: <226, 324> addr=0180,data=68
* w2104: <226, 374> addr=0181,data=98
* w2104: <226, 424> addr=0182,data=88
* w2104: <226, 474> addr=0183,data=68
* w2104: <226, 524> addr=0184,data=68
* w2104: <226, 614> addr=0185,data=98
* w2104: <226, 664> addr=0186,data=00
* w2104: <226, 714> addr=0187,data=66
* w2104: <226, 764> addr=0188,data=68
* w2104: <226, 814> addr=0189,data=28
* w2104: <226, 864> addr=018a,data=00
* w2104: <226, 914> addr=018b,data=66
* w2104: <226, 964> addr=018c,data=68
* w2104: <226,1014> addr=018d,data=28
* w2104: <226,1064> addr=018e,data=88
* w2104: <226,1114> addr=018f,data=68
* w2102: <226,1174> addr=0018,data=0c
* w2103: <226,1180> addr=0218,data=01
* w2104: <226,1248> addr=0218,data=a5
* w2102: <239,1120> addr=0200,data=00
* w2103: <239,1156> addr=0200,data=01
* w2104: < 0,1134> addr=0200,data=a5
* w2104: <112,1136> addr=0201,data=5a
* OAMreset: <225, 0> 0202->0200
* w2102: <226, 280> addr=0380,data=c0
* w2103: <226, 286> addr=0180,data=00
* w2104: <226, 354> addr=0180,data=68
* w2104: <226, 404> addr=0181,data=98
* w2104: <226, 454> addr=0182,data=88
* w2104: <226, 504> addr=0183,data=68
* w2104: <226, 594> addr=0184,data=68
* w2104: <226, 644> addr=0185,data=98
* w2104: <226, 694> addr=0186,data=00
* w2104: <226, 744> addr=0187,data=66
* w2104: <226, 794> addr=0188,data=68
* w2104: <226, 844> addr=0189,data=28
* w2104: <226, 894> addr=018a,data=00
* w2104: <226, 944> addr=018b,data=66
* w2104: <226, 994> addr=018c,data=68
* w2104: <226,1044> addr=018d,data=28
* w2104: <226,1094> addr=018e,data=88
* w2104: <226,1144> addr=018f,data=68
* w2102: <226,1204> addr=0018,data=0c
* w2103: <226,1210> addr=0218,data=01
* w2104: <226,1278> addr=0218,data=a5
* w2102: <239,1150> addr=0200,data=00
* w2103: <239,1186> addr=0200,data=01
* w2104: < 0,1136> addr=0200,data=a5
* w2104: <112,1136> addr=0201,data=5a
* OAMreset: <225, 0> 0202->0200
* w2102: <226, 248> addr=0380,data=c0
* w2103: <226, 254> addr=0180,data=00
* w2104: <226, 322> addr=0180,data=68
* w2104: <226, 372> addr=0181,data=98
* w2104: <226, 422> addr=0182,data=88
* w2104: <226, 472> addr=0183,data=68
* w2104: <226, 522> addr=0184,data=68
* w2104: <226, 612> addr=0185,data=98
* w2104: <226, 662> addr=0186,data=00
* w2104: <226, 712> addr=0187,data=66
* w2104: <226, 762> addr=0188,data=68
* w2104: <226, 812> addr=0189,data=28
* w2104: <226, 862> addr=018a,data=00
* w2104: <226, 912> addr=018b,data=66
* w2104: <226, 962> addr=018c,data=68
* w2104: <226,1012> addr=018d,data=28
* w2104: <226,1062> addr=018e,data=88
* w2104: <226,1112> addr=018f,data=68
* w2102: <226,1172> addr=0018,data=0c
* w2103: <226,1178> addr=0218,data=01
* w2104: <226,1246> addr=0218,data=a5
* w2102: <238,1270> addr=0200,data=00
* w2103: <238,1306> addr=0200,data=01
* w2104: < 0,1134> addr=0200,data=a5
* w2104: <112,1136> addr=0201,data=5a
* OAMreset: <225, 0> 0202->0200
* w2102: <226, 246> addr=0380,data=c0
* w2103: <226, 252> addr=0180,data=00
* w2104: <226, 320> addr=0180,data=68
* w2104: <226, 370> addr=0181,data=98
* w2104: <226, 420> addr=0182,data=88
* w2104: <226, 470> addr=0183,data=68
* w2104: <226, 520> addr=0184,data=68
* w2104: <226, 610> addr=0185,data=98
* w2104: <226, 660> addr=0186,data=00
* w2104: <226, 710> addr=0187,data=66
* w2104: <226, 760> addr=0188,data=68
* w2104: <226, 810> addr=0189,data=28
* w2104: <226, 860> addr=018a,data=00
* w2104: <226, 910> addr=018b,data=66
* w2104: <226, 960> addr=018c,data=68
* w2104: <226,1010> addr=018d,data=28
* w2104: <226,1060> addr=018e,data=88
* w2104: <226,1110> addr=018f,data=68
* w2102: <226,1170> addr=0018,data=0c
* w2103: <226,1176> addr=0218,data=01
* w2104: <226,1244> addr=0218,data=a5
* w2102: <239, 490> addr=0200,data=00
* w2103: <239, 526> addr=0200,data=01 |
Basically, the problem is with these writes here:
Code: |
* w2104: < 0,1136> addr=0200,data=a5
* w2104: <112,1134> addr=0201,data=5a |
Both of these should go to addr=0218, and the game will work fine. I
don't know how correct that is. If I block the writes, the game fails
to work correctly. If I force them to 0218, it works. But I cannot say
for certain that hardware is writing to 0218 here. SNES9x uses a hack
to force these two writes to $0218 for Uniracers alone. ZSNES somehow
manages to run Uniracers correctly, and supposedly does not have any
hacks. I do not know how this is possible, but perhaps a ZSNES dev
could shed light on how their OAM address invalidation code works,
possibly?
From what I can tell...
Code: |
//start vblank, perform OAM address reset
* OAMreset: <225, 0> 0202->0200
//do some NMI OAM updates
* w2102: <226, 280> addr=0380,data=c0
* w2103: <226, 286> addr=0180,data=00
* w2104: <226, 354> addr=0180,data=68
* w2104: <226, 404> addr=0181,data=98
* w2104: <226, 454> addr=0182,data=88
* w2104: <226, 504> addr=0183,data=68
* w2104: <226, 594> addr=0184,data=68
* w2104: <226, 644> addr=0185,data=98
* w2104: <226, 694> addr=0186,data=00
* w2104: <226, 744> addr=0187,data=66
* w2104: <226, 794> addr=0188,data=68
* w2104: <226, 844> addr=0189,data=28
* w2104: <226, 894> addr=018a,data=00
* w2104: <226, 944> addr=018b,data=66
* w2104: <226, 994> addr=018c,data=68
* w2104: <226,1044> addr=018d,data=28
* w2104: <226,1094> addr=018e,data=88
* w2104: <226,1144> addr=018f,data=68
//set correct address for table writes at V=226
* w2102: <226,1204> addr=0018,data=0c
* w2103: <226,1210> addr=0218,data=01
//write to $0218 here....... not sure why. This is probably why the top
half of the screen works correctly, but the game tries to update this
again at V=0, before any sprites are shown anyway. Perhaps this is why
future writes during active display go to $0218 every time?
* w2104: <226,1278> addr=0218,data=a5
//this forces next OAM address invalidation to $0200
* w2102: <239,1150> addr=0200,data=00
* w2103: <239,1186> addr=0200,data=01
//and also forces the next two HDMA OAM updates to go to $0200,$0201
//why would it write to $0218 twice? and not $0218,$0219?
//could it be related to address update on y=226?
* w2104: < 0,1136> addr=0200,data=a5
* w2104: <112,1136> addr=0201,data=5a
//repeat process from above
* OAMreset: <225, 0> 0202->0200 |
OAM $0218 = extended attributes for sprites 96-99. By alternating
between 5a and a5, the game is toggling X.d8 (moving sprite onscreen or
offscreen, in this case) and the OAM size attirubute, which I'm sure is
meaningless in this case (if it's offscreen, size does not matter).
I'm guessing it's using 96,97 for the top screen, and 98,99 for the
bottom screen (I might have those two pairs switched around).
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 23, 2006 6:06 am Post subject: |
|
Its gonna take a little while for me to get through T 160+ roms in that letter alone
Thinking of the uniracer bug, i didnt test any 2p modes, so there could
still be 2p bugs somewhere? maybe ill have to retest all 2p games
sometime with a friend.
I hope NSRT can pop out a list of all 2+player games also?
Im not too worried about unfixable bugs, even better maybe if a find
another game that has the same bug as uniracers it will help you fix it
quicker as there will be more hints to whats causing it, although i
have a lot of hope for that link bob posted 
I'll try to get my snes back this sunday and then test those reported games for bugs on PAL hardware. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 23, 2006 2:16 pm Post subject: |
|
Unforunately, that link only supplies this one line of changed code:
Code: |
mov byte[NextLineCache],0 |
That... doesn't explain anything to me :/
However, I think I have an idea that -might- just work. I noticed the
last write to $2104 before the start of the frame went to $0218... what
if the "OAM reset" address is set by the last write to $2104 (and not
$2102-$2103), and the OAM address is restored at the start of hblank
for every line instead of just at V=225,HC=~0-6?
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Aug 23, 2006 2:58 pm Post subject: |
|
Maybe nach or pagefault can explain zsknight's fix to mid-screen OAM updating and if it is indeed correct to the hardware. 
P.S. Snv presentation is a lot better than the cvs. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 23, 2006 3:26 pm Post subject: |
|
Quote: |
Maybe nach or pagefault can explain zsknight's fix to mid-screen OAM updating and if it is indeed correct to the hardware. |
It definitely isn't. It's a hack that specifically checks for the
values written by Uniracers to get the game working :(
Code: |
//this works in ZSNES, oamaddrs=0218 after these two writes
* w2102: <226,1204> addr=0018,data=0c
* w2103: <226,1210> addr=0218,data=01
//this write goes through
* w2104: <226,1278> addr=0218,data=a5
//this write is blocked by reg2102w
//or al,al
//jz .skipstore
//blocks oamaddrs (oam reset address) because data=00
* w2102: <239,1150> addr=0200,data=00
//this write is blocked by reg2103w
//cmp word[oamaddr],200h
//jne .notinvptr ;not inv pointer??
//blocks oamaddrs because addr=0200
* w2103: <239,1186> addr=0200,data=01
//now oam address reset value is still $0218 |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 23, 2006 4:24 pm Post subject: |
|
Too bad byuu
maybe ill find another game that has a similar bug and you can combine the information from both games to fix it 
By the way, has the "rom" been verfied to work perfectly on hardware? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 23, 2006 5:46 pm Post subject: |
|
My theory fails. It works in Uniracers but breaks Donkey Kong Country.
Yes, Uniracers works on hardware. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 23, 2006 5:50 pm Post subject: |
|
@
tetsuo: If you're suspecting it's a bad rom, keep in mind that this
problem occurs in all three regions of the rom. The chances that all
three are bad, and bad with the same affliction, is quite frankly, zero.
I tested Verne World last night and noticed nothing out of the usual on
either zsnes or bsnes. Perhaps you've got your zsnes sound settings
messed up, since that emulator offers you the opportunity of doing so
(something I never understood).
I did notice the "clipping" in Super Daikoukai Jidai. What's happening
here, byuu, is similar to what I reported about Super Mario Kart (E).
Looks like the game uses overscan, except this time it's not PAL.
Good job on the RPM Racing fix. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 23, 2006 6:25 pm Post subject: |
|
I tested it with default settings, no cfg file or anything.
I notice a distinct difference in the pitch and lenght of certain notes, its subtle but noticable.
Maybe ill get my snes tommorow and ill be able to so some early testing
what happens with Donkey Kong country when you try the fix for uniracers? |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Wed Aug 23, 2006 6:50 pm Post subject: |
|
byuu wrote: |
Quote: |
Super Daikoukai Jidai (J).smc > this game looks cropped at the top, looks normal in zsnes. |
Uses overscan mode, despite being an NTSC game. Set video standard to PAL and it looks just like ZSNES.
|
So I heard it's quite common for NTSC games to use overscan, although
not so common for US NTSC releases. Try Destructive (J) while you're at
it.
It's probably not common to find a TV which recenters any image fed to
it, regardless of the number of scanlines between vertical blank. What
happens when overscan is enabled after NMI? Oops, PPU resumes drawing.
Then what happens to the magic centering?
Oh yeah, and any display which recenters the image would have to be
displaying a frame behind the signal. That may also count in anything
which displays interlaced signals as progressive scan, with or without
frame rate doubling or motion interpolation filter. Hmm...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 23, 2006 7:15 pm Post subject: |
|
Here's an updated log with force blank status (fb):
(EDIT: and Super Sleuth tracelog output)
(EDIT2: commented on each action)
Code: |
//both of these writes should go to $0218
//to update extended attributes for sprites 96-99
//($0218 - $0200) * 4 = 96
* w2104: < 0,1138> fb=0,addr=0200,baseaddr=0100,data=a5
* w2104: <112,1132> fb=0,addr=0201,baseaddr=0100,data=5a
{
(HDMA writes)
}
//OAM address reset at V=225
* OAMreset: <225, 0> fb=0,0202->0200
//set oamaddr to sprite 96 address
//$0180 / 4 = 96
* w2102: <226, 244> fb=1,addr=0380,baseaddr=01c0,data=c0
* w2103: <226, 250> fb=1,addr=0180,baseaddr=00c0,data=00
{
82d2da lda #$00c0 A:001e X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d2dd sta OAMADDL [00:2102] A:00c0 X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
}
//update sprites 96-99 ($0180 / 4 = 96)
* w2104: <226, 318> fb=1,addr=0180,baseaddr=00c0,data=68 (P1x screen1)
* w2104: <226, 368> fb=1,addr=0181,baseaddr=00c0,data=96 (P1y screen1)
* w2104: <226, 418> fb=1,addr=0182,baseaddr=00c0,data=88
* w2104: <226, 468> fb=1,addr=0183,baseaddr=00c0,data=68
* w2104: <226, 518> fb=1,addr=0184,baseaddr=00c0,data=68 (P2x screen1)
* w2104: <226, 608> fb=1,addr=0185,baseaddr=00c0,data=96 (P2y screen2)
* w2104: <226, 658> fb=1,addr=0186,baseaddr=00c0,data=00
* w2104: <226, 708> fb=1,addr=0187,baseaddr=00c0,data=66
* w2104: <226, 758> fb=1,addr=0188,baseaddr=00c0,data=68 (P2x screen2)
* w2104: <226, 808> fb=1,addr=0189,baseaddr=00c0,data=27 (P2y screen2)
* w2104: <226, 858> fb=1,addr=018a,baseaddr=00c0,data=00
* w2104: <226, 908> fb=1,addr=018b,baseaddr=00c0,data=66
* w2104: <226, 958> fb=1,addr=018c,baseaddr=00c0,data=68 (P1x screen2)
* w2104: <226,1008> fb=1,addr=018d,baseaddr=00c0,data=27 (P1x screen2)
* w2104: <226,1058> fb=1,addr=018e,baseaddr=00c0,data=88
* w2104: <226,1108> fb=1,addr=018f,baseaddr=00c0,data=68
{
82d2d8 rep #$20 A:001e X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2da lda #$00c0 A:001e X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d2dd sta OAMADDL [00:2102] A:00c0 X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d2e0 sep #$20 A:00c0 X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d2e2 lda $1501 [00:1501] A:00c0 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2e5 sta OAMDATA [00:2104] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2e8 lda $1502 [00:1502] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2eb sta OAMDATA [00:2104] A:0097 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d2ee lda $1503 [00:1503] A:0097 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d2f1 sta OAMDATA [00:2104] A:0088 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d2f4 lda $1504 [00:1504] A:0088 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d2f7 sta OAMDATA [00:2104] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2fa lda $1505 [00:1505] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d2fd sta OAMDATA [00:2104] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d300 lda $1506 [00:1506] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d303 sta OAMDATA [00:2104] A:0096 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d306 lda $1507 [00:1507] A:0096 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d309 sta OAMDATA [00:2104] A:0000 X:0000 Y:0000 S:01de D:0000 DBR:00 P:67
82d30c lda $1508 [00:1508] A:0000 X:0000 Y:0000 S:01de D:0000 DBR:00 P:67
82d30f sta OAMDATA [00:2104] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d312 lda $1509 [00:1509] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d315 sta OAMDATA [00:2104] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d318 lda $150a [00:150a] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d31b sta OAMDATA [00:2104] A:0028 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d31e lda $150b [00:150b] A:0028 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d321 sta OAMDATA [00:2104] A:0000 X:0000 Y:0000 S:01de D:0000 DBR:00 P:67
82d324 lda $150c [00:150c] A:0000 X:0000 Y:0000 S:01de D:0000 DBR:00 P:67
82d327 sta OAMDATA [00:2104] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d32a lda $150d [00:150d] A:0066 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d32d sta OAMDATA [00:2104] A:006a X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d330 lda $150e [00:150e] A:006a X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d333 sta OAMDATA [00:2104] A:0029 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d336 lda $150f [00:150f] A:0029 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d339 sta OAMDATA [00:2104] A:0088 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d33c lda $1510 [00:1510] A:0088 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
82d33f sta OAMDATA [00:2104] A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
}
//set oamaddr to sprite 96 extended attribute address (($0218 - $0200) * 4 = 96)
* w2102: <226,1168> fb=1,addr=0018,baseaddr=000c,data=0c
* w2103: <226,1174> fb=1,addr=0218,baseaddr=010c,data=01
{
82d342 rep #$20 A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d344 lda #$010c A:0068 X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d347 sta OAMADDL [00:2102] A:010c X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
}
//update oam attributes for sprites 96-99 (($0218 - $0200) * 4 = 96)
* w2104: <226,1242> fb=1,addr=0218,baseaddr=010c,data=a5
{
82d34a sep #$20 A:010c X:0000 Y:0000 S:01de D:0000 DBR:00 P:45
82d34c lda $1599 [00:1599] A:010c X:0000 Y:0000 S:01de D:0000 DBR:00 P:65
82d34f sta OAMDATA [00:2104] A:01a5 X:0000 Y:0000 S:01de D:0000 DBR:00 P:e5
}
//set oamaddr to beginning of sprite attribute table ($0200)
//reason for this code is unknown
* w2102: <239,1102> fb=1,addr=0200,baseaddr=0100,data=00
* w2103: <239,1138> fb=1,addr=0200,baseaddr=0100,data=01
{
808663 lda #$00 A:6cc0 X:00ff Y:0020 S:01e3 D:0000 DBR:00 P:a4
808665 sta OAMADDL [00:2102] A:6c00 X:00ff Y:0020 S:01e3 D:0000 DBR:00 P:26
808668 ina A:6c00 X:00ff Y:0020 S:01e3 D:0000 DBR:00 P:26
808669 sta OAMADDH [00:2103] A:6c01 X:00ff Y:0020 S:01e3 D:0000 DBR:00 P:24
} |
Quote: |
It's
probably not common to find a TV which recenters any image fed to it,
regardless of the number of scanlines between vertical blank. What
happens when overscan is enabled after NMI? Oops, PPU resumes drawing.
Then what happens to the magic centering? |
I don't know what happens when you enable overscan between V=225 and
V=239. Regardless, the image *is* recentered on my TV if you enable
overscan normally and leave it on. I imagine if you enable it that
late, it will look the same as if the frame did not use overscan at
all. It could even be the PPU that's modifying its output based on
overscan setting at the start of a new frame (similar to how it works
with interlace).
Last edited by byuu on Wed Aug 23, 2006 10:11 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 23, 2006 9:34 pm Post subject: |
|
My
bad on the superfluous overscan report. I think I'm going crazy, I
could have sworn I read a comment like "I don't notice it" from byuu on
that game.
Anyhow, I'd like to propose my middle
finger to both PAL and snes overscan mode. Both are fucked up ideas
that have fucked with the possibility of a simpler world. I've noticed
Super Sleuth has its display window permanently heightened to account
for those games. Is that seriously what's going to have to be done?
Edit: In the future, I'd appreciate being corrected for stupidity. I
realize now that adding resolutions to the multipliers would be stupid
because the snes is capable of many different resolutions when you
include regions, overscan, hi-res, and interlace. I also think what
you're doing right now isn't that bad, but setting to PAL for an NTSC
game seems weird. Have you thought about adding a new setting, or just
doing what Sleuth does? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 2:53 pm Post subject: |
|
Got my snes, but the powersupply is damaged, need to fix it 
Its good to see my Super Wildcard DX again, although im still hoping to get a wildcard DX 2 some day.
i have another copybox but im not sure which one, i think its a Wildcard 32m
But it doesnt work, need to check every IC and rom/ram chip with a voltage meter to check which one is acting up. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 24, 2006 3:46 pm Post subject: |
|
Ok,
basically I was able to find out a little bit about mid-frame OAM
writes. But not enough to emulate Uniracers. Unfortunately, it does not
look like I'm going to be able to fix this game properly before v0.017,
and consequently, before more bug reports come in. Sigh. I did my best,
at least.
Basically, this is where SNES emulation at this point really stands:
CPU - 99% of games run, 95% hardware accurate, little headway on bus/event conflicts.
APU - same as CPU.
DSP - 99% of sound in games works fine, ~80% hardware accurate, DSP
cores currently read in multiple bytes from DSPRAM "immediately" and
run it at 32khz. In reality, it probably runs at 1.024mhz and performs
sequential reads that could cause 1-sample differences based on timing
of APU memory accesses. This would undoubtedly be the hardest area to
get hardware accurate. It's very hard to run timing specific tests on
the DSP, and the difference at best is probably only a sample anyway.
No tangible benefits and no perceived difference. Very tough work
indeed.
PPU - 99% of games display no graphical errors, I would go so far as to
say not hardware accurate at all. We're treating the PPU as if it runs
at ~13.5khz by rendering entire scanlines at a time. In reality, it
needs to be run at ~5.37mhz, *possibly twice that*. An unbelievable
difference that has all kinds of consequences and internal variables
that have yet to be discovered. We've only discovered how to match SNES
output in the most basic cases. Luckily, unlike the NES, very few SNES
games attempt to exploit the renderer much more than modifying windows
and scrolling regs during HDMA. But the second you start doing things
like mid-frame OAM/CGRAM writes, all hell breaks loose and no emulator
even comes close to real hardware.
The PPU is going to need massive work and a whole new emulation
approach if we're ever going to get true hardware accuracy. We're going
to have to decode all kinds of insane internal state machines based
solely on megabytes of data logs.
This isn't like emulating a CPU. With a CPU, you control what it
executes, it runs your program. And your program can analyze what's
going on. With the PPU, you're feeding a custom program input, and
reading its output (think DSP-1-4 and how long those took to emulate,
and imagine this being even more complex than that).
What we essentially have to do is emulate the internal PPU "program"
and run it in sync with the CPU and its clock. I can't begin to
estimate how much more power this will require, but suspect it will be
quite a lot more than currently used. But I'll try and leave bPPU in
there for gaming purposes. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 24, 2006 4:28 pm Post subject: |
|
Dude,
one known bug is stellar, and .017 will be an incredible release. Libco
had some regressions, but you ended up finding them all, and in the end
it kicked bcpu's ass. I think the question on everyone's minds though,
is what will you work on next? Do you think you'll start doing more
unemulated chips and peripherals, or will you start tackling this big
PPU thing? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 5:30 pm Post subject: |
|
Fixed the power supply
test run on PAL snes with PAL superwildcard DX
Yuujin - Janjuu Gakuen 2 (J) - single tile shows a tiny corrupt box at
bottom right of window. This is due to writing outside of vblank, very
likely to be a bug on the real SNES.
Graphics
corruption in bottom right of window do NOT happen on hardware, however
the flashing sprites at the fountain DOES happen.
Zan III Spirits (J) - Has little red dots on the title screen, could be
due to mode7 algorithm, could be due to bug, could be anything. Very
bizarre. Very minor detail, definitely needs hardware verification.
This is also due to writing outside of vblank, very likely to be a bug
on the real SNES.
Corrupt dots do NOT show on hardware
Winter Olympic Games - Lillehammer '94 (E/U) - does show black line,
happens with ZSNES, SNES9x and bsnes. Super Sleuth corrupts most of the
screen at this point (and then recovers), SNEeSe does not play this
game at all. I'm betting the line appears on hardware, will need to
confirm this one on hardware. Possibly an emulation issue we all share,
but unlikely.
black line does NOT show on hardware, tested U and E
Verne World sounds exactly like on hardware
Tested uniracers(U/E) both roms crash my snes, bad dumps after all? i know the original game worked.
EDIT: the beta works normaly on my snes, but still shows the bug in bsnes
Sorry Byuu |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 24, 2006 6:18 pm Post subject: |
|
Nice follow-up tetsuo. There goes the 1 known bug, but it's still not the weekend yet.
I'm testing more U roms today, but for the last hour or so I played
Arkanoid to make sure the level 22 gfx bug in zsnes does not also occur
in bsnes (it doesn't).
Regarding Uniracers not
working, is it possible your headers are messed up or absent on those
roms? Copiers need roms with clean headers, but emulators ignore them.
Use SNESTool or NSRT if so. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 6:21 pm Post subject: |
|
All
the roms where headerless, and special SWC header was added, they all
have the same header, so why would the beta work when the finals dont
if its a header problem?
too my dismea i found out
that NSRT is not able to add SWC headers and ucon64 cannot add them
either so i used snestool1.2
All other games worked fine, i dont think its a header problem
----
Also there doesnt seem to be a (J) version of unirally. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 24, 2006 6:32 pm Post subject: |
|
Well that's really odd. Why the heck wouldn't the game work on a copier :/ And you're right about the J region. Fixt.
By the way. I just tested your three confirmed bugs on .016 official.
Zan III and Yuujin are both fine in .016, so they appear to be
regression bugs. XIII Olympics still has the bug in .016. That info
ought to help. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Aug 24, 2006 6:42 pm Post subject: |
|
tetsuo55, SNEeSe does not support special chip games.
_________________
FF4 research never ends for me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 24, 2006 7:06 pm Post subject: |
|
tetsuo55 wrote: |
Sorry Byuu |
Sorry for what? Not testing NTSC games on an NTSC system so that the
bugs could be properly verified? There are CPU speed differences and
vblank frame delay differences that could easily cause your results to
not match hardware. Even if you have some rigged up toggle switch, I
wouldn't trust it vs using it on an NTSC system. I will test with my
UFO since nobody else has.
For one, PAL hardware runs 312 scanlines instead of 262, so it has more
time for vblank. I bet if I force those two games into PAL mode, they
will work fine in current bsnes.
And on the bright side, while other emulators are getting bug reports
of games crashing and displaying full screens of garbled tiles, I'm
getting nitpicks about two tiny red dots appearing on the bottom right
of the screen when they shouldn't. That's actually good news, not bad :)
Anyway, I'm not worried about it. They probably are bugs. Report it as
bugs or don't, your call FitzRoy. I'm getting 0.017 out this weekend,
and then I'm going to start working on a dot-accurate PPU core. Expect
that to take at least two years to be usable. No exaggeration. And
that's assuming I succeed at all.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 7:21 pm Post subject: |
|
Sorry for raising the buglist by at least 1 
i know the 2 others still have to be verfied against NTSC  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 24, 2006 7:32 pm Post subject: |
|
Hmm,
every oddity we've noticed thus far arising from the scpu addition has
been a regression bug, and something tells me these will end up being
no different. Anyway, I agree that they still need to be verified on
the native system. I never added them because of that. I won't have my
tototek cart until next week, so I'm sorry you had to do this yourself.
And before you consider that 2 year project, I really wish you'd to
consider adding the special chips that you're capable of doing. I know
about SA1 and FX, but is there hope for the others? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 8:04 pm Post subject: |
|
FitzRoy wrote: |
And
before you consider that 2 year project, I really wish you'd to
consider adding the special chips that you're capable of doing. I know
about SA1 and FX, but is there hope for the others? |
*nods*
----
Winter Olympic Games - Lillehammer '94 (E) has been verfied on hardware
so that can be added to the list, both E and U did not show the black
bar
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 24, 2006 8:07 pm Post subject: |
|
What
others? You know of any *good* special chips that aren't emulated?
DSP-3/4 is too experimental for my tastes and probably mostly in asm --
if you want to prove me wrong and link to pure c++ cores, please do :D
The anonymous people who emulated these two chips did an awesome job,
but I don't want to add incomplete stuff and end up with bugs I cannot
fix myself, eg like in MMX2.
ST01n lacks any good games for them. SPC7110 would require a special
devsystem so I could (try to) RE the decompression. BS-X, too little
info. ST, give me the cart mapping info and I'll add it.
Extra controllers, all requires a mouse but the multitap. I'm not adding anything requiring a mouse anytime soon.
SGB, Game Genie, ... no. Maybe in a few years.
SFX, maybe in a few years.
SA-1, probably never. Marvelous may be cool, Kirby 3 may be nice (if
slow), and SM:RPG may be popular (despite sucking), but none of the
other games are any good to warrant taking several months/years away
from core SNES emulation. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 24, 2006 8:24 pm Post subject: |
|
okay...
Question about libco, could it be combined with multicore cpu'sfar faster results??
What about things like sse4 and 64bit? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 24, 2006 11:47 pm Post subject: |
|
Actually,
C4 and DSP1 turned out alright in the end, didn't it? So long as Nach
didn't mind helping you fix that. You also won't have to worry about it
messing up the buglist. I would include a new section called partial
hardware support. It's better than having nothing, since there are not
likely to be many major developments. Plus that, would those fixes have
even been made or discovered if you hadn't tried to emulate these in C++?
It's strange to me that the zsnes team has been porting asm code to C,
but the recent additions of DSP3/4 are in ASM? Super Sleuth seems to
have partial support, but maybe you and Overload could work together on
it? SPC7110 sounds hopeful. If the ST chips can be added, I'd love to
see them, despite the fact that the games aren't too good. Supporting
more games is good, even if you happen to dislike them. I mean hey,
they can't be worse than dungeon master
Since I'm a user, if I had to choose between getting more game support
first, or a more accurate PPU, I'd choose the games. If you just do
what you can, I'll bet nobody but you would be disappointed 
And just getting multitap is fine for the peripherals. Lots of good games use this, too.
@tetsuo: I can answer the second question. SSE2 was made a compile-time
option because people with older processors couldn't even run bsnes
with it. 64-bit would probably be pointless and make bsnes incompatible
for LOTS of people. And byuu has said he isn't going to offer a zillion
different versions of his emu. Don't worry about your fps dropping, the
official .017 release will be faster than the wips. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Aug 25, 2006 6:46 am Post subject: |
|
i
was actually thinking more into the future, now that conroe is out
there are some changes in the world of CPU, for one its performance
with existing code is excelent, and binaires specifically compiled for
conroe chips should be even faster!
with cpu's like conroe and beyond in mind, i bet that even the new ppu could get 60/60 fps
for multi cpu i was thinking
1 thread does syncing
1 thread does cpu
1 thread does spu
1 thread does ppu
Even if its only 1 fps faster with this setup, in the future i think we
could gain a lot, just think about it, 32 core cpu's are on the way, we
should be able to emulate everything more accurately |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Aug 25, 2006 12:11 pm Post subject: |
|
tetsuo55 wrote: |
i
was actually thinking more into the future, now that conroe is out
there are some changes in the world of CPU, for one its performance
with existing code is excelent, and binaires specifically compiled for
conroe chips should be even faster!
with cpu's like conroe and beyond in mind, i bet that even the new ppu could get 60/60 fps
for multi cpu i was thinking
1 thread does syncing
1 thread does cpu
1 thread does spu
1 thread does ppu
Even if its only 1 fps faster with this setup, in the future i think we
could gain a lot, just think about it, 32 core cpu's are on the way, we
should be able to emulate everything more accurately |
byuu wrote: |
While
a multi-core CPU system allows multiple threads to execute
simultaneously, allowing for a major speed advantage, it also adds a significant overhead to program development by requiring programs to carefully avoid conflicts such as both threads accessing the same data at the same time. It
also requires a tremendous overhead to switch between threads, as the
operating system has to handle this for the application.
A common argument against cooperative multithreading is that the cost
of switching threads is actually very small. And in relative terms to
modern CPUs, a single thread switch is indeed fast enough to be
irrelevant. However, the overhead continues to increase as more and more thread switches occur per second.
The common rebuttal here is that programs should be written to not
require more than a few thread switches per second. In an ideal world,
sure, this would be no problem. But shouldn't we be designing our
programs around what we want them to do, and not around the programming
language being used? For
programs that must switch threads millions of times a second, we simply
must eliminate the need for the operating system to get involved.
When the OS gets involved, it forces the programming code to switch
between user mode and kernel mode, which is a very slow operation and
is ultimately unnecessary for certain types of applications. Luckily,
another form of multithreading exists: cooperative multithreading.
Cooperative multithreading shifts the focus of controlling each thread
from the operating system to the program. In other words, the OS is
completely unaware of cooperative threads within a program, and thusly
does not attempt to switch between such threads itself. The program has
to do this manually. This also makes running more than one cooperative
thread at the same time on a multi-core CPU system impossible. However,
it has its advantages. By shifting control to the program, rather than
the OS, you gain the ability to fine-tune threading to your programs'
particular needs. No
longer is it necessary to switch between user mode and kernel mode, for
example. A thread switch for cooperative multithreading is several
times faster as a result.
Now, why
would you want to switch threads millions of times a second? I'm sure
there are lots of reasons. Here's mine, and the reason I wrote libco
[...] |
http://byuu.cinnamonpirate.com/?page=libco&bg=2&browser= 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Sat Aug 26, 2006 12:22 pm; edited 1 time in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Aug 26, 2006 9:48 am Post subject: |
|
ok i understand it now, thanks.
EDIT:
Almost finished with T, 26 roms to go...
found a few graphics bugs but all supported hardware games worked up till now
need to verify the bugs on hardware first, although none of them occur in zsnes. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 27, 2006 5:47 am Post subject: |
|
bsnes v0.017 released.
Since the Winter Olympics bugs is so trivial and not tested on NTSC
hardware, I've decided not to mention it in the readme with this
release. Besides, I worked too hard to get that list down to one bug to
have you guys ruin it for me at the last minute :P
http://byuu.org/
Also redesigned the site to be a little more simplistic and upped the
contrast of all the colors. I'm planning on adding a low-contrast
stylesheet for those who prefer darker colored sites. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Aug 27, 2006 5:54 am Post subject: |
|
Your timing sucks byuu. 
_________________
FF4 research never ends for me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 27, 2006 7:24 am Post subject: |
|
Why's that? I'm in no competition with SNEeSe. In fact, I'm trying out the latest release right now :)
For those visiting my site about an hour ago, I thought I had
reintroduced that sound gibberish bug, but it went away when I
restarted the emulator... go figure x.x
The binary and source are back up on my site again. |
|
Twomp New Member
Joined: 27 Aug 2006
Posts: 1
|
Posted: Sun Aug 27, 2006 9:24 am Post subject: |
|
First of all I want to say hi to all and especially Byuu for his awesome emulator.
The new version is very good and very fast!!!
With the last version I couldn't run a normal game full speed, now I can run Mario Kart full speed.
I have a suggestion: you should disable the screensaver in widowed
mode. To do it you must simply intercept the WM_SysCommand windows
message and if the command is SC_SCREENSAVE (screensaver) or
SC_MONITORPOWER (shut down the monitor) and set the message resul to 0.
I have a sammple code but unfortunately is in delphi (i never wrote a gui program in C or C++):
Code: |
with TWMSysCommand(Message) do
if ((Msg=WM_SysCommand) and ((CmdType=SC_SCREENSAVE) or (CmdType=SC_MONITORPOWER))) then
begin
Message.Result:=0;
end
else
WndProc(Message);
|
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 27, 2006 10:26 am Post subject: |
|
Byuu great work on .17 the binary is a lot smaller and the emulation is a lot faster.
Your new site layout is much easyer to read but, has also lost its charm.
Also i would like to note that the pal version of Winter Olympics is
100% verfied to not have the bug on hardware, eventhough its trivial
I finished with T, some things i still need to verify but here is a list of stuff i can not 100% verify
Taz-Mania (U) [!].smc
A green line that looks like the gras texture constantly passes over the road
Zsnes looks OK
NEEDS HARDWARE VERIFICATION
This happens on the E version too, but i have to verify on hardware.
Top Gear 2 U/E/J
Black lines appear in bridge
Ok in Zsnes
NEEDS HARDWARE VERIFICATION
All the bugs i found so far look like the Winter Olympics bug, there is
a good chance they are all related somehow, and maybe could all be
fixed with 1 bugfix
Full report on T to follow after hardware verification
The best news is all supported hardware games worked!!!, so
compatibility in 1 player mode excluding small graphic bugs is 100% for
T-Z
S is going to take even longer, i guess there is going to be about 600-700 roms in there. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sun Aug 27, 2006 10:44 am Post subject: |
|
Super
Mario Kart (the only game I test, let's face it ! :p) has a 1-line
flickering at the bottom of the first half screen, during race.
(And I still have that gamepad problem, unfortunately...) |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 27, 2006 10:59 am Post subject: |
|
Flickering
line verfied in Bsnes, need to test on hardware, but im sure i dont
remember a flickering line there. We have Mario Kart running all day in
the store. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sun Aug 27, 2006 11:02 am Post subject: |
|
Having played SMK for years when I was a kid, I'm also pretty sure it doesn't happen on real hardware. |
|
kooshkaboose New Member
Joined: 27 Aug 2006
Posts: 2
|
Posted: Sun Aug 27, 2006 4:28 pm Post subject: |
|
Kirby Superstar (U) [!] isnt working in v0.017  |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sun Aug 27, 2006 4:32 pm Post subject: |
|
kooshkaboose wrote: |
Kirby Superstar (U) [!] isnt working in v0.017  |
That's because SA-1 games aren't supported yet(?) by bsnes.
|
|
kooshkaboose New Member
Joined: 27 Aug 2006
Posts: 2
|
Posted: Sun Aug 27, 2006 4:54 pm Post subject: |
|
EMu-LoRd wrote: |
kooshkaboose wrote: |
Kirby Superstar (U) [!] isnt working in v0.017  |
That's because SA-1 games aren't supported yet(?) by bsnes.
|
yes, i just read the readme.. probably should have done that before.
i noticed that starfox is the same case, but i could swear i played it on
an emu before..
|
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Sun Aug 27, 2006 5:08 pm Post subject: |
|
kooshkaboose wrote: |
EMu-LoRd wrote: |
kooshkaboose wrote: |
Kirby Superstar (U) [!] isnt working in v0.017  |
That's because SA-1 games aren't supported yet(?) by bsnes.
|
yes, i just read the readme.. probably should have done that before.
i noticed that starfox is the same case, but i could swear i played it on
an emu before..
|
Other emulators have SA-1 support.
_________________
_-|-_
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Aug 27, 2006 7:22 pm Post subject: |
|
And Super FX support.
_________________

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

Joined: 03 Mar 2006
Posts: 14
|
Posted: Sun Aug 27, 2006 8:04 pm Post subject: |
|
Erm,
any reason why sound isn't working for me?... logging audio data
works... but I can't hear anything while a game is running. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 27, 2006 8:10 pm Post subject: |
|
Quote: |
Erm,
any reason why sound isn't working for me?... logging audio data
works... but I can't hear anything while a game is running. |
That is indeed a strange issue. Perhaps your soundcard lacks 32khz support? What kind of soundcard do you use?
Quote: |
Other emulators have SA-1 support. And Super FX support. |
Alright, I get the hint -_-
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Sun Aug 27, 2006 8:19 pm Post subject: |
|
byuu wrote: |
Quote: |
Erm,
any reason why sound isn't working for me?... logging audio data
works... but I can't hear anything while a game is running. |
That is indeed a strange issue. Perhaps your soundcard lacks 32khz
support? What kind of soundcard do you use?
|
http://www.emu.com/products/product.asp?product=10447
This is also a recent problem, because previous versions of bsnes
worked fine (can't think of which version off the top of my head)
The card should be automatically resampling to 44.1 or 48khz,
considering it does that when I play the 32khz file that bsnes
creates...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Aug 27, 2006 10:05 pm Post subject: |
|
.017 hath arrived! 
vkamicht wrote: |
The card should be automatically resampling to 44.1 or 48khz,
considering it does that when I play the 32khz file that bsnes
creates...  |
Uhhhh, no audio card should
do that, but you can download .016 and tell us if that one works. Also,
try deleting the cfg file, and make sure you don't have "mute sound
output" enabled.
Oh, and I hope that suggested screensaver supression code (a) works and (b) is implimented for the next version.
|
|
chipzoller Rookie
Joined: 27 Jan 2005
Posts: 16
|
Posted: Mon Aug 28, 2006 1:31 am Post subject: |
|
Byuu,
version 0.017 is a VAST improvement over 0.016 in terms of bugs and
speed. I salute you for your excellent hard work. Well done. I very
much look forward to your continuing progress with this project.
many thanks! |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Aug 28, 2006 9:42 pm Post subject: |
|
I found a (cosmetic) issue in bsnes 0.017:
The pictures of the SNES controller in the Input configuration and the artwork in the About box are gone.
Not a big deal,but it looks kinda ugly now. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 28, 2006 10:12 pm Post subject: |
|
Agreed that it looks much worse, but I did it to save bandwidth.
The images were taking 337kb of space in both the main ZIP and source
ZIP. Since MS GDI can *only* load BMPs, this was a direct 337kb
executable size increase for two images, so until I can find a better
way to both embed the images and store them in source... they shall be
omitted :/ |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Aug 28, 2006 10:24 pm Post subject: |
|
Just as I thought 
I don't care about the artwork in the About Box,but there should be at
least *some* kind of SNES controller layout description (even if it's
in ASCII Art in the Input Config.
This won't increase the size of the .exe at all.
Also,I would like to see a button that clears all primary and secondary
key mappings of all controllers with just one button press.Clearing all
controls manually button by button can be tedious. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Aug 28, 2006 10:33 pm Post subject: |
|
byuu wrote: |
Agreed that it looks much worse, but I did it to save bandwidth.
|
Well I'm back from my vacation. Someone else could host for you...
byuu wrote: |
The images were taking 337kb of space in both the main ZIP and source
ZIP. Since MS GDI can *only* load BMPs, this was a direct 337kb
executable size increase for two images, so until I can find a better
way to both embed the images and store them in source... they shall be
omitted :/ |
Can it load BMPs from memory? If so you can include a PNG file or
something, and convert it to BMP in memory. Heck, just zlib compress it
and and unzlib it in memory.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Aug 28, 2006 10:47 pm Post subject: |
|
What
makes me thrilled with byuu's work is when I load Super Castlevania 4.
The sound is very accurate to what I remember, while other top
emulators have pretty messed up sound for this game. The patched
BS-Zelda rom works fantastic on this release too!
I look excitedly forward a future release that fixes the sound issue during tripple buffering. 
Excellent work thus far! |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Aug 28, 2006 10:52 pm Post subject: |
|
FirebrandX,have you ever tried SNeESe?
It's sound emulation is *almost perfect* (even more accurate than
bsnes) You have to try the latest version and see for yourself  |
|
chipzoller Rookie
Joined: 27 Jan 2005
Posts: 16
|
Posted: Mon Aug 28, 2006 11:41 pm Post subject: |
|
Small request: Ability to rename video profiles once customized. |
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Tue Aug 29, 2006 12:00 am Post subject: |
|
byuu wrote: |
Alright, I get the hint -_- |
I was just pointing out that when he said he remembered playing sa-1 games before on an emu 
Still, OTHER EMULATORS SUPPORT SA-1 GAMES!
AND SUPER FX!
_________________
_-|-_
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 29, 2006 12:05 am Post subject: |
|
I'm
interested to know what games you think sneese does better in sound vs
bsnes. zsnes and snes9x were a far cry, but these two sounded the same
in wav output tests. I'm on an egosys Juli@ with Sennheiser HD580s.
FirebrandX wrote: |
What
makes me thrilled with byuu's work is when I load Super Castlevania 4.
The sound is very accurate to what I remember, while other top
emulators have pretty messed up sound for this game. The patched
BS-Zelda rom works fantastic on this release too! |
That's not what makes me thrilled. What makes me thrilled is this + a
dream gui + almost every useful configuration option + the most
accurate emulation and game support. After so many years of snes
emultion, this is the all-in-one I was clamoring for 12 months ago when
this thread began.
kick wrote: |
Also,I
would like to see a button that clears all primary and secondary key
mappings of all controllers with just one button press.Clearing all
controls manually button by button can be tedious. |
Already recommended it. Sort of. Yours would be too dangerous to put
near the others. I only recommended a Primary + Secondary clear button.
If the mouse could be made to highlight more than one entry, you could
very easily wipe out a whole controller setup without the danger of
having an apocalypse button.
Last edited by FitzRoy on Tue Aug 29, 2006 12:24 am; edited 4 times in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Aug 29, 2006 12:12 am Post subject: |
|
MisterJones wrote: |
byuu wrote: |
Alright, I get the hint -_- |
I was just pointing out that when he said he remembered playing sa-1 games before on an emu 
Still, OTHER EMULATORS SUPPORT SA-1 GAMES!
AND SUPER FX!
|
The performance characteristics would be awful in BSNES... Snes9x seems
to be slightly ahead in the SuperFX support, but SuperFX has not been
perfectly emulated to this date (I could be wrong here).
_________________
FF4 research never ends for me.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Aug 29, 2006 3:41 am Post subject: |
|
One little feature request:
I'd like to be able to load a ROM by drag-n-drop of a .zip/.smc/.jma file in the bsnes window.
Almost all emulators support this feature and it's quicker for me for
example to drag and drop a file from 7-zip File Manager (Total
Commander-style) to bsnes than opening the ROM load dialog and
navigating to the folder.
I also would like an option to set the sound latency value (I don't know what bsnes is now using as default)
I compared the sound of SNEeSe and bsnes and just noticed how the sound
in SNEeSe was noticably better (even with that sound skip problem I'm
having). SNEeSe sounds a bit cleaner,more dynamic,with emphasized bass
and highs. Are you also hearing a difference or it's just my
imagaination? 
It really sounds different to me.
Last edited by kick on Tue Aug 29, 2006 7:47 am; edited 1 time in total |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Aug 29, 2006 4:13 am Post subject: |
|
Nach wrote: |
byuu wrote: |
Agreed that it looks much worse, but I did it to save bandwidth.
|
Well I'm back from my vacation. Someone else could host for you...
byuu wrote: |
The images were taking 337kb of space in both the main ZIP and source
ZIP. Since MS GDI can *only* load BMPs, this was a direct 337kb
executable size increase for two images, so until I can find a better
way to both embed the images and store them in source... they shall be
omitted :/ |
Can it load BMPs from memory? If so you can include a PNG file or
something, and convert it to BMP in memory. Heck, just zlib compress it
and and unzlib it in memory.
|
It's using d3dx library to save PNG screen shots, so you're looking at
about 100KB of extra binary code just for libpng, and then the images
only compress to 175KB, so that's barely 100KB savings.
On the other hand, just by reducing snes_controller.bmp to 8bpp with
Fireworks without dithering, and then converting the result to RLE8
BMP, we shave off 48,378 bytes.
Then if you compress about.bmp to JPEG using Fireworks, at 85 quality,
the result is very slightly blurred, but you'd have to actually toggle
between the original and output to notice the difference. Shaved off
another 259,599 bytes. Then for less than 10KB, you can use an OLE
function to import that JPEG as an IPicture object, copy the resulting
bitmap out for the life of the dialog, then destroy the object. I'll
share that code in a minute.
kick wrote: |
One little feature request:
I'd like to be able to load a ROM by drag-n-drop of a .zip/.smc/.jma file in the bsnes window.
Almost all emulators support this feature and it's quicker for me for
example to drag and drop a file from 7-zip File Manager (Total
Commander-style) to bsnes than opening the ROM load dialog and
navigating to the folder. |
Or you can apply one of the source patches I've made, which adds both Rar and 7-Zip support.
kick wrote: |
I
just noticed how the sound in SNEeSe was noticably better than in bsnes
(even with SNEeSe having those sample skipping/sync problems). SNEeSe
sounds cleaner,more dynamic and with emphasized bass and highs. Are you
also hearing a difference or it's just my imagaination? :D
It really sounds different to me. |
All of the terms you use are more commonly associated with placebo.
Cleaner? More dynamic? Emphasized bass and highs? Sheesh. Maybe if you
could capture the output of SNEeSe and actually ABX the difference, I'd
take you more seriously. :P
Anyway, bsnes v0.017 binary, and source patches
which I've separated all of the changes into. Although I separated them
from one big patch, and I haven't tested whether they all apply cleanly
as separate patches. GUI changes for the image compression and JPEG
loading coming soon.
Last edited by kode54 on Tue Aug 29, 2006 4:33 pm; edited 2 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 29, 2006 4:36 am Post subject: |
|
kode54 wrote: |
All of the terms you use are more commonly associated with placebo.
Cleaner? More dynamic? Emphasized bass and highs? Sheesh. Maybe if you
could capture the output of SNEeSe and actually ABX the difference, I'd
take you more seriously. |
Indeed. And we already did comparisons months ago with wav outputs of
the first 90 seconds of Super Castlevania IV on most emulators, which
also included a digital recording from a real snes. The resulting
discussions are in this thread somewhere, but I doubt the files links
are still alive.
On another note, I've added tetsuo55's latest bug findings. These are
obvious in my opinion. The middle line in Taz-Mania is not aligned
correctly. The grass is being drawn where the road should be. Top Gear
2's bridge should be solid, but there are black lines being introduced.
Both of these are also regression bugs, as they do NOT occur on .016.
The consensus on Super Mario Kart seems to be that this is a bug as
well. I, too, played this game a great deal and don't remember any
flickering. It's going on the list.
The XIII Olympics bug is not a regression bug, but if you choose
training mode, the screen looks fine. But once you choose an event,
some fancy effect triggers the black line to appear. tetsuo confirmed
that this does not happen on the E version of the game on an E console.
So it's on the list as well.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Aug 29, 2006 5:34 am Post subject: |
|
kick wrote: |
FirebrandX,have you ever tried SNeESe?
It's sound emulation is *almost perfect* (even more accurate than
bsnes) You have to try the latest version and see for yourself  |
Except I found SneESe to have a lot of visual emulation problems. It ran quite poorly for me.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Aug 29, 2006 5:43 am Post subject: |
|
FirebrandX wrote: |
kick wrote: |
FirebrandX,have you ever tried SNeESe?
It's sound emulation is *almost perfect* (even more accurate than
bsnes) You have to try the latest version and see for yourself  |
Except I found SneESe to have a lot of visual emulation problems. It ran quite poorly for me.
|
True, but no emulator is really perfect right? 
It's been worked on, but for games it has no problems in, it does sound rather good.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 8:21 am Post subject: |
|
Super
Mario Kart will likely never be fixed properly. It makes heavy use of
the DSP-1 which, while emulated bit-perfectly, does not include timing
emulation in any way. So don't expect the flickering to ever fully go
away.
As of now, the DSP-1, DSP-2 and C4 all suffer from the same bug.
As far as single complete line errors, these are also most likely due
to the scanline-based renderer. I'll try moving the render clock
position for the time being. In addition, I'll add a config file option
so these bugs can be isolated and classified.
Please note that when/if I add a dot based renderer, lots of
"micro-line" errors are going to start appearing, such as Metroid 3's
status bar showing 3-4 pixels of black onto the next line that should
be the overworld. Lots and lots of games use IRQs for hblank effects
and severely overlap it and write during active display. We know this
works on hardware (mid-scanline writes), and most TVs cut off too much
to see it. Of course, some of these could be real bugs. It'll be
tricky, indeed.
Quote: |
All of the terms you use are more commonly associated with placebo.
Cleaner? More dynamic? Emphasized bass and highs? Sheesh. Maybe if you
could capture the output of SNEeSe and actually ABX the difference, I'd
take you more seriously. :P |
It's been well known for a long time that SNEeSe is/was king of SNES
audio. And for good reason, Charles Bilyue and Brad Martin spent a ton
of time researching audio a great deal. However, anomie's DSP core is
based heavily off of their work, and bsnes' is almost directly derived
from anomie's work (I'd call it more of a port than a rewrite). In
addition, it's had countless bugfixes by the talented DMV27.
Therefore, I have to agree with kode54. With no confirmed audio bugs in
bsnes, I'm also very interested in actual wave graphs showing problems
in bsnes (FitzRoy can use his S/PDIF connection to confirm, hopefully).
Not to brag, but so that I can fix the problems and catch up to SNEeSe
eventually one day.
kode54, I don't want to add OLE stuff to bsnes. I will simply remove
the about image, as it isn't really necessary anyway. The controller
image sounds like a good idea.
Also, in the future, could you guys include updated files as well as
those diff files? I don't use diff, so it's kind of a pain to read
those things all the time. I would like the complete files if possible.
And I also prefer zip format for things. They're just text files, so no
need to compress with 7-zip.
Actually, I'd like your recent changes as well in ZIP as complete files, there's way too many changes.
I'd also like to know what you've done and why to DirectSound. I don't
see why you want to use WaitForSingleObject as well as a manual event
loop.
I don't generally enable exceptions because it slows the code down and
is only used by JMA. My local builds do not include ZIP+JMA support, so
there's no reason to slow down the emulator.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Aug 29, 2006 8:47 am Post subject: |
|
byuu wrote: |
Super
Mario Kart will likely never be fixed properly. It makes heavy use of
the DSP-1 which, while emulated bit-perfectly, does not include timing
emulation in any way. So don't expect the flickering to ever fully go
away.
As of now, the DSP-1, DSP-2 and C4 all suffer from the same bug. |
I'm disappointed.. it sounds like adding more special chips will
exhibit the same problems? (If true, well I guess there's a reason to
use other SNES emus of course )
Quote: |
I
don't generally enable exceptions because it slows the code down and is
only used by JMA. My local builds do not include ZIP+JMA support, so
there's no reason to slow down the emulator. |
Oh, you're gonna make the ROM whores cry. "OMG, WHERZ MY 7Z/RAR/INSERT SILLY FORMAT HERE SUPPORT"
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 9:12 am Post subject: |
|
Deathlike2 wrote: |
I'm
disappointed.. it sounds like adding more special chips will exhibit
the same problems? (If true, well I guess there's a reason to use other
SNES emus of course :wink: ) |
Precisely. You can add all the timing hacks you want to them.
Quote: |
Oh, you're gonna make the ROM whores cry. Twisted Evil "OMG, WHERZ MY 7Z/RAR/INSERT SILLY FORMAT HERE SUPPORT" |
Yeah, not sure if I want to add kode54's patches for RAR/7z support or not. I personally can't stand the formats.
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Aug 29, 2006 9:49 am Post subject: |
|
Byuu, why can't you emulate the timing properly ?
Because it would make bsnes much slower, or because you lack some information/data ? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 9:52 am Post subject: |
|
Quote: |
Byuu, why can't you emulate the timing properly ?
Because it would make bsnes much slower, or because you lack some information/data ? |
I lack information, and more importantly hardware to test this on.
Furthermore, the DSP-1 emulation core is written in such a way as to
make this very complex to add. I'm more interested in emulating the
base SNES than the DSP-1, sorry. This is why I didn't want to add any
special chips period, I do it as a favor to everyone else who use the
emulator. I make zero claims as to the accuracy of special chip code.
Quote: |
Super Mario Kart (E, J, U) - a horizontal line flickers beneath the top image |
DSP-1 timing related. I am not researching this unless someone donates adequate hardware to test DSP-1 on to me.
Quote: |
Taz-Mania (E, U) - horizontal line in middle of screen is screwy (does not occur in .016)
Top Gear 2 (E, J, U) - horizontal black lines appear on bridges (does not occur in .016) |
Both fixed by setting render_line position to HC=192 from HC=128. These
games are basically writing to the display well
after hblank ends. Expect these bugs to happen on real hardware, but be
more like partial lines. You wouldn't notice Taz-Mania because the road
doesn't often (ever?) touch the left-hand side of the screen.
Requires dot accurate PPU emulation. Otherwise, we're just playing
games moving this render position back and forth, causing different
bugs to appear each time. The scanline renderer itself is basically a
huge speed hack, end of story.
If you want to keep track of these bugs, or keep them in a separate
list, or not; that's fine by me. I'm not going to research them until I
have my dot renderer, sorry. In the mean time, I'll leave render_line
at HC=192 like v0.016, since it seems more compatible.
Quote: |
XIII Olympic Winter Games, The - Lillehammer 1994 (E) - horizontal black line appears on event screen. |
Alright, I'll look into it.
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Tue Aug 29, 2006 10:36 am Post subject: |
|
Sound
works for me with v0.013, and I'm fairly certain v0.014 & 5 as
well, but not the WIP versions. I remember having this problem (sound
not working at all) with some WIP versions until the final was
released, where it worked fine. This is not the case with 0.017...
where I don't get sound output at all. Yes, mute sound is not checked. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 10:43 am Post subject: |
|
I
don't have your sound card to test with. It could be any number of
problems, but my DSound driver uses standard DirectSound API calls,
exactly as defined in the DirectSound SDK sample source code.
If it does not work for you, I am unfortunately unable to assist,
sorry. Nothing has changed in src/ui/audio/dsound.cpp since the last
release except for a call to Sleep(1) that keeps processor usage from
hitting 100% when the emulator is running at full speed.
Side note: Zan3 and Yuujin2 are not fixed by moving render_line
position. Both are fixed by allowing VRAM writes outside of vblank,
which isn't going to happen. I will have to look into this more. I
can't see Yuujin2 on a copier, and I'm too apathetic to test Zan3. I'm
guessing it's the fault of sCPU not having H/DMA sync timing (and using
a rounded average sync delay). Mostly a complexity issue of adding that
back in, I want the code for it to be readable unlike bCPU's code here.
Still trying to think of a good way to do it. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Aug 29, 2006 4:28 pm Post subject: |
|
byuu wrote: |
kode54,
I don't want to add OLE stuff to bsnes. I will simply remove the about
image, as it isn't really necessary anyway. The controller image sounds
like a good idea. |
Is there any particular reason? It should work fine all the way down to
Windows 98, and possibly Windows 95 with Internet Explorer installed.
byuu wrote: |
Also,
in the future, could you guys include updated files as well as those
diff files? I don't use diff, so it's kind of a pain to read those
things all the time. I would like the complete files if possible. |
I'll include a list in the future, but for now, you can search or grep
the files for "diff -u". I only provide patches since I assume you
would prefer a summary of the changes, rather than having to compare
the files yourself, but whatever.
byuu wrote: |
And I also prefer zip format for things. They're just text files, so no need to compress with 7-zip. |
Or maybe you would prefer ZIP in ZIP, or .tar.something, since solid compression is better for text files.
byuu wrote: |
Actually, I'd like your recent changes as well in ZIP as complete files, there's way too many changes. |
Sure.
byuu wrote: |
I'd
also like to know what you've done and why to DirectSound. I don't see
why you want to use WaitForSingleObject as well as a manual event loop. |
There's probably no reason for that, as it's not likely that the event setup will fail.
byuu wrote: |
I
don't generally enable exceptions because it slows the code down and is
only used by JMA. My local builds do not include ZIP+JMA support, so
there's no reason to slow down the emulator. |
You can always just enable exceptions for the relevant source files,
namely cart.cpp and the JMA, Rar, and 7-Zip readers, and disable them
for everything else.
Anyway, new binary, source, and patches uploaded. The only change is the addition of the original artwork, using the evil OLE loader. Use it, or don't.
Edit: Woohoo, for the patches, tar.gz is only about 1KB larger than
tar.bz2, and then non-solid ZIP is only 1KB larger than that, so ZIP it
is.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 4:44 pm Post subject: |
|
Ok, Winter Olympics...

... in bsnes v0.017, SNEeSe v0.853, and SNES9x v1.502.
Line error at X=128-255, Y=128.

... in ZSNES SVN + v1.42.
Line errors at X=0-255, Y=127-128.

... in Super Sleuth v1.04e.
I do not see the black line error, but the screen glitches badly shortly after.
---
In bsnes, the background image is made entirely from OAM OBJ priority 0.
By disabling it, the entire background screen goes black so I cannot
determine if determine if that layer is the source of the program.
However, disabling OAM1-3+BG1-4 does not prevent the black line from appearing.
So it's either a problem with OAM pri0 or with something like windowing or add/sub effects. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 29, 2006 5:32 pm Post subject: |
|
Byuu, should i still submit everything i find?
You could check if they fall under bugs that will be fixed by the
rewrite, or which ones need to be looked at seperately
unless you have some way for me to discover which is which? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 29, 2006 5:43 pm Post subject: |
|
Yes,
thank you. We might as well categorize all of the scanline-render
errors now. Though I won't be able to fix them properly until the PPU
rewrite is finished. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 29, 2006 6:30 pm Post subject: |
|
You're
doing a good job, tetsuo. You've noticed some things I probably
wouldn't have. It's definitely important to keep going with this
bughunt. 3500 roms is a lot of games, and it will take some time, but
whatever's left needs to be found. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Aug 29, 2006 7:30 pm Post subject: |
|
Okay
i will continue my bughunt, this are gonna slow down a little though
over the coming weeks, as i have finally got a place for myself.
Going to move in there over the coming month, need to paint and stuff,
but once there i will finally have my own little corner for research
and testing (i do a lot of hardware repair on consoles too, Although snes are usually quite hopeless) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 30, 2006 5:13 am Post subject: |
|
kode54, I can't add your DirectSound code. It fails to work on my system here:
Code: |
if(!FAILED(dsb_b->QueryInterface(IID_IDirectSoundNotify, (void **)&dsbNotify))) { |
This fails and dsbNotify is null.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 30, 2006 5:58 am Post subject: |
|
Alright
byuu, I hope you see this because it's really important. Remember how I
reported that my soundcard was experiencing crackling in all latency
settings higher than the most extreme of 48ms? Kode's .017 build with
the directsound changes fixes this. I get no crackling on any setting.
I have no idea what he did, but it is absolutely wonderful to have this
fixed and I hope one of you can figure out why so it gets included.
Thank you! |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Aug 30, 2006 6:22 am Post subject: |
|
byuu wrote: |
kode54, I can't add your DirectSound code. It fails to work on my system here:
Code: |
if(!FAILED(dsb_b->QueryInterface(IID_IDirectSoundNotify, (void **)&dsbNotify))) { |
This fails and dsbNotify is null.
|
Quick google comes up with this:
http://www.gamedev.net/community/forums/topic.asp?topic_id=202998
This appears to be the same problem you are experiencing byuu (I could be wrong).
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 30, 2006 7:50 am Post subject: |
|
FitzRoy wrote: |
Kode's .017 build with the directsound changes fixes this. |
His ring buffer seeking is also backwards, meaning the sound latency is
4-5 frames behind in his build. That's probably why it works better for
you :/
On a similar note, I tried redoing some of the audio code myself while
I wait for kode54 to determine what the problem with my notify event is.
Check out wip2 and let me know how it sounds for you, please.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 30, 2006 8:33 am Post subject: |
|
T
Untested > Tri-Star Super 8 BIOS (NES-SNES Adapter).7z, Total Football.7z (beta), Tinhead.7z (beta),
Tested > 167 roms
Problems found:
Taz-Mania (E).smc/Taz-Mania (U) [!].smc
A green line that looks like the gras texture constantly passes over the road
Zsnes looks OK
Looks fine on hardware
Top Gear 2 U/E/J
Black lines appear in bridge
Ok in Zsnes
Tested the E version on hardware, a black line appears here too for
about1/2 second a black line happens at the top of the bridge, but
never in the bridge, tested several times, black line always shows in
the exact same spot.
Toy Story (U) [!].smc +U/E
sometimes sound buzzes when the game is loading
Happend several times, with different region versions
Unable to test in hardware as NONE of the region version will go ingame on my snes
Games not working due to missing hardware support:
Taikyoku Igo - Idaten (J).smc
Black screen, SA-1
Takemiya Masaki Kudan no Igo Taishou (J).smc
Black screen, SA-1
Tengai Makyou Zero - Shounen Jump no Shou (J) [!].smc
black screen, SPC7110
Tengai Makyou Zero (J) [!].smc
black screen, SPC7110
Top Gear 3000 (E) [!].smc
Top Gear 3000 (U) [!].smc
Planet's Champ TG3000, The (J).smc
Black screen, DSP 4
Does anyone know how to upgrade the bios of a Super Wildcard DX, and if
the bios in the goodsnes set is actually "usable" and if not where i
might be able to find the bios? I now hjave 2 games that dont use
special chips that dont work, i hope the new bios will help. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Wed Aug 30, 2006 9:01 am Post subject: |
|
byuu wrote: |
On
a similar note, I tried redoing some of the audio code myself while I
wait for kode54 to determine what the problem with my notify event is. |
DirectSound interfaces prior to 8 require DSBCAPS_CTRLPOSITIONNOTIFY.
Although I thought DSBCAPS_GETCURRENTPOSITION2 was sufficient as well,
maybe it's better to use the other flag instead. Also, when using
buffer position notification events, it's probably a good idea to force
DSBCAPS_LOCSOFTWARE, as I've heard from another developer that buggy
drivers have been known to trigger events for the wrong buffers when
using hardware buffers. Maybe older Creative Sound Blaster Live!
drivers? Probably best not to chance it, heh.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 30, 2006 9:09 am Post subject: |
|
byuu wrote: |
FitzRoy wrote: |
Kode's .017 build with the directsound changes fixes this. |
His ring buffer seeking is also backwards, meaning the sound latency is
4-5 frames behind in his build. That's probably why it works better for
you :/
On a similar note, I tried redoing some of the audio code myself while
I wait for kode54 to determine what the problem with my notify event is.
Check out wip2 and let me know how it sounds for you, please.
|
Damn, it had to be something like that didn't it Oh well. I appreciate the help, but wip2 still behaves the same as official.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Wed Aug 30, 2006 12:16 pm Post subject: |
|
My
code also keeps a running write position and always writes new blocks
one frame ahead of the previously written block, regardless of the play
cursor. It only uses the play cursor to determine whether it should
wait before writing, in the event that other parts of the emulation
thread delay it past one frame, making the wait worse than not waiting.
Not really an ideal buffering scheme, but it seems to work slightly
better. Maybe I can get someone else to look at the code when they have
free time and see if it could be improved even more? |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Aug 30, 2006 6:01 pm Post subject: |
|
Worked out a bug in our line caching engine and:

Was right to begin with, just was not being displayed properly. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 30, 2006 8:36 pm Post subject: |
|
Winter Olympics:
Code: |
* OBSEL=62 <127,1260>
* OBSEL=63 <225, 480>
* OBSEL=62 <127,1280>
* OBSEL=63 <225, 500>
[ 12] 32x32,x= 0,y= 97,c=00c0,p=0,ns=0
[ 13] 32x32,x= 32,y= 97,c=00c4,p=0,ns=0
[ 14] 32x32,x= 64,y= 97,c=00c8,p=0,ns=0
[ 15] 32x32,x= 96,y= 97,c=00cc,p=0,ns=0
[ 28] 32x32,x=128,y= 97,c=00c0,p=0,ns=1
[ 29] 32x32,x=160,y= 97,c=00c4,p=0,ns=1
[ 30] 32x32,x=192,y= 97,c=00c8,p=0,ns=1
[ 31] 32x32,x=224,y= 97,c=00cc,p=0,ns=1 |
It changes OBSEL's OAM tiledata pointer during hblank at V=127. At this
point, the OAM data for V=128 would already be cached by the real SNES
PPU. Not so on emulators. Fixing the problem will require caching OAM
objects one line before drawing them.
This is something that's much better suited for a dot-based renderer,
but can be done easily enough with a scanline-based renderer as well.
I would be very impressed if ZSNES were doing this already, considering
not even SNES9x does this. More probably, it works for similar reasons
that Uniracers does. But if not, that's truly impressive work.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Wed Aug 30, 2006 8:50 pm Post subject: |
|
I
noticed the sound in 0.017 crackles less if Triple Buffering is
ON,compared to 0.016 and the older 0.017 WIPs.Interesting.But I get a
big performance drop when I enable Triple Buffering and a Software
filter.With no filter,there's no difference between TB and no TB.
I would like to be able to set the DirectSound latency to 20ms = the
best value for Creative/E-MU cards and the default in many emulators.
Anything higher or lower than this is no good by my experience. <20 = crackling,40ms = laggy.
Testing this Kode54 build now.
Last edited by kick on Wed Aug 30, 2006 9:45 pm; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 30, 2006 8:54 pm Post subject: |
|
Interesting,
this PPU rewrite is sounding more important by the day. Still, I hope
you can fix this and possibly others with the scpu + scanline based.
I'm beginning to find more regressions concering mid-screen horizontal
line issues. Prince of Persia 2's title screen among them. tetsuo
confirmed taz-mania on (E). Attack of the horizontal line bugs! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 30, 2006 9:11 pm Post subject: |
|
FitzRoy wrote: |
Interesting,
this PPU rewrite is sounding more important by the day. Still, I hope
you can fix this and possibly others with the scpu + scanline based.
I'm beginning to find more regressions concering mid-screen horizontal
line issues. Prince of Persia 2's title screen among them. tetsuo
confirmed taz-mania on (E). Attack of the horizontal line bugs! |
Did you try these on wip2? Taz-Mania and Top Gear 2000 issues should be
gone. I've moved the dot render position back to HC=192 until I can
rewrite the PPU. Prince of Persia 2 should be the same as v0.016 now.
Also, you can consider Winter Olympics as "fixed" now, if you like.
I've moved OAM caching to Vn, and OAM rendering to Vn+1. I'll add this
to my main source tree tonight.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Aug 30, 2006 9:18 pm Post subject: |
|
It
currently works by toggling the next line to be cached on writes to
OBSEL. The next line can be cached setting the variable NextLineCache
to 1. See regsw.inc in reg2101w. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 30, 2006 10:45 pm Post subject: |
|
byuu wrote: |
Did you try these on wip2? Taz-Mania and Top Gear 2000 issues should be
gone. I've moved the dot render position back to HC=192 until I can
rewrite the PPU. Prince of Persia 2 should be the same as v0.016 now. |
Oh, excellent! I had not tested them. Consider them all removed.
I suppose I should test to see if the screensaver gets suppressed
tonight when I'm off. Never heard anything about that either. Another
pleasant surprise?
edit: nope
edit2: May have found another bug tonight. Sink or Swim (U) is
glitching up pretty badly in the levels. Just walk up and down the
ladders for a bit, it'll happen. Happens in .016 as well. Super Sleuth
seems to play the game fine. ZSNES gets a garbage screen and crashes to
desktop.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 31, 2006 6:36 am Post subject: |
|
Add F-1 Grand Prix to the list. I know what's wrong, but I cannot fix it.
The game sets VTIME to 9 on VCOUNTER=9, which triggers an IRQ. This
completely and utterly destroys my NMI / IRQ triggering methods.
I've spent the last three hours trying to figure out how the fuck
the SNES internally determines these triggers and can't come up with
even a working theory. I can't fix this, at least not any time soon.
Don't bug me about it or give me meaningless encouragement, please.
The following five IRQ rules are now all verified on hardware, and all false in every version of bsnes:
Code: |
Setting VTIME to current line for the first time triggers IRQ
Setting VTIME to current line for the second time does not trigger IRQ
Setting HTIME past HCOUNTER triggers IRQ at HTIME
Setting HTIME before HCOUNTER does not trigger IRQ
Lowering and raising NMITIMEN.[V/H]TIME triggers IRQ |
I went ahead and fixed Winter Olympics locally, but that's the best I can do.
EDIT: Setting DSBCAPS_CTRLPOSITIONNOTIFY works. But now I take a
significant (~15%) speed hit even when speed throttling is turned off,
by using the event notification code.
EDIT2: Ok, made a little progress on interrupts, in exchange for a
massive speed hit. Removed the need to have two separate IRQ/NMI
trigger points, so now I can allow IRQs to be triggered "instantly" in
a more correct fashion. But no luck trying to get it to actually do
this without breaking my various IRQ test ROMs.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 31, 2006 11:35 am Post subject: |
|
is there any point to running those tests on pal hardware. |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Thu Aug 31, 2006 5:34 pm Post subject: |
|
Earthworm
Jim 2 (Beta) has garbled sound during the intro and does not reach
in-game. Don't know if this game worked on real hardware, but it is in
NSRT's database.
Code: |
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Earthworm Jim 2 (Beta).smc
Name: _~__0k_______________ Company: Unlicensed
Header: None Bank: LoROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 24 Mb
Country: Unknown Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Bad 0x2241 != 0x0000 CRC32: C110A23A
MD5: DD84A2F97D4B9AC3108A62065DBD68F0
--------------------------Database--------------------------
Name: BETA Earthworm Jim 2
Country: Unknown Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Shooter |
_________________

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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 31, 2006 6:03 pm Post subject: |
|
Quote: |
Sink or Swim (U) is glitching up pretty badly in the levels. Just walk up and down the ladders for a bit, it'll happen. |
This is the same bug as F-1 Grand Prix. The same hackish fix for F-1 fixes this game as well.
I just need to keep thinking about it. Somehow, the real SNES keeps
certain internal variables to know when an IRQ needs to trigger and
when it already has. So far, nothing I try satisfies all known IRQ
conditions we've discovered.
The reason this is giving me so much trouble is because there are so
many variables involved at one time. I can focus on any three or four
at a time, but it's hard to visualize the "big picture" of how IRQs
work, at least for me. At the moment, I'm trying to figure out if the
SNES internally keeps its own "previous H/V counter positions" each
time IRQ is tested, or if IRQ is tested every clock tick, or if the IRQ
test is a direct comparison (eg trigger when VCOUNTER==VTIME &&
HCOUNTER == HTIME), or within a range (eg trigger when HCOUNTER >=
HTIME && !TRIGGERED), or something else.
Quote: |
is there any point to running those tests on pal hardware. |
Nope :/
Quote: |
Earthworm Jim 2 (Beta) has garbled sound during the intro and does not reach in-game. |
We haven't really been focusing on betas. A lot of them really are
bugged (eg KI Beta). If someone wants to verify on hardware though, I
suppose I could take a look at it.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 31, 2006 6:15 pm Post subject: |
|
i will try to verify asap, but i agree that testing beta's is not a good idea at this time. |
|
dragoonmaster New Member
Joined: 31 Aug 2006
Posts: 4
|
Posted: Thu Aug 31, 2006 6:59 pm Post subject: |
|
I have tested the EJ2 Betas:
The normal beta and an alternative beta, The alternative beta works the normal not, so i guess the dump is faulty.
Same goes for zsnes (latest cvs). |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Aug 31, 2006 7:40 pm Post subject: |
|
dragoonmaster wrote: |
I have tested the EJ2 Betas:
The normal beta and an alternative beta, The alternative beta works the
normal not, so i guess the dump is faulty.
Same goes for zsnes (latest cvs). |
Tested on real hardware?
Can you post the CRC32 for each?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Thu Aug 31, 2006 7:54 pm Post subject: |
|
I
tested kode54's bsnes 017 build,and I get severe sound crackling and
popping problems.With byuu's official 017 release and the 017 WIP
builds,there's no problem (sound is smooth).
Also,I noticed a *very slight* performance increase with the kode54 build.
OK,kode54's build supports archives,but I still can't drag and drop a
.ZIP file from 7-zip's file manager window and drop it in the bsnes
window to open it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 31, 2006 8:16 pm Post subject: |
|
I'm
not ignoring requests for user interface enhancements (disable screen
saver, drag and drop, etc), but I'm too busy with core emulation issues
to work on the user interface at this time.
I consider the IRQ bug very serious at the moment.
The sound crackling in kode54's build is because he is setting
readbuffer to prevbuffer. This *is* going backwards (playing that
sample block requires looping over the entire ring buffer - 1 block). I
get the same crackling (especially when enabling speed throttling where
it was off before) with my method when I set readbuffer to prevbuffer
instead of readbuffer + 1 (which is really +2, since the next buffer
will have started by this point).
However, the whole point of the modular AVI abstraction was to allow
multiple interfaces. If kode54's soundcode works better for some
(FitzRoy), then I will include it as an alternative. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Aug 31, 2006 9:06 pm Post subject: |
|
I
had no idea kode's build was having adverse effects on other people's
cards. If that's the case, there's no reason to add something just for
me. 48ms works fine. Just strange, because if it was my card, you would
think all my other programs would crackle on higher settings, too, but
they don't. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 31, 2006 11:33 pm Post subject: |
|
With TRAC's help, I think I have the new IRQ stuff (mostly) working.
At least, it passes both of my extremely rigorous IRQ test ROMs, as
well as runs F-1 Grand Prix and Sink or Swim properly.
Now I just need to make it use the fast clock increment code again,
which is sure to be a pain, and we should be good. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Sep 01, 2006 2:58 am Post subject: |
|
TRAC is awesome.....Enough said.  |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Sep 01, 2006 5:10 pm Post subject: |
|
Could
you go over what the correct IRQ semantics are then? Or is there a
thread somewhere else where you and TRAC figured it out? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 01, 2006 6:18 pm Post subject: |
|
To be honest, we're still not 100% on it. I need to run a lot more tests to try and determine a few things.
As per my webpage, I only have access to the internet at work, so I
should have plenty of time to work on this (read: nothing else to do
x.x) ...
I'll try and write up a document detailing all currently known
knowledge of NMI and IRQ. But I warn you now: it's very, very complex
and hard to implement properly :/
My test ROMs mostly test the most extreme edge cases possible and thus
require perfect CPU core timing to work, so my test ROMs will be of
little help to other emulator authors, unfortunately. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Sep 01, 2006 7:10 pm Post subject: |
|
actually
thats exactly what arbee needs, as he is going to use the info for
mame/mess, and their target is accurately documented emulation of the
hardware.
Apart from that i also thing that it
would be a great idea if you could write the things you have discovered
in documents, and host that with your testroms in a central place
they probably wont be accessed a lot, so you probably could take the bandwith hit from those files.
But its up to you ofcourse
PS
I'm putting all tests on hold untill you fix this timing thing, as i
dont want to provide any useless bugreports at this point, please
upload a wip as soon as youve got this fixed so i can continue testen,
cheers!
EDIT:
Arbee, ill be willing to do these tests too for Snes emulation in mess
once you think the time is ready for it, hopefully we will be able to
provide a list of gamebugs not caused by emulation to prevent fixing of
games that shouldnt be fixed (would be great to have fixed sets like haze suggests) |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Sep 01, 2006 9:38 pm Post subject: |
|
Actually
I'm not aiming for 100% accuracy first, but at the same time I'd like
to know as much as possible about the proper operation ahead of time so
I have an idea what things are critical and what can be approximated at
first (and replaced later with a more accurate version). My plan is to
finish up the new raster timing system and then rework the 65816 for
cycle-by-cycle operation (and along the way fix things like the
sei/cli/sei follies - amusingly some versions of Asteroids in the
arcade were recently discovered to rely on the same pipelining behavior
in the original 6502!) Those 2 things are fundamental to correct timing.
I've got some related questions if byuu or pagefault or anyone else can answer them:
- What HCNT does HDMA start on?
- When does drawing occur relative to HCNT?
- How many master clock cycles do (H)DMA transfers take?
- What's this OAM caching I've seen reference to?
And yes, a list of known test ROMs and what they test would be nice
too. I've got a nice document on the inner workings of the famous
Nintendo electronics test, but anything else would be good too.
Feel free to PM me here or on any other board I'm on if you'd rather not clog this thread  |
|
oxid New Member
Joined: 01 Feb 2006
Posts: 2
|
Posted: Fri Sep 01, 2006 11:24 pm Post subject: |
|
Arbee wrote: |
I've got a nice document on the inner workings of the famous Nintendo electronics test, but anything else would be good too.
|
I think one of the best references are anomie's docs on Romhacking
BTW, where i can find this document about Nintendo electronics test?
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Sat Sep 02, 2006 3:03 am Post subject: |
|
That's
good stuff! I think Anomie's various documents actually cover most of
the questions I just posted (except the OAM caching).
The electronics test doc was sent to me privately and isn't really
formatted for distribution, but I can maybe throw together a decent
summary. |
|
oxid New Member
Joined: 01 Feb 2006
Posts: 2
|
Posted: Sat Sep 02, 2006 9:40 am Post subject: |
|
Arbee wrote: |
The
electronics test doc was sent to me privately and isn't really
formatted for distribution, but I can maybe throw together a decent
summary. |
ok, thanks!
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Mon Sep 04, 2006 1:51 am Post subject: |
|
Ok,
it's pretty easy, but you need something with a debugger to really
understand what's going on. Basically each test it does as part of the
electronics test has a status byte at 7E/0060-7E/0075 or so. Once the
test completes you can check that RAM area to see what passed/failed.
If a test passed, it's byte is 0xff, otherwise it's 0x00.
The tests are:
0x60 = test WRAM
0x61 = tests NMI, also insures 00/1000-1005 and 20/1000-1005 are mirrors
0x62 = tests read/write from 7e/2000-7f/ffff
0x63 = test 2180-2183 read/write WRAM
0x64/0x65 - test VRAM even and odd locations to make sure they retain data
0x66 = test DMA registers read/write
0x67 = test read/write OAM
0x68 = test read/write palette RAM
0x69 = test hardware multiply at 4202-4203
0x6a = test hardware multiply at 211b-211c
0x6b = test hardware divide at 4204-4206
0x6c = test DMA to 2118-2119 + DMA from 2139-213a
0x6d = test HCNT and VCNT.
--- subtest 1: wait until immediately after VBlank. Latch the counters.
VCNT must be 0, HCNT must be between 0x10 and 0x40.
--- subtest 2: wait until immediately after VBlank, then wait until
HBlank starts. Latch the counters. VCNT must be 0, HCNT must be between
0x110 and 0x140.
--- subtest 3: wait until the start of VBlank and latch the counters.
VCNT must be 0xe1 and HCNT must be between 0x10 and 0x40.
0x6e = sets HIRQs and VIRQs at various screen positions and makes sure they fire appropriately
0x6f = test DMA from VRAM to WRAM
0x70 = same as subtest 3 of 0x6d, but tests both 240-line and 224-line
modes. In 240-line VCNT must be 0xf0 at the start of VBlank rather than
0xe1.
0x71 = Turn on interlace mode and make sure the even/odd field bit (I forget which register) toggles appropriately
0x72 = test bits 6 & 7 of 4212 (Vblank and Hblank status) against HCNT and VCNT
0x73 = test OAM range/time over flags
0x74 = apparently not used
0x75 = A few basic 65816 tests, if you don't pass this you have a real problem
Credit goes to TRAC and anomie for these. Any errors are likely my fault though. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Sep 04, 2006 8:25 pm Post subject: |
|
Question:
Where along the line is aspect ratio correction applied to the video
image? Is it before or after software filters? Before or after
resolution multiplication?
Bug?
Am I failing to see an option? A while back, you removed the default
windowed/fullscreen profile selections. In v0.017, the default profile
on first run is Profile 3. Then, using F11 to switch to fullscreen, the
fullscreen profile appears to be Profile 6. Then, using F11 again or
pressing ESC to leave fullscreen, the active profile is set to 1. Very
inconsistent. It seems like there is still default windowed/fullscreen
profiles, but now it's impossible to change them.
Feature Requests:
In my opinion, Alt+Enter is a much more common key combination than F11
for entering and leaving full screen. (F11 is used to enter/leave
"fullscreen" modes of Internet Explorer and Firefox; anything else?)
The ESC button has inconsistent behavior. When in windowed mode, it
shows or hides the menu bar. In fullscreen, it is used to leave
fullscreen. I think that ESC should not be used to exit fullscreen, but
rather only one key combination be used to enter and exit fullscreen
(F11 or Alt+Enter). Additionally, ESC can be used in fullscreen to
show/hide a menu if/when you figure out how to draw a menu in
fullscreen.
It would be nice if Ctrl+O was mapped to Load ROM and F12 was mapped to Unload ROM (consistent with Project 64).
ESC and F11 need menu items showing and performing their function, and
showing the key combination. Ctrl+1 through Ctrl+8 need to be shown
next to the Video Profile menu items. The more information about the
functions of your emulator that you present to your users in the
emulator itself, the fewer dumb questions you will get, and the less
documentation you will have to write.
The underlined letter of particular menu items (used to select that
menu item while viewing the menu) is the same for multiple items on the
same menu. Examples: Settings Menu. Show FPS and Speed Regulation. Under the Speed Regulation menu, two items using are S and two items are using F.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 04, 2006 11:00 pm Post subject: |
|
Jipcy wrote: |
Question:
Bug?
Am I failing to see an option? A while back, you removed the default
windowed/fullscreen profile selections. In v0.017, the default profile
on first run is Profile 3. Then, using F11 to switch to fullscreen, the
fullscreen profile appears to be Profile 6. Then, using F11 again or
pressing ESC to leave fullscreen, the active profile is set to 1. Very
inconsistent. It seems like there is still default windowed/fullscreen
profiles, but now it's impossible to change them. |
Dreadfully confusing, isn't it? It took me 15 minutes of testing to
figure out the behavior of profiles. If I had it my way, there would be
only 2 profiles to switch between, one for windowed and one for full
screen, and I would call them "Windowed" and "Full Screen." Having 8 is
a problem, and having the emu start on "Profile 3" is a problem. Other
emulators don't have profiles and I never see anyone request them. It's
just too confusing and 99% of users don't need them.
But this and many of your requests are in the territory of author vs. user.
I only disagree with the underlined letters, though. This is ugly and
the lists are short enough to use the up and down arrow keys (or a
mouse for god's sake).
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Sep 04, 2006 11:12 pm Post subject: |
|
I need only 4 profiles: 2 for PAL,2 for NTSC (fullscreen and windowed).
I can also use it with only 2 profiles - in that case,there would be
one for windowed and one for fullscreen if I set the mode to PAL in
both (240 scanlines visible)
I just wish the black bar/area at the bottom (the difference between
224 and 240 lines) to shift upwards,so I get even "borders" at the top
and bottom.I find it better-looking than having a big "chunk" at the
bottom. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 04, 2006 11:41 pm Post subject: |
|
I
like the "video standard" option rather than adding more profiles and
taking away the simplicty of the 1/2 switch. I doubt many people switch
regions enough to consider this an inconvenience.
And that chunk you speak of only appears when you play ntsc games on
pal mode. I'd think you'd want to switch modes, then you have no bars
to worry about. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Sep 05, 2006 12:13 am Post subject: |
|
Since even some NTSC games *do* use 240 lines (overscan),I always keep the video standard setting to PAL.
Either a "smart switch" to enable 240 lines for only those ROMs which
use overscan,or a shift downwards of the viewable 224 lines to get a
"letterboxed" kind of display . |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 05, 2006 12:45 am Post subject: |
|
I
remember discussions of this, and I think an auto switcher like zsnes
would've created more problems than it solved. Also, I think I would
find two smaller black bars between an image more distracting than a
large one at the bottom. And if I think that way, others do as well. So
count out this behavior as default. Lastly, I don't think this
preference is worthy of adding a whole new option to the config. So I
don't really have an answer for you.
July 15:
byuu wrote: |
That's overscan. In PAL mode, it really should show the extra lines,
ZSNES is correct. My overscan emulation however is correct for NTSC,
whereas ZSNES gets that wrong. I would like to get PAL overscan working
correctly one day, but right now I don't want to deal with window
resizing issues such as those you experience when entering the GUI in
ZSNES. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 05, 2006 1:33 am Post subject: |
|
Hm, ok. I will relabel profile 1 to windowed, and profile 2 to fullscreen.
Ctrl+(1-5) will switch multipliers, Ctrl+A will toggle the "fix aspect
ratio" option. The changes will only apply to the currently active mode.
I'm happy with the behavior of ESC, and I do not know how to capture
the Alt+Enter key combination in Windows. Alt does not get returned by
my key capture methods, because it goes to the menubar. Ctrl does not
have this problem. Windows sends a special message when Alt is pressed,
but then checking the status of enter at that point does not work. I'm
not interested in researching the matter further.
Likewise with the menu options showing their respective key shortcuts.
Don't know how to do it, not concerned enough to research the matter
further.
Two labels using the same key? Ok, press 's' once to go to the first
option, press 's' twice to go to the second. It seems smarter than
making "slowest" use S and "slower" use L. Same for fast and "F / A".
I'll use F for Show FPS, though. Thanks.
Overscan centering... is a problem. It's possible to toggle overscan
between 224 and 239, leading to any resolution from 224 to 239. It's
also possible to toggle it frequently, making the screen image jump up
and down. I might add 239-centering later, but for now the images stay like they are.
I will add some options for NTSC vs PAL refresh rates and reset the
modes when a ROM is loaded, so you can define 50/60/100/120/whatever.
I'll change video standard a little to be "Always NTSC, always PAL,
autodetect".
F12 is way too close to F11, and that's one damn annoying key mistake
to make. Ctrl+O... maybe. I want to add an input editor for GUI
shortcut keys. That will be there eventually.
Good enough? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 05, 2006 2:46 am Post subject: |
|
Yes, but a few points regarding these:
I am assuming you will remove full screen options from the profile
named "Windowed." If yes, splendid. As it should be.
I don't know how Alt+Enter came to be the standard among programs for
going full screen. The F keys do seem like a better choice, one key
press vs two (and what else are they there for?). In case it makes any
difference, I've noticed that pSXEmulator behaves in this way: it won't
go to the menu until you press AND release the ALT key. When you do a
key combo, you're essentially hitting ENTER while ALT is held down.
Simply pressing ALT in bsnes goes to the menu before it even gets
released.
Also, do you think it would be good to add a small section to the
readme regarding these hotkeys? Users need to find out how to operate
these somehow. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Sep 05, 2006 2:53 am Post subject: |
|
My
minor beef with the profiling system is simple... the cfg file doesn't
match up the way it is displayed. Profile 1 in BSNES == Profile 0 in
the cfg file. This can appear as nonintuitive/confusing.
Personally, I'd only use one profile.. maybe two if I felt like it. 4
is nice if you really bother to use NTSC/PAL...
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 05, 2006 6:44 pm Post subject: |
|
I agree that should be changed.
And I think at least two profiles are needed to separate windowed and
full screen preferences. There was also some kind of invisible window
bug on returning to the same profile from full screen, which wouldn't
happen with two. Having two also eliminates the problem of switching
from 3 to 6, and having it go back to 1 instead of 3.
EDIT:
All "A" (J) games tested. Core emulation problems found: 0. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 06, 2006 3:42 pm Post subject: |
|
Ok, there are now two profiles: Windowed and Fullscreen.
And for Deathlike's sake, the config file entries are "profile_win" and "profile_full". I'll work on hiding
the fullscreen options rather than just disabling them, as well as
adding an "autodetect" option to the video standard list later. Also,
multiplier now only shows 1x-5x. If you need to, you can edit the
config file by hand to set 6x-8x. I figure most people won't be using
resolutions > 1600x1200 and want to stretch the image that far with
them.
Corrected all of the & conflicts as well in the menu.
And I even managed to get some work done on actual SNES emulation, imagine that :)
Added a new counter system aimed for speed, it only runs when at least
one counter is > 0. I used this to emulate both the IRQ delay after
H/DMA, and a new one to SNES emulation, as far as I know: hardware
delay for multiply and divide operations. Now, if you read from
$4214-$4217 before the multiply or divide is given time to complete, it
does not return the correct result. Unfortunately, I don't know what it
should return (probably some hybrid partial calculation or something,
but hopefully
just the last completed mul/div result -- will test later), so it just
returns 0x00, but it's at least enough to cause errors when democoders
/ romhackers try using them without waiting like they should. No change
in any commercial games that I'm aware of.
Still
trying to get the new IRQ code working without having to step
clock-by-clock... a real losing battle, but I'll keep trying as always. |
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Wed Sep 06, 2006 6:38 pm Post subject: |
|
hi i am trying to wirte a snes emu too. my motivation is to understand how it works.
currently I am trying to understand how NMI/IRQ timing is working.
bsnes helps me a lot, Thank you byuu for your work. But I am convinced,
it is more interrest than work at least for me.
I have a short fix for Sink or swim and F1
I have tried the fix in bsnes 0.015 and it works
insert in update_irq() function after the line
hpos = (hpos != 0) ? ((hpos << 2) + 14) : 10;
following:
if ((time.v==vpos) && (exception)) hpos = 1360;
exception is a bool parameter : update_irq(bool exception)
exception is allways false, except for the two mmio functions VTIMEL
and VTIMEH. After updating virq_pos call update_irq(true);
Byuu do you know which exact hpos the IRQ fire, if there is no hpos set
and Vtime is set during the current scanline.
My assumption is the end of the scanline or beginning of the next. It
works with any hpos at the end of the scanline. |
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Thu Sep 07, 2006 4:39 am Post subject: |
|
byuu, are you plainning on putting a mouse support?
How about cheats saving to .cht?
Just right after you getting the fixes done first. We are not in a hurry. Time your time on everything.  |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 07, 2006 3:18 pm Post subject: |
|
Ok,
I was able to get NMI/IRQ working with only a single interrupt poll
during each add_clocks() call, but the code was fairly nasty. And then
there was a new problem: how do you set the IRQ trigger delay when your
IRQ test is (hclock+cycles) <= irq_trigger_pos? Since
(hclock+cycles) can be anything, that makes triggering the IRQ even
more nasty.
So, I'm going to stick with
alwaysinline functions and clock stepping for the forseeable future.
The code is just way easier to read and maintain. I'd rather get this
emulated right, and then worry about speedup tricks. 112fps instead of
127fps, IIRC. That also includes the overhead for the new hardware math
delay counter.
Quote: |
I have a short fix for Sink or swim and F1
I have tried the fix in bsnes 0.015 and it works |
Uhh.... thanks?
Quote: |
Byuu do you know which exact hpos the IRQ fire, if there is no hpos set and Vtime is set during the current scanline. |
It fires four clocks earlier than a V+HIRQ at HPOS=0.
Quote: |
How about cheats saving to .cht? |
Already there, though I don't support ZSNES/SNES9x binary cht files,
mine are stored in plaintext and allow for much longer descriptions.
The two formats will probably conflict with each other as I doubt any
emulator is doing any integrity checking on the files before attempting
to load / save them.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Thu Sep 07, 2006 6:58 pm Post subject: |
|
I
would talk about a few things I have noticed till my current state of
the emu. Sorry english isn't my home language, hopefully it's
understandable
I have build the Cpu opcodes with
the official document of Western Desgin Center mainly for the adressing
modes. For Cpu logic I have used the book 65816/65802 Assembly
Programming Language from 1986. It seems there are few mistakes in this
book or the 65c816 in the Snes is a little bit modified. For example
the mvn and mvp opcodes always uses a 16 bit accumulator. The book
considers the m flag in status register for this op.
Byuu it seems you don't handle the break bit right in emulation mode.
tell me if I am wrong. The brk opcode do's following in cycle 6:
if (mode_e) reg_p.b = 1;
write_stack(reg_p);
if (mode_e) reg_p.b = 0;
the break bit is needed in emulation mode, because the brk vector is
the same like the irq. So with the code below for example it is
possible to check after the irq or brk, if it was a hardware or
software interrupt:
PLA
PHA
AND #$10
BNE was_brk
I have coded the opcodes, which can have an additional cycle in native
mode, depending of x bit in status register like this:
if(mode_e || (!mode_e && reg_p.x))
so mode_e means that x bit is always 1. So I have the x-bit in
emulation mode free for the b-bit. The b-bit will be only true
temporally in the sixth cycle of brk opcode. It is not needed to set
the break bit 0 during a hardware interrupt, because it is 0 already.
In the xce opcode I use this:
if(mode_e) {reg_p.m = 1;
reg_p.b = 0;
reg_x.h = 0x00;
reg_y.h = 0x00;
reg_s.h = 0x01;}
else reg_p.x = 1;
in opcodes, which read p_reg from stack I use this code:
if(mode_e) {reg_p.m = 1; reg_p.b = 0;}
if(mode_e || (!mode_e && reg_p.x)) { reg_x.h = 0x00; reg_y.h = 0x00; }
reg_p.b and reg_p.x uses the same memory via union.
Last edited by PiCiJi on Thu Sep 07, 2006 7:07 pm; edited 2 times in total |
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Thu Sep 07, 2006 7:06 pm Post subject: |
|
From byuu: "I'm not adding anything requiring a mouse anytime soon." lol
Thanks. I will stick on the zsnes for now until bsnes get a mouse support.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 07, 2006 7:52 pm Post subject: |
|
Quote: |
Byuu it seems you don't handle the break bit right in emulation mode. |
Nope. I'd like to fix this, but I have more important issues with IRQs
and such to work on at the moment. Started fixing the first half of it
(checking e rather than just m/x for 16-bit opcodes), but it's still a
work in progress.
Quote: |
Thanks. I will stick on the zsnes for now until bsnes get a mouse support. :( |
Sounds good to me.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Thu Sep 07, 2006 8:03 pm Post subject: |
|
It
doesn't matter if BRK is handled properly in a SNES-only emulator. BRK
in a SNES game is pretty much always due to some emulation failure, so
you want to trap it. (It's possible some clever game uses it - some
Apple IIgs software trapped WDM and used it as a syscall - but I doubt
it). |
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Thu Sep 07, 2006 8:28 pm Post subject: |
|
Yeah my old book is from the Apple 2gs time. An other issue in the book is:
An reset terminates the wait state, save the program bank register (if
in native mode), the program counter and processor status register onto
the stack and transfers programm control to the appropriate
interrupt-handling routine.
Hmm I thought only a nmi or irq save the program counter and processor
status register? I wonder if a snes game consider this? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 08, 2006 12:10 am Post subject: |
|
Going
through the B's, I found a new bug. Using .017.04, Battle Blaze (J)'s
title screen is having "horizontal line issues". This might have been
introduced with the Taz-Mania and Top Gear 2 fix, as it does not happen
in .017 official. Possible to fix without breaking the others again?
No other problems were found in that letter. |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Fri Sep 08, 2006 6:03 am Post subject: |
|
byuu wrote: |
Quote: |
Byuu it seems you don't handle the break bit right in emulation mode. |
Nope. I'd like to fix this, but I have more important issues with IRQs
and such to work on at the moment. Started fixing the first half of it
(checking e rather than just m/x for 16-bit opcodes), but it's still a
work in progress.
|
The X/B and M/1 flags are already correct for emulation mode. This is the table from the GTE 65816 document:
Code: |
Emulation (E = 1) Native (E = 0)
Processor Status (P):
* Bit 4 Always one, except zero X flag (8/16-bit Index)
in stack after hardware
interrupt
* Bit 5 Always one M flag (8/16-bit Accumulator)
|
PiCiJi wrote: |
An
reset terminates the wait state, save the program bank register (if in
native mode), the program counter and processor status register onto
the stack and transfers programm control to the appropriate
interrupt-handling routine.
Hmm I thought
only a nmi or irq save the program counter and processor status
register? I wonder if a snes game consider this? |
During Reset the cpu tries to save PC and P to the stack, but the R/W
signal is always set high during reset. This causes the cpu to read
from the stack instead of writing to it. Also, the PB does not get read
because E = 1 at the beginning of reset.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 08, 2006 6:34 am Post subject: |
|
Quote: |
Going
through the B's, I found a new bug. Using .017.04, Battle Blaze (J)'s
title screen is having "horizontal line issues". This might have been
introduced with the Taz-Mania and Top Gear 2 fix, as it does not happen
in .017 official. Possible to fix without breaking the others again? |
I'll make the HCLOCK position to render the line a config file option
for the next release. If you want to keep a list of games that have
issues and their acceptable HCLOCK ranges, we could choose the best
general purpose one; but I don't want to keep hacking around this issue
personally. I need to focus on a dot based renderer and get away from
this hackery instead, but now the CPU interrupt stuff is requiring all
of my immediate attention :/
Quote: |
The X/B and M/1 flags are already correct for emulation mode. This is the table from the GTE 65816 document: |
I don't do anything with M/1 being forced to 1 in emulation mode, nor
do I push P&~0x10 when in emulation mode when calling hardware
interrupts, if I recall correctly. Maybe I do... I'll look into it
"shortly".
Quote: |
During
Reset the cpu tries to save PC and P to the stack, but the R/W signal
is always set high during reset. This causes the cpu to read from the
stack instead of writing to it. Also, the PB does not get read because
E = 1 at the beginning of reset. |
Odd, my tests seemed to indicate that PC+P was
pushed onto the stack when resetting. I had some demo a few years ago
that let you scroll around memory and I could've sworn the program
counter at reset was showing up after each reset. I'll have to retest
it, that was quite possibly the oldest test I ever wrote, and was
probably full of bugs.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Fri Sep 08, 2006 7:47 am Post subject: |
|
That
means the Snes sets x (break) bit by switching in emulation mode to
one? But why says my book that the brk op writes a 1 for the break bit
on the stack and resets afterwards the break bit to 0? Is the GTE
version different the WDC version of the CPU? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Sep 08, 2006 10:55 am Post subject: |
|
PiCiJi wrote: |
if(mode_e || (!mode_e && reg_p.x))
|
Just do:
Code: |
if(mode_e || reg_p.x)
|
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Fri Sep 08, 2006 12:08 pm Post subject: |
|
byuu wrote: |
I
don't do anything with M/1 being forced to 1 in emulation mode, nor do
I push P&~0x10 when in emulation mode when calling hardware
interrupts, if I recall correctly. Maybe I do... I'll look into it
"shortly". |
You're right about the M/X flags. I just assumed that the code was
correct, but it is not. The interrupt code in sCPU::op_irq looks like
it is correct.
Quote: |
Odd, my tests seemed to indicate that PC+P was pushed onto the stack when resetting. |
In both the GTE and WDC docs it says that "R/W remains in the high
state during Reset" and "RWB remains in the high state during the stack
address cycles".
I have a question about the TSC opcode: Are the N/Z flags set based on
the full 16-bit value in emulation mode, or just the low 8-bits like
bsnes does? I think it should be 16-bits like TDC.
PiCiJi wrote: |
That
means the Snes sets x (break) bit by switching in emulation mode to
one? But why says my book that the brk op writes a 1 for the break bit
on the stack and resets afterwards the break bit to 0? Is the GTE
version different the WDC version of the CPU? |
Both the GTE and WDC docs state that the M/X flags are always high
during emulation mode and cannot be changed. During an emulation mode
hardware interrupt (IRQ, NMI, ABORT, RESET), the Break bit / X flag is
set to zero on the stack only. The value in the P reg is not changed.
When the interrupt ends with an RTI, the cpu will load the P reg from
the stack. If the cpu is still in emulation mode, then the M/X flags
will be forced back to 1.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Fri Sep 08, 2006 12:51 pm Post subject: |
|
Quote: |
I
have a question about the TSC opcode: Are the N/Z flags set based on
the full 16-bit value in emulation mode, or just the low 8-bits like
bsnes does? I think it should be 16-bits like TDC. |
It seems you are right, N/Z is based on 16 bit value in native and emulation mode. At least my book says it.
Quote: |
if(mode_e || reg_p.x) |
Yeah it`s the same, but when the b bit is always true in emulation mode, then there is no need for this anymore.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 08, 2006 5:37 pm Post subject: |
|
byuu wrote: |
I'll make the HCLOCK position to render the line a config file option
for the next release. If you want to keep a list of games that have
issues and their acceptable HCLOCK ranges, we could choose the best
general purpose one; but I don't want to keep hacking around this issue
personally. I need to focus on a dot based renderer and get away from
this hackery instead, but now the CPU interrupt stuff is requiring all
of my immediate attention :/ |
Sounds good. I'm wondering if there is a magic number that will avoid
this issue in all games under a scanline based renderer. .016, for
example, has no issues with taz-mania or battle blaze. Odd.
EDIT:
All "C" (J) games tested: 1 bug found. Circuit USA (J)'s title screen
has missing gfx. Occurs in all .017 versions, but not in .016.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 10, 2006 4:31 am Post subject: |
|
All
"D" and "E" (J) games tested. A couple of small problems that do not
happen in zsnes or super sleuth, but will probably need to be verified
on hardware unless you suspect them to be more obvious than I do.
Dokapon 3-2-1 - Arashi wo Yobu Yuutou (J) - after title screen, the
leftmost vertical line has a transparent effect that looks out of place
Doraemon 3 - Nobita to Toki no Hougyoku (J) - during intro, as soon as
text box pops up, the leftmost vertical line becomes black
Both occur in all versions of bsnes. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Sep 10, 2006 8:00 am Post subject: |
|
I can probably test those on monday. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 10, 2006 11:23 pm Post subject: |
|
Yeah, and you'll definitely need a video-input card to see the left edge.
Ooo, an update:
byuu wrote: |
09/10/2006 - Misc improvements
Emulation-wise... I've finally emulated the delay required before CPU
multiplication and division operations complete. No commercial games
would ever read these registers without waiting, so don't expect any
bugfixes. The main reasons for adding this are hardware accuracy, and
so that democoders and ROM hackers remember to wait before reading
these registers. For now, I only return 0x00 when these registers are
read too soon. I will have to investigate what happens on real hardware
before I can emulate this more accurately.
Also added in a very fast non-LUT version of the memory speed detection
algorithm, mostly just to help lower memory / cache requirements. It
appears to be infinitesimally slower on my Athlon 64, but saves 128kb
of memory. Combined with the luminance table split, this lowers overall
memory usage by over 1MB.
Next up, I've added some new config file options to control the PPU
scanline render position and clock rates for NTSC/PAL S-CPU + S-SMP. I
strongly recommend these options not be modified, so they will not be
added to the GUI. These will mainly be used for bug testing.
Next is a new GUI panel option, emulation settings. This lets one
toggle HDMA and offset-per-tile effects, as well as BG+OAM layers. A
little more fine grained than standard emulators by allowing toggling
by priority, but a bit harder to use on the fly since there are no
shortcut keys mapped to me. This dialog actually used to exist as a
standalone window a few months back, but got removed during a UI
rewrite.
I also added in a new program icon, courtesy of FitzRoy. Same SNES
logo, but much more refined, and has an embedded 48x48 icon as well.
Now I just need a logo ...  |
I also noticed your website changes. Got the border... very nice. Only thing I don't like is the 2px sides.
All "F" (J) games tested. Problems found: 0
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Sep 11, 2006 12:11 am Post subject: |
|
If there's a new icon, I'd appreciate a 32x32 PNG of it, so I can update NF.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 11, 2006 5:08 am Post subject: |
|
Quote: |
I also noticed your website changes. Got the border... very nice. Only thing I don't like is the 2px sides. |
Why's that? I like them. Gives it a nice shadowed effect. Need a good
background image instead of the solid light blue.
Stuck your icon on the about screen in bsnes. Looks really good there.
Not as nice as the old Bahamut Lagoon fanart image, but saves ~300kb of
bandwidth per download. Thanks again.
|
|
|
Schism New Member
Joined: 07 Dec 2005
Posts: 4
|
Posted: Mon Sep 11, 2006 5:13 am Post subject: |
|
Umihara Kawase (J): Water in level 1 seems to flicker off every few seconds, especially when scrolling. Bug?
Zelda ALttP (J): As the item window slides down, it makes a sound, but
the sound effect is missing when it slides back up.
Also, was the pause button taken out or am I missing something? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 11, 2006 5:56 am Post subject: |
|
Quote: |
Also, was the pause button taken out or am I missing something? |
F11. DirectInput cannot detect pause/break key 90% of the time. You
have to keep tapping it because for some reason DirectInput is
reporting that you are constantly holding the button down and releasing
it, unlike all the other keyboard shortcuts. In my WIPs, I've added a
forced delay between pausing and unpausing, because I have no idea what
the fuck's wrong with DirectInput.
I might just say the hell with DirectInput for the keyboard and use it only for gamepad input.
Quote: |
Zelda ALttP (J): As the item window slides down, it makes a sound, but the sound effect is missing when it slides back up. |
Hmm, need someone to test that on hardware, please. If confirmed, try
screwing with smp.ntsc_clock_rate and cpu.ntsc_clock_rate and see if
any changes to those fix it. As it stands, the S-SMP is slightly
underclocked compared to a real system, as I'm going by official
specifications rather than observed realtime speed tests.
Note that this only happens when you start a new game.
Quote: |
Umihara Kawase (J): Water in level 1 seems to flicker off every few seconds, especially when scrolling. Bug? |
Couldn't tell you. Hopefully fixed with the recent IRQ changes?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Sep 11, 2006 6:27 am Post subject: |
|
After reading your latest news update
what hardware do you need?
maybe we could hold somekind of fundraiser, or ppl could lend/donate
stuff, or buy it from ebay or something and send it to you?? or do
tests for you? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 11, 2006 6:58 am Post subject: |
|
Nach wrote: |
If there's a new icon, I'd appreciate a 32x32 PNG of it, so I can update NF. |
pmed you.
byuu wrote: |
Why's that? I like them. Gives it a nice shadowed effect. Need a good
background image instead of the solid light blue. |
Oh, I guess I didn't see it that way. Only 1px larger solid black
didn't get me thinking "shadow." Though if you increase it, it would
become even less convincing with the 90 degree corners.
byuu wrote: |
Stuck
your icon on the about screen in bsnes. Looks really good there. Not as
nice as the old Bahamut Lagoon fanart image, but saves ~300kb of
bandwidth per download. Thanks again. |
No problem.
It is at least a step up from what you had before. I'm only unsatisfied
with the way it looks on the desktop. Without borders or shadows around
the colors, it looks washed out on lighter schemes. And believe me, I
added them, tried enclosures, and tinkered with it to worse results.
Icon art is really difficult, but I'm learning. Don't hesitate to
remove or relegate mine if something better gets made (the guy who did
snesgt's is great). Heck, I'm working on a console atm that seems to be
working better on the desktop.
schism wrote: |
Umihara Kawase (J): Water in level 1 seems to flicker off every few seconds, especially when scrolling. Bug?
Zelda ALttP (J): As the item window slides down, it makes a sound, but
the sound effect is missing when it slides back up. |
first bug: I didn't notice anything unusual in this or the new wip. The
water never disappears on me. It does flicker steadily and looks like a
somewhat shitty implimentation, but not a bug.
second: I don't think there is supposed to be a second sound effect. You may simply be remembering incorrectly.
But hey, if I'm wrong, oatmeal cookies for everyone.
EDIT: uh oh, Taz Mania (U) is hanging before title screen in the new wip. (E) remains okay.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 11, 2006 7:58 am Post subject: |
|
Quote: |
first
bug: I didn't notice anything unusual in this or the new wip. The water
never disappears on me. It does flicker steadily and looks like a
somewhat shitty implimentation, but not a bug. |
Looks like a lousy effect to me. Happens on all emulators, so I'll wait
for hardware verification before acknowledging this one.
Quote: |
second: I don't think there is supposed to be a second sound effect. You may simply be remembering incorrectly. |
Nah, it's there. If you try it during a resumed game you can hear it.
Another good game to verify on hardware, as this also happens in ZSNES,
SNEeSe, etc.
Quote: |
EDIT: uh oh, Taz Mania (U) is hanging before title screen in the new wip. (E) remains okay. |
I didn't change anything timing related to the best of my knowledge.
Maybe I should just blacklist shitty games and save myself a lot of
headache.
Last edited by byuu on Mon Sep 11, 2006 8:01 am; edited 1 time in total
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Sep 11, 2006 7:58 am Post subject: |
|
Edit: Nevermind. Didn't realize secondary button functions were active. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 11, 2006 3:16 pm Post subject: |
|
Yow >_<
FitzRoy, have you seen your bsnes icon in 256-color mode? It's only
displaying four colors for some reason. And of course since Windows is
retarded and uses the 256 color icons in 16-bit mode (rather than
downsampling the 24-bit ones), this is a problem... are you able to
store copies of the 24-bit one, only downsampled to 256 colors,
manually?
Taz-Mania (U) problem found. It's the new hardware multiply / divide
counters. The game is reading them too soon and expects non-zero
results. Wonderful.
Code: |
9A8618 SEP #$20 A:000A X:7208 Y:0017 S:01E9 DB:7E D:0000 P:00 e
9A861A STA $004202 A:000A X:7208 Y:0017 S:01E9 DB:7E D:0000 P:20 e
9A861E TYA A:000A X:7208 Y:0017 S:01E9 DB:7E D:0000 P:20 e
9A861F STA $004203 A:0017 X:7208 Y:0017 S:01E9 DB:7E D:0000 P:20 e
9A8623 REP #$20 A:0017 X:7208 Y:0017 S:01E9 DB:7E D:0000 P:20 e
9A8625 LDA $004216 A:0017 X:7208 Y:0017 S:01E9 DB:7E D:0000 P:00 e
9A8629 RTL A:00E6 X:7208 Y:0017 S:01E9 DB:7E D:0000 P:00 e |
Code: |
* w4203 at <258,1126>
* r4216 at <258,1170> 44 clocks
* r4217 at <258,1176> |
44 clocks between write to $4203 and read from $4216 ...
Sigh, you might want to stick with wip4 for testing... or use both, whatever works.
Quote: |
Edit: Nevermind. Didn't realize secondary button functions were active. |
Yeah, sorry. I realize it's a little complicated; but it's important to
me to be able to switch between keyboard and joypad without having to
remap all of my keys all the time.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 11, 2006 5:49 pm Post subject: |
|
byuu wrote: |
Yow >_<
FitzRoy, have you seen your bsnes icon in 256-color mode? It's only
displaying four colors for some reason. And of course since Windows is
retarded and uses the 256 color icons in 16-bit mode (rather than
downsampling the 24-bit ones), this is a problem... are you able to
store copies of the 24-bit one, only downsampled to 256 colors,
manually?
|
Ehhh, crap. Why can't I ever do something right on the first try. I'll look into this tonight. I know my icon program can create these.
byuu wrote: |
Sigh, you might want to stick with wip4 for testing... or use both, whatever works. |
Alright. I'm glad you figured this out. Really don't want to retest those thousand or so games 
By the way, is there any advice you can give me on the hclock number?
What was .016, for example? What is the range of acceptable values?
I've already tried some numbers and haven't been able to fix the battle
blaze issue. Is it possible this is just a separate regression that has
nothing to do with the taz-mania and top gear 2 issues?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 11, 2006 7:45 pm Post subject: |
|
Have
a new idea for my GTK+ UI wrapper. I can use GtkFixed container to put
my widgets at specific x,y positions and gtk_set_size_request to
specify width,height. Then the magic touch to handle theme issues: a
scalar value for all x,y,width,height values. Starts as 1.0 for
pixel-precision, but can be anywhere from 0.1 to 10.0 to resize the
entire interface as needed to get things looking good. Now I just
need to split off some base abstract classes from libwin32.h, simplify,
create some generic cross-platform types, and then write the GTK+
wrapper, and the linux port should be able to mostly share the Windows
GUI code in its entirity. Limitations would only be what GTK+ were
missing.
HCLOCK was 48*4 (192) for v0.016. Timing has changed between 016 and
017, obviously, so that may account for some fluctuation. Generally,
I've found that ~128-256 works in most cases.
The emulator will clip the value if its too high, so that it always renders before hblank begins (at 274*4, 1096).
Quote: |
I've
already tried some numbers and haven't been able to fix the battle
blaze issue. Is it possible this is just a separate regression that has
nothing to do with the taz-mania and top gear 2 issues? |
Maybe, I don't know.
|
|
Schism New Member
Joined: 07 Dec 2005
Posts: 4
|
Posted: Mon Sep 11, 2006 8:22 pm Post subject: |
|
Tested Zelda on an SNES, guess I did remember wrong. No bug. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 12, 2006 9:02 am Post subject: |
|
Quote: |
Ganso
Pachinko Ou (J) - Appears to show an error message. ZSNES as well.
Super Sleuth plays the game okay. Special cart? NSRT lies? |
What did I tell you guys about Japanese text -_-
'QƒRƒ"ƒgƒ[ƒ‰'̃RƒlƒNƒ^'É'ÍA
'Ήžƒpƒ`ƒ"ƒRƒRƒ"ƒgƒ[ƒ‰ˆÈŠOAÚ'±'µ'È'¢'ʼnº'³'¢B
Translation:
"Dirty otaku, do not attempt to play games from The Land of the Rising Sun."
Or perhaps it says something like:
"Please do not connect a second controller other than the corresponding Pachinko controller." (My Japanese is rusty, but you get the idea).
Hmm, lots of special new hardware turning up here, heh. We should catalogue this stuff.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Sep 12, 2006 4:04 pm Post subject: |
|
NSRT tells you it uses the Lasabirdie in both ports.
_________________
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: Tue Sep 12, 2006 5:41 pm Post subject: |
|
Nach wrote: |
NSRT tells you it uses the Lasabirdie in both ports.
|
Indeed, that's how I found out. :/ The images are just to show people what it is.
Pachinko, on the other hand, has "gamepad" on both ports. And since I
can't understand Japanese, I had to allow the possibility of another
problem.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 12, 2006 6:19 pm Post subject: |
|
If you want to, try and find some pictures of the Pachinko controller, because I can't. The Japanese really have a hate-on for images on websites. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Sep 12, 2006 6:29 pm Post subject: |
|
FitzRoy wrote: |
Pachinko, on the other hand, has "gamepad" on both ports. And since I
can't understand Japanese, I had to allow the possibility of another
problem. |
I have no idea what you're talking about 
Code: |
Mouse/S. Scope/Gamepad:
T2 - The Arcade Game: Port 2
Mouse/Multitap:
Super Gameboy: Port 2
Lasabirdie:
Get in the Hole: Port 1 & 2
Barcode Battler:
Barcode Battler Senki - Conveni Wars: Port 2
Miracle Piano Keyboard:
Miracle Piano Teaching System, The: Port 1
Pachinko:
Ganso Pachinko Ou: Port 2
|
And I have to remember to release another WIP 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
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Sep 12, 2006 7:03 pm Post subject: |
|
byuu wrote: |
09/11/2006 - I concede
Even before I started on bsnes, I always knew bit-perfect emulation of
the SNES was an impossible goal. But I tried anyway. Today, I tried to
reverse engineer the missing details of reading the hardware math
registers without waiting the required amount of time for the
operations to complete. Just testing the very basics, I've discovered
that there are multiple intermediate calculation results for many
different clock positions between the math operation beginning and
completing. I also learned that the results are calculated between
opcode edges, rather than in realtime. I also learned that not only is
the delay different for results of multiplication and division, but
also for results of the division quotient and remainder. Now, I could
spend months (yes, months) logging results of reading the HW math
result registers before the operations complete and RE the partial math
calculations, I could probably even figure out exactly at which point
calculations begin and end. All the while I would be taking massive
speed hits by adding more timer checks and calculations into critical
sections of code. However, this still wouldn't be good enough. There
would still be many clock positions I simply could not test due to
limitations of clock-stepping between writes to the math registers and
reading their results. And even if I were able to figure out every
possible read result, their math calculations, and how and when the
SNES internally decides to calculate these results, I'd still have yet
another major hurdle to overcome: what happens if you write to the
input math registers during calculations to the output registers while
the calculation is currently in progress? Probably lots of fun new
results to try and decipher. Easily 4+ months of work, and for what?
Emulating two math register edge cases that have never been used, even
unintentionally, in any commercial games ever released, to our
knowledge. And I have to wonder... who's going to spend months of their
life working on something without ever seeing any results from that
work?
And then there's so many other edge cases just like this: toggling
overscan enable between V=225 and V=240, writing to PPU registers
during active display, S-DSP register caching between the 32khz output
clock rate, etc, etc.
And ultimately, I have to concede. A fully bit-perfect emulator would
take decades to create using current emulation techniques, achieve no
visible improvements in virtually any games, and require absolutely
astounding CPU horsepower to run at full speed. Let alone with extra
features such as video filters and fast forwarding. Now, I'm not saying
accuracy in any form is a bad thing. But if we know that perfection can
never be achieved, where do we draw the middle ground between
performance and hardware accuracy? A very tough question, that I am
currently faced with, it seems...
Now, with that said: I've no intentions of reverting any accuracy that
currently exists in bsnes. This is more about what direction to take
bsnes toward in the future. I still plan to write a dot-based PPU
renderer, but I think that will very likely be the last major accuracy
improvement bsnes makes over existing emulators. I'm sure we'd all like
to think I could keep working on bsnes forever, but we all know that
isn't going to happen. I need to start prioritizing on what needs to be
done, so that I can leave this project with the most complete overall
emulator possible. I honestly don't know how much longer I will
continue to work on bsnes. While I presently have no plans to stop
working on it, it is absolutely inevitable that it will eventually
happen. Hopefully not for at least a few more years yet...
Along those lines, I need to start working smarter instead of harder.
I'm going to try getting into hardware engineering. I absolutely
require more specialized hardware if I'm ever going to make any
progress on emulating special chips such as the SPC7110, testing
power-on behavior of the base SNES unit, etc; and as usual, no one
capable seems all that interested in doing any of the work for me. |
Byuu, I admire your goals of bit-perfectly emulating the SNES. Did you
believe that this was a realistic goal at the outset?
In my opinion, the goal of using software to emulate a physical object,
a complex machine such as the SNES, is unrealistic.
One thing that seems to guide you when programming bsnes is to make
software that runs on the real thing also run (identically) in bsnes.
Additionally, software that doesn't run on the real thing should not run in bsnes. I think that this could continue to be a good secondary goal for bsnes.
Obviously, bit-perfectly emulating some parts of the SNES are going to
be prohibitively time-consuming and require more processing power than
most users have available. Is it possible to find a happy medium
between fine-grained approximation and bit-perfect emulation?
You're the only one holding yourself up to such high standards (of
emulation). I don't think a single one of your users expects you to
spend 4 months researching math operation delays, for the very reason
you said (no results).
Work smarter, not harder.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 12, 2006 8:43 pm Post subject: |
|
That it is. Good find.
byuu wrote: |
And ultimately, I have to concede. A fully bit-perfect emulator would take decades to create. |
Right on. The Super Nintendo is a game system. The original hardware
was designed to entertain people with games. If there are attributes of
the system that have no influence on any commercial game, why spend
exorbitant amounts of time trying to emulate them? Achieving perfect
game compatibility through
accurate hardware emulation/implimentation is a reasonable and
obtainable goal. Emulating all hardware behavior regardless of its
effect on games or emulator performance is not.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Sep 12, 2006 8:57 pm Post subject: |
|
2コントローラのコネクタには、
対応パチンココントローラ以外、接続しないで下さい。
Hmmm...My translation is like this:
" Do not connect anything else other than the supported Pachinko controller into the second controller port."
(more accurate)
When it comes to Kanji...my Japanese is never rusty.
And,in the future,could you please use Unicode? 
BTW,the two profile system of 0.17 wip7 is a great improvement.Much easier to set up and more intuitive.
Last edited by kick on Tue Sep 12, 2006 9:29 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 12, 2006 9:19 pm Post subject: |
|
Yes, it is! Thanks :)
I would've never suspected eBay would have it, after not even finding
the game itself on Yahoo! Japan Auctions... go figure.
Too bad they want $50 for it, it looks pretty simple to RE. No, don't
anyone buy it. $50 is crazy for a gamepad, even if you're rich.
Quote: |
(much more accurate) |
Much more? ... alright then, thanks.
Quote: |
And,in the future,could you please use Unicode? |
Nope :P
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Sep 12, 2006 9:28 pm Post subject: |
|
 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 12, 2006 9:29 pm Post subject: |
|
kick wrote: |
BTW,the two profile system of 0.17 wip7 is a great improvement.Much easier to set up and more intuitive. |
I must post to agree. Recent tangents kind of buried this great
concession from byuu. I love always knowing what "profile" I'm on, the
ease of initial setup, as well as having designated names and options
for both modes. woot!
byuu wrote: |
Too
bad they want $50 for it, it looks pretty simple to RE. No, don't
anyone buy it. $50 is crazy for a gamepad, even if you're rich. |
Pff. That's actually pretty reasonable for as rare as it is. You just hate charity.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Sep 12, 2006 9:44 pm Post subject: |
|
Can I get the link to the latest wip? I tried guessing the link from previous wips, but that didnt work. Thanks! |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Sep 12, 2006 9:49 pm Post subject: |
|
FitzRoy wrote: |
Pff. That's actually pretty reasonable for as rare as it is. You just hate charity. |
Yeah...
And being a collector of NeoGeo and other arcade games, $50 really
seems like nothing for some apparently rare hardware. If it's for a
good cause, I don't mind.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 12, 2006 9:58 pm Post subject: |
|
I'm
serious, though. He wouldn't even let me lend him something I already
owned. And I'm not buying that thing anyway, so if he changes his mind,
it's up to you. Fuck pachinko when I can buy something I care about.  |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Sep 12, 2006 10:29 pm Post subject: |
|
Heh,
if byuu is that uncomfortable with donations, he shouldn't see them as
charity, as everyone will benefit from them in the long term, through
the improvements of his emulator... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 12, 2006 10:51 pm Post subject: |
|
For one, it's a Pachinko controller. That works with one lousy Japanese game to our knowledge.
Two, it's money. I don't like money that isn't mine going into my projects.
Three, it's Pachinko. Even if I get the hardware, I wouldn't much enjoy
figuring it out. Although admittedly, it would be very easy to do.
Four, if someone really
wants to waste their money, then I suppose I could do it. I would
demand the sender receive the hardware back when I'm finished, and not
bug me about progress on it, though.
And don't even ask about the golf controller or MIDI keyboard. I'm not touching those with a 10ft pole.
As for the S/PDIF SNES... I'm learning about all of this resistor,
capacitor, transistor, oscillator, voltage + current regulator, watts,
joules, ergs, ohms, volts, coulombs, amperes, farads, anodes, cathodes,
resistance, current, capacitance, force, impedance, elastence, etc etc
etc etc crap now.
I should be able to make my own in a few months, assuming I don't electrocute myself to death first :)
Seriously, I'm most worried about switching polarity on these
electrolytic capacitors by mistake and having them blow up in my face
at the moment x.x
And I still have no clue as to how the hell I'm going to pull off
getting 100-pin surface mount IC such as the SPC7110 into a breadboard
or something. There's no way any human mortal could solder wires onto
all of those legs with no crosstalk between them. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Sep 12, 2006 11:05 pm Post subject: |
|
The golf controller isn't worth emulating,but I would LOVE to see that MIDI keyboard supported.
And what about ASCII's 'Tsukuru' series of games that use the "Turbo
File" memory cards,so you can save data in Ongaku Tsukuru Kanaderu for
example,and load it into RPG Tsukuru 2 ?
Or exchange between Sound Novel Tsukuru and Ongaku Tsukuru Kanaderu?
I would love to see this implemented. No emulator has ever done this.
It's interesting how only SNES9x actually runs the BS Zelda Kodai no
Sekiban games,but none of them are playable.(controls don't respond)
I would like to see an emulator that will support these 'series' to be playable at last.
Also,about SuperFX emulation,SNES9x has great SuperFX support,but
emulation is way too fast.On the other hand,ZSNES has the emulation
running too slow.Emulating the SuperFX at correct speed still seems
difficult to achieve. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Sep 12, 2006 11:12 pm Post subject: |
|
byuu wrote: |
Four, if someone really
wants to waste their money, then I suppose I could do it. I would
demand the sender receive the hardware back when I'm finished, and not
bug me about progress on it, though. |
That doesn't sound bad, except I wouldn't want the thing back, I've got too much junk on my hands as is...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 12, 2006 11:22 pm Post subject: |
|
My order of desire:
1. Core game fixes
2. Multitap support
3. Any new Special Chip
4. BS-X |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue Sep 12, 2006 11:24 pm Post subject: |
|
kick wrote: |
Also,about
SuperFX emulation,SNES9x has great SuperFX support,but emulation is way
too fast.On the other hand,ZSNES has the emulation running too
slow.Emulating the SuperFX at correct speed still seems difficult to
achieve. |
In bsnes, achieving this in an accurate sense would probably take a
real beefy processer and system for full speed emulation.
Stifu, are you going to buy that Pachinko off eBay? It says it's $24.99 buy now here.
Edit: Ahh, ok, $24.50 shipping is a little much for that thing.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 13, 2006 1:18 am Post subject: |
|
Work smarter not harder? Seriously, been smoking Dilbert PHB much lately?
_________________
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: Wed Sep 13, 2006 5:07 am Post subject: |
|
All "H" and "I" (J) games tested. Problems found: 1 possible.
Okay, so what's the story on this one. Reports as normal type with gamepad/gamepad in NSRT:
Honkaku Shougi Fuuunji Ryuuou (J) - hangs at "Virgin" logo. Happens in all emulators. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 13, 2006 6:26 am Post subject: |
|
FitzRoy wrote: |
All "H" and "I" (J) games tested. Problems found: 1 possible.
Okay, so what's the story on this one. Reports as normal type with gamepad/gamepad in NSRT:
Honkaku Shougi Fuuunji Ryuuou (J) - hangs at "Virgin" logo. Happens in all emulators. |
This game is a bit wierd. It doesn't like more than two controllers
plugged in and is a bit finiky on timing, but I didn't have a problem
running it in ZSNES.
Screenshots:



_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Wed Sep 13, 2006 8:10 am Post subject: |
|
King Of Chaos wrote: |
Stifu, are you going to buy that Pachinko off eBay? It says it's $24.99 buy now here. |
When I get byuu's final confirmation, about me not keeping the item and all. :p
Also, it seems like the whole thing bothers him more than it pleases him... o_o
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Wed Sep 13, 2006 12:41 pm Post subject: |
|
byuu wrote: |
Yes, it is! Thanks 
|
no problem 
mod edit: please don't post long URL's like that which invoke use of
the horizonal scrollbar, either make the link a text-based hyperlink
like above, or use www.tinyurl.com
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 13, 2006 1:33 pm Post subject: |
|
I just tested Honkaku Shougi Fuuunji Ryuuou in Snes9x and bsnes, works fine in both of them as well.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed Sep 13, 2006 3:14 pm Post subject: |
|
Stifu wrote: |
King Of Chaos wrote: |
Stifu, are you going to buy that Pachinko off eBay? It says it's $24.99 buy now here. |
When I get byuu's final confirmation, about me not keeping the item and all. :p
Also, it seems like the whole thing bothers him more than it pleases him... o_o
|
Personally, I'd buy it and keep it even if byuu didn't wan't it.
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Wed Sep 13, 2006 4:35 pm Post subject: |
|
King Of Chaos wrote: |
Personally, I'd buy it and keep it even if byuu didn't wan't it.  |
The thing is I'm not interested in that pad at all.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Sep 13, 2006 5:03 pm Post subject: |
|
Nach wrote: |
I just tested Honkaku Shougi Fuuunji Ryuuou in Snes9x and bsnes, works fine in both of them as well. |
hhhwwhat? What am I doing wrong? I'm posting the md5 of my rom tonight after work.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 13, 2006 5:19 pm Post subject: |
|
Stifu wrote: |
King Of Chaos wrote: |
Personally, I'd buy it and keep it even if byuu didn't wan't it. :wink: |
The thing is I'm not interested in that pad at all.
|
Exactly why you shouldn't buy it.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 13, 2006 7:06 pm Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
I just tested Honkaku Shougi Fuuunji Ryuuou in Snes9x and bsnes, works fine in both of them as well. |
hhhwwhat? What am I doing wrong? I'm posting the md5 of my rom tonight after work.
|
Did you press A after waiting at the Virgin logo for 5 seconds?
Code: |
---------------------Internal ROM Info----------------------
File: Honkaku Syogi Fuunji Ryuou (J).smc
Name: HONKAKU FUUUNJI RYUOU Company: Virgin Games
Header: None Bank: LoROM
Interleaved: No SRAM: 64 Kb
Type: Normal + Batt ROM: 8 Mb
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0xDB58 CRC32: B8BE82C2
MD5: 6DAB4BF6C34CEF8CACAA58D7ACDE17DB
--------------------------Database--------------------------
Name: Honkaku Shougi Fuuunji Ryuuou
Country: Japan Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Board Game Genre 2: Shougi
|
_________________
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: Thu Sep 14, 2006 12:34 am Post subject: |
|
Nach wrote: |
Did you press A after waiting at the Virgin logo for 5 seconds? |
Alright, it works. What I was doing last night was mashing buttons
trying to get it to go in. Apparently "A" in this game doesn't register
if you're holding down another button, even if it's directional. WOW. I
don't think I've ever seen that kind of behavior, let alone a game that
requires a button press to get to the title screen. What a piece of
shit game.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Sep 14, 2006 12:43 am Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
Did you press A after waiting at the Virgin logo for 5 seconds? |
Alright, it works. What I was doing last night was mashing buttons
trying to get it to go in. Apparently "A" in this game doesn't register
if you're holding down another button, even if it's directional. WOW. I
don't think I've ever seen that kind of behavior, let alone a game that
requires a button press to get to the title screen. What a piece of
shit game.
|
It must've been in the manual or something. At least this pales in
comparison to those people who can't seem to start FF3 for instance...
_________________
FF4 research never ends for me.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Sep 14, 2006 2:36 am Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
Did you press A after waiting at the Virgin logo for 5 seconds? |
Alright, it works. What I was doing last night was mashing buttons
trying to get it to go in. Apparently "A" in this game doesn't register
if you're holding down another button, even if it's directional. WOW. I
don't think I've ever seen that kind of behavior, let alone a game that
requires a button press to get to the title screen. What a piece of
shit game.
|
The game isn't that bad actually. I just wish I really knew how to play
Shougi. It's too different from Chess, and nothing like Siami Shougi
which seems to be a variation on Othello.
I know how to play and enjoy Chess, Othello, and Siami Shougi, yet this
looks like fun and I'm stumped what's with the peice promotion and
stuff.
_________________
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: Thu Sep 14, 2006 4:17 am Post subject: |
|
Certainly
I'm not referring to the gameplay with that, because I don't know how
to play either. I'm just hating on it for tricking me.
All "J" (J) games tested. 1 bug found.
Jumbo Ozaki no Hole in One (J) - name screen gfx screws up badly. Does
not occur in zsnes or sleuth. Happens in all bsnes versions. On the
list it goes... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 14, 2006 7:26 am Post subject: |
|
Worked on joypad input stuff.
The core emulation now takes a device type and device id for each port
(of two). So now you can set the device to 'none' or 'joypad', and then
set device id to 'joypad 1', 'joypad 2', etc.
Yes, this allows you to set both ports to the same joypad id. Makes for
a fun game in 2-player fighters, even if left and right aren't mirrored
for it to be a true 'shadow fight'.
No, I won't stop this from happening. You could do this on hardware,
too, if you wired one controller into both ports, and that's good
enough for me.
Eventually, if I ever get around to adding the MP5 (I've no plans to
add it), it will just use input settings for 'joypad 2' - 'joypad 5/6'.
Or maybe 1-5/6-10. I don't know yet.
The input configuration page is kind of busted right now, but things
work on the emulation settings page, and you can now get in-game with
that shougi ROM.
As a side note, I'm not going to be spending much (if any) time fixing
bugs for a while. I'm pretty much intent on studying electronic
circuits at the moment. Feel free to keep looking for them, though.
It'd be cool if we ever get all games tested. Then we can create a much
more accurate compatibility rate %, albeit only covering up to 5
minutes in-game. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 14, 2006 7:54 am Post subject: |
|
I
fully intend on having all games tested by the end of the month. I'm
also keeping a list of possible bugs so that I can verify them all when
I get my tototek cart. Even though it's 5 minutes into each game, that
still should give a very accurate projection. Intro, title, menus, and
a few minutes of gameplay for every snes game covers a LOT of
emulation. The chances of an unseen effect or a bug existing beyond all
of that is very slim, but possible. In any case, when testing is done,
that's it (thank god). The only way further issues can be found is from
people who actually play and beat games for fun. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Sep 14, 2006 2:41 pm Post subject: |
|
FitzRoy wrote: |
when I get my tototek cart. |
Which one are you getting? Doctor SF7?
From what I've seen on that website, you can max out your SF7 with
128MB RAM and the DSP adapter. What's the advantage of having more
memory in one of these things? Which games require it?
And what is inside the DSP add-on? Just a DSP-1 chip?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 14, 2006 8:20 pm Post subject: |
|
I'm getting the tototek flash cart. SF7 is a third party product. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Sep 14, 2006 8:48 pm Post subject: |
|
Which one?
Are the Tototek products functionally equivalent to the GDSF7?
I can't really make sense of how the Tototek product works, what with all the broken English.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 14, 2006 11:09 pm Post subject: |
|
It's
a kit. Super-Flash 64m. You get a flasher that connects to your
computer via usb. You install the software on your computer to flash
and dump devices connected to the flasher. The flash cart goes on the
flashing device to be flashed. Once it's flashed, you remove it from
the flasher and put it in the snes like a normal cart. The T-Connector
is an option for playing DSP chip games. The CIC chip is for C4 chip
games.
All "K" (J) games tested. 1 obvious problem found.
Koushien 2 (J) - after playing for a while, music stops, then game
hangs. Does not occur in zsnes. Occurs in all bsnes versions. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 14, 2006 11:36 pm Post subject: |
|
Quote: |
Koushien 2 (J) - after playing for a while, music stops, then game hangs. Does not occur in zsnes. Occurs in all bsnes versions. |
Played for over five minutes with no problems. No idea what you're talking about.
Very strange that you play the batter for both teams in this game.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 14, 2006 11:49 pm Post subject: |
|
byuu wrote: |
Quote: |
Koushien 2 (J) - after playing for a while, music stops, then game hangs. Does not occur in zsnes. Occurs in all bsnes versions. |
Played for over five minutes with no problems. No idea what you're talking about.
Very strange that you play the batter for both teams in this game.
|
Errr, I wasn't batting for both teams. I just hit start 7 times. Can't
read the options so I don't know what kind of game I picked. Maybe you
chose a different one where it doesnt happen. This time the sounds went
all screwy before dropping out :/
EDIT: weird, this time I went two innings before it happened.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 14, 2006 11:56 pm Post subject: |
|
Ah, I see. The batter was just switching sides. Could've sworn the uniform colors were reversed too.
You have to play way the hell into it to crash it. Alright. Don't
expect me to work much on this one even when I do get back to fixing
bugs, since I don't have savestates.
Jumbo Ozaki no Hole in One (J) - gfx messes up in name screen
VRAM corruption at 0xa800+. Too busy learning to work on bsnes at the moment, though. Sorry.
Interesting find, though. bsnes being the only actively-developed emulator with this bug.
Damn, I started on bsnes with the goals of working on emulating and
improving the classics. Zelda 3, Mario World, Super Metroid,
Castlevania IV... instead, I'm tracking down shady coding problems in
Jumbo Ozaki no Hole in One ;_; |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 15, 2006 12:02 am Post subject: |
|
byuu wrote: |
Damn,
I started on bsnes with the goals of working on emulating and improving
the classics. Zelda 3, Mario World, Super Metroid, Castlevania IV...
instead, I'm tracking down shady coding problems in Jumbo Ozaki no Hole
in One ;_; |
How dare you mention those four travesties in the same sentence as the great Jumbo Ozaki no Hole in One!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 15, 2006 12:07 am Post subject: |
|
You reply too fast :P
Circuit USA looks to be the same problem as Jumbo no Bad Game in One. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 15, 2006 12:13 am Post subject: |
|
byuu wrote: |
You reply too fast 
Circuit USA looks to be the same problem as Jumbo no Bad Game in One. |
Yeah I've got the forum refreshing as I hunt for bugs. Circuit USA is
okay in .016, whereas the golf game still screws up in .016. Can they
still be the same problem?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Sep 15, 2006 12:59 am Post subject: |
|
FitzRoy wrote: |
Koushien 2 (J) - after playing for a while, music stops, then game
hangs. Does not occur in zsnes. Occurs in all bsnes versions. |
If this occurs in ZSNES v1.36 but not in later versions, I might know what the problem is. Can you look into that?
_________________
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 15, 2006 2:49 am Post subject: |
|
Sure. Doesn't occur in 1.36 or ipher's latest wip. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 15, 2006 6:28 am Post subject: |
|
Ah, well at least Circuit USA will be easier to fix, then.
EDIT: problem with sCPU.
Code: |
80923d jsr $900b [$80900b] A:0240 X:0140 Y:0005 S:1ff9 D:0000 DB:00 nvmxdIzC
80900b stz $4300 [$004300] A:0240 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
80900e lda #$2122 A:0240 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809011 sta $4301 [$004301] A:2122 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809014 lda #$0100 A:2122 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809017 sta $4302 [$004302] A:0100 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
80901a stz $4304 [$004304] A:0100 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
80901d lda #$0200 A:0100 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809020 sta $4305 [$004305] A:0200 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809023 sep #$20 A:0200 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
809025 stz $2121 [$002121] A:0200 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvMxdIzC
809028 rep #$20 A:0200 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvMxdIzC
80902a lda #$0001 A:0200 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
80902d sta $420b [$00420b] A:0001 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC
* CGRAM 0004 write 0f @ <124, 304>
* CGRAM 0004 write 1d @ <124,1202>
* CGRAM 0004 write 00 @ <125,1200>
* CGRAM 0004 write 00 @ <126,1254>
809030 rts A:0001 X:0140 Y:0005 S:1ff7 D:0000 DB:00 nvmxdIzC |
Remember how I said I removed DMA bus sync delay? In the current bsnes,
the write to $420b starts DMA immediately. But you see, this write
happens before the $420c write. HDMA is still on before this write,
though. So basically, HDMA kicks in, kills the DMA transfer, and then
starts causing all kinds of havoc on CGRAM.
bCPU works with this game because it has the one-cycle delay before
starting DMA. Opcode-stepping CPU emulators (ZSNES et al) work with the
game because they perform DMA between opcodes.
I can fix this by adding DMA bus sync timing to sCPU, but I really
don't want to right now. That code is always a pain in the ass to write
:(
I'd rather spend my weekend playing with real circuits rather than Circuit USA ;_;
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 15, 2006 10:07 pm Post subject: |
|
Jumbo Ozaki no Hole in One (J):
Code: |
a800 = 11,20,12,20
a800 = 20,20,20,20
<2b413 in zst>
5400
00870C LDA [$00],Y [00AFF1] A:0AA7 X:AFEB Y:0006 S:1FE5 DB:00 D:1DD6 P:04 e
00870E STA $09 [001DDF] A:5400 X:AFEB Y:0006 S:1FE5 DB:00 D:1DD6 P:04 e
00876D LDA $09 [001DDF] A:7E80 X:0096 Y:0044 S:1FDF DB:00 D:1DD6 P:95 e
00876F STA $0200,X [000296] A:5400 X:0096 Y:0044 S:1FDF DB:00 D:1DD6 P:15 e
0086F9 LDA [$00],Y [00AFF4] A:548C X:0098 Y:0009 S:1FE5 DB:00 D:1DD6 P:A4 e
0086FB STA $04 [001DDA] A:5400 X:0098 Y:0009 S:1FE5 DB:00 D:1DD6 P:26 e
---
VRAM before DMA
3F083F083F083F083F083F083F083F08
3F083F083F083F083F083F083F083F08
3F083F083F083F083F083F083F083F08
3F083F083F083F083F083F083F083F08
008515 JSR $8612 [008612] A:0220 X:0001 Y:001F S:1FCC DB:00 D:0000 P:15 e
008612 REP #$20 A:0220 X:0001 Y:001F S:1FCA DB:00 D:0000 P:15 e
008614 SEP #$10 A:0220 X:0001 Y:001F S:1FCA DB:00 D:0000 P:15 e
008616 LDX $02 [000002] A:0220 X:0001 Y:001F S:1FCA DB:00 D:0000 P:15 e
008618 CPX $03 [000003] A:0220 X:0090 Y:001F S:1FCA DB:00 D:0000 P:95 e
00861A BEQ $8658 [008658] A:0220 X:0090 Y:001F S:1FCA DB:00 D:0000 P:94 e
00861C LDY $0200,X [000290] A:0220 X:0090 Y:001F S:1FCA DB:00 D:0000 P:94 e
00861F LDA $865B,Y [008661] A:0220 X:0090 Y:0006 S:1FCA DB:00 D:0000 P:14 e
008622 STA $4300 [004300] A:1800 X:0090 Y:0006 S:1FCA DB:00 D:0000 P:14 e
008625 LDA $865D,Y [008663] A:1800 X:0090 Y:0006 S:1FCA DB:00 D:0000 P:14 e
008628 TAY A:0800 X:0090 Y:0006 S:1FCA DB:00 D:0000 P:14 e
008629 STY $2115 [002115] A:0800 X:0090 Y:0000 S:1FCA DB:00 D:0000 P:16 e
00862C INX A:0800 X:0090 Y:0000 S:1FCA DB:00 D:0000 P:16 e
00862D LDA $0200,X [000291] A:0800 X:0091 Y:0000 S:1FCA DB:00 D:0000 P:94 e
008630 STA $4305 [004305] A:0400 X:0091 Y:0000 S:1FCA DB:00 D:0000 P:14 e
008633 INX A:0400 X:0091 Y:0000 S:1FCA DB:00 D:0000 P:14 e
008634 INX A:0400 X:0092 Y:0000 S:1FCA DB:00 D:0000 P:94 e
008635 LDA $0200,X [000293] A:0400 X:0093 Y:0000 S:1FCA DB:00 D:0000 P:94 e 10010100
008638 STA $4302 [004302] A:8000 X:0093 Y:0000 S:1FCA DB:00 D:0000 P:94 e
00863B INX A:8000 X:0093 Y:0000 S:1FCA DB:00 D:0000 P:94 e
00863C INX A:8000 X:0094 Y:0000 S:1FCA DB:00 D:0000 P:94 e
00863D LDY $0200,X [000295] A:8000 X:0095 Y:0000 S:1FCA DB:00 D:0000 P:94 e
008640 STY $4304 [004304] A:8000 X:0095 Y:007E S:1FCA DB:00 D:0000 P:14 e
008643 INX A:8000 X:0095 Y:007E S:1FCA DB:00 D:0000 P:14 e
008644 LDA $0200,X [000296] A:8000 X:0096 Y:007E S:1FCA DB:00 D:0000 P:94 e
008647 STA $2116 [002116] A:5400 X:0096 Y:007E S:1FCA DB:00 D:0000 P:14 e
00864A TAY A:5400 X:0096 Y:007E S:1FCA DB:00 D:0000 P:14 e
00864B STY $2121 [002121] A:5400 X:0096 Y:0000 S:1FCA DB:00 D:0000 P:16 e
00864E INX A:5400 X:0096 Y:0000 S:1FCA DB:00 D:0000 P:16 e
00864F INX A:5400 X:0097 Y:0000 S:1FCA DB:00 D:0000 P:94 e
008650 LDY #$01 A:5400 X:0098 Y:0000 S:1FCA DB:00 D:0000 P:94 e
008652 STY $420B [00420B] A:5400 X:0098 Y:0001 S:1FCA DB:00 D:0000 P:14 e
7e8000 DMA of #$0400 bytes
158000
$2115 = #$00
$4300 = #$00
$4301 = #$18
$4302 = $958000
$4305 = #$0400
VRAM after DMA
11081208120812081208120812081208
12081208120812081208120812081208
12081208120812081208120812081208
12081208120812081208120812081108
---
008515 JSR $8612 [008612] A:0220 X:0001 Y:00FF S:1FE8 DB:00 D:0000 P:14 e
008612 REP #$20 A:0220 X:0001 Y:00FF S:1FE6 DB:00 D:0000 P:14 e
008614 SEP #$10 A:0220 X:0001 Y:00FF S:1FE6 DB:00 D:0000 P:14 e
008616 LDX $02 [000002] A:0220 X:0001 Y:00FF S:1FE6 DB:00 D:0000 P:14 e
008618 CPX $03 [000003] A:0220 X:0098 Y:00FF S:1FE6 DB:00 D:0000 P:94 e
00861A BEQ $8658 [008658] A:0220 X:0098 Y:00FF S:1FE6 DB:00 D:0000 P:94 e
00861C LDY $0200,X [000298] A:0220 X:0098 Y:00FF S:1FE6 DB:00 D:0000 P:94 e
00861F LDA $865B,Y [008667] A:0220 X:0098 Y:000C S:1FE6 DB:00 D:0000 P:14 e
008622 STA $4300 [004300] A:1900 X:0098 Y:000C S:1FE6 DB:00 D:0000 P:14 e
008625 LDA $865D,Y [008669] A:1900 X:0098 Y:000C S:1FE6 DB:00 D:0000 P:14 e
008628 TAY A:0880 X:0098 Y:000C S:1FE6 DB:00 D:0000 P:14 e
008629 STY $2115 [002115] A:0880 X:0098 Y:0080 S:1FE6 DB:00 D:0000 P:94 e
00862C INX A:0880 X:0098 Y:0080 S:1FE6 DB:00 D:0000 P:94 e
00862D LDA $0200,X [000299] A:0880 X:0099 Y:0080 S:1FE6 DB:00 D:0000 P:94 e
008630 STA $4305 [004305] A:0400 X:0099 Y:0080 S:1FE6 DB:00 D:0000 P:14 e
008633 INX A:0400 X:0099 Y:0080 S:1FE6 DB:00 D:0000 P:14 e
008634 INX A:0400 X:009A Y:0080 S:1FE6 DB:00 D:0000 P:94 e
008635 LDA $0200,X [00029B] A:0400 X:009B Y:0080 S:1FE6 DB:00 D:0000 P:94 e
008638 STA $4302 [004302] A:8400 X:009B Y:0080 S:1FE6 DB:00 D:0000 P:94 e
00863B INX A:8400 X:009B Y:0080 S:1FE6 DB:00 D:0000 P:94 e
00863C INX A:8400 X:009C Y:0080 S:1FE6 DB:00 D:0000 P:94 e
00863D LDY $0200,X [00029D] A:8400 X:009D Y:0080 S:1FE6 DB:00 D:0000 P:94 e
008640 STY $4304 [004304] A:8400 X:009D Y:007E S:1FE6 DB:00 D:0000 P:14 e
008643 INX A:8400 X:009D Y:007E S:1FE6 DB:00 D:0000 P:14 e
008644 LDA $0200,X [00029E] A:8400 X:009E Y:007E S:1FE6 DB:00 D:0000 P:94 e
008647 STA $2116 [002116] A:5400 X:009E Y:007E S:1FE6 DB:00 D:0000 P:14 e
00864A TAY A:5400 X:009E Y:007E S:1FE6 DB:00 D:0000 P:14 e
00864B STY $2121 [002121] A:5400 X:009E Y:0000 S:1FE6 DB:00 D:0000 P:16 e
00864E INX A:5400 X:009E Y:0000 S:1FE6 DB:00 D:0000 P:16 e
00864F INX A:5400 X:009F Y:0000 S:1FE6 DB:00 D:0000 P:94 e
008650 LDY #$01 A:5400 X:00A0 Y:0000 S:1FE6 DB:00 D:0000 P:94 e
008652 STY $420B [00420B] A:5400 X:00A0 Y:0001 S:1FE6 DB:00 D:0000 P:14 e
7e8400 DMA of #$0400 bytes
<9013 in zst>
$2115 = #$80
$4300 = #$00
$4301 = #$19
$4302 = $7e8400
$4305 = #$0400
VRAM after DMA
11201220122012201220122012201220
12201220122012201220122012201220
12201220122012201220122012201220
12201220122012201220122012201160
---
cpulog15
00029b == #$8000 instead of #$8400
* write 00 to $029b at 008764
* write 80 to $029c at 00876b
* DMA 7e8000
* 20 20 20 20 20 20 20 20
* DMA 7e8000
* 20 20 20 20 20 20 20 20
0006/05(1dd3)/04(1dd2)
00875F LDA $05 [001DDB] A:000C X:009A Y:0062 S:1FDF DB:00 D:1DD6 P:95 e
008761 STA $0200,X [00029A] A:0004 X:009A Y:0062 S:1FDF DB:00 D:1DD6 P:15 e
008764 INX A:0004 X:009A Y:0062 S:1FDF DB:00 D:1DD6 P:15 e
008765 INX A:0004 X:009B Y:0062 S:1FDF DB:00 D:1DD6 P:95 e
008766 LDA $07 [001DDD] A:0004 X:009C Y:0062 S:1FDF DB:00 D:1DD6 P:95 e
008768 STA $0200,X [00029C] A:7E84 X:009C Y:0062 S:1FDF DB:00 D:1DD6 P:15 e
00876B INX A:7E84 X:009C Y:0062 S:1FDF DB:00 D:1DD6 P:15 e
00876C INX A:7E84 X:009D Y:0062 S:1FDF DB:00 D:1DD6 P:95 e
00875f lda $05 [$001ddb] A:000c X:009a Y:0062 S:1fdf D:1dd6 DB:00 NvmXdIzC
008761 sta $0200,x [$00029a] A:0004 X:009a Y:0062 S:1fdf D:1dd6 DB:00 nvmXdIzC
008764 inx A:0004 X:009a Y:0062 S:1fdf D:1dd6 DB:00 nvmXdIzC
008765 inx A:0004 X:009b Y:0062 S:1fdf D:1dd6 DB:00 NvmXdIzC
008766 lda $07 [$001ddd] A:0004 X:009c Y:0062 S:1fdf D:1dd6 DB:00 NvmXdIzC
008768 sta $0200,x [$00029c] A:7e80 X:009c Y:0062 S:1fdf D:1dd6 DB:00 nvmXdIzC
00876b inx A:7e80 X:009c Y:0062 S:1fdf D:1dd6 DB:00 nvmXdIzC
00876c inx A:7e80 X:009d Y:0062 S:1fdf D:1dd6 DB:00 NvmXdIzC
---
00872D PLA A:86FF X:8800 Y:0062 S:1FE1 DB:00 D:1DD6 P:07 e
00872E STA $06 [001DDC] A:8400 X:8800 Y:0062 S:1FE3 DB:00 D:1DD6 P:85 e
00872d pla A:82ff X:8400 Y:0062 S:1fe1 D:1dd6 DB:00 nvmxdIZC
00872e sta $06 [$001ddc] A:8000 X:8400 Y:0062 S:1fe3 D:1dd6 DB:00 NvmxdIzC
---
00871D LDY $0006 [000006] A:540A X:A922 Y:0010 S:1FE3 DB:00 D:1DD6 P:A4 e
008720 PHY A:540A X:A922 Y:8400 S:1FE3 DB:00 D:1DD6 P:A4 e
00871d ldy $0006 [$000006] A:540a X:a922 Y:0010 S:1fe3 D:1dd6 DB:00 NvMxdIzc
008720 phy A:540a X:a922 Y:8000 S:1fe3 D:1dd6 DB:00 NvMxdIzc
---
00872E STA $06 [001DDC] A:8000 X:8400 Y:0144 S:1FE3 DB:00 D:1DD6 P:85 e
//ZSNES=<179,????>, Super Sleuth=<222, 112>
008730 STX $0006 [000006] A:8000 X:8400 Y:0144 S:1FE3 DB:00 D:1DD6 P:85 e
00872e sta $06 [$001ddc] A:8000 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 NvmxdIzC
//bsnes=<224,1130>
008730 stx $0006 [$000006] A:8000 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 NvmxdIzC
008733 sep #$20 A:8000 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 NvmxdIzC
008735 lda #$7e A:8000 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 NvMxdIzC
008737 sta $08 [$001dde] A:807e X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 nvMxdIzC
008739 lda $03 [$001dd9] A:807e X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 nvMxdIzC
00873b and #$7f A:8086 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 NvMxdIzC
00873d sta $03 [$001dd9] A:8006 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 nvMxdIzC
00873f rep #$20 A:8006 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 nvMxdIzC
008741 jsr $874d [$00874d] A:8006 X:8400 Y:0144 S:1fe3 D:1dd6 DB:00 nvmxdIzC
00874d phy A:8006 X:8400 Y:0144 S:1fe1 D:1dd6 DB:00 nvmxdIzC
* /NMI
0084f3 pha A:8006 X:8400 Y:0144 S:1fdd D:1dd6 DB:00 nvmxdIzC
...
008526 lda #$8000 A:2000 X:fffe Y:0001 S:1fd4 D:0000 DB:00 nvmxdIzC
008529 sta $0006 [$000006] A:8000 X:fffe Y:0001 S:1fd4 D:0000 DB:00 NvmxdIzC
00852c plb A:8000 X:fffe Y:0001 S:1fd4 D:0000 DB:00 NvmxdIzC
00852d pld A:8000 X:fffe Y:0001 S:1fd5 D:0000 DB:00 nvmxdIZC
00852e ply A:8000 X:fffe Y:0001 S:1fd7 D:1dd6 DB:00 nvmxdIzC
00852f plx A:8000 X:fffe Y:0144 S:1fd9 D:1dd6 DB:00 nvmxdIzC
008530 pla A:8000 X:8400 Y:0144 S:1fdb D:1dd6 DB:00 NvmxdIzC
008531 rti A:8006 X:8400 Y:0144 S:1fdd D:1dd6 DB:00 NvmxdIzC
* /NMI end
00874d phy A:8006 X:8400 Y:0144 S:1fe1 D:1dd6 DB:00 nvmxdIzC
---
* NMI at 008bd2 <225, 20>
* 008730 @ <224,1118>
008730 stx $0006 [$000006] A:8000 X:8400 Y:0144 S:1fe3 D:1dd6
* NMI at 00874e <225, 36>
----------
* NMI at 008bcf <225, 24>
* 008730 @ <223, 522>
008730 stx $0006 [$000006] A:8000 X:8400 Y:0144 S:1fe3 D:1dd6
* NMI at 0089aa <225, 42>
* DMA 7e8000
* 11 11 11 11 11 11 11 11
* 008730 @ <160,1292>
008730 stx $0006 [$000006] A:8400 X:8800 Y:0062 S:1fe3 D:1dd6
* write 84 to $029b at 00876b
* NMI at 008bd2 <225, 22>
* DMA 7e8400
* 20 20 20 20 20 20 20 20
* NMI at 008bcf <225, 22>
* 008730 @ <224,1122>
008730 stx $0006 [$000006] A:8000 X:8400 Y:0144 S:1fe3 D:1dd6
* NMI at 00874e <225, 40>
* 008730 @ <156, 370>
008730 stx $0006 [$000006] A:8000 X:8400 Y:0062 S:1fe3 D:1dd6
* write 80 to $029b at 00876b
* NMI at 008bd2 <225, 38>
* DMA 7e8000
* 20 20 20 20 20 20 20 20
* DMA 7e8000
* 20 20 20 20 20 20 20 20 |
Essentially, bsnes is running a bit slower than a real SNES. The real
game sets $0006 to the location in WRAM of the name entry screen
tilemap. In bsnes, an NMI then triggers and updates $0006 to the wrong
address. This doesn't happen in other emulators because they run faster
(or 2+ scanlines slower, possibly). The game then loads $0006 and uses
it for a DMA transfer from WRAM to VRAM.
One solution to fix it in bsnes is to remove the HDMA per-channel
delay. But that causes flickering to reappear in Energy Breaker. I'll
just have to cave in and work on HDMA bus sync timing again :(
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 15, 2006 10:21 pm Post subject: |
|
Hmm, sounds awful. 
All "#" and "L" (J) games tested: no bugs found. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 15, 2006 10:41 pm Post subject: |
|
T-Z in all regions is already taken care of, thanks to tetsuo. So that means we're almost finished with crazy Japanese games :D
So then, M, N, O, P, Q, R and S. And we both know which of those letters is going to Suck the most, heh.
Keep up the great work, thanks :) |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 16, 2006 3:21 am Post subject: |
|
No problem.
All "M" (J) games tested. 3 bugs found:
Mahjong Taikai II (J) - KOEI intro gfx corrupt, gfx issue on stage during intro (occurs in all bsnes versions)
Mega lo Mania (J, E) - horizontal line issue during intro (does not occur in .016 or .017 official)
Might and Magic II (J) - horizontal line issue on title screen (line is
gone completely in .016 and .017. In .017.07, it flickers.)
No doubt, a lot of these I'm finding are related. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Sep 16, 2006 6:09 am Post subject: |
|
FitzRoy if you get to S dont do that one as i have already started it, but its HUGE 
Byuu, maybe you could do other stuff while you wait for the full list
of bugreports and then start fixing them all at once?
i would think 90% of them are related anyway. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Sat Sep 16, 2006 6:31 pm Post subject: |
|
byuu wrote: |
Damn, I started on bsnes with the goals of working on emulating and
improving the classics. Zelda 3, Mario World, Super Metroid,
Castlevania IV... instead, I'm tracking down shady coding problems in
Jumbo Ozaki no Hole in One ;_;
|
I hear you. I started changing the MESS driver so I could play Super
Metroid and Castlevania IV properly with good sound on Linux and I've
somehow ended up at "rewrite the entire 65816 and then the rendering"
even though the 2 benchmark games seem to work properly.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 16, 2006 6:55 pm Post subject: |
|
tetsuo55 wrote: |
Byuu, maybe you could do other stuff while you wait for the full list of bugreports and then start fixing them all at once?
i would think 90% of them are related anyway. |
That is a good idea, thanks.
Two thirds of my buglist now appears to be those "horizontal scanline
issues" bugs, which is quite simply due to not having a dot-based PPU
renderer. I really need a good solid week off of work to start on that
properly (which I won't have anytime soon), and I'm still not certain I
can even pull it off without requiring more CPU power than anyone even
has...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 16, 2006 8:22 pm Post subject: |
|
All "N" (J) games tested. No problems found.
byuu, what was the hclock position for .017 official? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Sep 16, 2006 8:23 pm Post subject: |
|
I was wondering.. these two things may be completely unrelated, but I don't know so don't hit me if it's nonsense ^_^;
But.. don't the newer graphics cards use per-pixel rendering? So
wouldn't they be rather good at processing dot-based rendering work? |
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Sat Sep 16, 2006 9:53 pm Post subject: |
|
Nevermind byuu. Your talking about something else.
Btw: I using BSNES with MAMEWAH. Because I can pick the roms from the
list on the screen. It much easyer to pick a game. 
================================================
Edit. The capture snapshot doesn't work on bsnes 0.17?

I made a snapshots folder and snaps folder. But still nothing in those folders. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 17, 2006 4:00 am Post subject: |
|
Hooray! built my first working circuit :D
Negative to 5v voltage regulator to 2.2kohm resistor to photoresistor
to 5mm 2.1v LED to positive looped across a 9vdc battery of unknown
amperage.
Result: LED turns on with light in the room, turns off without light.
$110 in parts well spent. Going to try and use an NPN transistor to
make a NOT gate on the photoresistor signal next so it only turns on in
the dark.
100-pin 2cm surface-mount SPC7110... you're on notice.
Quote: |
byuu, what was the hclock position for .017 official? |
128.
Quote: |
The capture snapshot doesn't work on bsnes 0.17? |
Not if you use the DirectDraw renderer (you have to set it manually in
the config file, so you're probably not using it) or if you're missing
d3dx_*.dll.
I've decided not to throw out an error message just yet. Mostly because
I'm planning to rewrite it to use my own code instead of d3dx code. It
will only output bitmaps this way, but won't require any extra drivers.
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Sep 17, 2006 4:02 am Post subject: |
|
byuu wrote: |
9vdc battery of unknown amperage. |
pry around 150-200mAh (best guess I can give, basing these findings off
rechargeable batteries shaped like 9volts, also my psone battery
project, using TWO 9v duracell alkaline batteries)
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Sun Sep 17, 2006 4:57 am Post subject: |
|
byuu wrote: |
Not
if you use the DirectDraw renderer (you have to set it manually in the
config file, so you're probably not using it) or if you're missing
d3dx_*.dll.
I've decided not to throw out an
error message just yet. Mostly because I'm planning to rewrite it to
use my own code instead of d3dx code. It will only output bitmaps this
way, but won't require any extra drivers. |
Where do I need to enable it at? I'm confused.
I have DirectX 9.0c install.
Last edited by T-Doomdays on Sun Sep 17, 2006 5:00 am; edited 1 time in total
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 17, 2006 4:57 am Post subject: |
|
Yeah, it kind of bothers me that my multimeter only goes up to 200mA for voltage measurement x.x
How am I supposed to test my 9VDC, 1000mA power source that I plan to
permanently wire to my breadboard? The 10A port is only for resistance
and/or current measuring, right? |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Sep 17, 2006 5:03 am Post subject: |
|
byuu wrote: |
Yeah, it kind of bothers me that my multimeter only goes up to 200mA for voltage measurement x.x |
I'm going to feel sorry for you when soul sees this thread, but voltage != current.
Volts are a measure of force/pressure/etc in a circuit.
Current is a measure of electricity flow, measured in amps.
Watts are a measure of TRUE power.
Volt-Amps are a measure of APPARENT Power.
And Resisitance is a measure of the resistence of current flow in a circuit, measures in ohms.
byuu wrote: |
How am I supposed to test my 9VDC, 1000mA power source that I plan to permanently wire to my breadboard? |
As long as you don't go over 200mA when testing current flow, you're
fine. If you're measuring voltage, you're fine there too.
byuu wrote: |
The 10A port is only for resistance and/or current measuring, right? |
Eh.. what ? I'm half-inclined to say 1000mA = 1 Amp, but I don't think that's what you mean.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Sun Sep 17, 2006 5:26 am Post subject: |
|
byuu, I download the d3dx9_26.dll (Lates) and put it into the BSNES folder. Now I getting the snapshots made.
I don't know why the DirectX 9.0c doesn't have any of the d3dx*_*.dll files.  |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sun Sep 17, 2006 5:26 am Post subject: |
|
byuu wrote: |
Yeah, it kind of bothers me that my multimeter only goes up to 200mA for voltage measurement x.x
How am I supposed to test my 9VDC, 1000mA power source that I plan to
permanently wire to my breadboard? The 10A port is only for resistance
and/or current measuring, right? |
When the red lead is plugged into the 10A plug, the meter must be set
at the 10A Current reading setting. For all other measurements, it goes
into the normal plug.
Always remember this and take this to heart: Voltage is measured ACROSS
a load. Current is measured by breaking the circuit and measuring IN
SERIES with the load.
I can remember watching in horror as my father ripped my new christmas
present from my hands and attempted to measure the voltage in the 110V
outlet. Hmm, 122V, a little high. Now to measure "current" in a 110V
outlet.
He moved the probe to the 10A lead, and set the meter at 10A, and just
as he started to move the two leads to the power outlet, I asked him if
that was such a good idea... Oh, nonsense, these things are built to
handle that current... Bright flash of white light, the smell of smoke,
there went any possibility of measuring current ever again ;_; but
since there was no blown fuse I could still measure voltage with the
thing...
There are non-contact ways to measure current, but in a multimeter, the
current is calculated from the voltage drop across a shunt (a low-value
resistance).
Byuu, Voltage measurement should not draw more than a single milliAmp from the source, if even that.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 17, 2006 5:39 am Post subject: |
|
Thank you. Needed this info to finish my hclock testing. My conclusions are as follows:
Despite seeing horizontal line issues in quite a few games, it seems
that there are two different issues at work here. One, is the hclock
number issue. The games in this camp are:
Taz Mania (E, U)
Prince of Persia 2 (E, U)
Top Gear 2 (E, U)
Might and Magic II (J)
In .016 (hclock of 192), just "MMII" has an issue.
In .017 (hclock of 128), all games have issues.
In .017.07 (hclock set to 128), all games have issues, like .017.
In .017.07 (hclock set to 192), just "MMII" has an issue, like .016.
In .017.07 (hclockset to 256), no games have the issue.
It appears 192 was not quite high enough. Despite version changes, game
response to hclock changes remained consistent. I also tested 1200
japanese roms with no further issues, so it seems a safe improvement to
increase hclock to 256 for future releases.
The next camp of games with horizontal line issues seem to be caused by
a regression bug that was introduced in .017.04 with either the "Winter
Gold" fix, or the "IRQ" fixes. These games are:
Battle Blaze (J)
Mega lo Mania (J)
In .016 (hclock of 192), neither has a problem.
In .017 (hclock of 128), neither has a problem.
In .017.07 (hclock at 128), both have problems.
In .017.07 (hclock at 192), both have problems.
In .017.07 (hclock at 256), both have problems.
I tried many other hclock settings with .017.07, but nothing had an
effect. The fact that these games work in .017 official proves that
despite the new core, and a lower hclock (which broke our last four
games), the games still worked. The problems came up with .017.04 when
those two fixes were made.
A doubt you could express would be: the IRQ fixes changed the timing to
make a different hclock work. But if that were the case, the behavior
in the previous four games would have also become warped. But they
didn't. Behavior with hclock remained fairly consistent with only the
slight difference of an MMII line flickering instead of not showing up.
Also, I've tried many other values to no avail.
Since the scanline renderer will be the renderer of choice for users
because of its speed and near-identical compatibility, I recommend not
treating these as inherent see-saw bugs of a hackish implimentation,
but a possible bug that can be rectified in the current renderer.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Sep 17, 2006 6:33 am Post subject: |
|
T-Doomdays wrote: |
byuu, I download the d3dx9_26.dll (Lates) and put it into the BSNES folder. Now I getting the snapshots made.
I don't know why the DirectX 9.0c doesn't have any of the d3dx*_*.dll files.  |
That is because DX9c does not come with them by default, you would have to obtain them as those post DX9c updates.
_________________
FF4 research never ends for me.
|
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Sun Sep 17, 2006 9:30 am Post subject: |
|
How I keep the saves, cheats and snapshots out of the roms folder? How I config the paths for those? |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sun Sep 17, 2006 10:00 am Post subject: |
|
Byuu,
I have a rendering request I was wondering if it were possible to
implement. Basically what I'm after is a cropped overscan ability.
What I'd like to do in fullscreen mode is set the "rendering"
resolution to 1280x1120, which is exactly 5x the original resolution.
This makes scanlines appear evenly.
Now the tricky part is I want to set the "screen resolution" to
1280x1024 and have the remaining 96 lines cropped evenly from the top
and bottom of the screen (48 lines each). As it is now, anything set in
the rendering options that goes beyond the screen res settings get
automattically squeezed down into a messy fit.
Let me know what you think of this. Thanks! |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Sep 17, 2006 10:09 am Post subject: |
|
T-Doomdays wrote: |
How I keep the saves, cheats and snapshots out of the roms folder? How I config the paths for those? |
There is a cfg file for BSNES for the save files... try looking in it.
For the latter two, there's nothing you can do at the moment... only byuu can change that (if he wants).
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 17, 2006 8:26 pm Post subject: |
|
adventure_of_link wrote: |
I'm going to feel sorry for you when soul sees this thread, but voltage != current. |
Thank you, but I know that. My point was that there is a positive (red)
connector and a negative (black) connector, and I want to measure
voltage. The positive connector clearly states under it "MAX 200mA",
which suggests to me that it can read voltages up to the amount
specified by the click position I set it to, and that it can only
handle, at maximum, 200mA from whatever voltage power source that is.
Which is why I'm worried, since my power supply is going to be 9VDC 1A.
Ignore my question about the 10A port. Let me read over measuring ohms and amps before messing with that again.
Quote: |
He
moved the probe to the 10A lead, and set the meter at 10A, and just as
he started to move the two leads to the power outlet, I asked him if
that was such a good idea... Oh, nonsense, these things are built to
handle that current... Bright flash of white light, the smell of smoke,
there went any possibility of measuring current ever again ;_; but
since there was no blown fuse I could still measure voltage with the
thing... |
Ouch x.x
My roommate tried to measure the amps on a non-rechargeable 9VDC fire
alarm battery we bought. Thing heated up extremely quick.
No bright white flash or blown fuse (hopefully), though. Then I tried
hooking up a LED without a resistor and found a cool way to make
smoking LEDs. Ah, but this is how we learn.
Quote: |
Since
the scanline renderer will be the renderer of choice for users because
of its speed and near-identical compatibility, I recommend not treating
these as inherent see-saw bugs of a hackish implimentation, but a
possible bug that can be rectified in the current renderer. |
If we find an hclock position that works for everything, ok.
Otherwise, it would require game-specific hacks, to store the hclock
positions needed for each game. I'll look at Battle Blaze and
Megalomania shortly.
Quote: |
Now
the tricky part is I want to set the "screen resolution" to 1280x1024
and have the remaining 96 lines cropped evenly from the top and bottom
of the screen (48 lines each). As it is now, anything set in the
rendering options that goes beyond the screen res settings get
automattically squeezed down into a messy fit.
Let me know what you think of this. Thanks! |
I did want an inverse clip mode for simulating TV borders anyway... I'll think about it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 17, 2006 8:51 pm Post subject: |
|
byuu wrote: |
If we find an hclock position that works for everything, ok.
Otherwise, it would require game-specific hacks, to store the hclock
positions needed for each game. I'll look at Battle Blaze and
Megalomania shortly.
|
Thanks. But like I said in the report, a 256 hclock resolved all issues
with the four known hclock-sensitive games. If Battle Blaze and Mega lo
Mania are indeed a separate bug as I suspect, and you are able to fix
them, theoretically all issues would be resolved without resorting to
hacks.
|
|
jorgenmz New Member
Joined: 23 Nov 2005
Posts: 6
Location: México
|
Posted: Sun Sep 17, 2006 10:50 pm Post subject: |
|
byuu wrote: |
Thank
you, but I know that. My point was that there is a positive (red)
connector and a negative (black) connector, and I want to measure
voltage. The positive connector clearly states under it "MAX 200mA",
which suggests to me that it can read voltages up to the amount
specified by the click position I set it to, and that it can only
handle, at maximum, 200mA from whatever voltage power source that is.
Which is why I'm worried, since my power supply is going to be 9VDC 1A. |
whicker is right. You shouldn't worry about the "MAX 200mA" stuff, it's
a warning only if you try to measure current (as whicker said, breaking
the circuit and in series).
|
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Mon Sep 18, 2006 2:09 am Post subject: |
|
Hey byuu, why my saves games aren't going into the saves folder? Here is what it is doing.
savesLegend of Zelda, The - A Link to the Past (U).srm
Here what I did.
# Default path for all save RAM and cheat files ("" = use current directory)
# (default = "")
fs.save_path = "saves"
So what I'm doing wrong?
I can't find a snapshot path setup. All I found is this.
# Image format for screenshots
# Valid formats: "bmp", "png", "jpg"
# (default = "png")
misc.image_format = "png"
Everytime that I go into the roms folder and get the snapshots... I get
lagging slowdown on my computer because I have too many roms. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Sep 18, 2006 4:34 am Post subject: |
|
T-Doomdays wrote: |
Hey byuu, why my saves games aren't going into the saves folder? Here is what it is doing.
savesLegend of Zelda, The - A Link to the Past (U).srm
Here what I did.
# Default path for all save RAM and cheat files ("" = use current directory)
# (default = "")
fs.save_path = "saves"
So what I'm doing wrong?
|
It should be rather obvious judging by its behavior.
Entering in "saves" is not valid, since it is being interpreted as a
name parsed as part of the the filename, and not part of a directory.
If you were to do "saves\" I would guess that it would try to store it
in "current BSNES directory\saves\".
Of course, using an absolute path would have made your life easier
though. Something like "C:\some\path\to\save\dir\" would work better.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 18, 2006 7:30 am Post subject: |
|
Quote: |
whicker
is right. You shouldn't worry about the "MAX 200mA" stuff, it's a
warning only if you try to measure current (as whicker said, breaking
the circuit and in series). |
Ah, thank you. Seems like you're really limited as far as measuring
current goes. But that should be ok, as long as I get voltage and
resistance, I should be able to figure out current anyways, at least
approximately.
Hopefully the multimeter/fuse wasn't damaged by testing the current on
the 9V battery (most 9Vs appear to be <200mA anyway).
RE: directory stuff:
I used to automatically append "\", but modified my config loading
system to not allow for overloaded operators on the Setting class type
to simplify it. Never bothered redoing that code. I'll get around to
it. For now, add on your "\" and be careful about where your ROMs are,
"..\" in your paths may not work like you expect in all cases.
Images don't have a path to save them in, they go where the ROM is.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 18, 2006 8:21 am Post subject: |
|
When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it?
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Sep 18, 2006 9:01 am Post subject: |
|
Holy moly your fast FitzRoy. |
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Mon Sep 18, 2006 9:13 am Post subject: |
|
Ok I got the cheats and saves setup the path correcty.
D:\BSNES\Saves\
Deathlike2, thanks point that one out on how to fixs it. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Sep 18, 2006 9:46 am Post subject: |
|
adventure_of_link wrote: |
I'm going to feel sorry for you when soul sees this thread, but voltage != current.
Volts are a measure of force/pressure/etc in a circuit.
Current is a measure of electricity flow, measured in amps.
Watts are a measure of TRUE power.
Volt-Amps are a measure of APPARENT Power.
And Resistance is a measure of the resistance of current flow in a circuit, measures in ohms. |
sorry but what IS true power exactly? and define apparent power.... i wanna know so that it makes sense lol.
_________________
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.
|
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Mon Sep 18, 2006 11:34 am Post subject: |
|
FitzRoy wrote: |
When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it?
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
Do you actually own the cartridges for the roms or are you just a
pirater who goes around bragging about how many roms you have and likes
to get attention from Nintendo
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Sep 18, 2006 11:52 am Post subject: |
|
djohnson wrote: |
FitzRoy wrote: |
When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it?
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
Do you actually own the cartridges for the roms or are you just a
pirater who goes around bragging about how many roms you have and likes
to get attention from Nintendo
|
He seems to be one of those guys who owns a bunch of games, but likes
to have a full dumped SNES set so he can test bsnes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Sep 18, 2006 12:04 pm Post subject: |
|
djohnson wrote: |
FitzRoy wrote: |
When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it?
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
Do you actually own the cartridges for the roms or are you just a
pirater who goes around bragging about how many roms you have and likes
to get attention from Nintendo
|
Do you always read only the last post and then respond?
If you had read better you would know what he's doing
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 18, 2006 1:49 pm Post subject: |
|
Quote: |
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
Awesome, thank you. One more letter... and we'll finally be at the end of Japanese ROM hell x.x
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Sep 18, 2006 3:34 pm Post subject: |
|
byuu wrote: |
Quote: |
whicker
is right. You shouldn't worry about the "MAX 200mA" stuff, it's a
warning only if you try to measure current (as whicker said, breaking
the circuit and in series). |
Ah, thank you. Seems like you're really limited as far as measuring
current goes. But that should be ok, as long as I get voltage and
resistance, I should be able to figure out current anyways, at least
approximately.
Hopefully the multimeter/fuse wasn't damaged by testing the current on
the 9V battery (most 9Vs appear to be <200mA anyway).
RE: directory stuff:
I used to automatically append "\", but modified my config loading
system to not allow for overloaded operators on the Setting class type
to simplify it. Never bothered redoing that code. I'll get around to
it. For now, add on your "\" and be careful about where your ROMs are,
"..\" in your paths may not work like you expect in all cases.
Images don't have a path to save them in, they go where the ROM is.
|
You said you have a 10A port on your multimeter, right? Then, you're
not limited at all. Just use that port when measuring current you
suspect may be above 200mA and it will operate just fine up to 10A!!
That port will also measure current under 200mA, but it will not be as
accurate as the 200mA stage. If you build or have something that
outputs more than 10A of current, you've graduated into a relm of
needing more than a new multimeter.
Not to mention, 10A is like vacuum cleaner current. I don't think
you'll be making any circuits sucking up that much juice without some
sort of motor.
As for voltage, it's already been
pointed out to you that voltage measurement is a SEPARATE measurement.
You can measure voltages as high as your meter scales allow you to go
without damaging the meter.
You can measure the several hundred volts coming off a flyback
transformer in a CRT monitor or TV with a simple multimeter without
issue because the meter is not in series with the circuit and the
current isn't going through it.
Lastly, I'm sure you've heard of Ohm's Law? If you haven't, that's a
fundamental principle anybody tinkering with electronics should learn.
A good excersise would be to draw a little schematic of your simple
circuit and put in the known values. Then see how everything works out
mathmatically. You can then verify it with your meter.
An important concept concerning wall adapters:
The rating on a wall adapter such as 9VDC 1000mA is what the adapter is
capable of putting out under load. Listen to me when I say this. If you
use this adapter for a circuit you build, yours probably will NOT
measure 1000mA of current in your circuit. A circuit only draws as much
current as it needs. It's a common misconception to think that current
levels of devices using a wall adapter are magically using the rated
current on the adapter. That's why many times you can get away with
using a variety of differenly rated adapters to power the same device.
That number is a rated maximum current output at a given voltage for
that power supply. It is NOT how much current will be output at any
given time on any circuit connected to it.
Also be aware that if you use an adapter such as 9VDC 1000mA and you
use that to power a lower current circuit, your supply voltage will
creep up as a result. For example, it can put out 1000mA at 9VDC, but
if you're only using 800mA, you may actually see 10 or 11 VDC as the
actual output.
Simple test, hook up your adapter and use your meter to measure the
voltage coming out of it. You're going to see it will be higher than
the rated voltage because there is no load.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 18, 2006 4:29 pm Post subject: |
|
Quote: |
As
for voltage, it's already been pointed out to you that voltage
measurement is a SEPARATE measurement. You can measure voltages as high
as your meter scales allow you to go without damaging the meter. |
I understand they are separate, and am familiar with Ohm's law. My thinking was this:
I = V / R. So if I have no resistance, and 9V, then I would be putting
out > 200mA of current from the power source. Despite the fact that
I was only measuring voltage, the higher amperage during the
measurement of volts was what I was afraid would cause problems. But
you're saying that current doesn't flow through the multimeter in
voltage reading mode...
Quote: |
You
can measure the several hundred volts coming off a flyback transformer
in a CRT monitor or TV with a simple multimeter without issue because
the meter is not in series with the circuit and the current isn't going
through it. |
Funny, I have a 36" TV with a dying flyback transformer. I can replace
it myself for $40, or pay some scam artist >$200 to do it for me.
I'm thinking the latter is a much smarter move at this point, heh.
Quote: |
Lastly, I'm sure you've heard of Ohm's Law? |
But of course.
Quote: |
Simple
test, hook up your adapter and use your meter to measure the voltage
coming out of it. You're going to see it will be higher than the rated
voltage because there is no load. |
Yes. Tried that, and indeed I wasn't sure why I was getting such a
higher voltage. I plan to feed the cathode directly into this:
http://www.radioshack.com/sm-5v-fixed-voltage-regulator-7805--pi-2062599.html
I have tried this with a 6-cell 9V battery and was able to read output
of 5V, so it apparently seems to work ok and doesn't burn up on me.
I'm not confident enough to try and measure the output current, but
according to what you're saying, the current level does not matter,
individual parts will only use what they need and pass on the rest (I
assume all the way to anode connection where most of it will be
recycled and passed right through cathode again).
So then, question... if there is only one device consuming ~10mA in a
circuit, then you're saying that chip only draws 10mA of current? I
would assume Ohm's law is correct in that I = V/R in all cases, so if
the device had a resistance of 100ohm's, 9V, it would consume 90mA, but
actually receive all ~1A (a little less since you said voltage would be
higher with nil load) of current from the DC adapter, and pass through
~910mA of current out of anode/positive for other devices to use?
In that case, I need a bit of help with resistors.
With my LED, I am putting a 2.2kohm resistor to keep it from catching
fire like my first one did. I've read that you take LED voltage (let's
say 2.1V) and resistance (let's say 20mA). So you want (5V - 2.1V) /
(0.02) = 145 ohm or greater resistor. Now what I'm curious about is why
does this work with 145 or greater ohms resistance, and get the same
average luminance either way? Wouldn't increasing the resistance weaken
the luminance of the LED? Surely a 2.2kohm resistor would be too
resistance to light up the LED at all.
Also, on my breadboard I have to connect the circuit like this for it to work:
(cathode [-]) -> resistor (2.2kohm) -> LED cathode -> LED -> LED anode -> (anode [+])
If I put the resistor on the other end, it no longer works.
And yet, most of the documents I read online say the resistor goes after the led, such that:
(cathode [-]) -> LED cathode -> LED -> LED anode ->
resistor (2.2kohm) -> (anode [+]), which does not power on the LED
for me.
Is this just due to us swapping + and - (thanks to Ben Franklin's
famous mistake)? I assume that energy flows from negative (cathode) to
positive (anode) in my examples, but still notate cathode as negative
and anode as positive.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 18, 2006 5:51 pm Post subject: |
|
tetsuo55 wrote: |
Holy moly your fast FitzRoy. |
Actually, that took up most of my weekend. I was sick, so I was able to
get it done. Plus that, "Q" was only one game. 
And believe me, djohnson, after trudging through every pachinko,
mahjong, and horse-racing simulation on the snes, the last thing I want
to do is brag.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Sep 18, 2006 8:17 pm Post subject: |
|
Had
to wait for a delivery today, so i had some time to get further along
through S, still a lot to go though, only bugs found sofar have to do
with BS.
BS roms are scarily compatible though
almost all of them work, my theorie is that BS only adds some work ram
or something judging from the bugs.... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 18, 2006 8:36 pm Post subject: |
|
RPG
Tsukuru is fixed. Wasn't mapping SRAM to $f0-$ff in LoROM due to logic
bug (have to block them in HiROM games or lots and lots of games go
nuts). |
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Mon Sep 18, 2006 8:47 pm Post subject: |
|
Are
you fixing the Super Nintendo or your moding it to where it can hookup
to your computer so that you can dump the roms through the snes from
the cart?
It would be cool to dump the cart roms
from the snes which you get a better dumping this way rather than
getting a hacking dumping tool to do it. Actually I don't know if it
will work this way or not because I haven't seen it done this way yet. |
|
dragoonmaster New Member
Joined: 31 Aug 2006
Posts: 4
|
Posted: Tue Sep 19, 2006 12:39 am Post subject: |
|
i found another obscure game thats not working:
Bananas de Pijamas (Unl) 
it frezzes @ the gamescreen, the same with zsnes |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 19, 2006 1:28 am Post subject: |
|
byuu wrote: |
RPG
Tsukuru is fixed. Wasn't mapping SRAM to $f0-$ff in LoROM due to logic
bug (have to block them in HiROM games or lots and lots of games go
nuts). |
Sweet. Didn't even add it yet.
dragoonmaster wrote: |
i found another obscure game thats not working:
Bananas de Pijamas (Unl) 
it frezzes @ the gamescreen, the same with zsnes
|
Thanks, but that rom is not in NSRT and this is a GoodTools-free zone.
Not speaking for byuu, but I have to assume that hacks and pirate carts
are not currently going to be looked at when commercial games still
have issues (if ever).
In fact, I've gone ahead and added a notice to my first post with the
hopes that people see it. Without the luxury of a separate forum and
fancy ass announcement stickies on how to file a proper bug report,
it's the best I can do.
|
|
djohnson New Member
Joined: 20 Apr 2006
Posts: 7
|
Posted: Tue Sep 19, 2006 9:34 am Post subject: |
|
tetsuo55 wrote: |
djohnson wrote: |
FitzRoy wrote: |
When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it?
All "O, P, Q, R" (J) games tested. 1 possible problem found:
RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before
gameplay, appears to think there are save games when there aren't. |
Do you actually own the cartridges for the roms or are you just a
pirater who goes around bragging about how many roms you have and likes
to get attention from Nintendo
|
Do you always read only the last post and then respond?
If you had read better you would know what he's doing
|
yes i have read it and i know what he is doing but do you see anyone
else say "I got a folder of over a thousand roms "
NOOOO!!!! to me that is bragging
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 19, 2006 10:01 am Post subject: |
|
This
is not the place to make those kind of bogus inferences. Lots of people
have a thousand or more roms. It gives them the ability the discover
fun games they would have otherwise never known existed, not to mention
try out new translations without having to go hunt something down
first. It's also a matter of convenience for testers such as myself,
and also allows greater circulation and preservation of games.
Plus that, if I were bragging about the number of roms I had, why would I hate GoodSNES so much?  |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Sep 19, 2006 10:56 am Post subject: |
|
Djohnson, you are totally off, just leave this thread.
Flitz is actually a great help for byuu, you are not. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Sep 19, 2006 1:16 pm Post subject: |
|
I'm
going to provide you with a bunch of information to help clear up some
of these concepts here. I'll try to not to give too much for fear
you'll hit that viscious circle where you'll just get a bit more
confused and ask more questions. 
byuu wrote: |
Quote: |
As
for voltage, it's already been pointed out to you that voltage
measurement is a SEPARATE measurement. You can measure voltages as high
as your meter scales allow you to go without damaging the meter. |
I understand they are separate, and am familiar with Ohm's law. My thinking was this:
I = V / R. So if I have no resistance, and 9V, then I would be putting
out > 200mA of current from the power source. Despite the fact that
I was only measuring voltage, the higher amperage during the
measurement of volts was what I was afraid would cause problems. But
you're saying that current doesn't flow through the multimeter in
voltage reading mode...
|
Well technically.. to be 100% correct, current DOES flow through the
multimeter, but it's very little and can be ignored in most
applications.
http://www.ee.duke.edu/~cec/final/node32.html
That's how it actually works. It is in parallel with a portion of the
circuit to measure a voltage drop. The internal resistance of the meter
is high enough to allow very little current to flow through at all, but
it's enough to give you a voltage drop measurement from the meter. When
you have two resistances in paralell, they will share the same voltage
drop(giving you an accurate voltage measurement) however the current
will be split proportionately(NOT evenly) between them. Since the
multimeter resistance value is so high, it has little to no effect on
the circuit and consumes very little current in most applications.
So, you can stick that on a power supply such as your 9VDC 1000mA and
it won't blow up because it will only draw a very small amount of
current from it.
Do some quick math here. Say the internal resistance is 100Meg Ohms(100
million). Generally, this value varies depending on your meter scale
and quality of the meter. Anyway, for arguement sake, let's say it is
100Meg ohms. You've got:
9V/100,000,000 Ohms = .09mA of current. That's so small, it's almost insignificant.
Quote: |
Quote: |
You
can measure the several hundred volts coming off a flyback transformer
in a CRT monitor or TV with a simple multimeter without issue because
the meter is not in series with the circuit and the current isn't going
through it. |
Funny, I have a 36" TV with a dying flyback transformer. I can replace
it myself for $40, or pay some scam artist >$200 to do it for me.
I'm thinking the latter is a much smarter move at this point, heh.
|
Be careful.. You may not have any problems with your meter measuring
the voltage here, but these transformers ARE dangerous to the human
body. If you attempt this, make sure not only that you unplugged your
TV, but that it has been unplugged for several HOURS so it is fully
discharged. no joke man, some of these that are faulty can output over
1000 volts at a current large enough to really hurt you.
Quote: |
Quote: |
Simple
test, hook up your adapter and use your meter to measure the voltage
coming out of it. You're going to see it will be higher than the rated
voltage because there is no load. |
Yes. Tried that, and indeed I wasn't sure why I was getting such a
higher voltage. I plan to feed the cathode directly into this:
http://www.radioshack.com/sm-5v-fixed-voltage-regulator-7805--pi-2062599.html
I have tried this with a 6-cell 9V battery and was able to read output
of 5V, so it apparently seems to work ok and doesn't burn up on me.
I'm not confident enough to try and measure the output current, but
according to what you're saying, the current level does not matter,
individual parts will only use what they need and pass on the rest (I
assume all the way to anode connection where most of it will be
recycled and passed right through cathode again).
|
That's the whole purpose regulators exist. They regulate the voltage to
what you need. Regulators aren't magic of course. The way they turn
9volts into 5 volts is by dropping the necessary voltage within
themselves.
The tradeoff of course is heat. That's why they recommend a heatsink in
some applications where the power disspitation is higher.
You'll only be dropping 4 volts on the regulator. That's probably less
than a 1/4 Watt power dissipation. You should be fine. However, if you
used say the maximum of 35 volts, you'd hav ea 30 volt drop which would
be several watts which would probably burn out the regulator without a
heatsink.
Quote: |
So then, question... if there is only one device consuming ~10mA in a
circuit, then you're saying that chip only draws 10mA of current? I
would assume Ohm's law is correct in that I = V/R in all cases, so if
the device had a resistance of 100ohm's, 9V, it would consume 90mA, but
actually receive all ~1A (a little less since you said voltage would be
higher with nil load) of current from the DC adapter, and pass through
~910mA of current out of anode/positive for other devices to use? |
That's what I'm saying. But listen, your example device here draws
90mA. So.. 90mA is ALL the current that flows through the circuit.
There is no 910 other miliamps. The power supply CAN output 1000mA but
it WON'T unless the circuit can draw that much. Generally this excess
potential is given off as heat(power dissipation) from the power supply
itself. That's why your wall adapters will generally be warm to the
touch even if the device they are plugged into is completely off.
That's another lesson for another day though. Power supplies are a big
subject. Just don't expect to see 1000mA of current in your circuit
just because that's the rated current of the supply. That's all you
need to know. The multimeter is proof of this. It can measure voltage
without burning out. Why? Because it only draws a tiny bit of power
from the big 1000mA supply.
LED's though are a bit different type of bear.. I'll explain those next.
Quote: |
In that case, I need a bit of help with resistors.
With my LED, I am putting a 2.2kohm resistor to keep it from catching
fire like my first one did. I've read that you take LED voltage (let's
say 2.1V) and resistance (let's say 20mA). So you want (5V - 2.1V) /
(0.02) = 145 ohm or greater resistor. Now what I'm curious about is why
does this work with 145 or greater ohms resistance, and get the same
average luminance either way? Wouldn't increasing the resistance weaken
the luminance of the LED? Surely a 2.2kohm resistor would be too
resistance to light up the LED at all.
Also, on my breadboard I have to connect the circuit like this for it to work:
(cathode [-]) -> resistor (2.2kohm) -> LED cathode -> LED -> LED anode -> (anode [+])
If I put the resistor on the other end, it no longer works.
And yet, most of the documents I read online say the resistor goes after the led, such that:
(cathode [-]) -> LED cathode -> LED -> LED anode ->
resistor (2.2kohm) -> (anode [+]), which does not power on the LED
for me.
Is this just due to us swapping + and - (thanks to Ben Franklin's
famous mistake)? I assume that energy flows from negative (cathode) to
positive (anode) in my examples, but still notate cathode as negative
and anode as positive. |
An LED is not a resistor and such is why it's rated in volts. LED's are
basically diodes that give off light instead of heat(technically heat
is light though, it's just not visible to us). What this means is it
will drop it's rated voltage and draw INFINITE current(or until it
burns up). You NEED a resistor to limit the current going through it.
If you just hooked up an LED to your 1000mA supply, just like you
experienced, it will draw the whole damn thing and burn right out.
That's the way LED's work. They will eat as much current as they can having no regard for their own wellbeing. 
When you put that resistor inline, you've now limited how much current
can flow through the LED to a finite number. And of course, the amount
of light it gives off is proportionate to the amount of current. If you
used a larger resistor value, it will start to grow visibly dimmer
until it won't even give off visible light anymore.
So, you've got the right idea. a 2.2K Ohm resistor will probably not
work very well, but you may still see some light. Typically, for our
designs here at work we use 330 Ohms as our typical LED current
limiting resistor. For portable battery powered devices, we use a
higher value sometimes as high as 780 Ohms. This gives good luminance
and limits the current to a nice level. From my experiences, you will
probably still have decent light output up to 800 Ohms or so. I'd say
with 1K, you'll probably notice dimming if not before that depending on
the LED.
An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode.
The resistor should be able to go on EITHER side of the LED so long as
the anode side of the LED is on the anode side of the battery. You can
flip the resistor to either side, but you can't flip the LED or battery.
The resistor can go on either side because it isn't changing anything
in the circuit. The series resistance and current values are still
going to be the same.
I'm not sure why it didn't work for you. Maybe you got something mixed up.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 19, 2006 3:33 pm Post subject: |
|
Quote: |
I'm
going to provide you with a bunch of information to help clear up some
of these concepts here. I'll try to not to give too much for fear
you'll hit that viscious circle where you'll just get a bit more
confused and ask more questions. ;) |
Thanks, I appreciate the help :)
Quote: |
Be
careful.. You may not have any problems with your meter measuring the
voltage here, but these transformers ARE dangerous to the human body. |
Indeed, I've read how lethal the stored charges inside TVs can be, even
whilst power is off. Hence, I probably won't ever attempt to repair it
myself.
Quote: |
When
you put that resistor inline, you've now limited how much current can
flow through the LED to a finite number. And of course, the amount of
light it gives off is proportionate to the amount of current. If you
used a larger resistor value, it will start to grow visibly dimmer
until it won't even give off visible light anymore. |
Odd. If the resistor resists 300ohms, then wouldn't that mean the LED itself would try and consume all available current from the power source minus
300ohms? Hence, a 2.2kohm resistor would take all power minus 2.2kohms,
thus the LED would get less current, thus it would get darker.
Quote: |
So, you've got the right idea. a 2.2K Ohm resistor will probably not work very well, but you may still see some light. |
Actually, it was quite bright, heh. But I didn't compare against 300ohms, so maybe it wasn't near its potential.
Quote: |
An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode. |
Wouldn't current always flow negative to positive?
Quote: |
The
resistor should be able to go on EITHER side of the LED so long as the
anode side of the LED is on the anode side of the battery. You can flip
the resistor to either side, but you can't flip the LED or battery. |
I guess that sort of makes sense. If it were water, and the resistor
were just a smaller tube length, it would slow water before or after it
(eg in the entire tube)... maybe I just connected it wrong.
I need to experiment more, but this is yet another thing I can only
really work on at home, and I think everyone here knows how
limited/stretched my time is there :(
I think what I'm doing wrong now is getting confused between so many
different variables (voltage, current and resistance), multiple
directions (some things being positive to negative, some being negative
to positive, current flowing one way, voltage going another?), and
still not clear on resistors entirely. I'll keep looking online for
better resistor tutorials.
---
EDIT: hmm, I think I understand the resistor thing now...
Say with 9V,1A power supply and 2.1V LED... I can't determine how to
get amperages going through the LED from this (9V-2.1V)/(0R?)... but
let's say with resistors:
(9V-2.1V)/300R = LED gets 23mA of current
(9V-2.1V)/2200R = LED gets ~3mA of current
So, more ohms = less amps. Resistance does take away current, but you
can only have as much current as your LED takes in volts. The resistor
itself doesn't affect the voltage level of your circuit, the voltage
usage is entirely from (Vtotal - Vparts), where in this case Vparts is
just the LED voltage rating, right?
Surprising my LED was so bright with only ~3mA current, though.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Sep 19, 2006 7:25 pm Post subject: |
|
byuu wrote: |
Quote: |
An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode. |
Wouldn't current always flow negative to positive?
|
Yes, but the LED doesn't let anything through if you put it in the
wrong way around (try it with a variable current, it should flicker
(though at the standard 50Hz, you might not notice))
As for current going one way and voltage the other, that's just a
problem of definitions. Back when electricity was first discovered,
they had to lay down some definitions; so they said current flows from
the positive to the negative pole (whatever they're called, I'm bad
with terms). This isn't true, as it turns out, because electrons are
negatively charged, and so are attracted to the positive pole - but
they never bothered to change the definition for the sake of tradition,
and because it's not that much of a problem.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 19, 2006 8:09 pm Post subject: |
|
Quote: |
As
for current going one way and voltage the other, that's just a problem
of definitions. Back when electricity was first discovered, they had to
lay down some definitions; so they said current flows from the positive
to the negative pole (whatever they're called, I'm bad with terms).
This isn't true, as it turns out, because electrons are negatively
charged, and so are attracted to the positive pole - but they never
bothered to change the definition for the sake of tradition, and
because it's not that much of a problem. |
I understand that the definition is backwards. So if current flows from
negative to positive, then why does Nightcrawler state that the current
flows from anode (+) to cathode (-) in LEDs?
Quote: |
An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode. |
If current flows from negative to positive (in reality), then the same should be true for the LED, right?
Sidenote, this is my "LED turn on only in the dark" circuit I'm
presently working on, hopefully it works. I'll try it tonight and see
what happens.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Tue Sep 19, 2006 8:28 pm Post subject: |
|
byuu wrote: |
anode (+) to cathode (-) |
You have that backwards the cathode is + and the anode is -
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 19, 2006 9:08 pm Post subject: |
|
Conventially,
historically, and mostly still presently, anode is referred to as
positive. For the fourth time now I repeat, I am aware this is
backwards, but this is how it's referred to. And I know why it's
backwards and I understand that.
I have read this page completely:
http://www.allaboutcircuits.com/vol_1/chpt_1/7.html
This is causing me nothing but confusion because literally everybody
swaps the definitions of the two based on their preferences and/or lack
of understanding that there are two alternatives, and as a result, I
have no idea what's really going on because nobody bothers to explain
which interpretation they are using for positive/negative or
anode/cathode.
Here is an example image:

So let's get rid of these terms all together and rephrase things.
Basically, in a LED, the current flows through it like this:
(power source, electrons moving right) -> resistor -> LED pin
left -> LED (electrons still moving right, LED works because the LED
also moves electrons from left to right) -> LED pin right ->
(other end of power source, completes a loop)
So... problem solved. Nightcrawler is using Electron Flow Notation. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Sep 19, 2006 9:47 pm Post subject: |
|
ha ha ha. be glad this isn't an AC ciruit.
wiring DIAGRAMs don't care about current direction, just as long as the plus and minus are lined up in the right way
the minus sign is generally to the left and to the top, and the plus is
to the right and to the bottom -and most parts are well labled in that
regard, and
beyond that is of little real issue to the average non-ubergeek which way current flows.
I use the heat ananlog, current flows towards there is none.
tho, IIRC, anode and cathode don't switch places in the notations.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 20, 2006 4:06 am Post subject: |
|
New
WIP should fix: RPG Tsukuru, Circuit USA, Jumbo Ozaki no Hole in One
(not a permanent fix, I'm not entirely happy with the HDMA timing, but
at least the name entry screen works again for now), and Taz-Mania.
The two games you said started flickering since v0.017.07 might be
fixed now, but I'm not worried about these horizontal-line issues
regardless of when they started occurring at the moment. The other ones
you said would be fixed by setting HCLOCK=256 should be fixed as well,
as this is the new default value.
Super Mario Kart's line doesn't appear to flicker now, but I think it's
because I'm technically running the emulation a little too fast again,
due to the Ozaki fix. Another game you shouldn't expect to stay fixed,
and again another game I'm not worried about remaining fixed.
Koushien 2 and Mahjongg Taikai 2 are very likely still broken.
Uniracers definitely is. These appear to be the only three serious
known bugs remaining. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Sep 20, 2006 4:44 am Post subject: |
|
Cool.
I'm having a big problem assigning buttons in this wip, though. Doesn't
seem to recognize my controller or keyboard presses during assignment.
Tried deleting the cfg file - no go. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 20, 2006 6:15 am Post subject: |
|
Well,
my LED circuit doesn't work at all. I can't tell the difference between
my two PNP and NPN transistors, so I tried both. One of them makes the
LED work as if there was no transistor at all (turns on with light,
turns off without light), the other results in the LED always being off.
Even more fun is I can't use the power lines on my breadboard, probably because I don't know how.
I have it like this:
Code: |
<battery-> ---- <2.2kohm resistor> ---- <LED> ---- jumper wire \
<battery+> +++++++++++++++++++++++++++++++++++++++ jumper wire / |
The LED just burns up like this. I know those lines are supposed to
only be used for power, but eg when I use them just for that, nothing
ever works right.
I really hate that there's no way to "debug" this stuff. I don't have
patience for things that either "work or don't work" like this...
Anyway, key assignments... yes. As mentioned previously, I added the
controller port assignment settings to the configuration options panel.
Doing that broke the input configuration panel. I haven't gotten around
to fixing that yet, so key assignment is busted. Edit the config file,
or copy/paste your settings from 0.017.07, or just use the defaults for
now, please.
Last edited by byuu on Wed Sep 20, 2006 6:21 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Sep 20, 2006 6:20 am Post subject: |
|
That works. Thanks. Going to start testing again this weekend, and it'll be nice to control stuff.  |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Wed Sep 20, 2006 8:17 am Post subject: |
|
FitzRoy wrote: |
The
next camp of games with horizontal line issues seem to be caused by a
regression bug that was introduced in .017.04 with either the "Winter
Gold" fix, or the "IRQ" fixes. These games are:
Battle Blaze (J)
Mega lo Mania (J) |
The problem with Mega lo Mania is caused by the Winter Olympics fix.
The game is probably writing to $2101 just before the PPU caches $2101.
Winter Olympics must be writing to $2101 after the caching. To fix both
games, OAM caching must be done at the correct time.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Sep 20, 2006 10:29 am Post subject: |
|
Fitzroy, which games are you gonna test?, im still working on S(ALL regions)
E and U from A to T still need to be done |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Sep 20, 2006 1:09 pm Post subject: |
|
byuu wrote: |
Quote: |
When
you put that resistor inline, you've now limited how much current can
flow through the LED to a finite number. And of course, the amount of
light it gives off is proportionate to the amount of current. If you
used a larger resistor value, it will start to grow visibly dimmer
until it won't even give off visible light anymore. |
Odd. If the resistor resists 300ohms, then wouldn't that mean the LED itself would try and consume all available current from the power source minus
300ohms? Hence, a 2.2kohm resistor would take all power minus 2.2kohms,
thus the LED would get less current, thus it would get darker.
|
I see what your logic is, but it doesn't quite work like that. Think of
it like this. The resistor only allows x current to pass through it
based on it's resistance value. So your (5V-LEDV)/300ohms = xxmA. So..
only xxmA flows through/past that resistor. Therefore, ONLY xxmA can
flow through the LED. Does that make sense to you?
A resistor is acting as water flow control device in a case like this
speaking in terms of water(current). So, even if the resistor is after
the LED, it will still limit the flow to 16mA. The LED doesn't limit
flow at all, therefore the resistor is the only thing to limit it.
So even though you have a supply that can output 1000mA, with the
resistor inline, the LED sees that all it can draw is xxmA and it will
draw just that.
Quote: |
Quote: |
An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode. |
Wouldn't current always flow negative to positive?
|
Life will be easier for you if you disregard the direction electrons
flow. This information is not necessary for schematics or circuit
building really. It's more of a physics thing. Believe me the physics
behind electronics is a whole nother world as well. While you're free
to study the internal structure of a diode or LED, it's not necessary
to use them.
When you design your circuits, keep it simple. + to +, - to -. Don't
worry about which direction electrons actually flow. Therefore, connect
the + side of the battery to the anode + side of the LED.
You're making it more difficult on yourself to bring it down to a
physics level immediately. That's alot to handle. You can learn about
electron holes, junctions, substrates, and doping to learn how these
things work on an electron level, but I'd stay away from that for now.
Quote: |
EDIT: hmm, I think I understand the resistor thing now...
Say with 9V,1A power supply and 2.1V LED... I can't determine how to
get amperages going through the LED from this (9V-2.1V)/(0R?)... but
let's say with resistors:
(9V-2.1V)/300R = LED gets 23mA of current
(9V-2.1V)/2200R = LED gets ~3mA of current
So, more ohms = less amps. Resistance does take away current, but you
can only have as much current as your LED takes in volts. The resistor
itself doesn't affect the voltage level of your circuit, the voltage
usage is entirely from (Vtotal - Vparts), where in this case Vparts is
just the LED voltage rating, right?
Surprising my LED was so bright with only ~3mA current, though. |
Yes. That's pretty much how it works.
I a series circuit with just an LED and resistor, there will be voltage
drop on both parts. You've got your 2.1V drop on the LED and you'll
measure the other 6.9V drop across the resistor.
In a series circuit like that, the voltage will always be divided
amongst the parts which will all add up to the source voltage.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 20, 2006 2:22 pm Post subject: |
|
Quote: |
The
problem with Mega lo Mania is caused by the Winter Olympics fix. The
game is probably writing to $2101 just before the PPU caches $2101.
Winter Olympics must be writing to $2101 after the caching. To fix both
games, OAM caching must be done at the correct time. |
Ah, thank you. Unfortunately, the PPU only runs at HCLOCK=0 and
HCLOCK=n (set by the config file, presently 256). So I can only cache
one line in advance, or not at all. Or in other words, either Winter
Gold is fixed or Mega lo Mania and the other game is fixed :/
So, yet another limitation of the scanline-based PPU. That leaves only
two issues that aren't directly related to the PPU. I guess I'll look
into Mahjongg next then.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Sep 20, 2006 2:31 pm Post subject: |
|
byuu wrote: |
Well, my LED circuit doesn't work at all. I can't tell the difference
between my two PNP and NPN transistors, so I tried both. One of them
makes the LED work as if there was no transistor at all (turns on with
light, turns off without light), the other results in the LED always
being off.
Even more fun is I can't use the power lines on my breadboard, probably because I don't know how.
I have it like this:
Code: |
<battery-> ---- <2.2kohm resistor> ---- <LED> ---- jumper wire \
<battery+> +++++++++++++++++++++++++++++++++++++++ jumper wire / |
The LED just burns up like this. I know those lines are supposed to
only be used for power, but eg when I use them just for that, nothing
ever works right.
I really hate that there's no way to "debug" this stuff. I don't have
patience for things that either "work or don't work" like this...
Anyway, key assignments... yes. As mentioned previously, I added the
controller port assignment settings to the configuration options panel.
Doing that broke the input configuration panel. I haven't gotten around
to fixing that yet, so key assignment is busted. Edit the config file,
or copy/paste your settings from 0.017.07, or just use the defaults for
now, please.
|
First, with your schematic, your design is for an NPN transistor. The
difference between NPN and PNP transistors is the collector is designed
to be at a more positive potential than the emitter on NPN and the
reverse on PNP. You'll see what this means in a minute.
Second. The way you laid out your circuit, the transistor turns ON when
light is present. I would expect the LED to turn ON when there is light
and off when there is not. That is what you are experiencing with one
of the transistors, right?
That's what I would expect to see happen. Think about it. The
transistor turns on with current at the base. Your LDR conducts when
light is present, therefore the transistor turns ON when light is
present thus lighting your LED.
You want an opposite effect. you want the LED to turn on in the dark.
Therefore, you need the transistor to turn on when the LDR is NOT
conducting.
To do this, you can use a PNP transistor. HOWEVER, you must connect it like this..

I don't have a scanner, so this is ripped from another site. Your Load
will be the LED and resistor. The Rb will be your LDR and resistor.
Ignore chip output.
With this setup, the transistor is ON when there is NO current to the
base and is OFF when current is there. This will make the transistor
OFF in the light and ON in the dark when the LDR is not conducting thus
turning on your LED.
You can 'debug' this stuff. That's what math and your multimeter are
for. You can calculate on paper what the current and voltage will be
for every part of your circuit. When your meter observation does not
match the math, you'll know where the problem is, or at least where to
start.
However, to effectively do this, you need a good understanding of what
SHOULD be going on to begin with which takes some time to build that
knowledge up.
It's really the same as programming. You have a debugger, but the
debugger is useless to you unless you KNOW how to use the debugger and
what you should expect to see.
_________________
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.
|
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Sep 20, 2006 4:54 pm Post subject: |
|
Now
I understand the confusion. The cathode is the positive terminal of a
voltaic cell, but the negative terminal of an electrolytic cell. I
guess I can blame my physics and chemistry teachers for not explaining
this better . |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 20, 2006 5:51 pm Post subject: |
|
Quote: |
First, with your schematic, your design is for an NPN transistor. |
My design used a PNP transistor, as the arrow was pointing at the base.
But if you mean it was an for an NPN transistor due to the placement of
my LED, then I guess I don't understand how to arrange these components
correctly yet...
With my circuit, my idea was that power would go through the LED, to
the PNP collector. Then, the LDR would go to the base. If the LDR was
illuminated, it would have a signal, and the signal would block current
flow to the emitter. Otherwise, it would have no current flowing
through it, and the collector would allow current to flow to the
emitter.
Apparently, this is not the case, heh.
Quote: |
Second.
The way you laid out your circuit, the transistor turns ON when light
is present. I would expect the LED to turn ON when there is light and
off when there is not. That is what you are experiencing with one of
the transistors, right? |
Yep. Be nice if I could tell the NPN and PNP transistors apart, heh.
Damn package I bought has both stuck next to each other unlabeled. I'll
have to go by Radio Shack and get some more in labeled packages.
Quote: |
That's
what I would expect to see happen. Think about it. The transistor turns
on with current at the base. Your LDR conducts when light is present,
therefore the transistor turns ON when light is present thus lighting
your LED. |
With an NPN transistor, yes. But my diagram showed a PNP transistor,
which is supposed to turn OFF when there is current at the base x.x
With current off between collector and emitter, it should break the
circuit and turn off the LED. But I'll try with your diagram tonight I
suppose, and put the LED after the emitter instead...

This look ok? Energy should flow from +5V to resistor where it's capped
to a safe value for both the LDR (though the LDR may not need one) and
the LED. The +5V line splits, one going to the PNP collector, one going
to the LDR, the LDR then connecting to the PNP base. The PNP emitter
will forward +5V to the LED only when the LDR resistance is low (eg the
room is dark), the LED forwards current to ground, forming a circuit
loop.
Result should be that the circuit only completes when the room is dark,
and thus the LED only lights up in the dark.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Sep 20, 2006 6:20 pm Post subject: |
|
I
was going to suggest using a relay, but try not attaching the wire from
the LDR back before the transitor, but to the wire that leads back to
the battery from ground.
Im thinking you don't
need to worry about ground anyways for these type of simple ciruits, it
might causing some issues in and of itself.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
JonasP New Member
Joined: 20 Sep 2006
Posts: 2
|
Posted: Wed Sep 20, 2006 7:31 pm Post subject: |
|
Just
a thought... Are there any software available which simulates
electronic conponents? Then you could "wire" your circuit with the
software by simply picking the components and filling in voltage and
resistance values and so on, and debug it on your PC. Would save a lot
of time and effort I think... |
|
zoink Lurker
Joined: 25 Apr 2005
Posts: 110
|
Posted: Wed Sep 20, 2006 8:00 pm Post subject: |
|
JonasP wrote: |
Just
a thought... Are there any software available which simulates
electronic conponents? Then you could "wire" your circuit with the
software by simply picking the components and filling in voltage and
resistance values and so on, and debug it on your PC. Would save a lot
of time and effort I think... |
electronic workbench or smth like that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 20, 2006 9:33 pm Post subject: |
|
Code: |
[Mahjongg Taikai II]
808050 REP #$30 A:FF00 X:00FF Y:0008 S:01F9 DB:01 D:0000 P:36 e
808052 PHA A:FF00 X:00FF Y:0008 S:01F9 DB:01 D:0000 P:06 e
808053 PHX A:FF00 X:00FF Y:0008 S:01F7 DB:01 D:0000 P:06 e
808054 PHY A:FF00 X:00FF Y:0008 S:01F5 DB:01 D:0000 P:06 e
808055 PHB A:FF00 X:00FF Y:0008 S:01F3 DB:01 D:0000 P:06 e
808056 PHD A:FF00 X:00FF Y:0008 S:01F2 DB:01 D:0000 P:06 e
808057 LDA #$0000 A:FF00 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:06 e
80805A TCD A:0000 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:06 e
80805B SEP #$30 A:0000 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:06 e
80805D LDA #$01 A:0000 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:36 e
80805F PHA A:0001 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:34 e
808060 PLB A:0001 X:00FF Y:0008 S:01EF DB:01 D:0000 P:34 e
808061 LDA $4210 [014210] A:0001 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:34 e
808064 LDA $4E [00004E] A:0081 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:B4 e
808066 BIT $4D [00004D] A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:34 e
808068 BVS $8073 [808073] A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:36 e
80806A BPL $807C [80807C] A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:36 e
80807C STA $2100 [012100] A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:36 e
80807F REP #$10 A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:36 e
808081 LDA #$01 A:000F X:00FF Y:0008 S:01F0 DB:01 D:0000 P:26 e
808083 TRB $4B [00004B] A:0001 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:24 e
808085 BEQ $8096 [808096] A:0001 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:24 e
808087 LDX #$043B A:0001 X:00FF Y:0008 S:01F0 DB:01 D:0000 P:24 e
80808A STX $4302 [014302] A:0001 X:043B Y:0008 S:01F0 DB:01 D:0000 P:24 e
80808D LDX #$0220 A:0001 X:043B Y:0008 S:01F0 DB:01 D:0000 P:24 e
808090 STX $4305 [014305] A:0001 X:0220 Y:0008 S:01F0 DB:01 D:0000 P:24 e
808093 STA $420B [01420B] A:0001 X:0220 Y:0008 S:01F0 DB:01 D:0000 P:24 e
$2102 = #$0000 <not set during NMI>
$4300 = #$00 <not set during NMI>
$4301 = #$04 <not set during NMI>
$4302 = #$043b
$4305 = #$0220
* DMA[0]: dmap=00 srcaddr=00043b destaddr=04 xfersize=0220 oamaddr=0000
* OAM 0040 @ 008097 <225,1344>
---
* 004b = 01 @ 00845e <201,1114>
* 004b = 00 @ 008085 <225, 632>
* DMA[0]: 00 00043b<>04 0220 0000 008097 <225, 824>
* OAM 0040 @ 008097 <225,1344>
* 004b = 00 @ 00809a <228,1256>
* 004b = 00 @ 0080e6 <229, 144>
* DMA[3]: 01 7f0000<>18 0800 0220 00832c < 21, 692>
* DMA[3]: 01 7f0000<>18 0800 0220 00832c <110, 992>
* 004b = 00 @ 008248 <123, 356>
* 004b = 02 @ 008251 <125, 0>
* 004b = 00 @ 008248 <125, 208>
* 004b = 02 @ 008251 <126,1216>
* 004b = 83 @ 0081a0 <128, 112>
* 004b = 82 @ 008085 <225, 630>
* DMA[0]: 00 00043b<>04 0220 0220
---
[ZSNES]
00845a 67,????
00819c 199,???? +~132 lines
008087 225,????
[Super Sleuth]
00845a 236,????
00819c 158,???? +~184 lines
008087 225,????
[bsnes]
00845a 201,1114
008087 225, 824
00819c 128, 112 +~189 lines |
Basically, the game's NMI routine checks $4b bit 0 to determine if it
should transfer 544 bytes of WRAM data to OAM, and then clears $4b.
However, the game does not bother to set the OAM write address.
The game sets $4b bit 0 twice, however, even though the transfer only
needs to happen once. Bad programming from a Japanese game company?
Whhhhhhhhhhhhhhhhaaaaaaaaaaaaaa????
In ZSNES, the first write to $4b happens really early in the frame,
then the second write occurs a bit later on the frame, both before any
NMIs trigger. Then NMI gets called, and the game transfers WRAM data
into OAM as described above.
In Super Sleuth, the first write to $4b happens just after NMI, and the
second write before NMI on the next frame. Result: only one DMA to OAM
is performed.
In bsnes, however, the first write happens shortly before NMI. This
causes the NMI routine to perform the DMA to OAM. Then, during the next
frame, the game sets $4b again. So at the next NMI, another DMA to OAM
is performed. This time though, things don't go so well. Since OAM addr
was never reset, it transfers the same data again, starting at OAM addr
= #$0220. 544 bytes transferred twice ends up corrupting the OAM high
attribute table, and the first 64 bytes of the OAM low table.
The problem is basically timing related. I really don't have any
fucking clue how I can get absolutely perfect clock latch positions in
bsnes after running tens of thousands of NMIs, IRQs, DMA transfers,
HDMA transfers, and executing nearly every opcode that the SNES CPU
supports, and yet be off by so much timing-wise. So, I can't fix this
bug; because I have no idea where the hell the problem is. I have to be
off, at minimum, by at least 32,736 clock cycles after only ~18 frames or so, which is absolutely insane.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 21, 2006 3:14 am Post subject: |
|
Sounds like Uniracers has company. Unfortunately, there aren't any other bugs left to pray for collateral damage.
byuu wrote: |
Moved the scanline render position to hclock=256, at the request of
FitzRoy. Supposedly it is more compatible than hclock=192. Goodbye,
Anthrox doesn't like this, but I don't really care about PD ROMs right
now.
|
Hmmm, I wasn't aware of this. Normally, I would be the first one to
discount a non-commercial cart, but this time I think it reveals a
better conclusion. Even though it's a PD rom, I don't think the cause
is bad coding. I think this is another genuine hclock issue from a rom
that simply renders something later than all the others. In other
words, no commercial game may exist to display an error at this
setting, but is nonetheless possible. 192 may not have flickered, but
there was still a stagnant line error right below the checkboard area.
A setting of of 384 reduces the flickering seen in 256, and a setting
of 512 aligns the data correctly so that there is no line issue. It
also continues to work for all other games. Noticing a trend here? A
higher setting is always proving better. My suggestion now is to set
the default to 1096 and be done with it. All known games relating to
this issue continue to be flawless at 1096, and since it is the highest
setting, it would probably eliminate any possible further issue.
Last edited by FitzRoy on Thu Sep 21, 2006 3:17 am; edited 2 times in total
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu Sep 21, 2006 3:15 am Post subject: |
|
zoink wrote: |
JonasP wrote: |
Just
a thought... Are there any software available which simulates
electronic conponents? Then you could "wire" your circuit with the
software by simply picking the components and filling in voltage and
resistance values and so on, and debug it on your PC. Would save a lot
of time and effort I think... |
electronic workbench or smth like that.
|
Yes, that would be it. I used to use this back in my IMT class, around the middle of the year.
However I think it's only winders 98se.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
T-Doomdays Rookie

Joined: 29 Aug 2006
Posts: 25
|
Posted: Thu Sep 21, 2006 4:04 am Post subject: |
|
Nevermind. Sorry guys.
Last edited by T-Doomdays on Thu Sep 21, 2006 10:25 am; edited 2 times in total |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Sep 21, 2006 6:03 am Post subject: |
|
electronic workbench (if its what i think it is) works fine under windows 2000 cause my school had it.
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 21, 2006 6:58 am Post subject: |
|
Quote: |
A
setting of of 384 reduces the flickering seen in 256, and a setting of
512 aligns the data correctly so that there is no line issue. It also
continues to work for all other games. Noticing a trend here? A higher
setting is always proving better. My suggestion now is to set the
default to 1096 and be done with it. All known games relating to this
issue continue to be flawless at 1096, and since it is the highest
setting, it would probably eliminate any possible further issue. |
The only problem with this is that the line between the mode7 and mode0 backgrounds is supposed to be there on real hardware, and it doesn't flicker.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 21, 2006 7:28 am Post subject: |
|
So you're saying the blue scrambled stuff on the left side is supposed to be there, or just a solid black line? |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Sep 21, 2006 8:08 am Post subject: |
|
T-Doomdays wrote: |
If you haven't thought of this. |
Please stop while you're ahead on this.
_________________
FF4 research never ends for me.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Sep 21, 2006 12:41 pm Post subject: |
|
byuu wrote: |
Quote: |
First, with your schematic, your design is for an NPN transistor. |
My design used a PNP transistor, as the arrow was pointing at the base.
But if you mean it was an for an NPN transistor due to the placement of
my LED, then I guess I don't understand how to arrange these components
correctly yet...
|
Your arrow went to the base from the collector. That's wrong for EITHER
transistor. I just made an assumption based on your collector emitter
labeling. Take a look at this:
http://en.wikipedia.org/wiki/Bipolar_junction_transistor
Look at the section for NPN and PNP. You can see the schematic symbol
for both. The arrow is always at the emitter.
The EMITTER on an NPN setup goes to ground. The COLLECTOR on PNP goes
to ground. (technically it's negative potential rather than ground, but
for your purposes it's ground)
That's the difference between the two. They are reverse polarity and
current at the base has a reverse effect as far as swtiching On and Off.
Quote: |
With my circuit, my idea was that power would go through the LED, to
the PNP collector. Then, the LDR would go to the base. If the LDR was
illuminated, it would have a signal, and the signal would block current
flow to the emitter. Otherwise, it would have no current flowing
through it, and the collector would allow current to flow to the
emitter.
Apparently, this is not the case, heh. |
Ok. Well you have the right idea then. It is just laid out wrong. Now
that I have a better understanding of what you did wrong and what's
going on. Let's scratch your latest drawing and look at your original
schematic.. You almost had it right.
http://i73.photobucket.com/albums/i221/byuusan/ldr.png
The ONLY thing you need to do now is flip your collector and emitter.
For a PNP setup, the LED/1K branch should flow *INTO* the EMITTER and
*OUT* the COLLECTOR to Ground. Your arrow in the schematic should be
INTO the base FROM the EMITTER.
Quote: |
Yep.
Be nice if I could tell the NPN and PNP transistors apart, heh. Damn
package I bought has both stuck next to each other unlabeled. I'll have
to go by Radio Shack and get some more in labeled packages. |
Give me the part numbers on your transistors. I will lookup the
datasheets for them and tell you which is NPN or PNP. If you plan on
advancing in electronics, the data sheets for parts are important. You
don't need to understand everything on them, but it will provide some
useful information such as it's pinout, maximum ratings, and if it's
NPN or PNP! 
I wish I had a scanner so I could draw some things to help you out.
Hopefully you understand what you need to do now. Just flip your E and
C sides on the transistor only. The rest of the original schematic is
fine.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 21, 2006 3:44 pm Post subject: |
|
Still can't get it to work...

This is my third attempt. The holes are for my breadboard. I don't use
the power lines because they don't seem to work right (that or I'm
screwing it up, probably the latter). The gray lines represent the long
columns that are connected behind-the-scenes on the breadboard.
Now, as for the transistor... I don't know if it should be { Tc, Tb, Te
} or { Te, Tb, Tc }. I've tried with both PNP and NPN transistors in
both orientations (basically, I flipped them around since I have no
clue which side is the collector and which is the emitter).
With the PNP, in one orientation the LED is always on. In the other,
the LED is only on with light, and off with darkness. With the NPN
transistor, the light never comes on regardless of which direction I
insert the transistor. Ideas? |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Sep 21, 2006 4:19 pm Post subject: |
|
I should crack out my 1000-in-1 electronics kit.
I need wires for it tho.
you can't use an NPN for this anyways, if I am reading that article right.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 21, 2006 4:34 pm Post subject: |
|
Back on the subject of the SNES for a brief moment...
I tested hardware interrupts (NMIs, specifically, but IRQs will be the
same). Ran four tests, with both FastROM enabled and disabled, and with
the non-interrupt code executing in $008xxx and $808xxx. All four
times, the NMI fired at $00xxxx (where your NMI interrupt was set to).
I tested this because I noticed ZSNES starts its NMIs in FastROM ($80xxxx) for whatever reason.
So, bsnes didn't have any problems there, works as I expected.
Next, I tested auto joypad polling. I knew it didn't consume any CPU
timing (it runs in the background), but I'm kind of desperate.
Something has to be throwing my time way the hell off, and I don't know
what. Seeked to V=0,HC=0, turned on auto joypad polling, ran for 128
frames and then latched the counters. Identical latch positions in
bsnes as on my UFO.
So, auto joypad polling definitely isn't consuming any CPU time.
So then... I have the following timing elements emulated:
- DRAM refresh (perfect)
- NMI timing (perfect)
- DMA timing (perfect)
- IRQ timing (near-perfect, withing ~12 clocks of being correct each IRQ)
- HDMA timing (near-perfect, within ~6 clocks of being correct each HDMA)
- opcode timing (perfect, excluding maybe emulation mode)
- long dot timing, short line timing, and basically all frame timing (perfect)
- CPU/APU synchronization (~99.8% perfect, syncs between bus hold delay
timing, impossible to get more accurate in emulation, as the difference
is due to hardware not running at stock speeds)
And yet, I'm still off by tens of thousands of clocks in Mahjongg,
assuming the game works on real hardware. My last floppy disk died on
me as I was trying to load the game on my UFO to see, though I'm sure
it wouldn't have been released if the first damn screen didn't work
right on the real thing.
I don't know what else to look at. My last resort is going to be to
hack the Mahjongg ROM and latch counters and kill the game at varying
points and compare the counter latch positions against emulation,
hopefully tracing back to the point where things go straight to hell. I
seriously doubt I'll have any luck.
---
Here's my next idea for the "glow in the dark LED circuit":
Code: |
(0v)----(Tc Tb Te)----(LED)----(2.2kR)---(+9v)
|
|
(LDR)
|
|
(100kR?)
|
|
(+9v) |
T is PNP, of course. The thing that's bothering me at the moment is the
LDR<>Tb connection. If Tb activates Tc<>Te passthru based
on voltage levels, then what good is using a resistor that only affects
amperage levels? And why even use a standard resistor before the LDR in
this case if resistors don't affect voltage?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 22, 2006 12:14 am Post subject: |
|
New
information regarding hclock behavior. Apparently some games break when
hclock is too high, just like some games break when hclock is too low.
Found this out while testing with 1096. T2 - The Arcade Game breaks
after 1054 (and there are probably many other games breaking even
lower). So here's what we know so far:
T2 - The Arcade Game - 0-1054 works, 1055-1096 breaks
Prince of Persia 2 - 0-182 breaks, 183-1096 works
Goodbye, Anthrox - 0-398 breaks, 399-1096 works
Might and Magic II - 0-216 breaks, 217-1096 works
Taz-Mania - 0-140 breaks, 141-1096 works
Knowing all this, I have to think somewhere in the middle is ideal.
Like 548. I'll start testing this weekend at this number and see what
happens. Still, I am in full support of PPU based rendering at this
point. I just hope it isn't any more than a 30% speed hit. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 22, 2006 5:31 am Post subject: |
|
Quote: |
Goodbye, Anthrox - 0-398 breaks, 399-1096 works |
Once again, that "garbled" line is supposed to be there x.x
Also, I do apologize for this, I just noticed you're testing each value
rather than ever two... the CPU can only step in two-clock-tick steps
minimum, so testing eg 256 and 257 yields the exact same results. Also,
because I test the clock position to draw the line between CPU cycles
rather than after every clock tick (because it's faster), the actual
position the line is rendered can vary between n and n+12 (or n+52 if
DRAM refresh occurs, but this is irrelevant since nothing from the CPU
can affect the PPU during this time anyway).
---
I fixed the input configuration panel. Also switched to Comic Sans MS
font for it, so the options are a little bigger. I wanted something
that was more widely spaced vertically to separate the entries
better... I'll probably have to replace the listbox control with a
custom one if I want to make it look really nice, though.
Also disabled the hwmath counter updating for now since I've blocked
the hwmath behavior until I can find something safer that doesn't break
any games.
What's your opinion about Battle Blaze and Mega lo Mania? Should I
leave these two broken, or revert the Winter Olympics change to get
these two working again? Can't have both for now, sadly. The only spot
I can cache OBSEL is where you set hclock to in the config file, so
it's either cached a line in advance, or not at all.
Also, I have an idea for the user interface... I was thinking of taking
away the menubar and replacing it with a pseudo-toolbar instead... what
do you think?
It would have say, 32x32 or so icons (I could even make a "small icons" version). The default buttons would be:
Load, Reset, Configuration, About
And I would move the rest of the menubar options into the configuration
panel. I could also add a toolbar editor to the configuration panel to
add and remove additional icons, such as:
Unload, Power (hard reset), Mute sound, Capture screenshot, etc
The basic goal would be to make bsnes "stand out" a bit more than a
plain old boring win32 app, and make commonly accessed features easier
to get to.
I don't, however, feel like adding this as well as the menubar. It's one or the other.
And of course, a nicer file load menu has been on the agenda for a long
time now, too. I will allow one to use the default windows file open
dialog as a replacement there, though.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 22, 2006 7:18 am Post subject: |
|
I
guess I'm having a difficult time believing that someone spent all that
time making a homebrew and didn't notice a major gfx anomoly like that.
I'll just have to be convinced when I get my flash cart and its staring
me in the face.
As for changing the menu and
stuff. I'm not for it. I use a lot of emulators and it's nice to have
fairly uniform menu bar implimentations across the board. Navigation
doesn't need to be pretty or stand out from other emus. I just want
simple, well-organized text-based menus, and that's exactly what you've
got right now. In fact, bsnes navigation and configuration as a whole
is a shining example at this point.
Icons in menus look goofy because some options have them and some
don't. What would look okay is putting one next to each entry in the
cfg white area. SNESGT is a good example of this done right. They use
pro looking icons that come stock with windows. Video settings =
monitor icon. Color adjustment = monitor icon with the painter's tool.
Etc. You'd have to revert back to arial to do this, but I think you
should do that anyway... not digging that new font.
Battle Blaze and Mega lo Mania can stay broken. That line caching stuff
is accurate hardware behavior. The inferior scanline renderer shouldn't
compromise its addition. Would it not be logical to use
scanline-renderer specific hacks for these games, knowing that there is
no possible way to overcome them with a renderer that is a speedhack in
itself?
By the way. I found another bug today.
Touge Densetsu Saisoku Battle (J) - at bike selection screen, choose an
option. The game's colors will mess up. happens in all bsnes versions.
happens in super sleuth. Doesn't happen in zsnes. |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Fri Sep 22, 2006 8:23 am Post subject: |
|
byuu wrote: |
Quote: |
The
problem with Mega lo Mania is caused by the Winter Olympics fix. The
game is probably writing to $2101 just before the PPU caches $2101.
Winter Olympics must be writing to $2101 after the caching. To fix both
games, OAM caching must be done at the correct time. |
Ah, thank you. Unfortunately, the PPU only runs at HCLOCK=0 and
HCLOCK=n (set by the config file, presently 256). So I can only cache
one line in advance, or not at all. Or in other words, either Winter
Gold is fixed or Mega lo Mania and the other game is fixed :/
|
Battle Blaze does not do any mid-frame writes to $2101, so the problem
must be caused by the other IRQ timing updates.
Assuming that my HDMA timing is correct, Mega lo Mania writes to $2101
at <0, ~1140> and <128, ~1140> while Winter Olympics writes
at <127, ~1260-1280> and <225, ~476-500>. In Anomie's
timing.txt it says that the PPU uses 256+16+68=340 vram reads per line.
My guess is that cycles 72-1096 and 1096-1160 are used for BG reads and
RTO calculation, while 1160-72 are used for OAM reads. So in order to
fix all games, OAM caching should be done at <V, 1160> and
rendering should be done at <V+1, dram_refresh_pos>.
Quote: |
Next,
I tested auto joypad polling. I knew it didn't consume any CPU timing
(it runs in the background), but I'm kind of desperate. Something has
to be throwing my time way the hell off, and I don't know what. Seeked
to V=0,HC=0, turned on auto joypad polling, ran for 128 frames and then
latched the counters. Identical latch positions in bsnes as on my UFO.
So, auto joypad polling definitely isn't consuming any CPU time. |
The timing of the polling does have an effect on Mahjongg Taikai II,
although nowhere near enough to fix the game. According to the SNES dev
manual, polling starts at 18us (48 machine cycles @ 2.68MHz) after
vblank and ends 214.55us (576 m.c. @ 2.68MHz) after vblank. This means
that joypad reading starts at cycle 48 * 8 = 384 and ends (576 - 48) *
8 = 4224 cycles later, which seems to match Anomie's tests. The manual
then states that "Standard CNTRL Enable" (which is $4200 bit 0) cannot
be set during joypad reading. Also from the wording it looks like
"machine cycle" is the same as "cpu cycle" and not "8 master cycles".
Quote: |
DRAM refresh (perfect) |
When does this occur? In older versions of bsnes, it is at 534/538. In
newer versions it is at 538 for bcpu and 530 for scpu.
Quote: |
NMI timing (perfect) |
Is it possible to trigger 2 NMIs like this?
Code: |
lda #$80
sta $4200
; wait for a while
stz $4200 ; NMI triggers at last cycle +2 or +4,
; after the test but before the write
sta $4200 ; write occurs after last cycle test
; first NMI triggers now, and another last cycle test is done
; second NMI will trigger if the first does not clear
; the NMI transition signal
|
And finally, is $213E bit 4 PPU1 open bus or is it always zero?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 22, 2006 2:39 pm Post subject: |
|
Quote: |
Battle Blaze does not do any mid-frame writes to $2101, so the problem must be caused by the other IRQ timing updates. |
Eh, oh well. I'm seriously burning out spending 6+ hours on each of
these obscure Japanese games to fix tiny little graphical glitches.
It'll have to stay broken.
Quote: |
The
timing of the polling does have an effect on Mahjongg Taikai II,
although nowhere near enough to fix the game. According to the SNES dev
manual, polling starts at 18us (48 machine cycles @ 2.68MHz) after
vblank and ends 214.55us (576 m.c. @ 2.68MHz) after vblank. This means
that joypad reading starts at cycle 48 * 8 = 384 and ends (576 - 48) *
8 = 4224 cycles later, which seems to match Anomie's tests. The manual
then states that "Standard CNTRL Enable" (which is $4200 bit 0) cannot
be set during joypad reading. Also from the wording it looks like
"machine cycle" is the same as "cpu cycle" and not "8 master cycles". |
$4200.d0 is auto joypad read enable. I'm aware there's probably a
hundred thousand anomalies involved with toggling $4200.d0 at odd
times, reading the joypads during auto joypad polling, with toggling
overscan around V=225-240, with the start and end positions of auto
joypad polling changing every frame based on the weather in Guatemala,
etc etc.
I guess I could set the status flag for auto joypad reading to be a
little more accurate than just "during scanlines 225-227".
I think investigating CPU opcode timing is the next best bet for
Mahjongg, maybe there's some big transfer loop that has one of its
opcodes timed wrong (missing/extra opcode cycle?).
Quote: |
When does this occur? In older versions of bsnes, it is at 534/538. In newer versions it is at 538 for bcpu and 530 for scpu. |
On CPU revision 1, it always happens at 530. On CPU revision 2, it
changes every scanline between 534 and 538, except for the scanline
with the missing dot, it doesn't change there. Basically, CPUr2 has
something like a separate timer that ticks every 8 clocks. The newer
bCPU is probably more than a little broken at this point.
Quote: |
Is it possible to trigger 2 NMIs like this? |
Wouldn't know off the top of my head, and unfortunately I'm out of floppies to test with at the moment.
Quote: |
And finally, is $213E bit 4 PPU1 open bus or is it always zero? |
That's probably the bit that gets set when PPU1 registers aren't read
for 40 frames or something like that. I haven't looked into it.
By the way, I don't suppose you've looked at Koushien 2, by chance? It
looks like the S-SMP is what's crashing (bad opcode?), but I really
don't want try and investigate a bug that occurs so far in game without
savestates. Hmm, maybe I'll generate a running SMP log that strips out
all the register info from each line, that way the log from game start
to crash is only 20gb instead of 60gb.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 22, 2006 4:38 pm Post subject: |
|
Koushien 2 S-SMP log:
Code: |
..0f17 mov $000,a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZC
..0f19 mov a,x A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZC
..0f1a mov $012,a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZC
..0f1c asl a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZC
..0f1d asl a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZc
..0f1e asl a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZc
..0f1f adc a,$012 A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZc
..0f21 mov $012,a A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZc
..0f23 mov a,$047f+x A:00 X:00 Y:c0 SP:01f7 YA:c000 nvpbhiZc
..0f26 mov $002,a A:86 X:00 Y:c0 SP:01f7 YA:c086 Nvpbhizc
..0f28 mov a,$0487+x A:86 X:00 Y:c0 SP:01f7 YA:c086 Nvpbhizc
..0f2b mov $003,a A:c2 X:00 Y:c0 SP:01f7 YA:c0c2 Nvpbhizc
..0f2d mov y,#$00 A:c2 X:00 Y:c0 SP:01f7 YA:c0c2 Nvpbhizc
..0f2f mov a,y A:c2 X:00 Y:00 SP:01f7 YA:00c2 nvpbhiZc
..0f30 mov y,#$00 A:00 X:00 Y:00 SP:01f7 YA:0000 nvpbhiZc
..0f32 addw ya,$002 A:00 X:00 Y:00 SP:01f7 YA:0000 nvpbhiZc
..0f34 movw $002,ya A:86 X:00 Y:c2 SP:01f7 YA:c286 Nvpbhizc
..0f36 mov y,#$00 A:86 X:00 Y:c2 SP:01f7 YA:c286 Nvpbhizc
..0f38 push x A:86 X:00 Y:00 SP:01f7 YA:0086 nvpbhiZc
..0f39 mov a,($002)+y A:86 X:00 Y:00 SP:01f6 YA:0086 nvpbhiZc
..0f3b inc y A:8e X:00 Y:00 SP:01f6 YA:008e Nvpbhizc
..0f3c and a,#$7f A:8e X:00 Y:01 SP:01f6 YA:018e nvpbhizc
..0f3e asl a A:0e X:00 Y:01 SP:01f6 YA:010e nvpbhizc
..0f3f mov x,a A:1c X:00 Y:01 SP:01f6 YA:011c nvpbhizc
..0f40 jmp ($0f43+x) A:1c X:1c Y:01 SP:01f6 YA:011c nvpbhizc
..143e pop x A:1c X:1c Y:01 SP:01f6 YA:011c nvpbhizc
..143f mov a,$fffc+x A:1c X:00 Y:01 SP:01f7 YA:011c nvpbhizc
..1442 tcall 0 A:00 X:00 Y:01 SP:01f7 YA:0100 nvpbhiZc
..0000 nop A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc
..0001 nop A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc
..0002 adc a,(x) A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc
..0003 set6 $07e A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc
..0005 clrp A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc
..0006 stop A:00 X:00 Y:01 SP:01f5 YA:0100 nvpbhiZc |
IPLROM is disabled ($00f1 = #$03) at this point.
spcdas disassembly from SPCRAM dump from ZSNES:
Code: |
0f19: 7d mov a,x
0f1a: c4 12 mov $12,a
0f1c: 1c asl a
0f1d: 1c asl a
0f1e: 1c asl a
0f1f: 84 12 adc a,$12
0f21: c4 12 mov $12,a
0f23: f5 7f 04 mov a,$047f+x
0f26: c4 02 mov $02,a
0f28: f5 87 04 mov a,$0487+x
0f2b: c4 03 mov $03,a
0f2d: 8d 00 mov y,#$00
0f2f: dd mov a,y
0f30: 8d 00 mov y,#$00
0f32: 7a 02 addw ya,$02
0f34: da 02 movw $02,ya
0f36: 8d 00 mov y,#$00
0f38: 4d push x
0f39: f7 02 mov a,($02)+y
0f3b: fc inc y
0f3c: 28 7f and a,#$7f
0f3e: 1c asl a
0f3f: 5d mov x,a
0f40: 1f 43 0f jmp ($0f43+x)
143e: ce pop x
143f: f5 b7 20 mov a,$20b7+x
1442: 04 32 or a,$32
1444: c4 32 mov $32,a
1446: 7d mov a,x
1447: 9f xcn a
1448: 08 05 or a,#$05
144a: c4 f2 mov $f2,a
... |
EDIT: dammit! The S-SMP is overwriting code somewhere, but it varies
every time you run it. In the above example, it's at $1440. So I set a
log for all $1440 writes and only get one.
So either I trace back 1.6gb worth of S-SMP log data to locate the
stray write to $1440, or I leave this one broken.
It would probably be easier to reverify every single S-SMP opcode and
its addressing mode stuff to check for page wrapping errors or somesuch
that could cause a write to go to the wrong place.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 22, 2006 10:19 pm Post subject: |
|
FitzRoy wrote: |
Touge
Densetsu Saisoku Battle (J) - at bike selection screen, choose an
option. The game's colors will mess up. happens in all bsnes versions.
happens in super sleuth. Doesn't happen in zsnes. |
Code: |
85b33e jsr $fc45 [$85fc45] A:0200 X:0000 Y:0015 S:01f2 D:0000 DB:85 NvMXdizc
85fc45 lda #$00 A:0200 X:0000 Y:0015 S:01f0 D:0000 DB:85 NvMXdizc
85fc47 sta $4350 [$854350] A:0200 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdiZc
85fc4a lda #$22 A:0200 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdiZc
85fc4c sta $4351 [$854351] A:0222 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc4f lda $1037 [$851037] A:0222 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc52 asl a A:0201 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc53 tax A:0202 X:0000 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc54 lda $fc79,x [$85fc7b] A:0202 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc57 sta $2121 [$852121] A:0221 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc5a lda $fc85 [$85fc85] A:0221 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc5d sta $4352 [$854352] A:0291 X:0002 Y:0015 S:01f0 D:0000 DB:85 NvMXdizc
85fc60 lda $fc86 [$85fc86] A:0291 X:0002 Y:0015 S:01f0 D:0000 DB:85 NvMXdizc
85fc63 sta $4353 [$854353] A:02fc X:0002 Y:0015 S:01f0 D:0000 DB:85 NvMXdizc
85fc66 lda #$0f A:02fc X:0002 Y:0015 S:01f0 D:0000 DB:85 NvMXdizc
85fc68 sta $4355 [$854355] A:020f X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc6b lda #$05 A:020f X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc6d sta $4354 [$854354] A:0205 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc70 sta $4357 [$854357] A:0205 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc73 lda #$20 A:0205 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc75 sta $420b [$85420b] A:0220 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc
85fc78 rts A:0220 X:0002 Y:0015 S:01f0 D:0000 DB:85 nvMXdizc |
The programmers didn't feel
like setting $4356. It just assumes the high byte of DMA channel 5's
transfer length will be 0x00. Well, it's not. HDMA occurs on the screen
before, with the biker guy talking about whatever. Not just HDMA,
indirect HDMA. Which loads the indirect address into the same register
used by transfer size.
I'm seriously not going
to last much longer with this. I think I'll just track down the
developers of this game and bash their fucking heads in until they die.
After all, Japanese prison has got to be more fun than fixing these
games the rest of my life.
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 :
STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356
EDIT: more logs for me for when I get home.
Code: |
$2121 = #$21
$4350 = #$00
$4351 = #$22
$4352 = $05fc91
$4355 = #$??0f
* 824356 = 00 @ 82aa02 <109, 942>
* DMA[5]: 00 05fc91<>22 f00f 0042 85fc79 <240, 928>
* w0000=14 @ 85fc79 < 54, 436>
* w0000=14 @ 85fc79 < 85, 464>
* w0000=14 @ 85fc79 < 88, 628>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <240, 924>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <240, 932>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <240, 936>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <240, 896>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <240, 908>
* DMA[5]: 00 05fc91<>22 000f 0042 85fc79 <247, 276>
* hdma5i kill f000 <223,1222>
7e0c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7e0c10: 00 00 00 00 00 00 00 00 96 00 8e 00 ff 00 00 00
7e0c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7e0c30: 00 00 f4 00 06 00 6d 00 78 00 82 00 5c a4 7e 00
7e0c40: 07 00 00 00 10 00 3c ff 00 3c ff 00 58 70 ef 01
7e0c50: ff 00 00 f0 00 e0 f0 d0 e1 f0 90 e3 00 f0 00 e8
7e0c60: f0 c0 e9 00 f0 00 f0 d0 e9 f0 90 eb 00 f0 00 f0
7e0c70: f0 c0 f1 00 ad 00 f0 2c f0 f0 ec f1 00 ad 00 98
* hdma5i fetch from 7e0c6d=f0
* hdma5i kill f000 <223,1220> |
ZSNES also has $7e0c6d = #$f0 here, so the HDMA table is correct.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Sep 23, 2006 4:21 am Post subject: |
|
Hey
byuu, I'll give you a US game to look into. Its Pilotwings, and I've
noticed an interesting glitch with every emulator I've tried. If you
the game play through its various demos, when it gets to the bi-plane
landing sequence, the plane will crash short of the runway. On the
actual console, the plane lands perfectly. I'm guessing its a timing
issue with how the input commands are processed on a real console
versus an emulator. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 23, 2006 8:45 am Post subject: |
|
I
hacked the fucking game to pieces and ran it on my UFO until I was able
to log the behavior and figure out what the hell was going on:
http://byuu.cinnamonpirate.com/temp/touge.txt

Sigh... and before I hear anything else about this godforsaken game,
the biker picture with the mosaic effect when you start a new game is supposed to fuck up on three different sections of the screen. I saw the same thing happen on the UFO. |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sat Sep 23, 2006 7:58 pm Post subject: |
|
byuu wrote: |
Sigh... and before I hear anything else about this godforsaken game,
the biker picture with the mosaic effect when you start a new game is supposed to fuck up on three different sections of the screen. |
I... seriously... cannot stop laughing...
omg. This is candidate for a sig quote.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 24, 2006 4:54 am Post subject: |
|
Good job. That's hardcore. 
Retested "T" through "Z" of (J) and didn't find anything else. Tested all minority regions and found no problems. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 24, 2006 5:57 am Post subject: |
|
Would
you mind testing S (J), as well? Just so we can say you tested them
all, and in case tetsuo55 missed anything (like Touge). If not, no big
deal.
Also, I'm getting quite upset and worn out,
but I do definitely want to know of any new bugs you find. Though if
indeed all Japanese games have been tested, I'm extremely relieved that
I'm almost done fixing these crazy games -- sans regressions, of course.
Some more news on Mahjongg Taikai II. I tested latch positions against
the real SNES and bsnes. Good news, my timing isn't off by much after
all. The game really does write to $4b.d0 during two separate frames,
and that does cause the OAM DMA to occur twice. I can disable either
one, and the game still works. I found the reason, too. But it isn't a
simple fix.
It's basically working because OAM address reset is setting the OAM
write address back to $0000 again. But it's weird the way it works. The
game disables video for an entire frame after the first OAM DMA, and
then during the NMI for the second frame, it re-enables the display at
V=225,HC=~484. It then performs the DMA at V=225,HC=~766. So,
basically, OAM address reset has to be occuring somewhere between
HC=484 and HC=766. I had to use 650 to get the stage -and- title screen
to work.
So, I need to come up with some extreme tests to figure out where OAM
address reset happens. Even once I find the exact clock position (or a
close estimate, as it probably bounces around a little between frames),
there's no easy way to add the reset to that position. The PPU only
gets called at HCLOCK=0 and HCLOCK=<config file position>. I
don't want to be forced to put the config file variable at ~650 to get
this game working, so basically the CPU is going to have to tell the
PPU to reset OAM address, which is going to look ugly. Again, this is
another good thing for a dot based renderer, but I will add it to
sCPU+bPPU for the time being anyway, if possible. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 24, 2006 7:27 am Post subject: |
|
byuu:1, Japan:0

Brand new SNES technical information:
1) OAM address reset occurs at exactly V=225(240),HC=10 if the display is not disabled.
2) OAM address reset also occurs if $2100.d7 (display disable) transistions from 1->0, and only
on 1->0 transistions. Not for 0->0, 0->1 or 1->1 writes.
This is true during vblank, I do not know if it is true during active
display (it probably is), because reads/writes to OAM are unreliable
during active display. Note that you can transistion $2100.d7 multiple
times, and reset OAM address every single time.
While I can't check Super Sleuth because it is closed source, no other
emulator implements the second finding (yet). If Mahjongg Taikai II
works in any other emulator, it is because the timing is inaccurate by
more than 128 scanlines. I've confirmed timing issues allow the game to
work in SS and ZSNES, because they have debuggers and I can see where
the two $4b writes occur. I have compared emulator latch positions to
the game running on real hardware.
I'm mostly pointing this out so that other authors don't assume that
because the game works for them, that my findings are not correct.
Here are two test ROMs verifying the above two findings.
The first is test_oamreset.smc for verifying the exact position auto
OAM reset occurs. Don't expect this to work in most emulators, due to
the use of libclock. Also, ignore the OPVCT/OPHCT output at the bottom
of this test, it latches the counters way after reading OAM. I got the
timing position of the read from $2138 from bsnes' debugger.
The second is test_oamresetm.smc, which verifies the second finding. This one should work in any emulator.
http://byuu.cinnamonpirate.com/temp/oamreset.zip
EDIT: yeah, ran test_oamresetm.smc on the latest public releases of all
active emulators. All of them fail the test. Had to modify the STP
instruction to BRA $FE since SNES9x and SNEeSe don't like that opcode.
A shame too, it's very useful ;)
Last edited by byuu on Sun Sep 24, 2006 8:21 am; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 24, 2006 8:01 am Post subject: |
|
byuu wrote: |
Would
you mind testing S (J), as well? Just so we can say you tested them
all, and in case tetsuo55 missed anything (like Touge). If not, no big
deal. |
Yes, I will. And if someone wants to go over mine again, knock yourselves out 
byuu wrote: |
Also,
I'm getting quite upset and worn out. Though if indeed all Japanese
games have been tested, I'm extremely relieved that I'm almost done
fixing these crazy games -- sans regressions, of course. |
Gah, don't even mention the word regression! Horror. We were lucky to
have caught the Battle Blaze and hanging Taz-Mania issues. They ended
up being pretty rare. However, it was the right time to do all that
testing. The emulator had gotten so accurate that the only ones left
were these obscure games that did weird shit or somehow got away with
sloppy code. But seeing as how regressions do still happen, and given
that I can't go back and retest all those (J) games, the best thing you
can do is fix what you can before I start with (E) and (U). Because as
long as there's 1000+ games for me to test, you still have an
opportunity to test the durability of recent fixes. That's the smart
way to do it, but there's no timetable here. I probably won't even get
to (E) and (U) games for at least another month.
Edit: wow, just saw your last post. Awesome news.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Sep 24, 2006 2:21 pm Post subject: |
|
Wow great news Byuu, thanks to these horrible games you found some unemulated stuff and were able to make new tests 
Ive also started with S, but yes they are on hold for now, i will be able to continue testing in about 2 weeks 
anyway i started from the top alphabetically sorted, so maybe fitzroy can start S from the bottom up?
i have not found any bugs yet that are not caused by the missing BS
emulation. I still think BS simply has a little more ram to play with |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 24, 2006 8:35 pm Post subject: |
|
tetsuo55 wrote: |
Wow great news Byuu, thanks to these horrible games you found some unemulated stuff and were able to make new tests :D |
Unfortunately, it's not a very big finding. It only fixes one known
game thus far, which is undoubtedly why nobody's ever noticed this
behavior before. I'm hoping though that this is part of the puzzle with
Uniracers, which is still broken.
Quote: |
i
have not found any bugs yet that are not caused by the missing BS
emulation. I still think BS simply has a little more ram to play with |
BS has a lot of stuff. There's at least one document explaining a lot
of the stuff in vague detail. I'd want a real BS I could run test code
on before I started trying to emulate it. Same for non-bit-accurate
special chips (SFX, SA-1, SPC7110, etc), I want hardware to test on
before I waste my time.
Running BS games by themselves is a hack to begin with, you need that
BIOS and all of that to setup the system first. I probably won't ever
support direct loading of BS games. If they load directly anyway
though, great.
By the way, I killed the debugger since I know I'll never get around to
it again. There's a tracer+console+memory editor there now instead, and
this will be enabled even in public releases. There's no DEBUGGER
variable, so the 10% speed hit with debugging enabled is now gone.
Sorry to those who wanted a powerful debugger. It's too hard to keep
the emulation code clean and maintain platform-specific debuggers that
need to hook as many things as one needs control over. Perhaps one day
when emulation is more complete, I can add a more full-featured
debugger like bsnes v0.013. I also plan on making the tracer far more
useful, allowing logging of hardware edge cases, DMA/HDMA transfers,
etc.
|
|
JonasP New Member
Joined: 20 Sep 2006
Posts: 2
|
Posted: Sun Sep 24, 2006 9:23 pm Post subject: |
|
Quote: |
Sorry
to those who wanted a powerful debugger. It's too hard to keep the
emulation code clean and maintain platform-specific debuggers that need
to hook as many things as one needs control over. |
MESS has a powerful debugger. You and Arbee could cooperate on improving that SNES driver instead...
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 25, 2006 7:18 am Post subject: |
|
Holy fuck, $320 with shipping for a system you can't even use anymore >_<
Well, I guess it's safe to say I won't be picking one of these up. And
no one else should either. That's a horrible ripoff. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Mon Sep 25, 2006 7:42 am Post subject: |
|
FirebrandX wrote: |
Hey
byuu, I'll give you a US game to look into. Its Pilotwings, and I've
noticed an interesting glitch with every emulator I've tried. If you
the game play through its various demos, when it gets to the bi-plane
landing sequence, the plane will crash short of the runway. On the
actual console, the plane lands perfectly. I'm guessing its a timing
issue with how the input commands are processed on a real console
versus an emulator. |
http://users.tpg.com.au/advlink/dsp/dsp1.html#OP28
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 25, 2006 6:53 pm Post subject: |
|
Quote: |
There are some cheaper ones available: |
Well, perhaps some day then. I don't even know if I'll be able to run
my own code on it. I'd probably have to figure out a way to dump/flash
the little addon carts first.
Could possibly do it with a BS-X cart connected to a GDSF7 that allows
passthru of the cart flashing registers. Who knows.
Here's a mockup of my potential alternate cart loading screen:

Ideas? The default is still going to be the windows file open dialog,
and this one will only have carts added to the database. Not sure if
I'll add a scan button to only show available carts, or just do a scan
at each startup, or something else like that.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Sep 25, 2006 6:58 pm Post subject: |
|
you are adding a rom library to bsnes?
oo-err
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 25, 2006 7:47 pm Post subject: |
|
"oo-err"?
I'm not including the ROMs, and only adding official releases to the
textual database. I already require the database to determine the PCB
for memory mapping purposes, so this is really just a glorified
frontend to that database.
Why, does that seem to go against my goals of writing a hardware emulator or something? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Sep 25, 2006 7:54 pm Post subject: |
|
byuu wrote: |
Why, does that seem to go against my goals of writing a hardware emulator or something? |
Yes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Sep 25, 2006 8:03 pm Post subject: |
|
byuu wrote: |
Still can't get it to work...
http://i73.photobucket.com/albums/i221/byuusan/ldr3.png
This is my third attempt. The holes are for my breadboard. I don't use
the power lines because they don't seem to work right (that or I'm
screwing it up, probably the latter). The gray lines represent the long
columns that are connected behind-the-scenes on the breadboard.
Now, as for the transistor... I don't know if it should be { Tc, Tb, Te
} or { Te, Tb, Tc }. I've tried with both PNP and NPN transistors in
both orientations (basically, I flipped them around since I have no
clue which side is the collector and which is the emitter).
With the PNP, in one orientation the LED is always on. In the other,
the LED is only on with light, and off with darkness. With the NPN
transistor, the light never comes on regardless of which direction I
insert the transistor. Ideas? |
http://www.futurlec.com/Transistors/C9015.shtml
This may not be your exact C9015, however, the pinouts for TO-92 package transistors are generally the same.
Ok.. Still not quite right. I happen to have found a schematic online
for doing exactly what you want to do using an NPN transistor. I
couldn't find one for PNP. And as I said, I have no means to draw one
for you aside from paint or something and well I suck at that.
Since pictures speak louder than words:
http://www.kpsec.freeuk.com/trancirc.htm#sensors
That's exactly what you're doing with some decent explanation of what's
going on. You don't need the variable 10K as it shows. You can use the
resistance values you have. The variable resistor would just allow you
to adjust the sensitivity of the LDR.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 25, 2006 8:28 pm Post subject: |
|
Quote: |
http://www.kpsec.freeuk.com/trancirc.htm#sensors |
Saw that, I'm working on a PNP version of this. I still can't believe
it was done with an NPN. The only part of that I don't understand is
when that circuit has light, the energy should flow from 0v to the LDR,
where it passes through, but then it goes right over the intersection
in the middle to the top left of the circuit through the resistors,
then to the right to +9v. Why doesn't the current still flow from 0v to
the NPN emitter, through the base, and enable the transistor flow from
emitter to collector, thus turning on the LED in both cases?
Personally, I found the explanation on that page extremely lacking.
Quote: |
Why, does that seem to go against my goals of writing a hardware emulator or something? |
Well, I guess I'll have to contradict myself, then. The memory mapper
info stored in carts may not be part of the hardware, but until
cartridges start storing that info in them, I've no choice. If you can
store all needed info in the 512-byte ROM headers (cart name, region,
special hardware, PCB ID, genre, year, etc) then I can just use that
instead. Until then, however...
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Sep 26, 2006 11:12 am Post subject: |
|
Did some more testing(in the newest wip ofcourse),
found a real bug i think
Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place
and probable some missing hardware bug
Same Game + Tengai Makyou Zero Jikei - Data Pack (J).smc > black screen, special hardware?
Byuu, i like that cartridge loading menu 
good work |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Sep 26, 2006 1:02 pm Post subject: |
|
tetsuo55 wrote: |
Same Game + Tengai Makyou Zero Jikei - Data Pack (J).smc > black screen, special hardware?
|
Last I checked only ZSNES supports dual cart games such as Sufami Turbo, Same Game, and SD Gundam GX.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
dragoonmaster New Member
Joined: 31 Aug 2006
Posts: 4
|
Posted: Tue Sep 26, 2006 1:36 pm Post subject: |
|
Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place
looks correctly for me, atleast a lot more correctly as in zsnes
edit: works correctly with the old grafigengine in zsnes without interlacing |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Sep 26, 2006 3:19 pm Post subject: |
|
Nach, the none datapack version do run however are those singel cart, or merged or hacked?
dragoonmaster, which version did u use? |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Sep 26, 2006 3:20 pm Post subject: |
|
byuu wrote: |
Quote: |
http://www.kpsec.freeuk.com/trancirc.htm#sensors |
Saw that, I'm working on a PNP version of this. I still can't believe
it was done with an NPN. The only part of that I don't understand is
when that circuit has light, the energy should flow from 0v to the LDR,
where it passes through, but then it goes right over the intersection
in the middle to the top left of the circuit through the resistors,
then to the right to +9v. Why doesn't the current still flow from 0v to
the NPN emitter, through the base, and enable the transistor flow from
emitter to collector, thus turning on the LED in both cases?
Personally, I found the explanation on that page extremely lacking.
|
The current that enters the base is based on the voltage drop of LDR.
Basically, you've got a voltage divider between the resistor and LDR.
Assume LDR is 1MegOhm when there is no light. When there is no light,
the resistance of LDR is very large as opposed to your 10K, therefore
most of the voltage will be dropped across LDR which in turn is high
voltage at the base.
If LDR is 100Ohms when there is much light, it is much smaller than the
10K and therefore the voltage drop across LDR will now be very close to
zero or ground which in turn is practically ground at the base.
YES, there IS current to the base in BOTH cases, however the current is
so small in one, it is not enough to turn the transistor on.
Transistors have a rated base current or voltage to turn the transistor
ON.
Check out Wikipedia for more in depth information on transistors. They
are probably one of the most complicated components in electronics, yet
are simple at the same time.
http://en.wikipedia.org/wiki/Bjt
As for using the PNP. I had a few spare minutes today and some extra
parts at my desk, so I constructed the circuit to refresh and make sure
I still knew what I was talking about. 
I made the circuit and it worked perfectly using a PNP transistor. THIS is what I did:
1. Positive Battery terminal goes directly to the EMITTER.
2. Positive Battery terminal also goes to LDR.
3. The other end of LDR goes to the BASE.
4. The COLLECTOR goes to a resistor(R1 for LED).
5. The other end of R1 goes to the anode of the LED.
6. Catchode of the LED goes to GROUND.
7. Ground also goes to a second resistor R2.
8. Other end of R2 goes to the BASE.
Behold my mad MS Paint skills.
It looks something like this:

_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 26, 2006 4:26 pm Post subject: |
|
tetsuo55 wrote: |
Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place
|
This is on my "to verify on hardware" list. One of the interlace fields
seems to persist rather than disappear during transitions, but I'd
hardly call it "all over the place." Maka Maka is another one.
Correct non-GoodSNES name - Ranma One Half - Chounai Gekitou Hen (J)
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 26, 2006 4:56 pm Post subject: |
|
There
might be some issues with the video blitter outputting the interlaced
scanlines... simulating interlace on a progressive monitor is easier
said than done. But this is certainly not an emulation bug. The game
does enable interlace, despite not using a "hires" mode to take
advantage of it. The developers probably thought they were clever
eliminating the "scanlined-look of the display" by enabling interlace,
but they just resulted in making the video twice as choppy, even on the
real system.
Note that to save speed, I only draw
to the currently active "field". If the game turns off the display AND
interlace at the same time, then bsnes would not erase the odd fields.
I could make it do this if nobody minds a 40% speed hit in hires video
games. No, I'm not going to write hackish code to detect screen enable
and disable to clear both lines.
Unless monitor manufacturers start including native interlace modes,
the best I can do is add options to forcefully disable interlacing in
224-height modes, or implement some sort of 30/25fps interlace frame
blending filter. |
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Wed Sep 27, 2006 6:16 am Post subject: |
|
Nightcrawler wrote: |
As for using the PNP. I had a few spare minutes today and some extra
parts at my desk, so I constructed the circuit to refresh and make sure
I still knew what I was talking about. 
I made the circuit and it worked perfectly using a PNP transistor. THIS is what I did:
1. Positive Battery terminal goes directly to the EMITTER.
2. Positive Battery terminal also goes to LDR.
3. The other end of LDR goes to the BASE.
4. The COLLECTOR goes to a resistor(R1 for LED).
5. The other end of R1 goes to the anode of the LED.
6. Catchode of the LED goes to GROUND.
7. Ground also goes to a second resistor R2.
8. Other end of R2 goes to the BASE.
Behold my mad MS Paint skills.
It looks something like this:
 |
Hmm... That reminds me... When I was 10, I built a small device using a
schematic I found in a book in the library. They called it an
"electronic rooster". It basically made noise when light hit it. I
distinctly remember driving all over hell and creation to find a "light
activated transistor". I can't remember if it was PNP or NPN but it
sure was a bitch to find. It looked like a normal transistor but the
top was transparent.
I remember that the circuit was really simple and used a 9 volt battery
for power. It used a small standard speaker for sound because I don't
think that piezo speaker devices were common yet.
EDIT: I just found some interesting circuits here...
http://www.michaelsharris.com/electronics/week3/transistorSwitches.htm
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Wed Sep 27, 2006 2:01 pm Post subject: |
|
Somewhat off-topic:
http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm
"Thread like an expert, without being one. Intel® Threading Building
Blocks 1.0 is a C++ runtime library that simplifies threading for
performance. It provides parallel algorithms and concurrent data
structures that eliminate tedious threading implementation work. It's a
tested and performance-tuned parallel substrate for your application.
"Introduce threading that unleashes the performance of multi-core
platforms. Write applications once and deploy on multiple OSs. Intel®
Threading Building Blocks enables your application performance to scale
as the number of cores grow."
How does this compare to libco? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 27, 2006 2:41 pm Post subject: |
|
tetsuo55 wrote: |
Nach, the none datapack version do run however are those singel cart, or merged or hacked?
|
I don't believe in merging. Hence NSRT's -split option.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 27, 2006 3:12 pm Post subject: |
|
Quote: |
How does this compare to libco? |
Sigh.
1) Intel's library is preemptive. Includes stuff for mutexes,
semaphores, critical sections, all of that shit. Mine is cooperative,
there's only one thread as far as the OS is concerned. You can think of
cooperative as having multiple stacks. In fact, that's all I do.
Allocate a new stack, then to switch cothreads, switch the stack
pointer and push/pop volatile registers like a callee typically would.
2) Intel's library is ridiculously priced, mine is public domain. You can do whatever you want with mine for free.
3) Intel has developers that are paid to improve and port it. I'm the
only one who would ever work on mine for free. So no doubt, Intel's
works on more platforms.
Quote: |
I don't believe in merging. Hence NSRT's -split option. |
Yeah, I really need a multi-file loader system in place, so I can load
"multi-file" games like SameGame and Sufami Turbo.
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Wed Sep 27, 2006 3:52 pm Post subject: |
|
byuu wrote: |
Sigh.
1) Intel's library is preemptive. Includes stuff for mutexes,
semaphores, critical sections, all of that shit. Mine is cooperative,
there's only one thread as far as the OS is concerned. You can think of
cooperative as having multiple stacks. In fact, that's all I do.
Allocate a new stack, then to switch cothreads, switch the stack
pointer and push/pop volatile registers like a callee typically would.
2) Intel's library is ridiculously priced, mine is public domain. You
can do whatever you want with mine for free.
3) Intel has developers that are paid to improve and port it. I'm the
only one who would ever work on mine for free. So no doubt, Intel's
works on more platforms.
|
Price tag aside, Intel's deal seemed like a lot of PR and little
substance. Sorry to threadjack, I certainly didn't want to suggest
anything that would be discouraging. The libco page is pretty
straightforward and honest, and based upon the results from bsnes it's
working. Maybe I'm just old-fashioned, but I'd rather trust somebody
who is open about his work than some faceless company with flashy PR,
and it's always really inspiring to flip through your WIP stuff.
Thanks.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 29, 2006 4:02 am Post subject: |
|
Got
my tototek kit in the mail today. Unfortunately, I couldn't find my
bloody snes power adapter. I have a universal, but none of the plugs it
came with are big enough Ordered a replacement on ebay which should hopefully come in next week.
I'll probably test the (J) S games this weekend. There's a huge college
football game this saturday and my city is going to clog to a stop. So
it's either stay inside or brave the drunken mayhem.
I was thinking about audio options the other day. I think it would be a
good idea to add sound channel disable/enable checkboxes to the
"emulation settings" area. Reason being, what if someone wanted to
record audio, but just sound effects or just music, and the game had no
sound test. SPC isn't always an option - Lord of the Rings anyone?
Otherwise, I see no need for an audio section or other audio options.
The ability to choose worse/less accurate interpolation options is
complete bloat. Frequency selection gives you the ability to increase
your sound frequency, which has NO tangible benefit. Reverse stereo?
Uhhhhhhhh... drawing a blank. Someone have their speakers plugged in
wrong?  |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Fri Sep 29, 2006 4:16 am Post subject: |
|
FitzRoy wrote: |
Reverse stereo? Uhhhhhhhh... drawing a blank. Someone have their speakers plugged in wrong?  |
Heh, actually I found this useful back when the most convenient
placement for the speaker connected directly to my PC was actually on
the wrong side. I've never been able to find an option like that in
windows.
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Sep 29, 2006 4:23 am Post subject: |
|
blackmyst wrote: |
FitzRoy wrote: |
Reverse stereo? Uhhhhhhhh... drawing a blank. Someone have their speakers plugged in wrong?  |
Heh, actually I found this useful back when the most convenient
placement for the speaker connected directly to my PC was actually on
the wrong side. I've never been able to find an option like that in
windows.
|
I forget if it was related to the sound card and/or speakers.. but such an option was needed back in the day.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 30, 2006 4:50 pm Post subject: |
|
Sooo, laziness and vague recollections of past importance. I'm totally for it now!  |
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Sat Sep 30, 2006 6:21 pm Post subject: |
|
I
seem to remember that the volume control was on my left speaker once,
but I wanted it on the right side of my screen where it was easier to
reach... that was the only time I can think of that I used reverse
stereo. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 30, 2006 6:46 pm Post subject: |
|
You're
going to need to post a picture to tell me what you mean. What kind of
wonky setup would absolutely force you to place your left speaker that
much farther away than the right? |
|
kevman Redneck Gamer-Mod

Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
|
Posted: Sat Sep 30, 2006 7:16 pm Post subject: |
|
I
have an ultra-ultra-ultra cheap PCI soundcard "asound 120" or
something, that outputs reversed audio all the time. Probably a driver
typo or something; even the balance in mixer is wrong.
_________________
SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!!
Steelers no longer officially own your ass. Pittsburgh will miss The Bus. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Sep 30, 2006 7:25 pm Post subject: |
|
Fitzroy,
a Reverse Stereo option is rather harmless for emulation.. it does help
those people that need it though (it's not like the option harms sound
emulation in any way).
I wasn't being vague
earlier, but I remember a number of DOS games that deployed such an
options in their sound tests. It was problematic back in the day, and
there are still reminences of it in today's hardware setups. Even
though 95% of the time, you will never need to use it.. this option is
relatively helpful for some.
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 30, 2006 8:52 pm Post subject: |
|
I
disagree. When we see the people who "need" this option, we see far
better solutions. If you're using a sound card that is so old and is so
bad that the drivers can't even separate the stereo channels correctly,
guess what the best thing to do is? No, it' isn't asking all the
authors of programs you use to add a software option because you belong
in the 1% of the population who is so incredibly cheap and lazy as to
not want to spend $10 to get a decent soundcard.
It's not harmless, either. The more useless options you add to your
emulator, the harder it is for people to find what they really need,
and the more confusing it becomes to new users. Once, it might seem so.
Then comes the frequency selection by the same token. Then the sound
buffering. Then hey, while we're at it, let's make our emulator seem
even more powerful with interpolation selection. Add a clock... a
little calendar... some nice snow effects and a rubber chicken that
dances across the screen because, you know, that's harmless, too.
C'mon... |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Sat Sep 30, 2006 9:33 pm Post subject: |
|
FitzRoy wrote: |
The
more useless options you add to your emulator, the harder it is for
people to find what they really need, and the more confusing it becomes
to new users. |
i call BS. it's all in the GUI whether extra options confuse or not. zsnes executes flawlessly here.
and no matter how streamlined the gui is, or how stripped and basic
your program is, you'll still always have someone who can't figure out
how get a game of FFVI started.
i personally like to have a choice when it comes to configurations in
any program. even if i don't make use of them, the fact that the choice
is there is appreciated.
_________________
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Sep 30, 2006 10:10 pm Post subject: |
|
I'd
also argue Sound Buffering is still useful.. but obviously "it is
useless" even if mainstream (including the high end) cards at times may
not simply work unless such a setting exists.. I guess all "sound card
assisting features" that "don't change emulated sound output" are
completely useless huh? 
sweener2001, I'm sure we will get another of those posts before the end of 2006. 
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 30, 2006 11:57 pm Post subject: |
|
sweener2001 wrote: |
FitzRoy wrote: |
The
more useless options you add to your emulator, the harder it is for
people to find what they really need, and the more confusing it becomes
to new users. |
and no matter how streamlined the gui is, or how stripped and basic
your program is, you'll still always have someone who can't figure out
how get a game of FFVI started.
|
That's defeatist reasoning. Should we stop teaching people to use
condoms because there will always be kids who don't listen? The idea
here has always been about reduction, and doing what we can.
Eliminating all user confusion is impossible, but when it comes to the
GUI, we can do something to alleviate it. We can make it better without
"stripping it" or "dumbing it down" simply by removing UNNECESSARY
OPTIONS that nobody WOULD/SHOULD be using. ZSNES is wrong on this.
Period.
Quote: |
i personally like to have a choice when it comes to configurations in
any program. even if i don't make use of them, the fact that the choice
is there is appreciated. |
I'm glad you're not writing the emulator then, because if you're the
type that would appease every idiotic request, I would vomit at the
download size, the source code, and the overall wading through useless
stuff given the same precendence as the useful.
@Deathlike: sound buffering may indeed be useful still. But I wonder if
this addition has more to do with a program's shortcomings in its code
than sound card drivers. None of my PC games, for example, have
buffering settings, but work perfectly.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Oct 01, 2006 12:17 am Post subject: |
|
FitzRoy wrote: |
@Deathlike:
sound buffering may indeed be useful still. But I wonder if this
addition has more to do with a program's shortcomings in its code than
sound card drivers. None of my PC games, for example, have buffering
settings, but work perfectly. |
I believe that has more to do with how the SNES audio has to sync with
the picture you are seeing.. and that is vastly different than normal
games that play their audio. The problem with this method is that some
audio cards aren't exactly friendly to this.
_________________
FF4 research never ends for me.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Sun Oct 01, 2006 1:04 am Post subject: |
|
FitzRoy wrote: |
You're
going to need to post a picture to tell me what you mean. What kind of
wonky setup would absolutely force you to place your left speaker that
much farther away than the right? |
The cable that goes into the main speaker isn't long enough to have it
reach the proper side of the monitor from where the PC is standing, as
opposed to the secondairy speaker which is only connected to the main
one via another cable. Do you really need a picture for that? >_>
I don't care about the option now (and I'm not gonna get into this
argument about which options should exist) but back then it was pretty
damn handy whether you ridicule it or not.
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 1:37 am Post subject: |
|
To be honest, as much as I dislike the GNOME mindset, I actually do think minimal options work good when done right.
GNOME just so happens to take it too far and think simplifying things
back to 1993-levels is a good thing. XFCE is a good example, though.
Every option that you need is there, nothing is missing that I'd want.
Takes about 5-10 minutes tops to fully configure the entire system.
I don't mind adding options like reverse stereo if someone really needs
it, but I won't add it to the GUI. I think a good mindset would be, add
useful options that more than 50% of people would use to the GUI, and
add the rest to the config file. If you need reverse audio, search for
"settings.reverse_audio" and set it to true.
I already have a few such hidden options in the config file, such as
CPU<>APU clock execution rates, PPU render position, etc.
Now, frivilous things like cubic spline and 8-point filtering, I will
not be adding. It isn't accurate, and it breaks sound effects in some
games. We know the SNES uses gaussian, and that's all I'm personally
adding.
By the way, anomie found the proper HDMA fix for Touge Densetsu. I'll
be adding that when I can. I'm also considering reverting the HDMA fix
for Jumbo Ozaki no Hole in One. I just don't feel comfortable with it.
Mahjongg Taikai II showed that there were some semi-important timing
problems elsewhere, so I think I should leave this game broken until I
find out where those timing issues are coming from. I can't verify the
Ozaki fix because my HDMA timing lacks DMA bus sync code. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 01, 2006 1:54 am Post subject: |
|
blackmyst wrote: |
FitzRoy wrote: |
You're
going to need to post a picture to tell me what you mean. What kind of
wonky setup would absolutely force you to place your left speaker that
much farther away than the right? |
The cable that goes into the main speaker isn't long enough to have it
reach the proper side of the monitor from where the PC is standing, as
opposed to the secondairy speaker which is only connected to the main
one via another cable. Do you really need a picture for that? >_>
I don't care about the option now (and I'm not gonna get into this
argument about which options should exist) but back then it was pretty
damn handy whether you ridicule it or not.
|
For the last time, the solution is not requesting that programs add an
option to account for your external problem. Guess what the REAL
solution is, that will not only enable you to hear correct separation
in bsnes, but EVERY program on your computer. Buy a $5 extension cable.
It's that simple! I can NOT BLOODY BELIEVE the resistance I am meeting
with this.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Sun Oct 01, 2006 2:38 am Post subject: |
|
FitzRoy wrote: |
For
the last time, the solution is not requesting that programs add an
option to account for your external problem. Guess what the REAL
solution is, that will not only enable you to hear correct separation
in bsnes, but EVERY program on your computer. Buy a $5 extension cable.
It's that simple! I can NOT BLOODY BELIEVE the resistance I am meeting
with this. |
blackmyst wrote: |
I don't care about the option now (and I'm not gonna get into this argument about which options should exist) but back then it was pretty damn handy whether you ridicule it or not. |
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
Joe Camacho Devil's Advocate

Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
|
Posted: Sun Oct 01, 2006 2:55 am Post subject: |
|
blackmyst wrote: |
FitzRoy wrote: |
For
the last time, the solution is not requesting that programs add an
option to account for your external problem. Guess what the REAL
solution is, that will not only enable you to hear correct separation
in bsnes, but EVERY program on your computer. Buy a $5 extension cable.
It's that simple! I can NOT BLOODY BELIEVE the resistance I am meeting
with this. |
blackmyst wrote: |
I don't care about the option now (and I'm not gonna get into this argument about which options should exist) but back then it was pretty damn handy whether you ridicule it or not. |
|
I can't BLOODY BELIEVE some people can't even read.
_________________
*Sometimes I edit my posts just to correct mistakes.
I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 2:59 am Post subject: |
|
Sigh.
Back on topic, I've added a buglist to my bsnes page. No reason to stop
maintaining yours FitzRoy, as it will probably be updated a lot faster.
The main reason is just so that people who don't read this board will
know which bugs to expect. And it also has more detailed information
(severity and cause).
Also notice the reversion of the Jumbo Ozaki fix. I took it back out
for now, as I'm not happy with it, and I recently remembered that this
was the cause of Energy Breaker splash screen flickering.
I am now happy with the Touge Densetsu fix, so there's not much need to
monitor that one in the future if you don't want to. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 01, 2006 4:39 am Post subject: |
|
blackmyst wrote: |
I
don't care about the option now (and I'm not gonna get into this
argument about which options should exist) but back then it was pretty
damn handy whether you ridicule it or not. |
I flipped out a bit, but that wasn't your entire post, and it's not
just you. Impossibly shitty sound card was another excuse in reverse
stereo's favor, and I had to waste time explaining that this was
something that you people need to fix, and not program authors. Again,
this was something I thought was obvious, so I think I was just
frustrated that two people offered their positive view on the option,
but never showed themselves willing or aware of fixing it themselves
for little cost.
@byuu. That's a good idea. I take it you don't want to mess with having a forum?
|
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Sun Oct 01, 2006 8:07 am Post subject: |
|
i
never said that every single option anybody would ever try and request
needed to be added. but i will concede that my logic was faulty in that
chunk you quoted.
users have an option for a
visual filter and color palette, but when it comes to sound, they're
refused? you can't argue for minimalism and streamlining for only half
of the experience.
my argument was that if the gui is configured properly, nobody with
half a brain will get confused by the options offered. clutter and
confusion is not your real reason for being against it. you just don't
feel it's necessary. there is a difference there.
i fail to see how the source would all of a sudden become a mess to
read, just because there are more options. do you just assume that
someone who adds extra options into the gui is a sloppy coder? i also
fail to see how an executable that is a few KB bigger hurts anyone,
especially today.
if you're against an option because you feel it's unnecessary, that's fine and dandy.
before you get all uppity and "flame" me, just realize that i never
disagreed with you on people just needing to get newer hardware so that
devs can code easier. i wasn't defending the guy trying to play with
his 10 year old box. my point was that a choice is nice and
appreciated(like whether i want the ntsc filter, or hqx), and that a
well-configured gui can basically eliminate confusion.
respond to this if you want, i won't be derailing this thread anymore on this subject.
_________________
 |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sun Oct 01, 2006 8:30 am Post subject: |
|
Hmm,
sorry to break in out of nowhere, but I had a little something to say:
quite weirdly, I no longer have those gamepad problems with SMK, yet
I'm still using v1.7 and didn't change anything. o_o
Good thing, anyway. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 8:35 am Post subject: |
|
I
have gamepad problems when my USB floppy drive is connected. No idea
why. I sincerely doubt it's my code, since the Joypad control panel
applet doesn't recognize input, either.
http://byuu.cinnamonpirate.com/temp/ups_100106.zip
Format is subject to change, still. But this is pretty much near
finished. Right now, the patcher is command-line only, and there are no
subformats.
I don't suggest using this for any releases, but if anyone wants to try
out creating and applying patches, then by all means...
I intend to have this out in time for bsnes v0.018, which will support
soft-patching with the new format. The license will probably be near
public domain, with the only rule being that no modifications to the
file format are allowed, for the sake of compatibility.
Included is a sample patch for Tekkaman Blade (J)->(E).
EDIT: fixed disk I/O mode. use create_d or apply_d to access files from
hard drive if you are making a patch from files that are larger than
your available physical memory. Expect these modes to be much slower
than create and apply for obvious reasons. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Oct 01, 2006 10:05 am Post subject: |
|
FitzRoy wrote: |
I
flipped out a bit, but that wasn't your entire post, and it's not just
you. Impossibly shitty sound card was another excuse in reverse
stereo's favor, and I had to waste time explaining that this was
something that you people need to fix, and not program authors. Again,
this was something I thought was obvious, so I think I was just
frustrated that two people offered their positive view on the option,
but never showed themselves willing or aware of fixing it themselves
for little cost.
|
Noone was suggesting that it should/must be added, but rather why it
has existed and still has value. It's like arguing against Triple
Buffering because your system (specifically video card+cpu combo)
should be able to handle BSNES. On the other hand, patches other than
DMV27 submitted to byuu have fallen on deaf's ears at times. However,
for you to say the following is appalling.
Quote: |
I'm
glad you're not writing the emulator then, because if you're the type
that would appease every idiotic request, I would vomit at the download
size, the source code, and the overall wading through useless stuff
given the same precendence as the useful. |
Source code growth is only as horrible as the code that is used to
implement said feature. With that said, adding filters will induce a
greater code size than reverse stereo, but with the same line of
logic.. I could suggest that the removal of the cheat code feature if I
disliked cheating. There's nothing we can do if you do not benefit from
a feature.. noone is forcing byuu to
enable/include/add/disable/remove/delete it. It is still worth debating
the merits.
</end rant>
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 01, 2006 10:29 am Post subject: |
|
sweener2001 wrote: |
i never said that every single option anybody would ever try and request needed to be added. |
So you admit that some options don't deserve to be added, but you make no mention of where you draw your line.
sweener2001 wrote: |
users
have an option for a visual filter and color palette, but when it comes
to sound, they're refused? you can't argue for minimalism and
streamlining for only half of the experience. |
Here is where your lack of a line comes back to confuse me. You're
basically putting video filters and reverse stereo in the same camp
here to defend the latter. You also seem to be saying that since video
and sound are equally important, that somehow that makes sound
preferences necessary in light of all the video options. But that's not
a given. Reverse stereo, for example, is a workaround for 1/1000 of
users who are afflicted with a self-resolvable issue and are too
cheap/lazy to do it. It's not a preference by any stretch.
sweener2001 wrote: |
my
argument was that if the gui is configured properly, nobody with half a
brain will get confused by the options offered. clutter and confusion
is not your real reason for being against it. you just don't feel it's
necessary. there is a difference there. |
It's not so much about the confusion when you're only talking about the
one. But when you add something that undeserving, and you've got a
whole new sound section to fill out, everything else would probably
come with it. And don't forget, now that an utterly useless option is
in there, users can use that to argue for new ones by comparitive
worth, and win.
sweener2001 wrote: |
before you get all uppity and "flame" me, just realize that i never
disagreed with you on people just needing to get newer hardware so that
devs can code easier. i wasn't defending the guy trying to play with
his 10 year old box. my point was that a choice is nice and
appreciated(like whether i want the ntsc filter, or hqx), and that a
well-configured gui can basically eliminate confusion. |
If you say "I call BS" to a well-thought out, detailed, and irrefutable
post, naturally I'm going to get a little hostile. I don't disagree
with you that video filters are nice and appreciated. Lots of people
use them and there is a clear discrepency between their usefulness and
the usefulness of reverse stereo or a rubber chicken dancing across the
screen.
sweener2001 wrote: |
respond to this if you want, i won't be derailing this thread anymore on this subject. |
Contrary to what others might think, we are technically talking about
something that should or shouldn't be added to bsnes. Besides, it's
hard to derail a thread this all-encompassing. And if byuu feels
differently, and wants to add an audio section with the stuff to fill
it out, I'm not going to go on a tear. I would have done so already
with the inverse colors option 
*what? you mean you don't want to see what the snes looks like as The Predator?*
@Deathlike: the source code comment was to say that if EVERY option asked for was gotten, not just Reverse Stereo.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 10:50 am Post subject: |
|
Deathlike2 wrote: |
On
the other hand, patches other than DMV27 submitted to byuu have fallen
on deaf's ears at times. However, for you to say the following is
appalling. |
Like most of my bugfixes sent to the ZSNES team that are in SNES9x SVN the same day?
I always add DMV27's patches because they have all been very useful and
appreciated. I'm mostly focused on core emulation, and that is what he
has helped me fix. I try and add as many patches as I can even still.
The only patches I haven't really added are some of kode54's, such as
7-zip+RAR (due to the formats being stupid and placing additional
licensing burdens on my source code), WaveOut support (DirectSound
works just fine for 100% of people so far...), and a few minor things
due to there being far too many changes. He releases his own custom
builds anyway, so what's the problem there?
And then bisqwit's libco_amd64 port. I didn't add that, once again, for
licensing reasons. That is a separate project and it is public domain
only.
Anything else is just due to time. I have a lot going on in life. My
hobbies include: programming, emulation, translation, learning foreign
language, electrical engineering and music; I sleep too much and I work
full time.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Oct 01, 2006 11:10 am Post subject: |
|
byuu wrote: |
Deathlike2 wrote: |
On
the other hand, patches other than DMV27 submitted to byuu have fallen
on deaf's ears at times. However, for you to say the following is
appalling. |
Like most of my bugfixes sent to the ZSNES team that are in SNES9x SVN the same day?
|
I never said they were unappreciated. On the other hand, I don't think
it as simple a matter as you suggest (I dare not touch the
core/rendering for the most part because of unfamiliarity).
_________________
FF4 research never ends for me.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Oct 01, 2006 12:03 pm Post subject: |
|
byuu wrote: |
Deathlike2 wrote: |
On
the other hand, patches other than DMV27 submitted to byuu have fallen
on deaf's ears at times. However, for you to say the following is
appalling. |
Like most of my bugfixes sent to the ZSNES team that are in SNES9x SVN the same day?
|
patches or just general data on how to fix the bug?
Not all of us can interpet your data or if we can, it may not be so easy to implement.
Rejecting a working patch though is an entirely different matter.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sun Oct 01, 2006 1:11 pm Post subject: |
|
Hey
byuu, I think it would be cool to have the emulator auto-revert to
window mode when you hit escape in fullscreen. The way it is now, I
have to "set as active" each time I want to go back to window mode to
tweak some video settings. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 1:28 pm Post subject: |
|
Esc
does switch to windowed mode when in fullscreen. If you're not using a
WIP, maybe you're just not understanding how switching works between
the two in the last release... |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sun Oct 01, 2006 6:03 pm Post subject: |
|
AS An aside, reverse stereo is only valid in a DOS port.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sun Oct 01, 2006 9:19 pm Post subject: |
|
I
am using a wip, but what happens when i hit escape is the only thing
that I see on the desktop is the configuration screen. I have to go
into that and set window as active to see the game display. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 01, 2006 9:36 pm Post subject: |
|
Sorry, I don't have that problem on any of the four computers I've tried bsnes on, so I wouldn't know how to fix that. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 02, 2006 3:14 am Post subject: |
|
"S" (J) games that don't begin with "Super" tested. 1 bug found.
*Street Racer (J) - track area flickers to wrong coordinates. Does not
occur in .016, but does occur in all .017 versions. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 02, 2006 3:35 am Post subject: |
|
Congratulations
on finding the 832nd reversion due to sCPU. If and when I ever get sCPU
caught up to bCPU, you can bet I'll never be rewriting that code again. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 02, 2006 8:14 am Post subject: |
|
But we still think youre doing an awesome job byuu 
I read some awesome news on nesdev, blargg has finally started on the pal nes timing tests 
hopefully soon we will have a pal and pal60 filter  |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Oct 02, 2006 8:41 am Post subject: |
|
I
figured out what's causing the problem byuu. In my windowed mode in
bsnes, I have a manual screen res set of 1024x896. My fullscreen mode
is also set to the same res (I use powerstrip to add custom res modes
to my video card). When I escape out of fullscreen mode, this display
is invisible and I have to "set as active" for it to become visible. If
I uncheck manual res and use one of the default res multipliers, the
problem stops. Conversly, if I change my fullscreen mode to a standard
res, the problem also stops. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Oct 02, 2006 3:42 pm Post subject: |
|
FirebrandX wrote: |
...I
use powerstrip to add custom res modes to my video card). When I escape
out of fullscreen mode, this display is invisible and I have to "set as
active" for it to become visible. If
I uncheck manual res and use one of the default res multipliers, the
problem stops.Conversly, if I change my fullscreen mode to a standard
res, the problem also stops. |
User error. no bug filed. bug closed.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 02, 2006 4:59 pm Post subject: |
|
FitzRoy wrote: |
*Street Racer (J) - track area flickers to wrong coordinates. Does not occur in .016, but does occur in all .017 versions. |
To those of you who don't think cycle/bus accuracy is needed for SNES
emulation... here is yet another example of a game that fails when it's
off by more than 4 clock cycles.
HDMA triggers on the first opcode cycle edge where HCLOCK >= 1106.
HDMA bus sync then begins, and one last CPU opcode cycle is executed.
This puts HCLOCK at 1112 - 1118, depending on the next opcode's memory
access speed. With sCPU not having HDMA bus sync timing, it performs
the HDMA at 1106 each time. This 6-12 clock difference causes the track
to flicker. However, if you always execute HDMA at HCLOCK >= 1118,
the problem goes away. But then you have new problems in other games
because you might not have enough time to complete HDMA transfer before
hblank ends. So you need to at the very least, delay HDMA transfer for
one CPU cycle after it begins.
I don't really know how this could happen, since 1106+ is hblank
anyway... and the screen redraw happens at HCLOCK=256 on the next
scanline. I didn't disassemble any of the game code to see what it was
doing. I had a feeling it was related to HDMA bus sync timing, and I
was right. I'll try and add in HDMA bus sync timing tonight, and hope
it doesn't break Wild Guns like in bCPU.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Oct 02, 2006 5:36 pm Post subject: |
|
funkyass wrote: |
User error. no bug filed. bug closed. |
Incorrect. It is either an error in how the video card reverts from a
custom res, or how the emulator does. I made no error at all because
the emulator ALLOWS for custom resolutions, not to mention the fact
that my custom res works perfectly fine, its only on escape that the
window version comes up invisible and has to be reset as active. Thank
you for being a jerk.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 02, 2006 6:30 pm Post subject: |
|
Battle Blaze (J):
Correct:
Code: |
* w4200=81 0000 0000 @ <182, 494>
* w4200=91 0000 0000 @ <182,1276>
* -HIRQ @ <183, 10>
* w4200=81 0000 0000 @ <183, 680>
* w4200=91 0000 0000 @ <184, 52>
* -HIRQ @ <185, 10> |
Incorrect:
Code: |
* w4200=81 0000 0000 @ <183, 108>
* w4200=91 0000 0000 @ <183, 884>
* -HIRQ @ <183, 886>
* -HIRQ @ <184, 10>
* w4200=81 0000 0000 @ <184, 248>
* w4200=91 0000 0000 @ <184,1030>
* -HIRQ @ <184,1032>
* -HIRQ @ <185, 10>
* w4200=81 0000 0000 @ <185, 394>
* w4200=91 0000 0000 @ <185,1170>
* -HIRQ @ <185,1172>
* -HIRQ @ <186, 10> |
My recent tests indicate that toggling HIRQ from $4200 triggers another
IRQ. Battle Blaze suggests it doesn't. That, or there's something evil
about the HIRQ occuring at HPOS=0. My code doesn't handle the 14-clock
delay between the IRQ timing and core timing very eloquently.
I'm obviously missing something as Overload seems to have it right in SNEeSe.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Oct 02, 2006 6:31 pm Post subject: |
|
byuu wrote: |
The
only patches I haven't really added are some of kode54's, such as
7-zip+RAR (due to the formats being stupid and placing additional
licensing burdens on my source code) |
I'm not sure what licensing burdens you speak of. If I recall, 7-Zip
falls under the LGPL, similar to SDL which you already use. The UnRar
source code is under an even looser license, which is basically "Do
whatever the hell you want, as long as you don't try to reimplement the
compression utility." I also added compile time options for disabling
them.
byuu wrote: |
WaveOut support (DirectSound works just fine for 100% of people so far...) |
My latest mess of changes does not include WaveOut support. I only use
it in my own emulator because it, like kernel streaming, supports
outputting variable sized packets, in case the emulator should ever
decide to vary a frame by one or two samples. That wouldn't really
matter, except that I also use the sound output for speed regulation,
and I want it to wait on whole frames, no matter how many samples a
frame may be. It's probably easier for DirectSound code to just
Sleep(1) until the buffer has at least N samples free for the next
frame or so worth of audio.
byuu wrote: |
and a few minor things due to there being far too many changes. |
The only other useless change I can think of is using an OLE object to
import that JPEG logo. Since I don't even use
OleInitialize/CoInitialize or whatever before importing that IPicture
object, I'm not even sure what the problem is, other than maybe going
to way too much trouble just to keep your old About dialog background.
Although I suppose it could be further trimmed to unload the OLE crap
as quickly as possible, by copying the bitmap from the IPicture to a
newly created offscreen bitmap instead of keeping it resident. It may
even be possible to dupe or increment the reference count on its
HBITMAP, but I doubt it.
byuu wrote: |
Anything
else is just due to time. I have a lot going on in life. My hobbies
include: programming, emulation, translation, learning foreign
language, electrical engineering and music; I sleep too much and I work
full time. |
All acceptable. Especially considering that none of my changes affect the core.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 02, 2006 6:59 pm Post subject: |
|
I
decided that the about image was too much effort, and even as a JPEG it
was adding to filesize. So there was no reason to keep it. I'm not big
on OLE for the same reasons I'm not big on MFC. It's more my own
personal dislike for them more than anything rational. No big deal, the
new about screen looks fine, and uses the already included icon on it
at 48x48. Looks really sharp. I don't know who drew that old picture
anyway to give proper credit or ask permission to use it.
Ok, then the licensing of RAR and 7-zip don't bother me. But I'd rather not add them for a few other reasons:
- size. adds to source code size and executable size. adds to the
former regardless of compile-time flag, and I'd have to turn them on
for official releases anyawy, otherwise what's the point of it being
there?
- annoyance. I don't like the formats, and I already support ZIP. I
don't want to encourage people to uses 7-zip and RAR, and start bugging
other emulator authors about why they don't add these formats since
bsnes has them.
- more annoyance. the only reason people care about even more
compression is because they're trying to hoard the entire GoodSNES set,
and are too stupid to realize that the 1GB of space savings max equates
to about ~$1 worth of hard disk space, or 30 cents more worth of DVD-R
space. and since this is primarily used for the sake of distributing
ROMs, it would look bad for emulators to support them. I feel the same
way about ZIP, but I gave in because literally everybody has their ROMs
in ZIP format. at least ZIP has been around for 10 years or so already.
WaveOut stuff... yeah, Sleep(1) works really well, and doesn't cause
any issues on anyone's system so far. It just seems good enough. I
could always add the WaveOut / DSound Notification stuff as derivative
audio wrappers (eg has its own derived Audio class). Then the user can
select the playback device they like from the config file. I just saw
no reason to add these two to my main audio playback since it works
pretty good in nearly all cases so far.
There's also the ctrl+alt+delete fix you added for D3D that I need to
add in there. It's on my backlist of things to do. I have about 300 of
those to work through at this point x.x
Anyway, I don't want to seem unappreciative of your help. You're one of
three people who have actually submitted code to me. Power of open
source, indeed. I'll try and add as many of your contributions as
possible.
---
Side note, I verified DMV27's finding. Mega lo Mania is due to Winter
Olympics fix. It's either one or the other until the dot-based renderer.
That leaves us with:
Battle Blaze (J) - horizontal line issues on title screen
- IRQ issue. Not sure if I can fix this, but I'll try.
Jumbo Ozaki no Hole in One (J) - name screen gfx corrupt
- Timing issue. Also not sure if I can fix this.
Koushien 2 (J) - sometimes the sound stops and game hangs
- S-SMP opcode error? I doubt I can fix this, it happens way too far
into the game with a log file >2gb in size. Occurs at different
times during each run, as well.
Mega lo Mania (J, E) - horizontal line issues during intro
- need sPPU.
Street Racer (J) - track area flickers to wrong coordinates
- I can most likely fix this by the weekend.
Uniracers (E, U) - 2 player mode issues
- need sPPU. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 03, 2006 3:58 am Post subject: |
|
Got
the adapter. All kinds of testing going down up in here. Checked on my
possibles list first. Miraculously, no new bugs were found.
First we have the "leftmost vertical line appears black/transparent"
issue. This was the most prevalent on my list, and usually occured when
some kind of text box was using a transparency. Just a few of many
games showing this:
*Captain Tsubasa IV (J) - ingame when bottom map shows up
*Doraemon 3 - Nobita to Toki no Hougyoku (J) - intro
*Popeye - Ijiwaru Majo Seahug no Maki (J) - title screen
This line occurs on bsnes and has been confirmed on the real thing. ZSNES ends up being wrong on this one.
Next we have some oldies that appear to be the same bug.
*PGA Tour Golf (J, U) - little flickering box on bottom left
*Yuujin Janjuu Gakuen 2 (J) - little flickering box on bottom right
*Zan III Spirits (J) - flickering dots on wolfteam logo
These have been confirmed to not occur on the real snes. bsnes had them
broken for a while, but a recent wip fixed them (dma bus syc?), and
interestingly, they are still fixed in .017.15
Here's some stuff that looked like bugs but were confirmed to occur on a real snes:
*The King of Rally (J) - missing/flickering textures at race beginning (zsnes wrong)
*Captain Tsubasa J (J) - parts of goal disappear when stuff comes in front (zsnes wrong)
*Gambling Hourouki (J) - Character portraits blink black during effect (zsnes wrong)
*Gegege no Kitarou (J) - possible mosaic issue on left side
*Great Battle IV, The (J) - in gameplay, flickering garbage for a split second at top of screen
*Jissen Bass Fishing Hisshouhou in USA (J) - line of water shows through boat (zsnes wrong)
*Kamen Rider SD (J) - bikes flicker heavily when ontop of eachother (zsnes wrong)
*Pop'n Twinbee (Sample) (J)- fails to load
*Takeda Nobuhiro no Super League Soccer (J) - top horizontal line during gameplay looks odd
*Tom and Jerry (J) - far right of first level has messed up vertical line
*Top Management II (J) - when car comes in, it is under line
*Sim City (J) - edges of of screen mess up when you scroll any direction
Next, I tested Goodbye, Anthrox (PD). You're right. 0-224 displays for
this rom what a real snes displays for it. I now realize that a lot of
homebrews were probably never tested on real hardware, but on
yesteryear emulators. Anyway, bsnes should still be outputting what the
real snes outputs. The hclock breaking point list is now as follows:
*T2 - The Arcade Game - 0-1054 works, 1055-1096 breaks
*Prince of Persia 2 - 0-182 breaks, 184-1096 works
*Goodbye, Anthrox - 0-224 works, 226-1096 breaks
*Might and Magic II - 0-216 breaks, 218-1096 works
*Taz-Mania - 0-140 breaks, 142-1096 works
That now makes the most determinable window of accuracy 218-224 for all known games to work.
Lastly, Super Mario Kart has regressed with .017.015 as you warned it might. I've added it to the list. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 03, 2006 5:17 am Post subject: |
|
Quote: |
Miraculously, no new bugs were found. |
o_O
What in the hell are the odds of that? Man, awesome work determining which games to not
mention to me as possible bugs. With all of those games to look at at
once, I may very well have snapped, heh. Especially if after each one I
found out the real SNES was supposed to act that way x.x
Quote: |
Lastly, Super Mario Kart has regressed with .017.015 as you warned it might. I've added it to the list. |
Keep in mind, I still don't consider this a bug with bsnes, nor of its' emulation of the base SNES hardware, but with the DSP-1 emulation lacking timing. DSP-1 calculations are completing way too fast (instantly, in fact). This is throwing off timing. I doubt this will ever be fixed.
The same problem is in the Cx4 and DSP-2. Games run too fast when
special chips that had timing delays on real hardware are used.
Nonetheless, you're free to keep listing it. I might make a more clear
note somewhere on my site indicating that I am not counting nor
interested in bugs on special chips, unless they are related to base
SNES emulation in some way (can be difficult to determine, I know).
Wow, all of those games and no errors... seriously, what are the odds?
218-224 is very narrow. Should I move the hclock test into the clock
tick, instead of in the opcode edge? It will probably slow down the
emulator by 3-5%, but will make results much more stable.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 03, 2006 7:25 am Post subject: |
|
Oh
wow, found a major simplification. There's no need to have separate
routines to sync DMA, HDMA and HDMA init events. I can actually combine
all of them into one global DMA bus sync event, and then just make HDMA
and HDMA init check and see if DMA bus sync has already begun. If so,
just perform the HDMA/init immediately, otherwise perform bus sync
before performing HDMA.
Seems to work ok, though
I can't guarantee HDMA timing is perfect, especially not when DMA is
active when the HDMA event begins.
Had to move HDMA trigger position forward from 1106 to 1110 to fix
flickering with Street Racer, but it seems to work fine now. I will
need to investigate further to see why it needs a later value than
bCPU. I consider this one "half fixed" for now.
Wild Guns still works, unlike with bCPU, so this approach appears to be better.
Super Mario Kart still flickers, and I still don't care.
Zan 3 Spirits and Yuujin 2 still work, with no flickering dots /
garbled boxes. The girl flickers in the intro, but I think she's
supposed to, as it's showing her "transform" into that catgirl thing.
Quote: |
Next,
I tested Goodbye, Anthrox (PD). You're right. 0-224 displays for this
rom what a real snes displays for it. I now realize that a lot of
homebrews were probably never tested on real hardware, but on
yesteryear emulators. |
Perhaps you'll trust what I say in the future :P
224 doesn't work well for me, it still flickers. I left it at 256 for
now, as I'm not too concerned about homebrew at this time. This PPU
HCLOCK stuff is identical to ZSNES/SNES9x' CPU execution ratio stuff.
Ugly hacks >_<
If I can get Koushien 2 and Battle Blaze fixed without breaking
anything else, I'll get a new version out and try and start on sPPU
(what I'm going to call the dot-based renderer).
My polymorphism code takes a significant speed hit (~10%) by not
allowing inlining between objects, but I think I may just have to turn
that on so that I only need one binary release that allows one to
toggle between bPPU and sPPU at runtime (and while we're at it,
bCPU<>sCPU and bSMP<>sSMP).
Lastly, I'm getting ~119.5fps on demo_mode3.smc, whereas v0.017
official ran at ~126fps. Looks like the next version speedhit won't be
so serious after all, thanks to lots of code inlining and optimizations
to sCPU.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Oct 03, 2006 8:25 am Post subject: |
|
wow great work guys!!
i can also confirm that any character flickering or disapearance in
yuujin2 also happens on hardware, so thats definatily not a bsnes
problem
hope those wrongly hacked/fixed games in zsnes get their bugs back 
I was wondering if anyone could document those ingame bugs? I dont have
any hosting to hold them, byuu, maybe you could host the list +screens
perhaps in your documentation section?? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 03, 2006 12:36 pm Post subject: |
|
K, I removed Super Mario Kart.
byuu wrote: |
224 doesn't work well for me, it still flickers. |
Appears to have gone down to 222 before breaking with the new wip 
Also, hate to bear bad news, but it looks like Kamen Rider SD (J) broke
after .017.13. At least, it no longer works in .017.15 and .017.16
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 03, 2006 4:08 pm Post subject: |
|
Quote: |
Also,
hate to bear bad news, but it looks like Kamen Rider SD (J) broke after
.017.13. At least, it no longer works in .017.15 and .017.16 |
Well, thanks for giving me a moment to fix it before adding it to the buglist at least :P
Code: |
diff --unified --recursive bsnes_v017_wip13/src/smp/ssmp/ssmp.cpp bsnes_v017_wip15/src/smp/ssmp/ssmp.cpp
--- bsnes_v017_wip13/src/smp/ssmp/ssmp.cpp Tue Aug 29 06:20:06 2006
+++ bsnes_v017_wip15/src/smp/ssmp/ssmp.cpp Thu Sep 28 02:45:20 2006
@@ -13,7 +13,10 @@
}
void sSMP::power() {
- memset(spcram, 0x00, 65536);
+ for(int i = 0; i < 65536; i += 64) {
+ memset(spcram + i, 0x00, 32);
+ memset(spcram + i + 32, 0xff, 32);
+ }
reset();
} |
Reverted that change to always initialize all of SPCRAM to 0x00 and it
works fine. Either bsnes is encountering another S-SMP bug (possibly
related to Koushien 2), or bsnes is getting something right that other
emulators are not, thus breaking the game when this pattern is in
SPCRAM. It's probably the former, but for now SPCRAM initializes to
0x00.
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Wed Oct 04, 2006 4:58 am Post subject: |
|
byuu wrote: |
I
decided that the about image was too much effort, and even as a JPEG it
was adding to filesize. So there was no reason to keep it. I'm not big
on OLE for the same reasons I'm not big on MFC. |
Huh, comparing OLE to MFC. Well, whatever. For some reason, this
reminds me of how a certain BitTorrent client author won't include URL
drag-and-drop support in his software because of the OMG XBOX HUEG
memory bloat that appears just after the necessary CoInitialize() call.
(In this case, the project is already using something else COM-based,
namely DirectX.)
byuu wrote: |
-
annoyance. I don't like the formats, and I already support ZIP. I don't
want to encourage people to uses 7-zip and RAR, and start bugging other
emulator authors about why they don't add these formats since bsnes has
them. |
All of my crap is gzipped, I only converted a few files to these
formats for the sake of testing the compression support. In fact, I
don't really know why I bothered to add it in the first place. 
byuu wrote: |
-
more annoyance. the only reason people care about even more compression
is because they're trying to hoard the entire GoodSNES set, and are too
stupid to realize that the 1GB of space savings max equates to about
~$1 worth of hard disk space, or 30 cents more worth of DVD-R space.
and since this is primarily used for the sake of distributing ROMs, it
would look bad for emulators to support them. I feel the same way about
ZIP, but I gave in because literally everybody has their ROMs in ZIP
format. at least ZIP has been around for 10 years or so already. |
I'm not sure how it's 30 cents more worth of DVD-R space since the
whole set fits on a DVD-R either way, unless OMG WOW now you can cram
more consoles' worth of merged and compressed ROM sets onto the same
disc.
byuu wrote: |
WaveOut
stuff... yeah, Sleep(1) works really well, and doesn't cause any issues
on anyone's system so far. It just seems good enough. I could always
add the WaveOut / DSound Notification stuff as derivative audio
wrappers (eg has its own derived Audio class). Then the user can select
the playback device they like from the config file. I just saw no
reason to add these two to my main audio playback since it works pretty
good in nearly all cases so far. |
On a side note, kernel streaming method works with event notification
per audio packet you feed into it, and that notification receives full
precision time slices even without setting the timer resolution
manually. At least, when I was using kernel streaming in my NES
emulator, it didn't need vsync to output almost a smooth 60fps, while
WaveOut mode outputs in bursts and requires vsync to smooth out the
frames.
byuu wrote: |
There's
also the ctrl+alt+delete fix you added for D3D that I need to add in
there. It's on my backlist of things to do. I have about 300 of those
to work through at this point x.x |
I think that's the only change in the D3D display code, so you can just replace the source file.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 04, 2006 6:27 am Post subject: |
|
Ok, reverted the SPCRAM initialization pattern, which should fix Kamen Rider SD.
Verified DMA timing steps, I had them right. Still need to verify
HDMA/HDMA init, but they're almost definitely the same anyway.
Also, I noticed the spc700.txt doc by anomie on romhacking.net was more
recent than mine, and had info on $00f0 - TEST o_O
So, went ahead and added emulation for 5 out of 8 of these bits.
Notably, the CPU speed control bits and the RAM write enable bit. The
other three aren't well understood enough to add support for them just
yet.
Now, the CPU speed control in the S-SMP means the SMP core is taking a
significant speed hit to support this register. ~5% total speed hit,
though I can probably get that number down a little with some more
optimizations. I know the register is never used by any games, but you
know how I am. I added support for it anyway.
Note that the WIP doesn't like my inlining combination and is taking a
much more significant speed hit with global optimizations turned on, so
the WIP is ~13% slower than the last one.
Quote: |
On
a side note, kernel streaming method works with event notification per
audio packet you feed into it, and that notification receives full
precision time slices even without setting the timer resolution
manually. At least, when I was using kernel streaming in my NES
emulator, it didn't need vsync to output almost a smooth 60fps, while
WaveOut mode outputs in bursts and requires vsync to smooth out the
frames. |
If you wouldn't mind turning that into a compatible derived Audio
class, I'd love to add this as an option into bsnes :)
It'll be drop-in and compile, so you don't have to worry about me not
adding the code this time. No problem if you don't have the time /
desire / patience to do this.
Although, I wouldn't want to do this if it requires 3rd-party libraries
/ loading a special .sys driver into the kernel space / Windows DDK to
compile / something else crazy like that.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 05, 2006 9:08 pm Post subject: |
|
All remaining "S" (J) games tested. No bugs found.
However, more hclock fun. "Super SWIV (J)" screws up on its title
screen from 0-284. Adding to that, "Super F-1 Hero (J)" has a
flickering line during gameplay which actually happens on the real
system. But I can't seem to get any hclock setting to look the same
way, because the line actually spans two horizontal lines and shifts
around differently. It's really odd, and probably will only look the
same with a pixel-based renderer. Anyway, if we ignore PD carts, it
appears the next best thing is around 300.
Due to the results of my possibles testing, I went ahead and confirmed
that the old Hungry Dinosaurs bug was indeed a bug in bsnes, so no
worries about leaving that fixed.
Lastly, if Nach reads this thread, the following roms are suspected to
be PD roms erroneously in NSRT's database. I say this because they all
have porn in them, and they're also not on Overload's list.
Riverse Kids (J)
SM Choukyoushi Hitomi - Bangai Hen 2 - Maki no Love Love Panic (J)
SM Choukyoushi Hitomi - Bangai Hen (J)
SM Choukyoushi Hitomi (J)
SM Choukyoushi Hitomi Vol. 2 - Trial Version (J)
SM Choukyoushi Hitomi Vol. 2 (J)
SM Choukyoushi Hitomi Vol. 2 Remix (J)
SM Choukyoushi Hitomi Vol. 3 - Test Version (J) |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 05, 2006 9:34 pm Post subject: |
|
I checked my DB none of them was dumped by anyone on my team.
I do remember hearing how some games were from some crazy magazine.
Are these those?
If you think they should be removed, I'll see to that.
_________________
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: Thu Oct 05, 2006 9:41 pm Post subject: |
|
I
just figured Nintendo would never license anything with that kind of
content. And if they're from a magazine, that would essentially make
them... a commercialized homebrew? Its existing in tangible form makes
it no more deserving of being included. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 05, 2006 10:29 pm Post subject: |
|
Quote: |
All remaining "S" (J) games tested. No bugs found. |
Hooray!!!!!!!!!!!!!!!!!!!!!!!!!!!! Five more to go, and no more Japanese hell!
Thanks for testing all of those awful games, FitzRoy :)
I believe the CIC pretty much eliminated pirate carts on the SNES. Of
course, I could be wrong. But compared to the NES and Genesis, where I
know of hundreds of pirate carts per system... I have to say, it
definitely helped cut down on them. Which, while it sucks for homebrew
(have to ruin a cart to make your own flashcart from a blank PCB), I'm
glad they did. Those games are always of ass quality, have crazy weird
banking protections, and tend to have the same programming quality as
PD ROMs.
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Thu Oct 05, 2006 10:30 pm Post subject: |
|
Unrelated to what you guys are talking about:
D4s released a German translation of Breath of Fire 2 featuring many modifications and additions.
D4s said this about this release "oh, and the game will also reliably
detect if its running on a real snes and will display an additional
warning telling the user that the patch is freeware and not be sold.".
Considering the goal bsnes is to behave as closely as possible to a
real SNES, I figure it should then display that warning that only shows
on real hardware ? It doesn't at the moment...
And I have no idea how d4s made that "real SNES check", but I can ask
him, or you can do it yourself if you prefer...
Links:
http://www.ultrasnes.de/snes.html
http://bof2.blogspot.com/
Your opinion ? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 06, 2006 1:20 am Post subject: |
|
I
asked on the ROM hacking board how to get in touch with him. If you
can, please ask how he determined the presence on an emulator with
bsnes. Also please ask him if the audio is supposed to crackle two
times very softly during the second intro character screen (the angel
girl). It does in all emulators at present, but I'm thinking it's a
flaw with the original audio (or its transcoding to the SNES) and not
in emulators.
If he doesn't want to say how he
detected bsnes, then I have no choice but to attempt reverse
engineering. And I know d4s wouldn't have made that easy :)
Anyway, determining the presence of an emulator isn't too hard. I can
think of quite a few ways to do that, which will never be possible to
emulate. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Fri Oct 06, 2006 1:55 am Post subject: |
|
byuu wrote: |
Quote: |
On
a side note, kernel streaming method works with event notification per
audio packet you feed into it, and that notification receives full
precision time slices even without setting the timer resolution
manually. At least, when I was using kernel streaming in my NES
emulator, it didn't need vsync to output almost a smooth 60fps, while
WaveOut mode outputs in bursts and requires vsync to smooth out the
frames. |
If you wouldn't mind turning that into a compatible derived Audio
class, I'd love to add this as an option into bsnes 
It'll be drop-in and compile, so you don't have to worry about me not
adding the code this time. No problem if you don't have the time /
desire / patience to do this.
Although, I wouldn't want to do this if it requires 3rd-party libraries
/ loading a special .sys driver into the kernel space / Windows DDK to
compile / something else crazy like that.
|
- It requires the DDK, or at least some very minor parts of it to compile. I think. Hmm.
- It requires at least Windows 2000 to operate.
- It
only supports sample rates and formats native to the device, so all
those AC'97 devices out there will be limited to 48000Hz 16-bit stereo.
- If
the device only supports a single output, such as case with AC'97
devices, it will effectively block all other output. Or, if the drivers
are really spoony, its own output will be blocked the instant anything
else tries to output.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 06, 2006 4:41 am Post subject: |
|
byuu wrote: |
Hooray!!!!!!!!!!!!!!!!!!!!!!!!!!!! Five more to go, and no more Japanese hell!
Thanks for testing all of those awful games, FitzRoy  |
w00t! No problem. I'm most excited about understanding the menus from
here on out. Should be faster to get into gameplay.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 06, 2006 6:05 am Post subject: |
|
Ok,
d4s replied. Looks like I have to disassemble his work to find out how
he's detecting bsnes, fun. The sound pop is due to wave -> brr
conversion. Not a bug, thankfully.
Nothing
emulation related for now. I instead rewrite huge chunks of libstring,
renamed libvector to libarray, and added a new libvector that works
with objects instead of memory buffers (libarray is now the memory
buffer template class). I then merged all of that into bsnes and got
everything mostly working again. Tons and tons of internal changes.
My next task is libconfig. I'm thinking of using templates to specify
type, instead of passing parameter types to the functions. This should
get rid of get<>sget and set<>sset ugliness.
Huge thanks to Nach, many of my libraries are dramatically simplified now. They should also leak less memory, as the string class even has a valid copy constructor now. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Oct 06, 2006 9:26 am Post subject: |
|
Did some testing of the memory leakadge.
In bsnes .17 memory usage is higher and keeps rising and rising
in the latest wip memory usage is higher when idle, but lower with a game loaded.
also the wip hardly uses any more ram during gameplay whereas .17 keeps eating more ram every few seconds.
When i open bsnes it uses about 14 mb, when i load dkc2 it uses 22 mb, when i unload dkc2 it uses 18 mb
so bsnes is not releasing everything it created for that cartridge session
tested some more, when opening the "load diagologue screen" memory
ususage obviously increases, but after closing it, not all ram is
released, so memory usage is higher.
but when i open de dialogue again it has the exact same high value as
the first time, tried this 10+ times, and everytime the low ram usage
is a different amount but the high ram usage is always the same
wierd? |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Fri Oct 06, 2006 3:08 pm Post subject: |
|
byuu wrote: |
Ok, d4s replied. Looks like I have to disassemble his work to find out how he's detecting bsnes, fun. |
He refused to share ? Aww, that's uncool of him. Although he's
certainly all proud of his work, hoarding harmless info for no reason
is pathetic. It will only result in making you waste your time...
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Oct 06, 2006 5:34 pm Post subject: |
|
I
would love to see Kernel Streaming implemented in bsnes (even in
ZSNES).ZSNES SVN builds do not have this option.Is this available only
in your custom builds of ZSNES? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 06, 2006 6:31 pm Post subject: |
|
Quote: |
It will only result in making you waste your time... |
Exactly right, I could be fixing bugs that affect real games now
instead. But I don't mind a challenge. And it looks like he has a sense
of humor, at least. Makes it more interesting.
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Fri Oct 06, 2006 6:39 pm Post subject: |
|
Haha. :p
Good luck with that, although I don't think it'll be all that challenging for you... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 06, 2006 6:47 pm Post subject: |
|
byuu, did you see that badass snes dev unit? How useful would that be for an emulator author? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 06, 2006 11:59 pm Post subject: |
|
Quote: |
byuu, did you see that badass snes dev unit? How useful would that be for an emulator author? |
It wouldn't, but you could buy me one anyway :)
Anyway:

I can't emulate his check. I won't give away the secret, so nobody
tries to remove that screen for the purposes of selling his translation
on a cartridge, but suffice to say it's something I figured he was
doing, and is one of the very few things I can never emulate properly due to absolutely massive difficulty compared to payoff. Of every SNES game ever released, not a single one relies on this behavior.
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Sat Oct 07, 2006 4:47 am Post subject: |
|
byuu wrote: |
Quote: |
byuu, did you see that badass snes dev unit? How useful would that be for an emulator author? |
It wouldn't, but you could buy me one anyway 
|
I'll chip in on it
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 07, 2006 5:00 am Post subject: |
|
Hehe, pretty sure he was joking. Guy says there's only four left in the world, which is why I was curious about its usefulness. |
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Sat Oct 07, 2006 12:11 pm Post subject: |
|
FitzRoy wrote: |
Hehe, pretty sure he was joking. Guy says there's only four left in the world, which is why I was curious about its usefulness. |
ahh damn, and I thought there was something he'd finally except for his great emu he has given us
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 08, 2006 3:44 am Post subject: |
|
Fixed a major memory leak with the new library -_-
Wasn't deleting the temporary object buffer copy. Memory usage dropped
by about 800kb after loading a ROM as a result.
FitzRoy wrote: |
tetsuo55 wrote: |
Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place
|
This is on my "to verify on hardware" list. One of the interlace fields
seems to persist rather than disappear during transitions, but I'd
hardly call it "all over the place." Maka Maka is another one.
|
Implemented a proper "clear line" routine for when display is disabled,
that now takes screen width and interlace field into account. All
interlace games should now clear the screen properly during transitions.
EDIT:

Not as bad as I thought it was going to be. F1 Grand Prix, Sink or Swim
and Battle Blaze all work. However, I'm now failing test_irq.smc.
Basically due to the trickery that is the +10 VIRQ, +14 H[V]IRQ
timeshifting. I'm no longer firing extra interrupts nor missing any
interrupts, but the IRQ trigger positions for VIRQs on the start of a
scanline is now off by exactly 8 clocks. Which is obviously a lot less
severe than before with Battle Blaze triggering multiple interrupts on
every scanline.
Also, I'd like to note now, Battle Blaze is buggy as hell. Even on real
hardware. The game locked up and died with corrupted palette data on
the final boss fight on my Super UFO. I also saw countless graphical
glitches on the map and in battles.
bsnes seems to play the last boss fight correctly, so perhaps it's open
bus related (the Super UFO somehow prevents open bus from functioning).
However, there's some shadiness when you beat an enemy and the soul
thing flies around. I think this is due to PPU mid-frame writes. A lot
of the graphical glitches are. I'm thinking, get test_irq.smc passing
again, and move on until sPPU is as compatible as bPPU.
So that leaves me with two more "fixable" bugs. Koushien 2 and Jumbo
Ozaki no Hole in One. Completely stumped on both at the moment.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 09, 2006 5:04 am Post subject: |
|
This game really frustrated me at first, but I figured out a trick to beat them all without much effort Didn't run into any game bugs like you, so maybe it is your copier. I was using the (U) version, btw. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 09, 2006 6:13 am Post subject: |
|
Yeah,
the sword stab takes them all out easy, excluding the last boss, who's
a bit harder. What a short game, huh? I'd be pissed if I spent $50 on
that game.
So, how about the soul floating around
scene? Are there blank scanlines in between it while its flying around?
It might just need a different HCLOCK value in bsnes if there aren't.
Who knows.
----------
Thanks to a genius observation by TRAC, I was able to finish
implementing proper IRQ timing. It should be virtually clock perfect,
excluding some unbelievable edge cases. Right now, bsnes is passing all of my tests, and still runs Battle Blaze + F1 Grand Prix + Sink or Swim :D
I lost more speed though, as a result. I'm now getting ~105fps, from
~125fps in bsnes v0.017. Sigh, just can't seem to keep that number up
there. Oh well, this pretty much gives me infinite precision, so even
if there are new IRQ findings (and there will be, it never ends), speed
should no longer be taking any beatings as a result of them. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 09, 2006 7:02 am Post subject: |
|
byuu wrote: |
So,
how about the soul floating around scene? Are there blank scanlines in
between it while its flying around? It might just need a different
HCLOCK value in bsnes if there aren't. Who knows. |
In bsnes, yes there are some strange issues during that effect, as well
as the last boss "coming apart" effect on the ending (same issue
probably). On the real system, these issues don't exist. You're saying
that despite your new IRQ fixes, these things still happen? If so, it
could be a separate issue. hclock doesn't seem to be affecting it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 09, 2006 4:51 pm Post subject: |
|
Well,
anomie and I have noted many mid-frame PPU writes in this game. The
authors of this game have apparently never heard of HDMA, and decided
to do all of their effects with much more costly HIRQs. I'll wait
for the dot renderer on this one, the title screen looks a lot better
now at least. Up to you if you want to consider it a bug. But at least
serious improvements to the IRQ handler resulted from the title screen
bugfix for now.
Now, remaining bugs:
Koushien 2 - same as always. Too much code to trace through (~2gb
worth). Exact position of error changes every time you play. No cleanly
written, C/C++ (no nested #defines) S-SMP (SPC700) emulation cores to
compare against. As it's the only game known to crash the SMP, it's
likely an obscure bug that would be hard to spot anyway. I've been
unable to fix it with about ~16-20 hours sunk into it thus far.
Jumbo Ozaki - has to be a CPU timing bug. Still need to double verify
HDMA timing (especially now with HDMA bus sync support readded), but
I'm pretty sure it's CPU related. Of that, it looks like the game sets
(regs.d & 0xff) != 0, which causes an extra math I/O cycle on all
direct accesses. Perhaps I'm adding the work cycle in some opcodes I
shouldn't be? Unfortunately, I can only test this one from home. I've
implemented my CPU core to spec with the 65c816 manual as best I could
read it, so hardware opcode timing tests will be needed to track this
down. Expect very slow progress since 90% of my time is spent at work.
Mega lo Mania and Uniracers - both waiting on sPPU. Hmm, doesn't look
like I can get any more fixes in before the weekend. Please go ahead
and test the latest WIP as a release candidate in that case. I'd like
to get v0.018 out on 10/14 for the two years in development mark for
bsnes.
Let me know if there's anything major that needs to be addressed before
another public release. Next release probably won't be until 01/07 or
so (and will probably not have any of sPPU included with it).
Lastly, I might revert the Street Racer fix, if my testing reconfirms
HDMA triggers at HC=1106 (anomie's tests indicate it starts at
HC=1112). If I do, then that game likely also suffers from slight CPU
opcode timing flaws.
Can someone please get me total counts for number of real SNES
cartridges (sans revisions of the same game and betas) released per
region? Perhaps a count with revisions for the hell of it as well. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 09, 2006 5:49 pm Post subject: |
|
great work, as far as i know no mayor bugs need to be fixed so if i dont find anything new your release is a go.
ill try to look at the total game list tommorow if fitzroy doesnt beat me to it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 09, 2006 6:50 pm Post subject: |
|
Mmm, an anniversary edition. Any chance of these things being added?:
"Auto-detect" for overscan
screensaver suppression in windowed mode (although you said you didn't know how)
I might add the Battle Blaze to the list, if only because hclock
doesn't affect it. I'm definitely leaving out all of the hclock
affected games, since they can be corrected individually at least by
messing with the hclock option. And sPPU will wipe these all out
anyway, so thank god for that. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 09, 2006 7:44 pm Post subject: |
|
Its
pretty cool that bsnes is only 2 years old, basically made by 1 guy,
mostly hardware accurate and as far as we know 99.something% compatible
with non special chip games  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Oct 09, 2006 10:47 pm Post subject: |
|
byuu wrote: |
two years in development |
And it's been maturing amazingly well. Congrats in advance! 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Tue Oct 10, 2006 7:20 pm Post subject: |
|
byuu wrote: |
Can
someone please get me total counts for number of real SNES cartridges
(sans revisions of the same game and betas) released per region?
Perhaps a count with revisions for the hell of it as well. |
http://www.nintendo.com/gamelist?category=classic
here a link from nintendo.com. My stupid work computer doesn't have
acrobat reader on it so I can't open and give you a count.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 11, 2006 4:59 am Post subject: |
|
Quote: |
Jumbo Ozaki no Hole in One (J) - name screen gfx corrupt |
No longer. I was correct, a CPU timing bug. A really embarassing one, too. CPU I/O condition 4 was wrong.
"Add 1 cycle for indexing across page boundaries, or write, or X=0.
When X=1 or in the emulation mode, this cycle contains invalid
addresses."
bsnes code:
Code: |
void sCPU::op_io_condition4(uint16 x, uint16 y) {
if(!regs.p.x && (x & 0xff00) != (y & 0xff00)) { op_io(); }
} |
Correct code:
Code: |
void sCPU::op_io_condition4(uint16 x, uint16 y) {
if(!regs.p.x || (x & 0xff00) != (y & 0xff00)) { op_io(); }
} |
Slows down the CPU (not the emulator!) a good deal. It fixes Ozaki by moving the write into $0006 until after
the NMI that resets the value, other emulators were all executing it
before, so I figured bsnes was running too slow. It was actually
running too fast.
That was a major, major timing
bug to be missed for so long. I shall have to make a generic test ROM
to clock CPU opcode timings. I'm suspecting my store opcodes (sta
$nnnn,x) may be wrong. I don't currently force those to consume another
cycle, but the above says "or write". I'll make that my last test for
today.
I also added in the CPU revision 1,2 differences for HDMA init and DRAM
refresh trigger positions. But it isn't perfect, my HDMA init timing
test is still off by ~2-4 clocks.
But, don't celebrate too soon. I decided to revert the Street Racer
fix, at least until I can get this HDMA init timing test passing and
verify the HDMA trigger position on hardware against emulation. Much
like the Ozaki fix, I don't feel good about the Street Racer fix.
EDIT: yep, writes always consume the CPU IO condition 4 cycle. Fixed as well.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Oct 11, 2006 6:13 am Post subject: |
|
Tetsuo55 does the Bsnes just got more hardware accurate dance 
thats a great gift just in time for its 2 year birthday!! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 11, 2006 6:22 am Post subject: |
|
Heck
yeah! Awesome job, byuu. Both Jumbo and Energy Breaker now work at the
same time. That's never happened before. New wip seems solid... no
regressions. |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Oct 11, 2006 8:21 am Post subject: |
|
OK, you wanted a count of games from each region. Here's a count, using NSRT, plus a few new dumps not in the latest NSRT:
NOTE: The counts for games that don't include revisions, etc. are
surely off by a few, as I probably missed a few variants (I almost
missed a "doritos promo" variant of George Foreman's KO Boxing (U), for
example). So take those figures with a grain of salt.
Australia: 3
Brazil: 1
Canada: 1
China: 1
Europe (with revisions/betas/alternates/bioses): 581
Europe (sans revisions/betas/alternates/bioses): 533
France: 29 (28 not including revisions)
Germany: 44 (42 not including revisions)
Italy: 2
Japan: (with everything): 1715
Japan: (sans revisions/betas/alternates/bioses):1625
Japan & USA: 4
Japan, USA, Europe: 3 (all Super Gameboy BIOSes)
South Korea: 2
Spain: 11
Sweden: 2 (1 of which is a copier BIOS)
The Netherlands: 2 (1 of which is a beta)
Unknown: 130 (Pretty much all of these are betas or BIOSes or pirates. 1 sample ROM)
USA (with everything): 803
USA (sans revisions/betas/alternates/bioses): 733 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 11, 2006 4:34 pm Post subject: |
|
Thanks,
zidanax. That's actually really good news. The Japanese games (all of
which have been tested) make up more than every other region combined,
not to mention many of the other region games are just translations of
the Japanese versions (so they shouldn't have problems). So,
hopefully... no more than five bugs will be discovered with testing all
of the remaining games. Hopefully, heh.
EDIT: Battle Blaze can be removed from the buglist.
The game actually is supposed to only fire an IRQ every other scanline. The HIRQ routine consumes 2000+ clocks, with only 1324 clocks available on each scanline.
The game is writing to PPU register $210d (BG1 horizontal scroll
position) anywhere between HCLOCK = 100 - 280, and that's just what I
personally observed. The range could be even greater. I tested with
HCLOCK=768 (because I hate the game and didn't want to play it
repeatedly to find a good value) for PPU scanline render position, and
the effect worked just fine. You could probably get away with 300-400,
but I wouldn't push it much further than that.
So then, why the black scanlines? Because $210d requires two writes to
set the scroll register. What's happening is, my scanline renderer at
HCLOCK=256 (the default) is triggering right in between the two writes,
so the BG1 scroll register is completely off, causing it to render an
area where there are no tiles mapped, hence some of the scanlines get
black lines. On a real SNES, these late writes will be visible, but
will be much harder to notice. Basically, you'll either see 3-12 black
dots at the very leftmost edge of the screen on some scanlines, or the
scroll positions will be slightly off. But it will be very hard to
notice with the effect moving so quickly, and with TV horizontal
overscan cutting off most of it anyway. Amazing what crap NoJ's QA
program let slip through. Indirect HDMA would've worked just as well
for this effect, and in fact would've allowed twice the fidelity of the
wave pattern to be shown. And all without mid-scanline PPU writes.
With all of these HCLOCK ranges, there's no getting around it. I'm
basically going to have to make this a GUI option until I get a proper
dot-based PPU renderer in there. There are just too many games that
rely on different settings to work right :( |
|
NGEfreak New Member
Joined: 11 Oct 2006
Posts: 1
|
Posted: Wed Oct 11, 2006 7:03 pm Post subject: |
|
FitzRoy wrote: |
Lastly,
if Nach reads this thread, the following roms are suspected to be PD
roms erroneously in NSRT's database. I say this because they all have
porn in them, and they're also not on Overload's list.
Riverse Kids (J)
SM Choukyoushi Hitomi - Bangai Hen 2 - Maki no Love Love Panic (J)
SM Choukyoushi Hitomi - Bangai Hen (J)
SM Choukyoushi Hitomi (J)
SM Choukyoushi Hitomi Vol. 2 - Trial Version (J)
SM Choukyoushi Hitomi Vol. 2 (J)
SM Choukyoushi Hitomi Vol. 2 Remix (J)
SM Choukyoushi Hitomi Vol. 3 - Test Version (J) |
Those games are not PD. They are original pirate games.
See for example: http://page8.auctions.yahoo.co.jp/jp/auction/h42988253
If you are going to ignore those games, please also include Super 3D Noah's Ark in this list as well.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 11, 2006 8:06 pm Post subject: |
|
@byuu:
Interesting, I'll have to add it to the my hclock list. There are
really only two fixable bugs left then in Street Racer and Koushien 2.
Everything else is just dependent on a dot-based PPU.
NGEfreak wrote: |
FitzRoy wrote: |
Lastly,
if Nach reads this thread, the following roms are suspected to be PD
roms erroneously in NSRT's database. I say this because they all have
porn in them, and they're also not on Overload's list.
Riverse Kids (J)
SM Choukyoushi Hitomi - Bangai Hen 2 - Maki no Love Love Panic (J)
SM Choukyoushi Hitomi - Bangai Hen (J)
SM Choukyoushi Hitomi (J)
SM Choukyoushi Hitomi Vol. 2 - Trial Version (J)
SM Choukyoushi Hitomi Vol. 2 (J)
SM Choukyoushi Hitomi Vol. 2 Remix (J)
SM Choukyoushi Hitomi Vol. 3 - Test Version (J) |
Those games are not PD. They are original pirate games.
See for example: http://page8.auctions.yahoo.co.jp/jp/auction/h42988253
If you are going to ignore those games, please also include Super 3D Noah's Ark in this list as well.
|
Good info, thanks. At the very least then, these games should be given
a [unl] or something to denote this, as well as Noah's Ark. I think a
pirate is different in that a pirate is an official game or compilation
of games that are copied and resold illegally. Could be wrong. I don't
know how to feel about [unl] carts being included in the database. But
I think I would keep official test cart roms, store demo carts, and
official add-on bios files, remove pirates and copier bios, and remove
all BETA roms that saw official release. Many of the BETA roms we have
are unverifiable and could simply be bad dumps.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 11, 2006 8:34 pm Post subject: |
|
Quote: |
@byuu:
Interesting, I'll have to add it to the my hclock list. There are
really only two fixable bugs left then in Street Racer and Koushien 2.
Everything else is just dependent on a dot-based PPU. |
Pretty much. I'm debating adding hacks for bPPU to play those last two
games once I have a working sPPU. Since I already know sPPU will
prevent pretty much everything but Core 2 Duos from playing bsnes, it
seems like a good idea. The accuracy is there, if you can afford the power requirements.
I might also put off sPPU development until I get a nice C2D. I don't
want to have to stress out at the framerates at first, I can always
optimize later. That might be a while though, as I'm presently living
paycheck to paycheck.
Quote: |
I don't know how to feel about [unl] carts being included in the database. |
I really don't know about this anymore, myself. Official, released, for
sale carts should absolutely be in there. Other than that... I can see
reasons to index them, but the fact is many of these authors don't want
their works indexed in such a manner as to appease to ROM collectors.
However, it's needed for cartridges since ROM dumps lack PCB layout
info. I'm hoping that UPS and the anti-hard patching code I have in
mind will help cut down on this whole situation. You should be able to
embed your readme inside a UPS file, and there's an info section to put
authoring information in there. I'm hoping we can also disallow soft
patching when the UPS file is inside a compressed archive. It will help
prevent Cowering and co from just distributing patched ROMs as SMC+UPS
pairs. I don' think many fan translators would mind their patches as
standalone files in their own archives being distributed.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 11, 2006 9:50 pm Post subject: |
|
You
could make an argument for that. But there are a few games off the top
of my head that were developed with the intention of being released
commercially, and for various reasons, never were. Star Fox 2,
Apocalypse II, Corn Buster... However, indexing BETAs of games that
were released commercially is kind of pointless. I suppose the novelty
of differences from the final product can be interesting, but most of
the time these were near-finished games which were lent out to
magazines and shit, and thus, the difference between versions is more
likely to be bugs than game changes. Additionally, we have no way of
verifying what these games claim to be. There have been a lot of betas
that simply ended up being bad dumps of the official release, and we've
also had a lot of betas that are dumped improperly and need special
emulator fixes. Then you've got ones that don't even work at all. Take
Pop N Twin Bee (Sample) for instance. The damn rom doesn't work in any
emulator, or the real system, so aside from the internal naming, how on
earth do we know or trust what it is? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 11, 2006 10:25 pm Post subject: |
|
Funny
story, someone on romhacking.net actually posted a link to two SNES
tech demo ROMs. One wasn't running on any emulators so I decided to
take a look at it. Hmm, completely missing any trace of a header, just
like the SNES Test Program. But this time, even the reset vector was
0000! Curious.
As it turns out, the ROM was
actually a Gameboy game. Someone apparently tried loading it in bgb and
it actually worked. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Thu Oct 12, 2006 4:27 am Post subject: |
|
I
believe I found a bug in 0.017, either that or in the ROM/game (Don't
have the HW to test it out). The game in question is Robocop Versus The
Terminator (U).
Frame skip set to 1
When I entered game play by repeatedly pressing the B button (not using
the start button at all) it starts up with a black screen, but music is
still playing and I can still hear that regular game play is going on.
When I press the start button and enter game play I see the game play just like I do on snes9x 1.502.
I don't know If the pressing of the B button versus the start button is
a clue to the problem or just a coincidence, but 5 tries of each
yielded identical results.
Frame skip set to 0
The game play screen flashes like crazy and this is independent of what
button is used to enter the game play. In snes9x (as mentioned earlier)
the screen does not flash like crazy. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 12, 2006 5:11 am Post subject: |
|
Thanks
for the report. Flickering bug occurs in .017 but not .017.21. In other
words, it's been fixed in recent test WIPs. Lots of timing/IRQ
improvements since .017.
Last edited by FitzRoy on Thu Oct 12, 2006 5:12 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 12, 2006 5:12 am Post subject: |
|
This
is fixed in my WIP builds, but thanks. One more game to add to the
"fixed" list. So, that's 12 games fixed and 4 still broken. Should make
for a decent release :)
----------
I'm trying out some wild ideas with my base libraries. Specifically,
libvector is now using a giant shared memory pool. Objects are created
with the placement new operator, and deleted with explicit destructor
invocations. Both libvector and libarray now mimic the API of boost
smart_ptr style template classes.
Man, this version's really going to take a beating in terms of speed :(
Still should be trivial to get 60fps on an A64 3500+ or above, at least.
Ok, I asked about this a while ago, before we knew that sCPU and sSMP
would be as fast and accurate as they are... but how about I rewrite
bCPU and bSMP to opcode CPU emulators with somewhat weaker accuracy (no
worse than SNES9x, obviously), but greatly enhanced speed? I figure,
the timing and all that is still just as accurate, it's just the
synchronization between core components (CPU<>SMP, CPU<>PPU
and SMP<>DSP) will be a little fuzzier. And the benefit would be
that with lower system requirements, more people would be able to use
the software.
Opcode based cores could also one day lead to savestates. bsnes still
stays an experimental emulator that pushes for as much accuracy as is
possible in software, and yet can appeal to end users with virtually no
maintainence costs. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 12, 2006 6:08 am Post subject: |
|
Always first to express his opinion... is me!
I have a 2.4c Northwood that gets 80-115 fps in .017. This processor
debuted in 2003, and was the lowest end mid range model. My guess is
you could go as far as four years back and still have technology
capable of running bsnes at 60fps. With a frameskip of 1, you could go
back even farther for playability. I don't think there's any need to
cater to people who haven't upgraded their computers in five years,
especially at a time when computers are cheaper than ever. And you know
that as time goes on, even these people eventually upgrade. When that
happens, in another five years, who's still going to need a crippled
version? Savestates, however, are probably a better argument for this.
It's probably not what you want to hear, but special chips would be far
more effective at getting more users. Even if the emulation speed is
off, or its not completely accurate, or SA1 is too slow and you have to
use frameskip, we've heard more jabs about that than speed in this
thread. Star Fox, Super Mario RPG, and TG3K carry a lot of weight. A
lot of weight. TG3K alone needed a board filter for years just to stave
off the requests for this game. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 12, 2006 6:28 am Post subject: |
|
Quote: |
I have a 2.4c Northwood that gets 80-115 fps in .017. |
You'll get 60-95fps with v0.018.
Quote: |
It's
probably not what you want to hear, but special chips would be far more
effective at getting more users. Even if the emulation speed is off, or
its not completely accurate, or SA1 is too slow and you have to use
frameskip, we've heard more jabs about that than speed in this thread.
Star Fox, Super Mario RPG, and TG3K carry a lot of weight. A lot of
weight. TG3K alone needed a board filter for years just to stave off
the requests for this game. |
Again, savestates are technically impossible at present. I might try it
with an opcode-based core, but that'd be about it.
I don't mind adding DSP-3 and DSP-4 (even if they're not 100%
accurate), but I need generic classes that I can stick in bsnes first.
And you're going to have to try a lot harder to convince me to add SA-1 and SuperFX, sorry. Maybe when sPPU is out publically, all other games have been tested, and zero known bugs remain :)
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Oct 12, 2006 6:44 am Post subject: |
|
I
would appreciate the re-written opcode cores. I'm in college, so I
don't really have the money to spend on upgrading computers.
However, if it's going to take a lot of work to re-write the cores, I'd rather see work start on sPPU.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 12, 2006 7:14 am Post subject: |
|
byuu wrote: |
You'll get 60-95fps with v0.018 |
True, but I've got a Core 2 Duo e6300 sitting here waiting for a 7650gs
to be built. Because unlike bum kids, I enjoy computer games and
applications and am willing to work hard enough to afford this luxury.
And I don't bloody expect people like you to compromise your work so
that I can use it on my mother's 486. 
byuu wrote: |
And you're going to have to try a lot harder to convince me to add SA-1
and SuperFX, sorry. Maybe when sPPU is out publically, all other games
have been tested, and zero known bugs remain  |
I wouldn't ask for it any sooner. But in regards to creating a bigger
userbase, neither old computer users nor Koushien 2 getting fixed has a
thing to do with that. Star Fox, Super Mario World 2, and Super Mario
RPG are three of the most popular games on the system, and they're
quality, Nintendo developed games. Average joe, who has no idea what a
special chip even is, downloads your emu and none of them work. That's
that.
I also think your own forum would help, because people appreciate
community and an easy place to ask questions or discuss things with
organized threads. It helped zsnes and snes9x and it can help you.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Oct 12, 2006 9:22 am Post subject: |
|
I really doubt we are going to find any none ppu related bugs in the rest of the games.
my opinion is the same as Haze's and that is that all games every sold
on carts should be in the list, even if they are pirates.
that also means that all homebrew and patched stuff shouldnt be.
I have almost finished moving, soon i will be able to continue going
through the list of snes games, and then we should have finished
testing all know games.
at least untill someone starts redumping all roms correctly by dumping
each individual eeprom instead of reading the cart pins
I also vote for adding special chips and hardware before doing sPPU,
eventhough some stuff isnt fully known yet, at least you can add
partial emulation of what is known.
Then after sPPU is done there might be more info out there about how those special chips work... |
|
trebor Rookie
Joined: 23 Nov 2005
Posts: 10
|
Posted: Thu Oct 12, 2006 11:42 am Post subject: |
|
FitzRoy wrote: |
I
wouldn't ask for it any sooner. But in regards to creating a bigger
userbase, neither old computer users nor Koushien 2 getting fixed has a
thing to do with that. Star Fox, Super Mario World 2, and Super Mario
RPG are three of the most popular games on the system, and they're
quality, Nintendo developed games. Average joe, who has no idea what a
special chip even is, downloads your emu and none of them work. That's
that. |
Hi byuu,
In harmony with FitzRoy statement, just my humble two cents in
following this thread and bsnes for awhile now and concerning creating
a bigger userbase in discussing what features to add or/and fix; many
(most) "Average Joe" end users are playing or want to play the games
full screen.
While bsnes does have full screen support it unfortunately contains
screen tearing due to lack of (or buggy) vsync or/and triple buffering
support. While triple buffering support is present, it does exactly as
noted next to the option in the current public beta, cause problems
with sound.
If possible fixing triple buffering support so games can be played
without screen tearing would be a nice fix to make the emulator more
appealing.
Understandably, vsync and/or triple buffering can be forced/enabled at
the driver level - but again - many do not want to change or modify
video driver settings for the sake of an emulator.
Again, just giving my humble two cents on the topic.
-Trebor
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 12, 2006 2:33 pm Post subject: |
|
The
larger userbase thing was more to the point that it would be a nice
side effect of faster alternative cores for bsnes. It would also mean I
could worry a little less about speed. If someone complains I can just
refer them to the "fast" version instead of saying, "go use another
emulator."
As for triple buffering, that's one of
the many things I've asked for help on several times in the past. I
tried to add it in. Microsoft's piece of shit drivers always force sync
immediately, so the second I call device->Present(...), the emulator
is locked by the system until vblank, desyncing sound. If anyone knows
how to make Present queue in a buffer and only occur when one is
actually in vblank (without the need for a 1ms precision timer to
constantly poll the raster status of D3D), I'll add the code. This is
common sense stuff that seems omitted by Microsoft's graphics library. |
|
trebor Rookie
Joined: 23 Nov 2005
Posts: 10
|
Posted: Thu Oct 12, 2006 4:23 pm Post subject: |
|
byuu wrote: |
As
for triple buffering, that's one of the many things I've asked for help
on several times in the past. I tried to add it in. Microsoft's piece
of shit drivers always force sync immediately, so the second I call
device->Present(...), the emulator is locked by the system until
vblank, desyncing sound. If anyone knows how to make Present queue in a
buffer and only occur when one is actually in vblank (without the need
for a 1ms precision timer to constantly poll the raster status of D3D),
I'll add the code. This is common sense stuff that seems omitted by
Microsoft's graphics library. |
I was beta-testing and working with Marty (Nestopia's author) for the
longest time on tearing problems/triple buffer issue with Nestopia.
Marty also was having problems with the ridiculous way video buffering
was being handled by Microsoft's library. I forgot all the details.
Thankfully, he was able to fix it and locate the source of the problem.
Marty is extremely nice and friendly. Perhaps you can ask on the
Nestopia Message Boards, or parse the Nestopia source?
http://nestopia.sourceforge.net/
-Trebor
|
|
trebor Rookie
Joined: 23 Nov 2005
Posts: 10
|
Posted: Thu Oct 12, 2006 4:57 pm Post subject: |
|
I'm
"challenged" to say the least in the field of programming. However, in
the Nestopia source zip (Nestopia134src.zip), there are two files that
may be of interest: NstDirect2D.cpp and NstDirect2D.hpp.
They may assist in understanding how to handle video buffering.
-Trebor |
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Thu Oct 12, 2006 5:21 pm Post subject: |
|
I just got a core 2 duo e6600, so I'm good to go with speed  |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Oct 12, 2006 5:53 pm Post subject: |
|
found a possible bug didnt have time to verify, fitzroy could you test on your hardware??
SD Gundam Gaiden - Knight Gundam Monogatari - Ooinaru Isan (J)
(V1.1).smc > tiles leak over to the other side of the screen when
scrolling sideways. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Thu Oct 12, 2006 6:28 pm Post subject: |
|
byuu wrote: |
Again, savestates are technically impossible at present. I might try it
with an opcode-based core, but that'd be about it.
|
There is some new discussion about this at nesdev http://nesdev.parodius.com/bbs/viewtopic.php?t=2174
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Oct 12, 2006 7:04 pm Post subject: |
|
trebor wrote: |
byuu wrote: |
As
for triple buffering, that's one of the many things I've asked for help
on several times in the past. I tried to add it in. Microsoft's piece
of shit drivers always force sync immediately, so the second I call
device->Present(...), the emulator is locked by the system until
vblank, desyncing sound. If anyone knows how to make Present queue in a
buffer and only occur when one is actually in vblank (without the need
for a 1ms precision timer to constantly poll the raster status of D3D),
I'll add the code. This is common sense stuff that seems omitted by
Microsoft's graphics library. |
I was beta-testing and working with Marty (Nestopia's author) for the
longest time on tearing problems/triple buffer issue with Nestopia.
Marty also was having problems with the ridiculous way video buffering
was being handled by Microsoft's library. I forgot all the details.
Thankfully, he was able to fix it and locate the source of the problem.
Marty is extremely nice and friendly. Perhaps you can ask on the
Nestopia Message Boards, or parse the Nestopia source?
http://nestopia.sourceforge.net/
-Trebor
|
Yes, Marty's Nestopia seems to handle sound with triple buffering
flawlessly. I'm betting he could offer some tips on how to get around
that problem. For me, this should be even more important to fix than
adding in super fx support or other chips.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 12, 2006 11:08 pm Post subject: |
|
tetsuo55 wrote: |
found a possible bug didnt have time to verify, fitzroy could you test on your hardware??
SD Gundam Gaiden - Knight Gundam Monogatari - Ooinaru Isan (J)
(V1.1).smc > tiles leak over to the other side of the screen when
scrolling sideways. |
Not a bug, but verified on hardware anyway. I saw this, too, but it was
the same thing as Sim City (J). Bad scrolling code that wouldn't appear
on most old tvs because it's in the overscan area. Several games out of
the thousand had this or similar. Another would be 7th saga while
walking south.
Oh, and agree about triple buffering. Lots of people like this feature,
not sure how I forgot about it. Good idea to ask Marty, he knows his
stuff.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 13, 2006 12:15 am Post subject: |
|
Actually, for a ~10-15% speed hit, I think I can pull that one off...
the only problem I see are "super DMAs". Basically, worrying about the
theoretical "maximum" time the CPU cothread could be consumed in
processing. It could be as great as ten full video frames between
pressing save state and actually having it saved. But really, we're
talking theory. No game in the world is going to actually do that. The
game would appear absolutely frozen even if it did. There's not even a
place to
transfer the limit (512kb) of memory to. And I believe ZSNES et al does
the same, it completes DMAs instantly. This just means that the CPU
savestate, in the absolute worst condition, could dump as much as 512kb
to the file. Not really a big deal, since it will only dump a few bytes
99.9% of the time.
Quote: |
Another would be 7th saga while walking south. |
Oh, wow. You saw that on a TV? Neat. I saw that myself, and assumed
emulation might be running a bit too slow, but figured it was most
likely missed because the developers didn't see it.
Quote: |
I just got a core 2 duo e6600, so I'm good to go with speed |
Nice. Hey, remember you were talking about donating something ...? Heheh, just joking.
Seriously, is that the 4MB L2 cache one? Would you mind telling me what
kind of framerates you pull with that baby on v0.017 official with
speed regulation disabled? Preferrably in a "typical" game like SMW or
Zelda 3 in-game.
|
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Fri Oct 13, 2006 11:56 am Post subject: |
|
[quote="byuu"]
Quote: |
Quote: |
I just got a core 2 duo e6600, so I'm good to go with speed |
Nice. Hey, remember you were talking about donating something ...? Heheh, just joking.
Seriously, is that the 4MB L2 cache one? Would you mind telling me what
kind of framerates you pull with that baby on v0.017 official with
speed regulation disabled? Preferrably in a "typical" game like SMW or
Zelda 3 in-game.
|
I'd gladly donate some money to you to help get one yourself. Yes I
will test this out for you this weekend. It is the 4mb L2 cahce one. Do
you want me to try the newest WIP also?
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Oct 13, 2006 1:14 pm Post subject: |
|
FitzRoy wrote: |
tetsuo55 wrote: |
found a possible bug didnt have time to verify, fitzroy could you test on your hardware??
SD Gundam Gaiden - Knight Gundam Monogatari - Ooinaru Isan (J)
(V1.1).smc > tiles leak over to the other side of the screen when
scrolling sideways. |
Not a bug, but verified on hardware anyway. I saw this, too, but it was
the same thing as Sim City (J). Bad scrolling code that wouldn't appear
on most old tvs because it's in the overscan area. Several games out of
the thousand had this or similar. Another would be 7th saga while
walking south.
|
Same thing as in the Axelay stage that has the giant walker at the end?
That stage also updates its BG tiles quite slowly.
byuu wrote: |
Actually, for a ~10-15% speed hit, I think I can pull that one off...
the only problem I see are "super DMAs". Basically, worrying about the
theoretical "maximum" time the CPU cothread could be consumed in
processing. It could be as great as ten full video frames between
pressing save state and actually having it saved. But really, we're
talking theory. No game in the world is going to actually do that. The
game would appear absolutely frozen even if it did. [...]
|
Personally I wouldn't care if the emulator needs ten seconds to save a
state. As long as it's faster than examining GBs of logfiles it's OK.
Actually such long saving times could even get me out of the savestate whoring that corrupts my gameplay. 
_________________
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: Fri Oct 13, 2006 6:57 pm Post subject: |
|
byuu wrote: |
Quote: |
Another would be 7th saga while walking south. |
Oh, wow. You saw that on a TV? Neat. I saw that myself, and assumed
emulation might be running a bit too slow, but figured it was most
likely missed because the developers didn't see it.
|
Yeah, not a TV, though. I'm hooking up my snes to a s-video input card
in my computer and running dscaler to view the output. This way I can
see on my monitor what would normally be cut off by a regular tv. I
suppose if you had an lcd tv though, you could achieve the same.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 13, 2006 8:24 pm Post subject: |
|
Koushien 2 (J) S-SMP opcode count log:
Code: |
00: 1 nop
01: 0
02: 0
03: 0
04: 29717 or a,dp
05: 8 or a,addr
06: 0
07: 0
08: 22420 or a,#const
09: 0
0a: 0
0b: 138094 asl dp
0c: 0
0d: 0
0e: 597 tset addr,a
0f: 0
10: 137211 bpl rel
11: 0
12: 0
13: 0
14: 0
15: 87 or a,addr+x
16: 0
17: 22 or a,(dp)+y
18: 0
19: 0
1a: 0
1b: 594 asl dp+x
1c: 90776 asl a
1d: 89456 dec x
1e: 0
1f: 3117 jmp (addr+x)
20: 920 clrp
21: 0
22: 0
23: 0
24: 41740 and a,dp
25: 0
26: 0
27: 0
28: 167790 and a,dp
29: 4155 and dp,dp
2a: 0
2b: 33240 rol dp
2c: 0
2d: 83709 rol addr
2e: 0
2f: 739 bra rel
30: 12356 bmi rel
31: 0
32: 0
33: 0
34: 0
35: 0
36: 0
37: 0
38: 1233 and dp,#const
39: 0
3a: 47 incw dp
3b: 0
3c: 48 rol a
3d: 2072 inc x
3e: 281 cmp x,dp
3f: 144545 call addr
40: 1533 setp
41: 0
42: 0
43: 0
44: 9082 eor a,dp
45: 0
46: 0
47: 0
48: 51830 eor a,#const
49: 0
4a: 0
4b: 252 lsr dp
4c: 0
4d: 37913 push x
4e: 8696 tclr addr,a
4f: 0
50: 0
51: 0
52: 0
53: 0
54: 0
55: 0
56: 0
57: 0
58: 0
59: 0
5a: 0
5b: 0
5c: 21674 lsr a
5d: 76707 mov x,a
5e: 0
5f: 18234 jmp addr
60: 60550 clrc
61: 0
62: 0
63: 0
64: 136972 cmp a,dp
65: 14 cmp a,addr
66: 0
67: 0
68: 97440 cmp a,#const
69: 0
6a: 0
6b: 20682 ror dp
6c: 0
6d: 12406 push y
6e: 0
6f: 144540 ret
70: 0
71: 0
72: 0
73: 0
74: 491 cmp a,dp+x
75: 0
76: 0
77: 199 cmp a,(dp)+y
78: 2770 cmp dp,#const
79: 0
7a: 25890 addw ya,dp
7b: 0
7c: 0
7d: 60322 mov a,x
7e: 6387 cmp y,dp
7f: 0
80: 12673 setc
81: 0
82: 0
83: 0
84: 21045 adc a,dp
85: 1288 adc a,addr
86: 0
87: 0
88: 13349 adc a,#const
89: 0
8a: 0
8b: 102 dec dp
8c: 28 dec addr
8d: 141465 mov y,#const
8e: 0
8f: 37740 mov dp,#const
90: 139891 bcc rel
91: 0
92: 0
93: 0
94: 0
95: 38290 adc a,addr+x
96: 28044 adc a,addr+y
97: 0
98: 0
99: 0
9a: 1439 subw ya,dp
9b: 952 dec dp+x
9c: 7220 dec a
9d: 0
9e: 12783 div ya,x
9f: 48823 xcn a
a0: 0
a1: 0
a2: 0
a3: 0
a4: 75 sbc a,dp
a5: 0 sbc a,addr
a6: 0
a7: 0
a8: 175 sbc a,#const
a9: 0
aa: 3560 mov1 c,mbit
ab: 79901 inc dp
ac: 5 inc addr
ad: 13 cmp y,#const
ae: 80148 pop a
af: 672 mov (x)+,a
b0: 43386 bcs rel
b1: 0
b2: 2 clr5 dp
b3: 0
b4: 0
b5: 0
b6: 0
b7: 0
b8: 0
b9: 0
ba: 770 movw ya,dp
bb: 1235 inc dp+x
bc: 12646 inc a
bd: 4 mov sp,x
be: 0
bf: 0
c0: 3 di
c1: 0
c2: 0
c3: 0
c4: 393572 mov dp,a
c5: 5368 mov addr,a
c6: 239 mov (x),a
c7: 0
c8: 782 cmp x,#const
c9: 0
ca: 0
cb: 48360 mov dp,y
cc: 0
cd: 23352 mov x,#const
ce: 37913 pop x
cf: 79065 mul ya
d0: 160851 bne rel
d1: 0
d2: 0
d3: 0
d4: 3794 mov dp+x,a
d5: 47581 mov addr+x,a
d6: 10260 mov addr+y,a
d7: 99918 mov (dp)+y,a
d8: 46214 mov dp,x
d9: 0
da: 15518 movw dp,ya
db: 0
dc: 207 dec y
dd: 49515 mov a,y
de: 0
df: 0
e0: 0
e1: 0
e2: 0
e3: 0
e4: 420386 mov a,dp
e5: 17588 mov a,addr
e6: 0
e7: 0
e8: 52440 mov a,#const
e9: 0
ea: 0
eb: 38531 mov y,dp
ec: 0
ed: 0
ee: 15966 pop y
ef: 0
f0: 215029 beq rel
f1: 0
f2: 0
f3: 0
f4: 115627 mov a,dp+x
f5: 158511 mov a,addr+x
f6: 65525 mov a,addr+y
f7: 118277 mov a,(dp)+y
f8: 69833 mov x,dp
f9: 0
fa: 76630 mov dp,dp
fb: 0
fc: 100705 inc y
fd: 121806 mov y,a
fe: 20682 dbnz y,addr
ff: 21804088 stop |
The reason for the huge stop count should be obvious. The processor crashed there.
If Koushien 2 is indeed due to an S-SMP opcode problem, it has to be in one of the above opcodes.
Immediately, tset,tclr,clr5 dp and mov1 are jumping out at me as
"likely" opcodes with problems... low opcode counts, obscure... hmm.
Could be due to flags being incorrect, could be due to opcode semantics
being incorrect.
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Oct 13, 2006 10:45 pm Post subject: |
|
byuu wrote: |
Seriously,
is that the 4MB L2 cache one? Would you mind telling me what kind of
framerates you pull with that baby on v0.017 official with speed
regulation disabled? Preferrably in a "typical" game like SMW or Zelda
3 in-game. |
I have this model and my system is quite fast:
- bsnes 0.017 -
SMW: typical speeds between 150 and 200 fps
Zelda 3: typical speeds between 150 and 250 fps
_________________
"Change is inevitable; progress is optional"
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 14, 2006 10:10 am Post subject: |
|
http://byuu.org/ wrote: |
10/14/2006 - bsnes v0.018 released
I began working on bsnes on October 14th, 2004. I am releasing bsnes
v0.018 today to celebrate bsnes' two year anniversary. Please note that
this release incurs a ~15% speed reduction since v0.017, due to IRQ and
S-SMP timing improvements.
Changelog:
* Fixed many critical errors in IRQ timing, should be *very* close to real hardware now
* Corrected major CPU timing bug involving CPU I/O condition 4
* Corrected bug with generic HiROM / LoROM memory maps
* Corrected bug involving HDMA indirect channel termination [anomie]
* OAM address reset now occurs when screen display is enabled, per recent research
* Readded full DMA, HDMA and HDMA init bus sync timing
* Added preliminary emulation of S-SMP $00f0 TEST register (6 of 8 bits are supported)
* Readded emulation of known timing differences between CPU revisions 1 and 2
* Config file can now control scanline-based PPU render position. This
will only be needed until a proper dot-based PPU renderer is added
* Removed core debugging hooks so that debugging console can remain in
public releases, it now functions as a tracer and memory editor
* Config file paths once again work correctly even if missing trailing backslash
* Video configuration simplified, sorry in advance to those who enjoyed the profile mode used before
* Added new configuration screen to control some emulation settings
* Replaced bsnes program icon with a much nicer one [FitzRoy]
* Optimized memory speed detection algorithm
* Preliminary UPS soft-patching support (do not use this yet!)
* Decreased memory usage and optimized generic libraries used by bsnes (/src/lib)
* Now caching OAM by one line, somewhat similar to a real SNES. Fixes
Winter Gold, but causes line rendering error in Mega lo Mania
* Lots more, as usual
The following games have been fixed since v0.017 by the above bugfixes:
* Battle Blaze (J, U)
* Circuit USA (J)
* F1 Grand Prix (J)
* Funaki Masakatsu no Hybrid Wrestler - Tougi Denshou (J)
* Jumbo Ozaki no Hole in One (J)
* Mahjongg Taikai II (J)
* RPG Tsukuru - Super Dante (J)
* Robocop Versus The Terminator (U, E)
* Sink or Swim (U, E)
* Street Racer (J)
* Touge Densetsu Saisoku Battle (J)
* Winter Olympics (U, E) |
Hopefully releasing this without much beta testing doesn't turn out to be a bad idea ...
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 14, 2006 10:34 am Post subject: |
|
Did you make a lot of changes since the last wip?
If not then there shouldnt be any problems with this version |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Oct 14, 2006 10:46 am Post subject: |
|
bsnes speed hit and version comparison on a Core 2:

I've used the stock speed for my processor (2.4 GHz). Nevertheless, awesome release 
_________________
"Change is inevitable; progress is optional" |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 14, 2006 10:52 am Post subject: |
|
Ah,
so it's a bigger speed hit on Intel processors than AMD processors,
great. I get 115fps in Mario World with v0.017, and 99fps with v0.018.
Oh well, it may not be a permanent speed hit. But don't get your hopes
up on that, we'll have to see what happens when the last bit of IRQ
testing is conducted. I didn't want to release until I could try and
remove the speed hit, but it's kind of an important date :/
Side note for EMu-LoRd: I'd be much more impressed with the Core 2 Duo
if both of those were running at the same time at those framerates ;) |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 14, 2006 11:18 am Post subject: |
|
If bsnes was optimised for core2duo it might be able to exceed 200fps
Maybe a SSE3 version could be compiled? |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sat Oct 14, 2006 11:50 am Post subject: |
|
Yeah,
I used to get 60 FPS with SMK with v0.17 (ie: perfect, no lag unless I
used a graphics filter), and with v0.18 I have something around 50 FPS.
:\
Still, I approve of your accuracy over speed changes.
PS: how about making it so Alt + Enter switches to full screen ? May have been requested before, no ?
Edit: ugh, remember the B button problem I used to have with SMK, with
it not working during tracks ? It's back again, but seems somewhat
random (didn't happen at first)... |
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Oct 14, 2006 12:03 pm Post subject: |
|
byuu wrote: |
Side
note for EMu-LoRd: I'd be much more impressed with the Core 2 Duo if
both of those were running at the same time at those framerates  |
They ARE running at the same time! 
This may look like a show-off, but here's a taste of what this processor is capable (fps) of:
http://www.xs4all.nl/~vdnoort/emulation/bsnes_core2duo_18x4.jpg
_________________
"Change is inevitable; progress is optional"
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 14, 2006 12:58 pm Post subject: |
|
EMu-LoRd, is that 2 bsnesses on each core?
how high is the fps with 1 instance on its own core? |
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Sat Oct 14, 2006 1:47 pm Post subject: |
|
EMu-LoRd wrote: |
byuu wrote: |
Side
note for EMu-LoRd: I'd be much more impressed with the Core 2 Duo if
both of those were running at the same time at those framerates  |
They ARE running at the same time! 
This may look like a show-off, but here's a taste of what this processor is capable (fps) of:
http://www.xs4all.nl/~vdnoort/emulation/bsnes_core2duo_18x4.jpg
|
can't wait to try mine out tonight
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sat Oct 14, 2006 1:50 pm Post subject: |
|
I can't even reach such a high FPS with just one bsnes. :p
(Celeron D, 2.4 GHz, 512 MB RAM)
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Oct 14, 2006 3:40 pm Post subject: |
|
Stifu wrote: |
PS: how about making it so Alt + Enter switches to full screen ? May have been requested before, no ? |
Yes, it has been requested before (by me).
EDIT: I have to use frameskip 2 to get 60 fps. I'm testing on an Athlon
T-Bird 1.1 GHz. I'll test on my laptop later (which has a Pentium M 1.6
GHz).
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Oct 14, 2006 5:26 pm Post subject: |
|
Jipcy wrote: |
Stifu wrote: |
PS: how about making it so Alt + Enter switches to full screen ? May have been requested before, no ? |
Yes, it has been requested before (by me).
|
IIRC Byuu explained that polling the Alt key does something strange,
and so he doesn't know how to catch the Alt + Enter..
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Oct 14, 2006 5:39 pm Post subject: |
|
Please
excuse my noobness if there is, but is there a key I can press to reset
the emulation while in fullscreen mode? Currently I'm having to exit
back to window mode and select the reset function from the menu options. |
|
dragoonmaster New Member
Joined: 31 Aug 2006
Posts: 4
|
Posted: Sat Oct 14, 2006 5:56 pm Post subject: |
|
iNTERESTING with my ATHLON 64 @2400mhz I GET 111 Frames, which means it is 22,5 % slower as the duo core |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Oct 14, 2006 10:45 pm Post subject: |
|
tetsuo55 wrote: |
EMu-LoRd, is that 2 bsnesses on each core?
how high is the fps with 1 instance on its own core? |
With or without using separate cores for each, it doesn't really affect
speed much. Using both for all seems just slightly faster.
_________________
"Change is inevitable; progress is optional"
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 15, 2006 9:29 pm Post subject: |
|
Quote: |
This may look like a show-off, but here's a taste of what this processor is capable (fps) of: |
Yep ... now I'm impressed :)
Quote: |
Please
excuse my noobness if there is, but is there a key I can press to reset
the emulation while in fullscreen mode? Currently I'm having to exit
back to window mode and select the reset function from the menu options. |
I don't currently have a hotkey for reset in fullscreen mode. I'll add
it to my (rather large) todo list. Eventually I'd like to have a big
list of actions you can assign hotkeys to, using either keyboard or
joypad.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Oct 17, 2006 3:09 am Post subject: |
|
Testing with SMW or Zelda3 doesn't give the true picture of bsnes' (018) speed.
Those are the least demanding non-special chip games when it comes to CPU requirements.
I get solid 73fps in SMW,but these suckers aren't even playable with an AthlonXP 2200+ box:
- Nitro Punks Might Heads (Rocky Rodent): 56 fps (gameplay, level 1 and 3) The shocker !
- DKC1: in the first bonus area in the first level,after getting Rambi
the rhino and ramming through the first 'wall' you see -> ~59fps,
sound crackles (In the main level,it's about 63fps : running fast
through the level,bashing enemies to stress the CPU)
- Front Mission: 54 fps at the weapons specs display demo. _SLOW_
.OK,this one is playable (66 fps ingame),but that demo is super
sluggish.
I'd love to see joypad-assignable emulation-specific controls.
P.S. How many FPS do you get in SMW with the Core2 Duo if both cores are used 100% by one instance of bsnes? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 17, 2006 4:47 am Post subject: |
|
Yes, but SMW or Zelda3 are games most people would have. It's hard to ask for performance comparisons on an obscure rom.
There should be no surprise about performance dips when certain special effects have to be rendered.
The most demanding effect I've seen in my testing is "Liberty or Death" at the end of setup. |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Tue Oct 17, 2006 8:06 am Post subject: |
|
I'm using 2 cores at the same time for these and 1 instance of bsnes.
kick wrote: |
I get solid 73fps in SMW,but these suckers aren't even playable with an AthlonXP 2200+ box: |

kick wrote: |
- Nitro Punks Might Heads (Rocky Rodent): 56 fps (gameplay, level 1 and 3) The shocker ! |

kick wrote: |
-
DKC1: in the first bonus area in the first level,after getting Rambi
the rhino and ramming through the first 'wall' you see -> ~59fps,
sound crackles (In the main level,it's about 63fps : running fast
through the level,bashing enemies to stress the CPU) |

kick wrote: |
-
Front Mission: 54 fps at the weapons specs display demo. _SLOW_
.OK,this one is playable (66 fps ingame),but that demo is super
sluggish. |

kick wrote: |
P.S. How many FPS do you get in SMW with the Core2 Duo if both cores are used 100% by one instance of bsnes? |
See first screenshot 
_________________
"Change is inevitable; progress is optional"
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 17, 2006 1:09 pm Post subject: |
|
bsnes
does not and cannot take advantage of both CPU cores. libco is
cooperative, so no two threads are ever running at the same time.
Honestly, by the time you even have
a dual core processor, you're getting framerates like EMu-LoRd, or
slightly lower. There's no reason to slow down single core CPUs to
split the workload from 50% on one core to 25% on two separate cores.
Especially since doing so would raise tons of new issues in coding.
Mutexes, semaphores, critical sections, locks, forget about debugging,
etc etc. Not worth it. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Oct 17, 2006 7:52 pm Post subject: |
|
That's some very nice performance from the E6600 
Now I just want to see a screenshot of Rocky Rodent level 1 with the NTSC filter on.
BTW,what's that XP theme you're using? Or is that Vista RC2?  |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Oct 17, 2006 8:04 pm Post subject: |
|
On
my crappy outdated p4 3gig, nothing has dipped below 70fps yet, but
that's cool with me since I only need 60 fps for smooth scrolling at
60hz.
I haven't tried bsnes out on my newer comp
yet, mainly because the graphics card is a littl weak in it, but the
cpu is a lot faster and I have 2gigs of ram in it as well. I'll
probably try it out today just to see how it performs. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Oct 17, 2006 9:26 pm Post subject: |
|
FitzRoy wrote: |
The most demanding effect I've seen in my testing is "Liberty or Death" at the end of setup. |
I'll try that. 
Btw. have you tried Rendering Ranger?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Tue Oct 17, 2006 9:47 pm Post subject: |
|
kick wrote: |
That's some very nice performance from the E6600 
Now I just want to see a screenshot of Rocky Rodent level 1 with the NTSC filter on. |
Normal (left) NTSC (right)

kick wrote: |
BTW,what's that XP theme you're using? Or is that Vista RC2?  |
Here you go: http://www.crystalxp.net/galerie/en.id.130.htm
_________________
"Change is inevitable; progress is optional"
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Oct 17, 2006 10:39 pm Post subject: |
|
thats a notable performance difference 
_________________
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. |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Wed Oct 18, 2006 1:09 am Post subject: |
|
still 60+, i'm impressed.
_________________
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 18, 2006 5:33 am Post subject: |
|
I've
written a new scheduler for bsnes to take 100% full advantage of
cooperative multithreading. Now, bsnes only performs jumps directly
from one thread to another (CPU->SMP instead of
CPU->main->SMP), and even then only when absolutely needed (eg
CPU is accessing SMP when CPU is currently ahead of SMP). This
unfortunately makes bCPU and bSMP no longer compile. However, it does
yield some impressive speed gains. From 109fps to 125fps.
By comparison, bsnes v0.017 yielded 128fps with my test ROM.
The speed gain though is dependant upon how utilized the CPU<>SMP
communication is, the difference in speed between v0.017 and my WIP can
be anywhere between 1% and 10%, with the WIP always being slower.
The better news is that this is still without IRQs fully optimized. I
don't know how easy it will be to optimize these, if it's even doable
at all... but if I can, that would yield another very important speed
increase, making the next release the fastest ever. Here's to hoping.
The bad news though is that cothreading's advantages are pretty much
maxed out completely now. Don't expect any future leaps in performance
from this. Still, overall... a 40% total speed increase and double the
processor synchronization precision was definitely worth the effort,
even for the potential loss of savestates.
The scheduler should also make sPPU much faster when and if that's ever
started upon, but that's still going to take a very significant speed
hit over bPPU.
One last benefit of the scheduler is that the new synchronization
method isn't limited to only two clocks. I can now easily add another
clock, eg for SFX/SA-1. Not that I'll be emulating either of those
within the next year or two, though. Just saying...
I might also make two schedulers, one for cothreaded cores and one for
non-cothreaded cores. One thing is for certain though, I won't be
writing schedulers for every combination of
cothreaded<>non-cothreaded cores (there's 4 of them, CPU, SMP,
PPU and DSP). And this will also rule out run-time polymorphism's
compile-time option, so expect that to change to a compile-time only
setting, meaning possibly two versions of bsnes in the future.
Now then, I also fixed up S-CPU emulation mode opcodes. Direct page
wrapping, stack wrapping with native mode opcodes and processor status
flag fixes. No games use emulation mode, but accuracy is always nice. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 18, 2006 7:25 pm Post subject: |
|
Thanks, byuu. So you suspect stability issues with these changes? Because I sure haven't noticed any thus far.
creaothceann wrote: |
FitzRoy wrote: |
The most demanding effect I've seen in my testing is "Liberty or Death" at the end of setup. |
I'll try that. 
Btw. have you tried Rendering Ranger?
|
If you mean for slowdowns, I went through three stages and stayed at
60fps. Comparitively, the Liberty or Death effect brings it down to
53fps.
RRR2 though, is fun. Half platformer, half space shooter. I remember
using it as opposition to nsrt including genres, but Nach just created
two fields.
Speaking of NSRT, I checked out No-Intro the other day and I'm
impressed. The databases are great, although the website is nonsensical
and the name is dumb. I'll have to recommend them as well on the first
page.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Oct 18, 2006 10:51 pm Post subject: |
|
FitzRoy wrote: |
you mean for slowdowns |
Yep
FitzRoy wrote: |
I went through three stages and stayed at 60fps. Comparitively, the Liberty or Death effect brings it down to 53fps. |
I see. LoD goes down to 29/30 fps here on this screen; RRR2 averages around 32 in the first stage. (P4 Celeron 1.7 GHz)
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Thu Oct 19, 2006 4:21 am Post subject: |
|
[EDIT]
R2 seems to be the most demanding non special chip game I've seen so far.
Getting steady 60fps throughout 99% of the game requires an AthlonXP
2500+ at least,but there is one small part in this game that will put
even a much more powerful CPU to it's knees - the small part at the
beginning of the first shooter level where the blue lightning strikes.
But the LoD effect is even mire CPU-munching.
(surprisingly R2 is actually a *good* game,created by Manfred Trenz,the
creator of the famous Turrican series).The shooter part is very good.
I see a 10% speed improvement with 018wip2 (over 017wip22)
The old 017 (final) is about 15% faster on my machine than 018 final,so 10% is a notable improvement.
WIPs tend to be ~25% slower,as always,so 
Last edited by kick on Fri Oct 20, 2006 1:11 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 19, 2006 6:47 am Post subject: |
|
Ok, bsnes v0.017 ran at 128fps.
Yesterday's scheduler raised the framerate of v0.018 from 109fps to 125fps.
Today, I regressed the IRQ timing code to v0.017's method of testing
ranges of positions at once, and then patched it to work with F1 Grand
Prix, Sink or Swim, Battle Blaze, and my three IRQ test ROMs + two NMI
test ROMs. In other words, it works with everything I have.
The good news, it raises speed from 125fps to 145fps. This is way
faster than even v0.017 now. Note, as always, these frame rates are
comparisons with PGO disabled. The official builds use PGO and so are
much faster than WIPs.
The bad news, while the new code does work with all known examples, I simply do not feel good about it. I hate
range testing the SNES interrupts, and I'm afraid extreme edge cases
may still be missed. Not to mention the code is sloppy (by nature of
what it is, a speed hack), and very hard to read / edit.
But the speed difference is absolutely incredible for no perceived
differences in any known games. Therefore, I'm going to use #define
FAVOR_[SPEED | ACCURACY] to toggle between the two IRQ testing methods.
I ask that you guys test the next WIP with all of the troublesome IRQ
games, and let me know if any are broken. If none are broken, I'm
planning on compiling v0.019 official with FAVOR_SPEED. Perhaps if
someone wants to host the files, I can post a FAVOR_ACCURACY build for
those of you with computers that can handle a significant speed hit
with no perceived differences in emulation. |
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Thu Oct 19, 2006 8:56 am Post subject: |
|
Liberty of Death effect:

_________________
"Change is inevitable; progress is optional" |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Oct 19, 2006 10:40 am Post subject: |
|
i'll be happy to host (and allow hotlinking) a v0.19 for you byuu 
_________________
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.
Last edited by franpa on Sun Oct 22, 2006 1:23 am; edited 1 time in total |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Oct 20, 2006 1:17 am Post subject: |
|
I'm
also for the FAVOR_ACCURACY build.The ~10% speed gain from the new
scheduler is more than enough,while still keeping bsnes very accurate.
A small overclock will do the trick for now,until the new PPU,but I'll upgrade to a C2D till then 
I'm very impressed with the E6600
Previous post edited and corrected,Emu-Lord.Read it again.
P.S. Is the PGO final build MMX or SSE optimized?
Switching to SSE[(1 at least)] makes a difference,especially on C2D and A64 CPUs. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 20, 2006 1:51 am Post subject: |
|
I
would probably agree with kick. Still, if it works with all the known
finicky games, and the test roms, that's impressive. You'll have to
decide if 10% is worth an extra version and the possibility of issues,
though. I barely notice a speed difference on my 2.4c. 52 dip vs 55 dip
on the LoD effect.
#-C of (U) games tested. No bugs found.
Your forecast of 5 bugs is probably a bit conservative, considering a
lot of these games have (J) versions. I'm gonna say we might find one
more in (U) and (E), but wouldn't be shocked if it was 0. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Oct 20, 2006 1:56 am Post subject: |
|
FitzRoy wrote: |
Your
forecast of 5 bugs is probably a bit conservative, considering a lot of
these games have (J) versions. I'm gonna say we might find one more in
(U) and (E), but wouldn't be shocked if it was 0. |
I think, in this case, you meant his forcast was liberal. You're saying
his forecast is too large, which would be liberal, rather than too
small, which is conservative.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 20, 2006 2:09 am Post subject: |
|
Hmm,
I could be wrong. But wait... if bugs are a bad thing... then guessing
more will happen would be a conservative outlook, right? Guessing 0
would be more liberal/generous of an outlook?
conservative = cautiously moderate
liberal = favorable/generous
Numerically, in this case, less is better. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Oct 20, 2006 2:48 am Post subject: |
|
Yes, you could think about it like that too.
I think your explanation is technically
right. The only problem being that, usually, when using the terms
liberal/conservative in regards to estimates, a larger estimate is
"better" and a smaller estimate "worse." But in this case, it's
reversed.
Ah, English.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 20, 2006 6:17 am Post subject: |
|
FitzRoy wins the AP English award :)
I was being conservative by bracing for more (bad) bugs in advance. But
I'm quite the pessimist, so that's normal for me.
Anyway, I didn't notice much difference on P4 processors. I guess
they're better at loops than A64s. I will try and optimize the
"accurate" code, then. If they end up with <= 10% speed difference,
I'll stick with just the accurate one in the next release. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 20, 2006 7:59 am Post subject: |
|
Ok, please
be courteous to my webhost and only download this WIP if you're going
to test it on a processor that hasn't been tested thus far.
byuu.org/files/bsnes_v018_wip4.zip
byuu.org/files/bsnes_tests.zip
This has two separate builds. Neither have PGO, SSE, SSE2, ZIP or JMA
support. They are identical except for the FAVOR_ flag define and title
of the program.
FAVOR_ACCURACY [bsnes_accurate.exe]:
- Always tests OAM RTO flags even on skipped frames
- Tests NMI/IRQ trigger every clock cycle
FAVOR_SPEED [bsnes_fast.exe]:
- Only tests OAM RTO flags on rendered frames (always with no frameskipping)
- Tests NMI/IRQ trigger using ranges
If you'd like to test, please run demo_mode3.smc on both versions of
bsnes, turn off speed regulation, and report the framerate both with a
frameskip of zero and a frameskip of nine (max), along with your
processor speed.
The other test ROMs are just to verify that IRQ behavior is still
reliable in both versions. A blue screen indicates passing, they all
pass on both versions. Don't expect test_* ROMs to pass on other
emulators, but demo_* ones should.
Example (my main PC):
AMD Athlon 3500+
Accurate:
- 121.5 fps w/o frameskipping
- 171 fps w/max frameskipping
Fast:
- 146.5 fps w/o frameskipping
- 271.5 fps w/max frameskipping
-----
As you can see, there are major
speed differences on my A64. Personally, I'm all for accuracy, but I
also want people to actually be able to use this program in the
interim. Perhaps in the future when a low end computer is a current
low-end Core 2 Duo, we can remove all of the "speedhack" code. And in
the meantime, the full 100% precision is there for people who have the
CPU power to afford it.
-----
If anyone wants to try and help, heh.
src/cpu/scpu/timing/irqtiming_accurate.cpp and
src/cpu/scpu/timing/irqtiming_fast.cpp are the two versions of the IRQ
testing code. If you see any ways to optimize either (preferrably the
former, obviously), I'd greatly appreciate it. Understand that both the
CPU counters (VCOUNTER, HCLOCK) and the IRQ timing positions (VIRQPOS,
HIRQPOS) can wrap not only the horizontal clock position (1362->0),
but the vertical position as well (261->0). And also that they are
"misaligned" by 10 clocks (which is really more of an internal CPU IC
delay thing, we aren't entirely sure why the difference is there). You
probably shouldn't mess with the code if you don't understand the
implications of this on eg range testing :/ |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Oct 20, 2006 8:40 am Post subject: |
|
Main PC:
Intel Core 2 Duo 2.4 GHz (@stockspeed)
Accurate:
w/o frameskipping (left) - w/max frameskipping (right)

Fast:
w/o frameskipping (left) - w/max frameskipping (right)

_________________
"Change is inevitable; progress is optional" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 20, 2006 9:12 am Post subject: |
|
Cool.
I like this better than doing a different core. Very generous to the
people on the fringe without compromising perceived accuracy. |
|
laynlow New Member
Joined: 12 Sep 2006
Posts: 9
|
Posted: Fri Oct 20, 2006 2:24 pm Post subject: |
|
Since
Emu lord did the C2D I decide to do my work computer so you can get the
far end of the spectrum. It locked down from me being able to check the
exact processor in the bios(i don't have admin rights) BUt I know it's
an AMD runing at 1.0ghz with a big wopping 128km of ram.
accurecy:
no frameskip 32 FPS
max frameskip 70FPS
Speed
no frameskip 35fps
max frameskip 101 fps |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 20, 2006 3:10 pm Post subject: |
|
FitzRoy wrote: |
Cool.
I like this better than doing a different core. Very generous to the
people on the fringe without compromising perceived accuracy. |
And much less effort on my part. Since we're discontinuing the PPC port
due to not having a port of libco, I don't feel as bad about dropping
bCPU/bSMP. Now the last problem to solve is how to pull off both bPPU
and sPPU at the same time. Preferrably without needing to write two
schedulers and riddle the whole project with #ifdefs.
Pentium 4 1.7ghz
Note: PC is loaded with 45+ background processes. Typical work PC.
Accurate:
- 29.5fps, 0fs
- 82fps, 9fs
Fast:
- 31fps, 0fs
- 108fps, 9fs
Amazing that the difference on a P4 is only ~3-5%, but the difference
on modern processors like the A64 and C2D is ~20-25%.
|
|
Cecil Paladin
Joined: 30 Jul 2004
Posts: 182
|
Posted: Fri Oct 20, 2006 5:39 pm Post subject: |
|
CPU: Athlon64 X2 4400+ @2.2GHz
Accurate
no frame skip: 121fps
max frame skip: 167fps
Fast
no frame skip: 146fps
max frame skip: 272fps
BTW, great work on the emulator so far, byuu. 
_________________
System Specs:
2.2GHz Athlon64 X2 4400+, 2GB DDR 400 SDRAM
EVGA Geforce 7600GT 256MB
Realtek AC '97
Microsoft Windows Vista Home Premium |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 20, 2006 6:41 pm Post subject: |
|
byuu wrote: |
Amazing that the difference on a P4 is only ~3-5%, but the difference
on modern processors like the A64 and C2D is ~20-25%. |
Yeah, maybe it will have a bigger use for these new cpus when sppu is
in. Any cpu that came out before 2002 is looking pretty sorry.
P4 2.4C, Super Mario World intro:
Fast: 76fps
Accurate: 70fps
"D, E" (U) games tested: no bugs.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Oct 20, 2006 7:50 pm Post subject: |
|
Yeah I'm only seeing a 6-frame increase from accurate to fast on the P4 3Ghz. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Oct 20, 2006 10:29 pm Post subject: |
|
On an Athlon 64 X2 3800+ @ 2.5 GHz:
Accurate:
137 FPS with frameskip 0
195 FPS with frameskip 9
Fast:
164 FPS with frameskip 0
305 FPS with frameskip 9 |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Sat Oct 21, 2006 2:53 am Post subject: |
|
Hmmm...not that shabby for a 'retro' AthlonXP 2400+ box @ stock speed (1.83GHz) w/1GB ram:
Accurate
-----------------------
Demo: 95 fps fs=0
128 fps fs=max
SMW: 66 fps fs=0
Fast
-----------------------
Demo: 109 fps fs=0
198 fps fs=max
SMW: 74 fps fs=0
Tests: All tests pass (Blue Screen of Quality ).Is this some kind of MS joke?
Just as expected,the 'F' version is about 14% faster than the 'A' version.
I'm expecting about 84 fps in SMW with the final PGO'd 'A' version,and 96 with the 'F' version.
I got the same difference when comparing wip3 to wip2.
DKC2 will gain even more speed this time,thanks to the new scheduler.
Note:PGO can improve performance greatly,something like ~29% in SMW 
So,the difference between Accurate and Fast builds is very dependent on the CPU type
P4 CPUs will get a 5% boost
plain Athlons get a 10% boost
AthlonXPs get up to 15%
Athlon64s get a 20% boost
Core2 gets the most - up to 25%
Not bad at all 
Interesting,this can also be used roughly as an indicator of the
'quality' of each CPU architecture:from P4 being the worst,to Core2
being the best so far.
Now we need more P4 and D Celerons for testing.I think Celeron Ds can gain more than 5% 
Anything below a Pentium4/AthlonXP is just not enough,unless you use the fast version 
P4 Northwoods are actually _very good_,but those &^%$ "Press-Hots" are just terrible,so that 'old' P4 3.0GHz must be one of the 'good ones'
A fullscreen reset key,sound channel enable/disable and gamepad 'shortcut' keys will be an added bonus for 019.
BTW,does bsnes perform even faster if you don't have/use a gamepad? (joystick polling speed penalty)
Cause I use one in all of my tests 
Also,where did the dd/d3d option go? It's not in the .cfg anymore. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Oct 21, 2006 4:16 am Post subject: |
|
--bug--
start emulator
go to configuration
engage in full screen (while playing a game)
press escape
the game will minimize except for the configuration dialog and i cant
restore the program unless i set it to window mode then to full screen
mode.
is it possible to access a gui while in fullscreen mode?
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 21, 2006 4:32 am Post subject: |
|

Opinions? |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Oct 21, 2006 4:41 am Post subject: |
|
FitzRoy wrote: |
[/nice pic]
Opinions? |
For consistancy, use white text for the "B" button and see if you can try a different color to blend it with.
Though, I'm not sure if anyone needs to point out the directional keys with arrows...
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 21, 2006 7:36 am Post subject: |
|
Good
crit. However, yellow simply needs to be paired with dark lettering.
Trying to get white to appear on yellow requires me to set it all the
way down to a dark gold, and even then it barely stands out. This way
also allows me to exactly match the icon's colors.
EDIT: going with the bold crosshairs as well for balance and better use of space.
Last edited by FitzRoy on Sat Oct 21, 2006 6:31 pm; edited 1 time in total |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sat Oct 21, 2006 10:10 am Post subject: |
|
Pad looks good, good job. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Oct 21, 2006 12:17 pm Post subject: |
|
What's wrong with how it's in bsnes 0.18?
Anyway, pads from some games: link
_________________
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: Sun Oct 22, 2006 7:26 am Post subject: |
|
creaothceann wrote: |
What's wrong with how it's in bsnes 0.18? |
Not a lot, mainly just a few blending oddities and dullish colors.
Shoulder buttons sink in. Y and B are misaligned. Controller is a bit
shorter than real.
creaothceann wrote: |
Anyway, pads from some games: link |
Thanks, I've seen those and at least fifty others (ah, the "benefits"
of testing 1500 games). But last week I hit the holy grail of
representations in Firepower 2000. Some time with me in photoshop, and
you have another option.
|
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Oct 22, 2006 7:43 am Post subject: |
|
The
left pic looks much much better. I wonder if you could make the letters
a little thicker/bolder... it's not necessary, but the text is slightly
tiny.
_________________
FF4 research never ends for me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 22, 2006 7:44 am Post subject: |
|
I
actually drew mine off a real SNES controller in Photoshop. The reason
for the blending oddities is due to scaling the original (~500x300)
image down to fit on the input configuration screen.
Anyway, I don't like the blueish background much. Doesn't flow well
with windows GUI colors to me. White or a grayish color I think would
be best. Other than that, my only gripe is the B button color being
different from the other buttons. No easy solutions there, of course.
Nice jab with the icons on the bottom, too :P
Now then, how about a logo while we're at it? Any takers? :D
If so, I'm picky about the spelling, all lowercase please :) |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Oct 22, 2006 8:10 am Post subject: |
|
That left controller is awesome, i would use that one! as is! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 22, 2006 8:49 am Post subject: |
|
byuu wrote: |
I actually drew mine off a real SNES controller in Photoshop. |
Was it a third party controller? 
But really, this is why I wished the controller image was referenced
externally. Then users can replace it with their own, and I wouldn't
have to try to argue for something that to me is superior. Apparently,
I got lucky with the new icon 
The navy background with white text matches the area selection
highlight, and the uppercase, white text is easier to pick up quickly
or peripherally than black on gray or white (which is exactly what
deathlike is picking up on, but fails to see the best, not better,
solution). Also notice the left one's d-pad, and how the dark gray
isn't different enough from the darker gray markings within it. This is
aesthetically unpleasant and creates a distracting focal point.
The reason I posted the icons is to show that no one besides myself saw
or attempted to improve upon the color or shape problems, but that they
nonetheless existed.
Last edited by FitzRoy on Sun Oct 22, 2006 10:06 am; edited 1 time in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Oct 22, 2006 9:22 am Post subject: |
|
FitzRoy wrote: |
I've
seen those and at least fifty others (ah, the "benefits" of testing
1500 games). But last week I hit the holy grail of representations in
Firepower 2000. |
Yep, that one looks good, too. Shame though that it's using the US colors. 

_________________
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: Sun Oct 22, 2006 9:43 am Post subject: |
|
creaothceann wrote: |
FitzRoy wrote: |
I've
seen those and at least fifty others (ah, the "benefits" of testing
1500 games). But last week I hit the holy grail of representations in
Firepower 2000. |
Yep, that one looks good, too. Shame though that it's using the US colors. 
|
See: Super SWIV (E, J)
If you're ever on "Who Wants to Be a Millionaire?" and they ask you
anything pertaining to regional name differences on the SNES, go ahead
and phone me.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Oct 22, 2006 10:46 am Post subject: |
|
Fitzroy we're slowly becoming living Snes databases  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Oct 22, 2006 2:16 pm Post subject: |
|
FitzRoy wrote: |
Super SWIV (E, J) |
Good to know. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Sun Oct 22, 2006 11:06 pm Post subject: |
|
Does noone here use vector graphics? Like, Inkscape, or Xara Xtreme Linux? :/ |
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Sun Oct 22, 2006 11:11 pm Post subject: |
|
I remember some dude did not long ago a snes controllers in vectors. It could turn out handy if it is still available.
_________________
_-|-_ |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 23, 2006 4:25 pm Post subject: |
|
Are there any good freeware vector art tools for Windows? I wouldn't mind learning the basics of vector art.
Side note, noticed an error with my S-SMP emulation of most of the mov
opcodes. Apparently, they read the source address before writing. I
think I remember reading that before, but never added it. This doesn't
fix Koushien 2, but the game does seem to get to the third inning every
time now, instead of dying on the first or second, so it's a start.
I wonder how this behavior was discovered, since no games seem to rely
on it. Now I also need to find out / test whether cmp opcodes actually
write back the value read from memory, or if the last opcode cycle for
cmp opcodes is simply an I/O cycle.
Ah, also appears cmpw timing is taking 5 cycles. anomie's doc lists 4.
Possibly a timing error. Also doesn't fix Koushien 2 (nothing ever
does). |
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Mon Oct 23, 2006 11:37 pm Post subject: |
|
byuu wrote: |
Are there any good freeware vector art tools for Windows? I wouldn't mind learning the basics of vector art. |
You can try Xara Xtreme for Linux (GPL), which has almost all of the same features as the $70 Windows version. Grab it here.
Xara Xtreme and Inkscape are the only freeware vector art programs that
are of professional quality that I know of .
|
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Mon Oct 23, 2006 11:39 pm Post subject: |
|
Not that one. The one I mean looked more like out of a blueprint, or something.
Plus, that one is rasterized already.
_________________
_-|-_
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Oct 24, 2006 2:52 am Post subject: |
|
I have the .svg source for one that I did up tonight in Inkscape.

I have a larger exported .png of it hosted on my linux box at http://wpage.homelinux.net/SNES%20Controller.png.
It would take moments to add the "Start" "Select" "X, Y, A, B" labels, but I wanted to get some feedback. |
|
Lex New Member
Joined: 19 Oct 2006
Posts: 2
Location: Waterloo, Ontario, Canada
|
Posted: Tue Oct 24, 2006 3:05 am Post subject: |
|
You could use POV-Ray.
It is even useful for 2D graphics. I've never used it, but a couple of
my friends have made some nice icons with it. It might just be the sort
of thing you'd like to use, byuu, considering your apparent love for
precision. It's not a typical vector graphics program.
Or you could just ignore POV-Ray and stick to typical vector graphics software. I'm no expert. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Oct 24, 2006 4:32 am Post subject: |
|
DataPath wrote: |
I have the .svg source for one that I did up tonight in Inkscape.

I have a larger exported .png of it hosted on my linux box at http://wpage.homelinux.net/SNES%20Controller.png.
It would take moments to add the "Start" "Select" "X, Y, A, B" labels, but I wanted to get some feedback. |
Go back to school and learn a thing or two about perspective. Or try
Povray and model it in 3D so you don't even have to figure that
perspective thing out.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 24, 2006 8:57 am Post subject: |
|
Just following through on what my eyes picked up:
Is that the vector art you're talking about MisterJones? Obvious
problems are no color, and no shoulder buttons. Does give nearly exact
positions and proportions though (like Super SWIV's)
I was experimenting with windows schemes today, and realized that the
navy selection doesn't stay navy with different schemes. For some
reason, I thought that might have been defined in the program. So one
strike against mine (still looks good on my windows scheme, though *grumble grumble*)
FGHIJK (U) games tested. No bugs.
Last edited by FitzRoy on Sun Apr 20, 2008 7:59 am; edited 2 times in total |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Oct 24, 2006 9:01 am Post subject: |
|
kode54 wrote: |
Go
back to school and learn a thing or two about perspective. Or try
Povray and model it in 3D so you don't even have to figure that
perspective thing out. |
lol, that might sound a bit harsh considering the guy was trying to
help, but still, the perspective is indeed fucked up.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 24, 2006 9:25 am Post subject: |
|
I wrote: |
... the S-DSP is completely enslaved to the S-SMP, and only $00f4-$00f7 communicate with the S-CPU anyway ... |
Code: |
..0967 or a,#$30 A:01 X:ff Y:5d SP:013d YA:5d01 nvpbhizc
..0969 mov $0f1,a A:31 X:ff Y:5d SP:013d YA:5d31 nvpbhizc |
I see now. $00f1 (CONTROL) also has the ability to interface with the
S-CPU, because if bits d4 or d5 are set, it clears port values to #$00.
So S-CPU needs to sync CPU<>SMP on accesses to $2140-$217f, and
S-SMP needs to sync SMP<>CPU on accesses to $f1,$f4-$f7.
Super Bomberman 4 now works again, and better yet -- I understand why this time :D
EDIT: aw. I accidentially edited my post instead of quoting it :(
Background: I removed the SB4 fix hoping I could find out what was
causing the "fix" to work, and maybe it would be related to Koushien 2.
Sadly, it wasn't related. But still good that I know why the old fix worked, at least.
Last edited by byuu on Tue Oct 24, 2006 4:04 pm; edited 2 times in total
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Oct 24, 2006 11:23 am Post subject: |
|
Stifu's about got it right. I have no eye for perspective or color, just giving it a shot. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 24, 2006 6:40 pm Post subject: |
|
Koushien
2 has to be the weirdest bug ever. Fairly random each time. Sometimes,
the sound will speed up a minute before it crashes. Others, it just
cuts out completely. Sometimes the cut out and crash happens at the
same time (usually during a transition).
EDIT: "L, M" (U) games tested. 1 bug found.
*Mighty Morphin Power Rangers - The Fighting Edition (U) - corrupt
sprite gfx during gameplay. Does not occur in .016, but does occur from
.017-on.
If it's WRAM related, I'm not counting it against my guesses  |
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Thu Oct 26, 2006 1:54 pm Post subject: |
|
Currently
I am following up with the apu opcodes. Koushien 2 reaches during
gameplay the stop apu opcode (seems randomly like the crash bug) and
loops in it. I don't know if only a reset can kill the stop state like
the CPU. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 26, 2006 2:36 pm Post subject: |
|
Quote: |
*Mighty
Morphin Power Rangers - The Fighting Edition (U) - corrupt sprite gfx
during gameplay. Does not occur in .016, but does occur from .017-on. |
Didn't I already fix this game before? It's probably the damn memory mapper again.
I can't seem to find a perfect map that works for all of these games
that have to screw with what's at $[70-7d|f0-ff]:[0000-ffff].
If someone could please get me the PCB ID for this game, I can fix it
for good by adding it to the ROM database. Overload's list does not
have this game yet.
Quote: |
Koushien
2 reaches during gameplay the stop apu opcode (seems randomly like the
crash bug) and loops in it. I don't know if only a reset can kill the
stop state like the CPU. |
I've known that for a while. Something (likely S-SMP, possibly even
S-DSP) is overwriting opcodes in the main program (stored in SPCRAM of
course), and when the main program hits those overwritten opcodes,
things crash.
Problem is, the address overwritten never shows up in tracelogs, and
every time I run another tracing set with explicit checks for writing
to said memory location, the location overwritten changes.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 26, 2006 3:49 pm Post subject: |
|
You know, I was just praying to myself... "Please god, I want to spend the rest
of my life backtracing fixes to sCPU from bCPU. Fixing the first 287
regressions as a result of the CPU rewrite just wasn't enough... you
know? So please let new bugs just keep appearing forever and ever.
Thank you."
... and it looks like my prayers have been answered! Hooray!
Well, whatever the hell the problem is this time, hopefully it's
related to Street Racer, because I have no idea about that game either.
M7A,B,C,D,X,Y + M7HOFS+M7VOFS all appear completely normal, even when
the screen is glitchy, so tracking that bug would be quite difficult.
(Street Racer also works with bCPU, of course.) |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 26, 2006 4:26 pm Post subject: |
|
"N, O" (U) games tested. 1 bug found (redundant)
Outlander (E, U) - horizontal line issue on title screen. same issue as Mega lo Mania, not affected by hclock. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 26, 2006 6:12 pm Post subject: |
|
If it's the same problem as Mega lo Mania, then we should revert Winter Olympics to fix two games instead of one.
EDIT: yeah, same issue. Swap Mega lo Mania with Winter Olympics, then, and consider Outlander "fixed". |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 26, 2006 7:40 pm Post subject: |
|
byuu wrote: |
You know, I was just praying to myself... "Please god... |
Nice to know you consider yourself a deity.
_________________
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: Thu Oct 26, 2006 9:00 pm Post subject: |
|
byuu wrote: |
If it's the same problem as Mega lo Mania, then we should revert Winter Olympics to fix two games instead of one.
EDIT: yeah, same issue. Swap Mega lo Mania with Winter Olympics, then, and consider Outlander "fixed". |
Bah. Why bother? It's very likely that Winter Olympics isn't alone
either. Check on "The Adventures of Dr Franken (E)" bugging out
similarly in .016-.017. Plus that, I just tested 1000 games since the
Winter Olympics fix, and there's no way to know what that might have
added for that side of things. Besides, line caching is not the
problem. The problem is the scanline renderer. That is as I understand
it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 26, 2006 10:05 pm Post subject: |
|
Quote: |
Nice to know you consider yourself a deity. |
Oops, nice catch. "I was just praying to $deity..."
Alle hageln der grammatik nazi!
Quote: |
Bah.
Why bother? It's very likely that Winter Olympics isn't alone either.
Check on "The Adventures of Dr Franken (E)" bugging out similarly in
.016-.017. |
Because I want my bug list small dammit >_<
If these are counting against me as emulation bugs, then I want to fix
them... sPPU is not going to be an option for a very long time, and
even then it's going to require a Core 2 Duo to possibly get 60fps, most likely.
EDIT: damn. Yeah, Winter Olympics fixed Adventures of Dr Franken. Why
do games insist on doing this weird crap >_<
I'll try and look into something that gets all of them running, but don't get too hopeful.
Code: |
[sCPU]
008c8e lda #$01 A:007e X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzc V:223 H:1058
008c90 sta $420b [$00420b] A:0001 X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzc V:223 H:1074
008c93 ldx #$7e80 A:0001 X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzc V:223 H:1104
[DMA] channel:0 direction:a->b reverse:0 fixed:0 mode:1 b_addr:$2118 a_addr:$7ea800 length:$0100 ( 256)
008c96 stx $2116 [$002116] A:0001 X:7e80 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzc V:225 H: 520
* NMI @ <225, 596>
[bCPU]
008c8e lda #$01 A:007e X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzC V:223 H:1056
008c90 sta $420b [$00420b] A:0001 X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzC V:223 H:1072
008c93 ldx #$7e80 A:0001 X:a800 Y:0000 S:0ff0 D:0000 DB:00 nvMxdIzC V:223 H:1102
* NMI @ <225, 510> |
Problem is, when you perform a DMA, there is a delay before an NMI will
fire if the DMA goes over on top of the NMI trigger position.
A delay too low and wild guns breaks, a delay too high and apparently power rangers and street racer both break.
EDIT:
Wild Guns needs a delay >= 2. I'm guessing the opcode for DMA is sta
$420b in 16-bit mode, so the IRQ is firing immediately after the write
to $420b, at the last_cycle event. I also believe this is where our
false misunderstanding that DMA requires a 24-clock delay after writing.
I think the DMA delay is the same as the sta $4200 NMI enable delay. If
you write sta $4200 in 16-bit mode, an NMI will not fire at the
last_cycle of that opcode, it pushes to the next opcode. I think DMA is
doing the exact same thing.
Anyway, Power Rangers needs a value <= 8, and Street Racer <= 16.
So, a value of 2 allows all three games to work. Consider them fixed,
and I'm somewhat confident it's a proper fix, but we're talking an
extreme edge edge case (yes, an edge case of an edge case, gotta love the SNES).
EDIT 2:
Futher example of my DMA->NMI theorem:
Code: |
[correct]
0089a6 lda #$01 A:007e X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 570
0089a8 sta $420b [$00420b] A:0001 X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 586
0089ab lda #$02 A:0001 X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 616
[DMA] channel:0 direction:a->b reverse:0 fixed:0 mode:1 b_addr:$2118 a_addr:$7eb800 length:$0200 ( 512)
0089ad tsb $66 [$000066] A:0002 X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:226 H: 788
* NMI @ <226, 826>
[incorrect]
0089a6 lda #$01 A:007e X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 512
0089a8 sta $420b [$00420b] A:0001 X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 528
0089ab lda #$02 A:0001 X:b800 Y:0022 S:0ff2 D:0000 DB:00 nvMxdIzc V:223 H: 598
[DMA] channel:0 direction:a->b reverse:0 fixed:0 mode:1 b_addr:$2118 a_addr:$7eb800 length:$0200 ( 512)
* NMI @ <226, 762> |
Now, see in the correct one... DMA triggers at the sta $420b. It's
actually only 8-bit so the opcode ends, and then one last CPU cycle
executes (well, a work cycle but let's not get into pipelining
here...), which is the opfetch for lda #$02. So now the only cycle left
in lda #$02 is the operand load, as it's a 2-cycle opcode. So the DMA
completes, and it's way past time to fire an NMI. So your last_cycle
test trips NMI and it triggers. Once the lda #$02 opcode completes. And
of course, this is incorrect, causing the massive screen flickering.
My hypothesis is that both NMI and IRQ have an edge case where if the NMI or IRQ pin goes high immediately upon last_cycle event, the NMI or IRQ does not happen at this time.
You can verify this behavior via rep #$20 : lda #$ff80 : sta $4200 : nop. The NMI fires after nop, not before.
I believe DMA is invoking the same thing. NMI testing is forced to not
trigger until the end of the DMA somehow, so it also hits this same
edge case of "NMI tripped" and "we're at the last cycle of the opcode"
at the exact same time. Therefore, a delay of 2 clocks means that
last_cycle fails for lda #$02, and the next opcode, tsb $66 executes.
This opcode's last_cycle event passes, and you get your NMI after this
opcode. And hence, you get the correct result, and Wild Guns works.
The theory does tend to complicate NMI/IRQ testing somewhat, however. I
figured the CPU would be polling to trip these opcodes all the time,
but it now seems more practical that it "catches up" when the CPU is
active and [H]DMA is inactive. How this works, I don't know. I'd have
to know EE a lot better than I do and see the hardware schematics to be
certain. But I can at least emulate the effect using only a 2-clock
"delay" after any [H]DMA events occur to protect against this edge
case. The output results should be 100% identical to the SNES, given
the same inputs -- hopefully, at least.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 27, 2006 12:01 am Post subject: |
|
byuu wrote: |
Because I want my bug list small dammit >_< |
It is small! And you just made it smaller
I'll just add "needs sPPU" to these, and at least now it seems there is
only one oddball left. Besides, you can "fix" these any way you see fit
when testing is done, but we can't find them if line caching is taken
out.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 29, 2006 7:27 am Post subject: |
|
Sufami Turbo emulation:

The way you have to load the carts is kind of screwy for now (you use a
text file that lists which carts to load). I need to flesh something
out that works well for end users. Ideas welcome.
Note that both carts need to maintain their own separate save RAM files
in order for it to be possible to play dual mode games. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Oct 29, 2006 10:31 am Post subject: |
|
Hmm I have an idea of sorts..
Code: |
File
-------------
Load Cartridge
Unload Cartridge
--------------
Surfami Turbo>|Load A Slot |
|Unload A Slot |
|------------ |
|Load B Slot |
|Unload B Slot |
|------------ |
|Load Bios |
|
Make sure the unload button gray out so they can tell there's no cart
inserted. Other then that you could probably change the names. I didn't
really put much thought into them.
Edit: Fuck, that didn't turn out very well. The crap after the Surfami
turbo name is supposed to be a single pop out menu. Also one thing I
forgot was don't start the emulation automatically after they load one
of the slots. Have them click power to start the emulation.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Oct 29, 2006 10:49 am Post subject: |
|
Sort of like this?
Code: |
____ ________________________
|File| > |Load Cartridge... |
¯¯¯¯ |Unload Cartridge... | _____________
|Sufami Turbo | > |Load A Slot |
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ |Unload A Slot|
|-------------|
|Load B Slot |
|Unload B Slot|
|-------------|
|Load Bios |
¯¯¯¯¯¯¯¯¯¯¯¯¯ |
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Sun Apr 29, 2007 10:53 am; edited 3 times in total
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Oct 29, 2006 10:51 am Post subject: |
|
That's exactly what I meant, thanks.  |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Oct 29, 2006 10:57 am Post subject: |
|
Byuu,
there seems to be a bug in the scale2x rendering code; here's me
testing it in Seiken Densetsu 3 (using Jap original for testing
purposes):
Normally it's fine:
http://img120.imageshack.us/my.php?image=scale2xokaypk9.jpg
But when dialogs are displayed... (pseudo hi-res mode?):
http://img100.imageshack.us/my.php?image=scale2xbugme8.jpg
I also wish filtering would actually work in that mode
but that's not so important.. this behaviour doesn't happen with any of
the other filters, though the NTSC one looks a bit off when no dialogs
are displayed, as it displays the very right edge of the last dialog on
the right edge of the screen.
Edit: oh, I tested in bsnes 0.018 official, and that accuracy/speed testing build you posted the other day. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Oct 29, 2006 12:33 pm Post subject: |
|
byuu wrote: |
Sufami Turbo emulation:

The way you have to load the carts is kind of screwy for now (you use a
text file that lists which carts to load). I need to flesh something
out that works well for end users. Ideas welcome.
Note that both carts need to maintain their own separate save RAM files
in order for it to be possible to play dual mode games. |
COOL!!!!
thank you for adding this special hardware!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 30, 2006 7:35 am Post subject: |
|
Hmm,
bad news. I misstepped and tried creating a new class to handle lists
of files associated with each ROM for the purpose of ST emulation.
In the end, it turns out I went a little too far with overarchitecting
the code. It makes more sense to leave things as they are, but modify
Cartridge class to handle all files associated with it. Too many major
code changes trying to redo that to safely undo, so I just went ahead
and restored from the wip6 backup I had. Meaning, no more ST emulation,
but only temporarily. wip6 was six days old, but I don't really recall
working on bsnes much last week. I readded the Street Racer
DMA<>NMI sync fix, and the newer versions of my base libs.
Hopefully by next weekend I can have ST emulation added back in again,
and on the plus side, this gives me more time to think how I want to
add support for it. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Oct 30, 2006 5:23 pm Post subject: |
|
you should set up a SVN/CVS repository, if just for yourself.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 30, 2006 5:57 pm Post subject: |
|
Cool, ST support. I wanted to wait for the new WIP to post this, because I wondered if it was related to street racer. It's not:
"P, Q, R" (U) games tested: 1 bug found.
R-Type III (U) - corrupt gfx during gameplay. Appears to have been introduced between .017 and .018. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 30, 2006 6:30 pm Post subject: |
|
Funny
how it's always the same games that keep having problems. Ok, I'll use
revision tests to find out what change broke it, and hopefully fix it.
S (U) is going to suck, as will likely T (U)... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 31, 2006 6:52 am Post subject: |
|
"U, V, W, X, Y, Z" (U) games tested. No bugs. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 31, 2006 3:33 pm Post subject: |
|
What happened to S, T (U) ? Heh.
Working on R-Type III, I have the change narrowed down to v0.017.18 -
v0.017.20. I didn't make a backup of v0.017.19, but that's ok. Also,
the problem is with sCPU changes between those versions. That was the
addition of timeshifting, so it may just be something like an IRQ going
off on line 261 that isn't working correctly or something. We'll see...
---
EDIT: alright, problem found.
Code: |
;old, correct IRQ behavior
* IRQ @ < 6, 20>
* IRQ @ <207, 22>
* IRQ @ <215, 34>
;new, broken IRQ behavior
* IRQ @ < 6, 40>
* IRQ @ < 8, 182>
* IRQ @ <215, 40> |
Code: |
//code causing problem
if(status.virq_enabled == true && status.hirq_enabled == false) {
status.irq_lock = false;
} |
Code: |
;sometime during IRQ routine
81ee49 lda $001a [$81001a] A:010f X:0000 Y:00a4 S:1fdb D:0000 DB:81 nvMXdIzC V: 6 H: 688
81ee4c sta $4200 [$814200] A:01a1 X:0000 Y:00a4 S:1fdb D:0000 DB:81 NvMXdIzC V: 6 H: 714
a1=%10100001
81ee57 lda $0218 [$810218] A:ee6e X:0000 Y:00a4 S:1fdb D:0000 DB:81 NvmXdIzC V: 6 H: 824
81ee5a sta $4209 [$814209] A:00cf X:0000 Y:00a4 S:1fdb D:0000 DB:81 nvmXdIzC V: 6 H: 858 |
The above code is basically writing #$20 to d5,d4 of $4200. My test
ROMs indicate this continues to trigger IRQs repeatedly. However,
R-Type III indicates this should not happen. There's obviously yet
another factor at work here. My current theory is that testing may not
occur at all when the I flag is set. This would cause testing to not
occur until after the IRQ completes, once VCOUNTER is on another line
(8 instead of 6), which would be too late for a VIRQ test to cause
another IRQ to trigger.
I will need to write more tests at home to verify. And I may have to
wait until tomorrow to do this, have some plans for tonight.
Last edited by byuu on Tue Oct 31, 2006 5:16 pm; edited 1 time in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Oct 31, 2006 5:13 pm Post subject: |
|
Im almost done with S and T-Z was already done |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 31, 2006 6:28 pm Post subject: |
|
i
have a question: I know taking advantage of dual cores is not possible
for emulation itself, but wouldn't it be possible to use the other core
for the rendering filters (such as NTSC) or possibly any other task not
directly related to emulation? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 31, 2006 7:19 pm Post subject: |
|
Ideally,
yes. Software video filtering could be passed onto another core. The
more important question would be if it was worth the speed gain for the
added problems. Especially since every dual core on the market can
already easily hit 60fps with current builds.
If
you were trying to use a monster filter like HQ4x which is more
computationally expensive than emulating an entire frame of video, it
would probably lead to a very decent speedup, of course.
But now I have to worry about mutexes, critical sections, semaphores,
locks, deadlocks between the two threads, even more complex debugging
issues, etc.
In short, I'm not really interested in all the additional work for the
small gains associated with offloading the software filtering. Further
that with the fact that most of these filters are now being performed
using pixel shaders which require no CPU power at all. I think time
would be better spent supporting those than in utilizing dual core
CPUs; but that's also not a priority at this point. |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Tue Oct 31, 2006 10:20 pm Post subject: |
|
I
wonder however what kind of speed hit I'd get when turning on filters
like HQ4X with bsnes. NTSC already gave me speed drop but is still way
over 60fps.
_________________
"Change is inevitable; progress is optional" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Nov 01, 2006 5:52 am Post subject: |
|
"S, T" (U) games tested. No bugs found.
Overall, I have a small list of possibles. Will wait until after R-Type to explore. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 01, 2006 9:05 am Post subject: |
|
Quote: |
Overall, I have a small list of possibles. Will wait until after R-Type to explore. |
Damn :(
I don't think the R-Type III fix will correct anything else. But, cross
your fingers I guess. The new WIP fixes the aforementioned game.
My SNES tests seem to indicate that writing #$20 to $4200 when
VCOUNTER==VIRQ will trigger an IRQ, even after an IRQ has already fired
on said line. My tests today indicate that it will not trigger an IRQ
under the above circumstances when the I flag is set. I don't know why,
it's the only thing other than the final IRQ trigger test that cares
what the I flag is set to. I'm not happy with the fix, but it's the
only explanation I can come up with, and all IRQ sensitive games are
running, as well all IRQ tests are still passing. So for now, it'll
have to do.
I'm going to attempt to document all of SNES IRQs and see if I can
figure out a more simple method of emulating them, but I'm not hopeful.
I also removed the "guessed" entries from my database. I've decided not
to add anything unless we definitively know its' PCB ID, or in the case
of ST games, if it doesn't have one.
Lastly, rewrote my SDP page on my site. It now uses XHTML 1.0 + pure
CSS2, so it should be a little easier on the eyes and a lot easier to
write documentation pages for.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Nov 01, 2006 4:07 pm Post subject: |
|
byuu wrote: |
Lastly,
rewrote my SDP page on my site. It now uses XHTML 1.0 + pure CSS2, so
it should be a little easier on the eyes and a lot easier to write
documentation pages for. |
Did you test that page in IE6 or below? IE doesn't like the XML
declaration (the first line), and it's not *required*, you might as
well leave it out. However, that means that character encoding would
have to be UTF-8, although I don't know if that matters to you.
You definitely seem to like your tables . Don't like <div>s?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 01, 2006 4:22 pm Post subject: |
|
Quote: |
Did you test that page in IE6 or below? |
Holy crap the entire page is flashing between no stylesheet and the full stylesheet in IE6. I better replace the @import with a PHP file copy/paste. Thanks, IE.
Quote: |
You definitely seem to like your tables Wink. Don't like <div>s? |
No. They don't work properly, they don't work the same in any
major browser, and they're equivalent to using a chainsaw on a stick of
butter when you're trying to design a site that utilizes the concept of
columns (eg left-side is content, right-right is navigation index).
The tables are done in 100% CSS2, so I don't see a problem with them
personally. But if you have an easy way to implement columns in
<div>s that work in all major browsers, I'll be happy to take a
look at it.
EDIT: ah, and no reason to clutter this thread with HTML programming stuff, please. PM is fine.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Nov 01, 2006 11:46 pm Post subject: |
|
Alrighty, the end of (U) brings a few more confirmations.
J.R.R. Tolkien's The Lord of the Rings - Volume 1 (E, G, U) - flickering boot/head on intro
Michael Jordan - Chaos in the Windy City (E, U) - corrupt gfx behind map, and second map effect has line issues
Ninjawarriors, The (E, U) - sprites flicker during gameplay
Toy Story (E, J, U) - sound effects linger or buzz sometimes between transitions
I should note a few things here.
First, Toy Story was already reported by tetsuo a while ago, and I just
got around to verifying it. It's kind of hard to reproduce, you have to
die a lot sometimes. Almost seems like you have to die in the middle of
some sound effect or note to trigger it. The real system always cuts
out silent with no issues. Seems related to Koushien, but this game
never crashes.
Second, I think Ninjawarriors and LOTR are the same issue. Seems to
have been introduced between .017 and .018. If you stand in front of
the green bikes and allow yourself to be hit, the sprites will flicker
there as well. However, this flickering DOES happen on real, and .016
and .017 behave as they should. In .018, however, there is much more
flickering which should not be happening. For whatever reason, the (J)
version is without issue on any bsnes.
For Michael Jordan, the real system displays black behind both map
effects. All emulators I tested appear to display some kind of corrupt
gfx grid behind the first map. It's a bug. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 02, 2006 12:26 am Post subject: |
|
Well
then, I'm pretty much done with this then. I simply don't have the
patience or perseverance to keep tracking these bugs down. I can't even
keep up with the new bugs anymore.
Besides, there's simply no chance in hell I'm going to be playing Toy Story for several weeks trying to track down a sound bug that's only barely noticeable if at all.
I got into this to work on emulating great games like Final Fantasy,
Metroid 3, Chrono Trigger, Tales of Phantasia, Star Ocean ... and all I
find myself doing is fixing absolute shit I never knew existed like Toy
Story, Bugs Bunny, Koushien 2, three different Power Rangers games, RPM
Racing, Battle Blaze, Super Conflict ...
Consider them all broken for good. I have no intentions of working on
any of these bugs anymore. Sorry, two years is enough for me. I'll keep
working on other useless stuff like a dot renderer and the ever elusive
cross-platform GUI library, but that's about it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Nov 02, 2006 1:45 am Post subject: |
|
byuu wrote: |
Well
then, I'm pretty much done with this then. I simply don't have the
patience or perseverance to keep tracking these bugs down. I can't even
keep up with the new bugs anymore.
Besides, there's simply no chance in hell I'm going to be playing Toy Story for several weeks trying to track down a sound bug that's only barely noticeable if at all.
I got into this to work on emulating great games like Final Fantasy,
Metroid 3, Chrono Trigger, Tales of Phantasia, Star Ocean ... and all I
find myself doing is fixing absolute shit I never knew existed like Toy
Story, Bugs Bunny, Koushien 2, three different Power Rangers games, RPM
Racing, Battle Blaze, Super Conflict ...
Consider them all broken for good. I have no intentions of working on
any of these bugs anymore. Sorry, two years is enough for me. I'll keep
working on other useless stuff like a dot renderer and the ever elusive
cross-platform GUI library, but that's about it. |
I'm saddened to hear this.
Note that I couldn't agree more about the crap like Power Rangers or
any other crappy games like that (and God knows the Super NES had it's
share of crappy games), but I guess from an accurate emulator point of
view "All games are created equals" lol
Imo the bug regressions thing is probably unavoidable. Until not so
long ago, bsnes almost had zero regressions. But as you said yourself,
the closer you get to perfect accuracy, the more often one fix will
break another thing...Even if say version 0.19 has bugs that weren't
present in 0.18 it's not that big of a deal.Hell, Zsnes had counless
fix/regressions/fix/regressions/fix... over the years. But ultimately,
it's your emulator.
/Snarkarob (praying byuu was only momentarily pissed...)
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Thu Nov 02, 2006 5:54 am Post subject: |
|
Hey, Bugs Bunny in Rabbit Rampage is a decent game.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Nov 02, 2006 2:22 pm Post subject: |
|
byuu wrote: |
I have no intentions of working on any of these bugs anymore. [...] I'll keep working on other stuff like a dot renderer |
Sounds like fun. Might simplify the code a bit, too.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 02, 2006 4:10 pm Post subject: |
|
Quote: |
/Snarkarob (praying byuu was only momentarily pissed...) |
No, I'm quite serious.
I'm obviously incapable of fixing S-APU related bugs (Koushien 2, Toy
Story, ...), require a dot-based renderer to fix some bugs (Mega lo
Mania, Outlander, Uniracers, ...), am just plain embarassed to be seen
"playing" some of these games at work (Toy Story, Michael Jordan, ...),
and am absolutely sick
of regression bugs (LoTR, Ninjawarriors). Besides, fixing any of these
will just break other games anyway. I think it's best to just leave the
crappy games broken. And who knows, maybe if I start working on core
emulation and my own custom tests again, some of these will fix
themselves.
Sorry.
---
So anyway, I've probably mentioned this in the past, but how does
everyone feel about a raster based UI, ala ZSNES but attractive?
I'll either have to create a more limited UI than I currently have and
a cross-platform wrapper for Win32 API + GTK+, etc etc. and only allow
building on ports that have said wrapper, or I can design a raster UI
that will build on any platform one can get a framebuffer on (including
consoles like the PS3, assuming the newer systems ever get cracked,
heh).
The raster UI also has the key advantage of being 100% completely
controllable using a joypad; as well as allowing the UI to be visible
in fullscreen mode with triple buffering.
I would basically design it to run at any resolution and be totally
themeable. The only thing I see as very impractical would be using
256x224 mode.
The downside of a raster UI is that even the prettiest raster would
still look a lot worse than one's native UI, IMO.
I really don't want to maintain two separate UIs, though I guess I
could do that for just Windows, and let Linux et al use the other one.
Yeah, that's probably what I'll end up doing...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Nov 02, 2006 8:16 pm Post subject: |
|
byuu wrote: |
Quote: |
/Snarkarob (praying byuu was only momentarily pissed...) |
No, I'm quite serious.
I'm obviously incapable of fixing S-APU related bugs (Koushien 2, Toy
Story, ...), require a dot-based renderer to fix some bugs (Mega lo
Mania, Outlander, Uniracers, ...), am just plain embarassed to be seen
"playing" some of these games at work (Toy Story, Michael Jordan, ...),
and am absolutely sick
of regression bugs (LoTR, Ninjawarriors). Besides, fixing any of these
will just break other games anyway. I think it's best to just leave the
crappy games broken. And who knows, maybe if I start working on core
emulation and my own custom tests again, some of these will fix
themselves.
|
Oh. I was afraid you were thinking of abandoning bsnes and/or your goal
of making bsnes a highly accurate emulator. I definitely agree with
your logic then.
Request: could you post some of the past binaries on your site? 0.17
would be nice to have, since it plays fine some of the games that broke
between 0.17 and 0.18 (R-type for example)
Quote: |
So
anyway, I've probably mentioned this in the past, but how does everyone
feel about a raster based UI, ala ZSNES but attractive? I'll either
have to create a more limited UI than I currently have and a
cross-platform wrapper for Win32 API + GTK+, etc etc. and only allow
building on ports that have said wrapper, or I can design a raster UI
that will build on any platform one can get a framebuffer on (including
consoles like the PS3, assuming the newer systems ever get cracked,
heh).
The raster UI also has the key advantage of being 100% completely
controllable using a joypad; as well as allowing the UI to be visible
in fullscreen mode with triple buffering.
I would basically design it to run at any resolution and be totally
themeable. The only thing I see as very impractical would be using
256x224 mode.
The downside of a raster UI is that even the prettiest raster would
still look a lot worse than one's native UI, IMO.
I really don't want to maintain two separate UIs, though I guess I
could do that for just Windows, and let Linux et al use the other one.
Yeah, that's probably what I'll end up doing... |
Sounds good, although I think visually Zsnes's GUI is pretty solid.
Personally I tend to prefer GUIs that move away from the very generic
windows-style interface (a la Snes9X) but I know there are as many
people that prefer the more traditional style, so it's all personal
preferences.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 02, 2006 10:08 pm Post subject: |
|
Quote: |
Second,
I think Ninjawarriors and LOTR are the same issue. Seems to have been
introduced between .017 and .018. If you stand in front of the green
bikes and allow yourself to be hit, the sprites will flicker there as
well. However, this flickering DOES happen on real, and .016 and .017
behave as they should. In .018, however, there is much more flickering
which should not be happening. For whatever reason, the (J) version is
without issue on any bsnes. |
Quote: |
::PM message, not copying and pasting out of courtesy:: |
Fine, fine. Yes, same issue as Mega lo Mania and Outlander: OAM caching.
So now that's four games broken with it, two games broken without it.
I'm making it a config file option, and I'll even stick it on the
emulation settings page. Default will be off, sorry TRAC. Too many
games are affected by this.
And again to reiterate, there's no way in hell you're getting me to
play Toy Story for the next three weeks at work. Not going to happen.
Perhaps we can beg DMV27 to take a look at this one? :)
Otherwise, see if it happens in another emulator, and I can see if any other emu authors care to investigate.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Nov 02, 2006 10:42 pm Post subject: |
|
If you're referring to me, I said I wanted you to not spend any more time on Toy Story or Koushien. 
I'm satisfied with the line caching option, though I'll have to shuffle
my buglist. So technically, that means sPPU is once again needed to fix
those games proper. That leaves Jordan all alone. Now this is one you
might be able to get someone else to look at, as it happens in all emus.
As per request, I'm finishing (E) this weekend.
"#, A, B, C, D, E, F, G, H, I" (E) games tested. No bugs or possibilities. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 02, 2006 11:19 pm Post subject: |
|
Quote: |
I'm satisfied with the line caching option, though I'll have to shuffle my buglist. |
I say keep all the games that are there already; and add Winter
Olympics + that European game as well. I recommend moving them to a
separate section and mentioning the config file option to toggle the
behavior and which it needs. I'm going to name the option something
like "bppu.hack.___" or "hack.bppu.____" or something, just so it's
clear what it is. The scanline render position option shall be
similarly renamed.
I've been planning to write an article for SDP explaining in detail the
accuracies and shortcomings of all emulators. I'll be sure to discuss
the above two issues involving the PPU there, so you have something to
link to explaining the issue in more detail.
sPPU is going to be really, really really really hard to make. And I
doubt it will even fix these issues for a long, long time. Not to
mention the monstrous CPU requirements it will need.
As for Michael Jordan, yeah. I can't test SNESGT because it crashes
when I load the game, but all five other emulators have the exact same
corruption on BG2, and line glitchiness on the next screen. I posted
about this on the SNES9x forum to see if anyone wanted to help.
Still interested to know about Toy Story in other emulators; especially the grandmaster of the S-DSP, SNEeSe.
Quote: |
As per request, I'm finishing (E) this weekend.
"#, A, B, C, D, E, F, G, H, I" (E) games tested. No bugs or possibilities. |
Neat! I was exepecting a lot worse from PAL region timing. Would you
mind testing all of the other regions while you're going through (E),
since there's only ~40 of them anyway? :)
Up to you though, we can do a separate run through those after (E) as well.
Once again, I thank you for so graciously testing all of these games.
We now have a clear understanding of the exact importance of truly
accurate PPU emulation.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Nov 02, 2006 11:27 pm Post subject: |
|
I did those smaller regions a while ago. I could go through them again, but I doubt we'd find anything new. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 02, 2006 11:38 pm Post subject: |
|
Quote: |
I did those smaller regions a while ago. I could go through them again, but I doubt we'd find anything new. |
Oh, really? Neat. Less to worry about. So then, (E) will finally finish this. Yay!
Think of the PPU as a signal processor, and not as an instruction
processor. The PPU has its' own internal program that we cannot see.
The only way we can give it input is by writing to the CPU at very
specific times. The only way we can see the results of that input is by
looking at blurry images produced on TV sets. We have to basically
reverse engineer the entire internal logic of the PPU through
experimentation. Think of it as the same issue as the DSP-1. Only the
PPU is an order of magnitude or two more complex, by nature of having
64 different registers, each with several controls each, that all
interact in strange and frightening ways.
Further, the PPU is actually two separate processors. So I either need
two separate cothreads for PPU emulation, or I have to find a way to
merge their behavior into a single thread. Either way will not be easy.
Trust me, there's a reason this has never been done before. And why
even the NES scene still doesn't have a fully functional dot-based
renderer despite having people smart enough to design actual physical
hardware for testing the internal behavior of these chips.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Nov 02, 2006 11:51 pm Post subject: |
|
byuu wrote: |
Otherwise, see if it happens in another emulator, and I can see if any other emu authors care to investigate. |
In regards to LOTR, I remember pf telling me something to the effect
that when you told him some info on correcting IRQ, he tried it and it
worked good but broke LOTR.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 03, 2006 12:39 am Post subject: |
|
Quote: |
In
regards to LOTR, I remember pf telling me something to the effect that
when you told him some info on correcting IRQ, he tried it and it
worked good but broke LOTR. |
Yes, unfortunately IRQs are ridiculously complex. I keep finding out
new stuff every few days. I can try and get an updated document on IRQ
behavior for pagefault if he's interested. But I'm still not confident
I have the behavior down 100%. No emulator does, for what it's worth.
Regarding that little flickering dot in the intro of LOTR, that is
definitely related to the OAM caching code, because I changed exactly
that and the problem went away. Reverted it and the problem reappeared.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 03, 2006 3:47 am Post subject: |
|
I thought I just explained why x.x
Ok, think of it like this. There are ~224 scanlines in a frame. There
are ~341 dots (256 visible) dots on a scanline, ~76,384 dots in a
frame. The PPU clock runs at 2-4 times that (2x from the CPU's
perspective). So, essentially, the dot based renderer has to break
things down to be 682x more precise than a scanline-based renderer.
Just stepping dot by dot as if it were a scanline based renderer would
be easy, just a lot slower. But actually gauging what happens when you
write to registers during the active display, is quite a lot more
complex.
If you still don't follow, I'm sorry. Just trust me that it's a lot harder :/ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 03, 2006 4:06 am Post subject: |
|
byuu wrote: |
Regarding
that little flickering dot in the intro of LOTR, that is definitely
related to the OAM caching code, because I changed exactly that and the
problem went away. Reverted it and the problem reappeared. |
I've changed my description of this bug to elaborate that this is not
intro specific. If you start a new game and walk in front of one of the
sitting hobbits, cancelling out the dialogue, you'll see that whenever
a sprite tries to occlude another sprite, it flickers heavily - just
like Ninjawarriors. It's just easier to see on the intro because that
pixel is the only place where a sprite was positioned occluding part of
another.
Most of the time, this is supposed to happen on real hardware (Contra
III 2 player, Kamen Rider), but I noticed LOTR as a possible bug
because that was one of the games I used to own as a kid and I've seen
the intro a hundred times before.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Nov 03, 2006 5:51 am Post subject: |
|
byuu wrote: |
Just
stepping dot by dot as if it were a scanline based renderer would be
easy, just a lot slower. But actually gauging what happens when you
write to registers during the active display, is quite a lot more
complex. |
That's what I was looking for. Thanks for the explanation. I trust you
that it's a lot harder; I'm just interested though.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 03, 2006 7:58 am Post subject: |
|
Ok,
the new WIP adds ppu.hack.obj_cache = [true/false], and renames the
scanline render pos to ppu.hack.scanline_render_position = [dec].
OBJ cache defaults to off now, as two bugs are better than four.
Made SDP a bit more friendly to view now. I may port that style over to
my main website, too. Specifically the non fixed width part. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 03, 2006 9:33 am Post subject: |
|
byuu,
I think I'm going to appeal for hclock to be defaulted to ~512 for
future versions. I've been testing with it for a while now, and it
seems stable while fixing line issues with:
Battle Blaze (swirling ghost, final boss effect)
Super SWIV/Fire Power 2000 (title screen)
Super F-1 Hero (gameplay)
Jurassic Park (intro effect)
While true that Super F-1 Hero has an issue on real hardware, the
scanline renderer can't reproduce it correctly anyway. At least 512
looks nice. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Nov 03, 2006 11:28 am Post subject: |
|
Fitzroy your on a roll!
Great work man.
Byuu, im glad your finally pissed at these bugs!
Its better to tackle the core emulation with all know bugs in hand,
than to try and fix those horrible games one at a time.
Eventhough the final buglist is going to be +/- 5 to 10 games or so,
keep in mind that your emulator still has the highest compatibility
without hacks of any snes emulator.
Also im guessing your emulator is the first to have a full testrun of
all know snes games done for it, as we have found at least 3 bugs that
happen in other emulators.
As far as i can see, exclusing those bugs your core emulation is
basically finished, as you say yourself the only further core
enhancement that can be don is the dot based renderer.
The rest would be special chips and hardware |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 03, 2006 4:23 pm Post subject: |
|
Quote: |
byuu, I think I'm going to appeal for hclock to be defaulted to ~512 for future versions. |
Ok, I'll try and remember to set it to 512 tonight. Remind me if I forget, please.
Quote: |
Eventhough
the final buglist is going to be +/- 5 to 10 games or so, keep in mind
that your emulator still has the highest compatibility without hacks of
any snes emulator. |
Eh, the differences between bsnes and other emulators are infinitesimal
compared to the differences between bsnes and real hardware.
It's also debatable that my entire PPU core is a giant hack (hence the
config file hack options) targeted toward speed and compatibility.
The first thing I need to do is add a timing system into bPPU, and add
cothreading support to it, so that I can actually build both bPPU and
sPPU into the same emulator. Right now, I can't even start on sPPU
without having a completely unplayable emulator result.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 03, 2006 7:52 pm Post subject: |
|
byuu wrote: |
Ok, I'll try and remember to set it to 512 tonight. Remind me if I forget, please. |
Cool, thanks. Now users will hopefully not have any reason to dick with
hclock and bsnes will be better out of the box. 400-700 seems to be the
sweet spot. I don't think anyone's going to care much about anthrox or
super f-1 hero not showing their graphics anomalies if that's what it takes to prevent the ones your emulator might introduce.
Scanline-based renderer may be a hack, but it's a hell of a good one to
achieve 99.98% identical game output without being per-game specific,
and have a 50% speed benefit. Practically an optimization if it weren't
for a few shitty games wanting line caching.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 03, 2006 9:06 pm Post subject: |
|
Quote: |
That leaves Jordan all alone. |
Well, we can't have that, can we?
Before:

After:


Quote: |
Now this is one you might be able to get someone else to look at, as it happens in all emus. |
I was hoping so, but my impatience got the best of me again. What can I
say, "if you want something done right...", heh.
For those interested (read: all SNES emulator authors):
Our old formula for all scrolling registers, $210d-$2114 was:
Code: |
BGnxOFS = (DATA << 8) | (BGOFSLATCH & ~7) | ((BGnxOFS >> 8) & 7);
BGOFSLATCH = DATA; |
Now, this makes sense. The &~7 is identical to the effect seen in
offset-per-tile mode. However, the effect does not apply to OPT VOFFSET
modifications. The reason is obvious for OPT, the SNES can easily
update VOFFSET, but since it renders tile by tile, it has trouble with
those low 3-bits of HOFS. So then, why were we applying to to BGnVOFS
as well? We shouldn't be. The following fixes Michael Jordan: Chaos in
the Windy City to work exactly as FitzRoy and I have observed on a real
SNES:
Code: |
BGnHOFS = (DATA << 8) | (BGOFSLATCH & ~7) | ((BGnHOFS >> 8) & 7);
BGOFSLATCH = DATA;
BGnVOFS = (DATA << 8) | (BGOFSLATCH);
BGOFSLATCH = DATA; |
Since I'm at work, I can't write any tests on the real SNES. And
honestly, I'm kind of not wanting to. This seems to work great and
makes perfect sense, so I'll leave that to someone else. Theme Park
should be retested with these changes, since that was the game that
convinced anomie to continue reverse engineering these registers in the
first place.
Anyway, long story short, the old algorithm was resulting on all of the
"hidden" scanlines being indexed at Y=VOFFSET+BG2VOFS==224, excluding
every 8th line, which hit the &~7 edge case and caused the
backscreen area to get rendered instead (see those white lines in the
before screenshot at the bottom? that's where they come from). With the
above changes, it always indexes at Y=VOFFSET+BG2VOFS==223, which is
black tiledata. Much better.
EDIT: yeah, Theme Park (J) still works fine with the above changes. No differences at all that I can see.
Previous reference for those who need a refresher on how these registers work:
http://www.snes9x.com/phpbb2/viewtopic.php?t=1715&
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 04, 2006 12:19 am Post subject: |
|
Brutal  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Nov 04, 2006 10:38 am Post subject: |
|
Redesigned
my site a bit. Look ok? Mostly just moved everything I could into a CSS
stylesheet, allowed the content window to expand to the full width of
the window, added in a proper firefox scrollbar hack (so it's always
visible and doesn't cause harsh repositioning of the contents menu),
and took advantage of the CSS3 opacity property for browsers that
support it.
Hopefully the text isn't too hard to
read, opacity is an inherited attribute, so the entire page acquires
the attribute, even text o_O. No way to override that, but this is a
million times easier than four separate translucent PNGs, and even
better -- it doesn't totally break the color scheme in browsers that do
not support opacity.
I should be able to design a few alternate stylesheets now as well. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Sat Nov 04, 2006 11:30 am Post subject: |
|
Site looks good, text is totally legible, no worry... |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Nov 04, 2006 1:35 pm Post subject: |
|
Wohoo another bug fixed!
byuu, the site looks great now! the old feeling back but with a new better look |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 04, 2006 10:48 pm Post subject: |
|
"J, K, L, M, N, O, P, Q, R" (E) games tested. 2 bugs found.
Mystic Quest Legend (E) - hangs on mountain entrance transition.
-Appears to have been introduced between .017 and .018 offical. (J) and (U) versions of the game seem unaffected.
RoboCop vs the Terminator (E, J, U) - screen flickers during gameplay
-We knew about this one earlier, but it appears to have been
re-introduced from the R-Type III fix between .018 official and the
latest WIP.
Don't flip out too much, byuu, this isn't that bad of a result.
By the way, I have some other interesting news to report. Koushien 2
randomly crashes Sneese, and Toy Story's sound issue is also present in
TRAC's emu. So you two have something in common here. Surprisingly,
neither game has issues in ZSNES. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 05, 2006 2:09 am Post subject: |
|
Quote: |
Mystic Quest Legend (E) - hangs on mountain entrance transition. |
FAVOR_SPEED it is from now on. Wonderful. I don't know what the fuck is
wrong with the other IRQ testing method. Whatever, it'll work in future
WIPs, and they'll be faster too.
Quote: |
RoboCop vs the Terminator (E, J, U) - screen flickers during gameplay |
It's either this game or R-Type III, then. They expect the exact
opposite behavior of each other. And since R-Type doesn't suck, this
one stays broken.
All IRQ stuff as usual. I can't get IRQ emulation that works everywhere
no matter how hard I try. I've spent probably 20-30% of all bsnes
development time trying to understand them. The SNES just has an
absolutely ridiculously complex IRQ system.
Quote: |
By
the way, I have some other interesting news to report. Koushien 2
randomly crashes Sneese, and Toy Story's sound issue is also present in
TRAC's emu. So you two have something in common here. Surprisingly,
neither game has issues in ZSNES. |
Hopefully TRAC won't mind taking a look at these games, then. I guess
Koushien 2 is most likely S-DSP related then. Perhaps the echo buffer
writes are going to the wrong address, I don't know. I know barely
anything about the S-DSP.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 05, 2006 3:43 am Post subject: |
|
byuu wrote: |
FAVOR_SPEED
it is from now on. Wonderful. I don't know what the fuck is wrong with
the other IRQ testing method. Whatever, it'll work in future WIPs, and
they'll be faster too. |
Could you elaborate on this a bit? I just want to know if there's any
chance that this could break more games than it fixes. I can't really
backtest 3000 games and was under the impression that favor_accuracy
was something of a safety precaution that could never exhibit more
issues than favor_speed.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 05, 2006 3:47 am Post subject: |
|
The
two FAVOR_ switches just go between the two separate IRQ testing
routines. Apparently, FF:MQ (E) is hitting some sort of edge case in
the ACCURACY one, causing the game to crash. I'm not sure what's
causing it, just that SPEED works fine, so for now, SPEED it is. I'd
prefer you finish testing S-Z (E) with the WIP you have (which is set
to ACCURACY, obviously), and I'll work out what's wrong with ACCURACY
later when I'm feeling more masochistic again. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Sun Nov 05, 2006 1:45 pm Post subject: |
|
Aah...the
WIP News page scrolls very,very slowly with Firefox 2.0. 100% CPU usage
and slow as &^*% with smooth scrolling.Haven't seen any page do
this before (and I'm even using a PGO SSE optimized Firefox) Weird. |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Sun Nov 05, 2006 11:44 pm Post subject: |
|
byuu wrote: |
I
guess Koushien 2 is most likely S-DSP related then. Perhaps the echo
buffer writes are going to the wrong address, I don't know. |
That seems to be exactly what the game is doing.
Code: |
// Reg: Echo Write, ESA, EDL, current offset / target, ad = esa + off
EDL: ew 1, esa D800, edl 0000, off 0C14, tar 2000, ad E414
ESA: ew 1, esa F800, edl 0000, off 0C14, tar 2000, ad 0414
FLG: ew 0, esa F800, edl 0000, off 0C18, tar 2000, ad 0418
...
EDL: ew 1, esa D800, edl 0000, off 10B0, tar 2000, ad E8B0
ESA: ew 1, esa F800, edl 0000, off 10B4, tar 2000, ad 08B4
FLG: ew 0, esa F800, edl 0000, off 10B4, tar 2000, ad 08B4
...
EDL: ew 1, esa D800, edl 0000, off 12C8, tar 2000, ad EAC8
ESA: ew 1, esa F800, edl 0000, off 12C8, tar 2000, ad 0AC8
FLG: ew 0, esa F800, edl 0000, off 12CC, tar 2000, ad 0ACC
STP: ew 0, esa F800, edl 0000, off 0000, tar 0000, ad F800
|
When the game wants to change the echo buffer address, it first sets
EDL to zero, then changes ESA, and finally it disables echo writes.
However, sometimes an echo write will happen between ESA and FLG, which
can be seen by the change in ad -> ad + 4. The write can happen
anywhere between 0xF800 and 0x1800. Either the game requires insane
sub-sample accurate timing, or one of those register writes sets
"echo_index = 0" and possibly sets "echo_target = echo_size".
In Toy Story, if you pause the game while a sound effect is playing
(such as an airplane or helicopter) sometimes the effect keeps playing
with the music muted. I don't know if this happens on real hardware.
Also, this problem might be related to the extended buzzing sounds that
happen in "Dokapon Gaiden - Honoo no Audition" and also the BS version
which NSRT labels as "Hono" instead of "Honoo". The sounds usually
occur during screen fades from the battle action to the battle menu.
These bugs might have something to do with the KON/KOFF register decay
that breaks Der Langrisser, but I haven't tested it yet.
Also for anyone interested: Clay Fighter 1 and 2 both require BRR
decoding to never stop, even after KOFF is set or a sample ends. This
is mentioned in anomie's dsp document, but these are the only games
that I know of that require this behavior to work properly.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 05, 2006 11:48 pm Post subject: |
|
"STUVWXYZ" (E) games tested. 1 bug found.
Secret of Mana (all regions) - mode7 map after intro flickers. Pretty much the same thing as Street Racer.
Welp, first run-through has come to an end. Won't be doing that again
for another few years. Basically, all that's popping up anymore are
these IRQ edge cases affecting good as well as bad games. So if you
ever figure out the last pieces of this IRQ puzzle, you'll be sitting
pretty.
Lastly, I take back what I said about hclock. Removing line caching
changes the behavior of some games and 512 is no longer recommended.
Everything except Jurassic Park now works okay at 224, including
anthrox. 256 breaks Super SWIV. I'll just stfu about hclock from now on
since it's confusing the hell out of me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 06, 2006 2:58 am Post subject: |
|
Quote: |
When
the game wants to change the echo buffer address, it first sets EDL to
zero, then changes ESA, and finally it disables echo writes. However,
sometimes an echo write will happen between ESA and FLG, which can be
seen by the change in ad -> ad + 4. The write can happen anywhere
between 0xF800 and 0x1800. Either the game requires insane sub-sample
accurate timing, or one of those register writes sets "echo_index = 0"
and possibly sets "echo_target = echo_size". |
Hmm... if you can think up any tests for this, we can try it on
hardware to see. I'd probably need an SMC to run on the copier, though.
I'm incredibly awful at writing tests for the S-DSP. Though obviously
it's time I start learning...
I hope we don't need sub-sample timing, because there's no way we're
going to be able to reverse engineer that kind of information without
some special testing hardware I don't have access to. Though simply
increasing the clock rate >32khz won't be a problem for me, at least.
Quote: |
In
Toy Story, if you pause the game while a sound effect is playing (such
as an airplane or helicopter) sometimes the effect keeps playing with
the music muted. I don't know if this happens on real hardware. Also,
this problem might be related to the extended buzzing sounds that
happen in "Dokapon Gaiden - Honoo no Audition" and also the BS version
which NSRT labels as "Hono" instead of "Honoo". The sounds usually
occur during screen fades from the battle action to the battle menu.
These bugs might have something to do with the KON/KOFF register decay
that breaks Der Langrisser, but I haven't tested it yet. |
It's a real shame anomie isn't around much anymore, because I really
can't offer you any insight here. Perhaps I can direct TRAC to this
thread to see what he thinks.
Thank you very much as always for looking into these issues for me. If
you can think of any way for me to help, I'll be very happy to.
Quote: |
Also
for anyone interested: Clay Fighter 1 and 2 both require BRR decoding
to never stop, even after KOFF is set or a sample ends. This is
mentioned in anomie's dsp document, but these are the only games that I
know of that require this behavior to work properly. |
Does anomie's S-DSP core always run BRR indefinitely? I haven't noticed any issues in Clay Fighter 1 or 2 yet.
Quote: |
Welp, first run-through has come to an end. Won't be doing that again for another few years. |
Thanks a million for testing all of those games for me. We shouldn't
have to retest everything anyway. We know it's the same games that keep
breaking and rebreaking again, so we really only need to retest those
on occasion. The majority of SNES games, it appears, were written by
people with a clue. But by testing all of them, we've uncovered a dozen
or two of the worst games ever written. Lucky us.
Quote: |
Lastly,
I take back what I said about hclock. Removing line caching changes the
behavior of some games and 512 is no longer recommended. Everything
except Jurassic Park now works okay at 224, including anthrox. 256
breaks Super SWIV. I'll just stfu about hclock from now on since it's
confusing the hell out of me. |
... so what do you want hclock to be set at from now on? >_<
Yeah, this is why I dislike hacks so much. But this one's going to be necessary for a long while, unfortunately.
As an aside, I'm working on adding back in ST support. I have the
single cart mode mostly working now. I've decided to go with fixed
names for the BIOS files, and add a new "path.bios" config file
variable for specifying the folder to find all of these files. I'm also
going to give in and start sticking folders in with releases of bsnes.
The default for path.bios is "./bios" now.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Nov 06, 2006 4:06 am Post subject: |
|
byuu wrote: |
Thanks
a million for testing all of those games for me. We shouldn't have to
retest everything anyway. We know it's the same games that keep
breaking and rebreaking again, so we really only need to retest those
on occasion. The majority of SNES games, it appears, were written by
people with a clue. But by testing all of them, we've uncovered a dozen
or two of the worst games ever written. Lucky us. |
No problem, glad it's done. On the IRQ thing, yeah we seem to have
enough example games. My list now looks like this:
Watchables
----------
Zan III - Spirits
Energy Breaker
Jumbo no Ozaki Hole in One
Sink or Swim
World Class Rugby
Bugs Bunny - Rabbit Rampage
IRQ Watchables
--------------
Chou Aniki
Mystic Quest Legend
Wild Guns
Street Racer
Robocop versus The Terminator
R-Type III
Might Morphin Power Rangers - The Fighting Edition
Secret of Mana
If you can get all the games on the second list working at once, and
the fix makes sense to you, the likelihood that you've figured out IRQ
is that much greater. That's the benefit that hopefully all this
testing has given you.
By the way, I just investigated DMV27's suspicion regarding the sound
effects persisting after pausing the game (Toy Story). I just verified
that this does NOT happen on the real hardware. It cuts off clean every
time, and zsnes does it right but bsnes and sneese sometimes persist
the plane engine sound effect through pause. This is MUCH easier to
trigger and hear than the other bugs, so hopefully that helps you guys
track this down, whatever it is. Great discovery, DMV27.
byuu wrote: |
...
so what do you want hclock to be set at from now on? >_< Yeah,
this is why I dislike hacks so much. But this one's going to be
necessary for a long while, unfortunately. |
Which is why I've been trying so hard to find the best value. A perfect
value apparently doesn't exist. 224 would be perfect if it weren't for
stupid Jurassic Park. At 512, NHL 94/Super SWIV screw up and
Anthrox/Super F1 are further from their true output. Line caching was
apparently Battle Blaze's problem, and it works fine now at lower
hclocks. So I recommend 224, I guess. If new information comes up,
great, we can change it again. Not a big deal, I guess.
byuu wrote: |
I'm also going to give in and start sticking folders in with releases of bsnes. The default for path.bios is "./bios" now. |
thankyouthankyouthankyou.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 06, 2006 7:51 am Post subject: |
|
Ok, the new WIP is extremely fragile with ST stuff, but it should work if you're careful.
It took a lot
of rewriting to get those damn dual carts booting. Right now,
everything but the SD Gundam games are in the database. I need to think
of a way of combining those. So, the only other dualable game is SD
Ultra Battle - Ultraman Densetsu + Seven Densetsu. Otherwise, test with
just one ST cartridge at a time.
Anyway, it's
definitely a work in progress, so be gentle with it. You need
"stbios.bin" in bsnes.cfg::path.bios for it to work. It probably won't
even give you an error if it isn't there.
Suggestions for how to layout the file menu are welcome. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Nov 06, 2006 10:36 am Post subject: |
|
Damn fitzroy, your lightning fast! where do you find the time!!
I'm glad the testrun is finished, now that all games have been tested
we have the final buglist. with this information in hand all there is
left to do is figure out those IRQ's do PAL timing/irq tests and hope
blargg soon creates the PAL filter (because then i can retire my snes) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 06, 2006 6:15 pm Post subject: |
|
Mystic Quest Legend (E) mystery solved.
Code: |
* IRQ @ < 7, 26> : 10 < 7,232>
000117 jml $00b898 [$00b898] A:1100 X:0002 Y:000a S:1fee D:2100 DB:0c nvMxdIZC V: 7 H: 88
00b898 rep #$30 A:1100 X:0002 Y:000a S:1fee D:2100 DB:0c nvMxdIZC V: 7 H: 120
00b89a phb A:1100 X:0002 Y:000a S:1fee D:2100 DB:0c nvmxdIZC V: 7 H: 142
00b89b pha A:1100 X:0002 Y:000a S:1fed D:2100 DB:0c nvmxdIZC V: 7 H: 164
00b89c phx A:1100 X:0002 Y:000a S:1feb D:2100 DB:0c nvmxdIZC V: 7 H: 194
00b89d sep #$20 A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:0c nvmxdIZC V: 7 H: 224
00b89f phk A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:0c nvMxdIZC V: 7 H: 246
00b8a0 plb A:1100 X:0002 Y:000a S:1fe8 D:2100 DB:0c nvMxdIZC V: 7 H: 268
00b8a1 stz $4200 [$004200] A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIZC V: 7 H: 296
00b8a4 lda $2137 [$002137] A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIZC V: 7 H: 326
00b8a7 lda $213f [$00213f] A:1121 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 356
00b8aa lda $213d [$00213d] A:1151 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 386
00b8ad sta $0118 [$000118] A:1107 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 416
00b8b0 lda #$40 A:1107 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 448
00b8b2 and $00da [$0000da] A:1140 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 464
00b8b5 bne $b8c2 [$00b8c2] A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIZC V: 7 H: 496
00b8b7 lda $0118 [$000118] A:1100 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIZC V: 7 H: 512
00b8ba asl a A:1107 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 584
00b8bb adc $0118 [$000118] A:110e X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzc V: 7 H: 598
00b8be adc #$0f A:1115 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzc V: 7 H: 630
00b8c0 pha A:1124 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzc V: 7 H: 646
00b8c1 plp A:1124 X:0002 Y:000a S:1fe8 D:2100 DB:00 nvMxdIzc V: 7 H: 668
00b8c2 lsr $0118 [$000118] A:1124 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzc V: 7 H: 696
00b8c5 bcc $b8a4 [$00b8a4] A:1124 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 742
00b8c7 ldx #$b8da A:1124 X:0002 Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 758
00b8ca stx $0118 [$000118] A:1124 X:b8da Y:000a S:1fe9 D:2100 DB:00 NvMxdIzC V: 7 H: 782
00b8cd lda #$11 A:1124 X:b8da Y:000a S:1fe9 D:2100 DB:00 NvMxdIzC V: 7 H: 822
00b8cf sta $4200 [$004200] A:1111 X:b8da Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 838
00b8d2 cli A:1111 X:b8da Y:000a S:1fe9 D:2100 DB:00 nvMxdIzC V: 7 H: 868
00b8d3 wai A:1111 X:b8da Y:000a S:1fe9 D:2100 DB:00 nvMxdizC V: 7 H: 882
* IRQ @ < 8, 952> : 01 < 7,232>
000117 jml $00b8da [$00b8da] A:1111 X:b8da Y:000a S:1fe5 D:2100 DB:00 nvMxdIzC V: 8 H:1014 |
See, after the WAI instruction, it's waiting an entire scanline.
Problem was that I was never testing IRQ when IRQ lock was set, even
for HIRQs. That was incorrect, the IRQ lock was only something that
occurs with VIRQs. Since VIRQs do not test HCOUNTER at all, it needs a
lock to prevent IRQs from firing repeatedly on the same scanline.
With HIRQs, it's an exact comparator, so since HIRQPOS == 232*4, and
HCOUNTER == 882, the IRQ should fire at V=7, not V=8. This is fixed, so
Mystic Quest Legend (E) now works with both FAVOR_ methods.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 06, 2006 6:35 pm Post subject: |
|
And here's info on Robocop <> R-Type III:
Robocop:
Code: |
* IRQ @ < 31, 22> : 10 < 31, 0>
00964b jml $80964f [$80964f] A:0000 X:0004 Y:fffe S:01f9 D:0000 DB:80 nvmxdIzC V: 31 H: 82
80964f phd A:0000 X:0004 Y:fffe S:01f9 D:0000 DB:80 nvmxdIzC V: 31 H: 114
809650 pea $0000 [$800000] A:0000 X:0004 Y:fffe S:01f7 D:0000 DB:80 nvmxdIzC V: 31 H: 142
809653 pld A:0000 X:0004 Y:fffe S:01f5 D:0000 DB:80 nvmxdIzC V: 31 H: 176
809654 phb A:0000 X:0004 Y:fffe S:01f7 D:0000 DB:80 nvmxdIZC V: 31 H: 210
809655 phk A:0000 X:0004 Y:fffe S:01f6 D:0000 DB:80 nvmxdIZC V: 31 H: 230
809656 plb A:0000 X:0004 Y:fffe S:01f5 D:0000 DB:80 nvmxdIZC V: 31 H: 250
809657 rep #$30 A:0000 X:0004 Y:fffe S:01f6 D:0000 DB:80 NvmxdIzC V: 31 H: 276
809659 pha A:0000 X:0004 Y:fffe S:01f6 D:0000 DB:80 NvmxdIzC V: 31 H: 294
80965a phx A:0000 X:0004 Y:fffe S:01f4 D:0000 DB:80 NvmxdIzC V: 31 H: 322
80965b phy A:0000 X:0004 Y:fffe S:01f2 D:0000 DB:80 NvmxdIzC V: 31 H: 350
80965c lda $4210 [$804210] A:0000 X:0004 Y:fffe S:01f0 D:0000 DB:80 NvmxdIzC V: 31 H: 378
80965f bpl $9664 [$809664] A:c141 X:0004 Y:fffe S:01f0 D:0000 DB:80 NvmxdIzC V: 31 H: 408
809661 jmp ($00e4) [$8000e4] A:c141 X:0004 Y:fffe S:01f0 D:0000 DB:80 NvmxdIzC V: 31 H: 420
809681 sep #$30 A:c141 X:0004 Y:fffe S:01f0 D:0000 DB:80 NvmxdIzC V: 31 H: 454
809683 lda #$20 A:c141 X:0004 Y:00fe S:01f0 D:0000 DB:80 NvMXdIzC V: 31 H: 472
809685 sta $4209 [$804209] A:c120 X:0004 Y:00fe S:01f0 D:0000 DB:80 nvMXdIzC V: 31 H: 484
809688 lda $022f [$80022f] A:c120 X:0004 Y:00fe S:01f0 D:0000 DB:80 nvMXdIzC V: 31 H: 508
80968b and #$fb A:c115 X:0004 Y:00fe S:01f0 D:0000 DB:80 nvMXdIzC V: 31 H: 574
80968d ldx $18a1 [$8018a1] A:c111 X:0004 Y:00fe S:01f0 D:0000 DB:80 nvMXdIzC V: 31 H: 586
809690 ldy $18a2 [$8018a2] A:c111 X:0000 Y:00fe S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 612
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 638
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 662
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 680
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 704
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 722
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 746
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 764
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 788
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 806
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 830
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 848
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 872
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 890
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 914
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 932
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 956
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 974
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H: 998
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H:1016
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H:1040
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H:1058
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H:1082
809693 bit $4212 [$804212] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nvMXdIZC V: 31 H:1100
809696 bvc $9693 [$809693] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1124
809698 sta $212c [$80212c] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1136
80969b stx $2111 [$802111] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1160
80969e sty $2111 [$802111] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1184
8096a1 lda $18a3 [$8018a3] A:c111 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1208
8096a4 sta $2112 [$802112] A:c18f X:0000 Y:0000 S:01f0 D:0000 DB:80 NVMXdIzC V: 31 H:1234
8096a7 lda $18a4 [$8018a4] A:c18f X:0000 Y:0000 S:01f0 D:0000 DB:80 NVMXdIzC V: 31 H:1258
8096aa sta $2112 [$802112] A:c100 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1284
8096ad rep #$30 A:c100 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVMXdIZC V: 31 H:1308
8096af lda #$96b5 A:c100 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIZC V: 31 H:1326
8096b2 jmp $9748 [$809748] A:96b5 X:0000 Y:0000 S:01f0 D:0000 DB:80 NVmxdIzC V: 31 H:1344
809748 sta $e4 [$0000e4] A:96b5 X:0000 Y:0000 S:01f0 D:0000 DB:80 NVmxdIzC V: 31 H:1362
80974a lda #$0081 A:96b5 X:0000 Y:0000 S:01f0 D:0000 DB:80 NVmxdIzC V: 32 H: 26
80974d sta $4200 [$804200] A:0081 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIzC V: 32 H: 44
809750 lda #$00a1 A:0081 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIzC V: 32 H: 74
809753 sta $4200 [$804200] A:00a1 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIzC V: 32 H: 92
809756 bra $9769 [$809769] A:00a1 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIzC V: 32 H: 122
809769 ply A:00a1 X:0000 Y:0000 S:01f0 D:0000 DB:80 nVmxdIzC V: 32 H: 140
80976a plx A:00a1 X:0000 Y:fffe S:01f2 D:0000 DB:80 NVmxdIzC V: 32 H: 174
80976b pla A:00a1 X:0004 Y:fffe S:01f4 D:0000 DB:80 nVmxdIzC V: 32 H: 208
80976c plb A:0000 X:0004 Y:fffe S:01f6 D:0000 DB:80 nVmxdIZC V: 32 H: 242
80976d pld A:0000 X:0004 Y:fffe S:01f7 D:0000 DB:80 NVmxdIzC V: 32 H: 268
80976e rti A:0000 X:0004 Y:fffe S:01f9 D:0000 DB:80 nVmxdIZC V: 32 H: 302
* IRQ @ < 32, 352> : 10 < 32, 0>
00964b jml $80964f [$80964f] A:0000 X:0004 Y:fffe S:01f9 D:0000 DB:80 nvmxdIzC V: 32 H: 412 |
Robocop expects that writing $4200.d5,4 = #$00, $4200.d5,4= #$20 with
IRQ flag set and when VCOUNTER==VIRQPOS, that upon clearing the I flag
(with rti in this case), that an IRQ will immediately fire.
R-Type III expects the exact opposite.
Code: |
* IRQ @ < 6, 40> : 10 < 6, 0>
00ff2b php A:0700 X:b46d Y:1d0c S:1fe8 D:0000 DB:82 nvmxdIZc V: 6 H: 100
00ff2c rep #$30 A:0700 X:b46d Y:1d0c S:1fe7 D:0000 DB:82 nvmxdIZc V: 6 H: 122
00ff2e pha A:0700 X:b46d Y:1d0c S:1fe7 D:0000 DB:82 nvmxdIZc V: 6 H: 144
00ff2f phb A:0700 X:b46d Y:1d0c S:1fe5 D:0000 DB:82 nvmxdIZc V: 6 H: 174
00ff30 phd A:0700 X:b46d Y:1d0c S:1fe4 D:0000 DB:82 nvmxdIZc V: 6 H: 196
00ff31 phx A:0700 X:b46d Y:1d0c S:1fe2 D:0000 DB:82 nvmxdIZc V: 6 H: 226
00ff32 phy A:0700 X:b46d Y:1d0c S:1fe0 D:0000 DB:82 nvmxdIZc V: 6 H: 256
00ff33 jml $81ee14 [$81ee14] A:0700 X:b46d Y:1d0c S:1fde D:0000 DB:82 nvmxdIZc V: 6 H: 286
81ee14 sep #$30 A:0700 X:b46d Y:1d0c S:1fde D:0000 DB:82 nvmxdIZc V: 6 H: 318
81ee16 phk A:0700 X:006d Y:000c S:1fde D:0000 DB:82 nvMXdIZc V: 6 H: 336
81ee17 plb A:0700 X:006d Y:000c S:1fdd D:0000 DB:82 nvMXdIZc V: 6 H: 356
81ee18 lda $0206 [$810206] A:0700 X:006d Y:000c S:1fde D:0000 DB:81 NvMXdIzc V: 6 H: 382
81ee1b pha A:0701 X:006d Y:000c S:1fde D:0000 DB:81 nvMXdIzc V: 6 H: 408
81ee1c lda #$01 A:0701 X:006d Y:000c S:1fdd D:0000 DB:81 nvMXdIzc V: 6 H: 428
81ee1e sta $0206 [$810206] A:0701 X:006d Y:000c S:1fdd D:0000 DB:81 nvMXdIzc V: 6 H: 440
81ee21 sta $00420d [$00420d] A:0701 X:006d Y:000c S:1fdd D:0000 DB:81 nvMXdIzc V: 6 H: 466
81ee25 ldx #$00 A:0701 X:006d Y:000c S:1fdd D:0000 DB:81 nvMXdIzc V: 6 H: 496
81ee27 lda $4211 [$814211] A:0701 X:0000 Y:000c S:1fdd D:0000 DB:81 nvMXdIZc V: 6 H: 508
81ee2a jsr ($0212,x) [$810212] A:07c2 X:0000 Y:000c S:1fdd D:0000 DB:81 NvMXdIzc V: 6 H: 572
81ee40 stz $0800 [$810800] A:07c2 X:0000 Y:000c S:1fdb D:0000 DB:81 NvMXdIzc V: 6 H: 628
81ee43 lda $0000 [$810000] A:07c2 X:0000 Y:000c S:1fdb D:0000 DB:81 NvMXdIzc V: 6 H: 654
81ee46 sta $2100 [$812100] A:070f X:0000 Y:000c S:1fdb D:0000 DB:81 nvMXdIzc V: 6 H: 680
81ee49 lda $001a [$81001a] A:070f X:0000 Y:000c S:1fdb D:0000 DB:81 nvMXdIzc V: 6 H: 704
81ee4c sta $4200 [$814200] A:07a1 X:0000 Y:000c S:1fdb D:0000 DB:81 NvMXdIzc V: 6 H: 730
81ee4f rep #$20 A:07a1 X:0000 Y:000c S:1fdb D:0000 DB:81 NvMXdIzc V: 6 H: 754
81ee51 lda $0214 [$810214] A:07a1 X:0000 Y:000c S:1fdb D:0000 DB:81 NvmXdIzc V: 6 H: 772
81ee54 sta $0212 [$810212] A:ee6e X:0000 Y:000c S:1fdb D:0000 DB:81 NvmXdIzc V: 6 H: 806
81ee57 lda $0218 [$810218] A:ee6e X:0000 Y:000c S:1fdb D:0000 DB:81 NvmXdIzc V: 6 H: 840
81ee5a sta $4209 [$814209] A:00cf X:0000 Y:000c S:1fdb D:0000 DB:81 nvmXdIzc V: 6 H: 874
81ee5d rep #$30 A:00cf X:0000 Y:000c S:1fdb D:0000 DB:81 nvmXdIzc V: 6 H: 904
81ee5f ldy #$0012 A:00cf X:0000 Y:000c S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H: 922
81ee62 lda ($00,s),y [$812c90] A:00cf X:0000 Y:0012 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H: 940
81ee64 dey A:2c2c X:0000 Y:0012 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H: 992
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0011 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1004
81ee62 lda ($00,s),y [$812c8f] A:2c2c X:0000 Y:0011 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1022
81ee64 dey A:2c2c X:0000 Y:0011 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1074
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0010 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1086
81ee62 lda ($00,s),y [$812c8e] A:2c2c X:0000 Y:0010 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1104
81ee64 dey A:2c2c X:0000 Y:0010 S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1156
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000f S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1168
81ee62 lda ($00,s),y [$812c8d] A:2c2c X:0000 Y:000f S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1186
81ee64 dey A:2c2c X:0000 Y:000f S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1238
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000e S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1250
81ee62 lda ($00,s),y [$812c8c] A:2c2c X:0000 Y:000e S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1268
81ee64 dey A:2c2c X:0000 Y:000e S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1320
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000d S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1332
81ee62 lda ($00,s),y [$812c8b] A:2c2c X:0000 Y:000d S:1fdb D:0000 DB:81 nvmxdIzc V: 6 H:1350
81ee64 dey A:2c2c X:0000 Y:000d S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 38
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000c S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 50
81ee62 lda ($00,s),y [$812c8a] A:2c2c X:0000 Y:000c S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 68
81ee64 dey A:2c2c X:0000 Y:000c S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 120
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000b S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 132
81ee62 lda ($00,s),y [$812c89] A:2c2c X:0000 Y:000b S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 150
81ee64 dey A:2c2c X:0000 Y:000b S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 202
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:000a S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 214
81ee62 lda ($00,s),y [$812c88] A:2c2c X:0000 Y:000a S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 232
81ee64 dey A:2c2c X:0000 Y:000a S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 284
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0009 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 296
81ee62 lda ($00,s),y [$812c87] A:2c2c X:0000 Y:0009 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 314
81ee64 dey A:2c2c X:0000 Y:0009 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 366
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0008 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 378
81ee62 lda ($00,s),y [$812c86] A:2c2c X:0000 Y:0008 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 396
81ee64 dey A:2c2c X:0000 Y:0008 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 448
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0007 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 460
81ee62 lda ($00,s),y [$812c85] A:2c2c X:0000 Y:0007 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 478
81ee64 dey A:2c2c X:0000 Y:0007 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 570
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0006 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 582
81ee62 lda ($00,s),y [$812c84] A:2c2c X:0000 Y:0006 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 600
81ee64 dey A:2c2c X:0000 Y:0006 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 652
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0005 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 664
81ee62 lda ($00,s),y [$812c83] A:2c2c X:0000 Y:0005 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 682
81ee64 dey A:2c2c X:0000 Y:0005 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 734
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0004 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 746
81ee62 lda ($00,s),y [$812c82] A:2c2c X:0000 Y:0004 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 764
81ee64 dey A:2c2c X:0000 Y:0004 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 816
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0003 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 828
81ee62 lda ($00,s),y [$812c81] A:2c2c X:0000 Y:0003 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 846
81ee64 dey A:2c2c X:0000 Y:0003 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 898
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0002 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 910
81ee62 lda ($00,s),y [$812c80] A:2c2c X:0000 Y:0002 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 928
81ee64 dey A:2c2c X:0000 Y:0002 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 980
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0001 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H: 992
81ee62 lda ($00,s),y [$812c7f] A:2c2c X:0000 Y:0001 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H:1010
81ee64 dey A:2c2c X:0000 Y:0001 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H:1062
81ee65 bne $ee62 [$81ee62] A:2c2c X:0000 Y:0000 S:1fdb D:0000 DB:81 nvmxdIZc V: 7 H:1074
81ee67 lda $0012 [$810012] A:2c2c X:0000 Y:0000 S:1fdb D:0000 DB:81 nvmxdIZc V: 7 H:1086
81ee6a sta $212c [$81212c] A:0010 X:0000 Y:0000 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H:1120
81ee6d rts A:0010 X:0000 Y:0000 S:1fdb D:0000 DB:81 nvmxdIzc V: 7 H:1150
81ee2d sep #$30 A:0010 X:0000 Y:0000 S:1fdd D:0000 DB:81 nvmxdIzc V: 7 H:1190
81ee2f pla A:0010 X:0000 Y:0000 S:1fdd D:0000 DB:81 nvMXdIzc V: 7 H:1208
81ee30 sta $0206 [$810206] A:0001 X:0000 Y:0000 S:1fde D:0000 DB:81 nvMXdIzc V: 7 H:1234
81ee33 sta $00420d [$00420d] A:0001 X:0000 Y:0000 S:1fde D:0000 DB:81 nvMXdIzc V: 7 H:1260
81ee37 rep #$30 A:0001 X:0000 Y:0000 S:1fde D:0000 DB:81 nvMXdIzc V: 7 H:1290
81ee39 ply A:0001 X:0000 Y:0000 S:1fde D:0000 DB:81 nvmxdIzc V: 7 H:1308
81ee3a plx A:0001 X:0000 Y:1d0c S:1fe0 D:0000 DB:81 nvmxdIzc V: 7 H:1342
81ee3b pld A:0001 X:b46d Y:1d0c S:1fe2 D:0000 DB:81 NvmxdIzc V: 8 H: 12
81ee3c plb A:0001 X:b46d Y:1d0c S:1fe4 D:0000 DB:81 nvmxdIZc V: 8 H: 46
81ee3d pla A:0001 X:b46d Y:1d0c S:1fe5 D:0000 DB:82 NvmxdIzc V: 8 H: 72
81ee3e plp A:0700 X:b46d Y:1d0c S:1fe7 D:0000 DB:82 nvmxdIzc V: 8 H: 106
81ee3f rti A:0700 X:b46d Y:1d0c S:1fe8 D:0000 DB:82 nvmxdIZc V: 8 H: 132
* IRQ @ < 8, 182> : 10 <207, 0>
00ff2b php A:0700 X:b46d Y:1d0c S:1fe8 D:0000 DB:82 nvmxdIZc V: 8 H: 242 |
Same exact
behavior, writing #$00,#$20 to $4200.d5,4 during an IRQ where the I
flag is set, and then returning. If an IRQ triggers upon returning,
R-Type III breaks. If an IRQ does not trigger upon returning, Robocop
breaks.
I have no idea what I'm missing.
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Mon Nov 06, 2006 11:32 pm Post subject: |
|
The
only difference that I can see is that Robocop first clears the VIRQ
flag before setting it, while R-Type does not clear it before setting
it. Also in Robocop the IRQ triggers at VCOUNTER(32) == VIRQPOS(32)
while in R-Type the wrong IRQ triggers at VCOUNTER(8) != VIRQPOS(207).
byuu wrote: |
I
hope we don't need sub-sample timing, because there's no way we're
going to be able to reverse engineer that kind of information without
some special testing hardware I don't have access to. Though simply
increasing the clock rate >32khz won't be a problem for me, at least. |
The problem most likely has something to do with the echo_index and
echo_target variables. Setting "status.echo_index = 0;" and
"status.echo_target = status.echo_size;" after writes to the EDL and/or
ESA registers should be enough to fix Koushien 2, although it might not
be hardware accurate.
Quote: |
Does anomie's S-DSP core always run BRR indefinitely? I haven't noticed any issues in Clay Fighter 1 or 2 yet. |
Yes it does. If you disable it, the intro song in CF1 will break and
the game will freeze after a while. In CF2 the game will freeze before
reaching the first menu.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 06, 2006 11:43 pm Post subject: |
|
DMV27 wrote: |
The
only difference that I can see is that Robocop first clears the VIRQ
flag before setting it, while R-Type does not clear it before setting
it. |
Nothing happens when you write #$00 to VIRQ. The VIRQ will have already
triggered so lock will be on. It's the #$20 write that's re-enabling
it. R-Type III also changes $4209 (VTIME) to something other than what
VCOUNTER is currently set to, I think that's somehow unlocking IRQ.
Almost as if the IRQ poistion always has to be tested, and the I flag
is just delaying the trigger point of a positive test, or as if the
$4209 write is clearing the "pending IRQ" flag. Not sure which is
happening right now. The former is unrealistic and complex, the latter
breaks demo_nmi.smc test 2 (I'd need to be at home to look at the
documented source for it). I also noticed that Robocop is not reading
$4211, which supposedly causes repeated IRQs to fire. Maybe that has
something to do with it? Sigh...
DMV27 wrote: |
The
problem most likely has something to do with the echo_index and
echo_target variables. Setting "status.echo_index = 0;" and
"status.echo_target = status.echo_size;" after writes to the EDL and/or
ESA registers should be enough to fix Koushien 2, although it might not
be hardware accurate. |
Hmm. I'll have to research this and come up with tests to run on the
SNES, then. Thanks for the info at any rate, it gives me a good
starting point for trying to figure out what's going on.
DMV27 wrote: |
Yes
it does. If you disable it, the intro song in CF1 will break and the
game will freeze after a while. In CF2 the game will freeze before
reaching the first menu. |
Ah, thank you. Good news :)
I spoke with TRAC about the S-DSP stuff, I don't think he's going to be
able to assist unfortunately. Though we were heavily discussing the
idea of a subsample-based S-DSP core running at 1.024mhz (well, both
the S-SMP and S-DSP running at 2.048mhz, interleaving bus accesses to
APURAM, but effectively executing at 1.024mhz each). That's going to
be... very very difficult to try and emulate, to say the least. Not to
mention the $00f0 TEST register S-SMP clock speed setting throwing
things off even more. But that, a clock accurate S-PPU, and fixes to
S-CPU and we should be about as accurate as we can possibly get with
emulation. Look forward to this in about 12 years from now :P
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 07, 2006 6:40 am Post subject: |
|
tetsuo55 wrote: |
I'm
glad the testrun is finished, now that all games have been tested we
have the final buglist. with this information in hand all there is left
to do is figure out those IRQ's do PAL timing/irq tests and hope blargg
soon creates the PAL filter (because then i can retire my snes) |
I hear ya, buddy. You at least got the Japanese design, though. Mine is
a yellow, gray, purple, boxy piece of dog crap.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 07, 2006 8:55 am Post subject: |
|
Ok,
Sufami Turbo is finished. Now I just need to add back in cheat/patch
loading, and that should do for src/cart modifications for a while.
Maybe I'll add split ROM support while I'm at it just for fun.
There's now some
safety code regarding ST loading, but it's not all there. Specifically,
if a file fails to load, then you won't get any errors, the game will
just not work, obviously. I now protect against loading oversized ROMs
and SRAM files.
The database now lists each Sufami
Turbo cart only once, and the cart loading code handles matching up two
ROMs from the database. It is also now possible to play ST games with
invalid checksums, so eg translations/hacks of these games should now
be possible, however unlikely.
FF:MQ (E) is fixed now too, so we're back to FAVOR_ACCURACY in WIP builds again.
A little more src/cart polishing and I'm going to start documenting all
that's known about IRQs, and try and figure out how they work once and
for all (hahah, yeah right -- I give it 2-3 weeks after fixing it again
before more problems are found). |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Tue Nov 07, 2006 6:41 pm Post subject: |
|
Hmmm...
There must be another game that relies on the same IRQ behavior as
Robocop that can help shed light on this. Robocop was fixed in a WIP
without you realizing it was even glitched, so there must be another
game that prompted the initial fix. |
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Fri Nov 10, 2006 11:44 am Post subject: |
|
Is the crackling sound in RPM Racing a known bug? It works fine on my real pal snes. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 10, 2006 3:39 pm Post subject: |
|
PiCiJi wrote: |
Is the crackling sound in RPM Racing a known bug? It works fine on my real pal snes. |
No, your computer speed is a known bug. I do not interpolate samples
when emulation runs too slowly, hence crackling.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Nov 10, 2006 9:20 pm Post subject: |
|
Gaussian interpolation?  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 10, 2006 10:04 pm Post subject: |
|
You
all should have the fpscounter on so that you can see when a game dips
you below 60. Some games use rarely used effects and it'll expose your
cpu power if you're on the fringe. You can always use frameskip on
these games, or, as byuu implies, upgrade your comp.
I wonder why nintendo even allowed stuff like interlace or psuedo hi-res at all. They both seem fairly pointless. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Nov 10, 2006 10:23 pm Post subject: |
|
FitzRoy wrote: |
I wonder why nintendo even allowed stuff like interlace or psuedo hi-res at all. They both seem fairly pointless. |
Consider the user base.
_________________
FF4 research never ends for me.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Fri Nov 10, 2006 10:49 pm Post subject: |
|
I get 60 fps with RPM Racing but the sound crackles. Other games work fine. Maybe its related to my onboard sound? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 10, 2006 11:14 pm Post subject: |
|
I
wouldn't know. It doesn't happen for any of us, and none of us have
your hardware. Sorry, I know of no way to simplify my sound code any
more than it already is. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 10, 2006 11:29 pm Post subject: |
|
PiCiJi wrote: |
I get 60 fps with RPM Racing but the sound crackles. Other games work fine. Maybe its related to my onboard sound? |
The (J) version smartly removed interlace and pseudo-hi-res. Try that.
I have to warn you, though. It doesn't make the game any less torturous
to play.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 11, 2006 9:24 am Post subject: |
|
Happens
just the same on the real system. Were you comparing different outputs?
You're probably not going to be able to hear the crackling on muddy ass
tv speakers. |
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Sat Nov 11, 2006 9:38 am Post subject: |
|
byuu wrote: |
I
wouldn't know. It doesn't happen for any of us, and none of us have
your hardware. Sorry, I know of no way to simplify my sound code any
more than it already is. |
By the way, I have a weird problem with sound. Somtimes when I start
bsnes, load rom and switch to fullscreen, sound becomes choppy. Either
right after switching to fullscreen, or after several seconds.
Sometimes this does not happen. Currently I set high priority to bsnes
process before loading rom and switching to fullscreen and it helps.
But even in this case in some rare cases sound becomes choppy after
going to fullscreen.
I can only guess it somehow related to sound buffering, either internal
or directsound. Extending buffer size should solve this problem
completely.
edit:
I have Athlon 64 3000+ / GeForce 6600GT PCI-E / 1GB RAM / SB Live! with kX driver / XP SP2.
Emu runs at 60 FPS flawlessly all the time.
|
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Sat Nov 11, 2006 11:01 am Post subject: |
|
Quote: |
You're probably not going to be able to hear the crackling on muddy ass tv speakers |
yeah you are right, I have used my headphone on the TV and could hear the crackling. So the crackling is normal.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Nov 13, 2006 1:47 am Post subject: |
|
Ipher wrote: |
ALL: Seta 11 support. Thanks anonymous donor and Jonas Quinn. [Nach] |
While it's fresh... does this have any implications for bsnes? I can't
remember what you said before about SETA chips...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 13, 2006 5:26 am Post subject: |
|
Not
really. The code would have to be ported to pure c++, and encapsulated
into a class before I could use it. Only one game even uses this chip
anyway. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Nov 13, 2006 5:56 am Post subject: |
|
Same
with DSP3 and 4 then... Pretty sad that we can't find anyone to do this
for you in two years. It's probably the one thing that doesn't need
your oversight, and it would be a great contribution. Too bad I can't
fucking do it  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 13, 2006 7:16 am Post subject: |
|
It
really isn't anyone else's responsibility to do it for me, I was very
lucky to receive the libraries from Andreas Naive for S-DD1 and DSP-1,
and the code porting help from Nach for the Cx4. But on the other hand,
since I've no interest in adding these chips myself, it probably won't
get done, or at least not until virtually nothing else is left to do.
In other news, I've completely rewritten NMI and IRQ handling. It
passes all of my tests, and all of the tricky games I know of.
Including both R-Type III and Robocop at the same time.
Funny, too. I rewrote the IRQ code in less than two hours, and with a
really high fever (I'll be fine). Rather strange the way I tend to
excel mentally when I have a fever. So anyway, please don't freak out
and add 40 new games to the buglist for me in the morning. The code
will no doubt have some issues here and there, given the complete
rewrite of arguably the most important aspect of SNES emulation, but
the code is so much simplier now, that I think future fixes will be a
lot easier.
The new code is of course not perfect yet, still need to test a lot of edge cases first.
And of course, this one took another major speed hit. I'm sure you're
all used to that by now, though. It's right about at the speed of
v0.018 official again.
To save you some time, the flickering is still there with SoM. I think
it's related to DMA<>IRQ conflict timing that I recently
modified. I'll look into it later. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Nov 13, 2006 7:35 am Post subject: |
|
Is
it not true that the simpler your C++ "reference" code is, the easier
it would be for someone to come along later and write an optimized
version of it, in either a high- or low-level language?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Mon Nov 13, 2006 11:20 pm Post subject: |
|
Jipcy wrote: |
Is
it not true that the simpler your C++ "reference" code is, the easier
it would be for someone to come along later and write an optimized
version of it, in either a high- or low-level language? |
If by simpler you mean "readable", well, sort off.
Extensive use of c++ features (mostly template metaprogramming) would
make a nightmare to port to other languages, though. I don't know if
much of these features would be of use in a hardware emulator.
_________________
_-|-_
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 13, 2006 11:41 pm Post subject: |
|
MisterJones wrote: |
Extensive use of c++ features (mostly template metaprogramming) would
make a nightmare to port to other languages, though. I don't know if
much of these features would be of use in a hardware emulator. |
A lot of that stuff isn't that hard to port. The hardest part to port
is STL. Templates can be replaced with macros 98% of the time.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 13, 2006 11:56 pm Post subject: |
|
I hope that the code will be clean enough to be used as a reference for improving / writing other emulators.
As far as the use of templates and c++-only features, I don't have any
intentions of opening up my license to allow derivative works
("forks"), so that really isn't much of a concern anyway. I really only
make light use of templates. It's mostly when you start getting down
into the library code (the code below the SNES emulation core code,
like the vector and string classes) that you start running into
template code. Even that isn't anything too complex to port.
And templates really are the smallest problem of all. As explained a
few dozen times so far, the use of cooperative multithreading makes
bsnes about as portable as ZSNES is now. A huge tradeoff, but accuracy
came before portability in my book, when 98% of my audience was using
x86/amd64 Windows/Linux anyway. Funny that I'm so stubborn about
assembly code going in there, given that.
So no one's noticing any new problems with the complete NMI/IRQ rewrite, then? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 14, 2006 1:16 am Post subject: |
|
Everything works on my watchlist except Secret of Mana.
Watchlist
---------
Bugs Bunny in Rabbit Rampage
Energy Breaker
F-1 Grand Prix
Jumbo no Ozaki Hole in One
Secret of Mana
Sink or Swim
World Class Rugby
Zan III - Spirits
IRQ Watchlist
-------------
Battle Blaze
Chou Aniki - Bakuretsu Rantou Hen
Might Morphin Power Rangers - The Fighting Edition
R-Type III - The Third Lightning
Robocop Versus The Terminator
Street Racer
Wild Guns
Last edited by FitzRoy on Wed Nov 15, 2006 3:00 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 14, 2006 4:59 pm Post subject: |
|
Thanks
for testing. I'm honestly quite surprised at how much simpler IRQs
turned out to be. I'll try optimizing the speed a little now then,
since there are no known bugs involving IRQs at this time.
Also, note to self: sync S-SMP<>S-CPU upon writes to S-SMP $00f1.
Fixes Super Bomberman 4 (for the fifth time). |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Nov 14, 2006 5:10 pm Post subject: |
|
gonna test a few more annoying games tonigh on the latest wip
just have to find something to put the latest wip on....
(still no internet at home) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 15, 2006 10:02 am Post subject: |
|
I
"fixed" Secret of Mana's map. HDMA bus synchronization was interfering
with DMA. So I disabled it for HDMA alone and went with the averaging
approach again until I have time to fix it (DMA still uses bus
synchronization). Since it was technically broken before, this is
"technically" more hardware accurate, but it's somewhat cheating. But
hey, since the old method was broken anyway causing missed HDMA
transfers, this is definitely an improvement. This also fixed a very
minor one frame flicker that was still occurring in Street Racer, both
games appears totally stable with mode7 rotozooming now.
Now that CPU IRQ hell appears over (at least for now ...), I should be
able to focus on HDMA bus sync here soon enough anyway.
Also finally added that $00f1 SMP<>CPU sync to my main branch, so Super Bomberman 4 (J) is working again. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Nov 15, 2006 5:18 pm Post subject: |
|
Alrighty then!!!
only 2 more non sPPU related bugs left.
As you stated before, you cannot solve these with your current paradyme
so i suggest you indeed move on to perfecting the hdma and dma
could you tell us what you still need to do with the core? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Nov 15, 2006 11:08 pm Post subject: |
|
Any word or ideas on this raster UI? I'm very interested in the idea.
byuu wrote: |
I
would basically design it to run at any resolution and be totally
themeable. The only thing I see as very impractical would be using
256x224 mode. |
How about make the minimum resolution 512x448, and get that much more
resolution for your UI? Hi-res games need that minimum resolution
anyway, right?
For people that *must* run it at less than 512x448, bsnes could accept command-line arguments or something.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Nov 15, 2006 11:27 pm Post subject: |
|
make it a config file option to go lower in res.
_________________
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: Fri Nov 17, 2006 4:49 am Post subject: |
|
It's been a while since I've been around, but good job on all the improvements byuu.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 17, 2006 9:09 pm Post subject: |
|
Neat,
so apparently people have already successfully booted PPC Linux on the
PS3. Given bsnes gets >60fps on a 2ghz G5, a dual-core 3.2ghz should
have no problems. Just need to get libco ported, and it should be a
viable emulator. Only competition would be SNES9x, as it's the only
other emulator not dependent on Win32 and/or x86. Speed obviously no
longer matters on a console since as long as you get 60fps (and can do
fastforward), you're good. And since SNES9x' X-Windows user interface
is supposedly not very good, I see potential here to get a little more
name recognition, and perhaps attract a little help in getting more
special chips and stuff supported :)
Now then, who wants to donate a PS3 so I can get started on this? :)
[or more realistically, is anyone with knowledge on how to compile
applications and a PS3 willing to throw a PPC Linux on it and try
compiling and profiling bsnes? And most importantly, snap some
screenshots?] |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 17, 2006 10:23 pm Post subject: |
|
I
was just thinking about this same thing the other day. I've been
keeping up with the latest PS3 announcements and was surprised to see
how easy it was to disassemble the PS3 compared to the 360. Even the HD
can be replaced with a custom one, and combined with the ability to run
linux, I have no doubt that we're going to see a lot of emulator ports
for this puppy in the years to come. There's a lot of buzz around the
PS3, and it's a big opportunity for bsnes if it can be the first SNES
emu ported.
My first curiosity, though, is if one core on the cell is enough to run at 60fps. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 17, 2006 10:46 pm Post subject: |
|
It
should be, yes. It's an IBM PPC, and the 2ghz G5 was enough to get
60-80fps on Mac OS X. Now, of course, ghz don't mean everything, it's
possible that the 3.2ghz Cell is slower than the 2ghz G5 ... but at the
very least, the Cell is a dual core processor so bsnes will have an
entire core to itself. I would be willing to increase the flexibility
of the FAVOR_SPEED build to guarantee >60fps on a PS3 if people
would be willing to use it there. The recognition would go a long
way to garnering programming help from other people, but if SNES9x gets
ported quickly (and it probably already has been), I doubt anyone would
bother. I'm going to have to focus on a really spiffy and complete GUI
interface for my Linux port, and quickly.
The good news is, as a console, it doesn't matter how much CPU usage an
emulator takes. It's a console. You're running a game on it, and you
have two cores anyway. Anyone with a PS3 will get the same framerate,
so the speed is no longer an issue, so long as you get full speed. I
could even release binary packages that are profile optimized like the
Windows releases.
It's also possible to run ZSNES and co on the PPC anyway, by use of an
emulator, but even ZSNES will likely have problems keeping a steady
60fps inside an x86 emulator on the PS3. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 19, 2006 3:57 am Post subject: |
|
Too
bad I'm not getting one for like a year, or I'd test stuff out for you.
Also, too many old games sitting on my shelf that I haven't played...
shadow of the colossus, eternal darkness... and this new dat site that
I've yet to launch is sucking up all of my time now that I'm done with
initial testing.
Make no mistake, though, I'm
still a whore for accuracy. After hdma bus sync, I'd like to see you
take a shot at those last two fixable bugs since getting new info on
them. Because if those get wiped, it would mean something fairly
remarkable. And I wouldn't be shy to say it in your next release notes
that get posted on news sites. Something along the lines of "All 3000
non-special chip games have been tested and only 3 known bugs remain,
all of which are dependent on a dot-based renderer." |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Nov 20, 2006 2:14 pm Post subject: |
|
Although
it could be my mind playing tricks on me, i have the feeling that the
audio sounds different in the latest wip, also Toy story seems to be
less buggy, but still has problems, it just seems to recover quicker
now...
Did you change anything to the sound? or is this being caused by the new IRQ behaviour.
The new sound sounds a lot better!
The game i noticed it the most on is may all time favorite "zombies ate
my neighbours" i know every song and sound effect by heart, en they
sound very different between the last wip i tried, 12 i think and the
new wip 18 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Nov 20, 2006 8:49 pm Post subject: |
|
I
don't notice a difference in any of the games you mentioned. In fact, I
don't think anything has changed with regards to sound quality since
.016... unless you count EWJ2, which was from the pal clock being too
slow. |
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Mon Nov 20, 2006 9:10 pm Post subject: |
|
tetsuo55 wrote: |
The
game i noticed it the most on is may all time favorite "zombies ate my
neighbours" i know every song and sound effect by heart, en they sound
very different between the last wip i tried, 12 i think and the new wip
18 |
I'm sorry, do I have a chance to get these wip builds?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 21, 2006 1:34 am Post subject: |
|
The
bsnes WIP builds are not public like zsnes. I think byuu has indicated
that .019 will be released sometime around January if things go well. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Nov 21, 2006 9:48 am Post subject: |
|
okay
i recorded the audio for 0.17 and 0.18wip18 and then compared them with
the EAC compare tool, and it flagged all the sections i thought sounded
different as different!
I also tested 0.18 and it was 99% the same as 0.18wip18
the change in audio code must have happened somewhere between 0.17 and 0.18
I didnt notice it before because i had a crappy soundcard , got an X-Fi now... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 21, 2006 10:13 am Post subject: |
|
Hmm...
could have something to do with the change from 32000hz to 32040hz. I
couldn't perceive any difference. Maybe I just don't know what to look
for. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Nov 21, 2006 10:30 am Post subject: |
|
that has to be it!
That would greatly alter the wav output
the new frequency does make a huge difference with a very good
soundcard and speakers, but is hardly noticeable on my onboard sound.
When testing a month ago i mentioned some sound differences in some
games i tested, they now sound on my pc like they do on the tv!
But that still doesnt explain why toy story is less bugy.. that must come from the irq changes |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 22, 2006 12:55 am Post subject: |
|
Glad
to see the change to 32040hz helped. It's only the internal
CPU<>SMP timing that was affected by the change, the actual
output is still forced to 32000hz (basically, emulation runs ~1/8th of
1% too slow), as the resampling penalties would be very rough with
maximum frequencies on sound cards being typically 48khz to 96khz.
Some people disagree with me in changing the S-SMP clock rate to match
observed rates of real hardware (in fact I was rather adamant against
it for a long time myself), but it is known that the stock speeds break
real games released for the system (eg EWJ2 (E)). At this point in
time, I think I'd rather try and emulate the actual SNES box myself,
than to emulate the specification sheets that don't reflect reality. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Nov 22, 2006 6:53 am Post subject: |
|
Might have a bug to report, but I'm not sure...
It has to do with one of the Test Cartridge roms. It's known as "SNES
Aging Test Program" in NSRT. Runs okay in zsnes, but won't run in any
bsnes version. The other two dumped test carts run okay, and supposedly
this rom is a verified dump.
EDIT:
Okay, something that might be useful: the rom runs at 60fps in zsnes
and works on my ntsc snes, but Overload insists that it is a PAL cart
despite being (J) internally.
Overload wrote: |
Hydr0x sent me a photo of the cart, it is definately PAL. |
Lastly, the "SNSP" on the title screen seems to confirm this because SNSP-001A is the UK SNES model number. Weird.
Anyway, going on vacation now. Happy Thanksgivings.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 27, 2006 5:55 pm Post subject: |
|
Hmm,
still working on the GUI wrapper for Win32<>GTK+. I doubt anyone
will add any other toolkits in the future, but this at least makes it a
possibility.
One thing I'm doing is specifically
designing the new UI wrapper to be as minimalist as possible. That
means giving up a lot of tricks that I know are possible in most GUI
toolkits such as windows inside of windows (see the current bsnes
configuration screen for an example).
Something that most definitely will not be possible is the highly
customized debugger memory editor in current bsnes Windows builds,
however a less intuitive and speedy interface can be designed that
works on Linux as well.
So then, should I just
keep the current Windows port and all of its platform-specific code, or
should I redesign the GUI to be more generic to support both Windows
and Linux? This would entail having separate windows for all of the
various configuration panels, for one. Not necessarily a big deal, I
think. It'd save time and allow the Windows and Linux ports to remain
mostly synchronous, but obviously won't look as good as custom tailored
solutions on each individual platform.
The biggest problem I foresee is that I have no idea how to switch to
fullscreen mode with GTK+ (I doubt it's even possible), so I've no idea
how that's going to work if I decide to use this new library for the
main Windows port as well.
So far, I just have the window creation working on Windows, and window
creation + menus on the Linux port. The code is easy, but highly
monotonous to write, hence why it's taking so long. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Nov 27, 2006 6:25 pm Post subject: |
|
byuu wrote: |
Hmm,
still working on the GUI wrapper for Win32<>GTK+. I doubt anyone
will add any other toolkits in the future, but this at least makes it a
possibility.
One thing I'm doing is
specifically designing the new UI wrapper to be as minimalist as
possible. That means giving up a lot of tricks that I know are possible
in most GUI toolkits such as windows inside of windows (see the current
bsnes configuration screen for an example).
Something that most definitely will not be possible is the highly
customized debugger memory editor in current bsnes Windows builds,
however a less intuitive and speedy interface can be designed that
works on Linux as well.
So then, should I
just keep the current Windows port and all of its platform-specific
code, or should I redesign the GUI to be more generic to support both
Windows and Linux? This would entail having separate windows for all of
the various configuration panels, for one. Not necessarily a big deal,
I think. It'd save time and allow the Windows and Linux ports to remain
mostly synchronous, but obviously won't look as good as custom tailored
solutions on each individual platform.
The biggest problem I foresee is that I have no idea how to switch to
fullscreen mode with GTK+ (I doubt it's even possible), so I've no idea
how that's going to work if I decide to use this new library for the
main Windows port as well.
So far, I just have the window creation working on Windows, and window
creation + menus on the Linux port. The code is easy, but highly
monotonous to write, hence why it's taking so long. |
Any chances that you might implement a way to start emulation fullscreen?
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Nov 27, 2006 6:45 pm Post subject: |
|
So did you scrap the idea of a raster-based GUI? Or is this in addition to that?
byuu wrote: |
So
then, should I just keep the current Windows port and all of its
platform-specific code, or should I redesign the GUI to be more generic
to support both Windows and Linux? |
I personally hate using GTK applications on Windows. However, I hate
them less if the GTK libraries are statically linked to the program,
instead of "shared" or whatever (I hope what I've said makes sense; my
knowledge of this stuff comes from using various X-Chat builds, Gaim,
and GIMP on Windows). So, ideally, I'd prefer to use a native Win32
interface, or a raster-based GUI. But if you go with more generic GUI
code, and use GTK on Windows, please statically link the GTK libraries.
Altogether, though, I'm for anything that makes the code simpler / more portable / easier for you.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Nov 27, 2006 7:56 pm Post subject: |
|
Jipcy wrote: |
I
personally hate using GTK applications on Windows. However, I hate them
less if the GTK libraries are statically linked to the program, instead
of "shared" or whatever. |
How does that affect the program?
_________________
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: Mon Nov 27, 2006 8:46 pm Post subject: |
|
creaothceann wrote: |
How does that affect the program? |
From what I know of GTK programs and using them on Windows, this is how it works:
You can install "system-wide" GTK libraries. Any program that has
shared or dynamically linked GTK libraries will use the system-wide
libraries. Any program that uses statically linked libraries has the
libraries compiled right into the program, or something.
The difference being that any change to the system-wide GTK libraries
affect all programs using them. With statically linked GTK, the program
only uses the libraries that are built into the program. So changes to
the shared libraries don't affect it.
The problem with shared libraries is evident when using Gaim. Before
the release of Gaim 2.0.0beta4, it required an old version of GTK,
v2.6. Some info here.
This old version could sometimes affect newer versions of GIMP. Also,
I've sometimes installed a new version of X-Chat or GAIM, and the new
GTK libraries sometimes affect the other program. The point is that
some programs might expect a certain version of GTK, while others
expect a different version. It just seems that sharing GTK libraries
among different programs on Windows is a bad idea. There's just too
many compatibility problems, etc.
This is just all from my experiences.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 27, 2006 9:50 pm Post subject: |
|
Quote: |
Any chances that you might implement a way to start emulation fullscreen? |
Probably not. Without a menu, it would only annoy most people unaware
of how to switch to windowed mode. The really ignorant would possibly
not be able to exit fullscreen mode, despite there being at least six
key combinations to get you out of fullscreen mode (esc, f11, windows
key, alt+tab, ctrl+alt+delete, ctrl+lshift+esc, etc).
Quote: |
I personally hate using GTK applications on Windows. |
As do I, which is why I'm writing a cross-platform user interface
library, rather than simply using GTK+ because it's portable. GTK+
looks great on Linux. It's fast, has a nice selection of themes that
are easy to select from the OS control panel (in my case, XFCE theme
applet), and works good. It also looks like all of my other apps. On
Windows, it's clear the port was half assed. GTK+ apps stick out like a
sore thumb as most apps use the Win32 API and are consistent whereas
GTK+ look and sometimes act completely different, they have redraw
issues, flicker issues, etc etc.
Hence, on Windows bsnes will use the Win32 API. On Linux, it will use
GTK+. On Mac, you can use Richard Bannister's port which I assume uses
Aqua. The only thing is, in order to support multiple APIs, I'm forced
to implement the library to use only the lowest common denominator of
functionality (basically, I can only do things that can be done on all
of the platforms, so I can't tweak each platform to look just perfect
anymore, and I'll lose a little of the refinement features in the GUI
such as the memory editor keyboard hook).
Note: you can technically build the Windows port to use GTK+ with the library, but ... why?
The raster GUI? Eh, I'd like to work on it, but it's a huge undertaking
to make it anywhere near half decent. This seems like it'd be a lot
faster, and it'd be a lot smoother for most. As a plus, it should give
a nice GUI for PS3 bsnes using GTK+.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Nov 27, 2006 10:31 pm Post subject: |
|
byuu wrote: |
The
raster GUI? Eh, I'd like to work on it, but it's a huge undertaking to
make it anywhere near half decent. This seems like it'd be a lot
faster, and it'd be a lot smoother for most. As a plus, it should give
a nice GUI for PS3 bsnes using GTK+. |
Fair enough. I'm more than happy to use a standard Win32 GUI.
Just out of curiosity, what's your "plan" for version 1.0 of bsnes? It
seems that you are versioning your emulator with sub-1.0 numbers
because you consider it a beta of some sort, or not ready for general
use.
Perhaps you're planning 100% base SNES accuracy for 1.0?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 27, 2006 10:38 pm Post subject: |
|
v1.0
would assume total completion and perfection of the emulator. Since
that will never happen, I'm not ever planning a v1.0. I might make the
final version 1.0 just for the hell of it, but most likely not.
The version numbers are just exact numbers of official full releases.
Only the first two versions were a little sketchy since I was releasing
most of the WIPs publically back then. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 28, 2006 1:27 am Post subject: |
|
Raster GUIs have maintenance and space issues galore. I think gtk for linux is fine.
Hopefully, the Windows config scheme doesn't suffer too much from linux support. It's awfully nice at the moment. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Nov 28, 2006 12:35 pm Post subject: |
|
Jipcy wrote: |
You
can install "system-wide" GTK libraries. Any program that has shared or
dynamically linked GTK libraries will use the system-wide libraries.
Any program that uses statically linked libraries has the libraries
compiled right into the program, or something.
[...]
It just seems that sharing GTK libraries among different programs on
Windows is a bad idea. There's just too many compatibility problems,
etc. |
Mmh. They should've secured all shared files (& other resources) with version numbers...
...but whatever.
/offtopic
_________________
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: Fri Dec 01, 2006 1:27 am Post subject: |
|
Tetsuo,
can you do me a favor and test George Foreman's KO Boxing (E) on your
PAL unit? I want to know if the sound stutters like that for real. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 01, 2006 8:39 am Post subject: |
|
Will do! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Dec 05, 2006 5:30 am Post subject: |
|
OT:
Haze on the recent CPS2 CHD 4GB each (for now that is)
http://shortlink.co.uk/h7s (mameworld board)
Quote: |
Quote: |
> A four giga chd for every games!!!, that's shit. |
10 years ago people considered 700mb too big and 'shit' so they ripped
all their console CD games to ISO+MP3.
10 years later we're stuck with ISO+MP3 for many many games and it's
pretty much impossible to find the games you want in good condition to
make perfect lossless rips.
|
We're fortunate to have bsnes and two other accurate Snes emus (and
maybe in the future Zsnes will figure in that list)
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Dec 05, 2006 8:10 am Post subject: |
|
actually,
unless someone starts dumping the rom chips with an ic reader and maps
the pcd layaout of each game cart there is a similar loss of data.
snes games are basically the same as the cps2 board but without the protection that needs a 4 gig CHD
a lot of the memory mappers used in snes emus are a pretty accurate guesses |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Dec 05, 2006 8:22 am Post subject: |
|
tetsuo55 wrote: |
actually,
unless someone starts dumping the rom chips with an ic reader and maps
the pcd layaout of each game cart there is a similar loss of data.
snes games are basically the same as the cps2 board but without the protection that needs a 4 gig CHD
a lot of the memory mappers used in snes emus are a pretty accurate guesses |
ah, I admit I wasn't aware of this. I was mentionning this more in
reference to documenting the Snes hardware, before there's no more
functionning Snes units. Didn't know it also extended to the game dumps
themselves (which make better sense for the analogy actually)
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Dec 05, 2006 10:31 am Post subject: |
|
FitzRoy wrote: |
Tetsuo,
can you do me a favor and test George Foreman's KO Boxing (E) on your
PAL unit? I want to know if the sound stutters like that for real. |
There is almost no difference in sound
it doesnt stutter for me on my system nor in bsnes wip18
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Dec 05, 2006 9:17 pm Post subject: |
|
Thank you, but it does stutter in bsnes. I'm referring to the
"Forema- Foreman for Real." and other sound effects that do it which
sounds really wrong. And it doesn't do it in the (U) version. Could be
that the developers thought it made a neat "echo" effect, but I thought
it might be a bug instead. The ref's voice gets completely jacked by it. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Dec 07, 2006 7:54 am Post subject: |
|
this game doesnt stutter on bsnes nor my real snes.
maybe your using a different version? or i tested the wrong game
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: 1.SMC
Name: FOREMAN'S KO BOXING Company: Acclaim
Header: Exists (type?) Bank: LoROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 8 Mb
Country: Euro/Asia/Oceania Video: PAL
ROM Speed: 200ns (SlowROM) Revision: 1.0
Checksum: Good 0xF3E9 CRC32: 09FE6EC1
MD5: B3DF09E19706763E5EAD764D384C891F
--------------------------Database--------------------------
Name: George Foreman's KO Boxing
Country: Europe Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Sports Genre 2: Boxing |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Dec 07, 2006 8:01 am Post subject: |
|
Gah,
my fault. I told you to check "George Foreman's KO Boxing (E)" but the
game in question is actually "Foreman for Real (E)". No wonder we're
confused.  |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Dec 07, 2006 9:44 am Post subject: |
|
lol okay ill test the other game 
Edit:
I got some interesting results here, all version of the game have the
"echo" on pal hardware U/E/J, but the ntsc version hang on a "this pack
si not for pal " screen.
So it looks like Bsnes is emulating corretly.
Byuu, i assume Bsnes automatically choses either pal or ntsc mode when
loading a cartidge, is it possible to force Bsnes to work as either pal
or ntsc, this way we sould get to see the "not ment for your region
screen" |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 07, 2006 2:47 pm Post subject: |
|
It's
not possible at present. I didn't see a need to add support for that,
as we've now officially tested every last commercial SNES game we have
dumped and the header+region detection is 100% accurate.
I guess I could add an option to choose the region, but it seems more
like feature bloat. You could change the region in the ROM header file
and achieve the same result, btw. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 08, 2006 6:52 am Post subject: |
|
okay sounds fair enough
changing a pal game to ntsc or vice versa, can i use the fix for
pal/ntsc option in snestool 1.2 for that or do i need to change it in a
different way? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Dec 16, 2006 1:15 pm Post subject: |
|
Does Bsnes support multiple roms in 1 zip?
like the pal, us and jap version of a game in 1 zip |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Dec 16, 2006 6:55 pm Post subject: |
|
There's one byte in the ROM header to set NTSC/PAL. 0x00, 0x01 and I think 0x13 (whatever Korea is) are NTSC. The rest are PAL.
I don't support multiple ROMs in one ZIP yet. I might
add that functionality when I design my own little mini container for
multiple files, but I don't know how zlib or libjma work, so I won't be
able to add the support there anyway. There's no advantage of this with
any of the containers supported in bsnes, as none offer solid state
archiving anyway (I believe JMA does, but I don't believe the version
of the library I am using does. And even if mine does, it can't be used
now anyway since I don't support multiple ROMs in one archive).
A small update, libui is ~90% complete for GTK+, and ~60% complete for
Win32. Windows users really aren't going to like the less stellar UI,
but Linux users should be very happy with it.
By the way, I'm looking for a way to display UTF-8 text inside Win32
native and common controls, is that possible? GTK+ supports it out of
the box, and I want to use that for internationalization. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Sun Dec 17, 2006 1:14 am Post subject: |
|
byuu wrote: |
By
the way, I'm looking for a way to display UTF-8 text inside Win32
native and common controls, is that possible? GTK+ supports it out of
the box, and I want to use that for internationalization. |
Sorry, you'll have to translate to UTF-16 for Windows. Your options include:
- Use
MultiByteToWideChar with CP_UTF8. This requires at least Windows 98 or
NT 4, and it may require the codepage to be installed.
- Translate
to UTF-16 yourself, or use GTK. Just as long as it handles surrogates
the same as Windows, unless you don't expect to use >FFFFh stuff.
Then, on Windows 9x, you still need to translate back to ANSI, so
that's a trip back through WideCharToMultiByte with CP_ACP.
Things also get a bit complicated if you want to support both NT and
9x, since a few of the Common Controls have separate window messages
for ANSI and Unicode.
Microsoft has released a library to simplify Unicode support under
legacy systems, but it pretty much wraps everything, so it's kind of
big.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 17, 2006 2:03 am Post subject: |
|
Quote: |
Sorry, you'll have to translate to UTF-16 for Windows |
Easy enough, I can make that transparent.
I'm willing to drop support for Win9x if it means being able to display
apps in any language, regardless of locale setting.
Not sure how I want to do the language stuff just yet. Probably just a
UTF-8 text document with a list of "File"="Fairu", etc lines.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sun Dec 17, 2006 4:22 am Post subject: |
|
byuu wrote: |
Quote: |
Sorry, you'll have to translate to UTF-16 for Windows |
Easy enough, I can make that transparent.
I'm willing to drop support for Win9x if it means being able to display
apps in any language, regardless of locale setting.
Not sure how I want to do the language stuff just yet. Probably just a
UTF-8 text document with a list of "File"="Fairu", etc lines.
|
you'd need flow control for dialogs too.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
Firon Trooper
Joined: 05 May 2006
Posts: 367
|
Posted: Sun Dec 17, 2006 7:33 am Post subject: |
|
9x needs to die already, along with support for it. |
|
Que saskatchewanite
Joined: 26 Apr 2006
Posts: 317
|
Posted: Sun Dec 17, 2006 8:11 am Post subject: |
|
Firon wrote: |
9x needs to die already, along with support for it. |
Didn't microsoft stop supporting it already as well?
_________________
everything i say is a lie
the above line is true
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Dec 17, 2006 8:17 am Post subject: |
|
Que wrote: |
Firon wrote: |
9x needs to die already, along with support for it. |
Didn't microsoft stop supporting it already as well?
|
Yes.
Though, but killing DOS will make me cry... or not.
If you can't help it, go kill the support. It is still a viable
platform for some. (I still should get around to testing BSNES under
98SE.)
_________________
FF4 research never ends for me.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Dec 19, 2006 4:47 pm Post subject: |
|
FitzRoy could you test "Star Ocean (J) [T+Eng1.0_DeJap].smc" on your NTSC hardware
The problem we are looking for is corruption on the title screen and slow displaying of items from itemboxes.
I can confirm that the unpatched version runs fine in bsnes, no slowdowns or corruptions |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Dec 19, 2006 6:28 pm Post subject: |
|
byuu wrote: |
There's one byte in the ROM header to set NTSC/PAL. 0x00, 0x01 and I think 0x13 (whatever Korea is) are NTSC. The rest are PAL.
|
2-12 are PAL, the rest are NTSC.
byuu wrote: |
I believe JMA does, but I don't believe the version of the library I am using does. |
You believe wrong.
_________________
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: Tue Dec 19, 2006 10:18 pm Post subject: |
|
tetsuo55 wrote: |
FitzRoy could you test "Star Ocean (J) [T+Eng1.0_DeJap].smc" on your NTSC hardware
The problem we are looking for is corruption on the title screen and slow displaying of items from itemboxes.
I can confirm that the unpatched version runs fine in bsnes, no slowdowns or corruptions |
I'll try but I don't think it's going to work since Star Ocean uses a special chip (SDD-1).
Could be that zsnes is allowing the patchers to do something that they
weren't supposed to be doing. Someone who knows what they're talking
about is going to have to look into it.
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Tue Dec 19, 2006 11:32 pm Post subject: |
|
tetsuo55 wrote: |
FitzRoy could you test "Star Ocean (J) [T+Eng1.0_DeJap].smc" on your NTSC hardware
The problem we are looking for is corruption on the title screen and slow displaying of items from itemboxes.
I can confirm that the unpatched version runs fine in bsnes, no slowdowns or corruptions |
NTSC Hardware? As in on a copier? I do know that if you have a GDSF7
with 96Mb+ of RAM, you can run the translated ROM on it (I've tried),
but you have to use a special hack made by Neviksti.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Dec 20, 2006 5:06 am Post subject: |
|
As
expected, it didn't work on my flash cart because the game requires a
special chip. And the Neviksti version won't work on what I have
because 96M is too big for my 64M flash cart. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 20, 2006 5:44 am Post subject: |
|
I replied to the DeJap Star Ocean issue on the pSX emulator forum page, where said discussion started.
I suppose I might as well start documenting "flaws" like this and
Gideon Zhi's older Y's 4 translation patch. This isn't the first board
where I've seen people suggesting this was a problem with bsnes.
Quote: |
You believe wrong. |
Hence why I said believe, because I knew no matter how I answered, you'd post that I was incorrect.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Dec 20, 2006 8:18 am Post subject: |
|
Yeah i should dig up the bugs that arnt emu bugs that i listed when testing the games, FitzRoy did you make such a list?
Too bad the rom is so big, as some special chip/hardware games do work
partially on bsnes eventhough the chip is not emulated
byuu im sorry the wip got posted there, i was asleep when that happend or i would have removed the link instantly, |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Dec 20, 2006 8:46 am Post subject: |
|
Bugs That are NOT emulation Bugs
Special Chip/Hardware Games
BS Test Results
BS Nichibutsu 4 Player Mahjong 1 (J).smc > seems to work fine, but there is no audio.
BS Nichibutsu 4 Player Mahjong 2 (J).smc > seems to work fine, but there is no audio.
BS Nichibutsu Mahjong (J).smc > seems to work fine, but one of the titlescreens fonts is messed up.
BS Same Game Koma Data (J).smc > black screen
BS Satella Walker 2 - Sate Bou wo Sukuidasu! (J).smc > black screen
BS Sousa Sentai Wappers 1 (J).smc > fonts messed up
BS Sousa Sentai Wappers 2 (J).smc > fonts messed up
BS Sousa Sentai Wappers Soushuu Hen (J).smc > fonts messed up
BS Special Tee Shot (J).smc > 2 words overlap in the level select
screen, apart from that the game works fine and is a lot of fun too!
(midget golf with a blob)
BS Spriggan Powered (J).smc > game seems to be working perfectly, but i cannot get passed the japanese dialogue.
BS St.Giga 10 Gatsu Gou (J).smc > fonts messed up
BS Super Mahjong Taikai (J).smc > koei logo and game logo messed up,
i cannot get passed the japanese name/password part so i didnt see
ingame
BS Super Mario Collection 3 (J).smc > i can only change the button layout, but i cannot get ingame.
BS Super Mario USA 1 (J).smc > Game works perfectly but there is no
music, and it seems like mario characters are talking to you in
japanese, but their voice is not heard.
BS Super Mario USA 2 (J).smc > Game works perfectly but there is no
music, and it seems like mario characters are talking to you in
japanese, but their voice is not heard.
BS Super Mario USA 3 (J).smc > Game works perfectly but there is no
music, and it seems like mario characters are talking to you in
japanese, but their voice is not heard.
BS Super Ninja-kun (J).smc > might be missing some soundFX, but seems 100% working
BS Super Tsume Shougi 1000 (J).smc > game works, but audio might not be 100%
BS Sutte Hakkun 2 6-3 (J) [!].smc > looks good, but i cannot get passed the japanese menu to get ingame.
BS Sutte Hakkun 2 10-8 (J).smc > looks good, but i cannot get passed the japanese menu to get ingame.
BS Sutte Hakkun 98 Winter Event Version (J).smc > looks good, but i
cannot get passed the japanese menu to get ingame.
BS Sutte Hakkun (J).smc > looks good, but i cannot get passed the japanese menu to get ingame.
SuperFX
Vortex (E/J/U) [!].smc > black screen
DSP 4
Planet's Champ TG3000, The (J).smc > Black Screen
To p Gear 3000 (E) [!].smc > black screen
To p Gear 3000 (U) [!].smc > black screen
SA-1
Taikyoku Igo - Idaten (J).smc > black screen
Takemiya Masaki Kudan no Igo Taishou (J).smc > black screen
SPC7110
Tengai Makyou Zero - Shounen Jump no Shou (J) [!].smc > black screeb
Tengai Makyou Zero (J) [!].smc > black screen
Bugs in games and not in emulation
Yuujin - Janjuu Gakuen 2 (J).smc > Sometimes the Characters will
disappear or flash heavily, happens on hardware in the same places.
Thunderbirds - Kokusai Kyuujotai Juudou Seyo! (J).smc > smoke effect
as 1 launches looks wrong, looks the same on hardware.
Tiny Toon Adventures - Wild & Wacky Sports (E) (V1.1) [!].smc +U/J
> feet missing 1 pixel line on character select screen, looks the
same on hardware.
Top Gear 2 U/E/J > A black line appears in the bridge on level 1,
happens on hardware too, but in a different part of the bridge and for
a shorter time.(needs sPPU)
Toy Story (U) [!].smc +U/E > Sometimes a buzzing is heard on loading
screens, unable to test in hardware as none of the releases will run on
my copier.
Aqutallion (J).smc > no visable battle damage, same on hardware.
Sim City > Scrolling causes a 1 tile wrap around to happen on the
direction your scrolling in., not visable on TV's only on plasma/lcd.
this is the list so far, i seem to have forgotten to test about 10 games on hardware. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Dec 20, 2006 9:33 am Post subject: |
|
byuu wrote: |
Quote: |
You believe wrong. |
Hence why I said believe, because I knew no matter how I answered, you'd post that I was incorrect.
|
If you would've posted correctly, I would not have told you that you were incorrect.
I don't know why you think I crippled the JMA decompression lib I've been passing out every where.
Especially a quick glance in jma.h and you notice:
_________________
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: Wed Dec 20, 2006 9:55 am Post subject: |
|
I
didn't bother keeping documentation on real glitches because I know the
list would just be too damn long. After seeing what was real and what
was truly a bug, I can safely say that
a. no graphical anomaly occuring only in the "overscan area" is a real bug.
b. no flickering sprite with line caching disabled is a real bug
This accounts for just about every "common" game glitch I've seen. Real
bugs will usually consist of something distractingly noticeable within
the first five minutes of gameplay: corrupt gfx, wrong colors, missing
effects, scrambled bg layers, unresponsive controls, and freezing.
There are very likely other games affected by the random Koushien hang,
which is why it's somewhat important that it gets fixed eventually for
reasons other than obsessive accuracy. We're lucky to have found one
example because it's apparently a fairly obscure bug. But one known
game is all you need for collateral damage (and who knows, maybe Toy
Story and Koushien are related).
Also, unsupported hardware is already documented, just not on a
game-by-game basis. I think that byuu's readme is sufficiently
inclusive for users, although I would be interested in having a text
file with a complete list of unsupported games followed by their
hardware (in alphabetical order and this format).
Star Fox (U) *SFX
Super Mario World 2 - Yoshi's Island (E) *SA1
Super Mario World 2 - Yoshi's Island (U) *SA1
etc...
Oh, and pSX emulator forum drama?
Summary for the lazy: KingHanco posts WIP link, young spriggans bash
bsnes for its speed, byuu comes in and chastises KingHanco, then
tommy-guns everyone (not really). |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 20, 2006 6:56 pm Post subject: |
|
I guess I can change my unsupported games list to be completely alphabetical, then.
No real drama at pSX forums. I'll just change where I stick WIP builds
in the future. I intentionally left the link as something fairly easy
to guess before. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Dec 20, 2006 7:50 pm Post subject: |
|
byuu isnt the latest link password protected??? |
|
Firon Trooper
Joined: 05 May 2006
Posts: 367
|
Posted: Wed Dec 20, 2006 9:20 pm Post subject: |
|
FitzRoy wrote: |
Super Mario World 2 - Yoshi's Island (E) *SA1
Super Mario World 2 - Yoshi's Island (U) *SA1
etc...
|
That's a SuperFX2 game.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Dec 20, 2006 10:21 pm Post subject: |
|
Yep. Tried to remember for the example and failed. All the more reason for a list! |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Dec 21, 2006 12:35 pm Post subject: |
|
I made a list with all the info i could find on games with special chips inside them, im currently building the add-on list.
(EDIT: Super Scope info added)
I could not find all the games as roms, i believe some might be misnamed.
Games that i could not find where marked as (!NOT FOUND!)
Games that where never released are marked as (Unreleased BETA)
The rest is standard naming fair, all names are from the latest Goodsnes.
You can copy and paste the following lists in Excel, and then edit them
and them resort them, you can even add everything to 1 list and sort it
alphabetically, i decided to simply list everything so everyone can use
it in whatever way they like it.
For Bsnes documentation its probably best to combine all the lists
remove the fully working games from it, then resort alphabetically.
,
Code: |
4x4 Racer (Unreleased BETA? or dev name for Dirt Trax FX?) SuperFX2
Ace no Nerae! (J) DSP2
Ballz 3D (J/U) DSP
Comanche (Unreleased BETA) SuperFX2
Dirt Racer (E) SuperFX2
Dirt Trax FX (E/U) SuperFX2
Doom (E/J/U) SuperFX2
Dragonball Z Hyper Dimension (F/J) SA 1
Dungeon Master (E/J/U) DSP
Exhaust Heat (E/J) DSP2
Exhaust Heat II - F-1 Driver no Kiseki (J) DSP
F1 ROC II - Race of Champions (U) DSP
F1 ROC Race of Champions (U) DSP2
FX Fighter (Unreleased BETA) SuperFX2
Hoshi no Kirby 3 (J) SA 1
Hoshi no Kirby Super Deluxe (J) SA 1
Jikkyou Oshaberi Parodius (J) SA 1
Kirby Super star (U) SA 1
Kirby's Dream Land 3 (U) SA 1
Kirby's Fun Pak (E) SA 1
Masoukichin : Lord of Elemental (!NOT FOUND!) SA 1
Mega Man X2 (E/U) C4
Mega Man X3 (E/U) C4
Parodius 3 (!NOT FOUND!) SA 1
PilotWings (E/J/U) DSP
Planet's Champ TG3000, The (J) DSP2
Power Slide (Unreleased BETA) SuperFX2
Rockman X2 (J) C4
Rockman X3 (J) C4
Soukou Kihei Votoms - The Battling Road (J) DSP
Star Fox (J/U) SuperFX
Star Fox 2 (BETA) SuperFX2
Star Fox Super Weekend Competition (U) SuperFX
StarWing (E) SuperFX
StarWing Offizieller Wettbewerb (G) SuperFX
StarWing Super Weekend Competition (E) SuperFX
Street Fighter Alpha 2 (E/U) SuperFX2
Street Fighter Zero 2 (J) SuperFX2
Stunt Race FX (E/U) SuperFX
Super Air Diver (!NOT FOUND!) DSP
Super Mario - Yoshi Island (J) SuperFX2
Super Mario Kart (E/J/U) DSP
Super Mario RPG - Legend of the Seven Stars (U) SA 1
Super Mario RPG (J) SA 1
Super Mario World 2 - Yoshi's Island (E) SuperFX2
To p Gear 3000 (E/U) DSP2
Transformers (Unreleased BETA) SuperFX2
Vortex (E/J/U) SuperFX
Wild Trax (J) SuperFX
Winter Gold (E) SuperFX2
|
All Super Scope games show the menu, but a lot of them cannot go ingame.
Code: |
Battle Clash (E/U) Super Scope Game Unplayable without Super Scope
Bazooka Blitzkrieg (U) Super Scope Game Unplayable without Super Scope
Destructive (J) Super Scope Game Unplayable without Super Scope
Hunt for Red October, The (E/J/U) (it is used for bonus games) Super
Scope Game Bonus games don't show up without Super Scope
Lamborghini - American Challenge (E/J/U) (it accesses a different game
mode from the normal one) Super Scope Game Special mode Doesn't work
without Super Scope
Metal Combat: Falcon's Revenge (E/U) Super Scope Game Unplayable without Super Scope
Operation Thunderbolt (U) Super Scope Game Game is playable with controlpad
Space Bazooka (J) Super Scope Game Unplayable without Super Scope
Super Scope 6 (!NOT FOUND!) Super Scope Game Unplayable without Super Scope
T2: The Arcade Game (E/J/U) Super Scope Game Game is playable with controlpad
Tin Star (U) Super Scope Game Game is playable with controlpad
X-Zone (E/U) Super Scope Game Unplayable without Super Scope
Yoshi no Road Hunting (J) Super Scope Game Unplayable without Super Scope
Yoshi's Safari (E/U) Super Scope Game Unplayable without Super Scope
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Dec 22, 2006 1:05 am Post subject: |
|
I
made a complete NSRT scan and searched for each chip to make this list.
Should be accurate, but no unreleased games are included. Watch out for
the board filter on Top Gear you know what, though (never mind, someone
fixed it).
Quote: |
Special Chips
-------------
C4 (Supported)
DSP-1 (Supported)
DSP-2 (Supported)
DSP-3
DSP-4
DSP Seta
OBC1 (Supported)
S-DD1 (Supported)
S-RTC (Supported)
SA-1
SPC7110
Super FX
Super FX2
Special Chip Games
------------------
3 Jigen Kakutou Ballz (J) *DSP-1
Ace wo Nerae! (J) *DSP-1
Asahi Shinbun Rensai - Katou Hifumi Kudan Shougi - Shingiryuu (J) *SA-1
Ballz 3D (U) *DSP-1
Battle Racers (J) *DSP-1
Bike Daisuki! Hashiriya Damashii - Rider's Spirits (J) *DSP-1
Daikaijuu Monogatari II (J) *S-RTC
Daisenryaku Expert WWII - War in Europe (J) *SA-1
Derby Jockey 2 (J) *SA-1
Dirt Racer (E) *Super FX
Dirt Trax FX (E/U) *Super FX
Doom (E/J/U) *Super FX2
Dragonball Z - Hyper Dimension (F/J) *SA-1
Drift King Shutokou Battle '94 - Tsuchiya Keiichi & Bandou Masaaki (J) *DSP-1
Drift King Shutokou Battle 2 - Tsuchiya Keiichi & Bandou Masaaki (J) *DSP-1
Dungeon Master (E/J/U) *DSP-2
Exhaust Heat II - F1 Driver heno Kiseki (J) *DSP Seta
F1 Race of Champions II (U) *DSP Seta
Final Stretch (J) *DSP-1
Habu Meijin no Omoshiro Shougi (J) *SA-1
Hanguk Pro Yagu (K) *DSP-1
Harukanaru Augusta 3 - Masters New (J) *SA-1
Hayazashi Nidan Morita Shougi (J) *DSP Seta
Hoshi no Kirby - Super Deluxe (J) *SA-1
Hoshi no Kirby 3 (J) *SA-1
Itoi Shigesato no Bass Tsuri No. 1 (J) *SA-1
J.League '96 Dream Stadium (J) *SA-1
Jikkyou Oshaberi Parodius (J) *SA-1
Jumpin' Derby (J) *SA-1
Kakinoki Shougi for Super Famicom (J) *SA-1
Kirby Super Star (U) *SA-1
Kirby's Dream Land 3 (U) *SA-1
Kirby's Fun Pak (E) *SA-1
Lock On (U) *DSP-1
Marvelous - Mouhitotsu no Takarajima (J)
Mega Man X2 (E/U) *C4
Mega Man X3 (E/U) *C4
Metal Combat - Falcon's Revenge (E) *OBC1
Michael Andretti's IndyCar Challenge (J/U) *DSP-1
Mini Yonku Shining Scorpion - Let's & Go!! (J) *SA-1
Momotarou Dentetsu Happy (J) *SPC7110
Pebble Beach no Hatou New - Tournament Edition (J) *SA-1
PGA European Tour (E/U) *SA-1
PGA Tour '96 (E/U) *SA-1
Pilotwings (E/J/U) *DSP-1
Planet's Champ TG3000, The (J) *DSP-4
Power Rangers Zeo - Battle Racers (E/U) *SA-1
Pro Kishi Jinsei Simulation - Shougi no Hanamichi (J) *SA-1
Rin Kaihou Kudan no Igo Taidou (J) *SA-1
Rockman X2 (J) *C4
Rockman X3 (J) *C4
Saikousoku Shikou - Shougi Mahjong (J) *SA-1
SD F-1 Grand Prix (J) *SA-1
SD Gundam G-Next (J) *SA-1
SD Gundam GX (J) *DSP-3
Shin Shougi Club (J) *SA-1
Shougi Saikyou (J) *SA-1
Shougi Saikyou II - Jissen Taikyoku Hen (J) *SA-1
Soukou Kihei Votoms - The Battling Road (J) *DSP-1
Star Fox (J/U) *Super FX
Star Fox - Super Weekend Competition (U) *Super FX
Star Ocean (J) *S-DD1
Starwing (E) *Super FX
Starwing Competition (G) *Super FX
Starwing - Super Weekend Competition (E) *Super FX
Street Fighter Alpha 2 (E/U) *S-DD1
Street Fighter Zero 2 (J) *S-DD1
Stunt Race FX (E/U) *Super FX
Super 3D Baseball (J) *DSP-1
Super Air Diver (E/J) *DSP-1
Super Air Diver 2 (J) *DSP-1
Super Bases Loaded 2 (U) *DSP-1
Super Bomberman - Panic Bomber W (J) *SA-1
Super F1 Circus Gaiden (J) *DSP-1
Super Mario - Yossy Island (J) *Super FX2
Super Mario Kart (E/J/U) *DSP-1
Super Mario RPG (J) *SA-1
Super Mario RPG - Legend of the Seven Stars (U) *SA-1
Super Mario World 2 - Yoshi's Island (E/U) *Super FX2
Super Power League 4 (J) *SPC7110
Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J) *SA-1
Super Shougi 3 - Kitaihei (J) *SA-1
Suzuka 8 Hours (J/U) *DSP-1
Taikyoku Igo - Idaten (J) *SA-1
Takemiya Masaki Kudan no Igo Taishou (J) *SA-1
Tengai Makyou Zero (J) *SPC7110 + RTC
Tengai Makyou Zero - Shounen Jump no Shou (J) *SPC7110 + RTC
Top Gear 3000 (E/U) *DSP-4
Vortex (E/J/U) *Super FX
Wild Trax (J) *Super FX
Winter Gold (E) *Super FX2 |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Dec 22, 2006 3:20 pm Post subject: |
|
For
my custom ROM loader that will scan the directories and give you a list
of available games ... I was thinking there were two ways to identify
available games:
1) By CRC32 This
means that I have to actually read in the entire file, and process the
CRC32 of the file to match it to the database. This will also require
decompression of ZIPs. Scanning will be slow (possibly several minutes
for a complete set), even on the fastest of machines.
2) By filename
Each file would have a special abbreviation, hopefully no more than
eight letters long. The emulator could then just scan the directory and
match via filename. Intentionally lying about the filename would yield
a false positive for a game being present, but I could always verify
upon actually trying to play the game and report a message about the
ROM being invalid. However, scanning a directory should only take a
second or two, even on slow machines. Would be difficult as you'd
probably need a ROM renamer in the first place that would have to scan
by CRC32 anyway.
Which one should I go with? |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Fri Dec 22, 2006 4:44 pm Post subject: |
|
MD5 hash 
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Dec 22, 2006 4:47 pm Post subject: |
|
Always
scanning everything might be overdoing it a bit; you could let the user
create a database of roms on his PC which you'd store in the same
folder as Bsnes; ask for it on the first run, let the user choose to
refresh it at will. By filename seems somewhat restrictive to me, and
would probably lead to a lot of whining from people who don't read the
instructions. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 22, 2006 6:05 pm Post subject: |
|
Yeah take the best scanning method, crc32 or md5 and store in a updateable database |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Fri Dec 22, 2006 6:12 pm Post subject: |
|
Here's a question: do you need to scan the entire ROM to uniquely identify it?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 22, 2006 7:45 pm Post subject: |
|
yeah because the built in crc check roms have only scans the first XX bytes |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Dec 22, 2006 7:57 pm Post subject: |
|
I
could store a database that only matches a small portion of the ROM,
but the bottleneck isn't really scanning the file once it's open. It's
decompressing the file from GZ/ZIP/JMA archives to memory so that I can
then calculate the CRC32.
Plus, it's technically
much easier to get false positives this way. Though of course, CRC32s
can easily be faked to begin with if someone really wanted, but at
least it's a 4,000,000,000 to 1 chance of a false positive without
deliberately forging the sum.
I've never seen an MD5sum algorithm that was short and concise enough
for me to use. If I can get a c/c++ MD5sum routine that is less than
100-200 lines of code, and well written so that I can derive my own
from the code (to avoid any licensing issues), I'd love to use MD5
instead. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Dec 22, 2006 9:20 pm Post subject: |
|
Yeah, I think the mame or Project64 method would be best. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 22, 2006 10:38 pm Post subject: |
|
/me chants: maem mame mame  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Dec 23, 2006 12:12 am Post subject: |
|
This
rom loader thing is an option, right? I want to just do database checks
on a per-load basis and use my own file preferences.
Meh, I suppose I would like it. It would make it easier for newbs, and
I'm guessing it would still allow you to run roms that weren't in the
database, like betas and so forth. Plus, I'm guessing it would
instantly recognize BIOS files so people wouldn't have to move them
around and rename them like in zsnes.
Last edited by FitzRoy on Sat Dec 23, 2006 1:11 am; edited 2 times in total |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Dec 23, 2006 12:29 am Post subject: |
|
byuu wrote: |
I've
never seen an MD5sum algorithm that was short and concise enough for me
to use. If I can get a c/c++ MD5sum routine that is less than 100-200
lines of code, and well written so that I can derive my own from the
code (to avoid any licensing issues), I'd love to use MD5 instead. |
The psuedocode on the Wikipedia page for MD5
is pretty well written, and only 62 lines. Even if it does wind up
being a bit long and messy in C, that's excusable because it's
implementing a messy concept.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Dec 23, 2006 4:44 pm Post subject: |
|
byuu wrote: |
I
could store a database that only matches a small portion of the ROM,
but the bottleneck isn't really scanning the file once it's open. It's
decompressing the file from GZ/ZIP/JMA archives to memory so that I can
then calculate the CRC32.
|
I do not agree with databases with emulators, however if you're looking
for a hash of the files, or a hash of the ROM and you know it's not
headered, not interleaved, don't care about corrupt archives, you could
just read the CRC32 right out of the archive header and not even bother
calculating 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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 25, 2006 9:06 pm Post subject: |
|
Hmm,
so I've brought this up for discussion at least ten times already, but
it's a very serious point. So I'll bring it up again for more input.
As everyone who follows this thread knows, there are three serious bugs
in bsnes, and two line flickering bugs. Three require a cycle-based PPU
renderer, two require S-DSP knowledge and testing equipment that I lack.
Now, I could also work on things that quite literally
no game relies on, like half-calculated math results and such ... and
indeed I intend to eventually, but it won't make any difference in any
games, so releasing new versions with these fixes would have no merit
outside of the five people writing new SNES code nowadays. These issues
require months of time to throw at them, and for zero gain. It would be
better to focus on the visible bugs first, especially considering I
cannot go on forever working on this project.
So
then, that only leaves me with rewriting the S-PPU. I've analyzed my
code again, and I can think of no way to allow both the scanline and
cycle based renderers to coexist as selectable options. The way the
cycle based renderer would have to work would make the scanline one
inoperable, and vice versa.
And the bigger problem being, a cycle-based PPU renderer would be too
slow. If my recent modifications to S-CPU IRQs is any indication, I'm
expecting a loss of 200-500% speed. If we were lucky, only
a high-end Core 2 Duo would be fast enough to run bsnes at fullspeed.
Probably not even then. We would be increasing the workload of what is
already the most CPU intensive part of the emulator from ~225 complex
operations a frame to ~76,500 less complex operations per frame.
Multithreading (to take advantage of multiple cores) won't work at all,
nor will super optimizations over time, and I think we can expect even
less emphasis on raw processing speed as Intel and AMD both move toward
"multiple cores, minimum power consumption" models. A cycle-based
renderer will also completely destroy all benefits of frameskipping.
So my basic problem is: either I settle for a scanline renderer as a
necessary evil, let my work stagnate, and eventually forget all that I
currently know regarding SNES internals long before PCs are fast
enough; or I completely destroy everyone's ability to ever enjoy any
future releases of bsnes because they will, quite simply, be far too
slow to be usable. The idea behind perfect accuracy at any cost is
nice, but I never expected bsnes to take as much CPU power as it
already does. I still like the ideal behind all the accuracy, but I
wanted something usable, too. Asking an end user to at least own a
modern low-end $50 processor wasn't much. Asking them to own a $1,000
C2D Extreme, is. With only one actual game benefitting to a degree
anyone will ever notice, and my ever-fleeting time, I can't see a
strong reason to try and write a cycle-based renderer. And yet, if I
don't, then bsnes really won't get much better in regards to core
accuracy. I can only add frivilous shit like special chips and add-on
peripherals.
I've also been considering stripping away some features from bsnes that
take away from its current accuracy. For example, I'd like to
completely remove frameskipping so I can calculate RTO flags every
frame. Frameskipping would just be stupid if it only offered a ~3%
speedup at a frameskip of 9. Special features are nice, but they only
serve to complicate my code and make it less maintainable. I'm at a
point that I don't expect the underlying architecture to change much,
so I want to start simplifying and streamlining it all to something I
can reasonably call "finished" one day.
So once again, I'd like some opinions. This time, before just saying
"yeah, go with accuracy!", realize what you're saying. It will
very well mean bsnes becoming completely irrelevent as an alternative
to ZSNES and SNES9x for at least the next several years. It could
also potentially mean that bsnes can become near-immortal in the sense
that no future emulator could really do any better, even when the
hardware to run it is finally available and mainstream. It's also very
likely that we'll never convince end users of the advantages of
accuracy, and they'll stick with ZSNES9x forever anyway. Even if their
computers can run bsnes without breaking a sweat, if ZSNES is quite
literally 100x faster, it could be enough for people to avoid using
bsnes anyway (there's also power consumption / battery life, game
consoles, handhelds and cell phones to worry about in the future).
I would essentially be turning bsnes into a reference emulator that
serves only to document hardware, rather than something people can use
and enjoy, and I would for all intents and purposes, be doing it to fix
only one game that's arguably already broken to begin with. |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Mon Dec 25, 2006 9:35 pm Post subject: |
|
Is
there a way to find a happy ground where you still draw per scanline,
but somehow trap an event that would require a cycle based render for
that line?
I guess the difference is detecting a
write to some area at such a time, and then using some sort of
mathematical method to go back and change how that line looked.
What I'm trying to say is, don't perform the intense calculation unless
it needs to happen, because just think of how rare that event is for
all the games.
What I'm saying may help a little with this analogy: Highschool physics
and the toss a ball up in the air problem, and find out what time it
was at such a height or whatever:
They typically give the students the quadratic function right away
describing the path of the ball (plugging in some starting conditions),
without them understanding why. There is the other way using discrete
time slice math, which is very simple summation but you have to start
at time offset 0 and keep looping until you get there. What you keep
doing is shrinking your time slices, making stuff take drastically
longer time.
What I'm getting at, and I haven't studied your code, is that if the
event that requires a dot based renderer happens somewhere within a
critical time period, maybe there is a way to figure out what really
happened previously just by knowing the specific tick at which it
happened, what the data was, and an algorithm that describes it, to be
able to redraw that line differently.
Does this help any? |
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Mon Dec 25, 2006 9:38 pm Post subject: |
|
I'm
trying to be open-minded about both sides of the issue, and I still
think going for accuracy would be the best choice in the long run. I
think in the future it would be regretted if you did otherwise. Plus, I
thought that accuracy and SNES documentation was the original goal of
this project anyway.
We still have the old versions, and the source code. Those can be used if needed. |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Mon Dec 25, 2006 10:00 pm Post subject: |
|
So I take it a cycle based renderer could not be optimized for minimal to zero interaction during scanline rendering?
I'm guessing optimization for rendering whole scanlines, or partial
scanlines when interaction would affect rendering, but since you
mentioned that switching scanline or cycle based renderer would not be
possible at runtime, I guess the two can't be mixed easily.
Plus I guess that scenario could even result in worse slowdown in an
extreme scenario where some cycle timed code is messing with the PPU
constantly, and while I don't expect that to be too common, I suppose a
reference implementation should handle everything consistently rather
than optimizing for "common" cases. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 25, 2006 10:01 pm Post subject: |
|
Quote: |
Is
there a way to find a happy ground where you still draw per scanline,
but somehow trap an event that would require a cycle based render for
that line? |
I'm sure there is. The more speed I squeeze out, the messier the code
gets. And I could very easily design around expecting something to not
be possible, and have it turn out that it is very much possible.
Quick example: I write code that detects something that would change a
scanline halfway through drawing, so that the end, I redraw the
scanline again. Now, what if that change happens twice? I lose the
middle result. It's pure complexity vs speed, and I don't like the idea
of aiming for a compromise.
Either I implement it like real hardware would operate, or I don't
implement it. Not trying to be close-minded about this. ZSNES and
SNES9x took similar approaches with the other portions of emulation
(SNES9x even had code to detect when the CPU was waiting for vblank and
skipped the entire clock ahead to that point), and we all see how
inadequate their opcode-based cores are now. And how many people are
capable of modifying / maintaining either emulators' cores at this
point?
I really want to avoid probability, emulator state rewinding and speed hacks at all costs, and have thus far.
Quote: |
Plus, I thought that accuracy and SNES documentation was the original goal of this project anyway.
We still have the old versions, and the source code. Those can be used if needed. |
And indeed, it was the original goal. And yet now, I have maybe 5,000 -
10,000 people downloading and using each new version of bsnes. Given it
has the highest compatibility among base games of any emulator, it is
useful to a lot of people. So everyone would be happy if bsnes v0.019
was the last release they could ever use? What would the motivation for
following the project be if no one could use it? Who would volunteer to
help? I would not have the time nor energy to backport any new findings
into older versions, as I have no interest in maintaining two forks of
the emulator. This would essentially seal v0.019 as the final version
of bsnes, give or take any new bugs that are discovered, any new
features that are added (special chips, controllers, savestates, etc)
after v0.019.
Quote: |
I'm
guessing optimization for rendering whole scanlines, or partial
scanlines when interaction would affect rendering, but since you
mentioned that switching scanline or cycle based renderer would not be
possible at runtime, I guess the two can't be mixed easily.
Plus I guess that scenario could even result in worse slowdown in an
extreme scenario where some cycle timed code is messing with the PPU
constantly, and while I don't expect that to be too common, I suppose a
reference implementation should handle everything consistently rather
than optimizing for "common" cases. |
Precisely. The most intensive SNES game will bring bsnes to 40% of its'
peak potential speed at present. The difference is almost entirely
related to the scanline renderer (eg Star Ocean will choke bsnes, but
Tetris will not). With a cycle-based PPU, bsnes' slowest speed would be
roughly ~80% its peak performance. Compare that to SNES9x, where I
could easily choke performance to a crawl (~1-2% optimal performance)
with the right combination of trickery (writing to $420d recalculates a
giant lookup table, imagine evil code that toggles that value nonstop
as fast as possible).
I should also add, that simply redrawing part of the scanline when a
mid-scanline write is detected is a very complex thing to do. I would
have to know the entire
state of the S-PPU from a certain point to redraw the screen correctly.
This could essentially get really messy when you think in terms of
"worst case scenarios" that I would undoubtedly have to support. What
if there were 50 modifications to S-PPU during a single scanline?
That's quite the buffer log of events to unwind through to attempt to
redraw the scanline. Also, more complex things could very well come
into play: imagine if the exact details of per-scanline rendering
changes somehow per actual scanline onscreen. Simply having a solid
scanline renderer and a cycle-scanline renderer would no longer be
sufficient. The emulation code would have to become even more complex.
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Mon Dec 25, 2006 10:52 pm Post subject: |
|
I said what I said knowing you're smart enough to come back with what you did, byuu.
Yes, going back and recalculating something has the potential to cause a huge variance in real time performance.
But doing something all the time that always takes an incredible hit on
performance (dot based renderer all the time) for something that a SNES
program just should not be doing anyways. Is that justifiable?
I agree about "What if there were 50 modifications to S-PPU during a
single scanline? That's quite the buffer log of events to unwind
through to attempt to redraw the scanline."
But you know that buffer is not infinite, and at what point do we reach
absurdity about mode changes / data changes that could very well crash
the real state machine in the PPU itself? Maybe there is some cool new
screen mode that can be entered by crashing the PPU? How could an
emulator writer ever know that before the fact?
Is it okay to assume that writing to $420d is a valid thing? It should
be, because maybe there are some fast rom chips and some slower
registers of something else inside a cartridge. Writing outside of
blanking is NEVER valid.
What's more likely? Some code loop runs too long past blanking. Some
new mischevious code does something to determine if it's running on an
emulator. Guess what? Somebody is always going to be able to have their
code determine that it is probably running on an emulator.
I'm not saying you lose, I'm saying you've pretty much won at this
point and maybe need to pass on your knowledge before you completely
burn out. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 25, 2006 11:13 pm Post subject: |
|
Quote: |
But
doing something all the time that always takes an incredible hit on
performance (dot based renderer all the time) for something that a SNES
program just should not be doing anyways. Is that justifiable? |
Again I'm not trying to outright dismiss your idea, and in fact it
really truly is the best long-term solution. The ideal emulator would
do things exactly like this. It's no coincidence all of the bright
minds in the SNES emulation scene keep telling me to do things this
way. However ...
The alternative is writing buggy, hackish code that implements the same
functionality no less than twice to accomodate both the majority of
games as well as special case games. Not a very good thing for the
purposes of clean, self-documenting code :/
I also think that it may
just be above my abilities. I've never written code to handle
prediction and rewinding. I probably could, but it's not a skill I
currently posess.
One reason I wanted a
dot-based renderer was to personally write brand new rastering demos
that blow the socks off of all existing PD ROMs out there, and to show
off what you can do by truly harnessing the full power of the SNES. One
thing I wanted to try (don't know if it's possible, probably not) was a
horizontally split mode7/mode3 screen.
Quote: |
Guess what? Somebody is always going to be able to have their code determine that it is probably running on an emulator. |
Oh, there's no doubt I'll ever be able to reach perfection and beat out
those trying to detect the presence of an emulator. If I were trying to
do that, I'd be going after a different fruit right now to have the
last laugh at d4s :P
Quote: |
maybe need to pass on your knowledge before you completely burn out. |
I really, really do need to start writing documentation. I just have to
... find more time, somehow. Perhaps I should stop posting here so
much, heh.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Dec 25, 2006 11:19 pm Post subject: |
|
byuu wrote: |
Quote: |
maybe need to pass on your knowledge before you completely burn out. |
I really, really do need to start writing documentation. I just have to
... find more time, somehow. Perhaps I should stop posting here so
much, heh.
|
No, that's simply not possible! Posting on the zboard hasn't really slowed people down. I think doc writing is probably the hardest thing... but meh. It will certainly take some time...
_________________
FF4 research never ends for me.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Tue Dec 26, 2006 1:25 am Post subject: |
|
I
have not followed this thread very carefully, but I take it you have
solved Koushien 2 bug. I don't think slowing down the emulator
immensely to only support one game better is worth it. I know this may
be a bad suggestion, but perhaps you can maybe work on SA-1 support as
it seems to have the most games of all the unsupported chips. I know
this would slow down the emulator a lot, but at least the slow down
would be for more than one game. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 26, 2006 1:48 am Post subject: |
|
No.
The two S-DSP issues remain. Koushien 2 randomly freezes, and Toy Story
has some sound repetition errors at various points in the game. I'm
really hoping anomie comes back around, because I haven't a clue what's
causing the problems nor how to fix them. Thanks to DMV27, as best we
know, Koushien 2's problem is due to ESA/EDL writes right around
disabling of the echo buffer. Both issues also affect SNEeSe, so
there's hope TRAC may one day look into the issues as well (but don't
bug him about it, I've already asked politely).
The nice thing about SA-1 support is that even though it probably won't
be playable at fullspeed on anyone's PCs, it will at least not slow
down emulation of non-SA-1 games by much. And no, that doesn't mean I'm
going to start working on it just yet. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Dec 26, 2006 4:52 am Post subject: |
|
I
would much rather prefer the dot-based renderer and any accurate ways
of emulating the system you feel capable of pulling off, even if no
visible end-user benefit is produced. Yes, I understand the implication
that the new renderer would render bsnes unplayable even on a high-end
PC but I think in the long run it's the better solution.
Honestly, for speed and compatibility the current bsnes version is
extremely capable and it's not like anyone's life depended on being
able to run the very last version at 60fps or anything. Not to mention
*Zsnes* is an extremely capable emulator too, overall. And we have
Snes9x...and Trac's emulator and Overload's and the Snes emulation in
MESS is getting better too and...Am I forgetting any major player? Well
you get the idea.
Don't worry, you won't get any "But but..! What happened to the SPEED..!" from this side of the screen. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Dec 26, 2006 7:37 am Post subject: |
|
The
benefits of pixel renderer on a game compatibility level are
practically nil. So if you're going to do it, the other reasons should
be worth it, because two years is a big piece of someone life for
uniracers.
I'm not like Snark. I don't really like
using an arsenal of emulators for each system. It's even more annoying
than plug-ins. So I will continue waiting for special chips and sane
peripherals. That's just my personal preference, though. I'm thankful
for each day that you continue working on the thing. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Dec 26, 2006 11:25 am Post subject: |
|
byuu wrote: |
A cycle-based renderer will also completely destroy all benefits of frameskipping. |
Geez, toss that thing out already if you don't want speedhacks... 
byuu wrote: |
With
only one actual game benefitting to a degree anyone will ever notice,
and my ever-fleeting time, I can't see a strong reason to try and write
a cycle-based renderer. And yet, if I don't, then bsnes really won't
get much better in regards to core accuracy. I can only add frivilous
shit like special chips and add-on peripherals. |
Then don't go for the cycle-based renderer. Document all that has to be
done and how your approach would be, comment the source etc., basically
make it ready for other people to take over. The best thing would be if
the components are separate enough that you can work on adding special
chips while others can implement the new renderer.
xamenus wrote: |
I
still think going for accuracy would be the best choice in the long
run. I think in the future it would be regretted if you did otherwise. |
Seconded. That should be the long-term goal. Special chips might get the attention of potential supporters. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
BRPXQZME Hazed

Joined: 30 May 2006
Posts: 65
Location: Centreville, VA
|
Posted: Tue Dec 26, 2006 11:38 am Post subject: |
|
Writing
code that only works well on computers that only exist in theory never
stopped Bethesda Softworks from making The Elder Scrolls series popular.
Frankly, if this were me I'd find this a tough decision as well, but I
think I'd personally end up sticking to my guns and go for accuracy...
after releasing one last version that works on slower computers.
Moore's Law is still going to be in effect for the rest this decade,
hopefully. Besides, you're doing this as a monument to the SNES, and
taking emulators where they haven't gone before; there's no point in
coming this far only to stop, when you could just take that extra mile
that means that nobody will ever bother to do it better than you did
(The Codex Seraphinianus is probably the perfect example of what I mean
here).
...but if it were me, this project wouldn't have gotten too far in the
first place; or if I did, this is where I'd stop, flip out, run away
and only ever be seen again once, two decades later, gnawing on my
wrist in the middle of the Sonoran desert surrounded by a pack of loyal
coyotes. If that sounds like something you'd do... then by all means,
don't do it.
_________________
Only a couple screws loose. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Dec 26, 2006 1:06 pm Post subject: |
|
BRPXQZME wrote: |
Writing
code that only works well on computers that only exist in theory never
stopped Bethesda Softworks from making The Elder Scrolls series popular.
Frankly, if this were me I'd find this a tough decision as well, but I
think I'd personally end up sticking to my guns and go for accuracy... |
Yes. And most importantly, regardless of what you choose, go for what
YOU want instead of trying to decide according to what you think the
majority of users want (one way or another)...I mean, bsnes is not a
commercial product and there's no "satisfaction guaranteed" or
anything. And if you ever need inspiration about not caring too much
about the end-user: take a look a M.A.M.E
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Dec 26, 2006 3:53 pm Post subject: |
|
byuu wrote: |
Quick
example: I write code that detects something that would change a
scanline halfway through drawing, so that the end, I redraw the
scanline again. Now, what if that change happens twice? I lose the
middle result. It's pure complexity vs speed, and I don't like the idea
of aiming for a compromise. |
No, no. Something pokes at the PPU mid-scanline, so you render the
scanline up to the pixel that corresponds with the current cycle.
There, now you have one partial scanline that corresponds with the PPU
state up until it was prodded. Something prods it again during the same
scanline, so you render more pixels. Up until the end of the scanline,
where changes shouldn't have a visible effect until the next scanline.
Or something like that, I think.
Isn't your PPU already cycle accurate for register accesses? Or does it
also rely on the renderer to keep its state up to date? (Wait, I could
be reading the release version source, but that's probably a bit out of
date now.)
byuu wrote: |
The
most intensive SNES game will bring bsnes to 40% of its' peak potential
speed at present. The difference is almost entirely related to the
scanline renderer (eg Star Ocean will choke bsnes, but Tetris will
not). With a cycle-based PPU, bsnes' slowest speed would be roughly
~80% its peak performance. |
Oops, forgot about that. Darn you, fancy sprite scaling trickery.
byuu wrote: |
Compare
that to SNES9x, where I could easily choke performance to a crawl
(~1-2% optimal performance) with the right combination of trickery
(writing to $420d recalculates a giant lookup table, imagine evil code
that toggles that value nonstop as fast as possible). |
Nefarious!
byuu wrote: |
I
should also add, that simply redrawing part of the scanline when a
mid-scanline write is detected is a very complex thing to do. I would
have to know the entire state
of the S-PPU from a certain point to redraw the screen correctly. This
could essentially get really messy when you think in terms of "worst
case scenarios" that I would undoubtedly have to support. What if there
were 50 modifications to S-PPU during a single scanline? That's quite
the buffer log of events to unwind through to attempt to redraw the
scanline. Also, more complex things could very well come into play:
imagine if the exact details of per-scanline rendering changes somehow
per actual scanline onscreen. Simply having a solid scanline renderer
and a cycle-scanline renderer would no longer be sufficient. The
emulation code would have to become even more complex. |
Sounds like a project of extreme dedication and/or boredom for somebody else, then.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 26, 2006 4:09 pm Post subject: |
|
Quote: |
No,
no. Something pokes at the PPU mid-scanline, so you render the scanline
up to the pixel that corresponds with the current cycle. There, now you
have one partial scanline that corresponds with the PPU state up until
it was prodded. Something prods it again during the same scanline, so
you render more pixels. Up until the end of the scanline, where changes
shouldn't have a visible effect until the next scanline. Or something
like that, I think. |
Oh, ok. Yes, that's what I was planning to try. That's pretty much how
my CPU<>SMP synchronize now. I run one until one tries to access
the other, then run the other until it tries to access the former.
There's a fallback in case synchronization differs by too much, it will
forcefully sync to avoid overflowing the cycle difference counters and
such.
This might have limited success with the S-PPU, but breaking everything
down into individual steps really will hurt performance still. Take for
instance a BG scroll register. Now, instead of preloading and
manipulating it at the start of the scanline, I have to use the
non-local variable that the MMIO register writes the new scroll
location to, in case that value is changed in the middle of the
scanline rendering routine. Only, it's not just the BG scroll register.
But all 64 MMIO registers used by the S-PPU.
I still think that even with this hack, things are going to get really
slow, really quickly. I can only just barely hit 100fps right now with
PGO.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Dec 26, 2006 4:16 pm Post subject: |
|
You probably dont want to hear this but i say take this path...
You could always add bugfixes and new chip support to the current bsnes
if your new code isnt too reliant on the sPPU.
Dont base your decision on coding or not coding the sPPU on Unirally,
the game sucks to much for that, at this point i could go as far to say
either hack it or leave it broken.
My vote is for adding special chips and hardware first... |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Dec 26, 2006 4:31 pm Post subject: |
|
If I were byuu,I would do this:
Ditch the frameskip code (who needs this anyway?),improve the Windows
port UI,add only the most important accessories/special chips:
Multitap,SuperScope,SA-1,Super FX 1/2 and DSP-4 (yes,TG3000 is _that_
good) support and release a *final* version of bsnes for normal
computers.
Document everything and then go for accuracy,regardless of how much
processing power it may require to run bsnes at full speed.
By the time the dot-based renderer is completed,CPUs will become more than capable to run bsnes at full speed.
Also,you can start to optimize everything after the PPU is done,lowering the requirements even more.
If you fear the chip industry is only interested in cramming more
cores,while not increasing the clocks at all,you should think twice.
AMD's secret weapon (reverse hyperthreading) and IBM's GHz race are not too far away 
It's not only more cores we need but more GHz as well,and they now that.
byuu.I would love to see your demo showing what's possible to do with a SNES if you use all of it's capabilities.
But when I think of it,isn't it possible to do the same if you had one of those SNES Emulator SE dev boxes?
You don't need to program a dot-based PPU renderer in this case.
Last edited by kick on Tue Dec 26, 2006 4:50 pm; edited 3 times in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Dec 26, 2006 4:44 pm Post subject: |
|
i totally forgot about reverse multithreading, that could solve the whole sPPU problem |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Tue Dec 26, 2006 9:20 pm Post subject: |
|
Damn...
the only thing stopping me from using bsnes right now is lack of vsync.
Is there any way to turn that on without triple buffering or do they go
together? Turning on force vertical sync in my ATI drivers for D3D
doesn't do anything either. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 26, 2006 11:06 pm Post subject: |
|
vsync doesn't work, I've tried it in the past.
Even blitting immediately upon vsync edge being detected, the blit to
the screen takes so long that the image still ends up tearing. It's
just a standard video->video hardware fullscreen blit, too. Nothing
special about it.
A shame, too. That would be one less frame of delay between input on
the controls and visual response on the screen. Something some people
are apparently very perceptive to. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Dec 27, 2006 12:23 am Post subject: |
|
vkamicht wrote: |
Damn... the only thing stopping me from using bsnes right now is lack of vsync. |
What's wrong with triple buffering? Works for me, no tearing.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Dec 27, 2006 3:03 am Post subject: |
|
Triple
buffring causes my sound to crackle horribly. In fact, the only thing I
ever could wish from bsnes right now is a fix to the sound crackle on
tripple buffer. If I could have that, I'd even pay for it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 27, 2006 3:33 am Post subject: |
|
I've
spent several days trying to fix it. Basically, when I call the triple
buffer "Present()" function, it automatically locks the entire process
until a flip occurs. This essentially locks the framerate at 60fps. But
the video simply must run at 60.09fps (or 59.97fps in interlaced mode)
to generate the correct amount of audio samples. Even a hair off, and
sound will eventually "crackle" to a certain extent.
Ideally, Microsoft would offer a PresentWhenPossible() function, that I
could call to queue a flip to automatically occur the next time vblank
is reached. When things get too far behind, no flip occurs. When they
run too fast, a frame gets skipped. While it gets trickier to handle
non-native refresh rates (60hz/NTSC and 50hz/PAL), those would still at
least work without crackling or tearing with such a function. However,
trying to add high performance timers to detect vblank edges and do the
Present() call myself always results in tearing anyway.
Much like SDL input inside a GTK+ window, this remains a major issue
that I need outside help with. For all the perceived benefits of open
source software, I've had at best 3 contributors help me with bsnes
thus far. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Dec 27, 2006 8:50 am Post subject: |
|
Using external tools for triple buffering causes the same crackling.
Wouldnt it be easyer to just cut off the 0.09 frame, and buffer add the 0.03 ? |
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Dec 27, 2006 12:12 pm Post subject: |
|
Stupid question: Does the same issue happen with OpenGL?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Dec 28, 2006 7:53 pm Post subject: |
|
I
think tripple buffering is only useful for apps like Media Player
Classic and ilk, its probably a bad match for more interactive software.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 31, 2006 7:29 am Post subject: |
|
My god. I'm not sure if whoever implemented listboxes in GTK+
was an evil genius, or absolutely retarded when it comes to designing
clean, intuitive, easy to use interfaces (eg libraries). But I won. I
beat the motherfucker and implemented listboxes into libui anyway.
Code: |
/*****
* Listbox
*****/
/*****
* GTK+'s implementation of list boxes was apparently someone's idea of a very, very cruel joke ...
* Attempt to understand the below code at the risk of your own sanity.
*****/
Window::Listbox& Window::Listbox::create(const char *style, uint
width, uint height, const char *columns, const char *data) {
type = Control::Listbox;
stringarray list, part;
split(part, "|", columns);
GType *v = (GType*)malloc(count(part) * sizeof(GType));
for(uint i = 0; i < count(part); i++) { v[i] = G_TYPE_STRING; }
store = gtk_list_store_newv(count(part), v);
safe_free(v);
split(list, "||", data);
for(uint l = 0; l < count(list); l++) {
gtk_list_store_append(store, &iter);
split(part, "|", list[l]);
for(uint i = 0; i < count(part); i++) {
gtk_list_store_set(store, &iter, i, strptr(part[i]), -1);
}
}
handle = gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
g_object_unref(G_OBJECT(store));
gtk_widget_set_size_request(handle, width, height);
gtk_widget_show(handle);
split(part, "|", columns);
for(uint i = 0; i < count(part); i++) {
renderer = gtk_cell_renderer_text_new();
column = gtk_tree_view_column_new_with_attributes(strptr(part[i]), renderer, "text", i, 0);
gtk_tree_view_append_column(GTK_TREE_VIEW(handle), column);
}
return *this;
}
void Window::Listbox::add_item(const char *data) {
stringarray part;
split(part, "|", data);
gtk_list_store_append(store, &iter);
for(uint i = 0; i < count(part); i++) {
gtk_list_store_set(store, &iter, i, strptr(part[i]), -1);
}
gtk_tree_view_columns_autosize(GTK_TREE_VIEW(handle));
}
int Window::Listbox::get_selection() {
//... because gtk_tree_view_get_selected_row(GTK_TREE_VIEW(handle)) would be too easy ...
GtkTreeSelection *selection = gtk_tree_view_get_selection(GTK_TREE_VIEW(handle));
GtkTreeModel *model = gtk_tree_view_get_model(GTK_TREE_VIEW(handle));
if(gtk_tree_model_get_iter_first(model, &iter) == false) { return -1; }
if(gtk_tree_selection_iter_is_selected(selection, &iter) == true) { return 0; }
for(uint i = 1; i < 100000; i++) {
if(gtk_tree_model_iter_next(model, &iter) == false) { return -1; }
if(gtk_tree_selection_iter_is_selected(selection, &iter) == true) { return i; }
}
return -1;
}
void Window::Listbox::set_selection(int index) {
//... because gtk_tree_view_set_selected_row(GTK_TREE_VIEW(handle), index) would be too easy ...
GtkTreeSelection *selection = gtk_tree_view_get_selection(GTK_TREE_VIEW(handle));
GtkTreeModel *model = gtk_tree_view_get_model(GTK_TREE_VIEW(handle));
gtk_tree_selection_unselect_all(selection);
if(index < 0) { return; }
if(gtk_tree_model_get_iter_first(model, &iter) == false) { return; }
if(index == 0) { gtk_tree_selection_select_iter(selection, &iter); return; }
for(uint i = 1; i < 100000; i++) {
if(gtk_tree_model_iter_next(model, &iter) == false) { return; }
if(index == i) { gtk_tree_selection_select_iter(selection, &iter); return; }
}
}
void Window::Listbox::reset() {
gtk_list_store_clear(GTK_LIST_STORE(store));
gtk_tree_view_set_model(GTK_TREE_VIEW(handle), GTK_TREE_MODEL(store));
gtk_tree_view_columns_autosize(GTK_TREE_VIEW(handle));
} |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Dec 31, 2006 6:18 pm Post subject: |
|
i guess an evil diabolic laugh is in place here
Byuu: Muhahahahahahahaha~~ |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 02, 2007 2:33 am Post subject: |
|
bsnes v0.019 has been released. But I'm afraid it's mostly just bad news all around.
Quote: |
2007-01-01 - bsnes v0.019 released
I'm releasing bsnes v0.019 today. This version contains Bandai Sufami
Turbo support, new IRQ emulation code, and some various bugfixes.
Unfortunately, this release is not entirely cause for celebration. Due
to fatal errors in Microsoft's "enterprise class" c++ compiler package,
I am no longer able to compile bsnes with profile guided optimizations.
I have tested v0.018 with and without these optimizations, and the
difference is a 40% speedup when PGO is used, even more significant
than I had previously believed. However, bsnes has now become too
complex for Visual C++ to handle. Unfortunately, there is nothing I can
do about this, except wait for Microsoft to fix their compiler.
(Warning: this paragraph contains personal opinions, skip it if you
can't handle that) As if this wasn't enough, I'm now doing my best to
wean my dependence from Microsoft's line of operating systems, as I'm
particularly concerned about the black box nature of Vista and its' DRM
control mechanisms. This isn't a road I wish to begin traveling down,
and thusly have no interest in upgrading to future versions of Windows.
Therefore, as of late, I've been writing a UI wrapper that will allow
me to code applications that are truly platform independent. The
biggest goal for this library is to design a GUI for bsnes that runs
virtually identically on both Windows and Linux/BSD. This is mostly
complete, however there were many tricks I used in bsnes using the
win32 API that I simply cannot do with GTK+ on Linux/BSD, such as the
memory editor window subclassing. I will be porting bsnes to use this
new UI wrapper, and in turn this will lessen the attractiveness /
functionality of the bsnes UI to a certain degree.
Perhaps the most devastating news is that I am still contemplating the
idea of designing a dot-based PPU renderer for bsnes. As if the loss of
PGO wasn't bad enough, this will likely eat away an unimaginable level
of performance as well. I can only estimate the speed loss being
between 100-500%. Yes, it will be that bad. And despite weeks of
planning, I cannot think of a way to allow a scanline-based and
dot-based renderer to coexist as selectable options, given their
massive differences in implementation.
And let's not even joke about SA-1 or SuperFX support ... those
processors are each four to eight times more powerful than the SNES'
main CPU.
All of these speed losses will basically make bsnes mostly irrelevant
as an alternative to ZSNES, SNES9x et al. Although I believe I really
came close to a viable alternative with v0.018, I know that I cannot
both create a mainstream emulator, as well as keep with my original
goal to emulate the SNES as accurately as possible.
The past few months have been very tough for me; trying to decide which
of the above two goals to pursue. I've still not absolutely made up my
mind. But for now, I've been sitting on a mostly untouched version of
bsnes for the last few months, and have decided to release it to the
public, profile guided optimizations be damned.
I'm once again asking for help, if anyone can figure out why bsnes
won't compile with PGO support, please let me know. I'd very much like
to get one last PGO build of bsnes released before starting on a
dot-based PPU renderer. But given the usual response I get from these
requests for help, I'd suggest no one getting their hopes up that bsnes
will ever be as fast as it once was again.
The new version can be downloaded at the usual place. I'm leaving
v0.018 up, as it may very well be the last stable, fast version of
bsnes ever released. |
|
|
Syntax New Member
Joined: 02 Jan 2007
Posts: 1
|
Posted: Tue Jan 02, 2007 6:25 am Post subject: |
|
would
it not be possible to still remain accurate and lower the system
requirements if you reprogrammed the emulator in ASM oppssed to the
much slower pure C++ coding? |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Jan 02, 2007 6:29 am Post subject: |
|
Syntax wrote: |
would
it not be possible to still remain accurate and lower the system
requirements if you reprogrammed the emulator in ASM oppssed to the
much slower pure C++ coding? |
Without even knowing the response, C++ is not "slow". Only poor code
will always make things run slow. It matters not the language.
_________________
FF4 research never ends for me.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Jan 02, 2007 6:59 am Post subject: |
|
Syntax wrote: |
would
it not be possible to still remain accurate and lower the system
requirements if you reprogrammed the emulator in ASM oppssed to the
much slower pure C++ coding? |
It would be possible. However, one of byuu's goals is writing portable code, and ASM is much less portable than C++.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 02, 2007 7:28 am Post subject: |
|
Thanks for the release, byuu. You are the master of downplaying your emulator.
This release brings the latest accuracy improvements from the .018 wips
to the public, albeit at another speed hit. Those of us with newer cpus
will be all over this like a dog on a frisbee. |
|
ssjkakaroto New Member
Joined: 26 Mar 2006
Posts: 7
|
Posted: Tue Jan 02, 2007 11:15 am Post subject: |
|
Hi
byuu, I really look forward to the day that bsnes accurately emulates
the SNES 100% regardless of speed. That code may be used as a reference
to other snes emulators, just like MAME is used as reference for other
arcade emulators.
I hope that you continue your work and thanks a lot! |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Jan 02, 2007 11:37 am Post subject: |
|
I
don't know about you guys... but I just tested bsnes v0.019, to check
the speed differences with v0.018 on my computer (Celeron D, 2.4 GHz,
512 MB RAM). I tested them with my Super Mario Kart hack.
1- Title screen, around 57 FPS on both versions
2- Player selection screen, around 55 FPS on both versions
3- During tracks, around 53 FPS on v0.018, and 60 FPS (full speed !) with v0.019
(I retried a couple of times to make sure those numbers are correct and stable)
Not only that, but the 1-pixel line flickering that used to be there
during tracks at the bottom of the first screen half is gone with
v0.019. Doesn't look like such a bad release to me, byuu.  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 02, 2007 12:32 pm Post subject: |
|
Stifu:
You're only going to notice that 40% speed up byuu was talking about in
games and sequences similar to the ones byuu profiled against.
Odds are byuu didn't profile any DSP-1 games.
And on the flip side, any game that acted in an opposite manner that
byuu profiled against would run slower, so in those cases (which are
probably rare to get the exact opposite) this release would be faster.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Tue Jan 02, 2007 12:46 pm Post subject: |
|
Nach:
ah, okay. Actually, considering byuu's somewhat "sad" tone in his
message above, I was sure he meant bsnes got slower. I misread, I
thought it was a 40% decrease. Also, the fact he said "I'm leaving
v0.018 up, as it may very well be the last stable, fast version of
bsnes ever released." made me assume v0.019 was supposed to be slower. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 02, 2007 1:38 pm Post subject: |
|
It is sad to be playing DKJM and others 40% slower. There are also some general cases which will now be slightly slower.
But it won't be for everything, that's not how PGO works.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 02, 2007 2:07 pm Post subject: |
|
Thanks for the kind words, as always.
Typically, when I run PGO, I run it on the following:
- Chrono Trigger title screen
The mode2 offset-per-tile code always make bsnes' framerate drop
significantly, PGO mitigates much of this huge speed loss whenever OPT
occurs in any games; not just Chrono Trigger.
- Zelda 3
The rain on the world map speeds up color add/sub in every game I test the final build against.
- Super Mario World
It's a classic. Has a lot of common SNES stuff to optimize against here.
By profiling against these three games, the resulting EXE is faster in
nearly every game. On a completely unprofiled game (Der Langrisser
scenario commander select screen), my framerate was at 126fps on my
main PC with v0.018. It is now at 83fps with this latest release. I get
similar results with most every other game I play.
We've already known in the past that all of my speedup attempts (incl
PGO) only seem to help newer processors. Look at the last set of posts
on the topic of v0.018's speed and subsequent speedups:
- Celerons showed virtually no differences
- Pentium IV CPUs barely showed a difference
- AthlonXPs showed a small difference
- Athlon64s showed a big difference
- Core 2 Duos showed the biggest difference of all
The most obvious difference for those of you not in "the know" is that
the above list is roughly in order from the highest pipeline count to
the lowest. It isn't just because the chips are "newer" or anything
like that.
PGO isn't just beneficial for the exact games they are profiled
against, as all SNES games share similar characteristics (eg opcode
"beq" will always be used more than "stp" in any
given game). Take for example a switch table with eight cases. Let's
say case 0 virtually never happens, and case 3 almost every single
time. PGO will see this and reorder the table to test for case 3 first.
Now you're thinking, "ok, why not do that in your code?" Two
reasons. One, it's more logical to order the table from cases 0 - 7.
Human beings trying to read the code won't understand why the table is
out of order, in fact: seemingly in random order. Two, I don't always
know which parts of the code PGO optimizes. It doesn't provide a list
of changes for me to pick out the biggest overall speed gains.
I will agree with Nach though, that PGO won't result in a 40% speed
drop everywhere. But there are games that are that much slower for me,
and many that are still 20+% slower than the last build. I've yet to
find any game that was slower as a result of running PGO, but I
wouldn't be surprised if such games did exist. They would be the
exceptions, however.
Anyway, I have some ideas I'd like to try this weekend to see if they
help. I'd suggest not getting one's hopes up, but maybe it'll build
with PGO again. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 03, 2007 11:34 pm Post subject: |
|
Hmm,
some (stolen) code from DeSmuME's GTK+ port. Posting here so I remember
to add it to libui. This should hopefully allow (keyboard-only) input
for the GTK+ port. Hey, it's a start.
Code: |
static gint Key_Press(GtkWidget *w, GdkEventKey *e)
g_signal_connect(G_OBJECT(pWindow), "key_press_event", G_CALLBACK(Key_Press), NULL);
gtk_widget_set_events(pDrawingArea, GDK_EXPOSURE_MASK |
GDK_LEAVE_NOTIFY_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK
| GDK_POINTER_MOTION_MASK | GDK_KEY_PRESS_MASK );
static gint Key_Press(GtkWidget *w, GdkEventKey *e)
{
int i;
u16 Key = 0;
for(i = 0; i < DESMUME_NB_KEYS; i++)
if(e->keyval == Keypad_Config[i]) break;
...
} |
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Jan 05, 2007 6:36 pm Post subject: |
|
Wow
this is interesting! If I set bsnes 19 to my custom res settings for
fullscreen, I no longer have crackling sound with tripple buffer! It
may be by pure fluke, but I'll take it!
My custom
fullscreen res is 1110x1024 with the bsnes res set to 1024x896x60.
Required the use of power strip to add 1110x1024 to the video card. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Jan 05, 2007 10:14 pm Post subject: |
|
byuu,can you add hue/saturation (or rgb) controls to bsnes? That's the only thing I find missing from bsnes.
For now,the colors in bsnes look a lot different than what I used to get on my TV.
For example,the color output of Samsung TV sets is more on the blue
side (compared to a standard computer monitor),while old TV sets of the
80's are more on the yellow side.Sometimes the differences can be
huge,like the menus in Breath of Fire (J).
NEStopia and ZSNES have this feature and it helps a lot to get the colors close to the real thing. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 06, 2007 4:37 am Post subject: |
|
kick, please take a look at bsnes/src/snes/video/video_colortable.cpp.
If you can provide me with algorithms in compatible form to eg:
Code: |
void SNES::gamma_adjust(int32 &input) {
int32 result;
result = int32(pow((double(input + 1) / 256.0), double(config::snes.gamma) / 100.0) * 256.0);
input = minmax<0, 255>(result);
} |
Then yes, I will add these sliders for you. The algorithms must take as
input and return as output, either BGR555 or RGB888 (and not YUV,
unless you want to convert back and forth inside the function). I have
not been able to find the appropriate algorithms myself.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jan 11, 2007 11:32 am Post subject: |
|
A few people have been confused about switching modes in bsnes. Here's a recommendation for .20:
- Change "Video profile to configure" to simply "Configure for"
- Elongate the selection box and then change "Fullscreen" to "Fullscreen (F11)"
If .20's different GUI makes this moot, then just ignore this and I'll
wait for WIPs. Truly, I should have thought of this before .018, though. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jan 12, 2007 1:29 pm Post subject: |
|
Byuu,
here are the funtions for altering the colour based on hue, saturation
and value adjustments.. I have tested them and they should be (close
to) as efficient as possible, though I do think it would be more
efficient to use one function for all three (but right now I can't be
buggered to make one It'd be an extended version of the hue_adjust)
hue_adjust, hue is a floating point value stored in degrees - will not
work right if adjustment pushes it below -360° or above 720°:
Code: |
void SNES::hue_adjust(int32 &input){
uint8 R = (input >> 16) & 0xff;
uint8 G = (input >> 8) & 0xff;
uint8 B = (input ) & 0xff;
uint8 V = (R > G && R > B) ? R : (G > B) ? G : B;
real32 D = V - ((R < G && R < B) ? R : (G < B) ? G : B);
real32 H, S = V ? D / V : 0;
if(S){
if(V == R) H = 60 * (G - B) / D;
else if(V == G) H = 120 + 60 * (B - R) / D;
else H = 240 + 60 * (R - G) / D;
H += config::snes.hue;
H += 360 * ((H < 0) + (H < -360) - (H >= 360));
H = modf(H / 60, &D);
R = V * (1 - S) + 0.5;
G = V * (1 - (H * S)) + 0.5;
B = V * (1 - ((1 - H) * S)) + 0.5;
switch(uint8(D)){
case 1: input = (G << 16) + (V << 8) + R; break;
case 2: input = (R << 16) + (V << 8) + B; break;
case 3: input = (R << 16) + (G << 8) + V; break;
case 4: input = (B << 16) + (R << 8) + V; break;
case 5: input = (V << 16) + (R << 8) + G; break;
default: input = (V << 16) + (B << 8) + R; break;
}
}
} |
saturation_adjust, saturation is an floating point value between 0.0 and 1.0:
Code: |
void SNES::saturation_adjust(int32 &input){
real32 D, N, S;
uint8 R = (input >> 16) & 0xff;
uint8 G = (input >> 8) & 0xff;
uint8 B = (input ) & 0xff;
uint8 *L, *M, *H;
switch(4 * (R > G) + 2 * (R > B) + (G > B)){
case 0: L = &R; M = &G; H = &B; break;
case 1: L = &R; M = &B; H = &G; break;
case 3: L = &B; M = &R; H = &G; break;
case 4: L = &G; M = &R; H = &B; break;
case 6: L = &G; M = &B; H = &R; break;
case 7: L = &B; M = &G; H = &R; break;
}
D = *H - *L;
N = (*M - *L) ? 0.5 * (*H - *M) / real32(*M - *L) : 1;
S = *H ? D / *H : 0;
S = minmax<0, 1>(S + config::snes.saturation);
D = S * *H;
*L = *H - D + 0.5;
*M = *H - D * N + 0.5;
input = (R << 16) + (G << 8) + B;
} |
value_adjust, value is an integer in between 0 and 255:
Code: |
void SNES::value_adjust(int32 &input){
uint8 R = (input >> 16) & 0xff;
uint8 G = (input >> 8) & 0xff;
uint8 B = (input ) & 0xff;
real32 V = (R > G && R > B) ? R : (G > B) ? G : B;
V = minmax<0, 255>(V + config::snes.value) / V;
input = (int32(R * V + 0.5) << 16) + (int32(G * V + 0.5) << 8) + int32(B * V + 0.5);
} |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 12, 2007 4:29 pm Post subject: |
|
I'm
not sure I understand why people would want to adjust HSV in an SNES
emulator ... HSV is neither native to the SNES, nor to the YUV/YIQ
televisions people mostly played SNES games on. It's really just
graphics artist fodder that has little use in actual display technology.
I would think YUV/YIQ style adjustments (tone, etc) would be what
people are expecting. I do have an algorithm for high-precision
RGB<>YCbCr, but I don't really know how to make TV-style
adjustment options from manipulating those values, other than the
obvious brightness adjustment. Should I just make scalers (~0.25 - 4.0x
intensity) for the Cb and Cr channels? |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Jan 12, 2007 4:33 pm Post subject: |
|
byuu wrote: |
I'm
not sure I understand why people would want to adjust HSV in an SNES
emulator ... HSV is neither native to the SNES, nor to the YUV/YIQ
televisions people mostly played SNES games on. It's really just
graphics artist fodder that has little use in actual display technology. |
"Because, we want it."
Note, this is generally the same group of people who want to
"overclock" the SNES. Though, I'm pretty sure everyone wants to have
TV-ish control altogether.
_________________
FF4 research never ends for me.
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sat Jan 13, 2007 7:39 am Post subject: |
|
if
bsnes runs in an overlay, couldn't one muck around with the overlay
sliders in the display settings? (system and graphics card dependent, I
suppose). Or mess with the monitor's tint until mario looks like an
oompa-loompa man?
hey byuu, could you model the
distortion of the obviously imperfect second order low-pass filter for
the audio output, taking into accound the imperfections of the
particular capacitors and op-amps used? |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 14, 2007 12:48 pm Post subject: |
|
I
just got my Core 2 Duo rig installed last night (was on a P4 2.4c).
First thing I did was run through the Chrono Trigger intro in bsnes
.019. Never went under 60 and the sound never crackled, even on the
black omen effect. POWAR!  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 14, 2007 8:14 pm Post subject: |
|
But how many frames per second do you get with speed throttling disabled? :) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 15, 2007 4:25 am Post subject: |
|
First screenshots of libui in bsnes:

Same exact codebase. The current WIP is obviously missing any semblance
of a GUI, other than the menubar and a ROM file loader.
Lots of issues on both ports, of course. I'm aware of the audio
repeating issue on the Windows port and already know how to fix it (had
the same problem with the old Windows UI). Linux of course simply has
no audio or input.
I'm planning on moving the framerate counter to display inside the
image, rather than on the titlebar this time. That of course won't
happen anytime soon. I don't expect to be adding fullscreen support
back in anytime soon, either.
Once this port gets stable enough, I intend to remove the "ui/win" and
"ui/sdl" ports completely. After that, I'm going to have to start
seriously rewriting a lot of internal stuff.
I'm also planning to go with a simpler user interface this time around.
bsnes v0.019 had too many options and features. I think I may scale
back this time and make things a lot simpler. Move a lot of the control
settings back into the menubar, rather than in the custom options panel
(which will most likely still exist). |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Mon Jan 15, 2007 9:07 am Post subject: |
|
I
like the framerate counter better inside the title bar, personally, so
that the game screen is still totally intact... But maybe you want to
put it over the game screen so that it can still be seen in fullscreen
mode, or something. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 15, 2007 10:10 am Post subject: |
|
Nice to see the rewrite is coming along.
To answer your earlier question:
1.86ghz e6300 / Chono Trigger title screen
.018 - 140 on pendulum, 90 max dip on wavy text
.019 - 105 on pendulum, 60 max dip on wavy text
So I'm losing around 33% without PGO. Still above the the magic 60 on the worst case scenarios, though. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jan 15, 2007 10:36 am Post subject: |
|
Can you play with 4 players in Streetracer?
The 4 split-screens might slow things down...
_________________
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 15, 2007 11:26 am Post subject: |
|
Players 3 and 4 are grayed out. Probably because bsnes doesn't support multi-tap. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 17, 2007 8:05 am Post subject: |
|
http://byuu.cinnamonpirate.com/images/bsnes_x2.png
Look closely to see what's new. You can pretty much thank Nach for that.
Also, if anyone's good at makefiles, can you please take a look at:
http://byuu.cinnamonpirate.com/temp/Makefile.txt ?
I'm trying to create an implicit rule that can match:
%.$(OBJ) : $(<D)/%.cpp
However, gmake seems to be ignoring $(<D) completely. I've tried
countless variations on this, such as $(dir $<)%.cpp, $(basename
$<).cpp, etc, but none seem to work.
I know it's possible to use $< in the dependency list, because %.$(OBJ) : $< matches all targets.
As it stands, I have to use a really evil trick to get around this, by
recursively invoking make with $< as a variable so that I can use
the conditional calculations to figure out what filetype $< is.
EDIT: nevermind. I figured out another trick that works. Replace the
recursion block with the below, and you get the same effect whilst only
needing to invoke make one time.
Code: |
######################
### implicit rules ###
######################
#nARGS=-c $< -o $@, /c $< /Fo$@, etc.
buildas = $(AS) $(ASFLAGS) $(ASARGS)
buildcc = $(CC) $(CFLAGS) $(CARGS)
buildcpp = $(CPP) $(CFLAGS) $(CARGS)
%.$(OBJ): $<
$(patsubst %.asm,$(buildas), \
$(patsubst %.c,$(buildcc), \
$(patsubst %.cpp,$(buildcpp), \
$<))) |
Basically, we simulate the conditional compilation (based on file
suffix) by using nested variables and pattern substitutions on the
first dependency, which is hardcoded as the source target in individual
object definitions. How intuitive! Hooray, open source software! Now if
only gmake could automatically deduce dependencies from these files,
eliminating the need for the individual object rules to point at every
file that is part of said object. Hahahah, yeah, just dreaming :)
I think I may just make an alternative to gmake, but I'll hold off for
now, since I've found a workaround in gmake for the time being.
EDIT 2:
The above still wasn't sufficient for Nach's plans. Fair enough, let's step things up another notch.
Code: |
%.$(OBJ): $<
$(if $(filter %.asm, $<), $(buildas))
$(if $(filter %.asm, $<), $(if $(filter mingw, $(CC)), objfix $@))
$(if $(filter %.c, $<), $(buildcc))
$(if $(filter %.cpp, $<), $(buildcpp)) |
Last edited by byuu on Wed Jan 17, 2007 7:29 pm; edited 1 time in total
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Thu Jan 18, 2007 11:40 pm Post subject: |
|
Nice work on libui - how did you get fast drawing inside the GTK window? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jan 19, 2007 9:36 am Post subject: |
|
doh, i just realised i have not been in the developement secrtion for over 3 weeks, thanks for waking me up Deathlike |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 19, 2007 9:51 am Post subject: |
|
Quote: |
Nice work on libui - how did you get fast drawing inside the GTK window? |
Thanks, you're free to use it with no strings attached if you like.
I implemented two video blitters for GTK+.
One uses GTK+'s own gdk_draw_rgb_image function (not that good, it only
accepts RGB888, so you have to convert the SNES renderer output from
RGB565 -> RGB888, then transfer that to video memory, and somewhere
along the way convert back to the display format (which, in my case, is
RGB565).
The other is just the SDL_WINDOWID environment variable hack.
Neither support hardware scaling, and neither allow me to use SDL input for keyboard input support.
I'm planning on adding an Xv renderer next, to perform hardware
scaling. The only problem with that is there's absolutely no way to
vsync / triple buffer with Xv, and hardware bilinear filtering is
always enabled. I'd also like to add an OGL renderer, but that seems
like too much work for me. It took me months to really get the hang of
D3D9, and I don't feel like learning another 3D API just to blit 2D
rects to the screen.
As for input, I'm going to go with Nach's suggestion, and just capture
key_press_event + key_release_event on the GTK+ window. To avoid sticky
keys when the application loses focus (and thus misses
key_release_event messages), I'm going to catch window focus
gained/lost messages and clear the keyboard buffer. Best I can do since
X-Windows lacks an alternative to Windows' GetAsyncKeyState. Not great,
but better than no input at all. I'm hoping to still use SDL input for
gamepad support one day.
---
In other news, the Makefile is now updated to the most recent work.
I've also simplified libco a little more (co_init and co_term are
called automatically; pre-defined stack sizes are now multiplied by
sizeof(void*) for semi-consistent behavior across different platforms)
and ported it to two new targets: x86-64 and ucontext. The x86-64 port
is currently broken, as I lack a 64-bit OS to test the code on. I could
really
use some help if anyone is familiar with x86-64 programming to tell me
where the problem is. It's a 1:1 port of libco_x86, but with registers
changed according to the SysV ABI (I'll make another for Microsoft's
when I get the SysV/Unix port working). Bisqwit also gave me an
AMD64-optimized version which will be included on the libco page as an
optional download. This one works but is licensed under CC BY-SA.
The ucontext port just uses <ucontext.h> from Unix. For those of
you who've said I should just use pth instead of "reinventing the
wheel" by making libco, feel free to try this port out. pth uses
ucontext for its' Unix wrapper, and setjmp magic for Windows.
To say ucontext is slower is a severe understatement: it is fifty times slower than libco_x86. Even windows fibers are only twice as slow as libco.
But, don't take my word for it, see for yourself:
http://byuu.cinnamonpirate.com/temp/libco_ucontext.h.txt
http://byuu.cinnamonpirate.com/temp/libco_ucontext.cpp.txt
Lastly, the ZIP for the latest beta:
Code: |
http://byuu.cinnamonpirate.com/files/libco_v09_beta.zip |
Again, if anyone could take a glance at libco_x86_64.asm and give me suggestions, it'd be appreciated greatly.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Jan 19, 2007 1:19 pm Post subject: |
|
If
it's worth anything, OpenGL works in the exact same way as D3D9 for the
most part. Slightly different function calls are the main difference.
If you now understand the 3D hardware drawing process and concepts to
get things going in D3D, it should be MUCH easier for your to learn
OpenGL if you choose to than it was D3D. It's just alternate syntax to
the same thing. That's a generalized statement of course, but mostly
true.
_________________
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. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Jan 19, 2007 10:53 pm Post subject: |
|
OpenGL
is pretty easy - it took me only a few hours to get it working in
SDLMAME initially. Check out the NeHe tutorials, they're quite good.
The one issue is that on Linux the ATI binary driver is very
performance-sensitive about 15/16 bit texture formats - it prefers
either 1-5-5-5 or 5-5-5-1 (I don't recall which off the top of my head)
and is really slow with 5-6-5 or the "wrong" 5-5-5 format. The NVidia
binary driver and most open source 3D drivers don't care - they're
always fast.
Also, older OpenGL (pre 2.0) required
power-of-2 sized textures, which isn't much of a problem on the SNES
since the framebuffer width already is (and you can just pad the height
with black and adjust the U/Vs so everything works out). |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 19, 2007 11:14 pm Post subject: |
|
Might
I get a link to that code to take a look at it, please? That's a shame
about RGB565, but I think everything should still work. I believe my
filters apply to BGR555 and finally output via one single color lookup
table, so I should be able to do any 16-bit format (but not 24/32-bit
formats) with it with zero speed loss. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Jan 20, 2007 11:24 am Post subject: |
|
Maybe switching to openGL will fix the crackling sound with tripple buffering |
|
Firon Trooper
Joined: 05 May 2006
Posts: 367
|
Posted: Sat Jan 20, 2007 6:33 pm Post subject: |
|
Why would it? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jan 21, 2007 1:01 pm Post subject: |
|
Magic |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Jan 21, 2007 2:00 pm Post subject: |
|
Firon:
Why wouldn't it? *is interested*
byuu wrote: |
Ideally,
Microsoft would offer a PresentWhenPossible() function, that I could
call to queue a flip to automatically occur the next time vblank is
reached. |
I don't know anything about OpenGL, but maybe it handles VSync better since it uses a different driver set?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Sun Jan 21, 2007 8:14 pm; edited 1 time in total
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 22, 2007 8:28 am Post subject: |
|
Found a regression bug that unfortunately made it into v0.019 official.
HDMA bus sync timing is required for BoF2 German ( sigh, and d4s went
out of his way to ask people to use bsnes, too ;_; ). I turned off HDMA
bus syncing since it was glitchy with either Battle Racers or SoM2 map
(I think it was the latter). I'll have to look into it further. For now
I have two workarounds: 1) temporarilly raise the HDMA sync delay from
12 to 18 clocks (from best case timing to average timing, still not
great of course), 2) revert to the old HDMA bus sync code and take the
hit from the other game. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 22, 2007 7:58 pm Post subject: |
|
Before
anyone asks what it is, I think I just figured it out. If you don't
jump to the title screen, the game will hang after the team bof2
screen. Only happens after the first run though, with a .srm generated. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 22, 2007 8:35 pm Post subject: |
|
Since it runs on hardware, it's clearly my fault, but I have to admit, the translation is quite
sensitive to timing. Moreso than any commercial game on the system. Not
saying that's a bad thing: you'll always get correct results on
hardware, and that's all that counts. If anything, it shows d4s pushed
the hardware even harder than commercial devs could.
Since a difference of ~6 master clock cycles/scanline (roughly the
length of 1/4th of an opcode) broke it completely, I'm really quite
impressed that it runs on other emulators at all.
The next release should address the problem. I will continue to be
cheap and use the ~18 clocks fix that works for everything. I'm way too
far into the UI to switch up and work on the core again just yet.
Should I post an interim release for this fix, or just an advisory to
please use v0.018 for this game for now? The new UI is still in
shambles, but the old one still compiles. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 22, 2007 10:33 pm Post subject: |
|
Question is, how many bsnes users aren't still using .018 already? And how many of those are German? 
What exactly was it that broke PGO anyway? New IRQ code? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 22, 2007 11:15 pm Post subject: |
|
I suspect I don't have that large of a userbase. Probably 5,000 or so, tops.
Unfortunately, I don't know exactly what broke PGO or when. I know it
was already very, very flaky and I would often have to try several
times to get it to work. I had a list of games that I knew I couldn't
profile. Now, I can't profile anything at all. Very annoying. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Jan 25, 2007 8:38 pm Post subject: |
|
Byuu,
you have asked for help about certain code problems you have, but it
seems you get little response from those requests for help. I imagine
that you could do two things to increase interest in bsnes and get more
people to look at the code:
- Have a forum hosted
on your own website. As it is now, it's kind of hard to find
information in this really long thread.
- Have your code hosted on some kind of public repository (SourceForge/BountySource).
I would definitely love to see some of the work you do to the code
between releases. It would also make the code more accessible to
everyone.
I'm sure you've already thought about these things, I just wanted to put it out there.
To some extent, I want to learn C/C++ just so I could contribute to
your program (mainly GUI stuff and extra features). I like your coding
philosophy. I have become frustrated with documenting ZSNES because it
so freakin complex and has so many features with complex behavior. Any
contributions I would (theoretically) make would have complete,
predictable behavior and be self-documenting where appropriate.
If you don't feel you have the time to change/maintain your website and
a forum, I would feel honored to take on that task for you. I have
experience administering my own private phpBB2 forum. And, of course, I
have extensive experience with HTML (~7 years).
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 25, 2007 9:01 pm Post subject: |
|
I dislike phpBB, and don't have SQL access anyway.
I've been meaning to write my own board, but I always have something more important to work on :/
I definitely dislike SourceForge / BountySource. I work on the codebase
locally, so I'd have to upload all of the changes. And since I don't
have any full time coders working on bsnes with me, it's not really
very productive ...
It doesn't help that the most important things I need help with are so
highly specialized that there's maybe three or four people who might be able to help still around :(
Luckily, thanks to Nach and some tricks on my end, the Linux stuff
should be taken care of. Nach's libao port has audio working, and I'll
have input working here shortly. Then all we need is a better renderer
to do hardware video scaling. Otherwise you're stuck with a 256x224
window only. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu Jan 25, 2007 11:04 pm Post subject: |
|
byuu wrote: |
I dislike phpBB, |
Is it cos of all the spambots 
But meh. I know you said you don't have SQL access, and you're going to
write your own board, but you might wanna give SMF a try.
_________________

<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Jan 26, 2007 1:53 pm Post subject: |
|
SMF
as of version 1.1 has been spambot proof on ROMhacking.net without any
modifications. It's probably only a matter of time, but it does seem to
be one step ahead of some other PHP based free forum software.
Also, don't forget about SQLite. It's built right into PHP5, NO
database server required! It uses SQL with flat files. Any piece of
forum software with a database abstraction layer can probably use it.
I've seen mods for a few popular boards. Just something to keep in mind
for somebody who doesn't have access to any database server software.
Because it's flat file, SQLite is in many cases faster than say MySQL.
So, even if you want to code your own, that's definitely an option to
consider.
_________________
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. |
|
Que saskatchewanite
Joined: 26 Apr 2006
Posts: 317
|
Posted: Fri Jan 26, 2007 5:39 pm Post subject: |
|
Nightcrawler wrote: |
SMF
as of version 1.1 has been spambot proof on ROMhacking.net without any
modifications. It's probably only a matter of time, but it does seem to
be one step ahead of some other PHP based free forum software.
Also, don't forget about SQLite. It's built right into PHP5, NO
database server required! It uses SQL with flat files. Any piece of
forum software with a database abstraction layer can probably use it.
I've seen mods for a few popular boards. Just something to keep in mind
for somebody who doesn't have access to any database server software.
Because it's flat file, SQLite is in many cases faster than say MySQL.
So, even if you want to code your own, that's definitely an option to
consider. |
SMF is unsecure as hell imo. I ran it on my domain for a while. It was
hacked within a week. Though this may have changed because I have not
tried the newer versions. I was using the RC2 build for 1.1.
_________________
everything i say is a lie
the above line is true
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Fri Jan 26, 2007 10:11 pm Post subject: |
|
Thats whatcha get for running RC versions of stuff in a production enviournment 
But in all seriousness, the old school 4 life boards were using SMF 1.1
RC2 (or was it 3 when I first signed up?) and it worked fine 
_________________

<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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 29, 2007 8:04 am Post subject: |
|
I
now have an Xv renderer for Linux/BSD users. This means hardware
accelerated video scaling. It also supports all video modes (hires,
interlace and overscan settings all work as expected).
This version also has a bit more of the UI rewrite done, but not much.
I've been having a lot of troubles with making a unified API that works
the same on both Windows and GTK+. I still have some problems (you
can't get the absolute size of a window in GTK+, so snapping windows to
screen edges like in the Windows port is not possible), but I've also
made some progress as well (managed to create a unified API for
controlling listbox column sizes on both platforms).
Well, here's a screenshot. Pretty much the only thing stopping the
Linux port from being usable now is the lack of input support. In due
time ...
http://byuu.cinnamonpirate.com/images/bsnes_x3.jpg |
|
dongle New Member
Joined: 12 Aug 2005
Posts: 4
|
Posted: Tue Jan 30, 2007 3:42 am Post subject: |
|
byuu, that's looking great! thanks for the port. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue Jan 30, 2007 10:05 am Post subject: |
|
byuu wrote: |
(you
can't get the absolute size of a window in GTK+, so snapping windows to
screen edges like in the Windows port is not possible) |
To be fair, under X11 that sort of thing is really the responsibility
of the window-manager, not each individual app. I know Metacity (the
standard GNOME window manager) works like that out of the box, many
others have it as an option.
|
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Tue Jan 30, 2007 11:23 am Post subject: |
|
It's been a long time since I tried bsnes and it seems it's progressed quite a bit, great work, seriously . Sorry if I mention something that has already been stated but I just don't feel like reading 87 pages... so go ahead and tell me if I say something redundant.
I recently downloaded it again to see how it emulates Star Ocean as
compared to ZSNES, and the first thing I noticed is that bsnes doesn't
auto patch IPS files. So I manually patched SO with SNESTool and gave
it a shot and that's when I noticed the DeJap logo displays as a bunch
of messed up pixils. What could possibly be the reason for that?
Other than that, so far so good. It doesn't seem to have the sound bugs
which ZSNES has with it (the sound pausing after a battle). bsnes'
sound in general is fine... except for when it drops down below 60
frames per second to say... 59, then the sound is thrown completely off
sync (or is the framerate/sound thing just a coincidence?) and sounds
like garbled crackling.
In some situations for some reason it just drops down to 59 frames such
as Chrono Trigger's first page in it's menu, it doesn't matter what
filters or whatever I use it seems to always run at 59FPS and the sound
is thrown off sync, when I move to any other page of it's menu the
sound goes back to normal. Could any of you try this out to see if it
that's how it is in general or if it's just me?
I know the emulator is a work in progress and some of these questions
may have been answered in the previous pages but I was wondering if
bsnes will ever include the following things:
-Auto IPS patching (I dunno about you guys but I prefer to have separate IPS files)
-Filters such as 2xSaI
-vSync
-Sound options
-Save states
-Save directory options |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 30, 2007 1:09 pm Post subject: |
|
Quote: |
I
recently downloaded it again to see how it emulates Star Ocean as
compared to ZSNES, and the first thing I noticed is that bsnes doesn't
auto patch IPS files. So I manually patched SO with SNESTool and gave
it a shot and that's when I noticed the DeJap logo displays as a bunch
of messed up pixils. What could possibly be the reason for that? |
The garbled gfx is probably the result of a faulty patching. Try NSRT.
edit: also in regard to translations in general keep in mind that if a
patch fail on real hardware it will probably fail on bsnes as well.
Some patches will work fine with Zsnes but not on hardware because they
were coded primarly with Zsnes in mind (which doesn't quite emulate the
Snes to the same extend as bsnes does)
Quote: |
Other
than that, so far so good. It doesn't seem to have the sound bugs which
ZSNES has with it (the sound pausing after a battle). bsnes' sound in
general is fine... except for when it drops down below 60 frames per
second to say... 59, then the sound is thrown completely off sync (or
is the framerate/sound thing just a coincidence?) and sounds like
garbled crackling.
In some situations for
some reason it just drops down to 59 frames such as Chrono Trigger's
first page in it's menu, it doesn't matter what filters or whatever I
use it seems to always run at 59FPS and the sound is thrown off sync,
when I move to any other page of it's menu the sound goes back to
normal. Could any of you try this out to see if it that's how it is in
general or if it's just me?
|
Two reason it might drop below 60. 1) Either you're hiting a
particularly demanding part of the game and you don't have the
horsepower to get a consistent 60fps. or 2) This has something to do
with the internal Snes framerate versus monitor refresh rate in which
case the crackling sound should be fairly consistent (like every 10
seconds)
Since you said it only occur in a specific place it most likely caused
by 1. Try unthrottling bsnes and check the framerate. If it goes from
72 to 59-60 there's your reason
The only solution to 1) is of course to get a better CPU. As for 2)
Someone (FirebrandX) mentionned they were able to get rid of the
cracking sound with triple buffering on using Powerstrip.
http://board.zsnes.com/phpBB2/viewtopic.php?t=4510&start=2100
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 30, 2007 3:30 pm Post subject: |
|
Quote: |
So
I manually patched SO with SNESTool and gave it a shot and that's when
I noticed the DeJap logo displays as a bunch of messed up pixils. What
could possibly be the reason for that? |
Probably the same reason Gideon Zhi's Ys 4 translation doesn't show any
of the dialogue font in bsnes or on real hardware: the patch author was
unable to test on hardware (though in this case due to the use of a
special add-on chip that copiers do not support), and relied on ZSNES.
The game looked fine on ZSNES, so it was assumed correct.
Though we can't be certain how this translation works on hardware since
none of us can test it, I'm willing to put my money on it being a
problem with the translation; given that out of 4,000+ games, only two
minor OAM graphical issues have been found in bsnes.
Perhaps I'll have to start displaying a popup when you load these fan
translations or something, this question is way too common.
Quote: |
In
some situations for some reason it just drops down to 59 frames such as
Chrono Trigger's first page in it's menu, it doesn't matter what
filters or whatever I use it seems to always run at 59FPS and the sound
is thrown off sync, when I move to any other page of it's menu the
sound goes back to normal. Could any of you try this out to see if it
that's how it is in general or if it's just me? |
Your processor is too slow. Unfortunately, I lost 30-40% of the speed
in bsnes because Microsoft's multi-thousand-dollar-per-license
"enterprise-class" compiler is unable to build bsnes with profile
guided optimizations. The linker simply bails out halfway through.
Another 30% was lost to IRQ accuracy improvements that really only fix
one or two games. Every time I try and range test IRQs, I end up with
bugs. So I rewrote the IRQ handler to test every clock position. The
code is much simpler, but much slower as well. So I share the blame
with a lot of the recent speed losses. Even my processor can't keep up
with 60fps in all games anymore. To make matters worse, the big
conundrum now is whether to slow down bsnes another 200-300% to fix
those two aforementioned graphics bugs affecting only three games. The
idea of having 100% compatibility is nice, but at the same time, I
wanted to be able to actually use bsnes one day, too :(
Quote: |
-Auto IPS patching (I dunno about you guys but I prefer to have separate IPS files)
-Filters such as 2xSaI
-vSync
-Sound options
-Save states
-Save directory options |
IPS is defective. No two ROM hackers can agree on whether to make all
patches against headered or unheadered ROMs (even though the former is retarded), IPS doesn't specify, and I can't simply guess. bsnes will one year have auto UPS patching (IPS' successor).
Vertical sync / triple buffering is hopelessly broken. I can't fix it, so no. bsnes will never, ever have this.
bsnes has all the sound options necessary. Mute and playback frequency
(this is how fast forward / slow motion work in bsnes).
No, I'll never have statestates. Not ever.
Save directory options have been there for over a year. I keep the
lesser used functions outside of the configuration screen. Hint: look
in the config file.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 30, 2007 6:34 pm Post subject: |
|
So,
easily the most desirable thing for bsnes would be liquid smooth video
and audio. Unfortunately, as we know, it's completely impossible to be
100% faithful to the original hardware, exactly match the speed of a
real system, and maintain perfect reproductions of video and audio at
the same time.
So something would have to give. As
best I can see it, there are videophiles and audiophiles, so ideally I
should cater to each individually. Either way, it's not possible to run
the SNES emulation at the exact speed of a real system and get smooth
video or audio. Monitors cannot run at 60.09hz and sound cards cannot output 32040hz. So that's out either way.
So then, two options. First, video synchronization:
Scale video playback to refresh rate. That is, 60/120hz for NTSC,
regardless of interlace setting. 50/100hz for PAL. If your monitor
doesn't support one of those (and most LCDs won't do 50 or 100hz),
you're out of luck. Sorry.
Now, we resample the audio to accomodate this. 32040hz becomes
(60/60.09*32040)=~31992hz. Finally, that would need to be resampled to
32000hz. Perfect video, always smooth. Slight sound distortion. Input
response time might be slightly higher with this approach, and in turn
audio response time might be slightly lower.
Second option, audio synchronization:
There's no getting around the pitch being a tad off due to the sound
card outputting at 32000hz instead of 32040hz, but we can avoid
resampling the audio, at least.
So then, we play the audio back at 32000hz, and still sync the video to
the output of the monitor. Too many or too few video frames may be
generated, which can cause a skipped / duplicate frame on occasion.
(32000/32040*60.09)=~60.015hz. So, one dropped frame every
(1/0.015)=~66.7 seconds. Crystal clear audio, but every minute or so,
you'll notice a slight stutter. Especially in animations and scrolling
backgrounds.
Has to be one or the other. Otherwise you deal with shearing video
and/or cracking audio. I'm thinking, offer both, but make the default
the video synchronization method. Despite more people claiming to be
audiophiles, I've noticed that many simply don't know what they're
talking about (not saying that about anyone here, just in general --
especially toward the people who don't even have SNES systems to
compare against and go from memory alone) :/
Video skipping or duplicating frames would be far more noticeable to
the majority of users. Feel free to present counterpoints and I'll
consider them.
And now, the bigger problem: I don't know how to implement either of
these. But I can at least add the options and APIs into bsnes, in case
someone, somehow, is able to help implement this stuff in the future. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Jan 30, 2007 7:15 pm Post subject: |
|
Having both options would definitely be nice. It would allow the user to choose which thing they want to be "perfect."
How does bsnes work currently, in terms of this stuff?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 30, 2007 9:53 pm Post subject: |
|
It
uses the audio synchronization (audio is not resampled at all, but
plays back at 32000hz instead of 32040hz due to sound card limitations
-- cheap cards probably resample anyway to 44050hz or 48000hz
internally), but the triple buffering on the video doesn't work, so the
video shears badly. It gets worse and worse as your refresh rate
lessens. At 60hz (the limit on my new monitor), it's almost unbearable.
Last edited by byuu on Tue Jan 30, 2007 9:54 pm; edited 1 time in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Jan 30, 2007 9:53 pm Post subject: |
|
would a tool Like Reclock be of any help in this case?
Its made for syncing audio and video to monitors, fixes a lot of problems for me on lcd
http://reclock.free.fr/
What is it ?
The purpose of ReClock is to definitely get rid of jerky playback
of AVI and MPEG material on a PC (or a HTPC driving a TV, a flat panel,
or a video-projector). It's a DirectShow filter which is loaded in
place of the default directsound audio renderer.
It provides a new reference clock that is locked to the video card hardware clock, in order to ensure that frames are played at the exact speed of what is expected by the video card vertical sync.
It also provides a frame rate adaptator for media files that do not match a multiple of the video card refresh rate (ex: playback of 23,976fps IVTC NTSC on a PAL TV).
The combination of the two will give you the true experience of smooth playback with your PC.
Finally it is an audio renderer with hardware or software rate adaptation in real-time, multi-channel audio, audio timestretching (pal speedup compensation) and dynamic range compression capabilities.
For a full description of ReClock, please read carefully the README
file in the distribution. There is also a little FAQ at the bottom of
the page that answers common questions. You can also visit the forums
here to meet other users. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 30, 2007 10:34 pm Post subject: |
|
Thank you for the emphasis. It makes the paragraph much easier to read :P
No, doesn't look helpful. But thanks anyway.
Ok, I worked this out on paper.
My idea is to keep a 3-stage ring buffer. Call them r0, r1, r2. The
size of each ring will be determined at startup, and will be constant.
We will call the size of each stage l. Latency of sound will be 3l
samples. We also create a temporary ring, called rt. rt will be special
in that it resides in system memory and is at least 8l in size.
Now, start playback at r0. Run emulation and write all samples into rt.
When playback reaches r1, we take the data in rt and perform a point
interpolation to fit rt into r2, regardless of the size of rt. rt can
be bigger or smaller than r2 (or l), it doesn't matter. However, it's
paramount that resampling the audio is guaranteed to be much faster
than it takes to play back one block. This should not be a problem at
all. Now, after resampling rt into r2, we clear out rt (reset the write
counter position to sample #0). During this resampling phase, and for a
while after, r1 will be playing. r1 should already contain valid sound
data, just as r0 will. Finally, advance the ring buffer by one
internally. Emulation now continues.
Samples get written into rt again, until r2 is reached. Once this
happens, rt is point interpolated to fit into r0, and we repeat.
Finally, video synchronization works by either setting a high
performance interrupt to keep testing the playback position of audio so
that the video card wait-for-vblank doesn't allow the audio playback to
pass two rings. That, or use the historically more difficult approach
of manually polling the video card to determine vblank edge, and draw
at the start of this. Lock emulation until vblank edge is reached to
ensure 60fps video output.
Unfortunately, the above will not work with libao/Linux due to it's
much more simplistic design. It automatically freezes your application
when you fill the audio buffer, so I cannot sync to video without audio
failing to work.
Also, I'll admit that point interpolation is the worst case resampling
method for audio, but it should work for the immediate time being. I
guess we'll find out how well it works when I get the code in, and then
if it's bad enough we can work on adding additional filters.
Code: |
void audio_resample_point(uint32 *output, uint32 *input, uint output_samples, uint input_samples) {
for(int i = 0; i < output_samples; i++) {
output[i] = input[(uint32)((double)input_samples / (double)output_samples * (double)i)];
}
} |
Don't laugh. If you want to do better, feel free :P
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 31, 2007 12:01 am Post subject: |
|
byuu wrote: |
but
the triple buffering on the video doesn't work, so the video shears
badly. It gets worse and worse as your refresh rate lessens. At 60hz
(the limit on my new monitor), it's almost unbearable. |
Triple buffering has always worked for me in bsnes (no video
tears/shearing). Do you mean it doesn't work anymore caused by recent
change? (sorry if I don't know what I'm talking about, just asking)
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 31, 2007 1:31 am Post subject: |
|
Regarding
Star Ocean, neviksti made a decompressed graphics patch for it to play
on a copier. I recall people saying that it ran fine with the Dejap
patch except for one place late in the game with garbled graphics
because the graphics for that part weren't decompressed right.
If that is correct, then yes it works fine on a real SNES...
Or perhaps neviksti modded the Dejap patch to fix bugs, I don't remember.
Anyone still have his Star Ocean patch?
_________________
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: Wed Jan 31, 2007 1:31 am Post subject: |
|
I
was messing around with triple buffering tonight. From what I could
see, it completely eliminated tearing @60hz and 75hz on my CRT. Chrono
Trigger was a good test, to see the pendulum breaking up with TB off
and not breaking up with TB on. The sound, of course, crackled
throughout in windowed modes. In fullscreen, TB appeared to work okay
on everything above 60hz. At 60hz, the sound crackled. Weird... can
anyone confirm these results?
You mentioned
resampling the audio before, byuu. I was just going to wait to see it
implemented. It sounds like a good tradeoff to get triple buffering
working without crackling the audio. Something tells me that it won't
be humanly possible to detect the difference. I'll try anyway, of
course  |
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Wed Jan 31, 2007 3:17 am Post subject: |
|
Aren't
headers just for copiers anyway? So why not have auto IPS patching work
for ROMs which don't have a header? A nice example would be Bahamut
Lagoon, the DeJap IPS for it (both the emulator and copier versions)
automatically patch in ZSNES only if it has a header... I don't see the
point to that.
As for the vsync and triple
buffering... that's bad to hear, it's kind of essential for a clear
view. At 1024x768 (which I think is the most common resolution used
these days) the shearing becomes horrible without vsync. I'm interested
in knowing why vsync in bsnes is broken beyond repair, can you explain
a bit?
You say you will bsnes will never have save states, what's the reason
for this? Also you didn't mention whether or not bsnes will ever have
filters such as 2xSaI.
I was reading over you wrote about having either having audio or video
sync... how is it that ZSNES seems to sync both so well? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jan 31, 2007 3:40 am Post subject: |
|
Cyrus wrote: |
You say you will bsnes will never have save states, what's the reason for this? |
There's plenty of answers to that in previous pages of this thread.
Quote: |
Also you didn't mention whether or not bsnes will ever have filters such as 2xSaI. |
Do actually prefer that filter to such filters as ScaleXx or even regular interpolation?
Quote: |
I was reading over you wrote about having either having audio or video sync... how is it that ZSNES seems to sync both so well? |
I
would imagine because ZSNES just outputs video at 60Hz and doesn't care
about the 0.09 difference. And that it just outputs sound at 32000Hz
and doesn't care about the 40Hz difference. Or something like that.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Wed Jan 31, 2007 3:46 am Post subject: |
|
Jipcy wrote: |
Cyrus wrote: |
Also you didn't mention whether or not bsnes will ever have filters such as 2xSaI. |
Do actually prefer that filter to such filters as ScaleXx or even regular interpolation?
|
Yes I use 2xSaI whenever possible. ScaleXx becomes all chunky in fullscreen resolutions and seems
to take more resources than 2xSaI so SaI would probably be better for
those with older computers. As for regular interpolation... it really
doesn't filter much at all, the only thing it could be good for is to
have a basic filter on extremely old computers.
Last edited by Cyrus on Wed Jan 31, 2007 3:51 am; edited 1 time in total
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 31, 2007 3:49 am Post subject: |
|
The answer to savestates is on the first post of this thread. A more elaborate answer is on byuu's website.
byuu wrote: |
Cooperative multithreading solves this problem beautifully. By
emulating each processor as a separate program, it is no longer
necessary to "break apart" each processor's emulation code. Instead,
you simply switch threads immediately, and only, when needed for
synchronization. This approach is faster, allows for any level of
accuracy desired, and results in much cleaner code. It is also a far
more logical way to emulate a system. You are now breaking the program
apart into separate threads, just as the SNES breaks apart the entire
system into separate processors. The only drawback to cooperative
multithreading, is that unlike a state machine, the state cannot be
saved between separate instances of the process. For
emulation, this means that savestates are virtually impossible. One
must weigh their design goals to decide if the tradeoff is worth it. Personally, I thought it was worth giving up savestates to allow for increased accuracy, and cleaner code. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 31, 2007 4:00 am Post subject: |
|
Jipcy wrote: |
I would imagine because ZSNES just outputs video at 60Hz and doesn't
care about the 0.09 difference. And that it just outputs sound at
32000Hz and doesn't care about the 40Hz difference. Or something like
that. |
Personally, I don't know how noticable a 1 frame drop in 4000 is
either, so I can't really fault zsnes for dropping these weird
remainders if they do.
Sry for the dbl post, hit the wrong button.
|
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Wed Jan 31, 2007 4:15 am Post subject: |
|
FitzRoy wrote: |
I
was messing around with triple buffering tonight. From what I could
see, it completely eliminated tearing @60hz and 75hz on my CRT. Chrono
Trigger was a good test, to see the pendulum breaking up with TB off
and not breaking up with TB on. The sound, of course, crackled
throughout in windowed modes. In fullscreen, TB appeared to work okay
on everything above 60hz. At 60hz, the sound crackled. Weird... can
anyone confirm these results? |
I tested it (though my monitor is an LCD) @60Hz and 75Hz in fullscreen
(1024x768), with and without triple buffering and in all 4 cases there
was horrible crackling.
FitzRoy wrote: |
The answer to savestates is on the first post of this thread. A more elaborate answer is on byuu's website.
byuu wrote: |
Cooperative multithreading solves this problem beautifully. By
emulating each processor as a separate program, it is no longer
necessary to "break apart" each processor's emulation code. Instead,
you simply switch threads immediately, and only, when needed for
synchronization. This approach is faster, allows for any level of
accuracy desired, and results in much cleaner code. It is also a far
more logical way to emulate a system. You are now breaking the program
apart into separate threads, just as the SNES breaks apart the entire
system into separate processors. The only drawback to cooperative
multithreading, is that unlike a state machine, the state cannot be
saved between separate instances of the process. For
emulation, this means that savestates are virtually impossible. One
must weigh their design goals to decide if the tradeoff is worth it. Personally, I thought it was worth giving up savestates to allow for increased accuracy, and cleaner code. |
|
Ah I see. Well that's as good as an answer for such a thing can get.
Edit: Typo fixed.
Last edited by Cyrus on Wed Jan 31, 2007 6:01 am; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 5:19 am Post subject: |
|
Alright, I'm in a semi-good mood.
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip9.zip |
This one uses the old win32 interface, and adds a new feature I'd like
people with sound troubles to try out. The config file now contains
"audio.latency". Don't mess with "audio.frequency", it won't do you any
good and gets overridden by the speed regulation settings for now.
The audio.latency is a precise measurement of the millisecond delay
between sound being output by a real SNES and hearing that same sound
in bsnes. It takes into account the current playback frequency, as well
as the three-ring buffering system used by bsnes' audio system.
Formula: sample_latency = CURRENT_playback_frequency / 1000 *
config_file_latency * 3 (so 32khz + 75ms latency means each ring buffer
is 800 samples long). The new formula should make latency sound better
(it's consistent now) on fast / slow emulation speed throttling
settings as well.
I also cut out the fourth ring, since it was redundant. This should
make bsnes appear ~25% more responsive to sound with the same buffer
latency. As a result, I increased the latency to 75ms (it was at ~45
before).
I'd like to know what the lowest good value is that works on 95% of
sound cards, so I can use that. I'll let people with cheap sound cards
increase their latency setting manually (eventually it will be an
option in the GUI).
NOTE: this version does nothing for triple buffering/vsync/whatever. You must disable triple buffering to try out the latency settings. This version is strictly to test audio playback support.
I also added in my audio point resampler. Good god, it sounds terrible.
Regardless of the latency setting (either really high or really low),
the pitch difference between each audio ring is extremely
noticeable. The code is there now in src/ui/audio/dsound.cpp :
AudioDS::run_videosync(), if anyone would like to take a look. I'll
hold my breath ;)
-----
Comparisons against ZSNES at this point are rather silly. Aside from
much more flexible timings, it probably has a nice audio resampler,
which I don't. If I faked CPU/SMP clock timings, I could get the SNES
spitting out 60 frames a second and 32khz audio a second. I'm not going
to do that, so I have to figure out how to resample the two. All of my
attempts at resampling video and
audio have both failed miserably to date. I really only need one of
those to work to get smooth video+audio, but both would be nice so the
user can decide what's more important to them.
I
don't care to add 2xSaI. I'm planning on redoing the filter stuff soon
to support 32-bit output for Xv, so if someone wants to add 2xSaI
support to bsnes after that, I'll add it in. Otherwise, HQ2x is
superior and Scale2x looks about the same, yet is way faster.
Regarding the IPS thing, exactly. As I said, IPS is a bad format. You
can't tell if you need to patch against a headered or unheadered ROM
unless you read the documentation that fuckheads like Cowering remove
in their ROM sets ("at least it's already prepatched"), or try patching
twice to see which one works. UPS will eliminate both of these
problems. Readmes will be included inside the patches, and UPS will
work regardless if your ROM has a header or not. It will also be
reversible. It'll be better in every regard over IPS, so I have no
reason to support IPS.
Lastly, I don't have any intention of working on fixing DeJap's patch,
regardless of where the problem is, as I have no way to run the game on
my copier. Maybe when and if the last two serious bugs (Uniracers and
Koushien 2) get fixed, I'll take a look at it then.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Jan 31, 2007 6:54 am Post subject: |
|
The
resampling method used in X-fi cards and windows Vista is near lossless
(like 99% lossless), i wonder if vista automagically fixes the
crackling sound due to the new audio engine. |
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Wed Jan 31, 2007 9:03 am Post subject: |
|
tetsuo55 wrote: |
The
resampling method used in X-fi cards and windows Vista is near lossless
(like 99% lossless), i wonder if vista automagically fixes the
crackling sound due to the new audio engine. |
I'll give this a shot sometime in the near future (since I have to format anyway) and post my results.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 31, 2007 1:23 pm Post subject: |
|
Did some testing with 0.19 wip9...
Tested with Final Fanatsy II (U) and Crono Trigger (U)
Quote: |
Box: (Sisoft sandra info)
Processor
Model : Intel(R) Pentium(R) 4 CPU 2.40GHz
Speed : 2.40GHz
Performance Rating : PR2616 (estimated)
Cores per Processor : 1 Unit(s)
Threads per Core : 1 Unit(s)
Rated Speed/FSB : 2400MHz / 4x 133MHz
Multiplier : 18/1x
Minimum/Maximum Multiplier : 4/1x / 18/1x
Generation : G8
Name : P4P-T/J (Prescott) Pentium 4E 90nm 2.8-3.8GHz 1.25-1.4V
Revision/Stepping : 4 / 1 (0)
Sound: (External PCI soundcard)
Device Name : Sound Blaster Audigy
Manufacturer : Microsoft
Version : 5.10
Product ID : 101 / 1
Specific Wave Information
Maximum Standard Sampling Bits : 16-bit
Maximum Standard Sampling Rate : 96kHz
Channels : 65535 |
bsnes settings: Full screen @ 60hz triple buffering On and Off (see
below) |||| NTSC filter scanline enable |||| hardware filter: bilinear
|||| Multiplier: 2x |||| Correct aspect ratio enable |||Resolution 640
x 480 ||||Refresh Rate 60
Frameskip = 4 (sorry, my PC 's not fast enough to get 60 with no frameskip)
<< 60 fps - (12frames) >>
Sound latency results(edit: with triplebuffering on):
Quote: |
At 100ms: No cracking ever heard.
At 50ms: Constant cracking
At 60ms: Rare almost inaudible cracking each 5 seconds or so.
Evrything above 70ms: Zero sound cracking
No screen tearing
|
edit:sigh...Just noticed your NOTE...sorry. I'll test without triplebuffering right now
Sound latency results without TripleB:
Quote: |
Same exact results as above except with tearing
At 100ms: No cracking ever heard.
At 50ms: Constant cracking
At 60ms: Rare almost inaudible cracking each 5 seconds or so.
Evrything above 70ms: Zero sound cracking
Screen Tearing
|
edit 543: Lowest good setting with zero cracking for me is 65ms. But that's pushing it I guess.
Considering I get no tearing PLUS no cracking at 75ms I consider these
results EXCELLENT... byuu, are you sure it's not something with your
PC/ drivers that's messing up? I'm telling you, these are smooth
results (granted, since I can't get 60fps with 0 frameskip regardless
if I select any filters, I don't know if the results would be the same
without frameskip)
Personally, I wouldn't really mind the occasional skip in video caused by the 60.09 Snes framerate thing.
edit: Needless to say the classically problematic Square sound efftects
sound extremely close to the real thing afaict. edit 542: Sorry, my
post is a mess...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 31, 2007 4:38 pm Post subject: |
|
Sound Card: EgoSys Juli@
CPU: Core 2 Duo E6300
XP Fully updated
Okay, so my card has a variety of its own latency "sample" settings. It
goes 48, 64, 128, 256, etc... The 256 is the default and bsnes was the
only program that had sound issues with that setting. Changing to 48
sample fixed this in older versions.
At my card's 256 setting, I can go down to 60ms without crackling. This
appears to be the reason why previous bsnes versions crackled, because
they were at 45ms. At my card's 48 setting, I can go down to 45ms
without crackling. 44ms and below crackles, I'm not kidding. I must
have been just making the cut back there!
Also, triple buffering appears to be benefiting from a higher latency.
Provided that I set my latency high enough (75ms has been sufficient
for me, personally), it no longer crackles in any scenario, windowed or
fullscreen.
Last edited by FitzRoy on Thu Feb 01, 2007 1:41 am; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 31, 2007 5:06 pm Post subject: |
|
I'll check if I can found similar latency settings with my soundcard.
edit: None that I can see. If I'm not mistaken my sound card was
plug-and-play supported by XP meaning no installation CD that came with
it were necessary.
If there's a way to change the setting in WindowsXP I don't know where is it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 5:31 pm Post subject: |
|
Also
note that you can raise frameskipping to 9 if you need to get 60fps, it
won't affect this audio test at all, but should be less taxing on your
CPU.
45ms in the old version is also an estimate.
It actually varied based on frequency setting (speed setting adjusts
frequency), and was basically "buffer = however many samples are
generated in one frame of video". So 32000 / 60 = 533.333 sample
buffer. At default speed, 32000hz, that should be:
(32000 / 1000) * (l / 3) = 533.333
32 * l / 3 = 533.333
l * 10.667 = 533.333
l = 533.333 / 10.667
l = ~50ms
The true latency was actually 25% higher than this (~62ms), but the
actual samples that could fit into one ring buffer went from 533 to 800
with a latency setting of 75 in the current WIP, which is probably why
it's working better for everyone.
So go with ~75ms as the default, then? Seems rather conservative so
far, but I guess I'll wait for a few more reports.
I can't really cut down my current ring buffer anymore than 3. I might
be able to with audio resampling, but not for unmodified audio output.
The problem is the sample data copy to the sound card happens when
emulation fills the sample buffer, not when the sound card reaches a
current point, so the sound card could very well start reading the
current ring being written to during the data transfer and cause some
horrible sound problems. As it stands, I detect the current ring being
played, and skip two forward, so that even if the current ring finishes
during the sound data transfer, I have one more ring as a buffer while
the sound transfer from emulation/RAM -> sound card occurs.
But man, I don't know how the hell I'm going to pull off audio
resampling. I've read some posts by some absolute DSP masters ( http://www.dsprelated.com/showmessage/42289/1.php ) and even they
don't have any idea how this could be done in software without
dedicated clocks (I can detect edges of the S-DSP emulated clock;
that's easy, whenever a new audio sample is generated); but the problem
is that due to emulation, it isn't consistent. The S-DSP may output
~32,040 samples a second, but that doesn't mean you get exactly one
sample every 1/32040th of a second. The reality is that it depends on a
million variables: how complex the video display is (PPU overhead),
what other applications are running and consuming CPU time, etc etc. So
the number of generated audio samples in a given timeslice varies
wildly. And then the PC sample rate clock is -somewhat- detectable by
using DirectSound::GetCurrentPosition (which calling 32,000 times a
second cuts the speed of bsnes *in half*, the hell is it doing to be so
slow?? I can reduce the calls to it by testing every n samples
generated, but that will create even greater variations between two
sample rings/blocks due to rounding). In truth, I really have no
idea how I can pull off audio resampling, aside from faking the
emulation clock speeds. But it would appear that even a miss of ~1-3
samples will cause very audible clicking and popping sounds, so my only
solution would be to fake S-DSP timing and force it to generate however
many samples I need when it really shouldn't. I believe this is what
ZSNES/SNES9x do to generate their audio, but the downside is that the
S-SMP can then poll the S-DSP registers and detect this odd behavior.
It can also distort delicate timers / sound effects.
Not sure what to do, and given how amazingly specialized my case is,
there doesn't appear to be any real documentation or examples out
there. And before anyone offers, resampling libraries do me no good.
The big problem here is that my audio stream is infinite
and asynchronous. Resampling libraries would be great if I were just
resampling a wave file on a hard disk, or if my input/output sample
rate clocks were constant, rather than variable (only the input is
variable, but still).
I don't really have anyone to ask for help on this. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 31, 2007 5:53 pm Post subject: |
|
byuu wrote: |
Also
note that you can raise frameskipping to 9 if you need to get 60fps, it
won't affect this audio test at all, but should be less taxing on your
CPU |
Yes, I think the requirements to get 60fps at 9 frameskip aren't that high...Like 1.2-1.5ghz maybe less.
Quote: |
So go with ~75ms as the default, then? Seems rather conservative so far, but I guess I'll wait for a few more reports. |
Following Fitzroy's post I guess the reason why I only get crackling
bellow 65-64ms is because my soundcard sample latency thing is set
to...64. That would make sense actually.
Yeah 75ms is a bit conservative but better to be slightly too much conservative than not enough I suppose.
Just one thing no matter what you choose for now: Please keep the
ability to manually change the latency in the .cfg file (unless you see
good reasons for not keeping it in the future, such as changes that
would render the option useless)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 6:21 pm Post subject: |
|
Ah,
I have no reason to remove the setting. I may even add it into the GUI
if enough people need to change it. I typically like to "hide" lesser
used options like this, however. Good to keep the UI as uncluttered as
possible.
Just note that the setting will have no
effect on AudioAO (Linux / FreeBSD audio output driver), as libao
doesn't let you control this (at least, not to my knowledge). |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 31, 2007 6:31 pm Post subject: |
|
byuu wrote: |
AudioAO (Linux / FreeBSD audio output driver) |
Linux, FreeBSD, Solaris, Mac OS X, OpenBSD, NetBSD, IRIX, KDE, GNOME, and possibly others 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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 6:36 pm Post subject: |
|
KDE and GNOME have their own kernels now? Why would that not surprise me? :P
Mmmm ... ls /dev
khdd0 khdd1 kmouse kkeyboard kpci kisa kdsp ...
That's neat that it works on Macs, too. Now if only it were more
powerful of a library. But, that's the problem with library
encapsulations. You have to aim for the lowest common denominator,
which usually means minimalist features. The fact that libao
automatically freezes your program when the audio buffer fills up means
that ports that use it will never be able to have 100% fluid video
output :( |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 31, 2007 6:51 pm Post subject: |
|
byuu wrote: |
KDE and GNOME have their own kernels now? Why would that not surprise me? 
|
They have their own sound systems.
So even if libao doesn't support the Kernel's system if KDE or GNOME is
there and they support it, you're still good.
byuu wrote: |
The fact that libao automatically freezes your program when the audio
buffer fills up means that ports that use it will never be able to have
100% fluid video output  |
Look at ZSNES v1.51, it when using libao can fast foward despite it
pausing, or frame skip as needed, you'll just get choppy audio.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 7:15 pm Post subject: |
|
I'd rather not read ZSNES' source code, and shall assume you're merely skipping/duplicating audio samples? :P |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 31, 2007 7:47 pm Post subject: |
|
Skip as needed, it's in src/linux/audio.c
_________________
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: Wed Jan 31, 2007 8:47 pm Post subject: |
|
I'm
curious to see more tests, now that we know frameskipping doesn't
affect results. If Snark and I have no issues with triple buffering at
the new default latency, I question if any resampling is even needed
for windows users. What is your card and results, byuu? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jan 31, 2007 9:26 pm Post subject: |
|
This
may be a silly question, but I'd like to help out by testing this on my
laptop's crappy onboard SoundMAX chip (and my PC's X-Fi if needed)..
Are there any specific games/scenes in games I should test this with? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 31, 2007 9:44 pm Post subject: |
|
Triple buffering + no audio resampling = fail, always :(
If it's working now, I have no idea why. It shouldn't. I'll try when I
get home, but even if it does work, it's by fluke and not by design.
I'll try again with D3D and manual vblank status polling. I'm adding
::tick() functions to audio and video for this purpose, so while the
audio sleeps, the video can keep polling the monitor raster position.
Though I've done this before, who knows ... maybe with the extra
latency it'll work. We can hope. |
|
lord darkstorm New Member
Joined: 31 Jan 2007
Posts: 2
Location: London
|
Posted: Wed Jan 31, 2007 10:26 pm Post subject: |
|
byuu wrote: |
Alright, I'm in a semi-good mood.
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip9.zip |
|
Just to let you, aep-emu.de are linking to this post. Thought I should
let you know as I think you once said you couldn't really afford the
bandwidth for more then a few people to download. Dunno if this is
still the case, but just to give you a heads-up.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 31, 2007 10:41 pm Post subject: |
|
Verdauga Greeneyes wrote: |
This
may be a silly question, but I'd like to help out by testing this on my
laptop's crappy onboard SoundMAX chip (and my PC's X-Fi if needed)..
Are there any specific games/scenes in games I should test this with? |
Just use Super Mario World or Chrono Trigger. Make sure you've got your
frameskip high enough to avoid crackling in the first place, then apply
TB off and on while its running. We want to know if your sound becomes
crackly with TB on.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 01, 2007 1:52 am Post subject: |
|
Quote: |
Just
to let you, aep-emu.de are linking to this post. Thought I should let
you know as I think you once said you couldn't really afford the
bandwidth for more then a few people to download. Dunno if this is
still the case, but just to give you a heads-up. |
I'm used to it, sadly. I posted about this WIP publically so I could
get the attention of the regulars here who usually give me feedback. I
doubt anyone downloading the WIP from aep-emu will be providing
feedback, but if they do, then I thank them in advance.
It would be nice if sites linking here anyway could advise that these
WIPs are intentionally "crippled" both to save bandwidth and
compilation time: eg this WIP will not run ZIP/JMA archives and lacks
full optimizations (though not as bad as it used to be since PGO is out
of the picture now).
Quote: |
We want to know if your sound becomes crackly with TB on. |
Well, you do at least, so alright :P
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 01, 2007 3:34 am Post subject: |
|
byuu wrote: |
Well, you do at least, so alright  |
TB could be working for the first time ever, and you don't care? Blasphemy!
Oh well. I can't explain why it works over here and not for the author.
If nothing else works, it wouldn't hurt to check your IRQs with
msinfo32 to see if it's sharing any. My sound cards have historically
hated not having their own IRQs.
By the way, where is that donate button? You really shouldn't have to use an SB16...
http://www.newegg.com/Product/Product.asp?Item=N82E16829120103
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Thu Feb 01, 2007 3:55 am Post subject: |
|
Q: What happens if I set the sound frequency and default speed frequency to 32040 Hz?
Does bsnes use its crappy built-in resampler in that case,or the
resampling is handled by the soundcard/windows resampler?
32040Hz works here and it doesn't sound that bad.
Your CRT monitor _can_ emulate a real NTSC refresh rate display.
Setting a custom NTSC resolution with a 60.09 Hz refresh is easy with
PowerStrip.
Having your monitor set to a refresh rate higher than 60Hz that's not a
multiple of 60 (such as 85Hz) still gives you less 'jumps' and smoother
video with triple buffering.
Latency test
---------------
45ms seems very stable _with_ triple buffering - No crackling at all
Without TB,it can go as low as 40ms
System:
AthlonXP 2400+
SB Audigy2 with kX Project drivers
XPSP2
Tested various titles of different genres in both fullscreen and windowed modes.
I had to use frameskip=1 or 2,cause this WIP is a good deal slower than the 019 release.
It would be interesting to do the same test with a WIP using 4 buffers
instead of 3 and see the difference in sound latency.
P.S. Get at least a dirt-cheap Audigy 2. SB16 is an old dinosaur 
P.P.S. Emu-France were even quicker with the news |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 01, 2007 8:45 am Post subject: |
|
If
you modify the speed throttling setting to 32040hz, then your sound
card/hardware will do the resampling. Modifying audio.frequency does
nothing for now.
kick wrote: |
Does bsnes use its crappy built-in resampler in that case,or the resampling is handled by the soundcard/windows resampler? |
It wasn't enabled in the last release. But is this better for you?
http://byuu.cinnamonpirate.com/temp/audio.txt
Point, linear, cosine and cubic filtering are now supported.
Ironically, it doesn't seem to matter which you use: bsnes is slow
enough so as to make the speed difference virtually non-existant :)
I notice that while cubic sounds the best, there's a tiny bit of
banding. It's either a bug in my filter, or just the way cubic works
(probably the former). Since they all sound virtually identical to me
anyway, I'll probably go with the cosine method as the default setting.
Cosine and cubic look extremely similar on a graph, but cubic tends to
handle sample point edges better since it has four sampling points.
I suppose I can add hermite interpolation if you want. I just didn't
want to have to add tension and bias controls into the config file.
That's getting a bit heavy for the average user.
Anyway, what I'm thinking about doing now is based on a suggestion by
blargg over at nesdev: combine buffering and resampling to sync to
video output. The idea is I start with a base resampling rate:
32040hz->32000hz or something (whatever gives a good ~60fps video
rate). Then, I monitor the buffer usage to see how many extra samples
or missed samples are occuring, and slightly adjust the resampling rate
to compensate and attempt to keep the audio buffer exactly two ring
buffers ahead at all times. It should be able to learn a best-case
value before any SNES game even begins to play audio, so it should
sound good.
tepples advises that the perceivable pitch difference for humans is
0.35 percent, so for 32khz, that's ~112 samples/second. I should be
able to sync to video and stay within that range fluctuation so that
minor pitch changes will not be perceivable.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 01, 2007 9:18 am Post subject: |
|
Does this open source near lossless sample rate conversion tool help?
its called SSRC
http://shibatch.sourceforge.net/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 01, 2007 9:31 am Post subject: |
|
Libraries don't help me. I need algorithms, heh. He doesn't even bother to say what interpolation algorithms he uses :P
You're not going to get better than cubic until you start using
window-sinc functions and all of that fun trig stuff, and that really
begins to become impractical for realtime resampling. Seriously, cubic
and cosine sound fine. I didn't notice any distortion, even in Chrono
Trigger / FF3. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Feb 01, 2007 10:28 am Post subject: |
|
lord darkstorm wrote: |
Just to let you, aep-emu.de are linking to this post. |
They're mirroring it now.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Thu Feb 01, 2007 4:18 pm Post subject: |
|
Cubic is a big improvement,but I'd go for 6-point hermite.
It's the best compromise between speed and resampling quality.It's almost as fast,but sounds better than cubic.
I won't need resampling anyway (the kX drivers resampling to 96kHz do a
better job),but most of those on-board audio and Creative card (with CT
drivers) users will need it.
I had this idea before: If I had a dual-core CPU (but no X-Fi),I
would've run bsnes on one core and connect the 32040Hz output of bsnes
via Jack [mp build] (yes,there's a Windows port too) to a very
high-quality resampler running on the second core,so I'd get very
high-quality low-latency output.
But I see this may be too difficult for the average user,so... 
Last edited by kick on Thu Feb 01, 2007 6:02 pm; edited 2 times in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 01, 2007 4:43 pm Post subject: |
|
Does resampling occur by default now? In other words, will there be some way to disable it if a user doesn't need it? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 01, 2007 6:59 pm Post subject: |
|
Was going to ask the same question actually. A way to enable/disable it (be it via the .cfg or the UI) woud be welcomed. |
|
lord darkstorm New Member
Joined: 31 Jan 2007
Posts: 2
Location: London
|
Posted: Thu Feb 01, 2007 10:35 pm Post subject: |
|
creaothceann wrote: |
lord darkstorm wrote: |
Just to let you, aep-emu.de are linking to this post. |
They're mirroring it now.
|
Joy cookies. That was nice of them.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 01, 2007 10:52 pm Post subject: |
|
Extremely
minor (possible) bug to report in 0.19wip9. In Chrono Trigger, at the
beginning of the game during the fair when the "vortex" first appears,
the lowest line where the black area is acting erratically.
Possibly caused by the ppu.hack.render_scanline default 512 position.
Or it happens on hardware... In either case, it's probably too minor to
even bother with but just in case you'd thought it might be significant.
edit: playing with the "scanline_default_position" in the cfg seem to
affect the "glitchy" bottom line behavior, so it's probably related to
that.
*disregard* |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 02, 2007 1:06 am Post subject: |
|
Quote: |
Cubic is a big improvement,but I'd go for 6-point hermite. |
I really wish I knew what you guys were hearing. The only one that
sounds different from the others is point, and that's obvious why.
Linear and cubic sound identical to me. I think I should make samples
for each filter, not label them and post them for comparison. See which
one people find best via blind audio tests against the original.
If you have an algorithm for 6-point hermite I can add it. Do note that
6-point is going to have even sharper resampled buffer edges due to the
way interpolation works. I don't currently have a good method for
pulling in previous buffer samples for the left and future buffer
samples for padding the right, but I suppose I'll have to figure
something out as soon I'll be asked to add 64-point Lagrange 3D spatial
hermite filtering to 7.1 channels :(
Quote: |
Does resampling occur by default now? In other words, will there be some way to disable it if a user doesn't need it? |
It will by default, and yes you can turn it off. But triple buffering
will no longer work without crackling audio if you turn it off.
Quote: |
Possibly caused by the ppu.hack.render_scanline default 512 position. |
Yep, I'm both afraid of the massive workload to writing a dot-based
renderer, as well as seriously not looking forward to quadripling
bsnes' system requirements ... sorry about that.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 02, 2007 1:43 am Post subject: |
|
byuu wrote: |
It will by default, and yes you can turn it off. But triple buffering
will no longer work without crackling audio if you turn it off. |
Well, hopefully that's the last sacrifice to the linux gods.
I have confidence in the resampling strategy, though. I just learned
that my sound card supports linux through something called ALSA
ice1724, whatever the hell that is. Something about modules and
compiling the kernel... Maybe one day when I'm feeling up to it, I'll
install linux on my second HD and find out why no one uses it.
|
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Fri Feb 02, 2007 3:26 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
It will by default, and yes you can turn it off. But triple buffering
will no longer work without crackling audio if you turn it off. |
Well, hopefully that's the last sacrifice to the linux gods.
I have confidence in the resampling strategy, though. I just learned
that my sound card supports linux through something called ALSA
ice1724, whatever the hell that is. Something about modules and
compiling the kernel... Maybe one day when I'm feeling up to it, I'll
install linux on my second HD and find out why no one uses it.
|
ALSA ice1724... ice1724 is the name of the sound driver for the sound system, ALSA. Linux is really quite nice; just find the right distribution for you.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 03, 2007 1:10 pm Post subject: |
|
Ok, I tried my best to add the audio synchronization method (drop video frames) yet again, and once again failed completely.
The below WIP is completely unusuable as it stands, so please don't
link to it, host it anywhere else, or even download it unless you can
help with the programming. I'm not going to be able to fix this myself
as I've tried countless times over the last two years in vain to fix it.
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip11.zip |
The included config file is important: it uses the DirectDraw renderer
instead of the D3D renderer, and has triple buffering enabled.
The relevant code is in src/ui/video/ddraw.cpp and src/ui/audio/dsound.cpp.
The most important code is below, but obviously any tests would need the above WIP to build and try out.
Code: |
void AudioDS::run(uint32 sample) {
uiVideo->tick();
data.buffer[data.buffer_pos++] = sample;
if(data.buffer_pos < latency)return;
uint32 ring_pos, pos, size;
do {
Sleep(1);
uiVideo->tick();
dsb_b->GetCurrentPosition(&pos, 0);
ring_pos = pos / data.ring_size;
} while(config::system.regulate_speed == true && ring_pos == data.ring_pos);
data.ring_pos = ring_pos;
void *output;
if(dsb_b->Lock(((data.ring_pos + 2) % 3) * data.ring_size,
data.ring_size, &output, &size, 0, 0, 0) == DS_OK) {
//Audio::resample_hermite((uint32*)output, data.buffer, latency, data.buffer_pos);
memcpy(output, data.buffer, data.ring_size);
dsb_b->Unlock(output, size, 0, 0);
}
data.buffer_pos = 0;
}
bool VideoDD::lock(uint16 *&data, uint &pitch) {
if(video_buffer[video_active]->Lock(0, &ddsd, DDLOCK_WAIT, 0) != DD_OK) return false;
video_valid[video_active] = false;
pitch = ddsd.lPitch;
data = (uint16*)ddsd.lpSurface;
return data;
}
void VideoDD::unlock() {
video_buffer[video_active]->Unlock(0);
}
void VideoDD::refresh() {
video_valid[video_active] = true;
video_active ^= 1;
tick();
}
void VideoDD::tick() {
if(video_valid[0] == false && video_valid[1] == false) return; //nothing to render
uint idx = video_valid[!video_active] == true ? !video_active : video_active;
// if(video_valid[!video_active] == false) return;
//uint idx = !video_active;
if(settings.triple_buffering == true) {
BOOL in_vblank;
lpdd7->GetVerticalBlankStatus(&in_vblank);
if(in_vblank == false) return;
//DWORD scanline;
// lpdd7->GetScanLine(&scanline);
// if(scanline < screen_height()) return;
// lpdd7->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, 0);
}
HRESULT hr;
RECT rd, rs;
snes.get_video_info(&vi);
SetRect(&rs, 0, 0, vi.width, vi.height);
POINT p = { 0, 0 };
ClientToScreen(hwnd, &p);
GetClientRect(hwnd, &rd);
OffsetRect(&rd, p.x, p.y);
hr = screen->Blt(&rd, video_buffer[idx], &rs, DDBLT_WAIT, 0);
video_valid[idx] = false;
if(hr == DDERR_SURFACELOST) {
screen->Restore();
video_buffer[0]->Restore();
video_buffer[1]->Restore();
}
} |
What I'm basically doing is:
Audio keeps a ring buffer, and waits until the temporary buffer fills
up before forcing the emulator to sleep until the audio playback
catches up. Every time an audio sample is generated, and every time the
emulator sleeps for one millisecond, it gives Video a chance to run.
Video has two backbuffers (a poor man's triple buffering, since that
doesn't work in windowed mode for DDraw). The PPU renders the entire
screen line by line, but it doesn't go from the PPU to the video card
until Video::video_lock is called. At this time, the current buffer
sets a flag to say it's contents are invalid, then it draws to the
frame, then sets a flag saying the current contents are again valid.
Finally, it calls the Video tick function to finish.
Every time the Video tick function is called from Audio (well over
32,000 times a second, so it should have good precision for detecting
vblank edges).
First, it will see if any frames have completely rendered. If not, it
will give up and return. Next, it will see if "triple buffering"
(really a vsync now, but emulates triple buffering at least) is
enabled. If so, it will return and do nothing if not in vblank.
Otherwise, or if triple buffering is disabled, it will continue. Next,
it finds the most recently rendered video frame that was valid and
blits that to the screen, and then sets that frame to invalid, so that
it is not rendered again (though it wouldn't hurt, it wastes CPU time
to blit the same image twice).
I've tried even adding in a 1ms interrupt timer to try and help with
any emulation code that might be freezing the emulator for over an
entire vblank (nothing in bsnes should be that intensive), and this did
not help either.
Basically, it's like I'm missing an unbelievable amount of frames, like
five out of six end up never getting drawn at all, so the video is so
choppy it's completely unusable. In reality, only one frame should be
dropped every 11 seconds. And when I enable the resampler, that should
change to only one frame every 66 seconds.
As a side note, I added a four-tap hermite resampler in. It sounds good
too, but I have no idea if it's better or worse than cubic.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Feb 03, 2007 1:36 pm Post subject: |
|
byuu wrote: |
The
fact that libao automatically freezes your program when the audio
buffer fills up means that ports that use it will never be able to have
100% fluid video output  |
Does it freeze the entire program, or only the responsible thread? Maybe multiple threads could help there.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Sun Feb 04, 2007 12:04 am Post subject: |
|
Found a potential bug with MKII:
Code: |
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Mortal Kombat II (U) (V1.1).sfc
Name: MORTAL KOMBAT II Company: Acclaim
Header: None Bank: HiROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 24 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.1
Checksum: Good 0x7221 CRC32: 70BB5513
MD5: A0B9BEBBC80958E36292ABD9B8FB758E
--------------------------Database--------------------------
Name: Mortal Kombat II
Country: USA Revision: 1.1
Port 1: Gamepad Port 2: Gamepad
Genre 1: Fighting Genre 2: Hand To Hand |
Character sprites glitch up in-game and in the Character Select. This happens in bsnes v0.019 and the wips.
Note: I also tested MK1, MK3 and UMK3, and they seem to be unaffected by this. Just affects MK2.
_________________

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

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 04, 2007 12:52 am Post subject: |
|
My first assumption is that it's related to the hdma bus sync stuff that messes up BoF2 German.
Will test the wip tomorrow night. This SC420 dell server I got my mom
for cheap is great for basic apps, but the castrated E7221 onboard
video can't do any direct3d and has limited directdraw. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 04, 2007 1:28 am Post subject: |
|
Clements wrote: |
Character sprites glitch up in-game and in the Character Select. This happens in bsnes v0.019 and the wips.
Note: I also tested MK1, MK3 and UMK3, and they seem to be unaffected by this. Just affects MK2. |
Confirmed here as well. Happens with 1.1 and 1.0. Doesn't affect (E)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 7:30 am Post subject: |
|
I give up. Video and audio synchronization at the same time is impossible for me to implement.
For audio synchronization, I've hooked polling vblank status as much as
possible, I had something like 40,000 vblank tests per second as well
as zero Sleep() commands. The result is that I still miss 20% of all
vblank periods entirely.
For video synchronization, it doesn't matter how close I get each
buffer, even a difference of ten samples with a hermite resampler
results in unbelievably noticeable pitch distortion. A lowpass filter
only makes the situation worse as the rounding error eventually builds
up until it overflows, resulting in an even more vastly different pitch
rate for that sample block.
Neither are possible, so I'm not going to keep wasting my time anymore.
I've removed all traces of my attempts at doing this and I will not be
trying this again.
If you want perfect audio, expect video tearing. If you want perfect
video, you'd better mute the audio. Don't like it? Use ZSNES. I don't
know how they pull it off, and I really don't care anymore. End of
topic.
As for Mortal Kombat II, the problem began between v0.018 wip14 and
wip16. The only change there was the total rewrite of IRQs.
Motherfucking hell if I'm touching IRQs again. Mortal Kombat II, fuck you.
You're staying broken forever, unless someone else fixes you (like
triple buffering, hahahahahah). Let's not kid ourselves: even if I did
fix this bug, it would just break three other games, guaranteed. Why
bother anymore?
I no longer have the motivation or
passion to continue to put myself through this physical and emotional
pain to work on these issues in bsnes anymore. bsnes has become nothing
but a headache for the last year now. Either someone else can join up
with me to work on this stuff, or we can consider v0.018 the final
version of bsnes for public use, and I'll take development in a
personal, private direction once again.
As of now, I'm refactoring and cleaning up the code. I've been chasing
down so many bugs and doing so many things at once to make everyone
happy that my code is now almost a complete trainwreck. I scrapped the
D3D-specific scanline renderer and will be rewriting a software
renderer for that purpose. I also removed the D3D-vertex-specific pause
gamma adjustment, video profiles, D3D-specific screenshot capturing,
and DD/D3D fullscreen support (I'll still support pseudo-fullscreen
mode in the future).
I'm going to continue cleaning up and refactoring my codebase. Filters
are going to be moved out of the core of the emulator, along with other
things that don't belong there. I'll continue to scrap wanton features
that are better suited for ZSNES and clutter up my code.
Sorry everyone, I'm going to make working on this emulator fun again,
even if it kills my userbase and my original project goals. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Feb 04, 2007 7:39 am Post subject: |
|
byuu wrote: |
I give up. Video and audio synchronization at the same time is impossible for me to implement. |
Sorry to hear that.
Quote: |
As
for Mortal Kombat II, the problem began between v0.018 wip14 and wip16.
The only change there was the total rewrite of IRQs. Motherfucking hell if I'm touching IRQs again. Mortal Kombat II, fuck you.
You're staying broken forever, unless someone else fixes you (like
triple buffering, hahahahahah). Let's not kid ourselves: even if I did
fix this bug, it would just break three other games, guaranteed. Why
bother anymore? |
I've noticed MKII is uber sensitive to IRQ changes when pf made changed
to the core recently. I can't really blame you for that.
Quote: |
I
no longer have the motivation or passion to continue to put myself
through this physical and emotional pain to work on these issues in
bsnes anymore. bsnes has become nothing but a headache for the last
year now. Either someone else can join up with me to work on this
stuff, or we can consider v0.018 the final version of bsnes for public
use, and I'll take development in a personal, private direction once
again. |
Take a deep breath and exhale. Lots of things are stressful.. you
should never make your hobby one of those things.
Quote: |
I'm
going to continue cleaning up and refactoring my codebase. Filters are
going to be moved out of the core of the emulator, along with other
things that don't belong there. I'll continue to scrap wanton features
that are better suited for ZSNES and clutter up my code. |
Sorry to hear this as well.
Quote: |
Sorry
everyone, I'm going to make working on this emulator fun again, even if
it kills my userbase and my original project goals. |
That's a tough pill to swallow man.
_________________
FF4 research never ends for me.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 04, 2007 7:58 am Post subject: |
|
byuu wrote: |
Neither are possible, so I'm not going to keep wasting my time anymore.
I've removed all traces of my attempts at doing this and I will not be
trying this again.
If you want perfect audio, expect video tearing. If you want perfect video, you'd better mute the audio. |
As was said before, I do get scratch-free audio + plus no tearing
(provided the latency is set to something above 64ms), as do Fitzroy so
unless I simply don't understand what is the real problematic issue
here, I don't actually see the need to rewrote those aspects of bsnes.
If it work for most people (whether by design or accident is not really
that important I would say) then isn't that good enough?
Quote: |
I
no longer have the motivation or passion to continue to put myself
through this physical and emotional pain to work on these issues in
bsnes anymore. bsnes has become nothing but a headache for the last
year now. Either someone else can join up with me to work on this
stuff, or we can consider v0.018 the final version of bsnes for public
use, and I'll take development in a personal, private direction once
again.
As of now, I'm refactoring and
cleaning up the code. I've been chasing down so many bugs and doing so
many things at once to make everyone happy that my code is now almost a
complete trainwreck. I scrapped the D3D-specific scanline renderer and
will be rewriting a software renderer for that purpose. I also removed
the D3D-vertex-specific pause gamma adjustment, video profiles,
D3D-specific screenshot capturing, and DD/D3D fullscreen support (I'll
still support pseudo-fullscreen mode in the future).
I'm going to continue cleaning up and refactoring my codebase. Filters
are going to be moved out of the core of the emulator, along with other
things that don't belong there. I'll continue to scrap wanton features
that are better suited for ZSNES and clutter up my code.
Sorry everyone, I'm going to make working on this emulator fun again,
even if it kills my userbase and my original project goals. |
Kind of a downer but if you really think this is the best or only way
to keep bsnes alive and for you to have the motivation to keep working
on it then I won't complain.
Fwiw, I personally consider (from a user pov) the latest stable
0.019wip9 version to be by far the most usable Snes emulator around.
The only thing that's not perfect for me is I have to set the frameskip
to 2 or 3 to achieve 60fps...but that's more an issue of my CPU than
the program. Other than that, aside from special chips games it does
play 99.xx% of games wonderfully.
Of course, I'd still love to see (regardless of speed) a dot-based
renderer and any improvement to the core Snes emulation in the future.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 8:38 am Post subject: |
|
If
you're using frameskipping, then you aren't getting clear scrolling
video. Anyway, if people out there can manage to rig bsnes to get
perfect video and audio, then that's great. But it doesn't work on most
PCs, so there's no sense stating I support something I can't.
I really don't have the motivation right now to write a dot-based PPU
renderer. Maybe that will change in the future, maybe not. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 04, 2007 9:00 am Post subject: |
|
byuu wrote: |
If you're using frameskipping, then you aren't getting clear scrolling video. |
Allright, so anyone with a PC fast enough, I'd be curious to hear the results.
edit: Still, I doubt the results would vary for me if I had a 3.2ghz
dual core and thus able to achieve 60fps with 0fskp.
Anyhow, I don't want to come off as annoying, just saying what has been my experience regarding this.
Quote: |
Anyway,
if people out there can manage to rig bsnes to get perfect video and
audio, then that's great. But it doesn't work on most PCs, so there's
no sense stating I support something I can't.
I really don't have the motivation right now to write a dot-based PPU
renderer. Maybe that will change in the future, maybe not. |
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sun Feb 04, 2007 9:23 am Post subject: |
|
You
shoudn't use triple buffering and poll for vblank. You should use a
call that waits for vblank. Triple buffering is not meant to be used as
a way of syncronizing to the refresh rate.
This is pretty much how I do it:
Code: |
void BSNES::resampleAudio(uint16_t *outBuffer, uint numberOfSamplesToResampleTo); |
Code: |
for (;;) {
bsnes.emulateOneFrame(); //Fills internal buffer with non-resampled audio
waitForVblank();
swapBuffers();
bsnes.resampleAudio(outBuffer, numberOfSamplesPlayedBackSinceLastFrame);
} |
If you use triple buffering you'll get no tearing, but some frames will last longer than other, making it choppy.
This example uses triple buffering, or no vblank blitting at all since triple buffering is transparent:
Code: |
for (;;) {
bsnes.emulateOneFrame(); //Fills internal buffer with non-resampled audio
blit();
waitAsLongAsIdLikeOneFrameToLast();
bsnes.resampleAudio(outBuffer, numberOfSamplesPlayedBackSinceLastFrame);
} |
If you only have access to fill the sound system's output buffer in one
big go, you should preferably use a callback function in a different
thread that fills up from a large intermediate buffer that you fill
samples into each frame. The number of samples that you fill the
intermediate buffer with, needs to be dynamically determined based on
how many samples are left in it after the sound system has taken it's
bite out of it. This can be quite tricky.
EDITed for saner placement of resample-calls
Last edited by sinamas on Sun Feb 04, 2007 10:13 am; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 9:54 am Post subject: |
|
I
shouldn't poll for vblank, period. I can't possibly poll frequently
enough to reliably detect vblank edges no matter how much I try. It's
not possible.
As I've stated above at least twice,
I've already tried resampling the audio based on how many samples were
generated during one video frame. It sounds absolutely horrible because
the number of samples generated per frame varies wildly, and the
constant resampling to different amounts causes horrible pitch
distortion. Your first example won't work for this reason.
As for your second example, if triple buffering is locking (eg nothing
happens and your program freezes until vblank), then the audio buffers
will empty while the video API freezes my app waiting on vblank. If I
manage to buffer audio enough to avoid that, it still won't matter
anyway, as once again, I cannot simply resample audio from arbitrary
amounts every video frame. It simply won't work.
I could solve this problem if PCs supported a feature twenty-year-old
Nintendos supported: NMI. Simply tell DD/D3D to call a function when
vblank is first hit, and my problems would be solved. But then, we
can't expect modern computers to have caught up to the functionality of
the NES, can we? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 04, 2007 10:04 am Post subject: |
|
byuu wrote: |
I could solve this problem if PCs supported a feature twenty-year-old
Nintendos supported: NMI. Simply tell DD/D3D to call a function when
vblank is first hit, and my problems would be solved. But then, we
can't expect modern computers to have caught up to the functionality of
the NES, can we? |
LOL
|
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sun Feb 04, 2007 10:08 am Post subject: |
|
Triple
buffering should never lock, that's the whole point of triple
buffering. As long as your audio buffers are large enough they
shouldn't empty while waiting for vblank anyway (it's only like 17 ms).
The number of samples generated internally by bsnes shouldn't vary,
since it should emulate the same number of cycles each frame. The
number of samples played back by the sound system shouldn't vary much,
since each frame should last as long as the previous one. My previous
placement of the resample calls wasn't very well thought through, and
I've edited my previous post for saner placement. Anyway this works for
me, so it should be possible to do for bsnes too afaics.
If the sound system is unable to report accurate playback position (as
you said the number of samples varies too much), you could use the big
intermediate buffer strategy anyway, but it can get really tricky to
calculate how many samples to output each frame.
Last edited by sinamas on Sun Feb 04, 2007 10:27 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 10:26 am Post subject: |
|
Quote: |
Triple buffering should never lock, that's the whole point of triple buffering. |
You'd think, wouldn't you? Unfortunately, that's not the case. Using
D3D with triple buffering (two backbuffers) still causes lockng when
calling Present(). DirectDraw does the same thing and locks with
Flip(), and that is further limited to only working in fullscreen mode.
Quote: |
The
number of samples generated internally by bsnes shouldn't vary, since
it should emulate the same number of cycles each frame. The number of
samples played back by the sound system shouldn't vary much, since each
frame should last as long as the previous one. |
They do vary. Greatly, in fact. It's due to my emulation model. I don't
run the CPU and SMP in perfect parity. If the CPU doesn't read from the
SMP, then there's no reason to switch cooperative threads and run the
SMP. I guess I can take a rather large speed hit to keep the two more
in parity and see if it helps. But I doubt it. Again, even tiny
resampling amounts (~10 samples/25ms buffer) cause serious problems for
audio playback.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sun Feb 04, 2007 10:29 am Post subject: |
|
Is
there any reason why you can't just force a sync at the end of each
frame? If your emulator doesn't generate the same number of samples
internally each frame, then it sounds like we're pretty screwed indeed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 10:41 am Post subject: |
|
For
one, emulating up to 1/8th of a second on either the CPU or the SMP is
quite processor-intensive, and easily enough to miss any narrow cutoff
windows I have for video or audio buffering.
You
made a good point, I had forgotten about my libco optimization before.
In that case, I will try disabling the out-of-order execution entirely
(and take the ~15% speed hit) and try one last time to see if it helps
any. Hopefully I can still get 60fps on my PC to even test it :(
That will give us a much closer number for samples/frame generated, but
it still won't be perfect. Hopefully we can get it within the magic 1-5
samples/difference per buffer, so that audio resampling won't be
detectable. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sun Feb 04, 2007 10:49 am Post subject: |
|
I'm
possibly not getting something here, but a context switch (or hundred)
each 16 ms shouldn't really cost you much in itself. I mean, you'll
have to do the emulation of it sooner or later anyway, and if the
context switch isn't the overhead, then what is? If anything syncing
cothreads each frame should make the actual system time used for
emulating each frame _more_ consistent, since you're never bulking up a
large amount of stuff that needs to be done in some other frame.
As a side note, the only way to get perfectly smooth video is to sync
completely to the refresh rate. This either means approximating the
speed of the original platform, or resampling the video output to the
refresh rate (doing weighed blending between frames, causing blurring
in motion and latency depending on the number of frames you blend
between). If you don't sync to the refresh rate, you're basically doing
nearest point interpolation. If directx blocks when using triple
buffering then directx is broken. It should not be necessary to poll
for vblank. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun Feb 04, 2007 5:11 pm Post subject: |
|
byuu wrote: |
Sorry
everyone, I'm going to make working on this emulator fun again, even if
it kills my userbase and my original project goals. |
Sounds good to me. Anything that keeps you working on bsnes makes me happy.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 04, 2007 11:35 pm Post subject: |
|
sinamas wrote: |
I'm possibly not getting something here, but a context switch (or hundred) each 16 ms shouldn't really cost you much in itself. |
I average about 20,000 context switches per second. That number would
rise to 200,000 or so per second without my speedup trick.
Quote: |
As
a side note, the only way to get perfectly smooth video is to sync
completely to the refresh rate. This either means approximating the
speed of the original platform, or resampling the video output to the
refresh rate (doing weighed blending between frames, causing blurring
in motion and latency depending on the number of frames you blend
between). |
I'd basically be doing the former. I don't mind always running at 60hz
rather than 60.09hz. Nobody can tell the difference. As it stands,
syncing to audio at 32000hz instead of 32040hz already slows down
emulation all the same anyway.
Quote: |
Sounds good to me. Anything that keeps you working on bsnes makes me happy. |
Thanks. Who knows, maybe I'll get over this hangup if I give myself enough time off.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 05, 2007 2:06 am Post subject: |
|
Snark wrote: |
byuu wrote: |
If you're using frameskipping, then you aren't getting clear scrolling video. |
Allright, so anyone with a PC fast enough, I'd be curious to hear the results.
edit: Still, I doubt the results would vary for me if I had a 3.2ghz
dual core and thus able to achieve 60fps with 0fskp.
Anyhow, I don't want to come off as annoying, just saying what has been my experience regarding this.
Quote: |
Anyway,
if people out there can manage to rig bsnes to get perfect video and
audio, then that's great. But it doesn't work on most PCs, so there's
no sense stating I support something I can't.
I really don't have the motivation right now to write a dot-based PPU
renderer. Maybe that will change in the future, maybe not. |
|
Byuu, I have the slowest core 2 duo and I can tell you that WIP9 worked
wonders without frameskipping. It worked for 3/4 of the users who
tested with it. From that information alone, it probably DOES work on
most PCs. You even said it yourself that frameskipping has nothing to
do with whether the TB code is working or not. I have to assume that
that is the best implementation to go with. Sure, it won't work on
linux, but neither did anything else, and that's only 3% of users. The
way I see it, if a linux user is complaining about something like TB
when they are lucky just to have a port, then that's a little strange
to me. Unless you're converting to linux yourself, then I get it.
There's no question that an author should be able to enjoy his own
emulator. However, it wouldn't make sense if you're blaming good code
for something that is the fault of your sound drivers.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 05, 2007 3:29 am Post subject: |
|
Ok, I had to track down a truly evil bug to disable the out-of-order execution speedup.
The CPU, during reset(), was calling add_clocks(186) to sync to the
delay seen on real systems when resetting the console. Without the
out-of-order execution, this caused the SMP to start running before
it's reset() function was called for the first time. Because
SMP::reset() was not called, the SMP clock ratio was never set, and so
the SMP attempted to execute an opcode to catch up to the CPU, and then
continually executed when all clock cycle counts were zero, so the
emulator froze hard.
I'm now rethinking how to perform CPU reset timing emulation, but in the meantime I have a quick workaround.
Oh, and I hereby declare 4576849921 as "byuu's constant". Have fun figuring out the meaning.
Disabling out-of-order execution results in a frameloss from 82.5fps to
77.5fps, or ~6%, due to having to call libco::co_switch hundreds of
thousands of extra times per second. Not as bad as I was thinking. This
is all overhead of libco, which will be worse on 64-bit processors,
especially on win64 with Microsoft's awful ABI.
It didn't help much anyway. With an audio buffer of 750ms, combined
with hermite resampling, I was able to synchronize to the video
refresh, getting the following (generated samples) -> (needed
samples) ratio:
8000 -> 8000
7952 -> 8000
7984 -> 8000
7968 -> 8000
7968 -> 8000
7952 -> 8000
That's with a 16-sample lowpass filter. The pitch difference is
virtually inaudible to my ears. However, that 750ms latency is
terrible. Anything lower and the sound becomes very noticeably
distorted.
To give you an idea, you can have Link swing his sword twice, and then
stop. And only after you stop will you hear the first swing.
Oh well. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Mon Feb 05, 2007 7:34 am Post subject: |
|
byuu wrote: |
sinamas wrote: |
I'm possibly not getting something here, but a context switch (or hundred) each 16 ms shouldn't really cost you much in itself. |
I average about 20,000 context switches per second. That number would
rise to 200,000 or so per second without my speedup trick.
|
Which is why I'm asking why you can't just keep using your speed trick,
but force a sync between cothreads at the end of every frame, before
resampling (meaning every 16/17 ms). If you reread my last post, my
argument should be pretty clear. Many emulators are coded in a way that
only syncs parts when needed. I don't see what's so different about
bsnes that you can't just sync up before resampling like I do.
byuu wrote: |
It
didn't help much anyway. With an audio buffer of 750ms, combined with
hermite resampling, I was able to synchronize to the video refresh,
getting the following (generated samples) -> (needed samples) ratio:
8000 -> 8000
7952 -> 8000
7984 -> 8000
7968 -> 8000
7968 -> 8000
7952 -> 8000
That's with a 16-sample lowpass filter. The pitch difference is
virtually inaudible to my ears. However, that 750ms latency is
terrible. Anything lower and the sound becomes very noticeably
distorted. |
Are you buffering up 750 ms worth of samples internally to get more
uniform resampling ratios? Could this be solved by forcing a sync
before resampling? I'd think the number of samples between frames
shouldn't have to vary by more than one or two (because of an uneven
ratio with the frame rate). If the 750 ms buffer is the external
buffer, then I don't see why that helps anything.
byuu wrote: |
Oh, and I hereby declare 4576849921 as "byuu's constant". |
A 33-bit number, ouch!
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 05, 2007 11:00 pm Post subject: |
|
Snark wrote: |
Clements wrote: |
Character sprites glitch up in-game and in the Character Select. This
happens in bsnes v0.019 and the wips.
Note: I also tested MK1, MK3 and UMK3, and they seem to be unaffected by this. Just affects MK2. |
Confirmed here as well. Happens with 1.1 and 1.0. Doesn't affect (E)
|
Just wanted to note that this does affect (E) as well. It does for me, at least.
We had a good list of IRQ sensitive games, too. Apparently the SNES IRQ system is insane.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Feb 06, 2007 12:39 am Post subject: |
|
do
whatever you need to do byuu, you're always learning more and that is
important. I'm sure as it becomes more common and affordable to have
faster processors, emulators will become more accurate. and all you
emuwizards will know far more by then.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 06, 2007 2:41 am Post subject: |
|
FitzRoy wrote: |
Snark wrote: |
Clements wrote: |
Character sprites glitch up in-game and in the Character Select. This
happens in bsnes v0.019 and the wips.
Note: I also tested MK1, MK3 and UMK3, and they seem to be unaffected by this. Just affects MK2. |
Confirmed here as well. Happens with 1.1 and 1.0. Doesn't affect (E)
|
Just wanted to note that this does affect (E) as well. It does for me, at least.
|
Weird. I've double tested...no character' sprite glitch like the one in the (U) version. I'll post the NSRT info:
NSRT v3.3 - Nach's SNES ROM Tools
Quote: |
---------------------Internal ROM Info----------------------
File: Mortal Kombat II (E) (V1.0).smc
Name: MORTAL KOMBAT II Company: Acclaim
Header: None Bank: HiROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 24 Mb
Country: Euro/Asia/Oceania Video: PAL
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x8989 CRC32: 1CC0C6EF
MD5: CEC1C21CDCE0579D18B78A5CAF517032
--------------------------Database--------------------------
Name: Mortal Kombat II
Country: Europe Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Fighting Genre 2: Hand To Hand
|
Tested with 0.019.09 bsnes
Quote: |
We had a good list of IRQ sensitive games, too. Apparently the SNES IRQ system is insane.  |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 06, 2007 2:54 am Post subject: |
|
byuu wrote: |
I'd basically be doing the former. I don't mind always running at 60hz rather than 60.09hz. |
Does this change the internal framerate of the emulation? Or does this
only change the external video output and doesn't affect the internal
workings of the emulation (an analogy would be an HQX filter running on
top of emulation)?
Bluntly put: could this be technically considered a hack?
Btw it IS possible to run a monitor at 60.09 using Powerstrip, but I
think you mentionned that the actual framerate of the Snes actually may
varies during gameplay.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 06, 2007 3:14 am Post subject: |
|
It
may not bug out as bad on the character select screen, but you need to
go further than that. The gfx corrupts during gameplay just like the
other regions.
Last edited by FitzRoy on Tue Feb 06, 2007 3:37 am; edited 2 times in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 06, 2007 3:33 am Post subject: |
|
FitzRoy wrote: |
It
may not bug out as bad on the character select screen, but you need to
go further than that. The gfx corrupts during gameplay just like the
other regions. |
Well, I tested during gameplay too (just for half a minute though) and
didn't see any garbage/corrupted gfx. I'll play longer to see if I can
see anything.
edit: My bad...it does crap out... Just seem less severe than (U).
Guess it depends of the stage and character because it really didn't
when I first tested (or it's more or less pseudo-random)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 12:39 am Post subject: |
|
Thank
you again DMV27 for looking into this in the past for me. I'm sorry I
took so long to get to it, but your notes were (and are) very helpful
to me.
DMV27 wrote: |
When
(Koushien 2) wants to change the echo buffer address, it first sets EDL
to zero, then changes ESA, and finally it disables echo writes.
However, sometimes an echo write will happen between ESA and FLG, which
can be seen by the change in ad -> ad + 4. The write can happen
anywhere between 0xF800 and 0x1800. Either the game requires insane
sub-sample accurate timing, or one of those register writes sets
"echo_index = 0" and possibly sets "echo_target = echo_size". |
Since I'm not touching Mortal Kombat II with a ten foot pole, I figured
I'd look at this issue again. Perhaps even learn some S-DSP stuff this
time.
So ok, anomie believes that (most likely) writes to EDL are cached. The
echo buffer continues to increment until the value wraps. At that time,
the echo buffer size is reloaded from EDL.
TRAC, however, believes that EDL's write takes effect immediately. In
light of observations with Koushien 2, I agree with his synopsis that
simplicity is key. Caching a value and reloading from that would
complicate the S-DSP design slightly, and doesn't really do a whole lot
of good. Given no definitive tests have been done, nor can be at this
time due to there being nobody left in the scene who can do these sorts
of tests ... I'm going to go with TRAC's opinion.
Myself and TRAC continue to have the same problem with Koushien 2
crashing though, of course. But now, the matter becomes much simpler.
Koushien 2 sets EDL to zero (meaning the echo buffer becomes only
1-sample long), and then updates ESA to the near the of SPCRAM. Lastly,
it disables FLG. Now the problem is, a sample sometimes gets generated
here. With anomie's approach, the sample would be written, and indeed
samples would continue to be written, well past where the programmer
wanted them to go. In fact, it keeps going until the echo buffer wraps,
which is well past wrapping SPCRAM and writing into program code at the
start of SPCRAM. TRAC's method does the same, but only one time. After
the one write, it would recover. But one write into critical code is
quite bad indeed. And sure enough, Koushien 2 can crash in SNEeSe as
well.
DMV27's idea is that writes to either EDL or ESA reset the write index
to zero. I don't believe this would be desirable from a hardware
standpoint, as this would mess with the FIR filter which reads from the
echo buffer, distorting the pitch.
So then, TRAC and I believe that the range test for echo index >=
EDL *512*4 happens before writing into SPCRAM. Hence, you set EDL to
zero, so the very next time a sample gets generated, it will see that
echi index >= EDL, and wrap it to zero. The result is that the echo
writes are bound to ESA<<8, and nothing else, immediately after
EDL is set to zero.
This could very well be incorrect from a hardware standpoint, but
without being able to test it, we'll just have to go with it and see
what happens. If other games break, we can look at how they work and
see why. Gain more info from them and come up with a fix that gets all
games working again. Kind of sad, but what can you do?
So, I've implemented this, and indeed Koushien 2 now plays fine without
crashing. No idea about Toy Story, probably the same since that's a
different issue anyway. I refuse to play the game to find out. I'll try
and post a build with a fixed Koushien 2 tonight or tomorrow if
possible.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Feb 09, 2007 4:40 am Post subject: |
|
I just tested Koushien 2 and Toy Story wip 0.019w9 and saw the bugs myself.
This might be a naive question but are we sure the bugs don't appear on
hardware? The Toy Story lingering sound during pause doesn't seem that
severe for a commercial game. Koushien 2 randomly freezing would be of
course critical...then again, I'm sure there are really obscure
commercial games that have been terribly coded to the point of
unplayability.
I know they don't happen in Zsnes, but we can't be sure Zsnes is
correct either. If I'm not mistaken Fitzroy has access to a copier...it
would be nice to confirm if they happen on hardware or not. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 6:48 am Post subject: |
|
I
was mistaken. Moving the pitch wrap to test before writing seriously
flattens the echo effects in pretty much every game. In that case,
let's go with DMV27's idea. EDL now clears echo_index. I also renamed
echo_target to echo_length, and removed echo_size, since it can be
calculated from EDL when needed. Koushien 2 is now playable.
Unbelievably tough game, that.
Since finally
fixing that awful baseball game left me in a good mood, and since I'm
apparently a masochist, I took a quick look at MK2.
Code: |
* IRQ @ <215, 46>
0086b1 rep #$30 A:0000 X:0000 Y:0016 S:1ff5 D:1800 DB:7e nvmxdIzC V:215 H: 106
0086b3 pha A:0000 X:0000 Y:0016 S:1ff5 D:1800 DB:7e nvmxdIzC V:215 H: 128
0086b4 phx A:0000 X:0000 Y:0016 S:1ff3 D:1800 DB:7e nvmxdIzC V:215 H: 158
0086b5 phy A:0000 X:0000 Y:0016 S:1ff1 D:1800 DB:7e nvmxdIzC V:215 H: 188
0086b6 phd A:0000 X:0000 Y:0016 S:1fef D:1800 DB:7e nvmxdIzC V:215 H: 218
0086b7 phb A:0000 X:0000 Y:0016 S:1fed D:1800 DB:7e nvmxdIzC V:215 H: 248
0086b8 jml $8086bc [$8086bc] A:0000 X:0000 Y:0016 S:1fec D:1800 DB:7e nvmxdIzC V:215 H: 270
8086bc pea $8080 [$7e8080] A:0000 X:0000 Y:0016 S:1fec D:1800 DB:7e nvmxdIzC V:215 H: 302
8086bf plb A:0000 X:0000 Y:0016 S:1fea D:1800 DB:7e nvmxdIzC V:215 H: 336
8086c0 plb A:0000 X:0000 Y:0016 S:1feb D:1800 DB:80 NvmxdIzC V:215 H: 362
8086c1 lda #$1700 A:0000 X:0000 Y:0016 S:1fec D:1800 DB:80 NvmxdIzC V:215 H: 388
8086c4 tcd A:1700 X:0000 Y:0016 S:1fec D:1800 DB:80 nvmxdIzC V:215 H: 406
8086c5 ldx $1a00 [$801a00] A:1700 X:0000 Y:0016 S:1fec D:1700 DB:80 nvmxdIzC V:215 H: 418
8086c8 jsr ($86d7,x) [$8086d7] A:1700 X:0000 Y:0016 S:1fec D:1700 DB:80 nvmxdIZC V:215 H: 452
8086da lda #$0118 A:1700 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIZC V:215 H: 504
8086dd sta $4207 [$804207] A:0118 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:215 H: 522
8086e0 sep #$20 A:0118 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:215 H: 592
8086e2 lda #$11 A:0118 X:0000 Y:0016 S:1fea D:1700 DB:80 nvMxdIzC V:215 H: 610
8086e4 sta $4200 [$804200] A:0111 X:0000 Y:0016 S:1fea D:1700 DB:80 nvMxdIzC V:215 H: 622
8086e7 lda $4211 [$804211] A:0111 X:0000 Y:0016 S:1fea D:1700 DB:80 nvMxdIzC V:215 H: 646
8086ea wai A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H: 670
8086eb stz $420c [$80420c] A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H:1144
8086ee lda #$80 A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H:1168
8086f0 sta $2100 [$802100] A:0180 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H:1180
8086f3 lda $4211 [$804211] A:0180 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H:1204
8086f6 rep #$20 A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvMxdIzC V:215 H:1228
8086f8 stz $1a00 [$801a00] A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvmxdIzC V:215 H:1246
8086fb lda #$00d7 A:01c2 X:0000 Y:0016 S:1fea D:1700 DB:80 NvmxdIzC V:215 H:1280
8086fe sta $4209 [$804209] A:00d7 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:215 H:1298
808701 lda #$0021 A:00d7 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:215 H:1328
808704 sta $4200 [$804200] A:0021 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:215 H:1346
808707 cli A:0021 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdIzC V:216 H: 12
808708 lda $24 [$001724] A:0021 X:0000 Y:0016 S:1fea D:1700 DB:80 nvmxdizC V:216 H: 24
* IRQ @ <216, 52>
0086b1 rep #$30 A:0000 X:0000 Y:0016 S:1fe6 D:1700 DB:80 nvmxdIZC V:216 H: 112 |
Extra interrupt, fun! Trying to toggle on VIRQs right at the end of the
scanline, causing another IRQ to fire on line 216 when it should not.
Copied the IRQ into a demo ROM, tested it on hardware. bsnes is
behaving the same way as hardware, just slightly off somewhere.
How slightly off? By _four clock cycles_. One pixel. Yes, if MK2's interrupt handler was one quarter of one opcode faster, the game would break totally on real hardware.
Don't believe me? See where the game is setting the dot position above?
(lda #$0118) Go there in the ROM and change that to lda #$0119. For the
less technically skilled, hex edit a headerless MK2 ROM and go to hex
offset 0x86db and change 0x18 to 0x19. The game now works just fine.
Set that to 0x17 (or maybe 0x16 in case the wai wraps another
iteration) and watch it break on real hardware just like in bsnes.
This is getting psychotic. For four clock cycles to completely break a game brings on a whole new world
of shitty programming. It's frightening that code like this even
exists. How do other emulators do it? As usual, they don't have proper
IRQ handling and their timing is off, so the game plays when it really
shouldn't.
Deathlike wasn't kidding. This game is absolutely sick. And no, I don't know how to fix it.
EDIT: fun log.
http://byuu.cinnamonpirate.com/temp/irq.txt
Last edited by byuu on Fri Feb 09, 2007 7:06 am; edited 1 time in total
|
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Fri Feb 09, 2007 7:02 am Post subject: |
|
byuu wrote: |
I
shouldn't poll for vblank, period. I can't possibly poll frequently
enough to reliably detect vblank edges no matter how much I try. It's
not possible.
As I've stated above at least
twice, I've already tried resampling the audio based on how many
samples were generated during one video frame. It sounds absolutely
horrible because the number of samples generated per frame varies
wildly, and the constant resampling to different amounts causes
horrible pitch distortion. Your first example won't work for this
reason.
As for your second example, if triple buffering is locking (eg nothing
happens and your program freezes until vblank), then the audio buffers
will empty while the video API freezes my app waiting on vblank. If I
manage to buffer audio enough to avoid that, it still won't matter
anyway, as once again, I cannot simply resample audio from arbitrary
amounts every video frame. It simply won't work.
I could solve this problem if PCs supported a feature twenty-year-old
Nintendos supported: NMI. Simply tell DD/D3D to call a function when
vblank is first hit, and my problems would be solved. But then, we
can't expect modern computers to have caught up to the functionality of
the NES, can we? |
PCs don't support non-maskable interrupts? You'll have to forgive my
utter lack of knowledge but can you explain why that is?
Last edited by Cyrus on Fri Feb 09, 2007 7:03 am; edited 1 time in total
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Feb 09, 2007 7:03 am Post subject: |
|
byuu wrote: |
Deathlike wasn't kidding. This game is absolutely sick. And no, I don't know how to fix it. |
use hacks /jokes
_________________
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.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Feb 09, 2007 7:48 am Post subject: |
|
Snark wrote: |
I just tested Koushien 2 and Toy Story wip 0.019w9 and saw the bugs myself.
This might be a naive question but are we sure the bugs don't appear on
hardware? The Toy Story lingering sound during pause doesn't seem that
severe for a commercial game. Koushien 2 randomly freezing would be of
course critical...then again, I'm sure there are really obscure
commercial games that have been terribly coded to the point of
unplayability.
I know they don't happen in Zsnes, but we can't be sure Zsnes is
correct either. If I'm not mistaken Fitzroy has access to a copier...it
would be nice to confirm if they happen on hardware or not. |
snark, these games where tested on 3 different copiers to confirm the
problems do not happen on hardware. We try to check every bug on
hardware because bsnes is so accurate most of the bugs that we see
happen on hardware too.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 8:05 am Post subject: |
|
<post removed, see next page for updated post>
Last edited by byuu on Fri Feb 09, 2007 8:51 am; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 09, 2007 8:19 am Post subject: |
|
Snark wrote: |
I
know they don't happen in Zsnes, but we can't be sure Zsnes is correct
either. If I'm not mistaken Fitzroy has access to a copier...it would
be nice to confirm if they happen on hardware or not. |
I have confirmed Toy Story's bug on hardware. I could dig up my post from this thread, but... nah.
byuu wrote: |
How slightly off? By _four clock cycles_. One pixel. |
That is insane. At least the other fixes make sense again. Pretty good news if you look at it that way.
Big props to you, TRAC, and DMV27 for Koushien. That makes Toy Story
the last known mystery bug, if it still exists.
EDIT: Yep, still there as you expected.
Last edited by FitzRoy on Fri Feb 09, 2007 8:56 am; edited 2 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 8:27 am Post subject: |
|
Please
hold up on testing wip13. TRAC found the bug with my echo buffer
adjustment. I'm fixing it now, and will upload wip13 again. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 09, 2007 8:33 am Post subject: |
|
My config options were not saving as well in that wip, but it's not a big deal. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 8:50 am Post subject: |
|
(Repost, since this got bumped by another page, but updated message.)
Ok, this build has TRAC's and my idea for an S-DSP EDL fix applied. EDL
writes take effect immediately, and echo index bounds checking occurs
before FIR filtering and echo buffer writes. Please test this with all
of the really really picky/sensitive audio games you're aware of, and
see if you notice a difference between this and v0.019 official.
Obviously, the sound differences should only exist in echo effects, but
luckily just about every game out there uses the echo buffer. Note any
differences you find either way, but I'm particularly interested if
things get worse, which will imply this fix is incorrect (assuming the
difference is verified in hardware as being correct in v0.019
official), and we can try out the fix idea suggested by DMV27. If no
one finds any new audio bugs, we'll assume the fix was correct.
And no, there's no audio resampling in this. I think log audio data
might still work, if that'll make it easier. It might not, the win32
port is falling apart as I rewrite the cross-platform port.
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip13.zip |
If anyone insists on posting about this on some other site (I'd prefer
not, as always), please at least mirror the file.
Update: audio logger works. I binary compared two files. The only
difference is that audio is being output four samples sooner now,
they're otherwise exact matches. Doesn't seem to be a bad thing by any
means.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Feb 09, 2007 11:27 am Post subject: |
|
I don't hear any differences in Chrono trigger, FF3, Killer instinct or Zombies ate my neighbors.
However i have the "feeling" that the audio sounds more accurate now.
did find a bug in one of my favorite games though.
Zombies ate my neigbours:
bug 1: line error on titlescreen, when the title is waving, 1 line
wraps around to the other side of the screen, i usually skip the title
screen, but this one scanline bug has been there as far back as 0.17
public.
bug 2: This bug seems to happen in most emulators, but its especially
annoying in bsnes, and worse than ever in 0.19wip13.
when i play on my original cart, if my sprite touches an item or person
i will immidiately pick it up or save them. but in bsnes i seem to have
to touch a certain pixel before it gets activated. seems like a problem
with the collision detection in the game? i have no idea what could be
causing this to happen in bsnes |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 3:37 pm Post subject: |
|
The one line error thing is quite well known. Not much can be done about that at present.
The SNES doesn't contain any sprite collision hardware code. All of
that is done in software, and I have serious doubts that I have core
CPU opcode logic bugs this far into bsnes' development that have gone
unnoticed.
Maybe it has something to do with the way I present video earlier than
most emulators ... this would probably be the hardest possible bug to
investigate because I would have to disassemble the game and figure out
how it's collision detection even works to attempt to fix anything with
it. I'd want serious confirmation on this before even acknowledging it,
but this would almost definitely be out of my hands to fix. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 09, 2007 4:40 pm Post subject: |
|
Tested
some games today with no problems, notably Earthworm Jim 2, Chrono
Trigger, Der Langrisser, and Super Castlevania IV. I heard no
differences in sound to wip9, and I'll bet a wav analysis confirms
that. Seems like you guys may have figured out that critical bug.
tetsuo55 wrote: |
bug 1: line error on titlescreen, when the title is waving, 1 line
wraps around to the other side of the screen, i usually skip the title
screen, but this one scanline bug has been there as far back as 0.17
public. |
I got suspicious of this "bug" after enabling line caching in the
config with no result. Here's a screenshot from real hardware.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 5:14 pm Post subject: |
|
FitzRoy wrote: |
Tested
some games today with no problems, notably Earthworm Jim 2, Chrono
Trigger, Der Langrisser, and Super Castlevania IV. I heard no
differences in sound to wip9, and I'll bet a wav analysis confirms
that. Seems like you guys may have figured out that critical bug. |
The output should actually be identical (excepting that output seems to
begin faster by four samples), except when changing ESA/EDL while echo
writes are enabled. This is a dangerously stupid thing to do (at the
very least, it screws up the FIR filtering for at least one sample),
but that's never stopped game programmers before. I don't expect many
games to have any audible differences. I don't know whether to be happy
that they allow us to emulate the hardware more accurately, or upset
that they make my life hell.
Unfortunately, without anomie around, we can't verify why he believes
that EDL is cached until the echo index wraps around. So I'm simply
going with TRAC's suggestion for a simplified approach. I have to agree
with that due to all of my IRQ findings. My original IRQ setup had tons
of internal variables and all kinds of special cases. The more I learn,
the more simplified the IRQ routines become.
Quote: |
I got suspicious of this "bug" after enabling line caching in the config with no result. Here's a screenshot from real hardware. |
Hooray! Less bugs to fix :D
Thanks for testing, FitzRoy.
---
My theory for MK2, based on that IRQ log, is that the SNES is only
testing to set the IRQ valid flags during lastcycle edges. That would
essentially be saying that the SNES hardware is range testing the IRQ
positions, rather than just testing on every clock edge. That seems
more complex, implementation wise, so maybe it's something else. Maybe
it simply doesn't lock the IRQ except on lastcycle edges ... hmmm.
In the off chance someone skilled enough is reading this thread anymore:
http://nesdev.parodius.com/bbs/viewtopic.php?p=21883#21883
I go into detaisl on my potential fix. I'm really starting to think
that the "delay" I'm currently implementing on $4200 writes is in
reality not a delay, but simply the CPU acknowledging the old $4200
variable instead. This would be very, very bad if true. It would
require SNES CPU pipeline emulation to emulate properly. That basically
means I would have to split the S-CPU in half, separate the bus cycles
from the work cycles (the latter being one cycle behind). Very, very
difficult to do, and libco will not help at all. Then again, maybe I
can hack things up again, and cache the old $4200 variable and use that
as a substitute. That's going to be messy and hackish, though :(
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Feb 09, 2007 7:29 pm Post subject: |
|
Good
work fitzroy, i do not remember that line being there on my cart, so to
verify what i posted i want to check my cart (the one in goodsnes might
be a bad dump or maybe my cart is a 1.1) but the box is empty and i
cant find it anywhere, i'm afraid it got stolen . |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Feb 09, 2007 8:18 pm Post subject: |
|
I know this is a test build,but there are some differences between WIP9 and this WIP build:
- Using frameskipping leads to zero performance gain in this WIP.Even
setting it to "9" doesn't change anything,this is unlike WIP9 in which
setting it to 1 made a huge difference
- Limit (throttle) speed doesn't work at all
- Speed (performance) has gotten noticably slower in this WIP.For
example,this machine now tries hard to get steady 50fps in SMW,LOL 
Tested some titles,no bugs found so far.Now to test some of the more
problematic stuff like EWJ,Aero the Acrobat,etc. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 09, 2007 9:17 pm Post subject: |
|
Quote: |
-
Using frameskipping leads to zero performance gain in this WIP.Even
setting it to "9" doesn't change anything,this is unlike WIP9 in which
setting it to 1 made a huge difference |
This was built with FAVOR_ACCURACY, which means RTO is calculated even
on skipped frames. You'll fail the SNES Electronics Test with
FAVOR_SPEED and frameskipping used. Was an accident though releasing
with that on.
Quote: |
- Limit (throttle) speed doesn't work at all |
Nope, that code got nuked while I rethink how to handle speed throttling.
Quote: |
-
Speed (performance) has gotten noticably slower in this WIP.For
example,this machine now tries hard to get steady 50fps in SMW,LOL :) |
Nothing changed since v0.019 official to slow the emulator down, other
than disabling the out-of-order execution for CPU<>SMP (it
doesn't affect accuracy, but was hindering my audio resampling. I'll
add that back in since the audio resampling thing won't work anyway).
Sorry you can't get 60fps anymore, I'm sure that makes testing the
audio quality quite difficult. Log audio data should help, you can
toggle it on and off mid-game, then listen to it in an audio player.
---
I have another idea of what might be wrong with MK2. I was too busy
looking at the IRQ code, but I'm now thinking ... wait a minute, a
four-clock error? I remember DMV27 submitted some fixes for WAI timing
a while back, but I never really verified I had it right. If that were
off by even one cycle, that could be the difference needed to fix MK2.
But, who knows. I'll try it out tonight and see what happens. I was
pretty sure I added DMV27's correction properly, though.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Sat Feb 10, 2007 1:49 am Post subject: |
|
Byuu wrote (taken from NESDev forums) :
Quote: |
I
could try and add a 100hz mode that just waits two vsyncs instead of
one. Kind of annoying as I won't be able to test it (of my four CRTs
and one LCD, none support 100hz in any resolution. They all go back
down to 85hz. Two of the monitors are very expensive, too). The
last, most evil method might be to pull off some sort of pulldown
method to perform 50->60hz transform. It won't look good, though.
|
Have you installed any _drivers_ for your monitor(s)?
No monitor in Windows (even the most expensive ones) can go above 85Hz without the drivers.
For example a high-end CRT supporting 2048x1536 and 200Hz refresh can
only display 1600x1200 and 85Hz (max) without its driver.
You have to disable the Refresh Rate Override setting for all resolutions in your graphics card drivers as well.
Also you should be aware that Linux doesn't support all refresh rates
and resolutions your monitor(s) can provide.Most distros don't even
support 100Hz and/or 1600x1200
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 10, 2007 7:24 am Post subject: |
|

Can you hear that? That's the sound of thousands of Japanese Besubaaru
enthusiasts rejoicing in unison at the prospect of playing one of Super
Famicom's greatest classic again on bsnes (ok, that's a mouthful)
Seriously, good to hear that Koushien 2 is finally working (even if
probably nobody will ever play it haha) and that the emulation is yet
again a little more closer to the real hardware. Perhaps like you said,
those crappy coded games do serve a purpose after all lol
kick wrote: |
Byuu wrote (taken from NESDev forums) :
Quote: |
I
could try and add a 100hz mode that just waits two vsyncs instead of
one. Kind of annoying as I won't be able to test it (of my four CRTs
and one LCD, none support 100hz in any resolution. They all go back
down to 85hz. Two of the monitors are very expensive, too). The
last, most evil method might be to pull off some sort of pulldown
method to perform 50->60hz transform. It won't look good, though.
|
Have you installed any _drivers_ for your monitor(s)?
No monitor in Windows (even the most expensive ones) can go above 85Hz without the drivers.
|
Yeah, most CRTs at least should support 100hz at 640x480 or 800x600. Well, all the ones I've ever used did.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sat Feb 10, 2007 1:15 pm Post subject: |
|
kick wrote: |
Also
you should be aware that Linux doesn't support all refresh rates and
resolutions your monitor(s) can provide.Most distros don't even support
100Hz and/or 1600x1200  |
X11 supports custom modelines to set pretty much any resolution you
want, within the specs of your monitor and display adapter. Some
drivers are fucked though, or need to be told to ignore EDID.
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sat Feb 10, 2007 2:43 pm Post subject: |
|
...Don't you specify refresh rates in the xorg.conf anyway? 
_________________

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

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sat Feb 10, 2007 2:54 pm Post subject: |
|
Those
are mainly used as a fallback if getting EDID information fails. Some
monitors, for some stupid reason, have incorrect EDID information which
you can override. Usually you only get a default list of modes, but you
can add custom ones, within the sync ranges of your monitor, using
modelines. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Feb 10, 2007 8:52 pm Post subject: |
|
i
checked out the box for zombies today, seems i might really have an
undumped version unless all pal releases where identical and they only
changed the box and stickers. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 11, 2007 2:07 am Post subject: |
|
Quote: |
i
checked out the box for zombies today, seems i might really have an
undumped version unless all pal releases where identical and they only
changed the box and stickers. |
Off topic,
Speaking of artboxs...I know you're currently extremely busy with the
core emulation and rewritting certain parts of bsnes but I figure I
might ask right now when the idea is fresh.
I think it would be a great thing, sometimes in the future, to have
some sort of game loader similar to Mame32 where you can see the game
box, manuals, catridge, game information etc (obviously all these would
be external files) Not only does this help to make the emulation feel
more "real", but it might also encourage people to preserve all those
things.
I guess it could either be integrated in bsnes itself or work like an
external frontends like the dozens availbale frontends for M.a.m.e (not
to confuse with derivatives M.a.m.es)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 11, 2007 4:27 am Post subject: |
|
Alright,
sorry to get so upset over Mortal Kombat II. I'm still burning out
pretty badly, not sure what to do about it. But I do appreciate you
pointing out the bug, Clements.
As it turns out,
it wasn't a problem with my IRQ support, but with wai timing. After
reading the w65c816s manual a little closer, and running some tests on
hardware, I've figured out how WAI is supposed to work:
Code: |
wai(0xcb) {
//last_cycle() will set event.wai to false
//once an NMI / IRQ edge is reached
1:event.wai = true;
while(event.wai) {
last_cycle();
op_io();
}
2:op_io();
} |
The only last minor detail is whether or not last_cycle() happens on
cycle 2 (3 in the manual, I number my cycles 0-2 instead of 1-3, 0 is
opcode fetch) or not. It would be exceedingly difficult to test,
though. The manual reads as if it does not.
I also wrote a test ROM to verify WAI timing is correct. I really don't
think it's possible for a non-cycle-based CPU core to emulate WAI
correctly, due to it's locking nature. To get MK2 working when your
emulator has proper interrupt support and timing, the important part is
the I/O cycle at the end of the opcode, otherwise WAI can end earlier
and throw off MK2's HIRQ interrupt code. Then again, extending the
opcode length rather than fixing it properly could potentially break
other games that rely on it not taking too long ...
So, one more game to scratch off the buglist.
I also tested all of the following games and they still work fine:
- Battle Blaze
- Battletoads & Double Dragon
- Final Fantasy IV
- Final Fantasy Mystic Quest + Mystic Quest Legend
- R-Type III
- Robocop Versus The Terminator
- Secret of Mana
- Street Racer
- Wild Guns
Everything looks good. Now if we can just fix Toy Story's audio
effects, we'll have the buglist back down to just Uniracers, which
remains as the only critical bug left.
Edit: new private WIP is up for testing out the WAI fix.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 11, 2007 6:30 am Post subject: |
|
Byuu you rock!!!!!!!!!!!!!!!!!!!!!!!
That "wai timing" stuff fixed zombies!! now its just like on the snes!!!
I tested several more games now, i think this wai timing has fixed
hundreds of subtle bugs, games now feel much more fluid and i no longer
feel a difference in playing them compared to the snes (except for the
graphics/colors)
games tested:
Zombies
chrono trigger
final fantasy 3
front mission eng patch
mario kart
everything feels perfect now
Last edited by tetsuo55 on Sun Feb 11, 2007 7:03 am; edited 2 times in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 11, 2007 7:02 am Post subject: |
|
Amazing. Could this truly mean the end for IRQ hell? 
Snark wrote: |
I
think it would be a great thing, sometimes in the future, to have some
sort of game loader similar to Mame32 where you can see the game box,
manuals, catridge, game information etc (obviously all these would be
external files) Not only does this help to make the emulation feel more
"real", but it might also encourage people to preserve all those things. |
I know there are websites out there that try to database the manuals in
txt format. But to obtain 3000 games in complete condition, without any
damage to the flimsy boxes and manuals... is pretty much not going to
happen. Cabinet art is way more durable and MAME has a much bigger
following than the SNES.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Feb 11, 2007 7:29 am Post subject: |
|
this
is true, but there is still a large SNES following, and a lot more
people had snes games than an actual arcade machine. It would take
awhile, and some games wouldn't have all the stuff for a long time, but
it'd be cool. Also it would premote people actually learning more about
games and seeing it all.
Can't wait for the next
release byuu, from the sound of it things are great. any particular
next step after you fix toy story and possibly uniracers. Are there
other parts of the main system you want to work with, or possibly sound
stuff or would you look into specialty chips. No matter what, this emu
is really great and everyone should see it. Sooner than most think this
is going to be a great emu to play with as people's computers get
faster.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 11, 2007 8:56 am Post subject: |
|
Quote: |
That "wai timing" stuff fixed zombies!! now its just like on the snes!!! |
Lucky me, that'd be a really tough one to try and fix.
Quote: |
Amazing. Could this truly mean the end for IRQ hell? |
Very likely, let's hope. However, I am not able to test every single
edge case for NMIs and IRQs. Mostly because with all the variations,
there's probably over 10,000 unique tests to be made. But the
differences would be much like the one edge case I can't test with wai.
To trigger an IRQ twice, one CPU cycle apart, would be unbelievably
difficult, even using specialized tests that I came up with for exact
clock position seeking, I would probably need to manually try 50+
combinations of opcodes to get the right timing to test it. I really
truly can't imagine any game ever relying on such an edge case of an
edge case. And if it does, that game really is utterly broken. Such
behavior probably even varies per revision of the chip. We really have
to draw the line at some point and say, "Whoa, whoa. This may have
worked on the real system by the grace of the gods, but this game
simply should not exist or be catered to!"
Not so sure we have to worry about that though, given how small the
buglist currently is. It seems IRQ emulation is accurate enough to run
all commercially-released games now. As nice as perfect hardware
emulation is, we'll never achieve that. It'll be nice to know that 100%
of all known games will be forever preserved with only a single
hack-free emulator, at least.
Now unfortunately, DMV27's notes on Toy Story aren't enough to give me
a headstart on trying to fix it. I'll just have to learn more about the
S-DSP and test sections at a time until I accidentally fix the bug.
It's at least minor enough that not many would really even notice it.
Quote: |
any particular next step after you fix toy story and possibly uniracers |
Honestly? I'm not sure if I want to take on the dot-based PPU needed to
fix Uniracers, and I lack the knowledge on how to fix Toy Story. I'll
probably focus on the latter, and polish up some details of S-DSP
operation. I want to try and emulate the S-DSP without the need for
subcycle emulation.
Basically, subcycle-accurate emulation of the S-DSP and S-PPU is going
to require the assistance of someone with a master's in electrical
engineering. We would absolutely need custom hardware built to
interface with these chips and determine exactly what they're trying to
do during each and every clock tick. Unfortunately, I still can't build
a simple LDR+PNP transistor circuit, and I really can't see myself
studying EE for half a decade just to support this in bsnes. The reason
I can emulate the S-CPU and S-SMP so well is because they are
general-purpose processors that I can run my own code on to analyze
their behavior. The S-DSP and S-PPU1/2 are DSPs with their own custom
programs that I cannot see. You all saw how long it took to get DSP-1
emulation bit-perfect, and the absolute geniuses that worked on that. I
don't think so highly of myself as to think that I could recreate their
success with these chips. Even more daunting is the fact that the exact
bit-perfect binary data could be read back from the DSP-1. We do not
have such luck with video and audio output data. Such data, even
through an S/PDIF or RGB output port which I lack, is probably at least
slightly altered from the original values, and even then probably has
some fluctuations after each run due to all of the crosstalk occuring
through imperfect timing crystals.
So basically, I want to try and fix Toy Story if I possibly can, and
then write a ROM patch to "correct" Uniracers' non-standard behavior,
if it's at all possible. I also want to try and get HDMA bus sync
timing working once and for all. Special chips would be nice, too. But
I won't be adding SA-1 or SuperFX myself. They are simply too
demanding, especially considering the lowest-possible-level approach I
take to processor emulation.
After that, I want to start polishing up the code. Moving all non-core
related code (such as filters and WAV file writing, and much later on
the file loading code) outside of the core, and into the
platform-specific code. Then I want to clean up and document all of my
work. Then clean up the user interface and its' code as much as
possible, and get the code ready for the inevitable final release. I'd
like to release my final SNES emulation core as a work of the public
domain, so that others can benefit. But I have a long, long way to go
until then (probably 2-4 years), and the code stays under my current
license until then.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 11, 2007 9:28 am Post subject: |
|
FitzRoy wrote: |
Amazing. Could this truly mean the end for IRQ hell? 
Snark wrote: |
I
think it would be a great thing, sometimes in the future, to have some
sort of game loader similar to Mame32 where you can see the game box,
manuals, catridge, game information etc (obviously all these would be
external files) Not only does this help to make the emulation feel more
"real", but it might also encourage people to preserve all those things. |
I know there are websites out there that try to database the manuals in
txt format. But to obtain 3000 games in complete condition, without any
damage to the flimsy boxes and manuals... is pretty much not going to
happen. Cabinet art is way more durable and MAME has a much bigger
following than the SNES.
|
True, true. But even if preserving all manuals, box scans etc is
probably never gonna happen, an emulator support would give it more
mainstream visibility, thus further encouraging preservation of
everything that's not directly strictly binary ROM dump related...
Plus it's a great thing to have imo. Of course it's always up to the
end user to find the manuals,scans,txt etc. like with Mame32
testsuo55 wrote: |
That "wai timing" stuff fixed zombies!! now its just like on the snes!!! |
Do you mean the bug2 collision detection you mentionned? Or the bug1 line?
byuu wrote: |
]
Quote: |
any particular next step after you fix toy story and possibly uniracers |
Honestly? I'm not sure if I want to take on the dot-based PPU needed to fix Uniracers
|
Ideally,if you ever decide to tackle the dot-based PPU. would be to
release one final "for public usage" version of bsnes with the current
scanline-based renderer, one that plays every non-special chips games
correctly (and maybe either a hack or like you said a ROM patch for
Uniracers) and then try the dot-based PPU that would serve more as a
reference than anything that's actually intended to use.
Thing is, I doubt there are many people, if any, that would actually
try to do it if you don't. Not complaining but merely stating the
situation. Of course, beggars (i.e: end-users) can't be choosers and
considering the insane ammount of work you've done these past few years
it's fair game either way whatever you decide.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 11, 2007 10:42 am Post subject: |
|
Byuu, i would like very much for you to pursue the remaining audio issues.
The audio is still slightly off compared to my hardware, but its
extremely close. ofcourse my sound could be different because of little
differences in clock frequencies.
Snark:
I ofcourse mean "bug2 collision detection", fitzroy already reproduced bug1 on hardware.
Byuu, do you think it would be possible to later create a winamp plugin
for you audio engine? this way i could have the best possible snes
music emulation.
Finally, do you still have contact with Arbee? I see a lot of
interesting things happening around mame and mess, a lot of people
there can do things like decapping chips and reading outputs from
dsp's, cpu's
Maybe if someone wanted to help with the snes we could somehow donate
the hardware and games needed so we could get the technical
documentation needed of the DSP's and Special chips? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 11, 2007 11:28 am Post subject: |
|
Snark wrote: |
FitzRoy wrote: |
Amazing. Could this truly mean the end for IRQ hell? 
Snark wrote: |
I
think it would be a great thing, sometimes in the future, to have some
sort of game loader similar to Mame32 where you can see the game box,
manuals, catridge, game information etc (obviously all these would be
external files) Not only does this help to make the emulation feel more
"real", but it might also encourage people to preserve all those things. |
I know there are websites out there that try to database the manuals in
txt format. But to obtain 3000 games in complete condition, without any
damage to the flimsy boxes and manuals... is pretty much not going to
happen. Cabinet art is way more durable and MAME has a much bigger
following than the SNES.
|
True, true. But even if preserving all manuals, box scans etc is
probably never gonna happen, an emulator support would give it more
mainstream visibility, thus further encouraging preservation of
everything that's not directly strictly binary ROM dump related...
|
It's really not an emulator's job to encourage people to care about ROM
or packaging preservation, especially when the latter has greater
nostalgic than gameplay implications. If you're talking about a
front-end, though, I have to believe that there already is one. I swear
I've seen stuff like this being made for people wanting full read-outs
for their games: names, release dates, genres, screenshots, etc. And
they work with stand-alones. Sounds easier than convincing every
stand-alone emulator to be more like MAME32, yes?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 11, 2007 12:29 pm Post subject: |
|
Still i think byuu wanted something similar too.
i too would like a mame32 like interface, with game screens, box shots,
info about the game, cheatcodes and all that stuff in a pane, but
without losing the "open cart" option |
|
|
ndru New Member

Joined: 30 Nov 2004
Posts: 8
|
Posted: Sun Feb 11, 2007 2:45 pm Post subject: |
|
Byuu, have you considered using the open-source cross-platform GUI library wxWidgets,
instead of writing your own? I haven't tried it myself, but it's the
same library used by Audacity, Code::Blocks, and VLC, and it's licensed
under a more permissive variant of the LGPL. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 11, 2007 8:42 pm Post subject: |
|
tetsuo55 wrote: |
Still i think byuu wanted something similar too.
i too would like a mame32 like interface, with game screens, box shots,
info about the game, cheatcodes and all that stuff in a pane, but
without losing the "open cart" option |
That was a long time ago, before he even decided to go cross-platform.
Maybe that changed his plans a little, because he doesn't mention this
on his agenda.
But like I said, why wait? There may already be a front-end out there
that will let you construct your own database, and not just for bsnes,
but for every other system. It doesn't make sense for every emulator to
integrate their own front-end. What games get included/excluded in the
games list? Who's going to update it when new dumps are discovered ten
years from now and he's not working on bsnes anymore? Are the benefits
of an official front-end really worth the trouble over referencing an
external database? Etc, etc.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Feb 12, 2007 3:01 am Post subject: |
|
FitzRoy wrote: |
It's really not an emulator's job to encourage people to care about ROM or packaging preservation, |
No, probably not.
Quote: |
especially
when the latter has greater nostalgic than gameplay implications. If
you're talking about a front-end, though, I have to believe that there
already is one. I swear I've seen stuff like this being made for people
wanting full read-outs for their games: names, release dates, genres,
screenshots, etc. |
If it works with bsnes then yes, fine with me.
Quote: |
What games get included/excluded in the games list? |
What I had in mind, it wouldn't necessarily work with a database, so no
maintining there (Although I wouldn't necessarily be against a
integrated system either)
But, in it's basic form, the user would simply point to the relevant
files that links them to one particular ROM/file. So let's say: 'Select
ROM.smc /Right click/Select Jpg for "screenshots"/Select Jpg for
Boxarts'...and so on. Entirely local, no maintining needed
whatsoever.Would work with any and all future Roms.
Anyway, if there are indeed frontends that accomplish just that, than I
guess that works just as well. edit I'll see if I can find something
that works well with bsnes and reports here if I find anything.
edit: Well a generic frontend named "Gamebase" http://www.bu22.com/
works well enough. although obviously, since it's aimed at emulators in
general, it's not nearly as intuitive but there's a little guide
included that tells you everything you need to start. It works well
with 0.019w9. Supports screenshots for individuals games and possibly
even music ( ) although I haven't tested that and seem like an overkill, but anyway overall it works fine.
Last edited by Snark on Mon Feb 12, 2007 4:49 am; edited 5 times in total
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Feb 12, 2007 3:38 am Post subject: |
|
testuo55 wrote: |
I ofcourse mean "bug2 collision detection", fitzroy already reproduced bug1 on hardware. |
Whow...considering what byuu said earlier that's pretty amazing, and a
little scary I guess. Bugs like this could go completely unnoticed
despite extended testing, because the only people who could notice them
are the ones who are very familar with the game...scary.
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Tue Feb 13, 2007 4:40 am Post subject: |
|
I
tested Toy Story a while ago, but I never got around to posting this
info. It seems that Toy Story and Der Langrisser require opposite KON
behavior.
Code: |
// Toy Story
// Register: Value, APU Clock
// Start pause
FLG: 27 61145907
KOF: FF 61145981
KON: FF 61146244
KOF: 00 61148251
// Update flags here
KON: 00 61148261
KOF: DE 61150012 // Stop all except 0, 5
KOF: DE 61152774
KOF: 00 61154617
KON: 00 61154627
...
KOF: 08 62074493
KOF: 10 62075515
KOF: 40 62076527
KOF: 10 62078969
KOF: 08 62080060
KOF: 04 62080997
KOF: 02 62081934
KOF: 01 62083238 // Stop voice 0
KOF: 00 62084291
KON: 1F 62084301
KOF: 20 62087085 // Stop voice 5
KOF: 00 62089535
KON: 20 62089545
// End pause
// Der Langrisser
KOF: 40 10761448
KON: 40 10766242
KOF: 00 10766256
KOF: 02 10968399
KON: 02 10972773
KOF: 00 10972787
KOF: 10 10973974
KON: 10 10978789
KOF: 00 10978803
KOF: 04 11180400
KON: 04 11184774
KOF: 00 11184788
KOF: 40 11185741
KON: 40 11190535
KOF: 00 11190549
|
In TS, the game sets KOF/KON = FF then about 2000 cycles later it sets
KOF/KON = 00. If the flags are updated by the DSP between the last
KOF/KON = 00 write, then KOF = 00 and KON = FF which will cause the
sound effects to start playing.
In DL, the game first stops a voice using KOF, waits until envx == 0,
then it enables the voice using KON and immediately sets KOF = 00. The
game expects that the voice will always start playing when using this
process.
Possible solutions:
* After the DSP flags are updated every other sample, if status.KOFF == FF then set the internal status.kon = 00.
* Create a var "bool kon_changed". After writes to the KON reg, set
kon_changed = true. After the DSP flags are updated:
Code: |
if(!(dsp_counter++ & 1))
{
if (status.key_flag)
{ ... }
if (!status.kon_changed)
status.kon = 0;
status.kon_changed = false;
}
|
This solution allows KON to decay fast enough to fix TS, but slow enough to allow DL to work.
It's possible that either game could require subsample timing, but that
seems unlikely. What we really need is more info on KON. Does KON get
read once at the beginning of each sample, or 8 times per sample as
each voice gets processed? Does KON really decay as fast as anomie's
tests indicate, or is there some special case that is being missed?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Feb 13, 2007 10:26 am Post subject: |
|
How could we be able to test con decay on hardware?
EdIt:
None of the video settings work in the latest wip.
Edit2:
Byuu, i would like to help and update the cartDB, how can i add info to it? i have access to a lot of pcb info now.. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 13, 2007 4:48 pm Post subject: |
|
DMV27 wrote: |
I
tested Toy Story a while ago, but I never got around to posting this
info. It seems that Toy Story and Der Langrisser require opposite KON
behavior. |
It can't be said enough, so thank you again for the info :D
Learning about the echo buffer was surprisingly easy (though I still
don't understand how that FIR filter works), but the KON/KOFF registers
seem far more involved. I'll keep studying the code. It doesn't look particularly complex, but there are so many little subtleties that will completely destroy audio output ...
Do you think I would be able to test and verify this stuff if I
continued to learn about the S-DSP? Or would I require some sort of
digital linkup to record SNES audio output to analyze? I'm thinking
maybe I can get a high quality RCA input sound card and just record
from line in. The results won't be perfect, but should hopefully at
least be able to catch 80 consecutive samples of sustain vs release.
At any rate, it's a lot easier to do this than capture echo buffer data
and transmit it back to the S-CPU to display onscreen as binary data.
With a sound linkup, I could just simply get an S-SMP program running
and log the audio output directly.
Quote: |
Possible solutions:
* After the DSP flags are updated every other sample, if status.KOFF ==
FF then set the internal status.kon = 00.
* Create a var "bool kon_changed". After writes to the KON reg, set kon_changed = true. |
I'm at your mercy as to which you believe is more correct :/
I should be able to implement either one. The latter sounds more
plausible, but if I've learned anything from the SNES, the more
reasonable approaches are quite often wrong.
It would be really nice if we could implement the S-DSP without going
into subsample timing. The problem with subsample timing is that we
really, really, really cannot test and verify anything that we try and
implement. Even trickier is that the S-SMP and S-DSP probably run
exactly one read access length apart (and take enough time for two
reads), so that bus conflicts do not occur. Talk about something fun to
try and emulate.
Quote: |
It's
possible that either game could require subsample timing, but that
seems unlikely. What we really need is more info on KON. Does KON get
read once at the beginning of each sample, or 8 times per sample as
each voice gets processed? Does KON really decay as fast as anomie's
tests indicate, or is there some special case that is being missed? |
If you're not busy ... are you able to program tests that I could run
on my copier, and have me give you the results? If you are busy, I'll
do my best to test these things when I can.
Quote: |
None of the video settings work in the latest wip. |
I know, but thanks.
Quote: |
Byuu, i would like to help and update the cartDB, how can i add info to it? i have access to a lot of pcb info now.. |
src/cart/db. I'm hoping to rewrite it in a few months anyway. I'll be
sure to make a graphical table editor at that time.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Feb 13, 2007 6:41 pm Post subject: |
|
thanks byuu, that version of the db is much more readable than the .db binary |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 15, 2007 9:01 am Post subject: |
|
DMV27,
I forwarded your reply to anomie, here is his feedback:
anomie wrote: |
Well... It sounds like the problem is that TS wants to start playing sounds when it shouldn't? And DMV27 suggests this as a fix:
DMV27 wrote:
After the DSP flags are updated every other sample, if status.KOFF ==
FF then set the internal status.kon = 00.
Perhaps it's not clear enough in my doc, but if "internal status.kon"
is what I think it is then you always set internal status.kon = 00
after processing the KON/KOFF (not just when KOFF=FF):
anomie's apudsp.txt wrote:
Also note that KON (tries to) take effect immediately, the value is not
persistant (much like "clear port" bits of SPC700 register $00f1).
I'll add a note to clarify slightly. Of course, more testing of the matter would always be welcome.
EDIT: My docs predict that DL should occasionally drop sounds, unless
it very carefully syncs with the DSP. Can this be confirmed or
unconfirmed? |
However, obviously by setting kon to 0 every time kon_changed is set,
Der Langrisser starts dropping ~30% of its' samples. My S-SMP and S-DSP
cores are as closely synced as is possible (down to subcycle bus hold
delays) without subsample-accurate emulation of the S-DSP.
Now, I'm looking at your Toy Story log ...
Code: |
KOF: 01 62083238 // Stop voice 0
KOF: 00 62084291
62083238/32 = sample # 1940101 being processed
62084291/32 = sample # 1940134 being processed |
Am I missing something? There are 33 full S-DSP samples being
generated, isn't this far more than enough time for the S-DSP to kill
voice 0, without the need for buffering kon_changed (thus resulting in
basically an 8000hz polling rate for KON/KOFF/FLG)?
anomie also updated his apudsp.txt file in SNES9x repository. PM me if
you'd like a link, but here's the important info he posted.
Code: |
Each bit of KON/KOFF corresponds to one voice.
Setting 1 to the KOFF bit will transition the voice to the Release
state.
Writing 1 to the KON bit when the KOFF bit is clear will set the
envelope to 0, the state to Attack, and will start the current sample
from the beginning. If the KOFF bit is set, there will be no effect. In
either case, the corresponding ENDX bit will be cleared.
Also note that KON (tries to) take effect immediately, the value is not
persistant (much like "clear port" bits of SPC700 register $00f1). If
KOFF prevents the channel from keying on, it will not be tried again
until KOFF is rewritten. |
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Fri Feb 16, 2007 7:16 am Post subject: |
|
byuu wrote: |
Do
you think I would be able to test and verify this stuff if I continued
to learn about the S-DSP? Or would I require some sort of digital
linkup to record SNES audio output to analyze? I'm thinking maybe I can
get a high quality RCA input sound card and just record from line in.
The results won't be perfect, but should hopefully at least be able to
catch 80 consecutive samples of sustain vs release. |
With the right tests you should be able to verify some things, but I
don't know how accurate an RCA input will be. You could also just get
an RCA to 3.5mm adapter instead of a new sound card.
Quote: |
I'm at your mercy as to which you believe is more correct :/
I should be able to implement either one. The latter sounds more
plausible, but if I've learned anything from the SNES, the more
reasonable approaches are quite often wrong. |
I would go with the second one. It seems to work well with DL, TS, EWJ2 and other games.
Quote: |
If
you're not busy ... are you able to program tests that I could run on
my copier, and have me give you the results? If you are busy, I'll do
my best to test these things when I can. |
I should be able to come up with something, but I want to finish
working on my audio regulator (video sync) code first. It's possible to
get smooth audio with a 75ms buffer, but it does require a bit of math
to keep the audio from sounding horrible.
byuu wrote: |
anomie wrote: |
EDIT:
My docs predict that DL should occasionally drop sounds, unless it very
carefully syncs with the DSP. Can this be confirmed or unconfirmed? |
However, obviously by setting kon to 0 every time kon_changed is set,
Der Langrisser starts dropping ~30% of its' samples. My S-SMP and S-DSP
cores are as closely synced as is possible (down to subcycle bus hold
delays) without subsample-accurate emulation of the S-DSP.
|
The best thing to do would be to just record the output of DL from a
real SNES and then compare it to bsnes to see if the notes all match
up. If they do, then no notes are being dropped. That still won't
(dis)prove that the game requires subsample timing, but the only way to
do that would be to examine the game's sound code.
Quote: |
Now, I'm looking at your Toy Story log ...
Code: |
KOF: 01 62083238 // Stop voice 0
KOF: 00 62084291
62083238/32 = sample # 1940101 being processed
62084291/32 = sample # 1940134 being processed |
Am I missing something? There are 33 full S-DSP samples being
generated, isn't this far more than enough time for the S-DSP to kill
voice 0, without the need for buffering kon_changed (thus resulting in
basically an 8000hz polling rate for KON/KOFF/FLG)?
|
The "..." in the middle of the log indicates the unneeded part of the
log that I removed (notice the large jump in clock cycles). The top of
the log is the start of the pause, and the end of the log is where the
game is unpaused. Everything from cycle 61150012 to 62083238 (or
62087085) is where the sound effect on voice 0 (or 5) gets stuck during
the pause because the KON=FF at cycle 61146244 did not decay. Although
this only covers about 0.91 seconds, it would continue on forever if
the game was left paused.
Also, kon_changed would only set the KON decay rate to 8000 Hz. The polling rate would still be 16000 Hz.
Code: |
Writing 1 to the KON bit (...) the corresponding ENDX bit will be cleared. |
The code in bDSP used to do this before the DL fix, but then it was
changed to only clear ENDX for voices that were actually keyed on. If
this is verified on real hardware, then it can be changed back. In
either case, I don't know of any games that are affected by the change.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 16, 2007 3:08 pm Post subject: |
|
DMV27,
blargg suggested the following to fix both Der Langrisser and Toy
Story. I don't have the latter to test, but the former works correctly
now, and using anomie's old "kon instantly gets cleared" hardware
findings. blargg also confirms those findings. The idea is that we
perform KOFF test, and then kon test, even if KOFF were set. This gives
games times to clear KOFF and still have the sound effect play. Nothing
plays immediately because we wait 8-9 samples before playing a new
keyed on channel anyway.
Everyone else, please
try the latest WIP with DL, TS, etc and see if any regressions have
occurred. This does work for DL for me, and should fix TS once and for
all. Consider this a private experimental WIP. If it works ok, I'll get
a new version up by tomorrow for everyone to try out.
Code: |
if(!(dsp_counter++ & 1) && status.key_flag) {
for(uint v = 0; v < 8; v++) {
if(status.soft_reset()) {
if(voice[v].env_state != SILENCE) {
voice[v].env_state = SILENCE;
voice[v].AdjustEnvelope();
}
} else {
if(status.KOFF & (1 << v)) {
if(voice[v].env_state != SILENCE && voice[v].env_state != RELEASE) {
voice[v].env_state = RELEASE;
voice[v].AdjustEnvelope();
}
}
if(status.kon & (1 << v)) {
voice[v].brr_ptr = readw((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.ENDX &= ~status.kon;
status.kon = 0;
status.key_flag = false;
} |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Feb 16, 2007 4:37 pm Post subject: |
|
where
can we get the latest wip? I know it isn't a public release, but I
wouldn't mind knowing how to check em out as this stuff interests me.
That is of course unless this is only for select testers, in which
case, never mind.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Sat Feb 17, 2007 1:29 am; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 16, 2007 5:24 pm Post subject: |
|
Toy
Story's not fixed in the new wip16 for me. DL, EWJ2, and Battlemaniacs
all sound fine, as they did in wip14, but Toy Story's problem seems to
actually have gotten worse (or better, if you wanted it to become
consistent). The repeating and persisting sounds used to be somewhat
random, happening ~50% of the time. Now they happen 100% of the time.
Woody says "Yee-ha" twice at the beginning, and the plane engine sound
always persists after pressing pause. Just to clarify, neither of these
happen on hardware.
Here's a bsnes wav output with
a really good example of the insanity that sometimes happens in the
middle. That part still seems random and dependent on where you end the
song. Sometimes it catches the middle of a note and then goes
screeeeeeeeeeech. The end is just me pressing pause during gameplay.
http://upload2.net/page/download/m20ZIcOfZPfi0rQ/toystory.rar.html |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Feb 16, 2007 6:02 pm Post subject: |
|
Does Der Langrisser drop sounds once in awhile on hardware? I know Earthworm Jim has some sound variances on hardware. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 16, 2007 6:13 pm Post subject: |
|
Quote: |
Toy Story's not fixed in the new wip16 for me. |
Sigh, alright. I'll try and be a bit more mature about this one than Mortal Kombat II.
Ok, so now it's always repeating the audio effects ...
Code: |
// Start pause
FLG: 27 61145907
KOF: FF 61145981
KON: FF 61146244
KOF: 00 61148251 |
Ok, so FLG doesn't set anything here except echo buffer write disable.
So the `if(soft_reset()) { ... } else { ... }' isn't the problem.
What I see happening from the above code is:
- KOFF disables all channels. KON then says, "no, actually, let's play
them", and clear internal kon to zero. However, KOFF is still set on
all channels. So two samples later, all of the sound effects stay off,
long before any sample from the KON write would get output. Then
finally, KOFF is released. But since internal kon is clear, no sound
effects should play. Why they still are, I don't know.
Sigh, I'm going to have to play this game at work to track this down.
Maybe I can just color adjust the image to be virtually pitch black or
something.
EDIT:
Here's my TS log:
Code: |
* FLG = 27 @ 1840972 ---
* KOFF = ff @ 1840974 + 2
* KON = ff @ 1840982 + 8
* KOFF = 00 @ 1841045 +63
* KON = 00 @ 1841046
* KOFF = f6 @ 1841100
* KOFF = f6 @ 1841321
* KOFF = 00 @ 1841357
* KON = 00 @ 1841358
* KOFF = f6 @ 1841559
* KOFF = 00 @ 1841680
* KON = 00 @ 1841680
* KOFF = f6 @ 1841798
* KOFF = f6 @ 1842030
* KOFF = 00 @ 1842046
* KON = 00 @ 1842047
* KOFF = f6 @ 1842263
* KOFF = 00 @ 1842320
* KON = 00 @ 1842320
* KOFF = f6 @ 1842501
* KOFF = 00 @ 1842641
* KON = 00 @ 1842641
* KOFF = f6 @ 1842738 |
I was looking over anomie's ported emulation code and I think I've found the problem.
Code: |
if(!(dsp_counter++ & 1) && status.key_flag) { |
anomie recently mentioned that the only reason for the key_flag was to
prevent performing the below code when it wasn't needed. But now that
we no longer have the `else' in the kon&(1<<channel) key-on
test, it appears that Toy Story is turning off all channels, then
turning them all back on. Now, key flag doesn't get set again until
later when KOFF is cleared entirely. So the result is that all channels
stay on, because key_flag isn't set again with KOFF=$ff. Some channels
get killed later on with KOFF=$f6, but some remain on.
I should have a fix for this tonight.
Last edited by byuu on Fri Feb 16, 2007 7:43 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 16, 2007 7:39 pm Post subject: |
|
bobthebuilder wrote: |
Does Der Langrisser drop sounds once in awhile on hardware? I know Earthworm Jim has some sound variances on hardware. |
From what I could tell, no. Nothing sounded different than the way
bsnes does it. I was even button mashing on the naming screen for a
while trying to get something to happen.
byuu wrote: |
Sigh,
I'm going to have to play this game at work to track this down. Maybe I
can just color adjust the image to be virtually pitch black or
something. |
lol. At least it's not Barbie Vacation Adventure.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 16, 2007 9:59 pm Post subject: |
|
Ok,
I think I have it fixed now. Removed status.key_flag, and Der
Langrisser still sounds correct. I made a before and after recording of
Toy Story, and you can see at the end of the latter recording that the
audio drops to all null samples. The sounds definitely stop in the
latter one, but it sounds a bit rough during the ~20ms key off release
state. I'm guessing real hardware sounds the same, but who knows.
Killing audio channels completely rather than fading them out slowly
typically causes popping in audio. Here's the samples:
http://upload2.net/page/download/HtXNsJQX8DC42wg/toystory.zip.html
I'll post a new build later tonight. This one should be fixed now.
EDIT: release takes up to 8ms, per TRAC. By setting KOFF=$ff, KON=$ff,
KOFF=$00, the game is forcing release a lot faster, as KON clears ENVX
to zero. This causes a much faster, much harsher release. Hence the
crackly sound. Had the game only used KOFF=$ff, release would have
taken longer but sounded better. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 18, 2007 4:29 am Post subject: |
|
Ok, as promised, a public WIP build:
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip17.zip |
As always, please be generous with this one. If you must link to it elsewhere, please at least mirror it.
This should finally take care of the Toy Story bug. Yes, the audio
should halt roughly. The developers felt the need to use an evil trick
to force the audio to release faster than it normally should.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 18, 2007 7:07 am Post subject: |
|
I
can vouch that it sounds just like hardware now. With only three
dot-based dependent bugs remaining, you've really proven libco to be a
great strategy. I hope future authors, especially on earlier systems,
will consider it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 18, 2007 8:14 am Post subject: |
|
Good times, thank you for verifying. I tried out the tougher games: EWJ2, ToP, SO and CT, they sound good still.
By the way, wasn't it Mega lo Mania and Winter Olympics that had the
scanline issues? I thought Adventures of Frankenstein flickered with
the other setting (with line caching enabled, IIRC) ...
I suppose I should look into that line caching a little more in the
future. I wonder if I can just modify bPPU to poll twice per scanline
to get those two working correctly.
But first, I'm thinking I'd like to stay in sync with blargg's work on
a subsample-accurate S-DSP emulator. Though it clearly isn't needed,
that's never really stopped me before. Luckily, this shouldn't be
anywhere near as processor-demanding as a dot-based PPU renderer.
Probably won't even be more than 3-5% slower, tops. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 18, 2007 8:57 am Post subject: |
|
byuu wrote: |
By the way, wasn't it Mega lo Mania and Winter Olympics that had the
scanline issues? I thought Adventures of Frankenstein flickered with
the other setting (with line caching enabled, IIRC) ... |
Frankenstein and Winter Olympics show their line bugs with line caching
disabled, and are unaffected by hclock. Their issues disappear with
line caching enabled, but enabling line caching then results in Mega lo
Mania having a permanent line issue, as well as sprite flickering in
games like Ninjawarriors and The Lord of the Rings. The flickering
would usually occur when one sprite occluded another one. Since this
specialized fix for dot-based games started affecting untold numbers of
normal ones, you moved it to disabled by default.
So, technically, I could say that "line caching" is a work around for
these two games on my buglist, but I don't really like the idea of
suggesting that. People could turn it on and forget to turn it off,
which has the potential to screw up a bunch of better games and get you
false bug reports. If you can fix it, great. But if not, consider
removing the line caching option and doing this:
People throw the word hack around like it's a wholly bad thing. I think
that if an emulator uses game-specific hacks by default, with no
transparency to the user that they even exist, then that's a bad thing.
But if you were completely transparent about it and had them disabled
by default, then what's the big deal? It beats modifying the original
data, and it wouldn't break other games by having them on. It also
doesn't rule out the possibility of one day getting a dot-based
renderer. The only problem is that some people are going to act like
these bugs should be fixed instead of hacked. But these bugs aren't
like the other ones. Spending two years to fix three shitty games
ceases to be a purely emulation related decision. That's friggin two
years of your life. Anyone who thought less of your project for
offering hacks would be completely misinformed. But meh, I guess you
know people...
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 18, 2007 10:05 am Post subject: |
|
What
you could do is add those games to the Database and have bsnes enable
that fix automatically when the game is loaded, the enableling of
individual game fixes could be enabled/disabled in the configuration
options.
this way everything would work before moving over to sPPU.
Although i would rather see special chips/hardware support at this
point i do think it would be a good idea to further improve on S-DSP,
as sounds are still off slightly compared to my snes. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Feb 18, 2007 12:07 pm Post subject: |
|
You sure? (link)
_________________
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 Feb 18, 2007 1:55 pm Post subject: |
|
Good
post, I actually am assuming that the last difference in audio is
caused by my crystals rather than anything emulation related.
At this point its as good as impossible to find any difference in audio
between bsnes and the snes except for tiny pitch differences. The only
part of the audio that still sounds off to my ears is the echo effect,
and the audio cut off.
however if have not yet had the chance to try the latest Wip, which might solve those last problems.
As i have no hard proof for any of this i currently account everything
to my snes crystals, but maybe an sample accurate S-DSP will close the
gap even more.
I hope when thats finished we could get a bsnes S-DSP plugin for
winamp2 that is compatible with the current music sets so the
soundtracks sound better 
Edit:
Fitzroy, could you compare the sound output for Zombies ate my
neighbors, just keep pressing start till you get ingame. Then compare
the "Woo Haa" sound, and the falling text sound.
Thanks in advance |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 19, 2007 1:05 am Post subject: |
|
http://upload2.net/page/download/zcFZdlcARrQJh82/zombies-realthenbsnes.zip.html
Isolated sound comparison. First the sound from real plays, then bsnes.
The konami logo seems overly amplified compared to real. The "woo-ha"
sound is nearly identical. And the falling text sound is nearly
identical, save for the harsher ending.
So for you S-DSP experts trying to improve things even more, this might be a nice reference. |
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Mon Feb 19, 2007 2:23 am Post subject: |
|
The konami logo sounds less muffled. This could be due to the reasons byuu pointed out in the romhacking thread. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 19, 2007 3:37 am Post subject: |
|
Unfortunately,
even an S/PDIF link from a real SNES isn't good enough, as we can't
verify/match its' CPU<>SMP communications. Our best bet for
verification is still the echo buffer.
I uploaded
a new private WIP. This build is just demonstrating part of the new UI.
I'm trying to move back to putting everything commonly used in the
menubar, and moving all of the obscure/complex stuff out into separate
windows.
So far, lots of stuff is still missing, and the speed setting (not enable) doesn't work.
How does the video mode configuration feel in this WIP compared to
v0.019's video settings panel? Easier, better, worse? I realize it
loses a bit of flexibility (eg with custom resolutions), but eh. I'd
rather go back to simplicity than feature bloat. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 19, 2007 5:36 am Post subject: |
|
I
like it. The only problem I see in doing away with separate
windowed/fullscreen is that it might be overly difficult or even
impossible to get fullscreen to fill the whole screen with video data.
As it is, if you set your multiplier too high in windowed mode, the
video just disappears and bsnes has to be restarted. I'm sure you're
aware of this and are thinking of something. This behavior has always
existed in bsnes, but the separate modes made it avoidable.
As far as speed regulation, I'm wondering why we need anything other
than [check] "Regulate Speed." Who would want to regulate faster or
slower than normal? If it's simply enable/disable, you can still find
out how many fps your system can push.
Semantics: The "(off)" under frameskip seems superfluous. I would guess
that most people, even newbs, could infer that a separated 0 means off.
I also like "Load" better than "Load Cartridge."
I'm guessing you're probably going to combine color/raster settings as
a popup window like input and cheats. Sounds fine to me. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Feb 19, 2007 6:42 am Post subject: |
|
FitzRoy wrote: |
http://upload2.net/page/download/zcFZdlcARrQJh82/zombies-realthenbsnes.zip.html
Isolated sound comparison. First the sound from real plays, then bsnes.
The konami logo seems overly amplified compared to real. The "woo-ha"
sound is nearly identical. And the falling text sound is nearly
identical, save for the harsher ending. |
Provided none of those differences are caused by the equipment used, I pretty much agree on all points.
The very beginning of the sound of the 'Konami' intro I cannot detect
any differences, but after that (aroud the 5th "note") the difference
is clearly heard, being louder.
"Woo-Ha..ha..ha..." I cannot detect any difference at all.
Falling text sound: The small "pop" sound marking the end of the sound are more apparent on bsnes.
edit: Ok, since it appear, from what was said, that the small
differences could indeed be caused by the process of logging the audio
just disregard this post.
Last edited by Snark on Mon Feb 19, 2007 8:19 am; edited 2 times in total
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Feb 19, 2007 7:19 am Post subject: |
|
byuu wrote: |
This
build is just demonstrating part of the new UI. I'm trying to move back
to putting everything commonly used in the menubar, and moving all of
the obscure/complex stuff out into separate windows. |
Do you think you can put up some screenshots for the curious [me]?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 19, 2007 7:58 am Post subject: |
|
bobthebuilder wrote: |
The konami logo sounds less muffled. This could be due to the reasons byuu pointed out in the romhacking thread. |
I agree. It could just be that bsnes is more clear. Maybe kmixer is
resampling my snes input just enough to muddle the sound. Could also be
attributable to the parts with which the mod was performed. The snes
isn't natively digital, we know, and it outputs at a strange 32040hz.
There's also something complex to do with sample randomness. As I
understand it, it's just a hardware quirk that can only be simulated,
not emulated. bsnes opts for ideal output vs slightly random output,
and I think it makes sense to stay that way.
The point, though, is that we can hear just how close it is. Anyone who
claims Chrono Trigger's sounds are still off as per the romhacking
thread is going to have to provide recordings to back it up. That guy
wasn't even using the same speakers in his comparison. Plus, it's so
damn easy for people to be tricked with placebo. That's why I
constructed the wav the way I did. One right after another, so your
memory doesn't screw with you.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 19, 2007 9:49 am Post subject: |
|
Thanks for the Wav file, the difference in your WAV file is exactly the same as the difference i hear between my snes and bsnes
byuu:
I like the new settings a lot  |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Feb 19, 2007 12:15 pm Post subject: |
|
byuu, how difficult would it be to implement an auto-frameskip feature?
I know for example Zsnes and SSF and many other emulators have such a
feature and I honestly have no idea how it works or whether or not it
would be desirable to have in bsnes
Hypothetical scenario: Someone has a system fast enough to get full
speed with 0fskp 99% of the time...but on those few occasions where
you're hitting a particularly demanding part the emulation will
actually slow down for a short while...Not very fun.
One solution is of course to set the frameskip to something like 1,
which should pretty much guarantee full speed in all
situations...Except it's kind of a waste to constantly play a +1
frameskip just for those rare occasions where your CPU can't keep
up...Ideally, it should only skip frames when it can't reach 60/60.
You can see why it's be a good option to have. In any case I'd be curious to hear how auto frameskip works. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Feb 19, 2007 6:08 pm Post subject: |
|
Can
I ask what you are using to record these sounds. I hope it's not some
crappy card that re samples everything to 48khz, I've found the only
reliable way to record sound from the SNES is by SPDIF or use a tv
tuner card on it since they better support the NTSC rate of noise. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 19, 2007 7:17 pm Post subject: |
|
Sound comparison stuff :
S/PDIF is flawed, too. The SNES outputs at ~32040.nhz. This is of
course because oscillators are not perfect. And really, they can't be.
Further, there are two oscillators. One for the CPU, one for the SMP.
And due to the differences, you get different rates of communication
every single time you run the SNES. That means you can run the same
game and record its' output, and get different results every single
time. Though, due to the DSP design, it'll probably only mean being off
by a sample or two for each channel being keyed on and off, but it
could possibly be more severe.
And even then, when you're trying to record the S/PDIF output, you have
to somehow capture samples. I can't say I know how a sound card would
record this input. It would have to have a pulse that tells it when to
capture a sample, otherwise it would only be able to poll the S/PDIF at
roughly 32khz, in which case you're duplicating and/or dropping samples
on occasion, which is no good.
Really, the best way to verify is to get a program into the S-SMP, and
cease all communications with the S-CPU. Once this is done, you need to
get the S-SMP to a known position. We do not have code to do this yet,
and it will be significantly more complex than my S-CPU code to do
this. Once here, we can generate sound and compare echo buffers on a
real system to emulation, and the results should be stable. There's
really no other way we can guarantee bit-perfect emulation. As it
stands, we have no way to get bit-perfect comparisons. We can get
"really, really" close, but not perfect. Because of this, and the
aforementioned issues I pointed out on romhacking.net, I am not
interested in investigating personal opinions on audio issues gauged by
imperfect human ears, unless they are very obviously wrong, eg Toy
Story's old bug. It's not to be mean, but we can't tell why the sound
is different, and I can't verify when I have it right, so there's no
way I can even attempt to try and fix any problems.
GUI stuff :

This is basically what I'm going for. Yes, less flexible. You can't
specify exact resolutions. But really, how often do end users need
this? I'm trying to go with simplicity. I'll probably add some kind of
manual override to the config file for power users, but I want to make
everything simple for the majority.
I like regulate speed settings. The only way I can play Mega Man X2 is
by playing the game at 50% speed. Sorry, my reaction times are low. I'm
more of an analytical thinker who spends a lot of time on detail,
rather than a fast reactionary kind of person. I can't seem to change
that, and I want to enjoy games too, so I "cheat" by slowing them down.
Also, Der Langrisser will drive you batshit insane if you don't have a
speedup ("fast-forward") mode.
This is my approach to ZSNES' fastforward/slowdown keys. I prefer to
keep the options permanently on, rather than keep a key you have to
hold down. It's very hard to play a game at 50% speed when youre
holding down a slowdown key the whole time, for instance.
I use "Load Cartridge" because of the need for a separate option for ST
dual cartridges. However, I am trying to think up a way to not require
a separate menu option for such obscure hardware. I'm thinking about
enabling multiple file selection inside the file open window, though
I'm not sure how tough that will be, or if it's even possible for GTK+,
yet.
Auto frameskip is possible, but I've never implemented such a thing
before. I'd basically have to predict how fast things are going and
adjust for it. I'd honestly rather not code such a thing, as I was
wanting to remove the frameskipping support eventually to begin with.
The reason is because fast frameskipping is not hardware accurate as it
skips RTO calculations. Enabling RTO calculations but not rendering
results in virtually no speed increase, so it doesn't really serve a
purpose other than to complicate the code. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 20, 2007 12:26 am Post subject: |
|
pagefault wrote: |
Can
I ask what you are using to record these sounds. I hope it's not some
crappy card that re samples everything to 48khz, I've found the only
reliable way to record sound from the SNES is by SPDIF or use a tv
tuner card on it since they better support the NTSC rate of noise. |
The mod is this: http://www.alpha-ii.com/Info/snes-spdif.html
It was recorded using an egosys Juli@'s spdif input and wavepad. My
driver's control panel allows me to select an external clock instead of
the internal one. That's what I select when recording and it detects
the 32khz rate being output from the modded unit. But yeah, these tests
are only useful in that we can get a general impression better than
that of analog.
byuu wrote: |
I
like regulate speed settings. The only way I can play Mega Man X2 is by
playing the game at 50% speed. Sorry, my reaction times are low. |
Oh, hehe.
byuu wrote: |
I use "Load Cartridge" because of the need for a separate option for ST dual cartridges. |
K. Only reason I brought it up is because bsnes can load homebrew data as well.
A minor warning on the simplicity thing... it seems simpler to put as
much as you can in the drop down menu, but the fact is that you're
still going to need separate menus for cheats and input, and possibly
the color/raster sliders if you're still planning them. And if you're
going to need separate menus for that, then what you had before
probably wasn't as bad as you think. The beauty of the previous design
was, you go into config to set up all the major stuff once, and then
you leave it alone. The stuff that people were likely to toggle was
left to the drop down menus. And it isn't as though the previous design
couldn't have been made simpler, too. Color/raster settings could have
been combined with "enable raster settings" removed. Most of the
emulation settings could have been removed. Manual screen render could
have been removed. Axis resistance could have been relegated to the cfg.
I think the result is going to depend on how you implement fullscreen.
If a person has to mess with the scale setting every time they toggle
fullscreen/windowed, then it might be more a of headache.
By the way, if you want an example of dropdown menus gone apeshit, look at Kega Fusion.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue Feb 20, 2007 1:47 am Post subject: |
|
You don't have to hold down any keys in ZSNES you can have it toggled on keypresses. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 20, 2007 1:48 am Post subject: |
|
Yes,
I need to work out some sort of embedded window-in-a-window system for
GTK+, so that I can make an oldschool window configuration panel.
For fullscreen, I'd like to make it just a hotkey, maybe a menu option
as well. I don't intend to support true fullscreen anymore, merely I
plan to stretch the window to consume 100% of the screen, and draw the
video inside there. I was planning to just add some sort of scaling
control to the fullscreen mode, such as "force fit all four corners",
"force fit as much as possible, but keep aspect", "scale, but only by
even multiples, as much as possible" ... I don't know.
Let me go home and work on it some more. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 20, 2007 2:01 am Post subject: |
|
byuu wrote: |
I
don't intend to support true fullscreen anymore, merely I plan to
stretch the window to consume 100% of the screen, and draw the video
inside there. I was planning to just add some sort of scaling control
to the fullscreen mode, such as "force fit all four corners", "force
fit as much as possible, but keep aspect", "scale, but only by even
multiples, as much as possible" ... I don't know.
Let me go home and work on it some more. |
Totally sufficient, if possible.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Feb 20, 2007 8:04 am Post subject: |
|
Let
me say I am against the new direction for fullscreen modes. One thing I
cannot stand is the "stretch to fill the screen" style fullscreen
methods in emulators. This is because they cause warped pixels in order
to acheive that end. You know where every 10 pixels or so, one of them
is doubled in length in order to have the total image width reach the
edge. This is why I don't use fix aspect ratio options either, they do
the same thing in order to trick the eye into seeing a corrected image,
but the keen eye notices the warped pixels from enabling that. The
whole point of accuracy should be to allow users to avoid that method
should they have the means and knowledge to make their own custom
resses on their system.
The way version 19 allows
me to set custom resses while setting the fullscreen res in separate
function is exactly what I always wanted and works perfectly. If the
later versions of bsnes end up being forced scale toggles or "stretch
and skew the image pixels to fill the screen" I'll stick with version
19's far superior display options. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 20, 2007 10:08 am Post subject: |
|
byuu wrote: |
Auto
frameskip is possible, but I've never implemented such a thing before.
I'd basically have to predict how fast things are going and adjust for
it. I'd honestly rather not code such a thing, as I was wanting to
remove the frameskipping support eventually to begin with. The reason
is because fast frameskipping is not hardware accurate as it skips RTO
calculations. Enabling RTO calculations but not rendering results in
virtually no speed increase, so it doesn't really serve a purpose other
than to complicate the code. |
I realise that RTO (though I don't know what "RTO" actually stands for
:P ) is not calculated when frameskip is enabled (hardware test failing
when fskp enabled for example). But I figured it's allright, because
you can always disable frameskip althogether and thus having RTO
enabled. In that sense I don't see the need to remove frameskip support.
I'll be honest, I'm not just in favor of having a highly accurate
emulator but also a playable one. So needless to say I'm for added
features like the NTSC filter, joypad support, frameskip support
etc...And yes, that means I'm also in favor of options that actually
reduce the accuracy of emulation (before anyone jumps, let me stress
'as long as they remains options' and the accurate way remains),
because of the obvious speed benefits.
Even that being said, I'll still support bsnes even if you decide to
take it to a more "pure" level meaning removing stuff that benefit end
users but has little or zero value in terms of accuracy or documenting
the hardware.
But, in a ideal situation, there would be a way to imbue both accuarate
and less accurate method into the program and having the possibility of
switching (having both a scanline and dot based renderer for example).
I know you said that you don't see how this could be coded given the
structure of bsnes, but surely there must be a way somehow?* The
current RTO disable/enable function is actually a good concrete example
of this concept.
Unless of course you feel it start to go against your emulation
philosophy and that even supporting the less accurate alternative would
go against your goals, in which case that's an entirely different
matter and a perfectly valid choice you can make as the author. ( Yeah,
praise the Lord I'm finally done talking for now lol)
edit: * Anyway, I don't want to come off as whining or begging for
features. Needless to say I believe the author is free to take his
emulator in the direction he sees fit.
edit2: It also didn't occured to me initially that keeping support for
the less accurate method while implementing more accurate ones might
render the code hellishly complex and difficult to deal with as things
progress.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Feb 20, 2007 2:38 pm Post subject: |
|
Snark wrote: |
I don't know what "RTO" actually stands for :P |
Range Time Over. It's about calculating if sprites are skipped or not.
anomie's register doc (link) has more details, see address 213E.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 20, 2007 2:58 pm Post subject: |
|
Snark wrote: |
edit2:
It also didn't occured to me initially that keeping support for the
less accurate method while implementing more accurate ones might render
the code hellishly complex and difficult to deal with as things
progress. |
Not to mention potentially slower.. if not directly, then because the
code is too complex to easily optimise. Myself, I'm all for clean code,
and if that means having to remove features that make it impossible,
then so be it.. but I'd prefer a modular approach, which by-and-large
seems to be what you're going for anyway. My suggestion is, take out
whatever features inherently make the code hackish, and clean
everything up, rewriting where you want.. then see what things you can
put back in or let others put back in.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 20, 2007 4:57 pm Post subject: |
|
Let's see ... other ideas for fullscreen mode ...
How about a list of options under "Window Mode" :
- "Windowed"
- "Fullscreen" -- use windowed mode settings
- "Fullscreen (scaled)" -- use windowed mode settings, but increase the
multiplier as much as possible for the best fit
- "Fullscreen (fill)" -- just fill the entire screen. Compensate for widescreen/portrait monitors?
(the menu will always be visible because GTK+ makes it nigh impossible
to hide the menu, you'll have to deal with that)
This is all a good ways down the road. It's going to be a long time until v0.020 is out.
Now, moving on to the other config stuff, I need :
- input configuration window
- cheat code editor
- raster settings
- debug console -> moving emulation settings here, end users should
have no need to understand / toggle BG layers, as this isn't 1996
anymore when nobody could figure out tile layering
Now, I have two options for how to design these.
Separate windows: The good thing here is that I don't have to have the
listbox on the left, so that means more room for stuff to be put on the
window. I can also resize the windows to use just what's needed.
One window: This just looks sharp. Everything all in one place is very
nice, but I'd need to go back and extend libui to support windows
inside of windows, which may or may not work well with GTK+ ...
Broken stuff:
- hardware scanline rasterer removed for simplification, will be moved to software
- software filters need to be moved outside of SNES class
- NTSC/PAL switch doesnt affect internal rendering at the moment
- no fullscreen support
- no linux input support
- need sync control menu (sync to video or audio, maybe add this to the
top of speed regulation menu, eg "No sync / Sync to video / Sync to
audio")
- need to fix speed controls (25,50,150,200% synced execution speed),
will be much more difficult for video than for audio
- need missing windows (input config, raster settings, cheat code
editor, debug console / memory editor / tracer / emulation settings)
and tools (log audio data, capture screenshot) |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Feb 20, 2007 5:03 pm Post subject: |
|
byuu wrote: |
Separate
windows: The good thing here is that I don't have to have the listbox
on the left, so that means more room for stuff to be put on the window.
I can also resize the windows to use just what's needed. |
I'm all for that. Although you have to decide if it's worth the extra
work for a sharper-looking config. Separate windows is similar to other
emulators too.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 20, 2007 5:55 pm Post subject: |
|
/Agree with Jipcy
For raster settings, you could skip having a separate window for this
by adding a "Video Scanlines" drop-down with denominations 0, 25, 50,
75, 100. Sure, you lose a little bit of flexibility, but that reduces
separate windows to input, cheats, and debug.
Color control could be taken out completely. If people want to simulate
their tv, they can adjust their monitor's colors. *flamesuit on* |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 20, 2007 9:07 pm Post subject: |
|
I
like gamma control. Real TVs do not have linear gamma curves. Just as
most are not willing to manually scale their monitor horizontal width
and distort all other applications, you can't expect them to ruin their
colors just for an emulator's sake :/
The gamma
adjust is free anyway. I have to convert bgr555->native format
(right now only rgb565, but this will be needed for rgb555, rgb888, etc
in the future). So, I have to convert anyway, may as well perform color
adjustments.
Right now, I'm not sure where I want all of this stuff. Do I want class
SNES to be an "intermediate" piece of emulation that sits between the
core and UI, or do I want it to be strictly part of the core and use
SNESInterface for all of that stuff? Hmm.
Ok, so I should go for separate windows, then? That will also remove
the problem I have with fonts. I don't have a way to select specific
fonts, as the names and sizes vary per OS. I could round things out
somewhat, but not completely. This way I can just use the defaults for
everything, and throw in one fixed-width font for the debugging stuff. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Feb 21, 2007 12:10 am Post subject: |
|
byuu wrote: |
I
like gamma control. Real TVs do not have linear gamma curves. Just as
most are not willing to manually scale their monitor horizontal width
and distort all other applications, you can't expect them to ruin their
colors just for an emulator's sake. |
I like Overload's gamma curve as well. But that wouldn't need a
separate window like sliders. Not that brightness/gamma control is
bloat... it's just an idea that went in hand with the scanlines. And
personally, I could live with having an original and gamma adjusted
choice.
Last edited by FitzRoy on Wed Feb 21, 2007 12:28 am; edited 1 time in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Feb 21, 2007 12:26 am Post subject: |
|
I'm very disappointed that the Fullscreen modes are being replaced with a Windowed facsimile. Oh well.
_________________
FF4 research never ends for me. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 21, 2007 12:39 am Post subject: |
|
Quote: |
I'm very disappointed that the Fullscreen modes are being replaced with a Windowed facsimile. Oh well. |
Please donate code to switch video modes with GTK+/X and I will be
happy to add the support back in. I'm not conditionally adding it on
one port.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 21, 2007 10:19 am Post subject: |
|
By
the way, byuu, how far do you intend to take this api you're writing?
(libui?) Do you intend to place it on your website as something like
libco or will it stay something exclusively for bsnes? |
|
Aaron Lurker

Joined: 31 Dec 2005
Posts: 145
|
Posted: Wed Feb 21, 2007 9:16 pm Post subject: |
|
Byuu: Does the GTK function, gtk_window_fullscreen(), not work?  |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Feb 21, 2007 9:38 pm Post subject: |
|
It's there in the manual
so I am pretty sure that is not byuu's problem. My guess is he is
having problems switching between fullscreen and windowed or he just
doesn't feel like working on it in favor of core related stuff??? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 21, 2007 10:32 pm Post subject: |
|
I
am planning to simulate gtk_window_fullscreen() for the Windows port.
This is what Deathlike2 is unhappy about. I'm assuming he wants the
actual screen resolution to be selectable, as well as the refresh rate.
Fullscreen also allows page flipping / triple buffering. And that would
indeed be very nice if there were a single API out there that
automatically queued page flip requests and didn't lock your
application waiting on vblank.
The only problem
with gtk_window_fullscreen() is that it does not hide the menubar. In
fact, thanks to GTK+'s "boxes" concept, I simply can't easily hide the
menubar at all like I can with windows. So fullscreen will always have
the menubar visible at the top. Good or bad, you can decide. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Feb 21, 2007 11:05 pm Post subject: |
|
byuu wrote: |
The
only problem with gtk_window_fullscreen() is that it does not hide the
menubar. In fact, thanks to GTK+'s "boxes" concept, I simply can't
easily hide the menubar at all like I can with windows. So fullscreen
will always have the menubar visible at the top. Good or bad, you can
decide. |
Kind of defeats the point of "full" screen... Wasn't expecting linux support to result in so many sacrifices.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Feb 22, 2007 12:03 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
The
only problem with gtk_window_fullscreen() is that it does not hide the
menubar. In fact, thanks to GTK+'s "boxes" concept, I simply can't
easily hide the menubar at all like I can with windows. So fullscreen
will always have the menubar visible at the top. Good or bad, you can
decide. |
Kind of defeats the point of "full" screen... Wasn't expecting linux
support to result in so many sacrifices.
|
Dude, I may not be pro-Linux here, but complaining about this issue when byuu wants portability is not helpful.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 22, 2007 1:20 am Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
byuu wrote: |
The
only problem with gtk_window_fullscreen() is that it does not hide the
menubar. In fact, thanks to GTK+'s "boxes" concept, I simply can't
easily hide the menubar at all like I can with windows. So fullscreen
will always have the menubar visible at the top. Good or bad, you can
decide. |
Kind of defeats the point of "full" screen... Wasn't expecting linux
support to result in so many sacrifices.
|
Dude, I may not be pro-Linux here, but complaining about this issue
when byuu wants portability is not helpful.
|
Just pointing out that the point of fullscreen is to make that external
stuff not visible. So it probably qualifies as "bad." The ideal
functionality is to able to toggle it on and off in fullscreen mode.
I'm more disappointed and confused at GTK+ than in bsnes. How do these
things get missed or added? Is it just "welp, it's fucked" or is there
some lead developer that you can appeal to?
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Feb 22, 2007 3:04 am Post subject: |
|
There is many ways to init full screen XRanR or XVidMode, it's not a GTK issues. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 22, 2007 3:12 am Post subject: |
|
GTK+'s
box system is the issue, so yes it is GTK+'s fault. Windows makes the
menubar part of the window decoration, so you can easily add and remove
it. No such luck with GTK+, where it's part of the client area. XRandR
and XVidMode aren't going to hide the menubar for me. As if I knew how
to use them, anyway. Like everything Linux, they're virtually
undocumented. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 22, 2007 6:13 am Post subject: |
|
Alright,
if everyone really cares about it ... I'll try and special case the
Windows port to allow toggling the menu on and off, at the cost of
consistency. It'll just not be there on the Linux port.
Similarly, it should be possible to add config file options for
changing the refresh rate. Will that be sufficient for everyone, or is
there really a pressing reason why the resolution should need to be
changed as well?
I still think everyone should stick to v018 or v019 for a while though.
It will take a long time to get all the features moved over to the port
rewrite. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Thu Feb 22, 2007 9:47 pm Post subject: |
|
The menubar is just another part of the widget hierarchy with the same visibility attributes that all the other widgets have.
Are you using glade for the UI? You can just give the menubar a name,
and then get the widget by name in your code, and then pass it to
gtk_widget_hide() |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 22, 2007 11:05 pm Post subject: |
|
If
I hide the menubar, the container will still be there. Can I hide a
container and have it automatically resize my window without leaving a
gap there? |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Fri Feb 23, 2007 12:49 am Post subject: |
|
You can alter the properties on the container for it -
void gtk_box_set_homogeneous (GtkBox *box, gboolean homogeneous);
void gtk_box_set_spacing (GtkBox *box, gint spacing);
void gtk_box_set_child_packing (GtkBox *box, GtkWidget *child, gboolean
expand, gboolean fill, guint padding,GtkPackType pack_type);
The "homogeneous" property:
Code: |
"homogeneous" gboolean : Read / Write
Whether the children should all be the same size. |
The "spacing" property:
Code: |
"spacing" gint : Read / Write
The amount of space between children. |
The "expand" child property:
Code: |
"expand" gboolean : Read / Write
Whether the child should receive extra space when the parent grows. |
The "fill" child property:
Code: |
"fill" gboolean : Read / Write
Whether extra space given to the child should be allocated to the child or used as padding. |
Another thing you could do is the window is a container for the
container, so you could change the widget hierarchy thusly:
Code: |
Window
|
\/
VBox
/ | \
menu bsnes statusbar (or whatever else you have) |
to
Code: |
Window VBox (with no parent window, so not displayed)
| / | \
\/ menu (null) statusbar
bsnes |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Feb 24, 2007 5:24 am Post subject: |
|
uh,
byuu, the address to your wip17 doesn't seem to work. Could you please
check it out? Also I know you are not concerned with emulating special
chips right now, but have you checked out the bs-x emulation in SNESGT,
it uses the BS-X bios and does a splendid job. as far as I know there
isn't any special graphical feats accomplished on the bs-x that aren't
part of the regular SNES hardware, so it's not like other enhancement
chips that alter gameplay. If it is to much work then forget about it.
But you have fixed certain other chips making, star ocean, sfa2,
megamanx, the sufami turbo and a whole slew of dsp games work, as well
as some bs-x games, so just thought you might take a look
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 24, 2007 7:57 am Post subject: |
|
BS-X
is partially documented, but there's far too much "I don't have any
idea what this does" parts, and I don't have a way to run my own test
code. If someone has a BS-X setup that I can use to run my own tests
on, I might be willing to purchase this from them and work on
supporting it. In the mean time, I'd do no better at guessing than
other emulators, and probably much worse since they most likely can run tests on the BS-X hardware.
Quote: |
Another thing you could do is the window is a container for the container, so you could change the widget hierarchy |
I will try hiding the VBox I use for the menubar and see if GTK+ can
compensate and resize properly. I'm hoping that it can, though that
seems a little too easy, having implemented support for GTK+ listboxes
and all -_-'
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 24, 2007 11:32 pm Post subject: |
|
Good news and bad news.
Good news first. anomie just confirmed blargg's suggestion for the Toy
Story fix, so that is permanently fixed. He also pointed out a tiny
difference in the current code (kon gets tested even with FLG set), so
I'll fix that as well. You won't hear a difference anywhere as no sane
programmer would write KON with soft reset FLG on, sound output will be
null either way as well.
Bad news. Both blargg and anomie verified the fix for Koushien 2 (EDL
reset) is not what the real hardware does. We'll keep looking into it,
but I'll be reverting that fix sometime soon. I need to get a little
clarification first, though.
---
EDIT: ok, figured out how to hide the menubar in GTK+, and added
support to libui. So fullscreen will by default not have a menubar, and
vsync will allow it to work with smooth refreshes (though you still get
audio distortion as usual, still one or the other).
So the only difference is you no longer directly control the resolution
and refresh rate for fullscreen, it just relies on your current monitor
settings. The good news is that means instant switching between the two
modes, the bad news is that CRT monitor users probably won't like
running their monitors at 60hz. I'll probably add config file options
for manually changing the refresh rate for the Windows port. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Feb 25, 2007 8:41 am Post subject: |
|
am I the only person who finds the address to the latest public wip not working?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Feb 25, 2007 9:49 am Post subject: |
|
Panzer88 wrote: |
am I the only person who finds the address to the latest public wip not working? |
It was probably taken down. Why do you want it? The configuration settings don't even work.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 25, 2007 1:02 pm Post subject: |
|
When a new public or private wip gets released the previous one gets removed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 27, 2007 9:16 am Post subject: |
|
Ok, more good news and more bad news.
- I renamed bDSP to aDSP.
- I modified aDSP to run in its' own separate thread, rather than be
enslaved to the S-SMP. This means aDSP can now run at any clock speed,
indepdendent of S-SMP. It now runs at 3.072mhz instead of 32khz, in
preparation for subsample-accurate emulation. Note that only 1.024mhz
is needed. I use 3.072mhz only for documentation (it's the true S-DSP
bus clock rate), and at no speed loss.
- I corrected a bug in aDSP for FLG/KOFF/KON processing, that has been confirmed by both anomie and blargg.
- I reverted the improper echo buffer fix, so Koushien 2 is broken
again, but my fix was not hardware accurate so it had to be removed.
Koushien 2 gets added back to the buglist again, sigh. I at least
simplified things a tad by removing the unnecessary echo_index variable.
Now, the reason for the aDSP changes was so that I can add in blargg's
S-DSP emulator. He's graciously allowing me to use his work, ala his
NTSC filter. His is subsample accurate, and he is making phenominal
progress with some truly innovative testing methods. I will allow users
to choose which DSP core they would like to use, hence I modified aDSP
so that the two can coexist. I also now have faith that I may be able
to modify bPPU to run with threading, given how well modifying aDSP
went.
Hopefully this will also benefit ZSNES, as it will give another point
of comparison for determining if new sound issues are due to a bug in
blargg's DSP, ZSNES' core or bsnes' core.
I will continue working with anomie's DSP as well.
The downside to this is a slight speedloss, surprise surprise. Since
the S-DSP is no longer enslaved to the S-SMP, there is additional
overhead in maintaining a synchronization counter between S-SMP and
S-DSP. It's roughly ~4% slower now (mainly because the S-SMP runs at
such a high clock rate that has to constantly sync test with S-DSP),
but I've been meaning to unenslave the S-DSP for a long time now, so I
believe it is worth it.
The last thing to note is that blargg's approach will undoubtedly be a
lot slower than anomie's sample S-DSP core, by virtue of running at 32
times the resolution. How that will pan out in bsnes is currently
unknown, but I suspect bsnes has enough overhead as it is with its'
S-CPU and S-PPU cores so as to make it not too noticeable.
And this will officially put the S-PPU as the last non-cycle accurate piece of core SNES emulation ... |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 27, 2007 1:43 pm Post subject: |
|
Whow. Looking very promising
byuu wrote: |
Ok, more good news and more bad news.
- I renamed bDSP to aDSP.
- I modified aDSP to run in its' own separate thread, rather than be
enslaved to the S-SMP. This means aDSP can now run at any clock speed,
indepdendent of S-SMP. It now runs at 3.072mhz instead of 32khz, in
preparation for subsample-accurate emulation. Note that only 1.024mhz
is needed. I use 3.072mhz only for documentation (it's the true S-DSP
bus clock rate), and at no speed loss.
- I corrected a bug in aDSP for FLG/KOFF/KON processing, that has been confirmed by both anomie and blargg.
- I reverted the improper echo buffer fix, so Koushien 2 is broken
again, but my fix was not hardware accurate so it had to be removed.
Koushien 2 gets added back to the buglist again, sigh. I at least
simplified things a tad by removing the unnecessary echo_index variable.
Now, the reason for the aDSP changes was so that I can add in blargg's
S-DSP emulator. He's graciously allowing me to use his work, ala his
NTSC filter. His is subsample accurate, and he is making phenominal
progress with some truly innovative testing methods. I will allow users
to choose which DSP core they would like to use, hence I modified aDSP
so that the two can coexist. I also now have faith that I may be able
to modify bPPU to run with threading, given how well modifying aDSP
went.
Hopefully this will also benefit ZSNES, as it will give another point
of comparison for determining if new sound issues are due to a bug in
blargg's DSP, ZSNES' core or bsnes' core.
I will continue working with anomie's DSP as well.
The downside to this is a slight speedloss, surprise surprise. Since
the S-DSP is no longer enslaved to the S-SMP, there is additional
overhead in maintaining a synchronization counter between S-SMP and
S-DSP. It's roughly ~4% slower now (mainly because the S-SMP runs at
such a high clock rate that has to constantly sync test with S-DSP),
but I've been meaning to unenslave the S-DSP for a long time now, so I
believe it is worth it.
The last thing to note is that blargg's approach will undoubtedly be a
lot slower than anomie's sample S-DSP core, by virtue of running at 32
times the resolution. How that will pan out in bsnes is currently
unknown, but I suspect bsnes has enough overhead as it is with its'
S-CPU and S-PPU cores so as to make it not too noticeable.
And this will officially put the S-PPU as the last non-cycle accurate piece of core SNES emulation ... |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 28, 2007 8:19 am Post subject: |
|
Ok, I keep getting this warning with gcc:
Code: |
warning: converting to `uint16' from `double' |
-Wno-conversion -Wno-implicit -Wno-traditional combined can't turn it off. I've read:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html
And found no way to disable it. Therefore, unless anyone knows which
option I should be using, Linux/gcc port is getting -w. Yes, the evil
disable all warnings flag. Like hell if I'm letting GNU hippies yell at
me because I use implicit conversions without explicitly casting. This
is a feature of c++, not a bug.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Mar 01, 2007 1:02 am Post subject: |
|
Implicitly
converting from a super-accurate format (double) to a super-inaccurate
format(uint16), like many features of C++, sounds a great way to shoot
yourself in the foot if you don't know what you're doing. Luckily,
programmers who do know what they're doing have a convenient way to
soothe the compiler's fears: the explicit cast.
Surely the most pragmatic thing to do would be to just add the explicit
casts where gcc wants them, and then leave warnings turned on so you'll
have, well, warning of other impending doom that might arise? |
|
nornagon New Member
Joined: 09 Jul 2005
Posts: 6
|
Posted: Thu Mar 01, 2007 6:08 am Post subject: |
|
Technically,
uint16 is more accurate than a double in that it most certainly
represents the number you think it does. Also, one can safely compare
uint16s to each other, whereas one must take extra care around
floating-point representations due to various architecture quirks.
I agree, though -- this is what explicit casts are for. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 01, 2007 7:00 am Post subject: |
|
If
explicit casts were required by the language, it would be fine. The
compiler wants to force me to either kill all warnings, or explicitly
cast everything, and I'm not cool with that. GNU is thankfully not in
charge of the c++ standard, and they should keep their warnings in line
with said standard.
Anyway, for the particular
code in question, I know what I'm doing and a uint16 to double cast is
fine. It's for my audio sample interpolation filters.
My point is more out of principle than reason. The code in question
would require about 60 extra int->double casts, and there's no real
reason I should have to do that. GCC just likes to be annoying. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 01, 2007 1:26 pm Post subject: |
|
Just
to get this straight, you mean the principal of having to type all that
stuff out when it should just work without complaining, right? What
you said is a little confusing because I can't tell whether or not
you're implying that the 'extra' casts would have an effect of the
code's efficiency (which they shouldn't as they would just be replacing
the implicit ones)
I agree that you should be able to turn the warning off; if you're
going to discern different types of warnings in your compiler at all,
and it's rather obvious to do so, there's no reason to exclude certain
types from being disabled independently of others.
Last edited by Verdauga Greeneyes on Thu Mar 01, 2007 4:19 pm; edited 1 time in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Mar 01, 2007 4:06 pm Post subject: |
|
byuu wrote: |
Like hell if I'm letting GNU hippies yell at me because I use implicit conversions without explicitly casting. This is a feature of c++, not a bug. |
Just because it's a feature doesn't mean it's not a stupid one.
byuu wrote: |
The compiler wants to force me to [...] explicitly cast everything, and I'm not cool with that.
The code in question would require about 60 extra int->double casts,
and there's no real reason I should have to do that. |
But there is: it sounds like a bad idea.
You have one implied (=hidden) rule: "this is valid code, ignore it".
If you want to make the source more understandable then you'll need to
include that rule in one way or another anyway.
You need the verbosity.
</IMO>
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 01, 2007 5:01 pm Post subject: |
|
Quote: |
Just
to get this straight, you mean the principal of having to type all that
stuff out when it should just work without complaining, right? |
Yes. Most of the "stupid" things I do are out of principle. I wouldn't
even mind if there were a way to turn off this warning. I'm absolutely
not the type of person to just blindly follow rules for no reason. Half
the time they are good rules and I eventually change my mind, half the
time they really are stupid and need to be changed / ignored.
Quote: |
Just because it's a feature doesn't mean it's not a stupid one.
...
But there is: it sounds like a bad idea. |
And this is why I work alone. I love the level of control so as to
disagree with another, and still do things my way anyway ;)
Ah well, sorry to bug you guys about this. Was hoping someone knew the -Wno flag I needed.
Back on track:
I fixed a serious bug with the lui port in Linux, so that's working
again. I also readded the speed throttling code, and now the
system.speed_* config file options take percentages rather than audio
samples rates. Also, audio.frequency in the config file sets your base
playback rate now.
I'm debating whether I should add a master_frequency value and apply
resampling to it, for the shitty onboard cards out there that lock up
with arbitrary sample playback rates (Windows has kxMixer, so it should
accept any playback frequency rate by default).
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 01, 2007 6:08 pm Post subject: |
|
to
each his own. I guess the way I figure you have your way and method,
and the results have been pretty good thus far. Keep up the good work.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 02, 2007 7:05 am Post subject: |
|
PS:
byuu wrote: |
The code in question would require about 60 extra int->double casts, and there's no real reason I should have to do that. |
Right, you have enough fans who can do that for you. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Mar 03, 2007 12:36 am Post subject: |
|
As
far as I know, the standard only requires that diagnostics be generated
for some kinds of erroneous code, and that a program be generated for
valid code. What else a compiler prints is outside the standard.
I too have a problem with warnings whose solution causes more problems
than the warning solves. As an example, I've used a compiler with an
optional warning for any
possible loss of bits, i.e. 32 bit int->16-bit short, unsigned int
to int (and vice-versa), etc. The required casts themselves become a
source of bugs, since the types involved might change in the future but
the cast will stay the same.
In your case, where
you're doing calculations on a sample value and then writing it out, a
semi-safe solution is to use a typedef:
Code: |
typedef short sample_t;
...
samples [i] = (sample_t) (...) |
But this still isn't very safe, since it's a C-style cast, so this
would silently accept even a pointer, yielding its raw bits.
Code: |
samples [i] = (sample_t) (foo_ptr) // valid code! |
OK, so we use static_cast<>:
Code: |
samples [i] = static_cast<sample_t> (...) |
That's pretty verbose and ugly. On the other hand, if a compiler warns
of precision loss only in cases where there could easily be unintended
truncation (double/float->int, int->char), then it might be worth
adding the casts. It would be nice if a functional-style C++ cast could
only perform static_cast<> conversions, rather than
reinterpret_cast<> as well, as that would allow this to be safe
and concise:
Code: |
samples [i] = sample_t (...) // drop parens from sample_t |
The main problem I've encountered is not compiler warnings themselves,
but people who demand that code compiles without generating any. If
these warnings were really that useful, such conversions would not be
implicit in the first place.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Mar 05, 2007 1:19 pm Post subject: |
|
blargg wrote: |
The
main problem I've encountered is not compiler warnings themselves, but
people who demand that code compiles without generating any. If these
warnings were really that useful, such conversions would not be
implicit in the first place. |
You got it. THAT is the real problem. Warnings for any language should
be treated as an advisory. What I mean by that is take a look at the
warning, understand what it's telling you and why it's happening. Then
make an intelligent decision on whether or not something needs to be
done about it.
Often times you may have done something ON PURPOSE in your code for
design reasons that generates a warning. WHY should you change it just
to make the warnings go away? That's silly. There is no problem in your
program in that case.
It is a false assumption to think that code that generates no warnings
is better than code that does generate a warning.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 05, 2007 4:07 pm Post subject: |
|
Ah, I'm in complete agreeance. You guys have a much more eloquent way of expressing the base point I was getting at.
Here, gcc is giving me a useless warning that I know will never cause
me issues. But it doesn't only give me the warning once, but several
times in a row, spamming an entire console window, every single time I
ever make any chances to that specific object file. And if I release a
version with this warning, people will complain that my software is
somehow defective for triggering warnings.
There's no reason for there to not be a specific warning disable flag
for this issue. As I tend to do most of the annoying things I do out of
principle, I'm not going to just go with the mass-accepted "just change
it to fix the warning" line. No, the problem isn't with my code, but
with the compiler. The standard explicity supports what I'm doing for a
reason. I trust the standards-body over the GCC authors.
Moving on though, I've rewritten libkeymap to take a more standard
approach (keysyms are constants rather than variables, remapping done
in realtime rather than startup), and created translators for most of
the keys on both the win32 and GTK+ ports. I now need to hook this into
the Input class, and Linux users should finally have input support.
The exact details are sketchy, in that GTK+ tends to send key messages
regardless of which control on a window is active, whereas win32 only
sends when no control has focus. I'll need to unify the behavior, but
for now, the main output window has no controls anyway so it's not
relevent for bsnes at the moment.
---
Ok, have a real fix for Koushien 2, courtesy of blargg.
This one is an approximation. Basically, the S-DSP fetches ESA at clock 29 for use on the next
sample. That value isn't used until clock 22 on the next sample. Right
now, anomie's core allows ESA writes to take effect immediately. By
using a close approximation, we can cache ESA after
echo buffer write, and use the old value before. This one-sample delay
is a lot closer to hardware timing, and indeed is enough to fix
Koushien 2. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 06, 2007 5:20 am Post subject: |
|
byuu wrote: |
Ok, have a real fix for Koushien 2, courtesy of blargg. |
Great! Thanks blargg.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 06, 2007 10:15 am Post subject: |
|
Ok, added blargg's changes. Played four levels, seems to be working fine.
Posted a new WIP with this change. I also replaced libkeymap with a new
implementation of it, this one is designed to work with window key
messages, meaning we can finally have input configuration for GUI
events and such in the future, and Linux users will finally have input
support shortly.
Still not now, though. Input on Windows might be a little sketchy, as well.
Just need to create an InputWM class for Linux. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Mar 06, 2007 1:12 pm Post subject: |
|
byuu wrote: |
Ok, added blargg's changes. Played four levels, seems to be working fine.
Posted a new WIP with this change. I also replaced libkeymap with a new
implementation of it, this one is designed to work with window key
messages, meaning we can finally have input configuration for GUI
events and such in the future, and Linux users will finally have input
support shortly.
Still not now, though. Input on Windows might be a little sketchy, as well.
Just need to create an InputWM class for Linux. |
Looks like your site is down at the moment
P.S. Is this new WIP public or private?
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue Mar 06, 2007 3:27 pm Post subject: |
|
We love you blargg.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 06, 2007 4:57 pm Post subject: |
|
Yes, site down. Appears to be something specific to subdomains. Not much I can do about it, but be grateful I have free hosting.
This one's private because it's pretty broken, but I'm getting close to
good enough for another public one. I want to at least have Linux input
working for that first, for all two people that use bsnes/Linux :)
---
blargg's subsample-accurate S-DSP merged into bsnes, and working.
Sounds really good. I'll try and get a public WIP out with both and WAV
recording so everyone can have fun comparing, heh. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 07, 2007 10:27 am Post subject: |
|
Ok,
this is a very important WIP release. Note that this file is rather
large, please mirror it if you must link to it elsewhere.
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip23.zip |
Included are two executables:
bsnes_adsp.exe - This version uses anomie's S-DSP emulator, clocked at 32khz
bsnes_bdsp.exe - This version uses blargg's S-DSP emulator, clocked at 1.024mhz
Please note that blargg's code is experimental and in-progress. That
said, I have been unable to find any errors with it so far. I hope I
haven't missed anything blargg wanted me to do before release.
Everyone, please give your thanks to blargg for creating this emulator
and allowing me to use his code :)
This day marks an important milestone, at least in bsnes, possibly in
the SNES emulation scene: the addition of a subsample-accurate S-DSP
emulator brings us one major step closer to the most faithful SNES
emulation that will ever be possible. Excepting bugs, this now gives us
bus-accurate S-CPU, S-SMP and S-DSP cores. It is not possible (nor
desirable) in software to get more precise than bus-level accesses. The
only core component remaining using an older, less faithful approach is
the S-PPU[1/2], and is not so coincidentally the source of the only
remaining bugs in bsnes. This will very likely be the biggest leap
forward in accuracy that will ever be seen for S-DSP emulation from
this date on.
The old win32 interface is now completely broken, so I am forced to
distribute using lui. As such, I've fixed the NTSC/PAL mode switches,
and added software video filter selection to the UI. Any configuration
changes that are not in the menu will have to be done via the config
file for the time being. I have also added the log audio data option
back to the misc menu. If you are not able to get 60fps in bsnes, or
would like to analyze the audio output between adsp and bdsp in another
program, you can use this option. Also, I'm aware of the lui-specific
issues, such as audio repeating when entering menus. lui is still a
work in progress.
Please test all of the games you can, and look for subtle audio
differences and the like. Bugs, improvements, whatever, would be very
useful to know. Please keep in mind that every commercial game ever
released was tested by both FitzRoy and tetsuo55, and there are
currently zero known problems with anomie's S-DSP emulator. Also note
that blargg's emulator will be slower, by nature of being more
low-level. I'll leave the decision on which core to enable by default
to you guys. Eventually, I'll have polymorphism fully functional, and
this will be a runtime-selectable option, and not require two separate
builds. But still, we unfortunately have to pick one to be the default
setting, which I hope does not offend anyone :(
I'm very appreciative and in debt to both anomie and blargg for their
help with S-DSP emulation. They have both done a very large service to
us all by creating these cores, so I thank both of them again for all
their hard work, and for allowing me to use their work in bsnes.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Mar 07, 2007 11:44 am Post subject: |
|
Thank you Blargg!!! thank you Byuu!!!
Eventhough controls are completely fubar for me in this build (whenever
i press a button on the keyboard ik gets repeated like 8 times(winxp
sp2)) The sound with blarggs core sounds exactly like my snes!! (well
my snes doesnt crackle )
The minute differences in sound i reported before are now gone.
I suggest you default to Blargg's core as that one is being emulated most accurately. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 07, 2007 4:29 pm Post subject: |
|
byuu wrote: |
Please
note that blargg's code is experimental and in-progress. That said, I
have been unable to find any errors with it so far. I hope I haven't
missed anything blargg wanted me to do before release. Everyone, please
give your thanks to blargg for creating this emulator and allowing me
to use his code :)
This day marks an
important milestone, at least in bsnes, possibly in the SNES emulation
scene: the addition of a subsample-accurate S-DSP emulator brings us
one major step closer to the most faithful SNES emulation that will
ever be possible. Excepting bugs, this now gives us bus-accurate S-CPU,
S-SMP and S-DSP cores. It is not possible (nor desirable) in software
to get more precise than bus-level accesses. The only core component
remaining using an older, less faithful approach is the S-PPU[1/2], and
is not so coincidentally the source of the only remaining bugs in
bsnes. This will very likely be the biggest leap forward in accuracy
that will ever be seen for S-DSP emulation from this date on.
The old win32 interface is now completely broken, so I am forced to
distribute using lui. As such, I've fixed the NTSC/PAL mode switches,
and added software video filter selection to the UI. Any configuration
changes that are not in the menu will have to be done via the config
file for the time being. I have also added the log audio data option
back to the misc menu. If you are not able to get 60fps in bsnes, or
would like to analyze the audio output between adsp and bdsp in another
program, you can use this option. Also, I'm aware of the lui-specific
issues, such as audio repeating when entering menus. lui is still a
work in progress.
Please test all of the games you can, and look for subtle audio
differences and the like. Bugs, improvements, whatever, would be very
useful to know. Please keep in mind that every commercial game ever
released was tested by both FitzRoy and tetsuo55, and there are
currently zero known problems with anomie's S-DSP emulator. Also note
that blargg's emulator will be slower, by nature of being more
low-level. I'll leave the decision on which core to enable by default
to you guys. Eventually, I'll have polymorphism fully functional, and
this will be a runtime-selectable option, and not require two separate
builds. But still, we unfortunately have to pick one to be the default
setting, which I hope does not offend anyone :(
I'm very appreciative and in debt to both anomie and blargg for their
help with S-DSP emulation. They have both done a very large service to
us all by creating these cores, so I thank both of them again for all
their hard work, and for allowing me to use their work in bsnes. |
Yes, thank you blargg for your great research and RE work :D
To be honest, I can't detect a clearcut difference where I can say
"yeah, there you have it, right there. Obvious difference" *Note that
I'm not doubting you if you say it's much more accurate. And yes I
know, accuracy is not always visible to the end-user but I'm all for it
anyway.
Then again, I haven't had/played a real SNES for years. So I wouldn't
exactly call myself a connoisseur. Perhaps testuo could post a wav
where the difference is most noticable for him.
byuu, how much of a speed hit do you estimate this sub-sample accurate
core cause? Right now, there are times where I can't reach 60/60fps,
even with frameskip set to 9 with wip23-B...something that does not
occur with wip23-A
If you don't mind either way, perhaps for now the default should be set
to the old core...Or just go with whatever Fitzroy suggest, democracy
style :P
small edit above *
Last edited by Snark on Wed Mar 07, 2007 4:53 pm; edited 3 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Mar 07, 2007 4:34 pm Post subject: |
|
Accuracy is your goal, so I say go for accuracy until you can make things modular
Great development, it's very impressive how close we've now gotten to
perfect emulation (or as perfect as feasible anyway). Are you still
planning to take a step back after you 'finish' libui to see if you can
clean up your code? Or have the recent advancements inspired you to
work on sPPU? (personally, I think you should only start on that when you feel the bsnes codebase is ready for such a significant change) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 07, 2007 5:01 pm Post subject: |
|
I
was also unable to perceive a difference between anomie's and blargg's
DSP cores. I regret not thinking of this sooner, but I shouldn't have
labeled the binaries. It would've been a lot more fun to rule out the
placebo effect. Sigh.
Unfortunately, I cannot
gauge the speedhit for blargg's S-DSP. My framerate display was only in
the old UI port that no longer compiles. I don't care to fix it, so
I'll need to add the framerate display to the lui port, then I can tell
you how much of an impact it has on performance.
I still have a long way to go with the new port, the hardest part will
probably be sticking windows inside of windows for GTK+. I believe I
get lots of assertion failures when I try and reparent windows like
that, but it's needed to get a nicer configuration panel. Once I get it
all cleaned up, I still want to work on cleaning up the codebase.
Nothing major really, just refactor all memory to the 'memory' class so
that eg DSP doesn't have to request memory from the SMP (in reality, it
works the other way anyway), etc. Then I also want to move all the
video filtering stuff out of the core. I don't see a reason why the
core should do stuff like this that is unrelated to SNES emulation, and
it'd be a cool pet project to be able to build each core component by
itself. Perhaps then I can ease up my licensing requirements some. A
shame it's impossible to release under PD, yet still bar the code or
derivatives from ever being relicensed under GPL. I shudder at the
thought of my work being forever locked into that license. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 07, 2007 5:13 pm Post subject: |
|
byuu wrote: |
I
was also unable to perceive a difference between anomie's and blargg's
DSP cores. I regret not thinking of this sooner, but I shouldn't have
labeled the binaries. It would've been a lot more fun to rule out the
placebo effect. Sigh. |
Well, nothing's preventing another zip release with unlabeled version
just for the heck of it. But aside from the hearable or un-hearable
differences, the fact is it's more internally precise and that's worth
its weight in gold imo.
Quote: |
Unfortunately,
I cannot gauge the speedhit for blargg's S-DSP. My framerate display
was only in the old UI port that no longer compiles. I don't care to
fix it, so I'll need to add the framerate display to the lui port, then
I can tell you how much of an impact it has on performance.
I still have a long way to go with the new port, the hardest part will
probably be sticking windows inside of windows for GTK+. I believe I
get lots of assertion failures when I try and reparent windows like
that, but it's needed to get a nicer configuration panel. Once I get it
all cleaned up, I still want to work on cleaning up the codebase.
Nothing major really, just refactor all memory to the 'memory' class so
that eg DSP doesn't have to request memory from the SMP (in reality, it
works the other way anyway), etc. Then I also want to move all the
video filtering stuff out of the core. I don't see a reason why the
core should do stuff like this that is unrelated to SNES emulation, and
it'd be a cool pet project to be able to build each core component by
itself. Perhaps then I can ease up my licensing requirements some. |
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Wed Mar 07, 2007 6:44 pm Post subject: |
|
Snark wrote: |
byuu wrote: |
I
was also unable to perceive a difference between anomie's and blargg's
DSP cores. I regret not thinking of this sooner, but I shouldn't have
labeled the binaries. It would've been a lot more fun to rule out the
placebo effect. Sigh. |
Well, nothing's preventing another zip release with unlabeled version
just for the heck of it. But aside from the hearable or un-hearable
differences, the fact is it's more internally precise and that's worth
its weight in gold imo.
Quote: |
Unfortunately,
I cannot gauge the speedhit for blargg's S-DSP. My framerate display
was only in the old UI port that no longer compiles. I don't care to
fix it, so I'll need to add the framerate display to the lui port, then
I can tell you how much of an impact it has on performance.
I still have a long way to go with the new port, the hardest part will
probably be sticking windows inside of windows for GTK+. I believe I
get lots of assertion failures when I try and reparent windows like
that, but it's needed to get a nicer configuration panel. Once I get it
all cleaned up, I still want to work on cleaning up the codebase.
Nothing major really, just refactor all memory to the 'memory' class so
that eg DSP doesn't have to request memory from the SMP (in reality, it
works the other way anyway), etc. Then I also want to move all the
video filtering stuff out of the core. I don't see a reason why the
core should do stuff like this that is unrelated to SNES emulation, and
it'd be a cool pet project to be able to build each core component by
itself. Perhaps then I can ease up my licensing requirements some. |
|
Not to mention the fact that the inaccuracies make themselves
perceptible instantly if you know what to look for (I always tend to
start with Chrono Trigger, and then go to a few other games I know of
that have notoriously hard sounds to emulate correctly).
byuu, I'll keep testing blargg's sound emulator against anomie's to see
if I can find anything that doesn't seem to stack up or seems odd.
I'll also say that if blargg's sound core is implemented into zsnes,
it'll probably sound 1000 times better than it does right now.
Last edited by Talbain on Wed Mar 07, 2007 6:59 pm; edited 1 time in total
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Mar 07, 2007 6:46 pm Post subject: |
|
I'm really glad to hear the progress on your emulator! I'm glad you haven't burnt out and stopped working.
A couple questions:
- Can you remind me if you ever fixed PGO compiling? I remember that broke a while back.
- Also, which parts of bsnes use/require libco?
Following the progress of your emulator make me want to learn how to
program. Overall, you seem to prefer to work on the emulation-related
aspects of your program more than the interface/GUI. And, obviously,
your priority with bsnes is to make it easy to compile on multiple
platforms and have a consistent interface. However, doesn't this limit
what you can do on each individual platform? For example, isn't it
possible to achieve more* by writing a custom Direct3D interface or
something like that? What I'm really saying here is that at some point
in the future, I think it would be cool to learn how to program C/C++
and the DirectX API so that I could make a very cool Windows interface
and video output engine, etc.
*I only have a vague understanding of what I mean by more.
After you get your current to-do list finished, do you plan on starting
in on the new PPU, or do you plan on working on other hardware (special
chips)?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Mar 07, 2007 7:25 pm Post subject: |
|
I
don't see much left for byuu to work on, except special chips. I hope
there is a way of improving the current ppu to work correctly with
uniracers. Optimizations, of course, would be great, since a 2.9 GHz P4
is still too slow . |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Mar 07, 2007 7:58 pm Post subject: |
|
Talbain wrote: |
I'll
also say that if blargg's sound core is implemented into zsnes, it'll
probably sound 1000 times better than it does right now. |
Perhaps you already know about this, but:
pagefault wrote: |
We are using blargg's DSP paired with a souped up version of _Demo_'s SPC. |
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Wed Mar 07, 2007 8:09 pm Post subject: |
|
zidanax wrote: |
Talbain wrote: |
I'll
also say that if blargg's sound core is implemented into zsnes, it'll
probably sound 1000 times better than it does right now. |
Perhaps you already know about this, but:
pagefault wrote: |
We are using blargg's DSP paired with a souped up version of _Demo_'s SPC. |
|
I know. The SPC sounds fine as far as I can tell; I haven't tested a
few of the wackier games like Uniracers yet though, so I'm holding out
reservations until I see what's actually released.
I'm looking forward to the release that sees the implementation of
blargg's sound core though, in both bsnes and zsnes.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 07, 2007 9:17 pm Post subject: |
|
PGO
is still broken, and this one I can honestly say is not my fault, but
the compiler's. The error even says as much. So far, S-CPU, S-SMP and
S-DSP require libco. S-PPU is the last piece that eventually will, but
currently does not. I already have a D3D renderer. My limitations are
in customization to controls. Eg on the old bsnes, my memory editor was
able to subclass an editbox control. I can't do that with GTK+. There
may be ways to get the same effect, but it'll be a completely different
interface. One thing I'm considering allowing is for others to develop
their own UIs, provided that they do not use the name bsnes, and they
do not modify the core (don't want hacks being added in). All ideas at
this point in time.
I'd like to do the S-PPU
next, but I don't know if I can. I will wait and see how much faster a
Core 2 Duo is compared to my Athlon 3500+. If I think I can push at
least 30fps with a cycle-renderer, I'll try it, if only for the sake of
utter completion.
Quote: |
Perhaps you already know about this, but: |
I'm not sure why we're still calling it an SPC700. pagefault is
referring to the S-SMP, they are using _Demo_'s version of this.
Typically, the S-SMP runs a program that writes to the S-DSP to play
sound back. So long as that program works correctly, sound output
should be fine.
I can't really speculate on _Demo_'s S-SMP emulator, but I believe it
is an opcode-based emulator. I could very well be wrong. If it is, then
it will lose the benefits of the precise interation between the SMP and
DSP on a cycle level. This isn't really a big deal, and blargg's filter
still has a lot of new findings (pitch modulation, echo buffering, etc)
that seem to make up the bulk of the improvements everyone is noticing
in Chrono Trigger et al. As ZSNES is currently using an even older DSP
core than anomie's, blargg's should be a huge leap forward. I doubt
most people will be able to tell the difference in sound between the
two emulators when we are both using his DSP emulator. The difference
will likely be about the same as the very real variance in sound you
get every time
a sound effect plays on a real system, for very similar reasons. In
fact, ZSNES will sound better on Vista, as I have no plans to rewrite
my DirectSound driver, and apparently Vista emulates DirectSound in
software, so you have forced audio resampling. Apparently someone at
Microsoft didn't understand why they put the 'Direct' in 'DirectX'.
I really
don't know what the S-SMP has to do with Uniracers' mid-frame OAM
writes, but admit to being almost tempted enough to not reply, just so
I could watch how the discussion continued to evolve :P
---
EDIT: I want to start reducing my dependency on my custom libraries in
my code. One step is to use <stdint.h>. Unfortunately, Microsoft
hasn't had the time to implement this eight year old standard, so I
cannot simply use it directly. Should I attempt to implement the types
I need myself in my own library file, or should I just start
referencing stdint.h in my code, and add documentation to the src
folder instructing Visual C++ users to seek out free implementations of
stdint.h to put in their include folders?
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Wed Mar 07, 2007 10:51 pm Post subject: |
|
byuu,
I've always been curious, is the SNES's sound processor that hard to
emulate? What exactly is it that makes it so much (seemingly) harder to
emulate than say... the Saturn processor, or the PSX, or the WSC, or
GBA, or NES, or Game Gear, or Genesis? I mean, I think until I heard
blargg's sound core today, I don't think I've ever heard an accurate
SNES sound processor. Is there just a lack of documentation or intense
complexity to it? Or does it do something strange that none of these
other sound processors do? |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Mar 07, 2007 11:06 pm Post subject: |
|
byuu wrote: |
Should
I attempt to implement the types I need myself in my own library file,
or should I just start referencing stdint.h in my code, and add
documentation to the src folder instructing Visual C++ users to seek
out free implementations of stdint.h to put in their include folders? |
Can't you include such an implementation with the source code?
byuu wrote: |
I'm not sure why we're still calling it an SPC700. |
As far as I remember it was used in the manual...
"5A22" was definitely used - well, it's a bit more specific than "S-CPU".
EDIT: Anti Resonance calls it SPC700 (link), even though it seems to say "S-SMP" on the chip. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Wed Mar 07, 2007 11:21 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 07, 2007 11:19 pm Post subject: |
|
Quote: |
byuu, I've always been curious, is the SNES's sound processor that hard to emulate? |
I'm the wrong person to ask, I've never attempted to personally emulate the S-DSP.
Quote: |
Can't you include such an implementation with the source code? |
I can, but it will choke on reference to <stdint.h>, as such a
file will most certainly not be in the compiler's include path. The
user would have to manually move the file to their compiler's include
folder.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Mar 07, 2007 11:48 pm Post subject: |
|
Talbain wrote: |
What
exactly is it that makes it so much (seemingly) harder to emulate than
say... the Saturn processor, or the PSX, or the WSC, or GBA, or NES, or
Game Gear, or Genesis?
I mean, I think until
I heard blargg's sound core today, I don't think I've ever heard an
accurate SNES sound processor. Is there just a lack of documentation or
intense complexity to it? Or does it do something strange that none of
these other sound processors do? |
It is relatively sensitive perhaps? Note that some games explicitly
rely on such timing (not that other consoles wouldn't have this issue,
but it is rather prominent on particular notable games). Besides, the
documentation has been lacking when the DSP/SPC has been referenced.
You can search the board, and the Snes9x board and you will come to the same conclusion.
_________________
FF4 research never ends for me.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Mar 08, 2007 12:18 am Post subject: |
|
Talbain wrote: |
I've
always been curious, is the SNES's sound processor that hard to
emulate? What exactly is it that makes it so much (seemingly) harder to
emulate than say... the Saturn processor, or the PSX, or the WSC, or
GBA, or NES, or Game Gear, or Genesis? |
The DSP in the sound processor (separate from the S-SMP, an 8-bit CPU
also in the APU) performs heavy signal processing using complex
algorithms. We don't even know how fast it runs internally. The DSP
itself is probably another processor and ROM running at a fairly high
clock rate. Since we don't know this code, we have to figure out what
it does by poking at it and seeing how it responds. This makes it a lot
more complex to figure out.
The S-SMP CPU that's in the APU runs at around 1024000 instruction
cycles per second. It can access the DSP during any one of these, so we
need to know what the DSP does every one of these clocks. Fortunately,
it uses a pattern of actions that repeats every 32 clocks, so we only
need to reverse-engineer 32 individual clocks. The main units of the
DSP are 8 independent voices and an echo unit. The voices do many
things in a particular order internally, and several things only in
some cases, so it's fairly difficult to determine exactly when it's all
occurring. The DSP has about 110 registers that the SMP can access, so
the times that each of these are read/written have to be known for
accurate emulation.
I've pretty much determined all the timing and actions performed each
clock, summarized in the link. This lists the various things performed,
along with what DSP registers are used and what memory accesses are
made.
S-DSP Timing Summary
The timing grid on the left shows how everything fits together. Voice
processing is significantly overlapped between successive voices. If
the table doesn't make much sense, here's an example: on clock 22, the
following actions occur in order:
- Voice 0 performs step V3a (calculate pitch)
- Voice 6 performs step V9 (update ENVX, perform gaussian interpolation)
- Voice 7 performs step V6 (OUTX-related stuff)
- Echo performs step E22 (read right echo sample, use FIR1 and FIR2)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 08, 2007 12:31 am Post subject: |
|
Talbain wrote: |
I've
always been curious, is the SNES's sound processor that hard to
emulate? What exactly is it that makes it so much (seemingly) harder to
emulate than say... the Saturn processor, or the PSX, or the WSC, or
GBA, or NES, or Game Gear, or Genesis? |
and just because these guys are making it extremely accurate doesn't
mean that we haven't had emulated SNES sound for awhile.
What I'm trying to say is, who says those other systems have accurately
emulated sound yet? Saturn emulation is barely anywhere at all at this
stage.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Mar 08, 2007 2:57 am Post subject: |
|
byuu:
ZSNES will not sound better on vista, it's just a different way of
accessin the card and making it easier to the user. And _Demo_'s core
is now cycle based after a lot of overhaul.
_________________
Watering ur plants. |
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 3:28 am Post subject: |
|
blargg wrote: |
Talbain wrote: |
I've
always been curious, is the SNES's sound processor that hard to
emulate? What exactly is it that makes it so much (seemingly) harder to
emulate than say... the Saturn processor, or the PSX, or the WSC, or
GBA, or NES, or Game Gear, or Genesis? |
The DSP in the sound processor (separate from the S-SMP, an 8-bit CPU
also in the APU) performs heavy signal processing using complex
algorithms. We don't even know how fast it runs internally. The DSP
itself is probably another processor and ROM running at a fairly high
clock rate. Since we don't know this code, we have to figure out what
it does by poking at it and seeing how it responds. This makes it a lot
more complex to figure out.
The S-SMP CPU that's in the APU runs at around 1024000 instruction
cycles per second. It can access the DSP during any one of these, so we
need to know what the DSP does every one of these clocks. Fortunately,
it uses a pattern of actions that repeats every 32 clocks, so we only
need to reverse-engineer 32 individual clocks. The main units of the
DSP are 8 independent voices and an echo unit. The voices do many
things in a particular order internally, and several things only in
some cases, so it's fairly difficult to determine exactly when it's all
occurring. The DSP has about 110 registers that the SMP can access, so
the times that each of these are read/written have to be known for
accurate emulation.
I've pretty much determined all the timing and actions performed each
clock, summarized in the link. This lists the various things performed,
along with what DSP registers are used and what memory accesses are
made.
S-DSP Timing Summary
The timing grid on the left shows how everything fits together. Voice
processing is significantly overlapped between successive voices. If
the table doesn't make much sense, here's an example: on clock 22, the
following actions occur in order:
- Voice 0 performs step V3a (calculate pitch)
- Voice 6 performs step V9 (update ENVX, perform gaussian interpolation)
- Voice 7 performs step V6 (OUTX-related stuff)
- Echo performs step E22 (read right echo sample, use FIR1 and FIR2)
|
You did all that by testing. o.O Wow. Heh.
Thanks for all the info blargg. Helps to understand a lot of why it takes so long.
Panzer88, yes, but I'm referring to accurate sound, and for the most
part, there are emulators out there with accurate sound for the
respective systems I've mentioned (Kega, Mednafen, VBA, ePSXe, pSX,
SSF, Magic Engine, MAME, et al). Some are even so far along as to be
able resample (as an option) the sound and make it sound better than
the original machine could. For as long as I can remember, the SNES
emulators have never had accurate sound cores. That isn't to say they
haven't progressively gotten better either. I'm not here to deride
anyone's work, in fact, I think the very fact that they're attempting
to make such improvements to their emulators just proves how skilled
and dedicated these people are.
Also, if you think Saturn emulation is "barely anywhere at all,"
clearly you haven't been to ngemu recently. Even Dreamcast emulation
will likely be a new reality once nullDC is formally released. It's
already getting better speed and runs more games than Chankast.
Emulation is moving, and at a faster pace than ever before, and I
applaud them for their work.
I'm simply here because I want to help with sound more as a tester,
because realistically that's the most I can do; I've studied sound,
music, and the theory of sound and I've become very adept at telling
even slight differences. The fact that Chrono Trigger (and a few other
games) sound correct in my recent tests with blargg's new sound core is
delightful to me, it made me giddy even.
As a result, I became increasingly more interested in more of the
background work that goes on in all of this. As such, I was merely
stating that I've heard more accurate emulation on other newer
emulators, and it somewhat bewildered me as to why. With blargg's
explanation, I now know. Thanks for the explanation. Sorry for my
long-winded reply.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Mar 08, 2007 4:41 am Post subject: |
|
byuu wrote: |
Please test all of the games you can, and look for subtle audio
differences and the like. Bugs, improvements, whatever, would be very
useful to know. Please keep in mind that every commercial game ever
released was tested by both FitzRoy and tetsuo55, and there are
currently zero known problems with anomie's S-DSP emulator. Also note
that blargg's emulator will be slower, by nature of being more
low-level. I'll leave the decision on which core to enable by default
to you guys. |
Welp, I can't perceive any differences between the two, which is good.
Also, somebody asked what the speed hit was between the two. It's
interesting that my situation is unique enough to estimate this. On
.019, which uses anomie's and has an fps counter, I get no lower than
60 on EWJ2's accordian screen (regulation off btw). On blargg's new
dsp, I get slight intermittent crackles, which tells me its dipping to
about 58 at most. So the speed hit is about 3% on my architecture.
That's a really small tradeoff and I don't see why you should need to
keep anomie's in addition to blargg's. I'll pin my own hopes on you
getting that bit of speed back with optimizations. It's just my luck
that I'd be dipping to 59 on certain scenes. I knew I should have
gotten the e6400...
By the way, I don't know if you're aware of this, but "log audio data"
creates two wav files for some reason and one of them is useless. Could
be a bug.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Mar 08, 2007 6:54 am Post subject: |
|
Talbain wrote: |
As
a result, I became increasingly more interested in more of the
background work that goes on in all of this. As such, I was merely
stating that I've heard more accurate emulation on other newer
emulators, and it somewhat bewildered me as to why. With blargg's
explanation, I now know. Thanks for the explanation. Sorry for my
long-winded reply. |
what you hear and how it is produced is two different things... they
can use hacks to get the sou nd to sound right... does that make it
accurate? yes it sounds like it would if it was played on a real
console... but no it is not accurate in the sense of coding... there
should be no need for hacks.
_________________
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: Thu Mar 08, 2007 6:56 am Post subject: |
|
franpa wrote: |
what
you hear and how it is produced is two different things... they can use
hacks to get the sou nd to sound right... does that make it accurate?
yes it sounds like it would if it was played on a real console... but
no it is not accurate in the sense of coding... there should be no need
for hacks. |
That's one of the first intelligent things I've seen you say. Congratulations.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 08, 2007 7:08 am Post subject: |
|
in
bsnes wip23 in Donkey Kong Country III, I noticed something odd and was
wondering if someone could confirm that it is like this on real
hardware also.
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Super Donkey Kong 3 - Nazo no Krems Shima (J) (V1.1).smc
Name: SUPER DONKEY KONG 3 Company: Nintendo
Header: None Bank: HiROM
Interleaved: No SRAM: 16 Kb
Type: Normal + Batt ROM: 32 Mb
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.1
Checksum: Good 0xB8F9 CRC32: 5B337FB6
MD5: D0CEFE1D11D0F84F98227A549E6E93B6
--------------------------Database--------------------------
Name: Super Donkey Kong 3
Country: Japan Revision: 1.1
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Side Scrolling
Ok this is the bug, at the very beginning when Kiddie and dixie are
spinning the xylophone. Look at Kiddie's eye on the left, every few
frames, part of it flashes an aqua color. Does this happen on real
hardware?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Thu Mar 08, 2007 8:08 am; edited 1 time in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Mar 08, 2007 7:26 am Post subject: |
|
I don't have my snes hooked up at the moment, does the bug also happen with pal and usa versions? |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 08, 2007 7:43 am Post subject: |
|
yes
it happens in this us version as well, not sure about the pal yet. It
seems to look like some compression of filtering bug rather than the
emulation.
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Donkey Kong Country 3 - Dixie Kong's Double Trouble (U) [!].smc
Name: DONKEY KONG COUNTRY 3 Company: Nintendo
Header: None Bank: HiROM
Interleaved: No SRAM: 16 Kb
Type: Normal + Batt ROM: 32 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0xB28C CRC32: 448EEC19
MD5: 120ABF304F0C40FE059F6A192ED4F947
--------------------------Database--------------------------
Name: Donkey Kong Country 3
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Side Scrolling
here is a screen print, I don't know how to do screencaps in this build
of bsnes, nor do I know how to turn off the standard filtering (I'm not
using any of the extra filters)
http://i163.photobucket.com/albums/t282/Numonohi_Boi/Kiddy.jpg
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Mar 08, 2007 7:55 am Post subject: |
|
No way that's a bug. I don't even have to check. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 08, 2007 8:07 am Post subject: |
|
my
apologies, if it hasn't already been done we should create a list of
bugs that exist on the hardware so that people can check those first,
I'm sure a lot of you testers already know many of them, but I'm sure
it would be helpful.
Just a thought
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Mar 08, 2007 8:21 am Post subject: |
|
The best thing would be to have something similar to mameinfo.dat, with all the game info and known game bugs. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 08, 2007 9:51 am Post subject: |
|
Good
news, v0.019's settings configuration panel is possible to implement in
GTK+. I figured out how to embed a window inside another.
This is technically not supported by the API, as the authors severely
underestimate the worth of such a direct function, however I was able
to rig up a cheap hack to pull off the same thing mostly transparently.
What I did was create a GtkFixed window called Panel. Then I added
Panel::attach, which takes a Window as a parameter. This function
reaches inside the referenced window, and grabs its' master container
that encapsulates the entire window and its' menubar, and reparents
this child widget from one window to another. It also makes sure the
owner window is hidden, as there'd be no point in showing an empty
window. The Panel class keeps track of multiple calls to attach and
detach, and can reparent windows back to their owner as needed. So,
with this, I can reimplement my listbox + panel style GUI.
Quote: |
The best thing would be to have something similar to mameinfo.dat, with all the game info and known game bugs. |
Nach doesn't like databases, mine will probably be removed when NSRT starts adding PCB IDs to ROM headers.
Quote: |
That's
a really small tradeoff and I don't see why you should need to keep
anomie's in addition to blargg's. I'll pin my own hopes on you getting
that bit of speed back with optimizations. It's just my luck that I'd
be dipping to 59 on certain scenes. I knew I should have gotten the
e6400... |
Nah, you really shouldn't need such a powerful processor. It's my fault
for putting code integrity completely over speed. I should be able to
get back a couple of recent slowdowns. Since that audio sync method
failed, I can add back in the CPU<>SMP drifting. Unfortunately,
the SMP<>DSP sync will still take a speed hit, as before I had
anomie's core enslaved to SMP. Much faster that way, but I just don't
feel right implementing enslavement in an emulator, regardless of
whether or not it has an effect on the end result ...
Quote: |
By
the way, I don't know if you're aware of this, but "log audio data"
creates two wav files for some reason and one of them is useless. Could
be a bug. |
Probably a UI issue calling clicked() twice or something. I've been
running into some problems of when exactly to call the clicked()
function for menu actions. I'll look into it.
Quote: |
byuu:
ZSNES will not sound better on vista, it's just a different way of
accessin the card and making it easier to the user. And _Demo_'s core
is now cycle based after a lot of overhaul. |
Ah, I figured bypassing the resampling algorithm of DirectSound in
Vista would help. Good to know that it will be less work for me.
Hmm, may I ask why you chose to make both the CPU and
SMP cycle-based? The SMP is easily enslavable to the CPU for a
significant speedup (your CPU no longer has to be cycle based -- so
long as the SMP is, they will communicate at cycle-level precision),
this is the method TRAC used. The end result is the same, and I'm sure
your reason is not to create a "pure" implementation from a hardware
standpoint (irrelevent to accuracy) at the cost of speed, given your
choice of x86 assembler for the language ...
At
any rate, congratulations. I'm glad you are improving this stuff, even
if end users don't care about it, as it's very important for historical
preservation. If anyone can pull off what I've done and fast, it's you
guys. That should give you roughly the same implementation-level
accuracy of bsnes (though we'll still obviously have different bugs in
our cores), so you can reclaim all 30 of my users. I'll have to wait
and see your finished result, but it sounds like I can go ahead and
work on that cycle-based PPU, since ZSNES can take my current place.
Not to mention, nobody can even run bsnes anymore, not even with Core 2
Duos, apparently -_-;
Unless of course, you've already implemented a cycle-based PPU too ...
Looks like we're finally moving SNES emulation as a whole from the
NESticle days to the Nestopia days. I'm in your debt for this.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Mar 08, 2007 3:01 pm Post subject: |
|
It
was just easier for us to make everything cycle based than to do it
elsewise. I don't think zsnes will replace bsnes completely there are
lots of quirks that we don't emulator or I have no idea if we will get
around to emulating. From a developers standpoint bsnes is better to
work on than ZSNES because it is closer to the real thing and you would
get similar results by using that. Each emulator will have a special
place to do something. We also have an option to use blarg's S-SMP or
_Demo_'s it's a compile time option.
_________________
Watering ur plants. |
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 3:03 pm Post subject: |
|
franpa wrote: |
Talbain wrote: |
As
a result, I became increasingly more interested in more of the
background work that goes on in all of this. As such, I was merely
stating that I've heard more accurate emulation on other newer
emulators, and it somewhat bewildered me as to why. With blargg's
explanation, I now know. Thanks for the explanation. Sorry for my
long-winded reply. |
what you hear and how it is produced is two different things... they
can use hacks to get the sou nd to sound right... does that make it
accurate? yes it sounds like it would if it was played on a real
console... but no it is not accurate in the sense of coding... there
should be no need for hacks.
|
Supposing that hacks could be used, there certainly haven't been any that I've heard that sound accurate.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 08, 2007 4:22 pm Post subject: |
|
pagefault wrote: |
It
was just easier for us to make everything cycle based than to do it
elsewise. I don't think zsnes will replace bsnes completely there are
lots of quirks that we don't emulator or I have no idea if we will get
around to emulating. |
Ah, well I can definitely understand making things easier :)
I'm also not so sure you won't be able to catch up on the quirks. Many
of the ones I've added were done so because they fixed games, and the
others only a handful of us care about. Since you'll likely be doing
the same thing, that shouldn't be a problem. I think you'll be
pleasantly surprised with how bugs start staying fixed with these new
cycle cores, though I still strongly recommend regression test ROMs.
Highly underrated, those.
Nonetheless, I'm more than willing to give you a hand if you get stuck on anything.
Again though, I have a serious problem that bsnes won't even run on a
Core 2 Duo anymore. The biggest drain on speed is the IRQ stuff, and I
really don't have the heart to touch that again. It took me over two
years to get that working right :(
Well, we'll see. Perhaps I can find another niche to focus on. Maybe a
really fancy cross-platform graphical debugger.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Mar 08, 2007 4:22 pm Post subject: |
|
Talbain wrote: |
Supposing that hacks could be used, there certainly haven't been any that I've heard that sound accurate. |
Are you saying that you have used emulators in which you know what specific hacks are being used and how they relate to the audio of a specific game?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Mar 08, 2007 5:03 pm Post subject: |
|
Your latest build gets 110 fps on my rig.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 08, 2007 5:19 pm Post subject: |
|
Quote: |
Your latest build gets 110 fps on my rig. |
Give me time v_v;
Quote: |
Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz x2 @ 4150 MHz |
o.O
Is that air cooled?
|
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 5:37 pm Post subject: |
|
Jipcy wrote: |
Talbain wrote: |
Supposing that hacks could be used, there certainly haven't been any that I've heard that sound accurate. |
Are you saying that you have used emulators in which you know what specific hacks are being used and how they relate to the audio of a specific game?
|
To a limited extent, yes. But this is mostly because most emulators I
have used have little released documentation; I simply know that some
games are using hacks in order to increase accuracy.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 08, 2007 6:09 pm Post subject: |
|
The
reality is that the majority of emulators for most systems are using
hacks (especially newer systems), though I don't think you have the
ability to personally tell as a casual emulation user :/ Try using
upx -d <file> && strings <file> > log. You'll
find game titles in many, many emulators. Again, nothing wrong with it
unless you specifically say that you're not using them. |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Thu Mar 08, 2007 6:53 pm Post subject: |
|
Talbain wrote: |
Jipcy wrote: |
Talbain wrote: |
Supposing that hacks could be used, there certainly haven't been any that I've heard that sound accurate. |
Are you saying that you have used emulators in which you know what specific hacks are being used and how they relate to the audio of a specific game?
|
To a limited extent, yes. But this is mostly because most emulators I
have used have little released documentation; I simply know that some
games are using hacks in order to increase accuracy.
|
...to increase compatibility.
using a hack to increase accuracy is an oxymoron.
as an aside, i'm really glad that there are still dedicated programmers on the snes emulation scene.
_________________
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Mar 08, 2007 7:08 pm Post subject: |
|
byuu wrote: |
Quote: |
That's
a really small tradeoff and I don't see why you should need to keep
anomie's in addition to blargg's. I'll pin my own hopes on you getting
that bit of speed back with optimizations. It's just my luck that I'd
be dipping to 59 on certain scenes. I knew I should have gotten the
e6400... |
Nah, you really shouldn't need such a powerful processor. It's my fault
for putting code integrity completely over speed. I should be able to
get back a couple of recent slowdowns.
|
Personally, I love the concept of selectionable cores and if like you said
Quote: |
I'll
leave the decision on which core to enable by default to you guys.
Eventually, I'll have polymorphism fully functional, and this will be a
runtime-selectable option, and not require two separate builds |
you're able to select any of them, I think it's a great compromise.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Mar 08, 2007 7:10 pm Post subject: |
|
Quote: |
using a hack to increase accuracy is an oxymoron. |
Using hacks to get a games running better is a perfectly reasonable and
accuracy-improving thing to do if your goal is to be a game emulator (for example, Nintendo's Virtual Console).
A console emulator, on the other hand, should be concerned only with
what the hardware does, not what games happen to do with the hardware.
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 7:40 pm Post subject: |
|
byuu wrote: |
The
reality is that the majority of emulators for most systems are using
hacks (especially newer systems), though I don't think you have the
ability to personally tell as a casual emulation user :/ |
Maybe not whether they're hacks all the time, but I can certainly tell
the difference between what is accurate and what is not, regardless of
hacks. There are many that I somewhat "assume" to be hacks simply
because of the fact that even to a casual emulation user, the
information gets passed down on what's working and how; and the hacks
are usually the first to be put into these types of categorization.
The unfortunate consequence of this however is that misinformation is
usually quicker to spread than correct information. This is just my
observation on the whole though, and case by case it may be different.
Also, byuu, this is just my opinion, but I'm not really a huge fan of
the selectable cores idea. Somehow I picture that in the future the
cores will diverge and then basically a choice will be made, and there
may be lots of code, implemented or unimplemented, that will have to be
trashed or re-arranged in order to accommodate the selected core. I
dunno... I just kinda foresee a lot of potential problems for this
(such as whether or not both cores work the same way, whether or not
one will get more focus than the other...), but it's up to you. Just
thought I'd toss in my two cents.
Last edited by Talbain on Thu Mar 08, 2007 7:48 pm; edited 1 time in total
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Mar 08, 2007 7:45 pm Post subject: |
|
blargg wrote: |
Using
hacks to get a games running better is a perfectly reasonable and
accuracy-improving thing to do if your goal is to be a game emulator
(for example, Nintendo's Virtual Console |
Agree. If the goal is only to preserve the games themselves. you could see some innacurate emulators as being game-preserving
in many cases, as opposed to hardware-documenting. Nothing inherently
wrong with it I guess. From an "historical" perspective it's better
than losing the game forever. *edit: and yes, if an hack makes a game
look and sound closer to the original you have indeed raised the
'game''s accuracy, so to speak.
Of course, I'm
still highly in favor of hardware-accurate emulators, and against
hacks. If only because hardware-accurate emulators also makes better
"game-emulators" programs due to their nature.
Sort of like how *thinking of an analogy* how...errr...better...errr...
water...makes...errr...better wine. (Okay that was awful)
edit above:*
Last edited by Snark on Thu Mar 08, 2007 8:10 pm; edited 2 times in total
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 7:50 pm Post subject: |
|
Snark wrote: |
blargg wrote: |
Using
hacks to get a games running better is a perfectly reasonable and
accuracy-improving thing to do if your goal is to be a game emulator
(for example, Nintendo's Virtual Console |
Agree. If the goal is only to preserve the games themselves. you could
see some innacurate emulators as being game-preserving
in many cases, as opposed to hardware-documenting. Nothing inherently
wrong with it I guess. From an "historical" perspective it's better
than losing the game forever.
Of course,
I'm still highly in favor of hardware-accurate emulators, and against
hacks. If only because hardwre-accurate emulators makes better
game-preserving/game-emulators programs.
|
That's one way to look at it, but when it can't work without a hack,
sometimes you just have to accept the lesser of two evils. Losing it
altogether or getting it working with a hack. Thankfully, there are not
many problems with that for the SNES because there are so many SNES
emulators, but it's certainly a possibility.
Unfortunately for me, my wanting an accurate emulator is somewhat
juxtaposed with my idea of wanting an emulator that can play games. If
this idea seems odd, think about it from the perspective of one who
doesn't have an extremely fast computer.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Mar 08, 2007 8:41 pm Post subject: |
|
Talbain wrote: |
Unfortunately
for me, my wanting an accurate emulator is somewhat juxtaposed with my
idea of wanting an emulator that can play games. If this idea seems
odd, think about it from the perspective of one who doesn't have an
extremely fast computer. |
You might just want to stick with ZSNES for right now. As far as I
understand it, byuu will never add game-specific hacks to bsnes. Also,
ZSNES, is much faster.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
Posted: Thu Mar 08, 2007 9:31 pm Post subject: |
|
Jipcy wrote: |
Talbain wrote: |
Unfortunately
for me, my wanting an accurate emulator is somewhat juxtaposed with my
idea of wanting an emulator that can play games. If this idea seems
odd, think about it from the perspective of one who doesn't have an
extremely fast computer. |
You might just want to stick with ZSNES for right now. As far as I
understand it, byuu will never add game-specific hacks to bsnes. Also,
ZSNES, is much faster.
|
I'm actually currently using snesgt. It seems to have the leanest code
and the most working games. It's Windows only though and closed-source.
Also, the info given by gigo and hii is rather sparse as to what
they're doing with it. Maybe they'll implement blargg's sound core
somehow, as the graphical core looks great. Toss in cheat support and
you've got just about everything I could think of for an emulator
(aside from an emulator used for romhacking purposes).
But hey, I'm just pipe-dreaming right now. I sincerely hope to see
blargg's sound core implemented as the standard, because right now, it
really is the most accurate I've heard amongst emulators; and I've
heard a lot.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 08, 2007 10:36 pm Post subject: |
|
I
really do like blargg's analogy. The problem is that the first word
always tends to get dropped, and people refer to programs as just
'emulators'. The exact same problem occurs with 'free software'. Free
what? Free to use and distribute? Free to modify and redistribute? Free
to use the work in a proprietary application? Not even the "free" GPL
grants all freedoms, nor does public domain software. It's a
compromise, and the term needs a qualifier to say what exactly is meant
by free.
We can either take Stallman's approach
and try and proselytize the terms emulator and simulator to mean
something they don't, or we have to, as a community, make a collective
effort to qualify what we mean by emulator when we refer to them.
But I agree, I'm totally and utterly fine with the concept of a game
emulator. I just got sick and tired of my fan translations breaking for
unexpected reasons in emulators but not on hardware. This was because
there was only one viable hardware emulator at the time, SNEeSe, which
lacked a critical debugger needed for said translations. It also at the
time was unable to perform even color add/sub. I'm happy to say SNEeSe
is now extremely usable in all respects. Calling both the old ZSNES and
SNEeSe the same thing urked me, and has been the source of a lot of
snide comments I've made that have unfortunately upset a lot of people
I respect in the community :/
But now, it looks like even ZSNES is moving in the direction of being a
hardware emulator, so I guess my point is now moot. A shame, I had
really grown to like our symbiotic relationship of having one shining
example of a game emulator focused on features and compatibility, and
another of a hardware emulator, focused on raw accuracy. Now we just
have a blend, as both of our primary objectives have become dilluted
over time. ZSNES focusing more on accuracy at the cost of (some) speed,
me focusing more on frivilous stuff like GUIs, video filters, special
chips and not pursuing massive tradeoffs like the ~10.2mhz S-PPU
renderer.
Quote: |
That's one way to look at it, but when it can't work without a hack, sometimes you just have to accept the lesser of two evils. |
And this is why we still don't have the SPC7110 decompression algorithm
reverse engineered. We found a hack to get the games running now, and
so nobody has any motivation to fix it properly. Same for the Uniracers
bug that absolutely nobody knows how to fix. Same for why it took us
nearly a decade for someone to finally put Razoola in his place and
crack CPS2. I can think of nothing more detrimental to progress than
hacks, they put off the problems, not solve them.
Quote: |
Maybe they'll implement blargg's sound core somehow, as the graphical core looks great. |
He could, but he'd be violating the LGPL unless he used a dynamically
linked library version of it, and included blargg's source with his
emulator.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Mar 08, 2007 11:00 pm Post subject: |
|
Yes that is on air cooling using Intel's HSF.
_________________
Watering ur plants. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 09, 2007 12:14 am Post subject: |
|
byuu wrote: |
so you can reclaim all 30 of my users. |
Lol Even with Zsnes' recent accuracy improvements (which I applaud) I
doubt we'll see it reaching the same level of accuracy as bsnes for a
long, long time. (and besides, wouldn't it become just as slow as bsnes
if it ever reach that level? which would destroy the point of being a
fast emulator in the first place anyway)
So I think it's a wee-bit early to call bsnes near evolution extinction :P
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 09, 2007 12:24 am Post subject: |
|
Snark wrote: |
Personally, I love the concept of selectionable cores and if like you said
Quote: |
I'll
leave the decision on which core to enable by default to you guys.
Eventually, I'll have polymorphism fully functional, and this will be a
runtime-selectable option, and not require two separate builds |
you're able to select any of them, I think it's a great compromise.
|
You really think that a 3% performance hit is worth keeping a lesser
core in the code and offering it as an option? Anomie's served us well,
but it's been completely superceded by blargg's.
A core option will make sense when S-PPU drops performance 50%.
Snark wrote: |
Lol Even with Zsnes' recent accuracy improvements (which I applaud) I
doubt we'll see it reaching the same level of accuracy as bsnes for a
long, long time. (and besides, wouldn't it become just as slow as bsnes
if it ever reach that level? which would destroy the point of being a
fast emulator in the first place anyway) |
byuu's just being his self-deprecating self again. Simply put, if you
have the power to run it, and don't care about savestates, bsnes is
money. No other SNES emulator has a better gui or accuracy rate on
games. .020's portability and uniformity between ports will just be
another feather in its hat.
Last edited by FitzRoy on Fri Mar 09, 2007 12:48 am; edited 1 time in total
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 09, 2007 12:37 am Post subject: |
|
FitzRoy wrote: |
Snark wrote: |
Personally, I love the concept of selectionable cores and if like you said
Quote: |
I'll
leave the decision on which core to enable by default to you guys.
Eventually, I'll have polymorphism fully functional, and this will be a
runtime-selectable option, and not require two separate builds |
you're able to select any of them, I think it's a great compromise.
|
You really think that a 3% performance hit is worth keeping a lesser
core in the code and offering it as an option? Anomie's served us well,
but it's been completely superceded by blargg's.
A core option will make sense when S-PPU drops performance 50%.
|
I suppose a 3% performance drop would indeed not justify the option,
although I would wait for byuu to re-integrate the fps counter to
confirm the drop is indeed only around 3%...Because it feels like more.
Like I mentionned, it's the first time ever I can't reach 60/60
regardless of option selected... (i.e: even with 9 frameskip) Of
course, my cpu is not that powerful to begin with either (middle range
P4)
edit: then again. and not to start an argument but I personally see no
harm in having both anomie and blargg's core into one .exe.
Anyway, whatever byuu decide I'll have no problem with it either way.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 09, 2007 1:00 am Post subject: |
|
FitzRoy wrote: |
byuu's just being his self-deprecating self again. |
yup 
Quote: |
Simply
put, if you have the power to run it, and don't care about savestates,
bsnes is money. No other SNES emulator has a better gui or accuracy
rate on games. .020's portability and uniformity between ports will
just be another feather in its hat. |
With no disrespect to the Zsnes team, accuracy issues aside, from a
user perspective the biggest problem with Zsnes has always been the bug
regression problem...and I guess the shear number of them (one only
needs to look at the bug report page for confirmation)
Although, 1.60 should be interesting. It looks like it's finally heading towards a better direction.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 1:07 am Post subject: |
|
Snark wrote: |
With
no disrespect to the Zsnes team, accuracy issues aside, from a user
perspective the biggest problem with Zsnes has always been the bug
regression problem...and I guess the shear number of them (one only
needs to look at the bug report page for confirmation)
Although, 1.60 should be interesting. It looks like it's finally heading towards a better direction. |
The fact that emulation in general is like this, this is rather insulting.
_________________
FF4 research never ends for me.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 09, 2007 1:15 am Post subject: |
|
Modularity
or em, polymorphism? is always a good thing, if not for speed then from
a programmer's point of view; that is, clean, readable code, being able
to work on a component without having to worry about it breaking
something that should be unrelated, et cetera. As byuu has said, of
course. I agree that Blargg's core is the way to go if it should be a
choice, but better if it isn't. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 09, 2007 1:23 am Post subject: |
|
Deathlike2 wrote: |
Snark wrote: |
With
no disrespect to the Zsnes team, accuracy issues aside, from a user
perspective the biggest problem with Zsnes has always been the bug
regression problem...and I guess the shear number of them (one only
needs to look at the bug report page for confirmation)
Although, 1.60 should be interesting. It looks like it's finally heading towards a better direction. |
The fact that emulation in general is like this, this is rather insulting.
|
Sorry if I came off as lacking respect, this was certainly not my intention.
I was simply giving the reason why imo, some users might have made the switch from Zsnes
Last edited by Snark on Fri Mar 09, 2007 1:30 am; edited 4 times in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 1:24 am Post subject: |
|
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
Quote: |
.020's portability and uniformity between ports will just be another feather in its hat. |
That remains to be seen... the portability part specifically.
Snark wrote: |
Deathlike2 wrote: |
Snark wrote: |
With
no disrespect to the Zsnes team, accuracy issues aside, from a user
perspective the biggest problem with Zsnes has always been the bug
regression problem...and I guess the shear number of them (one only
needs to look at the bug report page for confirmation)
Although, 1.60 should be interesting. It looks like it's finally
heading towards a better direction. |
The fact that emulation in general is like this, this is rather insulting.
|
Sorry if I came off as lacking respect, this was certainly not my intention.
I was simply giving the reason why imo, some users might have made the switch from Zsnes to bsnes.
|
You do realize you are under no specific obligation to use one
emulator, or one particular version of ZSNES as has been said many many
times.
_________________
FF4 research never ends for me.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 09, 2007 1:40 am Post subject: |
|
Let's
not treat eachother with an air of hostility here. Byuu's work on a
library unifying the Win32 API and the GTK+ API seems to be coming
along well, and that will ensure portability atleast so far as Linux is
concerned. Opinions about GUIs differ, but let's not get upset about
stating opinion like fact - just add a mental 'to me'! From the other
posts I've read, I don't think anyone is trying to offend. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 1:50 am Post subject: |
|
Verdauga Greeneyes wrote: |
Let's
not treat eachother with an air of hostility here. Byuu's work on a
library unifying the Win32 API and the GTK+ API seems to be coming
along well, and that will ensure portability atleast so far as Linux is
concerned. |
There is nothing wrong with what byuu is doing to make it happy on all
ports.. but I've also already read some really silly opinions and
conclusions based on the "difficulty of supporting linux". On the other
hand, IIRC there was a specifically a thread on compiling BSNES in
Linux out of the box.. I'm sure it will be successful, but just
something that needs to be noted when it is near completion.
Quote: |
Opinions
about GUIs differ, but let's not get upset about stating opinion like
fact - just add a mental 'to me'! From the other posts I've read, I
don't think anyone is trying to offend. |
It helps to add in IMO, because that's exactly what it is IMO. I've
seen too many things that get spouted "as fact" unfortunately.
_________________
FF4 research never ends for me.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 09, 2007 1:51 am Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
Quote: |
.020's portability and uniformity between ports will just be another feather in its hat. |
That remains to be seen... the portability part specifically.
Snark wrote: |
Deathlike2 wrote: |
Snark wrote: |
With
no disrespect to the Zsnes team, accuracy issues aside, from a user
perspective the biggest problem with Zsnes has always been the bug
regression problem...and I guess the shear number of them (one only
needs to look at the bug report page for confirmation)
Although, 1.60 should be interesting. It looks like it's finally
heading towards a better direction. |
The fact that emulation in general is like this, this is rather insulting.
|
Sorry if I came off as lacking respect, this was certainly not my intention.
I was simply giving the reason why imo, some users might have made the switch from Zsnes to bsnes.
|
You do realize you are under no specific obligation to use one
emulator, or one particular version of ZSNES as has been said many many
times.
|
Yes, and it wasn't my goal to say one emulator is better than the
other. One might be prefered by some, another one by other users, some
will even use both, it's all good.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 09, 2007 2:02 am Post subject: |
|
Quote: |
You
really think that a 3% performance hit is worth keeping a lesser core
in the code and offering it as an option? Anomie's served us well, but
it's been completely superceded by blargg's. |
The fun thing about polymorphism is that there is no speed loss in
having anomie's core alongside blargg's, other than the initial
polymorphism hit which is ~10% for all four cores, ~1% for the DSP
alone. It does benefit us in the meantime, as we have not tested all
4,000 games with blargg's S-DSP core yet, and this gives us a point of
comparison. If you all really want it removed just because it takes up
hard drive space, I'll be willing to consider that for v0.021 and above
...
Re: ZSNES discussion,
The above comment is equally impolite to anomie's work, as the comments that Deathlike has taken offense to.
Unfortunately, this is just the way emulation is. I can guarantee you
that if someone pops up tomorrow with something more accurate than
bsnes, I'll get the same negative comments. And if you go to a thread
discussing speed, features or total compatibility, of which I could
link you at least a dozen if not for me clearing my referrals daily,
you'll see even more condescending topics about my work compared to
ZSNES. We all get the flack, and believe it or not, but I get a lot
more as the little guy. My site doesn't have 30 million hits, but more
like 80,000. I'm really deeply sorry if my attitude encourages this
negative behavior, but it's just that I'm very frank in what I say, and
am quick to point out in what I believe. One thing I don't do, as it is
impractical, is add "this is a personal opinion, but ..." before
everything I mention. However, I hope that it's implied. I realize my
opinion is in the extreme minority, of roughly 0.1% of emulator users.
That doesn't mean it's right or wrong, but it's extremely far from
popular opinion, and should not be taken as being insulting nor as fact.
The biggest problem, is that this is the ZSNES boards. The ZSNES
authors should not have to take flack from anyone posting here. The
unfortunate thing is that if I want a board, I want to personally
control it on my domain. And to do that, means I'll have to write my
own. And to do that, takes time away from emulator development. I don't
want to spend 3 weeks writing a nice board, nor do I want to use
someone else's prepackaged board.
But back to the point, people will always attack things. Look how
quickly anomie's work came under fire. It was compared to SNEeSe, the
holy grail at the time of S-DSP emulation. And now it's deemed a lesser
core that has been completely superceded. Give it time and you'll see
even greater insults to anomie's work. This is just the way everyone is.
I may be a pessimist and self-defeating, but I do see ZSNES' steps
forward as a huge push toward catching up to my work. And while I
applaud that wholeheartedly, I see myself losing interest when my work
is no longer useful to anyone, and I hope that pagefault will then pick
up the torch and continue furthering emulation outside the friendly
"threat" of competition. I won't say SNES emulation stagnated from
98-04, but I will say very clearly that it was a whole hell of a lot
slower than it is currently. I'd like to think that will continue with
or without my presence.
I don't really have any answers to the above problems. Let's just say
that this is ZSNES' board, and despite my negative comments, I really
truly deeply have the utmost of respect for everyone involved in the
project, and I truly am not trying to, nor want to, compete with any of
them.
If not for ZSNES, you would not have
a 100% English translation of Der Langrisser coming out sometime this
year. You would not have my Dragon Quest 5 translation, Tekkaman Blade
translation, or possibly many other high-profile translations I've
helped with in the background. You would not have xkas. You would not
have bsnes. I would've never gotten so attached to this little console
without ZSNES being there back when I first got into computing. So once
again, please accept my apologies for the negative comments, both from
me and from others.
I will eventually get around
to making that message board, so that at least you guys don't have to
hear the negative comments on your own board. But they won't stop,
unfortunately. Not for any of us. I can't even help myself from saying
these things sometimes. Likewise, I will understand, and encourage you
guys, to be just as vocal about my flaws. I'm totally deserving of
that, and fair is fair.
A good one you just hinted at, Deathlike. I get totally pissed off and
complain loudly when I'm not able to figure something out with
"reasonable" effort. Yes, this includes a lot of Linux stuff that I go
off on obscure rants about. Same thing with regression bugs, man those
set me off. It just helps me to vent frustration somewhere, I guess. It helps to know someone's listening to me. But it is very childish.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 09, 2007 2:14 am Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say that "ZSNES is the best!"
|
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 2:17 am Post subject: |
|
byuu wrote: |
Re: ZSNES discussion,
The above comment is equally impolite to anomie's work, as the comments that Deathlike has taken offense to. |
I think progress is very important, even if the end result wasn't
perfect. The fact there is some previous research and insight put into
work that may not have been accurate, no less imperfect.. it doesn't
mean all their previous work was crap or done in vain. We are only
limited to what we understand, and although we thank blargg for putting
in the time and effort to update the research into the sound core... do
not ever take previous work for granted. This will happen with all
emulation that has yet to be perfected (N64 or PSX emulation for
example). Don't take what we have today to be perfect, for tomorrow,
something new may be discovered. It is best to say, that we know more
than we did yesterday and be happy there is still research on the SNES
being done here. I cannot speak for other "supposedly perfected" NES or
Genesis emulation, but I'm sure there is still more to figure out...
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say that "ZSNES is the best!"
|
For a thought: Noone said you couldn't say BSNES is the best. On the other hand, this is what board again?
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Fri Mar 09, 2007 2:21 am; edited 1 time in total
|
|
Talbain Rookie

Joined: 24 Feb 2005
Posts: 14
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 09, 2007 2:32 am Post subject: |
|
Ugh, what the hell did they do to poor Dragonforce?? ;_;
Dragonforce rocks your fucking socks.
Man, that game stuck a lot of good bands in it. Of the two bands I know
that have songs in it (the other being All That Remains), both
positively kick total ass :D |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 09, 2007 2:43 am Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say that "ZSNES is the best!"
|
For a thought: Noone said you couldn't say BSNES is the best. On the other hand, this is what board again?
|
My point is that opinions often get said without "IMO" attached. This
is the "Emulators" section of the zsnes forum, btw. There's nothing
wrong with what I said or where I said it. All I know is that nothing
is safe until bsnes has its own forum.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 2:55 am Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say that "ZSNES is the best!"
|
For a thought: Noone said you couldn't say BSNES is the best. On the
other hand, this is what board again?
|
My point is that opinions often get said without "IMO" attached. This
is the "Emulators" section of the zsnes forum, btw. There's nothing
wrong with what I said or where I said it. All I know is that nothing
is safe until bsnes has its own forum.
|
That may be true, but other comments you have made make absolutely no
sense (and are incorrect) as well. I'm just letting you know.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 09, 2007 3:11 am Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say
that "ZSNES is the best!"
|
For a thought: Noone said you couldn't say BSNES is the best. On the
other hand, this is what board again?
|
My point is that opinions often get said without "IMO" attached. This
is the "Emulators" section of the zsnes forum, btw. There's nothing
wrong with what I said or where I said it. All I know is that nothing
is safe until bsnes has its own forum.
|
That may be true, but other comments you have made make absolutely no
sense (and are incorrect) as well. I'm just letting you know.
|
You mean how I was "impolite" to anomie's work and "took it for
granted." *sigh* It was a compliment followed by a fact (if I
understand it enough). There is nothing that anomie's core can do that
blargg's can't. I thought that including anomie's might be redundant
because of that. It implies nothing about the superiority of the person
or the respect of previous work. I only used the word "lesser" because
I don't recall off hand the cycle/opcode whatever description for each.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 09, 2007 3:28 am Post subject: |
|
Mmm, please don't get my thread locked, guys ;_;
So close to the 100 pages mark. So close, indeed ...
Quote: |
You mean how I was "impolite" to anomie's work and "took it for granted." |
Not what I was meaning, either, btw. It just seems mean to me to want
to immediately drop anomie's work the second something technically
better comes along. Though I also appreciate blargg's hard work. It's a
difficult thing for me, as I respect both of them very much for all
they've done to help me (and everyone else), and want to show my thanks
to both. If it helps explain my comment better, imagine this from my
perspective in which I think of them both as friends. I've no problem
trying my own works by fire (eg bCPU / bSMP), but have difficulty doing
that to code that was graciously given to me, free of charge.
A little more direct than even I can be sometimes, but you're right.
It's technically superior, and that's what this game is about. Let's at
least allow one public release with blargg's core as primary before we
remove anomie's, just in case we're missing some bugs here. blargg's
also isn't technically complete yet, he is still researching the DSP,
as far as I know.
I don't see any
reason to remove the source code for it, though. At the very least, it
provides a nice eloquent simplified model of the S-DSP for research
purposes.
Last edited by byuu on Fri Mar 09, 2007 3:36 am; edited 2 times in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 3:29 am Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
No other SNES emulator has a better gui... |
Already inserting opinions as fact?
|
Funny you never say anything when people come in zsnes talk and say
that "ZSNES is the best!"
|
For a thought: Noone said you couldn't say BSNES is the best. On the
other hand, this is what board again?
|
My point is that opinions often get said without "IMO" attached. This
is the "Emulators" section of the zsnes forum, btw. There's nothing
wrong with what I said or where I said it. All I know is that nothing
is safe until bsnes has its own forum.
|
That may be true, but other comments you have made make absolutely no
sense (and are incorrect) as well. I'm just letting you know.
|
You mean how I was "impolite" to anomie's work and "took it for
granted." *sigh* It was a compliment followed by a fact (if I
understand it enough). There is nothing that anomie's core can do that
blargg's can't. I thought that including anomie's might be redundant
because of that. It implies nothing about the superiority of the person
or the respect of previous work. I only used the word "lesser" because
I don't recall off hand the cycle/opcode whatever description for each.
|
I apologize for not being clearer. I was referring to your comments about Linux support.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 09, 2007 3:57 am Post subject: |
|
byuu wrote: |
A little more direct than even I can be sometimes, but you're right.
It's technically superior, and that's what this game is about. Let's at
least allow one public release with blargg's core as primary before we
remove anomie's, just in case we're missing some bugs here. blargg's
also isn't technically complete yet, he is still researching the DSP,
as far as I know. |
Yeah, sounds good. If it wasn't already apparent, I can be blunt to a fault sometimes.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 09, 2007 6:52 am Post subject: |
|
Deathlike2 wrote: |
I apologize for not being clearer. I was referring to your comments about Linux support. |
What about Linux support?

Hardware scaling for video with Xv, or software with GTK+.
Multiple supported sound drivers via libao (thanks, Nach!)
Input support, though sadly keyboard only through GTK+.
Most options directly accessible via menubar, many more via config
file. When the configuration panel is added back to the Windows port,
it will appear in the Linux port at the exact same time.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 09, 2007 2:45 pm Post subject: |
|
byuu wrote: |
Deathlike2 wrote: |
I apologize for not being clearer. I was referring to your comments about Linux support. |
What about Linux support?
|
That comment wasn't directed at you, but that does look impressive.
_________________
FF4 research never ends for me.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Mar 09, 2007 2:53 pm Post subject: |
|
Quote: |
The
fact there is some previous research and insight put into work that may
not have been accurate, no less imperfect.. it doesn't mean all their
previous work was crap or done in vain. |
I am very grateful to everyone who's done research, documentation, and
implementation of all the systems I've done further research on (NES
and SNES). Without this I wouldn't have had anything to start with.
Regarding which sound core to use, only technical issues should be
considered. It's not an awards ceremony, it's an emulator. I've been
talking with byuu and he wants to write his own DSP to replace both
mine and anomie's, and I plan on helping him as much as I can with
information and test code to verify that it's working.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 09, 2007 4:15 pm Post subject: |
|
Quote: |
Regarding which sound core to use, only technical issues should be considered. It's not an awards ceremony, it's an emulator. |
Yes, you're right. It's my own hangup, but I'll get over it.
Quote: |
I've been talking with byuu and he wants to write his own DSP to replace both mine and anomie's |
Oh, I don't have any intentions of replacing your core.
There's a couple of reasons for wanting to write my own:
1) It's the only part of the SNES I haven't personally emulated, so I
haven't technically written a complete emulator yet myself.
2) I want to understand exactly how the S-DSP works. Both so I can fix
bugs should they arise, and so I can implement a BRR audio streamer for
use in fan translations I work on.
3) To reverify research, and hopefully write documentation on it as good as all of my other tech docs (hahahahahahahaha).
4) I do eventually want to release my core as a work of the public
domain, either when bsnes is discontinued or when I eventually consider
it "complete". I would need to remove any licensed code, regardless of
how reasonable the license is, for that to happen. Note that I do
consider the LGPL very reasonable, in fact it's probably one of my
favorite after BSD-style licenses; and I do completely respect others'
licenses. But again, even a single clause means I do not have control
to release my project as a work of the public domain in the future.
Anything I write is absolutely guaranteed to be much slower, and given
you haven't sacrified a drop of accuracy for speed, there's absolutely
no way I can beat you on the speed front, so there's no reason not to
use your core in official releases.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Mar 11, 2007 4:25 am Post subject: |
|
You
can always change the LGPL to avoid forking... We did with ours to only
apply to verison 2 of the license. The default allows for all licenses
even v3 to be used.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 12, 2007 9:49 am Post subject: |
|
Ok,
I've been saving up my money since I got my Athlon 3500+ for a dual
core processor. Ended up going for Intel, as they have better chips at
the moment.
Finally had enough money to pick up
a Core 2 Duo E6600 + eVGA 680i mainboard, and subsequently ended up
spending ~$200 over budget. Way, way too much for a mainboard. Really
wanted that nForce chipset, though. Proprietary or not, I'm a huge fan
of nVidia's driver quality.
Unfortunately, went with the stock heatsink. Horrible quality, nearly
broke my mainboard trying to install that thing (apparently Intel has
not heard of `screws' before). Runs at 40c idle, 55-60c max load, even
with my very, very generous airflow case (even the mainboard chipset
has its' own fan). Whatever, it works. If I ever choose to overclock
it, that fan will have to go. Does anyone have experience with
third-party LGA775 coolers? Do they have more competent mounting
systems? I'd really like a screw design, even if I have to use a bolt
on the bottom side of the mainboard.
I was in shock, I actually got Windows to boot up after switching
mainboards and didn't have to reinstall everything. FreeBSD actually
turned out to be the loser. Network and audio are no longer working
there, same exact PCI cards for both. First time for everything, I
suppose.
Here's a screenshot with the kind of performance I'm getting at stock 2400mhz and bargain 533mhz DDR2:
Desktop
I'm very impressed, but not exactly floored. I shall have to look into
multithreaded programming so I can offload video filtering to the
second core or something.
Quote: |
You
can always change the LGPL to avoid forking... We did with ours to only
apply to verison 2 of the license. The default allows for all licenses
even v3 to be used. |
Easier to just make my own license. My current mood is that I want to
clean up the core, and release that as public domain. Leave the ui as
"proprietary" as some FSF cult members would call it. If someone wants
to make a UI just to add in hacks or fork it, whatever. At least
they'll have to put in some effort. I'm kidding myself thinking anybody
would even want to fork my work anyway: much better emulators they can
already do that with.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Mar 12, 2007 12:43 pm Post subject: |
|
byuu wrote: |
Ok,
I've been saving up my money since I got my Athlon 3500+ for a dual
core processor. Ended up going for Intel, as they have better chips at
the moment.
Finally had enough money to pick
up a Core 2 Duo E6600 + eVGA 680i mainboard, and subsequently ended up
spending ~$200 over budget. Way, way too much for a mainboard. Really
wanted that nForce chipset, though. Proprietary or not, I'm a huge fan
of nVidia's driver quality.
Unfortunately, went with the stock heatsink. Horrible quality, nearly
broke my mainboard trying to install that thing (apparently Intel has
not heard of `screws' before). Runs at 40c idle, 55-60c max load, even
with my very, very generous airflow case (even the mainboard chipset
has its' own fan). Whatever, it works. If I ever choose to overclock
it, that fan will have to go. Does anyone have experience with
third-party LGA775 coolers? Do they have more competent mounting
systems? I'd really like a screw design, even if I have to use a bolt
on the bottom side of the mainboard.
|
http://www.newegg.com/Product/Product.asp?Item=N82E16835106061
The BigTyphoon is probably what I would consider one of the best air
cooling HSF units on the market today. I own one. It's nearly silent
and cools about as good as you can possibly expect from an air cooling
unit.
I use it on an AMD X2, but it says it works with LGA775 as well. I know
it came with all sorts of hookup options. I don't have a Core Duo setup
to confirm. It screws to the bottom of the board.The only drawback is
you need a mid size tower to accommodate 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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 12, 2007 1:30 pm Post subject: |
|
If you're looking for something a little less monstrous, I recommend the Zalman CNPS7700-Alcu.
I'm hoping there's still some performance to be squeezed out of bsnes.
You're probably 10% away from assuring anyone with Core 2 architecture
at least 60fps, including the E4xxx line, which simply has
virtualization taken out. That's a good goal to have as people
eventually upgrade from netburst. I don't really know what the AMD
minimum is right now for bsnes. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 12, 2007 2:01 pm Post subject: |
|
Best tested coolers today are (in order):
ThermalRight Ultra-120 Extreme (not yet released)
ThermalRight Ultra-120
SunBeam Tuniq Tower (somewhat noisier than the ThermalRight with a good
fan, but equal in cooling performance and comes with its own in the
first place)
All of them are about as good as a cheap water-cooled solution. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 12, 2007 3:02 pm Post subject: |
|
Need something from:
http://microcenter.com/byos/byos_search_results_e.phtml?coordinate_group=HJ1B
I'm thinking I want:
http://microcenter.com/byos/byos_single_product_results.phtml?product_id=0253017
It says it's for P4 only, but it's LGA 775 and I've read reviews from
two people using it on Core 2 Duos. They have the same exact form
factor and heat spreader, so it should be fine.
I really like the way it uses the new "screw technology" (tm). Very nice touch.
I really don't want one of those big 800gm monster tower fans, though
I'm not entirely opposed to the big wheel ones, so long as they fit in
my case. It's Mid-atx, but I'd rather not have to take off my cases'
wind tunnel thing. It's basically a pipe that goes on top of the
processor to get airflow outside, I have about 3-4" clearance with it
on to the stock HSF. Also, no push pin bs, please.
Has anyone had to remove a thermal pad from an LGA 775 before? When I
tried to remove the stock one from my AMD, I almost killed it. Didn't
realize it was like cement, and yanked the processor right out the
socket. Now, I know the LGA 775 is pinless and
has that shield over it that's locked in place. Is this a non-issue
now, or should I do some wiggling first to break up the cement maybe?
Quote: |
I'm
hoping there's still some performance to be squeezed out of bsnes.
You're probably 10% away from assuring anyone with Core 2 architecture
at least 60fps, including the E4xxx line, which simply has
virtualization taken out. That's a good goal to have as people
eventually upgrade from netburst. I don't really know what the AMD
minimum is right now for bsnes. |
I can get 10% with the desync code for CPU<>SMP. It will raise
the required audio latency a little. I can probably get most of that
back by moving back down to a two-stage ring buffer.
After that, I can get back into profiling and optimizing stuff. I need
to learn blargg's secret. He can reduce bit operations to 1/3rd the
operations I need for everything he touches.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Mar 12, 2007 3:31 pm Post subject: |
|
Going
with the nvidia chipset was a bad idea if you wanted to overclock, the
P965 does a lot better job at this. But if you are stuck with it you
should find it will work well at stock speed.
_________________
Watering ur plants. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 12, 2007 6:02 pm Post subject: |
|
Are
you sure about that, pagefault? Reviews tell me you should expect
atleast a 450 MHz FSB overclock.. with the default multiplier, that
would be an overclock from 2.4 GHz to 4.06 GHz.. if you get that on air
cooling, you're very lucky. (yes, pagefault, I think you are very lucky
) |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Mar 12, 2007 7:31 pm Post subject: |
|
byuu,how many fps do you get (in that same scene in Z3:LTTP) with the 019.19 build on your old AMD machine?
Also,was there any significant changes between wip17 and wip19 performance-wise?
I'm asking this because I find even the E6600 a small step forward from
a 4-year old machine for single-threaded apps.A bit disappointing 
I also find it strange how your 3500+ gets only 60fps.
(I get solid 60fps here on a 4-yr old AMD XP2200+ at stock speed with wip17)
There was very little progress in the last 4 years in raw (single-threaded) performance.
If you don't overclock,you're not getting much bang for the buck out of these Core2Duo 'beasts'. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Mar 12, 2007 9:26 pm Post subject: |
|
Is
it possible to log the bsnes output (of the latest WIP with blargg's
DSP) as a 32040Hz WAV? (currently it's locked at 32000Hz even if I set
the rate to 32040Hz in the cfg)
Last edited by kick on Mon Mar 12, 2007 9:29 pm; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Mar 12, 2007 9:29 pm Post subject: |
|
OT:
I brought a Snes recently, and would like to get a copier or any device
that allows one to play (insert excessive ammount of "airquotes" here)
""backups""
byuu, Fitzroy, tetsuo what do you guys
have and what would you recommend? I guess price would be number 1
factor here..as long as the unit is not complete sh** of course. And
since I'm not an emulator author or rom hacker, I don't really mind if
the unit has some nasty habit of messing up some memory address values
at start up or stuff like that. |
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Mon Mar 12, 2007 9:47 pm Post subject: |
|
Snark: the cheapest (but nonethless still nice) option may be to "back up" your games on a flash cart...
http://www.tototek.com/ - hardware section.
Edit: oops, sold out. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Mar 12, 2007 9:58 pm Post subject: |
|
kick wrote: |
Is
it possible to log the bsnes output (of the latest WIP with blargg's
DSP) as a 32040Hz WAV? (currently it's locked at 32000Hz even if I set
the rate to 32040Hz in the cfg) |
Hexedit the WAV file, change the 32000 in the header, you'll find it near the top with a good hex editor.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Mon Mar 12, 2007 10:16 pm Post subject: |
|
Stifu wrote: |
Snark: the cheapest (but nonethless still nice) option may be to "back up" your games on a flash cart...
http://www.tototek.com/ - hardware section.
Edit: oops, sold out. |
Another option is to get one of the Game Doctor copiers, which Tototek
still has in stock. They're in Products->Backup Unit. I have an SF7,
and it's quite nice .
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Mar 12, 2007 11:23 pm Post subject: |
|
zidanax wrote: |
Stifu wrote: |
Snark: the cheapest (but nonethless still nice) option may be to "back up" your games on a flash cart...
http://www.tototek.com/ - hardware section.
Edit: oops, sold out. |
Another option is to get one of the Game Doctor copiers, which Tototek
still has in stock. They're in Products->Backup Unit. I have an SF7,
and it's quite nice .
|
Ok, thanks for the link.
I looked at their page and the prices are much cheaper than what I was
expecting (maybe the price dropped in recent years?)
I'm looking at the "Doctor SF3 (32M) for NTSC SFC"...Is there any
reasons I should NOT get this unit? I.e: is it considered bad quality?
The price IS very low (30$) for a backup unit...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 13, 2007 4:35 am Post subject: |
|
Wow,
just bought a $70 HSF. It was the only screw-based HSF Microcenter had,
other than an $80 one. The Zalman 9500 LED is the one I got. Very nice.
Idles at 30c, peaks at 40c. Only 5c gain at idle, but really how much
cooler can you get anyway? But at peak, it's a 20c gain. Not
overclocking anything. At least not until I have a need to, and I have
some better RAM. My paultry 533mhz ValueRAM will be the first to fail
me.
Very happy with this HSF. The backplate was
easy to install, but screwing the actual HSF into the backplate was
fairly difficult and scary. The HSF kept sliding with the Arctic Silver
5 and it really took a lot of force to get both screws in. But ... it's
in, and it's working great. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Mar 13, 2007 8:23 am Post subject: |
|
Good fanchoice Byuu,
Snark, the best copier unit is the Super wildcard DX 1 or 2.
However you should definately get the docter FS if its only 30 $ as 2nd had wildcard dx'es go for a much as 100$ |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Mar 13, 2007 8:27 am Post subject: |
|
its supposed to be scary, they need to hold over a pound worth of metal. the fanless ones weigh even more.
I got a 3800+ with stock HSF and I barely hear it.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Tue Mar 13, 2007 8:35 am Post subject: |
|
tetsuo55 wrote: |
Snark, the best copier unit is the Super wildcard DX 1 or 2. |
Where can one even find those copiers anymore? I don't see it listed
anymore on Rob Webb's page, and even when he had them, they were
extraordinarily expensive.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Mar 13, 2007 12:25 pm Post subject: |
|
byuu wrote: |
Wow,
just bought a $70 HSF. It was the only screw-based HSF Microcenter had,
other than an $80 one. The Zalman 9500 LED is the one I got. Very nice.
Idles at 30c, peaks at 40c. Only 5c gain at idle, but really how much
cooler can you get anyway? But at peak, it's a 20c gain. Not
overclocking anything. At least not until I have a need to, and I have
some better RAM. My paultry 533mhz ValueRAM will be the first to fail
me.
Very happy with this HSF. The backplate
was easy to install, but screwing the actual HSF into the backplate was
fairly difficult and scary. The HSF kept sliding with the Arctic Silver
5 and it really took a lot of force to get both screws in. But ... it's
in, and it's working great. |
That's pretty good. I don't get much lower than that with my X2. Just a
few degrees and the X2 runs cooler than the Core Duo anyway I believe.
Air cooling can only do so much no matter what you get.
You can actually see even more of a difference using speed stepping technology(such as cool'n'quiet for AMD).
_________________
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.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Mar 13, 2007 2:49 pm Post subject: |
|
zidanax wrote: |
tetsuo55 wrote: |
Snark, the best copier unit is the Super wildcard DX 1 or 2. |
Where can one even find those copiers anymore? I don't see it listed
anymore on Rob Webb's page, and even when he had them, they were
extraordinarily expensive.
|
I too have not seen one in a very long time.,
I got my DX1 about 6 months before the DX2 came out, i paid about 250$
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 13, 2007 3:40 pm Post subject: |
|
Thanks
everyone for help with fans, I only went with the Zalman because it was
the only one Microcenter had locally, and I hate mail ordering stuff.
So, I noticed you can angle this fan in any direction, and obviously
hot air rises. I have a standard mid-ATX case standing upright. I have
a northbridge fan (for eventual overclocking, for now it's just cold
air) that blows air directly up at the CPU, and helps to hit the Zalman
heatpipes. I also have a neat PSU that sucks air in from the bottom to
blow air out the back of the case. Now, typically everyone
out there installs their Zalman's to blow the air from the drive bay
area out the back of the case, but this seemed less efficient to me,
given my case layout. I know you're supposed to aim for continuous air
flow, so I went ahead and pointed my Zalman to pull air from below (the
NB fan) and push it upwards (to the PSU fan), so it acts like a wind
tunnel, having the air exit from the PSU exhaust.
Had I not had the PSU fan, this would obviously be a terrible choice as
the hot air would just hit the PSU and disperse back into the case, but
given the NB fan, it seems like if I aimed it to blow air out the back,
the NB air would hit the side of the Zalman and not do any good, and
then the PSU would be sucking in air that wasn't hot to begin with,
possibly even interfering with the Zalman airflow.
So, to visualize, the board is vertical and my Zalman is horizontal.
Air goes straight from the bottom to the top of the case, using three
fans, and out the PSU.
The NB should never really get hotter than 30-35c, so I'm not too
worried about blowing hot air onto the CPU in this regard. I'm also not
at all worried about overheating the PSU. I'm not a gamer and am only
pulling maybe 150w through this 400w PSU. The air out the back isn't
even hot, probably 6-10c above room temperature.
So, what do you guys think? Good idea, bad idea? It's very nonstandard,
but it seems to work fine, as I get really low temps (30c idle, 40c
load). This is also 15-20c colder than the Intel stock fan that blew
air out in the traditional direction. Is my choice bad enough that I
should attempt moving the fan back to the traditional model (wasting
Arctic Silver and risking the board integrity again), or is it at least
equal, possibly better the way I have it now? And even still, I already
lost 15c, so I must be doing something right. I doubt I'd get more than
1-2c even if the standard way was more efficient. I just don't have the
heart to test both methods unless I absolutely have to. And if my
method does turn out to be better, I would cry at having to move things around a fourth time (counting the Intel HSF).
EDIT: here's a picture of someone else's setup:
http://i73.photobucket.com/albums/i221/byuusan/board.jpg
Now, on my case, the Zalman is rotated 90 degrees, so that the actual
fan is at the lowest possible point on the board. The nVidia fan you
see below the CPU blows air upwards, and the PSU fan at the top is
obviously an intake.
Also, http://www.evga.com/community/messageboard/topic.asp?TOPIC_ID=24179
Quote: |
For
those of you who have a case with top exhaust fans I would recommend
pointing the 9700 upwards. I have found 2 benefits with this
orientation.
1) 4C - 6C drop on the CPU
temperature. I assume the reason for this is hot air rises and more of
the exhaust is vented cleanly out of the case and not being trapped on
its way out the back.
2) 3C drop in the main board temperature (North Bridge). My guess is
because the fan from the 9700 is pulling more air through the north
bridge that it's helping to cool it more efficiently. I was actually
thinking about removing the little fan and see if this pulling effect
was enough to cool the NB sufficiently.
I also think there is better weight distribution on the 9700's hold
down brackets in this orientation. The hold down bracket is
perpendicular to the ground and the forces of gravity (assuming you are
mounting this is a tower of some sort). This appears to better fight
the twisting of all of this mass on the motherboard and cpu. Give it a
try you might like it better, I know I do. |
Quote: |
its supposed to be scary, they need to hold over a pound worth of metal. |
It's ~540g/~1.2lbs. That's actually the reason I went with the 9500, as
the 9700 weighed ~750gm. I'm not too worried, it has six screws on all
corners holding it in place. The recommended weight is 400g or below,
so I'm not over by much.
I would've gotten the smaller fan for $25 if they had it, but I'm
really impressed with this one. I've read reviews on third-party fans
and never saw drops above 3-4c. A 20c drop using air cooling is simply
amazing. It's quieter, too.
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Mar 13, 2007 8:55 pm Post subject: |
|
Actually, ATX spec specifies that the PSU should be actively exhausting air from the case.
And yeah, it's probably a good idea to direct hot air toward an exhaust point in your case.
Edit:
Apparently, older versions of the spec indicated that the PSU should
blow in, while the latest revisions indicate that the PSU should blow
out of the case.
This page has a diagram that seems to indicate something similar to what you describe, too:
http://www.heatsink-guide.com/casecool.htm |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 13, 2007 10:25 pm Post subject: |
|
Quote: |
And
yeah, it's probably a good idea to direct hot air toward an exhaust
point in your case. This page has a diagram that seems to indicate
something similar to what you describe, too:
http://www.heatsink-guide.com/casecool.htm |
Not really, both show the traditional method of letting the CPU blow
air directly out of case. With my method, I don't immediately vent the
CPU air, I pass it up into the PSU to exhaust it. The main reason for
this is because of the NB fan that blows air up to the CPU. It just
makes sense to me to not disrupt that flow of air between the NB out
and PSU in with a CPU fan in the middle blowing sideways. The hot air
only passes over the PSU, rather than immediately out, and I'm not
worried about my PSU overheating as I use very low power in my case
with only a simple 6600 LE graphics card.
Anyway, that post on evga.com where the guy tried both
orientations and noticed a 3-6c drop in heat using my method with the
same exact mainboard and fan, with the NB fan attached like with mine,
and with the same exact case setup, convinces me that it's the best
choice for my particular setup. I will agree, from reading about this
thoroughly now, that the standard way is indeed the best general case
method. But with my case, I believe it's superior to do things the way
I have. And at any rate, 40c for 100% load is pretty good, considering
it's allowed to get to 90c before it's in danger.
EDIT: here's a quick sketch of airflow in my case right now:
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Mar 14, 2007 12:26 pm Post subject: |
|
You'll
probably be just fine pointing it up. You can run it like that for a
few days and monitor the temperature and then change it back for
another few days and see what the difference is. That way you can use
whichever really does give you best results.
I
fail at aero/thermal dynamic calculations. I've experimented with all
sorts of setups over the years. I'm often surprised by the results.
Sometimes things run cooler or hotter when I don't expect them to.
Experimenting is the only real way to know for me.
Of course, more often than not, I notice little to no difference. 
_________________
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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 15, 2007 4:57 am Post subject: |
|
Sigh,
OCD can be so "fun" at times. Fan kept bugging me for the last two
days, and the temps kept rising with time, so I went ahead and switched
the orientation. Had to clean with standard Q-tips since apparently
Microcenter is no longer even capable of stocking lint-free swabs, let
alone Arctic Silver V. Absolutely incompetent store. So I cleaned the
CPU up, and was just extra careful, using ArctiClean. Putting the CPU
back in was incredibly difficult to lock down into the LGA 775 socket
this time, compared to normal. Applied less Arctic Silver, as I usually
use way too much, and because I really didn't have much left, but I
still went way over the "single grain of rice" approach. To hell with
that, better to have too much than too little. Put the Zalman 9500 on
the correct way and ran some stress tests. Results:
Zalman 9500 pointing to the top of case: idles at 30-36c, max at 40-45c.
Zalman 9500 pointing to the rear of case: idles at 28-30c, max at 36-38c.
The reason it's better is obviously because my case does not have a
true top exhaust fan. I was using the PSU which is also a side exhaust,
and indeed the exhaust rate was much slower through the PSU than it is
through the rear 120mm ventilation fan. I was also wrong in that the
PSU only has the one intake fan, there is not a fan on the back of the
case to pull air out.
Thank god it runs cooler this way, I don't think my poor processor can take another reinsertion.
Lastly, my mainboard is running the C2D at 1.3375v, which seems rather
high to me. I've been thinking about undervolting it, because the stock
specs say my CPU should run at 1.2v ... though it's already well below
average CPU temperatures anyway. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 15, 2007 7:02 pm Post subject: |
|
I
wouldn't worry about the voltage too much; from what I've read
overvolting is only dangerous when you take it right to the edge of its
abilities, and my A64 X2 3800+ has been running just fine at 1.55V
(1.35 default) for.. well, can't remember when I bought it, but quite a
long time now, without the overclock I'm running at destabilising at
all. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 22, 2007 6:34 am Post subject: |
|
This is what has been keeping me busy lately:
http://byuu.cinnamonpirate.com/articles/freebsd.txt
However, on the bright side: I now have libco (and subsequently, bsnes)
working on amd64 targets, fixed a GTK+ rendering bug, and learned a lot
of new stuff about the core of FreeBSD and Xorg that I never wanted to
know.
The above is also a sneak peak at something I've been planning for a
while now: I want to create an articles page on my site. Any opinions
on my writing style? Tried not be biased for or against anything,
pretty flat and to the point. Hoping this readme gets propogated, as
I've seen lots of people running into the same issues I've resolved in
the above.
Oh yeah, thanks to blargg for catching it, I fixed an S-SMP timing bug
with mov mb,c opcode, and fixed some issues regarding S-SMP register
reads and writes, and their effects on APURAM.
New private WIP has these fixes, as well as blargg's most recent S-DSP
core, which has a few small improvements and such. Mostly
performance-related, I believe. It sounds great to me, at any rate. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Thu Mar 22, 2007 8:38 am Post subject: |
|
DataPath wrote: |
Actually, ATX spec specifies that the PSU should be actively exhausting air from the case.
And yeah, it's probably a good idea to direct hot air toward an exhaust point in your case.
Edit:
Apparently, older versions of the spec indicated that the PSU should
blow in, while the latest revisions indicate that the PSU should blow
out of the case.
|
Heh... ATX1. That was an embarassment.
If I recall, they changed the spec because nearly every power supply
manufacturer on Earth refused to install their fans correctly.
Seems they realized that using the PSU as an intake instead of an
exhaust just meant your system was pumped full of pre-heated air before
Intel did.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Mar 23, 2007 9:35 am Post subject: |
|
The
new WIP is incompatible with any previous CFG files and crashes on my
pc when used, however, a new clean CFG file solves the problem 
Edit:
Also when idle this new wip uses 100% cpu |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 23, 2007 10:10 am Post subject: |
|
byuu wrote: |
New private WIP has these fixes, as well as blargg's most recent S-DSP
core, which has a few small improvements and such. Mostly
performance-related, I believe. It sounds great to me, at any rate. |
I've tested quite a few games now on blargg's and have yet to see any
issues. I see you've figured out the config window. Cool to have that
coming back again.
Issues you're probably aware of: video settings aren't saving on next
run... icon isn't showing up in the program bar... double audio log bug
still there. Yada yada.
Looks like tetsuo's right about the idle usage.
EDIT: video settings apparently do save, but only if applied before loading a game.
|
|
dongle New Member
Joined: 12 Aug 2005
Posts: 4
|
Posted: Mon Mar 26, 2007 9:42 am Post subject: |
|
Out of curiosity, can I ask why you chose FreeBSD over linux? I promise
I won't make any annoying posts disagreeing with anything you say or
trying to convert you.
And thanks again for supporting the *nix platform in your development of the most accurate snes emulator.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 26, 2007 4:38 pm Post subject: |
|
Quote: |
Out of curiosity, can I ask why you chose FreeBSD over linux? |
Couple of reasons.
The biggest reason is that I really like the way the system as a whole
works, compared to Linux. Things just seem more sane to me.
For example, there are no runlevels. You have your kernel, and the
drivers built into it, and the drivers you can attach / detach at
runtime through kld* functions, and then you have usermode applications.
Rebuilding the kernel is simply far easier to me.
Code: |
cd /usr/src
make buildkernel KERNCONF=myconfigfile
make installkernel KERNCONF=myconfigfile |
Done. No crashing out on errors, the kernel config file is sanity
checked before anything starts. The config file is plaintext and very,
very straightforward and minimal. Maybe Linux is this easy now, but I
can tell you it wasn't the last time I tried and I've since moved on.
I've no need to go back to Linux at this point.
From there, I can install just a flat, minimal working Xorg distro. Now, I can install vanilla xfce4:
Code: |
cd /usr/ports/x11-wm/xfce4
make install
echo "startxfce4" > ~/.xinitrc" |
Done, now XFCE4 is up and running, and without any annoying "distro" branding that RedHat seems to have invented.
Next, I'm not a fan of the GPL. In fact, I very much dislike it. I'll
support others' rights to license their code however they want, but
BSD's kernel being released under the BSD license I am much more
accepting of. I realize a lot of the userland utilities and such are
GPL'd, as is most of my desktop software. Not much you can do about
that.
Next, I like that FreeBSD, while not being as difficult to use as
OpenBSD, gets a lot of OpenBSD's security enhancements that are not
portable to Linux. Though I don't care to argue which is more secure.
They're both very secure and I have zero open ports to my PC as well as
an outbound whitelist firewall, so it doesn't really matter.
Next, I'm extremely displeased with the 20,000 distros of Linux. There
are three real distros of BSD, and one knockoff that nobody cares
about. Each of those three focus on very differing goals, and Free just
works best for what I want.
Lastly, we all need a bit of variety :)
We don't want a Linux monoculture, just like we don't want a Windows monoculture, right?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Mar 26, 2007 6:13 pm Post subject: |
|
byuu wrote: |
Rebuilding the kernel is simply far easier to me.
|
Why do you build the Kernel at all? I never built a UNIX Kernel in my life.
byuu wrote: |
There are three real distros of BSD, and one knockoff that nobody cares about. |
The original BSD branched into Solaris, FreeBSD, and NetBSD.
FreeBSD gave birth to DragonlyFlyBSD. People do care about it. It seems
to have more frequent releases. Copies ideas from Solaris, to provide
better utilization of multiple CPUs/cores. They're also working on some
interesting new stuff. Read: http://kerneltrap.org/node/8
NetBSD gave birth to OpenBSD. OpenBSD today is larger though.
Then there is Mac OS X which is based off of FreeBSD with code taken from NetBSD too.
That's a total of 6 BSDs today going strong. Of those with the BSD name, here's a pie chart:

You can also see that there are many smaller BSD descendants just like Linux has many distros:
http://en.wikipedia.org/wiki/BSD#Significant_BSD_descendants
http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#General_information
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Mar 26, 2007 6:39 pm Post subject: |
|
you should give gentoo a spin when you have the chance.
its package system is based on bsd's ports.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 26, 2007 10:44 pm Post subject: |
|
Quote: |
Why do you build the Kernel at all? I never built a UNIX Kernel in my life. |
SMP support is still disabled by default, and in my case I had to fix a
bug in one of the drivers that was linked into the kernel. Yes, it's
possible to link them at runtime, but the default kernel had it built
into the kernel.
It's nice to be able to do it when I need to.
Quote: |
That's a total of 6 BSDs today going strong. |
True, counting all the no-name ones that are minor variations, there's
probably a lot of BSDs. We can at least agree that three make up ~95%
of BSD users. And so far as desktop users (not servers or toasters),
that's pretty much all FreeBSD, perhaps some OpenBSD.
But you're right, it doesn't matter how many distros there are. I'm
just not a fan of forking, as you know. I wish there were less BSD
forks, but it's the best I can get.
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Tue Mar 27, 2007 5:49 am Post subject: |
|
byuu wrote: |
I
want to start reducing my dependency on my custom libraries in my code.
One step is to use <stdint.h>. Unfortunately, Microsoft hasn't
had the time to implement this eight year old standard, so I cannot
simply use it directly. Should I attempt to implement the types I need
myself in my own library file, or should I just start referencing
stdint.h in my code, and add documentation to the src folder
instructing Visual C++ users to seek out free implementations of
stdint.h to put in their include folders? |
I'd either implement the types you need yourself, or include a free implementation of stdint.h...
http://www.azillionmonkeys.com/qed/pstdint.h
.
|
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Mar 27, 2007 5:51 pm Post subject: |
|
wow, 100 pages.
the best way to combat forks is to change the license to a more restrictive one, and that defeats the purpose.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 27, 2007 7:19 pm Post subject: |
|
Happy 100th page.
How about a public wip to celebrate?  |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Mar 27, 2007 7:58 pm Post subject: |
|
If
it weren't for forks, X-Windows wouldn't be anywhere NEAR where it is
today. The old maintainers were crap, doing nothing with it, and not
accepting anyone's work into it.
So Xorg forked, and hardly anyone even remembers that there's another branch of X-Windows out there. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 27, 2007 8:57 pm Post subject: |
|
And
if Xorg were to make their own windowing system instead and design it
to not be crap, including built-in widget sets and such, the Unix
platform would be all the better for it. Instead we're still using the
vastly outdated, horribly bloated API that is X11.
They could make compatibility layers as a temporary solution to get
XFree86 users to switch over, then nuke off the compatibility once most
apps were natively running on their platform.
I wanted to write an emulator, so I did. I wrote my own. I didn't just
grab SNES9x and go to work improving it. Like it or hate it, I have a
unique program now that has no legacy crap associated with it. Of
course, it's not exactly the model of success that makes a good case in
point here, but whatever.
I might consider a WIP, then. Wouldn't hurt having more people test blargg's new DSP core. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Wed Mar 28, 2007 1:13 pm Post subject: |
|
Sorry,
byuu. I wasn't arguing in reference to your decision to develop your
own emulator instead of improving existing ones. I was just arguing
against the blanket statement that forking is bad. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 28, 2007 3:08 pm Post subject: |
|
DataPath wrote: |
Sorry,
byuu. I wasn't arguing in reference to your decision to develop your
own emulator instead of improving existing ones. I was just arguing
against the blanket statement that forking is bad. |
I didn't think that you were. I was merely refuting your XFree86 point,
and naming another program that benefitted from not forking :)
As usual, I debate to one extreme to make a point, though I generally
compromise in the middle somewhere in reality. I won't say all
forking is bad, but really, the Linux community needs all the unity it
can get if it's going to ever increase its' market share above 2-3%.
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Wed Mar 28, 2007 4:02 pm Post subject: |
|
Quote: |
And
if Xorg were to make their own windowing system instead and design it
to not be crap, including built-in widget sets and such, the Unix
platform would be all the better for it. Instead we're still using the
vastly outdated, horribly bloated API that is X11. |
Xorg has done a lot towards those goals you mentioned.
A completely new driver API that's a lot more flexible and natural
(introduced in 6.9, IIRC), a dynamic configuration mechanism with the
goal of making X work on many systems without a configuration file (to
be introduced in 7.2), and an updated X API:
Quote: |
The
X protocol C-language Binding (XCB) is a replacement for Xlib featuring
a small footprint, latency hiding, direct access to the protocol,
improved threading support, and extensibility. |
Whether they have plans for a native widget set or not, I have no clue. I suspect not.
Quote: |
They
could make compatibility layers as a temporary solution to get XFree86
users to switch over, then nuke off the compatibility once most apps
were natively running on their platform. |
They have implemented a compatibility layer over XCB to provide all of
the standard X C APIs (I'm pretty sure that that "bloated" C API is
part of the X standard), they will still allow static configuration via
classic configuration files, and the have maintained hooks for the old
driver model, which fulfills the "compatibility layers" aspect of your
suggestions.
My intent is not to refute your complaints about X, but rather to
demonstrate the rapid advances in X since Xorg forked from XFree86, and
to defend my original example as well-considered.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Mar 28, 2007 5:06 pm Post subject: |
|
Byuu
was bemoaning the fact that you need more layers than what should be
needed in order to have a functioning graphical desktop under Unix.
Unix is based on the mentality of a flexible tool chain, you pipe the
output from to another in order to produce work. Thats good for single
dimension data streams, but not the best sanity wise for a graphical
interface - and it results in unessicary duplication from many
projects, resulting in a non-uniform look that doesn't help expand *nix
adoption.
People ask when zsnes will have a standard windows interface, that
should be a good enough point against mutliple frameworks for drawing
windows.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 28, 2007 5:50 pm Post subject: |
|
This
is kind of going offtopic from forking now, and more toward consistency
arguments. Though I feel forking just makes the barrier to entry for
breaking consistency that much easier. I realize the below examples are
not forks.
I wouldn't even mind if they separated
the widgets from the server. The modularity is actually kind of neat.
But unfortunately, Xorg needs to come up with an officially sanctioned
widget set. The problem is that by not doing this, everyone and their
mother is going to want to reinvent the wheel and make their own widget
set. The mainstream two are GTK+ and Qt, though there are plenty of
others still around and in active use. They're so vastly different,
from the way they look all the way down to the keyboard shortcuts they
support, that I go out of my way to only have one or the other on my
desktop for the sake of consistency. Since I use XFCE, that means no Qt
apps for me, even though I like the Qt toolkit, especially it's file
open window. We can get the look pretty close with themes, but
definitely not the responsiveness and fine details.
Bottom line is that people love consistency, and while we're a lot
better than we were back in the 90's and those godawful black and white
X apps that were all over the place, we still have a long way to go.
The bad news is that the desktop environments are so well developed,
that there's a rat's chance in hell we'll ever standardize on one now.
A shame, too. XFCE does a fantastic job of compromising between the two
extremes: grandma (GNOME, "options? you don't need any of those, trust
us, we know best") and ubergeek (KDE, "how many ms do you want to wait
per tick by 2% luminance when you mouse over icons, but only when you
are holding the shift key down and you are on your primary display
monitor while running with battery power and are playing a DVD?")
[note: I'm obviously exaggerating for emphasis]. But, personal opinion,
I guess. No reason a standard desktop can't allow both high
configuration for power users and simplification for people who just
want a functioning desktop.
Microsoft and Apple have both shown that it's very much possible to
make an OS that has only one desktop environment associated with it. I
can near guarantee you Linux adoption would be higher if there were but
one desktop environment that everyone combined their efforts to work on
and improve. Not only would it be more consistent, but it would have
more developers working on improving it. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Mar 28, 2007 6:10 pm Post subject: |
|
Reinventing the wheel is everything! 
_________________
FF4 research never ends for me. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 30, 2007 8:53 am Post subject: |
|
Got
my Sf3 copier today. At first I couldn't make head or tail of it (no
documentation. And the thing is a semi-prehistorical long discontinued
product..) after some fiddling around I finally understood the basic
idea. Heh, now I see why there's so much "header" crap rom floating
around.
Anyway, apparently this thing needs it's
own custom header attached to the ROM othewise, nothing will happen.
Thanks to
uCON64 for supporting ridicoulously outdated products, it can attach the proper "gd3" header.
So finally, got some game running. Except for some reasons, only a few
would even start (Obviously, none of them were special chips
game)...After checking the rom info I think I might have figured out
the problem...And it suck, real bad (if my guess is correct)
So it seems all the rom that wouldn't start are in the so-called
"HiRom" format (I think byuu dislike this term actually). From what I
gather, some game PCBs access the Snes faster than some others, and the
Snes cpu put itself in a 3.58mhz mode as opposed to 2.xxmhz mode or
something to that effect. Now, it seems that some older copier does NOT
support the above-mentionned "HiRom/fastrom"...which needless to
say...suck.
So can someone confirm that the SF3 game doctor does not in fact
support "Hiroms"...and if so, what percentage of games are
"HiRoms"...70? 80 percent? All games except the ones published in the
first year of the console I take?................ -_-
Oh well, next time I'll know better at least.
Last edited by Snark on Fri Mar 30, 2007 9:36 am; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 30, 2007 9:33 am Post subject: |
|
Ok, sorry about the long post. I'm reading there's some workarounds for the above issue.
But what I'm wondering is if one use the patch/split files workaround
method...won't the game still end up playing at 2.68mhz instead of
3.58mhz, thus causing potentially more slowdowns or potentially even
game crashes or bugs? (I assume at least)
And sorry if not everything I say is correct. Obviously, there's lot of
informations I don't know or understand properly.
edit: old post from anomie on this board
Quote: |
HiROM,
LoROM, or whatever has nothing to do with FastROM/SlowROM (although it
does require that the cart have ROM chips with fast enough access
speeds). The speed is completely a function of the SNES: if you set bit
1 of the MEMSEL register, then accesses to $8000-$ffff in banks $80-$BF
and all of banks $C0-$FF are FastROM, otherwise they're SlowROM. Note
BTW that other regions ($2000-$3FFF and $4200-$5FFF in banks $00-$3F
and $80-$BF) are always FastROM. |
So, I guess there's no reason to worry about bugs, crashes and such?
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 30, 2007 10:26 am Post subject: |
|
HiROM uses full 64k banks instead of the LoROM 32k banks... so I'd guess the games won't find their data at the expected locations.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Mar 30, 2007 10:31 am Post subject: |
|
You
have to interleave your "HiROM"s to load them, then they'll work fine.
They make up 80% or so of all games >2MB, and perhaps 10% of games
less than that.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Mar 30, 2007 8:33 pm Post subject: |
|
Nach wrote: |
You
have to interleave your "HiROM"s to load them, then they'll work fine.
They make up 80% or so of all games >2MB, and perhaps 10% of games
less than that. |
Ah, I see.
I don't want to spam this thread with any more of my copier questions,
but is there a way to interleave a ROM with NSRT? I only notice a
"desinterleave" option...
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sat Mar 31, 2007 1:45 am Post subject: |
|
Ucon64 has an interleave option. It should work if you do this:
ucon64 "romname" --int
Edit: Hmm nevermind, that actually doesn't work. I've never really had
a reason to use it since I don't have a copier. However converting it
with the --gd3 switch will automatically make a HiROM file interleaved.
So making it interleaved probably isn't the problem. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Mar 31, 2007 3:50 am Post subject: |
|
crap, wanted to edit and replied.
Quote: |
Edit:
Hmm nevermind, that actually doesn't work. I've never really had a
reason to use it since I don't have a copier. However converting it
with the --gd3 switch will automatically make a HiROM file interleaved.
So making it interleaved probably isn't the problem. |
Ah, didn't know the -gd3 convertion automatically interleave the rom.
Well, in that case I really don't know what's the deal here...
edit:
Got it to work finally. Had to use an older version of Ucon (1.41)
Back to bsnes: I played quite extensively some games and tried to took
note of some of the places where an emulator might fail to reproduce
the exact same game behavior due to imperfect timing or stuff like that.
So far I've yet to find one difference between bsnes and the Snes 
I'm looking at weird original game "bugs". For example in "B.o.b" the
music slow downs whenever there are consecutive audio samples being
played (when you got up or down a ladder for ex)...Same behavior in
bsnes.
For some reason, I'm always half dissapointed whenever I found out there's no differences. I want to find a proper emulator bug damnit heh.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Apr 01, 2007 5:47 am Post subject: |
|
Possible bug in bsnes.
Quote: |
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Best of the Best - Championship Karate (U).smc
Name: BEST OF THE BEST Company: Electro Brain
Header: SWC Bank: LoROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 8 Mb
Country: USA Video: NTSC
ROM Speed: 200ns (SlowROM) Revision: 1.0
Checksum: Good 0x9AB1 CRC32: 7F6ED86E
MD5: 3E1AFA72971094777D9733289C9043B6
--------------------------Database--------------------------
Name: Best of the Best Championship Karate
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Sports Genre 2: Martial Arts
|
This was tested with my copier so it's very possible, even likely, that
the copier is causing the bug, but...just to leave no stones unturned:
In
Best of the Best - Championship Karate (U), during the training mode
(first part/sparing match) the screen blacks out at random intervals,
like everything disappears for half a second then it reappears.
Happened fairly consistently.
Does not occur in bsnes,
so in the unlikely case this also happen on the real cart, I guess this
would be a case where a "native" bug that should occur, doesn't.
Anyway, if someone has the real cart, or test it on their copier and it doesn't occur then we'll be fixed.
Incidently, Zsnes used to have problems with this game where the
background would not show up at all. So maybe the game has some
weird/unorthodox coding stuff going on.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Apr 01, 2007 8:51 am Post subject: |
|
As thats a NTSC game Fitzroy will have to verify.
Does this game also have a pal or japanese version? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Apr 01, 2007 11:08 am Post subject: |
|
tetsuo55 wrote: |
As thats a NTSC game Fitzroy will have to verify.
Does this game also have a pal or japanese version? |
There's also a PAL game. (no Japanese one though) But NTSC issues won't
necessarily shows on PAL versions or vise-versa I would assume.
edit: Also I should mention that I tested with 0frameskip in bsnes.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 01, 2007 12:23 pm Post subject: |
|
New beta --
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v020_beta.zip |
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Apr 01, 2007 4:55 pm Post subject: |
|
Is the sound issue related to SDL?
Anyway...
In Super Metroid there's a strange bug after the first Mode7 scene (Samus' ship approaching Ceres station).
EDIT: Very strange. I can't leave it!
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Apr 01, 2007 11:49 pm Post subject: |
|
creaothceann wrote: |
Is the sound issue related to SDL?
Anyway...
In Super Metroid there's a strange bug after the first Mode7 scene (Samus' ship approaching Ceres station).
EDIT: Very strange. I can't leave it! |
Hmm...The beta byuu posted seems like a corrupted exe. Most games do
not works and the ones that do shows corrupted gfxs...
Hmm...Today is april first...Coincidence?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 02, 2007 12:31 am Post subject: |
|
byuu wrote: |
New beta --
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v020_beta.zip |
|
SNES ultimacy has been achieved!
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 02, 2007 5:23 am Post subject: |
|
Snark wrote: |
creaothceann wrote: |
Is the sound issue related to SDL?
Anyway...
In Super Metroid there's a strange bug after the first Mode7 scene
(Samus' ship approaching Ceres station).
EDIT: Very strange. I can't leave it! |
Hmm...The beta byuu posted seems like a corrupted exe. Most games do
not works and the ones that do shows corrupted gfxs...
Hmm...Today is april first...Coincidence? :?
|
Yes, a poor April Fools joke. Sorry. Amazing how few people noticed :/
That was bsnes v0.0.002 ir9, or roughly, bsnes at ~six weeks old. I've
clearly not come as far as I previously thought, hm? :/
No matter. Hope you guys at least enjoyed taking a look at it.
I'll see about getting a real WIP up for you guys sometime soon,
though. I'm unfortunately planning to rewrite libui (heavily
copy/pasting, so it won't take too long). I want to make the API more
portable. Specifically by removing the parentless capabilities of
widgets. It'll kill some of the object-orientedness of the API, but
whatever.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Apr 02, 2007 5:44 am Post subject: |
|
byuu wrote: |
Snark wrote: |
creaothceann wrote: |
Is the sound issue related to SDL?
Anyway...
In Super Metroid there's a strange bug after the first Mode7 scene
(Samus' ship approaching Ceres station).
EDIT: Very strange. I can't leave it! |
Hmm...The beta byuu posted seems like a corrupted exe. Most games do
not works and the ones that do shows corrupted gfxs...
Hmm...Today is april first...Coincidence?
|
Yes, a poor April Fools joke. Sorry. Amazing how few people noticed :/
|
Beware of people bearing gifts on 4/1 or there are trojans behind you.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 07, 2007 7:25 pm Post subject: |
|
I've
been dumping some carts lately and trying to figure out what the PCB
codes mean and if they're worth documenting. First of all, byuu, how
useful are these codes to you and to SNES emulation in general?
Secondly, I'd be grateful if you or someone else could look at the
following list I've made (in an attempt to decipher the codes), and
point out any errors and fill in any mysteries.
FitzRoy wrote: |
SNES PCB Serials
[Code 1]-[Code 2]-[Code 3]
Code 1
------
SHVC: On cartridge PCBs manufactured in Japan.
MAXI: On cartridge PCBs manufactured in Mexico.
BSC: On BS interface cartridge PCBs manufactured in Japan.
EA: On some Electronic Arts cartridge PCBs manufactured in Thailand.
Code 2
------
1***: 1 ROM chip
Y***: 2 ROM chips (4Mb + 4Mb)
2***: 2 ROM chips (8Mb + 8Mb)
B***: 2 ROM chips (16Mb + 16Mb)
L***: 2 ROM chips (32Mb + 32Mb)
*A**: No coprocessor (LoROM)
*B**: DSP-1/2/3/4 (LoROM)
*CA**: Super FX (LoROM)
*DC**: C4 (LoROM)
*DE**: Seta 18 (LoROM)
*DH**: SPC7110 (HiROM)
*DS**: DSP Seta (LoROM)
*E**: OBC1 (LoROM)
*J**: No coprocessor (HiROM)
*K**: DSP-1/2/3/4 (HiROM)
*L**: SA-1 (LoROM)
*N**: S-DD1 (LoROM)
*PV**: Prototype
SGB2: Super Game Boy 2
**0*: 0Kb SRAM
**1*: 16Kb SRAM
**2*: 32Kb SRAM
**3*: 64Kb SRAM
**4*: 128Kb SRAM
**5*: 256Kb SRAM
**6*: 512Kb SRAM
**7*: 512Kb SRAM and ?
**8*: 512Kb SRAM and ?
**9*: 1024Kb SRAM
***B: Battery and ?
***C: Battery and RTC
***M: Battery and ?
***N: No battery
***R: Battery and S-RTC
***X: Battery and ?
Code 3
------
**: Board revision
|
Last edited by FitzRoy on Sun Apr 08, 2007 2:07 am; edited 2 times in total
|
|
Firon Trooper
Joined: 05 May 2006
Posts: 367
|
Posted: Sat Apr 07, 2007 11:28 pm Post subject: |
|
What about games that are a total of 48mbit? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Apr 07, 2007 11:36 pm Post subject: |
|
Firon wrote: |
What about games that are a total of 48mbit? |
As far as I know, there is no such thing as a 12Mb, 24Mb, or 48Mb sized
chip on which to put a game that size. So what they did was they split
the rom onto two ROM chips. What I'm not sure about is whether it was
possible to use different sizes while doing this (i.e. 16Mb + 8Mb for a
24Mb game, rather than two 16Mb chips with 8Mb unused space.) I've
already dumped several 32Mb roms that NSRT has detected as overdumps
and corrected as 24Mb, so I'm just guessing it had to be equal.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Apr 07, 2007 11:42 pm Post subject: |
|
Most
likely both for cost reasons. Sometimes it is "ok" to have the extra
allocated space available if it isn't cost prohibitive. It can signal
it may have had more content if more time was available (it is not a
given though).
_________________
FF4 research never ends for me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 08, 2007 1:35 am Post subject: |
|
If
we can get more info on the PCB codes, that would be great. I could
include them in the database editor I'm planning on making once libui
is finalized and v0.020 is out.
The third set on
the PCB codes is a board revision code, I believe major and minor
versions, but I could be wrong. Some have eg -10, -11, -12, -20. Sadly,
they do actually change the way things are wired, so they have to be
treated separately.
One thing I was actually wanting to do was move the PCB emulation glue
code out of hardcoded values and into the database, so people can
create their own custom mappers and such.
As far as games that aren't powers of two: it's most probable that the
games did use two separate ROM sizes. Take a 24mbit game, the game
would just not wire the top bit of the second 8mbit ROM, so the result
would be "mirroring" of the top 8mbits. I think it'd be very uncommon
for a 16mbit ROM to be cheaper than an 8mbit ROM, especially when they
order them in bulk. But it's technically possible to mirror the ROM
anyway. I don't know of any games that do this, and it's irrelevent to
emulation anyway. We may as well use the smaller, trimmed versions.
---
I finally
have my system fully up and running. I decided to stick with a 64-bit
OS, even though I can't run WINE (and thus, uTorrent). It's more out of
principle than anything else.
I've verified the
new changes to libco work with bsnes. I'm thinking this will be the
final revision to the core API, so I'm going to wait a while before
releasing this one.
I've also decided to make libui more portable. I'm going to require
widgets to take a reference to windows to create them. Creating widgets
by themselves requires the API to support reparenting. While Win32 and
GTK+ can do this, I can't say for certain that other APIs will allow
it. Better to make it easier than take a hardline, "OO only" approach.
Will probably take most of the weekend to update the code for both
ports, but then I can start working on the bsnes UI again. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 08, 2007 2:19 am Post subject: |
|
byuu wrote: |
The third set on the PCB codes is a board revision code, I believe
major and minor versions, but I could be wrong. Some have eg -10, -11,
-12, -20. Sadly, they do actually change the way things are wired, so
they have to be treated separately.
|
Thanks for the info. I figure the only people who could answer that
question is you and Overload, and maybe not even Overload with the way
his DB is set up. I can see that he hesitates to add "MAXI" codes and
has no multiple codes for any game, despite how prevalent I've found
them to be. It's possible that he didn't do a lot of dumping himself
and finally got to a point where he realized the stuff he was
documenting wasn't as finite as he thought he was.
EDIT: Updated list and further discussion moved to No Intro.
http://forums.no.intro.free.fr/showthread.php?p=7942
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 11, 2007 12:51 pm Post subject: |
|
New
WIP. This one adds a GDI renderer for windows. If anyone wants to test
it, edit bsnes.cfg and set system.video to "gdi". It will be very slow,
obviously. It's just there for the hell of it, as another fallback I
guess. I'd be interested if it didn't work for someone. I had to
add the code to libui to support pixel buffer images, so now I can add
things like the controller art into the new lui port, and it'll work on
Windows and Linux. The best part is that I can make these image buffers
anywhere, so things like PPU VRAM / OAM / CGRAM viewers in the debugger
will now not only be possible, but trivial, to add in the future.
Refined libui a lot more, but I did not merge that into this bsnes WIP,
because it would break the source pretty bad. Still working on the API,
too, so I'll probably hold off a bit longer. After I get the new libui
merged in, I can start working on that configuration settings window.
That window is the only thing holding up a new official release.
I'm trying to figure out how the hell you enable WinXP themes now. I
tried making a manifest file, even attaching the manifest to the EXE
directly with the mt tool, but it's still drawing the controls using
the old win32 compatibility mode.
Quote: |
I
can see that he hesitates to add "MAXI" codes and has no multiple codes
for any game, despite how prevalent I've found them to be. |
You have cartridges where it's the exact same game (eg bit-for-bit
identical ROM dumps), with the only difference being the PCB codes?
Care to cite an example? The last two digits may change for revisions
of the same game, obviously.
That complicates things, but there's no harm in just picking one in
that case. If the game didn't work with that PCB, it wouldn't have been
released with it, so ...
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Apr 11, 2007 2:20 pm Post subject: |
|
byuu wrote: |
[...]
so things like PPU VRAM / OAM / CGRAM viewers in the debugger will now
not only be possible, but trivial, to add in the future. |
Great! I love real-time graphic viewers. 
_________________
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 Apr 11, 2007 10:52 pm Post subject: |
|
byuu wrote: |
You have cartridges where it's the exact same game (eg bit-for-bit
identical ROM dumps), with the only difference being the PCB codes?
Care to cite an example? |
Sure. I don't have a scanner, but these camera pics are decent.
byuu wrote: |
The last two digits may change for revisions of the same game, obviously. |
There might be a correlation in that a 1.1 rom might be more likely to
have a higher board revision number, but otherwise the rom revision
doesn't seem to have anything to do with the third pcb code. Rather,
the rom revision seems to be printed on the ROM chip itself. For
example, a Monopoly 1.0 would have "SNS-ML-0" printed on it while the
1.1 version would have "SNS-ML-1." Of course, many MAXI boards I have
don't give away any version and simply print the game's name instead of
giving a code. The Pitfall cart above does that, although my camera was
unable to pick up the faint printing.
Whether the MAXI/SHVC part actually means anything more than
manufacturing location is up to someone else. Somehow I doubt it.
Frankly, I don't know why they didn't just stick with SHVC. I mean, the
cart says where it's manufactured. I looks like they eventually changed
it, because on every "Made in Mexico" cart, it's SHVC. Only the older
looking "Assembled in Mexico" carts have the MAXI code on the PCB. And
EA chooses to use its own code as well later on when they start making
shit themselves.
But yeah, no cut and dry 1 PCB code per game. If you look at the
updated list at No-Intro, you'll see that ***B and ***M were discovered
to correspond to the type/brand of memory address decoder chip being
used (for games that have SRAM). And you might be interested to know
that I have two identical data Ken Griffey Baseball carts that use
opposing chips. I don't know what the reason is for having two
different decoders. Cost, supply issues?
The No Intro guys have also already documented an instance of an
identical data game existing on a 1 chip and a 2 chip solution (Chrono
Trigger (J)).
What I'm getting at is that it seems we might be able to construct a
complete and accurate list of "possible middle codes" for each game
simply by using the ROM data and our newfound PCB code knowledge.
So I just did an example where I guessed a game's middle code from
looking at the dumped rom scan before opening it.
Code: |
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Mechwarrior.smc
Name: MECHWARRIOR Company: Activision
Header: None Bank: LoROM
Interleaved: No SRAM: 16 Kb
Type: Normal + Batt ROM: 8 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x2F85 CRC32: 40B7A858
MD5: 71516A3B67963CF91055A6C78566A1BA
--------------------------Database--------------------------
Name: Mechwarrior
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Simulation Genre 2: Mech
|
Okay, so it could be:
1A1M, 1A1B, YA1M, or YA1B
I opened the cart and it was:
1A1M
So let me know if this could work, because I'm not exactly learned in
the whole memory mapper business. I remember when all those "HiROM"
fighting games were broken and you ranted about these terms not meaning
anything, but every time I open the cart of a LoROM game, it's *A**.
And every time I open the cart of a HiROM game, it's *J**.
Last edited by FitzRoy on Sun Apr 20, 2008 7:54 am; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 13, 2007 11:38 pm Post subject: |
|
I'm working on regaining full licensing control over bsnes so that I have the ability to release the work as PD if I so choose.
As such, I have a question about licensing. Please do not respond
unless you know the answer for certain. I don't care about personal
opinions or guesses.
With libui, I basically wrote a wrapper around UI APIs.
So libui function A() maps to Windows X(), GTK+ Y() and potentially QT Z() one day.
My question is, because bsnes uses libui, and libui uses GTK+, does
that bind bsnes to LGPL requirements somehow? And how about QT? As QT
is licensed under GPL, that one tends to be a lot more viral. Would
adding an optional QT wrapper to libui make the entire bsnes project
GPL?
Amazing, with a 2% market share for Unix on the desktop, and a 1% share
for toolkits, that QT will push something like that on potential
developers.
The thing that makes this the most confusing for me is that I'm not
using the sources to GTK+ or QT, I am merely using their header files
and linking to the libraries. Does the license apply even for using
their headers and linking to the functions?
If so, then perhaps I could take a reverse approach. Instead of:
QT -> QT libs -> libui wrapper -> bsnes, I could use:
bsnes -> libui -> QT libs -> QT
Similar to how FreeBSD has BSDL kernel, but userland tools are GPL.
Basically, I'd have to do some sort of runtime dynamic linking, so that
the actual core of my system could be PD, and at least the Win32 port +
libui could be completely PD.
Thanks in advance. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Sat Apr 14, 2007 12:17 am Post subject: |
|
Unfortunately, this is an area where you'd have to talk to a lawyer to be certain.
The tricky part of GPL v2 is its notion of "derivative work" that is not explicitly defined.
In making your code able to link to the GPL code (by your inspection of
the headers, and the linker's inspection of the library), you may be
becoming a derivative work.
The way binary kernel modules (nvidia, ATI, etc) get around this
requirement is that the GPL license doesn't restrict how the
copyrighted work is USED, it restricts how it's DISTRIBUTED, and thus
they distribute the portion of the driver that interfaces directly with
the kernel in source form, and have compile that on the customer's
computer, wherein the user is doing the linking, and so the
now-derivative module isn't getting distributed.
Additionally, at least with respect to the linux kernel, major
copyright holders of the linux source (Linus being only one of them)
have (for the most part, grudgingly) defended this method of complying
with the language of the GPL.
edit:
Ahh - just read your part about runtime dynamic linking. If you can do
what you need to do using dlopen, then <IANAL>you might be free
and clear on the "derivative work" issue.</IANAL> |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Sat Apr 14, 2007 11:59 am Post subject: |
|
That goes for all GPL-compatible licenses
I think. And of course, all the code that you have copyright over may
be (re)licensed however you see fit, but you may not be allowed to
combine it with GPL code if that license is incompatible. Combining
your code with other code doesn't revoke your copyright. (Code
previously released under a different license can't be withdrawn of
course.)
GPL applies to linked object code, LGPL only does for static linking.
Oh, and remember that Trolltech wants to make a living too .
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Apr 14, 2007 5:37 pm Post subject: |
|
It's called Qt not QT. And Qt is licensed under GPL or QPL. You get a bit more leeway with QPL.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Apr 15, 2007 9:31 pm Post subject: |
|
I first want to thank Byuu for his efforts in making the most accurate emulator. Thank you!
Then I want to acknowledge that I did read all 101 pages of this thread. (Yeah, I lack a life)
I know you might not agree with me, but I personally would prefer if
you worked on supporting the unsupported chips and input devices
instead of the performance draining dot PPU. I really think that the
performance drain should go to something that most people gain from,
how big would the improvement for the dot PPU be for compatibility? I
think that if you are going to make the emulator slower, you should use
the CPU time on something that a lot of people will find bigger usage
of. Rest assured that I do realize that your opinion is likely to
differ here, this is only my opinion.
I read that you managed to break PGO of the Microsoft compiler, so why
are you using it? It is not the only compiler for Windows, I think that
if you can gain speed by changing compiler, you should. Do note that I
only assume you only use the MS compiler for windows right now, because
I have not seen anything saying otherwise.
I read about your libco, it is a great thing, but I want to add about
the discussion about optimisions for different CPU types and so on that
while it is very low level, you may want to consider self modifying
code to tweak the performance for different CPU types. I have thought
about it, and it can be done fairly cleanly, a simple jump table can be
used to change into the most optimized implementation for each
function. It would be of no more performance hit then a normal direct
jump directly after a call.
Rest assured that I do know that self modifying code is not easy to
debug, but for a self modified jump table, I think the possible gain
might make it interesting for public builds. Private builds can simply
be compiled without it and the jump table (if a jump table is even used
then) would be a static set of JMP instructions.
Just since I got space left, I want to add that the Windows load-time
DLL linking actually uses jump tables like this. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Apr 15, 2007 9:33 pm Post subject: |
|
henke37 wrote: |
Then I want to acknowledge that I did read all 101 pages of this thread. (Yeah, I lack a life)
I know you might not agree with me, but I personally would prefer if
you worked on supporting the unsupported chips and input devices
instead of the performance draining dot PPU. I really think that the
performance drain should go to something that most people gain from,
how big would the improvement for the dot PPU be for compatibility? I
think that if you are going to make the emulator slower, you should use
the CPU time on something that a lot of people will find bigger usage
of. Rest assured that I do realize that your opinion is likely to
differ here, this is only my opinion. |
Sure, wait until the 7GHz comp to finally make something out of SA-1 emulation in BSNES.
_________________
FF4 research never ends for me.
|
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Sun Apr 15, 2007 10:20 pm Post subject: |
|
byuu wrote: |
...lots of licensing stuff... |
In general, the LGPL does not require you release any of your source
code, as long as you dynamically link to any LGPL libraries, and
release the code to those libraries if you modify them.
With the GPL, you are probably
safe if you define a strict dynamic linking interface, and write your
Win32, GTK, and Qt plugins all to that interface. That way, your code
is not a derivative work of Qt, and only the Qt plugin is.
Or, you could release two versions of libui: A GPLed one with Qt
support, and a whatever one with the Qt code removed. That's probably a
bit more work than you'd like, though.
Nach: Only the X11 version of Qt is available under the QPL.
_________________
#577451
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Apr 16, 2007 1:12 am Post subject: |
|
Noxious Ninja wrote: |
Nach: Only the X11 version of Qt is available under the QPL. |
I see you're right, I never noticed each platform had different license information before.
http://www.trolltech.com/developer/knowledgebase/125/
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 16, 2007 3:23 pm Post subject: |
|
Quote: |
but
I personally would prefer if you worked on supporting the unsupported
chips and input devices instead of the performance draining dot PPU |
I might just do that, because the PPU will consume far more time than I
have to give, sadly. I only get somewhere around 5-10 hours a week
anymore to work on bsnes. The PPU would require probably a thousand
work hours to get working well. Still not dying to work on SA-1 and co,
though.
Would be nice if someone would volunteer to write the SA-1/SFX emulation for me :P
Quote: |
I read that you managed to break PGO of the Microsoft compiler, so why are you using it? |
Because MinGW is even worse. It's also GCC 3.x, which lacks PGO anyway.
Quote: |
consider
self modifying code to tweak the performance for different CPU types. I
have thought about it, and it can be done fairly cleanly, a simple jump
table can be used to change into the most optimized implementation for
each function |
A jump table isn't self modifying code. Self modifying would imply me
overwriting program code stored in the binary, and not variables in RAM
(as a block of memory containing function addresses is).
Anyway, this is of no use. I don't have optimized functions for each
platform, I wouldn't know how to write them, and I don't have any
bottleneck functions that would vastly benefit from this. The
bottlenecks are such because I don't want to make the code a horrible
mess just to speed things up.
Quote: |
Sure, wait until the 7GHz comp to finally make something out of SA-1 emulation in BSNES. |
Funny you shold mention this. I've just recently went back over and had
a minor epiphany regarding the implementation of bsnes as a whole,
thanks to me speaking with Nemesis about his Genesis emulator (and
blargg about the same emulator), and the problem of synchronizing chips
that have large shared busses. The reality is that there is no easy
trick to this. You either give up the performance, or the accuracy.
But the neat part is, given that I use threading and not a finite state
machine, the synchronization code is nothing more than a call to
co_switch (effectively a yield() implementation). See where I'm going
with this? The difference in making bsnes' CPU cores opcode-accurate,
ala ZSNES v1.51 and below, SNES9x, etc and bus-accurate, ala only bsnes
currently, is the placement of a dozen #ifdef statements.
I could simply move synchronization tests from the bus read/write
routines, to immediately after the completion of an emulated opcode,
and gain massive speedups at the cost of accuracy. Turn this into a
#define, and it should be possible to emulate chips like the SA-1 on
2-3ghz processors, and yet still have the 'accuracy' be there for
non-SA-1, and hopefully in the future, SA-1 as well. In fact, I may as
well make them two separate versions. Older, ~1.2-1.5ghz PCs should be
able to run bsnes at full speed with opcode syncing. Though I don't
know why they wouldn't just use ZSNES then, but whatever.
(side note: as ZSNES is now implementing cycle-based cores using an
FSM, there's a very slight chance that bsnes could end up being faster
-- yet less accurate -- if I use the above trick, get PGO working again
somehow, and optimize my code, eg CPU IRQ routines (as if). Wouldn't
that be an interesting reversal of roles?)
Now the only problem is the massive investment a true SA-1 emulator
would entail. The SA-1 does so much stuff that nobody even knows how to
emulate. The chip has a dedicated memory controller that actually
modifies the clock rate to the SA-1 to counter bus conflicts. I've
never heard of anything like that being emulated before.
Quote: |
In
general, the LGPL does not require you release any of your source code,
as long as you dynamically link to any LGPL libraries, and release the
code to those libraries if you modify them. |
That might be a problem. I only have static linking at present for
things such as blargg's NTSC filter. I may have to #ifdef that code out
to be able to release a PD version of bsnes in the future, or come up
with some sort of dynamic linking setup that works on both Windows and
Unix, and is still somehow portable. Hmm. Thanks for the feedback.
Perhaps I can use QT, but #error out if it is built on Windows, then. And just use the QPL for it on Unix.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Apr 16, 2007 3:48 pm Post subject: |
|
Ok, so the SA-1 is infinite fun.
But what about some simpler things? Mouse, super scope and multitap is
easier, right? The easiest would likely be the multi tap, considering
it is likely just as advanced as a snes controller(OMG it got shift
registers!).
Btw, If you ask me, do the SFX first, Yoshi island is far better then Super Mario RPG.
Last edited by henke37 on Mon Apr 16, 2007 3:59 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 16, 2007 3:58 pm Post subject: |
|
I
don't mind multitap, I just don't have four controllers to test with at
the moment. I don't want to mess with mouse stuff because mouse stuff
is a pain. The SNES was designed assuming it had a dedicated mouse, but
with Windows et al, it's shared. You either lock the mouse to the
window and piss off people who try and multitask, or you don't and piss
off people who aren't. Maybe ManyMouse will be a good thing to look
into.
On the positive side, I forgot to mention
earlier that I did a lot more work on libui. I believe I now have an
acceptable, finalized API for it. Very clean, very simple. Took out all
the hackish code I needed to get the super-strict OO approach
implemented, and went with a more leniant one. eg:
button.create(window_owner, x, y, width, height, ...);
instead of:
window_owner.attach(button.create(width, height, ...), x, y);
Not as nice from an OO standpoint, but infinitely easier as Windows
does things like demand you give the owner window handle to the
function to create the button, meaning you have to use hidden windows
and reparenting hacks to get the latter API syntax working. Really not
worth the trouble and complexity over something so stupid.
So now all that's missing is the font controls and some window message
bindings, and I should be able to get back to work on finishing up
bsnes' new UI and get another release out. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Apr 16, 2007 4:09 pm Post subject: |
|
You could just let people use joysticks as the mouse. That would actually be something new for snes emulators.
About people multitasking, let them take the consequences for it. Most
people would likely not bother with multitasking during gameplay anyway.
Also, if you do add mouse support, implement trapping of the cursor, it
sucks to move the mouse out of the window and likely missing the action
in the game, hiding the emulator window and or causing unwanted actions
in programs running beside the emulator. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Apr 16, 2007 5:08 pm Post subject: |
|
henke37 wrote: |
I first want to thank Byuu for his efforts in making the most accurate emulator. Thank you!
Then I want to acknowledge that I did read all 101 pages of this thread. (Yeah, I lack a life)
I know you might not agree with me, but I personally would prefer if
you worked on supporting the unsupported chips and input devices
instead of the performance draining dot PPU. I really think that the
performance drain should go to something that most people gain from,
how big would the improvement for the dot PPU be for compatibility? |
As far as we know, the only game which require a dot based renderer is Uniracers. Accuracy does not always means better compatibilty (the new sound core by blargg for example) nor should it necessarily do so imo.
Last edited by Snark on Mon Apr 16, 2007 5:38 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Apr 16, 2007 7:50 pm Post subject: |
|
byuu wrote: |
It's also GCC 3.x, which lacks PGO anyway.
|
Where do you get you information from? Seriously? Do you just decide
what things probably support without checking? The oldest manual for
GCC which I could find online which was for 2.x, ~8 years old lists its
PGO options.
Granted, GCC 3.2 from 5 years ago added some more PGO options than before, but MinGW is currently at 3.4.5.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 16, 2007 8:20 pm Post subject: |
|
Nach wrote: |
Where do you get you information from? |
From you, Nach! ... I got it -- from you!
(bonus points if you get the reference)
Well then, fantastic. I'm sorry I was incorrect. I seem to recall
reading from somewhere that it was added to 4.x, but I guess clearly
not. I'm sorry I don't look up every statement I make to verify it's
factuality when discussing things on a casual message board thread.
I suppose I'll look into this, I already build with GCC 3.x on FreeBSD,
so I could get it working there, then just add that MinGW patcher thing
you wrote and do the same on Windows in the future.
|
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Mon Apr 16, 2007 10:13 pm Post subject: |
|
I also thought it was added in 4.0.
Oh, and it is quite possible to build GCC 4.x for MingW. I'm using 4.1
at the moment, but I saw some 4.2 builds somewhere.
_________________
#577451 |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Tue Apr 17, 2007 3:46 am Post subject: |
|
byuu wrote: |
Nach wrote: |
Where do you get you information from? |
From you, Nach! ... I got it -- from you!
(bonus points if you get the reference)
Well then, fantastic. I'm sorry I was incorrect. I seem to recall
reading from somewhere that it was added to 4.x, but I guess clearly
not. I'm sorry I don't look up every statement I make to verify it's
factuality when discussing things on a casual message board thread.
I suppose I'll look into this, I already build with GCC 3.x on FreeBSD,
so I could get it working there, then just add that MinGW patcher thing
you wrote and do the same on Windows in the future.
|
Hmmm... Sounds familiar. Perhaps from this anti-drug commercial ?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 17, 2007 2:55 pm Post subject: |
|
Yep, you guys are as sharp as a tack :) |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Apr 18, 2007 7:56 pm Post subject: |
|
Could you please make a slightly more advanced joypad mapping system?
My system got a few odd things about joysticks and I just want to use
the keyboard, can you add a way to completely disable joysticks? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 20, 2007 5:52 am Post subject: |
|
I have made the following changes to the S-SMP core, thanks to research from blargg:
http://byuu.cinnamonpirate.com/temp/ssmp.txt
All but one opcode should now be cycle-accurate. Before, we were
speculating the order of cycles, as there is no public documentation on
the cycle breakdown of this chip. blargg came up with an ingenious way
to verify each cycle, and I've added his findings in above.
The only really big change (to incw and decw) I wrote a test to verify
all 64k possibilities and flags against the old method to try and
prevent any new bugs from appearing, but nonetheless if anyone familiar
with C wouldn't mind going over the above text document looking for
errors, it would be appreciated.
New WIP in case anyone wants to try, but I doubt a difference would be noticeable. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Apr 20, 2007 7:10 am Post subject: |
|
where would one locate these WIP builds?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Apr 20, 2007 8:28 am Post subject: |
|
byuu wrote: |
All but one opcode should now be cycle-accurate. |
Do you mean you're certain about all but the one?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 20, 2007 4:40 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Do you mean you're certain about all but the one? |
Well, unfortunately no. I mean I have all but one of blargg's opcode
tests passing now. I can't figure out how to get the other one to pass,
tried every combination I could think of. Something else must be
interfering.
As far as total accuracy, there are obviously certain opcodes we cannot
test for various reasons. And this test only validates the read/write
cycles that do not fetch from [pc++] (as those are exceedingly
difficult to test). Basically, anything that even has a 0.001% chance
of affecting a game's behavior is now tested and verified.
The cycle-based S-SMP I had before was nice and all for being
improvised and a first step, but now the S-SMP core really is mostly
cycle accurate, so we can all thank blargg for that.
Quote: |
My
system got a few odd things about joysticks and I just want to use the
keyboard, can you add a way to completely disable joysticks? |
I don't usually add special code to accomodate broken hardware and/or
software, sorry. But with the next release, you should probably be able
to set system.input to "ui" in the config file, which will effectively
disable joypad support.
---
EDIT: spoke to blargg, fixed the problem. I was calculating TCLR and TSET incorrectly.
Code: |
tset_addr_a(0x0e, |),
tclr_addr_a(0x4e, &~) {
1:dp = op_readpc();
2:dp |= op_readpc() << 8;
3:rd = op_readaddr(dp);
regs.p.n = !!((regs.a - rd) & 0x80);
regs.p.z = ((regs.a - rd) == 0);
4:op_readaddr(dp);
5:op_writeaddr(dp, rd $1 regs.a);
} |
Pass all tests now :)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Apr 22, 2007 4:29 am Post subject: |
|
ever considered emulating the third party x-band modem for SNES?
for those who don't know it supported netplay for these games
* Doom
* Ken Griffey Jr. Baseball
* Killer Instinct
* Kirby's Avalanche
* Madden NFL 95
* Madden NFL 96
* Mortal Kombat II
* Mortal Kombat III
* NBA Jam TE
* NHL 95
* NHL 96
* Super Mario Kart
* Super Street Fighter II
* WeaponLord
more information
http://en.wikipedia.org/wiki/XBAND
http://216.120.247.64/
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 22, 2007 6:22 am Post subject: |
|
Somehow I doubt that's even possible. I mean, if the host network went offline and took all its secrets with it....
Besides, a modern implementation of netplay for all games would
completely supercede that. I doubt anyone wants to relive the glory
days of a 14,400 baud modem. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Apr 22, 2007 7:47 am Post subject: |
|
ha,
no kidding, I know certain purists AHEM don't believe in too many
additional features, but if it were emulating a piece of hardware from
the time then it would be ok.
The network is dead,
but I'm sure there is some documentation yes? Anyways, I figured it was
far fetched, but thought I'd bring it up for discussion.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Apr 22, 2007 9:39 am Post subject: |
|
I
am quite sure it was just an elaborate cheat cart that did roughly the
same thing as netplay used to do or just changed the player status for
the opponents.
Very not needed to be emulated. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Apr 22, 2007 9:52 am Post subject: |
|
Infos about that device are very sparse; not enough to accurately emulate it. (doc)
You could help though; read here for more info.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Sun Apr 22, 2007 3:26 pm; edited 1 time in total
|
|
RobinOfSweden New Member

Joined: 22 Apr 2007
Posts: 1
|
Posted: Sun Apr 22, 2007 2:29 pm Post subject: Sry if already answerd. |
|
Greetings great crafters!
I am a ubuntu 6.10 using little SoB!
And i bet i am not the first one to ask in this thread but after
reading 28 pages my eyes started to hurt so i jumped to the latest post
>_<
(damn this thread is long!)
Anyway my question is for what OS is bSnes built for? i looked at your
site Byuu but i didnt find any info regarding OS (and i got to page 28
then my eyeballs fell out or atleast felt like it)
i also did a search at first page but no hit on Linux there.
Anyway if its a common question i am sry to repeat it but i would love to have an answer.
Thank you and sry if its a bugger question :S
_________________
Ubuntu Edgy 2.6.17-11-generic
AMD Athlon 64x2 Dual Core 3800+
2047MB DDR-SDRAM
GeForce 7900 GT |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Apr 22, 2007 2:36 pm Post subject: |
|
Full Linux support will come with v0.020, after the cross-platform UI is finished. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 29, 2007 3:25 am Post subject: |
|
Thanks to anomie for testing $2100.d7 OAM reset behavior further. I have confirmed his results, and updated my code.
Code: |
//INIDISP
void bPPU::mmio_w2100(uint8 value) {
if(regs.display_disabled == true && r_cpu->vcounter() == (!r_cpu->overscan() ? 225 : 240)) {
regs.oam_addr = regs.oam_baseaddr << 1;
regs.oam_firstsprite = (regs.oam_priority == false) ? 0 : (regs.oam_addr >> 2) & 127;
}
regs.display_disabled = !!(value & 0x80);
regs.display_brightness = value & 15;
} |
This doesn't fix any known games, but is more hardware accurate, so
yeah. My previous findings were wrong. It does update firstsprite, and
it happens whenver the display is disabled and you write to $2100, not
just from a 1->0 transition. Even weirder, this only happens on
scanline 225.
I also updated standard OAM address reset to update firstsprite priority as well.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Apr 29, 2007 3:41 am Post subject: |
|
yay,
one step closer to the next release. How are things going with the
sound, that seems to be the big transition for this and zsnes.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Apr 29, 2007 10:49 am Post subject: |
|
Great news.
I think i can find some games that could be influenced by this.
Just have to wait for a new wip revision
some games we could try:
Final Fantasy - Mystic Quest, RPM Racing, Genjuu Ryodan, Mortal Kombat, Uniracers, Mahjongg Taikai II, tazmania.
and ofcourse the sprite touching issue in Zombies  |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Apr 29, 2007 2:29 pm Post subject: |
|
225 you say... Hmm that could fix Cu On Pa on our side.
Thanks byuu/anomie!
Btw you aren't missing anything in SA-1 to get it accurate it will take
a ton of CPU like you said, my estimates are like 6ghz using ZSNES!
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 29, 2007 3:52 pm Post subject: |
|
I
was under the impression that your Cu On Pa bug was due to NMI timing
... has that changed recently, eg with your new CPU core?
And I apologize by the way, pagefault, I gave you the wrong information
last time about this new behavior (had it wrong myself, full credit
goes to anomie for tracking down the real behavior). I think the fact
that $2100 toggles the display disabled setting is what threw me off
before. We may still be missing a bit on it, though, as I didn't verify
exact cycle timings, what happens if you toggle overscan, etc ... the
new findings should be "mostly" right, however. I should make up a test
ROM for it too, eventually.
Re: SA-1 -- I posted a bit about this over at RHDN, and I've been
planning to write up an article detailing the problem further. Yeah,
6ghz doesn't surprise me at all. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 02, 2007 4:53 am Post subject: |
|
There,
disabled the unused audio resampling filters and completely rewrote
libconfig. It's no longer hackish. I just need to address a tiny issue
with object creation, but that can wait. Thanks to Nach for the Qt API
document link, lots of inspiration there.
I can build again in *nix without -w, and with no errors.
Also finally added back the framerate counter. Threw back in the
out-of-sync execution for CPU<>SMP (only sync when it's needed
for accuracy, instead of no matter what). I was quite surprised, a 27%
leap in performance, hmm. Now I just need to figure out GCC profiling
to really step that up some more.
Le: http://byuu.cinnamonpirate.com/images/bsnes_20070502.png
I'll put up another private WIP shortly. The GUI is still too useless for another public WIP, sorry :(
Hopefully won't be too much longer ... my big concern right now is the total lack of GUI-based input configuration. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 02, 2007 6:15 am Post subject: |
|
byuu wrote: |
27% leap in performance, hmm. Now I just need to figure out GCC profiling to really step that up some more. |
Wow, that puts the lowest core 2 models back into the clear again. No more 59fps crackling for me The possibility of profiling coming back on top of that is great news for the P4-gen.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu May 03, 2007 8:16 am Post subject: |
|
Woah. a combination of placebo and new speedier code feels a lot more like a real snes now.
Still many games grind to a halt on my system though
I haven't found any regression though, so thats good news! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 03, 2007 6:59 pm Post subject: |
|
Thanks
for testing the new beta for me, I apologize again for the speed issues
you guys have to bear all the time. I'll see about switching to MinGW
and using its' profiler instead of MSVC's for the next release, but
that's a rather radical change for me.
Below is
pretty much the same dual-emulator idea I've been talking about for the
past few months now ... no reason to read below unless you're really interested in reading a rehash of it again with my current thoughts on the matter.
I've looked into decoupling the S-PPU from the S-CPU again, but unfortunately only have bad news.
After talking things over with anomie, he has a solid theory that's
most likely correct: the S-CPU does not have internal H/V counters to
handle NMIs and IRQs. And indeed it couldn't. It wouldn't know about
S-PPU settings that change how many clocks are on each scanline, and
even how many scanlines there are per field. Most likely, the S-PPU
emits the H/V blank status flags to the S-CPU, which is mirrored at
$4212.d6,7 as an output. It can use these to note 1->0 transistions
to reset its' own internal H/V counters. These would obviously ignore
S-PPU side effects like long dots, and that is indeed consistent with
what we've noticed on hardware.
This also explains "dead spots", eg VTIME=261,HTIME=339, where IRQs
never fire. $4212.d7 sets and clears on HCOUNTER=0, whereas $4212.d6
sets and clears on HCOUNTER=2. This two-cycle difference explains the
two-cycle delay for NMI triggers, as well as the ten/fourteen cycle
delays for IRQs (the extra 4-8 cycles there are based on internal
calculation overhead. I suspect the test is pipelined in some way).
Now, the big problem is the current design of bsnes. When I started on
bsnes, I didn't know what I know now. I setup the S-CPU to keep track
of the counters, and enslaved the S-PPU to the S-CPU. The reality is
that to decouple it, this setup would no longer work. The S-PPU handles
the counters and that is where they belong.
So, if the S-CPU polls the S-PPU's V/H status flags every clock tick,
that means I will have to run the S-PPU at either ~5.25mhz or ~10.5mhz,
and I will not
be able to allow them to drift apart, they will have to run in
lockstep. To give you an idea of lockstep, remember the speedup I just
added that raised speed by ~27%? That was by allowing things to run out
of order between the 1mhz S-SMP and the 2.5mhz S-CPU. And now I'm
talking about being forced to lockstep two 10.5mhz processors.
The differences with the counters will make implementing my current
cores with the new cores as an option impossible. I will need to fork
both the S-CPU and the S-PPU, as well as the thread scheduler, to
support both the scanline-based renderer and the new CPU renderer.
Being one person, I can't really maintain both of these cores at the
same time. However, I'm fairly confident that we've pretty much done
the best we possibly could already. With the exception of Uniracers 2P
mode, we have exactly one known bug. I really don't know what else I
can improve with my current model.
However, again as I've stated in the past, forking this will
effectively kill any prospects of running bsnes at fullspeed anywhere.
But I can most likely add compile-time options to allow use of both the
old, discontinued CPU+PPU combination, or the new CPU+PPU combination.
If anyone was interested, perhaps they could become the maintainer of
the new CPU+PPU combo? A longshot, of course ...
Does this sound reasonable? I wanted to make the S-DSP before working
on the S-PPU, but I can probably piece the scanline renderer into the
new PPU renderer, and just improve on it where needed (eg fix the OBSEL
thing that causes the horizontal flickering as a first step, slowly
improve timing with new research, etc). If I decide to work on the
S-DSP, I can just switch back to the old CPU+PPU combo and continue on
there.
The CPU+PPU are nicely isolated already from the SMP and DSP (which are
both completely independent already), so that's good ...
Ultimately, I'm really starting to feel that the idea of combining the
utmost in accuracy with playable speeds is just unrealistic. It really
might be better to just allow a 'clean' implementation of the SNES,
that runs as fast as possible, doesn't blatantly cheat accuracy, but
ignores the more esoteric 'glitchiness' of SNES hardware (eg mid-frame
PPU register writes, mid-opcode bus communication syncing, etc) to
implement an 'ideal' SNES system that people can use who want to
actually play games on bsnes. It will still have the advantage of
having really accurate algorithms for effects like mode7 rendering and
such, and will work just fine in 98% of cases where the added accuracy
is just wasted as the games do not need it. And then have the separate
emulator model where accuracy is the only thing considered, so there's
no stress on my part for adding something that cuts into speed more ...
it won't matter as it won't run at full framerate anyway. If anything,
it can serve as a 'correct' implementation that shows how the SNES
really works, and can maybe be put to use in the future.
Those who are wanting as much accuracy as they can get with current
top-of-the-line CPUs will have exactly that with v0.020. I won't be
able to raise compatibility any further with my current model, so
there's really not much reason to keep waiting, right? |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu May 03, 2007 8:05 pm Post subject: |
|
Sounds
good and reasonable to me, just be sure you have both versions of Bsnes
set up the way you want them - I imagine you'd like to use it to play
games on yourself sometimes! To what extent can you isolate this
change? That is, would you still be able to improve the 'old' setup if
new information unrelated to the PPU comes up or would it effectively
become part of a different codebase? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 03, 2007 8:13 pm Post subject: |
|
I could easily keep everything but the new S-CPU and S-PPU synchronized with the old v0.020 core.
Another option I'm willing to entertain is releasing v0.020 under a BSD
or Apache-style license, if someone else would be willing to maintain
all of the changes with the old port. It would free up a lot of work
from me, but at the same time I kind of want to have my own personal
emulator for playing games on and such.
Meh, well I already have the CPU and SMP cores that would be 1:1 shared
between an accurate and fast version ... it would just be the glue code
to add in the rest of those chips that would change between the two
versions. Perhaps I can rig up some sort of setup.
Still need to plan this out more, and I still have months to go before
the new UI is completed. The input configuration panel is positively
haunting me at the moment. There's just going to be no easy way to pull
that off on both Windows+Linux ... |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri May 04, 2007 12:46 am Post subject: |
|
byuu wrote: |
Ultimately,
I'm really starting to feel that the idea of combining the utmost in
accuracy with playable speeds is just unrealistic. It really might be
better to just allow a 'clean' implementation of the SNES, that runs as
fast as possible, doesn't blatantly cheat accuracy, but ignores the
more esoteric 'glitchiness' of SNES hardware (eg mid-frame PPU register
writes, mid-opcode bus communication syncing, etc) to implement an
'ideal' SNES system that people can use who want to actually play games
on bsnes. It will still have the advantage of having really accurate
algorithms for effects like mode7 rendering and such, and will work
just fine in 98% of cases where the added accuracy is just wasted as
the games do not need it. And then have the separate emulator model
where accuracy is the only thing considered, so there's no stress on my
part for adding something that cuts into speed more ... it won't matter
as it won't run at full framerate anyway. If anything, it can serve as
a 'correct' implementation that shows how the SNES really works, and
can maybe be put to use in the future. |
Quote: |
Sounds good and reasonable to me |
(too)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri May 04, 2007 1:06 am Post subject: |
|
I
would just add that the current strategy is well-tested and assuredly
accurate. After that 27% speed bump, you did something I thought was
important. You guaranteed any core 2 model 60fps minimum. Profiling
would be further padding. So on June 3, when Intel releases a $50
single core based on Core 2, bsnes' speed is better viewed as an
incentive than a problem. Moreover, a superfast version with bugs is
sooner or later going to look rather pointless next to .020.
Also, now that I've typed it, I want to propose that you bump up to .20
for your next release (no more thousandths). Chiefly, I hate typing
that eternal 0
But otherwise, your emulator's state deserves more credit, and .020 is
minuscule enough to make people have negative assumptions about it. At
this release pace, your ideal of 1.0 would stay safe.
byuu wrote: |
Still
need to plan this out more, and I still have months to go before the
new UI is completed. The input configuration panel is positively
haunting me at the moment. There's just going to be no easy way to pull
that off on both Windows+Linux... |
Get sick again and do what you did with IRQs
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri May 04, 2007 6:55 am Post subject: |
|
Snark wrote: |
Quote: |
Sounds good and reasonable to me |
(too)
|
Yup.
_________________
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: Fri May 04, 2007 8:05 am Post subject: |
|
I
have to agree whit what fitzroy said, as soon as you have got the ui
completely working again, your emulator will officially have 3 known
game bugs, all caused by the same problem that your current model
cannot fix.
personally i feel bsnes deserves a mayor bump in version number.
What you could do, is release a special old-model final version that hack fixes those 3 games.
Bsnes Final for me would be all special chips and hardware emulated,
all as accurate as humanly possible. eventhough it wouldn't be playable
on current systems (it will be in the future).
The good thing about Bsnes is that it is open source, there could be
many advantages later by recoding snes for SSE4, 64bit, multicore and
so forth.
eventhough sync's take most of the cpu time, mame also managed to
squeeze out some extra fps by offloading some processes to the 2nd core.
Given enough time and optimizations even bsnes final will become fully playable.
(mame and mess dont care if a game will ever be playable, and year
after year new systems become playable, even those that supposedly
needed 6+ghz systems) |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Fri May 04, 2007 11:35 pm Post subject: |
|
I
was recently introduced to a lock-less wait-less algorithm for
readers/writers to provide their most recent state to each other.
That kind of thing might be very useful in keeping coherent system
state between multiple threads without the performance hits you take
from mutexes. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat May 05, 2007 4:11 am Post subject: |
|
I
would like to keep with my versioning numbers. I do believe there is a
very small chance I may make more than 100 releases, and it's been a
tradition since I started the project.
I've been
thinking more about it ... assuming my mind doesn't change by the time
I more or less complete the new UI, my plan is to make one last release
of bsnes, and then take the project back to its roots.
However, though I never initially set out to, I did actually end up
creating a useful emulator that end users can enjoy, and I would hate
to see it die just because I personally want to move on ...
After reading more about the sad state of the public domain's legal
protections against companies claiming copyright over code and
successfully suing others, I've decided that perhaps a BSD-style
license might be best. Simply, maintain copyright but still grant all
rights possible.
Now, my question is, if I were to release the next version of bsnes
under the BSDL, would anyone in the community be interested in taking
ownership of the codebase at that point? Yes, a fork. I will grant full
permission to relicense the work under GPL if desired, to set up a
source repository somewhere and have multiple committers, whatever is
wanted, ala ZSNES and SNES9x currently. The only condition will be that
the project will have to be renamed to avoid confusion. I'd like to
keep the bsnes project name for my own work. Other than that, the new
owner would be free to take the project in any direction they choose.
Be it adding savestates, special chip emulation, a hack for Uniracers,
bump the new emulator's version number to .20 as requested ...
whatever, I won't stand in the way.
I'm looking for someone with a high emulation-scene reputation, so that
the project won't simply stagnate and fail in a month.
I will even assist with programming where possible. But I know with my
limited time I simply won't be able to maintain two ports myself. A lot
of the stuff I want to do will directly conflict with the current port.
For example, I will be removing all video filters, Sufami Turbo
support, frameskipping, reverting the video renderer to be purely
512x478, etc. The idea for these changes is to simplify the codebase as
much as possible so that user-friendly features do not impede my
progress or decrease the readability of the code. If it won't run at a
useable framerate anyway, there's no point in preserving these
features. The new bsnes will be solely devoted to being a
self-documenting SNES emulator used to assist other emulators and
possibly to be used far, far in the future.
Again this is still all pretty much up in the air. It's going to be
very hard for me to abandon my current creation, but there's really not
much more I can do for it alone at this point :(
So ... any takers if I do decide to take this route?
Quote: |
I
was recently introduced to a lock-less wait-less algorithm for
readers/writers to provide their most recent state to each other. |
I'd be interested in hearing it if you didn't mind ...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 05, 2007 5:37 am Post subject: |
|
Just
thinking out loud here, but it seems like what you want to do, byuu,
would actually be possible for a slower system like the NES. From what
you know now and explained in your posts, total accuracy + playability
does look "unrealistic" for the SNES with today's cpus. But going back
a generation might be very possible. One could actually strive for
total accuracy from the beginning without fretting about playability
(and the consequent time spent writing inaccurate cores). The GUI from
bsnes would be largely transferable, and I assume there is good
documentation and at least a few similarities between the two systems.
By the time it was done, tech may have improved enough to make the same
goal realistic on the SNES. Ever consider doing something like that
after .020, byuu, or are you pretty much wanting out of the emulator
business after bsnes? 
I understand it completely (RL is a bitch), but it's always sad when an
emulator author decides to call it quits, considering the immense
knowledge they've accumulated about writing an emulator. When you do,
it will be especially sad, because I think the scene needs your
philosophies about coding and GUIs, and those are less likely to be
passed on than actual system knowledge. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat May 05, 2007 6:30 am Post subject: |
|
FitzRoy wrote: |
, but it's always sad when an emulator author decides to call it quits,
considering the immense knowledge they've accumulated about writing an
emulator. |
For me, making one last release of his current emulator (let's call it
"bsnes user-friendly") and then starting a completely new bsnes, one
that would put the focus solely on accuracy/harware documentation is
not "calling it quits".
Concerning a new maintainer of the "old" bsnes. Hmmm...The emulation
scene is not exactly American idol where everyone and their grandma
wants to be a part of it...Ideally, I assume anomie would be the best
since he's both extremely knowledgable about the Snes and (I suppose)
quite a bit familiar with bsnes since he contributed before.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 05, 2007 7:08 am Post subject: |
|
Snark wrote: |
FitzRoy wrote: |
, but it's always sad when an emulator author decides to call it quits,
considering the immense knowledge they've accumulated about writing an
emulator. |
For me, making one last release of his current emulator (let's call it
"bsnes user-friendly") and then starting a completely new bsnes, one
that would put the focus solely on accuracy/harware documentation is
not "calling it quits".
|
I'm not really referring to byuu specifically with that comment or the
scenario he presents about creating a simplified version. All I'm
saying is that it's inevitable for authors, including byuu, to quit at
some point, either because they're burned out or because they don't
have the time anymore.
Also, I'm not really sure I caught the difference between the proposed
clean version and .020. I don't know what could be removed from .020 to
increase speed but not break games. But I'm all for a version that
increases speed without affecting compatibility or resorting to
discreet game-specific hacks.
By the way, isn't anomie working on snes9x now? What ever happened to Overload?
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat May 05, 2007 8:18 am Post subject: |
|
byuu wrote: |
I will be removing [...] Sufami Turbo support |
Just curious, do you plan to add it later, or never since it doesn't concern the base unit?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat May 05, 2007 9:25 am Post subject: |
|
well
didn't he say something about eventual addition of external chips when
the main core is 100% accurate and emulation of these chips is feasible.
what about the S-DD1 chip and C4 chip? Are they going to be taken out?
Do they have 100% accurate emulation? and is the Sufami Turbo accurate?
hope I'm not asking redundant questions.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Sat May 05, 2007 4:43 pm; edited 1 time in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat May 05, 2007 11:18 am Post subject: |
|
Afaik the Sufami Turbo doesn't really use special chips, it just combines two ROMs. I might be wrong there though.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat May 05, 2007 12:19 pm Post subject: |
|
Going
'back to basics' does sound compelling if it will allow you to keep
track of everything. Perhaps I'll be able to contribute some extras
back into it someday.. (when I get better at programming) What
licensing will you use for the new bsnes? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat May 05, 2007 1:49 pm Post subject: |
|
I
was thinking, if you just make an extremely accurate emulator, you
could always look at optimizing or making a user friendly port of that
emulator at the end of the track.
I believe that
is somewhat how emulators like model2 and zinc handle things, adding
some optimalizations to the code that wouldn't strictly be 100%
accurate, but would create indistinguishable results for the end user. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat May 05, 2007 3:58 pm Post subject: |
|
Again,
I'm considering releasing under BSDL at this point for licensing. I
want to be able to protect my code from being copyrighted by someone
else, and I unfortunately have heard too many conflicting opinions on
what PD exactly entails. BSDL doesn't take away any rights anyways.
I'd only take out Sufami Turbo because it is too much of a mess to
support loading multiple ROM files and SRAM files and such. It would
stay in v0.020. Special chips are largely separated. As I don't emulate
any kind of timing for them, they're just pokes at RAM locations, so
they can stay neatly 100% isolated from the core, and removed in
seconds if desired.
Chips like SFX and SA-1 are different, as they require active emulation
of an additional coprocessor. Realistically, the other chips need the
same thing, but we never bothered with that.
I will also have to look more into the Cx4 code I use. I'm intending to
make v0.021+ 100% purely BSDL, and most of that code belongs to SNES9x
and ZSNES.
Again, all of this will stay for .020.
As far as how to speed up .020, it would be by dropping the philosophy
of making everything look exactly like hardware, even when it's not
necessary.
For a 10% speed boost, one could drop the cothreads between the SMP and
DSP, and simply enslave the SMP to the DSP, since they run at evenly
divisible clock rates off the same oscillator. The reason I don't do
this, is because strictly speaking, the SMP and DSP are separate chips.
It doesn't seem right to make one have knowledge about the other,
however it won't hurt anything to the end user to do this.
For a 40% speed boost, one could rewrite the IRQ testing code to range
test instead of testing every single clock position. I've tried, but I
keep running into bugs and got tired of how messy that looked.
For a 30% speed boost, one could start building bsnes with MinGW +
profiling, or fix MSVC + profiling, if that's even possible.
Combine all of those, and with the skew from each boost adding in,
you'd have an emulator that was about twice as fast, and just as
accurate.
Quote: |
By the way, isn't anomie working on snes9x now? What ever happened to Overload? |
anomie is, and is quite busy with real life in addition. I wouldn't
want to bother or ask anyone directly to do this for me, it'd only be
if they wanted to do it and had time to.
As for Overload, good question. I haven't seen him in forever. The last
preview release of Super Sleuth was on 2006-02 :(
He's one of maybe four or five people with complete, detailed knowledge
of the entire SNES still in the emulation scene.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 05, 2007 6:00 pm Post subject: |
|
byuu wrote: |
As far as how to speed up .020, it would be by dropping the philosophy
of making everything look exactly like hardware, even when it's not
necessary. |
Makes total sense to me to do it that way because the current version
already contains hardware inaccurate aspects (i.e. the scanline
renderer). Might as well just take it all the way and have a separate
one for no-holds-barred accuracy, right?
Quote: |
For a 40% speed boost, one could rewrite the IRQ testing code to range
test instead of testing every single clock position. I've tried, but I
keep running into bugs and got tired of how messy that looked. |
Yeah, it's too bad that it broke some games because that was a huge
boost. The other two don't look very dangerous.
Quote: |
anomie is, and is quite busy with real life in addition. I wouldn't
want to bother or ask anyone directly to do this for me, it'd only be
if they wanted to do it and had time to.
As for Overload, good question. I haven't seen him in forever. The last
preview release of Super Sleuth was on 2006-02 
He's one of maybe four or five people with complete, detailed knowledge
of the entire SNES still in the emulation scene. |
Thank goodness for blargg, though! Wouldn't want to have his contributions go unnoticed.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun May 06, 2007 3:10 pm Post subject: |
|
Byuu, would you please give me your opinion on this post i made on mameworld.
It looks like the needed cpu power is closer than we thought
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=110198&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=
EDIT:
ive been thinking, my bet is from now on any application should be
written with core2duo or higher in mind and if i remember correctly
both byuu and FitzRoy now have one. Some time ago Byuu wrote a
benchmark for some algorithm or opcode, one cpu won that battle , i was
thinking if these benchmarks are redone, this time looking at which one
wins on the core2duo and assuming thats the opposite one of the one we
are using now, that could mean a major speed jump for core2duo
processors, also if we keep focusing on core2duo it could be a good
idea to go multi-core and offload all the rendering and filters to the
2nd core.
finally if you could fix the profiling problems, compiling an SSEE3
build could result in another speed jump (combined this could result in
more than 100% speed increase on a core2duo chip theoretically) |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun May 06, 2007 6:05 pm Post subject: |
|
Heh,
I had the same thought this morning. I think bsnes should be compiled
with SSE2 instructions atleast and (right now) SSE3 at most. The
problem with SSE4 right now is that it comes in three
different parts. AMD will be including SSE4a with Barcelona, Intel will
be introducing SSE4.1 with Penryn and SSE4.2 with Nehalem (and SSE3+
with the 45nm Core 2 Duos coming soon) so right now it's all sorts of
confusing and unhelpful. One thing that should help with these things
would be if Byuu had some good hosting so he could upload multiple
(semi-private?) builds compiled with different optimisations.
I've been making some custom shaders for Pete's OpenGL 2 plugin lately,
and I think it's a very convenient way of going about video filtering..
even if you do need a fairly high-end card for it to work at full
speed. Especially since a lot of custom shaders have already been
written. Might be too much trouble to add OpenGL 2 rendering in the
first place though.. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun May 06, 2007 6:32 pm Post subject: |
|
Yes,
being able to host multiple builds would be very useful. There's still
the very trivial to add +40% speedhack of syncing only between opcodes
(ala ZSNES and SNES9x) that, combined with the other speedups mentioned
above, may even see bsnes running on a vanilla 1GHz box at full speed.
Though this one loses a little accuracy, if you only have a 1GHz
machine, it's better than nothing, right?
SSE2 gives me a 5-10% speedboost, here.
As for OpenGL 2 support, I'm actually very
interested in the idea. I just don't know how to get started. Ideally,
I want to work with the raw libs and avoid SDL like the plague (that it
is). And it needs to work on both Windows and Linux.
Speaking of video cards, I recently picked up a new one. My 6600 LE was
just vastly out of place in my new C2D system, so I replaced it with an
8800 GTS (wanted an 8600 with HDCP, but the 8800 was $30 more than the
lowest 8600 with HDCP, the 8600 GTS, and 3x faster, so whatever). This
should be far more than adequate to implement some pixel shader
filters. And I really like the idea of having external PS files. Then
my code doesn't have to be cluttered with software filters, and since
you already need a high end system anyway, most people will likely
already be able to use OGL2 shaders anyway. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun May 06, 2007 8:33 pm Post subject: |
|
Good
to hear you're interested, it'd be great to have such a good selection
of filters to use in bsnes. As for where to start, maybe you can get in
touch with Pete Bernert? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon May 07, 2007 6:36 am Post subject: |
|
Byuu, I have a question about something you talked about a few posts back.
You said you were thinking of making one emulator that represents an
"ideal SNES", which doesn't emulate all the little glitches and stuff.
And then make another emulator that attempts to emulate the SNES to
100% accuracy.
What are the approximate speed and accuracy differences between these
two? Obviously, with the 100% accurate emulator, you are going for 100%
compatibility. But how many games require the super-precise
glitch-emulating code?
Do you already have the ability to create this "ideal SNES" emulator?
I'm just interested in knowing more about how all this would work.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon May 07, 2007 12:58 pm Post subject: |
|
Jipcy wrote: |
Do you already have the ability to create this "ideal SNES" emulator? |
Well, considering that the "100% like the real thing" is a more
complicated version of an "ideal SNES" emulator, and that bsnes already
emulates the real SNES almost perfectly... 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 07, 2007 6:42 pm Post subject: |
|
Ok, let's use examples.
Ideally, IRQs would trigger when they are supposed to, not 10-14 clocks
later. But on real hardware, they do not. As a result, you have to
perform lots of clock timeshifting to perform the tests, slowing things
down.
Ideally, DMA and HDMA would happen immediately, without the sync
delays. The sync delays always complicate and break stuff. Removing
them would be a minor speedup.
Ideally, games would be written well enough to handle fault tolerances
of 2-32 clock ticks, so things like cycle-level processor emulators
would not be needed. Instead, we'd only sync once every opcode. Major
speed boost here.
Ideally, all video frames would be 262 scanlines long, and all
scanlines would be 1364 clocks long. Writing to most PPU registers
mid-frame would be ignored, especially the overscan setting.
The point was to make a fast SNES based on logical specs, as if the
SNES were some sort of software virtual machine, rather than an actual
hardware device with all of the quirks that come with it. It would be a
lot faster, but would lose ~1-2% compatibility to the real thing.
And to answer the question, no. I really don't have the time / means to
maintain both. I'm still hesitant about having to kill off the playable
version of bsnes to work more on accuracy, though. It's the only
non-derivative SNES emulator with a native GUI that matches my XFCE
desktop, for one. Other stuff that I want, I could add with time, too.
But not if the differences between my new emulator and the old bsnes
increase too much. Be too hard to port the changes backward.
At the very least, I should absolutely finalize my Video / Audio /
Input abstractions, so I can easily add in new stuff like an OpenGL
renderer whenever I eventually make it, and use it on the old bsnes.
Still
battling the input config screen thing. The keyboard input part should
be trivial to support, but the joypad polling would only come from the
Input class. It's basically X-Windows' lack of a decent way to poll the
hardware keyboard state directly that complicates this so much. |
|
|
PFUNK Lurker

Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
|
Posted: Tue May 08, 2007 1:52 am Post subject: |
|
I have this sinking feeling that my "like new" laptop running Ubuntu that can barely run a game like gusanos is not going to like bsnes very much. But I will make them love one-another.
_________________
I'm hot for you and you're hot for me ooka dooka dicka dee. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue May 08, 2007 7:04 am Post subject: |
|
Luckily,
emulators have vastly different hardware requirements then regular
games. Emulators need fast CPUs, normal games need fast GPUs.
Laptops usually uses less good GPUs. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed May 09, 2007 10:21 pm Post subject: |
|
What
I'm a bit worried about is documentation. There's now very good public
documentation on the NES (some of it by blargg) and pretty much nothing
on the SNES outside of the crumbs you can pick up here and on the
Development thread on this board. If byuu gets hit by a truck tomorrow
nobody may never know how IRQs work again  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed May 09, 2007 11:09 pm Post subject: |
|
That's why we devs love the anomie docs.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed May 09, 2007 11:46 pm Post subject: |
|
Yes,
I have a copy, but it doesn't cover all this up-to-the-minute stuff,
and I'd rather not bother anomie every month to see if it's updated 
ETA: BTW, if that's your blog, I love the reviews of the file dialogs.
Qt is really awesome, I just wish it was LGPL so I could use it for all
my Linux porting.
Last edited by Arbee on Wed May 09, 2007 11:59 pm; edited 3 times in total |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed May 09, 2007 11:55 pm Post subject: |
|
Arbee wrote: |
Yes,
I have a copy, but it doesn't cover all this up-to-the-minute stuff,
and I'd rather not bother anomie every month to see if it's updated  |
He updates them all the time.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 10, 2007 1:10 am Post subject: |
|
Quote: |
If byuu gets hit by a truck tomorrow nobody may never know how IRQs work again ;-) |
I keep meaning to document all of this stuff, I just never have the
time. And I really, really need to sit down and write up a real content
management system. My current method, even with PHP generating the site
itself from text files, is still a huge pain. I refuse to use packaged
sites, though. Sigh, perhaps after Der Langrisser's translation is
released ... heh.
Quote: |
ETA:
BTW, if that's your blog, I love the reviews of the file dialogs. Qt is
really awesome, I just wish it was LGPL so I could use it for all my
Linux porting. |
Agreed. It's a huge problem that to use a widget set, you have to give up your rights on the code you
write, or pay huge licensing fees for a free as in beer application.
Don't use it? Sure, but that just hurts Linux users a whole lot more.
Even Microsoft doesn't try and pull that one on its' developers :(
As a result, I've had to use GTK+, which is notoriously difficult to
try and program for. The listbox control code was absolutely maddening.
It looked like a really awful PhD thesis project -- you know, take
something simple, and make it as ridiculously complex as you possibly can to look overly intelligent.
I don't suppose you ever figured out how to capture keyboard input,
other than by capturing the keyboard events sent to individual windows?
There has to be some way to capture the realtime state of each key on
the keyboard, regardless of the active window ... it's critical I be
able to do that to avoid half-ass hackery in my input configuration
window.
By the way, how do you handle the LGPL? I assume all of your emulators
are open source anyway, to meet the static linking requirement? Or do
you actually create a wrapper through a dynamically linked library for
it?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 1:59 am Post subject: |
|
byuu wrote: |
There has to be some way to capture the realtime state of each key on the keyboard, regardless of the active window
|
That is a major security hole. Any program could just start key
logging. Although Linux for example has evdev which allows that IFF you
have read permission to it, which on good distros only root has.
byuu wrote: |
By the way, how do you handle the LGPL? I assume all of your emulators
are open source anyway, to meet the static linking requirement? Or do
you actually create a wrapper through a dynamically linked library for
it? |
If it's LGPL you just link to it or even include the unmodified source code in your program.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu May 10, 2007 4:34 am Post subject: |
|
Quote: |
If byuu gets hit by a truck tomorrow nobody may never know how IRQs work again ;-) |
byuu wrote: |
I keep meaning to document all of this stuff, I just never have the time. |
For the record, I have kept anomie up to date on all my S-DSP findings,
and his latest apudsp.txt covers all the details. My S-DSP emulator is
also written in a mostly clear way.
Nach wrote: |
If it's LGPL you just link to it or even include the unmodified source code in your program. |
My understanding is that you have to provide the user a way to
incorporate new versions of the LGPL code into your program without
your help. So you either make the LGPL code into a DLL and dynamically
link with that, or provide the full source code for your program (under
whatever license you want, as long as this allows the user to compile
it). Maybe you could provide just the object files (.o) for your
program, allowing the user to still statically re-link with new
versions of the LGPL code, but not see your source code.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 10, 2007 6:03 am Post subject: |
|
Quote: |
That is a major security hole. Any program could just start key logging. |
There's plenty of ways around that problem. One simple way would be to
only alert the current application to keys pressed inside windows that
belong to its' own process. Being able to get the realtime status of a
key without the need of hooking every single widget's input capture
routine to update a global status pool would be an incredibly handy
feature. My problem is not that I can't implement such a massive widget
hook system for all active windows, but rather that it doesn't fit in
well with my Input class system at all. I have to pass it messages from the UI, which is just absurd.
Quote: |
My
understanding is that you have to provide the user a way to incorporate
new versions of the LGPL code into your program without your help. |
Yeah, exactly. That seems rather insane, to host a bunch of .o files
like that. I can understand wanting to license your own project like
that, but for something as critical as a widget toolkit? It really
should be BSDL or PD. It's kind of sad that you have less restrictive
licensing for using Windows
APIs than most Linux ones. So then, I would at least assume that the
LGPL license is fine for GTK+, as you typically dynamically link
against those libraries anyway, right? Simply calling the API functions
would not affect the users' ability to modify the GTK+ library itself,
and then rerun the application.
Nonetheless, I
still intend to contribute back a little. Linux and BSD make incredible
desktop systems, so the licenses obviously work in one way or another.
Still trying to find something for my code between BSDL and PD. Need to
research copyright law a bit more, as the only thing I'm concerned
about is preventing others from copyrighting my work and then suing
others who use it.
To me, just the idea of losing the right to do what I want is more
upsetting than the actual rights lost, silly as that is. I've never had
any intentions of not releasing full source code for anything I've
worked on. I only do that when other people are involved in the project
and don't want the work to be publically released.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 7:49 am Post subject: |
|
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly.
blargg wrote: |
Nach wrote: |
If it's LGPL you just link to it or even include the unmodified source code in your program. |
My understanding is that you have to provide the user a way to
incorporate new versions of the LGPL code into your program without
your help. So you either make the LGPL code into a DLL and dynamically
link with that, or provide the full source code for your program (under
whatever license you want, as long as this allows the user to compile
it). Maybe you could provide just the object files (.o) for your
program, allowing the user to still statically re-link with new
versions of the LGPL code, but not see your source code.
|
Read it carefully. If you don't modify the library in any way, you're
allowed to make an executable and do whatever with it.
It only gets more complicated when you want to modify the LGPL library.
This part is of major signifigance:
Code: |
A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library". Such a work, in
isolation, is not a derivative work of the Library, and therefore falls
outside the scope of this License.
|
The LGPL can't force you to do anything to your program if you're only
linking against it using function calls and data structures.
Also read this.
Now WP says this line "Essentially, it must be possible for the
software to be linked with a newer version of the LGPL-covered program.
", although I don't see that in the license itself and not sure where
they got that from. But even if that is the case, since byuu
distributes the source to his application, it is possible, and thus
doesn't matter. It also wouldn't be a problem if the source wasn't
distributed if it was linked how we link to msvcrt.dll or libc.so
_________________
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 Thu May 10, 2007 8:06 am; edited 2 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu May 10, 2007 8:01 am Post subject: |
|
I'm
curious, what's stopping you from making your own license? Would that
be less valid than LGPL or BSDL because it's not a standard? Does a
license need to be licensed? o.o |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 8:02 am Post subject: |
|
Verdauga Greeneyes wrote: |
I'm
curious, what's stopping you from making your own license? Would that
be less valid than LGPL or BSDL because it's not a standard? Does a
license need to be licensed? o.o |
You can't just grab someone else's work and make up your own license to use it under.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Thu May 10, 2007 9:58 am Post subject: |
|
Nach wrote: |
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly.
|
um, if you're talking about the doc I think you're talking about, it's available at Romhacking.net anyway so it's not exactly a private document (don't know how up-to-date Romhacking.net's files are,though).
Last edited by zidanax on Thu May 10, 2007 10:03 am; edited 4 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu May 10, 2007 9:59 am Post subject: |
|
Nach wrote: |
You can't just grab someone else's work and make up your own license to use it under. |
Ah, uh, right. Forgive me, mindblank ^_^;
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 10:41 am Post subject: |
|
zidanax wrote: |
Nach wrote: |
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly.
|
um, if you're talking about the doc I think you're talking about, it's available at Romhacking.net anyway so it's not exactly a private document (don't know how up-to-date Romhacking.net's files are,though).
|
No, they don't. As Romhacking.net distributes old
docs. I like to go to the official location for sources when possible,
because then I know I get the latest ones, especially when the official
source updates every few weeks.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu May 10, 2007 12:31 pm Post subject: |
|
Nach wrote: |
zidanax wrote: |
Nach wrote: |
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly.
|
um, if you're talking about the doc I think you're talking about, it's available at Romhacking.net anyway so it's not exactly a private document (don't know how up-to-date Romhacking.net's files are,though).
|
No, they don't. As Romhacking.net distributes old
docs. I like to go to the official location for sources when possible,
because then I know I get the latest ones, especially when the official
source updates every few weeks.
|
20 days old is Old? 
All of Anomie's docs on RHDN are from April 21st, 2007. That includes
the latest version of all but two and they are scheduled for update.
Quit spreading untrue BS about us having old documents. I don't appreciate 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.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu May 10, 2007 2:43 pm Post subject: |
|
Quote: |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly. |
Great apologies. I had been given the link in IRC a few times and was
never told that it was not to be posted publicly. Since
romhacking.net's copies have been updated recently, I'll link to those
in the future. Thanks for the heads-up.
blargg wrote: |
My
understanding is that you have to provide the user a way to incorporate
new versions of the LGPL code into your program without your help. [...] |
Nach wrote: |
Read it [LGPL] carefully. If you don't modify the library in any way,
you're allowed to make an executable and do whatever with it. It only
gets more complicated when you want to modify the LGPL library. This
part is of major signifigance:
LGPL wrote: |
5.
A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library". Such a work, in
isolation, is not a derivative work of the Library, and therefore falls
outside the scope of this License. |
The LGPL can't force you to do anything to your program if you're only
linking against it using function calls and data structures.
|
I've read the LGPL carefully and the next paragraph (and section 6) supports my view (as does the GPL vs LGPL thing you mentioned):
LGPL wrote: |
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. |
The idea of the LGPL to me seems to be a miniature GPL, where the user
retains freedom to edit/improve the LGPL portion of any program using LGPL code.
As for the first paragraph you quoted, I understand that as applying to a program which can optionally use the LGPL work, either an executable which dynamically links to it, or source code which can be linked with it.
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Thu May 10, 2007 3:07 pm Post subject: |
|
zidanax wrote: |
Nach wrote: |
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't distribute details publicly.
|
um, if you're talking about the doc I think you're talking about, it's available at Romhacking.net anyway so it's not exactly a private document (don't know how up-to-date Romhacking.net's files are,though).
|
Eh.. I thought Nach was talking about most of snes9x's code, as it was written by Jerremy and Gary..
-shrug-
_________________

<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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 10, 2007 4:02 pm Post subject: |
|
I've read over the official LGPL license,
in its entirity, multiple times. I come to the same conclusion as
blargg. Though I could still be wrong. This is why I don't like overly
complex licenses like this, you need a lawyer to fully understand their
implications.
Also, I've been researching PD works
a little more. Though everyone seems to have a different opinion, the
most common one I've come across is the following:
The original
work loses copyright. Meaning, nobody, not even the original author,
can claim copyright over that work anymore. However, this also means
that nobody else can copyright this original work.
Now, someone else cam come along, change anything at all, and copyright their
version, but they have no legal authority over the original, unmodified
version. So everyone still has access to the original, unmodified work,
that is in the public domain.
Now obviously, like
the BSDL and GPL, the license is irrevokable once released, however the
original author could still regain licensing and copyright over his PD
creation in the future if he so chose, that would only entail modifying
the PD work, even infinitesimally, and then claiming copyright on that
derivative work from that point on.
Patent weaknesses (eg patenting something blatantly obvious, and then
using it in the application, such as "one click") still seem to apply,
even to BSDL code. Newer laws (and those in the future) can attack even
licenses such as the GPLv2, eg TiVo exploiting the DMCA to sidestep the
GPL.
PD doesn't sound all that bad to me, at least not for smaller works. Maintaining copyright of a specific work doesn't really seem to do much, if that's the only thing you care about. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu May 10, 2007 5:16 pm Post subject: |
|
byuu wrote: |
This is why I don't like overly complex licenses like this [LGPL], you need a lawyer to fully understand their implications. |
You always
need a lawyer when it comes to law. Writing your own license without
the help of a lawyer means you don't really know what the full legal
implications are. That's a good reason to use common licenses, even if
they aren't exactly what you want. A custom license also makes it
harder to deteremine compatibility with other licenses.
Quote: |
PD doesn't sound all that bad to me |
My understanding of public domain is that you are more liable for
damage claims in connection with use of your code. With a BSD-style
license, you can grant use only if your disclaimer of laibility is
accepted. If they try to claim damages, they have violated your
license, thus have no right to use the software.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 5:31 pm Post subject: |
|
Nightcrawler wrote: |
Nach wrote: |
zidanax wrote: |
Nach wrote: |
blargg wrote: |
and his latest apudsp.txt covers all the details. |
We have the Snes9x repository hidden for a reason, please don't
distribute details publicly.
|
um, if you're talking about the doc I think you're talking about, it's available at Romhacking.net anyway so it's not exactly a private document (don't know how up-to-date Romhacking.net's files are,though).
|
No, they don't. As Romhacking.net distributes old
docs. I like to go to the official location for sources when possible,
because then I know I get the latest ones, especially when the official
source updates every few weeks.
|
20 days old is Old? 
All of Anomie's docs on RHDN are from April 21st, 2007. That includes
the latest version of all but two and they are scheduled for update.
Quit spreading untrue BS about us having old documents. I don't appreciate it.
|
If you're not the official source for something, every time they update
you do have old documents until you catch up. If you know the official
source for something you should check their for the latest.
What I don't appreciate was that once someone asked me for some C4 help
they had some questions on some things, and I explained it to them, and
also gave them a copy of anomie's latest C4 doc, and was met with a
response "but that's not what the C4 doc from RHDN says", which at the
time was using a significantly older version.
RHDN is a good archive, but that doesn't magically make it the #1 source for a particular doc.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 10, 2007 5:58 pm Post subject: |
|
blargg wrote: |
My
understanding of public domain is that you are more liable for damage
claims in connection with use of your code. With a BSD-style license,
you can grant use only if your disclaimer of laibility is accepted. If
they try to claim damages, they have violated your license, thus have
no right to use the software. |
Does anyone have even a single reference to a case where someone
released something (anything at all) to the public domain, and was
subsequently sued for defects in said PD work?
If the original author gives up his copyright, then he is no longer the technical "owner" of the work, right?
If not, then yes, you have a very good point and a very good reason to
use BSDL. It would suck to be sued because someone used code you gave
them, even though they never gave you anything at all for using it in
the first place. You weren't under any contract with them to guarantee
your product would work as they expected it to.
Minor edit:
http://en.wikipedia.org/wiki/BSD_license
Seems to imply the three restrictions are:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of the <organization> nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
The first two just set up the ability to let people know about the
third, that they don't want their names used to endorse products. That
doesn't seem like it's worth requiring a license be appended to all
source files and binary releases to me. In fact, I'd rather they do
advertise that they're using my code than not give me any credit at all.
The warranty information appears separate from the restrictions, and I
should technically be able to claim that and still release to PD, from
what I can tell.
Quote: |
If
you're not the official source for something, every time they update
you do have old documents until you catch up. If you know the official
source for something you should check their for the latest. |
Not that it changes your point in any way, which is correct, but since
the official source for the documents is not public, RHDN is the best
you can get. So it's not really at all fair to criticize RHDN for being
out of date when they're the only public distributor of the documents
in question. Again, your point that they are not current is still
correct. But what else are people supposed to do, besides track down
anomie themselves and ask him daily for updates? I do hope RHDN has
asked anomie directly for permission to host the latest docs, though.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 10, 2007 10:24 pm Post subject: |
|
byuu wrote: |
Quote: |
If
you're not the official source for something, every time they update
you do have old documents until you catch up. If you know the official
source for something you should check their for the latest. |
Not that it changes your point in any way, which is correct, but since
the official source for the documents is not public, RHDN is the best
you can get. So it's not really at all fair to criticize RHDN for being
out of date when they're the only public distributor of the documents
in question. Again, your point that they are not current is still
correct. But what else are people supposed to do, besides track down
anomie themselves and ask him daily for updates? I do hope RHDN has
asked anomie directly for permission to host the latest docs, though.
|
Yes when two regular people are dealing with something, by all means in
this case they don't use the developer resource. But if one of the
people involved is one of the devs, suggesting to look at an older
version is just an insult.
For a developer in general to say look up RHDN for docs is fine. But if
we're getting into a specific case, the developer should be giving the
other person the latest copy. And that other person shouldn't go ahead
and decide to trust the archive source over the official one.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Thu May 10, 2007 10:58 pm Post subject: |
|
LGPL
can be linked to closed-source programs. LGPL specifically exists so
that commercial and closed-source software can exist on Linux, where
the C run-time itself is LGPL.
Directly from FSF's mouth at http://www.gnu.org/licenses/why-not-lgpl.html :
"This is why we used the Library GPL for the GNU C library. After all,
there are plenty of other C libraries; using the GPL for ours would
have driven proprietary software developers to use another--no problem
for them, only for us." |
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri May 11, 2007 12:32 pm Post subject: |
|
byuu wrote: |
Not that it changes your point in any way, which is correct, but since
the official source for the documents is not public, RHDN is the best
you can get. So it's not really at all fair to criticize RHDN for being
out of date when they're the only public distributor of the documents
in question. Again, your point that they are not current is still
correct. But what else are people supposed to do, besides track down
anomie themselves and ask him daily for updates? I do hope RHDN has
asked anomie directly for permission to host the latest docs, though. |
It was Anomie himself that gave us the link. We're in the clear. 
You make a fine point. Nobody is saying RHDN is a better source for
specific documents that come from somebody else. However, they are by
no means old, and the official source isn't public. So.. yeah.. you go
ahead and expect people to track down and bother Anomie then, Mr. Nach.
For everybody else, there's RHDN.
Let's move past this. This is a dumb discussion. I only jumped in
because an undeserving label of serving old documents was put upon RHDN.
_________________
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.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri May 11, 2007 1:52 pm Post subject: |
|
Nightcrawler wrote: |
I only jumped in because an undeserving label of serving old documents was put upon RHDN. |
I'd also question listing docs that contain misinformation with a
comment like: "'The most complete guide to a SNES cartridge worldwide'.
I'd say that just might be true."
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon May 14, 2007 1:42 pm Post subject: |
|
Nach wrote: |
Nightcrawler wrote: |
I only jumped in because an undeserving label of serving old documents was put upon RHDN. |
I'd also question listing docs that contain misinformation with a
comment like: "'The most complete guide to a SNES cartridge worldwide'.
I'd say that just might be true."
|
Quote: |
'The
most complete guide to a SNES cartridge worldwide'. I'd say that just
might be true. In depth detail on the actual cartridge layout. Contains
information on the INTERNAL SNES ROM HEADER INFORMATION. |
Oh Noes! The submitter quoted a line from the document itself and
didn't know some of the information may not not have been 100% correct.
And the staff is not on top of the accuracy of hundreds of documents of
information on the site which may be out of their realm of expertise
anyway. RHDN must suck. Don't go there.
Oh wait, no... Perhaps it's not the staff and site that is so poor,
it's the fact that nobody reported there was a problem with it or
offered a better description.
Are you trying to pick a fight? How about contributing to make the site
better and solve the problem instead of bitching about them.
_________________
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.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon May 14, 2007 4:05 pm Post subject: |
|
I'm
pointing out to you that RHDN isn't the last word on a topic. I too
often have some idiot asking me a question and then telling me but RHDN
says differently.
You don't have to put up with
idiots asking you emulation related questions, but I do. I don't know
whose fault it is that people are coming off with the impression that
RHDN is the final word on all matters, but it annoys me when I have to
put up with people who have questions and think such.
I'm not trying to pick a fight, I'm telling you how it is. It's also
annoying when devs are discussing getting to the bottom of some matter,
when some guy comes along and says: "What's the mystery? Just read this
documentation here."
I never got this kind of idiocy from people pointing to Zophar's docs
or something. I'm sure RHDN has a better collection, but something
about it is giving out a false impression making it seem better than it
could be. You for example telling me that you don't like me saying
something is old just goes to show that you're trying to make people
believe it's the most up to date accurate resource when you don't have
it magically auto updating and don't have it constantly checked for
accuracy.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Starman Ghost Veteran

Joined: 28 Jul 2004
Posts: 991
|
Posted: Mon May 14, 2007 5:02 pm Post subject: |
|
Nach wrote: |
Argument with Nightcrawler |
This can all be sloved by putting a disclaimer on RHDN saying something
to the effect of "Some or all of these documents are very old and may
not be entirly accurate. Please use with caution.". Problem solved.
_________________
Code: |
<Ranbert> someone shoot me please....
<tele> o \O_ Arrgh!!
<tele> <\==- - - - - - - --- __/
<tele> / \ \
|
θάνατος
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon May 14, 2007 5:15 pm Post subject: |
|
Starman Ghost wrote: |
Nach wrote: |
Argument with Nightcrawler |
This can all be sloved by putting a disclaimer on RHDN saying something
to the effect of "Some or all of these documents are very old and may
not be entirly accurate. Please use with caution.". Problem solved.
|
A disclaimer is the appropriate solution.
_________________
FF4 research never ends for me.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon May 14, 2007 5:35 pm Post subject: |
|
or
better yet, "the accuracy of these documents vary depending on the
author, this is merely a collection of documentation and the integrity
of the overall collection does not reflect on RHDN"
this way it warns about possible accuracy issues without making it
sound like the site makes no effort to carry quality information.
It's really common sense to know your source, the source isn't the
site, but the author of the doc. The only way to really solve the
problem is get rid of the idiots.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon May 14, 2007 6:07 pm Post subject: |
|
Panzer88 wrote: |
The only way to really solve the problem is get rid of the idiots. |
Idiots multiply in numbers. 
_________________
FF4 research never ends for me.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Mon May 14, 2007 6:18 pm Post subject: |
|
Deathlike2 wrote: |
Idiots multiply in numbers.  |
Personally, I find numbers to be much easier to multiply than letters... am I an idiot too? 
_________________
Why yes, my shift key *IS* broken.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 21, 2007 4:28 am Post subject: |
|
Apparently
my Xv renderer still has a few minor issues ... could I ask a favor
from Xorg users? Please post a log of the output you get when running
'xvinfo' on the command line. I'm trying to determine how to detect a
valid xv_port for rendering.
I need one from each
video driver. I already have a log from both the radeon and nvidia
drivers. I'm looking for logs from nv, fglrx, and all other drivers.
Also, I've been throwing around ideas to create a new license that
meets somewhere between copyright and copyleft. A draft version is here:
http://byuu.org/temp/cdl.txt
I'm by no means a lawyer, so this license probably invalidates itself
ten times over, but any help in refining it to be on a more solid legal
standing would be greatly appreciated. My intentions should be rather
obvious from reading it. I'd like to keep the license as verbose as
possible. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon May 21, 2007 9:40 am Post subject: |
|
Clause number 2 seems to contradict the intention about the author receiving patches from the users. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon May 21, 2007 10:41 am Post subject: |
|
Collaborative Development License Version 1.0 (draft) wrote: |
While
competition and alternatives can be advantageous, the act of forking an
existing project can further exacerbate the problem of unnecessary
duplication of efforts. |
I really think you're overestimating the harm associated with forking,
and underestimating the usefulness. There's a lot of big open source
projects that would have died a long time ago if a new development team
couldn't have formed around the old code - Xorg, gcc, OpenSSH and
Apache, for starters.
I've found a great essay about forking,
which is worth a read, but if you don't have the time, consider this:
as reliable and accurate as BSNES is, it's not perfect, and despite
your devotion to SNES emulation, you're not going to be around forever
to shepherd it.
Do you want your work to be
sealed off and buried from the moment you upload the final release (I
know I wouldn't want to work on a project where it would be illegal for
me to show off what I'd done) or would you prefer that BSNES become the
base and reference of the SNES emulation community? Sure, there's other
SNES emulators with less restrictive licenses than the CDL, but if I
were going to build some SNES-related tool I'd much prefer to work on
the best.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 21, 2007 3:20 pm Post subject: |
|
I'll read your essay with an open mind.
That said, Xorg is a bad example in my book. I'm not at all a fan of
Xorg and it's inability to put up any kind of decent documentatiion to
program for it. Had they been forced to, we might finally have
rewritten the decade-old windowing system to support modern features
like compositing from the ground up. And perhaps even added native,
themeable widgets. No more QT vs GTK+ divide. And what of the original
XFree86 authors? All they wanted to do was add one small clause to
their license, and now they've pretty much had the entire project taken
from them. Nobody will contribute to XFree86 anymore.
Anyway, my intention is to release the entire emulator as PD, the
moment I start on the dot-based PPU renderer. I wanted a license a) in
the mean time, and b) for others to use who have looked for something
similar as a middle ground between copyleft and copyright. Pretty much
98% of the stuff I release is PD, eg all of the programs on my
utilities page.
I agree about saving projects after death through the more open
licenses, and as such, barring some sort of sudden death of myself, I'd
release it as a PD work when I were to discontinue the project.
Further, the license doesn't prevent authorized forking. If it's a
legitimate project, the person who wants to take someone else's
codebase can simply ask him permission, and be given rights to fork. I
think that's quite fair. Want two years of free work? Sure, just ask
permission first. The idea is to give the maintainer the control to
decide whether or not the project gets forked, to avoid bad forks, such
as Beryl. Where they take Compiz' code, relicense it under an
incompatible one, and then continue taking functions from Compiz while
contributing nothing back.
---
EDIT: ok, I read over your article. Thank you for the link. Hmm, I
really do like the parts about specialization. It makes a good point,
that's really what I'm going for anyway. One port aimed at speed, one
aimed at accuracy, but at least 80% of the codebase can be shared.
Under a PD/BSDL license, the other developer could close the source and
I would be screwed. With something that forces code release, I could at
least reimplement any improvements to accuracy into my branch.
The only negative would be if a branch were to change so much that it
was impossible to keep the two in sync anymore, eg
Konqueror<>Safari. I suppose that's highly unlikely in our
community, anyway.
To satisfy my own desire to maintain end control over my own code, I'll
probably just take any GPL port modifications I want and rewrite them,
still releasing that back to GPL, but assured in the knowledge I have
the control I want over my own branch. See, I'm looking for the ability
to choose my own license, even if that is a closed source one, in the
future. Even though I'm certain I'll never want to do that anyway. On
the plus side, this will allow me to continue adding my own exception
clauses, like my research permission clause and exemption clause, so
that if people want the code without the GPL being attached, they need
only ask me.
Hmm, well I'm now leaning toward GPL, rather than BSDL, for the next release. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue May 22, 2007 3:57 am Post subject: |
|
If
you want to retain the ability to apply a license that is not
GPL-compatible to BSNES, you'll probably want to require contributors
to assign their copyright to you, or else you'll need to get the
explicit permission of each contributor whose code is in zsnes. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 22, 2007 5:37 am Post subject: |
|
Here is the new cheat code editor:

Opinions? Suggestions? The listboxes will have borders and scrollbars
just as soon as I can figure out how to do this in GTK+. The "Cheat
Code Editor" text will be twice as large when I figure out how to make
Pango fonts in GTK+. Toggle Status and Delete Code will be grayed out
when nothing is selected in the future, and clicking in the text fields
will clear out the comments on first click.
Quote: |
If
you want to retain the ability to apply a license that is not
GPL-compatible to BSNES, you'll probably want to require contributors
to assign their copyright to you, or else you'll need to get the
explicit permission of each contributor whose code is in bsnes (sic). |
I have thus far only added minor changes as contributions. The
exceptions are all noted in the license file (except Cx4 ... need to
add that one too). I pretty much expect one to two line fixes to be
given to me PD. If the submitter expects me to further sublicense bsnes
to eg GPL for a single line or two of code, he can keep it. If the
project is forked, I will study their GPL code and rewrite it myself
from memory.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 22, 2007 8:56 am Post subject: |
|
byuu wrote: |
The "Cheat Code Editor" text will be twice as large when I figure out how to make Pango fonts in GTK+. |
I think it would be better to remove these entirely. It's pretty clear
from the left listbox what section you're in. It's just redundant and
takes up space that can be better used, either to reduce the fixed size
window or increase the length of a listbox.
Also, for the cheat code editor, is there a reason why the listbox area
isn't longer? I would think that you would want to show as many codes
as possible inside the fixed size window. The space is there, and the
less scrolling, the better.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue May 22, 2007 9:12 am Post subject: |
|
A grid for the list would be nice.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue May 22, 2007 10:54 am Post subject: |
|
Do
you also intend to write a cheat searcher? If yes it would be nice if
you could edit the value of the address the cheat is effecting right
from the Cheat Code Editor window, say in a per-code properties window.
Something that's always aggravated me in the Snes9x cheat
searcher/editor is that when you search for multibyte addresses, you
can change the value to whatever you want in the cheat searcher, but
only the least significant byte shows in the editor! It would be very
nice if you could define a code as relating to, say, a 3-byte integer,
so you can change the whole thing at once (a-la ArtMoney, I suppose).
But it really depends on what your intentions are for this.. if you're
not going to build a cheat searcher there's not much point as you'll
only be able to enter codes found by other people anyway. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue May 22, 2007 12:50 pm Post subject: |
|
byuu wrote: |
That
said, Xorg is a bad example in my book. I'm not at all a fan of Xorg
and it's inability to put up any kind of decent documentatiion to
program for it. |
Note that Xorg is working on XCB,
a library that talks the X11 protocol which isn't as weighed down by
arcane 1980s-era API design as the traditional Xlib library is. It does
the same things as Xlib, but it's more programmer friendly.
byuu wrote: |
Had
they been forced to, we might finally have rewritten the decade-old
windowing system to support modern features like compositing from the
ground up. And perhaps even added native, themeable widgets. No more QT
vs GTK+ divide. |
As far as client applications (like Firefox or BSNES or KDE) care,
modern X11 servers support compositing as deeply as you like: when you
create a top-level window, you're given a ARGB canvas upon which you
can draw whatever you like, which becomes a texture that can be
composited however you like. The fact that the server starts up in a
backwards-compatible mode probably makes the X11 code a bit more messy,
but that's much better than adding version checks and multiple
code-paths to every other piece of X11 code on the planet.
Things like standard, native, themeable widgets would not necessarily
be a good idea - back in the day, there was a standard widget kit
called Xaw - if you've ever booted up xedit or xclipboard or xterm,
you'll know it hasn't aged very well. Motif was another attempt which
was pretty horrible to work with (Netscape 4 and below used this), and
while GTK+ 1.x was better than Motif, it couldn't easily and
backward-compatibly be extended to do all the things that GTK+ 2.x can
do, like having proper internationalisation and accessibilty support.
Qt, like Java's Swing and Mozilla's XUL was designed to be portable, so
it would be an 'alternate toolkit' even if there was a standard X11
toolkit.
Remember that even Windows has a number of independent GUI toolkits -
there's the standard Win32 widgets, the Office widgets and the widgets
that appear in web-pages in IE. I suspect Adobe has its own
cross-platform widget library for Photoshop. Even the standard Win32
widgets come in new (themable) and old (backwards-compatible) variants.
byuu wrote: |
And
what of the original XFree86 authors? All they wanted to do was add one
small clause to their license, and now they've pretty much had the
entire project taken from them. Nobody will contribute to XFree86
anymore. |
Don't waste too many tears on them. The licensing problem was just the
thing that forced Xorg to fork, rather than merely wanting to very
badly. Most of the technological advancements brought by Xorg were
things that XFree86 refused to allow into their tree - things like
anti-aliased font handling (Xft), hardware-accelerated anti-aliased 2D
graphics (Render), runtime resolution changing like Windows and Mac
have had for years (XRandR), true compositing support (XComposite) and
the replacement of the archaic and monolithic X build system with
something more modular and distribution-friendly. The guy behind most
of those changes (well, the graphical ones) was Keith Packard, who was
originally a member of the XFree86 dev team and is now one of the main
Xorg guys.
byuu wrote: |
Further,
the license doesn't prevent authorized forking. If it's a legitimate
project, the person who wants to take someone else's codebase can
simply ask him permission, and be given rights to fork. I think that's
quite fair. |
Fair enough, although you'd probably want to make explicit mention of
how that should work in your license, and when and how merging might be
possible.
byuu wrote: |
The
only negative would be if a branch were to change so much that it was
impossible to keep the two in sync anymore, eg Konqueror<>Safari.
I suppose that's highly unlikely in our community, anyway. |
The essay says that disparate forks of the Linux kernel are unlikely
because any significant fork would have to have a massive amount of
effort behind it just to keep up, and that's very unlikely. Well, it
turned out that Apple was indeed willing to burn huge amounts of effort
on maintaining their KHTML fork - and as you point out, that's even
more unlikely to occur in the small, non-commercial SNES emulation
community. Note also that the main problem between Konqueror and Safari
wasn't the that the code was technically incompatible, just that the
Safari folks said 'Hey, here's our changes' and delivered one huge
patch containing everything from vital crash-fixes to cosmetic changes.
Since then, the Safari folks have opened up a lot more and WebKit and KHTML are getting much closer.
byuu wrote: |
To
satisfy my own desire to maintain end control over my own code, I'll
probably just take any GPL port modifications I want and rewrite them,
still releasing that back to GPL, but assured in the knowledge I have
the control I want over my own branch. See, I'm looking for the ability
to choose my own license, even if that is a closed source one, in the
future. Even though I'm certain I'll never want to do that anyway. |
As DataPath pointed out, the usual way of doing this is to ask
contributors to assign their copyright to you. Sure, little one-and-two
line code patches are probably small enough that 'copyright doesn't
count', and large changes can probably be rewritten (although a proper
clean-room implementation requires *two* people, one to
reverse-engineer and document, and another to read the document and
write code), but it's a lot easier if you just say 'please assign the
copyright ownership of your changes to me' and they say 'yes'.
I should note that the Mozilla Foundation is in a vaguely similar
situation: although they don't require copyright assignment, they do
require that changes be licensed under the same three licenses that the
original Mozilla source is under, so that the changes can be merged. If
someone invents some absolutely fabulous change but they won't
tri-license it, Mozilla just says 'go away'.
Another advantage to having copyright assigned to you is so that when
Richard Bannister wants to do a closed-source OS X port, he can just
ask you for permission and you can say 'yes'.
byuu wrote: |
Hmm, well I'm now leaning toward GPL, rather than BSDL, for the next release. |
I look forward to your decision.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 22, 2007 3:39 pm Post subject: |
|
Quote: |
I
think it would be better to remove these entirely. It's pretty clear
from the left listbox what section you're in. It's just redundant and
takes up space that can be better used, either to reduce the fixed size
window or increase the length of a listbox. |
Good point. I'll just remove the text label at the top and use the
extra space on the left for more room. And yeah, I can expand the
listbox height. I was mostly holding off in case anything else was
needed.
Quote: |
A grid for the list would be nice. |
I can see about that as an option. I don't like the way the grid looks,
personally. Though I do like where each alternating line is a different
color. GTK+ used to do that, must be my theme or something.
Quote: |
Do you also intend to write a cheat searcher? |
Not at the moment. I suppose I can add an edit code button in the future if I do.
Thristian:
I realize they have plenty of wrappers around X11 now to make it more
modernized, but it's much like how your PC boots up in 8086 mode for
compatibility ... at some point, you have to be like, ok, the old API
is crap, and nobody is writing 8086 apps anymore. Let's just start the
system up in its' native mode. But, yeah, this method is more
compatible.
Quote: |
Remember
that even Windows has a number of independent GUI toolkits - there's
the standard Win32 widgets, the Office widgets and the widgets that
appear in web-pages in IE. I suspect Adobe has its own cross-platform
widget library for Photoshop. Even the standard Win32 widgets come in
new (themable) and old (backwards-compatible) variants. |
I write my UIs using the native controls and common controls, which
have been there from Win3.1 to Vista. I will agree they have a lot of
additional controls elsewhere, but Microsoft has not had a problem
adding most things to updated versions of Windows, eg Unicode support.
Yes, you'll need updates on Win9x, but it's mostly supported with
backwards patches rather than creating new, incompatible APIs in the
future.
Quote: |
Don't
waste too many tears on them. The licensing problem was just the thing
that forced Xorg to fork, rather than merely wanting to very badly.
Most of the technological advancements brought by Xorg were things that
XFree86 refused to allow into their tree |
Yes, let's do a little role reversal here. "The licensing problem was
just the thing that forced bsnes to fork. Most of the things brought
were things that byuu refused to allow into his tree -- things like
game-specific fixes (hacks), speedups (removing unimportant parts of
the emulation like DMA sync), adding BS-X support (buggy, incomplete),
and lots of (unnecessary) features like AVI recording, motion blur
filters, 24-bit color output, 32-bit 96khz audio output support, etc."
While a fairly contrived example, and I myself appreciate the
enhancements Xorg has brought to the stalling XFree86, I still believe
they would've been better off making their own project. But what they
did was permitted by XFree86's license, so no, I don't feel too badly
for them. They knew what they were getting when they used their license.
I can see myself as being stubborn about some of the above points -- I
would like to maintain some sort of integrity over my project code,
though. If someone were to fork my project for the above reasons, would
anyone contribute to my work anymore? Probably not. And as you say, I'd
have difficulty getting that code back into my project, as I'd lose
copyright ownership of my work, needed to grant permissions like I have
to Mr. Bannister.
Quote: |
(although
a proper clean-room implementation requires *two* people, one to
reverse-engineer and document, and another to read the document and
write code) |
It's depressing that even my friends continually threaten me about
violating unregistered copyrights. I'll read the code and reimplement
it myself from memory (absolutely no copying), just like how someone
would read an encyclopedia and use what they learned to write a school
report -- they wouldn't ask their friend to write the report for them
-- and if anybody has a problem, they can contact a lawyer. Legal or
not, I don't want to hear about it anymore. I don't have a twin who can
rewrite what I tell him to. With most things, there aren't many
variations you can take to reach the same end result. Whether I
reimplement something myself, or two people do, it'll still look a lot
like the original work, because they both intend to do the exact same
thing anyway. In fact, I'll bet my Scale2X code looks exactly like the
GPL'd version. Why? Because there's only one way to do it. I actually
read how to do it from some LucasArts discussion page (you know, the
original authors of the algorithm), but I'm sure if the Scale2X authors
knew about my code, they'd be threatening me too.
It's unfortunate that most of the people out there seem more interested
in protecting copyrights on work they give away for free anyway, than
friendships.
Thanks for the feedback.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue May 22, 2007 7:45 pm Post subject: |
|
Fuck
people who say it looks like GPL, if you wrote your own version of it
it's yours. GPL people do themselves. Look at their GPL port of the qt
lib, that was legit.
_________________
Watering ur plants. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Tue May 22, 2007 8:55 pm Post subject: |
|
Quote: |
If someone were to fork my project for the above reasons, would anyone contribute to my work anymore? Probably not. |
This is *really* what scares people about forking - it introduces
competition for your own code, which can be rough to mentally process.
Have some faith in yourself! The reason to use bsnes is the
correctness, and if someone threw a bunch of hack garbage into a fork
they would lose that reason and you would keep it. I run games it
supports in bsnes and stack-o-addon-hardware games in ZSNES, and I
imagine that's a pretty common scenario. A mythical hacky fork of bsnes
would compete more with ZSNES than it would the "real" bsnes and it
would likely die quickly.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu May 24, 2007 12:30 am Post subject: |
|
byuu wrote: |
Apparently
my Xv renderer still has a few minor issues ... could I ask a favor
from Xorg users? Please post a log of the output you get when running
'xvinfo' on the command line. I'm trying to determine how to detect a
valid xv_port for rendering.
I need one from
each video driver. I already have a log from both the radeon and nvidia
drivers. I'm looking for logs from nv, fglrx, and all other drivers.
|
Code: |
X-Video Extension version 2.2
screen #0
Adaptor #0: "NV Video Blitter"
number of ports: 32
port base: 57
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
depth 24, visualID 0x22
number of attributes: 2
"XV_SET_DEFAULTS" (range 0 to 0)
client settable attribute
"XV_SYNC_TO_VBLANK" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
maximum XvImage size: 2046 x 2046
Number of image formats: 5
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x3
guid: 03000000-0000-0010-8000-00aa00389b71
bits per pixel: 32
number of planes: 1
type: RGB (packed)
depth: 24
red, green, blue masks: 0xff0000, 0xff00, 0xff
|
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu May 24, 2007 1:25 am Post subject: |
|
byuu wrote: |
Here is the new cheat code editor:
Opinions? Suggestions? The listboxes will have borders and scrollbars
just as soon as I can figure out how to do this in GTK+. The "Cheat
Code Editor" text will be twice as large when I figure out how to make
Pango fonts in GTK+. Toggle Status and Delete Code will be grayed out
when nothing is selected in the future, and clicking in the text fields
will clear out the comments on first click. |
Now you're talking my language. I like how it looks.
A edit cheat button would really come in handy just in case somebody
messes up the code. Cheat search options would be nice, but I'm not in
any hurry there yet. Looking good nonetheless.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 24, 2007 5:13 am Post subject: |
|
Updated both screens with FitzRoy's suggestion. Looks a lot better in my opinion.
<snip>
Added presets. The first is my favorite, Super Sleuth's + a little
lower gamma. The second is the standard SNES colors. The third is a
Gameboy clone mode.
<snip>
Lots more room. Still no scrollbars.
Thank you, Nach. Looks like my YUY2 filter will work on your video card
with no changes necessary. I believe PutImage will be what is important
in determining a port you can draw to, and not the number of ports on
an adaptor.
Arbee wrote: |
This
is *really* what scares people about forking - it introduces
competition for your own code, which can be rough to mentally process.
Have some faith in yourself! The reason to use bsnes is the
correctness, and if someone threw a bunch of hack garbage into a fork
they would lose that reason and you would keep it. I run games it
supports in bsnes and stack-o-addon-hardware games in ZSNES, and I
imagine that's a pretty common scenario. A mythical hacky fork of bsnes
would compete more with ZSNES than it would the "real" bsnes and it
would likely die quickly. |
Thanks for the kind words. You do have a point in that it would be
ridiculous to use bsnes with hacks, at least. May as well use something
far faster for that.
EDIT: moved images to the next page so everyone sees them, sorry :)
Last edited by byuu on Thu May 24, 2007 7:08 am; edited 1 time in total
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu May 24, 2007 6:06 am Post subject: |
|
Mmm Mmm Mmm the same old bsnes with twice the sexy!
looking good byuu.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 24, 2007 7:07 am Post subject: |
|
Moving screenshots to this page so that they aren't missed :)
See the previous page for more discussion on them, please.
I'll probably remove these screenshots in a few days.
---
blargg's NTSC filter options will most likely appear here, by the way.
---
Again, thanks to FitzRoy for the excellent suggestion to drop the panel title.
One other point I wanted to bring up was the Windows port. Some things
I have to compromise on. For example, the text box size height of 30px
looks stunning on GTK+, but looks a little too tall on Windows. 25px
looks great on Windows, but looks terrible on GTK+, as it cuts off part
of the bottom. Windows is at fault here because it lacks the ability to
vertically center text. I'm going with 30px. My goal is going to be to
support up to slightly larger-than-normal fonts. Really large fonts?
Too bad. I don't want to use automatic sizing of widgets because a)
that doesn't exist on Windows and b) it gives me a lot less control
over aesthetics. I'll try and make the font selection configurable, and
I'll highly suggest using a larger font with cleartype enabled if
possible.
In other news, I tried out -fprofile-generate and -fprofile-use. It
gives a ~15% speedup. I also tried out nearly all of the -march
settings and special ones like -ftree-vectorize, and noticed no
relevant difference in speed. For those on Linux, you'll get a nice
speed boost by profiling the emulator, but it's still not as good as
MSVC's, which I can no longer use. About half as good, in fact. But at
least GCC's works, and it's way faster, too.
Last edited by byuu on Sun May 27, 2007 10:00 am; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu May 24, 2007 8:16 am Post subject: |
|
I'm sure the Win32 API allows you to vertically centre text.. *looks it up* Yeah, what's stopping you from using DrawText() with the DT_VCENTER flag? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 24, 2007 3:16 pm Post subject: |
|
Quote: |
Yeah, what's stopping you from using DrawText() with the DT_VCENTER flag? |
... the fact that I'm using an editbox control, that draws its' own
text? Editboxes only support SS_CENTER, which is horizontal only. Why
you'd horizontally center text in an editbox, though, is beyond me ...
Typical short sightedness, I presume. Same reason I had to write my own
static control, because Microsoft chose not to allow multiline text in
theirs.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu May 24, 2007 3:22 pm Post subject: |
|
Ah.
I'm afraid my experience with GUI programming is limited, so I didn't
know there was a difference. (and it's been months since I made a GUI
as well) Thank you for taking the time to explain. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 24, 2007 6:09 pm Post subject: |
|
That's
okay, I have something in mind that can resolve this problem in all but
extreme edge cases (eg people who set their dpi to < 80 or > 120,
99% of people use 80, 96 or 120).
The idea is to
calculate the height of the main font used throughout the GUI at
startup. With Windows, DrawText + DT_CALCRECT works fine. With GTK+, I
don't know ... I'm sure there's something. Worst case I can make a
hidden form, dump a test string into a static on there, let it autosize
the control, steal the height from that.
I'd like to extend the controls to send back sizing hints, too. Like
for Windows editboxes, they'd return a hint of 3 for border size.
Multiply by 2 (top+bottom) and you see you want height of the font + 6
to get a nice looking editbox. Buttons would return 5, giving them a
nice look as well.
Widths will be set to safe defaults, extra width padding hurts nothing
but looks really sharp, as evidenced in the above screenshots.
The windows that we need to fill completely, like the cheat code
editor, should be easy, too. Calculate how much room you'll need for
one line of buttons and one line of editboxes, then you know how big to
make your listbox. Voila! Perfect fit on Windows and Linux, regardless
of font.
And I don't have to make up some overly complicated "oh, windows should
be designed like BOXES, or SIZERS!" bullshit that nobody wants to learn
:) |
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Fri May 25, 2007 7:13 pm Post subject: |
|
Is there a reason why you're using a list control on the left side for navigation instead of tabbed navigation across the top?
Using a list control usually wastes a lot of screen space, unless you intend to have a lot of items in the list.
However, the problems with a tab control is that you're limited in the
number of tabs unless you go to multiple rows. Plus the length of the
text on the tabs themselves sometimes becomes an issue. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri May 25, 2007 8:13 pm Post subject: |
|
I
only have two options in the list now, but I intend to continue adding
items. I want everything to be here, even the about screen, eventually.
The only thing I want to keep separate is the debugger, as ideally you want multiple windows onscreen at the same time there.
Some good news, I believe I've figured out how to add scrollbars to
GTK+ edit and listbox controls. So that should near-complete my UI lib.
Now the only issue is the joypad config. My idea at the moment is to
only support the keyboard input directly. Get another release out, and
then work on all of the chaos involved in merging Input and UI parts
while still keeping them independent of each other. Fun, fun. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri May 25, 2007 8:22 pm Post subject: |
|
Would
you still be able to, say, configure your joystick/gamepad in bsnes
0.019 (if you have it) then copy the necessary bit of its config file
over to 0.020's config file? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 26, 2007 12:26 am Post subject: |
|
Couple of questions:
1. I see you've renamed "Color Settings" to "Raster Settings." Is this because you're planning to combine the two?
2. Why are there now three presets?
3. What are those three buttons you've got there on the left part of
your linux window? Is this why I get no icon in my xp window?
About what krick said: I'm indifferent to either approach, but there
are a couple of bothersome things about tabs, so he sort of answered
his own question. I think the listbox looks good even though it takes
up more space. Why would you consider moving the about box to the
configuration, though? Sure, it gets rid of a separate window, but...
it doesn't make a lot of sense there.
I still like having the video settings in the config panel rather than
the menubar. Maybe I'm in the minority, but I don't mess with my
configs very much after the first startup.
I hope there are more WIPs before release, because there are still some
issues that I think you're too busy to want reminders for right now. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat May 26, 2007 1:32 am Post subject: |
|
Quote: |
Would
you still be able to, say, configure your joystick/gamepad in bsnes
0.019 (if you have it) then copy the necessary bit of its config file
over to 0.020's config file? |
Yes, absolutely. It's also stored in plain text, so you could edit it
by hand if you chose. No odd hex values or anything like that to mess
with.
Quote: |
1. I see you've renamed "Color Settings" to "Raster Settings." Is this because you're planning to combine the two? |
Yes. I don't know about the scanlines yet. Only Direct3D can do the
scanlines, and I removed them because they were sloppy. I'd like to add
them back to software, but I'm trying to think of a compromise that
will avoid the need to run the video through a multipass filter, and
yet not overcomplicate the software blitters even moreso.
I'm planning on making a custom panel for blargg's NTSC filter. There
are a ton of options, and I want to add presets for all the different
video settings.
Quote: |
2. Why are there now three presets? |
Honestly? One made the window look too empty, and I wanted a second one
to set the default SNES colors for those that hate the gamma curve
option, but can't figure out what the standard presets should be. Two
would've been some ridiculously long buttons, so I had to come up with
a third. I would be very interested in a better preset for the third
one, though. I figured a gameboy clone would be a good placeholder for
now.
Quote: |
3.
What are those three buttons you've got there on the left part of your
linux window? Is this why I get no icon in my xp window? |
From left to right:
- Context Menu, same as Windows
- Sticky (show window on all virtual desktops instead of just the active one)
- Roll (click to roll up window so only titlebar is visible, click again to restore, kinda like in Winamp)
As for why there is no icon ... I don't know how to give a Linux
program an icon, and I'm even more confused on how to make a standard
API for libui that will give an icon to both the Windows and Linux
ports.
I'm also interested in trying to get an SVG icon for bsnes.
Firefox/Linux has one, and it's really cool because you can raise the
icon to 128x128 and it still looks awesome.
Quote: |
Why would you consider moving the about box to the configuration, though? |
Good point, nevermind then.
Quote: |
I
still like having the video settings in the config panel rather than
the menubar. Maybe I'm in the minority, but I don't mess with my
configs very much after the first startup. |
Would having it in both places bother you? That's something I could probably do with relative ease.
Quote: |
I
hope there are more WIPs before release, because there are still some
issues that I think you're too busy to want reminders for right now. |
Ah, I actually was planning on trying to get an official release out
shortly. I suppose a public WIP will be fine, too. I never did get that
double click thing fixed in the menubar (which is why you get two
audioNNN.wav files for the log audio data option).
Thanks for the feedback.
---
So, for now, the panels I am planning are:
- Emulation Settings (misc stuff like speed regulation settings)
- Video Settings (?)
- Raster Settings
- NTSC Filter Settings
- Input Configuration
- Cheat Code Editor
- Advanced (will be a GUI editor for the config file, just like Firefox -> about:config)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 26, 2007 5:13 am Post subject: |
|
byuu wrote: |
Would having it in both places bother you? That's something I could probably do with relative ease. |
No, that would be fine. I can't remember if you did the menubar thing
because you couldn't initially figure out how to replicate the old
config, or if you did it because you thought people accessed them more.
byuu wrote: |
Ah, I actually was planning on trying to get an official release out
shortly. I suppose a public WIP will be fine, too. I never did get that
double click thing fixed in the menubar (which is why you get two
audioNNN.wav files for the log audio data option). |
If you mention the missing function and its imminent return in the
release notes, it would probably be fine for a release. Otherwise, user
impression would be initial excitement and then "oh shit, my gamepad
won't work..."
Yeah, that audio thing was one of the things. A couple of other things
that are happening now on my xp box that did not in .019:
1. Audio isn't cut but infinitely stutters when the menu is accessed during gameplay.
2. The video window doesn't clear to black when a rom unloads. An image
persists. (if you move another window over the bsnes window in this
state, it clears the overlapped area.)
3. A duplicate configuration file is being made in my roms directory when I load a rom from there. Bug?
4. Video mode and filter setting changes still aren't saving after exit when applied after a rom is loaded.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat May 26, 2007 6:12 am Post subject: |
|
Quote: |
No, that would be fine. I can't remember if you did the menubar thing
because you couldn't initially figure out how to replicate the old
config, or if you did it because you thought people accessed them more.
|
I use it a lot, myself. 1x for screenshots, 2x for programming, 3x for gameplay.
Quote: |
1. Audio isn't cut but infinitely stutters when the menu is accessed during gameplay.
|
Menubar is modal. I know how to capture the menu enter message to clear
the audio buffer, but how to add that to a cross-platform UI API when
GTK+ menubars are non-modal ... ? I'm thinking I need to rewrite my
message system to be more flexible, and I can just have a generic
system to send and receive messages to relevant windows and controls.
Quote: |
2. The video window doesn't clear to black when a rom unloads. An image
persists. (if you move another window over the bsnes window in this
state, it clears the overlapped area.)
|
Yeah, it doesn't clear at startup, either. Need to get the clear_video
function working again and add calls at the right places.
Quote: |
3. A duplicate configuration file is being made in my roms directory when I load a rom from there. Bug?
4. Video mode and filter setting changes still aren't saving after exit when applied after a rom is loaded.
|
Same problem, another portability issue. With Windows, I can get the
exact path+filename of the bsnes executable, which I change the
filename part to bsnes.cfg, so that the config file always saves to the
same place. Not sure how to do that with Linux, ergo no support for
that on either platform, yet ...
Basically, whenever you load a ROM, your current working directory
changes there, so when you close bsnes, the config file is saved in
that folder. When you open it, the working directory is the EXE
directory, so it loads the config file from there. Hence, it looks like
your settings are being ignored ...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat May 26, 2007 7:17 am Post subject: |
|
byuu wrote: |
Same problem, another portability issue. With Windows, I can get the
exact path+filename of the bsnes executable, which I change the
filename part to bsnes.cfg, so that the config file always saves to the
same place. Not sure how to do that with Linux, ergo no support for
that on either platform, yet ...
|
Thanks for explaining. This one seems like it would be a fairly major
issue for the average user. I hope you can fix them eventually.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Sat May 26, 2007 11:00 pm Post subject: |
|
On
*IX, normally you'd store config data in the user's home directory
either as a .file or inside a .folder. I do this for my NEStopia port -
it stores settings (and some other things like the FDS BIOS) in
~/.nestopia. That way someone can install your app in /usr/local/bin or
whatever and multiple users can have their own configs. (And actually
Windows is headed that way too since 2000, except you call some shell32
thing to find the user's folder). |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat May 26, 2007 11:13 pm Post subject: |
|
%AppData%, you mean? (or %UserProfile%) |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun May 27, 2007 2:10 am Post subject: |
|
byuu wrote: |
Same problem, another portability issue. With Windows, I can get the
exact path+filename of the bsnes executable, which I change the
filename part to bsnes.cfg, so that the config file always saves to the
same place. Not sure how to do that with Linux, ergo no support for
that on either platform, yet ...
Basically, whenever you load a ROM, your current working directory
changes there, so when you close bsnes, the config file is saved in
that folder. When you open it, the working directory is the EXE
directory, so it loads the config file from there. Hence, it looks like
your settings are being ignored ...
|
Look in zpath.c in ZSNES for what you need to look at to do it.
getpwuid() under *nix and SHGetFolderPath() under Windows.
As for finding where the executable is located, it's the same way on
all OSs. You on program load append argv[0] to CWD, and get the
real/full path of 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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun May 27, 2007 3:30 am Post subject: |
|
CWD
can be modified. If you drag a ROM on top of an executable, the CWD at
startup is the folder the ROM is in, not the folder the program
executable is in.
For Windows, GetFullPathName()
gives you the exact path+program name, even if you start your program
with a shortcut that has set a different startup directory.
~/bsnes.cfg is a good idea ... I don't like the idea of "hiding" the
file, though. I guess if I get that "Advanced" panel up where you can
edit it ala Firefox about:config, that would work just fine ... think
anyone would freak out if I avoided hiding the file and stuck it in ~/
directly?
Thanks for the suggestions. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun May 27, 2007 3:37 am Post subject: |
|
byuu wrote: |
CWD
can be modified. If you drag a ROM on top of an executable, the CWD at
startup is the folder the ROM is in, not the folder the program
executable is in.
|
In those cases, argv[0] should contain the full path to the executable.
Of course before appending argv[0] onto CWD, check if it's absolute
first. Like I said, see zpath.c to see what we do. fullpath() and
realpath() should already handle the merging propery as well.
byuu wrote: |
~/bsnes.cfg is a good idea ... I don't like the idea of "hiding" the
file, though. I guess if I get that "Advanced" panel up where you can
edit it ala Firefox about:config, that would work just fine ... think
anyone would freak out if I avoided hiding the file and stuck it in ~/
directly?
|
Note, you can't use ~ directly as part of a file path in your program, ~ is a shell thing.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sun May 27, 2007 5:10 am Post subject: |
|
byuu wrote: |
~/bsnes.cfg is a good idea ... I don't like the idea of "hiding" the file, though. |
The *nix platform convention is that applications store there settings
in hidden files in the user's home directory (where by 'hidden' I mean
'the filename begins with a "."').
byuu wrote: |
think anyone would freak out if I avoided hiding the file and stuck it in ~/ directly? |
You'd probably get people complaining about you cluttering up their
home directories, yes - imagine if BSNES stored its master config file
on the Windows desktop.
For example, on Windows, Firefox stores its profiles in "C:\Profiles
and Settings\$USERNAME\Application Data\Mozilla\Firefox", while on *nix
it's "$HOME/.mozilla/firefox/". That's just how the users of those
platforms expect well-behaved programs to behave.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun May 27, 2007 10:08 am Post subject: |
|
Ok,
I've finally figured out how to add scrollbars to GTK+ widgets. It's
actually pretty simple, I just had to find code to reference elsewhere,
since the official documentation is extremely lacking.

Raster Settings, same as before but now with a border around the main list.

Cheat Code Editor, looks a lot better with the scrollbar. I also made
each line alternate colors so that it's easier to read across the
entire list.
---
New window. This one is an interface to bsnes.cfg. It's meant to be a
way to edit options not present in the UI, without requiring a restart
of bsnes. Of course, it has some issues (does not update UI elements,
some changes require restart), and an appropriate warning is presented
when you first enter the screen.
The reason I don't show the value and default value inside the list is
because some of them are ridiculously long. If you guys want to see
them there anyway, I can try cutting up the joypad config back down
into individual values, rather than one long string of all values.
You get the value now by clicking on an option in the list, it reloads the textbox at the bottom to that value.
Also, thanks to some help from Nach, I now have the config file always
saving to the program folder again, like v0.019. Works on both Windows
and Linux. I also rewrote the message passing system, so I should be
able to add in the menu_enter event again for Windows, to fix the audio
bug there.
Last edited by byuu on Mon May 28, 2007 4:10 am; edited 1 time in total |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun May 27, 2007 8:14 pm Post subject: |
|
Too
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. I suggest a normal /etc/bsnescfg + ~/.bsnescfg combo.
But I do see that some people do not like this, so what about a compile
option? Or a setting storaged somewhere it will always look and nobody
will mind.
For let the main config file ban or allow user custom config files. The
main config file can be storaged in the program directory for Windows
and in /etc for posix. The user specific config can be storaged in that
app data folder for windows. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 28, 2007 2:50 am Post subject: |
|
henke37 wrote: |
Too
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. |
Fine, the 'Advanced' panel was meant to allow UI configuration of the
config file. Now that it exists, I have moved the config file to
~/.bsnes/bsnes.cfg. It only works on Linux at the moment (Windows
continues to save to the current directory), but Windows support should
come soon, and it will be ~/Documents and
Settings/Username/.bsnes/bsnes.cfg or
~/Users/Username/.bsnes/bsnes.cfg. The .bsnes folder is chmod 755 on
Linux, doesn't matter on Windows.
I'm not putting anything in /etc. Please forward your complaints on that to /dev/null ;)
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon May 28, 2007 3:11 am Post subject: |
|
byuu wrote: |
henke37 wrote: |
Too
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. |
Fine, the 'Advanced' panel was meant to allow UI configuration of the
config file. Now that it exists, I have moved the config file to
~/.bsnes/bsnes.cfg. It only works on Linux at the moment (Windows
continues to save to the current directory), but Windows support should
come soon, and it will be ~/Documents and
Settings/Username/.bsnes/bsnes.cfg or
~/Users/Username/.bsnes/bsnes.cfg. The .bsnes folder is chmod 755 on
Linux, doesn't matter on Windows.
I'm not putting anything in /etc. Please forward your complaints on that to /dev/null
|
Using that fucked up predefined path system (or whatever it is called)
in Windows is atrocious, unless you are using Vista.
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Mon May 28, 2007 3:16 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon May 28, 2007 3:14 am Post subject: |
|
GUI path definitions! Yes!
The only thing I don't like is the alternating row colors for the left
listbox. They're okay on the right ones because the right ones have
multiple columns, so they serve the purpose of making the line fields
easy to correlate. But on the left there are no extra columns so
they're more distracting than purposeful. Almost look like inactive
selections or something. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 28, 2007 4:11 am Post subject: |
|
I've had paths forever, just not editable from the UI :/

Updated. I decided not to show the default value in the listbox, as it
just wastes space (most settings are the same anyway). You can tell if
a value is modified by looking for the (*), and you can get the default
value in the textbox below by selecting an item. Changing any entry
will immediately update the entry in the listbox.
I decided not to clip the width of the values to force no horizontal
scrollbar. It doesn't really hurt much to have it there.
I've updated the column hint to only apply when two or more columns are
visible, for FitzRoy. Unfortunately, Windows users won't see the hint
at all. I don't know how to do that with Windows. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon May 28, 2007 5:04 am Post subject: |
|
byuu wrote: |
I've had paths forever, just not editable from the UI :/ |
Yeah, that's what I meant. Thanks for that colors change, even though it didn't apparently affect me, lol.
So do you really think that the explanation box about defaults is
necessary? It would be really nice to have that extra space for the
listbox. It is an "advanced" section after all, and the button is
there, and something could always be added in the readme if you thought
it was too hard to figure out.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 28, 2007 5:29 am Post subject: |
|
It has really detailed information for some options. Example:
input.axis_resistance:
Quote: |
(default = 75)
Axis resistance for all analog joypads
Affects responsiveness of analog stick movement by specifying what percentage
in any given direction the axis must be pressed to trigger a button press.
In other words, this determines how hard you have to press the analog stick to
simulate pressing e.g. left or right on a digital joypad.
Value is a percentage, from 0 (axis will trigger with virtually any axis movement)
up to 100 (axis must be pressed fully to given corner).
Value affects all four directions of the axis equally.
Note: Values below 10 or above 90 are not recommended and may not work at all. |
I was aiming for a UI window that was fully viewable at 640x480.
However, I can bump that up to 800x600 if you really think there's a
problem with room. Nobody uses 640x480 anyway. Especially not people
who can make use of bsnes, heh.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon May 28, 2007 6:10 am Post subject: |
|
I agree that that is good info. It's not really a big deal.
I think 800x600 is unnecessarily large and I fear you creating more buttons to fill up the new space .
How about waiting to see how the input config turns out and then
assessing if 480 vert is needed? I know that it would be nice to not
have to scroll again.
EDIT: It occurs to me that
you might be planning to do away with the selection box and have a big
list for all controllers similar to the ones you've been implementing.
The scrolling for this wouldn't be too bothersome, I guess, because
most people set up their controller once. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon May 28, 2007 8:32 am Post subject: |
|
Quote: |
EDIT:
It occurs to me that you might be planning to do away with the
selection box and have a big list for all controllers similar to the
ones you've been implementing. |
Yep :)

The controller ports will eventually be enabled when/if I ever support
more input devices. A / B corresponds to the labels on a real SNES.
I have posted a new beta with all of these changes. Now, one big
problem is that Visual C++ is telling me that with
'interface::input.bind()', input is not a member of the global
namespace. Perplexing, since I know that and specified the 'interface'
namespace for this reason. I just disabled that one function to build a
new Windows binary, I don't feel like fighting with Microsoft's
compiler at the moment.
Basically, this just means that if you change a key value on Windows,
you'll have to close bsnes and reopen it for it to take effect.
Joypad keypresses aren't registered, and note that I only store one
value per keycode now. I wanted to simplify things. My idea is that if
you have a need for such a feature, there will eventually be 4-8
joypads you can setup controls on. You can just switch port A to a
joypad that's set to your controller or keyboard at will.
I was not able to find out how to get the local user directory on
Windows without requiring the <windows.h> header file (for
SHGetPath or whatever). I am not
adding that header in to libbase.h, so either we find a way to do it
with functions in Visual C++'s standard headers, or .bsnes/bsnes.cfg
will continue to be saved in the bsnes program folder.
The menu enter thing wasn't fixed yet, nor was the menu "double" click issue.
The UI also looks terrible on Windows. I'll try and polish it more
before release. The widgets need to be a lot smaller on Windows to look
good, so I'll have to add extensions to libui to query how tall widgets
should be, as I was saying before.
The cheat code editor is the only non-functional window. It's there for looks only at the moment.
I'm very curious in hearing how it works for Linux/BSD users. The Xv
renderer should hopefully work everywhere, but will probably have lots
of problems with ATI cards, as it always has.
Man, this UI rewrite is taking forever :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon May 28, 2007 8:59 am Post subject: |
|
byuu wrote: |
I was not able to find out how to get the local user directory on
Windows without requiring the <windows.h> header file (for
SHGetPath or whatever). I am not
adding that header in to libbase.h, so either we find a way to do it
with functions in Visual C++'s standard headers, or .bsnes/bsnes.cfg
will continue to be saved in the bsnes program folder.
|
windows.h is just a massive include all (most?) other Win32 headers
header. The proper header for this stuff is shlobj.h, and the function
requires linking with shfolder (prior to shell32 I might add for
Win9x), and works on anything with IE4+ IIRC.
Not a standard header to say the least, but you surely don't need some
massive lets include every Windows prototype include.
Also note that pretty much no two versions of Windows agree where the
user directory is. Some are %windir%\profiles\user, others are
C:\Documents and Settings\user, while newest is C:\users\user, and
there was another one used on some edition/flavor of 9x, but I forget
which. Where the location actually is can change too, it's a hidden
registry setting, but you can easily edit it on any version of Windows
using TweakUI. Oh and before I forget, it's in another location
entirely on a different machine no less if the user logs into NT Active
Directory or something similar.
_________________
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 May 28, 2007 9:03 am; edited 2 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon May 28, 2007 9:01 am Post subject: |
|
henke37 wrote: |
Too
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. |
What about having one copy of the application for each user?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon May 28, 2007 9:02 am Post subject: |
|
creaothceann wrote: |
henke37 wrote: |
Too
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. |
What about having one copy of the application for each user?
|
Sure, lets have 10 copies of the same program on one computer for no good reason.
_________________
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: Mon May 28, 2007 9:10 am Post subject: |
|
Doesn't hurt much with small applications, makes the code easier and you know exactly where to find the cfg files. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon May 28, 2007 12:37 pm Post subject: |
|
Dunno if c++ can access them directly (I've never tried ) but using %UserProfile% and %AllUsersProfile% consistently should be enough for Windows, right? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon May 28, 2007 1:41 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Dunno if c++ can access them directly (I've never tried ) but using %UserProfile% and %AllUsersProfile% consistently should be enough for Windows, right? |
No, don't even think about it, I should kill you for even suggesting such a thing.
That is non consistent across versions of Windows, doesn't have to be
there, and can be set to gibberish by any program. Use the functions
you're provided to get such info instead of trying to pull it yourself
from secondary unreliable sources.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon May 28, 2007 9:27 pm Post subject: |
|
Nach wrote: |
That is non consistent across versions of Windows |
True, these particular two have only existed since Windows 2k. But then
Windows 9x users most likely aren't going to care about a multi-user
environment, (could you even have one back then?) so if the variables
aren't set bsnes could simply default to its installation directory.
Nach wrote: |
and can be set to gibberish by any program. |
I'd classify any such program as 'broken' at best and more likely
'viral' as these variables are quite essential to Windows. I also
object to calling them a secondary, unreliable source, seeing that
you're getting them straight from the operating system.
If there are any other reasons why using them might fail and there are
other, safer ways that always work, then sure, but right now I'm not
convinced.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon May 28, 2007 11:23 pm Post subject: |
|
creaothceann wrote: |
Doesn't hurt much with small applications, makes the code easier and you know exactly where to find the cfg files.  |
I'm with you on this. It just seems like a ridiculously niche scenario to have all of these conditions met:
1. more than one person uses the same computer
2. more than one person uses bsnes
3. each person's settings are radically different
4. each person alternates with such frequency that manual changes are inconvenient
I didn't make it to step 1.
The new WIP looks good, byuu. You're already aware of remaining issues.
If screenshot functionality makes it back in, it would be nice to have
path entry for this, too.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 29, 2007 4:26 am Post subject: |
|
Verdauga Greeneyes wrote: |
Nach wrote: |
That is non consistent across versions of Windows |
True, these particular two have only existed since Windows 2k. But then
Windows 9x users most likely aren't going to care about a multi-user
environment, (could you even have one back then?) so if the variables
aren't set bsnes could simply default to its installation directory.
|
Windows had multiuser support since 95.
Verdauga Greeneyes wrote: |
Nach wrote: |
and can be set to gibberish by any program. |
I'd classify any such program as 'broken' at best and more likely
'viral' as these variables are quite essential to Windows.
|
Any program can modify them, you don't even have to know about it. And
they aren't even remotely essential, it's only essential for 'broken
programs'.
Verdauga Greeneyes wrote: |
I also object to calling them a secondary, unreliable source, seeing
that you're getting them straight from the operating system.
|
Yeah that'd be true, if you actually got them straight from the
operating system, but you're not, you're getting them straight from an
unsupervised playground. SHGetFolderPath() is how you get them straight
from the operating system.
Verdauga Greeneyes wrote: |
If there are any other reasons why using them might fail and there are
other, safer ways that always work, then sure, but right now I'm not
convinced. |
Good don't be convinced, give me a list of programs you wrote so I know
to stay away from them. Last thing we need is even more applications
with security holes in them.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 29, 2007 4:37 am Post subject: |
|
FitzRoy wrote: |
creaothceann wrote: |
Doesn't hurt much with small applications, makes the code easier and you know exactly where to find the cfg files.  |
I'm with you on this. It just seems like a ridiculously niche scenario to have all of these conditions met:
1. more than one person uses the same computer
2. more than one person uses bsnes
3. each person's settings are radically different
4. each person alternates with such frequency that manual changes are inconvenient
|
I have this scenario back at my parent's house. My siblings have one
computer shared between them. Each person likes some SNES game and
plays them in ZSNES. Each one of them prefers different controls. At
the time I set this up, most of them were too young to have a clue on
how to change the controls, consider that two of them can't even read
the menus.
Now I set this up some years back, each one knows to double click on
their picture on the load screen to get in, and then to click one of
the pretty icons on the desktop for the game they want to play. Since
ZSNES didn't support multiuser on Windows back then (and even now you
need SVN for multiuser), I made it that each one's launch icon ran a
batch file which copies <name>.cfg to zsnesw.cfg, runs zsnesw
with the game in question, then copies the config file back. For your
average non technical person who wants to setup a game PC for such a
scenario, it'd be much easier if the programs in question supported
multiuser internally. If bsnes wants to cater to your family computer
where no one is the family really has more advanced computer know how,
it would need the support internally.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue May 29, 2007 6:19 am Post subject: |
|
byuu wrote: |
I
was not able to find out how to get the local user directory on Windows
without requiring the <windows.h> header file (for SHGetPath or
whatever). I am not adding that header in to libbase.h. [..] |
As a last resort, you can always do the following, no matter what hoops
you have to jump through to access the desired function:
Code: |
// libbase.h
... MySHGetPath( ... );
// libbase.c
#include <windows.h>
... MySHGetPath( ... )
{
return SHGetPath( ... );
} |
henke37 wrote: |
To
be fair, I personaly hate when applications store configuration files
in their directory only. It is a lot of trouble in a multi user
environment. |
Plus it prevents a smart user/admin from making their program directory
read-only. Settings should always be stored in a system/user-defined
location. Obviously this requires that the program be provided at
minimum with a directory to store its data, either by the system or
some environment variable. The only use a program should make of the
path to its executable is to find any related read-only
data files that go along with it. Of course on UNIX you can make a
symlink to a program instead of making multiple copies, but it's still
a poor strategy since it requires you loosen restrictions (at least in
my noobish understanding of UNIX access control; maybe you can grant
read/write access to a single file in an otherwise read-only directory).
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 29, 2007 6:29 am Post subject: |
|
Nach wrote: |
Each one of them prefers different controls. |
See, this is where I would have gotten them a gamepad, set it up
myself, and told them to share it or I delete their savegames. :P On
the real SNES, the controllers are universally laid out, so why do
these kids need to have their own schemes? They don't. When they get
older and play newer systems with axis sensitivity and reversal options
to worry about, then they can have their own profile and bug me to show
them how.
Anyway, I don't care about multi-user so long as it isn't in direct
opposition to having a cfg in the bsnes root. But you can't just change
something to appease a such a small group of users because then you're
simply shifting the dissatisfaction to a far larger group of users who
would rather not have their cfg in some obscure directory. And with all
the cfg issues on people updating zsnes but not deleting their cfg,
you'd think it should be as easy to locate as possible.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 29, 2007 8:37 am Post subject: |
|
Ok, here's a public WIP for everyone:
Code: |
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip40.zip |
Please ... if you link to this post or file elsewhere, please mirror it.
Fixes since wip39:
- menu enter event captured, audio no longer hangs when entering the menu.
- multiple click problems resolved for all menu items plus list box
controls. Behavior should now be the same on both Windows and Linux,
but further polish is definitely needed here.
- buttons to set values on input config and advanced panels are now disabled when no item is selected.
Known problems:
- Windows/VC++ port is still complaining about that
interface::input.bind() thing. I believe it is a compiler problem. I am
not working around it, as I prefer a real fix. If anyone can help,
please see src/ui/lui/settings/ui_inputconfig.cpp, look for that line.
It is #if !defined(_MSC_VER) blocked at the moment. Until this is
resolved, you must restart before input settings take effect.
- Joypads cannot be auto polled on input config screen. You can set the
values manually on the advanced tab, they use the same values as bsnes
v019, IIRC.
- When pressing enter (or spacebar on Linux) on the input config panel,
the dialog pops up and closes right away assigning that key. I have no
easy way to fix this, since I can't poll the realtime status of those
keys on Linux to wait for them to clear before showing the input
capture window. It would really be immensely useful to be able to do
that.
- Linux with ati driver requires you to move the window one time to
make the image visible ... I have no idea why this is needed. nv and
nvidia drivers work fine. Use the gtk renderer if you don't like the
chroma blending that using YUY2 mode requires.
- Linux port does not focus properly to panel list when opening config screen.
- Config file still saves to startup working directory, rather than the
user folder. Still planning to work on that.
- UI is still pretty ugly on Windows, but overall it's not too bad.
Looks beautiful on Linux, though ... maybe if I could find a way to
enable theme support for Windows. I tried making a .manifest file and
using mt, and setting WINVER + _WIN32_WINNT to 0x0500, none of those
did anything.
- Cheat code editor has not been reimplemented yet. Really the last
major thing holding back a new release, but the above are pretty
important, too.
Let me know if anything else major pops up.
blargg wrote: |
Plus it prevents a smart user/admin from making their program directory read-only. |
Once again, blargg has the most convincing argument :)
Wouldn't want that config file on a read-only medium, eg CD-ROM.
I was wanting to implement this on Windows anyway, but this makes it something I simply have to do.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 29, 2007 9:55 am Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
Each one of them prefers different controls. |
See, this is where I would have gotten them a gamepad
|
They already have gamepads.
FitzRoy wrote: |
set it up myself, and told them to share it or I delete their savegames. 
|
So I take it you don't have younger siblings or kids.
FitzRoy wrote: |
On the real SNES, the controllers are universally laid out, so why do
these kids need to have their own schemes? They don't.
|
No one needs to play games either.
However, back when I was a kid, I whined to my parents about my NES not
having a joystick and it driving me crazy, so they got me the NES
Advantage. The SNES for example had 25+ controllers out there, some
which did have programmable buttons. I personally preferred using the
SNES with the ASCII pad, it just fit in my hands better.
Family PC has 3 different types of gamepads, each have their own
preference on which to use, and they like certain buttons in various
places, if one can cater to them, why not? If you want to take the
analogy further, on the SNES, if you had multiple pads and disliked
one, you just switch it and it works. On a PC, you dislike one, you
switch it, and absolutely nothing happens because you need to configure
these things.
FitzRoy wrote: |
When they get older and play newer systems with axis sensitivity and
reversal options to worry about, then they can have their own profile
and bug me to show them how.
|
They won't be playing newer systems, as no one has any intention in
buying them. Years ago, a console made sense, it had the best games,
and there were like 4 that you would find in your local Toys R Us. Now
PC games are just as good, backwards compatible, so you don't need all
sorts of hardware lying around to play all your games, and you don't
walk into Toys R Us, see a dozen to choose from, and know whichever you
buy you won't be able to play even 20% of the games you find in their
game isle.
FitzRoy wrote: |
Anyway, I don't care about multi-user so long as it isn't in direct
opposition to having a cfg in the bsnes root. But you can't just change
something to appease a such a small group of users because then you're
simply shifting the dissatisfaction to a far larger group of users who
would rather not have their cfg in some obscure directory. And with all
the cfg issues on people updating zsnes but not deleting their cfg,
you'd think it should be as easy to locate as possible. |
You can have both, and not having multiuser support these days is just
stupid. And the config issue no longer exists in ZSNES, I replaced the
binary config file with a text based one since 1.5, which doesn't have
the same limitations.
byuu wrote: |
blargg wrote: |
Plus it prevents a smart user/admin from making their program directory read-only. |
Once again, blargg has the most convincing argument 
Wouldn't want that config file on a read-only medium, eg CD-ROM.
I was wanting to implement this on Windows anyway, but this makes it something I simply have to do.
|
If you followed a similar thread from ZSNES development, and I think
you did since I recall you commenting privately to me about it, we had
this and more.
http://board.zsnes.com/phpBB2/viewtopic.php?t=9702 (If you can't see it, don't tell me it's broken)
If I remember wrong, and you hand not seen it before, you'll want to
look at it for a list of the pros and cons each way and what you might
want to do to make everyone happy.
_________________
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: Tue May 29, 2007 6:18 pm Post subject: |
|
Oh
well, I might use that function to look into the user's directori(es)
first - or not, if vSNES is started with a special command-line switch.
byuu wrote: |
Please ... if you link to this post or file elsewhere, please mirror it. |
Have you looked into nsis? It should at least make releases smaller.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue May 29, 2007 7:07 pm Post subject: |
|
creaothceann wrote: |
Have you looked into nsis? It should at least make releases smaller. |
If he wanted to make releases smaller, he'd probably be best off with
making RAR or 7z self extracting archives. Although for source, you
want tar + bz2 or tar + ppmd.
_________________
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: Tue May 29, 2007 8:02 pm Post subject: |
|
Nach wrote: |
So I take it you don't have younger siblings or kids. |
No, I have younger cousins, too. I was also a kid once myself, and
don't remember being demanding to the extent that I questioned how
buttons were mapped. I mean, there were gamepads with turbo settings
and stuff like that, but I never wanted to flip A and B, or L and R, or
Select and Start. It just never occurred to me to do that because I was
too busy having fun.
But yes, blargg has a good point with the CD-ROM thing.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 29, 2007 8:10 pm Post subject: |
|
I've
decided to abandon the GPL as a legal template for the reference
license I wanted to create, and instead decided to work off of the Ms-RL. Clearly, as always, I need to rewrite the license in my own words, but below is just a template.
Does this one at least look legally sound? See any obvious flaws / holes / contradictions?
Quote: |
This
license governs use of the accompanying software. If you use the
software, you must accept this license. If you do not accept the
license, you may not use the software.
1. Definitions
The terms "reproduce," "reproduction" and "distribution" have the same
meaning here as under U.S. copyright law.
"You" means the licensee of the software.
"Reference use" means your modification of the software and use thereof
as a reference, for the sole purpose of research, and specifically
excludes the right to distribute any modifications to the software, in
any form and through any means, except to the licensor.
2. Grant of Rights
(A) Subject to the terms of this license, the licensor grants you a
non-transferable, non-exclusive, worldwide, royalty-free copyright
license to use and reproduce the unmodified software, provided there is
no charge for the software, nor for any medium upon which the software
is distributed.
(B) Subject to the terms of this license, the licensor grants you a
non-transferable, non-exclusive, worldwide, royalty-free copyright
license to modify this software for reference use only.
3. Limitations
(A) This license does not grant you any rights to use the licensor's name, logo, or trademarks.
(B) This software is provided by the licensor "as is", and any express
or implied warranties, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose are
disclaimed. In no event shall the licensor or contributors be liable
for any direct, indirect, incidental, special, exemplary, or
consequential damages (including, but not limited to, procurement of
substitute goods or services; loss of use, data, or profits; or
business interruption) however caused and on any theory of liability,
whether in contract, strict liability, or tort (including negligence or
otherwise) arising in any way out of the use of this software, even if
advised of the possibility of such damage. |
Last edited by byuu on Tue May 29, 2007 10:16 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 29, 2007 8:38 pm Post subject: |
|
byuu wrote: |
- UI is still pretty ugly on Windows, but overall it's not too bad.
Looks beautiful on Linux, though ... maybe if I could find a way to
enable theme support for Windows. I tried making a .manifest file and
using mt, and setting WINVER + _WIN32_WINNT to 0x0500, none of those
did anything.
|
As far as the way the sizes and layout of things have carried over, it
looks great to me. I don't know about the themes thing because I
haven't tried it. What I have tried is some of XP's own built-in color
schemes. The only section that exhibits issues with these is the raster
settings. The sliders stay the same standard color no matter what. I'm
thinking this might be an issue you're unaware of, so if this were
fixed you'd at least be safe with schemes. This is "wheat" btw,
although I think they should have called it "piss."
Last edited by FitzRoy on Sun Apr 20, 2008 7:53 am; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue May 29, 2007 8:44 pm Post subject: |
|
Well,
the editbox heights are too big. They are 30px, and Microsoft didn't
have the foresight to center the text in the boxes vertically, so it
looks kind of tacky. My idea was to make a libui function that gives
you "suggested" sizes for controls, and just expand the listboxes to
fill the leftover space left after adding the buttons and editboxes ...
As for the sliders, yeah, I've seen that problem before. Unfortunately,
those controls seem to get their background color from somewhere else.
Even using SetClassLong to change the background brush appears to do
nothing. And WS_EX_TRANSPARENT, as always, does absolutely nothing. I am unsure of a solution ...
EDIT: this only seems to affect XP ... http://img485.imageshack.us/img485/5471/untitleddp2.jpg |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue May 29, 2007 9:11 pm Post subject: |
|
byuu wrote: |
Well,
the editbox heights are too big. They are 30px, and Microsoft didn't
have the foresight to center the text in the boxes vertically, so it
looks kind of tacky. My idea was to make a libui function that gives
you "suggested" sizes for controls, and just expand the listboxes to
fill the leftover space left after adding the buttons and editboxes ... |
Yeah, I see what you're talking about. Nowhere near as unsightly as the
slider thing, but they would look better without the extra height.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue May 29, 2007 9:51 pm Post subject: |
|
Quote: |
On the real SNES, the controllers are universally laid out, so why do these kids need to have their own schemes? They don't. |
People mostly non-SNES controllers with their PCs, which usually don't
exactly match the SNES button layout. Also, people use emulators for
their added flexibility, though sometimes "customizable just because it
can be" goes too far.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue May 29, 2007 10:50 pm Post subject: |
|
yeah in Super Metroid and Yoshi's Island I switch my firing action to a shoulder button trigger.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue May 29, 2007 11:10 pm Post subject: |
|
Panzer88 wrote: |
yeah in Super Metroid and Yoshi's Island I switch my firing action to a shoulder button trigger. |
Well, Super Metroid allows you to change the button config in it's
option...So it would be kinda silly to change the emulator button
layout just for the game.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 30, 2007 1:09 am Post subject: |
|
blargg wrote: |
Quote: |
On the real SNES, the controllers are universally laid out, so why do these kids need to have their own schemes? They don't. |
People mostly non-SNES controllers with their PCs, which usually don't exactly match the SNES button layout.
|
Very true, but I'm meaning to say that I would just set up the
controller as closely as possible to an SNES one for the kids and tell
them to share it. If they're not made aware of the configuration, or
that filters exist, or any of that stuff, then none would feel like
they're missing something and a fight would never break out over it.
Anyway, multi-user configuration has its uses, but let's just be aware
of how incredibly niche they are for most programs due to the
aforementioned requirements I laid out.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed May 30, 2007 2:46 am Post subject: |
|
Snark wrote: |
Panzer88 wrote: |
yeah in Super Metroid and Yoshi's Island I switch my firing action to a shoulder button trigger. |
Well, Super Metroid allows you to change the button config in it's
option...So it would be kinda silly to change the emulator button
layout just for the game.
|
I thought of that after posting, so nix that, but you get my point, ANY
game that involves shooting, it's easier to assign it to a shoulder
button if you have a run and jump button also.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 30, 2007 5:00 am Post subject: |
|
New WIP up.
I've replaced the interface::input setup, since Visual C++ was having
problems with it. I wanted something that wasn't so seemingly directly
linked to SNESInterface, anyway. Now I have InputManager, which will
handle not only all of the joypad mappings, but the GUI shortcut keys
as well. Yes -- I finally have all the code in place to support
user-defined shortcut keys. See? Something good did come out of the
rewrite after all. Dynamic keyboard mapping works on Windows now, but
there probably won't be joypad capture support until v0.021.
Further, I have added SHGetFolderPath to the Windows port. libbase.h
sadly requires shell32.lib now. I haven't tested this on 9x, but I
don't believe bsnes has worked on 9x in a long, long time now. I've
also heard you can copy shfolder.dll or something to use it on 9x
anyway.
Anyway, the config file now saves in your 'Application Data' folder on
Windows, and in your local directory on Linux. There's no need to worry
about what happens when you update bsnes and don't delete the file ...
as I use a text-based config file, like ZSNES / PSR, no harm will come
of it. Old variables will be flushed out, new variables will be added
with default values upon first load of the new version. Thanks again to
Nach for the code and help with this.
Lastly, I've added a bsnes license page.
So instead of debating whether to look up four letter English words in
Perens', Stallman's or Webster's dictionary, you can just link to that
page instead :)
Again, the license applies to
current and previous versions of bsnes. If and when it forks, the fork
will likely be licensed in a way that others can take over the old
version.
Opinions on how to fix contradictions / loopholes welcome, blanket
statements that it's totally flawed without describing why or how are
not. Thanks in advance. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed May 30, 2007 6:24 am Post subject: |
|
Well,
don't I feel dumb now. :/ I don't think you've got anything to worry
about regarding the XP color schemes, byuu. That "bug" only happens
when you change the scheme while bsnes is running. If you restart the
program or use the sliders, their colors change to the new scheme. My
bad. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed May 30, 2007 9:15 am Post subject: |
|
byuu wrote: |
I've
decided to abandon the GPL as a legal template for the reference
license I wanted to create, and instead decided to work off of the Ms-RL. Clearly, as always, I need to rewrite the license in my own words, but below is just a template. |
I'd recommend against rewriting the license in your own words, except
for the obvious replacement of "Microsoft" with your own details, and
so forth. In the same way that the careful positioning of semicolons in
C++ might easily be ignored by a lawyer, legal documents often have
particular phrases and structures that look like any other English text
to the layman but are designed to invoke the protections of particular
legal precedents and laws. I dare say Microsoft paid a good many
lawyers a lot of money to put together their licence, it would be a
shame to waste all that effort.
(that's why Creative Commons licences are so useful - mix-and-match
terms, with human-readable equivalents, already reviewed and debugged
by expensive lawyers)
Quote: |
Does this one at least look legally sound? See any obvious flaws / holes / contradictions?
Quote: |
This
license governs use of the accompanying software. If you use the
software, you must accept this license. If you do not accept the
license, you may not use the software. |
|
I'm not a lawyer, but I believe that a licence cannot allow or prevent
a user from using software they have lawfully acquired (think about it:
user downloads software, unzips, runs bsnes.exe - if they're allowed to
run the software without having to look at licence.txt, obviously it's
effectively ignorable. Even click-through licenses don't actually force
people to read, acknowledge, and agree to the contents, they just force
people to click the checkbox and hit 'next').
That's the nice thing about the GPL: the default state of a work under
copyright law is "nobody's allowed to duplicate it in any way"; the GPL
adds the exception "you're allowed to copy it if you conform to these
extra rules". If a user doesn't agree to the rules or if they don't
even read them, the user is still held to standard copyright law.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed May 30, 2007 2:26 pm Post subject: |
|
Quote: |
I'd
recommend against rewriting the license in your own words, except for
the obvious replacement of "Microsoft" with your own details, and so
forth. |
Alright, I have taken your advice and copied the legal semantics in more detail.
Quote: |
I'm
not a lawyer, but I believe that a licence cannot allow or prevent a
user from using software they have lawfully acquired (think about it:
user downloads software, unzips, runs bsnes.exe - if they're allowed to
run the software without having to look at licence.txt, obviously it's
effectively ignorable. Even click-through licenses don't actually force
people to read, acknowledge, and agree to the contents, they just force
people to click the checkbox and hit 'next'). |
Then how is it possible for software to enforce non-commercial
agreements? Nonetheless, I have looked over the exclusive rights
("pillars") of copyright, and I will agree with you to be on the safe
side.
I have modified the license to restrict only the rights granted by
copyright, the exclusive rights granted to the copyright owner, unless
the license is accepted.
The license grants reproduction rights so long as the software remains
free and unmodified, and adds an exception to transmit modifications to
the licensor only.
Hopefully this will do. It's a shame this sort of legal wrangling is
necessary. The intent could be summed in a single sentence:
"You are free to use and distribute the unmodified software, but any
modifications or derivations must be submitted directly to me, and not
distributed publically."
Does everything I want to a tee. It's unbelievable that such a license
doesn't exist already. I don't understand why there is this huge divide
between hidden and obfuscated closed source applications, and giving up
absolutely all rights and control over your software. I'm starting to
understand why some people just don't bother posting their source in
the first place.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu May 31, 2007 3:22 am Post subject: |
|
Thristian wrote: |
In
the same way that the careful positioning of semicolons in C++ might
easily be ignored by a lawyer, legal documents often have particular
phrases and structures that look like any other English text to the
layman but are designed to invoke the protections of particular legal
precedents and laws. |
Well-put. With the great number of open-source licenses available, I
think it's foolish for anyone to craft their own. Even if you have a
lawyer check your work, it's still a new license that you won't be able
to go elsewhere for elaboration on.
byuu wrote: |
It's
unbelievable that such a license doesn't exist already. I don't
understand why there is this huge divide between hidden and obfuscated
closed source applications, and giving up absolutely all rights and
control over your software. |
Because there are many types of control an author might want between all and none.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 31, 2007 5:06 am Post subject: |
|
Quote: |
Because there are many types of control an author might want between all and none. |
... so you're supporting my argument? :/
I feel the same way, but there does not appear to be pre-made licenses supporting the middle grounds here.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu May 31, 2007 5:24 am Post subject: |
|
better to use something that assuredly protects you on all fronts though than to take a chance.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu May 31, 2007 6:12 am Post subject: |
|
Quote: |
Well-put.
With the great number of open-source licenses available, I think it's
foolish for anyone to craft their own. Even if you have a lawyer check
your work, it's still a new license that you won't be able to go
elsewhere for elaboration on. |
Quote: |
better to use something that assuredly protects you on all fronts though than to take a chance. |
If anyone can point me to a license that does the same as mine, I will
happily use it. I have looked for a long time and found no such
license. The closest I could find were bogged down in countless pages
of legalese that could have all kinds of hidden meanings I do not
intend. Further, many popular licensing agreements, even those from
Microsoft such as their famous EULAs, probably won't hold up in court.
There's no guarantee a license will until it has been tried in court.
But let's be realistic. Even the GPL has only been tested once, and even then only in a German court.
If someone intends to violate my license, they are going to do so. And
I do not have the money to sue anyone over it, I could not reasonably
claim damages on free (yes, as in price) software, and I further
wouldn't even want such money, except to cover my own costs. All a
license does is attempt to state the legal boundaries in which my works
can be used. It at least would cause great harm to the credibility of
anyone violating the license, and I may be able to bring violations to
the attention of hosts, such as SourgeForce and BountySource. But
that's about all I can afford to do. Take a look at MAME32k sometime.
Nobody attempted to defend the MAME license when it was violated there.
If I were dead serious on absolutely controlling derivative works, I
would simply refrain from releasing source code. But I don't want that.
I want to offer anyone the ability to build the source, learn from it
-- possibly to improve upon their own emulators, and submit bugfixes
and patches to me if they choose to. I am taking a small risk by
releasing the source code, and I already know that. I believe stronger
in the aforementioned ideals than in protecting my work absolutely,
however. The only thing that really scares me is the prospect of
competing against myself and having my userbase, those who help me by
submitting bugfixes to me, and the project itself forked. I realize
this is highly unlikely, but I am only a single developer. I most
likely could not compete even against a single developer, let alone a
team of people who decided to fork my work. Mister Belmont made an
excellent point that this is extremely unlikely to occur ... however I
simply won't take that chance until I have ceased active development of
a branch of bsnes. This is nearly the same thing zsKnight and _Demo_
did with ZSNES, and Jeremy Koot and Gary Henderson did with SNES9x.
Both closed source until the authors were preparing to mostly leave the
projects, then open sourced to attempt to increase their longevity.
My plans now are to write up that article about software licensing this
weekend, and end my involvement in such debates. I've gone over my
stances, spent months looking at all of my options, and I'm pretty much
tired of it. The reality is that nobody is actually affected by this.
Since I started bsnes, I've offered to relicense any and all of my code
upon request. I would go so far as to offer that work as PD, depending
on what the person wanted to do with the code. To date, not one person
has ever directly asked me for any of the code, yet many have attacked
me in public over my choice of license. It seems people are more
interested in debating over ideals than actual merit. End users care
even less about licenses. The fantastic pSX is closed source, yet
nobody cares any less except maybe three or four others who are also
writing PSX emulators, and ten or so others who want to make changes to
it themselves. There's no point dwelling on this issue forever, and I
apologize that I have done just this for the past few months here and
on my website. I'll end this discussion and move on this weekend.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu May 31, 2007 3:45 pm Post subject: |
|
byuu wrote: |
But let's be realistic. Even the GPL has only been tested once, and even then only in a German court. |
Good enough for me. 
Quote: |
All
a license does is attempt to state the legal boundaries in which my
works can be used. It at least would cause great harm to the
credibility of anyone violating the license, and I may be able to bring
violations to the attention of hosts, such as SourgeForce and
BountySource. |
Do they need some legalese for that? If your intention is sufficient
then just use that summary you posted earlier.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 01, 2007 3:32 pm Post subject: |
|
I've
noticed what I believe to be a small bug with the WIP 40 public beta: I
(accidentally) set the scale to 4x, which doesn't fit on my laptop's
1440x900 resolution. But rather than showing only the top part as I
expected, bsnes apparently minimised itself. I right-clicked it on the
taskbar and chose to 'Move' it, at which point my cursor was moved to
the bottom-right corner of the screen, leading me to believe that bsnes
was somehow being drawn off-screen. Only deleting the .cfg file worked
to get bsnes visible again. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 01, 2007 4:09 pm Post subject: |
|
Hmm,
you say it was offscreen? I just figured Windows was hiding the window
because it was too large. Now, I'm thinking it's because my centering
algorithm is probably underflowing, putting it at some crazy position
like (-50, -80) or something.
It's tricky to
just block sizes larger than the current display, because the window
size is actually larger than (256,224)*multiplier. I don't really like
the idea of trying to figure out all the GetSystemMetrics calls I'd
need to get a true window size, but I guess I can use my hidden window
to get that. That will be a lot of fun getting to work on Linux, where
it's virtually impossible to get the total window size, because the
decorations are drawn by the WM ...
EDIT: yep, that was it. Thanks for the report.
src/lib/lib_win_window.cpp:
Code: |
void Window::resize(uint width, uint height) {
info.width = width;
info.height = height;
SetWindowPos(info.hwnd_resize, 0, 0, 0, width, height, SWP_NOZORDER | SWP_NOMOVE);
RECT rc, workarea;
SystemParametersInfo(SPI_GETWORKAREA, 0, &workarea, 0);
GetClientRect(info.hwnd_resize, &rc);
width += width - (rc.right - rc.left);
height += height - (rc.bottom - rc.top);
uint x, y;
if(GetSystemMetrics(SM_CXSCREEN) < width) {
x = workarea.left;
} else {
x = (GetSystemMetrics(SM_CXSCREEN) - width) >> 1;
}
if(GetSystemMetrics(SM_CYSCREEN) < height) {
y = workarea.top;
} else {
y = (GetSystemMetrics(SM_CYSCREEN) - height) >> 1;
}
SetWindowPos(info.hwnd, 0, x, y, width, height, SWP_NOZORDER | (info.center == true ? 0 : SWP_NOMOVE));
} |
(note that I am aware of AdjustWindowRect, but if your menubar takes
more than one line, it fails miserably at its' task).
Kind of botchy, probably don't want it to poll the work area when it
isn't needed like that all the time, not that the function is slow or
anything like that.
The above will center the window unless it's larger than the screen
size. If the window is larger, it sets it to the top left of the
visible work area (basically, if you put your taskbar at the top, my
code will actually see that and not try and stick the window at 0, 0
where you can't get at the titlebar controls like most apps love to do
to piss you off).
I debated just 'reverse centering' the window (show the center of the
window on the screen), but if I do that, it may be really hard to get
to the menubar to set a smaller screen multiplier. Ideally, a
pseudo-fullscreen toggle will be added in the future so nobody would
want that anyway.
Doing this same thing on Linux would be a lot harder, but the WMs there
tend to be more intelligent about letting you control oversized
windows, so it probably isn't needed.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 02, 2007 6:57 am Post subject: |
|
Added
a much better fix to the window resize problem. Same behavior I
mentioned above. Interesting, the behavior is the same on Linux with
XFCE's window manager: put a window at a negative position and it sets
it to the top/left of the visible workarea. Cool.
blargg very generously sent me a customized version of his S-DSP
emulator, optimized for bsnes and its cothreads + template function
library. It passes all of his extensive tests, so no regressions
resulted from this. This is very much appreciated, thank you blargg.
I'm pretty much ready to release a new version. I've been dying to let
the (albeit wealthier due to sys reqs) general public check out
blargg's awesome work officially. The remaining issues are going to
take me a long time to address (cheat editor, joypad mapping from the
UI, fullscreen, debugger) ... so I'm thinking, disable the cheat editor
tab and post a new version. Both cheats and the joypad controls still
work, you just have to edit the cht and cfg files by hand (or copy them
from v0.019's config file), sadly.
I'll probably end up spending another few weeks / months fixing the
above issues before I even consider forking bsnes.
Does anyone know of any show-stopping issues that should be addressed now before a new release? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 02, 2007 8:45 am Post subject: |
|
Can't
think of any issues, but I was meaning to ask you: is it possible to
get the triple buffering option back? Even if it was relegated as an
advanced option, at least those of us who can get it working can use it.
Also, I probably wasn't too clear about this earlier, but I do indeed
think that it would be nice to have the video settings in the config
window as well as the menu. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 02, 2007 9:32 am Post subject: |
|
For
those interested, I have started my articles section on my site, and as
promised, here is my article regarding software licensing:
http://byuu.cinnamonpirate.com/?page=articles/licensing
I'm interested in opinions, though I do not have nor will not add a
comments section on the site, as I suspect I will receive many very
negative responses that I do not want on my site.
Other than responding to some opinions, consider the topic closed for me from this point on. I need to move on.
Quote: |
Can't
think of any issues, but I was meaning to ask you: is it possible to
get the triple buffering option back? Even if it was relegated as an
advanced option, at least those of us who can get it working can use it. |
I could get it working in windowed mode again, but I no longer have a
true fullscreen mode, so I'm not sure how well it will work. The
windowed triple buffering mode is most likely just a vsync trick that
is wrapped around the same API as fullscreen triple buffering, as
obviously true triple buffering is not possible in a windowed
environment.
I'm sorry about this, this is one of the real sacrifices in return for
the Linux port. But since I'm pretty much using Linux exclusively now,
it's kind of needed for me to have a better port than the old SDL
window.
It is still possible that I can add back a true fullscreen mode, at
least for the Windows port, however. So I won't rule the possibility
out.
Quote: |
Also,
I probably wasn't too clear about this earlier, but I do indeed think
that it would be nice to have the video settings in the config window
as well as the menu. |
Yes, sorry. I will do my best to add that to v0.021. The next release
shouldn't take nearly as long as v0.020 has ... I hope not more than a
month or two. And of course, you'll have the WIPs a little sooner than
that.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 02, 2007 8:40 pm Post subject: |
|
Many thanks for explaining. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 03, 2007 4:55 am Post subject: |
|
lol, yeah I did a round through my favorites and saw your website post before you managed to post here I'm working on my resume right now. Thanks for the new version! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 03, 2007 7:08 am Post subject: |
|
Thanks for the new release! I'm using it to play Chrono Trigger right now. (actually just enjoying the music for now
) Unfortunately I noticed from the intro that the Black Omen appearing
scene brings my poor Athlon 64 X2 @ 2.5GHz to its knees (well it just
barely drops below 60fps, but it's enough to make the sound pop a
bit).. so I was wondering, do you still intend to look into moving all
video-related processing to a second core (if present)? |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sun Jun 03, 2007 8:15 am Post subject: |
|
In
future versions, will it be possible again to have the .cfg back in the
emulator's directory? I actually prefer to have all my config files
within the same directory and I'm not in a multi-user environment.
The version is great!
_________________
"Change is inevitable; progress is optional" |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jun 03, 2007 8:27 am Post subject: |
|
brilliant revisions, now hopefully buy the end of the summer I'll have a computer that runs it properly 
sometimes I think things reach a saturation point but even on my crusty
old computer it's nice to literally be able to see an emulator evolving
before my eyes and continue to push new accuracy and features.
Thank You. Congrats for v0.20
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jun 03, 2007 8:39 am Post subject: |
|
where do i get v0.19? so i can configure my joypad?
edit: ok, well i prefer the cfg file in the same folder as bsnes because its a pain exploring to 2 places.
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 03, 2007 9:05 am Post subject: |
|
You
know, maybe the cfg just needs to default in the root directory, but
have its path changeable in the advanced settings. Possible?
PS: Would this new bsnes version work on the PS3's linux? If so, I'd be really interested to know how well it runs. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jun 03, 2007 9:07 am Post subject: |
|
Thanks for the support, all.
For those interested, the winners for finding out about the new version the fastest are:
1) FitzRoy
2) snesemu.free.fr
3) e-lation.net
Quote: |
In future versions, will it be possible again to have the .cfg back in the emulator's directory? |
I don't have an easy way to do both. Why not make a shortcut to the
config file in your current directory? The end result would be the
same. Otherwise, it may not be possible to run bsnes from a read-only
medium.
Quote: |
where do i get v0.19? so i can configure my joypad? |
Try v0.018. You can also configure the joypad by editing the config
file. Set the key values to 'joypadN.key', N is the joypad number,
starting at 0. key can be 'up', 'down', 'left', 'right', and 'buttonY'
where Y is the button number, starting from 0.
So, for example, you could have:
input.joypad1.up = "joypad0.up"
input.joypad1.x = "joypad0.button0"
...
I'll be working on a fix for this issue shortly.
Quote: |
so I was wondering, do you still intend to look into moving all video-related processing to a second core (if present)? |
Not at the moment, but possibly in the future. The first step would be
writing a cross-platform pre-emptive multithreading library. libpe,
perhaps. The next would be reimplementing how filters work. The current
implementation is kind of sketchy. The ability for the SNES to change
its' resolution every single scanline really screws with the sanity of
said code ...
Quote: |
You
know, maybe the cfg just needs to default in the root directory, but
have its path changeable in the advanced settings. Possible? |
And where do you presume I save the setting of where to store the
config file, if I have to open the config file to read the path to know
where it is stored at? :P
(yes, I could store two config files, but I'd rather not if possible ...)
I designed the advanced editor so that the location wouldn't matter ...
is it just for aesthetic reasons that people prefer the config file to
be in the same folder as the emulator itself? :/
I don't want to discount people's suggestions and preferences here, just curious.
Quote: |
PS: Would this new bsnes version work on the PS3's linux? If so, I'd be really interested to know how well it runs. |
Only if someone ports libco to the cell processor. It should be very
easy, but practically nobody wants to port libco to anything.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jun 03, 2007 9:21 am Post subject: |
|
Code: |
# Joypad 1 button map
# Format: Up; Down; Left; Right; A; B; X; Y; L; R; Select; Start
# (default = "up | joypad0.up; down | joypad0.down; left |
joypad0.left; right | joypad0.right; x | joypad0.button3; z |
joypad0.button2; s | joypad0.button1; a | joypad0.button0; d |
joypad0.button6; c | joypad0.button7; rshift | joypad0.button4; enter |
joypad0.button5")
input.joypad1.map = "joypad0.up | joypad0.up; joypad0.down |
joypad0.down; joypad0.left | joypad0.left; joypad0.right |
joypad0.right; joypad0.button2 | joypad0.button3; joypad0.button1 |
joypad0.button2; joypad0.button3 | joypad0.button1; joypad0.button0 |
joypad0.button0; joypad0.button4 | joypad0.button6; joypad0.button5 |
joypad0.button7; joypad0.button8 | joypad0.button4; joypad0.button9 |
joypad0.button5" |
i tried manualy converting this to v0.20 but it does not work... if
anything it introduced severe crackling in all the games, but i assume
this is because it is polling invalid key input.
Code: |
# (default = "up")
input.joypad1.up = "up"
# (default = "down")
input.joypad1.down = "down"
# (default = "left")
input.joypad1.left = "left"
# (default = "right")
input.joypad1.right = "right"
# (default = "x")
input.joypad1.a = "button2"
# (default = "z")
input.joypad1.b = "button1"
# (default = "s")
input.joypad1.x = "button3"
# (default = "a")
input.joypad1.y = "button0"
# (default = "d")
input.joypad1.l = "button4"
# (default = "c")
input.joypad1.r = "button5"
# (default = "rshift")
input.joypad1.select = "button8"
# (default = "enter")
input.joypad1.start = "button9" |
_________________
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.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 03, 2007 9:33 am Post subject: |
|
Well, as a quick pointer, here's my current input configuration: (the joypad1 part anyway)
Code: |
# (default = "up")
input.joypad1.up = "joypad0.up"
# (default = "down")
input.joypad1.down = "joypad0.down"
# (default = "left")
input.joypad1.left = "joypad0.left"
# (default = "right")
input.joypad1.right = "joypad0.right"
# (default = "x")
input.joypad1.a = "joypad0.button1"
# (default = "z")
input.joypad1.b = "joypad0.button2"
# (default = "s")
input.joypad1.x = "joypad0.button0"
# (default = "a")
input.joypad1.y = "joypad0.button3"
# (default = "d")
input.joypad1.l = "joypad0.button6"
# (default = "c")
input.joypad1.r = "joypad0.button7"
# (default = "rshift")
input.joypad1.select = "joypad0.button9"
# (default = "enter")
input.joypad1.start = "joypad0.button8" |
Last edited by Verdauga Greeneyes on Sun Jun 03, 2007 9:34 am; edited 1 time in total
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jun 03, 2007 9:34 am Post subject: |
|
oh, i see now, thank you very much =)
edit: yesss it works good job byuu
_________________
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: Sun Jun 03, 2007 9:40 am Post subject: |
|
byuu wrote: |
Quote: |
In future versions, will it be possible again to have the .cfg back in the emulator's directory? |
I don't have an easy way to do both. Why not make a shortcut to the
config file in your current directory? The end result would be the
same. Otherwise, it may not be possible to run bsnes from a read-only
medium.
|
Could be done by checking the command-line parameters.
_________________
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: Sun Jun 03, 2007 10:08 am Post subject: |
|
hey,
with the "unload" function (windows port) shouldn't the screen get
refreshed when you choose this so as to make the screen be black?
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 03, 2007 10:13 am Post subject: |
|
byuu wrote: |
For those interested, the winners for finding out about the new version the fastest are:
1) FitzRoy
2) snesemu.free.fr
3) e-lation.net |
Was there ever any doubt? I win this round, obscure emulation news sites...
byuu wrote: |
And where do you presume I save the setting of where to store the
config file, if I have to open the config file to read the path to know
where it is stored at?  |
Doh!
byuu wrote: |
I designed the advanced editor so that the location wouldn't matter ...
is it just for aesthetic reasons that people prefer the config file to
be in the same folder as the emulator itself? :/
I don't want to discount people's suggestions and preferences here, just curious. |
Once joystick polling gets in, I don't think it will really matter.
byuu wrote: |
Only if someone ports libco to the cell processor. It should be very
easy, but practically nobody wants to port libco to anything. |
Hmmm, another DIY project? Could help get your emu some attention. I don't think zsnes works at all on the ps3, and snes9x has... issues.
franpa wrote: |
hey,
with the "unload" function (windows port) shouldn't the screen get
refreshed when you choose this so as to make the screen be black? |
It's a known problem.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jun 03, 2007 10:27 am Post subject: |
|
is
it possible to generate a shortcut to the config file when you run
bsnes? thus we can still double click something in the emulators folder
to edit the configuration.
_________________
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. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 03, 2007 11:00 am Post subject: |
|
I
suppose you could always let the user create a .config folder/an empty
bsnes.cfg file in bsnes' folder, and have bsnes use that if it exists.
Like FitzRoy said though, I doubt anyone will want that in addition to
the settings editor you built into bsnes once joystick polling is in
place. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Jun 03, 2007 1:10 pm Post subject: |
|
I can't get it to compile under Linux (Arch Linux, 64-bit version) and I have no idea why it dies:
Code: |
$ make PLATFORM=x-gcc-lui-x64
g++ -O3 -fomit-frame-pointer -ffast-math -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86_64 -DUI_LUI `pkg-config --cflags gtk+-2.0` -c
ui/main.cpp -o main.o
ui/lui/ui_main.cpp: In member function 'virtual int MainWindow::message(uint, void*)':
ui/lui/ui_main.cpp:13: error: cast from 'void*' to 'int' loses precision
ui/lui/ui_main.cpp:18: error: cast from 'void*' to 'int' loses precision
ui/lui/settings/ui_inputconfig.cpp: In member function 'virtual int InputCaptureWindow::message(uint, void*)':
ui/lui/settings/ui_inputconfig.cpp:165: error: cast from 'void*' to 'uint' loses precision
make: *** [main.o] Error 1 |
gcc:
Code: |
$ gcc --version
gcc (GCC) 4.1.2 20070430 (prerelease)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
Trying to compile the 32-bit version under 32-bit chroot also fails:
Code: |
$ sh cc.sh
g++ -O3 -fomit-frame-pointer -ffast-math -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86 -DUI_LUI `pkg-config --cflags gtk+-2.0` -c ui/main.cpp
-o main.o
In file included from ui/lui/../video/xv.cpp:1,
from ui/lui/ui.cpp:20,
from ui/lui/main.cpp:16,
from ui/main.cpp:30:
ui/lui/../video/xv.h:6:31: error: X11/extensions/Xv.h: No such file or directory
ui/lui/../video/xv.h:7:34: error: X11/extensions/Xvlib.h: No such file or directory
In file included from ui/lui/../audio/ao.cpp:1,
from ui/lui/ui.cpp:22,
from ui/lui/main.cpp:16,
from ui/main.cpp:30:
ui/lui/../audio/ao.h:1:19: error: ao/ao.h: No such file or directory
ui/lui/../video/xv.h:10: error: expected constructor, destructor, or type conversion before '*' token
ui/lui/../video/xv.h:16: error: ISO C++ forbids declaration of 'XvImage' with no type
ui/lui/../video/xv.h:16: error: expected ';' before '*' token
ui/lui/../video/xv.cpp: In member function 'virtual void VideoXv::refresh(uint, uint)':
ui/lui/../video/xv.cpp:20: error: 'xvimage' was not declared in this scope
ui/lui/../video/xv.cpp:39: error: 'XvShmPutImage' was not declared in this scope
ui/lui/../video/xv.cpp: In constructor 'VideoXv::VideoXv(long unsigned int)':
ui/lui/../video/xv.cpp:99: error: 'XvAdaptorInfo' was not declared in this scope
ui/lui/../video/xv.cpp:99: error: 'adaptor_info' was not declared in this scope
ui/lui/../video/xv.cpp:101: error: 'XvQueryAdaptors' was not declared in this scope
ui/lui/../video/xv.cpp:104: error: 'XvInputMask' was not declared in this scope
ui/lui/../video/xv.cpp:104: error: 'XvImageMask' was not declared in this scope
ui/lui/../video/xv.cpp:109: error: 'XvFreeAdaptorInfo' was not declared in this scope
ui/lui/../video/xv.cpp:114: error: 'xvimage' was not declared in this scope
ui/lui/../video/xv.cpp:114: error: 'XvShmCreateImage' was not declared in this scope
ui/lui/../audio/ao.h: At global scope:
ui/lui/../audio/ao.h:8: error: 'ao_sample_format' does not name a type
ui/lui/../audio/ao.h:9: error: ISO C++ forbids declaration of 'ao_device' with no type
ui/lui/../audio/ao.h:9: error: expected ';' before '*' token
ui/lui/../audio/ao.cpp: In member function 'virtual void AudioAO::sample(uint16, uint16)':
ui/lui/../audio/ao.cpp:7: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp:7: error: 'ao_play' was not declared in this scope
ui/lui/../audio/ao.cpp: In member function 'virtual void AudioAO::update_frequency()':
ui/lui/../audio/ao.cpp:12: error: 'driver_format' was not declared in this scope
ui/lui/../audio/ao.cpp:13: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp: In member function 'virtual void AudioAO::init()':
ui/lui/../audio/ao.cpp:20: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp:20: error: 'driver_format' was not declared in this scope
ui/lui/../audio/ao.cpp:20: error: 'ao_open_live' was not declared in this scope
ui/lui/../audio/ao.cpp:22: error: 'ao_info' was not declared in this scope
ui/lui/../audio/ao.cpp:22: error: 'di' was not declared in this scope
ui/lui/../audio/ao.cpp:22: error: 'ao_driver_info' was not declared in this scope
ui/lui/../audio/ao.cpp: In member function 'virtual void AudioAO::term()':
ui/lui/../audio/ao.cpp:29: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp:30: error: 'ao_close' was not declared in this scope
ui/lui/../audio/ao.cpp: In constructor 'AudioAO::AudioAO(const char*)':
ui/lui/../audio/ao.cpp:37: error: 'ao_initialize' was not declared in this scope
ui/lui/../audio/ao.cpp:40: error: 'ao_driver_id' was not declared in this scope
ui/lui/../audio/ao.cpp:40: error: 'ao_default_driver_id' was not declared in this scope
ui/lui/../audio/ao.cpp:42: error: 'driver_format' was not declared in this scope
ui/lui/../audio/ao.cpp:45: error: 'AO_FMT_LITTLE' was not declared in this scope
ui/lui/../audio/ao.cpp:46: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp: In destructor 'AudioAO::~AudioAO()':
ui/lui/../audio/ao.cpp:50: error: 'audio_device' was not declared in this scope
ui/lui/../audio/ao.cpp:51: error: 'ao_close' was not declared in this scope
ui/lui/../audio/ao.cpp:54: error: 'ao_shutdown' was not declared in this scope
make: *** [main.o] Error 1 |
Also, shouldn't the license come with the source code package too?
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sun Jun 03, 2007 2:11 pm Post subject: |
|
You
are missing some headers in 32bit chroot case, namely Xv.h, Xvlib.h and
ao.h. Install appropriate devel packages into that chroot and
compilation should go further. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Sun Jun 03, 2007 7:43 pm Post subject: |
|
I'd say this has shaped up to be a very good release! Thanks for the hard work. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jun 03, 2007 10:14 pm Post subject: |
|
Quote: |
I can't get it to compile under Linux (Arch Linux, 64-bit version) and I have no idea why it dies: |
Damn. I don't have a 64-bit OS to test on anymore, so this last minute change ended up breaking things :(
Maybe I'll just silently update the source.
Unfortunately, I'm not sure how to fix this issue. Yes, void* to int
loses precision on 64-bit platforms, but that isn't a problem. To be
honest, GCC *really* should consider this a warning and not an error.
Input::signal_key_N() takes uint16 as a parameter, so the loss of
additional bits does not matter.
Maybe try changing the lines to:
Code: |
if(uiInput) { uiInput->signal_key_down(static_cast<uint16>(param)); } |
Code: |
if(uiInput) { uiInput->signal_key_up(static_cast<uint16>(param)); } |
Code: |
window_input_config.set_value(index, static_cast<uint16>(param)); |
?
Quote: |
Trying to compile the 32-bit version under 32-bit chroot also fails: |
I don't know what OS/distro you are using, but if it's Ubuntu or similar, try:
sudo apt-get install build-essential libxv-dev libao-dev libgtk2.0-dev nasm yasm
And then try building again. Very interested to see if you get it
working. If you want I can give you my IM/IRC contact info and we can
work on getting these issues resolved and I can get a new source
package put up.
Quote: |
is it possible to generate a shortcut to the config file when you run bsnes? |
Yes. Use "create a new shortcut" and choose the config file in your home directory/.bsnes/bsnes.cfg
Quote: |
Hmmm, another DIY project? |
I don't own a PS3, nor do I ever intend to spend $600 on a video game console :/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 03, 2007 11:38 pm Post subject: |
|
byuu wrote: |
I don't own a PS3, nor do I ever intend to spend $600 on a video game console :/ |
Oh, I wasn't aware that it required you to have one.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jun 03, 2007 11:59 pm Post subject: |
|
well, where else do you plan on getting a cell processor 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 04, 2007 1:45 am Post subject: |
|
Panzer88 wrote: |
well, where else do you plan on getting a cell processor  |
Documentation on the cell? Someone that does have one and can run test code?
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Jun 04, 2007 2:31 am Post subject: |
|
doing
something like that, while totally possible, is generally a lot less
cumbersome when you have direct access to test it yourself.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 04, 2007 4:51 am Post subject: |
|
Well,
hopefully some coder with a PS3 realizes the potential for bsnes in
this application and does port it. I guess there's little else to say.
If I had a PS3, I would just lend it to byuu, but I don't. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 04, 2007 6:33 am Post subject: |
|
I could not find a way to safely cast from void* to uint16, so I had to use a dirty trick.
Code: |
void *param = 1;
uint16 t = uint64(param); |
This works by casting param to the highest integral size possible, so
GCC won't bitch about loss of precision (which I don't believe is a
violation of the C++ language, anyway), and then casts again to the
desired bitcount. It should work on both Windows and Linux, and on both
32-bit and 64-bit architectures. We'll worry about 128-bit
architectures when I have a port of libco to one.
I'm sure I'll take a lot of grief for this, but I can't find another
way of doing this without completely destroying the message system I am
using, which I really, really like.
I have updated the source code archive on my site with this fix and the
missing license.txt file, it is now also stored in bz2 format. Please
let me know if this fix works or not.
Quote: |
Well,
hopefully some coder with a PS3 realizes the potential for bsnes in
this application and does port it. I guess there's little else to say.
If I had a PS3, I would just lend it to byuu, but I don't. |
Not sure I'd even want to accept one, even as a loan. What if I damaged
it? Not worth the liability. co_switch is the only function that cannot
be written in pure C, and that only needs 3-12 instructions. It should
be trivial to port, you need only swap the stack pointer after saving
and restoring all non-volatile registers.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Jun 04, 2007 10:34 am Post subject: |
|
byuu's licensing article wrote: |
And
despite the fact that only one person has ever asked me to use my code,
I have been publically insulted and attacked by no less than five
people directly, and quite likely many more that I am unaware of, for
choosing the license I have for bsnes. |
I hope you do not number me among those five - if you do, I apologise.
I never intended to attack you, I just wanted to help correct what I
thought were misunderstandings on your part. Although I haven't read
your entire article in detail, I have read most of it, and I can see
you've put a lot of effort into it. In the end you didn't choose the
way I would have, but then I don't have the tenacity or drive to create
something as intricate and accurate as bsnes.
byuu wrote: |
I could not find a way to safely cast from void* to uint16, so I had to use a dirty trick.
Code: |
void *param = 1;
uint16 t = uint64(param); |
|
Without downloading the code, unpacking it and looking for the lines
you're talking about, I'm guessing the message-passing system to which
you refer is using a void* parameter as a miscellaneous hold-all to
pass around integers of various sizes as well as pointers. Have you
considered changing the type of that miscellaneous parameter to a union
of all the various types you pass around? It shouldn't take up any more
memory than a void* does anyway, it explicitly documents the
polymorphic approach you're using, and it ought to make the compiler
shut up about type warnings - all for the cost of a few extra
characters when sending and receiving messages.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 04, 2007 2:40 pm Post subject: |
|
Thristian wrote: |
I hope you do not number me among those five |
No, absolutely not. I apologize for giving you that impression. I
didn't want to name names in the article (though I unfortunately did
with lack of judgment mention one elsewhere in the past -- plus I
forgot half of them, I usually find this kind of stuff on random
message boards in my referral logs). Trust me, I reserved the term
'attacked' for people who were extremely rude about the issue. You were
very polite and helpful with the links you provided. The people in
question should have no doubt about who they are, nor care about what I
think anyway, so ...
Quote: |
Without
downloading the code, unpacking it and looking for the lines you're
talking about, I'm guessing the message-passing system to which you
refer is using a void* parameter as a miscellaneous hold-all to pass
around integers of various sizes as well as pointers. Have you
considered changing the type of that miscellaneous parameter to a union
of all the various types you pass around? |
EDIT: look at that, standards to the rescue:
stdint.h wrote: |
Integer types capable of holding object pointers
The following type designates a signed integer type with the property
that any valid pointer to void can be converted to this type, then
converted back to a pointer to void, and the result will compare equal
to the original pointer: intptr_t
The following type designates an unsigned integer type with the
property that any valid pointer to void can be converted to this type,
then converted back to a pointer to void, and the result will compare
equal to the original pointer: uintptr_t |
Works great, I can just take uintptr_t as the message function
argument, and then cast that to a pointer when necessary.
Thank you, #c++, for attempting to convince me that the above was
absolutely impossible, and that I should either implement callbacks for
every single event (~600 events thus far in bsnes' new UI), or use a
more complex to work with Event struct to hold all kinds of different
types of values.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jun 04, 2007 4:06 pm Post subject: |
|
Heh, glad you found a proper solution, I was about to suggest assignment operator overloading a union for all its types. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 04, 2007 4:36 pm Post subject: |
|
Quote: |
Heh, glad you found a proper solution, I was about to suggest assignment operator overloading a union for all its types. |
Hah, I actually posted exactly that as a possible workaround, but
removed it in the edit. The problem wasn't with the assignment (I could
template the input parameter and then assign to all types in the union
individually), but with the retrieval. An explicit cast would be
necessary every time I wanted to read the value from such a struct,
otherwise the cast would be ambiguous.
uintptr_t kind of requires a cast as well in many cases, but not for
what I want to use it for. Keycodes can be passed directly, and I have
to cast from void* to Control* anyway when I want to use the pointer.
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Mon Jun 04, 2007 5:10 pm Post subject: |
|
The
updated sources compiled fine, but a new error emerged. Everything in
the GUI works so far, but when I select Load Cartridge option, bsnes
segfaults. No dialogs pop up, bsnes crashes immediately. From past
experience I judge that this error might have something to do with
paths, but I'm not a programmer. Bsnes is unusable, I can't play
anything. I tried changing CFLAGS, but it wasn't a solution. My setup
is 64-bit Gentoo with GCC 4.1.2 and yasm 0.6.0.
Suggestion: command line parameter for defining the rom to be played. That might help in these kind of situations.
Also warning for Gentoo users: Yasm version 0.4.0 (stable branch) won't
accept format elf64. By unmasking the yasm package with ~amd64 keyword
and installing Yasm 0.6.0 you can continue compiling.
EDIT: I got it working, it has nothing to do with my setup. I had set
the default rom search path to end with a slash. By removing the slash
character it started working. Bsnes also segfaulted when the default
rom search path was defined as "".
Last edited by Turambar on Mon Jun 04, 2007 5:17 pm; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jun 04, 2007 5:12 pm Post subject: |
|
byuu wrote: |
Quote: |
Heh, glad you found a proper solution, I was about to suggest assignment operator overloading a union for all its types. |
Hah, I actually posted exactly that as a possible workaround, but
removed it in the edit. The problem wasn't with the assignment (I could
template the input parameter and then assign to all types in the union
individually), but with the retrieval. An explicit cast would be
necessary every time I wanted to read the value from such a struct,
otherwise the cast would be ambiguous.
uintptr_t kind of requires a cast as well in many cases, but not for
what I want to use it for. Keycodes can be passed directly, and I have
to cast from void* to Control* anyway when I want to use the pointer.
|
Ah, good point. Wonder if there's a good solution for the retrieval issue..
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 04, 2007 5:19 pm Post subject: |
|
Quote: |
The
updated sources compiled fine, but a new error emerged. Everything in
the GUI works so far, but when I select Load Cartridge option, bsnes
segfaults. |
Please see:
http://board.zsnes.com/phpBB2/viewtopic.php?t=10192
Discussion will continue at the above thread for this issue. I believe I have a fix posted there now.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Jun 04, 2007 6:46 pm Post subject: |
|
byuu wrote: |
I
have updated the source code archive on my site with this fix and the
missing license.txt file, it is now also stored in bz2 format. Please
let me know if this fix works or not. |
Compiles fine now, though however it segfaults when I select "File
-> Load cartridge". Hrm.. it seems to hang randomly even before the
menu is drawn, or draw the menu and not respond at all.
Okay, I just found the reason why it stops responding, seems to have
something to do with audio (looking up the device perhaps?). I had
Sonata (MPD client) playing during the first try, simply letting it
play music again makes bsnes start, though it still segfaults when
trying to load any game.
I have ALSA compiled in the kernel with OSS API support (hence I can
use both). I'm not the best with gdb and such, but I did a bt and I'll
mail you the result.
Installed the missing deps in 32-bit chroot and it built fine, as well as work as it should.
EDIT: I see you already got the info in the other thread, posting there instead.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 04, 2007 6:58 pm Post subject: |
|
Here's a neat trick, you can go to advanced, and set "syste.audio_flags" to the name of a libao driver, examples:
"alsa" (default, same as ""), "oss", etc.
There's more, I'm sure. I'd use "oss" with the opensound.com drivers if
you can. Otherwise, "alsa" should work, but tends to have a rather
large latency. Not much I can do about it, the API is -extremely-
sparse. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 05, 2007 6:19 am Post subject: |
|
Alright,
I've posted a source update that fixes file->load and adds back
command-line support. If you've already fixed it manually, there's no
reason to download the update (unless you want to be nice and test it).
For those that weren't able to compile it thus far, this version should
work.
Oh, and the main window now clears when you
close a ROM. It also removes the frame counter text from the titlebar.
It won't work on Linux though, as I haven't implemented clear_video()
in the Xv and GTK+ drivers yet. |
|
beender New Member
Joined: 03 Nov 2006
Posts: 4
|
Posted: Tue Jun 05, 2007 6:51 am Post subject: |
|
i
think there is a bug in the dsp1 code. when watching the pilotwings
intro, if you let it repeat 3 times until the plane sequence, the plane
crashes when trying to land. on a real snes, the plane lands everytime.
i know this also happens on zsnes and people are aware of it, but i
thought you had fixed your code on the dsp chip to be accurate with all
the new research.
File: Pilotwings (U).zip Header: Yes
PILOTWINGS TYPE:DSP-1
INTERLEAVED:No CHKSUM:OK
VIDEO:NTSC BANK:Lo CRC32:266C44ED |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 05, 2007 7:12 am Post subject: |
|
It
is a timing issue. The DSP-1 emulation bit input to output is perfect
-- everyone involved (Andreas Naive, Overload, The Dumper, neviksti,
...) did a fantastic job perfecting the emulation itself. The problem
is that we do not emulate DSP-1 timing. So really complex operations
that are supposed to take a long time to complete, actually complete
instantly in emulation. It throws off the timing, and things like that
and the SMK line appear.
The solution is to run
the DSP-1 as a processor and not as a glorified RAM device. Nobody
seems interested in emulating this, and I don't have the time. Too busy
emulating the main SNES, as its' accuracy affects a lot more games than
DSP-1 emulation does :(
I've only added emulation of special chips as a courtesy to people who
use bsnes, but I've never made any claims that such emulation is
accurate to any degree whatsoever. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jun 05, 2007 7:13 am Post subject: |
|
From page 68 in this thread.
Overload wrote: |
FirebrandX wrote: |
Hey
byuu, I'll give you a US game to look into. Its Pilotwings, and I've
noticed an interesting glitch with every emulator I've tried. If you
the game play through its various demos, when it gets to the bi-plane
landing sequence, the plane will crash short of the runway. On the
actual console, the plane lands perfectly. I'm guessing its a timing
issue with how the input commands are processed on a real console
versus an emulator. |
http://users.tpg.com.au/advlink/dsp/dsp1.html#OP28
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 05, 2007 7:43 am Post subject: |
|
Well, I #define DSP1_VERSION 0x0102, so ... |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Tue Jun 05, 2007 8:32 am Post subject: |
|
So
I updated my system today and noticed that gcc was updated to 4.2.0,
which in turns won't compile bsnes, it outputs a lot of warnings about
deprecated stuff and ends up dying at while compiling cart.o. I think
the list is too long to post here though, or at least in this thread, I
could open a new one and post it there, or mail it too you. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jun 05, 2007 8:42 am Post subject: |
|
byuu wrote: |
Well, I #define DSP1_VERSION 0x0102, so ... |
We posted at the same time. I was just doing a search of the issue
because I remembered it being addressed before. I guess it backfired,
though, because it seems you are saying that Overload's notes are
incorrect because he believed the bug to be from earlier versions of
the dsp1 only?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 05, 2007 4:31 pm Post subject: |
|
[vEX] wrote: |
So
I updated my system today and noticed that gcc was updated to 4.2.0,
which in turns won't compile bsnes, it outputs a lot of warnings about
deprecated stuff and ends up dying at while compiling cart.o. I think
the list is too long to post here though, or at least in this thread, I
could open a new one and post it there, or mail it too you. |
I swear, it better not
be complaining that functions like strcpy are deprecated, or I will
start writing my own version of libc. You do not deprecate a 20-year
standard because some idiots don't know how to use it properly.
Send the log file however you prefer, I don't mind. If it's something
easy, I'll fix it. But I'm not too concerned with the issue. GCC is the
one that likes to break everyone's apps with every new version of their
compiler, my code works just fine as can be seen by the thousands of
people who hold compiled binaries of it right now.
Quote: |
it
seems you are saying that Overload's notes are incorrect because he
believed the bug to be from earlier versions of the dsp1 only? |
I'm not saying that, Overload knows a lot more than I do about the
DSP-1. I'm just saying I don't have the time to research the issue
further. Until someone besides me starts caring about actually timing
these special chips, it won't happen. I'm going to be far too busy with
the S-PPU to worry about special chips.
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Jun 05, 2007 8:42 pm Post subject: |
|
After some brief testing I found these problems:
Pass a directory name as a command line parameter and bsnes tries to
play it. With certain directories bsnes segfaults, but sometimes it
shows plain black screen. In addition FPS oscillates strangely. You
might have thought of this, I haven't looked into the latest sources,
I'm using the previous sources with the patches from the other thread.
I didn't get JMA working. I only tried a few roms. This is probably Nach's area, but it should be fixed anyway.
The last and the worst. On my system bsnes utilizes multithreading
poorly. Bsnes is using only single core, and the second core stays
idle. Bsnes can't keep up with 60 FPS with just a single core. My
processor is AMD Athlon X2 5200+ |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Jun 05, 2007 9:00 pm Post subject: |
|
bsnes doesn't support parallel threads of execution. (yet)
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Jun 05, 2007 9:03 pm Post subject: |
|
Turambar wrote: |
I didn't get JMA working. I only tried a few roms. This is probably Nach's area, but it should be fixed anyway. |
My guess is that you are using an older version of the JMA format. Use
the latest version of NSRT and convert with it for reliable results.
Quote: |
The
last and the worst. On my system bsnes utilizes multithreading poorly.
Bsnes is using only single core, and the second core stays idle. Bsnes
can't keep up with 60 FPS with just a single core. My processor is AMD
Athlon X2 5200+ |
There's nothing to thread in BSNES (I could be wrong, but it wouldn't
be significant). All cores must be synced up aka dependencies, and that
prevents any sort of parallelism for a second core.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jun 05, 2007 9:14 pm Post subject: |
|
A
5200+ is pretty fast and I wouldn't have expected a e6300 to perform
over it. The other day, I was wondering if it would be a good idea to
create a test WIP using the old IRQ strategy with the new WAI and other
accuracy improvements. I dunno, it might be worth testing out to see if
those old bugs still persist. 40% would be a heck of a boost at no
compatibility hit. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 05, 2007 10:39 pm Post subject: |
|
Quote: |
Pass a directory name as a command line parameter and bsnes tries to play it. |
Silly. I'll add an fexists() check around the file loading routine when possible.
Quote: |
I didn't get JMA working. I only tried a few roms. |
Sorry, you need to specify you want it on the make line, try:
Code: |
make PLATFORM=x-gcc-lui-x64 GZIP_SUPPORT=true JMA_SUPPORT=true |
I leave them off by default because it doubles my compile time (I
perform clean builds 95% of the time due to the way I designed bsnes),
and I honestly don't even use it. I always enable both in my binary
release builds.
Quote: |
The
last and the worst. On my system bsnes utilizes multithreading poorly.
Bsnes is using only single core, and the second core stays idle. Bsnes
can't keep up with 60 FPS with just a single core. My processor is AMD
Athlon X2 5200+ |
It would be a very long article (that I plan to write eventually), but
essentially I cannot take advantage of multicore processors for
emulation. The executive summary is that a wait lock between two
processors is extremely expensive. At most, I could have the two cores
sync up maybe ~50,000 times a second (no exaggeration, try it), whereas
in emulation, the S-CPU and S-SMP need to sync up far more frequently,
I would estimate around ~500,000 times a second. So you see, 90% of CPU
time would be spent waiting for one CPU to say it's synced with the
other.
I'm really hoping that compilers can adapt to take advantage of
multicores automatically, and split up processes like video filtering
and such without requiring the programmer to resort to tricky
semaphores and mutexes. Sure, it won't reach 100% on both cores, but a
20% speed boost would be nothing to shake off.
For the record, I know of no SNES emulators that take advantage of
multicore, other than maybe offloading video filters.
And I'm sorry you can't reach 60fps on a 5200+ ... that's quite
distressing. I was getting 70-80fps with my 3500+ before the IRQ
rewrite. You can try building with the GCC flag -fprofile-generate, run
bsnes with a few games, and then compile again with -fprofile-use. This
will give you a ~15% speedup, which should keep you above 60fps.
For the record, I am getting 90fps with CT's Black Omen (the most
intense screen I know of), and 110fps with Zelda 3 (rather simplistic
game), at the moment. This is with an e6600 @ stock.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Jun 06, 2007 3:17 am Post subject: |
|
[quote="byuu"]
Quote: |
For
the record, I am getting 90fps with CT's Black Omen (the most intense
screen I know of), and 110fps with Zelda 3 (rather simplistic game), at
the moment. This is with an e6600 @ stock. |
good to know once i get my motherboard sorted so i can update the BIOS, im gonna move to a e6600 my self.
on my p4 3.00ghz HT processor i get slight skipping here and there, but
its only slight. (enough to piss me off tho)
_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 06, 2007 4:53 am Post subject: |
|
I
have a new bug to report. It very likely has something to do with
blargg's new core or his bsnes optimization of it. I don't really know
which as I don't have the WIPs to test with anymore to find out when it
was introduced.
King of Dragons (E, J, U) has some
missing audio. It almost seems like one or more of the channels aren't
playing. Sound effects are missing, too. It's safe to say that more
games are probably affected by this, but I know of only this one so far. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 06, 2007 3:20 pm Post subject: |
|
I
just tested The King of Dragons in bsnes 0.019, bsnes 0.019 wip 40 and
0.020. Sound is broken only in 0.020, so it looks like the
bsnes-optimised version of blargg's core is at fault here. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Jun 06, 2007 4:21 pm Post subject: |
|
Byuu, i saw the NTSC test thread on nesdev.
http://nesdev.parodius.com/bbs/viewtopic.php?p=24724#24724
As you know i have a pal snes with a pal tv, so if you finish that test
program i can try it and make pictures/measure it, i can also output
pal signals trhough my pc to my tv, so i can also test to see if bsnes
outputs the correct info to my pc when played back on a tv.
If there is any other info you need i can try to get it for you! also
if you need a pal snes and TV i can probably hook you up with some
cheap sellers (but transport costs would be pretty steep for a tv)
You could probably buy a snes and a tv for about 50-100 euro's and then have that shipped to your place. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 06, 2007 4:48 pm Post subject: |
|
Quote: |
I
just tested The King of Dragons in bsnes 0.019, bsnes 0.019 wip 40 and
0.020. Sound is broken only in 0.020, so it looks like the
bsnes-optimised version of blargg's core is at fault here. |
Alright, I'll switch back to the LGPL version for the time being, it's
probably something to do with the arithmetic shift right stuff ... most
likely my fault. I'll wait and see if blargg can find anything first,
as I'm terrible with these sound issues ...
For reference, I am currently using:
Code: |
template<int bits> inline signed sclip(const signed x) {
enum { b = 1U << (bits - 1), m = (1U << bits) - 1 };
return ((x & m) ^ b) - b;
} |
Code: |
template<int n, typename T> inline T asr(const T x) {
enum { bits = (sizeof(T) << 3) - n };
return sclip<bits>(x >> n);
} |
Haven't added the optimization for systems that natively support
arithmetic shift right yet, in fact hoping to avoid an issue just like
this. So much for that ...
And for reference, here is the optimized version with blargg's tricks, but it is not used in v0.020:
Code: |
inline signed asr(const unsigned bits, const signed data) {
if((-1 >> 1) == -1) { return data >> bits; }
unsigned mask = (-1U >> bits) + 1 };
return ((data >> bits) ^ mask) - mask;
} |
Still a little concerned about making bits a parameter, though ...
Quote: |
As you know i have a pal snes with a pal tv |
Ah, alright. I'll try and copy/paste tepples' screenshot into an SNES
ROM and send it to you. If you could tape measure it as closely as
possible (mm preferred, but cm shold be fine) in both width and height,
I should be able to match your TV. Thanks for the offer.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 06, 2007 8:42 pm Post subject: |
|
I
also have a PAL TV + SNES, but no copier.. but I was wondering. Would
using my graphics card's TV out, running at the SNES' resolution
(although I'm not sure I can do that with TV out, obviously the TV can
display it) work for this test? |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 06, 2007 8:50 pm Post subject: |
|
About
the only thing that could be done that would help which you could do
would be a really hi-res digital picture of a PAL TV screen with a very
common game running. I need at least 1600x1200, say in Zelda 3. I can
measure out something onscreen and do some math to duplicate the skew
of that image. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 06, 2007 8:59 pm Post subject: |
|
Hmm,
I should be able to get you a good picture, (5 Mpix or 10 interpolated)
but unfortunately I don't have that many games.. would Donkey Kong
Country (1 or 2), or Secret of Mana do? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 06, 2007 9:43 pm Post subject: |
|
Secret
of Mana @ 5MP is fine, please capture the title screen. Also, please
align the image as straight as you possibly can. I do not have
Photoshop to perform freeform rotation, so any angle will ruin my
ability to get a valid ratio.
This one:

Obviously with the PAL version of the game (though they're probably the
same anyway). I will then compare the aspect ratio of width:height of
the logo to width:height of your screenshot to get the ratio I need. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 06, 2007 10:02 pm Post subject: |
|
Alright;
I'll definitely use a tripod. Just by looking at that picture though, I
think the aspect ratio is slightly different. Could just be me, but
we'll see soon enough 
Edit: byuu, you have a PM  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 06, 2007 11:55 pm Post subject: |
|
Thank you, I have measured the 256x224 title screen block to be:
127x43
I have measured your (very) high resolution screenshot to be:
1140x272
Results:
Code: |
127x 43 = 2.953488
1140x272 = 4.191176
43x4.191176 = 180.220568
180.220568 / 127 = 1.419060 |
So the aspect skew I want is ~1.419060. tepples stated he believed the aspect to be 48 / 35, or ~1.371429.
Note that NTSC is 8 / 7, or ~1.142857, so there's quite a large difference here ... PAL is much, much wider.
Feel free to confer.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 12:17 am Post subject: |
|
Well if you're interested, here's how it looks ingame:
http://rapidshare.com/files/35669273/SANY0070.JPG.html
(rather good for a picture taken without a tripod *smug* The RGB 'grid'
is very obvious on this one, dunno why; IRL, the lines are about as
noticeable as the horizontal spacing between the pixels, which aren't
visible in my pictures)
Edit: I can't remember if the 'widescreen' effect visible in this
picture is present in all games. However, it is in Donkey Kong Country
(just tried). Is this the effect of the skewing? |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Jun 07, 2007 1:08 am Post subject: |
|
1.419/1.143
= 1.241, so the same image on a PAL SNES appears 24% wider than on an
NTSC SNES. Byuu's above calculation shows that a SNES PAL pixel is
1.419 units wide by 1 unit tall, while a SNES NTSC pixel is 1.143 units
wide by 1 unit tall. This only applies to the SNES, as other video game
systems generate a video signal with a different pixel rectangularity;
referring to PAL's inherent pixel size is just plain wrong, since there
is no such thing as a pixel inside the TV, only in the video encoder
inside whatever is generating the signal (and you could have a video
encoder that itself had no concept of a pixel, like the old vacuum-tube
style video cameras). |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 1:36 am Post subject: |
|
Hmm,
I see, thanks for explaining. I wonder why the PAL SNES does this.. I
mean, you're having to produce a PAL signal anyway, why not draw it to
the whole screen? Did a lot of TVs produced back then have a weird
aspect ratio? (so that it produces the black bars on my TV. Which have
never irritated me, but still) |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Thu Jun 07, 2007 1:53 am Post subject: |
|
Since
a normal PAL tv is 4:3 afaik, you should be able to roughly calculate
the ratio from the number of added black lines compared to NTSC. I
suppose that's what tepples' approximation is based on.
Anyway, I just grabbed bsnes v0.020.01 which seems to work pretty well at first glance 
Games (the ones I tested yet anyway) seem to be quite playable on frameskip 1 on my old p4 2.5GHz. Sweet!
Here's a tiny patch to ensure that the xv color key is painted by the x
server, so that bsnes doesn't turn up black after running apps like
mplayer that paint their own color key:
Code: |
--- bsnes_v020_01/src/ui/video/xv.cpp 2007-05-22 07:09:11.000000000 +0200
+++ bsnes_v020_01_2/src/ui/video/xv.cpp 2007-06-07 04:01:42.000000000 +0200
@@ -109,6 +109,11 @@
XvFreeAdaptorInfo(adaptor_info);
if(xv_port == -1) { printf("VideoXv: failed to find valid XvPort.\n"); }
+ {
+ const Atom atom = XInternAtom(display, "XV_AUTOPAINT_COLORKEY", True);
+ if(atom != None) { XvSetPortAttribute(display, xv_port, atom, 1); }
+ }
+
//0x00000003 = 32-bit X8R8G8B8 [xRGB] (few drivers support this mode)
//0x32595559 = 16-bit Y8U8,Y8V8 [YUY2] (most drivers support this mode)
xvimage = XvShmCreateImage(display, xv_port, 0x32595559, 0, 1024, 1024, &shminfo); |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 2:35 am Post subject: |
|
Quote: |
referring to PAL's inherent pixel size is just plain wrong |
Yes, sorry. I actually meant to bring that point up, but I posted right
before I left so I didn't really go into detail.
Quote: |
I wonder why the PAL SNES does this.. |
It shows more vertical lines of resolution. However, it's not possible
to change the number of vertical scanlines on a TV. The image appears
wider because it is crushed more vertically to account for the extra
scanlines.
They probably could've mitigated the damage by drawing narrower pixel
widths, but who knows. Maybe there's a reason why they couldn't do that.
Quote: |
Since
a normal PAL tv is 4:3 afaik, you should be able to roughly calculate
the ratio from the number of added black lines compared to NTSC. |
Actually ... that throws off my numbers a lot. My math must be wrong somewhere ...
[wrong]
(256*4/3) / 224 = ~1.523810
256 / 239 = ~1.071130
[right]
256 / 224 = ~1.142857
(256*4/3) / 239 = ~1.428172
Not sure what's going on now ...
Quote: |
Here's
a tiny patch to ensure that the xv color key is painted by the x
server, so that bsnes doesn't turn up black after running apps like
mplayer that paint their own color key: |
Neat! So that's how you set XV_ATTR values. Thanks a million, I'll add
your patch now. Now I can also add one for XV_SYNC_TO_VBLANK for 'nv'
driver users (the only card I've ever seen that had this flag, and that
it actually worked on).
Now I just need to figure out why the video starts off mostly or
entirely black on the s3 and ati drivers, but appears normal once you
move the window ...
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Jun 07, 2007 2:57 am Post subject: |
|
im pretty certain old PAL tv's did not have the thick black bars on the top and bottom of the picture the snes outputs.
am i saying something that means nothing? ;\
_________________
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. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Thu Jun 07, 2007 3:31 am Post subject: |
|
byuu wrote: |
Quote: |
Since
a normal PAL tv is 4:3 afaik, you should be able to roughly calculate
the ratio from the number of added black lines compared to NTSC. |
Actually ... that throws off my numbers a lot. My math must be wrong somewhere ...
[wrong]
(256*4/3) / 224 = ~1.523810
256 / 239 = ~1.071130
[right]
256 / 224 = ~1.142857
(256*4/3) / 239 = ~1.428172
Not sure what's going on now ...
|
I don't know much about how the SNES outputs video, nor about PAL/NTSC.
I just figured that games made for NTSC would be vertically
letter-boxed on PAL, due to PAL having more lines that would now be
black.
So basically:
ntsc_w/ntsc_h = pal_w/pal_h
pal_w = (pal_h/ntsc_h) ntsc_w
ntsc_h = 480 (?)
pal_h = 576 (?)
pal_w = 1.2 ntsc_w
Please ignore this if it's not really relevant.
byuu wrote: |
Quote: |
Here's
a tiny patch to ensure that the xv color key is painted by the x
server, so that bsnes doesn't turn up black after running apps like
mplayer that paint their own color key: |
Neat! So that's how you set XV_ATTR values. Thanks a million, I'll add
your patch now. Now I can also add one for XV_SYNC_TO_VBLANK for 'nv'
driver users (the only card I've ever seen that had this flag, and that
it actually worked on).
Now I just need to figure out why the video starts off mostly or
entirely black on the s3 and ati drivers, but appears normal once you
move the window ...
|
Probably a problem with redrawing of the color key. You may have better luck drawing it manually.
You may also want to add an option to use full chroma resolution by
doubling the horizontal resolution, duplicating each pixel, since two
neighboring pixels share chroma data. Most nvidia cards also have an
(otherwise inferior) xv port supporting rgb data it seems (newer cards
may not have a real overlay at all actually). FWIW older nvidia cards
sync to vblank transparently if XV_DOUBLE_BUFFER is set.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 8:34 am Post subject: |
|
I measured it on my Philips 37cm flatscreen CRT.
The results of the Secret of Mana logo are:
Height : 33 MM
Width : 165 MM
the image is definitely stretched when compared to the emulator, Also
the NTSC version after a pal patch shows the exact same measurements, i
tested a Toy story NTSC and PAL and which don't need any patches and
they measure the same too.
so it doesn't seem to matter what region the game was originally made
for, when played on a pal snes the game will always be stretched the
same.
well if i borrow your calculations
127/ 43 = 2.953488
165/ 33 = 5
43x5 = 215
180.220568 / 127 = 1.6929134
EDIT:
Found an interesting link, maybe this will help in determening a more accurate difference
http://gavin.panicus.org/doc/PAL%20NTSC%20differences.txt
it would seem that pal snes takes an 262 field line signal then
displays that at 312(stretch) and then squashes it to 224 active lines.
theoretically this would explain why everything is squashed
I also tested several pal only and ntsc only games om my snes and in
bsnes, it seems that currently Bsnes is displaying both pal and NTSC
games the way they should have been ported in the first place! But in
comparison to real life the image is completely wrong. i Would like to
take this chance to request that you leave the wrong pal screen
settings as an option, could even be hidden in the cfg file.
Also what i found is that pal games seem to be alligned at the top
instead of having equal sized black bars on the top and bottom. one
example is Tintin in Tibet (E) (M4).sfc (this game is completely
centered on my tv, showing black bars all around it)
EDIT2:
Wouldn't i be easyer to resize a convrgance test image to pal and ntsc
size, and then put that image in a rom, make sure the image has 4
clearly marked mesuring points and then use the mesurements from that
test image
EDIT3:
With some googling i found several sources that tell me the Pixel Aspect Ratio of a pal tv = 128/117
Source:
http://www.vistavision.de/par_pal_video.html
http://www.doom9.be/capture/preface.html
http://forum.doom9.org/showthread.php?t=32604&page=2 << attached PDF is in german but contains a lot of info about pal tv displays
Last edited by tetsuo55 on Thu Jun 07, 2007 1:30 pm; edited 2 times in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 12:19 pm Post subject: |
|
Hmm,
I measured the aspect ratio on my Sony Trinitron to be 41.1/30.2 =
1.36092715, which is quite close to tepples' suggested ratio of 48/35.
I then measured how much of the screen SoM takes up vertically, and
it's 25.4 / 30.2 = 0.841059603; 0.841059603^-1 = 1.18897638 suggesting
an 18.9% difference between NTSC and PAL SNES.. unless some stuff is
being drawn offscreen.
Edit: assuming the 41.1cm measurement is correct and extrapolating to a
4:3 ratio gives 30.825/25.4 = 1.21358268, which is closer to the
earlier measured 24%, though not quite there. I should mention however
that this CRT isn't a flatscreen, so the measurements could be a little
inaccurate, but for a 24% difference the width would have to be 42cm
for a supposed 4/3 ratio, or bigger for the other one, and I don't
think I'm off by 0.9mm or more. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 12:31 pm Post subject: |
|
Posted a reply or it might become to confusing
what it all boils down to is this:
A pal tv displays 576 scanlines, and each one has a duration of 52 uS,
this results in a visable area(including overscan zone) of 703x576
the pixel aspect ratio for pal TV's is 54/59
thus: 1:109259259...
the NTSC image is placed in the middle of the 576 lines, and then
stretched over the 703 pixel width at a 1:109259259 ratio
The result would be 176 black lines above and below including overscan,
that sounds about right to me, seeing as the black bars are quite huge.
Edit: due to Verdauga Greeneyes's post
Actually a lot of the image is lost behind the scanline area
This looks very accurate to me, and this way we dont have to worry about tv differences
Last edited by tetsuo55 on Thu Jun 07, 2007 1:05 pm; edited 3 times in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 1:01 pm Post subject: |
|
Ah, alright then. I'll try to get some more (useful) info to back up yours.
Edit: alright, I made a close-up of the logo. It's 2183x544 pixels, for a ratio of 4.01286765.
Results:
Code: |
127x43 = 2.95348837
2183x544 = 4.01286765
43x4.01286765 = 172.553309
172.553309 / 127 = 1.35868747 |
Does this match your findings better, tetsuo, or worse than byuu's measurement?
The close-up: http://rapidshare.com/files/35756784/SANY0091.JPG.html
The selection: http://rapidshare.com/files/35757143/selection.jpg.html
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 1:57 pm Post subject: |
|
Okay this should be my last post
both pal and NTSC displays have a fixed number of visible pixels, and a fixed pixel aspect ratio.
they are:
Pal is 703x576
PAR = 54/59 = 1:109259259
NTSC is 711×486
PAR = 4320/4739 = 1.09699
any image sent to the tv will be vertically centered based on the
number of scanlines, after than the image will be horizontally centered
and stretched at with the PAR to the maximum pixel width
this results in a widescreen image, but this is okay because the image
gets cropped on the left and right side by the overscan and also a
little at the top to get the 4:3 aspect ratio back.
So i added 3 pictures, they are all the exact size as they would be
inside the tv, keep in mind however that when displayed on the tv,
quite a bit gets cropped of the left and right side (see simcity as an
example), The white parts is where nothing would be rendered, this
would either fall in the overscan area or simply be a black bar
the first is the BSNES version as shown on a 640x480 RGB monitor
The Second is how a pal TV would try to display the same image
The Third is how a NTSC TV would try to display the same image
And below, a pretty standard 5% overscan and masked screen crop, again white areas would appear as black on screen.
NTSC 680x450
PAL 680x550
PS. the NTSC aspect ratio is way off because the physical TV has
scanlines , i currently don't know how to accurately add these
scanlines to the test image to restore the correct aspect ratio of the
test image. but im guessing that 450 x 1/4th pixel scanlines would
restore the aspect ratio
EDIT: IMPORTANT, i just discovered that my data may be incomplete, the
data posted above is what a tv does with a data signal that is industry
standard. However the snes could be using slightly different timings, i
will have to double check that and see if and how it influences the
image size (it will only influence the width not the hight, hight is
correct). However is bsnes was set up correctly via tvout(that abides
industry standard 100%) to a tv the above images should match your TV
(although your overscan and cropping could differ greatly(up to 10%
difference))
@Verdauga Greeneyes: Your measurements are probably influenced by tv
age, overscan, convergance, cropping and timing differences. Also as
you can read above my calculation could be wrong with respect to finale
image width, and this could be why our data is so different. My guess
is the snes pulse line is slightly off causing an extra widening of the
pixels.(possibly an NTSC pulse on a pal tv). |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 3:24 pm Post subject: |
|
tetsuo55 wrote: |
@Verdauga
Greeneyes: Your measurements are probably influenced by tv age,
overscan, convergance, cropping and timing differences. Also as you can
read above my calculation could be wrong with respect to finale image
width, and this could be why our data is so different. My guess is the
snes pulse line is slightly off causing an extra widening of the
pixels.(possibly an NTSC pulse on a pal tv). |
Yeah, when I saw you were figuring all this technical data out I just
wanted to get something as accurate as possible from my TV for sake of
reference. Are there any TV-Out tests I could do to help with
comparison?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 3:35 pm Post subject: |
|
set
your tvout resolution to 256x224 @ 50hz and display that image of the
SoM logo on you screen, does it match my test image for pal tv's? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 3:35 pm Post subject: |
|
I
know there's a lot of variance all over the place, the problem is that
every kind of formula I use to calculate things gives me wildly
different results, when every one should give me the same aspect
correction ratios. I think the problem is that there are too many
different measurements involved and I keep doing something wrong. I
can't get one single formula that gives a good general estimate for
both NTSC and PAL. But if I can find that, I'll use that, and let users
adjust the width correction in the UI themselves, ala what blargg
suggested.
Here's what we know:
- Both PAL and NTSC are 4:3, width to height, on the end image
- PAL outputs 256x239 that fills this screen
- NTSC outputs 256x224 that fills this screen
- We don't care about overscan for this ... I'll add cropping features later
- I am assuming 1:1 pixels on the monitor, 1280x1024 CRT users can
figure out their own widths and use the sliders if they want to use
non-square pixels
- Monitor width:height is irrelevent, picture not intended to fill the screen
- Emulator output height will be 224 in NTSC, and 239 in PAL. This is
different from a TV where the height would be the same as the TV set.
This means PAL size will be both taller and wider.
- It's not that TV pixel size is 4:3, we know that the pixel width is
determined by the video chip. It's that the TV output window is 4:3 ... if UxV is 4x3 in the end, we have to compensate for this. But ... how?
So, given the above ... it seems the correct formula would be to assume
the height filled the entire screen, top to bottom.
Now, since the TV is 4:3 and the PC is 1:1, if we were to do this, we
would have some black area at the right. So we have to stretch the
width to fill this excess area, the end result should be a 4:3 window
size on the emulator window.
With 4x3, we'd have 4 dots to 3 dots, but on the 1:1 PC, it'd be 3 dots
to 3 dots. We can conver the PC resolution with height * 4 / 3 = 4.
So, we do the same for the height.
224 * 4 / 3 = 298.667
239 * 4 / 3 = 318.667
So far, so good.
298.667 / 224 = 1.333 = 4 / 3
318.667 / 239 = 1.333 = 4 / 3
So we want:
299x224 NTSC
319x239 PAL
So, to get the scale from the effective width and the original 1:1 width, we use E / 256.
298.667 / 256 = ~1.166668x NTSC
318.667 / 256 = ~1.244793x PAL
So where does 8 / 7 come from? 256 and 224 are divisible by 32, and
give you 8 to 7. I don't know why we have been using this number in the
past.
256 / 224 = 1.142857 NTSC
256 / 239 = 1.071130 PAL
So, this number can't be correct. In fact, I have no idea what it's
even trying to do ... if the TV was perfectly square, maybe then it
would be valid? |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 3:58 pm Post subject: |
|
Your calculation are actually pretty close to the resolutions of my test images, so we are on the right track.
The tv isn't 4:3 its actually a little wider, the mask crops the screen to 4:3
As you can seen in Verdauga Greeneyes's extreme closeup, each
individual pixel is 1 scanline high and 2 pixels wide, look at the
"comma' and the "TM" Also as you can see in that screenshot, pal tv's
simply have pixels, there should be 703x576 pixels(including the ones
behind the mask)
this means my theory is correct and the tv maps the scanlines 1:1 (at
least a pal tv does) I am convinced my hight calculations are 100%
correct for pal tv's, its just the width i'm not yet 100% sure about.
my theory is that NTSC shows each scanline on 2 separate lines, and
that the scanline space makes up for the lost hight to get 4:3 ratio
back, i could use an extreme closup shot of the SoM titlescreen to
prove-disprove that. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 4:24 pm Post subject: |
|
Well,
I hooked up my TV-Out to my TV, and tried setting the resolution to
256x224@50Hz with Powerstrip, but I get a garbled image (just a few
white stripes near the bottom right corner, rest of the screen is
black). Is there any way I can achieve this resolution, or am I out of
luck?
PS: when I measured my TV's screen size
before, I found it to be a little wider than 4:3 - possibly the same as
tepples' suggestion which was 48:35.. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 4:41 pm Post subject: |
|
again proving that exactly 4:3 is a myth.
We need to think about the path the image travels
1: 256x224(239) image is output from the ppu to the snes tv module.
2: the tv module turns that into a 224(239) signal with a scanpulse
time and length that should be the same as 256 pixels.
3: The tv receives the signal and maps that to its own grid
step 3 is where all hell breaks loose and the pixels get distorted, the
tv tries to map the signal as well as it can, but the end result will
be a distorted pixel in almost all cases.
the reason why your calculations seem to be off is that not all of the
factors are taken into account, i will do more research, but its
obvious that a pal tv behaves wildly different from an ntsc tv |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 4:41 pm Post subject: |
|
Quote: |
Your calculation are actually pretty close to the resolutions of my test images, so we are on the right track. |
Hopefully ...
I created a 640x480 image, and drew a perfect square at 200x200. I then resized to both 256x224 and 256x239.
The boxes were now:
256x224 = 80x94
256x239 = 80x100
Now, on the SNES, they never, ever redraw the graphics to scale with
the new height. So I need to crop the PAL square to be the same height
as the NTSC square.
94/100*80=75.2
So I started a new image at 256x224, and drew 80x94 and 75x94
rectangles. I also saved a 256x239 image, doing nothing but increasing
the height with no scaling applied. This simulates a real life
"example" of SNES graphics.
If I resize the 256x224 to 640x480, I get the NTSC square at 80x94
looking like a perfect square, and PAL looks crushed horizontally.
If I resize the 256x239 to 640x480, I get the NTSC square at 80x94
looking too wide, and the PAL one looks perfectly square.
So, the same exact image will definitely appear wider on PAL screens.
It's not really wider, it's only an optical illusion because the height
is crushed with PAL's extra 15 scanlines.
This matches our results thus far, it's just that the PAL correction
seems to be a lot less severe than 1.4x, it looks more like 1.24x.
Perhaps the difference was just due to the individual TV, overscan and
/ or screen curvature?
I'm going to implement my aspect correction as:
emulator_window_width = emulator_window_height * 4 / 3
... which should work for all 1:1 pixel monitors / video modes. Now, I
can either give the user the ability to compensate for the monitor's
pixel size, or for the stretch width. The former would be easier for
the user to calculate, the latter would give more fine control over the
process (eg "my TV stretches more than that ...").
This means that by default, the output will
be wider, but the height will be increased, too. My goal is to preserve
the vertical quality by not having to resample the image vertically by
a non-whole number.
Quote: |
again proving that exactly 4:3 is a myth. |
I realize this, but it's kind of like oscillators. We can either go by
specs or by real-world recorded examples. The latter will almost always
be flawed, because it is imprecise. We could only refine it by getting
tons of samples and creating an average of them all.
Last edited by byuu on Thu Jun 07, 2007 5:00 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 4:57 pm Post subject: |
|
1.4
vs 1.24 seems like a rather big difference.. This TV is still
functioning just fine so far as I can tell, so what could be causing it? |
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Jun 07, 2007 5:02 pm Post subject: |
|
I give up here. I had a long post of corrections, but I can't overcome the tide of misinformation. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Jun 07, 2007 5:05 pm Post subject: |
|
Aw, so no PAL filter? 
_________________
FF4 research never ends for me. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 5:48 pm Post subject: |
|
Can
anyone run NTSC Secret of Mana and get a really, really, really high
res screenshot of their TV on the same title screen as shown on the
previous page, please?
I want to get another "real world" average for NTSC, like we have for PAL.
I also really need an SPC of the King of Dragons song with the sound
problems, please. They're problems with the BGM, and not with the sound
effects, right? Need to be able to reproduce the problem without an
S-CPU emulator. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 6:28 pm Post subject: |
|
Will this set do? Sound effects are also missing, mind you.
And to blargg, I'm sorry if the terms we're using are incorrect, or if
our theories are technically unsound.. we're just trying to help
improve SNES emulation, and these (amateuristic, in my case) real world
examples do seem to help. On the other hand any corrections you give
would be appreciated.
Last edited by Verdauga Greeneyes on Thu Jun 07, 2007 6:51 pm; edited 1 time in total |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Jun 07, 2007 6:47 pm Post subject: |
|
blargg wrote: |
I give up here. I had a long post of corrections, but I can't overcome the tide of misinformation. |
I'm glad to finally see I'm not the only one who suffers from this problem.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 7:02 pm Post subject: |
|
Blargg, nach, I'm sorry if my information is partially or fully incorrect, im learning as a i go along here.
Instead of correcting the mistakes that i and maybe others have made in
previous posts could you tell me the correct data?
it would seem that the pal snes outputs 240 scanlines at 1.8mhz pulserate for 312 pixels wide?
is this correct? the universal standard seems to be 13.5mhz for both
ntsc and pal, for a full resolution image at least.
Edit:
Begin resolution 312*240
59/54: 340.89*240, mask adjust to 320x240 for 4:3 aspect ratio
That produces this image
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 8:22 pm Post subject: |
|
Which KoD track# has the problem?
Quote: |
I give up here. I had a long post of corrections, but I can't overcome the tide of misinformation. |
Quote: |
I'm glad to finally see I'm not the only one who suffers from this problem. |
Your input would be helpful, but if it's distressing you to do so, I
completely understand. We can continue on in our efforts to learn how
these things work for ourselves.
I've been on both sides of the fence, myself. I started off ROM hacking
knowing practically nothing about it, asking questions to anyone
listening. And yet at this point, everything I read on the matter just
annoys me at how little it appears other people research the issues
before asking questions. Indeed, it is lonely at the top of my mountain.
Whereas on the other hand, I'm quite bad at non-bitwise math and at
writing C++ code the way most people do, but I am working on it. I've
taken a lot of the info you all have given me seriously, even if I
complain a lot about it, and you can hopefully see that in my work as
it continues to evolve.
So I have sympathy on both sides here. I give you my apologies if my
own misguided information posted here has upset you, but I am taking
your advice seriously, and I thank you for the info you've given me
thus far.
Last edited by byuu on Thu Jun 07, 2007 8:32 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jun 07, 2007 8:26 pm Post subject: |
|
byuu wrote: |
Which KoD track has the problem? |
Title Screen: the high-pitched trumpets are missing.
Edit: it also sounds a bit flat compared to the spc in foobar2000, but
I can't say whether that's caused by anything besides the missing
trumpets.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 8:34 pm Post subject: |
|
Thanks, I'll try and track down the problem. Wish me luck :P |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jun 07, 2007 9:31 pm Post subject: |
|
Unless
someone else has more accurate data, or we create a testrom, with lines
boxes and overscan/cropping(slaps self for not being able to code)
i think we can safely say, that pal =
aspect ratio: 59/54
256x239
239 * 59/54 = 279.704
280x239
279.704 / 256 = 1.0925925...
The resulting image is an almost exact match to my tv
My tv has a visible area of 33.5x25cm much closer to 59/54 than 4/3 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 07, 2007 10:49 pm Post subject: |
|
1.09x ... on PAL?!
We have 1.4x on our measurements on actual hardware. Even my "if TVs were perfect" calculations show it as at least ~1.24x ... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 08, 2007 12:37 am Post subject: |
|
blargg
helped me track down the bug with the new S-DSP core. It was due to the
initial register settings: KOFF was being set to have some channels
disabled, but King of Dragons never wrote to KOFF, so the channels stayed off forever, heh.
The bug actually escaped wip40 because I was using an older version of
the emulator before the register initialization code was added.
This kind of reiterates why I was trying to get ZSNES to use anomie's
sound core (before blargg decided to tackle subsample timing, of
course). This bug would be, and possibly already is, in ZSNES as well.
But now that we're sharing the same core, we can fix it in both at the
same time. Less duplication of effort :)
No need to test extensively on this one, but if anyone else spots a bug
like this in another game, I'll make an emergency release to address
the issue. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jun 08, 2007 2:21 am Post subject: |
|
Cool! Thanks to you both. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jun 08, 2007 8:12 am Post subject: |
|
I think i know what i was doing wrong now
this is the correct edit:
superimpose the ntsc image on pal canvas (increase vertical canvas size
to pal) this adds small white lines to the top and bottom.
Then stretch resize that image to a 10 inch 4:3 canvas(a small TV)
i measured the exact size of the logo from top to bottom (last time i only measured the M this was incorrect)
so the logo is now: 142x39
142 / 39 = 3.641025...
43 x 3.641025... = 156.564102...
156.564102 / 127 =1.2327882
so it would seem a perfect (and flat) tv without any overscan or
masking would show the entire image at this PAR, almost 1.24 like you
said.
I did several overscan tests, i get about 1.35 with 5% horizontal
overscan, add to that the slight bend in the CRT and you get 1.4
So i suggest the default for pal should be 1.2327882, and then allow
manual overscan settings (ofcourse overscan has to be cropped back to
4:3)
This is also logical because the image is only squashed 16 pixels. or 6.778%
This is the result without any overscan or other distortions
If i apply the same math to NTSC, a perfectly flat TV would give the following values
so the logo is now: 142x42
142 / 42 = 3.380952...
43 x 3.380952... = 145.308952...
156.564102 / 127 =1.1447319
with 5% overscan that would turn into 1.1689163, almost the 1.1666 you said before
PS, my tv clips the overscan on the left side of the image and not
evenly all around, but the image is vertically centered. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 9:10 am Post subject: |
|
tetsuo,
that has your results approximately matching mine; with my close-up I
measured 1.35868747 as well. Considering my CRT is fairly big (~50cm
diagonal), and that I measured just the logo in the middle of the
screen, the bend might not be too noticeable. Of course I wouldn't want
bsnes to use my measurement as some magic average, but it's nice to
hear age hasn't effected my TV too badly  |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jun 08, 2007 9:20 am Post subject: |
|
Good to hear!, i think i really got it this time 
EDIT:
Deleted the entire post
Everything i posted here about real pixel size calculations is wrong.
Last edited by tetsuo55 on Fri Jun 08, 2007 2:11 pm; edited 3 times in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 10:04 am Post subject: |
|
Hmm,
I'm afraid they look quite different on mine; I hooked up my SNES
digitally, and the pixels form a grid. Because of the way colours are
built up it looks like a grid, anyway; the subpixels are (well, look
like) bars of a certain length, and the TV accomplishes a sort of
anti-aliasing by the positioning of these bars (so if you have white
letters, say, one of the top pixels - where it fades to black in the
SoM title screen - will have the bars positioned at the bottom of the
pixels, whereas the bottom ones will have them at the top). There are
very faint vertical, greenish lines in between the pixels, but I can't
make out much of a grid for white pixels. I suppose the green comes
from the fact that the lines run along the green subpixels.
Of course, all this may just be quirks of Sony Trinitrons; looks good though. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jun 08, 2007 10:20 am Post subject: |
|
Your
closeup picture confirms that my pixel is accurate, however it seems
that sony does not offset the grid, instead the pixels are neatly in
line.
So i guess we should have 2 different grids at least. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 10:43 am Post subject: |
|
Yeah,
the pixel dimensions should be correct, but there're no black lines.
(atleast for white) I'll see if I can get an extreme close-up later, my
eyes aren't so good that I'm 100% certain about this. I just don't know
if my camera can do better  |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jun 08, 2007 10:53 am Post subject: |
|
the
black lines are clearly visible in your photo, but dont forget that the
pixels bleed colors into the black line causing it to visually become
smaller or disappear completely |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 11:03 am Post subject: |
|
Well, whatever the case may be, here are the extreme close-ups:
First is the letter H from RIGHTS with the mana tree behind it, second
is a more-or-less random part of said mana tree to show a gradient. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 3:32 pm Post subject: |
|
Ah,
I see. I knew of the technology, but I thought it was only for
flatscreens. My Sony Trinitron is only vertically flat, and doesn't
(noticeably) have the stabilising lines that my monitor has. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 08, 2007 5:46 pm Post subject: |
|
Wow,
that's really cool. I have an aperture grille TV (I've stared at it way
too closely when testing the $2100 brightness setting, heh).
I don't think I've seen a shadow mask CRT TV up close before.
The scanline effect really looks to be less than 70% colored to 30% black, at least from these screenshots.
Anyway, some programming stuff:
- added sinimas' patch
- fixed Xv video clear, there's no longer green edges on the bottom and
right; and unloading a ROM clears the display, too
- added fullscreen support, but only for GTK+ -- Windows shouldn't be
too hard -- this isn't a true "fullscreen", as it won't change
resolution or refresh rate, not like it matters as I lack working
triple buffering anyway. fullscreen centers the output, but copies the
windowed mode scaling settings
- started readding key bindings. esc toggles menu, f11 fullscreen state
- fixed the KoD sound issue (still need to add the change to the code, though)
- started working on auto centering for labels, this should greatly
reduce the ugliness of the Windows port and make it less susceptible to
looking like ass when non-standard font sizes are used
I would have more done, but I've been finishing up Der Langrisser's
English translation. A few hours ago I finally built the final patch +
patching tool. It should be out today, so I can finally scratch that
one off the list of things eating up all my free time. I've gotten like
2-3 hours of sleep in the past two days thanks to that game :(
I will be crashing -- hard -- this weekend as a result. |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Jun 08, 2007 5:54 pm Post subject: |
|
Okay Blargg was right, my previous calculations are ALL wrong
The correct calculation is:
240 scanlines at 50hz
each scanline has a pulserate of 15.625 mhz
50 / 240 = 0.2083333s per scanline
pulsrate x time per scanline = pixel width
1562.5 x 0.2083333 = 325.52078125 pixels
325.52078125 / 240 = 1.3563365885416.....
PS, does bsnes support autopatching for a ninja patchfile? |
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Fri Jun 08, 2007 6:22 pm Post subject: |
|
Both images are from NTSC SNES -> RF Switch -> NTSC TV.
Secret of Mana

Final Fantasy 2
 |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 6:39 pm Post subject: |
|
Did a selection the same way I did with my own close-up. Thanks for testing.
Results:
Code: |
127x43 = 2.95348837
2291x692 = 3.31069364
43x3.31069364 = 142.359827
142.359827 / 127 = 1.12094352 |
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Jun 08, 2007 10:05 pm Post subject: |
|
[deleted by blargg]
Last edited by blargg on Sun Jun 10, 2007 3:32 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 08, 2007 11:47 pm Post subject: |
|
Heh, I thought you were referring to the SNESGT author at first ...
Are you disapproving of our comparisons against TV camera pictures? I'm
intending to use those, rather than the hypothetical calculations, for
the default values.
Right now, we have VG's 1.42x PAL, and DMV27's 1.12x NTSC. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 08, 2007 11:54 pm Post subject: |
|
Sorry
if this is slightly off-topic, but it is quite relevent to bsnes, as
this has been what has consumed roughly half of my free time. Meaning
that time will now be going to bsnes instead.
Der Langrisser English Translation Version 1.0 Released
We're all simply exhausted, so I won't write up a speech. Copy it from the PDF manual if you like.
http://langrisser.cinnamonpirate.com/
http://langrisser.cinnamonpirate.com/downloads/
The archive is licensed under:
http://creativecommons.org/licenses/by-nc-nd/3.0/
... meaning, you can host it anywhere you like, but do not modify the
archive, please. Specifically, we do not want to see an IPS patch made
against this work. We have included patchers for Windows, Linux and Mac
OS X that eliminates patching against the wrong ROM, and automatically
removes any headers that exist. The patcher literally cannot be any
easier than what we have made.
I welcome any and all feedback, bug reports, etc on the programming,
and also any bug reports / typos on the translation. We are not at all interested in personal opinions on how the script has been translated.
Last edited by byuu on Sat Jun 09, 2007 2:21 am; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 08, 2007 11:57 pm Post subject: |
|
Well
if you're going to use my measurements of DMV27's NTSC, my later
measurement of 1.36 uses very close to the same selection. Both
measurements include the selection used. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Jun 09, 2007 1:34 am Post subject: |
|
[deleted by blargg]
Last edited by blargg on Sun Jun 10, 2007 3:32 am; edited 1 time in total |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Sat Jun 09, 2007 4:26 am Post subject: |
|
Wow.
So pretty much the entirety of the last few pages of posts can be
summed up into something like "measure an area of 200 by 200 pixels,
divide real world width by real world height, ratio get!" ?
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Jun 09, 2007 6:18 am Post subject: |
|
I'm going to agree with blargg, we should go for the ruler measurements, we should take an average of xx measurements.
Here's why:
The calculations i made show pixel ratio, not pixel aspect ratio.
The pal tv is going to display the game as 325 individual dots
horizontally, but this doesn't tell us how big each dot will eventually
be (because it will display the exact same 325 on a widescreen tv)
these 325x240 dots are then blasted onto the entire screensurface.
these dots are not pixels however. Its obvious that this simply means
the tv displays 1.36 dots per snes pixel(but again this says nothing at
all about aspect ratio)
So what does this tell us? Well if any snes developer wanted to, they
could have boosted horizontal resolution to 325 (but as far as i know
noone ever did), it probably does however influence colors as pixels
are now spread over several dots, meaning small differences in colors
might occur.(this could explain why gradients look completely different
on tv and why the image looks softer)
So put simply: Take snes output, apply measured PAR, resample resulting
image to 325*240 pixels without altering the size, apply apperature
grill or shadow mask, output to screen. Ill try to make a mock image in
photoshop later, blargg what do you think about this? |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Sat Jun 09, 2007 7:20 am Post subject: |
|
byuu wrote: |
Sorry
if this is slightly off-topic, but it is quite relevent to bsnes, as
this has been what has consumed roughly half of my free time. Meaning
that time will now be going to bsnes instead.
Der Langrisser English Translation Version 1.0 Released
We're all simply exhausted, so I won't write up a speech. Copy it from the PDF manual if you like.
http://langrisser.cinnamonpirate.com/
http://langrisser.cinnamonpirate.com/downloads/
The archive is licensed under:
http://creativecommons.org/licenses/by-nc-nd/3.0/
... meaning, you can host it anywhere you like, but do not modify the
archive, please. Specifically, we do not want to see an IPS patch made
against this work. We have included patchers for Windows, Linux and Mac
OS X that eliminates patching against the wrong ROM, and automatically
removes any headers that exist. The patcher literally cannot be any
easier than what we have made.
I welcome any and all feedback, bug reports, etc on the programming,
and also any bug reports / typos on the translation. We are not at all interested in personal opinions on how the script has been translated. |
nice job, congratulations
_________________
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 09, 2007 9:50 am Post subject: |
|
That translation looks really impressive, I wish I had time to play through it. And wow, nice patching system, too. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Jun 09, 2007 11:17 am Post subject: |
|
Great
to hear it's done; I'd been following the progress of the beta test
since you posted a link to the Langrisser website and I was impressed
by the speed with which it progressed. I'll be sure to try the
translation when I have time! (after this Tuesday) |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Jun 09, 2007 4:36 pm Post subject: |
|
[deleted by blargg]
Last edited by blargg on Sun Jun 10, 2007 3:31 am; edited 1 time in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Jun 09, 2007 7:11 pm Post subject: |
|
thanks for you reply 
blargg wrote: |
tetsuo55, you keep posting things that muddle discussion, not clarify it:
tetsuo55 wrote: |
The calculations i made show pixel ratio, not pixel aspect ratio. |
Stop and define these terms first. Anyone else sure they know what is meant by these?
a dot: a blob on the screen of any random shape or size
Pixel ratio: The number of dots there are in a given surface/image
Pixel aspect ratio: the ratio at which a pixel is horizontally and
vertically defined, a pixel could be 1 unit high and 1.3 units wide
tetsuo55 wrote: |
The
pal tv is going to display the game as 325 individual dots
horizontally, but this doesn't tell us how big each dot will eventually
be (because it will display the exact same 325 on a widescreen tv) |
What's a dot? And widescreen TVs are not under any consideration here.
They further complicate things and were not in use during the SNES era.
I
named widescreen tv's as proof that my previous calculations are
completely wrong, as these tv's stretch the image even further
tetsuo55 wrote: |
these
325x240 dots are then blasted onto the entire screensurface. these dots
are not pixels however. Its obvious that this simply means the tv
displays 1.36 dots per snes pixel(but again this says nothing at all
about aspect ratio) |
Where did this 1.36 come from?
325/240=1.35 the 6 must have been a wrong roundup or typo 
tetsuo55 wrote: |
So
what does this tell us? Well if any snes developer wanted to, they
could have boosted horizontal resolution to 325 (but as far as i know
noone ever did), |
How could they do that? The only software option they have is to double horizontal resolution.
i guess your right about them not being able to
However the analog signal in the tv has 325 individual horizontal
"dots" of information (assuming the snes uses the standard pal mhz like
the nes did)
tetsuo55 wrote: |
it
probably does however influence colors as pixels are now spread over
several dots, meaning small differences in colors might occur.(this
could explain why gradients look completely different on tv and why the
image looks softer) |
Does anyone else make any sense of this?
what
i meant to say is, your ntsc filter changes how the colors appear on
the nes/snes, the same is true for the pal snes, the colors on the
monitor do not match the color on tv at all.
tetsuo55 wrote: |
So put simply: Take snes output, apply measured PAR, |
I'm guessing PAR is pixel aspect ratio, which is width/height of a
single pixel. What does it mean to apply it to the SNES output?
I mean to the emulated square pixels
tetsuo55 wrote: |
resample resulting image to 325*240 pixels without altering the size, |
What does this mean? Resample without altering size? And after we've
"applied" the PAR. Assuming this means rescale, where did this 325 come
from?
If
we take a 4inch by 4 inch image that currently exist of 40x40 pixels,
we could resample that image at 400x400 pixels without increasing the
physical size of 4by4 inch
tetsuo55 wrote: |
apply apperature grill or shadow mask, output to screen. |
OK, I actually understand this part. I've tried this and it darkens the image a bit much.
|
i
have to agree, with the darkening, i have some hypothetical ideas to
solve this problem, but my solutions are not possible on current gen
displays
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Jun 09, 2007 9:07 pm Post subject: |
|
blargg wrote: |
tetsuo55 wrote: |
So
what does this tell us? Well if any snes developer wanted to, they
could have boosted horizontal resolution to 325 (but as far as i know
noone ever did), |
How could they do that? The only software option they have is to double horizontal resolution.
i guess your right about them not being able to
However the analog signal in the tv has 325 individual horizontal
"dots" of information (assuming the snes uses the standard pal mhz like
the nes did)
|
Whatever the NTSC/PAL standard says, the SNES can set the "color" only 256 times per scanline.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sun Jun 10, 2007 1:55 am Post subject: |
|
tetsuo55 wrote: |
pulsrate x time per scanline = pixel width
1562.5 x 0.2083333 = 325.52078125 pixels |
I was under the impression that the horizontal resolution of a TV
signal depended entirely on the quality of the components it passed
through between the original camera and the TV. Thus, a signal from a
VHS tape might have at most 240 "pixels" per line, while DV and
professional gear can have 500+ (source).
325.52 is a nice number (almost a palindrome!), but I don't think it's
actually relevant to TV aspect ratios in any way.
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sun Jun 10, 2007 2:25 am Post subject: |
|
[kind of irrelevant response to thirstan]
Last edited by whicker on Sun Jun 10, 2007 3:53 am; edited 1 time in total |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sun Jun 10, 2007 3:09 am Post subject: |
|
[deleted by blargg] |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sun Jun 10, 2007 4:32 am Post subject: |
|
Okay, here is some concrete calculations:
Rows:
244 visible NTSC lines
224 snes lines
244 - 224 = 20 black lines
Horizontal:
NTSC Active Video 52.6 microseconds
SNES clocked at 21.47727 MHz
256 pixels per line
4 clocks per pixel
256 * 4 * 1 / 21477270 = 47.67 microseconds
52.6 - 47.67 = 4.93 microseconds of black
4.93 / (47.67 / 256) = 26
equivalent to roughly 26 pixels of black
Ratio for perfectly adjusted NTSC TV:
256 + 26 / 224 + 20 = 1.15 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jun 10, 2007 9:00 am Post subject: |
|
whicker,
mind doing the same for PAL? Just kind of curious how close it is to
our ruler measurements. I believe SNES PAL runs at 21281370hz, but of
course, nobody's verified that yet either.
Ok, I
have fullscreen and joypad mapping back in. The only problem is that
the Linux support is very hacky. I desperately need a Linux equivalent
to GetAsyncKeyState().
I don't give a shit how easy that makes keyboard loggers. If it requires root privileges, whatever.
The model I have chosen for bsnes was to abstract the hardware (video, audio and input) from the UI. I am not combining DirectInput with libui on account of Linux' paranoia to letting apps poll the state of the keyboard.
I have searched for a few hours now on Google trying to find a way to
do this and have failed, so ... I really need help here. I'd be willing
to offer monetary compensation for assistance at this point. How in the
living hell can I get the realtime status of whether or not a key is
being held down on Linux, without mapping the key up / down events to
every single window and hoping they never miss key up / down messages
(which they do all the time)? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 9:50 am Post subject: |
|
byuu wrote: |
I
have searched for a few hours now on Google trying to find a way to do
this and have failed, so ... I really need help here. I'd be willing to
offer monetary compensation for assistance at this point. How in the
living hell can I get the realtime status of whether or not a key is
being held down on Linux, without mapping the key up / down events to
every single window and hoping they never miss key up / down messages
(which they do all the time)? |
Well, nothing concrete, but here's a library that does basically the
same thing as libui, only for console programming: ctio.
I remembered reading that the author had to configure the linux
terminal to get the keypresses, which you can read about here
(the article also links to another article about the Linux keyboard).
Perhaps an equivalent solution exists outside of the terminal?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jun 10, 2007 9:54 am Post subject: |
|
http://byuu.org/ wrote: |
2007-06-10 - bsnes v0.021 released
This is a maintainence release. I am mostly releasing this for the sake
of the recently released Der Langrisser translation.
Changelog:
* Windows port can once again map joypads through the Input Configuration panel
* Using enter or spacebar to assign a key should no longer instantly map those keys
* F11 now toggles fullscreen mode
* Esc now toggles menu on and off (use F11+Esc combined to hide UI completely)
* Fixed a bug in King of Dragons (J, U, E), KOFF was not cleared during
S-DSP power(), thanks to FitzRoy for the report, and blargg for
assistance fixing the bug
* Fixed serious crashing error with File->Load on Linux/amd64 port
* Hopefully fixed min/max undefined error on GCC 4.2.0, but I am unable to test to verify
* Fixed many cast const char* to char* warnings for GCC 4.2.0, but some
probably remain, as again, I am unable to test as I lack GCC 4.2.0
* Set XV_AUTO_COLORKEY to 1 for Video/Xv renderer. Should fix some
video drivers where there was no output, especially after running
mplayer, etc. Thanks to sinimas for the fix
* Added clear_video() to Video/Xv renderer. Green edges at the bottom
and right sides of the video output are now gone, and unloading a ROM
will clear video
I am desperately looking for the Linux/X-Windows equivalent to
GetAsyncKeyState(). The current method I use on Linux is to capture key
events on every window's key up / down messages. This is flawed,
however, and it's very easy to end up with a key 'permanently' stuck
down. This also results in the input capture window code being very
hacky. I really need a way to poll the realtime state of keys. If you
know of a way to do this, and have example code, please let me know at
my hotmail.com address, setsunakun0. Thanks. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jun 10, 2007 10:08 am Post subject: |
|
If you want key states, and don't care about requiring root and it being Linux only, I can help you out.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jun 10, 2007 10:56 am Post subject: |
|
whicker wrote: |
Snip! An accurate looking calculation
|
This calculation looks really accurate, but i have some questions
How do you know this: "244 visible NTSC line" (according to this doc its 262 http://gavin.panicus.org/doc/PAL%20NTSC%20differences.txt)
How did you calculate this: "NTSC Active Video 52.6 microseconds" and what does it mean?
Last edited by tetsuo55 on Sun Jun 10, 2007 11:19 am; edited 3 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 11:14 am Post subject: |
|
Thanks
for the 0.021 release, byuu. I don't know why, but it appears to run
faster on my PC than 0.020 - I get 60fps at the Black Omen screen
without having to resort to frame skipping now! (on an Athlon 64 X2
3800+ @2.5Ghz) |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Jun 10, 2007 12:08 pm Post subject: |
|
I get that impression, too.
Switching to fullscreen (F11) while using the "linear" filter shows a
border of garbage pixels around the SNES picture (pic). Is there a way to remove that, apart from switching to the "point" filter?
_________________
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: Sun Jun 10, 2007 12:24 pm Post subject: |
|
why does the cheat editor come with 2 cheats included with nothing saying what games there for?
clean install of 0.21
_________________
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. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 1:19 pm Post subject: |
|
Well, the cheat editor doesn't actually do anything yet.. only the UI part is implemented right now.
creaothceann: no garbage pixels appear on my system. Which port are you
running and what renderer are you using? (I'm on Windows)
Edit: byuu, I just measured the SoM title block from your .gif original
and I get 126x43 rather than 127x43. Applying this to the NTSC and PAL
selections I made gives the following results:
PAL:
Code: |
126x43 = 2.93023256
2183x544 = 4.01286765
43x4.01286765 = 172.553309
172.553309 / 126 = 1.36947071 |
NTSC:
Code: |
126x43 = 2.93023256
2291x692 = 3.31069364
43x3.31069364 = 142.359827
142.359827 / 126 = 1.1298399 |
I'm also looking into accounting for my TV being vertically but not horizontally flat.
Last edited by Verdauga Greeneyes on Sun Jun 10, 2007 6:16 pm; edited 3 times in total
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jun 10, 2007 1:24 pm Post subject: |
|
nice update byuu, fixed the audio crackling i had before now onto getting the video output smooth !
_________________
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: Sun Jun 10, 2007 4:22 pm Post subject: |
|
Verdauga Greeneyes wrote: |
no garbage pixels appear on my system. Which port are you running and what renderer are you using? (I'm on Windows) |
WinXP on a laptop, gfx card = SiS (Silicon Integrated Systems) M760
bsnes video mode: scale 2x, correct aspect rati, NTSC
bsnes video filter: linear, none
bsnes video frameskip: 0
I'll try a new gfx card driver...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sun Jun 10, 2007 4:39 pm Post subject: |
|
tetsuo55 wrote: |
whicker wrote: |
Snip! An accurate looking calculation
|
This calculation looks really accurate, but i have some questions
How do you know this: "244 visible NTSC line" (according to this doc its 262 http://gavin.panicus.org/doc/PAL%20NTSC%20differences.txt)
How did you calculate this: "NTSC Active Video 52.6 microseconds" and what does it mean?
|
Okay, I only posted what I think would be happening, based on the following assumptions.
NTSC interlaced is 525 lines.
525 lines divided by 2 = 262.5, discard the .5 = 262
Vsync is not one line. It is a series of lines. My assumption is that
most video chips will use 6 VSYNC HIGH pulses, 6 vsync LOW pulses, and
finally 6 vsync HIGH pulses again.
VSYNC is not displayed.
262 - 6*3 = 244
52.6 microseconds comes directly from the NTSC spec. The "active video"
portion after HSYNC. It needs to be padded on both sides with some
black, but only a tiny bit. It's more about finding a happy medium
between picture width and sensible clocks per pixel. This padding also
makes it easy for software adjustment of horizontal centering.
The reason I know this crap is because I was curious enough to try to generate video with a microcontroller.
Byuu:
It's going to take me more time with PAL, so I don't pull the numbers out of my arse.
I don't know if the SNES PPU uses 18 lines for vsync. It's an educated guess.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 4:40 pm Post subject: |
|
creaothceann wrote: |
I'll try a new gfx card driver... |
Hope it works 
After some headache-inducing trigonometry (I was never good at that
stuff) I've determined the following things about my TV:
Middle of the screen sticks out 2.10cm farther than the edges.
Line tangent to one of the edges of the screen sticks out a further
2.3cm at the middle of the screen for a total of 2.10 + 2.3 = 4.4cm.
Screen width: 42.35cm = 2*21.175cm
SoM block width: 20.6cm.
21.175 * sqrt((21.175 / 4.4)² + 1) = 104.081439
0.5 * 20.6 / 104.081439 = 0.0989609684
0.0989609684 / sin(0.0989609684) = 1.00163408
So a more accurate measurement for my TV would be the following:
Code: |
126x43 = 2.93023256
2335x580 = 4.02586207
4.02586207x1.00163408 = 4.03244065
43x4.03244065 = 173.394948
173.394948 / 126 = 1.37615038 |
..not the biggest difference ever, I admit. But an interesting exercise
in amateur experimentation. By the way, assuming DMV27's TV is shaped
the same as mine (unlikely) I get these results:
Code: |
126x43 = 2.93023256
2291x692 = 3.31069364
3.31069364x1.00163408 = 3.31610358
43x3.31610358 = 142.592454
142.592454 / 126 = 1.13168614 |
Edit: now with better picture for my TV.
Edit2: updated with better measurements (tangent line is the hardest)
Last edited by Verdauga Greeneyes on Sun Jun 10, 2007 6:40 pm; edited 5 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Jun 10, 2007 5:23 pm Post subject: |
|
Verdauga Greeneyes wrote: |
creaothceann wrote: |
I'll try a new gfx card driver... |
Hope it works
|
It's worse. bsnes didn't display anything at all, even though the driver was newer.
I've reverted back to the version that was already on the harddrive; maybe I'll try again later.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sun Jun 10, 2007 7:14 pm Post subject: |
|
Using this source for PAL numbers:
http://lipas.uwasa.fi/~f76998/video/modes/
PAL is 625 lines per frame (interlaced)
625 / 2 = 312.5 discard the .5 to get 312
Rows:
source says 25 scanlines used for retrace (VSYNC)
I'm going to venture a guess that it's 24 for video chips (3 * 8 = 24)
312 - 24 = 288 visible lines
288 - 240 = 48 pixels padding
288 - 224 = 64 pixels padding
Horizontal:
source says 52 microseconds visible portion per PAL scanline
4 clocks per pixel
21 281 370 Hz
256 * 4 * 1 / 21281370 = 48.11 microseconds
52 - 48.11 = 3.89 microseconds of black padding
3.89 / (48.11 / 256) = about 20 pixels padding
Ratio:
"240" mode
256 + 20 / 240 + 48
"224" mode
256 + 20 / 224 + 64
276 / 288
To expand to a 4/3 ratio (square pixels), the math really sucks.
I'm trying to figure out a number to multiply to a width of a square to
get the height of the square so that it appears square.
( (4/3 width to height) / 276 width) / ( (1 height to height) / 288 height) = 1.391
For NTSC from before
( (4/3) / 282 ) / ( 1 / 244 ) = 1.154
A square of 100 pixels wide needs to be 139 pixels tall in PAL
A square of 100 pixels wide needs to be 115 pixels tall in NTSC |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 9:39 pm Post subject: |
|
whicker wrote: |
( (4/3 width to height) / 276 width) / ( (1 height to height) / 288 height) = 1.391
( (4/3) / 282 ) / ( 1 / 244 ) = 1.154 |
Awesome, look at how close those are to my measurements:
PAL: 100 * ((1.391 / 1.37615038) - 1) ≈ 1.08% off
NTSC: 100 * ((1.154 / 1.13168614) - 1) ≈ 1.97% off (and I suspect that
DMV27's TV is more bulbous than mine, so the result would be even
closer)
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 11:10 pm Post subject: |
|
I'm getting 100% cpu time when no ROM is loaded.
Also clean setup, version 0.021 under Windows XP SP2.
_________________
"Change is inevitable; progress is optional" |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jun 10, 2007 11:18 pm Post subject: |
|
EMu-LoRd wrote: |
I'm getting 100% cpu time when no ROM is loaded.
Also clean setup, version 0.021 under Windows XP SP2. |
Hey, me too; nice catch!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 11, 2007 12:00 am Post subject: |
|
I
know about idle usage. I need an equivalent to Sleep(1) on Linux and I
can eliminate the CPU usage when idle. Eh, screw it. I'll just put it
inside the run() call when no events are pending.
Ok, so ...
NTSC = 1.154
PAL = 1.391
They're very close to our ruler measurements. I'll round those off. Say, 1.15 and 1.40. Sound good?
creaothceann, try using advanced editor, set "system.video" to "dd".
Perhaps it will work better for you than the "d3d" renderer? Only issue
is the obvious one: it's not possible to disable linear filtering with
it.
I forgot to disable the cheat editor, the screen there now is just for example. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jun 11, 2007 12:18 am Post subject: |
|
I
don't particularly mind or anything, but I'm curious. Does rounding the
values help simplify calculations for rendering? Also, do you know
where the mysterious speedup in 0.021 came from?  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 11, 2007 12:24 am Post subject: |
|
Quote: |
I don't particularly mind or anything, but I'm curious. Does rounding the values help simplify calculations for rendering? |
Simplicity, nothing more. Same way it's easy to recall pi = 3.14, but not that pi = 3.141592653 ...
Quote: |
Also, do you know where the mysterious speedup in 0.021 came from? |
Unfortunately, no I don't. I always get wildly different results every time I compile like this.
Here's the fix for 100% CPU usage on Windows:
src/ui/lui/main.cpp:
Code: |
void run() {
while(ui::events_pending() == true) { ui::run(); }
if(cartridge.loaded() == true) {
snes.runtoframe();
event::update_frame_counter();
}
#if defined(_MSC_VER)
//prevent bsnes from consuming 100% CPU resources when idle
else { Sleep(1); }
#endif
} |
I hate defines, but this should work until I find the Linux/GTK+
equivalent. Though I should warn you all, the Windows task manager is
absolutely horrendous at reporting CPU usage. For example, place the
Sleep(1); call inside ui::events_pending() and bsnes will consume 0-3%
CPU -tops-, yet run at half speed (~65fps).
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Jun 11, 2007 12:39 am Post subject: |
|
byuu wrote: |
I know about idle usage. I need an equivalent to Sleep(1) on Linux and I can eliminate the CPU usage when idle. |
Something like sleep(3) (or usleep for sub-second delays)?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 11, 2007 5:09 am Post subject: |
|
I
just want to comment on the pseudo-fullscreen mode in .021: I really
like it. It's great how you can hide or access the menu from within
without having to go back to windowed. The only tradeoff with
pseudo-fullscreen seems to be that you can't quite fill the whole area,
but at least I can get it as close as possible using the multipliers at
no cost to image quality. If that vsync trick "triple buffering" comes
back, I doubt I would miss a true fullscreen mode. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Jun 11, 2007 8:16 am Post subject: |
|
byuu wrote: |
Ok, so ...
NTSC = 1.154
PAL = 1.391
They're very close to our ruler measurements. I'll round those off. Say, 1.15 and 1.40. Sound good?
|
I suggest you don't round up pal , go with 1.39 it comes closest to all
the theoretical and measured values. 1.15 for ntsc sounds fine!
this is how the final result should look like on a pc monitor (its
funny that eventhough i used 1.39 the pal image turned out at 1.4)
RGB
PAL
NTSC
How i made these images:
Open som.gif in photoshop.
Increase canvas size to the calculated number of pixels (this adds the
black border(which i show in white)), then i resize the image to 4"x3"
making it exactly 4:3, this is the image on a 5inch tv (PS if i had
chosen to display on a 10" tv no image data would have been lost)
What if, instead of using aspect ratio on each pixel, you try to
display the image like it would be shown on the tv
So add the black pixels to all sides, and resize to 4:3
for example: SoM on PAL: 256*224 add black border, new size: 276x288
resize image to 4:3, new size 288*216, using this method might allow
for advanced/accurate apperature grill or shadowmask filters in the
future (starting at 4xscale)
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Jun 11, 2007 10:43 am Post subject: |
|
Byuu,
I cannot seem to open files from the command line, if the file name
contains spaces, is it possible to add support for this?(i'm on winxp) |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Jun 11, 2007 11:19 am Post subject: |
|
tetsuo55 wrote: |
Byuu,
I cannot seem to open files from the command line, if the file name
contains spaces, is it possible to add support for this?(i'm on winxp) |
Use quotes for the filename with spaces in it. This isn't something byuu is supposed to deal with.
bsnes "C:\file\with spaces\to be opened.smc"
_________________
FF4 research never ends for me.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Mon Jun 11, 2007 11:48 am Post subject: |
|
If
it's gonna be displayed exactly like on the TV, are you gonna emulate
the thing where it's shifted to the left and cuts off a bit of the
image? :p
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Jun 11, 2007 1:01 pm Post subject: |
|
Deathlike2 wrote: |
Use quotes for the filename with spaces in it. This isn't something byuu is supposed to deal with.
bsnes "C:\file\with spaces\to be opened.smc" |
thanks for this solution!
blackmyst wrote: |
If it's gonna be displayed exactly like on the TV, are you gonna
emulate the thing where it's shifted to the left and cuts off a bit of
the image? :p |
Yeah with the overscan setting
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 11, 2007 8:46 pm Post subject: |
|
This aspect ratio talk is just for the NTSC/PAL TV filters, right? |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jun 11, 2007 9:39 pm Post subject: |
|
FitzRoy wrote: |
This aspect ratio talk is just for the NTSC/PAL TV filters, right? |
Well, I think byuu intends to put sliders for the NTSC and PAL aspect
ratios in the options. Whether these should be enabled by default is
another matter altogether, but it seems to me playing with the correct
- or much closer to what it looked like on your TV anyway - that the
correct aspect ratio would help with immersion and that nostalgic
feeling
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jun 11, 2007 10:36 pm Post subject: |
|
byuu wrote: |
creaothceann,
try using advanced editor, set "system.video" to "dd". Perhaps it will
work better for you than the "d3d" renderer? Only issue is the obvious
one: it's not possible to disable linear filtering with it. |
Thanks, that's much better. 
_________________
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: Tue Jun 12, 2007 8:45 am Post subject: |
|
Verdauga Greeneyes wrote: |
FitzRoy wrote: |
This aspect ratio talk is just for the NTSC/PAL TV filters, right? |
Well, I think byuu intends to put sliders for the NTSC and PAL aspect
ratios in the options. Whether these should be enabled by default is
another matter altogether, but it seems to me playing with the correct
- or much closer to what it looked like on your TV anyway - that the
correct aspect ratio would help with immersion and that nostalgic
feeling
|
What does it look like when the SNES is hooked up to an LCD tv?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Jun 12, 2007 10:19 am Post subject: |
|
I
think, the LCD would closely match a regular tv, but the image would be
really blocky. also depending on the adc(analog to digital converter)
the image could be wildly different
I tried a
google search, all i could find was that samsung lcd tv's have tons of
trouble displaying a normal snes image (they get green lines and blurry
image) |
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Wed Jun 13, 2007 11:57 pm Post subject: |
|
Good to see Der Langrisser finally out!
And I suppose Star Ocean runs on BSNES, too?
Will my 1.5 Ghz AMD Athlon (256 RAM) be enough for maximum framerate? (1 frameskip?) |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 14, 2007 7:42 am Post subject: |
|
lordgalbalan wrote: |
Good to see Der Langrisser finally out!
And I suppose Star Ocean runs on BSNES, too?
Will my 1.5 Ghz AMD Athlon (256 RAM) be enough for maximum framerate? (1 frameskip?) |
bsnes supports the SDD1, so it runs Star Ocean. As for your 6 year old
CPU, I'm guessing it can avoid crackling at 1 frameskip, but we're not
going to know that. Why not just try it?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 15, 2007 7:50 am Post subject: |
|
Ok, I believe the NTSC / PAL aspect ratio issue is now resolved, see:
http://nesdev.parodius.com/bbs/viewtopic.php?t=3393&start=45
I am now using:
NTSC = 54 / 47
PAL = 32 / 23
Nice, rational numbers. NRS is who wrote the original NTSC filter, so I
think we can trust his input on this matter. His numbers are close to
everyone else's latest numbers, and there's a degree of variance
between TVs anyway, so ... I think we're good here now.
Quote: |
It's great how you can hide or access the menu from within without having to go back to windowed. |
Due to the implementation of Windows, it is not possible to use both
triple buffering and allow the menu to be visible. I can go into a long
explanation of why, if you'd like. But suffice to say, I may be able to
add vsync, but that will probably cause the audio to crackle, or the
video to be very choppy. You know how that goes, I've been trying for
years to get this right. It's not happening, sorry :(
Believe me, I want perfectly smooth video and audio as much as anyone else. I even have the hardware for it.
Quote: |
Will my 1.5 Ghz AMD Athlon (256 RAM) be enough for maximum framerate? (1 frameskip?) |
Unlikely, but possible ...
One thing I can do, is create an alternate build that synchronizes only
between opcodes, rather than between bus accesses. It should give a
significant speedup, at a hit to accuracy. Would only take a few
defines. I would guess about 5 - 10 games would display errors, and
even then only in audio, with this opsync method.
But given the problems with eg Der Langrisser in ZSNEeSe9x (I love
these concatenations :P), perhaps it's a good idea?
I've actually been planning to start adding debugger hooks back in, but
all encapsulated in #ifdef's. Now that I have the Linux UI up, a
cross-platform debugger should be good for a little friendly
"competition "between myself and pagefault/ZSNES/Qt ;)
We can finally start making debuggers with tools such as graphical data
viewers. Heh, maybe even give creaothceann a little competition ;)
Lastly, I've been working on some new patching formats lately, hence my
lack of updates. The UPS spec is hopefully almost done, just waiting on
Nach's approval / suggestions / feedback there.
Also, in case anyone missed it, see http://board.zsnes.com/phpBB2/viewtopic.php?t=10063&start=25
if anyone is still wondering about that bug report that keeps popping
up in this thread from time to time. I might have an ace or two up my
sleeve to solve this mystery once and for all here soon ...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 15, 2007 10:55 am Post subject: |
|
Aspect
ratio calculations look good to me, and I guess it makes sense to round
the vertical pixels down considering whatever the SNES may have tried
to do the incomplete 'pixel' would never have shown up on a TV (I hope).
By the way, I was wondering if you've given this any thought:
FitzRoy wrote: |
The
other day, I was wondering if it would be a good idea to create a test
WIP using the old IRQ strategy with the new WAI and other accuracy
improvements. I dunno, it might be worth testing out to see if those
old bugs still persist. 40% would be a heck of a boost at no
compatibility hit. |
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Jun 15, 2007 1:37 pm Post subject: |
|
byuu wrote: |
Quote: |
It's great how you can hide or access the menu from within without having to go back to windowed. |
Due to the implementation of Windows, it is not possible to use both
triple buffering and allow the menu to be visible.
|
Unless you draw your own menus...
byuu wrote: |
One
thing I can do, is create an alternate build that synchronizes only
between opcodes, rather than between bus accesses. It should give a
significant speedup, at a hit to accuracy. Would only take a few
defines. I would guess about 5 - 10 games would display errors, and
even then only in audio, with this opsync method. |
"bsnes light"? Yes, there might be a "market" for it. If it takes only
a few defines, and the build doesn't take that long...
byuu wrote: |
I've
actually been planning to start adding debugger hooks back in, but all
encapsulated in #ifdef's. Now that I have the Linux UI up, a
cross-platform debugger should be good for a little friendly
"competition" between myself and pagefault/ZSNES/Qt 
We can finally start making debuggers with tools such as graphical data
viewers. Heh, maybe even give creaothceann a little competition  |
Sure, go ahead. 
I loved the debug/info windows of genecyst - the same for the SNES would be great.
_________________
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: Fri Jun 15, 2007 8:46 pm Post subject: |
|
byuu wrote: |
Due to the implementation of Windows, it is not possible to use both
triple buffering and allow the menu to be visible. I can go into a long
explanation of why, if you'd like. But suffice to say, I may be able to
add vsync, but that will probably cause the audio to crackle, or the
video to be very choppy. You know how that goes, I've been trying for
years to get this right. It's not happening, sorry Believe me, I want perfectly smooth video and audio as much as anyone else. I even have the hardware for it. |
Well, if you ever come up with anything, it would make a good test WIP.
Also, I'm not sure if you're saying that triple buffering is impossible
with the new GUI rewrite or if you're unwilling to go back to the
"works for most people" implementation.
byuu wrote: |
One thing I can do, is create an alternate build that synchronizes only
between opcodes, rather than between bus accesses. It should give a
significant speedup, at a hit to accuracy. Would only take a few
defines. I would guess about 5 - 10 games would display errors, and
even then only in audio, with this opsync method. |
These ideas would be good for WIPs. Testers can try to figure out more
precisely how many games might be affected and which ones, and then you
can decide if the tradeoff is worth it. I still like the idea of having
two bsnes versions, one for no-holds barred accuracy, and one that
seeks to be as fast as possible without going below 99% compatibility.
You already seem to offer a speed version on your website (.018) as the
"stable" version, but it's really no more stable than .021. .018 could
be replaced by a ".022 Speed." I would have separate buglists for both
versions, by the way.
|
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Fri Jun 15, 2007 8:59 pm Post subject: |
|
byuu wrote: |
Ok, I believe the NTSC / PAL aspect ratio issue is now resolved, see:
http://nesdev.parodius.com/bbs/viewtopic.php?t=3393&start=45
I am now using:
NTSC = 54 / 47
PAL = 32 / 23
Nice, rational numbers. NRS is who wrote the original NTSC filter, so I
think we can trust his input on this matter. His numbers are close to
everyone else's latest numbers, and there's a degree of variance
between TVs anyway, so ... I think we're good here now.
Quote: |
It's great how you can hide or access the menu from within without having to go back to windowed. |
Due to the implementation of Windows, it is not possible to use both
triple buffering and allow the menu to be visible. I can go into a long
explanation of why, if you'd like. But suffice to say, I may be able to
add vsync, but that will probably cause the audio to crackle, or the
video to be very choppy. You know how that goes, I've been trying for
years to get this right. It's not happening, sorry 
Believe me, I want perfectly smooth video and audio as much as anyone else. I even have the hardware for it.
Quote: |
Will my 1.5 Ghz AMD Athlon (256 RAM) be enough for maximum framerate? (1 frameskip?) |
Unlikely, but possible ...
One thing I can do, is create an alternate build that synchronizes only
between opcodes, rather than between bus accesses. It should give a
significant speedup, at a hit to accuracy. Would only take a few
defines. I would guess about 5 - 10 games would display errors, and
even then only in audio, with this opsync method.
But given the problems with eg Der Langrisser in ZSNEeSe9x (I love these concatenations ), perhaps it's a good idea?
|
I've managed at 2 frameskip without crackle.
It would certainly make the experience of the games more enjoyable,
less jerky. (for older computers) One possibility would be to integrate
a page of "speed hacks" in the GUI that can be switched on and off as
the situation requires.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 15, 2007 9:54 pm Post subject: |
|
The
problem with runtime options like this is the overhead of testing the
option. We're talking about really deep-in-the-core stuff that is
tested millions of times a second. Both versions would lose speed if it
were something people could select at runtime.
Separate builds are really my only choice. On that topic, I've
attempted to design bsnes with a polymorphic interface to the classes
... while I want to keep that so that other cores can be swapped out
... I'm thinking of removing the #define trick to make the system
polymorphic as I've never once utilized it in a release due to the
~10-15% speed hit it incurs.
Quote: |
By the way, I was wondering if you've given this any thought: (using old IRQ range testing code) |
The code has changed too much on the last IRQ rewrite, the old method
is no longer drop-in compatible with the new one.
I'll have to rewrite a less accurate one, which is certainly something I can do for massive speed gains, too.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Jun 16, 2007 2:00 am Post subject: |
|
You can also use templates to generate multiple versions of code at compile time,
then select between them at run-time at a top-level function, so you
don't have any speed hit. But this means that practically everything
becomes a function or class template, making compilation more stressful
on the compiler. It's an alternative to multiple builds. |
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Sat Jun 16, 2007 6:49 pm Post subject: |
|
byuu wrote: |
The
problem with runtime options like this is the overhead of testing the
option. We're talking about really deep-in-the-core stuff that is
tested millions of times a second. Both versions would lose speed if it
were something people could select at runtime.
|
You're absolutely right about that.
Quote: |
Quote: |
By the way, I was wondering if you've given this any thought: (using old IRQ range testing code) |
The code has changed too much on the last IRQ rewrite, the old method
is no longer drop-in compatible with the new one.
I'll have to rewrite a less accurate one, which is certainly something
I can do for massive speed gains, too.
|
Isn't writing for accuracy problem enough? Perhaps it would be better
if you let opimization specialists do this for you. (with your counsel,
of course)
It would stand to reason by my PoV that BSNES is the "new generation"
of SNES emulation. Perhaps the SNES emulation community could benefit
from a larger collaboration as regards this software. FreeBASIC took a
similar path, and has come out pretty well on top of the
non-professional BASIC development scene while providing a useful
product.
It would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped.
Furthermore, it would seem to me that if the efforts of the community
were pooled, 100% emulation effectiveness could be in sight....
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jun 16, 2007 6:59 pm Post subject: |
|
lordgalbalan wrote: |
It
would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped. |
Funny that you think you speak for the ZSNES team.
_________________
FF4 research never ends for me.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Jun 16, 2007 7:12 pm Post subject: |
|
lordgalbalan wrote: |
It would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped.
Furthermore, it would seem to me that if the efforts of the community
were pooled, 100% emulation effectiveness could be in sight.... |
Wrong, try again.
_________________
Watering ur plants.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Jun 16, 2007 7:47 pm Post subject: |
|
byuu wrote: |
The
problem with runtime options like this is the overhead of testing the
option. We're talking about really deep-in-the-core stuff that is
tested millions of times a second. Both versions would lose speed if it
were something people could select at runtime.
|
http://insanecoding.blogspot.com/2007/05/secrets-to-optimization-function.html
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Sat Jun 16, 2007 7:55 pm Post subject: |
|
Deathlike2 wrote: |
lordgalbalan wrote: |
It
would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped. |
Funny that you think you speak for the ZSNES team.
|
I'm just recalling what you yourself said regarding StarOcean last
year: you weren't going to go to the trouble to fix the timing.
Well maybe it wasn't you (I'm not going to check), but the position wasn't contested.
Finally, what else are you going to do? Maybe you guys are super-hard
core about getting rediculously software-hardware correspondent
emulation, and I suspect on that note you could keep on like you have
been till the end of your lives and even pass on the torch to later
generations. But is there really a point to it anymore? Most all the
development talk seems to be about little more than filters nowadays.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jun 16, 2007 8:13 pm Post subject: |
|
lordgalbalan wrote: |
Deathlike2 wrote: |
lordgalbalan wrote: |
It
would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped. |
Funny that you think you speak for the ZSNES team.
|
I'm just recalling what you yourself said regarding StarOcean last
year: you weren't going to go to the trouble to fix the timing.
|
That's because Star Ocean itself is buggy, and that work towards a new
core is more important that continuing to retweak the current core
every so often, and that's not a good solution.
Quote: |
But is there really a point to it anymore? Most all the development talk seems to be about little more than filters nowadays. |
That is because users brings that up more often than not, simply
because they prioritize that than most other features.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 16, 2007 8:19 pm Post subject: |
|
lordgalbalan wrote: |
Isn't writing for accuracy problem enough? Perhaps it would be better
if you let opimization specialists do this for you. (with your counsel,
of course) |
Maintaining two separate builds would have been crazy hard two years
ago. There were too many bugs, changed ideas, and things that ended up
getting rewritten. It's probably a better idea today. The biggest jumps
in speed/playability aren't going to come from code optimizations,
they'll come from simplifying a major process at the possible cost of
game compatibility. For example, the current scanline renderer is over
100% faster than a dot-based one would be. It has one show-stopper
issue in one mode of one game, but with dot-based, bsnes on today's
computers would be completely unplayable, and there's no optimization
that's going to overcome that. The scanline renderer is a perfect
example of a reasonable compromise in a "playability over accuracy"
version. Otherwise, keeping one version is just constant straddling
between achieving accuracy and achieving immediate playability, which
is what ZSNES has been doing for years with a much higher consideration
for old computers. But tell me which strategy would actually end up
taking more time: two bsnes versions now, or more straddling?
Quote: |
Furthermore,
it would seem to me that if the efforts of the community were pooled,
100% emulation effectiveness could be in sight.... |
By that rationale, byuu should have joined the ZSNES team. ZSNES needed
so much work in order for Der Langrisser to get a permanent and
competent fix, it probably would have been easier for byuu to write his
own emulator than try to convince any of the ZSNES team to give up
savestates and 486 support for x, y, and z accuracy benefits. Wasn't
going to happen.
Last edited by FitzRoy on Sat Jun 16, 2007 8:31 pm; edited 2 times in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jun 16, 2007 9:00 pm Post subject: |
|
FitzRoy wrote: |
Quote: |
Furthermore,
it would seem to me that if the efforts of the community were pooled,
100% emulation effectiveness could be in sight.... |
By that rationale, byuu should have joined the ZSNES team. ZSNES needed
so much work in order for Der Langrisser to get a permanent and
competent fix, it probably would have been easier for byuu to write his
own emulator than try to convince any of the ZSNES team to give up
savestates and 486 support for x, y, and z accuracy benefits. Wasn't
going to happen.
|
Some emus are written for a different set of users. There's nothing
exactly wrong with that.. it doesn't mean that savestate support is a
bad thing. You are making it sound like it should be dropped, but the
simple fact is that it would be vastly difficult to accomplished based
on how BSNES is constructed, not our fault that savestate support is
somehow deemed "evil". Again, different goals for different emus for
the same system. The simple fact that you are asking for "less
accurate, but faster" optimizations to the same this is the same reason
while older emus like Snes9x+ZSNES have had speed hacks. You can't have/argue it both ways FitzRoy.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 16, 2007 9:16 pm Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
Quote: |
Furthermore,
it would seem to me that if the efforts of the community were pooled,
100% emulation effectiveness could be in sight.... |
By that rationale, byuu should have joined the ZSNES team. ZSNES needed
so much work in order for Der Langrisser to get a permanent and
competent fix, it probably would have been easier for byuu to write his
own emulator than try to convince any of the ZSNES team to give up
savestates and 486 support for x, y, and z accuracy benefits. Wasn't
going to happen.
|
Some emus are written for a different set of users. There's nothing
exactly wrong with that.. it doesn't mean that savestate support is a
bad thing. You are making it sound like it should be dropped, but the
simple fact is that it would be vastly difficult to accomplished based
on how BSNES is constructed, not our fault that savestate support is
somehow deemed "evil". Again, different goals for different emus for
the same system. The simple fact that you are asking for "less
accurate, but faster" optimizations to the same this is the same reason
while older emus like Snes9x+ZSNES have had speed hacks. You can't have/argue it both ways FitzRoy.
|
And you're making it sound like it was my idea to drop savestates. What
I'm meaning to say is that byuu has his own ideas about tradeoffs that
are not compatible with other projects. Maybe savestates wasn't as
direct of an example as I wanted, but byuu thought they were expendable
and I doubt you or anyone else on the ZSNES team thinks the same. By
the way, I'm a supporter of separate bsnes versions at some point.
Would that not be having it both ways? And what exactly is your goal
now, by the way? And if it's changed, what was it when ZSNES began?
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jun 16, 2007 9:25 pm Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Quote: |
Furthermore,
it would seem to me that if the efforts of the community were pooled,
100% emulation effectiveness could be in sight.... |
By that rationale, byuu should have joined the ZSNES team. ZSNES needed
so much work in order for Der Langrisser to get a permanent and
competent fix, it probably would have been easier for byuu to write his
own emulator than try to convince any of the ZSNES team to give up
savestates and 486 support for x, y, and z accuracy benefits. Wasn't
going to happen.
|
Some emus are written for a different set of users. There's nothing
exactly wrong with that.. it doesn't mean that savestate support is a
bad thing. You are making it sound like it should be dropped, but the
simple fact is that it would be vastly difficult to accomplished based
on how BSNES is constructed, not our fault that savestate support is
somehow deemed "evil". Again, different goals for different emus for
the same system. The simple fact that you are asking for "less
accurate, but faster" optimizations to the same this is the same reason
while older emus like Snes9x+ZSNES have had speed hacks. You can't have/argue it both ways FitzRoy.
|
And you're making it sound like it was my idea to drop savestates. What
I'm meaning to say is that byuu has his own ideas about tradeoffs that
are not compatible with other projects. Maybe savestates wasn't as
direct of an example as I wanted, but byuu thought they were expendable
and I doubt you or anyone else on the ZSNES team thinks the same.
|
Then you need to say it explicitly then. It would have been succinct in
saying they have different philosophies, different user base, etc.
However, the point has to be made clear and in a way that respects both
user bases.
Quote: |
And what exactly is your goal now, by the way, and is it the same as when ZSNES began? |
Obviously accurate emulation is the goal now.. but getting to that
point will not be the same like BSNES (since byuu started from
scratch). Goals change when they do... as it is the natural progression
of things.. but it always depends on goals of the people who are
running the project.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 16, 2007 10:38 pm Post subject: |
|
Ouch, not the discussion I was hoping to see this morning ...
Quote: |
You can also use templates to generate multiple versions of code at compile time |
I could ... but since the entire CPU core would have be embedded inside
this function, or I would need at least 3 million extra function
pointer calls/second, it isn't very practical. 2x EXE size and 2x
compile time, or a marked increase in overhead.
Although, Nach may be right. Maybe I should try function pointers,
perhaps 3 million of those won't be so bad compared to that tight
single-cycle-stepping IRQ tester.
Quote: |
It
would seem to me that if ZSNES is not going to take the same path as
BSNES, development on it has for all intents and purposes stopped. |
Nooo ... don't say things like that, please.
The truth is that people posting here are in the minority, maybe representing ~2% of emulation users.
Most people just want the games playable, and true accuracy is impossible to maintain, anyway.
My goals when I started bsnes were dead-on accuracy or nothing, but I
soon found myself with something completely unplayable on any
computers. The reason for this was simple, when I started I didn't
fully understand exactly what was involved like I do now. As nice as it
is to have such a perfect reference, it's hard to keep up morale to
work on a project with a user base of zero people. As such, I'm
currently aiming toward the most accuracy I can get, while still being
playable on relatively newer processors.
Quote: |
Furthermore,
it would seem to me that if the efforts of the community were pooled,
100% emulation effectiveness could be in sight.... |
Our ideals are all too different, and I'm in the smallest minority. I
see little hope of pooling everyone's resources on a single emulator,
mine or otherwise. Plus, even most ZSNES and SNES9x developers aren't
able to work on the core much. Little changes, sure, but nothing major.
This is why you see emphasis on other features over accuracy ... they
work on areas in their forte.
With TRAC, Overload and anomie mostly gone, GIGO not being entirely
fluent in English and us not in Japanese, there's really few core
developers left at all. The scene that existed in 2003 over at the 9x
boards has most certainly moved on and gone. Even I've nearly reached
the limits of what I can do, and there are no affluent EEs willing to
help me with my current limitations. Plus I can barely run bsnes on a
Core 2 Duo ... how much farther can I take things? I don't see SNES
emulation going much farther at all to be honest with you, but perhaps
I'm just a pessimist.
Quote: |
That's
because Star Ocean itself is buggy, and that work towards a new core is
more important that continuing to retweak the current core every so
often, and that's not a good solution. |
The game isn't that buggy. But we agree that continuing to try and fix
the current opcode cores is silly, at least. It's well known that you
can't get 100% compatibility with an opcode-based core, no matter what
you do. You'll just break other games and play whack-a-mole forever.
But pagefault is working on new cycle cores, which is awesome. That should help a lot.
Quote: |
By that rationale, byuu should have joined the ZSNES team ... |
Yeah, pretty much. I knew my ideals were too different to try and
convince many others to follow them. Best to just start my own project,
really.
Quote: |
t doesn't mean that savestate support is a bad thing. |
To be honest, I really do want savestate support. I just can't have it
both ways. I don't have a problem at all with features, and quite like
them. That's why I have graphics filters, color adjustments and a cheat
code editor in there. They're nice little features to have. I don't
have a lot of features because I'm just one person and I prefer to
focus on the actual emulator more. It's just that savestates is not one
I can add. I knew that, and decided it would be more beneficial to use
threading than implement savestates. I have no problems with emulators
that implement things like savestates, and actually enjoy having the
features available. pagefault's cycle cores will be a welcome addition.
It's a lot easier to have a cycle core and savestates, and I'm sure he
can pull it off. I don't have that in bsnes, though. I can actually
sync in the middle of cycles to emulate bus hold delays. This is a very
minimally important feature that probably doesn't even affect accuracy
much, but I thought it was worth adding. I think pagefault will end up
with the best of both worlds when he is finished.
Quote: |
but byuu thought they were expendable and I doubt you or anyone else on the ZSNES team thinks the same |
Exactly. But if bsnes were the only
SNES emulator in existence, it probably would've been better to add
savestate support to it. I knew everyone who really wanted savestates
could use ZSNES, same for people with older PCs ... they could use the
already fantastic ZSNES. It made it easier for me to create something
wildly different.
But since ZSNES already exists
... if I just tried to make the same, fast, featureful emulator
(ignoring the fact that one man alone could never recreate ZSNES
anyway), I'd just end up with an inferior ZSNES. Why bother?
Quote: |
However, the point has to be made clear and in a way that respects both user bases. |
It's a tricky line to draw. Overall, ZSNES is clearly the better
emulator. The download counts alone don't lie: 3,000,000 to 5,000 per
release. But sometimes it's important to say, for instance: "ZSNES is
way faster and supports special chips like SFX and SA-1, and features
like savestates, movie recording, and key combination editors, whereas
bsnes does not." or "bsnes is more accurate, and runs more base-SNES
software than ZSNES." -- both are true, neither have any real bias in
them. It's also very easy to cross that line and offend developers.
I've unfortunately done this a lot in the past and upset pagefault,
which I never had any intention of doing. It's hard to draw the line
between making everyone happy, and actually trying to inform people of
the advantages of one program over another. If we never said bsnes was
better than ZSNES at anything, why would anyone ever want to use it?
I think I'm achieving my initial goals, anyway, though. I've at least
convinced a lot of people of the importance of accuracy, and now ZSNES
and SNES9x are moving in that direction. I question if the same would
be true today if I never wrote that emulator article back in 2004. My
involvement in that is irrelevant anyway, I'm just happy it's happening.
I know ZSNES can make a super fast, highly accurate emulator. And when
they succeed and everyone using bsnes switches back, they'll have
earned it. I'll continue to fill a niche until that day, however. I
still think it's unfortunate that we can't just agree to have our two
projects focus on different userbases. There will no longer be an
emulator focused exclusively on speed when both ZSNES and SNES9x start
moving toward bsnes-specific features like cycle cores. As nice as they
are, they really only improve compatibility by ~1-2% while costing a
lot of speed, no matter how fast they are.
You see, I'm undecided if I want ZSNES to become as accurate as bsnes
or not. I'm really not sure what will be better for the community as a
whole. We'll just have to wait and see which aces pagefault has up his
sleeve.
The only real problem I have right now with ZSNES' development is that
even the new cycle cores are being written in non-portable x86
assembler. Such code is ridiculously hard for an outsider to read, and
prevents ZSNES from running on neat new platforms that will be coming
out now and in the future, eg PS3, ARM-based UMPCs, etc. I understand
why ZSNES was written in assembler in the first place, but not why the
developers continue to write new code in assembler. But, to each their
own.
Last edited by byuu on Sat Jun 16, 2007 10:43 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jun 16, 2007 10:42 pm Post subject: |
|
The
only thing I wanted to criticize ZSNES for in that post was that I
think you guys are overly considerate of old hardware. As technology
progresses, your emulator should have progressed in line with that, and
it really hasn't. At one point, ZSNES probably needed a high-end CPU to
run full speed just like bsnes does today, and now it runs on dirt but
needs a ton of code rewritten. Whether or not that has to do with skill
or time constraints, I have no idea. But that's where it stands, and
you all seem happy to keep rewriting, so who cares what I think?
Believe it or not, SNES emulators are all chiefly similar in their
goals. You're all trying to document/emulate the same system and get
the same games working for the most platforms as possible. What
sacrifices you're willing to make in order to bring about immediate
playability is the biggest difference between you: hacks, code
language, core strategies, etc. Lordgalbalan, as a user, probably is
wondering why the most experienced and skilled coders (who could drop
out of the scene at any moment due to RL events) would continue to work
on separate emulators that need seemingly endless work instead of
together on something like bsnes under two versions. And the reasons
have more to do with pride, control, and nostalgic tradition than
actually choosing what's best to achieve both goals in the least amount
of time. The hobbyist excuse only applies to an extent because you're
performing the same hobby/challenge under either project. Aesthetics?
Petty when it comes down to it. But you know what... I'm not
complaining anymore. At least you're not all closed source and paranoid
about people stealing your work (PSX). Things turned out pretty good
here. I'm just wondering what other systems could have benefited from
time lost on SNES separatism. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jun 16, 2007 10:52 pm Post subject: |
|
FitzRoy wrote: |
At least you're not all closed source and paranoid about people stealing your work (PSX). |
pSXAuthor's relectunce very likely stems from possible (legal) issues
for just releasing it open source (due to the nature of what his job
is).
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 16, 2007 10:54 pm Post subject: |
|
Quote: |
The only thing I wanted to criticize ZSNES for in that post was that I think you guys are overly considerate of old hardware. |
Unfortunately, this causes a lot of strife for me. I had to ban someone
at langrisser.cinnamonpirate.com for being extremely distasteful for
this exact issue. Sadly, the general public uses the speed of the
fastest emulator as a measuring stick to how good other emulators are.
And if other emulators are slower, they lack the ability to comprehend
why that might be. It's not always just because the programmer involved
sucks at what he's doing.
Quote: |
Lordgalbalan,
as a user, probably is wondering why the most experienced and skilled
coders (who could drop out of the scene at any moment due to RL events)
would continue to work on separate emulators that need seemingly
endless work instead of something like bsnes under two versions. |
Essentially, ZSNES is not willing to start over. Whereas I've done so
twice and am willing to do it again if it's necessary. I can kind of
see why, the oldest rewrite of bsnes is ~1.5 years old, the oldest
ZSNES is about ten. Would you want to throw away ten years of work? :/
I don't care about the fame, though, and I actually agree with you
about working together, even if it means more than one maintained
version. I have tried to get other emulators to use the same class
abstraction techniques I mostly was forced to come up with myself. Then
we could just plug in our own customized processor emulators, and all
work together on each one as we see fit. We still have our own brand
names for our emulators, but everyone gets a community that works 100%
together rather than separately.
I would even be willing to ditch bsnes and start on a new project, from
the ground up, to make a new collaborative emulator, but sadly nobody
would join in. We tried to do this in the past, actually, and it just
didn't work. The end result was a useless partial emulator skeleton.
It's just not meant to be :(
Quote: |
And
the reasons have more to do with pride, control, and nostalgic
tradition than actually choosing what's best to achieve both goals in
the least amount of time. The hobbyist excuse doesn't apply because
you're performing the same hobby under either project. |
I agree completely, and this applies as much to me, if not moreso, as
to anyone else. I could've sucked up my pride and tried to improve
ZSNES instead, but I chose to start my own project because I didn't
want to deal with the hassle involved in fighting other people over
directions to take the project in. It's that I want control over end
decisions that I started on bsnes instead.
Quote: |
I'm just wondering what other systems could have benefited from time lost on the SNES. |
Probably none. At least speaking for myself, it was the SNES or
nothing. I want to work on Saturn emulation, but Jesus H. Christ that
is a complicated system. I'd never make a dent in that, so I would
never have bothered. I really doubt any other SNES emu authors would've
spent the extra time working on other systems.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Jun 16, 2007 11:51 pm Post subject: |
|
I
honestly have no idea why this is such a hot debate. Just use any
program that does the best job for your own needs and leave it at that.
This is getting stupid, like arguing over linux distros.
_________________
Watering ur plants. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Sun Jun 17, 2007 2:11 am Post subject: |
|
pagefault,
if there's anything worth telling right now, you should consider
posting another ZSNES status update, like you did in this thread.
Compared to bsnes, little news about ZSNES' development is revealed. That thread is over a year old, too. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jun 17, 2007 2:49 am Post subject: |
|
Nice
job on the latest progress with bsnes and the pal aspect ratio
findings. Also amazing work on the Der Langrisser translation, I'll be
sure to play it throughout whenever I have the time.
Silly off topic: I can think of at least one way to have pseudo-save
staes in bsnes...But it's too insane to be pratical in real life. edit:
see the thread "hibernation + ghosting" in tech...the method used has
nothing to do with bsnes itself)
blargg's sugestion
Quote: |
You
can also use templates to generate multiple versions of code at compile
time, then select between them at run-time at a top-level function |
sounds interesting.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jun 17, 2007 3:36 am Post subject: |
|
xamenus wrote: |
pagefault,
if there's anything worth telling right now, you should consider
posting another ZSNES status update, like you did in this thread.
Compared to bsnes, little news about ZSNES' development is revealed. That thread is over a year old, too. |
We have jobs and lives so development is slow. We also have a level of
secrecy we like to maintain. When there is news you will know about it.
_________________
Watering ur plants.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 17, 2007 7:39 am Post subject: |
|
pagefault wrote: |
I
honestly have no idea why this is such a hot debate. Just use any
program that does the best job for your own needs and leave it at that.
This is getting stupid, like arguing over linux distros. |
The program that does the best job at meeting most people's wants is one that could exist but doesn't.
byuu wrote: |
Would you want to throw away ten years of work? :/ |
No, but I'd try to archive old versions and let anyone continue to use
them. Walking away isn't the same as throwing away. It would be nice if
people didn't have to keep duplicating each other's efforts at this
point. But like I said, I'm not exactly disappointed with the way
things have been going.
Deathlike2 wrote: |
FitzRoy wrote: |
At least you're not all closed source and paranoid about people stealing your work (PSX). |
pSXAuthor's relectunce very likely stems from possible (legal) issues
for just releasing it open source (due to the nature of what his job
is).
|
If true, that's totally understandable, but I was referencing the PSX
scene on the whole. When ePSXe "died" (it's not dead, it's not dead!),
the source stayed closed. In fact, I don't know of any prominent PSX
emulators that are open-source.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jun 17, 2007 12:10 pm Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
At least you're not all closed source and paranoid about people stealing your work (PSX). |
pSXAuthor's relectunce very likely stems from possible (legal) issues
for just releasing it open source (due to the nature of what his job
is).
|
If true, that's totally understandable, but I was referencing the PSX
scene on the whole. When ePSXe "died" (it's not dead, it's not dead!),
the source stayed closed. In fact, I don't know of any prominent PSX
emulators that are open-source.
|
I can confirm that legal reasons keep this source closed
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sun Jun 17, 2007 2:17 pm Post subject: |
|
byuu wrote: |
The
only real problem I have right now with ZSNES' development is that even
the new cycle cores are being written in non-portable x86 assembler.
Such code is ridiculously hard for an outsider to read, and prevents
ZSNES from running on neat new platforms that will be coming out now
and in the future, eg PS3, ARM-based UMPCs, etc. I understand why ZSNES
was written in assembler in the first place, but not why the developers
continue to write new code in assembler. But, to each their own. |
Not to say it wouldn't happen in the future, but I've the SNES emu
scene has generally put Snes9x in the portability catagory, and for
good reason. I don't think that would change in the future, so dreams
of ZSNES portability will probably be on some backburner.
_________________
FF4 research never ends for me.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jun 17, 2007 2:41 pm Post subject: |
|
FitzRoy wrote: |
The program that does the best job at meeting most people's wants is one that could exist but doesn't. |
So how about helping out rather than criticizing and speculating. Both
projects offer their source to the public and both are happy to take
constructive meaingful patches. Otherwise I have to say stfu because
you don't help either of us.
_________________
Watering ur plants.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 17, 2007 11:59 pm Post subject: |
|
pagefault wrote: |
FitzRoy wrote: |
The program that does the best job at meeting most people's wants is one that could exist but doesn't. |
So how about helping out rather than criticizing and speculating. Both
projects offer their source to the public and both are happy to take
constructive meaingful patches. Otherwise I have to say stfu because
you don't help either of us.
|
You seem to think that anyone who can't code very well can't contribute
in some way. I may not have chosen to spend my years becoming a
professional programmer, but I do what I can as a beta tester to offer
ideas, support, and constructive criticism. Byuu doesn't agree with
everything I say, but at least he's receptive to it, or takes the time
to respond. When I make long posts for the sake of backing things up
with reason, you see it as a stupid "debate." Nobody's debating
anything here. People just want emulation to improve for everybody, and
with good intentions, they "speculate" how. I'm sorry if you feel that
criticism from one who doesn't code is not worth considering. I'll
refer you to byuu's post then, because he mostly agreed with what I
said and I'm pretty sure he's a programmer.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jun 18, 2007 12:10 am Post subject: |
|
FitzRoy wrote: |
pagefault wrote: |
FitzRoy wrote: |
The program that does the best job at meeting most people's wants is one that could exist but doesn't. |
So how about helping out rather than criticizing and speculating. Both
projects offer their source to the public and both are happy to take
constructive meaingful patches. Otherwise I have to say stfu because
you don't help either of us.
|
You seem to think that anyone who can't code very well can't contribute
in some way. I may not have chosen to spend my years becoming a
professional programmer, but I do what I can as a beta tester to offer
ideas, support, and constructive criticism. Byuu doesn't agree with
everything I say, but at least he's receptive to it, or takes the time
to respond. When I make long posts for the sake of backing things up
with reason, you see it as a stupid "debate." Nobody's debating
anything here. People just want emulation to improve for everybody, and
with good intentions, they "speculate" how. I'm sorry if you feel that
criticism from one who doesn't code is not worth considering. I'll
refer you to byuu's post then, because he mostly agreed with what I
said and I'm pretty sure he's a programmer.
|
Ha!
That was really funny, thanks for the laugh 
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jun 18, 2007 2:42 am Post subject: |
|
FitzRoy wrote: |
You seem to think that anyone who can't code very well can't contribute in some way. |
Thanks for the speculation. Also for proving my point.
_________________
Watering ur plants.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 18, 2007 2:53 am Post subject: |
|
FitzRoy wrote: |
I'll refer you to byuu's post then, because he mostly agreed with what I said and I'm pretty sure he's a programmer. |
No, but I did stay at a Holiday Inn Express last night ...
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jun 18, 2007 3:04 am Post subject: |
|
I hear they have good waffles.
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 18, 2007 3:14 am Post subject: |
|
Quote: |
Ha!
That was really funny, thanks for the laugh Laughing |
This is why bsnes needs its own forum because ZSNES devs, for all your
coding knowledge, lack the order of reason to put yourselves in the
shoes of the average user. Thus we have stuff like sound filters that
literally allow people's own ignorance to waste their time, and an
entirely new compression format to save a mere 300mb max on a rom
collection when space is CENTS per GB. It's absurd.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Jun 18, 2007 3:58 am Post subject: |
|
FitzRoy wrote: |
Quote: |
Ha!
That was really funny, thanks for the laugh Laughing |
This is why bsnes needs its own forum because ZSNES devs, for all your
coding knowledge, lack the order of reason to put yourselves in the
shoes of the average user.
|
I'm very offended by that comment. I'm not just a developer, but I'm a
user too. I have a pretty good idea the problems people have, but I
also understand why things are done even if I disagree with it. It is
no different from any app, let alone emu.
Quote: |
Thus
we have stuff like sound filters that literally allow people's own
ignorance to waste their time, and an entirely new compression format
to save a mere 300mb max on a rom collection when space is CENTS per
GB. It's absurd. |
What does that have to do with anything? Whether or not you use a sound
filter is a user preference. Whether people prefer to conserve as much
space as possible is also another user preference. Now whether or not
something gets done for them is a completely seperate issue altogether.
There's a fair chance as to what people want done isn't what developers
would prefer and you will have to live with the result.
_________________
FF4 research never ends for me.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Mon Jun 18, 2007 4:05 am Post subject: |
|
Absurdity is irrelevant. Illogical discussions are irrelevant. You will be assimilated. </borg>
IMNHO - ZSNES = x86 powerhouse, SNES9X = portable magnificence, bsnes =
immaculate accuracy. Let them be what they are, and they will become
even better. Force them to become what they are not, and they will
falter in mediocrity. The very differences between these three
emulators are the strengths that make them ideal for different purposes
and audiences.
As for myself - I'm a coder. And hell yes, I have definite opinions on
what would be best for all three projects. However, I know damn well
that there's a reason that I'm not listed as * developer here - I'm not
of the level or type of experience at this point where I could make any
difference. (Ask Nach - if he remembers, he spent a few hours with me
on IRC a while back just trying to get ZSNES to compile with OpenGL on
my other Linux box.) It's that very knowledge that makes me realize
that hey, maybe besides the actual academic programming knowledge,
there's something else they know that gives them a solid idea on what
they're aiming for. Will I give input where input is requested? Sure!
But I wouldn't be so presumptious to assume I know what would be best.
Sorry for the slightly off-topic rant - I'll go back to being the mostly silent lurker now 
_________________
Why yes, my shift key *IS* broken. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jun 18, 2007 4:08 am Post subject: |
|
I
repeat. If you don't like it don't use it and stfu. FitzRoy I have not
laughed harder than this for a long time. You are so up your own ass
it's funny. You make yourself seem elitist to everyone and put everyone
under you. You are not an average user, you are a whiner who doesn't
know the difference between what is a feature and was added for users
to enable if they want and something that is required.
You also have no idea what the development process of ZSNES is and
making stupid assumptions based on that just makes me laugh even
harder. You seem to know more about out project than we do. Maybe we
aren't elite enough to work on it ourselves.
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 18, 2007 6:38 am Post subject: |
|
pagefault wrote: |
I
repeat. If you don't like it don't use it and stfu. FitzRoy I have not
laughed harder than this for a long time. You are so up your own ass
it's funny. You make yourself seem elitist to everyone and put everyone
under you. You are not an average user, you are a whiner who doesn't
know the difference between what is a feature and was added for users
to enable if they want and something that is required.
You also have no idea what the development process of ZSNES is and
making stupid assumptions based on that just makes me laugh even
harder. You seem to know more about out project than we do. Maybe we
aren't elite enough to work on it ourselves. |
Instead of continuing to go on a raging tear with vague insults about
how you perceived me to come across, how about quoting what I actually
said and addressing the "assumptions" themselves in turn. I hate
neither you nor your emulator, but your posts are nothing but short
quips and fire and brimstone so far. Out of respect for byuu, who hates
when this happens, if you want to move this to a separate thread below,
please do.
Deathlike2 wrote: |
What
does that have to do with anything? Whether or not you use a sound
filter is a user preference. Whether people prefer to conserve as much
space as possible is also another user preference. Now whether or not
something gets done for them is a completely seperate issue altogether.
There's a fair chance as to what people want done isn't what developers
would prefer and you will have to live with the result. |
If someone comes in your feature request forum and says that they want
the option to make a dancing chicken go across the screen when they
unload a rom, would you add it? They prefer it, Deathlike. Where do you
say no and where do you say yes? Is it less worthy than a different
interpolation method?
Here are examples where we know for sure that people have wasted their
time trying to fix sound issues by messing with all the sound options.
This doesn't include the people who did it and never posted it:
http://board.zsnes.com/phpBB2/viewtopic.php?t=5556
http://board.zsnes.com/phpBB2/viewtopic.php?t=9605
Conversely, I can't remember a single request for those options in the
bsnes thread after it was discussed and byuu decided not to add them.
You can't call these assumptions anymore. I'm giving you evidence and
then reason through comparison. I want to know what those interpolation
options do and how anyone could perceive them to be better than
default. Once you reason that that's even possible, just give me an
honest opinion if you think they cause more grief than they're actually
worth? Then we can agree or disagree in a civilized manner.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Jun 18, 2007 10:09 am Post subject: |
|
If
we have snow in the background of the menus, why not a chicken dancing
across the screen. Assuming someone is bored enough to draw said
chicken.
</sarcasm>
My point is, unneeded things already are in the emulators. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Jun 18, 2007 11:06 am Post subject: |
|
while were at it, lets have every single emulator in existence (with the spoken feature supported) remove savestate support.
_________________
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: Mon Jun 18, 2007 11:59 am Post subject: |
|
NO! 0_0
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Jun 18, 2007 1:19 pm Post subject: |
|
FitzRoy wrote: |
If
someone comes in your feature request forum and says that they want the
option to make a dancing chicken go across the screen when they unload
a rom, would you add it? They prefer it, Deathlike. Where do you say no
and where do you say yes? Is it less worthy than a different
interpolation method? |
You have completely ignore that ones that have been denied, such as
having RAR/7z support and adding mouse support for games that did not
originally have it (it probably could be done, but that is beyond the
scope of my argument).
Quote: |
Here
are examples where we know for sure that people have wasted their time
trying to fix sound issues by messing with all the sound options. This
doesn't include the people who did it and never posted it:
http://board.zsnes.com/phpBB2/viewtopic.php?t=5556 |
That's a very pathetic reference. The guy doesn't even come back to
look for options or anything. There are plenty of troubleshooting
options to attempt, but what good is there when the guy doesn't come
back to his post to respond, like many different posts that have been
made on this board.
Quote: |
http://board.zsnes.com/phpBB2/viewtopic.php?t=9605 |
The guy asked an opinioned question, which he also gets a opinioned
answer. His question about the CT "black lines" issue was also dealt
with, and was given an actual explanation about it.
What the hell is your point?
Quote: |
Conversely,
I can't remember a single request for those options in the bsnes thread
after it was discussed and byuu decided not to add them. You can't call
these assumptions anymore. I'm giving you evidence and then reason
through comparison. I want to know what those interpolation options do
and how anyone could perceive them to be better than default. Once you
reason that that's even possible, just give me an honest opinion if you
think they cause more grief than they're actually worth? Then we can
agree or disagree in a civilized manner. |
No. It is pointless to converse if you have a flawed argument,
especially in your examples. The only perception that is being conveyed
is a flawed one, and a solo one. When someone asks an opinionated
question, you expect an opinionated answer. As long as the answer gives
valid reasoning (when facts, not opinions are involved), then there
isn't an issue. I fail to see how you've provided any legitimate
analysis.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 18, 2007 9:28 pm Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
If
someone comes in your feature request forum and says that they want the
option to make a dancing chicken go across the screen when they unload
a rom, would you add it? They prefer it, Deathlike. Where do you say no
and where do you say yes? Is it less worthy than a different
interpolation method? |
You have completely ignore that ones that have been denied, such as
having RAR/7z support and adding mouse support for games that did not
originally have it (it probably could be done, but that is beyond the
scope of my argument).
|
I realize that you've denied requests. IIRC, RAR wasn't denied because
people wouldn't use it, it was denied because of licensing issues.
Mouse support like that would also get used, but might not even be
feasible. The chicken animation might not be feasible, either, but we
could use some type of echo filter instead. When we talk about some of
those sound options, we're talking about things that people have a
greater tendency to enable out of misinformation or frustration than
out of actual preference.
I believe already implemented options that are too old for anyone to
remember how they got there still need their worth to be questioned.
You're saying that because they exist and that they don't cause any
direct problems with users, that they deserve to remain because they're
harmless. I'm trying to be more practical with someone who is not tech
savvy. If you were someone like that, wouldn't you try to dick with
foreign sound options for a sound problem right away? Instead of making
things more self-explanatory and minimizing user confusion from the
beginning by removing things that no one would miss, you blame their
wasted time as a result of user stupidity and poor correlations based
on a lack of research. The proper recourse to you is for them to
consult the doc, but the doc is humongous and may not even contain
anything about zsnes' longstanding sound issues. They'd probably have
to come on the forum anyway.
And as someone who IS technologically inclined, you should also be able
to explain away misinformed preferences that something like 96khz is
not better simply because it's higher, or that slightly more efficient
compression isn't worth deviating from the simplicity of a standard.
How many more formats would you accept before saying "enough is enough
for people to have to learn." Some of these things aren't as
self-explanatory as brightness or volume. I've seen people come in here
and go "what is hell is JMA, why doesn't it work anymore with this
revision, what the hell is this, what the hell is that?" And the
combined time that gets wasted for them to inquire about it and for
others to respond isn't worth the benefit that some of these options
can claim.
And franpa, nobody's arguing against savestates or video filters.
People use savestates for convenience and cheating reasons, the idea
has been around for ages, and it's a good one that tons of people use.
Some people use video filters because it makes things more rounded and
more real compared to sharp pixels. It's an understandable aesthetic
preference, just like AA vs jagged lines for 3D. There is no jagged
pixelation to what we see in real life. Some people don't like filters
because of CPU overhead or the unavoidable imperfections of a technique
being applied to low-res source material. It isn't hard to come up with
good reasons for why people actually prefer some things.
|
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Jun 18, 2007 10:24 pm Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
If
someone comes in your feature request forum and says that they want the
option to make a dancing chicken go across the screen when they unload
a rom, would you add it? They prefer it, Deathlike. Where do you say no
and where do you say yes? Is it less worthy than a different
interpolation method? |
You have completely ignore that ones that have been denied, such as
having RAR/7z support and adding mouse support for games that did not
originally have it (it probably could be done, but that is beyond the
scope of my argument).
|
I realize that you've denied requests. IIRC, RAR wasn't denied because
people wouldn't use it, it was denied because of licensing issues.
Mouse support like that would also get used, but might not even be
feasible. The chicken animation might not be feasible, either, but we
could use some type of echo filter instead. When we talk about some of
those sound options, we're talking about things that people have a
greater tendency to enable out of misinformation or frustration than
out of actual preference.
|
That's why if you use your brain, you would filter through this info. Otherwise, asking for clarification.
Quote: |
I
believe already implemented options that are too old for anyone to
remember how they got there still need their worth to be questioned.
You're saying that because they exist and that they don't cause any
direct problems with users, that they deserve to remain because they're
harmless. I'm trying to be more practical with someone who is not tech
savvy. If you were someone like that, wouldn't you try to dick with
foreign sound options for a sound problem right away? Instead of making
things more self-explanatory and minimizing user confusion from the
beginning by removing things that no one would miss, you blame their
wasted time as a result of user stupidity and poor correlations based
on a lack of research. The proper recourse to you is for them to
consult the doc, but the doc is humongous and may not even contain
anything about zsnes' longstanding sound issues. They'd probably have
to come on the forum anyway. |
Imposing your opinion on others is a sad state of affairs. If you are
too damn lazy to read the docs, let alone figure out how to extract
ZSNES from the zip it comes in, noone can help you there. I don't see
an issue when it has been properly troubleshooted by the user to a
reasonable degree, which is an expectation all bug reports should be
handled.
Quote: |
And
as someone who IS technologically inclined, you should also be able to
explain away misinformed preferences that something like 96khz is not
better simply because it's higher, or that slightly more efficient
compression isn't worth deviating from the simplicity of a standard.
How many more formats would you accept before saying "enough is enough
for people to have to learn." Some of these things aren't as
self-explanatory as brightness or volume. I've seen people come in here
and go "what is hell is JMA, why doesn't it work anymore with this
revision, what the hell is this, what the hell is that?" And the
combined time that gets wasted for them to inquire about it and for
others to respond isn't worth the benefit that some of these options
can claim. |
There are simply some instances, like the arguments you bring up that
sound just like the people who ask said questions. There is a point
where using the brain a little helps so much more than random blather
and complaints.
_________________
FF4 research never ends for me.
|
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Mon Jun 18, 2007 11:52 pm Post subject: |
|
Please! Stop the violence! 
Hugs all around! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jun 19, 2007 7:16 am Post subject: |
|
Agreed.
The conversation hasn't gotten moved and I get tired of arguing and
being insulted. It was my mistake to even hypothesize devs coming
together on the same project when I have no knowledge of anyone but
byuu's motivations. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Jun 19, 2007 3:12 pm Post subject: |
|
FitzRoy wrote: |
Agreed.
The conversation hasn't gotten moved and I get tired of arguing and
being insulted. It was my mistake to even hypothesize devs coming
together on the same project when I have no knowledge of anyone but
byuu's motivations. |
I don't think you even know byuu's complete motivations to begin with.
Look, it is fair enough the community at least shares its info.. which
is all one could ask for. Doing something with this info will always be
completely different story.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 19, 2007 3:19 pm Post subject: |
|
Deathlike2 wrote: |
Look, it is fair enough the community at least shares its info.. |
If only we all did ...
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Jun 19, 2007 3:24 pm Post subject: |
|
byuu wrote: |
Deathlike2 wrote: |
Look, it is fair enough the community at least shares its info.. |
If only we all did ...
|
That is human nature... or the Internets, whichever you prefer to believe. 
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jun 19, 2007 8:59 pm Post subject: |
|
For the record,
Lord Nightmare wrote: |
There's a bug in bsnes 0.21 in regards to the game 'lemmings 2':
during the intro sequence, after the screen scrolls upward (the camera
'moves downward', theres some garbage text which appears right before
it says 'Psygnosis Presents', etc. |
I'll fix it if I get bored, otherwise not.
|
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Tue Jun 19, 2007 11:53 pm Post subject: |
|
So let me get this straight:
- The primary dissent between ZSNES and BSNES was the issue of
savestates, which are difficult to create at higher accuracy levels.
This fact divided SNES emulation interests along more or less political
lines. (the situation could be compared, in a VERY broad sense, to Der
Langrisser's own plot: the matter at hand is simply a divergence of
perspective. In the case of SNES emulation, it was a problem of
accuracy; in the case of Der Langrisser, it was a problem of peace.
Kalxath and Rayguard took different approaches, where neither was
willing to compromise and so ended up in conflict with each other.
Obviously accuracy is a less vital resource than is peace, so the
conflict potential is limited. Equally, there is no actual competition
for resources, as there was in Der Langrisser, so in as much as the
opposing views are not forced to cooperate, there is little potential
for outright conflict.)
- The issue of the divergences of focus has come to a head in the
situation of the Der Langrisser patch, because it forces a choice of
practicality betweeen accuracy and speed. The one emulator that has
focused primarily on speed, ZSNES, is reaching the "end" of its
evolution from a pragmatic standpoint: emulation quality may be
"enhanced" still yet, but not actually improved due to the
timing-irrelevant focus of the emulation engine. To achieve greater
compatibility, ZSNES needs to shift its focus away from performance and
toward the correct modeling of SNES timing, as BSNES has already done.
BSNES, by contrast, is in need of the resources of the ZSNES team as
regards special chips that have been studied by ZSNES coders. ZSNES, it
would appear, has access to tools that BSNES needs for greater
compatibility. BSNES, on the other hand, has highly generalized -- very
likely unique -- coding algorithms by which to simulate hardware timing
at a very precise level. Without these algorithms, it may not be
possible for ZSNES to ever emulate Der Langrisser
effectively -- or, for that matter, some number of other games which
have yet to be translated into ZSNES' primary user base -- native
english speakers -- and maybe in the future. ZSNES is struggling for a
new sense of self, in a sense. On the other hand, BSNES is faced with
never having a "self", serving only as a response to ZSNES'
compatibility issues. If ZSNES were to take over the emerging "self"
(that is, niche) of BSNES, then BSNES would have no reason to exist and
would discontinue, as is made clear by Byuu. On the one hand, such a
choice would portray Byuu as the "Garibaldi" figure who goes back to
his farm after winning the battle, the battle here represented by the
acceptance of accurate timing as a generally pursued emulation goal.
But is that the true Byuu? The question as hand, really, is what comes
after SNES emulation. The question of what comes after the present
reality, is something that is too vague and unforseeable to be
approached without great anxiety. To move on from SNES emulation for
any of these people -- Nach, Deathlike2, Byuu, the rest of the people
so involved in SNES emuation -- would mean in a sense that a part of
one's life is at an end. These people stand apart from the masses of
people who download their games because they are called by vocation, a
sense of connectedness to a goal that is beyond situational -- it is
personal. I believe it is this personal dimension that really seperates
them into distinct political camps, which have taken the form of
seperate development efforts. If they were to work together on the
mutual goal of near perfect emulation, they might the tasks ahead of
them easier than they ever could have imagined seperately. But with the
attainment of the ideal brings closure, and until the form of the
aftermath is understood, closure is a psychological prematurity.
I'm a psychology student, in case you couldn't tell. |
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Wed Jun 20, 2007 12:25 am Post subject: |
|
And
you are one of those studenets that need to bring up their knowledge
(sans wisdom) on the field everywhere, specially when no one asked for
it or it is unrelated.
I mean, I love psychology
and all, but bringing it up with lifeless entities for just the sake of
showing up your a good psychology student is rather pointless.
_________________
_-|-_ |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jun 20, 2007 12:34 am Post subject: |
|
lordgalbalan wrote: |
I'm a psychology student, in case you couldn't tell. |
Too bad you are confusing the reality with random blather.
_________________
FF4 research never ends for me.
|
|
Cyrus Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
|
Posted: Wed Jun 20, 2007 12:44 am Post subject: |
|
Spacing
out those paragraphs wouldn't hurt. And byuu has already stated that
saving states cannot be done at all due to the way bsnes is programmed.
He didn't say hard, he said impossible. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 20, 2007 1:31 am Post subject: |
|
Well,
I believe byuu said it could possibly be done, but taking a save state
might take a while due to the amount of synchronisation needed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 20, 2007 2:34 am Post subject: |
|
lordgalbalan wrote: |
Pavlov's Dogs |
o.O
Meh, well the only issue to me is that, yes. If ZSNES were to become
nearly or as accurate as bsnes, there'd be no point for me to continue.
Who knows, maybe I'd go work on ZSNES then instead. But then the people
with slower machines would suffer as despite all the boasting in the
world, accuracy bleeds speed. You can minimize it a hell of a lot more
than I have, but it's there. I don't care how good you are at
programming. While I was upset with ZSNES initially for their lack of
accuracy ... after filling that niche, I'm no longer bothered by it
anymore.
Unfortunately, it seems that everyone and their mother wants us to be
enemies and compete against each other. Ignoring the fact that we
constantly share all of our findings, contribute code to each others'
projects, and chat and hang out all the time on IRC. The battle between
our two emulators lies solely in the heads of some of the posters here
:(
Yes, it would be nice to all work together on a single project. I'd
love to, in fact. But as we have vastly different ideas on how to reach
the same end goal (all games fully playable), it just simply can't
happen. What is neat though, is that now we get to see what happens
when each path is taken. It's kind of neat that there's no real clear
winner, isn't it?
Quote: |
Well,
I believe byuu said it could possibly be done, but taking a save state
might take a while due to the amount of synchronisation needed. |
mozz came up with a very clever solution that I believe makes
savestates possible. Basically, when starting a savestate, record all
of the bus accesses to a file, and then when loading, read out from
those buffers before continuing. In theory, it should work. In
practice, it's an unbelievable amount of work to test out an idea that
may not work in the end, as nobody has ever before tried it.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jun 20, 2007 2:39 am Post subject: |
|
Your analysis of me is waaay off.
And it's not really personal, I can walk away at any time.
Working on SNES emulation is just one of my hobbies, and in fact one of
my lesser hobbies at the moment. Although at times I'll merge outcomes
of some of my other hobbies into SNES related software.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Jun 20, 2007 10:04 am Post subject: |
|
Warning,
this is from me, somebody who does not have the in deep knowledge, but
merely applies commonsense and surface knowledge.
I think that save states in bsnes could be done. All that is needed is
to snapshot where each of the threads are and then reload that state. I
know byuu made himself a cooperative threading library, so I know that
it would be possible to add the feature to preload the thread info that
this library uses into memory, just like other things, like chip
states. And with the ability to load the chip states and the thread
data, you can do save states.
But do rest assured that I do know that byuu is not too terribly
focused on savestates, but instead wants to focus his energy on making
an accurate emulator. I respect that, but I want to say that as far as
I understand this, it is not impossible to implement savestates. But
please keep in mind that I do not have the knowledge that byuu has, he
might know a fact that really does makes my method impossible. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 20, 2007 8:25 pm Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
Agreed.
The conversation hasn't gotten moved and I get tired of arguing and
being insulted. It was my mistake to even hypothesize devs coming
together on the same project when I have no knowledge of anyone but
byuu's motivations. |
I don't think you even know byuu's complete motivations to begin with.
|
What I do know, though, is still knowledge that is greater than what I
know of ZSNES devs, and that's all I really said. You have to admit
that byuu is more publicly active than you guys, and his website has
stated goals. He's mentioned Der Langrisser many times as a favorite
game and important side project. He probably enjoys the challenge, too,
because it's a great way to learn and improve. There's a social aspect.
There's also the enjoyment that he and others can or will get from this
fun and historically significant system. Shooting for what's ideal is
simply the belief that he thinks will get him there.
byuu wrote: |
I'll fix it if I get bored, otherwise not. |
I added it to the list. .018 and .019 show a small red line on the left
side of the screen, but no garbage. .021 has this line, too, but shows
corrupt gfx, too, which disappears when the text shows up. I'll try to
see what real hardware does over the weekend.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jun 20, 2007 8:35 pm Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
FitzRoy wrote: |
Agreed.
The conversation hasn't gotten moved and I get tired of arguing and
being insulted. It was my mistake to even hypothesize devs coming
together on the same project when I have no knowledge of anyone but
byuu's motivations. |
I don't think you even know byuu's complete motivations to begin with.
|
What I do know, though, is still knowledge that is greater than what I
know of ZSNES devs, and that's all I really said.
|
Then, you simply don't know anything then. I'm not putting down byuu,
as he's very intelligent. However, it is rather a backhanded comment to
think we aren't as intelligent, if anything. Every developer has their
own particular strengths and to make such a blanket statement is
outright insulting. If you go completely by everything that is said,
then you are foolish.
Quote: |
You
have to admit that byuu is more publicly active than you guys, and his
website has stated goals. He's mentioned Der Langrisser many times as a
favorite game and important side project. He probably enjoys the
challenge, too, because it's a great way to learn and improve. There's
a social aspect. There's also the enjoyment that he and others can or
will get from this fun and historically significant system. Shooting
for what's ideal is simply the belief that he thinks will get him there. |
I would only agree that opening up information to the public is good,
but delivering the goods is actually more important the any sort of "PR
fluff" that exists.
_________________
FF4 research never ends for me.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jun 20, 2007 8:55 pm Post subject: |
|
FitzRoy wasn't insulting anyone there, he just said he knows more about byuu's motivations than he does about the other devs'. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 20, 2007 9:25 pm Post subject: |
|
I really don't see why we have to keep fighting with each other ... :(
Quote: |
Then, you simply don't know anything then. I'm not putting down byuu, as he's very intelligent. |
Nah ... I have a fairly average IQ. Never really had great grades in
school, either. I'm not really all that intelligent, I just simply have
the ability to focus on a goal and work on it for several hours a day
for several years. Anyone else who did the same could do just as much
or more than I do. But it seems most people aren't willing to invest
that much time and effort into their goals, and to take the initial
"chances" at doing things they believe to be impossible. I didn't think
I could localize SNES games or write an emulator, but I tried anyway.
But I certainly didn't start out wildly successful, either. How does that old Gandhi saying go again? "First they ignore you, then they laugh at you, then they fight you, then you win."
I don't believe knowledge that only requires substantial time
investment reflects intelligence, rather merely dedication ... and
perhaps the lack of a social life :/
Of course, I also have areas that even I can't focus on like this. In
fact, it's kind of ironic. To be able to fulfill my dreams in ROM
hacking, I need to learn Japanese, but can't. To be able to solve the
last mysteries of the SNES, I need to learn Electrical Engineering, but
I can't even get my foot in the door there.
Quote: |
I
would only agree that opening up information to the public is good, but
delivering the goods is actually more important the any sort of "PR
fluff" that exists. |
To be fair, I don't talk about most of these things as a means of PR, I
simply gain a lot of clarity while writing about stuff and reflecting.
It would seem a lot of people are interested in reading about it, so I
share.
Even still, it isn't as if I don't (eventually) deliver, so ...
Last edited by byuu on Wed Jun 20, 2007 9:27 pm; edited 1 time in total
|
|
Stifu Regular

Joined: 10 Dec 2004
Posts: 307
|
Posted: Wed Jun 20, 2007 9:27 pm Post subject: |
|
byuu wrote: |
Never really had great grades in school, either. |
Neither did Einstein. :p
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jun 20, 2007 9:36 pm Post subject: |
|
byuu wrote: |
Quote: |
I
would only agree that opening up information to the public is good, but
delivering the goods is actually more important the any sort of "PR
fluff" that exists. |
To be fair, I don't talk about most of these things as a means of PR, I
simply gain a lot of clarity while writing about stuff and reflecting.
It would seem a lot of people are interested in reading about it, so I
share.
Even still, it isn't as if I don't (eventually) deliver, so ...
|
My point was explicitly that we shouldn't totally read everything as
gospel. I'm not saying insight was gospel or anything.
I haven't actually questioned you results and you have delivered, so
don't worry about it. I'm just talking about the number of projects
that say they'll get something done.. but fail to deliver. It happens,
and that's just my stance on the issue.
Stifu wrote: |
byuu wrote: |
Never really had great grades in school, either. |
Neither did Einstein. :p
|
Gates didn't finish Harvard either 
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 20, 2007 9:52 pm Post subject: |
|
Deathlike2 wrote: |
Then, you simply don't know anything then. I'm not putting down byuu,
as he's very intelligent. However, it is rather a backhanded comment to
think we aren't as intelligent, if anything. Every developer has their
own particular strengths and to make such a blanket statement is
outright insulting. If you go completely by everything that is said,
then you are foolish. |
When did I ever
say that I outright believed you guys were less intelligent than byuu?
When? Every single one of you ZSNES devs ganged up on ME and wrote
stupid libel about me out of sheer anger. Then I decided to inform you
that you are not universally intelligent simply because you can code.
Everyone is smart at some things and stupid at others. Everyone,
including myself. You have zero tolerance for users less
technologically savvy than you and you use your forum more to bash
newbs than to inform them or take constructive criticism. Get a clue
already so this thread can move on.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jun 20, 2007 9:56 pm Post subject: |
|
Quote: |
I'm
just talking about the number of projects that say they'll get
something done.. but fail to deliver. It happens, and that's just my
stance on the issue. |
Ah ok, misunderstood, sorry.
A good way to measure the expertise of someone making a claim is to
look at their optimism. If they're too optimistic about the outcome,
chances are it's not going to happen.
|
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Wed Jun 20, 2007 10:20 pm Post subject: |
|
Quote: |
But it seems most people aren't willing to invest that much time and
effort into their goals, and to take the initial "chances" at doing
things they believe to be impossible.
|
I see it as those who would pursue a goal needing the support of those
who would equate their goals with the pursuer's. The pursuit of the
goal removes oneself from the struggle to survive, to do the menial
things in life. Someone must pick up the slack, just as Der Langrisser's Erwin and Leon have supporting casts.
Quote: |
Yes, it would be nice to all work together on a single project. I'd
love to, in fact. But as we have vastly different ideas on how to reach
the same end goal (all games fully playable), it just simply can't
happen. What is neat though, is that now we get to see what happens
when each path is taken. It's kind of neat that there's no real clear
winner, isn't it?
|
Correct... but why not agree on an independent path that overcomes the
difficulties posed to either side? Are your streams of thought simply
too different... or are there some thoughts within either stream that
obstruct the otherwise free flow...?
Quote: |
Of course, I also have areas that even I can't focus on like this. In
fact, it's kind of ironic. To be able to fulfill my dreams in ROM
hacking, I need to learn Japanese, but can't. To be able to solve the
last mysteries of the SNES, I need to learn Electrical Engineering, but
I can't even get my foot in the door there.
|
Indeed, the ZSNES "side" seems to have everything you don't. A union of
the projects is needless--however, cooperation between its members and
the BSNES side seems advantageous in light of the mutual goals held by
either side. The question is whether either side can correctly
scrutenize the prejudices that would blind it to the other side's PoV.
If the PoVs were mutually respected, then a free flow of energy would
be capable between either. The allies of the ZSNES side could assist
the allies of the BSNES side, and we might see an uptick in the rate of
SNES translations and emulation evolutions.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jun 20, 2007 10:24 pm Post subject: |
|
FitzRoy wrote: |
Deathlike2 wrote: |
Then, you simply don't know anything then. I'm not putting down byuu,
as he's very intelligent. However, it is rather a backhanded comment to
think we aren't as intelligent, if anything. Every developer has their
own particular strengths and to make such a blanket statement is
outright insulting. If you go completely by everything that is said,
then you are foolish. |
When did I ever say that I outright believed you guys were less intelligent than byuu? When?
|
Quote: |
What I do know, though, is still knowledge that is greater than what I know of ZSNES devs, and that's all I really said. |
Wording is important, as that is a poor choice of stating that you've
heard lots more stuff from byuu, but it also can be interpreted as
"byuu is the ultimate source of SNES info" or potentially "byuu knows
more than ZSNES devs about the SNES".
Quote: |
Every single one of you ZSNES devs ganged up on ME and wrote stupid libel about me out of sheer anger. |
It was to point out that you completely are drawing conclusion out of
thin air and in some instances you reall have no idea what you are talking about.
Quote: |
Then I decided to inform you that you are not universally intelligent simply because you can code. |
Ok byuu, give up now. The jig is up!
Seriously though, if you had any respect for the opinions of others, you wouldn't be met with such hostility.
Quote: |
You
have zero tolerance for users less technologically savvy than you and
you use your forum more to bash newbs than to inform them or take
constructive criticism. Get a clue already so this thread can move on. |
That actually isn't true. There is a reasonable expectation for people
when they post here. Depending on how one asks a question, may one get
the answer they are looking for. If they do their proper research, a
better question would be asked. That is a critical part of being a good
forumer, no matter how good or bad you are with software. If you don't
understand that, then there really is nothing more to discuss.
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Wed Jun 20, 2007 10:25 pm; edited 1 time in total
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jun 20, 2007 10:25 pm Post subject: |
|
lordgalbalan wrote: |
however, cooperation between its members and the BSNES side seems advantageous |
Have you even remotely read up on either project?
We work together all the time.
If you check changelogs, you'll see byuu helped with a lot of info on
ZSNES, and that I submitted a lot of code and info to bsnes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Wed Jun 20, 2007 10:43 pm Post subject: |
|
Nach wrote: |
lordgalbalan wrote: |
however, cooperation between its members and the BSNES side seems advantageous |
Have you even remotely read up on either project?
We work together all the time.
If you check changelogs, you'll see byuu helped with a lot of info on
ZSNES, and that I submitted a lot of code and info to bsnes.
|
I'm aware of that. But if that is the case, then why isn't BSNES more
compatible? (does Byuu have access to your chip research, IOW?)
I also intended to suggest a general bridge between the political lines
that seem to divide emulation-related efforts (translations included)
in general. For example, Byuu says he needs translators to translate
games. I say this from my own observation, that in general people who
are further left on the political spectrum, as Byuu seems to be, tend
to have greater ignorance of cultural peculiarities because they are
inclined to transcend them in favor of a non-culture specific
viewpoint. A person who is closer to the right, by contrast, emphasizes
the cultural distinctions between individuals of different ethnicities
and is more aware of their presence than a person farther left on the
poltical spectrum. They will be capable of translating ethnic details
in Japanese easier than a person farther left, who would probably be
confused. (I know because I've tried translating game scripts myself,
and failed miserably.) I'm not entirely sure how this is directly
relevant to the discussion at hand, however.... Perhaps what I am
trying to say is, Byuu's difficulty finding translation help and the
split between ZSNES and BSNES appear to me to be intrinsically linked.
Were the ZSNES and BSNES teams closer, there would probably be greater
intersection of interests between individuals who are related to either
team by proxy (translation enthusiasts, for example), leading to a
greater collective convergence of efforts.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jun 20, 2007 11:03 pm Post subject: |
|
Deathlike2 wrote: |
FitzRoy wrote: |
Deathlike2 wrote: |
Then, you simply don't know anything then. I'm not putting down byuu,
as he's very intelligent. However, it is rather a backhanded comment to
think we aren't as intelligent, if anything. Every developer has their
own particular strengths and to make such a blanket statement is
outright insulting. If you go completely by everything that is said,
then you are foolish. |
When did I ever say that I outright believed you guys were less intelligent than byuu? When?
|
Quote: |
What I do know, though, is still knowledge that is greater than what I know of ZSNES devs, and that's all I really said. |
Wording is important, as that is a poor choice of stating that you've
heard lots more stuff from byuu, but it also can be interpreted as
"byuu is the ultimate source of SNES info" or potentially "byuu knows
more than ZSNES devs about the SNES".
|
You're kidding, right? Go back and read what that statement was
replying to. It was a direct reply to the subject of my knowledge of
emu authors' motivations. It is not ambiguous and does not translate to
what you've written AT ALL.
Quote: |
Ok byuu, give up now. The jig is up! |
What are you trying to say? That because of marketers, musicians,
comedians, and writers, programmers should just give up? I didn't say
it, you did.
Quote: |
Seriously though, if you had any respect for the opinions of others, you wouldn't be met with such hostility. |
This is dmog-like. You are a major hypocrite. Anybody want to go back
and count how many times Deathlike here has been disrespectful when
polite explanations or reasoning could have prevailed?
Quote: |
That
actually isn't true. There is a reasonable expectation for people when
they post here. Depending on how one asks a question, may one get the
answer they are looking for. If they do their proper research, a better
question would be asked. That is a critical part of being a good
forumer, no matter how good or bad you are with software. If you don't
understand that, then there really is nothing more to discuss. |
Regurgitation. Your expectations are outrageous, and when I questioned
those sound options politely a few years ago before bsnes existed, I
got a canned response and the thread was deleted. But keep doing things
the way they are. I can't stop you.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jun 20, 2007 11:34 pm Post subject: |
|
FitzRoy wrote: |
This
is dmog-like. You are a major hypocrite. Anybody want to go back and
count how many times Deathlike here has been disrespectful when polite
explanations or reasoning could have prevailed? |
If you choose to ignore all threads with reasonable responses, then I guess I must be as awful as you suggest.
Quote: |
Quote: |
That
actually isn't true. There is a reasonable expectation for people when
they post here. Depending on how one asks a question, may one get the
answer they are looking for. If they do their proper research, a better
question would be asked. That is a critical part of being a good
forumer, no matter how good or bad you are with software. If you don't
understand that, then there really is nothing more to discuss. |
Regurgitation. Your expectations are outrageous, and when I questioned
those sound options politely a few years ago before bsnes existed, I
got a canned response and the thread was deleted. But keep doing things
the way they are. I can't stop you.
|
Dude, those options are there because they do. They don't hurt ZSNES or
the user in any way. Unless they completely fuck with the emulation (as
in the game goes haywire, screen goes to black, etc.), there is no
reason to get rid of them. Since we are using blargg's core, the
options are obsolete, so why the hell are you bringing this back up?
_________________
FF4 research never ends for me.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Jun 21, 2007 3:57 am Post subject: |
|
lordgalbalan wrote: |
Nach wrote: |
lordgalbalan wrote: |
however, cooperation between its members and the BSNES side seems advantageous |
Have you even remotely read up on either project?
We work together all the time.
If you check changelogs, you'll see byuu helped with a lot of info on
ZSNES, and that I submitted a lot of code and info to bsnes.
|
I'm aware of that. But if that is the case, then why isn't BSNES more
compatible? (does Byuu have access to your chip research, IOW?)
|
BSNES is devoid of the hacks that were used to make games just run.
Compatibility is a loaded word in snes emulation, just because a game
runs doesn't mean ZSNES is emulating it correctly.
the last couple of years ZSNES and SNES9X have been working hard to
reduce the amount of hacks used, and byuu is dedicated to accurate
emulation from the start.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 21, 2007 7:06 am Post subject: |
|
I
think he means compatible with special chips. Which is because I'm not
writing an emulator for every SNES cartridge PCB, instead I'm writing
an emulator for the SNES hardware and cartridge mappers. In regards to
that, I have one single known bug that all SNES emulators without hacks
share. Maybe two now when FitzRoy looks at Lemmings 2.
I added a few special chips because it was easy and quick. As to why I
don't have more is simple: I don't port more from ZSNES and SNES9x, as
I'm really not interested in spending two weeks to get an obscure
Gundam or Hanafuda game working correctly. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 21, 2007 7:41 am Post subject: |
|
Regarding
the PCB stuff: after dumping a lot more games since the MAXI/SHVC
pitfall example, it might interest you to know that I've come across
instances of the same game being on PCBs with different memory address
decoder chips (different PCB codes as a result). I've also come across
the same game existing on one ROM chip or spread across multiple ROM
chips (different PCB codes as a result). The fact that I didn't really
have all that many duplicates, but still found variances on them, makes
me think that variability in PCB codes per game could be anywhere from
1 to 5. Although it is possible to document at least one legitimate
code or every possible code
for each game (now that we've deciphered the codes as they correspond
to the PCB and game attributes), there's no chance in hell that we're
going to be able to document the actually existing manufacturing
variations of each game. Because with no records and so many possible
variations, no matter how many historically legitimate codes we
document, we'll never be able to assume complete data and we'll never
know what we missed.
Anyway, I don't know how this info affects your plans for a PCB database, but I thought you should know. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 21, 2007 8:15 am Post subject: |
|
I honestly doubt we'll ever document all the SNES cart PCBs.
Emulators would have to unify and refuse to play games without valid
PCBs to get enough people interested to open up their carts and verify
for us (and then people would just make shit up). Sure, we know Chrono
Trigger's PCB code ... but how about Jumbo Ozaki no Hole in One's? Do
you think anyone will ever
donate that one (other than simply to spite me for this one specific
example, of course) ? What about for the crazy expensive games like
FEoEZ: SJnS (heheh, send it to me and I'll open it with my game bit) ?
Nach's idea to embed this into the ROM itself is the best way to do it,
as it takes the maintainence of a database out of the equation ... but
we still don't have any formalized specs out there to go by.
I also passionately hate ROM headers (as they stand, they're absolutely
fucking worthless to be in distributed ROMs), so it kind of sucks to be
supporting their revival. Hell, if I had the clout of ZSNES, I'd have
killed off headers years ago by refusing to recognize games with them
-- or better, by popping up a dialog stating the ROM needed to be
converted to play with a yes/no box.
Anyway, I would say: first, use a generic HiROM / LoROM mapper. If we
have one PCB, use that. If we have multiple PCBs, use the more standard
one (eg use SHVC instead of MAXI), or just pick. Document it in a
database somewhere so that it's not forgotten. It really doesn't matter
too much. If the game wasn't compatible with the mapper, they wouldn't
have used it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jun 21, 2007 9:44 am Post subject: |
|
byuu wrote: |
I honestly doubt we'll ever document all the SNES cart PCBs.
Emulators would have to unify and refuse to play games without valid
PCBs to get enough people interested to open up their carts and verify
for us (and then people would just make shit up). Sure, we know Chrono
Trigger's PCB code ... but how about Jumbo Ozaki no Hole in One's? Do
you think anyone will ever
donate that one (other than simply to spite me for this one specific
example, of course) ? What about for the crazy expensive games like
FEoEZ: SJnS (heheh, send it to me and I'll open it with my game bit) ? |
Yeah, pretty much, although there are people who are being very
thorough such as Yakushi~Kabuto and myself. It is a bit of a pipe dream
to get every one, but it's definitely not impossible. Although it costs
money to acquire the carts, you generally average the same amount
selling them back after verification. The hard part is all the manual
labor involved. Unscrewing, cleaning, and dumping 170 carts took me
about a month and I don't look forward to doing it again. Trying to win
ebay auctions can be frustrating, too, and you are limited in the sense
that you want to buy lots but as you go the likelihood that the lots
contain too many games that you've already verified increases. You have
to minimize dupes or it's a quick path to either more time listing
separate auctions or selling dupe auctions which no one wants and you
lose money.
byuu wrote: |
I
also passionately hate ROM headers (as they stand, they're absolutely
fucking worthless to be in distributed ROMs), so it kind of sucks to be
supporting their revival. Hell, if I had the clout of ZSNES, I'd have
killed off headers years ago by refusing to recognize games with them
-- or better, by popping up a dialog stating the ROM needed to be
converted to play with a yes/no box. |
I can't stand them either the more that I learn about them. I prefer
DATs for verifying my roms, too, rather than GoodTools, but DATs need
headerless roms (or some stupid workaround in ClrMamePro which I refuse
to use). NES actually has it a lot worse than SNES, though, because
they're actually dependent on them for emulation. Discussions to dump
iNES headers in favor of a database + UNIF support haven't really gone
anywhere so far. NES emu authors don't seem convinced that there needs
to be a change simply because the current method is in place and works
"good enough." I also think they're scared to lose their userbase to
other emus if any of them do it, because Cowering's tool has come to
dictate distribution and wouldn't change its methods unless most
emulators were to change. It's a real dependency mess.
byuu wrote: |
Anyway,
I would say: first, use a generic HiROM / LoROM mapper. If we have one
PCB, use that. If we have multiple PCBs, use the more standard one (eg
use SHVC instead of MAXI), or just pick. Document it in a database
somewhere so that it's not forgotten. It really doesn't matter too
much. If the game wasn't compatible with the mapper, they wouldn't have
used it. |
I've made an SNES PCB guide with YK, with which anyone can calculate
possible codes. For historically legitimate codes, we still document
them just for shits. No-Intro uses a wiki, but I prefer an offsite text
file that I update continuously. I'll have a DAT website soon which
should hopefully deliver all this info in my format to anyone who wants
it.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Jun 21, 2007 9:21 pm Post subject: |
|
byuu:
I would love to do away with headers if there was an easy transition
for people used to the way roms work now. That is my only concern.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jun 21, 2007 10:03 pm Post subject: |
|
pagefault,
the best solution would be to pop up a dialog asking the user if its ok
to remove the headers, same for deinterleaving ROMs. Super Sleuth does
this with overdumps. I was (barely) surprised to learn that MMX2 was an
overdump in Cowering's set -- SS asks you, then fixes it. It wouldn't
affect the game in any other emulators. We would need the clout of
ZSNES to convince idiots like Cowering to follow suit and remove
headers from his ROM DB.
The only issue I have
with doing that right now though is that it's the only really good
solution for allowing users to define PCB IDs (especially for fan
translations, hacks and PD ROMs) -- stick them in the header. But the
problem there is that without a database / ROM auditing tool, people
will inevitably end up with fake / invalid PCB IDs in headers, and
we'll have new bugs reports and problems to deal with.
It's a real mess. Unfortunately, back in 1995-1996, the only concern
was getting games running. Preservation of things like cartridge layout
wasn't even considered. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Jun 22, 2007 12:17 pm Post subject: |
|
I'd
make it a one time question or some type of option. I have a directory
of ROMs that are headered for play on my copier that I also play in
ZSNES. I don't need to be harassed every time I decided to play a
headered ROM in ZSNES that I DON'T want removed. That would be a great
way for me to quit using said emulator. 
Forcing your ideals is probably not a good idea. A gentle tug in the right direction though can go a long way.
_________________
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. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jun 22, 2007 1:22 pm Post subject: |
|
I'd recommend a simple Yes/No popup with a 'Never ask me this again' option that can be reset at any time in the configuration. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Jun 22, 2007 1:39 pm Post subject: |
|
Don't do the "Never ask me this again" checkbox.
Users with copiers can simply change the source. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 22, 2007 2:32 pm Post subject: |
|
Quote: |
I
have a directory of ROMs that are headered for play on my copier that I
also play in ZSNES. I don't need to be harassed every time I decided to
play a headered ROM in ZSNES that I DON'T want removed. That would be a
great way for me to quit using said emulator. |
I think we'll somehow manage to continue on without all three of you
that use both emulators and copiers with the same ROMs.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Jun 22, 2007 4:47 pm Post subject: |
|
Also, how hard is it to keep two copies of a rom?
Btw, byuu, I think you may have missed my previous post on the previous page. |
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Fri Jun 22, 2007 8:44 pm Post subject: |
|
Byuu:
As regards your desires to get more games translated, one solution may
be a team-up between yourself and an existing translation team. RPGOne,
Aeon Genesis, and others all have their distinctive philosophies, one
of which may be compatible with your own. I would get in touch with
them. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Jun 22, 2007 8:46 pm Post subject: |
|
byuu:
I would like to come to an agreement with all the active emulator
authors over this so we have compatibility over the spectrum. I have no
problem asking people once to remove the header. They can always use
NSRT I guess to add it again. The other question is how to do it
without the headers, I guess I would have to adopt your DB, which isn't
really a problem unless it gets outdated with the emulator. I don't
want it to turn out like N64 where you had INI files coming out every
week for games. Perhaps we can automate this by having the program grab
the latest DB.
I don't care if the DB is in a file
or in the rom itself, I just would like some solution, so we don't drag
this on like HD-DVD vs Bluray.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 23, 2007 12:11 pm Post subject: |
|
I'll
be taking a break from bsnes for a little while. No, I don't know how
long. Hopefully only a few weeks at the most. I am working on a side
project at the moment, the details of which are not public at this
time. Sorry for the inconvenience.
pagefault wrote: |
byuu:
I would like to come to an agreement with all the active emulator
authors over this so we have compatibility over the spectrum. I have no
problem asking people once to remove the header. They can always use
NSRT I guess to add it again. The other question is how to do it
without the headers, I guess I would have to adopt your DB, which isn't
really a problem unless it gets outdated with the emulator. I don't
want it to turn out like N64 where you had INI files coming out every
week for games. Perhaps we can automate this by having the program grab
the latest DB. |
I think Nach will murder you if you ask him about a DB in ZSNES ... he
has good points as well, but I still feel a DB is necessary for now
until the majority of ROMs out there have PCB IDs in them. That is,
unless, ZSNES is willing to break all of the games like Ys 3 and the
BSC games so that the majority will start updating their ROMs to
whatever new format we come up with.
I'm not too
picky, I just don't want a lot of useless crap in the header. All I
really need is the PCB ID. The rest I can figure out from analyzing the
file itself.
I also don't want to skimp on the PCB ID string. Put the - characters
in there. We have 512 bytes, we don't have to worry about two extra -
in the string. Also add the SHVC, as there are also MAXI and BSC
variants that we know of. So, eg:
db "SHVC-1A3M-20",0 is what I want in the header.
That will tell me the exact memory mapper, RAM size, and special chips
present. fsize() will tell me the ROM size (and I mirror up from
there). Everything else is irrelevant.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Jun 23, 2007 4:28 pm Post subject: |
|
Man,
after the amount of time you spent working on libui and its application
in bsnes I'm sure you could use some time away from it - be looking
forward to learning the details of this side project. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Jun 23, 2007 9:42 pm Post subject: |
|
byuu wrote: |
I think Nach will murder you if you ask him about a DB in ZSNES ... he
has good points as well, but I still feel a DB is necessary for now
until the majority of ROMs out there have PCB IDs in them. That is,
unless, ZSNES is willing to break all of the games like Ys 3 and the
BSC games so that the majority will start updating their ROMs to
whatever new format we come up with. |
I would like to do something, I am tired of discussing different ways
of doing it, it should just be done, like when interleaved rom support
was dropped. I would rather have authentic roms than some hacker format.
_________________
Watering ur plants.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jun 24, 2007 12:43 am Post subject: |
|
byuu wrote: |
Nach's idea to embed this into the ROM itself is the best way to do it,
as it takes the maintainence of a database out of the equation ... but
we still don't have any formalized specs out there to go by.
|
The maintenance issues with a database can be reduced and offloaded if you made the database file:
a. a universal file/format used by all emulators
b. text based so it is readable to and modifiable by anyone.
With a database, you can't buy that kind of simplicity and transparency
to end-users. We don't need another subjectively defined format being
attached to original data and requiring people to use secondary
programs like NSRT and GoodTools to get their roms working.
All you would have to do is be willing to host/receive or link to a
sporadically updated database file and have them available somewhere
for people to download. You don't necessarily have to be the one that
maintains it. Dumpers could do this. An emulator version can include
the latest db file at the time of that version's release. It should not
be very difficult for users to add custom entries in the event that
they need to do so.The whole infinitely creatable content thing is the
one argument against a database that might have some merit. I don't
know enough about patching in order to refute it, but is there an
emulator-oriented patch format that doesn't rely on headers and doesn't
permanently modify data (maintaining db detection)? I dunno, what would
be a creative solution for this that does not involve headers?
After 1000 verifications, it's looking like we won't be making many
corrections to the actual data part of what we consider good right now
(thanks to SNES internal checksums). Everything has panned out so far,
meaning we won't have to do much maintenance-wise other than the PCB
stuff. Because of this, anything not yet in the database can fallback
to working under the other detection method as it does currently. That
wouldn't be so bad, would it?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jun 24, 2007 10:14 am Post subject: |
|
I agree with fitzroy
A simple database design that is maintained elsewhere,
This way there could be a database for hacks, translations, verified dumps, a mix of everything
As long as the DB format is correct the games should work. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Jun 25, 2007 12:18 pm Post subject: |
|
creaothceann wrote: |
Don't do the "Never ask me this again" checkbox.
Users with copiers can simply change the source.  |
By that logic, we don't even need to add any new features at all.
Everyone can just modify the sources of all their open source emulators
to make the emulator work to their preferences! Yes, that's a fabulous
idea. Obviously everyone has programming abilities with the language in
question and knowledge enough to handle it easily. 
_________________
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.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jun 25, 2007 1:30 pm Post subject: |
|
Well, you have to weigh your options. 
Forcing the users to either remove the header or to be nagged has
(IMHO) more weight than the needs of very few "power user" individuals.
Besides, you can always keep two versions of the ROM. It's not as if
savestates etc. are incompatible.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jun 25, 2007 2:32 pm Post subject: |
|
I
agree; when I first suggested the option I hadn't really thought it
through. Since, in this case, the idea is to urge people to remove
their headers, perhaps just an 'Always remove the header' checkbox. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 25, 2007 3:11 pm Post subject: |
|
There's
a major gap there, though. Fan translations won't be in this database
(nor should they be). However, we need a way to identify their memory
maps to get them to run.
We either need two files, one to specify the PCB code, or we need a header.
The two file thing would be really neat, though. It has a lot of
potential. Imagine being able to create a custom .map file that lets
you create your own mapper. Would allow 32mbit HiROM games to be
expanded further. Obviously you'd be screwed when it comes to running
it on real hardware. The granularity of the mapping could also cause
different emulators a lot of trouble. bsnes has a granularity limit of
256 bytes. ZSNES looks like 64k bytes from what I've seen of their
memory mapper, but I admit to only having looked at the S-DD1 stuff, so
I could be mistaken. |
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Mon Jun 25, 2007 4:21 pm Post subject: |
|
byuu,
have you ever come across in your travels the motorola S-record format
or the Intel IHX (http://en.wikipedia.org/wiki/Intel_HEX) format?
You may already know this, but when creating the binary image for
programming a PROM, EPROM, whatever, you intentionally lose the CPU
address location information because the memory mapper (CPU address
decoder) takes care of that.
Really it should be possible to take the IHX file from an assembler and
run it in an emulator without even having a mapper come into play. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jun 25, 2007 8:34 pm Post subject: |
|
In
the current SVN code we can only map as small as 32kb, thus causing a
problem for some BS games. But in the new memory map code it will be
able to pretty much be able to allocate in any power of 2. Still
haven't really much thought into it yet though.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jun 25, 2007 10:28 pm Post subject: |
|
Well the problem is that the more granular you get, the more RAM you eat.
256 bytes means my block lookup table is 65,536 entries long (256kb RAM on x86, 512kb RAM on amd64).
128 = 512kb
64 = 1mb
32 = 2mb
16 = 4mb
8 = 8mb
4 = 16mb
2 = 32mb
1 = 64mb
Yow, sixty-four megabytes to allow mapping to every single byte. At
that point, it'd be better to just write some crazy black magic code
that does all kinds of range testing and table iterations to cut back
on memory usage. Wouldn't actually be too
terrible, you'd only need 4-8 rules for most carts, and those rules
would only need two logic tests each. But the lookup table is so much
faster ...
The smallest region I've ever seen was
the 768-byte SuperFX GSU region. So 256-bytes is enough to break that
apart just fine. I don't see a reason to get more precise than that,
unless you just want to do it for the technical challenge. In which
case, I say go for it :D |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jun 25, 2007 11:02 pm Post subject: |
|
Sorry
for being late with this, but I've confirmed the Lemmings 2 bug. No red
line or anything shows up on the real hardware. As I mentioned before,
.020 has added garbage, but all bsnes versions had a visible anomaly
that tetsuo and I missed in our testing (sorry). I guess it's good
news, though, that it's not a regression from who knows when. |
|
tcaudilllg Rookie
Joined: 06 Sep 2004
Posts: 33
Location: Middletown, OH
|
Posted: Thu Jun 28, 2007 11:12 pm Post subject: |
|
I
agree with Byuu that there don't seem to be any serious disparities
between BSNES and ZSNES. They are simply moving in perpendicular
directions to each other: not against each other but not with each
other, either. There is certainly room for greater cooperation;
however, I should note that there appear to be both reform-oriented and
liberal elements on the BSNES team. Perhaps if Byuu sought to seperate
his dealings with BSNES' reformative element from his interactions with
the paleo-conservative/libertarian elements which lead ZSNES, there
could be more cooperation between the camps.
There
is a book out called "Eight Ways to Run the Country: A New and
Revealing Look at Left and Right" that speculates the existence of
eight fundamental opinions. My own (independent) research has verified
the existence of these fundamentals, which pair into four cohesive
domains of contextual understanding. From what I can discern, Der
Langrisser is the story of one man's interaction with these divergent
opinions.
Rather than be dominated by our pride as either the Descendents of
Light and the Empire were, we should seek avenues of cooperation while
mitigating our confrontations.
That said, SNES emulation is looking quite healthy. |
|
Joe Camacho Devil's Advocate

Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
|
Posted: Fri Jun 29, 2007 12:25 am Post subject: |
|
lordgalbalan wrote: |
I
agree with Byuu that there don't seem to be any serious disparities
between BSNES and ZSNES. They are simply moving in perpendicular
directions to each other: not against each other but not with each
other, either. There is certainly room for greater cooperation;
however, I should note that there appear to be both reform-oriented and
liberal elements on the BSNES team. Perhaps if Byuu sought to seperate
his dealings with BSNES' reformative element from his interactions with
the paleo-conservative/libertarian elements which lead ZSNES, there
could be more cooperation between the camps.
There is a book out called "Eight Ways to Run the Country: A New and
Revealing Look at Left and Right" that speculates the existence of
eight fundamental opinions. My own (independent) research has verified
the existence of these fundamentals, which pair into four cohesive
domains of contextual understanding. From what I can discern, Der
Langrisser is the story of one man's interaction with these divergent
opinions.
Rather than be dominated by our pride as either the Descendents of
Light and the Empire were, we should seek avenues of cooperation while
mitigating our confrontations.
That said, SNES emulation is looking quite healthy. |
Dude, less pseudo-psychology posts, more emulation progress and good stuff from Bsnes, ok?
_________________
*Sometimes I edit my posts just to correct mistakes.
I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Jun 29, 2007 5:04 am Post subject: |
|
lordgalbalan wrote: |
the paleo-conservative/libertarian elements which lead ZSNES |

_________________
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
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jun 29, 2007 7:26 pm Post subject: |
|
That
should probably go in the Nestopia thread, tetsuo, but I'm glad they're
doing something like this. Per-rom xml + database for all licensed,
commercially released data FTW. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jun 29, 2007 9:04 pm Post subject: |
|
I
don't like the XML idea, it's too complicated for most to edit, and I
definitely don't like the idea of multiple files ... even if they're
inside ZIPs. That's no good for fan translations and soft patching.
Realistically, we only need a ten-character PCB ID code. We really
don't need XML parsers and SHA-1 hash verification routines (ala the
bannister.org thread linked here) to support accurate SNES memory maps. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jun 29, 2007 9:49 pm Post subject: |
|
The
NES is pretty unique with the CHR and PRG rom thing. Some games even
have more than two. Is there a reasonable order for combining them?
Otherwise, the big problem with not separating them is that we have a
combined file checksum entries in DAT files, and that's really no way
to be documenting or storing this data. Perhaps for the same reason
that you split up processes for the sake of closeness, we also seek the
most accurate thing for archival. Can you explain the patching problem
in more detail? Why is it so hard to patch when there's more than one
file? There's no new format or creative workaround that could solve
this?
Also, what's your take on how MAME does it?
Don't they split up the files as well, or are you drawing a discrepancy
between three and 10+ rom chips? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jun 30, 2007 3:16 am Post subject: |
|
creaothceann wrote: |
lordgalbalan wrote: |
the paleo-conservative/libertarian elements which lead ZSNES |
|
Dude, the guy is either a clown/troll or he's having a schizophrenic breakdown*. What he wrote made absolutely no sense.
Look! I can type completely nonsensical sentences with big words too!
The
fundamentality of Zsnes in the perpendicularity of emulation is one
which absolve all distribution of sameness. In that sense, it does not
only comply with the gaussian vector setups, but go ahead of it. With
that said I think bsnes's multi-threading greatly promote opposing
divergences of single process data redundancies
*edit: I forgot to add postbot. I guess that's possible too.
Last edited by Snark on Sat Jun 30, 2007 6:14 am; edited 1 time in total
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Jun 30, 2007 8:22 am Post subject: |
|
My opinion is that the added XML file is the perfect solution
Why?
The original rom remains unchanged, thus not breaking backwards
compatibility, retaining full support for any and every patch ever
released
Multiple files in one rom adds the option to add patches directly to
the zip with their relevant infomation in the XML, this way an emulator
could pop up an options screen asking you which of these patches you
would like to have applied on the fly.
finally, by using XML hackers/translators could experiment and could
possible create better patches or bigger translations.
Of course this could all be unnecessary if you already have an even simpler system in the works? |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Sat Jun 30, 2007 5:55 pm Post subject: |
|
byuu wrote: |
The
two file thing would be really neat, though. It has a lot of potential.
Imagine being able to create a custom .map file that lets you create
your own mapper. Would allow 32mbit HiROM games to be expanded further.
Obviously you'd be screwed when it comes to running it on real hardware. |
Now, I don't really feel strongly about this or anything, so don't take
this the wrong way. But whenever people talk about doing "more" with
SNES games until they will not run on original hardware anymore, I
always wonder, what's the point? If you're going to remove limits, why
not just go all the way and make it for the PC, and be rid of all those
strict artificial limits altogether? Because artificial is what they
become, when it's not a game for the SNES anymore. If you want
portability there are a myriad of ways to achieve that, right?
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jun 30, 2007 7:10 pm Post subject: |
|
Quote: |
But
whenever people talk about doing "more" with SNES games until they will
not run on original hardware anymore, I always wonder, what's the
point? If you're going to remove limits, why not just go all the way
and make it for the PC, and be rid of all those strict artificial
limits altogether? |
Because adding cool features to existing classics like FF3 and CT is a
lot easier than porting the entire games over to the PC. It may also be
necessary for the less skilled ROM hackers who have already hit size
limits on ROMs, yet need more space for their translations / hacks and
aren't adept enough to write better compression algorithms for the
games.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Sat Jun 30, 2007 8:28 pm Post subject: |
|
Ah, right. I was looking at it from the perspective of making games from scratch, I hadn't even thought of that.
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 01, 2007 4:41 am Post subject: |
|
Hi, I'd appreciate if I could have some testing done on a special build for me.
http://nsrt.edgeemu.com/bsnes021n.zip
First off, caveats:
May not work in Windows 2000
Might be slower than bsnes 0.021
Does not have icon or joypad image appear inside bsnes.
Pros:
More encompassing DB system.
Please test to see if any games now give issues which didn't under
0.021 or see if anything which did load incorrectly under 0.021 is now
fixed.
Other issues do not concern me.
Games to test:
90 Minutes - European Prime Goal
ABC Monday Night Football
Actraiser
Air Management
Battle Dodge Ball
Derby Stallion 96
Dezaemon
Equinox
Fire Emblem - Thracia 776
Gemfire
Killer Instinct
RPG Tsukuru 2
Sound Novel Tsukuru
Ys III - Wanderers from Ys (U & J)
Any of course any other games you feel like testing.
Please play into each game and if applicable get to a save point and
save, then load from scratch and make sure save is working.
Please remark on issues where game works in one version but not the other. Post CRC32 of game when doing so.
If you tested one of the above games thoroughly and no problems were found, post about that too.
More details will be furnished once more test results are in.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Lex New Member
Joined: 19 Oct 2006
Posts: 2
Location: Waterloo, Ontario, Canada
|
Posted: Sun Jul 01, 2007 10:40 pm Post subject: |
|
I
just tested Actraiser in bsnes 0.021n in Windows XP. I was able to save
my game, restart the emulator, and load my saved data properly. CRC32
according to the console window behind the emulator: eac3358d Grinvader confirmed that I was using a valid Actraiser (U) (1.0) ROM. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jul 03, 2007 2:18 am Post subject: |
|
Everything
on that list works fine for me, but I have noticed that in some cases,
the pcb code is listed but the mapper is listed as "not found" and it
is falling back to the old method, such as Killer Instinct. I'm just
guessing this is to test if fallback is working? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jul 03, 2007 2:37 am Post subject: |
|
FitzRoy wrote: |
Everything
on that list works fine for me, but I have noticed that in some cases,
the pcb code is listed but the mapper is listed as "not found" and it
is falling back to the old method, such as Killer Instinct. I'm just
guessing this is to test if fallback is working? |
It's to test my fallback code yes, but the main point is to test my PCB
set. I'll give more details if we know for sure they're all working
good.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
85cocoa Rookie
Joined: 22 Jul 2006
Posts: 17
Location: USA
|
Posted: Sat Jul 07, 2007 7:05 am Post subject: Sorry for the stupid question, but... |
|
Just
to make sure the files are being extracted properly from the zip, can
you tell me what the MD5 hashes (or at least the file sizes) of the
extracted bsnes.exe and cart.db should be? (I've had some weird
glitches downloading official releases of bsnes, and I want to make
sure this isn't screwing up similarly.)
_________________
Dell Inspiron 9300: 1.86GHz Pentium M, 1GB DDR2 SDRAM, 80GB 7200RPM HDD, 256MB Nvidia GeForce Go 6800 (Specs are here only to facilitate bug reports)
Q: Can ZSNES run on a monkey? A: No, not enough RAM. I was -_pentium5.1_- until I screwed up |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Sat Jul 07, 2007 1:55 pm Post subject: |
|
Zip
archive format has checksums written in, probably some kind of CRC
checksum. Therefore if the zip file extracts without warnings, the
files are probably unchanged (CRC is weaker than MD5). This is a nice
advantage in addition to (usually) smaller file sizes. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jul 08, 2007 4:27 am Post subject: |
|
22631b3b2d259d8d40930330e277f104 bsnes.exe
cc5fda71223132f613188c071a3776d0 cart.db
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jul 09, 2007 9:04 pm Post subject: |
|
1010010101010101001010101010101 zsnesw.exe
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jul 11, 2007 8:57 pm Post subject: |
|
Lemmings 2 fodder ...
Code: |
corruption is on bg2 pri1 -- appears to be tilemap
not CPU
not PPU
not hdma
not offser-per-tile
not bit functions (sclip, uclip, etc)
not vram writes during vblank
//v019
bgmode = 3
bg2_scaddr = 0000
bg2_tdaddr = 0000
bg2_vofs = 0050
bg2_hofs = 0000
//v020
bgmode = 3
bg2_scaddr = 0000
bg2_tdaddr = 0000
bg2_vofs = 004e
bg2_hofs = 0000 |
Shit. The VRAM, OAM and CGRAM are identical between bsnes v0.019 (one
red line) and v0.020 (screen clusterfuck). Identical! The fuck! So I
replace the S-PPU and S-CPU with v0.019's ... no effect!
The registers aren't different, so ... I don't know how this one is
happening. Unfortunately, v0.020 completely lacks a debugger to try and
track this bug down with.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Jul 12, 2007 12:04 pm Post subject: |
|
Didn't you tell me as an emulator author, you didn't need a debugger? 
_________________
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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jul 12, 2007 3:41 pm Post subject: |
|

Fixed. This one wasn't an emulation bug at all, which explains why I could find no anomalies in VRAM.
src/ppu/bppu/bppu.h:
Code: |
inline uint16 read16(uint8 *addr, uint pos) {
#if defined(ARCH_LSB)
return *((uint16*)(addr + pos));
#else
return (addr[pos]) | (addr[pos + 1] << 8);
#endif
} |
src/ppu/bppu/bppu_render_bg.cpp:
Code: |
uint16 bPPU::bg_get_tile(uint8 bg, uint16 x, uint16 y) {
x = (x & bg_info[bg].mx) >> bg_info[bg].tw;
y = (y & bg_info[bg].my) >> bg_info[bg].th;
uint16 pos = ((y & 0x1f) << 5) + (x & 0x1f);
if(y & 0x20)pos += bg_info[bg].scy;
if(x & 0x20)pos += bg_info[bg].scx;
return read16(vram, regs.bg_scaddr[bg] + (pos << 1));
} |
Notice regs.bg_scaddr[bg] + (pos << 1) ... I was not wrapping the
address to 16-bits, so it was overflowing and reading garbled data. A
pretty serious flaw, I'm surprised only Lemmings 2 managed to expose it.
This is a tricky one to fix properly, so I'm going to put some thought
into it. For now, a cheap fix is to change read16's pos parameter from
uint to uint16. Since bg_scaddr is always an even address, and pos
<< 1 by nature is also always even, you don't have to worry about
a read from 0xffff, 0x10000. I'll probably end up killing read16 all
together and perform byte reads instead.
This was a fun one to track down ...
Code: |
if(!hires) {
if(bg_enabled == true && !wt_main[x]) {
if(line.y == 141 && x == 10 && bg == BG2) {
fprintf(fp, "* scaddr=%0.4x tdaddr=%0.4x scoffset=%0.4x
scdata=%0.4x\r\n", regs.bg_scaddr[BG2], regs.bg_tdaddr[BG2],
__dbg_scoffset, __dbg_scdata);
}
setpixel_main(x);
}
if(bgsub_enabled == true && !wt_sub[x]) { setpixel_sub(x); }
} |
I added a hook that tested for the first red pixel that appeared in
both v0.019 and v0.020 and logged some information about it.
Surprisingly, doing so fixed the problem, because I was caching the
results of bg_get_tile into those debug registers which were clamped to 16-bits. Heh.
Thanks again for the bug report, Lord Nightmare.
Quote: |
Didn't you tell me as an emulator author, you didn't need a debugger? |
I need a window to print shit in, at least :/
I'll probably just have to log stuff to a text file for now.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jul 12, 2007 6:14 pm Post subject: |
|
Nice. Off the list it goes. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jul 12, 2007 9:17 pm Post subject: |
|
byuu wrote: |
Quote: |
Didn't you tell me as an emulator author, you didn't need a debugger? |
I need a window to print shit in, at least :/
|
I have some code to create a console window and write text to it. Win32, of course... link, pic
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jul 16, 2007 4:17 pm Post subject: |
|
AllocConsole()
GetStdHandle()
WriteConsole()
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jul 16, 2007 5:24 pm Post subject: |
|
Thanks,
but a Windows-only solution is no good. I need something that works for
both platforms. And I want to add my own controls, so what I need is a
textbox that I can set a font with, that gives the same # of x/y
characters on both platforms. Yeah, that'll be fun. Maybe I'll just
draw the control myself, though I'll lose scrollbars and copy/paste
that way. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Jul 26, 2007 12:09 am Post subject: |
|
Wow, glad to see all the progress byuu. Glad to see it's working on Linux too. Good work. 
I'm planning to get a new computer in the near future with an Intel
Core 2 Duo Extreme Quad Core QX6850 processor, so I'll be able to fully
start playing with emulators again. 
Again, good work.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jul 31, 2007 11:33 pm Post subject: |
|
Hmm, I have a rather important polling question for everyone.
Basically, I don't consider 'Adventures of Dr Franken' and 'Winter
Olympic Games' to be 'bugs' per se, as they are merely a limitation of
emulation. Due to the imprecision of a scanline-based PPU, they exhibit
a see-saw effect. Move OBSEL writes too far one way, and these two
break. Move it the other way and four others break. We need more
precision to fix it, so it is not possible to fix things with my
current approach. And I provide that toggle in my config file as
"ppu.hack.obsel_cache" or whatever. They're also barely noticeable ...
a one-line flicker, which shows that it's merely a scanline-based
renderer accuracy miss.
With that said, that leaves me with one known bug. Uniracers OAM writes
during active display. I know where Uniracers is expecting the writes
to go, but I can't do anything about it, because I don't understand the
internal specifics of the PPU.
To give an analogy, it's like trying to understand how a specific
capacitor works by staring at an electrical power box from the outside
and poking it with a stick. And we've been poking that box since 1996
now. Suffice to say, it's isn't working. We aren't figuring this one
out. The only way to figure this one out will be to start on that
masochistic dot-based PPU renderer.
My biggest fear with that is basically sacrifing the emulator I have now to work on it: bsnes will not be usable by anyone
for gaming if I try and emulate the PPU at that level of precision. But
it's the only next logical step. bsnes is stagnating because I won't
touch the PPU. Everything else is done to as low as precision as we're
going to get. Bus-accurate CPU, bus-accurate SMP, bus-accurate DSP
(thanks to blargg). Only GUI changes remain, and I can share the GUI
code between the old v0.021 core and a new PPU core, at least.
Now, I look at the possible fix for Uniracers, and I think ... hmm.
Right now, I let OAM writes go wherever they want during active
display. That's quite bad, as this is incorrect behavior. But since we
have no idea how it really works ... what if I were to just map the
writes to where Uniracers expects them? It will fix Uniracers, won't
break anything else, and will affect all games globally. And on the
plus side, any OAM-write-during-active-display bugs in fan translations
or hacks will now be exposed, as the writes won't go where logically
expected.
I think about this, and immediately think, "no ... even if it's global
... it's still a hack". But I think more, "Well, what about the render
scanline position that we adjust for maximum compatibility? What about
the position I cache OBSEL? Aren't THOSE hacks, too? Isn't using a
scanline renderer to begin with a hack?? What's the difference?"
And Uniracers is really the last straggler remaining. So, what do you
guys think? Should I modify OAM writes to behave like Uniracers? Even
if we don't know why it acts like that, it acts like the only known
hardware example we have of this behavior, and it's really no less a
hack than the scanline render position hack.
And as it's the last game that's unplayable, that would technically
give me 100% compatiblity with no *game-specific* hacks, right? The
Uniracers fix wold apply to all games, and wouldn't affect any of them
but Uniracers (if it would have, they would've been broken already).
I could release this final version, and then take that dreaded plunge
for dot-based rendering, and at least be happy with the fact that
there's a fast, playable version of bsnes with zero known bugs, which
has always been a dream of mine since I started on bsnes.
Or is this just cheating? If you guys agree it's cheating, I'll leave
Uniracers broken until we find the proper emulation method.
Adding this fix won't discourage me from working on the proper fix,
either. In fact, it will just free me up to work on it even moreso. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Jul 31, 2007 11:55 pm Post subject: |
|
I think the measuring stick should be "does this change make the emulator any less accurate?"
If you can improve compatibility without reducing accuracy, then it seems win-win to me.
On the other hand, I suppose you're inserting a "magic number" that has
no global meaning across different carts - it only has meaning in the
context of uniracers, and thus qualifies as a hack. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Jul 31, 2007 11:58 pm Post subject: |
|
1 game-specific hack? thats a fucking victory.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 01, 2007 12:06 am Post subject: |
|
Quote: |
I think the measuring stick should be "does this change make the emulator any less accurate?" |
In this case, it does not. In fact, it's technically an improvement.
Before, writes were valid during active display. This will block that.
The writes won't go where they're supposed to on hardware in 100% of
cases (instead, only in 100% of known cases, eg the only known case,
Uniracers), but they won't go to where they're expected as they do on
emulators now (which was bad). The only thing we can say, is that we do
know where the writes should go for Uniracers, but not where they
should go in all cases. So, though a very large stretch ... it's also technically more correct than what I have now ...
So, it's a real 50-50. But yes, the issue I have with it is that it's
specific to Uniracers. And yes, it's kind of a magic number, so to say
... but it wouldn't be a case of checking the ROM cart name, and only
applying it for one game. It would be across the board.
Basically, I can add this or not add it. I'm just wondering how others would feel about it.
|
|
Joe Camacho Devil's Advocate

Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
|
Posted: Wed Aug 01, 2007 12:55 am Post subject: |
|
Well,
I might not know a lot about this stuff, but if the uniracers bug is
taking a lot of time of your schedule, from other proyects that you
think could benefit the emulator, I don't see why you couldn't add that
for the time being.
I only fear the bad
intentioned people that will discredit Bsnes because of this, "hack",
or whatever. But in the long run, it will benefit the emulator, giving
you time to work on something else, while giving the masses an Emulator
with 100% Accurancy.
And I'm sure you are going to note this in the documentation, so you
wouldn't be disliked because of "false advertising".
I say go for it, you get free time, and the people get an emulator without problems.
_________________
*Sometimes I edit my posts just to correct mistakes.
I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 01, 2007 1:36 am Post subject: |
|
Yeah, that's the thing though. In and of itself, I wouldn't add it ... but playing the devil's advocate, how is it any less
of a hack than the scanline renderer and the "magic number" of 576 we
use for which cycle position to render the scanline at? Even if I fixed
Uniracers properly, it wouldn't be fair to claim 100% pure accuracy
anyway because of the OBSEL and scanline timing tricks.
If I modified things away
from what I knew to be right to fix Uniracers, it would certainly be a
hack. But, as it stands ... I don't know how it really works either
way. So I'm technically not losing any accuracy. And really, it's a bit
safer. But of course, the safest and fairest way would be to send all
OAM writes to 0x0000, breaking Uniracers and not allowing OAM writes
during active display, either.
Meh, I don't know ... I'll go with whatever the majority is here, one way or the other, for the next release. |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Aug 01, 2007 2:25 am Post subject: |
|
I
would say it's a compromise necessitated by the use of a scanline-based
renderer, and therefore OK. It can be removed when you progress to the
next level of accuracy with the dot-based renderer.
_________________
Why yes, my shift key *IS* broken. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Aug 01, 2007 5:17 am Post subject: |
|
byuu wrote: |
Or
is this just cheating? If you guys agree it's cheating, I'll leave
Uniracers broken until we find the proper emulation method. . |
I personally believe it's cheating. And in my opinion, a global
hack/modification is actually far more worse than a game-specfific hack.
About Uniracers: it plays fine in one player mode, and the people who
absolutely need to play it with two-players can also use Zsnes, which
play the game fine (even if it uses imperfect means to do so)
Achiving 100% compatibility with a global "hack"/modification is...well
not really achiving 100% compatibility, plus it can shed some doubts
for the others 99.99% which are emulated correctly using accurate means.
I say don't let that one evil game pull you away from the path of
honest emulation...as...err..some honest dude in the past that was
tempted by...err, something not good..or something like that anyway.
Note: I understand this is not necessarily meant as a permanant
solution, but I think it's better to stay away from those things from
the start.
edit:
byuu wrote: |
Yeah, that's the thing though. In and of itself, I wouldn't add it ... but playing the devil's advocate, how is it any less of a hack than the scanline renderer and the "magic number" of 576 we use for which cycle position to render the scanline at? |
True, but the difference here imo is that the scanline renderer is used
because nothing more accurate is currently available, so we settle for
second best. This however would be more deliberate, like the difference
between first and second degree murder or accidental man slaughter or
something (just an example mind you lol)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 01, 2007 6:16 am Post subject: |
|
Quote: |
I
personally believe it's cheating. And in my opinion, a global
hack/modification is actually far more worse than a game-specfific hack. |
Oh, I do, too. But this specific global hack will actually make things
better than what I have currently. I believe it was Nightcrawler who
recently pointed out that he had a routine that updated OAM outside
vblank, which of course worked fine on bsnes, but not on real hardware.
Adding this change would actually prevent that.
But if the consensus is not to do this, then I'll remap OAM and CGRAM
writes to address 0x000 until we find the proper behavior.
Quote: |
Achiving
100% compatibility with a global "hack"/modification is...well not
really achiving 100% compatibility, plus it can shed some doubts for
the others 99.99% which are emulated correctly using accurate means. |
But that's just it ... the scanline render position is a hack, too.
Move the value by 4 cycles in either direction and another game will
break. Either Battle Blaze or that other one. The only difference here
is that this one is a lot more targeted. But I'd technically just be
duplicating the only observed instance of this behavior in commercial
software.
Sigh, this is such a tricky issue ...
Another option could be to make it a config file option, and just set
the default address to write OAM / CGRAM data outside vblank to 0. That
way, people who really
want to play Uniracers will have a means to do it (set the value to
0x218), and the default state will be to leave things alone. Or vice
versa. Sound better? Worse?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 01, 2007 7:19 am Post subject: |
|
I
see you are bothered by being so close to 100% and having that
horizontal line issue stuff on the list, so I removed them and
addressed it as best I could. Let me know if it needs changing.
I have always been in favor of a temporary hack for uniracers so long
as it was transparent and could be disabled. You've already committed
to the scanline-renderer as a temporary hackish compromise to afford
people the ability to actually enjoy games on bsnes until a dot-based
renderer is complete and modern CPUs can run it. With that in place, a
hack for a game that exhibits issues associated with that compromise
would give bsnes users the ability to perceive 100% accuracy for all
games. I don't understand why it would bother people to have another
scanline-renderer hack if indeed that is what the problem is.
Currently, scanline-associated hacks already exist as options to afford
people this perception with games that have horizontal line issues.
Uniracers, however, is the one game that cannot currently be perceived
as bug free with any setting. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Aug 01, 2007 8:30 am Post subject: |
|
byuu wrote: |
Quote: |
I
personally believe it's cheating. And in my opinion, a global
hack/modification is actually far more worse than a game-specfific hack. |
Oh, I do, too. But this specific global hack will actually make things better than what I have currently.
|
Sorry,I missed the part where you wrote:
Quote: |
In fact, it's technically an improvement. Before, writes were valid during active display. |
Re-reading your original post I take back what I said.
Quote: |
Now,
I look at the possible fix for Uniracers, and I think ... hmm. Right
now, I let OAM writes go wherever they want during active display.
That's quite bad, as this is incorrect behavior. But since we have no
idea how it really works ... what if I were to just map the writes to
where Uniracers expects them?
I believe it
was Nightcrawler who recently pointed out that he had a routine that
updated OAM outside vblank, which of course worked fine on bsnes, but
not on real hardware. Adding this change would actually prevent that.
|
It's not the dot-based PPU but sounds like an improvement, or at least
not a regression in accuracy and with the added benefit of making
Uniracers playable.
So you have my vote for what you originally proposed.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Aug 01, 2007 8:45 am Post subject: |
|
I
like your analogy with the fuse box. At the moment, you can either poke
it with a stick, or look at Uniracers and figure atleast a -part- of it
out. When you do start to work on a dot-accurate PPU you'll be able to
complete the fix, maybe change the behaviour if it turns out you
misunderstood something, but until then this is the best you have, and
like you said is still better than just letting the writes go nowhere.
Personally I see this as a partial fix rather than a hack.. the
uncertainty may be more significant than those final timing changes in
the sSMP, but in that case blargg's core was better than what we had
before, even when the order of the code (bus accesses?) was just a
matter of deduction and guessing. So I'd say go for it, and get your
mind off the problem until you can fix it once and for all.
By the way, when - I have every confidence that you will - when you do
figure out the dot-based PPU, with everything that entails, will you be
able to add the correct OAM writes behaviour to sPPU or does the
improved accuracy need the different core? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 01, 2007 9:13 am Post subject: |
|
The
obj_cache thing was also thought to be an accuracy improvement, but it
ended up causing severe sprite flickering in tons of games. So if this
is thought of as a fix, it might be a good idea to do some WIP testing
first. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Aug 01, 2007 10:35 am Post subject: |
|
Verdauga Greeneyes wrote: |
When
you do start to work on a dot-accurate PPU you'll be able to complete
the fix [...] but until then this is the best you have, and like you
said is still better than just letting the writes go nowhere.
Personally I see this as a partial fix rather than a hack. [...] So I'd
say go for it, and get your mind off the problem until you can fix it
once and for all. |
Seconded.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Aug 01, 2007 12:05 pm Post subject: |
|
The chip is still copyrighted, right?
So you can not use expensive equipment to open the chip up and extract the exact layout of the die.
Well, you could, but you likely wouldn't be legally allowed to share your findings. I think.
To compare to the stick poking, this would be like disintegrating the
box around the stuff and then, using a magnifying glass, noting exactly
how each sub-part is connected.
It will be a hard task to figure out how the chip works internally, but
it is required if you are ever going to make this mystery go away.
Btw, while I admire your goal, I think you need a break from hard
stuff. Go and code support for the multi tap or something similarly
easy. |
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Aug 01, 2007 12:59 pm Post subject: |
|
This is pretty black and white to me.
It is currently unknown how the hardware is supposed to work when it
comes to writing during the active display. Based on this, at this
time, the best educated guess should be used based on evidence we do
have as it is the most accurate solution known to anyone. Since the
behavior of Uniracers on the real hardware acts as our only evidence, I
view it as IMPROVING accuracy to make Uniracers behave correctly by
modifying the way active display writes behave.
It should obviously be tested with as many games as possible. IF there
are no noticeable effects, it should be ASSUMED that it is the correct
behavior until anytime in the future evidence is discovered to show
otherwise. Because as far as we know it *IS* correct. It may be days,
months, or even years before any additional information can be provided
to prove or disprove this fix is correct or incorrect. We're hopeful
the PPU dot based renderer will help, but there's still not guarantee
even then that the correct behavior will be known.
I don't view it as a hack in the least bit. It's simply providing the
most accurate emulation behavior that we currently know of based on the
only evidence we have on the situation. At this point and time, no
other human can offer a more accurate solution for the behavior of
active display writes, so naysayers can bug off.
The emulator is LESS ACCURATE without it because we know it's current
behavior is INCORRECT! ti makes logical sense to make not leave it what
is known to be incorrect and instead make it into the what is believed
to be correct based on all the evidence we have at this time.
As for the scan line setting adjustment. Not a hack either. It's
allowing for the most accurate behavior currently known within the
confines of the emulator framework. It's impossible to make it any more
accurate without a new framework (dot based renderer). At the time that
is implemented, obviously that setting will go. However, at this point,
it reflects the most accurate result possible within the current
emulator.
So, there you have it folks. It seems cut and dry to me and it agrees with the ideals of BSNES.
_________________
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
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Aug 01, 2007 3:22 pm Post subject: |
|
It would indeed seem from byuu and nightcrawlers posts that this improves accuracy.
I vote do it!
I will be able to do another full game testrun after the summer if needed.
I'm confident the new ppu will shed some light on this and the other scanline issues |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Aug 01, 2007 3:41 pm Post subject: |
|
henke37 wrote: |
The chip is still copyrighted, right?
So you can not use expensive equipment to open the chip up and extract the exact layout of the die.
Well, you could, but you likely wouldn't be legally allowed to share your findings. I think. |
No, I think you're allowed to use clean room techniques.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 01, 2007 5:17 pm Post subject: |
|
Quote: |
I
see you are bothered by being so close to 100% and having that
horizontal line issue stuff on the list, so I removed them and
addressed it as best I could. Let me know if it needs changing. |
I'm sorry, I didn't mean I wanted you to remove them from the bug list.
They technically don't behave like hardware, so it is valid to call
them bugs (as well as the games that just so happen to work now with
the default obj_cache setting ... they aren't really being emulated
correctly even if they look correct to us). And it is good to keep
track of all the games that are affected by either
setting of obj_cache. But there's unfortunately nothing I can do about
those two with a scanline renderer. It's simply not possible to fix
those and their counterparts
(Megalomania et al) at the same time, without increasing the precision
of the S-PPU, thus making it a hybrid scanline/dot renderer, inheriting
the worst of both designs (ugly, slow, confusing). Hence, I have
obj_cache to test emulation to verify that this is the cause of certain
scanline render issues ... but it's all I can do. The good news is that
it doesn't affect the execution of the game at all. The SNES has no way
to read back pixels rendered on screen, so the the S-CPU and S-SMP,
this one-line glitch is completely transparent. It's just simply a
limitation of my renderer (nay, of ALL SNES emulator renderers).
Quote: |
when
you do figure out the dot-based PPU, with everything that entails, will
you be able to add the correct OAM writes behaviour to sPPU or does the
improved accuracy need the different core? |
I suspect that unlike obj_cache, this one will be fixable if we know
the internal rendering details of the S-PPU. So I'm somewhat confident
this change can be backported to scanline renderers. I can't say for
certain though, as again, I don't know how it really works yet. And the
scanline renderer is bPPU, funny as that sounds :P
Quote: |
The
obj_cache thing was also thought to be an accuracy improvement, but it
ended up causing severe sprite flickering in tons of games. |
Well, in this case ... I'm almost certain it will cause no regressions.
Reason being, the writes were already going to the wrong addresses. If
a game relied on this, then it would be broken on real hardware, too. I
will post a WIP nonetheless tonight or tomorrow, hopefully.
Quote: |
So you can not use expensive equipment to open the chip up and extract the exact layout of the die. |
I have neither the skill to read such layouts, nor the money to afford
doing this. I will have to RE the S-PPU using my own test programs.
Quote: |
Since
the behavior of Uniracers on the real hardware acts as our only
evidence, I view it as IMPROVING accuracy to make Uniracers behave
correctly by modifying the way active display writes behave. |
That is the one sticky point. I am the only person who has ran any kind
of test on real hardware with this (to my knowledge). What I found was
a pattern of writes to OAM memory. The S-PPU strobes along the OAM
address as it reads the various sprite data throughout the scanline.
Things seem to stop moving during hblank (where Uniracers writes its'
data).
Unfortunately, something
is happening with Uniracers to bump that address to sprite extended
attribute #96-99 (0x218) ... and nobody knows what. Most likely, the
address varies based on other internal state information (how many
sprites there were on the last scanline, how big the sprites were, etc
etc). My test was with no active sprites onscreen, whereas Uniracers
was a fully populated screen with lots of variables all over the place.
I cannot, at this time, modify my code to work with both my one test
and Uniracers. To get the information I need, I have to start
implementing what I have learned from my test ROM*, and that means
dot-based renderer.
(* Bad analogy time! Fixing
Uniracers properly with a scanline based renderer would be like trying
to fix DMA bus sync delays while my CPU core was an opcode emulator
with no understanding of the different memory access timings ... I
wouldn't understand that some regions ran at 6, 8 or 12 clocks ... nor
would I understand the breakdown of each cycle in an opcode. Both are
very important to how DMA bus sync works. In the end, we weren't able
to figure out the DMA bus sync behavior until I had the cycle core with
proper memory timings in place to perform the proper tests via
emulation. Likewise, I need to start with a raw dot based renderer, and
then slowly build my way up to OAM writes during active display. Right now, that's too low level a concept for our high level scanline emulator. There's way too much missing information between the two points for us to figure out what's really going on here.)
However, the behavior of Uniracers is
the only known example in a commercial game, so it seems more empirical
to me than my test ROM, which may have been flawed in and of itself.
So now would be the last chance for a long time to get a partial fix in for Uniracers.
---
Thank you everyone for your feedback, it's really appreciated!
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Aug 01, 2007 9:40 pm Post subject: |
|
Quote: |
At
this point and time, no other human can offer a more accurate solution
for the behavior of active display writes, so naysayers can bug off |
I don't know if you're including me there, but just to clear things up
in case: I'm in favor for the new OAM write, see previous post.
byuu wrote: |
I have neither the skill to read such layouts, nor the money to afford doing this. |
How much money would one need?
I'd be willing to contribute money (through a PayPal account or
something) toward some project (in the same fashion as the Mame dumping
projet) and maybe others would, that would make this possible.
It sound like the ultimate RE method, and wouldn't it be much, much
faster than going the old route of RE everything by software?
Last edited by Snark on Wed Aug 01, 2007 9:43 pm; edited 2 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 01, 2007 9:42 pm Post subject: |
|
So, with that issue settled ... time to start planning the development of sPPU.
The overall layout of bsnes loops something like this:
UI <> SNES { S-PPU <> S-CPU <-> S-SMP <> S-DSP }
The CPU and SMP crosstalk via a very small 4-register window, so it's
very easy to run them out of sync and simply sync them up periodically
and on access to those registers. This is great, since they run with
different crystal clocks (different frequencies), whereas
PPU<>CPU and SMP<>DSP run off the same crystal clocks
(different multipliers).
For the SMP<>DSP sync, they share 64k (P/S?)RAM. Thusly, I can't
cheat by simply syncing only when shared registers are accessed ...
because literally every single bus read and write can be influenced by
the other chip.
For the CPU<>PPU sync, there are only 64 shared registers. So, at
first glance, it looks like my CPU<>SMP speedup trick would work
well. But upon closer inspection, there are 'hidden' values shared
between the two: the latch counters. You see, it isn't that these
entire values are accessible constantly to the CPU, there's actually
pins to signal vblank and hblank. The CPU keeps its' own internal
counters and wraps and increments them based on high to low transitions
of these pins. At least, that's our theory, and it's a very plausible
one (probably the only plausible one).
But here's the thing: those two flags are updated constantly.
I don't want to mess around with speedhacks right off the bat. So, for
now, my plan is to design the S-PPU like the S-DSP: synchronize every
clock tick. This is going to be very
painful. It'll be something like 5mhz - 10mhz of synchronizations. I
don't know which will be necessary just yet. Knowing my luck, 10mhz.
Scary ... but I'm not going to make the CPU the enslaved one, because
the CPU operations are a lot more complex (each cycle there takes 6, 8
or 12 ticks, whereas the PPU will always be either 2 or 4 ticks).
Now, the question is ... do I want to try and split the PPU into PPU-1
and PPU-2, each with their own threads ... or try and merge the
operations into one shared PPU thread? Hmm ... the former will be more
descriptive of the actual hardware, but will be way slower and possibly
completely unnecessary (as if speed is even going to matter anymore ...
sigh). I suppose splitting the PPU would be like splitting the CPU with
its' internal DMA unit, IRQ unit, etc ... the two PPUs are actually
separate ICs, unlike the CPU, though.
Quote: |
How much money would one need?
I'd be willing to contribute money (through a PayPal account or
something) toward some project (in the same fashion as the Mame dumping
projet) and maybe others would, that would make this possible. |
Oh, man ... probably $10,000 or so per IC for high resolution pictures.
And since the chips are somewhat newer than the archaic stuff MAME
works on, there's probably multiple layers. I don't even think the
diagrams would help much.
What I could really
use is a special development board where I can run the two S-PPU chips
via an interface to my PC. To be able to strobe all of the pins however
I want through software and control the crystal clock, like this guy
did with the NES PPU would be -immensely- useful. Sadly, I don't know
who could even do something like that. The dual SNES PPUs are much
smaller and more difficult to control than the single NES PPU.
I suppose I'd be willing to throw a few hundred for an EE willing to make something like that for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 8:46 am Post subject: |
|
Alright, I've posted the new WIP.
This one's really important, so please test it thoroughly! :D
I've ran it through my usual list of troublesome games, and everything
looks good, but it's possible I've overlooked something.
The new config file settings are:
ppu.hack.oam_address_invalidation
ppu.hack.cgram_address_invalidation
Set to true, OAM goes to 0x0218 (for Uniracers), CGRAM to 0x0000
(address is insignificant, we know of zero examples of this behavior,
so the address chosen does not matter for now). Set to false, the
writes are allowed and go where 'expected' (by programmers, not by
hardware).
There's a slight difference in that OAM access is invalid even during
hblank, whereas CGRAM is obviously not (that's how games draw those
gradient fades and such).
This WIP also has the Lemmings II fix.
---
Now, I know I said I wouldn't bring this up again, but meh. So,
assuming I decide to go full force at this PPU renderer ... I still
want to let bsnes live on in its' current form, even if that means
losing my userbase to a competitor :(
I'm planning for the next release to allow derivative works, in hopes
that someone will continue it. Does anyone have any objections to that?
Would it be better to use GPLv2/3 to ensure source availability (even
though I disagree with the notion of 'freedom through restrictions' --
I liken it to becoming your enemies to defeat them), or better to use
PD to ensure the widest possible use of the code (even if that means
the source can be closed off to the public, and the binary sold for
profit -- which I also detest as immoral)? I realize the latter means
the value of all of my work will be lost, but I never intended to
profit from any of this anyway, so ...
If you prefer GPL, please specify either v2 only, v2+ or v3. I can use
v3 and grant ZSNES an exception to use it under v2, so their v2 only
license won't be a problem.
Some examples:
ZSNES is GPLv2, which got them the source to Zsnexbox.
PocketNES is PD, which got the emulator used in commercial software by
Atlus, Hudson and Jaleco (though the assholes couldn't even be bothered
to send a thank you letter to the PocketNES devs).
EDIT: I can also stick with the current license, a no-derivative one,
and do my best to maintain bsnes' old PPU renderer, if you like. But I
won't lie ... the pace of development will slow down a lot on the older version (it shouldn't affect my new PPU development speed much) if we go with this option.
Once again, I'll go with community opinion this time. I'm personally not casting a vote for either.
Last edited by byuu on Thu Aug 02, 2007 3:14 pm; edited 1 time in total |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Aug 02, 2007 11:08 am Post subject: |
|
I would write my own license. Gpl is poison and BSD is too lose. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Aug 02, 2007 1:22 pm Post subject: |
|
byuu wrote: |
Now, I know I said I wouldn't bring this up again, but meh. |
Would you no longer develop the last-released codebase (the one which
you will release under some new license) once you start on the new PPU?
Or will you, over time, still make small changes or backports to the
scanline PPU emulator? Like, are you starting a whole new emulator?
How will your choice of license restrict your own use of your own code in your future projects?
From your standpoint, I'd say the GPL is the lesser of the two evils. The differences between versions I know not.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Aug 02, 2007 1:33 pm Post subject: |
|
byuu wrote: |
Some examples:
ZSNES is GPLv2, which got them the source to Zsnexbox.
PocketNES is PD, which got the emulator used in commercial software by
Atlus, Hudson and Jaleco (though the assholes couldn't even be bothered
to send a thank you letter to the PocketNES devs).
. |
Not like I ever programmed anything, so it's just my uninformed
opinion, but I sure wouldn't want to go Public Domain. There's just as
much chance that the program could be use as a reference as there are
that it ends up like a horrible shadow of it's former self, forever
lost.
Imagine a few years from now, some r0mz
kiddy decide to modify bsnes, change it so it could run on a 50hz
portable device or something, and in the process obviously destroy
everything that makes it accurate.
Few years later...no copies is left of the original... Well, I don't
know if that's a realistic scenario, but that's how I envision PD in
this case, or what I fear could happen.
edit: Then again, if you're going to start a newer, even more accurate
bsnes...then it wouldn't be as bad I guess... as long as you never go
PD with the newer bsnes of course.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 2:39 pm Post subject: |
|
Quote: |
I would write my own license. Gpl is poison and BSD is too lose. |
I suppose I'll count that as a vote for my current license, then. Nobody can take over that, though.
Quote: |
Would
you no longer develop the last-released codebase (the one which you
will release under some new license) once you start on the new PPU? Or
will you, over time, still make small changes or backports to the
scanline PPU emulator? Like, are you starting a whole new emulator?
How will your choice of license restrict your own use of your own code in your future projects? |
I'm still planning to backport UI changes and bugfixes to the non-PPU
stuff. If the OAM address write stuff is figured out, I'll probably
port that back, too. But the only thing changing now is the PPU and CPU
(I have to fork both, because the two now are too intertwined).
So long as I require copyright to be transferred to me for any code I
use (which is what I'll be doing), then I can take any part of bsnes
that's mine and relicense it as I need to in the future. I'm sure that
means the ultra far gone GPL zealots won't donate any code for that
reason. Fine by me, I've made it this far without them. But you did
stumble across a fun problem. If you don't reassign copyrights, then
you lose the right to your code as it becomes denatured by more and
more copyright owners you need permission from to change your license
in the future. You can usually get away with changing the license
anyway, like ZSNES did when they removed the "or any later version"
clause without getting approval from every single donator of code since
ZSNES first went GPL. It'd really only be a super major project like
the Linux kernel where people would start raising legal questions over
such a move.
Quote: |
There's
just as much chance that the program could be use as a reference as
there are that it ends up like a horrible shadow of it's former self,
forever lost. |
I claim unregistered trademark, so any forks would be required to use a
different name anyway. And yes, it would be a sad day for me as well to
see something like UOSNES happen to my codebase ... but the ideal
behind these allow-derivative licenses is that you can allow the 'best'
software to be developed, even if it's not by you (see
XFree86->Xorg). I don't entirely believe that, because I don't think
a stranger coming in to our scene can do any better than me (yay ego!),
let alone because they're editing ~1MB of code they didn't even write
(at best, they'd make a few small bugfixes and claim to have a more
accurate emulator than me -- but that'd just damage their credibility
more than mine) ... but who knows. I suppose it's possible.
---
My main concern here is that I hate to leave all of you guys in the
dark if I start on this new PPU. I can't backport my changes forever. I
can try ... but a lot of stuff is going to go. Filters (the new PPU
will be locked at 512x480 for simplification), frameskipping (I won't
be able to skip the PPU anymore since the latch counters will be
embedded in the PPU), and more will be pulled. I know a lot of you guys
have started using bsnes, which I never expected when I first started
on it. And to kill it off just so I can follow my own crazy accuracy
dreams seems sad.
Nonetheless, if you guys want to vote for me to keep my license alone,
and just make backport changes when I can, then I can do that as well.
The current license still stands as, "all you have to do is ask, and
you'll most likely get an exemption to use my code in your projects"
... but that rules out a lot of stuff, including ever seeing bsnes in
things like apt-get repositories with 'free software' only for Linux
users. I don't know if more people will help if I release as GPL or
not, honestly. Probably not, but you never know. Nobody has volunteered
to take over the current codebase yet, if I do go through with this new
PPU renderer.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Aug 02, 2007 2:57 pm Post subject: |
|
byuu wrote: |
My main concern here is that I hate to leave all of you guys in the dark if I start on this new PPU. |
I don't think you need worry about that so long as you keep us
up-to-date on your progress in this thread and/or on your website
I realise WIPs would be out of the question for a long while once you
start on the PPU, but perhaps you'll consider releasing the
stripped-down version of bsnes, that you'll be using as a base for it,
with the scanline-based PPU, so we know what bsnes with sPPU (I'll try
harder to remember the various acronyms )
will be like. Hell, some purists might even prefer it, and the extra
bit of speed might help people who're having to use a frameskip of 1 to
play at full speed.. y'never know.
As for the
license stuff, I second that you keep your current license, because if
people can't even be bothered to -ask-, why should they get to use your
code?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Aug 02, 2007 3:02 pm Post subject: |
|
byuu wrote: |
You
can usually get away with changing the license anyway, like ZSNES did
when they removed the "or any later version" clause without getting
approval from every single donator of code since ZSNES first went GPL. |
It wasn't a problem because we made it more restrictive, we don't need permission to do that.
As it was, we also didn't parade the fact, and all the official
developers agreed, so no crazy arguments or people running to make new
forks.
Besides, most of the developers who ever contributed anything useful
(besides libraries), has become an official developer, or contributed
code that was replaced or very minor. If we had a case where 10% of our
code base or something was outside contributions, I'd worry, but as it
is, aside from libraries, less than 1% of the current code base is from
non team members.
And before someone says, oh look open source did nothing for ZSNES, all
the current developers joined because it was open source. Unlike some
other projects, anyone who does something really significant, we make
them part of the team. Also, some of the minor tweaks from outside
while not a required change, were generally very useful. Many small
minor outside fixes are usually to improve compatibility on some
whacked out setup.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 3:36 pm Post subject: |
|
Ok, so far we have:
Current license: (2 votes) Verdauga Greeneyes, henke37
- I still grant license exemptions upon request [ala OSX port], but may
prevent contributions to bsnes in the future, and also rules out the
chances of someone taking over development of the older version
- Best choice if you're interested in maintaining the integrity of
bsnes at all costs (even the current version has ~99.9+% compatibility,
so it isn't as if you're being left in the dark if development of the
old core stagnates due to the new PPU core)
GPLvN: (3 votes) Jipcy, Lazarus, Snark
- The copyright reassignment clause I will need may limit development,
or completely fork development away from me [ala XFree86->Xorg] --
but this might be for the best public interest; most likely to result
in more contributions
- Best choice if getting the best possible open source version of
bsnes, regardless of who develops it (possibly won't be me), is your
top preference
PD: (0 votes)
- Unlikely to result in more contributions, as virtually nobody gives
their code away PD, but should not result in less than the current
license. Most likely to result in closed-source, binary, and commercial
versions of bsnes; but that doesn't mean those versions won't have
worth, they may bring amazing speedups or features like savestates, etc
too [ala Wine->Cedega]
- Best choice if getting the best possible version of bsnes, at any cost, is your top preference
(anyone can alert me if they'd like to change their vote, eg if I've misunderstood their vote)
Quote: |
It wasn't a problem because we made it more restrictive, we don't need permission to do that. |
Really? Wasn't aware of that. I'll admit to only understanding half of
that license' legal implications. That's good to know that nobody can
come back to complain about that in the future. I've heard ramblings
about the legality of the Linux kernel moving to GPLv3, but that's in
the opposite direction.
Quote: |
If we had a case where 10% of our code base or something was outside contributions, I'd worry |
Yeah, that's all I was going for was that it was a possibility that I
could lose the rights to my code without the copyright reassignment
requirement. I'd lose the most valuable part of GPL by doing that
anyway ... I wouldn't be able to take others' bsnes-derivative code and
use it in mine without their permission (funny how that permission
thing works only one way, huh?)
Quote: |
And
before someone says, oh look open source did nothing for ZSNES, all the
current developers joined because it was open source. |
True. It definitely kept ZSNES alive after zsKnight and _Demo_ (mostly) left. I'm going to have
to pick some sort of license when I eventually discontinue bsnes one
year, otherwise it really will die, as I won't be able to give
permission to anyone after that.
I honestly
don't know whether a change of license will help any with bsnes or not.
It might, it might not. ZSNES has at least a 70-80% market share, so
any GPL devs would likely choose it anyway, and especially because
AFAIK ZSNES doesn't require copyright reassignment to contribute.
Well, whatever gets decided here, is what I'll stay with until I
discontinue bsnes (yeah, sad, but let's be realistic, I can't work on
it forever, but I have no plans to drop it at this time). At that time,
we can have another license discussion.
Do you have any preference in this, Nach?
Last edited by byuu on Fri Aug 03, 2007 3:31 pm; edited 4 times in total
|
|
Lazarus New Member
Joined: 29 Aug 2006
Posts: 8
|
Posted: Thu Aug 02, 2007 4:04 pm Post subject: |
|
Quote: |
(even though I disagree with the notion of 'freedom through restrictions' -- I liken it to becoming your enemies to defeat them) |
You have no doubt heard this before, but in reality all freedoms need
restrictions. No enforced restrictions in a society means no laws, and
this in turn means complete anarchy. For example, freedom to kill
conflicts with other's freedom to live. Without laws (i.e.
restrictions) this conflict is decided by whoever has the most power.
Laws ideally exist to protect those freedoms (of the weaker) which the
vast majority of people agree to be more valuable than other freedoms
(e.g. freedom to live over freedom to kill).
Likewise, without restrictions (software in public domain) anyone has
the freedom to steal/abuse code as one sees fit regardless of the
effect on the freedoms of both users and developers. The GPL imposes
the restrictions needed to protect the freedoms of said users and
developers.
That's why I vote GPL version 3. Version 3, because, for example, if I
were you I wouldn't allow bsnes to be TIVOized in a DRM ridden closed
source "media station" by some company with a shitty reputation and
dubious ethics.
BTW, I really enjoy bsnes. Thanks for the great work.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 4:58 pm Post subject: |
|
Vote recorded, thank you for your input.
Quote: |
You have no doubt heard this before, but in reality all freedoms need restrictions. |
Yes, but who am I to determine those restrictions? It's also
hypocritical that I defy the copyrights of video games I translate (eg
Der Langrisser), yet use copyright to protect my own works.
Not that it would happen, but it would also be a serious problem if all
software were GPLv3. It would make it completely impossible to develop
non-GPL software. It would, in essence, have a monopoly. Just like the closed source software we all love to hate does now.
Quote: |
f
I were you I wouldn't allow bsnes to be TIVOized in a DRM ridden closed
source "media station" by some company with a shitty reputation and
dubious ethics |
The thing most people sidestep is that the GPLv3 software tells you what you can and can't do with your hardware.
I agree that TiVo made a huge mistake exploiting a loophole in the
GPLv2, though. Their lawyers were retarded for not using BSDL code
only, and they deserve the retaliation they are seeing now. I also
consider the "we added DRM because the media companies made us" excuse
bunk. They benefitted just as much by making it impossible to release a
free service alternative, which would have undercut their monthly
subscription fees. So, overall, I applaud the FSF for sealing the
loophole. I wish they wouldn't have decided to play games with Novell
by allowing them an exemption to the patent protection plug. As it
stands, Novell has free reign to bypass this protection, even with
GPLv3. And we all know it won't invalidate any of Microsoft's patents
in the future. They have $100 billion in lobbying money, after all.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Aug 02, 2007 10:10 pm Post subject: |
|
byuu wrote: |
Filters
(the new PPU will be locked at 512x480 for simplification),
frameskipping (I won't be able to skip the PPU anymore since the latch
counters will be embedded in the PPU), and more will be pulled. |
Couldn't filters eventually be applied to the video output? And by eventually, I mean after you're satisfied with the accuracy of your new emulator?
byuu, I think you've all made us quite aware that the new PPU will be
nearly unplayable on most processors for a long time. So I don't think
you have to worry about us expecting some kind of playable emulator for
a long time. I'm just excited to see what you can do with RE'ing the
PPU.
I think there is a lot of potential good for relicensing your old code
so that people can start adding stuff as they see fit (like special
chips and stuff). And yes, in my opinion, some version of the GPL would
probably be the best for protecting the open-sourceness of the code
while attracting potential future developers.
I'm not sure if this is applicable, but is there any merit to licensing
each "core" of your emulator as a separate piece of code/program? Or,
at the very least, have libui separately licensed?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 10:29 pm Post subject: |
|
libui
is already public domain. But yes, I'm also willing to consider
licensing each component separately. I don't how what that would help,
necessarily ... it would just mean anyone wanting to make a derivative
work would have to rewrite certain parts of the system. The zealots
would just decry the whole work because a single piece of it wasn't
"Open Source (tm)"
Quote: |
byuu, I think you've all made us quite aware that the new PPU will be nearly unplayable on most processors for a long time. |
Yeah, sorry to be repetitive. Just want everyone to be clear on that one.
Quote: |
Couldn't filters eventually be applied to the video output? |
By someone other than me, sure.
I need to design this to be as flexible and simplified as possible. For
example, if video mode changes are possible mid-scanline (we don't know
yet), then it would be possible to create quasi-resolution modes that
are neither 256 nor 512 pixels wide.
We can perform post processing on the image once the PPU is finished
rendering, though. Scaling (up or down), cropping, etc.
I've also never been happy with the dynamic resolution code, and it
makes the code a real mess. I have to keep tables of each scanline's
width, whether or not the interlace or hires flags have been set for a
scanline, etc etc. I could do away with all of that and simplify.
Also, some bad news: I'll have to clock the S-PPU at ~10.5mhz, so that
the S-CPU gets full precision on the latch counters. ~5.25mhz is out.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Aug 02, 2007 11:03 pm Post subject: |
|
byuu wrote: |
I've heard ramblings about the legality of the Linux kernel moving to GPLv3, but that's in the opposite direction.
|
They can't go from v2 to v3, because v3 is more permissive in certain
cases. The Linux Kernel wasn't listed as v2+.
byuu wrote: |
Do you have any preference in this, Nach? |
I personally despise the GPL, so I'd like something nice and open but not GPL.
I have not had the time to read up on every open source license out
there. But I'd look into Apache, OpenSSL, CDDL, and some Creative
Commons ones before deciding.
byuu wrote: |
Not that it would happen, but it would also be a serious problem if all software were GPLv3. It would make it completely impossible to develop non-GPL software. |
Nope, GPLv3 greatly relaxed restrictions on linking. I also have to
reread it some more, but based on initial analysis, you can even use
GPLv3 libraries in closed sourced software.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 11:10 pm Post subject: |
|
Thanks
for your input, I'll put your vote down as PD for now. There's really
not a whole world of difference between eg Apache, CDDL, BSDL, etc, as
I believe they allow closed source derivatives (could be wrong on some
of those).
If PD wins, we can discuss which of the 'lesser' licenses to use. They really don't matter all that much. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Thu Aug 02, 2007 11:31 pm Post subject: |
|
I
don't think you should rule out the possibility that a cycle-accurate
PPU can be fast enough in most cases if you only update the PPU on
relevant register/RAM changes (without keeping two code paths of
course). FWIW it had neglible overhead on a GBC PPU I wrote. I probably
_could_ have found ways of writing it that would have made it slow
though.
As for licensing, you'll just have to go
with what suits you best. If you want full control over who's using
your code (and don't care for linking with GPL code) just go with your
own license. If you don't care who uses your code, or for what, go for
something BSD-like (PD is ambiguous I think). If you only want to
prevent use of your code in proprietary projects, using a GPL license
is probably the simplest (if nothing else for compatibility with all
the other GPL code out there).
You could always seperate the core emulation code to one or more
libraries that don't allow forking, but allow linking with most things.
I don't share your fear of forking though. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Thu Aug 02, 2007 11:56 pm Post subject: |
|
Might I suggest something?
An expiration on your license, after which it becomes public domain?
Basically, pre-expire your copyright, instead of making everybody wait
20 years after you expire to be able to do whatever they want with it.
Say, 10 years, or upon your death, whichever comes first.
I say this because you'll grant permission to individuals to fork, but
they don't have permission to further extend it, so if you disappear
from the scene or get hit by a bus, bsnes will languish in the hands of
the few you'd granted permission to, and can never be passed on from
them onto others. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 02, 2007 11:59 pm Post subject: |
|
Yeah, no problem. I'll set an expiry clause of 2015-01-01 or so. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Aug 03, 2007 2:14 am Post subject: |
|
byuu wrote: |
Ok, so far we have:
Current license: (2 votes) Verdauga Greeneyes, henke37
- I still grant license exemptions upon request [ala OSX port], but may
prevent contributions to bsnes in the future, and also rules out the
chances of someone taking over development of the older version
- Best choice if you're interested in maintaining the integrity of
bsnes at all costs (even the current version has ~99.9+% compatibility,
so it isn't as if you're being left in the dark if development of the
old core stagnates due to the new PPU core)
GPLvN: (2 votes) Jipcy, Lazarus
- The copyright reassignment clause I will need may limit development,
or completely fork development away from me [ala XFree86->Xorg] --
but this might be for the best public interest; most likely to result
in more contributions
- Best choice if getting the best possible open source version of
bsnes, regardless of who develops it (possibly won't be me), is your
top preference
PD: (1 vote) Nach
- Unlikely to result in more contributions, as virtually nobody gives
their code away PD, but should not result in less than the current
license. Most likely to result in closed-source, binary, and commercial
versions of bsnes; but that doesn't mean those versions won't have
worth, they may bring amazing speedups or features like savestates, etc
too [ala Wine->Cedega]
- Best choice if getting the best possible version of bsnes, at any cost, is your top preference
(need Snark to vote again after I clarified some of his concerns)
(anyone can alert me if they'd like to change their vote, eg if I've misunderstood their vote) |
Bah, not that I'm an authority on the matter but put me down for the GPLx.
Basically I would like the code to be "public available" (whatever that
means edit:ex: allow derivative works without necessiting the author's
consent, allow the code to be used as a reference) BUT I would like to
prevent anyone from claiming the code for themselves, preventing any
crappy company in re-approating the code for themselves and to prevent
any individual(s) in nuking the (original source) code from the face of
the net.
One important point imo is the potential for "code longetivity". That
is, I'd like the original, untouched code to continue to exist (while
permitting derivative works) many decades from now. Essantially,
preventing the code from dissapearing (in theory that's probably
impossible as the sun itself is doomed to disappear,so ultimately every
piece of information known to Man will one day inevitably disappear but
that's entering the realm of philosophy)...Well, at the very least, not
for a long time.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 03, 2007 8:23 am Post subject: |
|
I've
posted a new private WIP. This one just adds the cheat code editor back
in again. Feedback on how it works is appreciated. You'll notice it's a
lot simpler than v0.019's cheat editor ... I was going for simplicity
this time. Editing a code means deleting and re-adding it (or edit the
text file directly). Yes, I realize it's damn annoying entering codes
because the emulator detects your keypresses as controller presses
(unless you're using a joypad). Sorry, I still need to add code to
determine if the active window is the main emulator window or not for
GTK+ before I can fix this on both ports.
Hopefully I can get that in before v0.022, but no promises. Worst case,
I'll add a dummy Window::active() function that always returns true for
GTK+ if needed.
The cheat editor works the exact same on Windows and Linux, so this
should be the first release to allow Linux users to use it.
Looking more at how useful bsnes is in its' current form ... I'm simply
not going to be able to walk away from it. Fuck it, I'll just have to
split the emulator and maintain two separate versions. It may cost me
some time, but whatever. It'll be good practice in trying to streamline
things to share as much code as possible. I'll keep them together in
one version as long as possible, too (using #defines and such).
If I do this, any suggestions on how to differentiate the two versions?
Different names? Different acronyms after bsnes (eg bsnes/AE and
bsnes/SE ...)? Different icons?
Quote: |
One
important point imo is the potential for "code longetivity". That is,
I'd like the original, untouched code to continue to exist (while
permitting derivative works) many decades from now. |
No matter the license, that won't change. People can close derived
works with PD, but it's their code that they added which becomes
closed, not mine. It won't make my code cease to be.
It's not like it all matters that much. Regardless of license, anyone
is always free to get PD access to my code by asking. This is just me
trying to get a public consensus on whether or not I should allow
people to use my code without my permission, and to what extent I
should allow it.
I was hoping the votes would be less 'all over the board' like the
Uniracers fix ... this vote isn't going very well. Sigh.
It'd be annoying specifying licenses on everything. Maybe I'll just
bundle the core components (cpu, smp, ppu, dsp, memory, chip sans c4 (I
don't own the rights to that)) and stick them in a separate
downloadable archive that's PD [or GPL w/permission exception]. That
way, I'm giving away the stuff that's important and can help others the
most, the emulation core. If someone can't be bothered to ask me for
mine, then they can write their own GUI. Call the package something
like 'libbsnes'. Meh.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Aug 03, 2007 8:50 am Post subject: |
|
If
you feel you can maintain both versions, then cool; I suppose this
means more rewrites/code cleanups will make it into both versions? And
how about bsnes Stable and bsnes Experimental (slow!)? That should give
enough warning and it's more descriptive than acronyms (you can always
name them bsnes/S and bsnes/E elsewhere).
As for
the license stuff, myself I find myself almost changing my mind
whenever new arguments come up, but I still think that so long as you
are around, asking permission should be fine. It's not like you can't
get at the source code easily enough, it would only be when someone
wants to distribute something that includes bsnes' code (or something
based on it) that licensing 'issues' might come up, at which point
asking you if it's okay is a lot easier than hiring a lawyer to go over
the license with a microscope  |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Aug 03, 2007 9:45 am Post subject: |
|
Why
do you need two versions anyway? At worst a second code path for the
PPU that is used depending on the time since the last relevant
register/RAM change should be sufficient. You know this. All it takes
is for you to want to do it, and I can't see why you don't. I won't
bother mentioning this again. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Aug 03, 2007 2:43 pm Post subject: |
|
byuu wrote: |
Thanks for your input, I'll put your vote down as PD for now. |
What? I didn't say PD.
byuu wrote: |
There's really not a whole world of difference between eg Apache, CDDL,
BSDL, etc, as I believe they allow closed source derivatives (could be
wrong on some of those).
|
I didn't list BSD. And I wouldn't choose anything that allows closed source derivatives.
With just a quick glance of what's out there, I'd strongly consider one of these two:
http://www.opensource.org/licenses/mozilla1.1.php
http://www.opensource.org/licenses/cddl1.php
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 03, 2007 3:22 pm Post subject: |
|
sinamas wrote: |
Why
do you need two versions anyway? At worst a second code path for the
PPU that is used depending on the time since the last relevant
register/RAM change should be sufficient. You know this. All it takes
is for you to want to do it, and I can't see why you don't. I won't
bother mentioning this again. |
I've been over this before ...
I don't program like that. Remember when I spent the better part of a
year trying to emulate IRQs by range testing (eg testing once per
opcode)? I never did get it working right in all cases. I finally gave
up, and implemented it just like the hardware would do it: test every
single clock tick. And what do you know? Within two days I had it
working perfectly. Sure, it slowed the entire emulator down by 40%, but
it works better than any other emulator's IRQ code. In fact, SNES9x is
experiencing the old F1 Grand Prix + Sink or Swim IRQ regressions right
now with v1.51.
Adding two PPUs, and performing all kinds of range testing is going to
be too complex to try and maintain. Especially during the initial
implementation, where we don't know what to expect, nor what will be
required and what won't. I'm trying to emulate what is essentially a
DSP (or more accurately, something that has its' own internal program
... I just poke at it with registers), and one that only has analog
output (at least for me, I lack an RGB modded SNES), that we have
virtually zero knowledge on, apart from our scanline renderers. I'm not
going to deal with the hassles of a more complex implementation when
I'm already not sure if I can even pull this off at all.
And yes, this is one of the major reasons why my emulator is 10+ times
slower than everyone else's. I'm perfectly aware of that. When I get
everything perfect, then we can let someone else go back, use my
reference implementation, and make something fast and
accurate, with completely unreadable source code to match. Say what you
will about my approach, but I think my bug list on page one of this
thread speaks for itself.
Quote: |
I didn't list BSD. And I wouldn't choose anything that allows closed source derivatives. |
Oh, wow. I'm sorry, I didn't realize those were copyleft licenses.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Aug 03, 2007 5:10 pm Post subject: |
|
There
are other ways than range testing. I tend to use my own event systems
where events are scheduled as needed. What works well for me may not
work well for you I guess. I don't think you can get me on the accuracy
of what I've written though.
A big seperate PPU
code path would be worst case and rather unlikely, but I'd consider it
better than maintaining two versions of bsnes.
Trust me, I know hardware testing is a pain. My collection of tests
I've written (mostly in a hex editor) for the GBC counts roughly 1200
files atm. That includes mid-line PPU stuff that only affects display,
as well as a previously unknown insane mode3 timing algorithm that
depends on a plethora of register value combinations at different times
and weird combinations of all sprite positions (relative to scx,
overlap, previous sprites etc), this is every line and affects hdma
timing, mode0 irq, vram/oam access, register values and other things.
The SNES is no doubt more complex, but the GBC has some pretty weird
shit that afaik noone besides me even knows about. I don't think anyone
imagined it would be that bad.
I obviously agree with putting accuracy and clearity first. I just find
that there are often more efficient ways of doing things that I find
just as clear. You definitely need to use what ever method is most
clear to you. You've certainly done an awesome job as far as accuracy
goes this far.
Quote: |
Nach wrote: |
I didn't list BSD. And I wouldn't choose anything that allows closed source derivatives. |
Oh, wow. I'm sorry, I didn't realize those were copyleft licenses.
|
I was only aware that the CDDL was. There were some changes for the GPL
v3 for compatibility with at least the Apache license IIRC.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 03, 2007 6:08 pm Post subject: |
|
Quote: |
What
works well for me may not work well for you I guess. I don't think you
can get me on the accuracy of what I've written though. |
Yes, basically what I was going for, perhaps too defensively. I also
certainly don't doubt your abilities -- I'm convinced your emulator is
every bit as hardware accurate as any approach I tried would be. You go
the extra mile to optimize your code on top of everything else, which
is very admirable, it's just not my cup of tea, and never has been with
the development of bsnes.
Quote: |
A
big seperate PPU code path would be worst case and rather unlikely, but
I'd consider it better than maintaining two versions of bsnes. |
Trust me, I really want to avoid two versions of bsnes, too. But to
give you an idea, it takes 4922 clocks @ 1000 clocks/sec for 100mhz
co_switch calls. With my S-PPU requiring 10.5mhz (*2 to and from), that
means it will take ~1050ms for one emulated second. Meaning it would be
literally impossible to get 60fps on this machine. Cothreads really do
work great for CPU<>SMP communications (even if they kill
savestates) because the CPU is so complex and because you can run them
out of sync so well, but they just bomb terribly for SMP<>DSP and
CPU<>PPU.
One approach would be to rewrite my scheduler. Use libco for UI
<> CPU <> SMP, and use enslavement for SMP <> DSP and
CPU <> PPU (possible on the last two because they share the same
crystal clocks ... but enslavement requires state machines).
You mention using events and such. This won't work, I need those
v/hblank pins and latch counters to be updated by the PPU. The S-CPU
needs to poll the S-PPU every single clock tick to trigger IRQs from
it. The IRQs are based on the PPU's screen position.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Aug 03, 2007 6:28 pm Post subject: |
|
byuu wrote: |
You
mention using events and such. This won't work, I need those v/hblank
pins and latch counters to be updated by the PPU. The S-CPU needs to
poll the S-PPU every single clock tick to trigger IRQs from it. The
IRQs are based on the PPU's screen position. |
The screen position is predictable on register changes, so events are
quite possible, it's just a matter of who controls the events (the PPU
or the CPU). Even if the CPU polls the PPU for such things mid-opcode,
this could be a fast inline function that only really updates if
necessary. If you don't like such an approach I guess it doesn't matter
anyway though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 03, 2007 8:29 pm Post subject: |
|
Hmm,
I suppose I could always just say the hell with hardware literalism and
design some sort of middle-ground latch counter class. Then the S-CPU
and S-PPU can run with their own relative counter positions. The shared
latch counter class can keep track of the interlace setting that fucks
with the counters. S-CPU can test for IRQ triggers with it, and S-PPU
can determine what to draw with it. Now, I only need to sync up on
writes to $2100-$213f. Only large DMA transfers to $2118,$2119 should
really screw me, and I can exempt those anyway since mid-frame VRAM
writes are expressly forbidden anyway.
This will
ruin my plans to actually implement the S-CPU counters as hardware
would, where the counters wrap upon S-PPU signalling, but oh well. I
need to get the context switches under control, 1050ms per emulated
second is insane.
I'm not interesting in prediction and undoing events, though. I'll just sync up when it's possible for something to change based on the other processor.
And basically, with my design, neither the CPU nor PPU are in control.
They are completely independent. They sync only by way of a
CPU<>PPU relative cycle counter. When CPU runs 10 cycles, the
counter increases by 10, when PPU runs 10, it reduces the counter by
10. You know the CPU is head when counter >= 0, and PPU is ahead
when counter < 0. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Aug 03, 2007 9:29 pm Post subject: |
|
I
guess my ignorance for hardware literalism is the main reason we see
things differently. You won't be able to know for sure how everything
is done in hw anyway (without literally picking it apart), and I guess
I consider all the unnecessary work done by the emulator as kind of
ugly too. It just doesn't seem worth it to me in general. In the end, I
don't care as long as the code is nice, clear and accurate.
If hardware literalism is an important goal for you, you may not want
to compromise it for performance. I guess it comes down to a weighing
of priorities. I can see how hardware literalism often implies clarity
too. In any case you should probably do one change at a time. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 03, 2007 9:45 pm Post subject: |
|
Of
course I can't get it perfect. I don't expect to emulate things down to
individual transistors or anything. But if the counter hardware is in
the PPU, then I want the counter emulated in my PPU, and not in my CPU.
If it's in the CPU, then the code is no longer self documenting. It may
provide identical outputs, but it's not how the hardware was designed.
Ideally, I'll complete the PPU (unlikely, but who knows). At that time,
we can go back and optimize everything. Take sacrifices like scanline
renderers, opcode cores, 32khz DSP, etc. I think the result could be
extremely fast and compatible, while still being written in a portable
programming language. If ZSNES continues to try and move toward bsnes'
accuracy level, then there will be a prime opening for a lightweight,
superfast SNES emulator. Not that I have any plans at the moment to do that or anything ... |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Aug 03, 2007 10:36 pm Post subject: |
|
byuu wrote: |
But if the counter hardware is in the PPU, then I want the counter emulated in my PPU, and not in my CPU. |
Note that I wouldn't organize my code in nonsensical ways either, but
I'll happily skip updating some status registers for a few ticks, if
they're not being read anyway.
byuu wrote: |
...we can go back and optimize everything. Take sacrifices like scanline renderers, opcode cores, 32khz DSP, etc. |
Those are two different things though
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Aug 04, 2007 10:57 am Post subject: |
|
byuu wrote: |
I'm trying to emulate what is essentially a DSP (or more accurately,
something that has its' own internal program ... |
This sounds like perfect emulation of it will require the user to have
copyrighted, extremely hard to get software. Making the amount of
people who can legally use it about 2 people in the world.
My comment about the license was not that I favor or unfavor any of the
options, but that I suggest that you don't limit yourself to existing
options.
I wrote my own license for my ircbot library, because I wanted to grant very specific rights.
Gpl is needlessly restrictive. Bsd and pd is pretty much giving up on
having restrictions. A middle ground is what most people truly want.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 04, 2007 12:11 pm Post subject: |
|
Alright,
it's been a few days since the private WIP was up. I haven't heard any
new bug reports from that, so ... I posted bsnes v0.022 on my homepage.
I made sure to be extra boastful about its' compatibility to attract
new testers looking to spite me for it. Anyone want to take bets on how
quickly a new bug is discovered? ;) |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Aug 04, 2007 3:53 pm Post subject: |
|
I
was just testing bsnes 0.0.22 against an older version (well,
0.0.19wip40 was the only one I had lying around so I used that) and I
noticed something odd. I don't know if this was intentional and I just
forgot, but in Chrono Trigger atleast, bsnes 0.0.22 is 3 pixels wider
than 0.0.19wip40. This has a profound effect on the image, blurring
some areas and sharpening others. Is this because of the aspect ratio
tests we did? (it's such a small difference that the thought only just
now occurred to me..) In that case I suppose it's probably better to
play the game at 4x or 5x scale. Which I usually do anyway.
bsnes 0.0.19wip40:
bsnes 0.0.22: |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Aug 04, 2007 5:08 pm Post subject: |
|
Hmm,
neither one of those images seems worse than the other to me. I think
the blurring from the image being stretched is just appearing in
different places for both.
Congrats on the new release, byuu, and on squashing all those bugs. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Aug 04, 2007 5:24 pm Post subject: |
|
Yeah,
they both look about as good to me too; I guess 0.0.22 has the correct
aspect ratio though. I did notice however that stretched to 4x or 5x
the blurring still occurs in the same places, rather than averaging
out; I suppose this is just the way bsnes renders the image though. |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Aug 04, 2007 7:12 pm Post subject: |
|
Congratulations byuu, for getting this far into development 
I was wondering though, with each filter I'm getting a solid 60/60
(rarely 59) but NTSC. Is true if I say that the NTSC filter requires
something better than your average Core 2 Duo, because of the improved
accuracy? I'm getting some framedrops with the filter on (between 55
and 60).
_________________
"Change is inevitable; progress is optional" |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 04, 2007 10:26 pm Post subject: |
|
Thanks all for the congrats!
Even though I know bugs will eventually be found, that's all right. We
can never verify 100% compatibility no matter what, after all. It will always be a 'wait and see' game when all known bugs are resolved. But I knew this was the best we could do, and I finally got there :D
I think bsnes needs to refocus now. Not right away, but in the coming
months. I have (imo) the best tradeoff to 100% compatibility and speed,
and that release is already out there as v0.022. In the future, I think
the cores should be split up. I have
to split the CPU and PPU anyway to save the scanline renderer. So,
split the other two cores and get: fast, opcode-based CPU and SMP,
scanline-based PPU, and sample-based DSP; making use of enslavement
techniques instead of true threading. I believe we could then have a
bsnes version that runs 98-99% of games, that can support savestates,
with very few regressions, and that runs on mid-range hardware like
1.0-1.5GHz machines. Then we can also have the research version for
hardware enthusiasts that throws speed out the window and goes all out.
I agree with points made by FitzRoy et al in the past that it sucks to
lose the current accuracy vs speed tradeoff point, but bsnes v0.022 is
already out there for people with the hardware to use it. What am I
supposed to improve or change in it at this point?
Quote: |
I was just testing bsnes 0.0.22 against an older version |
Hah, for a second I thought you had my compatibility claim beat in a mere three hours :P
Yes, I changed the algorithm based on all that discussion we had about PAL vs NTSC aspect.
I know there's one tiny problem that non-aspect-corrected 1x scale
blurs with the D3D renderer. You can set the DD renderer in the
advanced config panel if that bothers you. I have to do it for 1x
screenshots, myself.
Quote: |
I did notice however that stretched to 4x or 5x the blurring still occurs in the same places, rather than averaging out |
I don't know why that might be. The scaling is done by the video card
hardware, and not bsnes. I transfer the video at 256x224, and the video
card scales it to blit to the screen.
Quote: |
I
was wondering though, with each filter I'm getting a solid 60/60
(rarely 59) but NTSC. Is true if I say that the NTSC filter requires
something better than your average Core 2 Duo, because of the improved
accuracy? |
Hmm, that's possible. NTSC is a fast filter, but combined with a monstrous CPU hog like bsnes ...
You have my apologies for the speed problems. I think things will start
to change from here on out. Maybe in a few months I can give you
something more useful.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Aug 04, 2007 11:16 pm Post subject: |
|
Hmm,
it might be the video card taking the easy way out then, I dunno. If I
have time I'll have a closer look at the effect, but IIRC it looks like
the aspect ratio correction is done first to the 256x224 image so you
get a small image that's blurred in places, only after which the image
is scaled up. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Aug 05, 2007 1:41 am Post subject: |
|
byuu wrote: |
I think bsnes needs to refocus now. Not right away, but in the coming
months. I have (imo) the best tradeoff to 100% compatibility and speed,
and that release is already out there as v0.022. In the future, I think
the cores should be split up. I have
to split the CPU and PPU anyway to save the scanline renderer. So,
split the other two cores and get: fast, opcode-based CPU and SMP,
scanline-based PPU, and sample-based DSP; making use of enslavement
techniques instead of true threading. I believe we could then have a
bsnes version that runs 98-99% of games, that can support savestates,
with very few regressions, and that runs on mid-range hardware like
1.0-1.5GHz machines. Then we can also have the research version for
hardware enthusiasts that throws speed out the window and goes all out. |
I really have to agree with that direction at this point, but I think
there are going to be some difficult tradeoff decisions associated with
this in the future. Let's say, for example, that you have a choice
between speeding up bsnes by 100% and losing no compatibility (using
enslavement, possibly range-testing, and global simplification hacks
but retaining cycle-based) versus speeding it up by 200% and breaking
2% of games (going opcode + above techniques). Which do you choose? I
mean, a user really only cares about speed and perceived accuracy, and
the first option would do that better than .022. The code would use
these safe simplification techniques that you were unwilling to do when
you wanted one version and self-documentation. To us, games would play
exactly the same as .022 but with significant performance benefits and
savestates.
However, I know it's probably a bad assumption to see other opcode
emulators' bugs and think that a bsnes with opcode would inherently
have timing bugs. Do you think that it's theoretically possible that by
starting with something so accurate and writing it down to that level,
that perceived compatibility could achieve 100% even with opcode based
cores?
|
|
qwerty` Rookie
Joined: 17 Feb 2007
Posts: 29
|
Posted: Sun Aug 05, 2007 9:04 am Post subject: |
|
... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 05, 2007 10:30 am Post subject: |
|
Wrote
up that article I mentioned the other day. In case anyone enjoys
reading page after page of meaningless banter, you can check it out
here:
http://byuu.cinnamonpirate.com/?page=articles/emulation
FitzRoy wrote: |
Do
you think that it's theoretically possible that by starting with
something so accurate and writing it down to that level, that perceived
compatibility could achieve 100% even with opcode based cores? |
I believe I can do better than current opcode-based emulators with all
of the low level stuff I know (eg I could trick DMA bus sync by always
adding 18 clock cycles per DMA transfer ... the timing would average
itself out), but I don't believe it would be possible to reach 100%
compatibility with opcode cores.
!!!
No, seriously. If you were going to say something, positive or
negative, please feel free. I'd be honored to hear what the author of
SNEqr has to say about me or my work, as your work was somewhat of an
inspiration to me long ago.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Aug 05, 2007 11:43 am Post subject: |
|
Nice
article, byuu. One thing, I don't think the hope that in 10 years,
computers will be fast enough even for the cycle-based PPU is at all
unrealistic. By then, hopefully our CPUs will be using ballistic
transistors or something similar and advanced silicon photonics.
Ballistic transistors should, atleast in theory, be more than an order
of magnitude faster than anything we can make today, and silicon
photonics might make libco unnecessary - atleast in its current form. I
do think you'll have to look into using more than one core eventually,
as there's a good chance we'll be ending up with a lot of specified
co-processors in our systems (AMD's proposed CPU packages, whatever
they're called), and it'd be a shame if none of that could be put to
use.
As for ruining bsnes for us: it may just be
my opinion, but we've -got- 0.0.22, and maybe a slightly less accurate
version coming up for slower systems - now what will keep me checking
this topic daily will be your progress on sPPU, because like all
scientific progress, it's exciting. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 05, 2007 12:31 pm Post subject: |
|
Impressing article Byuu,
I think newer cpu's could help bsnes lower the system requirements
When the new intel cpu's come out,they claim up to 60% faster execution of the some types of code.
Imagine if you will, a bsnes version that is SSE4 optimised and has multicore support for 2 or more cores/threads
When talking about sync delays of up to 1200ms the delay between cores
seems negligable and thus support for multiple cores seems more
logical, you already stated that some parts of bsnes can already be
executed seperately.
assuming a 4 core CPU
1st core for main bsnes thread
2nd core for sound
3rd core for video
4th core for something else
core 2, 3 and 4 will mostly be waiting for the results from core 1 but
at least their execution will have no impact on the cpu uages of core 1.
For accuracy's sake, how long would it take to syncronise 2 sets of emulated information run on 2 different core's?
Edit:
I found an interesting link on wikipedia
http://en.wikipedia.org/wiki/Speedup
And have you tried this new compiler?
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/fwin/278834.htm
from the changelog:
Advanced Optimization Features
Software compiled using the Intel Visual Fortran Compiler for Windows
benefits from advanced optimization features, a few of which are
explained briefly here, with links to more complete descriptions:
Multithreaded Application Support, including OpenMP and
auto-parallelization for simple and efficient software threading.
Auto-vectorization parallelizes code to utilize the Streaming SIMD
Extensions (SSE) instruction set architectures (SSE, SSE2, SSE3, SSSE3,
and SSE4) of our latest processors.
High-Performance Parallel Optimizer (HPO) restructures and optimizes
loops to ensure that auto-vectorization, OpenMP, or
auto-paralllelization best utilizes the processor's capabilities for
cache and memory accesses, SIMD instruction sets, and for multiple
cores. This revolutionary capability, new for 10.0, combines
vectorization, parallelization and loop transformations into a single
pass which is faster, more effective and more reliable than prior
discrete phases.
Interprocedural Optimization (IPO) dramatically improves performance of
small- or medium-sized functions that are used frequently, especially
programs that contain calls within loops. The analysis capabilities of
this optimizer can also give feedback on vulnerabilities and coding
errors, such as uninitialized variables or OpenMP API issues, which
cannot be detected as well by compilers which rely strictly on analysis
by a compiler front-end.
Profile-Guided Optimization (PGO) improves application performance by
reducing instruction-cache thrashing, reorganizing code layout,
shrinking code size, and reducing branch mispredictions. |
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Aug 05, 2007 4:11 pm Post subject: |
|
That seems to be a Fortran compiler, not C++.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 05, 2007 7:37 pm Post subject: |
|
Multicore, at least as it stands now, won't help much at all.
Multicore is best when you have very large chunks of your program to
break up into separate threads. For example, say you want to convert a
folder of 2,000 BMP images to PNG images. You could easily batch that
across all the cores you have evenly.
But an SNES doesn't work like that. Perhaps at a higher level of
emulation, it could help as it has with PS2, etc emulators. But when
you start getting really low level into this stuff, especially with the
S-CPU and SA-1, or S-CPU and S-PPU ... you start needing to sync your
separately running processes millions of times a second. The reason I
wrote libco is because a context switch there is several hundred times
faster than a context switch for a true thread, by use of the kernel.
From what I've seen, using mutexes on a dual core processor to sync two
threads is just as bad an actual context swap. It's most likely because
these processors are designed with super deep pipelines and try and run
things in a steady stream. But when you tell the processor to suddenly
halt itself, and wait on another processor, it's kind of like stopping
a very fast conveyor belt with lots of packages on it instantly. Not
very pretty at all.
So, I think if processors start aiming away from the pipelining, and
give much tighter controls over the multiple cores to control without
the use of kernel-level system calls ... I think multicore could be the
way to go. But as it stands today ... it's only useful when you don't
have to sync two separate threads more than a few thousand times a
second. And bsnes would put that number around 10+ million times a
second to get the precision I have. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Aug 05, 2007 8:28 pm Post subject: |
|
thanks for the explenation, too bad though.
however that doesnt mean that you couldn't put something else on a
second core, like the video renderer and the filters
creaothceann , good catch, here is the right link and info
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cwin/279578.htm
dvanced Optimization Features
Software compiled using the Intel C++ Compilers for Windows benefits
from advanced optimization features, a few of which are explained
briefly here, with links to more complete descriptions:
Multi-Threaded Application Support, including OpenMP and
auto-parallelization for simple and efficient software threading.
Auto-vectorization parallelizes code to utilize the Streaming SIMD
Extensions (SSE) instruction set architectures (SSE, SSE2, SSE3, SSSE3,
and SSE4) of our latest processors.
High-Performance Parallel Optimizer (HPO) restructures and optimizes
loops to ensure that auto-vectorization, OpenMP, or
auto-parallelization best utilizes the processor's capabilities for
cache and memory accesses, SIMD instruction sets, and for multiple
cores. This revolutionary capability, new for 10.0, combines
vectorization, parallelization and loop transformations into a single
pass which is faster, more effective and more reliable than prior
discrete phases.
Interprocedural Optimization (IPO) dramatically improves performance of
small- or medium-sized functions that are used frequently, especially
programs that contain calls within loops. The analysis capabilities of
this optimizer can also give feedback on vulnerabilities and coding
errors, such as uninitialized variables or OpenMP API issues, which
cannot be detected as well by compilers which rely strictly on analysis
by a compiler front-end.
Profile-guided Optimization (PGO) improves application performance by
reducing instruction-cache thrashing, reorganizing code layout,
shrinking code size, and reducing branch mispredictions.
Optimized Code Debugging with the Intel® Debugger improves the
efficiency of the debugging process on code that has been optimized for
Intel® architecture.
EDIT:
What would i need to compile a windows build of bsnes with visual
studio? and what would i need to compile with GCC? (besides installing
these basic apps) |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun Aug 05, 2007 9:35 pm Post subject: |
|
byuu, I'm starting to read your article. I've found a few possible mistakes in it.
Quote: |
To summarize, I covered what I perceived as the primary problem with emulators: their focus for only worrying if software for said hardware ran inside the emulators properly.
I can justify that, because I do not claim to have achieved a 100% compatible SNES game emulator, but a 100% compatible SNES emulator.
But you give up just a little speed, and all of the sudden your compatibility grows by a lot.
|
OK, I just finished reading it. Sorry about the nitpicking. I think the
only important correction up there is the second of the three. Other
than that, though, very well written. Very interesting overall. The
biggest thing I noticed is that you seem to be very self-conscious of
your decisions and such. I've really enjoyed following this thread and
your development over the past few years. I've learned a lot about SNES
emulation myself. I only wish that I had the programming skills to help.
I'm really looking forward to seeing your progress with the new PPU.
I think in the end, once you're satisfied that you have created the
best emulator you possibly can, you should definitely release it to
public domain. One benefit of that is that Nintendo or any other game
manufacturer could use the code in future game consoles and in future
versions of the Wii Virtual Console or XBLA. And then we could all
enjoy pretty much all SNES games on these future consoles.
Until you're pretty much finished though, some other license would
probably be best. Again, not that I know much about the various
licenses, but a version of the GPL seems like the best bet in terms of
code compatibility and attracting potential developers to improve
pre-bPPU versions of bsnes.
As always, don't depend too much on the opinions of your userbase
and/or popular opinion. Doing your own thing and following your own
heart in opposition to the commonly held opinions seems to have served
you in the past. Even if you create a completely unusable emulator, the code will be there; the entire SNES will be there, written in C/C++ (whatever), for future generations of hardware and people to use it.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Aug 05, 2007 11:16 pm Post subject: |
|
Well,
hopefully you guys don't mind being a little patient. I now have
multiple side projects that I need to work on, which is good because I
need the time anyway to reflect on how I want to start on the new
renderer. So, don't expect any news on the S-PPU rewrite anytime soon.
I also want to try and setup my site to allow updates a little easier,
especially to SDP. Perhaps I can try and document things as I go along (hahah, like I said for everything else thus far).
Quote: |
byuu, I'm starting to read your article. I've found a few possible mistakes in it. |
Thanks for pointing that out, I'll go through and fix them.
Quote: |
I
think in the end, once you're satisfied that you have created the best
emulator you possibly can, you should definitely release it to public
domain. |
Yeah, definitely. Once it's discontinued by me, I see no reason to lock up the code for the next century or so.
Quote: |
What
would i need to compile a windows build of bsnes with visual studio?
and what would i need to compile with GCC? (besides installing these
basic apps) |
Visual C++/Windows just needs the free Visual Studio 2k5, even express
edition works fine. You also need the platform SDK and DirectX SDK, and
also GNU make and nasm.
GCC/Linux, you just need to install the dev libraries. libao-dev,
libgtk2.0-dev, libxv-dev and yasm (64-bit) or nasm (32-bit).
The Intel compiler sounds really neat. If anyone could try it out and
post a build of bsnes using it, I'd really appreciate that.
Specifically, see if PGO works without crashing like Microsoft's shoddy
compiler. Also, the auto parallelization sounds neat. I doubt it will
help much at all, especially this early on, but it's definitely worth a
shot. If it's more than 10% faster than my MSVC builds, I'll switch
compilers.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Aug 06, 2007 1:52 am Post subject: |
|
A
very good article byuu, and I would say even more interesting to those
that doesn't follow bsnes' progress on this forum/thread. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Aug 06, 2007 4:06 am Post subject: |
|
byuu wrote: |
Almost
three years ago, I wrote an article on the state of emulation. I
focused primarily on the SNES, as it is the system I am most familiar
with. Unfortunately, that article has been lost to the sands of time. |
It's still available on the Wayback machine btw
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Aug 06, 2007 1:49 pm Post subject: |
|
a yes/no question.
does BSNES 0.22 windows, ttake advantage of multiple cpu cores and/or multiple cpu's?
i tried monitoring the cpu usage and found both cores to have pretty drastic cpu usage while bsnes was running.
_________________
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. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Aug 06, 2007 2:05 pm Post subject: |
|
byuu, I've got a few things to say:
1. Congratulations on reaching this milestone! Your efforts have made a
permanent mark on SNES emulation and perhaps all of emulation. It's
also an accomplishment worthy of respect when you have put your money
where your mouth has been for lack of a better phrase.
Hopefully your ideals and practices will help improve and/or shape the
future of emulation even after you are no longer involved. If nothing
else, BSNES is a shining case example of what can realistically be
accomplished with your ideals. Where there were doubters, now there
should be none. You've earned that much.
2.
Informative article. It gives good insight on BSNES, your feelings
about it, and the internal struggle with your ideals. Personally, I
like the explanation of each global hack, and why it is in place. This
article should be required reading for anyone wanting to criticize
BSNES.
3. What the hell did you do to your web page? Bandwidth aside, the old one/s were MUCH better. What's your typical monthly bandwidth usage?
4. Ok.. so now we have a 100% hardware compatible emulator. We have a
huge milestone. However, we have no debugger! That's a serious tragedy.
The audience that a 100% hardware accurate emulator MOST appeals to is
left out in left field. You're ready to move on from this milestone in
new directions, and leave the world's most accurate, usable SNES
emulator with no debugger. That just seems like a violation of a
commandment to me! Shouldn't the two go hand in hand in wonderful
marital bliss?
What are your comments on this? To fully reap the benefits of your
hardware accurate emulator, it should have a debugger so people can see
it! I'd say that's probably just as valuable as a dot based PPU
renderer. What do you want people to actual use BSNES for? Without a
debugger, it's only useful to play games and perhaps visal inspection
code I may write works, but it could be so much more useful. But that's
just me.
_________________
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. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 06, 2007 3:19 pm Post subject: |
|
Quote: |
It's still available on the Wayback machine btw |
Neat! Kind of cool seeing the parts I was wrong about, but I was at
least correct that I hadn't even scratched the surface yet.
I'll see if D will let me host that article again.
Quote: |
3.
What the hell did you do to your web page? Razz Bandwidth aside, the
old one/s were MUCH better. What's your typical monthly bandwidth usage? |
1. New site is easier to read, the old translucency thing blended with any inline pictures and text
2. New site is faster, the old site lagged badly to scroll even on a P4 system
3. New site takes less bandwidth, no pictures to load (~150k/user before)
4. New nagivation menu is superior, not as quick to navigate, but I
intend to add a lot more articles and programming page entries ... soon
the right content bar would've been multiple pages if I didn't organize
better
5. New site works better on lowres displays like a psp (yeah, not many people use those, but whatever)
I may not use a ton of bandwidth, but I also don't pay for hosting, so I want to conserve wherever possible.
Would you mind giving more constructive criticism next time? :)
I can still edit things. Were you wanting a low contrast version or something?
I'd actually like to get a bunch of backdrop images like AGTP, but I'm
really bad at art, so that isn't happening ... :/
Quote: |
However, we have no debugger! That's a serious tragedy. |
1. I lack savestates, so most of the usefulness of a debugger is lost
2. I'm trying to support Linux and its' userbase, despite how they act
because of my license, but I've yet to come up with a good way to
simulate my text console that I had on Windows
Otherwise, yeah. I miss the debugger, too.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Aug 06, 2007 3:55 pm Post subject: |
|
As
for the savestates, it is technically possible to do them with any
level of emulation accuracy, after all, people could at worst run bsnes
in a vm and snapshot that. I know that you can get the same effect
without running bsnes in a vm. All that is needed is to save what each
chip was doing and which one is next to run.
byuu, hear my wish:
Please implement some easy to emulate features that you don't have yet.
I am not talking about discarding your goal of a dot based renderer,
but I ask that you have another goal as side project:
Extend the compatibility definition to include known extra hardware like the mouse, the super scope and the multitap.
I believe that if you do this, you can actually fulfill your goal of as accurate emulation as possible even better.
Please take a week to implement the other controllers, I know that they
are not hard to implement and it is only going to increase the accuracy
of the emulation to do it.
It is worth the time, you are not just fixing one game, you will be
fixing more games then you can count on your hands. |
|
Lord Nightmare Rookie
Joined: 26 Nov 2004
Posts: 14
Location: PA, USA
|
Posted: Mon Aug 06, 2007 5:29 pm Post subject: |
|
>Oh,
man ... probably $10,000 or so per IC for high resolution pictures. And
since the chips are somewhat newer than the archaic stuff MAME works
on, there's probably multiple layers. I don't even think the diagrams
would help much.
Ogoun will decap chips for $90 each, but you're on your own for imaging said chips.
LN
_________________
"When life gives you zombies... *CHA-CHIK* ...you make zombie-ade!" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Aug 06, 2007 6:00 pm Post subject: |
|
I think the mouse request has already been addressed before. I would personally like to see in the future:
-Multitap support.
-SPC ripping (I don't think this is useless simply because other
emulators can do it and there are websites with incomplete libraries
and shitty rips)
-a "Pause Emulation" option added under "Settings" which also
automatically takes effect by default when the emulator is minimized.
(not only are there parts of games that can't be paused, but music
usually still plays when paused which can get annoying.)
-The remaining DSP chips emulated.
-On a minor note, I also think the "(off)" under frameskip is ugly and redundant and would look better if removed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 06, 2007 7:42 pm Post subject: |
|
So ... anyone have ideas on how to improve the website? :)
Quote: |
-Multitap support. |
Who wants to donate five joypads? :P
Would be nice ... most emulators feature auto rewinding and seeking
tricks to get a 'perfect rip', though. That's a bit out of my league. I
could do a 'dump the contents of SPC at exactly this point' option,
though ...
Quote: |
-a
"Pause Emulation" option added under "Settings" which also
automatically takes effect by default when the emulator is minimized. |
I could try ...
Quote: |
-The remaining DSP chips emulated. |
The emulation is imperfect, and kind of hard-coded into ZSNES and
SNES9x. But that's okay. If someone wants to help, I'll write the
stubs. I just need someone to write the opNN() functions. I don't have
time to port it myself.
Quote: |
-On a minor note, I also think the "(off)" under frameskip is ugly and redundant and would look better if removed. |
If more people agree, I'll remove it. I think it clarifies it's off.
Some emulators consider frameskip 0 to mean 'run as fast as possible'
... right? Hmm ...
Quote: |
Ogoun will decap chips for $90 each, but you're on your own for imaging said chips. |
Not very helpful :/
I could use someone to help with a PC<>PPU-1/PPU-2 interface to
the PC, though ... think kevtris or someone could handle that for maybe
$200-300?
Quote: |
Extend the compatibility definition to include known extra hardware like the mouse, the super scope and the multitap. |
I don't like mouse support ... too many headaches with that. I'll get to it eventually ... sigh :(
I guess I can at least start on a stub. Worst case, it'll only work on Windows for a while ...
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Aug 06, 2007 7:59 pm Post subject: |
|
byuu wrote: |
Would be nice ... most emulators feature auto rewinding and seeking
tricks to get a 'perfect rip', though. That's a bit out of my league. I
could do a 'dump the contents of SPC at exactly this point' option,
though ...
|
I thought ZSNES just delayed performing the dump until a new song starts... not hard, I'd guess.
byuu wrote: |
Quote: |
-On a minor note, I also think the "(off)" under frameskip is ugly and redundant and would look better if removed. |
If more people agree, I'll remove it. I think it clarifies it's off.
Some emulators consider frameskip 0 to mean 'run as fast as possible'
... right? Hmm ...
|
Just to clarify, the "0" should definitely stay. The "off" text could be removed, but IMO it's more descriptive the way it is.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Aug 07, 2007 12:22 am Post subject: |
|
byuu,
I know you have lots of requests right now,but before you move to the
new version/ppu renderer I wonder if it would be possible to bring back
the old true full screen and video configurations from the 0.18 era...
I was under the impression those were removed temporarily. Although if
you can't, it's no problems. V0.18 is extremely usable, even with it's
"poor" 99.9% compatibility : D |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Tue Aug 07, 2007 12:39 am Post subject: |
|
byuu wrote: |
So ... anyone have ideas on how to improve the website? 
|
A different scholor cheme perhaps. Asx it is now is quite good, despite
not being as "pretty". I find the agtp layout to be ugly, actually.
_________________
_-|-_
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 07, 2007 2:56 am Post subject: |
|
creaothceann wrote: |
The "off" text could be removed, but IMO it's more descriptive the way it is. |
I dunno. I guess I'm trying to understand why it's more descriptive
rather than just redundant. If frameskip is 0, then the emu is not
skipping frames. The implication seems clear. Can someone actually
confuse 0 as meaning it's "on" and skipping frames?
byuu wrote: |
Who wants to donate five joypads?  |
Hmmm, five you say? Should've said something earlier, I think I threw
some old ones away last week while cleaning my room.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Aug 07, 2007 6:00 am Post subject: |
|
MisterJones wrote: |
A different scholor cheme perhaps. |
I second this. I quite like blue, and the current scheme is a bit too pale for my liking.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Aug 07, 2007 6:10 am Post subject: |
|
heck,
if getting five gamepads ( I assume you mean SNES ) is what is
hindering multitap support I'd buy em new and ship them to you.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Aug 07, 2007 9:18 am Post subject: |
|
Well, I'm impressed.

...
'S been a while since I had a computer that was ALMOST fast enough to emulate the SNES. Ah, nostalgia.  |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Aug 07, 2007 9:44 am Post subject: |
|
You
know, we discussed the multitap on IRC the other day, and I gained a
reasonable amount of info. The multitap is a one bit addressing, two
one channel to two channel multiplexer. Know that bit stream for a
normal controller? There is two bit streams for two controllers at a
time with the multitap. The multitap selects what controllers to send
by the final IO pin in the controller.
The pin is btw hooked to the ppu position latches and used by the super
scope to know when the gun is pointed at the drawn point. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Aug 07, 2007 1:23 pm Post subject: |
|
byuu wrote: |
Quote: |
3.
What the hell did you do to your web page? Razz Bandwidth aside, the
old one/s were MUCH better. What's your typical monthly bandwidth usage? |
1. New site is easier to read, the old translucency thing blended with any inline pictures and text
2. New site is faster, the old site lagged badly to scroll even on a P4 system
3. New site takes less bandwidth, no pictures to load (~150k/user before)
4. New nagivation menu is superior, not as quick to navigate, but I
intend to add a lot more articles and programming page entries ... soon
the right content bar would've been multiple pages if I didn't organize
better
5. New site works better on lowres displays like a psp (yeah, not many people use those, but whatever)
I may not use a ton of bandwidth, but I also don't pay for hosting, so I want to conserve wherever possible.
Would you mind giving more constructive criticism next time? 
I can still edit things. Were you wanting a low contrast version or something?
|
There's not much constructive to give. It's more of a styling
preference. The new is one plain, colorless, and boring. Your old ones
were all nice colorful blends, stylish, and somewhat unique. This one
seems out of character for you based on the past history of your pages
that I can remember.
One large constructive critique I can give is you are now using a fixed
width layout. Why? Your previous one was fluid. I detest fixed width.
People just assume everybody uses the resolution it was designed for.
It doesn't' look so great with 40% blank screen on my screen. It's
inconsiderate (no offense) on the developer's part in my opinion.
You're going to be considerate about psp users, but not desktop users?
Something is wrong with that logic. You got it right before, the old
one looked good full screen, why did you change that aspect of it?
Quote: |
1. I lack savestates, so most of the usefulness of a debugger is lost
2. I'm trying to support Linux and its' userbase, despite how they act
because of my license, but I've yet to come up with a good way to
simulate my text console that I had on Windows
Otherwise, yeah. I miss the debugger, too. |
I disagree. Some of the debugger usefulness is lost without savestates,
but certainly not most. Your emulator still has SRAM saves. It would
also still do a fabulous job for any homebrew or splash screen or
anything where somebody is trying to get something up and running for
the first time on the SNES. BSNES was the best debugger for the job
when I was learning to use the SPC700 and the sound hardware. That's a
nasty cracker to debug sometimes when the problem can be the CPU side,
or the APU side.
The simultaneous CPU and APU debugging output was nice there, not to
mention knowing I could rely on the the DSP memory contents to be
correct was helpful, although I think that was before blarggs core
which would mean it would be even more reliable today.
Long story short, I wouldn't discount the usefulness of the debugger
just because of lack of savestates. Would it be more useful with
savestates? Certainly, but it's not completely useless without them
either.
_________________
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.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 07, 2007 3:13 pm Post subject: |
|
Quote: |
If
frameskip is 0, then the emu is not skipping frames. The implication
seems clear. Can someone actually confuse 0 as meaning it's "on" and
skipping frames? |
Well, alright. True enough. I'll remove '(off)' the next time I'm
working on bsnes. Remind me if I forget, please. Is it cool that I
leave the menu separator, then?
Quote: |
I second this. I quite like blue, and the current scheme is a bit too pale for my liking. |
Colors are RGB444 hex, eg #000 - #fff. If you'd like to recommend back
colors for the three sections (bg, header and body) I'll give them a
shot.
Quote: |
heck,
if getting five gamepads ( I assume you mean SNES ) is what is
hindering multitap support I'd buy em new and ship them to you. |
No, I could always just map up and start, and leave the rest unmapped.
It's more of a convenient excuse, really ...
Quote: |
'S been a while since I had a computer that was ALMOST fast enough to emulate the SNES. Ah, nostalgia. |
Strange, you can almost get full speed? Thanks for the bug report, I'll
slow things down for you in the next release ;)
Quote: |
You know, we discussed the multitap on IRC the other day |
They're supposed to work on either controller port, right? And how does
the Multitap-5 work, then? I'm sure that will be the very next feature
request :P
Quote: |
There's not much constructive to give. |
All I got from your response is to make the width 100% instead of
800px. I like fixed width because it guarantees a consistent look with
the image placement. But okay, I'll make it 100% again.
I'll work on a debugger eventually, too. I'm really, really backlogged
at present though. But I'll need one for that dot PPU anyway, so I may
as well work on the debugger first.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Aug 07, 2007 4:30 pm Post subject: |
|
henke37 wrote: |
It is worth the time, you are not just fixing one game, you will be
fixing more games then you can count on your hands. |
That means >1023, and I really doubt that many games have issues.
Edit:
I just read that monster article. Man byuu, you have to do something
about the colors, I don't like staring into a light bulb in order to
read.
Quote: |
A real SNES renders each pixel in real time, whereas bsnes, along with
every other SNES emulator ever released, renders an entire scanline at
a time.
|
Not true. Several SNES emulators used or offered tile based rendering.
And regarding your jab at UltraHLE, corn was faster than it, and ran more games.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 07, 2007 5:42 pm Post subject: |
|
Quote: |
I
just read that monster article. Man byuu, you have to do something
about the colors, I don't like staring into a light bulb in order to
read. |
Ah, yes. The Maddox defense, heh.
So start suggesting some color values :P
Quote: |
Not true. Several SNES emulators used or offered tile based rendering.
And regarding your jab at UltraHLE, corn was faster than it, and ran more games. |
Yes, NLKSNES and possibly the oldest ZSNES versions used tile
rendering. Didn't think it was notable enough to mention.
Same for UltraHLE. I'm familiar with the static recompiler, Corn. And
even UHLE can run more games if you want to add a few hundred hacks per
game to the ini file.
Both of those still make my point, at least. There certainly is an
element of skill to how you program an emulator, but in an optimally
programmed emulator, speed and accuracy are usually direct tradeoffs.
I'd have to say, the biggest problem I perceive is synchronization. The
more you have to do it, the more overhead you accumulate that goes to
'nothing'.
Speaking of which, there has to be a name for a half bell curve. Anyone know what it is? Example:

Last edited by byuu on Tue Aug 07, 2007 5:52 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Aug 07, 2007 5:49 pm Post subject: |
|
byuu wrote: |
Quote: |
I
just read that monster article. Man byuu, you have to do something
about the colors, I don't like staring into a light bulb in order to
read. |
Ah, yes. The Maddox defense, heh.
So start suggesting some color values 
|
White on black.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
MisterJones Veteran

Joined: 30 Jul 2004
Posts: 921
Location: Mexico
|
Posted: Tue Aug 07, 2007 6:18 pm Post subject: |
|
Nightcrawler wrote: |
One large constructive critique I can give is you are now using a fixed width layout. |
I didn't notice such thing before (probably because I have to check it
at work wih a tiny window). I have to agree with NC on that. Liquid
layouts are far better for use in many screen resolutions, and fits
your layout. You don't have to make it that it uses 100%, but at last
it adjusts its prpotonal width on different window sizes
_________________
_-|-_
|
|
paulguy Regular
Joined: 02 Jul 2005
Posts: 280
|
Posted: Tue Aug 07, 2007 8:23 pm Post subject: |
|
Quote: |
Speaking of which, there has to be a name for a half bell curve. Anyone know what it is? |
Squared relationship
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Aug 07, 2007 9:43 pm Post subject: |
|
I'm thinking hyperbole, personally. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 07, 2007 10:06 pm Post subject: |
|
I have no idea what a 'squared relationship' is ... no matches on Google Images that are related to graphing.
A hyperbole looks like this: perso.orange.fr/jean-paul.davalan/anl/curves/hyperbole.png
While it's mostly good, it's a bit too exaggerated. I should just get a
graphing tool and make up a good y= rule for what I'm looking for. |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Aug 07, 2007 10:50 pm Post subject: |
|
byuu wrote: |
A hyperbole looks like this: perso.orange.fr/jean-paul.davalan/anl/curves/hyperbole.png
While it's mostly good, it's a bit too exaggerated. I should just get a
graphing tool and make up a good y= rule for what I'm looking for. |
Yeah, my hyperbole uses the following formula: y = 10/(x + .75) - .75
because I found the standard too extreme. (Domain: [0,10], Range:
[0,10] (if those are the right terms anyway.. English isn't my first
language so I'm vague on things like that))
As for a squared relationship.. parabole?
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Tue Aug 07, 2007 11:35 pm Post subject: |
|
hyperbola
parabola
hyperbole is exaggeration.
_________________
Why yes, my shift key *IS* broken. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Aug 07, 2007 11:53 pm Post subject: |
|
Heh, thanks for the correction No such issues in Dutch.. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 08, 2007 12:03 am Post subject: |
|
Hmm, both of these graphs look like they express the point I'm getting at:
y=1.35^x
y=15/x
I like that Wikipedia article. What I'm getting at is not a true
exponential growth because there is both a floor and ceiling, even if
they are unimaginably high. But eventually, even if only in theory and
completely implausible in real life, there's a limit to the amount of
accuracy you can achieve. At least, being reasonable there is. But ...
the Wikipedia article works well.
Thanks for the insight, I'm quite rusty at geometry / trig, as you can see. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 08, 2007 6:26 am Post subject: |
|
byuu wrote: |
Is it cool that I leave the menu separator, then? |
In other sections, the divider is used to separate things which don't
belong to the same option/checkmark, yet it's used here to imply
something (which doesn't really need to be). That makes it seem both
inconsistent and unnecessary to me. I'd say remove it and use an
undivided number scale.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Aug 08, 2007 10:37 pm Post subject: |
|
By
the way byuu, kudos on the new colour scheme for your website: it looks
much better this way. Actually, would you mind if I borrowed from your
design for a website of my own I have to set up as a university
assignment? (ugh.. graphic design was never my strong point and browser
incompatibility grounded my last attempt) Don't worry, I know the
basics of making websites (which is what the assignment is about, after
all) and I won't just do a copy/paste or anything. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 08, 2007 10:56 pm Post subject: |
|
Wait
until tonight, please. I've been busy reinventing CSS2 for IE6. I had
to skimp on a lot of important features last night because it was
already far too late at night to be working on that.
To give you a hint of what it will look like:
http://i73.photobucket.com/albums/i221/byuusan/website.png
Note that text-shadow is only supported in Safari and Konqueror.
Firefox has a bug report to add this feature, but it was only filed in
July of 1999
... so needless to say, they haven't gotten around to adding it yet. I
don't think you need to ask if IE7 supports it or not. Opera 10 will
supposedly have it, and there's a godawful slow Firefox extension to
fake it with opacity ... but unless you like pain, I wouldn't recommend
that.
For everyone else, the site will look the same, sans the text shadow, of course. |
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 09, 2007 9:44 am Post subject: |
|
Verdauga Greeneyes, I finished updating my page. If you want to reference it, feel free. Damn shame about text-shadow.
Quote: |
A) Your Software is licensed under one of the following licenses: |
Does me no good. "Hey, you can be exempt from the GPL if you give up
even more control of your work (so we can relicense it ourselves to GPL
anyway)!"
It's okay, it isn't my loss that I'm not helping their GUI toolkit to
be more popular, and instead helping their competition, Microsoft and
GTK+.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Aug 09, 2007 10:26 am Post subject: |
|
The red links are a bit hard to read over the much brighter text and the dark background.
Of course that might look better with text shadows...
Trivia: Some recommend a line length of "10-15 words per line". (link)
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Aug 09, 2007 11:08 am Post subject: |
|
byuu wrote: |
Note
that text-shadow is only supported in Safari and Konqueror. Firefox has
a bug report to add this feature, but it was only filed in July of 1999 ... so needless to say, they haven't gotten around to adding it yet. |
To be fair, Safari only got text-shadow support when OS X's built-in
text-rendering engine got text-shadow support. Trying to roll your own
arbitrary alpha-compositing solution when the underlying OS only just
supports text anti-aliasing (Hello, Win98!) is a world of pain that I
can't blame the Firefox devs for avoiding.
Now that Gecko 1.9 is using somebody else's alpha-compositing solution
(libcairo from GNOME), and now that it supports all those general
graphics filters required by the SVG spec, you've got a better chance
that Firefox 3 will support text-shadow when it comes out.
Also, I have to protest your assertion that text-shadow makes things
more readable. It's a special effect, and like all special effects it's
supposed to be used sparingly. Compare your page in Safari and Camino
(Safari's on the left, with text-shadow, and Camino's on the right,
without it - Camino uses the same rendering engine as Firefox). I find
the Camino screenshot far, far easier to read - partially because the
text is bolder, but also because the text-shadow makes the background
in Safari look weird and blotchy, and makes me want to rub my eyes.
(I was going to claim that white-on-blue is more readable for long
periods than any other color scheme, but I couldn't find any facts to
back me up. I will note that to this day, Microsoft Word has a special 'white-text-on-blue-background-mode' for people who find that the most comfortable colour scheme, and I've found some evidence that it's particularly good in low-light, or on very old equipment)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Aug 09, 2007 11:58 am Post subject: |
|
byuu wrote: |
Verdauga Greeneyes, I finished updating my page. If you want to reference it, feel free. |
Thanks ^_^
Thristian wrote: |
Also,
I have to protest your assertion that text-shadow makes things more
readable. It's a special effect, and like all special effects it's
supposed to be used sparingly. Compare your page in Safari and Camino
(Safari's on the left, with text-shadow, and Camino's on the right,
without it - Camino uses the same rendering engine as Firefox). I find
the Camino screenshot far, far easier to read - partially because the
text is bolder, but also because the text-shadow makes the background
in Safari look weird and blotchy, and makes me want to rub my eyes. |
I see what you mean with the background thing, though it doesn't bother
me, but I disagree with you about the boldface being easier to read; I
prefer a bit of seperation between the letters, I suppose. I do agree
that there's not much point in using text shadow for -everything-
though; it looks best on the red buttons anyway (well, I think it looks
awesome there).
By the way, about the white on blue thing, I've heard that before. I
wouldn't want to see every bit of text that way (though it may just be
a matter of getting used to it), however I often find myself selecting
text in long posts because it's easier to read it that way (also I can
deselect text after I've read it so I don't lose track of where I am).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 09, 2007 3:21 pm Post subject: |
|
Quote: |
Also,
I have to protest your assertion that text-shadow makes things more
readable. It's a special effect, and like all special effects it's
supposed to be used sparingly. |
It's a special effect that video game designers have realized is useful since at least 1992.
I'm honestly very surprised you prefer the Camino version to the Safari
version. But then, you can't please everyone, right? :/
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Aug 11, 2007 11:31 am Post subject: |
|
byuu wrote: |
Quote: |
Also,
I have to protest your assertion that text-shadow makes things more
readable. It's a special effect, and like all special effects it's
supposed to be used sparingly. |
It's a special effect that video game designers have realized is useful since at least 1992.
|
Yeah, I suppose - although they tend to only use a single-pixel,
hard-edged drop-shadow, and they can tune the font and shadow-shape for
optimum legibility. With CSS, all you can do is sort of wave your hands
at the browser and say 'here, try and figure something out for
yourself'.
byuu wrote: |
I'm honestly very surprised you prefer the Camino version to the Safari version. But then, you can't please everyone, right? :/ |
I have to admit that Arial renders pretty horribly in that screenshot;
I got sick of ugly fonts and told Camino to render everything in Lucida
Grande regardless of what font individual web pages tried to set, and
now everything looks gorgeous. :)
|
|
whicker Veteran
Joined: 27 Nov 2004
Posts: 621
|
Posted: Sat Aug 11, 2007 8:51 pm Post subject: |
|
On
a television, one absolutely had to use the 1-pixel shadow, due to the
horizontal color signal having about only the equivalent of 80 pixels
worth of information. The luma signal is what has the fine resolution.
Light text on black or with a black border just plain shows up better.
It's not that they were smart, they had to do this so that Mario's hat doesn't bleed into the smiling bush and such.
If you notice, the eye already does contrast enhancement on edges. Or
at least mine do. Black text on pure white kind of overloads the
system, however, with today's monitors.
For about the past 3 months, Scientific American has had articles about
the visual system, even if it is really light reading. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Aug 12, 2007 8:37 pm Post subject: |
|
Byuu,
I really, really enjoy the fact that you explain just about everything
that goes into your thought process. It's insightful and interesting,
even though I don't always understand what you're talking about...
Also, I like the website colors very much! It's a shame he text shadows
won't work under Firefox, but it's not a huge deal. It's readable and
simple. Nice job. |
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Tue Aug 14, 2007 4:47 pm Post subject: |
|
whicker wrote: |
If you notice, the eye already does contrast enhancement on edges. Or at least mine do. |
[Not the eyes, the brain. But yes, we have auto baseline correct,
contrast enhance, shape inter/extrapolation, and s'more algos builtin
(as long as brain works fine).
Eyes only send (comparatively rough) chroma signals and a luma signal,
both of which are finer-grained in the line of sight due to higher
cones/rods concentration]
You can resume normal thread activity now.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Aug 14, 2007 10:19 pm Post subject: |
|
I wonder what the next special chip will be. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 14, 2007 11:47 pm Post subject: |
|
Quote: |
Also,
I like the website colors very much! It's a shame he text shadows won't
work under Firefox, but it's not a huge deal. It's readable and simple.
Nice job. |
Thanks. Looking forward to Opera 9.5 / 10 to see how it looks there.
Might try moving the px sizes to em sizes to help out with really large
fonts when I have more than one browser to try it out on.
Quote: |
I wonder what the next special chip will be. |
I can tell you which two it won't be ...
If someone will set me up a test rig, it'll be the SPC7110. Otherwise,
probably the DSP-3 or DSP-4 if and when someone helps port the code in
ZSNES.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Thu Aug 16, 2007 6:14 pm Post subject: |
|
Quote: |
Also,
I like the website colors very much! It's a shame he text shadows won't
work under Firefox, but it's not a huge deal. It's readable and simple.
Nice job. |
Found this link on the page byuu linked to. No need to do a CSS hack to get shadows on a Mozilla-based or KHTML-based browser.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 17, 2007 5:46 am Post subject: |
|
Added a new programming page entry, but I haven't written up the tech info on it yet.
http://byuu.cinnamonpirate.com/?page=programming/libfunctor
This is basically my functor implementation with some new tricks since the old one in bsnes v0.022 and below.
At this point, I believe it to be perfect. I'm sure it's a long shot
here (not being an advanced C++ programmers forum and all), but what
the hell? I'll challenge anyone
to come up with a better functor method than this. It excels even
against boost::function in terms of simplicity and ease of use (see
what happens when you try and bind an overloaded member function to
boost::function). Hopefully an example of me exceeding the best of the
best major implementations in every respect will go a ways toward
stopping people from complaining that I have 'NIH syndrome'.
As I'm now completely satisfied with the library, barring anyone
pointing out any serious issues, I'm going to start incorporating this
into my applications. xkas will be the first to use it to implement
completely generic two-way class communication. After that, I'd like to
use it in bsnes to eliminate the need for the abstract template classes
to cross the core<>UI code separation barrier.
Quote: |
Found this link on the page byuu linked to. No need to do a CSS hack to get shadows on a Mozilla-based or KHTML-based browser. |
The shadow tricks don't work well, they all have various issues. The
best one I've seen was using a nested span and storing the text string
twice. But even that is just ... not cool. And it fails miserably on
IE6 -- I'll hold while you all get over your disbelief that IE6 could
fail to render CSS properly.
I appreciate the research though, but I'm happy with text-shadow for
now. Perhaps even Opera being more standards compliant than Firefox
will spur some more development. And if not, perhaps a Windows native
port of Konqueror would provide some much needed competition for
Firefox to stop resting on its' laurels.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Aug 17, 2007 5:52 am Post subject: |
|
byuu wrote: |
I
appreciate the research though, but I'm happy with text-shadow for now.
Perhaps even Opera being more standards compliant than Firefox will
spur some more development. And if not, perhaps a Windows native port
of Konqueror would provide some much needed competition for Firefox to
stop resting on its' laurels. |
I use Opera. What Firefox really needs is this thing called "fixing memory leaks" and at least a competent built in download manager.
_________________
FF4 research never ends for me.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Aug 17, 2007 9:08 am Post subject: |
|
Firefox does not have any big memory leaks, it just uses some ram for caching. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Aug 17, 2007 12:21 pm Post subject: |
|
henke37 wrote: |
Firefox does not have any big memory leaks, it just uses some ram for caching. |
Agreed. This was explained in a few documents from the Mozilla Team. I
don't have the source on hand aside from this one.
http://weblogs.mozillazine.org/ben/archives/009749.html
Also, since I was a skeptical disbeliever, I ran my own tests. There
are no major memory leaks that I have found in the last several
versions of Firefox 2. I DID see one in 1.5 though.
That's a thing of the past now. No joke. If I have any memory leaks
now, it's because I have opened a .pdf inline or run a java application
or some third party BS.
As for Firefox and it's CSS support. They're doing well, but yes, they room for improvement, that's for sure.
However.... Firefox 3 will be using Gecko v1.9 (completely overhauled)
for the layout engine. It will also PASS THE ACID2 TEST at long last
because of it. Standards compliance will go way up.
The Firefox team is certainly not 'resting on its' laurels'. They've
been hard at work making things better, but things don't happen
overnight. You should know that byuu.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 17, 2007 2:30 pm Post subject: |
|
Quote: |
However....
Firefox 3 will be using Gecko v1.9 (completely overhauled) for the
layout engine. It will also PASS THE ACID2 TEST at long last because of
it. Standards compliance will go way up.
The
Firefox team is certainly not 'resting on its' laurels'. They've been
hard at work making things better, but things don't happen overnight.
You should know that byuu. |
Seriously, have you tried Firefox 3 alpha 7? It's far worse than
Firefox 2 in every respect. It was completely unusable due to all the
bugs. Yes, yes, alpha. Yeah. I got that part, thanks. Anyway, Gecko 1.9
still
does not add text-shadow. So much for Cairo. I saw no improvements
anywhere with CSS support. Not saying there aren't improvements, just
that I didn't see any. The few CSS bugs I was aware Firefox had were
still there.
And yes, I consider having an open
bug report for eight years to be resting on your laurels. You claim to
be leading the front on standards compliance ... there's no excuse to
have a bug report open that long. That's the reason I left IE6 ...
having to wait eight years for transparent PNG support. Now Firefox is
selectively choosing what it wants to implement, and using the fact
that IE lacks the support as one of the reasons it's low priority.
But yes, I'm just looking at one specific feature that I want, I know.
I think it's a major feature, but I'm sure the devs don't give a fuck
about it -- that much is obvious. Whatever, it isn't that big of a
deal. I'll just be recommending Opera 9.5 when it comes out over
Firefox 3. Adblock be damned.
We're really beating this issue into the ground now, though. Can we
just agree to disagree and move on? The CSS attribute is in my
stylesheet, so whatever. If Firefox ever adds the tag, it'll work. And
if not, it never will. And that'll be that.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Aug 17, 2007 4:03 pm Post subject: |
|
Nightcrawler wrote: |
henke37 wrote: |
Firefox does not have any big memory leaks, it just uses some ram for caching. |
Agreed. This was explained in a few documents from the Mozilla Team. I
don't have the source on hand aside from this one.
http://weblogs.mozillazine.org/ben/archives/009749.html
Also, since I was a skeptical disbeliever, I ran my own tests. There
are no major memory leaks that I have found in the last several
versions of Firefox 2. I DID see one in 1.5 though.
That's a thing of the past now. No joke. If I have any memory leaks
now, it's because I have opened a .pdf inline or run a java application
or some third party BS.
|
It crashes way too much for my liking. I would put some blame on the
plugins (Flash is always a culprit).. but there seems no end to why it
implodes on simple stuff.
Quote: |
However....
Firefox 3 will be using Gecko v1.9 (completely overhauled) for the
layout engine. It will also PASS THE ACID2 TEST at long last because of
it. Standards compliance will go way up.
The
Firefox team is certainly not 'resting on its' laurels'. They've been
hard at work making things better, but things don't happen overnight.
You should know that byuu. |
It makes you wonder why browser standards can't be followed, yet
documented protocols are usually followed to the letter. Go figure.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 17, 2007 4:31 pm Post subject: |
|
Allow me to pre-empt the inevitable discussion with a hint of sarcasm for entertainment ...
<Deathlike2> It crashes way too much for my liking. I would put
some blame on the plugins (Flash is always a culprit).. but there seems
no end to why it implodes on simple stuff.
<Nightcrawler> Really? Because it's never once crashed for me,
and I've been using it since Phoenix 0.4. Don't blame your computer
problems on Firefox.
<Deathlik2> Well, I've had three separate computer systems, and Firefox has crashed on all of them.
<Nightcrawler> Yeah? Well I have four computers, and Firefox works great on all of them! Which version were you using?
<Deathlike2> Firefox 1.5
<Nightcrawler> Oh, well there's your problem! You should be using 2.0!
<Deathlike2> Ok, I tried 2.0 and it still crashes.
<Nightcrawler> Well then you must be doing something wrong because it doesn't crash here.
<Deathlike2> That's great. I'll stick with Opera because it doesn't crash for me.
<Nightcrawler> ... and I'll stick with Firefox, thanks.
<Deathlike2> Hey, why is this byuu guy putting words in my mouth? I'd never say any of the above!
<Nightcrawler> Yeah, me too! He's totally exaggerating! He needs to stop putting words in my mouth, too!
<byuu> x.x
:D
Anyway, I did want to comment on one other thing.
Quote: |
It will also PASS THE ACID2 TEST at long last because of it. |
Wow, passing the most popular test known. Aiming to implement the bare
minimum to pass a popular test is a publicity stunt. It's the same
thing as trying to pass the SNES electronics test. It's a small subset
of the available functionality, and it's targeted as one of the first
tests to pass simply because it's so infamous. But passing the test
means nothing, really. No test can get anywhere near testing all
features of something as complex as an SNES or CSS.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Aug 17, 2007 8:13 pm Post subject: |
|
Pfft.
Firefox this, Opera that.
REAL men use Seamonkey.
It's like Firefox*, but it doesn't suck!
http://www.mozilla.org/projects/seamonkey/
*In that Firefox is a hacked-down, crippled version of it that insults the user's intelligence.
Anyways.... looking forward to the next major BSNES update. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Aug 17, 2007 10:34 pm Post subject: |
|
Ok,
I've timed libfunctor against boost::function. Not only is it simpler,
more flexible and easier to use ... it's also faster. Four times over
on member function pointers when not using maximum compiler optimizations.
Code: |
/*****
* timing results in ms of 100,000,000 function calls
*****
* g++
* 115 - (*func)(int)
* 130 - (m_func->*func)(int)
* 280 - byuu::functor<int ()>(int)
* 300 - byuu::functor<int (C::*)()>(int)
* 360 - boost::function<int ()>(int)
* 965 - boost::function<int (C::*)()>(int)
* g++ -O3
* 20 - (*func)(int)
* 95 - (m_func->*func)(int)
* 150 - byuu::functor<int ()>(int)
* 185 - byuu::functor<int (C::*)()>(int)
* 400 - boost::function<int ()>(int)
* 295 - boost::function<int (C::*)()>(int)
* cl
* 1109 - (*func)(int)
* 1250 - (m_func->*func)(int)
* 3250 - byuu::functor<int ()>(int)
* 3328 - byuu::functor<int (C::*)()>(int)
* 4031 - boost::function<int ()>(int)
* 11844 - boost::function<int (C::*)()>(int)
* cl /O2
* 640 - (*func)(int)
* 750 - (m_func->*func)(int)
* 1985 - byuu::functor<int ()>(int)
* 1453 - byuu::functor<int (C::*)()>(int)
* 1844 - boost::function<int ()>(int)
* 1843 - boost::function<int (C::*)()>(int)
*****/ |
The large disparity between g++ and cl is because g++ does not honor the volatile keyword to the extent cl does.
And the test itself:
Code: |
int (*fp)(int) = &func;
Func *mf = &m_func;
int (Func::*mp)(int) = &Func::func;
functor<int (int)> f1(&func);
functor<int (int)> f2(&m_func, &Func::func);
boost::function<int (int)> bf1(&func);
boost::function<int (int)> bf2 = boost::bind(&Func::func, &m_func, _1);
time_t start, end;
volatile int x;
/* direct function pointers */
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += fp(5);
}
end = clock();
printf("%10d - (*func)(%d)\n", int(end - start), x);
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += (mf->*mp)(5);
}
end = clock();
printf("%10d - (m_func->*func)(%d)\n", int(end - start), x);
/* byuu::functor */
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += f1(5);
}
end = clock();
printf("%10d - byuu::functor<int ()>(%d)\n", int(end - start), x);
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += f2(5);
}
end = clock();
printf("%10d - byuu::functor<int (C::*)()>(%d)\n", int(end - start), x);
/* boost::function */
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += bf1(5);
}
end = clock();
printf("%10d - boost::function<int ()>(%d)\n", int(end - start), x);
start = clock();
x = 0;
for(volatile int i = 0; i < 100000000; i++) {
x += bf2(5);
}
end = clock();
printf("%10d - boost::function<int (C::*)()>(%d)\n", int(end - start), x); |
So much for all that talk about how a team of hundreds of developers
cannot be beaten by a single person and how I should just use the
standard libraries. Hopefully this will serve as encouragement to
others to challenge the standard libraries. You'll learn a lot of
really cool, advanced stuff in the process, and if you really try hard
enough ... there's a good chance you can outdo them in every respect.
Can't wait to start binding bsnes to this and get rid of those ugly
hacks like template<> class SNESInterface.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 18, 2007 12:03 am Post subject: |
|
Ah, good question :)
http://www.codeproject.com/cpp/FastDelegate.asp
is not compatible with the C++ standard. It uses hacks, so it's
worthless. I don't care how well it performs. It has awful syntax
anyway.
http://www.codeproject.com/cpp/ImpossiblyFastCppDelegate.asp may be conformant, but has severely bastardized syntax.
typedef delegate5<void, int, long, float, double, void*> D4;
D4::from_method<TestClass, &TestClass::f4>(&obj)(sum, 1, 2.0, 3.0, (void*)0);
versus:
functor<void (int, long, float, double, void*)> f(&obj, &TestClass::f4);
f(sum, 1, 2.0, 3.0, (void*)0);
Which is clearer to you?
Note that he uses separate 'delegate' templates (what the hell is up
with that name?) for every single parameter count. Many other libraries
even differentiate functors with and without return types. He also
completely ignores the power of partial template specialization and
insists on direct lists. It's hard to tell at first glance that the
first template argument is the return type in his library.
I'm not going to bother trying to set up his library to benchmark it.
If someone else wants to, be my guest. Frankly, I don't even care if
it's faster. The syntax alone makes it a nightmare. My first and
foremost priority is clean code. Speed comes last. And yet I still beat
boost.
Similarly, my syntax clearly beats out Loki and tr1, as well as every
hobbyist implementation you can find on Google in 10 minutes, such as
all the crap on codeproject.com. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Aug 18, 2007 12:49 am Post subject: |
|
byuu wrote: |
The large disparity between g++ and cl is because g++ does not honor the volatile keyword to the extent cl does. |
You might be interested in this recent Linux Kernel mailing list post.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Aug 18, 2007 5:30 am Post subject: |
|
I
can agree with not using volatile freely in code like that. The only
reason I use it is because there's no way to totally disable
optimizations.
Otherwise, the for loops will be
condensed down into x = 1000000000, and will totally bypass actually
calling the functions. Which is what I'm trying to measure. It was
either use volatile, or write code that is complex enough to fool the
optimizers into calling the functions. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 22, 2007 10:28 am Post subject: |
|
blargg
pointed out a rather serious flaw with the library ... parameters
passed by value end up being copied three times. Not a big deal for
integers, but the overhead can be substantial if you're passing around
large objects like strings or RAM buffers. It seems boost::function
suffers from the same shortcoming.
Unfortunately, this one's really tough to fix. The only way to avoid
the copies is to pass by reference until the final call where one would
then pass by value. Distinguishing between byval and byref is easy
enough with template traits, but this breaks down when you try passing
primitive types (integers and floating point values), as it's not
possible to reference those.
Since I can't create a partial specialized template to match only
structs and classes, my only option is to fully specialize every
primitive type.
Edit: came up with an acceptable workaround. In a scaled down example:
Code: |
template<bool C, typename T, typename F> struct ifelse {};
template<typename T, typename F> struct ifelse<false, T, F> { typedef F type; };
template<typename T, typename F> struct ifelse<true, T, F> { typedef T type; };
template<typename T> struct reference_cast {
typedef typename ifelse< boost::is_fundamental<T>::value, T, T& >::type type;
};
template<typename T> struct reference_cast<T&> { typedef T& type; };
template<typename P1>
struct functor {
void (*proc)(P1);
void operator()(typename reference_cast<P1>::type p1) { (*proc)(p1); }
functor(void (*p)(P1)) : proc(p) {}
}; |
The idea is to pass integers and floats by value, but when objects
(structs and classes) are passed, use references until the final call,
where the byval copy will occur.
I'll obviously be implementing is_fundamental myself rather than adding
a 17MB dependency, but there's only ~16 fundamental types, so it should
be fine.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 22, 2007 6:29 pm Post subject: |
|
byuu wrote: |
but
this breaks down when you try passing primitive types (integers and
floating point values), as it's not possible to reference those.
|
I didn't know this was supposed to be a Java library, in fact this doesn't compile in Java.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Aug 22, 2007 6:55 pm Post subject: |
|
Somebody got their sarcasm back.
c++ gets ugly at times, doesn't it?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Wed Aug 22, 2007 7:14 pm Post subject: |
|
Nach wrote: |
byuu wrote: |
but
this breaks down when you try passing primitive types (integers and
floating point values), as it's not possible to reference those.
|
I didn't know this was supposed to be a Java library, in fact this doesn't compile in Java.
|
Let's just hope he hasn't forgotten about destructors and the delete
operator too (or the const keyword even). Of course, passing by value
for built-in types are usually ever so slightly faster, but that
probably drowns in other overheads (not to mention the overhead of more
code to maintain). Oh, and remember to use const references (it may
just be me but it looks like you didn't), otherwise you'll be screwed
if temporaries are passed if I'm not mistaken.
I've hardly looked at your code at all, but I couldn't help noticing
your assignment operator doesn't seem to handle self-assignment. (And I
couldn't spot any good reason why f needs to be public.)
edit: it are? wtf?
Last edited by sinamas on Wed Aug 22, 2007 9:46 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 22, 2007 8:55 pm Post subject: |
|
Geez, everyone's extra friendly and helpful today, huh? :/
Sarcastic Stan wrote: |
I didn't know this was supposed to be a Java library, in fact this doesn't compile in Java. |
Code: |
#include <stdio.h>
void test(int x) { printf("test(%d)\n", x); }
void passthru(int &x) { test(x); }
int main() {
passthru(5);
return 0;
} |
Repeat your comment again when you make the above compile. And no,
assigning 5 to a variable before calling passthru is not an acceptable
solution. If you make passthru take (int x), then when you try the same
with objects, you'll end up calling the object's copy constructor twice.
Quote: |
Let's just hope he hasn't forgotten about destructors and the delete operator too (or the const keyword even). |
You should look over the code. Everything that needs to be is const
qualified, and the only thing I create with new has a matching delete.
Even in the destructor.
Quote: |
I've
hardly looked at your code at all, but I couldn't help noticing your
assignment operator doesn't seem to handle self-assignment. |
Assigning a functor directly to itself is retarded. If you really want
me to take a speed hit for the mentally handicapped, fine. I'll add
if(this == source) { if((rand() % 10) == 0)throw "Thou art a fool.";
return *this; }
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Aug 22, 2007 9:10 pm Post subject: |
|
byuu wrote: |
Geez, everyone's extra friendly and helpful today, huh? :/
Sarcastic Stan wrote: |
I didn't know this was supposed to be a Java library, in fact this doesn't compile in Java. |
Code: |
#include <stdio.h>
void test(int x) { printf("test(%d)\n", x); }
void passthru(int &x) { test(x); }
int main() {
passthru(5);
return 0;
} |
Repeat your comment again when you make the above compile. And no,
assigning 5 to a variable before calling passthru is not an acceptable
solution. If you make passthru take (int x), then when you try the same
with objects, you'll end up calling the object's copy constructor twice.
|
Uh huh, here's the code written right:
Code: |
#include <iostream>
using namespace std;
void test(int x) { cout << "test(" << x << ")\n"; }
void passthru(const int &x) { test(x); }
int main()
{
passthru(5);
return 0;
}
|
byuu wrote: |
Quote: |
Let's just hope he hasn't forgotten about destructors and the delete operator too (or the const keyword even). |
You should look over the code. Everything that needs to be is const
qualified, and the only thing I create with new has a matching delete.
Even in the destructor.
|
Yeah Right.
Please next time put a warning label on your posts if it's supposed to be Java.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Wed Aug 22, 2007 9:10 pm Post subject: |
|
byuu wrote: |
Geez, everyone's extra friendly and helpful today, huh? :/
Sarcastic Stan wrote: |
I didn't know this was supposed to be a Java library, in fact this doesn't compile in Java. |
Code: |
#include <stdio.h>
void test(int x) { printf("test(%d)\n", x); }
void passthru(int &x) { test(x); }
int main() {
passthru(5);
return 0;
} |
Repeat your comment again when you make the above compile. And no,
assigning 5 to a variable before calling passthru is not an acceptable
solution. If you make passthru take (int x), then when you try the same
with objects, you'll end up calling the object's copy constructor twice.
|
I already told you to use const references:
Code: |
#include <cstdio>
using namespace std;
void test(int x) { printf("test(%d)\n", x); }
void passthru(const int &x) { test(x); }
int main() {
passthru(5);
}
|
byuu wrote: |
Quote: |
Let's just hope he hasn't forgotten about destructors and the delete operator too (or the const keyword even). |
You should look over the code. Everything that needs to be is const
qualified, and the only thing I create with new has a matching delete.
Even in the destructor.
|
That was meant as a reference to Java's lack of those.
byuu wrote: |
Quote: |
I've
hardly looked at your code at all, but I couldn't help noticing your
assignment operator doesn't seem to handle self-assignment. |
Assigning a functor directly to itself is retarded. If you really want
me to take a speed hit for the mentally handicapped, fine. I'll add
if(this == source) { if((rand() % 10) == 0)throw "Thou art a fool.";
return *this; }
|
I'll just refer to Effective C++ Item 11 here I think, and leave it at that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 22, 2007 10:22 pm Post subject: |
|
Ah, I actually just figured that out, unfortunately you beat me to a reply :(
Well, now I feel stupid. Oh well, we can't all be Bjorne Stroustrups.
Code: |
template<typename T> struct reference_to { typedef const T& type; };
template<typename T> struct reference_to<T&> { typedef T& type; };
template<typename R, typename P1>
struct functor<R (P1)> {
typedef typename reference_to<P1>::type RP1;
...
}; |
Much better.
|
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Aug 23, 2007 5:32 am Post subject: |
|
I'll
summarize the problem that self-assignment reveals: what happens to
your functor in operator = if the call to copy() throws an exception
due to lack of memory? Bingo, dangling pointer. If you solve this
problem, you solve self-assignment as well. Exception safety is the name of the game. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 23, 2007 6:27 am Post subject: |
|
Rewrote the library, thanks to help solely provided by blargg.
He advised me of the byval object copy problem, and also showed me a
neat trick to eliminate the virtual function call and replace it with a
standard pointer to function call instead.
I took things a bit further and combined blargg's new trick with all of
my own tricks and created the library below. Along with heavy use of
the C preprocessor, the result is a ~4kb (4x smaller than the last
version) functor library that requires absolutely no dynamic memory
allocation via new/delete. It's fully compatible with the old one, but
even more flexible now. I also swapped the member function and object
pointer order to match everyone else's libraries for consistency's sake.
Code: |
http://byuu.cinnamonpirate.com/files/libfunctor_v04.zip |
For sinimas, this also now works as expected:
Code: |
functor<void ()> fself(&func);
fself(); //calls func();
fself = fself;
fself(); //calls func(); |
I'd be really impressed if anyone could come up with any significant
enhancements over this library at this point. I think I'll send it over
to the boost team, at least to point out to them the issue with byval
copying in their library before it makes it into C++0x.
Even though I'm sure I won't end up using this much, I do appreciate
your help on this blargg. It was a great learning experience for the
more advanced C++ template topics that you don't come across very often
in day-to-day programming.
Oh, and this is officially the coolest C++ function call in the entire world:
Code: |
return (((C*)d.object)->*((R (C::*&)(PL))d.fn_member))(CL); |
... and if you complain about not using static_cast and reinterpret_cast, I will murder you.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Aug 23, 2007 3:13 pm Post subject: |
|
Will this new library make bsnes quicker? or is this just groundwork for the new ppu? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Aug 23, 2007 4:49 pm Post subject: |
|
Quote: |
Will this new library make bsnes quicker? or is this just groundwork for the new ppu? |
I'll probably use it to eliminate the template class interface between
the core and UI, but it won't really speed things up any.
The PPU will only be using the cothreads.
Anyway, below are some benchmarks. Calling and copying functors hundreds of millions of times.
Code: |
/*****
* g++
* 3.131868 byuu::functor
* 4.120879 boost::function
* 3.571429 byuu::member_functor
* 11.373626 boost::member_function
* 2.527473 byuu::functor_copy
* 130.604396 boost::function_copy
* g++ -O3
* 1.648352 byuu::functor
* 2.802198 boost::function
* 2.087912 byuu::member_functor
* 3.296703 boost::member_function
* 0.494505 byuu::functor_copy
* 27.527473 boost::function_copy
* cl
* 2.984000 byuu::functor
* 4.203000 boost::function
* 2.797000 byuu::member_functor
* 13.953000 boost::member_function
* 5.751000 byuu::functor_copy
* 142.721000 boost::function_copy
* cl /O2
* 1.968000 byuu::functor
* 1.875000 boost::function
* 1.984000 byuu::member_functor
* 1.844000 boost::member_function
* 0.188000 byuu::functor_copy
* 64.767000 boost::function_copy
*****/ |
Note the unbelievable overhead with copying boost::function objects,
due to dynamic memory allocation. The actual function calls were only
tested by directly invoking the objects themselves. I didn't even
exploit the triple copy problem with objects for this timing test, or
the odds would have been even more in my favor.
And should you actually try passing a boost::function object by-value
to a callback dispatcher, the boost::function_copy overhead will be
added to the boost::function call. So, if you're going to use boost
just because boost is so cool and all, I must strongly recommend that instead of writing functions like:
Code: |
void call(boost::function<void ()> f); |
You instead write them like this:
Code: |
void call(boost::function<void ()> const& f); |
Though it should be obvious and good programming practice to use the
latter, I doubt any programmer would expect the omission of const&
to cause, quite literally, a ~400x speed drop.
---
EDIT: apparently, the byval copy problem exists with return types, as well. Example:
Code: |
struct Foo {
Foo() {}
Foo(const Foo&) { printf("copy\n"); }
} myfoo;
Foo direct() { return myfoo; }
Foo (*indirect)() = &direct;
void test() { Foo /*& here won't help*/ foo = indirect(); } |
GCC is smart enough to only make a copy of Foo one time, but Visual C++ makes a copy twice.
The functor library would of course end up calling the copy constructor
three times, as there's two indirect function calls needed for that.
Unfortunately, my reference trick doesn't work here.
|
|
Zakule New Member
Joined: 13 Dec 2005
Posts: 4
|
Posted: Mon Aug 27, 2007 3:50 pm Post subject: very impress with bsnes |
|
I
recently tested out this emulator and was very impressed with it on its
trial run! It can emulate some games very well that other emulators
take issue with (such as Actraiser 2).
There are a couple of features I'd love to see added, though:
Fullscreen mode, with the option to set separate resolutions for both windowed and fullscreen mode.
An in-game option to enable/disable vsync.
Save state support.
Even without those features, you've created a great emulator, byuu. I look forward to future installments!  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Aug 27, 2007 7:30 pm Post subject: Re: very impress with bsnes |
|
Zakule wrote: |
Save state support. |
Already discussed, not that easy.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Aug 27, 2007 9:25 pm Post subject: |
|
Quote: |
Fullscreen mode, with the option to set separate resolutions for both windowed and fullscreen mode. |
I had to remove the resolution settings because I do not have the
ability to change resolutions on Linux. I'm trying to come up with a
way to re-add that when available, though.
In the mean time, you can get fullscreen by using the F11 key. It
simply uses your existing resolution and video size settings. It won't
fill 100% of your screen, but on the bright side the distortion is
minimized, especially on widescreen monitors.
Quote: |
An in-game option to enable/disable vsync. |
I'm sorry, but I've tried for the last 2+ years to get vsync and sound
working together. I simply can't do it alone, and nobody seems apt to
help out with more than a quick Google search for solutions. Sure,
other people can do it in their emulators ... but I'm not other people,
and I can't figure it out. If vsync is enabled, the sound skips and
pops every 200ms. If you're interested in the technical details, I've
posted about it many times on previous pages in this thread.
Quote: |
Save state support. |
Even more complicated. Again, reasons are listed on the previous pages.
In short, due to my programming design, this is likely something I'll
never be able to add.
Sorry for the inconveniences these issues cause. I'd love to have those
features too and would add them if I could.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Mon Aug 27, 2007 11:59 pm Post subject: |
|
byuu: regarding the debugger, there's two ways I can think of to have a text console portably.
In MAME, debugger windows are treated as low-feature tilemaps (no
scrolling, a simple per-cell color selector). The core code gives you
the tilemap memory and it's up to the platform code how to draw it
(Windows uses DrawText() with a fixed-width font, Linux uses GTK+ with
a fixed-width font, and OS X uses Carbon APIs with a fixed-width font).
Visual Boy Advance does it another way: it requires that you start it
from a terminal window (Linux)/command prompt (Win32) in order to use
the debugger and just uses that window/prompt. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Aug 28, 2007 4:01 am Post subject: |
|
byuu,
what do you think about showing the NTSC and PAL aspect ratios in
"advanced" to let users define their own if they want? I'm somewhat
interested in setting NTSC to 4:3 (1.33) or possibly stretching it to
16:9 (1.78) widescreen if I ever get such a display.
Also, is it still impossible to get that icon displaying properly in
Windows? It would be cool to get that back someday. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 28, 2007 7:36 am Post subject: |
|
Quote: |
byuu: regarding the debugger, there's two ways I can think of to have a text console portably.
In MAME, debugger windows are treated as low-feature tilemaps (no
scrolling, a simple per-cell color selector). The core code gives you
the tilemap memory and it's up to the platform code how to draw it
(Windows uses DrawText() with a fixed-width font, Linux uses GTK+ with
a fixed-width font, and OS X uses Carbon APIs with a fixed-width font). |
Ah, thanks for the suggestion. I have to say I like the MAME approach
more. I can abstract the debugger and console text buffer itself into
the core of the emulator, and then simply draw the result to the
screen, exactly as I want. This way, I can also combine the debugger
with a more suitable GUI to control it with, and have more control over
the width X height of the terminal. Ultimately, to get the exact level
of control I want, it'll probably be best to write a pixel buffer
renderer. I'll have to settle for a button to copy the contents of the
custom-drawn terminal to the clipboard, however (native
textboxes/terminals are nicer for letting users highlight and copy.)
That, or go with fonts guaranteed to be able to show all width X height
cells, and err on extra spacing at the right and bottom.
I'm going to attempt the new S-PPU before I restart on the debugger (to
avoid having to redo things with the new cores), but I suppose I can
start working on the console widget sooner.
By the way, good timing in stopping by. I sent you a PM here in case
you don't usually check that, as I lost your e-mail.
Quote: |
byuu,
what do you think about showing the NTSC and PAL aspect ratios in
"advanced" to let users define their own if they want? I'm somewhat
interested in setting NTSC to 4:3 (1.33) or possibly stretching it to
16:9 (1.78) widescreen if I ever get such a display.
Also, is it still impossible to get that icon displaying properly in
Windows? It would be cool to get that back someday. |
Sure thing, I'll work on both of these. I'll have to #ifdef the icon
support for Windows for the time being ... no idea how to load a .ico
from inside an executable file for GTK+. It's a shame not having your
awesome icon there for so long :)
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue Aug 28, 2007 9:20 am Post subject: |
|
byuu wrote: |
Sure
thing, I'll work on both of these. I'll have to #ifdef the icon support
for Windows for the time being ... no idea how to load a .ico from
inside an executable file for GTK+. It's a shame not having your
awesome icon there for so long :) |
The underlying GTK API you want is probably gtk_window_set_icon_list(),
which takes a list of GdkPixbuf objects in much the same way that a
.ico file contains multiple resolutions and bit-depths of the same
image.
I would be surprised if you could open a
.ico file and retrieve all its contents as a suitable list; I believe
most Unix software packages a bunch of png files to load as its icon.
If you really don't want to rely on external files, or you want a
fallback mechanism, you can compile XPM images into your code (the XPM
file format was designed to be legal C code) and load it with gdk_pixbuf_new_from_xpm().
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Aug 28, 2007 1:04 pm Post subject: |
|
I
still don't think that save state support is that far fetched. I mean,
what is needed? you need to save the registers in the chips(subclass
them and add a common virtual method), the ram(easy) and the timing
info(you wrote libco) and then reload the data. Nothing hard at all.
Especially since byuu have a very oo architecture. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Aug 28, 2007 3:14 pm Post subject: |
|
henke37 wrote: |
I
still don't think that save state support is that far fetched. I mean,
what is needed? you need to save the registers in the chips(subclass
them and add a common virtual method), the ram(easy) and the timing
info(you wrote libco) and then reload the data. Nothing hard at all.
Especially since byuu have a very oo architecture. |
You really aren't understanding what's required, as been discussed in
this thread and why this method won't work the way BSNES is currently
written.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Aug 28, 2007 5:16 pm Post subject: |
|
Thristian, thanks for the link. I'll have to do something like that when I have time.
henke37, Deathlike2 is exactly right. Saving the context of a
software-based state machine is a far more trivial task in comparison
to saving the context of multiple hardware-based threads -- especially
doing so in a portable manner.
This board-in-a-thread approach really isn't working, is it? All of
this has been discussed literally dozens of times already, but due to
the sheer size of the thread, it's almost unreasonable to ask people to
search for the information before posting anymore, hmm. I don't like
the idea of someone else hosting a board for me, and I really don't
like the idea of having to write my own board software (because I lack
SQL access.)
Given the recent Wikipedia crap, maybe I should start on my own
wiki-style self-documentation of the program itself and reasons for the
shortcomings. |
|
Zakule New Member
Joined: 13 Dec 2005
Posts: 4
|
Posted: Tue Aug 28, 2007 6:27 pm Post subject: |
|
byuu, thanks for the tip on fullscreen - I probably should have read the docs first before posting, huh?!!!
I'll try out F11 tonight. As long as the correct aspect ratio is
maintained, then it works for me (I never opt to stretch to fill the
screen if it distorts the image).
I'm not a programmer myself and therefore am unable to offer any assistance towards adding vsync or or savestates.
I'm afraid that savestate support in the other emulators I use (Kega
Fusion, Nestopia, ZSNES) has spoiled me! It's hard to imagine playing a
platform game and knowing that if I slip up and die I'll have to do the
whole level over again! That's one of the main reasons I moved away
from console games and into PC games. For me, savestates in old school
console emulators are a godsend. I get to enjoy the nostalgia of
playing my old favorites without any of the frustration of having to
replay segments of the game after repeated failed attempts to surmount
a difficult obstacle.
Anyway, I'm rambling. Thanks again for all your efforts in creating an
excellent SNES emulator, byuu. It will come in handy for those games
where savestates aren't as much of an issue, like in RPGs or Adventure
games where you can save to SRAM at certain intervals. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Aug 28, 2007 6:40 pm Post subject: |
|
byuu wrote: |
All
of this has been discussed literally dozens of times already, but due
to the sheer size of the thread, it's almost unreasonable to ask people
to search for the information before posting anymore, hmm. |
People can search for individual posts though.
Zakule wrote: |
As
long as the correct aspect ratio is maintained, then it works for me (I
never opt to stretch to fill the screen if it distorts the image). |
4:3 is the correct aspect ratio. Anything else is distorted.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Aug 29, 2007 9:01 am Post subject: |
|
Saving a state machine is not hard. Just freeze it between two ticks.
For example: Chip 1 is running at clock speed X and is due in XX
milliseconds and Chip 2 is running at clock speed Y and is due in YY
milliseconds.
That is all that needs to be saved from the threading system as far as
I can tell. And the clock speeds isn't needed to be saved since they
are the same every time anyway.
Edit: misunderstood and though that libco was a state machine.
But you can still just save the timing info(whatever it is) in a platform independent way.
I am in no way expecting you to save asm in the save state. I think
that saving state that resulted in asm the approach to use.
Define that save states can only be taken when the thread library
(possibly) switches threads. This will require some addons to libco,
but checking a global variable is not going to be that much of an issue
for the speed. Only if the flag to do something special instead of only
the regular thread switching is set, will you need to start the whole
each-chip-dumps-registers business.
In the same way, add a way to pre-set the due counters (or whatever
sync info libco uses) when setting up the threads.
If I made any wrong, then please tell me why it is wrong. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Aug 29, 2007 7:02 pm Post subject: |
|
Heya byuu,
Is there any chance you'll add back in adjustable scanlines? I really dig those 
BTW I'm still using version 19 because for whatever reason the sound
doesn't skip or pop in my custom fullscreen I use with it. Maybe I
somehow got incredibly lucky in that the timing of the refresh I set
happened to be perfectly in sync with the sound timing. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Aug 29, 2007 8:36 pm Post subject: |
|
Quote: |
Edit: misunderstood and though that libco was a state machine.
But you can still just save the timing info(whatever it is) in a platform independent way. |
You almost understand, but not quite. Alright, a small example:
Code: |
void run_cpu_opcode() {
while(true) {
int opcode = read();
if(opcode == 0xa9) { return opcode_lda_const(); }
}
}
void opcode_lda_const() {
regs.a = read();
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
}
uint8_t read() {
wait(4); //sleep for four clock cycles (bus hold delay)
sync(); // ***
return memory_subsystem->read(regs.pc++);
} |
See the *** part? When sync() is called, execution either jumps
immediately to another SNES processor, or to the user interface. When
you call the CPU thread again, it resumes immediately after the sync()
call. Now, let's say the sync() call goes to the UI, and the UI notices
the user asked for a savestate.
Tell me, without using a state machine, how am I supposed to save
information that can get my CPU thread to start back up right after the
call to sync() ? It will start at the top of run_cpu(), and none of the
local variables that are on the stack will be there anymore. Sure, I
can dump all the cothread stack information, but it won't do me any
good. Local addresses and such can change every time you run the
program. The only way I can tell it to jump back to read() is with a
state machine. Meaning my code would end up looking like this:
Code: |
void run_cpu_opcode() {
static int opcode; //ugh, we can't use local variables with a state machine
switch(state.run_cpu_opcode) {
case 0:
read_hold();
state.run_cpu_opcode++;
break;
case 1:
opcode = read();
state.run_cpu_opcode++;
break;
case 2:
if(opcode == 0xa9) {
opcode_lda_const(); //this will reset state.run_cpu_opcode when finished
}
break;
}
}
void opcode_lda_const() {
switch(state.opcode_lda_const) {
case 0:
read_hold();
state.opcode_lda_const++;
break;
case 1:
regs.a = read();
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
state.opcode_lda_const = 0;
state.run_cpu_opcode = 0;
break;
}
}
//useless bloat function needed for state machine design
void read_hold() {
wait(4); //sleep for four clock cycles (bus hold delay)
//run_cpu_opcode() will return here, allowing the subsystem to sync() components
}
uint8_t read() {
return memory_subsystem->read(regs.pc++);
}
void capture_savestate() {
state.write(state.run_cpu_opcode);
state.write(state.opcode_lda_const);
} |
And indeed, that's exactly what my code looked like in the last version
of bCPU (minus the fact that I unrolled a lot of loops like
read_hold(), which made the code that much harder to read.)
This is the big thing bsnes does that no other emulator does. And it's
why my code is actually readable, and why I can easily fix bugs in a
mere two hours most of the time. Personally, I think it's worth the
tradeoff. It's faster, it's smaller, it's cleaner, and it's more
accurate. But I can't save the state.
Quote: |
Is there any chance you'll add back in adjustable scanlines? I really dig those |
I hope to re-add that with the new renderer. It will require a lot of
rewriting due to the new platform-independence v0.020 and above have.
However, the new renderer won't be fast enough to be playable on any
PCs, so yeah, you'll probably want to stick with v0.019 if it works
best for you. I've only fixed ~5 or so bugs since then, anyway. Unless
the bugs affect games you play, you should be alright.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Aug 30, 2007 7:09 am Post subject: |
|
Yeah, I see the issue now.
It is very difficult to freeze this properly.
You'd need to manually scrape the stack/heap for each "thread" for the
values to save and record what line of c++ code to resume to.
Then when restoring, you would need to carefully rebuild the stack, but
with addresses that's valid for this execution and then carefully jump
in the asm to exactly the right point in the function/method that
called sync().
To fixup pointers and other runtime "random" values that's not going to
be the same, just save each thing that will be pointed to an non random
ID that will be valid every time the save is loaded. Then it is a
simple matter of making a cleanup pass on all variables that held
pointers and swap in the new addresses.
It is still doable, but much much more messy. And it would likely
require some sort of c++ to asm lookup table to know where all stuff
you'd need to save is.
I am going to rank this as about as crazily difficult as attempting to make an emulator in c++ only. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Aug 30, 2007 4:57 pm Post subject: |
|
AHHH! Freakin awesome. I'm pumped for that translation.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 01, 2007 9:16 am Post subject: |
|
Quote: |
byuu,
I didn't know you were working on the Mother 3 translation. Your
contributions will really give that nice byuu-sheen to the final
product. |
Yeah, Tomato asked for some help on the game. It's a fun challenge, and
he's an awesome guy, so I'm honored to be helping.
Just don't expect much from me. The hackers already working on the game
are more skilled than I am with GBA assembly. I've zero experience with
the ARM7. I'm mainly just lending a hand as a backup.
Right now, I'm completely stuck on some really tough problems due to
allowing more than 21 characters per line. Looks like we're going to
need yet another GBA hacker that's better than me to help out. Heh, a
long shot, but anyone here more experienced than I interested? :)
I wrote: |
2007-09-01 - libco v0.10 beta3
I've finally decided against accepting a void* parameter argument to
entry points for new cothreads. It's simply far less portable, due to
all of the variant ABIs out there; and it can be simulated (and a lot
more flexibly) by using global variables. I've included a new test_args
file to demonstrate this.
If anyone cares at all about libco, now is the time to check it out.
This is the final beta, and I will be freezing the API permanently for
v0.10 official. My e-mail is in the doc/libco.html file if you have any
comments or suggestions.
You can download the beta here.
Note that it won't work with bsnes v0.022 due to API changes, so you'll
have to test with the sources in test/, or write your own. Also, I
would appreciate if someone using a 64-bit version of Windows could let
me know if libco_win works there or not. You'll need a C++ compiler to
test, as no binaries are included. |
I lack a 64-bit OS at the moment. If anyone with a compiler and a
64-bit OS -- Windows or Linux -- can test this beta to make sure
test_timing still works, I'd appreciate it. Only need one verification
per OS.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Sep 01, 2007 11:48 am Post subject: |
|
byuu wrote: |
I
was completely and utterly underqualified to attempt to comment on such
a massively important topic as Wikipedia, which delves right down into
human nature. In comparison, my article was an outright joke. So
apparent after listening to Jason's speech, I have removed mine to
avoid further embarassment. |
Interesting. I read your article before you removed it; I'll listed to
Jason's speech, if only to see how your opinions differed (not to point
out how supposedly bad your article was).
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Sep 04, 2007 12:06 am Post subject: |
|
Jipcy wrote: |
byuu wrote: |
I
was completely and utterly underqualified to attempt to comment on such
a massively important topic as Wikipedia, which delves right down into
human nature. In comparison, my article was an outright joke. So
apparent after listening to Jason's speech, I have removed mine to
avoid further embarassment. |
Interesting. I read your article before you removed it; I'll listed to
Jason's speech, if only to see how your opinions differed (not to point
out how supposedly bad your article was).
|
I would have been curious to see what byuu wrote.
Like many people I guess, when I first became aware of Wikipedia, my
first reaction was: "Whow, so much potential!" But quickly realised
that while it's a nice project it's very much
imperfect...Pseudo"NPOV"...Systemic bias... Those things unfortunately
are pretty much unavoidable, or so it would seem.
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Sep 04, 2007 7:08 pm Post subject: |
|
yes,
I use it for random pieces of information, like what cola flavor
consists of etc. but I get rather annoyed when they start ripping down
information as if they are some sort of credible source that should be
taken as an encyclopedia, I don't use them that way.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 07, 2007 4:10 pm Post subject: |
|
I finally got around to adding Nach's MinGW patches.
MinGW (w/GCC3, in my case) isn't very fast, though. With -O3 and lots
of -fopts, I get about a ~20% speed loss over Visual C++ with /O2 by
itself. My experience shows PGO with GCC adds only a ~10% speedup, so
I'll be sticking with Visual C++ for official releases for now.
There seems to be a bug somewhere that's only triggered by MinGW where
vsnprintf(0, 0, s, temp) is returning -1, so I'm kind of stuck. Visual
C++ / Linux GCC never do this. Reading this page
shows that apparently vsnsprintf isn't implemented the same way
everywhere. I'm not going to use the referenced workaround function.
Instead, I'm slowly converting my string library to support streaming.
I'll just remove vsnsprintf all together when that is finished.
Anyway, next release should have a new target, win-mingw-lui. Thanks,
Nach. Sorry for the delay in adding these patches. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Sep 08, 2007 12:06 am Post subject: |
|
byuu wrote: |
Instead, I'm slowly converting my string library to support streaming. |
If you don't mind my asking, what's this mean exactly? (if you do mind, how should I google it?)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 08, 2007 2:57 am Post subject: |
|
Quote: |
If you don't mind my asking, what's this mean exactly? |
It's like std::ostringstream or whatever. Works a lot like cout, but
directly on strings. So you can have something like:
string t = "My name is: " << bob << ", and I am " << age << " years old.\n";
Doesn't work too well when you try and stream multiple string objects
this way though, as the operator<< returns references. Meaning
with:
string x = "x", y = "y";
x << y << "z";
x = "xyz" and y = "yz". But, what can you do, right?
It's also nice because it gives intrinsic sprintf-style argument
support to any function that takes a const char* as an argument. So you
can do things like:
FILE *fp = fopen(string() << basename << ".txt", "rb");
I'm still trying to think up a better system than std::ios_base or sprintf for formatting integral values, though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 08, 2007 12:58 pm Post subject: |
|
Double post!
I've uploaded a new WIP, which I'll make public (only to this forum,
please don't post about it anywhere else unless you mirror the file):
Code: |
http://byuu.org/files/bsnes_v022_wip03.zip |
This version adds all of Nach's MinGW fixes, updated libco, libui and
libfunctor, cleans up the code that detects if the main window has
focus or not (if not, ignore keyboard input), adds the new makefile
target win-mingw-lui, finally fixes all of the char* conversion
warnings with GCC 4.2.x (thanks [vEX]), and I'm sure there's more, but
I don't remember.
The ZIP includes a Visual C++ generated binary, but it also works with
MinGW GCC4. It won't work with MinGW GCC3 because that one lacks a
C99-compliant vsnprintf function. You can hack your way around that by
editing src/lib/libstring_sprintf.cpp if you really want to use MinGW
GCC3.
You may also need to change the CC / CPP variable names. I went with
the generic names mingw32-gcc and mingw32-g++, but the GCC4 binaries
have -sjlj or -dw2 appended to them. You'll also need to set
-I/path/to/directxheaders, or copy them all into
/path/to/mingw/include, since MinGW seems to ignore the include
environment variable.
And finally, a bit of good news. It appears that MinGW GCC4 builds
binaries that are ~6% faster than Visual C++. That means with PGO
enabled, they should be at least ~16% faster than v0.022 official. If I
can figure out how to hide the ugly terminal window in the background,
I'll start making official releases with MinGW GCC4 from now on.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Sep 08, 2007 2:48 pm Post subject: |
|
byuu wrote: |
It's like std::ostringstream...integral values, though. |
Thank you for explaining
As for the new beta of bsnes, sounds like a lot of improvements behind
the scenes (so to speak); good stuff. What're you planning to work on
next?
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Sat Sep 08, 2007 5:01 pm Post subject: |
|
byuu wrote: |
If
I can figure out how to hide the ugly terminal window in the
background, I'll start making official releases with MinGW GCC4 from
now on. |
You need to use "-mwindows" when linking (the opposite is "-mconsole").
Using this setting will also automatically include "-lgdi32 -lcomdlg32"
in addition to "-luser32 -lkernel32 -ladvapi32 -lshell32".
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 11, 2007 3:09 pm Post subject: |
|
Thank
you, DMV27. -mwindows works great. Although it doesn't appear -prof_gen
and -prof_use work with MinGW, it's still faster overall, so it'll
probably be used for future releases.
And for some
bad news, looks like the first bug-free run lasted for 32 days. That's
okay, I never expected it to hold forever anyway.
Nightcrawler spotted a bug in Emerald Dragon's sound support on the
5th. Took a few days to test on hardware and verify it wasn't related
to blargg's S-DSP core. Try starting a new game, and after talking to
the three dragons and the child, the sound channels cut out, then go
really fast, then start working normally. There's a few other songs
affected, but this is the easiest to reach. I suspect it's a timer
problem, but I've triple verified 100% of the behavior in anomie's
S-SMP document, so I don't know what's going on just yet. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Sep 11, 2007 4:08 pm Post subject: |
|
From the gcc documentation:
`-fprofile-generate'
Enable options usually used for instrumenting application to
produce profile useful for later recompilation with profile
feedback based optimization. You must use `-fprofile-generate'
both when compiling and when linking your program.
The following options are enabled: `-fprofile-arcs',
`-fprofile-values', `-fvpt'.
`-fprofile-use'
Enable profile feedback directed optimizations, and optimizations
generally profitable only with profile feedback available.
The following options are enabled: `-fbranch-probabilities',
`-fvpt', `-funroll-loops', `-fpeel-loops', `-ftracer'
Last edited by Verdauga Greeneyes on Tue Sep 11, 2007 4:21 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 11, 2007 4:12 pm Post subject: |
|
The
ED bug is not in bsnes v0.019. I don't have v0.020, but that doesn't
really matter. I performed some code surgery to create a hybrid v0.022
with v0.019 opcode core (but the newer timer code and such), and it
works again.
The only change I've made to the
opcode core was the changes to pass blargg's S-SMP cycle timing tests.
I'll have to go through each opcode, one by one, until I find the
culprit. Note that this is almost guaranteed to be a bug in my code,
and not in blargg's timing test.
EDIT: hah, my first guess was that I messed up incw/decw. Sure enough, that was it.
v0.019:
Code: |
incw_dp(0x3a, incw),
decw_dp(0x1a, decw) {
1:dp = op_readpc();
2:rd = op_readdp(dp);
3:rd |= op_readdp(dp + 1) << 8;
4:rd = op_$1(rd);
op_writedp(dp + 1, rd >> 8);
5:op_writedp(dp, rd);
}
uint16 sSMP::op_incw(uint16 x) {
x++;
regs.p.n = !!(x & 0x8000);
regs.p.z = (x == 0);
return x;
}
uint16 sSMP::op_decw(uint16 x) {
x--;
regs.p.n = !!(x & 0x8000);
regs.p.z = (x == 0);
return x;
} |
v0.022:
Code: |
incw_dp(0x3a, rd++),
decw_dp(0x1a, rd--) {
1:dp = op_readpc();
2:rd = op_readdp(dp);
$1;
3:op_writedp(dp++, rd);
4:rd += op_readdp(dp) << 8;
5:op_write(dp, rd >> 8);
regs.p.n = !!(rd & 0x8000);
regs.p.z = (rd == 0);
} |
Now I just need to figure out what's different between these two by
making some test cases and this bug will be fixed.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Sep 11, 2007 4:22 pm Post subject: |
|
Heh,
nice work on finding the bug so quickly. Just posting to let you know I
edited my previous post. These should be the MinGW equivalents for the
switches you mentioned. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 11, 2007 6:02 pm Post subject: |
|
I fixed it. Silly bug.
Code: |
incw_dp(0x3a, rd++),
decw_dp(0x1a, rd--) {
1:dp = op_readpc();
2:rd = op_readdp(dp); //note the read__dp__()
$1;
3:op_writedp(dp++, rd); //note the write__dp__()
4:rd += op_readdp(dp) << 8; //note the read__dp__()
5:op_write(dp, rd >> 8); //note the *lack of* dp in write()
regs.p.n = !!(rd & 0x8000);
regs.p.z = (rd == 0);
} |
The math was fine. I verified it with a separate test program. I knew
it relied on some tricky wrapping behavior, but the SNES writes the low
byte before reading the high byte, so I had no choice with that.
The problem was the low byte write wasn't using dp addressing. This
means that regs.p was ignored. regs.p, when set, means dp writes to
0x0100+dp. When clear, just dp. It was always writing to just dp
because of this.
This bug is now fixed. It should certainly fix the other two sound
glitches in the same game Nightcrawler noticed. It's pretty serious
even if only ED seems to have problems, so I'll get a new public
release out this weekend. It's a good chance to publically release the
GCC 4.2 warning fixes, MinGW support, MinGW speedups and PGO. The MinGW
PGO doesn't seem to do much though, so don't expect much of a speedup.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 11, 2007 6:45 pm Post subject: |
|
Great job! Regarding the next release, do you think either Pause Emulation or aspect ratio definition will make it in?
Also, gambatte reminds me of something I should have noticed already.
If you prefer, "..." is typically put after things in the menu that
open new windows. So right now, "Configuration" and "Load" could use
it. This is just more immediately telling of what clicking on that item
will do, as opposed to looking just like a checkable. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 11, 2007 7:40 pm Post subject: |
|
Ok, I'll add the ...
As for the aspect ratio, I have one small issue. I can't just give it
an arbitrary number, unless it's an X:Y ratio. But the numbers can't be
floating point, because my math parser works in integers only. I don't
feel like writing a floating-point enabled one right now.
The two options are:
1) make it a math string using only integral math. Give it an automatic
two floating points. So, eg you could write: "4500 / 3300" and get 136,
which becomes 1.36:1.
2) make two parameters for both NTSC and PAL that form a divisor. eg:
video.aspect_ntsc_x = 45
video.aspect_ntsc_y = 33
result = 45 / 33 = 1.36.
I think I can do pause emulation, but it's not a priority so no promises. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 11, 2007 7:58 pm Post subject: |
|
Sounds good, thanks much. As for the AR advanced option, I think option 2 looks perfect. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Sep 12, 2007 7:59 am Post subject: |
|
byuu,
you may know this, but on the front page of your web site, the link to
your Philosophical Ramblings page is
"http://localhost/index.php?page=articles/philosophy".
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 12, 2007 10:08 am Post subject: |
|
Ok,
I've posted a new WIP with the Emerald Dragon bug fix. This time, I'm
not posting the WIP publically. My last request not to link directly to
the file elsewhere was ignored, and ended up on at least two emulation
news sites (I won't mention names.) I'm not trying to be a jerk about
it, I really can't spare that kind of bandwidth.
If anyone has contributed any code or bug fixes, reported any confirmed
bugs, or is an emulator author I've spoken to in the past, feel free to
request a link to the WIP page from me in PM if desired.
Sorry to everyone else. I'll have the new version out as soon as possible.
Quote: |
As for the AR advanced option, I think option 2 looks perfect. |
Done. I didn't add any sanity checks, so that people can have a little
fun with it. It's not going to be a GUI option, so only advanced users
can play with it anyway. Try setting a crazy aspect like 3:1 and play a
platform game. It's guaranteed to mess with your mind.
I also added the ... stuff, but I did not add the pause support back in
yet. Not sure if that'll make the next release, because it requires
some changes to the main loop functions that have been missing for a
while now. I usually like to leave more of a beta testing window before
messing with that stuff.
Quote: |
byuu,
you may know this, but on the front page of your web site, the link to
your Philosophical Ramblings page is
"http://localhost/index.php?page=articles/philosophy". |
Hahah, oops. No, I didn't notice that. I must have copied the link from my browser instead of typing it manually.
It's a stupid article, anyway. Didn't come out like I planned. I was
also reading some comments by Miguel de Icaza (supporting patent pacts)
and Linus Torvalds (bashing the hell out of C++ programmers), and came
across an interesting comment that got me thinking. Basically that
people who have any kind of notability really shouldn't go around
talking about things outside their specific expertise, because it makes
them look foolish when people take them too seriously (and people do)
as those two comments by de Icaza and Torvalds did. Lucky for me I
really don't
have any kind of notability, but it's a good principle to adhere to
anyway. Stick to talking about what I know best. That goes against my
whole personality though, so I probably won't change at all anyway.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Sep 12, 2007 5:47 pm Post subject: |
|
Is there a way to disable the FPS, if not could it be added? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 13, 2007 5:09 am Post subject: |
|
AR
definition is working well. I'm using 583 / 500 (1.166) to achieve a
4:3 ntsc ratio, which is negligibly wider than the 1.148 default. Was
there ever any discussion about what the game makers were actually
designing for? Could it actually be closer to a 4:3 value?
bobthebuilder wrote: |
Is there a way to disable the FPS, if not could it be added? |
It's there, at the very bottom of advanced.
byuu wrote: |
I'll
have to #ifdef the icon support for Windows for the time being ... no
idea how to load a .ico from inside an executable file for GTK+. It's a
shame not having your awesome icon there for so long  |
Still the ugly window icon thing for xp in this build. Just thought I'd
mention it in case you added it and expected it to be working.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Sep 13, 2007 2:40 pm Post subject: |
|
FitzRoy wrote: |
If
you prefer, "..." is typically put after things in the menu that open
new windows. So right now, "Configuration" and "Load" could use it. |
Close; "..." means that the command requires more information from the
user before it can be carried out. So "Load" gets it while "Show
configuration" doesn't, since the latter completes immediately: it
shows the configuration window. See Apple's Human Interface Guidelines section about the ellipsis.
byuu wrote: |
Try setting a crazy aspect like 3:1 and play a platform game. It's guaranteed to mess with your mind. |
Hey, can you set a negative ratio, like -1:1? That'd be useful for
flipping horizontally, which helps a ton on a few Donkey Kong Country 3
levels near the end.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 13, 2007 3:20 pm Post subject: |
|
Well, I'm not actually maintaining a Mac port myself. I suppose it's possible to compile it there if someone wanted to, though.
I say that because it doesn't seem many Windows or Linux apps conform
to that ellipses rule. Both Firefox and Outlook have ... on "options".
I don't care either way. Whatever makes most people happy.
Quote: |
Hey, can you set a negative ratio, like -1:1? |
o.O
That's ... a novel way to add the feature, but no. Definitely not. I
could easily do that if I were only aiming for Windows, but doing it
everywhere would require a software renderer fallback to flip the image
before drawing it.
Easy to do, but too much trouble. It's a nice feature, but I'm much too
busy on the core stuff still to go back to adding more features.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Thu Sep 13, 2007 3:30 pm Post subject: |
|
FitzRoy wrote: |
It's there, at the very bottom of advanced.
|
Thanks. 
Adding ellipsis is a good idea.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Sep 13, 2007 11:44 pm Post subject: |
|
byuu wrote: |
Quote: |
Hey, can you set a negative ratio, like -1:1? |
o.O
That's ... a novel way to add the feature, but no. Definitely not. I
could easily do that if I were only aiming for Windows, but doing it
everywhere would require a software renderer fallback to flip the image
before drawing it.
Easy to do, but too much trouble. It's a nice feature, but I'm much too
busy on the core stuff still to go back to adding more features.
|
perhaps something to remember for the future.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 14, 2007 5:37 am Post subject: |
|
blargg wrote: |
Close;
"..." means that the command requires more information from the user
before it can be carried out. So "Load" gets it while "Show
configuration" doesn't, since the latter completes immediately: it
shows the configuration window. See Apple's Human Interface Guidelines
section about the ellipsis. |
Interesting. I run Windows and most programs I use do it for anything
that will pop up a new window and take input. Something like "About",
though, seems 50/50. I personally think it makes sense to have the rule
be more general. I also think you could argue that the purpose of
"configuration" is to configure something via user input, not merely
show the configuration window.
byuu wrote: |
Well, I'm not actually maintaining a Mac port myself. I suppose it's possible to compile it there if someone wanted to, though. |
Wasn't Richard Bannister doing this for a while? What happened?
PS... I take back the idea of putting a new checkable for Pause
Emulation that under settings. As long as emulation stops when
minimized or when the main bsnes window is not the active window, you'd
be fine. Although, I would like to know why "0" doesn't work as a speed
regulation value (it crashes bsnes).
Last edited by FitzRoy on Fri Sep 14, 2007 6:44 am; edited 3 times in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Sep 14, 2007 6:32 am Post subject: |
|
FitzRoy wrote: |
Something
like "About", though, seems 50/50. I personally think it makes sense to
have the rule be more general. I also think you could argue that the
purpose of "configuration" is to configure something via user input,
not merely show the configuration window. |
Yes, that's why I changed the wording to "Show configuration", so I
didn't have to deal with this more tricky case heh. The value of having
"..." mean that the command doesn't execute immediately (rather than
simply opens a window) becomes apparent when you consider someone
experimenting with a program and wanting to know which commands might
immediately change things (possibly irreversably), and which commands
will still offer a chance to back out by simply clicking cancel when
asked for further information. A while back Apple got more consistent
and changed the About menu items to not have a "..." since they tell
you about the program/computer without further user input. Now back to
your regularly scheduled program.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 14, 2007 6:45 am Post subject: |
|
Heh,
I edited when you quoted me. Anyway, I think I do realize the
technicality. If it were a verb like "Configure" then it would fit the
rule, right? Because that implies further user input whereas
"Configuration" the noun is equivalent to "Show Configuration." |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 14, 2007 7:24 am Post subject: |
|
You can technically back out of "Load Cartridge", too. So either both load and config should get ..., or both shouldn't.
Whenever I get around to localization, I'll just let you guys edit the menus to whatever you want.
And yes, Bannister is still working on the OS X port. My point was that
it's not me doing it, and it's a different UI anyway. I think libco is
why the releases are no longer synced. That lib is terribly platform
dependent, and nobody has ported it to anything yet. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 17, 2007 12:39 am Post subject: |
|
byuu didn't post here, but it appears that .023 was released today. Thread updated. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Sep 17, 2007 12:48 am Post subject: |
|
edit:
I am no longer sure this is accurate. I fear that maybe one of my rom
folders has been corrupted and it is very likely that this was the
cause of the crash. The original post is as follows.
Panzer88 wrote: |
just something to be aware of for bsnes users. (or at least this is what I have experienced).
when using bsnes I had it in one directory, and then deleted it, and
when I got a newer version I put it in a different directory. Well the
problem is that it remembers the old directory and looks for things like
path.rom
path.save
path.bios
path.save_ext
system.video
systems.audio
systems.input
systems.video_flags
systems.audio_flags
systems.input_flags
in the old directory that it saved. Well if that old directory doesn't
exist, or the bsnes files are no longer there then it will crash when
you try to load roms so just keep in mind to update your directories if
you move it or get a new version of bsnes etc.
Just thought I would bring it to people's attention. |
EDIT 2: oh bother, now it's crashing again, I know it isn't bsnes's
fault but I thought I had it fixed, how irksome. I know this isn't
exactly a troublshooting topic but could someone give my some pointers
on why bsnes crashes when I try to load roms? I am running windows xp
SP2 on a dusty old computer. I know it certainly won't run full speed,
more like 20 FPS, but for awhile bsnes has refused to open a rom
without crashing, then today I just changed some options and it worked,
and then a few minutes later it is back to not working.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Mon Sep 17, 2007 2:10 am; edited 1 time in total
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Sep 17, 2007 2:03 am Post subject: |
|
hey, byuu megaman x doesnt run smooth as butter >.< on my core2 duo e6750. FIX IT PLEASE.
xD no, no, im just curious why no version so far (well maybe 0.18 )
dont run perfectly smoothly... the CPU usage for both cores is
erratically above 50%
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 17, 2007 2:42 am Post subject: |
|
franpa wrote: |
hey, byuu megaman x doesnt run smooth as butter >.< on my core2 duo e6750. FIX IT PLEASE.
xD no, no, im just curious why no version so far (well maybe 0.18 )
dont run perfectly smoothly... the CPU usage for both cores is
erratically above 50% |
Runs fine for me on an e6300. CPU usage is ~30%. You using XP @ SP2?
Only disappointment so far for me is not getting that 16% speedup because of *cough* JMA.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 17, 2007 2:55 am Post subject: |
|
Quote: |
I
know it certainly won't run full speed, more like 20 FPS, but for
awhile bsnes has refused to open a rom without crashing, then today I
just changed some options and it worked, and then a few minutes later
it is back to not working. |
Try deleting the c:\documents and settings\<your
username>\application data\.bsnes folder. That really shouldn't be
an issue, but it's worth a try.
Quote: |
hey, byuu megaman x doesnt run smooth as butter >.< on my core2 duo e6750. FIX IT PLEASE.
xD no, no, im just curious why no version so far (well maybe 0.18 )
dont run perfectly smoothly... the CPU usage for both cores is
erratically above 50% |
I get over 100fps with an E6600. bsnes is also single-threaded, if you
have over 50% on another core, it's because of something else on your
computer.
If you're asking why the video tears, I've been over that many times now. See previous posts.
Quote: |
Only disappointment so far for me is not getting that 16% speedup because of *cough* JMA. |
The compilation errors are almost certainly my fault. But I would've
just disabled it for the time being. The real problem was that bsnes
crashes every now and then with GCC PGO turned on. I can't release an
emulator that crashes every five minutes :(
I wish these compiler developers would fix PGO already ... even if it
ends up slower, at least make sure it generates valid code. The
features are absolutely useless the way they are.
That said, I'll post a private beta in a few hours of a MinGW PGO build for you to try out.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Sep 17, 2007 3:16 am Post subject: |
|
thanks
byuu, I can't believe I didn't think of that. sadly this has not fixed
the problem, which means there is a setting that when at standard,
makes bsnes not want to run on my system. Which means i simply need to
think carefully and find that setting.
thank you for your speedy troubleshooting though, much appreciated.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Sep 17, 2007 5:50 am Post subject: |
|
byuu wrote: |
Try deleting the c:\documents and settings\<your
username>\application data\.bsnes folder. That really shouldn't be
an issue, but it's worth a try. |
i did that first.
byuu wrote: |
I
get over 100fps with an E6600. bsnes is also single-threaded, if you
have over 50% on another core, it's because of something else on your
computer.
If you're asking why the video tears, I've been over that many times now. See previous posts. |
both cores jump to 50% or more while bsnes runs. nothing else runs
while they run. im fully aware of screen tearing and thats not what i
meant, it gets eliminated via setting the appropriate synchronize
option in bsnes.
i mean it slows down, IE: it jitters along with crackly audio every so often. (about every 20 seconds or so)
dont worry, im getting my pc looked at tomorrow, it might be a power
supply issue, a video card issue or even a hard disk issue lol.
_________________
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.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Sep 17, 2007 7:19 am Post subject: |
|
well
I adjusted the file paths again from the standard of "**" to "./save"
or "./rom" or "./bios" etc. and bsnes seems to be working consistantly
now. How odd, but I'm not going ot question it!
now all I need is a new computer!
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Sep 17, 2007 12:39 pm Post subject: |
|
franpa wrote: |
im
fully aware of screen tearing and thats not what i meant, it gets
eliminated via setting the appropriate synchronize option in bsnes.
i mean it slows down, IE: it jitters along with crackly audio every so often. (about every 20 seconds or so) |
NTSC uses a refresh rate of 29.97 frames per second, or 59.94 fields
(which is what emulators display). In the best case the monitor uses 60
(or 120) Hz, and vsync ties the emulator to the monitor refresh.
See the problem?
_________________
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: Mon Sep 17, 2007 12:50 pm Post subject: |
|
yes, but... how does (say) zsnes have smooth display all the time?
_________________
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. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Sep 17, 2007 1:02 pm Post subject: |
|
I
just noticed that when starting bsnes CPU usage sky rockets to 100%
even if nothing is running. However, if I open the 'Load Cartridge'
dialog it plunges down to 0% again. As soon as I close the dialog
(without loading any game) it climbs right back to 100%. It's as if
it's entering some infinite loop doing nothing. Tried both 0.021 and
0.022 as well as 0.023 and the behaviour is the same in all versions.
All tests made running under 64-bit Linux, computer specs as in my signature.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Sep 17, 2007 1:12 pm Post subject: |
|
doesnt happen here but im using 32bit windows.
_________________
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. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Sep 17, 2007 2:55 pm Post subject: |
|
creaothceann wrote: |
NTSC
uses a refresh rate of 29.97 frames per second, or 59.94 fields (which
is what emulators display). In the best case the monitor uses 60 (or
120) Hz, and vsync ties the emulator to the monitor refresh. |
The solution is for the emulator to emulate the system 1% faster than
it really runs so that it matches the PC's 60 Hz refresh. Beyond the
unnoticeably faster movement of things, sound will be a slightly higher
pitch.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 17, 2007 3:44 pm Post subject: |
|
Quote: |
well I adjusted the file paths again from the standard of "**" to "./save" or "./rom" or "./bios" etc. |
"**" is standard for a path? The default is "". I guess the Win32 API
is crashing when trying to parse that or something. "**" is definitely
an invalid folder path.
Quote: |
yes, but... how does (say) zsnes have smooth display all the time? |
The only two ways to do it are to: a) modify the CPU timing to align
60hz video and 32khz audio (less hardware accurate); or b) double/drop
video or audio samples to sync the video and sound cards. Usually audio
is resampled, as it's easier and less noticeable to most people.
I tried the latter, but couldn't pull it off. Even with high-end audio
resampling, there was noticeable pitch distortion between sample
blocks. I don't know why other people can do it and I can't, but that's
just the way it is, sorry.
Quote: |
I just noticed that when starting bsnes CPU usage sky rockets to 100% even if nothing is running. |
If you don't mind doing me a small favor ... look at
src/ui/lui/main.cpp:run(), I have added a call to Sleep(1) when
emulation is idle which is what gives most of the time back to the CPU
on Windows. I don't know the equivalent command on Linux (probably
usleep, but will that also work on FreeBSD, etc?), but if you add it
there, it should drop the CPU usage back down to 0%. If you know the
command name, and it works, I'll add it to my official port.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Sep 17, 2007 5:14 pm Post subject: |
|
byuu wrote: |
Quote: |
I just noticed that when starting bsnes CPU usage sky rockets to 100% even if nothing is running. |
If you don't mind doing me a small favor ... look at
src/ui/lui/main.cpp:run(), I have added a call to Sleep(1) when
emulation is idle which is what gives most of the time back to the CPU
on Windows. I don't know the equivalent command on Linux (probably
usleep, but will that also work on FreeBSD, etc?), but if you add it
there, it should drop the CPU usage back down to 0%. If you know the
command name, and it works, I'll add it to my official port.
|
I'm no big C or C++ coder and certainly don't know all the ins and outs
of Linux/BSD. However, both usleep(1000) and sleep(1) seems to work
fine for me. According to the man page for sleep()
it's supposed to be part of the Standard C Library and some ISO
standard also called 'POSIX.1'. I guess that means it should work on
most *nix systems.
usleep() is also mentioned to be part of the Standard C Library but not the ISO standard.
Using sleep(1) makes it idle, but also makes the menus sluggish if you
click them during the sleep period, using usleep(100) works better as I
don't perceive the menus to be sluggish then and it idles fine. The man
page mentions usleep() was introduced in 4.3BSD so I suppose it should
work fine on both Linux/BSD but as I said I'm no expert.
Code: |
#if defined(PLATFORM_WIN)
//prevent bsnes from consuming 100% CPU resources when idle
else { Sleep(1); }
#elif defined(PLATFORM_X)
else { usleep(100); }
#endif
} |
EDIT: There are links in the text, they just doesn't seem to be marked
so you notice them easily so I'll list them here too.
- sleep() BSD man page
- usleep() BSD man page
- sleep() Linux man page
- usleep() Linux man page
EDIT2: Just noticed that both man pages I looked up on the net were for
BSD, but both sleep() and usleep() works fine for me and the Linux man
page for usleep() mentions it conforms to BSD 4.3 so I guess usleep()
should be a safe bet.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Sep 17, 2007 5:33 pm Post subject: |
|
blargg wrote: |
creaothceann wrote: |
NTSC
uses a refresh rate of 29.97 frames per second, or 59.94 fields (which
is what emulators display). In the best case the monitor uses 60 (or
120) Hz, and vsync ties the emulator to the monitor refresh. |
The solution is for the emulator to emulate the system 1% faster than
it really runs so that it matches the PC's 60 Hz refresh. Beyond the
unnoticeably faster movement of things, sound will be a slightly higher
pitch.
|
I know you weren't advocating for this, but just to add: I personally
wouldn't want this solution. as it kinda compromise on the accuacy.
What about using a Tv-out display? Would that solve the issue?
Also, there's always PowerStrip for non-standard monitor refresh rates and resolutions.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 17, 2007 5:52 pm Post subject: |
|
Thanks [vEX], I'll add usleep to the codebase on my next update.
Snark, unfortunately accuracy with clock timings is tricky. Due to the
nature of such high precision oscillators, there is variance in every
single one. So really, the best we can do for accuracy is to either use
the stock reference speeds (that don't reflect reality), or use mean
averages of multiple systems. I went with the latter, myself, as I
agree with you. But one can definitely argue that a 0.03% offset of
clock speeds to get perfect 60fps won't hurt much. It's most likely
within their acceptable tolerance ranges, anyway.
As for PowerStrip, no amount of tweaking resolution timings will get
things perfect. You can get it 99.99% perfect with enough precision,
but there will always be rounding errors eventually, unless you
resample the audio or drop/duplicate video frames when necessary. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Sep 17, 2007 8:09 pm Post subject: |
|
byuu wrote: |
Thanks [vEX], I'll add usleep to the codebase on my next update. |
No problem, try and get some BSD people (and some more Linux people
wouldn't hurt, just to play it safe) to test it before release perhaps?
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Sep 17, 2007 8:32 pm Post subject: |
|
byuu wrote: |
Quote: |
well I adjusted the file paths again from the standard of "**" to "./save" or "./rom" or "./bios" etc. |
"**" is standard for a path? The default is "". I guess the Win32 API
is crashing when trying to parse that or something. "**" is definitely
an invalid folder path.
|
that would make sense but I went back and checked it and it was just my
bad eyes, I still can't figure out why it didn't want to work, but it
does now, so I'm not going to lose any sleep over it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 17, 2007 9:28 pm Post subject: |
|
Snark wrote: |
blargg wrote: |
creaothceann wrote: |
NTSC
uses a refresh rate of 29.97 frames per second, or 59.94 fields (which
is what emulators display). In the best case the monitor uses 60 (or
120) Hz, and vsync ties the emulator to the monitor refresh. |
The solution is for the emulator to emulate the system 1% faster than
it really runs so that it matches the PC's 60 Hz refresh. Beyond the
unnoticeably faster movement of things, sound will be a slightly higher
pitch.
|
I know you weren't advocating for this, but just to add: I personally
wouldn't want this solution. as it kinda compromise on the accuacy.
What about using a Tv-out display? Would that solve the issue?
Also, there's always PowerStrip for non-standard monitor refresh rates and resolutions.
|
If he was advocating it, then I'm going to side with blargg. The other
option already failed, and tearing is far, far more annoying and
noticeable than any 1% audio/video speed increase would likely be.
Perhaps this is a situation where exact system behavior should be
documented rather than implemented.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 17, 2007 10:18 pm Post subject: |
|
Quote: |
If he was advocating it, then I'm going to side with blargg. |
That's fine. Feel free to modify the CPU / SMP clock speed values in
the bsnes.cfg file yourself. I won't be doing this for any official
releases that claim to be accuracy oriented. And no, I don't know what
they should be changed to. Your soundcard is locked at 32khz which
multiplies to 24576000hz (I use 32.04khz now) where 21477272hz CPU is
equivalent to 60.09fps. Some division should get you a more suitable
CPU clock speed value. Match it to your monitor refresh rate, not to
60hz exact.
Maybe if I ever make a fast version without cothreads and such, I'll do something like that.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Sep 17, 2007 10:47 pm Post subject: |
|
blargg wrote: |
creaothceann wrote: |
NTSC
uses a refresh rate of 29.97 frames per second, or 59.94 fields (which
is what emulators display). In the best case the monitor uses 60 (or
120) Hz, and vsync ties the emulator to the monitor refresh. |
The solution is for the emulator to emulate the system 1% faster than
it really runs so that it matches the PC's 60 Hz refresh. Beyond the
unnoticeably faster movement of things, sound will be a slightly higher
pitch.
|
ah, cool then. im getting my computer checked today, theres like 9 big
issues with it and some of the issues had risen way back in February
this year ;\
_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 17, 2007 11:19 pm Post subject: |
|
byuu wrote: |
Quote: |
If he was advocating it, then I'm going to side with blargg. |
That's fine. Feel free to modify the CPU / SMP clock speed values in
the bsnes.cfg file yourself. I won't be doing this for any official
releases that claim to be accuracy oriented. And no, I don't know what
they should be changed to. Your soundcard is locked at 32khz which
multiplies to 24576000hz (I use 32.04khz now) where 21477272hz CPU is
equivalent to 60.09fps. Some division should get you a more suitable
CPU clock speed value. Match it to your monitor refresh rate, not to
60hz exact.
Maybe if I ever make a fast version without cothreads and such, I'll do something like that.
|
Is that even going to do anything for tearing without a true fullscreen or a vsync option in the program itself?
And maybe I'm missing something here, but I don't see what's more
inaccurate about 32000 over 320040. Has anyone even tested the newstyle
snes' to see what they output? What if it's at or under 32000? Could
the number derived from a mean average then actually become the
intended stock value? Lastly, how does choosing the ideal value
threaten the accuracy orientation of your current builds if a scanline
renderer doesn't already?
|
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Sep 18, 2007 7:32 am Post subject: |
|
it
appears as tho my power supply is on its last legs and my video card is
damaged but not as bad as the power supply. so this most likely
explains the performance issues.
_________________
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. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Sep 18, 2007 10:13 am Post subject: |
|
I
wasn't advocating changing anything inside the emulator, rather, doing
the equivalent of speeding up a movie. Not sure why you'd have trouble
resampling audio between buffers, unless you weren't storing the
previous left and right sample points for use by interpolation. Without
the previous samples you will obviously have a glitch since you're
missing essential data for interpolation. To understand it, just
simplify the situation down to mono sound with a sample buffer size of
1. If you're resampling that to double the rate, you need two output
samples for every sample buffer, and obviously you can't interpolate
with only one sample. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 18, 2007 12:23 pm Post subject: |
|
Quote: |
Is that even going to do anything for tearing without a true fullscreen or a vsync option in the program itself? |
Good point, probably not.
Quote: |
And
maybe I'm missing something here, but I don't see what's more
inaccurate about 32000 over 320040. Has anyone even tested the newstyle
snes' to see what they output? What if it's at or under 32000? Could
the number derived from a mean average then actually become the
intended stock value? Lastly, how does choosing the ideal value
threaten the accuracy orientation of your current builds if a scanline
renderer doesn't already? |
32000 breaks Earthworm Jim 2 (E), for one. No, I don't think anyone has
tested a new SNES. If they do, then we can make a mean average
including that. Until then, we should go with what we know to be true
... it's the best we can do.
And nice jab with the renderer. The only difference is that we know the
average APU clock rate and how it works per cycle, so we can emulate
it. We don't know how the PPU works per cycle, so we cannot. Truth is,
I still haven't started on that because I'm still struggling with how
to run two separate processors independently while keeping a single V/H
counter synchronized for both of them. The V/H values change based upon
PPU settings, which means I can't just keep two separate counters. At
the moment, I can't think of a way to emulate both without having to
single step both CPU and PPU.
Quote: |
Not
sure why you'd have trouble resampling audio between buffers, unless
you weren't storing the previous left and right sample points for use
by interpolation. |
No, the problem was the number of samples generated per frame were too
sporadic. I let my CPU and SMP run nonstop until either too much time
has passed, or they talk to each other. So they can desync a lot. As a
result, sometimes I'll get 7,600 samples in my buffer, and the very
next time I'll get 8,400 samples. I have to stretch both to the same
playback speed, which results in severe pitch distortions.
I've tried forcing the CPU and SMP to single step, and even added
primitive lowpass buffering, which just resulted in patterns like:
7,600 ; 7,600 ; 7,600 ; 7,600 ; 12,800 ; 7,600 ; 7,600
Which was really even worse. The rounding error just came back less frequently and more severe.
I honestly don't know why I can't get something like ~7,500 - ~7,700
samples per buffer length every time. I figure it must have something
to do with the DirectX APIs (like vsync polling or page flipping)
locking the emulator too long or something.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Sep 19, 2007 2:09 am Post subject: |
|
byuu wrote: |
Quote: |
And
maybe I'm missing something here, but I don't see what's more
inaccurate about 32000 over 320040. Has anyone even tested the newstyle
snes' to see what they output? What if it's at or under 32000? Could
the number derived from a mean average then actually become the
intended stock value? Lastly, how does choosing the ideal value
threaten the accuracy orientation of your current builds if a scanline
renderer doesn't already? |
32000 breaks Earthworm Jim 2 (E), for one. No, I don't think anyone has
tested a new SNES. If they do, then we can make a mean average
including that. Until then, we should go with what we know to be true
... it's the best we can do.
|
Yeah, I forgot about that. But couldn't that also throw into question
the cpu clock value for PAL, since 32000 works for NTSC's current rate
without breaking it? When I set the PAL cpu rate to a slightly lower
value, EWJ2 (E) acts fine again.
It might also be argued that the "reality" is that console makers could
use cheap, imperfect, and different brands of parts spanning revisions
or simply as supply and cost issues arise. If the parts vary, then the
only absolute throughout it all is that they all had to come within an
acceptable range of the reference
value. In that case, maybe the reference would be the ideal one to
choose, as it's even more accurate at doing the job than whatever
you've tested so far.
I wasn't trying to take a
jab at you, it was just a point through comparison. You've made a few
compromises here and there at no expense to compatibility to make the
emulator more enjoyable, so if it's possible again with no noticable
effects to end-users, then I think it's worth considering. Personally,
I want a return of the fullscreen/windowed profiles as defined through
configuration and not the menu. That was a great system. I didn't have
to change my multiplier each time I changed modes, and vsync/triple
buffering was actually possible. True, you can't use the menu in a true
fullscreen mode like you can in zsnes, but who cares? It's not a major
inconvenience to go into windowed to change roms, and your emulator
doesn't have savestates to save/load like zsnes does. Hell, maybe you
could even do both. F11 for the current "menu" fullscreen, and F12 for
the true one.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 19, 2007 8:28 am Post subject: |
|
If the reference value didn't ruin EWJ2, I'd definitely be using it.
And yeah, I did make compromises, the absolute biggest one to date has been that Uniracers "fix."
The big difference is simply what we've observed. And like the aspect
ratio correction, you can change the CPU / SMP values yourself if
you're not happy. If I ever write up real documentation on bsnes, I'll
include a section with the optimal values for 60hz video. Just do keep
in mind that it will only work for non-interlace mode. Any games that
enable interlace will then be even worse off than before.
(non-interlace = 60.09, interlace = 59.97; adjusted non-interlace =
60.00, adjust interlace = 59.88)
blargg has the right solution to this problem, but until I get some
help figuring out why I can't generate a consistent number of samples
per frame, I can't implement that.
And you know, you're right about the video mode thing. I hate having to
change multipliers when I switch screen modes, too. And you also have a
good point about adding both types of fullscreen, one with the menu and
one without. It's a good compromise and will allow the Linux port to
keep working with only one.
Ok, here's what I'm thinking:
- Change the video menu to give three mode options: Windowed, Hybrid (or Pseudo-Fullscreen), Fullscreen.
- Add back the video configuration panel, and allow configuration of
all three modes. Dynamically show and hide controls rather than just
disable them. If the current renderer lacks true fullscreen, then the
menu and the panel will not show an option for true fullscreen mode.
(sorry, Linux users)
- Keep the simplicity of the new systems. Only keep a scalar and an
aspect correction option, rather than allowing manual XxY resolutions
(or both and bloat the panel). Less powerful, yes, but easier for the
majority to use.
- Don't even try and show the menu in true fullscreen, pushing escape will exit back to windowed mode.
I wanted F12 to be pause, though, since some input systems can't map
pause/break. And I believe F10 acts like Alt in Windows. I'll just
leave F11 as mapping to the pseudo-fullscreen mode, and make the GUI
the only way to access true fullscreen mode.
It'll take me a long while to add this back, I completely scrapped all
of the fullscreen stuff in my video plugins a while back because it was
terrible. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Sep 19, 2007 11:06 am Post subject: |
|
I would really appreciate having a true fullscreen mode again, and I have absolutely no problems not having menu access.
One thought: I believe Kega uses a mouse-based menu instead of a
toolbar-like menu. You bring it up by right-clicking and it acts like a
context menu. This is all Windows-centric of course. Anyway, a thought.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 19, 2007 12:36 pm Post subject: |
|
Jipcy,
thanks for the suggestion, but I don't like the right click menus much,
myself. It also doesn't make it possible to have the menus in true
fullscreen mode when page flipping is enabled (all GDI functions are
disabled.)
---
Ok, here's my concept panel. Ignore the titlebar color, I have partial translucency enabled on it.

One major thing I did here was do away with separate text labels to the
left of the combo boxes. I realize that's very non-standard, but I
think it looks a bit better, myself. It means I don't have to worry
about the font sizes on different platforms, which would result in
overcompensation, or large gaps between the text and the combo boxes
themselves, eg:
Code: |
"Configure: [Combobox]"
"Region: [NTSC] Scale: [3x]" |
I'm also missing a separator control, which would really be appropriate
below the configure combobox, and maybe below the checkboxes.
Next, I'm not sure which options should be here and which should be in
the main menu. For instance, would it be better to have a global region
selection in the main menu (x224 or x239 height setting -- eventually
I'll have an auto mode that changes based on the game region), or make
it per video mode type? How about correct aspect ratio? I figure
per-mode is more flexible, and can clone the other functionality anyway
...
I should probably add (Width x Height) worst cases to the scale box, so
it's easy to tell when your scale is greater than the current screen
size. Whether to account for aspect correction would be tricky, I'd say
yes. So like, "Scale: 1x (320x240)", "Scale: 2x (640x480)" ...
I did away with the apply box. I want it to work like raster settings,
where changes are immediate. Since the only textboxes are for the true
fullscreen mode settings, where it's impossible to have the config
window open anyway, this should work out fine.
Note of course that none of these controls do anything at all yet. Just
getting feedback on it before I start changing the video parsing code
again.
If this is implemented, then the Settings menu will only have:
Video mode -> "Windowed, Pseudo-fullscreen, Fullscreen"
Video frameskip -> "0 - 9"
---
...
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Sep 19, 2007 2:04 pm Post subject: |
|
The board search only returns the topic it seems and not the specific posts.
So:
What is the problem with triple buffering again? Triple buffering by
definition should combat all the problems you've just described about
vsync and having to change clock speeds due to NTSC and PC monitor
differences.
_________________
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. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Sep 19, 2007 2:11 pm Post subject: |
|
byuu wrote: |
I'm
also missing a separator control, which would really be appropriate
below the configure combobox, and maybe below the checkboxes. |
You could use a panel with its height set to 2 or a similar low value.
Or put all the controls below the "configure:" button into a panel.
Nightcrawler wrote: |
The board search only returns the topic it seems and not the specific posts. |
Toggle the "display results as" option.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Sep 19, 2007 9:55 pm Post subject: |
|
I
think region control should be placed/kept in the menu bar, as setting
a different region for different display modes just seems confusing to
me. It'd only be two clicks away anyway. I like your concept though,
looks good. Definitely account for the aspect ratio for those worst
cases if it's not too much trouble; what you see is what you get, kinda
thing. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Sep 20, 2007 6:02 am Post subject: |
|
I
really like the new setup. Note that for the new style of box, you
might remember to change the ones in "Input Configuration" for
consistency. Here's my suggestions to video settings, as shown
(settings don't reflect my idea of what should be default, it's just
for show):

I added frameskip and aspect ratio (Corrected/Native?) to the boxes as
another row. I think that unifies things a bit more. So then the only
checkmark is the vsync option which is exclusive to the fullscreen
setting and would be absent or grayed out when not in that mode.
Frameskip settings are also with the video settings and would be saved
and configurable per mode. I don't see why they can't be removed from
the menu altogether and put with everything else. Now the only thing
you'd have to show in the menu is the mode select. I like that idea, by
the way, because you don't have to use a mystery hotkey. I'm sure
plenty of people have downloaded bsnes in the past and wondered how to
toggle fullscreen. The reason I don't think region changing needs to be
made more convenient is that I look at the time disparity between both
methods of changing it and it doesn't seem to be all that much longer
via configuration. Maybe a few extra clicks for something that can't be
getting switched back and forth any more than once per play session. I
like simplifying the menu better.
While the scale resolutions idea would be helpful, I also see it being
a source of misinformation. The most obvious implication of "Scale1x
(320x240)" is going to be "SNES resolution = 320x240", which isn't
true. It's really just the next highest standard resolution with which
to avoid overlap. Maybe in this case, trial and error is sufficient.
Lastly, triple buffering: if vsync requires users to make advanced
changes to the cpu clocks, it might be more trouble than its worth. I
remember everyone but yourself having some success with TB after
increasing default audio latency to 75. Which do you think is better or
more feasible now that fullscreen is coming back for windows users? |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 20, 2007 3:08 pm Post subject: |
|
Nightcrawler,
the issue with triple buffering was that it was still locking. Once I
drew two images ahead, the next flip request would lock the
application, rather than drop the request. Kind of defeats the whole
purpose of having page flipping, but alas.
Verdauga, the only nice thing about having a different region setting
for each mode is that fullscreen doesn't noticeably suffer from "black
bar syndrome" as SNES9x used to. But in windowed mode, it's very
evident. But I kind of agree anyway to leave it in one place, I imagine
everyone is going to go with the "auto" region mode, whenever I get
around to adding it.
FitzRoy, your idea looks neat, but a few critiques.
The reason I keep frameskip as non-saving and customizable, is because
the frameskip requirements vary per game, and per scene. I also wanted
to bind it to a key shortcut, eg + and -, which would make showing it
in this window at the same time tricky (have to keep them both in sync.
Easier when it's in the menu.) I also want to eventually kill the
frameskip option entirely. It has no place in the emulation core and
hurts the RTO flag calculation.
Aspect ratio is only two options, and that's all it ever will be, so it
seems better to leave that as a checkbox for on/off. Things like the HW
filter though, I'd like to add pixel filters there one day.
The checkbox on the bottom looks a lot better for now, but I do have
additional checkboxes (scanlines and such) I'd want to add in the
future. Then it'd look out of place to have checkboxes above and below
the textboxes.
And of course, one thing I need to do is keep an even number of
dropdown lists for obvious reasons. That makes it more difficult to
just add or remove one by itself. But, maybe we can still work
something out ... I still think your mockup looks good, too.
I'm also really not liking the text inside the comboboxes. It looks
great at a glance, but awkward when you drop the lists down. It's also
not like any other UI out there. I'm going to have to work on extending
libui more, I guess. Need some sort of vertical text centering flag. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 21, 2007 12:06 am Post subject: |
|
I
agree with pretty much everything you say. Why not just get rid of
frameskip now, then? It seems to me that anyone who has to use it is
probably going to choose full speed on a faster emulator anyway. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Sep 21, 2007 4:29 am Post subject: |
|
I need frameskip when using the ntsc filter, so it is a must have feature . |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 21, 2007 5:29 am Post subject: |
|
You would choose 30fps + ntsc filter over 60fps unfiltered? Man, that's some hardcore filter loving. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Sep 21, 2007 2:29 pm Post subject: |
|
byuu wrote: |
I
also want to eventually kill the frameskip option entirely. It has no
place in the emulation core and hurts the RTO flag calculation. |
I was quite in favor of frameskipping before, but if it actually
compromise the accuracy of the RTO thing calculation, I'm in favor of
removing it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Sep 21, 2007 2:32 pm Post subject: |
|
I think it's more likely to be hurting the -speed- of the RTO flag calculation due to increasing complexity. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Sep 21, 2007 2:48 pm Post subject: |
|
Verdauga Greeneyes wrote: |
I think it's more likely to be hurting the -speed- of the RTO flag calculation due to increasing complexity. |
Oh ok, thanks for the clarification. But then again, those two things
are highly related I would imagine. That is, if the calculation is not
done fast enough, the end results - or at least some
results anyway, end up being incorrect, as evidence by the fact that
when frameskip is on, one of the hardware test in the official test
cart thing fails...wherea it passes when it's off.
edit: I mean for me, correct calculation speed would equal a more accurate one.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Sep 21, 2007 3:30 pm Post subject: |
|
byuu,
completely off topic: If you don't mind telling: from what anime(?) did
the character in your previous avatar come from? or does anyone else
know?
edit: Never mind my above comments on the RTO flag calculation
Last edited by Snark on Fri Sep 21, 2007 8:31 pm; edited 1 time in total |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Sep 21, 2007 3:51 pm Post subject: |
|
FitzRoy wrote: |
You would choose 30fps + ntsc filter over 60fps unfiltered? Man, that's some hardcore filter loving. |
When accuracy is needed frame skip can be set to zero, but when showing
off bsnes to old snes'ers like me the ntsc filter is a must. In fact,
that is how I have wowed people in the past with bsnes.
P.S. I think all the other filters are useless, but I guess most people
like the "enhanced" graphics look. I feel that is disingenuous to say
how great the SNES is, but then change the appearance of graphics to
make them more modern. 
Snark wrote: |
byuu,
completely off topic: If you don't mind telling: from what anime(?) did
the character in your previous avatar come from? or does anyone else
know? |
I am fairly sure it is Syaoran Li from Cardcaptor Sakura.
P.P.S. Also off topic, but I always thought it was kind of funny that
byuu didn't use the image of the character from Bahamut Lagoon as his
avatar.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 21, 2007 5:27 pm Post subject: |
|
Quote: |
Why not just get rid of frameskip now, then? |
Only because I use it on my slowest machine, gets ~18fps without,
~55fps with fs=9. Huge time saver for debugging, but I suppose that
isn't very important anymore though, eh? You hoser?
Quote: |
I think it's more likely to be hurting the -speed- of the RTO flag calculation due to increasing complexity. |
Not exactly. To calculate the RTO flags, I have to process all sprites
on every line. This is actually the slowest part of rendering. When
using frameskipping, the idea is to gain speed. I gain 70% of that
speed by skipping RTO flag calculation. But yeah, without the
calculation, the SNES electronics test will fail. It's a pretty simple
hack, it just technically doesn't "belong" in the emulation core.
Plus, FitzRoy is correct. I doubt anyone would accept frameskipping (or
lack of special chips, savestates, speed, etc etc) over using ZSNES for
general purpose gaming.
I'm planning on keeping it though until I get the cycle-PPU renderer
(which may never happen if I can't figure out how to implement it.)
Perhaps I should just hide it from the menu, too? Leave it as a
keybinding only?
Quote: |
In fact, that is how I have wowed people in the past with bsnes. |
Neat-o :D
Well, for the record, I upgraded to snes_ntsc 0.2.2 yesterday (thanks
again for the great lib, blargg!), since Deathlike mentioned ZSNES had
a newer version. Gotta keep up with the Joneses!
Quote: |
I am fairly sure it is Syaoran Li from Cardcaptor Sakura.
P.P.S. Also off topic, but I always thought it was kind of funny that
byuu didn't use the image of the character from Bahamut Lagoon as his
avatar. |
That is correct. I removed the avatar because I got tired of looking at
it. Haven't found a suitable replacement, so.
As for the second point, Square never released any detailed artwork of
Byuu, other than that awful FF4-style one in the manual. Fan art
versions are largely speculative as a result.
Plus, I don't consider my name a relation to that (the game was likely
a romanization of the word 'View'). I kept the name 'byuu' because of
its Japanese meaning.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Sep 22, 2007 1:20 am Post subject: |
|
byuu wrote: |
...that isn't very important anymore though, eh? You hoser?
|
[offtopic] have you watched the movie "Strange Brew?" Also, nice explanation of your name. [/offtopic]
yeah, with other emus frameskipping is often used primarily to speed a
game up beyond 100% anyways but we don't need that when we can just
throttle bsnes up without frameskipping.
Is there a shortcut key to do that? that would be really handy in a bit
if there was, sort of like "incremental throttle up" and "incremental
throttle down" keys.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 24, 2007 6:45 pm Post subject: |
|
I found an interesting article in my referral logs here:
http://www.aep-emu.de/Sections-req-viewarticle-artid-115.html
Hopefully that link is public, heh.
Anyway, from what I could babelfish from German, it seems he's saying
something is wrong with the color in "WWF Super WrestleMania (U) [!]"
... can anyone confirm or deny that? I think he's probably just thrown
off by my color curve that is enabled by default. It will definitely
make the colors appear different from every other emulator (except of
course for the one I stole the idea from, Super Sleuth.)
If it is a bug, let me know and I can start on a fix.
EDIT: heh, looks like the CGRAM address invalidation is throwing it
off. Set the config option to true (the default) and it shows red on
the match preview thing. Set it to false to fix it. Anyone want to test
this on real hardware? I'll have to run some tests, myself. I sincerely
doubt it's timing related.
If anyone knows the author to let him know, the S-DD1 fan translation
bug is not my fault. It's a problem with the translation. I have a fix
for the fan translation here as proof.
And as for ST support, yeah there's not a way to load those at the
moment (you have to manually merge the BIOS with the games to play
them). The emulator supports the games fine, but I never added back the
ST load menu. Kind of forgot and put it off, I'll fix that shortly.
v0.019 should be able to run them for now.
Kind of cheap to get a fail because I don't emulate the mouse on some of those, though :P
Quote: |
have you watched the movie "Strange Brew?" |
Nope, why?
Quote: |
Is there a shortcut key to do that? |
Not yet, planning to use +/- for that. Frameskipping for now; when removed, for speed regulation setting.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Sep 24, 2007 7:20 pm Post subject: |
|
WWF Super WrestleMania (U) [!] - soundtest undertaker intro
"regarding sound the best of all, small color bug in the audience
during the introduction of the wrestlers, otherwise ok"
Star Ocean (J) [T+Eng1.0_DeJap]
"[...] in the unmodified game the title screen is displayed correctly, so it still gets the smiley"
So they're probably aware of the translation's bug...
bsnes gets a minus point for lacking a picture of the controller in the options. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Sep 24, 2007 8:44 pm Post subject: |
|
byuu wrote: |
something is wrong with the color in "WWF Super WrestleMania (U) [!]" ... can anyone confirm or deny that? |
FYI:
There's a copy of an SNES WWF game floating around, I forget which one,
which is interleaved. The interesting thing about this one is that
despite being interleaved, it loads normally, but loads some graphics
from the wrong location.
Of course the fix is to download NSRT and deinterleave 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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Sep 24, 2007 9:07 pm Post subject: |
|
Well, the graphics in this copy look alright. It's just one screen that shows the wrong colors in the background.

I ran some logging, it is attempting to write to CGRAM at V=116 while
the display is enabled. Our tests indicated that CGRAM writes during
active display (except during hblank) went to unknown locations (eg the
S-PPU was likely controlling the CGRAM access address to read palette
colors to display onscreen.)
It looks like HDMA is signaling the writes in this case. They fall between clock 16 and clock 70.
70/4 = 17.5. We know that dots 0 - 274 are hblank, so it appears that
CGRAM writes during 0 to 274-256 (17.5) should go through. This is
another unfortunate bug that requires a cycle-based PPU before we can
really be 100% certain, but I believe increasing the valid times for
CGRAM writes to account for hblank start lead-in will be sufficient for
now. I didn't catch this bug because, well, I'm the first to block
CGRAM writes, so you kind of have to learn this stuff the hard way, heh.
Anyway, my belief is that the PPU really draws between dots 18 - 273,
and not from dots 0 - 255. It's the best explanation for why hblank
takes longer than 256 dots. The lead-in gives time to pre-process
stuff. But of course we have no proof either way of this at the moment.
The bug is now fixed, if the aep-emu guy wants to give me credit for
that, I'd appreciate it. If not, I can post a .01 release ;)
Fix: edit the four lines in cgram_mmio_read and cgram_mmio_write and change:
Code: |
if(v < (!r_cpu->overscan() ? 225 : 240) && hc > 0 && hc < 1096) { |
to:
Code: |
if(v < (!r_cpu->overscan() ? 225 : 240) && hc >= 72 && hc < 1096) { |
My choice of 0x0000 for the forced invalid CGRAM write offset was also
a poor one. I suspect that due to this very tight timing and very, very
late CGRAM write, that the real game is missing some of these CGRAM
writes. At least, it's a possibility. But because I'm remapping them to
the most important color (0, the back color), it's showing up very
strongly. I will change the default write location to 0x01ff for now.
Again, we don't have the algorithm of where to map it right now. Same
thing as with OAM.
Should I post a .023.01 build with this fix or no? I'll also throw in
the NTSC filter update and an ST menu loading option.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Sep 24, 2007 11:31 pm Post subject: |
|
byuu wrote: |
Should I post a .023.01 build with this fix or no? I'll also throw in
the NTSC filter update and an ST menu loading option. |
Hmmmm... will the speed increase or the video setting changes make it in as well?
creaothceann wrote: |
bsnes gets a minus point for lacking a picture of the controller in the options.  |
I know that zsnes and snesgt don't have one either, yet this was only mentioned under bsnes... wha?
Last edited by FitzRoy on Mon Sep 24, 2007 11:43 pm; edited 1 time in total
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Sep 24, 2007 11:39 pm Post subject: |
|
byuu wrote: |
Quote: |
have you watched the movie "Strange Brew?" |
Nope, why?
|
it's filled with canadian terms like "eh?" and "hoser" that were in your post. it was just an offhand comment.
so is their any way to config shortcut keys to incrimentally raise or lower the emulation throttle?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Baron_Samedi New Member
Joined: 25 Sep 2007
Posts: 4
Location: Germany
|
Posted: Tue Sep 25, 2007 1:06 am Post subject: |
|
hello
i'm the one who wrote the snes emu test 
wow that's a fast reaction on the wwf bug 
(i wish other software companies would be this fast)
sure relase your new version with the bug fixes
if u release a new version, i will test it too 
yep i was thinking that the star ocean bug is not your fault
and give your emu full points for star ocean
your emu focuses on accuracy and a clean code without hacks for games,
so i thought that a modified game could create probs
star ocean was the only modified game in the test, because i dont speak japanese to test the org version 
"snesgt has no controller picture"
(i knew i've forgotten something )
zsnes has no pic too, i know but it has a description which button is on which position
but this is only a small thing
somebody who wants to play snes games with an emu will probably know how to set the buttons
there is no need to be unhappy
i give no rating to the emus only a recommendation
and its said that bsnes is the emu of choice for people who have a fast cpu
and who don't play games with the other controllers and unsupported chips
hope u can add support for the missing chips and controllers in the future
atm
there is no perfect snes emulator but if u can add this and the games will run like the other supported games now
i think then the chances to find the perfect emu are very good 
btw: have u plans to add scanlines ? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 25, 2007 1:47 am Post subject: |
|
Quote: |
Hmmmm... will the speed increase or the video setting changes make it in as well? |
I don't remember a speed increase being talked about (bad memory, I
know), but no, the video settings won't make it in so quickly.
I spoke to someone whose input I value (no names since it might upset
those who wanted this), who pointed out that I have in fact been making
too many quick releases without much testing. I happen to agree. So,
I'm just going to release the next version as a private beta to get
some testing done first. I'll release the new version when the
fullscreen settings are complete.
Quote: |
it's filled with canadian terms like "eh?" and "hoser" that were in your post. |
Well, there are other ways to familiarize oneself with Canadian lingo :P
I also know a lot of European / UK / British lingo, too. Now that stuff
is really hard to learn. If you use 100% of it, it sounds like a
completely different language o.O
And no, no way to configure GUI shortcut keys yet. Working on it.
Quote: |
i'm the one who wrote the snes emu test |
Neat! Thanks for stopping by. And thanks a lot for making that review.
Quote: |
wow that's a fast reaction on the wwf bug
(i wish other software companies would be this fast) |
And thank you very much for the bug report. If you ever encounter any
more bugs, please post about it here and I'll fix the bug ASAP. I'm
very serious about maintaining 100% compatibility. If the bug is
possible to fix, I'll do so as quickly as possible.
Thanks again :)
Quote: |
sure relase your new version with the bug fixes
if u release a new version, i will test it too |
Since you reported a bug, I will send you a private message here with a
link to the beta version. It may be a couple of days, but I'll let you
know as soon as I get it ready.
Quote: |
but this is only a small thing
somebody who wants to play snes games with an emu will probably know how to set the buttons |
I used to have a controller picture, the same one that the uosnes
author took from bsnes. I had to remove it when I ported to Linux, but
I've been meaning to add it back for a while now. I'll add it back
eventually.
Quote: |
there is no need to be unhappy |
Oh, don't worry. I'm actually very happy in that you reported a new bug
that I was able to fix. I'll be the first to admit that bsnes is
probably the worst emulator to use for casual gaming. It's very slow,
lacks features like savestates, and only supports the simplistic
special chips that are well documented. I like to think of it as a
research project, where my findings mostly get backported into ZSNES
and SNES9x. And of course, there's the friendly competition that helps
motivate the entire community.
Quote: |
btw: have u plans to add scanlines ? |
This was another thing I lost when I ported the emulator to Linux. I
use hardware acceleration to draw scanlines with no overhead. I had to
remove them in v0.020 and above because of this. But yes, I do plan to
add them back eventually.
Sorry for all the missing features, I've still yet to recover from the loss of features in v0.019.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Sep 25, 2007 3:39 am Post subject: |
|
yeah
other terms in other english speaking countries are very interesting. I
myself spent most of my young years around Australians.
I'm sure you'll eventually work out the lost features and it's no
biggie, I think you porting it was also just as if not more important
than the features in and of themselves. (even though I am currently
running a windows system, but plan make a partition for the new version
of Kubuntu for starters)
What with what you are doing with bsnes such as bugfixes and getting
the old features back plus more, AND ZSNES 2.0 in developement this is
an exciting time for the SNES scene.
Keep up the great work!
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Sep 25, 2007 4:03 am Post subject: |
|
byuu wrote: |
I don't remember a speed increase being talked about (bad memory, I
know), but no, the video settings won't make it in so quickly.
|
Something about MingGW giving a 16% boost?
Also, the gamepad image isn't necessary and it shouldn't be held
against bsnes or any other emulator for not trying to make space for
some oblong jpg in the cfg. It isn't that hard to google image an snes
pad if they can't remember that B comes before A. If you were really
worried, you could just include the image as a separate file. But
seeing as how zsnes gets umpteen posts about savestate issues and
nothing about abxy, you probably don't have to be.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 25, 2007 2:20 pm Post subject: |
|
Alright, I've posted the new WIP.
Changelog:
- CGRAM fix for WWF Super Wrestlemania
- Updated to blargg's snes_ntsc library to version 0.2.2
- Added ST and ST dual cart loading menu options (*)
- Redesigned the video mode configuration panel a bit -- let me know what you think (**)
(*) - You have to set path.bios to an -absolute- path, ./ is currently
broken and I need to fix that. So, set it to eg "c:/path/to/bsnes/bios"
where stbios.bin is inside that folder.
(**) - The video menu obviously doesn't do anything, it's just there for design advice / suggestions for now.
You'll notice the icon is gone. This is because I built this version
with MinGW 4, and I'm not sure how to add the icon to MinGW apps.
You'll also notice it's ~6% faster on Core 2 processors as a result.
The 16% speedup was only when PGO was enabled. But I can't enable that,
because it causes bsnes to crash randomly. GCC gets too risky with its
optimizations and ends up generating bad code (the GCC manual states as
much, I'm not just trying to blame problems in my app on GCC here.)
So, 6% is the best speedup we can do for now. Compare to v0.023
official if you like. You probably won't see the speedup on older
processors like the Pentium IV.
EDIT: it seems like that MinGW vsnprintf problem is based on DLL files
on the local computer. Probably the MS VisualC runtime files. The WIP
works fine on my home PC (WinXP Pro), but not on my work PC (Win2k).
I'm going to have to stick with Visual C++ builds until I am able to
completely remove all sprintf-style calls from the emulator.
If you get an error about memory at 0xffffffff which cannot be read,
you know why. Try building with Visual C++ if you have it, or maybe
there's some way to upgrade libc DLLs that the app is binding to.
Whatever DLL has vsnprintf is the one that needs to be updated, if at
all possible.
Here's what the video config screen looks like at the moment.

I tried putting the text at the top, that way there won't be any odd
gaps between the text and combo box dropdown, due to different sized
fonts on different platforms. |
|
Baron_Samedi New Member
Joined: 25 Sep 2007
Posts: 4
Location: Germany
|
Posted: Tue Sep 25, 2007 6:08 pm Post subject: |
|
thx for the wip version
when u release a new public version i'll change the test
btw the guys from aep modified the test
now smilys are visibly like they should be 
u said something that bsnes is a bit slow....
yep with my old amd 2700+
i get sometimes only 50 to 55 fps...
the solution until i buy i new comp is to play with european pal roms 
(in the test i used only ntsc roms because some pal games run slower as
they are designed to be played because of ntsc-->pal conversation)
(before i made the test i haven't looked into bug threads of the emus
because i want to make a fair test and chose the games without knowing
the bugs of each emu with some games)
savestates would be very good, but i read something that its very difficult to include it
mey be this is something for bsnes.....
in the past some progs for pc games (under ms based os) save the complete memory
doing this in bsnes would create a very large savegame....
the bad part
u have to create the same envrionment when resuming
as u have saved the memory
otherwise the os will crash
mey be its possible to save only the part in memory which bsnes uses
to create a savegame.... |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Sep 25, 2007 6:13 pm Post subject: |
|
byuu wrote: |
So, 6% is the best speedup we can do for now.
|
If you use GCC's special options for certain processors, you can get it even faster for those.
I've toyed with this idea before, I got a bsnes which at run time
peforms CPU optimization, except this idea blows up if you have static
class created at run time. If we can replace the global static classes
created at run time and replace with a factory method inside a
singleton access function, we'd be able to provide this per CPU speed
up for everyone regardless of the CPU inside one binary.
byuu wrote: |
EDIT: it seems like that MinGW vsnprintf problem is based on DLL files
on the local computer. Probably the MS VisualC runtime files. The WIP
works fine on my home PC (WinXP Pro), but not on my work PC (Win2k).
I'm going to have to stick with Visual C++ builds until I am able to
completely remove all sprintf-style calls from the emulator.
If you get an error about memory at 0xffffffff which cannot be read,
you know why. Try building with Visual C++ if you have it, or maybe
there's some way to upgrade libc DLLs that the app is binding to.
Whatever DLL has vsnprintf is the one that needs to be updated, if at
all possible.
|
I've said it before, I'll say it again, it's terrible to use ...
functions. You should try to replace with C++ style functions whenever
possible. However if you really need to use them, you can find proper
implementations of vsnprintf online that you could use instead, this is
easy to work around.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 25, 2007 6:44 pm Post subject: |
|
Quote: |
I've
toyed with this idea before, I got a bsnes which at run time peforms
CPU optimization, except this idea blows up if you have static class
created at run time. |
Well, I'm certainly willing to try it. Just suggest small changes at a
time, and I can try and rework the code so that this idea is possible.
Just don't overwhelm me with too many changes at once please, I've been
rather pressed for time this past ... year and a half.
Quote: |
I've said it before, I'll say it again, it's terrible to use ... functions. |
Oh, I certainly agree with you. I've been trying to rewrite all of the
string functions to use string streaming. Having trouble coming up with
a nice wrapper to the %0.Nf formatting of printf, though. I don't like
std::ios_base syntax at all. But yes, my goal is to remove all ...
syntax from the program eventually (well, sans what libraries like GTK+
require.)
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Sep 25, 2007 7:49 pm Post subject: |
|
byuu,
I wanted to ask about the 0.023 CGRAM change that affect WWF Super
WrestleMania (U) and if you were aware of any other games that had
issues because of it, but I see you've posted something about it on
your WIP. So if you don't mind me quoting you for those that haven't
checked your page:
byuu wrote: |
One
of the problems when you want to emulate a hardware restriction, but do
not know the exact details, is that you have to make a choice: you can
be permissive, allowing the invalid input more often than not, which
also yields the greatest overall compatibility; or you can be
restrictive, and enforce the restriction even moreso than the real
hardware, which will often break games. I usually choose the latter, as
this allows us to quickly locate games with very sensitive timing and
that can be affected by these restrictions.
Recently, I added restrictions to writing to CGRAM during active
display. As I learned yesterday, this is being triggered by WWF Super
Wrestlemania, causing the colors in the intro to appear wrong. I have
since adjusted the timing to be just permissive enough to fix this bug.
But it did reveal something interesting: a game that tries to write to
CGRAM during active display, outside of vblank. We did not have any
known examples of games doing this before yesterday.
So, on the downside, v0.023 is no longer known to be bugfree. But on
the upside, we have a good regression test ROM for when CGRAM writes
during active display are better understood and emulated properly.
Unfortunately, I've been rushing releases too much lately, so I'm not
going to post a new version just because of this one fix. Instead, I'm
working on some additional things first.
So far, I've re-added ST and ST dual cart loading from the menu,
updated to blargg's snes_ntsc 0.2.2 filter, and started on re-adding
true fullscreen support to the Windows port. I've only completed the
GUI portion on the last point, but it's getting there little by little. |
So there are no known games broken by the new CGRAM restriction/change
so far? Guess those Acclaim Midway arcade ports (mostly Wolf unit
games: MK, Mk2 Wrestlemania etc) used (back then) some pretty "novel"
coding methods eh?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 25, 2007 8:25 pm Post subject: |
|
Nah,
it looks like it just tried to do too much during HDMA and ran out of
vblank time. Lots and lots of games do that. This is the main reason we
need to render the scanline halfway through the line to get things to
appear correct in most games.
Lots of games have
this issue with other stuff. Metroid 3 and Dai Kaijuu Monogatari 2 do
the same thing with the background enable register. This is just the
first one we've seen do this with CGRAM writes. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Sep 25, 2007 9:15 pm Post subject: |
|
Ah sorry. Didn't noticed you mentionned that it was related to the scanline renderer:
Quote: |
This is another unfortunate bug that requires a cycle-based PPU before we can really be 100% certain |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Sep 26, 2007 3:23 am Post subject: |
|
Looks
nice and balanced. The 6% speed increase is actually fairly significant
for me. I was dipping to 57 on the CT intro before, and now it doesn't 
Some suggestions:
-Change the selection boxes in the "Input" section to the same style as
the video setting ones. Also, there seems to be 2x more space than
normal under the input boxes right now.
-The "mode" in the three mode names is overly descriptive as we know
they're modes from "Select video mode." An analogy would be calling the
filters "HQ2x software filter," etc.
-Compared to the video setting checkboxes, the raster setting
checkboxes seem to have more space between them. Both should probably
be like the video setting ones are now.
-Consider listing out the raster checkboxes instead of pairing them. I think it would look better.
-The "Default" button under "Advanced" seems unnecessary. Anyone
advanced enough to use this area can see and set the default back the
same way they changed it. Removing it also allows the "Set" button to
be a 1/3 width like those in the cheat code editor. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Sep 26, 2007 3:28 am Post subject: |
|
i
disabled C1E support and Intel Speedstep Technology and adjusted the
affinity mask on the emulators EXE file so that only 1 core is used.
now it sits at 100% usage on the one core and the other core indeed
doesnt do anything... performance is the same either way tho.
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 26, 2007 3:31 pm Post subject: |
|
Offtopic:
I was recently discussing a common entry-level CS question with Nach,
and came up with a solution requiring no conditional branching. I
thought it would be fun to demonstrate my solution, while at the same
time reversing the question in a Jeopardy-like fashion.
So, can anyone identify what problem the below function solves?
Code: |
int fn(int a, int b) {
return (a != (b + 1) % 3) + 1 & (a == b) - 1;
} |
Nach, you aren't allowed to answer :P
Quote: |
Looks
nice and balanced. The 6% speed increase is actually fairly significant
for me. I was dipping to 57 on the CT intro before, and now it doesn't |
Wow, I get around ~100fps on the CT intro with a stock speed E6600 ... well, glad to hear it helped.
As far as your suggestions, I agree with most of them. The reason the
spacing is off is because I have to use the smallest size that won't
crush the text on Linux, which is always much bigger than on Windows.
What I need to do is add functions to libui to calculate the most
desirable height for various controls, and then adjust the list boxes
to fill the rest of the space. Until then, it's going to look like crap
on one platform or the other, sadly.
The only suggestion I disagree with: I like the default button on the
advanced panel. It's just a quick way to revert changes. I use it quite
a bit, actually. But I mess around there a lot more than most people.
Quote: |
now
it sits at 100% usage on the one core and the other core indeed doesnt
do anything... performance is the same either way tho. |
I really don't know why you're having this problem. I only show one
core being used. Only my Pentium IV with the fake dual core
("Hyperthreading") shows CPU usage on both cores. Maybe the video card
driver or something is forking another thread? Who knows ... but I can
assure you that my code is single threaded.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Sep 26, 2007 9:34 pm Post subject: |
|
byuu wrote: |
So, can anyone identify what problem the below function solves?
Code: |
int fn(int a, int b) {
return (a != (b + 1) % 3) + 1 & (a == b) - 1;
} |
|
..I don't see it ;_; Testing it out is cheating, I presume? By the way, you should try sending it in to that bit twiddling hacks website.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Wed Sep 26, 2007 10:10 pm Post subject: |
|
The remainder after a division of 3, and the 'f', make me think it has something to do with making triple buffering work.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Sep 26, 2007 10:54 pm Post subject: |
|
Quote: |
So, can anyone identify what problem the below function solves?
Code: |
int fn(int a, int b) {
return (a != (b + 1) % 3) + 1 & (a == b) - 1;
} |
|
Hmmm... next year's Obfuscated C Contest entry?
Here's a tested, clear function that does the equivalent. Looks like
Metatron is right, and the function returns the number of frames to
emulate, with a being the currently displayed buffer and b some kind of
frame counter.
Code: |
int fn2( int a, int b )
{
if ( a == b )
return 0;
if ( a == (b + 1) % 3 )
return 1;
return 2;
} |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 26, 2007 11:07 pm Post subject: |
|
Quote: |
..I
don't see it ;_; Testing it out is cheating, I presume? :P By the way,
you should try sending it in to that bit twiddling hacks website. |
Nope, not cheating at all. Feel free to test it all you like.
Quote: |
The remainder after a division of 3, and the 'f', make me think it has something to do with making triple buffering work. |
Nope.
Quote: |
Here's a tested, clear function that does the equivalent. |
Correct, that function gives the same result. Now, what does the function do? :)
Again, a hint is that this solves a problem one would ask an
entry-level CS class. Triple buffering would be too complex for that.
---
EDIT: blargg is out of the 'competition', as I told him what the function does.
... and then he came up with a vastly superior solution that completely destroys mine, reducing it from seven ops to a mere three operations. Sigh, why must he be so much smarter than me? I try so hard, too ;_;
Without further ado, blargg's masterpiece:
Code: |
int fn(int a, int b) {
return (a + 3 - b) % 3;
} |
Other (much faster, but more complex) variations:
Code: |
a -= b; if ( a < 0 ) a += 3; return a;
return 0x62118 >> (a * 8 + b * 2) & 3; |
Last edited by byuu on Wed Sep 26, 2007 11:51 pm; edited 1 time in total
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Sep 26, 2007 11:46 pm Post subject: |
|
the question is: " are a and b different"
Entry level CS? more like grade 8 computer class.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Sep 26, 2007 11:54 pm Post subject: |
|
One thing missing is an assertion showing the range of the inputs, which should be part of CS teaching too:
assert( 0 <= a && a <= 2 && 0 <= b && b <= 2 );
That is, a and b are in the range 0-2, inclusive. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Sep 26, 2007 11:59 pm Post subject: |
|
There are three results based in the inputs funkyass, not two. |
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Sep 27, 2007 12:10 am Post subject: |
|
Code: |
int fn(int a, int b, int c)
{
return (a + c - b) % c;
} |
I kept on wondering why I keep windows powershell around...
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
ndru New Member

Joined: 30 Nov 2004
Posts: 8
|
Posted: Thu Sep 27, 2007 1:14 am Post subject: |
|
The function seems to effectively rotate the elements of an array to the right b times, relative to the index a. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 27, 2007 1:52 am Post subject: |
|
What
funkyass posted is essentially the implementation of a ring buffer
rewind, where 'a' is the current position, 'b' is how far you want to
rewind, and 'c' is the size of the buffer. What blargg has done was use
this with a constant 'c' of 3.
There's a funny
problem with modulo when your input is less than zero. I realized that
adding would avoid the problem, coming up with !=(b+1)%3 to substitute
for ==(b-1)%3.
I had the partial solution earlier of ((b - 2) - a) % 3, but ran into
the negative modulo problem, and abandoned the idea, regrettably too
soon.
But what I failed to realize, blargg did not. You can extend that to
handle cases greater than one. You need only add the size of the ring
buffer, where it will be eliminated by the modulo later anyway. It's
funny how an idea can elude you so completely, yet seem so obvious when
presented to you later on. But, this reasoning is what separates the
smart from the helpless.
Anyway, I was hoping someone would be able to figure out both what the
function does, as well as what problem it solves. But alas, the former
has already been mostly determined:
Takes two inputs between 0 - 2, and returns 'a' moved left by 'b'
places, clamped inside a result of 0 - 2 (modulo 3). This gives you 3x3
inputs with 3 results. Equality returns 0, but inequality can return
either 1 or 2 (but does anyone know the significance of 1 or 2 as a
result?)
Now, the question is, what could one use this function to solve? If
nobody can determine the answer by tomorrow afternoon, I'll post the
answer. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Sep 27, 2007 3:14 am Post subject: |
|
Quote: |
Now,
the question is, what could one use this function to solve? If nobody
can determine the answer by tomorrow afternoon, I'll post the answer. |
Put another way, what meanings can be mapped to the values. It's such a
general algorithm (rotate array, as ndru stated) that there are
probably many meanings you could assign to the inputs and outputs.
Tabluating the whole thing, with output values grouped:
a b out
--------
0 0 0
1 1 0
2 2 0
0 2 1
1 0 1
2 1 1
0 1 2
1 2 2
2 0 2
And for kicks, several implementations of it, some possibly more efficient:
Code: |
int fn3( int a, int b ) { return (a + 3 - b) % 3; }
int fn4( int a, int b )
{
a -= b;
if ( a < 0 )
a += 3;
return a;
}
// table padded to 4 to avoid multiply in indexing
int fn5( int a, int b )
{
const int table [3] [4] = { {0, 2, 1}, {1, 0, 2}, {2, 1, 0} };
return table [a] [b];
}
// table encoded into an integer, 2 bits per entry
int fn6( int a, int b ) { return 0x62118 >> (a * 8 + b * 2) & 3; } |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 27, 2007 3:43 am Post subject: |
|
I
love getting rid of if's ... though it's a toss up as to whether or not
a single branch is faster or slower than a single multiplication.
Code: |
int fn4a(int a, int b) {
return (a -= b) + (a < 0) * 3;
//return (a -= b) + ((a >= 0) - 1) & 3; //may be faster
} |
fn3, while the slowest of all, is definitely my favorite function, by virtue of its sheer simplicity.
I'll give one more hint. When using (a - b) with b > a, you get a
negative value. The +3 and subsequent modulus convert this negative
value to 'wrap around' back to the top. That is, -1 becomes 2, -2
becomes 1. Typical behavior of a ring (or circular) buffer.
You could look at it as ... 0 < 1 < 2 < 0 < 1 < 2 <
... or ... 2 > 1 > 0 > 2 > 1 > 2 ... it's circular. Try
and think of a common circular problem with two inputs that can be up
to three different values each, that gives one of three results.
Last edited by byuu on Thu Sep 27, 2007 3:49 am; edited 2 times in total
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Thu Sep 27, 2007 3:47 am Post subject: |
|
For some reason, uses of modulo like that always elude me... much like the term modulo itself, ahahaha.
This is probably so painfully simple and I will feel stupid tomorrow. <.<
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Sep 27, 2007 3:42 pm Post subject: |
|
Alright, sorry guys. Time's up.
Here are the inputs:
Code: |
enum { Rock, Paper, Scissors }; |
And here are the outputs:
Code: |
enum { Draw, PlayerAWins, PlayerBWins }; |
fn3 is a three-operation implementation of the usual below routine:
Code: |
int play_conditional(int a, int b) {
if(a == Rock) {
if(b == Rock)return Draw;
if(b == Paper)return PlayerBWins;
return PlayerAWins;
} else if(a == Paper) {
if(b == Rock)return PlayerAWins;
if(b == Paper)return Draw;
return PlayerBWins;
} else {
if(b == Rock)return PlayerBWins;
if(b == Paper)return PlayerAWins;
return Draw;
}
} |
The experiment served two purposes. To show off my solution, and to see
if anyone could do better (blargg bested me), and more importantly, to
demonstrate the sheer difficulty of reverse engineering these bit
tricks.
It seems that it takes most a few hours to figure out what the function does, but without an explanation of why, understanding the function is useless.
This just goes to reaffirm that extreme documentation is absolutely
critical whenever one uses these fun little algorithms.
Another interesting point was the sheer difficulty of creating an
optimal solution. You may be surprised to learn that "(a + 3 - b) % 3"
was actually the slowest routine of all, almost twice as slow as all
the others. And despite conditionals supposedly destroying performance
on modern pipelined processors, even with full randomization of inputs,
the 12x conditional version was tied in second place for the fastest
algorithm of all.
But that was only on one platform. Undoubtedly, the optimal solution
changes depending on the platform. It kind of regulates extreme
simplification of algorithms down to an art form, but not a practical
one for daily use. Surely we can usually tell when one algorithm beats
another, but really fine tuning things seems to be an impossibility.
Kind of makes you wonder what you should aim for when coding. The
clearest, yet most whorish of examples, such as the 12-step conditional
version; the most concise version, such as blargg's; or what appears to
work best overall for your current platform, such as blargg's
integer-packed table. Or maybe just using flat lookup tables is best.
Though I always tend to hate those, as they make the values in the
tables appear so mysterious to everyone else.
Anyway, thanks everyone for playing along. As a bonus for me, I was
able to pick up a few new bit tricks that I can definitely make use of
in bsnes. And if anyone ever wants to freak the hell out of their CS
101 teacher in the future, you now have a really fun solution to this
common question.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Sep 27, 2007 5:08 pm Post subject: |
|
Quote: |
And
if anyone ever wants to freak the hell out of their CS 101 teacher in
the future, you now have a really fun solution to this common question. |
...unless the CS teacher reorders the enum to something like enum {
PlayerAWins, Draw, PlayerBWins }; hmmm actually any reorderings of the
enums can be dealt with since it merely rotates/mirrors the values (a
special property of three-valued systems like this). Rotation is
obviously dealt with by the offset before the modulo, and mirroring by
swapping a and b in the calculation.
Another interesting thing that came of this was byuu's original timing
test did the combinations in a repeating order like a=0 b=0, a=0 b=1,
a=0 b=2, a=1 b=0 ... which the x86's branch predictor was able to lock
on to, due to its storage of history. Changing it to use random a and b
inputs caused the conditional implementations to perform worse than the
table-based ones.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Sep 27, 2007 8:14 pm Post subject: |
|
byuu wrote: |
Or
maybe just using flat lookup tables is best. Though I always tend to
hate those, as they make the values in the tables appear so mysterious
to everyone else. |
byuu wrote: |
This just goes to reaffirm that extreme documentation is absolutely critical whenever one uses these fun little algorithms. |
Just include the algorithm as code or pseude-code in the comments. Table values can be explained. 
(If that makes the source messy, "outsource" the algorithm to programs
residing in subdirectories, that create the tables to be #included into
the emulator's source. That's how I unrolled tile decoding...)
_________________
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: Fri Sep 28, 2007 12:02 am Post subject: |
|
Byuu,
with the graphics filters are they off loaded onto another core (if
available) while the emulation is done on a single core?
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 28, 2007 12:06 am Post subject: |
|
franpa,
reinstall xp slipstreamed @ sp2 + RyanVM patches. Install the latest
chipset and video card drivers, and if your problem still persists, you
have a legitimate issue. Until then, the possibility exists that you've
screwed something up. And get xp pro while you're at it. Home doesn't
even support multiple CPU systems, which makes me think its dual-core
support is sketchy as well. You also have an extremely new CPU. Try
updating your BIOS. There are all kinds of updates you can do on your
end before fixating on bsnes. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Sep 28, 2007 1:54 am Post subject: |
|
video drivers are latest.
winXP was just then reinstalled. (due to getting a virus before -.-)
latest motherboard chipset installed.
no updates for my BIOS are available yet.
turned off all power saving options in the BIOS including thos CPU options like C1E, Intel Speed Step, TM, etc.
yes im using service pack 2 and latest windows updates..
what is this RyanVM Patches?
Windows XP doesnt support 2 seperate CPUs in 2 different sockets on the
one motherboard... Windows XP Pro does. a dual core and core2 duo are
just a single CPU in a single socket... (you may be right that the
support in winXP home is simply horrible tho)
_________________
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. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Sep 28, 2007 7:15 am Post subject: |
|
For all purposes that matters to the os, a core is a cpu.
So it should show 2 cpu usage bars in the task manager. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Sep 28, 2007 7:57 am Post subject: |
|
yes but the limitation is whether the CPUs are indeed separate or not.
if its a single CPU with multiple cores then of course it would be given special treatment.
_________________
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. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Sep 28, 2007 8:50 am Post subject: |
|
RyanVM's Website
code65536's update addon to keep everything up to date while RyanVM is busy
Updated DirectX 9.0c addon (updates for managed code, but a lot of games want a later version than SP2 ships with)
Those are the main ones, but the unattended scene goes pretty deep.
Kelsenellenelvian and RogueSpear offer runtimes addons, Shark007 the
VistaCodecPack (also suitable for XP), and there are loads of
switchless installers and addons that allow you to integrate other 3rd
party software into your Windows XP CD.
For the actual integration use either nLite or the Integrator. I prefer nLite myself, for various reasons, but it offers a lot of functionality you might not need. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Sep 28, 2007 9:02 am Post subject: |
|
so im meant to reinstall updates from RyanVM's website/forums?
im looking at this direct x thing... what is it? is it for
slipstreaming the quarterly builds of direct x into the CD? if yes then
why would i need to if i already went to MS site to get the august
build?
_________________
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. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Sep 28, 2007 1:30 pm Post subject: |
|
Byuu,
i would optimise for intel core2duo and beyond, the reason for this is
that intel is slowly catching up to any advantages AMD currently has,
so either way in a few cpu's the results will probably be similar. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Fri Sep 28, 2007 1:34 pm Post subject: |
|
FitzRoy wrote: |
And
get xp pro while you're at it. Home doesn't even support multiple CPU
systems, which makes me think its dual-core support is sketchy as well. |
Home supports multi-core, but not multiprocessor.
The limitation is not an operating system limitation, but a licensing one, enforced by software.
XP Home is licensed to only run on 1 CPU, but multicore works just fine, just the same as on Pro.
XP Pro is licensed to only run on 1-2CPUs, but works just fine on the Intel Quad Core processors.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Sep 28, 2007 2:04 pm Post subject: |
|
DataPath wrote: |
FitzRoy wrote: |
And
get xp pro while you're at it. Home doesn't even support multiple CPU
systems, which makes me think its dual-core support is sketchy as well. |
Home supports multi-core, but not multiprocessor.
The limitation is not an operating system limitation, but a licensing one, enforced by software.
XP Home is licensed to only run on 1 CPU, but multicore works just fine, just the same as on Pro.
XP Pro is licensed to only run on 1-2CPUs, but works just fine on the Intel Quad Core processors.
|
I believe multi-core support was enhanced on Home with the release of SP2. Same difference, of course.
franpa, there's no difference except that you won't have to go to
Microsoft's website, and it's a much smaller download. All the packs
and things I mentioned are meant to be integrated into your windows CD,
although of course switchless installers will run just fine when you
run them manually. (the same can be said for most addons, but in that
case you have to do some more work which requires a basic knowledge of
inf files)
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Sep 28, 2007 4:08 pm Post subject: |
|
tetsuo55 wrote: |
Byuu,
i would optimise for intel core2duo and beyond, the reason for this is
that intel is slowly catching up to any advantages AMD currently has,
so either way in a few cpu's the results will probably be similar. |
This is simply a terrible idea, especially when it alienates the user
base even futher, which was already limited to begin with.
_________________
FF4 research never ends for me.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Sep 28, 2007 6:24 pm Post subject: |
|
Yeah,
optimising for Core 2 Duos seems like a bad idea, especially now that
AMD's Phenom is closing in. However, if byuu ever takes out frame
skipping, bsnes might as well be compiled with SSE2 (although I dunno
if that makes much of a difference) because non-SSE2 capable processers
won't be able to run it full speed anyway. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Sep 28, 2007 7:25 pm Post subject: |
|
usually it would be a bad idea but in this case:
-From what ive seen a lot of bsnes users have intel systems, or have recently upgraded to core2duo's
-If i remember correctly intel usually loses more than amd wins with byuu's optimisations
Besides these points the most demanding games are already unplayable on
most amd systems, if the phenom really is faster and cheaper(googling
around the consesus is that it will be slower than penryn's and more
expencive) it will easily get 60fps and even if its slower than
core2duo it will still get 60fps, that is as long as the dot based
renderer is not in there. By the time thats finished we will again have
new cpu's
to put a little more perspective on things: i actually use amd systems to play bsnes.
Lets discuss it further |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 28, 2007 8:36 pm Post subject: |
|
I
don't think the cell supports SSE. Even if it were implemented, the
only reason would be to make SuperFX and SA-1 feasible, since even the
lowest end Core 2 Duo already runs at 60fps. And you know, I doubt SSE2
is going to do squat for that. More effective would be creating an
opcode version, which I don't think byuu is quite ready to do yet. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Sep 28, 2007 9:58 pm Post subject: |
|
You're
probably right.. I remember there was some discussion on this a while
ago, and it was mentioned that SSE4 might help a lot more.. of course
that's still a ways off and, like you said, isn't needed anyway. Though
I hope it might help make the dot-based renderer more feasible  |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 28, 2007 10:09 pm Post subject: |
|
Quote: |
Yeah,
optimising for Core 2 Duos seems like a bad idea, especially now that
AMD's Phenom is closing in. However, if byuu ever takes out frame
skipping, bsnes might as well be compiled with SSE2 (although I dunno
if that makes much of a difference) because non-SSE2 capable processers
won't be able to run it full speed anyway. |
Enabling SSE2 optimizations actually makes bsnes run slower on my E6600. Kind of amusing, really.
Quote: |
This is simply a terrible idea, especially when it alienates the user base even futher, which was already limited to begin with. |
True, less than 2% of SNES emulator users even have bsnes. ZSNES is at
least ten times faster, supports far more special chips and hardware,
and has a ton of additional features. It represents absolutely zero
challenge to ZSNES' dominance.
Quote: |
More effective would be creating an opcode version, which I don't think byuu is quite ready to do yet. |
I really do want to refactor the code to support things like this in
the future. A really clean, polished opcode core built as a general
purpose library could possibly rival SNES9x one day. But yes, that's a
long ways off.
I've been reading over Effective C++ lately, and it's very clear that
bsnes, well, isn't. I kind of have my own style, but I really do need
to adhere more to accepted standards other than my own personal
preferences.
Perhaps an opcode-based version of the core is a good opportunity to work on this.
Quote: |
Though I hope it might help make the dot-based renderer more feasible |
I honestly think it can be done on modern hardware. Just not the way I
want to do it. Perhaps after I've reverse engineered enough of the
S-PPU, ZSNES v2.x can use those findings as well to implement a fast
version for end users.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 29, 2007 12:07 am Post subject: |
|
byuu wrote: |
True, less than 2% of SNES emulator users even have bsnes. ZSNES is at
least ten times faster, supports far more special chips and hardware,
and has a ton of additional features. It represents absolutely zero
challenge to ZSNES' dominance. |
That number is not entirely a result of those differences. Most people
get their emulators from the same place they get their roms, and as far
as romsites are concerned, SNES9x and ZSNES are it. Good luck changing
that, too, since most sites look like the admin's been on vacation for
two years.
There are definitely things you could do to help yourself, though. You
just need some marketing tactics. I'll bet if you released a bSNES 1.52
next week, you'd double your userbase overnight. See how the capital
letters stand out more? See how 1.52 is higher than 1.51? I don't think
you know how right I am on this
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Sat Sep 29, 2007 3:16 am Post subject: Bsnes gfx bug in rom |
|
Hiya byuu,
I am a big fan of your emu ever since the early days of bsnes as I knew
it had amazing potential so cheers for a great emu, and a website that
I check all the time =D
I know of a snes rom that could help you get more accurate snes raphics
rendering and help with some other timing stuff.
The rom is called "Sidmania (PD).smc"
by the demo group censor and is a collection of c64 sid chip tunes
emulated with the spc700. You need to press start like 4 times at the
start to get past the initial text screen.
This
rom shows that bsnes is second to none when it comes to snes sound
emulation, just try it in snes9x, zsnes, or snesgt to see how much
better your emu is, I truly think you have achieved perfect snes sound
emulation, something I have waited years for 
However there is a star wars style mode 7 scroller at the start before
the music list, that does not display correctly, I run the rom on real
hardware so I know that it is not being precessed correctly, and you
can see obvious graphics glitches in bsnes v 0.23.
It is meant to show a white single pixel star field moving from right
to left, with a thick grey font scrolling star wars style and
rotatating around the screen. You can also see that for a few seconds
the scroller gets rendered correctly then goes back into random garbled
pixels again in bsnes v 0.23.
(I know that you preffer official game bugs to homebrew rom bugs but I
think this rom can show you processing in the snes hardware that no
official games, or the official snes test can show you)
Also I know this may sound crazy but I think the graphics worked
perfectly in bsnes v 0.09, 0.11, 0.12, 0.13, 0.14, cant remember which
because I can not find the binaries anywhere to test, and after like
v0.14 I remember the gfx getting worse in the rom and the sound getting
better and better with each subsequant bsnes release!
I hope this helps you to make the best snes emu even better, p.s your emu thrashes everyone elses (sorry zsnes guys!)
and I know this because I have been following the snes emu scene since
the early days of snes96 when mario jumped upside down, and this is the
emu that gives me the most hope of accurate snes emulation, keep up the
amazing work =D |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 29, 2007 4:52 am Post subject: |
|
krom,
you can thank blargg for that wonderful sound core. He contributed it
to bsnes after extensive testing, though it probably won't be exclusive
to bsnes forever.
As for your bug report, I've
tested the rom on real hardware and have gotten different results from
you. The mode7 scroll that appears "correctly" on zsnes appears
identically broken for me on bsnes and real hardware. I am using a
tototek flash cart. I take it you have an older copier device, though I
can't suggest why yours would display correctly while mine doesn't.
byuu might know. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Sat Sep 29, 2007 5:58 am Post subject: reply to FitzRoy |
|
Hi FitzRoy,
I just tested in zsnes and you are right the mode 7 scroller is there
but it is missing the point pixel stars scrolling from right to left,
so maybe there is a clue in the zsnes mode 7 or hdma to fix the bsnes
issue with the scroller.
I own a very old Super Wildcard DX
that uses disks, so maybe this old demo was designed on one of these
old backup devices, and will not work with newer devices, possibly
because of ram timing or something, pretty weird if you ask me!
p.s thanks to blargg for that wonderful sound core =D |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Sep 29, 2007 6:48 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
True, less than 2% of SNES emulator users even have bsnes. ZSNES is at
least ten times faster, supports far more special chips and hardware,
and has a ton of additional features. It represents absolutely zero
challenge to ZSNES' dominance. |
That number is not entirely a result of those differences. Most people
get their emulators from the same place they get their roms, and as far
as romsites are concerned, SNES9x and ZSNES are it. Good luck changing
that, too, since most sites look like the admin's been on vacation for
two years.
|
I know of one site (which has most g003xxx s3ts) who described bsnes as
"fairly new and thus, has still fairly low compatibility" (my
translation)...Sad I know. Worse thing is they DO have the latest 0.023
version...they just don't bother updating the description. Heh.
Quote: |
There
are definitely things you could do to help yourself, though. You just
need some marketing tactics. I'll bet if you released a bSNES 1.52 next
week, you'd double your userbase overnight. See how the capital letters
stand out more? |
buzz. Wrong. byuu needs to change the name to bNES...Now THAT is teh 3lite...Just like that other emulator...what's the name again...oh yeah, Z NES
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Sep 29, 2007 7:32 am Post subject: |
|
might as well test the Sidmania (PD) demo rom in question myself on my SF3...
Ok: I tested the demo on my copier and bsnes 0.023.
First, the intro screen where "CENSOR" is bouncing up and down with the
text...My copier(?) and/or SNES(?) just shows bouncing corrupted gfx...Whereas it shows normal text in bsnes. So that's a first difference, don't know what's causing it, could be caused by the copier.
EDIT: WAIT the above is not correct. It works fine on the copier...For
some reason it only shows corrupted gfx on the first initial loading
(after loading from the floppy) after that if I reset or power off it
works fine. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Sep 29, 2007 7:39 am Post subject: |
|
Ok I'm sorry for triple posting...But for the sake of clarity:
I wrote: |
I tested the demo on 0.023 on my SF3 copier and could not find any differences |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Sep 29, 2007 9:41 am Post subject: |
|
This is beginning to sound more and more as reading uninitialized memory... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 29, 2007 10:07 am Post subject: |
|
krom,
thank you for the feedback. Yes, I hope that one day my S-PPU emulation
is as great as blargg's S-DSP emulation. I'll personally consider that
99.9% as good (accurate) as SNES emulation can get, at least at the
conceptual level.
As for Sidmania, I believe
henke37 is correct, though it may also be related to
render_scanline_position, too. Almost all of the PD ROMs were developed
using copiers. Almost all of these copiers reset all WRAM to 0x00 on
power on, and most PD ROMs do not. I can't say if the Tototek flash
cart does, but it sounds like it does not.
On a real SNES, we don't really know what the default value is. Every
time someone reads the data, they get different results. Meaning that,
to me, the data is random, or has to do with something related to
electrical engineering.
I chose to act like most other SNES emulators and initialize the RAM to
0x55. The reason is because there are multiple official games that do
not initialize RAM (and variables that they use in it) which cause many
games to fail. These games include "Death Brade", "RPM Racing" and
"Super Power Drive". 0x55 is a "lucky" variable that nothing seems to
complain about. It's also a nice pattern of alternating
010101010101010101 ....
But, when I made this change, somewhere around v0.016 or so, it did in
fact break a lot of demos. "Goodbye, Anthrox" is a great example of
that.
You may want to verify this in an emulator like Super Sleuth. It
detects invalid checksums as PD ROMs, and initializes their WRAM to
0x00. I'd bet this game works fine there.
The reason I won't use a random value for WRAM init, or set WRAM to
0x00 on power on for PD ROMs, is because of one major design rule of
bsnes: I wanted the exact same behavior to occur consistently on every
run of bsnes. That means that input A always, always returns output B.
The above two would violate that rule. I don't consider either a hack
though. This is also why I've not even considered trying to emulate
blargg's S-SMP timer glitch: it has percentages of probability.
Quote: |
There
are definitely things you could do to help yourself, though. You just
need some marketing tactics. I'll bet if you released a bSNES 1.52 next
week, you'd double your userbase overnight. See how the capital letters
stand out more? See how 1.52 is higher than 1.51? I don't think you
know how right I am on this |
Hah. You know, I really like seeing v0.023, and thinking to myself,
"there's been exactly 23 official versions thus far," ignoring that I
released daily WIPs until v0.(0.)004, of course.
I do see myself as exceeding 100 releases (let's hope), and I consider
v1.0 to be a version number that depicts perfection. I don't think
perfection is obtainable in an emulator, so I consider a version 1.0
something of a logical fallacy for an emulator. You're free to disagree
with me on that, though. Since perfection is obviously unobtainable
anyway, I guess a v1.0 doesn't really matter all that much.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Sep 29, 2007 10:40 am Post subject: |
|
byuu wrote: |
On
a real SNES, we don't really know what the default value is. Every time
someone reads the data, they get different results. Meaning that, to
me, the data is random, or has to do with something related to
electrical engineering. |
I read an interesting story on Slashdot a while ago about using the initial state of RAM on powerup as a cheap source of randomness,
and also a way of "finger-printing" particular chips: power up the RAM
a number of times, and record which bits are more likely to be 1 at
power-up, and which bits are more likely to be 0.
So assuming the SNES uses ordinary SRAM chips, the 'default' state would be randomness.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Sep 29, 2007 11:31 am Post subject: |
|
byuu wrote: |
Quote: |
There
are definitely things you could do to help yourself, though. You just
need some marketing tactics. I'll bet if you released a bSNES 1.52 next
week, you'd double your userbase overnight. See how the capital letters
stand out more? See how 1.52 is higher than 1.51? I don't think you
know how right I am on this |
Hah. You know, I really like seeing v0.023, and thinking to myself,
"there's been exactly 23 official versions thus far," ignoring that I
released daily WIPs until v0.(0.)004, of course.
I do see myself as exceeding 100 releases (let's hope), and I consider
v1.0 to be a version number that depicts perfection. I don't think
perfection is obtainable in an emulator, so I consider a version 1.0
something of a logical fallacy for an emulator. You're free to disagree
with me on that, though. Since perfection is obviously unobtainable
anyway, I guess a v1.0 doesn't really matter all that much.
|
Well, the version "v" is a bit misleading. You could use the notation "bsnes R23", for example.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Sep 29, 2007 2:05 pm Post subject: |
|
I found a VERY interesting document about the SNES, that I feel that you just MUST see.
Link -> Google patents about the SFX chip <- Link
This, if anything, should be enough for somebody to write a clean enough SFX core, right?
This means that bsnes might eventually support Yoshi's Island and StarFox. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Sep 29, 2007 5:33 pm Post subject: |
|
byuu wrote: |
Hah. You know, I really like seeing v0.023, and thinking to myself,
"there's been exactly 23 official versions thus far," ignoring that I
released daily WIPs until v0.(0.)004, of course.
I do see myself as exceeding 100 releases (let's hope), and I consider
v1.0 to be a version number that depicts perfection. I don't think
perfection is obtainable in an emulator, so I consider a version 1.0
something of a logical fallacy for an emulator. You're free to disagree
with me on that, though. Since perfection is obviously unobtainable
anyway, I guess a v1.0 doesn't really matter all that much. |
Hehe, now I can't even decide if I was joking or being insightful with
that. I guess it depends on how impressionable you think people are.
The version number probably doesn't matter. I wonder, though, how
coincidental it is that SNES9x and ZSNES are both at 1.51. Kind of
reminds me of the Me2 episode of Red Dwarf where the Rimmers keep
sitting in front of each other in the cinema.
I do think that bSNES would help, if only because SNES is usually
capitalized (being an acronym and all) and would be more instantly
recognizable to people. Big ass capital letters also tend to jump out
more. Glance at the above paragraph and I'll bet they're the first
things you focus on.
Still, I know how you feel about tradition, but it's got to be the easiest thing you could try.
Quote: |
I found a VERY interesting document about the SNES, that I feel that you just MUST see.
Link -> Google patents about the SFX chip <- Link
This, if anything, should be enough for somebody to write a clean enough SFX core, right?
This means that bsnes might eventually support Yoshi's Island and StarFox. |
Oh, but aren't we forgetting about the "game which sucks because there's no gun on the hood," which is possible now. 
Last edited by FitzRoy on Sat Sep 29, 2007 7:43 pm; edited 2 times in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Sep 29, 2007 5:35 pm Post subject: |
|
Quote: |
The
reason I won't use a random value for WRAM init, or set WRAM to 0x00 on
power on for PD ROMs, is because of one major design rule of bsnes: I
wanted the exact same behavior to occur consistently on every run of
bsnes. That means that input A always, always returns output B. The
above two would violate that rule. I don't consider either a hack
though. This is also why I've not even considered trying to emulate
blargg's S-SMP timer glitch: it has percentages of probability. |
If you used a pseudo-random number generator that you re-seed with the
same value at power-up, you'd get repeatability without having to use a
simplistic pattern.
Quote: |
[...]
using the initial state of RAM on powerup as a cheap source of
randomness, and also a way of "finger-printing" particular chips: power
up the RAM a number of times, and record which bits are more likely to
be 1 at power-up, and which bits are more likely to be 0. |
This is certainly the case for the SRAM chips in the SPC-700 of my
SNES. The low 32K chip has one general pattern at power up, the upper
32K another (they're made by different companies).
henke37, patent documents don't necessarily match behavior of the
hardware (same goes for developer documentation). Programmers work with
what the hardware actually does, so that's the only truely reliable
source of information for an emulator. Patents are good as a start for
hardware research, though.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Sep 29, 2007 5:58 pm Post subject: |
|
Yes, patents does not say what reality is.
But they are very close, this one even got precise timing charts for the signals. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Sep 29, 2007 6:00 pm Post subject: |
|
There is a reason why manual errata exists. You're falling into the same hole.
_________________
FF4 research never ends for me. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Sep 29, 2007 6:02 pm Post subject: |
|
byuu wrote: |
I chose to act like most other SNES emulators and initialize the RAM to
0x55. The reason is because there are multiple official games that do
not initialize RAM (and variables that they use in it) which cause many
games to fail. These games include "Death Brade", "RPM Racing" and
"Super Power Drive". 0x55 is a "lucky" variable that nothing seems to
complain about. It's also a nice pattern of alternating
010101010101010101 ....
|
If all else fails, couldn't you just include an advanced option (cfg or
otherwise) to let the user decide which value they want to set it to?
Doesn't Nestopia have something like that? Or maybe it was another
emu...
OR an option to let the user decide if he wants to have a random
initial RAM value or always initialize RAM to 0x55...
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Sep 29, 2007 6:12 pm Post subject: |
|
henke37 wrote: |
bsnes might eventually support Yoshi's Island and StarFox. |
Great, another CPU to sync to... 
Some patents are known (1, 2, 3), but they can only help a bit.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Sep 29, 2007 6:14 pm Post subject: |
|
wouldn't it take like a super computer to run anyways though? at least at bsnes standards (aka no corner cutting)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Sep 29, 2007 6:19 pm Post subject: |
|
Panzer88 wrote: |
wouldn't it take like a super computer to run anyways though? at least at bsnes standards (aka no corner cutting) |
Too slow to play would still be better than no SFX chip emulation I
suppose...Plus it could be the ultimate raw CPU power benchmark! i.e:
user1: "My super-ultra cooler mega overcloacked core2 gets 3fps in Starfox...
everyone: "Whoa...*Resp3ct*
This aside I'm just speculating and I know byuu currently has no
intention to start working on these chips, which is perfectly
understandable if he is to work on the new dot-based renderer (which
ultimately is much more important imo)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Sep 29, 2007 6:48 pm Post subject: |
|
Snark wrote: |
Panzer88 wrote: |
wouldn't it take like a super computer to run anyways though? at least at bsnes standards (aka no corner cutting) |
Too slow to play would still be better than no SFX chip emulation I
suppose...Plus it could be the ultimate raw CPU power benchmark! i.e:
user1: "My super-ultra cooler mega overcloacked core2 gets 3fps in Starfox...
everyone: "Whoa...*Resp3ct*
This aside I'm just speculating and I know byuu currently has no
intention to start working on these chips, which is perfectly
understandable if he is to work on the new dot-based renderer (which
ultimately is much more important imo)
|
you sold me 
but yeah, one step at a time, it'll already take awhile to get the dot-based renderer I'm sure.
but here I am talking for byuu **runs away**
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Sep 29, 2007 6:51 pm Post subject: |
|
Who said he can't do both at the same time? |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Sep 29, 2007 7:03 pm Post subject: |
|
Snark wrote: |
buzz. Wrong. byuu needs to change the name to bNES...Now THAT is teh 3lite...Just like that other emulator...what's the name again...oh yeah, Z NES |
"Byuu Nintendo Entertainment System" tm 
P.S. byuu, an opcode version of the core sounds like a good idea.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Sep 29, 2007 11:50 pm Post subject: |
|
Finally
converted the config_file object from a non-local static object used
across multiple translation units (whew) to a local static one inside a
function. Neat little trick, now I can be sure the config items will
never be called before the config_file object has been created. It
worked before because I was lucky.
Quote: |
Oh, but aren't we forgetting about the "game which sucks because there's no gun on the hood," which is possible now. |
If I could get decent documentation, I could add support for it.
Quote: |
If
you used a pseudo-random number generator that you re-seed with the
same value at power-up, you'd get repeatability without having to use a
simplistic pattern. |
A very
good point. And I know just the PRNG algorithm to use. I'll give it a
try. I don't suppose you have a test ROM to verify if the behavior is
emulated "mostly" correctly or not?
Quote: |
This
aside I'm just speculating and I know byuu currently has no intention
to start working on these chips, which is perfectly understandable if
he is to work on the new dot-based renderer (which ultimately is much
more important imo) |
The biggest problem is redesigning the processor scheduler to
accomodate another processor. I sidestep that with all of the other
coprocessors, because they have no emulation of timing. I can't do this
for the SA-1 or SuperFX.
Quote: |
P.S. byuu, an opcode version of the core sounds like a good idea. |
The funny part is that what bsnes has now is kind of skewed. Because of
the cothreads, I can literally execute thousands of opcodes in a row
without switching to the other processor at all. But the second one
tries to talk to the other, they can instantly switch back and forth as
needed.
An opcode core would gain its speed by emulating the S-SMP as an opcode
core, and enslaving the S-SMP to it. And then further enslaving the
S-DSP to the S-SMP, and the S-PPU to the S-CPU.
I imagine it'd be about twice as fast, with probably about 20 or so broken games. But the code would be vastly
different from what I have now, and I couldn't easily keep both in the
same source tree. Need to plan that out a lot more first.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 30, 2007 3:17 am Post subject: |
|
You
guys have been really awesome lately (as well as always), and it's been
a while since I did anything really interesting, so ...
I sat down today and added in support for a new game. Rather than just
say what it is, I thought it'd be more entertaining to just post the
binary alone and see who can figure out which game now works that
didn't before :)
And before anyone bothers asking, no I didn't add SuperFX or SA-1 support :P |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Sep 30, 2007 3:43 am Post subject: |
|
byuu wrote: |
You
guys have been really awesome lately (as well as always), and it's been
a while since I did anything really interesting, so ...
I sat down today and added in support for a new game. Rather than just
say what it is, I thought it'd be more entertaining to just post the
binary alone and see who can figure out which game now works that
didn't before 
And before anyone bothers asking, no I didn't add SuperFX or SA-1 support  |
Well let's see...These are the only chips that are only used in one game:
DSP-2
DSP-3
DSP-4
OBC1
ST010
ST011
ST018
S-RTC
DSPs-X are pretty much out of the question, considering how complex
they are (I assume they're basically as complex as the DSP-1 and all
the same save for a few differences?)
OBC1 is Metal Combat: Falcon's Revenge. I don't know how compex that
chip is, but since that would also require Super Scope support that's
less likely.
That leaves either one of the Seta chips (ST01x) or S-RTC in Dai Kaiju Monogatari 2
So I'll guess and say B: S-RTC Dai Kaiju Monogatari 2 final answer.
edit: Oh crap, Dai Kaiju Monogatari 2's S-RTC is already supported isn't it? Well, that leaves one of the Seta chips...Although two of them are used in friggin' Shogi games (Which brings the question why the hell would one need a special chip in a Shogi game anyway?)
Last edited by Snark on Sun Sep 30, 2007 6:25 am; edited 1 time in total
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Sep 30, 2007 3:58 am Post subject: |
|
oh, I didn't realize that it would break games but come to think of it that should have prolly been obvious.
as for the game. Lets see, you already support the entire regular SNES
game library (right?) so that means it must be some kind of special
chip (I think). You've already ruled out SFX and SA-1
Snark wrote: |
OBC1
is Metal Combat: Falcon's Revenge. I don't know how compex that chip
is, but since that would also require Super Scope support that's less
likely.
|
Metal Combat: Falcon's Revenge already boots, sure you can't play it (no super scope support *cough* *cough*
) but as far as I can tell the audio and video all check out and if you
let attract mode play you can see that the battle graphics are fine
also (at least as far as I can see). the DSP-2 chip is also supported
right? (at least Dungeon Master boots fine for me and doesn't seem to
display garbage, of course it was only supposed to be used for scaling
and transparencies so maybe I am missing that, still, I doubt that this
is the game)
you already support DSP-1, DSP-2,
S-DD1, Cx4, and OBC1 so it's probably not one of those, or Sufami Turbo
which you've also done.
my guesses are
SD Gundam GX on DSP-3
Top Gear 3000 on DSP-4
F1 ROC II: Race of Champions on ST010
Hayazashi Nidan Morita Shougi on ST011
Nidan Morita Shougi 2 on ST018
I doubt this, but it could be the SPC7110 chip which would include
- Far East of Eden Zero
- Far East of Eden Zero: Shounen Jump no Shou
- Momotarou Densetsu Happy
- Super Power League 4
Do you support S-RTC (is Daikaijuu Monogatari 2 fully functional)? and
has SameGame always worked? (also Undake 30 - Same Game, and Same Game
+ Tengai Makyou Zero Jikei)
for kicks this stuff is insignificant in my search now but there is also
MegaChips MX15001TFC - used in storage cartridges
Satellaview - actually has a lot of games load, has problems with games
relying on live broadcast and other features unique to the accessory.
Super Gameboy 1 & 2 - bios boots fine but no way to load GB games (duh)
are BS-X, Same Game, Sufami Turbo, and SD Gundam G-Next the only SNES
games that use a bios? I know there are many other bios files like
Action Replay, Game Doctor, Game Genie, XBAND Modem, Super 8, Tristar
etc. but do any licensed games REQUIRE ones other than those listed
above to boot?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 30, 2007 9:38 am Post subject: |
|
Ah,
it is F1 ROC II / Exhaust Heat II. Thanks, byuu. It may seem like only
one game, but every new chip you support also lessens the perception
that your emulator is less "featureful." In that way, it is time well
spent. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Sep 30, 2007 9:51 am Post subject: |
|
FitzRoy wrote: |
It
may seem like only one game, but every new chip you support also
lessens the perception that your emulator is less "featureful." In that
way, it is time well spent. |
You couldn't be more close to how many people feel, even if you tried.
Each extra chip supported is worth the time.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 30, 2007 2:55 pm Post subject: |
|
Yep, ST010 support. Should benefit F-Zero fans who love mode7 race tracks.
I really can't take any credit for it, though. All but one opcode, one
table, and one bug was taken from Overload's DSP page. The rest from
SNES9x.
If I had to actually research the trigonometric functions of that DSP,
I wouldn't have stood a chance. I could've gotten maybe half of the
eight functions figured out with two weeks of research, and only then
if I had a hardware rig to probe that chip (I don't.)
I should warn everyone though, just because the code is in bsnes
doesn't make it any more accurate than it is in ZSNES and SNES9x. It's
the same emulation, and it looks as though half of the opcodes are not
bit perfect. op05 looks ... interesting, and op04 relies on sqrt with a
double, which seems like overkill precision compared to what an SNES
era DSP would have. But overall, it works great, and there's absolutely
no reason to downplay the difficulty Overload, Matthew Kendora and
Feather had deciphering this chip. Many thanks to them. I was kind of
unintentionally rude about op06 not being perfect on the DSP-1 last
time, which I greatly regret.
It's nice that we can all share code like this -- I share base system
findings, and borrow special chip findings. It would be torture to have
to reinvent the wheel with all of these special chips. The only ones I
could have done myself so far were the S-RTC and OBC1.
Anyway, that puts us up to:
Supported (in roughly decreasing order of complexity):
- DSP-1
- Cx4
- S-DD1
- ST010
- DSP-2
- S-RTC
- OBC1
Not supported (no idea which are more complex):
- SuperFX
- SA-1
- SPC7110
- ST011
- ST018
- DSP-3
- DSP-4
- BS-X (not really a 'chip', per se)
- SameGame (also kind of different)
Now, the bad news. The ST010 looks like the last easy chip to add.
The DSP-3 and DSP-4 look like the only other doable targets. SuperFX
and SA-1, I'm not going to repeat myself. SPC7110 lacks a key
decompression algorithm and I despise graphics packs, ST011 is an utter
waste of time and the ST018 is an even greater waste of time and is
vastly more complex. Plus it's not been emulated elsewhere yet for me
to copy, and without a system to test on, that makes it pretty near
impossible to support. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Sep 30, 2007 7:05 pm Post subject: |
|
Many thanks for the ST010 support, byuu 
Quote: |
ST011 is an utter waste of time and the ST018 is an even greater waste of time |
Damn!!! I wanted to play those Shougi games! Seriously, I still wonder
what they needed those chips for... A.I perhaps 
Last edited by Snark on Sun Sep 30, 2007 7:19 pm; edited 1 time in total
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Sep 30, 2007 7:12 pm Post subject: |
|
well that may be a dead end for chips for awhile, but there is always special input support 
seriously though, this is great news, and bsnes seems to be keeping very busy lately.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 30, 2007 8:13 pm Post subject: |
|
Quote: |
Damn!!! I wanted to play those Shougi games! |
You speak Japanese?
I tried out SD Gundam GX ... ugh, that is a terrible game as well. It's
just a board game with the most horribly dull graphics I have seen in a
long time. Looks like it could easily be an NES game.
Looks like Top Gear 3000 is the only moderately fun one left.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Sep 30, 2007 9:19 pm Post subject: |
|
byuu wrote: |
Quote: |
Damn!!! I wanted to play those Shougi games! |
You speak Japanese?
|
Watashi Ha Yoku...Janai...err...Nihongo... de? hanasemasen... desu. Or something like that...
Seriously, I don't speak a word of Japanese, as you can see lol. I read
Japanese at a...oh...I would say first grade, maybe second grade
level,max. Kanji comprehension: maybe third grade. Enough to play
something like Chrono Trigger without having to look up Kanjis all the
time. Overall: pretty weak, but I'm slowly getting there.
And with the help of this great DS software:
http://www.play-asia.com/paOS-13-71-9g-49-en-70-198v.html
I can read well enough (stress: well enough) most games and Japanese books/newspapers etc...albeit in an extremely slow manner.
Quote: |
I
tried out SD Gundam GX ... ugh, that is a terrible game as well. It's
just a board game with the most horribly dull graphics I have seen in a
long time. Looks like it could easily be an NES game. |
Well, to be honest I've never played a single Gundam game. If anyone
knows (regardless of platform) of a good one, I might try it.
edit: surely there's a few good ones in all of them...
http://en.wikipedia.org/wiki/List_of_Gundam_video_games
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Sep 30, 2007 9:41 pm Post subject: |
|
byuu wrote: |
Looks like Top Gear 3000 is the only moderately fun one left. |
yeah, but I don't get what makes it need that chip, and how is it
superior? a lot of those chips leave that impression (like other one's
you've mentioned), that is, what can these chips do that a normal SNES
can't do? (not all of them but some of them)
EDIT: good gundam game = Gundam Wing: Endless Duel
if you like fighting games you might like it Snark, and Gideon has even translated it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 30, 2007 10:43 pm Post subject: |
|
I've
finally added ideal_height values to all of the controls in libui. I
need to come up with a better name and implementation style, but for
now this should work. They're also all constant. Not really a good
idea, but I can extend that later without breaking stuff.
So, for the most part, unless you try changing the default fonts, the
controls should look good on both Windows and Linux now. It's actually
a bit weird looking at the Windows one now -- I've grown used to the
ridiculously large controls there.
I also finally added [vEX]'s idle sleep patch. I verified CPU usage is at 0% when idle on Linux now.
Overall, I think I have a lot done. I think if I fix the ./ issue,
that'll be enough for an interim release. The fullscreen video stuff is
a long way away, anyway. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 30, 2007 11:20 pm Post subject: |
|
Panzer88 wrote: |
byuu wrote: |
Looks like Top Gear 3000 is the only moderately fun one left. |
yeah, but I don't get what makes it need that chip, and how is it
superior? a lot of those chips leave that impression (like other one's
you've mentioned), that is, what can these chips do that a normal SNES
can't do? (not all of them but some of them)
|
Sometimes it's just for copy protection. Very effective, but costly.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 01, 2007 12:04 am Post subject: |
|
Eh,
what the hell. Ten additional games can be played that couldn't be in
the last release, plus there's an important bugfix. And I'm not sure
how long the fullscreen support will take to add, but I won't be able
to release once I start on that until it's finished, so ...
byuu.org wrote: |
2007-09-30 - bsnes v0.024 released
This is an interim release between some major changes to the video mode
support, which may take a long time to complete. It also fixes a bug
with CGRAM access timing, re-adds the Sufami Turbo load menu, and adds
support for the ST-010 coprocessor, used by F1 Race of Champions.
To load Sufami Turbo cartridges, stbios.bin must be placed inside a
folder named bios in the bsnes folder. There is not currently a warning
if this file is missing.
Changelog:
* Improved CGRAM access timing restrictions, fixes a bug in WWF Super WrestleMania
* Re-added Sufami Turbo menu to load ST and ST dual cartridges
* Added support for the ST-010 coprocessor, used by F1 Race of Champions II
* Improved libui to automatically adjust control sizes based on platform, vastly improves Windows UI
* Fixed relative paths in config file for Windows port
* bsnes no longer consumes 100% CPU time when idle on Linux port, thanks [vEX]
* Fixed config file object to not rely on undefined C++ language behavior, thanks Nach |
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Oct 01, 2007 12:20 am Post subject: |
|
nice, now when i force it to use a single core it doesn't use 100% also, forcing it to use a single core yields in smoother frame rates.
_________________
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. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 02, 2007 12:52 am Post subject: |
|
byuu wrote: |
This is an interim release between some major changes to the video mode
support, which may take a long time to complete. It also fixes a bug
with CGRAM access timing, re-adds the Sufami Turbo load menu, and adds
support for the ST-010 coprocessor, used by F1 Race of Champions.
To load Sufami Turbo cartridges, stbios.bin must be placed inside a
folder named bios in the bsnes folder. There is not currently a warning
if this file is missing. |
Sufami Turbo support works perfectly. Very easy and intuitive. Thanks for the 0.024 version.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 03, 2007 2:48 am Post subject: |
|
You guys might like this update. It's almost certainly the first and last time you'll ever see anything like it.
http://byuu.cinnamonpirate.com/?page=bsnes_news
And just to ruin the surprise, because I'm a dick like that ...


Of course, there's a new private beta up for testing. Expect bugs in
both games, as the special chip emulation is still incomplete. Better
than before at least, right?
Quote: |
Sufami Turbo support works perfectly. |
Thank you for confirming it works okay. While you're at it, please be
sure to check out Poi Poi Ninja World if you haven't already.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Oct 03, 2007 3:09 am Post subject: |
|
Quote: |
Lastly,
the chip I want to support more than any other, the SPC7110, has a
compression algorithm in it that has not been cracked. Using graphics
packs goes strongly against my philosophies regarding emulation, and
since I lack adequate hardware for testing (not to mention skill to
reverse engineer the algorithm anyway), that won't be happening, either. |
This confuses me. If there is compressed data whose compression-format
is not known, how was the data uncompressed to make the graphics pack?
Or does the graphics pack just contain dummy data in order to get the
game to run?
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Oct 03, 2007 3:13 am Post subject: |
|
Sweet deal. Now there will be just a couple fewer people bitching that you don't support a certain special chip.
How's reading that C++ book going? Have you made any of your code more
"standard"? And will that bring any (direct) speed benefits, or just
code readability and bug-squashing?
I can't wait to start hearing your progress on the PPU. You'll be
breaking into a whole new realm of emulation, n'est-ce pas?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Oct 03, 2007 3:21 am Post subject: |
|
Thristian wrote: |
Quote: |
Lastly,
the chip I want to support more than any other, the SPC7110, has a
compression algorithm in it that has not been cracked. Using graphics
packs goes strongly against my philosophies regarding emulation, and
since I lack adequate hardware for testing (not to mention skill to
reverse engineer the algorithm anyway), that won't be happening, either. |
This confuses me. If there is compressed data whose compression-format
is not known, how was the data uncompressed to make the graphics pack?
Or does the graphics pack just contain dummy data in order to get the
game to run?
|
i believe the graphics packs are derived from a port of the games to other systems.
_________________
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.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Wed Oct 03, 2007 4:07 am Post subject: |
|
franpa wrote: |
Thristian wrote: |
Quote: |
Lastly,
the chip I want to support more than any other, the SPC7110, has a
compression algorithm in it that has not been cracked. Using graphics
packs goes strongly against my philosophies regarding emulation, and
since I lack adequate hardware for testing (not to mention skill to
reverse engineer the algorithm anyway), that won't be happening, either. |
This confuses me. If there is compressed data whose compression-format
is not known, how was the data uncompressed to make the graphics pack?
Or does the graphics pack just contain dummy data in order to get the
game to run?
|
i believe the graphics packs are derived from a port of the games to other systems.
|

Wrong. From what I know, after some initial reverse engineering of the
SPC7110 games by Dark Force, Dejap managed to dump and release to the
web huge, unoptimised packs years ago. This was trimmed down to almost
100% optimisation with the help of graphics loggers built into
ZSNES/Snes9x. In the end, Caitsith2 managed to reverse engineer the
games and produce 100% trimmed packs.
Some old threads about the SPC7110 are preserved on Caitsith2's site:
http://www.caitsith2.com/snes/flashcart/page4.htm
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Oct 03, 2007 4:57 am Post subject: |
|
franpa wrote: |
Thristian wrote: |
Quote: |
Lastly,
the chip I want to support more than any other, the SPC7110, has a
compression algorithm in it that has not been cracked. Using graphics
packs goes strongly against my philosophies regarding emulation, and
since I lack adequate hardware for testing (not to mention skill to
reverse engineer the algorithm anyway), that won't be happening, either. |
This confuses me. If there is compressed data whose compression-format
is not known, how was the data uncompressed to make the graphics pack?
Or does the graphics pack just contain dummy data in order to get the
game to run?
|
i believe the graphics packs are derived from a port of the games to other systems.
|
Given
that as of right now, there ARE NO PORTS TO OTHER SYSTEMS AVAILABLE....
I'd recommend doing basic research before posting whatever random
hypothesis you've pulled out of your ass.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Oct 03, 2007 5:05 am Post subject: |
|
byuu wrote: |
You guys might like this update. It's almost certainly the first and last time you'll ever see anything like it.
http://byuu.cinnamonpirate.com/?page=bsnes_news
And just to ruin the surprise, because I'm a dick like that ...
Of course, there's a new private beta up for testing. Expect bugs in
both games, as the special chip emulation is still incomplete. Better
than before at least, right? |
Three special chips in one week, now that's indeed something we don't see everyday :D
byuu on his homepage wrote: |
So
basically what I'm getting at here is, don't expect support for any new
special chips anytime soon. In fact, don't expect that at all. |
I'm cool with that and who knows, maybe some talented programmer/REer/
will come forth and help in the future with those chips.
Quote: |
Quote: |
Sufami Turbo support works perfectly. |
Thank you for confirming it works okay. While you're at it, please be
sure to check out Poi Poi Ninja World if you haven't already.
|
No problem or bugs detected, least none that I could find. I didn't
test extensively I should admit as the game well...it sorta sucks imo
(though maybe I just don't get it) It plays like a poor's man Bomberman
or something.
Any reason this particular game might cause problems?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 03, 2007 5:41 am Post subject: |
|
Awesome! Thanks for adding these.
It's strange that all that research just seemed to stop. That was
what... five years ago that they were studying the SPC7110? Was their
only goal to make the game playable? Who on earth is going to RE this
stuff now that Overload, etc, are all gone?  |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 03, 2007 6:05 am Post subject: |
|
holy crap! one thing after another, what's left anways? a few chips, and then input emulation right?
I mean what else is there?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Oct 03, 2007 1:56 pm Post subject: |
|
Maybe if we can combine everything we know, on each of the special chips into one document+ pictures.
then try to make a list of missing information we might be able to get more help.
Like maybe some chips could be better emulated if they were decapped?
maybe the algorythm can be solved with the help of mame/mess
(escpecially if the chip is used in more systems)
I bet there are enough people willing to donate carts and or money
towards such a goal. The same goes for hardware accurate emulation of
things like the multi-tab, lightgun and mouse |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Oct 03, 2007 3:01 pm Post subject: |
|
I hate to tell you guys this, but maybe the manufacturer can help?
If you ask nicely, I don't see why they wouldn't give you the specs for the chip.
Last edited by henke37 on Wed Oct 03, 2007 6:06 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 03, 2007 3:18 pm Post subject: |
|
I
should mention, DSP-3/SD Gundam GX supposedly freezes when the red
player starts his turn. And I've seen a tiny bit of flickering with
DSP-4/Top Gear 3000 in split screen mode. But the latter seems fully
playable at least. It looks like a timing issue, but since we emulate
these chips as registers rather than as separate processors,
computations always occur instantly, so timing is going to be way off
no matter what I do.
Also, by using SNES9x's
code directly, that binds binary releases to SNES9x's licensing
conditions. It's essentially ISC compatible with the exception that it
is a non-commercial only license. That's fine by me for now, my license
also restricts commercial use. I happen to strongly agree with the
SNES9x team that money should never be made off of emulation. But
whenever I do eventually release my source as PD or whatever, those
restrictions will be a lot more important.
Quote: |
It's
strange that all that research just seemed to stop. That was what...
five years ago that they were studying the SPC7110? Was their only goal
to make the game playable? Who on earth is going to RE this stuff now
that Overload, etc, are all gone? |
I've wondered the same thing myself. It seems SNES development just
stopped on May 2004 when the old SNES9x forums shut down. It seems
people are still working on some of these things in private, but at a
much slower pace.
And yes, when you're talking about a chip that is only used by 1-3
games, often playability is the only concern. But that's a lot more
than I would have done, especially for the really awful games like SD
Gundam GX. So they're definitely all worth commending for their efforts.
Hell, if not for them, bsnes would only have S-RTC emulation right now, and nothing else.
Quote: |
I mean what else is there? |
SA-1, SuperFX, SPC7110, ST011 and ST018. Then there's the supplementary
hardware, BS-X, SGB and SameGame. Then there's inputs, Multi-tap,
mouse, Super Scope and Justifier. Then features, savestates and speed
being most important. Though I'll never get close to finishing even
half of that, I'd bet such an emulator could rival even ZSNES :P
Quote: |
I bet there are enough people willing to donate carts and or money towards such a goal. |
If I could get a Super Wildcard DX2 or something like what Overload
had, I could try and help out with the SPC7110 by running my own tests
on it. Problem now is that my UFO8 can't probe the cartridges directly
from custom software, so I can't really do anything at the moment.
But even if I had the hardware, I could never crack that compression algorithm.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Oct 03, 2007 3:48 pm Post subject: Mystic Ark not working and questions to byuu |
|
Heya byuu,
Thanks for your extensive reply to the sidmania problem the other day,
I was racking my brain as to how could your wonderful emulator not run
them properly, so now it makes much more sense why you have done what
you have done to get other official games to work.
Now I know how strange the whole initial memory state thing is, with
you having to set it to the "lucky" number 0x55 instead of 0x00 so the
official game roms do not complain I was wondering:
1) Have you tried every different hex code from 0x00 to 0xFF, to see if
any of them will please everything, PD and official roms?
(If not I would be happy to check every single one for you if you gave
me a list of problem roms that reqire 0x55, and a build of bsnes with a
hex digit in the config that I could change easily to test.)
2) Could you put the hex memory initialisation digit in the config file
anyway in case there is no number to satisfy all different
circumstances as Snark suggested in an earlier post?
The only reason I am asking this is because it would be a great shame
to lose the ability to see these demos on your great emulator, and I
have some spare time on my hands so it would be great to help out with
your project =D
One more thing I just tried out "Mystic Ark - 7th Saga 2 (J).smc" by enix, with bsnes 0.24, but it did not boot, so you might want to check that out.
To end on a plus note thank you very much for your Der Langrisser english translation patch, I heavily recommend everyone in here to try it out (if they have not allready!)
I am playing it on my snes now =D
p.s I love your work getting those extra chips emulated in such a short time!! |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Oct 03, 2007 4:13 pm Post subject: |
|
Mystic
Ark is very often found in an interleaved form. Use NSRT to
deinterleave for your own good. I don't believe BSNES does any sort of
deinterleaving thus why it fails to work. It works fine when
deinterleaved.
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 03, 2007 4:23 pm Post subject: |
|
byuu wrote: |
I happen to strongly agree with the SNES9x team that money should never be made off of emulation.
|
Any particular reason for this? I respect your personal decision not
to, but I don't see why you would want to hold others to it. I see
nothing wrong with someone accepting compensation for their time and
labor. For some, it is a hobby, and for others, it is time that they
could not warrant spending if not for compensation. The reason that I
bring this up is that I have often considered putting a bounty on
things not directly related to you, like special chip emulation for
example. I agree with you that the game should be emulated properly
without graphics packs - in all emulators. In the case of the SPC7110,
you may not even be capable of doing it. Maybe nobody is. But what
would be wrong with offering a monetary prize for cracking the
compression? For one old game that's already playable, I don't see any
other way of inciting this research. None.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Oct 03, 2007 4:51 pm Post subject: |
|
franpa wrote: |
Thristian wrote: |
Quote: |
Lastly,
the chip I want to support more than any other, the SPC7110, has a
compression algorithm in it that has not been cracked. Using graphics
packs goes strongly against my philosophies regarding emulation, and
since I lack adequate hardware for testing (not to mention skill to
reverse engineer the algorithm anyway), that won't be happening, either. |
This confuses me. If there is compressed data whose compression-format
is not known, how was the data uncompressed to make the graphics pack?
Or does the graphics pack just contain dummy data in order to get the
game to run?
|
i believe the graphics packs are derived from a port of the games to other systems.
|
Just stop guessing.
FitzRoy wrote: |
byuu wrote: |
I happen to strongly agree with the SNES9x team that money should never be made off of emulation.
|
Any particular reason for this? I respect your personal decision not
to, but I don't see why you would want to hold others to it. I see
nothing wrong with someone accepting compensation for their time and
labor. For some, it is a hobby, and for others, it is time that they
could not warrant spending if not for compensation. The reason that I
bring this up is that I have often considered putting a bounty on
things not directly related to you, like special chip emulation for
example. I agree with you that the game should be emulated properly
without graphics packs - in all emulators. In the case of the SPC7110,
you may not even be capable of doing it. Maybe nobody is. But what
would be wrong with offering a monetary prize for cracking the
compression? For one old game that's already playable, I don't see any
other way of inciting this research. None.
|
I don't think byuu was speaking of generous donations, but it has more
to do with hampering emulation efforts. As much as a person would like
"insert specific game" emulated (due to popularity), holding money for
something like this will in turn become more like "an emu for $$$"...
think Bleem for a moment here and how that turned out.
On the SPC7110, I'd say it is simply an issue of not enough research
being done. It is also relative to the popularity of said games that
holds the process up (I mean, considing SDD-1 has SFA2 and SO, both
games have popularity on their side). When you consider the special
chip games and the popularity and impact they had on people, you can
see the desire by people that have the ability to do something allow
research to progress further. I wouldn't ever count it out ever.. just
hope someone cares enough to do something about it (I don't mean emu
authors, I mean people who have the skills, access, and desire).
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 03, 2007 5:50 pm Post subject: |
|
Quote: |
2)
Could you put the hex memory initialisation digit in the config file
anyway in case there is no number to satisfy all different
circumstances as Snark suggested in an earlier post? |
Yeah, sure. Why not? I'll add one to initialize memory via PRNG, too.
Would be good for verifying broken by design games.
Quote: |
I don't believe BSNES does any sort of deinterleaving thus why it fails to work. |
Nope -- I realize I'm in the minority here so my opinions don't really
matter, but I happen to greatly dislike interleaving and believe
supporting it only encourages its proliferation.
I'd honestly like to do the same to ROM headers, but I suspect I'd lose 95+% of the few supporters I have now.
Thank you for verifying the game works on your end.
Quote: |
Any
particular reason for this? I respect your personal decision not to,
but I don't see why you would want to hold others to it. I see nothing
wrong with someone accepting compensation for their time and labor. |
Well, I personally don't want any money for my efforts. I'd like to pay
people for hardware resources that I desperately need, though.
I don't really have that much of a problem if someone else wants to say
"for X$, figure out Y" -- so long as they do that and donate the code
as PD, so that everyone can benefit. I still don't like that idea
though, hence I wouldn't be participating for money myself.
But the bsnes and SNES9x licenses are basically saying "don't sell this
software", and I think that's totally fair. I'm not charging for the
software, so why should I allow others to charge for it? If someone
wants my software, they should be able to get it for free. I would even
take offense to my software being offered on a Linux CD in a store for
$49.95. You want to sell something? Sell your own software.
As far as what people do with the software they write, well, that's their business. Whether or not to allow them to combine that with our
software depends on your personal philosophy of what freedom is. That
stupid rant on my website goes over that one. I don't have an answer of
which is better at this time.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 03, 2007 6:44 pm Post subject: |
|
I
see what you're saying. If a program has other contributors, then it
seems wrong to accept money when it is not 100% a result of your own
time and research. I think the special chip bounties are a good idea,
though, provided that the work is verifiable as correct and that it is
made public domain for all to use.
Last edited by FitzRoy on Wed Oct 03, 2007 7:30 pm; edited 1 time in total |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Oct 03, 2007 7:27 pm Post subject: Interleaved roms |
|
Thanks byuu
for another quick reply, and cheers for thinking about adding those
memory options to bsnes I truly think it will be an improvement to an
allready great program =D
Sorry for not knowing
about interleaved roms in bsnes, I will make sure that I check a roms
format with a tool, making sure it is not interleaved, before posting a
bug report in the future. I am glad you do not support interleaved roms
because it is quite a yucky format!
Also cheers to Deathlike2 for spotting the problem with the Mystic Ark rom, and helping to not waste byuu's time...
Keep up the great work  |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Oct 03, 2007 8:29 pm Post subject: |
|
FitzRoy wrote: |
Awesome! Thanks for adding these.
It's strange that all that research just seemed to stop. That was
what... five years ago that they were studying the SPC7110? Was their
only goal to make the game playable? Who on earth is going to RE this
stuff now that Overload, etc, are all gone?  |
Like always in the emulation scene the invariable answer is: whoever
(if anyone) happen to have the interest and know-how to work on the
project. It's randomness really..
I know Andreas Naive worked on the S-DD1 and he and Aaron cracked (or
RE? whichever is more correct) CPS2 recently. So maybe in a distant
future who knows.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 04, 2007 12:17 am Post subject: |
|
byuu wrote: |
I'd honestly like to do the same to ROM headers, but I suspect I'd lose 95+% of the few supporters I have now. |
you really think that would turn people off? as long as you have NSRT
you can remove a header so it's not like you couldn't play your games,
you just might have to take some time to get rid of the roms you have
that do have headers.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Thu Oct 04, 2007 1:13 am Post subject: |
|
Panzer88 wrote: |
byuu wrote: |
I'd honestly like to do the same to ROM headers, but I suspect I'd lose 95+% of the few supporters I have now. |
you really think that would turn people off? as long as you have NSRT
you can remove a header so it's not like you couldn't play your games,
you just might have to take some time to get rid of the roms you have
that do have headers.
|
People who use certain SNES copiers. People who use SNES copiers are also much more likely to know about bsnes.
_________________

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

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 04, 2007 1:50 am Post subject: |
|
Clements wrote: |
Panzer88 wrote: |
byuu wrote: |
I'd honestly like to do the same to ROM headers, but I suspect I'd lose 95+% of the few supporters I have now. |
you really think that would turn people off? as long as you have NSRT
you can remove a header so it's not like you couldn't play your games,
you just might have to take some time to get rid of the roms you have
that do have headers.
|
People who use certain SNES copiers. People who use SNES copiers are
also much more likely to know about bsnes.
|
BIGGEST STUPID MOMENT EVER **runs away in shame**
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 04, 2007 1:56 am Post subject: |
|
I
have a device which requires a header as well as the file name to be
.smc, and I am ardently in favor of emulators having absolutely nothing
to do with either one. I actually wish that emulators were more
hard-line about this. The SNES extension issue needs to simplified to
SFC-only for sure. What do we have? 6, 7 different accepted extensions
for SNES roms? Yeah, it's totally worth having 7 copier extensions
floating around so that the .1% of people who interchange between a
copier and emulator won't have the UNTHINKABLE inconvenience of keeping
two sets of roms... worst tradeoff ever. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Oct 04, 2007 2:24 am Post subject: |
|
byuu wrote: |
Well,
I personally don't want any money for my efforts. I'd like to pay
people for hardware resources that I desperately need, though. |
Put up a donation link so users can directly fund additional hardware for you to do research on.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 04, 2007 3:09 am Post subject: |
|
I
understand that having headers is needed for most copier devices. The
thing there is, there's at least a dozen incompatible header formats.
Aside from a few newer copiers that can read multiple header formats,
that means that most ROMs out there with headers are useless to those
who have copiers. And only maybe 0.1% of users even have copiers.
And if you do have a copier, you have to load them one at a time
anyway. Why not use a simple script to attach a header, rename it to
.smc, and copy it to your floppy disks in chunks? This is what I do for
my UFO8. End to end, much easier for everyone.
But anyway, I realize I'm in the minority here so don't worry about it.
Headers aren't going anywhere. As with the special chips I've added,
I'm trying to make bsnes into what most people want, rather than solely
what I want. With the exception of making it fast, heh.
The only reason I'd personally want to keep headers though would be if
we were to store PCB info in them, to eliminate the need for a
database. But I'd honestly prefer a footer for that.
Quote: |
Put up a donation link so users can directly fund additional hardware for you to do research on. |
Well, cost really isn't an issue for me. I suppose if it were for
something like decapping the S-DSP, I'd be cool with that. Hell, I'd
donate money and hardware myself for that.
---
EDIT: Neat! Check this out: http://bbs.emu618.com/thread-37641-1-1.html
bsnes in simplified Chinese :D
Man, I do need to hurry up with the UTF-8 support, so I can add a
language.cfg file. Should make life a lot easier.
I bet the guy who made that hates me. Heh, I dont use resource forms at all, so he must have had to patch every single string by hand ...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 04, 2007 5:29 am Post subject: |
|
byuu wrote: |
The only reason I'd personally want to keep headers though would be if
we were to store PCB info in them, to eliminate the need for a
database. But I'd honestly prefer a footer for that.
|
Don't make me break down in a youtube video...
"Leave... the data... alone... YOU LEAVE IT ALONE!"
Ghost Chaser Densei FTW?
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 04, 2007 6:07 am Post subject: |
|
there
are enough emus ot the pot. I think bsnes' strict standards are what
make it unique. Just be sure you stay true to your goal in making it,
if that means less ease of use for the end user, I mean there are
always other emus, and with each year more people get systems that are
closer to running it smoother, so keep up the good work.
not like it's a huge issue, but I don't think people would freak out
too much without header support. I mean you can always add or remove
headers, it's not the end of the world.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 04, 2007 6:10 am Post subject: |
|
byuu wrote: |
bsnes in simplified Chinese 
Man, I do need to hurry up with the UTF-8 support, so I can add a
language.cfg file. Should make life a lot easier.
I bet the guy who made that hates me. Heh, I dont use resource forms at all, so he must have had to patch every single string by hand ... |
Nah, he likely just used an automatic tool to find and replace all
"strings", I belive that GNU got one, was it called gettext?
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Oct 04, 2007 6:25 am Post subject: |
|
henke37 wrote: |
byuu wrote: |
I bet the guy who made that hates me. Heh, I dont use resource forms at all, so he must have had to patch every single string by hand ... |
Nah, he likely just used an automatic tool to find and replace all
"strings", I belive that GNU got one, was it called gettext?
|
Gettext makes it easy to add new translations, but you need to design
your application to use it from the start - you can't take somebody
else's app and sprinkle gettext-dust on it, at least without having
access to the source and potentially spending a lot of time re-writing
things to be gettext-friendly.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 04, 2007 8:07 am Post subject: |
|
Panzer88 wrote: |
there
are enough emus ot the pot. I think bsnes' strict standards are what
make it unique. Just be sure you stay true to your goal in making it,
if that means less ease of use for the end user.. |
*nods*
This bit particularly
Quote: |
I
decided it would be best to simply encapsulate the SNES9x code for
these two chips inside a namespace and write an interface between it
and bsnes. |
strike me as straying away from bsnes' "original path".
byuu (on page1) wrote: |
We won't get anywhere by cutting and pasting misc. emulators together. |
*(see edit):
And considering the two chips in question and the games (all two of
them) are extremely marginal...I personally don't believe it's worth
it. I don't think people care that much for TG3000.
So, perhaps a vote "all for, all against" maybe? Note: even if byuu
choose to keep them (at least in their "copy pasted snes9x code form)
I'm still gonna support bsnes of course. It's not that big of a deal,
just something I believe would be better off bsnes for the moment.
Again, just my opinion.
*edit: and yes, I realise there's a difference between a core SNES
component and an EXTERNAL chip, which is why I don't believe it's a big
deal, yet I still think it's not worth it for one game (one and a half
if you count Gundam GX)
Quote: |
Typically,
for special chip support, I manually rewrite all of the code by hand. I
like the code to fit my style, and more importantly, I like to port the
code to C++. |
Of course I'm not the one who will do all the work here, but perhaps
the extra work is worth it to keep bsnes more "true".
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Oct 04, 2007 12:21 pm Post subject: |
|
Snark wrote: |
And
considering the two chips in question and the games (all two of them)
are extremely marginal...I personally don't believe it's worth it. I
don't think people care that much for TG3000. |
If you actually seen the ZSNES board before the DSP-4 support, you
would think differently, even though I don't see why this game is
special at all.
_________________
FF4 research never ends for me.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 04, 2007 2:38 pm Post subject: |
|
Top
Gear 3000 is actually a rather good game. It's got a nice soundtrack
and gets quite challenging later on. It also has 4-player split screen,
which I think is the only racing game on the system to do that. It's no
RNRR, but it's fun.
Special chips and crazy
add-ons are the nature of many cartridge-based systems. Let's not keep
lamenting the fact that some coprocessor games aren't the best of the
best. Some people are fonder of games they used to own, and nothing
could be less fun than a blank screen. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Oct 04, 2007 2:46 pm Post subject: |
|
Well, the other part to its popularity is notable since there was a board filter for that game's name.
_________________
FF4 research never ends for me. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 04, 2007 3:16 pm Post subject: |
|
henke37,
if you want to ask Epson for technical docs, feel free. Let me know if
you get anything. I consider winning the lottery more likely, but
you're welcome to try if you like.
Quote: |
So, perhaps a vote "all for, all against" maybe? |
Sure, why not? If the majority is in favor of removing any
special chips, I'll do so. It'll make licensing easier for me anyway.
Or if preferred, I can make them all a compile-time option. I honestly
only want S-RTC myself, because Dai Kaijuu II rules. But I'll take them
all out if that's what people want.
I do want to
ask if you're familiar with C++, though. Not to be rude, but it would
make my explanations of what I'm doing kind of hard to follow if you
aren't.
I don't like C because it pollutes the global namespace. Encapsulating
a C file inside a custom namespace is a neat trick to avoid that. But
it isn't object oriented. I could also stick the whole thing into a
class, and move all the global initializations into the constructor,
but that's not really any better and it just makes it much harder to
copy over future improvements to these two chips. It's not like the
DSP-1 where we already have bit-perfect emulation.
Honestly, I agree with Deathlike. There's nothing special about TG3k to
me, and I'm not about to spend six weeks porting a DSP whose code is
twice the size of even the DSP-1 just to get one game playable. So
either we use SNES9x' code, or I can take it out. Either way is fine by
me. I added them because everyone seems so happy whenever I add special
chips.
And again, I don't mean to downplay the amazing work everyone put into
getting these games playable. Their preservation is clearly very
important, and reverse engineering even the worst of the worst games
like Morita Shougi II have meaning in that regard. I'm meaning more
that the games are already emulated elsewhere, I don't have any means
to actually help improve the emulation (all I'm doing is copying other
peoples' code here -- something I despise doing), and I have very
different goals anyway -- I want to preserve hardware, not the software
that runs on it. Nothing wrong with either approach, either.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Oct 04, 2007 4:01 pm Post subject: |
|
FitzRoy wrote: |
Top
Gear 3000 is actually a rather good game. It's got a nice soundtrack
and gets quite challenging later on. It also has 4-player split screen,
which I think is the only racing game on the system to do that. |
Street Racer
_________________
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 Oct 04, 2007 4:30 pm Post subject: |
|
byuu wrote: |
I'm meaning more that the games are already emulated elsewhere, I don't have any means to actually help improve the emulation |
Sure you do. Do these games run entirely on the special chip? No. And
your sound core and cpu core are superior to all other emulators. Thus,
the same special chip code in your emulator results in superior
emulation and a superior gaming experience. Emulator arsenals are also
loathsome to me. 1 big AYE to special chip support and licensed device
support, no matter where the code comes from.
byuu wrote: |
I'm not about to spend six weeks porting a DSP whose code is twice the
size of even the DSP-1 just to get one game playable. |
This is part of what I was talking about. There are going to be things
that you may not want to spend time fixing or emulating based on your
perceived worth of said game or device. If you accepted compensation,
maybe people could pay you for the trouble and get something they want
in return. Then you can even use that money to fund research you care
about. It's a win-win.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 04, 2007 5:07 pm Post subject: |
|
byuu wrote: |
henke37, if you want to ask Epson for technical docs, feel free. Let me
know if you get anything. I consider winning the lottery more likely,
but you're welcome to try if you like.
Quote: |
So, perhaps a vote "all for, all against" maybe? |
Sure, why not? If the majority is in favor of removing any
special chips, I'll do so. It'll make licensing easier for me anyway.
Or if preferred, I can make them all a compile-time option. I honestly
only want S-RTC myself, because Dai Kaijuu II rules. But I'll take them
all out if that's what people want.
I do
want to ask if you're familiar with C++, though. Not to be rude, but it
would make my explanations of what I'm doing kind of hard to follow if
you aren't.
I don't like C because it pollutes the global namespace. Encapsulating
a C file inside a custom namespace is a neat trick to avoid that. But
it isn't object oriented. I could also stick the whole thing into a
class, and move all the global initializations into the constructor,
but that's not really any better and it just makes it much harder to
copy over future improvements to these two chips. It's not like the
DSP-1 where we already have bit-perfect emulation.
|
Well, I'm only in favor of removing DSP-3 and DSP-4 and for the sole
reason the code was directly borrowed from Snes9x. And no, I'm not
familiar with C or C++. I seriously underestimated the ammount of
time/work it would take to port the code I guess.
Quote: |
Honestly,
I agree with Deathlike. There's nothing special about TG3k to me, and
I'm not about to spend six weeks porting a DSP whose code is twice the
size of even the DSP-1 just to get one game playable. So either we use
SNES9x' code, or I can take it out. Either way is fine by me. I added
them because everyone seems so happy whenever I add special chips. |
And perhaps like Deathlike said I also understimated the popularity of
TG3k...If it were only me I would just remove it, by no mean was I
expecting you to work for a month+ just for two chips that supports one
game each.
Meh, if most people are in favor of keeping them, then I suppose I'm in favor too.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 04, 2007 5:44 pm Post subject: |
|
Quote: |
This
is part of what I was talking about. There are going to be things that
you may not want to spend time fixing or emulating based on your
perceived worth of said game or device. If you accepted compensation,
maybe people could pay you for the trouble and get something they want
in return. Then you can even use that money to fund research you care
about. It's a win-win. |
Well, I know it's difficult to understand (and to explain), but I
really don't want money. And if I do things I don't want to do for
money, then this becomes a job. And I already have a great paying job
that I hate very much.
Quote: |
And no, I'm not familiar with C or C++. |
That's what I was getting at, I probably came off too harsh at first. I
don't like the idea of using C code in a C++ program, but you know ...
the namespace encapsulation is really just a problem to me, not a
technical one. Overall, it works fine, and thanks to the namespace
wrapper it won't interfere with anything else. My wrapper interface to
it is C++ like all the other chips, so all of the code outside of
src/chip/dsp[34] is identical either way.
And of course, I do dislike the idea of cutting and pasting emulators
together, you're right. But special chips are probably a good
compromise. And it's not like I'm actually doing anything useful with
my rewrites anyway. And like FitzRoy pointed out, it's another point of
comparison to see if a flaw in the emulation is due to the special chip
code, timing or the base SNES emulation itself.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Oct 04, 2007 9:16 pm Post subject: |
|
I
say leave the special chips in. It's not like they're degrading bsnes'
accuracy in any way, since bsnes' goal is emulation of the base SNES
hardware. They're just addons and, due to the namespace encapsulation
don't pollute the code to any appreciable degree. Not to mention that
they potentially bring with them an increase in userbase and more games
to test - although bug reports from them may be less valuable due to
the inaccuracy of the special chip emulation, who knows what might come
up. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 04, 2007 9:56 pm Post subject: |
|
yeah, i find myself nuetral on the situation, as there are pros and cons on both sides so I really can't say either way.
I guess a question I would have is how accurate or inaccurate IS the
emulation of these special chips? or more specifically do they take
shortcuts or do they follow the same general pattern of base bsnes
(which is why it's a slower emu)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 04, 2007 10:34 pm Post subject: |
|
Quote: |
I guess a question I would have is how accurate or inaccurate IS the emulation of these special chips? |
I went over this before, but I'll recap for interested parties.
Those who worked on these chips were aiming for bit perfect outputs for
each opcode. They succeeded for DSP-1/2, but not yet for DSP-3/4,
ST-010/011/018 or Cx4. It's a lot of work with little reward,
obviously. If you ever take a look at the math for some of these, it's
mind bogglingly complex trig and calculus stuff.
Emulation is very close, though. It appears DSP-4 is fully playable,
but has a few small issues here and there. DSP-3 though does not look
as good, the game supposedly locks up when the computer tries to move.
Still, what we have is better than nothing.
Anyway, even with DSP-1/2, the chips are emulated as sort of like
instant calculation registers. You store your inputs, and read the
calculation results instantly. Whereas with real hardware, they're
actual processors that take time to compute each result. We cheat by
clearing the busy flag immediately. Emulating timing requirements would
be far, far more complex (even the same opcodes could take differing
times to complete based on inputs), and it would make DSP-1 emulation
many times slower than it is now. And let's not even get into what
happens if you try and read inputs before the calculations are finished
...
In effect, this causes special chip games to run way faster than they
would on real hardware. To give a made up example, a hobbyist developer
might try using DSP-7 in his demo game, and he might think that he can
calculate ~10,000,000 square roots a second, because emulators will let
him do that. But when he moves it to hardware, his game will crawl, pushing out only ~50,000 square roots per second.
This also makes fixing bugs in special chips near impossible for me. If
it's a problem with the special chip code itself, I won't understand
how to fix it. If it's a problem with timing, it could either be in my
base emulation or because we don't emulate special chip delays.
But the bottom line is this: special chip emulation does not affect
emulation of the base system for any other games. Either you get
imperfect emulation of special chip games, or no emulation at all.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Oct 04, 2007 11:48 pm Post subject: |
|
I
vote that byuu does exactly what he wants. I think byuu's own interest
in his project is more important to the long-term success of bsnes than
the userbase's desires.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Oct 05, 2007 12:04 am Post subject: |
|
Jipcy wrote: |
I
vote that byuu does exactly what he wants. I think byuu's own interest
in his project is more important to the long-term success of bsnes than
the userbase's desires. |
My sentiment as well. Then again, byuu said he wanted to add those chips because of the userbase's desires for special chips support...so, that's a bit of a conundrum lol
Last edited by Snark on Fri Oct 05, 2007 3:51 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 05, 2007 2:35 am Post subject: |
|
Quote: |
And I already have a great paying job that I hate very much.
|
Haha. I know how you feel... well, except for the high-paying part. :/
btw, I know you've gone over SA1 and SuperFX many times, but I failed
to catch why it wasn't also possible to encapsulate these from SNES9x.
Are they not written in C?
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Oct 05, 2007 3:49 am Post subject: |
|
Deathlike2 wrote: |
Well, the other part to its popularity is notable since there was a board filter for that game's name. |
Yeah,
but that was only added because people wouldn't quit going on about it
like it was the only reason anyone would ever want to play a Super
Nintendo.
When by most counts it was a mediocre game at best.
...
And it didn't have a gun. Seriously, why play a racing game with no gun?
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Oct 05, 2007 4:03 am Post subject: |
|
Gil_Hamilton wrote: |
Deathlike2 wrote: |
Well, the other part to its popularity is notable since there was a board filter for that game's name. |
Yeah,
but that was only added because people wouldn't quit going on about it
like it was the only reason anyone would ever want to play a Super
Nintendo.
When by most counts it was a mediocre game at best.
...
And it didn't have a gun. Seriously, why play a racing game with no gun?
|
I think people often want support for something because,well because
it's not supported...And when it's finally supported, they're like "Ah
cool. Now I want support for *name of the other game that's not
supported*...Simple as that really. Those familiar with M.A.M.E
probably knows the phenomena.
That's one of the reason I'm more excited about advancement of base hardware accuracy.
FitzRoy wrote: |
btw,
I know you've gone over SA1 and SuperFX many times, but I failed to
catch why it wasn't also possible to encapsulate these from SNES9x. Are
they not written in C? |
Noooo..... >_<
That would be even worse, as those chips are even less accurately emulated from what I gather.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 05, 2007 4:28 am Post subject: |
|
Snark wrote: |
Noooo..... >_<
That would be even worse, as those chips are even less accurately emulated from what I gather. |
Worse? How can it be worse than nothing? This stuff has absolutely
nothing to do with bsnes' base code. All it does is allow people to
play more games with better core and sound emulation than other
emulators. Their only INTENTIONAL inaccuracies, from what I understand,
were to make the games reach 60fps on modern hardware... almost the
same reasoning behind bsnes' scanline renderer. There is already code
in bsnes that byuu has not written himself. Enough thinking that this
somehow sullies bsnes or compromises its purpose.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Oct 05, 2007 4:58 am Post subject: |
|
FitzRoy wrote: |
btw,
I know you've gone over SA1 and SuperFX many times, but I failed to
catch why it wasn't also possible to encapsulate these from SNES9x. Are
they not written in C? |
byuu mentioned above that these latest chips he's added work like
'instant calculation registers' - when the game writes the correct
inputs to the correct addresses, the emulator immediately calculates
the output so the game can read it when it's ready. The SA1 and SuperFX
cores in SNES9x are presumably more complicated and emulate the delays
those chips would have on real hardware, so bsnes can't "cheat" and
pretend that they're instant.
As I understand it, bsnes currently has an intricate dance between the
CPU, SPU and PPU cores so that they can all see each other's correct
'state' at any given point in time. Any new cores that have timing
concerns (such as the SNES9x SA1 and SuperFX cores) would have to be
added to this "dance" so that their results become available at the
right time. I can think of two problems this might cause: firstly, SA1
and SuperFX have not been reverse-engineered to the level of detail
that the CPU, SPU and PPU have and so figuring out exactly where in the
dance the SA1 and SuperFX should go could be difficult; secondly, the
dance is complicated enough with three cores who are always present -
keeping things neat and tidy with extra cores that might or might not
be around sounds like horror.
byuu: did I get that anything near right, or should I just hush in future? :)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Oct 05, 2007 5:44 am Post subject: |
|
byuu wrote: |
To
give a made up example, a hobbyist developer might try using DSP-7 in
his demo game, and he might think that he can calculate ~10,000,000
square roots a second, because emulators will let him do that. But when
he moves it to hardware, his game will crawl, pushing out only ~50,000 square roots per second. |
interesting, and this helps me understand the even greater importance
of true to hardware accuracy because then when you are developing a
homebrew SNES game you can use bsnes now and in the future to tell if
it'll run on a real SNES. That's cool because you have all the some
technical constraints as developers back then and it'd be neat to see
how far people can push the "real" (read: accurate) SNES hardware.
Snark wrote: |
Jipcy wrote: |
I
vote that byuu does exactly what he wants. I think byuu's own interest
in his project is more important to the long-term success of bsnes than
the userbase's desires. |
My sentiment as well.
|
I was planning on saying this too, but forgot. It's your time, effort,
and life, I think most of us will support you either way byuu.
Snark wrote: |
I think people often want support for something because,well because
it's not supported...And when it's finally supported, they're like "Ah
cool. Now I want support for *name of the other game that's not
supported*...Simple as that really. Those familiar with M.A.M.E
probably knows the phenomena.
That's one of the reason I'm more excited about advancement of base hardware accuracy. |
yeah, although sometimes there actually is a game that isn't supported
that you actually WANT to play. That's more with mame though, SNES is
pretty much all supported more or less in some state.
I am also excited about the advancement of base hardware accuracy.
FitzRoy wrote: |
Snark wrote: |
Noooo..... >_<
That would be even worse, as those chips are even less accurately emulated from what I gather. |
Worse? How can it be worse than nothing?
|
I think he meant it would be worse than the other chips that have
recently been added, as they are fairly accurate, where as the SA-1 and
SFX would be less accurate.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Oct 05, 2007 6:30 am Post subject: |
|
Partial support is better then no support.
We can always come back and replace it with something better when we want to.
And for the SuperFX, did anyone read that patent and compare to what is
currently known? I mean, it does have these fancy timing charts.
Byuu, I've been thinking about that sound buffer issue you've talked about.
You say that since you get an irregular amount of samples each frame, the smoothing is thrown of.
This is due to the desync until needed timing method, right?
There is a simple solution, use a buffer and read from the buffer at a
constant speed. I mean, you are pretty much guaranteed that the buffer
shouldn't run out since it is restocked with the averenge speed that
it's read from. Of course there is the case when the cpu stops talking
with the spu, but that plain doesn't happen often enough. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Oct 05, 2007 6:48 am Post subject: |
|
Gil_Hamilton wrote: |
Deathlike2 wrote: |
Well, the other part to its popularity is notable since there was a board filter for that game's name. |
Yeah,
but that was only added because people wouldn't quit going on about it
like it was the only reason anyone would ever want to play a Super
Nintendo.
When by most counts it was a mediocre game at best.
...
|
Well, it is idiocy at its finest. There are so many good games that
don't use a special chip, and are classics. That's why I can never take
people too seriously when they make their argument to "support this
game" or "support this chip"... because such reasoning is generally
faulty.
Quote: |
And it didn't have a gun. Seriously, why play a racing game with no gun? |
Hahahaahaha.
_________________
FF4 research never ends for me.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Oct 05, 2007 8:35 am Post subject: |
|
Jipcy wrote: |
I
vote that byuu does exactly what he wants. I think byuu's own interest
in his project is more important to the long-term success of bsnes than
the userbase's desires. |
I disagree. I think from now on, byuu should just do what I want. Sound good? Okay.
...
um...
Make a... Genesis emulator?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 05, 2007 5:19 pm Post subject: |
|
Quote: |
btw,
I know you've gone over SA1 and SuperFX many times, but I failed to
catch why it wasn't also possible to encapsulate these from SNES9x. Are
they not written in C? |
Quote: |
byuu: did I get that anything near right, or should I just hush in future? :) |
Yes, Thristian has it 99% right. Very impressive :)
With the DSP-3/4, I only had to hook three functions. InitDSPN(),
DSPNGetByte() and DSPNSetByte(). I write my own memory mapping and
interface binding code.
With the SuperFX and SA-1, they are dedicated processors. And at least
the SA-1 shares a lot of stuff with the base system: WRAM, MMIO access,
IRQ handling, etc. It would honestly be easier to write the whole thing
myself than try and rig SNES9x' code into bsnes.
I would also have to sacrifice speed even in ordinary games to support
an additional processor. Right now, the scheduler that invokes the four
main processors is all inlined and specific. Adding another special
chip would require a) making another function with that chip and
turning the function itself into a function pointer (no more inlining)
or b) using a conditional variable in one of the most heavily called
functions in the entire emuator (not pretty).
And lastly, you guys really aren't understanding the sheer performance magnitude here. We're talking maybe 2fps, tops. Nobody is going to play it, and if any bugs are found, without savestates it will be a nightmare to try and fix bugs with. "Play five minutes in Marvelous and talk to the monkey to see the bug" turns into 2 1/2 hours per
run where I try and fix a bug. For reference, the semi-recent Lemmings
2 bug took me about 50 test runs to track down the bug and fix it.
It's nice to say "yeah well speed doesn't matter", but at the end of
the day you have to at least get 10% speed if you ever hope to test and
fix bugs with it. How many of you would bug test 40+ games that ran as
fast as that circuit-level pong emulator that gets <1fps on a 3GHz
processor?
And the worst part is, the system requirements of a cycle-accurate PPU
are roughly identical to the requirements SA-1 support would add. This
is why I'm so hesitant to start on that.
Unless I come up with a magical way to make that fast, despite years of
planning turning up nothing, or successfully fork the emulator into two
parts yet still be part of the same program, it's quite literally the
death of bsnes to start on it.
Quote: |
There is already code in bsnes that byuu has not written himself. |
Well again, I only care about the base hardware. CPU, SMP, PPU and DSP.
The rest, I don't mind using other peoples' code. Licensing issues is
the only reason I don't use more.
And yes, that means eventually I'd like to try my hand at the DSP, as
I've said before. Not that blargg's work isn't impeccable, I just would
like to be able to say that I've emulated the entire base system myself.
Quote: |
um...
Make a... Genesis emulator? |
Funny you should mention that. I actually would like to emulate some
other systems. You know, just for fun. Problem is I have no interest in
getting the emulation perfect there, and I think it would give people
false expectations of accuracy if I tried. But it would be nice, it
would help abstract the SNES code to a library-like state, which I need
to do if I want to support both a fast and accurate version of that
anyway.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Oct 05, 2007 6:17 pm Post subject: |
|
byuu wrote: |
Funny you should mention that. I actually would like to emulate some
other systems. You know, just for fun. Problem is I have no interest in
getting the emulation perfect there, and I think it would give people
false expectations of accuracy if I tried. But it would be nice, it
would help abstract the SNES code to a library-like state, which I need
to do if I want to support both a fast and accurate version of that
anyway. |
That was a very surprising and interesting response. What systems have
you thought about working on, even just as a random idea? You've done
really good work with bsnes, and it sounds like you're helping out a
lot with the Mother 3 translation, I'd be very interested in any new
ventures you might decide to do.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 05, 2007 6:30 pm Post subject: |
|
Very good explanation. Thank you. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Oct 05, 2007 6:37 pm Post subject: |
|
so..... where were we before all this special chip discussion?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Baron_Samedi New Member
Joined: 25 Sep 2007
Posts: 4
Location: Germany
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 05, 2007 9:10 pm Post subject: |
|
Quote: |
so..... where were we before all this special chip discussion? |
I'm looking to restructure the codebase to start prepping for some sort
of split-bsnes mode where I have the "fast enough for modern computers"
version, and the "ohmygod whythefuck does an SNES emulator require a
200GHz computar!? It'slikeit'slikeit'slike 2MHz!! It should only need
2Mhz*(super_magic_constant)=~150MHz tops!!!!11eleven lim(x->0)
sin(x) / x"
Here's the current code structure of bsnes:
http://i73.photobucket.com/albums/i221/byuusan/current.png
If I can get enough time, I'll post my planned restructuring later
tonight. Otherwise expect it sometime this weekend.
Quote: |
What systems have you thought about working on, even just as a random idea? |
NES, Gameboy/Color, Genesis/Sega CD, and especially Saturn.
I also worked on this for a bit.
Quote: |
it sounds like you're helping out a lot with the Mother 3 translation |
Not really, I'd like to be. I just came up with an idea to implement
the 8-bit script routine, and added it. Game bugs made that not very
useful. I've been wanting to write a GBA assembler like xkas to help
out, but I've been extremely apathetic to work on that. I'm easily the
least useful member on that team. Sorry to disappoint, but the GBA
simply is not my specialty.
Quote: |
3 games (WWF Super WrestleMania, F1 ROC II - Race of Champions, Poi Poi Ninja World) were promoted to :D |
Excellent, thank you very much for updating the test :)
Now I need to nag you to add Top Gear 3000 next (and possibly SD Gundam
GX, but I'm pretty sure that doesn't fully work yet.)
Kind of a shame I still lose the overall :D count as there are many
SuperFX and SA-1 games in the list, but what can I do, right? (besides
support the chips, heh)
|
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Oct 05, 2007 9:46 pm Post subject: |
|
byuu wrote: |
NES, Gameboy/Color, Genesis/Sega CD, and especially Saturn.
I also worked on this for a bit.
|
What constitutes "a bit"? Either way, that's pretty badass. Would you
want to make a whole new emulator, or would you be interested in
helping out another project?
EDIT: Don't sell yourself short on the GBA. At the very, very least,
that's a fucking experience to be part of a team like that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 05, 2007 10:29 pm Post subject: |
|
Damn, the design I wanted doesn't seem to be possible in C++ ...
Code: |
struct SNES {
struct CPU {
SNES &snes;
CPU(SNES &r_snes) : snes(r_snes) {}
} cpu;
SNES() : cpu(*this) {}
}; |
I'd like to put all of the components (CPU, SMP, PPU, DSP) inside of
the SNES class, and then give those classes references to the parent
class. I realize SNES::CPU::CPU() would be called before SNES::SNES(),
but that should be fine so long as I don't try and touch variables
inside SNES::SNES() there.
I also don't like the idea of turning 'class SNES' into a namespace, as
that lacks a consistent access interface and everything in it is
public. But I really need some way of keeping the namespace entries
down to a minimum. Ideally, there should only be one SNES class that is
visible. CPU, SMP, etc should not be visible unless accessed through
the SNES class.
I also want to bind all of them together, so that it's possible to have
multiple instances of the emulator running at the same time (read: no
singletons, please), but I don't want to have any pointers anywhere, so
that inlining is possible everywhere.
Making 'class SNES' a template class is out. That would make every
single member function declaration a pain in the ass.
Ideas?
Quote: |
Would you want to make a whole new emulator, or would you be interested in helping out another project? |
Honestly? If I work on anything, I'd prefer to work alone. I work better that way ...
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Oct 05, 2007 10:41 pm Post subject: |
|
byuu wrote: |
Damn, the design I wanted doesn't seem to be possible in C++ ...
[...]
I'd like to put all of the components (CPU, SMP, PPU, DSP) inside of
the SNES class, and then give those classes references to the parent
class. |
Heh, this sounds familiar.
Do you really need the reference to the parent class, or is it just a convenient shortcut?
Afaik OOP says that the "inner" objects should have no knowledge about the "outer" objects.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 05, 2007 11:01 pm Post subject: |
|
Quote: |
Heh, this sounds familiar. |
It sounds familiar because it's the exact same problem I solved for
functions with cooperative multithreading. But now I have to solve it
for objects, too.
Quote: |
Do you really need the reference to the parent class, or is it just a convenient shortcut? |
Well, it solves my problem very nicely when A can know about B, and B
can know about A. But C++ doesn't like that design paradigm at all.
Here's what I've come up with so far:
Code: |
struct SNES {
struct Core;
struct CPU;
struct SMP;
struct Core {
CPU &cpu;
SMP &smp;
Core(CPU &r_cpu, SMP &r_smp) : cpu(r_cpu), smp(r_smp) { printf("SNES::Core\n"); }
} core;
struct CPU {
Core &core;
SMP &smp;
CPU(Core &r_core, SMP &r_smp) : core(r_core), smp(r_smp) { printf("SNES::CPU\n"); }
} cpu;
struct SMP {
Core &core;
CPU &cpu;
SMP(Core &r_core, CPU &r_cpu) : core(r_core), cpu(r_cpu) { printf("SNES::SMP\n"); }
} smp;
SNES() : core(cpu, smp), cpu(core, smp), smp(core, cpu) { printf("SNES\n"); }
}; |
The idea would be that I could add all the objects I want, and then
simply link together the ones that absolutely need to be.
Now I need to split this into four object files and see if the beast still compiles.
Quote: |
Afaik OOP says that the "inner" objects should have no knowledge about the "outer" objects. |
I really think that's backwards, personally. By doing things this way,
it makes encapsulation a breeze. Now, you only need one actual object
to create and manage all of the sub objects.
And if this were Java, I could add "inherits Serializable" and add
instant savestate support to the non-cothread version :P
The alternative is to create five separate objects, and then either a)
bind them together with pointers, taking a massive speed hit, or b) use
global object handles, thus making multiple instances impossible.
Again, this is all because C++ absolutely hates the concept of bidirectional communication.
A can call and access B, and B can call and access C, but B cannot
access A at all, and C can't access neither B nor A.
But with an emulator, this design falls flat on its face. All of the different components of the SNES talk with each other and don't adhere to the OOP design paradigm.
More and more, I feel C++ is a terrible language for writing an
emulator in, but I really don't have an alternative. And please don't
suggest any, I've researched languages for the last ten years. Even if
there is a superior language, it's too obscure to be useful.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Oct 05, 2007 11:32 pm Post subject: |
|
edit
Last edited by Snark on Sat Oct 06, 2007 12:27 am; edited 5 times in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Oct 05, 2007 11:45 pm Post subject: |
|
byuu,
I'm a bit confused. Your first example compiles fine for me and so does
the second one even when I modify it to resemble the first. What's the
problem here? (sorry I can't do any real testing, should be in bed
already) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 05, 2007 11:57 pm Post subject: |
|
Passing this in an initializer list throws the below warning:
Code: |
warning C4355: 'this' : used in base member initializer list |
I could disable the warning, but I don't know if that's a good idea. I
suppose if what I'm doing is valid C++, then I'll do it anyway and say
the hell with Visual C++.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Oct 06, 2007 12:08 am Post subject: |
|
For the record, MinGW GCC 3.4.5 w/ -Wall gives me no warnings. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 06, 2007 12:42 am Post subject: |
|
byuu wrote: |
Quote: |
so..... where were we before all this special chip discussion? |
I'm looking to restructure the codebase to start prepping for some sort
of split-bsnes mode where I have the "fast enough for modern computers"
version, and the "ohmygod whythefuc does an SNES emulator require a
200GHz computar!? It'slikeit'slikeit'slike 2MHz!! It should only need
2Mhz*(super_magic_constant)=~150MHz tops!!!!11eleven lim(x->0)
sin(x) / x"
|
sweet Unreasonably slow and accurate bsnes FTW! 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Oct 06, 2007 1:46 am Post subject: |
|
Quote: |
Passing this in an initializer list throws the below warning:
Code: |
warning C4355: 'this' : used in base member initializer list |
I could disable the warning, but I don't know if that's a good idea. I
suppose if what I'm doing is valid C++, then I'll do it anyway and say
the hell with Visual C++.
|
If such code were strictly invalid, the C++ standard would require a
diagnostic. Apparently the "always enable warnings!!!!" crowd has upset
your judgment. Warnings are an optional tool that you can use in
situations where they add value. This warning is saying that the callee
must know that it has a reference to an uninitialized object.
OK, so your overall goal is to have a group of objects which each
communicate with the others. In any language, what you want is for each
to have references to the others it sends messages to,
and for these to be set up when the objects are created. C++ supports
this just fine, so I don't understand your claims that it makes it so
hard. What more could it do? Even if you had some way of saying that
the CPU and PPU communicate both directions, it'd still need to know which CPU and PPU objects are communicating.
I also don't understand why you want to nest all the classes in
another. This makes the design more tightly coupled, since this master
class must have declarations for all the nested classes. With a
namespace, each class could be declared in a separate file, since
namespaces can be built up incrementally.
Code: |
// CPU.h
namespace bsnes
{
class Core;
class SMP;
class CPU {
Core& core;
SMP& smp;
public:
CPU( Core&, SMP& );
...
};
}
// bsnes.h
#include "CPU.h"
#include "Core.h"
#include "SMP.h"
...
namespace bsnes
{
class SNES {
CPU cpu;
Core core;
SMP smp;
...
public:
SNES() : cpu( core, smp ) ...
...
};
} |
At a cost of increased coupling, you could have each object keep only a
pointer to SNES, which has all the other objects in it. This opens the
way to an obscure way of avoiding the object pointers entirely. Here's
the concept distilled:
Code: |
// X.h
struct X { int x };
// Y.h
struct Y { int y };
// Both.h
struct Both : X, Y { };
template<class T>
inline Both& both( T& t ) { return static_cast<Both&> (t); } // downcast
// user.cpp
void func( Y& y )
{
// Given just a Y reference, we can get a reference to Both, which
// gives us X
X& x = both(y);
x.x = 1234;
// Other more concise ways of the same thing:
both(y).x = 1234;
both(y).X::x = 1234; // more explicitly way to show use of X
}
A decent compiler should turn the call to both() here into a simple
subtract instruction. If Y had an inline function that needed to use
both(), it could be defined like so:
// Y.h
struct Y { void inline_func(); };
#include "Both.h"
inline void Y::inline_func()
{
both(*this).x = 1234;
} |
If you didn't mind a macro, you could streamline all uses of both from inside X and Y member functions:
Code: |
#define BOTH both(*this)
inline void Y::inline_func()
{
BOTH.x = 1234;
} |
This is safe since both() will only work with a base class for Both
(the static_cast<> requires that the reverse conversion be
implicit).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 06, 2007 3:43 am Post subject: |
|
Quote: |
C++ supports this just fine, so I don't understand your claims that it makes it so hard. What more could it do? |
Yeah, I wasn't sure if it was valid. I looked into it more, and it is.
The obvious catch is that you can't rely on the pointer during the
construction of the subclass, but I already knew that much.
As far as what more they could do ... I understand your point. I
honestly think that classes inside classes should be able to access
parent functions directly. Meaning you'd need a new concept, 'this' as
well as 'parent', and anything not in 'this' automatically looks in
'parent'.
Yes, this would mean you couldn't create A::B objects outside of A. But
if you had any desire to do that, you'd make A and B separate anyway.
The current system makes nesting classes "mostly" useless.
So, why do this at all? Because you don't want to create supermassive
classes that contain your entire program, either. The reason I want a
class inside a class is because:
1) It means the global namespace is only polluted by one class name.
2) The user of said library only has access to create one type of class.
3) Creating that one class automagically creates and maintains all of
the subclasses. No need to explicitly declare anything but 'SNES snes'.
4) All of the class communication can easily be inlined. Inlining
obviously means static programming. No polymorphism, no derived
classes. It's worth it for the speed gain.
5) You have to admit that SNES::CPU, a nested class, looks much more elegant that SNES_CPU, a separate class ...
Here's the big picture of where I'm going:
I want to have two separate emulators for each core chip. One that is
fast, simple, and can be serialized; and one that is dead-on accurate,
super slow and uses threading to simplify parallelism.
I want to combine the two into one program, but I also want to share
the very large base of code that is the same, that is:
- The user interface (and its video, audio, input API wrappers)
- The config settings
- The video filters
- The cartridge loading and all of the memory mappers
- All of the special chips
- etc, etc
But! The model I have now won't work. The way my four base processors
communicate isn't compatible with the two different types of emulation
I want to implement. I think it may be possible to make that so sans a
function or two. Not sure yet there ...
Ideally, it would be nice to make the whole thing a runtime switch, but
I think I'm going to have to accept that there will be separate builds
for each mode. Inlining is more important than one single build.
I'm also wanting to move this all toward a more library-like
implementation. It would be nice if others could easily take the core
of bsnes and put it into other programs with ease, or even turn it into
something like the "wall NES" demos, just for fun. I don't like the
current design, where it's impossible to have more than one instance,
as all of the chips declare their own global objects that directly talk
to each other.
As for your two ideas, I admit that I do like the first one. I could
extend that a bit using multiple inheritance on 'class SNES' to
simplify combining the different CPU, SMP, ... implementations into one
big class object.
The second idea is very intriguing, but I don't like the idea of
merging all of the classes together like that. I see I can easily avoid
naming conflicts by being explicit, but having to use the wrapped
static_cast all of the time is a major downside to that, even if it's
as simple as a "BOTH." prefix.
Nonetheless, I'll look into it further. Thank you very much for the suggestions.
I'm definitely not going to start on this rewrite until we can come up
with a model everyone agrees is good, so there's plenty of planning
time here.
EDIT: here's my mockup, based on blargg's first template:
Code: |
namespace bsnes {
struct Core;
struct CPU;
struct SMP;
struct Core {
CPU &cpu;
SMP &smp;
Core(CPU &r_cpu, SMP &r_smp) : cpu(r_cpu), smp(r_smp) {}
};
struct CPU {
Core &core;
SMP &smp;
CPU(Core &r_core, SMP &r_smp) : core(r_core), smp(r_smp) {}
};
struct SMP {
Core &core;
CPU &cpu;
SMP(Core &r_core, CPU &r_cpu) : core(r_core), cpu(r_cpu) {}
};
struct bCPU : CPU {
bCPU(Core &r_core, SMP &r_smp) : CPU(r_core, r_smp) {}
};
struct bSMP : SMP {
bSMP(Core &r_core, CPU &r_cpu) : SMP(r_core, r_cpu) {}
};
struct sCPU : CPU {
sCPU(Core &r_core, SMP &r_smp) : CPU(r_core, r_smp) {}
};
struct sSMP : SMP {
sSMP(Core &r_core, CPU &r_cpu) : SMP(r_core, r_cpu) {}
};
}
namespace bsnes {
template<typename CPU, typename SMP>
struct SNES {
Core core;
CPU cpu;
SMP smp;
//Cart cart;
//Bus bus;
//Cheat cheat;
//Video video;
//Audio audio;
//Input input;
//SDD1 sdd1;
//SRTC srtc;
//...
SNES() : core(cpu, smp), cpu(core, smp), smp(core, cpu) {}
};
struct bSNES : SNES<bCPU, bSMP> {
bSNES() {}
};
struct sSNES : SNES<sCPU, sSMP> {
sSNES() {}
};
}
namespace bsnes {
//use if more specialization is needed
bSNES b_snes;
sSNES s_snes;
//use if less specialization is needed
SNES<bCPU, bSMP> ib_snes;
SNES<sCPU, sSMP> is_snes;
} |
I think I can hide the differences between cothreaded and state machine
+ enslavement processor emulators by sticking the co_switch() stuff
inside the individual processor classes. Not entirely certain this will
be possible, but it should be. That will mean I only need one scheduler.
But the big difference then will be that only sCPU and sPPU can talk to
each other, and only bCPU and bPPU can talk to each other, because
their internal design will be fundamentally different ... I may need to
make two types of base class processor objects, one for each emulation
model, and then inherit the final classes from that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 06, 2007 6:49 am Post subject: |
|
Sigh, this isn't going to work ... this is going to be a depressing soapbox post, so be forewarned.
To go over things again, but in more detail ...
I want one implementation to take advantage of enslavement. That is,
eliminate cothreads. The CPU won't even need a state machine. It will
call the PPU scanline renderer, and SMP cycle emulator when needed. The
SMP can even run multiple cycles at a time, with states only on cycle
reads/writes. The SMP could further enslave the DSP. The most ironic
part is that this would probably even be almost as accurate as what I
have now, it would just lose the bus hold delays. But even that could
be bullshitted to an extent with more ugliness.
I want the other implementation to be designed as an ideal, or concept
program. Design it like real hardware, where no chip has any knowledge
of the other. You could remove the CPU from an SNES and use it
independently. Ideally, the same would be true of code, thus
enslavement can't be used in such an ideal. But this has its problems,
too.
I've been trying and trying to come up with the magic bullet to a fast
cycle PPU, and failing for over a year. The truth, which I already
know, is that it's not possible. The basic problem is again, the crux
of emulation as a whole, parallelism. The CPU has to probe the PPU
v/hsync pins every single clock tick. And the PPU's state can be
changed by the CPU at virtually any clock tick as well. So they can't
run ahead of each other. The result? You'd need probably at least 5GHz
or better to emulate these processors independently of each other.
And even then, that model is still bullshit. There isn't one PPU, there are two PPU chips. Why make a hybrid PPU class that emulates two chips as one? That violates my separation. And even then,
that's still not good enough! Take a look at the CPU's hardware math.
Yes, it's inside an IC, but like all electronics, even that is
parallel. The math unit slowly calculates a result as the CPU continues
on executing other instructions. To emulate it ideally, would require
separate threads for each, and the same precision level as the PPU
would require now. Yeah, a multiple GHz speed hit just to get the
partial results of mul/div reads working properly. Again, shoddy hacks
may or may not make that possible without the speed hit at all.
And so, here I am now, with the bastard child of the above two
approaches. A PPU enslaved to the CPU, and independent SMP and DSP
modules. Bullshit mul/div emulation, from the most accurate SNES
emulator around. Capped on speed, preventing me from making any more
improvements without making it unplayable. No more known game bugs to
fix. No more special chips I can add. No more features (other than
fullscreen support and maybe some input peripherals) that I can add.
And as you've seen for the last few months, I keep deluding myself into
believing the solution is to split the emulator into two completely
different models that can't realistically share much, if any, code at
all. What they can share may be a large volume of code, but it's all
simplistic crap.
So now I want to try and turn what I have into ZSNES +
Pong-circuit-emulator. Or in other words, an existing emulator that's
already light years ahead of anything I could ever hope to make and has
ten times the talented developers, and a worthless concept emulator.
Yes, worthless. I'm sorry, as much as I eschew accuracy, there's no
value in an emulator that needs a THz+ computer to get 60fps. Maybe in
60 years after I'm dead someone might care, if they even know what an
SNES is.
I can't bear to write fast code full of speed hacks, bugs and problems
like most of the current emulators, nor can I bear to write an emulator
that takes five hours just to get to the title screen of my favorite
games. But as anyone knows, extremism in either direction is never the
solution. You have to find a middle ground. But isn't that what I've
already done and have now?
If you can't tell what I'm getting at, it's that I've failed. The
current bsnes was the best I could do. I took things as far as I could,
until I exhausted all of the resources of the fastest of the fastest
processors on the market.
And I did a lot, I reached 100% compatibility without hacks, and
discovered a lot more about how the base hardware itself works than we
knew before. But perhaps the most important thing I did was finally
give ZSNES needed competition to evolve. And now that it is, it isn't
afraid of using tricks I have problems with, like enslavement. It'll
easily destroy what I have now as bsnes. And yes, it'll probably be
thrice as fast, with all the features everyone wants to boot.
So, what place is left for me? Well, ZSNES v2.0 isn't out yet. I
suppose I'll just stick with what I have ... clean up the code, try and
add the few things left that I can like multitap and fullscreen, fix
any bugs that do pop up in the meantime, and by example give
encouragement for others to improve their emulation.
But I've ultimately reached my limits. The longer I try and deny that,
the more disservice I'm doing to everyone here. It's fitting that the
three year anniversary of bsnes is about a week away. I'll see if I can
get the video settings module working in time. I'll most likely release
a new version with that, DSP-3 and DSP-4 support, and release the whole
emulator to the public domain. Not discontinued, just disheartened.
I'll also still poke at the hardware to try and fill in some more
details wherever I can, too.
I'm not at all surprised, though. I never expected to reach perfect
accuracy anyway. I was just hoping I could get a lot closer than I did.
But the rabbit hole is tricky. In truth, we can already see the bottom
of it, it is the Pong circuit emulator. But we can't even jest about
such a thing for the SNES -- the circuitry is many orders of magnitude
more complex, and quite likely impossible to fully decap and decode
anyway. And let's not even joke about those system requirements.
Well, it was a good run anyway. I really had a lot of fun, and I have no regrets.
Maybe if one day everyone decides to work together on a new, clean,
from scratch emulator, I'll join in on that. I think current bsnes
accuracy at 800MHz is a realistic goal, and then maybe we can push that
accuracy up a few notches with the increased headroom. Or maybe I'll
change my mind yet again and take a stab at a fast emulator myself or
something, even though it'd just be another clone that wouldn't stand a
chance against ZSNES v2.x. Without the EE skills and hardware, and
without the processing power, I sadly have low hopes for a more
accurate PPU emulator, but ... you never know. I hate speculating,
because I tend to change my mind a lot on these things. But the above
is how I've felt for quite a long while now. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Oct 06, 2007 8:05 am Post subject: |
|
If
you really want to work the same as the hardware (beyond being the
exact same silicon design), use an FPGA. That's the only way to really
do things in parallel with the same high-level hardware units (counter,
shift register, latch, etc.). For a software-based emulator, it seems
absurd to try to make it at the hardware level; you need to work at a
higher level, at the level of functional modules. It's reasonable to
have the CPU (mostly) independent of the PPU, but not to try to break
up instructions into clocks the way hardware does.
If it were just the CPU that could access the PPU at any time, this
wouldn't prevent the PPU from being allowed to fall behind until the
next CPU access or end of frame. But you say the PPU can potentially
affect the CPU every instruction? How so? And if so, can this effect be
predicted easily in advance, for example "given current PPU state and
no CPU accesses to the PPU, the earliest the PPU can affect the CPU is
X clocks from now"?
Quote: |
If
you can't tell what I'm getting at, it's that I've failed. The current
bsnes was the best I could do. I took things as far as I could, until I
exhausted all of the resources of the fastest of the fastest processors
on the market. |
I think the ideal you have of "emulating the hardware as it actually
runs" is flawed, and is displacing realistic approaches to accurately
emulating hardware behavior.
I guess I encounter this regularly, and I'm not even trying something
as complex as the SNES PPU. What I'm finding I need is a classification
of major to minor behavior, so I have more than an all-or-nothing view
of what is emulated. It's always progress to get another more major
behavior nailed down correctly.
I also think
trying to keep bsnes usable by splitting the code base is a mistake. I
think you need someone else to maintain the optimized version, so you
don't have to think one bit about how a new change will affect that
one. Trying to maintain two versions yourself seems like too much of a
burden, given the conflicting goals each would have.
But hey, I consider the SNES to be a very complex beast and beyond my
ability to ever fully understand in this lifetime. It's a choice
between deeper understanding of simpler systems or shallower
understanding of more complex systems.
Last edited by blargg on Sat Oct 06, 2007 11:05 am; edited 1 time in total
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Oct 06, 2007 8:40 am Post subject: |
|
byuu wrote: |
If
you can't tell what I'm getting at, it's that I've failed. The current
bsnes was the best I could do. I took things as far as I could, until I
exhausted all of the resources of the fastest of the fastest processors
on the market. |
This may be little consolation, but I for one am greatly impressed at
what you've achieved - as far as I can tell, you've almost
single-handedly pushed the entire emulation scene to higher standards
in emulation accuracy. And not just by talking big and encouraging
other people to do the work, but by getting your hands dirty and
proving what's possible.
I shall watch with great interest any future software projects you get involved with!
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 06, 2007 9:17 am Post subject: |
|
I
hope you can work through this discouragement byuu, life can be rough
on you sometimes, and often the things you are most passionate about
are the things that torment you the most.
another
thought is this, bsnes is an emulator that is trying to most accurately
represent the Super Famicom system, but it is an emulator written to
run ON today's personal computers and operating systems. While the
standard of the SNES is set in stone, our systems are always changing,
and you can only do the best for what is out there right now.
if we all wanted just the real deal (just for playing), it'd be much
easier to go out and find an SNES, but this is so much more than that.
I'd say don't worry about a faster version, and just stick to what bsnes has always been.
I think you should know that we all appreciate what you've done and
will support your future endeavours, whether it be continued
development of bsnes, or something else.
it is a bit of a predicament, because while further development I think
is important to all of us, there will be less and less tangible
differences in the following version of bsnes (right?) and this I'm
sure will prove to be a frustration not only for people using the
emulator but to yourself.
because there isn't much more you CAN do at this point (for the time
being anyways), due to running out of most but a select few things to
emulate (of which most are essentially impossible at this point), and
not being able to further push the core emulation due to current
technical constraints, I would encourage you to not strive to achieve
unrealistic improvements in bsnes builds for awhile because you will
only only frustrate and disappoint yourself.
If you aren't truly enjoying the work you are putting into this, then
it really seems like a waste. I would hope that whatever you work on
that it be something that you can learn from and really get something
out of.
I mean if you could still enjoy working on cleaning the code or just
fleshing out the user interface or working on portability, then I say
more power to ya. or if you just need a break, GREAT, or if you want to
work on another system fantastic.
I think we'd all love to see bsnes continue to grow (including
yourself) but if it becomes a chore then for you then it's useless in a
sense.
I do believe you still have a lot to bring to the table though, and offer to the entire community.
What aspects are you really interested in? I know you seemed fascinated
with all you did with libco and making bsnes Linux friendly and a lot
of the work you did on the interface. This may seem superficial and I
know you don't see bsnes as a feature emulator, but just working on the
UI may be the therapy you need. I don't know, I'm begining to ramble
now so I'll wrap this up, just trying to throw in a layman's two cents.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 06, 2007 9:31 am Post subject: |
|
I personally don't think you have failed at all.
Also i dont think you need to make a faster version of bsnes.
Bsnes is fast enough as it is on modern hardware, you could just add
the new sPPU as a compile time option, so any fixes to the core would
still benefit runnable bsnes aswell as sPPU bsnes.
Also Aaron of mame recently updated some mame components to 64bit, and
added software SLI which now gives some games 60fps on his system!
there is still a lot of optimisation possible that we have no idea
about at this point!
Besides that you have inspired many people to make their emulators more accurate! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Oct 06, 2007 10:47 am Post subject: |
|
It
does seem that there isn't that much left to do at this point, but all
that shows is that you've succeeded in emulating the SNES as accurately
as possible on today's computers - while also staying as faithful as
possible to how things actually work on the SNES. If the new PPU is
something you're not that motivated to work on anymore, I think
everyone will agree that bsnes has already reached a very impressive
level of accuracy without it, and no one will blame you for taking a
break or stepping back. Perhaps you could start on the documentation
you've often mentioned wanting to write? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 06, 2007 11:06 am Post subject: |
|
An emulator/circuit simulator with the sole
purpose of documenting and reproducing the original hardware does not
sound bad imo. Even if the bottom line is it takes 500Ghz to reach full
speed. (I've gotta be fully honest: I still got my copier (plus the
games are currently very cheap)
Yes,I realise
you don't share that sentiment and you want an emulator that's at least
playable on today's hardware and that's perfectly understandable but
the fact would remain that it would still serve as an amazing
documentation and ultimately would preserve the Snes
... It's clear Nintendo doesn't give a crap about preservation their
own hardware or even their own games for that matter, save for the few
games that will be released as Virtual titles on their
let's-hack-each-games-individually-so-it-actually-works Whorerulator.
Quote: |
So now I want to try and turn what I have into ZSNES + Pong-circuit-emulator. |
If it has to comes to that,I mean if mathematically speaking playable
speed + top accuracy is not possible... I personally don't see the
problem with many different emulators.
Might as well make it three:
-Fast and with 98-99% compatibility with no game specific hacks.
-Current design
-"Pong circuit simulator"
Of course, I'm not expecting you to work on three different builts and
someone else would maintain the other ports.
Sorry for going off-track. I really do hope you regain your motivation
to work on bsnes. You certainly haven't failed as you've given us an
amazing emulator but ultimately you gotta do what you think is best for
you.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Oct 07, 2007 1:07 am Post subject: |
|
I
agree with everyone. The very idea that you've failed is laughable.
You've done so much, and no one here can say they don't appreciate all
your hard work. I also agree that if this is really weighing on your
mind, you should take a break, either to work on little things that can
be improved, work on some other project you would find fun, or take a
complete break altogether to relax, and not have to worry so much. Even
personal projects can become tiresome if you work on them for too long,
and none of us would want you to burn out.
Honestly, really honestly, I don't use bsnes all that much. I am one of
those people who is interested in silly things like filters, and save
states, and all that jazz. But I've never been more impressed by a
program than I have with yours, because of your complete unwillingness
to compromise. Frankly, it's inspiring. You do really good work, and
you do almost all of it without a lot of help. If only for this, I see
bsnes as a success, even while it's still a work-in-progress. We don't
need you to fork the project, we don't need you to add video modes, we
don't need special chips. We want you to do what you enjoy doing. If
that means I can't use it, at least I'll know you're doing something I
could never do, and it's really cool to even "know" you. I swear, these
forums make me feel like I'm talking to celebrities sometimes. And then
I feel really nerdy 
Do what you want to do. We'll support you. That's how I feel. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sun Oct 07, 2007 1:21 am Post subject: |
|
DancemasterGlenn wrote: |
I swear, these forums make me feel like I'm talking to celebrities sometimes. And then I feel really nerdy :D |
Quoted for truth.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Oct 07, 2007 1:46 am Post subject: |
|
here
here, three cheers for byuu, and all the other many developers on these
forums that work so hard to let us share something we all enjoy so very
much. By no means am I trying to burden any of you with empty flattery,
certainly not, but lets give credit where credit is due. We are all
truly grateful for all of your contributions.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Sun Oct 07, 2007 4:20 am; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Oct 07, 2007 4:16 am Post subject: |
|
Panzer88 wrote: |
but lets give credit where credit is due. We are all truly grateful for your contributions. |
Yes indeed.
Personally I don't believe byuu's ideals are flawed. He does have
however, amazingly high emulation standards. There's nothing wrong with
that imo. But perfection (or striving for perfection) sometimes has a
high price.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 07, 2007 5:57 am Post subject: |
|
byuu wrote: |
Sigh, this isn't going to work ... this is going to be a depressing soapbox post, so be forewarned. |
This is pretty much a battle you seem to be having with yourself over
which is more worth it to you: self-documentation or playability.
You've reached a point where you can no longer work on improving both.
I'm going to be honest with you. I don't like the idea the idea of
self-documentation. My opinion is that hardware is nothing without the
software. Paramount is the preservation of the enjoyment of the games.
In the end, the preservation of the hardware is only important inasmuch
as it replicates the game as it was experienced on the real hardware.
And now people are going to say "Oh, so you support game specific
hacks?" No, generally I'm against them. But it's not because my
knowledge of the hack somehow affects my enjoyment of the same exact
gameplay. It's mainly because they're a fucking terrible strategy to
use on a system with a library of 3000 games. Suppose you create a
hundred hacks, then make emulation changes. How many of those hacks are
necessary any more? Would take a while to remove them all and backtest
wouldn't it? Completely unfeasible in the development of such an
emulator.
Anyway, you seem to have discovered that a program serving as an "exact
model" of what the actual hardware does is not only nigh impossible,
but unusable for enjoyment as well. Given the requirements of perfectly
translating every little detail of operation to a PC, you may find it
satisfactory to simply preserve the exact details of the SNES through
documentation and then create a highly portable emulator that makes the
best tradeoffs between accuracy and playability (in other words,
self-documenting only to the extent that it affects game
compatibility). There is no emulator that currently does this. ZSNES
2.0 will not change that and I think you would have great success with
this strategy. You just have to lay out some rules for yourself and not
go so far as to break too many games. In fact, it would be better
initially to see how fast you could make your current version by
restructuring or doing things that would only affect self-documentation
but not compatibility. Then you could decide if things like IRQ
range-testing or opcode cores are worth creating bugs for. And I also
support things like further research on the PPU... it's just that
documentation might be a better place for it.
Anyway, I really appreciate what you've already done. Whatever you do,
it comes down to do what motivates you and makes you happy. So I can
try to consider your post and suggest a new direction for you to take,
but if the games and the users aren't what motivates you or makes you
happy, then that's not what you should do.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sun Oct 07, 2007 9:05 am Post subject: |
|
Good post, FitzRoy. I agree with most of it.
FitzRoy wrote: |
My
opinion is that hardware is nothing without the software. Paramount is
the preservation of the enjoyment of the games. In the end, the
preservation of the hardware is only important inasmuch as it
replicates the game as it was experienced on the real hardware. |
Well-summarized. The main problem is that to be sure the game is really
being run the same, the hardware must be emulated accurately. In many
cases inaccurate hardware emulation results in obvious game problems,
but not always.
This line of thinking does give a very practical basis for determining
aspects of hardware that are much more important to get right. The
games illustrate common programming practice for the system, so
catering things to what games do is catering to the common way the
system is used, which is a reasonable thing and just a hack. The same
approach would be appropriate for emulating a PC system that had
important software.
There is another aspect of hardware preservation that has nothing to do
with games, that is documenting the designs of the time. The general
design is well-known, but detailed aspects might be of interest in the
future.
Quote: |
Anyway,
you seem to have discovered that a program serving as an "exact model"
of what the actual hardware does is not only nigh impossible, but
unusable for enjoyment as well. |
This is what my "flawed ideal" referred to. What constitutes a software recreation of the hardware that works the same was as the hardware?
Beyond behaving the same, it's all philosophical, and ultimately just
speculation unless every chip in the SNES is decapped and the circuit
determined.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Oct 07, 2007 9:27 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
Sigh, this isn't going to work ... this is going to be a depressing soapbox post, so be forewarned. |
I'm going to be honest with you. I don't like the idea the idea of
self-documentation. My opinion is that hardware is nothing without the
software. Paramount is the preservation of the enjoyment of the games.
|
You're entitled to your opinion. All I gotta say is I disagree. bsnes
imo, goes way beyond a simple 100% compatibility bug free results.
There are others emulators that could probably achieve that (with or
without game-specific hacks) but they would probably not even come
close to bsnes current level of accuracy.
Most importantly, there are other emulators that focus on playability.
Heck, nothing can beat a real Super Famicom as far as enjoying the
games. They can be found for 30$ bucks if you look a bit and most games
can be brought for a fraction of that price. The point is, right now,
nobody NEEDS a Snes emulator to enjoy the games. If you got money to
have a PC fast enough to run bsnes, you've got enough money to buy a
Snes and many games (or an snes an a copier)
The main point of emulators is that they make playing those old games possible when the original hardware is not longer available.
Believe it or not, my opinion doesn't differ that much from yours.
Documenting an old console if you got no games to run on it does indeed
seems like a very pointless exercise, so yes, ultimately I think it IS
about the softwares, but like byuu said, and I agree 100% with him, the
best way to preserve the software is to (virtually) preseve/document
the hardware to the best of our ability.
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Oct 07, 2007 3:23 pm Post subject: |
|
First
of all I'd like to say thank you to the above posts, I agree with a lot
of points in them. I think it's all about what motivates you (byuu) to
write this amazing, complicated piece of software. Your drive to obtain
the ultimate in accuracy, as I understand it has kept you going for
(amazingly) almost three years now. As it turns out getting this ideal
(or even, in absolute terms, getting close to it) is simply impossible,
and it's only natural that it gets you down. But this isn't the
first time that you've realised that there's an end to what you can
reasonably do in software, and I've watched you, uh, pick up your
keyboard again and continue regardless. It's not for me or anyone to
judge how hard it's hitting you now compared to those other times, but
I think it's important to ask, who are you doing it for?
As far as my opinion goes, I think the compromise bsnes has been
improving on for the last two or three years is an ideal in and of
itself. Seeing how far you can get with accuracy while maintaining (or
even improving) code clarity and readability is an idea that's inspired
me as a programmer, perhaps especially when seeing how it paid off for
you (being able to fix a new bug two hours after it was found, for
instance). I think besides emulating hardware or software, you've also
pulled attention to the underlying theory and philosophy of computer
sciences, sometimes showing how far we've come, other times how badly
founded some aspects still are. In the end programming is all about
creating things, and when you're doing that it's not just the end
result that's important but also laying down new concepts that will
help other people to better structure and design both their program and
the code itself, which in turn paves the way for others.. Basing
everything on 'optimal' and/or clean code (if not clean internally than
atleast having a good interface - and taking into account as many edge
cases as possible) is obviously much superior to basing it on slow
hackish implementations which are still used far too often in this
field. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 07, 2007 6:05 pm Post subject: |
|
Snark wrote: |
FitzRoy wrote: |
byuu wrote: |
Sigh, this isn't going to work ... this is going to be a depressing soapbox post, so be forewarned. |
I'm going to be honest with you. I don't like the idea the idea of
self-documentation. My opinion is that hardware is nothing without the
software. Paramount is the preservation of the enjoyment of the games.
|
You're entitled to your opinion. All I gotta say is I disagree. bsnes
imo, goes way beyond a simple 100% compatibility bug free results.
|
Yeah it does go beyond it, but what's the point if all it does is slow
the same gameplay down by 500%? The whole purpose behind the SNES or
any game console lies in the enjoyment of the games that you could buy
and play on it, and self-documentation is only important to the extent
that it helps that. For many processes, self-documenting accuracy is
exactly what you want to do because there is no way to simplify without
affecting compatibility.
Quote: |
There are others emulators that could probably achieve that (with or without game-specific hacks) |
None closer than bsnes. I've never seen an emulator author as
relentless towards bugs as byuu. There are other SNES emulators out
there, but it's all wishful thinking when you compare certain things.
Like Verdauga, I think it's great that people are inspired by bsnes.
But I don't see inspiration as the prevailing quality of bsnes, or the
catalyst that can bring about such a dramatic change in other emulators.
Quote: |
Most importantly, there are other emulators that focus on playability. |
Super Sleuth is the only close one I can think of... if it had gotten finished.
Quote: |
Heck, nothing can beat a real Super Famicom as far as enjoying the
games. They can be found for 30$ bucks if you look a bit and most games
can be brought for a fraction of that price. The point is, right now,
nobody NEEDS a Snes emulator to enjoy the games. If you got money to
have a PC fast enough to run bsnes, you've got enough money to buy a
Snes and many games (or an snes an a copier) |
A real SNES has no savestates, digital a/v, netplay, it can't play
translated or hacked versions of special chip games, it IS expensive
(CT and FF3 combined would fetch over $100), it can't be made portable
by using it on a laptop or a psp... Yeah, emulation can and does beat a
real SNES, even with a copier.
Last edited by FitzRoy on Sun Oct 07, 2007 6:14 pm; edited 2 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Oct 07, 2007 6:06 pm Post subject: |
|
byuu wrote: |
Take
a look at the CPU's hardware math. Yes, it's inside an IC, but like all
electronics, even that is parallel. The math unit slowly calculates a
result as the CPU continues on executing other instructions. To emulate
it ideally, would require separate threads for each, and the same
precision level as the PPU would require now. Yeah, a multiple GHz
speed hit just to get the partial results of mul/div reads working
properly. Again, shoddy hacks may or may not make that possible without
the speed hit at all. |
What about hardware tests with each and every value, at any time?
(Might very well be an academic question.) IMO using these tables would
not be a "true" hack since it is based directly on the hardware, and
not something to make certain games run. Would be a compromise, of
course.
byuu wrote: |
I'm
sorry, as much as I eschew accuracy, there's no value in an emulator
that needs a THz+ computer to get 60fps. Maybe in 60 years after I'm
dead someone might care, if they even know what an SNES is. |
I'd guess that the technology will change rapidly in the next ten
years. As soon as a viable technology is found, everybody will jump on
it.
byuu wrote: |
I
can't bear to write fast code full of speed hacks, bugs and problems
like most of the current emulators, nor can I bear to write an emulator
that takes five hours just to get to the title screen of my favorite
games. But as anyone knows, extremism in either direction is never the
solution. You have to find a middle ground. But isn't that what I've
already done and have now? |
Yep. Time for the features then. 
byuu wrote: |
But
I've ultimately reached my limits. The longer I try and deny that, the
more disservice I'm doing to everyone here. It's fitting that the three
year anniversary of bsnes is about a week away. I'll see if I can get
the video settings module working in time. I'll most likely release a
new version with that, DSP-3 and DSP-4 support, and release the whole
emulator to the public domain. Not discontinued, just disheartened.
I'll also still poke at the hardware to try and fill in some more
details wherever I can, too. |
Disheartened, after having achieved everything that was possible with what is available?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Oct 07, 2007 8:18 pm Post subject: |
|
dp sorry
Last edited by Snark on Mon Oct 08, 2007 12:07 am; edited 2 times in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Oct 07, 2007 11:59 pm Post subject: |
|
creaothceann wrote: |
byuu wrote: |
I'm
sorry, as much as I eschew accuracy, there's no value in an emulator
that needs a THz+ computer to get 60fps. Maybe in 60 years after I'm
dead someone might care, if they even know what an SNES is. |
I'd guess that the technology will change rapidly in the next ten
years. As soon as a viable technology is found, everybody will jump on
it.
|
*nods*
Also, don't underestimate the attraction of things that are out of
reach. It may actually help create an interest. The fact that it woud
be unplayable on today's computer I meant. I've seen this with MAME
with some drivers.
edit: ok, maybe that's a bit far-fetched but you never know...
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 08, 2007 7:14 am Post subject: |
|
FitzRoy wrote: |
A real SNES has no savestates, digital a/v, netplay, it can't play
translated or hacked versions of special chip games, it IS expensive
(CT and FF3 combined would fetch over $100), it can't be made portable
by using it on a laptop or a psp... Yeah, emulation can and does beat a
real SNES, even with a copier. |
bsnes doesn't have savestates either, and they aren't necessarily
necessary. neither does bsnes have netplay, heck even ZSNES's is down.
You have a point on the special chips there, but bsnes still doesn't
emulate several special chips, in fact if you want two of the more
popular ones, SA-1 and SFX, you're still gonna need another emulator.
As for CT and FF3, I think that's what the copier is for, sure it costs
a lot, but as it's already been said, if we can afford a nice enough PC
to run bsnes at 60 I'm sure we can afford a copier.
bsnes may be a little slower than other emus, but it's also the best at
what it does, and within a few years computer speeds are going to
dramatically increase, just like they have in the past. There are gonna
be multi-core computers that would enable him to write each chip to be
handled by a different processor I bet by that time.
I know you are just saying what you think is best for the emu, just pointing a few things out.
I think that's something we all need to consider too, computer
technology changes rapidly, and there will be exponentially faster
computers in the mainstream market before we know it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Oct 08, 2007 8:52 am Post subject: |
|
I thought we agreed on the fact that the timing just wont work with more then one thread. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Oct 08, 2007 10:21 am Post subject: |
|
Running
all the components on two cores may generate too much overhead, but if
you run each component on its own core the amount of synchronisation
between individual cores should decrease substantially. I'm not saying
it would work, because I don't know, but the situation would be
different from what it is now. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Oct 08, 2007 10:51 am Post subject: |
|
Verdauga Greeneyes wrote: |
Running
all the components on two cores may generate too much overhead, but if
you run each component on its own core the amount of synchronisation
between individual cores should decrease substantially. |
Um, no. Working to keep four things synchronised (CPU, PPU, SPU and...
SMP?) is much harder than keeping two things synchronised with each
other, and much, much harder than keeping one thing synchronised with
itself.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Oct 08, 2007 11:19 am Post subject: |
|
Well,
remember they'd all be done in parallel.. so long as you can ensure
components don't synchronise in the wrong order (which should be
relatively simple to ensure with some flags and maybe some pointers to
avoid unnecessary branching) this should have less overhead as far as I
can see. Right now there are just as many components that need to be
syncronised, but it all has to be done on one core. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 08, 2007 12:40 pm Post subject: |
|
Thats
actually a good idea in theory, If each cpu core, emulates its own,
independed processor, and all of them would simply modify data in the
memory bank, it should act a lot like a real snes, all you would need
to do is make sure that each chip runs at its original frequency
Are any chips enslaved on a real snes? how do they communicate? (the
communication between a real snes is probably faster than in the
emulated multicpu scenario, or maybe not!)
maybe if all snes processors run at exactly their original speed, and
communication between each of these is exactly as fast as on the snes,
all the sync's wouldn't be needed, or at least lessened right?
So if you had 8 cpu's:
cpu1: main thread
cpu2: cpu
cpu3: ppu1
cpu4: ppu2
cpu5: filters and rendering
cpu6: and so forth..
looks a lot like what i think co-threads does |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Oct 08, 2007 1:42 pm Post subject: |
|
tetsuo55 wrote: |
Thats
actually a good idea in theory, If each cpu core, emulates its own,
independed processor, and all of them would simply modify data in the
memory bank, it should act a lot like a real snes, all you would need
to do is make sure that each chip runs at its original frequency |
This is very true. However!
It is very, very difficult to make, say, bsnes' emulated SPU go at the
exact speed of the original SNES SPU. Consider that bsnes runs on PCs
from about 1.5GHz up to 4GHz, so you can't apply some constant slowdown
factor. If you want the emulated SPU to just sleep until the next time
it has to do something, consider that most operating systems will only
let you sleep for multiples of 50ms (20 sleeps per second), while a
cycle-accurate SNES SPU has to wake up and do things millions of times
a second. Consider that bsnes is designed to run on multitasking
operating systems that can take your real CPU away for other programs
to use at any time, causing your emulated SPU to miss any deadlines
that the other emulated components were expecting it to meet.
In a multi-tasking, multi-core, multi-threaded environment (such as
your hypothetical multi-core bsnes running on Windows or Linux), your
program can never tell exactly how long any single thing is going to
take. So while in theory, if everything ran at the same speed as the
SNES things would Just Work, you can never write software with such
precise timing. The only alternative is to have your emulated
components check up on each other to make sure they're 'up to date'
before communicating. So an operation that looks like this on a real
SNES:
Code: |
CPU: Here you go, SPU! <toss>
SPU: <catches it>
SPU: <calculates a response>
SPU: Here you go, CPU! <toss>
|
...looks like this in emulation:
Code: |
CPU: I need to send something to the SPU. Are you there, SPU?
CPU: <waits>
SPU: Oh, CPU wants to send me a message, but I'm still a few cycles behind.
SPU: <grind, grind>
CPU: I need to send something to the SPU. Are you there, SPU?
SPU: I'm here!
CPU: Here you go, SPU! <toss>
...
|
...and so forth.
So no, multiple cores aren't going to help bsnes (or any other reliably accurate emulator) at all.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Oct 08, 2007 1:45 pm Post subject: |
|
It has already been explained that synchronizing the CPU cores is much slower than what bsnes requires.
That's one of the reasons for libco, and it's also the reason why
running each component on its own core is not possible at a decent
speed.
See http://byuu.cinnamonpirate.com/?page=programming/libco ("Basic Concept of Multithreading").
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 08, 2007 3:26 pm Post subject: |
|
I
didn't actually mean to start a huge discussion about it. It was just a
loose example about how future hardware can change the way we do things.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 08, 2007 4:07 pm Post subject: |
|
Thank
you all for the feedback. It really has helped clarify some major
points for me. I'll start by responding, then going over my current
thoughts.
Quote: |
If you really want to work the same as the hardware, use an FPGA. |
I don't have the EE skill for that yet, but there would be that very few could enjoy or test my work there.
Quote: |
I also think trying to keep bsnes usable by splitting the code base is a mistake. |
I honestly agree. As one person, two or three emulators to maintain is too much.
Quote: |
What aspects are you really interested in? |
The PPU. I know it's nightmarishly complex, but it sounds like the last
frontier, so to speak. I am happy with modern CPU, SMP and DSP
emulation.
Quote: |
you could just add the new sPPU as a compile time option |
I wanted that, but at least both the CPU and PPU would have to fork for that to work.
Quote: |
Of course, I'm not expecting you to work on three different builts and someone else would maintain the other ports. |
If only someone were interested in maintaining one of the other two.
Quote: |
In
the end, the preservation of the hardware is only important inasmuch as
it replicates the game as it was experienced on the real hardware. |
Yes, but I've already preserved all games (sans 5 chips). I could maybe
optimize things by 30-50% if I could fix PGO and get IRQ range testing
back (both near impossible), but that improves emulation naught.
Quote: |
but if the games and the users aren't what motivates you or makes you happy, then that's not what you should do. |
Honestly, all three of these motivate me equally. Hence the difficulty I have deciding.
Quote: |
Beyond
behaving the same, it's all philosophical, and ultimately just
speculation unless every chip in the SNES is decapped and the circuit
determined. |
Agreed to an extent. I don't think it's philosophical that the PPU is
not enslaved to the CPU, but I realize both result in the same output
for the same input.
My ideal has been to aim for "what would the hardware do?" as much as
possible. Not surprisingly, when emulating new behavior, having the old
stuff implemented correctly made understanding new behavior much easier
than not.
Quote: |
But this isn't the first time that you've realised that there's an end to what you can reasonably do in software |
No, I keep putting off the problem and sticking with what I have,
hoping I can come up with a solution later on. But that keeps on
failing and my software stagnates.
Quote: |
(being able to fix a new bug two hours after it was found, for instance) |
Ah, I'm glad you noticed. That's why I don't use software state
machines for speed, and want to separate everything as hardware would.
It simplifies the design, makes it easier to read and debug, and makes
fixing and improving emulation far easier.
IRQ testing was the most extreme example. I spent a year and a half
fixing IRQ bugs while trying to optimize it with range testing.
Finally, I just gave up and made it test the position every single clock tick, and within two days it was working perfectly -- at the cost of a 40% speed hit.
But, you see the tradeoffs. Truth is, ZSNES v2.0 can probably get
90-95% as accurate without the tradeoffs, and unlike me they probably
have the expertise to still fix the bugs anyway.
Quote: |
or the catalyst that can bring about such a dramatic change in other emulators. |
Maybe ... maybe not. I saw nobody with a cycle-based processor emulator
before bsnes. Now all but SNES9x have them to an extent. But saying I'm
at all responsible is speculative at best, and narcissistic at worst.
Quote: |
IMO using these tables would not be a "true" hack since it is based directly on the hardware |
Do you want a 64k*64k*sizeof(uint16)*3*(96/2) table on your hard disk?
Then the hard drive would be the bottleneck for emulation. Easier to
just determine the algorithm and implement it.
Quote: |
Disheartened, after having achieved everything that was possible with what is available? |
Disheartened that I've reached a proverbial fork in the road.
Quote: |
bsnes doesn't have savestates either, and they aren't necessarily necessary. |
I agree, but it's a feature people want that I can't add, despite what some experts may think.
Quote: |
If
you want the emulated SPU to just sleep until the next time it has to
do something, consider that most operating systems will only let you
sleep for multiples of 50ms (20 sleeps per second), while a
cycle-accurate SNES SPU has to wake up and do things millions of times
a second. |
Again, I'm very impressed by Thristian. This is exactly the problem
I've encountered personally. Though I've only tested on a dual core CPU.
But even for the future, cothreads are unpopular for a reason: the
people in charge of design realize how difficult fast timing is, so
they preach that multithreaded apps should run each thread as long as
possible without syncing, and eschew that as "good design", and if you
have to sync more than 10k times/second, "you're doing something wrong"
(eg something they didn't account for with their limited ideas.)
I don't expect things to get much better. Even when we finally have 64
CPUs, I suspect timing between them will still incur massive penalties.
Even if I could sync with 100 times the speed of modern processors, by
then other apps will be multithreaded, more than one will be running,
and the overhead of that alone will still make using multiple threads
infeasible.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Oct 08, 2007 4:57 pm Post subject: |
|
byuu wrote: |
Quote: |
IMO using these tables would not be a "true" hack since it is based directly on the hardware |
Do you want a 64k*64k*sizeof(uint16)*3*(96/2) table on your hard disk?
Then the hard drive would be the bottleneck for emulation. Easier to
just determine the algorithm and implement it.
|
I'm sure for actual emulation it could be reduced to a few "areas" for
each value. Logging the data would probably be the main problem.
Eh, moot point anyway I guess.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 08, 2007 5:04 pm Post subject: |
|
And now my current thoughts ...
Again, I've reached a proverbial fork in the road. I was trying to stay
in the middle, but now I've gone as far as I could. Instead of picking
a path, I've come to a stop -- for about a year now. I've looked as far
as I could down both paths, without actually taking either. They both
look like dead ends.
To the left, I see myself competing more directly with other emulators,
something I don't want. But I see the program being more appealing to
others, which in itself is important -- more users means more bugs
uncovered. You saw the recent WWF bug, that lasted for weeks because I
lacked the userbase to find it faster. But ultimately I see myself
failing if I take this path ... frankly, other emulators are quite
simply better at it than I am, and also have more developers. I'll also
never reach 100% compatibility like that, which violates bsnes' raison
d'être.
To the right, I can keep chasing hardware accuracy. But I already know
that's impossible. Eventually, the emulator will become too slow for me
to continue, and it will die there.
I stick where I am, and no real progress will ever be made. Incremental
progress will mean small speed gains, but nothing miraculous. And once
it's optimized, I'm still stuck exactly where I am now.
blargg's suggestion is true, I really should stick with more of the
most optimal ways to reach the same accuracy I have now ... but I look
at past projects that did the best they could for their means, and I
see them either stuck where they are (SNES9x cannot fix current IRQ
bugs due to CPU limitations which cannot be overcome), or forced to
perform massive rewrites to add new functionality (ZSNES has still yet
to add blargg's DSP to an official release, and is now forced to
rewrite major portions of code to improve.) Whereas with my approach,
adding new things and fixing bugs was very trivial for me. I'm not sure
either will be true if I start clamping things down for raw speed.
Again, you all saw what happened when I tried speed optimizing IRQ
testing.
No matter which direction I take, none offer a great deal of longevity.
It's true, I can't maintain multiple emulators. And the comments in
response highlight the biggest problem: though everyone is happy for me
to do whatever I want, I don't really have a definitive path I want to
take. I see the advantages of all three approaches, but any of them
will alienate at least some people I have great respect for.
I think the best case scenario is if I can just come up with a simple
way to keep the old PPU in there somehow. Then I could stick to having
a release build with that enabled, and a developer build that uses the
new PPU.
This is still a major problem (I don't want two CPU cores), but not so
insurmountable as two completely separate emulators merged into one.
With the right #defines, I think I can manage this. But I simply have
to make a dual-purpose sCPU to proceed.
But I think I've spent enough time speculating the overhead of a cycle
accurate PPU, I'm going to actually implement it into bsnes as it
stands now, sans the actual emulation. That will fall back on the
existing PPU. The additional 20m context switches should simulate most
of the overhead.
Going forward, I think the best strategy is to split up the differing goals.
1) Fast, mostly compatible
2) Slow, fully compatible
3) Unusably slow, philosophically accurate
I can try harder to maintain 2 for now, but also work on 3 as I'd like.
I wish a new emulator could emerge to work on 1 with a fresh, clean
codebase that is heavily OOP -- I could volunteer time to work on that
when desired. But I suppose I can instead try and take a more active
role helping with other emulators if I want to work on that.
Suffice to say, 1 may be the best for general gaming, but I can't
compete against the heavy competition already there. And probably not
against 2 for long, either. 3 I think is my forte. Aside from anomie, I
don't know of anyone who's actually reverse engineering the hardware
itself still.
But I will have to set limits for myself on 3. Getting things too slow
would be too much. If I get 30fps with the new PPU, and still have my
old PPU to fall back on, I think that will give me the best compromise
to make everyone happy. And I'll be very happy to walk away. 100%
compatibility with none of the ppu.hack tricks will be a respectable
conclusion to my project.
I'll also hereby offer up my current codebase to anyone who wants to
try and maintain a 1 or 2 version of it. 1 would require forking as the
ideas are not compatible, 2 could go either way with forking not
preferred.
Of course, there's still that fun looming licensing choice. Hah, I don't even want to talk about that one anymore :P |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 08, 2007 6:45 pm Post subject: |
|
I would personally vote for taking path 3.
The reason is:
While walking down this path you will learn a lot more about the ppu,
and so will everyone else, by the time sPPU starts to to become stable
and usable pc's will be even faster than they are now, and if you
succeed in creating sPPU, at that point it should not be to hard to
take your finished bsnes and go over path2, optimising the emulator so
it can run on slower cpu's (even if it needs some tradeoffs here and
there)
This way you will have created the most accurate emulator possible with
current thinking/programming and future computers, and you will be able
to make a usable one after that. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 08, 2007 7:05 pm Post subject: |
|
Well, that was surprising ...
I tried adding a new empty cothread that does nothing but switch back
to the CPU immediately. I then switched to that every single IRQ tick
(~10.5MHz frequency). Since the old PPU was still rendering the frames,
most of the work was still being done, just more batched. This should
roughly simulate S-PPU contextual overhead for replacing the state
machine.
[Pentium IV 1.7GHz]
Before: 30fps normal / 86fps frameskip=9
After: 23fps normal / 45fps frameskip=9
I expected to get a lot less than 15fps. But this result makes sense,
too. You'll recall I tested the overhead of 10m context switches alone.
It took roughly one second to complete. So if that alone takes a full
second, that leaves virtually zero time left for actual emulation.
Now, assuming I was getting 60fps exactly, then this would cut speed in
half to 30fps. One second to do 10m context switches, and one second to
do 60 frames = 30fps.
But because I'm already getting 30fps, then one frame equals two
seconds. That combined with 10m context switches equals three seconds.
30 * .667 = ~20, very close to 23fps.
Keep in mind that frameskipping as it stands now completely skips PPU
rendering. I won't have that as an option, so we can assume the speed
hit will be roughly 30-40%, in the absolute best case scenario. I think
the impact will be a bit more severe on Core 2 Duos, though. I'll post
a WIP sometime soon so we can get more before->after comparisons.
More than likely, it will probably be a lot slower, 40-80% slower. But
if I'm lucky, an overclocked Core 2 could reach full speed.
And then, like tetsuo said, we can go back and convert all of bsnes'
findings to an enslavement / state machine model.
I still wonder what most would think, since a scanline renderer is
technically fully sufficient for all but two games that have nothing
but one black line on the title screens. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 08, 2007 7:56 pm Post subject: |
|
byuu wrote: |
Quote: |
What aspects are you really interested in? |
The PPU. I know it's nightmarishly complex, but it sounds like the last
frontier, so to speak. I am happy with modern CPU, SMP and DSP
emulation.
|
then you should definately look into that
byuu wrote: |
Quote: |
bsnes doesn't have savestates either, and they aren't necessarily necessary. |
I agree, but it's a feature people want that I can't add, despite what some experts may think.
|
yeah but one step at a time right?
ultimately to me bsnes has always been slower on my system, but you
have strict quality control guidelines to set it apart. I think path 3
is the most relevant to bsnes, because like you said it's really what
makes it unique and what you are good at. sure everyone wants features
and speed, but I mean that isn't a rare quantity.
I'll be looking forward to seeing bsnes develope more, even if it isn't
a huge difference in the emu overall at first glance, I just like
reading the developement here. So by all means continue your work on
the PPU, optimize the code more, and perhaps here and there work on
some modest features or your UI.
having a larger user base has it's pros and cons, sure it may take a
little longer to find bugs with our current size, but from what I've
seen you have some serious bug hounds here, and I think the quality of
testing there is MUCH higher than 1000s of incoming questions from
users who have no idea how to use the emu and 3 times out of 5 are
suffering from user error not an emulation bug.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Oct 08, 2007 9:26 pm Post subject: |
|
byuu wrote: |
Well, that was surprising ...
I tried adding a new empty cothread that does nothing but switch back
to the CPU immediately. I then switched to that every single IRQ tick
(~10.5MHz frequency). Since the old PPU was still rendering the frames,
most of the work was still being done, just more batched. This should
roughly simulate S-PPU contextual overhead for replacing the state
machine.
[Pentium IV 1.7GHz]
Before: 30fps normal / 86fps frameskip=9
After: 23fps normal / 45fps frameskip=9
I expected to get a lot less than 15fps. But this result makes sense,
too. You'll recall I tested the overhead of 10m context switches alone.
It took roughly one second to complete. So if that alone takes a full
second, that leaves virtually zero time left for actual emulation.
Now, assuming I was getting 60fps exactly, then this would cut speed in
half to 30fps. One second to do 10m context switches, and one second to
do 60 frames = 30fps.
But because I'm already getting 30fps, then one frame equals two
seconds. That combined with 10m context switches equals three seconds.
30 * .667 = ~20, very close to 23fps.
Keep in mind that frameskipping as it stands now completely skips PPU
rendering. I won't have that as an option, so we can assume the speed
hit will be roughly 30-40%, in the absolute best case scenario. I think
the impact will be a bit more severe on Core 2 Duos, though. I'll post
a WIP sometime soon so we can get more before->after comparisons.
More than likely, it will probably be a lot slower, 40-80% slower. But
if I'm lucky, an overclocked Core 2 could reach full speed. |
Whoo! Promising news!
Quote: |
And then, like tetsuo said, we can go back and convert all of bsnes' findings to an enslavement / state machine model.
I still wonder what most would think, since a scanline renderer is
technically fully sufficient for all but two games that have nothing
but one black line on the title screens. |
Should come as no suprises, but definitely in favor.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 08, 2007 10:56 pm Post subject: |
|
I
think blargg asked this earlier, but maybe if I go over it in more
detail, a programmer here could think of something clever. Okay, here's
the PPU problem:
On real hardware, the PPU
contains the vertical and horizontal counters. It communicates by way
of the Vblank and Hblank pins that go from it to the CPU. The CPU
notices when these pins change, and keeps its own internal counters. It
keeps them synchronized by the pulse from the PPU pins. Pin.H 1->0
resets CPU Hcounter, Pin.V 1->0 resets CPU Vcounter. By this
mechanism, the CPU can trigger both NMIs (at the start of Vblank) and
IRQs (via programmable Vtime and Htime registers.)
There are two PPU registers that can manipulate the Vcounter / Hcounter
values. The first is overscan, this can change whether Pin.V goes high
at line 225 or at line 240. The second is interlace which, when
enabled, can actually enable a new line, line 262, each alternating
frame. These two registers can be written at any time. This is what
makes prediction of future Vcounter / Hcounter values difficult.
The current trick I use is to put the Vcounter / Hcounter values inside
the CPU. The CPU polls the PPU registers whenever a scanline has
completed (eg 1364 cycles have passed.) The CPU also asks the PPU to
render one scanline when this occurs. Through this means, the CPU
itself increments the Hcounter by two ticks at a time, as a result of
CPU opcodes / DMA executing.
To get a cycle accurate PPU, the PPU will obviously need the realtime
counter positions. It's also more like hardware to put the counters in
the right chip. The cheap way would be to keep two full sets of
counters, but this causes serious headaches trying to keep the two
separate counters synchronized. Ideally, the counters would be in the
PPU, and the CPU would strobe the realtime status of the counters at
~10.5MHz.
With the latter model, the CPU cannot run ahead of the PPU because then
the V/H pins will get out of sync and NMI / IRQs will fire at the wrong
times. The PPU can only run ahead of the CPU until it needs to access
$2100 - $213f (read or write). It then has to let the CPU catch up, in
case the CPU were to modify one of these registers in some way. This
probably happens at least once per dot, so there isn't a lot of leg
room to run far ahead with either processor. That means, worst case
scenario, 20M context switches a second.
Aside from the cheap hack of keeping two full sets of counters, and
preferrably having only one counter in the PPU ... does anyone have any
ideas to pull this off faster than keeping the CPU and PPU perfectly
aligned at ~10.5MHz? The less hackish the better.
Keeping them completely
separate means that it will be technically possible to overclock just
the CPU or the PPU independently, without breaking games. That in
itself could be a really neat feature. But if necessary, I'll be okay
with relying on the fact that the PPU and CPU run off the same ~21MHz
clock and need to tick at ~10.5MHz precision.
I need one
model that will work for both types of PPUs, but I want to preserve the
speed of the former model if at all possible. If possible, then I can
make the two separate PPUs a compile-time option, and I won't need to
fork the CPUs as well. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 09, 2007 1:56 am Post subject: |
|
byuu wrote: |
But I see the program being more appealing to others, which in itself
is important -- more users means more bugs uncovered. |
That's the benefit to having more users? Here's one that I thought of:
more people enjoying SNES games. Games that sound better and don't have
a 20% chance of of breaking somewhere along the line. There are
hundreds of bugs in those emulators. Let's use an example:
User A wants to play "Der Langrisser" on his a 1.6ghz athlon has three options under your model:
1. A fast emulator that by your accounts "does better than you" and sporadically crashes.
2. Current version of bsnes that isn't fast enough due to self-documentation.
3. Future version of bsnes that isn't fast enough due to self-documentation.
Quote: |
To
the right, I can keep chasing hardware accuracy. But I already know
that's impossible. Eventually, the emulator will become too slow for me
to continue, and it will die there. |
No argument from me here.
Quote: |
I
stick where I am, and no real progress will ever be made. Incremental
progress will mean small speed gains, but nothing miraculous. And once
it's optimized, I'm still stuck exactly where I am now. |
Stuck with a 2x faster version at 100% compatibility with a highly
increased chance of SuperFX and SA1 becoming playable? Is that a bad
situation to be "stuck" in?
Quote: |
but
I look at past projects that did the best they could for their means,
and I see them either stuck where they are (SNES9x cannot fix current
IRQ bugs due to CPU limitations which cannot be overcome), or forced to
perform massive rewrites to add new functionality (ZSNES has still yet
to add blargg's DSP to an official release, and is now forced to
rewrite major portions of code to improve.) Whereas with my approach,
adding new things and fixing bugs was very trivial for me. I'm not sure
either will be true if I start clamping things down for raw speed. |
Again, clamping down on near perfection is not analogous to ten year
old emulators having major code issues. What are you afraid you won't
be able to add or fix? I don't get it. Lots of great special chip games
can't even be played right now. If TG3K is not worth spending time on
due to its quality as a game, how is a minor gfx glitch in Adventures
of Dr Franken worth spending months on? Simply by virtue of it being
related to the base hardware?
Quote: |
No matter which direction I take, none offer a great deal of longevity. |
If it's a matter of you being more concerned with the hardware, then
that's fine and easy to accept, but I just think you're wrong in your
attempt to rationalize against #1 on the basis of its potential
offerings vs existing options. I do wish you luck with the PPU, though,
and hopefully something miraculous happens where either blargg does #1,
or the PPU is easier than expected.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 09, 2007 3:13 am Post subject: |
|
Quote: |
1. A fast emulator that by your accounts "does better than you" and sporadically crashes. |
Well, I was meaning in general. One could add savestates, SFX and SA-1
easily to a fast emulator. Obviously, that has its problem games.
Quote: |
Stuck
with a 2x faster version at 100% compatibility with a highly increased
chance of SuperFX and SA1 becoming playable? Is that a bad situation to
be "stuck" in? |
Really, the best I can do to optimize the code I have now is to
optimize IRQ testing. That's a 40% speedup. I've gone over how badly
I've failed at that already.
The only thing that leaves at present is to add enslavement. That means
reverting all the way back to v0.016's state machine hell, and would
gain about a 20% speedup (mostly from SMP<>DSP, not from
CPU<>SMP), but would cause some problematic scenarios (such as
the infamous ten-frame DMA edge case).
And the the other 30-40% would be if
I got lucky and PGO worked again. But you can't blame me ... my code
gives no warnings or errors, Visual C++'s PGO is just busted. The
technology is too new for such a huge project.
Anyway, I would ideally like to keep the current PPU around as well, if
possible. See my last post. That leaves in the first and third
optimizations above as still something that might be possible again in
the future.
Quote: |
If
TG3K is not worth spending time on due to its quality as a game, how is
a minor gfx glitch in Adventures of Dr Franken worth spending months on? |
I actually have no interest in Dr Franken at all. I'm honestly more
interested in tapping the potential of the S-PPU. For example, it may
be possible to switch video modes mid-scanline. Imagine a puzzle game
... mode 1 on the left, mode 7 on the right. This one's really about
the fact that if I don't figure this stuff out now, it'll likely never
be figured out. I see absolutely no one interested in this but me.
Quote: |
but
I just think you're wrong in your attempt to rationalize against #1 on
the basis of its potential offerings vs existing options. |
By #1 I was referring to adding new hacks to speed up emulation. I
honestly don't know of any areas I can remove support from to speed up
emulation, without breaking at least one game. Maybe DMA bus sync, but
that doesn't slow emulation down anyway. The rest is pretty much all
necessary, especially the IRQ stuff. We have a huge list of games that
are really, really finicky about that being absolutely perfect.
It seems you're against #1 as well, per my first quote from you above.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Oct 09, 2007 3:44 am Post subject: |
|
FitzRoy wrote: |
Stuck with a 2x faster version at 100% compatibility with a highly
increased chance of SuperFX and SA1 becoming playable? Is that a bad
situation to be "stuck" in?
If TG3K is not worth spending time on due to its quality as a game, how
is a minor gfx glitch in Adventures of Dr Franken worth spending months
on? Simply by virtue of it being related to the base hardware?
|
since when has there been a highly increased chance of SFX and SA-1 emulation in bsnes?
I don't know, I think all bugs no matter how insignificant the game are
worth squelching, not only to fix the game but to ensure the entire
system is correct.
this seems to have always been the aim of bsnes, to not comprimise on these areas where other emus do.
I dunno... that's just the way I've seen it, I don't see it as a fork,
but simply continuing on the path and in the niche bsnes always has
been, why change now? It's always been this way.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 09, 2007 3:45 am Post subject: |
|
FitzRoy: as I said before I don't believe in a software-centric view of emulation but I do acknowledge that many people are. I don't think it's an invalid pov, just a different one.
But there's still one thing that's counter-intuitive here:
On one hand you praise and love bsnes for it's non-existant (last we
checked) bugs , on the other one you seem to be against a (more)
hardware-centric model of emulation...the very same model that is responsible for bringing you this bug free emulator in the first place It's a contradiction imo.
byuu may correct me if I'm wrong but all those things: absense of game
bugs, the possibility of fixing bugs extremely rapidly...were made
possible because
byuu chose a more hardware centric model of emulation...Not because he
is more "relentless toward bugs". Put him behind Zsnes and he probably
wouldn't have an easier time fixing bugs.
And now
you're basically saying: "Ok, we've reached a point where we have no
bugs, and the emulator is fast enough so that we can enjoy it; let's
basically stop here, or at least, let's not make changes that wouldn't
impact on compatibility or playability in any meaningful ways (such as
the dot-based renderer)"
The last thing I want to do is start an argument or flamme war, but I do disagree.
Last edited by Snark on Tue Oct 09, 2007 3:55 am; edited 2 times in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 09, 2007 3:52 am Post subject: |
|
byuu wrote: |
Really, the best I can do to optimize the code I have now is to
optimize IRQ testing. That's a 40% speedup. I've gone over how badly
I've failed at that already.e
The only thing that leaves at present is to add enslavement. That means
reverting all the way back to v0.016's state machine hell, and would
gain about a 20% speedup (mostly from SMP<>DSP, not from
CPU<>SMP), but would cause some problematic scenarios (such as
the infamous ten-frame DMA edge case).
|
Okay, so that's a potential 60%, but you suspect it might break some games. There were,
however, some serious timing errors in bsnes at the time range-testing
was used that were discovered long after its removal. The MKII issue
was one of them. Maybe those were the true culprit for those bugs and
that the range-testing implementation was sound. Really the only way to
find out would be to try doing this again, and I realize you've said
before that the code has changed so much since then that it's no longer
possible to just cut and paste the old code - it has to get rewritten
to test if this is true.
I don't know how many
bugs enslavement would create, but I remember you saying that one of
them shouldn't create any, and that it simply went against your
philosophy of trying to model a real SNES.
If it is inherently impossible to get perfect compatibility with opcode
cores, then I think cycle is here to stay. It's really a damn shame
about the C++ PGO, that is such a monstrous free speed-up.
byuu wrote: |
I
actually have no interest in Dr Franken at all. I'm honestly more
interested in tapping the potential of the S-PPU. For example, it may
be possible to switch video modes mid-scanline. Imagine a puzzle game
... mode 1 on the left, mode 7 on the right. This one's really about
the fact that if I don't figure this stuff out now, it'll likely never
be figured out. I see absolutely no one interested in this but me. |
Maybe it's because nobody makes SNES games anymore, and SNES homebrew
is non-existent in light of faster, more popular, and easier platforms
on which to develop?
Snark wrote: |
On
one hand you praise and love bsnes for it's non-existant (last we
checked) bugs , on the other one you seem to be against a (more)
hardware-centric model of emulation...the very same model that is responsible for bringing you this bug free emulator in the first place It's a contradiction imo.
|
No, I'm not contradicting myself. I actually thought I was really clear
about my conditional stance on accuracy, even going so far as to
explain what I thought about hacks. I can't really say it again any
better.
Quote: |
since when has there been a highly increased chance of SFX and SA-1 emulation in bsnes? |
Correct me if I'm wrong, byuu, but won't these chips need a
ridiculously more powerful system to run with a dot-based renderer, or
does the overhead stay the same no matter what changes you make to the
cores?
In other words, my thinking was that if bsnes were sped up by 100%, a
customized implementation of these chips might become feasible at 60fps
on a 3ghz penryn, maybe less.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Oct 09, 2007 8:07 am Post subject: |
|
If
I'm not mistaken it's more of a choice between the special chips and
the PPU with added overhead potentially being about the same. However
as byuu is far more interested in figuring out the PPU than in writing
a custom implementation of complex and imperfectly emulated chips, the
PPU gets precedence. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Oct 09, 2007 11:43 am Post subject: |
|
I
was wondering, byuu, would you consider it an option to split the CPU
and PPU into seperate functions/objects while keeping them in the same
thread? Although less modular and versatile, this would I imagine cut
down on overhead significantly by avoiding context switches. I made
some mock-ups to illustrate how this could work without too much
overhead, though there are probably a hundred details
(threading-related or not) I'm missing:
Code: |
typedef void* (*Ptr)(CPUVars, PPUVars);
Thread(){
CPUVars CPU; //stores the CPU variables
PPUVars PPU; //stores the PPU variables
Ptr CPPUPtr = NULL;
CPPUPtr = (Ptr)&CPUFunc;
while(CPPUPtr) CPPUPtr = (Ptr)CPPUPtr(CPU, PPU);
}
//example function definitions:
void* CPUFunc(CPUVars, PPUVars){
Ptr thePtr = &CPUFunc;
do stuff;
if(need to synchronise with PPU) thePtr = &PPUFunc;
if(need to synchronise with other component) thePtr = NULL;
return (void*)thePtr;
}
void* PPUFunc(CPUVars, PPUVars){
Ptr thePtr = &PPUFunc;
do stuff;
if(need to synchronise with CPU) thePtr = &CPUFunc;
else if(need to synchronise with other component) thePtr = NULL;
return (void*)thePtr;
}
//note that calling a cast function pointer isn't technically standard C++..
//the cast itself is, however, and it should work correctly on most if not all
//compilers
|
Or alternatively (less hackish and more object-oriented):
Code: |
struct bCPU;
struct bPPU;
struct CPPU{
virtual void access(bCPU&, bPPU&, CPPU*&) = 0;
};
struct bCPU : CPPU{
void access(bCPU& CPU, bPPU& PPU, CPPU*& Ptr);
};
struct bPPU : CPPU{
void access(bCPU& CPU, bPPU& PPU, CPPU*& Ptr);
};
Thread(){
bCPU CPU;
bPPU PPU;
CPPU *CPPUPtr = &CPU;
while(CPPUPtr) CPPUPtr->access(CPU, PPU, CPPUPtr);
}
//example function definitions:
void bCPU::access(bCPU& CPU, bPPU& PPU, CPPU*& Ptr){
do stuff;
if(need to synchronise with CPU) Ptr = &PPU;
else if(need to synchronise with other component) Ptr = NULL;
}
void bPPU::access(bCPU& CPU, bPPU& PPU, CPPU*& Ptr){
do stuff;
if(need to synchronise with CPU) Ptr = &CPU;
else if(need to synchronise with other component) Ptr = NULL;
}
|
(note both of these should be considered pseudo-code, though they're mostly valid C++ as that's how I tested them)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 09, 2007 1:08 pm Post subject: |
|
Verdauga Greeneyes wrote: |
If
I'm not mistaken it's more of a choice between the special chips and
the PPU with added overhead potentially being about the same. However
as byuu is far more interested in figuring out the PPU than in writing
a custom implementation of complex and imperfectly emulated chips, the
PPU gets precedence. |
Well, one thing is for sure. If it is about the games, then research
improving Star Fox and SMW2 is more important than research affecting
The Adventures of Dr. Franken, and while sPPU will slow down all games
including special chip ones, special chip implementations afflict
nothing. That's really all I was trying to get across.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Oct 09, 2007 2:34 pm Post subject: |
|
FitzRoy wrote: |
Verdauga Greeneyes wrote: |
If
I'm not mistaken it's more of a choice between the special chips and
the PPU with added overhead potentially being about the same. However
as byuu is far more interested in figuring out the PPU than in writing
a custom implementation of complex and imperfectly emulated chips, the
PPU gets precedence. |
Well, one thing is for sure. If it is about the games, then research
improving Star Fox and SMW2 is more important than research affecting
The Adventures of Dr. Franken, and while sPPU will slow down all games
including special chip ones, special chip implementations afflict
nothing. That's really all I was trying to get across.
|
But we've been told more than once not to wait up for implementation of these chips. I don't understand...
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Oct 09, 2007 3:29 pm Post subject: |
|
Maybe it's time to stop waiting for nobody and figure it out us self.
I mean, that patent gotta be of some help to write a proper c++ core. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 09, 2007 5:28 pm Post subject: |
|
Ok, following blargg's advice on other issues in the past, I've isolated the PPU problem to a separate program.
Below is a minimal C++ app that implements both types of PPU timing
systems, bCPU/bPPU is the current design, sCPU/sPPU is my preferred
future design. The latter has about 3.5x overhead right now. What
that'll translate to in bsnes, I have no idea.
http://www.geocities.com/byuu64/pputest.zip
What I'm looking for is a way to use the same timing model for the
vcounter / hcounter in both bCPU and sCPU. I want to have only one CPU
core, yet have both the fast and accurate PPU cores separate.
Quote: |
Maybe it's time to stop waiting for nobody and figure it out us self. |
By all means, I'd love that. The code is available. Get SA-1 or SuperFX
working, and I'll be happy to merge in your changes.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 09, 2007 9:03 pm Post subject: |
|
I'll
start implementing the bounty system. I have $100 for a C++
implementation of SuperFX and $100 for the same on SA1. The only
requirement I have is that it be totally open source and it must also
must result in emulation at least at good as what is currently in other
emulators. Also, you should post your intent to go for something so
that multiple people are not working on the same thing.
I then have $200 to whoever cracks the SPC7110 algorithm.
Anyone who wants to add to these let me know. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 09, 2007 10:04 pm Post subject: |
|
I'm
okay with this if you want to pay others to donate code, that's your
decision to make. Just please make it very clear that I'm not involved
with the money in any way. I'm neither offering money nor accepting
money, by any means. I don't want any part in that for personal ethical
reasons.
I recommend putting the bounty stuff on
the first post as well. Also, I'll require dual copyright assignment on
any code donated to me, unless it is licensed under BSDL, ISC or public
domain. As it's dual licensed, it can also be released by the author
under any license they choose.
As a single person, I will have great difficulty merging large patches
of code; so please, anyone working on this, try not to change my code
except where absolutely required. Code all you want inside
src/chip/<chipname>, that's fine by me.
FitzRoy, since you're so serious about this, I'll start working on a
SuperFX skeleton this week. I think SuperFX is the best first choice,
since it's more separate from the S-CPU, and people seem to like
SMW2+StarFox more than Mario RPG+Kirby 3.
Since you're paying, you should also set some requirements of what you
want. Do you expect every game to run correctly, most to run correctly,
or just the bare minimum to get in-game on a few titles? Do you care if
the implementation uses an opcode-based core, a cycle-core, or better?
I don't personally care, myself. None of the other special chips are
very accurate either, they're there just to get the games playable and
not much else. Opcode core would obviously be the fastest. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Oct 09, 2007 11:10 pm Post subject: |
|
byuu wrote: |
Since you're paying, you should also set some requirements of what you
want. Do you expect every game to run correctly, most to run correctly,
or just the bare minimum to get in-game on a few titles? Do you care if
the implementation uses an opcode-based core, a cycle-core, or better?
I don't personally care, myself. None of the other special chips are
very accurate either, they're there just to get the games playable and
not much else. Opcode core would obviously be the fastest. |
Playability and a starting point for future improvements in C++ and not
some other language is all that matters right now. Nothing higher than
cycle, but opcode is probably ideal and likely what you're using for
DSP1, right? As long as the games work as well or better than ZSNES,
then the money will be awarded.
I appreciate you doing what needs to be done to add them in if someone
does submit something. I know $100 is kind of paltry for the amount of
work involved, but I'm hoping others will want it too and add to my
pledge. It's important to start generating more interest in this
research again. It's also better to give these chips a core like bsnes'
so that we know what bugs are from the chip emulation. I suspect that
many of the bugs in ZSNES special chip games aren't always because of
incomplete chip emulation.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 09, 2007 11:38 pm Post subject: |
|
Yeah,
$100 for the SuperFX isn't much at all, sadly ... I was looking at the
specifics of the chip, and wow. It's pipelining actually executes the
next instruction after the current instruction, even if the current one
is a branch. And it has really wild math if it has to read two bytes
forward. Looks like a real bitch to support properly.
Anyway, another good bounty would be to try and optimize the IRQ
testing to use range testing again. That would give at least a 30-40%
speed boost. I could supply test ROMs that are required to pass.
The current code looks like this:
Code: |
void sCPU::add_clocks(uint clocks) {
if(status.dram_refreshed == false) {
if(status.hclock + clocks >= status.dram_refresh_position) {
status.dram_refreshed = true;
clocks += 40;
}
}
counter.sub(counter.irq_delay, clocks);
scheduler.addclocks_cpu(clocks);
//this is what we ideally want to get rid of ...
//call poll_interrupts(clocks) to test if an IRQ fires between
//the current counter position and counter+clocks-2
clocks >>= 1;
while(clocks--) {
status.hclock += 2;
if(status.hclock >= status.line_clocks) { scanline(); }
poll_interrupts();
}
} |
Code: |
void sCPU::poll_interrupts() {
uint vpos = status.vcounter, hpos = status.hclock;
//NMI test
timeshift_backward(2, vpos, hpos);
bool nmi_valid = (vpos >= status.vnmi_trigger_pos);
if(status.nmi_valid == false && nmi_valid == true) {
//0->1 edge sensitive transition
status.nmi_line = true;
counter.nmi_hold = 6;
} else if(status.nmi_valid == true && nmi_valid == false) {
//1->0 edge sensitive transition
status.nmi_line = false;
}
status.nmi_valid = nmi_valid;
//NMI hold
if(counter.nmi_hold) {
counter.nmi_hold -= 2;
if(counter.nmi_hold == 0) {
if(status.nmi_enabled == true) { status.nmi_transition = true; }
}
}
//IRQ test
timeshift_backward(8, vpos, hpos);
bool irq_valid = (status.virq_enabled == true || status.hirq_enabled == true);
if(irq_valid == true) {
if(status.virq_enabled == true && vpos != status.virq_trigger_pos) { irq_valid = false; }
if(status.hirq_enabled == true && hpos != status.hirq_trigger_pos) { irq_valid = false; }
}
if(status.irq_valid == false && irq_valid == true) {
//0->1 edge sensitive transition
status.irq_line = true;
counter.irq_hold = 6;
}
status.irq_valid = irq_valid;
//IRQ hold
if(counter.irq_hold) { counter.irq_hold -= 2; }
if(status.irq_line == true && counter.irq_hold == 0) {
if(status.virq_enabled == true || status.hirq_enabled == true) { status.irq_transition = true; }
}
} |
Code: |
void sCPU::timeshift_backward(uint clocks, uint &vtime, uint &htime) {
if(htime >= clocks) {
htime -= clocks;
} else {
htime += status.prev_line_clocks - clocks;
if(vtime > 0) {
vtime--;
} else {
vtime = status.prev_field_lines - 1;
}
}
} |
... of course, someone doing it for free would be really nice, too ;)
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Oct 10, 2007 12:50 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
I
actually have no interest in Dr Franken at all. I'm honestly more
interested in tapping the potential of the S-PPU. For example, it may
be possible to switch video modes mid-scanline. Imagine a puzzle game
... mode 1 on the left, mode 7 on the right. This one's really about
the fact that if I don't figure this stuff out now, it'll likely never
be figured out. I see absolutely no one interested in this but me. |
Maybe it's because nobody makes SNES games anymore, and SNES homebrew
is non-existent in light of faster, more popular, and easier platforms
on which to develop?
|
And yet they make games on slower, harder platforms.
The fucking 2600 has one of the liveliest console homebrew communities around.
That's a system with 2 "player" sprites, 1 "missile" half-sprite, and 256 bytes of RAM. BYTES, people!
Programming anything more complex than Combat relies almost exclusively
on exploiting quirks and bugs in the chipset.
And it has more homebrews than the NES, SNES, and Genesis COMBINED.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 10, 2007 1:32 am Post subject: |
|
Gil_Hamilton wrote: |
FitzRoy wrote: |
byuu wrote: |
I
actually have no interest in Dr Franken at all. I'm honestly more
interested in tapping the potential of the S-PPU. For example, it may
be possible to switch video modes mid-scanline. Imagine a puzzle game
... mode 1 on the left, mode 7 on the right. This one's really about
the fact that if I don't figure this stuff out now, it'll likely never
be figured out. I see absolutely no one interested in this but me. |
Maybe it's because nobody makes SNES games anymore, and SNES homebrew
is non-existent in light of faster, more popular, and easier platforms
on which to develop?
|
And yet they make games on slower, harder platforms.
The fucking 2600 has one of the liveliest console homebrew communities around.
That's a system with 2 "player" sprites, 1 "missile" half-sprite, and 256 bytes of RAM. BYTES, people!
Programming anything more complex than Combat relies almost exclusively
on exploiting quirks and bugs in the chipset.
And it has more homebrews than the NES, SNES, and Genesis COMBINED.
|
I guess what I meant to say by faster is that a game with the same
level of complexity as the SNES developed today would be far more
lucrative on a PC than bsnes @ 10fps on a 3ghz Core 2 Duo.
I think there is also something easier about drawing and animating for
something with such limited capabilities that makes the 2600 a good
choice for some developers. You don't have to be a great artist,
animator, or sound technician to make something comparable to licensed
2600 games, thats for sure.
Ah, here's a better quote than I can give you:
Quote: |
"All of this extreme, stripped-down simplicity does have one benefit:
making a game can be a one-person effort. "Game development projects
for old machines can be done by single developers, while modern game
systems require a lot more manpower, if you want to make
state-of-the-art games for these platforms," says Quernhorst." It's
almost impossible for a single person to create a cool game on a modern
platform. It's easier to develop cool games for the ancient machines
due to their limitations." |
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Oct 10, 2007 3:44 am Post subject: |
|
FitzRoy wrote: |
Gil_Hamilton wrote: |
FitzRoy wrote: |
byuu wrote: |
I
actually have no interest in Dr Franken at all. I'm honestly more
interested in tapping the potential of the S-PPU. For example, it may
be possible to switch video modes mid-scanline. Imagine a puzzle game
... mode 1 on the left, mode 7 on the right. This one's really about
the fact that if I don't figure this stuff out now, it'll likely never
be figured out. I see absolutely no one interested in this but me. |
Maybe it's because nobody makes SNES games anymore, and SNES homebrew
is non-existent in light of faster, more popular, and easier platforms
on which to develop?
|
And yet they make games on slower, harder platforms.
The fucking 2600 has one of the liveliest console homebrew communities around.
That's a system with 2 "player" sprites, 1 "missile" half-sprite, and 256 bytes of RAM. BYTES, people!
Programming anything more complex than Combat relies almost exclusively
on exploiting quirks and bugs in the chipset.
And it has more homebrews than the NES, SNES, and Genesis COMBINED.
|
I guess what I meant to say by faster is that a game with the same
level of complexity as the SNES developed today would be far more
lucrative on a PC than bsnes @ 10fps on a 3ghz Core 2 Duo.
I think there is also something easier about drawing and animating for
something with such limited capabilities that makes the 2600 a good
choice for some developers. You don't have to be a great artist,
animator, or sound technician to make something comparable to licensed
2600 games, thats for sure.
Ah, here's a better quote than I can give you:
Quote: |
"All of this extreme, stripped-down simplicity does have one benefit:
making a game can be a one-person effort. "Game development projects
for old machines can be done by single developers, while modern game
systems require a lot more manpower, if you want to make
state-of-the-art games for these platforms," says Quernhorst." It's
almost impossible for a single person to create a cool game on a modern
platform. It's easier to develop cool games for the ancient machines
due to their limitations." |
|
Any context for that quote? I've seen "old machines" Applied to the PS1 era.
Not to mention that I find it absurd. There's a big difference between
pushing the system to it's limits and making a good game.
There were commercial-quality 1-person efforts even on the PS.
Hell, there's a psp version of Every Extend. It's still QUITE possible for one person to make a good game.
They just usually stick to PC development. Probably because it's the easiest thing to get your code running on.
Speaking of the PS1....
I think the intentional crippling and subsequent execution of the
NetYaroze was one of the greatest tragedies of modern gaming.
The original concept of giving the masses access to a complete and
fully-functional dev kit was an incredible idea. Making it
limited-availability, horribly crippled, and bound in heavy legal tape
was NOT.
I think the 2600 gets the attention because of the generation that's attached to it.
That was the era of the home computer. Programming was "cool." Doing it yourself was something to be proud of.
The generation around the SNES was more about pre-packaged fun.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed Oct 10, 2007 4:48 am Post subject: |
|
Part
of it also is that while there's a fairly large amount of pain involved
in bringing stuff up on *any* console, you get more love doing it on
something limited. There's lots of old 6502 dogs around (myself
included) that'll still wag our tails when something like the C64
conversion of Desert Dream or wAMMA's recent 2600 demo shows up 
Regarding the custom chips: we've recently noticed on MAME that Seta
made at least 3 arcade Shogi games using an NEC V810 as a coprocessor
to calculate the AI. And yes, that's *all* it does. Moreover, the
V810's program is largely identical across the games. So there's been
some speculation that the ST-0018 might just be that same V810 again. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 10, 2007 5:30 am Post subject: |
|
Ok, I've posted a new beta.
The video settings are now saved based on the current video mode. This
means you can set a larger multiplier in pseudo-fullscreen mode, and
switch back to windowed mode without having to reduce the multiplier
again. It's quite nice.
I also found an old variable I had lying around,
video<.mode>.synchronize. Set it to true and it will prevent
tearing completely in both windowed and pseudo-fullscreen mode, by
syncing to the vertical retrace. Yes, it'll distort the sound. You'll
want to mute sound and turn off speed regulation if you use it. Edit it
from the advanced panel only.
I'm honestly starting to think that if we can get audio syncing working
with this, then I can just add a special modeline in the advanced panel
to set an actual video mode for the purists. No need for three video
modes.
Also, more or less importantly, I've added detection for the SuperFX,
SA-1, ST011 and ST018 chips. ST011 support isn't working yet, because
they share the same mapper and ROM type. I'd appreciate if everyone
would test the rest and report any problems.
bsnes now gives a message box warning whenever you load a game with one
of the above unsupported special chips. Should be nice for end users
who don't know I don't support those chips, at least.
And speaking of the ST018 ...
Quote: |
Regarding
the custom chips: we've recently noticed on MAME that Seta made at
least 3 arcade Shogi games using an NEC V810 as a coprocessor to
calculate the AI. And yes, that's *all* it does. Moreover, the V810's
program is largely identical across the games. So there's been some
speculation that the ST-0018 might just be that same V810 again. |
This sounds very interesting. If you're interested in pursuing this
further, let me know. I'd be very interested in trying to implement
this into bsnes. If I succeed, I'll release my work as PD so it can be
used in MESS, etc.
If you have a picture of the V810 on any of these Shogi games, I can
compare the package size and pin count to the ST018. Not a fool proof
method, but better than nothing.
EDIT: ST018 is a 40x4 pin square surface mount IC, whereas the NEC V810
is a 30x4 pin square surface mount IC. Unlikely they're the exact same thing ... but if we're lucky, it's just the V810 + extra controller stuff to interface with the SNES CPU.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 10, 2007 6:07 am Post subject: |
|
on
the topic of homebrew, I believe there are several reasons. Firstly I
may be wrong in saying this, but I believe that the 16 bit era consoles
were the second most convoluted to make a game for (the most being the
32 bit era) and the work and resources required to make a good SNES
game are far greater than making your own atari game, it's more
complex, and there is a lot more artwork involved.
as it's been said before, it'd be easier to just make that kind of
stuff on a computer, or if you aren't savvy, with the aid of some sort
of game making program.
there is a HUGE community based around rom hacking though and some
hacks really go way out of the bounds of the original game that you
might almost consider them their own game.
I think it's important that these hacks be made to work under the
constraints of the real hardware though, because if you're cheating you
might as well make it for the PC where the limits are only your own rig.
so while there may not be a ton of homebrew because people are either
doing it on 1) older systems 2) frontier newer systems, or 3) PCs, I
still think that the romhacking/translation crowd is more that enough
of a reason.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
PiCiJi Rookie
Joined: 30 Dec 2005
Posts: 15
|
Posted: Wed Oct 10, 2007 12:37 pm Post subject: |
|
couldn't find anything in bsnes source about emulating a 2-stage pipeline other than last_cycle.
Western design center told me, the 65C02 has the same pipline approach
like the 65C816. The 65C02 has a simple 2-stage pipeline, means it's
not possible to make 2 read/write actions at the same time but if the
last cycle of an instruction is a i/o cycle the next opcode will be
fetched at the same time. Has anyone additional knowledge? |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Oct 10, 2007 2:29 pm Post subject: |
|
I guess I don't get a buck for finding that patent link, right? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 10, 2007 3:17 pm Post subject: |
|
PiCiJi wrote: |
couldn't find anything in bsnes source about emulating a 2-stage pipeline other than last_cycle. |
I've wanted to emulate that more directly for a long time, but that's a really tough thing to do in C++.
But yes, last_cycle fully emulates the only observable effect of the
two-stage pipeline ... IRQ trigger testing occurs one cycle before the
end of each opcode, hence, last_cycle.
I haven't heard about the memory fetch happening at the same time as
the last I/O cycle. That doesn't sound correct, because then that'd
leave the next cycle where the memory fetch should occur empty. Doesn't
seem there's a lot of point to that.
Last edited by byuu on Wed Oct 10, 2007 4:35 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 10, 2007 4:06 pm Post subject: |
|
Gil_Hamilton wrote: |
Any context for that quote? I've seen "old machines" Applied to the PS1
era. Not to mention that I find it absurd. There's a big difference
between pushing the system to it's limits and making a good game. There
were commercial-quality 1-person efforts even on the PS. Hell, there's
a psp version of Every Extend. It's still QUITE possible for one person
to make a good game. They just usually stick to PC development.
Probably because it's the easiest thing to get your code running on. |
Okay, so it's not a good quote. "Ancient" and "cool" are both
subjective. The point is, the SNES is still past the threshold of those
earlier consoles and it's too difficult to develop for in light of
other options. It's a stretch to say that the disparity in homebrew is
because of generational attitude differences towards programming. The
desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 10, 2007 6:26 pm Post subject: |
|
@Gil
you're completely right, although to create a game say on SNES or PSOne
that has the amount of content that the big commercial releases had it
would take one person a very long time to generate all that content
from scratch. I realize that wasn't the key focus of your argument, but
I just wanted to point that out.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 10, 2007 7:37 pm Post subject: |
|
byuu wrote: |
Ok, I've posted a new beta.
The video settings are now saved based on the current video mode. This
means you can set a larger multiplier in pseudo-fullscreen mode, and
switch back to windowed mode without having to reduce the multiplier
again. It's quite nice.
I also found an old variable I had lying around,
video<.mode>.synchronize. Set it to true and it will prevent
tearing completely in both windowed and pseudo-fullscreen mode, by
syncing to the vertical retrace. Yes, it'll distort the sound. You'll
want to mute sound and turn off speed regulation if you use it. Edit it
from the advanced panel only.
I'm honestly starting to think that if we can get audio syncing working
with this, then I can just add a special modeline in the advanced panel
to set an actual video mode for the purists. No need for three video
modes. |
That does pretty much make "true" fullscreen pointless. I still think
you should put video settings in the config area, though. Perhaps now
that you have only two, you could just use two columns with the same
drop-downs/checkboxes, windowed on the left and fullscreen on the
right. Then you could remove the video settings from the menu area
since they were essentially put there when per-mode configuration
wasn't possible. I would leave "Video Mode>Windowed/Fullscreen" in
the menu as a way to toggle this via the menu rather than just a hotkey
you have to see in the readme to know about.
I tested the chip detection and it works fine. Vsync works for about
the first ten seconds and then BAM, it's gone. 
Last edited by FitzRoy on Thu Oct 11, 2007 12:04 am; edited 3 times in total
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Oct 10, 2007 11:25 pm Post subject: |
|
FitzRoy wrote: |
The desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was. |
The era AROUND the 2600 was different, is what I was saying.
While the VCS was certainly prepackaged, the attitude at the time was
more hands-on, and less "if it's not on a shelf, it doesn't exist"
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 10, 2007 11:54 pm Post subject: |
|
Gil_Hamilton wrote: |
FitzRoy wrote: |
The desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was. |
The era AROUND the 2600 was different, is what I was saying.
While the VCS was certainly prepackaged, the attitude at the time was
more hands-on, and less "if it's not on a shelf, it doesn't exist"
|
The NES actually wasn't very far from being that same kind of deal
http://www.nintendopedia.org/index.php?title=Nintendo_AVS
but plans changed before the launch
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 11, 2007 5:13 am Post subject: |
|
Alright, I've started on the SuperFX interface. Nothing there but the GSU interface mapping, and the registers + SFR.
I'm not making any promises that I'll ever be able to get it working, and even if I do, you're all in for a world of pain
regarding speed, but what the hell ... I never thought I'd get any
commercial games playing when I first started on bsnes, but I just kept
working on it anyway, adding everything I could, piece by piece. So,
I'll do the same for the SuperFX, and we'll see where that leads.
I've decided against using any existing SuperFX implementations,
because they're quite frankly all completely unreadable. I'm aiming to
make mine as clean and readable as possible. I'm going to try my best
to support the timing correctly, but I don't know how to time the
variable-cycle opcodes like PLOT and RPIX. Since I lack the means to
run my own tests on the hardware, I can't possibly aim for the accuracy
I have with the base SNES unit, so instead I'm aiming to implement the
chip according to its specifications, instead.
I could certainly still use help, however. Any help at all would be
greatly appreciated. In the absolute best case scenario, this is
several months away. Worst case scenario, I'll never get anything
working and give up.
I suppose that means I'll have to put off the cycle-based S-PPU once
again. Oh well, I need more time to clean up the code and come up with
a way to support both types of PPUs anyway. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 11, 2007 5:19 am Post subject: |
|
cool, it'll be interesting to see you troubleshoot with the code whether it gets anywhere or not.
Also a delay on the other stuff isn't a big deal as long as you eventually get back to the S-PPU/dot based rendered.
who knows what you'll learn along the way though, and like you said there is always code cleaning to be done. 
and thus the next chapter of bsnes begins.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Oct 11, 2007 6:38 am Post subject: |
|
whats
mortal kombat use? if your just after a cartridge that uses the special
chip, i can go and look for one at my local gametraders and see if its
worth it to me to buy it for you.
of course if mortal kombat uses a different chip then please tell me what games do use the chip.
_________________
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. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 11, 2007 6:48 am Post subject: |
|
Well, the super-fx chip is most widely known for being used in Yoshi's Island (FFS, deinterleave it) and StarFox.
I found a nice thing to quote from the patent:
Quote: |
It
is noted that, if the host CPU attempts to access the program ROM while
the Mario chip is using the program ROM bus, a mechanism is provided
whereby the Mario chip returns dummy addresses to the Super NES. The
branching to such addresses will keep the Super NES occupied until the
Mario chip no longer requires access to the cartridge ROM bus. |
Sounds like that one will be a bit tricky to implement.
Last edited by henke37 on Thu Oct 11, 2007 7:04 am; edited 1 time in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Oct 11, 2007 6:51 am Post subject: |
|
Mortal kombat doesn't use any special chips. its just badly coded. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Oct 11, 2007 6:52 am Post subject: |
|
hmm, i havnt seen them in stores yet so cant comment on price, no doubt they would be about 50$ -> 80$ AUD
if i see one, someone would be willing to contribute money to it? id
send the product prior to you guys sending money to me for proof that i
had it of course and id include a copy of the docket with it. just in
case you guys don't trust me >.<
_________________
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. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Oct 11, 2007 7:00 am Post subject: |
|
I
don't think obtaining an example SuperFX chip is the problem, so much
as hooking one up to a flash-cart so that you can write your own
programs that test it, and/or obtaining and using a logic analyzer that
you can attach to the pins of the SuperFX chip to see what it's
actually doing. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 11, 2007 7:08 am Post subject: |
|
The
only way I can think of to debug Super-FX software is to take an
existing cartridge and replace the ROM with an EEPROM. This due to the
fact that the S-FX just loves to be the Man in the middle when
accessing the cartridge.
Kinda difficult for a copier to fake this, even with an unmodified original S-FX cartridge. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Oct 11, 2007 7:55 am Post subject: |
|
I've
been able to get my code running in the SNES main RAM, then pull out a
cartridge and put another in, without it crashing. Once the new
cartridge is in, I can upload code to be executed. Once that's done, it
goes back to the loader in RAM. Main downside is that byuu says code
executing in RAM is subject to periodic wait-states while the DRAM is
refreshed, so doing critical timing tests harder. If the cartridge
being tested had its own RAM, perhaps code can be executed out of that
without any wait-states (since it's usually SRAM). |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 11, 2007 9:47 am Post subject: |
|
S-FX games does indeed have local ram on the cartridge. And this is in addition to the sram. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 11, 2007 10:36 am Post subject: |
|
henke37 wrote: |
S-FX games does indeed have local ram on the cartridge. And this is in addition to the sram. |
How fascinating!
Here's a picture of an SFX cart: http://nsrt.edgeemu.com/INFO/chip-pix/GSU1.JPG
I'd love for you to point out two different RAM chips on this.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 11, 2007 11:04 am Post subject: |
|
Ok, good that you corrected me.
Not even FIG. 1 on the patent shows any sram.
But perhaps, if just to teach me, could you please list what each chip in that picture does?
After rereading the patent, I got that the cartridge working ram can (if it's static) double as save ram. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 11, 2007 3:03 pm Post subject: |
|
Yet again, I don't need money. I have plenty to support my hobby. Thank you, though.
What I need is an electrical engineer, and given this scene has only
ever seen one (and he's made his contribution already and should not be
bugged on my behalf), that's almost certainly not going to happen.
Anyway, to run tests on the SuperFX, I would need the cartridge ROM
replaced with a ROM emulator, so that I could load my own programs onto
it. I didn't expect that to happen, I was just meaning that it'd be
nice. Instead, I'll have to emulate it from the little info I do have
on the chip and its opcodes. And even if an EE did arrive one day, it'd
be better to spend time on the unemulated chips instead, like the
SPC7110. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Oct 11, 2007 4:42 pm Post subject: |
|
henke37 wrote: |
Well, the super-fx chip is most widely known for being used in Yoshi's Island (FFS, deinterleave it) and StarFox. |
don't forget Stunt Race FX! 
it's a shame that even if we had the carts to work with that there is
still no one here with the expertise to make use of them 
I'm gonna ask around though, I might no a guy, but no promises.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Fri Oct 12, 2007 5:22 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 11, 2007 6:59 pm Post subject: |
|
I
wrote up a test program for IRQ range testing. Note that this is ultra
simplified, and doesn't account for many issues the real SNES faces,
such as:
- scanline 240 is only 1360 clock cycles long, but only on non-interlace odd frames
- when interlace is enabled, there is an extra scanline on even frames
So, the calculations in irq_calc() are greatly simplified. Hence, this
is just a mockup. I took the old method further, before my range
testing only worked on HTIME, but this one calculates both VTIME and HTIME. So the calculations are slower, but the testing is a lot faster.
That said,
Code: |
#include "libbase.h"
#include <conio.h>
//simplify v/h ranges to ease testing
//v = 0 - 7
//h = 0 - 31
//clocks per frame = 256
struct sCPU {
int vcounter, vtime;
int hcounter, htime;
volatile int trigger;
void tick() {
hcounter += 2;
if(hcounter >= 32) {
hcounter = 0;
vcounter += 1;
if(vcounter >= 8) {
vcounter = 0;
}
}
if(vcounter == vtime && hcounter == htime) {
trigger++;
}
}
void add_clocks(uint clocks) {
clocks >>= 1;
while(clocks--) { tick(); }
}
sCPU() {
vcounter = 0;
hcounter = 0;
vtime = 4;
htime = 16;
trigger = 0;
}
} scpu;
struct bCPU {
int vcounter, vtime;
int hcounter, htime;
volatile int trigger;
int irq_clocks;
void irq_calc() {
irq_clocks = (vtime - vcounter) * 32 + (htime - hcounter);
if(vcounter > vtime || (vcounter == vtime && hcounter >= htime)) {
irq_clocks += 32 * 8;
}
}
void add_clocks(uint clocks) {
hcounter += clocks;
if(hcounter >= 32) {
hcounter -= 32;
vcounter += 1;
if(vcounter >= 8) {
vcounter -= 8;
}
}
irq_clocks -= clocks;
if(irq_clocks <= 0) {
trigger++;
irq_calc();
}
}
bCPU() {
vcounter = 0;
hcounter = 0;
vtime = 4;
htime = 16;
trigger = 0;
irq_calc();
}
} bcpu;
int main() {
printf("start\n\n");
time_t start, end;
start = clock();
for(int i = 0; i < 100000000; i++) {
scpu.add_clocks(8);
}
end = clock();
printf("%10d, %d\n", int(end - start), scpu.trigger);
start = clock();
for(int i = 0; i < 100000000; i++) {
bcpu.add_clocks(8);
}
end = clock();
printf("%10d, %d\n", int(end - start), bcpu.trigger);
printf("\ndone\n");
getch();
return 0;
} |
Visual C++ 8 ranks at 3500ms for sCPU, and 500ms for bCPU.
MinGW 4 ranks at 1200ms for sCPU, and 400ms for bCPU.
So, ~3x-7x faster. Seeing as bsnes spends nearly half of the program
execution testing for IRQ triggering, this would give us a speedup of
at least 50%.
Of course, the bad news is that I've yet to get the above to work in
the real SNES environment, as it's quite a bit more complex than the
above test. It also exposes even deeper edge cases that are probably
impossible to trigger anyway. With range testing, it isn't possible to
detect two interrupts that fire in succession, but you would be very
hard pressed to trigger a second IRQ so quickly after the first.
But, what I'm hoping to do is move back to the old model where I had
two separate IRQ testers. The "good enough for ~99% of cases" (bCPU)
model, and the "clock-by-clock test" (sCPU) model. We could extend bCPU
to be optimal by ignoring the edge cases such as scanline 240
missing-dot and interlace scanline 262. It wouldn't affect
compatibility much, and the speed gain would be enormous.
Of course, this would require separate compiles of the emulator, but
eh. The speedup is definitely worth it, and will be needed to even joke
about playable framerates with SuperFX / SA-1 emulation.
As an amusing aside, I was recently testing out bsnes v0.009 again ...
it runs literally 250% faster than the current version, and that one
didn't even have PGO enabled. Pretty awesome, huh? I could get 60fps
with my Pentium IV 1.7GHz processor.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 12, 2007 6:55 am Post subject: |
|
New WIP up.
This one merges the most recent DSP-3 / DSP-4 work. Not sure if it
fixes any bugs or not, but good to be up to date, right? Testing would
be appreciated.
I also cleaned up the cart stuff a bit. Nicer enums, removed some unused variables and such.
Then I turned all of the special chip class object pointers into actual
objects. It was kind of stupid to dynamically create them all, and was
just wasting performance.
I also finished adding all of the SuperFX registers, and mapped them
all to the GSU interface range ($3000-$32ff). Fixed an oversight with
the mapping, and added a new PCB database entry to get the memory map
for Yoshi's Island perfect. If you want to hear something nice, try
loading the USA version in this WIP with sound + speed regulation
enabled.
Then I added a 'Show FPS' option to the misc menu. I also didn't
realize I was still embedding the SNES controller bitmap even though it
wasn't displayed anywhere, so for now that's been removed. Makes the
EXE and archive a bit smaller.
Lastly, I redid the bsnes section of my site to look a little more
polished. Getting ready for 10/14. I've always hated the way SNES
emulator authors always cherry picked most of their screenshots to show
off their special chip support (jealousy because I didn't have any for
a long time), so I decided I'd do the exact same thing myself this time
:P
Ripped off Overload yet again, this time I stole his screenshot layout
style. Sorry, Overload ... but imitation is the sincerest form of
flattery, right? :)
Also, note that all of the ?page=bsnes_* URIs have changed to
?page=bsnes/* ... so if you get redirected to the main page from a
bookmark or something, that's why.
Whew, busy day today ... |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Oct 12, 2007 8:23 am Post subject: |
|
Panzer88 wrote: |
Gil_Hamilton wrote: |
FitzRoy wrote: |
The desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was. |
The era AROUND the 2600 was different, is what I was saying.
While the VCS was certainly prepackaged, the attitude at the time was
more hands-on, and less "if it's not on a shelf, it doesn't exist"
|
The NES actually wasn't very far from being that same kind of deal
http://www.nintendopedia.org/index.php?title=Nintendo_AVS
but plans changed before the launch
|
I've seen the prototype NES shots before.
I don't see how a new case, a tape drive, and a commercially-released
keyboard peripheral would change societal attitudes.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Oct 12, 2007 11:30 am Post subject: |
|
byuu wrote: |
This one merges the most recent DSP-3 / DSP-4 work. Not sure if it
fixes any bugs or not, but good to be up to date, right?
|
It does.
Those updates were made due to bug reports, such as the screen
disappearing at times, or an infinite loop in some cases.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Oct 12, 2007 3:02 pm Post subject: |
|
byuu wrote: |
Lastly, I redid the bsnes section of my site to look a little more polished. |
I notice the page says "The emulator itself was not derived from any
existing emulator source code, such as SNES9x. It was written from
scratch by myself", which isn't strictly true now that you're using
blargg's sound core, and SNES9x's DSP-3 and DSP-4 code.
byuu wrote: |
I've
always hated the way SNES emulator authors always cherry picked most of
their screenshots to show off their special chip support (jealousy
because I didn't have any for a long time), so I decided I'd do the
exact same thing myself this time :P |
And yet you don't have any screenshots from Der Langrisser or any of
the other 'difficult to emulate' games that really do set bsnes apart
from the crowd. Come on, boast a little! :)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 12, 2007 4:28 pm Post subject: |
|
Quote: |
I
notice the page says "The emulator itself was not derived from any
existing emulator source code, such as SNES9x. It was written from
scratch by myself", which isn't strictly true now that you're using
blargg's sound core, and SNES9x's DSP-3 and DSP-4 code. |
I put that there because many news sites at first were reporting that
bsnes was an SNES9x fork, ala SNES9x PP and UOSNES, which wasn't the
case at all.
Do you think I should claim it's a derivative work of SNES9x because of
borrowing 90kb worth of partial special chip support code (in a ~2MB
codebase) that affects two games of four thousand? I consider special
chips more as addons to an SNES emulator, like filters or compressed
archive support.
If everyone's going to keep getting upset about this, I'll take it out.
Really, it's not a big deal to me. I added it because I thought people
would want it there. If you don't, it doesn't bother me to remove it.
As for blargg's sound core, you're definitely right about that. I've
said many times now that it's one of the things I want to go back and
try my own hand at one day. I keep getting sidetracked by other stuff
like SuperFX support. On the plus side, that's only maybe 30kb worth of
code. On the down side, it's probably the most complicated 30kb of code
in the entire emulator. And blargg already did such an amazing job that
there really isn't a lot of point to me doing things myself here. Even
with my crazy high standards, I'm 100% satisfied with the level of
accuracy in his code.
If you're just meaning to clarify what code isn't mine, I already do
that. license.txt mentions all code I borrow except for blargg's S-DSP
(which I only omitted because he allowed me to use the same license I
have in bsnes for it, so it doesn't need to be there). I really should
make a clearer note that I'm using his sound core, and that an LGPL
version is available. I'll do that in the next release for sure.
I should be more clear though, I'll make a clearer note of what code I borrow on the main bsnes page.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Oct 12, 2007 5:05 pm Post subject: |
|
byuu wrote: |
I should be more clear though, I'll make a clearer note of what code I borrow on the main bsnes page. |
In an earlier draft of my last post I was going to suggest just
changing "The emulator itself..." to "The emulation core itself..." or
"The emulation of the basic system...", but on re-reading it I removed
that part because I didn't want to sound like I was claiming more
knowledge of bsnes' ancestry than its author.
I agree that it's a minor change, and the original wording was
completely true up until recently. More than once I've reworked the
design of a page and totally missed that the content was subtly
out-of-date, and I guessed that perhaps you'd done the same thing. I
don't think the main page is the place to get into details about who
wrote what (as you point out, the licence page does that), I just
thought I should mention a small detail you might have missed.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Oct 12, 2007 5:30 pm Post subject: |
|
Gil_Hamilton wrote: |
Panzer88 wrote: |
Gil_Hamilton wrote: |
FitzRoy wrote: |
The desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was. |
The era AROUND the 2600 was different, is what I was saying.
While the VCS was certainly prepackaged, the attitude at the time was
more hands-on, and less "if it's not on a shelf, it doesn't exist"
|
The NES actually wasn't very far from being that same kind of deal
http://www.nintendopedia.org/index.php?title=Nintendo_AVS
but plans changed before the launch
|
I've seen the prototype NES shots before.
I don't see how a new case, a tape drive, and a commercially-released
keyboard peripheral would change societal attitudes.
|
well it just might have not sold as well, but the audience buying it
would be more the hobbyist and programmer crowd because it'd be more
expensive. The keyboard was a music one for composing, it also had
additional storage memory and the ability to edit games.
It wasn't just a shiny NES with wireless controllers. It was a
commercially released dev kit. It probably wouldn't have sold, but if
it had, it'd be to the developer crowd, people who like to make stuff
themselves.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Oct 12, 2007 7:42 pm Post subject: |
|
Panzer88 wrote: |
Gil_Hamilton wrote: |
Panzer88 wrote: |
Gil_Hamilton wrote: |
FitzRoy wrote: |
The desire to program you own game to the limits of modern hardware has
done nothing but increase over time while the feasibility of doing it
has decreased, and the 2600 was just as much prepackaged fun as the
SNES was. |
The era AROUND the 2600 was different, is what I was saying.
While the VCS was certainly prepackaged, the attitude at the time was
more hands-on, and less "if it's not on a shelf, it doesn't exist"
|
The NES actually wasn't very far from being that same kind of deal
http://www.nintendopedia.org/index.php?title=Nintendo_AVS
but plans changed before the launch
|
I've seen the prototype NES shots before.
I don't see how a new case, a tape drive, and a commercially-released
keyboard peripheral would change societal attitudes.
|
well it just might have not sold as well, but the audience buying it
would be more the hobbyist and programmer crowd because it'd be more
expensive. The keyboard was a music one for composing, it also had
additional storage memory and the ability to edit games.
It wasn't just a shiny NES with wireless controllers. It was a
commercially released dev kit. It probably wouldn't have sold, but if
it had, it'd be to the developer crowd, people who like to make stuff
themselves.
|
Look at the picture. That's an alphanumeric keyboard, mot a music keyboard.
Going by the FamiCom, it would've been an accessory, not a pack-in.
And it would've been crippled by the fact that the only development
software available was a really shitty version of BASIC.
The bulk of that additional RAM was almost guaranteed to be used for
loading the data off the tapes, so you could actually PLAY games. The
rest would just bring the system's video RAM up to full capacity, as
many cartridges did(for cost reasons, the NES/FC shipped with half the
possible video RAM and provision to include more in the cartridges).
I would bet money that if full system specs were released, they'd match
a FamiCom+FDS, just using a tape drive instead of a floppy drive.
You can edit games on the NES and FamiCom too.
In the US, they're identified by a "Programmable Series" badge on the
label. They just lack a way to save, as there was never a drive of any
sort released for the NES.
In Japan, they're either FDS games or Dezaemon.
You(and Nintendopedia) forget that this isn't really an exotic
unreleased system. It's the same hardware as the commercial NES/FamiCom.
The promises made were based on what the FamiCom was (misleadingly) claiming at the time.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Oct 12, 2007 9:45 pm Post subject: |
|
fair enough, I'd rather look like a fool today and learn than look like a fool forever. Information noted.
(sorry byuu for crapping up your topic)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Oct 12, 2007 10:41 pm Post subject: |
|
byuu wrote: |
If
everyone's going to keep getting upset about this, I'll take it out.
Really, it's not a big deal to me. I added it because I thought people
would want it there. If you don't, it doesn't bother me to remove it. |
Please, you shouldn't get distracted by this... I've been following
your progress and I'm so totally impressed by all your achievements as
of late. Keep it up 
You have my vote for leaving it in!
_________________
"Change is inevitable; progress is optional"
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 13, 2007 12:19 am Post subject: |
|
it
doesn't matter to me, although if it isn't hurting any other part of
the emulation I don't see the point in taking it out. If you really
want to redo some of that stuff later you can always take it out and do
it then, but until then, there doesn't seem much point to take it out.
We know you work hard and will give credit to people who have helped you, and have made sections of code.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 13, 2007 1:46 am Post subject: |
|
byuu wrote: |
I also finished adding all of the SuperFX registers, and mapped them
all to the GSU interface range ($3000-$32ff). Fixed an oversight with
the mapping, and added a new PCB database entry to get the memory map
for Yoshi's Island perfect. If you want to hear something nice, try
loading the USA version in this WIP with sound + speed regulation
enabled. |
Ah, sweet, and it works for other games like Star Fox, too. It's great
to hear blargg's sound core on that. First time ever that Star Fox's
engine sound isn't a crackly mess.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Sat Oct 13, 2007 2:35 am Post subject: |
|
byuu wrote: |
New WIP up.
Lastly, I redid the bsnes section of my site to look a little more
polished. Getting ready for 10/14. I've always hated the way SNES
emulator authors always cherry picked most of their screenshots to show
off their special chip support (jealousy because I didn't have any for
a long time), so I decided I'd do the exact same thing myself this time

Ripped off Overload yet again, this time I stole his screenshot layout
style. Sorry, Overload ... but imitation is the sincerest form of
flattery, right? 
Also, note that all of the ?page=bsnes_* URIs have changed to
?page=bsnes/* ... so if you get redirected to the main page from a
bookmark or something, that's why.
Whew, busy day today ... |
To make things more busy, maybe you could update the links page with Super Slueths current page . On a side note, your emu keeps getting more user friendly everyday, it might someday become main stream .
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 13, 2007 2:47 am Post subject: |
|
FitzRoy wrote: |
Ah, sweet, and it works for other games like Star Fox, too. It's great
to hear blargg's sound core on that. First time ever that Star Fox's
engine sound isn't a crackly mess. |
sweetness, I'll have to check this out with the next public release
bobthebuilder wrote: |
On a side note, your emu keeps getting more user friendly everyday, it might someday become main stream . |
while it certainly isn't as popular as some of the other emus, I'd say
judging by the hit to byuu's site everytime he puts out a public
release that it has already reached some level of mainstream success.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 13, 2007 5:37 am Post subject: |
|
byuu wrote: |
If
everyone's going to keep getting upset about this, I'll take it out.
Really, it's not a big deal to me. I added it because I thought people
would want it there. If you don't, it doesn't bother me to remove it. |
Doesn't upset me either. My initial reaction looking back was silly,
and if special chips games can benefit from bsnes' accuracy (which like
it was mentionned, could help us determine what causes the bugs in
others emus: the superfx core or the main emulator core) than it's all
the better.
The only thing I really wouldn't like to see in bsnes -and I'm
definitely not changing my mind on this one, is regression toward say,
a faster opcode core-based emulator (that is, supposing no alternative
built is made of course. I'm not opposed to forking)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 13, 2007 7:49 am Post subject: |
|
[quote="Snark"]
byuu wrote: |
The
only thing I really wouldn't like to see in bsnes -and I'm definitely
not changing my mind on this one, is regression toward say, a faster
opcode core-based emulator (that is, supposing no alternative built is
made of course. I'm not opposed to forking) |
same here.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Oct 13, 2007 8:47 am Post subject: |
|
It's all a pity that only a select few can try out the WIP releases.
I do understand the reasons, but that doesn't mean I have to like the end result.
If it's only bandwidth, maybe a better distribution system would be of use?
I am sure someone on this forum got nothing better to do then to mirror the WIP releases.
Sure, a select few get's to feel special, fun for them. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 13, 2007 9:36 am Post subject: |
|
Public
WIPs are a bad idea. WIPs in the past have had non-functioning
configuration panels, missing features, less speed... it would be
bothersome during development to constantly address people about known
issues. You could always just ask byuu to become a tester. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 13, 2007 9:58 am Post subject: |
|
Panzer88 wrote: |
Quote: |
The
only thing I really wouldn't like to see in bsnes -and I'm definitely
not changing my mind on this one, is regression toward say, a faster
opcode core-based emulator (that is, supposing no alternative built is
made of course. I'm not opposed to forking) |
same here.
|
And I just want to add Panzer88 is not a sockpuppet of mine or
vise-versa lol. I'm saying this cause we do seem to share the same
opinion most of the time.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 13, 2007 10:22 am Post subject: |
|
henke37 wrote: |
It's all a pity that only a select few can try out the WIP releases ... Sure, a select few get's to feel special, fun for them. |
Sorry, not trying to be mean. But there's a lot of reasons for this.
1) Bandwidth, at 800kb per download, that adds up fast.
2) News sites, they like to report on every public WIP release, even
when I only post it here and ask to please not post them elsewhere.
While I do really appreciate that they like my software, sometimes I'll
release new WIPs nightly where only the code has been cleaned up and no
actual emulation changed; I imagine so many bsnes WIP posts on news
sites would start to annoy people, as well as drain my bandwidth faster
3) Missing features, compile time is twice as fast without ZIP/JMA
support added in; and was 5+ times faster than a PGO release build when
I could make them
4) Work-in-progress features, things like the video renderer tab are
there but do nothing; emulation changes I'm not entirely sure about may
break games
Overall, if someone thought they were like the periodic ZSNES WIPs, they'd be in for a disappointment.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Oct 13, 2007 2:10 pm Post subject: |
|
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs.
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 13, 2007 4:38 pm Post subject: |
|
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
that sounds like a sweet deal, even if you don't go public with the
WIPs you could still used it to soften the blow for your regular public
releases.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Sat Oct 13, 2007 6:18 pm; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 13, 2007 6:17 pm Post subject: |
|
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
What did you do, read the first reason and just stop there?
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 13, 2007 6:19 pm Post subject: |
|
FitzRoy wrote: |
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
What did you do, read the first reason and just stop there?
|
did you miss my post? it could still help with normal releases.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 13, 2007 7:21 pm Post subject: |
|
Panzer88 wrote: |
FitzRoy wrote: |
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
What did you do, read the first reason and just stop there?
|
did you miss my post? it could still help with normal releases.
|
What's there to help? Bandwidth hasn't been a problem for official releases, and his hosting has always been free.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Oct 13, 2007 8:15 pm Post subject: |
|
Private
WIPs should remain private, but perhaps with more hosting options they
could be available to all users who frequent this thread (and aren't
going to hotlink it anywhere). I also have hosting available with
plenty of bandwidth, but I'd rather not use it for anything that can be
googled or otherwise found on news websites due to an agreement I have
with the person who is letting me use that space. (giving me virtually
unlimited space, but not available to leechers) |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 13, 2007 8:45 pm Post subject: |
|
Verdauga Greeneyes wrote: |
users who frequent this thread (and aren't going to hotlink it anywhere). |
It's already happened.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Oct 13, 2007 9:34 pm Post subject: |
|
FitzRoy wrote: |
Verdauga Greeneyes wrote: |
users who frequent this thread (and aren't going to hotlink it anywhere). |
It's already happened.
|
What, hotlinking? Or all users who frequent the thread having access to
private WIPs? (I don't, but I've never asked as I don't think it would
help bsnes any considering how little testing I would do. If I can get
bsnes to compile, though, it'd be nice to have the latest source code
to look at)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 13, 2007 10:33 pm Post subject: |
|
Man,
it looks like the SuperFX is the most difficult chip to support after
all. I didn't realize how bad the caching mechanism was in that chip.
It does countless crazy things with the CACHE instruction, and that
isn't even the half of it. It also have ROM buffering, RAM buffering,
PLOT pixel buffering, lots of WAIT states to allow both CPUs to access
RAM/ROM ... and all of this has significant effects on timing. To
support it right, I'm absolutely going to have to emulate pipelining
somehow.
... sounds like a fun challenge, and maybe it'll benefit my S-CPU emulation code.
It's too bad it's so hard to read the SNES9x implementation. I can't
even figure out how the hell they're timing the chip to see what kind
of leeway I have.
Quote: |
perhaps
with more hosting options they could be available to all users who
frequent this thread (and aren't going to hotlink it anywhere) |
I'd be fine with that. If someone with access to the WIPs wants to
mirror them and grant others access upon request, that's fine. But we
need some sort of accounting system in case someone leaks them. The
only problem I'd have with them being leaked if they were hosted
elsewhere is that I really don't want to annoy casual emulation users
seeing news posts about bsnes every single day of the week with
one-line changelogs.
Anyway, I should have a new public version out tomorrow for those interested.
Quote: |
If I can get bsnes to compile, though, it'd be nice to have the latest source code to look at |
I'd be really happy if you could make some contributions, too ^^.
Aside from [vEX]'s idle patch, the last thing I got was blargg's S-DSP core about half a year ago :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Oct 14, 2007 2:48 am Post subject: |
|
byuu wrote: |
I'd be fine with that. If someone with access to the WIPs wants to
mirror them and grant others access upon request, that's fine. But we
need some sort of accounting system in case someone leaks them. The
only problem I'd have with them being leaked if they were hosted
elsewhere is that I really don't want to annoy casual emulation users
seeing news posts about bsnes every single day of the week with
one-line changelogs.
|
We can arrange a setup where a user has to login into a site, and every
file that he is downloading is modified to say that user downloaded it.
Then if we see it anywhere else, we can check against our logs and see
who it was that leaked it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Oct 14, 2007 4:24 am Post subject: |
|
FitzRoy wrote: |
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
What did you do, read the first reason and just stop there?
|
i don't care about hot linking issues, if my bandwidth runs out my
space simply becomes inaccessible for a time period... at any point i
could simply stop hosting them but right now and from what i can tell,
i wont be making use of my webspace productively any time soon.
if your putting emphasis on how often wips get released and how
annoying it can be, then fair enough i wont offer my space any more.
_________________
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: Sun Oct 14, 2007 9:12 am Post subject: |
|
What's wrong with using sites like MegaUpload?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Oct 14, 2007 9:30 am Post subject: |
|
byuu wrote: |
I'd be really happy if you could make some contributions, too ^^.
Aside from [vEX]'s idle patch, the last thing I got was blargg's S-DSP core about half a year ago :( |
You gotta stop contribute me for that, all I did was check the man
pages, it's a 4-line fix of which the most characters was for the
#ifdef part. It's not like I did contribute something significant, you
even suggested checking out the usleep() function.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Oct 14, 2007 10:02 am Post subject: |
|
creaothceann wrote: |
What's wrong with using sites like MegaUpload? |
JavaScript countdowns
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 14, 2007 11:27 am Post subject: |
|
franpa wrote: |
FitzRoy wrote: |
franpa wrote: |
i got like 20mb of free'd up webspace and nothing to fill it, i can host public for you and save you on costs. |
What did you do, read the first reason and just stop there?
|
i don't care about hot linking issues, if my bandwidth runs out my
space simply becomes inaccessible for a time period... at any point i
could simply stop hosting them but right now and from what i can tell,
i wont be making use of my webspace productively any time soon.
if your putting emphasis on how often wips get released and how
annoying it can be, then fair enough i wont offer my space any more.
|
Man, you're slow. Byuu gives several reasons for not wanting public
WIPs, including but not limited to bandwidth. How does offering
bandwidth account for the other issues? You a need a total solution,
not a partial one.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Oct 14, 2007 12:08 pm Post subject: |
|
i
know i provided a solution to one of the issues, if the other issues
are big enough to not make public wips viable still then fair enough,
im not byuu so how am i meant to know that?
how am i slow?
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 14, 2007 1:36 pm Post subject: |
|
franpa wrote: |
if
the other issues are big enough to not make public wips viable still
then fair enough, im not byuu so how am i meant to know that? |
At some point, you're going to have to learn how to infer information
that isn't necessarily spelled out for you. You should be inferring
that anything he took the time to post needs resolved before he would
consider public WIPs. Instead, you infer that some are conditionally
important depending on the one issue with which you can help?
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Oct 14, 2007 4:35 pm Post subject: |
|
that's funny because it kinda sounds like you're putting words in his mouth, after all he did just say
byuu wrote: |
I'd be fine with that. If someone with access to the WIPs wants to
mirror them and grant others access upon request, that's fine. But we
need some sort of accounting system in case someone leaks them. The
only problem I'd have with them being leaked if they were hosted
elsewhere is that I really don't want to annoy casual emulation users
seeing news posts about bsnes every single day of the week with
one-line changelogs. |
if whoever is hosting them can control access, then he is fine with it.
I'm sure there are several solutions, one of which would be to send PMs
to people who are regulars to the topic, that's at least more secure
than them being available to anyone who is signed up to the ZSNES
forums.
not to be rude but why are you so helbelt against this FitzRoy? I only ask because I don't understand.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 14, 2007 5:07 pm Post subject: |
|
I'm
not hellbent against it. All of my recent responses are concerning
franpa and his inability to grasp important concepts. Half his posts on
this forum don't make any sense and I'm trying to teach him to use his
head before posting. We have one thread for this emulator and it needs
to be at least somewhat coherent.
In fact, both
you and franpa fail to understand my posts for some reason. How, from
my last post, do you suppose that I am putting words in byuu's mouth?
Doesn't his solution address all the problems and become the total
solution that I told franpa he needed before posting? |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Oct 14, 2007 7:15 pm Post subject: |
|
I
don't want to take up to much more space here, but I do understand you,
and do understand that he didn't meet all the points, but you seem
intent on discarding the idea before a solution can be found.
That is why I said you were speaking for byuu because he already said
he didn't mind so long as the criterion were met.
at this point we are both saying the same thing. I also want to clarify
I mean no disrespect, you just seemed very adamant about stopping this
idea before it started. Clearly I misunderstood you.
~regards.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 14, 2007 9:57 pm Post subject: |
|
Well,
it's still not a fully public system, which is what I said was a bad
idea. I think it's unrealistic to expect no leaks even with this
system, but I'm not going to be the one policing it or addressing known
issues that get posted here. So long as no one expects me or someone
else to do that, it's fine. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 12:49 am Post subject: |
|
byuu.org wrote: |
2007-10-14 - bsnes v0.025 released
bsnes is exactly three years old today. I've posted a new version which
adds DSP-3 and DSP-4 special chip support. The DSP-3 is used by SD
Gundam GX, and the DSP-4 is used by Top Gear 3000. Please note that the
DSP-3 is not fully emulated, thusly SD Gundam GX is not fully playable.
Also, due to lack of timing emulation with the DSP-4, the Top Gear 3000
track sometimes flickers in split screen mode. However, it is believed
that Top Gear 3000 is fully playable.
I should also note that I have started on SuperFX emulation, as some
will inevitably see said code in my source releases. What I have now is
nothing more than a skeleton implementation, and absolutely nothing
using it is playable yet. I am making absolutely no promises that I
will ever be able to emulate this chip. It will take at least several
months of work, and even then, the speed will probably be too slow to
reach 60fps on any system, but ... I'm working on it. While I have no
way to run tests on the actual SuperFX hardware, I will do the best I
can to emulate the chip accurately. I will be emulating the caching and
cycle delays as best I can, but the information I have on this chip is
extremely limited, so don't expect miracles.
Lastly, as promised, I have released the special chips I have
personally emulated to the public domain. See license.txt for more
information if interested. I cannot release the special chips whose
code I did not write to the public domain, but all of that is already
available under the GPLv2 (from ZSNES) or the SNES9x license.
Changelog:
* Added DSP-3 support, thanks to John Weidman, Kris Bleakley, Lancer, z80 gaiden
* Added DSP-4 support, thanks to Dreamer Nom, John Weidman, Kris Bleakley, Nach, z80 gaiden
* Started on support for SuperFX, no games playable as chip emulation is less than 1% complete
* Unsupported special chips will now display an alert
* Missing stbios.bin file when loading Sufami Turbo cartridges will now display an alert
* Video settings now saved separately for windowed and fullscreen mode
* Advanced option video<.mode>.synchronize can be enabled for vsync, but will cause sound crackling
* Added menu option to toggle FPS counter
* Minor source code cleanup |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 1:39 am Post subject: |
|
happy birthday to bsnes! It has the same birthday as my girlfriend, the day not the year, I'm no pedophile.
anyways, wow, it's gone by so fast, that's a lot of developement time, congrats.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Oct 15, 2007 2:44 am Post subject: Mem initialization options |
|
Hey byuu
I just checked out the new bsnes version 0.025, but I could not find
any option in the config file to change the memory / mem via PRNG
initialization byte, that we were talking about earlier to help get
some old pd stuff working...
I can totally understand why you might have forgotten it, with the
massive amount of changes you have implemented since back then 
On another note your emulator has inspired me to do my first
translation for the snes "Albert Odyssey", and has been very useful for
this purpose. Also I have peace of mind that my translation will work
on real hardware!
keep up the great work + happy birthday to bsnes =D |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Oct 15, 2007 4:57 am Post subject: |
|
Happy 3rd anniversary and long live to bsnes! |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 5:21 am Post subject: |
|
I'll bet this will surprise you all, I already have a private WIP for the v0.025 series up :P
Absolutely no emulation changes, just lots of major code changes I held
off on as I didn't want to break anything last minute.
- Polymorphism through pointers using compile-time flag is dead. It
took a ~10% speed hit, so it was never feasible to use anyway. This is
also a required step to encapsulating the entire emulator inside a
single class which can support multiple instances. r_cpu-> becomes
cpu. , r_smp-> becomes smp. , etc.
- Greatly cleaned up interface.h as much as possible for now. Right
now, bsnes takes a lot longer than it should to compile because every
single object includes every last header for all objects. In the
future, I want to move headers so that only objects that need others
include those headers. Will increase compile speed a good bit.
- Created chip/chip.h to start on the above.
- Finally renamed chip/c4 to chip/cx4. Class name also changed from C4 to Cx4.
- Removed libsort, as it's not used (yet?). Was needlessly slowing down compile time.
- Created src/doc. This will be a folder that contains source code
documentation, diagrams, maps, to-do lists, etc. Started things off by
creating a very basic overview of bsnes as a whole.
Much more radical stuff to come. I don't anticipate making another
public release for quite a long time, so I should be able to go wild
here with restructuring things.
Quote: |
I
just checked out the new bsnes version 0.025, but I could not find any
option in the config file to change the memory / mem via PRNG
initialization byte, that we were talking about earlier to help get
some old pd stuff working... |
Oh, I'm sorry about that. Didn't get a chance to add it this time. I
need to work a PRNG with a consistent seed value into the core first.
Not sure how I want to do that.
For what it's worth, initializing RAM to 0x00 unfortunately did not fix
Sidmania's graphical issues as I had hoped. Given FitzRoy reports the
glitches occur on real hardware as well, I'm afraid there's not a whole
lot I can do about it. I will pay attention to it when working on my
cycle-based PPU in the future, though.
Quote: |
On
another note your emulator has inspired me to do my first translation
for the snes "Albert Odyssey", and has been very useful for this
purpose. |
Neat! Be sure to check out bsnes v0.013 on RHDN for its debugger. It's
the only SNES emulator with VRAM breakpoints, as far as I know. Also be
sure to try out xkas for your cross assembler :D </shameless
self-promotion>
Quote: |
Oct. 14 also happens to be the 10th anniversary of the first public release of ZSNES, interestingly enough. |
o.O
Holy crap, why didn't I ever hear about this before? That's really,
really interesting ... of course, the difference is that bsnes was
started on 10-14, ZSNES was first released then but obviously started
much sooner. Still cool, though.
I wonder if anyone knows the exact date zsKnight started on ZSNES, or
Jeremy Koot on SNES9x. It would be really cool to have a history of the
SNES emulation scene. So many emulators most have never even heard of
... RSRSNES, GrimSNES, TrepSNES, Moonlit Coalition's emulator (that
played one game, heh), Simkin's simulator thing ... heh, I wonder if
anyone here knows the name of the SNES emulator I tried (and failed)
making way before bsnes, back in 2001. Google doesn't even know of it :)
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Mon Oct 15, 2007 6:42 am Post subject: |
|
byuu wrote: |
For
what it's worth, initializing RAM to 0x00 unfortunately did not fix
Sidmania's graphical issues as I had hoped. Given FitzRoy reports the
glitches occur on real hardware as well, I'm afraid there's not a whole
lot I can do about it. I will pay attention to it when working on my
cycle-based PPU in the future, though. |
It's
most likely the mapping. When I changed the SRAM mapping in ZSNES to
map ROM to $8000-$ffff the mode 7 stuff in Sidmania was the same as in
bsnes. But after changing the mapping in bsnes it still didn't look
like ZSNES.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Oct 15, 2007 8:30 am Post subject: |
|
byuu wrote: |
I'll bet this will surprise you all, I already have a private WIP for the v0.025 series up 
Absolutely no emulation changes, just lots of major code changes I held
off on as I didn't want to break anything last minute.
- Polymorphism through pointers using compile-time flag is dead. It
took a ~10% speed hit, so it was never feasible to use anyway. This is
also a required step to encapsulating the entire emulator inside a
single class which can support multiple instances. r_cpu-> becomes
cpu. , r_smp-> becomes smp. , etc.
- Greatly cleaned up interface.h as much as possible for now. Right
now, bsnes takes a lot longer than it should to compile because every
single object includes every last header for all objects. In the
future, I want to move headers so that only objects that need others
include those headers. Will increase compile speed a good bit.
- Created chip/chip.h to start on the above.
- Finally renamed chip/c4 to chip/cx4. Class name also changed from C4 to Cx4.
- Removed libsort, as it's not used (yet?). Was needlessly slowing down compile time.
- Created src/doc. This will be a folder that contains source code
documentation, diagrams, maps, to-do lists, etc. Started things off by
creating a very basic overview of bsnes as a whole.
Much more radical stuff to come. I don't anticipate making another
public release for quite a long time, so I should be able to go wild
here with restructuring things.
|
COOL, that gives me the same fuzzy feeling as when aaron completely
breaks mame in a u release by adding or changing core elements
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Oct 15, 2007 3:51 pm Post subject: |
|
The
release seems to work fine, it even managed to treat the not drive
mapped network resource i keep insisting on using properly, in fact,
not even disconnecting while playing didn't cause any crash!
Maybe you should extend the unsupported chip check to also check for
games that requires one of the unsupported input devices?
It would be nice if you got one of them working if you got bored of the S-FX chip.
Also, while I am sure you know of it, the sound buffer repeats when the
process is processing events. Maybe you want to either fix that or at
least cut the sound while doing that? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Oct 15, 2007 4:25 pm Post subject: |
|
henke37 wrote: |
Maybe you should extend the unsupported chip check to also check for
games that requires one of the unsupported input devices? |
Lets add specific game hacks, marvelous idea!
_________________
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: Mon Oct 15, 2007 5:26 pm Post subject: |
|
also, how about an option in the config to enable/disable every specific special chip?
_________________

<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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 5:34 pm Post subject: |
|
Quote: |
When
I changed the SRAM mapping in ZSNES to map ROM to $8000-$ffff the mode
7 stuff in Sidmania was the same as in bsnes. But after changing the
mapping in bsnes it still didn't look like ZSNES. |
Ah, so it's a mapping issue. Thank you for the information.
That's a tricky one, those generic mappers are really hacked up for
maximum compatibility. Changing them even a little would definitely
break games.
Quote: |
Maybe you should extend the unsupported chip check to also check for games that requires one of the unsupported input devices? |
If you're meaning to pop up a warning that the mouse / multitap / etc
is not supported, that may be tricky. I'm pretty sure the cartridge
header doesn't ID the list of acceptable inputs like it does the
special chips used. I'd have to keep a database of all games using
inputs not supported.
I'll work on supporting more input devices eventually. As just one guy,
it's pretty low on the priority list is all. I imagine it would be
especially boring (or challenging) playing multitap Bomberman alone :P
Quote: |
Also,
while I am sure you know of it, the sound buffer repeats when the
process is processing events. Maybe you want to either fix that or at
least cut the sound while doing that? |
Uh, what? The sound mutes itself when you enter the menubar. If
emulation runs too slow, or if another process eats up all CPU time,
sound will skip. Not much I can do about that ...
Quote: |
also, how about an option in the config to enable/disable every specific special chip? |
I could add this, but ... why?
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Mon Oct 15, 2007 5:42 pm Post subject: |
|
byuu wrote: |
Quote: |
also, how about an option in the config to enable/disable every specific special chip? |
I could add this, but ... why?
|
Everytime you add a special chip to the emulator, doesn't that need more CPU power?
If you could enable/disable the use of the special chip(s) that you
will/won't be using at will, you can probably make it faster 
_________________

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

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 5:50 pm Post subject: |
|
can
any snes game tell if a controller/input devise is not plugged in? I
know some games if the super scope is pugged in, or snes mouse the game
will tell you that it isn't compatible. Was there also something like
that if you managed to get a rom to load in the wrong region? (or am I
thinking of another system?)
What I'm getting to
is- Could there be a way to tell bsnes if the super scope sensor ( or
any controller for that matter) is plugged in, or not plugged in? There
really isn't a whole lot of purpose other than getting the "this devise
does not work with this game" or "you don't have any controllers
plugged in" screen.
And seperately, I know it prolly wasn't the SNES because the cartridges
were different shapes but there was some system that loaded an text
error screen if you tried to load the wrong region game. (it was prolly
my genesis or N64) anyways if this was the case with SNES too it'd be
cool to recognise that also.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Mon Oct 15, 2007 5:53 pm; edited 2 times in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 5:51 pm Post subject: |
|
Only
the SuperFX and SA-1 support is going to cause a speed hit to
non-special chip games. It will do this because I need to add a way to
run an additional processor with its own clock counter. I'll either
have to make a critical timing function into a function pointer, or add
a boolean test right inside that very critical loop to test if there is
a coprocessor present.
And a checkbox in the GUI
won't avoid that overhead ... it would require a separate compile of
the emulator with said code omitted.
Also, not presently a way to override controller or region settings.
Controllers are always connected and region is always auto selected for
now. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Oct 15, 2007 6:04 pm Post subject: |
|
byuu wrote: |
So
many emulators most have never even heard of ... RSRSNES, GrimSNES,
TrepSNES, Moonlit Coalition's emulator (that played one game, heh),
Simkin's simulator thing ... |
SNEM...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 6:21 pm Post subject: |
|
I'm
loving dia, not sure how I went without it before. After looking at
current.png, it's obvious to see that the memory management is
haphazard at best, and very inconsistent.
http://i73.photobucket.com/albums/i221/byuusan/current.png
Here's my plans to clean things up. I want to turn the extra class,
Memory, into a general memory bus, which will contain all memory ICs in
the future. Hopefully even special chip memory, much much later.
But they won't be "bound" directly to the Memory class, instead they
will be separate classes bound within the Memory class. Eg, you would
use bus.vram.read(addr), bus.cpu.write(addr) [write to
$00-ff:0000-ffff], bus.apu.write(addr) [write to SPCRAM / APURAM], etc.
bus.cpu will be an address decoder, handling access to bus.wram, bus.rom, etc.
http://i73.photobucket.com/albums/i221/byuusan/mockup.png
While also not "ideal" from a hardware representation (OAM and CGRAM
specifically are embedded inside the PPU, but VRAM is not), I think
it's a lot cleaner and more consistent than before.
I hope he continues working on that ... NeuSNem really sounds
interesting ... and I feel bad about insulting his previous codebase
(but it was true, heh). He seems very talented. We could certainly use
another active SNES emulator author around here.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 6:59 pm Post subject: |
|
what I was suggesting in a not so concise way can be easily achieved in ZSNES.
open Yoshi's Island, set the first controller to mouse or second
controller to super scope or mouse, then reset, and you see the screen
I'm talking about.

I don't think this is the only game but it's the only one that comes to
mind. It doesn't show it with the justifiers.
I'm aware that bsnes doesn't support the FX-Chip or the Super
Scope/Mouse right now but it is still something to be aware of.
In fact I think even without full FX emulation or super scope/mouse
emulation you could code bsnes to know if the super scope/mouse (or
other input devises from normal controllers to the multitap +
justifier) is plugged in or not and if it is when you try to boot
Yoshi's Island you would see this screen.
Again I know there is little use for this, but it is another behavior of the snes to emulate.
I'm not sure if this happens with other peripherals besides super
scope/mouse (in yoshi's island the justifier does nothing), or if no
controller is plugged in at all, since it has been awhile since I've
used a real SNES.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Mon Oct 15, 2007 7:07 pm; edited 2 times in total |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 7:03 pm Post subject: |
|
Ah,
shit. It appears Cartridge::load_file is also used to load SRAM files.
Meaning you'll get a popup alert whenever a SRAM file doesn't exist.
I'll have to post an emergency fix for that ...
I really need to stop with the last minute changes before release.
Panzer88:
By the way, the reason Yoshi's Island displays that warning is quite
funny. The SuperFX apparently drains so much power that having the SNES
plus the Super Scope connected will end up drawing more current than
the power supply is rated for. So it's a requirement for SuperFX games
to verify these peripherals are not attached at startup, and to suspend
the SuperFX if they are. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 7:26 pm Post subject: |
|
interesting, that's pretty funny and I guess pretty irrelevant to bsnes right now then.
On a side note the computers in the library at my community college run
bsnes at 60 FPS holy hell my home computer sucks!!! (a nice 30 FPS)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 15, 2007 9:05 pm Post subject: |
|

Well, that was easy enough. Just need a custom PCB mapper. Wonder how
much harder it'll be to map in a BS-X cart onto the bus. Hopefully
those things are literal memory dumps and not hacked up ROMs designed
to run on existing emulators. Lots and lots of battery-backed memory to
worry about, going to have to store it in more than one file. I think
I'll add an option to the load special menu for this, I'm not going to
bother supporting a BIOS skipping mode. The known MMIO registers seem
easy enough to support for the most part ... |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 9:52 pm Post subject: |
|
now
the problem are games that wait to pick up a live signal via satellite,
how do you fake them out of that? just have them "detect" it on boot
everytime? (it'd require emulation of the Satellaview unit, how complex
is this?)
on a side note, who wants to translate the BS-X bios 
EDIT: also
http://wakoopa.com/software/bsnes
WTF?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Oct 15, 2007 10:48 pm Post subject: |
|
You surprise me greatly sir. SFX? BS-X? In bsnes? What is the world coming too?
I really enjoy following your development of bsnes. I can't wait for
the day I have a computer that is actually fast enough to play games
with it (I'm currently using an Athlon 1.1 GHz).
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 15, 2007 11:01 pm Post subject: |
|
Richard Bannister did Mac ports of bsnes.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Oct 15, 2007 11:05 pm Post subject: |
|
FitzRoy wrote: |
Richard Bannister did Mac ports of bsnes.
|
I'm aware of that, but that's just the Mac port.
byuu, you always show something cool in a new version RIGHT after your official releases 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 15, 2007 11:43 pm Post subject: |
|
Panzer88 wrote: |
FitzRoy wrote: |
Richard Bannister did Mac ports of bsnes.
|
I'm aware of that, but that's just the Mac port.
byuu, you always show something cool in a new version RIGHT after your official releases
|
Well, those are the only versions I see listed. Byuu should still be
listed as developer, but it seems to just be a mistake. I'd be more
concerned if someone was intentionally passing the program off as their
own.
Byuu, that's some sweet ass shiz. You are a man on a mission this week.
Let me know when you feel you've supported it enough to remove it from
the list.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 16, 2007 5:50 am Post subject: |
|
Alright, posted a new WIP with the BS-X skeleton. The BIOS needs to be named bsxbios.bin, and it can't have a header.
There's also "Load Special -> Load BS-X Cartridge ...", but it
doesn't work yet. It maps the flash cart into $[c0-ff]:[0000-ffff], but
that doesn't do much good. The BIOS then detects the flash cart and
starts probing the memory mapping registers and eventually deadlocks.
To emulate the MMIO registers, I will have to completely
rework my memory mapping code to support dynamic remapping. Not
necessarily a bad thing, I was planning to rewrite all of that anyway
(per my diagram yesterday). Might as well kill two birds with one stone.
Gonna take at least a few days of planning before I go at that. I want
to get it right this time, so I don't have to do this again.
In the meantime, have fun walking around the dead St. GIGA ghost town ;)
Quote: |
Byuu,
that's some sweet ass shiz. You are a man on a mission this week. Let
me know when you feel you've supported it enough to remove it from the
list. |
Yeah, not sure what's up. I rarely have motivation to do anything
anymore, but it always comes in bursts. So I'll take advantage of it
now, and hope it doesn't burn out soon.
I've a long way to go with BS-X before we can remove it, sadly. I think
we can remove when I get >50-75% of games loading. I doubt we can
reach 100%. There's missing info, corrupted / hacked BS ROMs galore,
and I don't even have BS-X hardware to test with.
Quote: |
byuu, you always show something cool in a new version RIGHT after your official releases |
Sorry about that, it's not intentional. The thing is that no BS-X games
are even playable yet. I suppose when it's stable, I'll post another
public version, assuming the core is still stable with all the plans I
have for it.
Quote: |
I
really enjoy following your development of bsnes. I can't wait for the
day I have a computer that is actually fast enough to play games with
it (I'm currently using an Athlon 1.1 GHz). |
Sorry about that :(
---
Side note: I also posted v0.025a, which removes the warning message
when SRM files don't exist. Nothing else is different, though.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Oct 16, 2007 5:52 am Post subject: |
|
Panzer88 wrote: |
now
the problem are games that wait to pick up a live signal via satellite,
how do you fake them out of that? just have them "detect" it on boot
everytime? (it'd require emulation of the Satellaview unit, how complex
is this?) |
Remember, the games was made to not crash if the satellite stopped broadcasting.
bsnes would have no other choice then to report that the signal is offline, since well, it is no longer broadcast.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Oct 16, 2007 5:59 am Post subject: |
|
unless byuu made a time machine that would take us back to the late 90s, or perhaps make a satalite, hmm....
sorry. couldn't help myself. Any plans on this byuu? I know it's the
furthest thing away with all the other problems, but lets just pretent
it would be as easy as lying to the game, telling it that it was ok to
play the next part. (I know that this wouldn't always be the case,
sometimes live voice or music was played etc.)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 6:16 am Post subject: |
|
Panzer88 wrote: |

on a side note, who wants to translate the BS-X bios :Very Happy: |
No idea. My Japanese suck right now. What I could translate doesn't make much sense...
"Sore ha namae o nusumareta gai/jitsu no monokatari"
(That) NAME (something about) STEELING (or not steeling) something
about DISTRICT (but that doesn't make much sense) and finally STORY.
Sorry that's all I could do. byuu's Japanese is probably better than mine anyway.
edit: The fifth kanji is possibly "art" instead of "district" (that
would make more sense anyway). They are very similar and are near
impossible to distingish at such low resolution...
So I'm taking a guess the size of Jupiter here...
"BS-X: That's the name of the thing that's making it an art to stole stories" (lol)
or
"BS=X:That's the name(thing) that has stolen(borrowed) the art to tell stories"
edit: And the part in black is Satellite data broadcasting
Last edited by Snark on Tue Oct 16, 2007 6:40 am; edited 5 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Oct 16, 2007 6:30 am Post subject: |
|
Go on, byuu, make us a satellite. You know you want to 
On a more serious note, well done on all the progress o.o
I've been working on a custom string class based on (copying the
interface of) basic_string<char>.. interested? It's possibly a
bit more memory hungry than the gcc version but should hopefully be
faster, and I've identified several (obscure?) cases where it's
definitely better. Of course it's not done yet, so I can't do any speed
testing (although a test I did that made me start on it suggested it
should be much faster) but it's coming together well - just the various
find functions and getline left to do. Well, aside from anything
iterator-related, but I don't know how those work yet and as I've
therefore never used them it hasn't been a priority. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Oct 16, 2007 6:36 am Post subject: |
|
Snark wrote: |
translation stuff
|
I'm going to take a wild guess and say it basically says (in the
Panzer88 Paraphrase) "This product and artwork copyrighted, any
pirating will be punished by the full force of the law" not really
that, but you know, your typical disclaimer and copyright information.
how exciting 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 6:46 am Post subject: |
|
Panzer88 wrote: |
Snark wrote: |
translation stuff
|
I'm going to take a wild guess and say it basically says (in the
Panzer88 Paraphrase) "This product and artwork copyrighted, any
pirating will be punished by the full force of the law" not really
that, but you know, your typical disclaimer and copyright information.
how exciting
|
......Dohhhhhhhhhhhhhhhhhhhhh!!!!!!!!
Of course you're right. "That name is a copyrighted mark.
That would make more sense In any case someone with REAL Japanese skill (i.e: not me) would need to step up.
edit:
nope...I was closer Doesn't have anything to do with copyrights afterall (though that was a good guess)
"The Story of The Town Whose Name Has Been Stolen"
http://en.wikipedia.org/wiki/Satellaview
The forth kanji is not 'art' afterall but district or town.
Ok, it's wikipedia so it is to be taken with a grain of salt...
And if THAT is the real translation, no wonder it's hard to translate...wtf
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Oct 16, 2007 6:57 am Post subject: |
|
nice,
from your original attempt it sounded like it could have been
copyright, oh well, I guess it pays to know japanese (literally!....
sometimes)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 7:07 am Post subject: |
|
Panzer88 wrote: |
nice,
from your original attempt it sounded like it could have been
copyright, oh well, I guess it pays to know japanese (literally!....
sometimes) |
Literally to a certain extend only...Japanese has completely different
sentence structures compared to English (or French) and being too
literal is not always good.
So...let's say you have a sentence with: mouse, cat, dog, eat...One
could see the Japanese word orders and think: "Mouse was eaten by cat.
Cat eaten by dog" etc... When the real meaning could be: "The cat that
ate the dog was eaten by the mouse"
Basically the Jap sentence structures tend to fuck with foreigners...
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Oct 16, 2007 7:19 am Post subject: |
|
Snark wrote: |
Panzer88 wrote: |
nice,
from your original attempt it sounded like it could have been
copyright, oh well, I guess it pays to know japanese (literally!....
sometimes) |
Literally to a certain extend only...Japanese has completely different
sentence structures compared to English (or French) and being too
literal is not always good.
So...let's say you have a sentence with: mouse, cat, dog, eat...One
could see the Japanese word orders and think: "Mouse was eaten by cat.
Cat eaten by dog" etc... When the real meaning could be: "The cat that
ate the dog was eaten by the mouse"
Basically the Jap sentence structures tend to fuck with foreigners...
|
um, you misunderstood me. the phrase "it pays to.." is an idiom, but
what I was saying is that sometimes it actually does pay money (it
literally pays) to know japanese aka as a paid translator.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 7:39 am Post subject: |
|
Panzer88 wrote: |
od
me. the phrase "it pays to.." is an idiom, but what I was saying is
that sometimes it actually does pay money (it literally pays) to know
japanese aka as a paid translator. |
Oh. Sorry. 
Anyway, it's good to see the Satellaview in bsnes. Unfortunately it's
one of those thing that can never be fully be reproduced. Closer we
could get is if somewhere there were dumps of the "Live Voice"
broadcasts I guess. Though unfortunately none exists, probably.
wikipedia wrote: |
Because
of the inclusion of Live Voice, the clock, and other live elements, the
BS Zeldas could not be played at any time like some of the other BS-X
games, but only during the set hours. |
How will that work in bsnes?
edit: woops sorry allready mentionned earlier in the discussion.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Oct 16, 2007 8:05 am Post subject: |
|
90%
of BS-X games aready seem to "fully" work, even without the BS-X
emulation, just load them as regular carts and most of the time they
are fully playable (i also tested ALL BS-X games when i did my testrun)
There are maybe 1 or 2 games that do not run at all, the rest of the
games that do not work have messed up GFX(but are otherwise fully
playable).
The broken games could simply be bad hacks or bad bumps |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Oct 16, 2007 11:29 am Post subject: |
|
Snark wrote: |
Closest
we could get is if somewhere there were dumps of the "Live Voice"
broadcasts I guess. Though unfortunately none exists, probably.
|
Well, Nintendo probably got those archived somewhere...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 11:50 am Post subject: |
|
henke37 wrote: |
Snark wrote: |
Closest
we could get is if somewhere there were dumps of the "Live Voice"
broadcasts I guess. Though unfortunately none exists, probably.
|
Well, Nintendo probably got those archived somewhere...
|
Somehow I doubt that.
The fact is: Outside of monetary profit, big gaming corporations don't
really give a damn about their own history or the preservation of old
hardware and old games. Bottom line: they're not too fond of archiving
most of their own stuff.
Nintendo probably has a big statue of Mario in it's headquarters and
maybe a few Game&Watches games for good measure and that's it.
It's up to hobbyists: people like byuu and people that collect old
games, manuals, hardware etc to document and preserve this stuff, or so
it would seem.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Tue Oct 16, 2007 4:25 pm Post subject: |
|
Actually,
most/all US publishers have full source code/art/sound archives of all
their games (I know Activision and EA do back to the early 80s for
sure). Doesn't help when they go out of business (e.g. Acclaim), but
it's normally standard practice to keep things archived. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Oct 16, 2007 5:03 pm Post subject: |
|
Arbee wrote: |
Actually,
most/all US publishers have full source code/art/sound archives of all
their games (I know Activision and EA do back to the early 80s for
sure). Doesn't help when they go out of business (e.g. Acclaim), but
it's normally standard practice to keep things archived. |
Oh, there I go talking out of my ass again. Thanks for the info.
I guess I ASSume they didn't cared based on the fact they always seem
to make those crappy commercial chees-ulators (compared to the quality
of hobbyist emulators like M.A.M.E, Nestopia, Stella or bsnes)
Last edited by Snark on Tue Oct 16, 2007 5:09 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Oct 16, 2007 5:06 pm Post subject: |
|
byuu wrote: |
There's missing info, corrupted / hacked BS ROMs galore, and I don't even have BS-X hardware to test with. |
There aren't any BS ROMs, there never were.
Snark wrote: |
Nintendo probably has a big statue of Mario in it's headquarters and
maybe a few Game&Watches games for good measure and that's it.
|
Actually, at headquarters, they have a room with a copy (cart) of every
single game ever made for any of their systems in 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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 16, 2007 5:26 pm Post subject: |
|
Ok, working on the new memory mapping system. I want it to be dynamic. Here's what I have so far:
Code: |
struct Memory {
virtual uint8 read (uint addr) = 0;
virtual void write(uint addr, uint8 data) = 0;
};
struct Bus {
Memory *page[0x10000];
void map(uint16 page_number, Memory &r_page) {
page[page_number] = &r_page;
}
uint8 read(uint addr) {
return page[addr >> 8]->read(addr);
}
void write(uint addr, uint8 data) {
page[addr >> 8]->write(addr, data);
}
};
/* */
struct WRAM : Memory {
uint memory[128 * 1024];
uint8 read (uint addr) { printf("* read %0.6x = %0.2x\n", addr,
memory[addr & 0x1ffff]); return memory[addr & 0x1ffff]; }
void write(uint addr, uint8 data) { memory[addr & 0x1ffff] = data; }
};
/* */
Bus bus;
namespace memory {
WRAM wram;
};
/* */
int main() {
memory::wram.write(0x00012, 0xea);
bus.map(0x0000, memory::wram);
bus.map(0x7e00, memory::wram);
bus.read(0x000012);
bus.read(0x7e0012);
printf("done\n");
getch();
return 0;
} |
Like before, I'm mapping based on 256-byte pages. I omitted the MMIO
special cases (1-byte mapping for $[00-3f]:[2000-5fff]) for simplicity.
They're easy enough, anyway.
The problem I'm running into here is that when WRAM::read() is called,
it gets the address on the bus, which can be 0x000012 or 0x7e0012. The
former is a mirror for the latter, but both should read from
WRAM::memory[0x00012].
I could just assign an index value to each page table entry, but then
that would make memory lookups twice as slow. Anyone have a better idea?
Please note that I do not want to map direct pointers to memory arrays, eg page[0x0002] = memory + (0x0002 << 8);
That isn't flexible enough for some things I want to do, such as MMIO,
cheat code support wrapped in here, and possibly even a breakpoint
system for a debugger in the future.
Mr. Semantic wrote: |
There aren't any BS ROMs, there never were. |
Are there any available direct dumps of the contents of the 8mbit BS-X
flash carts? You know, similar to those NP dumps Y~K had a while back.
I assume that's what I need to be mapping to $[c0-ef/ff]:[0000-ffff] to
get the St. GIGA town game play menu to recognize games and offer to
start them.
I know that at least some BS-X games have been taken from the flash
carts and hacked up into pieces to run as standard SNES ROMs on older
emulators. The BS Zelda translation comes to mind.
I imagine the contents on the flash carts look really close to standard
HiROM / LoROM images, so it probably isn't a lot of work, but still ...
there's probably some means by which you can store multiple games on
the same flash cart. Some sort of directory information in there or
something that the BIOS can parse.
Also, not to be rude, but if you have additional information I'm
missing in the above, please explain in detail rather than pointing out
my semantic mistakes and leaving it at that. It would be a lot more
helpful ;)
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Oct 16, 2007 6:11 pm Post subject: |
|
Snark wrote: |
Panzer88 wrote: |

on a side note, who wants to translate the BS-X bios :Very Happy: |
No idea. My Japanese suck right now. What I could translate doesn't make much sense...
|
Snark,if you look closely,you can already find the correct translation in the Wikipedia article.
'Satellite data broadcast(ing)' is correct
_________________
Have a nice kick in da nutz @~@*
Last edited by kick on Wed Oct 17, 2007 1:46 pm; edited 2 times in total
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Oct 16, 2007 6:45 pm Post subject: |
|
Nach wrote: |
Snark wrote: |
Nintendo probably has a big statue of Mario in it's headquarters and
maybe a few Game&Watches games for good measure and that's it.
|
Actually, at headquarters, they have a room with a copy (cart) of every
single game ever made for any of their systems in it.
|
That sure is cool, but that isn't what I meant. I meant that they kept
the needed files to build the games, at least for in house productions.
Now don't go and tell me that the modified SMW ports is rom hacks. They
could only have done it with the aid of the original source code.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Oct 16, 2007 6:47 pm Post subject: |
|
byuu wrote: |
Mr. Semantic wrote: |
There aren't any BS ROMs, there never were. |
Are there any available direct dumps of the contents of the 8mbit BS-X
flash carts? You know, similar to those NP dumps Y~K had a while back.
I assume that's what I need to be mapping to $[c0-ef/ff]:[0000-ffff] to
get the St. GIGA town game play menu to recognize games and offer to
start them.
|
Yes we have over a hundred dumps from flash carts which contained the
BS games. However, many of them seem sketchy, and could be that about
half of them are hacked up in some way.
byuu wrote: |
I know that at least some BS-X games have been taken from the flash
carts and hacked up into pieces to run as standard SNES ROMs on older
emulators. The BS Zelda translation comes to mind.
|
Some is putting it mildly. The dumps are marked with a size, about a
dozen of the dumps are too small compared to the size marked as. We
have dumps which contain part of the BIOS. Then some to be normal ROM
images hacked up to look like it came from the BS-X Sattelite thingy.
byuu wrote: |
I imagine the contents on the flash carts look really close to standard
HiROM / LoROM images, so it probably isn't a lot of work, but still ...
there's probably some means by which you can store multiple games on
the same flash cart. Some sort of directory information in there or
something that the BIOS can parse.
|
That's part of what bothers me. We know ROMs come with psyical
hardware, so they can be mapped differently. How exactly do you explain
software which you download having multiple mappings?
I suspect that several dumps had people convert their mappings to try to get them to run in emulators.
byuu wrote: |
Also, not to be rude, but if you have additional information I'm
missing in the above, please explain in detail rather than pointing out
my semantic mistakes and leaving it at that. It would be a lot more
helpful  |
Well, considering for Snes9x, we wrote a 1200 line file to handle a
bunch of the BS-X stuff, and we feel we're missing quite a few things,
I think there may be a bit more to it than you're mentioning in the
thread here.
But who knows, the state of the dumps, and lacking all the streamed
data just makes me negative on this whole subject.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Oct 16, 2007 6:49 pm Post subject: |
|
henke37 wrote: |
Nach wrote: |
Snark wrote: |
Nintendo probably has a big statue of Mario in it's headquarters and
maybe a few Game&Watches games for good measure and that's it.
|
Actually, at headquarters, they have a room with a copy (cart) of every
single game ever made for any of their systems in it.
|
That sure is cool, but that isn't what I meant. I meant that they kept
the needed files to build the games, at least for in house productions.
Now don't go and tell me that the modified SMW ports is rom hacks. They
could only have done it with the aid of the original source code.
|
Considering that a current Nintendo dev contacted us, and sent us some
source code and documents of old SNES games and hardware, as well as
some betas, you know they have old stuff lying around somewhere.
Could be that it was stuff they were throwing out though, otherwise he
could get in really big trouble. And either way we can't use it for
legal reasons.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Oct 16, 2007 7:23 pm Post subject: |
|
Arbee wrote: |
Actually,
most/all US publishers have full source code/art/sound archives of all
their games (I know Activision and EA do back to the early 80s for
sure). Doesn't help when they go out of business (e.g. Acclaim), but
it's normally standard practice to keep things archived. |
They also have a bad habit of losing stuff.
Aside from Atari-era stuff, the first example that springs to mind is the
NeoGeo 64.
SNK's publicly stated that they WANT to port the games to a home system
now that it's technically feasable, but they lost the source. And the
textures and sound samples, if I recall.
I know Atari lost a lot of stuff in the modern era too. Bunch of it
turned out to be sitting in the back of their warehouse and they just
had no idea which box it was in.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Oct 16, 2007 8:17 pm Post subject: |
|
Nach wrote: |
Considering
that a current Nintendo dev contacted us, and sent us some source code
and documents of old SNES games and hardware, as well as some betas ... |
Whoah! 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Tue Oct 16, 2007 11:40 pm Post subject: |
|
Re: losing stuff.
Yes, and both SNK and Atari went through multiple owners (and building
moves and even being out of business) between when the stuff in
question was created and now. There's no reason to believe stable
companies like Nintendo or Sega have that problem (certainly I've seen
no evidence that e.g. Super Mario Advance isn't based on the original
code). Also, Atari leaked like a sieve over the years, up to and
including when Midway pulled the plug (Scott Evans and Aaron Giles got
to raid their offices the day they were shut down - that's where a lot
of the prototypes in MAME came from). |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 17, 2007 12:22 am Post subject: |
|
Arbee wrote: |
There's no reason to believe stable companies like ... Sega have that problem |
I laughed out load, and I'm a sega fan. Shame on me 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Oct 17, 2007 2:40 am Post subject: MSYS compile fix |
|
Hey byuu,
I tried out your debugging bsnes 0.013 and it is really impressive/great, thanks for that =D
I will also definitely try out your snes assembler xkas for some snes programming I want to do, so cheers for that too!
I just got bsnes to compile after ages of trying using my msys mingw
environment and I was just wondering if you could tell me the changes
to the source you did to get the missing .srm complaint to go away, as
the source on your website is still bsnes 0.025 without that fix...
If it is more than like 2 lines of changes then don't bother I will live!
Also I found that my msys mingw environment gave me this error when I compiled bsnes:
error: redefinition of 'struct _D3DVECTOR'
It said this about 4 times, so to fix it I defined "D3DVECTOR_DEFINED" by adding:
-DD3DVECTOR_DEFINED
to the end of the CFLAGS = portion of the makefile for the mingw platform.
This might help others here who have had the same problem.
Also I noticed a healthy speedup for my system (an old pentium4 HT 2.8ghz) using these flags:
-O8 -mtune=prescott -ffloat-store -fforce-addr -finline-functions
-fexpensive-optimizations -funroll-all-loops -ffast-math
-fomit-frame-pointer
This made albert odyssey go at full 60 fps frame rate, even when the
funky mode 7 and hdma are going on, and it all scrolls much smoother...
yay =D
cheers for all this fun! |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Oct 17, 2007 4:32 am Post subject: |
|
Arbee wrote: |
Re: losing stuff.
Yes, and both SNK and Atari went through multiple owners (and building
moves and even being out of business) between when the stuff in
question was created and now. There's no reason to believe stable
companies like Nintendo or Sega have that problem (certainly I've seen
no evidence that e.g. Super Mario Advance isn't based on the original
code). Also, Atari leaked like a sieve over the years, up to and
including when Midway pulled the plug (Scott Evans and Aaron Giles got
to raid their offices the day they were shut down - that's where a lot
of the prototypes in MAME came from). |
I meant home Atari, not arcade Atari.
Bushnell to TimeWarner to Tramiels to JTS. And with JTS came death and corpse-robbing.
Atari under Hasbro wasn't a company, just a sub-brand.
And SNK lost their stuff before they folded.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 17, 2007 4:51 am Post subject: |
|
New WIP up, and this one is not for playing games on.
I replaced the memory mapper entirely with a new system that should be
infinitely easier to remap dynamically. This is a necessary step for
BS-X MMIO register emulation. It should also speed up S-DD1 emulation
by eliminating the need for a special address conversion routine to
simulate its memory mapper.
However, the new bus memory mapper is anything but complete. Right now,
it only loads really, really basic LoROM games. Stick to Super Mario
World and Zelda 3.
Some good news is that it's ~1-2% faster with MinGW4, but the bad news
is that it's ~10% slower with Visual C++, and MS' compiler is stupidly
storing my 128kb array directly into the EXE, making the file size
bigger. And yet the ZIP of the whole thing is smaller! >_<
Bah. I think I can fine tune most of the performance lost back out of
Visual C++ with some forced inlining, and I'll make that WRAM array
allocate at runtime.
Surprised I was able to get any games playable in less than three
hours, replacing the entire memory mapping system like that. Lucky me.
Quote: |
-O8
-mtune=prescott -ffloat-store -fforce-addr -finline-functions
-fexpensive-optimizations -funroll-all-loops -ffast-math
-fomit-frame-pointer |
I didn't realize you could go above -O3 ... interesting. If you want,
try building with profile guided optimizations for another ~15% speed
boost. It's pretty unstable like that, though. Maybe you'll have better
luck than me.
The warning message is in src/cart/cart_file.cpp at the top.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Oct 17, 2007 6:54 am Post subject: |
|
So Nach, basically what you are saying is:
Any BS game that works in Bsnes when loaded as a regular rom has been hacked to work on copiers/emulators right?
that would mean that basically every BS game in the no-intro dat is a hack |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Wed Oct 17, 2007 1:24 pm Post subject: |
|
byuu wrote: |
Quote: |
-O8
-mtune=prescott -ffloat-store -fforce-addr -finline-functions
-fexpensive-optimizations -funroll-all-loops -ffast-math
-fomit-frame-pointer |
I didn't realize you could go above -O3 ... interesting. If you want,
try building with profile guided optimizations for another ~15% speed
boost. It's pretty unstable like that, though. Maybe you'll have better
luck than me.
The warning message is in src/cart/cart_file.cpp at the top.
|
Just to clarify: Cases where the number in the -O flag is greater than
three are treated as -O3, and gcc probably doesn't warn about this. I
read this from Gentoo Forums and it was proved by quoting a few lines
from gcc's source code.
I have built bsnes (older versions) with additional flags
-arch=athlon64 and -msse3 and I haven't noticed any speed increase.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 17, 2007 2:34 pm Post subject: |
|
so
is there no way to scan to make sure bsx games are clean with something
like NSRT? It's just too bad we don't know more about them.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Oct 17, 2007 4:38 pm Post subject: |
|
With
GCC 4.2 one can use -mtune=native and it will optimize the binary as
per what features your CPU supports. If it supports SSE1/2/3 those kind
of optimizations will be enabeld etc.
From GCC 4.2 changes list:
Quote: |
New Targets and Target Specific Improvements
IA-32/x86-64
* -mtune=generic can now be used to generate code running well on
common x86 chips. This includes AMD Athlon, AMD Opteron, Intel
Pentium-M, Intel Pentium 4 and Intel Core 2.
* -mtune=native and -march=native will produce code optimized for the
host architecture as detected using the cpuid instruction. |
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Oct 17, 2007 7:18 pm Post subject: |
|
Found a bug.
Battletoads in Battlemaniacs Level 4 part 2 has the sprite priority wrong.

The snake is supposed to be going through the hole, not behind it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Oct 17, 2007 7:57 pm Post subject: |
|
Post NSRT info!!!
...Joking, joking : -D
I might test it on real hardware to confirm later.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Oct 17, 2007 8:07 pm Post subject: |
|
Snark wrote: |
Post NSRT info!!!
|
Sure!
Code: |
NSRT v3.5 - Nach's SNES ROM Tools
-------------------------Container--------------------------
File: Battletoads in Battlemaniacs (U)
Sub File: Battletoads in Battlemaniacs (U)
---------------------Internal ROM Info----------------------
Name: BT IN BATTLEMANIACS Company: Midway/Tradewest
Header: None Bank: LoROM
Interleaved: None ROM: 8 Mb
Type: Normal SRAM: 0 Kb
Expansion: None Battery: None
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x6756 Game Code: None
---------------------------Hashes---------------------------
CRC32: 617AC925
MD5: E44B9987E33EF7237B24457A6C997723
RIPEMD: B6AFCAAC20883679FCF670531D22ACED57A12E05
SHA-1: 3041C5C2A88449CF358A57D019930849575F8F6D
SHA-256: B0DBD4D7E5689C32234E80B0C5362EF67C425AB72D6DDB49D1CB1133EF630EF7
SHA-512: 4D34BB803C3A217D042D5A9038F1D1C9A5E1D6DBC8A020F425CB41068E6D706A
8F753C1DD1E6EE77B025F04E3A16969ECE579413F49B7D03230E697014C14B80
Tiger: 9040B4AE845B52D3E5307C31DAABF02CBEB0CF0593DC73FD
Whirlpool: E06E0E5F91DBF952DF385B03CA87962768D5F5A0E4230F40CB864FBD66E50A6A
EEA63417DDDEEC9BA98C033FFD4CAA0325E36AE58228F869A323DCF8E76A9A6B
--------------------------Database--------------------------
Name: Battletoads in Battlemaniacs
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Fighting Genre 2: Brawler
|
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 17, 2007 8:13 pm Post subject: |
|
Good
to know, thanks. Hardware confirmation's always nice, but this one
looks like it'll be a bug. Besides, I imagine Nach knows this game
quite well.
If it's using FirstSprite+Y priority,
I don't emulate that because I don't really understand anomie's
explanation of it, and I lack test ROMs for it. I'll worry more about
this bug if and when I get to working on a cycle-based S-PPU.
Otherwise, it's way too far into the game to test it repeatedly. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Oct 17, 2007 8:20 pm Post subject: |
|
byuu wrote: |
Good
to know, thanks. Hardware confirmation's always nice, but this one
looks like it'll be a bug. Besides, I imagine Nach knows this game
quite well.
|
I don't recall seeing this in the actual game. However, I know from
experience that the Battletoads series were tricky and not bug tested
enough. It could be this does happen in game if the circumstances are
right.
Not only would I test it in hardware, I'd check this point in multiple
lives, to see if something doesn't screw it up with one of them.
Something like this though, I would think they'd notice. And if they
were intelligent enough to have a debug ROM with a level select code,
they definitly should've been able to test this portion enough, in
which case, I can't imagine such a bug escaping notice by the
developers.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 17, 2007 10:31 pm Post subject: |
|
byuu wrote: |
Good
to know, thanks. Hardware confirmation's always nice, but this one
looks like it'll be a bug. Besides, I imagine Nach knows this game
quite well.
If it's using FirstSprite+Y
priority, I don't emulate that because I don't really understand
anomie's explanation of it, and I lack test ROMs for it. I'll worry
more about this bug if and when I get to working on a cycle-based
S-PPU. Otherwise, it's way too far into the game to test it repeatedly. |
is this just in the most recent version or more versions?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 17, 2007 10:49 pm Post subject: |
|
Panzer88 wrote: |
byuu wrote: |
Good
to know, thanks. Hardware confirmation's always nice, but this one
looks like it'll be a bug. Besides, I imagine Nach knows this game
quite well.
If it's using
FirstSprite+Y priority, I don't emulate that because I don't really
understand anomie's explanation of it, and I lack test ROMs for it.
I'll worry more about this bug if and when I get to working on a
cycle-based S-PPU. Otherwise, it's way too far into the game to test it
repeatedly. |
is this just in the most recent version or more versions?
|
FirstSprite+Y has never been emulated in bsnes. It's in the readme.
I'll confirm this bug soon. Time to take old ugly out of its storage box again.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 17, 2007 11:12 pm Post subject: |
|
FitzRoy wrote: |
Panzer88 wrote: |
byuu wrote: |
Good
to know, thanks. Hardware confirmation's always nice, but this one
looks like it'll be a bug. Besides, I imagine Nach knows this game
quite well.
If it's using
FirstSprite+Y priority, I don't emulate that because I don't really
understand anomie's explanation of it, and I lack test ROMs for it.
I'll worry more about this bug if and when I get to working on a
cycle-based S-PPU. Otherwise, it's way too far into the game to test it
repeatedly. |
is this just in the most recent version or more versions?
|
FirstSprite+Y has never been emulated in bsnes. It's in the readme.
I'll confirm this bug soon. Time to take old ugly out of its storage box again.
|
that's odd I somehow didn't hear that before and still can't find it in
the readme or on the site. I guess if byuu is going to wait till he
does the PPU to do this too then that's pretty important, especially
being part of the base hardware.
also what is the difference between dot based, and cycle based PPU?
maybe you should post emu limitations on your page byuu next to "bugs - none" so people aren't mislead.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 17, 2007 11:30 pm Post subject: |
|
Christ
Nach, pick a more difficult bug to get to, will ya? This game's hard as
fuck and there's no sram and no level select code.
Anyway, take a look at this youtube video of what the level is like.
I'm guessing it was captured with zsnes, so it's not reference, but
take note of the smoke appearing on top ("coming out") of the holes
almost every time the snake goes in or out of them. It looks like a
clever way to AVOID having to do the snake-through-wall-blend, but for
whatever reason they don't smoke on a few entries (0:35), making the
shortcut blatantly noticeable. I'll still try to confirm it, but I'm
guessing it's not a bug.
http://youtube.com/watch?v=12fP4JFN7VQ
Panzer88 wrote: |
maybe you should post emu limitations on your page byuu next to "bugs - none" so people aren't mislead. |
There is a known bugs list, and this bug was not known and still hasn't
been confirmed. No one's being misled. Even if it is a bug,
FirstSprite+Y may not be the cause. Lack of support is right there in
the readme. Do a search for the words if you have to.
Last edited by FitzRoy on Thu Oct 18, 2007 12:12 am; edited 3 times in total
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 17, 2007 11:42 pm Post subject: |
|
sorry I missed it in the readme the first time, I thought it would be on the site also.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 17, 2007 11:57 pm Post subject: |
|
FitzRoy wrote: |
Christ Nach, pick a more difficult bug to get to, will ya? This game's hard as fuck ... |
QFT.
Also,
ZSNES v1.51:

SNES9x v1.51:

My notes so far show that this screen uses BG Mode1, and both the snake
and the wall are on BG1. The wall tiles have the priority bit set, but
the snake tiles do not. I really see no sane way the snake could blend
into this wall properly. But I won't rule it out as impossible until we
confirm on hardware.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 18, 2007 12:19 am Post subject: |
|
I confirmed that the bug happens in this too:
Code: |
NSRT v3.5 - Nach's SNES ROM Tools
-------------------------Container--------------------------
File: BETA Battletoads in Battlemaniacs (U).gz
Sub File: BETA Battletoads in Battlemaniacs (U)
---------------------Internal ROM Info----------------------
Name: BT IN BATTLEMANIACS Company: Midway/Tradewest
Header: None Bank: LoROM
Interleaved: None ROM: 8 Mb
Type: Normal SRAM: 0 Kb
Expansion: None Battery: None
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x197E Game Code: None
---------------------------Hashes---------------------------
CRC32: 1783E3A2
MD5: 6B042DA023E26CF195689FA182C19A0E
RIPEMD: 7DDBBA99C8352F2D50EB1AAD7AFDCAAE28C6E08B
SHA-1: 650680FA4DA5D4F0B319451B4E3BD5B828585CFB
SHA-256: 14A66C1DED5E59E8AD7D6A42F0ACCCBD4C3F54D1CBC5520AA6F2B39A21D39E38
SHA-512: FD3CA25D2986ABD070E5DE57319E5AF9BB0E00A61585BD1DE858DEC2801BC227
A4CDA9668A458E9F5DD54DD190C766D501E685D658616D5BED2F3C702F24191E
Tiger: D6322C5113C03B65811DA1D6912D5C9920976612097528C5
Whirlpool: C02EA07DE30DA77B991494EA7A48C22C7ABAF8135B76442BFA51287C8AC8FFB4
40216514E7D3B2A31C1A60F08D6FF14919324BC2DBF0A1A74D436921E8E86E72
--------------------------Database--------------------------
Name: BETA Battletoads in Battlemaniacs
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Fighting Genre 2: Brawler
|
I played the whole game start to finish, it's the only bug I found.
I must also say that man the 3rd level (4th if you count bonus level),
the one with the race, has the last part massively hard in bsnes with
the speed changing during play. You actually made me lose a life there
byuu 
I only had 8 lives left when beating the game 

_________________
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 Thu Oct 18, 2007 12:39 am; edited 2 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 18, 2007 12:31 am Post subject: |
|
Course, when you've played it before... |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 18, 2007 12:39 am Post subject: |
|
Okay,
I'm a bit nuts, but I went ahead and decided to test two players. I
mapped both players to the same input, and played until that point:

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
anonyman New Member
Joined: 01 Apr 2006
Posts: 4
|
Posted: Thu Oct 18, 2007 12:59 am Post subject: |
|
Nach wrote: |
Okay,
I'm a bit nuts, but I went ahead and decided to test two players. I
mapped both players to the same input, and played until that point:
 |
this why i like readng
leet devs play hard game as two persons
you show more?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 18, 2007 6:12 am Post subject: |
|
In
case I didn't specify earlier, since both the snake and the wall is on
BG1, this is not a FirstSprite+Y bug. And this is part of why I haven't
emulated FS+Y ... there are zero known examples of it. I'd probably
implement it anyway if I understood the behavior enough to make a test
ROM, but I'll definitely pay attention to it when I rewrite the S-PPU.
I honestly have no idea how the real game could possibly make the snake go through that hole in the wall.
Anyway, I finally figured out how to tell if a window has focus.
GTK_WIDGET_HASFOCUS is not it, you want to use gtk_window_is_active().
All two Linux users should be happy that input is no longer read when
bsnes is in the background.
Now to go work more on the new memory mapper ... |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 18, 2007 8:47 am Post subject: |
|
Fuck......!!!
That's it. I'm beginning to think this is yet another cruel joke made
by Nach :rolls: he knows this is no emulator bugs... only this time,
the testers are the butt of the joke 
Ok, I only need to know one thing: In the race level, how the hell do
you made the jump just before the first (green) enemy appears? Is there
a trick or something? Or is it just a matter of presing jump exactly
the right time, like, not 0.01sec too late not 0.01 too early?
edit: nevermind Saw a vid and I think you're supposed to bump on some sort of rock or something :sigh:
Last edited by Snark on Thu Oct 18, 2007 8:55 am; edited 1 time in total |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Oct 18, 2007 8:52 am Post subject: |
|
Snark wrote: |
Fuuuck......!!!
That's it. I'm beginning to think this is yet another cruel joke made
by Nach, only this time, the testers are the butt of the joke  |
Too bad it isn't a joke. When someone loves a particular game,
seemingly minor details become blantently obvious like "the mole" in
the last Austin Powers movie. It is the same thing here.
_________________
FF4 research never ends for me.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Oct 18, 2007 9:01 am Post subject: |
|
byuu: is it possible there's supposed to be steam appearing there to create the illusion, but isn't?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 18, 2007 9:40 am Post subject: |
|
New
WIP up. This one's a bit better than last, but I don't want bug reports
yet. This one only maps generic LoROM and HiROM games.
Took about four or five hours, but I reworked most of the new memory
mapper yet again. SRAM should be working now, and I managed to gain
back the speed lost by dropping the address masking and forcing Visual
C++ to inline (__forceinline). The masking was no good anyway, because
the ROM file loaded in is definitely not always a power of two, which
means I'd have to use modulus and holy fuck no I'm not adding a
division for every memory access.
The old memory mapper didn't have this either, as it stored a bunch of
pointers into memory chunks. The new one just stores one pointer plus
integer offsets into that pointer (a bit slower but cleaner and
necessary for abstraction), so it's really mostly the same thing.
Man, I was looking at my old generic LoROM / HiROM mapper, and the
difference from that and what I have now is astounding ... it would
seem I've certainly gotten better at programming since then.
Code: |
/* new */
void sBus::map_generic() {
switch(cartridge.info.mapper) {
case Cartridge::LOROM: {
map(MapLinear, 0x00, 0x3f, 0x8000, 0xffff, memory::rom);
map(MapLinear, 0x80, 0xbf, 0x8000, 0xffff, memory::rom);
map(MapLinear, 0x40, 0x7f, 0x0000, 0xffff, memory::rom);
map(MapLinear, 0xc0, 0xff, 0x0000, 0xffff, memory::rom);
} break;
case Cartridge::HIROM: {
map(MapShadow, 0x00, 0x3f, 0x8000, 0xffff, memory::rom);
map(MapShadow, 0x80, 0xbf, 0x8000, 0xffff, memory::rom);
map(MapLinear, 0x40, 0x7f, 0x0000, 0xffff, memory::rom);
map(MapLinear, 0xc0, 0xff, 0x0000, 0xffff, memory::rom);
} break;
}
if(memory::sram.size() == 0) { return; }
map(MapLinear, 0x20, 0x3f, 0x6000, 0x7fff, memory::sram);
map(MapLinear, 0xa0, 0xbf, 0x6000, 0x7fff, memory::sram);
map(MapLinear, 0x70, 0x7f, 0x0000, 0x7fff, memory::sram);
if(cartridge.info.mapper != Cartridge::LOROM) { return; }
map(MapLinear, 0xf0, 0xff, 0x0000, 0x7fff, memory::sram);
}
/* old */
void bMemBus::cart_map_generic(uint type) {
uint rom_size = cartridge.info.rom_size;
uint ram_size = cartridge.info.ram_size;
for(uint page = 0x0000; page <= 0xffff; page++) {
if(memory_type(page << 8) != TYPE_CART)continue;
uint addr = page << 8;
uint bank = page >> 8;
//RAM mapping is incorrect in several games, this is the most compatible
//layout I can create using only ROM header information. Additional accuracy
//requires PCB identification.
//Unmapped region
//$[00-1f|80-9f]:[6000-7fff]
if((bank & 0x7f) >= 0x00 && (bank & 0x7f) <= 0x1f
&& (addr & 0xe000) == 0x6000) {
continue;
}
//HiROM RAM region
//$[20-3f|a0-bf]:[6000-7fff]
if((bank & 0x7f) >= 0x20 && (bank & 0x7f) <= 0x3f
&& (addr & 0xe000) == 0x6000) {
if(ram_size == 0)continue;
addr = ((bank & 0x7f) - 0x20) * 0x2000 + ((addr & 0xffff) - 0x6000);
addr %= ram_size;
page_handle[page] = cartridge.ram + addr;
page_read [page] = &bMemBus::read_ram;
page_write [page] = &bMemBus::write_ram;
continue;
}
//LoROM RAM region
//$[70-7f|f0-ff]:[0000-7fff]
//Note: WRAM is remapped over $[7e-7f]:[0000-ffff]
if((bank & 0x7f) >= 0x70 && (bank & 0x7f) <= 0x7f
&& (addr & 0x8000) == 0x0000) {
if(!(bank & 0x80) || type == Cartridge::LOROM) {
//HiROM maps $[f0-ff]:[0000-7fff] to ROM
if(ram_size == 0)continue;
addr = ((bank & 0x7f) - 0x70) * 0x8000 + (addr & 0x7fff);
addr %= ram_size;
page_handle[page] = cartridge.ram + addr;
page_read [page] = &bMemBus::read_ram;
page_write [page] = &bMemBus::write_ram;
continue;
}
}
//ROM region
switch(type) {
case Cartridge::LOROM: {
addr = (bank & 0x7f) * 0x8000 + (addr & 0x7fff);
addr = mirror(rom_size, addr);
} break;
case Cartridge::HIROM: {
addr = mirror(rom_size, addr);
} break;
}
page_handle[page] = cartridge.rom + addr;
page_read [page] = &bMemBus::read_rom;
page_write [page] = &bMemBus::write_rom;
}
} |
Note that those two certainly aren't identical in function, and I'll no
doubt have some memory mapping bugs again (probably with Final Fight,
SFII and such), but it should only require minor changes to fix that.
Quote: |
byuu: is it possible there's supposed to be steam appearing there to create the illusion, but isn't? |
That's a lot more likely, honestly. Hopefully someone can make it to level 5, heh. I know I sure as hell can't.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 18, 2007 10:07 am Post subject: |
|
Fuuuuck....!!! FINALLY...!
"Only" took me two hours...urg!
Anyway:
BUG CONFIRMED TO HAPPEN ON HARDWARE (and there's no fog present either)
(And no, I didn't test it many times, with two players, while jumping etc)
edit: thanks for the video Nach, but it looks like I finished it about
the same time you posted it.Still appreciated. If anyone else wants to
take a shot at it, better look at Nach's vid record...the racing stage
is a bitch..Also remember to press B/Jump to bump on the rocks later in
the stage..
Last edited by Snark on Thu Oct 18, 2007 8:33 pm; edited 2 times in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 18, 2007 10:26 am Post subject: |
|
Off topic just saw the vid and wondered: would be neat to have a way to
display the input being pressed when playing back a movie in
Zsnes...might help in certain game or some people might want that info.
Anyway I'll post in the feature request.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Oct 18, 2007 11:06 am Post subject: |
|
Bug report in Zsnes:
On real hardware in BattleToads in BattleManiac, in the racing stage
when you pass a check point there is a sound effect; this effect is not
present in Zsnes (note that I didn't tested this and this is based on
the BB video Nach posted.
I'll test this in bsnes.
edit: Sound is fine in bsnes 0.025
edit2: No bug in Zsnes either. Nach mentionned the video was taken with the beta game. Sorry. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Oct 18, 2007 4:57 pm Post subject: |
|
While
performing standalone tests on the new ranged memory mapper, I noticed
a flaw: by using modulus on size, it's effectively making the mirror()
call pointless.
But I found an even more flexible
way of doing things. Still allow an optional size modulus, but default
it to being off. Now, the memory mapper will by default mirror offsets
up to powers of two (can never go out of bounds with this mirroring),
and the mapper routine can take an optional modulus of any value. I'm
also moving the mirror() call into the single-page map() call that the
ranged map() call uses. Should make it mostly bullet-proof.
So, in a sense, you can now optionally specify both start and end
points from within a raw medium, and specify multiple mapping modes for
how to plot each individual page.
Given the sheer simplicity and power, I was thinking it'd be nice to
take advantage of that to add a new power user toy. How about we come
up with a .map file format that is capable of storing mapping
information for individual files? It would allow others to experiment
and do things that take me a lot longer to get into public builds, such
as the Yoshi's Island mapper to get audio, BS-X BIOS loading, etc etc.
One could in theory easily map even neviksti's 96MB Star Ocean ROM, and
I wouldn't have to support it directly in bsnes (as it's not an
official mapper anyway).
I'd like to standardize on the format in case other emulators decide to
support it. The cht file format is a wreck now, by comparison.
Two ways of doing this:
1) have a unique text file for each PCB name and a mapper/ folder. This
would have eg "SHVC-1A3M-20.map", and then we just need to store the
PCB info somewhere else (either in the header or as another .map file)
2) have the entire mapper inside the .map file for each .smc file. More flexible, but harder to use.
Both of those would help eliminate the need for a database. I could
code a tool to help visually map the ROM files for novices. Overall, it
won't be a killer feature by any means, but I think it'd be neat. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Oct 18, 2007 7:02 pm Post subject: |
|
I support a common library of mapping definition files with the odd game custom one.
Well, maybe not as a library of files, the distribution could get messy. But something with the same effect.
Maybe one big text file in some nice format.
I still think that you should provide some fallback detection, there
will be less clued in people who will run it without any support files
and with a bad dump.
I am sure there is some rom database that could store the id of the mapping to use for each known good dump.
There is one big issue with this through, the S-FX chip and how it sits in the middle of everything. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Oct 18, 2007 11:29 pm Post subject: |
|
byuu wrote: |
One
could in theory easily map even neviksti's 96MB Star Ocean ROM, and I
wouldn't have to support it directly in bsnes (as it's not an official
mapper anyway). |
You shouldn't have to support that rom under any system.
byuu wrote: |
Both of those would help eliminate the need for a database. |
And in return make users jump through hoops to get certain licensed
games working. What is it about a database that bothers you so much?
Database+fallback detection seems like the best all-round solution an
emulator can use. Actually, modifiable database+fallback detection is
probably the best.
EDIT: Then again, if you say that every different PCB code needs to be
supported internally before a user can define a game entry with it and
have it work, then that's obviously going to be a PITA for you. I'm
trying to understand the scope of the issue in simpler terms. If this
is true, then what you've been doing seems to be the most practical
solution, using detection for the bulk of games and the DB for the few
games that absolutely need specifically mapped to work properly.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Oct 19, 2007 8:01 am Post subject: |
|
If
you are going for the pcb info inside the zip idea, may i suggest using
the XML file that was discussed before, and is being discussed for the
nes?
Also i have said before, over at no-intro we
now have pcb information for about 40-50%(guestimate) off all the games.
Either way, the database could be updated or, xml (or .map) files could be made easily for most official games.
I support the idea for manually creating mappers to support wierd games  |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Oct 19, 2007 4:43 pm Post subject: |
|
Don't
put these mapping files inside each cartridge file, since that makes
fixing errors a mess. It's easy enough to be sure the ROM dumps are
correct (by dumping them more than once and comparing), but a new
mapping format is bound to result in some erroneous mapping files.
Seems better to have the cartridge file reference the board name only,
with the emulator keeping a database of the board wirings that can be
fixed much more easily. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 19, 2007 5:04 pm Post subject: |
|
One
thing that's always bothered me about C++ emulator programming was that
no sizes were guaranteed. You get around that a little with
<stdint.h>, and indeed I even use that file despite Visual C++
being behind the times, hence VC++ users have to fetch that file
elsewhere first.
But even then, that only keeps
uint8_t, uint16_t, uint32_t and uint64_t. This isn't very nice for a
lot of SNES-related stuff. Specifically, let's say address bus accesses
... they use 24-bit addressing, so ideally a bus write function would
look like this:
void Bus::read(uint24_t addr, uint8_t data);
Instead, I'm now forced to use uint32_t and either clamp off the top
eight bits manually when needed, or risk the chances of crashing if a
value > 0xffffff is passed to it.
Now, I have a workaround for this, I wrote a template class that allows
me to create my own sub-exponential unit sizes, which looks like this
(cut out some functions for space):
Code: |
template<int bits> inline unsigned uclip(const unsigned x) {
enum { m = (1ULL << bits) - 1 };
return x & m;
}
template<unsigned bits, typename T = unsigned> class uint_t {
private:
T data;
public:
inline operator T() const { return data; }
inline T operator ++(int) { T r = data; return data = uclip<bits>(data + 1), r; }
inline T operator --(int) { T r = data; return data = uclip<bits>(data - 1), r; }
inline T operator ++() { return data = uclip<bits>(data + 1); }
inline T operator --() { return data = uclip<bits>(data - 1); }
template<typename N> inline T operator =(const N i) { return data = uclip<bits>(i); }
template<typename N> inline T operator |=(const N i) { return data = uclip<bits>(data | i); }
inline uint_t() : data(0) {}
inline uint_t(const T i) : data(uclip<bits>(i)) {}
}; |
I also have one for signed integers, but you get the idea.
Anyway, the problem with using this class is speed. Specifically,
compiling without optimizations, using these "integer objects" is 3-4x
slower than normal. But with optimizations, there's hardly a difference
at all. I can't imagine anyone sane building even debug versions of
bsnes with optimizations off.
<1.6 billion [for you Bits, 1,600,000,000] add operations>
GCC 4.2:
5703 -1328482304
5734 -1328482304
skew = 0.994594x
Visual C++ 8.0:
4421 -1328482304
4313 -1328482304
skew = 1.025041x
I can use the above template class like this:
typedef uint_t<24> uint24; //or uint24_t;
... and suddenly I have a nice way to make that clamping intrinsic. But
it'll cut into speed a bit to use this. Think it's worth it for the
code clarity?
Quote: |
Seems
better to have the cartridge file reference the board name only, with
the emulator keeping a database of the board wirings that can be fixed
much more easily. |
That's the idea I liked, but that lacks the flexibility to create one's own custom mapper. Perhaps allow both?
Code: |
[rom1.smc]
board = SHVC-1A3M-20
[rom2.smc]
board = custom(
linear, 0x00, 0x3f, 0x8000, 0xffff, rom
linear, 0x70, 0x7d, 0x0000, 0xffff, ram
) |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Oct 19, 2007 5:24 pm Post subject: |
|
Can someone explain to me why custom mappers are so important? Why can't people just use standard mappers? |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Oct 19, 2007 6:53 pm Post subject: |
|
byuu wrote: |
One
thing that's always bothered me about C++ emulator programming was that
no sizes were guaranteed. You get around that a little with
<stdint.h>, and indeed I even use that file despite Visual C++
being behind the times, hence VC++ users have to fetch that file
elsewhere first.
But even then, that only keeps uint8_t, uint16_t, uint32_t and uint64_t. |
I've been planning to get rid of the <stdint.h> dependency in
gambatte (it's C99 only, so not C++98). C++0x will have a cstdint, but
specific width types will probably never be mandatory (nor will
[u]intptr_t sadly). As you've shown this can be easily worked around
(if you use uint_leastN_t base types all masks are usually optimized
away). For pointers to stuff that is used outside the library I'll just
have them be uint_leastN_t pointers and have the (library) user handle
any conversion. For now one could depend on tr1, but it's a bit
inconvenient since for instance boost's tr1 doesn't really include
cstdint event though boost has a cstdint in the integer library.
Another way is to use a HAS_STDINT or HAS_CSTDINT macro, and otherwise
define your own types.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 19, 2007 8:32 pm Post subject: |
|
Quote: |
Can someone explain to me why custom mappers are so important? Why can't people just use standard mappers? |
Mainly because we'll never have all mappers known. It really doesn't
help too terribly much, just allows mapping of some odd ROMs like
copier BIOSes and X-Band, unsupported special chips, and such. I was
just throwing the idea out there since it's something trivial to
implement now.
Ideally, we'd have all PCBs defined within the emulator, and a much,
much better generic mapper to handle cases where exact mappers are not
known.
Quote: |
I've been planning to get rid of the <stdint.h> dependency in gambatte (it's C99 only, so not C++98). |
This is true that it's not C++98 ... I've actually been considering this as well.
Quote: |
As you've shown this can be easily worked around (if you use uint_leastN_t base types all masks are usually optimized away). |
Unfortunately, (u)int_leastN_t types are also from stdint.h, and what's
even screwier is that their definitions technically allow
uint_least128_t to only store 64-bits, if the vendor chooses.
But you're right that if we get the right base unit sizes, the masks
will be removed through optimizations, so there should be no speed
penalties at all for 8-bit, 16-bit, 32-bit and 64-bit integers. We
could define platform-specific blocks to declare these types to
optimize for the only platforms that are actually used (Windows, Mac
and Linux/BSD), and default the rest to the largest sizes for variables.
And unfortunately, there will always be grave performance penalties for
using these without compiler optimizations enabled. Compilers just love
to make template code ridiculously complex.
I need to complete the left/right side math operators (non-assignment
based), convert the returns of assignment ones to *this, and then I'll
post up the library when it's done. I think I'll call it varint.h.
You're free to use it as PD if you like.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Oct 20, 2007 5:11 am Post subject: |
|
Remind
me again why fixed-width types are important (outside of uint8_t),
especially a 24-bit type. Preferably, show some short "with" and
"without" code examples. I'm just wondering what problems these solve
that a mask here and there doesn't solve. |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 20, 2007 5:54 am Post subject: |
|
PCB info for most games is already known or can be guestimated using fitzroy and y~k's pcb info.
byuu have you ever seen this information? i would guess that you can
already create this database and best case scenario generic mapper |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 20, 2007 6:15 am Post subject: |
|
blargg wrote: |
Remind
me again why fixed-width types are important (outside of uint8_t),
especially a 24-bit type. Preferably, show some short "with" and
"without" code examples. I'm just wondering what problems these solve
that a mask here and there doesn't solve. |
It doesn't solve anything. It just makes the code look a bit nicer.
Code: |
void sBus::read(uint32 addr) {
return bus[addr & 0xffffff];
}
void sCPU::op_writedbr(uint32 addr, uint8 data) {
op_write(((regs.db << 16) + addr) & 0xffffff, data);
}
//
void sBus::read(uint24 addr) {
return bus[addr];
}
void sCPU::op_writedbr(uint24 addr, uint8 data) {
op_write((regs.db << 16) + addr, data);
}
|
The masks aren't hard to do at all, but you know ... why have code you
don't have to have? I'm really big on absolutely minimizing red tape
and coming up with the smallest solutions to problems, and my approach
doesn't even appear to incur much of a speed hit at all.
There's also the sheer elegance of using SNES-native sizes, especially
when one of your main goals is making your code as self-documenting as
possible (silly as that idea is -- code will never replace true
documentation.)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 20, 2007 6:51 am Post subject: |
|
byuu wrote: |
Ideally,
we'd have all PCBs defined within the emulator, and a much, much better
generic mapper to handle cases where exact mappers are not known. |
I was just thinking that you might want to get dynamic mapping equal
with the previous system before before thinking about some new format.
The way you described it, it sounded like needless complexity to allow
for a non-existant homebrew scene the ability to do something they
probably don't need to in the first place. And even though I dump a
bunch of games and decyphered what the codes mean, I have very little
understanding of their significance in emulation. What is the
difference, code-wise, for example, between the mapper for SHVC-1A0N-01
and SHVC-1A0N-02? And which mapper do you choose when the same data is
known to exist under two different board codes?
Let me see if I understand the current system correctly: since the
majority of games use the same "SHVC" type board, and have internal
attributes that can be scanned and correlated to the second code, then
bsnes can effectively guess a correct or "working" mapping in 95% of
cases without any need for a database. The NES is different and can't
do this because their rom data doesn't contain this info, and there was
really no standardization on Nintendo's part, meaning that mappers were
a company defined free-for-all. Is this at least somewhat correct?
Here's something else I don't get. YS III needs to be in the database
to have its saves work correctly. Its board type is SHVC-1A3B-12. I
know of two other games that I dumped that have this same exact code,
yet their saves work fine. Why?
|
|
Overload Hazed
Joined: 17 Sep 2004
Posts: 94
|
Posted: Sat Oct 20, 2007 8:25 am Post subject: |
|
FitzRoy wrote: |
Here's
something else I don't get. YS III needs to be in the database to have
its saves work correctly. Its board type is SHVC-1A3B-12. I know of two
other games that I dumped that have this same exact code, yet their
saves work fine. Why? |
It's because YS III writes save data to $xx8000 - $xxffff where as the
other games write save data to $xx0000 - $xx7fff which is fine on the
SHVC-1A3B board because sram is mapped $xx0000 - $xxffff but not on the
SHVC-1A3M board which maps sram $xx0000 - $xx7fff. There is no way of
detecting which board the game used from the rom itself.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Oct 20, 2007 8:58 am Post subject: |
|
Overload wrote: |
FitzRoy wrote: |
Here's
something else I don't get. YS III needs to be in the database to have
its saves work correctly. Its board type is SHVC-1A3B-12. I know of two
other games that I dumped that have this same exact code, yet their
saves work fine. Why? |
It's because YS III writes save data to $xx8000 - $xxffff where as the
other games write save data to $xx0000 - $xx7fff which is fine on the
SHVC-1A3B board because sram is mapped $xx0000 - $xxffff but not on the
SHVC-1A3M board which maps sram $xx0000 - $xx7fff. There is no way of
detecting which board the game used from the rom itself.
|
Ah, that explains it nicely. You're right, the fourth digit of the
middle code is the one digit that can't really be obtained from the rom
because it denotes the memory decoder chip type. M is MAD-1 and B is
74LS139. I have at least one example of duplicate carts yielding an "M"
on one board and a "B" on the other, which made me think that B and M
were just interchangeable parts with no significance for emulation. But
apparently it's possible for a game to be specifically coded with one
or the other in mind?
By the way, did OVERLOAD just post for the first time in a year?
Awesome. Don't tell me that you haven't come back to RE special chips
until tomorrow as I'd like to dream it in my sleep tonight.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Oct 20, 2007 2:04 pm Post subject: |
|
byuu wrote: |
It doesn't solve anything. It just makes the code look a bit nicer.
Code: |
void sBus::read(uint32 addr) {
return bus[addr & 0xffffff];
}
void sCPU::op_writedbr(uint32 addr, uint8 data) {
op_write(((regs.db << 16) + addr) & 0xffffff, data);
} |
|
Personally I'd never do that in the function itself. Valid parameters
are 24-bit, otherwise the calling code is broken. Besides, it slows
down the code that is passing the correct values.
For debugging purposes one could use an assert().
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Oct 20, 2007 5:10 pm Post subject: |
|
The
bsnes WIP which I posted here a while back had NSRT display info and
pulled PCB data from there, which was generated from the info.
Yes you can tell the difference between M and B, and the cases where you can't, it's because it doesn't matter.
The WIP I posted didn't screw up on YS III, right?
No database or info besides what is in the ROM is needed. It can all be generated.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 23, 2007 7:48 am Post subject: |
|
Seems I've burned out again. Damn. I'll have to go a little slower for a while.
So Nach, I'm fine with omitting the middle step of ROM->PCB->map
... how simplified do you think we can get a generic memory mapper that
works for all cases? I don't want it to be too monstrous if at all
possible.
If we can get that working completely, I'll stop distributing cart.db
with bsnes, though I still like the idea of direct PCB mapping so I'll
probably leave backend support for it or something for power users.
---
Offtopic, as a testament to my pitifulness, I'm reading comics at 4AM and come across this one: http://xkcd.com/287/
Of course, I'm sure every programmer who sees that is compelled to solve it. Ergo, my solution:
Code: |
int price[] = {
215,
275,
335,
355,
420,
580,
};
int limit[] = {
1505 / 215,
1505 / 275,
1505 / 335,
1505 / 355,
1505 / 420,
1505 / 580,
};
char name[][64] = {
"Mixed Fruit",
"French Fries",
"Side Salad",
"Hot Wings",
"Mozzarella Sticks",
"Sampler Plate",
};
printf("Possible combinations = %d\n\n",
(limit[0] + 1) * (limit[1] + 1) * (limit[2] + 1) *
(limit[3] + 1) * (limit[4] + 1) * (limit[5] + 1));
for(int a = 0; a <= limit[0]; a++) {
for(int b = 0; b <= limit[1]; b++) {
for(int c = 0; c <= limit[2]; c++) {
for(int d = 0; d <= limit[3]; d++) {
for(int e = 0; e <= limit[4]; e++) {
for(int f = 0; f <= limit[5]; f++) {
int result = 0;
result += a * price[0];
result += b * price[1];
result += c * price[2];
result += d * price[3];
result += e * price[4];
result += f * price[5];
if(result == 1505) {
printf("Match:\n");
if(a)printf("%d x %s\n", a, name[0]);
if(b)printf("%d x %s\n", b, name[1]);
if(c)printf("%d x %s\n", c, name[2]);
if(d)printf("%d x %s\n", d, name[3]);
if(e)printf("%d x %s\n", e, name[4]);
if(f)printf("%d x %s\n", f, name[5]);
printf("\n");
}
}
}
}
}
}
} |
Output:
Code: |
Possible combinations = 14400
Match:
1 x Mixed Fruit
2 x Hot Wings
1 x Sampler Plate
Match:
7 x Mixed Fruit |
... I'd make a great waiter ...
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Oct 23, 2007 9:34 am Post subject: |
|
byuu wrote: |
So Nach, I'm fine with omitting the middle step of ROM->PCB->map
... how simplified do you think we can get a generic memory mapper that
works for all cases? I don't want it to be too monstrous if at all
possible.
|
That would depend on what you mean by all cases, and what steps are taken to make it generic.
If you mean something like:
map(-5, -3, -4)
if (a) { map(1, 2, 3) }
else if (b) { map(6, 9, 12) }
else if (c) { map(3, 2, 1) }
if (a || b) { map(25, 16, 42) }
Then yeah, shouldn't be too hard.
The key points I found in mapping would be:
Chips
Expansions
SRAM Presence
Sizes of ROM and SRAM
So called Hi and Lo ROM.
Between that, everything should be mappable correctly.
As for homebrew stuff, instead of coming up with some complex PCB key,
why not just specify some mapper override configurations that can be
included in a copier like header or in something that accompanies the
file?
Even a text file with something like:
$42:* = ROM[0000-FFFF]
$43:* = ROM[10000-1FFFF]
$44:* = RAM[0000-FFFF]
$45:0000-7FFF = RAM[10000-17FFF]
$45:8000-FFFF = ROM[20000-27FFF]
$46:* = 0
$47:* = ROM[0000-FFFF]
Should be fine, as long as we give examples of all existing stuff, and
perhaps offer something to match a copier or two.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Oct 23, 2007 12:50 pm Post subject: |
|
that
actually sounds very logical and straightforward, those copier headers
for custom roms, thats what it would be like on the real thing anyway.
Great idea Nach! |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Oct 23, 2007 3:12 pm Post subject: |
|
Or, we can just hack the detection routine manually for each rom that don't work with the normal detection logic. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Oct 24, 2007 9:18 am Post subject: |
|
IMO
anything that can be detected using just the rom should be. It's only
for the very special cases that the additional customisation would be
nice. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Oct 26, 2007 8:37 pm Post subject: |
|
I
was wondering if someone could provide some linux noob support. I've
got the bsnes source and extracted it. I'm in a terminal in the
directory (bsnes/src) and I type 'make' and it says
"please specify which platform to compile for with PLATFORM=platform_name"
I really know NOTHING about this sort of thing so if someone could let
me know where I'm going wrong or just copy a list of commands that
would be great.
for the record I'm using Kubuntu 7.10 "gutsy gibbon"
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Oct 26, 2007 11:50 pm Post subject: |
|
Sure, I'll lend a hand. Thanks for trying the Linux version -- be sure to let me know how it works for you :)
Run this on your terminal:
32-bit (i386):
Code: |
sudo apt-get install g++ libxv-dev libao-dev libgtk2.0-dev nasm
cd /path/to/bsnes/src
make PLATFORM=x-gcc-lui
sudo cp ./bsnes /usr/bin/bsnes
bsnes |
64-bit (amd64):
Code: |
sudo apt-get install g++ libxv-dev libao-dev libgtk2.0-dev yasm
cd /path/to/bsnes/src
make PLATFORM=x-gcc-lui-x64
sudo cp ./bsnes /usr/bin/bsnes
bsnes |
First line just makes sure you have everything you need. Second to last
is just if you want to run bsnes from any folder. Otherwise, you don't
need it.
Some things to note, I use Xv for video and libao for audio, and both
have some unfortunate shortcomings. Xv's vsync is based on
XV_SYNC_TO_VBLANK, which doesn't work on nvidia's binary driver. The
setting is controlled by a program called xvattr, so it may or may not
be on for you. And if you have fglrx, you may not have Xv support at
all. And libao has horrible latencies (around ~300ms), and I can't stop
it from locking when the buffer fills, meaning you can't disable speed
regulation when it's enabled.
You can change some of this, however. Go to
settings->configuration->advanced, and you can set system.video
to "gtk", which will use pure RGB but will be really bad/slow at
scaling; and you can set system.audio to "none" to mute the sound if
it's too jarring, but you'll want Xv+vsync if you do that, otherwise
you'll get no speed regulation.
I've also recently moved fulltime to Gutsy, so improving the Linux port
is a high priority, however I'm very much in the dark on how to.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 27, 2007 3:51 am Post subject: |
|
thanks
that worked great, and it's cool to see some of the few differences.
I'm sure you'll continue to improve small problems too.
I appreciate it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 27, 2007 5:00 am Post subject: |
|
Sure thing.
Overall though, the goal was to make them as similar as possible.
Before libui, the Linux port was just a graphical window with no
menubar, and no configuration windows. I still have a long way to go
though with polishing and video/audio/input support.
Also, if you really want to use bsnes fulltime, you should check out
-fprofile-generate and -fprofile-use options. I know it's probably a
bit over your head now, but profiling will give you a ~20% speedup that
can't be duplicated with WIndows compilers. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 27, 2007 6:30 am Post subject: |
|
thanks,
I'm still using a slower system but hope to get a new computer sometime
in the semi-near future and I'll surely use bsnes even more then. I am
learning now but thanks for suggesting those things, I'm sure it'll be
useful and it's nice to be taken seriously even if I am a beginner.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 27, 2007 7:19 am Post subject: |
|
People are too hard on beginners to Linux, which just makes people flee back to Windows. Quite the shame ...
You brought up a good point, too. That message when you run make by
itself isn't very useful. Thanks for alerting me to that.
I've updated it as below (be sure to view it with a fixed-width font):
Code: |
help:
@echo "Usage: $(MAKE) PLATFORM=platform [options]"
@echo ""
@echo "Available platform targets:"
@echo " x-gcc-lui - Linux / BSD (i386) (requires nasm)"
@echo " x-gcc-lui-x64 - Linux / BSD (amd64) (requires yasm)"
@echo " win-mingw-lui - Windows (i386) (requires nasm)"
@echo " win-visualc-lui - Windows (i386) (requires nasm)"
@echo ""
@echo "Available options:"
@echo " GZIP_SUPPORT=[true|false] - Enable ZIP / GZ support (default=false)"
@echo " JMA_SUPPORT=[true|false] - Enable JMA support (default=false)"
@echo ""
@echo "Example: $(MAKE) PLATFORM=x-gcc-lui GZIP_SUPPORT=true"
@echo "" |
Formatted, it looks like this:
Code: |
Usage: make PLATFORM=platform [options]
Available platform targets:
x-gcc-lui - Linux / BSD (i386) (requires nasm)
x-gcc-lui-x64 - Linux / BSD (amd64) (requires yasm)
win-mingw-lui - Windows (i386) (requires nasm)
win-visualc-lui - Windows (i386) (requires nasm)
Available options:
GZIP_SUPPORT=[true|false] - Enable ZIP / GZ support (default=false)
JMA_SUPPORT=[true|false] - Enable JMA support (default=false)
Example: make PLATFORM=x-gcc-lui GZIP_SUPPORT=true |
Look good?
Also added a configure script, which is just to alert people that bsnes
does not use the standard Linux build pattern of "./configure
&& make && make install" ...
Code: |
#!/bin/sh
echo "Warning: bsnes does not use a configure script"
echo "To compile bsnes, use make ..."
echo ""
make #prints make usage instructions |
I shy away from ./configure because I don't want to depend on that for
the Windows port, plus I don't see much of a point to it (read: I'm
lazy and don't want to learn it). I like having just one clean makefile.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Oct 27, 2007 7:38 am Post subject: |
|
byuu wrote: |
People are too hard on beginners to Linux, which just makes people flee back to Windows. Quite the shame ...
You brought up a good point, too. That message when you run make by
itself isn't very useful. Thanks for alerting me to that.
I've updated it as below (be sure to view it with a fixed-width font):
Code: |
help:
@echo "Usage: $(MAKE) PLATFORM=platform [options]"
@echo ""
@echo "Available platform targets:"
@echo " x-gcc-lui - Linux / BSD (i386) (requires nasm)"
@echo " x-gcc-lui-x64 - Linux / BSD (amd64) (requires yasm)"
@echo " win-mingw-lui - Windows (i386) (requires nasm)"
@echo " win-visualc-lui - Windows (i386) (requires nasm)"
@echo ""
@echo "Available options:"
@echo " GZIP_SUPPORT=[true|false] - Enable ZIP / GZ support (default=false)"
@echo " JMA_SUPPORT=[true|false] - Enable JMA support (default=false)"
@echo ""
@echo "Example: $(MAKE) PLATFORM=x-gcc-lui GZIP_SUPPORT=true"
@echo "" |
Formatted, it looks like this:
Code: |
Usage: make PLATFORM=platform [options]
Available platform targets:
x-gcc-lui - Linux / BSD (i386) (requires nasm)
x-gcc-lui-x64 - Linux / BSD (amd64) (requires yasm)
win-mingw-lui - Windows (i386) (requires nasm)
win-visualc-lui - Windows (i386) (requires nasm)
Available options:
GZIP_SUPPORT=[true|false] - Enable ZIP / GZ support (default=false)
JMA_SUPPORT=[true|false] - Enable JMA support (default=false)
Example: make PLATFORM=x-gcc-lui GZIP_SUPPORT=true |
Look good?
Also added a configure script, which is just to alert people that bsnes
does not use the standard Linux build pattern of "./configure
&& make && make install" ...
Code: |
#!/bin/sh
echo "Warning: bsnes does not use a configure script"
echo "To compile bsnes, use make ..."
echo ""
make #prints make usage instructions |
I shy away from ./configure because I don't want to depend on that for
the Windows port, plus I don't see much of a point to it (read: I'm
lazy and don't want to learn it). I like having just one clean makefile.
|
The platform targets text is ridiculously helpful, thank you!
I'm still an incredible linux noob, and when I got ./configure, make,
make install down I was so proud (haha) so editing makefiles is still
very intimidating. It's actually keeping me from installing sdlmame
right now, even though I's very much like to use it... I'm just not
sure exactly what to do, even though it seems like a lot of the
makefile is pretty self-explanatory. But yeah, no pressure on you to
learn how to make ./configure and implement it... more pressure on me
to learn how to freaking edit a makefile myself and stop being a pussy
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 27, 2007 8:01 am Post subject: |
|
that's great byuu, I think that'll be a big help to users in the future.
@dancemasterglenn about SDLMame, I just learned this over at the
mameworld message boards. Basically you compile it (you've already got
the hang of it with the make, make install etc. you prolly know more
than I do)
anyways then you go to where you've compiled it and see the name of the mame file.
for me it is just 'mame' but for you it may be followed by an
additional letter or two depending on your processor so whatever that
file is called remember it and then in a terminal type
./mame -createconfig (like I said, if your mame file has two letters
after mame in it, like mamepm for a Pentium M, make sure to include
those letters)
that creates your config.ini then you can simply type
./mame -video opengl -nowindow game
again, where I put 'mame' make sure to include the letters if there are any extra on your file.
where I put 'opengl' you can also put other video things... like sdl (I think ?)
and where I put 'game' is where you put the name of the arcade game zip you want to play.
at least the best I understand it. It works for me. if this explanation
is too long winded or confusing for you read what this guy sad he had two posts and may word things better than I did.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Sat Oct 27, 2007 4:06 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Oct 27, 2007 8:33 am Post subject: |
|
Ok,
finally started working again. I fixed lots of bugs and oversights with
the new memory mapper, and added the first two special chip mappers
back. I'm really liking this new mapping system ... I can now link chip
objects directly into it, rather than having to create a bMemBus
passthrough. Compare the before and after to see what I mean:
Code: |
uint8 bMemBus::read_dsp1 (uint32 addr) { return dsp1.read(addr); }
void bMemBus::write_dsp1(uint32 addr, uint8 data) { dsp1.write(addr, data); }
void bMemBus::cart_map_dsp1() {
if(cartridge.info.dsp1_mapper == Cartridge::DSP1_LOROM_1MB) {
//$[20-3f|a0-bf]:[8000-ffff]
for(uint bank = 0x20; bank <= 0x3f; bank++) {
for(uint page = 0x80; page <= 0xff; page++) {
page_read [0x0000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_read [0x8000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_write[0x0000 + (bank << 8) + page] = &bMemBus::write_dsp1;
page_write[0x8000 + (bank << 8) + page] = &bMemBus::write_dsp1;
}
}
} else if(cartridge.info.dsp1_mapper == Cartridge::DSP1_LOROM_2MB) {
//$[60-6f|e0-ef]:[0000-7fff]
for(uint bank = 0x60; bank <= 0x6f; bank++) {
for(uint page = 0x00; page <= 0x7f; page++) {
page_read [0x0000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_read [0x8000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_write[0x0000 + (bank << 8) + page] = &bMemBus::write_dsp1;
page_write[0x8000 + (bank << 8) + page] = &bMemBus::write_dsp1;
}
}
} else if(cartridge.info.dsp1_mapper == Cartridge::DSP1_HIROM) {
//$[00-1f|80-9f]:[6000-7fff]
for(uint bank = 0x00; bank <= 0x1f; bank++) {
for(uint page = 0x60; page <= 0x7f; page++) {
page_read [0x0000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_read [0x8000 + (bank << 8) + page] = &bMemBus::read_dsp1;
page_write[0x0000 + (bank << 8) + page] = &bMemBus::write_dsp1;
page_write[0x8000 + (bank << 8) + page] = &bMemBus::write_dsp1;
}
}
}
}
// -->
void sBus::map_dsp1() {
switch(cartridge.info.dsp1_mapper) {
case Cartridge::DSP1_LOROM_1MB: {
map(MapDirect, 0x20, 0x3f, 0x8000, 0xffff, dsp1);
map(MapDirect, 0xa0, 0xbf, 0x8000, 0xffff, dsp1);
} break;
case Cartridge::DSP1_LOROM_2MB: {
map(MapDirect, 0x60, 0x6f, 0x0000, 0x7fff, dsp1);
map(MapDirect, 0xe0, 0xef, 0x0000, 0x7fff, dsp1);
} break;
case Cartridge::DSP1_HIROM: {
map(MapDirect, 0x00, 0x1f, 0x6000, 0x7fff, dsp1);
map(MapDirect, 0x80, 0x9f, 0x6000, 0x7fff, dsp1);
} break;
}
} |
Such a difference ... clearly this rewrite was long overdue.
Looks like S-DD1 is going to be the trickiest one to support again, but shouldn't be too hard.
Quote: |
But
yeah, no pressure on you to learn how to make ./configure and implement
it... more pressure on me to learn how to freaking edit a makefile
myself and stop being a pussy |
In this case at least, you don't have to edit anything. You type the
arguments directly on your terminal, eg "./configure --use-x-gcc-lui
&& make" becomes "make PLATFORM=x-gcc-lui". Basically, my
makefile is
my configure script. The benefits are obvious, but the problem is that
it can't (as easily, or at all in bsnes' current state) auto-detect
stuff like configure scripts can.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Oct 27, 2007 8:54 am Post subject: |
|
Panzer88 wrote: |
that's great byuu, I think that'll be a big help to users in the future.
@dancemasterglenn about SDLMame, I just learned this over at the mameworld message boards.
basically you compile it (you've already got the hang of it with the
make, make install etc. you prolly know more than I do)
anyways then you go to where you've compiled it and see the name of the mame file.
for me it is just 'mame' but for you it may be followed by an
additional letter or two depending on your processor so whatever that
file is called remember it and then in a terminal type
./mame -createconfig (like I said, if your mame file has two letters
after mame in it, like mamepm for a Pentium M, make sure to include
those letters)
that creates your config.ini then you can simply type
./mame -video opengl -nowindow game
again, where I put 'mame' make sure to include the letters if there are any extra on your file.
where I put 'opengl' you can also put other video things, I think.
and where I put 'game' is where you put the name of the arcade game zip you want to play.
at least the best I understand it. It works for me. |
Thank you sir, I'll try that out after I get a little shuteye...
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Oct 27, 2007 11:49 am Post subject: |
|
Wow that mapper code now looks tiny in comparison to the old code |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 27, 2007 12:57 pm Post subject: |
|
Panzer88 wrote: |
I
was wondering if someone could provide some linux noob support. I've
got the bsnes source and extracted it. I'm in a terminal in the
directory (bsnes/src) and I type 'make' and it says
"please specify which platform to compile for with PLATFORM=platform_name"
I really know NOTHING about this sort of thing so if someone could let
me know where I'm going wrong or just copy a list of commands that
would be great.
for the record I'm using Kubuntu 7.10 "gutsy gibbon" |
Panzer, I also tried to compile bsnes in Linux but gave up after a
while. If you're a Linux noob than I'm probably an extreme Linux noob...
Anyway question: do you have to download any compiler or anything in
order to be able to compile in Kubuntu 7.10, or is everything you need
allready included?
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 27, 2007 4:01 pm Post subject: |
|
Snark wrote: |
Panzer, I also tried to compile bsnes in Linux but gave up after a
while. If you're a Linux noob than I'm probably an extreme Linux noob...
Anyway question: do you have to download any compiler or anything in
order to be able to compile in Kubuntu 7.10, or is everything you need
allready included? |
yes you do but it's nothing too complicated, since I have been learning
how to compile lots of emus I've already picked up most things I need
but some things are already installed by default, and most emus will
tell you what you need in some sort of install readme.
Anyways in this case it's super easy because byuu just posted how to get whatever tools you need
byuu wrote: |
Run this on your terminal:
32-bit (i386):
Code: |
sudo apt-get install g++ libxv-dev libao-dev libgtk2.0-dev nasm
cd /path/to/bsnes/src
make PLATFORM=x-gcc-lui
sudo cp ./bsnes /usr/bin/bsnes
bsnes |
|
ok open a terminal program, and that first line that byuu wrote, you
know that starts with the "sudo apt-get install"... that line is
getting you all the compiler stuff and libraries you need automatically.
so just type that in and you'll be set, and the rest has also been
discussed, just download the bsnes source, decompress it, and then
follow the terminal code stuff. Remember everything is case sensitive
too.
I hope it works for you.
(note: I copies the 32 bit version of what he said but if you have a 64
bit system you can scroll up to see what he said about that but the
only difference as far as getting the required programs is at the end
of the line it's yasm instead of nasm.)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 27, 2007 5:57 pm Post subject: |
|
Panzer88 wrote: |
Snark wrote: |
Panzer, I also tried to compile bsnes in Linux but gave up after a
while. If you're a Linux noob than I'm probably an extreme Linux noob...
Anyway question: do you have to download any compiler or anything in
order to be able to compile in Kubuntu 7.10, or is everything you need
allready included? |
yes you do but it's nothing too complicated, since I have been learning
how to compile lots of emus I've already picked up most things I need
but some things are already installed by default, and most emus will
tell you what you need in some sort of install readme.
Anyways in this case it's super easy because byuu just posted how to get whatever tools you need
byuu wrote: |
Run this on your terminal:
32-bit (i386):
Code: |
sudo apt-get install g++ libxv-dev libao-dev libgtk2.0-dev nasm
cd /path/to/bsnes/src
make PLATFORM=x-gcc-lui
sudo cp ./bsnes /usr/bin/bsnes
bsnes |
|
ok open a terminal program, and that first line that byuu wrote, you
know that starts with the "sudo apt-get install"... that line is
getting you all the compiler stuff and libraries you need automatically.
so just type that in and you'll be set, and the rest has also been
discussed, just download the bsnes source, decompress it, and then
follow the terminal code stuff. Remember everything is case sensitive
too.
I hope it works for you.
(note: I copies the 32 bit version of what he said but if you have a 64
bit system you can scroll up to see what he said about that but the
only difference as far as getting the required programs is at the end
of the line it's yasm instead of nasm.)
|
Allright thanks for the info. However, I'm such a Linux noob that I
can't actually connect to the internet with Linux haha, ..Well I'll see
if I can find a way.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Oct 27, 2007 6:56 pm Post subject: |
|
what
distro are you using? I had a really big problem with this when I
started, the first night the internet worked and then it didn't for a
few agonizing days that I battled it. In a lot of them it's supposed to
automatically connect but I know it can be a trial sometimes. I doubt I
can be much help but what distro are you using? I'm using Kubuntu.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 27, 2007 7:07 pm Post subject: |
|
Panzer88 wrote: |
what
distro are you using? I had a really big problem with this when I
started, the first night the internet worked and then it didn't for a
few agonizing days that I battled it. In a lot of them it's supposed to
automatically connect but I know it can be a trial sometimes. I doubt I
can be much help but what distro are you using? I'm using Kubuntu. |
Ubuntu 6.10.
Might as well try Kubuntu and see if I still have problems connecting.
edit: needless to say I can connect fine with XP :P
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sat Oct 27, 2007 7:54 pm Post subject: |
|
Are you using a dialup connection by any chance? (or perhaps your wireless card?)
if so, good luck, as winmodems (usually) don't work in linux, and it's
tricky to get a wireless card to run in Linux. However in Gutsy,
there's setups to get your winmodems going, so hey.
_________________

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

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Oct 27, 2007 8:40 pm Post subject: |
|
adventure_of_link wrote: |
Are you using a dialup connection by any chance? (or perhaps your wireless card?). |
Nope, just an ethernet card w/modem for adsl internet.
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sat Oct 27, 2007 8:55 pm Post subject: |
|
Hmm... I don't see why it doesn't work, considering I have the exact same setup on my desktop.
_________________

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

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Oct 28, 2007 12:56 am Post subject: |
|
using
kubuntu, or even a newer version of ubuntu won't necessarily solve your
problems, it's just a preference thing, but if you want to sure, I just
want to make sure I'm not trying to say that it's better or will solve
your problems. As a general rule for me though installing a new OS or
just reinstalling often solves some problems.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 28, 2007 7:07 am Post subject: |
|
Alright,
I finished porting over the rest of the special chips, and added in
ExLoROM (S-DD1 games) + ExHiROM (ToP + DKJM2). Everything but the games
in cart.db (Ys3, BS-X flashcart games, Yoshi's Island music) should work now (but we're not often that lucky, are we?)
What was really neat is that I was able to do away with the S-DD1
mapping all together. $4800-$4807 are mapped through the MMIO code, but
before I had to map $c0-ff:0000-ffff, to emulate the memory mapper. It
looked like this:
Code: |
uint8 bMemBus::read_sdd1(uint32 addr) {
addr = sdd1.offset(addr) % cartridge.info.rom_size;
return cartridge.rom[addr];
}
void bMemBus::write_sdd1(uint32 addr, uint8 data) {
if(cart_write_protect_enabled == true)return;
addr = sdd1.offset(addr) % cartridge.info.rom_size;
cartridge.rom[addr] = data;
}
void bMemBus::cart_map_sdd1() {
//$[c0-ff]:[0000-ffff]
for(uint page = 0xc000; page <= 0xffff; page++) {
page_read [page] = &bMemBus::read_sdd1;
page_write[page] = &bMemBus::write_sdd1;
}
} |
sdd1.offset(addr) would convert the requested address to the memory-mapped ROM address.
But with the new mapping system, I can simply remap the banks whenever
the memory mapping registers are changed. The interesting point about
that is that's exactly what I needed to continue on with BS-X support.
That it works well is definitely a good sign.
But a tiny bit of bad news, it's apparently marginally (~5-8%) slower this way than before. Note that this only
affects Star Ocean. I honestly can't believe that ... I was using
modulus on every single cart read before, whereas now it's a direct map
to ROM. It appears the bus.map() overhead is quite high, most likely
due to the use of the recursive mirror() function. I will certainly
have to optimize that a lot more. I should be able to make up the speed
loss in the future, but it's not a priority right now.
---
Nach, could you lend a hand when you have some free time with Ys3 SRAM
and BS-X flashcart connector detection? Once I get those working, I'm
going to remove cart.db entirely. Eventually, I'll add it back to allow
users to create their own per-game mappers, but no need to keep an
official database along with the emulator if it's not needed.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Oct 28, 2007 7:59 am Post subject: |
|
byuu wrote: |
Nach, could you lend a hand when you have some free time with Ys3 SRAM
and BS-X flashcart connector detection? Once I get those working, I'm
going to remove cart.db entirely. Eventually, I'll add it back to allow
users to create their own per-game mappers, but no need to keep an
official database along with the emulator if it's not needed. |
Yeah, catch me at our usual meeting place.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Oct 28, 2007 10:05 am Post subject: |
|
Nach wrote: |
byuu wrote: |
Nach, could you lend a hand when you have some free time with Ys3 SRAM
and BS-X flashcart connector detection? Once I get those working, I'm
going to remove cart.db entirely. Eventually, I'll add it back to allow
users to create their own per-game mappers, but no need to keep an
official database along with the emulator if it's not needed. |
Yeah, catch me at our usual meeting place.
|
Down by the docks, eh? That's where I do most of my business, too.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Oct 28, 2007 11:42 am Post subject: |
|
DancemasterGlenn wrote: |
Nach wrote: |
Yeah, catch me at our usual meeting place. |
Down by the docks, eh? That's where I do most of my business, too.
|
Nah, he means evil clone hideout #317b.
_________________
皆黙って俺について来い!!
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: Tue Oct 30, 2007 10:50 pm Post subject: |
|
byuu, were you aware that the latest WIP has no executable? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Oct 30, 2007 11:08 pm Post subject: |
|
FitzRoy wrote: |
byuu, were you aware that the latest WIP has no executable? |
I was.
Good thing it's so easy to compile 
_________________
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: Wed Oct 31, 2007 12:26 am Post subject: |
|
If it's a compile-yourself version, that's fine. It was just the first time I've seen a WIP without the executable. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 31, 2007 10:18 am Post subject: |
|
I
mentioned that it wasn't there. Exact reason was because I reloaded
Ubuntu and Windows, and I really hate installing Visual C++. It takes
forever. I posted a new WIP, and built it with MinGW4. Need to figure
out how to get the icon into the binary with MinGW.
Anyway, new stuff in the WIP:
- Much, much faster mirror() function; thanks to lots of help from Nach
(doesn't speed anything up, but might help with BS-X MMIO registers)
- Removed cart.db and all database-related code, now that Ys3 works
- Lots of code cleanups everywhere
- New help information for trying to run ./configure or make by itself
- Cheap temporary MinGW fix for non-C99 vsnprintf
The BS-X slot games (Derby Stallion et al) won't work on this release.
Nach gave me the code to detect those, and I'll get that mapper in
eventually before the next release. Also, Yoshi's Island won't play
audio anymore most likely.
If anything else is broken, it's due to mapping. Please let me know so
I can fix it. If there are more than three broken games, that's good --
please don't overwhelm me with a list of 500+ broken games in the
morning :)
EDIT: fixed the Windows issues I was having. The Realtek HD Audio driver software is fucking stupid. You have
to unplug your speakers, reconnect them, and then select line out
(rather than the option for speakers) to get audio. This is the only
way to get audio. And apparently both regular Winamp (without
visualization) and Mozilla Firefox now need DEP turned off not to crash
the fuck all over themselves constantly. Wonderful.
EDIT2: forgot to set the region, so PAL games will run as though they
are NTSC. Most will probably give you an error splash screen. I'll fix
that. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 31, 2007 10:40 pm Post subject: |
|
Cool,
why does it seem like this MinGW built bsnes is so much faster than
before? I don't even dip on the Black Omen now and .025 took me to 53.
Also, I had no idea that it was possible to detect everything without a
database. I'm glad you guys figured out how to do it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Oct 31, 2007 11:02 pm Post subject: |
|
FitzRoy wrote: |
Cool,
why does it seem like this MinGW built bsnes is so much faster than
before? I don't even dip on the Black Omen now and .025 |
Nice.
Speaking of speed improvements I saw this on Aaron Giles's blog.
Probably completely unrelated and not useful for bsnes but just in case:
http://aarongiles.com/?p=217
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Oct 31, 2007 11:16 pm Post subject: |
|
FitzRoy wrote: |
Cool,
why does it seem like this MinGW built bsnes is so much faster than
before? I don't even dip on the Black Omen now and .025 took me to 53.
Also, I had no idea that it was possible to detect everything without a
database. I'm glad you guys figured out how to do it. |
diddo that's spiffy (about the database) also is that part of Chrono
Trigger really processor intensive? are there other games that would
slow you down more?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Nov 01, 2007 1:06 am Post subject: |
|
The
Black Omen bit during the CT intro (and ingame) is the most intensive
scene anywhere IIRC. It's definitely the toughest I've seen. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Nov 01, 2007 2:33 am Post subject: |
|
perhaps someone could make a homebrew tech demo that maxes out the SNES for the ultimate test even though it wouldn't matter because no game would require it, it'd just be for kicks.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Nov 01, 2007 9:41 am Post subject: |
|
The SNES always runs at maximum speed, but you can force emulators to clear their rendering caches by updating VRAM every frame.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Nov 01, 2007 10:04 am Post subject: |
|
creaothceann wrote: |
The SNES always runs at maximum speed, but you can force emulators to clear their rendering caches by updating VRAM every frame. |
Don't count on that, ZSNES uses some buffering techniques, and hashes
video frames to decide if it needs to actually send something new to
the video card or not.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Nov 01, 2007 11:30 am Post subject: |
|
Just practice the big square dance. I mean, draw rectangles randomly over the screen with random colors as fast as possible. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Nov 01, 2007 2:25 pm Post subject: |
|
creaothceann wrote: |
The SNES always runs at maximum speed, but you can force emulators to clear their rendering caches by updating VRAM every frame. |
I know that, but clearly some things slow a system down more than usual.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Nov 01, 2007 4:59 pm Post subject: |
|
creaothceann wrote: |
The SNES always runs at maximum speedp |
You're saying regardless of whether you're running "Hello world" (or
something equally as simple) or a highly complex scene full-loop (like
the CT black omen intro) it won't make a difference in terms of,say,
system temperature or power consumption? (and by "difference" I mean
even a marginally small one.)
I'm not just talking cpu clock rate, but the system as a whole. I know
some DS games for example comsume more because they definitely wear the
rechargable batteries faster.
Quote: |
perhaps
someone could make a homebrew tech demo that maxes out the SNES for the
ultimate test Smile even though it wouldn't matter because no game
would require it, it'd just be for kicks. |
That would be great. Could be used on real SNESs as some sort of
"burn-in"/stability test, and to test the speed of SNES emulators in
general.
|
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Nov 01, 2007 7:43 pm Post subject: |
|
Snark wrote: |
creaothceann wrote: |
The SNES always runs at maximum speed |
You're saying regardless of whether you're running "Hello world" (or
something equally as simple) or a highly complex scene full-loop (like
the CT black omen intro) it won't make a difference in terms of, say,
system temperature or power consumption? (And by "difference" I mean
even a marginally small one.)
|
No, I mean that, even if you display all four backgrounds and all
sprites on screen, the system will still render the pixels with the
same speed, and the CPU will still run at the designate speeds
(slowdown is a function of the game to avoid flicker).
There are some additional scrolling values for backgrounds that are
normally set to zero, and hence don't have a visible effect. In the
"offset-per-tile" screen modes (Modes 2, 4 and 6) these scrolling
values can be changed, and that's what happens in the "Black Omen"
scene.
As for your question, I guess
it might be possible that a scene with no transparent pixels and with
all sprites off-screen would show a noticeable difference in the power
consumption of the PPU subsystem.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Nov 01, 2007 7:45 pm Post subject: Inserting an icon into a mingw executable |
|
Hey byuu,
As per your request for inserting an icon file into a mingw compiled
bsnes, I found out how to do this from this url: http://fragglet.livejournal.com/4448.html
Edit the makefile like this to use your original ui/bsnes.rc resource file:
replace lines 173-177 with:
Code: |
ifeq ($(OS),win)
ifeq ($(CC),cl)
OBJECTS += bsnes.res
else
OBJECTS += bsnes.o
endif
endif |
replace line 198 with:
Code: |
ifeq ($(OS),win)
ifeq ($(CC),cl)
bsnes.res : ui/bsnes.rc ; rc /r /fobsnes.res ui/bsnes.rc
else
bsnes.o : ui/bsnes.rc ; windres -I data ui/bsnes.rc bsnes.o
endif
endif |
This will link the icon into the executable and it will show up in the explorer.
I still can not figure out why the icon does not show in the top left
of the aplication window, but it is better than nothing 
I hope this helps, keep up the great work =D
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Nov 01, 2007 8:30 pm Post subject: Re: Inserting an icon into a mingw executable |
|
krom wrote: |
Hey byuu,
As per your request for inserting an icon file into a mingw compiled
bsnes, I found out how to do this from this url: http://fragglet.livejournal.com/4448.html
Edit the makefile like this to use your original ui/bsnes.rc resource file:
replace lines 173-177 with:
Code: |
ifeq ($(OS),win)
ifeq ($(CC),cl)
OBJECTS += bsnes.res
else
OBJECTS += bsnes.o
endif
endif |
replace line 198 with:
Code: |
ifeq ($(OS),win)
ifeq ($(CC),cl)
bsnes.res : ui/bsnes.rc ; rc /r /fobsnes.res ui/bsnes.rc
else
bsnes.o : ui/bsnes.rc ; windres -I data ui/bsnes.rc bsnes.o
endif
endif |
This will link the icon into the executable and it will show up in the explorer.
I still can not figure out why the icon does not show in the top left
of the aplication window, but it is better than nothing 
I hope this helps, keep up the great work =D
|
I already sent him a Makefile which had the icon in MinGW, as well as
offered cross compile support, but for some reason he never merged that
into the main tree.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 01, 2007 8:48 pm Post subject: Re: Inserting an icon into a mingw executable |
|
Quote: |
I hope this helps, keep up the great work =D |
It certainly does, thank you! One issue is that I use MinGW4, which names everything *-sjlj (eg gcc-sjlj).
However, when I run windres, I get:
Code: |
'gcc' is not recognized as an internal or external command, operable program or batch file. |
I don't really want to rename all of the MinGW4 files to remove the
-sjlj, and it will probably cause invocation dependencies to break ...
maybe there's some clever way of making a batch file to redirect all
arguments to gcc-sjlj (no symlinks on Windows, of course).
Quote: |
I
already sent him a Makefile which had the icon in MinGW, as well as
offered cross compile support, but for some reason he never merged that
into the main tree. |
Sorry, I do everything by hand. So I don't always get 100% of every
change you make. Especially when you send me giant tarballs with 200
diffs and no line-by-line explanation of what you changed and why. Not
to say I don't really appreciate your help, I just overlook some things
on occasion. It's not intentional.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Nov 01, 2007 9:19 pm Post subject: windres error |
|
Code: |
'gcc' is not recognized as an internal or external command, operable program or batch file. |
Sorry byuu, I did not realize that windres uses "gcc.exe" 
When I got the new mingw gcc 4, I copied all of the files in the bin
directory that ended with sjlj again to their proper names to maintain
compatibility with my older mingw programs, so I did not realise this
would happen.
I should think when gcc 4 becomes the standard in mingw, it will not
have these strange endings on all the names of the binaries, and it
will work correctly, sadly I have no idea when this will happen, so we
will probably have to grin and bear it for now.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 01, 2007 10:30 pm Post subject: |
|
Hmm,
so removing -sjlj from everything worked okay for you still? No errors,
eg the linker trying to invoke the -sjlj version? I stopped because
mingw32-gcc-sjlj -v returns "--program-suffix=-sjlj", which looked like
it was important. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Fri Nov 02, 2007 12:30 am Post subject: reply to byuu |
|
Quote: |
Hmm,
so removing -sjlj from everything worked okay for you still? No errors,
eg the linker trying to invoke the -sjlj version? I stopped because
mingw32-gcc-sjlj -v returns "--program-suffix=-sjlj", which looked like
it was important. |
I did not remove anything, all I did was copy all of the binaries that
have "-sjlj" to the same directory without the "-sjlj" e.g gcc-sjlj.exe got copied again to gcc.exe to the same directory.
So I assume the linker is using mingw32-gcc-sjlj.exe all the way thru
until it hits the new windres section, then it uses my copied gcc.exe
(which is exactly the same as gcc-sjlj.exe) to do that bit, then it
carries on using mingw32-gcc-sjlj.exe... I hope that made sense!! 
This maintains backwards compatibility with my old programs that need a
gcc.exe when there was not one, and I wanted the newest 4.2 gcc for my
old projects, so it was the only way to do it easily without changing
all my sources...
I reckon it will work if you just copy gcc-sjlj.exe to a seperate gcc.exe in the same directory!
When mingw's gcc 4 binaries are named correctly after this preview sjlj
build becomes standard, we will not have any of these problems, and you
will not need a seperate section in the makefile for mingw 4...
Last edited by krom on Fri Nov 02, 2007 12:40 am; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Nov 02, 2007 12:37 am Post subject: |
|
You could also build (or even download) a copy of MinGW without any crazy pre/post labels.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Fri Nov 02, 2007 12:47 am Post subject: Can you point me! |
|
Quote: |
You could also build (or even download) a copy of MinGW without any crazy pre/post labels. |
Hey Nach,
Are there correctly named binaries of mingw gcc 4 available to
download, I don't suppose you could point me to the correct place I can
get these... I really hate this whole sjlj business...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Nov 02, 2007 12:59 am Post subject: |
|
In this guide
which I used to setup my MinGW (because I remembered the instructions
were clear) it says simply to copy/rename them without the suffixes.
Also IIRC the suffixes are present only because MinGW GCC 4 is still in
beta. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 02, 2007 9:30 am Post subject: |
|
Ok, new WIP up. Pretty much all of the credit goes to others, this time.
Changelog:
- I forgot to set the region, so PAL games were running as NTSC; this is fixed
- Added Nach's BS-X slotted flashcart detection (added his Ys'3 SRAM detection earlier)
- Used BSC-1A7M-10 PCB mapper from Overload's documentation for the
generic BS-X slotted cart games; Derby Stallion '96, Sound Novel
Tsukuru and RPG Tsukuru II are all playable once again; hopefully the
rest of the slotted games work, too (sans the SA-1 game(s)). Please
test if you can
- Added krom's (and I suppose Nach's earlier submitted) MinGW32 icon
support; so FitzRoy's wonderful icon is there now on the EXE -- still
need to add it to the window titlebar (easy on Windows), and to Linux
in general, ugh
- Removed win-mingw4-lui target, simplifying Makefile. Use
win-mingw-lui now. Thanks again to krom's suggestion to just copy the
MinGW4 -sjlj files, that worked great
- Some more cleanup work to src/cart. Still a lot to go here.
Everything that was playable in the last release should now be
playable, excepting Yoshi's Island music. Please let me know if
anything is broken that wasn't before now.
As always, I'm really thankful to everyone for their contributions. My
program would be useless if not for all the help I've gotten from
everyone else.
---
Now then, I aim to support those BS-X slotted cart games as well. But
one thing I did not know until today was that you could actually
exchange those carts between games. That ruins the model I planned to
use for them (eg make romname.smc -> romname.bsf files).
Thinking about it -- I really need to completely redesign file loading.
BS-X and Sufami Turbo stuff really throws off the "Load ROM" paradigm
that is so popular amongst emulators.
I'm thinking ... remove the "Load Special" menu completely. Modify the
main ROM loading routine to parse what exactly is being loaded.
If it's a BS-X slotted cart, pop up a menu that lets one optionally
select to load an additional flash cart, or cancel the menu to load
nothing in the slot. This won't be hot-swappable in-game.
If it's a Sufami Turbo cart, assume Slot A for the cart. If this game
supports dual slotting*, pop up an additional menu to select the Slot B
game, which can also be left empty. (* perhaps popup the menu no matter
what, to more closely simulate that with real hardware, you could stick
incompatible games in both slots anyway?)
Same deal for Same Game, G-Next, and all that other crap, if or whenever I end up supporting those.
I think it's best to keep the BIOS stuff in the config file, rather
than giving an optional popup menu to modify which BIOS to load. The
reason being that it will allow direct loading of BS-X games with no
need to ever show a popup menu.
Lastly, I will have to add a new Misc menu option to generate empty
BS-X flashcart files. Though it's really easy to make one, I imagine
end users might have trouble doing that.
Ideas or suggestions welcome. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Nov 02, 2007 11:10 am Post subject: |
|
It might be easier for the user data flash carts to offer say 10 right off the bat.
Meaning if you go to load a BS-X slotted cart, you see the menu with
the ROMs, but perhaps on the bottom a button to select one of your 10
user save data ones (and perhaps on top of this a browse button, or a
create new with particular name).
Makes it easy for users to separate the hard coded data from their music containing carts and stuff.
Also be worthwhile to use different extensions for everything.
NSRT uses ".bs" for the BS-X downloads, or the sold in store add ons.
ZSNES and Snes9x IIRC recognize this extension.
For flash save data, maybe we can standardize on ".bsf"?
_________________
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: Sat Nov 03, 2007 4:46 am Post subject: |
|
Just
elaborating on the speed gain a bit: .025 gets 55 while the new WIP
gets 63. 15% increase from MinGW and whatever else byuu did. Not bad.
Nach's idea would sound better if both emulators dropped copier
extension support. Honestly, I have no idea why infinitely creatable,
unlicensed devices get their extensions supported by emulators. If I
make my own copier with a .ass extension, will you include it for me? 
BIOS - .bin
Sufami Turbo - .st
Broadcast Satellaview-X - .bs
Super Famicom / SNES - .sfc |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Nov 03, 2007 5:01 am Post subject: |
|
FitzRoy wrote: |
Just
elaborating on the speed gain a bit: .025 gets 55 while the new WIP
gets 63. 15% increase from MinGW and whatever else byuu did. Not bad.
Nach's idea would sound better if both emulators dropped copier
extension support. Honestly, I have no idea why infinitely creatable,
unlicensed devices get their extensions supported by emulators. If I
make my own copier with a .ass extension, will you include it for me? 
BIOS - .bin
Sufami Turbo - .st
Broadcast Satellaview-X - .bs
Super Famicom / SNES - .sfc |
that sounds like a good idea.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Nov 03, 2007 4:51 pm Post subject: |
|
I agree about the extensions. I'll definitely drop them if ZSNES does.
As it stands, every time I remove them (eg when I first started bsnes
and after both the rewrite at 0.006 and GUI rewrite at 0.020), I have
multiple requests to re-add all of these extensions.
It's a major disadvantage to not have them when ZSNES et al does, but
if everyone here agrees I should do it anyway, I'll remove them and
take the small userbase hit. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 03, 2007 7:52 pm Post subject: |
|
Just thought I'd let you know that Derby Stallion 98 isn't working while it did in .025. Only one I could find not working. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Nov 03, 2007 8:14 pm Post subject: |
|
FitzRoy wrote: |
Just thought I'd let you know that Derby Stallion 98 isn't working while it did in .025. Only one I could find not working. |
Did the game ever broke in past releases? I assume by now it's pretty
much always the same games who broke or fixes depending on emulation
changes.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 03, 2007 8:38 pm Post subject: |
|
It's one of the those special slotted carts like Stallion 96, but I don't know the difference between 98 and 96. |
|
darkNiGHTS New Member
Joined: 03 Nov 2007
Posts: 2
|
Posted: Sat Nov 03, 2007 11:30 pm Post subject: |
|
Hello, I am getting an error when I compile on 64-bit Ubuntu 7.10.
Code: |
g++
-obsnes -O3 -fomit-frame-pointer -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86 -DUI_LUI `pkg-config --cflags gtk+-2.0` main.o
libco_x86.o libui_gtk.o libstring.o reader.o cart.o cheat.o memory.o
bmemory.o cpu.o scpu.o smp.o ssmp.o bdsp.o ppu.o bppu.o snes.o
superfx.o srtc.o sdd1.o c4.o dsp1.o dsp2.o dsp3.o dsp4.o obc1.o st010.o
`pkg-config --libs gtk+-2.0` -lXv -lao
/usr/bin/ld: i386 architecture of input file `libco_x86.o' is incompatible with i386:x86-64 output
collect2: ld returned 1 exit status
make: *** [all] Error 1
|
Thanks
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 04, 2007 2:13 am Post subject: |
|
Thank
you for the bug report, FitzRoy. I'll look into it as soon as I can.
Hopefully I can make just one mapper for all slotted cart games.
darkNiGHTS, compile with make PLATFORM=x-gcc-lui-x64, and not x-gcc-lui. That should solve the problem. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 04, 2007 2:52 am Post subject: |
|
byuu wrote: |
Thank
you for the bug report, FitzRoy. I'll look into it as soon as I can.
Hopefully I can make just one mapper for all slotted cart games.
|
From those two mappers you had before, you probably picked the wrong one.
The test build I put out a while back only had one mapper for those slotted games.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 04, 2007 6:58 am Post subject: |
|
Derby
Stallion '98 is not a BS-X slotted cart game. In fact, an actual
cartridge for it does not exist, as far as I can tell. It's a Nintendo
Power game, so you'll only find it on those flash cart things.
Anyway, I fixed it. My memory mapper was splitting LoROM up the same
way HiROM was split up -- into four pieces (00-3f, 40-7f, 80-bf,
c0-ff). Technically, no LoROM game greater than 2MB should have worked
with the last WIP.
I've expanded LoROM into two chunks: 00-7f and 80-ff. I'm now leaving
$[40-7f|c0-ff]:[0000-7fff] unmapped, so who knows what'll happen. Maybe
some games will break, maybe not. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 04, 2007 7:38 am Post subject: |
|
Code: |
-------------------------Container--------------------------
File: NP Derby Stallion 98 (J).gz
Sub File: NP Derby Stallion 98 (J)
---------------------Internal ROM Info----------------------
Name: DERBY STALLION 98 Company: Nintendo
Header: None Bank: LoROM
Interleaved: None ROM: 24 Mb
Type: Normal SRAM: 256 Kb
Expansion: NP Cart Battery: Present
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x1D2A Game Code: Marked, BDBJ
---------------------------Hashes---------------------------
CRC32: 525FFB26
--------------------------Database--------------------------
Name: NP Derby Stallion 98
Country: Japan Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Unknown Genre 2: Horse
-------------------------Container--------------------------
File: Derby Stallion 96 (J).gz
Sub File: Derby Stallion 96 (J)
---------------------Internal ROM Info----------------------
Name: DERBY STALLION 96 Company: ASCII Co./Nexoft
Header: None Bank: LoROM
Interleaved: None ROM: 24 Mb
Type: Normal SRAM: 256 Kb
Expansion: BS-X Slot Battery: Present
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0xCC86 Game Code: Marked, ZDBJ
---------------------------Hashes---------------------------
CRC32: 19BDCB19
--------------------------Database--------------------------
Name: Derby Stallion 96
Country: Japan Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Unknown Genre 2: Horse
|
_________________
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 Nov 04, 2007 7:38 am Post subject: |
|
byuu wrote: |
Derby
Stallion '98 is not a BS-X slotted cart game. In fact, an actual
cartridge for it does not exist, as far as I can tell. It's a Nintendo
Power game, so you'll only find it on those flash cart things. |
Whoops, my bad.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 04, 2007 7:43 am Post subject: |
|
No worries. You caught a much more important bug in the process. In
theory, Dezaemon, Tokimeki Memorial and possibly many more games
would've been broken (perhaps not right away) if that bug were to slip
past us. Nice catch!
I've tested with all of the games I have. Which is essentially all of
my favorites plus every game there's ever been a bug report for.
Everything seems good.
And it looks like I misread Overload's PCB doc. BSC-1A5M and BSC-1A7M
look mostly identical. So one mapper should be fine there.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Nov 04, 2007 9:11 am Post subject: |
|
I too support the changing of the file extensions
(you could still support the old extentions but you could popup a screen bitching about the wrong extention) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 04, 2007 11:36 am Post subject: |
|
Ok,
posted the new WIP with the LoROM map corrections. This one also
modified the load special menu. They now bring up a new window that
lets you select the base cart + slot cart(s). However, the menus do not
work yet. There's also some odd issue that it loses focus when you
select a ROM from the browse button, but only on Windows. Hitting load
just hides the window. I also need to add code to automatically load /
save the BIOS filenames where applicable.
Also,
forgot to mention last time, but I added a new config file option,
cpu.wram_initial_value or something like that. It's purpose should be
pretty obvious. |
|
darkNiGHTS New Member
Joined: 03 Nov 2007
Posts: 2
|
Posted: Sun Nov 04, 2007 2:02 pm Post subject: |
|
byuu wrote: |
Thank
you for the bug report, FitzRoy. I'll look into it as soon as I can.
Hopefully I can make just one mapper for all slotted cart games.
darkNiGHTS, compile with make PLATFORM=x-gcc-lui-x64, and not x-gcc-lui. That should solve the problem. |
Thanks that did the trick! And it runs beautifully, thanks for making such an awesome emulator .
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 04, 2007 8:50 pm Post subject: Re: bsnes thread (v.025 & updated buglist) |
|
So for the file loading system, base cart will point to the BIOS for stuff like ST and BS-X, right?
The cool thing about the new extensions if adopted, is that a list of a
thousand items will be reduced to only files with that add-on's
extension. Should make things easier to load for people with lots of
roms. I think this is why in the old days BS rom names had a "BS" in
front of them, just so they would all appear in one place.
Last edited by FitzRoy on Sun Nov 04, 2007 8:58 pm; edited 2 times in total |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Nov 04, 2007 8:52 pm Post subject: |
|
so
just to be clear, what is the state of BS-X emulation right now?
working? are there more compatible games now then the previously
leading emu (SNESGT)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 05, 2007 12:41 am Post subject: |
|
darkNiGHTS wrote: |
Thanks that did the trick! And it runs beautifully, thanks for making such an awesome emulator :) . |
Thank you for the compliment and for letting me know it worked. Always
good to get more Linux testing, as this is my first Linux app.
Quote: |
So for the file loading system, base cart will point to the BIOS for stuff like ST and BS-X, right? |
Yeah, I actually had (BIOS) in the names for a bit, but decided against
keeping them. The reason is ... they aren't really BIOSes. They're just
cartridges like any other, but with some additional hardware to map
another chip. Sometimes the slot(s) load actual games, sometimes they
load data carts. The reason I have two BS-X entries in the menu is
because the regular one is going to "remember" the base cart path since
it never changes, and the slotted cart option will always be empty.
I'll be changing path.bios to path.bsx and path.st, which will be filename paths.
Quote: |
The
cool thing about the new extensions if adopted, is that a list of a
thousand items will be reduced to only files with that add-on's
extension. |
A very good point, indeed.
Ok, so then we have:
.sfc [we'll keep .smc, .fig and .swc for compatibility for now] --
standard cartridge ROM file. Will be used for carts, including ST and
BS-X "BIOS" files.
.bs - BS-X 8mbit flash cart. Will be used both for BS-X games, as well
as for BS-X carts to connect to slotted cart games like Sound Novel
Tsukuru.
.st - Sufami Turbo cart. Will only be used for the two slots when loading ST games.
I also like Nach's idea to add pictures to the load special windows,
demonstrating the kind of cart loading that is happening. That'll be a
ways off, though. He also had another idea to add pre-defined slots
which will point to by-default empty flash carts. Should make loading
RPG Tsukuru II and Sound Novel Tsukuru stuff easier. Need to wait until
I actually support those carts before even considering that, though.
Quote: |
so
just to be clear, what is the state of BS-X emulation right now?
working? are there more compatible games now then the previously
leading emu (SNESGT) |
bsnes' BS-X emulation is minimal, consisting only of the mappers and
the extra SRAM mirroring. There are three parts to it that need to be
emulated:
1) Satellaview $21xx registers. Little can be done here, of course. I
can implement the ones like the time register, and enough to feign the
unit being there ... just offline, I suppose.
2) BS-X cartridge MMIO registers ($00-0f:5000). These remap the address
bus around, and was why I needed to completely rewrite my memory
mapper. Now that that's done, I can start on this part.
3) BS-X flash cartridge MMIO registers ($c0:????). These are used to
read vendor information from the flash carts, to enable writing to the
carts, etc. Will be required both for BS-X and BS-X slotted cart games.
I hope to share the code between the two.
But overall, emulation won't ever exceed SNESGT. The best I can do is
rely on Dreamer Nom et al's BS-X notes, and the SNES9x sources. As
SNESGT is closed source, if GIGO has any information other than those
two sources, I won't have access to it.
But then, I'm not trying to compete with GIGO anyway. He's a cool guy
and would probably give me the info ... if only the language barrier
between us wasn't so strong. A shame I'm too stupid to learn Japanese :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 05, 2007 1:13 am Post subject: Re: bsnes thread (v.025 & updated buglist) |
|
FitzRoy wrote: |
The cool thing about the new extensions if adopted |
*New* extensions???
Adopted?
_________________
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: Mon Nov 05, 2007 1:19 am Post subject: Re: bsnes thread (v.025 & updated buglist) |
|
Nach wrote: |
FitzRoy wrote: |
The cool thing about the new extensions if adopted |
*New* extensions???
Adopted?
|
bsnes doesn't recognize them, and if it did they would be new.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 05, 2007 1:32 am Post subject: Re: bsnes thread (v.025 & updated buglist) |
|
FitzRoy wrote: |
Nach wrote: |
FitzRoy wrote: |
The cool thing about the new extensions if adopted |
*New* extensions???
Adopted?
|
bsnes doesn't recognize them, and if it did they would be new.
|
Doesn't make them new extensions, new to bsnes perhaps.
But yes, it would be nice if bsnes used the same default extensions that NSRT did.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 05, 2007 7:22 am Post subject: |
|
New WIP up.
I spent four hours completely rewriting everything but the generic
header parsing code in src/cart. I'm now happy with the code both in
src/memory and src/cart. Hoorah.
With the new load_cart() functionality, I made the "Load Special" menu
entries functional. For those of you stuck on Windows or without WIP
access, you can see how nice the load menus look on Linux below :)
http://byuu.cinnamonpirate.com/bsnes/images/ui_bsx.png
http://byuu.cinnamonpirate.com/bsnes/images/ui_st.png
There is one bug: because of the way I map the slotted carts into one
contigious chunk of ROM (and hence update the size accordingly), it
throws off the memory mirroring on some of the BS-X slotted cart games
(like RPG Tsukuru II). I need to work on that a bit. For now, you can
play it through the normal load cartridge menu option.
And of course, there's still that annoying Windows issue where the main
window steals focus after loading a ROM. Haven't looked into that yet.
And I still need to rework the file extension stuff per previous
discussions. It'd be nice to have the BS-X / ST windows only show .bs /
.st ROMs by default. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 05, 2007 7:33 am Post subject: |
|
byuu wrote: |
It'd be nice to have the BS-X / ST windows only show .bs / .st ROMs by default. |
Don't forget archive files as well.
And if need be, check archive files for internal extensions.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 05, 2007 6:17 pm Post subject: |
|
Just noting, SameGame was another victim of the mapper rewrite.
Nach's code detects that it has a BS-X slot, but it uses a HiROM-style
header, rather than a LoROM-style one. In fact, it's compatible with
the HiROM memory mapper as it is now, sans the flash cart.
So I'll have to fork the BSCROM mapper to both BSCLoROM and BSCHiROM
(so I can map the BS-X cart, obviously). Not much of a problem.
Mentioning here so I don't forget.
I plan to use the same "Load BS-X Slotted Cart" menu option for
SameGame. And I'll probably need a BSCSA1ROM mapper if I ever get SA-1
support added and want G-NEXT support. Sigh, it never ends ... |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Nov 05, 2007 6:35 pm Post subject: |
|
byuu wrote: |
But then, I'm not trying to compete with GIGO anyway. He's a cool guy
and would probably give me the info ... if only the language barrier
between us wasn't so strong. A shame I'm too stupid to learn Japanese  |
does anyone here know japanese? I'm starting to think it would be
really beneficial if somehow someone could get in contact with him, get
some information and make a doc, just to see how he does stuff.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Nov 05, 2007 9:40 pm Post subject: |
|
Panzer88 wrote: |
byuu wrote: |
But then, I'm not trying to compete with GIGO anyway. He's a cool guy
and would probably give me the info ... if only the language barrier
between us wasn't so strong. A shame I'm too stupid to learn Japanese  |
does anyone here know japanese? I'm starting to think it would be
really beneficial if somehow someone could get in contact with him, get
some information and make a doc, just to see how he does stuff.
|
I'd feel like the biggest liar if I were to say I do, but I do honestly think that someone with some good basic
skills in Japanese should not have that much trouble communicating with
the help of translations tools (I personally like Rikaichan for Firefox
) Of course, your Japanese will probably sound something like: "You how
to make the function recurring in the sub class" or something like that
to a native speaker, but it should be good enough.
Then again, maybe I'm being overly optimistic. For sure,something like
real-time chat would prove somewhat arduous, to say the least. And if
you add technical computer mumbo-jumbo to the whole thing, well I don't
know...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Nov 05, 2007 10:55 pm Post subject: |
|
An
option would be to get an interpreter and include him in an IM
conversation. I know someone who's studied Japanese but he isn't into
emulation. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Nov 06, 2007 12:10 am Post subject: |
|
I been studying Japanese for five years and I also lived in Japan for two years.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Nov 06, 2007 3:10 am Post subject: |
|
Verdauga Greeneyes wrote: |
An
option would be to get an interpreter and include him in an IM
conversation. I know someone who's studied Japanese but he isn't into
emulation. |
the interpreter idea sounds good.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Nov 06, 2007 3:29 am Post subject: |
|
I thought there was a person on the Snes9x dev team who was Japanese. Maybe try asking them? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Nov 06, 2007 4:34 am Post subject: |
|
byuu wrote: |
Yeah, I actually had (BIOS) in the names for a bit, but decided against
keeping them. The reason is ... they aren't really BIOSes. They're just
cartridges like any other, but with some additional hardware to map
another chip.
|
Interesting, I wonder how I never realized this myself. They can be
scanned and dumped like roms because they apparently are roms. So why
does NSRT and zsnes decide on stbios.bin, etc? Seems like it should
have just been st.sfc or something.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Nov 06, 2007 6:23 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
Yeah, I actually had (BIOS) in the names for a bit, but decided against
keeping them. The reason is ... they aren't really BIOSes. They're just
cartridges like any other, but with some additional hardware to map
another chip.
|
Interesting, I wonder how I never realized this myself. They can be
scanned and dumped like roms because they apparently are roms. So why
does NSRT and zsnes decide on stbios.bin, etc? Seems like it should
have just been st.sfc or something.
|
If it had a use besides being a BIOS, I would label it .sfc instead of .bin.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 06, 2007 7:11 am Post subject: |
|
Please
don't bug GIGO. Let me implement what I know about the BS-X, and if I
still need more information, I'll go from there. Thanks, though.
As for BIOS file extensions, it's a non-issue for bsnes. It defaults
both to "" now, and you can select your base cart / BIOS file, which
can be named whatever you want.
And actually, the Sufami Turbo base cart alone does have a purpose. If
you run it with no carts inserted, it runs in copy mode (copy SRAM? not
sure), and putting a cart into slot B (but none in slot A) triggers an
erase mode (again, SRAM? sure hope so). Of course, to make use of that,
we'd have to support hot-swappable carts :/
The BS-X base cart has a purpose too -- getting into the St. GIGA ghost town. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Nov 06, 2007 7:51 am Post subject: |
|
byuu wrote: |
As for BIOS file extensions, it's a non-issue for bsnes. It defaults
both to "" now, and you can select your base cart / BIOS file, which
can be named whatever you want.
|
Not an issue for ZSNES either, if you don't use the default name, you can enter the name you do use.
byuu wrote: |
And actually, the Sufami Turbo base cart alone does have a purpose. If
you run it with no carts inserted, it runs in copy mode (copy SRAM? not
sure), and putting a cart into slot B (but none in slot A) triggers an
erase mode (again, SRAM? sure hope so). Of course, to make use of that,
we'd have to support hot-swappable carts :/
|
I didn't know about that...
Then again, I can easily copy or erase an SRAM with any OS.
byuu wrote: |
The BS-X base cart has a purpose too -- getting into the St. GIGA ghost town. |
You don't see me naming the BS-X base .bin, in fact in Snes9x, you have
to load the BIOS and enter a name before you can use a child cart
properly IIRC.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 07, 2007 10:41 am Post subject: |
|
I redesigned my site again. Opinions would be appreciated. I don't want to hear any negatives about the brightness, though.
Note that you need a non-IE6- browser if you want to see the cool new
fixed header trick. I have probably one of two dozen websites in the
world that actually nest the scrollbar properly inside the body div.
Every other site just lets the scrollbar eat right into the fixed
header. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Nov 07, 2007 10:55 am Post subject: |
|
byuu wrote: |
I redesigned my site again. Opinions would be appreciated. I don't want to hear any negatives about the brightness, though. |
Looking good!
The only comment that I have would be that your "<div
class='topic'>" markup seems to be an awkward way of spelling
"<h2>".
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Nov 07, 2007 11:49 am Post subject: |
|
Hrm,
your website looks almost exactly the same to me in IE7 and Firefox
>.> I checked the source and it is using a different style sheet,
but aside from spacing between news posts and the thickness of the bar
seperating the menu from the page I don't see any difference..
Edit: I spoke too soon, didn't try scrolling. (in FF the menu stays onscreen as I imagine it should) |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Nov 07, 2007 1:01 pm Post subject: |
|
Looks good. I miss the max-width of the body text, too. Maybe you can find a way to make that work better.
Perhaps just add another div around everything and give it a max-width?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Nov 07, 2007 1:22 pm Post subject: |
|
byuu wrote: |
I
have probably one of two dozen websites in the world that actually nest
the scrollbar properly inside the body div. Every other site just lets
the scrollbar eat right into the fixed header. |
Thanks, you can add my new site to the list. Although I have it have a
fixed header and navigation menu on the left, with the body scrolling.
Thanks for giving me some good CSS ideas to steal.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Nov 07, 2007 2:29 pm Post subject: |
|
It's looking good, Byuu! Nice work!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Nov 07, 2007 2:31 pm Post subject: |
|
I
was just starting to get used to the colors of your last redesign. You
don't like to keep the same thing for very long, do you? 
I think it's fine. If I had to contribute a suggestion, I'd suggest
adding a background color for the navigation menu/header div. Having it
white almost made me think something didn't load or was wrong
initially. Maybe use the same background color as the rest of the page
unless your goal was to make the navigation menu stand out with a
different background color. Purely an artistic decision. Of course,
when I think about the displays of artistic genius I've graced the
world with in my life, I'd think twice about taking my artistic advice.

From a code standpoint, if you didn't already know, you have no
document declaration, which of course means everything that views your
page has to guess at your character encoding, mime type, and what to
parse with. And some may flat out refuse to render it.
Naturally, I'm always appreciative of considerate web site designs so
people using larger resolutions than the one the designer uses don't
have to stare at 40%+ empty space on their screen for no good reason or
use an override. Yes, I'm talking to you, you max-width using freaks. 
_________________
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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 07, 2007 4:12 pm Post subject: |
|
Cool, so nobody's freaking out this time for once. Thanks for the feedback!
Quote: |
The
only comment that I have would be that your "<div class='topic'>"
markup seems to be an awkward way of spelling "<h2>". |
Because it's not h2. It's a custom background color class that can
contain any sized text, multiple lines or even images. And I may want
h2 for text inside one of them sometime. I use h3 now. Note that my
actual pages use <topic></topic>. Kind of an XML-in-PHP
thing there.
Quote: |
Perhaps just add another div around everything and give it a max-width? |
The problem was the scrollbar. If you center the page, the scrollbar
ends up in the middle of the screen. But I think I came up with a
solution. Set only right: 0px; and then set max-width. This will leave
the scrollbar on the right as expected, and still let the width be
limited.
I'll have to add cookie support to select CSS stylesheets with so I
don't have to hear Nightcrawler complain anymore, though :)
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Nov 07, 2007 6:25 pm Post subject: |
|
About limited width, typography experts agree that too wide text is less easy to read. Think of the widescreen people. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Nov 07, 2007 6:32 pm Post subject: |
|
hmm, it looks fine, I liked the old design better but no big deal.
I see both sides with the width, I do agree on fixed max width but I
also think it'd be cool if there could be versions that are slightly
larger for someone using a different resolution.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Thu Nov 08, 2007 12:19 am Post subject: |
|
henke37 wrote: |
About limited width, typography experts agree that too wide text is less easy to read. Think of the widescreen people. |
So he should put a note at the top saying "unmaximize your freaking browser already!" 
Seriously, I haven't run a maximized browser in ages. And I'm relatively low res(1280*960)
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Thu Nov 08, 2007 5:21 am Post subject: |
|
byuu wrote: |
I redesigned my site again. Opinions would be appreciated. I don't want to hear any negatives about the brightness, though.
Note that you need a non-IE6- browser if you want to see the cool new
fixed header trick. I have probably one of two dozen websites in the
world that actually nest the scrollbar properly inside the body div.
Every other site just lets the scrollbar eat right into the fixed
header. |
Looks good, but Your links page has still not been updated with Overlord's current page address.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 08, 2007 10:38 am Post subject: |
|
Well here's something nobody should complain about:
http://byuu.cinnamonpirate.com/bsnes/news/
Yeah. No more GET commands.
Quote: |
Looks good, but Your links page has still not been updated with Overlord's current page address. |
Ah, forgot. Fixed, thanks.
Quote: |
I
see both sides with the width, I do agree on fixed max width but I also
think it'd be cool if there could be versions that are slightly larger
for someone using a different resolution. |
Not looking too great, that. Lots of CSS issues and browser
incompatibilities (even ignoring IE) when I start messing around with
containing the widths of the two separate divs ... but we'll see. Maybe
sometime in the future.
|
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Thu Nov 08, 2007 11:16 am Post subject: |
|
henke37 wrote: |
About limited width, typography experts agree that too wide text is less easy to read. Think of the widescreen people. |
the font size and line spacing take this issue away for me.
_________________
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Thu Nov 08, 2007 7:51 pm Post subject: |
|
byuu wrote: |
Quote: |
I
see both sides with the width, I do agree on fixed max width but I also
think it'd be cool if there could be versions that are slightly larger
for someone using a different resolution. |
Not looking too great, that. Lots of CSS issues and browser
incompatibilities (even ignoring IE) when I start messing around with
containing the widths of the two separate divs ... but we'll see. Maybe
sometime in the future.
|
Are you using EMs? Ugly things but...
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Nov 09, 2007 5:00 am Post subject: |
|
I'm
a little bummed, because I did enjoy the colors/layout of the last
version very very much, but this is a nice, simple theme. Very
enjoyable. If you're ever feeling really masochistic, you could always
code it so we can "select our own theme" and save it in cookies (it's
just a joke, but it would be kind of cool). The only place I can think
of that does this is Metallica.com, but of course those themes are all
similarly set up with different pictures. So it would still be
different.
Oh, and this widescreen person doesn't maximize his browser either, so no complaints on that front.
That's all. Good job. |
|
exdeath New Member
Joined: 09 Nov 2007
Posts: 7
|
Posted: Fri Nov 09, 2007 10:45 pm Post subject: |
|
I found a bug in the game mickey mania.
In the loading screen ( that mickey keeps looking in the watch) there
is a graphical bug in the corner of the screen.
Sorry for no pic, but its because where i am now i don't have mickey mania and bsnes. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 09, 2007 11:36 pm Post subject: |
|
exdeath wrote: |
I found a bug in the game mickey mania.
In the loading screen ( that mickey keeps looking in the watch) there
is a graphical bug in the corner of the screen.
Sorry for no pic, but its because where i am now i don't have mickey mania and bsnes. |
Only happens in the PAL version with the extra vertical resolution.
Definitely doesn't look like a bsnes bug. I see stuff like this all the
time in overscan areas that developers never bothered to fix.
|
|
exdeath New Member
Joined: 09 Nov 2007
Posts: 7
|
Posted: Sat Nov 10, 2007 1:37 am Post subject: |
|
No, its happens for me in ntsc too.
Here is the thing  |
|
exdeath New Member
Joined: 09 Nov 2007
Posts: 7
|
Posted: Sat Nov 10, 2007 4:52 pm Post subject: |
|
looking the picture again, its the one of the ears mickey.
PS: Sorry, I forgot to say, that this graphical bug changes acording to mickey animation. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Nov 10, 2007 8:58 pm Post subject: |
|
Turn
on the framecounter. Does it say 50fps? Then you're running the PAL
version of the game. NTSC/PAL option in bsnes only controls the
resolution displayed by bsnes. Some NTSC games will even use "PAL"
resolution. I don't know why he doesn't just call it 256x224 and
256x240. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Nov 11, 2007 12:54 am Post subject: |
|
FitzRoy wrote: |
Turn
on the framecounter. Does it say 50fps? Then you're running the PAL
version of the game. NTSC/PAL option in bsnes only controls the
resolution displayed by bsnes. Some NTSC games will even use "PAL"
resolution. I don't know why he doesn't just call it 256x224 and
256x240. |

he said the glitch happens in the NTSC version also.
_________________

<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: Sun Nov 11, 2007 1:19 am Post subject: |
|
Then why can't I confirm it in either the US or Japanese version of the rom? |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Nov 11, 2007 3:08 am Post subject: |
|
Maybe he neglected to post relevant NSRT info of the ROM?
-shrug-
_________________

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

Joined: 21 Nov 2005
Posts: 216
|
Posted: Sun Nov 11, 2007 3:47 am Post subject: |
|
FitzRoy wrote: |
Then why can't I confirm it in either the US or Japanese version of the rom? |
I couldn't reproduce it either, but it did show up in the European version like both of you guys said.
Edit:Yep he's most likely running a PAL rom and changed the video setting to NTSC thinking it did something else.
|
|
exdeath New Member
Joined: 09 Nov 2007
Posts: 7
|
Posted: Sun Nov 11, 2007 4:30 am Post subject: |
|
yes, i was talking that the glitch happens if you go, settings -> video mode and change to NTSC. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 11, 2007 5:45 am Post subject: |
|
Hmm,
does anyone have a PAL TV and this game or a copier? It's most likely a
timing issue with the game itself. Like FitzRoy said, most NTSC->PAL
ports were really poorly done.
If anyone can confirm that it doesn't happen on hardware, I'll try and see what's going on.
By the way, you have a very sharp eye to notice that, exdeath! Very impressive. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 11, 2007 8:57 am Post subject: |
|
byuu wrote: |
Hmm,
does anyone have a PAL TV and this game or a copier? It's most likely a
timing issue with the game itself. Like FitzRoy said, most NTSC->PAL
ports were really poorly done. |
Well, in this particular case it was. Overall, though, it's not really
a port-specific issue. In 7th Saga when you walk south, little flashing
blocks appear on the bottom right of the screen. In Sim City, scrolling
looks like a blocky, laggy mess. Confirmed on hardware of course. And
they're there because most games were bugtested on everyday overscan tv
sets, which would have occluded any graphical glitches on the far
reaches of any side. So they were never seen and thus, never fixed.
It's inevitable that you're going to get reports on graphical glitches
in overscan areas, and I would assume that anything that fits that
description at this stage is just a game bug. There's no way to
document them all to prevent people from posting them, so I guess we
just address them as they come.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Nov 11, 2007 9:04 am Post subject: |
|
yeah,
I say once we find them just make a list of confirmed on hardware
glitches, or known glitches or whatever. (notice I don't use the word
bsnes bug as that isn't the case in these situations)
it's like Kiddie Kong's eye having a green speck in it on the intro of DKC3
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Sun Nov 11, 2007 7:58 pm Post subject: PAL Harware test of Mickey Mania (E).smc: |
|
I have tested Mickey Mania (E).smc that exhibits the gfx bug in bsnes, on a PAL snes, with a PAL TV, on a Wildcard DX backup device.
I could see a single pixel of grey flash on and off in the top left
hand corner of my t.v, so even though I can not confirm the bug is
exactly the same on hardware (because there is black paint on the
inside of the glass screen not letting me see the overscan area), I can
confirm a bug is there, flashing a grey pixel on the topmost viewable
pixel scanline of my t.v.
Also the flashing pixel on my t.v does indeed seem to match the most
bottom right flashing grey pixel of the gfx bug in bsnes.
I hope this helps =D |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 11, 2007 8:11 pm Post subject: Re: PAL Harware test of Mickey Mania (E).smc: |
|
Unfortunately, been busy dealing with real life issues this weekend. Didn't get anything done that I wanted to ...
krom wrote: |
I hope this helps =D |
It does very much, thank you! :D
[ego] I love this ... we've gotten things so accurate that new bugs are
immediately suspect and more likely to be bugs in the original games
than they are in emulation :) [/ego]
We just obviously still have to test each one, as the last thing we
want to do is overlook a real emulation bug. So yeah, definitely keep
reporting these things. Thanks again for the report, exdeath.
Quote: |
yeah,
I say once we find them just make a list of confirmed on hardware
glitches, or known glitches or whatever. (notice I don't use the word
bsnes bug as that isn't the case in these situations) |
It would be nice to keep such a list, but indeed such a list would end
up being way too long. This may be something to look into more if and
when we get cycle-based PPU renderer and can duplicate the more
esoteric things like the scanline glitchiness in Top Gear 2 or whatever.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 11, 2007 8:15 pm Post subject: |
|
The company didn't bother porting the game to PAL, hence it breaks up on PAL timing.
Code: |
NSRT v3.5 - Nach's SNES ROM Tools
Comparing files Mickey Mania (U) and Mickey Mania (E):
00007FB5: 45 50
00007FD9: 01 02
00007FDC: 98 8C
00007FDE: 67 73
End of both files.
|
All those changes are to the header, and nothing else.
And both dumps are from trusted dumpers.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Sun Nov 11, 2007 8:56 pm Post subject: |
|
how's that version 3.5 looking?
_________________
 |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Nov 11, 2007 9:55 pm Post subject: |
|
Panzer88 wrote: |
yeah,
I say once we find them just make a list of confirmed on hardware
glitches, or known glitches or whatever. (notice I don't use the word
bsnes bug as that isn't the case in these situations) |
I say let's just assume that the visuals bugs in the overscan areas are
:de-facto: original hardware bugs. And that someone who wants to show
otherwise has to provide evidences to that effect.
Listing all known Snes games bugs seem an insane amount of work. I
expect most Snes games, even the well coded ones will always have some level of graphical glitches, even minor ones.
Also it may border on the extreme or even sometime on the downright stupid, as to what constitutes a "bug".
Quote: |
bug report 1
Symptom:
Ken's outfit is not the same red in his portrait as it is in the fighting stage!
Results: After extensive testing: confirmed to happen on real hardware |
Quote: |
bug report 2
Cannot defeat x [insert boss character] in X RPG cut scene even when using infinite life cheat code!p |
Well you get the idea...
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 11, 2007 10:03 pm Post subject: |
|
sweener2001 wrote: |
how's that version 3.5 looking? |
Quite nicely.
grinvader and I spent a lot of time perfecting overdump detection.
We've exposed dozens of overdumps in what we thought till now were
okay. We've cleaned up the info quite nicely, improving it in some
circumstances.
The DB team has submitted a whole slew of updates, so many more
verifications and a handful of new dumps. I've also been spending time
optimizing the various hashing algorithms in assembly using special
instruction sets (if available), so it runs much faster. I also fixed
up some minor issues here and there.
I still have quite a bit to do before new version is ready though. I'm
writing a new compression library, which currently covers gzip, and
hopefully soon zip and others, so I'll be able to offer much more
options such as merged archives, and also work with archives much
faster than all the other programs based on existing libraries which
aren't really that good.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Sun Nov 11, 2007 11:46 pm Post subject: |
|
sweets. looking forward to it.
by far the best ROM tool i've ever used.
_________________
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 12, 2007 9:52 pm Post subject: |
|
I posted a new WIP last night. No binary this time, sorry.
It redoes the memory mapping of the cartridge and moves it into the
cartridge class -- forking each slotted cart away from the base cart
memory.
This allows me to determine the proper sizes for each individual cart
again, so I can now map RPG Tsukuru II again correctly.
EDIT:
Ahahahahahah!! Finally! I figured out how the S-DD1 $4800 and $4801 registers work! :D
Original game transfer (should transfer compressed->decompressed):
Code: |
CC2418 LDA #$4000 A:00DA X:F458 Y:1C00 S:01FA DB:00 D:0000 P:01 e
CC241B PEA $00DB [0000DB] A:4000 X:F458 Y:1C00 S:01FA DB:00 D:0000 P:01 e
CC241E LDX #$E8ED A:4000 X:F458 Y:1C00 S:01F8 DB:00 D:0000 P:01 e
CC2421 LDY #$0800 A:4000 X:E8ED Y:1C00 S:01F8 DB:00 D:0000 P:81 e
CC2424 JSR $2470 [CC2470] A:4000 X:E8ED Y:0800 S:01F8 DB:00 D:0000 P:01 e
CC2470 STA $2116 [002116] A:4000 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:01 e
CC2473 SEP #$20 A:4000 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:01 e
;* enable $4800 *
CC2475 LDA #$01 A:4000 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2477 STA $4800 [004800] A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC247A LDA #$09 A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:4009 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:4009 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:4018 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:4018 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:4018 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:40DB X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DB X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DB X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2495 PLA A:4001 X:E8ED Y:0800 S:01F5 DB:00 D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E8ED Y:0800 S:01F6 DB:00 D:0000 P:01 e |
Custom transfer (should transfer decompressed->decompressed):
Code: |
CC2428 LDA #$5008 A:00DB X:E8ED Y:0800 S:01FA DB:00 D:0000 P:01 e
CC242B PEA $00E9 [0000E9] A:5008 X:E8ED Y:0800 S:01FA DB:00 D:0000 P:01 e
CC242E LDX #$0400 A:5008 X:E8ED Y:0800 S:01F8 DB:00 D:0000 P:01 e
CC2431 LDY #$04E0 A:5008 X:0400 Y:0800 S:01F8 DB:00 D:0000 P:01 e
CC2434 JSR $244C [CC244C] A:5008 X:0400 Y:04E0 S:01F8 DB:00 D:0000 P:01 e
CC244C STA $2116 [002116] A:5008 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:01 e
CC244F SEP #$20 A:5008 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:01 e
;* disable $4800 *
CC2451 STZ $4800 [004800] A:5008 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
;* $43x0.d3 (fixed transfer flag) is irrelevent to S-DD1 *
;* can be #$01 or #$09 here *
CC2454 LDA #$09 A:5008 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2456 BRA $247C [CC247C] A:5009 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:5009 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:5009 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:5018 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:5018 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:5018 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:50E9 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:50E9 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:50E9 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2495 PLA A:5001 X:0400 Y:04E0 S:01F5 DB:00 D:0000 P:21 e
CC2496 STA $420B [00420B] A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:21 e
CC249E RTS A:5001 X:0400 Y:04E0 S:01F6 DB:00 D:0000 P:01 e |
Original transfer right after custom transfer:
Code: |
CC2438 LDA #$4000 A:00E9 X:0400 Y:04E0 S:01FA DB:00 D:0000 P:01 e
CC243B PEA $00DC [0000DC] A:4000 X:0400 Y:04E0 S:01FA DB:00 D:0000 P:01 e
CC243E LDX #$E0E8 A:4000 X:0400 Y:04E0 S:01F8 DB:00 D:0000 P:01 e
CC2441 LDY #$1080 A:4000 X:E0E8 Y:04E0 S:01F8 DB:00 D:0000 P:81 e
CC2444 JSR $2458 [CC2458] A:4000 X:E0E8 Y:1080 S:01F8 DB:00 D:0000 P:01 e
CC2458 STA $2181 [002181] A:4000 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:01 e
CC245B SEP #$20 A:4000 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:01 e
CC245D LDA #$7F A:4000 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC245F STA $2183 [002183] A:407F X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2462 LDA #$01 A:407F X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
;* $4800 enabled again *
CC2464 STA $4800 [004800] A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2467 LDA #$08 A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2469 STA $4300 [004300] A:4008 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC246C LDA #$80 A:4008 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC246E BRA $2481 [CC2481] A:4080 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC2481 STA $4301 [004301] A:4080 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC2484 STX $4302 [004302] A:4080 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC2487 LDA $03,S [0001F9] A:4080 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC2489 STA $4304 [004304] A:40DC X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DC X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DC X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2495 PLA A:4001 X:E0E8 Y:1080 S:01F5 DB:00 D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E0E8 Y:1080 S:01F6 DB:00 D:0000 P:01 e |
I was completely wrong, and was thrown off by ZSNES' memory remapping
magic that worked due to an oversight with $43x0.d3, or the fixed
transfer flag. I never added a check for the fixed transfer flag
because it quite honestly made no sense. Why would the S-DD1 care about
that?
Turns out, it doesn't. What really matters is $4800. The register everyone currently ignores completely.
I figured out what purpose it serves: it's a sticky toggle, whereas $4801 is a loose toggle.
It works like this: in order for the S-DD1 to decompress a DMA
transfer, both $4800 and $4801 have to be set. Upon completion of the
transfer, $4801 is cleared. But $4800 is not.
If you look at the above logs, it becomes clear. And it's all contained
inside the S-DD1 code. It has nothing to do with $43x0.
Now, how can I verify this? orwannon made a flash cart for Star Ocean
and ran my old title screen patch on it. Sure enough, it did not try
and decompress the graphics data, despite the fixed transfer flag being
set. That tells us that the fixed transfer flag has nothing to do with
this.
What's interesting is that every single S-DD1 supporting emulator works
just fine with my title screen patch. Meaning that they've all
implemented these two registers wrong.
What was also interesting is that it's supposedly been confirmed that
the patched SO works on real hardware. That means the bug was in bsnes
after all. No excuses, I was flat out wrong. My sincere apologies.
I've added the above changes, and bsnes now works with the original
patch, and fails with my custom patch. This mimics the behavior of real
hardware.
Huge thanks to orwannon for the screenshot of my patch running on real
hardware. This fix wouldn't have been possible without that.
|
|
orwannon Rookie
Joined: 21 Jan 2005
Posts: 13
|
Posted: Tue Nov 13, 2007 9:34 am Post subject: |
|
byuu wrote: |
Huge
thanks to orwannon for the screenshot of my patch running on real
hardware. This fix wouldn't have been possible without that. |
You're most welcome!
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Nov 13, 2007 12:16 pm Post subject: |
|
This is GREAT news |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 13, 2007 4:08 pm Post subject: |
|
Yeah,
even if we still don't have the S-DD1 100% understood, we can at least
get all known software working properly. And now we at least have all
the registers understood, just the edge cases that need to be tested.
I'm honestly glad I was incorrect in that the original patch worked on
hardware. Given it will never be updated again, this means I won't have
to get bug reports from now unto infinity about it.
I posted a new binary WIP. If anyone wants to play through a few levels
of SFA2 or dungeons in SO and look for corrupted graphics, it'd be
appreciated. I'm sure it'll be fine, though. Oh, and the speedhit I
reported a few days ago was wrong. The old builds ran at the same
speed. Seems I have a ~6-8fps variance in that game per reboot.
New WIP also starts the BS-X mapping. You can map in a cart now, but it
immediately freezes because the flash I/O registers do not respond.
---
Also, I'd like to get serious about emulating the SPC7110. But to do that, I need custom-made hardware.
I asked someone about this already, but I may as well throw it out
there publicly in case anyone else would like to help.
Here is the PCB for one of the SPC7110 games:
http://nsrt.edgeemu.com/INFO/chip-pix/SPC7110.JPG
What I would need is for the top two ICs to be desoldered, and socket
IC connectors to be placed on them instead. I would also obviously need
lots of compatible EEPROMs to connect to it (just two would suffice,
more would be better as it's quite possible I'd wear out the write
cycles with lots of intense testing, or bend up the pins like I usually
do when removing socket ICs).
I would also need software+hardware to actually flash the EEPROMs, as I don't have anything like this presently.
More complex solutions, such as a ROM emulator with a parallel/USB
interface to the PC would be acceptable as well. So long as it's
something I can reprogram at my relatively low skill level.
One cart would suffice, but again, the more carts the better in case of
failure. And I'd also like to see about sending one to another person
who's been interested in the SPC7110 for a while. So, three or four
preferred.
I can supply the cartridges and money for time + shipping. I'd prefer someone who knows
they can do this well try, so that we don't ruin any unnecessary
cartridges and so that the test cartridges are as durable as possible.
Especially since they most likely won't be encased anymore.
So, any takers?
Last edited by byuu on Tue Nov 13, 2007 7:45 pm; edited 3 times in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Nov 13, 2007 7:32 pm Post subject: |
|
tetsuo55 wrote: |
This is GREAT news |
Yep Nice dess :D
Afaik SO always played fine on bsnes, or at least much better than
other emulators -where emulation bugs are often sadly mistaken for game
bugs, but it's good to see we're getting even better S-DD1 emulation.
That'll help separate the game bugs from emulation issues.
edit: Just so that no one miss your edit with my mostly irrelevant post:
byuu wrote: |
Also, I'd like to get serious about emulating the SPC7110. But to do that, I need custom-made hardware.
I asked someone about this already, but I may as well throw it out
there publicly in case anyone else would like to help.
Here is the PCB for one of the SPC7110 games:
http://nsrt.edgeemu.com/INFO/chip-pix/SPC7110.JPG
What I would need is for the top two ICs to be desoldered, and socket
IC connectors to be placed on them instead. I would also obviously need
lots of compatible EEPROMs to connect to it (just two would suffice,
more would be better as it's quite possible I'd wear out the write
cycles with lots of intense testing, or bend up the pins like I usually
do when removing socket ICs).
I would also need software+hardware to actually flash the EEPROMs, as I
don't have anything like this presently.
One cart would suffice, but again, the more carts the better in case of
failure. And I'd also like to see about sending one to another person
who's been interested in the SPC7110 for a while. So, three or four
preferred.
I can supply the cartridges and money for time + shipping. I'd prefer
someone who knows they can do this try, rather than an amateur.
So, any takers? |
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Nov 14, 2007 12:27 pm Post subject: |
|
Wouldn't
stop-n-swop work for testing those custom chips? Get code running in
SNES RAM, pull devcart out, put game cartridge in, then send commands
to code in RAM via controller port (which I've done successfully
before). What all things need to be tested? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Nov 14, 2007 12:41 pm Post subject: |
|
blargg wrote: |
Wouldn't
stop-n-swop work for testing those custom chips? Get code running in
SNES RAM, pull devcart out, put game cartridge in, then send commands
to code in RAM via controller port (which I've done successfully
before). What all things need to be tested? |
And how would this help to work on chips that only accept instructions
from ROM? Meaning, you make a request of the chip, and it checks the
ROM in back of it for details on what to do (of course offsetted by the
original request).
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 14, 2007 4:23 pm Post subject: |
|
Honestly,
for the last bits of info I need for the S-DD1, stop'n'swop would
probably work, assuming nothing screwy happens with its extra CIC or
whatever. I just hope it doesn't ruin my copier :/
I may as well try, it'd be much less expensive than an S-DD1 devcart.
But for the SPC7110 ... the connectors are setup like this:
Code ROM <> Address Bus <> SNES
Data ROM <> SPC7110 <> Address Bus <> SNES
The SPC7110 will accept commands from the SNES CPU, but will only work
with / decompress data from the data ROM that is connected behind the
SPC7110. A major part of cracking the compression algorithm is going to
be running custom data sets through the chip to see how it acts on the
data. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 15, 2007 8:46 am Post subject: |
|

That's from the original BS Zelda, week 3. At least, as original as we can get ... very little BS-X stuff is actually verified :/
The game itself boots through the BIOS. To get that to work, I had to
modify $ffd5 from $80 to $7f. Apparently, if that byte is >= $80,
the game will not show up in the list of games on the flash cart. I'm
guessing it's some sort of game disable thing. The St. GIGA service
probably disabled the game after a certain time period elapsed. I could
easily enough auto patch games when loaded, I guess.
I have all of the flash cart I/O emulated, and about half of the BS-X
cart MMIO emulated. But I don't emulate any of the base unit yet. Kind
of pointless to emulate the base unit anyway, but I'll add what I can
there as it may help compatibility. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Nov 15, 2007 10:21 am Post subject: |
|
byuu wrote: |
I
had to modify $ffd5 from $80 to $7f. Apparently, if that byte is >=
$80, the game will not show up in the list of games on the flash cart.
I'm guessing it's some sort of game disable thing. |
My notes on the subject tell me it's the year of download or'd with
other data. I haven't entirely figured out everything it's or'd with
though.
The BS-X did change the flags after some time to disable game. Also
when you go to delete a game in the town, it doesn't erase it, only
marks it as not there.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 15, 2007 10:43 am Post subject: |
|
New WIP up. Has a Windows binary this time.
I completed the BSX cart MMIO registers. It definitely doesn't work too
well. For one, I don't override the header bit in the emulator, so
anyone testing will have to modify the bit as discussed first. It also
doesn't work on my only other BS game, BS Dragon Quest. I don't know
why, it throws a St. GIGA error (09). Maybe it needs base unit
emulation ... who knows. There's probably bugs in the cart and flash
reg support, too.
Quote: |
My
notes on the subject tell me it's the year of download or'd with other
data. I haven't entirely figured out everything it's or'd with though. |
Well, Lancer said the BIOS makes sure d15 of $ffd5,$ffd4 is not set. If
it is, the game does not appear in the list of games you can start. I'm
guessing certain (all?) games expired after a certain date. If that's
true, then we're quite fortunate that only a header bit was set, rather
than the entire cart erased. So then, most likely all of these games
with $80 in $ffd5 appeared "blank", but were dumped and the games
retrieved.
Sigh, such a sad fate. Really makes you wonder why Nintendo hates their
fanbase so much to go out of their way to destroy these games.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Nov 15, 2007 11:26 am Post subject: |
|
byuu wrote: |
It also doesn't work on my only other BS game, BS Dragon Quest. |
What BS Dragon Quest game?
Seriously, you should use NSRT, so you know if you have any fishy hacks and incomplete dumps.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Nov 15, 2007 3:31 pm Post subject: |
|
All this talk about the BS makes me wonder if anybody recorded the actual satellite broadcasts.
I mean, somebody must have done it, right?
It used the normal satellite decoder, right? That means it should not have been that hard to record the broadcasts. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Nov 15, 2007 6:35 pm Post subject: |
|
or you'd think that Nintendo still has the original ones recorded.
when you release the next public version byuu I can start testing a
whole slew of BS games, I've got a bunch and I'll include the NSRT
information.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Nov 15, 2007 10:07 pm Post subject: 2 bugs to report: |
|
Heya byuu,
I was checking out the new WIP build, and I tried out the game: Fire Emblem - Thraki 776 (J) (NP).smc.
I noticed that when you start the game past the title screen all the gfx look like white garbled blocks.
Also if you do not start the game, and leave the title screen running, it crashes to a black screen.
As this game runs in previous versions of bsnes, I thought it was important to tell you right away.
Also I noticed that the configuration option: path.save does not seem to work for me any more.
It seems to only work at the default setting "" and any paths that I type in do not seem to work, it just saves to the same directory as the rom.
I hope this bug report helps you out, I am really impressed with your BS-X work, cheers dude  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 15, 2007 11:08 pm Post subject: |
|
Thanks for the feedback.
src/memory/smemory/mapper/generic.cpp:line 74:
Code: |
uint16 addr_hi = (cartridge.info.rom_size > 0x200000 || cartridge.info.ram_size > 32 * 1024) ? 0x7fff : 0xffff; |
Change to:
Code: |
uint16 addr_hi = (cartridge.cart.rom_size > 0x200000 || cartridge.cart.ram_size > 32 * 1024) ? 0x7fff : 0xffff; |
I moved the size stuff when I split the cart and slotted carts into
separate objects, rather than one merged one. Per above, it was
assuming the size of the cart was 0 (ouch), and mapping SRAM on top of
cartridge ROM.
As for path.save, yeah. Rewrote all of that code, it just chops off the
extension and replaces with .srm. I need to turn modify_extension()
into get_save_filename() or something, and parse path.save there.
Two good catches, thanks again.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Nov 17, 2007 10:09 am Post subject: |
|
New WIP is up.
I fixed PSRAM size, it's now 512kbytes. SRAM was correct before at
32kbytes. I also now save these files to "bsxbios.psr" (PSRAM) and
"bsxbios.srm" (SRAM). I honestly don't know if the PSRAM is supposed to
be battery backed or not. If it's not, it'll be easy enough to remove.
I imagine it is, because that's where you'd store your games on if you
lacked a flash cart. Would be pretty lousy to have it wiped every time
you power cycle.
I also save the PSRAM+SRAM data only once, just as a real BS-X cart
would work, and it also makes the Ancient Tablets series work with no
file renaming needed. I may add an option later to save these files
separately per-game.
BS-X support overall is still pitiful. bs-x.txt doc says $03 has to be
set to mirror PSRAM, SNES9x thinks it needs to be clear. Neither know
whether it affects just $60-6f or also $70-77. bs-x.txt doesn't say to
mirror hi/lo on PSRAM based on $02 setting, but SNES9x seems to try it.
LoROM doesn't map well into 64k granularity banks. Still don't emulate
$0c/$0d flash i/o register enable. Base unit is still completely
unsupported, and it's apparently needed for some games. And I have no
intentions of including an internal database of times to manually hack
the clock (even while the system is running!) ala SNESGT. I'm just
going to map the BS-X base unit RTC to the PC clock. Some stuff like
Dragon Slayer Eiyuu Densetsu work fine under regular mapping, yet don't
work with BS-X mapping. No idea why. Still don't hack-enable headers
during load, so that has to be done manually still (do this if the game
doesn't show up in cart menu. Make a backup if you care.)
Added SameGame support. Load it with "Load BS-X Slotted Cartridge"
(that's what it is, after all.) Unfortunately, I don't know what the
memory map is supposed to be, so the add-on cart doesn't appear to be
working. Or maybe I just can't figure out how to tell.
Nach or anyone else, would you mind sharing that info with me? The code
in SNES9x looks identical to what I have, but loading the FEoEZ
512kbyte cart doesn't seem to do anything. Well, at least the game
itself works under this menu option now.
Fixed config::path.save, and added realpath() for the Linux port, so ./
paths work too. Of course it won't be useful at all if you "install"
bsnes to /usr/bin, but if you keep it in its own folder, it's helpful.
Fixed the SRAM mapping bug affecting Fire Emblem 776. Also optimized
the file loading stuff a little more, removing a couple redundant ROM
memcpy's. Still far from perfect.
If possible, please test this WIP a lot. I'd like to post a new public release this weekend. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sat Nov 17, 2007 12:36 pm Post subject: Linux bsnes seems to abuse libao's PulseAudio driver |
|
In
Fedora 8, PulseAudio is the default sound daemon. Since libao 0.8.8
supports it, I decided to give that a try. Results weren't really
appealing. PulseAudio process was eating a whole lot of CPU power, and
after a while the connection to the daemon was terminated. ogg123 works
fine with PA, so I suspect the issue lies within bsnes. I've managed to
get some logs using verbose mode, but the behaviour here is different:
Code: |
I: protocol-native.c: Enabled SHM for new connection
I: client.c: Client 0 changed name from "Native client (UNIX socket client)" to "libao[bsnes]"
I: resampler.c: Using resampler 'speex-float-0'
I: resampler.c: Using float32le as working format.
I: resampler.c: Choosing speex quality setting 0.
I: sink-input.c: Created input 0 "libao[bsnes] test" on
alsa_output.pci_8086_27d8_alsa_playback_0 with sample spec s16le 2ch
44100Hz
D: memblockq.c: memblockq requested: maxlength=132300, tlength=88200, base=4, prebuf=86436, minreq=1764
D: memblockq.c: memblockq sanitized: maxlength=132300, tlength=88200, base=4, prebuf=86436, minreq=1764
I: module-alsa-sink.c: Trying resume...
I: module-alsa-sink.c: Resumed successfully...
I: module-alsa-sink.c: Starting playback.
D: module-suspend-on-idle.c: Sink alsa_output.pci_8086_27d8_alsa_playback_0 becomes busy.
I: module-volume-restore.c: Creating new entry for <pulsecore/protocol-native.c$libao[bsnes]>
D: module-suspend-on-idle.c: Sink alsa_output.pci_8086_27d8_alsa_playback_0 becomes idle.
D: module-suspend-on-idle.c: Sink alsa_output.pci_8086_27d8_alsa_playback_0 becomes idle.
I: sink-input.c: Freeing output 0 "libao[bsnes] test"
I: client.c: Freed 0 "libao[bsnes]"
I: protocol-native.c: connection died.
I: client.c: Created 1 "Native client (UNIX socket client)"
I: protocol-native.c: Got credentials: uid=500 gid=500 success=1
I: protocol-native.c: Enabled SHM for new connection
I: client.c: Client 1 changed name from "Native client (UNIX socket client)" to "libao[bsnes]"
I: module-volume-restore.c: Restoring volume for <pulsecore/protocol-native.c$libao[bsnes]>
I: module-volume-restore.c: Restoring sink for <pulsecore/protocol-native.c$libao[bsnes]>
I: resampler.c: Using resampler 'speex-float-0'
I: resampler.c: Using float32le as working format.
I: resampler.c: Choosing speex quality setting 0.
I: sink-input.c: Created input 1 "libao[bsnes] playback stream" on
alsa_output.pci_8086_27d8_alsa_playback_0 with sample spec s16le 2ch
32000Hz
D: memblockq.c: memblockq requested: maxlength=96000, tlength=64000, base=4, prebuf=62720, minreq=1280
D: memblockq.c: memblockq sanitized: maxlength=96000, tlength=64000, base=4, prebuf=62720, minreq=1280
D: module-suspend-on-idle.c: Sink alsa_output.pci_8086_27d8_alsa_playback_0 becomes busy.
D: memblock.c: Pool full
D: memblock.c: Pool full
D: memblock.c: Pool full
---snip--- |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Nov 17, 2007 5:28 pm Post subject: |
|
The
code in libao is the most simplistic in all of bsnes. There are only
perhaps three actual API calls. If there's something wrong with that
... oh well. The code looks fine and works great with ALSA and OSS. And
since I lack PulseAudio, someone else will have to fix it. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sat Nov 17, 2007 7:27 pm Post subject: |
|
OK, I'll try to find a solution with PA devs then. There are two more issues with 0.025:
1. Even when cartridge is not loaded, bsnes uses a considerable amount of cpu power.
2. Fullscreen does not work - toggling it moves the picture around the
window, but full screen mode is never entered.
Cheers. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 18, 2007 1:28 am Post subject: |
|
belegdol wrote: |
1. Even when cartridge is not loaded, bsnes uses a considerable amount of cpu power. |
I know you're reporting a linux issue, but I just thought I'd report that in Windows, this isn't happening.
Quote: |
2. Fullscreen does not work - toggling it moves the picture around the window, but full screen mode is never entered.
Cheers. |
I don't think a true fullscreen exists, if that's what you're asking
about. No one could think of a reason for having it.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Nov 18, 2007 1:54 am Post subject: |
|
fullscreen would be nice eventually, I know I'll never convert my brother until that day.
"I don't want to see any shit but the game I'm playing" he always says.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 18, 2007 2:08 am Post subject: |
|
I don't see anything but the game in pseudo-fullscreen, though. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 18, 2007 8:27 am Post subject: |
|
Figured
out what was wrong with SameGame. My mapper was correct (I compared it
to ZSNES by reading from each memory address), but it was using the
BS-X cart flash i/o registers. Something it's reading back out of the
vendor information is making it ignore the cart. I'll need to
disassemble the code to find out what.
Ironically, forcefully disabling vendor information completely makes it
work just fine. As a cheap fix for right now, I'll make the BSCHiROM
mapper (-only- used by SameGame) turn off that register.
This one will be tricky to fix right, though. The vendor info was not
dumped alongside these cartridges, and doesn't exist inside the files.
So there's really no reliable way to tell what kind of information a
BS-X flashcart should be returning when polled, even if I know what
both SameGame carts and standard carts should return. I can't rely on
cartridge size. I don't know of any actual BS-X carts that are
<8mbits (SameGame uses 4mbit carts), but some BS-X images have been
"trimmed" to that size by idiots.
Quote: |
1. Even when cartridge is not loaded, bsnes uses a considerable amount of cpu power. |
Fixed in WIPs.
Quote: |
2. Fullscreen does not work - toggling it moves the picture around the window, but full screen mode is never entered. |
It's pseudo-fullscreen. The window itself will fill your entire screen.
It then centers the window. You can change the video size from the menu
to fill more of the monitor, but if you make the picture bigger than
the screen, typically most video APIs will fail completely and you'll
get nothing. Eventually, I should poll the screen size and do the
clipping myself. But I don't have enough time to do everything I want,
and this is pretty low on the priority list.
I don't like the idea of stretching the video automatically. You run
into all kinds of issues then, like whether the monitor is widescreen,
running at 1280x1024 (5:4 instead of 4:3), etc.
And some people like having more control over the video output size, so there you go.
The only thing I lose by not having true fullscreen is the ability to
modify the refresh rate. And since I've never gotten video+audio
syncing together (and I'm starting to doubt I ever will), there's no
point in changing refresh rate anyway.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Nov 18, 2007 8:43 am Post subject: |
|
byuu wrote: |
It's pseudo-fullscreen. The window itself will fill your entire screen.
It then centers the window. You can change the video size from the menu
to fill more of the monitor, |
I actually really like that, how long has that been in place?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Nov 18, 2007 12:32 pm Post subject: |
|
I am quite sure that fullscreen does exist on Linux. Just look at the screensavers! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 18, 2007 1:18 pm Post subject: |
|
byuu.org wrote: |
2007-11-18 - bsnes v0.026 released
Since the last public release, I've completely rewritten the memory
mapping and cartridge loading systems. With this, I've added
preliminary support for the Broadcast Satellaview (BS-X), however very
few BS-X games will run at this time. I've also switched compilers from
Visual C++/8 to MinGW/GCC4, which grants a ~5-10% speedup over the
previous release.
Changelog:
* Major source code cleanup
* Completely rewrote memory mapper to support runtime MMCs
* Updated S-DD1 MMC to use new memory mapping interface
* Improved S-DD1 emulation, thanks to information from orwannon
* Added support for SameGame -- load via "Load Special -> Load BS-X Slotted Cart" menu option
* Completely rewrote cartridge loader to support BS-X, BS-X slotted carts and ST carts
* Created custom dialog windows for multicart loading
* Improved generic memory mapper, which eliminates the need for cart.db [Nach]
* Added BS-X slotted cart detection to generic memory mapper [Nach]
* Linux port will now ignore keypresses when window is inactive
* Linux port will use much less CPU power when idle
* Added detailed compilation instructions to Makefile for Linux port
* Added "make install" target and PNG program icon for Linux port
* Switched Windows compiler to MinGW/GCC4
* Windows executable is now packed with UPX to decrease filesize
* Removed .ufo, .gd7 and .078 ROM extensions; added .bs extension
* Added preliminary support for the BS-X base unit, BS-X base cartridge + MMC, and BS-X flash I/O |
Here's hoping that someone will lend a hand with the BS-X emulation, now that the code is public.
belegdol, you should like this release the most. It fixes a lot of the
stuff that was giving you trouble. Sorry about all of that, by the way.
Quote: |
I actually really like that, how long has that been in place? |
Not sure ... probably since v0.020 - v0.024 or so ...
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sun Nov 18, 2007 2:10 pm Post subject: |
|
This
release is quite nice, the bugs I mentioned are indeed fixed. I'll try
to work on the install section of the makefile a little bit, to make it
more relocation-friendly.
BTW, would it be possible to use system-wide zlib? |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Sun Nov 18, 2007 4:29 pm Post subject: |
|
One
thing that would be great for usability on Linux is to set the current
directory each time the file selector is run (no, the GTK file selector
does not do this for you, that would make too much sense). In my GTK
apps I now strip the filename off what gtk_file_chooser_get_filename()
returns and call chdir() on that, which works great. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sun Nov 18, 2007 7:47 pm Post subject: |
|
As promised, here is the patch improving the makefile:
http://www.belegdol.republika.pl/temp/bsnes-makefilefix.patch
Keep in mind that it is required to specify the target (make
PLATFORM=x-gcc-lui install) or it won't work. If you don't mind, I'll
add it to the RPM for the time being. I also have the .desktop file
handy, I can post it if you are interested. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Nov 18, 2007 8:18 pm Post subject: |
|
The
patch for the makefile looks nice to me, perhaps you could silently
update the source to include the updated Makefile? Or call it 0.026.01
or something? Having a fixed location isn't really pretty. :-/
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 18, 2007 8:44 pm Post subject: |
|
Oh, wow! I didn't even notice and it's been nearly a month!
tommowalker released NeuSneM v0.01.
http://www.geocities.com/tommowalker/snem.html
Pretty neat little open source Windows emulator, has sound and is
supposed to have a cycle-level CPU. Looks like he did this by having
the CPU ops call SMP ops when accessing the bus, which means the SMP
will still be opcode bound, which makes for a very good tradeoff
between accuracy and speed. Requires only ~1GHz for a cycle-level emu
written in C. Not too shabby.
I was hoping he would've switched to C++ and abstracted some stuff
more, but it's definitely shaping up a lot since the last release I
looked at. And I like the win32 menubar. Strangely nostalgic for me :)
Worth supporting, we need all the SNES developer interest we can get.
Quote: |
BTW, would it be possible to use system-wide zlib? |
Nope, need zlib for the Windows port. Nach's donated version should be
quite well optimized anyway. It only adds ~50kb when statically linked.
Quote: |
One
thing that would be great for usability on Linux is to set the current
directory each time the file selector is run (no, the GTK file selector
does not do this for you, that would make too much sense). In my GTK
apps I now strip the filename off what gtk_file_chooser_get_filename()
returns and call chdir() on that, which works great. |
Ah, I didn't realize GTK+ did this. For the meantime, try setting
"settings->config->advanced->path.rom" to the folder where you
keep your SNES games, and it'll always start up there.
I'll add your fix (assuming I don't forget, I'm bad at that) to the next release. Thank you!
Quote: |
As promised, here is the patch improving the makefile: |
Alright thanks, I'll improve the install target.
What's up with $(DESTDIR)? Is that supposed to be user defined? It also
looks like the actual paths are still hardcoded in the makefile, just
in variables that may be a tiny bit easier to modify :/
The install command looks really neat, not actually used that before. I assume it's just a cp + chmod?
Quote: |
The
patch for the makefile looks nice to me, perhaps you could silently
update the source to include the updated Makefile? Or call it 0.026.01
or something? Having a fixed location isn't really pretty. :-/ |
Well, see above first. Plus, I'd prefer not to make a silent source
release if possible, or make all the news sites update again for such a
small change. If you want to change the install target for ArchLinux
(or belegdol for Fedora), that's okay with me.
Last edited by byuu on Sun Nov 18, 2007 8:51 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 18, 2007 8:51 pm Post subject: |
|
byuu wrote: |
Quote: |
BTW, would it be possible to use system-wide zlib? |
Nope, need zlib for the Windows port. Nach's donated version should be quite well optimized anyway.
|
I'm not sure if I gave you the optimized zlib or not...
If I didn't and you want it though, I can arrange that.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sun Nov 18, 2007 8:54 pm Post subject: |
|
byuu wrote: |
Alright thanks, I'll improve the install target.
What's up with $(DESTDIR)? Is that supposed to be user defined? It also
looks like the actual paths are still hardcoded in the makefile, just
in variables that may be a tiny bit easier to modify :/ |
The destdir is used for the sake of chroot environments - most of the
software uses it. Normally, its value is nil, but in the process of RPM
building it is getting set to a temporary path and then rpmbuild
harvests built files from there.
The paths aren't really hardcoded, if you run
Code: |
make PLATFORM=x-gcc-lui PREFIX=/usr install |
the files will go to /usr instead of /usr/local.
byuu wrote: |
The install command looks really neat, not actually used that before. I assume it's just a cp + chmod? |
Basically, yes.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Nov 18, 2007 9:21 pm Post subject: |
|
I think you overlooked a tiny detail in the advanced configuration. There is entries marked as Integer that has boolean values. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Nov 18, 2007 9:35 pm Post subject: |
|
Woot.
Compiled bsnes on Linux (Still using Ubuntu) Pretty sweet. I'll
definitely start using Linux more and more but I doubt I'll abandon
Windows (well at least not XP). |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Nov 18, 2007 11:55 pm Post subject: |
|
Thanks for the new version. Did some testing this weekend on wip15 and didn't run into any issues myself.
I'm personally waiting for someone to create a better SNES emulator on
the psp. Just something from scratch that's faster than snes9x, with
anomie or blargg-level sound accuracy. I'm not really hurting for a
13th SNES emulator for the desktop that runs on old cpus. If he could
help an existing effort, though, that would be most beneficial.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 19, 2007 3:27 am Post subject: |
|
Quote: |
The destdir is used for the sake of chroot environments |
Ok, that all sounds good. Last question ... does $(DESTDIR) always have
a trailing backslash on the path? I noticed you used $(DESTDIR)$(BLA),
rather than $(DESTDIR)/$(BLA) ... just double checking.
Quote: |
I think you overlooked a tiny detail in the advanced configuration. There is entries marked as Integer that has boolean values. |
Well, not really. There are two types of Setting subclasses:
IntegerSetting and StringSetting. The former holds any kind of integral
value, but has a type flag that allows it to display and save in
boolean, decimal or hex notation. You're right that it's a bit
confusing to the end user ... but I figure it should be easy enough to
tell which of the three types are used, and you can actually specify
the number in any format for any Integer setting.
Quote: |
Woot.
Compiled bsnes on Linux (Still using Ubuntu) Pretty sweet. I'll
definitely start using Linux more and more but I doubt I'll abandon
Windows (well at least not XP). |
Cool! For those who have problems compiling, Derrick keeps debs up at http://repository.cinnamonpirate.com
, but I think that still has v0.025 at the moment. Man, three separate
distro packages made for me plus a Mac OS X port ... how fortunate am I
to have all this help? :)
Quote: |
Thanks for the new version. Did some testing this weekend on wip15 and didn't run into any issues myself. |
Sure, and thank you for testing the emulator so much. I can imagine
it's getting pretty mundane to keep testing all the time, and now that
we've gotten "everything" working -- you have me going back in and
rewriting / breaking stuff all the time :/
The help really is appreciated, though. There's just too many games for any one person to really test.
Quote: |
I'm personally waiting for someone to create a better SNES emulator on the psp. |
You and me both. Just picked up the slim model today for the video out (yeah, I mostly play at home ...)
The SNES9x port is quite bad, runs below 60fps most of the time and has
serious issues even with basic HDMA effects such as the circle fade-ins
in Mario and Zelda 3. But, better than nothing, right?
Still, something about a pocket-sized SNES with hundreds of games is just awesome.
I really don't know why people are wasting their time on the GBA and DS
... the psp has the right amount of buttons, a big enough screen for
the whole image, way easier and cheaper homebrew + storage capacity,
and the processing power to reach 60fps and 98% compatibility with the
right speed hacks in place.
If I weren't already working on an emulator, I'd probably give it a shot myself. But alas ...
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Nov 19, 2007 3:39 am Post subject: |
|
and yet you play it on your tv at home awesome. and thanks for another public release so soon.
EDIT: what must the bs bios file be named again?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Mon Nov 19, 2007 10:20 am Post subject: |
|
byuu wrote: |
Quote: |
The destdir is used for the sake of chroot environments |
Ok, that all sounds good. Last question ... does $(DESTDIR) always have
a trailing backslash on the path? I noticed you used $(DESTDIR)$(BLA),
rather than $(DESTDIR)/$(BLA) ... just double checking.
|
It does not. $(BLA), i.e. $(PREFIX) is supposed to start with a slash.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Nov 19, 2007 11:41 am Post subject: |
|
Also,
compilling bsnes is a lot faster than I thought it would be. Not even
half a minute and I have an old P4. Then again, the only prior
compiling experience I had was with MAME with it's hundred of drivers
so...
Ah...all this human readable codes, and I
can't even help... Heck, I even have a copier so in theory I even have
access to all the hardware I need to run my own code on hardware and
stuff... |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Nov 19, 2007 3:30 pm Post subject: |
|
Thanks for the new release, byuu 
Snark wrote: |
Ah...all this human readable codes, and I can't even help... |
I know what you mean.. hope to help out in the future though.
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Mon Nov 19, 2007 9:48 pm Post subject: |
|
Holy crap! This release is amazing! I noticed a siginificant speed increase! Congrats!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Nov 19, 2007 11:26 pm Post subject: |
|
small bug, loading a invalid file as a ROM crashes the emulator i tried loading a JMA file and it crashed with the standard windows error.
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 20, 2007 12:06 pm Post subject: |
|
I wanted to get v0.026 out the door before I started on a major new project.
That project is miu.
First pre-alpha release (Linux/GTK+ only):
Code: |
byuu.org/files/miu_20071120.zip |
Comments / suggestions from programmers very welcome.
miu is a ground-up rewrite of libui. This time, it gets promoted from a
tiny stub library to a full-fledged standalone development library.
It's goal is to become a lightweight, ISC-licensed toolkit similar to
wxWidgets. Rather than implement my own graphical toolkit, I'll just
leverage the best available for each platform. Combined with the
video/audio/input drivers I've been accumulating from bsnes, it should
be a viable system for cross-platform development.
But the goal isn't to create some overkill, massive, ~500kb of source
library spanning 1,500+ files. It's designed for lightweight
applications that do not need very specific customizations to UI
elements (eg tree-nested drag-and-drop menus with pixmap icons that
resize dynamically and are multi-monitor aware probably won't show up
in miu). The idea is to compile the source statically into applications
that use it, and dynamically link against the libraries the miu-backend
uses.
I learned from the shortcomings in libui, so this time here is how things are different:
Before, I was forced to have separate base headers for each
implementation, as the classes required data objects that were declared
inside platform-specific headers like gtk/gtk.h and windows.h. This
also polluted the global namespace with their names. GTK+ was quite
bad, due to X11 dependencies. X11 eats up names like "Window", "Font",
etc ... horrible design, that.
Now, I'm implementing the base library using the "pimpl" (private
implementation) idiom. This allows one object to be built with the
actual platform-specific stuff, and all other object files only see the
base header, shared between all ports. This also has the benefit of
hiding all of the implementation details even farther from library
users, whereas before I was forced to expose some platform-specific
internal stuff. And yet another benefit that the implementation can be
changed without having to recompile the entire program.
I'm also using the functor template library blargg helped me with, and
a standardized event message passing system, which will allow one to
bind callbacks however they like. One can bind all callbacks for the
entire program to one single member function pointer, or to a hundred
different static function pointers. Whatever you want -- the Event
struct passed to the callback function will have all the info you need
either way.
The source is going to be split up a lot more, rather than sticking
with those giant grouped files from before. Different backends in
different folders, and such.
Before, I had problems where Windows had to have hide() inside MenuItem
: Control, but GTK+ could implement hide() inside Control. Thanks to
the pimpl design, this will be standardized now.
I've also built in the singleton pattern for the core object that
handles initialization and termination, rather than use global
functions and variables for those.
Next, I've got font stuff working on GTK+ now, so I'll be developing
more adept font rendering tricks to get a more consistent look between
Windows and GTK+, and hopefully allow me to work on a cross-platform
debugger finally.
After that, I'm also planning to develop a toolkit optional add-on for
"bloat" features like various widget packing styles, so you don't have
to worry about exact pixel placement of controls anymore.
All in all, it's going to be a lot cleaner, a lot better documented, a
lot more feature-filled, a lot safer, and a lot easier to use.
... and it'll probably have zero to ten users, just like all my other libs :)
But yeah, should mark a nice improvement once I get it ready and ported
back into bsnes. Won't have to spend months with another full UI
rewrite this time, as the basic API will still be very similar, just a
lot more polished. Maybe one week to rewrite all that stuff.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Nov 20, 2007 1:33 pm Post subject: |
|
byuu wrote: |
... and it'll probably have zero to ten users, just like all my other libs  |
Hell, I'd use it, sounds like a big time-saver at the least
I've wanted to see if I could use libui for a while now, but since it
was only included in bsnes.. You should consider spreading the word
once you get the first release ready though, could save a lot of people
a big headache.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Nov 21, 2007 10:09 am Post subject: |
|
byuu wrote: |
Comments / suggestions from programmers very welcome. |
This probably isn't all that helpful, but your test app doesn't compile
on OS X 10.4 because test.cpp defines a global "kill", but that name
already exists in a system header (the library version of /bin/kill).
Renaming your flag to "shouldExit" (or whatever) works nicely.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Nov 21, 2007 7:15 pm Post subject: |
|
sounds fantastic and will help things go much smoother.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 21, 2007 10:19 pm Post subject: |
|
Quote: |
This
probably isn't all that helpful, but your test app doesn't compile on
OS X 10.4 because test.cpp defines a global "kill", but that name
already exists in a system header (the library version of /bin/kill).
Renaming your flag to "shouldExit" (or whatever) works nicely. |
... wow, you can build GTK+ apps on OS X? I figured Qt would be required for that for some reason.
Hmm, I don't suppose I could ask you for a huge favor, then? Richard
Bannister has done a fantastic job with the OS X port of bsnes, but
sadly due to my constant changes and breaking PPC support by use of
x86-only assembler, that port has kind of stalled out nine versions
ago. It would be really nice if I could get the current version to
compile on OS X. Even if it lacks the polish of a custom Carbon / Cocoa
/ Core (or whatever the trend-of-the-week there is) interface, and
lacks PPC support -- something would be better than nothing ...
I believe this would, at most, require a new makefile target
(osx-gcc-lui), a PLATFORM_OSX define, and to change some headers and
function names. We could tie video out to the GTK+ backend, and leave
audio and input disabled for now. I can rig up a GTK+ input backend
later on if it works, and that should be good. wertigon gave me some
OpenAL code recently, so if libao or OpenAL exists there, audio could
be doable, too. And then there's always the off-chance that someone
will donate more workable modules for that stuff once building is
possible.
Problem is, I don't have any Apple hardware or OS X to test on myself,
so I wouldn't know what to change / fix. Would you be willing to take a
look at building there?
If not, that's okay. I was planning on targeting OS X more aggressively
with a Qt backend to miu in the future. Obviously, due to licensing
incompatibilities, that would require end-users to build their own
binaries and not distribute them.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Nov 21, 2007 11:33 pm Post subject: Ideas for Debugging in bsnes |
|
Heya byuu,
Your new project mui sounds really cool and the thing that excites me the most is the cross platform debug support.
I think if it is possible to implement this, it would be great to have
the following options added to your allready great debugging options
from bsnes version 0.13:
1) Map Viewer: Show any BG maps in use with a maximum 1024x1024 size for mode 7.
2) OAM Viewer: Show the sprite blocks in use, with an oam base address selecter for different sprites.
3) Tile Viewer: Show the tiles from a selectable memory address, with a
toggle for the different snes colour modes.
4) Pallete Viewer: Show the 256 Pallette entries for BG's and Sprites, in order.
5) BG, Sprite Toggle: Have the ability to turn of any BG's or Sprites on screen with tick boxes.
I have nicked these ideas from Visual Boy Advance's
debugging functionality, which is a GBA emulator, so if you want a
rough idea of what I am on about check it out with a gba rom. The
reason I am suggesting this at the mo, is incase you need to tweak
anything in your new lib mui, to be able to perform these functions,
(only if you like any of these ideas of course)!
Tell me what you think, and keep up your great work =D
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Nov 22, 2007 11:01 am Post subject: |
|
http://www.robpol86.com/Pages/imagecfg.php
using this tool on v0.26 results in bsnes failing to initialize yet earlier versions of bsnes ran perfectly. why?
i also see a massive performance increase in this version ^^ good stuff byuu.
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 22, 2007 11:10 am Post subject: |
|
miu, not mui :)
And here's a new version, completely rewritten again, heh.
Code: |
http://byuu.cinnamonpirate.com/files/miu_20071122.zip |
This version is wild. I had to basically implement multiple-level
virtual functions both on the public implementation and the private
implementation -- despite them being two different objects. This got to
be really complex, and took a lot of deep thought to figure out. I only
had to do one thing I'm not sure is part of the standard ... in my
constructor initialization list, I had to assign the new pointer to one
of the other variables, eg:
Window::Window() : Widget(p = new pWindow(*this)) {}
Lucky me though, gotw.ca was saying it wasn't possible to implement
virtual functions through pimpl setups ... heh.
I can't read p right back from Widget after assignment, because it is
private. I could make it protected, though, if need be. But then I'd
have a "protected implementation" pimpl instead of a "private
implementation" pimpl. Or I could rig up specific member friend
functions to fetch the variables out.
I also threw out the XEvent clone in favor of even more simplicity and
safety. Events are now just a 3-entry struct of type, param (can be
user defined if invoking events manually) and widget pointer. And with
a handy constructor, they can be built inside event function calls, eg:
on_click(Event(Event::Click, param, this));
The only issue I have currently is that due to the sharing of pointers,
delete ends up getting called for each class derivation on the public
implementations, ergo crashing on exit. I was under the impression that
a non-virtual base destructor would not be called when deleting the
derived object only, but apparently it is ... not sure why. My idea to
fix it is to use a shared_ptr wrapper around each new pointer.
test.cpp is really showing off miu's simplicity now. It creates a full
window with buttons that have different actions.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Nov 22, 2007 11:41 am Post subject: |
|
Quote: |
NSRT v3.3 - Nach's SNES ROM Tools
---------------------Internal ROM Info----------------------
File: Donkey Kong Country 2 (U) (R1.1).SWC
Name: DIDDY'S KONG QUEST Company: Nintendo
Header: SWC + NSRT Bank: HiROM
Interleaved: No SRAM: 16 Kb
Type: Normal + Batt ROM: 32 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.1
Checksum: Good 0x9860 CRC32: 4E2D90F4
MD5: D323E6BB4CCC85FD7B416F58350BC1A2
--------------------------Database--------------------------
Name: Donkey Kong Country 2
Country: USA Revision: 1.1
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Side Scrolling
-------------------------NSRT Header------------------------
Version: 2.2
Port 1: Gamepad Port 2: Gamepad
Renamed Donkey Kong Country 2 (U) (R1.1).SWC to Donkey Kong Country 2 (U)(R1.1).SWC |
hey the Nintendo logo is squished to the left while it flashes o0.
_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Nov 23, 2007 1:20 am Post subject: |
|
I can't seem to reproduce your bug. That's kind of a weird looking header though. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Nov 23, 2007 2:27 am Post subject: |
|
removing
the header fixes it o0... i thought headers were ignored in bsnes?
anyway i removed the header for all roms except those with special
controls.
_________________
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. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Nov 23, 2007 5:38 am Post subject: |
|
franpa,
it should be obvious that it is the NSRT header that BSNES does not
support or handle. Same thing would occur for all other emus that don't
deal with it as well.
_________________
FF4 research never ends for me. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Nov 23, 2007 11:59 am Post subject: |
|
Deathlike2 wrote: |
franpa,
it should be obvious that it is the NSRT header that BSNES does not
support or handle. Same thing would occur for all other emus that don't
deal with it as well. |
So? It should ignore it like all others. It shouldn't make the screen go funny.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 23, 2007 12:56 pm Post subject: |
|
Crushed
video is caused by switching video modes (sizes) with the D3D driver
when your graphics card lacks StretchRect support. There's some issue
with the texture coord settings that I just honestly haven't had any
time to look into. Restarting the emulator fixes it.
EDIT: oh yeah, solved the miu problems.
Multiple delete was an easy one -- just delete only on the base
destructor. Since ctors / dtors are called in FILO order, that works
fine.
And then I used the base_from_member trick rather than relying on
potentially undefined behavior of assignment to a derived class member
inside a base class initializer.
Looks like this:
Code: |
Button::Button() :
base_from_member<pButton&>(*new pButton(*this)),
FormControl(base_from_member<pButton&>::value),
p(base_from_member<pButton&>::value) {}
Button::Button(pButton &p_) :
base_from_member<pButton&>(p_),
FormControl(base_from_member<pButton&>::value),
p(base_from_member<pButton&>::value) {}
FormControl::FormControl() :
base_from_member<pFormControl&>(*new pFormControl(*this)),
Widget(base_from_member<pFormControl&>::value),
p(base_from_member<pFormControl&>::value) {}
FormControl::FormControl(pFormControl &p_) :
base_from_member<pFormControl&>(p_),
Widget(base_from_member<pFormControl&>::value),
p(base_from_member<pFormControl&>::value) {}
Widget::Widget() : p(*new pWidget(*this)) {}
Widget::Widget(pWidget &p_) : p(p_) {}
Widget::~Widget() { delete &p; } |
Pretty verbose, but it's hidden away from the user and there won't be
more than ~20 classes anyway. Typedefs would probably help. But it
works as intended. And best of all, I get to keep p private, instead of
having to make it protected (read: public).
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Nov 24, 2007 11:07 am Post subject: |
|
byuu wrote: |
Quote: |
This
probably isn't all that helpful, but your test app doesn't compile on
OS X 10.4 because test.cpp defines a global "kill", but that name
already exists in a system header (the library version of /bin/kill).
Renaming your flag to "shouldExit" (or whatever) works nicely. |
... wow, you can build GTK+ apps on OS X? I figured Qt would be required for that for some reason.
|
Well, OS X comes with an X11 server, so (modulo the usual
compiler/library breakage) most GTK+ apps compile and run just fine.
Real Mac users absolutely detest such apps, but I personally prefer
GIMP to Photoshop so I'm quite happy.
byuu wrote: |
Hmm,
I don't suppose I could ask you for a huge favor, then? Richard
Bannister has done a fantastic job with the OS X port of bsnes, but
sadly due to my constant changes and breaking PPC support by use of
x86-only assembler, that port has kind of stalled out nine versions
ago. It would be really nice if I could get the current version to
compile on OS X. Even if it lacks the polish of a custom Carbon / Cocoa
/ Core (or whatever the trend-of-the-week there is) interface, and
lacks PPC support -- something would be better than nothing ... |
Unfortunately, I only have a PPC available to me, so I'm unlikely to be much help here.
byuu wrote: |
wertigon gave me some OpenAL code recently, so if libao or OpenAL exists there, audio could be doable, too. |
libao is ported, but only supports 44.1KHz output.
byuu wrote: |
If not, that's okay. I was planning on targeting OS X more aggressively with a Qt backend to miu in the future. |
I almost asked why you didn't just use Qt when you originally announced
miu, especially since you don't share my personal biggest objection to
it[1]. Then I remembered that it's always nicer to deal with a simple,
focussed API rather than a huge, general API. Still, it seems to have
worked nicely for Gambatte.
[1] It's written in C++.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Mon Nov 26, 2007 3:54 pm Post subject: |
|
Yeah,
Mac OS X comes with or can support all the goodies you'd expect from
Linux/BSD. There's even a community-supported port of the BSD ports
system, from which you can grab GTK, KDE, GNOME, and anything else
you'd want that would make diehard Mac users freak out 
I will definitely be taking a look at miu - I've been intending to port
Richard Bannister's Mac-only Virtual Boy emulator to Linux and Windows
and unlike him I don't have a standard GUI framework around so I've
been putting it off  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Nov 26, 2007 5:52 pm Post subject: |
|
Quote: |
Real Mac users absolutely detest such apps |
Hah, yeah. "What's this? A menubar in the actual application window
where it belongs? Balderdash! Keep up this nonsense, and the next thing
you know -- clicking the close button will actually close the
application! Why don't we just send elephants to the moon while we're
at it?!"
Quote: |
Unfortunately, I only have a PPC available to me, so I'm unlikely to be much help here. |
Ah, that's too bad. No PPC libco port exists. Thanks anyway.
Quote: |
[1] It's written in C++. |
I actually have to agree, C++ libraries, by virtue of having so much
more power, also have the ability to add so much more complexity. And
you can't use them in both C and C++ apps.
I'm really trying to keep things as simple as possible here, though. No
#define maps for callbacks, no template / overloaded operator /
inheritance stuff if you don't want it ... the worst case is that for a
few operations, you call object.create(...) instead of just
create_object(object, ...)
You have to admit though, a user interface library is practically the
poster child example for OOP. I can't think of any task more suited for
it.
Of course, C wrappers ala DirectX should be doable if desired.
Anyway, my main objection to Qt is licensing. I'm not going to be
bullied into releasing under the GPL just to use a graphical toolkit.
Besides, the GPL is a distribution license. If someone wants to take
miu, and modify the bsnes Makefile with sed s/miu_gtk/miu_qt ... only
distribution of the resulting binary would be illegal. Nothing I could
do about that, right?
Quote: |
I
will definitely be taking a look at miu - I've been intending to port
Richard Bannister's Mac-only Virtual Boy emulator to Linux and Windows
and unlike him I don't have a standard GUI framework around so I've
been putting it off |
Oh, neat! In that case, feel free to directly request features and such
once I get a beta version ready, and I'll try and add them. Even one
project that I'm not in charge of using the library would be a great
help. It will also hopefully encourage other people to make backend
ports to other APIs such as Qt, Cocoa, etc. Hey, one can always dream
...
EDIT:
I just realized I never linked to any of the bsnes ports on my website
... oops. If anyone wants me to link to their port (belegdol, [vEX]?),
please let me know.
Last edited by byuu on Tue Nov 27, 2007 11:30 am; edited 1 time in total
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Mon Nov 26, 2007 6:48 pm Post subject: |
|
Quote: |
I
will definitely be taking a look at miu - I've been intending to port
Richard Bannister's Mac-only Virtual Boy emulator to Linux and Windows
and unlike him I don't have a standard GUI framework around so I've
been putting it off |
Please do! I want to get my Wario Land on
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Nov 27, 2007 4:54 pm Post subject: |
|
byuu wrote: |
"What's
this? A menubar in the actual application window where it belongs?
Balderdash! Keep up this nonsense, and the next thing you know --
clicking the close button will actually close the application! Why
don't we just send elephants to the moon while we're at it?!" |
What's this? Fitts' law?
|
|
Kazuma New Member
Joined: 24 Jul 2006
Posts: 3
|
Posted: Tue Nov 27, 2007 6:51 pm Post subject: |
|
I
believe the Cheat Code Editor may be broken in 0.026. I was toying
around with a few cheats lately, and noticed they worked in older bsnes
versions such as 0.025 and back, but not 0.026.
Example: In Legend of Zelda: A Link to the Past, the code 7EF36E:80
should give you full magic. It does in 0.025 and back, but not in 0.026. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Nov 27, 2007 7:47 pm Post subject: |
|
blargg's link wrote: |
Detaching applications from their UI in this manner seems to violate the rule of proximity - related things should be together. |
QFT.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 27, 2007 9:23 pm Post subject: |
|
Quote: |
What's this? Fitts' law? |
Fitts' Law has nothing to do with Mac menubars ... I'm sure you could
find another law to support the close button really being more of a
glorified minimize button ("Hey, users don't really know better, and
often close an app when they really wanted to minimize it. This saves productivity by making apps open faster!")
First, the "infinite height" thing may be valuable if you have an
accessibility handicap. I myself don't recall the last time I missed a
menubar in an application, nor do I feel it's much slower than slamming
the mouse into the top of the screen, far away from your application,
just so you don't have to align the Y-axis of your mouse to the menu.
Second, it ruins multi-tasking, since only one menubar can be visible
at a time. Especially bad if you have a complex app that has two
separate windows that each have their own menubars.
Third, the proximity is terrible. You can have an application and its
buttons down at the bottom of your screen, but you have to move all the
way up to the top to get to the menubar ... this gets worse as screen
size increases.
I'm really not in favor of things having to be one way or the other,
set in stone ... and I think that's what I dislike most about Macs.
It's Jobs' way or the highway. I'll admit that Windows lacks an option
to put menubars at the top of the screen (maybe it's patented?), but it
is less restrictive as a whole. Overall I think all OSes should offer
multiple models for what best serves each person.
Anyway, no need to dilute this thread, if you want to reply to the
above publicly and then take it to PM, I'd be happy to discuss the
issue further. Not that it really matters, we're probably the least
likely people in the world to actually change any of this.
Quote: |
I believe the Cheat Code Editor may be broken in 0.026. |
Thanks, I'll take a look at it.
|
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Tue Nov 27, 2007 10:31 pm Post subject: |
|
Quote: |
Fitts' Law has nothing to do with Mac menubars |
Everyone has preconcieved notions about what's best in UIs, but the
pure research is consistent and well-documented (and currently ignored
to varying degrees by Apple, Microsoft, Trolltech, and GTK in favor of
making the function a slave to the form). Fitts fully supports the Mac
menubars, and it's cited frequently by members of the original Mac
design team (e.g. Bruce Tognazzini's online usability blog/column/rant
thing).
If you're like me and the first GUI you learned was Apple-style you
pick up the muscle memory of slamming the mouse to the top to hit
menus, and it really is faster (and less prone to carpal tunnel due to
fewer fine-grained wrist motions). If you were first exposed to
Windows-style UIs you won't understand the point (especially since the
Win95 and later taskbar copied some of the surface attributes of the
Mac menubar without understanding the underlying research, and thus
violates Fitts all over the place).
Multitasking works fine - the menubar changes to whatever window has
focus. Multiple monitors is a solvable problem for both the Mac-style
menubar and the Windows-style taskbar that nobody's solved yet,
although KDE 3.5 does a better job than most. And if you have multiple
menubars in one application you have far worse usability problems than
where the menubar is.
The close button is how it is because the Mac's philosophy is
one-document-at-a-time whereas Windows betrays it's DOS roots by being
one-application-at-a-time. In practice it again depends which UI you
learned UIs on, but I do think the Apple approach has merit if you are
in that mindset. And most experienced users are keyboard warriors so
there's little difference between Alt-F4 and Command-Q to force a full
app close.
Anyway, back to topic
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Wed Nov 28, 2007 12:27 am Post subject: |
|
Arbee wrote: |
If
you're like me and the first GUI you learned was Apple-style you pick
up the muscle memory of slamming the mouse to the top to hit menus, and
it really is faster (and less prone to carpal tunnel due to fewer
fine-grained wrist motions). If you were first exposed to Windows-style
UIs you won't understand the point (especially since the Win95 and
later taskbar copied some of the surface attributes of the Mac menubar
without understanding the underlying research, and thus violates Fitts
all over the place).
|
You talk like Microsoft designed their user interface to knock off Apple's, which is simply not true.
All the major companies in the business of UI design were drawing
elements from a lot of different research projects and failed OSes.
It's really unfortunate that the most vocal advocates of Mac OS have to
parade around the superiority of their OS as if it were born ex nihilo
perfect and complete, rather than being a result of standing on the
shoulders of giants.
Mark Twain wrote: |
But
lemme correct you in one thing -- I mean soothe you with one fact: a
considerable part of every book is an unconscious plagiarism of some
previous book. There is no sin about it. If there were, and it were of
the deadly sort, it would eventually be necessary to restrict hell to
authors -- and then enlarge it. |
- Mark Twain to editor of Grants Pass Observer dated April 2, 1887.
Reprinted in The Morning Oregonian, May 4, 1910, p. 10.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Nov 28, 2007 12:52 am Post subject: |
|
the first Mac and Windows OSs were basically salvaged from a group of researchers at Xerox PARC right?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 28, 2007 1:34 am Post subject: |
|
Quote: |
And if you have multiple menubars in one application you have far worse usability problems than where the menubar is. |
I haven't actually had the need to ever do this myself, but if there's
one thing I've learned while studying the millions of different
features in C++, it's that you will sometimes think a specific language
feature / template / idiom is useless ... until you need it. Then you
realize that it had value all along.
I was thinking myself that a menubar on the bsnes debugger window might
be a better approach than a ton of buttons. At least, it would take a
lot less total screen space that way. And that's going to be a big
issue, my last debugger ate up ~80% of a desktop running at 1152x864,
despite being reasonably compact, and lacking any kind of PPU debugging
capabilities (read: large graphical bitmaps all over the screen).
The good news is that if miu is a success, one can use Qt, and at least
for KDE3/4 and OS X, you can have the menubar as you like at the top :)
Only problem is that I know next to nothing about Qt, so I'll need a
lot of help with the port. I can only deliver Win32 (non-MFC, of
course) and GTK+ bindings for sure.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed Nov 28, 2007 1:47 am Post subject: |
|
Quote: |
You talk like Microsoft designed their user interface to knock off Apple's, which is simply not true. |
I talk like it was a major influence, which is well documented. Yes,
Windows 1.0 was mostly a basic PARC-alike, but Windows 2.0 was designed
by the leader of the Word for Mac team, and Windows 3.0 was themed by
the same artist who designed the theme for the original Mac OS.
Quote: |
It's
really unfortunate that the most vocal advocates of Mac OS have to
parade around the superiority of their OS as if it were born ex nihilo
perfect and complete |
I didn't claim the Mac OS was superior (I'm a Unix bigot by trade), and
I certainly didn't claim it was magically born from nowhere (it's an
obvious evolution of the Lisa UI, which in turn was evolved from PARC -
Andy Hertzfeld's book that publishes a lot of screenshots of the
intermediate steps is fascinating). I was pointing out that a lot of
what is percieved as "right" and "wrong" in UIs depends on what you
trained on first, and that actual usability studies can show that all
sides are wrong.
For instance, the best and fastest Windows file open dialog ever
shipped (according to usability data) was the Windows 3.11 one.
Seriously. And OS X is a large step downards in usability from the
"classic" Mac OS. Innovation isn't always a good thing.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed Nov 28, 2007 1:52 am Post subject: |
|
Quote: |
The
good news is that if miu is a success, one can use Qt, and at least for
KDE3/4 and OS X, you can have the menubar as you like at the top  |
Actually I don't run KDE that way (I have to use Windows at work, so my
original muscle memory is long gone). But GNOME does ship with a
menubar at the top by default, at least on Fedora 7 and 8.
And Qt's C++ness is exactly why it's better than GTK - because OO is a
native idiom in C++ instead of something bolted on with macros a lot of
things simply work much more naturally (not to mention that on a good
editor with autocompletion you don't need to refer to API docs as much
- just type mListbox-> and see what appears).
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Nov 28, 2007 1:53 am Post subject: |
|
Arbee wrote: |
For
instance, the best and fastest Windows file open dialog ever shipped
(according to usability data) was the Windows 3.11 one. Seriously. And
OS X is a large step downards in usability from the "classic" Mac OS.
Innovation isn't always a good thing. |
Usable? Yes. Fast? Yes. Friendly? Hell no, you'd be scared to death how unfriendly looking that was.
_________________
FF4 research never ends for me.
|
|
Lazarus New Member
Joined: 29 Aug 2006
Posts: 8
|
Posted: Wed Nov 28, 2007 1:53 am Post subject: |
|
I may be way off on this (I'm not much of a programmer) but, Byuu, wile I of course value the miu effort, have you considered using cairo? |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Nov 28, 2007 2:11 am Post subject: |
|
Panzer88 wrote: |
the first Mac and Windows OSs were basically salvaged from a group of researchers at Xerox PARC right? |
Mac was stolen from the Xerox STAR, which was developed at the PARC.
It wasn't "rescued" as STAR actually came out.
Windows was stolen partially from Mac, partially from the emerging DOS
GUI market. Poducts such as DESQView, GEM, and VisiOn were coming to
market, and if one of them was established first, Windows was
doomed(all 3 hit before Windows did, barely).
Windows was actually announced early to knock the wind out of VisiOn's
sails, as it was the one they were really worried about.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Nov 28, 2007 11:14 am Post subject: |
|
Lazarus wrote: |
I may be way off on this (I'm not much of a programmer) but, Byuu, wile I of course value the miu effort, have you considered using cairo? |
miu seems to be a GUI-toolkit abstraction layer, like wxWindows, or...
uh... well, like wxWindows. Cairo is a cross-platform 2D graphics API,
much like OpenGL is for 3D. byuu could implement his own GUI toolkit on
top of Cairo (much like GTK+ does), but I'd wager he'd much prefer to
let other people deal with the mind-numbing complexity of GUI-toolkit
coding.
Obligatory off-topic comment: the history of MacOS and Windows, and the
measurable usability differences between them (as in
time-elapsed-with-a-stopwatch, not 'I prefer mauve') have been
adequately covered elsewhere; go read about it on Wikipedia or
something. :P
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 28, 2007 11:46 am Post subject: |
|
libui
had eighteen controls. I have four ported to miu/win32, and eight to
miu/gtk. I've been trying to do more, but my mind just goes numb after
six or so hours straight of this ...

I also rewrote libstring. I apparently didn't know about implicit
conversion operators back then, because half the functions weren't even
needed ...
Not sure why, but I renamed all of the libs from lib* -> b*, except libco. bco sounds kind of stupid.
Quote: |
miu
seems to be a GUI-toolkit abstraction layer, like wxWindows, or...
uh... well, like wxWindows. Cairo is a cross-platform 2D graphics API,
much like OpenGL is for 3D. byuu could implement his own GUI toolkit on
top of Cairo (much like GTK+ does), but I'd wager he'd much prefer to
let other people deal with the mind-numbing complexity of GUI-toolkit
coding. |
Yeah, the only abstraction GUI toolkit I could find was wxWindows,
which I really didn't like very much. Too big, too bulky. Good if you
want a really high-end interface with a ridiculous level of control.
Bad if you want to learn the API quickly, or want to port it to another
toolkit yourself.
And funny story, I actually have written my own GUI toolkit before,
many years back. It ran in both Windows/DirectX and DOS/VESA2. It was
quite terrible, of course. I never realized how unbelievably difficult
it was to implement an editbox control by hand ... insert/delete
operations bounded by the cursor position which changes based on
arbitrary clicking positions by the mouse inside the editbox, when you
have a variable width font ... world of pain, seriously. Don't ever go there.
|
|
Lazarus New Member
Joined: 29 Aug 2006
Posts: 8
|
Posted: Wed Nov 28, 2007 12:50 pm Post subject: |
|
Thanks, I understand. I failed to read properly this morning.
And good luck. Should be quite useful for others too, if it works out. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Nov 30, 2007 7:02 am Post subject: |
|
Alright,
I'm out of time and won't be able to work on anything for the next week
or so. I wanted to get miu finished, and I got damn close ... about
80kb of pure C++ written in four days (and another ~30kb ported from
the old libstring to the new bstring). But it still lacks the Win32
callback hooks. And both backends lack window nesting (needed for the
bsnes configuration panel), file load/save dialogs, and font change
stuff. Well, I tried.
I made a page for it here: http://byuu.org/miu
It also has a download link for what I have so far. I'll still have
internet access to respond to comments here and such.
If anyone considering using the library wouldn't mind, please take a
look at test/test.cpp and let me know what you think. If you don't like
the names of various functions / callbacks, see functionality you
require missing, have concerns about the overall design, or anything
like that, now's definitely the time to let me know. I'm planning to
use multiple dots in the version number, and keep minor versions
API-compatible, so I'd like to have even the first release relatively
stable and long-lasting, if possible.
Other controls that don't exist:
- status bar -- need to carefully plan how to design that and interact with window size, but I'd like to add this
- editbox with up/down arrows to scroll through number range -- sliders
and pure editboxes work better, and they're also a major pain to
implement both in GTK+ and Windows
- tab container -- a major pain on Windows, but this would be very nice
to have as an alternative to the listbox + panel trick.
- standalone scrollbars -- what's the point? Use sliders, scrollbars
are too specialized for such a simplistic library |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Nov 30, 2007 1:16 pm Post subject: |
|
byuu,
Visual C++ 2008 was released last week. I know you previously had some
issues with Visual C++. You're probably happy with MiniGW/GCC and don't
care, but I figured I'd say something anyway in case you wanted to
experiment with it to see if they fixed anything worthwhile. It seems
like their focus was Vista development this time around of course, so
perhaps not.
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Dec 04, 2007 9:10 pm Post subject: |
|
since
it's in the recommended specs on byuu's site, I was wondering if anyone
knew where online to shop for nice sound cards that support
non-standard sampling rates, I know I can search but I figured there is
probably someone here more knowledgeable than I on the subject who can
suggest something excellent.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Fri Dec 07, 2007 12:35 pm Post subject: system.audio |
|
Hello
there. I was playing with bsnes configuration and found system.audio
variable. I tried to use either numeric or textual representation of
audio hardware interface, but bsnes still uses the default one for
audio playback. Is it possible to change audio interface to use with
this variable or it has some different meaning? I'm working under
Windows XP, and there are 2 sound cards installed. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Dec 07, 2007 6:36 pm Post subject: |
|
Quote: |
I figured I'd say something anyway in case you wanted to experiment with it to see if they fixed anything worthwhile |
The only thing worthwhile would be to test PGO with it. And to get
that, you need the pro or enterprise / team suite /
phrase-of-the-month-at-Microsoft edition. I really don't want to
"purchase" another 2GB worth of software that most likely won't work
... however, if anyone here "bought" one of these editions and wants to
try PGO, please let me know if it works. And feel free to post the
binary here for testing if you want. If it does work, I'll switch
compilers again.
Quote: |
I was wondering if anyone knew where online to shop for nice sound cards that support non-standard sampling rates |
The only sound "card" I've ever seen choke on non-standard rates was
AC'97. Whenever I set a sampling rate of something > 48khz, the
emulator would just deadlock. Even Intel HD Audio works just fine, so
it was most likely a driver problem.
Still, any card will always resample to a single native format to allow
mixing. Maybe not if I wrote my own kernel mixer thing, but I wouldn't
have a clue how to do that, so ...
Quote: |
Is it possible to change audio interface to use with this variable or it has some different meaning? |
That variable just selects the API to use for playing audio. It can be
"dsound", or "none". If it isn't one of those two, it will default to
DirectSound.
On Linux, it has "ao" and "none", defaults to "ao".
I hope to add more drivers, like OpenAL, OSS, etc.
|
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Fri Dec 07, 2007 9:13 pm Post subject: |
|
byuu wrote: |
Still, any card will always resample to a single native format to allow mixing. |
Not any, but most. 
Quote: |
That
variable just selects the API to use for playing audio. It can be
"dsound", or "none". If it isn't one of those two, it will default to
DirectSound. |
I see now. Any chance there will be some way to choose what sound card to use in the future?
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Dec 07, 2007 10:41 pm Post subject: |
|
Hey byuu,
I started messing around with bsnes 26 release and discovered a problem
with the 2x, 3x, 4x, etc scaling features. They are not properly
scaling on a one-to-one ratio. You can tell plain as day when playing
games with segmented life bars like Super Castlevania 4. On 1x scaling,
the life bar units are perfectly segmented and evenly spaced. When you
try a scaling option like 2x, the pixels become warped and the life bar
segments become noticably misshapen. It looks like the math for the
scaling is incorrect.
To make certain of this, I turned off all other hardware and software
filtering options, as well as aspect ratio correction. The pixels
should be perfectly semetrical when using the scaling feature. If need
be, I can link to screenshots to show examples of the problem. Just let
me know. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Dec 07, 2007 11:48 pm Post subject: |
|
burning shadow wrote: |
I see now. Any chance there will be some way to choose what sound card to use in the future? |
start -> settings -> Control Panel -> Sounds and Audio Devices
-> Audio tab -> change primary sound device.
_________________
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.
|
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Sat Dec 08, 2007 1:56 am Post subject: |
|
franpa wrote: |
start -> settings -> Control Panel -> Sounds and Audio Devices -> Audio tab -> change primary sound device. |
Imagine that I don't need to use my HQ sound card as default sound
device. There are lots of reasons. There is an API allowing application
to choose sound device to use and that is what I'm talking about.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Dec 08, 2007 3:45 am Post subject: |
|
burning shadow wrote: |
There are lots of reasons. |
These are a good thing to give when making a request. Also, looking at
most of my programs, it looks like you may have a long and arduous
journey ahead of you.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Dec 08, 2007 4:09 am Post subject: |
|
FitzRoy wrote: |
burning shadow wrote: |
There are lots of reasons. |
These are a good thing to give when making a request. Also, looking at
most of my programs, it looks like you may have a long and arduous
journey ahead of you.
|
These are one of those situations where it is nice to have, but so few
apps+people fall in this category. The only app that I have that even
falls into this catagory is Nestopia.
_________________
FF4 research never ends for me.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Dec 08, 2007 9:19 am Post subject: |
|
pardon me for sounding nooby but what is the benefit?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Dec 08, 2007 10:48 am Post subject: |
|
Does it matter? Let the crybaby have his feature, it can't be more than a few extra lines of code anyway. |
|
|
burning shadow Rookie

Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
|
Posted: Sat Dec 08, 2007 10:58 am Post subject: |
|
Im
not a crybaby. I asked if there is a chance to have such feature. And
it's ok if author just say no. But I hate stupid answers like the one
from franpa. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Dec 08, 2007 11:16 am Post subject: |
|
I know you guys are still busy having a scuffle, but I'm still in the dark here.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Dec 08, 2007 12:10 pm Post subject: |
|
Panzer88 wrote: |
pardon me for sounding nooby but what is the benefit? |
If someone has multiple sound-cards, odds are the cards do different
things and the person will want some programs to use one, and other
programs to use the other. For example, you might have a computer with
on-board consumer-level sound hardware, and a PCI professional
sound-card as well. Any professional audio software probably ought to
talk to the pro hardware, but you might want bsnes to use the built-in
sound instead (say, your pro card is plugged into a DAT recorder
instead of speakers).
I don't know how much of that applies to burning shadow, but it's possible.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Dec 08, 2007 4:20 pm Post subject: |
|
burning shadow wrote: |
Im
not a crybaby. I asked if there is a chance to have such feature. And
it's ok if author just say no. But I hate stupid answers like the one
from franpa. |
Bad choice of words by me. Just that I lost focus while writing, me focusing on the just add it part.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Dec 08, 2007 7:54 pm Post subject: |
|
burning shadow wrote: |
Im
not a crybaby. I asked if there is a chance to have such feature. And
it's ok if author just say no. But I hate stupid answers like the one
from franpa. |
It's franpa. Stupid is to be expected.
I could use the option in DOSBox, on the MIDI side.
It provides internal emulation of the FM synth SoundBlasters and the
Gravis Ultrasound, but not of the Roland stuff, which was the shit back
in the day.
Got an MT32 emulator installed on my system, but there's no way I can
find to tell DOSBox to use it without changing the the system default
from my the standard sample-based MIDI synth provided by my soundcard.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Dec 09, 2007 2:25 am Post subject: |
|
i provided a valid solution to the question o_O
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Dec 09, 2007 3:26 am Post subject: |
|
franpa wrote: |
i provided a valid solution to the question o_O |
you know they wouldn't say it if they didn't love ya 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 09, 2007 4:11 am Post subject: |
|
Quote: |
I see now. Any chance there will be some way to choose what sound card to use in the future? |
I'm sure it's easy to add, but I don't know how off the top of my head.
If someone wants to write the code *, I'll make it a config option for
the DirectSound driver. Something like system.audio_flags =
"soundcard=2". I don't really have the time to read up on this and add
it myself right now, sorry.
(* The Video / Audio / Input device drivers in src/ui are all public
domain, so feel free to post modifications online.)
Quote: |
I
started messing around with bsnes 26 release and discovered a problem
with the 2x, 3x, 4x, etc scaling features. They are not properly
scaling on a one-to-one ratio. |
Did you turn off the linear filtering? Pixel filtering should give you
what you want, and you need the D3D renderer (default, unless you
messed with the config file, that's what's being used.)
Failing that, as a temporary workaround, try setting system.video to
"dd", or failing that, "gdi" if you have the processing power to burn.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sun Dec 09, 2007 4:00 pm Post subject: |
|
Looks
like the D3D render was causing the warped pixels. I set it to dd as
your suggested, and the pixels got corrected. Btw, I was already on
pixel filtering instead of linear.
My question is, why is D3D screwing up the scaling? |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Dec 09, 2007 5:09 pm Post subject: |
|
My
question is: why bother with all the messy 3d stuff when all you wanted
to do was to blit pixels to the screen as fast as possible?
DirectDraw does exactly that, let's you dump pixels on the screen, in
whatever format you want and sometimes with hardware acceleration.
People keep over complicating things, pixels are 2d, no need for any
3d. 3d rendering is not even nearly as fast as 2d rendering, for 2d
images.
Well, in theory. We all know how the system designers keep doing over
complicated driver designs that makes what should been faster slower
than the alternative that in theory should been noticeably slower for
the task. Those people need to be hit with objects. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Dec 09, 2007 5:47 pm Post subject: |
|
henke37 wrote: |
My
question is: why bother with all the messy 3d stuff when all you wanted
to do was to blit pixels to the screen as fast as possible?
DirectDraw does exactly that, let's you dump pixels on the screen, in
whatever format you want and sometimes with hardware acceleration.
People keep over complicating things, pixels are 2d, no need for any
3d. 3d rendering is not even nearly as fast as 2d rendering, for 2d
images.
Well, in theory. We all know how the system designers keep doing over
complicated driver designs that makes what should been faster slower
than the alternative that in theory should been noticeably slower for
the task. Those people need to be hit with objects. |
If only we had some sort of device to propel said objects toward our
adversaries at high speed... ah well, we can always dream.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sun Dec 09, 2007 7:30 pm Post subject: |
|
Quote: |
My
question is: why bother with all the messy 3d stuff when all you wanted
to do was to blit pixels to the screen as fast as possible? |
Because 2D is a subset of 3D, and 3D graphics cards these days have
really fast engines that 2D APIs sometimes don't take the best
advantage of (perhaps because the API makes guarantees that can't be
met when using 3D hardware). I doubt the 2D APIs are going to be around
that much longer, or maintained as well as the 3D ones.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 09, 2007 8:46 pm Post subject: |
|
I
use Direct3D because DirectDraw was discontinued three versions of
DirectX ago. And DirectDraw lacks a lot of important stuff. Most
importantly for bsnes is a pixel scaler ... so when images are resized,
the video card automatically applies a bilinear filter that many people
dislike. Hence, you'll notice that the pixel / linear selection in the
menu does nothing for the DD renderer (I'll make that menu option not
show up with that renderer eventually ...)
I also
like a lot of stuff in D3D in general for other apps (hardware alpha
blending, color diffusion, pseudo-3D effects such as rotation, etc),
and they may also have some benefit in future versions of bsnes, such
as cornered color diffusion to emphasize an emulator pause feature.
As for why the Direct3D renderer is warping the pixels upon scaling ...
I'm really not sure. I'll look around when I get a chance for anything
obvious. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sun Dec 09, 2007 9:12 pm Post subject: |
|
Yeah, some people don't like it, but, w/out that whole Direct Draw filter, games look even worse.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Dec 09, 2007 10:58 pm Post subject: |
|
blargg wrote: |
Because 2D is a subset of 3D... |
I beg to differ. 3D rendering is in my opinion an application that runs
on 2D. In the end, it is a drawn on a bitmap, if the image was a bitmap
to begin with, it is a waste of well, cpu time to go truh the 3D
pipeline for basic pixel coping. And Bitmaps is 2D, even if you don't
like it.
It is sad that people have gone mad with 3D these days. 3D here, 3D
there. 2D is still important. For example, take the games made by the
developer "The Beaumont", pure 2D fun. People still hasn't gotten over
the fact that 2d can be done very well. 3D is cool indeed. But a high
quality game is better. Besides, not every application needs 3D. Go and
explain how MS Word is going to take advantage of 3D, you can't.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Dec 09, 2007 11:56 pm Post subject: |
|
[quote="henke37"]
blargg wrote: |
Because 2D is a subset of 3D... |
I beg to differ. 3D rendering is in my opinion an application that runs
on 2D. In the end, it is a drawn on a bitmap, if the image was a bitmap
to begin with, it is a waste of well, cpu time to go truh the 3D
pipeline for basic pixel coping. And Bitmaps is 2D, even if you don't
like it.
so you like playing bsnes in a tiny 256x224 box on your 1280x960
desktop? if you read what he says then you would know that directdraw
sux at video scaling 
_________________
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.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 10, 2007 12:53 am Post subject: |
|
yeah, sadly it's outdated and D3D is being worked on more.
if you ever get around to getting SFX up and running would there be
benefits there also? (because the chip runs basic 3D effects)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Dec 10, 2007 1:50 am Post subject: |
|
Quote: |
As
for why the Direct3D renderer is warping the pixels upon scaling ...
I'm really not sure. I'll look around when I get a chance for anything
obvious. |
Could be something to do in your vertex handling? I am encountering
similar issues with my work, but that would be the first place to look
(probably something in your SetFVF() function or before you do
DrawPrimative() )
Quote: |
I
also like a lot of stuff in D3D in general for other apps (hardware
alpha blending, color diffusion, pseudo-3D effects such as rotation,
etc), and they may also have some benefit in future versions of bsnes,
such as cornered color diffusion to emphasize an emulator pause feature. |
Also, there is pixel shader capabilities, for stuff like hardware 2xSai
and HQ2x for example, which might be handy for freeing the CPU to do
more work on the emulation threads.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Dec 10, 2007 7:29 am Post subject: |
|
You
are still not giving any real reasons why they should stop supporting
2D. 3D might be able to do more cool tricks, but honestly, isn't they
doing things that a 2D interface could have had too? |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 10, 2007 7:33 am Post subject: |
|
henke37 wrote: |
You
are still not giving any real reasons why they should stop supporting
2D. 3D might be able to do more cool tricks, but honestly, isn't they
doing things that a 2D interface could have had too? |
I could be wrong, but I think the point is that it is no longer being
officially supported in DX, and most gfx cards are designed to work
well with 3D stuff.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Dec 10, 2007 8:00 am Post subject: |
|
henke37 wrote: |
You
are still not giving any real reasons why they should stop supporting
2D. 3D might be able to do more cool tricks, but honestly, isn't they
doing things that a 2D interface could have had too? |
Why differentiate between 2D and 3D? Why not have one single graphics interface that handles both?
As it happens, Direct3D can do that. DirectDraw can't.
Anyways, overhead or not, the "3D" portion of a modern video
accelerator is FAR more optimized than the "2D" side. And thus it runs
faster.
Same reason MS is rolling their GUI over to the 3D side for Vista.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Dec 10, 2007 12:12 pm Post subject: |
|
Quote: |
I beg to differ. 3D rendering is in my opinion an application that runs on 2D. |
Yes, 3D rendering is all about projecting a 3D space onto a 2D surface.
My point was that projecting a 2D space onto a 2D surface needs no
special handling from a 3D engine.
Quote: |
In
the end, it is a drawn on a bitmap, if the image was a bitmap to begin
with, it is a waste of well, cpu time to go truh the 3D pipeline for
basic pixel coping. |
The 3D pipeline doesn't use any more CPU time than a 2D one, since the
graphics card is doing the work. The 3D card has a hardware pipeline
that likely shuts down unused portions (to reduce heat), so it's no
loss to be doing simpler operations that don't involve shading,
perspective transforms, etc. The thing is, you rarely just do basic
pixel copying anyway, unless you want a tiny 256x223 image.
Quote: |
It
is sad that people have gone mad with 3D these days. 3D here, 3D there.
2D is still important. For example, take the games made by the
developer "The Beaumont", pure 2D fun. |
What the heck does this have to do with graphics APIs? A 3D API can do
all a 2D one can do, so it doesn't prevent making a 2D game. Anyway,
once there is only a 3D API, all the 2D uses of it (current GUIs for
example) will make it beneficial for graphics card makers to ensure
that these common 2D operations work efficiently.
In the end, it's just a matter of whether you have two APIs to the 3D
graphics card, or just one. Two APIs where one would be sufficient
means extra work and bugs, and one API getting less attention than the
other. Not worth it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Dec 10, 2007 12:29 pm Post subject: |
|
Correct, it is the gpu time that is wasted, my bad.
And I am generic, DD vs D3D is not the main issue here. The main issue
is that computer screens is 2D. The simplest api, and thereby fastest,
api is in theory a 2D api. This is because the fastest algorithm is the
zero length algorithm. No need to even bother with stuff that is a
waste of time, like converting data formats when you have the right
format.
About 2D not being able to do 3D, that is true. But nothing prevents a
2D api from letting a 3D api be used on certain parts of the screen. At
the same time, it is not impossible for a 3D api to to the same thing,
because this is a cooperative task. The ideal solution is a api that
have both a 3D part and a 2D part.
I also have a great example on something other than emulators that
needs fast 2D apis, Movies. Be it a youtube movie or a dvd movie, both
have 2d pixels that need to be moved to the framebuffer as fast as
possible. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Dec 10, 2007 1:08 pm Post subject: |
|
henke37,
I get the increasing sense that you know just enough to sound like you
know what you're talking about, but you really don't.
Quote: |
The ideal solution is a api that have both a 3D part and a 2D part. |
I believe that blargg just explained to you that this already exists: with Direct3D.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Dec 10, 2007 2:37 pm Post subject: |
|
Quote: |
The main issue is that computer screens is 2D. The simplest api, and thereby fastest, api is in theory a 2D api. |
Yes, for sure.
Quote: |
The ideal solution is a api that have both a 3D part and a 2D part. |
Since 2D is a subset, a 3D API will support 2D without any explicit
support. In other words, you get the 2D API without any extra work.
Internally, the 3D engine can and does optimize for common cases,
including ones where there is no depth to the scene being rendered. In
other words, internally it can detect when the program is using it as a
2D API. The only question is how much overhead this brings as compared
to having a direct 2D API. I imagine the main overhead is in setting
things up; actual repeated copying probably has little overhead in
comparison.
|
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Dec 10, 2007 3:07 pm Post subject: |
|
Jipcy wrote: |
henke37,
I get the increasing sense that you know just enough to sound like you
know what you're talking about, but you really don't. |
He's been taken to task on IRC more often than not, for that very reason alone.
_________________
FF4 research never ends for me.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Dec 10, 2007 3:44 pm Post subject: |
|
Just
an update in that I tried to reproduce the pixel warping by going back
to the d3d renderer and now it displays them correctly. I can't
understand how switching to dd and then back to d3d corrected the
problem.
btw, byuu where is the config file being saved for bsnes26 on my hard drive? I can't find it anywhere. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Dec 10, 2007 3:45 pm Post subject: |
|
henke37:
Have you ever programmed anything at all with a 3D API? I am huge
advocate of 2D graphics, however I use a *3D* API to do them. Why?
Well, it's clearly been explained twice already. 3D APIs simply have
more to offer for 2D development and can actually produce something
with some advanced effects quicker than 2D APIs most of which have been
discontinued by several years now.
I don't think you really know what you're talking about either. It's
the underlying software DRIVER created by the manufacturer that
determines the actual hardware being used on the card for a given task.
The last time I educated myself on video card hardware and driver
design, the pipeline was being used for just about everything. The
cards today feature very little, if any, hardware dedicated to 2D
acceleration. In fact, the driver software translates pure 2D
acceleration commands into equivalent 3D operations.
In fact, this is one reason why there are minor differences in
rendering DirectDraw scenes from video card to video card these days. A
specific example I have read about and tried out is when using
DirectDraw for graphics with Geforce 3 and 4 series GPUs, the
rectangles are not the same. By enlarging the destination rectangle by
one pixel, the driver would translate the operation to a textured quad,
thereby utilizing the hardware for a speed advantage. At standard size,
the accelerated path was not used, presumably replaced with a software
renderer internal to either DirectDraw or the driver. The cards caused
those graphics to be drawn at 2x scale, as its dimensions were rounded
up to the next power of two.
The API has little to nothing to do with 'wasting' anything. The API is
merely an application programming interface by definition. It makes
much more sense to offer an API most closely integrated and matching
the capabilities of the hardware devices it's aimed to run on. 3D API's
such as OpenGL and D3D are structured in a similar manner to the
hardware they run on. They can do both 2D and 3D efficiently. In many
cases when using effects, 3D API's can render 2D *FASTER* than 2D APIs
of yesteryear which need to rely on pure software rendering via the
programmer for advanced effects because they have no provisions for
them.
In fact, depending on what you're doing, 3D API's can blit pixels
faster than 2D APIs. I think you need to go to Google and start reading.
_________________
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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 10, 2007 5:59 pm Post subject: |
|
Ok, henke37, I understand where you're coming from. I really hate that DirectDraw was discontinued, too.
Having to learn how to set up and manipulate various vertex buffers,
transform pixel offsets to and from floating-point coordinates, disable
all the stuff I don't need like fog, lighting, set up 3D raster
operations, prevent Z-depth buffering, etc, etc. was a lot of stuff I
really had zero
interest in learning how to do. I don't care, all I wanted to do was
blit a rectangle onto the screen using hardware to upscale it, because
the RAM -> Video RAM transfer is the slowest part of modern PC
graphics.
However, while you and I would prefer
a simple 2D API (preferably as a wrapper on top of the 3D one, rather
than a dedicated API), the market disagrees. I can see the developer
advantage of not needing to maintain two APIs, and pretty much everyone
and their mother is all about 3D these days, even when it's very
inappropriate to use it (see: Aero interface)
So, regardless of how we feel, DirectDraw was discontinued several
years ago, and complaining here won't get it reinstated. And we'll keep
having the same problem in the future. Everyone who has any say in
this, and most end users, want 3D only, so that's what we have to
support.
Hence, I use D3D because it has features that nobody every bothered to
backport to DDraw, and nobody ever will. It also adds really cool stuff
like pixel shaders that 2D hardware wouldn't be able to do as easily.
Now, as for the overhead -- yes, it is definitely slightly slower to
setup and blit a triangle strip (2x right triangles) to draw an image
than it is even to use the D3D-specific StretchRect function. And in
fact, I use StretchRect when it exists with bsnes, but some cards lack
this API, so I have to use the vertex mode on those cards. Those older
cards are coincidentally the ones that are having problems with the
pixel scaling in bsnes, there's a bug in my code somewhere.
Anyway, the overhead is there, but it's infinitesimal. You have to
remember that 99% of the overhead is on the video card size, which you
may as well use, as it's just sitting there idle if not. You only lose
maybe 1-3fps in bsnes when you don't have StretchRect on the D3D side.
Otherwise, D3D is just as fast as DD. But even if it weren't -- 2fps
really isn't anything to lose too much sleep over. And with all the
newfound power you can gain for free because you're doing everything in 3D, it's worth it.
3D can also greatly enhance 2D games, but the market has pretty much
moved to killing off 2D (a travesty in itself). But if you look at the
newest 2D software, they perform awesome battle spell effects and such
using the 3D stuff. And those old mode 7 maps like in FFIV's airship?
They look a lot better using native 3D, and are vastly easier to pull
off.
So yeah, we can hate 3D all we want, but we either deal with it and
learn the new APIs, or we get stuck in the past and eventually burned
when the APIs are completely deprecated. Take for example what happened
to people relying on VESA2 and raw SoundBlaster APIs for DOS and
refusing to move to Windows.
Quote: |
Could be something to do in your vertex handling? |
Yes, this is most likely where the bug is at. I'm not too stellar at
working with these just yet ... and if you're off even a little, your
pixels end up getting bilinear filter resized, which is certainly
what's happening here.
I'll see if I can fix it, if not, could I bug you for some assistance? :)
Quote: |
Also,
there is pixel shader capabilities, for stuff like hardware 2xSai and
HQ2x for example, which might be handy for freeing the CPU to do more
work on the emulation threads. |
Good point, yes. I wish I knew how to do that. And I wish even more
that blargg had his NTSC filter written in PS for D3D and OGL ... then
I could remove all of my software filters and go with these :)
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Dec 10, 2007 6:50 pm Post subject: |
|
I've updated my directx drivers, which fixed my problem of not being able to properly switch back to d3d within bsnes.
Here's a picture of the scaling mismatch in d3d compared to how it
should look. On the left is d3d and the right is how it should look
when accurately scaled. (scaling at 4x, cropped image of the
castlevania 4 life bar):
 |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Dec 10, 2007 8:28 pm Post subject: |
|
Quote: |
I'll see if I can fix it, if not, could I bug you for some assistance?  |
Sure, when my new dev system is up and running, and if you can't find the issue, I'll take a look for you 
Quote: |
Good
point, yes. I wish I knew how to do that. And I wish even more that
blargg had his NTSC filter written in PS for D3D and OGL ... then I
could remove all of my software filters and go with these  |
Actually, gulikosa, guest(r) and mtrooper
have already ported those scaling algorithms to HLSL pixel shaders. The
shader parsing code is in a C++ class, if you want to add it. And yeah,
I agree with you about blargg having his NTSC filter as a pixel shader.
Though, I do know some extremely talented folks that might know how to
pull off such a thing..
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Dec 10, 2007 10:32 pm Post subject: |
|
I
could probably port it to a shader, if it's within the limits of the
OGL2 shading language (no pointers or dynamically filled arrays, and a
limited amount of conditionals ... not to say it might not be possible
to get around using some or all of them if they are used in the C++
version, but it raises the issue of speed as well) |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Dec 10, 2007 11:23 pm Post subject: |
|
Quote: |
I
could probably port it to a shader, if it's within the limits of the
OGL2 shading language (no pointers or dynamically filled arrays, and a
limited amount of conditionals ... not to say it might not be possible
to get around using some or all of them if they are used in the C++
version, but it raises the issue of speed as well) |
Hmmm, well possibly the main snag will be the convolution filter blargg
used for the kernels. The instruction length shouldnt be a issue, if it
is written to Shader Model 2.0 or 3.0 specs. I might email Mitja Gros
to see if he knows how to best tackle this, or Humus to see if he can
write a GLSL version.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Dec 10, 2007 11:55 pm Post subject: |
|
I
might have a look at bsnes' implementation of the filter if I have time
... have an exam coming up though. Instruction length shouldn't be a
problem, I believe ARB assembly specifies a mininum required maximum
length of 2000 instructions - the number of temporaries shouldn't be a
problem either unless the filter samples a great number of pixels. In
my experience speed is the greatest issue; if you're working with
conditionals, make them as unnested and disjunct as possible.. but
whatever you do they're likely to be the bottleneck. Unfortunately,
making do without pointers often introduces more conditionals ... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 11, 2007 1:15 am Post subject: |
|
I
posted a news update on my page regarding libco v0.10a. In short,
vastheman ported it to OS X PowerPC 32-bit and 64-bit. However, he's
only able to test the 32-bit version himself.
I
also applied fixes sent to me by Lucas for the x86 32-bit and 64-bit
versions on OS X. Again, I'm unable to test these changes.
If anyone has OS X and can test any or all of these, please please do.
I do not have detailed compile instructions, though.
I also still need someone to test libco_win on 64-bit Windows, and some
recent changes should ideally be tested on libco_x86_64 + Linux (but
I'm very confident this one will still work.)
So if anyone here can build any of these, please do and let me know the
results. It'll be very much appreciated. Unfortunately, I don't know
the command-line stuff necessary to compile these as I lack said OSes,
but I assume anyone who's ever used yasm/nasm and gas shouldn't have
any problems.
Each verification will mean one more target that bsnes can support :) |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Dec 11, 2007 7:12 am Post subject: |
|
byuu wrote: |
So
yeah, we can hate 3D all we want, but we either deal with it and learn
the new APIs, or we get stuck in the past and eventually burned when
the APIs are completely deprecated. Take for example what happened to
people relying on VESA2 and raw SoundBlaster APIs for DOS and refusing
to move to Windows. |
Stupid reality.
But I do recognize that using the GPU has it's benefits. Not like my
old 120 MHz had any issues running the graphical filters, but free*
resources is fine by me to use.
*Might not be real in all computers, due to sucky drivers forcing D3D
to do the job on the CPU. Also, it increases the energy consumption of
the GPU, possibly reducing the battery time on laptops.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue Dec 11, 2007 9:09 am Post subject: |
|
byuu wrote: |
If anyone has OS X and can test any or all of these, please please do. I do not have detailed compile instructions, though. |
Changes required to get ppc and ppc64 targets compiling on OS X 10.4.11
(I have no idea if this is the Right Way to do things, but I don't know
any better, and it works for me):
Code: |
diff --git a/libco-old/libco.h b/libco/libco.h
index 20433de..dda3d24 100755
--- a/libco-old/libco.h
+++ b/libco/libco.h
@@ -8,6 +8,8 @@
#ifndef LIBCO_H
#define LIBCO_H
+extern "C" {
+
/*****
* cothread_t is a handle to a thread.
* a value of zero indicates that the cothread is invalid
@@ -48,4 +50,6 @@ void co_delete(cothread_t cothread);
*****/
void co_switch(cothread_t cothread);
+}
+
#endif //ifndef LIBCO_H
diff --git a/dev/null b/libco/test/cc_ppc.sh
new file mode 100755
index 0000000..8f6e4c5
--- /dev/null
+++ b/libco/test/cc_ppc.sh
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+as -arch ppc -force_cpusubtype_ALL -o libco_ppc.o ../libco_ppc.asm
+g++ -DPPC -c test_timing.cpp
+g++ test_timing.o libco_ppc.o -o test_timing
diff --git a/dev/null b/libco/test/cc_ppc64.sh
new file mode 100755
index 0000000..0635896
--- /dev/null
+++ b/libco/test/cc_ppc64.sh
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+as -arch ppc64 -force_cpusubtype_ALL -o libco_ppc.o ../libco_ppc64.asm
+g++ -DPPC -arch ppc64 -c test_timing.cpp
+g++ -arch ppc64 test_timing.o libco_ppc.o -o test_timing
diff --git a/libco-old/test/test.h b/libco/test/test.h
index 70eba77..6a2bf7a 100755
--- a/libco-old/test/test.h
+++ b/libco/test/test.h
@@ -15,4 +15,6 @@
#include "../libco_ucontext.h"
#elif defined(WIN)
#include "../libco_win.h"
+#elif defined(PPC)
+ #include "../libco.h"
#endif
|
Everybody loves screenshots:
Code: |
[st@Churchy]: ~/Downloads/libco/test% ./cc_ppc.sh && ./test_timing
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 100
235 clocks / 50,000,000 subroutine calls (50000000 iterations)
753 clocks / 100,000,000 co_switch calls (50000000 iterations)
co_switch skew = 3.204255x
done
[st@Churchy]: ~/Downloads/libco/test% ./cc_ppc64.sh && ./test_timing
context-switching timing test
application must be compiled with optimizations disabled for this to work
clocks per second = 100
159 clocks / 50,000,000 subroutine calls (50000000 iterations)
679 clocks / 100,000,000 co_switch calls (50000000 iterations)
co_switch skew = 4.270440x
done |
byuu wrote: |
Each verification will mean one more target that bsnes can support :) |
Because I can't wait to get 20fps on my G5. ;)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 11, 2007 5:14 pm Post subject: |
|
Wow, that is awesome! Only ~3.2x and ~4.2x skew! So it'll be even faster ...
The only reason I can imagine it being so much faster, despite being
~5-10x bigger code-wise, is if the PowerPC chips are just much less
pipelined and don't get absolutely massacred when you change the stack
pointer like with x86 chips. Man, almost makes me with I had a G5
myself.
And as for 20fps, nah ... you'll probably get fullspeed with a
frameskip of 1. Not like that's anything to brag about. If I ever get
IRQs range tested again, you should easily manage 60fps.
I'm really impressed, vastheman managed to get his port working
perfectly on his first try, despite not having a 64-bit PowerPC
processor. My AMD64 port never worked until I had a 64-bit OS to test
on myself.
I wonder how hard it'll be to port PPC64 to the PS3 ...
I'll update the archive shortly with your compilation steps. Thanks a lot for testing! |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Dec 11, 2007 6:53 pm Post subject: |
|
a lack of CISC to RISC decoding in PPC chips helps...
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Dec 11, 2007 10:34 pm Post subject: |
|
funkyass wrote: |
a lack of CISC to RISC decoding in PPC chips helps... |
You forgot the CISC to VLIW decoding, too.
AMD and Intel's chips both employ a CISC ISA with a pretty dynamic
microarchitecture that can't really be said to be RISC, CISC, or VLIW,
but incorporates aspects of each.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 12, 2007 6:26 am Post subject: |
|
Ok,
Lucas Newman verified the x86 and x86-64 versions work on OS X. And
with Thristian's ppc + ppc64 verifications, that means they're all
working.
This should make a bsnes port to OS X possible now. It'll just require GTK+ for the time being.
I posted libco v0.11 with some source cleanup and new documentation on
how to compile things, if anyone is interested.
In other news, I wrote a libc FILE wrapper. On Windows, using fgetc()
to read a 32MB is very slow compared to using fread() to read in the
entire file at once. But reading large files eats up too much RAM.
Buffering chunks is the way to go, but that's annoying to have to do
all of the time. Linux buffers in the background. Very nice of it, but
I need something portable.
So, my wrapper buffers 4k chunks at a time.
On Windows, it's ~3x slower than a 32MB fread(), and ~6x faster than fgetc() * 32M.
On Linux, both my wrapper and fgetc() * 32M are ~3x slower than a 32MB fread().
And the good news is that it never needs more than 4k RAM. It'll only
really suffer when you try accessing files via for(;;) { seek(rand());
poke(); } -- but who does that? :P
But I'm kind of sketchy with this sort of thing, I often mix up >
and >=, etc etc. If it's not a bother, would anyone mind looking
over the wrapper for any mistakes? It's very tiny, and all the magic is
in two functions: buffer_sync() and buffer_flush().
It's available here: http://byuu.cinnamonpirate.com/temp/bfile.h
Note that I don't follow libc behavior on reads / writes past the end
of the file, because I don't particularly like it.
If everything's good, I'll be using it for UPS patching and my cross-assembler. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Dec 12, 2007 12:47 pm Post subject: |
|
byuu wrote: |
Ok,
Lucas Newman verified the x86 and x86-64 versions work on OS X. And
with Thristian's ppc + ppc64 verifications, that means they're all
working.
This should make a bsnes port to OS X possible now. It'll just require GTK+ for the time being. |
I'm interested in trying to compile it, if only to see if it's
possible. Does bsnes' build system support static-linking? Otherwise it
would be rather difficult to create a redistributable binary...
although maybe nobody particularly cares.
byuu wrote: |
In
other news, I wrote a libc FILE wrapper. On Windows, using fgetc() to
read a 32MB is very slow compared to using fread() to read in the
entire file at once. But reading large files eats up too much RAM. |
Even my aged 1.6GHz G5 has 1.5GB of RAM; I'm sure any machine capable
of running bsnes would be new enough to have at more than 512MB. Does
allocating 32MB of RAM really hurt that much?
byuu wrote: |
Buffering
chunks is the way to go, but that's annoying to have to do all of the
time. Linux buffers in the background. Very nice of it, but I need
something portable. |
For Linux, the best way to read a large file is surely mmap() - pages
of data on disk are magically loaded into your address-space as needed,
without all that copying of data through the kernel and libc. I've
heard that on Win32, CreateFileMapping() is an acceptable substitute. Would that serve your needs?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 12, 2007 7:56 pm Post subject: |
|
Quote: |
I'm
interested in trying to compile it, if only to see if it's possible.
Does bsnes' build system support static-linking? Otherwise it would be
rather difficult to create a redistributable binary... although maybe
nobody particularly cares. |
Certainly worth a try ... if for no more than to verify the PPC libco ports work in a full-sized program.
You'll want to set uiVideo to VideoGTK(), uiAudio to Audio() and
uiInput to Input(). Meaning you'll have no sound or input ... though I
do have AudioAO(), I believe you or someone else said it wouldn't
handle 32khz output.
As for static linking ... I never specifically added support for
anything like that. It should work, though. Why did you want to
statically link? None of bsnes' code is under the GPL.
Quote: |
Does allocating 32MB of RAM really hurt that much? |
Well, that was just one example. It's supposed to be arbitrary.
Meaning, someone could patch a 4GB DVD ISO if they wanted to. That'd be
stupid of course, you'd want to patch each individual file.
Plus, it actually would be more painful in an assembler's case, if you
only want to patch ~3,000 bytes and you have to read in a 32MB file and
write it all out again. In that case, only buffering ~4k at a time
would save a lot of time.
I notice on VBA, on an older PIV, there's noticeable freezing when loading a 32MB image.
Quote: |
Would that serve your needs? |
Well, it doesn't seem portable enough. I'd like it to work on any
system that has libc ... but it does look really interesting. Maybe I
can just rig a backend so that if it's Linux, use mmap(), Windows use
CreateFileMapping() and everything else use fopen(). But that seems
like too much hassle.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Dec 12, 2007 9:28 pm Post subject: |
|
byuu wrote: |
As
for static linking ... I never specifically added support for anything
like that. It should work, though. Why did you want to statically link?
None of bsnes' code is under the GPL. |
...oh, you're right, I forgot about that. Never mind, then.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Dec 14, 2007 9:52 am Post subject: |
|
Well,
good news. Can't say much more at the moment, but I'm now certain the
PowerPC port of libco works perfectly well. Awesome stuff, Vas.
In other news, I finally took a stab at importing all of my new library
stuff into bsnes, inlcuding miu. I have it ~90% working now.
The big problem at the moment is that I have to expose the X11 Window
handle in order to draw video inside of a window, but I hate to expose
that inside miu. No choice, really ... so at the moment, I just spawned
a new window.
The Xv and XInput drivers were crushing the global namespace (X11
typedef's Window in the global namespace ... asshats), so I decided to
go ahead and rework the video / audio / input stuff into its own
library. I'm calling that vai. Just an obvious acronym -- it works.
Only ~40 million matches on Google, should be easy to get a high
ranking on that.
If miu can be thought of as a lightweight competitor to wxWidgets, then
vai can be thought of as a lightweight competitor to SDL. NIH? What's
that?
Anyway, the idea was to turn each component into a header of basic
functions (video.h, etc), and then headers for public interfaces
(video.xv.h) which derive from the base headers, and then use a pimpl
here so that I can store structs from X11/Win32/etc headers inside the
class objects without the interfaces crushing the namespace again
(without the pimpls, the public interfaces would have no way to
reference, say XShmSegment's struct data, and I don't want those vars
global in the cpp files -- I may want to create multiple objects one
day for these for some reason.)
Lots of fun. Modified the Makefile a lot to build all of these. The
main UI component can now be built without #including a single thing
related to Windows, X11 or GTK+. Cool stuff. I don't like the way the
Makefile spits out the full line of -DPLATFORM_BLA ... `pkg-config junk
...` stuff, when only a few files actually need it, but I guess it's
not hurting anything either, and I love those implicit Makefile rules.
Such a timesaver.
So, here's what I have so far:
Code: |
http://byuu.cinnamonpirate.com/images/bsnes_20071214.png |
The Linux video is "sort of" working, audio is fine, and input works.
Nearly all of the GUI works, except the cheat code editor, and input
config won't read any keypresses. Windows is completely and utterly
broken in a million ways. Missing miu functionality, missing miu
events, missing ALL vai drivers, etc etc.
I'm really loving the change in miu to use function callbacks with the
functor library. It makes the code a lot cleaner to have separate
functions for each event, rather than one gigantic function that has
lots of conditionals to determine exactly what happened. Lots less code
indenting, too. And I get to do a lot of cool new tricks like "hijack"
(copy, override, restore when finished) event handler functions and
stuff like that. And no need to ever have to subclass anything just to
get access to events.
Well, since the Win port is shattered, looks like it will be quite a
while before I can work on that D3D filtering issue. Remind me when the
Win port is working again if I forget to look at that, please.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Dec 14, 2007 12:42 pm Post subject: |
|
yes!!! byuu i can run megaman x2 and donkey kong country games with no lag or crackly audio now 
i replaced my video card and power supply.
_________________
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. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 14, 2007 2:28 pm Post subject: |
|
Well i guess thats good news and bad news, good thing i just installed gentoo on my ibook G3 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Dec 15, 2007 9:47 am Post subject: |
|
Windows port is partially revived.
Code: |
http://byuu.cinnamonpirate.com/images/bsnes_20071215.png |
Lots of fun issues abound. SetParent() is so unbelievably broken on
Windows it's not even funny. If you create a listbox, it caches
hwndParent internally upon the WM_CREATE message. So what happens when
you reparent the listbox? Yep, all the notification messages continue
to go to the old window.
I want miu to be OO, which means I need to be able to make controls and manipulate them before attaching them to windows. And I also need to be able to freely move controls between windows.
Solution was to simplify every single wndproc down to just one global
wndproc. Rely on GetWindowLongPtr(GWLP_USERDATA) as much as possible,
and keep one global list of all existing widgets so that I can convert
either HWND or LOWORD(wparam) (for menu items / controls) back to
widget objects and call their respective on_event functors.
Only problem now is that this limits the max# of controls to ~64k. Not
really a huge problem, but it's not a nice limit to have nonetheless.
Maybe I should rig in GetParent() somehow to help out. That should give
the real parent HWND, at least.
Let's see ... only audio is working. Still have to rewrite much of D3D,
DDraw, GDI and DInput to get that up. miu/win is missing a few
callbacks still, and checkboxes / radioboxes don't work at all. Have to
redo window positioning, everything goes to the top-left of the screen
by default at the moment.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 16, 2007 10:08 am Post subject: |
|
Alright, it's been a full month now since the last private WIP.
I have Direct3D, DirectSound and DirectInput all working on the Windows
port now; and Xv, GTK+ Video, libao and XInput working on the Linux
port, so now's a good time for a beta.
Note that countless things are broken, still.
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- Windows always appear at 0,0 instead of centered
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like GTK+
without needing multiple threads ...
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't set focus to the listbox on show just yet
Any bugs outside of this that seem serious, please tell me about. Otherwise, I'm working on the rest still :/ |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Dec 16, 2007 11:32 am Post subject: |
|
byuu wrote: |
Code: |
http://byuu.cinnamonpirate.com/images/bsnes_20071215.png |
|
hey byuu, how did you get a image to appear and act like a webpage? url redirection?
_________________
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.
|
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Dec 16, 2007 12:36 pm Post subject: |
|
The http rfc have no concept of file extensions, the server is free to send any reply it feels like. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Sun Dec 16, 2007 3:31 pm Post subject: |
|
obviously byuu wrote that as an HTML web page, then dropped the htm (or html) extension and replaced that with a png
_________________

<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


Joined: 27 Jul 2004
Posts: 4328
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 16, 2007 9:30 pm Post subject: |
|
Sorry, I deleted 1214 and 1215 because they're really big. I figured most had a chance to see it already.
As for the 404 -- rather than give a custom 404, my site just redirects
to the front page for now. I really should fix that. If you need more
details than that on why the site acts as it does, PM me. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Dec 16, 2007 9:56 pm Post subject: |
|
yea it started to become somewhat obvious after i made my initial post questioning it.
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 18, 2007 12:29 pm Post subject: |
|
New
WIP. Much, much closer to release quality. Linux port (probably) won't
compile at the moment due to minor changes to miu and vai. I left the
console enabled for this WIP.
Bugs fixed:
- Windows always appear at 0,0 instead of centered
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't set focus to the listbox on show just yet
- bsnes will no longer crash when you try and load a GZ / ZIP / JMA
file with the support not built in (it obviously won't play the games
either) [Richard Bannister]
Bugs remaining:
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like GTK+
without needing multiple threads ...
New bugs:
- Esc doesn't toggle menu yet
- F11 fullscreen doesn't center, and window background is gray. This
will be tricky, as I only have one RegisterClass() in miu, but you can
only have one HBRUSH per class. Hopefully there's a window message I
can hijack to add back window.set_background_color().
- miu/Win enable() / disable() doesn't work -- input config dropdowns active, despite them not working yet
Other than that, any new bug reports would be appreciated. I hope to
have v027 out by Sunday, but I may not make it in time. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Dec 18, 2007 9:04 pm Post subject: |
|
Quote: |
D3D still blurring image, haven't looked at it yet |
Since I can get BSNES to compile so easily, I'll have a snoop around
your D3D code and see if you made any mistakes
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Dec 19, 2007 1:40 am Post subject: |
|
So far all I could find:
Infinite sound stutter on menu access has returned
Logging audio doesn't appear to work
Either the font or font size is different than before in the config
All on XP, of course |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 19, 2007 8:26 am Post subject: |
|
> Since I can get BSNES to compile so easily, I'll have a snoop around your D3D code and see if you made any mistakes
Cool, thank you! You'll find all of it located in
ui/vai/video/video.direct3d.(cpp,h) -- no rogue bits hiding in the UI,
the PPU, etc. If anything, I'm guessing it might be something like
using gdi32 to get the window size as 0,0,320,240 and D3D wanting a
rect of 0,0,319,239 or something like that.
> Infinite sound stutter on menu access has returned
Yeah, I hate adding WM_ENTERMENULOOP to miu. It's never used by Linux/GTK+.
> Logging audio doesn't appear to work
Good catch, I didn't know about that.
> Either the font or font size is different than before in the config
I bumped it up to Tahoma 9 so that I could use the same button and
textbox heights as GTK+ to simplify the GUI code. I know it looks a
little worse, but I hope it isn't too bad. When I get the font setting
code ready, I'll add a configuration option to change the font
program-wide. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 19, 2007 2:39 pm Post subject: |
|
Another WIP. This one builds on Windows and Linux, and the binary has the terminal window disabled.
Bugs fixed:
- Added WM_ENTERMENULOOP message. Fixes audio looping for the 37th time since I started on bsnes.
- Esc toggles menu properly
- F11 fullscreen centers, but only to the screen, not to the window
(meaning when the menubar is visible, it isn't really centered) -- this
is because GTK+ does not return the correct widget size after calling
gtk_window_fullscreen() for up to ~200ms after processing all messages
via gtk_main_iteration_do(), and thus I can't make a window.get_size()
function. I really hope GetSystemMetrics(SM_CXSCREEN) and
gdk_screen_width() only return the width of the active monitor, and not
both for multi-monitor setups
- Background of main window is black on Linux only. Only one background
brush per class for Windows. It may end up staying gray on Windows for
the next release ...
- miu/Win enable/disable works. Even for menu items now, so I can
disable features that aren't supported by certain drivers now.
Bugs remaining:
- bsnes/Win background in fullscreen mode is gray -- quite ugly
- D3D still blurring images even with perfect multiplier
- cheat code editor still doesn't load .cht files on ROM load
New bugs:
- bsnes/Win menubar is ultrafucked in fullscreen mode if you toggle it on and off with esc. I have no
idea what the hell is up with that. Code to show and hide the menu is
identical to libui/bsnes v026. Not sure I can fix this one. Basically,
when the menu gets toggled back on, clicking it does nothing, and if
you press alt, it will pop up the menu, but it will be below
the visible menubar, so you end up seeing two of them. And you can only
access the new menubar via keyboard. Weird stuff ... could use some
help here. Anyone ever seen or heard of anything like this before?
- I still need to work on that makefile cp+chmod -> install thing for belegdol, I think ... |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Dec 19, 2007 3:17 pm Post subject: |
|
byuu wrote: |
- bsnes/Win menubar is ultrafucked in fullscreen mode if you toggle it on and off with esc. I have no
idea what the hell is up with that. Code to show and hide the menu is
identical to libui/bsnes v026. Not sure I can fix this one. Basically,
when the menu gets toggled back on, clicking it does nothing, and if
you press alt, it will pop up the menu, but it will be below
the visible menubar, so you end up seeing two of them. And you can only
access the new menubar via keyboard. Weird stuff ... could use some
help here. Anyone ever seen or heard of anything like this before? |
I don't know if it's at all related, but when working with Java I had
some problems with the menu becoming unresponsive/being drawn wrong.
Edit: checked what I actually did, solution was to request a repaint
for onMenuSelected and onMenuDeselected.. perhaps in this case events
for the menubar itself are also involved, though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 20, 2007 10:43 am Post subject: |
|
Another WIP. Consider this one v0.027 RC1.
Bugs fixed:
- cheat code editor works once again -- cart/ was not loading or saving
the files, and memory/ was not reading from it. Yeah, it was completely
broken in v0.026
- miu/Win supports window.set_background_color(). The trick was to
capture WM_ERASEBKGND and use FillRect to draw the background myself.
- miu/Win menubar toggle in fullscreen mode works as expected now for
me. Testing would be appreciated. A total shot in the dark, I tried
using SWP_FRAMECHANGED when resizing the windows, and it worked. It
seems to be an issue due to having two windows that are both set to use
the same menu (I have a hidden window I use for resize-purposes only,
because AdjustWindowRect doesn't work right on multi-line menus, but
the resize window is never visible.) I'm not sure exactly why
SWP_FRAMECHANGED fixed the problem, or why it wasn't needed in libui,
but it works, so I'll take it.
- make install target uses "install" rather than cp+chmod, but belegdol
unfortunately removed his makefile patch, and I don't recall where
$(DESTDIR) and $(PREFIX) are supposed to go, so those aren't in there
yet ... belegdol, could you please repost that? You're of course free
to change my makefile with your packages as always in case it gets
missed before v027.
Bugs remaining:
- D3D renderer is still acting weird. If you start at 256x224 window
size, then the point video filter never works. If you resize to a
larger window and back to 256x224, the video image is linear filtered
no matter what. I tried to fix this tonight, but I had no luck. I'm
really not sure what's wrong, I don't think it's ever really worked
right. Should I fallback on the DDraw renderer for the next release? It
lacks the point filter mode (DDraw lacks an API to control mag
filtering), but that's it. Also, mudlord, PM me if I haven't given you
my WIP URL and you wanted to look at the latest stuff. I can never
remember who I gave the link to or not.
- system.video / audio / input are not checked, so you get the compiled
defaults only. All vai drivers have now been ported, however.
I changed the cheat code format. It is now:
code = status, "description" \r\n
Or for an example:
7e1234:56 = enabled, "Infinite Lives"
7e1235:67 = disabled, "Infinite Health"
A little easier to read. But maybe still not perfect. I'd really like
to unify the .cht file format with other SNES emu devs ... I don't want
to use a binary file format like ZSNES and SNES9x does.
I tried testing log audio data -- it seems to be working for me both on
Windows and Linux. FitzRoy, maybe the file isn't going to the folder
you are expecting? Or maybe I fixed it and didn't realize it? Hmm ...
Anything else I'm forgetting before a new release? Anyone see any new / show stopping bugs? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Dec 20, 2007 12:12 pm Post subject: |
|
Quote: |
I
tried testing log audio data -- it seems to be working for me both on
Windows and Linux. FitzRoy, maybe the file isn't going to the folder
you are expecting? Or maybe I fixed it and didn't realize it? Hmm ... |
My fault. For some reason I was expecting it to generate in my bsnes
folder, but it's generating in my roms folder.
By the way, is it normal for a black border to be generated on the
outer two pixels in hq2x mode? I don't normally use this mode, so I
never noticed it before, but it doesn't appear to be happening in zsnes.
Shame about the point filter not working right, I prefer the non-blurry look.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 20, 2007 12:25 pm Post subject: |
|
Quote: |
My fault. For some reason I was expecting it to generate in my bsnes folder, but it's generating in my roms folder. |
I could make it go to the save path, too. I don't want it in the path
of bsnes, because that causes problems on Linux. You don't want WAVs
being written to /usr/bin ...
Quote: |
By
the way, is it normal for a black border to be generated on the outer
two pixels in hq2x mode? I don't normally use this mode, so I never
noticed it before, but it doesn't appear to be happening in zsnes. |
It's a speed hack. I know it's ugly, but you can't read the pixel to
the left of X0, or above Y0, etc. Rather than modify my x,y loop to
test for if(x==0||x==width-1||y==0||y==height-1) or separate out the
logic to have one pixel write inside the Y loop at the top and bottom,
and one line write above and below the Y loop itself (ugly), I just
skipped those pixels entirely. I actually have that test in the scale2x
one too, which is kind of silly.
Quote: |
Shame about the point filter not working right, I prefer the non-blurry look. |
Well, it works ... mostly. Just start the emulator with the pixel
filter enabled, and preferably at the size you want to keep the
emulator window at. It's really only sketchy when you keep resizing the
window and swapping between the filter modes.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Dec 20, 2007 12:36 pm Post subject: |
|
byuu wrote: |
Quote: |
By
the way, is it normal for a black border to be generated on the outer
two pixels in hq2x mode? I don't normally use this mode, so I never
noticed it before, but it doesn't appear to be happening in zsnes. |
It's a speed hack. I know it's ugly, but you can't read the pixel to
the left of X0, or above Y0, etc. Rather than modify my x,y loop to
test for if(x==0||x==width-1||y==0||y==height-1) or separate out the
logic to have one pixel write inside the Y loop at the top and bottom,
and one line write above and below the Y loop itself (ugly), I just
skipped those pixels entirely. I actually have that test in the scale2x
one too, which is kind of silly.
|
Or you could create a larger image, fill the borders with the outermost
lines/columns of the source image, let the filter operate on it and
then transfer the main area to the gfx card.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Dec 20, 2007 2:23 pm Post subject: |
|
byuu wrote: |
-
make install target uses "install" rather than cp+chmod, but belegdol
unfortunately removed his makefile patch, and I don't recall where
$(DESTDIR) and $(PREFIX) are supposed to go, so those aren't in there
yet ... belegdol, could you please repost that? You're of course free
to change my makefile with your packages as always in case it gets
missed before v027. |
As I use his nice patch for the PKGBUILD I'm maintaining for Arch Linux I got it mirrored; http://aur.archlinux.org/packages/bsnes/bsnes/bsnes-makefilefix.patch.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Thu Dec 20, 2007 3:14 pm Post subject: |
|
I
didn't get any audio output with the latest WIP. I have ALSA configured
properly and everything has worked before. I tested with bsnes version
0.026 and the audio was just fine. I did also a fresh install of bsnes,
but the problem remained.
It seems that bsnes
isn't connected to ALSA at all, usually I get lots of ALSA underrruns
notices when I load a rom, but with the latest WIP this doesn't happen. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 20, 2007 11:44 pm Post subject: |
|
Turambar, go to ui/miu/ui.cpp, you'll see a line such as uiAudio = new Audio();
Change that to uiAudio = new AudioAO(); and audio should work again.
AO is the default, but in my WIPs I don't check system.audio yet, and I
usually prefer audio off so I can run at max speed (libao always
blocks.)
Hmm, as for ALSA underrun, you might try setting speed regulation to
slow. You'll get 45fps, but at least the audio won't crackle.
Thanks, [vEX], I'll try and get the changes in faster this time.
creaothceann, thought about that, just seemed hacky. I'll probably go
back and fix all that eventually when I rewrite snes/. As it stands,
none of the filters other than blargg's even support hires games yet. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Dec 21, 2007 4:19 am Post subject: |
|
i
got a 2nd stick of memory and moved them both to new slots in dual
channel mode and now i get zero audio static in your program unless i
either click on the menu bar/title bar or do something intense like
opening firefox or a webpage. (scrolling through a webpage is fine)
but it is a massive improvement over before. also, is it possible to
pause emulation while editing bsnes advanced configuration? really
annoying listening to audio stutter when you scroll around in there.
your emulator still uses 2 cores and now uses both much more
erratically then it did before i moved my memory around. the usage on
both cores is dependent on what song is being played... various songs
have massively different loads in Donkey Kong Country 2.
_________________
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. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Fri Dec 21, 2007 5:09 pm Post subject: |
|
byuu wrote: |
Thanks, [vEX], I'll try and get the changes in faster this time. |
While you're at it, I think you should kill of your "configure" since
it's just a bogus file. If there is no configure script then it's more
confusing to have the file there than not. People assume all
applications uses automake should simple learn and read the docs.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Dec 21, 2007 5:52 pm Post subject: |
|
Over at mess.org, the mame/mess devs are discussing a universal XML system for all data types (rom, hdd, optical and so forth)
The system looks really simple and allows for and even helps out things
like translations and hacks (in the case of mame this system will allow
people to use hacks and such so that misfitmame will no longer be
needed)
As some of the readers here do actually write and maintain emulators it
might be a good idea to take a look at it and maybe give some input on
what you think the bare bones basic xml should look like, because if
more emulators use the system the biggers the chance it will become the
standard one day
Link: http://www.bannister.org/forums/ubbthreads.php?ubb=postlist&Board=1&page=1 |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sat Dec 22, 2007 11:08 am Post subject: |
|
Yay, new version!
Looking through the Makefile I have some questions, why do you install
the files with mode 775? 755 should be enough.
The help message needs to be adjusted a bit, the example uses the old platform target:
"Example: make PLATFORM=x-gcc-lui GZIP_SUPPORT=true"
Target x-gcc-lui is no more, it should say x-gcc-x86 instead.
You're installing the icon to /usr/share/icons, though I'm no expert on
these things, shouldn't it be put in /usr/share/pixmaps? Every
application I've seen installing single icons put them there and they
can then be used in a .desktop file.
And now for completely different issue, what is required for JMA
support to be compiled? It doesn't seem to compile for me, seems like
it's not compatible with GCC 4.2.2 (this is just a small snippet, it
outputs lots of stuff like this):
Code: |
stream.tcc:289: error: expected unqualified-id before '(' token
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/fstream.tcc:
In member function 'virtual std::streamsize
std::basic_filebuf<_CharT, _Traits>::xsputn(const _CharT*,
std::streamsize)':
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/fstream.tcc:612:
error: expected unqualified-id before '(' token
In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/vector:71,
from reader/jma/jma.h:23,
from reader/jmareader.h:3,
from reader/jmareader.cpp:3,
from reader/reader.cpp:9:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_bvector.h:
In member function 'void std::vector<bool,
_Alloc>::_M_fill_insert(std::_Bit_iterator, size_t, bool)':
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_bvector.h:916:
error: expected unqualified-id before '(' token
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_bvector.h:
In member function 'void std::vector<bool,
_Alloc>::_M_insert_range(std::_Bit_iterator, _ForwardIterator,
_ForwardIterator, std::forward_iterator_tag)':
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_bvector.h:961:
error: expected unqualified-id before '(' token
In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/vector:74,
from reader/jma/jma.h:23,
from reader/jmareader.h:3,
from reader/jmareader.cpp:3,
from reader/reader.cpp:9:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/vector.tcc:
In member function 'void std::vector<_Tp,
_Alloc>::_M_fill_insert(__gnu_cxx::__normal_iterator<typename
std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer,
std::vector<_Tp, _Alloc> >, size_t, const _Tp&)':
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/vector.tcc:350:
error: expected unqualified-id before '(' token
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/vector.tcc:
In member function 'void std::vector<_Tp,
_Alloc>::_M_range_insert(__gnu_cxx::__normal_iterator<typename
std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer,
std::vector<_Tp, _Alloc> >, _ForwardIterator,
_ForwardIterator, std::forward_iterator_tag)':
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/vector.tcc:453:
error: expected unqualified-id before '(' token
make: *** [reader.o] Error 1 |
Earlier in the output it also complains about macros min and max getting the wrong number of parameters:
Code: |
g++
-O3 -fomit-frame-pointer -DPLATFORM_X -DCOMPILER_GCC -DPROCESSOR_X86_64
-DUI_MIU `pkg-config --cflags gtk+-2.0` -DJMA_SUPPORT -c
reader/reader.cpp -o reader.o In file included from
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/char_traits.h:46,
from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/string:47,
from reader/jma/jma.h:21,
from reader/jmareader.h:3,
from reader/jmareader.cpp:3,
from reader/reader.cpp:9:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_algobase.h:226:56:
error: macro "min" passed 3 arguments, but takes just 2
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/bits/stl_algobase.h:246:56:
error: macro "max" passed 3 arguments, but takes just 2
In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/memory:60,
from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/string:48,
from reader/jma/jma.h:21,
from reader/jmareader.h:3,
from reader/jmareader.cpp:3,
from reader/reader.cpp:9:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/limits:290:22:
error: macro "min" requires 2 arguments, but only 1 given
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/limits:292:22:
error: macro "max" requires 2 arguments, but only 1 given
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/limits:320:23:
error: macro "min" requires 2 arguments, but only 1 given
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/limits:322:23:
error: macro "max" requires 2 arguments, but only 1 given
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../include/c++/4.2.2/limits:374:23:
error: macro "min" requires 2 arguments, but only 1 given |
But the worst part seems to be if I just make a regular binary without
any extra flags (make PLATFORM=x-gcc-x86-64) the GUI won't work at all.
It gets drawn correctly, but it doesn't respond and if I switch
desktops back and forth the menu is all grey (the items aren't visible
anymore).

_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Dec 22, 2007 11:32 am Post subject: |
|
> why do you install the files with mode 775?
I don't see a reason to deny users from modifying the file if they want
to. Maybe I just don't follow typical Unix security mentality, but I
like being able to modify files without `su root'.
I do need to make the icon 664 or whatever though. No need to execute that.
> Target x-gcc-lui is no more, it should say x-gcc-x86 instead.
Oops! Fixed, thank you.
> You're installing the icon to /usr/share/icons, though I'm no
expert on these things, shouldn't it be put in /usr/share/pixmaps?
Honestly, I don't know. I just stuck it in icons because it was more
descriptive of what I wanted. The icon also wasn't a pixmap but a PNG :/
If you're sure it should be in pixmaps, I'll move it.
> And now for completely different issue, what is required for JMA
support to be compiled? It doesn't seem to compile for me, seems like
it's not compatible with GCC 4.2.2
Yeah, I'm not sure if it is compatible or not. Most likely, it's
because of my code. I define my own min/max, and it appears MinGW and
GCC implement their own min/max as templates that take 1-3+ arguments.
What. The. Fuck ...
Anyway, I #define min and max because C++ templates are incapable of
properly implementing generics. I could go into a big discussion about
that, but you may try looking at the ~30-page article on Dr. Dobbs that
tries to implement min/max. Myself, I'd rather just be careful about
how I use the #define than mess with that stuff.
I do need to fix JMA, so I guess I'll have to deal with it and add
using std::min; using std::max; to that file instead. I'll be pissed if
I have to cast all kinds of "can't compare signed and unsigned integer"
errors, though.
> But the worst part seems to be if I just make a regular binary
without any extra flags (make PLATFORM=x-gcc-x86-64) the GUI won't work
at all. It gets drawn correctly, but it doesn't respond and if I switch
desktops back and forth the menu is all grey (the items aren't visible
anymore).
... that's definitely the worst part, alright. I'm sorry, I really
don't know what to tell you. I've tested it on two separate Linux
machines and I have no such issue. Are you able to build a 32-bit
binary and run that? Maybe it's a problem with 32-bit -> 64-bit. I
use uintptr_t a lot more ... but I can't see how that would be a
problem :/
I could certainly use a hand fixing this one, as I lack a 64-bit Linux install :/ |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sat Dec 22, 2007 1:11 pm Post subject: |
|
byuu wrote: |
> why do you install the files with mode 775?
I don't see a reason to deny users from modifying the file if they want
to. Maybe I just don't follow typical Unix security mentality, but I
like being able to modify files without `su root'.
I do need to make the icon 664 or whatever though. No need to execute that. |
I see, I'll just change it in the PKGBUILD so for Arch it will be 755 and 644 then.
byuu wrote: |
>
You're installing the icon to /usr/share/icons, though I'm no expert on
these things, shouldn't it be put in /usr/share/pixmaps?
Honestly, I don't know. I just stuck it in icons because it was more
descriptive of what I wanted. The icon also wasn't a pixmap but a PNG :/
If you're sure it should be in pixmaps, I'll move it. |
Like I said, I don't know either, but that's where all icons seems to
end up in Arch. I use Openbox so I don't use anything that uses the
.desktop-files (I have made one for the Arch Linux package of bsnes) so
I can't say if it works or not. But since all other packages put icons
there I'm going put it there too. The Desktop Entry Specification has the following link to how the "icon=" part works: http://standards.freedesktop.org/icon-theme-spec/latest/ar01s05.html. That doesn't really say much since you have to know which directory it starts in.
byuu wrote: |
>
And now for completely different issue, what is required for JMA
support to be compiled? It doesn't seem to compile for me, seems like
it's not compatible with GCC 4.2.2
Yeah, I'm
not sure if it is compatible or not. Most likely, it's because of my
code. I define my own min/max, and it appears MinGW and GCC implement
their own min/max as templates that take 1-3+ arguments. What. The.
Fuck ...
Anyway, I #define min and max because C++ templates are incapable of
properly implementing generics. I could go into a big discussion about
that, but you may try looking at the ~30-page article on Dr. Dobbs that
tries to implement min/max. Myself, I'd rather just be careful about
how I use the #define than mess with that stuff.
I do need to fix JMA, so I guess I'll have to deal with it and add
using std::min; using std::max; to that file instead. I'll be pissed if
I have to cast all kinds of "can't compare signed and unsigned integer"
errors, though. |
Go blame the GCC devs I guess, at least ZIP/GZIP support compiles and presumably works.
byuu wrote: |
>
But the worst part seems to be if I just make a regular binary without
any extra flags (make PLATFORM=x-gcc-x86-64) the GUI won't work at all.
It gets drawn correctly, but it doesn't respond and if I switch
desktops back and forth the menu is all grey (the items aren't visible
anymore).
... that's definitely the worst
part, alright. I'm sorry, I really don't know what to tell you. I've
tested it on two separate Linux machines and I have no such issue. Are
you able to build a 32-bit binary and run that? Maybe it's a problem
with 32-bit -> 64-bit. I use uintptr_t a lot more ... but I can't
see how that would be a problem :/
I could certainly use a hand fixing this one, as I lack a 64-bit Linux install :/ |
As I'm not really a C/C++ coder I can't provide much help, but I'll be
happy to help and track the problem. I tried building the 32-bit one
under a 32-bit chroot and that works fine, so it's something to do with
the 64-bit specific code.
You should know that in Arch Linux the 64-bit "version" doesn't have
any 32-bit libraries in it, it's a clean 64-bit environment, not like
say Ubuntu that from what I've read is multilib. I'm not sure if it
makes a difference for bsnes, but I thought I mention it right away
incase it can help you locate any entry point for finding the 'cause.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Dec 22, 2007 1:27 pm Post subject: |
|
byuu wrote: |
> why do you install the files with mode 775?
I don't see a reason to deny users from modifying the file if they want
to. Maybe I just don't follow typical Unix security mentality, but I
like being able to modify files without `su root'. |
Whether users can edit the files depends entirely on what group you set
on the file when you install it. Generally binaries installed
system-wide are set 755 so that one user can't mess things up for other
users.
Quote: |
>
You're installing the icon to /usr/share/icons, though I'm no expert on
these things, shouldn't it be put in /usr/share/pixmaps?
Honestly, I don't know. I just stuck it in icons because it was more
descriptive of what I wanted. The icon also wasn't a pixmap but a PNG :/
If you're sure it should be in pixmaps, I'll move it.
|
From the freedesktop.org icon theme spec:
Quote: |
By
default, apps should look in $HOME/.icons (for backwards
compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in
that order). [...] In order to have a place for third party
applications to install their icons there should always exist a theme
called "hicolor" |
Reading through the spec, the proper place for a bsnes icon would seem
to be /usr/share/pixmaps/hicolor/48x48/bsnes.png (assuming that
bsnes.png actually is 48x48). Then the bsnes.desktop file can just say
"Icon=bsnes.png" and GNOME or KDE should be able to find it.
|
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sat Dec 22, 2007 1:30 pm Post subject: |
|
Now
this is interesting, all of sudden it's working again. Which means
something on my system didn't want it to work in the first place. Yet I
tried several clean builds (even removed the files and unpacked it all
over) with the same result. Also removed the configuration file to make
sure it wasn't causing any problems.
I'm going to go ahead and blame.. umm... the evil santa.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Dec 22, 2007 1:41 pm Post subject: |
|
> Go blame the GCC devs I guess, at least ZIP/GZIP support compiles and presumably works.
Yes, it works. I've tested ZIP files on Windows and Linux.
> I see, I'll just change it in the PKGBUILD so for Arch it will be 755 and 644 then.
Alright, I've done the same. 755 binary, 644 data.
> Reading through the spec, the proper place for a bsnes icon would
seem to be /usr/share/pixmaps/hicolor/48x48/bsnes.png (assuming that
bsnes.png actually is 48x48).
Well, I don't know if you want to call Ubuntu broken or not, but I lack
a hicolor folder. There are, however, hundreds of icons in
/usr/share/pixmaps. And there is a /usr/local/share/icons folder. There
is no such /usr/local/share/pixmaps folder, either.
Therefore, since it works for everyone including Ubuntu users, I'm
leaving it at /usr/local/share/icons for now. Feel free to change it
for your distro if it's appropriate.
> Now this is interesting, all of sudden it's working again.
Wow, that's weird. Yeah, Linux really is too temperamental for my
tastes. audacious only lets me edit ID3 tags half the time, Firefox
segfaults five seconds after every other time I open it, system tray
icons don't show up one in ten times an app goes there, apps frequently
just vanish -- no crash error, nothing, just silent segfaults ... I
really miss FreeBSD. None of this stuff ever happened there.
Glad it's working for you, at least. I'll wait and see if other 64-bit users have the problem or not, I guess.
I believe it should be possible to build bsnes on 32-bit and 64-bit PPC
Linux systems now, too. But the ABI may be different from Apple's.
---
As far as future plans, I'd like to take somewhat of a small break to
work on some other projects. After that, I really want to get back into
the core emulation stuff again, so I'll probably target the SFX some
more. No idea how the hell I'm going to emulate that thing's 256-byte
cache. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Dec 22, 2007 3:28 pm Post subject: |
|
/false alarm on d3d issue. I didn't realize I had .026 set to "dd"
Thanks for the new release. I do have a PS3 now. Haven't installed
linux on it yet, but I'm guessing you would need a PS3 yourself to
figure out how to support it. If it's possible to do it just by me
running your tests, though, I'd be glad to help. |
|
bobbens New Member
Joined: 22 Dec 2007
Posts: 2
|
Posted: Sat Dec 22, 2007 5:08 pm Post subject: |
|
Is there no joystick support for bsnes under linux?
Great emulator for us 64 bit people though.
EDIT:
more observations.
Was trying to figure out how to hack joystick support in (I've always
used SDL for joystick input), but my C++ isn't up to the task (I'm a C
guy). Was going to try to use joy2key or some other joystick to
keyboard translation tool, but the way you handle input doesn't allow
that, since it seems you XQueryKeymap, which bypasses X events
generated, so those tools don't work. Since I haven't done much
low-level X stuff, i don't really know where to start fixing that (I
also use SDL for input generally).
Another issue I've been noticing is after using gtk windows and such,
there will be a big black box appearing on the screen where the game is
displayed. If I then click on a menu again it'll go away, which is sort
of weird, but it's not very important as long as it works.
And finally, if you get joystick support in for linux, I'd love to see
a feature like zsnes' "set all input" which prompts you one-by-one what
you want each key to be.
Overall I'm surprised how well bsnes reacts and works, really looking
forward to getting it all working better. I love the concept too, since
I tend to value precision over hacks  |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Dec 23, 2007 3:37 am Post subject: |
|
how
much work would it take to implement soft patching, hopefully soft
patching with the ability to patch multiple patches on one rom.
just out of curiosity, this is a feature I use a whole lot. of course
it holds no priority, just curious if it would be a big project or a
small one.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 4:20 am Post subject: |
|
Quote: |
If it's possible to do it just by me running your tests, though, I'd be glad to help. |
We should start by trying to build libco. The PPC64 version might work.
If we can do that, then bsnes will run fine on the PS3. In fact, I'm
90% sure it'll get full speed, too. I get a cool 60-70fps minimum on an
old $30 Pentium IV 3.2GHz. Given the x86 nature of ZSNES, and the lack
of an official GUI for SNES9x/Linux ... it might actually be a platform where bsnes gets good overall reception :D
Quote: |
Is there no joystick support for bsnes under linux? |
Unfortunately, no. If I knew how to add it, I certainly would. I need
something portable that'll work on BSD and Unix, too. SDL is a bad
idea. It's keyboard input won't work on any window that it doesn't
create itself, and bsnes needs to create its own window to attach a
menubar to, plus another window to assign keys to.
Glad to hear it's working okay on your 64-bit box.
Quote: |
since it seems you XQueryKeymap, which bypasses X events generated, so those tools don't work |
XQueryKeymap was the only way I could find to capture keypresses that
didn't involve having to include X11-specific header files to bind X
events and get key notifications.
I could also fall back on miu/GTK+'s on_keydown event, but that doesn't
poll the joypad, so that would ruin Windows DirectInput support.
Ideally, I want the keyboard / joypad polling in a separate object file
that only communicates with the UI through a fixed interface -- meaning
the input object file can't create its own windows.
Quote: |
Another
issue I've been noticing is after using gtk windows and such, there
will be a big black box appearing on the screen where the game is
displayed. If I then click on a menu again it'll go away, which is sort
of weird, but it's not very important as long as it works. |
Wow, that's a weird one. I played to level 2 in Dracula X (love the BGM
there), and didn't notice this at all. Anyone else seeing this?
Only thing I can think of is that for some reason, the gtk_drawing_area
control is redrawing on top of the video, and Xv uses a different
colorkey than 0. I did add sinamas' auto Xv color key, but maybe it's
not working right?
Still hoping to get an OpenGL renderer in there, too.
Quote: |
Overall
I'm surprised how well bsnes reacts and works, really looking forward
to getting it all working better. I love the concept too, since I tend
to value precision over hacks |
Thanks :)
Yeah, I really do like it myself. On the three systems I have (of
seven) that can get fullspeed, it's really nice. If only it were
possible for me to implement savestates and vsync + smooth audio at the
same time, it'd easily be my first choice for playing games on as well.
Quote: |
how
much work would it take to implement soft patching, hopefully soft
patching with the ability to patch multiple patches on one rom. |
A moderate amount, nothing too complex. I intend to support NINJA3 /
UPS, but not IPS. IPS has the problem that you never know whether or
not the patch wants a ROM with or without a header. NINJA3 and UPS
won't have these problems.
It's just ... work on those patching formats has been ... glacial, at best.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Dec 23, 2007 4:45 am Post subject: |
|
that's
great news, well I wish you luck with it, and people should start
spreading the word as most stuff is distributed as ips right now. I'm
sure people wouldn't mind providing those versions along with their ips
patches as long as it didn't require them too much extra work.
also, because of your recent work, does this mean the debugger is coming back to bsnes?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 6:42 am Post subject: |
|
Added a statusbar to miu + bsnes, and a message window to the Linux port (works on WIndows as well.)

Show FPS is now Show statusbar, and is self explanatory. The
statusbar's main advantage is being able to show messages and the
framerate in fullscreen mode. I'll also have it indicate when emulation
is paused and such in the future. Maybe even put the name of the game
down there, who knows.
In fact, perhaps it'll be best to add an advanced config option and let
the user output whatever info they want there as a formatted string.
Something like "%n : %f / %s fps" n = name of ROM, f = current
framerate, s = standard framerate for current region, etc. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sun Dec 23, 2007 8:27 am Post subject: |
|
byuu wrote: |
The
statusbar's main advantage is being able to show messages and the
framerate in fullscreen mode. I'll also have it indicate when emulation
is paused and such in the future. Maybe even put the name of the game
down there, who knows.
In fact, perhaps
it'll be best to add an advanced config option and let the user output
whatever info they want there as a formatted string.
Something like "%n : %f / %s fps" n = name of ROM, f = current
framerate, s = standard framerate for current region, etc. |
Very sweet.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Dec 23, 2007 9:03 am Post subject: |
|
byuu wrote: |
A moderate amount, nothing too complex. I intend to support NINJA3 /
UPS, but not IPS. IPS has the problem that you never know whether or
not the patch wants a ROM with or without a header. NINJA3 and UPS
won't have these problems.
It's just ... work on those patching formats has been ... glacial, at best. |
Good to hear, i plan to convert all the patches i can find to the ninja format some day......
|
|
bobbens New Member
Joined: 22 Dec 2007
Posts: 2
|
Posted: Sun Dec 23, 2007 11:00 am Post subject: |
|
byuu wrote: |
Quote: |
Is there no joystick support for bsnes under linux? |
Unfortunately, no. If I knew how to add it, I certainly would. I need
something portable that'll work on BSD and Unix, too. SDL is a bad
idea. It's keyboard input won't work on any window that it doesn't
create itself, and bsnes needs to create its own window to attach a
menubar to, plus another window to assign keys to.
|
What about using libjsw ( http://wolfpack.twu.net/libjsw/
)? I have it lying around here for some reason or another and it does
seem to work. For joystick input (on linux at least) you could actually
use SDL (which would be a bit overkill), since it probably just opens
/dev/input/js# and plays around with that, which is window independent.
byuu wrote: |
Quote: |
since it seems you XQueryKeymap, which bypasses X events generated, so those tools don't work |
XQueryKeymap was the only way I could find to capture keypresses that
didn't involve having to include X11-specific header files to bind X
events and get key notifications.
I could also fall back on miu/GTK+'s on_keydown event, but that doesn't
poll the joypad, so that would ruin Windows DirectInput support.
|
Yes, but the XQueryKeymap isn't the "proper" waying of doing it. It
would be like scanning the entire keyboard status in SDL instead of
polling for events. Maybe you could try checking on what other people
use for X input. I'd love to help, but I don't do X stuff so low level,
and frankly, C++ gives me a headache .
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 3:25 pm Post subject: |
|
I
posted a new private WIP that adds the new statusbar. But much more
importantly, thanks to Nach, the Linux port now has an OSS driver.
It's current set as the default. You can get ao again by setting system.audio to, yep, you guessed it, "ao".
Would some Linux users mind giving it a spin? For me, it appears to be
blocking and causing serious video lag (xv [XV_SYNC_TO_VBLANK=0] or
GTK+ video, 60hz monitor, speed regulation = normal). Not happening for
Nach ... it's quite possible the problem is just on my system.
The complete and utter lack of perceived latency lag though, makes this
sound a million times better than the ao driver. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 23, 2007 5:12 pm Post subject: |
|
I
played with the OSS code a bit more, I now have it perfect for me, no
latency, no lag, no crackles or pops, smooth the whole time, and a
constant 60/60.
The status bar I think should go
away when the menu is hidden. The status bar works for me in 64 bit
mode, but is completely black the entire time in 32 bit mode.
As for the CDX hearts problem, in some areas I always see it, in some areas it's not there.

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sun Dec 23, 2007 6:57 pm Post subject: |
|
Quote: |
Still hoping to get an OpenGL renderer in there, too. |
Hheheeheh I was thinking of writing a OGL renderer for BSNES..OGL is more my strength than D3D.
Gonna check out that D3D prob more in detail, as I looked over your
code, and it looks okay-ish. Might need more investigation though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 7:27 pm Post subject: |
|
Quote: |
The
status bar I think should go away when the menu is hidden. The status
bar works for me in 64 bit mode, but is completely black the entire
time in 32 bit mode. |
I can make esc toggle the statusbar as well, I suppose. I kept it on
because I figured the "show statusbar" option would be a little weird
with that there. But then, if the menu is hidden too, it doesn't matter
that there's a show statusbar menu option, right?
As for why you can't see it in 32-bit mode, again, not sure. Seems like
lots of people are having issues with miu/GTK+ :(
I don't know ... I don't have any issues on either of my Linux boxen.
Both are 32-bit. If you have any luck tracking down the cause, please
let me know. I don't really have a way to fix bugs I can't reproduce.
Quote: |
As for the CDX hearts problem, in some areas I always see it, in some areas it's not there. |
Not sure. I guess we might as well test it on a copier. I can always
see the bar, but I notice it starts blinking once I have ten or more
hearts. That's really weird.
Quote: |
Hheheeheh Wink I was thinking of writing a OGL renderer for BSNES..OGL is more my strength than D3D.
Gonna check out that D3D prob more in detail, as I looked over your
code, and it looks okay-ish. Might need more investigation though. |
OGL, neeeeat :D
Well, please just focus on whatever you're comfortable with. If it
helps encouragement any, the code really isn't bsnes-specific. I'm
intentionally isolating all of vai from bsnes, so that if one were to
add support for vai, one would have a full range of cross-platform APIs
for video+audio+input.
This could end up as a very real competitor to the likes of SDL one day :)
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 23, 2007 7:46 pm Post subject: |
|
byuu:
I ported the OpenAL code you gave me to the new system, and got it all building and everything.
Problem is, I don't hear anything.
Let me know what you want to do.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 8:00 pm Post subject: |
|
Nach,
I cannot reproduce your Dracula X bug. I played through to level 2
three times in bsnes, and once in both ZSNES and SNES9x.

The heart counter does
flicker constantly, however. It happens as soon as you get >10
hearts and you have a weapon equipped. No idea why, but I bet the
original game does it, too.
Every emulator acts
the same, except once in ZSNES the hearts were completely invisible and
never flickered. Maybe this is what you triggered in bsnes somehow. I
wonder if that's a real game bug or an emulation bug ...
Quote: |
I ported the OpenAL code you gave me to the new system, and got it all building and everything.
Problem is, I don't hear anything.
Let me know what you want to do. |
I looked at the official dev manual for OpenAL ... it's over four hundred pages long ...
I asked wertigon recently via PM if he had any updates, I'll have to
wait on his reply, because I have absolutely no idea how to fix it :/
Thank you for trying, though. I can't say it enough -- all your help with bsnes is greatly appreciated.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 23, 2007 8:08 pm Post subject: |
|
byuu wrote: |
The heart counter does
flicker constantly, however. It happens as soon as you get >10
hearts and you have a weapon equipped. No idea why, but I bet the
original game does it, too.
Every emulator
acts the same, except once in ZSNES the hearts were completely
invisible and never flickered. Maybe this is what you triggered in
bsnes somehow. I wonder if that's a real game bug or an emulation bug
...
|
May I venture a guess that for some reason on my system bsnes is only
updating the screen every other frame or something, only on the frame
that the flickering is currently in the state of off, so I end up not
seeing anything?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sun Dec 23, 2007 10:09 pm Post subject: |
|
Quote: |
OGL, neeeeat 
Well, please just focus on whatever you're comfortable with. If it
helps encouragement any, the code really isn't bsnes-specific. I'm
intentionally isolating all of vai from bsnes, so that if one were to
add support for vai, one would have a full range of cross-platform APIs
for video+audio+input.
This could end up as a very real competitor to the likes of SDL one day  |
Currently, my init code for the OpenGL PFD is this:
Code: |
PIXELFORMATDESCRIPTOR pfd;
// get the device context (DC)
hDC = GetDC( GetForegroundWindow() );
// set the pixel format for the DC
ZeroMemory( &pfd, sizeof( pfd ) );
pfd.nSize = sizeof( pfd );
pfd.nVersion = 1;
pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
pfd.iPixelType = PFD_TYPE_RGBA;
pfd.cColorBits = 24;
pfd.cDepthBits = 16;
pfd.iLayerType = PFD_MAIN_PLANE;
SetPixelFormat (GetDC (GetForegroundWindow()), ChoosePixelFormat (
GetDC (GetForegroundWindow()), &pfd), &pfd);
wglMakeCurrent (GetDC (GetForegroundWindow()), wglCreateContext(GetDC (GetForegroundWindow()) ) ); |
Since your code doesn't seem to have a handle for the main window, I
had to use the hack as above. Thats mainly the only Windows specific
code in that renderer I am working on.
The other stuff got ported fine, I just need to work out a way to do
texturing from that pointer you use for image data in lock(), vertex
handling, and some other minor things like that.
Last edited by mudlord on Sun Dec 23, 2007 10:18 pm; edited 3 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Dec 23, 2007 10:09 pm Post subject: |
|
Nach wrote: |
byuu wrote: |
The heart counter does
flicker constantly, however. It happens as soon as you get >10
hearts and you have a weapon equipped. No idea why, but I bet the
original game does it, too.
Every
emulator acts the same, except once in ZSNES the hearts were completely
invisible and never flickered. Maybe this is what you triggered in
bsnes somehow. I wonder if that's a real game bug or an emulation bug
...
|
May I venture a guess that for some reason on my system bsnes is only
updating the screen every other frame or something, only on the frame
that the flickering is currently in the state of off, so I end up not
seeing anything?
|
If it were doing that, wouldn't you have noticeable lag in the game similar to frameskipping being on?
I don't have the problem either, but it seems that the number is indeed
turned off every other frame, because when I turn frameskipping to "1"
at the right moment, the frame that shows it ends up being perfectly
skipped.
I think the game is kind of goofy in that flickering is normally used
to warn you that you're low on an item, not the other way around.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Dec 23, 2007 10:31 pm Post subject: |
|
Is
there currently a way to set the variables in the advanced
configuration ("video aspect x/y", "video multiplier" and such) as to
basically stretch the video to fullscreen? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 23, 2007 10:48 pm Post subject: |
|
Deathlike,
I see, thanks. Wasn't aware this game had item crash. Still, the
blinking is definitely backwards to conventional logic. Blinking should
be for low hearts :/
Quote: |
Since your code doesn't seem to have a handle for the main window, I had to use the hack as above. |
Wow, thanks a ton for working on this :)
In bsnes, the main window has a nested sub window. It's a fully fledged
custom type (has its own class), not a CommonControl or something. The
reason for this is so that I can center the sub window in fullscreen,
and the blitters will auto scale to fill that whole view window. They
extract the size from GetClientRect, of course.
The handle to this sub window is passed through
uiVideo->set(Video::Handle, window_main.view.handle()) -- that's a
standard HWND by the time it reaches your Win32-specific code. It's
just passed as a uintptr_t to support any possible operating systems in
the future. So long as you #ifdef using it, you'll be fine.
However, if you really need the main window handle anyway (I can't
imagine why), you can get that from window_main.handle(). I can add a
message such as Video::WindowHandle to send this.
Quote: |
Is
there currently a way to set the variables in the advanced
configuration ("video aspect x/y", "video multiplier" and such) as to
basically stretch the video to fullscreen? |
Sorry, but not really. For most video modes, you can get really really
close, but it won't fully stretch. I try and keep the height an even
multiple scaler, as it results in much less blocky video, and more
importantly, it makes scanlines possible -- if I ever add those back
again.
If you can find a video mode that's 4:3 and a multiple of 224, you can
pull it off, but the video won't show up until the menubar is hidden,
which would be pretty annoying.
The main reason I haven't added an option to do this anyway is because
a) GTK+ doesn't report the realtime values of widget width/height to
know how to fullsize the view window, and b) monitors are moving away
from 4:3 to 16:10 and 16:9. That would kill the SNES aspect completely
...
Better scaling options are needed though, you're right.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 23, 2007 11:00 pm Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
byuu wrote: |
The heart counter does
flicker constantly, however. It happens as soon as you get >10
hearts and you have a weapon equipped. No idea why, but I bet the
original game does it, too.
Every emulator acts the same, except once in ZSNES the hearts were
completely invisible and never flickered. Maybe this is what you
triggered in bsnes somehow. I wonder if that's a real game bug or an
emulation bug ...
|
May I venture a guess that for some reason on my system bsnes is only
updating the screen every other frame or something, only on the frame
that the flickering is currently in the state of off, so I end up not
seeing anything?
|
If it were doing that, wouldn't you have noticeable lag in the game similar to frameskipping being on?
|
Yeah good point. It's running really smooth for me now though.
_________________
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 Dec 23, 2007 11:01 pm Post subject: |
|
Quote: |
monitors are moving away from 4:3 to 16:10 and 16:9. That would kill the SNES aspect completely... |
Probably the best reason not to care. Stretch-to-fit on widescreen
would be completely distorted. So you're going to have to deal with
empty black space at some point. I don't personally find it that
distracting. In fact, I wish more 1366x768 HDTVs would support 1:1 with
borders for 1280x720 material because it would give better video
quality (course, it should have been the latter in the first place).
These resolution standards with LCDs always confuse me.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 24, 2007 12:33 am Post subject: |
|
how
about a fullscreen mode that doesn't stretch the actual game video. you
could still have 1x 2x 3x 4x 5x etc. sizes but within a black border
etc.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Dec 24, 2007 12:52 am Post subject: |
|
byuu wrote: |
Deathlike,
I see, thanks. Wasn't aware this game had item crash. Still, the
blinking is definitely backwards to conventional logic. Blinking should
be for low hearts :/ |
The fact I deleted my own statement.. and you still read it is insane.
Anyways, AFAIK, the hearts blinking is intentional to denote being able
to use the special attack (the heavy heart consuming version of it
anyways).
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 24, 2007 1:11 am Post subject: |
|
Quote: |
how
about a fullscreen mode that doesn't stretch the actual game video. you
could still have 1x 2x 3x 4x 5x etc. sizes but within a black border
etc. |
... isn't that what I already have?
Quote: |
The fact I deleted my own statement.. and you still read it is insane. |
=) (I read your statement earlier, I was just too tired to respond right then.)
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 24, 2007 2:16 am Post subject: |
|
Greets byuu!
I'm pleased to see such a great software. Keep up the good work. I'm
somewhat experienced with sound engines but unfortunately for windows
only.
Bsnes's sound engine is not good designed while keeping Vista in mind.
I made complete Bsnes OpenAL backend on weekends, and don't want to
feel myself some kind of greedy man for keeping the code to myself, so
here it is. That is how Open Software works - you share the code and me
share the code too.. It can have some notes to Quake2XP internals, but
well, most of the code like device enumeration and other cool things
was removed or shifted to meet Bsnes specifics.
Here is some notes: this wrapper provides any (up to 20 to be safe)
hardware channels quantity and hardware volume controls, as well. So,
the main particular changes to API i made is:
void AudioAL::volume(uint8 channel, float volume)
void AudioAL::sample(uint8 channel, uint16 l_sample, uint16 r_sample)
Other way it's 100% compatible with what the Bsnes have now. The most compatible way we can use advanced API
is just audio->sample(0, l_sample, r_sample); with no volume controllers but it's not what all the changes about.
Please keep in mind, that volume controller have it's effect on stereo
pair with no balance and unfortunately it's an OpenAL restriction, not
hardware.
So, in my bsnes verion i doubled the channel count this way:
volume(channel*2+0, volume_left); /* left volume 0 to 1.0 */
volume(channel*2+1, volume_right); /* right volume 0 to 1.0 */
sample(channel*2+0, sample_left, 0);
sample(channel*2+1, 0, sample_right);
where channels accessed through (0) to (ALchemy_CHANNELS - 1), where
ALchemy_CHANNELS is some magic number you need, the sum of normal snes
channels, echo's channels, any service channels and so on.
Channel volume is computed like:
SNES_OpenAL volume = SNES_channel_volume * SNES_master_volume / (SNES_channel_volume_MAX*SNES_master_volume_MAX)
This solution is a MUST for Creative sound cards. Kindly this code may
have some disbalancing for all channels as they are independent and can
have different sample start offsets, but it's not like a frame or even
half a frame, if it ever managed to be more then 0 samples. The code
can be tuned up to garantee the channels are running in sync, i just
went the easy way to get the working code early. So this should be not
considered as a bad side effect for beta. Same goes to volume
controllers which in general sense are asinchronous to channels raw
data streams. Hope it is not critical to SNES. Needless to say the
single channel is always in sinc with itself :
But the main bonus gain is the greatly reduced overall latency and
better quality that is, well, no doubt have greater value.
And much, much more important this code can handle floating audio
frequency without triggering the hardware, moreover this frequency can
be independent for all channels!
In teory, OpenAL can take care of special effects like echo for selected channels.
Plus, this code already have Creative X-Fi specific code like X-RAM
extension for better sound card onboard memory management for optimized
RAW streaming.
Sorry for an barbarian english mates, it's not my native. Hope cheerfullnes and kindness that is your native too 
Byuu, check your PM, that's all you need to get OpenAL right now 
Edit: spellcheck
_________________
quake2xp audio engineer |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 24, 2007 3:03 am Post subject: |
|
how
do you enable full screen byuu? I saw several parameters referring to
full screen in the advanced configuration, but couldn't get any of them
to actually switch to full screen. Wouldn't it be easier to just have a
window and fullscreen option in the settings --> video mode menu
that you could toggle back and forth between.
@willow
special sound effects and maximizing on the abilities of certain sound cards sounds great.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Dec 24, 2007 3:30 am Post subject: |
|
You press F11 to switch to fullscreen mode. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Dec 24, 2007 3:40 am Post subject: |
|
And Esc to hide the menu. Both are in the readme.
By the way, byuu, I noticed your license file still says "libui" instead of "miu." |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 24, 2007 3:54 am Post subject: |
|
FirebrandX wrote: |
You press F11 to switch to fullscreen mode. |
ha, I'm a brilliant one it'd still be cool to have an option, but for the record I feel pretty retarded for not thinking of that.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 24, 2007 7:34 am Post subject: |
|
Quote: |
I
made complete Bsnes OpenAL backend on weekends, and don't want to feel
myself some kind of greedy man for keeping the code to myself, so here
it is. |
Wow! First an OSS driver, then help with D3D and OpenGL, and now an
OpenAL driver! It feels like Christmas Day already :D
Thank you so much!
As for the changes, I'll see what I can incorporate into bsnes.
Unfortunately, I can't take advantage of OpenAL's multiple channels.
The SNES has its own algorithm to merge channels, add echo adjustments,
and then add gaussian interpolation. By performing any part of that in
hardware, it could result in non-bit-perfect audio, and it would also
break all other sound drivers. Kind of the same reasons none of us have
OpenGL video acceleration :(
The volume change, as well as the doubling of channels, looks to be
fine, however. I can add that to the other drivers.
Quote: |
Sorry for an barbarian english mates, it's not my native. |
Nah, not at all. Your English is very good, I had no problems understanding it :)
Quote: |
By the way, byuu, I noticed your license file still says "libui" instead of "miu." |
Oops, thanks. I'll make a mental note of that.
Quote: |
it'd still be cool to have an option |
Okay, should I put the option under Settings->Video Mode above the
scalers, or below Video Frameskip in the main menu?
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Dec 24, 2007 7:49 am Post subject: |
|
Quote: |
Wow, thanks a ton for working on this  |
No probs dude. Glad to help 
Quote: |
In bsnes, the main window has a nested sub window. It's a fully fledged
custom type (has its own class), not a CommonControl or something. The
reason for this is so that I can center the sub window in fullscreen,
and the blitters will auto scale to fill that whole view window. They
extract the size from GetClientRect, of course.
The handle to this sub window is passed through
uiVideo->set(Video::Handle, window_main.view.handle()) -- that's a
standard HWND by the time it reaches your Win32-specific code. It's
just passed as a uintptr_t to support any possible operating systems in
the future. So long as you #ifdef using it, you'll be fine.
However, if you really need the main window handle anyway (I can't
imagine why), you can get that from window_main.handle(). I can add a
message such as Video::WindowHandle to send this. |
Well, the only place where I need the handle is with the PFD init and
possibly when killing the OGL rendering and device contexts. The hack I
used is common in all the apps I work on, like in VBA-M, so its proven
to work. But still, its nicer having a handle that makes it work
proper, rather than relying on a Windows API call that tries to get the
handle itself. I did some more work on porting the Direct3D code to
OpenGL, mainly now all that should be left is the rendering code &
vertex/view matrix handling.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 24, 2007 10:49 am Post subject: |
|
byuu wrote: |
Quote: |
it'd still be cool to have an option |
Okay, should I put the option under Settings->Video Mode above the
scalers, or below Video Frameskip in the main menu?
|
either is good, I guess I would put it above the scalers. I know it is
in the readme, and I know it now, but I figure there will be others who
will look for it there. Of course if you wouldn't want it cluttering
your menus that would make sense too.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 24, 2007 11:40 am Post subject: |
|
byuu wrote: |
monitors are moving away from 4:3 to 16:10 and 16:9. That would kill the SNES aspect completely ...
Better scaling options are needed though.
|
Better approach and to make things clear is to keep 2 different aspect
ratios: Snes's one (constant, im sure it is not 1:1) and end user
monitor ratio (variable). Those two ratios can be used in effective
ratio calculation.
byuu wrote: |
As
for the changes, I'll see what I can incorporate into bsnes.
Unfortunately, I can't take advantage of OpenAL's multiple channels.
The SNES has its own algorithm to merge channels, add echo adjustments,
and then add gaussian interpolation. By performing any part of that in
hardware, it could result in non-bit-perfect audio, and it would also
break all other sound drivers. Kind of the same reasons none of us have
OpenGL video acceleration 
|
You can't think the endpoint device is all that snes friendly and have
bit-to-bit performance. At least it lagging and therefore it's not bit
perfect. Plus, OpenAL do not guranteed to work on the 32000hz audio
clock. Generally it will be upmixed to system-wide shared clock. Not
bad thing for a game application. if SNES using different clocks for
selected channels then it would be wize to upsample them to endpoint
sample rate separately.
I have a question. Why some synth tones sound crisp while other samples
is totally blurred. I think this blur is because of that gaussian
interpolation, do the SNES use it for resampling or just for post
processing? I have no regrets to subst some of snes circuitry with X-Fi
powerhorse , well i'm always can do it for myself, thanks to source code .
Of course i will share the good things it they turns out so. It's more
a question of hardware upmixing and hardware post processing, i can't
take SNES optimized output circuitry as a PC optimized, so it can be
improved in some way or another.
I'll try to make the ASIO and WASAPI wrappers too . But tshhh!! It's a secret! 
_________________
quake2xp audio engineer
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Dec 24, 2007 12:01 pm Post subject: |
|
hi end emulation/ improvement is cool, but you're not too into that are you byuu? at least not with bsnes anyways.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 24, 2007 1:03 pm Post subject: |
|
When
i first time saw the audio frequency can float in realtime i can
definetely say byuu is already gone hi end emulation way. In essence of
floating frequency I'd like to say: man, you are joking, right? It
can't be true, stop kidding.. But it seems to be for real, and
therefore it's a serious challenge for PC. PC codec works with fixed
clocks like 32000, 44100, 48000, 88200, 96000 and so on. It can't
handle 32011 or 32323 or whatever else the evil mind can imagine. Once
clock is set it can't be changed without system-wide consequences. You
just can't imagine what the hellish imp your application becomes for OS
point of view. I believe the sound should lag and click in most
mindless style. If it's not, this only shows the foolproof design of
the drivers. But look, it is really a bugs nest !
So, technically wize the samples should be upmixed to system-wide
sample rate. In software or with the help of audio chip DSP. No choice.
_________________
quake2xp audio engineer |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Dec 24, 2007 2:30 pm Post subject: |
|
byuu wrote: |
A
moderate amount, nothing too complex. I intend to support NINJA3 / UPS,
but not IPS. IPS has the problem that you never know whether or not the
patch wants a ROM with or without a header. NINJA3 and UPS won't have
these problems.
It's just ... work on those patching formats has been ... glacial, at best. |
I thought NINJA was dead.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Dec 25, 2007 12:08 am Post subject: |
|
I
got OpenAL support working. It's working wonderfully for me in Linux.
Need other Linux users to test it though, I'm sure byuu will post
another WIP soon enough.
I would like some people to test for Windows though.
system.audio = "oal" for OpenAL, system.audio = "ds" for DirectSound.
http://rapidshare.com/files/78868896/bsnes-oal-test.zip.html
You may need to install this for OpenAL support: http://developer.creative.com/articles/article.asp?cat=1&sbcat=31&top=38&aid=46&file=oalinst.exe
You may also want to try removing the OpenAL32.dll I included to see if
it makes a difference. I'd be interested in knowing if this works for
anyone.
If not, we'll see if compiling using the official MSVC OpenAL SDK makes
a difference, since I used a bit of a hacked up MinGW one.
Also, this build should be slower than usual, don't worry about it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Dec 25, 2007 12:45 am Post subject: |
|
Here's a source WIP: http://rapidshare.com/files/78875298/bsnes_wip.tar.bz2.html
Linux, BSD and whatever users should test it. I tweaked the OSS code,
and it works wonderfully for OSS 4. I also have the OpenAL code in it.
In the config file, set system.audio to oal, oss, or ao.
You may have to edit src/ui/vai/audio/audio.oss.cpp to tell it where the OSS headers are.
By me, I have OSS 3 headers by default in my main include directory,
while my OSS 4 header is in /usr/lib/oss/include/sys/soundcard.h, and
if I use the latter, I get much better audio.
Linux users, please tell me how OSS 3, OSS 4, and OpenAL audio is working for you.
I added cross compile support to the Makefile too.
Byuu: Use this over the Makefile I sent you, as I corrected clean in cross compile mode.
You'll need OpenAL dev headers and libs to compile this. If you're
going to use MSVC, you'll also have to correct the Makefile to link
with OpenAL, as I didn't touch the MSVC compile instructions.
If you're compiling on a UNIX without OSS, such as Mac OS X, you'll
have to remove OSS files from Makefile, and comment out the include of
it in src/ui/miu/ui.cpp, since I didn't feel like adding ifdef's and
what not.
Please let me know how things work out for you.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Dec 25, 2007 2:50 am Post subject: |
|
Nach, your code works quite well...
Did some preliminary tests with Skyblazer (U)(!) and OpenAL works
extremely well. Noticed a teensy bit of crackling on my Intel Pentium
Dual Core E2140, but that could be just a speed issue (gonna upgrade to
at least a Core 2 Duo Allendale CPU next week). Other than that, the
sound works just fine. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Dec 25, 2007 3:07 am Post subject: |
|
Hey thanks for testing. Which OS was it on? And which sound card?
You have to do anything special to get it to work?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Dec 25, 2007 3:21 am Post subject: |
|
OS: Windows XP Home with SP2
Sound card: Realtek HD Audio (integrated)
Didn't have to do anything special at all. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Tue Dec 25, 2007 4:13 am Post subject: |
|
First
thing I noticed was it crashed when I tried changing the speed
regulation while the game was running. It could just be buggy drivers
though and it's not like I change the speed while I'm playing a game.
Other then that it sounds pretty much just like the direct sound to me.
OS: Windows XP Pro SP2
Sound: SB Audigy 2 Value |
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Tue Dec 25, 2007 6:25 am Post subject: |
|
I
installed the OpenAL support package first, then ran bsnes using the
Inindo (U) ROM. I got, at best, very brief bursts of sound, but most of
the time, there was no sound. The sound worked just fine when I set
bsnes to use DirectSound. Whether or not the OpenAL DLL was in the
bsnes directory made no difference. I tried installing the OpenAL SDK
to run the tests that come with it. The tests worked. But still no
sound output from bsnes. My sound device is a Sigmatel STAC 92xx.
I also tried Skyblazer (U), but still nothing. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Dec 25, 2007 6:29 am Post subject: |
|
mudlord wrote: |
Nach, your code works quite well...
Did some preliminary tests with Skyblazer (U)(!) and OpenAL works
extremely well. Noticed a teensy bit of crackling on my Intel Pentium
Dual Core E2140, but that could be just a speed issue (gonna upgrade to
at least a Core 2 Duo Allendale CPU next week). Other than that, the
sound works just fine. |
Dude... No need to spend the extra cash on a CPU. OC the son of a
bitch. I've read reviews on that model, and as it turns out it's not
only a steller OCer, but gets a lot of performance out of OCing too.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 25, 2007 8:23 am Post subject: |
|
Tried
bsnes-oal-win on a P4 Vista box, as well as on a P4 XPSP2 box. Both
crash without installing Creative's OpenAL support. Both run fine, but
produce no sound and fail to throttle speed. Also of course fails on
the older P4 Win2k machine.
Vista has HDA, XP has AC'97. 2k has external USB Creative sound card. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Tue Dec 25, 2007 10:18 am Post subject: |
|
Nach wrote: |
Here's a source WIP: http://rapidshare.com/files/78875298/bsnes_wip.tar.bz2.html
Linux, BSD and whatever users should test it. I tweaked the OSS code,
and it works wonderfully for OSS 4. I also have the OpenAL code in it.
In the config file, set system.audio to oal, oss, or ao.
You may have to edit src/ui/vai/audio/audio.oss.cpp to tell it where the OSS headers are.
By me, I have OSS 3 headers by default in my main include directory,
while my OSS 4 header is in /usr/lib/oss/include/sys/soundcard.h, and
if I use the latter, I get much better audio.
Linux users, please tell me how OSS 3, OSS 4, and OpenAL audio is working for you. |
Not setting the system.audio variable (as it's empty be default) made
OpenAL the default driver. And if OpenAL can't access the device bsnes
will segfault like so:
Code: |
$ ./bsnes
open /dev/[sound/]dsp: Device or resource busy
libOpenAL: failed to open audio device.
Segmentation fault |
And that's with no application using /dev/dsp, never used OpenAL before
so I'm not sure what needs to be done to make it work.
OSS 3 however seems to be working fine, don't have OSS 4.
My machine is a bit slow for bsnes needs, but with OSS 3 I seem to get
better performance than with AO. The audio in the CT intro doesn't
stutter as much, with ao I keep getting "ALSA: underrun, at least
0ms.". Though as the status bar is just all black I can't tell what FPS
I get.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 25, 2007 11:08 am Post subject: |
|
OpenAL on Linux works here, have to apt-get install libopenal-dev and libalut-dev first. Summary time.
OpenAL/Windows:
- always crashes on 3 separate machines
- using official Creative driver stops crashes, but produces no audio
OpenAL/Linux:
- runs faster than 60fps (~62fps) and causes crackling audio, latency
setting does not help, nor does using a more common frequency
- changing the frequency crashes bsnes
- closing bsnes causes it to hang forever in either ~pAudioOAL() or pAudioOAL::term()
- works even when Audacious is running
- imperceptible latency, very good
OSS3/Linux:
- audio sounds fantastic, low latency
- cannot run when Audacious is running, /dev/dsp busy. Very annoying, but mostly a Linux/OSS3 problem
- causes terrible video lag, feels like video runs five frames, skips
three frames, repeat. Very unpleasant to look at
- changing frequency works fine here, but cannot disable frequency
throttle to allow uncapped speed > current frequency |
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Tue Dec 25, 2007 11:31 am Post subject: Updated makefile patch |
|
byuu,
here is the updated patch for the makefile. It adds the missing DESTDIR
(required for chrooted builds), fixes the permissions on the icon,
ensures the target dirs exists (again, required for chrooted builds)
and moves the icon to pixmaps (themed icons go to DATADIR/icons,
unthemed ones to DATADIR/icons).
Code: |
--- src/Makefile.makefilefix 2007-12-25 12:15:41.000000000 +0100
+++ src/Makefile 2007-12-25 12:18:32.000000000 +0100
@@ -304,8 +304,10 @@
####################
install:
- install -m 775 bsnes $(PREFIX)/bin/bsnes
- install -m 775 data/bsnes.png $(PREFIX)/share/icons/bsnes.png
+ install -d $(DESTDIR)$(PREFIX)/bin
+ install -d $(DESTDIR)$(PREFIX)/share/pixmaps
+ install -m 755 bsnes $(DESTDIR)$(PREFIX)/bin/bsnes
+ install -m 644 data/bsnes.png $(DESTDIR)$(PREFIX)/share/pixmaps/bsnes.png
clean:
-@$(RM) *.$(OBJ) |
I also have a desktop entry, feel free to integrate it if you are interested:
Code: |
[Desktop Entry]
Name=bsnes
Comment=SNES Emulator
Exec=bsnes
Icon=bsnes
Terminal=false
Type=Application
Categories=Game;Emulator;
|
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Dec 25, 2007 5:20 pm Post subject: |
|
It works here with system.audio = "ds", no sound with "oal".
(P4, WinXP, AC'97)
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Dec 25, 2007 5:54 pm Post subject: |
|
Okay, here's the deal with sound.
wertigon's initial OpenAL driver was incomplete and produced no audio,
and _willow_'s had some Windows-specific bindings.
So, Nach took those, some OpenAL sample code, and some other
application's OpenAL code and produced a working driver for it. Then
Nach and I refined the driver -- I got rid of the crashing on exit and
frequency changing, and both of us wrote new sample() functions. Nach's
is vastly superior on CPU resources, so we'll probably go with that one.
That code can be found here: http://byuu.cinnamonpirate.com/temp/audio.openal.cpp
This code wouldn't be possible without the help from wertigon, _willow_ and
Nach, so many thanks to everyone, and I'm sorry I wasn't able to go
directly with anyone's specific OpenAL driver. Linux compatibility was
a big concern here. You'll all be getting full credit in the source and
documentation for bsnes v0.028.
---
Now, as for the driver itself. It should work on Windows now with the
sample() and init() corrections, but maybe not. I don't have the means
at the moment to build a Windows binary with it, but maybe I can in the
future.
But anyway, I don't intend to compile in OpenAL/Win support by default
with bsnes, but rather leave it as an option for those who compile it
themselves. Why? Because Windows does not come with alut.dll and
OpenAL32.dll. I don't want to require another download to use bsnes,
and I don't want to package an extra 300kb of DLLs with it either.
Plus, it doesn't seem to be working too well for most people anyway
thus far.
Windows does come with DX9, and basically nobody has problems with
DirectSound. It's great, it has very low latency, and it seems to work
on everyone's sound cards, unlike the OpenAL stuff. So it's really not
needed for Windows.
---
However, on Linux, OpenAL has a lot of good points. Unlike with
Linux/OSS3, OpenAL backends to ALSA which supports software mixing.
Meaning audacious and bsnes can run at the same time. And OpenAL has
much lower latency than libao, as well as the ability to disable speed
throttling when necessary.
But! The OSS4 driver, with SND_DSP_COOKEDMODE, absolutely destroys even the OpenAL driver. In fact, it's even twice as good as the DirectSound driver on Windows! No joke!
From http://wiki.freebsd.org/RyanBeasley/ioctlref :
Quote: |
...
this ioctl is meant to give processes direct access to the hardware
buffer, giving the application the most control possible (ex:
minimizing latency by avoiding in-kernel processing). |
With this, I get roughly ~15-20ms latency, at the very most, with
bsnes. It skips kernel processing entirely! It's hard to even describe
such a low latency. I've never heard Link's sword sound effect start so
quickly. It's really quite impressive. Remember when kode54 was talking
about ASIO or kmixer or whatever? That super low latency kernel-level
audio setup that bypasses the kernel and goes directly to the sound
card? This is it, but for Linux. It's that good.
But the problem, of course, is Linux' obsession with ALSA, even though
OSS4 is GPLv2 now (and not to mention portable). ALSA is, of course,
total garbage. Anyone who's programmed for it knows that.
It's very easy to install OSS4, download a DEB package, double click
it, hit install and reboot. But the problem is, many Linux distros try
their best to kill OSS now. Lots of apps are compiled by Linux distro
vendors to only support ALSA, so it does cause some problems, and you
have to reconfigure many apps to use OSS afterwards, so it's not a very
good solution to make bsnes default to the OSS driver.
Further, because ALSA is so terrible, it causes the OpenAL driver
(which is really just a wrapper to ALSA here) to suck, and it causes
lots of static in the sound. And ALSA's OSS emulation causes severe
video lag -- bizarre, but it has something to do with the blocking
mechanism in ALSA. Only installing OSS4 fixes this. For both drivers,
in fact.
So, because of ALSA's pathetically poor emulation of both OSS and
OpenAL, I can't default bsnes to either of these drivers. Therefore, I
have to leave the libao driver as the default, but I really recommend
the installation of OSS4 (if you haven't gotten that hint already) if
you really want the best audio possible, and don't mind losing a couple
of your favorite ALSA-only apps. If installing OSS4 is too much of a
plunge, then I still recommend experimenting with the OpenAL and OSS
(in that order) drivers under ALSA. If they work good, great. If not,
sorry, it isn't a problem with the bsnes drivers. You'll have to stick
with libao and it's terrible latency and forced blocking. Unless
someone else wants to write an ALSA driver. I have no intentions of
programming for yet another single-platform API, myself.
---
With all of that said, I have a new WIP up. I'll send the link to any
Linux users who want to test it, as well. Feel free to ask.
This WIP is source code only (nothing changed on Windows), and has both the new OpenAL and OSS drivers. Testing would be greatly appreciated.
Last edited by byuu on Tue Dec 25, 2007 6:02 pm; edited 3 times in total
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Tue Dec 25, 2007 5:57 pm Post subject: |
|
byuu wrote: |
OpenAL on Linux works here, have to apt-get install libopenal-dev and libalut-dev first. Summary time. |
I have both OpenAL and ALUT installed, yet it just tells me /dev/dsp is
busy (lsof /dev/dsp shows that's not the case).
Do you need to run a some sound deamon for OpenAL to work?
EDIT: Thanks to this wiki
I managed to configure OpenAL to use ALSA and now it's working. Though
as my machine is to slow to get full-speed I can't say if it's better
than OSS3. But it seems better than 'ao' since there is less stutter in
the CT intro. With the 'ao' driver it's horrible. But again, the
statusbar is just black so I have no idea what FPS I'm getting.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
Last edited by [vEX] on Tue Dec 25, 2007 6:14 pm; edited 1 time in total
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Tue Dec 25, 2007 6:02 pm Post subject: |
|
Nach wrote: |
I would like some people to test for Windows though.
system.audio = "oal" for OpenAL, system.audio = "ds" for DirectSound. |
WinXP SP2, E-MU 0404 sound card
Crashes without the creative driver installed
No audio when using "oal", removing the openAL32.dll makes no difference
"ds" works fine of course...
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Dec 25, 2007 6:13 pm Post subject: |
|
Let me clarify the OpenAL driver.
I took my buffered OSS code and basically replaced the OSS specific stuff with the code I saw from wertigon.
This had no sound though.
I then looked through the code submitted by Yohumbus (make sure he gets
credit) in the ZSNES sound thread for OpenAL, and one example I found
online, and played with it based on what I read there to get sound
working.
After sound was working, it played a bit funny, so I mostly merged
_willow_'s sample code into my existing sample function. At this point
it was working pretty good.
byuu then cleaned up the OpenAL closing code, since apparently I made
some mistakes there. I really don't know OpenAL at all.
After this point, I cleaned up the sample function a bit more.
I'd have to say the overall framework is mine. The init code is
wertigon + Yohumbus + Google, with tweaks by me. The sample code is now
mostly _willow_'s with tweaks by me. And the closing code is wertigon +
Nach, fixed by byuu.
In any case, I recommend just using OSS 4, it's on every UNIX but Mac
OS X, and it sounds fantastic. I also personally didn't have much
trouble getting stuff to work with it, but your mileage of difficulty
may vary.
_________________
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 Tue Dec 25, 2007 6:23 pm; edited 1 time in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Dec 25, 2007 6:16 pm Post subject: |
|
byuu wrote: |
But
the problem, of course, is Linux' obsession with ALSA, even though OSS4
is GPLv2 now (and not to mention portable). ALSA is, of course, total
garbage. Anyone who's programmed for it knows that.
It's very easy to install OSS4, download a DEB package, double click
it, hit install and reboot. But the problem is, many Linux distros try
their best to kill OSS now. Lots of apps are compiled by Linux distro
vendors to only support ALSA |
Any idea (links?) why they're doing that? Sounds illogical.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Dec 25, 2007 6:47 pm Post subject: |
|
creaothceann wrote: |
byuu wrote: |
But
the problem, of course, is Linux' obsession with ALSA, even though OSS4
is GPLv2 now (and not to mention portable). ALSA is, of course, total
garbage. Anyone who's programmed for it knows that.
It's very easy to install OSS4, download a DEB package, double click
it, hit install and reboot. But the problem is, many Linux distros try
their best to kill OSS now. Lots of apps are compiled by Linux distro
vendors to only support ALSA |
Any idea (links?) why they're doing that? Sounds illogical.
|
Check out Nach's blog. He's already detailed the specifics on this issue.
http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
byuu wrote: |
But
anyway, I don't intend to compile in OpenAL/Win support by default with
bsnes, but rather leave it as an option for those who compile it
themselves. Why? Because Windows does not come with alut.dll and
OpenAL32.dll. I don't want to require another download to use bsnes,
and I don't want to package an extra 300kb of DLLs with it either.
Plus, it doesn't seem to be working too well for most people anyway
thus far. |
That's not a good way to go. If you are solely concerned about OpenAL
on Windows, just make sure your readme or cfg file or wherever provides
the link to download the default Creative OpenAL (wrapper) one if none
is provided by the sound card manufacturer. Not difficult at all to
worry about. You still should make DirectSound the default on Windows
anyways, for obvious reasons.
_________________
FF4 research never ends for me.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Dec 26, 2007 5:49 am Post subject: |
|
Code: |
"audio.openal.cpp":
//OpenAL suggests not to change frequency on the same source,
//but at least it works without crashing when we do this ...
|
That is plane wrong, OpenAL DO suggests
to change frequency on the same source, that its why it is superior to
other drivers. 100% clear thing. OpenAL should change frequency on
source, not by changing master clock. It's ideology and even not a tip.
As for windows sound i would like to take a bit of competition to make
the code more healthy at end. For me, DirectSound is something better
to avoid on windows, because it's direct hardware translation is
strictly limited to WinXP.
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 26, 2007 9:05 am Post subject: |
|
Quote: |
But again, the statusbar is just black so I have no idea what FPS I'm getting. |
I really want to fix this, but I can't trigger this bug at all on any of my machines :(
Is there any way you can test to see why it's doing that? The statusbar
handling code is in bsnes/lib/miu.gtk/miu.gtk.window.cpp under create()
and status_(show/hide/visible/set_text). It's very standard code, so it
should work the same as regular widgets ... maybe the gtk_box_pack for
it is wrong? I try to pack the menubar no vexpand, then the form no
vexpand, then the statusbar no vexpand. But I want the menubar and
statusbar with horizontal expand on for obvious reasons.
Quote: |
That is plane wrong, OpenAL DO suggests to change frequency on the same source |
Oh, I read this from the programmer's manual:
2) All buffers attached to a source using alSourceQueueBuffers should have the same audio format.
I figured frequency was part of the format. I guess it just means not
to change the 8-bit/16-bit/mono/stereo format stuff. Thanks for
clearing that up, I'll remove the comment.
Quote: |
That's
not a good way to go. If you are solely concerned about OpenAL on
Windows, just make sure your readme or cfg file or wherever provides
the link to download the default Creative OpenAL (wrapper) one if none
is provided by the sound card manufacturer. Not difficult at all to
worry about. You still should make DirectSound the default on Windows
anyways, for obvious reasons. |
Quote: |
For
me, DirectSound is something better to avoid on windows, because it's
direct hardware translation is strictly limited to WinXP. |
Yes, these are good points. Hmm, well I guess we'll see how the Windows OpenAL driver sounds when it's fixed up.
_willow_, please make sure you only use OpenAL 1.0 functions, too.
Creative doesn't seem to care much about its Linux driver, which is
labeled 0.8, but is supposedly compatible with 1.0.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Dec 26, 2007 9:24 am Post subject: |
|
byuu wrote: |
It's
very easy to install OSS4, download a DEB package, double click it, hit
install and reboot. But the problem is, many Linux distros try their
best to kill OSS now. Lots of apps are compiled by Linux distro vendors
to only support ALSA, so it does cause some problems, and you have to
reconfigure many apps to use OSS afterwards, so it's not a very good
solution to make bsnes default to the OSS driver. |
Will you update the readme with recommendations for which sound driver
to use on which system? That might avoid some questions when 0.0.28
goes public. Very good to see all the work that's been and is being
done on the sound drivers
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 10:44 am Post subject: |
|
byuu wrote: |
Quote: |
But again, the statusbar is just black so I have no idea what FPS I'm getting. |
I really want to fix this, but I can't trigger this bug at all on any of my machines :(
Is there any way you can test to see why it's doing that? The statusbar
handling code is in bsnes/lib/miu.gtk/miu.gtk.window.cpp under create()
and status_(show/hide/visible/set_text). It's very standard code, so it
should work the same as regular widgets ... maybe the gtk_box_pack for
it is wrong? I try to pack the menubar no vexpand, then the form no
vexpand, then the statusbar no vexpand. But I want the menubar and
statusbar with horizontal expand on for obvious reasons.
|
After a lot of poking around I found why it's black. In
src/ui/miu/ui_main.cpp, MainWindow::setup() you call
set_background_color(0, 0, 0), for some reason that makes the statusbar
black. I changed it to set_background_color(0, 255, 0) and sure enough
I had a green statusbar. The main window background color was still
black though. Assuming that set_background_color() is meant to be used
for the main UI this is very odd.
One would assume that GTK would use the color from the users GTK theme (in my case the default one).
EDIT: Omitting that function call completely (just commented it out) seems to work fine as well.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
Last edited by [vEX] on Wed Dec 26, 2007 11:03 am; edited 1 time in total
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 11:02 am Post subject: |
|
Some FPS/audio results now that I can see the counter:
With AO:
Chrono Trigger, ~47-55 during the intro, audio is stuttering a lot.
Super Mario Kart, ~48-58 during the intro, audio stuttering some.
With OpenAL:
Chrono Trigger, ~50-60 during the intro, audio stuttering some.
Super Mario Kart, ~50-60 during the intro, very little audio
stuttering. When they racing parts starts it was doing almost 60fps all
the time.
With OSS3:
Chrono Trigger, ~50-60, during the intro, not much audio stuttering.
Super Mario Kart, ~52-60, about the same as with OpenAL.
In Chrono Trigger, the worst part is just after the pendel stops
swinging and the CT text is floating in, it stutters really bad there
for all drivers.
As far as I can tell, the audio sounds the same with all drivers, but
clearly for my OSS3 seems to produce the best audio and at the same
time the best FPS. Though this was a very limited test.
EDIT: Wooa, there seems to be some serious memory leaks in the bsnes
code, my memory consumption is up at 1.06GB! Going to kill some stuff
and see if it was something else hogging memory or not.
EDIT2: After some testing it doesn't appear that bsnes was guilty. I
can't reproduce the memory consumption, but it could be all the
recompiling bsnes that somehow ate all my memory.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
Last edited by [vEX] on Wed Dec 26, 2007 12:34 pm; edited 2 times in total |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Dec 26, 2007 11:04 am Post subject: |
|
byuu wrote: |
_willow_,
please make sure you only use OpenAL 1.0 functions, too. Creative
doesn't seem to care much about its Linux driver, which is labeled 0.8,
but is supposedly compatible with 1.0. |
I don't know what is going on Linux, but actually it's supposed to be
1.1 with shared includes with creative's one. Do not worry about
extended features, i'm always provide alteranative solutions and double
check for extensions. It's more of useless precaution, because Bsnes
will hardly use any of 1.1 features.
svn checkout http://www.openal.org/repos/openal/trunk openal
Non accelerated OpenAL source for MacOS and Windows marked 1.1. If that
is not so for linux, then it's a question of time.
byuu wrote: |
I
figured frequency was part of the format. I guess it just means not to
change the 8-bit/16-bit/mono/stereo format stuff. Thanks for clearing
that up, I'll remove the comment. |
There is a lot more misreadings in specification. For that case i think
they mean the format should be valid one, same as buffer itself for
sure, and hopefully it's not changing in time - it would be certanly
cool to seamlessly connect/remix buffers as the single stream. And that
8-bit/16-bit/mono/stereo stuff is the first thing to keep constant,
because it's a question of channel mapping. OpenAL provider have it's
right to crush on format change, and it's a blank question do we call
frequency to be part of format. I don't like much more things about
OpenAL, too bad i need to actully look to the source code to see how
it's done in OpenAL wrappers . I believe OpenAL is pretty smart in frequency handling.
_________________
quake2xp audio engineer
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Dec 26, 2007 11:47 am Post subject: |
|
To think of this misreadings:
1) FREQUENCY, BITS, CHANNELS are buffer properties (attributes). Clear.
2) BITS, CHANNELS are format of the buffer. Clear.
3) FREQUENCY have no evidence to be format. The frequency is just
frequency or "property of Buffer". We have the right to turn it we'd
like.
Well, the freedom of interpretation is not absolute with OpenAL. Consult (Insult?) with actual OpenAL sources 
_________________
quake2xp audio engineer |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 26, 2007 1:03 pm Post subject: |
|
I have a new WIP up. Again, this one has only source, as nothing has changed on Windows since wip01.
This time, I've just cleaned up the OSS and OpenAL drivers. Nach will
probably want to kill me, since by cleaned up, I mean "removed lots of
not-so-helpful comments and safety checks", but I intend to add them
back. Before v028, I'd like to have vai init() functions return a
boolean success value, and have bsnes continue to fall back on lesser
drivers until there are none left, in which case it won't use one. But
it will keep the program from crashing.
Also, I tried some black magic on the OSS4 support. Because soundcard.h
is included in a different location than the OSS3 one, I tried manually
defining the new SNDCTL options and invoking ioctl regardless of OSS
version. This is supposed to be safe -- the ioctls should just fail
silently and it will behave just like OSS3. Let me know if you have
problems compiling or using the driver with OSS3, especially on
non-Linux boxen.
> Will you update the readme with recommendations for which sound driver to use on which system?
I suppose I can do that. I was planning on writing up an article about
OSS4 and such, perhaps I can just link to that in the readme.
> I changed it to set_background_color(0, 255, 0) and sure enough I
had a green statusbar. The main window background color was still black
though. Assuming that set_background_color() is meant to be used for
the main UI this is very odd.
Okay, here's how this works. Inside the main window, there is a view
control, which is a gtk_drawing_area(). I draw the video to this. When
bsnes is in windowed mode, obviously this control fills the entire
window. And the view control draws a black background by default. But
when you go fullscreen, the view area centers itself on your screen (or
tries to, some issues in GTK+ size requests render it non-perfect.) Now
there's the problem that the window itself is exposed on the sides.
Therefore, I have to set the window background to black here, otherwise
it will show up gray, which is very distracting in fullscreen mode, to say the least.
Now, I only tell GTK+ to set the window to black. The reason I do this
is because just setting the formcontainer to black has no effect, since
containers do not draw a background. As for why that is causing your
statusbar to render black ... good lord, I have no idea at all o.O
I don't know what to do to fix this, unfortunately ... but at least we
now know where the problem is so we can research it. Thank you very
much for tracking that down [vEX], I realize my request to have an
end-user look into that was unreasonable, but it's very much
appreciated.
> EDIT2: After some testing it doesn't appear that bsnes was guilty.
I can't reproduce the memory consumption, but it could be all the
recompiling bsnes that somehow ate all my memory.
bsnes does appear to have a tiny memory leak at the moment. It loses
about ~100k a minute on me. I'm not sure if it's specific to the Linux
port or not. This will certainly be a hard one to track down in such a
big program.
> I believe OpenAL is pretty smart in frequency handling.
Definitely. I don't really like complex APIs, but the buffering system
in OpenAL will actually come in handy. I failed with DirectSound, but
maybe with OpenAL I can manage to resample audio -- maybe even let
OpenAL do the resampling for me by calculating the frequency as a
measure of "how many samples should have been created" versus "how many
actually were."
That would be awesome. Combine that with OpenGL triple buffering, and
SDL/libjsw joypad support, and wow ... I'll have something really,
really usable :) |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 1:21 pm Post subject: |
|
byuu wrote: |
I have a new WIP up. Again, this one has only source, as nothing has changed on Windows since wip01.
> I changed it to set_background_color(0, 255, 0) and sure enough I
had a green statusbar. The main window background color was still black
though. Assuming that set_background_color() is meant to be used for
the main UI this is very odd.
Okay, here's how this works. Inside the main window, there is a view
control, which is a gtk_drawing_area(). I draw the video to this. When
bsnes is in windowed mode, obviously this control fills the entire
window. And the view control draws a black background by default. But
when you go fullscreen, the view area centers itself on your screen (or
tries to, some issues in GTK+ size requests render it non-perfect.) Now
there's the problem that the window itself is exposed on the sides.
Therefore, I have to set the window background to black here, otherwise
it will show up gray, which is very distracting in fullscreen mode, to say the least.
Now, I only tell GTK+ to set the window to black. The reason I do this
is because just setting the formcontainer to black has no effect, since
containers do not draw a background. As for why that is causing your
statusbar to render black ... good lord, I have no idea at all o.O
I don't know what to do to fix this, unfortunately ... but at least we
now know where the problem is so we can research it. Thank you very
much for tracking that down [vEX], I realize my request to have an
end-user look into that was unreasonable, but it's very much
appreciated. |
I only have Nach's WIP source to play around with, but I assume it
would still be the same as in your new WIP source. Could it be that the
statusbar has it's background set by default to be the same as the
parent container? Or is the parent for the statusbar the formcontainer
and not the window?
I actually never tried full screen mode before, but I just did with
0.027 and with Nach's WIP source.. it doesn't work at all for me. The
window moves to the upper right corner (same fixed size as windowed),
but the drawing area seems to be centered on the screen still, 'causing
me to only see the upper left part of the screen (1280x1024
resolution). Are there any settings I need to set for fullscreen to
work? I couldn't find anything about it in the readme.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 1:24 pm Post subject: |
|
byuu wrote: |
>
EDIT2: After some testing it doesn't appear that bsnes was guilty. I
can't reproduce the memory consumption, but it could be all the
recompiling bsnes that somehow ate all my memory.
bsnes does appear to have a tiny memory leak at the moment. It loses
about ~100k a minute on me. I'm not sure if it's specific to the Linux
port or not. This will certainly be a hard one to track down in such a
big program. |
Perhaps Valgrind can be of use? I never had to use anything like it before, but it might help finding the leak.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 26, 2007 1:28 pm Post subject: |
|
>
Could it be that the statusbar has it's background set by default to be
the same as the parent container? Or is the parent for the statusbar
the formcontainer and not the window?
Containers
lack background drawing, so they have no color. The statusbar's parent
is the window though. It would seem that on your system, it is
inheriting the window color, but on mine it is not. I wonder if that is
theme specific, and how I might override it :/
Maybe I can grab the GdkColor out of a newly created statusbar, and
then set the statusbar color to that inside the window set bgcolor
function ...
> I actually never tried full screen mode before, but I just did
with 0.027 and with Nach's WIP source.. it doesn't work at all for me.
The window moves to the upper right corner (same fixed size as
windowed), but the drawing area seems to be centered on the screen
still, 'causing me to only see the upper left part of the screen
(1280x1024 resolution). Are there any settings I need to set for
fullscreen to work? I couldn't find anything about it in the readme.
Man, what the heck are you using? TWM on Y-Windows?? o.O
That is freaking weird. I just call regular gtk_window_fullscreen(),
it's supposed to do the rest itself. No settings need to be made. Worst
case would be the default video out size was too big, but that wouldn't
cause the problem you see. You'd just have no video. And you'd need to
run at <640x480 for that to be a problem anyway.
> Perhaps Valgrind can be of use? I never had to use anything like it before, but it might help finding the leak.
Maybe, I've never used it. I should, but I don't want to grow dependent
on non-portable software again. Maybe when valgrind makes a BSD port ... |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Dec 26, 2007 2:16 pm Post subject: |
|
I found a problem with "audio.openal.cpp"
sample_buffer varied from 1 up to sample_buffer_size depending on
situation. I'm speaking about early data flush (queued up) in case of
frequency change. You can't merge different frequency data in one block.
That is what i mean:
Code: |
bool set(Audio::Setting setting, uintptr_t param) {
if(setting == Audio::Frequency) {
flush_data = true;
flush_frequency = settings.frequency;
settings.frequency = param;
if(sample_buffer) {
}
return true;
}
return false;
}
void sample_byuu(uint16 sl, uint16 sr) {
sample_buffer[sample_buffer_filled++] = sl + (sr << 16);
if(sample_buffer_filled < sample_buffer_size && !flush_data) return;
ALuint buffer = 0;
while(device_queue >= openal_queue_length) {
int processed;
alGetSourcei(device_source, AL_BUFFERS_PROCESSED, &processed);
while(processed--) {
alSourceUnqueueBuffers(device_source, 1, &buffer);
alDeleteBuffers(1, &buffer);
device_queue--;
}
}
alGenBuffers(1, &buffer);
alBufferData(buffer, device_format, sample_buffer, sample_buffer_filled * 4, flush_frequency);
flush_frequency = settings.frequency;
alSourceQueueBuffers(device_source, 1, &buffer);
device_queue++;
ALint playing;
alGetSourcei(device_source, AL_SOURCE_STATE, &playing);
if(playing != AL_PLAYING) alSourcePlay(device_source);
sample_buffer_filled = 0;
flush_data = false;
}
|
Don't know how it will work in real life, just a mind flash. The side
effect is the buffer get's shorter, i don't know do we need to
compensate it somehow.
P.S. don't like this simplified output routine. Not always to be simple equals to be faster 
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 26, 2007 2:55 pm Post subject: |
|
>
sample_buffer varied from 1 up to sample_buffer_size depending on
situation. I'm speaking about early data flush (queued up) in case of
frequency change. You can't merge different frequency data in one block.
I can sort of see what you're saying ... I'm honestly not worried about
a little sound glitchiness for one or two buffers when changing
frequencies. That's not something the user really does very often, if
ever. With every other driver, we kill the sound device entirely and
reinitialize it to change the frequency.
> P.S. don't like this simplified output routine. Not always to be simple equals to be faster
Yeah, mine wasn't very good or efficient. I want to ideally merge
Nach's with mine. I don't like the "build up the queue from 0 and stay
with 3" approach. My idea was to create all three queues at init(), and
kill all three at term(). But I haven't put a lot of thought into it
yet. It may not be that easy. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 2:57 pm Post subject: |
|
byuu wrote: |
>
Could it be that the statusbar has it's background set by default to be
the same as the parent container? Or is the parent for the statusbar
the formcontainer and not the window?
Containers lack background drawing, so they have no color. The
statusbar's parent is the window though. It would seem that on your
system, it is inheriting the window color, but on mine it is not. I
wonder if that is theme specific, and how I might override it :/
Maybe I can grab the GdkColor out of a newly created statusbar, and
then set the statusbar color to that inside the window set bgcolor
function ... |
Hmm.. I installed some GTK-themes and a theme-switcher. For some of the
themes the statusbar is not black, but not for all. I'll test a few
themes and then I'll post back and you can try theme and see if it's
all black for you too.
byuu wrote: |
> I actually never tried full screen mode before, but I just did
with 0.027 and with Nach's WIP source.. it doesn't work at all for me.
The window moves to the upper right corner (same fixed size as
windowed), but the drawing area seems to be centered on the screen
still, 'causing me to only see the upper left part of the screen
(1280x1024 resolution). Are there any settings I need to set for
fullscreen to work? I couldn't find anything about it in the readme.
Man, what the heck are you using? TWM on Y-Windows?? o.O
That is freaking weird. I just call regular gtk_window_fullscreen(),
it's supposed to do the rest itself. No settings need to be made. Worst
case would be the default video out size was too big, but that wouldn't
cause the problem you see. You'd just have no video. And you'd need to
run at <640x480 for that to be a problem anyway. |
I use plain Openbox, here's how it looks (with the black statusbar as well):

_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 3:28 pm Post subject: |
|
[vEX] wrote: |
Hmm..
I installed some GTK-themes and a theme-switcher. For some of the
themes the statusbar is not black, but not for all. I'll test a few
themes and then I'll post back and you can try theme and see if it's
all black for you too. |
Okay, the following GTK-themes gives me a black statusbar in bsnes:
Crux, H2O-gtk2-{Amber,Amythist,Emerakd,Ruby,Saphire}, HighContrast,
Humid, Industrial, LargePrint, Litoral, Mist, Raleigh, Redmond, Simple,
Smooth-Funky-Monkey.
And the following GTK-themes gives a usuable statusbar: Clearlooks,
Glossy, Inverted, Murina{Aquaish,Candy,Ealm,Olivo}, toolbox2.
It's only in bsnes that the statusbar is black, in any other
GTK-application (Firefox, Geany, Medit, Sonata) it's the correct color.
For what it's worth, my GTK2 version is 2.12.3.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Dec 26, 2007 4:46 pm Post subject: |
|
Thanks,
I've figured it out with your help. I used Murrina, so that is why I
couldn't reproduce your issue. It's apparently theme-dependent for the
statusbar to be transparent or solid.
I found someone with PHP-GTK that had the same problem: http://marc.info/?l=php-gtk-general&m=116642489803045&w=2
Although the code is PHP, he did have the solution: I need to pack the
statusbar inside of a GtkEventBox. Since the EventBox paints its own
color, rather than being transparent to the form, this should solve the
issue.
And of course, I now know how to reproduce the bug so I can verify that it was fixed :D
As for bsnes in fullscreen, it honestly looks like a problem with your
window manager. I'll have to write a simple test app or something to
verify that. But it looks like gtk_window_fullscreen() is thinking your
desktop is only 590x490 ... very bizarre. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Dec 26, 2007 4:51 pm Post subject: |
|
byuu wrote: |
Thanks,
I've figured it out with your help. I used Murrina, so that is why I
couldn't reproduce your issue. It's apparently theme-dependent for the
statusbar to be transparent or solid.
I found someone with PHP-GTK that had the same problem: http://marc.info/?l=php-gtk-general&m=116642489803045&w=2
Although the code is PHP, he did have the solution: I need to pack the
statusbar inside of a GtkEventBox. Since the EventBox paints its own
color, rather than being transparent to the form, this should solve the
issue.
And of course, I now know how to reproduce the bug so I can verify that it was fixed :D |
Yay, one down, one to go! :-)
byuu wrote: |
As
for bsnes in fullscreen, it honestly looks like a problem with your
window manager. I'll have to write a simple test app or something to
verify that. But it looks like gtk_window_fullscreen() is thinking your
desktop is only 590x490 ... very bizarre. |
Just send it to me via PM/mail or whatever and I'll be happy to help
you track it down. Probably better send it as source since I'm running
64-bit and not 32-bit.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Dec 27, 2007 2:10 am Post subject: |
|
Almost finished the OpenGL renderer. 
Just need to test out a few more things. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 27, 2007 2:03 pm Post subject: |
|
Okay, I fixed the statusbar issue in the new WIP. I also added a new library called bproperty.h.
The idea is that cap/get/set aren't sufficiently capable for vai. Like
say, OSS has SNDCTL_DSP_POLICY, which can be 0 - 10, and controls
latency. libao has a list of supported drivers. But I don't want to add
new enums to the base Audio class for every single feature of every
driver. That would be unwieldy.
I also only have a base Audio* pointer, and testing Audio* and casting
to modify variables isn't something I want to do. That defeats the
purpose of encapsulation if I'm dynamic_casting all the time.
So then, I need a way to access all variables directly from the base
class, but without naming them ... really, only strings will do this.
So I want to use audio->set("policy", 10), for instance.
If audio were not a pointer, maybe audio["policy"] = 10 would look
nicer, but eh. No reason to confuse people with overloaded operators,
and I can abort set() if "policy" doesn't exist, but not [].
So then, I also need a way to encode any type of data. Be it strings,
integers, etc. This is always a major pain in C++ ... I went with const
string& for the datatype, since my string class can intrinsically
cast between integers and strings, eg string t = 4; if(t == 4) t =
"yes"; -- it just stores 4 as "4", basically, and operator int()
converts it back to an integer. Slow, but I'm not looking for speed
here. The array string search to find the variable is slower anyway.
It's either this, or I stick with uintptr_t and send back const
string&s through that when I want strings. But that'll make the
functions ugly, eg: audio->set("driver", (uintptr_t)"oss"); -- ick.
But then, strings will have a hard time portably converting to and from
uintptr_t, as that can be bigger than int (and is on 64-bit systems.)
Anyway, other goals were to allow a list enumeration of all settings so
that users can easily see and modify things, and to bind a callback on
get and set events, similar to the on_events in miu. That part was
easy, at least.
Quote: |
Almost finished the OpenGL renderer. |
:D
Hopefully it'll work on Linux. Really not happy with the Xv renderer ...
You're using OpenGL directly, right? No SDL wrapper or anything like that?
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Dec 27, 2007 2:14 pm Post subject: |
|
Quote: |
You're using OpenGL directly, right? No SDL wrapper or anything like that? |
Yes, no SDL, GLUT, or GLEW is used at all. Only platform specific code
is the PFD init and culling of the OpenGL device and rendering
contexts. Everything else is done based on OpenGL 1.1-1.3 specs.
|
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Thu Dec 27, 2007 4:07 pm Post subject: |
|
byuu wrote: |
So then, I also need a way to encode any type of data. Be it strings, integers, etc. |
Well, have you considered void pointers? I know, it's a *really* ugly
hack, but atleast it'd be consistent. Just make sure to validate that
the value is an integer or whatever you need. Example:
Code: |
int value = 42;
audio->set("property", (void*)&value); |
And, sorry for not being able to work more on that OpenAL stuff... It's
been in the back of my head, but lots of stuff is going on in my life
right now. I'm glad my code helped somewhat though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 27, 2007 6:38 pm Post subject: |
|
Quote: |
Well, have you considered void pointers? I know, it's a *really* ugly hack, but atleast it'd be consistent. |
Lots and lots of issues with using void* as a generic type. I decided
to try implementing my own any type. It was actually really easy, I
used the old function<class> hide trick (a pointer to a base
type, that holds a derived<class> type, statically casted as
needed for use.)
I would use boost::any, but I don't want to add a 12MB dependency to
build bsnes for just one thing. And mine's better (read: lacks real
world testing, has more bugs, works on less compilers, but has a nicer
interface), as always. Mine can read and compare any's against whatever
without any_cast<>.
Code is here:
http://www.geocities.com/byuu64/any.cpp.txt
Quote: |
And,
sorry for not being able to work more on that OpenAL stuff... It's been
in the back of my head, but lots of stuff is going on in my life right
now. |
No worries, we got it all working in the end with everyone's help :)
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Dec 27, 2007 7:00 pm Post subject: |
|
I
just wanted to say that while I wish I knew enough about programming to
contribute, and also haven't actually seen any of the new WIPs, I
wanted to say how happy I am to see such a frenzy of activity and
support for bsnes. So much contribution all at once! I can only hope
this trend will continue for a long time.
EDIT: took out an unnecessary "just"
Last edited by DancemasterGlenn on Sat Dec 29, 2007 8:12 am; edited 1 time in total |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Dec 27, 2007 8:08 pm Post subject: |
|
Just
got OSS 4 installed and I must say that when my machine can't keep up
and FPS drops below 60 it sounds really awful! Lots of crackling and
popping. I need a new, faster machine. :-/
Hmm..
the speed regulation menu entry "Enable" doesn't seem to do anything,
even if I have it unchecked the different options will be applied.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 27, 2007 10:13 pm Post subject: |
|
Quote: |
So much contribution all at once! I can only hope this trend will continue for a long time. |
Likewise! I've been in a really positive mood all week as a result,
despite returning to work after an extended vacation. Thanks, everyone!
Quote: |
Hmm..
the speed regulation menu entry "Enable" doesn't seem to do anything,
even if I have it unchecked the different options will be applied. |
Ah, this is because none of the Linux sound drivers support
non-blocking mode yet. libao can never support it due to the API being
too simplistic. OSS can do it with a special SNDCTL setting that I
already forgot ... and OpenAL should be the easiest of all, just drop
the current buffer if we already have more than two queued buffers,
rather than wait for a buffer to finish playing.
The options will work eventually, and drivers that don't support the
options will have the menu items removed (rather than grayed out --
graying out items just confuses end users as to why it's not enabled.)
---
Okay, wow. I just profiled boost::any versus my implementation to see
if they had a better internal approach. Apparently not.
Code: |
volatile int counter = 0;
boost::any o;
any n;
volatile int m;
time_t start, end;
start = clock();
for(volatile int i = 0; i < 100000000; i++) {
n = counter; counter++;
}
end = clock();
printf("any %d\n", int(end-start)); |
I perform the exact same loop for byuu::any, boost::any, and a standard int. Timing results in milliseconds?
Code: |
any 2359
boost::any 69611
int 406 |
Hah. Mine is ~6x slower than a native type, and boost::any is ~172x
slower. So, my implementation is ~30x faster than boost's for the most
common usage scenario.
The speed hit is obviously coming from boost always
calling delete + new upon assignment, even when the types are the same.
Obviously, if you always assign different types in succession (which
would be very odd indeed), then boost::any would fare a lot better.
Still ... that's a rather basic optimization. I never understand why
people recommend this code and never bother to even perform basic
profiling on it.
Sadly, we can't bypass the need
to use new+delete when the type changes. blargg's trick of using a
buffer to store the data in would only work for primitive types.
Objects can be any size, so the second you end up with struct foo {
char n[really_big_number]; }; that will blow up your any class
container.
---
EDIT: minor improvements to any. A smart casting system will now auto
convert strings to pointers, so any t = "string"; will convert const
char[7] to const char*.
Code: |
class any {
public:
template<typename T> struct autocast { typedef T type; };
template<typename T> struct autocast<T[]> { typedef T* type; };
template<typename T> struct autocast<const T[]> { typedef const T* type; };
template<typename T, int N> struct autocast<T[N]> { typedef T* type; };
template<typename T, int N> struct autocast<const T[N]> { typedef const T* type; };
bool empty() const { return bin; }
const std::type_info& type() const { return bin ? bin->type() : typeid(void); }
template<typename T> operator T&() { return ((containee<T>*)bin)->data; }
template<typename T> operator const T&() const { return ((containee<T>*)bin)->data; }
template<typename T> any& operator=(const T &value_) {
if(type() == typeid(T)) {
((containee<typename autocast<T>::type>*)bin)->data = value_;
} else {
if(bin) delete bin;
bin = new containee<typename autocast<T>::type>(value_);
}
return *this;
}
template<typename T> bool operator==(const T &value) const {
return value == ((containee<T>*)bin)->data; }
template<typename T> bool operator!=(const T &value) const {
return value != ((containee<T>*)bin)->data; }
struct container { virtual const std::type_info& type() const = 0; } *bin;
template<typename T> struct containee : container {
T data;
const std::type_info& type() const { return typeid(T); }
containee(const T &data_) : data(data_) {}
};
any() : bin(0) {}
template<typename T> any(const T &value_) : bin(0) { operator=(value_); }
}; |
Still not sure what I want to do when casting to invalid types. I can
detect that by verifying that typeid(T) != bin->type(). But that
triggers even on conversions that are possible through a
reinterpret_cast, such as the case with unsigned int vs int. Of course,
problems do arise from that. If you store a type uint8 and read back as
int, you're reading 3 bytes past the size of the object. I really hate
boost's approach of throwing, though. What a terrible idea to have to
try {} catch every single variable read.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Dec 28, 2007 11:45 am Post subject: |
|
Quote: |
Likewise!
I've been in a really positive mood all week as a result, despite
returning to work after an extended vacation. Thanks, everyone! |
No probs
Glad to help. Plus, I thought BSNES was overdue for a OGL renderer
anyway, since its got everything else including the kitchen sink
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Dec 29, 2007 11:35 pm Post subject: |
|
Quote: |
Mine
is ~6x slower than a native type, and boost::any is ~172x slower. So,
my implementation is ~30x faster than boost's for the most common usage
scenario.
The speed hit is obviously coming
from boost always calling delete + new upon assignment, even when the
types are the same. Obviously, if you always assign different types in
succession (which would be very odd indeed), then boost::any would fare
a lot better. Still ... that's a rather basic optimization. I never
understand why people recommend this code and never bother to even
perform basic profiling on it. |
Basic optimization is profiling your entire program and finding hotspots to optimize. If boost/byuu::any isn't a hotspot, optimizing it is a waste of time
that could be better spent optimizing things that are major
contributors to program speed, and leaves you with a class that's
harder to understand. If one were using boost::any where its
performance was critical, the allocator could be replaced with an
optimized one (with a couple of lines of code, no changes to boost
code).
Boost's authors have purposes other than
speed at all other costs. Their code is primarily aimed at providing
useful constructs for a wide range of programs, most of which will run
no faster even if boost::any took zero time. In these cases, you want a general class, not one that trades off flexibility to save a few cycles.
Quote: |
Sadly,
we can't bypass the need to use new+delete when the type changes.
blargg's trick of using a buffer to store the data in would only work
for primitive types. Objects can be any size, so the second you end up
with struct foo { char n[really_big_number]; }; that will blow up your
any class container. |
Keep a small buffer in the object and use it if it's big enough, otherwise fall back on a memory allocation:
Code: |
char small [...];
void* raw = &small;
if ( sizeof (T) > sizeof (small) )
raw = new char [sizeof (T)];
T* obj = new (raw) T( ... );
...
if ( (void*) obj != (void*) &small )
delete obj; |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 30, 2007 2:10 am Post subject: |
|
Quote: |
If
boost/byuu::any isn't a hotspot, optimizing it is a waste of time that
could be better spent optimizing things that are major contributors to
program speed, and leaves you with a class that's harder to understand. |
I like to optimize the foundation (libraries) as much as possible. Let
the actual program you're working on be implemented to show how it
should be done, at the cost of speed -- if you want. The core library
should be fast, so that it can be built upon as much as you like, and
never become the performance bottleneck.
Anyway, I wasn't too worried about speed, and for the most part I agree
with you about optimizing the important parts only. Really, I just like
implementing this stuff by hand myself. Call it NIH, but I like the
experience / practice. It's made me a much better programmer as a
whole, by knowing all of these template meta-programming and partial
specialization tricks.
Quote: |
Keep a small buffer in the object and use it if it's big enough, otherwise fall back on a memory allocation: |
I thought about that, but I don't like having additional approaches
that don't work in all cases. I came up with something that should help
out 99% of the time, though.
For type deduction, given typename T, use something like:
Code: |
typedef
typename type_if<is_integral<T>::value, uint64_t, typename
type_if<is_floating_point<T>::value, long double, typename
type_if<is_array<T>::value, typename
remove_extent<T>::type*, T>, T>, T> type; |
This way, you always have enough storage space for anything
fundamental, and you can now perform all implicit casts safely (though
unfortunately right now my class even allows const casts, which can be
quite dangerous). This will also let me be more aggressive with what to
do when typeid(T) != type_info(current_object_type). I still don't like
the idea of throwing, but it's probably best in this case. It would
just be stupid to throw when you cast an unsigned int to an int, as
boost::any's strict template type matching does.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Dec 31, 2007 1:25 am Post subject: |
|
i finally got around to testing bsnes on another machine...
on my current system and on my dads pc the same issue with it using
BOTH cores is present... my dads uses HT (intel) so it isn't really a
second core but still.
his pc is a...
ASUS P5LD2
Intel Pentium 4 3.00ghz with HT and 2mb cache
2gig ddr2 800mhz ram
Geforce 6600gt 128mb jetway
onboard sound
4 drives
300 watt high quality power supply (provides 30 amps on the 5v and 15 amps on the 12v rails)
_________________
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. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 31, 2007 3:05 pm Post subject: |
|
Ok, that's what i have so far:
I'm finished the channels splitting and got hardware volume
controllers. The quality is much better on my X-Fi soundblaster as it's
internal mixer is 24bit, still huge problem persist. The problem is
that volume controllers do quite different job then PS's one. On PC you
set the source volume and let em start. On SNES it works like the part
of synth maker and this messing things a lot.
So, no more hardware volume controllers and echo, sorry , Its not turning on as i expected.
But i do suggest to use multisource 24bit output. It can be mixed in
hardware or in software dependind on plugin or setup. 24bit output is
quite obvious suggestion as many modern build-in codecs are 24bit.
Multisource output making sense on hardware mixers, when audio DSP
performs sample-rate conversion, it's very important to minimize
cross-channel interference. In case of initially splitted sources the
outcome signal would be much more precise compared to pre-mixed signal.
Please byuu, can you extend the API, would you be so kind? . I'm already have the extended multisource OpenAL plugin.
I do not want to patch just for myself any single release in future 
_________________
quake2xp audio engineer |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Dec 31, 2007 6:00 pm Post subject: |
|
how do you get cross-channel interference on digital inputs into a digital mixer?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Dec 31, 2007 6:10 pm Post subject: |
|
Good question, it's digital so....
_________________
Watering ur plants. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 31, 2007 7:09 pm Post subject: |
|

Ahh, good question!
Look, output signal for resampling algorithm is nothing but a function.
It's hard to predict how exactly it should look at some moment. Because
it's too complex. Resampling algorithm expecting the signal to be
looking like sinus wave, because sinus function have physical presence
in any wave process, also sinus have minor fluctuations and easier to
predict. The less complex wave function is, the more it looks like
sinus graph, the more correct prediction will be. And then, after we
resample output channels (all audio DSPs do this computing virtually or
in true parallel), the DSP chip will mix them. So we will get the same
clean wave as before resampling with a much less misprediction as it
could be with premixed stream. The trick here is not mixing channels
before resampling - mixing is the most precise operation anyway, not to
resample the complex wave. I'm pointing out that OpenAL have the
opportunity to resample channels in parallel, this should be used the
most wize way. If the API have no such capabilities then it would be
nothing wrong to premix all sources to the single stream.
_________________
quake2xp audio engineer |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Dec 31, 2007 9:27 pm Post subject: |
|
I am not expert on OpenAL but isn't it more geared toward 3d sound?
_________________
Watering ur plants. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Dec 31, 2007 9:52 pm Post subject: |
|
It
works for flat sounds as well. The API can perfectly sync hardware
channels, can handle queues with different sample rates. Multipurpose
API is not that bad.. It is not any harder then X3DAudio. Well, OpenAL
is designed to take most of the sound card, for example i like it's
buffer management, the way it support sound card onboard memory for
storing buffers. This gives great acceleration and ultra low latencies
for games. OpenAL is designed to be expandable. It is actually can work
as a sound system for the whole OS, i miss the 24bit samples support
the most. And most goodness of it, it is guaranteed to bypass software
mixers and talking directly to the hardware. On Creative's hardware of
course. It's not designed for professional needs, that is what ASIO
for. ASIO have nothing, even have no volume controller and blocking any
other API, really like it.
EDIT:
My total latency for bsnes is 1024 samples (0.031 sec refresh frame) with 18 test channels in sync, need i say more?
_________________
quake2xp audio engineer |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Dec 31, 2007 11:55 pm Post subject: |
|
Quote: |
Look,
output signal for resampling algorithm is nothing but a function. It's
hard to predict how exactly it should look at some moment. Because it's
too complex. Resampling algorithm expecting the signal to be looking
like sinus wave, because sinus function have physical presence in any
wave process, also sinus have minor fluctuations and easier to predict.
The less complex wave function is, the more it looks like sinus graph,
the more correct prediction will be. And then, after we resample output
channels (all audio DSPs do this computing virtually or in true
parallel), the DSP chip will mix them. So we will get the same clean
wave as before resampling with a much less misprediction as it could be
with premixed stream. The trick here is not mixing channels before
resampling - mixing is the most precise operation anyway, not to
resample the complex wave. I'm pointing out that OpenAL have the
opportunity to resample channels in parallel, this should be used the
most wize way. If the API have no such capabilities then it would be
nothing wrong to premix all sources to the single stream. |
Meanwhile, in the real world, a digital resampler can handle any input
signal, be it a pure sine wave or combination of many (as most signals
are). The math is well-defined and very predictable. Also, a resampler
that handles stereo signals will do them separately; it's absolutely
silly to think that the left and right channels would mix together
(unless your sound card adds stereo effects or something stupid).
(Sorry to come down on the above quote but it's pure junk that might
mislead other people)
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 01, 2008 1:23 am Post subject: |
|

No NO NO!! i'm not about left and right channels and balance stuff, but
sources of the snes synth itself! At my most trusted practice i use
nine (9) stereo sources (8+echo) to pass directly to OpenAL.
blargg wrote: |
Meanwhile,
in the real world, a digital resampler can handle any input signal, be
it a pure sine wave or combination of many (as most signals are). The
math is well-defined and very predictable. |
Right of it's digitness, resampler predicted this combination of many
to be single (as you feed it single stream) and smoothing the signal,
while multistream independed processing and only then the final mix
shall let em stay well-shaped. I'm not saying the interpolation of the
single stream would not work, it WOULD do the job of course, i just
think it's would be clever to use the wasted power of the hardware to
improve the quality. If you still do not understand my point then i'll
do my own bsnes compilation .
Not a problem for me, just time waste to do the same patch all the
time. But you'd better think of my idea as for bit-perfect partial
traslation of SNES DSP to PC DSP, so it's not heresy and i'm not
splitting those raw stereo streams from nowhere, they are already exist
in SNES and i'm confident about speaking logical. Well, i did actual
direct volume controllers pass-trough as well, and it works, but i
reject this because it's not bit-perfect, all because of uncontrollable
massive desyncs with actual raw streams.. I propose what is best, feel
the difference.
_________________
quake2xp audio engineer
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Jan 01, 2008 6:11 am Post subject: |
|
My concern is that wouldn't this detract from accurate emulation?
Like afterall, this emulator is meant to be focused on accuracy. But
wouldn't mapping to hardware sound channels detract from this? To me,
this sounds sorta like HLE.
Anyways, byuu, here's
what I wrote of the OpenGL renderer so far, to prove its very much
being worked on. I based it on the DDraw class as a guide, and ported
some of the ideas from the D3D renderer to OpenGL. For some odd reason
though, I am not getting a image, but the rest seems okay, and the PFD
seems to close and open properly, which is the main thing. Just seems a
issue with writing the texture though. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Jan 01, 2008 1:08 pm Post subject: |
|
Byuu,
i have noticed that thin vertical lines tend to look weird while the
screen scrolls horizontally... is there a reason behind it? most
noticable in the floor in megaman x1, x2 and x3
_________________
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. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Jan 01, 2008 2:30 pm Post subject: |
|
frandpa, that sounds like the D3D scaler issue that has already been discussed. I believe byuu was looking into it. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 01, 2008 3:21 pm Post subject: |
|
Oh guys, which one of you is audio engineer and messing with codecs too?
mudlord wrote: |
Like afterall, this emulator is meant to be focused on accuracy. But
wouldn't mapping to hardware sound channels detract from this?
|
It's not a question to discuss. Of cource my suggestion focused on
improving emulation accuracy! PC and SNES too, i'm sure, they are
mixing channels similar way:
channel 1 + channel 2 + channel 3 + channel 4 ... and so on.
The exact math presented on all platforms. Plus limiters to clip overflows. All chips must have limiters, otherwise it's a buggy chip.
Well, i'm going to compare PC and SNES functionality now:
SNES:
1) hardware mixing
2) hardware clipping
BSNES (variant b, bsnes now):
1) software mixing
2) software clipping
3) hardware resampling (optional, 33khz to system clock)
4) final PC-wide hardware mixing
5) final PC-wide hardware clipping
BSNES (variant a, suggestion ):
1) hardware resampling (optional, 33khz to system clock)
2) final PC-wide hardware mixing
3) final PC-wide hardware clipping
What the bsnes do now is an illusion of quality. Because it's final mix
output is not PC endpoint, unlike it is on SNES. What i did, is just
provided more natural data flow, bit-perfect translation. You see, we
have optional resampling step. We have no such step on SNES. Resampling
is always
lossy computation. All i did is just swap the steps to effectively
decrease the influence of the resampling math. Reduce influence of the
resampling math by the use of the right computing order, that is what
all hardware audio DSP do, OMG!!! Except SNES, because it do not need
resampling. I'm going to say, it's not obligatory to use
multisource-ness, such single stream API plugins like ASIO plugin could
premix sources like the current BSNES do. It's not bad at all, because
most likely that API's would support direct output without resampling
because of their professional profile. And multisource API's like
OpenAL, XAudio are most likely do resampling because of gaming profile.
_________________
quake2xp audio engineer
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 01, 2008 5:05 pm Post subject: |
|
_willow_ wrote: |
Oh guys, which one of you is audio engineer and messing with codecs too?
|
*Raises Hand
I do much work with video as well, but on the video front I don't have
much experience with writing the output to the screen. Maybe one of
these days I'll learn that too and add multimedia expert to my resume.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 01, 2008 5:24 pm Post subject: |
|
I
do not doubt your experience, i do not know SNES hardware at all, i
just know how the PC hardware and mixers works. And i'm all for
improving quality without compromizing the speed and moreover the
equality to SNES hardware. Just look at this rendering graph again:
BSNES (Byuu's compilation):
1) software mixing
2) software clipping
3) hardware resampling (optional, 33khz to system clock)
4) final PC-wide hardware mixing
5) final PC-wide hardware clipping
BSNES (My compilation):
1) hardware resampling (optional, 33khz to system clock)
2) final PC-wide hardware mixing
3) final PC-wide hardware clipping
_________________
quake2xp audio engineer |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue Jan 01, 2008 5:34 pm Post subject: |
|
What
about guys like me who just stick to Intel HDA. I mean a lot of us
can't be bothered to by an X-Fi because onboard is just good enough.
_________________
Watering ur plants. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Jan 01, 2008 6:31 pm Post subject: |
|
Yeah,
I'm about to build a PC and I don't really have the cash to get a sound
card... Would the changes you propose effect the newer Intel audio? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 01, 2008 7:24 pm Post subject: |
|
Okay, I posted a new WIP. This one's source only again, since the Windows port is still unchanged.
I went through and used std::min + std::max, rather than my own
#define, for the sole benefit of getting Nach's JMA code to compile
again (JMA includes a C++ standard header that doesn't like you
#defining min/max, apparently). I was kind of cheap with it though,
max(0, min(10, value)) -> max(0U, min(10U, value)), etc.
Geez, std::min/max can't even cast between uint16 and uint32. What a
joke, I'll have to write my own that takes advantage of type traits.
I also started killing off the "bheader.h" files. Since 90% of them are
just template classes, I figure I may as well stick them all in a
namespace and make something akin to boost / Loki. I'm calling this one
nall (I love making up all these names, lately). I also use gcc -I to
point to it, so you get #include <nall/array.hpp> instead of
#include "../../../lib/barray.h", much nicer.
Taking advantage of the new template library, I added any.hpp (generic
object container), traits.hpp (type traits) and static.hpp (static
assert, if), and with that, I made stdint.hpp, which is a C++
implementation of stdint.h. Since stdint.h is part of C99, it isn't
included with all compilers (eg Visual C++). By using sizeof() and
static_if, I was able to make my own compiler-independent version of
this file. Thus, the dependency on stdint.h was removed.
I'd be very interested in feedback on anything in nall/ (it's located in src/lib).
Specifically, could someone with a big-endian machine test any.hpp? I'm
worried that downcasting will reverse the order of data read back.
Example test app:
Code: |
#include <stdio.h>
#include <nall/any.hpp>
int main() {
nall::any t = 0x01020304;
printf("0x%x\n",nall::any_cast<short>(t)); //should print 0x0304
return 0;
} |
Quote: |
Please byuu, can you extend the API, would you be so kind? |
Of course, I want vai to be used for more than just SNES emulation.
Though I've yet to get anyone using any of my libraries before, so it
may be a fairly pointless endeavor.
It'll take me some time, though. I'm working on a lot of other stuff first.
Quote: |
Anyways, byuu, here's what I wrote of the OpenGL renderer so far, to prove its very much being worked on. |
Really cool! My only concern is the use of Win32-specific code (header,
GetForegroundWindow(), HDC stuff, setting up the pixel format stuff)
... no idea how this is going to compile on Linux :(
I don't know the Linux equivalents to all of the Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have the
Win version finished. Thanks a million for making this :D
Quote: |
What about guys like me who just stick to Intel HDA. |
Hah, I do the same. I'm not going to spend more on my sound card than on my mainboard that comes with onboard sound. HDA sounds just fine to me :/
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 01, 2008 9:36 pm Post subject: |
|
Intel
HDA can benefit from 24bit output. On the PC hardware the output device
driver must decide what should be castrated and what shouldnt Better
pay a little bit extra computing on oldest 16bit codecs, but well the
PC hardware changes more faster then SNES equipment
If you really think you'll pass 16 bit data on 24bit codec like Intel
HDA, then better do not fool yourself as the data will be extended to
24bit with some sort of guessing about the lowest bits. You are not
guaranteed to get the bit-to-bit passing up to analog generator. Well,
there is some special API's like ASIO exist, but they are not always
comfortable to end user as they more likely to block output for other
background programs and services. I better choose a friendly home PC
with ICQ notifications and stuff, not professional studio .
The output plugin can sort out the software codecs if the API get's
extended up to device enumeration, which i'm seriously suggest to
implement. Something like all plugins will generate the unique device
name strings like:
"OpenAL: default"
"OpenAL: software"
"OpenAL: hardware"
"OpenAL: device ABC"
"OpenAL: device DEF"
"XAudio: default"
"XAudio: device ABC"
"XAudio: device DEF"
So the output plugin can premix the sources to reduce computing on
software codecs. That is really easy, just source 1+source 2+source 3
etc.
byuu wrote: |
Of course, I want vai to be used for more than just SNES emulation.
Though I've yet to get anyone using any of my libraries before, so it
may be a fairly pointless endeavor.
It'll take me some time, though. I'm working on a lot of other stuff first.
|
I do not want it to do anything but emulation too. I'll polish API a
bit more for software codecs case and then you can use it. Or not.. i
like open source 
_________________
quake2xp audio engineer
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 01, 2008 11:06 pm Post subject: |
|
franpa wrote: |
Byuu,
i have noticed that thin vertical lines tend to look weird while the
screen scrolls horizontally... is there a reason behind it? most
noticable in the floor in megaman x1, x2 and x3 |
Franpa, random question, are you running the filtering in point rather than linear? that might cause that effect.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Jan 02, 2008 12:39 am Post subject: |
|
yes, the latter = blurred screen.
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 02, 2008 2:21 am Post subject: |
|
yes, I've noticed that when using point filtering also, I think that it has something to do with that.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Jan 02, 2008 3:00 am Post subject: |
|
willow,
I get what your idea is, to have the S-DSP output each voice
individually, with as little processing as possible, but it's pointless
since the sound quality of the S-DSP isn't good enough to make a
difference. The instrument samples themselves are compressed with an
ADPCM-like compression and post-filtered, and low bits are lost during
mixing so it's not even 16 bits of resolution. If one wanted an
enhanced version, the S-DSP emulator could do all operations in 24
bits, without the lossy scaling used. In fact, I imagine the SNESAPU
library probably has some options to do this. Even then, I doubt you'll
ever hear the difference for SNES games, and bsnes is aimed at accurate
reproduction, not enhancement, so it's pretty much wasted effort for
most users. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 02, 2008 3:09 am Post subject: |
|
is anyone currently working on an enhancement snes emu? It seems to only be popular with later consoles.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 02, 2008 4:44 am Post subject: |
|
Panzer88 wrote: |
is anyone currently working on an enhancement snes emu? It seems to only be popular with later consoles. |
On 3d consoles, you can render in a higher resolution and apply higher
levels of AA and AF than the console itself. All you have for 2d
material is nostalgic "enhancements" like scanlines and graphics
filters to mimic the effects of the prevailing analog display
technology of the time. They don't objectively perform an enhanced
operation already performed in a lesser form on the console itself.
Either way you see it, unfiltered/filtered is offered on most emulators
for old consoles, so you're already getting your enhancement option.
What do you feel you're still missing exactly? It's not like bsnes can
double the resolution of every game. The information is not there, it
would have to invent it.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 02, 2008 6:26 am Post subject: |
|
take
it easy man, I'm fully aware that working with with sprites is quite
limiting compared to 3D models. Nor am I asking more of, or trying to
insult bsnes.
what more do I want? nothing from bsnes, I'm happy with what it is.
I would like to see other things like the audio things being talked
about here. Granted there are prolly negligible differences, but it's
not that I just need more, more, more features or filters, that's not
the point. But it's fascinating to see what is possible, and
interesting.
many things would require hacking of roms in correlation with the
emulator enhancements. Anything from a rumble addition, to the
equivalent of high res textures on the N64 (which would involve
allowing the system to itself output higher resolutions, you would have
to replace the sprites in the rom with larger equivalents, but the core
game engine could remain unaltered)
those two examples are WAY out there, and like I said, it's not
something that is necessary, which is why I'm not even bothering asking
for it with accuracy emulators because I love them for what they are.
all I was asking was if there was anyone interested in those sorts of things working on anything SNES related.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 02, 2008 7:31 am Post subject: |
|
Another WIP, this one's really just for myself to look over at work tomorrow.
Changed any.hpp again to not auto upcast fundamental types, as it
causes problems such as downcasting references to long doubles and
such. Sucks how limited the any type is by forced casting 100% of the
time, but whatever ... no endian issues possible now, at least.
I added property.hpp and bound that to the Audio class (not to Video or
Input yet). It's a lot more complicated than the old integral
identifier cap/get/set functions, but I need the char*-named list
functionality to allow changing driver-specific settings from the GUI
one day. Not too much done there yet. Need to work on it more, I'd like
to make bconfig use property.hpp rather than the IntegerSetting +
StringSetting classes. Tried to make property.hpp read in a config file
without bstring, talk about pain ... ugh.
Tried to move bstring into nall, failed miserably. When strcpy(char*,
const char*) is in the global namespace and strcpy(string&, const
char*) is not, the compiler gets angry. Not going to work. Really
should go object-oriented entirely and ditch libc functions, but ...
that's a lot of code rewriting on my part. Need to think about it more first.
Removed bbase.h dependency from bstring, miu and xkas. Now I just need
to do something about bkeymap.h, and things will be looking a lot
better for code sanity.
Nach wrote the seventh(!!)
libco driver tonight, an implementation using setjmp / longjmp. Pretty
neat, overhead is ~20x, which puts it only slightly worse off than
Windows Fibers on my machine. Using it in bsnes slows the emulator down
by <1%, but it should be portable across all Unix-derivative systems
now. This means eg a PS3, Alpha, SPARC, etc port should be completely
doable now, just need someone to compile it.
Planning to position libco as a competitor to GNU Pth, so that leaves me with:
SDL -> vai
wxWidgets -> miu
GNU Pth and pthreads -> libco
boost and Loki -> nall
std::string -> bstring
Good times. Now I just need to register inventedhere.org for all of these libraries.
Quote: |
but it's pointless since the sound quality of the S-DSP isn't good enough to make a difference. |
The only thing we could possibly bypass would be the driver / API
resampling our audio (eg 32khz -> 44khz native). Running each SNES
channel through its own hardware channel is just silly. Either use an
API that bypasses the mixer, or don't.
And yes, there's lots of ways to "enhance" the audio. Replacing
gaussian with a higher end interpolation, bypassing the clipping, etc.
But then you end up with "better" (in most cases), but less accurate
sound.
Quote: |
is anyone currently working on an enhancement snes emu? |
ZSNES adds cubic spline audio interpolation, SNES9x adds "hi-res"
mode7, ZSNES/XBOX adds rumble pad support to most games.
Other than smaller things like that, not really.
I've talked about adding things like rumble, a new MMC to map more than
64mbits, CD-audio and video playback capabilities. Nobody seemed all
that interested. Eh, maybe if someone finds and sends me one of those
SNES CD player addons used by that one English teaching game, I'll add
support for that to bsnes and then rig something like Der Langrisser to
use it :P
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 02, 2008 8:04 am Post subject: |
|
excellent,
it's about 2 factors away from possible at this point, but you could
backport the enhanced parts from the Saturn enhanced version.
any one have a remote idea as to where to even begin searching for the
cd thing? ebay? talking to private collectors? Anybody got any info on
it? I'm willing to do some research but I've never even heard of it.
I'm assuming since it was teaching english it was only used in Japan, so I should be looking for "Super Famicom" +CD
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 02, 2008 12:03 pm Post subject: |
|
byuu wrote: |
This means eg a PS3, Alpha, SPARC, etc port should be completely doable now, just need someone to compile it. |
Even though I don't actually own a PS3, I'd love to see bsnes on it.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 02, 2008 2:30 pm Post subject: |
|
It would be highly ironic, wouldn't it? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 02, 2008 3:00 pm Post subject: |
|
byuu wrote: |
GNU Pth and pthreads -> libco
|
pthreads serves a completely different purpose, and apps that are
designed for true threading don't want to use libco or GNU Pth.
I also wouldn't say that instead of using boost, one should use nall
when the available features are completely different. It's like saying
don't buy any products whatsoever from general motors because I happen
to have better tires than general motors has (and the only thing I
produce is tires and coffee).
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 02, 2008 3:11 pm Post subject: |
|
I.S.T. wrote: |
It would be highly ironic, wouldn't it? |
What would be ironic about that? Granted, one could question why, given
I don't have a PS3 , but I fail to see any irony.
Anyway, I don't have a PS3, but I might very well get one in the future so...
Advantage
of running bsnes (0.027) on a PS3 (well, any console for that matter
but older generations consoles obviously wouldn't have the raw
horsepower to run it anyway)
-PS3 should be more than enough to run it fullspeed
-Consoles are standard, meaning if it works on one, it should work on
every (non-defective) unit, unlike PCs which of course have a
quasi-infinite number of hardware/software configurations.
-Playing on a TV is a better environment for a Snes emulator imo (yes, I know opinion will vary)
-As was said before it might give bsnes more visibility.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 02, 2008 3:52 pm Post subject: |
|
Quote: |
any one have a remote idea as to where to even begin searching for the cd thing? |
Not a one. I've never even seen a picture of it before :(
Quote: |
pthreads serves a completely different purpose |
Oh, sorry. I thought it implemented cooperative threads as well.
Quote: |
I
also wouldn't say that instead of using boost, one should use nall when
the available features are completely different. It's like saying don't
buy any products whatsoever from general motors because I happen to
have better tires than general motors has (and the only thing I produce
is tires and coffee). |
Ouch, brutal but true. I was actually going to mention that it's really
no competition at all there, but really -- it's the same for every lib
I'm working on. wxWidgets has 100x the flexibility of miu, SDL runs on
cellphones, and boost::spirit alone is more complex than all of bsnes
and all its libraries combined. Even GNU Pth does a lot of signal stuff
and has a lot more functions (mostly trivial ones that an end user
could add to libco in five minutes.)
Still, I aim for exactly what I need. Nothing more, nothing less. So
it's not as if I miss having a YACC clone in bsnes by not using boost.
Lambda functions would be nice, though.
Quote: |
-PS3 should be more than enough to run it fullspeed |
Hopefully, we can just barely get 60fps on a 2GHz PowerPC 5 for the
Mac, so a 3.2GHz PowerPC should be well more than enough. But, time
will tell. The total lack of video acceleration is really going to hurt
things on the PS3. Can't use OpenGL most likely, and we probably won't
even have an Xv adapter. GTK+ video rendering is painfully slow.
Last edited by byuu on Wed Jan 02, 2008 3:53 pm; edited 1 time in total
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 02, 2008 3:53 pm Post subject: |
|
the irony comes from how the playstation got its' start... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 02, 2008 4:21 pm Post subject: |
|
byuu wrote: |
Hopefully, we can just barely get 60fps on a 2GHz PowerPC 5 for the
Mac, so a 3.2GHz PowerPC should be well more than enough. But, time
will tell. The total lack of video acceleration is really going to hurt
things on the PS3. Can't use OpenGL most likely, and we probably won't
even have an Xv adapter. GTK+ video rendering is painfully slow. |
I was going to ask about that. Obviously, we've seen an snes9x build
working on the PS3, so it's still possible apparently to use software
only. There has been some work on tapping into the RSX for linux,
though.
http://forums.ps2dev.org/viewforum.php?f=27
Unfortunately, my linux knowledge is so poor that I don't know half the
things these people are saying. Maybe they've already achieved a
limited driver bsnes can use? What is Xv?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 02, 2008 5:20 pm Post subject: |
|
byuu wrote: |
Quote: |
any one have a remote idea as to where to even begin searching for the cd thing? |
Not a one. I've never even seen a picture of it before 
Quote: |
pthreads serves a completely different purpose |
Oh, sorry. I thought it implemented cooperative threads as well.
Quote: |
I
also wouldn't say that instead of using boost, one should use nall when
the available features are completely different. It's like saying don't
buy any products whatsoever from general motors because I happen to
have better tires than general motors has (and the only thing I produce
is tires and coffee). |
Ouch, brutal but true. I was actually going to mention that it's really
no competition at all there, but really -- it's the same for every lib
I'm working on. wxWidgets has 100x the flexibility of miu, SDL runs on
cellphones, and boost::spirit alone is more complex than all of bsnes
and all its libraries combined. Even GNU Pth does a lot of signal stuff
and has a lot more functions (mostly trivial ones that an end user
could add to libco in five minutes.)
Still, I aim for exactly what I need. Nothing more, nothing less. So
it's not as if I miss having a YACC clone in bsnes by not using boost.
Lambda functions would be nice, though.
Quote: |
-PS3 should be more than enough to run it fullspeed |
Hopefully, we can just barely get 60fps on a 2GHz PowerPC 5 for the
Mac, so a 3.2GHz PowerPC should be well more than enough. But, time
will tell. The total lack of video acceleration is really going to hurt
things on the PS3. Can't use OpenGL most likely, and we probably won't
even have an Xv adapter. GTK+ video rendering is painfully slow.
|
I suppose that's what the SPUs are for... 
Seriously, though, there is progress on the RSX front: http://forum.beyond3d.com/showthread.php?t=45511
You know, when I typed up the sentence, I hadn't gotten the link yet.
The similarity between my title and theirs is eerie...
Edit: Fuck, I was beaten to it!
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 02, 2008 6:39 pm Post subject: |
|
byuu wrote: |
Hopefully, we can just barely get 60fps on a 2GHz PowerPC 5 for the
Mac, so a 3.2GHz PowerPC should be well more than enough. But, time
will tell. The total lack of video acceleration is really going to hurt
things on the PS3. Can't use OpenGL most likely, and we probably won't
even have an Xv adapter. GTK+ video rendering is painfully slow. |
No video acceleration...basically equivalent of running XP without any
gfx drivers installed and performing the most basic task like moving
windows around takes forever? If so, then yeah I would imagine that
would kill the performance.
Hopefully that won't be an issue and a solution will be found. Would be really sad not be able to harness the power of the PS3 /end commercial when we know it's obviously there because of some driver issues.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 02, 2008 7:08 pm Post subject: |
|
Quote: |
Would be really sad not be able to harness the power of the PS3 |
Sony is most likely terrified that people are going to find a way to
rig Linux to boot PS3 ~40GB game ISOs / BluRay RW disks (that cost more
than games themselves). Those kinds of people probably already have the
system mod-chipped anyway. And of course, there's a million ways to
give full hardware control to the Linux OS without allowing this to
happen (eg lockout only a decryption chip from Linux).
But that's Sony for you. Their locking down of the Linux port isn't at all surprising from a company that habitually
treats their customers like criminals and shits all over them. Yes, hi
rootkit music CDs. Hi PSP firmware. Hi BD-ROM+. Not that this stops
people from lining up to throw money at them any chance they get. Hell,
even I bought a PSP recently (and only because I was able to hack the firmware to run homebrew emulators. Pocket SNES is very nice.)
To be honest, I was really surprised they allowed Linux to boot at all.
But I suppose "it's also a computer" is a great selling point --
nevermind that without video acceleration you're better off with an
XBOX 1 (at 1/6th the cost) for a home PC. Who knows, maybe they'll kill
off Linux support after another revision or two, like they did with the
PS2 by removing the internal hard drive capability.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 02, 2008 10:25 pm Post subject: |
|
If
it's true that they're terrified, one has to wonder why they even
bothered with linux at all. They could have easily locked out the
capability a la 360. There's no telling what the real reasons are, or
if linux was simply an afterthought. We could try to rationalize what
it is and probably fail, since we can also rationalize how DRM doesn't
prevent piracy, but companies continue to convince themselves
otherwise. If you look back to the NES and SNES days, however, you did
have quite a few companies circumventing licensing fees and releasing
unlicensed carts (more popular in some countries than others). Sony may
not want to create an alternative gaming platform on their own system.
They make the least amount of money from hardware out of any of the
console companies, so profits from the licensing process are rather
important. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Jan 02, 2008 10:39 pm Post subject: |
|
Quote: |
Really
cool! My only concern is the use of Win32-specific code (header,
GetForegroundWindow(), HDC stuff, setting up the pixel format stuff)
... no idea how this is going to compile on Linux 
I don't know the Linux equivalents to all of the Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have the
Win version finished. Thanks a million for making this  |
Hhehehe, I researched the Linux and Mac equivalents for the Windows specific code (God bless NeHe Productions
), so the problems with Win32 hacks shouldn't be a issue. Plus, with me
acquiring a decent Allendale E4500 class Core 2 Duo CPU tommorrow,
working on BSNES and testing my code should be much less painful than
it is now
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 02, 2008 11:46 pm Post subject: |
|
mudlord wrote: |
Quote: |
Really
cool! My only concern is the use of Win32-specific code (header,
GetForegroundWindow(), HDC stuff, setting up the pixel format stuff)
... no idea how this is going to compile on Linux 
I don't know the Linux equivalents to all of the Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have the
Win version finished. Thanks a million for making this  |
Hhehehe, I researched the Linux and Mac equivalents for the Windows
specific code (God bless NeHe Productions
), so the problems with Win32 hacks shouldn't be a issue. Plus, with me
acquiring a decent Allendale E4500 class Core 2 Duo CPU tommorrow,
working on BSNES and testing my code should be much less painful than
it is now
|
Would you mind reporting how well that runs? I plan on buying an Allendale based CPU myself.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Jan 03, 2008 12:08 am Post subject: |
|
Sure, I will when I install it and do some intensive work with it  |
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Thu Jan 03, 2008 1:16 am Post subject: |
|
This is off-topic, but the Nouveau
project have a couple of people working on getting hardware
acceleration working on the PS3 nVidia GPU... Check their TiNDC
newsletter. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 03, 2008 3:51 am Post subject: |
|
Quote: |
Sony may not want to create an alternative gaming platform on their own system. |
Yeah, that's probably true as well. Wouldn't want people able to
publish games without charging your licensing fees. Geez, what's next?
Selling your hardware for profit?
Quote: |
Would you mind reporting how well that runs? I plan on buying an Allendale based CPU myself. |
A 2.2GHz Core 2 should get roughly ~100-120fps. But then, we shall see :)
Quote: |
This
is off-topic, but the Nouveau project have a couple of people working
on getting hardware acceleration working on the PS3 nVidia GPU... Check
their TiNDC newsletter. |
Oh great, so at their current pace, we may have basic accelerated OSS
nVidia drivers shortly before the last remaining PS3 hardware in
existence fails due to old age. Hoorah!
Sorry, I don't mean to be such a pessimist lately, I really respect
what they're doing, but if you've been following their progress as much
as I have ... it's really quite depressing. They really only have a few
really primitive ops working on the oldest NV chipsets, after all of
this time :(
And it looks like I was right about ATI, too. They've still only
released information on modesetting registers. Just enough lip service
for the publicity of being OSS friendly. Hooray, now we can implement
what VESA has been able to do for the past ten years. Yeah, keep
expecting the rest of the specs "real soon now" ...
And Intel still won't make standalone video cards for those who want to support them :(
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Thu Jan 03, 2008 2:21 pm Post subject: |
|
Intel is going to be entering that market in late 2008/some time in 2009. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Jan 03, 2008 4:07 pm Post subject: |
|
I.S.T. wrote: |
Intel is going to be entering that market in late 2008/some time in 2009. |
---immediately postpones buying new PC to see how the video card market is affected----
not that I have the money now anyways 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 03, 2008 4:59 pm Post subject: |
|
Quote: |
---immediately postpones buying new PC to see how the video card market is affected---- |
Not much. Intel won't be competing with nVidia and ATI for horsepower.
And with Linux only making up ~2% of the market (if that), I don't
expect them to make too big of an impact on anything but maybe the
low-end of the market.
Myself, I don't really need 3D acceleration. I don't play any 3D games
for that. So in this case, I'd rather support the company that provides
driver source code.
I have problems with nVidia's binary drivers. For one, they have a
cheap hack that disables XV_SYNC_TO_VBLANK whenever compositing is
enabled, which is to work around a bug in Beryl. I kid you not. So if I
want smooth mplayer or bsnes video, I have to turn off compositing.
Two, nVidia's driver has always had problems with XFCE's menus.
Whenever I navigate menus, the windows appear as garbled graphics for
1-3 frames before being visible. It's more of an annoyance than
anything else.
I'd be very happy to replace my nVidia card with an Intel one about now.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Jan 03, 2008 6:06 pm Post subject: |
|
byuu wrote: |
But that's Sony for you. Their locking down of the Linux port isn't at all surprising from a company that habitually
treats their customers like criminals and shits all over them. Yes, hi
rootkit music CDs. Hi PSP firmware. Hi BD-ROM+. Not that this stops
people from lining up to throw money at them any chance they get. Hell,
even I bought a PSP recently (and only because I was able to hack the firmware to run homebrew emulators. Pocket SNES is very nice.)
|
I remember back in 1999 I purchased one of Sony's more expensive,
high-end model DVD players for about $500. This player had so much
lockout protection built-in, you could ONLY
play region one commercial movies on it. Any attempt to play home video
discs or discs with mp3s would result in the player rejecting the
discs. I was so disgusted by this, I went out and purchased a cheap-ass
$70 dvd player that played everything, including DVDRs and CDRs.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 03, 2008 7:19 pm Post subject: |
|
I just use my computer to play DVDs, so that I can bypass region coding.
I love the way our legal systems allow region coding. Sure, if a
company wants to send our jobs overseas (to save money), hey that's
just free trade. But if a person wants to obtain a product overseas (to
save money or otherwise), that's somehow a huge problem which companies
are free to impede us from doing -- legally, with the DMCA.
It's particularly ironic with game consoles that sell at a loss. This
just forces one to buy the same console twice, or lures them toward a
modchip, which will likely entice them to stop paying for software all
together. I guess you can sort of see one reason why the PS3 has no
region coding, and the Wii does. |
|
ArtVandelae New Member
Joined: 03 Jan 2008
Posts: 4
|
Posted: Thu Jan 03, 2008 7:26 pm Post subject: |
|
FirebrandX wrote: |
I remember back in 1999 I purchased one of Sony's more expensive,
high-end model DVD players for about $500. This player had so much
lockout protection built-in, you could ONLY
play region one commercial movies on it. Any attempt to play home video
discs or discs with mp3s would result in the player rejecting the
discs. I was so disgusted by this, I went out and purchased a cheap-ass
$70 dvd player that played everything, including DVDRs and CDRs. |
You bought an earlier-gen DVD player from a major company and were
upset that it was region locked (as any player from a major brand is)
and didn't play formats that it wasn't advertised to play?
Also, being unable to read -R media was fairly common amongst players
from many manufacturers in that era. The Toshiba SD-2109 player I
bought in 1999 won't play CD-R/RW or DVD+-R/RW media, nor will my
cousin's high-end Denon player from the same year. It was simply a
matter of the laser units used in some models not being able to read
these types of media.
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Jan 03, 2008 9:03 pm Post subject: |
|
This
may be WOT, but, I also find killing the region-lock very satisfying; I
can play Japanese DVDs just fine on a normal DVD ROM
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Jan 04, 2008 1:42 am Post subject: |
|
yeah
the DS is region free but not the Wii, hopefully they'll fix that next
system around. They also promised VGA support but that's nowhere to be
seen from Nintendo. Although there is (ironically enough) an import
company that is selling a VGA adapter, still, I was a little upset to
not see a port on the system itself after all the advertising they did
for it post launch "you can play it on your computer monitor" --my ass
you can.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Fri Jan 04, 2008 1:49 am Post subject: |
|
wasn't the wii theoretically supposed to be region-free when the system was announced back in early 2005?
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Jan 04, 2008 2:20 am Post subject: |
|
neo_bahamut1985 wrote: |
wasn't the wii theoretically supposed to be region-free when the system was announced back in early 2005? |
yes
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Jan 04, 2008 3:39 am Post subject: |
|
Let's get back to the audio discussion.
Something that would be really interesting to see in bsnes [or any other emulator] is an ASIO sound output option.
One of the PCSX2 programmers (GigaHerz) has already done this by
creating the first SPU plugin in history to use ASIO output,so PCSX2
became the first emulator with ASIO output.
Many of you think of ASIO output as a feature reserved only for
pro/semi-pro soundcards.Well,that's not the case anymore.Things have
changed a lot lately.
Now the only thing one has to do is install a tiny freeware ASIO driver available at www.asio4all.com and your audio chipset gets ASIO support with almost native performance.
Works with almost all cards: from the crappiest of crap onboard
chipsets,integrated onboard "HD" audio,to gaming soundcards,semi-pro
and pro audio systems.The best thing is this one supports 32kHz (or
lower) and has a built-in resampler,unlike any other ASIO driver.
Works on all 32-bit MS OSes,even on Vista 32-bit by utilizing WaveRT.
So,by using this plugin,you'll get the benefits of bit-perfect
output,avoid the crappy resampling of onboard chipsets/shitty
soundcards and the best part: get rid of the high sound latency that
plagues every emulator with DSound output.
(the latency is an order of magnitude lower)
There are a couple of drawbacks,though:
1. Other apps that use other APIs for sound output (like
DirectSound,WaveOut,OpenAL,etc.) won't be able to output sound while
bsnes is running,but how many of you do other things when using bsnes
with a gamepad? So it's not a big deal anyway 
2. It requires a CPU that can handle bsnes and still have a bit of
spare CPU time left for the ASIO thread.ASIO output is not stable with
very high CPU loads (> 85%).
Having this will be more useful than separate channels for the S-DSP.
(although in PS1/PS2/DC emulators this would be much more useful -
beat/music/dancing games where timing is critical need this badly)
Even by using OpenAL over DirectSound there will be a noticable
improvement.It's not nearly as good as ASIO,but a lot better than
DSound.
OpenAL output should be the default,since it works better with slower CPUs/high loads.
EDIT: updated
_________________
Have a nice kick in da nutz @~@*
Last edited by kick on Fri Jan 04, 2008 10:19 am; edited 9 times in total |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Jan 04, 2008 3:56 am Post subject: |
|
ArtVandelae wrote: |
You bought an earlier-gen DVD player from a major company and were
upset that it was region locked (as any player from a major brand is)
and didn't play formats that it wasn't advertised to play?
Also, being unable to read -R media was fairly common amongst players
from many manufacturers in that era. The Toshiba SD-2109 player I
bought in 1999 won't play CD-R/RW or DVD+-R/RW media, nor will my
cousin's high-end Denon player from the same year. It was simply a
matter of the laser units used in some models not being able to read
these types of media. |
Except that, as I mentioned in my post, I was able to go out and buy a
cheap dvd player that did play all those other disc formats. That's
what disgusted me at the time. That I could spend $500 dollars for
limited access, or $100 for unlimited access. Also, I didn't much care
about the region encoding at the time, it was more the protection
against playing non-commercial discs that pissed me off.
One thing I do have against region encoding is often times there are
movies from overseas places like Japan that never see the light of day
for a US release. So its either find a way around the region encoding,
or never see the movie.
BTW, Computer drives also try that region shit too. The last DVD drive
I purchased for one of my computers warned me it was going to switch to
a specific region code based on whatever discs I played after so many
uses.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Jan 04, 2008 4:15 am Post subject: |
|
i think firebrand should check out dvdfab...
_________________
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. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Fri Jan 04, 2008 4:20 am Post subject: |
|
yeah,
that's good software, being able to change the region without screwing
up the DVD ROM. Too bad one can't find that kind of DVD software for
free...
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Jan 04, 2008 6:37 am Post subject: |
|
kick wrote: |
Let's get back to the audio discussion.
Something that would be really interesting to see in bsnes [or any
other emulator] is an ASIO sound output option.
One of the PCSX2 programmers (GigaHerz) has already done this by
creating the first emulator plugin in history to use ASIO output (PCSX2
became the first emulator with ASIO output).
Many of you thought ASIO output was only reserved for pro/semi-pro
soundcards.Well,that's not the case anymore.Things have changed a lot
lately.
Now the only thing you need to do is install is a tiny freeware ASIO driver available at www.asio4all.com and your audio chipset gets ASIO support with almost native performance.
Works with almost all cards: from the crappiest of crap onboard
chipsets,integrated onboard "HD" audio,to gaming soundcards,semi-pro
and pro audio systems.The best thing is it supports 32kHz output and
has a built-in resampler,unlike any other ASIO driver.
Works on all MS OSes,even on Vista by utilizing WaveRT.
So,by using this plugin,you'll get the benefits of bit-perfect
output,avoid the crappy resampling of onboard chipsets/shitty
soundcards and the best part: get rid of the high sound latency that
plagues every emulator with DSound output.
(the latency is an order of magnitude lower)
The only drawback is other apps that use other APIs for sound output
(like DirectSound,WaveOut,OpenAL,etc.) won't be able to output sound
while bsnes is running,but how many of you do other things when using
bsnes with a gamepad? So it's not a big deal anyway  |
Sounds very interesting, I'd be curious to know what byuu think about this.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Jan 04, 2008 6:50 am Post subject: |
|
ditto
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Fri Jan 04, 2008 8:33 am Post subject: |
|
[EDIT] Updated with even more info.See previous post.
_________________
Have a nice kick in da nutz @~@* |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Jan 04, 2008 10:14 am Post subject: |
|
Quote: |
Sounds very interesting, I'd be curious to know what byuu think about this. |
Yeah, ASIO support would be great for vai, then it can be a true SDL
killer...Though, its all up to byuu though to decide if its worth it.
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Jan 04, 2008 11:59 am Post subject: |
|
Quote: |
A 2.2GHz Core 2 should get roughly ~100-120fps. But then, we shall see  |
..You were 100% spot on. Average FPS of around 100, going up to 120 in
places on the games I tested. Of course, with the NTSC filter, there's
quite a speed hit (like, in the 80's), but still, the speed is
perfectly fine, and the games are extremely playable with the chip.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Jan 04, 2008 12:40 pm Post subject: |
|
About games with chips.
I still miss support for those extension chips that some really good
games uses. If we get crazy framerates like 120 FPS, then maybe it is
time to add support for them. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Jan 04, 2008 1:31 pm Post subject: |
|
henke37 wrote: |
About games with chips.
I still miss support for those extension chips that some really good
games uses. If we get crazy framerates like 120 FPS, then maybe it is
time to add support for them. |
Refer to past discussion. From what was said, even a Pc that could
reach 150+ fps would probably crawl with Sa-1 or SuperFX support.
You can simply use Zsnes for now (or just get the real carts)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jan 04, 2008 3:11 pm Post subject: |
|
I
remember byuu talked about offloading the graphics filtering onto a
second processor core (or indeed the GPU if OGL support was added), but
saying this wouldn't be easy and that it was a long term objective..
maybe the same could be done for ASIO support? Since then, bsnes has
been restructured, the GUI rewritten and all sorts of work done on its
libraries and drivers, so perhaps it would be easier now.. (but that
could be wishful thinking) |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Fri Jan 04, 2008 3:48 pm Post subject: Sound Latency |
|
Hiya byuu,
Happy new years =D
I have been doing tests on my ubuntu 7.10 with your new WIP's and I
must say the new sound code is a vast improvement, (I am using openal
because of the problems I read about using oss with unbuntu).
I was wondering if the ability to change the sound latency still exists
in the bsnes configuration. It used to have a seperate option for this
set at "75", but all I can find now is a system.audio setting that may contain this, I was wondering what are the options for this configuration setting.
The reason I am asking is because I would like to test bsnes at
different audio latencies on my system, to see if I can find any magic
numbers that work well on my system which currently needs frameskip 1
to get perfect sound in linux, although looking at the framerates it
should be full speed at frameskip zero, which crackles alot...
If the option does not exist any more at all, where is the sound latency stated in the bsnes source code?
Cheers for all of your help, here's to another exciting year for bsnes  |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Jan 04, 2008 4:33 pm Post subject: |
|
Apparently
we can no longer include the SPC ROM in our sources because this is
against some copyright allegedly according to debian. So I was thinking
we either put the ROM in it's own file or we disassemble the current
code and make an assembler for it. This would be fine according to them
if we had source for the current ROM. What is your take on this. It
would be nice to have something that worked in all emulators since we
are all affected.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 04, 2008 5:58 pm Post subject: |
|
Quote: |
Sounds very interesting, I'd be curious to know what byuu think about this. |
Sure, the more drivers we can add, the better. Just need someone to help write the driver :)
The only thing is, I don't want keep vai statically linked. So with
each new module, it will add more DLL dependencies. My current idea
would be to make a bsnes lite, that has only stuff that would come with
a new install of Windows (D3D, DSound + DInput), and one that has all
of the drivers, but will require lots of other drivers first (OpenAL,
ASIO, etc.)
Quote: |
I still miss support for those extension chips that some really good games uses. |
I'm very slowly working on SuperFX support, but I don't know if I'll
ever get that working. To be honest, I haven't touched it in ~3 months
now.
Quote: |
I
remember byuu talked about offloading the graphics filtering onto a
second processor core (or indeed the GPU if OGL support was added) |
I really don't want to make bsnes multithreaded if I don't have to.
That brings in a whole new world of potential problems, the least of
which is portability. And I really, really don't want to make vai
multithreaded.
I am interested in OpenGL pixel shader support, though.
Quote: |
I was wondering if the ability to change the sound latency still exists in the bsnes configuration. |
Unfortunately not at this time. It was only supported by the
DirectSound driver, so I saw no reason to keep it there to confuse
people. I hope to make separate config files for each driver in the
future, and add a lot more options per driver then.
You can edit it by hand for now:
src/ui/vai/audio/audio.openal.cpp line 136:
buffer.size = device.latency * 32;
Make that smaller for lower latency.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 04, 2008 6:35 pm Post subject: |
|
Quote: |
Apparently
we can no longer include the SPC ROM in our sources because this is
against some copyright allegedly according to debian. So I was thinking
we either put the ROM in it's own file or we disassemble the current
code and make an assembler for it. This would be fine according to them
if we had source for the current ROM. What is your take on this. It
would be nice to have something that worked in all emulators since we
are all affected. |
My pessimism here isn't directed at you, pagefault. I thank you for
bringing this to my attention, in fact. However, this hits a sore spot
with me back from my dealings with MESS.
The IPLROM in its entirity is the size of an SHA-512 hash.
Yes, I know some braindead, prematurely born judge who had absolutely
no understanding whatsoever of technology declared that using Sony's
BIOS in VGS was illegal. However, even with that dipshit's ruling
(which can be used to effectively destroy emulation of all future
systems trivially), that applied to a very large BIOS full of
proprietary code.
The IPLROM, however, is not a traditional BIOS. It is a tiny bootstrap
loader that is absolutely required for the purposes of emulation. We
can't implement it using high level emulation, because games can read
the entire IPLROM right out of memory, and indeed they rely on it
functioning exactly as is. The ROM itself is not a complex program
designed by Nintendo, it's just a bootstrap that is required and built
into the actual SMP processor itself.
I believe the use of the IPLROM is legal, and ten years of emulators
using it without Nintendo or Sony ever asserting any legal objections
gives strong precedent in my favor (and yes, I realize the difference
between copyright and trademark assertion). Nonetheless, if a true
court case or takedown notice ever materializes, then (and only then)
might I reconsider my stance.
The only mistake you made was stating that this affects me as well: it
does not. I won't be a party to the stupidity of the MESS and Debian
developers. This is even more ridiculous than the MPAA going after
people posting one of the HD-DVD processing keys online. Any attempts
Nintendo or Sony make to outlaw IPLROM distribution will result in the
same exact thing: you'll end up with 100,000,000 Google hits for the
512-bit stream.
If you want to cripple your product unnecessarily to appease these
morons, be my guest. You'll have an emulator that cannot play anything
at all after running "apt-get install zsnes". It'll only result in more
users switching from ZSNES to "the emulator that just works without all
those crazy BIOS files." -- be it SNES9x, bsnes or ZSNES++ UDXP SE
Pro^2.
Nonetheless, if you want to work out some sort of standardized BIOS
approach (we can share the design for the DSP-n data ROMs, at least),
catch me on Freenode sometime. I'll throw a few ideas at you.
Last edited by byuu on Sun Jan 06, 2008 6:40 pm; edited 4 times in total
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Jan 04, 2008 7:12 pm Post subject: |
|
If we are going to try to do the no really illegal data scheme, can't we use a classic like those illegal primes? |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Fri Jan 04, 2008 8:35 pm Post subject: |
|
byuu wrote: |
src/ui/vai/audio/audio.openal.cpp line 136:
Code: |
buffer.size = device.latency * 32;
|
|
What the magic number "32" is? And what the measure for latency ? samples or milliseconds or magic multipliers:?
....
After trying to hardcode all known OpenAL hints that comes to my mind I found 512 samples (16 ms )
for all 16 hardware stereo streams working stable for me. The problem
is in high processor loading when almost every bit of interruption or
even breeze of it causes "sandy" sound.
We need to increase sound plugin thread priority, up to high or realtime. This will allow to half the latency.
byuu wrote: |
The only thing is, I don't want keep vai statically linked. So with
each new module, it will add more DLL dependencies. My current idea
would be to make a bsnes lite, that has only stuff that would come with
a new install of Windows (D3D, DSound + DInput), and one that has all
of the drivers, but will require lots of other drivers first (OpenAL,
ASIO, etc.)
|
My thought exactly. I do not understand why useless OpenAL libs gets linked. It is not hard to load yourself :
Code: |
#define GPA(a) GetProcAddress(hInstOpenAL, a);
HINSTANCE hInstOpenAL;
pAudioOpenAL(AudioOpenAL &self_) : self(self_)
{
settings.frequency = 192000;
memset(device_source, 0, sizeof(device_source));
device_handle = 0;
device_context = 0;
device_latency = 1024; //latency in samples
device_queue = 0;
memset(sample_buffer, 0, sizeof(sample_buffer));
sample_buffer_size = device_latency;
sample_buffer_filled = 0;
hInstOpenAL = LoadLibrary("OpenAL32.dll");
if (hInstOpenAL)
{
// Binds our AL function pointers to the appropriate AL stuff
alcOpenDevice = (LPALCOPENDEVICE)GPA("alcOpenDevice");
alcCloseDevice = (LPALCCLOSEDEVICE)GPA("alcCloseDevice");
alcCreateContext = (LPALCCREATECONTEXT)GPA("alcCreateContext");
alcDestroyContext = (LPALCDESTROYCONTEXT)GPA("alcDestroyContext");
alcMakeContextCurrent = (LPALCMAKECONTEXTCURRENT)GPA("alcMakeContextCurrent");
alcProcessContext = (LPALCPROCESSCONTEXT)GPA("alcProcessContext");
alcSuspendContext = (LPALCSUSPENDCONTEXT)GPA("alcSuspendContext");
alcGetCurrentContext = (LPALCGETCURRENTCONTEXT)GPA("alcGetCurrentContext");
alcGetContextsDevice = (LPALCGETCONTEXTSDEVICE)GPA("alcGetContextsDevice");
alcGetString = (LPALCGETSTRING)GPA("alcGetString");
alcGetIntegerv = (LPALCGETINTEGERV)GPA("alcGetIntegerv");
alcGetError = (LPALCGETERROR)GPA("alcGetError");
alcIsExtensionPresent = (LPALCISEXTENSIONPRESENT)GPA("alcIsExtensionPresent");
alcGetProcAddress = (LPALCGETPROCADDRESS)GPA("alcGetProcAddress");
alcGetEnumValue = (LPALCGETENUMVALUE)GPA("alcGetEnumValue");
alDistanceModel = (LPALDISTANCEMODEL)GPA("alDistanceModel");
alBufferData = (LPALBUFFERDATA)GPA("alBufferData");
alDeleteBuffers = (LPALDELETEBUFFERS)GPA("alDeleteBuffers");
alDeleteSources = (LPALDELETESOURCES)GPA("alDeleteSources");
alDisable = (LPALDISABLE)GPA("alDisable");
alEnable = (LPALENABLE)GPA("alEnable");
alGenBuffers = (LPALGENBUFFERS)GPA("alGenBuffers");
alGenSources = (LPALGENSOURCES)GPA("alGenSources");
alGetBoolean = (LPALGETBOOLEAN)GPA("alGetBoolean");
alGetBooleanv = (LPALGETBOOLEANV)GPA("alGetBooleanv");
alGetBufferf = (LPALGETBUFFERF)GPA("alGetBufferf");
alGetBufferi = (LPALGETBUFFERI)GPA("alGetBufferi");
alGetDouble = (LPALGETDOUBLE)GPA("alGetDouble");
alGetDoublev = (LPALGETDOUBLEV)GPA("alGetDoublev");
alGetEnumValue = (LPALGETENUMVALUE)GPA("alGetEnumValue");
alGetError = (LPALGETERROR)GPA("alGetError");
alGetFloat = (LPALGETFLOAT)GPA("alGetFloat");
alGetFloatv = (LPALGETFLOATV)GPA("alGetFloatv");
alGetInteger = (LPALGETINTEGER)GPA("alGetInteger");
alGetIntegerv = (LPALGETINTEGERV)GPA("alGetIntegerv");
alGetListener3f = (LPALGETLISTENER3F)GPA("alGetListener3f");
alGetListenerf = (LPALGETLISTENERF)GPA("alGetListenerf");
alGetListenerfv = (LPALGETLISTENERFV)GPA("alGetListenerfv");
alGetListeneri = (LPALGETLISTENERI)GPA("alGetListeneri");
alGetProcAddress = (LPALGETPROCADDRESS)GPA("alGetProcAddress");
alGetSource3f = (LPALGETSOURCE3F)GPA("alGetSource3f");
alGetSourcef = (LPALGETSOURCEF)GPA("alGetSourcef");
alGetSourcefv = (LPALGETSOURCEFV)GPA("alGetSourcefv");
alGetSourcei = (LPALGETSOURCEI)GPA("alGetSourcei");
alGetString= (LPALGETSTRING)GPA("alGetString");
alIsBuffer= (LPALISBUFFER)GPA("alIsBuffer");
alIsEnabled=(LPALISENABLED)GPA("alIsEnabled");
alIsExtensionPresent= (LPALISEXTENSIONPRESENT)GPA("alIsExtensionPresent");
alIsSource= (LPALISSOURCE)GPA("alIsSource");
alListener3f= (LPALLISTENER3F)GPA("alListener3f");
alListenerf= (LPALLISTENERF)GPA("alListenerf");
alListenerfv= (LPALLISTENERFV)GPA("alListenerfv");
alListeneri= (LPALLISTENERI)GPA("alListeneri");
alSource3f= (LPALSOURCE3F)GPA("alSource3f");
alSourcef= (LPALSOURCEF)GPA("alSourcef");
alSourcefv= (LPALSOURCEFV)GPA("alSourcefv");
alSourcei= (LPALSOURCEI)GPA("alSourcei");
alSourcePause= (LPALSOURCEPAUSE)GPA("alSourcePause");
alSourcePausev= (LPALSOURCEPAUSEV)GPA("alSourcePausev");
alSourcePlay= (LPALSOURCEPLAY)GPA("alSourcePlay");
alSourcePlayv= (LPALSOURCEPLAYV)GPA("alSourcePlayv");
alSourceQueueBuffers= (LPALSOURCEQUEUEBUFFERS)GPA("alSourceQueueBuffers");
alSourceRewind= (LPALSOURCEREWIND)GPA("alSourceRewind");
alSourceRewindv= (LPALSOURCEREWINDV)GPA("alSourceRewindv");
alSourceStop= (LPALSOURCESTOP)GPA("alSourceStop");
alSourceStopv= (LPALSOURCESTOPV)GPA("alSourceStopv");
alSourceUnqueueBuffers= (LPALSOURCEUNQUEUEBUFFERS)GPA("alSourceUnqueueBuffers");
}
}
~pAudioOpenAL()
{
if (hInstOpenAL)
{
term();
FreeLibrary(hInstOpenAL);
}
}
|
_________________
quake2xp audio engineer
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Jan 04, 2008 10:41 pm Post subject: |
|
Hi,
"stupid" MESS developer here. I really don't understand your problem
with the various IPLs and data ROMs. It's not any harder to code, it
gives you ironclad legal protection, it saves a bit of bandwidth on
distribution, and it's good software engineering practice. And since
stupid old me's supported the SPC700 and DSP1 ROMs for a while in the
most popular non-commercial emulator on the planet (MAME), most users
probably already have 'em. I'll add DSP3 and 4 too if you want 
(No, I don't actually take offense at byuu's statement, I know how he
is. But as usual someone PM'ed me trying to start an emu-author-war so
I'm having a little Friday afternoon fun with it). |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Jan 04, 2008 11:11 pm Post subject: |
|
Quote: |
I am interested in OpenGL fragment shader support, though. |
Heheheh, I have been experimenting with this in VBA-M, and it shouldn't
be that hard to add to the OpenGL renderer. Only requirement is that we
render directly the pixel output to a OGL texture, then fragment shader
handling is all easy from there. Plus, byuu, since you already have
texture support in your D3D renderer, HLSL shader support can be added
too. Though, your optional rendering to a surface might hinder that
somewhat, since post-processing surfaces is more complex than post
processing textures of course.
Anyway, I posted the OpenGL renderer code earlier, so if anyone wants
to improve it, be my guest. It needs quite a bit of work still, since
its pretty prelim.
Now that I can run BSNES quite comfortably though with Vsync and the
OpenAL sound renderer, things should be loads easier for me to test,
and work on.
Side note: "Pixel" shaders in D3D, are "fragment" shaders in OpenGL.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Jan 04, 2008 11:34 pm Post subject: |
|
mudlord wrote: |
Side note: "Pixel" shaders in D3D, are "fragment" shaders in OpenGL. |
What about vertex shaders? A lot of the shaders out there also depend upon them, although my own so far haven't.
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Jan 04, 2008 11:55 pm Post subject: |
|
"fragment
shader" is actually the original correct computer science term, but
"pixel shader" works better when explaining to nontechnical people why
they need to buy a $250 graphics card "Vertex shader" is the same usage everywhere. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Jan 05, 2008 12:03 am Post subject: |
|
To
avoid confusion (and I guess my quote wasn't very good), I was asking
whether those would also be implemented, since it wasn't mentioned in
mudlord's post. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 05, 2008 12:03 am Post subject: |
|
Quote: |
It is not hard to load yourself <snip> |
Messy, and I'd need to wrap GetProcAddress with whatever Linux' equivalent is. Meh.
Quote: |
Plus,
byuu, since you already have texture support in your D3D renderer, HLSL
shader support can be added too. Though, your optional rendering to a
surface might hinder that somewhat, since post-processing surfaces is
more complex than post processing textures of course. |
The StretchRect mode is just a minor speedup for cards that support if.
If we can get HLSL shaders working with the texture model, I'll just
drop the StretchRect mode and use the triangle strip mode only. But
once again, I'm not sure how to add such things. I could learn, but I'm
kind of busy at the moment refactoring a lot of my core libraries and
such.
Quote: |
Hi, "stupid" MESS developer here. I really don't understand your problem with the various IPLs and data ROMs. |
Ah, you already know I wasn't referring to you; and I didn't say stupid
-- I said stupidity, implying this particular decision was stupid.
Quote: |
(No,
I don't actually take offense at byuu's statement, I know how he is.
But as usual someone PM'ed me trying to start an emu-author-war so I'm
having a little Friday afternoon fun with it). |
Hahah, yes. I believe most people just refer to me as having no "tact,"
or something like that. Luckily those who matter understand this about
me and don't take offense ;)
No, it isn't hard to code around, but it is damn annoying to an end user (ref).
I don't intend to make life more difficult for end users, because I'm
worried about a one in a million chance that I might get a C&D one
day. It's impossible to avoid all legalities. Hell, linked lists are
technically patented right now. And if Nintendo really wanted to pick a
fight with any of us, they could tie us up in the court system until we
were buried with legal debts for the rest of our lives -- even if we
were innocent. Sony showed how well this could work with Bleem!
Again, I really think it's a mistake to cripple our emulators over a
64-byte chunk of data. I don't want to be a party to this. But if
everyone else follows suit, you'll likely force my hand to participate,
as I don't want the unfair advantage of being the only emulator capable
of playing games without BIOS files.
And what is it about everyone trying to start "omg emu wars!!!!!" all
the time? Geez. People need to comprehend this already -- there is no
competition when every emulator is open source already.
My apologies for causing someone to bug you (again).
Last edited by byuu on Sun Jan 06, 2008 6:40 pm; edited 2 times in total
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Jan 05, 2008 1:33 am Post subject: |
|
Note: IANAL...
byuu wrote: |
Quote: |
Apparently
we can no longer include the SPC ROM in our sources because this is
against some copyright allegedly according to debian. So I was thinking
we either put the ROM in it's own file or we disassemble the current
code and make an assembler for it. This would be fine according to them
if we had source for the current ROM. What is your take on this. It
would be nice to have something that worked in all emulators since we
are all affected. |
My pessimism here isn't directed at you, pagefault. I thank you for
bringing this to my attention, in fact. However, this hits a sore spot
with me back from my dealings with MESS.
|
Don't be hating on Debian - I know that traditionally the emulation
scene has taken a fairly lax attitude towards copyright, but even
though Nintendo doesn't seem to care care the law still cares, and
Debian is trying hard to obey the law even if it seems crazy to you or
I.
The law only cares about "who wrote this thing" and "was this thing
derived from another thing, or is this thing original". So including
the IPLROM is an infringement (because it's an exact copy of Nintendo's
work), and dissassembling the current code and including an assembler
is infringement (because it's derived from Nintendo's work) and
including an obfuscated version as per byuu's sarcastic suggestion is
also infringement (because, yes, it's still directly derived from
Nintendo's work).
byuu wrote: |
The IPLROM in its entirity is the size of an SHA-512 hash. |
That sounds like the best defense: if you can argue that given the
instruction-set, the task required and the space-constraint, that
there's no other way to write the code in the ROM and hence there's no
creative expression involved, then I suspect you could argue that the
IPLROM is uncopyrightable and hence not a problem.
byuu wrote: |
The
IPLROM, however, is not a traditional BIOS. It is a tiny bootstrap
loader that is absolutely required for the purposes of emulation. We
can't implement it using high level emulation, because games can read
the entire IPLROM right out of memory, and indeed they rely on it
functioning exactly as is. The ROM itself is not a complex program
designed by Nintendo, it's just a bootstrap that is required and built
into the actual SMP processor itself. |
Here's an idea: find someone with assembly-language skills who hasn't
seen the IPLROM, give them a copy of the instruction set, tell them
what the code should do and the 64-byte limit, and get them to figure
out a way to achieve it. Once they do, then either you have a very
similar byte-stream that proves the original IPLROM was trivial, or you
have a new, copyright-free clean-room re-implementation. Win!
byuu wrote: |
The
only mistake you made was stating that this affects me as well: it does
not. I won't be a party to the stupidity of the MESS and Debian
developers. |
I guess my point is that what you call "stupidity" might be more
accurately termed "putting legal concerns before technical concerns",
and just because technical concerns are more important for a hobbyist
like yourself, doesn't mean they should be for everyone else.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Jan 05, 2008 1:46 am Post subject: |
|
Quote: |
The
StretchRect mode is just a minor speedup for cards that support if. If
we can get HLSL shaders working with the texture model, I'll just drop
the StretchRect mode and use the triangle strip mode only. But once
again, I'm not sure how to add such things. I could learn, but I'm kind
of busy at the moment refactoring a lot of my core libraries and such. |
I'll see about taking a look into this.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 05, 2008 1:49 am Post subject: |
|
Quote: |
Don't be hating on Debian |
Now why would I hate on the distro that brought us Iceweasel? :P
Quote: |
Here's
an idea: find someone with assembly-language skills who hasn't seen the
IPLROM, give them a copy of the instruction set, tell them what the
code should do and the 64-byte limit, and get them to figure out a way
to achieve it. Once they do, then either you have a very similar
byte-stream that proves the original IPLROM was trivial, or you have a
new, copyright-free clean-room re-implementation. Win! |
In the absolute best case, you can swap three or four instructions, and
remove the reset vector that emulators do not use (it may also be "di :
stop", but that makes less sense. A) there was no matching "ei", and B)
the code is unreachable anyway,) however there is one glaring problem
with this, and the judge in the VGS case was too inept to realize it:
Games have full access on most platforms to read the BIOS ROMs. In
fact, this is how these ROMs are dumped. So, what's to stop Sony or
Nintendo from requiring each game to store a bit-for-bit copy of the
BIOS, and compare their copy to the copy on the hardware? If it's not
identical, refuse to play the game. Now, emulators are helpless. They
can't perform game-specific hacks (as that shows willful intent to use
the emulator for piracy and negates the debugger / homebrew defense),
and they can't match what the games expect because that data is
copyrighted.
Even if we store a rewritten IPLROM, it's still not technically
accurate to hardware. And that's a very important concern for me.
And if we're going to start considering tiny blocks of 64-byte data as
copyrighted ... where does it end? What about when we need arrays to
emulate certain hardware concepts that approximate 64-bytes of data,
and they also exist on the hardware implementation -- such as maybe
gaussian interpolation tables, frequency rate tables, "fuzzy" sin/cos
tables, etc? How about 16-byte IPLROMs? How about the initialization
sequences of memory?
Quote: |
I
guess my point is that what you call "stupidity" might be more
accurately termed "putting legal concerns before technical concerns",
and just because technical concerns are more important for a hobbyist
like yourself, doesn't mean they should be for everyone else. |
Yeah, as Arbee said, I'm just being my typical self. I'm always overly
cynical and hostile toward things I dislike. Basically, I'm the Theo de
Raadt of the emulation scene :P
Ultimately, I respect MESS' decision not to use the ROMs, and they know
that. But that doesn't mean I'm going to agree with them, and I'll try
my hardest not to let pagefault and co follow suit with them. I don't
think my argument would be as convincing if I sugar coated it to avoid
hurting anyone's feelings.
Maybe we should run a poll to see what the actual users think about
needing an IPLROM to play their games. With all the fun ZSNES had with
graphics packs, I'm sure requiring an IPLROM will be an absolute blast
for them.
Quote: |
I'll see about taking a look into this. |
Thanks, you're the best!! :D
Three cheers for mudlord!
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Sat Jan 05, 2008 3:32 am Post subject: |
|
Byuu,
you've managed to reverse engineer the behavior of a lot of SNES
hardware based on tests you've written, and based on the behavior of a
lot of games.
You could probably work out a way to get a clean-room implementation that's fully legal. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 05, 2008 3:42 am Post subject: |
|
DataPath wrote: |
Byuu,
you've managed to reverse engineer the behavior of a lot of SNES
hardware based on tests you've written, and based on the behavior of a
lot of games.
You could probably work out a way to get a clean-room implementation that's fully legal. |
If I understood correctly...
-Some games may require the exact match of the "bios"
-Given the incredible small size of that thing, there's very little room to make a (viable) alternative
-Even if you could make the above two points a non-issue, one could argue it goes against "true" emulation.
If it has to come to this, I'd rather download the damn thing already.
I figure it would be the same file needed for MESS's Snes emulation
anyway. edit: or rip it from my Snes lol I don't think you could do that with just a Snes and a copier, though.
|
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Sat Jan 05, 2008 4:00 am Post subject: |
|
byuu wrote: |
wertigon wrote: |
This
is off-topic, but the Nouveau project have a couple of people working
on getting hardware acceleration working on the PS3 nVidia GPU... Check
their TiNDC newsletter. |
Oh great, so at their current pace, we may have basic accelerated OSS
nVidia drivers shortly before the last remaining PS3 hardware in
existence fails due to old age. Hoorah!
Sorry, I don't mean to be such a pessimist lately, I really respect
what they're doing, but if you've been following their progress as much
as I have ... it's really quite depressing. They really only have a few
really primitive ops working on the oldest NV chipsets, after all of
this time
|
The situation isn't all that bad... Progress is being made, it's just
that writing unified graphics drivers is a gargantuan undertaking.
They've been focusing on accellerating the 2D right now, but since
that's more or less getting done (yes, done, as in "everything works
from nv01 and up" done, with the exception of a couple of fringe cases)
they'll put in much more work on the 3D drivers.
Hopefully, the next year will see some real progress in that area. But,
you're right that it's not as good as could be, yet. (And yes, I'm
tracking it fairly close too - Or, well, I subscribe to their TiNDC
newsletter).
[edit]Oh, and sorry for such an offtopic post... Didn't realize that
the thread had gotten so far. I blame Opera's long caching limits. [/edit]
Last edited by wertigon on Sat Jan 05, 2008 4:09 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jan 05, 2008 4:04 am Post subject: |
|
If
Nintendo wastes its resources on anyone, it's going to be emulators for
commercially available systems. Until that happens, you probably have
zero reason to be concerned about an SNES BIOS... So why not wait until
there is reason to be concerned? Or does Debian not care?
I never realized Linux was so rife with drama. The audio API argument just about made my head explode. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 05, 2008 4:29 am Post subject: |
|
FitzRoy wrote: |
If Nintendo wastes its resources on anyone, it's going to be emulators for commercially available systems. |
I suppose it could be argued the Snes WIIs a commercially available system
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Jan 05, 2008 4:29 am Post subject: |
|
Quote: |
What about vertex shaders? A lot of the shaders out there also depend upon them, although my own so far haven't. |
They, will of course, will be considered in the implementation. due to the very reason you said.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 05, 2008 4:41 am Post subject: |
|
Quote: |
You could probably work out a way to get a clean-room implementation that's fully legal. |
I certainly could. But it won't be bit-accurate to hardware unless it's
exact. I could probably even get a clean-room perfect copy of the
IPLROM, too. But nobody would care. They'd still claim the 64 bytes
were copyrighted. I wonder if anyone even knows who the true owner of
that "copyright" is -- I sure don't.
Quote: |
They've
been focusing on accellerating the 2D right now, but since that's more
or less getting done (yes, done, as in "everything works from nv01 and
up" done, with the exception of a couple of fringe cases) |
Really? That's good to hear. If they get the 2D working really well,
and enough to do very basic OpenGL stuff, I'll switch over. From what
I've heard, they still don't have XVideo at all. That's a big
requirement for me. If only my time weren't stretched so thin, it would
be nice to help these projects out rather than complain all the time.
Quote: |
Or does Debian not care? |
Trust me, they don't care.
Quote: |
I never realized Linux was so rife with drama. The audio API argument just about made my head explode. |
Oh, all of Linux is a picnic like that. But I love it anyway, so I'm
determined to get my Linux software working as good as my Windows
software. It's really unfortunate that most Linux emulator ports just
give you an SDL window with either no GUI or a raster GUI.
You just have to learn to ignore the drama (hah, that coming from me of
all people). Pretty much no distro will make an official bsnes package
due to the license, but at the same time I don't have to worry about
all of their different restrictions like ZSNES is facing with Debian
about its IPLROM now.
I may just go back to FreeBSD myself. Ports may not be as convenient as
apt-get, but there's really no drama there at all. Not about license
ideologies (excepting Theo's recent GPL backlash, but that's just Theo
being himself), not about which OS is the best, not about whether their
task scheduler is O(1) or O(n) ... it's just there.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Jan 05, 2008 1:24 pm Post subject: |
|
Snark wrote: |
FitzRoy wrote: |
If Nintendo wastes its resources on anyone, it's going to be emulators for commercially available systems. |
I suppose it could be argued the Snes WIIs a commercially available system
|
I guess that's true. I still think that they would go after DS emulators or something first.
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Sat Jan 05, 2008 3:48 pm Post subject: |
|
byuu wrote: |
I certainly could. But it won't be bit-accurate to hardware unless it's
exact. I could probably even get a clean-room perfect copy of the
IPLROM, too. But nobody would care. They'd still claim the 64 bytes
were copyrighted. I wonder if anyone even knows who the true owner of
that "copyright" is -- I sure don't. |
Debian is probably the only non-commercial linux distro that maintains a legal team and actually listens to them.
And the lawyers would be satisfied by the documentation involved in a clean-room implementation.
And yes, I agree that there's a decent chance you could probably get a
perfect implementation (I think you said that there are three
instructions that could be reasonably re-ordered?). The iterative
process of arriving at that point, making adjustments according to
what's needed to make things work, without the foreknowledge of the
copyright material is what's needed.
Patents prevent people from using an idea, even if arrived at completely independently.
Copyright allows you to have the same idea, but you'd darned well
better be able to show that you weren't in the least inspired by the
other guy.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 05, 2008 5:34 pm Post subject: |
|
Quote: |
And the lawyers would be satisfied by the documentation involved in a clean-room implementation.
And yes, I agree that there's a decent chance you could probably get a
perfect implementation (I think you said that there are three
instructions that could be reasonably re-ordered?). The iterative
process of arriving at that point, making adjustments according to
what's needed to make things work, without the foreknowledge of the
copyright material is what's needed. |
Alright then, I'm certainly willing to try it. Obviously I can't do it
myself, but I can write SNES S-CPU tests that verify what happens in
the IPLROM, explain how it works in general, and try and walk someone
else through producing the same thing.
For instance, a simple S-SMP app can verify the stack reset behavior
and range. S-CPU counter tests can verify when the S-SMP writes to
certain ports. With that filled in, there's no more room for variance,
and someone should be able to clone the IPLROM.
Now, if that's good enough for Debian, would it be good enough for MESS?
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 05, 2008 5:40 pm Post subject: |
|
byuu wrote: |
Quote: |
And the lawyers would be satisfied by the documentation involved in a clean-room implementation.
And yes, I agree that there's a decent chance you could probably get a
perfect implementation (I think you said that there are three
instructions that could be reasonably re-ordered?). The iterative
process of arriving at that point, making adjustments according to
what's needed to make things work, without the foreknowledge of the
copyright material is what's needed. |
Alright then, I'm certainly willing to try it. Obviously I can't do it
myself, but I can write SNES S-CPU tests that verify what happens in
the IPLROM, explain how it works in general, and try and walk someone
else through producing the same thing.
For instance, a simple S-SMP app can verify the stack reset behavior
and range. S-CPU counter tests can verify when the S-SMP writes to
certain ports. With that filled in, there's no more room for variance,
and someone should be able to clone the IPLROM.
Now, if that's good enough for Debian, would it be good enough for MESS?
|
Could you still had an option to load the original (external) spc700 "bios"?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 05, 2008 6:33 pm Post subject: |
|
Quote: |
Could you still had an option to load the original (external) spc700 "bios"? |
I wouldn't use a clean-room implementation unless it was 100% identical
to the original, so there wouldn't be any need.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Jan 05, 2008 10:05 pm Post subject: |
|
Right right, just decide on the file name of the bytes and let the build system take care of embedding it somehow.
If people don't want to distribute the code, let them.
But if you want to, do your distribution with the code. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 06, 2008 5:29 am Post subject: |
|
byuu wrote: |
Quote: |
Could you still had an option to load the original (external) spc700 "bios"? |
I wouldn't use a clean-room implementation unless it was 100% identical
to the original, so there wouldn't be any need.
|
Ok I'm an idiot, but I just don't get it. If something is effectively
100% identical how could that shield you (or any emulators authors)
from whatever legal/copyright problems you could get into before?
When you say 100% identical, do you mean only in terms of function, or in terms of raw byte sequence?
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Jan 06, 2008 7:15 am Post subject: |
|
Snark wrote: |
byuu wrote: |
Quote: |
Could you still had an option to load the original (external) spc700 "bios"? |
I wouldn't use a clean-room implementation unless it was 100% identical
to the original, so there wouldn't be any need.
|
Ok I'm an idiot, but I just don't get it. If something is effectively
100% identical how could that shield you (or any emulators authors)
from whatever legal/copyright problems you could get into before?
|
It would document that there's only one way to do it.
Quote: |
When you say 100% identical, do you mean only in terms of function, or in terms of raw byte sequence? |
byuu means in terms of raw byte sequence.
Though he's made the argument that there's probably not many different ways to do it in 64 bytes.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 06, 2008 7:34 am Post subject: |
|
Gil_Hamilton wrote: |
Snark wrote: |
byuu wrote: |
Quote: |
Could you still had an option to load the original (external) spc700 "bios"? |
I wouldn't use a clean-room implementation unless it was 100% identical
to the original, so there wouldn't be any need.
|
Ok I'm an idiot, but I just don't get it. If something is effectively
100% identical how could that shield you (or any emulators authors)
from whatever legal/copyright problems you could get into before?
|
It would document that there's only one way to do it.
Quote: |
When you say 100% identical, do you mean only in terms of function, or in terms of raw byte sequence? |
byuu means in terms of raw byte sequence.
Though he's made the argument that there's probably not many different ways to do it in 64 bytes.
|
If this titanic-ely huge 64-byte sequence ends up being the same...how
could you prove you came up with the same result on your own? (without
going in complicated technical explanations that is... which no judge
would be competent enough to get anyway) And most importantly: does it
actually matter legally?
I've always thought, legally speaking, it was the end results that
mattered, regardless of how you got there (that is, if something is
copyrighted) And it's starting to fall in the realm of philosophy. I
mean, if file or data sequence A is in every point identical to data
sequence B, then they're effectively the same afaic.
I've always thought in reverse engineering cases there has to be SOME
end result differences for one to be shielded legally.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jan 06, 2008 7:59 am Post subject: |
|
Snark wrote: |
If
this titanic-ely huge 64-byte sequence ends up being the same...how
could you prove you came up with the same result on your own? (without
going in complicated technical explanations that is... which no judge
would be competent enough to get anyway) And most importantly: does it
actually matter legally?
I've always
thought, legally speaking, it was the end results that mattered,
regardless of how you got there (that is, if something is copyrighted)
And it's starting to fall in the realm of philosophy. I mean, if file
or data sequence A is in every point identical to data sequence B, then
they're effectively the same afaic.
I've always thought in reverse engineering cases there has to be SOME
end result differences for one to be shielded legally. |
As mentioned earlier, therein lies the difference between patents and
copyright. To patents, only the end result matters, whereas in
copyright all one has to do is prove you arrived at a result
independently. In this case, since the piece of code is so short, you
could probably even fake it by writing up some elaborate documentation
of a supposed cleanroom approach you took
This fact alone makes it rather hard to prove, I imagine.. possibly the
only way to do it right would involve a legal representative watching
the process and confirming everything happened as it was supposed to.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Jan 06, 2008 8:08 am Post subject: |
|
Snark wrote: |
If this titanic-ely huge 64-byte sequence ends up being the same...how
could you prove you came up with the same result on your own? (without
going in complicated technical explanations that is... which no judge
would be competent enough to get anyway) And most importantly: does it
actually matter legally?
I've always thought, legally speaking, it was the end results that
mattered, regardless of how you got there (that is, if something is
copyrighted) And it's starting to fall in the realm of philosophy. I
mean, if file or data sequence A is in every point identical to data
sequence B, then they're effectively the same afaic.
I've always thought in reverse engineering cases there has to be SOME
end result differences for one to be shielded legally. |
Unless there's no room for differences.
If there's only one way to do it, than it's not copyrightable.
Copyrights are for works of creativity. There's no creativity involved if there's only one way to do it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 06, 2008 8:38 am Post subject: |
|
Ah I see. Thanks both for the explanation. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sun Jan 06, 2008 9:28 am Post subject: |
|
I started to rework the Direct3D renderer...
I found a few bugs in vertex handling, namely with vertex[0], which
should be 0.00 instead of 1.00. Hopefully you guys can notice a
difference. I also started to weed out the StretchRect stuff, too.
http://vba-m.ngemu.com/bsnes.rar |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jan 06, 2008 10:13 am Post subject: |
|
mudlord wrote: |
I started to rework the Direct3D renderer...
I found a few bugs in vertex handling, namely with vertex[0], which
should be 0.00 instead of 1.00. Hopefully you guys can notice a
difference. I also started to weed out the StretchRect stuff, too.
http://vba-m.ngemu.com/bsnes.rar |
Too bad it does not work in systems that have DirectX8 or older (the same goes for byuu's releases)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jan 06, 2008 2:08 pm Post subject: |
|
DirectX
9 can be installed even on Windows 98, atleast according to Microsoft's
DirectX web installer download page (they might be wrong).. if there
are any Windows 95 users out there, they're probably used to having to
switch to DDraw by now.. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jan 06, 2008 2:16 pm Post subject: |
|
Verdauga Greeneyes wrote: |
DirectX
9 can be installed even on Windows 98, atleast according to Microsoft's
DirectX web installer download page (they might be wrong).. if there
are any Windows 95 users out there, they're probably used to having to
switch to DDraw by now.. |
"IF" you have admin rights, which i do not on this pc...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jan 06, 2008 2:44 pm Post subject: |
|
tetsuo55 wrote: |
"IF" you have admin rights, which i do not on this pc... |
Fair enough, well OpenGL support is coming soon anyway, and from the same guy!
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sun Jan 06, 2008 2:58 pm Post subject: |
|
New test build: http://vba-m.ngemu.com/bsnes2.rar
Quote: |
DirectX
9 can be installed even on Windows 98, atleast according to Microsoft's
DirectX web installer download page (they might be wrong).. if there
are any Windows 95 users out there, they're probably used to having to
switch to DDraw by now.. |
Well, a D3D8 renderer should be possible to implement, if one implements that..
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Jan 06, 2008 3:23 pm Post subject: |
|
Verdauga Greeneyes wrote: |
DirectX
9 can be installed even on Windows 98, atleast according to Microsoft's
DirectX web installer download page (they might be wrong).. if there
are any Windows 95 users out there, they're probably used to having to
switch to DDraw by now.. |
of course it can, but support was dropped fairly early in there bi-monthly scheme of 9.0c updates.
_________________
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.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Jan 06, 2008 4:31 pm Post subject: |
|
How can i force ddraw mode? as bsnes refuses to run it also doesn't create a config file |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jan 06, 2008 4:33 pm Post subject: |
|
Thanks
byuu, that might work, but we will be switching to ROMs as well if we
have to. Although I don't really care personally, but I have to please
these people who have demands against 64 byte blobs of code. I am sure
it would never have been a problem if we never said it was ROM code,
they said some of the tables in DSP-1 were a problem but we argued with
them and showed them the source of the tables so they eventually
dropped that issue. But they were pretty much questioning every
pre-initialized array we had. Rather ridiculous.
I
just wanted to see what you had to say about it because I would like to
co-ordinate something everyone can use and is "ok" for debian. That way
they can't kick us all out.
_________________
Watering ur plants. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jan 06, 2008 5:11 pm Post subject: |
|
tetsuo55 wrote: |
How can i force ddraw mode? as bsnes refuses to run ... |
I believe that's something for byuu to look at. To quote him: "I'd like
to have vai init() functions return a boolean success value, and have
bsnes continue to fall back on lesser drivers until there are none
left, in which case it won't use one." So presumably future versions of
bsnes would fall back on DDraw (in Windows) automatically.
As for the option in the config file, I believe it's
system.video = "ddraw"
or possibly
system.video = "dd"
(I should look in the source code really)
but I don't know if bsnes accepts partial config files ...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 06, 2008 6:38 pm Post subject: |
|
Quote: |
I
found a few bugs in vertex handling, namely with vertex[0], which
should be 0.00 instead of 1.00. Hopefully you guys can notice a
difference. I also started to weed out the StretchRect stuff, too. |
Thanks for the bugfix. I suppose I'll go ahead and kill StretchRect,
then, so that we can make use of HLSL shaders one day.
EDIT: or not, framerate drops from ~121 to ~108 using textures instead
of StretchRect. Going to need to get the texture version a lot faster
if I'm going to replace it.
Quote: |
Thanks
byuu, that might work, but we will be switching to ROMs as well if we
have to. Although I don't really care personally, but I have to please
these people who have demands against 64 byte blobs of code. I am sure
it would never have been a problem if we never said it was ROM code,
they said some of the tables in DSP-1 were a problem but we argued with
them and showed them the source of the tables so they eventually
dropped that issue. But they were pretty much questioning every
pre-initialized array we had. Rather ridiculous. |
... you actually convinced them that using the 1,024 byte data ROMs was
okay, but failed to convince them that using a 64-byte IPLROM was? Wow
... just wow.
And why do you have to please them, exactly? It's your codebase.
Quote: |
I
just wanted to see what you had to say about it because I would like to
co-ordinate something everyone can use and is "ok" for debian. That way
they can't kick us all out. |
They already have ignored my code, and they consider SNES9x "non-free"
too, which is laughable at best. Is their approval really that
important to you? Just make a .deb file, and anyone who wants it can go
to zsnes.com, click download, double click the deb file and press
install.
And now you don't have to deal with the inevitable hundreds of bug reports that the new ZSNES "won't play any games anymore".
But in the worst case, your code is GPL'd already. If they want to
remove your IPLROM, let them. They can rename it DSNES, and share the
same market success as they did with Iceweasel, and leave you alone.
Luckily for me, they can't legally neuter my code.
---
Okay, here's some more information on the whole thing.
It's technically possible to make a very, very small number of changes
to the IPLROM. Most likely, we could even get 100% of software working
with such a rewrite. But it will never be the same ... any changes will
throw off timing. Timing is directly observable via the CPU inspecting
the S-SMP port registers and comparing values to the PPU latch counters.
Further, it's entirely possible for an SNES software program to read
back the IPLROM, compare it to an internally cached copy, and refuse to
run if they did not match exactly.
In fact, this situation would be 100% identical to some old IBM
software that refused to run unless the string "IBM CORPORATION" was
found. A company cloning it copied the string, because it was required,
and were sued for it. They won in court, obviously.
I tried my best to find a reference to this, but failed miserably. Anyone want to give it a try?
Also, http://en.wikipedia.org/wiki/Phoenix_BIOS
Quote: |
Because,
due to the nature of low-level programming, in two well-written pieces
of code that perform the same function some correspondence is
inevitable, it would be impossible for Phoenix to defend itself on the
grounds that no part of its BIOS matched IBM's. Phoenix developed a
"clean room" technique that isolated the Engineers who had been
contaminated by reading the IBM source listings in the IBM Technical
Reference Manuals. |
http://en.wikipedia.org/wiki/Clean_room_design
Quote: |
Sony
Computer Entertainment, Inc. v. Connectix Corporation was a 1999
lawsuit which established an important precedent in regard to reverse
engineering. Sony sought damages for copyright infringement over
Connectix's Virtual Game Station emulator, alleging that its
proprietary BIOS code had been copied into Connectix's product without
permission. Sony won the initial judgment, but the ruling was overturned on appeal.
Sony eventually purchased the rights to Virtual Game Station to prevent
its further sale and development. This established a precedent
addressing the legal implications of commercial reverse engineering
efforts.
Some works are closer to the core
of intended copyright protection than others. Sony's BIOS lay at a
distance from the core because it contains unprotected aspects that
cannot be examined without copying. The court of appeal therefore
accorded it a lower degree of protection than more traditional literary
works. |
And lastly, I'll go ahead and write up a technical summary of the
IPLROM. Technically, that summary should be approved by a lawyer to be
safe, but I doubt anyone here wants to shell out the money for that.
Then we just need to find someone who has never seen the IPLROM, and
have him try and implement it. Should be fun. Just to be safe, I'll
edit out the "SHA-512 hash" from earlier.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Jan 07, 2008 8:55 am Post subject: |
|
byuu wrote: |
And lastly, I'll go ahead and write up a technical summary of the
IPLROM. Technically, that summary should be approved by a lawyer to be
safe, but I doubt anyone here wants to shell out the money for that. |
just out of sheer curiosity how much would something like that even cost?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jan 07, 2008 9:18 am Post subject: |
|
I like the idea of an external BIOS file... cleaner design IMO.
Besides, anybody can download old emulator sources and type up the ROM into a hex editor.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Jan 07, 2008 1:09 pm Post subject: |
|
If the ROM data is the part of processor's chip logic, it's a hardware, not a software.
If that IPLROM external to processor, can be reflashed (or can be
written to a blank ROM), and would allow revisions, then it's a software.
_________________
quake2xp audio engineer |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Jan 07, 2008 1:58 pm Post subject: |
|
_willow_ wrote: |
If the ROM data is the part of processor's chip logic, it's a hardware, not a software.
If that IPLROM external to processor, can be reflashed (or can be
written to a blank ROM), and would allow revisions, then it's a software. |
And yet, both hardware and software can be copyrighted, and it would be
just as illegal to distribute copyrighted code that was burnt to ROM as
it would to distribute copyrighted code from a floppy disc.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Jan 07, 2008 3:07 pm Post subject: |
|
I
will admit I don't really care too much about the situation because
whatever they do they will just be hurting their own userbase in the
long run because they will not be offering the packages. I guess thats
why they don't offer webmin as well for some reason, I always had to
get that package myself.
_________________
Watering ur plants. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Jan 07, 2008 3:37 pm Post subject: |
|
1) both hardware and software can be copyrighted
yes, sure.
2) it would be just as illegal to distribute copyrighted code
very very likely
But:
Can i shot my snes on camera? Can i paint it's boards and chips on
paper, can i? Emulation software is NOT hardware, it's legal to do it
and share it like to say you sharing the paint of the copyrighted
hardware you bought. I'd say it's not legal to steal that paint too
unless you let it go. The ROM in question is a pure fiction i see, as
you can only guess is it true hardware or not. It's not legal to copy
carts but legal to dump it yourself. It's not legal to copy hardware
but legal to mimic it. The picture shown on the TV is yours and i can
do whatever i want with it, backup it, share it, because i do NOT
reproduce the hardware, just mimic at best 
::::summarize it::::
If THAT code is an integral part of the chip - it's NOT a code. You can
mimic the behaviour. Someone can say: wow - it's a Super Duper Mega
System Limited Edition v2.0! But it's not.
If THAT code is an independent ROM and you will be able to REPLACE it -
that is code. This code is real and not a fiction.
_________________
quake2xp audio engineer |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Jan 07, 2008 4:48 pm Post subject: |
|
you can't copyright hardware, thats what patents are for.
ROM data is copyrighted, how the ROM data is stored on that chip may
have been patented at some point. Simply because its read only does not
mean its hardware.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Jan 07, 2008 6:01 pm Post subject: |
|
funkyass wrote: |
Simply because its read only does not mean its hardware. |
Can you replace this "code" with your own on real SNES? Boot loaders
are not software until they cant be safely REPLACED. You can read it,
so what? By case it have sense as boot loader, so what?? You emulate
registers, tons of processing triggers, why do not emulate SOME data
sequence? Now try to tell me i have no right to read SOMETHING in
memory, to read something in registers. Simply i do not read something
i can Replace!! Do i have no right to use paid hardware and mimic it or
what? Then i can share mimic image because it's mine vision of the
hardware. Whats the difference between single register and registers
chain you calling ROM?
_________________
quake2xp audio engineer
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Jan 07, 2008 7:58 pm Post subject: |
|
_willow_ wrote: |
funkyass wrote: |
Simply because its read only does not mean its hardware. |
Can you replace this "code" with your own on real SNES? Boot loaders
are not software until they cant be safely REPLACED. You can read it,
so what? By case it have sense as boot loader, so what?? You emulate
registers, tons of processing triggers, why do not emulate SOME data
sequence? Now try to tell me i have no right to read SOMETHING in
memory, to read something in registers. Simply i do not read something
i can Replace!! Do i have no right to use paid hardware and mimic it or
what? Then i can share mimic image because it's mine vision of the
hardware. Whats the difference between single register and registers
chain you calling ROM?
|
by that logic, all software that comes on CDs is hardware as well.
Software has to be modifiable at some point in its existence, and it
obliviously was before it was written to ROM for mass production. Think
of it like this: ROM is cheap storage area for software that its makers
think works well enough not to be fixed.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 07, 2008 8:36 pm Post subject: |
|
Let's try a different approach to this argument to try and reach consensus.
How about, what constitutes the minimum size a work must be to be
copyrighted? Certainly, I can't write down "the sky is blue" and expect
to copyright that as an artistic work. Similarly, with the IPLROM being
as small as it is (much smaller than even this paragraph), could it
qualify as sufficiently complex enough to be copyrighted?
Or perhaps an example from Nach, what about if we think of the IPLROM
as the state of memory upon initialization? Much the same as the DSP-n
ROMs are nothing more than mathematical trigonometry tables and
constants, they form a necessary state that is needed for emulation.
Lastly, what about a C++ implementation of the IPLROM?
Code: |
void iplrom() {
enum smp_cpu_bridge_port { port0 = 0xf4, port1, port2, port3 };
extern indexed_ptr<uint8_t> ram[64 * 1024];
sp = x = 0xef;
a = 0x00;
do { ram[x--] = a; } while(x);
ram[port0] = 0xaa;
ram[port1] = 0xbb;
while(ram[port0] != 0xcc);
goto wait_;
do {
while(!(y = ram[port0]));
do {
if(y == ram[port0]) {
a = ram[port1];
ram[port0] = y;
ram[ram<uint16_t>[0x00] + y++] = a;
if(y) continue;
ram[0x01]++;
if(ram[0x01] < 0x80) continue;
}
} while(uint8_t(y - ram[port0]) < 0x80);
wait_:
ya = ram<uint16_t>[port2];
ram<uint16_t>[0x00] = ya;
ya = ram<uint16_t>[port0];
ram[port0] = a;
x = a = y;
} while(x);
goto ram<uint16_t>[x];
static uint16_t reset_vector = 0xffc0;
} |
Last edited by byuu on Mon Jan 07, 2008 9:21 pm; edited 1 time in total
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Jan 07, 2008 9:07 pm Post subject: |
|
64
bytes is also 512 bits. I can paint the head of a pin black and get a
copyright on it. Size isn't a good metric for that argument.
Its not a question of that it should be covered under a copyright or a
patent, its really a question of can you provide enough evidence that
the Debian Foundation won't be party to any possible lawsuits stemming
from it, and Debian is free to be as inconsistent as they want on the
issue.
In short, I'd not bother with getting into the debian repositories, and actually request zsnes's removal from them.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 07, 2008 9:37 pm Post subject: |
|
Quote: |
64
bytes is also 512 bits. I can paint the head of a pin black and get a
copyright on it. Size isn't a good metric for that argument. |
I don't personally believe that to be true. I would assume there has to
be some artistic expression, just as patents are required to be
non-obvious (I know there are awful patents out there ...)
If such a simple act could be copyrighted, it would bring commerce to a
standstill, as everyone would be suing everyone for everything. "I'm
sorry, a wizard named Merlin was my idea. Nevermind you wrote a
400-page story that just so happened to share that trait. You can't
make a wizard with that name for ~150 years without paying me
royalties, kthxbye."
Quote: |
In short, I'd not bother with getting into the debian repositories, and actually request zsnes's removal from them. |
I strongly agree here. To hell with Debian. We've had this IPLROM for
the last twelve years. At the very least, if Sony cares at all, they
can send us a C&D order and I'm sure we'll all stop using it then
(or consult our lawyers.) Until then, they're probably having a good
time laughing at us for all of this pointless infighting. Personally, I
think Sony knows better from their damaging legal precedents set by
their losses against Connectix.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Jan 07, 2008 9:41 pm Post subject: |
|
funkyass wrote: |
64
bytes is also 512 bits. I can paint the head of a pin black and get a
copyright on it. Size isn't a good metric for that argument. |
copyright.gov wrote: |
What is not protected by copyright?
[...]
- Works
consisting entirely of information that is common property and
containing no original authorship (for example: standard calendars,
height and weight charts, tape measures and rulers, and lists or tables
taken from public documents or other common sources)
|
While it's true that size isn't listed as a primary criterion, the
argument we're trying to establish is 'the IPLROM contains no original
authorship because given the constraints there's no possible
alternative implementation', and one of the major constraints involved
is size.
(note that the quotation above from copyright.gov also explains why DSP
ROM data should be safe - anyone can precalculate a sine table and get
the same results independently, it's not an original creative work)
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Jan 07, 2008 11:17 pm Post subject: |
|
funkyass wrote: |
by that logic, all software that comes on CDs is hardware as well.
Software has to be modifiable at some point in its existence, and it
obliviously was before it was written to ROM for mass production. Think
of it like this: ROM is cheap storage area for software that its makers
think works well enough not to be fixed.
|
You do not follow me. I can burn CD with equal data. It's a software. I
can flash motherboard BIOS because it is a software. BIOS is not pure
loader and can have some variations. But it have some points that can't
be changed in any way, because those parts are loaders.
For example, i read bios mirror from RAM\ROM whatever you like and it
says "Nvadia XXL" for some provider string. How can i mimic this? I
should say "Nvadia XXL" on the same place to make sure software believe
in it. You have no alternatives, so it's a key. Not a software. Key is
not software. Like fingertips tells almost nothing about persons they
belong. Initialisation sequence is not software. That "soft" was
existed before chip becomes "hard". If the loader can't be replaced
it's not software. IT MAY LOOK LIKE CODE, but it's a key. Otherwise you
will get "is the sky blue", because you have only 4 words to say 'the'
'sky' 'is' 'blue'. The result is predefined.
_________________
quake2xp audio engineer
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Jan 08, 2008 4:21 am Post subject: |
|
Non-obvious
is iffy, the best evidence for such must come before the patent was
filed. Non-obvious is simply not "there is only one way to do
something", but "more than one person already knew how to do it".
The entire point behind the patent system was to reward people who developed that one way of doing something.
Going to court is not cheap, and neither are Lawyers during litigation.
Debian, like most sane people, do not want to pay their lawyers more
than they have to. At the end of the day, the issue over authorship
over the IPLROM will have to be settled in court, a judge has to rule
over any potential evidence given to make anything legal fact.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Jan 08, 2008 4:27 am Post subject: |
|
_willow_ wrote: |
You do not follow me. I can burn CD with equal data. It's a software. I
can flash motherboard BIOS because it is a software. BIOS is not pure
loader and can have some variations. But it have some points that can't
be changed in any way, because those parts are loaders.
For example, i read bios mirror from RAM\ROM whatever you like and it
says "Nvadia XXL" for some provider string. How can i mimic this? I
should say "Nvadia XXL" on the same place to make sure software believe
in it. You have no alternatives, so it's a key. Not a software. Key is
not software. Like fingertips tells almost nothing about persons they
belong. Initialisation sequence is not software. That "soft" was
existed before chip becomes "hard". If the loader can't be replaced
it's not software. IT MAY LOOK LIKE CODE, but it's a key. Otherwise you
will get "is the sky blue", because you have only 4 words to say 'the'
'sky' 'is' 'blue'. The result is predefined. |
you are in over your head on this. You cannot convert software into
hardware logic. hardware logic cannot be "read".
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 08, 2008 6:06 am Post subject: |
|
So,
I replaced bkeymap.h with nall/keymap.hpp. That leaves one last holdout
from my old unsorted misc libraries, but a lot of the nall/ ones are
still really ugly and need cleaning. Anyway, the new keymap code is
very, very experimental, and it changes some key names. In the process,
I realized that I still had some really old joypad code in
inputmgr.cpp, which would've prevented a second joypad from working
with bsnes. Seems nobody out there has ever played with a friend using
bsnes to notice :(
Oh well, that's fixed now. But
virtually all of my input handling code is just ... shit. Absolute
shit. Ugh. It all needs to be cleaned up and rewritten :(
Oh, with strip -s + upx -9, I got bsnes.exe down to ~250kb. Hoorah! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 7:51 am Post subject: |
|
byuu wrote: |
Seems nobody out there has ever played with a friend using bsnes to notice :( |
Friend? What's that? Seriously, nowadays, no one plays emulators with
someone else unless it's over the net so that would probably explain it.
|
|
Rydian Lurker

Joined: 02 Jul 2007
Posts: 156
Location: Virginia
|
Posted: Tue Jan 08, 2008 8:12 am Post subject: |
|
byuu wrote: |
Seems nobody out there has ever played with a friend using bsnes to notice  |
It's okay, I still <3 you.
_________________
AMD K6-2 @ 475mhz
312MB Memory
SiS 530 Integrated Graphics, 8MB
I tried fitting in here, but I care too much about feelings. Maybe it's
why the gay member asked me for my IM info...
By the way, your legs are still not safe.
|
|
Rydian Lurker

Joined: 02 Jul 2007
Posts: 156
Location: Virginia
|
Posted: Tue Jan 08, 2008 8:13 am Post subject: |
|
Snark wrote: |
byuu wrote: |
Seems nobody out there has ever played with a friend using bsnes to notice  |
Friend? What's that? Seriously, nowadays, no one plays emulators with
someone else unless it's over the net so that would probably explain it.
|
Actually,
I've gathered a few people and played bomberman 3/4/5 a couple of
times. Got a couple of cheap 8-button genesis-looking control pads at
walmart, decided to use them.
Forgot them when I moved. o_<;
_________________
AMD K6-2 @ 475mhz
312MB Memory
SiS 530 Integrated Graphics, 8MB
I tried fitting in here, but I care too much about feelings. Maybe it's
why the gay member asked me for my IM info...
By the way, your legs are still not safe.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 08, 2008 8:34 am Post subject: |
|
yeah, a few years ago me and my friends used to crowd around the keyboard for bomberman.
itś been awhile but with some games I mess with the second player just
for the heck of it. Not so much with bsnes I guess, I don't know why
that is, it still isn't fullspeed on my current system but hopefully
I'll be upgrading sooner rather than later.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 9:48 am Post subject: |
|
Panzer88 wrote: |
yeah, a few years ago me and my friends used to crowd around the keyboard for bomberman.
itś been awhile but with some games I mess with the second player just
for the heck of it. Not so much with bsnes I guess, I don't know why
that is, it still isn't fullspeed on my current system but hopefully
I'll be upgrading sooner rather than later. |
Right now, I think the only thing missing in bsnes to be a true
mainstream emulator is true fullscreen support (post 0.020) and the
video options for NTSC filter 2.0 found in Nestopia (adjustment for
Fieldmerging, Scanlines, Resolution, Sharpness)
Yes, I know there has been some major rewrites which forced to disable
those features, but I'm just pointing it out. Hope it doesn't come as
begging as that's not my intention.
'Speed' is not so much a concern for me, because I know CPU will get faster over time.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 08, 2008 11:10 am Post subject: |
|
for
me it's soft patching and multi patch soft patching. also can you
really call screen stretching "true fullscreen" I suppose, but ack,
screen stretching.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 08, 2008 11:14 am Post subject: |
|
What is to be gained from a "true" fullscreen mode, exactly?
bsnes isn't mainstream because it doesn't have savestates and because
of the elevated status of the competition. Nearly every rom site on the
planet is outdated or treats ZSNES and SNES9x as the only emulators on
the planet worth offering. ZSNES is great, but the eager atmosphere is
such that many current sites give it an exuberant 10/10 legendary
perfect rating, sometimes going as far as to say "the only SNES
emulator you'll ever need." Course, if that were true, byuu would be
wasting his time, and I know nobody here believes that.
Last edited by FitzRoy on Tue Jan 08, 2008 11:19 am; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 11:18 am Post subject: |
|
Panzer88 wrote: |
for me it's soft patching and multi patch soft patching. |
I don't really understand the reason for emulators soft patching
honestly. How hard could it be to make a copy of a rom (keeping the
non-modified one intact) and "hard" patch this copy?
(put on his flame retardant suit)
|
|
Rydian Lurker

Joined: 02 Jul 2007
Posts: 156
Location: Virginia
|
Posted: Tue Jan 08, 2008 11:28 am Post subject: |
|
Because
I'm sure the people that make patches would rather edit a patch file
over and over instead of copying and deleting a copy of a rom and
running a patcher over and over?
Also, that suit will not protect your legs from humping.
_________________
AMD K6-2 @ 475mhz
312MB Memory
SiS 530 Integrated Graphics, 8MB
I tried fitting in here, but I care too much about feelings. Maybe it's
why the gay member asked me for my IM info...
By the way, your legs are still not safe. |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 11:29 am Post subject: |
|
FitzRoy wrote: |
What is to be gained from a "true" fullscreen mode, exactly? |
Because having the image fill the entire screen (on 4.3 display
devices. Not 16.9 of course, as that would look ass) is imo, better. In
fact, I still use 0.019 just for that reason (and for the video
adjustments that were previously available)
Quote: |
bsnes
isn't mainstream because it doesn't have savestates and because of the
elevated status of the competition. Nearly every rom site on the planet
is outdated or treats ZSNES and SNES9x as the only emulators on the
planet worth offering. |
That's true unfortunately. I think I might have mentioned this before
(or maybe I edited the comment I don't remember) but one notable french
r** site* still describe bsnes as "relatively new and as such, still
have low compatibility".
A joke to be sure, but heh. How many years did it takes for emulation
sites to stop saying "grab teh nesticles n0ws this is the l33t NES
emu!!1!" when superior Nes emulators were already available?
edit: I think French laws are more liberal in terms of hosting that
kind of content because I've seen many french r** site lasting many
years.
Last edited by Snark on Tue Jan 08, 2008 11:38 am; edited 2 times in total
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Jan 08, 2008 11:33 am Post subject: |
|
I
say, bundle a free home made code that does roughly the same thing and
let people who feel a need for the exact code hunt it down on their
favorite rom site. You can just add another flag in the rom info
database about if the game is incompatible with the free replacement.
- Most people won't care as long there is some code to do the work
- Copyright issues is left to those who run rom sites
- Runs out of the box.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 08, 2008 4:36 pm Post subject: |
|
Quote: |
true
fullscreen support (post 0.020) and the video options for NTSC filter
2.0 found in Nestopia (adjustment for Fieldmerging, Scanlines,
Resolution, Sharpness) |
True fullscreen is only so difficult due to the Linux port. I don't
have a method of setting the video mode there. It's also largely
impeded by the lack of a quality audio resampler to get smooth audio +
video.
And if the video tears anyway, there's no point in switching video
modes just to change the refresh rate. Plus, setting fullscreen
disables the menubar in all but Direct3D. And if I allow the menubar
with Direct3D, I can no longer page flip -- again negating the
usefulness of the mode :(
As for NTSC filter options ... alright, I promised blargg I'd add those
(a year ago ...), I'll bump this up on my list of things to do.
Note that his filter does not have scanline support (or does it?), he
leaves that up to the emulators. I don't have it currently because it
only ever worked with Direct3D, and it didn't work with
D3D::StretchRect.
The work I'm doing on the property class is so that I can enable
driver-specific features on-the-fly. So this may be making a return one
day.
Quote: |
for me it's soft patching and multi patch soft patching. |
Yeah, UPS is stalled out bad. I would add IPS support if you could
think of a way to handle the header issue. You can't tell if an IPS
patch was made against a headered or an unheadered ROM, and there's no
CRC32 to verify you made the right choice. Emulators now just patch
directly to the ROM data -- but bsnes discards the header as the very,
very first step in processing. So if I made an IPS patcher, it would
only patch headerless IPS patches.
Quote: |
I
say, bundle a free home made code that does roughly the same thing and
let people who feel a need for the exact code hunt it down on their
favorite rom site. |
For one, bundling "near equivalent" code goes against the whole point
of bsnes. And two, even with lots of code comments, I would be afraid
that others would take my fake IPLROM to be the real thing. I don't
want to confuse anyone like that. Speaking of which, blargg, could you
contact me when you have some time? I'd like to ask something about
your Game Music Emu.
---
Since we've all been talking about one killer feature ...
Official list of damning problems in bsnes (mostly in decreasing order):
- Slow as molasses -- 2-10x the overhead of other emulators, very few actually care "why"
- No SuperFX, SA-1 support
- No savestate support
- No audio resampling, so either video tears or audio crackles
- No true fullscreen support
- Few video options (no pixel shaders, no scanlines)
- No patching support
- No game-specific hacks (makes ~99% of true BS-X games unplayable)
- Parts of the code (input, video filters, etc) are still a trainwreck that ruins my "clean code" goal
I seriously want to add the features everyone wants. Just wasting so
much time cleaning up the base code ... seems like a never-ending
project.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Jan 08, 2008 5:07 pm Post subject: |
|
byuu wrote: |
I
seriously want to add the features everyone wants. Just wasting so much
time cleaning up the base code ... seems like a never-ending project. |
Remember
that I'm always here just enjoying watching the development of bsnes. I
don't use it regularly at all, in part because my computers aren't fast
enough, but also in part because I don't play much games anymore. But I
still love seeing the development. If I ever get around to learning
C/C++, this is one of the programs I'm most interested in learning
about (code-wise) and contributing to.
I'd say
keep working on the non-emulation parts of the program, until you are
really satisfied with that, then start working on emulation again.
Also, can you post some information on the relative speed of all the
bsnes releases? Since speed is such an important issue with bsnes, I'd
like to have more information in order to weigh speed vs. features when
choosing what version of bsnes I should use for a given task.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 08, 2008 5:20 pm Post subject: |
|
Seriously,
it's not like any of us are waiting around impatiently for bsnes to ADD
SOME GODDAMN SAVESTATES (or whatever other feature someone would yell
in that fashion). I'm pretty sure everyone who stops in regularly here
understands that it's gonna take time to get the larger problems
conquered. Just keep working on code cleanup, that's important to your
goals and it seems like as you do it, you're finding better ways to
write a lot of it; hopefully that will bring some sort of speed
increase. Other features can wait til cleanup is done, as far as I'm
concerned (and I know everyone values MY opinion, heh).
EDIT: Just wanted to add that there are so many other awesome things
being contributed by people like mudlord and nach and everyone, as well
as your work on miu and cleaning code... it really doesn't feel like
the project is at anything even remotely resembling a standstill. So I
have complete confidence that the project will continue to be refined,
and all features that can be implemented, will be. It's all just a
matter of time. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 08, 2008 5:33 pm Post subject: |
|
byuu wrote: |
Emulators now just patch directly to the ROM data -- but bsnes discards the header as the very, very first step in processing.
|
Excuse me?
ZSNES discards the header at the very very first step of processing
after loading/decompressing/merging the ROM. Patching comes after
header removal.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 08, 2008 6:41 pm Post subject: |
|
byuu wrote: |
Quote: |
for me it's soft patching and multi patch soft patching. |
Yeah, UPS is stalled out bad. I would add IPS support if you could
think of a way to handle the header issue. You can't tell if an IPS
patch was made against a headered or an unheadered ROM, and there's no
CRC32 to verify you made the right choice. Emulators now just patch
directly to the ROM data -- but bsnes discards the header as the very,
very first step in processing. So if I made an IPS patcher, it would
only patch headerless IPS patches.
|
I was going to say, it's not like it's a biting issue. I will add
though that headerless patches are better than none, right?
again though, it's not like it's a priority next to some of the other big stuff you're working on.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Jan 08, 2008 6:42 pm Post subject: |
|
byuu wrote: |
Quote: |
I
say, bundle a free home made code that does roughly the same thing and
let people who feel a need for the exact code hunt it down on their
favorite rom site. |
For one, bundling "near equivalent" code goes against the whole point
of bsnes. And two, even with lots of code comments, I would be afraid
that others would take my fake IPLROM to be the real thing. I don't
want to confuse anyone like that.
|
Yeah, because labeling the code byuusReplacementSpcIpl in the code base is definitely going to be confusing.
byuu wrote: |
Since we've all been talking about one killer feature ...
Official list of damning problems in bsnes (mostly in decreasing order):
|
I do not think that there is a need for game specific hacks for the
stelaview. I am of the opinion that the hardware can be emulated
accurately.
And you missed one thing in your list, support for the other controllers, mouse and so on.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 08, 2008 6:47 pm Post subject: |
|
so
does byuu, the only problem is good luck finding satellaview roms that
are unaltered or unhacked, at least a good full set of them. And I'm
sure emulating that thing has some major quirks, along with the fact
that he doesn't have one and there is little documentation.
not saying it can't be done... just saying...
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 6:58 pm Post subject: |
|
[quote="henke37"]
byuu wrote: |
And you missed one thing in your list, support for the other controllers, mouse and so on. |
Mouse support would be a good way to "support" more games "requiring"
it (Mario Paint for example, though I know there are hacks made for
Joypad support) Although, I have no idea how hard it would be to get
proper Snes mouse emulation up and running.
Certainly, at the very least, it wouldn't make any difference in speed like Sa-1 or Sfx would.
Heck, I have an Snes mouse which I would gladly donate. Though seeing
as they cost like 2.99$ on ebay I doubt byuu would have trouble
affording one.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 08, 2008 7:21 pm Post subject: |
|
Rydian wrote: |
Because
I'm sure the people that make patches would rather edit a patch file
over and over instead of copying and deleting a copy of a rom and
running a patcher over and over? |
Seriously, don't tell me emulator soft patch support is mainly aimed at
patch developers. I'm sure Patch devs have some effective ways of
testing quick changes to their work without going over the normal
process standard users would.
Quote: |
Also, that suit will not protect your legs from humping. |
Now, please don't include me in your legs humping habits :P
Rydian's sig wrote: |
I hump legs. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 08, 2008 8:04 pm Post subject: |
|
Quote: |
Also, can you post some information on the relative speed of all the bsnes releases? |
v017 was the fastest release. Range-tested IRQs and PGO support. v018
and later were quite slow without those. You'll have about ten broken
games in v017, though.
v018 - v025 has been mostly the same speed, v026 or so added a small ~10% boost by switching to MinGW4.
Quote: |
it really doesn't feel like the project is at anything even remotely resembling a standstill |
Yeah, I just feel that way because it's been so long since I worked on
the actual core. And no bugs to fix, either. A blessing and a curse,
but more of a blessing.
Quote: |
Yeah, because labeling the code byuusReplacementSpcIpl in the code base is definitely going to be confusing. |
Ouch.
And what if someone runs their own SNES program that dumps the IPLROM
from the emulator, or if they examine it from the debugger's memory
viewer? Or if they don't speak English?
Quote: |
I
do not think that there is a need for game specific hacks for the
stelaview. I am of the opinion that the hardware can be emulated
accurately. |
If they can be dumped cleanly, and they don't have the "expired" flags
set that prevent them from showing up in the BIOS load menu (many games
expired after a week or so, or after a set date). And we emulate the
St. GIGA satellite for games like BS Dragon Quest that require it. And
we require users to set their system clocks to arbitrary timeframes
that these games could be played in. Certain days, certain hours,
certain years ... and so on :(
Seriously, it's a real mess. The whole thing.
SNESGT fakes the system clock. Play the Mario Excitebikes and you'll
see it manipulating the time to skip the pauses. It also hacks out the
St. GIGA communication routines from BS Dragon Quest. You can see it in
the memory viewer. It also clears the "expired" flags of games
automatically. It does a lot. There's probably individual hack lists
for each game. I'm not saying this is a bad thing in the BS-X case,
since there's no other way to really play them :/
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 08, 2008 8:26 pm Post subject: |
|
Snark wrote: |
Rydian wrote: |
Because
I'm sure the people that make patches would rather edit a patch file
over and over instead of copying and deleting a copy of a rom and
running a patcher over and over? |
Seriously, don't tell me emulator soft patch support is mainly aimed at
patch developers. I'm sure Patch devs have some effective ways of
testing quick changes to their work without going over the normal
process standard users would.
|
ok, you want an example? say you have FFVI and a bunch of individual
bugfixes etc. with multi soft patching you can apply multiple ones of
them in different combinations depending on what you want to use at the
time.
in addition you'll always have clean roms so say you are trying one
hack for a game and then you want to try a different one, but you just
want to switch patches, you don't want to go and download it again, or
copy a rom, or anything, it's just easier to switch the patch and go.
byuu wrote: |
SNESGT fakes the system clock. Play the Mario Excitebikes and you'll
see it manipulating the time to skip the pauses. It also hacks out the
St. GIGA communication routines from BS Dragon Quest. You can see it in
the memory viewer. It also clears the "expired" flags of games
automatically. It does a lot. There's probably individual hack lists
for each game. I'm not saying this is a bad thing in the BS-X case,
since there's no other way to really play them :/ |
does anyone know if on the real hardware did you set the clock or did it just check a clock via satelite?
in any case just allowing the user to set the clock doesn't seem too
hacky, I mean it isn't exactly to the hardware maybe, but it's just
resetting a clock.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue Jan 08, 2008 10:45 pm Post subject: |
|
Full
screen in linux is a pipedream unless you want to start using the 3d
pipeline since there is no sane way to do it any other way.
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 08, 2008 11:36 pm Post subject: |
|
First
post now has unsupported features. I figure byuu is quite aware of what
he's missing, so repeat explanations might get annoying after a while.
For some reason I agree with Snark about soft-patching. What's the
point? It's niche convenience, and every time you add an option to a
program, it makes it harder to use. I don't think it's worth the
trouble. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Jan 08, 2008 11:36 pm Post subject: |
|
Quote: |
Full
screen in linux is a pipedream unless you want to start using the 3d
pipeline since there is no sane way to do it any other way. |
Yep, which means there is a need for OGL support to do it. If only I
can convert a 16-bit image to 24 bits for OpenGL to handle...
Quote: |
Few video options (no pixel shaders, no scanlines) |
AFAIK, no SNES emulators atm use or exploit shaders at all atm...Not
sure about the upcoming ZSNES. But, I have found a D3D shader method
that works on surfaces, although that requires using render targets to
pull it off....Plus, I don't really see the point in scanlines.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Tue Jan 08, 2008 11:40 pm Post subject: |
|
Some
people don't like the ntsc filter and prefer just plain scanlines.
Because it's not difficult to implement I think thats why everyone
supports it easily.
_________________
Watering ur plants. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Wed Jan 09, 2008 12:08 am Post subject: |
|
2d
full screen in Linux really isn't that bad with XR&R. (Or SDL,
which calls R&R internally). It's nothing at all like as bad as it
was 4-5 years ago, although I do think 2d is basically dead and you may
as well start using GL for everything.
Also, it's
perfectly possible to send 15 and 16 bit images to OpenGL. Yes, older
ATI drivers for Linux go into some awful slow PIO texture upload code
path when you try but that seems to have been fixed in newer ones and
it was never a problem with Nvidia. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Jan 09, 2008 12:17 am Post subject: |
|
Quote: |
Also,
it's perfectly possible to send 15 and 16 bit images to OpenGL. Yes,
older ATI drivers for Linux go into some awful slow PIO texture upload
code path when you try but that seems to have been fixed in newer ones
and it was never a problem with Nvidia. |
Ah thank you! I seen in some OpenGL implementation in Snes9x that it
converts raw image data to 24-bit for handling by the OGL renderer,
plus using around 5 textures for rendering, when it should be possible
to use one.
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Jan 09, 2008 12:23 am Post subject: |
|
How about you just eliminate menu in fullscreen mode for all ports and switch to window mode when a call is made for the menu? |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Jan 09, 2008 12:33 am Post subject: |
|
mudlord wrote: |
If only I can convert a 16-bit image to 24 bits for OpenGL to handle...
|
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,r_width,r_height,GL_RGBA,GL_UNSIGNED_BYTE, pixels );
==>
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,r_width,r_height,GL_RGB4,GL_UNSIGNED_BYTE, pixels );
or maybe
qglTexImage2D(GL_TEXTURE_2D, 0, GL_RGB4, r_width, r_height, 0, GL_RGB4, GL_UNSIGNED_BYTE, pixels);
I don't know OpenGL so can't help more.
_________________
quake2xp audio engineer
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Jan 09, 2008 12:38 am Post subject: |
|
Thanks for the suggestion _willow_ .
I'll play around with the code more, my main goal is to get a image showing at least.
Quote: |
qglTexImage2D(GL_TEXTURE_2D, 0, GL_RGB4, r_width, r_height, 0, GL_RGB4, GL_UNSIGNED_BYTE, pixels); |
qgl, is a Qt call, and not part of the official standard though.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Jan 09, 2008 12:46 am Post subject: |
|
mudlord wrote: |
qglTexImage2D
qgl, is a Qt call, and not part of the official standard though. |
Sorry it's a Quake engine binding, means QUAKE-glTexImage2D.
mistyping, you want int to read glTexImage2D. Sorry for confusion again.
_________________
quake2xp audio engineer
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Jan 09, 2008 12:55 am Post subject: |
|
It won't be using the colour curve when you do that though. It is better to convert in software first then render.
_________________
Watering ur plants. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 09, 2008 1:12 am Post subject: |
|
FitzRoy wrote: |
For
some reason I agree with Snark about soft-patching. What's the point?
It's niche convenience, and every time you add an option to a program,
it makes it harder to use. I don't think it's worth the trouble. |
I thought I gave a pretty good reason with the multi patch example. To
have combinations of different patches with hard patching you would
have to make many MANY different hard patches of the combinations
instead of just switching them in and out.
doing it with soft patching is much more efficient, and keeps your rom
clean. Plus the patching tools that are available for whatever reason
seem to never quite work with me, I've barely ever successfully been
able to hard patch a rom, most of the instances I'd even bother trying
is when I am trying to patch two patches on one rom (before the advent
of multi-soft patching in zsnes)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Jan 09, 2008 1:13 am Post subject: |
|
Quote: |
Sorry it's a Quake engine binding, means QUAKE-glTexImage2D. |
Its also a binding in Qt4, AFAIK 
Quote: |
mistyping, you want int to read glTexImage2D. Sorry for confusion again. |
There should be also a way to use glTexImage2D() and just create a
blank texture at startup, and then blit the data from *pixels into it...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 09, 2008 3:52 am Post subject: |
|
Panzer88 wrote: |
FitzRoy wrote: |
For
some reason I agree with Snark about soft-patching. What's the point?
It's niche convenience, and every time you add an option to a program,
it makes it harder to use. I don't think it's worth the trouble. |
I thought I gave a pretty good reason with the multi patch example. To
have combinations of different patches with hard patching you would
have to make many MANY different hard patches of the combinations
instead of just switching them in and out.
|
And what percentage of games have this many patches, and what
percentage of people use them all or interchange between them with such
frequency? It's a minor convenience for a very small number of people.
Quote: |
doing it with soft patching is much more efficient, and keeps your rom clean. |
If you make copies of the unmodified rom and modify those, you still have a clean copy.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jan 09, 2008 4:14 am Post subject: |
|
FitzRoy wrote: |
Panzer88 wrote: |
FitzRoy wrote: |
For
some reason I agree with Snark about soft-patching. What's the point?
It's niche convenience, and every time you add an option to a program,
it makes it harder to use. I don't think it's worth the trouble. |
I thought I gave a pretty good reason with the multi patch example. To
have combinations of different patches with hard patching you would
have to make many MANY different hard patches of the combinations
instead of just switching them in and out.
|
And what percentage of games have this many patches, and what
percentage of people use them all or interchange between them with such
frequency? It's a minor convenience for a very small number of people.
|
It depends on the game. Something as popular as SMW has many many
hacks. I do think you are underrating the usefulness of soft-patching.
The two main issues revolving around hard-patching:
1) Romsites... effectively keeping GoodSNES useful. Hard patching more
often than not hurts the romhacking community because unfortunately
people believe there is some ultimate-already-pretranslated rom and the
romhackers don't get the credit for the translation or hack.
2) Bug reports... as there's always a fair chance the the hack itself is causing the bug.
Obviously soft-patching does not magically eliminate these issues, but
it keeps people aware that something is actually altering the game and hopefully to some extent distinguish that the emu isn't responsible for said changes.
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Wed Jan 09, 2008 4:26 am; edited 1 time in total
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Jan 09, 2008 4:24 am Post subject: |
|
Deathlike2 wrote: |
It depends on the game. Something as popular as SMW has many many
hacks. I do think you are underrating the usefulness of soft-patching.
The two main issues revolving around hard-patching:
1) Romsites... effectively keeping GoodSNES useful. Hard patching more
often than not hurts the romhacking community because unfortunately
people believe there is some ultimate-already-pretranslated rom and the
romhackers don't get the credit for the translation or hack.
|
I actuall got in an argument with someone once over whether or not Star Ocean had a limited US release.
They said it did, and they could prove it because they downloaded the US version.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Jan 09, 2008 4:28 am Post subject: |
|
Gil_Hamilton wrote: |
Deathlike2 wrote: |
It depends on the game. Something as popular as SMW has many many
hacks. I do think you are underrating the usefulness of soft-patching.
The two main issues revolving around hard-patching:
1) Romsites... effectively keeping GoodSNES useful. Hard patching more
often than not hurts the romhacking community because unfortunately
people believe there is some ultimate-already-pretranslated rom and the
romhackers don't get the credit for the translation or hack.
|
I actuall got in an argument with someone once over whether or not Star Ocean had a limited US release.
They said it did, and they could prove it because they downloaded the US version.
|
Seriously, some people believe there is a US SD3 version. Then, there
were the idiots who were trying to selling a fake SD3 German version.
_________________
FF4 research never ends for me.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 09, 2008 4:57 am Post subject: |
|
FitzRoy wrote: |
And what percentage of games have this many patches, and what
percentage of people use them all or interchange between them with such
frequency? It's a minor convenience for a very small number of people.
|
there are enough games in the romhacking community that have multiple
hacks that - fix bugs, translate, alter the controls, improve font,
etc. and seeing as the romhacking community (the people who make, and
who play romhacks) are the people who are using these emulators the
most these days.... it's a bigger userbase than you think.
and you're right, you can make multiple copies of a rom, but if you can
do it without making multiple copies that's a good thing, especially if
this trickles over into newer emulation that uses games that are much
bigger in filesize.
I dunno, I just see it as a step forward rather than a step backwards.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 09, 2008 5:12 am Post subject: |
|
So
let me get this straight: it's possible to create a soft-patching
format that can not be hard-patched, eliminating the possibility of
GoodTools to database (and promote distribution of) hard-patched roms?
If that's true, why hasn't this been done yet? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 6:16 am Post subject: |
|
Quote: |
So
let me get this straight: it's possible to create a soft-patching
format that can not be hard-patched, eliminating the possibility of
GoodTools to database (and promote distribution of) hard-patched roms?
If that's true, why hasn't this been done yet? |
I have no respect for Cowering. He includes my fan translations in his
GoodSNES set despite my asking him to remove them. These patches lack
the accompanying readme files. It's people like him that are the reason
all the new fan translations have obnoxious, long-winded splash screens
and disclaimers when you start them. It's the only way we can send a
message to users of our patches.
So I've put a lot of thought into how to prevent hard patching of ROMs.
Unfortunately, the only really solid way I could come up with was to
apply an advanced encryption to it. And then release the binary bsnes
versions with a special, closed-source decrypter built in. The open
source releases would obviously lack the ability to apply this special
patch format. The ROM itself would have to be encrypted in RAM, before
applying the patch, and the entire ROM, even post patching, would have
to remain encrypted during the entire execution. Instead, only one byte
at a time should be decoded, and immediately discarded as soon as
possible. The debugger would have to be killed when running a patched
game. Anything, and I do mean anything, less would allow one to simply
dump the patched game back to a binary, and then make an unprotected
IPS patch, or index it in to GoodSNES. And even with all of these
protections, it really depends on how valuable the patch is. There's no
such thing as fool proof way to hide data from the user when your user
absolutely has to decode your message anyway to read it in the first
place. It's the same misnomer you see with Blu-Ray / HD-DVD and AACS.
The only thing that would protect us would be making the protection
strong enough that nobody would care enough to keep on trying to break
it.
Ultimately, it's just not worth the effort. There's always going to be
someone who goes out of their way to spite you. Better to not stoop to
their level.
Instead, we took a different approach with our latest fan translation,
Der Langrisser. We almost didn't release it publicly, but we changed
our minds. Since Cowering claims he adds each ROM solely because they
have different CRCs, we wrote a special patcher which generates a
unique checksum every time you run it. And we have and still encourage
everyone to send every last ROM over to Cowering to index into his
GoodSNES set as a separate variation. He'll probably just end up
indexing only one, but oh well. I hope a thousand people send him
variants anyway.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 6:53 am Post subject: |
|
Double post! Better to separate this, I think.
Okay, new WIP lacks Windows binary, and only changes one header.
I figured it might be fun to show you guys what I've been doing as far
as code cleanup goes, something a little different, you know?
Okay, here was the config.hpp file from the last WIP:
http://byuu.cinnamonpirate.com/temp/config_old.txt
And here is the new one:
http://byuu.cinnamonpirate.com/temp/config_new.txt
Or for those who do not know C++ ... :)
Like a standard library should be, I've reverted UpperCase to
lower_case, I've converted everything to const-correctness, I've hidden
everything that should not be public, improved the code formatting,
added proper casting, removed the needless template overloads all over
the place, converted the variable names from incomprehensible gibberish
(idef, ifmt?) to clean, understandable alternatives (default_value,
type), removed needless copying of const char* data, which means no
more destructors needed, and added proper int -> unsigned types when
indexing arrays.
The only thing left is to add better-named integer->string
conversion routines to string.hpp, to get rid of the ugly sprintf code. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jan 09, 2008 7:05 am Post subject: |
|
byuu wrote: |
Like
a standard library should be, I've reverted UpperCase to lower_case,
I've converted everything to const-correctness, I've hidden everything
that should not be public, improved the code formatting, added proper
casting, removed the needless template overloads all over the place,
converted the variable names from incomprehensible gibberish (idef,
ifmt?) to clean, understandable alternatives (default_value, type),
removed needless copying of const char* data, which means no more
destructors needed, and added proper int -> unsigned types when
indexing arrays.
The only thing left is to
add better-named integer->string conversion routines to string.hpp,
to get rid of the ugly sprintf code. |
I see you've also switched to declaring variables on the same er, level
(tab? English no be first language, urgh). I'm more used to that, but
what made you make the change?
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 09, 2008 8:20 am Post subject: |
|
byuu wrote: |
Quote: |
So
let me get this straight: it's possible to create a soft-patching
format that can not be hard-patched, eliminating the possibility of
GoodTools to database (and promote distribution of) hard-patched roms?
If that's true, why hasn't this been done yet? |
I have no respect for Cowering. He includes my fan translations in his
GoodSNES set despite my asking him to remove them. These patches lack
the accompanying readme files. It's people like him that are the reason
all the new fan translations have obnoxious, long-winded splash screens
and disclaimers when you start them. It's the only way we can send a
message to users of our patches.
So I've put a lot of thought into how to prevent hard patching of ROMs.
Unfortunately, the only really solid way I could come up with was to
apply an advanced encryption to it. And then release the binary bsnes
versions with a special, closed-source decrypter built in. The open
source releases would obviously lack the ability to apply this special
patch format. The ROM itself would have to be encrypted in RAM, before
applying the patch, and the entire ROM, even post patching, would have
to remain encrypted during the entire execution. Instead, only one byte
at a time should be decoded, and immediately discarded as soon as
possible. The debugger would have to be killed when running a patched
game. Anything, and I do mean anything, less would allow one to simply
dump the patched game back to a binary, and then make an unprotected
IPS patch, or index it in to GoodSNES. And even with all of these
protections, it really depends on how valuable the patch is. There's no
such thing as fool proof way to hide data from the user when your user
absolutely has to decode your message anyway to read it in the first
place. It's the same misnomer you see with Blu-Ray / HD-DVD and AACS.
The only thing that would protect us would be making the protection
strong enough that nobody would care enough to keep on trying to break
it.
Ultimately, it's just not worth the effort. There's always going to be
someone who goes out of their way to spite you. Better to not stoop to
their level.
Instead, we took a different approach with our latest fan translation,
Der Langrisser. We almost didn't release it publicly, but we changed
our minds. Since Cowering claims he adds each ROM solely because they
have different CRCs, we wrote a special patcher which generates a
unique checksum every time you run it. And we have and still encourage
everyone to send every last ROM over to Cowering to index into his
GoodSNES set as a separate variation. He'll probably just end up
indexing only one, but oh well. I hope a thousand people send him
variants anyway.
|
So, in other words, in order to spite one dickface, you'd screw over
most of the people who would use the translation in the first place?
And you honestly considered not releasing DL, despite the fact that so
many people wanted it, had been keeping track of its' progress and you
had even sent out beta patches to people so they could test it? Christ!
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Jan 09, 2008 12:03 pm Post subject: |
|
I
dont see how using a soft patcher is screwing people over...Besides,
byuu is the author, so he has every right to do whatever he wants with
his work. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 3:27 pm Post subject: |
|
Quote: |
I
see you've also switched to declaring variables on the same er, level
(tab? English no be first language, urgh). I'm more used to that, but
what made you make the change? |
Honestly? I'm not even sure ... I think I just kept seeing others code
like that, and kind of changed my syntax to match the norm. I also
started doing that with switch/case and class headers, too. I usually
like variable declarations to stick out more, myself. But doing things
this way does make the code easier on the eyes at first glance.
Quote: |
So,
in other words, in order to spite one dickface, you'd screw over most
of the people who would use the translation in the first
place? |
Screw them
over? What's with the strong sense of entitlement to work we gave
everyone for free? We weren't obligated to release anything. You spend seven years of your life
working on something, and see how you react to having absolutely no
respect at all given to your work from anyone in the so-called
translation scene. It wasn't just
Cowering, but he was certainly a part of it. Consider him the straw
that almost broke the camel's back. If you really want all the history
(#romhack spamming D's host with complaints until they deleted his
account, along with years' worth of his work hosted there; constant
trolling on our message board; etc, etc, etc), go talk to D. I'm not getting into it again.
You have to remember, when we started working on that game, most of us were kids. Speaking only
for myself here, there was lots of passion, and little logic. In the
end, I came to the same conclusion you have now. It wasn't worth
hurting even one person who
would ultimately enjoy our work, just to spite even one-thousand who
would take advantage of and disrespect it. Plus, in Cowering's case --
it's really no different from sites hosting commercial ROMs, anyway. We
aren't on some sort of elevated morality level just because we
translated the game as fans.
Besides, why act all surprised now? You have the patch, it was released. You're welcome.
Quote: |
And
you honestly considered not releasing DL, despite the fact that so many
people wanted it, had been keeping track of its' progress and you had
even sent out beta patches to people so they could test it? Christ! |
We didn't send out betas until we changed our minds (reference.) Saoshyant!
And thank you for reminding me why I got out of that scene all together.
Last edited by byuu on Wed Jan 09, 2008 4:11 pm; edited 2 times in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Jan 09, 2008 3:40 pm Post subject: |
|
I agree, the best thing is softpatches
Ninja format lends itself perfectly for this and every patch ever
made/released can be converted to this format in a few seconds.
Also Ninja also supports internal storage of who made the patch and so
on, and hard patched files can be unpatched, the list just goes on.
A small community effort could convert everything to ninja in a day or 2.
The patches are so small that the entire archive could be hosted on a
free download site and in a torrent or something.
If zsnes and snes9x support this format in softpatching too it would almost force the format into publicity |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jan 09, 2008 4:44 pm Post subject: |
|
FitzRoy wrote: |
and every time you add an option to a program, it makes it harder to use. |
That may be somewhat true, but soft-patching is a fairly standard
feature with emulators (IMO). And at least the way ZSNES implements it,
the features is invisible. Normal users that have no need to soft-patch
are never bothered by the feature, and users who want to do it can
learn how.
Personally, I think it would be cool to implement something like this:
In addition to using the same method as ZSNES uses to soft-patch ROMs,
add a "Load Patch" menu item, allowing you to select any patch,
regardless of filename. After selecting the patch, the in-memory ROM
would be patched and the system reset. The reason why I would want this
is so I don't have to rename all my different patches to that of the
ROM file. I can just download the patch, unzip, load the ROM, load the
patch, and I'm there.
However, it seems like at least FitzRoy is interested in keeping bsnes
at an absolute minimum of features. If and when ZSNES 2.0 is released,
it may serve all my needs and more, and I won't have any interest in
requesting features for bsnes.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 5:34 pm Post subject: |
|
I
intend to add UPS, and then NINJA3 patching, just as soon as the
libraries for these are completed. I actually had an older beta of UPS
patching support in older builds of bsnes, believe it or not. Just
wasn't too useful as only I had the patch maker.
As far as simplicity, I have to say I like simplicity in the UI. I look
at some emulators and I'm lost in a sea of options. Such as those M68K
emulators and such. "VPU2 clock speed"? What? Why do I care about that?
Anyway, one idea I had was to set some sort of UI option that lets you
toggle on more "advanced" features in the main menu and such. The load
patch option doesn't sound too hard, but then "load multiple patches"
would come into play, etc.
Quote: |
However,
it seems like at least FitzRoy is interested in keeping bsnes at an
absolute minimum of features. If and when ZSNES 2.0 is released, it may
serve all my needs and more, and I won't have any interest in
requesting features for bsnes. |
I don't always go with what FitzRoy suggests (I put the video options
only in the menu and not in a panel), we just happen to agree most of
the time is all. And of course, given all his and tetsuo55's invaluable
help testing, I also feel obliged to work with them more on requested
changes.
And you probably shouldn't have ever started using bsnes as a general
purpose emulator, it really wasn't meant for that. It just kind of
became useful as a side effect of development. Kind of cool, really.
I'm sincerely sorry to disappoint you with my rate of progress, though.
I'm trying to get all of everyone's features in, but unlike the ZSNES
team, I'm just one person -- who is blessed to have some people
contributing new modules here and there. But ultimately, I can never
compete with ZSNES v1.51, let alone v2.0. Not that I'm trying to.
Oh well, if anything, ZSNES v2 will let me get back to working on core
emulation again. And maybe that research will also trickle down one day
into ZSNES v3. Who knows. I'll keep at it though, even with no users,
because it's fun for me to work on.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 09, 2008 6:54 pm Post subject: |
|
Yeah,
I'm not trying to dictate and maybe I'm still wrong. I just don't
personally understand moving the patching process into the emulator. I
understand the loathsomeness of GoodTools and have always shared it.
But does soft-patching really stop Cowering from doing what he's doing
or challenge the popularity of it? Not really. I'm working on that one
myself. In the meantime, I fear emulators implementing practically
useless options that, by themselves don't appear to hurt anything, but
collectively can make an emulator harder to navigate and use. That is
the only reason I resist seemingly benevolent features, because I
wouldn't want to see bsnes become like Kega or something. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jan 09, 2008 7:29 pm Post subject: |
|
byuu wrote: |
And you probably shouldn't have ever started using bsnes as a general purpose emulator, it really wasn't meant for that. |
I never really did. But I do like bsnes overall better than ZSNES, as each emulator stands today (publicly released).
Quote: |
I'm sincerely sorry to disappoint you with my rate of progress, though. |
You're
not disappointing me. Seriously. My "feature request" was just a
viewpoint on that feature of emulators in general. I'd like to have a
load patch dialog in all emulators I use. I find it cumbersome to
rename patches to the same filename as the ROM (as in ZSNES).
Quote: |
I also feel obliged to work with them more on requested changes. |
By all means.
Quote: |
Oh
well, if anything, ZSNES v2 will let me get back to working on core
emulation again. And maybe that research will also trickle down one day
into ZSNES v3. Who knows. I'll keep at it though, even with no users,
because it's fun for me to work on. |
I think you have succeeded in pushing the boundaries of SNES emulation.
I hope your work will continue to influence the rest of the SNES
emulation community for the better. I have no problem treating your
emulator as a research emulator rather than an end-user emulator.
You did at least create some "more general"-purpose libraries in the process of developing bsnes.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Jan 09, 2008 7:34 pm Post subject: Mode 7 PPU Confirmation |
|
Hi byuu,
I was looking thru the source of bsnes and stumbled upon the mode 7 section of the ppu emulation:
src\ppu\bppu\bppu_render_mode7.cpp
At lines 61-64 TRAC suggests that the difference can be no greater than 1 bit for psx + psy, and you said that confirmation of this would be good.
I made a mode 7 binary containing a detailed 1024x1024 interleaved snes
bg map, and put random numbers into the 4 mode 7 sine and cosine
registers, to get severe single pixel differences in the mode 7 gfx
output.
I then ran this smc file with the current implementation of the mode 7
ppu code in bsnes, and then with TRAC's implementation, saving a 24 bit
raw bmp file of the gfx output of bsnes with each run.
I created an IPS file between the two BMP files I had made to see if
there was any differences in the gfx output. There were so many
different bytes of difference in the IPS file that I decided to look at
the screen shots with my eyes, and I could see lots of single pixels
changing colours between the two.
I saw that there was a nice circular pattern of bright yellow single
pixels in the centre of the screen that had a big difference on TRAC's
ppu implementation compared to your current implementation.
So I ran the mode 7 test binary on a real snes, using a large CRT telly
to see which PPU implementation matched the actual hardware, using that
pattern of yellow pixels as my guide.
I could clearly see the current implementation of the PPU was 100 % correct and can confirm that the difference can be greater than 1 bit for psx + psy.
So now you can remove the lines 61-64 in that source file 
I Hope this helps =D
P.S If you would like proof I can give you the screen shots I created,
the smc test file, and asm sources if you require it... |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Jan 09, 2008 7:49 pm Post subject: |
|
FitzRoy wrote: |
That
is the only reason I resist seemingly benevolent features because, I
wouldn't want to see bsnes become like Kega or something. |
You know, I really don't think Kega is that hard to use, or that it has
so much features it becomes confusing for new users. The major
difference between Kega and bsnes is that one is closed source while
the other is open.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Jan 09, 2008 8:20 pm Post subject: |
|
Snark wrote: |
FitzRoy wrote: |
That
is the only reason I resist seemingly benevolent features because, I
wouldn't want to see bsnes become like Kega or something. |
You know, I really don't think Kega is that hard to use, or that it has
so much features it becomes confusing for new users. The major
difference between Kega and bsnes is that one is closed source while
the other is open.
|
Keep in mind that Kega is also a multi-system emulator; we're not exactly talking apples to apples here.
------
On a side note, I find the progress of your emulator fascinating, and
the hundreds of thousands of views this thread has garnered leads me to
believe I'm not the only one. Largely, the people who are vocal in this
forum are the ones who support it the most. I think the general
consensus is something like "We wub j00, byuu!"
byuu wrote: |
spamming, trolling, idiocy |
One thing the internet has taught me is that stupidity and and volume
seem to have a linear correlation. Too bad there aren't automated
shmuck filters so that all the positive stuff doesn't get drowned out.
_________________
Why yes, my shift key *IS* broken.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Jan 09, 2008 8:46 pm Post subject: |
|
byuu wrote: |
Quote: |
Yeah, because labeling the code byuusReplacementSpcIpl in the code base is definitely going to be confusing. |
Ouch.
And what if someone runs their own SNES program that dumps the IPLROM
from the emulator, or if they examine it from the debugger's memory
viewer? Or if they don't speak English?
|
Those cases is so unlikely to ever happen that the user would either
not know the difference or be clued in enough to have read the manual
where you state that it's not the real original rom.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 09, 2008 9:12 pm Post subject: |
|
byuu wrote: |
Quote: |
So,
in other words, in order to spite one dickface, you'd screw over most
of the people who would use the translation in the first
place? |
Screw them
over? What's with the strong sense of entitlement to work we gave
everyone for free? We weren't obligated to release anything. You spend seven years of your life
working on something, and see how you react to having absolutely no
respect at all given to your work from anyone in the so-called
translation scene. It wasn't just
Cowering, but he was certainly a part of it. Consider him the straw
that almost broke the camel's back. If you really want all the history
(#romhack spamming D's host with complaints until they deleted his
account, along with years' worth of his work hosted there; constant
trolling on our message board; etc, etc, etc), go talk to D. I'm not getting into it again.
You have to remember, when we started working on that game, most of us were kids. Speaking only
for myself here, there was lots of passion, and little logic. In the
end, I came to the same conclusion you have now. It wasn't worth
hurting even one person who
would ultimately enjoy our work, just to spite even one-thousand who
would take advantage of and disrespect it. Plus, in Cowering's case --
it's really no different from sites hosting commercial ROMs, anyway. We
aren't on some sort of elevated morality level just because we
translated the game as fans.
Besides, why act all surprised now? You have the patch, it was released. You're welcome.
Quote: |
And
you honestly considered not releasing DL, despite the fact that so many
people wanted it, had been keeping track of its' progress and you had
even sent out beta patches to people so they could test it? Christ! |
We didn't send out betas until we changed our minds (reference.) Saoshyant!
And thank you for reminding me why I got out of that scene all together.
|
it appears I am mostly mistaken...
I guess I got pissed off because I had been keeping an eye out on this
for two years before its' release. >.>
As for the screw people over thing, I was referring to those who like
to hardpatch but don't distribute. From all of the posts and shit I've
seen, that does seem to be the most popular method. Going with the
bsnes only patch would have screwed over every single person who will
play the game on zsnes2.0.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Jan 09, 2008 10:12 pm Post subject: |
|
byuu wrote: |
I'm sincerely sorry to disappoint you with my rate of progress, though. |
Are you kidding? It plays most stuff (ie everything that doesn't depend
on some nonimplemented chip) 100% correctly. I just wish my machine was
fast enough to be able to use it without frameskipping.
Keep working in your own pace and don't forget to post irregular
updates WIP news items, I enjoy reading them, even if I don't
understand it all.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 10:55 pm Post subject: |
|
Quote: |
My
"feature request" was just a viewpoint on that feature of emulators in
general. I'd like to have a load patch dialog in all emulators I use. I
find it cumbersome to rename patches to the same filename as the ROM
(as in ZSNES). |
Alright. I'll add this to the list of things to do, once UPS support is
added. It won't be hard or require extra code, I can use the existing
BS-X / ST loaders. I will probably leave it hidden by default, but I'll
leave an advanced configuration option to enable it. Still, no promises
though, just in case I never get around to it. I'm kind of bad at that
sometimes.
Quote: |
I
could clearly see the current implementation of the PPU was 100 %
correct and can confirm that the difference can be greater than 1 bit
for psx + psy.
So now you can remove the lines 61-64 in that source file |
Ah, awesome test! I actually had one similar I used to verify anomie's
algorithm initially. I really didn't think the rounding could make the
results any different.
For those interested, this is the code in question:
Code: |
int32
psx = ((a * CLIP(hofs - cx)) & ~63) + ((b * CLIP(vofs - cy)) &
~63) + ((b * mtable_y[y]) & ~63) + (cx << 8); int32 psy =
((c * CLIP(hofs - cx)) & ~63) + ((d * CLIP(vofs - cy)) & ~63) +
((d * mtable_y[y]) & ~63) + (cy << 8);
//suggestion by TRAC, difference can be no greater than 1 bit (due to rounding) from above,
//but verification would be good...
//int32 psx = ((a * CLIP(hofs - cx)) & ~63) + ((b * (CLIP(vofs -
cy) + mtable_y[y])) & ~63) + (cx << 8);
//int32 psy = ((c * CLIP(hofs - cx)) & ~63) + ((d * (CLIP(vofs -
cy) + mtable_y[y])) & ~63) + (cy << 8); |
TRAC deduced that the latter was more probable as it removed a needless
multiplication. Doesn't appear to be the case, though, since it seems
that extra multiplication makes a real difference, as observed by krom.
It was my belief that (B * C) + (B * M) was associative to (B * (C +
M)), but it appears the & ~63 (the low 8-bits are floating point,
we clamp all but two bits here) had a more pronounced effect that I
thought.
Oh, and "1 bit" in the comment was a bad description, I meant to say
"one whole number, or pixel", suggesting rounding of the floating point
fraction.
Quote: |
I Hope this helps =D
P.S If you would like proof I can give you the screen shots I created,
the smc test file, and asm sources if you require it... |
It helps tremendously!! Thank you so much! Now we know that anomie's formula is exactly right, definitively.
I wouldn't mind having the test ROM, just so I can stick it in my test
folder in case the question comes up again one day, but I'll take your
word for it, too. With the sources, I guess I can add the two versions
of the algorithm so that we have a formal proof of why the latter above
is incorrect. I do that with all of my IRQ stuff now.
Quote: |
The major difference between Kega and bsnes is that one is closed source while the other is open. |
Right. As much as I respect developer's licensing choices, and Steve
Snake in particular ... emulators are a special case. The whole point,
to me at least, is to document the hardware, and continue to refine it
to get as close to perfection as possible. A closed source emulator
does nothing for the community in the long term.
Quote: |
Those
cases is so unlikely to ever happen that the user would either not know
the difference or be clued in enough to have read the manual where you
state that it's not the real original rom. |
Most likely, that is correct. Anyway, it's all theoretical. I won't be
removing the IPLROM from my official builds, nor will I use anything
less than a bit-perfect copy, as that goes against the goal of bsnes. I
hope that decision doesn't bother anyone here ... however, I appreciate
your suggestions. Perhaps the ZSNES / Debian team can benefit from your
ideas.
Quote: |
I guess I got pissed off because I had been keeping an eye out on this for two years before its' release. >.> |
Oh, I can understand your side of it, too. Honestly, our mistake was
discussing the project publicly in the first place. We shouldn't have
ever mentioned it until we released it. Anything else is just setting
people up for a possible disappointment. I learned a lot from my past
experiences ... and yet I keep talking about a possible cycle-based
S-PPU lately that I probably can't deliver :P
And my apologies for also getting upset. It's still a sore spot for me,
as you can tell. I "wasted" most of my childhood on that stuff. And of
course, I have only myself to blame for that.
Quote: |
As
for the screw people over thing, I was referring to those who like to
hardpatch but don't distribute. From all of the posts and shit I've
seen, that does seem to be the most popular method. Going with the
bsnes only patch would have screwed over every single person who will
play the game on zsnes2.0. |
Also good points. These issues weighed heavily on our minds, and were
part of the reason we decided to release a pure patch for the game.
Now that you bring it up, I'll mention another idea we had. The main
cause for concern was the lack of our documentation. One idea I had was
to add code that detects the real SNES, that no emulator can ever pass
(actually quite trivial to do). Failing that, test a special
emulator-only register that tells if a game was soft-patched, and pass
if so. Failing both of those, display a special boot menu with
copyright info and an embedded documentation viewer, stored right
inside the ROM, on power-on. If running on hardware, or soft-patched,
assume this info is available and jump directly into the game. Only
reason we didn't do that was because NINJA / UPS was not ready in time.
Quote: |
Are
you kidding? It plays most stuff (ie everything that doesn't depend on
some nonimplemented chip) 100% correctly. I just wish my machine was
fast enough to be able to use it without frameskipping. |
I'm sorry, I hate to keep playing the sympathy card like that. Not my
intention. I was meaning in regards to features. For instance, nearly
everyone has been asking for multitap and mouse support for ages now. I
really do need everyone's help for bug-testing, WIP testing, etc, and I
want to return the favor by adding desirable features that are feasible
for me. I've been doing a fairly lousy job of that recently.
---
But I'm getting there. The only major WTF
I'm worried about in the source right now is my keymap.hpp file, and
all the code that uses it throughout the UI. I'm having a hell of a
time coming up with some sort of keysym system for all possible keys
(what about keyboards from other countries?), joypads, etc ... the most
important part is that I need a way to convert the keycodes between
numbers for the program code itself, and strings to display nice labels
in the bsnes GUI and configuration file.
It's a real hassle. Even the naming.
I can't use key_a - key_z, because GCC declares key_t in sys/types.h. I
could use keyboard::a - keyboard::z, but what if some evil header tries
something sadistic like #define n ... ?
Or I could make it really ugly ... keyboard_a - keyboard_z. Then what
about gamepads? How to make those intrinsic? How many gamepads to
support? How many buttons per gamepad? Should I support the diagonal
keys on the d-pad? What about funky gamepads with other special
features? And on, and on, and on ... I can't make up my mind about any of it.
Last edited by byuu on Wed Jan 09, 2008 11:13 pm; edited 1 time in total
|
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Jan 09, 2008 11:05 pm Post subject: |
|
I can understand why you got so pissed off. I'm of a similar mindset, actually.
So, NINJA isn't dead after all? I thought D was quitting romhacking in general. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 09, 2008 11:18 pm Post subject: |
|
Quote: |
I can understand why you got so pissed off. I'm of a similar mindset, actually.
So, NINJA isn't dead after all? I thought D was quitting romhacking in general. |
We aren't taking part in the scene and associated politics. I still
post at RHDN, as I'm sure you've noticed, though. Though I'm honestly
not trying to, I'm waiting until I finally piss off Nightcrawler enough
to ban me from there, then I'll just stop going around those parts all
together ;)
But you spend ten years of your life working on something, and it's
hard to just write off all that knowledge and move on. D is working on
something called libpirate, a PHP-based "do-it-all" toolkit -- think Qt
for ROM hacking. NINJA will probably be related to that somehow.
Myself, I'm actually still poking around on some remnant translation
stuff, too. But as I said from what I learned from DL, I'm not going to
talk much about that and get anyone's hopes up. If I ever finish
anything, it'll be a sudden release with no warning, and I won't
participate in any drama-llama discussions about it. Tomato is talking
about Mother 3 publicly, so obviously you know I've worked on that a
tiny, tiny bit. But then, I get way too much credit for my little part in that translation.
bsnes is mostly sapping all the time I would otherwise spend on M3, it seems :(
Not fair to Tomato and co, such awesome people over there. Hence why I
got involved in that "heated" debate over on RHDN just recently.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 09, 2008 11:30 pm Post subject: |
|
FitzRoy wrote: |
Yeah,
I'm not trying to dictate and maybe I'm still wrong. I just don't
personally understand moving the patching process into the emulator. I
understand the loathsomeness of GoodTools and have always shared it.
But does soft-patching really stop Cowering from doing what he's doing
or challenge the popularity of it? Not really. I'm working on that one
myself. In the meantime, I fear emulators implementing practically
useless options that, by themselves don't appear to hurt anything, but
collectively can make an emulator harder to navigate and use. That is
the only reason I resist seemingly benevolent features, because I
wouldn't want to see bsnes become like Kega or something. |
no I get it, it's a matter of preference, you prefer one thing, and I
another. It wouldn't affect bsnes in terms of complex menus if it was
implemented like zsnes. That is, there is no menu, it simply patches
the rom if they both have the same filename, and if such an instance
doesn't occur, then it quietly does nothing.
if anything it might slow things down but as far as menu problems it
really wouldn't need to do anything. It could be like many features in
emulators these days, there, but invisible unless you read the readme
etc. (aka not part of the GUI)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Thu Jan 10, 2008 12:01 am Post subject: |
|
byuu wrote: |
Quote: |
I can understand why you got so pissed off. I'm of a similar mindset, actually.
So, NINJA isn't dead after all? I thought D was quitting romhacking in general. |
We aren't taking part in the scene and associated politics. I still
post at RHDN, as I'm sure you've noticed, though. Though I'm honestly
not trying to, I'm waiting until I finally piss off Nightcrawler enough
to ban me from there, then I'll just stop going around those parts all
together 
But you spend ten years of your life working on something, and it's
hard to just write off all that knowledge and move on. D is working on
something called libpirate, a PHP-based "do-it-all" toolkit -- think Qt
for ROM hacking. NINJA will probably be related to that somehow.
Myself, I'm actually still poking around on some remnant translation
stuff, too. But as I said from what I learned from DL, I'm not going to
talk much about that and get anyone's hopes up. If I ever finish
anything, it'll be a sudden release with no warning, and I won't
participate in any drama-llama discussions about it. Tomato is talking
about Mother 3 publicly, so obviously you know I've worked on that a
tiny, tiny bit. But then, I get way too much credit for my little part in that translation.
bsnes is mostly sapping all the time I would otherwise spend on M3, it seems 
Not fair to Tomato and co, such awesome people over there. Hence why I
got involved in that "heated" debate over on RHDN just recently.
|
Ah, I see. I remember libpirate(Used to check his page a fair bit back
when Ninja 2.0 was the hot topic. >.>), but I thought he'd
dropped it.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Thu Jan 10, 2008 12:09 am Post subject: |
|
If
NINJA/UPS gets implemented in bsnes, then we are going to need to see
it implemented in ZSNES/Snes9x as well. I'm one of those crazy people
who use more than 1 SNES emulator and use soft-patching.
Having two sets of (near identical) patches is not 100% ideal in my
opinion (and I dislike hard-patching like most people here seem to).
Wouldn't kill me personally, but I'd prefer having a single accepted
format between emulators than a bunch of different patching systems
being used at once.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Thu Jan 10, 2008 4:10 am Post subject: |
|
I'm sure all of the big emulators would jump on a better format...
It really is needed still. If i had the skills, i'd do it myself. >.< |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Jan 10, 2008 4:11 am Post subject: |
|
the bigger thing would be to convert all the old ones, sure it's not hard, but who's gonna do it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Thu Jan 10, 2008 4:20 am Post subject: |
|
I
imagine all you would have to do is properly patch the rom, then run
the ninja/whatever program on the rom like you do with IPS patches...
Of course, I could be wrong. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jan 10, 2008 6:32 am Post subject: |
|
Panzer88 wrote: |
It
wouldn't affect bsnes in terms of complex menus if it was implemented
like zsnes. That is, there is no menu, it simply patches the rom if
they both have the same filename, and if such an instance doesn't
occur, then it quietly does nothing. |
That would seem to be okay then, I guess I should move up a space on my jump to conclusions mat.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 10, 2008 7:52 am Post subject: |
|
Man, another five hours of programming.
This time, I rewrote my arithmetic <> string conversion routines.
The arithmetic -> string stuff before was really bad. It just forced
the assumption that your output buffer was big enough. If not, crash
time.
This time, I implemented them like the OpenBSD strl* functions, but a
little better. You can call these with no string output and get the
required length for the string. Or you can give it the actual size of
your output, and it will stop writing when it needs to. You can verify
truncation by checking the return value.
Something really wild for me was adding floating-point support. The
good news is that a new add-on to config.hpp is trivial now, which will
add floating-point values to bsnes' config file. Great for eg the
gamma, contrast, speed multipliers, etc.
But wow, you have no idea how many subtle problems pop up there.
There's a function called modf, where you can split 12.75 into 12.0 and
0.75. Now how do you convert 0.75 to 75, so that you can write it out
to a string? (and don't say multiply by 100, that doesn't work then for
12.275, etc) Heh ... I had to come up with my own solution since
apparently the standard library lacked one.
Anyway, as per yesterday I'll post the relevant code, and how it helped
clean up that last part of config.hpp that was relying on sprintf():
http://byuu.cinnamonpirate.com/temp/convert.txt
All of that written in five hours :) |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Thu Jan 10, 2008 10:50 am Post subject: |
|
This has been around at least since WIP 8.
Code: |
$ make PLATFORM=x-gcc-x86-64
** CUT **
ui/vai/audio/audio.openal.cpp:3:19: error: AL/al.h: No such file or directory
ui/vai/audio/audio.openal.cpp:4:21: error: AL/alut.h: No such file or directory
ui/vai/audio/audio.openal.cpp:12: error: ISO C++ forbids declaration of 'ALCdevice' with no type
ui/vai/audio/audio.openal.cpp:12: error: expected ';' before '*' token
ui/vai/audio/audio.openal.cpp:13: error: ISO C++ forbids declaration of 'ALCcontext' with no type
ui/vai/audio/audio.openal.cpp:13: error: expected ';' before '*' token
ui/vai/audio/audio.openal.cpp:14: error: 'ALuint' does not name a type
ui/vai/audio/audio.openal.cpp:15: error: 'ALenum' does not name a type
ui/vai/audio/audio.openal.cpp: In member function 'void pAudioOpenAL::sample(uint16, uint16)':
** CUT **
|
I cut most of the lines because the missing header probably causes
them. It really seems that AL/al.h and AL/alut.h cannot be found, I
also looked around a bit and I didn't find them.
The build process completes after removing parts relevant to OpenAl and alut from Makefile and ui/miu/ui.cpp.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Thu Jan 10, 2008 11:51 am Post subject: |
|
Turambar wrote: |
This has been around at least since WIP 8.
...
I cut most of the lines because the missing header probably causes
them. It really seems that AL/al.h and AL/alut.h cannot be found, I
also looked around a bit and I didn't find them.
The build process completes after removing parts relevant to OpenAl and alut from Makefile and ui/miu/ui.cpp. |
http://www.openal.org/
byuu wrote: |
But wow, you have no idea how many subtle problems pop up there.
There's a function called modf, where you can split 12.75 into 12.0 and
0.75. Now how do you convert 0.75 to 75, so that you can write it out
to a string? (and don't say multiply by 100, that doesn't work then for
12.275, etc) Heh ... I had to come up with my own solution since
apparently the standard library lacked one.
|
Code: |
x86 assembler (build-in floating point unit in use)
.data
dw mantissa //me is short
dw exponent //me is short too
double value //me is double
.code
fld value //load double to FPU stack
fxtract //split it to mantissa and exponent
fistp mantissa //return mantissa
fistp exponent //return exponent
|
It's really cleaner and faster whatever else you going to do or did.
Something similar should be in C math too if you want it to be CPU
independent.
_________________
quake2xp audio engineer
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jan 10, 2008 12:03 pm Post subject: |
|
I.S.T. wrote: |
I
imagine all you would have to do is properly patch the rom, then run
the ninja/whatever program on the rom like you do with IPS patches...
Of course, I could be wrong. |
Panzer88 wrote: |
the bigger thing would be to convert all the old ones, sure it's not hard, but who's gonna do it. |
I.S.T. wrote: |
I
imagine all you would have to do is properly patch the rom, then run
the ninja/whatever program on the rom like you do with IPS patches...
Of course, I could be wrong. |
Converting patches to Ninja format is simple, there are 2 options.
1. Patch is meant for a headerless rom.
Get the correct headerless rom, make a copy of it, then apply the
current patch(format does not matter) to the copy of the rom.
Now tell Ninja to make a patch of the difference between the clean rom
and the patched rom, the resulting file will be a universal ninja patch.
This patch will work on any compatible rom, it doesnt matter if the rom has a header or not.
2.patch is meant for a headerd rom.
Get the correct rom with the correct header, then make a copy of it.
Apply the patch to the copy of the rom.
then scan both files and remove the headers.
Now open the files in Ninja and let it cratea a patch file from the differences.
This patch will work on any compatible rom, it doesnt matter if the rom has a header or not.
However, doing this will not add the copyright information to the
patch, to do so you need to copy the "readme" into the info section of
Ninja, Ninja will then embed the readme file into the patch.
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Thu Jan 10, 2008 12:03 pm Post subject: |
|
Alright...
I was a bit stupid, I misread #include <AL/al.h> as
#include"AL/al.h" or something. Everything is fine then. Adding an
ifdef for disabling OpenAL would be nice though.
EDIT: I added the ifdefs myself. This way it works after editing only
the makefile. I don't understand that much C/C++ that I'd knew if this
was a good solution or not.
Code: |
--- src/ui/miu/ui.cpp 2008-01-02 08:54:10.000000000 +0200
+++ edit/ui/miu/ui.cpp 2008-01-10 14:11:53.000000000 +0200
@@ -21,7 +21,9 @@
#include "../vai/video/video.xv.h"
#include "../vai/video/video.gtk.h"
#include "../vai/audio/audio.ao.h"
+#if defined(OPENAL)
#include "../vai/audio/audio.openal.h"
+#endif
#include "../vai/audio/audio.oss.h"
#include "../vai/input/input.x.h"
#endif
@@ -77,8 +79,10 @@
if(config::system.audio == "none") {
uiAudio = new Audio();
+#if defined(OPENAL)
} else if(config::system.audio == "openal") {
uiAudio = new AudioOpenAL();
+#endif
} else if(config::system.audio == "oss") {
uiAudio = new AudioOSS();
} else {
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Jan 10, 2008 6:05 pm Post subject: |
|
I
wasn't so much concerned about the complexity as I was about someone
actually going through all the hacks on the databases, and some that
aren't, and converting them. I suppose if people had initiative they
could convert their own hacks. They could even do some revision and
then "rerelease" it.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 10, 2008 7:04 pm Post subject: |
|
Quote: |
It's
really cleaner and faster whatever else you going to do or did.
Something similar should be in C math too if you want it to be CPU
independent. |
There is no such function in math.h. And there's no way I'm going to
start using platform-specific implementations for this :/
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Jan 10, 2008 7:12 pm Post subject: |
|
Did you mean not at all or just not as the only alternative?
I am sure that the build system can be told how to chose the best alternative for the user at compile time. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Jan 10, 2008 7:48 pm Post subject: |
|
Panzer88 wrote: |
I
wasn't so much concerned about the complexity as I was about someone
actually going through all the hacks on the databases, and some that
aren't, and converting them. I suppose if people had initiative they
could convert their own hacks. They could even do some revision and
then "rerelease" it. |
Well, i did it once before with "usefull" patches, and i can get my hands on relatively up to date patch batches.
imho usefull = Translate game or menu fully, adds missing options to games or game/graphic fixes.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 11, 2008 4:58 am Post subject: |
|
So,
I've been studying functional programming recently. With the
development of yet another version of xkas, and with the real gem that
was gladius' recursive descent parser ... it really got me interested
in coming up with more sophisticated parsers.
Back in the day, I never really understood how gladius' parser worked
(too advanced for my skill level), I just bolted the rest of the
operators I wanted onto it.
So I figured I would take a stab at writing my own recursive descent
parser to parse C-style math expressions. A very useful thing for an
assembler.
After a few hours, I came up with this:
http://byuu.cinnamonpirate.com/temp/eval.txt
eval() is what I wrote myself, 100% my code.
strmath() is what gladius wrote, 99% his code.
Results? Mine is ~4x faster, is half the size, and is much easier to understand and add new stuff onto :D
Huge success.
Comments, suggestions or improvements on my eval design are very much
welcome. My plan is to continue studying, and eventually create a
generalized RDP that takes user-specified lists and does all the
parsing internally. Something like boost::spirit, but instead of
mimicking EBNF syntax, it'll just have basic elements, and look
something like this:
Code: |
RDP<result_type> rdp;
rdp.group(priority, functor, "(", ")");
rdp.unary(priority, functor, "!");
rdp.binary(priority, functor, "==");
rdp.ternary(priority, functor, "?", ":");
rdp.unodecatricentimal(priority, functor, ...); //hahah, just kidding
if(rdp.evaluate(string, result) == true); //success |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Jan 11, 2008 5:26 am Post subject: |
|
byuu wrote: |
So, I've been studying functional programming recently. |
Fear Scheme and Lisp! 
_________________
FF4 research never ends for me.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Jan 11, 2008 6:30 am Post subject: |
|
byuu wrote: |
So, I've been studying functional programming recently. |
for some reason I read "fictional" programming the first time. weird eh?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 11, 2008 11:33 pm Post subject: |
|
Hmm,
I remember ZSNES was supposedly using gladius' parser, so I decided to
take a look. Sure, it's there, but with a lot less features than mine.
So that got me curious as to how well it performed :)
From:
Code: |
https://zsnes.bountysource.com/svn/!source/5177/trunk/src/parsegen.cpp |
Unfortunately, my previous timing test didn't work on it since it lacks
ternary, comparative, logical, not, positive, hex, binary and octal
support, so I had to simplify a bit. Here's the results:
Code: |
"2+(3*7)%3+146-12*11/2+(5<<(3>>1))+(127&126|1^8)"
run 1000000 times
output = "ms, result of evaluation * 1000000"
cl
eval = 2093 219000000
enhanced_atoi = 10329 219000000
strmath = 8562 219000000
cl /O2
eval = 1281 219000000
enhanced_atoi = 9859 219000000
strmath = 4797 219000000
mingw32-g++
eval = 2093 219000000
enhanced_atoi = 14422 219000000
strmath = 7766 219000000
mingw32-g++ -O3
eval = 1203 219000000
enhanced_atoi = 14406 219000000
strmath = 4969 219000000 |
... wow. Seems the culprit is sscanf. It's apparently vastly slower (as well as more dangerous) than an ad-hoc implementation.
So ... anyone interested in adding my version to ZSNES? It should speed
up PSR parsing quite nicely, and you get lots of extra parsing power
for free :)
Oh, and what in the name of all that is holy is this?!
... you made it compile a program to parse the math?? Ye gods, I won't even dare try and benchmark that! :P
Though I greatly admire the cleverness behind it, I think we should submit that one here ;)
Quote: |
Fear Scheme and Lisp! |
From what I understand, they're very similar, with Scheme being based
on Lisp. But yes, that's the general idea. Unfortunately, I'm having
trouble finding just a straight up binary, something like php-cli.exe
... where I can just say "scheme myapp.sch" and have it run and do its
thing.
So I've pretty much just been practicing in C++ and by reading Scheme examples.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 5:58 am Post subject: |
|
ha,
ok byuu you cought me over at RHDN, I figure it's just a hack
malfunction, which is why I didn't post it here yet, but I'll have you
give it a look over, or someone with a copier or something.
anyways, the hack in question is
Chrono Trigger: Prophet's Guile
and it's from some of the guys over at the chrono compendium. It's just
a single chapter hack I believe, not a full feature, but it's pretty
interesting.
Anyways, the game works very well in bsnes, there is only one part where it glitches.
the part in question is when magus steps on the teleporter to enter the
ocean palace. It is only an hour or so into the game if even. That is
the only part where it has locked up, and I saved immediately after the
transport and started playing in bsnes again and I haven't had any more
difficulties. can anyone pinpoint the reason of this glitch? (I'm sure
it's to do with the hack, or temporal flux or something)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 12, 2008 6:24 am Post subject: |
|
Could you provide a save relatively close to the teleporter thing so that nobody has to play it for an hour? :) |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 6:27 am Post subject: |
|
sure,
I was doing it off of a library computer, but I'll try to get that here
asap. sorry i didn't even think of posting that. be back in a bit.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 7:12 am Post subject: |
|
http://www.fileden.com/files/2008/1/9/1688344/Chrono%20Trigger%20%28U%29%20%5B%21%5D.srm
that is the save file, I'm using a clean US headerless rom.
to get to the point of the bug, simply go down a screen, you will see a
landing with stairs in 3 directions, go to the left, and then up to a
Nu gaurding a door.
Talk to the Nu and he will move, continue up the hall to the Mammon
Machine, there will be a dialog with the queen and dalton, then, when
you step on the elevator it will show you transporting to the ocean
palace, and then the screen will go black and it will freeze.
it does not do this in zsnes, so far this is the only time the game has frozen, and it will do it consistently.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 12, 2008 7:24 am Post subject: |
|
Awesome, thank you.
Anyone have their copier / flashcart handy to test this one? I can test
if need be, but if I can avoid having to dig it out that'd be great :) |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 7:27 am Post subject: |
|
here is the info of the rom I used, before I patched it
---------------------Internal ROM Info----------------------
File: Chrono Trigger (U) [!].smc
Name: CHRONO TRIGGER Company: Square
Header: None Bank: HiROM
Interleaved: None SRAM: 64 Kb
Type: Normal + Batt ROM: 32 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x788C Game Code: ACTE
---------------------------Hashes---------------------------
CRC32: 2D206BF7
and then after I patched it
---------------------Internal ROM Info----------------------
File: Chrono Trigger (U) [!].smc
Name: CHRONO TRIGGER Company: Square
Header: None Bank: Extended HiROM
Interleaved: None SRAM: 64 Kb
Type: Normal + Batt ROM: 48 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Bad 0x5159 != 0x788C Game Code: ACTE
---------------------------Hashes---------------------------
CRC32: 1EB43B3A
MD5: 64E42C2715AB9D408EA146230CC23BF1
--------------------------Database--------------------------
ROM wasn't found in the database (possible bad dump).
You can try using -fix or -findover to see if the
file has been slightly altered in a rectifiable way.
I used LunarIPS
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Jan 12, 2008 7:48 am Post subject: |
|
Panzer, SRM is the most compatible thing across emus (and flash carts). It's just data.
The only thing that wouldn't quite work is if the hack massively
changed how data was stored (think Zelda: Parallel Worlds).
_________________
FF4 research never ends for me. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 8:07 am Post subject: |
|
right, hmm, I knew that and yet I guess force of habit, I'll remember that for next time.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 6:09 pm Post subject: |
|
Panzer88 wrote: |
http://www.fileden.com/files/2008/1/9/1688344/Chrono%20Trigger%20%28U%29%20%5B%21%5D.srm
that is the save file, I'm using a clean US headerless rom.
to get to the point of the bug, simply go down a screen, you will see a
landing with stairs in 3 directions, go to the left, and then up to a
Nu gaurding a door.
Talk to the Nu and he will move, continue up the hall to the Mammon
Machine, there will be a dialog with the queen and dalton, then, when
you step on the elevator it will show you transporting to the ocean
palace, and then the screen will go black and it will freeze.
it does not do this in zsnes, so far this is the only time the game has
frozen, and it will do it consistently. |
99% sure this is caused because he probably used zsnes as a reference
when making the patch. If it freeze on bsnes it will freeze on real
hardware.
Sorry, right now I'm not at my place so I won't be able to test it on
my copier for four, five days. If no one tested on hardware in the
meantime, I'll be sure to test it when I get back.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 12, 2008 7:38 pm Post subject: |
|
Damn, I'm not able to test this, then. My copier only has 32MB DRAM.
We'll need someone who has successfully played Tales of Phantasia to
test this bug.
Quote: |
99%
sure this is caused because he probably used zsnes as a reference when
making the patch. If it freeze on bsnes it will freeze on real hardware. |
Well, that's what we're hoping, but I figure we should go ahead and
make sure. Although this is just a hack which I usually hate working
with, I was
wrong about the S-DD1 hack bug. Besides, the last thing I want is to
end up considering ever new bug found as a bug on real hardware, too.
bsnes isn't quite perfect yet :/
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 8:58 pm Post subject: |
|
byuu wrote: |
Damn, I'm not able to test this, then. My copier only has 32MB DRAM. .
|
Doh. Likewise, my GD3 copier only has 32MB...
Quote: |
Quote: |
99%
sure this is caused because he probably used zsnes as a reference when
making the patch. If it freeze on bsnes it will freeze on real hardware. |
Well, that's what we're hoping, but I figure we should go ahead and
make sure. Although this is just a hack which I usually hate working
with, I was
wrong about the S-DD1 hack bug. Besides, the last thing I want is to
end up considering ever new bug found as a bug on real hardware, too.
bsnes isn't quite perfect yet :/
|
I know, and I agree tests should be done on hardware, but I'm just
making predictions in the meantime. I've seen quite a bit of hacks that
"seemingly" works on ZSNES but end ups crapping halfway on
hardware...kind of sad in a way because those hacks can't technically
be considered "real" SNES game hacks if they crap on the real console
imo.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Jan 12, 2008 9:21 pm Post subject: |
|
ZSNES 1.51 is no way a representation or a direction the ZSNES team is taking right now.
_________________
Watering ur plants. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 9:53 pm Post subject: |
|
pagefault wrote: |
ZSNES 1.51 is no way a representation or a direction the ZSNES team is taking right now. |
Meant no disrespect for the ZSNES team. I hope more hacks that fails on hardware fail on ZSNES 2.00 :D
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 10:06 pm Post subject: |
|
also snark I already thought that it was prolly just the hack itself, but byuu asked me to file a report, which is why I did.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 10:24 pm Post subject: |
|
Panzer88 wrote: |
also snark I already thought that it was prolly just the hack itself, but byuu asked me to file a report, which is why I did. |
It most definitely is the fault of the hack itself. I never, ever
intended to say it was the fault of ZSNES. If rom hackers can't test
their hacks on real hardware (or bsnes for that matter, which comes a
very close second) then that's not the fault of the ZSNES team
obviously.
Just saying if the person(s) who made the hack used 1.51 as a reference
then there's a few things that might have pass on ZSNES which normally
would not pass on hardware.
Bottom line: it's always better to test on hardware.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 10:36 pm Post subject: |
|
(Previous post was getting crowded)
edit: The problem is: (and again,I want to make it clear I'm not
blaming ZSNES but the rom hackers) What happens when the emulators
which used to play your hack no longer does because it has changed or
has gotten more accurate? Doh. The hack you spent months working on
will effectively forever disappear because there's no emulators left to
play it, and the original console doesn't either...
That's a lack of planning imo, which again rom hackers are solely responsible for. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 12, 2008 10:37 pm Post subject: |
|
Quote: |
ZSNES 1.51 is no way a representation or a direction the ZSNES team is taking right now. |
It's very unfortunate how long the direction change took. I really
would have preferred to join a ZSNES v2.0 team back in 2004-2005,
rather than start my own emulator. I guess that's why I'm slightly
bitter about it now, even though I'm very glad things are changing.
Hopefully you won't mind if I try collaborating a bit more with your
team once v2.0 is out the door.
I guess the thing still going for me is the total separation of the
components that I'm working toward (not there yet with the
CPU<>PPU). It doesn't enhance accuracy, and it makes things an
order of magnitude slower, but it does help make the code easier to
read, debug and understand. But I don't see how we could ever merge our
ideas anyway, given that mine kills off invaluable features like
savestates.
But seriously, is there anyone even really working on the lowest-level
core emulation stuff, other than you and me? With anomie/SNES9x and
TRAC/SNEeSe mostly inactive, it doesn't seem to be the case =(
Quote: |
also snark I already thought that it was prolly just the hack itself, but byuu asked me to file a report, which is why I did. |
That I did, and thank you for the report.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 12, 2008 10:42 pm Post subject: |
|
@snark
not to talk just for the sake of talking, but I'm sure it was an honest
mistake of the hackers, I think they used Temporal Flux, an editing
program.
sure they should have checked it on hardware, but not everyone has that option.
I do agree though that hackers really need to start getting their stuff
tested on real hardware by SOMEONE as a part of bugtesting before
release.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 12, 2008 11:03 pm Post subject: |
|
Panzer:
Ok I'll try to keep it short lol
It just seem silly to not test on hardware as that might very well
determine the "life" longevity of your hack. Then again, it's possible
some rom hackers lack the skill to pull off a working hack that works
on hardware and instead rely on imperfect third party editing tools.
The higher level rom hackers no doubts test their stuff on hardware
because there ARE a few hacks that works on console thankfully. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Jan 12, 2008 11:58 pm Post subject: |
|
byuu wrote: |
We'll need someone who has successfully played Tales of Phantasia to test this bug. |
I successfully played ToP... with the real cart. I guess that won't help you much with this hack, will it ? ;)
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sun Jan 13, 2008 2:02 am Post subject: |
|
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 13, 2008 2:12 am Post subject: |
|
blargg wrote: |
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels. :) |
... that .... that's the smallest assembler I've ever seen in my life o.O
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jan 13, 2008 2:21 am Post subject: |
|
It works and it is good.
_________________
Watering ur plants. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jan 13, 2008 2:32 am Post subject: |
|
blargg wrote: |
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels.  |
what was the issue, and what is different now, for the techically inept.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 13, 2008 3:31 am Post subject: |
|
Panzer88 wrote: |
blargg wrote: |
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels. :) |
what was the issue, and what is different now, for the techically inept.
|
Technically inept here.
My guess is the spc code is being generated when the emulation start
and the bios code itself does not need to be included anymore...or
something to that effect...ok, so I don't actually know either :/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 13, 2008 4:39 am Post subject: |
|
Panzer88 wrote: |
http://www.fileden.com/files/2008/1/9/1688344/Chrono%20Trigger%20%28U%29%20%5B%21%5D.srm
that is the save file, I'm using a clean US headerless rom.
to get to the point of the bug, simply go down a screen, you will see a
landing with stairs in 3 directions, go to the left, and then up to a
Nu gaurding a door.
Talk to the Nu and he will move, continue up the hall to the Mammon
Machine, there will be a dialog with the queen and dalton, then, when
you step on the elevator it will show you transporting to the ocean
palace, and then the screen will go black and it will freeze.
it does not do this in zsnes, so far this is the only time the game has
frozen, and it will do it consistently. |
I can't seem to initiate this "dialog" between the two people. When I
go in, there are three people I can speak to but it doesn't do
anything. I see no elevator.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jan 13, 2008 4:48 am Post subject: |
|
my mistake, somehow the wrong save file was uploaded.
again, my appologies, I will have the correct file up shortly 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 13, 2008 6:59 am Post subject: |
|
Verified to crash on hardware. bsnes is right. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jan 13, 2008 7:16 am Post subject: |
|
I guess I should inform the guys over at the compendium then. Thanks FitzRoy.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 13, 2008 10:51 am Post subject: |
|
FitzRoy wrote: |
Verified to crash on hardware. bsnes is right. |
... it seems I have wasted everyone's time again. My sincere apologies.
Thank you very much for testing, FitzRoy. Your help is truly invaluable.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 13, 2008 12:30 pm Post subject: |
|
FitzRoy wrote: |
Verified to crash on hardware. bsnes is right. |
I am teh shock, Gentlemen.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jan 13, 2008 4:09 pm Post subject: |
|
I
would like another party to investigate this issue. I can't seem to
reproduce these results playing directly from the cart. What was used
to test this on the hardware?
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 13, 2008 4:42 pm Post subject: |
|
64M Tototek flash cart. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jan 13, 2008 4:54 pm Post subject: |
|
Ok thanks, I will re-run my tests on that hardware.
_________________
Watering ur plants. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sun Jan 13, 2008 4:56 pm Post subject: |
|
Snark wrote: |
Panzer88 wrote: |
blargg wrote: |
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels. :) |
what was the issue, and what is different now, for the techically inept.
|
My guess is the spc code is being generated when the emulation start
and the bios code itself does not need to be included anymore...
|
Yes. Instead of the machine code being included directly (those 64
bytes of ROM), only the textual commented assembly source code
is present in the executable. Each time you run the emulator, it
assembles that into the machine code (those 64 bytes). Presumably, the
copyright applies to the machine code, so this doesn't include any
copyrighted material. But I'm not a lawyer...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 13, 2008 5:53 pm Post subject: |
|
blargg wrote: |
Snark wrote: |
Panzer88 wrote: |
blargg wrote: |
SPC boot ROM issue solved. Mini-assembler that assembles commented assembly at run-time. Even supports numbered labels.  |
what was the issue, and what is different now, for the techically inept.
|
My guess is the spc code is being generated when the emulation start
and the bios code itself does not need to be included anymore...
|
Yes. Instead of the machine code being included directly (those 64
bytes of ROM), only the textual commented assembly source code
is present in the executable. Each time you run the emulator, it
assembles that into the machine code (those 64 bytes). Presumably, the
copyright applies to the machine code, so this doesn't include any
copyrighted material. But I'm not a lawyer...
|
Yeah, I was wondering if it actually makes a difference, legally speaking. (Or if they still cared afterward)
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Jan 13, 2008 6:38 pm Post subject: |
|
An assembler is just an encoding tool. And so is the deassembler you used to get the code.
Even if you write out the lyrics of a song that you have heard, the copyright does not go away. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 13, 2008 7:12 pm Post subject: |
|
pagefault wrote: |
I
would like another party to investigate this issue. I can't seem to
reproduce these results playing directly from the cart. What was used
to test this on the hardware? |
All I could find was this which says:
Quote: |
When
the portal opens, Crono's party is "teleported" to the center of the
screen and Magus to the top-right corner of the screen. I checked the
commands and it seems that for some reason, it's due to the fact that
there's no battle. If there's a battle, the characters will be
correctly placed when the mode-7 portal opens. If there's no battle,
they get displaced. I don't think there's a solution to this bug since
we can't really have a Magus vs. party battle (or can we? ...no,
probably too much bothersome to hack). |
Anyway, I'm not going to worry about it. FitzRoy reproduced the crash
on hardware -- that's enough time I wasted on this issue for me.
The bad thing is, I'm not sure if I should keep pressing people to post
potential bug reports from fan translations and hacks anymore. People's
time is valuable, and there will always be new SNES code created via
emulation. Perhaps it's better to leave it as "report a bug only if you
confirm it via hardware tests" ?
Hmm yeah, let's go with that. Unless the game is <= 32MB and uses no
special chips ... in that case, you can tell me about the bug in
private message and I will personally test it for you. Sound good?
Quote: |
An assembler is just an encoding tool. And so is the deassembler you used to get the code.
Even if you write out the lyrics of a song that you have heard, the copyright does not go away. |
Ah, always the optimist. Sadly, I do have to agree in this case. It
seems like an easy end-run around copyright (not that I think the
IPLROM is copyrightable in the first place.) But if it's good enough
for the Debian team and their anti binary array crusade, all the better.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sun Jan 13, 2008 7:18 pm Post subject: |
|
byuu wrote: |
All I could find was this which says:
Quote: |
When
the portal opens, Crono's party is "teleported" to the center of the
screen and Magus to the top-right corner of the screen. I checked the
commands and it seems that for some reason, it's due to the fact that
there's no battle. If there's a battle, the characters will be
correctly placed when the mode-7 portal opens. If there's no battle,
they get displaced. I don't think there's a solution to this bug since
we can't really have a Magus vs. party battle (or can we? ...no,
probably too much bothersome to hack). |
Anyway, I'm not going to worry about it. FitzRoy reproduced the crash
on hardware -- that's enough time I wasted on this issue for me.
|
just for the record I believe they are describing the beginning of the
game, and a glitch that happens in SNES9x, I'd like to note that that
isn't the one that happens on bsnes, which is much later, but FitzRoy
did confirm it and tthat's good enough for me. In future cases I'll
prolly just inform the author of the hack and if they so desire they
can get their own hack checked by someone with the ability to test real
hardware. I'm sure many would be willing to put in the time although
sadly I'm sure many are without the means to do it themselves so
they'll have to bug friends who can.
I also concur on the Debian folks, as long as it's good enough for
them, it really doesn't matter, good one blargg.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 13, 2008 11:00 pm Post subject: |
|
byuu wrote: |
Quote: |
If it's possible to do it just by me running your tests, though, I'd be glad to help. |
We should start by trying to build libco. The PPC64 version might work.
If we can do that, then bsnes will run fine on the PS3. In fact, I'm
90% sure it'll get full speed, too. I get a cool 60-70fps minimum on an
old $30 Pentium IV 3.2GHz. Given the x86 nature of ZSNES, and the lack
of an official GUI for SNES9x/Linux ... it might actually be a platform where bsnes gets good overall reception
|
I'm ready to try this, but I've never "built" anything in my life and
this is my first time using linux. Very familiar with Windows, though.
So basically, I need a newb proof guide on what to do. I have the
source of the latest WIP. I am using YellowDogLinux 5.02. No idea what
video or audio APIs it uses. Any help is appreciated.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Jan 13, 2008 11:37 pm Post subject: |
|
I
ran the test again and it's not freezing at all for me.... Anyone else
want to test? I ran it on all 3 revisions of SNESes I have including
the PAL one.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 14, 2008 4:15 am Post subject: |
|
FitzRoy wrote: |
I'm
ready to try this, but I've never "built" anything in my life and this
is my first time using linux. Very familiar with Windows, though. So
basically, I need a newb proof guide on what to do. I have the source
of the latest WIP. I am using YellowDogLinux 5.02. No idea what video
or audio APIs it uses. Any help is appreciated. |
Hmm, unfortunately I really don't know how to start with YDL. But I
should mention that I recently posted a new libco version with SJLJ.
I'd recommend grabbing that from my programming page to try and build
that first. To build it, you'd just run "./cc_sjlj.sh" inside the test
folder.
Other than that, I'll have to look up instructions for how to install
the required dev libraries for YDL. I'll see what I can find tomorrow.
pagefault wrote: |
I
ran the test again and it's not freezing at all for me.... Anyone else
want to test? I ran it on all 3 revisions of SNESes I have including
the PAL one. |
No. Again, FitzRoy confirmed the bug. I trust his testing ability, so
his verification is good enough for me. I won't look at it even if you
and others can't reproduce the crash. It's not as if I could anyway, my
copier can't run the game to compare code with.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 14, 2008 4:53 am Post subject: |
|
Running that file generates a 13.4kb "test_timing" executable. If I try to run that, nothing happens. Not even an error message.
Quote: |
I
ran the test again and it's not freezing at all for me.... Anyone else
want to test? I ran it on all 3 revisions of SNESes I have including
the PAL one. |
Well, that's pretty weird. What flash cart are you using?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 14, 2008 5:29 am Post subject: |
|
You
execute the program on the command line, right? It prints output there.
Double clicking inside something like konqueror, dolphin, nautilus,
thunar, etc won't show anything.
You have to be in that folder on the command line and type "./test_timing" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 14, 2008 6:10 am Post subject: |
|
Quote: |
application must be compiled with optimizations disabled for this to work
clocks per second = 1000000
2140000 clocks / 50,000,000 subroutine calls (50000000 iterations)
24950000 clocks / 100,000,000 co_switch calls (50000000 iterations)
co_switch skew = 11.658879x
done. |
Okay, that's what the output looks like.
Last edited by FitzRoy on Mon Jan 14, 2008 6:16 am; edited 2 times in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 14, 2008 6:15 am Post subject: |
|
Awesome!! :D
The overhead of SJLJ on the PS3 is roughly the same as my assembly
optimized version on x86. Okay, then. bsnes should definitely be
portable to the PS3.
Now let's see ... can you paste the output of the command "xvinfo" for
me? That'll tell us if the default video driver will work for you.
After that, I'm at a loss. I know which libraries you need (xv, gtk+2,
openal optional, libao optional), but not how to install them. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 14, 2008 6:20 am Post subject: |
|
Quote: |
X-Video Extension version 2.2
screen #0
no adapters present |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jan 14, 2008 9:54 am Post subject: |
|
FitzRoy wrote: |
Quote: |
application must be compiled with optimizations disabled for this to work
clocks per second = 1000000
2140000 clocks / 50,000,000 subroutine calls (50000000 iterations)
24950000 clocks / 100,000,000 co_switch calls (50000000 iterations)
co_switch skew = 11.658879x
done. |
Okay, that's what the output looks like.
|
Yay.
byuu: I think it's safe to assume my SJLJ will work on any modern Linux anywhere, and most UNIXes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Jan 14, 2008 11:59 am Post subject: |
|
FitzRoy wrote: |
Yeah,
I'm not trying to dictate and maybe I'm still wrong. I just don't
personally understand moving the patching process into the emulator. I
understand the loathsomeness of GoodTools and have always shared it.
But does soft-patching really stop Cowering from doing what he's doing
or challenge the popularity of it? Not really. |
The best argument for soft-patching is that the distribution-format
(patches and documentation) is also the usage-format. If your friend
likes a patch you're playing with, you can give him the original bundle
you downloaded, and make use of it immediately. With hard-patching, the
patch you download is useless on its own, so you patch a copy of the
ROM to produce the usage-format then throw away the distribution
format. If your friend likes a patch you're playing with, you can be a
dick and tell her to go download it herself, or you can just hand over
the pre-patched ROM while the Ghost of Cowering laughs mercilessly in
the background.
The best argument against soft-patching is probably the horrible complication
of detecting and decoding all possible input formats to get a sensible
image to patch - but if you're writing an emulator you have to do this
work anyway.
So no, the Ghost of Cowering will always be with us and soft-patching
won't solve that, but a really easy soft-patching implementation would
encourage people away from that fate.
While I'm here, some feature requests for this hypothetical soft-patching implementation in bsnes:
- Have
a directory somewhere (~/.bsnes/patches or My Documents\BSNES Patches
or something) that bsnes automatically looks in for potential patches.
- When loading a ROM, look in that directory for the first patch that "matches" the ROM. If one is found, apply it.
- Temporarily display a message like "Loaded patch %s", so the user knows that a patch has been applied, and which one.
In
the above list, "matches" would be defined for a smart patch format as
something like "the TARGET_IMAGE_SHA1 field in the patch header matches
the SHA1 of the loaded ROM", and for a dumb patch format as "the
patch's filename matches the ROM's filename up to the last period". The
"%s" would be replaced with the "PATCH_NAME" field from the header of a
smart patch, or filename of a dumb patch. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 14, 2008 11:46 pm Post subject: |
|
Quote: |
no adapters present |
As I thought :(
There are no suitable output adapters at this time. GTK+ will work,
somewhat, but it won't be pretty. It puts video into a separate window.
Sadly, as the PS3 lacks 3D acceleration, I'm not even sure OpenGL can
be used. Maybe MESA can give playable framerates, but no matter what,
90+% of the overhead is going to be scaling the video output.
Quote: |
While I'm here, some feature requests for this hypothetical soft-patching implementation in bsnes: |
Those features all sound good to me. I'll need the advanced status bar
text option in there to allow the display of "patched" or something
there. I'm not sure a long patch name will fit very well, and popping
up a window upon each load seems kind of annoying.
Note that bsnes doesn't have a "write text to the PPU video output" option like ZSNES and SNES9x.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Jan 14, 2008 11:59 pm Post subject: |
|
I guess something for people making patches to keep in mind then is keep the name succinct.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 15, 2008 12:52 am Post subject: |
|
Quote: |
As I thought 
There are no suitable output adapters at this time. GTK+ will work,
somewhat, but it won't be pretty. It puts video into a separate window.
Sadly, as the PS3 lacks 3D acceleration, I'm not even sure OpenGL can
be used. Maybe MESA can give playable framerates, but no matter what,
90+% of the overhead is going to be scaling the video output. |
Poop. Guess I'll check back on it later this year.
Is GTK+ what the snes9x port uses?
|
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue Jan 15, 2008 1:15 pm Post subject: |
|
byuu wrote: |
Sadly,
as the PS3 lacks 3D acceleration, I'm not even sure OpenGL can be used.
Maybe MESA can give playable framerates, but no matter what, 90+% of
the overhead is going to be scaling the video output. |
It amuses me that scaling video output is one of the very few tasks in
bsnes that could even conceptually benefit from multi-threading.
byuu wrote: |
Those
features all sound good to me. I'll need the advanced status bar text
option in there to allow the display of "patched" or something there.
I'm not sure a long patch name will fit very well, and popping up a
window upon each load seems kind of annoying. |
Sure, a status-bar message would be fine. For dealing with long patch
names, I'd probably just leave it up to GTK's and Windows' automatic
truncation code. What with Unicode, combining characters and all that
junk, the correlation between "string length in bytes" and "text length
in pixels" is so vague as to be useless.
byuu wrote: |
Note that bsnes doesn't have a "write text to the PPU video output" option like ZSNES and SNES9x. |
Ahahaha, yes, you read my mind. :) The sexiest possible presentation
would be to overlay the text on top of the video signal much like
music-video channels briefly display the band and song name over the
top of each clip. I assume a program as portable as bsnes abstracts the
PPU-rendering-to-pixmap code away from the pixmap-rendering-to-GUI
code, so adding extra shiny text-rendering to that layer should be a
simple matter of hours of tedious programming for little-to-no
functional reward. :D
FitzRoy wrote: |
Is GTK+ what the snes9x port uses? |
Although there's a GTK+ port now (that uses OpenGL for scaling, I
think), I believe traditional snes9x does the scaling internally and
draws the result to the screen with raw X11 calls.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Jan 15, 2008 1:44 pm Post subject: |
|
Thristian wrote: |
so
adding extra shiny text-rendering to that layer should be a simple
matter of hours of tedious programming for little-to-no functional
reward.  |
The perfect task for byuu's secret army of code monkeys, surely.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Tue Jan 15, 2008 2:01 pm Post subject: |
|
Quote: |
The
sexiest possible presentation would be to overlay the text on top of
the video signal much like music-video channels briefly display the
band and song name over the top of each clip. I assume a program as
portable as bsnes abstracts the PPU-rendering-to-pixmap code away from
the pixmap-rendering-to-GUI code, so adding extra shiny text-rendering
to that layer should be a simple matter of hours of tedious programming
for little-to-no functional reward.  |
..You can do that on the renderer side. D3D has functions for font rendering through D3DX.... OpenGL can use a similar process...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 15, 2008 2:11 pm Post subject: |
|
Ok,
this is what I came up with for my input keysym map. It's the best I
can do. I dropped the keys that are altered by modifiers such as shift,
etc ... because that would mean having to support potentially every
language. Instead, I'm aiming for the minimal set of keys that should
be on every keyboard.
http://byuu.cinnamonpirate.com/temp/input.txt
Opinions welcome.
Quote: |
Although
there's a GTK+ port now (that uses OpenGL for scaling, I think), I
believe traditional snes9x does the scaling internally and draws the
result to the screen with raw X11 calls. |
That's really something I should add to bsnes, rather than rely on the
GTK+ blitter. Will be fun trying to find the correct API calls for
that, given only a buffer and an XWindow handle.
Quote: |
What
with Unicode, combining characters and all that junk, the correlation
between "string length in bytes" and "text length in pixels" is so
vague as to be useless. |
I have some plans for that, Windows has DrawTextEx which can be used
with DT_CALCRECT to determine the size an output string will require.
And I can perhaps take advantage of GTK+'s auto sizing of widgets to
calculate the length of text there.
This will be required for my GUI, which needs a window with a monospace
font that contains exactly ~80 characters per line.
Quote: |
..You
can do that on the renderer side. D3D has functions for font rendering
through D3DX.... Cool OpenGL can use a similar process.. |
You really need to think more about portability :P
It would be terrible program design to have the text only show up with
certain renderers (D3D, OpenGL) and not with the rest (DDraw, GDI, X11,
Xv, GTK+, SDL, ...)
If I do code this, I'll have to write the pixels to the output buffer
myself immediately before blitting to the screen.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 15, 2008 3:33 pm Post subject: |
|
Code: |
void SNES::audio_update(uint16 l_sample, uint16 r_sample) {
if(pcmfp) {
fput(pcmfp, l_sample, 2);
fput(pcmfp, r_sample, 2);
}
if(config::snes.mute == true) { l_sample = r_sample = 0x0000; }
snesinterface.audio_sample(l_sample, r_sample);
}
|
Don't like it. The audio hardware or generic audio drivers can mute
sound more efficiently. Software resamplers can optimize this case too
by switching off any processing for example..
You can get a good use of this to actually reduce cpu usage by letting
know the audio drivers that you are muting the sound. You mute your
sound and let OS knows it and optimize it (if your OS only knows how to
do it of course).
The most easy way to mute sound is to set API's volume controller to 0.
It do not require much programming and changes but will make program
wize, cleaner and faster!
_________________
quake2xp audio engineer
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 15, 2008 6:58 pm Post subject: |
|
_willow_ wrote: |
The most easy way to mute sound is to set API's volume controller to 0.
It do not require much programming and changes but will make program
wize, cleaner and faster! |
That most assuredly depends on the API.
In some APIs (pretty much anyone without a circular buffer thing), if
you want the sound muted, you just stop outputting sound.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Jan 15, 2008 7:58 pm Post subject: |
|
Quote: |
Quote: |
if ( muted ) sample = 0; |
Don't like it. The audio hardware or generic audio drivers can mute
sound more efficiently. Software resamplers can optimize this case too
by switching off any processing for example..
|
So, it just comes down to lost efficiency when bsnes is muted. How does
that compare with complexity added by having emulation have to handle
running without sound? I'm guessing it's not worth it. But your
compromise of just setting the driver volume to 0 wouldn't change
emulation or add any complexity.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 15, 2008 8:15 pm Post subject: |
|
blargg wrote: |
Quote: |
Quote: |
if ( muted ) sample = 0; |
Don't like it. The audio hardware or generic audio drivers can mute
sound more efficiently. Software resamplers can optimize this case too
by switching off any processing for example..
|
So, it just comes down to lost efficiency when bsnes is muted. How does
that compare with complexity added by having emulation have to handle
running without sound? I'm guessing it's not worth it. But your
compromise of just setting the driver volume to 0 wouldn't change
emulation or add any complexity.
|
Complexity?
Code: |
if(!config::snes.mute) { snesinterface.audio_sample(l_sample, r_sample); }
|
You get the idea.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 15, 2008 9:25 pm Post subject: |
|
It seems the disconnect here is that everyone seems to prefer taking advantage of specific APIs as much as possible.
Whereas I prefer using the APIs to the minimum degree necessary so that
I am guaranteed the same operation regardless of the API used.
Most audio APIs will have an option to mute sound, but it's going to
behave differently for each API. DirectSound will have to stop the
active source channel (or it will keep looping with the previous sample
blocks), which will stop the audio synchronization (eg the emulator
will run at uncapped speed), OSS3 (probably) only has the option to
change the global speaker settings, libao handles synchronization
internally, so if I stop feeding it samples it'll lag and/or stall out
waiting for more, and who knows with future APIs I might add.
Please don't correct me if any of the above specifics about any of
those APIs is incorrect. I'm making a general point which should still
be clear even if the specifics aren't correct.
Whereas by just simply outputting null samples, the audio mutes as soon
as the latency length runs out (~33ms), with virtually no audio
popping, and works with any API, regardless of buffering or
synchronization method.
To date, absolutely no one has complained about the quality of audio
muting, so it seems kind of silly to worry that much about it.
Last edited by byuu on Tue Jan 15, 2008 9:27 pm; edited 2 times in total |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Jan 15, 2008 9:26 pm Post subject: |
|
Yes, complexity if
bsnes uses audio output as the master timebase (I don't know how bsnes
handles timing). In this case, turning audio output off would require
the emulator to select between audio and another timebase, adding
complexity. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 15, 2008 10:30 pm Post subject: |
|
byuu wrote: |
It seems the disconnect here is that everyone seems to prefer taking advantage of specific APIs as much as possible.
|
I think there is currently only a 2 sided argument, whether to mute the
volume in the API wrapper or keep doing what we're doing.
However I will offer a 3rd option.
Instead of coding a check of config mute in the SNES core, check that
mute in every audio API wrapper we have, and each does whatever that
API does for muting.
Whether it be sending the volume to 0, ignoring output requests,
closing the device, calling the API's mute, or as currently being done,
just set the sample to 0.
The base class itself could do the work of setting the sample to 0, and
each API wrapper can overload that function if need be to do something
else. And ideally such logic should not be done within an SNES core.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Jan 15, 2008 11:23 pm Post subject: |
|
Nach
is very close to me. SNES processor mute must not depend on PC
behaviour. The optimization case is the application level mute of
course. ALL APIs preserve correct clocks for muted sound (volume 0),
but the trick here is you can set can set volume only ONCE, without
calling the same hack every other sample.
Quote: |
if ( muted ) sample = 0;
|
Yes, it's a kind of quick coding hack because it's not a natural
solution for PC or any other platform. Any API have virtually
independent volume controls and RAW streams.
byuu wrote: |
Whereas I prefer using the APIs to the minimum degree necessary so that
I am guaranteed the same operation regardless of the API used.
|
Seamless clocks ARE guaranteed on any API. And volume controls as well.
In some really rare cases the mute can be processed in software.
All i want to say the mute is just volume 0 and nothing changing it,
even "sample=0" (that is not 'real' mute). The difference is the
hardware do mute without polling the mute state in main program loops,
in your case you do the job yourself. But that's not all. Even if you
have doing-all-in-software API, you actually do processing twice - once
is your "sample=0" second is "0*volume" in API . Think about real complexity and "correct" data processing, not about quick shortcut hacks!
I tried to translate SNES volume controls to PC's one and it works, but
it's not correct processing flow and highly timings unsafe thing. So i
dropped it. I have 16 stereo channels right from the bdsp processor and
this is correct processing flow. So i keeping it. I'm not going to
translate SNES mute up to application level, but i'd like to see PC
application mute "native" way.
Just do the changes to API and code monkeys do the rest 
_________________
quake2xp audio engineer
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 15, 2008 11:43 pm Post subject: |
|
I have a fourth solution! Remove it and let people use speaker knobs and driver controls.  |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Jan 16, 2008 1:23 am Post subject: |
|
no,
no forth solution, because i think byuu is using audio frequency as
custom clock sometimes. For slowmotion or something like that. You
don't want to hear slooow soooouuund too 
_________________
quake2xp audio engineer |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 16, 2008 2:50 am Post subject: |
|
_willow_ wrote: |
Even
if you have doing-all-in-software API, you actually do processing twice
- once is your "sample=0" second is "0*volume" in API . Think about real complexity and "correct" data processing, not about quick shortcut hacks!
|
And if volume was 0, instead of doing 0*volume, it can now do sample*0, same difference.
It's only an optimization if the API/drivers/firmware does:
if (volume)
But then again, by the same token they can do:
if (sample)
Perhaps on the safe side, we should set both to 0 each time. In case
the whatever in question only checks one but not the other as an
optimization.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Jan 16, 2008 4:20 am Post subject: |
|
huh, same...
a
1) sample=0 (software set this every sample)
2) 0*volume (hardware)
b
1) volume=0 (software set this only once)
2) sample*0 (hardware)
There is not much difference on hardware side, but you must not forget
about "sample=0" hack. That's not optimization, that... simply coding
shortcut assuming the application volume is max by default.
The good thing with 0 volume the drivers are free to assume the whole data block is silence.
if (volume=0) throw off data block. The driver just need to preserve timers that's all.
if (sample=0) throw off sample. This case can't be optimized because comparing is more expensive can be.
That's the big difference. But honestly you don't need to dig so deep,
the only optimization i spoke about is a bit more clean sound
processing. I'd like to see mute(on) or mute(off) command calls coming
directly from MIU or on sound driver restart.
_________________
quake2xp audio engineer |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 16, 2008 7:59 am Post subject: |
|
Okay, new WIP.
But before you download it ... there's no Windows binary, because I
haven't finished porting some changes over to DirectInput yet. So it
won't compile just yet.
But, here's the changes anyway:
- fixed up the recursive descent math parser, it should reject 100% of invalid math now
- added a new header, new.hpp, by Nach. This allows for uint8_t *buffer
= new(zeromemory) uint8_t[65536]; //zeromemory == memset(buffer, 0,
65536);
- updated input.hpp more, and removed keymap.hpp completely -- this is why DirectInput is broken right now
- rewrote all of inputmgr.cpp, and InputCaptureWindow. The really ugly,
hackish code is now gone. InputCaptureWindow no longer needs to hijack
the main UI event loop to catch keycodes. Instead, a ~20ms polling
occurs that will alert event::key(up|down) of key changes. The really,
really good news about this, is that it also catches the UI keypresses
now, too. That means that I can now map GUI events to the joypad, or
alternate keys!! Expect that within the next release or two.
- ran krom's mode7 test -- holy hell, he has good eyes o.O -- took me
about 20 minutes to definitively tell which output looked correct on my
SNES. He was right of course, and I trusted him, but double
verification is always nice, right? Removed TRAC's theorem from the
mode7 code, and spruced up the formatting in that file a bit.
- a real emulation change!!
zones recently pointed out that anomie figured out that $213e.d4 was
PPU1 open bus. I'm pretty sure I was really thorough when I initially
added PPU1+PPU2 open bus (even verified CGRAM.d15 open bus (-much-
harder than it sounds)), but I guess I missed a bit ... odd. anomie
also said that $213e.d5 is basically tied to GND, so that should mean
it always returns 0. I read previously that it was some weird "no PPU
activity for ~40 frames" bit or something, but I don't even remember
where I saw that. I trust anomie anyway, so that means all PPU register
status bits should be accounted for. Thanks for the heads up, zones! :)
Now, of course, it's extremely
minor and it won't fix any games (there aren't any known bugs anyway),
but it's still nice to actually fix something in the core for a change. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Jan 16, 2008 9:14 am Post subject: |
|
byuu wrote: |
Ok,
this is what I came up with for my input keysym map. It's the best I
can do. I dropped the keys that are altered by modifiers such as shift,
etc ... because that would mean having to support potentially every
language. Instead, I'm aiming for the minimal set of keys that should
be on every keyboard.
http://byuu.cinnamonpirate.com/temp/input.txt
Opinions welcome. |
You have a big disclaimer about how it's perfectly legal to use "_0" as
an identifier inside a namespace... and then never actually do it.
Apps that process input according to 'the characters printed on the
key' are my pet hate because I the Dvorak layout, so Z and X or WASD
are not nearly as convenient as you might otherwise expect. In my ideal
world, you'd set keys by clicking on the action you wanted to define
("START", for example), then pressing the button you wanted to use; the
app would write down the platform-specific scancode, and then that key
should continue to work no matter what keyboard layout happens to be
active at the time.
I guess for that to work you'd need some kind of "what symbol does
scancode X produce at the moment" API, and I don't know how easy it is
to get at that information.
byuu wrote: |
Quote: |
Although
there's a GTK+ port now (that uses OpenGL for scaling, I think), I
believe traditional snes9x does the scaling internally and draws the
result to the screen with raw X11 calls. |
That's really something I should add to bsnes, rather than rely on the
GTK+ blitter. Will be fun trying to find the correct API calls for
that, given only a buffer and an XWindow handle.
|
wmbubblemon wrote: |
X11
really doesn't provide any simple way to deal with drawing stuff on
screen without messing with colormaps or other serious ugliness. If you
are familiar with game programming and that kind of stuff, you know
that screen is usually drawn on a back buffer and then switched, so the
user sees smooth animation instead of watching the screen redraw. X11
doesn't really have this feature, because even drawing to a off-screen
pixmap is still slow - and requires contacting the server, and still
requires dealing with colormaps. Solution is simple. GDK. Gimp Drawing
toolKit. |
My guess is that GDK does clever things with the X11 protocol directly,
rather than going through the Xlib API. Still, this might be a good place to begin looking.
byuu wrote: |
Quote: |
..You
can do that on the renderer side. D3D has functions for font rendering
through D3DX.... Cool OpenGL can use a similar process.. |
You really need to think more about portability :P
It would be terrible program design to have the text only show up with
certain renderers (D3D, OpenGL) and not with the rest (DDraw, GDI, X11,
Xv, GTK+, SDL, ...)
|
It doesn't seem to crazy to have the bsnes core output text streams as
well as video and audio streams. Leave it up to the GUI code to figure
out how to display messages like "55fps" or "Der Langrisser English
Translation" or "Paused" - whether by drawing it as a texture on a
translucent quad over the OpenGL display, or sticking it in a
status-bar, or just printing it to stdout (hello, SDL!).
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Jan 16, 2008 9:35 am Post subject: |
|
Thristian wrote: |
byuu wrote: |
Ok,
this is what I came up with for my input keysym map. It's the best I
can do. I dropped the keys that are altered by modifiers such as shift,
etc ... because that would mean having to support potentially every
language. Instead, I'm aiming for the minimal set of keys that should
be on every keyboard.
http://byuu.cinnamonpirate.com/temp/input.txt
Opinions welcome. |
You have a big disclaimer about how it's perfectly legal to use "_0" as
an identifier inside a namespace... and then never actually do it.
Apps that process input according to 'the characters printed on the
key' are my pet hate because I the Dvorak layout, so Z and X or WASD
are not nearly as convenient as you might otherwise expect. In my ideal
world, you'd set keys by clicking on the action you wanted to define
("START", for example), then pressing the button you wanted to use; the
app would write down the platform-specific scancode, and then that key
should continue to work no matter what keyboard layout happens to be
active at the time.
I guess for that to work you'd need some kind of "what symbol does
scancode X produce at the moment" API, and I don't know how easy it is
to get at that information.
|
I have to say that using scancodes as absolute character ids is
downright wrong. Unescaped data in sql querys wrong.
It must be properly mapped for it to be a character, if a character at all.
Last time I checked, things like the arrow keys had not standard characters.
The mapping is best left to the OS, as people do have non US Qwerty
keyboards. Dvorak is just the extreme example, I have for example a
Swedish Qwerty keyboard. Always fun to type paths in programs that uses
the wrong mapping.
So, unless you plan on getting the mapping right for ALL keyboards across multiple platforms, plain don't try it.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Jan 16, 2008 10:04 am Post subject: |
|
henke37 wrote: |
I have to say that using scancodes as absolute character ids is downright wrong. Unescaped data in sql querys wrong.
It must be properly mapped for it to be a character, if a character at all.
Last time I checked, things like the arrow keys had not standard characters. |
I was talking about bsnes using the keyboard as a 104-button joypad -
it doesn't care about what characters the key produces at all, it just
needs to know "the user said that scancode 0x42 means the SNES Start
button".
For actual text-entry, bsnes should of course let the OS do all the key-handling.
(for the record, byuu, I see your input.txt mentions things like lbrace and rbrace that not every keyboard has)
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Jan 17, 2008 2:01 am Post subject: Glad to help! |
|
byuu wrote: |
- ran krom's mode7 test -- holy hell, he has good eyes o.O |
Cheers man!
byuu wrote: |
-- took me about 20 minutes to definitively tell which output looked correct on my SNES. |
That is my fault, I should have circled the areas I looked at to give
you the easiest way to check it, I am very sorry 
byuu wrote: |
He was right of course, and I trusted him, but double verification is always nice, right? |
I am glad that you trusted me =D
I would want the author of one of the best emulators in the world to
second check that his mode7 rendering is 100% perfect, so yeah double
verification is always nice 
If there is any other areas in the bsnes ppu rendering code that you
want me to verify in a similar fashion, please tell me, so that I can
try and code something to prove if it is right.
Cheers byuu =)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 17, 2008 6:48 am Post subject: |
|
Okay, new WIP. This time there's a Windows binary.
I improved input.hpp a lot, and now InputManager will scan the joypads
as well. DirectInput is fixed, so the Windows port works again. Now
that the InputCaptureWindow stuff is cleaned up, I made it only capture
joypad assignment keypresses when that window has focus.
I'm also planning to make a "fast assign all keys" button or something,
like I used to have. Not sure how I want to do that just yet.
I also tested triggering UI events through the joypad, it works great :)
Now I just need to add entries to Input Configuration window for each
UI action. Hmm, should I list the UI entries above or below the SNES
joypad entries? (eg ui.fullscreen, joypad1.up, ... or ...
joypad2.start, ui.fullscreen?)
The rest of my time tonight I spent working on my cross assembler,
xkas. Added sublabels to it, and some more parsing improvements. It's
getting messy already, though. Trying to write complex grammar parsers
in C++ usually does. But it has to be pure C++. No yacc, flex, etc. So,
I'll have to go back through and find redundant code to factor out. Why
would you care about xkas? Well, the sooner I get that done, the sooner
I can help out the Mother 3 translation project a bit more. GBA cross
assemblers suck for ROM hacking.
Quote: |
You
have a big disclaimer about how it's perfectly legal to use "_0" as an
identifier inside a namespace... and then never actually do it. |
I was using it for joypad button IDs, but I just decided to go with
button_0n. I removed the comment in the latest WIP. Also added a way to
index joypad IDs at runtime, and packed the enums into a linear list.
Quote: |
Apps
that process input according to 'the characters printed on the key' are
my pet hate because I the Dvorak layout, so Z and X or WASD are not
nearly as convenient as you might otherwise expect. |
Would require supporting every keyboard in existence, and needing some
sort of lower-level stuff to translate keycodes to raw keyboard IDs.
The only issue you'll have to reassign your keys one time on first
startup :(
I envy you though for managing to switch to dvorak. I tried for a
really long time, I could never get above ~40wpm, whereas I get ~110wpm
with qwerty now. I think programming is the worst part, all of my
brackets moved? Well, that or the fact that all apps use Ctrl+C/X/V/Z.
That hack to make Ctrl+ use qwerty on dvorak doesn't solve the
underlying issue, either.
Quote: |
If
there is any other areas in the bsnes ppu rendering code that you want
me to verify in a similar fashion, please tell me, so that I can try
and code something to prove if it is right. |
Hahah, there sure are :)
I think the biggest one is that I've yet to test setting BG3 tilesize
to 16x16 when using Mode2/4/6's offset-per-tile mode. Does it affect
indexing? I don't think that it does. May want to also toggle BG1/2
tilesize, just for fun, but I'm almost certain I have that right
already.
Don't worry about it if you're busy. It's obviously not a big deal
since no game in the world uses the effect (that, or I already emulate
it correctly), and I'll no doubt get around to it if I ever rewrite the
PPU emulation.
Either way, many thanks for helping me with this :D
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Jan 17, 2008 9:10 am Post subject: |
|
byuu wrote: |
Why
would you care about xkas? Well, the sooner I get that done, the sooner
I can help out the Mother 3 translation project a bit more. |
Yay, Mother 3!
Quote: |
Quote: |
Apps
that process input according to 'the characters printed on the key' are
my pet hate because I the Dvorak layout, so Z and X or WASD are not
nearly as convenient as you might otherwise expect. |
Would require supporting every keyboard in existence, and needing some
sort of lower-level stuff to translate keycodes to raw keyboard IDs.
|
I guess I'm kind of confused about what you're trying to achieve. My
idea was that - to use SDL as an example API - when the user bound a
key to a function, bsnes would listen for the next SDL_KeyboardEvent, grab event->keysym.key,
and store that integer in the config somewhere. Then at runtime when
bsnes gets a keyboard event whose keysym.key matches the stored one, it
would trigger the function in question. To display the bindings to the
user in the UI, you'd use SDL_GetKeyName() to get a vaguely human-readable description.
GDK supports the same sort of thing - GdkEventKey has a keyval field which can be converted to a name with gdk_keyval_name() - and I assume OS X and Windows would have similar API calls.
None of that requires bsnes to have any knowledge of keyboard layouts
at all - Maybe bsnes is already doing something like that, and you're
talking about something else?
Quote: |
I
envy you though for managing to switch to dvorak. I tried for a really
long time, I could never get above ~40wpm, whereas I get ~110wpm with
qwerty now. I think programming is the worst part, all of my brackets
moved? |
I won't say it didn't take me quite a while to get used to it. :)
Probably the best thing about switching to Dvorak for me was it gave me
a chance to learn proper touch-typing - after years of
hunting-and-pecking QWERTY, there was no chance I'd ever be able to
retrain myself to touch-type there.
Quote: |
Well,
that or the fact that all apps use Ctrl+C/X/V/Z. That hack to make
Ctrl+ use qwerty on dvorak doesn't solve the underlying issue, either. |
I also had the benefit of learning Dvorak on the Mac, which has a
similar hack based around the Cmd key instead of Control. Unlike
Windows or Linux, though, the Mac is much more consistent about using
Cmd for keyboard shortcuts, so the hack was actually quite helpful.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Jan 17, 2008 2:27 pm Post subject: |
|
Thristian wrote: |
To display the bindings to the user in the UI, you'd use SDL_GetKeyName() to get a vaguely human-readable description.
GDK supports the same sort of thing - GdkEventKey has a keyval field which can be converted to a name with gdk_keyval_name() - and I assume OS X and Windows would have similar API calls. |
Just for the record, Windows has GetKeyNameText.
_________________
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: Thu Jan 17, 2008 4:15 pm Post subject: |
|
Thristian wrote: |
Probably
the best thing about switching to Dvorak for me was it gave me a chance
to learn proper touch-typing - after years of hunting-and-pecking
QWERTY, there was no chance I'd ever be able to retrain myself to
touch-type there. |
I pity people who don't/can't touch-type (on their keyboard layout of
choice). The only time I need to look at the keys nowadays is to type
numbers and the symbols on them.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 17, 2008 4:59 pm Post subject: |
|
Quote: |
GDK
supports the same sort of thing - GdkEventKey has a keyval field which
can be converted to a name with gdk_keyval_name() - and I assume OS X
and Windows would have similar API calls. |
There's a few problems with an approach like this:
1) DirectInput and raw XQueryKeymap don't have these handy
integer->key name conversion routines (to my knowledge).
2) I need consistency, and integer->string->integer conversion,
not just one way or the other. The config file stores the string names,
so that they can be edited by hand. string->integer at startup,
integer->string on close. Not that you'd ever want to copy it, but
the config file from bsnes/Linux is 1:1 compatible with the config file
from bsnes/Windows.
3) I need default keymappings for the majority of users. I need escape
to toggle the menubar, I need F11 to toggle fullscreen. I need input to
at least work somewhat when a user starts the emulator for the very
first time. Yes, I could pop open a "Hi new user, please configure all
joypad and UI keys for the first time" window or something, but meh.
Ugly. I like working right out of the box.
4) miu (Win32/GTK+ wrapper) uses these keycodes as well. I can see a
lot of applications that would need to know for sure what keysym
something applied to right away. Say you were making a text entry that
only took numbers, you'd need to know whether the key was 0-9 or not
before accepting it, etc. Therefore I need portable keysym values.
Quote: |
after years of hunting-and-pecking QWERTY, there was no chance I'd ever be able to retrain myself to touch-type there. |
Hah, I don't actually hunt and peck on QWERTY, but I did teach myself
how to type, and I sure as hell don't keep my hands steady on the home
row like you're supposed to. I fling them around wildly, and always
seem to hit the right keys somehow. I'm faster than most touch-typers
anyway, so apparently my strategy isn't all that bad ...
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Jan 17, 2008 5:18 pm Post subject: |
|
byuu wrote: |
Hah,
I don't actually hunt and peck on QWERTY, but I did teach myself how to
type, and I sure as hell don't keep my hands steady on the home row
like you're supposed to. I fling them around wildly, and always seem to
hit the right keys somehow. I'm faster than most touch-typers anyway,
so apparently my strategy isn't all that bad ... |
Same here, makes me feel a bit self-conscious, but it gets the job
done. Maybe at some point I'll re-teach myself touch-typing...
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Jan 17, 2008 7:27 pm Post subject: |
|
In Windows you can use MapVirtualKey to get the scancode of the current keyboard.
_________________
Watering ur plants. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 17, 2008 7:41 pm Post subject: |
|
MapVirtualKey, GetKeyNameText, etc all work with VK_* codes, eg GetAsyncKeyState.
While I could use that, I use DirectInput. And I'd still need
equivalent functions and such under Linux. And even then, I still have
the problems listed above :( |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Jan 17, 2008 7:53 pm Post subject: |
|
Jipcy wrote: |
Thristian wrote: |
Probably
the best thing about switching to Dvorak for me was it gave me a chance
to learn proper touch-typing - after years of hunting-and-pecking
QWERTY, there was no chance I'd ever be able to retrain myself to
touch-type there. |
I pity people who don't/can't touch-type (on their keyboard layout of
choice). The only time I need to look at the keys nowadays is to type
numbers and the symbols on them.
|
ha, I should try Dvorak sometime, there are like 3 or 4 different types
right? It's funny, I had to take a typing class in 7th grade and did
terrible, that summer one of my best friends moved away and I started
writing a lot of letters and all of a sudden I could instantly use all
those touch typing skills I was taught 
right now I actually use the International keyboard setup right now,
allowing me to type accented letters etc. easier.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Jan 17, 2008 9:47 pm Post subject: |
|
Yeah
so I use DirectInput too, I use GetDeviceState or whatever it's called
to get me an array of the keyboard then I use the VK functions to map
them so it works with international keyboard layouts. I don't like DIK
because i've found it to be missing some keys and it ignores the
current keyboard set using the IME, using the first installed keyboard
instead. Plus you can map all those wonderful macro keys like on the
gaming keyboards. Plus it gives a common denominator with SDL which can
use a similar array I don't have to write input processing code for
each OS, only the code to read it into the array. But I don't know much
about the linux side of things I just let SDL do input, it's about the
only thing it's good at.
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Jan 18, 2008 2:22 am Post subject: |
|
byuu wrote: |
Hmm,
should I list the UI entries above or below the SNES joypad entries?
(eg ui.fullscreen, joypad1.up, ... or ... joypad2.start, ui.fullscreen?) |
I think actual game controls should show up first with the UI options
last. Game controls are essential and most people probably don't keep
the presets. Right now, the typical user can setup his controls without
even using the scrollbar, and that's good.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Jan 18, 2008 3:16 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
Hmm,
should I list the UI entries above or below the SNES joypad entries?
(eg ui.fullscreen, joypad1.up, ... or ... joypad2.start, ui.fullscreen?) |
I think actual game controls should show up first with the UI options
last. Game controls are essential and most people probably don't keep
the presets. Right now, the typical user can setup his controls without
even using the scrollbar, and that's good.
|
sounds smart, to me it doesn't really matter the order, but FitzRoy puts forward a very good point.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Jan 18, 2008 8:11 pm Post subject: |
|
It is a while since somebody last brought it up.
I still think that save states is 100 % possible, even with the custom threading library.
So what if it needs to return to separate stacks that is not on a fixed location?
Just run each cpu loop until it hits the right yeld call and then once that all are in sync, edit their state data.
So, it is just a matter of adding a special run to right yeld mode for
the threading library that can be used to do this. And a callback to
complete the state loading.
I heard that Nach was working on something to make one future prof save state file format or something.
Sure, it can't solve things like one emulator using a opcode accurate
implemention while another is using a cycle accurate one. But the data
itself is safe from the future. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 19, 2008 5:47 am Post subject: |
|
Quote: |
But I don't know much about the linux side of things I just let SDL do input, it's about the only thing it's good at. |
Hahah, quoted for truth.
Quote: |
I
think actual game controls should show up first with the UI options
last. Game controls are essential and most people probably don't keep
the presets. Right now, the typical user can setup his controls without
even using the scrollbar, and that's good. |
Done and done. Thanks!
Quote: |
Just run each cpu loop until it hits the right yeld call and then once that all are in sync, edit their state data. |
You can run until one is in sync (at a stoppable point that can be
re-entered from), but the others won't be. If you run the others to get
them at a stoppable point, then the one you had synced earlier won't be
synced anymore.
You can add more and more sync points to make the code more re-entrant,
but those entry points have another name: state machines. The very
thing libco was meant to avoid depending upon! The more precision you
get with your sync points, the more pointless using libco is in the
first place. They also add program overhead.
You can't just dump a cothread's stack memory and then reload it. It
doesn't work that way ... the stack has pointers to heap allocated
functions, absolute locality references, etc that will be broken when
you load in a new state.
Savestates are theoretically possible using mozz' method. Log all bus
accesses to a file on save until a safe stopping point. Then on load,
deplete the saved logs and then resume normal emulation. The problem is
that the actual implementation is a lot more complex than that. For
one, there are also non-bus elements at play, such as PPU V/Hblank
signals (though in theory, you could log those as well.) And
virtualizing the bus read/write functions, rather than inlining them,
will carry substantial
performance penalties for bsnes. One of the unfortunate WTF's in bsnes'
code is the required ordering of header files, because some headers use
forceinline mode on those read/write functions. You can't forceinline
when the code is not in the header. Sure, you can tell it to, but the
compiler will laugh and ignore you.
And in the
worst case scenario, I'll spend months adding this feature, only to
find out that we overlooked a minute detail, which makes this approach
fail in practice. Then I'd be stuck weeding out months' worth of broken
savestate code.
Anyway, if you really want to give it a shot ... download the latest
libco, and make a simple test application with a few threads, and try
and come up with a model to save and reload those threads. If your
model is proven well enough, I'll attempt adding it to bsnes.
Nach was looking into something known as process freezing. Think of it
as application-level savestates. Unfortunately, the PC industry hasn't
really looked into this idea very much, despite countless potential
uses. Imagine how much it could help with sleep / hibernation mode, for
example.
And you know, as much as I want savestates (and I really do, they're practically required for a real
debugger), I have to admit that not having them has made gaming fun and
challenging again for me. I recently played through Dracula X. Though I
did use a Game Genie code, you can't cheat your way around falling down
pits, so you're forced to use actual skill. It actually made the game
exciting again. If I ever do add savestates, I guarantee I'll be adding
a config file option to disable them that can't be enabled without an
emulator restart :)
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Jan 19, 2008 7:24 am Post subject: |
|
byuu wrote: |
And you know, as much as I want savestates (and I really do, they're practically required for a real
debugger), I have to admit that not having them has made gaming fun and
challenging again for me. I recently played through Dracula X. Though I
did use a Game Genie code, you can't cheat your way around falling down
pits, so you're forced to use actual skill. It actually made the game
exciting again. If I ever do add savestates, I guarantee I'll be adding
a config file option to disable them that can't be enabled without an
emulator restart  |
You couldn't be more right... savestates make me so incredibly lazy.
Playing games like the Mega Man X series without states is always a
thrill for me. As for the option to disable them (assuming states ever
do come to fruition), I think it's an amazingly unnecessary but
hilariously awesome idea. You could have them turned off by default
too, to scare off n00bs (silly n00bs, you know I love you).
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sat Jan 19, 2008 8:11 am Post subject: |
|
Myself,
I only use savestates to speed up a process, such as the refining items
part of Akira's chapter in Live a Live. It'd be a bitch having to
reload each time the game didn't give you the right item. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Jan 19, 2008 8:20 am Post subject: |
|
I
only use save states when I need to quit a game and I'm not in a
savable place, to capture passwords so I don't need to write them down,
and when I'm so pissed off at the game I don't care HOW I beat it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 19, 2008 8:46 am Post subject: |
|
Gil_Hamilton wrote: |
I
only use save states when I need to quit a game and I'm not in a
savable place, to capture passwords so I don't need to write them down,
and when I'm so pissed off at the game I don't care HOW I beat it. |
agree with byuu on savestates whoring...it just ruin the fun hence why
I don't care for savestates and why I never use them. I see them as a
debugger's tool -to quickly get to a point where there might be an
emulation bug for example. Not for actual playing.
I loathe savestates so much that I'll actually take the time to write
passwords (such as in Metroid). and I consider such cases as you
describe above perfectly legitimate, non cheating uses for savestates,
I'm just insane in that way.
And yes,even the ultra frustrating games you just want to finish already...I don't use them even in those cases.
Note the presence
of savestates in emulators doesn't really bother me...as long as the
emulator doesn't actually force me to use the function I'm fine with
it's implementation. You could say I'm used to not using them.
edit: Sure, the first time I tried savestates I thought it was cool
(wow, I can control times lolz I'm invincible!) but 5 minues
later..."wow...this makes the game boring..."
But I guess some people develop a dependence on them or something
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Jan 19, 2008 9:17 am Post subject: |
|
Snark wrote: |
I
loathe savestates so much that I'll actually take the time to write
passwords (such as in Metroid). and I consider such cases as you
describe above perfectly legitimate, non cheating uses for savestates,
I'm just insane in that way. |
Getting pissed and using states to rape the game is non-cheating?
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Jan 19, 2008 12:11 pm Post subject: |
|
byuu wrote: |
Quote: |
Just run each cpu loop until it hits the right yeld call and then once that all are in sync, edit their state data. |
You can run until one is in sync (at a stoppable point that can be
re-entered from), but the others won't be. If you run the others to get
them at a stoppable point, then the one you had synced earlier won't be
synced anymore.
|
My idea is to just run each thread to the right stop place and then,
like in F1 races, swap everything while it has a pit stop.
It is not important what each thread does until it goes to the yield
call. The point is that once that point is reached all logical state
data is overwritten with data from the savestate. The run of the code
up to the right yield call is just a dummy run that is technically just
wasting a little time to get stuff to the right place.
And for the overhead, I would expect the minimum data needed info to be the return address, that is already saved.
The library is free to save the return address and compare it and stuff.
But it still needs a portable state id, like
YEILD_THATCHIP_CYCLEXYDONE, if you want savestates that will work on
two different compilations.
But this does not mean you can't have two separate build variations,
one with shareable save states and one with build dependent ones.
It's like assert, if you want speed and don't care for the feature,
leave it out. If you want the feature, include it.
Pointers to stuff can be saved and remapped with a small lookup table,
you can even use the old addresses as the mapping keys.
All the misc sync data, like how long it is until things like VBLANK
will happen is easy to save, it is just another number, big deal.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Jan 19, 2008 12:29 pm Post subject: |
|
henke37 wrote: |
easy to save |
*demands proof by custom bsnes build* 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 19, 2008 8:04 pm Post subject: |
|
Gil_Hamilton wrote: |
Snark wrote: |
I
loathe savestates so much that I'll actually take the time to write
passwords (such as in Metroid). and I consider such cases as you
describe above perfectly legitimate, non cheating uses for savestates,
I'm just insane in that way. |
Getting pissed and using states to rape the game is non-cheating?
|
Well, yeah it is actually. But using them when you cannot save in-game
and as a way to save passwords is legitimate imo (heck, I do it with my
VCR)
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sat Jan 19, 2008 9:04 pm Post subject: |
|
Would
you consider using the Virtual Console's suspend mode cheating, too? I
mean, I think some games, especially the Contra series, it should be
used so one doesn't go crazy of having to go through the same level
over and over. Heck, I use it all the time in BOF2, etc.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Jan 19, 2008 9:12 pm Post subject: |
|
Snark wrote: |
Well,
yeah it is actually. But using them when you cannot save in-game and as
a way to save passwords is legitimate imo (heck, I do it with my VCR) |
Well, there you have it, folks! If his VCR can do save states, why can't bsnes?
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Jan 19, 2008 11:36 pm Post subject: |
|
DancemasterGlenn wrote: |
Snark wrote: |
Well,
yeah it is actually. But using them when you cannot save in-game and as
a way to save passwords is legitimate imo (heck, I do it with my VCR) |
Well, there you have it, folks! If his VCR can do save states, why can't bsnes?
|
I meant I use the VCR to record passwords.
The equivalent in bsnes would be to implement movie recording...which
would require save states support I guess to work in the first place.
Quote: |
Would you consider using the Virtual Console's suspend mode cheating, too? |
I never used N's Virtual console so I couldn't say. Does it allow you
to resume the same save/resume multiple times? Or is it erased once you
load it? If it's the former, definitely since that would work like a
normal savestate.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Jan 19, 2008 11:53 pm Post subject: |
|
Snark wrote: |
I
never used N's Virtual console so I couldn't say. Does it allow you to
resume the same save/resume multiple times? Or is it erased once you
load it? If it's the former, definitely since that would work like a
normal savestate. |
I
believe if you load a savegame up it is still there but quitting the
game overwrites it with a new save. If you turn the console off after
loading it then I think you can still load the same save when you turn
it on. I don't own a wii tho.
_________________
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.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 19, 2008 11:54 pm Post subject: |
|
Snark wrote: |
Quote: |
Would you consider using the Virtual Console's suspend mode cheating, too? |
I never used N's Virtual console so I couldn't say. Does it allow you
to resume the same save/resume multiple times? Or is it erased once you
load it? If it's the former, definitely since that would work like a
normal savestate.
|
you don't ever actually actively save it. here is how it works.
when you quite, it makes a savestate, so when you boot it up next time,
it starts you where you were last time, and is automatically
paused.That way you can play a bit at a time. it's not like you can
reload something if you died though or anything, it's a resume function.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sun Jan 20, 2008 12:01 am Post subject: |
|
AFAIK,
it only makes one "save" per game, but N64 games are the only type of
games that don't have it (for some weird reason). You can make one for
several games (the wii doesn't limit just one, but lets one make
several). Of course once it's, loaded it's gone. Very nice before you
get to a tough boss or level!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 20, 2008 1:35 am Post subject: |
|
Well,
again, the fun that savestates take away from the game is no excuse not
to have them, and I'm not trying to make it seem like that. They're
sorely missing in bsnes :(
I added something new
to the Linux/BSD ports tonight though, that should make some people
happy: joystick support! :D
It uses SDL, since as pagefault so eloquently put, it's the only thing
SDL is good at. Of course, that means no keyboard support when the SDL
driver is loaded, since SDL can't capture keypresses unless it owns the
window they are sent to. My plan is to use XQueryKeymap on the Linux
port, and GetAsyncKeyState on the Windows port. A minor annoyance, but
better than nothing.
This means that the only thing making the Linux port a second-class
citizen now is the video support. The Xv renderer is the strongest
piece there. While it can do hardware scaling, most systems lack an RGB
overlay surface, so you lose 50% chroma information.
Quote: |
And for the overhead, I would expect the minimum data needed info to be the return address, that is already saved.
The library is free to save the return address and compare it and stuff. |
You make that sound a lot easier than it really is. Let me give you a small example:
Code: |
void CPU::run() {
...
CPU::opcode_lda_addr();
...
}
void CPU::opcode_lda_addr() {
...
add_clocks(4);
uint8_t rd = Memory::read();
...
}
void CPU::add_clocks(uint clocks) {
...
Scheduler::synchronize();
...
}
void Scheduler::synchronize() {
...
co_switch(thread_smp); //SMP is behind CPU, CPU write may affect SMP read
//(1)
} |
Let's say we grab a savestate where the CPU's last action was switching
to the SMP above. How do you propose I save the "return address" in
this case? Whenever I reload a savestate and call co_switch(thread_cpu)
for the first time with a new stack, it will enter at the very top of
CPU::run(), but I need to get the execution position to (1) above.
The only way to do that would be to add switch(state) statements around
each function, and export the required patterns, eg:
STATE_CPU_RUN_STATE_OPCODE_LDA_ADDR + STATE_CPU_OPCODE_LDA_ADDR_CYCLE_4
+ STATE_CPU_LDA_ADDR_CYCLE_4_SCHEDULER_SYNCHRONIZE +
STATE_SYNCHRONIZE_SYNC_SMP.
... and the code will look horrendous. And be a lot slower. It will
completely defeat the purpose of using cothreads in the first place.
And you might be saying, "well, somehow magically extract the return addresses from the stack heap memory!"
Ignoring the fact that's really quite impossible, those values would be
platform-specific, and there will still be more stack data (function
arguments, etc) that needs to be saved and restored. And it's
inevitable that some of that data will be dependent upon the memory
layout, which changes each time you save and load a state.
If you still don't believe me, I'll go ahead and make a small-scale
test application. If you can add savestates to it, then we'll go from
there. Who knows, maybe you have some tricks that nobody else has been
able to come up with thus far. I won't say it's impossible. Some people
thought my cothread idea was impossible, so there you go :)
|
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 20, 2008 2:25 am Post subject: |
|
franpa wrote: |
Snark wrote: |
I
never used N's Virtual console so I couldn't say. Does it allow you to
resume the same save/resume multiple times? Or is it erased once you
load it? If it's the former, definitely since that would work like a
normal savestate. |
I
believe if you load a savegame up it is still there but quitting the
game overwrites it with a new save. If you turn the console off after
loading it then I think you can still load the same save when you turn
it on. I don't own a wii tho.
|
If this indeed works (perhaps someone who own a wii could test it) that would be a lot of hassle just to cheat.
edit: What a terribly way-off topic manner to start a new bsnes page...sorry.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Jan 20, 2008 5:03 am Post subject: |
|
byuu wrote: |
Nach was looking into something known as process freezing. Think of it
as application-level savestates. Unfortunately, the PC industry hasn't
really looked into this idea very much, despite countless potential
uses. Imagine how much it could help with sleep / hibernation mode, for
example.
|
You're both right. Or perhaps both wrong.
I've been looking into something to make save state more future proof (and totally unrelated to bsnes).
I've also been looking into process freezing with regard to bsnes.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Jan 20, 2008 10:37 am Post subject: |
|
byuu wrote: |
You make that sound a lot easier than it really is. Let me give you a small example:
Code: |
void CPU::run() {
...
CPU::opcode_lda_addr();
...
}
void CPU::opcode_lda_addr() {
...
add_clocks(4);
uint8_t rd = Memory::read();
...
}
void CPU::add_clocks(uint clocks) {
...
Scheduler::synchronize();
...
}
void Scheduler::synchronize() {
...
co_switch(thread_smp); //SMP is behind CPU, CPU write may affect SMP read
//(1)
} |
Let's say we grab a savestate where the CPU's last action was switching
to the SMP above. How do you propose I save the "return address" in
this case? Whenever I reload a savestate and call co_switch(thread_cpu)
for the first time with a new stack, it will enter at the very top of
CPU::run(), but I need to get the execution position to (1) above.
The only way to do that would be to add switch(state) statements around
each function, and export the required patterns, eg:
STATE_CPU_RUN_STATE_OPCODE_LDA_ADDR + STATE_CPU_OPCODE_LDA_ADDR_CYCLE_4
+ STATE_CPU_LDA_ADDR_CYCLE_4_SCHEDULER_SYNCHRONIZE +
STATE_SYNCHRONIZE_SYNC_SMP.
... and the code will look horrendous. And be a lot slower. It will
completely defeat the purpose of using cothreads in the first place.
And you might be saying, "well, somehow magically extract the return addresses from the stack heap memory!"
Ignoring the fact that's really quite impossible, those values would be
platform-specific, and there will still be more stack data (function
arguments, etc) that needs to be saved and restored. And it's
inevitable that some of that data will be dependent upon the memory
layout, which changes each time you save and load a state.
If you still don't believe me,...
|
Let's make one thing clear here, you and I agree on the fact that for
portable save states, we need to name every single point that each
thread can be swapped out at.
What I propose in addition to that is non portable save states.
And no, it is not impossible at all to read the return address from the stack.
The only difference in speed in my design is an additional integer in the function call.
What is key in my design is that you don't have to change the design of
the code, no algorithm changes. My method is so generic that any
cooperative threading system can be save stated with it. As long there
is a sync call.
And about the loading part, you did not seem to understand my trick.
Yes, it does start at CPU::run. But the trick here is that when
loading, we feed it the data that causes it to move to the right sync
call. We ignore what it does with the data, it is just a trick to get
it into the right position.
Once the thread is swapped out, the data in the thread is completely
ignored and overwritten with data from the save state(remapped as
needed).
Also, you claim that the memory layout may be different at each time.
So what? How do you think exceptions with their unrolling of the stack
is supposed to work? (Rhetorical question) It is smart enough to
understand the stack frames, so why can't the threading library
understand them?
And here is another method that I just came up with:
And seriously, if we understand the stack frames, what prevents us from
parsing them, saving the data in a portable format and later pre filing
the stack with the data and then "returning" to the function?
If the return-to-libc exploit methods can fake stack entries, why can't we?
The computer knows no difference.
Yes, it is portable, the data on the stack is after all just the
function's local variables, the return address and the arguments to the
function. That data does not change. Sure, the format of the data can
be different, but it is still the same values, just in different
formats.
Sure, the actual binary format is very platform, compilator and build
setting specific. But the data that is stored is not.
To summary, if we know the stack frame format, we can easily freeze a
full callstack, by reading the stack frames into a portable format and
then later regenerating equivalent stack frames.
To know the stack format, we could use that debugging info the compiler
can generate. That makes it reasonable, since we no longer need to
manually figure out the format of each stack frame.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 20, 2008 11:12 am Post subject: |
|
Alright, OpenGL is the worst API I have ever had to work with in my entire fucking life.
It took me six hours just to get glXMakeContextCurrent to stop crashing.
GTK+ creates X windows using Visual ID 0x21, yet glX wants Visual ID
0x29. What does xdpyinfo say? They're completely identical, of course.
No way to change the Visual ID on a realized GTK+ widget ... but I
could hack miu to do this during control creation, like so:
Code: |
/*//OpenGL GLX support
Display *xdisplay = XOpenDisplay(0);
int xscreen = DefaultScreen(xdisplay);
int elements = 0;
GLXFBConfig *fbconfig = glXChooseFBConfig(xdisplay, xscreen, 0, &elements);
XVisualInfo *glvisual = glXGetVisualFromFBConfig(xdisplay, fbconfig[0]);
GdkScreen *screen = gdk_screen_get_default();
GdkColormap *colormap = gdk_screen_get_default_colormap(screen);
GdkVisual *visual = gdk_colormap_get_visual(colormap);
if(GDK_VISUAL_XVISUAL(visual)->visualid != glvisual->visualid) {
visual = gdk_x11_screen_lookup_visual(screen, glvisual->visualid);
colormap = gdk_colormap_new(visual, FALSE);
gtk_widget_set_colormap(canvas, colormap);
}*/ |
Ugh. And make miu dependent on OpenGL? No thanks.
So another two hours later and I have:
Code: |
display = XOpenDisplay(0);
screen = DefaultScreen(display);
XWindowAttributes attribs;
XGetWindowAttributes(display, (::Window)canvas.handle(), &attribs);
GLXFBConfig selected = 0;
int elements = 0;
GLXFBConfig *configs = glXGetFBConfigs(display, screen, &elements);
for(int i = 0; i < elements; i++) {
int visualid;
glXGetFBConfigAttrib(display, configs[i], GLX_VISUAL_ID, &visualid);
if(visualid == attribs.visual->visualid) {
selected = configs[i];
break;
}
}
if(!selected) printf("failure\n");
int attribute_list[] = {
GLX_DOUBLEBUFFER, False,
GLX_RED_SIZE, 1,
GLX_GREEN_SIZE, 1,
GLX_BLUE_SIZE, 1,
GLX_ALPHA_SIZE, 0,
None,
};
fbconfig = glXChooseFBConfig(display, screen, attribute_list, &elements);
context = glXCreateNewContext(display, selected, GLX_RGBA_TYPE, NULL, False);
//context = glXCreateContext(display, &visual_info, NULL, False);
glxwindow = glXCreateWindow(display, selected, (::Window)canvas.handle(), NULL);
Bool result = glXMakeContextCurrent(display, glxwindow, glxwindow, context); |
Well, whatever. At least it's not inside miu.
Four more hours of trying to get mudlord's code to actually blit a 2D texture. Does every single API function in OpenGL require a PhD in mathematics and an IQ of 170+ to comprehend?!?! Christ!!
glPixelStorei:
Quote: |
GL_UNPACK_ROW_LENGTH
If greater than 0, GL_UNPACK_ROW_LENGTH defines the number of pixels in
a row. If the first pixel of a row is placed at location $p$ in memory,
then the location of the first pixel of the next row is obtained by
skipping $k ~=~~ left { ~ lpile { n l above {a over s left ceiling { s
n l } over a ^ right ceiling}} ~~ lpile {s ~>=~ a above s ~<~ a }$
components or indices, where $n$ is the number of components or indices
in a pixel, $l$ is the number of pixels in a row (GL_UNPACK_ROW_LENGTH
if it is greater than 0, the $width$ argument to the pixel routine
otherwise), $a$ is the value of GL_UNPACK_ALIGNMENT, and $s$ is the
size, in bytes, of a single component (if $ a < s$, then it is as if
$a = s$). In the case of 1-bit values, the location of the next row is
obtained by skipping$k ~=~ 8 a left ceiling { n l } over { 8 a } right
ceiling$
components or indices.
The word component in this description refers to the nonindex values
red, green, blue, alpha, and depth. Storage GL_RGB, for example, has
three components per pixel: first red, then green, and finally blue. |
... it looks like English, but ... what?! Seriously, is there a person in the world who understands "(if $ a < s$ n { | } { 8 a }" ? Were the authors of this smoking crack cocaine when they wrote that?!
All I want to know is what value to put there. If I have a 1024x1024
texture, then what row width do I want? It can't possibly be as complicated as these pages make it out to be!
With Direct3D9 + MSDN, you'd get something like:
"D3D_UNPACK_ROW_LENGTH: sets the number of bytes in a row. If your
texture is 256x256, and your bits per pixel is 32, that means there are
four bytes per pixel. Four times the width means you would use 1,024 in
this case."
And it just goes on and on. glOrtho, glMatrixMode, glTexCoord2i,
glVertex2i, glTexSubImage2D, etc etc etc. They're all completely
incomprehensible.
I give up. Nearly ten hours and I can't get anything but a white box
blitting to the screen. If anyone can comprehend this garbage, look at
the new WIP I posted ... ui/vai/video/video.glx.cpp. Any help is
greatly appreciated.
In comparison, it took me about two hours to write the D3D9 driver with
no experience working with that API and Microsoft's documentation.
Bravo, Microsoft. A+.
You would think there would be a tutorial out there somewhere
where someone said "okay, let me stick a 2D image into a texture and
blit it" ... in theory it should only be ~10 function calls or so. Yet
everything you find is either 20x more complicated than necessary, or
does all kinds of 3D stuff anyway. Really, it should be as simple as a
library function such as glBlitTexture2D(format, buffer, tex_x, tex_y,
tex_width, tex_height, screen_x, screen_y, screen_width,
screen_height); -- ah, but that'd just be too easy, wouldn't it?
Anyway, new WIP hacks in XQueryKeymap on top of SDL joystick support.
So you have keyboard + input now. And I've added five UI controlling
functions to the input config list thus far. More to come. No Windows
binary, and Linux binary defaults to the unbelievably broken GL driver.
You'll probably want to recompile with that set to Xv if you actually
want to use this WIP.
And henke37, my apologies, I'm way too work out from OpenGL to continue
debating the possibility of libco + savestates. I'll reply sometime
tomorrow.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Jan 20, 2008 11:26 am Post subject: |
|
byuu wrote: |
And
henke37, my apologies, I'm way too work out from OpenGL to continue
debating the possibility of libco + savestates. I'll reply sometime
tomorrow. |
No worry, practically everything that isn't in the standard feels like this.
Using other people's code usually sucks, especially if they don't ask you to RTFM, but to RTFS.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Jan 20, 2008 8:00 pm Post subject: |
|
byuu wrote: |
Alright, OpenGL is the worst API I have ever had to work with in my entire fucking life.
[... lots of rambling ...] |
Does any of these URLs help (just googled to try and find something that might help you):
- OpenGL V: Translating Windows DIBs (MSDN, you said the Microsoft API documentation was great, perhaps this is too?).
- Drawing Pixels, Bitmaps, Fonts, and Images - Controlling Pixel-Storage Modes (this one seems to be understandable english)
- Open GL Super Bible - Panning a Pixmap (seems to be plain english as well, with commented examples!)
- 2D-Drawing with OpenGL
- Drawing Tiles with OpenGL
- glPixelStore Subroutine
EDIT: One more (scroll up a little bit, it's #7, yes the image is pretty damn crappy):
- Avoiding 16 Common OpenGL Pitfalls - Watch Your Pixel Store Alignment
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Jan 21, 2008 12:29 am Post subject: |
|
Sorry for not getting back to you byuu. I've been quite busy on some university assignments which really need to be done.
Quote: |
Alright, OpenGL is the worst API I have ever had to work with in my entire fucking life.
It took me six hours just to get glXMakeContextCurrent to stop crashing. |
6 hours to get the rendering context right on Linux? Gosh Linux OGL must be a pain.
Quote: |
Four
more hours of trying to get mudlord's code to actually blit a 2D
texture. Does every single API function in OpenGL require a PhD in
mathematics and an IQ of 170+ to comprehend?!?! Christ!! |
I'm so sorry for putting you through hell on submitting incomplete code 
I was having similar issues getting it to blit right too, hence getting
a black screen, which suggests my context opening code works fine.
Quote: |
And
it just goes on and on. glOrtho, glMatrixMode, glTexCoord2i,
glVertex2i, glTexSubImage2D, etc etc etc. They're all completely
incomprehensible. |
Not really, but the documentation makes it so. All glTexSubImage() does
is output a image from a pointer, which in this case was that pointer
you use to get SNES image data. And which is needed. Unless we manually
create a blank texture using glGenTextures() and use glBindTexture to
manipulate it to get the image data we want.
Quote: |
Really,
it should be as simple as a library function such as
glBlitTexture2D(format, buffer, tex_x, tex_y, tex_width, tex_height,
screen_x, screen_y, screen_width, screen_height); -- ah, but that'd
just be too easy, wouldn't it? |
I agree. I wish GLUT was still alive so that we could use just that. OR it comes with later OGL specs.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 21, 2008 5:25 am Post subject: |
|
It is finally over.
http://byuu.cinnamonpirate.com/temp/bsnes_opengl.png
http://byuu.cinnamonpirate.com/temp/video.glx.cpp
Once I finally
got something appearing onscreen, it was easy to slowly figure out all
of the various other commands to get the image looking correct. It's
really depressing when it's 100x easier to figure out an API by trial
and error than by reading the documentation for it.
The cool part is that not only do you get full chroma information once
again, you have the option to enable or disable filtering. It's also a
lot faster than Xv.
So now I have to ask ... should I use OpenGL as the default Linux video
driver? People using open source drivers like nv would probably be
forced to change the config, though.
Same for libao. It sounds so much worse than OpenAL and OSS, but it's
probably more compatible. I'm also thinking of killing the GTK+
renderer, since I can't find a way to output to a GTK+ window given
only an X11 handle. The "spawn a separate window" bit is really tacky.
But wow, bsnes/Linux + OpenGL + OSS4/OpenAL + SDL Joystick Input = win.
The Linux port is finally on-par with the Windows port in every last
respect. Add to the fact that GCC4's PGO support actually works, and
you could even argue that it's superior to the Windows port!
Quote: |
I'm
so sorry for putting you through hell on submitting incomplete code. I
was having similar issues getting it to blit right too, hence getting a
black screen, which suggests my context opening code works fine. |
Oh no, it's no problem at all. I'm sorry I gave you that impression. In
fact, I really appreciate the code you did write, working or not. It
pointed me in the right direction. I really shouldn't expect others to
write code for me anyway. It's always very nice, but not realistic to
keep expecting that.
And by the way, the main problem with your code was that you never
created a texture for glTexSubImage2D to use. Your input buffer format
was also wrong. See my above code if you're interested.
Quote: |
I started a new thread to discuss the save state implementation: |
Much appreciated. I'll swing by when I can to respond.
Quote: |
Does any of these URLs help (just googled to try and find something that might help you): |
A little, yes. Though I will say the tutorials that advise to use
glDrawPixels are leading you in the wrong direction. I finally managed
to rig that API to flip my image and output it to the screen properly
(GL draws upside down because the developers are batshit insane), but
even with that horrible hack, the texture filtering wouldn't work, and
I'm sure pixel shaders would be out of the question.
My approach now uses glTexSubImage2D and a GL_TRIANGLE_STRIP. It's
actually faster than the glDrawPixels method, too. I really hate the
fact that modern video cards can draw a rectangle as two triangles
faster than it can as ... well, a rectangle.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Jan 21, 2008 6:06 am Post subject: |
|
Quote: |
Oh
no, it's no problem at all. I'm sorry I gave you that impression. In
fact, I really appreciate the code you did write, working or not. It
pointed me in the right direction. I really shouldn't expect others to
write code for me anyway. It's always very nice, but not realistic to
keep expecting that.
And by the way, the
main problem with your code was that you never created a texture for
glTexSubImage2D to use. Your input buffer format was also wrong. See my
above code if you're interested. |
I'm glad it at least pointed you in the right direction in how to do it. Sorry still about it not working . Thanks though for showing me the obvious in what was wrong in my code. I always miss little details like that .
I also looked over your code and its pretty good. I managed to make a
dirty port of it to Windows. Here's hoping it works just as well as it
does for you on Linux.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Jan 21, 2008 6:57 am Post subject: |
|
byuu wrote: |
Add to the fact that GCC4's PGO support actually works, and you could even argue that it's superior to the Windows port! |
Why does PGO makes it so good?
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Jan 21, 2008 6:59 am Post subject: |
|
It boosts speed, a lot.
PGO is a method of optimization that targets specifically parts that are known to be troublesome. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 21, 2008 9:02 am Post subject: |
|
I posted a lot of the recent progress on my webpage,
http://byuu.cinnamonpirate.com/bsnes/news/
Some of it hasn't been mentioned here.
If any Linux users could, please grab the latest WIP and try it out.
I'm most interested in how the OpenGL driver works for you. Note that
you'll need OpenGL support, obviously. The open source drivers such as
nv usually don't come with that out of the box. And ATI cards ... ugh.
Good luck. You'll need to set system.video to "opengl", since I still
default to Xv for video. I recommend also setting system.audio to
"openal", as that driver has the most features of any Linux drivers.
Leave system.input as "" (blank), and it will default to the SDL joypad
+ XQueryKeymap keyboard polling code.
Also, there's a Windows binary in this release.
Big changes in summary (see webpage for more info) include truly
centered video in fullscreen mode now (looks a lot better), video
output size clamping in both windowed and fullscreen modes (should
hopefully get rid of the invisible window problem), and Linux OpenAL
driver can disable speed regulation now. Meaning with OpenGL + OpenAL,
all GUI options work in Linux now. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Jan 21, 2008 9:16 am Post subject: |
|
mudlord wrote: |
It boosts speed, a lot.
PGO is a method of optimization that targets specifically parts that are known to be troublesome. |
Ah. Thank you for the info.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Mon Jan 21, 2008 9:26 am Post subject: |
|
How do I grab the WIP, again? I'd love to help test this one.
Also, I believe I've finally got oss4 installed? I can't tell if it's
working or if it's just defaulting everything to the old oss... not
exactly sure how to test that, everything just shows up as "OSS". Also
seems to have broken a lot of crap... like my midi composition software
(damn...) which I had finally gotten working in alsa... this is going
to take a lot of getting used to. Any suggestions would be appreciated. |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Mon Jan 21, 2008 10:04 am Post subject: |
|
I'll test the latest WIP as soon as someone tells me which libraries/programs I'm missing:
Code: |
main.cpp:(.text+0x1158a): undefined reference to `InputSDL::InputSDL()'
main.cpp:(.text+0x11619): undefined reference to `VideoGLX::VideoGLX()'
|
I really don't want to randomly compile some packages to see if bsnes
compiles. Actually I don't have OpenAL either, but it's easy to
disable. I think the project is slowly reaching the point where a
configure script is needed. If byuu doesn't want to write a configure
script, I think it would be relatively easy to add a few handy ifdefs.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jan 21, 2008 10:51 am Post subject: |
|
byuu didn't fix the Makefile for x86-64, here's a patch to make it work:
Code: |
--- Makefile-old 2008-01-20 11:08:54.000000000 +0200
+++ Makefile 2008-01-21 12:58:57.000000000 +0200
@@ -30,10 +30,10 @@
CFLAGS = -O3 -fomit-frame-pointer -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86_64 -DUI_MIU `pkg-config --cflags gtk+-2.0` -Ilib
AS = yasm
ASFLAGS = -f elf64
-LIBS = `pkg-config --libs gtk+-2.0` -lXv -lao -lopenal -lalut
+LIBS = `pkg-config --libs gtk+-2.0` `sdl-config --libs` -lXv -lao -lopenal -lalut -lGL -lGLU
LIBCO = libco.x86-64
MIU = miu.gtk
-VAI = video.xv.$(OBJ) video.gtk.$(OBJ) audio.openal.$(OBJ) audio.oss.$(OBJ) audio.ao.$(OBJ) input.x.$(OBJ)
+VAI = video.glx.$(OBJ) video.xv.$(OBJ) video.gtk.$(OBJ)
audio.openal.$(OBJ) audio.oss.$(OBJ) audio.ao.$(OBJ) input.sdl.$(OBJ)
input.x.$(OBJ)
endif
ifeq ($(PLATFORM),win-mingw-x86-cross)
|
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Jan 21, 2008 12:45 pm Post subject: |
|
Thanks Nach, now it compiles fine.
I tried setting system.video to both xv and opengl and I don't notice
any big difference between the two. Using OpenAL as audio driver so I
can turn of speed regulation and see how fast it can really get.
There's ~10FPS increase during the pendel swinging part, but as soon as
the text comes in it goes down to ~52-53FPS, just as Xv does. In
overall it seems to only add a few FPS above Xv for me. :-/
Using the nvidia driver (169.07) which is set up correctly and is working fine.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 21, 2008 2:14 pm Post subject: |
|
That
scene is one of the most intensive scenes the SNES has to offer; as far
as I know only the Dark (Black? I can't remember..) Omen appearing
trumps it (seen in the intro, as well as of course ingame) So that
slowdown is core emulation, and a change in video driver isn't likely
to help speed it up (unless Xv is really that much slower.. byuu does
mention it's slow on his homepage, but I doubt it's the bottleneck here) |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Jan 21, 2008 4:23 pm Post subject: |
|
Maybe
a demo showing hi-res color add/sub would be more demanding. With HDMA
effects. And Offset-Per-Tile changes. </guess>
The Black Omen scene uses Offset-Per-Tile changes.
EDIT: Range-Tile Offset? 0_o
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Mon Jan 21, 2008 7:51 pm; edited 2 times in total
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Jan 21, 2008 4:58 pm Post subject: |
|
Verdauga Greeneyes wrote: |
That
scene is one of the most intensive scenes the SNES has to offer; as far
as I know only the Dark (Black? I can't remember..) Omen appearing
trumps it (seen in the intro, as well as of course ingame) So that
slowdown is core emulation, and a change in video driver isn't likely
to help speed it up (unless Xv is really that much slower.. byuu does
mention it's slow on his homepage, but I doubt it's the bottleneck here) |
Yeah, but it's still not fullspeed with OpenGL on my machine. Even the
Super Mario Kart intro/title screen (before they show the ingame
action) is slow, ~50-52FPS with Xv, and ~50-53FPS with OpenGL. Though
ingame they both seem to be able to keep a steady 60FPS (using OpenAL
for audio).
Oh, and byuu, full screen still doesn't work for me.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 21, 2008 5:20 pm Post subject: |
|
Quote: |
How do I grab the WIP, again? I'd love to help test this one. |
Cool, thank you. I'll send you the link via PM.
Quote: |
Also
seems to have broken a lot of crap... like my midi composition software
(damn...) which I had finally gotten working in alsa... this is going
to take a lot of getting used to. Any suggestions would be appreciated. |
Yes, this is actually why I haven't been pushing OSS4 harder lately.
Linux distros these days have ALSA integrated so deeply that it makes
Windows/IE integration seem absolutely trivial. They even intentionally
compile everything with OSS support disabled (most apps have it, as
they also need to work on *BSD.)
There's a workaround for 99% of things, though. It's just that you have
to do it on an almost application-level basis.
For WINE, there are OSS packages, I forget the name of. For SDL,
there's debiansdl1.2-oss or something. For OpenAL, you have to edit
/etc/openal.conf. For libao, there's /etc/libao.conf. For pure ALSA,
there's not much you can do. OSS4 doesn't really have fully featured
ALSA emulation. I've yet to get flash audio working yet. Supposedly you
have to build some flashplugin.c file somewhere for it.
Realistically, you should probably stick with ALSA on Linux unless you
have really laggy sound with it in emulators.
Quote: |
I think the project is slowly reaching the point where a configure script is needed. |
I really don't like the syntax of those. But yes, I really do need a
more powerful build system. Make just isn't up to the task anymore.
Quote: |
byuu didn't fix the Makefile for x86-64, here's a patch to make it work: |
Oops. Sorry about that.
Quote: |
I tried setting system.video to both xv and opengl and I don't notice any big difference between the two. |
Well, at least it's working. The bigger differences would be that the
color reproduction is much cleaner. Look at a screenshot with Xv
compared to OpenGL ... say, Zelda 3's heart containers, they blur with
the background on the edges due to loss of chroma. And you can also now
use the Video Filter -> [ Point, Linear ] modes, too. Some people
love pixely video.
And of course, I can work on triple buffering and pixel shader support now :)
Quote: |
That scene is one of the most intensive scenes the SNES has to offer |
Strangely enough, yes. Black Omen and the CT clock always give me the
most trouble for speed. PGO helps a lot, but it's such a pain to make
those builds.
The reason RTO (range-tile offset) is so slow is because with the tiles
changing every time, I lose a big optimization in the PPU (assuming the
next tile is just the current tile + 1.)
And yes, in theory, RTO (the CT clock / Black Omen effect) on mode 6
would be a lot more intensive, but we've yet to find a game that
actually uses that mode with RTO. Someone should make a demo :P
Quote: |
Yeah, but it's still not fullspeed with OpenGL on my machine. |
Unfortunately not. My emulator is too slow for an Athlon 3000+ :(
I get the framerates I do (~90-140fps) from a Core 2 E6600 at stock speed.
Quote: |
Oh, and byuu, full screen still doesn't work for me. |
Odd. Does it still do exactly the same thing? In that case, X11 is
reporting the window size as your full desktop screen size, despite the
window being smaller. The last thing I can think of is trying the below
patch:
Code: |
src/lib/miu.gtk/miu.gtk.window.cpp:
void pWindow::fullscreen() {
if(is_fullscreen == true) return;
is_fullscreen = true;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), false);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_NONE);
gtk_window_move(GTK_WINDOW(window), 0, 0);
gtk_widget_set_size_request(formcontainer, gdk_screen_width(), gdk_screen_height());
//super hack: GTK+ doesn't update window sizes for up to ~100ms,
//even if you pump gtk_main_iteration_do() ...
//so wait for a window change. yes, if old and new window size is
//the same, application will wait for ~500ms before loop exits
//not much I can do about this ...
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
}
void pWindow::unfullscreen() {
if(is_fullscreen == false) return;
is_fullscreen = false;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), true);
//this is hacky, miu/GTK+ does not cache window size yet ...
//if this works, I'll update the below code to restore window size and positioning
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER_ALWAYS);
gtk_widget_set_size_request(formcontainer, 640, 480);
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
} |
If you want to give that a try ... it simulates
gtk_window_(un/)fullscreen(). Note that exiting fullscreen will not set
the correct window size, but if it works for entering fullscreen mode,
then I can work with that.
EDIT: fixed gtk_window_set_decorated(). Thanks, krom!
Last edited by byuu on Mon Jan 21, 2008 8:05 pm; edited 1 time in total
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Jan 21, 2008 6:16 pm Post subject: |
|
Verdauga Greeneyes wrote: |
That scene is one of the most intensive scenes the SNES has to offer |
Never had a look at kirby superstar/dream land 3 have you... or you forgot to put 'without extra coprocessors'. :p
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 21, 2008 6:33 pm Post subject: |
|
grinvader wrote: |
Verdauga Greeneyes wrote: |
That scene is one of the most intensive scenes the SNES has to offer |
Never had a look at kirby superstar/dream land 3 have you... or you
forgot to put 'without extra coprocessors'. :p
|
I'll take your word for it I did mean SNES as in 'the console', but you're right, I should've clarified that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 21, 2008 6:40 pm Post subject: |
|
Quote: |
Never had a look at kirby superstar/dream land 3 have you... or you forgot to put 'without extra coprocessors'. :p |
He didn't forget to put that qualifier. The SA-1 has as much to do with the SNES itself as your refrigerator does.
But yes, yes. It's my honor to try to emulate every last coprocessor
any published SNES game ever used. Thank god nobody published an SNES
cart with an actual fridge interface + connector.
|
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Jan 21, 2008 7:22 pm Post subject: Linux WIP testing. |
|
I am using Ubuntu 7.10 with a Pentium 4 HT at 2.8 ghz and a 6600 nvidia gfx card.
First thing I noticed was the escape key was not toggling the menubar,
so I changed "esc" to "escape" for this to work.
src/ui/config.cpp line 150
Code: |
string_setting Input::GUI::toggle_menubar (config(), "input.gui.toggle_menubar", "", "esc"); |
to:
Code: |
string_setting Input::GUI::toggle_menubar (config(), "input.gui.toggle_menubar", "", "escape"); |
All of the new joypad and keyboard input works perfectly for me.
I use the "oss" option for the best sound, even though I have not
installed oss it works better than the "openao" option which clicks and
pops alot for me.
I found that the sidmania
pd demo which uses the highest snes volume output level, distorts alot
in linux compared to the windows direct sound driver, so maybe you can
check this demo on your linux setup compared to windows and tell me if
you can hear the volume distortion too.
I am using the "opengl" option for gfx, linear + pixel mode works correctly now.
Full screen does not work for me like [vEX], I tried your fullscreen patch above and needed to change:
Code: |
gtk_window_set_decoration |
to:
Code: |
gtk_window_set_decorated |
in the fullscreen and unfullscreen sections for it to compile.
I tested it out and fullscreen works much better than ever before, but
the main taskbars at the top and bottom of my window manager are still
visable. When I unfullscreen it goes back to the mode it was in before.
I would agree with you on killing the GTK+ renderer too now that opengl works so well =D
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 21, 2008 8:04 pm Post subject: |
|
krom,
thanks so much for your testing. It's greatly appreciated. Now all we
need is an ATI user to test the OpenGL code. If it works there, I'll
kill the GTK+ driver. Maybe one day I'll write a raw X11/XShm driver as
an ultimate fallback.
Quote: |
First thing I noticed was the escape key was not toggling the menubar, so I changed "esc" to "escape" for this to work. |
Oops, thank you. I'll fix that tonight. Side note, you can bind this
key inside the input configuration screen now. You can also bind the
statusbar to the same key, as well. Which allows you to toggle both at
the same time. Some people probably prefer it that way.
Quote: |
I
use the "oss" option for the best sound, even though I have not
installed oss it works better than the "openao" option which clicks and
pops alot for me. |
It's "openal", lowercase for OpenAL. If you tried with "openao", you
would get the libao driver, which is the default. And yes, that driver
has terrible performance.
Unfortunately, you're still using ALSA, so even the OpenAL driver will
most likely be less than spectacular. Not much can be done there.
Realistically, I need an ALSA driver for Linux users :(
Oh man, that's an API I don't want to touch with a ten foot pole. Out
of curiosity, are you also using Intel HD audio? If so, perhaps ALSA
will improve the hardware driver one day to fix these issues.
Quote: |
I
tested it out and fullscreen works much better than ever before, but
the main taskbars at the top and bottom of my window manager are still
visable. When I unfullscreen it goes back to the mode it was in before. |
Ah, thank you for testing that. To get the window on top of your
taskbar, you can use: gtk_window_set_keep_above(GTK_WINDOW(window),
true) in fullscreen(), and the same but with false in unfullscreen(). I
was hoping to avoid that, as it may be undesirable to some, and in the
worst case, it might obscure the ability to use the other UI windows.
I'd have to make them all topmost as well. Nonetheless, if that works
for you and everyone else, then that's what I'll do.
What is your window manager, by the way? Maybe I'll install it on my box so I can test this better.
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Mon Jan 21, 2008 8:38 pm Post subject: |
|
Quote: |
How do I grab the WIP, again? I'd love to help test this one. |
byuu wrote: |
Cool, thank you. I'll send you the link via PM.
|
I'd like to test this build as well (looks like you've found your Linux user with an ATI card )
_________________
Have a nice kick in da nutz @~@*
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Jan 21, 2008 9:07 pm Post subject: opengl Fullscreen tests: |
|
byuu wrote: |
Out of curiosity, are you also using Intel HD audio? |
I am not sure, I have a 3 - 4 year old intel motherboard with on board sound card, if that is any help.
byuu wrote: |
What is your window manager, by the way? |
I am using the standard ubuntu 7.10 setup which comes with the Gnome window manager although other sources say it might be the Compiz window manager, maybe another ubuntu 7.10 user can shed some light on this.
Here is the exact code I am using at the mo with gtk_window_set_keep_above added:
Code: |
void pWindow::fullscreen() {
if(is_fullscreen == true) return;
is_fullscreen = true;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), false);
gtk_window_set_keep_above(GTK_WINDOW(window), true);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_NONE);
gtk_window_move(GTK_WINDOW(window), 0, 0);
gtk_widget_set_size_request(formcontainer, gdk_screen_width(), gdk_screen_height());
//super hack: GTK+ doesn't update window sizes for up to ~100ms,
//even if you pump gtk_main_iteration_do() ...
//so wait for a window change. yes, if old and new window size is
//the same, application will wait for ~500ms before loop exits
//not much I can do about this ...
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
}
void pWindow::unfullscreen() {
if(is_fullscreen == false) return;
is_fullscreen = false;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), true);
gtk_window_set_keep_above(GTK_WINDOW(window), false);
//this is hacky, miu/GTK+ does not cache window size yet ...
//if this works, I'll update the below code to restore window size and positioning
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER_ALWAYS);
gtk_widget_set_size_request(formcontainer, 640, 480);
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
} |
This makes bsnes run in proper fullscreen =D
The only problem is when I turn the menubar off with escape whilst in
fullscreen and then unfullscreen with f11, bsnes loses its top bar with
the minimise/maximise close buttons, and bsnes needs a restart to go
back into perfect full screen mode again.
Last edited by krom on Mon Jan 21, 2008 9:29 pm; edited 4 times in total
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Jan 21, 2008 9:16 pm Post subject: |
|
byuu wrote: |
Quote: |
Oh, and byuu, full screen still doesn't work for me. |
Odd. Does it still do exactly the same thing? In that case, X11 is
reporting the window size as your full desktop screen size, despite the
window being smaller. The last thing I can think of is trying the below
patch:
Code: |
src/lib/miu.gtk/miu.gtk.window.cpp:
void pWindow::fullscreen() {
if(is_fullscreen == true) return;
is_fullscreen = true;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), false);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_NONE);
gtk_window_move(GTK_WINDOW(window), 0, 0);
gtk_widget_set_size_request(formcontainer, gdk_screen_width(), gdk_screen_height());
//super hack: GTK+ doesn't update window sizes for up to ~100ms,
//even if you pump gtk_main_iteration_do() ...
//so wait for a window change. yes, if old and new window size is
//the same, application will wait for ~500ms before loop exits
//not much I can do about this ...
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
}
void pWindow::unfullscreen() {
if(is_fullscreen == false) return;
is_fullscreen = false;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_set_decorated(GTK_WINDOW(window), true);
//this is hacky, miu/GTK+ does not cache window size yet ...
//if this works, I'll update the below code to restore window size and positioning
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER_ALWAYS);
gtk_widget_set_size_request(formcontainer, 640, 480);
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
} |
If you want to give that a try ... it simulates
gtk_window_(un/)fullscreen(). Note that exiting fullscreen will not set
the correct window size, but if it works for entering fullscreen mode,
then I can work with that.
EDIT: fixed gtk_window_set_decorated(). Thanks, krom!
|
At least it was working better than in v0.027, it was still placed in
the top left corner, but all the graphics was drawn in the window
instead of the center of the screen with only some off it being
viewable.
With the patch it works somewhat, I still see the bsnes titlebar and
the left side got a one pixel border from Openbox. With krom's fix to
make the window on top, I don't see the panel anymore though. :-)
I'll try and take a screenshot and show you how it looks.
EDIT: Screenshot:

EDIT2: Reading up on GTK stuff tells me that gtk_window_set_decorated()
might not work if the window managed has already painted the window and
should be called before gtk_window_show(). From what I can tell Openbox
supports EWMH (Extended Window Manager Hints); "Full support for EWMH
1.4-draft2". Yet I can't seem to find anything to fix this issue. But
it appears that it might be the interaction between GTK and Openbox
that is to be blamed, or just Openbox.
EDIT3: How come you haven't added the icon to the window? Need to write
another class for handling it (for MIU)? Adding the following to the
end of pWindow::create() in 'src/lib/miu.gtk/miu.gtk.window.cpp':
Code: |
GtkWidget *bsnes_icon;
bsnes_icon = gtk_image_new_from_file("data/bsnes.png");
gtk_window_set_icon(GTK_WINDOW(window), gtk_image_get_pixbuf(GTK_IMAGE(bsnes_icon))); |
adds the icon, though just adding
"gtk_window_set_icon(GTK_WINDOW(window),
gtk_image_get_pixbuf(GTK_IMAGE(gtk_image_new_from_file("data/bsnes.png"))));"
would be good enough, but probably doesn't look as good.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Mon Jan 21, 2008 11:16 pm Post subject: |
|
I
tested the linux version of bsnes with my Radeon Mobility x1400, and I
don't get any video inside the bsnes window. I'm running Ubuntu, and
I've set up all the ATI driver stuff, AFAIK (Compiz, at least, works). |
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Mon Jan 21, 2008 11:38 pm Post subject: |
|
byuu wrote: |
If it works there, I'll kill the GTK+ driver. Maybe one day I'll write a raw X11/XShm driver as an ultimate fallback. |
Does GtkSocket not do what you're looking for?
http://www.gtk.org/api/2.6/gtk/GtkSocket.html"
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Tue Jan 22, 2008 12:42 am Post subject: Nearly Perfect opengl Full Screen |
|
This is the best I can get the opengl full screen mode to work in Ubuntu 7.10.
src/lib/miu.gtk/miu.gtk.window.cpp:
Code: |
void pWindow::fullscreen() {
if(is_fullscreen == true) return;
is_fullscreen = true;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_fullscreen(GTK_WINDOW(window));
gtk_window_set_keep_above(GTK_WINDOW(window), true);
gtk_window_set_decorated(GTK_WINDOW(window), false);
gtk_widget_set_size_request(formcontainer, gdk_screen_width(), gdk_screen_height());
//super hack: GTK+ doesn't update window sizes for up to ~100ms,
//even if you pump gtk_main_iteration_do() ...
//so wait for a window change. yes, if old and new window size is
//the same, application will wait for ~500ms before loop exits
//not much I can do about this ...
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
}
void pWindow::unfullscreen() {
if(is_fullscreen == false) return;
is_fullscreen = false;
int initial_width = get_width();
int initial_height = get_height();
gtk_window_unfullscreen(GTK_WINDOW(window));
gtk_window_set_keep_above(GTK_WINDOW(window), false);
gtk_window_set_decorated(GTK_WINDOW(window), true);
//this is hacky, miu/GTK+ does not cache window size yet ...
//if this works, I'll update the below code to restore window size and positioning
gtk_widget_set_size_request(formcontainer, 640, 480);
time_t start = clock();
while(true) {
if(miu().pending()) miu().run();
if(int(clock() - start) > CLOCKS_PER_SEC / 2) break;
if(initial_width != get_width() && initial_height != get_height()) break;
}
} |
It has more stability now, and lets me go in and out of fullscreen quickly.
It still sometimes loses the minimise/exit buttons coming out of
fullscreen mode, but it is stable enough to get them back when you
press f11 twice.
[vEX] try this out and see if it works for you too...
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Tue Jan 22, 2008 3:27 am Post subject: Re: Nearly Perfect opengl Full Screen |
|
I'm having a hard time compiling this build in Ubuntu 7.10.
I installed the necessary packages
(g++,libxv-dev,libao-dev,libgtk2.0-dev,nasm and yasm) but when I start
the make process (x-gcc-x86 build),I get an error message: '/bin/sh:
sdl-config not found'.
What other package(s) do I need to install to correct these warnings/errors?
[SDL is installed by default in Ubuntu]
_________________
Have a nice kick in da nutz @~@*
Last edited by kick on Tue Jan 22, 2008 3:35 am; edited 4 times in total |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 22, 2008 3:28 am Post subject: Re: opengl Fullscreen tests: |
|
krom wrote: |
I am using the standard ubuntu 7.10 setup which comes with the Gnome window manager although other sources say it might be the Compiz window manager, maybe another ubuntu 7.10 user can shed some light on this. |
From the compiz website:
Quote: |
Compiz
is a compositing window manager that uses 3D graphics acceleration via
OpenGL. It provides various new graphical effects and features on any
desktop environment, including Gnome and KDE. |
So GNOME uses compiz for special graphical effects, I'm gathering.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 22, 2008 3:58 am Post subject: |
|
Sorry for the double post, but here goes:
My first problem when running this WIP is that my statusbar is black.
All black. No one else has complained, so this must just be happening
over here... any ideas why? Also, fullscreen won't work for me...
gameplay freezes for a moment when I toggle it and then continues
windowed, as normal.
Secondly, when attempting to map my gamepad, every single key logged
correctly... except my right directional. What? Weird. Every other
button on my controller registers. It's a ps2 controller hooked up
through a usb adapter, and even the dual shock doesn't seem to work
right: the left analog stick works exactly the same as the d-pad (which
means the right movement won't map), and the right one maps like this:
pressing left = joypad00.up
pressing right = joypadd00.down
pressing up = joypad00.left
pressing down = nothing. of course. bah!
I tested it in all my other emulators, and it's still running the same in those.
Finally, turning on Scale2x with or without opengl as video does this
to the Donkey Kong Country intro (note the statusbar)... 
Oh, and using opengl allowed me to use the aforementioned filter
without any clicking or popping, so far. Even without changing the
sound driver! All the other filters still give me those sound issues.
Hope that was all helpful! |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Jan 22, 2008 6:36 am Post subject: |
|
close and open bsnes to fix that squished image. it is a known bug i reported a while ago now.
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 22, 2008 6:53 am Post subject: |
|
where is the list of known bugs?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 22, 2008 7:28 am Post subject: |
|
franpa wrote: |
close and open bsnes to fix that squished image. it is a known bug i reported a while ago now. |
How many times did you have to open and close? Because it happens every
time I load the rom... and it actively squishes/unsqushes as I toggle
the scale2x filter on and off.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 22, 2008 7:37 am Post subject: |
|
New
WIP. No Windows binary. This one fixes the GTK+ fullscreen issue on
Openbox completely. How do I know? Because I'm running Openbox now to
verify :P
It's pretty spiffy, whole thing is only consuming ~5mb of memory. Total mem usage sans the 'fox is ~40mb.
The cool part with these changes is that video no longer flickers for
one frame when you toggle the menubar in fullscreen mode anymore. Not
even on XFCE.
Just in case, verification always helps. Hopefully it'll work on all
the esoteric window managers out there, so long as they honor the
undecorate window request. You may have some small issues if not.
I didn't need keepabove to get on top of my XFCE panel, even when I run
the panel in Openbox. I'd like to keep it off if possible.
Code: |
void pWindow::fullscreen() {
if(state.is_fullscreen == true) return;
state.is_fullscreen = true;
gtk_window_fullscreen(GTK_WINDOW(window));
gtk_window_set_decorated(GTK_WINDOW(window), false);
gtk_widget_set_size_request(window, gdk_screen_width(), gdk_screen_height());
}
void pWindow::unfullscreen() {
if(state.is_fullscreen == false) return;
state.is_fullscreen = false;
gtk_widget_set_size_request(formcontainer, state.width, state.height);
gtk_widget_set_size_request(window, -1, -1);
gtk_window_set_decorated(GTK_WINDOW(window), true);
gtk_window_unfullscreen(GTK_WINDOW(window));
} |
I also fixed the "esc" -> "escape" keysym for menu toggle, and
updated the x86-64 target with OpenGL + SDL input stuff. Thanks
everyone for the awesome feedback!
Quote: |
EDIT3:
How come you haven't added the icon to the window? Need to write
another class for handling it (for MIU)? Adding the following to the
end of pWindow::create() in 'src/lib/miu.gtk/miu.gtk.window.cpp': |
Yes, I need a way to do the same in Windows. Ideally, I need a way to
embed the icon inside the EXE, and have an API that allows me to set
the icon both on Windows and Linux from it. I'd prefer to not require
another external file for bsnes binary releases.
Thanks for the GTK+ code, though. It's a step in the right direction.
Quote: |
I
tested the linux version of bsnes with my Radeon Mobility x1400, and I
don't get any video inside the bsnes window. I'm running Ubuntu, and
I've set up all the ATI driver stuff, AFAIK (Compiz, at least, works). |
Aw ... well, thanks for trying. I kind of figured it wouldn't work.
Perhaps ATI doesn't support GLX ... I honestly have no idea. I'll look
into it.
Quote: |
What other package(s) do I need to install to correct these warnings/errors? |
libsdl1.2-dev
Quote: |
My
first problem when running this WIP is that my statusbar is black. All
black. No one else has complained, so this must just be happening over
here... any ideas why? Also, fullscreen won't work for me... gameplay
freezes for a moment when I toggle it and then continues windowed, as
normal. |
Sigh. I fixed this a while back. Certain GTK+ themes weren't painting
the background of statusbars, so I embedded the statusbar inside an
event box. I don't know why it still isn't working for you. It seems to
work for everyone else now ...
Quote: |
Secondly, when attempting to map my gamepad, every single key logged correctly... except my right directional. What? Weird. |
Good question. The SDL docs say axis 0 = x, axis 1 = y. but the two
thumbs are axes 2, 3 left and 4,5 right. The left thumb uses 2 for X
and 3 for Y, but the right uses 4 for Y and 5 for X. Since the API has
no way to tell you what direction an axis is in, I decided to play it
safe and do axis&1 over all axes. I guess I'll just hardcode for
D-pad + two thumbs in the next version by swapping 4 and 5 ... no idea
how other apps do it.
Quote: |
Finally, turning on Scale2x with or without opengl as video does this to the Donkey Kong Country intro (note the statusbar)... |
Longstanding issue. Never modified the hq2x and scale2x filters to
support hires modes. Only direct and NTSC do. Hoping to bypass the
issue with pixel shaders in the future. That, or wait until I cleanup
the video filter code and get it out of the core.
Nah, that's for other processes. I just need to convert an X11 handle
back to a gtk_drawing_area GtkWidget. Sounds weird, but miu only has
one handle() function for cross-platform reasons. So I make that export
an X11 handle (that Xv and OGL take) rather than a GtkWidget handle
(which requires gdkx.h header to extract the X11 handle from in a safe
manner.)
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 22, 2008 7:45 am Post subject: |
|
byuu wrote: |
Sigh.
I fixed this a while back. Certain GTK+ themes weren't painting the
background of statusbars, so I embedded the statusbar inside an event
box. I don't know why it still isn't working for you. It seems to work
for everyone else now ...
...
Longstanding issue. Never modified the hq2x and scale2x filters to
support hires modes. Only direct and NTSC do. Hoping to bypass the
issue with pixel shaders in the future. That, or wait until I cleanup
the video filter code and get it out of the core. |
Haha, well, I guess I'm behind in terms of bugs as well as experience.
The first problem is probably on my end, I'll try fiddling with stuff
to see if I can fix it myself. And thank you for confirming the
confirmation that the second is a longstanding bug, I actually think I
remember franpa mentioning it a long time ago, but now I guess I don't
need to go searching.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Tue Jan 22, 2008 9:56 am Post subject: |
|
byuu wrote: |
New
WIP. No Windows binary. This one fixes the GTK+ fullscreen issue on
Openbox completely. How do I know? Because I'm running Openbox now to
verify :P
It's pretty spiffy, whole thing is only consuming ~5mb of memory. Total mem usage sans the 'fox is ~40mb.
The cool part with these changes is that video no longer flickers for
one frame when you toggle the menubar in fullscreen mode anymore. Not
even on XFCE.
Just in case, verification always helps. Hopefully it'll work on all
the esoteric window managers out there, so long as they honor the
undecorate window request. You may have some small issues if not.
I didn't need keepabove to get on top of my XFCE panel, even when I run
the panel in Openbox. I'd like to keep it off if possible. |
It's working wonderfully here now! :-D
EDIT: Actually, when in fullscreen, if you bring up the configuration
dialog you will see the xfce-panel again, but it will disappear as soon
as you close the dialog. Nothing really to care about I think, I just
noticed it.
byuu wrote: |
Quote: |
EDIT3:
How come you haven't added the icon to the window? Need to write
another class for handling it (for MIU)? Adding the following to the
end of pWindow::create() in 'src/lib/miu.gtk/miu.gtk.window.cpp': |
Yes, I need a way to do the same in Windows. Ideally, I need a way to
embed the icon inside the EXE, and have an API that allows me to set
the icon both on Windows and Linux from it. I'd prefer to not require
another external file for bsnes binary releases.
Thanks for the GTK+ code, though. It's a step in the right direction.
|
I pretty much guessed it was something like that. I think I'll patch
the sources to add those three lines for the next Arch Linux package if
it's not fixed for v0.028 then, if you don't mind.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Tue Jan 22, 2008 3:25 pm Post subject: Full Screen |
|
Just to confirm, the new WIP full screen code works perfectly for my ubuntu 7.10 too =D |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 22, 2008 3:55 pm Post subject: |
|
byuu wrote: |
If it works there, I'll kill the GTK+ driver. Maybe one day I'll write a raw X11/XShm driver as an ultimate fallback. |
Just curious, since I have no idea what that is, but is it possible to
do video rendering using the CPU for almost everything instead of being
dependent on nvidia/ati/intel graphics drivers? Wouldn't that be the
ultimate in portability (and circumvent the issue with the PS3)?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 22, 2008 6:42 pm Post subject: |
|
Quote: |
I
pretty much guessed it was something like that. I think I'll patch the
sources to add those three lines for the next Arch Linux package if
it's not fixed for v0.028 then, if you don't mind. |
Not at all.
Quote: |
It's working wonderfully here now! :-D |
Quote: |
Just to confirm, the new WIP full screen code works perfectly for my ubuntu 7.10 too =D |
Hah! I win!
byuu: 1, Linux: 37.
Quote: |
Just
curious, since I have no idea what that is, but is it possible to do
video rendering using the CPU for almost everything instead of being
dependent on nvidia/ati/intel graphics drivers? |
You'd need GTK+ or XShm to draw the video to the screen, but yes, this
is possible. The problem is that upscaling the video in software is
fairly slow, and transferring it to the video card is murderously slow.
Transferring a 256x224 image and having the video card scale it to
1600x1200 is infinitely faster than scaling the image to that size in
software and then transferring it to the video card.
I'm not talking a ~3-5fps drop like using Xv instead of OpenGL. I'm
talking a major drop from ~100fps to ~10-20fps if I use software
upscaling like that.
With 1x scale, there's no difference in speed (obviously). 2x scale
requires 4x the bandwidth, 3x scale requires 9x, 4x scale is 16x and 5x
scale is a staggering 25x the video bandwidth.
That said, GTK+/XShm is a good fallback for 1-2x scale, if you have no other choice, hence why I want to add it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 22, 2008 8:07 pm Post subject: |
|
byuu wrote: |
I'm not talking a ~3-5fps drop like using Xv instead of OpenGL. I'm
talking a major drop from ~100fps to ~10-20fps if I use software
upscaling like that.
With 1x scale, there's no difference in speed (obviously). 2x scale
requires 4x the bandwidth, 3x scale requires 9x, 4x scale is 16x and 5x
scale is a staggering 25x the video bandwidth.
That said, GTK+/XShm is a good fallback for 1-2x scale, if you have no
other choice, hence why I want to add it. |
Eww... didn't realize it would take that much power. Is it not possible
to hand off this process to an additional core or cores?
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Jan 22, 2008 8:15 pm Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
I'm not talking a ~3-5fps drop like using Xv instead of OpenGL. I'm
talking a major drop from ~100fps to ~10-20fps if I use software
upscaling like that.
With 1x scale, there's no difference in speed (obviously). 2x scale
requires 4x the bandwidth, 3x scale requires 9x, 4x scale is 16x and 5x
scale is a staggering 25x the video bandwidth.
That said, GTK+/XShm is a good fallback for 1-2x scale, if you have no
other choice, hence why I want to add it. |
Eww... didn't realize it would take that much power.
|
Yeah. Try uninstalling your video drivers in XP and have the OS fall
back on it's generic driver or whatever and try an emulator...you'll
see what the slowness is all about.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 22, 2008 9:24 pm Post subject: |
|
http://psubuntu.com/forum/viewtopic.php?t=1805
Some further research suggests the CPU acceleration thing is being
worked on. No idea what implications this has for emulator upscaling,
but they are apparently trying to use the SPEs to do XV and EXA
acceleration. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Jan 22, 2008 11:12 pm Post subject: |
|
Snark wrote: |
Yeah.
Try uninstalling your video drivers in XP and have the OS fall back on
it's generic driver or whatever and try an emulator...you'll see what
the slowness is all about. |
Even booting in Safe Mode and dragging large window shows the problem (at least on this PC).
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 23, 2008 12:53 am Post subject: |
|
[quote="byuu"]
Quote: |
Quote: |
Just
curious, since I have no idea what that is, but is it possible to do
video rendering using the CPU for almost everything instead of being
dependent on nvidia/ati/intel graphics drivers? |
You'd need GTK+ or XShm to draw the video to the screen, but yes, this
is possible. The problem is that upscaling the video in software is
fairly slow, and transferring it to the video card is murderously slow.
Transferring a 256x224 image and having the video card scale it to
1600x1200 is infinitely faster than scaling the image to that size in
software and then transferring it to the video card.
I'm not talking a ~3-5fps drop like using Xv instead of OpenGL. I'm
talking a major drop from ~100fps to ~10-20fps if I use software
upscaling like that.
With 1x scale, there's no difference in speed (obviously). 2x scale
requires 4x the bandwidth, 3x scale requires 9x, 4x scale is 16x and 5x
scale is a staggering 25x the video bandwidth.
That said, GTK+/XShm is a good fallback for 1-2x scale, if you have no
other choice, hence why I want to add it.
|
thatś what I thought (they don't call em graphics cards for nothing) ,
I find it interesting that it doesn't slowdown if you're not scaling
though, so if you ran it at 1x there would be no slowdown? that would
be fun just for an experimental build, but clearly there are about 1000
other things more pressing.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 23, 2008 2:30 am Post subject: |
|
How can I revert bsnes to its default settings? installing the new wip after deleting the old one kept all my changes... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 23, 2008 2:39 am Post subject: |
|
Delete ~/.bsnes/bsnes.cfg
Quote: |
Some
further research suggests the CPU acceleration thing is being worked
on. No idea what implications this has for emulator upscaling, but they
are apparently trying to use the SPEs to do XV and EXA acceleration. |
As long as the Xv API works. Right now, your xvinfo indicates the
driver won't work at all. Heck, even if it's a 100% software fallback,
that's fine.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 23, 2008 3:31 am Post subject: |
|
byuu wrote: |
Delete ~/.bsnes/bsnes.cfg |
Durr. Thanks, that was a retarded question on my part.
EDIT: Is there any information I can send you in regards to my themes
and other settings that could help with the fact that I'm now the only
person in existence with a black statusbar? Also, I'd just like to
confirm on top of everyone else that fullscreen works now, though only
in 2x size (which I'm assuming is intentional, or is set in a setting
that I didn't see).
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Jan 23, 2008 7:30 am Post subject: |
|
just
out of curiosity did you stick the config file there just because it is
a professional standard or what? not that it's a bad thing, it's fine,
it just seems a trend with emulators to put it in the emulator folder
itself.
is there any specific reason?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jan 23, 2008 8:33 am Post subject: |
|
DancemasterGlenn wrote: |
Also,
I'd just like to confirm on top of everyone else that fullscreen works
now, though only in 2x size (which I'm assuming is intentional, or is
set in a setting that I didn't see). |
Fullscreen and Windowed mode settings are intentionally seperate. Just
go into the menu while you're in fullscreen mode to change it.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Jan 23, 2008 8:42 am Post subject: |
|
Panzer88 wrote: |
just
out of curiosity did you stick the config file there just because it is
a professional standard or what? not that it's a bad thing, it's fine,
it just seems a trend with emulators to put it in the emulator folder
itself.
is there any specific reason? |
thats a unix standard.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Wed Jan 23, 2008 3:51 pm Post subject: |
|
funkyass wrote: |
Panzer88 wrote: |
just
out of curiosity did you stick the config file there just because it is
a professional standard or what? not that it's a bad thing, it's fine,
it just seems a trend with emulators to put it in the emulator folder
itself.
is there any specific reason? |
thats a unix standard.
|
I'm not familiar with that unix standard.
The most common behavior I've seen on unix is check /etc for
<configfilename> and then the current user home directory for
.<configfilename>
The best behavior in my experience has been when systemwide defaults
are set in /etc, and then user-custom settings go in
~/.<configfilename>
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 23, 2008 4:40 pm Post subject: |
|
Verdauga Greeneyes wrote: |
DancemasterGlenn wrote: |
Also,
I'd just like to confirm on top of everyone else that fullscreen works
now, though only in 2x size (which I'm assuming is intentional, or is
set in a setting that I didn't see). |
Fullscreen and Windowed mode settings are intentionally seperate. Just
go into the menu while you're in fullscreen mode to change it.
|
And again, Durr. Not painfully obvious, but I should have been able to figure that one out. Thanks.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 23, 2008 5:58 pm Post subject: |
|
Okay, I looked into ATI GLX support. It appears to be there, but there are apparently lots of problems with what it reports.
I would like to get OpenGL working there though, if possible. For anyone using Linux+ATI, please provide:
- The driver you are using
- The output of glxinfo -v
- The output of xdpyinfo
- The command-line output from bsnes pertaining to VideoGLX, if any
Preferably not inlined in this thread, as they're quite long. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Wed Jan 23, 2008 8:54 pm Post subject: |
|
Seems
nobody else noticed this very old compilation bug. Some things changed
from time to time but this mistype have been on its place for a long
time.
Visual Studio 2005 Team Suite:
Code: |
miu.win.cpp:
void pMiu::init() {
...
wc.lpfnWndProc = pmiu_wndproc;
...
|
Visual Studio 2005: wrote: |
.\lib\miu.win\miu.win.cpp(42) : error C2440: '=' : cannot convert from
'long (__cdecl *)(HWND,UINT,WPARAM,LPARAM)' to 'WNDPROC'
|
so i fixing it this way:
Code: |
wc.lpfnWndProc = (WNDPROC)pmiu_wndproc;
|
_________________
quake2xp audio engineer
|
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Wed Jan 23, 2008 11:32 pm Post subject: |
|
_willow_ wrote: |
Seems nobody else noticed this very old compilation bug. Some things
changed from time to time but this mistype have been on its place for a
long time.
Visual Studio 2005 Team Suite:
Code: |
miu.win.cpp:
void pMiu::init() {
...
wc.lpfnWndProc = pmiu_wndproc;
...
|
Visual Studio 2005: wrote: |
.\lib\miu.win\miu.win.cpp(42) : error C2440: '=' : cannot convert from
'long (__cdecl *)(HWND,UINT,WPARAM,LPARAM)' to 'WNDPROC'
|
so i fixing it this way:
Code: |
wc.lpfnWndProc = (WNDPROC)pmiu_wndproc;
|
|
That __cdecl should be __stdcall, so typedef isn't the correct fix.
Changing the function declaration is. I'm surprised the resulting build
doesn't just crash.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Thu Jan 24, 2008 2:23 am Post subject: |
|

Silly me. Here it is, the correct VC2005 declaration:
Code: |
LRESULT CALLBACK pmiu_wndproc(HWND hwnd, UINT nmsg, WPARAM wparam, LPARAM lparam);
|
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 24, 2008 5:48 am Post subject: |
|
It doesn't crash, because it's already defined correctly.
miu.win.cpp:line 10:
Code: |
long __stdcall pmiu_wndproc(HWND, UINT, WPARAM, LPARAM); |
Further, my copy of VS2k5 does not even give a warning about this
assignment. However, I'll add the cast if your compiler is broken and
this fixes it for you.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Jan 24, 2008 6:20 am Post subject: |
|
DancemasterGlenn wrote: |
How can I revert bsnes to its default settings? installing the new wip after deleting the old one kept all my changes... |
Alternatively, you can go into advanced settings and default everything with an asterisk next to it.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Thu Jan 24, 2008 9:46 am Post subject: |
|
byuu wrote: |
miu.win.cpp:line 10:
Code: |
long __stdcall pmiu_wndproc(HWND, UINT, WPARAM, LPARAM); |
Further, my copy of VS2k5 does not even give a warning about this assignment.
|
nope, it's just bad declaration and i'm going to second kode54. And i'm
sorry i do not mention it before, as i'm using 64 bit compiler and 64
bit VC progect (which works fine BTW).
winuser.h :
Code: |
typedef LRESULT (CALLBACK* WNDPROC)(HWND, UINT, WPARAM, LPARAM); |
WTypes.h :
Code: |
typedef LONG_PTR LRESULT |
And guess what about CALLBACK?
Code: |
#define CALLBACK _stdcall |
nothing interesting really
but LONG_PTR is the most interesting species
it's declaration can be:
Code: |
typedef _w64 long LONG_PTR |
or
Code: |
typedef _int64 LONG_PTR |
depending on _WIN64 preprocessor definition presence.
Either case it have nothing similar to "long", so
long __stdcall pmiu_wndproc is the wrong declaration. Casting is not
really a solution as the return value for the callback function should
be 64bit but not 32bit.
kode54 wrote: |
I'm surprised the resulting build doesn't just crash. |
Seems the callback return the value in EAX register and the upper bits
of RAX just contains garbage or filled with zeros by a blind luck -
it's how it works now without proper declaration.
_________________
quake2xp audio engineer
|
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Jan 25, 2008 10:02 pm Post subject: |
|
FWIW,
the latest ATI fglrx driver is reported to work extremely well in
SDLMAME (including shader effects) after a few rocky versions, so make
sure anyone trying to test it is using the absolute latest from ATI's
site. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Jan 25, 2008 11:50 pm Post subject: |
|
As if it wasn't already known, blargg is an absolute genius.
I'm sure everyone is bored to tears from hearing about libco (myself
included), but blargg recently went and optimized it due to the save
state discussion.
I also went back and moved the ASM into inlined C files, that way an
assembler would no longer be needed to build bsnes, and so that the
fastest implementation could be chosen at compile time automatically.
At the same time, I removed the single global (co_active), so that the
library would function in a multi-threaded environment (meaning it's MP
safe now.)
My technique:
Code: |
__declspec(naked) __declspec(noinline)
static void __fastcall
co_swap(cothread_t prev, cothread_t next) {
__asm {
push ebp
push esi
push edi
push ebx
mov [ecx],esp
mov esp,[edx]
pop ebx
pop edi
pop esi
pop ebp
ret
}
}
clocks per second = 1000
2843 clocks / 50,000,000 subroutine calls (500000000 iterations)
32157 clocks / 100,000,000 co_switch calls (500000000 iterations)
co_switch skew = 11.310939x |
Not bad ... twice as fast as Windows SwitchToFiber(), three times faster than Linux longjmp, and three hundred
times faster than Linux swapcontext(). I used push instead of mov
reg,[imm], because it performs better on the Pentium IV. While it
performs worse on the Athlon 64, the PIV was hurt worse. Note that
using pushad here would be foolish ... it pushes all registers, rather
than just non-volatile ones, takes a lot longer to complete, and also
pushes and pops ESP, which means I'd have to use more black magic to
fix that.
Right away, blargg realized that the
pipeline stall from not knowing where the code would continue executing
(it is determined after the ret) was more significant than the push vs
mov difference.
blargg's version:
Code: |
__declspec(naked) __declspec(noinline)
static void __fastcall
co_swap(cothread_t prev, cothread_t next) {
__asm {
mov [ecx],esp
mov esp,[edx]
mov eax,[esp] //fetch return address as soon as possible,
add esp,4 //so that pipeline can begin caching sooner ...
mov [ecx+4],ebp
mov [ecx+8],esi
mov [ecx+12],edi
mov [ecx+16],ebx
mov ebp,[edx+4]
mov esi,[edx+8]
mov edi,[edx+12]
mov ebx,[edx+16]
jmp eax
}
}
clocks per second = 1000
2875 clocks / 50,000,000 subroutine calls (500000000 iterations)
17078 clocks / 100,000,000 co_switch calls (500000000 iterations)
co_switch skew = 5.940174x |
32157 / 17078 = ~188% speedup!
Further, by declaring the active thread (prev) as volatile to keep the
compiler from getting too overzealous, we can pull off the following
black magic to inline co_swap. Note that this only works on GCC:
Code: |
__attribute__((always_inline))
inline void co_swap( cothread_t prev, cothread_t next )
{
__asm__ volatile
(
"movl 4(%%edx),%%eax\n\t"
"movl %%esp,(%%ecx)\n\t"
"movl (%%edx),%%esp\n\t"
"movl %%ebp, 8(%%ecx)\n\t"
"leal 0f,%%ebp\n\t"
"movl %%esi,12(%%ecx)\n\t"
"movl %%edi,16(%%ecx)\n\t"
"movl %%ebx,20(%%ecx)\n\t"
"movl %%ebp, 4(%%ecx)\n\t"
"movl 8(%%edx),%%ebp\n\t"
"movl 12(%%edx),%%esi\n\t"
"movl 16(%%edx),%%edi\n\t"
"movl 20(%%edx),%%ebx\n\t"
"jmp *%%eax\n"
"0:\n\t"
: "=c" (prev), "=d" (next)
: "0" (prev), "1" (next)
: "%eax"
);
}
clocks per second = 1000
3031 clocks / 50,000,000 subroutine calls (500000000 iterations)
9484 clocks / 100,000,000 co_switch calls (500000000 iterations)
co_switch skew = 3.129000x |
32157 / 9484 = ~339% speedup!!!
Unfortunately, there's a lot of problems. First, the active thread has
to be marked volatile to keep GCC from getting overzealous and
"optimizing" out required code. Second, because of the inlining, it
only works well in a small timing example where co_swap is only called
once or twice. It's easy to fit the entire timing loop into L1 cache.
In a real world example, such as with bsnes, the inlining actually
hurts it a lot. The executable was increased by over 100kb, and it
netted a speed loss of ~5-10%. So, despite the timing test being
faster, it didn't work out so well.
And because of it being GCC-specific (inlining with MSVC is fruitless,
it generates red tape around the function that cannot be omitted), and
because it requires additional coding decisions, this was a net loss
and will not be used. Still very cool, though! I knew inlining was
possible from ASM, but I didn't think this was possible from C code at
all. blargg proved me wrong, and helped show that it isn't worth
pursuing anyway. It's not a good idea to inline this critical function
in a real-world app.
What does this mean for bsnes? A small speedup for now, ~1-2%. libco
isn't by any means a bottleneck to performance right now, taking a mere
~6-8% of execution time. The bottleneck is IRQs, consuming ~40-50% of
CPU time, and the PPU BG renderer, taking ~30-40% of CPU time. Even
more during RTO scenes.
However, this will be absolutely invaluable if and when bsnes finally
adds a cycle-accurate S-PPU renderer. That would require ~21 million
co_switch calls per emulated second, or (21m / 100m * 32157 =) ~6.75
seconds.
Now, that would only need (21m / 100m * 17078 =) ~3.59 seconds. It's
still too slow to be practical. Real time takes more than emulated
time, means 60fps is impossible.
But it's a lot better. If I can find a way to handle the PPU V/Hblank
pin issue, then I'd only need to sync on CPU accessing $2100-$213f,
just as CPU<>SMP only syncs on $2140-$217f, which works remarkably well.
Quote: |
nope,
it's just bad declaration and i'm going to second kode54. And i'm sorry
i do not mention it before, as i'm using 64 bit compiler and 64 bit VC
progect (which works fine BTW). |
bsnes is working after compiling it as a 64-bit binary?
libco.x86-64.asm is not compatible with Win64's ABI, may I ask how you
managed to get it working?
Quote: |
typedef _w64 long LONG_PTR |
Ah, that would do it. Didn't realize they changed that. Okay, I'll fix it, thank you.
Quote: |
FWIW,
the latest ATI fglrx driver is reported to work extremely well in
SDLMAME (including shader effects) after a few rocky versions, so make
sure anyone trying to test it is using the absolute latest from ATI's
site. |
Good to know, thanks. Maybe I'll pick up a cheap ATI card to fix up the
OpenGL driver. That's going to be a total waste of money for me
personally, but if it makes my software better ...
Last edited by byuu on Sat Jan 26, 2008 12:02 am; edited 1 time in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Jan 26, 2008 12:02 am Post subject: |
|
GCC
inline asm-unuglified and commented inline version. The processor likes
to be preparing things ahead of where it's doing actual execution, so
we want to load the new PC as early as possible so it can start
preparing immediately. It looks ahead and sees the JMP EAX and says
"Well, does anything modify EAX between where we're at and the JMP?"
Right after we load EAX, the answer to that question is "no", so it can
then begin decoding instructions from wherever EAX points (technically
it can do this before, using a cache of the places it jumped to on
previous executions, but when it's wrong it has to start over).
Apparently it does something similar for the stack pointer, so I also
have that loaded as soon as possible.
Note how
the LEAL avoids the need for a CALL as the non-inline version used.
You'd have CALL co_swap, which would push the address of the
instruction after call on the stack. Now we just calculate that address
without pushing anything on the stack.
Code: |
; Context structure:
; + 0 SP
; + 4 PC
; + 8 ebp
; +12 esi
; +16 edi
; +20 ebx
; Write current thread state to prev,
; load new state from next
movl 4(next),eax ; Get new PC as early as possible
movl esp,(prev) ; Save old SP
movl (next),esp ; Get new SP early too
movl ebp, 8(prev) ; Save ebp
leal resume,ebp ; ebp = PC to resume old thread at
movl esi,12(prev) ; Save other NV regs
movl edi,16(prev)
movl ebx,20(prev)
movl ebp, 4(prev) ; Save old PC
movl 8(next),ebp ; Restore new NV regs
movl 12(next),esi
movl 16(next),edi
movl 20(next),ebx
jmp eax ; Restore new PC
resume: |
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Sat Jan 26, 2008 2:26 am Post subject: |
|
byuu wrote: |
bsnes
is working after compiling it as a 64-bit binary? libco.x86-64.asm is
not compatible with Win64's ABI, may I ask how you managed to get it
working? |
*Crushed from chair*
Yes, it works without crushes under Vista. I have no WinXP to test it.
for v0.026 i used this:
Code: |
yasm-0.6.2-win64.exe -f win64 -o Release\libco_x86_64.obj lib\libco_x86_64.asm |
and then linked project with libco_x86_64.obj. Works like a charm.
for v0.027 i'm just include libco.win.cpp to project, that's all.
Download the project file for Visual Studio 2005 here, win32 and win64 profiles included.
I'm the lucky one?
_________________
quake2xp audio engineer
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 26, 2008 3:06 am Post subject: |
|
byuu wrote: |
However, this will be absolutely invaluable if and when bsnes finally
adds a cycle-accurate S-PPU renderer. That would require ~21 million
co_switch calls per emulated second, or (21m / 100m * 32157 =) ~6.75
seconds.
Now, that would only need (21m / 100m * 17078 =) ~3.59 seconds. It's
still too slow to be practical. Real time takes more than emulated
time, means 60fps is impossible.
But it's a lot better. If I can find a way to handle the PPU V/Hblank
pin issue, then I'd only need to sync on CPU accessing $2100-$213f,
just as CPU<>SMP only syncs on $2140-$217f, which works remarkably well. |
= sweetness, one step closer.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Jan 26, 2008 4:57 am Post subject: |
|
The
version in blargg's post looks like the volatile version in your post,
byuu. Is it? Or is it the version you'll actually use, and if so how
does it compare to the first version you posted above? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Jan 26, 2008 6:12 am Post subject: |
|
Holy shit! It's even faster on my Core 2 Duo!!
Code: |
my method:
clocks per second = 1000000
1280000 clocks / 50,000,000 subroutine calls (500000000 iterations)
14180000 clocks / 100,000,000 co_switch calls (500000000 iterations)
co_switch skew = 11.078125x
blargg's method:
clocks per second = 1000000
1260000 clocks / 50,000,000 subroutine calls (500000000 iterations)
4390000 clocks / 100,000,000 co_switch calls (500000000 iterations)
co_switch skew = 3.484127x |
That's a ~323% increase in speed! This means 21m co_switch calls would
consume ~922ms. Again, still completely impractical.
bsnes running the SNES Test Application at uncapped speed and max frameskip went from ~196.5fps to ~200.5fps here.
Quote: |
The
version in blargg's post looks like the volatile version in your post,
byuu. Is it? Or is it the version you'll actually use, and if so how
does it compare to the first version you posted above? |
It's the same function, he just made the code readable, as the creators
of AT&T assembler syntax had some sort of severe mental defect.
It's still partially bastardized in that the argument parameters are
backwards, and register sizes are being declared explicitly despite
their sizes being blatantly obvious from the register types -- but it's
a lot more readable, at least.
Quote: |
and then linked project with libco_x86_64.obj. Works like a charm. |
If that's the case, then Microsoft is lying when they say their ABI is different from System V's.
Quote: |
for v0.027 i'm just include libco.win.cpp to project, that's all. |
Cool! I've been asking people to verify if the fibers port worked there
for the better part of a year. My sincere thanks for verifying this for
me!
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Jan 26, 2008 7:17 am Post subject: |
|
byuu wrote: |
This means 21m co_switch calls would consume ~922ms. Again, still completely impractical. |
Even so, that's -quite- a lot faster
How fast do you think it needs to be to make the future PPU core
practical? (Taking into account, if possible, how much faster the rest
of bsnes would be on this hypothetical processor.. from earlier posts I
take it your Core 2 Duo takes somewhere between 0.4 and 0.6 seconds for
every emulated second right now, without any frameskipping)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Jan 26, 2008 9:09 am Post subject: |
|
yes, it might not be that unattainable in a few years when better PCs are coming around.
also, with all the work being done lately, do you think you will have
28 ready soon? I realize you still have to work a few things out but I
can't wait to get my hands on it, any tiny speed update will help my
computer 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 27, 2008 6:57 am Post subject: |
|
Verdauga Greeneyes wrote: |
byuu wrote: |
This means 21m co_switch calls would consume ~922ms. Again, still completely impractical. |
Even so, that's -quite- a lot faster
How fast do you think it needs to be to make the future PPU core
practical? (Taking into account, if possible, how much faster the rest
of bsnes would be on this hypothetical processor.. from earlier posts I
take it your Core 2 Duo takes somewhere between 0.4 and 0.6 seconds for
every emulated second right now, without any frameskipping)
|
I haven't been following progress in processors development.
It's been said many times that the industry was moving toward more
multi cores and that pure processing power won't increase for quite
some times.
Are there any indications that we're gonna witness a real speed
increase in the next few year with some new generation of CPU or
something?
Regardless like I said, I'm quite in favor of the development of the
cycle based renderer even if it mean no playable speed for some time.
And in the meantime, new ideas as how to make it faster (without
sacrifying accuracy) can always come up.
|
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Jan 27, 2008 7:01 am Post subject: |
|
That
is false. It's not the main focus anymore, but it will certainly still
continue(Hell, the new 45 nm Core 2 duos are faster at the same clock
speed than the original Core 2 Duos...). Look up Nehalem and you'll
learn a bit more about their future plans.
Fact is, even Intel knows some things just cannot be multi threaded and gain gain a shitload of performance. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 27, 2008 7:14 am Post subject: |
|
I plan on getting an e8400 soon. I usually upgrade every time mid-range performance doubles (I have an e6300 now).
As a user I'm not terribly excited about S-PPU as it won't do anything
for enjoyment. Playing SuperFX games on the other hand... now there's a
good incentive to get a faster processor. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Jan 27, 2008 7:16 am Post subject: |
|
I'm gonna get an E8200 and OC the shit out of it. >.> |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 27, 2008 7:22 am Post subject: |
|
I.S.T. wrote: |
That
is false. It's not the main focus anymore, but it will certainly still
continue(Hell, the new 45 nm Core 2 duos are faster at the same clock
speed than the original Core 2 Duos...). Look up Nehalem and you'll
learn a bit more about their future plans.
Fact is, even Intel knows some things just cannot be multi threaded and gain gain a shitload of performance. |
Good to know then.
And my mistake, I think actually what was said, and correct me if I'm wrong, is that pure clock speed
have stopped going up. And that afaik is correct. In the past decade
we've seen CPU clocked at 1ghz(?) going progressively up to 4ghz. And
then it pretty much stopped, and even regressed slightly in fact.
But obviously clock speed is just one component that determines the
"real" speed of the CPU anyway, and like you said the fastest processor
today ARE faster than older, higher clocked ones.
All the more reasons to consider a dot-based ppu in the future then :D
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 27, 2008 7:57 am Post subject: |
|
Well,
what happened was that for a long time AMD and Intel engaged in mhz
wars. The consumer perception for a long time was performance =
clockspeed, which isn't true. It's a part of it, but there's also cache
and pipeline length and all other sorts of stuff coming into play. That
ended after netburst and "preshott" and obscenely long pipeline length.
So with that major shift in strategy away from mhz and long pipelines,
you saw a temporary regression in clockspeed, but performance still
increased. Now both companies have pushed the clockspeed into the specs
and adopted model numbers because the average consumer would have been
like "the hell I'm going to 'upgrade' to half the clockspeed."
Clockspeed is still going to increase with the new strategy, though. My
e6300 is 1.86ghz dual core and was $200 when it came out. The penryn
e8400 is 3.0ghz dual core and is $200. So clockspeed, cache, and
performance per clock is still going up despite the push for more cores.
Last edited by FitzRoy on Sun Jan 27, 2008 8:02 am; edited 2 times in total |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Jan 27, 2008 7:58 am Post subject: |
|
Nehalem is going ot be roughly 10-25% faster at same clockspeed and single thread performance, supposedly. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Jan 27, 2008 8:04 am Post subject: |
|
FitzRoy wrote: |
Well,
what happened was that for a long time AMD and Intel engaged in mhz
wars. The consumer perception for a long time was performance = mhz,
which isn't true. It's a part of it, but there's also cache and
pipeline length and all other sorts of stuff coming into play. That
ended after netburst and "preshott" and obscenely long pipeline length. |
And the resurrection of model numbers and performance indexes and whatever else they call them.
They started actively obscuring the clock speed.
Quote: |
Now
both companies have pushed the mhz into the specs and adopted model
numbers because the average consumer would have been like "the hell I'm
going to 'upgrade' to half the clockspeed." |
The model numbers began before the clock war was over. Actually, they
initially came back BECAUSE of the clock war.
AMD brought them back because they couldn't get the Athlons going as
fast as the Pentium 4s, and needed a way to advertise that they were
equivalent to this faster-running P4(and they were actually semi-honest
about it, which is more than can be said for the older days).
And then Intel started using totally arbitrary numbers to stop the comparison of their MHz to AMD's model number.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Jan 27, 2008 8:16 am Post subject: |
|
AMD's numbers made sense at first, but then they went to hell over the past few years... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Jan 27, 2008 8:43 am Post subject: |
|
Yes,
netburst ended not out of Intel's own revelations, but because AMD went
to the shorter pipeline first and started using the ratings system to
combat the clockspeed mentality. Their CPUs were on par with Intel's
netburst architecture at much lower clockspeeds, and I think they were
gaining ground at that point. I think the Phenom uses a model number
system now. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Jan 27, 2008 8:55 am Post subject: |
|
I.S.T. wrote: |
AMD's numbers made sense at first, but then they went to hell over the past few years... |
You mean right after they resurrected it, not in the 5x86.
It was complete bullshit when it was introduced. Then it was retired because everyone hated it.
Then it came back, and it was reasonably honest. Now it's arbitrary,
though MOSTLY consistent across AMD's product line.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Jan 27, 2008 9:02 am Post subject: |
|
Guess I'm the only one here still stuck with an old, power hungry P4 huh?
On a positive note, I think it's been quite some time since anyone
asked whether or not Zsnes (also commonly known as Z.NES) will runs on
their *insert prehistoric P1-level PC here*. hasn't it? |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Jan 27, 2008 9:54 am Post subject: |
|
Snark wrote: |
Guess I'm the only one here still stuck with an old, power hungry P4 huh? |
Still running on my 2k1 Suckamette here, compadre. Should change in the coming months, methinks.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Jan 27, 2008 10:02 am Post subject: |
|
byuu wrote: |
I
also went back and moved the ASM into inlined C files, that way an
assembler would no longer be needed to build bsnes, and so that the
fastest implementation could be chosen at compile time automatically. |
v0.027.19:
Code: |
$ make PLATFORM=x-gcc-x86-64
g++ -O3 -fomit-frame-pointer -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86_64 -DUI_MIU `pkg-config --cflags gtk+-2.0` `sdl-config
--cflags` -Ilib -mtune=native -c ui/main.cpp -o main.o
gcc -O3 -fomit-frame-pointer -DPLATFORM_X -DCOMPILER_GCC
-DPROCESSOR_X86_64 -DUI_MIU `pkg-config --cflags gtk+-2.0` `sdl-config
--cflags` -Ilib -mtune=native -c lib/libco.c -o libco.o
/tmp/cccGPPca.s: Assembler messages:
/tmp/cccGPPca.s:25: Error: bad register name `%0)'
make: *** [libco.o] Error 1
$ gcc --version
gcc (GCC) 4.2.2 |
Also, shouldn't "make clean" remove all .o files? Whenever I do make clean they're left behind.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Jan 27, 2008 10:30 am Post subject: |
|
Wow, you are fast!! :D
Yeah, accidentally had %%0 instead of %0 at one spot. I've re-uploaded
libco v0.13 rc1 and bsnes v0.027.19 with the fix, thanks.
Could you please let me know if it works for you? I don't have an amd64 OS to test on ...
Quote: |
Also, shouldn't "make clean" remove all .o files? Whenever I do make clean they're left behind. |
You have to define a platform, as the delete command varies. Use
clean.sh in that folder, or type make PLATFORM=x-gcc-x86-64 clean.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Jan 27, 2008 11:04 am Post subject: |
|
byuu wrote: |
Wow, you are fast!! :D
Yeah, accidentally had %%0 instead of %0 at one spot. I've re-uploaded
libco v0.13 rc1 and bsnes v0.027.19 with the fix, thanks.
Could you please let me know if it works for you? I don't have an amd64 OS to test on ... |
It compiles, yes. Works, no. :-/
Just starting bsnes consumes ~80-90% CPU just sitting there and showing
the GUI. Trying to start a game gives me a segfault. Did another
compile with the -g flag:
Code: |
(gdb) run
Starting program: /tmp/src/bsnes
[Thread debugging using libthread_db enabled]
[New Thread 0x2b5c7647db20 (LWP 9957)]
[New Thread 0x40804950 (LWP 9960)]
[New Thread 0x41005950 (LWP 9961)]
* Loading "/home/fredrik/Spel/SNES/Chrono Trigger (U) [!].smc"...
* Loading "/home/fredrik/Spel/SNES/Chrono Trigger (U) [!].srm"...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b5c7647db20 (LWP 9957)]
0x000000000041c62a in co_switch (to=0x8197e0) at lib/libco/libco.x86-64.c:58
58 __asm__ __volatile__(
Current language: auto; currently c
(gdb) bt
#0 0x000000000041c62a in co_switch (to=0x8197e0)
at lib/libco/libco.x86-64.c:58
#1 0x00000000000000d7 in ?? ()
#2 0x0000000000418755 in main (argc=<value optimized out>,
argv=0x7fff3aceb1b8) at ui/miu/main.cpp:114 |
I won't claim to be the master of GDB, this is pretty much what I know,
so if you need more info tell me what and how to get it.
byuu wrote: |
Quote: |
Also, shouldn't "make clean" remove all .o files? Whenever I do make clean they're left behind. |
You have to define a platform, as the delete command varies. Use
clean.sh in that folder, or type make PLATFORM=x-gcc-x86-64 clean.
|
I see, then it's working like it should. :-)
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Jan 27, 2008 2:18 pm Post subject: |
|
FitzRoy wrote: |
That ended after netburst and "preshott" and obscenely long pipeline length. |
I recall reading that Intel gave P4s their long pipeline length with
the intention of utilising it at higher clock speeds (i.e. 6GHz+) but
they ran into current leakage problems - then by the time they started
getting those under control, the architecture was so obsolete that they
just dropped it in favour of the much more efficient Pentium M-based
Core (2) Duo. But I don't know if there's any truth to that, or if it's
a story Intel themselves spread to try and save face.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sun Jan 27, 2008 10:05 pm Post subject: |
|
the
P4's deep pipeline was to be paired with high-bandwidth, higher latency
memory, namely RAMBUS. Yes, the P4 was specifically made with RAMBUS in
mind.
the idea was you could get more instructions
and data into the pipeline with the RAMBUS's high bandwidth, the deeper
pipeline meant the P4 wouldn't be starved between reads from the
RAMBUS's high latency. nearly 20 years of data collection also meant
that Intel could guess with high reliability which instructions could
be put into the pipeline.
This would've worked well, except for two things:
RAMBUS never really lived up intel's expectations on bandwidth, and its
latency was detrimental enough to make the first models of P4 get their
asses handed to them by late-model P3's.
And they never anticipated the cost of getting a prediction wrong: you
have to flush the entire pipeline and start over. It meant with a 20
stage pipeline the P4 is pretty much twiddling its thumbs waiting for
the RAMBUS to finish its read. The prediction system in the early-model
P4's wasn't accurate enough to be used in such an environment.
Then AMD went on to 7 years of beating Intel in performance.
There were a few things that Intel could do to try to rectify the
situation, namely drop RAMBUS faster than a lead ball fired from an
orbital platform, replacing it with standard DDR and DDR2, which for
that former faster, and for the later faster and more bandwidth; and
improve the P4's prediction system, so much so that the late model p4
extremes had a 30-stage pipeline. Cranking up the hertz also helped, as
it was SOP for Intel for all of its existence at that point.
As Verdauga said, physics put the kabosh on high ghz P4's pretty fast,
and then Intel was forced to fall back onto plan b, and back to being
top dog again.
the only major company still to be using RAMBUS ram is Sony. Go figure.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Jan 28, 2008 12:21 am Post subject: |
|
I'll
be building a new Quad-core computer the moment Intel's Q9450 hits the
stores. I've already got the money and will be putting in 4 GB of DDR2
ram (DDR3 is a little too expensive for me right now). I'd be happy to
test things for Byuu when I get the machine built.
Unfortunately, it will be 64-bit and using Vista 64 Ultimate, so I'm
not sure what all will be compatible in terms of software and
emulators. It can't be helped though, since my primary use will be for
deep chess analysis and I need a 64-bit OS for the multi-core chess
program I'm using. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 28, 2008 1:03 am Post subject: |
|
I
intend the same thing, but I probably won't get Vista right away or
another 2GiB of RAM, so that might make for an interesting comparison. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Jan 28, 2008 1:13 am Post subject: |
|
funkyass wrote: |
the
P4's deep pipeline was to be paired with high-bandwidth, higher latency
memory, namely RAMBUS. Yes, the P4 was specifically made with RAMBUS in
mind.
the idea was you could get more
instructions and data into the pipeline with the RAMBUS's high
bandwidth, the deeper pipeline meant the P4 wouldn't be starved between
reads from the RAMBUS's high latency. nearly 20 years of data
collection also meant that Intel could guess with high reliability
which instructions could be put into the pipeline.
This would've worked well, except for two things:
RAMBUS never really lived up intel's expectations on bandwidth, and its
latency was detrimental enough to make the first models of P4 get their
asses handed to them by late-model P3's.
And they never anticipated the cost of getting a prediction wrong: you
have to flush the entire pipeline and start over. It meant with a 20
stage pipeline the P4 is pretty much twiddling its thumbs waiting for
the RAMBUS to finish its read. The prediction system in the early-model
P4's wasn't accurate enough to be used in such an environment.
Then AMD went on to 7 years of beating Intel in performance.
There were a few things that Intel could do to try to rectify the
situation, namely drop RAMBUS faster than a lead ball fired from an
orbital platform, replacing it with standard DDR and DDR2, which for
that former faster, and for the later faster and more bandwidth; and
improve the P4's prediction system, so much so that the late model p4
extremes had a 30-stage pipeline. Cranking up the hertz also helped, as
it was SOP for Intel for all of its existence at that point.
As Verdauga said, physics put the kabosh on high ghz P4's pretty fast,
and then Intel was forced to fall back onto plan b, and back to being
top dog again.
the only major company still to be using RAMBUS ram is Sony. Go figure. |
Don't
forget that RAMBUS was fucking everyone up the ass for RDRAM licenses,
which kept prices higher than comparable DDR setups.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 28, 2008 6:27 am Post subject: |
|
New WIP posted.
I downloaded a 64-bit Linux OS to verify that libco.x86-64.c worked
this time. Turns out the problem was that I declared "register stack =
*(long long*)to;" -- forgot the size qualifier, so it was being
truncated to 32-bits. Anyway, it works now.
I also added two more GUI keys, one to pop open the load ROM window,
and one to pause emulation. Yes, took me eight versions, but I finally
re-added pause mode. It probably still consumes CPU time, not sure. I
don't really care, I'll fix it before release. The whole thing is silly
anyway, task scheduler is so easy to cheat. Add sleep(1) inside the
main loop and it states bsnes uses ~1-2% CPU time. As if.
Windows binary updated, too.
Quote: |
Unfortunately,
it will be 64-bit and using Vista 64 Ultimate, so I'm not sure what all
will be compatible in terms of software and emulators. |
32-bit software runs fine for the most part on Vista. bsnes works there
for sure. But if you want it 64-bit native, you'll have to compile it
yourself, as I have no idea how to make a 64-bit Windows binary. Nor do
I really feel like maintaining another build :/
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Jan 28, 2008 7:15 am Post subject: |
|
funkyass wrote: |
the
P4's deep pipeline was to be paired with high-bandwidth, higher latency
memory, namely RAMBUS. Yes, the P4 was specifically made with RAMBUS in
mind.
the idea was you could get more
instructions and data into the pipeline with the RAMBUS's high
bandwidth, the deeper pipeline meant the P4 wouldn't be starved between
reads from the RAMBUS's high latency. nearly 20 years of data
collection also meant that Intel could guess with high reliability
which instructions could be put into the pipeline.
This would've worked well, except for two things:
RAMBUS never really lived up intel's expectations on bandwidth, and its
latency was detrimental enough to make the first models of P4 get their
asses handed to them by late-model P3's.
And they never anticipated the cost of getting a prediction wrong: you
have to flush the entire pipeline and start over. It meant with a 20
stage pipeline the P4 is pretty much twiddling its thumbs waiting for
the RAMBUS to finish its read. The prediction system in the early-model
P4's wasn't accurate enough to be used in such an environment.
Then AMD went on to 7 years of beating Intel in performance.
There were a few things that Intel could do to try to rectify the
situation, namely drop RAMBUS faster than a lead ball fired from an
orbital platform, replacing it with standard DDR and DDR2, which for
that former faster, and for the later faster and more bandwidth; and
improve the P4's prediction system, so much so that the late model p4
extremes had a 30-stage pipeline. Cranking up the hertz also helped, as
it was SOP for Intel for all of its existence at that point.
As Verdauga said, physics put the kabosh on high ghz P4's pretty fast,
and then Intel was forced to fall back onto plan b, and back to being
top dog again.
the only major company still to be using RAMBUS ram is Sony. Go figure. |
You forget how Northwood improved things for the P4. Giving it the
extra cache and higher FSB speed really gave it the ability to kick the
Athlon XP's ass once clock speeds got high enough. It took over a year
for AMD to properly respond with the Athlon 64...
You also forget Intel finally realizing it needed to Dual-Channel its'
DDR chipsets. Rambus had been dual-channeled since the P4 began(Don't
believe the P3 ever needed it...), and was only workable due to that
fact.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 28, 2008 11:16 am Post subject: |
|
Hehe, who needs Tech Talk when you have the bsnes thread!
Thanks for the new WIP. Pause as a command is cool, but is there a
reason why anyone would not want the emulator to pause automatically on
minimization or becoming the inactive window? I see this as desirable
standard behavior. It would save me from even needing to use the
command as those are the natural situations I would want the game and
music to pause (when I'm attending to something else).
Last edited by FitzRoy on Mon Jan 28, 2008 11:26 am; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 28, 2008 11:25 am Post subject: |
|
FitzRoy wrote: |
Pause
as a command is cool, but is there a reason why anyone would not want
the emulator to pause automatically on minimization or becoming the
inactive window? |
It can be nice if you don't want to focus 100% on the game you're
playing, but don't want to keep interrupting the music either.. Other
than that, tbh I'm blank, but a pause command is nice if you have to go
somewhere but you intend to continue playing when you get back - all
convenience stuff of course, but so are a lot of features.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 28, 2008 11:27 am Post subject: |
|
To clarify, I'm not arguing to remove the pause command, I'm just arguing for new automatic pause behavior. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Jan 28, 2008 12:48 pm Post subject: |
|
Just make it an option. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jan 28, 2008 1:10 pm Post subject: |
|
FitzRoy wrote: |
To clarify, I'm not arguing to remove the pause command, I'm just arguing for new automatic pause behavior. |
Judging from other emulators, everyone wants the option to have the
emulator on one screen 'in the background' controlled by a gamepad,
while work can be done 'in the foreground' on the other screen.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 28, 2008 1:23 pm Post subject: |
|
That would mean ignoring input from keyboard, but not gamepad, while inactive. Which seems fair enough. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 28, 2008 4:27 pm Post subject: |
|
Quote: |
Pause
as a command is cool, but is there a reason why anyone would not want
the emulator to pause automatically on minimization or becoming the
inactive window? |
I like leaving bsnes in the background sometimes, eg for listening to
Dracula X music. SPCs would probably work better, if Audacious had a
blargg-DSP plugin.
Anyway, SNESGT has a checkbox toggle for this functionality. I can add
the same to bsnes. I'll just make it poll window_main.focused() once
every emulated frame and use it as an edge-sensitive input to modify
the state of the paused variable.
Quote: |
Judging
from other emulators, everyone wants the option to have the emulator on
one screen 'in the background' controlled by a gamepad, while work can
be done 'in the foreground' on the other screen. |
Alright, let's not get too carried away here. Next you'll all want toaster options or something v_v'
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 28, 2008 6:50 pm Post subject: |
|
byuu wrote: |
Anyway,
SNESGT has a checkbox toggle for this functionality. I can add the same
to bsnes. I'll just make it poll window_main.focused() once every
emulated frame and use it as an edge-sensitive input to modify the
state of the paused variable. |
Good enough, thanks.
Nach wrote: |
Judging
from other emulators, everyone wants the option to have the emulator on
one screen 'in the background' controlled by a gamepad, while work can
be done 'in the foreground' on the other screen. |
I'm not sure what you're saying.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Jan 28, 2008 7:00 pm Post subject: |
|
yeah having an option is best, different strokes for different folks.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Jan 28, 2008 7:31 pm Post subject: |
|
byuu wrote: |
Quote: |
Pause
as a command is cool, but is there a reason why anyone would not want
the emulator to pause automatically on minimization or becoming the
inactive window? |
if Audacious had a blargg-DSP plugin.
|
... it has.
It's using game_music_emu, the blargg emu collection.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Jan 28, 2008 7:49 pm Post subject: |
|
FitzRoy wrote: |
Nach wrote: |
Judging
from other emulators, everyone wants the option to have the emulator on
one screen 'in the background' controlled by a gamepad, while work can
be done 'in the foreground' on the other screen. |
I'm not sure what you're saying.
|
I'm thinking two monitors, bsnes on the one and everything else on the
other with bsnes 'inactive'.. and you'd still be able to play the game
with your gamepad.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Jan 28, 2008 8:15 pm Post subject: |
|
yeah I'm sure lots of people here use two or three monitors, I use 2.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Jan 28, 2008 8:40 pm Post subject: |
|
I
think a very low percentage of people actually have a multi-monitor
setup, and I have always failed to see the benefit of dual screen for
anything other than individuals needing massive design workspace. What
I'm saying is that the prevalent use of a pause feature is going to be
out of attending to something else. If you're going to go attend to
something else, like checking on an auction, you have to bring the
other program up. Bringing it up automatically makes bsnes the inactive
window. But it doesn't pause it. Instead, you're telling me that I
should either perform the action manually to pause or endure the same
music over and over, which is also cutting out on processor intensive
actions being done in the other program. I don't see that as the
rational default functionality. If you're in another window and not
playing the game, there is little reason why that game should continue
running. Byuu says he likes to listen to the repeating music in the
background, and this being the author, I wasn't going to argue. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Jan 28, 2008 9:31 pm Post subject: |
|
byuu wrote: |
Quote: |
Judging
from other emulators, everyone wants the option to have the emulator on
one screen 'in the background' controlled by a gamepad, while work can
be done 'in the foreground' on the other screen. |
Alright, let's not get too carried away here. Next you'll all want toaster options or something v_v'
|
I'm not sure why you think that's getting carried away.
I can find like a dozen threads here or on the Snes9x forum about people doing that or wanting that.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Jan 28, 2008 10:41 pm Post subject: |
|
I
had a novel idea for mouse support, that's kind of an alternative to
ManyMouse. What if I were to bind mouse movement to the analog stick of
a joypad? Then it would be possible to have multiple mice using
multiple joypads. Or even multiple mice on one single dual-axis joypad.
Because fuck if that isn't practical.
The same could be done for Super Scope and Justifier, but would require drawing my own cursor.
It would also allow binding to the keyboard, but obviously controlling
it that way would be much less fun without a "pressure" setting for
speed.
And obviously, pure mouse support would be needed anyway. Have to add a lot of support to miu and vai first.
Quote: |
Byuu says he likes to listen to the repeating music in the background, and this being the author, I wasn't going to argue. |
Nah, it's fine. I'll default the action to pausing when the window loses focus. No problem.
Quote: |
I'm not sure why you think that's getting carried away.
I can find like a dozen threads here or on the Snes9x forum about people doing that or wanting that. |
It's because I don't have nearly as much developer man-power, so I have
to prioritize what I work on. Pause only takes a few minutes to add,
"only accept joypad input when on the second monitor" would take quite
a bit longer.
And if you've seen the utter lack of substantive progress since v0.019,
you'd know that my priorities are bad off enough already :(
Worse yet is I have another big project to work on as well.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Jan 29, 2008 12:15 am Post subject: |
|
byuu wrote: |
"only accept joypad input when on the second monitor" would take quite a bit longer. |
I think it's more a case of "only accept keyboard input when bsnes has
focus" with accepting joypad input when bsnes has lost focus being
optional.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 29, 2008 12:43 am Post subject: |
|
byuu wrote: |
Quote: |
I'm not sure why you think that's getting carried away.
I can find like a dozen threads here or on the Snes9x forum about people doing that or wanting that. |
It's because I don't have nearly as much developer man-power, so I have
to prioritize what I work on. Pause only takes a few minutes to add,
"only accept joypad input when on the second monitor" would take quite
a bit longer.
|
What kind of crazy drugs are you on?
Just always accept joypad input, and don't have an enforced
unchangeable *feature* that bsnes pauses when non focused, and anyone
can use bsnes on a second screen with a joypad while someone is working
on the other screen.
In fact if I'm not mistaken, you already support this. Just don't unsupport it by adding autopause.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Jan 29, 2008 12:57 am Post subject: |
|
yeah, what nach said. 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 29, 2008 12:58 am Post subject: |
|
If
I understood him correctly, there is still going to be an entry in
advanced settings to disable the autopause for the possible scenario
you're giving. But there's no way that situation wins the battle for
default. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Jan 29, 2008 1:06 am Post subject: |
|
Who the heck cares about the default?
As long as the default isn't to delete SRAMs the first time a game is launched or something like that, no one cares.
_________________
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: Tue Jan 29, 2008 1:25 am Post subject: |
|
I
disagree. When you design a program, the defaults should always speak
to the majority, not 1 out of 100 scenarios. You don't give the niche
the luxury of not having to dick with the setting while far more people
have to change it. |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Tue Jan 29, 2008 3:30 am Post subject: |
|
tell that to some of my professors and their excel chart requirements.
but i agree with catering to the masses. it's just that the masses
don't favor the same things. every time i install anything, i go to the
preferences and mess around. i think there really isn't a "majority,"
just groups who like different things. and no one group really stands
out. unless you're talking about really basic basics.
_________________
 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 29, 2008 7:27 am Post subject: |
|
Yes,
most people are going to change something but that's not the point. The
point is achieving the lowest possible average across the entire
userbase. Let's say your userbase is 5000 and average changes-per-user
at first startup is at the minimal number by defaulting to the most
popular setting of each category. If you default color to grayscale,
that's probably going to result in a .99 increase to the average
changes needed per user, because probably 99% of people prefer standard
while only 1% want grayscale. You've just necessitated 4950 extra
actions on startup across the userbase instead of 50 the other way. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 29, 2008 7:42 am Post subject: |
|
Alright, new WIP posted, Windows binary included.
I've added the auto-pause setting. I removed the formerly useless
joypad selection comboboxes, as I want to stick those in the main menu
when they are ready anyway. It defaults to auto-pause, so that
discussion is moot now.
Don't complain that three combo boxes are not natural compared to two
checkboxes -- I don't care. There are only three possible states, and I
like it the way it is. Thanks in advance.
Nach, you have my humble thanks for your input today. This was
definitely a lot easier than I thought it would be with your help.
For those curious, here's how things look at the moment:

I also fixed up the CPU usage when paused. I tried to stress test as
many things as possible (manual pause <> auto pause conflicts,
statusbar update failures, toggling settings in real time, etc etc),
but I may have overlooked something. Rigorous testing would be
appreciated :)
---
In other news, I completely rewrote the Makefile. It is now far more
advanced, and will allow you to easily remove vai modules. Once
removed, the dependencies on those modules will automatically be
removed. The source still needs to be updated to auto-detect
non-existent modules, but this is a step in the right direction.
Take a look at some of my GNU make-fu:
Code: |
ifneq ($(findstring gcc,$(compiler)),) # GCC family
flags = -O3 -fomit-frame-pointer -Ilib
c = $(compiler) $(flags)
cpp = $(subst cc,++,$(compiler)) $(flags) |
Code: |
ifeq ($(platform),x) # X11
miu = miu.gtk
vai = video.glx video.xv video.gtk audio.openal audio.oss audio.ao input.sdl input.x |
Code: |
link += $(if $(findstring audio.directsound,$(vai)),$(call mklib,dsound))
link += $(if $(findstring audio.openal,$(vai)),$(call mklib,openal) $(call mklib,alut))
link += $(if $(findstring input.directinput,$(vai)),$(call mklib,dinput8) $(call mklib,dxguid))
link += $(if $(findstring input.sdl,$(vai)),`sdl-config --libs`) |
Code: |
arch := $(patsubst %,$(call mkdef,%),$(arch))
objects := $(patsubst %,%.$(obj),$(objects)) |
Code: |
compile = $(strip \
$(if $(filter %.c,$<), \
$(c) $(1) $(rule), \
$(if $(filter %.cpp,$<), \
$(cpp) $(1) $(rule) \
) \
) \
)
%.$(obj): $<; $(call compile) |
Code: |
video.glx.$(obj) : ui/vai/video/video.glx.cpp ui/vai/video/*
video.gtk.$(obj) : ui/vai/video/video.gtk.cpp ui/vai/video/*
$(call compile,`pkg-config --cflags gtk+-2.0`) |
Hahahahahah :)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 29, 2008 8:17 am Post subject: |
|
Leave it to byuu to come up with the best solution.
Small wordage criticism: should "Pause emulator" be "Pause emulation"
to match the list or was that an intended distinction? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Jan 29, 2008 9:56 am Post subject: |
|
FitzRoy wrote: |
Leave it to byuu to come up with the best solution.
Small wordage criticism: should "Pause emulator" be "Pause emulation"
to match the list or was that an intended distinction? |
Does 'allow input' include the keys assigned to the UI options as well as the SNES gamepad controls?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 29, 2008 3:43 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Does 'allow input' include the keys assigned to the UI options as well as the SNES gamepad controls? |
No, the main window must be focused for those to ever work. Wouldn't
want to set pause to "p" and have the emulator keep unpausing as you're
typing up something in another window.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Jan 29, 2008 8:16 pm Post subject: |
|
Was
there any revelation in terms of my not being able to map my right
directional? And is there anything I can do to help figure out why my
status bar is still black? |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Jan 29, 2008 9:58 pm Post subject: |
|
Quote: |
Was there any revelation in terms of my not being able to map my right directional? |
Wish I knew how to fix it properly ...
http://sector7.xor.aps.anl.gov/programming/sdl/html/sdljoystickgetaxis.html
The documentation doesn't say a damn thing about axes 4 and 5, which are reversed compared to axes 0, 1, 2 and 3.
I'll get around to hacking it to swap axes 4 and 5 before release, since my joypad does the same thing.
Quote: |
And is there anything I can do to help figure out why my status bar is still black? |
Try changing your GTK+ theme, perhaps? I don't know why it's black, but if I can't reproduce it, I can't fix it.
I added the status bar to an event box just like the documentation says
to do, so like the old "fullscreen" issue, it's probably not a bug in
my code.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 30, 2008 3:54 am Post subject: |
|
All
fixed! Well, the status bar is, at least. The theme I was using was old
and buggy, and there was a newer version that works perfectly. Should
have switched long ago. So that just leaves me with my axis issues...
since my computer seems to be playing most games at full speed for now.
Just tested it with my gravis gamepad pro, and that worked like a
charm. I have no idea why there would be a difference but that's just
me being a noob. My controller of choice is my ps2 dual shock plugged
in through a usb adapter, which isn't giving me any problems in my
other emulators (though I don't know how many of my emulators use sdl
offhand, to be honest). On still further testing, configuring the
gravis pad correctly and then switching it with the ps2 pad (restarting
the emulator and all) still won't make the right directional work, even
though all other directions and buttons will be properly configured
under the same settings (did I lose you yet?).
Does that help, or was that completely useless? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jan 30, 2008 6:47 am Post subject: |
|
DancemasterGlenn wrote: |
Secondly,
when attempting to map my gamepad, every single key logged correctly...
except my right directional. What? Weird. Every other button on my
controller registers. It's a ps2 controller hooked up through a usb
adapter, and even the dual shock doesn't seem to work right: the left
analog stick works exactly the same as the d-pad (which means the right
movement won't map), and the right one maps like this:
pressing left = joypad00.up
pressing right = joypadd00.down
pressing up = joypad00.left
pressing down = nothing. of course. bah!
I tested it in all my other emulators, and it's still running the same in those. |
DancemasterGlenn wrote: |
Just
tested it with my gravis gamepad pro, and that worked like a charm. I
have no idea why there would be a difference but that's just me being a
noob. My controller of choice is my ps2 dual shock plugged in through a
usb adapter, which isn't giving me any problems in my other emulators
(though I don't know how many of my emulators use sdl offhand, to be
honest). On still further testing, configuring the gravis pad correctly
and then switching it with the ps2 pad (restarting the emulator and
all) still won't make the right directional work, even though all other
directions and buttons will be properly configured under the same
settings (did I lose you yet?). |
So, do your analog sticks work properly now? Or only if you pre-configure them using the Gravis pad?
And the right direction on the d-pad still doesn't work?
It seems like the Dualshock or the adapter is using variable names for
its axes/buttons that bsnes doesn't recognize as gamepad input. Perhaps
if there is some kind of calibration program out there that will show
you the variable names and values of input from a gamepad, they can be
added to bsnes.
This seems like an issue that any program accepting gamepad/joystick
input would have to overcome. Actually, it all relates to interpreting
input from a theoretically infinite number of sources (keyboards of
different languages, varying gamepads/joysticks, etc).
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 30, 2008 7:01 am Post subject: |
|
Well,
I'm using my d-pad, not the analog sticks, but the analog sticks still
have the same problem as reported in the original post. The left stick
does the same thing as the d-pad (maps everything but the right
directional), while the right stick logs everything but the top
directional... because the direction inputs from that stick are all
moved counter-clockwise (ie, "up" is "right"). In other words, all
three are mapped as the same input, with the addition of the
counter-clockwise problem on the right stick (which probably shouldn't
be mapped the same as the other two directional inputs anyway, not that
I was going to use it for anything).
So what I'm
saying in my recent post is that I still cannot map "right" with my
dual shock. I CAN map "right" with my gravis pad, and it works
(pressing right = joypadd00.right). However, switching back to my dual
shock after this has been mapped (I was hoping that joypadd00.right
being already in the input box might make the right directional
magically work on my dual shock) still does not allow right movement.
Which I wasn't really expecting would solve the problem, since that
wouldn't really make sense.
Hopefully that was more clear. My gravis pad maps and works. my dual
shock neither maps nor works, in terms of the right directional. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Jan 30, 2008 1:30 pm Post subject: |
|
What's
the deal with BSNES being unable to stop the screensaver/power savings
from coming on? I think it's the only emulator I've ever used with this
issue. Every 20 minutes, off goes my monitor. I know it was mentioned
in one of the past 170 pages, but I couldn't effectively find 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Jan 30, 2008 2:59 pm Post subject: |
|
I
think I was the one who requested that a long time ago, but screensaver
suppression is apparently hard to figure out. Currently, if you use a
gamepad only to play like I do, the screensaver pops up while you're
playing. Ideally you don't want absolute suppression, but for the OS or
emulator to treat joypad presses like keyboard presses and recognize
them as proof that someone is doing something... instead it ignores
them and thinks you're idle. This is in Windows, anyway, I don't know
if Linux behaves the same. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 30, 2008 4:17 pm Post subject: |
|
Quote: |
So what I'm saying in my recent post is that I still cannot map "right" with my dual shock. |
Oh, sorry. I thought you meant the right analog thumb was the problem.
Right in general ... the only thing I can think of is that your dual
shock is giving crazy X axis values.
Can you do me a small favor? Since you had to compile anyway on Linux
... edit src/ui/vai/input/input.sdl.cpp, starting at line 222:
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
if(axis == 0) printf("axis %d = %d\n", a, SDL_JoystickGetAxis(joy[i], a); //add this line
if((a & 1) == 0) { //X axis
joystate[i][joy_left] |= SDL_JoystickGetAxis(joy[i], a) < -16384;
joystate[i][joy_right] |= SDL_JoystickGetAxis(joy[i], a) > +16384;
} else { //Y axis
joystate[i][joy_up] |= SDL_JoystickGetAxis(joy[i], a) < -16384;
joystate[i][joy_down] |= SDL_JoystickGetAxis(joy[i], a) > +16384;
}
} |
Now, when you start bsnes, do it from a terminal, and when you load a
game you'll see the terminal go crazy printing the state of axis 0. You
can change the if(axis == 0) to if(axis == 1), etc as you like. 0 is
the X axis for the left D-pad.
Basically, you should see a value of about 0 when your dual shock left
D-pad or thumb is centered. It should go to as low as -32768 when you
press left, and as high as 32768 when you press right. Please let me
know what values you are seeing for each three directions fully pressed.
Quote: |
What's the deal with BSNES being unable to stop the screensaver/power savings from coming on? |
I don't know how to disable the screensaver. Is it just a single API call? Post it and I'll add it.
Quote: |
I think it's the only emulator I've ever used with this issue. |
That's nice.
Quote: |
Every 20 minutes, off goes my monitor. |
You should tell the dipshits at Microsoft, as well as Torvalds, that a
keyboard and a joypad are both input devices, and both should suppress
the screensaver. In the meantime, leave it to every last individual
application developer to keep fixing shortcomings in operating systems.
As we already do for compressed archive support.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Jan 30, 2008 4:26 pm Post subject: |
|
byuu wrote: |
I don't know how to disable the screensaver. Is it just a single API call? |
IIRC, it's two. One to disable screen saver, and another to disable power management on the screen.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Jan 30, 2008 6:28 pm Post subject: |
|
byuu wrote: |
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
if(axis == 0) printf("axis %d = %d\n", a, SDL_JoystickGetAxis(joy[i], a); //add this line
if((a & 1) == 0) { //X axis
joystate[i][joy_left] |= SDL_JoystickGetAxis(joy[i], a) < -16384;
joystate[i][joy_right] |= SDL_JoystickGetAxis(joy[i], a) > +16384;
} else { //Y axis
joystate[i][joy_up] |= SDL_JoystickGetAxis(joy[i], a) < -16384;
joystate[i][joy_down] |= SDL_JoystickGetAxis(joy[i], a) > +16384;
}
} |
|
That won't compile. I get this error:
Code: |
ui/vai/input/input.sdl.cpp: In member function 'void pInputSDL::poll()':
ui/vai/input/input.sdl.cpp:224: error: 'axis' was not declared in this scope
ui/vai/input/input.sdl.cpp:224: error: expected `)' before ';' token
make: *** [input.sdl.o] Error 1 |
At a quick glance, I can see there is a ) missing in the line you told
me to add, but I'm not 100% certain where it's supposed to go. Once I
know and this compiles, I'll be more than happy to test this thoroughly.
And thank you as well, I'm glad I made more sense in my last post.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Jan 30, 2008 6:51 pm Post subject: |
|
From the looks of it there should be another ) just before the semicolon. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Jan 30, 2008 7:02 pm Post subject: |
|
For those with GNU make, try running the below "Makefile" that I just created :)
Code: |
l1 = 9 8 7 6 5 4 3 2 1 0
l2 = $(1)$(2) bottle$(if $(filter 1,$(1)$(2)),,s) of beer on the wall, \
$(1)$(2) bottle$(if $(filter 1,$(1)$(2)),,s) of beer ... \
you take one down, pass it around ... \
$(if $(filter 1,$(1)$(2)),no more bottles of beer on the wall!,)$(space)
all:
#We can't turn the below statements into one dual-nested foreach loop, because
#it exceeds the maximum length for a string supported by GNU make. Pity that.
@echo $(foreach n,$(l1),$(call l2,9,$(n)))
@echo $(foreach n,$(l1),$(call l2,8,$(n)))
@echo $(foreach n,$(l1),$(call l2,7,$(n)))
@echo $(foreach n,$(l1),$(call l2,6,$(n)))
@echo $(foreach n,$(l1),$(call l2,5,$(n)))
@echo $(foreach n,$(l1),$(call l2,4,$(n)))
@echo $(foreach n,$(l1),$(call l2,3,$(n)))
@echo $(foreach n,$(l1),$(call l2,2,$(n)))
@echo $(foreach n,$(l1),$(call l2,1,$(n)))
@echo $(foreach n,$(wordlist 1,9,$(l1)),$(call l2,,$(n))) |
Quote: |
That won't compile. |
Oops, sorry. Didn't even proofread the code.
Code: |
if(axis == 0) printf("axis %d = %d\n", a, SDL_JoystickGetAxis(joy[i], a)); //add this line |
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Jan 31, 2008 2:49 am Post subject: |
|
Still no on compiling... I still get these errors.
Code: |
ui/vai/input/input.sdl.cpp: In member function 'void pInputSDL::poll()':
ui/vai/input/input.sdl.cpp:224: error: 'axis' was not declared in this scope
make: *** [input.sdl.o] Error 1 |
So I changed axis to axes in this part":
if(axes == 0) printf("axis %d = %d\n", a, SDL_JoystickGetAxis(joy[i], a));
and it compiles, but isn't giving me any readouts when I launch it in terminal... what's my next step?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 31, 2008 6:57 am Post subject: |
|
Geez, I suck at this. Third time's a charm, right?
Code: |
if(a == 0) printf("axis %d = %d\n", a, SDL_JoystickGetAxis(joy[i], a)); //add this line |
Have to run a game before the text starts printing.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Jan 31, 2008 7:30 am Post subject: |
|
Well,
it worked... I didn't have to run a game before text started printing,
actually. -32767 and 32767 are the values I got for left and right...
with both pads. So bsnes is getting the same left and right values for
both pads... but I still can't map "right" with my dual shock.
I'm totally stumped. Not that I wasn't stumped before. Is there anything else I can do or try, at all? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 31, 2008 7:52 am Post subject: |
|
Quote: |
Is there anything else I can do or try, at all? |
Yes, of course. We'll get it fixed, no worries :)
Thanks so much for your help testing this.
Please try the below code. Perhaps polling the axis location twice in a row is causing a problem.
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
int value = SDL_JoystickGetAxis(joy[i], a);
if((a & 1) == 0) { //X axis
joystate[i][joy_left] |= value < -16384;
joystate[i][joy_right] |= value > +16384;
} else { //Y axis
joystate[i][joy_up] |= value < -16384;
joystate[i][joy_down] |= value > +16384;
}
} |
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Jan 31, 2008 8:24 am Post subject: |
|
That code seems to work the same for me as the previous code :\
And you're totally welcome, I'm glad to be contributing something to
bsnes development. Anything I can test is welcome. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jan 31, 2008 9:44 am Post subject: |
|
This is a linux-only problem, right? If not, I also have a PS2 controller adapter I could test. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Jan 31, 2008 1:31 pm Post subject: |
|
byuu wrote: |
I don't know how to disable the screensaver. Is it just a single API call? |
byuu, every piece of information I can find points to simply handling
some additional messages in the Win32 message loop.
Code: |
case WM_SYSCOMMAND://if its a system command
{
switch (wParam)//enter the switch
{
case SC_SCREENSAVE://intercept the screensaver
return 0;//prevent it from happening
case SC_MONITORPOWER://intercept the powersave
return 0;//prevent it from happening
}
break;
}
|
If you implement that in your message loop, that should be all there is too 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.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Jan 31, 2008 3:26 pm Post subject: |
|
Verdauga Greeneyes wrote: |
This is a linux-only problem, right? If not, I also have a PS2 controller adapter I could test. |
No idea, maybe later today I can test it on my roommate's computer or
something. What kind of adapter do you have? I just have the 15 dollar
one from radio shack.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Jan 31, 2008 4:59 pm Post subject: |
|
Ah,
I ordered one online, dunno how hard it would be to get one over here
otherwise. It's called "Universal PS2 Controller Adapter" and connects
to PC, GameCube and.. something else, Dreamcast perhaps.
Edit: ah, it's the Xbox. Anyway, I'm going to wait for an answer from
byuu before I test this one.. would probably need to use the latest WIP
anyway. |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Thu Jan 31, 2008 6:13 pm Post subject: |
|
I've
got a Ubuntu 6.10 machine sitting around, likely still in
bootable/usable shape, along with a pair of each type of Radio Shack
USB/DualShock adapter. Relevant hardware would be the south bridge
(into which the USB controllers are integrated), which is an Intel
82801ER (ICH5R).
Let me know if you need an extra
test box for that controller issue, and I'll see if I can get that box
up tomorrow or over the weekend.
_________________
Why yes, my shift key *IS* broken. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Thu Jan 31, 2008 6:14 pm Post subject: |
|
Nightcrawler wrote: |
byuu wrote: |
I don't know how to disable the screensaver. Is it just a single API call? |
byuu, every piece of information I can find points to simply handling
some additional messages in the Win32 message loop.
Code: |
case WM_SYSCOMMAND://if its a system command
{
switch (wParam)//enter the switch
{
case SC_SCREENSAVE://intercept the screensaver
return 0;//prevent it from happening
case SC_MONITORPOWER://intercept the powersave
return 0;//prevent it from happening
}
break;
}
|
If you implement that in your message loop, that should be all there is too it.
|
That's right. Windows polling every application in message system chain
and asking everyone - i'm going to run screensaver, are you ok with it?
Touching keyboard & mouse seems to constantly\instantly reset the
countdown. Usually it's not a big problem even for a game, but
unfortunately joystick do not reset screensaver countdown.
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Jan 31, 2008 9:41 pm Post subject: |
|
Yes, joypad issue is Linux only. If anyone else wants to test, that's cool, but please don't go out of your way.
Well, let's try working our way backward and see what part exactly is
failing for you. Please try the below code next, if you don't mind.
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
int value = SDL_JoystickGetAxis(joy[i], a);
if((a & 1) == 0) { //X axis
joystate[i][joy_left] |= value < -16384;
joystate[i][joy_right] |= value > +16384;
printf("left = %d, right = %d\n", joystate[i][joy_left], joystate[i][joy_right]);
} else { //Y axis
joystate[i][joy_up] |= value < -16384;
joystate[i][joy_down] |= value > +16384;
}
} |
This should print left = 0, right = 1 when pushing right.
Quote: |
byuu, every piece of information I can find points to simply handling some additional messages in the Win32 message loop. |
Alright, thanks. I'll think of some clever names and add them tonight.
Won't work on Linux, of course. Looks like you have to use D-Bus
(another dependency), or fake X11 events periodically. The latter
sounds like less trouble.
---
More work on allowing vai modules to be compile-time options.
Code: |
strtr = \
$(eval __temp := $3) \
$(strip \
$(foreach c, \
$(join $(addsuffix :,$1),$2), \
$(eval __temp := \
$(subst $(word 1,$(subst :, ,$c)),$(word 2,$(subst :, ,$c)),$(__temp)) \
) \
) \
$(__temp) \
)
strupper = $(call strtr,$([a-z]),$([A-Z]),$1)
vaidef := $(foreach c,$(subst .,_,$(call strupper,$(vai))),$(call mkdef,$c)) |
Eval usage and variables with [] in them was inspired by GMSL.
That above code will turn:
"video.glx audio.openal input.sdl input.x"
into:
"-DVIDEO_GLX -DAUDIO_OPENAL -DINPUT_SDL -DINPUT_X"
I'm sure you can imagine why that'd be useful. Headers are easily included only when appropriate defines are set.
But now, how to handle the uiVideo = new VideoFoo(); parts ... ?
Specifically, how to handle the ultimate fallback. We don't want
system.video = "" to default to no video at all ...
Seems like it'd be annoying to keep #ifdef lists once for the headers,
once for the config-file name matching and once more for the blank
config-file name auto selection.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 01, 2008 4:54 am Post subject: |
|
I
think you've found the problem, perhaps... upon starting bsnes left is
at 0, but right keeps showing a 1 every few lines. Pressing and holding
left gives me all 1s, but the right behaviour continues with its 1s and
0s. Pressing and holding right gives me all 1s in that column, all
zeros in the left column (but I'm sure that doesn't matter). So yeah,
that seems to be the problem? It's weird that bsnes is the only
emulator affected by this... I don't suppose there's a way to code
around it? There never seems to be more than one 1 in a row when it's
doing this, so maybe if there was a way for the input config to wait
for a "long press"?
And even if that is possible,
I wonder if I would just constantly be moving right? Blah, this is so
weird. It must be my controller, right? So really, why doesn't this
happen in any of my other apps?
Unless it has something to do with the analog sticks? They're still
mapped to the same axes as the dpad, right? The button to use them is
off, but that might not be stopping them if they're not mapped
separately... does that make sense? That would mean if they're even a
bit off, they're polling right and skewing the dpad input data. But
that's just me throwing out ideas now.
Let me know if there's anything else I can try. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 01, 2008 5:33 am Post subject: |
|
Have
you tried setting higher and lower sensitivity settings within bsnes?
Maybe the device really is haywire and it only works with other
emulators by virtue of some sensitivity quirk. I dunno, when I can't
get something to work I try anything remotely related to it and try to
rationalize why it might work even if I don't understand wth I'm on
about. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 5:40 am Post subject: |
|
The
code byuu provided prints a 1 if the function is telling it the stick
is moved more than 50% in that direction.. This makes it sound like
some sort of short is happening in the adapter. What has me confused is
that you say the right axis keeps printing 1s now and again even when
you're pushing the stick to the left? Looking at byuu's code, that
should be impossible, considering the variable 'value' can't be <
-18384 and > +18384 at the same time. Could you confirm this?
And if you would, could you give us an idea of the value spread when
you use the following code instead? What happens when you leave the
stick centred? And if you push it all the way to the right?
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
int value = SDL_JoystickGetAxis(joy[i], a);
if((a & 1) == 0) { //X axis
joystate[i][joy_left] |= value < -16384;
joystate[i][joy_right] |= value > +16384;
printf("value = %d\n", value);
} else { //Y axis
joystate[i][joy_up] |= value < -16384;
joystate[i][joy_down] |= value > +16384;
}
} |
(I hope that works, never actually used printf() before, oddly)
Edit: sorry to push your post out of sight, FitzRoy; I'd like to
clarify that in the code being used to test this, there's a deadzone of
50%, and anything above that is 'pressed'.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 01, 2008 6:40 am Post subject: |
|
Apologies in advance, this could be a long post.
This doesn't seem to be a sensitivity issue, thinking about it a little
more. The value that keeps getting polled is 32767, which is the same
as my maximum press in any direction. So for some reason, the
controller (or whatever is going on) thinks it's being pressed fully to
the right every few seconds (or whatever interval it's running at,
possibly frames despite me not running any roms with this code).
To clarify, this is what I was getting (without pressing anything) with the last code:
Code: |
left = 0, right = 1
left = 0, right = 0
left = 0, right = 0
left = 0, right = 0
left = 0, right = 1
left = 0, right = 0
left = 0, right = 0
left = 0, right = 0
left = 0, right = 1
left = 0, right = 0
left = 0, right = 0
left = 0, right = 0 |
and so on. Pressing right gave me this:
Code: |
left = 0, right = 1
left = 0, right = 1
left = 0, right = 1
left = 0, right = 1
left = 0, right = 1
left = 0, right = 1 |
and left gave me this:
Code: |
left = 1, right = 1
left = 1, right = 0
left = 1, right = 0
left = 1, right = 0
left = 1, right = 1
left = 1, right = 0
left = 1, right = 0
left = 1, right = 0 |
which led me to believe that yes, for some reason it's polling both
directions at once, which I assumed was impossible.
At Fitz, I'm tweaking numbers like crazy, but it doesn't seem to be helping any...
New code gives me this, at rest:
Code: |
value = 32767
value = 0
value = 0
value = 0
value = 32767
value = 0
value = 0
value = 0 |
pressing left...
Code: |
value = 32767
value = -32767
value = 0
value = 0
value = 32767
value = -32767
value = 0
value = 0 |
pressing right...
Code: |
value = 32767
value = 32767
value = 0
value = 0 |
So I'm mostly stumped, though I do have one more thing that might be
helpful? I'm starting to notice something that may be very important
(but may be totally trivial...
See in the code how it polls the "right" value once every four times?
And how pressing right gives me two of that value in a row, instead of
making them all 32767? I think it has to do with more than one part of
my joystick being treated as the dpad... to test this, I enabled the
analog sticks and tried pressing right on both the dpad and the left
stick at once. Which got me this:
Code: |
value = 32767
value = 32767
value = 32767
value = 0 |
and keeping in mind that the right stick is still twitsted so that down
is "right", pressing down on that stick as well gave me this:
Code: |
value = 32767
value = 32767
value = 32767
value = 32767 |
So... here's what I'm thinking (probably wrong, but hey...). For some
reason, four different things are being polled for my directional
input. Three of them are my dpad and analog sticks. One of them...
well, I have no idea. But whatever it is seems to be stuck on "right".
Right? If this is the case (I wouldn't know how to test this), then
something in the code is reading directional inputs incorrectly. Right?
I hope so, I feel like I'm talking gibberish... hope I've hit on
something, though. Thanks for the code, VG.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Fri Feb 01, 2008 7:07 am Post subject: |
|
a d-pad is nothing but four buttons arranged in a cross.
the design of the pad is there to prevent that, but it is possible to have all four being read as pressed.
A quickie suggestion would have bsnes skip a read if it looks like both ends of the axis is being pressed.
have you tested with other PS2 dual shocks?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 7:28 am Post subject: |
|
Okay,
I'm reversing my earlier verdict. To anyone who read my post before
this, sorry. I've been trying to figure out how the joystates, which
are bitwise ORed, kept resetting in byuu's test code, when they seemed
to be set at the start of the loop. Solution is simple: they're not set
at the start of the loop, they're set at the end; it's just human
nature to put a big number first. Rather than a non-existent thumbstick
for axes 0 and 1, I'm pretty sure it's detecting a -fourth- stick that
doesn't exist. So axes 0 and 1 are the D-pad, 2 and 3 are the left
analogue stick, 4 and 5 are the right one, keeping in mind that they're
reversed, and 6 (and 7?) doesn't actually exist and always returns
32767.
Last edited by Verdauga Greeneyes on Fri Feb 01, 2008 8:12 am; edited 2 times in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 8:05 am Post subject: |
|
Verdauga
Greeneyes is exactly correct. Looking at your log, it's clear to me
that there are eight axes total. While your stick only has six (three
per X/Y direction. One for D-Pad, one for left analog, one for right
analog.)
DancemasterGlenn, go ahead and run Verdauga's newest test if you don't mind, just to be absolutely certain.
Thanks Verdauga Greeneyes, I wouldn't have caught this without your
printf modification. I was starting to suspect stack corruption on the
joystate buffer earlier.
Now, the question is ... how are we going to fix this? If I ignore
SDL's built-in JoystickNumAxes function, then controllers that really
do have four axes (if such a thing exists) will no doubt be crippled.
This seems more to be a bug with either SDL itself or the joypad
driver. Sigh, looks like I was wrong. Even the SDL input driver is a
piece of shit. It would seem that quite literally all of SDL is completely worthless. Too bad there's no portable (to BSD et al) alternative for joypads.
The last idea I can think of is kind of lousy. I could disassociate
each axis after 0,1 (the real D-pad) as separate keys. The thing that
sucks so much here is that now you won't be able to switch to the
analog sticks unless you remap the controller again. But the neat thing
is that you can use both as additional buttons, eg to perform UI
operations or something cute like that.
The phantom axis shouldn't map since the state never changes. No
transition should ever occur on it, so no key will ever be assigned.
It's this, or I just ignore any axis > 3 or 5.
Last edited by byuu on Fri Feb 01, 2008 8:08 am; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 8:08 am Post subject: |
|
Hey
byuu, looks like my edit and your post crossed eachother. As an
extension to your idea, couldn't you simply allow the user to map other
axes as alternative keys?
Edit: figured I'd repost my test, somewhat modified:
Code: |
int axes = SDL_JoystickNumAxes(joy[i]);
for(int a = 0; a < axes; a++) {
int value = SDL_JoystickGetAxis(joy[i], a);
if(a == 0 || a == 2 || a == 5 || a == 6) { //X axis
joystate[i][joy_left] |= value < -16384;
joystate[i][joy_right] |= value > +16384;
printf("axis = %d: left = %d, right = %d\n", a, value < -16384, value > +16384);
if(a == 1 || a == 3 || a == 4 || a == 7) { //Y axis
joystate[i][joy_up] |= value < -16384;
joystate[i][joy_down] |= value > +16384;
}
} |
Last edited by Verdauga Greeneyes on Fri Feb 01, 2008 8:15 am; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 8:11 am Post subject: |
|
That's okay, your edit is still in line with what I see. The problem is with axes 6 and 7.
I'm almost certain DancemasterGlenn will always see
"a=7,left=0,right=1". The bitwise OR in the loop before is why we
couldn't see the pattern before. My test manually excluded axes 1-7,
which gave him the correct range when he pushed the axis in said
directions.
Quote: |
As an extension to your idea, couldn't you simply allow the user to map other axes as alternative keys? |
Yes, mentioned at the end of my above post. The one problem is that
Windows DirectInput probably won't allow this, and Linux will no longer
let the user switch back and forth between D-pad and analog stick to
play games without remapping the input first. On the plus side, you get
4-8 new mappable keys on the same joypad.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 8:17 am Post subject: |
|
byuu wrote: |
and
Linux will no longer let the user switch back and forth between D-pad
and analog stick to play games without remapping the input first. |
Why is this? Won't both simply work at the same time? (when analog is enabled on the gamepad)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 9:11 am Post subject: |
|
How annoying.
Code: |
analog mode:
0,1 = left
3,2 = right (swapped axes)
4,5 = D-pad
digital mode:
0,1 = D-pad
4,5 = left
3,2 = right (swapped axes) |
So basically, if I only accept axes 0,1 then the D-pad will be used in
digital mode, and the left thumb stick in analog mode.
I was hoping to just map 0-3 and be done with it.
EDIT: http://www.google.com/codesearch?hl=en&q=+sdl_joystickgetaxis&sa=N
Yeah, everyone else either reads just 0,1 or reads them all. The
emulators all seem to only process 0,1. Great. Yet another reason to
hate SDL.
Alright, fine. I'll just poll axes 0-5 for now, which should fix
DancemasterGlenn's issue. When I manage to get per-driver settings,
I'll add one to SDL input to let the user specify which axes to poll,
eg:
vai.input.sdl.x_axes = "0,3,4"
vai.input.sdl.y_axes = "1"
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 01, 2008 10:01 am Post subject: |
|
byuu wrote: |
I'm almost certain DancemasterGlenn will always see "a=7,left=0,right=1". |
It ended up being axis 6, but yes, that pinpointed it exactly.
Quote: |
Alright, fine. I'll just poll axes 0-5 for now, which should fix DancemasterGlenn's issue. |
Yay! I'm happy this will be working soon, and thank you so much for working me through it. You too, Verdauga!
(Also, Glenn is just fine, no need to waste precious time typing)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 10:53 am Post subject: |
|
DancemasterGlenn wrote: |
It ended up being axis 6, but yes, that pinpointed it exactly.
Yay! I'm happy this will be working soon, and thank you so much for working me through it. You too, Verdauga! |
Yeah, I initially had 6 and 7 switched, then realised this wasn't the
case. Instead, I switched 4 and 5 in my test, but according to byuu's
last post that's not right either o.o
Oh well, glad it's been somewhat resolved, even if the conclusion is
that the way to do it sucks. Glad I could help 
byuu wrote: |
vai.input.sdl.x_axes = "0,3,4"
vai.input.sdl.y_axes = "1" |
So besides up, down, left and right there would be these two 'special
case' controls to accomodate thumbsticks? That seems reasonably sane
and intuitive 
By the way, in Windows up on the D-pad and up on the left analogue
stick are the same, and the right stick is disabled entirely; I guess
that's what you were aiming for all along - I hadn't really noticed
before!
Last edited by Verdauga Greeneyes on Fri Feb 01, 2008 11:04 am; edited 2 times in total
|
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Fri Feb 01, 2008 10:59 am Post subject: |
|
Hmm, this might be slightly off topic; just wondering if you've considered using OIS (Object-oriented Input System) yet? It's what OGRE uses for all their demos. Might be worth to take a look.
Would need porting for BSD gamepads however. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 11:46 am Post subject: |
|
New WIP.
I removed property.hpp, as I really didn't like it. Reverted Audio
wrappers to use cap/get/set method that Video and Input wrappers use.
Yay, consistency.
Capped input.sdl to only poll up to six axes. I suppose if someone
really only has 2 or 4, and has phantom 5,6 axes, they'll run into
Glenn's problem. Meh. We'll wait for a way to configure vai settings on
a per-driver basis to work on that problem more. I was thinking of just
giving it the handle to either unique configuration class objects, or
to the bsnes.cfg one. Just dump all settings for all (compiled-in)
drivers in there, in case the user wants to keep swapping between
drivers.
Added Nightcrawler's screensaver and monitorpower disable code. Happy
now? Note, I don't use screensavers, nor do I feel like playing for ten
minutes to verify. If anyone else could verify whether or not it's
working, I'd appreciate it. Note again, this won't work on X11, only
Windows.
Improved the makefile a bit more for Visual C++. Disabled the warning
about passing "this" in a constructor. It's valid and safe C++, and the
only way to implement a bidirectional private implementation by
reference. The last warning is comparison between unsigned long long
and bool, which I can't see a problem with (it gives no warnings about
unsigned long and bool, either). Should I just disable that warning, as
well?
Quote: |
It ended up being axis 6, but yes, that pinpointed it exactly. |
Oops, sorry. When there are two of something, I always have a really
hard time telling them apart (x/y, hidori/migi, edge/level (sensitive),
etc etc). Not sure why that is. Three or more choices and it's never a
problem.
Quote: |
Would need porting for BSD gamepads however. |
If it doesn't support BSD, then I'm not really interested. I kind of
have to special case Windows (~95+% userbase), but I don't personally
want to waste my time writing Linux only code.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 01, 2008 1:02 pm Post subject: |
|
Any chance of seeing something like this in a future version of bsnes?
(note I whipped this up very quickly in paint.. the axes should probably know what gamepad they belong to, as well) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 5:07 pm Post subject: |
|
Hmm,
thinking about it ... I really don't like the name vai for the
video/audio/input wrappers. Need to come up with something catchier,
and then move all of that stuff into there (header inclusions, uiVideo
= new Video*(), etc). Then I'll write wrappers for the uiVideo* et al
to work as a solid object that internally chooses and allocates each
driver internally. Should make driver-specific settings a bit easier to
manage, too.
Ruby would've been a great name for it to complement Nall, but meh. A certain programming language would probably get mixed up really well with that. Maybe I should use it anyway? :)
It isn't as if anyone in the world is ever going to use this lib
besides me, anyway. Or does anyone have a better name suggestion, for
what is essentially an ultra-lightweight, statically-linked version of
SDL which allows the user to create and manage their own windows?
Quote: |
Any chance of seeing something like this in a future version of bsnes? |
Probably not. One axis has "three" possible states (eg left, center,
right), which we need to map to two unique "keys". And we can't even
assume whether a given axis is horizontal or vertical since SDL just
randomly switches them up and lacks any way to get more detailed info
on them.
So we'd end up with having to give each and every direction random numerical identifiers, two per axis.
So for a PS2 dual shock, there would be joypadN.<axis_00 - axis_11>, and even then, the values assigned would change whenever the user toggles the digital button on the joypad.
Plus, it's not at all intuitive. If the user wants "Up" mapped to the
joypad's up button, they aren't going to know what joypad00.axis_08
means. Especially when it changes dynamically on them.
But who knows. Maybe I can add a new joypad option that lets map each
axis separately. The user can use the individual mapping mode, knowing
full well it will be unreadable, but allow more buttons to be mapped.
Not so sure I can add this to DirectInput, and I bet even SDL isn't as
fucked up on Windows, since it probably backends to DirectInput anyway.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 01, 2008 5:37 pm Post subject: |
|
This new WIP... is like butter
This completely fixes all my issues (except for sound, which is partly
linux's fault anyway). Anything after this will just be icing on the
cake.
Next time I'd better not stay up so late helping out... I slept through my first japanese quiz oh well. I'll work extra hard to catch up.
Anyhoo, just wanted to say thank you. Let me know if you need anything else tested. |
|
Arbee Rookie
Joined: 20 Aug 2006
Posts: 35
|
Posted: Fri Feb 01, 2008 9:29 pm Post subject: |
|
Quote: |
The documentation doesn't say a damn thing about axes 4 and 5, which are reversed compared to axes 0, 1, 2, and 3.
I'll get around to hacking it to swap axes 4 and 5 before release, since my joypad does the same thing. |
That's because it's not SDL doing it. Linux's kernel drivers for
various types of joypads tend to be inconsistent for one of 2 reasons:
1) The driver itself is inconsistent
2) The hardware's inconsistent and the driver doesn't bother to clean up the input to meet "standard" results
For instance, the PS3 Sixaxis controller is recognized automatically by
recent kernels. All of it's buttons are pressure sensitive, and so
there are roughly 2 dozen axes reported. The problem is that the axes
which actually are axes (the digital pad and the 2 analog joysticks)
work as you'd expect with 0 the center, -32k is left/up, and +32k is
right/down. The buttons all report such that -32k is unpressed, 0 is
halfway, and +32k is fully pressed. This causes holy hell for MAME, as
you might expect. I added a -sixaxis switch to ignore the extra axes.
It seemed saner that way.
On the other side, the Xbox 360 controller also works with recent
kernels and has no pressure-sensitive buttons to cause trouble, but
some of the directional axes are mapped the opposite of all other
controllers (left reports +32k and right reports -32k, stuff like
that). I gather in both cases that's just how the hardware is, but you
and I at the application level shouldn't have to deal with that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 01, 2008 11:13 pm Post subject: |
|
Quote: |
1) The driver itself is inconsistent
2) The hardware's inconsistent and the driver doesn't bother to clean up the input to meet "standard" results
...
The buttons all report such that -32k is unpressed, 0 is halfway, and +32k is fully pressed. |
Ah, good to know, thank you.
And those buttons, holy hell. With -32k being unpressed, they're going
to trip off everything as being already set for sure.
Hmm, here's what I'm thinking ... we create a special calibration test window, and ask the user to make fucking sure
no buttons are pressed and all axes are centered / untouched. We then
poll everything available and map whatever value we get as the "idle"
state.
From there, we can ask the user to press
left, map what axis is affected and what that value should be. Do the
same for each other direction. When finished, ask if they wish to map
another stick to the emulated D-pad as well. Repeat until they've had
enough. Then, every axis not mapped is completely ignored. Or possibly,
ask if they want to start mapping other axes to virtual buttons. We'll
keep a list and avoid conflicts, and then add a tolerance slider to
affect the variance allowed from the measured value. Buttons are easy
as they're just booleans.
Even SDL has an option to query the name of the joypad, so we can
create profiles for each joypad name, so that the user can hotswap
joypads. Boy, will all of that be fun to implement.
---
Another alternative would be to just write a simple standalone (or
integrated) GTK+ app that lets the user see what each axis does in
real-time, and then just do the axis mapping as "hey, trigger this
button when axis changes by ~32k in this direction."
Of course, that sucks for GUI axis labels ("axis_06CL" (CL =
center-to-low) instead of "up", for instance,) but it works ...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Feb 02, 2008 1:25 am Post subject: |
|
It's
a pity that there is so much inconsistency even with how the state
changes when a button is pressed; other than that, your idea is pretty
similar to the one I had before:
1.) User selects a button on the SNES to assign to a button on his/her controllers
2.) The moment User clicks Assign Key, bsnes polls and saves the state
of all buttons/axes (or do buttons always work the same way) on
detected joypads to dynamically created tables with a few for loops
3.) bsnes polls keyboard, joypad buttons and axes until an event is
received (does this work for axes or would you have to poll them for
change manually?)
4.) when event is received, bsnes records a 'mode 0' control to the
config file if it's from a button, containing just the joypad and
button names, or a 'mode 1' control that also includes the value of the
axis before and after the event, then exits the loop (presumably, mode
0 could just be mode 1 with an empty field)
That way you could add a button assignment wizard such as zsnes', that
does the same thing as described above but goes through all the SNES
controls in order (for one of the joypads?) without changing the basic
assignment system for the user.
Edit: I'd like to add a note on sensitivity. I think in all cases for
axes, bsnes should demand a change of 16384 or greater: for the normal
cases where the difference between 'centred' and 'maximum deflection'
is 32768 this is 50%, and for those PS3 controller buttons it would be
25%, which is also fine, since it's in the right direction; bsnes can
just 'round' up to 0 if it's still less than that when the event is
sent (or still more if it's reversed), and round up to 32768 (or 1) if
it's more than 17384. If you use normal integers this would be fine
during games, because bsnes would simply demand '> -17384' when if
it knew about the full range it would be '> 0'. Considering SDL was
fast enough to capture it the first time, requiring it knows about the
full range would just increase input latency in games. (I hope all of
that came out right, I have the idea in my head but explaining it is
taking more words than I'd hoped..)
As for labelling the axes, perhaps just an 'U' for anything that goes
up and a 'D' for anything that goes down? As long as the assignment
process is intuitive I don't think the user will care what the labels
say (I wouldn't, can never remember what number of button does what
anyway) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 02, 2008 11:58 am Post subject: |
|
Yeah,
I'll probably worry about the axis stuff later. I didn't intend to
spend a ton of time on adding SDL input support like this, to be
honest. Though I guess I should have known better with SDL and Linux.
Okay, new WIP with no Windows binary. There's really no reason to get
the WIP. The only change is renaming vai to ruby. That's right matz,
ruby. Deal.
Moved the folder to lib/ruby from ui/vai. The main point is trying to
make it easier to use for other applications. Instead of having each
app include all sorts of platform-specific header files and manually
create the objects at runtime, it's all done for you now. Just #include
<ruby/ruby.h>, call ruby::input.init(const char *driver = "") and
use it. So far, only the input driver has been ported in this way.
Note: if you use this WIP, you'll want to make sure system.input is set
to either "sdl"/Linux or "directinput"/Windows. It defaults to no
driver with "", for the time being.
Once I finish the video and audio drivers in the same manner, I'm
strongly considering eliminating the "multiple UI" bindings, as my
Win32/GTK+ wrapper is pretty much meant to wrap all possible interfaces
into one. This means it would be harder to create a standalone,
GUI-less SDL or VESA2/DOS only port in the future, for example. But I
really don't have any plans to do that anyway. So it's just needless
separation of components, really.
That extra separation layer was being blurred a lot recently anyway.
The config.cpp file was adding miu-specific GUI commands, where they
had to be to bind to interface.cpp, which binds to the core. Meh.
So basically, I'm wanting to change the structure from:
core <> abstracted UI <> miu, SDL, VESA2
to:
core <> miu
Even with this, porting to pure SDL would still be doable in the
future, you'd just have more code to write to do it.
Any objections? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Feb 02, 2008 12:21 pm Post subject: |
|
I
wouldn't mind having a look at the axis stuff if you'll PM me a link to
the WIP; main problem is I don't have a Linux box to test on so I'd be
doing the actual input stuff blind (but the functions themselves seem
straightforward). It would help to know which files to edit, of course,
as this involves the UI, the config file and input handling. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Feb 02, 2008 1:33 pm Post subject: |
|
byuu wrote: |
Any objections? |
Anything is better than re-using an already well-established name (even
a short acronym like "vai"), but that's just me.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Sat Feb 02, 2008 8:24 pm Post subject: |
|
quark?
_________________
Why yes, my shift key *IS* broken. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Feb 02, 2008 9:50 pm Post subject: |
|
Leave fermions out of this please.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Sun Feb 03, 2008 12:41 am Post subject: |
|
grinvader wrote: |
Leave fermions out of this please. |
Then how about mesons?
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Sun Feb 03, 2008 4:27 am Post subject: |
|
grinvader wrote: |
Leave fermions out of this please. |
*groan*
Did the other dragons have names? It's been too long; I can't remember.
_________________
Why yes, my shift key *IS* broken.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sun Feb 03, 2008 7:21 am Post subject: |
|
Name it Luna you tards.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Feb 03, 2008 9:26 am Post subject: |
|
Clements wrote: |
Bitches can't find mah Higgs boson |

Had to do it.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 03, 2008 10:12 am Post subject: |
|
Quote: |
Anything is better than re-using an already well-established name (even a short acronym like "vai"), but that's just me. |
I was asking about eliminating the extra layer of abstraction in the UI.
But since you brought it up ... I'm sure vai has been taken before.
Quark certainly has been. Hell, BSNES was taken by some people trying
to port ZSNES to BeOS (they gave up). Given, none of those have
anywhere near the popularity of the programming language. But eh, I really don't care. I like the name, and nobody else in the world is ever going to use any of my software libraries anyway, so I'll use it.
Speaking of which, I hate the name miu for the GUI library, it sounds stupid. So in the spirit of selecting totally random names that are certainly not associated with any licensed / trademarked / copyrighted proper nouns, especially not from any video games or somesuch; I've renamed miu to the completely arbitrary name of hiro. Boy, I'm so creative and original with naming.
---
That said, new WIP up, with Windows binary.
Windows users, be sure to set system.video to "direct3d", system.audio
to "directsound", system.input to "directinput".
Linux users, "opengl", "openal" and "sdl" are preferred. "xv", "ao" and "x" are safer fallbacks.
Changes:
- Finally found a problem with dots in folder names, it screws with GNU make. So foo.bar has been renamed foo_bar.
- Decided to drop the pointless duplications of folder names into file
names, such as miu.gtk/miu.gtk.button.cpp -> hiro_gtk/button.cpp.
Same for libco.
- ruby is completed, all 13 drivers are in the ruby namespace, and
bound to the base ruby.cpp file. The UI just calls
ruby::video.driver("name"); to select a driver. Before v028's release,
omitting the name will select the default best-case driver. ruby is no
longer dependent on anything besides nall (the template library, for
those losing track in the sea of arbitrary names.)
- miu became hiro, as mentioned above. Like ruby, I wanted to remove
the need for platform-specific tests inside the UI for it. There's now
a base hiro.cpp file that will auto-select the best implementation and
compile it. Just build hiro.cpp on whatever platform you want and it
does the rest.
- UI platform abstraction removed. src/ui/miu was moved to src/ui. The
two main.cpp files were merged into one. With the GUI wrapper and
hardware drivers moved out of this folder, it's quite orderly there now.
- More improvements to the Makefile system. New folder obj/ accumulates
all of the object files now. Added streq(al) and strn(ot)e(qual) to
Makefile.string library. Improved the delete command to support
deleting from either obj/*.$(obj) with rm, or obj\*.$(obj) with del.
bsnes executable is moved up one folder above src/ for both Windows and
Linux now. The batch file doesn't perform this copy anymore.
- Killed the doc/ folder. Just a pointless, out of date .dia file there anyway.
Future plans:
- I want to make ruby take advantage of nall/config.hpp, and output to
~/.bsnes/ruby.cfg. This file will contain driver-specific configuration
settings. I may or may not add editing support for them to the advanced
window. Or maybe I'll be lazy and just throw everything into bsnes.cfg.
- Really need to add automatic driver selection to ruby. Can't release it with "" defaulting to no driver.
- I'd like to replace the god-awful GTK+ video driver (that spawns a
new window) with SDL video. Yeah, I know. At least with SDL_WINDOWID
environment variable hack, it will go into the main window. I'll
probably make this the default driver on Linux, since ATI can't even
seem to get X-Video right with their drivers.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Feb 03, 2008 1:37 pm Post subject: |
|
*sad sigh* Alright, I'll just have to cope, I guess...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 5:28 am Post subject: |
|
Okay,
I was able to write the SDL video driver. Lucky me, you can just use
SDL_InitSubSystem to initialize each component by itself, without
needing to ever call SDL_Init.
Add to that a
little XGetWindowAttributes and undocumented SDL_SoftStretch magic, and
we have a fully-functional video driver.
And now the bad news, speed. At 1x, it gets roughly ~10% less speed
than the OpenGL driver. At 5x scale at the Zelda 3 load screen, I get
~22fps. The OpenGL driver gets ~110fps on the same screen.
But, the SDL driver should work anywhere. On ATI cards with their
broken GLX implementations. On ATI binary-blob drivers with their lack
of an X-Video extension. On ATI open-source drivers with their buggy
X-Video extension. Even on PS3s, with their total lack of any and all
video acceleration.
Given that, should I default the Linux port to the SDL video driver by
default? I figure it would make a better impression for a first-time
user to see bsnes running kind of slowly (hahah), than to see a black
window. They'd probably be more likely to look into ways to speed
things up, rather than to just assume it's broken and move on, right?
That would give:
Windows: direct3d + directsound + directinput
X11: sdl(video) + libao + sdl(input)
At any rate, the GTK+ renderer is now dead. Good riddance. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 7:04 am Post subject: |
|
byuu.org wrote: |
bsnes
v0.028 has been released. The major focus of this release was cleaning
up the code even more, and greatly enhancing the Linux port to be an
equal with the Windows port.
For Linux
users, please note that the safest drivers were chosen by default,
rather than the most full-featured drivers. The active driver can be
changed by editing
settings->configuration->advanced->system.(video, audio,
input), and then restarting bsnes. You can also edit the drivers by
hand, by editing ~/.bsnes/bsnes.cfg
Available Linux drivers are: video ("opengl", "xv", "sdl" (default)),
audio ("openal", "oss", "ao" (default)), input ("sdl" (default), "x").
In particular, the SDL video driver and libao audio driver are very
poor performers. The SDL video driver lacks hardware accelerated
scaling, and runs tremendously slow. The libao audio driver has
horrendous, ~150ms+ latency.
OpenGL is the best video driver, but it requires OpenGL graphics
libraries to be installed to use. These do not typically come with
open-source video drivers. The Xv driver will at least allow hardware
accelerated scaling, offering a tremendous speedup, but some ATI
drivers have poor (or even missing) X-Video implementations.
OpenAL is the best audio driver, but ALSA works very poorly with it.
OSS4 works far better with the OpenAL driver. The OSS driver has the
lowest latency (~15-20ms), but requires the most CPU power. It too has
problems when using the ALSA emulation layer.
While the SDL input driver is superior to the X driver (and is the
default), if your joypad fails to work correctly and prevents you from
mapping any keys (highly unlikely), you can always revert to the
keyboard-only X driver.
At any rate, I strongly encourage you to try out each driver and choose the ones that work best for you.
Changelog:
* OpenGL (with hardware filter mode support) and SDL video drivers added to Linux port
* OpenAL (with speed regulation disable support) and OSS audio drivers added to Linux port [Nach]
* SDL input driver (with joypad support) added to Linux port
* Emulator pause option added
* Added option to select behavior of bsnes when idle: allow input, ignore input or pause emulator
* Added support to remap common GUI actions to key/joypad presses on the "Input Configuration" screen
* bsnes will now clamp the video output size when it is larger than the screen resolution
* GUI library has been enhanced, and renamed to hiro
* Fullscreen mode now always centers video, rather than approximates
* Fullscreen mode now works correctly on Linux/Openbox
* Extra layer of abstraction in src/ui has been removed, as GUI lib unifies all ports anyway
* Video, audio and input drivers unified into standard library, named ruby
* All custom headers have been merged into a new template library, named nall
* Makefile rewritten, vastly improved. Allows quick toggling of compiled-in drivers
* Makefile: all object files now placed in /src/obj, binary placed in /
* libco greatly enhanced, no longer requires an assembler to build [byuu, blargg, Nach]
* libco SJLJ driver added; bsnes should now build on any Unix-derivative now (Solaris, OS X, PS3, etc) [Nach]
* Fixed register $213e.d4 PPU1 open bus behavior [zones]
* Windows port will not activate screensaver while bsnes is running [Nightcrawler]
* Visual C++ target no longer requires stdint.h
* And lots more -- mostly code refactoring related
|
FitzRoy, if you install the SDL and GTK+ 2.0 development libraries on
your PS3 (sadly, I don't know how you would go about doing this), then
you should be able to build and run bsnes now. You'll want to edit
src/Makefile, and look for the ruby = line for X11 (it's the first
one), and change it to just video.sdl input.sdl. If you want to install
more libraries or play around with getting sound support, you can try
adding audio.oss and audio.ao, but they may not work yet there.
[vEX] and belegdol, you're free to modify the Makefile as you see fit,
and add the bsnes program icon to the window for your ports if you like.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 04, 2008 7:49 am Post subject: |
|
Thanks, I'll see if I can figure out linux some time. The screensaver suppression appears to work fine for me in XP, btw. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Mon Feb 04, 2008 8:23 am Post subject: |
|
When
you say that the safest drivers should be chosen by default, does that
mean they should be showing up in their proper categories? In other
words, should system.video have "sdl" as its value, or should there be
no text in that input when you first compile? Because all three of
those categories (video, audio, input) were blank when I compiled this
release.
Congrats to you on another solid release,
byuu. I'm really enjoying all of the new features, and I just wanted to
let you know that using oss as my system.sound (which I assume means
I'm using the oss wrapper for alsa) with no video filters, the intro of
Chrono Trigger (the clock and the wavy text) played pretty much
flawlessly on my system. It was very joyous and most other games are running fullspeed for me in opengl, even with the scale2x filter on. So yay! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 9:49 am Post subject: |
|
For those on Ubuntu or Debian Linux who don't feel like building bsnes from source, be sure to try Derrick's repository, here:
http://repository.cinnamonpirate.com/
He compiled with PGO optimizations (compile the app with special flags,
run the app with a few games to build a profile, recompile it), which
gives a free ~10-15% speedup. Too bad PGO doesn't work with Visual C++
or MinGW :(
Derrick was telling me this build was ~20% slower than the last build.
That seemed crazy to me, as I get the exact same speed on both versions
(see 27 vs 28).
I tracked down what it was -- the SDL input driver has a hefty
performance penalty, about ~5-8%. If you don't have a gamepad, set the
driver to "x". Disabling audio also gives another ~5-10% speedup, but
takes away your ability to regulate speed. If you can't get 60fps
anyway, you probably don't care about that.
He
also confirmed that OpenGL doesn't work at all with ATI drivers -- any
of them. I'm sorry, I really don't know what the problem is. If anyone
can help, it'd be greatly appreciated. Most OpenGL apps create their
own window (mednafen, gens, ZSNES, Snes9x, gmplayer etc), but I have to
bind my GLX context to an existing window. I scan all available
VisualIDs, find a match, and set that. The API command to make it the
active context causes the app to crash violently, even though it
supposedly found a perfect match.
Quote: |
Thanks, I'll see if I can figure out linux some time. |
Thanks, no hurry.
Quote: |
When
you say that the safest drivers should be chosen by default, does that
mean they should be showing up in their proper categories? |
No, they should default to blank, or "".
Quote: |
I
just wanted to let you know that using oss as my system.sound (which I
assume means I'm using the oss wrapper for alsa) with no video filters,
the intro of Chrono Trigger (the clock and the wavy text) played pretty
much flawlessly on my system |
Excellent! Thanks, Nach! It must just be my Intel HDA that ALSA hates so dearly.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Feb 04, 2008 10:04 am Post subject: |
|
You're welcome everyone, enjoy the OSS support.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Feb 04, 2008 10:52 am Post subject: |
|
Any
chance we can have scanlines added back into the raster sliders? I
really miss those from bsnes, and I use them in every emulator I have
for other systems. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Feb 04, 2008 1:08 pm Post subject: |
|
byuu wrote: |
[vEX]
and belegdol, you're free to modify the Makefile as you see fit, and
add the bsnes program icon to the window for your ports if you like. |
Thanks! It looks so much nicer with the icon instead of a boring small white square.
EDIT: byuu, is there any reason to why you don't pass the -D flag to
the install commands, ie: "install -D -m755 ../bsnes
${prefix}/bin/bsnes"? That flag creates the directories (if they don't
exists) before installing the files. Yes, if you run make as an
ordinary user the directories probably already exist. But if you're
building a package it's probably being built in a sandbox environment
where you must create those. It's not really a pain to create the
directories manually before calling "make install", but it doesn't hurt
do add the flag I think. Unless the reason is that it doesn't work for
all supported operating systems.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Feb 04, 2008 4:28 pm Post subject: |
|
The windows binary is about 20% smaller. Is this the result of all the source cleanup?
I'll test the release on my laptop (Pentium M 1.6 GHz) later to see what kind of speed I can get.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 5:00 pm Post subject: |
|
Quote: |
EDIT: byuu, is there any reason to why you don't pass the -D flag to the install commands |
Didn't know it existed. I'll add it shortly, thanks.
Quote: |
The windows binary is about 20% smaller. Is this the result of all the source cleanup? |
Not really, v028 finally re-adds JMA support, making it even bigger.
The EXE is smaller because I stripped the debugging symbols before
using UPX this time. When zipped, the new version is actually ~80kb
larger than the old one. But I have a lousy ZIP program anyway, so I'm
told.
Quote: |
I'll test the release on my laptop (Pentium M 1.6 GHz) later to see what kind of speed I can get. |
~25-30fps, depending on the game =(
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Mon Feb 04, 2008 5:26 pm Post subject: |
|
byuu wrote: |
Quote: |
EDIT: byuu, is there any reason to why you don't pass the -D flag to the install commands |
Didn't know it existed. I'll add it shortly, thanks.
|
Yeah, it's pretty nice.
man install wrote: |
-D create all leading components of DEST except the last, then copy SOURCE to DEST |
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Lazarus New Member
Joined: 29 Aug 2006
Posts: 8
|
Posted: Mon Feb 04, 2008 5:48 pm Post subject: |
|
Quote: |
Quote: |
I'll test the release on my laptop (Pentium M 1.6 GHz) later to see what kind of speed I can get. |
~25-30fps, depending on the game =(
|
On my Debian Sid running Intel Celery 1.73 GHz lowly Acer Travelmate
laptop I get a steady 60~65 f/s in most games (OpenGL video is the only
config setting I changed (which seems to make only a slight
difference)). I'm using the precombiled binary deb from the repo you
linked to.
This is the first time I'm attempting to run bsnes (expected it too be
slower). Only the sound stutters noticeably (turning frameskip on fixes
it in most cases). All in all, very nice!
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Mon Feb 04, 2008 5:59 pm Post subject: |
|
Way to go with v0.28, Byuu! This version has a noticeable speed boost (I've tried out 4x video, and still runs 60fps!) Congrats!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 04, 2008 6:57 pm Post subject: |
|
FirebrandX wrote: |
Any
chance we can have scanlines added back into the raster sliders? I
really miss those from bsnes, and I use them in every emulator I have
for other systems. |
So does everyone think this should go on the unsupported list?
Scanlines = removal of image information to imitate CRT television
output. Desirable? More trouble than it's worth? Maybe we should have a
feature that imitates the corner warping that my flat screen CRT
exhibited, or a pincushion feature, or a screen of static when a rom
isn't loaded, or a high pitched squeeling sound that many people claim
not to hear. I mean we could go all day with this 'recreating CRT
nostalgia' stuff. We already have a filter that adds color bleed and analog noise, god help us.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 04, 2008 7:06 pm Post subject: |
|
Scanlines should be very easy to do in a fragment shader.. how do things stand there, now that OpenGL support has been added? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Feb 04, 2008 7:17 pm Post subject: |
|
byuu wrote: |
Quote: |
I'll test the release on my laptop (Pentium M 1.6 GHz) later to see what kind of speed I can get. |
~25-30fps, depending on the game =(
|
I actually get ~30fps on SMW with my Atholon 1.1 GHz.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 7:53 pm Post subject: |
|
Quote: |
On my Debian Sid running Intel Celery 1.73 GHz lowly Acer Travelmate laptop I get a steady 60~65 f/s in most games |
Wow. My Pentium IV 1.4GHz Pentium IV gets less than half that.
Shouldn't be too surprised, the initial P4 line was quite awful.
Quote: |
Any chance we can have scanlines added back into the raster sliders? |
Quote: |
So does everyone think this should go on the unsupported list? |
The problem with scanlines is that the old support was a Direct3D
texture trick. That obviously only works with one specific video driver
(of six), and even then only on Windows. And even then,
it doesn't work with the StretchRect trick (which does not perform
alpha blending), which otherwise adds a very noticeable speedup.
The only way to make it portable would be to implement it in software.
And doubling video bandwidth and the extra filter level would add
tremendous overhead.
Plus, at this point, src/snes is probably the least organized of all
code in bsnes. Especially the video filtering code. That class was
initially supposed to be the abstraction layer between the core and the
UI, but as it were, I still needed a core component to organize and
handle all the individual chips. So, first thing would be reorganizing
that class. Move the audio logging and video filters out to be
performed in the UI. After that, we could consider some sort of
piggybacking system to generate software scanlines.
Not looking forward to that, but on the bright side, virtually all of
the rest of the code has already been refactored, excepting some minor
touchups needed in src/cart and src/reader. And once that's done, I can
start speeding up compilation by not including headers for the entire
project in each core object file. Overall, I'm really feeling a lot
more confident about the quality of the code as a whole now.
Quote: |
We already have a filter that adds color bleed and analog noise, god help us. |
Well, it's novel. I don't really use it much myself. I'm partial to
HQ2x these days, though it tends to look bad on really detailed backgrounds ...
Quote: |
Scanlines should be very easy to do in a fragment shader.. how do things stand there, now that OpenGL support has been added? |
I don't have the first idea how to implement GLSL shaders. If anyone
makes a diff against the code in bsnes, I'll be happy to add them.
Hell, I'll even port the GL code to wgl/Windows, and use it as the
default driver for all ports -- allow an optional slot for user-defined
filters. Start distributing bsnes with a bunch of built-in filters for
HW acceleration, assuming GPL licensing isn't an issue with that
(shouldn't be, code is not compiled into the emulator). That would be
really nice.
Honestly, if the NTSC filter had a GLSL implementation, and someone
found out what the hell is wrong with ATI's GLX implementation, I'd
drop the software filters all together. That would certainly be nice.
I may pass off a lot of programming issues as not my fault, but the GLX
code is only four commands, and the app flat out crashes hard rather
than returning an error as it's supposed to. There's no way in hell
this one is my fault, and now I'm probably going to have to end up
purchasing an ATI video card (eg a $50 paperweight) to fix it.
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Mon Feb 04, 2008 8:41 pm Post subject: |
|
How about "rubi" instead of "ruby"?
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 04, 2008 8:54 pm Post subject: |
|
byuu wrote: |
Well,
it's novel. I don't really use it much myself. I'm partial to HQ2x
these days, though it tends to look bad on really detailed backgrounds
... |
At least HQ2X attempts to do something though which might be considered
desirable on an aesthetic level rather than a nostalgic one. You know,
whether it's one of the blur modes, or HQ2X, the intent is to make the
image seem like a higher resolution than it really is by eliminating
definition between or assuming curves at angles defined by blocks. Of
course, that's impossible technically and results in artifacts or
issues that many would consider even more distracting than low-res. But
at least there's a motive there other than just to destroy the image to
make it look it did on a crappy tv I had back in the 90s. Are PS3
emulators in the future going to have screendoor, backlight bleed, and
dead pixel filters for all the people who want to relive the glory days
of LCD?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 9:15 pm Post subject: |
|
Quote: |
How about "rubi" instead of "ruby"? |
Well, Rubi is certainly more attractive than Ruby (though Aerdan and Rydian would probably disagree), so I guess that's fine. But I really did want to keep the obvious coincidental connection between the various library names that does not exist for legal reasons.
Quote: |
Are
PS3 emulators in the future going to have screendoor, backlight bleed,
and dead pixel filters for all the people who want to relive the glory
days of LCD? |
Oh, god yes! Dead pixel filter! I demand this feature right now!! Oh, and I want dead subpixel support, too.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Feb 04, 2008 9:38 pm Post subject: |
|
Fritzroy,
I disagree with your assessment of scanlines. First of all, to me and
many others, it makes the image look better than a pure pixel output
image. A pure snes image looks incredibly blocky, while the scanline
effect actually makes the image look higher res. Granted I don't like
full scanlines, only about 25% as I do in ZSNES and other emulators.
Also, image is not "taken away" as you put it, because you still see
every line of resolution, just with less "blockyness" and it looks much
better in my opinion. Here's a Genesis example below taken for Kega:
To me, scanlines below:

look better than blocky pure output:

Now I understand its merely a matter of preference from one individual
to the other, but you don't see me calling for removal of all the HQx2
and supersai filters because I see them as destroying the original
image, so please give me the same courtesy. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Feb 04, 2008 9:45 pm Post subject: |
|
FitzRoy wrote: |
I mean we could go all day with this 'recreating CRT nostalgia' stuff. We already have a filter that adds color bleed and analog noise, god help us. |
I'm not sure about the SNES, but I believe there are some games for the
NES that require NTSC colour-bleeding to appear as intended. Likewise,
there are games for the original Gameboy that use that system's
famously blurry screen to simulate transparency (which you might call
"hardware transparency support" if you were perverse enough). The
pixels in the framebuffer are not always exactly what the game author
intended you to see.
If you have 'video output features a game might rely on' as a feature
criterion, then the NTSC filter should be included, but "artificial
scanlines" and "20KHz hum" probably shouldn't.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Feb 04, 2008 9:48 pm Post subject: |
|
Interpolation FTW!
_________________
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 Feb 04, 2008 9:58 pm Post subject: |
|
Quote: |
Now
I understand its merely a matter of preference from one individual to
the other, but you don't see me calling for removal of all the HQx2 and
supersai filters because I see them as destroying the original image,
so please give me the same courtesy. |
I'm not trying to be discourteous, I'm just trying to get a rational
basis for scanlines. It's no use turning the argument from an objective
one to a subjective one. There might be someone out there who wants a
transparent image of a chicken behind the game. There might be someone
out there who wants to reproduce any of the aforementioned
technological shortcomings, so what distinguishes this from theirs?
What makes scanlines more worthy other than the fact that you
personally like them? HQ2X has already been explained and is not a
simulation of any display technology. We need to know how darkening
every other horizontal line sets out to improve the image.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Feb 04, 2008 10:17 pm Post subject: |
|
Quote: |
I
don't have the first idea how to implement GLSL shaders. If anyone
makes a diff against the code in bsnes, I'll be happy to add them.
Hell, I'll even port the GL code to wgl/Windows, and use it as the
default driver for all ports -- allow an optional slot for user-defined
filters. Start distributing bsnes with a bunch of built-in filters for
HW acceleration, assuming GPL licensing isn't an issue with that
(shouldn't be, code is not compiled into the emulator). That would be
really nice.
|
GLSL shaders can be implemented by just post-processing the current
texture. I've worked with shaders before, so if the GLX code can be
ported to Windows completely, I might look into adding shader support.
Implementing them is simple enough. The problem is, if it will even
work with the current GLX implementation tho...Which was one of the
issues when I added them to VBA-M (removed them since I lost the
working code from the first test build with them).
Last edited by mudlord on Mon Feb 04, 2008 10:18 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 04, 2008 10:18 pm Post subject: |
|
Quote: |
We need to know how darkening every other horizontal line sets out to improve the image. |
Well for one, it causes each scanline to appear somewhat different,
thus it visually appears to reduce blockiness by a small amount. But
it's really just an optical illusion. I think it has more to do with
simulating how the image looked on CRT televisions of the time. For
instance, you never see anyone arguing for horizontal scanline support,
even though it provides the same effect.
Of course, if blockiness is your main objection, then a higher quality
video scaling filter would probably be preferable. However, D3D and
OpenGL only support point and linear sampling. That means we'd have to
rely on software. Cubic would be higher quality, and gaussian or
lanczos window sine would be the highest. But then, try the SDL video
driver at 5x scale. The software scaling and transfer alone cap bsnes'
speed from ~120fps to ~20fps. Add to that a high-end interpolation
algorithm and you're just asking for a world of pain. This stuff really
needs to be done on the video card hardware. There's probably a few GL
shaders out there for this.
Anyway, I have a screenshot at home I grabbed from a random BBS. I've
been wanting a software implementation of it in bsnes for ages, but I
don't know what exactly the filter is. I'll post the screenshot later
tonight or tomorrow to see if anyone knows. It's really impressive
looking.
Quote: |
The problem is, if it will even work with the current GLX implementation tho... |
Is GLSL implemented using standard gl* commands, or with wgl* commands?
If the latter, then I suspect we will have a lot of problems
implementing it on Linux. You might be able to talk me into using glu*
commands, but definitely not glut* commands.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Feb 04, 2008 10:37 pm Post subject: |
|
Quote: |
Is GLSL implemented using standard gl* commands
|
Depends on how you use the shaders. I seen in most cases GLUT &
GLEW are used to handle shader linkage and compilation. But, it is
possible to do shaders normally without that crap:
Code: |
void SetupGLSLProcs()
{
glCreateProgramObjectARB = (PFNGLCREATEPROGRAMOBJECTARBPROC)
glXGetProcAddress("glCreateProgramObjectARB");
glCreateShaderObjectARB = (PFNGLCREATESHADEROBJECTARBPROC)
glXGetProcAddress("glCreateShaderObjectARB");
glShaderSourceARB = (PFNGLSHADERSOURCEARBPROC)
glXGetProcAddress("glShaderSourceARB");
glCompileShaderARB = (PFNGLCOMPILESHADERARBPROC)
glXGetProcAddress("glCompileShaderARB");
glGetObjectParameterivARB = (PFNGLGETOBJECTPARAMETERIVARBPROC)
glXGetProcAddress("glGetObjectParameterivARB");
glAttachObjectARB = (PFNGLATTACHOBJECTARBPROC)
glXGetProcAddress("glAttachObjectARB");
glGetInfoLogARB = (PFNGLGETINFOLOGARBPROC)
glXGetProcAddress("glGetInfoLogARB");
glLinkProgramARB = (PFNGLLINKPROGRAMARBPROC)
glXGetProcAddress("glLinkProgramARB");
glUseProgramObjectARB = (PFNGLUSEPROGRAMOBJECTARBPROC)
glXGetProcAddress("glUseProgramObjectARB");
glGetUniformLocationARB = (PFNGLGETUNIFORMLOCATIONARBPROC)
glXGetProcAddress("glGetUniformLocationARB");
glUniform1f = (PFNGLUNIFORM1FARBPROC)
glXGetProcAddress("glUniform1fARB");
}
|
That should set up shader code in Linux, providing you declare the
function pointers, too. All the rest is code that can swappable from
Linux, Mac, Windows, whatever, since you might only need glext.h. GLUT
and GLEW are only to make things easier.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Feb 04, 2008 10:48 pm Post subject: |
|
Just
want to add that I've tried and do not like ANY other filters on my
output image other than scanlines. Interpolation, dotbleed, HQXX, Sai,
etc. all just don't float my boat. Maybe its because I have fond
memories of playing the real thing, but I do recall at that time
wishing I could play the games via RGB instead of crappy RF signal or
composite, so I know its not purely a nostalgia thing.
Also, you guys should probably consider that many of these games
feature artwork that was specifically designed to look good on a CRT,
hence why many of them look better with scanlines (at least to some of
us). |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Feb 04, 2008 11:59 pm Post subject: |
|
Quote: |
I'm
not trying to be discourteous, I'm just trying to get a rational basis
for scanlines. It's no use turning the argument from an objective one
to a subjective one. [...] What makes scanlines more worthy other than
the fact that you personally like them? HQ2X has already been explained
and is not a simulation of any display technology. We need to know how
darkening every other horizontal line sets out to improve the image. |
Good summay, but a question about scanlines? A TV has them, so it's a simulation of display technology.
Emulator features can be divided into two categories: features which
make it less like the emulated system but more enjoyable to some users,
and features which make it more like the emulated system. The former is
based on the taste of individual users, while the latter is mostly
objective. The subjective part of accuracy is deciding which aspects
are more important to spend time improving, or which ones are most
perceptible.
Most systems output a video signal that a TV had to decode, so there is
a question of whether to emulate the TV as well, or to display an
idealized version of the pixels inside the system, before they are sent
to the video encoding system. Virtually all emulators support the
idealized display, since it's simple and efficient. The NTSC composite
filter and scanline darkening are both aspects of the video
encoding/decoding/display system, and make a noticeable improvement in
accuracy in this area. The argument for their inclusion doesn't even
need to cover the intent of the game developers; all that matters is
that the TVs most people played on had these characteristics, so
reproduction of that experience requires that they be emulated. The
main things different about the TV image are
- Non-square pixels (on SNES; some consoles probably do have square pixels)
- Blurred edges
- Scanlines, which makes for rounder corners of objects
- Reduced chroma resolution, which causes hue changes to be more gradual
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 05, 2008 12:09 am Post subject: |
|
Here's
an example of a higher quality filter. I don't know how much it helps
3D compared to 2D, but.. Other than that I've worked on a 2xSaI/HQ4x
alternative for a while, but that really is a mammoth task. If I ever
get anywhere, I doubt as a GLSL it'll be useable on anything but
upcoming generations of cards. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 05, 2008 12:28 am Post subject: |
|
Sigh, now I remember why I've avoided touching the SNES video filters for so long. The whole system is a convoluted mess.
Basically, hires can be toggled on each and every scanline. This
changes the scanline width between 256 and 512 pixels wide. Interlace
can also be toggled, but thankfully it does not actually take effect
until the next field / frame (hard to say which.)
We can't just draw at 512 always, this will ruin HQ2x and Scale2x on
99% of games that are lores. We can't just always upscale to 512 on
mixed-resolution games, such as SD3's textbox. This will cause the
filtering to vanish when textboxes appear, and reappear when the
textboxes go away. Nasty.
So, we basically have to keep a list of line lengths in a table. The
filter has to look at the width of each line and separate them into
"blocks", and then filter each block by itself.
There's no way to write a standardized filtering library applicable to
any emulator based on such a bastardized approach. There would need to
be an SNES-specific layer that separates out each block (separated
where the line width changes) and reconstruct the image from each
block. Not too difficult, at least.
Next is the issue of where to render to. Right now, bsnes renders the
image internally to a RAM buffer in the PPU. I have no choice, due to
the fact that we don't know how wide future line lengths will be. After
that, it runs the filter that transfers that data to the video card
memory. Direct copy is the simplest, it just normalizes the line widths
(eg if there is a 512-width line, double all 256-width lines.)
Next, typically it's good to have the library user tell the library the
requested output size of video. But filters like HQ2x, Scale2x and NTSC
dictate their own output sizes. I have to be very careful to make sure
all output blocks are of the same width, which means the library user
will be forced to be aware of the the innards of each and every filter
supported in the filter library itself.
So, to get this right, I'm going to have to:
A) output the PPU image to a temporary buffer with a list of line widths in the core
B) have to core signal the UI that a refresh is needed, and give it
pointers to the video data, screen height, list of line widths and the
max line width value
C) have the UI call a special block sorting algorithm that will break
the image into logical chunks and pass each one on to the appropriate
filter. The UI will have to keep track of what filter it uses and swap
out different ones to guarantee the final image output size is
consistent
D) perform post-processing effects (scanlines, etc)
E) blit this final resulting image to the screen
C can at least be optimized to not need multiple buffers by using pointer arithmetic.
In the worst case scenario, a game that changes widths every single
scanline, it will only be viewable by using filters that do not take Y
into account (eg direct and NTSC filters) -- they will be hopelessly
broken in those that do (HQ2x and Scale2x.) Note that 100% of actual
SNES games should be fine, as they only change widths once or twice per
frame. The distortion should be minimal (~2-4 lines of half-luma
pixels.)
So then, the strategy:
Core -> UI (hiro) -> Custom SNES-specific block filter -> {
Filter, Filter, ... } (libfilter) -> Video HW interface (ruby) ->
Screen
Note that the core just passes pointers that are passed on through the
UI to the block filter. No significant performance penalty to do that
~60x a second.
I'll be writing libfilter (no video game names!) to handle video and
audio filtering. It'll probably be forced to be LGPL due to using other
people's libraries in it, sadly. And it will be one single object file.
Not going to break down ~80kb of code into fifteen unique object files.
Planning to start working my way backwards, by writing libfilter first.
I'll make a small test app that loads a bitmap, filters it and blits it
to the screen.
I'll add attributes to the video filters to indicate what they are
capable of (arbitrary sizing vs fixed sizing, bit depths supported,
etc), and a query function to determine "if I give you an image of size
XxY, what image size will you return?" so that the block filter doesn't
have to special case each driver by hand.
This shouldn't affect speed at all, but we all know by now that that's
never the case. It'll somehow end up being ~3-5% slower, guaranteed :)
Any suggestions, concerns or ideas for improvement?
Quote: |
Here's an example of a higher quality filter. |
Hah, like hell he implemented HQ4x in ~30 lines of code. That's clearly
his own, much lower quality implementation. What's with these authors
and choosing names of existing products lately? Geez ...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 05, 2008 3:58 am Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
Well,
it's novel. I don't really use it much myself. I'm partial to HQ2x
these days, though it tends to look bad on really detailed backgrounds
... |
At least HQ2X attempts to do something though which might be considered
desirable on an aesthetic level rather than a nostalgic one. You know,
whether it's one of the blur modes, or HQ2X, the intent is to make the
image seem like a higher resolution than it really is by eliminating
definition between or assuming curves at angles defined by blocks. Of
course, that's impossible technically and results in artifacts or
issues that many would consider even more distracting than low-res. But
at least there's a motive there other than just to destroy the image to
make it look it did on a crappy tv I had back in the 90s. Are PS3
emulators in the future going to have screendoor, backlight bleed, and
dead pixel filters for all the people who want to relive the glory days
of LCD?
|
Your entitled to your opinion but to proclaim the feature as outright
stupid and 'therefore' as not being worthy of being added (or re-added)
is a bit arrogant. Besides, afaik it was removed in the first place
because of code base changes...not because byuu deemed it stupid or
useless
You could make the same argument the other way around and say viewing
graphics that were designed with old tv in minds on ultra high
resolutions is just a silly and ugly as viewing your latest PS3/360
games on a crappy old tv. I don't think it's an "upgrade" to be able to count the number of pixels on Mario
I agree with FirebrandX on this; old consoles gfx looks better on old
tv resolutions (and newer games and recent tvs)
The difference here is I don't have problems if someone DO want to play
in pure unfiltered gfx, and I don't go telling others that really,
scanlines should be mandatory because playing otherwise is pure
stupidity (nor do I think it is)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 05, 2008 5:57 am Post subject: |
|
blargg wrote: |
features which make it less like the emulated system but more enjoyable
to some users, and features which make it more like the emulated system.
|
I guess I question correlating accuracy to the limited types of output
available on a system. The SNES had various kinds of "accuracy"
depending on the model: s-video, scart, composite, and RF. It makes
more sense to me that when you emulate a system on a PC, the video card
and the display to which it is sending information should determine
what anomalies are introduced to the image. I could probably hook up my
computer to an old tv via the composite output of my video card and get
all of the effects you're trying to simulate internally. So without
software filters, is bsnes really less accurate when I can still output
to the device you're trying to simulate?
Quote: |
Your
entitled to your opinion but to proclaim the feature as outright stupid
and 'therefore' as not being worthy of being added (or re-added) is a
bit arrogant. Besides, afaik it was removed in the first place because
of code base changes...not because byuu deemed it stupid or useless |
Correct me if I'm wrong, but I never used such rhetoric, nor did I
question its worth on the basis of me just thinking it's stupid. This
argument is trying to be objective, you and Firebrand are the ones who
are inserting subjectivity as your defense. It's been said before,
personally wanting something is not reason enough to add a feature.
Where are my chickens, I tell you? You have to draw the line somewhere.
I don't even use HQ2x or Scale, but I defended them. At the very least,
it should be nice to have someone who is going to make you think a
little even if I'm ultimately wrong.
Last edited by FitzRoy on Tue Feb 05, 2008 6:13 am; edited 1 time in total
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Feb 05, 2008 6:06 am Post subject: |
|
Snark wrote: |
I agree with FirebrandX on this; old consoles gfx looks better on old
tv resolutions (and newer games and recent tvs)
The difference here is I don't have problems if someone DO want to play
in pure unfiltered gfx, and I don't go telling others that really,
scanlines should be mandatory because playing otherwise is pure
stupidity (nor do I think it is) |
Neither do I. I never went around telling others scanlines should be
mandatory, but when Fritzroy talked trash on the concept of them, I
felt I needed to make a defense rebuttle and also an example of his
argument.
Basically I was letting byuu know I really appreciated the scanline
feature and was hoping to see it return to bsnes at some point, and
that's when I got the "scanlines are retarded" lashing.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Feb 05, 2008 6:19 am Post subject: |
|
FirebrandX wrote: |
Now
I understand its merely a matter of preference from one individual to
the other, but you don't see me calling for removal of all the HQx2 and
supersai filters because I see them as destroying the original image,
so please give me the same courtesy. |
Amen, brother!
FitzRoy wrote: |
I'm not trying to be discourteous, I'm just trying to get a rational basis for scanlines. |
Precedent? Many emulators implement them, many users prefer to use them and have something of an expectation of them.
To some extent, if there is enough users requesting a certain feature
for ANY program, the developer will have some incentive to add that
feature, in order to satisfy his user base. Obviously the developer
should think about the best way to implement the requested feature so
that the configuration dialog isn't some 10-tab 1000-checkbox
monstrosity.
blargg wrote: |
The
NTSC composite filter and scanline darkening are both aspects of the
video encoding/decoding/display system, and make a noticeable
improvement in accuracy in this area. |
When
considering how an SNES image was decoded and displayed, shouldn't we
consider all possibilities? What I'm talking about is that an SNES can
output (using official Nintendo cables) via RF, composite, or S-Video.
Which of these does NTSC simulate (RF I assume)? When an SNES is used
with some digital display (LCD/plasma/whatever), is the image close
enough to the "internal/ideal" image that we don't need to compensate
for these digital displays? Obviously the vast majority of televisions
used during the SNES' time were 4:3 CRT televisions (and also PAL
televisions), so that's definitely what we should be compensating the
most for.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 05, 2008 6:20 am Post subject: |
|
FirebrandX wrote: |
when Fritzroy talked trash on the concept of them |
Oh, brother... I give up, just add them. It's not worth getting demonized in what is apparently holy territory.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 05, 2008 6:49 am Post subject: |
|
byuu wrote: |
Hah,
like hell he implemented HQ4x in ~30 lines of code. That's clearly his
own, much lower quality implementation. What's with these authors and
choosing names of existing products lately? Geez ... |
He didn't call it HQ4x, did he? It just works best on 4x the resolution or more. Not a clue what I'd call my filter if I got it done, might be VG4x 
As for GLSL shaders, fragment shaders operate on a per-pixel basis
(I've never understood vertex shaders so I won't touch those). So to
them it only matters that they get the right information if they query
a pixel on a row above or below them.. you could create two textures,
one where all the lines are 256 pixels wide that takes the averages of
lines that were supposed to be twice that, and one that's 512 pixels
wide and doubles the pixels on lines that were half that. Then either
switch between those mid-frame (if OpenGL allows that), provide them as
textures 0 and 1 with some variable saying 'this pixel is on a line ...
pixels long', or put both textures next to each other in the same
bitmap and change the coordinates in accord with that.
Hope all of that was coherent, as I'm a bit rushed Good luck!
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Feb 05, 2008 7:34 am Post subject: |
|
byuu wrote: |
Quote: |
Are
PS3 emulators in the future going to have screendoor, backlight bleed,
and dead pixel filters for all the people who want to relive the glory
days of LCD? |
Oh, god yes! Dead pixel filter! I demand this feature right now!! Oh, and I want dead subpixel support, too.
|
Not until I get flashing screen support for my NES emus! And random graphics corruption!
Thristian wrote: |
FitzRoy wrote: |
I mean we could go all day with this 'recreating CRT nostalgia' stuff. We already have a filter that adds color bleed and analog noise, god help us. |
I'm not sure about the SNES, but I believe there are some games for the
NES that require NTSC colour-bleeding to appear as intended.
|
I've seen that noted on some threads about the RGB mod before.
It makes certain games look a LOT duller.
(It also breaks some effects in a few games due to differences in
behavior between the composite nad RGB PPUs, but that's a different
issue entirely).
Quote: |
Likewise,
there are games for the original Gameboy that use that system's
famously blurry screen to simulate transparency (which you might call
"hardware transparency support" if you were perverse enough). |
Game Gear as well.
Quote: |
The pixels in the framebuffer are not always exactly what the game author intended you to see. |
As another famous example: Damn near everything before the Dreamcast has non-square pixels.
Quote: |
If
you have 'video output features a game might rely on' as a feature
criterion, then the NTSC filter should be included, but "artificial
scanlines" and "20KHz hum" probably shouldn't. |
Heh, that reminds me of the Asteroids GL emulator.
Aside from all the tricks it uses to make the display LOOK like a real
vector screen, it ALSO features options to emulate audio interference
from the power supply and flyback transformer, with independent
user-defined levels for each.
All in the name of accurate emulation of the original machine, which
often had one or the other to some degree(the graphics tweaks are ALSO
user-adjustable, partially in the name of simulating the game as one
specific end-user may've played it instead of choosing one specific
Asteroids cab as an "ideal" and forcing everyone to use that model).
Now, I'll admit... I DO turn on the flyback noise.
I grew up on the Vectrex buzz. It seems right for a vector game to do
that. (Similarly, my AstGL is tweaked to resemble a Vectrex. I've only
ever seen a single Asterodis cab in my life.)
By the same token, most raster console/arcade games look "right" with scanlines.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Feb 05, 2008 9:46 am Post subject: |
|
wow
byuu, sounds like a lot of work for video stuff but such is life. I
like using filters sometimes but I'd be just as happy if bsnes didn't
have any if it made your job easier
FitzRoy wrote: |
blargg wrote: |
features which make it less like the emulated system but more enjoyable
to some users, and features which make it more like the emulated system.
|
I guess I question correlating accuracy to the limited types of output
available on a system. The SNES had various kinds of "accuracy"
depending on the model: s-video, scart, composite, and RF. It makes
more sense to me that when you emulate a system on a PC, the video card
and the display to which it is sending information should determine
what anomalies are introduced to the image. I could probably hook up my
computer to an old tv via the composite output of my video card and get
all of the effects you're trying to simulate internally. So without
software filters, is bsnes really less accurate when I can still output
to the device you're trying to simulate?
|
you're right, but much like many people don't have SNESs soon many
people will not have their oldschool tvs, or at least not readily
available to hook up to their PC. now I don't mind if bsnes doesn't
have any video filters, but think of it this way, on top of emulating
the snes, filters like the NTSC filter is KINDA like emulating the tv
along with the snes.
I mean you say well you could just hook your PC with bsnes up to an old
tv but if we want to be that way about it we could just go hook up an
snes to an old tv, problem solved right not quite.
surely you can see both sides to the coin, but I think first comes the
stuff byuu was talking about, and then later work out the details with
filters.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Feb 05, 2008 11:51 am Post subject: |
|
FitzRoy wrote: |
blargg wrote: |
features which make it less like the emulated system but more enjoyable
to some users, and features which make it more like the emulated system.
|
I guess I question correlating accuracy to the limited types of output
available on a system. The SNES had various kinds of "accuracy"
depending on the model: s-video, scart, composite, and RF. It makes
more sense to me that when you emulate a system on a PC, the video card
and the display to which it is sending information should determine
what anomalies are introduced to the image. I could probably hook up my
computer to an old tv via the composite output of my video card and get
all of the effects you're trying to simulate internally. So without
software filters, is bsnes really less accurate when I can still output
to the device you're trying to simulate?
Quote: |
Your
entitled to your opinion but to proclaim the feature as outright stupid
and 'therefore' as not being worthy of being added (or re-added) is a
bit arrogant. Besides, afaik it was removed in the first place because
of code base changes...not because byuu deemed it stupid or useless |
Correct me if I'm wrong, but I never used such rhetoric, nor did I
question its worth on the basis of me just thinking it's stupid. This
argument is trying to be objective, you and Firebrand are the ones who
are inserting subjectivity as your defense. It's been said before,
personally wanting something is not reason enough to add a feature.
Where are my chickens, I tell you? You have to draw the line somewhere.
|
One would assume you draw them horizontally, at a regular interval.
Seriously, you're just as subjective on this issue as FirebrandX and I.
Scanlines have been around in many emulators since a long time ago.
Hardly a fringe demography feature imo
Now for the "objective" part is that it does (in part) make the image
closer to a typical older CRT TV. Nothing more, nothing less. You
question the very reason why anyone want to do that. Fine. But that's
an opinion. The rest is down to the users preference.
And no: I don't want dead pixel support. I don't want a TV burn-in
image in the background...I don't want to...have the CRT TV radiations
or anything like that.
For the record I'm not for any and every features. I just think scanlines are 1) decently popular and not marginal and 2) fall in the " reasonably sane feature" realm.
Quote: |
I
don't even use HQ2x or Scale, but I defended them. At the very least,
it should be nice to have someone who is going to make you think a
little even if I'm ultimately wrong. |
Well I think we've explained the (subjective) "rationale" behind it. As
others could explain their rationale for using "image-enhancement" type
filters like HQ2x even if I don't use them.
edit: someone over the psX board discussing whether people would be
partial to a NTSC filter for the psXemu. Indeed, psX games do NOT
appear that pixellated on older TV sets:
http://psxemulator.proboards54.com/index.cgi?board=feedback&action=display&thread=1173508168&page=1
http://xs220.xs.to/xs220/07406/psxemulator113.jpg
Last edited by Snark on Tue Feb 05, 2008 8:33 pm; edited 4 times in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 05, 2008 12:10 pm Post subject: |
|
FitzRoy wrote: |
I
guess I question correlating accuracy to the limited types of output
available on a system. The SNES had various kinds of "accuracy"
depending on the model: s-video, scart, composite, and RF. |
Yes, it would be limiting if an emulator supported only one output
type. I believe bsnes for example supports all of the above.
FitzRoy wrote: |
It
makes more sense to me that when you emulate a system on a PC, the
video card and the display to which it is sending information should
determine what anomalies are introduced to the image. |
No SNES had the output quality your PC's composite video out. The PC
card will use the proper color phase shift, and likely interlace the
signal and apply a flicker reduction filter. If you want the image of
S-Video or RGB, then a PC connected to a TV via S-Video or RGB will be
very similar.
There's no question that the video encoding hardware on the SNES is
part of the system, but I guess you could argue that the TV was not
part of the SNES, so an emulator with a composite video filter would
really be a "SNES+TV emulator". So be it. On the other hand, without a
video decoder, you had no image, not even the idealized pixel one.
Games were mostly played on TVs with RF or composite video, so the
appearance was effectively part of the game. In this sense emulating
the TV is more part of a "SNES game
emulator", since if the SNES were just a teletype terminal system with
artifacts on the text, those artifacts would be a much less important
aspect of preservation.
FitzRoy wrote: |
I
could probably hook up my computer to an old tv via the composite
output of my video card and get all of the effects you're trying to
simulate internally. So without software filters, is bsnes really less
accurate when I can still output to the device you're trying to
simulate? |
Your PC's composite video will be clearer than what the SNES outputs,
like the Wii's virtual console. The differences in the SNES video
encoder really does make a difference. For S-Video and RGB, it'll
probably look the same if your PC can output the non-standard progressive (non-interlaced) video the SNES did.
Jipcy wrote: |
FitzRoy wrote: |
I'm not trying to be discourteous, I'm just trying to get a rational basis for scanlines. |
Precedent? Many emulators implement them, many users prefer to use them
and have something of an expectation of them. To some extent, if there
is enough users requesting a certain feature for ANY program, the
developer will have some incentive to add that feature, in order to
satisfy his user base.
|
FitzRoy wanted to come up with reasons for a feature that were relevant
to SNES emulation, as opposed to simply because users wanted them. This
is a useful activity since it allows features to be separated into
those that make the emulator more accurate, and those that simply
please some users. Someone using the emulator might want to first focus
on accuracy-oriented features if his goal is to study how a SNES
behaved. But like Jipcy says, the ultimate reason any features are
there, including accuracy-oriented ones, is because users want them.
For example assigning keyboard keys was never present on the SNES, but
most users want that ability in an emulator.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 05, 2008 2:12 pm Post subject: |
|
I
bought a cheap $25 ATI Radeon X600SE to try and get the OpenGL renderer
working there. Working with fglrx, the radeon driver runs like shit for
me. fglrx isn't much better. No X-Video support whatsoever?! Ugh.
Spec wise, I get 1,400 fps in glxgears, compared to 11,500 fps on my
nVidia card. Course, the nVidia card cost a bit more.
Anyway, it looks like the problem with my GLX implementation is that
ATI implements literally half of the GLX 1.3 spec. You know, the 1.3
spec that came out at least eight fucking years ago?!
Yeah, that one. The other half just fails miserably. I'm forced to use
glXGetConfigs, which is from 1.3, but it works. Whatever.
Alright, and now this is the problem with the GLX implementation as a whole.
Basically X11 has a concept of "visuals", which basically tell the
server the formats and masks of each color ... stuff like that. Sanity
would tell you that there was only one per video mode. One for RGB565,
one for RGB888, etc. But then, sanity knew not the Xlib developers.
There's typically about ~50-100 different visuals per display. They're
mostly all the same.
Here's the problem I have. GTK+ picks the default visual for your
display, which is always different from the default visual picked by
GLX. Even though they're completely identical as per glxinfo -v and
xdpyinfo output, it doesn't matter. The visual ID is different, so it
just crashes hard.
Now, the problem is, there's no way to change the visual of a window that was already created (ref -- "For example, depth, class, and visual are assigned at window creation and cannot be changed.").
With my UI library, I create the window near application
initialization. Then for my video API wrapping library, I bind OpenGL
to an existing window much, much later on.
It's
possible to use a lot of black magic to force GTK+ to use a different
visual when creating a new window, but in order to know which visual to
use, I'd have to query the GLX extension to see what it wanted. This
won't do. I refuse to make my GUI library dependent upon GLX. If I did,
then what next? Cater to every possible unrelated API in the future
there? No, not happening.
So then, how do I get video into the window now? Well, it's possible
using the GLX 1.3-only function, glXGetFBConfigs, to get a list of all
visuals. I iterate through and find a match to the current window and
use that visual. This means the doublebuffer attribute is up to the
default visual, and I have no control over it. It also means that the
code technically does not work on pure GLX 1.2 implementations. And
worse yet, ATI seems to have some redrawing issues with the default
visual. It seems the pure color white is being rendered as black. I
have absolutely no idea why. When I use the visual ID GLX wants (and
thus spawn another window), the problem isn't there anymore.
I've tried and failed to hijack reparent a new window inside my
existing window. It's not going to work because the visuals are
different, and even if it did, GTK+ would go apeshit if I tried messing
with the raw innards of windows like that.
So, there's basically nothing I can do about this. There's no way I can
use the preferred GLX visual with bsnes, and my code is forced to rely
on some GLX 1.3 features. I don't know what is causing the bizarre
drawing problems, but I'm sure it's due to my rather unique method of
selecting a visual in one way or another.
So there's nothing I can do. I can't fix GLX fully on ATI cards.
Anyone who wants the latest code can get it here:
http://byuu.cinnamonpirate.com/temp/glx.cpp
Drop that in src/lib/ruby/video and recompile. It also has a small
speedup for nVidia cards, I was needlessly clearing the background each
frame. This caused horrendous tearing on the ATI card since the default
visual isn't double buffered like on nVidia, hence how I spotted the
issue.
I think the worst part is that I have absolutely nobody
to seek advice on with this. If I had a problem like this with
Direct3D, there'd be a thousand solutions to it already posted out
there. For an issue like this? Absolutely no help anywhere, and nobody
even knows anything about this stuff. Sigh ...
EDIT: here's a picture of the ATI rendering issue. Note how pure white is showing up as black. Ideas welcome.
 |
|
|
tukuyomi New Member
Joined: 02 Aug 2004
Posts: 9
|
Posted: Tue Feb 05, 2008 3:44 pm Post subject: |
|
byuu wrote: |
the radeon driver runs like shit for me. |
Only 2D acceleration is supported with radeon libre driver :/
byuu wrote: |
fglrx isn't much better. |
Fear not, ATI (and AMD) are Open Source Friendly ( *255^255)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 05, 2008 4:03 pm Post subject: |
|
This
is an unfounded guess, but perhaps it considers
vec4(255./256.,255./256.,255./256.,1.) to be white, rather than
vec4(1.,1.,1.,1.) and the ATI driver loops, where the nVidia driver
just caps it? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 05, 2008 4:11 pm Post subject: |
|
Confirmed it works on the radeon driver as well, but with one small change:
http://byuu.cinnamonpirate.com/temp/glx.cpp
Change line 140 from:
Code: |
if(glx.version_minor <= 2) { |
To:
What that does is essentially force GLX 1.2 mode. I'm just going to
remove the GLX 1.3 mode, as the nVidia driver has no problems with it
either. The API is backwards compatible, so it should be fine.
Quote: |
This
is an unfounded guess, but perhaps it considers
vec4(255./256.,255./256.,255./256.,1.) to be white, rather than
vec4(1.,1.,1.,1.) and the ATI driver loops, where the nVidia driver
just caps it? |
I don't know what that means :/
Is there a part of the glx.cpp file above I should change to test that?
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Tue Feb 05, 2008 5:18 pm Post subject: |
|
byuu wrote: |
Here's
the problem I have. GTK+ picks the default visual for your display,
which is always different from the default visual picked by GLX. Even
though they're completely identical as per glxinfo -v and xdpyinfo
output, it doesn't matter. The visual ID is different, so it just
crashes hard.
Now, the problem is, there's no way to change the visual of a window that was already created (ref -- "For example, depth, class, and visual are assigned at window creation and cannot be changed.").
With my UI library, I create the window near application
initialization. Then for my video API wrapping library, I bind OpenGL
to an existing window much, much later on. |
Did you try just using a child window?
excerpt from an obsoleted glxblitter I once threw together:
Code: |
int attribList[] = {
GLX_RGBA,
GLX_DOUBLEBUFFER,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
None
};
XVisualInfo *info = glXChooseVisual(QX11Info::display(), QX11Info::appScreen(), attribList);
context = glXCreateContext(QX11Info::display(), info, NULL, True);
std::cout << (glXIsDirect(QX11Info::display(), context) ? "direct\n" : "indirect\n");
Colormap cmap = XCreateColormap(QX11Info::display(),
RootWindow(QX11Info::display(), info->screen), info->visual,
AllocNone);
XSetWindowAttributes swa;
swa.colormap = cmap;
swa.border_pixel = 0;
glxWin = XCreateWindow(QX11Info::display(), winId(), 0, 0, width(),
height(), 0, info->depth, InputOutput, info->visual,
CWBorderPixel | CWColormap, &swa);
XFree(info);
XMapWindow(QX11Info::display(), glxWin);
XSync(QX11Info::display(), 0);
if (glXMakeCurrent(QX11Info::display(), glxWin, context) == False)
std::cout << "failed to make current\n"; |
winId() is the id/handle of the parent window. use XResizeWindow() as needed.
EDIT: included glXMakeCurrent call for clearity.
Last edited by sinamas on Tue Feb 05, 2008 7:30 pm; edited 1 time in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 05, 2008 5:25 pm Post subject: |
|
byuu's
using GL_UNSIGNED_SHORT_5_6_5, so are you suggesting that 31,63,31 is
improperly displayed as black, and that one would have to scale
everything by 30/31 so that white comes out as 30,61,30? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 05, 2008 5:35 pm Post subject: |
|
Quote: |
Did you try just using a child window? |
Actually ... no. No I did not. I made it a standalone window and then
tried XReparentWindow. I'll have to wait until tonight to try this,
sadly.
The only issue I foresee is GTK+ getting stupid with me when I try and
attach a child window to gtk_drawing_area(), which traditionally isn't
a GtkBin/GtkContainer. But Xlib shouldn't really care -- to it, a
window is a window.
Out of curiosity, was your winId() a standalone top-level window, or a widget inside of a window?
Quote: |
winId() is the id/handle of the parent window. use XResizeWindow() as needed. |
Yeah, something like:
Code: |
XWindowAttributes parent, child;
XGetWindowAttributes(display, settings.handle, &parent);
XGetWindowAttributes(display, settings.childhandle, &child);
if(parent.width != child.width || parent.height != child.height) {
XResizeWindow(display, settings.childhandle, parent.width, parent.height);
} |
... stuck inside the top of refresh() should do the trick.
Thanks for the idea, I'll let you know how it works out. Would be
really nice to be able to control the double-buffer flag in software.
Quote: |
byuu's
using GL_UNSIGNED_SHORT_5_6_5, so are you suggesting that 31,63,31
specifies white, and that one would have to scale everything by 30/31
so that white comes out as 30,61,30? |
Oh, no way. No way in hell. Not even as a fallback for ATI only cards.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 05, 2008 5:47 pm Post subject: |
|
byuu wrote: |
Quote: |
byuu's
using GL_UNSIGNED_SHORT_5_6_5, so are you suggesting that 31,63,31
specifies white, and that one would have to scale everything by 30/31
so that white comes out as 30,61,30? |
Oh, no way. No way in hell. Not even as a fallback for ATI only cards.
|
My apologies, I should've read the file you included in the first
place.. Yes, I was thinking of something like that, not considering the
output format you're actually using.
I was thinking
0-255 to 0.0-1.0 (as in RGB888 and the floating point representation GLSL uses)
maybe should be
0-255 to 0.0-255.0/256.0
But since you're not doing any kind of conversion, but rather telling
it what colour format you're using, it doesn't (couldn't) apply.
Just to clarify, I thought there might be a conversion that was using
the wrong numbers, I wasn't suggesting simply capping it.
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Feb 05, 2008 6:04 pm Post subject: |
|
I've
been writing a short text on bsnes, and I released it today. It's in
Finnish so most of you can't understand it. I wrote it because I wanted
to share information about this amazing project in Finnish, and perhaps
attract a few Finns to join the discussion. It's the very first
version, and I'm going to revise it as the development goes further. If
there is any Finn around, please proofread my text.
And the link: http://www.turambar.org/jarkko/emulaattorit.php. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Tue Feb 05, 2008 7:21 pm Post subject: |
|
byuu wrote: |
Out of curiosity, was your winId() a standalone top-level window, or a widget inside of a window? |
A widget inside of a window.
byuu wrote: |
Quote: |
winId() is the id/handle of the parent window. use XResizeWindow() as needed. |
Yeah, something like:
Code: |
XWindowAttributes parent, child;
XGetWindowAttributes(display, settings.handle, &parent);
XGetWindowAttributes(display, settings.childhandle, &child);
if(parent.width != child.width || parent.height != child.height) {
XResizeWindow(display, settings.childhandle, parent.width, parent.height);
} |
... stuck inside the top of refresh() should do the trick.
|
Catching the resize event would be way nicer though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 05, 2008 9:06 pm Post subject: |
|
sinamas, you are a genius! :D
http://geocities.com/byuu64/glx.cpp.txt
Works perfectly. The code is obviously in a rough state, as I hacked it
together really quickly on my lunch break. I still need to clean it up,
remove all GLX 1.3 functions, and add an expose event to clear the
video.
But the good news is, I can now use any X11 visual I want :D
Thanks a million!
Quote: |
Catching the resize event would be way nicer though. |
That would require the video API wrapping library to have knowledge of
the GUI abstraction library, to be able to bind to its signals like
that. That, or add an otherwise useless "resize" notification function.
I guess that wouldn't be all bad. I was thinking of adding out_width,
out_height to the refresh function anyway, so that I don't need to call
XGetWindowAttributes / GetClientRect. Caching it would probably work
just as well.
|
|
jisakujien New Member
Joined: 27 Dec 2007
Posts: 1
|
Posted: Wed Feb 06, 2008 12:19 am Post subject: |
|
fglrx supports xv just fine, put
Code: |
Option "OpenGLOverlay" "off"
Option "VideoOverlay" "on"
|
in the Device section of your xorg.conf.
Also, the GLX 1.3 version works fine with 'ati' (the driver 'ati') on
my r300, with AIGLX and Compositing disabled. However, performance was
quite terrible. With Xv I can get 60fps on the Chrono Trigger intro
until it comes to the text, with 'opengl' it doesn't even get 30. It
also segfaulted my xserver when exiting just now (which I guess is an
improvement over completely hardlocking my system when I tried using
1.2 calls with XVisualInfo from glXGetVisualFromFBConfig).
The new code is still slower than xv when I have AIGLX off, but only
about 5 fps. There is horrible flickering if used with compiz.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 06, 2008 12:42 am Post subject: |
|
Quote: |
fglrx supports xv just fine |
Ah, so that's how you do it. Thanks.
Quote: |
Also, the GLX 1.3 version works fine with 'ati' (the driver 'ati') on my r300 |
Another ATI driver?!?! That's ati, radeon, radeonhd, fglrx, ... how many others am I missing now?
Quote: |
completely hardlocking my system when I tried using 1.2 calls |
Ouch! Terribly sorry about that.
Quote: |
The
new code is still slower than xv when I have AIGLX off, but only about
5 fps. There is horrible flickering if used with compiz. |
I noticed that AIGLX murders performance. Probably because bsnes is
very different from most OpenGL apps. Rather than just uploading some
textures and blitting those with small lists, I'm transferring 60 full
frames of video data per second. The overhead to pass through X is
obviously tremendous in this case. Or perhaps my code just sucks. With
the fglrx driver, I'm able to tell GLX to render directly to the card,
and I go from ~20fps to ~70fps. I didn't have to explicitly enable or
disable AIGLX in xorg.conf or anything.
So, 5fps slower for the new code isn't that bad, though I personally
get a ~10fps improvement over the Xv code on my nVidia. A ~5fps loss is
worth it for having full chroma information and the ability to disable
the linear filter.
Quote: |
There is horrible flickering if used with compiz. |
Yeah, Derrick noticed this when he had a translucent terminal via
xcompmgr onscreen at the same time as bsnes. Not sure what's going on
here ... perhaps it's because I try and gain direct access to OpenGL
while something else is using it, or perhaps it's because I choose a
Visual ID that's already in use ... ?
I'm pretty much following the reference manual to a tee at this point,
so I'm not sure what else I can try. Maybe forcing double buffering
will help.
Thanks very much for registering and sharing the useful information, by the way. Very helpful.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 06, 2008 1:20 pm Post subject: |
|
Linux/OpenGL driver updated. Thanks for all of the help, everyone!
byuu.org wrote: |
2008-02-06 - bsnes v0.028.01 source released
While v0.028's release went a lot better than expected, there was one
significant problem: it appears that the Linux OpenGL renderer did not
work correctly on any of the four ATI graphics card drivers. It seems
to be related to partial implementations of GLX v1.3 (you know, the ten
year old Xlib interface for OpenGL?)
Rather than continue fighting these drivers, I instead opted to
backport the driver to use GLX v1.2 instead. This seems to work on the
fglrx, ati and radeon drivers. I don't know much of the radeonhd
drivers, but I believe they lack 3D acceleration anyway.
sinamas also came up with an ingenius trick to work around the X Visual
problem: that is to say, a GLX rendering context requires a window with
the same X Visual as itself. But it's not possible to change the Visual
of the existing window that is passed to the GLX driver. sinamas
suggested creating this new window as a child window, and embedding
that within the rendering window. This worked wonderfully, and
eliminates the need for enumerating all available GLX contexts, which
is why I needed the GLX 1.3 API in the first place. bsnes now uses the
GLX-recommended Visual, which also eliminates a color problem that
existed on the fglrx driver when using the default X11 visual.
I also removed the glClear command inside refresh(), as it was
redundant and caused flickering on non-buffered visuals. It might even
give a slight speed increase on some cards.
Lastly, [vEX] pointed out that I should use the -D flag for the install
command in the Makefile. This has been fixed.
I'm not updating the Windows binary to v0.028.01, as absolutely nothing
has changed in the Windows port yet. I'll update again when the Debian
repository is synced with the new version. |
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Feb 06, 2008 2:11 pm Post subject: |
|
byuu wrote: |
Linux/OpenGL driver updated. Thanks for all of the help, everyone! |
Yay, I'm sure the ATi users are happy now!
EDIT: Umm.. it seems like the child window doesn't redraw when you're
not running anything so if you drag another window over it you will
have garbage in it. Using the 'nvidia' driver, specs in signature.

_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 06, 2008 3:00 pm Post subject: |
|
Oh
wow, my nvidia driver repaints the window to black for me. Maybe
because I have compositing on. I knew it did that on ATI cards, and
mentioned it previously.
Anyway, I wasn't sure how
to capture expose events for an XWindow, so I didn't add that just yet.
I figured it was minor enough compared to the old driver completely
failing on all ATI cards. But yeah, definitely need to get that fixed
for the next release.
I can't wait to get rid of this ATI card. I get ~700(!!) fps in
glxgears with the "ati" driver. And I can't figure out how to turn off
AIGLX with it (it ignores the glXDirect = true setting, so ~70fps
becomes ~15fps). And it draws the video ~8" to the right, so I can't
see half the screen. Ugh. The only really nice thing is that it has RGB
Xv surfaces. Would be nice to add an optional RGB renderer to Xv. The
compositor seems to work, too. fglrx's compositor is just ... fucked.
At this point, I think I'll just take this card out tonight, and add
RGB support to Xv using the nv driver. So no need to help with my ati /
fglrx issues. That card is going in the closet ASAP, hopefully for good. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Wed Feb 06, 2008 3:45 pm Post subject: |
|
byuu wrote: |
Oh
wow, my nvidia driver repaints the window to black for me. Maybe
because I have compositing on. I knew it did that on ATI cards, and
mentioned it previously. |
Yeah, it's nothing major, I just wanted to point it out so you knew
about it. And actually, I have composition enabled in my xorg.conf, but
I don't use it. Only enabled it to test out xcompmgr a while ago, never
bothered to disable it since it doesn't seem to have any negative
effect.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
kick Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
|
Posted: Wed Feb 06, 2008 11:40 pm Post subject: |
|
I
can't believe your ATI card scored that low in glxgears. Only 700?
Wow,that's a 'record-breaking' score you got there with the X600
'Stripped Edition'.
FYI,a 5-year old 'junk' PC
with an 'ancient' R200-based card beats the snot out of your PC in
glxgears,LOL. (over 1,500fps in glxgears @ 1600x1200 / 85Hz / 24bpp
with fglrx, and about 1,250 with the 'radeon' or 'ati' drivers)
Tested on 4 live distros: Kubuntu,Ubuntu,Knoppix and Puppy Linux.
You should know that the glxgears score you got is a very relative
number.There are many factors that can influence the result.For
example,even the screen position (!) of the glxgears window can alter
the result a bit.
So,may I ask you what distro,driver,resolution,bitdepth,refresh
rate,glxgears window size and position were you using when you
benchmarked that ATI card with glxgears? Was the glxgears window on top
of another window during the benchmark?
_________________
Have a nice kick in da nutz @~@* |
|
qwerty` Rookie
Joined: 17 Feb 2007
Posts: 29
|
Posted: Thu Feb 07, 2008 8:22 am Post subject: |
|
I found a funny bug. Try unchecking 'Show Statusbar' and then press Esc. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Feb 07, 2008 8:40 am Post subject: |
|
that
bug appears to be just the menu bar disappearing upon press of escape.
you can press escape at any time to trigger it in bsnes... pressing it
again restores it.
i did notice some graphics
corruption with the bsnes window but i believe this is related to my
old buggy video card.
_________________
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. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Feb 07, 2008 8:54 am Post subject: |
|
I tried this, and although "apt-get update" mentions checking http://repository.cinnamonpirate.com/ "apt-cache search bsnes" returns nothing. Does the repository have x86_64 binaries?
I'd check for myself but the webserver is misconfigured to disallow
directory browsing, unlike every other package repo I've come across.
EDIT: According to some friends on IRC:
Code: |
20:09 <@cuz> Screwtape: As far as I can tell, that repository has an empty Packages file for amd64.
20:09 <@cuz>
http://repository.cinnamonpirate.com/dists/gutsy/pirate/binary-i386/Packages
<-- exhibit A
20:09 <@cuz>
http://repository.cinnamonpirate.com/dists/gutsy/pirate/binary-amd64/Packages
<-- exhibit B |
Oh well. :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Feb 07, 2008 11:30 am Post subject: |
|
If someone wants a 64 bit binary for Linux, I can provide one.
Let me know which CPU though.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Feb 07, 2008 12:29 pm Post subject: |
|
Nach wrote: |
If someone wants a 64 bit binary for Linux, I can provide one. |
I was rather hoping for the ease and magical 'always up to date' nature
of software repositories; I'm sure I can compile it myself if I have a
pressing need to test it out.
I was going to suggest uploading the source .debs to a Launchpad PPA
where they'd be automatically built for all supported Ubuntu releases
and architectures, but (among other restrictions) they won't allow you
to upload software with a "no commercial use" licence, so no easy
package-building and repository hosting for bsnes. :(
Actually, are source .debs available for bsnes? I notice
repository.cinnamonpirate.com doesn't have a "deb-src" line in its
sources.list settings.
Also, it seems a shame that even architecture-neutral packages like vgfonts aren't available. :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Feb 07, 2008 12:33 pm Post subject: |
|
Well I don't do debs, I only specialize in optimized binaries.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 07, 2008 5:38 pm Post subject: |
|
Okay,
ExposureMask for an X11 window sends events, but you have to check the
event queue periodically to get the event. Since I can only do that
when calling video.refresh(), it's kind of pointless by that point to
even bother. Therefore, I'm going to have to add an on_expose functor
to my GUI library, and have that call video.clear(). Lame.
Quote: |
FYI,a 5-year old 'junk' PC with an 'ancient' R200-based card beats the snot out of your PC in glxgears,LOL. |
Everyone and their mother beats me with their glxgears scores. It
doesn't matter what video card I use. I really don't care -- I don't
play any 3D games on Linux anyway.
Quote: |
So,may
I ask you what distro,driver,resolution,bitdepth,refresh rate,glxgears
window size and position were you using when you benchmarked that ATI
card with glxgears? Was the glxgears window on top of another window
during the benchmark? |
Geez, that's too much information. I just opened a terminal, ran
glxgears, and said what it output. 24bpp depth as usual, that's about
it. No worries, I don't care about getting a bad score in it.
Quote: |
I found a funny bug. Try unchecking 'Show Statusbar' and then press Esc. |
That's not really a bug, though. The command in input configuration
states "toggle" menubar and "toggle" statusbar. I linked them together
by default as Nach suggested, and each time you start the emulator
they're both visible, so it typically works as expected. If you want to
toggle both individually, I strongly recommend remapping the UI keys.
The only way I could avoid this would be to remove the option to
show/hide the statusbar from the menu, but even then you could go out
of your way to remap the keys repeatedly and cause the same effect.
Another novelty is that you can link fullscreen, toggle menu and toggle
status all to the same key, to quickly go to a "pure" fullscreen and
back to windowed + menu + status.
Quote: |
Does the repository have x86_64 binaries? |
No, sorry. Would be nice if Linux would take a page from Microsoft and
natively allow 32-bit binaries to run on 64-bit Linux without the need
for wrappers and such :(
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Feb 07, 2008 7:49 pm Post subject: |
|
byuu wrote: |
No, sorry. Would be nice if Linux would take a page from Microsoft and
natively allow 32-bit binaries to run on 64-bit Linux without the need
for wrappers and such  |
What?
It does, where have you been?
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Feb 07, 2008 7:50 pm Post subject: |
|
byuu wrote: |
No,
sorry. Would be nice if Linux would take a page from Microsoft and
natively allow 32-bit binaries to run on 64-bit Linux without the need
for wrappers and such  |
I would switch to 64 bit so fast if that was true...
Nach wrote: |
What?
It does, where have you been? |
It does? Sorry, I posted like two seconds after you and didn't see your post.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Feb 07, 2008 8:31 pm Post subject: |
|
all x86-64 kernels come with the ability to execute 32-bit code.
whether or not the package manger installs 32 and 64 bit versions of libraries at the same time is another matter.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 07, 2008 10:22 pm Post subject: |
|
If
amd64 Linux can execute 32-bit binaries, then why is Thristian asking
for a 64-bit version of bsnes? It's not any faster -- I get the same
speed on both Xubuntu 7.10 i386 and amd64.
Maybe
this is the fault of apt-get failing to support installation of 32-bit
binaries? Or general apathy to installing 32-bit copies of libraries? I
can see that as being a valid argument, actually. But really, not a big
deal for the convenience you get with so much software already out
there which is locked to 32-bits, eg ZSNES. |
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Fri Feb 08, 2008 12:08 am Post subject: |
|
Well,
I for one would love 64-bit binaries as well. While Linux *can* run
32-bit mode, you have to install 32-bit compatibility layers for it.
The more you can avoid those libs, the less your system will get bogged
down by duplicate versions of the same lib. And yes, Ubuntu has both in
it's repositories.
But, besides the nice warm
fluffy feeling of having a fully 64-bit supported system, there isn't
much point in it otherwise I suppose... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 08, 2008 12:26 am Post subject: |
|
Okay, I really do need to add a more friendly driver configuration screen to bsnes.
I was thinking of something like this as a quick mock-up:
http://i73.photobucket.com/albums/i221/byuusan/driverconfig.png
Pretend there's an "Active driver: foo" in there somewhere. And maybe
some errata notes, and / or a general description of sorts.
For this approach, there would be three separate tabs. But I could just
as easily add a radio box selection to the top for Video / Audio /
Input that updates the below boxes dynamically, as well.
I'm not going to go crazy trying to add something like combo boxes and
text boxes nested inside the list box to let you change those
driver-specific settings. I want the important ones to be controllable
elsewhere in the GUI, such as in the menu; and the crazy,
driver-specific ones to be in the Advanced configuration panel.
I can't put the dropdown box on the same line as the combo box because
different themes have different font sizes, and it doesn't line up that
well. Maybe in the future with a text vertical center option.
I'm also really worried about driver crashes. Much more common on
Linux, but still possible on Windows. The problem is, if your driver is
set to one that crashes, then restarting bsnes will just result in
another crash before you can change the setting.
The best I can think of is to set a "safe_closed" variable to false on
startup, and true on close. If the app crashes, it won't get set to
true. Then when you restart, I'll initialize all three drivers to the
safest driver, or to no driver at all if the safest was in use already,
display an alert, pop open the config window, and let the user select
new drivers.
But that still causes a crash. A really, really, really impatient user
might give up after the very first crash. Not much I can do ... Xorg
loves to crash the app the second an API call failed (BadDrawable,
BadMatch, etc), rather than return an error code for you to try and
handle. Yes, you can catch them globally by installing your own handler
supposedly, but that's not all that useful for the level of abstraction
I'm going for (UI separate from drivers.) Sometimes things just flat
out segfault.
Perhaps I should default bsnes to all "none" for the drivers, and the
very first time bsnes opens, have it display a welcome screen, telling
the user about the crash recovery support, and allowing the user to
select the drivers they want? This has the added benefit that it won't
scare off users with the horrendous quality of the default drivers on
Linux.
Suggestions welcome. |
|
qwerty` Rookie
Joined: 17 Feb 2007
Posts: 29
|
Posted: Fri Feb 08, 2008 1:01 am Post subject: |
|
byuu wrote: |
That's
not really a bug, though. The command in input configuration states
"toggle" menubar and "toggle" statusbar. I linked them together by
default as Nach suggested, and each time you start the emulator they're
both visible, so it typically works as expected. If you want to toggle
both individually, I strongly recommend remapping the UI keys. The only
way I could avoid this would be to remove the option to show/hide the
statusbar from the menu, but even then you could go out of your way to
remap the keys repeatedly and cause the same effect. |
I do use esc to toggle both. I said it is funny because I think it
is--I don't really care though and I would agree it's not worth
changing if it makes the code longer.
I remember something like bsnes having audio sync issues with video sync on. Was that ever fixed?
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 08, 2008 1:06 am Post subject: |
|
Hmm,
while it won't help with the crashing itself, since this concerns
realtime switching between drivers, why not hold off writing the new
setting to the config file until the driver has been initialised?
(obviously that wouldn't help if the default drivers make it crash, and
your 'config on first run' idea has merit for the other reason you
mentioned, as well) |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Feb 08, 2008 3:55 am Post subject: |
|
qwerty` wrote: |
I remember something like bsnes having audio sync issues with video sync on. Was that ever fixed? |
Nope.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Feb 08, 2008 6:28 am Post subject: |
|
byuu wrote: |
If
amd64 Linux can execute 32-bit binaries, then why is Thristian asking
for a 64-bit version of bsnes? It's not any faster -- I get the same
speed on both Xubuntu 7.10 i386 and amd64.
|
To run bsnes 32-bit, on a 64 bit machine one needs:
libgtk
libSDL
libXv
libao
libopenal
libalut
libGL
libc
libX11
libXext
libpthread
libstdc++
libXrender
libz
libpng
All in 32 bit , as well as what they depend on in 32 bit, and probably
some others (check out "ldd bsnes") - just like one would need on a 32
bit system.
The first thing here is annoyance, do you really want to have two copies of every DLL/SO on your system?
The other issue is how distros and package managers may handle it. Most
64 bit distros will not include every 32 bit library. They may include
some of the more popular ones such as libc, libc++, libx, libz, but
they rarely go deeper than that.
I'm told Gentoo with their build everything yourself approach will
install GCCs with multiple targets, so whenever you compile any lib on
your 64 bit system, it'll compile 32 bit copies of that library as well.
I have not yet seen any Debian based distros that want to give a full
32 bit library set. Personally, I used deb boot strap to install a
Debian Skeleton of 32 bit, link /usr/lib32 to my skeleton, and then
within this skeleton, I can apt-get install any 32 bit lib, since apt
sees i386 in it's settings, and then my system as a whole (64 bit) can
access the downloaded libs.
I have no trouble launching bsnes whether 32 (no wrappers required) or
64 bit, although the 64 bit one does give me a couple more FPS.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Feb 08, 2008 8:48 am Post subject: |
|
byuu wrote: |
If
amd64 Linux can execute 32-bit binaries, then why is Thristian asking
for a 64-bit version of bsnes? It's not any faster -- I get the same
speed on both Xubuntu 7.10 i386 and amd64. |
More an issue of expectations, really. I installed a shiny new amd64
Ubuntu system, and my browser is 64-bit, my desktop is 64-bit, my
programming environment (/usr/bin/python!) is 64-bit, bazillions of
other 64-bit packages just an "aptitude install" away. I had become
accustomed to the idea that every useful and respectable package was
available in a 64-bit variant, and (since I had already heard that
bsnes was 64-bit compatible) I just blindly assumed that 64-bit
binaries would be available.
I guess I was wrong.
I'm not trying to complain - if your repository-maintaining friend
doesn't have an amd64 install with which to build packages, then I'll
just get my copy bsnes the traditional way, with g++. :)
[/url]
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 08, 2008 10:33 am Post subject: |
|
New WIP posted, Linux only. Need all the testers I can get on this one, please.
First and foremost, I spent about four hours figuring out how to
disable the screensaver on Linux. I tried XSetScreensaver,
XResetScreenSaver, XScreenSaverSuspend, DPMSDisable, synthetic
XSendEvent, and all of them failed miserably. I ended up getting it to
work with only one thing: XTestFakeKeyEvent. I send a fake keypress
every ~20 seconds. The key send is keycode (not keysym) 255. I don't
know of many 256-key keyboards, so I think that should be fine.
Anyway, testing would be greatly appreciated. Please make sure the
synthetic key events do not interfere with your applications in any
way. Technically, the fake key send goes to whatever the active app is.
It shouldn't matter as the keycode used is undefined. I haven't seen
any GTK+ or Qt apps do anything with it, they just ignore it. If any
issues come up, then the best I can do is enable the screensaver
whenever bsnes doesn't have focus, and disable when it does have focus.
I think it should be fine, though. Totem uses the same trick and nobody
seems to mind. mplayer tries all of my above methods plus bizarre fake
messages and dbus commands to try and stop the screensaver, and it
still fails for a lot of people.
Next up, I've extended the Xv renderer. It can handle RGB15, 16, 24, 32
and YUY2 formats now. It defaults to RGB ones if you have them. I'd
like if all of them could be tested. RGB15 and 16 should be perfect, 24
and 32 will likely have bad pointer arithmetic, but will hopefully work.
Need to set driver to "xv", and check what you have with "xvinfo". It
defaults to RGB16, then RGB15, then RGB32, then RGB24, then YUY2, then
it gives up and fails. In the future we can see about letting the
encoding be user-selectable.
Quote: |
if your repository-maintaining friend doesn't have an amd64 install with which to build packages |
That's exactly it, sorry. Plus I don't want to burden him more than I do already.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Feb 08, 2008 10:50 pm Post subject: |
|
A
bit late I guess but I just noticed how you can now bind emulation
related stuff to any joypad buttons in bsnes (or simply chose to not
assign the function to anything at all). Very sweet. |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Fri Feb 08, 2008 11:04 pm Post subject: |
|
Thank you for fixing joypad support under windows!
I've got three different pads plugged in and only one of them was recognized by bsnes, until v0.028.
Also I'd like to point out two little bugs:
1) Cheat files aren't saved in the save directory, but in the rom directory.
2) I believe the screen is rendered one scanline too low (with certain
games?). I've been comparing the output with real SNES using "Legend of
Zelda, The (E)", and I'm 100% positive that bsnes shows the topmost
scanline at the bottom, or something like that.
I think the topmost line should be black, not just cut off. In PAL mode
the black bar at the bottom is only 15 pixels high, while Zelda shows a
too high 17 pixel "block" on top of it.
Aside from that, bsnes is just unbelievably magnificent for what it is.
I don't care about some special chip games not working, for me it's enough even if just one game works flawlessly!
I've only read about half of this whole thread, but is it possible to
configure bsnes to really output 32040Hz audio and 60.09Hz video?
Audio probably needs to be resampled into 32kHz, does the resampling
make it sound inferior compared to native 32kHz output?
I've tried to run bsnes and real SNES in sync but bsnes is just slightly slower. 
--
Edit: corrected mix-ups |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Feb 08, 2008 11:46 pm Post subject: |
|
rayno wrote: |
Thank you for fixing joypad support under windows!
I've got three different pads plugged in and only one of them was recognized by bsnes, until v0.028.
Also I'd like to point out two little bugs:
1) Cheat files aren't saved in the save directory, but in the rom directory.
2) I believe the screen is rendered one scanline too low (with certain
games?). I've been comparing the output with real SNES using "Legend of
Zelda, The (E)", and I'm 100% positive that bsnes shows the topmost
scanline at the bottom, or something like that. |
I may be talking out of my ass but it's possible bsnes is not quite as
accurate in regards to PAL emulation compared to NTSC. PAL emulation
often tend to be relegated to second simply because most devs
possess/test on NTSC units...Plus everyone hates PAL region anyway lol
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Fri Feb 08, 2008 11:55 pm Post subject: |
|
use the US version of SNES games if they exist.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sat Feb 09, 2008 12:06 am Post subject: |
|
Snark wrote: |
I may be talking out of my ass but it's possible bsnes is not quite as
accurate in regards to PAL emulation compared to NTSC. PAL emulation
often tend to be relegated to second simply because most devs
possess/test on NTSC units...Plus everyone hates PAL region anyway lol |
I figured out that much already, but the reason I wanted to bring it up
is because it's present in the NTSC version as well.
It's evident in Zora's fountain when you're standing near the exit.
Another place is the dungeons when standing near southmost walls.
For some reason it's not that visible in the outside world, maybe
because the game renders slightly ahead of the next screen?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 09, 2008 12:08 am Post subject: |
|
Quote: |
Thank you for fixing joypad support under windows! |
Yes, sorry about that. Nobody reported it and I just noticed the bug recently.
Quote: |
1) Cheat files aren't saved in the save directory, but in the rom directory. |
Never really thought about it. I suppose that's more logical. I'll make the change shortly, thanks.
Quote: |
2) I believe the screen is rendered one scanline too low (with certain games?). |
Well, I can assure you that what I draw is what is really rendered. The
first scanline is not drawn because the PPU is busy pre-fetching
sprites. The last scanline is usually clipped by most emulators, but
the PPU is in fact quite active. It's counting sprite range / time
over, it's reading from VRAM and locking the CPU out of accessing it,
it's holding the vertical blank pin low, etc etc.
Now, one thing to note is that almost all CRT NTSC and PAL televisions
have overscan to varying degrees. That is, they intentionally chop off
some of the top and bottom scanlines, to prevent "artifacts" from being
displayed from poor video sources.
As for the bottom line:
SNES game developers realized this, and so they typically ignore the
very last scanline, because it's the start of a new tile. Why process
an tile row when 7/8ths of it isn't rendered, and the other 1/8th isn't
visible, right? This is why on a few games you see a solid color bar at
the bottom, and on very few games, you'll see garbled data. I just chose not to cut off any visible pixels is all.
As for the top line:
While it is almost certainly "drawn" (even if clipped by overscan), and
it probably affects centering of the image on-screen, I couldn't find a
convincing reason to always, always draw a black line at the top of
bsnes. It's always 100% guaranteed to be solid black here. It's been
verified by using TVs with underscan / manually tuned overscan by
others, and even via TV input from capture cards.
This means 224 vertical lines are drawn for NTSC, and 239 lines for
PAL. I'm sure you're more accustomed to 225/240.
Quote: |
I don't care about some special chip games not working, for me it's enough even if just one game works flawlessly! |
Thank you! :)
And hopefully I'll get those two last major special chips in eventually, too.
Quote: |
I've
only read about half of this whole thread, but is it possible to
configure bsnes to really output 32040Hz audio and 60.09Hz video?
Audio probably needs to be resampled into 32kHz, does the resampling
make it sound inferior compared to native 32kHz output?
I've tried to run bsnes and real SNES in sync but bsnes is just slightly slower. |
Unfortunately, this is not possible. The audio syncs to the sound card
rate. Many sound cards resample audio internally to 48khz. Since
32khz<>48khz (1.5) is close, there's a lot less aliasing than
32.04khz<>48khz (1.498127...) So believe it or not, sound quality
would be worse at 32.04khz than at 32khz.
I've never heard of a sound card that will actually output at 32040hz
without resampling the audio first. If they exist, they're surely very,
very expensive. But yes, we run into the problem that bsnes runs 0.125%
slower than a real SNES :(
As for video, it will redraw at 60.09 * (1.0 - 0.00125)fps. The audio
syncing is delaying the video to keep them in sync with each other. But
it's worth noting that 60.09fps with smooth video is completely
impossible. The best we can do is average to the monitor refresh rate.
And setting a refresh rate of 60.09fps, while probably possible in
Xorg, isn't even a good idea. PAL runs at ~50fps, and even NTSC
interlace runs at 59.97fps. It's best to just leave it alone.
There's also the inherent problems of latency. Video and audio appear
slightly later than they do on a real SNES. Roughly 1-2 frames of video
delay and ~30ms of audio delay; which manifest as "less responsive
input." Sadly, there's really nothing that can be done about this. Not
even Nintendo Wii's Virtual Console can work around these problems, as
they are inherent to every software-based emulator in existence.
Luckily, the latency levels in most emulators are far below human-observable levels.
Sadly, there's nothing like the real thing. bsnes doesn't even come close. No emulator does.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 09, 2008 12:28 am Post subject: |
|
byuu wrote: |
This is why on a few games you see a solid color bar at the bottom, and on very few games, you'll see garbled data. I just chose not to cut off any visible pixels is all. |
If simple enough ,perhaps a small video option to let the user choose
how many lines they want to hide/display (if any). Not proposing
changes to the inherent emulation process of course, just something
you'd slap on top.
Quote: |
There's
also the inherent problems of latency. Video and audio appear slightly
later than they do on a real SNES. Roughly 1-2 frames of video delay
and ~30ms of audio delay; which manifest as "less responsive input."
Sadly, there's really nothing that can be done about this. Not even
Nintendo Wii's Virtual Console can work around these problems, as they
are inherent to every software-based emulator in existence. |
ah...The age-old emulation question/problem...I notice this is highly
dependent on the emulator. I doubt there's an inevitable (minimal) 1-2
frame delay in all emulators. For example in Elsemi's standalone CPS3
emulator there's zero lag (least none that I can notice and I'm used to
play the arcade version) if I turn off vsync. whereas in M.A.M.E
regardless of settings there's noticeable lag...I think it may even
vary by drivers...
I really wish the emulation "community", or someone very knowledgeable
would research this issue once and for all, because it's a problem that
many have complained about yet there seem to be no global solution.
Quote: |
Sadly, there's nothing like the real thing. bsnes doesn't even come close. |
There may or may not be anything like the real thing depending on who
you're asking but bsnes definitely come most closer to any emulators
currently around (including whatever the crap Nintendo uses in there Wii virtual console)
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sat Feb 09, 2008 12:33 am Post subject: |
|
So, in essence, you're saying that forcing vsync to prevent tearing in bsnes is impossible...?
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 09, 2008 12:45 am Post subject: |
|
byuu wrote: |
If
they exist, they're surely very, very expensive. But yes, we run into
the problem that bsnes runs 0.125% slower than a real SNES :( |
Couldn't this be side stepped one way or another by skipping one frame
once in a while or by any other means? Or maybe there's other ways to
sync the emulator other than to base it on the audio (although I don't
know how much rewriting that would demand)
|
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sat Feb 09, 2008 1:06 am Post subject: |
|
byuu wrote: |
As for the bottom line:
SNES game developers realized this, and so they typically ignore the
very last scanline, because it's the start of a new tile. Why process
an tile row when 7/8ths of it isn't rendered, and the other 1/8th isn't
visible, right? This is why on a few games you see a solid color bar at
the bottom, and on very few games, you'll see garbled data. I just chose not to cut off any visible pixels is all.
-- cut --
This means 224 vertical lines are drawn for NTSC, and 239 lines for
PAL. I'm sure you're more accustomed to 225/240. |
It's just I've always thought the SNES renders 224/240 lines and the
topmost black line is one of them, because that's what I've seen my
console do.. So the bsnes just shows one line more than the actual unit
because it cuts off the first black line. Nothing dangerous.
Thank you for the explanation, you're the first emulator developer I've
seen who cares to tell the details to everyone :)
Quote: |
Unfortunately, this is not possible. The audio syncs to the sound card
rate. Many sound cards resample audio internally to 48khz. Since
32khz<>48khz (1.5) is close, there's a lot less aliasing than
32.04khz<>48khz (1.498127...) So believe it or not, sound quality
would be worse at 32.04khz than at 32khz.
As for video, it will redraw at 60.09 * (1.0 - 0.00125)fps. The audio
syncing is delaying the video to keep them in sync with each other. But
it's worth noting that 60.09fps with smooth video is completely
impossible. The best we can do is average to the monitor refresh rate.
And setting a refresh rate of 60.09fps, while probably possible in
Xorg, isn't even a good idea. PAL runs at ~50fps, and even NTSC
interlace runs at 59.97fps. It's best to just leave it alone. |
NVidia drivers claim my monitor is running at 60.019 Hz (DMT), while GTF timing is 59.998 Hz.
I tried 60.09 Hz but it didn't affect anything, I get the same one frame drop every 10-15 seconds.
On a sidenote, it's nice how LCD monitors can do 50 Hz without any flickering (unlike CRTs) :)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Feb 09, 2008 5:25 am Post subject: |
|
rayno wrote: |
I tried 60.09 Hz but it didn't affect anything, I get the same one frame drop every 10-15 seconds. |
bsnes uses the audio frequency for speed regulation, so raising your
refresh rate like that only makes the difference between bsnes' speed
and your refresh rate slightly larger, which would logically lead to
more frequent frame drops. I'm impressed you can notice them at all
though
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 09, 2008 6:54 am Post subject: |
|
I
doubt it's humanly possible to notice something 0.1% slower. I did
recently notice something a little strange with bsnes scaling. On my
box, it seems to render the pixels differently on anything higher than
1x scaling for PAL, and anything higher than 2x for NTSC, so everything
appears more blurry even with no filters and no AR correction. Normal?
 |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Feb 09, 2008 11:26 am Post subject: |
|
FitzRoy wrote: |
I doubt it's humanly possible to notice something 0.1% slower. |
You can, if it accumulates over time.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 09, 2008 5:56 pm Post subject: |
|
Quote: |
I
really wish the emulation "community", or someone very knowledgeable
would research this issue once and for all, because it's a problem that
many have complained about yet there seem to be no global solution. |
There isn't a solution. It's an inherent problem of emulation. If you
use a 2GHz CPU to emulate a 2.048MHz S-DSP, you can't possibly run each
opcode at the same exact speed. But you can get really close.
Then you have to add in other overhead:
- emulating multiple processors in the base system; and again,
multi-core processors are useless for this problem due the insanely high latency between them
- using a multi-tasking operating system
- using computer hardware that was designed for buffering video and
audio, rather than just-in-time signal output on a TV
- less (or at least, much more difficult) flexibility of monitor refresh rates -- TVs are very lenient about this
- just the simple fact that TV hardware != computer hardware
If you really want to avoid these problems, the only way to do it is to
design your own hardware that outputs to a television, such as CopyNES.
The reason I won't even consider that approach is because I want my
software to be usable by millions, not tens, of people. Plus, at this
point in time, if you're going to use hardware, you might as well use
the real thing. Things like the FC Twin just seem spectacularly useless
to me at this time.
Quote: |
There
may or may not be anything like the real thing depending on who you're
asking but bsnes definitely come most closer to any emulators currently
around Very Happy (including whatever the crap Nintendo uses in there
Wii virtual console) |
I may have made it to Jupiter where others have made it to Mars, but when your ultimate destination is NGC 4414, the difference isn't as relevant as you might like.
Not trying to play the negative card, just stating the obvious.
Software emulation can not and will not ever replace the real thing.
But nonetheless, we'll keep pushing to get as close as possible :)
It's also worth noting that the subjective differences between
emulation and hardware are certainly far more discernible for me than
for most anyone else. Obviously, the differences I worry about don't
visibly affect any games you guys play -- hence you can't even know
that they are there if you cannot observe them. And that seems good
enough for 99.9% of people.
Quote: |
So, in essence, you're saying that forcing vsync to prevent tearing in bsnes is impossible...? |
It's possible, but you have to enable it. Windows has video.synchronize
in the config file, and Linux forces the user to always manually
enable/disable vsync, both in Xv and in OpenGL (see nvidia-settings)
because it's stuck in 1970. But you can do it. Your audio will stutter
then. You can't sync both or you'll end up with both video and sound
stuttering.
I really need a commonly asked questions page. I've been over why I
can't sync both (cant generate a consistent enough audio rate to
perform clean resampling) many times in the past.
Quote: |
On
my box, it seems to render the pixels differently on anything higher
than 1x scaling for PAL, and anything higher than 2x for NTSC, so
everything appears more blurry even with no filters and no AR
correction. Normal? |
D3D driver has had that problem forever. It seems to be worse when
resizing the window without restarting the emulator. I don't know
what's wrong with it yet.
Quote: |
You can, if it accumulates over time. |
Right, loop the intro to your favorite game on a real SNES and in the
emulator and you can watch the two drift apart.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 09, 2008 8:01 pm Post subject: |
|
creaothceann wrote: |
You can, if it accumulates over time.
byuu wrote: |
Right, loop the intro to your favorite game on a real SNES and in the
emulator and you can watch the two drift apart. |
|
But that's.... observing through direct comparison. If you could set up
a situation where you let a test subject play an emulator at 100% speed
for twenty minutes and then let them play at 100.1% speed, and didn't
tell them which was which, and then asked them which they thought was
slower, they'd likely get it wrong 50% of the time.
|
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sat Feb 09, 2008 10:16 pm Post subject: |
|
Again, thank you byuu for explaining all these things :)
Is it possible to use OpenGL renderer in Windows via configuring the system.video variable?
If possible, you should make a quick manual for these "undocumented"
features of bsnes, since average user probably won't be reading this
forum and this thread. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Feb 09, 2008 10:42 pm Post subject: |
|
Quote: |
Is it possible to use OpenGL renderer in Windows via configuring the system.video variable? |
No, the WGL driver isnt done yet. I was writing a Windows port of
byuu's GLX renderer, but never got around to finishing it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 09, 2008 10:52 pm Post subject: |
|
mudlord wrote: |
Quote: |
Is it possible to use OpenGL renderer in Windows via configuring the system.video variable? |
No, the WGL driver isnt done yet. I was writing a Windows port of
byuu's GLX renderer, but never got around to finishing it.
|
That would be awesome of you. Hopefully the D3D scaling bug will be
discovered, but in the meantime OGL might be a good workaround.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 10, 2008 1:04 am Post subject: |
|
byuu wrote: |
It's also worth noting that the subjective differences between
emulation and hardware are certainly far more discernible for me than
for most anyone else. Obviously, the differences I worry about don't
visibly affect any games you guys play -- hence you can't even know
that they are there if you cannot observe them. And that seems good
enough for 99.9% of people. |
True perhaps. I myself am most sensitive to input delay [(which I know, might not necessarily be input
delay, but rather, video delay which cause the impression of input
delay but for the sake of discussion I'll call it "input" delay)
there really is a clear difference in all Snes emulators (or just most
emulators in general) when you're playing SMW or Super Aleste on the
real console and you can see the instantaneous response...Really makes
a difference.
I can't say I'd really care about
all the other possible emulators hiccpus (occasional frame jump or
occasional scratch in sound...)
Personally, if an Snes emulator was:
-Accurate with zero (known) bugs (including on non-commercial demos)
-Obvious stuff like video, sound and input support
-and with no more "input" delay than on the real thing...
Then, I'd consider it equal, from a gameplay perspective, to a real
console...After that, it's just a matter of saying you don't actually
have a bunch of carts lying around and a gray box a few pounds heavy.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Feb 10, 2008 1:18 am Post subject: |
|
byuu wrote: |
Next
up, I've extended the Xv renderer. It can handle RGB15, 16, 24, 32 and
YUY2 formats now. It defaults to RGB ones if you have them. I'd like if
all of them could be tested. RGB15 and 16 should be perfect, 24 and 32
will likely have bad pointer arithmetic, but will hopefully work.
Need to set driver to "xv", and check what you have with "xvinfo". It
defaults to RGB16, then RGB15, then RGB32, then RGB24, then YUY2, then
it gives up and fails. In the future we can see about letting the
encoding be user-selectable. |
I'm not exactly sure what you're asking me to do... am I correct that
I'm setting the system.video to xv? and then in console typing xvinfo
while running, and then giving you that output? If that's the case,
here is my output...
Code: |
X-Video Extension version 2.2
screen #0
Adaptor #0: "NV17 Video Texture"
number of ports: 32
port base: 355
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
depth 24, visualID 0x24
depth 24, visualID 0x25
depth 24, visualID 0x26
depth 24, visualID 0x27
depth 24, visualID 0x28
depth 24, visualID 0x29
depth 24, visualID 0x2a
depth 24, visualID 0x2b
depth 24, visualID 0x2c
depth 24, visualID 0x2d
depth 24, visualID 0x2e
depth 24, visualID 0x2f
depth 24, visualID 0x30
depth 24, visualID 0x31
depth 24, visualID 0x32
depth 24, visualID 0x33
depth 24, visualID 0x34
depth 24, visualID 0x35
depth 24, visualID 0x36
depth 24, visualID 0x37
depth 24, visualID 0x38
depth 24, visualID 0x39
depth 24, visualID 0x3a
depth 24, visualID 0x3b
depth 24, visualID 0x3c
depth 24, visualID 0x3d
depth 24, visualID 0x3e
depth 24, visualID 0x3f
depth 24, visualID 0x40
depth 24, visualID 0x41
depth 24, visualID 0x42
depth 24, visualID 0x43
depth 24, visualID 0x44
depth 24, visualID 0x45
depth 24, visualID 0x46
depth 24, visualID 0x47
depth 24, visualID 0x48
depth 24, visualID 0x49
depth 24, visualID 0x4a
depth 24, visualID 0x22
depth 24, visualID 0x4b
depth 24, visualID 0x4c
depth 24, visualID 0x4d
depth 24, visualID 0x4e
depth 24, visualID 0x4f
depth 24, visualID 0x50
depth 24, visualID 0x51
depth 24, visualID 0x52
depth 24, visualID 0x53
depth 24, visualID 0x54
depth 24, visualID 0x55
depth 24, visualID 0x56
depth 24, visualID 0x57
depth 24, visualID 0x58
depth 24, visualID 0x59
depth 24, visualID 0x5a
depth 24, visualID 0x5b
depth 24, visualID 0x5c
depth 24, visualID 0x5d
depth 24, visualID 0x5e
depth 24, visualID 0x5f
depth 24, visualID 0x60
depth 24, visualID 0x61
depth 24, visualID 0x62
depth 24, visualID 0x63
depth 24, visualID 0x64
depth 24, visualID 0x65
depth 24, visualID 0x66
depth 24, visualID 0x67
depth 24, visualID 0x68
depth 24, visualID 0x69
depth 24, visualID 0x6a
depth 24, visualID 0x6b
depth 24, visualID 0x6c
depth 24, visualID 0x6d
depth 24, visualID 0x6e
depth 24, visualID 0x6f
depth 24, visualID 0x70
depth 24, visualID 0x71
number of attributes: 3
"XV_SET_DEFAULTS" (range 0 to 0)
client settable attribute
"XV_ITURBT_709" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
"XV_SYNC_TO_VBLANK" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
maximum XvImage size: 2046 x 2046
Number of image formats: 4
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
Adaptor #1: "NV05 Video Blitter"
number of ports: 32
port base: 387
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
depth 24, visualID 0x24
depth 24, visualID 0x25
depth 24, visualID 0x26
depth 24, visualID 0x27
depth 24, visualID 0x28
depth 24, visualID 0x29
depth 24, visualID 0x2a
depth 24, visualID 0x2b
depth 24, visualID 0x2c
depth 24, visualID 0x2d
depth 24, visualID 0x2e
depth 24, visualID 0x2f
depth 24, visualID 0x30
depth 24, visualID 0x31
depth 24, visualID 0x32
depth 24, visualID 0x33
depth 24, visualID 0x34
depth 24, visualID 0x35
depth 24, visualID 0x36
depth 24, visualID 0x37
depth 24, visualID 0x38
depth 24, visualID 0x39
depth 24, visualID 0x3a
depth 24, visualID 0x3b
depth 24, visualID 0x3c
depth 24, visualID 0x3d
depth 24, visualID 0x3e
depth 24, visualID 0x3f
depth 24, visualID 0x40
depth 24, visualID 0x41
depth 24, visualID 0x42
depth 24, visualID 0x43
depth 24, visualID 0x44
depth 24, visualID 0x45
depth 24, visualID 0x46
depth 24, visualID 0x47
depth 24, visualID 0x48
depth 24, visualID 0x49
depth 24, visualID 0x4a
depth 24, visualID 0x22
depth 24, visualID 0x4b
depth 24, visualID 0x4c
depth 24, visualID 0x4d
depth 24, visualID 0x4e
depth 24, visualID 0x4f
depth 24, visualID 0x50
depth 24, visualID 0x51
depth 24, visualID 0x52
depth 24, visualID 0x53
depth 24, visualID 0x54
depth 24, visualID 0x55
depth 24, visualID 0x56
depth 24, visualID 0x57
depth 24, visualID 0x58
depth 24, visualID 0x59
depth 24, visualID 0x5a
depth 24, visualID 0x5b
depth 24, visualID 0x5c
depth 24, visualID 0x5d
depth 24, visualID 0x5e
depth 24, visualID 0x5f
depth 24, visualID 0x60
depth 24, visualID 0x61
depth 24, visualID 0x62
depth 24, visualID 0x63
depth 24, visualID 0x64
depth 24, visualID 0x65
depth 24, visualID 0x66
depth 24, visualID 0x67
depth 24, visualID 0x68
depth 24, visualID 0x69
depth 24, visualID 0x6a
depth 24, visualID 0x6b
depth 24, visualID 0x6c
depth 24, visualID 0x6d
depth 24, visualID 0x6e
depth 24, visualID 0x6f
depth 24, visualID 0x70
depth 24, visualID 0x71
number of attributes: 2
"XV_SET_DEFAULTS" (range 0 to 0)
client settable attribute
"XV_SYNC_TO_VBLANK" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 2046 x 2046
Number of image formats: 5
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x3
guid: 03000000-0000-0010-8000-00aa00389b71
bits per pixel: 32
number of planes: 1
type: RGB (packed)
depth: 24
red, green, blue masks: 0xff0000, 0xff00, 0xff |
Hopefully that was what you're looking for. For the record, if that was
what I was supposed to do, it makes audio hella choppy. Much moreso
than the opengl setting.
Also haven't had a problem yet with the random phantom keypress, but
I'll keep testing and let you know if that changes.
EDIT: Never really noticed any audio lag, but now I do, since we're on
the subject of timing and stuff. Seems like I get less audio lag if I
use openal instead of oss, but oss sounds much nicer... there may not
be a difference between them anyway, my ears may just think they hear a
difference.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 10, 2008 12:19 pm Post subject: |
|
Okay,
so I've been planning how I want to rewrite the video system. I'm going
to remove the colorspace conversion (which we'll call rastering) and
filtering (HQ2x, etc) from the core, and place them into a separate
library. The idea is that these things have little to do with actual
emulation, so they don't belong in the core.
I've spent the last seven hours planning how to do this. Essentially, I really
don't want to put all of this into ruby, the video/audio/input driver
library, because then it would have to support virtually endless color
formats and conversions. For instance, the SNES outputs BGR555, which
every single filter would have to support, and then every video driver
would have to support. It's that, or I write up colorspace conversion
functions that run on data to get them to standardized format. The only
globally-compatible format would be RGB888, which would make colorspace
conversion impossible (can't use a lookup table on RGB888, real-time
adjustments would be maddeningly slow.) I could only do that with SNES
-> RGB888 -> Filter -> Output; meaning ruby would have to have
built-in support to upscale the color and apply raster adjustments. But
then the adjustments would be unavailable for 24-bit color output. Ugly.
So, all of that in mind, this is the best I could come up with:
- BGR555 is native to the SNES only. There's no justification for a
general purpose library to support such a bastardized format. It
belongs in a separate library.
- Filters can still directly output to video memory for most drivers by
using the handle provided by ruby::video.lock(). I can avoid having to
support every last format in existence by just leaving the filters as I
have them now: BGR555 input to lookuptbl[filtered input] -> output.
I can stick these filters along with the colorspace lookup table into
the same library.
- ruby can and should be kept simple, supporting only one video format.
So essentially, I wouldn't be changing how bsnes worked. There wouldn't
be additional levels of buffer conversions slowing anything down to
many ruby a general purpose filtering system. I'd just be moving the
src/snes/video filtering stuff out to src/lib/libfilter.
Now, one big problem arises: what output format should ruby support?
Right now, it supports RGB565. This works great for the SNES, but might
not be so nice for other systems. And even SNES could benefit from
RGB888 output. The gamma curve for instance would look a hell of a lot
smoother. The darkest colors wouldn't be crushed completely as they are
now. It would also give much finer grained control over the brightness
/ contrast settings. But the problem is, more color depth means more
bandwidth to transfer to the video card. It will result in a slight
slowdown in bsnes. I can't gauge how much until I add it, but I'd
estimate about 3-5% or so? The Xv filter would be hit even harder, as
it would be forced to do RGB888->RGB565->YUY2 conversion, to be
able to utilize the fast lookup tables. Probably 5-10% speed hit there.
So, informal poll. Would you rather I make the final output use RGB888,
which gives slightly improved color adjustments and is better suited
for a general purpose library; or make it use RGB565, which is faster
and ~95% as good?
Supporting both would be possible, but a ton of work. Maybe in the
future, but I'd like to focus on just one for now.
Quote: |
But that's.... observing through direct comparison ... they'd likely get it wrong 50% of the time. |
Absolutely correct :)
Quote: |
If
possible, you should make a quick manual for these "undocumented"
features of bsnes, since average user probably won't be reading this
forum and this thread. |
Yeah, would be a good idea to do eventually.
Quote: |
Hopefully
that was what you're looking for. For the record, if that was what I
was supposed to do, it makes audio hella choppy. Much moreso than the
opengl setting. |
Ah, you have two adaptors. My code only scans the first adaptor that
supports drawing to the screen. I'll have to adapt it further. I also
found out that bits_per_pixel is unreliable, so I'll have to test each
color mask to find the best modes.
Quote: |
Seems
like I get less audio lag if I use openal instead of oss, but oss
sounds much nicer... there may not be a difference between them anyway,
my ears may just think they hear a difference. |
OSS has lower latency. Lower latency sounds better, but runs out of
buffering much easier. I get crackling on occasion with OSS myself,
even though I can run at 2x full speed.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Feb 10, 2008 12:52 pm Post subject: |
|
My
vote goes out to RGB888, because of the quality argument. In my opinion
bsnes has always been about accuracy and quality, and most processors
that can run it at full speed consistently can do so with a fair bit of
leeway anyway.
By the way, I'm curious, is
BGR555->RGB888 as simple as swizzling the bits and shifting them
left three places? (i.e. output.rgb = input.bgr << 3 to merge
some GLSL and C++ into pseudo-code) Or is there more to it than that? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 10, 2008 12:58 pm Post subject: |
|
Here is the proper way to convert RGB565 to RGB888:
Code: |
p = ((p & 0x001f) << 3) + ((p & 0x001c) >> 2)
+ ((p & 0x07e0) << 5) + ((p & 0x0600) >> 1)
+ ((p & 0xf800) << 8) + ((p & 0xe000) << 3); |
The right side is important. It's what makes white 0xffff -> white
0xffffff, rather than white 0xffff -> light gray w/green tint
0xf8fcf8, that you see in most emulators and hardware convertors.
Obviously, I would be using a lookup table, so it would just be:
The overhead comes solely from having to send twice the video data to
the video card for each frame. The reason it won't be twice as slow is
because most of the overhead in bsnes comes from other places.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Feb 10, 2008 1:04 pm Post subject: |
|
A friendly reminder, think for 60 sec about the future controllers like the super scope when you are designing this, k? |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Feb 10, 2008 1:10 pm Post subject: |
|
I'd also vote for RGB888. It's supposed to be a general-purpose library, after all.
byuu wrote: |
Quote: |
Seems
like I get less audio lag if I use openal instead of oss, but oss
sounds much nicer... there may not be a difference between them anyway,
my ears may just think they hear a difference. |
OSS has lower latency. Lower latency sounds better, but runs out of
buffering much easier. I get crackling on occasion with OSS myself,
even though I can run at 2x full speed.
|
Even if you give bsnes more CPU priority?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sun Feb 10, 2008 1:20 pm Post subject: |
|
My vote goes for RGB888 as well |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Sun Feb 10, 2008 1:34 pm Post subject: |
|
Hi folks,
I have just tested 0.028.1 under Fedora 8 and I have discovered the following:
1. With opengl video driver, the window is not cleaned up (was mentioned here before).
2. The problem with hogging the CPU when idle seems to be back. What
even funnier, it eats more CPU power than when actually emulating the
console.
3. OpenAL audio driver constantly claims that open /dev/[sound/]dsp is
busy. Not sure why, as it is most certainly not. What is more,
tremulous, which also uses openal for sound, works perfectly fine.
4. Last, but not least, could you please integrate my makefile patch
adding the destdir? Here is the most recent version:
Code: |
--- src/Makefile.makefilefix 2008-02-10 12:11:27.000000000 +0100
+++ src/Makefile 2008-02-10 12:14:25.000000000 +0100
@@ -270,8 +270,8 @@
$(strip $(cpp) $(call mkbin,../bsnes) $(objects) $(link))
install:
- install -D -m 755 ../bsnes $(prefix)/bin/bsnes
- install -D -m 644 data/bsnes.png $(prefix)/share/icons/bsnes.png
+ install -D -m 755 ../bsnes $(DESTDIR)$(prefix)/bin/bsnes
+ install -D -m 644 data/bsnes.png $(DESTDIR)$(prefix)/share/pixmaps/bsnes.png
clean:
-@$(call delete,obj/*.$(obj)) |
It is necessary for packaging, and if you merge it, I won't have to
update it every bsnes release. Pretty please with sugar on top
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Feb 10, 2008 1:52 pm Post subject: |
|
byuu wrote: |
Here is the proper way to convert RGB565 to RGB888:
Code: |
p = ((p & 0x001f) << 3) + ((p & 0x001c) >> 2)
+ ((p & 0x07e0) << 5) + ((p & 0x0600) >> 1)
+ ((p & 0xf800) << 8) + ((p & 0xe000) << 3); |
The right side is important. It's what makes white 0xffff -> white
0xffffff, rather than white 0xffff -> light gray w/green tint
0xf8fcf8, that you see in most emulators and hardware convertors.
|
Thank you, I've wondered about this for some time. If you would, what's
the relationship between BGR555 and RGB565? Are they very similar? (to
be fair I could probably manage to look this up, but I have had some
trouble finding concrete specifications and conversion code)
Last edited by Verdauga Greeneyes on Sun Feb 10, 2008 2:02 pm; edited 1 time in total
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Sun Feb 10, 2008 2:28 pm Post subject: |
|
byuu,
is it any way for core to generate the separate color strobes
(channels), so the conversion would be free of that masking strip
operation?
Besides, as i noticed the native data
for SNES is RGB555, not RGB565 so i think it's better not to prepack
data in the core if it's possible of course. The output plugin better
work with raw data:
Code: |
struct pixel
{
unsigned R; //5-bit data
unsigned G; //5-bit data
unsigned B; //5-bit data
} |
The best thing of it you can apply effects inline as well as format conversion:
for example RGB555 -> RGB888 conversion:
Code: |
unsigned FINAL_R = (pixel.R << 3) | (pixel.R >> 2);
unsigned FINAL_G = (pixel.G << 3) | (pixel.G >> 2);
unsigned FINAL_B = (pixel.B << 3) | (pixel.B >> 2); |
so each plugin (read PLATFORM, CONSOLE) can choose what is best suited it!
then do effect post-processing (or do the equal hardware texture processing) and finally output:
for example RGB888 output:
Code: |
unsigned color = (FINAL_R << R_SHIFT) | (FINAL_G << G_SHIFT) | (FINAL_B << B_SHIFT); |
or:
Code: |
*out++ = FINAL_R;
*out++ = FINAL_G;
*out++ = FINAL_B;
*out++ = FINAL_R;
*out++ = FINAL_G;
*out++ = FINAL_B;
|
without alpha channel...
i'd highly recommend to separate channels processing to avoid useless format repacking operations.
_________________
quake2xp audio engineer
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sun Feb 10, 2008 2:32 pm Post subject: |
|
I
vote for RGB565, if it doesn't look 100% perfect, I'm fine with that;
as long as the speed is that much closer to a real SNES, that's okay.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Feb 10, 2008 2:54 pm Post subject: |
|
neo_bahamut1985 wrote: |
I
vote for RGB565, if it doesn't look 100% perfect, I'm fine with that;
as long as the speed is that much closer to a real SNES, that's okay. |
Hmm, I'm not sure what you're saying here. If the conversion doesn't
drop your fps below 60 for NTSC or 50 for PAL there shouldn't be any
difference in speed or latency. Correct me if I'm wrong, byuu; the only
theoretical increase in latency I can think of would be due to a
lengthier conversion process in the graphics hardware, if that even
makes sense.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 10, 2008 2:57 pm Post subject: |
|
Since
neither of them impact on internal emulation accuracy...Hm, depends
just how faster RGB565 is...Unless it's by a significant margin and
make a 10+fps difference, I'd vote 888. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Feb 10, 2008 3:03 pm Post subject: |
|
I agree with willow if his system is possible
i also agree with henke37 that this is also the time to think about
allowing things like lightguns to interact with the videostream. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Feb 10, 2008 4:40 pm Post subject: |
|
byuu wrote: |
New WIP posted, Linux only. Need all the testers I can get on this one, please.
First and foremost, I spent about four hours figuring out how to
disable the screensaver on Linux. I tried XSetScreensaver,
XResetScreenSaver, XScreenSaverSuspend, DPMSDisable, synthetic
XSendEvent, and all of them failed miserably. I ended up getting it to
work with only one thing: XTestFakeKeyEvent. I send a fake keypress
every ~20 seconds. The key send is keycode (not keysym) 255. I don't
know of many 256-key keyboards, so I think that should be fine. |
Seems to be working fine here. Been running it for a while and no other application seems to be affected.
Will edit the post later and see if it prevented the screensaver from starting or not (using XScreenSaver).
EDIT: Well, it seems to prevent the screensaver alright, left it
running for ~30-40 mins and screensaver should kick in after 10 mins
(though I think it fails sometimes so I'll test again later).
byuu wrote: |
Next
up, I've extended the Xv renderer. It can handle RGB15, 16, 24, 32 and
YUY2 formats now. It defaults to RGB ones if you have them. I'd like if
all of them could be tested. RGB15 and 16 should be perfect, 24 and 32
will likely have bad pointer arithmetic, but will hopefully work.
Need to set driver to "xv", and check what you have with "xvinfo". It
defaults to RGB16, then RGB15, then RGB32, then RGB24, then YUY2, then
it gives up and fails. In the future we can see about letting the
encoding be user-selectable. |
I don't know how to test them all, but it seems like the 'nvidia' driver and/or my card only supports YUV2.
Code: |
$ xvinfo |grep YUY
id: 0x32595559 (YUY2)
id: 0x32595559 (YUY2)
$ xvinfo |grep RGB
type: RGB (packed)
$ xvinfo |grep rgb
|
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Feb 10, 2008 9:52 pm Post subject: |
|
vEX, just adjust it so the screen saver occurs after like 10 seconds and then it's much less time consuming to test lol.
_________________
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. |
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Feb 10, 2008 10:27 pm Post subject: |
|
franpa wrote: |
vEX, just adjust it so the screen saver occurs after like 10 seconds and then it's much less time consuming to test lol. |
I just leave bsnes running while I'm not using the computer, to lazy to
mess with all that. I would just end up forgetting setting it back to
10 minutes.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 5:07 am Post subject: |
|
RGB888:
- Verdauga Greeneyes
- creaothceann
- rayno
- Snark
RGB565:
- neo_bahamut1985
Alright, I will convert the primary to RGB888. The filters will stay
BGR555, only the final output will be converted. I will also work on an
option for RGB565 in the future, hopefully by v0.030 at the latest.
Thank you for the input.
Quote: |
A friendly reminder, think for 60 sec about the future controllers like the super scope when you are designing this, k? |
It'll get there, eventually.
Quote: |
Even if you give bsnes more CPU priority? |
Didn't try, but most likely yes.
Quote: |
It
is necessary for packaging, and if you merge it, I won't have to update
it every bsnes release. Pretty please with sugar on top |
Oh, did I forget that again? Sorry, I'm pretty bad at adding some of these changes. Bad memory and all that.
Quote: |
1. With opengl video driver, the window is not cleaned up (was mentioned here before) |
Turns out, GTK+'s gtk_drawing_area widget won't detect exposure events
when a child window is covering it, and I can't get the child messages
to pass back to the parent. So, at this time, the only chance I have to
check for XEvents is during refresh(), where I'm already redrawing the
window contents anyway. I don't have any solution to this problem.
Does anyone know if there's a way to specify an auto-paint brush, similar to Windows, for Xlib windows?
Quote: |
2.
The problem with hogging the CPU when idle seems to be back. What even
funnier, it eats more CPU power than when actually emulating the
console. |
Very odd, the usleep() call is still there. Maybe try increasing it some?
Quote: |
3. OpenAL audio driver constantly claims that open /dev/[sound/]dsp is busy. |
No idea, it works for everyone else ...
Quote: |
Thank you, I've wondered about this for some time. If you would, what's the relationship between BGR555 and RGB565? |
The ordering of pixels. Pretend each character represents one bit:
RGB565 = rrrrr gggggg bbbbb
BGR555 = 0 bbbbb ggggg rrrrr
Essentially, you just shuffle around the bits. I can do this with a
lookup table. I can also convert BGR555 -> RGB888 with a lookup
table. It's the reverse (RGB888->lower) that's a real PITA.
Quote: |
for example RGB555 -> RGB888 conversion: |
That would be horrendously slow, and offer no real advantage. I would
have to repack the data before sending to the video card, anyway.
Quote: |
I don't know how to test them all, but it seems like the 'nvidia' driver and/or my card only supports YUV2. |
I researched the issue. The NV17 Video Texture adaptor (YUV only) is
supported on all nVidia GPUs. The NV05 Video Blitter (with RGB support)
is only supported by older GPUs. Specifically, an nVidia Linux driver
developer stated that the hardware for it was removed from the 8800
series GPUs. They're removing more and more 2D support with each new
GPU. Nothing we can do about it, but use OpenGL.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 7:09 am Post subject: |
|
Okay, I've ported the GLX driver to RGB888. Pretty easy, really.

Let's rule out placebo, this time. I'm not going to tell you which row
is which. Perhaps I went with the traditional old, new; or perhaps I
figured you might think that and switched the rows. I'm not telling ;)
Note that OpenGL is smart enough to fill in the low bits. The difference will be more visible on APIs that do not.
Let me know which one you like more. Top row or bottom row.
I shouldn't have to tell anyone this, but you obviously need to be
running your desktop at >=24bpp if you expect to see a difference.
Next, you'll probably want to save the image and zoom in two times to see the color difference better.
Another thing to note is that the human eye can spot the differences in
green far easier than in red, and in red easier than in blue. As such,
the right-most picture is a really good one to look closely at.
As for the speed impact, I went from ~119fps to ~113fps. A ~5% speed
loss. But no worries, I'll probably be making it an option to choose
one or the other within the next two official releases or so.
EDIT: dear god ... SDL video ported. At 2x scale, SDL gets ~75fps with
RGB565, and ~110(!!)fps with RGB888. I'm speechless.
EDIT2: finished porting all six video drivers.
Performance differences from RGB565 -> RGB888:
GLX: 119fps -> 113fps
SDL: 75fps -> 110fps
Xv: 114fps -> 110fps
Direct3D: 120fps -> 120fps
DirectDraw: 121fps -> 120fps
GDI: 84fps -> 94fps
It would seem some APIs work much better at 32-bpp than at 16-bpp.
Overall, with the fallback drivers being so much faster, I think it's
worth it to take small speed hits to Linux GLX and Xv. Looks like
Windows users will be completely unaffected by this change, speed-wise.
So, free better color reproduction.
Last edited by byuu on Mon Feb 11, 2008 8:13 am; edited 1 time in total |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Mon Feb 11, 2008 8:08 am Post subject: |
|
The top one is the new one. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 8:14 am Post subject: |
|
Hmm,
new page. At the end of the previous page, I have a comparison picture
between RGB565 and RGB888 output. If you have a moment -- please go
back, take a look at it, and post which version you think looks better.
Executive summary is that RGB888 runs at the same speed for ~99% of
Windows users. It's ~3% slower for Linux users using hardware
accelerated drivers. And it's ~10-20% faster for those forced to use
the fallback GDI and SDL drivers.
Given this, I see no reason to even add RGB565 support now.
Quote: |
The top one is the new one. |
Is it? Or is it not? Which one looks better to you?
|
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Mon Feb 11, 2008 8:36 am Post subject: |
|
grass looks the tiniest bit nicer on the top row, other than that, i can't really tell.
maybe some tales pics, or something else with "more."
_________________
 |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Mon Feb 11, 2008 8:43 am Post subject: |
|
Actually,
no, I'm wrong. I was thinking for some reason the new output would look
more vibrant, but rereading I think what's actually happening is that
now it won't look so overly contrasted in optimal mode. If that's the
case (which would be good, since I always change it from the optimal
preset... makes the darks too dark for me), then not only was I totally
wrong in choosing the top one as being the new one, but it also means
that the optimal preset would actually mean something to me now. Yay
for vibrant colors without things getting washed out!
Assuming that now I'm right, of course.
EDIT: To clarify, this means that I think the bottom one is "better",
though I wouldn't know for sure until I saw some screenshots from
darker games (Castlevania IV, perhaps?)
Last edited by DancemasterGlenn on Mon Feb 11, 2008 9:37 am; edited 1 time in total |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Feb 11, 2008 9:29 am Post subject: |
|
Grass
looks "greener" in top image. Regardless of the fact I "prefer" the top
one (for all we know I might have thought red grass looks nicer but
what I prefer is irrelevant here) the bottom one seems closer to
console/TV...Though I might be wrong.
Last edited by Snark on Mon Feb 11, 2008 9:42 am; edited 1 time in total |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 11, 2008 9:32 am Post subject: |
|
NEITHER! It's a trap!
No really, I strained to see some differences, but they're so minor I
can't really profess a preference. Whatever RGB888 is, it works for me. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 10:00 am Post subject: |
|
I'd
say the top one is generally the tiniest bit more vibrant, but I really
don't know how it's supposed to look, having never played the Zelda
game on my SNES
But yes, both look fine to me; not that I've ever claimed to be very
sensitive to graphical differences, I'm always amazed when people can
spot a difference between different drivers. I'm just glad the
performance differences are in favor of the new mode. Perhaps the
slight differences from version to version will accumulate over time
though, and we'll be able to look back on 0.028 and say "Oh yeah, it's
gotten so much more refined."
Also, thanks again for your explanation on the different colour modes. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 10:14 am Post subject: |
|
Okay, I've posted a new WIP. Windows binary included.
Changes:
- Video output uses RGB888, rather than RGB565
- Removed RGB modes from Xv. They're a major hassle, I can't test them,
and they didn't even work right. Maybe I'll try again in the future
- $(DESTDIR) added to Makefile
- Increased Linux usleep idle delay from 20 to 20,000, so bsnes appears to consume 0% CPU time when idle
- Started moving src/snes/video to src/lib/libfilter. So far, only the colortable has been moved over
I held off on actually using libfilter's colortable. I'm intending to
break things completely here very shortly by eliminating src/snes/video
stuff, but I wanted to get a WIP out before doing so, so that people
could mess around with RGB888.
Speed is going to be a little slower for Linux users who use the GLX or
Xv video driver. Very sorry about this. If you need to, stick with
v0.028 official for the time being.
---
By the way, RGB888 is the bottom row. Thanks for playing. RGB888
doesn't make bright colors darker or vice versa, it avoids rounding
errors. It has the biggest effect on near-black colors, as before they
were getting crushed badly by the exponential curve gamma adjust. But
don't be fooled: really dark colors will still be much harder to see
than with the gamma curve turned off.
Anyway, if you liked the top row more, then just adjust the settings slightly on the raster settings tab :)
EDIT: Neat, fglrx driver goes from 57.5fps to 59.5fps with GLX. YMMV. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 11:18 am Post subject: |
|
byuu wrote: |
The ordering of pixels. Pretend each character represents one bit:
RGB565 = rrrrr gggggg bbbbb
BGR555 = 0 bbbbb ggggg rrrrr
Essentially, you just shuffle around the bits. I can do this with a lookup table. |
Hmm, seems I have another question after all. Since green uses 6 bits
in RGB565, just shuffling the bits around would leave the lowest bit
always unset.. In other words, shouldn't a conversion use something
like "output.g = round(input.g*63.0/31.0)" (int(input.g*63.0/31.0 +
0.5)) for green? What are you using for BGR555->RGB888?
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Feb 11, 2008 12:53 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Hmm,
seems I have another question after all. Since green uses 6 bits in
RGB565, just shuffling the bits around would leave the lowest bit
always unset.. <......> What are you using for BGR555->RGB888? |
I'm not byuu but i can say for sure RGB555 -> RGB565 conversion give
more color aliasing then RGB555 -> RGB888 because of the
significance of that single green bit. Either value you set it, it's
would be very rough. If you still want to do the most correct
conversion then just set the lowest green bit to the same value in
highest bit.
You should know that modern PC hardware works best with 24 (32) bit
colors, and ANY video accelerator expand images to 24 data while
process them.
byuu wrote: |
That
would be horrendously slow, and offer no real advantage. I would have
to repack the data before sending to the video card, anyway. |
Colortables consumes the memory and cache resources, plus you can win
on actual filter code as you do not unpack expansive RGB565
For what i think now you perfom double repacking operation
RGB555 -> RGB565 -> RGB888
Correct me if i'm wrong.
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 1:09 pm Post subject: |
|
To expand a color to have more bits, you just mirror the bitstream.
Let's say you want 5-bits to 8-bits. Your five bits are 12345. So to
expand that, you'd just copy the top bits and end up with 12345123. Six
bits would just be 123451. Note of course that a bit can only be 0 or
1, this is just an example, and the numbers represent the bit indexes.
10110 would become 101101011010 after 5->12-bit expansion. Whereas a
poorly written driver would expand that to 101000000000. In other
words, it would just store 0's after the number you have. This makes
whites appear gray.
The reason 8-bit color matters in bsnes is because of my color
adjustment filters. I'm not just mirroring up the bottom three bits.
When adjusting eg the brightness, extra bits result in less rounding,
as there is more precision. This in effect means that the raster
settings are more fine-grained now.
As far as how bsnes works internally ...
The PPU outputs a BGR555 image. The filter then reads this, computes
new values, also in BGR555, then it indexes the result into a 15-bit
table and pulls out a 24-bit RGB888 result that gets written directly
to the video card. Could I make the SNES internally compute as RGB555
or RGB565 and then output in that format with no need for a lookup
table? Sure, but that's not how the hardware works. I'll take a 2fps
speed hit to properly represent how the hardware works. Sum up all of
these "stubbornness" compromises over the past three years, and it's
little wonder why bsnes is so slow :P
Quote: |
I'm
not byuu but i can say for sure RGB555 -> RGB565 conversion give
more color aliasing then RGB555 -> RGB888 because of the
significance of that single green bit. |
If you're upconverting FROM RGB555 to a higher bit depth, how exactly can RGB565 have more
"aliasing" than RGB888? There's no data being truncated, so the end
result is the same. Both RGB565 and RGB888 can be converted back to
RGB555 with no loss of the original information.
The best I can figure is that you mean RGB565 would be quicker to round
a value than RGB888, by way of the latter having more bits to work
with. Which is fairly obvious.
But since our source data only has five bits per channel, the only
thing we can do is repeat the pattern to fill in the lower bits,
mirroring up to the native resolution of our output target. It makes no
difference how many bits per channel our output target has, just that
we mirror enough bits to fill all of them.
Last edited by byuu on Mon Feb 11, 2008 1:28 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 1:25 pm Post subject: |
|
byuu wrote: |
To expand a color to have more bits, you just mirror the bitstream.
Let's say you want 5-bits to 8-bits. Your five bits are 12345. So to
expand that, you'd just copy the top bits and end up with 12345123. Six
bits would just be 123451. Note of course that a bit can only be 0 or
1, this is just an example, and the numbers represent the bit indexes.
10110 would become 101101011010 after 5->12-bit expansion. Whereas a
poorly written driver would expand that to 101000000000. In other
words, it would just store 0's after the number you have. This makes
whites appear gray. |
Thanks guys, I had no idea. Is this a natural consequence of binary
arithmetic? I did some tests with what I suggested before
(round([input]*255/31)) and I get the same thing as the mirroring
you're suggesting. Do you know of any resources I could read to learn
more about this? I'm not sure what to search for..
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Feb 11, 2008 1:32 pm Post subject: |
|
Nice image you got there byuu, after just looking at it, I didn't see any differences.
Now I'm not going to go save some random image, ew, what a waste, I
just used my browser's zoom into image feature. I zoom in one time, and
now a difference is noticeable.
I'm not going to claim I'm an expert, especially since my eyesight
isn't the greatest, but difference in green? I don't really notice one.
However the edges in the top row seem to be darker than the images in
the bottom row.
_________________
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 Feb 11, 2008 4:27 pm; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 11, 2008 1:43 pm Post subject: |
|
I don't know of any articles on the subject.
It's fairly straight-forward, though.
If you want pure white, you have "11111", so you want "11111111". Not "11111000" (light gray).
You can't expand with the low bits always being "1"s, because then if
you want black, and you had "00000", you'd end up with "00000111" (dark
gray).
It's similar to fractions with the decimal system, really.
1/3 = 0.33333 if you only had five numbers of precision. It would
expand to 0.33333333 if you had eight. Not to 0.33333000, not to
0.33334000.
Quote: |
Nice image you got there byuu, after just looking at it, I didn't see any differences. |
Sorry, the difference really is minimal. Converting from
RGB888->RGB555 is much more dramatic. But upconverting from
RGB555->RGB888 is basically filling in information that wasn't there
to begin with. It's the same as with interpolation and 96KHz audio.
This only benefits the precision of color adjustments, and even then,
16-bits is already reaching the limits that the human eye can reliably
discern anyway. 24-bits is more colors than the human eye is capable of
discerning at all.
If you want to see one of the most extreme examples, try looking at a
gradient fade in 24-bits, and again in 16-bits.

Of course, since the SNES hardware wasn't capable of more than 15-bits
of color information, you'll never this much of a difference in bsnes.
Last edited by byuu on Mon Feb 11, 2008 1:59 pm; edited 1 time in total
|
|
Bisqwit Rookie

Joined: 02 Aug 2004
Posts: 15
Location: Kerava, Finland
|
Posted: Mon Feb 11, 2008 1:49 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Thanks guys, I had no idea. Is this a natural consequence of binary arithmetic? |
Yes.
Extending ABCDE to 8 bits by producing ABCDE000 is equivalent to multiplying with 8 (1000 binary).
However, doing so means that while 0 produces 0, 31 produces 248, not 255.
The proper method is to scale 31 to 255, not to 248.
When we get 248, we were actually multiplying the value with 248/31 (which is 8).
We should really be multiplying with 256/31. (Due to rounding down. 255/31 if we rounded to nearest integer.)
In binary, 256/31 is 1000.0100001000010000100<...>.
So by multiplying ABCDE with 1000.0100001000010000100, we get:
Code: |
ABCDE.
* 1000.0100001000010000...
----------------------------
= ABCDE000.
+ 00000ABC.DE
+ 00000000.00ABCDE
+ 00000000.0000000ABCDE
----------------------------
= ABCDEABC.DEABCDEABCDEABCDE... |
We are not interested in the decimals, so we round down and get ABCDEABC.
Which is the correct value: now 31 becomes 255, 0 becomes 0, 15 becomes 123, 16 becomes 132, and so on.
Similarly, for 6 to 8 bits conversions, the factor is 256/63
(100.00010000010000010000 in binary), again the same periodical pattern.
It just works like that :)
When we multiply with 1000.0100001000010000<...> but we're only
interested of the rounded-down integer part, we're doing the bit shift
operations byuu described:
― As those who have handled integer math know, multiplying A with 1101
would be equivalent to (A<<3) | (A << 2) | (A << 0).
― When we also handle decimals, we know that multiplying A with 1.001
is equivalent to (A << 0) | (A >> 3).
― So, multiplying A with 1000.01 is equivalent to: (A << 3) | (A >> 2).
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Feb 11, 2008 2:09 pm Post subject: |
|
byuu wrote: |
If you're upconverting FROM RGB555 to a higher bit depth, how exactly can RGB565 have more "aliasing" than RGB888? |
Better to feel this.. Look,
6 bit:
00000 -> 000000
00100 -> 001000
00111 -> 001110
01111 -> 011110
10000 -> 100001
11111 -> 111111
8 bit:
00000 -> 00000000
00100 -> 00100001
00111 -> 00111001
01111 -> 01111011
10000 -> 10000100
11111 -> 11111111
Now you see? It's like 5.1 and 5.3 point comparison. 6bit have higher
color grades, higher "steps". The ideal expansion would be 10bit,
15bit, 20bit result i.e. full mirroring that gives no parasite "tail".
You need to compare not 6 and 8 bits but 1 and 3! And 1bit and 3bit
precision makes huge difference.
BTW, check how the "Show Statusbar" option works now. Is it have new behaviour in 0.028.0X?
_________________
quake2xp audio engineer
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 3:14 pm Post subject: |
|
Thanks for writing that out, Bisqwit; it's mostly clear to me now.
Bisqwit wrote: |
We should really be multiplying with 256/31. (Due to rounding down. 255/31 if we rounded to nearest integer.) |
I'm having some trouble seeing how this works.. how do we know that 256
is enough to ensure rounding down works, and small enough that it
doesn't lead to rounding up? (I mean, just looking at the binary result
of 256/31 it's a nice regular pattern where 255/31 and 257/31 aren't,
but can we predict this?) Am I overcomplicating things?
|
|
Bisqwit Rookie

Joined: 02 Aug 2004
Posts: 15
Location: Kerava, Finland
|
Posted: Mon Feb 11, 2008 3:20 pm Post subject: |
|
Verdauga Greeneyes wrote: |
how
do we know that 256 is enough to ensure rounding down works, and small
enough that it doesn't lead to rounding up? (I mean, just looking at
the binary result of 256/31 it's a nice regular pattern where 255/31
and 257/31 aren't, but can we predict this?) Am I overcomplicating
things? |
That, I don't know, sorry.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 3:29 pm Post subject: |
|
That's fine, thanks for your help!  |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Feb 11, 2008 4:03 pm Post subject: |
|
Verdauga Greeneyes wrote: |
I'm
having some trouble seeing how this works.. how do we know that 256 is
enough to ensure rounding down works, and small enough that it doesn't
lead to rounding up? (I mean, just looking at the binary result of
256/31 it's a nice regular pattern where 255/31 and 257/31 aren't, but
can we predict this?) Am I overcomplicating things? |
It's fairly easy 
Integer math always rounds down.
To ensure the math is correct you should perform all operations in strict order:
new_value = value * NEW_HIGHEST_VALUE / OLD_HIGHEST_VALUE;
and yes, you right about 255 and 31 as it's a comlete bit pattern
without undefined states. So we can simply copy higher bits to the
lower bits of the new "extended" number. This is not a magic trick but
the binary multiplication logic that follow the above formula in most
simplified way.
_________________
quake2xp audio engineer
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Feb 11, 2008 4:18 pm Post subject: |
|
Bisqwit wrote: |
?
As those who have handled integer math know, multiplying A with 1101
would be equivalent to (A<<3) | (A << 2) | (A << 0).
? When we also handle decimals, we know that multiplying A with 1.001
is equivalent to (A << 0) | (A >> 3).
? So, multiplying A with 1000.01 is equivalent to: (A << 3) | (A >> 2). |
Only if multiplying an N-bit value by a factor where the 1 bits have no
fewer than N-1 zeros between them, otherwise you must use add, not
bitwise or (|).
_willow_ wrote: |
6bit
have higher color grades, higher "steps". The ideal expansion would be
10bit, 15bit, 20bit result i.e. full mirroring that gives no parasite
"tail". |
Another solution is video hardware that expanded components by adding
zeros rather than repeting MSBs. It'd result in a very slightly darker
image, which could be a problem if combining graphics of several depths.
Somewhat related, consider what happens when you go from 5 to 6 to 8 by
repeating the MSBs, versus 5 straight to 8:
Code: |
5->6->8: ABCDE->ABCDEA->ABCDEAAB
5 -> 8: ABCDE -> ABCDEABC |
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Mon Feb 11, 2008 4:49 pm Post subject: |
|
blargg wrote: |
_willow_ wrote: |
6bit
have higher color grades, higher "steps". The ideal expansion would be
10bit, 15bit, 20bit result i.e. full mirroring that gives no parasite
"tail". |
Another solution is video hardware that expanded components by adding
zeros rather than repeting MSBs. It'd result in a very slightly darker
image, which could be a problem if combining graphics of several depths.
|
you got it! Filling LSBs with zeros is not that bad as it just reduce
overall brightness, but do not have any bad side effect on aliasing.
After all better do the math yourself without guessing and finally do
the exact bit copy right to DAC chip of this system.
blargg wrote: |
Somewhat related, consider what happens when you go from 5 to 6 to 8 by
repeating the MSBs, versus 5 straight to 8:
Code: |
5->6->8: ABCDE->ABCDEA->ABCDEAAB
5 -> 8: ABCDE -> ABCDEABC |
|
Another nice shot, this is what happens for RGB565 texture! 
_________________
quake2xp audio engineer
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Feb 11, 2008 5:51 pm Post subject: |
|
DAMN, I'm way late but I swear before reading all the other stuff, I would have voted for RGB888 for accuracy sake regardless.
on the pictures I would have said in that specific example the top row
looked slightly more saturated but that the bottom row was prolly the
more accurate one, HONESTLY 
stupid reserves stole my weekend 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Mon Feb 11, 2008 7:47 pm Post subject: |
|
I
finally found a proof for the expressions Bisqwit posted (took a few
hours, since my math is rusty). We want to show that 2^m/(2^n-1) yields
a bit sequence with single 1 bits separated by n-1 bits, where m >
n. Another way of specifying this is that the result must be of the
form a + a/2^n + a/2^2n + a/2^3n + ... and that a must be a power of 2.
First, simplify things by letting x=2^m and y=2^n, turning the original
expression into x/(y-1). This is equal to the series x/y + x/y^2 +
x/y^3 + ... which matches the series above, where a=x/y Since x and y
are powers of 2, x/y is a power of 2.
The following shows how the series can be arrived at step-by-step. The
last two lines just apply the expansion recursively to show that the
pattern keeps repeating, adding one more term each time.

Last edited by blargg on Mon Feb 11, 2008 10:26 pm; edited 1 time in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 11, 2008 7:51 pm Post subject: |
|
blargg wrote: |
I
finally found a proof for the expressions Bisquit posted (took a few
hours, since my math is rusty). We want to show that 2^m/(2^n-1) yields
a bit sequence with single 1 bits separated by n-1 bits, where m >
n. Another way of specifying this is that the result must be of the
form a + a/2^n + a/2^2n + a/2^3n + ... and that a must be a power of 2.
First, simplify things by letting x=2^m and y=2^n, turning the original
expression into x/(y-1). This is equal to the series x/y + x/y^2 +
x/y^3 + ... which matches the series above, where a=x/y Since x and y
are powers of 2, x/y is a power of 2.
The following shows how the series can be arrived at step-by-step. The
last two lines just apply the expansion recursively to show that the
pattern keeps repeating, adding one more term each time.
 |
I have no idea whatsoever what that means 
But if that proves what he said then Yay!
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Mon Feb 11, 2008 8:04 pm Post subject: |
|
It's
a simple example of proof by mathematical induction. Under the
assumption that something is true for earlier steps, if you can prove
that it will hold for the next step, you only need to show that it's
true for some initial value(s). |
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Mon Feb 11, 2008 9:24 pm Post subject: |
|
byuu wrote: |
Okay, I've posted a new WIP. Windows binary included.
Changes:
- Video output uses RGB888, rather than RGB565
- Removed RGB modes from Xv. They're a major hassle, I can't test them,
and they didn't even work right. Maybe I'll try again in the future
- $(DESTDIR) added to Makefile
- Increased Linux usleep idle delay from 20 to 20,000, so bsnes appears to consume 0% CPU time when idle
- Started moving src/snes/video to src/lib/libfilter. So far, only the colortable has been moved over
I held off on actually using libfilter's colortable. I'm intending to
break things completely here very shortly by eliminating src/snes/video
stuff, but I wanted to get a WIP out before doing so, so that people
could mess around with RGB888.
Speed is going to be a little slower for Linux users who use the GLX or
Xv video driver. Very sorry about this. If you need to, stick with
v0.028 official for the time being.
---
By the way, RGB888 is the bottom row. Thanks for playing. RGB888
doesn't make bright colors darker or vice versa, it avoids rounding
errors. It has the biggest effect on near-black colors, as before they
were getting crushed badly by the exponential curve gamma adjust. But
don't be fooled: really dark colors will still be much harder to see
than with the gamma curve turned off.
Anyway, if you liked the top row more, then just adjust the settings slightly on the raster settings tab 
EDIT: Neat, fglrx driver goes from 57.5fps to 59.5fps with GLX. YMMV. |
Forgive my ignorance, but where to get the WIP source/builds from?
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Feb 11, 2008 10:07 pm Post subject: |
|
It's only been mentioned like 6000 times in this thread that you have to request WIP access privately.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 11, 2008 11:12 pm Post subject: |
|
Out
of curiosity I looked into the colour conversion thing a bit more, and
I found some differences between the bit shifting + copying way
(integer version) and using floating point and rounding the results:
Code: |
00011 ( 3): 00011000->00011001 (18->19)
00111 ( 7): 00111001->00111010 (39->3A)
11000 (18): 11000110->11000101 (C6->C5)
11100 (1C): 11100111->11100110 (E7->E6) |
Where the left version is the integer way and the right version the
floating point way. I don't know which is correct, but I don't see how
the floating point version could be wrong, so.. could there be some
rounding issues in the integer version? Here's the code I used:
(conversion is RGB555 to RGB888)
Code: |
for(int k,j,i = 0; i < 32768; i++)
{ j = (i & 31) << 3 | (i & 28) >> 2 |
(i & 992) << 6 | (i & 896) << 1 |
(i & 31744) << 9 | (i & 28672) << 4;
k = int(((i & 31) >> 0) * 255./31. + .5) << 0 |
int(((i & 992) >> 5) * 255./31. + .5) << 8 |
int(((i & 31744) >> 10) * 255./31. + .5) << 16;
} |
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Feb 11, 2008 11:49 pm Post subject: |
|
wouldn't it be simpler to multiply each 5bit component by 8?
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Feb 12, 2008 12:01 am Post subject: |
|
@Verdauga Greeneyes
Do not use floating point to build those tables! It rounds everything by the will of fortune.
Code: |
for (i=0; i<0x20; i++)
{
colortable[i] = i * 0xFF / 0x1F;
}
|
Single table for red, green and blue. That's all 
but if you want to build the complete RGB555 -> RGB888 color lookup
table then it may look like.. mmm.. wait a min.. to say like this:
Code: |
for (b=0; b<0x20; b++)
{
colortable_b = b * 0xFF / 0x1F;
for (g=0; g<0x20; g++)
{
colortable_g = g * 0xFF / 0x1F;
for (r=0; r<0x20; r++)
{
colortable_r = r * 0xFF / 0x1F;
colortable[(r << r_5b_shift) | (g << g_5b_shift) | (b << b_5b_shift)] =
(colortable_r << r_8b_shift) |
(colortable_g << g_8b_shift) |
(colortable_b << b_8b_shift);
}
}
}
|
...no, no, silly me !! your code was better!
Code: |
for(i = 0; i < 0x8000; i++)
{
colortable[i] = (((i >> 0) & 0x1F) * 0xFF / 0x1F) << 0 |
(((i >> 5) & 0x1F) * 0xFF / 0x1F) << 8 |
(((i >> 10) & 0x1F) * 0xFF / 0x1F) << 16;
}
|
Don't make things more complicated then they are 
_________________
quake2xp audio engineer
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 12, 2008 12:19 am Post subject: |
|
Quote: |
wouldn't it be simpler to multiply each 5bit component by 8? |
... that's what we've been discussing for the past two or so pages :/
Executive summary: simpler, yes; better, no.
Code: |
colortable[i] = i * 0xFF / 0x1F; |
Oooooh, I like that a lot. Thank you very much!
Code: |
struct pixelformat {
unsigned r_bits, g_bits, b_bits;
unsigned r_index, g_index, b_index;
};
pixelformat rgb888 = { 8, 8, 8, 16, 8, 0 };
pixelformat rgb565 = { 5, 6, 5, 11, 5, 0 };
r = r * ((1 << pf.r_bits) - 1) / 31;
g = g * ((1 << pf.g_bits) - 1) / 31;
b = b * ((1 << pf.b_bits) - 1) / 31;
colortable[i] = (r << pf.r_index) + (g << pf.g_index) + (b << pf.b_index); |
Easy to support any potential output format, with no need for custom shift length magic. Very nice.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 12:28 am Post subject: |
|
I
still think it would be better to use floating point (or the state of
the first bit after the comma, if you really want to avoid fp) so as to
avoid rounding things down, i.e.:
Code: |
r = r * ((1 << pf.r_bits) - 1) / 31. + .5;
g = g * ((1 << pf.g_bits) - 1) / 31. + .5;
b = b * ((1 << pf.b_bits) - 1) / 31. + .5; |
Casts to int are should be implicit.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 12, 2008 12:34 am Post subject: |
|
Argh, nevermind, found some errors. I should have tested the code first. :) |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 12:46 am Post subject: |
|
blargg wrote: |
out = in * 64 / 31; // Correct (which is what my earlier proof verified)
out = (int) ((double) in * 63.0 / 31.0 + 0.5); // Correct
out = (in * 63 + 15) / 31; // Correct (does rounding using integer math)
out = in * 63 / 31; // Incorrect |
Oddly, in * 64 / 31 actually differs from the floating point version in
the four cases I mentioned earlier, as well as overflowing when in ==
31.. So either the third or second method would be best, depending on
architecture.
blargg wrote: |
Argh, nevermind, found some errors. I should have tested the code first.  |
Heh, our posts crossed.
Edit: so to reiterate, byuu, I suggest one of the following to avoid rounding errors:
Code: |
r = r * ((1 << pf.r_bits) - 1) / 31. + .5;
g = g * ((1 << pf.g_bits) - 1) / 31. + .5;
b = b * ((1 << pf.b_bits) - 1) / 31. + .5; |
Edit2: grr, guess it's getting late. Fixed version:
Code: |
r = (r * ((1 << pf.r_bits) - 1) + 15) / 31;
g = (g * ((1 << pf.g_bits) - 1) + 15) / 31;
b = (b * ((1 << pf.b_bits) - 1) + 15) / 31; |
Last edited by Verdauga Greeneyes on Tue Feb 12, 2008 1:15 am; edited 1 time in total
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 12, 2008 1:06 am Post subject: |
|
OK,
figured it out. The conv_float() and conv_round() yield different
results from conv_shift() for 3, 7, 24, and 28 as inputs. conv_fixed()
matches the shifts, and should be generalizable to any bit conversion
with
in_range = 1 << in_depth
ut_range = 1 << out_depth
factor = in_range * out_range / (in_range - 1)
out = (in * factor) >> in_depth
Code: |
static int conv_float( int n ) { return n * 255.0 / 31 + 0.5; }
static int conv_round( int n ) { return (n * 255 + 15) / 31; }
static int conv_fixed( int n ) { return (n * (32 * 256 / 31)) >> 5; }
static int conv_shift( int n ) { return (n << 3) | (n >> 2); }
// Compares each listed function below with conv_fixed, and prints any differences
int main()
{
int (*funcs [])( int ) = { conv_float, conv_round, conv_fixed, 0 };
for ( int i = 0; funcs [i]; i++ )
{
for ( int in = 0; in < 0x20; in++ )
{
int x = conv_shift( in );
int y = funcs [i]( in );
if ( x != y )
printf( "%d %2d->%3d %3d\n", i, in, x, y );
}
}
} |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 1:20 am Post subject: |
|
Heh,
so now the question is: which is better, a function that matches the
shifts or one that spreads the colours out evenly (i.e. conv_float()
and conv_round())? |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Feb 12, 2008 2:31 am Post subject: |
|
@Verdauga Greeneyes
No No No Enough! Oh my lord hope no one reads you in depth... follow me
- 5bit data forms the penta, 3 lower bits (LSB) is the fraction of
penta. This fraction of penta is just a copy of pentas most significant
bits(MSB). Simple binary scaling already use the optimal rounding:
00 / 2 = 0
01 / 2 = 0
10 / 2 = 1
11 / 2 = 1
000 / 4 = 0
001 / 4 = 0
010 / 4 = 0
011 / 4 = 0
100 / 4 = 1
101 / 4 = 1
110 / 4 = 1
111 / 4 = 1
and so on. What the no-thing you trying to optimize 
FPU processor do the floating point operations especially mul's and
div's by it's own weird logic, so 0+0.5 can easily result in
0.4999999999 or something like this.
_________________
quake2xp audio engineer |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 2:53 am Post subject: |
|
_willow_, I'm really not sure where you're coming from. Let's look at the numbers for a moment:
Code: |
0.00000000 0 0
8.22580645 8 8
16.45161290 16 16
24.67741935 24 25
32.90322581 32 33
41.12903226 41 41
49.35483871 49 49
57.58064516 57 58
65.80645161 65 66
74.03225806 74 74
82.25806452 82 82
90.48387097 90 90
98.70967742 98 99
106.93548387 106 107
115.16129032 115 115
123.38709677 123 123
131.61290323 131 132
139.83870968 139 140
148.06451613 148 148
156.29032258 156 156
164.51612903 164 165
172.74193548 172 173
180.96774194 180 181
189.19354839 189 189
197.41935484 197 197
205.64516129 205 206
213.87096774 213 214
222.09677419 222 222
230.32258065 230 230
238.54838710 238 239
246.77419355 246 247
255.00000000 255 255 |
Here the left column is the floating point result of [input colour]*255.0/31.0;
The centre column is the result of [input colour]*255/31; note how it's
the same as the left column, but with the fractional part chopped off -
in the worst case it's off by almost 0.97!
The right column is the result of round([input colour]*255.0/31.0),
which is obviously much closer to the actual values.
Need I say more? (by the way, I prefer the integer rounding version
that blargg posted, wherein we use ([input colour]*255 + 15)/31; but
that's just nitpicking, although an integer-based version is preferable
on today's CPUs)
Edit: hrm, perhaps I misinterpreted what you were talking about. Yes,
I'm wondering whether the rounded versions might be better than the
ones that rely on repeating the sequence of bits. Why? Well, remember
that the sequence of bits will repeat the same pattern for as long as
it has space - so if you cut it off at any point, shouldn't it be
subject to rounding as well? After all, as the binary arithmetic on the
last page showed, in essence it's just a fractional part. So to get it
right, my guess is we'd have to check the bit that would've gone to the
right of the lowest bit if there had been space, and round up or down
based on that. I haven't been able to confirm this because at the time
I was losing focus (it's quite late over here), and then the topic
moved away from the issue for a time. I'll see if I can figure it out
tomorrow, but either way both rounded versions (integer and floating
point) should be perfect. Just look at the list above, the floating
point calculations are precise enough no problem.
|
|
Bisqwit Rookie

Joined: 02 Aug 2004
Posts: 15
Location: Kerava, Finland
|
Posted: Tue Feb 12, 2008 10:51 am Post subject: |
|
blargg wrote: |
Bisqwit wrote: |
?
As those who have handled integer math know, multiplying A with 1101
would be equivalent to (A<<3) | (A << 2) | (A << 0).
? When we also handle decimals, we know that multiplying A with 1.001
is equivalent to (A << 0) | (A >> 3).
? So, multiplying A with 1000.01 is equivalent to: (A << 3) | (A >> 2). |
Only if multiplying an N-bit value by a factor where the 1 bits have no
fewer than N-1 zeros between them, otherwise you must use add, not
bitwise or (|).
|
Ah, indeed; thanks for pointing it out. It was a mistake.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 12, 2008 1:45 pm Post subject: |
|
Posted
a new WIP, which cleans up src/snes. I've completely killed all the
video filtering stuff, and cleaned up the rest. Only the audio WAV
logger remains. Didn't feel like moving that to the UI tonight.
So far, I have the colortable and a direct filter moved to libfilter.
I'll probably just add Scale2X and a simple scanline filter for the
time being, but HQ2x and NTSC will have to be re-added before another
official release can happen. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Tue Feb 12, 2008 2:05 pm Post subject: |
|
The CPU hogging problem is gone. Also, thank you for adding the destdir.
[pedantic]I think bsnes.png should be installed to pixmaps, not icons,
since, at least under Fedora, unthemed icons go to datadir/pixmaps,
while themed ones go to datadir/icons[/pedantic].
I'll try to figure out what is going on with OpenAL later.
Also, you mentioned issues with disabling screensavers. The main
problem is that there are at least 3 widely used screensavers:
kscreensaver (which now has probably 2 versions, kde 3 and kde 4),
xscreensaver and gnome-screensaver, each of which has different api
call to disable. While fake keypresses might be considered an ugly
solution, it is quite easy and does not cause huge dependency bloat. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Feb 12, 2008 3:48 pm Post subject: |
|
byuu wrote: |
So
far, I have the colortable and a direct filter moved to libfilter. I'll
probably just add Scale2X and a simple scanline filter for the time
being, but HQ2x and NTSC will have to be re-added before another
official release can happen. |
When you say "add Scale2X", does this just mean re-add, or re-write?
just curious as to whether the DKC graphics weird filter behaviour is
about to get its ass handed to it.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Feb 12, 2008 4:15 pm Post subject: |
|
@Verdauga Greeneyes
quote: "...in essence it's just a fractional part..."
I have to agree. Moreover that was me who said this,
quote myself: "...3 lower bits (LSB) is the fraction of penta..."
Ok, i got your point but i need a time to produce a common solution as i'm sort of slightly changed my mind.
For a quick note i found that the ultimate goal is the well-aligned
aliasing, rounding goes next to nothing. Like with rounding alchemy we
will play around the last bit, 0 or 1; it's going to be the most
hardest to guess.
We have redefined borders, so we need to "stretch" the values between
the new borders. The more increase steps uniform-like the better color
grade is, and so better algorithm is.
EDIT:
stepping deltas must form the uniform pattern
Again, sorry for my English.
_________________
quake2xp audio engineer |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 4:52 pm Post subject: |
|
After
the discussion last night, I decided to dig into the issue of rounding
a bit more. I dunno if anyone's interested enough anymore to read this,
but here goes.
First you have to define what exactly we want to do. As I see it there are two options:
1.) Match black up to black in the new colourspace, and white up to
white, and spread the rest of the colours evenly between the two. This
is what we've been doing so far, and is I think what we should stick
to, but I want to name the alternative anyway. As an example, consider
the following:
Code: |
4: 0 1 2 3
13: 0123456789012 |
2.) Assign each colour a certain range that it can expand into, and
centre it in that range. If you expand 5 bits to 15, this means each
original colour will get a range of 3 pixels, and you can put it into
the centre pixel without having to do any rounding. Of course, we're
not quite that lucky with our conversion. You might do something like
this to spread out sampling points for anti-aliasing, unfortunately
with colours it means white won't be exactly white, and black won't be
black. Instead, it'll have a colour one (or more) above black and below
white. Here's an example:
Code: |
4: 0 1 2 3
20: 01234567890123456789 |
Since we're going for the first option, we then have to determine how
to generate the right spacing; this is most easily done by looking at
scaling that doesn't need any rounding and can be done in all integers.
For scaling up 32 colours, here are some that work:
0: 32
1: 63
2: 94
3: 125
In there the 0 through 3 stand for the number of pixels in between each
original colour. Note that the ranges are always one more than a
multiple of 31 - RGB888's 256 falls in between 8*13 and 9*13, so it's
definitely going to need some rounding.
Because we have 32 colours, there are 31 spaces in between those
colours, their size depending on the scaling we're using. This means
we'll have to divide the new range by 31. In our case: i*([colour
space]-1)/31.0 gives the new floating point coordinates for each input
colour i. These coordinates spread the original colours perfectly
across the new colour space, but unfortunately there's no room for
floating point in RGB888, so we'll have to round them to most closely
approximate the ideal. Rounding the values and taking the difference
from their unrounded counterparts gives a mean of around 0.24 and a
standard deviation of around 0.15.
In contrast, comparing the floating point coordinates to the result
given by blargg's conv_fixed() and conv_shift() gives a mean of 0.27
and a standard deviation of 0.20. The difference is far from big, but
if we can agree that the floating point values are the best case, then
rounding them is the best solution.
I also had a look at the binary arithmetics involved in both versions,
but I don't think it really adds to the above, and I'm not sure how to
post it anyway. So in closure: in my opinion the best solution to the
problem is still what I suggested a few posts up, i.e.
Code: |
r = (r * ((1 << pf.r_bits) - 1) + 15) / 31;
g = (g * ((1 << pf.g_bits) - 1) + 15) / 31;
b = (b * ((1 << pf.b_bits) - 1) + 15) / 31; |
As this avoids floating point altogether while still giving the same result.
PS: credit for the integer-based rounding goes to blargg; I'd never really thought about it.
Edit: heh, this thing took so long to write. When I started _willow_'s
post above it wasn't there yet. I hope you agree with my assessment,
_willow_. From what you say in your post I think we agree, hope this
post is clear enough.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 12, 2008 5:24 pm Post subject: |
|
Verdauga
Greeneyes, good analysis. As you say, there are two competing goals:
black and white correspondence, and uniform steps. The first is
important when using multiple depths together, where their brightness
levels must match. Uniform steps are important if the material has lots
of smooth gradients and the target bit depth is low (like 555 to 565).
A third option to the two you mentioned is to use dithering, where the
formerly-lost fraction sets the probability of rounding up or down for
a particular pixel. Not that bsnes will use it, but it's an option for
other less performance-intensive applications. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Feb 12, 2008 8:10 pm Post subject: |
|
why not for bsnes, too slow?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Feb 12, 2008 8:52 pm Post subject: |
|
@Verdauga Greeneyes
@blarg
yeah, but dont forget about another option please!
256 slots downscale to 32 slots easily so each 8 nearby positions
grouped in to 1 slot. No rounding tricks and magic. No dead brain.
On the contrary try to prove it's not the correct method.
_________________
quake2xp audio engineer |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 12, 2008 9:45 pm Post subject: |
|
_willow_ wrote: |
@Verdauga Greeneyes
@blarg
yeah, but dont forget about another option please!
256 slots downscale to 32 slots easily so each 8 nearby positions
grouped in to 1 slot. No rounding tricks and magic. No dead brain.
On the contrary try to prove it's not the correct method. |
What you're describing is the reverse of my option 2. This option
suffers far less from rounding issues, but doesn't preserve the upper
and lower limits.
Panzer88 wrote: |
why not for bsnes, too slow? |
I imagine so. I don't know much about dithering (in fact, hardly
anything, although the option did occur to me), but where bsnes now
uses a lookup table, which is one of the most efficient tricks there
are, dithering would add an extra layer of complexity for each pixel.
(or might possibly make the lookup table very big, which would lessen
its effect as well, and hog a lot of memory)
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Tue Feb 12, 2008 10:04 pm Post subject: |
|
_willow_ wrote: |
256
slots downscale to 32 slots easily so each 8 nearby positions grouped
in to 1 slot. No rounding tricks and magic. No dead brain. |
You seem to be missing the fundamental problem: when increasing the
number of bits, you have to choose between preserving absolute level or
uniform steps between levels. Neither is superior. When decreasing the
number of bits, you just truncate, no problem.
Quote: |
On the contrary try to prove it's not the correct method. |
Since there's a tradeoff, there is no correct method for all uses. For
reducing the number of bits, truncating is arguably the correct method
since it's about all you can do.
But since I don't understand your posts very well, I am just guessing.
It'd help if you were clearer on your intent.
|
|
_willow_ Rookie

Joined: 24 Dec 2007
Posts: 48
Location: Russia
|
Posted: Tue Feb 12, 2008 10:37 pm Post subject: |
|
_willow_ wrote: |
256 slots downscale to 32 slots easily so each 8 nearby positions grouped in to 1 slot
|
Sorry i thougth of downscale but not upscale as i'm very tired today.
It do not upscale that easy... No wonder you do not understand me.
so far i did the delta table with excellent peaks pattern
1 : 8
2 : 8
3 : 8
4 : 9 (1st delta peak)
5 : 8
6 : 8
7 : 8
8 : 9 (2nd delta peak)
9 : 8
10 : 8
11 : 8
12 : 9 (3rd delta peak)
13 : 8
14 : 8
15 : 8
16 : 9 (4th delta peak)
17 : 8
18 : 8
19 : 8
20 : 9 (5th delta peak)
21 : 8
22 : 8
23 : 8
24 : 9 (6th delta peak)
25 : 8
26 : 8
27 : 8
28 : 9 (7th delta peak)
29 : 8
30 : 8
31 : 8
i.e.
0: --> 0
1: --> 0+8
2: --> 0+8+8
3: --> 0+8+8+8
4: --> 0+8+8+8+9
5: --> 0+8+8+8+9+8
and so on
it have correct scale with fine grade.
but i dont know the formula for this yet.
--
all formulas just placing peaks (spikes) randomly, trying the formula
scaled_color = ((color * 0xFF) + 0x0F) / 0x1F;
give not that good pattern comparing to above pattern:
1 : 8
2 : 8
3 : 9 - peak
4 : 8
5 : 8
6 : 8
7 : 9 - peak
8 : 8
9 : 8
10 : 8
11 : 8
12 : 9 - peak
13 : 8
14 : 8
15 : 8
16 : 9 - peak
17 : 8
18 : 8
19 : 8
20 : 9 - peak
21 : 8
22 : 8
23 : 8
24 : 8
25 : 9 - peak
26 : 8
27 : 8
28 : 8
29 : 9 - peak
30 : 8
31 : 8
note:
delta = colortable[i] - colortable[i-1];
EDIT 1: fix some prehistoric grammar
EDIT 2: same. it's just endless 
_________________
quake2xp audio engineer
Last edited by _willow_ on Wed Feb 13, 2008 1:10 am; edited 2 times in total
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 12:43 am Post subject: |
|
I'm
guessing you mean either 'peak' or 'spike' rather than pike. I'll check
the pattern out tomorrow, and compare it to my 'optimal' solution. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Feb 13, 2008 1:04 am Post subject: |
|
Using a factor of 8.25 yields the first pattern _willow_ posted, and what conv_shift() and conv_fixed() both yield. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Feb 13, 2008 3:40 am Post subject: |
|
so dithering would be your method of choice blargg if it didn't slow things in an already slow emulator?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Bisqwit Rookie

Joined: 02 Aug 2004
Posts: 15
Location: Kerava, Finland
|
Posted: Wed Feb 13, 2008 5:30 am Post subject: |
|
I don't think dithering will affect significantly to the performance. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 1:47 pm Post subject: |
|
Hmm,
to be honest this development has left me a bit indecisive. I thought
about it for a while, and I suppose it comes down to: how does one
define maximum uniformity? Do we define it as the minimum deviation
from the optimal distribution (255/31) or as um.. (I'm struggling with
how to put this one) the pattern with the most recurrence
(conv_shift())? There's something to be said for either one, so I'm
hesitant to state a preference.. any mathematicians around that can
help out?  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 13, 2008 2:09 pm Post subject: |
|
New
WIP. Windows binary included. I've added back Scale2x support, and I
also added a scanline filter for Snark. No, I don't plan on combining
them so you can do things like Scale2x + scanlines. It's a 50% scanline
filter. I may add 75% and 100% in the future.
Ah, and a while back I mentioned a certain software filter I saw. Here is that picture:
Code: |
http://byuu.cinnamonpirate.com/temp/PhosphorSimTest1.jpg |
Unfortunately, I don't even remember where I found the image anymore,
let alone who made it. Does anyone here know how to recreate the
filtered image from the source image?
I'd prefer to avoid baseless speculation, if you know how it is done --
and better yet, if you can duplicate it -- please let me know. I
really, really like the filter and would love to add it to bsnes.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Feb 13, 2008 2:20 pm Post subject: |
|
byuu wrote: |
I really, really like the filter |
Seconded. 
Btw. maybe the NTSC filter could be applied to the source picture first, for even more "realism"...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Wed Feb 13, 2008 2:30 pm Post subject: |
|
byuu wrote: |
Ah, and a while back I mentioned a certain software filter I saw. Here is that picture:
Code: |
http://byuu.cinnamonpirate.com/temp/PhosphorSimTest1.jpg |
Unfortunately, I don't even remember where I found the image anymore,
let alone who made it. Does anyone here know how to recreate the
filtered image from the source image?
I'd prefer to avoid baseless speculation, if you know how it is done --
and better yet, if you can duplicate it -- please let me know. I
really, really like the filter and would love to add it to bsnes.
|
I did a quick google search, is this possibly what you are talking about?
http://board.zsnes.com/phpBB2/viewtopic.php?p=126502#126502
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Feb 13, 2008 2:43 pm Post subject: |
|
Google likes me.
http://selectbutton.net/archive/topic/7402/page/2 wrote: |
Posted: Sat Aug 19, 2006 9:40 pm Post subject:
Appropriate time for my phosphor simulation experiment image? This
looks better or worse depending on the resolution people see it at, but
yeah, for a while I tried to figure out how the phosphor halation thing
worked in making jaggedy-ass images look smoove on low-def CRTs.
http://psiga.mp3.googlepages.com/PhosphorSimTest1.jpg
This was all done in Photoshop, though I've half-forgotten the steps to replicate it. |
Looks like this was just a Photoshop job, and even the original artist doesn't remember how he did it.
_________________
Why yes, my shift key *IS* broken.
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Wed Feb 13, 2008 2:54 pm Post subject: |
|
odditude wrote: |
Google likes me.
Looks like this was just a Photoshop job, and even the original artist doesn't remember how he did it. |
Guess I was wrong!
Looks like we better get started on reverse engineering this filter, because I like it too much!
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 3:48 pm Post subject: |
|
Well,
it's nothing like the 'filter' we're discussing, but this is something
I came up with in an attempt to replicate it. Looks pretty interesting,
I think: (note when you click the link you get a slightly scaled
version, so be sure to click that image as well to get the full size) |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Feb 13, 2008 3:51 pm Post subject: |
|
blur
that VERY slightly and give it a very slight glow (just looking at the
source pictures numbers, they kinda have a glowy look to them) and that
would look pretty spot-on, in my opinion. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Feb 13, 2008 5:00 pm Post subject: |
|
Panzer88 wrote: |
so dithering would be your method of choice blargg if it didn't slow things in an already slow emulator? |
Not for going from 5 to 8 bits, where the error would only be 12.5% of
the 1/32 step between each SNES color level. I doubt anyone here could
even tell the difference.
byuu wrote: |
Unfortunately,
I don't even remember where I found the image anymore, let alone who
made it. Does anyone here know how to recreate the filtered image from
the source image? |
Heh, remember when I recreated that a while back? But gah, now that I'm
finally geting to play Zelda: Twilight Princess, I'm really tired of
the overuse of that effect. Why would anyone want to have it all the
time like that?!?
- In Photoshop, put the original image (580x448) in the background.
- Make a new layer with a copy of the image and apply Gaussian Blur, radius=2.3 pixels.
- Change that layer's mode to Lighten, with opacity=93%.
- Make a new scanlines layer over both with alternating white and black
horizontal lines. To do this, draw a white pixel over a black pixel,
make a 1x2 selection, Define Pattern, Select All, Fill... and use that
pattern.
- Change the scanlines layer to Multiply mode, opacity=15%.
- Experiment with things.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 5:17 pm Post subject: |
|
I added a bit of glow to it (was a PITA, too):
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 13, 2008 5:22 pm Post subject: |
|
Neat, thanks for finding the original source :)
And as for the LCD filters, they won't work for SNES emulation, because
the SNES aspect ratio is 8:7 internally, and 4:3 externally. In other
words, we have to stretch the filtered image horizontally. The LCD
filters look very bad with non-multiple stretching in either direction.
Quote: |
Heh, remember when I recreated that a while back? |
v_v;
Actually, no. I had completely forgotten about that, sorry.
But looking at your steps, I remember it now. Yes.
And unfortunately, I remember the problem. Real-time software-based
gaussian interpolation is not going to be pretty.
Do you think it'd be possible to quickly approximate the effect as a
whole in software? Best I could think would be to grab the neighboring
4 pixels to create a blurred pixel equivalent (basically a simple 2x
bilinear filter), index that into a luma increase table, and then blend
the original pixel (as assumed by a 2x point filter -- simple enough)
with our blurred, lightened pixel to generate the final result. Throw
in 50% scanlines as the last step. Probably won't look nearly as good,
sadly.
Quote: |
Why would anyone want to have it all the time like that?!? |
I like it, it makes me feel like I'm slightly drunk. Add some fog haze
on the edges and I might think it's a dream sequence. And just imagine
using that filter when I actually am drunk and tired :)
-----
Another question for everyone. This PC has an nVidia Vanta 16MB
graphics card. With it, I get ~28fps using Direct3D + 16bpp. I get
~18fps with Direct3D + 24bpp. And I get ~65(!!)fps with DirectDraw, the
same amount in both 16bpp and 24bpp.
That's an amazing difference. Clearly, cards that have virtually no 3D
acceleration suffer major performance penalties for 3D rendering.
I also noticed that with my Radeon X300 on Vista, Direct3D at 24bpp
takes a ~5% speed hit, whereas there is no speed difference with
DirectDraw.
Given this, would it be a safer bet to default to the DirectDraw filter
in the future? The only real problem with DD is that you can't use
point filtering to resize images. Obviously, anyone wanting that
functionality could enable the D3D driver. I really need a nice
configuration system for letting users change out drivers.
Last edited by byuu on Wed Feb 13, 2008 5:31 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 5:30 pm Post subject: |
|
Just
so you know, my filter is a GLSL one, and I currently get ~25fps on my
6600GT at 1600x1200; also the filter is pretty unoptimised. Tested in
ePSXe with Pete's OGL2 plugin. (that's where the screenshots come from) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 13, 2008 5:37 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Just
so you know, my filter is a GLSL one, and I currently get ~25fps on my
6600GT at 1600x1200; also the filter is pretty unoptimised. Tested in
ePSXe with Pete's OGL2 plugin. (that's where the screenshots come from) |
Neato! The one thing I noticed about it that was different was that the
original seems to have both horizontal and vertical partial scanlines
applied to it. Makes the pixels seem to pop a bit more.
Anyway, if I ever get GLSL support working, that would be really cool!
I'd definitely include it as an option for those with OpenGL support.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 13, 2008 6:15 pm Post subject: |
|
Hmm,
well the original is a 2x filter (well, it's a photoshopped image, but
nevermind that) that seperates R, G and B like a TV does. It also does
a lot of blurring on that. My filter tries to do the same thing, but I
didn't have much luck getting it to look good so I'm blending it with
the full original colour. I think the horizontal scanlines you're
seeing in the original is actually just the blue channel standing out
as being pretty dark. |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Wed Feb 13, 2008 6:55 pm Post subject: System-wide libs |
|
byuu,
in the process of Fedora package review I was pointed that using local
copies of system libraries is frowned upon. One of the fellow users
came up with a patch which adds an option to use system zip/gzip:
Code: |
diff -up bsnes-0.028.01/src/Makefile.system-zlib bsnes-0.028.01/src/Makefile
--- bsnes-0.028.01/src/Makefile.system-zlib 2008-02-13 19:09:30.000000000 +0200
+++ bsnes-0.028.01/src/Makefile 2008-02-13 19:45:11.000000000 +0200
@@ -84,6 +84,13 @@ ifeq ($(enable_gzip),true)
flags += $(call mkdef,GZIP_SUPPORT)
endif
+ifeq ($(system_gzip),true)
+ flags += $(call mkdef,SYSTEM_GZIP_SUPPORT)
+ flags += $(call mkdef,GZIP_SUPPORT)
+ link += $(shell pkg-config --libs minizip)
+endif
+
+
ifeq ($(enable_jma),true)
objects += jma jcrc32 lzmadec 7zlzma iiostrm inbyte lzma winout
flags += $(call mkdef,JMA_SUPPORT)
diff -up bsnes-0.028.01/src/reader/zipreader.h.system-zlib bsnes-0.028.01/src/reader/zipreader.h
--- bsnes-0.028.01/src/reader/zipreader.h.system-zlib 2008-02-13 19:55:12.000000000 +0200
+++ bsnes-0.028.01/src/reader/zipreader.h 2008-02-13 19:55:35.000000000 +0200
@@ -1,6 +1,10 @@
//created by Nach
+#if defined(SYSTEM_GZIP_SUPPORT)
+#include <minizip/unzip.h>
+#else
#include "zlib/unzip.h"
+#endif
//Could be up to 65536
#define ZIP_MAX_FILE_NAME 4096
diff -up bsnes-0.028.01/src/reader/reader.h.system-zlib bsnes-0.028.01/src/reader/reader.h
diff -up bsnes-0.028.01/src/reader/gzreader.h.system-zlib bsnes-0.028.01/src/reader/gzreader.h
--- bsnes-0.028.01/src/reader/gzreader.h.system-zlib 2008-02-13 19:16:20.000000000 +0200
+++ bsnes-0.028.01/src/reader/gzreader.h 2008-02-13 19:18:17.000000000 +0200
@@ -1,4 +1,8 @@
+#if defined(SYSTEM_GZIP_SUPPORT)
+#include <zlib.h>
+#else
#include "zlib/zlib.h"
+#endif
class GZReader : public Reader {
private: |
Would you like to merge it? If not, is it OK if I used it with the package? Cheers.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 13, 2008 7:21 pm Post subject: Re: System-wide libs |
|
Quote: |
in the process of Fedora package review I was pointed that using local copies of system libraries is frowned upon. |
What? A Linux developer complaining about something completely irrelevant? Surely you jest.
Quote: |
Would you like to merge it? If not, is it OK if I used it with the package? Cheers. |
I don't really want to add this change to bsnes, no. A system-wide zlib
would require a DLL for Windows, and I see no reason to provide a lean,
stripped down zlib along with bsnes for Windows users, yet have an
option to use the system version for Linux (especially when there is no
similar lib for JMA), just to appease a few people with nothing better
to do than complain about random garbage.
However, feel free to appease the Fedora development team by changing
that in your source tree if you like. My sincere apologies that you'll
have to keep backporting the change.
I don't want any part in trying to appease these people. They
constantly bring up crap about non-commercial clauses, about using a
64-byte IPLROM, about compiling in support for OSS by default, and now
about a massive ~80kb that can be shaved off the bsnes binary by adding
extra dependencies to the emulator. Perhaps I should just start
offering a raw Linux binary on my website ala nVidia, Macromedia et al.
|
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Wed Feb 13, 2008 7:31 pm Post subject: Re: System-wide libs |
|
byuu wrote: |
Quote: |
in the process of Fedora package review I was pointed that using local copies of system libraries is frowned upon. |
What? A Linux developer complaining about something completely irrelevant? Surely you jest.
Quote: |
Would you like to merge it? If not, is it OK if I used it with the package? Cheers. |
I don't really want to add this change to bsnes, no. A system-wide zlib
would require a DLL for Windows, and I see no reason to provide a lean,
stripped down zlib along with bsnes for Windows users, yet have an
option to use the system version for Linux (especially when there is no
similar lib for JMA), just to appease a few people with nothing better
to do than complain about random garbage.
However, feel free to appease the Fedora development team by changing
that in your source tree if you like. My sincere apologies that you'll
have to keep backporting the change.
I don't want any part in trying to appease these people. They
constantly bring up crap about non-commercial clauses, about using a
64-byte IPLROM, about compiling in support for OSS by default, and now
about a massive ~80kb that can be shaved off the bsnes binary by adding
extra dependencies to the emulator. Perhaps I should just start
offering a raw Linux binary on my website ala nVidia, Macromedia et al.
|
Thanks for the permission. BTW, that was one of the funnier posts I read recenly . I would also happily keep the internal zlib, but I can't review my own package, unfortunately . Anyway, here is what the guideline says, in case anyone is interested:
Quote: |
For
several reasons, a package should not include or build against a local
copy of a library that exists on a system. The package should be
patched to use the system libraries.
This prevents old bugs and security holes from living on after the core system libraries have been fixed. |
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Wed Feb 13, 2008 7:50 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Hmm,
well the original is a 2x filter (well, it's a photoshopped image, but
nevermind that) that seperates R, G and B like a TV does. It also does
a lot of blurring on that. My filter tries to do the same thing, but I
didn't have much luck getting it to look good so I'm blending it with
the full original colour. I think the horizontal scanlines you're
seeing in the original is actually just the blue channel standing out
as being pretty dark. |
For some reason I really like the look of the original image, and I'm
actually wracking my brain trying to figure out how it was done
I picked a section out of the image and the original with some white
pixels which better show the separation of colors. Open these two
images up in tabs or something and compare them directly. This is quite
an intense change when you see it close up. Obviously we probably can't
get the exact same result as numbers might be off here or there but I'm
still curious as to how the colors are split, and pixels averaged
together and everything.
http://img404.imageshack.us/img404/9250/origqg7.png
http://img166.imageshack.us/img166/9820/phta5.png
EDIT: Well I've messed around with a .NET program I made to manipulate
an input image and see if I could get an output pretty similar... I can
get a lot of it close except the "striped" vertical lines, and I
suspect there is that gaussian blur technique but not as strong as the
one used above in this thread. Not sure how to easily duplicate that
outside of PS. If a filter was made I don't know what kind of a load it
would have on the processor though, compared to something like the ntsc
filter. Oh well.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 13, 2008 11:15 pm Post subject: |
|
Okay,
Richard Bannister is stating that the x86 version of libco is not
working on his OS X box. Odd, neither is the older ASM code that Lucas
verified worked for him.
Not sure what else to
try. Anyone here have an Intel Mac who can do some tests with it? So
long as it is compiled with -fomit-frame-pointer, it should be fine.
Quote: |
I can get a lot of it close except the "striped" vertical lines |
To me, it kind of looks like the colors were split. Eg:
Out pixel 0 = In pixel blue, Out pixel 1 = In pixel red+green
This explains how white can get patterns of blue and yellow when you zoom in closely.
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Wed Feb 13, 2008 11:36 pm Post subject: |
|
byuu wrote: |
To me, it kind of looks like the colors were split. Eg:
Out pixel 0 = In pixel blue, Out pixel 1 = In pixel red+green
This explains how white can get patterns of blue and yellow when you zoom in closely. |
Well to get a pretty good base image to work with, I had pixel (x,y) in
a new blank image equal to (x,y) from the source image, with the R
value averaged with (x+1,y) and the B value averaged with (x-1,y). G
remains the same.
It looks pretty similar, minus the scanlines, vertical blue/yellowred
tinted lines, and the photoshop touchups (gaussian blur, and I think
contrast adjustments) I think this technique or one very similar was
used as it generates the blue/yellow seen in the white areas, and most
colors match up well
|
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Feb 14, 2008 12:47 am Post subject: Re: System-wide libs |
|
byuu wrote: |
yet have an option to use the system version for Linux |
Lets not forget to mention that <minizip/unzip.h> isn't a
standard header by any stretch of the imagination and probably only
exists on Fedora.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 14, 2008 1:46 am Post subject: |
|
I
looked into doing a Gaussian blur in GLSL, and although it should be
relatively easy to implement, with blargg's suggested 2.3 pixel range
we have to do a -lot- of texture reads. Worst case, 225 texture reads
(15x15), but the outer edges probably don't need that kind of
precision. Indeed, we could probably get away with a smaller grid
anyway, but I'd like to look into the ideal case first. Doing a quick
test case, the filter -does- seem to work, although framerate goes down
to around 30 fps, so we'll see. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 14, 2008 5:15 am Post subject: |
|
byuu wrote: |
Another question for everyone. This PC has an nVidia Vanta 16MB
graphics card. With it, I get ~28fps using Direct3D + 16bpp. I get
~18fps with Direct3D + 24bpp. And I get ~65(!!)fps with DirectDraw, the
same amount in both 16bpp and 24bpp.
That's an amazing difference. Clearly, cards that have virtually no 3D
acceleration suffer major performance penalties for 3D rendering.
I also noticed that with my Radeon X300 on Vista, Direct3D at 24bpp
takes a ~5% speed hit, whereas there is no speed difference with
DirectDraw.
Given this, would it be a safer bet to default to the DirectDraw filter
in the future? The only real problem with DD is that you can't use
point filtering to resize images. Obviously, anyone wanting that
functionality could enable the D3D driver. I really need a nice
configuration system for letting users change out drivers. |
Well, it takes a powerful CPU to get 60fps in bsnes. So how frequently
do you expect someone to pair a powerful modern CPU with a ten year old
video card? Can't be more than 5% of users doing that. Why default to a
crippled renderer to save those people a few clicks?
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Feb 14, 2008 5:22 am Post subject: |
|
Uh, when you say "Well, it takes a powerful CPU to get 60fps in bsnes" what's your definition of powerful?
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 14, 2008 5:44 am Post subject: |
|
My
Core 2 Duo 1.86ghz dips to 65 on the Chrono Trigger title screen.
That's the lower end of a recent architecture. From that performance we
can infer that anything less than that is likely not enough to maintain
a 60fps minimum. |
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 7:21 am Post subject: |
|
hi, being a looooong time lurker and supporter of bsnes, maybe I can finally give something back.
I have an Intel Mac with OS X 10.4 (no Leopard, sorry, but it shouldn't
be that different yet) I can test whatever on
let me know either here or through PM what I can test to help you.
Notice that I'm not uber-expert about compiling and coding, but I can
easily compile SDLMAME/MESS, so I'm not completely clueless either... |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 14, 2008 10:22 am Post subject: |
|
byuu wrote: |
New WIP. Windows binary included. I've added back Scale2x support, and
I also added a scanline filter for Snark. No, I don't plan on combining
them so you can do things like Scale2x + scanlines. It's a 50% scanline
filter. I may add 75% and 100% in the future.
Ah, and a while back I mentioned a certain software filter I saw. Here is that picture:
Code: |
http://byuu.cinnamonpirate.com/temp/PhosphorSimTest1.jpg |
Unfortunately, I don't even remember where I found the image anymore,
let alone who made it. Does anyone here know how to recreate the
filtered image from the source image?
I'd prefer to avoid baseless speculation, if you know how it is done --
and better yet, if you can duplicate it -- please let me know. I
really, really like the filter and would love to add it to bsnes.
|
Well i did a LOT of testing to get those fosfors correct, the esiest
way is to overlay an image of fosfors like mame does, just add it last
to the image, using this system also means you can use the same images
as mame meaning all forms off scanlines/fosfors can be easily supported
The fosfors in that screenshot look very much like pal-sony tv's, that
effect can be created quite easily with the overlay images.
However, my testing has revealed that its best to create a different overlay for each image/resolution size.
For example, if you fullscreen the image at a resolution of 1280x1024
this means you can create a very fine fosfor image, but you have to
make it for this resolution, this way you can quite accurately simulate
the fosfors of a 17inch TV for example.
Even better would be subpixel hinting, this would be almost 100% accurate
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Feb 14, 2008 11:16 am Post subject: |
|
FitzRoy wrote: |
My
Core 2 Duo 1.86ghz dips to 65 on the Chrono Trigger title screen.
That's the lower end of a recent architecture. From that performance we
can infer that anything less than that is likely not enough to maintain
a 60fps minimum. |
Aye, my Athlon64 3000+ (1.8GHz) can't maintain 60FPS on the CT title screen, unless I set the frameskip to 1.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 14, 2008 11:18 am Post subject: |
|
Yeah,
my Athlon 64 (2.5GHz) tends to just barely fall below 60fps on the
black omen scene. Really, you want a first-gen Core 2 Duo or newer. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Feb 14, 2008 1:18 pm Post subject: |
|
My
CPU is a 64-bit Pentium IV Prescott clocked at 3.20GHz (which isn't as
good as a dual core, but most games run 60 fps, except for SDD1 games,
they dip lower than 55.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 14, 2008 1:54 pm Post subject: |
|
New WIP up. This one re-adds HQ2x and NTSC, so all filters from v028 are back, plus there's the new scanline filter.
So all of that code is now out of the core. It was pretty silly that eg
the S-SMP core was dependent upon the SNES class, which depended on the
VideoFilter class, which depended upon the HQ2x class, which depended
upon the ~50kb HQ2x blending tables. Well, no longer.
While I didn't make V-only HQ2x and Scale2x filters (yet?), I did add
some code to make it fallback on the direct renderer if hires or
interlace is being used. This means the issues with hires games (eg DKC
intro) should be gone. Let me know if you find any problems.
I also re-added DMPSDisable to the GTK+ screensaver disable code, since
that was triggering after ~30 minutes or so still. It probably won't
even work, but whatever.
Quote: |
Why default to a crippled renderer to save those people a few clicks? |
First impressions and all that, mostly.
Quote: |
I have an Intel Mac with OS X 10.4 (no Leopard, sorry, but it shouldn't be that different yet) I can test whatever on |
Thank you! :D
Okay, first thing would be to make sure libco itself works. Please download this:
Code: |
http://byuu.cinnamonpirate.com/files/libco_v13_rc2.zip |
You can compile the test program like this:
Code: |
g++ -O3 -fomit-frame-pointer -c test_timing.cpp
gcc -O3 -fomit-frame-pointer -o libco.o -c ../libco.c
g++ -O3 -fomit-frame-pointer test_timing.o libco.o -o test_timing |
Then just run test_timing that is produced, and let me know what the output is, or if it segfaults.
Quote: |
Really, you want a first-gen Core 2 Duo or newer. |
Yeah, it's pretty slow. Especially since v018. It used to be easy to get 80-100fps with a 3500+.
|
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 3:25 pm Post subject: |
|
it segfaulted on my macbook intel core 2 duo (2.16 Ghz)...
Code: |
context-switching timing test
1.400 seconds per 50 million subroutine calls (500000000 iterations)
Segmentation fault |
the actual error seems to be the following (according to gdb)
Code: |
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x18ec94ac
0x00002d24 in co_create () |
of course, not being sure about how to build it with symbols (if
possible), I cannot backtrace it any more with gdb
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 14, 2008 4:11 pm Post subject: |
|
Quote: |
it segfaulted on my macbook intel core 2 duo (2.16 Ghz)... |
Well, that's actually a good thing. It means we can reproduce the bug without needing to compile bsnes.
Okay, then. co_create is the problem ...
Current code:
Code: |
//old version
cothread_t co_create(unsigned int size, void (*entrypoint)(void)) {
cothread_t handle;
assert(sizeof(long) == 4);
if(!co_active_) co_active_ = &co_active_buffer;
size += 128; /* allocate additional space for storage */
size &= ~15; /* align stack to 16-byte boundary */
if(handle = (cothread_t)calloc(size, 1)) {
long *p = (long*)((char*)handle + size); /* seek to top of stack */
*--p = (long)crash; /* crash if entrypoint returns */
*--p = (long)entrypoint; /* start of function */
*(long*)handle = (long)p; /* stack pointer */
}
return handle;
} |
Hmm ... can you try replacing that function with the below, and then recompiling?
Code: |
//new version
cothread_t co_create(unsigned int size, void (*entrypoint)(void)) {
cothread_t handle;
assert(sizeof(unsigned char) == 1);
assert(sizeof(unsigned long) == 4);
if(!co_active_) co_active_ = &co_active_buffer;
size += 128;
size &= ~15;
handle = (cothread_t)malloc(size + 16);
if(handle) {
unsigned long *p = (unsigned long*)((unsigned char*)handle + size);
*--p = (unsigned long)crash;
*--p = (unsigned long)entrypoint;
*(unsigned long*)handle = (unsigned long)p;
}
return handle;
} |
|
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 4:39 pm Post subject: |
|
ehm, just to be sure, I shall edit that code in libco/libco.x86.c, right?
if this is correct, now test_timing gives a bus error
Code: |
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? () |
otherwise, which file has to be edited?
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Feb 14, 2008 4:56 pm Post subject: |
|
I could have sworn that the compiler should have been fed some more random switches to make it ad proper debugging info. |
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 5:08 pm Post subject: |
|
not
necessarily... it reports anyway why it's crashing... the additional
switches are needed to give a precise trace of what has happened since
the beginning, to see e.g. if you entered a piece of code you were not
supposed to  |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Feb 14, 2008 8:07 pm Post subject: |
|
The new WIP does indeed fix the DKC graphic when using filters, much obliged byuu
I guess the only thing that's missing for me at this point is the sound
lag, which I guess I'm not going to be able to fix. Oh well. I also
wish the hq and nstc filters didn't bog down my framerate, but at this
point I guess that's just as fast as my computer can push it.
What are you working on now? More rewrites? |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Feb 14, 2008 8:32 pm Post subject: |
|
Is there is reason why 60FPS is impossible to achieve on this type of CPU. Sorry for being WOT.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Thu Feb 14, 2008 8:41 pm Post subject: |
|
I have an Intel Mac running OS X 10.5 Leopard. I decided to try out the libco test as well, to see what results I got.
Well, it appears something really weird is going on. According to gdb,
when the crash occurs, execution is in main(), at line 35 (the call to
co_active()). But the weird thing is, that piece of code had already
executed! In fact, by setting breakpoints I was able to confirm that
co_create(), co_switch() and even co_timingtest() all execute at least
once prior to the crash! So why in the world is gdb claiming the crash
to be at the call to co_active()?
It appears the crash is actually happening during the second call to
co_switch(), to return to the main thread. However, I can't step
through that function, because gdb can't handle the assembly language
portion (for obvious reasons).
Does this help any? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 14, 2008 8:52 pm Post subject: |
|
neo_bahamut1985 wrote: |
Is there is reason why 60FPS is impossible to achieve on this type of CPU. Sorry for being WOT. |
If you're referring to your previous post: Perhaps because it's still too slow even at that clock rate you know of course that Mhz doesn't necessarily = Speed!
Your P4 3.2Ghz may be clocked much higher but it still do less compared
to a Core 2 Duo at half the clockrate, simple as that...Nothing much
you can do about it, unless perhaps you can manage to overclock it to
4.x Ghz. (though I wouldn't recommend it, if you don't know what you're
doing you may just risk toasting your CPU, and for a relatively small
gain)
edit:
and woot! nice to see the ol' scanlines option is back. I hope in the
future (if you have the time to work on this of course) we can manage
to get all the pre 0.019 video options back in (or something
equivalent/similar), in one form or another.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 14, 2008 9:28 pm Post subject: |
|
Quote: |
if this is correct, now test_timing gives a bus error |
That's correct, and I have absolutely no idea how it could be writing
to 0x00000000 inside co_create(). So, I'm at a loss. Thanks for trying
to help, but I'm completely out of ideas now.
Quote: |
What are you working on now? More rewrites? |
Not sure, probably. Still want to clean up the filter code more.
Thinking, I won't be using any audio resampling filters anyway for the
next few years, might as well drop out that abstraction so it's just
using namespace libfilter; filter.set() + filter.render();
I notice src/config/config.h is pretty empty. Maybe I should move the
last of it into the UI, and make the essential stuff settings to be
toggled through class SNES or class CPU/SMP/DSP/PPU. Then make the core
separate from libstring and libconfig.
Quote: |
Is there is reason why 60FPS is impossible to achieve on this type of CPU. |
Let's see.
1) I lack the programming skill to create a range-based IRQ tester. I
really, really tried. I failed. My clock stepping costs ~40% of bsnes'
speed, while offering no accuracy improvement. It just makes the code
100x easier to read.
2) Both Microsoft Visual C++'s and MinGW's profile guided optimizers
are fucked up beyond all recognition. Worthless garbage. I lost another
~30% speed when bsnes became too complex for them to handle.
3) Typical stubbornness. I use cothreads for SMP<>DSP despite the
S-DSP being fully enslaveable, because I want the two to operate in
complete isolation from each other. This costs another ~10% of speed
with no accuracy improvement.
That's all the major stuff. The only major speed advantages you could
pull off after that without losing accuracy would require rewriting
stuff in assembler. I'd estimate you could get a ~50-100% speedup by
rewriting every critical area in assembler.
Really, bsnes just isn't an emulator that's built for speed. If I tried
insane optimizations for speed, the code would become a mess and I'd be
chasing phantom bugs in the CT Black Omen screen for the next ten
years. Ideally, what would be best would be for someone with the time
to maintain a speed-fork. Using my actual research and findings, but
relying on more common techniques like processor enslavement and more
advanced synchronization tricks like time-stamping and rewinding.
Quote: |
I
hope in the future (if you have the time to work on this of course) we
can manage to get all the pre 0.019 video options back in |
The only other video options I am aware of were the progressive /
interlace scanline intensity settings. I was able to do that because I
had free Direct3D alpha blending. Now, I'd need a luma table. Maybe
some day. Any others?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 14, 2008 9:47 pm Post subject: |
|
Hmm,
okay. I was speaking with blargg ... perhaps the incorrect stack
alignment was to blame? Please try the below co_create. Maybe it'll
help.
As always, make sure -fomit-frame-pointer
is used, or co_switch will generate prologue code that will cause all
sorts of hell.
Code: |
cothread_t co_create(unsigned int size, void (*entrypoint)(void)) {
cothread_t handle;
assert(sizeof(long) == 4);
if(!co_active_) co_active_ = &co_active_buffer;
size += 128; /* allocate additional space for storage */
if(handle = (cothread_t)calloc(size, 1)) {
long *p = (long*)(((long)handle + size) & ~15); /* seek to top of stack */
*--p = (long)crash; /* crash if entrypoint returns */
*--p = (long)entrypoint; /* start of function */
*(long*)handle = (long)p; /* stack pointer */
}
return handle;
} |
If it's still crashing, perhaps try compiling with -S or whatever and
posting the assembler output of co_switch ...
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Feb 14, 2008 9:53 pm Post subject: |
|
Hey,
no worries, Byu. I didn't mean to make you feel bad. I was just asking;
that's all. I know jack squat about programming as complex a system as
SNES
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 10:39 pm Post subject: |
|
same
bus error also with this new version. I always used the same compile
options you posted the first time, so I wouldn't blame the compiler...
I then tried to compile also test_timing.cpp with the -S option and this is the test_timing.s output
http://www.sendspace.com/file/hbkakz
(I assume this was the thing you were asking me to do... but I'm a bit
tired here at GMT+1 and it was a bad day at work, so maybe I'm missing
something obvious. if so, please be patient and let me know which
assembler output you need)
finally, did you see dvdmth post about co_trade running at least once
before the crash? maybe it can help to single out the issue |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 14, 2008 10:57 pm Post subject: |
|
byuu wrote: |
Quote: |
I
hope in the future (if you have the time to work on this of course) we
can manage to get all the pre 0.019 video options back in |
The only other video options I am aware of were the progressive /
interlace scanline intensity settings. I was able to do that because I
had free Direct3D alpha blending. Now, I'd need a luma table. Maybe
some day. Any others?
|
Well, I don't know if you'd call them video options, but as I mentioned
before, 100% full screen (for 4:3 displays) used to be nice. Other than
that you already mentioned progressive/interlace settings so that would
be pretty much it.
edit: Might as well put it here...(I know this otoh, was never present in any version of bsnes)
Perhaps one of those days: blargg's NTSC filter (v2.0?) additional
options found in Zsnes 1.51 (artifacts,bleeding,hue warping...) You
know, the stuff Fitzroy hates ^_^
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 14, 2008 11:09 pm Post subject: |
|
Oops, sorry. Forgot to respond to this last time.
Quote: |
It
appears the crash is actually happening during the second call to
co_switch(), to return to the main thread. However, I can't step
through that function, because gdb can't handle the assembly language
portion (for obvious reasons).
Does this help any? |
Yes, this plus the stack alignment test rules out that co_create()
isn't the problem. But unfortunately, that leaves me back where I
started. With no idea what's going on x.x
Quote: |
And
maybe one day: blargg's NTSC filter (v2.0?) additional options found in
Zsnes 1.51 (artifacts,bleeding,hue warping...) You know, the stuff
Fitzroy hates ^_^ |
I really need a good system for providing these options to users. I
could stick them all in advanced, but it's a pretty poor place to put
that stuff. And I really don't want a million tabs inside the config
settings panel for each filter, each driver, etc etc.
Perhaps it's time to merge a list + tab combination interface ...
Quote: |
(I
assume this was the thing you were asking me to do... but I'm a bit
tired here at GMT+1 and it was a bad day at work, so maybe I'm missing
something obvious. if so, please be patient and let me know which
assembler output you need) |
I need the libco.c assembler output, please. Thank you very much for
the help, feel free to get some rest, we can work on this when you're
more up to it :)
Thanks again.
Quote: |
finally,
did you see dvdmth post about co_trade running at least once before the
crash? maybe it can help to single out the issue |
Good catch, thanks.
|
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 14, 2008 11:23 pm Post subject: |
|
Quote: |
I
need the libco.c assembler output, please. Thank you very much for the
help, feel free to get some rest, we can work on this when you're more
up to it 
Thanks again. |
just to avoid misunderstanding and further mistakes by my side, do you
mean to compile only the final step with -S and post the result?
otherwise, could you post a step by step procedure to obtain the file
you need?
almost time go to to sleep... zzz...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 14, 2008 11:47 pm Post subject: |
|
byuu wrote: |
I
really need a good system for providing these options to users. I could
stick them all in advanced, but it's a pretty poor place to put that
stuff. And I really don't want a million tabs inside the config
settings panel for each filter, each driver, etc etc.
Perhaps it's time to merge a list + tab combination interface ... |
Perhaps you could add an "Advanced Options" button for the filters that
have them, (greyed out for the ones that don't) that opens a dialog
with the relevant sliders/checkboxes.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 15, 2008 12:28 am Post subject: |
|
Quote: |
just
to avoid misunderstanding and further mistakes by my side, do you mean
to compile only the final step with -S and post the result? otherwise,
could you post a step by step procedure to obtain the file you need?
almost time go to to sleep... zzz... :) |
Nah, the middle one, gcc -S -fomit-frame-pointer libco.c or whatnot. Forget the exact syntax for -S.
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Fri Feb 15, 2008 12:55 am Post subject: |
|
Here's the generated assembly code for co_switch (hope I got it all):
Code: |
.globl _co_switch
_co_switch:
pushl %ebx
movl 8(%esp), %eax
call L24
"L00000000004$pb":
L24:
popl %ebx
movl (%eax), %ecx
movl _co_active_-"L00000000004$pb"(%ebx), %edx
movl %eax, _co_active_-"L00000000004$pb"(%ebx)
movl %esp,(%edx)
movl (%eax),%esp
addl $4,%esp
movl %ebp, 4(%edx)
movl %esi, 8(%edx)
movl %edi,12(%edx)
movl %ebx,16(%edx)
movl 4(%eax),%ebp
movl 8(%eax),%esi
movl 12(%eax),%edi
movl 16(%eax),%ebx
jmp *(%ecx)
popl %ebx
ret |
Compiled with: gcc -S -O3 -fomit-frame-pointer ../libco.c
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Feb 15, 2008 5:00 am Post subject: |
|
Haha,
that's the same crap I see for PowerPC on OS X, and what is breaking
it. That pushl %ebx is screwing everything up, but it's something the
compiler inserts invisibly in order to access globals. The call is just
to get the program counter, which it pops off the stack into %ebx.
Maybe it's because it's being compiled as a shared library or
something? Would -static help? |
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Fri Feb 15, 2008 5:33 am Post subject: |
|
blargg wrote: |
Haha,
that's the same crap I see for PowerPC on OS X, and what is breaking
it. That pushl %ebx is screwing everything up, but it's something the
compiler inserts invisibly in order to access globals. The call is just
to get the program counter, which it pops off the stack into %ebx.
Maybe it's because it's being compiled as a shared library or
something? Would -static help? |
Right on! Adding -static removes that fancy call and produces a working
executable, at least for me. Hopefully Bannister has the same success
(can hardly wait for bsnes to be finally updated on OSX).
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 15, 2008 2:01 pm Post subject: |
|
Code: |
pushl %ebx
movl 8(%esp), %eax
call L24 |
Yeah, that shouldn't be there.
Quote: |
Right
on! Adding -static removes that fancy call and produces a working
executable, at least for me. Hopefully Bannister has the same success
(can hardly wait for bsnes to be finally updated on OSX). |
Awesome! It worked for Richard Bannister, too. Thanks blargg! :D
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 15, 2008 6:21 pm Post subject: |
|
Something
cool, blargg helped me with writing 2D filtering code. With that, I was
able to apply my 2-tap and 4-tap 1D filters to 2D video output :)
That is to say, I have linear (2), cosine (2), cubic (4) and hermite (4).
You can grab two screenshots of each filter from this link:
<edit: updated link, see below>
Compared to each other, there's little difference, but compared to the
built-in hardware scaler, it's night and day. Hardware scaler sucks.
Ignore the awful framerates. It's because the algorithm is unoptimized
and supports arbitrary scaling. An optimized 2x scale wouldn't be
nearly as bad.
Last edited by byuu on Fri Feb 15, 2008 6:37 pm; edited 1 time in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 15, 2008 6:26 pm Post subject: |
|
Hmm, says the file is currently unavailable. Since you posted 3 minutes ago, though, maybe it's not available -yet- 
Edit: yep, it's there now.
Last edited by Verdauga Greeneyes on Fri Feb 15, 2008 6:36 pm; edited 1 time in total |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 15, 2008 6:34 pm Post subject: |
|
Downloaded
fine over here. They seem to have slight differences in being
contrasted... cubic being the most so, and linear being the least. Hw
is a bit blurred. The contrast change is most apparent in the trees in
the background... cubic shows the two colors of said trees as being
very different, where the other modes seem to blend them/more
accurately worded, place them closer together in the spectrum. The
"brick work" on the castle wall also goes through varying degrees of
line thickness and such.
None of this really means anything to me, but it's still pretty cool  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 15, 2008 6:35 pm Post subject: |
|
http://www.megaupload.com/?d=W8M8HKOO
Added 3x + aspect correction hardware vs hermite filtering example. A
shame it's so ungodly slow to do this stuff in software. It'd be fun to
offer these instead of the hardware filters. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Feb 15, 2008 6:44 pm Post subject: |
|
The file you are trying to access is temporarily unavailable. 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Fri Feb 15, 2008 6:47 pm Post subject: |
|
Link works for me...
Edit: i was referring to the first link, not the second. >.< |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Feb 15, 2008 7:54 pm Post subject: |
|
Hey Byuu.
I got my parts in finally and built my Quad core computer. I'm running
Vista 64-bit Ulitmate edition. Was there a specific frame rate test I
can perform and report here for the bsnes wips? I just tested 28.06 by
running Chrono Trigger and watching the FPS counter during the demo.
The lowest it reported was 87 fps during the scene with the black ship
phasing in on the bottom of the screen. This was with frame skipping
set to zero btw. |
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Feb 15, 2008 8:15 pm Post subject: |
|
byuu wrote: |
Something
cool, blargg helped me with writing 2D filtering code. With that, I was
able to apply my 2-tap and 4-tap 1D filters to 2D video output 
That is to say, I have linear (2), cosine (2), cubic (4) and hermite (4).
You can grab two screenshots of each filter from this link:
<edit: updated link, see below>
Compared to each other, there's little difference, but compared to the
built-in hardware scaler, it's night and day. Hardware scaler sucks.
Ignore the awful framerates. It's because the algorithm is unoptimized
and supports arbitrary scaling. An optimized 2x scale wouldn't be
nearly as bad. |
Not sure if you noticed, but I've got bicubic catmull-rom spline 2x and
3x filters I wrote a few years ago included in gambatte. It's pretty
slow (especially since it's all in C++), but the 2x one is quite a bit
faster than hq2x. I don't think the 3x one compares as favourably to
hq3x though (edit: actually maybe it does) . Since you're changing the
aspect ratio for the SNES that's probably a bit slower, but it also
makes such a filter more useful (unless you were planning to leave the
aspect ratio correction up to the hardware scaler).
Last edited by sinamas on Fri Feb 15, 2008 11:50 pm; edited 1 time in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Feb 15, 2008 8:46 pm Post subject: |
|
Well i checked out the image used for that shadow mask and this is what it looks like up close
It's clear to see that each mask-hole is made out of 9 individual pixels.
this means the mask will always be at least the size of 9 pixels, where in reality this mask is the size of 1 pixel.
Maybe if the dark parts where made brighter by a few shades the mask
would be less obvious and the effect more like the real thing? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 15, 2008 9:41 pm Post subject: |
|
FirebrandX wrote: |
Hey Byuu.
I got my parts in finally and built my Quad core computer. I'm running
Vista 64-bit Ulitmate edition. Was there a specific frame rate test I
can perform and report here for the bsnes wips? I just tested 28.06 by
running Chrono Trigger and watching the FPS counter during the demo.
The lowest it reported was 87 fps during the scene with the black ship
phasing in on the bottom of the screen. This was with frame skipping
set to zero btw. |
bsnes minimum requirements are already known, but it's always
interesting to hear what speeds new chips can get. CT black omen is the
preferred test and will reveal your minimum fps, which is really the
only number that matters. Cores don't matter at all for bsnes and never
will, so if you're trying for the best single-thread program speed,
only stuff like architecture and clockspeed matters. A 3.2ghz dual core
penryn will heavily outperform a 2.2ghz quad core penryn.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 15, 2008 9:48 pm Post subject: |
|
tetsuo55 wrote: |
It's clear to see that each mask-hole is made out of 9 individual pixels.
this means the mask will always be at least the size of 9 pixels, where
in reality this mask is the size of 1 pixel.
Maybe if the dark parts where made brighter by a few shades the mask
would be less obvious and the effect more like the real thing? |
If I can ever get my scaling code to work properly I've got a few ideas
I'd like to try that emulate my Sony CRT. It uses that other technique
(not shadow masking), can't remember what it's called.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Feb 15, 2008 10:07 pm Post subject: |
|
Quote: |
I've
got a few ideas I'd like to try that emulate my Sony CRT. It uses that
other technique (not shadow masking), can't remember what it's called. |
Aperture grille, a very fine row of vertical wires under tension. If
you do this, you'll also be doing an LCD, since the pattern is the
same. The only difference is that on an LCD, each pixel is perfectly
aligned with an RGB triplet, while on a Trinitron CRT it's not, since
the phosphor triplet pitch almost never matches the width of a pixel,
and the electron beam bleeds over into neighboring phosphors. The best Trinitron/low-resolution LCD approximation I came up with
is 50% green on odd columns, 50% red and blue on even columns, but like
all these it works best on an LCD. With the common RGB RGB RGB RGB...
arrangement, this gives RgB rGb RgB rGb (where lowercase is 50%), which
properly spreads out the "phosphors" without darkening things too much.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Fri Feb 15, 2008 10:09 pm Post subject: |
|
FitzRoy wrote: |
FirebrandX wrote: |
Hey Byuu.
I got my parts in finally and built my Quad core computer. I'm running
Vista 64-bit Ulitmate edition. Was there a specific frame rate test I
can perform and report here for the bsnes wips? I just tested 28.06 by
running Chrono Trigger and watching the FPS counter during the demo.
The lowest it reported was 87 fps during the scene with the black ship
phasing in on the bottom of the screen. This was with frame skipping
set to zero btw. |
bsnes minimum requirements are already known, but it's always
interesting to hear what speeds new chips can get. CT black omen is the
preferred test and will reveal your minimum fps.
|
I just finished "The Firemen" (J version) on copier and from what I
tested with bsnes, the intro seems to be as demanding as the CT Black
Omen part...only it's constant and you don't have to wait 1 minute. So
I don't know, maybe it would be a good benchmark test. The result I got
may not be representative though, so maybe if you could give us the
results compared to CT...
The intro has a heavy "distortion" flame effect similar to the CT black
omen part, so that would perhaps explain it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 15, 2008 10:29 pm Post subject: |
|
blargg wrote: |
Quote: |
I've
got a few ideas I'd like to try that emulate my Sony CRT. It uses that
other technique (not shadow masking), can't remember what it's called. |
Aperture grille, a very fine row of vertical wires under tension. If
you do this, you'll also be doing an LCD, since the pattern is the
same. The only difference is that on an LCD, each pixel is perfectly
aligned with an RGB triplet, while on a Trinitron CRT it's not, since
the phosphor triplet pitch almost never matches the width of a pixel,
and the electron beam bleeds over into neighboring phosphors. The best Trinitron/low-resolution LCD approximation I came up with
is 50% green on odd columns, 50% red and blue on even columns, but like
all these it works best on an LCD. With the common RGB RGB RGB RGB...
arrangement, this gives RgB rGb RgB rGb (where lowercase is 50%), which
properly spreads out the "phosphors" without darkening things too much.
|
Yeah, I want to see if I can approach more how it looks to us from a
distance, but include what's actually happening. Anyway, I could
explain my idea but I dunno if it'll even work yet, so I'll try and get
a result first. I did finally fix my scaling code, so I can get working
on this.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Fri Feb 15, 2008 11:05 pm Post subject: |
|
Blargg > your simulation actually looks very good.
Here are my theories on correct CRT simulation, assuming square pixels on the monitor
In its most basic (digitized) form at tv is:
A 4:3 square with with a resolution of 720*576 for PAL or 720*480 for NTSC
each horizontalpixel is made out of 6 lines: black,red,black,green,black,blue,black
NOTE "Each colored pixel can bleed over the black lines next to it"
So all the information on a single horizontal line is 4320 pixels wide.
so each single pixel has a resolution of 6*1 with an aspect ratio of
4:3 so that means that to represent each pixel we have a resolution of
6*4,5 where the height 4.5 always contains the same data in each of the
4.5 pixels
This means we now have a total resolution of 4320*2592 for PAL or 4320*2160 for NTSC
we can now stretch the image to fit into this grid we created, the
resulting image should then be resized down to to actual screen size of
720*540 for both pal and ntsc
A TV shows either 720*576 for PAL or 720*480 for NTSC of information in
a 720*540 4:3 square. (as you can see in this tiny tv example PAL data
is lost (this tv would in fact only be about 2 inches in size))
in this square is actually 4320*2592 for PAL or 4320*2160 for NTSC of image data
So for an NTSC example, place the high resoltion overlay on the 720*480
image then resize the endresult to 720*540. this would be the smallest
image size (bsnes 1x output)
and then for a real snes example
Stretch 256x224 to 4320*2160 overlay the 4320*2160 grid on that, and
recalculate all te colors based on the fosfors and black lines. Resize
the resulting image to 720*540
again this is based on a 2.2 inch television, a 17 inch television
would actually have a grid in the range of "34560*17280" !!
however i think that with some testing a pretty good average can be
found, where the difference in the resulting image would be less than 5%
resizing the screen would be as follows
1.0x 720*540
1.5x 1080*810
2.0x 1440*1080 |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Feb 16, 2008 12:27 am Post subject: |
|
Quote: |
so each single pixel has a resolution of 6*1 with an aspect ratio of 4:3 |
Virtually every time I see 4:3 mentioned these days, there is sure to
be something else equated with this that is not 4:3. Let's review the
starting conditions with our critical thinking caps on:
Quote: |
In its most basic (digitized) form at tv is:
A 4:3 square with with a resolution of 720*576 for PAL or 720*480 for NTSC |
OK, you're digitizing a 4:3 rectangle at 720x480 (NTSC). The rectangle
is 4 units wide (in relation to the height), therefore the width of
each pixel is 4/720 units. Applying the same to the height, each pixel
is 3/480 units high. Therefore, the aspect ratio of each of these
pixels is 4/720:3/480 = 8:9, not 4:3. The only time the aspect ratio of
the pixels would match that of the original rectangle is if you used
the same number of pixels horizontally as vertically, like 480x480 or
720x720.
Quote: |
This means we now have a total resolution of 4320*2592 for PAL or 4320*2160 for NTSC |
If you digitize the image to 720x480 (NTSC), then expand each pixel
horizontally by a factor of 6 and want to preserve their aspect ratio,
you should also expand them vertically by that same factor of 6,
yielding 720*6x480*6 = 4320x2880.
Later you say something about a 2 inch television; from what I've seen,
the phosphors are larger on bigger tubes, rather than than being more
closely spaced. It's only on computer displays that they have a fairly
constant spacing, since the purpose of getting a larger display is to
have more overall detail, unlike a TV where the video signal encoding
is the main limitation on detail.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 16, 2008 12:44 am Post subject: |
|
Well, this sucks. Something I've suspected for a long time:
http://www.toledo-bend.com/colorblind/Ishihara.html
My results:
The top left I can easily make out as "25".
The top right takes me a minute, but I can barely tell it's "29".
The middle left, I can very faintly see the "45", but I could easily mistake it for another number.
The middle right is easy, "56".
The bottom left, I cannot make out at all. Not even a little.
The bottom right takes me a minute or two, but all I can see is a "5" or "6", not an "8".
Essentially, this means I'm partially deuteranopic. I fare better than
the average case, but I'm still unable to pass most of the tests for it.
I used to be able to pass these tests as a child, but just barely; so
clearly my color vision (and memory, and ...) is deteriorating with age.
Anyway, it's not a big deal. But it lends itself to one major problem:
I probably shouldn't be selecting the default color adjustments for
bsnes when I have color vision deficiency.
The thing is, I'm only adjusting all three channels equally, so I don't
think color deficiency matters all that much.
So, I know picking between Overload's exponential gamma ramp adjust or
not is like picking between the ZSNES GUI and the Snes9X GUI; but is
the choice of gamma ramp + 0.8x gamma really, really out of place to any of you trichromatic bastards? :P
I really want to avoid the standard 1:1 mapping, it's so unbelievably
washed out that it causes me great pain to look at.
---
Also, Richard Bannister noted one issue with porting. Rather than using
a Makefile, he pretty much adds all .c and .cpp files to a project and
builds. Well, that works rather poorly since I kind of go against the
norm and #include .c and .cpp files. I prefer one object per "concept",
rather than one object per "file". Yeah, sue me.
Anyway, I was thinking of a way to avoid this. Perhaps in each file
that should be compiled, #define foo. Then in each file that should not
be directly compiled, add #ifdef foo { ... } #endif to it.
Sound good? Or is there a better way? If this is a standard programming
practice, what should "foo" be named? If not, I guess I'll have to make
a name up for it. I'm running out of video game character names, though
:P |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 16, 2008 1:08 am Post subject: |
|
byuu wrote: |
Well, this sucks. Something I've suspected for a long time:
http://www.toledo-bend.com/colorblind/Ishihara.html
My results:
The top left I can easily make out as "25".
The top right takes me a minute, but I can barely tell it's "29".
The middle left, I can very faintly see the "45", but I could easily mistake it for another number.
The middle right is easy, "56".
The bottom left, I cannot make out at all. Not even a little.
The bottom right takes me a minute or two, but all I can see is a "5" or "6", not an "8".
Essentially, this means I'm partially deuteranopic. |
Sorry to read that byuu. Although, From what little I'm reading on the
subject, it doesn't sound like something particularly severe or life
altering. Just a less acute (compared to average) ability to distingish
between color tones.
Fwiw, I passed the test easily but who knows, there's probably some
color test somewhere that I would fail that someone else would pass.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Feb 16, 2008 1:14 am Post subject: |
|
I
thought that "5 or 2" test below the main six was pretty tough,
although I can only see a 5 now that I know the choices (I wondered if
it might be an S). Anyway, I'm sorry to hear about your results, byuu.
I've never had any complaints about the colour scheme bsnes uses though. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 16, 2008 1:45 am Post subject: |
|
byuu wrote: |
I used to be able to pass these tests as a child, but just barely; so
clearly my color vision (and memory, and ...) is deteriorating with age. |
Unfortunately, I think you may
suffer from a lethal condition known as "Aging"... This devastating
illness which doesn't currently have a cure, causes millions of victims
each years...Fortunately, it is still amongst the lesser causes of
death, with famine, war, murder, cancer, various illnesses etc combined
far surpassing age-related death [/end weak dark humor]
Quote: |
I
thought that "5 or 2" test below the main six was pretty tough,
although I can only see a 5 now that I know the choices (I wondered if
it might be an S) |
Likewise here. Frankly, the whole thing seems like no big deal. But
explain that to modern day medicine..."Quick, bring on the genetic
counseling! Some folks may have troubles distinguishing between shades
of colors! Think of the life challenges they will face when asked to
take the Ishihara color test!"
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 16, 2008 4:40 am Post subject: |
|
I
didn't have a problem making out any of the numbers in that test. My
grandfather was color-blind, though, and sometimes had problems seeing
certain traffic lights. He would often look at the cars around him to
know what to do.
It's hard to say what is more
"accurate" in terms of the color presets. The standard preset seems to
reveal more information in really dark areas, like Ozzie's palace in CT
while the optimal preset crushes it, but to my eye the optimal preset
has more "punch" in most games. |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Sat Feb 16, 2008 6:39 am Post subject: |
|
you'd really have to consult an eye doctor before declaring yourself going colour blind.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Feb 16, 2008 8:39 am Post subject: |
|
FitzRoy wrote: |
I
didn't have a problem making out any of the numbers in that test. My
grandfather was color-blind, though, and sometimes had problems seeing
certain traffic lights. He would often look at the cars around him to
know what to do.
|
Ummm.... why didn't anyone ever point out to him that there's a
standard orientation for just that reason? Top/left is stop,
bottom/right is go.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 16, 2008 9:09 am Post subject: |
|
I
don't know, but I'm guessing it's more difficult for color-blind people
to distinguish what light is actually illuminated when their blindness
makes them see a shade rather than a hue. In bright sunlight with older
lights, that might have been pretty tough. Also, caution lights simply
alternate colors. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Feb 16, 2008 9:20 am Post subject: |
|
is
it Red-Green? or more complete? it doesn't really matter though, you
still have a firm grip of shading, it must stink to find out now for
you personally, but as a user I'm not worried about it, I know it
hasn't affected bsnes yet.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Feb 16, 2008 9:43 am Post subject: |
|
Too
bad about the test results, you should indeed consult a doctor though,
some things are fixable. As for natural cure's, you should know that
tomatoes, spinach and carots are well known for their power to
fix/prevent eye problems. In a multiyear study with elderly people with
major eye problems were given different kinds of berries to eat daily,
some of them made a full recovery!
i wish you the best of luck with it
Back to the tv simulation problem
We basically have 3 different things we need to keep in mind
1. The TV has a maximum digital resolution of 720*480 or 720*576
2. The TV is unaware of the aspect ratio of this data
3. The image we see is actually a large grid of phosphors, this grid
can be any resolution depending on the quality of the TV
4. The phosphor grid has a 4:3 shape, each individual phosphor triplet
does not have to be 4:3, it could be any shape and size depending on
the quality of the TV and the used masking style.
To accurately simulate the tv i think the following needs to be done
1. a phosphor map should be created of several pal and ntsc tv's
2. the selected phosphor map should be overlay'd on the output image
(this means stretching the image to the resolution of the phosphor
map)(any resolution above 720*480/576 would have to be downscaled to
these maximums first, upscaling is not needed due to the analogueness
of the tv)
3. each phospor can be recalculated to a single digital pixel
3.1 for low resolution output, each phosphor triplet can be recalculated to a single digital pixel
as the phosphor map consist of hundreds of half pixels the color will
change in certain erea's like the NTSC filter currentluy does, this
should result in more accurate colors and softer edges like on a real tv
So an accurate example for the snes would be:
A tv needs to be able to display 720*480, this means the phosphor grid
has to have at least 800*600(4:3) phosphor triplets
each phosphor triplet is 6 pixels wide, so the grid is 4800*3600
The snes is stretched over the 4800*3600 grid, then a 800*600 grid is
placed over this image, the colors within the grid are resampled and a
800*600 image is output, i think this image would closely match a tv
from a 1 meter distance (where the grid is no longer visable) |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Feb 16, 2008 11:38 am Post subject: |
|
Snark wrote: |
I
just finished "The Firemen" (J version) on copier and from what I
tested with bsnes, the intro seems to be as demanding as the CT Black
Omen part...only it's constant and you don't have to wait 1 minute. So
I don't know, maybe it would be a good benchmark test. The result I got
may not be representative though, so maybe if you could give us the
results compared to CT...
The intro has a
heavy "distortion" flame effect similar to the CT black omen part, so
that would perhaps explain it. |
I get 35 fps for Firemen and 29..30 for the Black Omen scene (bsnes v0.28).
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 16, 2008 11:54 am Post subject: |
|
Sorry
if I seemed alarmist or anything, it's really not that big of a deal.
It doesn't really change my existing quality of life. It's just a bit
disappointing to know I'm missing out on some of the color vibrancy
that others experience. I can't help but wonder what others see looking
at games like Zelda and Star Ocean now. And of course, let's say I were
to color in a picture. It would suck to choose a nice skin tone, only
to have others wonder why the hell I made the character look like he
had jaundice :P
Could be a lot worse -- being totally colorblind would absolutely suck.
Hell, honestly, even having four cone types like some women have would
suck, as the world caters to the norm. Even if you were right, it'd be
annoying that 80+% of the world tells you you're wrong about what a
certain color looks like.
Quote: |
My
grandfather was color-blind, though, and sometimes had problems seeing
certain traffic lights. He would often look at the cars around him to
know what to do. |
I had a school teacher with the same problem. It's not hard to tell
with top-to-bottom lights, but it's really hard to tell when you have
left-to-right and solo-flashing lights (eg red or yellow? Do I yield or
stop?) He did the same thing your grandfather did -- pay attention to
other drivers for clues.
This typically only affects those who are completely missing one or
more cone types. I can tell the primary colors apart very, very easily.
So driving isn't a problem for me.
Quote: |
you'd really have to consult an eye doctor before declaring yourself going colour blind. |
I remember passing the test ten years ago, and I can't now. I don't
really think you need a PhD to determine the conclusion from that.
Just red-green. I can tell red from green on a monitor very easily. But
sometimes with things like LEDs, I can't tell whether the color is
green or orange. Deduction tells you that it's almost certainly green,
of course.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Feb 16, 2008 4:52 pm Post subject: |
|
byuu wrote: |
Quote: |
you'd really have to consult an eye doctor before declaring yourself going colour blind. |
I
remember passing the test ten years ago, and I can't now. I don't
really think you need a PhD to determine the conclusion from that.
|
Are you confident about the color calibration/reproduction of your
monitor? It could easily affect the colors you see in those tests.
Obviously most people's monitors are all slightly different in color
representation. Those color tests should probably only be taken using
(properly color-calibrated) printed pages.
For what its worth, I can only clearly discern the 25 and the 56. I can
see a faint outline of something in the top-right circle. The other
three are all just spots.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Sat Feb 16, 2008 5:11 pm Post subject: |
|
byuu wrote: |
Also,
Richard Bannister noted one issue with porting. Rather than using a
Makefile, he pretty much adds all .c and .cpp files to a project and
builds. Well, that works rather poorly since I kind of go against the
norm and #include .c and .cpp files. I prefer one object per "concept",
rather than one object per "file". Yeah, sue me.
Anyway, I was thinking of a way to avoid this. Perhaps in each file
that should be compiled, #define foo. Then in each file that should not
be directly compiled, add #ifdef foo { ... } #endif to it.
Sound good? Or is there a better way? If this is a standard programming
practice, what should "foo" be named? If not, I guess I'll have to make
a name up for it. I'm running out of video game character names, though
:P |
If you use a macro guard, I'd suggest calling "foo" the same as the
file in which it should be included. For instance, if "first.c"
includes "second.c", set "foo" to "FIRST_C". This would make the intent
of the defined symbol somewhat more clear for those looking at the code
(you can also include a comment in the sub-file like "Make sure we are
within such-and-such file").
Years ago, I encountered a project in which a .cpp file was being
included by a .h file (I believe because the class was using
templates). In that project, instead of using the normal .cpp
extension, the extension .template was used. I was told that this was
to prevent someone from compiling that file individually my mistake. I
don't know how Xcode would handle this, though, so I wouldn't recommend
using this technique.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Sat Feb 16, 2008 5:22 pm Post subject: |
|
Quote: |
Quote: |
you'd really have to consult an eye doctor before declaring yourself going colour blind. |
I remember passing the test ten years ago, and I can't now. I don't
really think you need a PhD to determine the conclusion from that.
|
I suggest you see an Optician. The sooner the better. If you do indeed
have colour blindness, there are some treatments available for various
mild forms, such as tinted contact lenses and glasses.
Edit: This is an interesting website that has some real-world
colour-blindness simulations rather than just the dot-test:
http://critiquewall.com/2007/12/10/blindness?page=1
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
Last edited by Clements on Sat Feb 16, 2008 5:55 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Feb 16, 2008 5:51 pm Post subject: |
|
Jipcy wrote: |
For
what its worth, I can only clearly discern the 25 and the 56. I can see
a faint outline of something in the top-right circle. The other three
are all just spots. |
As that matches the result for colour-blindness, I take it you are?
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Feb 16, 2008 6:09 pm Post subject: |
|
FitzRoy wrote: |
It's
hard to say what is more "accurate" in terms of the color presets. The
standard preset seems to reveal more information in really dark areas,
like Ozzie's palace in CT while the optimal preset crushes it, but to
my eye the optimal preset has more "punch" in most games. |
I totally agree with this. The "punch" looks nice most of the time, but
I almost always use the "standard" preset now. It just works!
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 16, 2008 7:42 pm Post subject: |
|
creaothceann wrote: |
Snark wrote: |
I
just finished "The Firemen" (J version) on copier and from what I
tested with bsnes, the intro seems to be as demanding as the CT Black
Omen part...only it's constant and you don't have to wait 1 minute. So
I don't know, maybe it would be a good benchmark test. The result I got
may not be representative though, so maybe if you could give us the
results compared to CT...
The intro
has a heavy "distortion" flame effect similar to the CT black omen
part, so that would perhaps explain it. |
I get 35 fps for Firemen and 29..30 for the Black Omen scene (bsnes v0.28).
|
Yeah, Black Omen dips to 60 for me and Firemen only dips to 78. So
Black Omen is definitely what you want to use to test.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Feb 16, 2008 8:29 pm Post subject: |
|
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". This is where I notice
little molecule-looking structures swishing across my field of vision,
epecially when looking at a plain object like a wall. When I was a kid,
I didn't know what it was and assumed I was seeing dust on the surface
of my eye. It wasn't until years later I found out it was eye-jelly
clumps floating inside my eyes and not on them. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 16, 2008 8:32 pm Post subject: |
|
FitzRoy wrote: |
creaothceann wrote: |
Snark wrote: |
I
just finished "The Firemen" (J version) on copier and from what I
tested with bsnes, the intro seems to be as demanding as the CT Black
Omen part...only it's constant and you don't have to wait 1 minute. So
I don't know, maybe it would be a good benchmark test. The result I got
may not be representative though, so maybe if you could give us the
results compared to CT...
The
intro has a heavy "distortion" flame effect similar to the CT black
omen part, so that would perhaps explain it. |
I get 35 fps for Firemen and 29..30 for the Black Omen scene (bsnes v0.28).
|
Yeah, Black Omen dips to 60 for me and Firemen only dips to 78. So
Black Omen is definitely what you want to use to test.
|
Thank creaothceann and FitzRoy for testing. I wondered because both the
Black Omen part and "The Firemen" intro drop at 45-46fps on my
machine...Maybe I haven't tested enough or the results were screwed one
way or another... because given those results I should also experience
lower fps on CT seeing creaothceann has a weaker cpu.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sat Feb 16, 2008 9:01 pm Post subject: |
|
FirebrandX wrote: |
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". This is where I notice
little molecule-looking structures swishing across my field of vision,
epecially when looking at a plain object like a wall. When I was a kid,
I didn't know what it was and assumed I was seeing dust on the surface
of my eye. It wasn't until years later I found out it was eye-jelly
clumps floating inside my eyes and not on them. |
holy shit so thats what that is! (20/20 vision, perfect colors, but i do see floaters)
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Feb 16, 2008 9:23 pm Post subject: |
|
A
display's gamma is critical for those tests. If it's wrong, it can make
some of the numerals visible to someone who's colorblind, since it
alters the shade that they are mapped to. As an illustration, this
first image below converted to grayscale results in a uniform gray, but
when its gamma is changed to the common 2.2 of a PC monitor (lower
image), the pattern is preserved in gray (the upper images are quite
dark, so you may need to use a magnifier program).

EDIT: Cool, found an image that only the colorblind can see:
http://www.collisiondetection.net/mt/archives/2006/06/anticolorblindn.html
Pretty lame that almost none of these online tests tell what gamma your display should be set to. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Feb 16, 2008 10:10 pm Post subject: |
|
Neat. Is there a settings with your monitor to see clearly the hidden image?
edit: Remove the red and push the blue setting all the way up on the monitor and it should appear.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Feb 16, 2008 10:40 pm Post subject: |
|
Snark wrote: |
Neat. Is there a settings with your monitor to see clearly the hidden image?.
|
I changed the display profile to assume my display had a gamma of 1.0
instead of the usual 2.2 and it was clearly visible. This page has a
great gamma and black level calibration chart and instructions on how
to adjust it:
http://normankoren.com/makingfineprints1A.html#gammachart
Last edited by blargg on Sat Feb 16, 2008 10:46 pm; edited 1 time in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Feb 16, 2008 10:46 pm Post subject: |
|
Regarding compiling the inline assembly on an Intel Mac, the propper Apple only cerified insane hack to use is:
Since -fno-PIC on an Intel Mac doesn't do anything, and you need Apple only parameters.
And for reference, on x86, -fno-PIC is the default, except of course if
you're some hacked up junkie OS where the parameters don't actually do
what they're supposed to.
_________________
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 Sun Feb 17, 2008 12:35 pm; edited 1 time in total
|
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Feb 16, 2008 11:06 pm Post subject: |
|
Snark wrote: |
Maybe
I haven't tested enough or the results were screwed one way or
another... because given those results I should also experience lower
fps on CT seeing creaothceann has a weaker cpu. |
I have an older P4 with not much cache - different architectures give different results.
tetsuo55 wrote: |
FirebrandX wrote: |
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". This is where I notice
little molecule-looking structures swishing across my field of vision,
epecially when looking at a plain object like a wall. When I was a kid,
I didn't know what it was and assumed I was seeing dust on the surface
of my eye. It wasn't until years later I found out it was eye-jelly
clumps floating inside my eyes and not on them. |
holy shit so thats what that is!
|
Yep: http://en.wikipedia.org/wiki/Floaters
_________________
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: Sun Feb 17, 2008 6:34 am Post subject: |
|
Well,
I was talking earlier about detail getting crushed in the optimal mode
in certain games, and I thought to setup some comparison images to
better show what I've seen.

Standard on the left and optimal on the right. If your monitor
brightness is too low, you may not see the disparities here. But the
track patterns in RNRR and the floor pattern in CT are getting killed
by the optimal adjustments.
If I were to come to any conclusion on this, it's that standard might
be the better default. And I'm also curious if a saturation slider is
possible or might yield better results for people wanting to add more
"punch" to their games. When I tried doing this in photoshop, it seemed
to work pretty well for the CT "standard" image. It would also make
"grayscale" unnecessary as going full negative on saturation has the
same effect. Using the "contrast" scale in photoshop also had good
results. Sorry, I'm too newb to know how these relate to gamma. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 17, 2008 10:08 am Post subject: |
|
Quote: |
Are you confident about the color calibration/reproduction of your monitor? |
Tried on at least three or four monitors. Same result.
Quote: |
If
you use a macro guard, I'd suggest calling "foo" the same as the file
in which it should be included. For instance, if "first.c" includes
"second.c", set "foo" to "FIRST_C". |
Yeah, I was thinking that. But figured since the name wouldn't matter
from project to project, consistency might be preferred. I guess we'll
go with FIRST_C then.
Quote: |
I
suggest you see an Optician. The sooner the better. If you do indeed
have colour blindness, there are some treatments available for various
mild forms, such as tinted contact lenses and glasses. |
Meh, maybe I'll look into it, then.
Quote: |
http://critiquewall.com/2007/12/10/blindness?page=1 |
The only one that doesn't look very different is the color plate. The right is just slightly brighter.
Quote: |
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". |
Well, I have 20/10 - 20/15 (far sighted, cant read books up close to my
face), but I still see floaters all the time. I was surprised when my
roommate had no idea what I was talking about. So I showed him the best
trick I know for seeing them: go out on a clear, sunny blue sky day,
lie down and stare straight up. They appear all over the place.
Needless to say he was quite shocked :)
I never knew what the hell they were as a kid. You'd think that would
be something they'd teach you in school. Instead, most of my "ailments"
I have to learn about on my own.
Floaters, orthostatic hypotension, far-sightedness, color deficiency
(they don't tell you the results of your tests anyway, probably so as
not to discourage you), and other things ... all stuff I always thought
were personal problems which turn out to be much more common. And I
still find new ones to this day -- each time making me feel just a
little bit less unique :)
Funny, you'd think in this society where our main goal for all our
problems is proving that they aren't "our fault", there'd be a lot of
interest in writing these off, too.
Quote: |
http://www.collisiondetection.net/mt/archives/2006/06/anticolorblindn.html |
I can see the first one, but not the latter. Seems I'm stuck right in
the middle between red-green colorblind and normal :P
Quote: |
Standard on the left and optimal on the right. |
Hmm, is that with the RGB888 version? The gamma at 0.8 (default)
should've made the floor colors visible again. I'll have to do some
testing ...
Quote: |
Sorry, I'm too newb to know how these relate to gamma. |
Gamma is like making an exponential curve, but 0 = 0 and 255 = 255 always.
Contrast is like drawing a straight line. Only one point is stationary,
eg 0 = 0 or 255 = 255. When you adjust contrast, you're moving the
other side of the bar, and all colors get adjusted along with that line.
Brightness is moving the bar entirely. Eg +5 brightness = 0->5,
255->260 (clamped back to 255, of course. What happens is all the
brightest colors get crushed.)
From your description, saturation is apparently color intensity vs luminance. I don't know much about the others.
Anyway, try your video card driver software. They usually have config
options that show you the color bars and how they interact with color.
Last edited by byuu on Sun Feb 17, 2008 10:11 am; edited 1 time in total
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sun Feb 17, 2008 10:08 am Post subject: |
|
FirebrandX wrote: |
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". This is where I notice
little molecule-looking structures swishing across my field of vision,
epecially when looking at a plain object like a wall. When I was a kid,
I didn't know what it was and assumed I was seeing dust on the surface
of my eye. It wasn't until years later I found out it was eye-jelly
clumps floating inside my eyes and not on them. |
I've always wondered what those were.. never thought a forum thread about emulation would give the answer. (Wikipedia - Floaters)
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 17, 2008 10:25 am Post subject: |
|
Quote: |
I've
always wondered what those were.. never thought a forum thread about
emulation would give the answer. (Wikipedia - Floaters) |
This is really interesting, how many of you don't know about this.
Perhaps I should reiterate on my last comment more, then.
Quote: |
You'd think that would be something they'd teach you in school. Instead, most of my "ailments" I have to learn about on my own. |
Though off-topic, who cares? How about we all share conditions we
thought were strictly personal, but are actually quite common and have
official-sounding names? Let's not get too disgusting or too
adult-themed here, please. I'll start:
Floaters
-- translucent cells floating in your eye, that get magnified so much
that you can visually see them. Kind of like a microscope :)
Orthostatic Hypotension
-- ever get really dizzy when you stand up after sitting for a while?
Notice your vision start blacking out? Get mildly delirious thoughts
while this is happening? And it goes away in ~10-20 seconds? This is
probably what you have. Blood pressure plummets when you stand up. If
oxygen doesn't get to your brain fast enough, this is the result.
Sleep Paralysis
-- ever wake up in the middle of the night, know you're awake, yet find
you are completely unable to move? Bad dream? Nope, you're not
dreaming. You really did wake up. The body sends out signals and such
that really do paralyze you while you sleep. If you wake up while that
effect is active, you get sleep paralysis. Scary as all hell, can take
anywhere from a few seconds to a few minutes to shake it off.
Cytochrome P450 2D6
-- another white male problem. This is a liver enzyme, and if you have
a deficiency with yours, it makes psychoactive chemicals such as
alcohol much more difficult to absorb. Hence you have to take more than
others to get the same effects. You can do your own research to see
what else this affects.
Ever notice a swollen
bump somewhere on your neck? This is most likely a lymph node
infection. Anti-biotics usually help, and smaller ones usually go away
on their own.
Ones I know about that I don't have names for:
This might be part of why I'm partially colorblind -- as a very young child,
a friend showed me that if you push on your eyes while closed, you'd
see millions of patterns and colors appear and dance all over the
place. It's extremely bizarre, and most obviously very dangerous to
your eyes. Though this should be very obvious already, do not try it yourself.
Another is a form of inverse lockjaw, when you open your mouth too
wide, it will lock and give you excruciating pain while the muscles
below the mandible get stuck ... you can physically feel them there,
and it takes ~30 seconds or so for them to go down. It's most similar
to a charlie horse. Really sucks when you try eating those restaurant
burgers.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sun Feb 17, 2008 10:49 am Post subject: |
|
byuu wrote: |
This might be part of why I'm partially colorblind -- as a very young child,
a friend showed me that if you push on your eyes while closed, you'd
see millions of patterns and colors appear and dance all over the
place. It's extremely bizarre, and most obviously very dangerous to
your eyes. Though this should be very obvious already, do not try it yourself.
Another is a form of inverse lockjaw, when you open your mouth too
wide, it will lock and give you excruciating pain while the muscles
below the mandible get stuck ... you can physically feel them there,
and it takes ~30 seconds or so for them to go down. It's most similar
to a charlie horse. Really sucks when you try eating those restaurant
burgers. |
I get the inverse lockjaw, but thankfully don't get the firest thing,
though I do rub my eyes when they're closed...
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Feb 17, 2008 11:04 am Post subject: |
|
Yeah, I've had that; knew it was common (surely this happens to
everyone at one point or other) so I never looked into it. You get the
same effect from a big adrenaline rush if your body's not used to it.
Once got a cut on my wrist from a sword (don't ask); tiny thing, but it
came out of the blue. Started feeling light-headed and went to the
restroom, where I actually collapsed and blacked out for a few seconds.
If you don't know, this is because the adrenaline sends a lot of blood
into your muscles, and there ends up not being enough left for your
brain. Eating sugary things helps you recover.
I think I've had this happen to me once, like ten years ago. My memory
is terrible (very associative but completely inconsistent) so it goes
to show what a freaky experience this is.
byuu wrote: |
This might be part of why I'm partially colorblind ... |
I dunno, I've done this a million times, mostly through vigorously
rubbing my eyes as they itched from allergies - but my colour vision
and vision as a whole are fine. Of course, I'm younger than you, but no
adverse effects yet. I don't imagine it's very good for your eyes
though.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Feb 17, 2008 11:54 am Post subject: |
|
FitzRoy wrote: |
<img>http://img100.imageshack.us/img100/3531/compare2ei6.png</img>
Standard on the left and optimal on the right. If your monitor
brightness is too low, you may not see the disparities here. But the
track patterns in RNRR and the floor pattern in CT are getting killed
by the optimal adjustments. |
Would be interesting to know if they are visible on a TV set that is
calibrated "perfectly" (shows skin tones etc. correctly).
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Feb 17, 2008 12:31 pm Post subject: |
|
byuu wrote: |
Floaters
-- translucent cells floating in your eye, that get magnified so much
that you can visually see them. Kind of like a microscope 
Sleep Paralysis
-- ever wake up in the middle of the night, know you're awake, yet find
you are completely unable to move? Bad dream? Nope, you're not
dreaming. You really did wake up. The body sends out signals and such
that really do paralyze you while you sleep. If you wake up while that
effect is active, you get sleep paralysis. Scary as all hell, can take
anywhere from a few seconds to a few minutes to shake it off.
Ones I know about that I don't have names for:
This might be part of why I'm partially colorblind -- as a very young child,
a friend showed me that if you push on your eyes while closed, you'd
see millions of patterns and colors appear and dance all over the
place. It's extremely bizarre, and most obviously very dangerous to
your eyes. Though this should be very obvious already, do not try it yourself.
Another is a form of inverse lockjaw, when you open your mouth too
wide, it will lock and give you excruciating pain while the muscles
below the mandible get stuck ... you can physically feel them there,
and it takes ~30 seconds or so for them to go down. It's most similar
to a charlie horse. Really sucks when you try eating those restaurant
burgers. |
Got all of the quoted one. The sleep paralysis is a huge, huge pain in
the ass. I've found that sleeping on my side generally cuts it down by
a lot... It rarely happens now, even though I have to mostly sleep on
my back due to shoulder injuries.
It used to scare the ever living fuck out of me, but I've gotten used
ot that aspect. It is VERY uncomfortable, however.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Feb 17, 2008 1:06 pm Post subject: |
|
byuu wrote: |
Ones I know about that I don't have names for:
This might be part of why I'm partially colorblind -- as a very young child,
a friend showed me that if you push on your eyes while closed, you'd
see millions of patterns and colors appear and dance all over the
place. It's extremely bizarre, and most obviously very dangerous to
your eyes. Though this should be very obvious already, do not try it yourself. |
Intraocular hypertension - you increase pressure manually, is all.
Tickles the optic nerve, causing the hallucinations. Can be dangerous
if done too long/too hard, obviously.
Quote: |
Another
is a form of inverse lockjaw, when you open your mouth too wide, it
will lock and give you excruciating pain while the muscles below the
mandible get stuck ... you can physically feel them there, and it takes
~30 seconds or so for them to go down. It's most similar to a charlie
horse. Really sucks when you try eating those restaurant burgers. |
That's just a cramp. Most skeletal muscles can get them, submandibulars are no exception.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 17, 2008 2:22 pm Post subject: |
|
Quote: |
I get the inverse lockjaw, but thankfully don't get the firest thing, though I do rub my eyes when they're closed... |
It takes a lot more pressure than that, which is why you should not ever try it.
Quote: |
Once
got a cut on my wrist from a sword (don't ask); tiny thing, but it came
out of the blue. Started feeling light-headed and went to the restroom,
where I actually collapsed and blacked out for a few seconds. |
Wild, small cuts don't phase me much, and the biggest cuts I've gotten
(all the way to the leg bone, for instance), I don't even feel. I think
my body just realizes that it's beyond fucked at that point and doesn't
bother to send pain signals anymore :P
Anyway, the hypotension goes away quickly enough, you just get the
occasional odd comment if you blank out in front of other people. I've
only passed out once or twice from it. It's kind of like a seizure at
that point.
Quote: |
Would be interesting to know if they are visible on a TV set that is calibrated "perfectly" (shows skin tones etc. correctly). |
Yeah, definitely.
Quote: |
The sleep paralysis is a huge, huge pain in the ass.
It used to scare the ever living fuck out of me, but I've gotten used
ot that aspect. It is VERY uncomfortable, however. |
Yeah, for me it tends to come back every 2-3 years, and will happen
every other night for a few weeks and go away. But yes, it's easily one
of the most terrifying things I've experienced in life. You're still so
out of it that you think it might be permanent. Then that makes you try
and move more, then you realize you still can't, etc etc. It's like a
closed loop panic response. I hear it's worse for other people, too.
Some sense a presence in the room with them, and some hallucinate big
time. In that state, holy hell that would suck.
On the bright side, I hear a lot of people are able to enter lucid
dreams through this state. Perhaps you can try that out next time if
you're conscious enough to remember to.
Quote: |
Intraocular hypertension |
Neat! I figured there was a name for it. Interesting how similar it is
to closed eye visuals induced by certain "compounds", though I'm sure
the two mechanisms are completely different.
Quote: |
That's just a cramp. Most skeletal muscles can get them, submandibulars are no exception. |
Well that's lame :P
Though I'm not happy to hear someone else gets it, it's good to know I'm not the only one who gets that all the damn time.
So, anyone else have any examples? I'd be interested in seeing if I've missed anything I frequently experience.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sun Feb 17, 2008 4:31 pm Post subject: |
|
I've
been messing around with the gamma, brightness, and contrast in bsnes.
A problem I've noticed is that, no matter how I juggle the sliders,
there no way to increase the contrast intensity without also causing
the black levels to become washed out.
In a paint
program like photoshop, you can increase the contrast intensity while
maintaining the same black levels (the lighter colors are more vivid
and intense, while the darker colors stay dark and vivid). This does
not appear to be possible with the current sliders in bsnes.
Edit: I see that Fritzroy mentioned the same thing. Its that "Punch" as he calls it.
Last edited by FirebrandX on Sun Feb 17, 2008 4:36 pm; edited 2 times in total |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Feb 17, 2008 4:34 pm Post subject: |
|
Something interesting regarding slight color differences: compare bsnes and SNES9x (pic).
The "almost black" color below the door is 8/16/24 in bsnes (standard
preset) and 0/16/16 in SNES9x. It's best to see on a black background.
EDIT: This might be due to the RGB565 format.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
beender New Member
Joined: 03 Nov 2006
Posts: 4
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Feb 17, 2008 4:49 pm Post subject: |
|
New WIP.
Richard Bannister asked me a year ago to add support to detect the file
compression type by reading the header, as apparently Mac users can't
be bothered to use proper file extensions.
In an act of extreme expediency, I've added his request in record time :P
Here's the detection code I wrote:
Code: |
Reader::Type Reader::detect(const char *fn) {
FILE *fp = fopen(fn, "rb");
if(!fp) return Unknown;
fseek(fp, 0, SEEK_END);
unsigned size = ftell(fp);
rewind(fp);
uint8_t a = size >= 1 ? fgetc(fp) : 0;
uint8_t b = size >= 2 ? fgetc(fp) : 0;
uint8_t c = size >= 3 ? fgetc(fp) : 0;
uint8_t d = size >= 4 ? fgetc(fp) : 0;
fclose(fp);
if(a == 0x1f && b == 0x8b && c == 0x08 && d <= 0x1f) return GZIP;
if(a == 0x50 && b == 0x4b && c == 0x03 && d == 0x04) return ZIP;
if(a == 0x4a && b == 0x4d && c == 0x41 && d == 0x00) return JMA;
return Normal;
}
|
If anyone sees any problems, please let me know. And unless your name
is Nach, I expect you to read and cite official documentation to point
out any problems.
Note: I need more than 16-bit accuracy to avoid false positives, so I
read the compression type and flags for GZIP. Compression type should
always be 0x08 according to my understanding of GZ. Flag top 3 bits are
always 0 per spec. I guessed with JMA's fourth byte. I hope it's always
zero, but I don't know that for certain.
The new WIP has GZ/ZIP/JMA support built-in, so testing would be
appreciated, though I doubt you'll hit any false positives.
Now, a more important question. Should I enable this detection by default in bsnes, or go by filename? It's possible
an SNES ROM could have these headers, despite not being compressed at
all. One could even add these signatures intentionally if they really
wanted. A real SNES game could have these bytes at the top of the file,
quite obviously.
So, is it better to cater to
people who misname extensions, or to the possibility that a game might
have these bytes in the signature (a one in four billion chance of
happening accidentally. One in 500 million for GZ false detection.)
---
Also, I added some changes by KarLKoX to allow OpenAL to build on
Windows. Namely, I removed the unused ALut dependency, and added
support to the makefile to include openal32. I don't intend to build
OpenAL into the default Windows binaries (because I don't want extra
DLL dependencies that most people do not have; and because OpenAL
support sucks on Windows for non-Creative cards), but perhaps in the
future I'll offer more than one version for download.
Quote: |
The
"almost black" color below the door is 8/16/24 in bsnes (standard
preset) and 0/16/16 in SNES9x. It's best to see on a black background.
EDIT: This might be due to the RGB565 format. |
Wow, that's quite a difference. If you have bsnes v013-v019, you can
dump the palette through the memory viewer. Perhaps see what SNES9x has
from its savestate, and if it's different -- one of us has an emulation
bug.
Not an RGB565 problem, or the colors would match when ignoring the low three bits (two for green.)
bsnes:
00001000
00010000
00011000
SNES9x:
00000000
00010000
00010000
|
|
paulguy Regular
Joined: 02 Jul 2005
Posts: 280
|
Posted: Sun Feb 17, 2008 6:09 pm Post subject: |
|
On the conditions thing: I'm an albino.
I'm ridiculously white and can't see very well at all. I don't know
exactly what kind of albino but it's not one of those fatal kinds.
Also, good work on the emulator. I'd like to see more super accurate
emulators out there, now that we have the computing power for it. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Feb 17, 2008 6:28 pm Post subject: |
|
byuu wrote: |
Code: |
Reader::Type Reader::detect(const char *fn) {
FILE *fp = fopen(fn, "rb");
if(!fp) return Unknown;
fseek(fp, 0, SEEK_END);
unsigned size = ftell(fp);
rewind(fp);
uint8_t a = size >= 1 ? fgetc(fp) : 0;
uint8_t b = size >= 2 ? fgetc(fp) : 0;
uint8_t c = size >= 3 ? fgetc(fp) : 0;
uint8_t d = size >= 4 ? fgetc(fp) : 0;
fclose(fp);
if(a == 0x1f && b == 0x8b && c == 0x08 && d <= 0x1f) return GZIP;
if(a == 0x50 && b == 0x4b && c == 0x03 && d == 0x04) return ZIP;
if(a == 0x4a && b == 0x4d && c == 0x41 && d == 0x00) return JMA;
return Normal;
}
|
|
GZIP code is fine. ZIP code can be cleaner, and JMA code is a bit short.
ZIP signiture is 'P' 'K' 0x03 0x04, and JMA is 'J' 'M' 'A' 0x00 'N'.
You'd be best off reading 7 bytes, and then memcmp()'ing them.
BZip2 and JMA are both 5 bytes, and IIRC, 7z and RAR are 6 and 7 respectively.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Sun Feb 17, 2008 6:54 pm Post subject: |
|
Nach wrote: |
Regarding compiling the inline assembly on an Intel Mac, the propper
Apple only cerified insane hack to use is:
Since -fno-PIC on an Intel Mac doesn't do anything, and you need Apple only parameters.
And for reference, on x86, -fno-PIC is the default, except of course if
you're some hacked up junkie OS where the parameters don't actually do
what they're supposed to.
|
Where is -fno-PIC documented? None of the gcc docs I've looked at include that option. Am I missing something?
That being said, Apple has been known to do things differently with
their version of gcc (their docs warn that not all standard options are
available). I'm sure Apple has their reasons, but I myself have had
frustrations with their ways of doing things (especially since their
doc isn't 100% accurate in certain areas).
Anyway, the -mdynamic-no-pic option does work and is likely the better
solution, since it apparently continues to allow linking to dynamic
libraries, whereas -static apparently does not. Since libco doesn't
depend on any dylibs, the two options are essentially equivalent, but
if you wanted to apply the option to the entire project, -static would
probably cause problems. (Of course, I'm not very fluent in this area,
so I may have misunderstood something.)
byuu wrote: |
Richard
Bannister asked me a year ago to add support to detect the file
compression type by reading the header, as apparently Mac users can't
be bothered to use proper file extensions. |
I learned early on in programming that you can never assume anything
about a file you're given, that the file name and extension cannot be
trusted. And no, I did not learn this while programming for the Mac.
Believe it or not, there are files with the extension .ZIP which are
not actually compressed (they were text adventure games from back in
the days of Infocom). Not that anyone would be dumb enough to try to
play Zork on an SNES emulator...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 17, 2008 7:13 pm Post subject: |
|
I.S.T. wrote: |
It used to scare the ever living fuck out of me, but I've gotten used
ot that aspect. It is VERY uncomfortable, however. |
I've had sleep paralysis when I was very young. Never happened since then.
edit: Not scary but I remember making a conscious effort and getting
out of the sleep paralysis phase and waking up. Although I'm not
actually if that's possible at all, and maybe the sleep paralysis
period simply "wear off" itself and perhaps I falsely attributed that
my doing.
Last edited by Snark on Sun Feb 17, 2008 7:27 pm; edited 2 times in total
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Feb 17, 2008 7:17 pm Post subject: |
|
dvdmth wrote: |
Nach wrote: |
Regarding compiling the inline assembly on an Intel Mac, the propper
Apple only certified insane hack to use is:
Since -fno-PIC on an Intel Mac doesn't do anything, and you need Apple only parameters.
And for reference, on x86, -fno-PIC is the default, except of course if
you're some hacked up junkie OS where the parameters don't actually do
what they're supposed to.
|
Where is -fno-PIC documented? None of the gcc docs I've looked at
include that option. Am I missing something?
|
http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Code-Gen-Options.html#index-fPIC-1693
And don't start telling me that Apple has their reasons. There is no
reason for doing 90% of the hacks they're doing.
_________________
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: Sun Feb 17, 2008 7:39 pm Post subject: |
|
byuu wrote: |
Quote: |
The
"almost black" color below the door is 8/16/24 in bsnes (standard
preset) and 0/16/16 in SNES9x. It's best to see on a black background.
EDIT: This might be due to the RGB565 format. |
Wow, that's quite a difference. If you have bsnes v013-v019, you can
dump the palette through the memory viewer. Perhaps see what SNES9x has
from its savestate, and if it's different -- one of us has an emulation
bug.
|
Well, turns out the CGRAM content is the same... 
bsnes, ZSNES and vSNES show 8/16/24, so it's something to do with SNES9x.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Feb 17, 2008 9:02 pm Post subject: |
|
Snark wrote: |
I.S.T. wrote: |
It used to scare the ever living fuck out of me, but I've gotten used
ot that aspect. It is VERY uncomfortable, however. |
I've had sleep paralysis when I was very young. Never happened since then.
edit: Not scary but I remember making a conscious effort and getting
out of the sleep paralysis phase and waking up. Although I'm not
actually if that's possible at all, and maybe the sleep paralysis
period simply "wear off" itself and perhaps I falsely attributed that
my doing.
|
From my years of experience, it does seem ot be breakable. At least
with me, there is a tiny bit of movement possible while under the
effects of sleep paralysis. I've found that trying to move as hard as
you can will break it.
But I have no idea if that will work with other people, however.
Edit:
Quote: |
Yeah,
for me it tends to come back every 2-3 years, and will happen every
other night for a few weeks and go away. But yes, it's easily one of
the most terrifying things I've experienced in life. You're still so
out of it that you think it might be permanent. Then that makes you try
and move more, then you realize you still can't, etc etc. It's like a
closed loop panic response. I hear it's worse for other people, too.
Some sense a presence in the room with them, and some hallucinate big
time. In that state, holy hell that would suck. |
It's happened so often to me that I know what it is, and it doesn't scare me at all, even when I'm barely awake.
Never had any hallucinations, though... I'm thankful for that.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Feb 17, 2008 9:35 pm Post subject: |
|
dvdmth wrote: |
Believe
it or not, there are files with the extension .ZIP which are not
actually compressed (they were text adventure games from back in the
days of Infocom). Not that anyone would be dumb enough to try to play
Zork on an SNES emulator... |
You obviously haven't been around here very long. 
Believe me, someone has or will try it.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sun Feb 17, 2008 9:58 pm Post subject: |
|
byuu wrote: |
Some sense a presence in the room with them, and some hallucinate big time. In that state, holy hell that would suck. |
Never had hallucination with sleep paralysis either, but the
hallucination/"presence" thing might apparently explain most of the
"kidnapped/visited by extra terrestrials" some people have reported.
Being the pragmatic that I am, I found this more likely than Aliens
visiting Earth from 100 light years just to visit someone in their
sleep.
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sun Feb 17, 2008 11:13 pm Post subject: |
|
Sleep
paralysis doesn't happen to me very often, but when it does, it sure
scares the crap out of me. But I don't have hallucinations, thank
goodness.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Mon Feb 18, 2008 4:08 am Post subject: |
|
paulguy wrote: |
On the conditions thing: I'm an albino.
I'm ridiculously white and can't see very well at all. I don't know
exactly what kind of albino but it's not one of those fatal kinds.
Also, good work on the emulator. I'd like to see more super accurate
emulators out there, now that we have the computing power for it. |
I have the same thing. Ocular albinism.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 18, 2008 1:16 pm Post subject: |
|
Metatron wrote: |
I have the same thing. Ocular albinism. |
I read on Wikipedia that this can give the illusion of violet/purple irises in sunlight.. is that true?
|
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Mon Feb 18, 2008 1:18 pm Post subject: |
|
happy to see that you fixed libco on Mac Intel and sorry if I haven't managed to be more useful 
finally, a (small) request to byuu: if you would get bored by
refactoring your code, a good way to spend some time in a different way
[1] could be to write down a bit of documentation on your discoveries
(especially PPU related). this way, other authors would be able to more
easily obtain a larger accuracy degree in their emus.
thanks anyway for your efforts, and just post if you need any more mac testing 
now I'll leave you all to this medical hijacking of the thread, while
waiting for richard bannister to successfully compile and release a new
bsnes (btw those optical tests have shown that I have at least a small
color blindness which I wasn't aware of: I can spot correctly ALL the
number except the final one. with the last one, I can see the outline
of the 5 -even if it seems more an S than a 5 to my eyes- but I can
more clearly see the 2...)
[1] an even better way would be to simply take an holidays, but this is obvious  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Feb 18, 2008 3:47 pm Post subject: |
|
etabeta wrote: |
finally,
a (small) request to byuu: if you would get bored by refactoring your
code, a good way to spend some time in a different way could be to
write down a bit of documentation on your discoveries (especially PPU
related). this way, other authors would be able to more easily obtain a
larger accuracy degree in their emus. |
There's already anomie's docs, but it's written for people who are programming for the SNES... Maybe a commentary?
Another small issue could be adding a list of recently loaded ROMs to the menu. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 18, 2008 3:55 pm Post subject: |
|
byuu's
been planning to write documentation for ages, he's just never gotten
around to it. Perhaps all the experience he's gained restructuring
bsnes will help him plan out the documentation when he does, though  |
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Mon Feb 18, 2008 4:50 pm Post subject: |
|
oh,
I know that very well. even if I registered only recently and started
to post last week, I'm following this thread since its first pages and,
before first bsnes release, I was reading with interest byuu's test in
Development forum  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 18, 2008 5:02 pm Post subject: |
|
New
WIP adds an option to enable or disable filetype detection by reading
the format header. I received no feedback, so I'm defaulting to this
behavior being off. In other words, I'm defaulting to requiring the
file extension to be correct to properly handle the file. This is
because there's no reason a real SNES would behave different just
because $8000 = 'P' and $8001 = 'K', and with the option enabled by
default, you wouldn't be able to get such a game to run. But the option
is there for those who want it.
I've also added
bumpers to everything but the core (cpu, smp, ppu, dsp) and some of the
library stuff and platform-specific stuff (hiro, libfilter, libco, ui)
-- really can't add them to libco as I want each individual file to
compile on its own if the user wants. But overall, it should make
things a lot easier for those trying to build bsnes without using my
Makefile.
Not in the WIP, I just fixed a frameskipping bug. It was broken in the last few WIPs, including the most recent.
Quote: |
You'd be best off reading 7 bytes, and then memcmp()'ing them. |
Can't memcmp() the low five bits of the GZ flags byte. I'm not
concerned about rigid speed here anyway. It's just file type detection.
I changed it to fread() the bytes, that's good enough.
Thanks for the information, I've extended JMA to a 40-bit check.
Quote: |
Anyway,
the -mdynamic-no-pic option does work and is likely the better
solution, since it apparently continues to allow linking to dynamic
libraries, whereas -static apparently does not. |
Well, we use -static only when building libco.c. I like -static more,
because it exists in all versions of GCC. I will mention
-mdynamic-no-pic in the libco documentation for v0.13 official.
Quote: |
Well, turns out the CGRAM content is the same... Surprised
bsnes, ZSNES and vSNES show 8/16/24, so it's something to do with SNES9x. |
Thank you for testing! If only all beta testers had your technical prowess :D
Glad to see it's not a bug on my side. Not really in the mood to track down bugs at the moment, heh.
Quote: |
You obviously haven't been around here very long. Razz
Believe me, someone has or will try it. |
I've actually been very fortunate in that regard. At least 95%, if not
all, of bsnes users have been very intelligent and well spoken :)
Quote: |
Another small issue could be adding a list of recently loaded ROMs to the menu. |
Not a chance. I can't stand recently opened document lists.
Quote: |
now
I'll leave you all to this medical hijacking of the thread, while
waiting for richard bannister to successfully compile and release a new
bsnes |
He has. Get it here. Be sure to send him thanks, please :)
Quote: |
byuu's
been planning to write documentation for ages, he's just never gotten
around to it. Perhaps all the experience he's gained restructuring
bsnes will help him plan out the documentation when he does, though |
I won't start on docs until I have a functional CPU<>PPU
cycle-level emulation model. I'll try documenting the PPU as I work on
cycle timing, and I can expand upon the documentation from there.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 18, 2008 6:21 pm Post subject: |
|
Tried the new version on this pc
Still doesn't work, hope you get time to default the renderer to directdraw instead of direct3d |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Feb 18, 2008 7:26 pm Post subject: |
|
byuu wrote: |
New
WIP adds an option to enable or disable filetype detection by reading
the format header. I received no feedback, so I'm defaulting to this
behavior being off. In other words, I'm defaulting to requiring the
file extension to be correct to properly handle the file. This is
because there's no reason a real SNES would behave different just
because $8000 = 'P' and $8001 = 'K', and with the option enabled by
default, you wouldn't be able to get such a game to run. But the option
is there for those who want it.
|
You skimmed over having copier headers which can contain literally anything.
byuu wrote: |
Can't memcmp() the low five bits of the GZ flags byte.
|
I wasn't refering to memcmp() for gzip, I was refering to it for the other ones.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 18, 2008 7:36 pm Post subject: |
|
Ah
yes, big question. The default configuration panel in bsnes is sized to
fit on 640x480 monitors. But as you can see, eg from the advanced
panel, it's quite compacted. Do you guys think I should raise the
window size to fit 800x600 monitors? XP by default doesn't even allow
you to set 640x480 anymore, and that's been out for 6-7 years now.
Quote: |
Still doesn't work, hope you get time to default the renderer to directdraw instead of direct3d |
Well, you can change it yourself for now. It works then for you, right?
Don't know what to tell you, every system I have runs the D3D renderer
just fine. Even this old nVidia Vanta. I'm sure you have a hundred
other D3D apps that work just fine, that's always a given. Sadly, I
can't fix bugs that I can't reproduce. Very sorry about that.
The consensus seems to be to leave it at D3D, because it has more
features and works for most people. Though DD makes bsnes run twice as
fast on this Vanta card, and apparently D3D doesn't work at all on
whatever card you are using. What graphics card do you have, anyway?
If people want to default to DD, I can make that happen as well.
Quote: |
You skimmed over having copier headers which can contain literally anything. |
I thought that was obvious enough not to mention. But since you brought
it up, have you seen any copier headers that produce any of these magic
signatures (produce, not "can be made to work with them by manual file
manipulation")? I doubt any new copiers will be created in the future.
But if they are, I really hope they don't use headers at all :)
I'd love nothing more than to kill headers once and for all. But I need
the ZSNES and Snes9X team to back me up on that, and we both know
there's a snowball's chance in hell of that happening.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Feb 18, 2008 7:58 pm Post subject: |
|
byuu wrote: |
Quote: |
You skimmed over having copier headers which can contain literally anything. |
I thought that was obvious enough not to mention. But since you brought
it up, have you seen any copier headers that produce any of these magic
signatures (produce, not "can be made to work with them by manual file
manipulation")? I doubt any new copiers will be created in the future.
But if they are, I really hope they don't use headers at all 
|
In my research, I've noticed several headers (as found dozens live in
the wild) that weren't filled with copier data, but completely random
numbers, literally, every byte from start to end was random.
I especially noticed these, since some of these didn't work on older
versions of ZSNES with a crumier header detection routine.
Since it can be random, there is the odd chance of 1 in some large
number that a random header can end up having those magic bytes.
Nothing can really be fool proof, especially considering you can have a
file which is both a zip file and a gif at the same time, or who knows
what else.
But if we were worried about it, additional checks can be placed on the
file to determine if it's a multiple of 32KB, or a multiple + 512.
There's only so much we can do with a heuristic though, and if someone
wanted, someone could make a virus to infect a person's ROMs. Basically
it would make ROMs get detected wrong and screw up an emulator from
running them, or in a really bad scenerio, pack them with data that
buffer overflows an emulator and does all kinds of nasty stuff, but of
course, no one targets emulators, and I'm just being paranoid 
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Mon Feb 18, 2008 8:05 pm Post subject: |
|
My
new Core 2 Duo (along with a bunch of other new parts) just got here
via UPS, soon I'll be able to play bsnes the way it was meant ^_^
(upgrading from an Athlon XP 3200+.. bleh!)
Hope to do some extensive Windows based testing! |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 18, 2008 8:10 pm Post subject: |
|
byuu wrote: |
Ah
yes, big question. The default configuration panel in bsnes is sized to
fit on 640x480 monitors. But as you can see, eg from the advanced
panel, it's quite compacted. Do you guys think I should raise the
window size to fit 800x600 monitors? XP by default doesn't even allow
you to set 640x480 anymore, and that's been out for 6-7 years now. |
i am all for 800*600 as the default window size as it's more accurate
for representing the TV, and everyone with a fast enough cpu to run
bsnes has 800x600 or higher
byuu wrote: |
Quote: |
Still doesn't work, hope you get time to default the renderer to directdraw instead of direct3d |
Well, you can change it yourself for now. It works then for you, right?
|
I cannot change it because bsnes does not create a configuration file if the renderer fails
byuu wrote: |
Don't know what to tell you, every system I have runs the D3D renderer
just fine. Even this old nVidia Vanta. I'm sure you have a hundred
other D3D apps that work just fine, that's always a given. Sadly, I
can't fix bugs that I can't reproduce. Very sorry about that.
The consensus seems to be to leave it at D3D, because it has more
features and works for most people. Though DD makes bsnes run twice as
fast on this Vanta card, and apparently D3D doesn't work at all on
whatever card you are using. What graphics card do you have, anyway?
If people want to default to DD, I can make that happen as well. |
this pc(P4) has a intel 865G, but thats not the problem, the problem is
the inability to update directX. I have seen the problem many times,
defaulting to directdraw removes the annoyance of having to download
the latest DirectX (or in my case inability to install it)
byuu wrote: |
Quote: |
You skimmed over having copier headers which can contain literally anything. |
I thought that was obvious enough not to mention. But since you brought
it up, have you seen any copier headers that produce any of these magic
signatures (produce, not "can be made to work with them by manual file
manipulation")? I doubt any new copiers will be created in the future.
But if they are, I really hope they don't use headers at all 
I'd love nothing more than to kill headers once and for all. But I need
the ZSNES and Snes9X team to back me up on that, and we both know
there's a snowball's chance in hell of that happening.
|
As a no-intro and XML proponent i am all for killing headers, to make
the move easier you could make a "patchonthefly" app for the 3 people
out there with a copier.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Mon Feb 18, 2008 9:31 pm Post subject: |
|
byuu wrote: |
Quote: |
now
I'll leave you all to this medical hijacking of the thread, while
waiting for richard bannister to successfully compile and release a new
bsnes |
He has.
|
In the Black Omen section of the Chrono Trigger attract mode, I get an awesome 6FPS! w00t!
(yes, 6, not 60 ;)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 18, 2008 9:45 pm Post subject: |
|
Quote: |
i
am all for 800*600 as the default window size as it's more accurate for
representing the TV, and everyone with a fast enough cpu to run bsnes
has 800x600 or higher |
Alright, I'm thinking of using 800x460, or roughly 25% larger in each
direction. It used to be 640x365. I'm leaving some vertical room for
taskbars and such.
Example: http://img526.imageshack.us/img526/6650/bsnes800ur8.png
Side note: I've also been thinking about removing most of the options
from advanced. Specifically, all of the ones that can already be
modified elsewhere within bsnes. That way you don't have to worry about
the values desyncing and not taking immediate effect and such. And with
the extra vertical height, I can start adding more panels. A paths
panel would be nice.
Quote: |
I cannot change it because bsnes does not create a configuration file if the renderer fails |
Sure it does.
Code: |
// src/ui/main.cpp:
int main(int argc, char *argv[]) {
set_config_filename();
get_base_path(argv[0]);
hiro().init();
config::config().load(config::filename);
if(fexists(config::filename) == false) {
//in case program crashes on first run, save config file
//settings, so that they can be modified by hand ...
config::config().save(config::filename);
}
snes.init();
ui_init(); //video, audio, input drivers initialize here ...
...
} |
The config file is stored in c:\documents and settings\username\application data\.bsnes\bsnes.cfg.
I have lots of ideas to solve this problem, including a crash detection
that will default all drivers to null and give you an option to change
settings before the emulator starts. Realistically, the drivers should
not crash because they fail, but a lot of these APIs make it impossible
to avoid. You call a function, and rather than get an error code, it
just crashes the whole app.
Quote: |
In the Black Omen section of the Chrono Trigger attract mode, I get an awesome 6FPS! w00t! |
o.O
Geez, 6fps ... even if I went absolutely all-out in optimizing an SNES
emulator designed exclusively for speed, I seriously doubt I could get
it to 60fps on your system >_<
EDIT: why has nobody pointed this out to me??
Quote: |
Warning: modifification of certain variables will not take effect until
bsnes is restarted, and corresponding UI elements will not be updated
to reflect changes here. (*) = modified |
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 18, 2008 10:35 pm Post subject: |
|
that code must be broken because there is no bsnes dir in application data (and i have full access to it) |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 18, 2008 10:52 pm Post subject: |
|
Quote: |
that code must be broken because there is no bsnes dir in application data (and i have full access to it) |
It's extremely straight forward. It isn't crashing because of the
Direct3D driver. Hence you have much more serious problems to deal
with. Hard to say, maybe there's a bug in my code somewhere that only
affects your system; or maybe there's a problem with some other part of
your system that only manifests itself in bsnes. Either way, I'm afraid
there's not much I can do. A damn shame, your testing thus far has been
absolutely invaluable.
If you feel really technically adept, you could try compiling with
debugging information and capture the crash point in gdb or Visual
Studio debugger, but I take it you probably don't want to go that far.
And if you're not into programming, you probably can't even if you
wanted to :/
Does anyone else have this problem with v028?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Feb 18, 2008 11:00 pm Post subject: |
|
start bsnes.exe
ERROR dx9xx.dll not found!!, i endlessly look on okay, or click cancel and the application exits
I dont think bsnes registers that as a crash? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Feb 18, 2008 11:12 pm Post subject: |
|
byuu wrote: |
Quote: |
i
am all for 800*600 as the default window size as it's more accurate for
representing the TV, and everyone with a fast enough cpu to run bsnes
has 800x600 or higher |
Alright, I'm thinking of using 800x460, or roughly 25% larger in each
direction. It used to be 640x365. I'm leaving some vertical room for
taskbars and such.
Example: http://img526.imageshack.us/img526/6650/bsnes800ur8.png
|
I think this creates too much vacant space in many areas and will make
the buttons look ridiculous. It will also block out the game window for
many people who modify color settings and want to see instant results.
I'm also going to go return some bottles today and use the money to get
tetsuo a video card that can actually handle d3d...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Feb 18, 2008 11:20 pm Post subject: |
|
Quote: |
ERROR dx9xx.dll not found!!, i endlessly look on okay, or click cancel and the application exits |
Oh, well, you're fucked in that case :(
That error happens before bsnes reaches int main(). The only way to
avoid it is to omit D3D support entirely upon compilation. Given how
helpful you have been in the past, I'll be happy to make you a custom
DirectDraw-only build for each new release if you like.
Quote: |
I think this creates too much vacant space in many areas and will make the buttons look ridiculous. |
Yeah, agreed. It looks better on Linux with it's bigger-sized text and
fancier widgets, but I'd like the Windows port to look good, too. I
guess I'll leave it alone for now. Maybe increase the height somewhat,
but leave the width alone. It'd be nice if I could get XP themes to
apply to bsnes controls. But even making those damn manifest files and
including them don't seem to do anything. Don't suppose anyone else
knows how to enable that?
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Feb 18, 2008 11:27 pm Post subject: |
|
tetsuo55 wrote: |
ERROR dx9xx.dll not found!!, i endlessly look on okay, or click cancel and the application exits |
Out of curiosity, what happens if you create an empty text file and save it as 'dx9xx.dll'?
Edit: mind you, I don't have any files like this on my Windows XP
system. The closest is 'dx8vb.dll' or something like 'd3dx9_24.dll'.
byuu wrote: |
Don't suppose anyone else knows how to enable that? |
Comparing compilation of a standard Windows GUI project with Dev-C++
with the "Support Windows XP Themes" option enabled and disabled gives
me the following:
Code: |
g++.exe main.o -o "Project1.exe" -mwindows -s
windres.exe -i Project1_private.rc --input-format=rc -o Project1_private.res -O coff
g++.exe main.o Project1_private.res -o "Project1.exe" -mwindows -s |
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Tue Feb 19, 2008 1:13 am Post subject: |
|
Verdauga Greeneyes wrote: |
Metatron wrote: |
I have the same thing. Ocular albinism. |
I read on Wikipedia that this can give the illusion of violet/purple irises in sunlight.. is that true?
|
It is, in my case anyway.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 19, 2008 1:17 am Post subject: |
|
I've
used XP for years and I've never seen anything that weird. What you
should do is reinstall Windows, fully update it, then install the
latest drivers, and if you still get the problem, you just need to
report it to Microsoft. This might seem drastic but troubleshooting
something like this on a web forum is a waste of time. We're completely
ignorant to the state of your OS on this end. A reinstall and full
update will eliminate a lot of possibilities and is going to narrow
things down far faster than weeks of inquiries about your system. |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Tue Feb 19, 2008 2:48 am Post subject: |
|
what
if he got that file from a friend and input the file where it should
normally go? that would save him about 3-5 hours of reinstall time
_________________

<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: Tue Feb 19, 2008 3:51 am Post subject: |
|
Well,
like byuu said. No file like that exists. I've done a windows search
and a google search and it isn't coming up with anything. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Feb 19, 2008 6:46 am Post subject: |
|
Can't the trouble file in question just be loaded after WinMain is entered? You know, after it has read what drivers to use. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Feb 19, 2008 9:14 am Post subject: |
|
The exact error says: error with 'd3dx9.dll' or 'd3dx9_XX.dll' where XX stands for any number.
If i download any of these files off the web and place them in the
bsnes folder, the error will be replaced by a new missing file, and
this will go on untill i finally reach kernel32.dll
none of these files are actually missing though(except for the
'd3dx9_XX.dll') The problem is simple, bsnes will not work on pre-SP2
systems
Now on to a fix, either bsnes should fallback on dx8 if the dx9 version
needed is not detected, or fallback to directdraw.
But the easiest solution is this: include a ini file in the zip!
No need to compile a specialversion, make any fallbacks, if the ini
file is in the zip, and bsnes accepts ini files from its own folder,
than you can just add a readme entry that says: change to DD in ini if
you have any problems |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Tue Feb 19, 2008 11:21 am Post subject: |
|
byuu wrote: |
Quote: |
In the Black Omen section of the Chrono Trigger attract mode, I get an awesome 6FPS! w00t! |
o.O
Geez, 6fps ... even if I went absolutely all-out in optimizing an SNES
emulator designed exclusively for speed, I seriously doubt I could get
it to 60fps on your system >_<
|
Well, I seem to recall I got 40 or 50fps in version 0.1.8 or whatever
the last OS X build was. But that's OK, SNES9x still works fine if I
really need some SNES emulatin', and i have a 2GHz Core 2 Duo laptop
here if I really need grunt-work done (my desktop is a 1.6GHz G5).
byuu wrote: |
Yeah,
agreed. It looks better on Linux with it's bigger-sized text and
fancier widgets, but I'd like the Windows port to look good, too. |
With a web-page, you can size elements in 'ems' and have them look good
no matter what size text the user has configured. With GTK+, you just
plonk widgets into hboxes and vboxes and GTK+ handles all the sizing
and geometry for you. Why does bsnes' UI toolkit not just say "ah,
Windows is using a 10px font, so I'll size everything appropriately"?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 12:42 pm Post subject: |
|
Quote: |
Comparing
compilation of a standard Windows GUI project with Dev-C++ with the
"Support Windows XP Themes" option enabled and disabled gives me the
following: |
Hmm, what's in the .rc file? Because I pretty much do the same thing
with my windres call to store the program icon.
Quote: |
Now on to a fix, either bsnes should fallback on dx8 if the dx9 version needed is not detected, or fallback to directdraw.
But the easiest solution is this: include a ini file in the zip! |
None of that will solve this problem. When you link against d3d9.lib,
it tries to load D3D's DLLs before reaching WinMain. No way to avoid
that, except to link against your own DLL before D3D.
But even that won't stop it from loading D3D9's DLLs. The only way to
avoid that would be to either omit D3D9 support entirely, or convert
that driver to work entirely off LoadLibrary + GetProcAddress, and use
the C interface, rather than the C++ interface. And that's not
happening.
Quote: |
Well, I seem to recall I got 40 or 50fps in version 0.1.8 or whatever the last OS X build was. |
Everyone on MacScene "only" noticed a 20-30% speed loss, which is of
course the IRQ testing biting us in the ass once again. I take it you
might be hitting some sort of porting bug :/
Quote: |
Why does bsnes' UI toolkit not just say "ah, Windows is using a 10px font, so I'll size everything appropriately"? |
Let's see ... 1) changing DPI can change the size of the font, so I'd
have to factor that in as well. 2) em only tells you the size of M, and
not the size of everything else. I'd have to use DrawText + DT_CALCRECT
to determine how big each widget needs to be. And I don't know of an
equivalent with GTK+. The two APIs would need to be 100% consistent.
What I was planning on doing was adding "novresize" and "nohresize"
flags to each widget. Then just let the programmer pick whatever
default size they want, and place their widgets on that. When the
window is resized, compare it to the old size to get a multipler (eg
newwidth / oldwidth), then multiply that by the size of all widgets on
the form to reposition them. But that's a long ways off, anyway.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 2:28 pm Post subject: |
|
New WIP.
Fixed the frameskipping bug, fixed the DirectDraw renderer. I also
added a new folder_select function to both ports of hiro (Windows and
GTK+), and with that, I added a new path settings panel to the
configuration window.
You can see how it looks here:
Code: |
http://byuu.cinnamonpirate.com/images/bsnes_20080219.png |
Also, I compiled the Windows binary with Direct3D support omitted.
tetsuo55, please grab this version, as I intend to compile with
Direct3D support for subsequent WIPs.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 19, 2008 2:32 pm Post subject: |
|
tetsuo55 wrote: |
The exact error says: error with 'd3dx9.dll' or 'd3dx9_XX.dll' where XX stands for any number.
If i download any of these files off the web and place them in the
bsnes folder, the error will be replaced by a new missing file, and
this will go on untill i finally reach kernel32.dll
none of these files are actually missing though(except for the
'd3dx9_XX.dll') The problem is simple, bsnes will not work on pre-SP2
systems |
Well, there you go. You've chosen not to fully update your OS.
Something you may want to try is downloading the latest dx9 redist
here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1a2393c0-1b2f-428e-bd79-02df977d17b8&DisplayLang=en
If that doesn't work, you'll just have to use the ddraw renderer.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 19, 2008 2:38 pm Post subject: |
|
byuu wrote: |
Hmm, what's in the .rc file? Because I pretty much do the same thing with my windres call to store the program icon. |
Code: |
/* THIS FILE WILL BE OVERWRITTEN BY DEV-C++ */
/* DO NOT EDIT! */
//
// SUPPORT FOR WINDOWS XP THEMES:
// THIS WILL MAKE THE PROGRAM USE THE COMMON CONTROLS
// LIBRARY VERSION 6.0 (IF IT IS AVAILABLE)
//
1 24 "Project1.exe.Manifest"
|
Project1.exe.Manifest contains
Code: |
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
name="DevCpp.Apps.Project1"
processorArchitecture="x86"
version="1.0.0.0"
type="win32"/>
<description>Project1</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
|
Which, incidentally, is the same as Project1_private.res except that
that file contains some code in front of and after it:
Code: |
L 2 .rsrc ì < ( @ À ºG € ºG 0 € ºG H X " [Project1.exe.Manifest]H .rsrc |
|
|
DataPath Lurker
Joined: 28 Jul 2004
Posts: 144
|
Posted: Tue Feb 19, 2008 2:48 pm Post subject: |
|
byuu wrote: |
I'd
have to use DrawText + DT_CALCRECT to determine how big each widget
needs to be. And I don't know of an equivalent with GTK+. The two APIs
would need to be 100% consistent. |
Pango is GTK+'s underlying text rendering engine. The Pango functions
that I think correspond to the windows one are here.
pango_layout_get_pixel_size ()
Quote: |
Determines
the logical width and height of a PangoLayout in device units.
(pango_layout_get_size() returns the width and height scaled by
PANGO_SCALE.) This is simply a convenience function around
pango_layout_get_pixel_extents(). |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 19, 2008 3:28 pm Post subject: |
|
Oh, goody, a path selector!
Consider rewording to "Default ROM file path:" and "Default SRAM file path:"
I see "cartridge" as being the ROM and SRAM together.
Also, could we have "Default cheat file path:"?
edit: god, why can't I spell
Last edited by FitzRoy on Tue Feb 19, 2008 4:14 pm; edited 3 times in total
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Feb 19, 2008 4:01 pm Post subject: |
|
Thanks
for trying to help Fitzroy, and thanks byuu for that version, i will
send it to my work pc and test it when i'm at work again.
I cannot update the pc due to lack of admin rights, and the servicedesk
see's no reason to update to SP2 or any other updates for that matter.
the reason i started this up again is simple, the linux version seems
to work on everything and everyone, but the windows version is still
limited to Sp2 and the latest version of DX9c, its a bit lame to see
Half life 2 and Farcry running on a system and then see Bsnes fail
horribly on a dll error.
What makes it even worse is that any random other emulator works fine,
as far as i know bsnes uses nothing specific to dx9c, it should even
work on dx7 as proven by the linux port. |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Tue Feb 19, 2008 4:22 pm Post subject: |
|
Yes! I mean I want the cheat path option included as well :) |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 19, 2008 4:38 pm Post subject: |
|
tetsuo55 wrote: |
I cannot update the pc due to lack of admin rights, and the servicedesk
see's no reason to update to SP2 or any other updates for that matter. |
Ah, so that's the story. Now all you need to do is infect the computer with something so that they update 
But really, if bsnes cannot support initial dx9 versions of xp without
sacrificing something or adding hacks, I think you may be out of luck.
I don't think that bsnes should default to a blurry mess renderer that
requires advanced setting changes for most users just to get point.
That greivance outweighs yours, and yours is also user error, even if
it isn't your own.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 5:16 pm Post subject: |
|
Code: |
1 24 "Project1.exe.Manifest" |
Mmm, that might be what I need, thanks. I'll give it a try when I can.
Quote: |
pango_layout_get_pixel_size () |
Hmm, I'll try it. Would make my UI a lot nicer.
Quote: |
Consider rewording to "Default ROM file path:" and "Default SRAM file path:"
I see "cartridge" as being the ROM and SRAM together.
Also, could we have "Default cheat file path:"? |
Well, right now the cheat path is broken, but it's supposed to be the
same as the save path. Do you really think it'd be beneficial to have a
third path? I realize you can set cheat and save to the same folder
that way, but is it worth the added complexity? If you think so, I'll
add it. But then we'd want "Default patch path", etc etc.
Good point on "cartridge" being both ROM+SRAM. I hate calling it ROM,
it just seems so warezey. Meh. Also, how's the checkbox option sound?
That one's a real pain in the ass to make sound good.
"[ ] Open file and read the header to determine the compression format,
rather than relying upon the file extension" is a bit too long for one
line :P
Or maybe I should keep the option buried in the advanced panel ... if I
can't get a good description for it, it'll probably just confuse
people. And yeah, I'll probably add a filter to that panel tonight to
hide all the options already controllable from the UI.
Quote: |
What makes it even worse is that any random other emulator works fine |
Meh, how'd I know this would be mentioned? The reason other emulators
work is because they use DX8 and below. I'd like to take advantage of
HLSL shaders and stuff like that eventually. They may work with DX8,
but why should I intentionally use older APIs? Even Windows 98 has DX9
available for it. It's not like I'm using DX10 and limiting people to
Vista. To date, you're the only person I've heard from that can't even
open bsnes.
But again, I'm willing to make a legacy build with just DirectDraw.
That'll save me time compared to going back and backporting the D3D
renderer. D3D8 and D3D9 have a lot of minor differences. Way more than
you would think.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Feb 19, 2008 5:28 pm Post subject: |
|
byuu wrote: |
Also, how's the checkbox option sound? That one's a real pain in the ass to make sound good.
"[ ] Open file and read the header to determine the compression format,
rather than relying upon the file extension" is a bit too long for one
line 
Or maybe I should keep the option buried in the advanced panel ... if I
can't get a good description for it, it'll probably just confuse people. |
File type detection behavior:
[o] Use extension [o] Detect header
On the other hand, I've always been of the mind that filename extensions should only be used as a visual clue
for the filetype. All programs, in my opinion, should be able to
adequately detect the filetypes that they explicitely support, without
just relying on the filename extension.
However,
as in the case of ROMs, I gathered from the brief discussion between
you and Nach that there is no way to reliably detect the filetype of a
given file, when ROM headers are taken into account? That seems like a
pretty good reason to not support ROM headers. The question that seems
to be asked here is, "Do I want to support a type of header that is
undefined and can have completely arbitrary data?"
Anyway, it just seems like now is a good time to make a robust filetype detection mechanism for your emulator.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 5:48 pm Post subject: |
|
The
game itself can start with any data as well. I could make an SNES game
that runs on real hardware that has a valid ZIP file signature at the
top. Given the odds of that happening randomly are 1:4 billion -- it's
still quite possible, and one could even do so maliciously if they
wanted.
Realistically, an SNES emulator that claims to act as real hardware should be able to play such a game, right? |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Feb 19, 2008 6:16 pm Post subject: |
|
About the manifest? Do you think that you can please read this 136 page word document about UAC in vista?
By following the instructions in there, you can guarantee that your
config files and so on will never be caught by the "friendly file
access redirection system".
A lot of the info in it is overkill and for real admin tools, you can get away with a few lines in the manifest. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Feb 19, 2008 6:26 pm Post subject: |
|
Don't
forget that because of multiple formats, the ratio of a ROM or a copier
header misdetecting as any compressed file (as just opposed to zip) is
signifigantly higher.
Based on your initial 3 formats, 4 byte checks, one check allows a large range.
Ratio would be 226:4294967296, or ~1:19004281.
_________________
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: Tue Feb 19, 2008 6:27 pm Post subject: |
|
byuu wrote: |
Well, right now the cheat path is broken, but it's supposed to be the
same as the save path. Do you really think it'd be beneficial to have a
third path? I realize you can set cheat and save to the same folder
that way, but is it worth the added complexity? If you think so, I'll
add it. But then we'd want "Default patch path", etc etc.
Good point on "cartridge" being both ROM+SRAM. I hate calling it ROM,
it just seems so warezey. Meh. Also, how's the checkbox option sound?
That one's a real pain in the ass to make sound good. |
The only real purpose of paths is for people who want to separate
everything, possibly because they have thousands of files and want to
quick copy or manage or keep organized archives of their files without
worrying about sift time or carryover. So yes, I think a patch file
path might be nice, too. What would be needed beyond that? BIOS would
only be necessary if you were emulating a system that had one (or
couldn't legally include it). The "BIOS" rom images for SNES add-on
devices should be stored in the ROM area and loaded in the manner you
currently implement. So we don't really need a separate path for those.
Screenshots are probably never getting in and are best done externally.
I don't know if audio logging is even necessary since you can do that
externally as well. SPC ripping would be a welcome addition. So I could
see the path section looking like:
Default ROM (SFC, BS, ST) file path:
Default SRAM (SRM) file path:
Default audio (SPC) file path:
Default cheat (CHT) file path:
Default patch (IPS) file path:
I think that's pretty newb proof. Note that I wouldn't include the
copier extensions even if you continue to support loading them. People
need not be encouraged into thinking that they are acceptable by giving
them recognition. SuperMagiCom is a random ass copier extension and
should not prevail over the actual system's acronym. The scene screwed up royally on that one.
byuu wrote: |
"[
] Open file and read the header to determine the compression format,
rather than relying upon the file extension" is a bit too long for one
line  |
Sorry, I missed the boat for this. Why was this needed again? No issues
with file extensions over here, unless of course I've renamed to
something it shouldn't be, which I can correct with ease.
Last edited by FitzRoy on Tue Feb 19, 2008 7:16 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 19, 2008 7:13 pm Post subject: |
|
FitzRoy wrote: |
Sorry,
I missed the boat for this. Why was this needed again? No issues with
file extensions over here, unless of course I've renamed to something
it shouldn't be, which I can correct with ease. |
Richard Bannister requested it for his mac build, I believe. Not that I
don't agree with you.. if you -do- have files that have an extension
that's already being used by something else, don't put them in the same
folder, or name them appropriately. How hard can it be? Mind you, I do
like being able to load files that use the same compression format but
have a different extension in programs like WinRAR, but bsnes is not a
compression utility.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Feb 19, 2008 7:22 pm Post subject: |
|
thanks for the reply, seeing as you did purposfully code for DX9 i see no reason to go down to DX8!
Well what make's it worse for me is that i have seen it happen to quite a few people i suggested bsnes too.
I agree with you that the best solution is to add a directdraw version
to each official release, just in case someone has a problem with the
D3D version, it also means i can run tests at work  |
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Tue Feb 19, 2008 8:37 pm Post subject: |
|
The
reason Richard Bannister wants file type detection which doesn't rely
on the file's extension is because some (old-fashioned) Mac users don't
like file extensions because they're "ugly" or "PC-like" or whatever
(my father was that way). In the HFS+ file system, each file contains a
32-bit file type and a 32-bit creator code, which used to be the way
files were identified. That method is obsolete in OSX, but it is
(somewhat) still supported, so files don't need an extension to be
identified by the OS as belonging to a particular application. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Feb 19, 2008 9:04 pm Post subject: |
|
dvdmth wrote: |
The
reason Richard Bannister wants file type detection which doesn't rely
on the file's extension is because some (old-fashioned) Mac users don't
like file extensions because they're "ugly" or "PC-like" or whatever
(my father was that way). In the HFS+ file system, each file contains a
32-bit file type and a 32-bit creator code, which used to be the way
files were identified. |
Disliking it because it's "PC-like" is just ignorant. Macs ARE PCs, and always have been.
Disliking it because it's ugly...
They're file names. You can't MAKE them pretty. So.... ignorant.
Disliking it because it's a cheap kludge that should never have existed
in the first place, and MS should be ashamed that they never introduced
a more reliable system like, say, a file header with a unique filetype
identifier... that's a bit more rational.
Hell, my 99/4a has headers with filetype identifiers. Not that that
particular file system allows for great diversity of headers(resulting
in far too many types of files claiming to be 80-column text), but...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 10:04 pm Post subject: |
|
This is going to be a long post.
I think I may have a workable solution to the CPU<>PPU sync
problem, which will allow the scanline renderer to co-exist with a
pixel/clock renderer.
Problem recap:
The PPU outputs vertical (V) and horizontal (H) blanking pins, which
the CPU polls every clock tick. The CPU doesn't know what values the
PPU vertical and horizontal counters hold -- it has nothing to do with
the video display, after all.
So how does the CPU implement NMIs, which occur when vblank starts, and
IRQs, which occur at precise V, H counter positions? Simple, it keeps
its own internal V, H counters, and monitors the PPU V, H pins on each
clock tick. When PPU H goes low, CPU V gets incremented and CPU H is
reset to zero. When PPU V goes high, an NMI is generated. When PPU V
goes low, CPU V gets reset to zero. Note that I may have the actual
logic stated backwards (eg swap "low" and "high"), but the result is
the same, so it doesn't change the behavior.
Now, here's the problem. If the CPU were to run ahead of the PPU, it
can't ask the PPU the state of the V, H pins, because the PPU isn't
caught up. In this regard, it's as though the CPU is "reading" from the
PPU. This action requires a synchronization. That's very damning. It
means the CPU can never run ahead of the PPU.
Okay, but the PPU can run ahead of the CPU, right? Surprisingly, no.
The same problem applies. The CPU needs to probe the PPU V, H pins every single clock tick.
If the PPU runs ahead of the CPU, then the CPU could miss the exact
transition moments, and the CPU's internal counters would desync with
the PPU's internal counters. Not good.
That
means we can only step one single clock tick. As the smallest time unit
for the CPU is ~10.7MHz, that means ~10.7*2 million co_switch calls per
second. You want to talk about world of pain ... this is it.
The current solution:
How do emulators of today solve this problem? Simple, we bullshit how
the hardware works. We store the vcounter and hcounter inside the CPU.
The CPU increments the counters, and each time a "scanline" has passed
(~1364 clocks), we draw a new scanline. The PPU simply cannot cope with
mid-scanline accesses.
The easy solution:
So, my problem probably seems pretty simple. You can just store
counters in both the CPU and PPU, right? Well, not exactly. You see,
PPU register $2133 contains two interesting bits. One to control
interlace, one to control overscan.
Interlace can change the number of vertical scanlines per frame, and overscan can change when the V pin is raised.
That means that with two counters, extra special care would be needed
when writing to this register to make sure the counters do not desync.
Further, the idea frankly sucks, because the CPU should not know about
PPU raster positioning anyway! It's hackish, and it makes the CPU
dependent upon the PPU. A serious problem when you want your code to be
documenting how the hardware works.
My proposed solution:
After analyzing the problem, one thing is clear to me. So long as the
CPU hasn't written to $2133, the PPU can reliably calculate the V and H
pin statuses of the current time, and an infinite amount of time both forward and
backward! Further, since overscan only affects the V pin state, and not
the number of scanlines in a frame, nor the short scanline V=240, we
really only need two special functions. One for interlace mode, one for
progressive mode.
Just like with the CPU and SMP
now, we'll want to make sure the two stay synced to a certain degree. I
believe once every scanline is reasonable for syncing up the two. That
gives up 262*60=15,720*2 (bidirectional)=31,440 co_switch calls per
second. Piece of cake. The SMP<>DSP perform 2.048 million
co_switch calls, which only cost ~5-10% of bsnes' total speed. 31,440
won't even be felt.
But what will
be felt is the extra work involved in calculating the PPU V, H pins,
rather than relying on internal CPU counters. I honestly can't predict
how badly this will affect performance, but it's certainly not going to
be faster than it is currently.
The really fucking awesome thing about this approach though, is that
it's compatible with the scanline renderer. That means I can work on a
cycle-based PPU without killing the bsnes that runs on full speed on
$400+ modern PCs :D
Here is a proof-of-concept example of my time-shifting example:
Code: |
void sPPU::query(uint16_t &v, uint16_t &h, signed offset) {
v = vcounter;
h = hcounter + offset;
if(offset > 0) {
while(h >= 1364) {
h -= 1364;
if(++v >= 262) v = 0;
}
} else if(offset < 0) {
while((int16_t)h < 0) {
h += 1364;
if((int16_t)--v < 0) v = 261;
}
}
}
void sPPU::pinquery(bool &v, bool &h, signed offset) {
uint16_t vcounter, hcounter;
query(vcounter, hcounter, offset);
v = vcounter >= 225;
h = hcounter <= 2 || hcounter >= 1096;
} |
Obviously, a finished version would be much more complex and optimized. But you get the idea.
The offset value would simply be the CPU<>PPU counter offset
value from the scheduler. That is, a value that starts off at zero. As
the CPU executes clocks, it adds those clocks to this counter. As the
PPU executes clocks, it subtracts from this counter. Simple enough.
I'm not ready to jump ship and try this idea out just yet. I'll write
up a more formal document on the matter and then elicit help from
everyone before actually attempting anything. But this looks fairly
promising ... I can't see any problems at this time.
Input from other programmers would be greatly appreciated.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Feb 19, 2008 10:41 pm Post subject: |
|
Wow,
this sounds like a great alternative to the doom-scenario problem. I
suppose you could argue that it's a bit of a compromise since there
won't be any polling like the hardware is doing, but that's nothing a
bit of code commenting won't cure - and it's not like there's an
alternative at this point. Will this have any effect on the way NMIs
are implemented? I wanted to try my hand at a range-testing
implementation last time it came up, but it was never very clear to me
what the ranges that should be tested were and where this was meant to
be implemented. But maybe the whole thing is just out of my league (for
the moment, rargh). As for the example, is that a working solution for
the calculations? (i.e. could anyone reading your post take that bit of
code and start optimising the crap out of it straight away, or would
that be a waste of time?) |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Feb 19, 2008 10:57 pm Post subject: |
|
In the example code you don't need the extra test if offset is < 0. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 19, 2008 10:59 pm Post subject: |
|
Quote: |
I suppose you could argue that it's a bit of a compromise since there won't be any polling like the hardware is doing |
It will be polling completely transparently. The PPU will just have a
special timeshifting function, and the SNES will pass the offset value
along to it. But the raw CPU and PPU emulation code will look just like
it's polling as hardware would.
Quote: |
Will this have any effect on the way NMIs are implemented? |
Yes, it will be more true to hardware.
Quote: |
I
wanted to try my hand at a range-testing implementation last time it
came up, but it was never very clear to me what the ranges that should
be tested were and where this was meant to be implemented. |
Sadly, this setup will rule out range testing. With the counters
external to the CPU, we cannot range test anymore. Even if range
testing is possible, it's so unbelievably messy and error prone, that
it doesn't belong in bsnes.
I've been thinking about it ... I'd really like to set up a milestone section on my site.
bsnes v002 ir9 -- oldest surviving copy of bsnes
bsnes v0.017 -- last range-testing IRQ + PGO version; it is ~55% faster
than v028 (I get full speed on my Pentium 4 1.7GHz processor!)
bsnes v028/v029 -- last enslaved CPU<>PPU version; might be a good deal faster than future versions
Really, v017 has only a half dozen known bugs. It's quite a nice
emulator in and of itself. SNESGT is only ~50% faster than it.
Quote: |
As for the example, is that a working solution for the calculations? |
Nope. Progressive mode needs the short dot on the odd field's scanline
240, and interlace mode needs the extra scanline on the even field.
I'll probably start things off by implementing a simple timeshifter
into the base PPU class (so that it can be shared by both PPU cores.)
We'll optimize once it's working.
Question is, should I make a release with current changes before
attempting this new idea, or just start on it now so that it's ready
for v029?
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Feb 20, 2008 1:24 am Post subject: |
|
I'd
make a release with all the other changes first... you've made a lot of
good changes to the emulator, and now you're going to start something
very big and cool, that should probably be sat on for one more release.
Plus, people will probably like the new paths section a lot.
That's just my two cents, though. For what it's worth, you've got me pumped about your plans!
_________________
I bring the trouble. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Feb 20, 2008 1:55 am Post subject: |
|
I'd
also say do the release first, not because everyone needs it so much,
but it will make things up to date before a long wait, and also just
good timing I think, and gives people the ability to bug hunt.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Wed Feb 20, 2008 3:11 am Post subject: |
|
Gil_Hamilton wrote: |
Disliking
it [file extension] because it's a cheap kludge that should never have
existed in the first place, and MS should be ashamed that they never
introduced a more reliable system like, say, a file header with a
unique filetype identifier... that's a bit more rational. |
I hate visible file extensions too since they are visual clutter and a
file's icon tells its type already (and the icons are aligned in a
column, unlike the extensions). On OS X you can set a flag that hides a
file's extension, including when the filename is displayed in
applications (title bar, etc.). Even better, if the user deletes the
extension by renaming the file in the Finder, instead of actually
removing the extension, the file's "hide extension" flag is set
instead. Even file renaming utilities have options to avoid messing
with file extensions when doing renaming (at least Renamer4Mac, an
lame-named good utility).
byuu wrote: |
Okay, but the PPU can run ahead of the CPU, right? |
Obviously if can't, because the CPU can affect PPU operation at any
point. There is no easy way to predict what the CPU will be doing X
clocks from now, other than executing X clocks. The PPU, on the other
hand, is very predictable.
Quote: |
After
analyzing the problem, one thing is clear to me. So long as the CPU
hasn't written to $2133, the PPU can reliably calculate the V and H pin
statuses of the current time, and an infinite amount of time both
forward and backward! |
Can't you just separate this aspect of the PPU and allow it to be
emulated independently? Currently you have the CPU and PPU, each not
always in sync. After separation, you'd have CPU, PPU H/V counters, and
the rest of the PPU. You'd always run the H/V counters in sync with the
CPU. If the PPU also needs the H/V counters, you could have two copies
of it emulated, one for the CPU and one for the PPU. That's not too
hacky, since things are still encapsulated and the H/V counter is only
implemented once in source code.
Dwedit and I came up with a similar approach for an emulator that runs
on a multi-CPU machine, with one CPU running the main emulator and the
second running the sound chip. Writes to the sound chip are queued and
send to the second CPU every frame. The main emulator needs to be able
to read back from the sound chip immediately, so it runs a second
"shadow" copy with sound muted (so it's fast). Another way to think of
the setup is that the emulator doesn't generate any sound, simply
generates a log of sound chip writes, which the second CPU plays back.
The point of the setup is that the second sound CPU doesn't have to
constantly synchronize with the emulator.
In the bsnes case, the CPU writes to the H/V counter configuration
registers, and needs to be able to read the counters constantly. The
PPU only needs to know when they're written to, otherwise doesn't need
to affect them (presumably), so it's like the second sound CPU in the
above example.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Wed Feb 20, 2008 6:57 am Post subject: |
|
blargg wrote: |
Gil_Hamilton wrote: |
Disliking
it [file extension] because it's a cheap kludge that should never have
existed in the first place, and MS should be ashamed that they never
introduced a more reliable system like, say, a file header with a
unique filetype identifier... that's a bit more rational. |
I hate visible file extensions too since they are visual clutter and a
file's icon tells its type already (and the icons are aligned in a
column, unlike the extensions).
|
Ehhh... I wouldn't go that far on the icons on a Windows system where
few set their own icons; for example I don't know how a Winamp icon on
my mp3s tells me that it's an mp3 as opposed to the fact it'll play on
Winamp, like my spcs, my psfs, ad nauseum.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Feb 20, 2008 7:49 am Post subject: |
|
blargg wrote: |
Gil_Hamilton wrote: |
Disliking
it [file extension] because it's a cheap kludge that should never have
existed in the first place, and MS should be ashamed that they never
introduced a more reliable system like, say, a file header with a
unique filetype identifier... that's a bit more rational. |
I hate visible file extensions too since they are visual clutter and a
file's icon tells its type already (and the icons are aligned in a
column, unlike the extensions).
|
Only to a degree. At least on Windows, there's a lot of file types with
shared icons(typically because they're all handled by the same app, as
in different types of image files).
Especially when executables can have embedded icons.
The solution I find most viable is a multi-columned list with a dedicated file type column.
Again, this has problems. In this case, it's because the "file type" is
set by the associated viewer, and is often something generic like
"image file" instead of "JPEG image" or branded with the application
associated, but not the actual file type. But it's usually reasonably
accurate.
I leave file extensions active because it lets me differentiate between
"image file" types, and I just like having the ENTIRE file name.
Quote: |
On
OS X you can set a flag that hides a file's extension, including when
the filename is displayed in applications (title bar, etc.). Even
better, if the user deletes the extension by renaming the file in the
Finder, instead of actually removing the extension, the file's "hide
extension" flag is set instead. |
It's an option in Windows too. And it's enabled by default(maybe not on
Vista), but it's highly recommended you disable it due to the security
issues posed by having EXEs masquerading as JPEGs.
Which is because MS used a hackish kludge, and then compounded the
issue by allowing periods in filenames outside of the traditional
name.type separator.
Letting executables have their own unique icons embedded in the file
itself isn't exactly safe, but it's probably considered too
aesthetically pleasing to get rid of.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 20, 2008 11:33 am Post subject: |
|
I
think it would be better to release v0.029 when you're happy that the
changes are enough to warrant a new release. That way you'll have a
last 'complete' version before you start changing things that will
effect the speed. Also, making those changes at 0.030 is like making it
part of 'bsnes 3'
but I don't know if you want that implication. Either way I'm looking
forward to seeing a finished and working (but unoptimised) version of
those calculations. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Feb 20, 2008 11:39 am Post subject: |
|
Quote: |
I hate visible file extensions too since they are visual clutter and a file's icon tells its type already |
If my roms didn't have extensions, things would get confusing rather
quickly, because none have icons or programs assigned to them. Same
with associated files being generated from them like CHT or SRM. There
are too many filetypes like this flying around my folders to rely on
manually assigned graphical identifiers or columnar visual pairing. I
don't see how any human could or would want to identify a similarly
named file in PNG, JPG, GIF, and BMP formats by training themselves to
correlate a certain graphic with a certain filetype. It seems as absurd
as a one-button mouse.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Feb 20, 2008 1:36 pm Post subject: |
|
Can't you have 2 columns? one showing file names with the extension trimmed and the other showing the trimmed characters?
_________________
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. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Feb 20, 2008 2:59 pm Post subject: |
|
I
agree with blargg's suggestion if changes are to be made. If you really
break it down, the core of the CPU should operate independently of the
timer circuitry. At the fundamental level, the CPU simply operates
indefinitely until an external interrupt or event occurs. From the
hardware's perspective, it doesn't actually have to check anything
every clock tick. When an interrupt triggers, it causes an electrical
circuit change. However because interrupts or external events can occur
at any time, logically speaking you can view it as if it 'checks' the
interrupt lines each clock tick.
Let's look at the
S-CPU, the 5A22. What is it? Well, it's a 65c816 CPU with additional
circuitry. The 65c816 by itself would have no knowledge of H/V and/or
NMI timings. It's the additional logic blocks that were added on to
make the 5A22 that introduces this.
Internally though, it should operate the same way. The CPU core will
sit there and execute until an interrupt or external event occurs. It
just so happens that the 'external' event (H/V counters to trigger NMI)
in this case is built into the physical chip and thus technically
internal physically.
The logic of treating the H/V counter as a separate logical block make
sense to me as viable progression for further breaking down the system.
At one time you had speculated about the idea of ultimately going to a
transistor level. Well, this certainly isn't that, but it is the next
step into breaking down the 5A22 if my understanding of the chip is
correct.
P.S. Typically, CPU spec sheets often have block diagrams with logic
blocks of the internal workings. I don't have anything for the 5A22
specifically, but if somebody else does, that would be a good way to
confirm this. I'd expect you'll find the execution core and H/V timing
circuitry would be separate logic blocks tied together by an interrupt
line or two.
_________________
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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 20, 2008 3:14 pm Post subject: |
|
bsnes with XP/Vista themes:
http://img257.imageshack.us/img257/7342/99918115xi4.png
Quote: |
Obviously
if can't, because the CPU can affect PPU operation at any point. There
is no easy way to predict what the CPU will be doing X clocks from now,
other than executing X clocks. The PPU, on the other hand, is very
predictable. |
Correct. Technically, for the scanline-based renderer, this isn't a
problem. And even for the clock-based one, not a big problem. The CPU
will run a whole scanline ahead, then the PPU will be free to run until
it catches up, where it will have to switch back to the CPU. Timing
only gets worse when games write to the PPU register many times during
an active scanline.
Quote: |
If the PPU also needs the H/V counters, |
It almost certainly does, but it's hard to say for sure. It will need
to know about the "short" line on non-interlace odd frame line 240, and
it will need to know about V=0 to perform initial frame-level setup. It
could arguably need to know V for other reasons, but most of those
could be separated from core rendering.
So yes, for the most part it could be a state machine like the DSP.
Quote: |
you
could have two copies of it emulated, one for the CPU and one for the
PPU. That's not too hacky, since things are still encapsulated and the
H/V counter is only implemented once in source code. |
I think that would get very hacky. The problem is that if the CPU
writes to $2133, it can affect future calculations of the V/H counters.
It's very possible that they can get desynced, if even for only a few
clock cycles. I'm not entirely sure we can avoid this simply by syncing
up the PPU immediately after a write to $2133, but that could be a very
good option.
Quote: |
Dwedit
and I came up with a similar approach for an emulator that runs on a
multi-CPU machine, with one CPU running the main emulator and the
second running the sound chip. Writes to the sound chip are queued and
send to the second CPU every frame. The main emulator needs to be able
to read back from the sound chip immediately, so it runs a second
"shadow" copy with sound muted (so it's fast). |
I don't follow. If you're emulating the sound CPU on the first
processor anyway, why have a "real" sound processor on the other
processor? Might as well just make the first processor's sound CPU the
real one.
Quote: |
At
one time you had speculated about the idea of ultimately going to a
transistor level. Well, this certainly isn't that, but it is the next
step into breaking down the 5A22 if my understanding of the chip is
correct. |
That was more of a joke, I don't really think that's possible. I have
thought about breaking up the individual chips more. The thing I really
need to avoid though is the need to have another clock timer to "sync"
components. If I can break them up without introducing another counter
+ cothread, I'm all for it.
Last edited by byuu on Wed Feb 20, 2008 4:08 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 20, 2008 4:04 pm Post subject: |
|
Looking good Did those numbers from the .rc file do it?
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Feb 20, 2008 5:06 pm Post subject: |
|
I seem to have run into a new bug. I hooked up my TV to my PC to play bsnes on it using an s-video cable.
After I did that, bsnes will not work properly. It won't display the
game. I tried moving the window back onto my CRT monitor, but that
didn't help.
I'm using Vista x64, and the video card is a GeForce 8500 GT with the 171.16 version drivers.
Edit: Nevermind, it's working properly now for some reason. o_O |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 20, 2008 6:04 pm Post subject: |
|
Did
you start bsnes before or after you hooked your PC up to the TV? With
my laptop, if I hook my Xtreme Audio Notebook card up to it I won't get
sound until I restart whatever I was listening to, presumably because
it has to reopen the audio device. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Feb 20, 2008 6:27 pm Post subject: |
|
After.
Also, it seems to be related to FF3 only. I tried Super Mario All-stars and it doesn't have that problem.
I tried playing FF3 again(Wanted to see if the text was readable
maximized.) starting it up on the TV rather than dragging over after
starting it on the monitor, and ran into the same issue. Odd.
On a completely off-topic note, am I the only one who thinks Beast Wars when I see the words maximize or maximized? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 20, 2008 6:40 pm Post subject: |
|
Well, I tried my seek ahead / backward pin querying method on a forked v028 as a test.
The good news -- it works great. The CPU and PPU run independently of each other.
The bad news -- it's slow. 68fps -> 44fps slow. This is with the
same scanline renderer. I know, it boggles my mind that this emulator
can get so much slower, too.
I simply can't justify that kind of speed loss. Back to the drawing board :(
Looks like I'm going to end up forced into rigging this to act nothing
like hardware whatsoever, just to get a decent frame rate.
I know nobody else cares about the means, so long as the end output
matches hardware. It's just me who cares about this.
My method would make all of the otherwise "bizarre" dead IRQ spots
suddenly make sense. I wouldn't even have to emulate them, they'd be
intrinsically supported. With two counters, I'll have to keep a list
like this around:
Code: |
if(vpos == 240 && hpos == 339 && interlace() == false && interlace_field() == 1)return false;
if(vpos == (vlimit - 1) && hpos == 339 && interlace() == false)return false;
if(vpos == vlimit && interlace() == false)return false;
if(vpos == vlimit && hpos == 339)return false;
if(vpos > vlimit)return false;
if(hpos > 339)return false; |
Yeah -- I know, I know. We can comment and explain why that's there.
Thank you. That doesn't change the fact that code is disgusting and
doesn't belong anywhere in a "self-documenting" emulator. What a joke
that's turning out to be.
And I'm forced to make the CPU calculate video timing positions. And
no, it makes no difference that the routines themselves are inside the
PPU core. None whatsoever. We're just obfuscating the fact that we're
bullshitting things for speed.
Honestly, I just don't have the mindset required to write emulators. I absolutely hate
compromise. Sigh ... maybe I'll just say the hell with it and do this
anyway. I don't know ... I know you guys are cool with it either way,
and I appreciate that.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Feb 20, 2008 7:05 pm Post subject: |
|
68 FPS on what, exactly? |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Feb 20, 2008 7:08 pm Post subject: |
|
byuu wrote: |
Well, I tried my seek ahead / backward pin querying method on a forked v028 as a test.
The good news -- it works great. The CPU and PPU run independently of each other.
The bad news -- it's slow. 68fps -> 44fps slow. This is with the
same scanline renderer. I know, it boggles my mind that this emulator
can get so much slower, too.
I simply can't justify that kind of speed loss. Back to the drawing board 
Looks like I'm going to end up forced into rigging this to act nothing
like hardware whatsoever, just to get a decent frame rate.
I know nobody else cares about the means, so long as the end output
matches hardware. It's just me who cares about this.
My method would make all of the otherwise "bizarre" dead IRQ spots
suddenly make sense. I wouldn't even have to emulate them, they'd be
intrinsically supported. With two counters, I'll have to keep a list
like this around:
Code: |
if(vpos == 240 && hpos == 339 && interlace() == false && interlace_field() == 1)return false;
if(vpos == (vlimit - 1) && hpos == 339 && interlace() == false)return false;
if(vpos == vlimit && interlace() == false)return false;
if(vpos == vlimit && hpos == 339)return false;
if(vpos > vlimit)return false;
if(hpos > 339)return false; |
And I'm forced to make the CPU calculate video timing positions. And
no, it makes no difference that the routines themselves are inside the
PPU core. None whatsoever. We're just obfuscating the fact that we're
bullshitting things for speed.
Yeah -- I know, I know. We can comment and explain why that's there.
Thank you. That doesn't change the fact that code is disgusting and
doesn't belong anywhere in a "self-documenting" emulator. What a joke
that's turning out to be.
|
Jesus...Go with what YOU want already. If you want to do the method
that's closer to how hardware work, then go with that and never mind
others. If you want to go by a faster method, then go with that too.
But you said it yourself you made this to be a self documenting
emulator. There's no reason you should force yourself to be disgusted
with codes you don't like just to get speed gains... I know we've been
over this but speed considerations (particularly those of this
relatively small magnitude) are imo, very short terms considerations
and when those speed constraints are rendered pointless and essentially
nuked by faster, more powerful CPUs, you're gonna tell yourself "Damn,
I should have done it the way I really wanted then..."
I'm not trying to be disrespectful as you know I greatly respect your
work. I just don't see why you should go against what you're own ideas
of what your emulator should be.
Last edited by Snark on Wed Feb 20, 2008 7:13 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 20, 2008 7:09 pm Post subject: |
|
byuu wrote: |
The good news -- it works great. The CPU and PPU run independently of each other.
The bad news -- it's slow. 68fps -> 44fps slow. This is with the
same scanline renderer. I know, it boggles my mind that this emulator
can get so much slower, too.
I simply can't justify that kind of speed loss. ... |
What's the code like? Is there any chance of optimisation making more than a minor difference?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 20, 2008 7:34 pm Post subject: |
|
Quote: |
68 FPS on what, exactly? |
Pentium IV 1.7GHz. Given, this is the "solid blue screen hitting STP
instruction" test ROM. Real games are even slower.
Well, Zelda 3 fairs better. 40fps -> 31fps. That's actually much more acceptable.
Quote: |
Jesus...Go with what YOU want already. |
Yeah, that's what I'm thinking. I had a ray of hope of getting this
thing usable on everyone's computers. v017 reaches ~55-60fps on this
old Pentium IV. It's only the new IRQ stuff that's so slow.
But it just wasn't meant to be. I'll just have to post v017+v028 and tell people to use those for gaming.
Quote: |
What's the code like? Is there any chance of optimisation making more than a minor difference? |
It's hard to say, really. I have a lot of ideas that could really help
out. Synchronization testing every clock tick adds a lot of extra work
for CPU<>SMP sync. Separating that to just do CPU<>PPU, and
perform one faster CPU<>SMP sync would help. A circular ring
buffer for timeshifting within the CPU core would also help out quite a
bit. I could maybe pull off a few more optimizations, too. It's really
hard to say, but I don't think I'm going to match the old speed.
But yeah, enough talk. I think it's time to give up on 60fps for good.
Let's finalize bsnes v029 and move on. If anyone comes along and wants
to maintain the older versions that ran at decent speeds, we can do
that.
Code example, nowhere near hardware accurate, just a test:
Code: |
alwaysinline
void pin(bool &v, bool &h, signed offset) {
uint16_t vc = vcounter;
uint16_t hc = hcounter + offset;
if(offset > 0) {
while(hc >= 1364) {
hc -= 1364;
if(++vc >= 262) vc = 0;
}
} else {
while((int16_t)hc < 0) {
hc += 1364;
if((int16_t)--vc < 0) vc = 261;
}
}
//printf("calculated %3d,%4d with offset of %d from %3d,%4d\n", vc, hc, offset, vcounter, hcounter);
v = vc >= 225;
h = hc >= 1096;
}
alwaysinline void sync_cpuppu() {
if(clock.cpuppu < 0) {
clock.active = THREAD_PPU;
co_switch(thread_ppu);
}
}
alwaysinline void sync_ppucpu() {
if(clock.cpuppu >= 0) {
clock.active = THREAD_CPU;
co_switch(thread_cpu);
}
}
alwaysinline void addclocks_cpu(uint clocks) {
clock.cpusmp -= clocks * (uint64)clock.smp_freq;
if(clock.cpusmp < -(250000 * (int64)20000000)) { sync_cpusmp(); }
clock.cpuppu -= clocks;
if(clock.cpuppu < -1364) sync_cpuppu();
}
alwaysinline void addclocks_ppu(uint clocks) {
clock.cpuppu += clocks;
if(clock.cpuppu > 1364) sync_ppucpu();
}
void sCPU::add_clocks(uint clocks) {
/*if(status.dram_refreshed == false) {
if(status.hclock + clocks >= status.dram_refresh_position) {
status.dram_refreshed = true;
clocks += 40;
}
}*/
counter.sub(counter.irq_delay, clocks);
clocks >>= 1;
while(clocks--) {
bool vold, hold;
ppu.pin(vold, hold, -scheduler.clock.cpuppu);
scheduler.addclocks_cpu(2);
bool vnew, hnew;
ppu.pin(vnew, hnew, -scheduler.clock.cpuppu);
if(hold == 1 && hnew == 0) { status.hclock = 0; status.vcounter++; scanline(); }
else status.hclock += 2;
if(vold == 1 && vnew == 0) { status.vcounter = 0; }
//printf("%3d,%4d <%d,%d - %d,%d> %d\n", status.vcounter,
status.hclock,vold,hold,vnew,hnew,-scheduler.clock.cpuppu);
//getch();
poll_interrupts();
}
} |
Yeah, we can do a lot better. I know.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Feb 20, 2008 7:46 pm Post subject: |
|
An
idea: would it be too hard to integrate blargg's DSP code into 0.17?
That would give the people with slower PCs 100%(Or close enough for
their usages.) accurate sound. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Wed Feb 20, 2008 8:10 pm Post subject: |
|
Wouldnt that be taking it to the next level
discrete snes emulation, that would rock even at 0.1fps:)
And it should be 99.9% hardware accurate |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Feb 20, 2008 8:23 pm Post subject: |
|
Well,
unfortunately you have a lot of people who let their computers
depreciate to nothing rather than following upgrade/resell cycles that
wouldn't cost them any more. You're a bit ahead of the curve with your
speed hits in regards to the rate at which people upgrade. Because if
this were to happen three years from now, no one would bat an eye. So
if anything, your frustration in wanting both playability and
self-documentation is largely due to the time at which you are making
these changes.
I'm just a little surprised because
you seem to find this stuff regularly: code you've already written and
don't bring up as "ugly" in old debates about forking bsnes, but now
realize as unacceptably non-self-documenting insomuch that
range-testing isn't even possible. I keep sitting here thinking that
the only significant speed hit left is a dot-based renderer. And then
wham! Something else needs to get rewritten to be more like hardware
which incurs a significant speed hit. Now you've made my core 2 duo
cry.  |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 20, 2008 9:07 pm Post subject: |
|
FitzRoy wrote: |
And
then wham! Something else needs to get rewritten to be more like
hardware which incurs a significant speed hit. Now you've made my core
2 duo cry.  |
Don't forget that doing this is very much a part of making a dot-based
renderer! Indeed, in the discussions I remember, almost no emphasis has
been placed on the complexity of a theoretical dot-based renderer,
except by saying that 'even if all the synchronisation was doable,
let's not forget that's not the only thing it'll have to do'. With this
implemented, that hurdle will be gone. Myself, I'm not that worried
about the speed, but then I intend to overclock my next processor quite
a bit. The fact that the dot-based renderer and the current scanline
one will be able to co-exist sounds very attractive to me, though. One
thing I'm hoping will alleviate things a bit will be mudlord's OpenGL
code, so filters such as the NTSC one can be done on the graphics card.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 20, 2008 9:25 pm Post subject: |
|
Quote: |
But you said it yourself you made this to be a self documenting
emulator. There's no reason you should force yourself to be disgusted
with codes you don't like just to get speed gains... I know we've been
over this but speed considerations (particularly those of this
relatively small magnitude) are imo, very short terms considerations
and when those speed constraints are rendered pointless and essentially
nuked by faster, more powerful CPUs, you're gonna tell yourself "Damn,
I should have done it the way I really wanted then..." |
Is it just me or is that the same attitude MAME developers share. In
that, they don't give a rats ass about optimization, as long as it
perfectly documents the hardware, even on a subcycle level. I
personally feel having efficient code is important, and if there is a
limit to how much optimization you can do, so be it. But not optimizing
at all....that does not sit right with me at all, as I have always been
a fan of code that is optimized the most. And without resorting to
emulation hacks.
Sorry for going off on a tangent, its just I don't like the idea of unoptimized code at all.
But heck, for the sake of argument, people could just use 0.17 if they
want a moderately fast and cycle accurate emulator. Especially if it
only has only 6 known emulation bugs. But, if people want to go the
more accurate route and use newer versions, so be it.
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 20, 2008 9:28 pm Post subject: |
|
Quote: |
One
thing I'm hoping will alleviate things a bit will be mudlord's OpenGL
code, so filters such as the NTSC one can be done on the graphics card. |
If I could get 0.17 to compile, I could even get HLSL shader code
working in BSNES, and at a nice zippy speed. Currently my new CPU
struggles a lil with the current BSNES builds, whereas 0.17 runs
superbly and I noticed zero emulation issues in the games I play.
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Wed Feb 20, 2008 10:17 pm Post subject: |
|
Hmm, question about cpu.ntsc_clock_rate and audio frequency and such..
So I've noticed the difference between video synchronize is night and
day, and I really can't deal with the tearing and choppiness that
leaving it off causes on my LCD. But as we all know, turning it on
causes audio to crackle here and there (seemingly random sometimes).
I was playing around with every setting I could trying to get audio to
play correctly, and the only thing that seemed to have an effect was
lowering the cpu.ntsc_clock_rate. I pretty much halved it just to see
what would happen, and although the game was running at 32fps, the
audio sounded great. So I gradually increased it until it was around
59fps and audio still sounded good. I could live with this loss of 1
fps. Is there a simple explanation as to why this happens? Furthermore,
is there a way to calculate the optimal value for cpu clock rate to get
the fastest video without audio screwing up? |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Feb 20, 2008 10:27 pm Post subject: |
|
mudlord wrote: |
I
personally feel having efficient code is important [...]. But not
optimizing at all....that does not sit right with me at all, as I have
always been a fan of code that is optimized the most. |
It's probably just a question of how deep you want to go. If you want
to treat each processor as a black box then you can pull off all crazy
programming tricks "inside" of these chips, as long as the outside
behaviour stays the same. Others might want to emulate the inner
operations as well, and will reject that kind of optimization.
The fastest code might be a huge multi-dimensional array for each
output, with one value for every combination of inputs. But it won't be
documenting the hardware at all.
_________________
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 Feb 20, 2008 11:47 pm Post subject: |
|
What
I think would be good, byuu, is if you finished .029, but then skipped
up to .050 for the S-PPU releases. That way, if anything comes up (like
OpenGL for windows) and needs fixed or added, there will be plenty of
versions left in between to backport them. I dunno, there has to be
some way to move on, but still allow for certain changes. I can tell
you're itching to do the dot-based thing. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Feb 21, 2008 12:01 am Post subject: |
|
Quote: |
It's
probably just a question of how deep you want to go. If you want to
treat each processor as a black box then you can pull off all crazy
programming tricks "inside" of these chips, as long as the outside
behaviour stays the same. Others might want to emulate the inner
operations as well, and will reject that kind of optimization.
The fastest code might be a huge multi-dimensional array for each
output, with one value for every combination of inputs. But it won't be
documenting the hardware at all. |
I see your points, but I still feel optimization should be of importance, rather than rejecting it entirely.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 21, 2008 1:40 am Post subject: |
|
mudlord wrote: |
Quote: |
But you said it yourself you made this to be a self documenting
emulator. There's no reason you should force yourself to be disgusted
with codes you don't like just to get speed gains... I know we've been
over this but speed considerations (particularly those of this
relatively small magnitude) are imo, very short terms considerations
and when those speed constraints are rendered pointless and essentially
nuked by faster, more powerful CPUs, you're gonna tell yourself "Damn,
I should have done it the way I really wanted then..." |
Is it just me or is that the same attitude MAME developers share. In
that, they don't give a rats ass about optimization, as long as it
perfectly documents the hardware, even on a subcycle level.
|
Obviously not a M.A.M.E developer, but yes, I believe MAME have a
similar approach. I don't see that as being a bad point though.
Quote: |
I personally feel having efficient code is important, and if there is a limit to how much optimization you can do, so be it. |
From my non programmer's perspective: There's a difference between
"code optimization" and different coding approaches.
What byuu said when he wrote:
Quote: |
That
doesn't change the fact that code is disgusting and doesn't belong
anywhere in a "self-documenting" emulator. What a joke that's turning
out to be. |
...felt in the later category imo. It's a different "approach"
altogether. "Code optimization" would be things like selected coding
language (C++, assembly etc) compiler optimization, smarter more
efficient coding and so on without fundamentally changing what the code
actually "do".
Quote: |
But
not optimizing at all....that does not sit right with me at all, as I
have always been a fan of code that is optimized the most. And without
resorting to emulation hacks. |
That's the point.
It's a fine line between them. What one may consider a hack, another may consider optimization...
Quote: |
But
heck, for the sake of argument, people could just use 0.17 if they want
a moderately fast and cycle accurate emulator. Especially if it only
has only 6 known emulation bugs. But, if people want to go the more
accurate route and use newer versions, so be it. |
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Feb 21, 2008 1:59 am Post subject: |
|
Quote: |
It's a fine line between them. What one may consider a hack, another may consider optimization... |
Hmm, well you could try to develop a routine in the smallest amount of
code possible, yet it still gives the exact same output emulation wise.
Which I think is not a hack if it doesn't alter from precisely how the
hardware works. And if you optimized as much as you can without using
hacks, so be it . At least you gave it your best shot though, than not trying at all. 
Quote: |
...felt
in the later category imo. It's a different "approach" altogether.
"Code optimization" would be things like selected coding language (C++,
assembly etc) compiler optimization, smarter more efficient coding and
so on without fundamentally changing what the code actually "do". |
Yes and thats my point. If people could be very smart and code
efficiently without breaking fundamentals (via using hacks), then thats
definitely not a bad thing. But I do believe compromises can be made,
like if you prefer code clarity. But of course, theres the
exceptions..blargg's code is very nice in style and yet its highly
optimized & accurate too.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Feb 21, 2008 2:48 am Post subject: |
|
mudlord wrote: |
Quote: |
It's a fine line between them. What one may consider a hack, another may consider optimization... |
Hmm, well you could try to develop a routine in the smallest amount of
code possible, yet it still gives the exact same output emulation wise.
.
|
Like byuu said: yes, you could in theory get 100% identical output that
way (and get a faster emulator in the process).
However, if your aim is not only to get 100% identical output but to
document and virtually "reproduce" very closely how the hardware
worked, then you wouldn't want to choose that route.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 21, 2008 3:47 am Post subject: |
|
Snark wrote: |
However,
if your aim is not only to get 100% identical output but to document
and virtually "reproduce" very closely how the hardware worked, then
you wouldn't want to choose that route. |
You might consider it if it's a difference between 1fps and 60, though.
Not to say I disagree with you, but having run into speed issues with
my shaders, I know how very frustrating it can be when you see the fps
just trickling away.. even when you know you're getting a new card for
your birthday! I's very demoralising, and I'm glad that in this case
there are still alternate solutions that don't, atleast, compromise the
result, even if they do complicate matters internally. We all know byuu
would still find the will to work on it, which is one of the things
that keeps me hooked on this topic, but it's nice when, hmm, how to put
this.. a situation doesn't call for 'what doesn't kill us makes us
stronger', for once. There may not be true magic in computer science,
but it's those almost frantic times when there's light at the end of
the tunnel that inspire.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 21, 2008 5:34 am Post subject: |
|
New
WIP with XP / Vista theming and cheat path selection. Note that cheat
selection is just a placeholder. It still saves in the same folder as
the ROM for now.
I also spent about four hours
trying to get the dual counter into a fork of bsnes ... and had my ass
handed to me. Rigging something up really quickly that will break every
last timing test I have is easy. But it looks like doing this properly
is going to be an extreme undertaking that will take at least a few
weeks. The code is just too old and too hardcoded.
I've started cleaning up that code to match my modern programming
style. It seems the only way to really tackle this is going to be very
slowly moving variable by variable to a separate class/struct somewhere
(and running my regression test ROMs each time), and then once the
entire thing is moved out of the CPU, try and clone it and fork off the
PPU to its own thread.
By my estimates, it appears that simply splitting the CPU and PPU, and
giving the PPU its own cothread, is eating ~8% of performance. The good
news though is that if and when I succeed, it's quite possible I can
emulate the OAM cache behavior, which would fix the black scanlines in
Dr Franken and Winter Olympics.
Some other good news ... I decided there was really no sane reason to
have different clock frequencies for the CPU<>PPU and
SMP<>DSP, since the real SNES only has two crystal clocks anyway.
A novelty, sure, but that would complicate the fuck out of dual
counters. With that gone, I can avoid a 64-bit multiplication during
each SMP/DSP addclocks call. That gives a modest ~2% speedup --
possibly placebo.
Looks like a ring buffer for timeshifting backwards isn't going to help
much. I only notice a ~1-2fps difference even when disabling
timeshifting completely. Not surprising, timeshifting really doesn't
have that much overhead to it.
Oh yeah, it seems I disabled the code that set the hclock to 186 upon
reset a while back, which was causing some of my oldest tests to fail.
I can't remember why I disabled that (maybe something to do with
cothreads), and enabling it didn't seem to cause any problems, so ... I
left it enabled. Let me know if anything screwy happens. |
|
etabeta Rookie
Joined: 17 Jun 2007
Posts: 32
|
Posted: Thu Feb 21, 2008 6:48 am Post subject: |
|
mudlord wrote: |
Is
it just me or is that the same attitude MAME developers share. In that,
they don't give a rats ass about optimization, as long as it perfectly
documents the hardware, even on a subcycle level. |
[OT]except that in the past 5 months they started to exploit 64bit
& dual cores to speed up ALL the 3d systems (now Gauntlet Legends
is above 75% of speed vs. 1FPS last spring)... it's just that in MAME
optimization comes definitely after accuracy[/OT]
anyway it's just a matter of tastes, and I love the fact there are speed focused emulators as well
back to bsnes, I'd go with a final 0.029 with all the changes in UI and
the refactorizations in the source, then begin to work on the new/slow
PPU
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 9:08 am Post subject: |
|
Indeed,
mame does optimise after the emulation is accurate, but optimising will
never involve hackish approaches (which means a similar speed hit that
bsnes has) |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Feb 21, 2008 9:30 am Post subject: |
|
vkamicht wrote: |
Hmm, question about cpu.ntsc_clock_rate and audio frequency and such..
So I've noticed the difference between video synchronize is night and
day, and I really can't deal with the tearing and choppiness that
leaving it off causes on my LCD. But as we all know, turning it on
causes audio to crackle here and there (seemingly random sometimes).
I was playing around with every setting I could trying to get audio to
play correctly, and the only thing that seemed to have an effect was
lowering the cpu.ntsc_clock_rate. I pretty much halved it just to see
what would happen, and although the game was running at 32fps, the
audio sounded great. So I gradually increased it until it was around
59fps and audio still sounded good. I could live with this loss of 1
fps. Is there a simple explanation as to why this happens? Furthermore,
is there a way to calculate the optimal value for cpu clock rate to get
the fastest video without audio screwing up? |
This has been the biggest downside to bsnes. There's some secret other
emulators are hiding about how to play the audio crackle-free with
vsync on
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Thu Feb 21, 2008 9:56 am Post subject: |
|
other emulaters run games faster (or was it slower?) then a real snes so that it is in sync with 60hz.
_________________
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. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 11:51 am Post subject: |
|
franpa wrote: |
other emulaters run games faster (or was it slower?) then a real snes so that it is in sync with 60hz. |
Thats pretty interesting, Byuu would it be possible to add a underclock
feature to bsnes so that it indeed runs a little bit slower but exactly
in sync with LCD's, this would solve all the tearing issues when the
cpu is able to keep 60fps
|
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Thu Feb 21, 2008 1:15 pm Post subject: |
|
vkamicht wrote: |
Hmm, question about cpu.ntsc_clock_rate and audio frequency and such..
So I've noticed the difference between video synchronize is night and
day, and I really can't deal with the tearing and choppiness that
leaving it off causes on my LCD. But as we all know, turning it on
causes audio to crackle here and there (seemingly random sometimes).
I was playing around with every setting I could trying to get audio to
play correctly, and the only thing that seemed to have an effect was
lowering the cpu.ntsc_clock_rate. I pretty much halved it just to see
what would happen, and although the game was running at 32fps, the
audio sounded great. So I gradually increased it until it was around
59fps and audio still sounded good. I could live with this loss of 1
fps. Is there a simple explanation as to why this happens? Furthermore,
is there a way to calculate the optimal value for cpu clock rate to get
the fastest video without audio screwing up? |
vkamicht mentioned about underclocking too, I guess his post just got overlooked
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Feb 21, 2008 1:48 pm Post subject: |
|
I
finally took the time to try using the GCC profiling compilation mode
(-fprofile-generate and -fprofile-use) byuu suggested to me some time
ago. During the generation process I let it run the Chrono Trigger,
Super Mario World and Super Mario Kart intros. That seems to be enough
for me to get a steady 60FPS during the CT intro! :-D
http://www.redhat.com/magazine/011sep05/features/gcc/#tb-alias,
just below the table are instructions. It's the "flags = " line in the
Makefile under the entry for your compiler (GCC or Visual C++) you want
to change.
_________________ MSI K8N NEO4-FI | AMD
Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200 3-3-3-8 | Seagate
Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS 256MB | Pioneer
DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch Linux 64-bit |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 21, 2008 1:52 pm Post subject: |
|
I've
tried to get bsnes in sync with perfect video and audio. For many
years. It's another of the major things I'm unable to pull off myself.
I have code that allows the CPU to run up to 0.2 seconds ahead of the
SMP, and vice versa. This means that in a given emulated video frame,
the number of samples generated are wildly different.
By disabling this out-of-order execution, I take a 10-20% speed hit,
but I get a more consistent number of samples per frame.
Even with the out-of-order execution disabled, and a lowpass buffer
that adds a good 50-100ms latency, and a high-end 4-tap hermite filter
to resample audio, I'm unable to get the audio to sound right.
It seems the lowpass buffer just continues to either grow or deplete at
a constant rate, eventually the queued samples overflow and you get a
horrendously different number of samples for one quick burst.
The resampling causes very noticeable pitch differences every time it's
not by roughly ~20 samples or less. So either you go with what I have
now, and you get wildly different pitches constantly for every packet
that plays; or you take the speed hit, execute in sync, and buffer to
hell and back, and end up with smooth audio for 3-4 seconds, then hear
a really, really off pitch block for ~20-40ms.
Vblank + smooth audio is the last killer feature I really want in the
emulator, but you'll find dozens of pages in this thread where I've
tried to pull it off and failed. I don't know why everyone else can do
it but me, but they can and I can't.
Quote: |
I
finally took the time to try using the GCC profiling compilation mode
(-fprofile-generate and -fprofile-use) byuu suggested to me some time
ago. During the generation process I let it run the Chrono Trigger,
Super Mario World and Super Mario Kart intros. That seems to be enough
for me to get a steady 60FPS during the CT intro! :-D |
Wow, on a 3000+?? Not bad! I can only imagine what kind of framerates
would be possible with range testing. Probably around ~100fps.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Feb 21, 2008 2:02 pm Post subject: |
|
byuu wrote: |
Quote: |
I
finally took the time to try using the GCC profiling compilation mode
(-fprofile-generate and -fprofile-use) byuu suggested to me some time
ago. During the generation process I let it run the Chrono Trigger,
Super Mario World and Super Mario Kart intros. That seems to be enough
for me to get a steady 60FPS during the CT intro! :-D |
Wow, on a 3000+?? Not bad! I can only imagine what kind of framerates
would be possible with range testing. Probably around ~100fps.
|
Yeah, and it's not even overclocked (for those who don't know it's
running at 1.8GHz). If I disable speed regulation it shows ~62-63 FPS
when the text floats in.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 2:15 pm Post subject: |
|
Okay, i want to crack this nut
How does the snes do it?, the sound doesn't crackly, but the image would still tear.
So we have to fix the sound crackle before we can fix the tearing
On hardware fixing the tearing would simply be done by slowing the snes
down to exactly 60fps (easier said then done), doing this would
slowdown the sound to and slightly change the pitch, but the change
would be constant.
So how does the communication between the cpu and the smp work in the
real snes and what is bsnes doing differently from that? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 21, 2008 2:51 pm Post subject: |
|
tetsuo55 wrote: |
How does the snes do it?, the sound doesn't crackly, but the image would still tear.
So we have to fix the sound crackle before we can fix the tearing
On hardware fixing the tearing would simply be done by slowing the snes
down to exactly 60fps (easier said then done), doing this would
slowdown the sound to and slightly change the pitch, but the change
would be constant.
So how does the communication between the cpu and the smp work in the
real snes and what is bsnes doing differently from that? |
SNES -> TV is very different from bsnes -> PC -> monitor/TV.
Operating systems implement all sorts of buffering and most sound cards
work at 48000 (sometimes even 44100Hz?) internally. I don't know the
technical details about what the TV does with the SNES' analog audio
signal, but you can see the process is much more direct.
As for how bsnes is different from how the SNES works, remember that
the SNES contains several specialised processors that work in parallel
at different speeds (again I don't know the technical details, so bear
with me). The SNES doesn't need to synchronise, components just poll
eachother for their current states. What I don't know is if video and
sound are output at their own independent speeds, but they are
generated independently without any hassle. bsnes builds up a buffer of
frames while going back and forth between the different components to
keep them synchronised, but I don't know how it chooses when to output
(does it just wait until a certain threshold is reached?). Even so, I
expect it can only do this on synchronisation events, and since
components aren't, as byuu mentioned, forced to run lockstep, the
amount of frames it has to output differs wildly each time.
By the way, this reminded me, I recall a major problem with video
synchronisation was that D3D has some big latency issues with
wait-for-vblank calls? And it was mentioned that these problems might
not be present in OpenGL.. now that Linux has OpenGl support, have you
checked if this is the case?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 3:12 pm Post subject: |
|
I am aware of these limitations, working around them is not a priority, getting the audio to stop crackling is for now.
So what google tells me is that the spc700 recieves "code" which it
executes together with its DSP, there is no feedback to the snes CPU,
so it would seem that the spc700 just runs through the program it gets
and doesnt care about the rest of the snes
The game is written in such a way that the sound doesnt go out of sync or wacky or whatever.
Also according to google the spc700 except a startup header to play the track/sample/fx
---
nevermind, my train of though would kill bsnes(it would basically mean
breaking down bsnes to the point where everything is emulated at its
native speed, as you would need to let the mpc run independantly
whitouht gettign the audio out of sync) mame seems to be able do this
though, with discrete audio emulation
-----
Lol i think i just explained why sound crackles  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Feb 21, 2008 3:20 pm Post subject: |
|
As Verdauga said, things are a bit different for the SNES.
On the PC, when synching with the display, you're updating at exactly 60 Hz (in the ideal case; it gets worse with 75, 85 or 100 Hz). But NTSC doesn't:
Wikipedia wrote: |
The NTSC field refresh frequency was originally exactly 60 Hz in the black-and-white system [...]
In the black-and-white standard, the ratio of audio subcarrier
frequency to line frequency is 4.5 MHz / 15,750 = 285.71. In the color
standard, this becomes rounded to the integer 286, which means the
color standard's line rate is 4.5 MHz / 286 ~ 15,734 lines per second.
Dividing by 262.5 lines per field, this gives approximately 59.94
fields per second. |
The SNES generates signals that directly drive the electron beam; most
(all?) games update the PPU parameters in VBlank or HBlank, exactly in
sync with the TV. It guarantees that there's no tearing.
Sound generation is separate from video generation; the audio unit runs independently from the SNES CPU.
_________________
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: Thu Feb 21, 2008 3:31 pm Post subject: |
|
Yeah i didn't know the sound chip acts as a completely seperated system
if this was not the case syncing would be a peace of cake
Simply slow down the snes's 60.09 to exactly 60 and live with the 0
.09 change in pitch
As for how the tv works, a combination of the ntsc filter and my idea
for a mask filter would result in the exact same image as the snes on
your tv |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 21, 2008 3:49 pm Post subject: |
|
The
confusion is likely coming from the fact that there are emulators that
have it and face similar translation of hardware problems, so people
assume that it's not hard in bsnes. But this feature is almost as
popular as savestates, and if it were easy to do, a blargg or Nach
would have come in and done it already. So it obviously isn't. I don't
know why I forgot to put it in my unsupported feature list. It's there
now.
I agree, though, that opengl should be explored. I have the faint hope that vsync is somehow easier with it. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 21, 2008 4:25 pm Post subject: |
|
OpenGL is even worse. You have no control over it. You can request a double buffered visual, but that's it.
For nVidia, you have to run nvidia-settings to enable or disable vsync
globally. It can't be controlled through software.
Worse yet, it's not page flipping (obviously, other stuff onscreen),
meaning it's even slower. And in this case, with no audio output, I
can't even get smooth video to fill the screen. I have to use a ~3x
scaler on my 1920x1200 monitor. Anymore and the top of the video will
still tear. Basically because it's taking too long to blit the new
video to the screen that the vblank period is running over.
And even more damning, is that there is no DirectSound on Linux. The
best there is, is OpenAL. You can only query when entire buffers have
completed, rather than just asking where the current playback cursor is
at. That makes predicting how much you need to resample your current
audio block by that much harder. You basically need to add lots more,
much smaller, blocks and even then, you'll be worse off than with
DirectSound.
Linux is just ... dark ages with this stuff. Video, audio, input ...
it's no wonder most companies won't even port games to Linux. Linux'
APIs just suck royally. Microsoft is light years ahead with DirectX.
Quote: |
But
this feature is almost as popular as savestates, and if it were easy to
do, a blargg or Nach would have come in and done it already. |
Yeah, I'm sure someone would have added it by now if it were easy. I've
considered offering a bounty on it, but I'm afraid that the quality of
code written for money will be far, far worse than code written by
someone passionate about the issue.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 5:11 pm Post subject: |
|
yeah i was just hoping for a thinking outside of the box approach  |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Thu Feb 21, 2008 5:17 pm Post subject: |
|
creaothceann wrote: |
On the PC, when synching with the display, you're updating at exactly 60 Hz (in the ideal case; it gets worse with 75, 85 or 100 Hz).
|
I still don't believe PCs do exactly 60Hz. It depends on the timing
standard you're using: GTF is 59.998 Hz, DMT is 60.020 Hz and CVT is
59.895 Hz.
I don't know how much there's real time variance though, if any.. You
need to ask someone who knows more about video card drivers
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Feb 21, 2008 5:17 pm Post subject: |
|
an
outside of the box approach would be to convince torvalds the benefit
of having a good Kernel API for direct multimedia access.
Until then, linux won't go anywhere faster.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Thu Feb 21, 2008 5:21 pm Post subject: |
|
funkyass wrote: |
an
outside of the box approach would be to convince torvalds the benefit
of having a good Kernel API for direct multimedia access.
Until then, linux won't go anywhere faster. |
torvalds needs to piss off and leave people who actually create usefull
updates to the kernel alone.(refering to the scheduler warz)
Also linux needs to adapt a damn standard already, supporting
everything and everyones mom is fun and all, but just check out all the
posts here to see what a freakin nightmare it is.
the best thing would be to simply have opengl and openal, preferably
through the oss4 api, i don't know what the best linux api is for
opengl (to allow backwards compatibility with non-opengl cards)
Last edited by tetsuo55 on Thu Feb 21, 2008 5:23 pm; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 21, 2008 5:23 pm Post subject: |
|
byuu wrote: |
OpenGL is even worse. You have no control over it. You can request a double buffered visual, but that's it. |
Hmm, too bad. By the way, can I ask you something? Since you made those
interpolation filters the other day.. I'm trying to implement a
gaussian blur filter in GLSL, but I'm not sure whether to use the
Normal Distribution function or the Gaussian Integral (so that i.e. the
centre pixel would be the area under the Normal Distribution function
in the domain [-0.5,+0.5]). I made a GLSL-compatible function (code
below) that approximates the integral from 0 to 'a', although it
doesn't yet take standard deviation into account.. but I'm sure using
it would slow any filter to a crawl.
Code: |
const float PI = 3.1415926535897932;
float ans = 0.;
float a = .5;
for(float passes = 10000.; passes > 0.; passes--) ans = passes / (((even(passes)+1.)*a) + ans);
ans = .5*sqrt(PI) - exp(-(a*a))/(2.*a + ans); |
(I'm using 'float' since this is meant for GLSL, which doesn't know
doubles or long doubles; even() just returns whether the number input
is even; it returns a float for ease of use)
PS: I got the function for approximating from Wolfram Research's Mathworld website.
Last edited by Verdauga Greeneyes on Thu Feb 21, 2008 5:39 pm; edited 1 time in total
|
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Thu Feb 21, 2008 5:27 pm Post subject: |
|
byuu: have you tried SDL API? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 21, 2008 5:39 pm Post subject: |
|
Ring buffer for previous clock times:
Code: |
struct History {
struct State {
uint16_t vcounter;
uint16_t hcounter;
} value[32];
unsigned index;
alwaysinline void enqueue(uint16_t vcounter, uint16_t hcounter) {
State &state = value[index++];
index &= 31;
state.vcounter = vcounter;
state.hcounter = hcounter;
}
alwaysinline uint16_t vcounter(unsigned offset) {
return value[(index - offset) & 31].vcounter;
}
alwaysinline uint16_t hcounter(unsigned offset) {
return value[(index - offset) & 31].hcounter;
}
} history;
void run() {
history.enqueue(counter.vcounter, counter.hcounter);
counter.add(2);
printf("%3d,%4d -> %3d,%4d -> %3d,%4d -> %3d,%4d -> %3d,%4d\n",
counter.vcounter, counter.hcounter,
history.vcounter(1), history.hcounter(1),
history.vcounter(2), history.hcounter(2),
history.vcounter(3), history.hcounter(3),
history.vcounter(4), history.hcounter(4)
);
} |
Optimizations are welcome.
Output:
Code: |
0,1360 -> 0,1358 -> 0,1356 -> 0,1354 -> 0,1352
0,1362 -> 0,1360 -> 0,1358 -> 0,1356 -> 0,1354
1, 0 -> 0,1362 -> 0,1360 -> 0,1358 -> 0,1356
1, 2 -> 1, 0 -> 0,1362 -> 0,1360 -> 0,1358
1, 4 -> 1, 2 -> 1, 0 -> 0,1362 -> 0,1360
1, 6 -> 1, 4 -> 1, 2 -> 1, 0 -> 0,1362
1, 8 -> 1, 6 -> 1, 4 -> 1, 2 -> 1, 0
1, 10 -> 1, 8 -> 1, 6 -> 1, 4 -> 1, 2 |
This replaces the old timeshifting code (scpu/timing/timeshift.cpp):
Code: |
alwaysinline void sCPU::timeshift_backward(uint clocks, uint &vtime, uint &htime) {
if(htime >= clocks) {
htime -= clocks;
} else {
htime += status.prev_line_clocks - clocks;
if(vtime > 0) {
vtime--;
} else {
vtime = status.prev_field_lines - 1;
}
}
} |
It looks like it'd be slower, but it's about the same. I get ~2% less
speed with my test ROM, and ~2% more speed in Zelda 3. Go figure.
The important part is eliminating the need to track prev_line_clocks
and prev_field_lines. This will help with moving counters out of the
CPU core. As far as the invalid states of the buffer on bootup, adding
186 clocks at reset before any interrupts can trigger anyway eliminate
that concern.
This backward timeshifting is needed for NMI and IRQ timing. There
seems to be some sort of hardware delay in acknowledging them. NMIs are
delayed two clock ticks, VIRQs ten, H(V)IRQs fourteen. Not sure why,
but I know it's there. Have lots of tests that verify those numbers.
Quote: |
byuu: have you tried SDL API? |
There are drivers for SDL video and SDL input in bsnes/Linux now, so yes.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Thu Feb 21, 2008 7:10 pm Post subject: |
|
mudlord wrote: |
Hmm,
well you could try to develop a routine in the smallest amount of code
possible, yet it still gives the exact same output emulation wise.
Which I think is not a hack if it doesn't alter from precisely how the
hardware works. And if you optimized as much as you can without using
hacks, so be it . At least you gave it your best shot though, than not
trying at all. |
It depends on the goal(s). If accurate, fast emulation, then the above
is progress. If the goal is clear code that is easy to update with new
findings, then the above is usually detrimental. As you say later, some
code can achieve all three, but the techniques require lots more time
to discover.
Verdauga Greeneyes (or someone familiar with shaders), can those
shaders use an IIR filter, or does it support FIR only (or the
equivalent, where your code just has to calculate each final pixel,
given the nearby pixels)?
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 21, 2008 7:43 pm Post subject: |
|
blargg wrote: |
Verdauga
Greeneyes (or someone familiar with shaders), can those shaders use an
IIR filter, or does it support FIR only (or the equivalent, where your
code just has to calculate each final pixel, given the nearby pixels)? |
I looked those terms up before (when I noticed the GIMP, I believe it
was, offering either IIR or.. well, I can't remember what the
alternative was, for their Gaussian blur) but I don't really understand
what either of them mean.. However from the last sentence of your post
I would say FIR. GLSL Fragment shaders don't allow intra-pixel
communication, so a filter is run from the perspective of each rendered
pixel each frame. According to the shader language specs this is done
so pixels can be rendered in parallel without any hassle.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 21, 2008 9:10 pm Post subject: |
|
Wish
I could help, but I still don't know the algorithm for gaussian blur. I
got all of the ones I have from some random website. blargg helped me
apply them to 2D images. And Bisqwit tells me that the way I'm doing it
sucks when you got scale more than ~4-5x, since my sampling radius
sucks.
Meh, I really can't tell a whole lot of
difference from linear to hermite anyway. The latter is surely a bit
sharper, but not worth the speed hit or added emulator complexity. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 21, 2008 9:26 pm Post subject: |
|
byuu wrote: |
Wish
I could help, but I still don't know the algorithm for gaussian blur. I
got all of the ones I have from some random website. blargg helped me
apply them to 2D images. And Bisqwit tells me that the way I'm doing it
sucks when you got scale more than ~4-5x, since my sampling radius
sucks.
Meh, I really can't tell a whole lot
of difference from linear to hermite anyway. The latter is surely a bit
sharper, but not worth the speed hit or added emulator complexity. |
Alright, thanks for your answer anyway. If I can figure out how to vary
the standard deviation (my maths is so rusty) I'll simply test both,
perhaps compare them to the result something like photoshop gets.
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Feb 22, 2008 3:18 am Post subject: |
|
byuu wrote: |
Wish
I could help, but I still don't know the algorithm for gaussian blur. I
got all of the ones I have from some random website. blargg helped me
apply them to 2D images. And Bisqwit tells me that the way I'm doing it
sucks when you got scale more than ~4-5x, since my sampling radius
sucks.
Meh, I really can't tell a whole lot
of difference from linear to hermite anyway. The latter is surely a bit
sharper, but not worth the speed hit or added emulator complexity. |
perhaps something much further down the road when more important things are sorted out.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Feb 22, 2008 6:54 am Post subject: |
|
Okay, I worked out a method for HLSL shaders for BSNES.
Go here
and download the shader pack I compiled. Unzip d3d9.dll to the BSNES
emulator directory. Unzip ONE shader entitled "fakehdr.fx" to the same
BSNES directory (I put all the shaders in different groups to make them
easier to identify). Make sure you have Direct3D rendering enabled and
thats all. I only tested this with BSNES 0.17 and all my shaders
(everything except the cel shading and HDR shader is my code) should
work fine.
And here's one shader which I managed to write in a couple of minutes:

It might not look like much, but in action, its trippy has hell. Its a
improvement on the "Waves" shader I got in the pack right now tho... |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 22, 2008 9:48 am Post subject: |
|
mudlord wrote: |
Okay, I worked out a method for HLSL shaders for BSNES. |
Sweet, now I just need to learn the syntax of HLSL shaders. Did you
define any Uniforms? By the way, that wave shader -is- quite trippy.
Also, does anyone know the aspect ratio I should use if I want square
pixels? (I tried 8/7 but it makes atleast one column of pixels a bit
too wide)
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Feb 22, 2008 10:07 am Post subject: |
|
mudlord wrote: |
And here's one shader which I managed to write in a couple of minutes:

It might not look like much, but in action, its trippy has hell. Its a
improvement on the "Waves" shader I got in the pack right now tho... |
Touch Fuzzy, Get Dizzy!
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Feb 22, 2008 10:13 am Post subject: |
|
Quote: |
Sweet,
now I just need to learn the syntax of HLSL shaders. Did you define any
Uniforms? By the way, that wave shader -is- quite trippy. |
The main uniforms and variables are:
CurrentBrightness (needed for HDR)
CurrentEye (also needed for HDR)
rcpres (reciprocal of screen resolution)
tex1 (main unprocessed texture from the backbuffer)
tex2 (processed texture from previous render pass)
Quote: |
Touch Fuzzy, Get Dizzy! |
You can easily change the shader variables to control the amount of
bending. Its quite fun, and I managed to make a approximation of a
stained glass window with the right values .
Although, one of my wishes is to add a uniform for the current time,
which could be useful for effects that rely on timing (like dynamic
colour shifts)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Feb 22, 2008 10:19 am Post subject: |
|
Gil_Hamilton wrote: |
Touch Fuzzy, Get Dizzy! |
my thoughts exactly
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Feb 22, 2008 12:17 pm Post subject: |
|
Well, after some more help from Wikipedia and Mathworld, here's the function I was going for:
Code: |
#include<iostream>
#include<cmath>
using namespace std;
long double Gaussian(long double a, long double b, long double c, long double p)
{ const long double sPI = 1.77245385090552;
long double ans1 = 0., ans2 = 0., t;
c = sqrt(.5/(c*c));
a *= c;
b *= c;
for(; p > 0.; p--)
{ t = p - 2.*floor(.5*p) + 1.;
ans1 = p / (t*a + ans1);
ans2 = p / (t*b + ans2);
}
if(a == 0.) return sPI - exp(-b*b)/(b + ans2);
return exp(-a*a)/(a + ans1) - exp(-b*b)/(b + ans2);
}
int main()
{ cout << 2.*Gaussian(0.0,0.5,1.0,10000.) << endl;
cout << Gaussian(0.5,1.5,1.0,10000.) << endl;
cout << Gaussian(1.5,2.5,1.0,10000.) << endl;
cout << Gaussian(2.5,3.5,1.0,10000.) << endl;
cin.get();
return 0;
}
|
Note that while the actual values don't correspond to the normal
Gaussian function (the Probability density function) the only thing we
care about here is the distribution, and the slope should be correct.
It doesn't go below zero, unfortunately, which is something I may have
to fix. Even so, I'm happy that I was able to simplify it by this much.
Mind you, I'm still not sure whether I need this, or simply the result
of the Probability density function.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 22, 2008 1:22 pm Post subject: |
|
mudlord,
you found it easier to write an external DLL that wraps all calls to
D3D functions than to add HLSL directly to my existing codebase? o.O
Still, very cool looking! I guess the best part is that a DLL should
theoretically work with any version of the emulator, but unfortunately
it's not something I can package and add to the UI. Any chance you'd be
able to help get that into my D3D driver? :) |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Feb 22, 2008 1:38 pm Post subject: |
|
Quote: |
I guess the best part is that a DLL should theoretically work with any version of the emulator |
Correct.
It should work fine on the newest BSNES versions.
Quote: |
Any chance you'd be able to help get that into my D3D driver?  |
Mainly, there needs to be mechanisms to capture the current frames,
like through render targets. For the HDR shader, 2 textures are needed.
So 2 render target surfaces are needed. There also needs to be
modifications to allow for the shaders to process the graphics,
according to how much shader passes each shader uses. Not to mention
uniform handling. So its a bit of work, but it can be done. Only the
main reason, I chose the DLL, is that it doesnt interfere with
bsnes.exe at all, so theres no risk me breaking anything there.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Feb 22, 2008 1:45 pm Post subject: |
|
mudlord wrote: |
<img>http://vba-m.ngemu.com/smwshader.JPG</img> |
There might be a small bug?

_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Feb 22, 2008 1:52 pm Post subject: |
|
Thanks, I removed that line bug.
Code is:
Code: |
float4 NormalColourPass( in float2 Tex : TEXCOORD0 ) : COLOR0
{
float4 color = tex2D( s0, Tex );
color.a = 1;
return color;
}
float4 WavePass( in float2 Tex : TEXCOORD0 ) : COLOR0
{
Tex.y = Tex.y + (sin(Tex.x*50)*0.01);
float4 Color = tex2D( s0, Tex.xy);
return Color;
} |
Which gives:
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 22, 2008 3:05 pm Post subject: |
|
New WIP.
This one nukes the region, region_scanlines, prev_line_clocks and
prev_field_lines variables, and removes timeshift.cpp; replaced with
the new history ring buffer. It doesn't appear to affect speed at all,
which is fine by me. Next up, I want to move interlace and overscan
settings back to the PPU.
All of my NMI and IRQ test ROMs, even the absolutely insane
clock-perfect ones, still pass. So there shouldn't be any regressions.
But if you feel like testing any IRQ sensitive games, that's cool.
More visibly, I've bound the .cht path to the selection in the path
settings window. So all three paths actually work now. I tested it by
sorting all of my images by ROM, SRAM and Cheat ... have to say, the
folder looks a whole hell of a lot nicer now. I can see why this
feature is so popular.
Quote: |
Mainly, there needs to be mechanisms to capture the current frames, like through render targets. |
Well, I guess if you don't mind writing up a small example I could work on porting the current code over.
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Feb 22, 2008 9:52 pm Post subject: |
|
Quote: |
Well, I guess if you don't mind writing up a small example I could work on porting the current code over. |
Sure
When I get a spare moment, I'll write a small code example on how to
capture the screen and apply a shader to it. Funnily enough, in OpenGL,
its more difficult to do this. Whereas with D3D, you can use a render
target surface and post process it using the Effect framework in D3DX.
I apologise for not modding the D3D driver to allow for, but to me the
DLL allows for more flexibility, than if the code was tied to one BSNES
version. The DLL hooks the Present() and CreateDevice() calls when
applying the shaders, as well as minor things when processing the
backbuffer. Everything else is preserved though.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 22, 2008 10:00 pm Post subject: |
|
Quote: |
Sure
:) When I get a spare moment, I'll write a small code example on how to
capture the screen and apply a shader to it. Funnily enough, in OpenGL,
its more difficult to do this. Whereas with D3D, you can use a render
target surface and post process it using the Effect framework in D3DX.
I apologise for not modding the D3D driver to allow for, but to me the
DLL allows for more flexibility, than if the code was tied to one BSNES
version. The DLL hooks the Present() and CreateDevice() calls when
applying the shaders, as well as minor things when processing the
backbuffer. Everything else is preserved though. |
Oh, I certainly don't mind the DLL. I thought it was an extremely
clever solution, in fact. I'd just love to get this into the main
codebase is all, that way I can add menu options to select the shader
and such :)
Thanks so much for the help with this! :D
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat Feb 23, 2008 1:32 am Post subject: |
|
It would be nice if someone could test something on real hardware for me.
I want to know if the Mode 7 mosaic part in the "2.68 MHz Demo" looks like bsnes or snes9x on real hardware.
The link with the ROM and two pics is here:
http://rapidshare.de/files/38648841/2.68-test.zip.html |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 23, 2008 2:32 am Post subject: |
|
Jonas Quinn wrote: |
It would be nice if someone could test something on real hardware for me.
I want to know if the Mode 7 mosaic part in the "2.68 MHz Demo" looks like bsnes or snes9x on real hardware.
The link with the ROM and two pics is here:
http://rapidshare.de/files/38648841/2.68-test.zip.html |
Impressive special effects, first time I've actually seen Mode 7 + mosaic used together.
Tested it on my 1/1/1 Super Famicom. It looks like bsnes. Worth noting,
on hardware the game screws up and crashes during the 3D cube part.
It's clearly a very poorly programmed demo. But then, you can't expect
much from those days, can you?
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat Feb 23, 2008 3:04 am Post subject: |
|
byuu wrote: |
Jonas Quinn wrote: |
It would be nice if someone could test something on real hardware for me.
I want to know if the Mode 7 mosaic part in the "2.68 MHz Demo" looks
like bsnes or snes9x on real hardware.
The link with the ROM and two pics is here:
http://rapidshare.de/files/38648841/2.68-test.zip.html |
Impressive special effects, first time I've actually seen Mode 7 + mosaic used together.
Tested it on my 1/1/1 Super Famicom. It looks like bsnes. Worth noting,
on hardware the game screws up and crashes during the 3D cube part.
It's clearly a very poorly programmed demo. But then, you can't expect
much from those days, can you?
|
Thanks. Now that I know I can fix it in ZSNES.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 23, 2008 4:00 am Post subject: |
|
Sure, let me know if I can lend a hand.
The main part you want to look at is the mosaic countdowns. When you
write to a mosaic register, it starts the countdown to the next pixel
right there. It is not evenly divided against the entire screen itself.
Eg if you had a mosaic of 3 at the start of the frame, and you were to
write 3 again after line 2 -- Snes9X appears to be working as in the
left column, which while intuitive, is wrong. The right side is the
correct behavior.
AAA -> AAA
AAA -> AAA -- write mosaic register during hblank here (mosaic countdown reset to 3)
AAA -> AAA -- mosaic countdown = 2
BBB -> AAA -- mosaic countdown = 1
BBB -> BBB -- mosaic countdown = 0 -> 3
BBB -> BBB -- mosaic countdown = 2
I may be one off in the above, it's been too long to be sure. It's in
my bppu_mmio.cpp and bppu.cpp source files, though.
Also, take a look at Sim Earth. I believe that requires the same
behavior to display the map correctly. And if I recall, older versions
of ZSNES got this wrong. Not sure if it was ever fixed.
Last edited by byuu on Sat Feb 23, 2008 2:43 pm; edited 1 time in total |
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sat Feb 23, 2008 4:22 am Post subject: |
|
Thank
you very much for that info. I might fix that bug in Sim Earth somehow.
The mode 7 mosaic bug was that the mode 7 parameters where taken from
the "adjusted mosaic line" (i.e. y-(y%mosaicsize) I think) instead of
the current line. I'm not sure if that's right with everything but none
of the other games that actually use mode 7 mosaic somewhere are
changed by it.
PS: I tried to implement RTO in ZSNES so if you have some test roms it would be nice if you could send them my way. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 23, 2008 8:53 am Post subject: |
|
mudlord wrote: |
 |
Oh, the somber reminder that bsnes used to have a pretty icon in its window. 
Couple of things:
1. I noticed "modifification" is still there in the latest WIP.
2. Is vertical centering coming back into the windows GUI fields, or is this pretty much impossible now?
3. I'm wondering, is it possible to put a checkmark enable/disable on a
menu item which has an arrow (branches to a selection)?
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Feb 23, 2008 10:01 am Post subject: |
|
I
strongly would not recommend it, since a menu entry can not be clicked
and thereby the inutive way of toggling the arrow would be lost. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Feb 23, 2008 10:49 am Post subject: |
|
Heh.
After all these years of using Windows, I assumed that merely selecting
an arrowed item spawned the new window automatically. But it only does
this when you're using the mouse. It changes the behavior when you're
using the keyboard and wants you to press enter or right arrow to
perform the action, which doesn't make a lot of sense to me. If they
just spawned the new window automatically on selection like the mouse,
enter (and left-click) could be freed up to exclusively perform actual
actions like enable/disable on items, including arrowed ones.
So then, of course, instead of this:
Speed Regulation > [X] Enable | [] Slowest, [] Slow, [X] Normal, [] Fast, [] Fastest
You'd have this:
[X] Speed Regulation > [] Slowest, [] Slow, [X] Normal, [] Fast, [] Fastest
And instead of this:
Video Frameskip > [X] 0 | [] 1, [] 2, [] 3, [] 4, [] 5, [] 6, [] 7, [] 8, [] 9
You'd have:
[] Video Frameskip > [X] 1, [] 2, [] 3, [] 4, [] 5, [] 6, [] 7, [] 8, [] 9
I guess it would get confusing, though, to have checkable arrowed items
and uncheckable arrowed items, when Windows shows nothingness for
"unchecked" rather than a faint box from which to infer the capability.
I will say that perhaps frameskip's menu could be changed to match the
behavior of the speed regulation menu, that is "0" changing to "Enable"
(but unchecked by default). And hey, that way, byuu, you can have a
divider and it will make sense too!  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Feb 23, 2008 2:54 pm Post subject: |
|
Quote: |
PS: I tried to implement RTO in ZSNES so if you have some test roms it would be nice if you could send them my way. |
Honestly? That's one of the few things I don't really have any tests on :/
I'll double check later today to make sure.
What I used to add RTO was the SNES electronics test (obviously), and
Super Conflict's title screen. RTO is really annoying, you have to go
back and forth against these lists you need to build. And then account
for special cases like the X=256 bug.
Quote: |
The
mode 7 mosaic bug was that the mode 7 parameters where taken from the
"adjusted mosaic line" (i.e. y-(y%mosaicsize) I think) instead of the
current line. |
Ah yes, that would definitely not be good. It also really shouldn't be y%mosaicsize, which is what I was getting at with my last post, sorry if I'm just repeating myself here.
> 1. I noticed "modifification" is still there in the latest WIP.
Yeah, so lazy :/
Planning to fix that when I purge all the redundant entries. Have to rewrite how that code works to do it.
> 2. Is vertical centering coming back into the windows GUI fields, or is this pretty much impossible now?
Well, the textboxes won't let me center the text vertically. Labels are
easy enough. I'm still planning a way to "auto-detect" the best sizes,
given a control and current font, and then I'll get all the controls
looking nice.
> 3. I'm wondering, is it possible to put a checkmark enable/disable
on a menu item which has an arrow (branches to a selection)?
Maybe, but not to my knowledge.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Feb 23, 2008 10:59 pm Post subject: |
|
Quote: |
Well, I guess if you don't mind writing up a small example I could work on porting the current code over. |
To that end, here's a small example on how to capture the screen into a offscreen render target, and post process it.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Feb 24, 2008 8:59 am Post subject: |
|
Jonas Quinn wrote: |
PS: I tried to implement RTO in ZSNES so if you have some test roms it
would be nice if you could send them my way. |
The main tests I've used for RTO is the Megaman games. I think all of
them have part of the power bar disappear for a moment as a boss
explodes.
Also the first boss in MMX2 should have his fist go through the power bars if you get it to punch.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
Jonas Quinn ZSNES Developer

Joined: 29 Jul 2004
Posts: 116
Location: Germany
|
Posted: Sun Feb 24, 2008 8:08 pm Post subject: |
|
Nach wrote: |
Jonas Quinn wrote: |
PS: I tried to implement RTO in ZSNES so if you have some test roms it
would be nice if you could send them my way. |
The main tests I've used for RTO is the Megaman games. I think all of
them have part of the power bar disappear for a moment as a boss
explodes.
Also the first boss in MMX2 should have his fist go through the power bars if you get it to punch.
|
I'm
mostly done with implementing it. The only thing that's still needed is
to get the sprite priority right again. I can't really test the SNES
Test Program RTO test. The test is never finishing in SVN because the
timing is broken.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 26, 2008 4:07 am Post subject: |
|
New WIP up.
I was a little too busy to work on bsnes this weekend, but I got some work done tonight.
First, I moved the field / interlace / overscan status functions over to the PPU, where they belong.
This led me to kill a lot of extra CPU timing variables, such as
vblstart and vnmi_trigger_pos. The latter I had to kill because I can
no longer call sCPU::update_interrupts() when the PPU changes the
overscan setting. You may be wondering about interlace toggle -- well,
it can only take effect at the start of a new frame anyway, and the
timing for scanline 0 is the same regardless of interlace setting, so
it doesn't really need to call update_interrupts() anyway.
With this moved back to the PPU, I was able to clean up the PPU
functions a bit, too. Before, I had PPU::scanline_is_hires() and
CPU::interlace(), and then a function called PPU::get_scanline_info()
that would read the previous two functions and copy them into a struct.
What an odd construct, I'm sure it was more complex in the past. Cruft,
basically. I just killed that, renamed scanline_is_hires to just hires,
and now SNES::Video just queries ppu.hires() and ppu.interlace()
directly. Much nicer.
I didn't lose any speed here, either. I made up the difference by force
inlining the PPU states in the bPPU header file.
I ran all my IRQ and NMI tests again, I didn't see any regressions.
Testing of games that use interlace and overscan, as well as of
IRQ-sensitive games, would be appreciated.
While cleaning up the PPU, I had some code that would flush the PPU
buffer when disabling interlace. I removed that as it looked rather
ugly. Don't really have a clean way of handling that. Not like any game
out there toggles interlace every frame anyway.
I went through and killed a bunch of config file options that don't
actually do anything anymore, such as audio.frequency and
video.use_vram.
Lastly, I rewrote the advanced panel code finally. All options that can
be controlled through the UI have been removed. The list is ~80%
smaller now. I also improved a lot of the descriptions. I think it
looks a lot better now, at least. I went with a blacklist, rather than
whitelist. I figure, better to have extra options if I forget to filter
them out; than to have missing options if I forget to add them.
Before the next release, I'd like to add back default_height() stuff to
get the textboxes and buttons smaller on the Windows port. Maybe revert
that back to Tahoma 8. I should also add descriptions to the last few
advanced panel options missing them. Other than that -- just regression
testing, I suppose. I can't break up the PPU enslavement any more
without adversely affecting performance at this point.
Hmm, would also be nice to rename vcounter / hclock / hcounter to
vcounter / hcounter / hdot. Afraid of missing a reference somewhere and
screwing up the timing, heh.
I tried to get the icon working again on the Windows port. But using
LoadImage or CreateIconIndirect doesn't handle the alpha level of
bsnes' icon properly. It ends up as a 1-bit transparency that looks
terrible in the titlebar, as well as the taskbar. The only way I can
get it to look good is with LoadIcon and grabbing the icon from the
resource file. The reason I don't want to do this is because it's not
at all portable to GTK+. Sigh. Tested this on Win2k, by the way. Win2k
isn't supposed to support the alpha channel in icons at all, but it
sure the hell does on the taskbar.
I even tried GetIconInfo() on the icon returned from LoadIcon(), and
then CreateIconIndirect on that, and it crushes the translucency again.
So it isn't a problem with the format of hbmMask and hbmColor in my
ICONINFO struct. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Feb 26, 2008 5:08 am Post subject: |
|
byuu wrote: |
You may be wondering about interlace toggle |
For some reason, that made me laugh a lot. Probably because the
interlace toggle never even crossed my mind. Ever. In my life.
So thank you for that 
_________________
I bring the trouble.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Feb 26, 2008 6:40 am Post subject: |
|
Did
some regression testing on a whole bunch of games, tested interlace on
RPM Racing but couldn't remember many of the other games that used it.
I used to know a game that had a half-interlace, half-normal scene...
maybe I'm thinking of hi-res.
Where are the resident Windows coders to help out with the icon issue? Does everyone use linux now?
Quote: |
Hmm,
would also be nice to rename vcounter / hclock / hcounter to vcounter /
hcounter / hdot. Afraid of missing a reference somewhere and screwing
up the timing, heh. |
Well, I'm sure the issue would be found pretty fast if one appeared. We
have a good list of timing sensitive games.
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Feb 26, 2008 12:36 pm Post subject: |
|
I wonder if this happens on hardware. I don't remember this happening ever on the console, and I can't test it right now.

Every time the enemy shoots the second spike thing, a black horizontal
line appers which covers Mega Man partially. This glitch is always
reproduciable. I also tested this with another enemy of the same type,
and it worked too. It's easiest to see in Crush Crawfish's stage (the
picture).
EDIT: The image was a bit bigger than I expected. Sorry. |
|
paulguy Regular
Joined: 02 Jul 2005
Posts: 280
|
Posted: Tue Feb 26, 2008 1:20 pm Post subject: |
|
It
probably does, i've seen it happen before in other games. But I'm more
curious what crazy computer you have to get the window that big. More
than 2x makes it just crawl horribly for me no matter what and im on
core 2 duo 2.66Mhz, geforce 8500 GT. |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Feb 26, 2008 1:38 pm Post subject: |
|
Nothing
fancy actually. I'm using 3x scale without any filters. OpenGL for
video and OpenAL for sound. My processor is AMD Athlon 64 X2 5200+
which has much worse performance than the latest Intel processors, if
I've understood correctly. In case of Mega Man X3, I barely get 60 fps.
It runs smoothly enough, I just beat the game the other day. |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Tue Feb 26, 2008 2:10 pm Post subject: |
|
I believe that does happen on hardware.
Megaman 7 does that too when you fight Protoman, and when I reported it here and got told that.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Feb 26, 2008 2:31 pm Post subject: |
|
FitzRoy wrote: |
Where are the resident Windows coders to help out with the icon issue? Does everyone use linux now? |
No, we use Windows. We just use methods that work on Windows and just don't care about Linux. 
Anyway, I believe I CAN still offer some insight.
The issue is of course using icons that have a full alpha channel. It's
simply not well supported in the old Win32 API as byuu has found out.
You can of course use the resource file. That works, but as said, it's
not easily portable. The Win32 GDI functions were written a long time
ago (Most modern windows only programmers would be using .NET anyway),
long before alpha channels were popular. Almost all of the Win32 GDI
functions will ignore the alpha channel or crunch it to 1bit as a
result. Alpha channel support was added with the AlphaBlend() function
in Windows 98, part of the MSIMG32.DLL if my information is correct.
My best guess is you'll need to create a blank 32-bit HDC bitmap object
to work with and render it with AlphaBlend().
http://msdn2.microsoft.com/en-us/library/ms532324.aspx
I've also seen evidence you can somehow manipulate the alpha bytes of
the bitmap object yourself, but I couldn't tell you exactly how.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 26, 2008 2:32 pm Post subject: |
|
Quote: |
Did
some regression testing on a whole bunch of games, tested interlace on
RPM Racing but couldn't remember many of the other games that used it.
I used to know a game that had a half-interlace, half-normal scene...
maybe I'm thinking of hi-res. |
You can't have half-interlace, that setting only takes effect at the
start of a new frame. If you toggle interlace in the middle of the
frame on, and back off before it ends, you'll see the interlaced mode
addressing take effect (you'll be missing every other line), but every
even line will always appear black, so you're really just cutting the
vertical resolution in half. Same for OAM interlace. Hires can be
toggled mid-frame, and this makes supporting filters a royal PITA. I
really hope hires can't be toggled mid-scanline, or I'll be forced to
always render at 512 pixels for a dot-based PPU renderer.
So, no bugs? Awesome :D
Thanks a lot for testing. Next release is likely to be very important, so it's much appreciated.
Quote: |
Every time the enemy shoots the second spike thing, a black horizontal line appers which covers Mega Man partially. |
The SNES has sprite limitations just like the NES and Genesis. When
they're reached, sprites stop getting rendered. The bar isn't black,
you're just seeing the background.
Now, the reason I can't say for sure this is correct behavior (the game
is definitely using too many sprites on one line, so some
are going to be clipped no matter what), is because MMX2/3 use the Cx4
chip that has its own OAM sorting routines that affect priorities. If
it were any other game, I'd be 99% confident. The range/tile over in
the SNES test, Super Conflict and FF6 all work exactly as on hardware.
The first two are extremely picky.
Either way, I know nothing about the Cx4, so even if it were a bug, there wouldn't be much I could do.
Quote: |
It
probably does, i've seen it happen before in other games. But I'm more
curious what crazy computer you have to get the window that big. More
than 2x makes it just crawl horribly for me no matter what and im on
core 2 duo 2.66Mhz, geforce 8500 GT. |
Ah, lots of Linux users, I see. Go to settings -> advanced, change
system.video to either "xv", or if you're using nVidia's binary
drivers, "opengl", and restart. The default SDL renderer is
ridiculously slow at scaling, no matter what kind of computer you have.
Quote: |
My best guess is you'll need to create a blank 32-bit HDC bitmap object to work with and render it with AlphaBlend(). |
I'm familiar with that function, I used to insert it into my Win95 OSR2 system for DirectDraw alpha blending :)
But, drawing the icon directly onto the titlebar and taskbar?! Holy crap that sounds difficult!
|
|
paulguy Regular
Joined: 02 Jul 2005
Posts: 280
|
Posted: Tue Feb 26, 2008 7:41 pm Post subject: |
|
Thanks byuu. It works great now fullscreen on the 42". |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Feb 26, 2008 9:37 pm Post subject: |
|
Quote: |
And byuu, in case you missed it: |
Oops, sorry! Thanks for posting! I'll cache it on my hard disk later
tonight. It probably won't make it in v029, sadly. But I'll definitely
try and get it in there ASAP :D
Quote: |
Thanks byuu. It works great now fullscreen on the 42". |
Neat! I'm working on a better way of selecting those drivers now, so
hopefully this won't be so obscure in future versions.
Planning to make three separate tabs, one for each driver type. Then I
can add checkboxes and selection things for stuff like pixel shaders,
vsync, etc that is driver specific.
---
EDIT: Ah, the good old days ...
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 3:23 am Post subject: |
|
Quote: |
Oops,
sorry! Thanks for posting! I'll cache it on my hard disk later tonight.
It probably won't make it in v029, sadly. But I'll definitely try and
get it in there ASAP  |
No probs dude, glad I can help
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 27, 2008 5:55 am Post subject: |
|
New WIP.
vcounter / hclock / hcounter renamed to vcounter / hcounter / hdot. I
think it's more clear this way. Fixed up the v/hc stuff to v/h in
bppu_mmio.cpp to match.
Instead of building each driver for ruby independently, I grouped them
all together into one object file. I know everyone else hates that, but
too bad -- that's the way I program. No sense building ~10 object files
when one will do just as well. I was able to cut out ~20 lines from the
Makefile as a result of this.
I added CB_SETITEMHEIGHT magic to actually set combo box to requested
height. Neat. Of course, bsnes doesn't currently use any combo boxes in
the UI, but it'll be nice when it does, at least.
Lastly, I added something new to the Windows port (that used to be there a long time ago), just for FitzRoy :P
I'll go over that in more detail tomorrow. For now, consider it a surprise. |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Feb 27, 2008 7:46 am Post subject: |
|
The debugger?
j/k
Also, I asked this earlier, but did not get a response, so I'll ask
again. Would it be possible to integrate blargg's audio code into bsnes
v017? That would give people with slower PCs the ability to play
FF3(And many, many other games, but that's the one that comes to mind
right now) with the right frigging audio. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Feb 27, 2008 2:14 pm Post subject: |
|
Version
.17 doesn't use Blargg's audio core? Huh! I always though it did. That
version works fine (60fps) and the music in FF3 sounds great to me..
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 2:16 pm Post subject: |
|
Correct me if I'm wrong, but I believe it used anomie's emulation code... |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Feb 27, 2008 3:11 pm Post subject: |
|
Oh..I couldn't tell the difference in 0.17's and 0.28's sound emulation; either way, they both sounded extremely accurate.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 27, 2008 3:36 pm Post subject: |
|
blargg's
core is a relatively recent development. Before, bsnes used anomie's
core, which is as accurate as it can get for the time steps it divides
the emulation up into. The differences between anomie's and blargg's
cores are very hard to detect (mainly I believe some clicks in DKC
songs were cited as not being present in anomie's core where they are
on the real SNES) for normal humans, but internally blargg's core is a
great deal closer to how the SNES does things, to the point where even
the order in which instructions are executed is confirmed as far as
possible. (that is, as far as current tests allow)
Last edited by Verdauga Greeneyes on Wed Feb 27, 2008 3:40 pm; edited 1 time in total |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Feb 27, 2008 3:40 pm Post subject: |
|
So, will Zsnes use Blargg's SPC700 core?
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Feb 27, 2008 3:41 pm Post subject: |
|
I think Zsnes 2.0 uses it, but don't quote me on that  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 27, 2008 4:18 pm Post subject: |
|
Alright,
the surprise was that I've re-added the window icon to bsnes. It only
works as expected on XP or later (Vista included, obviously.) This is
because Win2k and prior do not support the alpha channel. With a
one-bit transparency mask, there isn't much I can do. Trying to
downsample the alpha to 1-bit does not work at all -- it looks horrible.
It still looks fairly decent on Win2k and prior, though. Certainly better than no icon at all.

EDIT: Ah, I see now. It's not that Win2k is automatically applying
alpha blending only when loading icons from the executable, it's that
Win2k is choosing the 256-color icon versions inside FitzRoy's .ico
file. Well, that certainly sucks. I don't intend to provide two
separate APIs just for Win2k's sake. Will everyone be okay with Win2k
and prior looking as it does above in future versions?
I just need to find a way to get the icon into GTK+ now. It's stored as:
Code: |
static uint8_t icon32[32 * 32 * 4]; |
Yeah, 22kb header file. Meh, not much can be done about it. C++ has no
standardized #include for pure binary files. Only takes ~10ms to
compile, but perhaps I'll apply LZSS compression to the array to shrink
it down some in the future.
Quote: |
Would it be possible to integrate blargg's audio code into bsnes v017? |
If anyone wants to do this, I'll give them my permission. I don't have time to backport code, myself ...
I think a better idea would be to re-implement the range IRQ tester
into v028. Then the only thing missing will be PGO -- maybe someone
with VS2k8 can try PGO again?
Quote: |
Oh..I couldn't tell the difference in 0.17's and 0.28's sound emulation; either way, they both sounded extremely accurate. |
Accuracy has diminishing returns, hence why it's so hard to identify,
and the main reason it's not very popular aside from the posters in
this thread ;)
anomie's core was the best of the best for 32KHz clock rate. blargg's
core is 32x more precise (it's actually 2.048MHz, but the S-SMP is
limited to 1.024MHz, so the precision is the same either way.) And yet
despite this, the only severe bug it fixed that we know of is in Toy
Story.
But behind the scenes, it improved a lot. Koushien 2's echo buffer
issue was fixed properly, rather than hackishly. KON/KOFF are keyed at
the exact right times now, etc etc etc. But it really makes the most
difference between two samples, which is way too short for humans to
audibly hear.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Feb 27, 2008 5:55 pm Post subject: |
|
Awesome,
thank you. I don't really care about 2k any (most people use XP,
right?), but do you think it would help if the less than stellar
versions of the icons were removed from the .ico file? Would that force
2k to default to the one it should? Who needs the 256 color version
anyway, it's a POS even as a fallback. I think you asked me for all
those versions to be included way back when because back then you
didn't see the harm in having a fallback. Now, however, we unexpectedly
see them being favored by some OS deficiency... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 27, 2008 6:29 pm Post subject: |
|
For the GTK+ window icon, looks like I'll need to:
- Create GdkPixmap with gdk_pixmap_new()
- Swap icon data from ARGB to BGRA format for GTK+'s stupidity
- Use gdk_draw_rgb_32_image() to render icon data into GdkPixmap
- Create GtkImage widget from gtk_image_new_from_pixmap()
- Bind GtkImage to window with gtk_window_set_icon()
Fun. Now watch one of those not support alpha transparency or something.
Also, in retrospect, I think using base64 encode on the icon file would
be best. That should get the header file much smaller. That can of
course be LZSS compressed too, but that's probably approaching overkill.
Quote: |
do
you think it would help if the less than stellar versions of the icons
were removed from the .ico file? Would that force 2k to default to the
one it should? |
I think that'd be a bad idea. WinXP and above will use the higher color
versions anyway. But if the 256-color versions do not exist, then the
EXE icon for bsnes on Win2k and below will show the black box around
it, because it will ignore the alpha layer entirely. Right now, at
least the EXE icon has the 1-bit transparent version from the icon
file. Worse yet, WinXP and above in 256-color mode will probably gain
the black border without the 256-color icons present.
The only thing I want to avoid is needing two Window::set_icon()
functions -- one for WinXP and Linux, and one for Win2k and below. I'd
rather just ignore alpha blending on Win2k and below and have one
unified RGB32 function.
Now, one thing that sounded kind of cool is that Vista supports 256x256
icons. But I think that'd just be absolute overkill and needlessly
increase the EXE size of bsnes.
---
Hmm, one more concern. Obviously, I store my image data in ARGB8888.
And this image data is endian swapped, so in raw binary, it's { B8, G8,
R8, A8, ... };
So, I believe this rules out being able to store icons in uint32_t[] {
... }. This is really annoying. That probably makes my Canvas control's
uint32_t unsafe for big endian systems, too.
I wonder if it'd be better to detect endian and perform the swapping
myself, or if it'd be better to force using uint8_t* to write out image
data so that it's always endian safe.
Last edited by byuu on Wed Feb 27, 2008 6:33 pm; edited 1 time in total
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Feb 27, 2008 6:31 pm Post subject: |
|
Care
to post a 256x256 icon here for us to use if we'd like? I could use it
for my dock, and then it wouldn't need to be packaged with the emulator
or anything. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 8:10 pm Post subject: |
|
Quote: |
Then the only thing missing will be PGO -- maybe someone with VS2k8 can try PGO again? |
I have VS2008.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 8:53 pm Post subject: |
|
And it looks like its no go..
I tried to first do a PGO compile, but the whole thing runs at around 2-4 FPS... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 27, 2008 9:06 pm Post subject: |
|
Quote: |
I tried to first do a PGO compile, but the whole thing runs at around 2-4 FPS... |
Yeah, you have to PGINSTRUMENT it, then run a few games. I know, it's
really tedious when they run at 2-4fps. Just run CT, get it to the
title screen when the text stops wavering, then exit. It generates a
bunch of profile files. Make sure to move those back into src/, and
then run the compilation again with PGOPTIMIZE. If it gives you a fatal
compiler error, we have the same problem. Otherwise, the optimized
build will run ~20-40% faster.
If VBA-M doesn't use much x86 asm, you'll get the same speedups there :)
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 9:07 pm Post subject: |
|
Quote: |
Yeah,
you have to PGINSTRUMENT it, then run a few games. I know, it's really
tedious when they run at 2-4fps. Just run CT, get it to the title
screen when the text stops wavering, then exit. It generates a bunch of
profile files. Make sure to move those back into src/, and then run the
compilation again with PGOPTIMIZE. If it gives you a fatal compiler
error, we have the same problem. Otherwise, the optimized build will
run ~20-40% faster.
If VBA-M doesn't use much x86 asm, you'll get the same speedups there  |
Thanks! I never really used profile guided optimizations before, but I'll do a recompile and see how it works.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Feb 27, 2008 9:27 pm Post subject: |
|
Quote: |
If it gives you a fatal compiler error, we have the same problem. |
Yep, gives a fatal internal compiler error...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Feb 27, 2008 9:43 pm Post subject: |
|
Quote: |
Yep, gives a fatal internal compiler error... |
Ah, good old Microsoft quality. Thanks, you saved me a 4GB download.
I'll stick with my ~10% faster, ~10,000% smaller, MinGW 4 :)
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Feb 27, 2008 11:18 pm Post subject: |
|
I'm
getting some new stuff hopefully in a week or so, using it I may be
able to provide PGO Windows binaries, if desired, let me know.
_________________
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: Thu Feb 28, 2008 12:21 am Post subject: |
|
Okay,
I got home to try the new WIP and it seems that there is something
slightly off about the icon as rendered in the window. It definitely
looks different (worse) in the window than it did when it was rendered
in .018. Not that big of a deal, and I hate to complain after bugging
you about it for so long, but is this unavoidable?
 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 28, 2008 12:37 am Post subject: |
|
It's
because I store the icon internally at 32x32. v018 is picking the
32-bit 16x16 icon, whereas v028 is resizing the 32x32 icon. I could use
the 16x16 icon, but then alt+tab's icon would look a lot blurrier.
Aside from storing the icon in every conceivable size (eg all eight in
the ico file), it's not going to be possible to get it to look as nice,
sadly.
Really sorry, portability is a major pain in the ass. The downside is
the Windows port looks a bit uglier here and there. But the upside is
that it should work on your PS3, and look and feel exactly like the
Windows port, with 100% feature parity :)
The alternative is Snes9X' approach, where the Linux port has no
official UI, the Windows port was broken for a long time due to
internal changes, and the OS X port is absolutely phenomenal, yet
completely different from every other port. And that's saying nothing
of all the extra work involved. I just don't have that kind of time. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 28, 2008 1:02 am Post subject: |
|
/grabs linux by the throat and strangles
/remembers PS3 and removes grip momentarily
/goes for the throat again but can't continue
/breaks down into forced laughter that quickly turns into sobbing
"Linuuuuuuuux!" |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 28, 2008 5:44 am Post subject: |
|
Well,
nothing seems to have broken from renaming that stuff. I do have a new
feature request, though. In pseudo-hires mode, you know how bsnes
blends the adjacent pixels together (which is apparently how hardware
does it)? Could we have an option to disable this effect in advanced
settings so that the mode can appear "crisp" as it does in other
emulators? Maybe it's not something you can implement, but I thought
I'd ask. The fuzziness of the text in games that use this is getting to
my eyes, accurate or not. |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Thu Feb 28, 2008 6:09 am Post subject: |
|
byuu wrote: |
Aside from storing the icon in every conceivable size (eg all eight in
the ico file), it's not going to be possible to get it to look as nice,
sadly. |
This is a problem? If it's a question of storing them all in an ico,
why not simply say "Here's a nicer ico set seperately, DL if you want'.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Feb 28, 2008 8:42 am Post subject: |
|
We are going to need to celebrate a happy 200 pages worth of discussion soon.
And I honestly think that the best thing for the icons is to ship a properly sized version for each of it's uses.
It's a few KiBi more tops. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Thu Feb 28, 2008 9:51 am Post subject: |
|
byuu wrote: |
It's
because I store the icon internally at 32x32. v018 is picking the
32-bit 16x16 icon, whereas v028 is resizing the 32x32 icon. I could use
the 16x16 icon, but then alt+tab's icon would look a lot blurrier.
Aside from storing the icon in every conceivable size (eg all eight in
the ico file), it's not going to be possible to get it to look as nice,
sadly. |
If you don't mind bsnes depending on an external file, you could ship a
Windows .ico file with all the sizes and colour-depths built-in. I
assume Windows has a way of loading a full icon structure from a .ico
file, and on Linux you can use gtk_window_set_icon_from_file() - Linux
doesn't read in all the different colour depths, but it reads the
highest-quality version it can find and resamples it, which is about
the best you can do with just one source image file.
Quote: |
The
alternative is Snes9X' approach, where the Linux port has no official
UI, the Windows port was broken for a long time due to internal
changes, and the OS X port is absolutely phenomenal, yet completely
different from every other port. And that's saying nothing of all the
extra work involved. I just don't have that kind of time. |
On the other hand, the SNES9x team can devote their time to emulation
issues instead of trying to master multiple GUI toolkit APIs
simultaneously. And then when somebody comes along who cares about a
particular platform enough to support it, they can create their own phenomenal port without much hassle.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 28, 2008 12:30 pm Post subject: |
|
Thristian wrote: |
On
the other hand, the SNES9x team can devote their time to emulation
issues instead of trying to master multiple GUI toolkit APIs
simultaneously. And then when somebody comes along who cares about a
particular platform enough to support it, they can create their own phenomenal port without much hassle. |
Snes9x actually has emulation issues to focus on though, and has had
cross-platform GUI problems for ages, where bsnes has only relatively
recently gained full cross-platform support at all, and well-structured
at that.
Don't take this the wrong way, I'm a longtime fan of Snes9x ... If
it still sounds nasty, well, right now I honestly don't care. I
shouldn't bother you guys with this, but a very dear friend of mine
died suddenly late last Tuesday from an unknown cause.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Feb 28, 2008 1:23 pm Post subject: |
|
byuu wrote: |
Quote: |
Yep, gives a fatal internal compiler error... |
Ah, good old Microsoft quality. Thanks, you saved me a 4GB download.
I'll stick with my ~10% faster, ~10,000% smaller, MinGW 4
|
I was curious if it would still fail in VS 2008. I guess we got our
answer. That's disappointing. However, perhaps they don't know about
this bug. Do either of you know exactly what crashes? I was thinking,
you know, one of you could report it to them. Can't expect them to fix
things they don't know about, right? Why am I giving Microsoft the
benefit of the doubt? Well, hardly anyone defends them, so why not? 
_________________
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.
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Thu Feb 28, 2008 2:04 pm Post subject: |
|
Yeah, one issue they can fix is maybe implement blargg's spc core; then again, I thought Snes9x was dead.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
sweener2001 Inmate

Joined: 06 Dec 2004
Posts: 1571
Location: WA
|
Posted: Thu Feb 28, 2008 5:16 pm Post subject: |
|
Nightcrawler wrote: |
byuu wrote: |
Quote: |
Yep, gives a fatal internal compiler error... |
Ah, good old Microsoft quality. Thanks, you saved me a 4GB download.
I'll stick with my ~10% faster, ~10,000% smaller, MinGW 4
|
I was curious if it would still fail in VS 2008. I guess we got our
answer. That's disappointing. However, perhaps they don't know about
this bug. Do either of you know exactly what crashes? I was thinking,
you know, one of you could report it to them. Can't expect them to fix
things they don't know about, right? Why am I giving Microsoft the
benefit of the doubt? Well, hardly anyone defends them, so why not?
|
i've heard that their compiler is really strict. but that doesn't appear to apply to this case.
i just remember that it wouldn't compile my professor's code, but gcc
would. just because of some extra semi-colons and minor formatting
issues.
_________________
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 28, 2008 6:39 pm Post subject: |
|
New WIP.
Adds a base64 encoder, which zaps the ~21kb icon down to ~5kb. With the
extra space, I used the 48x48 icon instead. It should look a tiny bit
better, but it still obviously can't beat a non-resampled icon. Also
added Linux icon support. That turned out to be a royal pain, as the
gdk-pixbuf library documentation was separate from the GDK
documentation. Tried finding visuals, to make colormaps, to get GCs, to
create pixmaps to blit onto as drawables, to create pixbufs with, to
attach to the window. Turns out, gdk-pixbuf has a function to turn raw
data into a pixbuf.
Quote: |
Could
we have an option to disable this effect in advanced settings so that
the mode can appear "crisp" as it does in other emulators? |
This blurring is required for pseudo-hires to operate properly, eg in Jurassic Park.
Nonetheless, if you guys really want the option to disable the
blurring, I can add it. Just keep in mind that we're opening up a can
of worms. People will then want an option to disable the sprite drawing
limit, to add hi-res mode7, etc etc. Harder to draw a line in the sand
when you aren't all or nothing.
Quote: |
This
is a problem? If it's a question of storing them all in an ico, why not
simply say "Here's a nicer ico set seperately, DL if you want'. |
I'm not going to put resources external to the executable, unless I
absolutely have to. Thus, I have to put all of these icons inside the
source code, and I have to modify the GUI API wrapper to handle this.
Quote: |
I was thinking, you know, one of you could report it to them. |
"Hi, uh, Microsoft? Yeah, your compiler is erroring out when I compile my emulator with it and PGO enabled."
"Sure, as that's a $12,000 Team Suite Edition feature, if I could just get your serial number, that'd be great."
"Oh, uh ... I think I left that at home. I'll call you right back with it, okay?"
"Oh, no problem. If I can just get your full name, I'll pull you up in our system ... ... hello? Sir?"
::dial tone::
And for the official legal record, I only used the free trial and express editions :)
Quote: |
Yeah, one issue they can fix is maybe implement blargg's spc core; then again, I thought Snes9x was dead. |
Not dead, but on severe life support. Same for SNEeSe and Super Sleuth.
anomie, TRAC and Overload have minimal presence anymore. A damn shame.
The SNES scene is in worse shape than most people realize at the
moment. NES emulators have had dot-based PPU renderers for years now.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 28, 2008 8:25 pm Post subject: |
|
Hmm,
finally tried to implement that gaussian function in a filter,
unfortunately the word on performance is.. not good. Even if I just
call it once with the lowest acceptable precision (around 500 passes)
each frame takes about 4.5 seconds on my GF6600.. I think maybe the
continued fraction method isn't optimal in this case (dunno why, I was
given to believe it was always optimal), so I'll try a simpler method,
but don't expect miracles. Mind you a newer gen card would probably be
much faster, but even in the standard 1.0 spread case I'll have to call
it 49 times, so.. This doesn't mean we're out of options, but unless I
can do about a thousand times better than this I'll have to store the
distribution in an array, which makes it a lot less versatile for
scaling. But bsnes only includes integer scaling anyway, so maybe it's
not a problem (I'm not sure what happens when aspect ratios get
involved however) |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Feb 28, 2008 8:45 pm Post subject: |
|
If we are going for filters, I have a personal favorite, the super eagle series.
Pretty good looking and practically no slowdown, even at computers that suck. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Feb 28, 2008 9:04 pm Post subject: |
|
Hey byuu,
Do you think you might could be able to work out an "auto-frame skip"
feature? This is where with vsync on, the frames stay at 60fps and only
skip a frame when needed to keep in timing with the audio. I'm
wondering if this might fix the popping audio issue by just having the
frame jump one only when it falls behind by a frame from the audio. |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Thu Feb 28, 2008 10:28 pm Post subject: |
|
Quote: |
Yeah, one issue they can fix is maybe implement blargg's spc core; then again, I thought Snes9x was dead. |
Snes9x's core is based on OpenSPC's core, which in turn is based on
TRAC's code...So its quite accurate already. Though, since blargg's APU
core is super efficient, it wouldnt hurt to plug it in.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Feb 28, 2008 10:48 pm Post subject: |
|
Okay, second try, OGl2 GLSL style:
Code: |
float Gaussian2(in vec2 a, in float m, in float s, in float n)
{ const float iSqrt2Pi = .398942280401432677939946/s, iSq2s = -.5/(s*s);
float d = 0., e = 3./(3.*n-1.); a -= m;
for(float i = a.x+e/3.; i < a.y; i += e) d += iSqrt2Pi*exp(i*i*iSq2s);
return (a.y-a.x)*d/n;
} |
Doing say 5 passes of this seems to yield a passable average (with
maybe workable framerates) although I dunno how accurate it will be for
the values farther from the centre. It'll probably be a bit too high
for them. The first version is much better for high numbers of passes,
but unfortunately it really falls apart for low numbers.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Thu Feb 28, 2008 11:02 pm Post subject: |
|
mudlord wrote: |
Quote: |
Yeah, one issue they can fix is maybe implement blargg's spc core; then again, I thought Snes9x was dead. |
Snes9x's core is based on OpenSPC's core, which in turn is based on
TRAC's code...So its quite accurate already. Though, since blargg's APU
core is super efficient, it wouldnt hurt to plug it in.
|
I couldn't get FF3(and some other games whose names i do not recall
right now. >.<) to sound right on the latest version of it. Am i
the only one?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 28, 2008 11:37 pm Post subject: |
|
byuu wrote: |
Nonetheless, if you guys really want the option to disable the
blurring, I can add it. Just keep in mind that we're opening up a can
of worms. People will then want an option to disable the sprite drawing
limit, to add hi-res mode7, etc etc. Harder to draw a line in the sand
when you aren't all or nothing. |
Seeing as how the same reasoning gets used for graphics filters...
maybe at some point in the future you can add those three things in the
advanced menu. special."" or something.
Quote: |
I'm not going to put resources external to the executable, unless I absolutely have to. |
Well, considering that the resized version is unable to look as good in
the window (and the new WIP doesn't fare any better), I wonder if this
then justifies the "having to." The icon is more overt and ugly than an
extra file in the bsnes folder. I don't even look at the folder past
installation. But I use the program almost every day. I understand
wanting to keep external files to a minimum, but I don't see one little
file being more important than a nice icon.
As a final brainstorm, the original file is 256x256 when I process it
through my icon making program. If that program can resize that image
down to 16x16 with the desired result, could you perform a similar
resize by having that version of the icon, or is the method being used
to resize unavoidably different than the one in the icon program?
Last edited by FitzRoy on Thu Feb 28, 2008 11:42 pm; edited 2 times in total
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Thu Feb 28, 2008 11:37 pm Post subject: |
|
I.S.T. wrote: |
mudlord wrote: |
Quote: |
Yeah, one issue they can fix is maybe implement blargg's spc core; then again, I thought Snes9x was dead. |
Snes9x's core is based on OpenSPC's core, which in turn is based on
TRAC's code...So its quite accurate already. Though, since blargg's APU
core is super efficient, it wouldnt hurt to plug it in.
|
I couldn't get FF3(and some other games whose names i do not recall
right now. >.<) to sound right on the latest version of it. Am i
the only one?
|
No you're not. Snes9x's sound, though improved in 1.51, is still quite
inaccurate in some games, while BSNES seems to be perfect in the games
I've tried out. What really got my attention is Mega Man X - some of
its sound effects are way off in Snes9x, at least on my computer (Intel
iMac).
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Fri Feb 29, 2008 12:06 am Post subject: |
|
Heck,
on the Snes9x core, I get a buncha of popping and clicks. Not only that
but SPUAsync doesn't work. Yeah, can't wait till the new Zsnes comes
out..
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 29, 2008 12:36 am Post subject: |
|
Quote: |
If we are going for filters, I have a personal favorite, the super eagle series. |
As far as I know, 2xSaI and Super Eagle are GPL'ed. I neither can nor would use them because of that.
Quote: |
Do you think you might could be able to work out an "auto-frame skip" feature? |
Never tried, and I'm not sure how to do that at the moment. Given that
I can't even get audio clear with vsync enabled, I somehow doubt I'll
have much luck with auto frame skipping :/
Quote: |
Snes9x's core is based on OpenSPC's core, which in turn is based on TRAC's code...So its quite accurate already. |
anomie's core is more accurate, and blargg's is obviously king.
Quote: |
(and the new WIP doesn't fare any better) |
Really? Wow, I thought it looked quite nice on Vista.
Quote: |
I understand wanting to keep external files to a minimum, but I don't see one little file being more important than a nice icon. |
Where would I put this file (note that Linux binaries are located in
/usr/local/bin -- icons cannot go here), and what would I do if it were
deleted? I would have to special case Windows and Linux to locate the
icon, and then I'd have to have a fallback anyway.
Quote: |
As
a final brainstorm, the original file is 256x256 when I process it
through my icon making program. If that program can resize that image
down to 16x16 with the desired result, could you perform a similar
resize by having that version of the icon, or is the method being used
to resize unavoidably different than the one in the icon program? |
Hard to say. I'd certainly be willing to try. That icon alone would add
~175-350kb onto the bsnes file size. For an icon, that's pretty insane.
Can you experiment on your side? Save multiple versions of the icon,
and then shrink each one down to 16x16, and stick it on a window. See
what the smallest size is that looks really good, and that is also at
least 48x48.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 29, 2008 6:09 am Post subject: |
|
byuu wrote: |
Quote: |
(and the new WIP doesn't fare any better) |
Really? Wow, I thought it looked quite nice on Vista.
|
Well, this is what is looks like on XP. Bottom left.

byuu wrote: |
Where would I put this file (note that Linux binaries are located in
/usr/local/bin -- icons cannot go here), and what would I do if it were
deleted? I would have to special case Windows and Linux to locate the
icon, and then I'd have to have a fallback anyway. |
God, I don't know. Every time I think of some simple solution, I'm told
of some other goofball linux rule. Where did the cart db file go when
you had one of those? And why would you have to special case an icon if
it were deleted? Wouldn't it just do what it did before and show
nothing?
Quote: |
Can you experiment on your side? Save multiple versions of the icon,
and then shrink each one down to 16x16, and stick it on a window. See
what the smallest size is that looks really good, and that is also at
least 48x48. |
So far, I've resampled the image down to 16x16 in photoshop with
several different methods, and "bilinear" and "bicubic" were very
similar to the .018 result while "nearest neighbor" looked similar to
the new ugly result. Even 48x48 being resampled this way gave good
results. This is what I'm guessing the problem is. Whatever is
responsible for resampling the icon down to 16, it's not doing a very
good job. What is doing it, the OS or bsnes? Can you change the method?
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Feb 29, 2008 10:03 am Post subject: |
|
byuu wrote: |
Quote: |
I understand wanting to keep external files to a minimum, but I don't see one little file being more important than a nice icon. |
Where would I put this file (note that Linux binaries are located in
/usr/local/bin -- icons cannot go here), and what would I do if it were
deleted? I would have to special case Windows and Linux to locate the
icon, and then I'd have to have a fallback anyway.
|
Seems like this should be something pretty easily abstracted into your
GUI toolkit wrapper. When you call the Windows implementation of
setIcon(filename), it would look in the executable directory, and when
you call the GTK implementation, it could try the executable directory
first (so you'd get your icon if you were just running a
freshly-installed bsnes without installing it) and if that didn't work,
$prefix/share/pixmaps where $prefix is whatever the installation prefix
was set to at compile time (/usr/local by default, but a .rpm or .deb
build process should be allowed to override it to /usr).
There are other places you could stick it in Linux, depending on how
much you want to research and adhere to various potential file-system
hierarchy standards, but /usr/share/pixmaps is not wrong.
As for what happens if the icon is deleted, well then bsnes windows
would just fall back on the OS default icon. That's what it's there
for, after all.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Fri Feb 29, 2008 11:05 am Post subject: |
|
this makes the resource forks of the mac file systems look so much saner...
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Fri Feb 29, 2008 5:32 pm Post subject: |
|
FitzRoy wrote: |
byuu wrote: |
Quote: |
(and the new WIP doesn't fare any better) |
Really? Wow, I thought it looked quite nice on Vista.
|
Well, this is what is looks like on XP. Bottom left.

byuu wrote: |
Where would I put this file (note that Linux binaries are located in
/usr/local/bin -- icons cannot go here), and what would I do if it were
deleted? I would have to special case Windows and Linux to locate the
icon, and then I'd have to have a fallback anyway. |
God, I don't know. Every time I think of some simple solution, I'm told
of some other goofball linux rule. Where did the cart db file go when
you had one of those? And why would you have to special case an icon if
it were deleted? Wouldn't it just do what it did before and show
nothing?
Quote: |
Can you experiment on your side? Save multiple versions of the icon,
and then shrink each one down to 16x16, and stick it on a window. See
what the smallest size is that looks really good, and that is also at
least 48x48. |
So far, I've resampled the image down to 16x16 in photoshop with
several different methods, and "bilinear" and "bicubic" were very
similar to the .018 result while "nearest neighbor" looked similar to
the new ugly result. Even 48x48 being resampled this way gave good
results. This is what I'm guessing the problem is. Whatever is
responsible for resampling the icon down to 16, it's not doing a very
good job. What is doing it, the OS or bsnes? Can you change the method?
|
Looks like you are in best performace mode in xp, how does the icon look in the best appearance mode.
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Fri Feb 29, 2008 7:02 pm Post subject: |
|
funkyass wrote: |
this makes the resource forks of the mac file systems look so much saner... |
Are resource forks still being used in OSX applications? I thought they were obsolete...
|
|
ArtVandelae New Member
Joined: 03 Jan 2008
Posts: 4
|
Posted: Fri Feb 29, 2008 8:42 pm Post subject: |
|
dvdmth wrote: |
No you're not. Snes9x's sound, though improved in 1.51, is still quite
inaccurate in some games, while BSNES seems to be perfect in the games
I've tried out. What really got my attention is Mega Man X - some of
its sound effects are way off in Snes9x, at least on my computer (Intel
iMac). |
Snes9x
actually has very good sound provided that the "Generate samples in
sync with the CPU" option is turned on. Super Mario RPG, for example,
sounds almost perfect with the option turned on but terrible with it
off. The same is probably true of the MMX games.
|
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Fri Feb 29, 2008 9:24 pm Post subject: |
|
byuu wrote: |
Quote: |
I was thinking, you know, one of you could report it to them. |
"Hi, uh, Microsoft? Yeah, your compiler is erroring out when I compile my emulator with it and PGO enabled."
"Sure, as that's a $12,000 Team Suite Edition feature, if I could just get your serial number, that'd be great."
"Oh, uh ... I think I left that at home. I'll call you right back with it, okay?"
"Oh, no problem. If I can just get your full name, I'll pull you up in our system ... ... hello? Sir?"
::dial tone::
And for the official legal record, I only used the free trial and express editions 
|
I reported a bug that I found in VC2005 when compiling the MAME source and it got some attention...
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=133141
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 29, 2008 10:12 pm Post subject: |
|
Hmm,
krick, since you've already signed up there ... would you mind relaying
this bug to them for us? I'm rather apathetic, and I really, really
don't want to reinstall Visual C++ again to get the exact error
message. That thing takes an eternity to load, eats a ton of hard disk
space, and does me no good.
And mudlord, would you mind re-posting the error you received, if it's not too much trouble? |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Feb 29, 2008 10:23 pm Post subject: |
|
Happy 200 pages  |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 29, 2008 11:41 pm Post subject: |
|
bobthebuilder wrote: |
Looks like you are in best performace mode in xp, how does the icon look in the best appearance mode. |
Didn't make any difference.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 01, 2008 12:05 am Post subject: |
|
Alright,
I've added GetVersionEx() to test for the Windows version. This allows
me to blend the icon against a black background for Win2k. I think the
result looks a lot better than even the native 256-color icon did from
v018 and such -- black border be damned.

The top left was the old icon, the top right was the new icon, and the
bottom left is the new icon with Win2k-alpha applied. And before you
ask, setting alpha = 0 to transparent doesn't work at all. It looks
horrendous as there's lots of low alpha pixels all around. We need the
full alpha range to make the icon look really good.
Also, this is the lower resolution 32x32 icon. The 48x48 icon looks a bit better, especially the yellow circle.
Lastly, it's possible that a bilinear / bicubic resize will help with
image quality a bit. We can always give it a try.
Thank you very much for the error log, mudlord. krick or someone else,
would you mind posting that info over to the VC forums? |
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Sat Mar 01, 2008 1:19 am Post subject: |
|
dvdmth wrote: |
funkyass wrote: |
this makes the resource forks of the mac file systems look so much saner... |
Are resource forks still being used in OSX applications? I thought they were obsolete...
|
Packages are the new resource forks,
even supported in Mac OS Classic. They're just a normal folder with a
flag set to make them look like a file to the user. Hide all your
program's files in one and you and your users win.
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Sat Mar 01, 2008 3:39 am Post subject: |
|
mudlord wrote: |
http://vba-m.ngemu.com/personalfiles/error.txt |
I haven't been following along that closely. Can you summarize the
exact situation that results in the error so I can try to relay it to
them?
Is there a copy of the offending Visual Studio project and source
somewhere that I can link to? They'll need it to be able to reproduce
the error, I'm sure.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Mar 01, 2008 5:46 am Post subject: |
|
Okay:
The exact situation was creating a PGO optimized build. I managed to
instrument the build just fine for optimization, but when the PGC's get
merged into the PGD, the error occurs. The only "project file" used per
se, is BSNES's makefile. Unfortunately, I use the latest BSNES WIP code
to try to make the PGO optimized build, but I am 100% sure that the
0.28 code gives exactly the same result. I could even try to make a PGO
optimized build with that so that it can be reproduced. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 01, 2008 7:30 am Post subject: |
|
Okay, I worked on something a bit different this evening.
The 48x48 32-bit icon was exactly 9,270 bytes in BMP format.
To insert this into the binary, the typical method is to store the data in hex format, eg:
Code: |
uint8_t data[] = { 0x00, 0x00, 0x00, 0x00, ... }; |
This takes six bytes per binary byte to encode. A 55,620 byte source
file just for a tiny icon was unacceptable to me. You could use
"\x00\x00" to drop this down to four bytes per binary byte, but that's
still awful.
As I've unfortunately mentioned previously, thus ruining part of the
fun here, I've used base64 encoding, which allows me to insert binary
data where the source file is ~1.333x larger. In this case, the
previous icon was encoded to 13,283 bytes.
Meh, that still wasn't good enough. I want to store more icons and
graphics in the future, so I need this to be as small as possible. So
this evening, I got the data down to a mere 2,646 bytes :)
Here is the 48x48 icon, encoded with my new technique:
Code: |
static char lookup_table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
static char enc_icon48[] = {
"_gAB8AHwAfAB8AHwAfAB8P8B8AHwAfAB8AHwAfAB8AHw_wHwAfAB8AHwAfAB8AHw"
"AfD_AfAB8AHwAfAB8AHwAfAB8P8B8AHwAfAB8AHwAfAB8AHw_wHwAfAB8AHwAfAB"
"8AHwAfD_AfAB8AHwAfAB8AHwAfAB8P8B8AHwAfAB8AHwAfAB8AHw_wHwAfAB8AHw"
"AfAB8AHwAfD_AfAB8AHwAfAB8AHwAfABgFD_oRYPBAA1BABWVQQAWwQAQQQAGgQA"
"Av8u8AHwAfAB8AHwAfAB8AHwVbSAAQQALQQAsAQA9FUEAP8EwPsEAM4EAFP9BAAE"
"QvAB8AHwAfAB8AHwqwHwvOAEBACFBAD5uPDVBOD-BAC9BAAUSvAB8L8B8AHwAfAB"
"8AHwvGADBACuoqjwBPAEwNsEABZS8H8B8AHwAfAB8AHwAfDAIHuvnPAE8ATwBCDH"
"BAAFVvC_AfAB8AHwAfAB8LzAIAQA3vaY8ATwBPAEYGZa8AHw3wHwAfAB8AHwwMCX"
"kPAE8OsE8ASg3wQABl7wAfAB8K8B8AHwAfC8QAYEAOeQ8PcE8ATw0OMvYvAB8AHw"
"AfDXAfAB8MBAHAQA_JDwBPALBPAE4GRi8AAAPz9U_wEEAA0EAB0EAB59BAAPBABE"
"9gHwAfDA8BVVBABxBAB3BAChUET9p5zwBPAE8BaGuMALBACqbAQAzgQA9AQA-wQA"
"qvwEAPYEANYEAHoEAL4SlvAB8AHwAfAEhjIEAF68FEKo8ATwBFCBcIFHtQQA5AQA"
"_wTwBKDuBAB-XDQQjvAB8AHwAfAQhmhHzPYE8ARgpQ5YwEBor2xBsPAE8AQQ_QQA"
"hFTyfwHwAfAB8MjA-Bgg8wTQowAQ-_-rACMuNrz_SrzwBPAE8MQgZ4LwbwHwAfAB"
"8BDJkbTwBMCnAAfLfV-0ETU6fP_mnPAE8ATwBCAkExxfhvAB8AHwAfDEgBEEAO0D"
"uPAEQKQO_f-tAIBCLDX_cTw-mPA3BPAE8ASAlYLwAUDNAKoBBAAFBAAUBAAiBAB-"
"JQhAEBAYEETz5PYE8KgABZxKRfIENju8_9eQ8ATwBPAEoOq0wKoDBAAsBACGBADM"
"BADq7AQA_AQA_gSAEBAYEOrKBACDBAAqBABMo6gAFkC88AQgrvgCBy83wP8VPj7_"
"-JDwBPCvBPAIs7yAuBDEoED_BPBXBPAEQDAQwAQAKcCAHRf8S7hQMBl_uFk4O_--"
"KYzwBPAE8ATwvEBhBABe95zwBPAE8ARg9gQAW1HAIJ8XFKwA8uhIkFUEAB-sxhkE"
"AH0EAJL1BADDBADznPAE8ATwwADozQBIBAD5kPAE8ATwAQTg-ADQACn_nrwYAshD"
"pPUB8NAQEQQA3nGgRqjwBPDAkOKI8ATw9wTwBPAEIM8UAwHwAfAB8HvIEPQYzKjw"
"BPAEQDQS0t-I8ATwBPAE8ARAeprwAfB3AfDEYLAZyqzwBPAEAMX1cAAvBADxiPAE"
"8ATwBOB68AQAGZbwAfAB8MSgHK0EAPGw8ASg_gQAScBDvj4URZTwBPAE8AQw6gQA"
"RjwN9mwJ__8IBAAT_QQAGgRADBAUEET2xHDgE6u48ARwuwQAA0CFGQQAup0EAPOc"
"8ATwBIDyBACgmADLABe0gAkEAKpFBACaBADSBADsBABa-QQA-wRADBDtBADTVQQA"
"nQQASAQACsDAGK0EAPW48AQg3QQAFfbwVcggEQQAUwQAoRxD6b0EAPRcJNwwEBAY"
"EJ8EAKpRBAAQuIAGBABuBAC66AQA_wTwBPAEgOoEAEpzBAAHSxBBOFgryF-88BQg"
"LHEB8NDQBgQAC10EAA0IQLj-vDAQBADFr5jwBPAE8ASgywQAFMRA6pm4gOcEAHAE"
"AOAgAfCvAfAB8AHwvEACBAC1jPAvBPAE8ATwBAC_VBBDMtT_TrAAeQQAPAQAYKLf"
"AfAB8AHwAfDAQBnYQozw1wTwBPAE8P0EAB1p8AHwrwHwAfAB8MDgGAQA-ojw7wTw"
"BPAE8AQA_AQA3PsB8N8B8AHwAfDA8CQVsYjwBPD3BPAE8AQAulz1AfAB8AHw1wHw"
"AfDEQA0EAL2M8ATw9wTwBKAEFBFh8AHwAfAB8FcB8AHwxIAFBABoBADjXQQA_pzw"
"BPAEgOUEAG3_hCUB8AHwAfAB8AHwAfAB8KvIEFwXPQQAkgQAz8BGXveYQwQQDBAU"
"ENAEAJT9BABB9CYB8AHwAfAB8AHwrwHwAfAB8NBwBAQADtgl_QQwDxRA5PIB8AHw"
"AfAB8P8B8AHwAfAB8AHwAfAB8AHw_wHwAfAB8AHwAfAB8AHwAfD_AfAB8AHwAfAB"
"8AHwAfAB8P8B8AHwAfAB8AHwAfAB8AHw_wHwAfAB8AHwAfAB8AHwAfD_AfAB8AHw"
"AfAB8AHwAfAB8P8B8AHwAfAB8AHwAfAB8AHwfwHwAfAB8AHwAfAB8AGA"
}; |
With the exception of Nach, who I already mentioned the idea to ... I'm curious if anyone here can figure out exactly what format the above data is stored in now. Obviously, it's compressed. And obviously, it's base64. But can anyone tell how it's compressed? :)
One cookie to determine the compression type, and five cookies if you manage to decompress it yourself :)
This actually seems like a rather useful tool to have for many
purposes, so I've added it to my general purpose library, nall.
I'd like to re-add the controller graphic next. But my version really
isn't all that great. Anyone want to take a shot at creating a really
nice graphic to be used?
Requirements: it must be lossless, it must be as clean as possible, it
must use the Super Famicom controller and its colors (not the bland
SNES controller), and the graphic must be public domain. Resolution
doesn't matter, as long as it looks good around the ~480x240 range with
scaling.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 01, 2008 9:21 am Post subject: |
|
Having
done a quick google, the Super Famicom controller looks the same as the
PAL one, right? Also: 95% smaller than the original, eh? That's quite
impressive. I suppose it helps that there aren't any compression
artifacts complicating the picture, but that's 9% higher than the best
result found here. Not that I really know anything about compression though, so no cookies for me  |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Mar 01, 2008 9:45 am Post subject: |
|
Verdauga Greeneyes wrote: |
the Super Famicom controller looks the same as the PAL one, right? |
Right.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Mar 01, 2008 10:16 am Post subject: |
|
Yay!
Based on byuu's lookup table, I managed to make a perfectly working base64 encoder/decoder:

Which means, as soon as I get it to output decoded files...your algorithm will soon be cracked byuu.  |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Mar 01, 2008 10:51 am Post subject: |
|
byuu wrote: |
I'd
like to re-add the controller graphic next. But my version really isn't
all that great. Anyone want to take a shot at creating a really nice
graphic to be used?
Requirements: it must be
lossless, it must be as clean as possible, it must use the Super
Famicom controller and its colors (not the bland SNES controller), and
the graphic must be public domain. Resolution doesn't matter, as long
as it looks good around the ~480x240 range with scaling. |
I don't have time to bust out Inkscape right now, but if someone is
looking for a nice, high-res image of a PAL SNES controller to trace, Wikimedia has you covered.
That image is under the GFDL rather than being public-domain, but I
think (IANAL) that wouldn't be an issue - if two people can take photos
of the Eiffel Tower and have independent copyrights, I'm sure two
people can draw a standard SNES controller and have independent
copyrights.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Sat Mar 01, 2008 12:13 pm Post subject: |
|
Quote: |
f
two people can take photos of the Eiffel Tower and have independent
copyrights, I'm sure two people can draw a standard SNES controller and
have independent copyrights. |
I have to agree 
Anyway byuu...I got my base64 decoder/encoder to now output file
streams. Works brilliantly in the test case...lets see what it does to
your datastream....
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 01, 2008 3:50 pm Post subject: |
|
byuu wrote: |
Lastly, it's possible that a bilinear / bicubic resize will help with
image quality a bit. We can always give it a try.
|
Please do. Using the 48 actually looks worse as the shapes lose their
rounded form even more from the originals. The yellow only appears to
look better to you because, (a) the defects are now evenly distributed
on both sides of the oval, (b) you're putting it against another light
color background in Vista's windows, so the defects are merely being
hidden, just like if you were to put a yellow background behind it, you
wouldn't see any edges at all, much less the defects. I remember taking
heat on this when I had the audacity to go dark on yellow and white on
everything else when putting text on my buttons when we had controller
debates a long time ago. Here's a guide I found to illustrate this
behavior:
http://www.sapdesignguild.org/resources/diagram_guidelines/textcolor_bk.html
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sat Mar 01, 2008 7:17 pm Post subject: |
|
byuu wrote: |
I'd
like to re-add the controller graphic next. But my version really isn't
all that great. Anyone want to take a shot at creating a really nice
graphic to be used?
Requirements: it must be
lossless, it must be as clean as possible, it must use the Super
Famicom controller and its colors (not the bland SNES controller), and
the graphic must be public domain. Resolution doesn't matter, as long
as it looks good around the ~480x240 range with scaling. |
How about this one: http://commons.wikimedia.org/wiki/Image:SNES-controller.png?
Perhaps not the prettiest one, but it seems to be public domain if you read the license and it's already done.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Mar 01, 2008 8:33 pm Post subject: |
|
Perhaps
someone could take that one and photshop/gimp it to be more
aesthetically pleasing? I would think having the basic shape to start
with would be the most important thing. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 01, 2008 8:34 pm Post subject: |
|
Here's my version of that one completely re-drawn and vectored...


 |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sat Mar 01, 2008 8:37 pm Post subject: |
|
Why you need to have the icon in bmp format?
I know nothing about how icons are stored in executables, but I think
256 or 65536 colors should be enough for the shades of those four main
colors..
Or is there a problem with resampling an icon which doesn't have enough color depth originally? |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Mar 01, 2008 8:43 pm Post subject: |
|
King Of Chaos wrote: |
Here's my version of that one completely re-drawn and vectored... |
Those look very crisp! Would it be at all possible to give them some
shading, perhaps? It just looks weird because the buttons are shaded
(more reflective, I guess) for some reason, and nothing else is.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 01, 2008 8:48 pm Post subject: |
|
Ok, made a new set...



Thoughts?
@ DancemasterGlenn, I'll see what I can do.  |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Sat Mar 01, 2008 8:54 pm Post subject: |
|
I like both of them, a lot |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 01, 2008 9:01 pm Post subject: |
|
Ok, here's the 2nd version transparent...



Thoughts? These are considered a proof-of-concept of some ideas. 
EDIT: New ones above to fix a little issue... |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 01, 2008 9:52 pm Post subject: |
|
Well, I was looking for the Super Famicom colors to match the program icon. The US SNES controllers are ugly x.x
Other than that, they look really good! I wonder if you could raise the
number of colors? Don't see any reason to have so much color aliasing. |
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 01, 2008 10:00 pm Post subject: |
|
Yea,
I'll see if I can edit the colors of the US SNES controller to the
Super Famicom colors, and remove the Super Nintendo logo. 
Yea, I can easily raise them. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 01, 2008 10:18 pm Post subject: |
|
Actually,
PAL SNES controllers have the Super Nintendo logo as well, with the
logo (like in FitzRoy's icon, but in black and white) to the left of
it. 'course, I dunno about the Japanese controller, but it does fill
some otherwise blank space nicely  |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 01, 2008 10:25 pm Post subject: |
|
Yep, just noticed that. The entire controller is darker than the US counterpart. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 01, 2008 11:00 pm Post subject: |
|
The
directional pad is way larger than the real thing, and you may also
want to check where the original came from. If it's a filtered
photograph, you're probably okay.
I should also
add that we need to remember the application for this, which I'm
assuming is to be a reference for people to know where the original
controllers buttons are located, and they're not clearly labeled right
now. I realize you may think L and R are obvious, but... to a
non-English speaking person, left and right means nothing. Once again,
I also took shit for this when I made my controller, so... take my
advice with a grain of salt because it may not be what the masses want. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 02, 2008 12:21 am Post subject: |
|
By
the way, would it help at all if I scanned my PAL controller in at high
res? It's a bit dusty right now and I'd have to carefully centre the
buttons, which can move around a bit (as I imagine they can for all
controllers) but it's fairly unscathed. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Mar 02, 2008 7:22 am Post subject: |
|
byuu wrote: |
Well, I was looking for the Super Famicom colors to match the program icon. The US SNES controllers are ugly x.x
|
I like the look of the US controller.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Mar 02, 2008 8:36 am Post subject: |
|
doesn't the famicon just have two shades of purple while the SNES has Red, Green, Blue, Yellow?
if yes, i prefer the SNES by far.
_________________
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. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Mar 02, 2008 9:39 am Post subject: |
|
franpa wrote: |
doesn't the famicon just have two shades of purple while the SNES has Red, Green, Blue, Yellow?
if yes, i prefer the SNES by far. |
No.
The US SNES has 2 shades of purple, with X and Y being concave and A and B convex.
The PAL SNES uses the Super FamiCom controllers, which have 4 convex colored buttons.
The FamiCom controllers are rectangles with 2 concave fire buttons and a spiffy metal inlay.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Mar 02, 2008 10:03 am Post subject: |
|
ah cool, then im all for either the famicon/pal controller >.>
_________________
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. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Mar 02, 2008 10:33 am Post subject: |
|
While those vector images sure is nice, I doubt that they are useful for being icons. Icons is very small bitmaps,
the one thing that vector art does poorly. For those that did not get
it the last page, an icon can have more than one image, different
images for different sizes/color deeps.
Grab a
dedicated icon editor (I use an application called Microangelo) that is
made for the job. That way, you can use exactly all features in the
icon format. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Mar 02, 2008 10:45 am Post subject: |
|
I don't think they are supposed to be icons, but rather a small image to illustrate what button goes where.
I actually do think a vector is great for this purpose, especially if
bsnes could scale the image to grow with larger resolutions.
To make the image more usefull the controller should be tilted slightly
so the back L and R buttons are more visable.
What would be even better is when you select a field to edit the button
the selected buttong should be shaded so you actually see a relation
between the button field and the actual graphic of the button |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 02, 2008 4:10 pm Post subject: |
|
I have an icon program actually, and I could create an icon if needed. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 02, 2008 7:18 pm Post subject: |
|
So I got bored and scanned in my SNES controller anyway 
Here's a resized version:
And just because the amount of detail is cool, here's the original  |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 02, 2008 7:21 pm Post subject: |
|
GEEZ. 74MB is kinda... huge. 
If you don't mind, I want to base the next design concept on the controller you scanned.  |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 02, 2008 7:22 pm Post subject: |
|
King Of Chaos wrote: |
GEEZ. 74MB is kinda... huge.  |
Hehe, I know. Mind you jpg would do a much better job of compressing
it, but I thought what the hell. Glad to hear you want to use it,
that's what I scanned it for after all!
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 02, 2008 7:27 pm Post subject: |
|
I've already found a good reference photo. Still gonna be a day or two before I finish mine.
Last edited by FitzRoy on Sat Mar 08, 2008 9:56 am; edited 1 time in total |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 02, 2008 7:57 pm Post subject: |
|
Ok, new concepts...



They're not perfect, but I like the progress of these proof-of-concepts.  |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Mar 02, 2008 8:16 pm Post subject: |
|
Amazing. Really. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Mar 02, 2008 8:19 pm Post subject: |
|
King Of Chaos wrote: |
Ok, new concepts...
They're not perfect, but I like the progress of these proof-of-concepts.  |
Woah those are pretty damn accurate (except for the horrible banding)
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Mar 02, 2008 8:22 pm Post subject: |
|
I actually think that makes it look really classy... |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 02, 2008 8:46 pm Post subject: |
|
Here's without the glassy vector look...



Thoughts?  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Mar 02, 2008 8:53 pm Post subject: |
|
Could you center the directional pad and the select/start buttons?
Verdauga Greeneyes:
What is the resolution of that thing? 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sun Mar 02, 2008 9:00 pm Post subject: |
|
If
you're going to use that version, you'll need to use a healing tool on
the buttons... one or two of them are a bit scratched up.
EDIT: I actually do like that better. But yes, the scratched buttons are the only issue on this end. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 02, 2008 9:14 pm Post subject: |
|
creaothceann wrote: |
Verdauga Greeneyes:
What is the resolution of that thing?  |
Heh, I scanned it at 1600 DPI.
King of Chaos: I didn't realise you were going to use it literally o.o
All the tiny flecks of dust and paper towel (which sticks to the start
and select buttons like crazy) not to mention the dirt in the grooves
no doubt complicates the conversion to a vector graphic..
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Mar 02, 2008 9:19 pm Post subject: |
|
I see a tiny cut in the down right corner, even if a real controller had such a cut, it looks bad. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 02, 2008 9:34 pm Post subject: |
|
henke37 wrote: |
I see a tiny cut in the down right corner, even if a real controller had such a cut, it looks bad. |
I think that's there to make sure that plate can only go in the right
way up.. it's definitely not a cut, mind you, the lighter grey shell
extends into that area.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 03, 2008 9:24 am Post subject: |
|
New
WIP. Adds Win2k alpha adjust (against black background), some minor
code cleanups, LZSS compression / decompression for storing graphics,
and puts the program icon onto the about screen, which has been shrunk
down a bit again.
So, too late mudlord, the answer was LZSS :P
I wanted to just go with RLE for simplicity, but the compression ratio
sucked. LZSS is the same number of lines of code, yet is three times
more efficient with the icon. And something like a controller with much
more repetition will probably make an even bigger difference. Meh, the
code's easy enough. I wrote it for clarity over speed, and
decompression is always lightning fast with LZ anyway.
Good job decoding the base64 portion, though. Very useful routine for a library.
As for the controller graphics, wow ... I'm really torn. I really love
how clean FitzRoy's version looks, yet at the same time King of Chaos'
version is so lifelike it's scary. I dislike the "flaws", though. The
scratches on the X, the dot on the bottom right, and the off-center
buttons ... since it's digital anyway, I'd prefer it to appear perfect,
if at all possible.
But it's a tough call. I'll have to hold a vote or something :)
Thanks a million for helping with the controller graphic, both of you! |
|
rayno Rookie

Joined: 15 Aug 2005
Posts: 14
|
Posted: Mon Mar 03, 2008 12:40 pm Post subject: |
|
Well, that little dot actually is in every official joypad :)
I guess they were using it as a guide to get the letters aligned perfectly in each pad
--
Well not exactly aligned, but rather guiding assemblers that they wouldn't put the dark gray plate upside down :D |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 03, 2008 4:02 pm Post subject: |
|
Hey
guys, spent some time cleaning up the SNES logo on the scan I made of
my controller. I used the original resolution version scan and took the
average colour over a large region to get the two basic colours for
this - it probably isn't 'perfect' as I don't have the vector graphics
description of the actual logo
But it's as close as I could get to the actual image on the controller.
Cleaning up the whole scan this way would obviously be a massive job,
so I'd have to be quite bored, but this bit came out quite nice I
think: (by the way I rotated the scan by one degree anti-clockwise
first so I wouldn't be working with an offset image) |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Mar 03, 2008 4:36 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Hey
guys, spent some time cleaning up the SNES logo on the scan I made of
my controller. I used the original resolution version scan and took the
average colour over a large region to get the two basic colours for
this - it probably isn't 'perfect' as I don't have the vector graphics
description of the actual logo
But it's as close as I could get to the actual image on the controller.
Cleaning up the whole scan this way would obviously be a massive job,
so I'd have to be quite bored, but this bit came out quite nice I
think: (by the way I rotated the scan by one degree anti-clockwise
first so I wouldn't be working with an offset image) |
woah nice, using this will surely lead to great vector of the controller!
If we color that and turn the background transparent we should have a very high quality vector of the bsnes logo!
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 03, 2008 4:37 pm Post subject: |
|
Ok
boys, I fixed as much as I could in these images (including the X
button and other "imperfections" I saw). 2 different sets, one with the
little dot on the bottom right of the buttons (like the real
controller) and one without...





 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 03, 2008 9:03 pm Post subject: |
|
Posting this here so I don't forget about it.
A ROM hacker recently got in touch with me, he managed to find
something that behaves differently in bsnes and hardware CPU revision 2
(works the same as CPU revision 1). I usually hate working with
hobbyist code. But whatever, it's been long enough since a real bug
report came in, so I looked into it anyway.
The specifics of what triggered the issue aren't important, but the reason is:
Looks like the game ends up transferring from WRAM to $2180. Obviously,
that's not allowed. You can't read and write from the same chip in the
same cycle, as DMA requires. What bsnes does is transfer the CPU MDR
("open bus"), and the screen fills with gibberish.
But the CPUr2 seems to work with this! As does Snes9X and Super Sleuth
... hmm. It looks as though CPUr2 is actually blocking the write from
occurring at all. Apparently it doesn't even update the $43x2 address.
I've been meaning to overhaul DMA for a while now. I suppose now's as
good of a time as any. I'll go through and verify what each CPU is
doing, and special case as needed. Need to verify what happens to
$2181-$2183 and $43x2-$43x4, as well. Note that I'm sticking with CPUr1
behavior for the default build of bsnes, but it'll be nice to document
the differences, at least. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Mar 04, 2008 2:42 am Post subject: |
|
byuu wrote: |
Posting this here so I don't forget about it.
A ROM hacker recently got in touch with me, he managed to find
something that behaves differently in bsnes and hardware CPU revision 2
(works the same as CPU revision 1). I usually hate working with
hobbyist code. But whatever, it's been long enough since a real bug
report came in, so I looked into it anyway.
The specifics of what triggered the issue aren't important, but the reason is:
Looks like the game ends up transferring from WRAM to $2180. Obviously,
that's not allowed. You can't read and write from the same chip in the
same cycle, as DMA requires. What bsnes does is transfer the CPU MDR
("open bus"), and the screen fills with gibberish.
But the CPUr2 seems to work with this! As does Snes9X and Super Sleuth
... hmm. It looks as though CPUr2 is actually blocking the write from
occurring at all. Apparently it doesn't even update the $43x2 address.
I've been meaning to overhaul DMA for a while now. I suppose now's as
good of a time as any. I'll go through and verify what each CPU is
doing, and special case as needed. Need to verify what happens to
$2181-$2183 and $43x2-$43x4, as well. Note that I'm sticking with CPUr1
behavior for the default build of bsnes, but it'll be nice to document
the differences, at least. |
Ooooh! You could code multiple behaviors, and offer a menu option to select a specific SNES revision!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 04, 2008 3:34 am Post subject: |
|
Alright, only took two hours to write up a thorough test. Looks like previous information out there was wrong.
I've decided that in the spirit of other emulators, I'll keep my
findings a secret and no tell anybody. That way I can have the best
emulator out there.
...
Nah, just kidding :)
Code: |
byuu.org/temp/test_dmavalid_v01.zip |
I even went out of my way and made the vcounter test very lenient. It
will allow up to four scanlines of timing flaws, so any opcode-based
emulator should be able to easily pass this test with a few minor
changes.
Blue screen indicates success, red screen indicates failure. I don't
believe any publicly released emulator will pass this test; but my
updated WIP will. Gets perfect vcounter / hcounter times to real
hardware, too :)
I don't feel like explaining it again. It's documented in plain English
inside the test_dmavalid.asm source file. And here's my updated
dma_transfer function:
Code: |
void sCPU::dma_transfer(bool direction, uint8 bbus, uint32 abus) {
if(direction == 0) {
//a->b transfer (to $21xx)
if(bbus == 0x80 && ((abus & 0x7e0000) == 0x7e0000 || (abus & 0x40e000) == 0x0000)) {
//illegal WRAM->WRAM transfer
//no read occurs; no write occurs
} else if((abus & 0x40ff00) == 0x2100 || (abus & 0x40ff80) == 0x4300
|| (abus & 0x40ffff) == 0x420b || (abus & 0x40ffff) == 0x420c) {
//illegal register access
bus.write(0x2100 | bbus, regs.mdr); //TODO: verify if MDR is written here
} else {
//valid transfer
bus.write(0x2100 | bbus, bus.read(abus));
}
} else {
//b->a transfer (from $21xx)
if(bbus == 0x80 && ((abus & 0x7e0000) == 0x7e0000 || (abus & 0x40e000) == 0x0000)) {
//illegal WRAM->WRAM transfer
//no read occurs; write does occur
//does not write MDR as expected
//TODO: 0x00 was observed on hardware; verify if other values are possible
bus.write(abus, 0x00);
} else if((abus & 0x40ff00) == 0x2100 || (abus & 0x40ff80) == 0x4300
|| (abus & 0x40ffff) == 0x420b || (abus & 0x40ffff) == 0x420c) {
//illegal register access
bus.write(abus, regs.mdr); //TODO: verify if MDR is written here
} else {
//valid transfer
bus.write(abus, bus.read(0x2100 | bbus));
}
}
//each byte *always* consumes 8 clocks, even if transfer is invalid and no read and/or write occurs
dma_add_clocks(8);
cycle_edge();
} |
bsnes was definitely way off before. $2181-3 was being incremented when
it shouldn't, it was erroneously allowing A->B bus WRAM->WRAM
transfers, and even worse, invalid B->A bus register transfers
weren't incrementing the clock. So this version should have improved
timing. WIP testers, please test any timing sensitive games you can
think of to look for regressions. Just two or three games each should
be enough testing, really. I suspect these invalid transfers are quite
rare. Many thanks in advance.
Behavior is identical on CPU 1/1/1 and CPU 2/1/3. Something else was
breaking the ROM hacked game I was testing. I now believe it was the
DMA<>HDMA conflict bug. That would explain why CPUr2 doesn't have
this problem.
One important thing to note that's not visible there -- $43x2 is always
updated, regardless of direction. It was previously thought to remain
unchanged. That's good news for me. My code was too abstracted, it
would've been annoying to have to pack code back together into one huge
routine.
Another thing is that writes from WRAM $2180->WRAM do not write the
MDR ("open bus") as we thought before, they seem to write some unknown
value. I went with 0x00 as that's what I saw on real hardware, but I
strongly suspect the value to change based on something ...
I'll get around to verifying if invalid register reads transfer open bus. I suspect they do.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 04, 2008 5:39 am Post subject: |
|
Tested
the usual suspects, nothing there, however... chanced upon a bug in
Chrono Trigger caused by this change. In a saveless game, when you get
to the "active/wait" choice right after the title menu, that text will
be missing now.
Last edited by FitzRoy on Sun Apr 20, 2008 7:29 am; edited 2 times in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 04, 2008 6:21 am Post subject: |
|
Okay, tested the other emulators. I love comparing them :)
Had to modify the STP instruction to an infinite branch, since some emulators are still dieing when hitting that opcode. Ugh.
Looks like I was wrong about the test being flexible enough. I only
give ~4 scanlines of leniency. But at least the first half of the test
($2180->WRAM) will run, even if timing is off by more than that.
Legend, line 1:
Code: |
;[3f 55] $2180 not incremented (would be [?? 3f] if so)
;[55] DMA write did not occur (would be [aa] if so, or at least not [55] if eg MDR was written)
;[00 14 7e] $43x2 incremented (would be [00 10 7e] if not)
;[00 00] $43x5 decremented (would be [00 04] if not)
;[ce 00] htime
;[36 00] vtime -- consumes DMA time (would be < [33 00] if not) |
Legend, line 2:
Code: |
;[3f 55] $2180 not incremented
;[00] DMA write did occur, but wrote unknown value (not MDR, which would be #$ea)
;[00 14 7e] $43x2 incremented
;[00 00] $43x5 decremented
;[ce 00] htime
;[36 00] vtime -- consumes DMA time |
Real hardware / bsnes:
3F 55 55 00147E 0000 CE00 3600
3F 55 00 00147E 0000 CE00 3600
Time = V:54, H:206
---
Snes9X passes the test, no changes needed. Neat! Looks like it's
writing MDR, but that it doesn't emulate the one cycle look-ahead
before DMA executes.
3F 55 55 00147E 0000 DB00 3600
3F 55 01 00147E 0000 DA00 3600
Time = V:54, H:219 (a fraction of a scanline too slow)
Snes9X needs to stop disabling video output upon STP instruction, though.
---
Super Sleuth comes dangerously close.
3F 55 55 00147E 0000 C400 3700
55 55 FF 00147E 0000 C200 3700
Time = V:55, H:196 (one scanline too slow)
Looking at the state inspector, it appears that DMA from WRAM to $2180
causes $2181 to increment one single time. It shouldn't increment at
all. Looks like a very minor glitch.
---
SNESGT fails. It's incrementing $2180 on each write. It also fully allows WRAM<>WRAM transfers.
AA3F AA00 147E 0000 D800 3600
Time = V:54, H:216 (a fraction of a scanline too slow)
---
SNEeSe fails, too. Same as SNESGT, incrementing $2180 and allowing
WRAM<>WRAM. And it crashes the entire emulator when hitting STP.
AA3F AA00 147E 0000 3C00 4900
Time = V:73, H:60 (~19 scanlines too slow)
---
ZSNES fails. Also incrementing $2180 and allowing WRAM<>WRAM.
AA3F AA00 147E 0000 2001 0700
Time = V:7, H:288 (~47 scanlines too fast)
---
I have to say, aside from the severe lack of quirky behavior supported
(most likely due to the language barrier), SNESGT is really starting to
look good! It even passes the Electronics Test now. Though SNESGT has a
cleaner GUI, Snes9X is still coming out on top for most tests I run.
Quote: |
Tested
the usual suspects, nothing there, however... chanced upon a bug in
Chrono Trigger caused by this change. In a saveless game, when you get
to the "active/wait" choice right after the title menu, that text will
be missing now. |
Good catch, thank you. I'll see what's up tomorrow morning. Probably something silly.
Quote: |
More work on the controller: |
Looks amazing! :O
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Mar 04, 2008 6:48 am Post subject: |
|
FitzRoy wrote: |
Tested
the usual suspects, nothing there, however... chanced upon a bug in
Chrono Trigger caused by this change. In a saveless game, when you get
to the "active/wait" choice right after the title menu, that text will
be missing now.
More work on the controller:
|
I... I want to have sex with that.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Mar 04, 2008 8:08 am Post subject: |
|
That
last image just feels like it's not t-bone shaped enough, the middle
top feels like it should be slightly thiner than the outer corners.
I think it is due to the lack of shoulder buttons. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 04, 2008 8:53 am Post subject: |
|
I miss the shadows a bit, but it's good enough. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Mar 04, 2008 8:58 am Post subject: |
|
FitzRoy wrote: |
Tested
the usual suspects, nothing there, however... chanced upon a bug in
Chrono Trigger caused by this change. In a saveless game, when you get
to the "active/wait" choice right after the title menu, that text will
be missing now.
More work on the controller:
 |
Interesting...
The shading on the buttons makes them look concave, given they're
bright at the bottom and shadowed at the top while the main controller
body is lit from the top and shadowed at the bottom.
Is that intentional, or are they lit upside-down on accident?
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Mar 04, 2008 10:49 am Post subject: |
|
the colours need to be duller, i've never ever seen such bright colours on a snes/super famicon pad. (@ FitzRoy)
_________________
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. |
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Tue Mar 04, 2008 2:00 pm Post subject: |
|
franpa wrote: |
the colours need to be duller, i've never ever seen such bright colours on a snes/super famicon pad. (@ FitzRoy) |
Perhaps he didn't intend for it to look photorealistic but rather just really good.
I agree that the buttons look concave.
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 04, 2008 4:57 pm Post subject: |
|
Wow,
that was a major flaw. I was only blocking B->A WRAM->WRAM
transfers before. Chrono Trigger attempts an A->B ROM->WRAM
transfer, where my emulator was falsely detecting it as WRAM->WRAM.
For those who care, here's why:
Code: |
if(bbus == 0x80 && ((abus & 0x7e0000) == 0x7e0000 || (abus & 0x40e000) == 0x0000)) |
I use magic masks as a speedup over range testing.
So, there are two locations for WRAM. The problem here is with the
first location test. WRAM can be between $7e0000 - $7fffff.
The typical solution is:
if(abus >= 0x7e0000 && abus <= 0x7fffff);
But this can be simplified with a mask. The idea is to mask the bits
that can be any value (0 or 1), and leave the bits that are always 0 or 1, eg fixed.
Examine the lowest and highest values:
Code: |
$7e0000 = 0111111 00000000000000000
$7fffff = 0111111 11111111111111111 |
So what is consistent is the top seven bits, or $fe0000. Masking
against that value should give us the consistent bits with the rest set
to zero, eg the lowest value.
Thus, we can reduce the above solution to:
if((abus & 0xfe0000) == 0x7e0000);
The problem with my code was that I was using:
if((abus & 0x7e0000) == 0x7e0000);
In other words, it was also detecting $fe0000 - $ffffff as WRAM.
Transfers such as this one were being blocked as a result:
Code: |
[DMA] channel:0 direction:a->b reverse:0 fixed:0 mode:0 b_addr:$2180 a_addr:$ff8e60 length:$0e00 ( 3584) |
Anyway, the second part of the test:
if((abus & 0x40e000) == 0x0000);
... is correct. It's the same as:
if(((abus >> 16) >= 0x00 && (abus >> 16) <=
0x3f && (abus & 0xffff) <= 0x1fff) || ((abus >>
16) >= 0x80 && (abus >> 16) <= 0xbf &&
(abus & 0xffff) <= 0x1fff));
Eg, true if addr is $[00-3f|80-bf]:[0000-1fff].
So, you see, these masking techniques greatly speed up code, but they can make it a lot harder to spot bugs in.
Very nice catch, FitzRoy. I'm much obliged.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Mar 04, 2008 11:23 pm Post subject: |
|
Wow
i don't check this board for 2 days and when i get back actually
emulation bugs have been found AND fixed,byuu you're so fast!! |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Mar 05, 2008 4:53 am Post subject: |
|
.. no one's going to say anything?
Really?
Where are the shoulder buttons?
EDIT: Just to be clear, I still am preferring King Of Chaos' version,
but I would concede in an instant that (with shoulder buttons) this is
an incredibly sleek interpretation. Nice work so far, FitzRoy. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Mar 05, 2008 5:17 am Post subject: |
|
henke already did, and so far i still prefer the controller that looks like a real snes controller.
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 05, 2008 5:19 am Post subject: |
|
Quote: |
Where are the shoulder buttons? |
Hey, I never said it was finished. Shoulders are last.
Quote: |
henke already did, and so far i still prefer the controller that looks like a real snes controller. |
Well, byuu wasn't too specific on what he wanted. I figured he wanted a
hand-drawn representation. Anyone can take a photograph and run it
through a filter for christ's sake. It's nearly impossible to draw
something exactly as it appears in real life, and if you could, why
would you do it since it is then indistinguishable from a photograph?
Do you find any artistic embellishments preferable?
Last edited by FitzRoy on Sun Apr 20, 2008 8:18 am; edited 2 times in total
|
|
bobthebuilder Hazed
Joined: 28 Jan 2006
Posts: 93
|
Posted: Wed Mar 05, 2008 6:59 am Post subject: |
|
both
look really good... I can't make up my mind. I like that the realistic
one has the tab on the lower right side just like my controller, most
drawings of the controllers miss this detail. |
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Wed Mar 05, 2008 8:18 am Post subject: |
|
I
say go for the drawing. I doubt Nintendo would be very happy with
someone using images of their stuff in an emulator. You might consider
taking out that super nintendo logo too. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Mar 05, 2008 9:09 am Post subject: |
|
The logo is fine.
Even the fact that it is a trademark is of no issue. |
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Wed Mar 05, 2008 9:22 am Post subject: |
|
Okay cool. I was just making sure about the logo and controller image. Eh I still like the hand drawn one better personally.  |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Mar 05, 2008 1:38 pm Post subject: |
|
The buttons look much better now
A bit convex, perhaps, maybe you could tone the lighting on them down
altogether? I think you're doing a great job on the whole though. Do
you intend to add holes around the buttons? Right now they look like
they were stuck right to the outer shell, and with how good everything
looks already, some black outlines shouldn't pose a problem.. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Mar 05, 2008 4:45 pm Post subject: |
|
Fritz
I do rendered 3D artwork myself, so I can appreciate the effort you've
put into it (and I do like it best). As you said the other one is
merely a filtered photograph, which while accurate, doesn't pop out at
me like yours does.
But of course, I'm more used
to the "asciipad" which was pretty much legendary among SNES console
owners at the time  |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Mar 05, 2008 5:41 pm Post subject: |
|
i swore by my asciiPad, and i never even used the turbo functions.
_________________
Why yes, my shift key *IS* broken. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 06, 2008 5:12 am Post subject: |
|
I've added something Linux users should like.
It appears that unlike Windows XP and below, Xorg with a compositor can render windows with an alpha channel per pixel. This means we can make a window transparent, without making the text on controls impossible to read.
Here's an example:

Obviously, my choice of background wallpaper probably wasn't the best,
nor was the alpha level I chose. But you get the idea. It can look
really, really good if done right. It also works fine when compositing
is not available.
Planning to use the Windows "make the whole damn window translucent"
trick again there, and default the behavior to off for all platforms.
Also, I started working on extending the status bar text. The idea is
to let you control the formatting that is printed there.
So far, you can print the FPS counter, the internal ROM name, and the base file name (sans path and extension).
I went a little farther with the internal ROM name. I converted it to
"Camelcase" and then lowercased all articles (except the first word).
In other words, "THE LEGEND OF ZELDA" becomes "The Legend of Zelda".
Not sure if I should keep this filtering. If you really want a nice
name, you should probably be using the filename instead anyway.
Example:
http://i73.photobucket.com/albums/i221/byuusan/bsnes_statusbar.png
All of this stuff is only half-way done, so no WIP for now. No point with how broken it is. Perhaps tomorrow.
Quote: |
Wow
i don't check this board for 2 days and when i get back actually
emulation bugs have been found AND fixed,byuu you're so fast!! |
Thank FitzRoy for spotting the bug so quickly. It's so much easier to
track down bugs when I know exactly what change broke said game(s).
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Mar 06, 2008 9:09 pm Post subject: |
|
Heh, either I have to be the most oblivious person alive or I clicked the wrong thing.
For some reason, I start up the latest bsnes and the window doesn't
appear to me. As far as I can tell, it's being created out of frame. I
deleted the config file, but I can't force the window to appear again.
Is there any place in the registry where bsnes' settings are saved?  |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 06, 2008 9:36 pm Post subject: |
|
All
settings are saved in the config file. You deleted the one in
%AppData%\.bsnes, right? (that is, assuming you're using Windows) |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Mar 06, 2008 9:43 pm Post subject: |
|
Ah, that fixed it. Might want to add to the readme that settings are saved there on Windows. Thanks a lot.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 06, 2008 10:18 pm Post subject: |
|
You set a window size bigger than your current desktop. bsnes saves that setting as soon as you change it.
It would be nice if Windows didn't decide to just completely hide any
windows that are even 1 single pixel bigger than your current
resolution.
Since the window size you request doesn't include the window
decoration, it makes it a real pain in the ass to determine if your
actual window size, with borders, will be bigger than the users'
current desktop resolution.
I'll fix it eventually with some GetSystemMetrics() and
AdjustWindowRect() magic, although it's Microsoft that should be fixing
this issue, and not me. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Mar 06, 2008 10:41 pm Post subject: |
|
Yea,
I was trying to boost the window size to about 960x720, but I got
pretty close. Going to scale4x and above for me causes the
disappearance.  |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Thu Mar 06, 2008 11:42 pm Post subject: |
|
byuu wrote: |
I've added something Linux users should like.
It appears that unlike Windows XP and below, Xorg with a compositor can render windows with an alpha channel per pixel. |
So can Windows 2000 and newer. See UpdateLayeredWindow.
Of course, you'll have to produce the RGBA bitmap yourself, or direct
GDI to paint to an off-screen bitmap and fill the alpha channel
yourself.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 07, 2008 12:18 am Post subject: |
|
byuu wrote: |
Here's an example:
|
Wow, your icon in linux looks just fine. Did you change anything for WIP18? No wonder you thought it looked good!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 07, 2008 7:22 pm Post subject: |
|
Quote: |
So
can Windows 2000 and newer. See UpdateLayeredWindow. Of course, you'll
have to produce the RGBA bitmap yourself, or direct GDI to paint to an
off-screen bitmap and fill the alpha channel yourself. |
UpdateLayeredWindow is of no help. That API was clearly designed only
for blitting fully self-rendered applications (think ZSNES or a fancy
taskbar clone) and cute bitmaps onto the screen (think of those little
animated characters that sit on your taskbar.) It might also help with
a novel startup splash screen. But it was never meant to be used to
create partially translucent windows with controls on them.
You can't simply use the HDC from a window, it won't work. The only
thing you can do with it is blit an HDC acquired from
CreateCompatibleDC(GetDC(0)) onto the screen with it. From there, you
attach a 32-bit bitmap to it with SelectObject(). And that's how you
get your per-pixel alpha channel.
So, to pull this off, you'd basically need to find some way of
capturing the window contents of another window, then manually blitting
that over to your translucent window. Then you have to compensate for
Microsoft's fucked pre-multiplied alpha values -- easy enough. Then
you'd need to somehow adjust the alpha. You could use clipping regions
to leave alpha = 255 for all controls. But then your "transparent"
controls, such as frames, labels and checkboxes will look like shit.
You can use GetSysColor() to detect the BG color and adjust the alpha
for that area as well, and now anti-aliased fonts will look horrible.
Ignoring this near-unsolvable problem ... next, you'd need to emulate
the Windows frame decorations on your translucent window. And even
after all of that, you're still left trying to parse all window
messages to know when to redraw your controls, since your form controls
on a layered window with this API will not be shown at all.
It would be very slow, indescribably difficult,
and even then, it would almost certainly look visually horrendous. And
it would be guaranteed to have lots of issues on a great number of
systems due to various quirks involved with such hackery.
Oh well, SetLayeredWindowAttributes (eg one alpha value for the entire window) will just have to do.
Quote: |
Wow, your icon in linux looks just fine. Did you change anything for WIP18? No wonder you thought it looked good! |
Nope, same icon. Linux is probably just better at scaling the icon than Windows.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 08, 2008 6:00 am Post subject: |
|
Okay,
I'm calling it done. If I dick with it anymore, it'll just end up being
worse. Tried to do something with the buttons, but no matter what
someone's going to see them as too concave or too convex. Trying to put
dark circles around them also looked terrible...
Last edited by FitzRoy on Sun Apr 20, 2008 7:27 am; edited 7 times in total |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Mar 08, 2008 6:13 am Post subject: |
|
it
looks almost perfect, i do think the colours red, green, blue, yellow
are too bright but it is only a tiny/minuscule personal preference...
you have done a excellent job.
_________________
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. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sat Mar 08, 2008 6:35 am Post subject: |
|
I think that's excellent the way it is.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Mar 08, 2008 6:53 am Post subject: |
|
that actually looks quite amazing. I agree about the button color shades, though. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Mar 08, 2008 7:44 am Post subject: |
|
i just noticed, the shoulder buttons look a tad too fuzzy/blurred. could be the white background tho.
_________________
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. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Mar 08, 2008 8:05 am Post subject: |
|
That's the shadowing from the light radiosity. The controller is actually casting shadows on a white countertop, if you will. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sat Mar 08, 2008 10:32 am Post subject: |
|
FitzRoy wrote: |
Trying to put dark circles around them also looked terrible... |
Just look how you did the Start/Select buttons - they look perfect.
_________________
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: Sat Mar 08, 2008 10:44 am Post subject: |
|
make
the shoulder buttons more prominent and you have a winner. based on the
gray background, this would be the last suggestion from me.
_________________
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. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sat Mar 08, 2008 12:57 pm Post subject: |
|
That's
very cool. Where did you get the artwork/font for the text? I seem to
recall somebody telling me once what fonts were used, although now I
can't recall... |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Sat Mar 08, 2008 4:33 pm Post subject: |
|
FitzRoy wrote: |
Okay,
I'm calling it done. If I dick with it anymore, it'll just end up being
worse. Tried to do something with the buttons, but no matter what
someone's going to see them as too concave or too convex. Trying to put
dark circles around them also looked terrible... |
I think the specular highlights on the buttons are too intense/white -
muting that a little might improve the perception.
Currently, they look very much like the translucent crystal orbs that Aqua (OS X) uses.
On a closer look, this may also be because the lighting is still
inconsistent with the rest of the controller. The bottom of the buttons
have the purest, brightest shade, and then it gets darker as you go up
- if the light source is angled from above, the "bottom" of the button
face should be the darkest spot.
Having the bottom be the brightest implies translucency as it appears
that it is the thinnest portion of a sphere (from front-to-back) and is
therefore occluding less light than the center is.
Hopefully I worded that all understandably 
_________________
Why yes, my shift key *IS* broken.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 08, 2008 10:57 pm Post subject: |
|
creaothceann wrote: |
FitzRoy wrote: |
Trying to put dark circles around them also looked terrible... |
Just look how you did the Start/Select buttons - they look perfect.
|
But there's an actual bevel there on a real controller. The buttons and
d-pad don't have that, it's a clean cut. And the cut for the buttons is
so precise and so tight, that, when looking at a real controller
head-on, you can't really see a dark outline at all. If I were to be
uber-realistic, I should have a much larger black outline around the
d-pad as you can clearly see King of Chaos' photos. But it just looks
so ugly at this angle, I refuse to add it. The black is too similar to
the d-pad, which makes it look like it's a part of the d-pad rather
than vacant spance beneath and around it.
Attempts at the buttons continue to end up looking blah.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 09, 2008 12:52 am Post subject: |
|
FitzRoy wrote: |
The
black is too similar to the d-pad, which makes it look like it's a part
of the d-pad rather than vacant spance beneath and around it. |
You may be right about that, but I messed with it a bit and I think it still looks less pasted on:
PS: though there's something to be said for some sort of outline around
all the buttons, I think the D-pad needs it most, for it to look like
it's able to move.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Mar 09, 2008 6:01 am Post subject: |
|
Thanks, FitzRoy. The controller graphic looks really amazing. I have two very minor changes to request if you don't mind.
First, I had to increase the size to 372x178 (Windows BMP format adds
alignment if width is not a multiple of 4 -- this makes it a real bitch
to convert the image to my UI wrapper pixel format), and shift the
actual image one pixel left to center the gradient fade.
Second, and more importantly, could you store the controller graphic in
32-bit format with alpha? Rather than using a white or gray background,
if I could get the full alpha channel information, then I can adjust
the background color to anything I like in the future. Depending on how
it looks, maybe I can just let the controller blend against the window
background itself.
And thank you, King of Chaos, as well. It was extremely difficult to
choose one over the other. I wish I could use just both so as not to
offend anyone. But I kind of like FItzRoy's more. I was kind of going
for that pristine, "cleaner than real life" look. Still, I really
appreciate your help in making a controller graphic.
---
New WIP.
I've added FitzRoy's controller graphic to the input capture window. It
will only display when configuring joypad buttons, not when configuring
UI buttons.
I've also added the new UI settings panel. This lets you control window
translucency for all but the main bsnes window. I capped opacity to 50%
minimum, because I don't want to hear bug reports when people slide it
to 0% and can't find the config window anymore :P
Works on Windows and Linux. If you lack a compositor on Linux, it'll
just stay a solid color. If you have Compiz / Beryl and the blur
filter, use it with gaussian alpha blur. Then you can set opacity all
the way down to 50% and it will still look amazing. I want to post a
screenshot of it, but the image is ~3MB. Maybe later I'll post it to
one of those file hosting sites.
There's also a setting here to control what gets written to the
statusbar. I went back to just displaying the raw ROM title. So you can
use %t for that, %n for the filename, and %f for the frame rate. Still
working on this feature. Plan to keep the game name visible when
pausing, add some additional info that can be output here, etc. It may
be better to keep this setting in the advanced panel, as it's not the
most user friendly thing in the world. Up to you guys, I guess.
Need more settings here, though. Need to fill out that window more. |
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Sun Mar 09, 2008 10:55 am Post subject: |
|
byuu wrote: |
There's
also a setting here to control what gets written to the statusbar. I
went back to just displaying the raw ROM title. So you can use %t for
that, %n for the filename, and %f for the frame rate. |
Quick, somebody try "%#+03.2ffps" and complain if it doesn't work!
;)
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 09, 2008 3:28 pm Post subject: |
|
Thristian wrote: |
Quick, somebody try "%#+03.2ffps" and complain if it doesn't work! |
It works 
So does, say, "%ffps - ROM: %n - filename: %n".
Or even "%f%n%t%f%tn%n"
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 09, 2008 4:03 pm Post subject: |
|
byuu wrote: |
And
thank you, King of Chaos, as well. It was extremely difficult to choose
one over the other. I wish I could use just both so as not to offend
anyone. But I kind of like FItzRoy's more. I was kind of going for that
pristine, "cleaner than real life" look. Still, I really appreciate
your help in making a controller graphic. |
No problem, it was more of a proof-of-concept than anything else. Is there any screenshots of the FitzRoy's image in action? =P
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 09, 2008 4:49 pm Post subject: |
|
King Of Chaos wrote: |
No problem, it was more of a proof-of-concept than anything else. Is there any screenshots of the FitzRoy's image in action? =P |
Here ya go:
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 09, 2008 4:59 pm Post subject: |
|
Oh, I like that! Good work byuu.  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Mar 09, 2008 5:08 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Thristian wrote: |
Quick, somebody try "%#+03.2ffps" and complain if it doesn't work! |
It works ;)
So does, say, "%ffps - ROM: %n - filename: %n".
Or even "%f%n%t%f%tn%n"
|
Thristian was joking. His example was a formatted string that you would give to eg sprintf().
% - variable marker
# - force decimal point to always show for floats
+ - adds +/- prefix always
0 - left-pad with zeroes (instead of spaces)
3 - minimum number of real characters to output
. - precision indicator
2 - minimum number of fractional bits to output
f - float-type output
So, all of that should print, eg "+060.01fps"
And here I thought writing my own sprintf() implementation wouldn't come in handy someday :P
(and no, I'm not adding that to bsnes)
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Mar 09, 2008 6:06 pm Post subject: |
|
Quick, somebody write a format string that crashes the application. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 10, 2008 7:39 am Post subject: |
|
Quote: |
I have two very minor changes to request if you don't mind. |
Sure, I've changed the original file to 372x178. Also changed the
bit-depth to 32-bit (I think). Actual controller length without shading
applied is 328, so there should be 22px of space on either side if it's
centered correctly, and it is. This one also has some minor
improvements to the cord and lower corners.
Regarding the transparent background: unfortunately I was lazy with the
cord layer and made the edges with the brush rather than the eraser
(had to use gradient map on the layer to make the gray one). Will
rework it when I get time, but, artistically I don't think you want a
transparent background anyway. If the background assumes the color of
the window, there will be no frame and the cord cutoff will look
strange. I think the white is a good choice as it goes with your white
config areas.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Mar 10, 2008 9:09 am Post subject: |
|
Now the d-pad looks like it's hovering above the controller. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 10, 2008 1:17 pm Post subject: |
|
henke37 wrote: |
Now the d-pad looks like it's hovering above the controller. |
That hasn't changed though I suggested a fix on the last page, but no one said whether they thought it was an improvement or not..
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Mar 10, 2008 1:43 pm Post subject: |
|
or
rip the D pad from King Of Chaos controller image... just draw it with
a thick black outline and not a shadow... since when have you seen a
shadow cast from the D pad on a snes controller?
_________________
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. |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Mon Mar 10, 2008 2:45 pm Post subject: |
|
Found
an interesting glitch with the game: Super Bomberman 5 - Gold
Cartridge. Happens when create, configure and then rename a custom
bomber (From what I gather from the Japanese).

This happens in every emulator, so I think this is a glitch in the
actual game - but I guess it is worth pointing out just in case it is a
real bug.
_________________

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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 10, 2008 3:03 pm Post subject: |
|
Quote: |
This
happens in every emulator, so I think this is a glitch in the actual
game - but I guess it is worth pointing out just in case it is a real
bug. |
Ah, my favorite kind of bug. If it doesn't occur on hardware, then
finding a fix most likely means exposing new hardware behavior that
will improve all emulators.
Okay, then. Anyone want to verify if this occurs on hardware?
|
|
powerspike Regular

Joined: 21 Nov 2005
Posts: 216
|
Posted: Mon Mar 10, 2008 3:43 pm Post subject: |
|
What
about something like this FitzRoy? Please excuse my ugly as sin editing
job, it's just an example. I stuck L and R on top of the controller
because I thought it was more clear to the user. Also I don't think the
cord is necessary since it's just to show the user how the button
layout looks.
 |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Mon Mar 10, 2008 4:44 pm Post subject: |
|
FitzRoy wrote: |
artistically
I don't think you want a transparent background anyway. If the
background assumes the color of the window, there will be no frame and
the cord cutoff will look strange. |
Would terminating the cord in a transparent fade work well?
_________________
Why yes, my shift key *IS* broken.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 10, 2008 4:53 pm Post subject: |
|
FitzRoy wrote: |
I
don't think you want a transparent background anyway. If the background
assumes the color of the window, there will be no frame and the cord
cutoff will look strange. I think the white is a good choice as it goes
with your white config areas. |
But with transparency users have the choice to change it if they want to. 
_________________
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 Mar 10, 2008 7:04 pm Post subject: |
|
creaothceann wrote: |
FitzRoy wrote: |
I
don't think you want a transparent background anyway. If the background
assumes the color of the window, there will be no frame and the cord
cutoff will look strange. I think the white is a good choice as it goes
with your white config areas. |
But with transparency users have the choice to change it if they want to.
|
Suppose the image with the transparent background is used. What choice
does a person who wants a non-window background have? Even now, you
have people who prefer the U.S. controller colors not getting them. You
see, any suggestion at this point is going to be in direct opposition
to someone else's. That goes for the controller, the icon, the menu
names, the menu placements, the window sizes, defaults, everything. At
some point, you need an authoritative decision or your program starts
to enter the realm of bloat, overwhelming it with options in the
attempt to satisfy every dissenter. In your defense, I always supported
externalizing the icon and controller, but that doesn't affect the GUI.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Mar 10, 2008 11:04 pm Post subject: |
|
byuu wrote: |
Quote: |
This
happens in every emulator, so I think this is a glitch in the actual
game - but I guess it is worth pointing out just in case it is a real
bug. |
Ah, my favorite kind of bug. If it doesn't occur on hardware, then
finding a fix most likely means exposing new hardware behavior that
will improve all emulators.
Okay, then. Anyone want to verify if this occurs on hardware?
|
The game doesn't have any special chips and can be tested on copier
right? If so I will test it and report back. Should have the results in
a few hours.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Mon Mar 10, 2008 11:46 pm Post subject: |
|
No special chips. It's tricky to reproduce, so here are the steps that should reproduce the screen every time:
1. Battle Game.
2. 3rd Option.
3. 1st Option.
4. Select 3rd Row (White Bomberman)
5. Choose the Bomberman with the Moustache and Cape and select the Gold Colour.
6. Select Next.
7. Select the forth option going down from the top (Save).
8. Select the top row (White Bomberman)
9. Select OK, and you see VVJPVW appear.
10. Select the second option from the top.
11. Type in CRA1G1 as the name and then choose the blue option at the far bottom-right.
12. If you have followed my instructions exactly, you arrive at the glitch screen I posted earlier.
This is tested with a valid rom, no save states, no cheat codes and fresh SRAM.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Tue Mar 11, 2008 2:00 am Post subject: |
|
It happen here as well. I try 2 dump versions.
"9. Select OK, and you see VVJPVW appear." The screen doesn't show this on my end. It say this on both version.

Super Bomberman 5 (Japan) and Super Bomberman 5 - Caravan Event Ban (Japan)

Btw: The controller picture look nice.
Waiting on Snark report.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 11, 2008 6:33 am Post subject: |
|
Clements wrote: |
No special chips. It's tricky to reproduce, so here are the steps that should reproduce the screen every time:
1. Battle Game.
2. 3rd Option.
3. 1st Option.
4. Select 3rd Row (White Bomberman)
5. Choose the Bomberman with the Moustache and Cape and select the Gold Colour.
6. Select Next.
7. Select the forth option going down from the top (Save).
8. Select the top row (White Bomberman)
9. Select OK, and you see VVJPVW appear.
10. Select the second option from the top.
11. Type in CRA1G1 as the name and then choose the blue option at the far bottom-right.
12. If you have followed my instructions exactly, you arrive at the glitch screen I posted earlier.
This is tested with a valid rom, no save states, no cheat codes and fresh SRAM. |
Thanks Clements. I'll test and report back. Shouldn't take too long hopefully.
edit: I managed to reproduced the bug in bsnes and ended up with the screenshot you posted.
The game doesn't boot in my copierso far..., probably just a matter of
auditing the rom (adding or removing an header...sometimes it happens)
Hopefully I'll get it to work.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 11, 2008 8:30 am Post subject: |
|
Sigh....Can't
get the game to work on my copier...Either I have a dump that doesn't
work on this unit or something else is messing up...in any cases if
Fitzroy or someone else could see if they has better luck on
hardware...Very sorry... |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Mar 11, 2008 12:57 pm Post subject: |
|
Damn.
Every time byuu needs help with hardware testing, I don't have my Snes
around. I just got back yesterday... We'll have to wait for Fitzroy I
guess. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 11, 2008 1:04 pm Post subject: |
|
My
flash cart was left at a friend's house and I won't be getting it back
for at least two weeks. Somebody else will have to do it or wait until
then. |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 11, 2008 2:41 pm Post subject: |
|
FitzRoy wrote: |
My
flash cart was left at a friend's house and I won't be getting it back
for at least two weeks. Somebody else will have to do it or wait until
then. |
Aah, bad luck. Is your cart big enough to hold this game, byuu?
|
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Tue Mar 11, 2008 2:48 pm Post subject: |
|
I will have a copy of the game in about a month, but I suppose that will be a bit late.
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way. |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Mar 11, 2008 2:59 pm Post subject: |
|
If that's the case, I'll test it on weekend when I have access to my console and flash cart. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Tue Mar 11, 2008 8:44 pm Post subject: |
|
I'm having an issue on making bsnes.
I'm using zmingw4.7z and bsnes_v028_01.tar.bz2
It will not make on my Vista 32bit right. Keep on saying something about "ease" when it stop there.
I'm using the right MinGW files byuu?
Oh yea another problem is that some of the files in zget4.2.zip keep
crashing after zmingw4.7z download. I had to download it from the
website.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Mar 11, 2008 8:50 pm Post subject: |
|
Dullaron wrote: |
I'm having an issue on making bsnes.
I'm using zmingw4.7z and bsnes_v028_01.tar.bz2
It will not make on my Vista 32bit right. Keep on saying something about "ease" when it stop there.
I'm using the right MinGW files byuu?
Oh yea another problem is that some of the files in zget4.2.zip keep crashing after zmingw4.7z download. |
You probably need this.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 11, 2008 8:54 pm Post subject: |
|
kode54 wrote: |
You probably need this. |
Hmm, as I recall bsnes does not compile right without changing the code
on gcc 3 (and if you do get it to compile it'll be a lot slower than on
gcc 4).
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue Mar 11, 2008 9:31 pm Post subject: |
|
Ok,
I've been playing with this today and I have a couple questions that
probably been asked (heh, how nice it'd be to be able to search within
the topic's 200+ pages).
-I set cheats and RAM to
save in a directory where bsnes is located, but it always saves the
cheat files within the ROMs folder. And reason why this is, even though
I've set it otherwise?
-My computer's internal speaker inside the tower beeps each time I
click on a menu, or anywhere within bsnes' configuration. Any reason
why bsnes running on Vista would beep at me like an error is occurring?
=P
Now, I have a couple suggestions and ideas, that *shouldn't* screw with
the overall fact that bsnes is to be as accurate as possible.
-Recent Games menu. I'm pretty sure this small feature wouldn't mess
with accuracy. Just to load games played before. Last 5 perhaps?
-Toggled Turbo Mode (aka fast forward). Heh, I suppose this kinda
messes with accuracy to be able to speed up a game on and off with a
toggle (backspace comes to mind), but I think it'd be handy for those
damn games that love to take their time loading. I realize an effect
like this is possible with video frameskip/speed regulation, but that's
too much clicking for my liking. =P
Well, that's all for now with my feedback. I'm off to cheat at some games. =P
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 11, 2008 10:21 pm Post subject: |
|
Quote: |
Suppose the image with the transparent background is used. What choice does a person who wants a non-window background have? |
It was mainly so that I had the choice to change it in the future if I
wanted. No so much that I was worried about others having that choice.
If it's a burden, don't worry about it. I'm happy with the white.
Thanks so much for making it.
Quote: |
Aah, bad luck. Is your cart big enough to hold this game, byuu? |
I have the same UFO copier as others. If the game doesn't work on theirs, it won't work on mine.
Quote: |
I'm using zmingw4.7z and bsnes_v028_01.tar.bz2 |
Sorry, I don't really have time to help people compile the emulator. It
uses standard MinGW4 plus the D3D9 SDK. Maybe Nach can help you with
zmingw.
Quote: |
-I
set cheats and RAM to save in a directory where bsnes is located, but
it always saves the cheat files within the ROMs folder. And reason why
this is, even though I've set it otherwise? |
That setting only applies to save RAM (srm) files. The new version
(v029) will add one for cheat (cht) files. You can specify unique
folders for both, or share the same folder if you like.
Quote: |
-My
computer's internal speaker inside the tower beeps each time I click on
a menu, or anywhere within bsnes' configuration. Any reason why bsnes
running on Vista would beep at me like an error is occurring? =P |
Doesn't happen on any of my boxes. And yes, I have the PC speaker
connected to the mainboard jumpers on at least the Vista box. Try
disabling "Windows Beep" under device manager (make sure View ->
Show hidden devices is checked.)
Quote: |
-Recent
Games menu. I'm pretty sure this small feature wouldn't mess with
accuracy. Just to load games played before. Last 5 perhaps? |
No way. I can't stand history tracking applications. Not adding that to bsnes.
Quote: |
-Toggled
Turbo Mode (aka fast forward). Heh, I suppose this kinda messes with
accuracy to be able to speed up a game on and off with a toggle
(backspace comes to mind), but I think it'd be handy for those damn
games that love to take their time loading. I realize an effect like
this is possible with video frameskip/speed regulation, but that's too
much clicking for my liking. =P |
I've been meaning to work on that. My idea was to allow both speed
multiplier and frameskip selection for each of the five modes. Then add
GUI key mappings to bump the speed up or down.
Then again, I was also thinking of merging the enabled toggle. Right
now, it acts the same as if frameskip had "Enabled" and then 1-9. No
reason for that. Make "Disabled" part of the six possible states. It'll
be the setting after "Fastest", for obvious reasons.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 11, 2008 11:11 pm Post subject: |
|
byuu wrote: |
Quote: |
Suppose the image with the transparent background is used. What choice does a person who wants a non-window background have? |
It was mainly so that I had the choice to change it in the future if I wanted.
|
Oh, well I can certainly see to that.
Quote: |
I'm happy with the white. Thanks so much for making it. |
No problem. Even if you hadn't, I figured it was fun to make and I
learned some new photoshop tricks along the way.
Quote: |
I can't stand history tracking applications. Not adding that to bsnes. |
I was about to request the continued absence of it myself. You would
have to go through several games every hour to justify the
seconds-saving convenience and added navigational bloat. I don't know
why other emulators bother.
Quote: |
I've
been meaning to work on that. My idea was to allow both speed
multiplier and frameskip selection for each of the five modes. Then add
GUI key mappings to bump the speed up or down. |
That sounds rather complicated. My idea is this:
1. Reduce the number of speed options to three for simplicity's sake.
Slow, Normal, and Fast. All still definable in the advanced panel. Then
create two input settings for "Slow Down" and "Speed Up" defaulted as
the "-" and "+" buttons on the keyboard. It would function as a step
system. So if you were on "Slow" and used speed-up, the checkmark would
go to "Normal." If you used slow-down on "Slow," nothing would happen.
2. Remove the "enable" entry entirely. The only purpose of disabling
speed regulation is for the novelty of using bsnes as a benchmark, and
anyone who wanted to do this could temporarily define "Fast" as 1000%
percent or something. It's just not that important of a feature to
warrant complicating the speed system with a separate option.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 11, 2008 11:17 pm Post subject: |
|
byuu wrote: |
Quote: |
Suppose the image with the transparent background is used. What choice does a person who wants a non-window background have? |
It was mainly so that I had the choice to change it in the future if I
wanted. No so much that I was worried about others having that choice.
If it's a burden, don't worry about it. I'm happy with the white.
Thanks so much for making it.
Quote: |
Aah, bad luck. Is your cart big enough to hold this game, byuu? |
I have the same UFO copier as others. If the game doesn't work on theirs, it won't work on mine.
|
There's no theoretical reasons it shouldn't work though, no? I was
thinking mine didn't work because of the specific rom dump I tried. It
might be worth a shot trying with your unit.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Mar 11, 2008 11:27 pm Post subject: |
|
FitzRoy wrote: |
Quote: |
I can't stand history tracking applications. Not adding that to bsnes. |
I was about to request the continued absence of it myself. You would
have to go through several games every hour to justify the
seconds-saving convenience and added navigational bloat.
|
Yes, sometimes I like to do that. Of course not in longer sessions of actual gameplay.
The issue is that the file selector is reset back to the first file when you open the dialog.
If it'd stay at the previously loaded file then there wouldn't be an issue.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 11, 2008 11:37 pm Post subject: |
|
Yeah, my idea was over complicated. I made a mock-up and it looked awful.
Quote: |
1. Reduce the number of speed options to three for simplicity's sake. Slow, Normal, and Fast. |
This is tricky. If bsnes weren't so slow, this would be a no brainer.
But on my system at least, I can get 100% speed with 1.5x execution
rate in any game, but 2.0x speed will falter on the most extreme games
on occasion, eg CT Black Omen, etc.
An auto-frameskip option would also take care of this, but I don't
really want to bother trying to code something like that. I could make
a frameskip control that increases the frameskipping until it maintains
120fps, but it wouldn't then lower the framerate when it reaches a less
intensive area. Sigh, it does need to be added, though ...
Maybe I can query the results of clock() between two frames. If I am
below the number of frames I need, raise frameskip by one. If I'm
equal, and less than ~800ms of time passed, decrease frameskip by one.
Alright, I'll give auto frameskip a try. If I can pull it off, we'll
reduce speed regulation to 3 options. 50%, 100% and 200%. Nice and
simple. Even nicer is not needing a system to manually modify the
frameskipping based upon the current speed regulation setting.
Quote: |
2.
Remove the "enable" entry entirely. The only purpose of disabling speed
regulation is for the novelty of using bsnes as a benchmark, and anyone
who wanted to do this could temporarily define "Fast" as 1000% percent
or something. |
I need this option to test changes to the code. I run some test ROMs to
see if a change sped up the emulator or slowed it down. I also use the
fast forward function feature, so crippling that is no good.
Heh, I wonder what I'd do for auto frameskip with uncapped speed.
Probably just leave frameskip at zero, which would be silly if it ended
up slower than fast mode (quite likely.) Which means putting it
immediately after fast wouldn't be good for up/down speed keys.
Almost makes Enable / Slow, Normal, Fast sound better ... right back where we started.
Quote: |
There's
no theoretical reasons it shouldn't work though, no? I was thinking
mine didn't work because of the specific rom dump I tried. It might be
worth a shot trying with your unit. |
Lots of games have anti-copier detection code in them. It's possible
it's tripping one of those. I don't really feel like disassembling the
game to get it working on a copier.
Quote: |
The issue is that the file selector is reset back to the first file when you open the dialog.
If it'd stay at the previously loaded file then there wouldn't be an issue. |
If you specify a ROM path, it defaults to that folder every time.
Otherwise, it's OS-dependent. Windows will use the last folder you
opened a ROM from, and GTK+ will default to your home folder or some
nonsense. I've been meaning to hack up GTK+ to default to the last
selected folder, because it's nicer. But I haven't gotten around to it
yet.
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 11, 2008 11:49 pm Post subject: |
|
byuu wrote: |
Lots of games have anti-copier detection code in them. It's possible it's tripping one of those. |
Yeah I found that on my own. Funny, but I wouldn't have guessed console
games in this era actually had software copy protections sometimes...
-Super Metroid has one (It displays a message at beginning)
-Demon's Crest has one too. DC is kinda nasty because the protection
involve the second or third boss of the game being invincible. Has
least Nintendo didn't tried to fuck with you...
But so far I haven't seem a game that doesn't have at least one dump
that doesn't "fix" or otherwise circumvent the protection. I'll see if
I can find one.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Mar 12, 2008 1:01 am Post subject: |
|
byuu wrote: |
Quote: |
The issue is that the file selector is reset back to the first file when you open the dialog.
If it'd stay at the previously loaded file then there wouldn't be an issue. |
If you specify a ROM path, it defaults to that folder every time.
Otherwise, it's OS-dependent. Windows will use the last folder you
opened a ROM from
|
Yeah, and you still have to scroll to the desired file, or type in
enough characters to select it. There's also probably no way to do that
automatically.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Mar 12, 2008 4:37 am Post subject: |
|
OK,
I tested Bomberman 5 Gold Cartridge on my SF7 copier and got the
glitch. Other than that the game works great. This copier has pretty
high compatibility; I've never had to "fix" a game to get it to work on
this copier, but let's see what results other people get. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 12, 2008 4:46 am Post subject: |
|
zidanax wrote: |
OK,
I tested Bomberman 5 Gold Cartridge on my SF7 copier and got the
glitch. Other than that the game works great. I've never had to "fix" a
game to get it to work on this copier, but let's see what results other
people get. |
Damn...
I'd really want to know what rom dump you have...Just to know if it's the rom I used or the copier
I know asking for roms is obviously against the rules...But could you
post the crc32 or some type of hash? (I don't think that- goes against any rules...)
Last edited by Snark on Wed Mar 12, 2008 4:49 am; edited 3 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 12, 2008 4:46 am Post subject: |
|
King Of Chaos wrote: |
In that case, I feel sorry for those with the entire SNES GoodSet.  |
I recommend these people use some minimal directory management and keep
the games they play copied or separated from their entire collections.
Even with history, bumped games and initial loads are going to continue
taking longer, so it's no silver bullet. Directory management is.
Last edited by FitzRoy on Wed Mar 12, 2008 4:56 am; edited 1 time in total
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Mar 12, 2008 4:56 am Post subject: |
|
What
type of copier do you have? Generally, the ROM has to be modified to
fit your copier's "format". Usually, this means adding the appropriate
copier header and/or interleaving the ROM. The program ucon64 can convert ROMs to a whole bunch of different copier formats automatically.
The dump I converted to SF7 format to transfer to my copier is:
Code: |
-------------------------Container--------------------------
File: Super Bomberman 5 - Gold Cartridge (J).SFC
Sub File: Super Bomberman 5 - Gold Cartridge (J).SFC
---------------------Internal ROM Info----------------------
Name: Hu SUPER BOMBERMAN 5G Company: Hudson Soft
Header: None Bank: HiROM
Interleaved: None ROM: 16 Mb
Type: Normal SRAM: 64 Kb
Expansion: None Battery: Present
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x6075 Game Code: Marked, AK8J
---------------------------Hashes---------------------------
CRC32: 4590AE9D
--------------------------Database--------------------------
Name: Super Bomberman 5 - Gold Cartridge
Country: Japan Revision: 1.0
Port 1: Gamepad Port 2: The Multitap
Genre 1: Action Genre 2: Bomberman |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 12, 2008 5:25 am Post subject: |
|
zidanax wrote: |
What type of copier do you have? Generally, the ROM has to be modified
to fit your copier's "format". Usually, this means adding the
appropriate copier header and/or interleaving the ROM. The program ucon64 can convert ROMs to a whole bunch of different copier formats automatically.
The dump I converted to SF7 format to transfer to my copier is:
Code: |
-------------------------Container--------------------------
File: Super Bomberman 5 - Gold Cartridge (J).SFC
Sub File: Super Bomberman 5 - Gold Cartridge (J).SFC
---------------------Internal ROM Info----------------------
Name: Hu SUPER BOMBERMAN 5G Company: Hudson Soft
Header: None Bank: HiROM
Interleaved: None ROM: 16 Mb
Type: Normal SRAM: 64 Kb
Expansion: None Battery: Present
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x6075 Game Code: Marked, AK8J
---------------------------Hashes---------------------------
CRC32: 4590AE9D
--------------------------Database--------------------------
Name: Super Bomberman 5 - Gold Cartridge
Country: Japan Revision: 1.0
Port 1: Gamepad Port 2: The Multitap
Genre 1: Action Genre 2: Bomberman |
|
Thanks!
I have a Game Doctor SF3. Already using ucon64. Hmmm...CRC is the
same...Although mine has an "smc" extension not SFC though in theory
that really doesn't change anything...Can you tell me what version of
Ucon you're using?
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Mar 12, 2008 5:31 am Post subject: |
|
Using ucon64 2.0.0. Since the SF3 and the SF7 use the same ROM format, how about I post my ucon64 output for converting the ROM:
Code: |
F:\Incoming>ucon64 --gd3 "Super Bomberman 5 - Gold Cartridge (J).SFC"
uCON64 2.0.0 Win32 (MinGW) 1999-2005
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License
Create: NTUSER.idx
ERROR: Can't open "C:\Documents and Settings\zidanax\NTUSER.DAT" for reading
Please see the FAQ, question 47 & 36
WARNING: "NTUSER.DAT" is meant for a console unknown to uCON64
F:\Incoming\Super Bomberman 5 - Gold Cartridge (J).SFC
Multi Game Doctor (2)/Multi Game Hunter/MGH
0000ffb0 31 38 41 4b 38 4a 00 00 00 00 00 00 00 00 00 00 18AK8J..........
0000ffc0 48 75 20 53 55 50 45 52 20 42 4f 4d 42 45 52 4d Hu SUPER BOMBERM
0000ffd0 41 4e 20 35 47 31 02 0b 03 00 33 00 8a 9f 75 60 AN 5G1....3...u`
Super Nintendo Entertainment System/SNES/Super Famicom
Hu SUPER BOMBERMAN 5G
Hudson Soft
Japan
2097152 Bytes (16.0000 Mb)
Padded: Maybe, 24619 Bytes (0.1878 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: No
HiROM: Yes
Internal size: 16 Mb
ROM type: (2) ROM + SRAM + Battery
ROM speed: 120 ns (FastROM)
SRAM: Yes, 8 kBytes
Version: 1.0
Checksum: Ok, 0x6075 (calculated) == 0x6075 (internal)
Inverse checksum: Ok, 0x9f8a (calculated) == 0x9f8a (internal)
Checksum (CRC32): 0x4590ae9d
Wrote output to: sf16Sup
|
And the ucon64 output of the resulting ROM. (Not NSRT, because I want
the CRC32 calculated while taking into account the interleaving and
header):
Code: |
F:\Incoming>ucon64 sf16sup
uCON64 2.0.0 Win32 (MinGW) 1999-2005
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License
Create: NTUSER.idx
ERROR: Can't open "C:\Documents and Settings\zidanax\NTUSER.DAT" for reading
Please see the FAQ, question 47 & 36
WARNING: "NTUSER.DAT" is meant for a console unknown to uCON64
F:\Incoming\sf16sup
Game Doctor SF3(SF6/SF7)/Professor SF(SF II)
000101b0 31 38 41 4b 38 4a 00 00 00 00 00 00 00 00 00 00 18AK8J..........
000101c0 48 75 20 53 55 50 45 52 20 42 4f 4d 42 45 52 4d Hu SUPER BOMBERM
000101d0 41 4e 20 35 47 31 02 0b 03 00 33 00 8a 9f 75 60 AN 5G1....3...u`
Super Nintendo Entertainment System/SNES/Super Famicom
Hu SUPER BOMBERMAN 5G
Hudson Soft
Japan
2097152 Bytes (16.0000 Mb)
Padded: Maybe, 13438 Bytes (0.1025 Mb)
Interleaved/Swapped: Yes
Backup unit/emulator header: Yes, 512 Bytes
HiROM: Yes
Internal size: 16 Mb
ROM type: (2) ROM + SRAM + Battery
ROM speed: 120 ns (FastROM)
SRAM: Yes, 8 kBytes
Version: 1.0
Checksum: Ok, 0x6075 (calculated) == 0x6075 (internal)
Inverse checksum: Ok, 0x9f8a (calculated) == 0x9f8a (internal)
Search checksum (CRC32): 0x4590ae9d
Data checksum (CRC32): 0x03df1f12 |
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 12, 2008 6:14 am Post subject: |
|
zidanax wrote: |
Using ucon64 2.0.0. Since the SF3 and the SF7 use the same ROM format,
how about I post my ucon64 output for converting the ROM:
Code: |
F:\Incoming>ucon64 --gd3 "Super Bomberman 5 - Gold Cartridge (J).SFC"
uCON64 2.0.0 Win32 (MinGW) 1999-2005
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License
Create: NTUSER.idx
ERROR: Can't open "C:\Documents and Settings\zidanax\NTUSER.DAT" for reading
Please see the FAQ, question 47 & 36
WARNING: "NTUSER.DAT" is meant for a console unknown to uCON64
F:\Incoming\Super Bomberman 5 - Gold Cartridge (J).SFC
Multi Game Doctor (2)/Multi Game Hunter/MGH
0000ffb0 31 38 41 4b 38 4a 00 00 00 00 00 00 00 00 00 00 18AK8J..........
0000ffc0 48 75 20 53 55 50 45 52 20 42 4f 4d 42 45 52 4d Hu SUPER BOMBERM
0000ffd0 41 4e 20 35 47 31 02 0b 03 00 33 00 8a 9f 75 60 AN 5G1....3...u`
Super Nintendo Entertainment System/SNES/Super Famicom
Hu SUPER BOMBERMAN 5G
Hudson Soft
Japan
2097152 Bytes (16.0000 Mb)
Padded: Maybe, 24619 Bytes (0.1878 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: No
HiROM: Yes
Internal size: 16 Mb
ROM type: (2) ROM + SRAM + Battery
ROM speed: 120 ns (FastROM)
SRAM: Yes, 8 kBytes
Version: 1.0
Checksum: Ok, 0x6075 (calculated) == 0x6075 (internal)
Inverse checksum: Ok, 0x9f8a (calculated) == 0x9f8a (internal)
Checksum (CRC32): 0x4590ae9d
Wrote output to: sf16Sup
|
And the ucon64 output of the resulting ROM. (Not NSRT, because I want
the CRC32 calculated while taking into account the interleaving and
header):
Code: |
F:\Incoming>ucon64 sf16sup
uCON64 2.0.0 Win32 (MinGW) 1999-2005
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License
Create: NTUSER.idx
ERROR: Can't open "C:\Documents and Settings\zidanax\NTUSER.DAT" for reading
Please see the FAQ, question 47 & 36
WARNING: "NTUSER.DAT" is meant for a console unknown to uCON64
F:\Incoming\sf16sup
Game Doctor SF3(SF6/SF7)/Professor SF(SF II)
000101b0 31 38 41 4b 38 4a 00 00 00 00 00 00 00 00 00 00 18AK8J..........
000101c0 48 75 20 53 55 50 45 52 20 42 4f 4d 42 45 52 4d Hu SUPER BOMBERM
000101d0 41 4e 20 35 47 31 02 0b 03 00 33 00 8a 9f 75 60 AN 5G1....3...u`
Super Nintendo Entertainment System/SNES/Super Famicom
Hu SUPER BOMBERMAN 5G
Hudson Soft
Japan
2097152 Bytes (16.0000 Mb)
Padded: Maybe, 13438 Bytes (0.1025 Mb)
Interleaved/Swapped: Yes
Backup unit/emulator header: Yes, 512 Bytes
HiROM: Yes
Internal size: 16 Mb
ROM type: (2) ROM + SRAM + Battery
ROM speed: 120 ns (FastROM)
SRAM: Yes, 8 kBytes
Version: 1.0
Checksum: Ok, 0x6075 (calculated) == 0x6075 (internal)
Inverse checksum: Ok, 0x9f8a (calculated) == 0x9f8a (internal)
Search checksum (CRC32): 0x4590ae9d
Data checksum (CRC32): 0x03df1f12 |
|
F*ck!
I get the exact same output with both the pre and post SF3/7 convertion
using UCON....I don't get it. Unless the SF3 and SF7 varies in terms of
compatibility I don't see what's wrong...
edit
Your unit doesn't require the use of floppies, right? I'm forced to use
the "-s" split option in my case. That's the only real difference so
far.
|
|
zidanax Hazed

Joined: 29 Jul 2004
Posts: 86
Location: USA
|
Posted: Wed Mar 12, 2008 6:35 am Post subject: |
|
Yeah,
I have my unit set up to use the parallel cable. I use ucon64's --xgd6
command to transfer over my cable. I suppose you haven't had problems
transferring through floppies before? Anyway, it's possible that
Bomberman 5 is indeed incompatible with the SF3. The SF3's
compatibility is known to be imperfect. http://www.tototek.com/phpBB2/viewtopic.php?t=1371.There
are a few different options in ucon64 for removing various kinds of
protection, if you want to experiment with that. Although that might
not be such a good idea for bug testing, since you'd be testing with a
hacked ROM. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Mar 12, 2008 6:55 am Post subject: |
|
Snark wrote: |
byuu wrote: |
Lots of games have anti-copier detection code in them. It's possible it's tripping one of those. |
Yeah I found that on my own. Funny, but I wouldn't have guessed console
games in this era actually had software copy protections sometimes...
-Super Metroid has one (It displays a message at beginning)
|
If I recall, it also erases your saves. I may be mixing it up with something else.
Megaman X had one too. I can't recall what it did, just that it was there.
|
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Mar 12, 2008 7:45 am Post subject: |
|
the
colours on the logo and controller look great and all, but I'm curious
as to why we don't use the official Super Famicom colours ( seen in
Star Road in Super Mario World)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 12, 2008 8:19 am Post subject: |
|
What do you mean? Green, blue, yellow, and red are the official colors. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Mar 12, 2008 9:06 am Post subject: |
|
I assume he means the exact same colours that nintendo used and not just a generic red, green, blue, yellow.
_________________
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. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 12, 2008 9:18 am Post subject: |
|
Shit............
I think my backup unit may be Mou......Shinde iru...(or shinde aru anyway if that makes any Japanese sense)
It craps on games it used to play fine... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 12, 2008 9:56 am Post subject: |
|
franpa wrote: |
I assume he means the exact same colours that nintendo used and not just a generic red, green, blue, yellow. |
I think if you both start digging for reference material, you'll
eventually answer your own questions. What's reference? Super Mario
World and the one that appears on boxes don't match exactly either.
Ever think that maybe the SMW one can't possibly be reference material
since the SNES has a limited palette? And guess what happens when the
controller is not photographed in a well-lit environment and with no
lighting? The colors not only appear darker than reality, there is no
lightening across the surface of the buttons. What's your beef with the
program icon? It's almost identical to several box scans I've
accumulated, and god knows what scanner they were taken with or what
effect the material on which the ink was applied changed the color from
reference. Any further assertion that I'm not doing the colors "right"
better be accompanied by an essay-style analysis.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Mar 12, 2008 1:59 pm Post subject: |
|
FitzRoy wrote: |
And
guess what happens when the controller is not photographed in a
well-lit environment and with no lighting? The colors not only appear
darker than reality, there is no lightening across the surface of the
buttons. |
Uh, I'm sorry, I normally agree with you, but there's no freaking way
the colours you used are correct. They're much too light; I have two
controllers lying around here and a friend of mine has atleast two more
that would prove it. They're also much more angular than your picture
suggests and are, in fact, almost entirely flat. Like someone else
said, the buttons look like they're partially transparent, where
they're opaque in reality, which probably explains some of the
difference in colouring.
I appreciate all the work you've done on it and I think it looks great,
but these differences are much too big to be subjective. I don't know
what sources you've used, but I'm sorry, they're wrong.
|
|
paulguy Regular
Joined: 02 Jul 2005
Posts: 280
|
Posted: Wed Mar 12, 2008 4:08 pm Post subject: |
|
Jesus
christ people. This is horrible nitpicking, mostly. I like the image.
I'll agree with the buttons looking too round/translucent but who CARES
about the colors. It's not supposed to be accurate. It's supposed to
LOOK GOOD. Only thing I don't like is the buttons look like aqua from
mac osx. It's not too big a deal, though, that there should be several
10s of posts on it. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 12, 2008 6:33 pm Post subject: |
|
I will try another lighting technique on the buttons this week. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 12, 2008 9:03 pm Post subject: |
|
Wow.
I really appreciate that everyone just wants the best possible work in
bsnes -- but it's just a controller graphic. It doesn't have to be
perfect. FitzRoy said he didn't want to keep working on the image, so
let's please leave it be.
It was really nice of
him to make the graphic. And you guys were way more than courteous
about my previous controller graphic that was absolutely terrible by
comparison. This is a huge improvement, so it should definitely be
welcomed.
Quote: |
I will try another lighting technique on the buttons this week. |
Please don't worry about it. I'm very happy with the graphic already in there.
If someone wants to make their own graphic that everyone agrees is
superior, I'll be happy to use that instead. Otherwise, I'm very happy
with FitzRoy's :)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 12, 2008 9:26 pm Post subject: |
|
Thanks,
I don't mind the criticism on the lighting. If I didn't partially
agree, I wouldn't have conceded to try again. This is oddly the hardest
part, and I thought the shoulders were going to be. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Mar 12, 2008 9:36 pm Post subject: |
|
I agree; it looks nice the way it is, so, like Byuu said, let it be.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Mar 12, 2008 10:17 pm Post subject: |
|
FitzRoy wrote: |
I will try another lighting technique on the buttons this week. |
Thanks; sorry about my last post, I was a bit cranky this morning. It's
not a big deal to me, just wanted to point out that there is a core of
truth to what people have been saying as your reply to franpa was a bit
dismissive. Anyway, many thanks for your effort.
|
|
doktor_kris Rookie
Joined: 25 Feb 2006
Posts: 38
|
Posted: Wed Mar 12, 2008 10:49 pm Post subject: |
|
IIRC MMX tries to write to SRAM and halts if successful in doing so.
Aladdin also does something like that, I think. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 13, 2008 4:47 am Post subject: |
|
oh
I have no beef, I absolutely love the graphic, I was honestly just
wondering why we were using non official shades is all. didn't mean to
start a debate, I was just wondering, I actually thought that maybe
there was some revised snes with new colors that I didn't know about.
Really, no big deal, just honestly curious.
also
not to make a big deal of it, but yes I did think that Super Mario
World might have a limited pallet, but lets be realistic here, the
screen it's on is all black with some white, yellow, and red dots, and
then there is the logo, there is no shading, just the straight 4
colours,
**shrugs**
not trying to make a bigger deal, just explaining my thought process
again, I absolutely love the graphic, was just honestly curious, so is it just that you don't like the other ones?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Thu Mar 13, 2008 9:51 pm; edited 1 time in total |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Mar 13, 2008 6:04 pm Post subject: |
|
Panzer88 wrote: |
the snes can display 256 different colours at once, and can choose from a greater amount |
... HDMA and colour math, baby. Have some then correct that sentence.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Mar 13, 2008 8:29 pm Post subject: BomberMan 5 Tested on Wildcard DX |
|
Hey
byuu, sorry I am a bit late on this one. I tested BomberMan 5 Gold on
my Wildcard DX 1, and it exhibits the same bug as in bsnes. So I reckon
bsnes is displaying the gfx output correctly =D |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Thu Mar 13, 2008 9:46 pm Post subject: |
|
grinvader wrote: |
Panzer88 wrote: |
the snes can display 256 different colours at once, and can choose from a greater amount |
... HDMA and colour math, baby. Have some then correct that sentence.
|
club me, don't know what I was thinking.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Thu Mar 13, 2008 10:07 pm Post subject: |
|
I
am bored, when do we start with supporting something that is not
currently supported? Seriously, at least give us multitap support.
It's not that I think that the GUI is a complete waste of time but, it sure gets a lot of attention lately. |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Mar 13, 2008 10:24 pm Post subject: |
|
henke37 wrote: |
when do we start with supporting something that is not currently supported? . |
"We" is pretty much byuu alone.
edit: unless you actually started to be an active bsnes dev that is
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Thu Mar 13, 2008 10:52 pm Post subject: |
|
henke37 wrote: |
I
am bored, when do we start with supporting something that is not
currently supported? Seriously, at least give us multitap support.
It's not that I think that the GUI is a complete waste of time but, it sure gets a lot of attention lately. |
So let me get this straight. You rather byuu focus his time supporting the things that currently aren't supported?
Heh, it's byuu's project, he can do whatever he wants with it. If he
wants to spend time doing the GUI, that's fine by me. I'm sure he'll
want to support unsupported things when HE feels like it. Just be glad
with what you have. 
Unless, of course, you know how to code, and how the hardware works,
and wish to contribute to bsnes, go right ahead. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 13, 2008 11:15 pm Post subject: |
|
Adding useability features to your program is very satisfying, lemme tell you
But after 206 pages we should all know that byuu starts to feel bad
after not making any core changes for a while - so I wouldn't worry
about it. Remember that he's been implementing that time-shift code in
preparation for working on the new PPU; it's just a matter of getting
0.029 as finished as possible as the new core will no doubt be slower
than the current one, not to mention that work on it will take quite a
while. I don't remember byuu's stance on multitap, but he has added
more-or-less all the stuff he can without wasting loads of time
researching it. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Thu Mar 13, 2008 11:18 pm Post subject: |
|
I
would like to see only the mouse support for Mario Paint. If pc mouse
and Super Nintendo mouse doesn't work the same way then I will let byuu
explain to me why. I don't really get it.
I felt like he is in pSX Author shoes added what he knows. I understand that.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Mar 14, 2008 1:25 am Post subject: |
|
Panzer88 wrote: |
grinvader wrote: |
Panzer88 wrote: |
the snes can display 256 different colours at once, and can choose from a greater amount |
... HDMA and colour math, baby. Have some then correct that sentence.
|
club me, don't know what I was thinking.
|
You
were thinking that surely Nintendo wouldn't actively make their system
look WORSE than it was in their own marketing literature.
Why they insisted, and still insist, that it's 256 colors per screen is beyond me.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Mar 14, 2008 3:47 am Post subject: |
|
Nintendo's Marketing Literature actually stated 512 colors at a time when it compared it to the Genesis in one of them.
Also, there's one scene in DKC which I took a screenshot of, which my
paint program tells me has over 1000 colors in it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Mar 14, 2008 6:43 am Post subject: |
|
it
may seem like the GUI is getting a lot of attention, but you have to
understand guys it's been long overdue, cut the guy some slack, also it
is us in the community that have gone on about it for several pages 
@ Gil
yes! I feel so lied to and confused, damn you Nintendo! 
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Fri Mar 14, 2008 6:54 am Post subject: |
|
Yes,
it is his project. Yes, the GUI might have needed the work. But I
personaly think that some easy things are overdue, like the multitap. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Mar 14, 2008 7:43 am Post subject: |
|
And we're all very excited to see your code for said easy feature!
... or your kind donation to byuu of a multitap with which to actually
begin implementing this feature! Gosh, that would be swell!
... or maybe even just you letting byuu run his project at his own
pace, in whatever order he decides to work on features for his emulator.
Yeah. Maybe it's just me not being in desperate need for multitap
support (probable), but I hope that would make sense even if I wanted
it as badly as you seem to. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Mar 14, 2008 7:53 am Post subject: |
|
what snes games are there, that supports the multi tap anyways?
_________________
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. |
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Fri Mar 14, 2008 9:23 am Post subject: |
|
franpa wrote: |
what snes games are there, that supports the multi tap anyways? |
Super Bombermans, duh.
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Mar 14, 2008 10:07 am Post subject: |
|
Johan_H wrote: |
franpa wrote: |
what snes games are there, that supports the multi tap anyways? |
Super Bombermans, duh.
|
Shouldn't it be Super Bombermen? 
Don't forget Secret of Mana!
...
But DO forget Seiken Densetsu 3.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Mar 14, 2008 10:24 am Post subject: |
|
so, like 10 games in total support it but dont rely on it? sounds kinda obvious why focus is on core emulation then 
_________________
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. |
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Fri Mar 14, 2008 11:10 am Post subject: |
|
There
are like 6873 sports games with multi tap support. No one plays them of
course, but on the other hand everyone plays SoM and Bomberman.
http://en.wikipedia.org/wiki/SNES_Multitap
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Fri Mar 14, 2008 11:39 am Post subject: |
|
Oh man bsnes went hidden after I max the screen size. I wasn't able get it back like it was. How I get it back? 
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Fri Mar 14, 2008 12:13 pm Post subject: |
|
the answer was given a page or 2 ago.
_________________
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. |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Fri Mar 14, 2008 12:32 pm Post subject: |
|
If
anyone has been stalking me over the years, you might know that
Bomberman is one of my favourite games, so yes, multi-tap is important
to me. I'm sure byuu is not opposed to adding support for multi-tap eventually in bsnes. The multi-tap is probably the peripheral that the most people actually care about.
_________________

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

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 14, 2008 2:22 pm Post subject: |
|
franpa wrote: |
what snes games are there, that supports the multi tap anyways? |
I should just say RTFM or use NSRT, but at this moment, I'll be nice... for this post.
_________________
FF4 research never ends for me.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Mar 14, 2008 2:23 pm Post subject: |
|
Nach wrote: |
Nintendo's Marketing Literature actually stated 512 colors at a time when it compared it to the Genesis in one of them.
Also, there's one scene in DKC which I took a screenshot of, which my
paint program tells me has over 1000 colors in it. |
I still have my old Nintendo Powers where they claimed it was 256 colors from a palette of 32,768.
Can you tell me which scene in DKC has the possible 1000+ colors in it?
Just want to make sure it wasn't something like a filter or bilinear
filtering causing the paint program to record more colors.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 14, 2008 2:34 pm Post subject: |
|
DKC scenes have tons of blending going on.. so that shouldn't that surprising if you think about it.
_________________
FF4 research never ends for me. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 14, 2008 4:18 pm Post subject: |
|
Something
to feed the restless crowd here: I began toying with vsync again and
realized something I had never tried before. With vsync off in bsnes, I
created a d3d game profile for bsnes within my ati driver settings with
vsync forced. This created a special shortcut to bsnes on my desktop,
and running bsnes in this manner seems to make vsync work without audio
issues. Anyone with a 2ghz or above core 2 duo should try this and post
your results. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 14, 2008 4:27 pm Post subject: |
|
FitzRoy wrote: |
Something
to feed the restless crowd here: I began toying with vsync again and
realized something I had never tried before. With vsync off in bsnes, I
created a d3d game profile for bsnes within my ati driver settings with
vsync forced. This created a special shortcut to bsnes on my desktop,
and running bsnes in this manner seems to make vsync work without audio
issues. Anyone with a 2ghz or above core 2 duo should try this and post
your results. |
As an addendum, have you tried using D3D Overrider (comes with
RivaTuner) to enable Triple Buffering with those settings?
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Fri Mar 14, 2008 4:45 pm Post subject: |
|
FirebrandX wrote: |
Can
you tell me which scene in DKC has the possible 1000+ colors in it?
Just want to make sure it wasn't something like a filter or bilinear
filtering causing the paint program to record more colors. |
grinvader wrote: |
... HDMA and colour math, baby. Have some then correct that sentence. |
I won't tire of quoting myself anytime soon !
... and I won't give the exact number myself either !
(wait for a nice guy like byuu to plaster your face in delicious accurate possibilities flavour pie)
Weeeeeeee
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 14, 2008 5:24 pm Post subject: |
|
IIRC there's a test ROM that demonstrates displaying all possible 32768 colours at the same time  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 14, 2008 7:35 pm Post subject: |
|
Verdauga Greeneyes wrote: |
IIRC there's a test ROM that demonstrates displaying all possible 32768 colours at the same time  |
Yep.

_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Fri Mar 14, 2008 7:47 pm; edited 2 times in total
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Fri Mar 14, 2008 7:43 pm Post subject: |
|
Verdauga Greeneyes wrote: |
all possible 32768 colours |
You're not taking every possibility into account ! Now start toying around with the brightness reg !
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
vkamicht Rookie

Joined: 03 Mar 2006
Posts: 14
|
Posted: Fri Mar 14, 2008 8:14 pm Post subject: |
|
FitzRoy wrote: |
Something
to feed the restless crowd here: I began toying with vsync again and
realized something I had never tried before. With vsync off in bsnes, I
created a d3d game profile for bsnes within my ati driver settings with
vsync forced. This created a special shortcut to bsnes on my desktop,
and running bsnes in this manner seems to make vsync work without audio
issues. Anyone with a 2ghz or above core 2 duo should try this and post
your results. |
Hmm, anyone know any way to do this with NVidia cards?
EDIT: I found something in the control panel but it tends to refer to
"3d applications", and although I set up a profile for bsnes forcing
vsync on it doesn't do anything.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 14, 2008 8:25 pm Post subject: |
|
Quote: |
OK, I tested Bomberman 5 Gold Cartridge on my SF7 copier and got the glitch. Other than that the game works great. |
Quote: |
Hey
byuu, sorry I am a bit late on this one. I tested BomberMan 5 Gold on
my Wildcard DX 1, and it exhibits the same bug as in bsnes. |
Sweet, thanks for verifying! We need to start making lists of known
bugs in games, heh. I can see us forgetting that we tested this two
years from now.
Quote: |
Megaman X had one too. I can't recall what it did, just that it was there. |
KDL3 was the best. Three-tier protection. Break one and the game
silently modifies another area slightly. Break that and repeat. They
actually thought this would stop piracy. I'm sure that was the idea of
some upper-level management person. Developers are typically smart enough to realize how stupid protections like these are.
Then again, I add some of these myself. But I do it just to chase off
the newbies with hex editors. I don't really expect to stop anyone with
a debugger and a clue from breaking the protections.
Quote: |
I
am bored, when do we start with supporting something that is not
currently supported? Seriously, at least give us multitap support. |
I'll add it eventually. Do you really have four friends who are into retro SNES gaming and want to play you in SB5? If so, I am very jealous.
Quote: |
It's not that I think that the GUI is a complete waste of time but, it sure gets a lot of attention lately. |
Well, I work on what interests me at the time. I'm also developing
work-related applications using my hiro UI library. Features added to
bsnes are features added to business productivity apps. Features added
to business productivity apps are one step closer to a promotion for me
:)
This is pretty much the only way I'm going to land a developer job without a BS degree.
I just figured out how to use IsDialogMessage(), but the tabs are backwards for some bizarre reason. But soon, soon, bsnes will have a working tab key :)
Quote: |
I
would like to see only the mouse support for Mario Paint. If pc mouse
and Super Nintendo mouse doesn't work the same way then I will let byuu
explain to me why. I don't really get it. |
A PC mouse gives an X/Y offset on the screen. Very easy. The SNES mouse
gives offsets to the previous position, as well as a speed rate flag.
Eg "mouse moved really fast up by 30 and left by 80 pixels."
The Super Scope and Justifier are X/Y based, but they trigger SNES IRQs. Ugh.
Much more of a pain to emulate. But I'll most likely get it all added eventually.
Quote: |
Oh man bsnes went hidden after I max the screen size. I wasn't able get it back like it was. How I get it back? |
Alright, let me see if GetWindowRect() on my hidden resize window can help solve this problem ...
Quote: |
You're not taking every possibility into account ! Now start toying around with the brightness reg ! |
This is actually true ... the SNES brightness reg is bizarre. B=0 still
results in a visible image, believe it or not. B=1 is a huge step up,
and B=2+ are pretty much gradual up to B=15. But since the brightness
setting appears to affect luma directly, it gives you more than 32,768
possible colors. Not like you'd ever be able to tell, though.
It's easiest to see with B=1 ... no 15-bit adjustment amount seems to
properly simulate the colors you get from there.
|
|
blargg Regular

Joined: 30 Jun 2005
Posts: 206
Location: USA
|
Posted: Fri Mar 14, 2008 8:45 pm Post subject: |
|
grinvader wrote: |
You're not taking every possibility into account ! Now start toying around with the brightness reg ! |
Assuming
that the color is output as Cout = Cin * brightness, where Cin is a
5-bit R/G/B component, brightness is a 4-bit value, I calculate 449059
unique possible colors. It's less than 2^(5+5+5+4) because there are
several duplicates, for example all 32768 RGB values with brightness=0
result in black output.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 14, 2008 8:50 pm Post subject: |
|
byuu wrote: |
This
is actually true ... the SNES brightness reg is bizarre. B=0 still
results in a visible image, believe it or not. B=1 is a huge step up,
and B=2+ are pretty much gradual up to B=15. But since the brightness
setting appears to affect luma directly, it gives you more than 32,768
possible colors. Not like you'd ever be able to tell, though.
It's easiest to see with B=1 ... no 15-bit adjustment amount seems to
properly simulate the colors you get from there. |
Interesting.. I wonder if anyone's ever attempted to make the smoothest gradient the SNES can display using this.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 14, 2008 9:08 pm Post subject: |
|
blargg wrote: |
It's
less than 2^(5+5+5+4) because there are several duplicates, for example
all 32768 RGB values with brightness=0 result in black output. |
False.
Quote: |
B=0 still results in a visible image, believe it or not. |
Try it for yourself and see. Display a bright image, set B=0, then max
out all of your TV settings. You'll be able to faintly make out the
image. Works best with black background and white text.
It's also not a residual image. The second you set the display disable flag, the image really does disappear.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 14, 2008 9:22 pm Post subject: |
|
Are
the relative differences in brightness for each of the values known?
(If they are, I suppose the follow-up question is "Does bsnes emulate
them?" and if so, does it use RGB888 for that step? Do you anticipate
the behaviour will change throughout work on a dot-based PPU?) Also,
byuu, you may already be aware of this, but your website seems to be
down. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 14, 2008 10:22 pm Post subject: |
|
Quote: |
Are the relative differences in brightness for each of the values known? |
They're rougly stable steps from 15 down to 1. It's 0 that's screwy.
And no, it isn't emulated. I haven't been able to get it right. I tried
a luma that just gives a possible color range of 0-2 and it was way
off. I tried a bunch of RGB->YUV->RGB stuff and still failed to
get close. And no again, all internal color math is RGB555. This is a
large reason why I don't bother with B=0.
If I make the internal output RGB888, I won't be able to use the quick
brightness / contrast / gamma adjust tables anymore. 24-bit lookup
table == memory whore. Plus, it'd be slower.
Quote: |
Also, byuu, you may already be aware of this, but your website seems to be down. |
I don't know why that happens all the time. Just add /index.php onto
the URI and it will work. Hopefully it'll fix itself shortly.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Mar 14, 2008 11:16 pm Post subject: |
|
grinvader wrote: |
FirebrandX wrote: |
Can
you tell me which scene in DKC has the possible 1000+ colors in it?
Just want to make sure it wasn't something like a filter or bilinear
filtering causing the paint program to record more colors. |
grinvader wrote: |
... HDMA and colour math, baby. Have some then correct that sentence. |
I won't tire of quoting myself anytime soon !
... and I won't give the exact number myself either !
(wait for a nice guy like byuu to plaster your face in delicious accurate possibilities flavour pie)
Weeeeeeee
|
Yeah, I had a look at the snes docs for dma and hdma. I understand now.
Basically the snes can display more colors than normal via the use of
raster tricks.
BTW I have been looking at DKC and couldn't find any scenes that used
more than about 220 colors. I'd really like to mess around with the
thousand color-scene that was mentioned. Anyone remember where in the
game it is?
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Mar 14, 2008 11:38 pm Post subject: |
|
FitzRoy wrote: |
Something
to feed the restless crowd here: I began toying with vsync again and
realized something I had never tried before. With vsync off in bsnes, I
created a d3d game profile for bsnes within my ati driver settings with
vsync forced. This created a special shortcut to bsnes on my desktop,
and running bsnes in this manner seems to make vsync work without audio
issues. Anyone with a 2ghz or above core 2 duo should try this and post
your results. |
I've tried this and you basically trade stuttering sound for a
stuttering frame rate. All 60 frames are shown, but the game will
freeze for a fraction of a second several times in order to keep in
time with the audio. Its quite a bit worse than how an auto-frame-rate
feature behaves on other emulators.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 14, 2008 11:47 pm Post subject: |
|
FirebrandX wrote: |
BTW
I have been looking at DKC and couldn't find any scenes that used more
than about 220 colors. I'd really like to mess around with the thousand
color-scene that was mentioned. Anyone remember where in the game it is? |
Dunno, but it's probably something with half-transparent layers.
_________________
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: Fri Mar 14, 2008 11:54 pm Post subject: |
|
FirebrandX wrote: |
FitzRoy wrote: |
Something
to feed the restless crowd here: I began toying with vsync again and
realized something I had never tried before. With vsync off in bsnes, I
created a d3d game profile for bsnes within my ati driver settings with
vsync forced. This created a special shortcut to bsnes on my desktop,
and running bsnes in this manner seems to make vsync work without audio
issues. Anyone with a 2ghz or above core 2 duo should try this and post
your results. |
I've tried this and you basically trade stuttering sound for a
stuttering frame rate. All 60 frames are shown, but the game will
freeze for a fraction of a second several times in order to keep in
time with the audio. Its quite a bit worse than how an auto-frame-rate
feature behaves on other emulators.
|
Hmm, perhaps my CRT at 85hz makes this less apparent. I was meaning to test with an LCD as well.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Mar 15, 2008 12:05 am Post subject: |
|
FitzRoy wrote: |
Hmm, perhaps my CRT at 85hz makes this less apparent. I was meaning to test with an LCD as well. |
That may be the issue. I am using an LCD at fixed 60Hz refresh rate.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Mar 15, 2008 1:02 am Post subject: |
|
byuu wrote: |
Quote: |
Also, byuu, you may already be aware of this, but your website seems to be down. |
I don't know why that happens all the time. Just add /index.php onto
the URI and it will work. Hopefully it'll fix itself shortly.
|
Adding that will only get you to the main page. It doesn't seem to work on the bsnes page or other sub pages
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 15, 2008 4:10 am Post subject: |
|
Ok
I deleted all the bsnes and bsnes.exe in the regedit.exe. It didn't
reset back to the default settings. It use to reset when I done this.
Where are the settings save at? I'm scratching my head trying to reset
it so that I have the bsnes window screen back. F11 full screen is
fine. My screen is max out at 1280 by 1024. 
Just trying to save your time working on fixing this. I thought it will be easier to fix it on my own. 
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 15, 2008 4:37 am Post subject: |
|
I
guess that's one drawback to hiding the cfg. What was the argument for
that again? Transporting bsnes on CD-Rs or something... which no one
uses anymore since usb flash drives have gotten massive and cheap. I
guess you can't change it back in advanced anymore can you, since it's
been removed. *shrugs* |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sat Mar 15, 2008 7:14 am Post subject: |
|
C:\Documents and Settings\Franpa\Application Data\.bsnes
Dullaron
_________________
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. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Sat Mar 15, 2008 7:45 am Post subject: |
|
byuu wrote: |
Quote: |
Are the relative differences in brightness for each of the values known? |
They're rougly stable steps from 15 down to 1. It's 0 that's screwy.
And no, it isn't emulated. I haven't been able to get it right. I tried
a luma that just gives a possible color range of 0-2 and it was way
off. I tried a bunch of RGB->YUV->RGB stuff and still failed to
get close. And no again, all internal color math is RGB555. This is a
large reason why I don't bother with B=0.
If I make the internal output RGB888, I won't be able to use the quick
brightness / contrast / gamma adjust tables anymore. 24-bit lookup
table == memory whore. Plus, it'd be slower.
|
hmm.... yet another thing that prolly isn't even visible, and yet, it
is another thing.... damn machines are complex.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sat Mar 15, 2008 8:37 am Post subject: |
|
King Of Chaos wrote: |
http://byuu.cinnamonpirate.com/ is dead. Did they delete your page byuu? |
Well, D's page is still up...
Edit: byuu.org doesn't work either.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Sat Mar 15, 2008 9:34 am Post subject: |
|
I.S.T. wrote: |
King Of Chaos wrote: |
http://byuu.cinnamonpirate.com/ is dead. Did they delete your page byuu? |
Well, D's page is still up...
Edit: byuu.org doesn't work either.
|
They (the host) were doing a server transfer:
Quote: |
We're currently in the middle of a server transfer!
(for better and faster service, of course!)
Unfortunately, all sites will be unavailable until the transfer is complete.
Website owners - you do not have to do anything to get your site
working again. We will be finished by 8AM EST. |
Then I got this earlier today:
Quote: |
Welcome to cinnamonpirate.com!
This is a place-holder for the cinnamonpirate.com home page. [...] |
So I guess the move is done, but some stuff needs to be fixed. Though now I can't reach the server at all either.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Mar 15, 2008 12:50 pm Post subject: |
|
I
can only wish for 3+ friends, I use the multitap since it is the
simplest thing to support. I mean, there is a make your own template in
the official documentation, without PICs!
The only worry is if bsnes should support banned extension controller setups. Like multiple mice and so on. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 15, 2008 2:17 pm Post subject: |
|
franpa wrote: |
C:\Documents and Settings\Franpa\Application Data\.bsnes
Dullaron |
Thanks a lot.
Why is it save over here C:\Documents and Settings\Mitchell Hancock\Application Data\.bsnes and not in C:\bsnes?
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Mar 15, 2008 2:21 pm Post subject: |
|
Dullaron wrote: |
franpa wrote: |
C:\Documents and Settings\Franpa\Application Data\.bsnes
Dullaron |
Thanks a lot.
Why is it save over here C:\Documents and Settings\Mitchell
Hancock\Application Data\.bsnes and not in C:\bsnes?
|
"Some people" wanted multiple profile support (for an emu, it is a
waste of time IMO, especially if you prefer self containment of files).
_________________
FF4 research never ends for me.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Mar 15, 2008 2:25 pm Post subject: |
|
henke37 wrote: |
banned extension controller setups. Like multiple mice and so on. |
... I can't find a way to develop my point without a lot of swear
words, so I'm just gonna say you should stop while you're ahead
(especially since you're not).
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 15, 2008 4:19 pm Post subject: |
|
franpa wrote: |
C:\Documents and Settings\Franpa\Application Data\.bsnes |
That's "%AppData%\.bsnes" which could be anything considering you can
change where user data is stored; in my case it's "C:\Users\[user
name]\Application Data\.bsnes". Anyway, it's the standard place for
apps to place their config files in Windows when you want multiple user
support. It's stored in a similar place for Linux for that very reason.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Mar 15, 2008 5:02 pm Post subject: |
|
FirebrandX wrote: |
Nach wrote: |
Nintendo's Marketing Literature actually stated 512 colors at a time when it compared it to the Genesis in one of them.
Also, there's one scene in DKC which I took a screenshot of, which my
paint program tells me has over 1000 colors in it. |
I still have my old Nintendo Powers where they claimed it was 256 colors from a palette of 32,768.
|
Do you have the issue where they compare it to the Genesis, where you
see the two people painting a picture, and the little kid asks the guy
over there if he can borrow a crayon? It says 512 there.
FirebrandX wrote: |
Can you tell me which scene in DKC has the possible 1000+ colors in it?
Just want to make sure it wasn't something like a filter or bilinear
filtering causing the paint program to record more colors. |
It was some point in the first level. No filtering or anything, just a
regular direct SNES image screenshot, and then color count.
byuu wrote: |
KDL3 was the best. Three-tier protection. Break one and the game
silently modifies another area slightly. Break that and repeat. They
actually thought this would stop piracy. I'm sure that was the idea of
some upper-level management person. Developers are typically smart enough to realize how stupid protections like these are.
|
No, very no. You're thinking of KDC.
byuu wrote: |
I'll add it eventually. Do you really have four friends who are into retro SNES gaming and want to play you in SB5? If so, I am very jealous.
|
Don't be jealous, but I've done it more times than I can count on two
hands (>1023). For example, the only games my little sisters like
playing is Mario Party or one of the SBs, so when I go to visit them,
it's usually something that's played.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Mar 15, 2008 9:38 pm Post subject: |
|
grinvader wrote: |
henke37 wrote: |
banned extension controller setups. Like multiple mice and so on. |
... I can't find a way to develop my point without a lot of swear
words, so I'm just gonna say you should stop while you're ahead
(especially since you're not).
|
Relax, it's not like I am suggesting anything unreasonable, like SGB
support. But multiple mice is probably not going to happen. At least
not until there is proper OS support and a game that uses it. But
multitap + superscope is not that insane.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Mar 15, 2008 9:43 pm Post subject: |
|
henke37 wrote: |
grinvader wrote: |
henke37 wrote: |
banned extension controller setups. Like multiple mice and so on. |
... I can't find a way to develop my point without a lot of swear
words, so I'm just gonna say you should stop while you're ahead
(especially since you're not).
|
Relax, it's not like I am suggesting anything unreasonable, like SGB
support. But multiple mice is probably not going to happen. At least
not until there is proper OS support and a game that uses it. But
multitap + superscope is not that insane.
|
Wow, just wow.
Seriously, go stick your head in the ground, and hope some real brains start growing.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Mar 15, 2008 11:24 pm Post subject: |
|
henke37 wrote: |
I
can only wish for 3+ friends, I use the multitap since it is the
simplest thing to support. I mean, there is a make your own template in
the official documentation, without PICs!
The only worry is if bsnes should support banned extension controller setups. Like multiple mice and so on. |
WTF is a banned extension controller setup. Multiple mice are completely valid. I point you to Arkanoid.
_________________
Watering ur plants.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Mar 15, 2008 11:31 pm Post subject: |
|
Nach,
If you could let me know which issue that appeared in, I'll check to
see if I have it. I've got like over a hundred of those old mags
stashed in my closet.
As for the DKC thing, I've taken screenshots all over the first level,
but nothing ever got above the "normal" 256 color limit. I'll keep
looking though.
Edit: found one with over 500 colors. While not a thousand, its still enough to impress! |
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Mar 16, 2008 12:21 am Post subject: |
|
FirebrandX wrote: |
Nach,
If you could let me know which issue that appeared in, I'll check to
see if I have it. I've got like over a hundred of those old mags
stashed in my closet.
As for the DKC thing, I've taken screenshots all over the first level,
but nothing ever got above the "normal" 256 color limit. I'll keep
looking though.
|
I don't remember which issue, it might've been something in the 40s.
FirebrandX wrote: |
Edit: found one with over 500 colors. While not a thousand, its still enough to impress! |
I think the screenshot was near the beginning where the ostrich thing
is, and I was rolling on a barrel and had Diddy.
_________________
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 Mar 16, 2008 12:25 am Post subject: |
|
I'm
afraid I lack the skill to make a button look convex without resorting
to lighting effects, but this still looks better than the last one.
 |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Mar 16, 2008 12:29 am Post subject: |
|
FitzRoy wrote: |
I'm
afraid I lack the skill to make a button look convex without resorting
to lighting effects, but this still looks better than the last one.
 |
The pad makes no sense, it's a Super Famicom controller with the Super Nintendo logo.
_________________
Watering ur plants.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Sun Mar 16, 2008 12:37 am Post subject: |
|
the shadow on the D-pad is way too big for it considering how far it is off the pad. the buttons look a fair bit better.
_________________
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. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Mar 16, 2008 12:40 am Post subject: |
|
pagefault wrote: |
The pad makes no sense, it's a Super Famicom controller with the Super Nintendo logo. |
PAL pads are pretty close to that.
They're exactly like that, except for the gloss, and shiny, and effects, you get my drift.

_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Mar 16, 2008 12:42 am Post subject: |
|
I stand corrected. Why did we get the fruitloops edition of it.
_________________
Watering ur plants. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Mar 16, 2008 12:43 am Post subject: |
|
pagefault wrote: |
I stand corrected. Why did we get the fruitloops edition of it. |
Same reason we got Terranigma.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sun Mar 16, 2008 12:47 am Post subject: |
|
Both the SFC/PAL Snes controllers looks better than the US version.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 1:35 am Post subject: |
|
I'll see if I can get one up later with the flatter buttons. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 2:26 am Post subject: |
|
Byuu, I've found a bug:
On the intro of Sailor Moon, text is chopped out.
I've did a screen recording and uploaded it to youtube. It shows what
happens (basically, a visual representation of what I'm saying, and
explain below)
http://youtube.com/watch?v=onCz0PUwuRk
I'm no programmer (yet), but I have a pretty good guess what causes it.
When there is a fully animated background (like that star approaching,
or when the star is shown moving left), text flickers as it rolls
across the screen, and much of it is chopped and cut out. But when
there is no animation happening in the background, and just sprites,
etc (you know, the usual stuff), there's nothing wrong with the text,
so I'm guessing it's that star at the beginning of the intro, that
causes the text to be cut out like that. Basically, animated background
do something that makes the text look like spiders have eaten it. This
is the only problem I've had so far, because apart from that, the game
pretty much runs perfectly.
(psst, I show a lot of footage from the game, after the bug isn't
happening anymore, to emphasize that it's only happening right at the
start (as far as I can tell anyway))
PS:
You'll notice the occasional sound crackling in this video; that's not
a problem with your emulator, but because when recording, I get a lot
of frame drops, so the sound crackles (usually, when I'm not recording,
I always get full speed). So, it's a problem with my hardware not being
good enough, that's all 
PS2:
Sorry about the video being a tad stretched. I forgot to add a border
to the video so that it wouldn't do that when I upload it. Ohwell, I'm
sure it doesn't matter that much anyway.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 3:04 am Post subject: |
|
The
full name of the game is "Bishoujo Senshi Sailormoon - Another Story
(SHVC-AASJ-JPN) (v1.0)". The original text is Japanese and I don't
think there is an official Euro or U.S. translated release for this
title. You're probably using a hard-patched translation of the game
that was only tested on an emulator and not real hardware. Somebody
should just test the hard patched rom with their copier and save byuu
the trouble.
Last edited by FitzRoy on Sun Mar 16, 2008 3:07 am; edited 1 time in total |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sun Mar 16, 2008 3:05 am Post subject: |
|
Sailormoon (France) is the one I have. The circle isn't line up at all. Is this normal?

---------------------Internal ROM Info----------------------
File: smoonf.sfc
Name: SAILOR MOON Company: Angel/Sotsu Agency/Sunrise
Header: None Bank: HiROM
Interleaved: None SRAM: 0 Kb
Type: Normal ROM: 12 Mb
Country: France Video: PAL
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0xBD73 Game Code:
---------------------------Hashes---------------------------
CRC32: CD89020D
MD5: D65F6CB61E6AA709A2C8874FF407FCB9
RIPEMD: EF2C17F4C2863AB363A82515CB17DE4838630C39
SHA-1: E3E4886F2E69E15E878EB70EF97E31C84F9F81DE
SHA-256: 0AA16D6B588BA05AB00936201E68A694746FC5E1B2E4F2DBF7CDA09265A81379
SHA-512: 26930683A6A951B8738065C5168951ABF04DEAA7C8AE5CF4545A304532BF7D9D
2390A6D969A6ED76721623B4EF70AA4F75F486BDF350EADCC5910548B0D6F84E
Tiger: 133EC0110F102B32813DB20CE16B58033EC35BAC7041E4F9
Whirlpool: 615D017597EE167901B21EEAADC7DE6A29155590EE73440F9FEF277C066ABEF2
BA9FF66DC875498D0DD3435961B54916FB08D0BBC801D60EC4578936C18B9AE1
--------------------------Database--------------------------
Name: Sailor Moon
Country: France Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Fighting Genre 2: Brawler
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 3:09 am Post subject: |
|
The
cat is sitting on a platform. The spotlight is being broken up by it.
The France release of Sailor Moon is a port of Bishoujo Senshi
Sailormoon (SHVC-AE-JPN) (v1.0). |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 3:15 am Post subject: |
|
FitzRoy wrote: |
The
full name of the game is "Bishoujo Senshi Sailormoon - Another Story
(SHVC-AASJ-JPN) (v1.0)". The original text is Japanese and I don't
think there is an official Euro or U.S. translated release for this
title. You're probably using a hard-patched translation of the game
that was only tested on an emulator and not real hardware. Somebody
should just test the hard patched rom with their copier and save byuu
the trouble. |
Just got the original (that you mentioned from) from [ROM image links
are not allowed] , and there aren't any problems.
However, I also heeded your advice and tried the hard-patched one (the
one in English that I show a YT vid of), that I'm having problems with
on bsnes, on a copier, and there are no problems.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 3:22 am Post subject: |
|
FitzRoy wrote: |
The
cat is sitting on a platform. The spotlight is being broken up by it.
The France release of Sailor Moon is a port of Bishoujo Senshi
Sailormoon (SHVC-AE-JPN) (v1.0). |
No. From what I can tell, it's a complete rewite, i.e. not the same game.
http://en.wikipedia.org/wiki/Sailor_moon#Video_games
Dullaron/Fitzroy, shut up and stop acting as if your king, let byuu decide.
PS:
I got my hard-patched Sailor Moon rom here:
Removed by me because I've found out that I'm allowed to post rom links here <_<
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Sun Mar 16, 2008 3:28 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 3:23 am Post subject: |
|
Gah, remove the rom link. Not allowed to do that here.
Quote: |
Dullaron/Fitzroy, shut up and stop acting as if your king, let byuu decide. |
Dude, I'm trying to help you. You didn't post jack for information.
There are tons of Sailor Moon games, translated and otherwise. How does
he know which one you're reporting?
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 3:26 am Post subject: |
|
Because I gave a link to the one I got, until you told me to remove it.
Annnyyyy way, I didn't expect I'd be flamed for posting a bug report. Byuu, contact me at this address:
coil_e@yahoo.co.uk, and I will give you a link to the rom that highlights the bug in bsnes (and of course, you have my youtube link above)
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 3:34 am Post subject: |
|
wikipedia wrote: |
The
only original Sailor Moon game to be released outside of Japan was the
Bishōjo Senshi Sailor Moon game developed by Angel, released in France
as "Sailormoon" in 1994. |
Where does it say it's a completely new game? That very link says in
plain English that "Bishōjo Senshi Sailor Moon" was released in France
under the name "Sailormoon."
Quote: |
Because I gave a link to the one I got, until you told me to remove it. |
No, you posted that after you reported the bug and I elaborated information.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 3:37 am Post subject: |
|

(the original japanese version. Look at "1995")
A japanese game being released in FRANCE first. That's a new one on me.
wikipedia wrote: |
The
only original Sailor Moon game to be released outside of Japan was the
Bishōjo Senshi Sailor Moon game developed by Angel, released in France
as "Sailormoon" in 1994. |
Quote: |
No, you posted that after you reported the bug and I elaborated information. |
At first, I assumed that there was only one version (i.e. the one I
had). I posted that exact one afterwards, because that's when I found
out there were different versions. Duh.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Sun Mar 16, 2008 3:46 am; edited 1 time in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 3:45 am Post subject: |
|
You're confused. I referenced two different games in my above posts.
Yours:
"Bishoujo Senshi Sailormoon - Another Story (SHVC-AASJ-JPN) (v1.0)"
and Dullaron's:
"Bishoujo Senshi Sailormoon (SHVC-AE-JPN) (v1.0)"
released in France as "Sailormoon (SNSP-AE-FRA) (v1.0)" |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 3:51 am Post subject: |
|
Pfff, whatever. I only signed up so I could post this bug report anyway. I didn't expect to be flamed for it.
Oh, and, who the fuck are you? Exactly. You are nobody, therefore not
worth arguing with (I also don't care about the different versions, I'm
only posting about the one I have). Good bye (well, until maybe I have
something else to say elsewhere).
Byuu, remember, since I can't post romlinks here, coil_e@yahoo.co.uk, and I'll send it to you.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Sun Mar 16, 2008 4:09 am Post subject: |
|
Franky wrote: |
Pfff, whatever. I only signed up so I could post this bug report anyway. I didn't expect to be flamed for it.
Oh, and, who the fuck are you? Exactly. You are nobody, therefore not worth arguing with |
You're the only one here using abusive language, disagreeing with you
is not "flaming." Besides, Fitzroy is probably the single most
qualified person to tell you about BSNES compatibility. He's tested and
retested and regression tested numerous ROMs on BSNES. Who are you to
step in and insult him for trying to help you?
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Mar 16, 2008 4:19 am Post subject: |
|
Fitzroy: Welcome to the wonderful land of facing righteous stupidity.
Enjoy your stay, it never ends... >:D
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 16, 2008 4:54 am Post subject: |
|
Wow,
well, I won't get into this, but Fitzroy, I feel for you. I hope byuu
is willing to do something with this bug report regardless how
disagreeable its source.
By the way, the curvature
of the buttons on your new controller image actually looks better to me
than before, but they look incredibly glassy. Pretty, to be sure, but
it feels rather impractical - couldn't you just make them less shiny?
Other than that, great work as always. I don't think the shadow looks
particularly odd. |
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 5:06 am Post subject: |
|
Hey, if something good comes of it, I'm all for getting told by a Sailor Moon fan. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Mar 16, 2008 5:36 am Post subject: |
|
Lots of talking.
As I've said many times before, I typically don't like working on fan
translations. The programmers are almost always far less skilled than
professional developers, and they almost always test on emulators
rather than hardware.
I may look into this when I'm feeling particularly bored, though I
don't know how you could have possibly picked a worse game for me to be
caught debugging at work. Well, maybe those "Adult Manga" PD ROMs ...
EDIT: New WIP. This one adds IsDialogMessage() support. It isn't
perfect, the test apps get the highlighted dots around the active
controls, but bsnes isn't for some reason. Don't know why that is yet.
And it seems once tab enters into a child window, you can't get back to
the outer window. But otherwise, it's better than nothing. I even got
the z-order thing down so tab works in the right direction. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Mar 16, 2008 6:15 am Post subject: |
|
byuu wrote: |
I may look into this when I'm feeling particularly bored, though I
don't know how you could have possibly picked a worse game for me to be
caught debugging at work.
|
What, are you afraid they'll find out you're a girly-man?
It'd be an OK game if the play balance wasn't totally screwed up. You
can leave one area reasonably powerful, enter the next, and be facing
1-hit kills from every random encounter in the new area.
...
Or at least, that's what I've been told. I'm certainly never going to admit to playing it.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Mar 16, 2008 6:47 am Post subject: |
|
Gil_Hamilton wrote: |
I'm certainly never going to admit to playing it.  |
You can play it? 
I thought it was one of those things everyone jokes about but doesn't actually exist.
Or at least, that's what I've been told. I'm certainly never going to admit to seeing it.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Mar 16, 2008 7:39 am Post subject: |
|
*Has beaten it.*
It's not that hard. Hell, if you're careful, you can own just about
everything with ease. There are a few bosses that are hard, but they're
the exception, not the rule. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Mar 16, 2008 7:53 am Post subject: |
|
I.S.T. wrote: |
*Has beaten it.*
It's not that hard. Hell, if you're careful, you can own just about
everything with ease. There are a few bosses that are hard, but they're
the exception, not the rule. |
My sister beat it.
She state-whored. And the final boss took forever.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Mar 16, 2008 7:58 am Post subject: |
|
Gil_Hamilton wrote: |
I.S.T. wrote: |
*Has beaten it.*
It's not that hard. Hell, if you're careful, you can own just about
everything with ease. There are a few bosses that are hard, but they're
the exception, not the rule. |
My sister beat it.
She state-whored. And the final boss took forever.
|
She must not have gotten the super secret prize for completing the
puzzle: Five identical accessories that kick ass.
Or leveled very high. Leveling is very easy towards the end.
Edit: In one or two hours I went from 60-80 to 99.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Mar 16, 2008 8:45 am Post subject: |
|
I.S.T. wrote: |
Gil_Hamilton wrote: |
I.S.T. wrote: |
*Has beaten it.*
It's not that hard. Hell, if you're careful, you can own just about
everything with ease. There are a few bosses that are hard, but they're
the exception, not the rule. |
My sister beat it.
She state-whored. And the final boss took forever.
|
She must not have gotten the super secret prize for completing the
puzzle: Five identical accessories that kick ass.
Or leveled very high. Leveling is very easy towards the end.
Edit: In one or two hours I went from 60-80 to 99.
|
I THINK she needed one piece. Not sure.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Mar 16, 2008 9:17 am Post subject: |
|
You
can get 70% or more of the pieces needed just by fighting. It's
entirely possible to complete the puzzle without getting all of the
pieces found on the map. I did. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Mar 16, 2008 9:51 am Post subject: |
|
byuu wrote: |
Sweet, thanks for verifying! We need to start making lists of known
bugs in games, heh. I can see us forgetting that we tested this two
years from now.
|
I have been saying that from the first day fitzroy and i did the full romset test.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Mar 16, 2008 9:53 am Post subject: |
|
Hey,
you know what what, my bad. I was kinda half asleep when posting all
that (very late at night it was). I'm just got up a few minutes ago,
and I realise I was being an asshole.
Hmm, ok then
I just accept that the patched rom I have was coded badly (the hackers
that changed some of teh code anyway). But it does work properly on a
real snes using a copier, while it has that glitch I reported on bsnes;
if it works on the real thing, but not on bsnes, then that's something
that needs to be changed.
(hmm, I'll just play sailor moon on snesgt until/if the bug is fixed).
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Mar 16, 2008 10:17 am Post subject: |
|
tetsuo55 wrote: |
byuu wrote: |
Sweet, thanks for verifying! We need to start making lists of known
bugs in games, heh. I can see us forgetting that we tested this two
years from now.
|
I have been saying that from the first day fitzroy and i did the full romset test.
|
I wasn't ever opposed to it, I just didn't want to manage documenting
something as daunting as game glitches. And I certainly don't think it
needs displayed on the first page. It'll only be useful as a reference
in the rare events that people do inquire about a glitch that was
already addressed.
Bishoujo Senshi Sailor Moon - Another Story (J) [T+Eng1.00_BST] is the
goodsnes name of the rom with the text bug. If anyone else with a
copier wants to double verify, please do.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sun Mar 16, 2008 10:52 am Post subject: |
|
The
official snes development book part 2 has a list of rules for combining
extension controllers. I would quote it if I where not stuck on my Wii,
feel free to do so in my place. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Mar 16, 2008 12:21 pm Post subject: |
|
henke37 wrote: |
The
official snes development book part 2 has a list of rules for combining
extension controllers. I would quote it if I where not stuck on my Wii,
feel free to do so in my place. |
...
Let's put it simply. On the real console nothing prevents you from
plugging any peripheral in a slot. it simply works or not depending
what it needs to work (for example the superscope can't latch if you
don't plug it in port 2, but the buttons are properly sent even if it's
on port 1 - so "something" could be made that uses a scope on port 1).
That's all there is to it. Emulate the device, emulate the port.
Forbidding combinations because you think it's not practical and/or
doesn't exist is about as retarded as not emulating some weird mosaic
behaviour because nothing ever used it.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 16, 2008 1:13 pm Post subject: |
|
Franky wrote: |
Hey,
you know what what, my bad ... But it does work properly on a real snes
using a copier, while it has that glitch I reported on bsnes ... |
There you go, that's something we can work with. Does everyone have access to this ROM?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Mar 16, 2008 1:24 pm Post subject: |
|
FitzRoy wrote: |
tetsuo55 wrote: |
byuu wrote: |
Sweet, thanks for verifying! We need to start making lists of known
bugs in games, heh. I can see us forgetting that we tested this two
years from now.
|
I have been saying that from the first day fitzroy and i did the full romset test.
|
I wasn't ever opposed to it, I just didn't want to manage documenting
something as daunting as game glitches. And I certainly don't think it
needs displayed on the first page. It'll only be useful as a reference
in the rare events that people do inquire about a glitch that was
already addressed.
|
I agree with you, the "bugs that are not bugs" should be a seperate
effort, untill the xml-in-a-rom system catches on it might be a good
idea to add a .txt file to bsnes zip file with a list of these bugs,
that does mean however that byuu would need to maintain the list.
Come to think of it though, it might be a good idea to simply put up a
sticky somewhere on the zsnes board, as this list would effect ALL snes
emulators
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 16, 2008 6:31 pm Post subject: |
|
Well,
my thoughts are about such an idea to log game specific bugs is that
it'd be an endless list to keep track of. Now, a way to remedy this as
game bugs are discovered is some form of Wiki that users can edit and
add information about game bugs.
This method could
be used to keep track of emulation-related game issues as well for the
various emulators for different consoles (could be extended to
Genesis/VBA/NES emulators too).
P.S. Blah, this is another dumb question (surprise, surprise as I don't
feel like searching through 200+ pages) but where do I find these WIPs?
Heh, I must of not been around for that one. Oh well. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Mar 16, 2008 7:02 pm Post subject: |
|
The WIPs are private; you can PM byuu if you want the link  |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Mar 16, 2008 7:15 pm Post subject: |
|
Verdauga Greeneyes wrote: |
The WIPs are private; you can PM byuu if you want the link  |
Thought so, thanks! I recall hearing about some incident a couple years ago about WIPs being reported on emulator news sites.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Mar 16, 2008 8:12 pm Post subject: |
|
grinvader wrote: |
henke37 wrote: |
The
official snes development book part 2 has a list of rules for combining
extension controllers. I would quote it if I where not stuck on my Wii,
feel free to do so in my place. |
...
Let's put it simply. On the real console nothing prevents you from
plugging any peripheral in a slot. it simply works or not depending
what it needs to work (for example the superscope can't latch if you
don't plug it in port 2, but the buttons are properly sent even if it's
on port 1 - so "something" could be made that uses a scope on port 1).
That's all there is to it. Emulate the device, emulate the port.
Forbidding combinations because you think it's not practical and/or
doesn't exist is about as retarded as not emulating some weird mosaic
behaviour because nothing ever used it.
|
You also completely forgot mentioning that some of what he listed as
"banned" existed in several games that were sold, while his super scope
+ multitap idea never did exist.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 5:55 am Post subject: |
|
Franky wrote: |
However,
I also heeded your advice and tried the hard-patched one (the one in
English that I show a YT vid of), that I'm having problems with on
bsnes, on a copier, and there are no problems. |
Franky wrote: |
But
it does work properly on a real snes using a copier, while it has that
glitch I reported on bsnes; if it works on the real thing, but not on
bsnes, then that's something that needs to be changed. |


Your turn.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Mar 17, 2008 6:04 am Post subject: |
|
I.S.T. wrote: |
You
can get 70% or more of the pieces needed just by fighting. It's
entirely possible to complete the puzzle without getting all of the
pieces found on the map. I did. |
Got to 1 piece left, and they just stopped dropping pieces. It was sad.
Yay bad luck!
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 17, 2008 7:52 am Post subject: |
|
Is
it possible that one copier is screwing up(Either by causing the glitch
or not showing it when it should be there.) and another isn't? |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Mar 17, 2008 7:55 am Post subject: |
|
I.S.T. wrote: |
Is
it possible that one copier is screwing up(Either by causing the glitch
or not showing it when it should be there.) and another isn't? |
How would the copier be able to do that without causing rampant corruption in everything else?
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 17, 2008 7:59 am Post subject: |
|
Gil_Hamilton wrote: |
I.S.T. wrote: |
Is
it possible that one copier is screwing up(Either by causing the glitch
or not showing it when it should be there.) and another isn't? |
How would the copier be able to do that without causing rampant corruption in everything else?
|
I thought of that, but I have no experience with copiers, hence the question. >.>
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 8:17 am Post subject: |
|
bsnes v0.029 released.
Quote: |
Changelog:
* Greatly improved invalid DMA transfer behavior, should be nearly perfect now
* Major code cleanup -- most importantly, almost all PPU timing-related settings moved back to PPU, from CPU
* Added option to auto-detect file type by inspecting file headers rather than file extensions
* Rewrote video filter system to move it out of the emulation core --
HQ2x and Scale2x will work even in hires and interlace modes now, 50%
scanline filter added
* Re-added bsnes window icon
* Added new controller graphic when assigning joypad keys [FitzRoy]
* Redundant "Advanced" panel settings which can be configured via the GUI are no longer displayed
* Improved speed regulation settings
* XP and Vista themes will now apply to bsnes controls
* Added "Path Settings" window to allow easy selection of default file directories
* Tab key now mostly works throughout most of the GUI (needs improvement)
* Main window will no longer disappear when setting a video multipler
which results in a window size larger than the current desktop
resolution
* Added two new advanced options: one to control GUI window opacity, and one to adjust the statusbar text |
---
Quote: |
Is
it possible that one copier is screwing up(Either by causing the glitch
or not showing it when it should be there.) and another isn't? |
Different copiers initialize memory and registers differently upon
power up, and my copier in particular asserts memory accesses that
should be open bus (bsnes does not), so there is some degree of
variance between copiers. And of course, the truly ignorant might try
running an NTSC game on PAL hardware, or vice versa.
bsnes, Snes9X and SNEeSe all exhibit the same behavior with the missing
characters and flickering; and both Super Sleuth and SNESGT show
flickering (though all characters are still visible); ZSNES is the only
emulator which runs the game with no flickering and all text visible.
Note that the first three emulators are known to properly block VRAM
writes outside of vblank, while the latter three are not.
EDIT:
... and sure enough, allowing VRAM writes during vblank results in the
text being visible (yet still flickering) in bsnes. It also works
flawlessly when run in PAL mode. Sigh ... I wanted to be polite about
this, but there's only three possibilities now, in increasing
likelihood:
1) Franky has the only SNES unit in the world that allows VRAM writes during active display.
2) He assumed that since it worked in other emulators, that it "had to
be a bug in bsnes," and lied about testing it on actual hardware.
3) He has a PAL SNES / copier, which is ... beyond words to use to test an NTSC game with. But then, "never assume malice" and all that ...
This "bug" is closed. The fan translation is defective, and this whole thing was a waste of time. Sigh, yet another reason to be even more skeptical of reports regarding unlicensed hacks in the future.
Last edited by byuu on Mon Mar 17, 2008 4:11 pm; edited 3 times in total
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 17, 2008 8:36 am Post subject: |
|
Stupid question: How do you turn on fullscreen? >.<
And thanks for the info, byuu. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 17, 2008 8:50 am Post subject: |
|
I.S.T. wrote: |
Stupid question: How do you turn on fullscreen? >.< |
Press F11, as you might in any web browser. Congrats on the release, byuu!
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Mar 17, 2008 8:51 am Post subject: |
|
byuu wrote: |
Even
noting the above, a difference such as this is highly unlikely. bsnes,
Snes9X and SNEeSe all exhibit the same behavior with the missing
characters and flickering; and both Super Sleuth and SNESGT show
flickering (though all characters are still visible); ZSNES is the only
emulator which runs the game with no flickering and all text visible.
Note that the first three emulators are known to properly block VRAM
writes outside of vblank, while the latter three are not.
It's obvious which emulator BST used to translate this game with. But
I'll wait for a picture of Franky's copier running the game before
saying anything more. |
http://www.romhacking.net/trans/401/
Well, SNEeSe and bsnes certainly aren't in the running, as they didn't EXIST back then.
I think it worked in SNES9x as well as ZSNES in 1999(at least until
Lavos emerged and killed us all), but I'm not inclined to hunt down an
absolutely ancient version of an emu I've never used regularly just for
the sake of checking whether a single hack worked right(or a specific
type of wrong, as it happens) back in the day.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 17, 2008 9:43 am Post subject: |
|
I went and edited that entry to reflect the new information about the intro.
Thank you for the info, Verdauga Greeneyes. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 17, 2008 4:25 pm Post subject: |
|
byuu wrote: |
3) He has a PAL SNES / copier, which is ... beyond words to use to test
an NTSC game with. But then, "never assume malice" and all that ...
|
I'm British, and yes, I have a PAL machine. That's probably why it
works for me (can't even get NTSC working on my machine. I'd need a
US/JPN console for that).
But man:
byuu wrote: |


|
On your snes, it does the same as in bsnes, which means bsnes is actually getting it right. Heh, my bad.
(Btw, I'm not ignorant just because I tried running an NTSC game on a
PAL console; I just don't have an NTSC console, and obviously can't get
NTSC working on my PAL console, that's all. Any other NTSC game I play
in PAL mode, well except for the (approx) 20% slow down, the game
usually plays just like it does in NTSX mode)
Now, I understand that I'm in the wrong here. Also, I'm arguing with
the person who made it possible for me to USE this wonderful emulator.
That's pretty harsh (being rude to a person who helps you), so I'll
shut up now.
I apologize for the trouble (that and unintentionally wasting your time).
Actually, I do feel a bit ignorant now >_<
(PS: I've just downloaded 0.029)
PS:
I'll delete that YT vid now.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 5:48 pm Post subject: |
|
Quote: |
(Btw,
I'm not ignorant just because I tried running an NTSC game on a PAL
console; I just don't have an NTSC console, and obviously can't get
NTSC working on my PAL console, that's all. Any other NTSC game I play
in PAL mode, well except for the (approx) 20% slow down, the game
usually plays just like it does in NTSX mode) |
Hah, called that one.
Yeah, I was being an ass, sorry. Spent two hours digging for the damned
camera USB cable before giving up and driving to the local 24hr
department store at 1AM to get one. Also delayed the release of v029
because I didn't want a known bug going out with it.
I kind of had higher expectations since you had an SNES copier, and
because of the relatively high knowledge of most posters here, but I
really shouldn't expect ordinary users to know internal hardware timing
differences, that's just simply not common knowledge. So I'll explain:
There is a world of difference
in timing between the NTSC and PAL SNES consoles. The 60 vs 50 frames
per second means vertical retrace time is greatly increased for PAL
games. PAL has 2 1/2 times more vblank time per frame. This creates major differences in games.
Under no circumstances should you even try and run NTSC games on your
PAL system. Even if they mostly work. Even if you've applied a bunch of
patches and things. It's a really, really bad idea. At the very least,
this is extremely important information to post before stating there's
definitely a bug in an emulator, but not hardware, that needs to be
fixed :/
This is a good learning lesson. Time to post an official "how to submit a bug report" guide on my website.
Quote: |
I apologize for the trouble (that and unintentionally wasting your time). |
Nah, don't worry about it. My time's no more valuable than yours, I was
just a bit ticked off last night. I appreciate you trying to report a
bug. If you run across any in PAL games, I'd be happy to take a look
for you. If I haven't scared you off, that is :)
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 17, 2008 5:56 pm Post subject: |
|
Ah, so it's all sweet then.
byuu wrote: |
Spent
two hours digging for the damned camera USB cable before giving up and
driving to the local 24hr department store at 1AM to get one. Also
delayed the release of v029 because I didn't want a known bug going out
with it. |
wow, now I am sorry for the trouble
Quote: |
The
60 vs 50 frames per second means vertical retrace time is greatly
increased for PAL games. PAL has 2 1/2 times more vblank time per
frame. This creates major differences in games.
|
Umm, isn't the 50/60 thing about the refresh rate in a TV?
I mean, NTSC goes at about 29.97 fps (I think, based on what I read
somewhere) on a 60hz refresh, while PAL goes exactly 25fps on a 50hz
refresh. Umm, well, could you explain?
so why do emulators call "fps" what would usually be the refresh rate in a TV?
(what you've told me is quite interesting btw)
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Mon Mar 17, 2008 6:09 pm Post subject: |
|
Great release. Only one thing:
Quote: |
*
Rewrote video filter system to move it out of the emulation core --
HQ2x and Scale2x will work even in hires and interlace modes now |
I can't get this particular feature to work. I tested Seiken Densetsu
3's title screen (that shows all the characters), which uses a Hi-Res
mode. The linear filter works, but not HQ2X/Scale2x. HQ2X/Scale2x still
only works in non-hi-res scenes. Perhaps I'm doing something wrong,
though.
I mentioned sometime before that bsnes is the only emulator that can
apply a filter to the screen at all (a linear filter). ZSNES will only
use automatic video card filtering/interpolation, which looks pixelated.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
Last edited by Clements on Mon Mar 17, 2008 6:15 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 6:15 pm Post subject: |
|
Quote: |
Umm, isn't the 50/60 thing about the refresh rate in a TV?
I mean, NTSC goes at about 29.97 fps (I think, based on what I read
somewhere) on a 60hz refresh, while PAL goes exactly 25fps on a 50hz
refresh. Umm, well, could you explain?
so why do emulators call "fps" what would usually be the refresh rate in a TV?
(what you've told me is quite interesting btw) |
The SNES runs at roughly the same speed, as the hardware is almost
identical. Because there are less frames per second on a PAL
television, that means there is more "blanking" time between frames.
Basically, after a TV draws the picture, it needs time to get the
electron beam cannon (the thing that draws the picture) back to the top
left of the screen for the next frame. On NTSC televisions with 60hz,
there's little time here. But because PAL televisions only run at 50hz,
that gives you a lot more time.
For NTSC and many PAL games, the vertical resolution is 224 scanlines.
The total frame time for NTSC is 262 scanlines, that gives you 38
scanlines of vertical blank time. For PAL, there are 312 scanlines,
giving you 88 scanlines of vblank.
With those numbers, you see that 262*60 ~= 312*50. The rest of the
difference is made up by infinitesimally tweaking the SNES processor
speed. Multiply those numbers by 1364 (SNES CPU clock cycles per
scanline) and you get the raw crystal clock speed (frequency) of the
processor. Divided by one million is the MHz speed.
Now, as for your 29.97 and 25 numbers ... those are interlaced frames
per second. What the SNES typically does, is draw every other
scanline on your screen. Each odd line just stays black. This is why
you can see "scanlines" on NTSC televisions. PAL TVs use some other
trick to reduce those. This is called progressive scan, and it can run
at ~60/50hz. However, when interlace is enabled, you basically draw
every other line of your
image in alternating frames. That is, rather than writing to the even
scanlines every frame, you write to the even ones the first line, and
the odd ones the second time, and repeat. You get twice the vertical
resolution, but half the speed.
Television and VHS are interlaced, so that is why you hear 29.97 and 25 so often.
Emulators call it FPS simply because of tradition. It could just as
easily be called Hz, but Hz can refer to any kind of counter. FPS is
easier for most to understand.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Mon Mar 17, 2008 6:19 pm Post subject: |
|
byuu wrote: |
Under
no circumstances should you even try and run NTSC games on your PAL
system. Even if they mostly work. Even if you've applied a bunch of
patches and things. It's a really, really bad idea. |
You mean for bug reporting purposes? I finished many an NTSC RPG on my
PAL system, and as far as simply playing the game goes, most of them
run 100% perfectly aside from the different game speed. Or is it
detrimental to the hardware in some way? I hope not. 
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 17, 2008 6:22 pm Post subject: |
|
Ah, I see, that's pretty interesting. I'll read up on a few articles on the net.
Byuu, you are a god. You always have an answer.
Hey, I have another question. Though it's only really used in France, what about SECAM?
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 6:30 pm Post subject: |
|
Quote: |
I
can't get this particular feature to work. I tested Seiken Densetsu 3's
title screen (that shows all the characters), which uses a Hi-Res mode.
The linear filter works, but not HQ2X/Scale2x. HQ2X/Scale2x still only
works in non-hi-res scenes. Perhaps I'm doing something wrong, though. |
I wasn't very clear on this change, sorry. I meant that the video
wouldn't get crushed in half, or not output at all, like on old
releases if you have one of those filters enabled. Maybe I made this
change in v028, though ... hmmm.
But only the NTSC filter will apply in mixed frame output, such as SD3
textboxes. The rest just default to nearest neighbor scale. I need to
basically write HQ2xV and Scale2xV subfilters (eg to scale 512x224
-> 512x448) to get those working like the NTSC filter.
Quote: |
I
mentioned sometime before that bsnes is the only emulator that can
apply a filter to the screen at all (a linear filter). ZSNES will only
use automatic video card filtering/interpolation, which looks pixelated. |
Doesn't ZSNES have the option of DR and D modes or somesuch, that allow
both nearest neighbor and linear interpolation? Perhaps I misunderstand.
Quote: |
You
mean for bug reporting purposes? I finished many an NTSC RPG on my PAL
system, and as far as simply playing the game goes, most of them run
100% perfectly aside from the different game speed. Or is it
detrimental to the hardware in some way? |
I doubt it will hurt the hardware, but it's self-defeating. I imagine
most people play games on their hardware because they want that totally
faithful, accurate representation. With timing off by that much, even
the worst emulators would be far more accurate.
The point is, you never know what will happen. Games that are very
simplistic will obviously continue to work, and glitches will mostly be
minor, but the last thing you want is your game to freeze three hours
into a scenario in Der Langrisser.
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Mon Mar 17, 2008 6:45 pm Post subject: |
|
Quote: |
Doesn't
ZSNES have the option of DR and D modes or somesuch, that allow both
nearest neighbor and linear interpolation? Perhaps I misunderstand. |
With the Windows version of ZSNES, there is software interpolation that
simply blurs the screen slightly - which works in all modes. The effect
is slightly more pronounced than automatic hardware filtering. The
Linux variant may be different (haven't tried it). The linear filter
with bsnes does a much better job at removing pixelation than software
interpolation, which is especially noticeable in hi-res scenes where
the scaling filters don't work.
I'm sure that someone will write a scaling filter in pixel shaders that doesn't have this issue.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Mon Mar 17, 2008 6:46 pm Post subject: |
|
byuu wrote: |
I
doubt it will hurt the hardware, but it's self-defeating. I imagine
most people play games on their hardware because they want that totally
faithful, accurate representation. With timing off by that much, even
the worst emulators would be far more accurate.
The point is, you never know what will happen. Games that are very
simplistic will obviously continue to work, and glitches will mostly be
minor, but the last thing you want is your game to freeze three hours
into a scenario in Der Langrisser. |
Haha well, this was a very long time ago and back then I just had no
choice but to play those games through a converter. CT, SoM and BoF all
work great right to the end. FF6 works pretty well too except there's
this weird bug where the item screen goes black under certain
circumstances, and the only way to bring it back to normal is to fight
a battle (obviously a pain when there's no battles to fight). And the
ending movie stops about halfway. But it's no great loss, and certainly
defeats not playing the game at all. :)
These days, of course, I only play them in NTSC mode on a modded SNES.
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Mon Mar 17, 2008 6:59 pm Post subject: |
|
blackmyst wrote: |
These days, of course, I only play them in NTSC mode on a modded SNES. |
I
was going to ask about that. What about a PAL SNES running at 60hz?
Will NTSC games run well while PAL games are likely to have glitches?
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 7:00 pm Post subject: |
|
Thanks for the new release.
I need to get my flash cart back, it seems. I've noticed that most of
the people on this board are in PAL locations. I'm one of the few NTSC
testers.
On one hand, you wish rom hackers would test on real hardware before
releasing, but on the other, these old translations probably had to
choose. Working on hardware is ideal so that your work doesn't one day
get broken by emulation improvements, but then if it didn't work in
emulators at the time, what is your audience going to do? Wait five
years for emulation to improve? Seems like the natural course for these
things. But nobody should be neglecting to do it these days, that's for
sure.
Last edited by FitzRoy on Mon Mar 17, 2008 7:05 pm; edited 1 time in total |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Mar 17, 2008 7:04 pm Post subject: |
|
blackmyst wrote: |
byuu wrote: |
I
doubt it will hurt the hardware, but it's self-defeating. I imagine
most people play games on their hardware because they want that totally
faithful, accurate representation. With timing off by that much, even
the worst emulators would be far more accurate.
The point is, you never know what will happen. Games that are very
simplistic will obviously continue to work, and glitches will mostly be
minor, but the last thing you want is your game to freeze three hours
into a scenario in Der Langrisser. |
Haha well, this was a very long time ago and back then I just had no
choice but to play those games through a converter. CT, SoM and BoF all
work great right to the end. FF6 works pretty well too except there's
this weird bug where the item screen goes black under certain
circumstances, and the only way to bring it back to normal is to fight
a battle (obviously a pain when there's no battles to fight). And the
ending movie stops about halfway. But it's no great loss, and certainly
defeats not playing the game at all. 
These days, of course, I only play them in NTSC mode on a modded SNES.
|
isn't the disapearing menu problem a bug in the game itself, and not related to playing it on a pal snes?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 7:10 pm Post subject: |
|
blackmyst wrote: |
Haha well, this was a very long time ago and back then I just had no
choice but to play those games through a converter. CT, SoM and BoF all
work great right to the end. FF6 works pretty well too except there's
this weird bug where the item screen goes black under certain
circumstances, and the only way to bring it back to normal is to fight
a battle (obviously a pain when there's no battles to fight). And the
ending movie stops about halfway. But it's no great loss, and certainly
defeats not playing the game at all. 
These days, of course, I only play them in NTSC mode on a modded SNES. |
Damn, I always forget that PAL people didn't get CT or the Final
Fantasies. It's just hard to imagine that pinnacles of the system could
actually go unreleased in one part of the world while utter crap gets
ported no problem. I'm glad the PAL/NTSC disconnect is finally over. I
think it really kept you guys from getting some great art (though that
may have been it's domestic agenda, I dunno... maybe I'm thinking of
SECAM).
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 17, 2008 7:23 pm Post subject: |
|
FitzRoy wrote: |
Damn,
I always forget that PAL people didn't get CT or the Final Fantasies.
It's just hard to imagine that pinnacles of the system could actually
go unreleased in one part of the world while utter crap gets ported no
problem. I'm glad the PAL/NTSC disconnect is finally over. I think it
really kept you guys from getting some great art (though that may have
been it's domestic agenda, I dunno... maybe I'm thinking of SECAM). |
On the upside, those games (FF3/6 and CT in particular) are what got me into emulation in the first place Aah, the days of the painfully unemulated sound effects in those games.. So nostalgic.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 7:28 pm Post subject: |
|
Oh, my bad, you guys did get Final Fantasy Legend. So not all Final Fantasies eluded you.  |
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Mon Mar 17, 2008 7:35 pm Post subject: |
|
Johan_H wrote: |
I
was going to ask about that. What about a PAL SNES running at 60hz?
Will NTSC games run well while PAL games are likely to have glitches? |
Yes,
I believe so. I think Gargoyle's Quest (or whatever the SNES version of
that game was called) transparent water that disappears when you run
the PAL version at 60hz.
tetsuo55 wrote: |
isn't the disapearing menu problem a bug in the game itself, and not related to playing it on a pal snes? |
I
don't think so, I remember checking those bugs specifically when I
first got to play the game in its intended region, and was pleased to
see them gone.
FitzRoy wrote: |
Damn,
I always forget that PAL people didn't get CT or the Final Fantasies.
It's just hard to imagine that pinnacles of the system could actually
go unreleased in one part of the world while utter crap gets ported no
problem. I'm glad the PAL/NTSC disconnect is finally over. I think it
really kept you guys from getting some great art (though that may have
been it's domestic agenda, I dunno... maybe I'm thinking of SECAM). |
Yeah,
it sucked. Well, at least I got to play them in some manner. I'm not
sure about any sort of domestic agenda though. And we did get
Terranigma, one of my favourite games ever, that you guys never got. ;D
FitzRoy wrote: |
Oh, my bad, you guys did get Final Fantasy Legend. So not all Final Fantasies eluded you.  |
You mean Mystic Quest? Hey, no dissing that game! 
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 17, 2008 7:42 pm Post subject: |
|
No, Legend was a GB game. A retitled SaGa, no less. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Mon Mar 17, 2008 7:47 pm Post subject: |
|
tetsuo55 wrote: |
blackmyst wrote: |
byuu wrote: |
I
doubt it will hurt the hardware, but it's self-defeating. I imagine
most people play games on their hardware because they want that totally
faithful, accurate representation. With timing off by that much, even
the worst emulators would be far more accurate.
The point is, you never know what will happen. Games that are very
simplistic will obviously continue to work, and glitches will mostly be
minor, but the last thing you want is your game to freeze three hours
into a scenario in Der Langrisser. |
Haha well, this was a very long time ago and back then I just had no
choice but to play those games through a converter. CT, SoM and BoF all
work great right to the end. FF6 works pretty well too except there's
this weird bug where the item screen goes black under certain
circumstances, and the only way to bring it back to normal is to fight
a battle (obviously a pain when there's no battles to fight). And the
ending movie stops about halfway. But it's no great loss, and certainly
defeats not playing the game at all. 
These days, of course, I only play them in NTSC mode on a modded SNES.
|
isn't the disapearing menu problem a bug in the game itself, and not related to playing it on a pal snes?
|
Nope.
The game may be glitchy, but it at least displays menus correctly.
|
|
blackmyst Inmate

Joined: 26 Sep 2004
Posts: 1637
Location: Place.
|
Posted: Mon Mar 17, 2008 8:04 pm Post subject: |
|
I.S.T. wrote: |
No, Legend was a GB game. A retitled SaGa, no less. |
Well, I know about the GB games, I just thought he might have meant MQ since we're talking about SNES games. :)
Johan_H wrote: |
I
was going to ask about that. What about a PAL SNES running at 60hz?
Will NTSC games run well while PAL games are likely to have glitches? |
Oh and PS: you can test this yourself in zsnes, since it has a force PAL/force NTSC option. I don't know if bsnes does, though.
_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 8:12 pm Post subject: |
|
Sorry, the full PAL name of the SNES one is Final Fantasy: Mystic Quest Legend. |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Mar 17, 2008 8:15 pm Post subject: |
|
I.S.T. wrote: |
No, Legend was a GB game. A retitled SaGa, no less. |
http://en.wikipedia.org/wiki/Final_Fantasy_Mystic_Quest
Mystic Quest legend was the name for that game in pal land, i actually
bought it when it was newish for only 5 euros!
See also this cart scan:
http://www.rpg-museum.com/bilder2/mqpal.JPG
the game was like a stripped down final fantasy 2, it was released
everywhere so people could learn how to play the RPG genre.
If the game didn't suck so much and had such low sales games like CT
and Earthbound would have been released in europe too....
Last edited by tetsuo55 on Mon Mar 17, 2008 8:20 pm; edited 1 time in total
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Mon Mar 17, 2008 8:19 pm Post subject: |
|
PAL
regions also missed several top tier PS2 RPG titles that were released
in the USA, such as Tales of the Abyss, Radiata Stories, Suikoden III,
Grandia III and probably others.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Mar 17, 2008 8:22 pm Post subject: |
|
Yeah
i really hate it how product marketers think europe and to a lesser
degree america are unable to deal with things like anime related rpg's
and religion related rpg's.
You'd think things
like bully and manhunt would get their heads straight and start
releasing all rpg's outside of japan |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 8:37 pm Post subject: |
|
Quote: |
I'm
not sure about any sort of domestic agenda though. And we did get
Terranigma, one of my favourite games ever, that you guys never got. ;D |

Quote: |
Oh and PS: you can test this yourself in zsnes, since it has a force PAL/force NTSC option. I don't know if bsnes does, though. |
Nope, have to change $xFD9 to do this. Didn't see a point in adding
this, or really, the allow up+down/left+right option. I just added the
latter because I like showing off the Zelda 3 exploit with it :)
But a force option would have to be in the UI directly ... and I don't
want to clutter that up with such a useless option. I don't know of a
single commercial game that has this value set incorrectly. Even the
betas with bad headers all work with a simple test.
Quote: |
Yeah
i really hate it how product marketers think europe and to a lesser
degree america are unable to deal with things like anime related rpg's
and religion related rpg's. |
If only Japanese weren't such a god-damned hard language to learn. Why
the hell couldn't Mexico be the RPG capital of the world? Their
language can be picked up in like six months ...
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Mar 17, 2008 8:42 pm Post subject: |
|
FitzRoy wrote: |
Damn, I always forget that PAL people didn't get CT or the Final
Fantasies. It's just hard to imagine that pinnacles of the system could
actually go unreleased in one part of the world while utter crap gets
ported no problem. I'm glad the PAL/NTSC disconnect is finally over. I
think it really kept you guys from getting some great art (though that
may have been it's domestic agenda, I dunno... maybe I'm thinking of
SECAM). |
why do you think the megadrive was so popular in pal regions 
also great release byuu, much kudos as usual.
byuu wrote: |
If only Japanese weren't such a god-damned hard language to learn. Why
the hell couldn't Mexico be the RPG capital of the world? Their
language can be picked up in like six months ... |
Indeed.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
Last edited by Panzer88 on Mon Mar 17, 2008 8:54 pm; edited 2 times in total
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Mon Mar 17, 2008 8:51 pm Post subject: |
|
byuu wrote: |

|
LOL!
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Mar 17, 2008 9:08 pm Post subject: |
|
honestly
whoever translated that... it must have been late at night for them not
to catch that. either that or they thought it was funny.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Mon Mar 17, 2008 9:32 pm Post subject: |
|
blackmyst wrote: |
Johan_H wrote: |
I
was going to ask about that. What about a PAL SNES running at 60hz?
Will NTSC games run well while PAL games are likely to have glitches? |
Oh and PS: you can test this yourself in zsnes, since it has a force PAL/force NTSC option.
|
Yeah, but it can's be switched after loading the ROM, to get around the startup check 
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Mar 17, 2008 9:44 pm Post subject: |
|
It could with some source changes very easily but what would be the point?
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Mar 17, 2008 10:44 pm Post subject: |
|
speaking of t shirts, that pic right there should be made into a t shirt.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Mon Mar 17, 2008 10:47 pm Post subject: |
|
Way
to go, Byuu! Version 0.29 runs fast on my computer; I have the NTSC
filter and 4x video size enabled! I get 60fps on all my games (like
Star Ocean); notably ones that didn't run that smooth before!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 11:01 pm Post subject: |
|
In
windows at least, an overkill multiplier now stretches to fit the
screen. Does it do the same in linux? If so, I can probably remove that
feature from the unsupported list. |
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Mon Mar 17, 2008 11:02 pm Post subject: |
|
pagefault wrote: |
It could with some source changes very easily but what would be the point? |
Fooling around with and testing sort of how games behave with a 50/60 switch on a real SNES. So nothing useful.
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 17, 2008 11:10 pm Post subject: |
|
Quote: |
You know, it's even funnier that his other hand is hidden. |
... even better :D
Quote: |
Way to go, Byuu! Version 0.29 runs fast on my computer |
Odd, v028 ran ~4-5% faster than v029. The CPU<>PPU isolation took
a small performance hit, because inlining isn't as trivial and it has
worse locality of code. Glad it's working good for you, though!
Quote: |
In windows at least, an overkill multiplier now stretches to fit the screen. Does it do the same in linux? |
Yes. The only problem with this is that it's hard to get fullscreen
when you have a really high resolution (eg 1920x1200), and on top of
that you really don't want fullscreen on a widescreen monitor. You need
the side black bars to get a proper aspect ratio.
The nice thing is that it does the same thing in windowed mode now,
too. No more "bsnes window is invisible" bugs :)
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Mon Mar 17, 2008 11:12 pm Post subject: |
|
Johan_H wrote: |
pagefault wrote: |
It could with some source changes very easily but what would be the point? |
Fooling around with and testing sort of how games behave with a 50/60 switch on a real SNES. So nothing useful.
|
Maybe I can add it to the developer tools but I wouldn't let a user change this in any way.
_________________
Watering ur plants.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 17, 2008 11:15 pm Post subject: |
|
byuu wrote: |
The nice thing is that it does the same thing in windowed mode now,
too. No more "bsnes window is invisible" bugs  |
Heck yeah, you killed two birds with one stone.
By the way, why did you tag the new options under advanced as "misc"
instead of "gui"? Don't you think something like gui.statusbar_text
would be more descriptive?
Last edited by FitzRoy on Mon Mar 17, 2008 11:19 pm; edited 1 time in total
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Mon Mar 17, 2008 11:19 pm Post subject: |
|
It
was odd that version 0.28 ran slower, but strangely enough, I haven't
noticed a single framerate decrease...Heck, fullscreen's amazing, too!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Mon Mar 17, 2008 11:20 pm Post subject: |
|
Thanks byuu for 0.029 and for continuing working on the emulator that revitalized (and dare I say revolutionize) Snes emulation.
Just one complain (ah, but we knew there'd be one):
As it is, it's not possible to combine both the NSRT filter plus the
scanline one, like it used to be. So if you could somehow make it
possible to allow these two at the same time that'd be great |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Mon Mar 17, 2008 11:32 pm Post subject: |
|
[quote="FitzRoy"]. And we did get Terranigma, one of my favourite games ever, that you guys never got. ;D
Interesting...funny that you say that; while we may have never gotten that game, I do have the ROM, so, I wasn't completely bereft of cool RPGs.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Mar 17, 2008 11:54 pm Post subject: |
|
neo_bahamut1985 wrote: |
Interesting...funny that you say that; while we may have never gotten
that game, I do have the ROM, so, I wasn't completely bereft of cool RPGs. |
I think he meant back in teh dayz, of course we can emulate stuff now,
but back then you were screwed (pronounce it screw-wed for emphasis)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 17, 2008 11:54 pm Post subject: |
|
Snark wrote: |
As
it is, it's not possible to combine both the NSRT filter plus the
scanline one, like it used to be. So if you could somehow make it
possible to allow these two at the same time that'd be great |
This is due to the way the filtering system was designed; however,
writing an OpenGL or DirectX GLSL scanline filter is easy, so once that
takes off it should no longer be an issue. If you want it now, see if
you can find mudlord's modified DirectX dll with a pack of example
shaders. It may even include a scanline filter, I'm not sure.
neo_bahamut, I think you mean
blackmyst wrote: |
And we did get Terranigma, one of my favourite games ever, that you guys never got. |
(not Fitzroy)
Last edited by Verdauga Greeneyes on Mon Mar 17, 2008 11:59 pm; edited 1 time in total
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Mon Mar 17, 2008 11:55 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Snark wrote: |
As
it is, it's not possible to combine both the NSRT filter plus the
scanline one, like it used to be. So if you could somehow make it
possible to allow these two at the same time that'd be great |
This is due to the way the filtering system was designed; however,
writing an OpenGL or DirectX GLSL scanline filter is easy, so once that
takes off it should no longer be an issue. If you want it now, see if
you can find mudlord's modified DirectX dll with a pack of example
shaders. It may even include a scanline filter, I'm not sure.
|
speaking of mudlord's shaders, what ever became of that.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Tue Mar 18, 2008 12:05 am Post subject: |
|
Verdauga Greeneyes wrote: |
Snark wrote: |
As
it is, it's not possible to combine both the NSRT filter plus the
scanline one, like it used to be. So if you could somehow make it
possible to allow these two at the same time that'd be great |
This is due to the way the filtering system was designed; however,
writing an OpenGL or DirectX GLSL scanline filter is easy, so once that
takes off it should no longer be an issue. If you want it now,
|
Oh no no..If it can be added eventually then it's fine by me.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Mar 18, 2008 12:58 am Post subject: |
|
Okay
this is getting ridiculous. For the past few days, every time I don't
look at this thread for a couple hours, it grows by 2-3 pages.
Catching up on all those pages, most of the posts aren't even bsnes related.
This is not RTTT, so cut it out.
Thank you.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding |
|
denzilla Rookie
Joined: 26 Sep 2004
Posts: 45
|
Posted: Tue Mar 18, 2008 1:48 am Post subject: |
|
Vista 64-bit SP1
X2 4400+ @ 2.2GHz
2GB Dual Channel DDR667
Radeon HD 3450 512 Meg
Realtek on board HD Audio
LG Flat panel 1280x1024 @ 60Hz
BSNES 0.29 Runs full speed according to the framecounter, but the
scrolling is very jerky in every game I've tried. Not that it makes a
difference, but ZSNES runs scrolls smooth as butter. Tried Windowed and
Fullscreen modes, btw. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Tue Mar 18, 2008 2:18 am Post subject: |
|
hey byuu, trying to build in linux here.
I am in a terminal in the bsnes_v029/src directory
but when I type
Quote: |
make PLATFORM=x-gcc-lui |
(what byuu has told me to input in the past)
it gives me this output
Quote: |
Usage: make platform=(os) compiler=(cc) [options]
Supported platforms:
x - Linux / BSD (x86, x86-64)
win - Windows (x86, x86-64)
Supported compilers:
gcc - GCC compiler
mingw32-gcc - MinGW compiler
i586-mingw32-gcc - MinGW cross compiler
cl - Visual C++
Available options:
enable_gzip=[true|false] - Enable ZIP / GZ support (default=false)
enable_jma=[true|false] - Enable JMA support (default=false)
Example: make platform=x compiler=gcc enable_gzip=true |
my friend who is more knowledgeable in the ways of Linux also tried to compile it but got these results
Quote: |
sanctuary::brian-> make platform=x compiler=gcc
g++ -O3 -fomit-frame-pointer -Ilib -c lib/ruby/audio/openal.cpp -o obj/audio.openal.o
lib/ruby/audio/openal.cpp:2:21: error: AL/alut.h: No such file or directory
lib/ruby/audio/openal.cpp:15: error: ISO C++ forbids declaration of 'ALCdevice' with no type
lib/ruby/audio/openal.cpp:15: error: expected ';' before '*' token
lib/ruby/audio/openal.cpp:16: error: ISO C++ forbids declaration of 'ALCcontext' with no type
lib/ruby/audio/openal.cpp:16: error: expected ';' before '*' token
lib/ruby/audio/openal.cpp: In member function 'bool ruby::pAudioOpenAL::init()':
lib/ruby/audio/openal.cpp:93: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:93: error: 'alcOpenDevice' was not declared in this scope
lib/ruby/audio/openal.cpp:94: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:94: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:94: error: ��alcCreateContext' was not declared in this scope
lib/ruby/audio/openal.cpp:95: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:95: error: 'alcMakeContextCurrent' was not declared in this scope
lib/ruby/audio/openal.cpp: In member function 'void ruby::pAudioOpenAL::term()':
lib/ruby/audio/openal.cpp:144: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:145: error: 'alcMakeContextCurrent' was not declared in this scope
lib/ruby/audio/openal.cpp:146: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:146: error: 'alcDestroyContext' was not declared in this scope
lib/ruby/audio/openal.cpp:147: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:150: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:151: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:151: error: 'alcCloseDevice' was not declared in this scope
lib/ruby/audio/openal.cpp:152: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp: In constructor 'ruby::pAudioOpenAL::pAudioOpenAL(ruby::AudioOpenAL&)':
lib/ruby/audio/openal.cpp:163: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:164: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:176: error: 'alutInit' was not declared in this scope
lib/ruby/audio/openal.cpp: In destructor 'ruby::pAudioOpenAL::~pAudioOpenAL()':
lib/ruby/audio/openal.cpp:181: error: 'alutExit' was not declared in this scope
make: *** [obj/audio.openal.o] Error 1 |
he hasn't ever used bsnes before though
I am running Kubuntu 7.10
He is running Arch Linux
EDIT:
when I input this
Quote: |
make platform=x compiler=gcc |
I get this
Quote: |
g++ -O3 -fomit-frame-pointer -Ilib -c ui/main.cpp -o obj/main.o
gcc -O3 -fomit-frame-pointer -Ilib -static -c lib/libco/libco.c -o obj/libco.o
g++ -O3 -fomit-frame-pointer -Ilib `pkg-config --cflags gtk+-2.0` -c lib/hiro/hiro.cpp -o obj/hiro.o
g++ -O3 -fomit-frame-pointer -Ilib -DVIDEO_GLX -DVIDEO_XV -DVIDEO_SDL
-DAUDIO_OPENAL -DAUDIO_OSS -DAUDIO_AO -DINPUT_SDL -DINPUT_X `sdl-config
--cflags` -c lib/ruby/ruby.cpp -o obj/ruby.o
/bin/sh: sdl-config: not found
In file included from lib/ruby/ruby_impl.cpp:16,
from lib/ruby/ruby.cpp:2:
lib/ruby/video/glx.cpp:26:19: error: GL/gl.h: No such file or directory
lib/ruby/video/glx.cpp:27:20: error: GL/glx.h: No such file or directory
In file included from lib/ruby/ruby_impl.cpp:20,
from lib/ruby/ruby.cpp:2:
lib/ruby/video/sdl.cpp:9:21: error: SDL/SDL.h: No such file or directory
In file included from lib/ruby/ruby_impl.cpp:38,
from lib/ruby/ruby.cpp:2:
lib/ruby/audio/openal.cpp:1:19: error: AL/al.h: No such file or directory
lib/ruby/audio/openal.cpp:2:20: error: AL/alc.h: No such file or directory
lib/ruby/video/glx.cpp:36: error: 'Bool' does not name a type
lib/ruby/video/glx.cpp:45: error: ISO C++ forbids declaration of 'Display' with no type
lib/ruby/video/glx.cpp:45: error: expected ';' before '*' token
lib/ruby/video/glx.cpp:47: error: 'Window' does not name a type
lib/ruby/video/glx.cpp:48: error: 'GLXContext' does not name a type
lib/ruby/video/glx.cpp:49: error: 'GLXWindow' does not name a type
lib/ruby/video/glx.cpp:50: error: 'GLuint' does not name a type
lib/ruby/video/glx.cpp:59: error: 'Window' does not name a type
lib/ruby/video/glx.cpp: In member function 'uintptr_t ruby::pVideoGLX::get(ruby::Video::Setting)':
lib/ruby/video/glx.cpp:70: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp: In member function 'bool ruby::pVideoGLX::set(ruby::Video::Setting, uintptr_t)':
lib/ruby/video/glx.cpp:77: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp: In member function 'void ruby::pVideoGLX::clear()':
lib/ruby/video/glx.cpp:97: error: 'glClearColor' was not declared in this scope
lib/ruby/video/glx.cpp:98: error: 'GL_COLOR_BUFFER_BIT' was not declared in this scope
lib/ruby/video/glx.cpp:98: error: 'glClear' was not declared in this scope
lib/ruby/video/glx.cpp:99: error: 'glFlush' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'glxwindow' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'glXSwapBuffers' was not declared in this scope
lib/ruby/video/glx.cpp: In member function 'void ruby::pVideoGLX::refresh(unsigned int, unsigned int)':
lib/ruby/video/glx.cpp:108: error: 'XWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:108: error: expected `;' before 'parent'
lib/ruby/video/glx.cpp:109: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:109: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp:109: error: 'parent' was not declared in this scope
lib/ruby/video/glx.cpp:109: error: 'XGetWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:110: error: 'xwindow' was not declared in this scope
lib/ruby/video/glx.cpp:110: error: 'child' was not declared in this scope
lib/ruby/video/glx.cpp:112: error: 'XResizeWindow' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_TEXTURE_2D' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_TEXTURE_WRAP_S' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_CLAMP_TO_EDGE' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'glTexParameteri' was not declared in this scope
lib/ruby/video/glx.cpp:116: error: 'GL_TEXTURE_WRAP_T' was not declared in this scope
lib/ruby/video/glx.cpp:117: error: 'GL_TEXTURE_MAG_FILTER' was not declared in this scope
lib/ruby/video/glx.cpp:118: error: 'GL_NEAREST' was not declared in this scope
lib/ruby/video/glx.cpp:118: error: 'GL_LINEAR' was not declared in this scope
lib/ruby/video/glx.cpp:119: error: 'GL_TEXTURE_MIN_FILTER' was not declared in this scope
lib/ruby/video/glx.cpp:122: error: 'GL_PROJECTION' was not declared in this scope
lib/ruby/video/glx.cpp:122: error: 'glMatrixMode' was not declared in this scope
lib/ruby/video/glx.cpp:123: error: 'glLoadIdentity' was not declared in this scope
lib/ruby/video/glx.cpp:124: error: 'glOrtho' was not declared in this scope
lib/ruby/video/glx.cpp:125: error: 'glViewport' was not declared in this scope
lib/ruby/video/glx.cpp:127: error: 'GL_MODELVIEW' was not declared in this scope
lib/ruby/video/glx.cpp:129: error: 'GL_UNPACK_ROW_LENGTH' was not declared in this scope
lib/ruby/video/glx.cpp:129: error: 'glPixelStorei' was not declared in this scope
lib/ruby/video/glx.cpp:132: error: 'GL_BGRA' was not declared in this scope
lib/ruby/video/glx.cpp:132: error: 'GL_UNSIGNED_INT_8_8_8_8_REV' was not declared in this scope
lib/ruby/video/glx.cpp:132: error: 'glTexSubImage2D' was not declared in this scope
lib/ruby/video/glx.cpp:142: error: 'GL_TRIANGLE_STRIP' was not declared in this scope
lib/ruby/video/glx.cpp:142: error: 'glBegin' was not declared in this scope
lib/ruby/video/glx.cpp:143: error: 'glTexCoord2f' was not declared in this scope
lib/ruby/video/glx.cpp:143: error: 'glVertex3i' was not declared in this scope
lib/ruby/video/glx.cpp:147: error: 'glEnd' was not declared in this scope
lib/ruby/video/glx.cpp:149: error: 'glFlush' was not declared in this scope
lib/ruby/video/glx.cpp:150: error: 'glxwindow' was not declared in this scope
lib/ruby/video/glx.cpp:150: error: 'glXSwapBuffers' was not declared in this scope
lib/ruby/video/glx.cpp: In member function 'bool ruby::pVideoGLX::init()':
lib/ruby/video/glx.cpp:154: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:154: error: 'XOpenDisplay' was not declared in this scope
lib/ruby/video/glx.cpp:155: error: 'DefaultScreen' was not declared in this scope
lib/ruby/video/glx.cpp:156: error: 'glXQueryVersion' was not declared in this scope
lib/ruby/video/glx.cpp:162: error: 'XWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:162: error: expected `;' before 'wa'
lib/ruby/video/glx.cpp:163: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp:163: error: 'wa' was not declared in this scope
lib/ruby/video/glx.cpp:163: error: 'XGetWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:168: error: 'GLX_RGBA' was not declared in this scope
lib/ruby/video/glx.cpp:169: error: 'GLX_DOUBLEBUFFER' was not declared in this scope
lib/ruby/video/glx.cpp:170: error: 'None' was not declared in this scope
lib/ruby/video/glx.cpp:172: error: 'XVisualInfo' was not declared in this scope
lib/ruby/video/glx.cpp:172: error: 'vi' was not declared in this scope
lib/ruby/video/glx.cpp:172: error: 'glXChooseVisual' was not declared in this scope
lib/ruby/video/glx.cpp:178: error: 'Colormap' was not declared in this scope
lib/ruby/video/glx.cpp:178: error: expected `;' before 'colormap'
lib/ruby/video/glx.cpp:179: error: 'XSetWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:179: error: expected `;' before 'swa'
lib/ruby/video/glx.cpp:180: error: 'swa' was not declared in this scope
lib/ruby/video/glx.cpp:180: error: 'colormap' was not declared in this scope
lib/ruby/video/glx.cpp:182: error: 'StructureNotifyMask' was not declared in this scope
lib/ruby/video/glx.cpp:183: error: 'xwindow' was not declared in this scope
lib/ruby/video/glx.cpp:183: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp:185: error: 'InputOutput' was not declared in this scope
lib/ruby/video/glx.cpp:186: error: 'CWColormap' was not declared in this scope
lib/ruby/video/glx.cpp:186: error: 'CWBorderPixel' was not declared in this scope
lib/ruby/video/glx.cpp:186: error: 'CWEventMask' was not declared in this scope
lib/ruby/video/glx.cpp:186: error: 'XCreateWindow' was not declared in this scope
lib/ruby/video/glx.cpp:187: error: 'XMapWindow' was not declared in this scope
lib/ruby/video/glx.cpp:188: error: 'XEvent' was not declared in this scope
lib/ruby/video/glx.cpp:188: error: expected `;' before 'event'
lib/ruby/video/glx.cpp:189: error: 'event' was not declared in this scope
lib/ruby/video/glx.cpp:189: error: 'x_wait_for_map_notify' was not declared in this scope
lib/ruby/video/glx.cpp:189: error: 'XIfEvent' was not declared in this scope
lib/ruby/video/glx.cpp:191: error: 'glxcontext' was not declared in this scope
lib/ruby/video/glx.cpp:191: error: 'GL_TRUE' was not declared in this scope
lib/ruby/video/glx.cpp:191: error: 'glXCreateContext' was not declared in this scope
lib/ruby/video/glx.cpp:192: error: 'glxwindow' was not declared in this scope
lib/ruby/video/glx.cpp:192: error: 'glXMakeCurrent' was not declared in this scope
lib/ruby/video/glx.cpp:196: error: 'glXGetConfig' was not declared in this scope
lib/ruby/video/glx.cpp:198: error: 'glXIsDirect' was not declared in this scope
lib/ruby/video/glx.cpp:201: error: 'GL_ALPHA_TEST' was not declared in this scope
lib/ruby/video/glx.cpp:201: error: 'glDisable' was not declared in this scope
lib/ruby/video/glx.cpp:202: error: 'GL_BLEND' was not declared in this scope
lib/ruby/video/glx.cpp:203: error: 'GL_DEPTH_TEST' was not declared in this scope
lib/ruby/video/glx.cpp:204: error: 'GL_POLYGON_SMOOTH' was not declared in this scope
lib/ruby/video/glx.cpp:205: error: 'GL_STENCIL_TEST' was not declared in this scope
lib/ruby/video/glx.cpp:208: error: 'GL_DITHER' was not declared in this scope
lib/ruby/video/glx.cpp:208: error: 'glEnable' was not declared in this scope
lib/ruby/video/glx.cpp:209: error: 'GL_TEXTURE_2D' was not declared in this scope
lib/ruby/video/glx.cpp:212: error: 'gltexture' was not declared in this scope
lib/ruby/video/glx.cpp:213: error: 'glGenTextures' was not declared in this scope
lib/ruby/video/glx.cpp:214: error: 'glBindTexture' was not declared in this scope
lib/ruby/video/glx.cpp:215: error: 'GL_UNPACK_ROW_LENGTH' was not declared in this scope
lib/ruby/video/glx.cpp:215: error: 'glPixelStorei' was not declared in this scope
lib/ruby/video/glx.cpp:217: error: 'GL_RGB' was not declared in this scope
lib/ruby/video/glx.cpp:219: error: 'GL_BGRA' was not declared in this scope
lib/ruby/video/glx.cpp:219: error: 'GL_UNSIGNED_INT_8_8_8_8_REV' was not declared in this scope
lib/ruby/video/glx.cpp:219: error: 'glTexImage2D' was not declared in this scope
lib/ruby/video/glx.cpp: In member function 'void ruby::pVideoGLX::term()':
lib/ruby/video/glx.cpp:225: error: 'gltexture' was not declared in this scope
lib/ruby/video/glx.cpp:226: error: 'glDeleteTextures' was not declared in this scope
lib/ruby/video/glx.cpp:230: error: 'glxcontext' was not declared in this scope
lib/ruby/video/glx.cpp:231: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:231: error: 'glXDestroyContext' was not declared in this scope
lib/ruby/video/glx.cpp: In constructor 'ruby::pVideoGLX::pVideoGLX(ruby::VideoGLX&)':
lib/ruby/video/glx.cpp:242: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp:243: error: 'xwindow' was not declared in this scope
lib/ruby/video/glx.cpp:244: error: 'glxcontext' was not declared in this scope
lib/ruby/video/glx.cpp:245: error: 'glxwindow' was not declared in this scope
lib/ruby/video/glx.cpp:246: error: 'gltexture' was not declared in this scope
lib/ruby/video/sdl.cpp: At global scope:
lib/ruby/video/sdl.cpp:21: error: ISO C++ forbids declaration of 'SDL_Surface' with no type
lib/ruby/video/sdl.cpp:21: error: expected ';' before '*' token
lib/ruby/video/sdl.cpp: In member function 'bool ruby::pVideoSDL::lock(uint32_t*&, unsigned int&)':
lib/ruby/video/sdl.cpp:46: error: 'buffer' was not declared in this scope
lib/ruby/video/sdl.cpp:46: error: 'SDL_MUSTLOCK' was not declared in this scope
lib/ruby/video/sdl.cpp:46: error: 'SDL_LockSurface' was not declared in this scope
lib/ruby/video/sdl.cpp:47: error: 'buffer' was not declared in this scope
lib/ruby/video/sdl.cpp: In member function 'void ruby::pVideoSDL::unlock()':
lib/ruby/video/sdl.cpp:52: error: 'buffer' was not declared in this scope
lib/ruby/video/sdl.cpp:52: error: 'SDL_MUSTLOCK' was not declared in this scope
lib/ruby/video/sdl.cpp:52: error: 'SDL_UnlockSurface' was not declared in this scope
lib/ruby/video/sdl.cpp: In member function 'void ruby::pVideoSDL::refresh(unsigned int, unsigned int)':
lib/ruby/video/sdl.cpp:62: error: 'SDL_Rect' was not declared in this scope
lib/ruby/video/sdl.cpp:62: error: expected `;' before 'src'
lib/ruby/video/sdl.cpp:64: error: 'src' was not declared in this scope
lib/ruby/video/sdl.cpp:69: error: 'dest' was not declared in this scope
lib/ruby/video/sdl.cpp:74: error: 'buffer' was not declared in this scope
lib/ruby/video/sdl.cpp:74: error: 'screen' was not declared in this scope
lib/ruby/video/sdl.cpp:74: error: 'SDL_SoftStretch' was not declared in this scope
lib/ruby/video/sdl.cpp:75: error: 'SDL_UpdateRect' was not declared in this scope
lib/ruby/video/sdl.cpp: In member function 'bool ruby::pVideoSDL::init()':
lib/ruby/video/sdl.cpp:83: error: 'SDL_INIT_VIDEO' was not declared in this scope
lib/ruby/video/sdl.cpp:83: error: 'SDL_InitSubSystem' was not declared in this scope
lib/ruby/video/sdl.cpp:84: error: 'screen' was not declared in this scope
lib/ruby/video/sdl.cpp:84: error: 'SDL_HWSURFACE' was not declared in this scope
lib/ruby/video/sdl.cpp:84: error: 'SDL_SetVideoMode' was not declared in this scope
lib/ruby/video/sdl.cpp:85: error: 'buffer' was not declared in this scope
lib/ruby/video/sdl.cpp:88: error: 'SDL_CreateRGBSurface' was not declared in this scope
lib/ruby/video/sdl.cpp: In member function 'void ruby::pVideoSDL::term()':
lib/ruby/video/sdl.cpp:93: error: 'SDL_INIT_VIDEO' was not declared in this scope
lib/ruby/video/sdl.cpp:93: error: 'SDL_QuitSubSystem' was not declared in this scope
lib/ruby/audio/openal.cpp: At global scope:
lib/ruby/audio/openal.cpp:15: error: ISO C++ forbids declaration of 'ALCdevice' with no type
lib/ruby/audio/openal.cpp:15: error: expected ';' before '*' token
lib/ruby/audio/openal.cpp:16: error: ISO C++ forbids declaration of 'ALCcontext' with no type
lib/ruby/audio/openal.cpp:16: error: expected ';' before '*' token
lib/ruby/audio/openal.cpp:17: error: 'ALuint' does not name a type
lib/ruby/audio/openal.cpp:18: error: 'ALenum' does not name a type
lib/ruby/audio/openal.cpp: In member function 'void ruby::pAudioOpenAL::sample(uint16_t, uint16_t)':
lib/ruby/audio/openal.cpp:62: error: 'ALuint' was not declared in this scope
lib/ruby/audio/openal.cpp:62: error: expected `;' before 'albuffer'
lib/ruby/audio/openal.cpp:65: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:65: error: 'AL_BUFFERS_PROCESSED' was not declared in this scope
lib/ruby/audio/openal.cpp:65: error: 'alGetSourcei' was not declared in this scope
lib/ruby/audio/openal.cpp:67: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:67: error: 'albuffer' was not declared in this scope
lib/ruby/audio/openal.cpp:67: error: 'alSourceUnqueueBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:68: error: 'alDeleteBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:76: error: 'albuffer' was not declared in this scope
lib/ruby/audio/openal.cpp:76: error: 'alGenBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:77: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'format'
lib/ruby/audio/openal.cpp:77: error: 'alBufferData' was not declared in this scope
lib/ruby/audio/openal.cpp:78: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:78: error: 'alSourceQueueBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:82: error: 'ALint' was not declared in this scope
lib/ruby/audio/openal.cpp:82: error: expected `;' before 'playing'
lib/ruby/audio/openal.cpp:83: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:83: error: 'AL_SOURCE_STATE' was not declared in this scope
lib/ruby/audio/openal.cpp:83: error: 'playing' was not declared in this scope
lib/ruby/audio/openal.cpp:83: error: 'alGetSourcei' was not declared in this scope
lib/ruby/audio/openal.cpp:84: error: 'AL_PLAYING' was not declared in this scope
lib/ruby/audio/openal.cpp:84: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:84: error: 'alSourcePlay' was not declared in this scope
lib/ruby/audio/openal.cpp: In member function 'bool ruby::pAudioOpenAL::init()':
lib/ruby/audio/openal.cpp:93: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:93: error: 'alcOpenDevice' was not declared in this scope
lib/ruby/audio/openal.cpp:94: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:94: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:94: error: 'alcCreateContext' was not declared in this scope
lib/ruby/audio/openal.cpp:95: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:95: error: 'alcMakeContextCurrent' was not declared in this scope
lib/ruby/audio/openal.cpp:96: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:96: error: 'alGenSources' was not declared in this scope
lib/ruby/audio/openal.cpp:99: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:99: error: 'AL_PITCH' was not declared in this scope
lib/ruby/audio/openal.cpp:99: error: 'alSourcef' was not declared in this scope
lib/ruby/audio/openal.cpp:100: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:100: error: 'AL_GAIN' was not declared in this scope
lib/ruby/audio/openal.cpp:101: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:101: error: 'AL_POSITION' was not declared in this scope
lib/ruby/audio/openal.cpp:101: error: 'alSource3f' was not declared in this scope
lib/ruby/audio/openal.cpp:102: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:102: error: 'AL_VELOCITY' was not declared in this scope
lib/ruby/audio/openal.cpp:103: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:103: error: 'AL_DIRECTION' was not declared in this scope
lib/ruby/audio/openal.cpp:104: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:104: error: 'AL_ROLLOFF_FACTOR' was not declared in this scope
lib/ruby/audio/openal.cpp:105: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:105: error: 'AL_SOURCE_RELATIVE' was not declared in this scope
lib/ruby/audio/openal.cpp:105: error: 'AL_TRUE' was not declared in this scope
lib/ruby/audio/openal.cpp:105: error: 'alSourcei' was not declared in this scope
lib/ruby/audio/openal.cpp:107: error: 'alListener3f' was not declared in this scope
lib/ruby/audio/openal.cpp:109: error: 'ALfloat' was not declared in this scope
lib/ruby/audio/openal.cpp:109: error: expected `;' before 'listener_orientation'
lib/ruby/audio/openal.cpp:110: error: 'AL_ORIENTATION' was not declared in this scope
lib/ruby/audio/openal.cpp:110: error: 'listener_orientation' was not declared in this scope
lib/ruby/audio/openal.cpp:110: error: 'alListenerfv' was not declared in this scope
lib/ruby/audio/openal.cpp: In member function 'void ruby::pAudioOpenAL::term()':
lib/ruby/audio/openal.cpp:125: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:125: error: 'alIsSource' was not declared in this scope
lib/ruby/audio/openal.cpp:125: error: 'AL_TRUE' was not declared in this scope
lib/ruby/audio/openal.cpp:127: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:127: error: 'AL_SOURCE_STATE' was not declared in this scope
lib/ruby/audio/openal.cpp:127: error: 'alGetSourcei' was not declared in this scope
lib/ruby/audio/openal.cpp:128: error: 'AL_PLAYING' was not declared in this scope
lib/ruby/audio/openal.cpp:129: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:129: error: 'alSourceStop' was not declared in this scope
lib/ruby/audio/openal.cpp:131: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:131: error: 'AL_BUFFERS_QUEUED' was not declared in this scope
lib/ruby/audio/openal.cpp:133: error: 'ALuint' was not declared in this scope
lib/ruby/audio/openal.cpp:133: error: expected `;' before 'albuffer'
lib/ruby/audio/openal.cpp:134: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:134: error: 'albuffer' was not declared in this scope
lib/ruby/audio/openal.cpp:134: error: 'alSourceUnqueueBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:135: error: 'alDeleteBuffers' was not declared in this scope
lib/ruby/audio/openal.cpp:140: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:140: error: 'alDeleteSources' was not declared in this scope
lib/ruby/audio/openal.cpp:141: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:144: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:145: error: 'alcMakeContextCurrent' was not declared in this scope
lib/ruby/audio/openal.cpp:146: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:146: error: 'alcDestroyContext' was not declared in this scope
lib/ruby/audio/openal.cpp:147: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:150: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:151: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:151: error: 'alcCloseDevice' was not declared in this scope
lib/ruby/audio/openal.cpp:152: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp: In constructor 'ruby::pAudioOpenAL::pAudioOpenAL(ruby::AudioOpenAL&)':
lib/ruby/audio/openal.cpp:162: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'source'
lib/ruby/audio/openal.cpp:163: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'handle'
lib/ruby/audio/openal.cpp:164: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'context'
lib/ruby/audio/openal.cpp:165: error: 'struct
ruby::pAudioOpenAL::<anonymous>' has no member named 'format'
lib/ruby/audio/openal.cpp:165: error: 'AL_FORMAT_STEREO16' was not declared in this scope
lib/ruby/input/sdl.cpp: At global scope:
lib/ruby/input/sdl.cpp:40: error: ISO C++ forbids declaration of 'SDL_Joystick' with no type
lib/ruby/input/sdl.cpp:40: error: expected ';' before '*' token
lib/ruby/input/sdl.cpp:41: error: 'SDL_Event' does not name a type
lib/ruby/input/sdl.cpp: In member function 'void ruby::pInputSDL::poll()':
lib/ruby/input/sdl.cpp:209: error: 'SDL_JoystickUpdate' was not declared in this scope
lib/ruby/input/sdl.cpp:216: error: 'joy' was not declared in this scope
lib/ruby/input/sdl.cpp:228: error: 'joy' was not declared in this scope
lib/ruby/input/sdl.cpp:228: error: 'SDL_JoystickNumAxes' was not declared in this scope
lib/ruby/input/sdl.cpp:230: error: 'SDL_JoystickGetAxis' was not declared in this scope
lib/ruby/input/sdl.cpp:241: error: 'SDL_JoystickGetButton' was not declared in this scope
lib/ruby/input/sdl.cpp: In member function 'bool ruby::pInputSDL::init()':
lib/ruby/input/sdl.cpp:247: error: 'SDL_INIT_JOYSTICK' was not declared in this scope
lib/ruby/input/sdl.cpp:247: error: 'SDL_InitSubSystem' was not declared in this scope
lib/ruby/input/sdl.cpp:248: error: 'SDL_IGNORE' was not declared in this scope
lib/ruby/input/sdl.cpp:248: error: 'SDL_JoystickEventState' was not declared in this scope
lib/ruby/input/sdl.cpp:250: error: 'SDL_NumJoysticks' was not declared in this scope
lib/ruby/input/sdl.cpp:251: error: 'joy' was not declared in this scope
lib/ruby/input/sdl.cpp:251: error: 'SDL_JoystickOpen' was not declared in this scope
lib/ruby/input/sdl.cpp: In member function 'void ruby::pInputSDL::term()':
lib/ruby/input/sdl.cpp:263: error: 'joy' was not declared in this scope
lib/ruby/input/sdl.cpp:263: error: 'SDL_JoystickClose' was not declared in this scope
lib/ruby/input/sdl.cpp:265: error: 'SDL_INIT_JOYSTICK' was not declared in this scope
lib/ruby/input/sdl.cpp:265: error: 'SDL_QuitSubSystem' was not declared in this scope
lib/ruby/input/sdl.cpp: In constructor 'ruby::pInputSDL::pInputSDL(ruby::InputSDL&)':
lib/ruby/input/sdl.cpp:269: error: 'joy' was not declared in this scope
make: *** [obj/ruby.o] Error 1 |
any ideas?
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Mar 18, 2008 6:41 am Post subject: |
|
Yes, fix your header files, you are missing at least one |
|
belegdol Rookie
Joined: 07 Dec 2004
Posts: 40
|
Posted: Tue Mar 18, 2008 10:52 am Post subject: |
|
byuu wrote: |
bsnes v0.029 released.
Quote: |
Changelog:
* Greatly improved invalid DMA transfer behavior, should be nearly perfect now
* Major code cleanup -- most importantly, almost all PPU timing-related
settings moved back to PPU, from CPU
* Added option to auto-detect file type by inspecting file headers rather than file extensions
* Rewrote video filter system to move it out of the emulation core --
HQ2x and Scale2x will work even in hires and interlace modes now, 50%
scanline filter added
* Re-added bsnes window icon
* Added new controller graphic when assigning joypad keys [FitzRoy]
* Redundant "Advanced" panel settings which can be configured via the GUI are no longer displayed
* Improved speed regulation settings
* XP and Vista themes will now apply to bsnes controls
* Added "Path Settings" window to allow easy selection of default file directories
* Tab key now mostly works throughout most of the GUI (needs improvement)
* Main window will no longer disappear when setting a video multipler
which results in a window size larger than the current desktop
resolution
* Added two new advanced options: one to control GUI window opacity,
and one to adjust the statusbar text |
|
I don't know if you touched openal since 0.028_01, but it works like
charm in Fedora ATM. It even plays nice with pulseaudio. In my
experience it works much better than with libao, so is it possible to
globally change the default setting (just in the package, of course)?
Also, would you be interested in a desktop entry so that bsnes will show up in menus? I have one ready. Cheers.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Tue Mar 18, 2008 1:39 pm Post subject: |
|
Panzer88 wrote: |
hey byuu, trying to build in linux here.
I am in a terminal in the bsnes_v029/src directory
but when I type
Quote: |
make PLATFORM=x-gcc-lui |
(what byuu has told me to input in the past)
it gives me this output
Quote: |
Usage: make platform=(os) compiler=(cc) [options]
Supported platforms:
x - Linux / BSD (x86, x86-64)
win - Windows (x86, x86-64)
Supported compilers:
gcc - GCC compiler
mingw32-gcc - MinGW compiler
i586-mingw32-gcc - MinGW cross compiler
cl - Visual C++
Available options:
enable_gzip=[true|false] - Enable ZIP / GZ support (default=false)
enable_jma=[true|false] - Enable JMA support (default=false)
Example: make platform=x compiler=gcc enable_gzip=true |
my friend who is more knowledgeable in the ways of Linux also tried to compile it but got these results
Quote: |
sanctuary::brian-> make platform=x compiler=gcc
g++ -O3 -fomit-frame-pointer -Ilib -c lib/ruby/audio/openal.cpp -o obj/audio.openal.o
lib/ruby/audio/openal.cpp:2:21: error: AL/alut.h: No such file or directory
[...] |
he hasn't ever used bsnes before though
I am running Kubuntu 7.10
He is running Arch Linux
EDIT:
when I input this
Quote: |
make platform=x compiler=gcc |
I get this
[...]
any ideas?
|
Point your Arch Linux friend here if he wants to use bsnes: http://aur.archlinux.org/packages.php?ID=11576.
As for you, you're missing headers as already stated. As you're using
an Ubuntu you probably want a bunch of -dev packages, ie sdl-dev (the
whole bunch of them I presume), freealut/openal dev packages, and
whatever package that provides glx headers (could be some mesa
package). I think byuu gave the command to install all the stuff needed
somewhere earlier in the thread.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Tue Mar 18, 2008 1:45 pm Post subject: |
|
I just got the game pack and guidebook, no idea a shirt was supposed to come with it 
_________________

<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: Tue Mar 18, 2008 2:12 pm Post subject: |
|

_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Tue Mar 18, 2008 2:53 pm Post subject: |
|
Panzer88,
you need to install OpenAL developement headers. I don't know which
package(s) you need to install since I'm not using Ubuntu. It should be
easy to figure out though.
Byuu, I wrote a little
about the makefile in the past and you vastly improved it right away.
Still a lot of unnecessary problems like this could be avoided if you
could somehow write a check (you wrote that you don't like configure
scripts) for OpenAL and perhaps for a few other headers.
I'll try 0.29 soon. Thank you for this awesome emulator. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Tue Mar 18, 2008 4:34 pm Post subject: |
|
denzilla wrote: |
Vista 64-bit SP1
X2 4400+ @ 2.2GHz
2GB Dual Channel DDR667
Radeon HD 3450 512 Meg
Realtek on board HD Audio
LG Flat panel 1280x1024 @ 60Hz
BSNES 0.29 Runs full speed according to the framecounter, but the
scrolling is very jerky in every game I've tried. Not that it makes a
difference, but ZSNES runs scrolls smooth as butter. Tried Windowed and
Fullscreen modes, btw. |
Sounds like a vsync issue to me.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 18, 2008 5:04 pm Post subject: |
|
Denzilla,
you may want to try what I posted a couple pages back: create a profile
for bsnes in your video card drivers that forces vsync on bsnes. It
works better for me than the internal setting for some reason. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Mar 18, 2008 5:20 pm Post subject: |
|
Or just turn vsync on in the advance settings, and change the cpu cycles to 21400000. Works great for me now. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 18, 2008 7:11 pm Post subject: |
|
FitzRoy wrote: |
Denzilla,
you may want to try what I posted a couple pages back: create a profile
for bsnes in your video card drivers that forces vsync on bsnes. It
works better for me than the internal setting for some reason. |
Fitzroy, did you ever try that tool I suggested, D3DOverrider? Actually
since you always get 60 fps it might not matter but for those who are
on the edge, triple buffering could make a difference.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 18, 2008 8:10 pm Post subject: |
|
No, I didn't. I'll have to try tonight. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Mar 18, 2008 8:35 pm Post subject: |
|
Verdauga Greeneyes wrote: |
FitzRoy wrote: |
Denzilla,
you may want to try what I posted a couple pages back: create a profile
for bsnes in your video card drivers that forces vsync on bsnes. It
works better for me than the internal setting for some reason. |
Fitzroy, did you ever try that tool I suggested, D3DOverrider? Actually
since you always get 60 fps it might not matter but for those who are
on the edge, triple buffering could make a difference.
|
It seems this is all for nvidia based cards. What about those of us with ati cards?
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 18, 2008 9:39 pm Post subject: |
|
FirebrandX wrote: |
It seems this is all for nvidia based cards. What about those of us with ati cards? |
D3DOverrider should work fine for ATI cards; it comes with RivaTuner
which, despite the name, has supported ATI cards for ages now. You need
it (if you want triple buffering) because DirectX doesn't officially
support it for some reason - but you can still make it work with this
program. By the way, I don't know the finer details of triple buffering
and vsync, but are you turning speed regulation off in bsnes when you
use them?
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Mar 18, 2008 9:57 pm Post subject: |
|
Yeah, I have the same issues with the screen tearing even if I force vsync/triple buffering? Where's the download for D3DOverrider?
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Mar 18, 2008 10:02 pm Post subject: |
|
Verdauga Greeneyes wrote: |
FirebrandX wrote: |
It seems this is all for nvidia based cards. What about those of us with ati cards? |
D3DOverrider should work fine for ATI cards; it comes with RivaTuner
which, despite the name, has supported ATI cards for ages now. You need
it (if you want triple buffering) because DirectX doesn't officially
support it for some reason - but you can still make it work with this
program. By the way, I don't know the finer details of triple buffering
and vsync, but are you turning speed regulation off in bsnes when you
use them?
|
Well I just now downloaded rivatuner, and after an hour of removing
Vista 64-bit's signed driver requirement bullshit, I manged to get
rivatuner installed. Problem is I see d3doverrider having no effect on
bsnes. I added the bsnes exe to its active profiles and checked on all
the tripple buffering a vsync options, but it appears to have no effect
on bsnes. Maybe I'm doing something wrong.
Last edited by FirebrandX on Tue Mar 18, 2008 10:02 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 18, 2008 10:02 pm Post subject: |
|
bsnes will sync to vblank / page flip already, if you ask it to.
Go to the advanced panel and set video.(windowed |
fullscreen).synchronize to true, and then disable speed regulation from
the menu. Your audio will now crackle, but the video will be smooth.
You can either mute audio, or screw with the cpu.(ntsc |
pal)_clock_speed setting to try and tune it to your monitor. Audio will
still crackle every now and then, but the closer your CPU frequency
value, the less crackling you'll get.
This really needs to be fixed ... and I've been going about it the
wrong way. I should make a separate program that outputs nothing but a
square wave at 32040hz, and video at 61fps, then force that to output
at 60hz + 32khz. Then we can all take a stab at it to find out what
works, and I can backport that into bsnes.
We'll put off that CPU<>PPU decoupling a little longer for this.
Quote: |
g++ -O3 -fomit-frame-pointer -Ilib -c ui/main.cpp -o obj/main.o
gcc -O3 -fomit-frame-pointer -Ilib -static -c lib/libco/libco.c -o obj/libco.o
g++ -O3 -fomit-frame-pointer -Ilib `pkg-config --cflags gtk+-2.0` -c lib/hiro/hiro.cpp -o obj/hiro.o
g++ -O3 -fomit-frame-pointer -Ilib -DVIDEO_GLX -DVIDEO_XV -DVIDEO_SDL
-DAUDIO_OPENAL -DAUDIO_OSS -DAUDIO_AO -DINPUT_SDL -DINPUT_X `sdl-config
--cflags` -c lib/ruby/ruby.cpp -o obj/ruby.o
/bin/sh: sdl-config: not found
In file included from lib/ruby/ruby_impl.cpp:16,
from lib/ruby/ruby.cpp:2:
lib/ruby/video/glx.cpp:26:19: error: GL/gl.h: No such file or directory
lib/ruby/video/glx.cpp:27:20: error: GL/glx.h: No such file or directory
In file included from lib/ruby/ruby_impl.cpp:20,
from lib/ruby/ruby.cpp:2:
lib/ruby/video/sdl.cpp:9:21: error: SDL/SDL.h: No such file or directory
In file included from lib/ruby/ruby_impl.cpp:38,
from lib/ruby/ruby.cpp:2:
lib/ruby/audio/openal.cpp:1:19: error: AL/al.h: No such file or directory
lib/ruby/audio/openal.cpp:2:20: error: AL/alc.h: No such file or directory
lib/ruby/video/glx.cpp:36: error: 'Bool' does not name a type
lib/ruby/video/glx.cpp:45: error: ISO C++ forbids declaration of 'Display' with no type
lib/ruby/video/glx.cpp:45: error: expected ';' before '*' token
lib/ruby/video/glx.cpp:47: error: 'Window' does not name a type
lib/ruby/video/glx.cpp:48: error: 'GLXContext' does not name a type
lib/ruby/video/glx.cpp:49: error: 'GLXWindow' does not name a type
lib/ruby/video/glx.cpp:50: error: 'GLuint' does not name a type
lib/ruby/video/glx.cpp:59: error: 'Window' does not name a type
lib/ruby/video/glx.cpp: In member function 'uintptr_t ruby::pVideoGLX::get(ruby::Video::Setting)':
lib/ruby/video/glx.cpp:70: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp: In member function 'bool ruby::pVideoGLX::set(ruby::Video::Setting, uintptr_t)':
lib/ruby/video/glx.cpp:77: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp: In member function 'void ruby::pVideoGLX::clear()':
lib/ruby/video/glx.cpp:97: error: 'glClearColor' was not declared in this scope
lib/ruby/video/glx.cpp:98: error: 'GL_COLOR_BUFFER_BIT' was not declared in this scope
lib/ruby/video/glx.cpp:98: error: 'glClear' was not declared in this scope
lib/ruby/video/glx.cpp:99: error: 'glFlush' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'glxwindow' was not declared in this scope
lib/ruby/video/glx.cpp:100: error: 'glXSwapBuffers' was not declared in this scope
lib/ruby/video/glx.cpp: In member function 'void ruby::pVideoGLX::refresh(unsigned int, unsigned int)':
lib/ruby/video/glx.cpp:108: error: 'XWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:108: error: expected `;' before 'parent'
lib/ruby/video/glx.cpp:109: error: 'display' was not declared in this scope
lib/ruby/video/glx.cpp:109: error: 'struct ruby::pVideoGLX::<anonymous>' has no member named 'handle'
lib/ruby/video/glx.cpp:109: error: 'parent' was not declared in this scope
lib/ruby/video/glx.cpp:109: error: 'XGetWindowAttributes' was not declared in this scope
lib/ruby/video/glx.cpp:110: error: 'xwindow' was not declared in this scope
lib/ruby/video/glx.cpp:110: error: 'child' was not declared in this scope
lib/ruby/video/glx.cpp:112: error: 'XResizeWindow' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_TEXTURE_2D' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_TEXTURE_WRAP_S' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'GL_CLAMP_TO_EDGE' was not declared in this scope
lib/ruby/video/glx.cpp:115: error: 'glTexParameteri' was not declared in this scope
lib/ruby/video/glx.cpp:116: error: 'GL_TEXTURE_WRAP_T' was not declared in this scope
lib/ruby/video/glx.cpp:117: error: 'GL_TEXTURE_MAG_FILTER' was not declared in this scope
lib/ruby/video/glx.cpp:118: error: 'GL_NEAREST' was not declared in this scope
lib/ruby/video/glx.cpp:118: error: 'GL_LINEAR' was not declared in this scope
lib/ruby/video/glx.cpp:119: error: 'GL_TEXTURE_MIN_FILTER' was not declared in this scope
lib/ruby/video/glx.cpp:122: error: 'GL_PROJECTION' was not declared in this scope
lib/ruby/video/glx.cpp:122: error: 'glMatrixMode' was not declared in this scope
... |

You need development headers.
libopenal-dev, libxv-dev, etc etc etc etc etc. There's lots of them,
and I don't recall their exact names or which ones you need. They're
usually pretty easy to find with a Google search. If you really get
stuck on one, I'll try and find the name for you.
Maybe I'll make a "sudo make ubuntu-devel" target to apt-get all of them for the next release.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Mar 18, 2008 11:18 pm Post subject: |
|
After
spending another hour trying different settings, I've determined d3d
overrider has ZERO effect on bsnes, at least in Vista 64-bit
environment. No matter what combination of vsync disabling and/or speed
regulation disabling I tried in bsnes, the results were exactly the
same as if d3d overrider was not running at all. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 18, 2008 11:28 pm Post subject: |
|
FirebrandX wrote: |
After
spending another hour trying different settings, I've determined d3d
overrider has ZERO effect on bsnes, at least in Vista 64-bit
environment. No matter what combination of vsync disabling and/or speed
regulation disabling I tried in bsnes, the results were exactly the
same as if d3d overrider was not running at all. |
Well, it's possible that it's not forcing vsync correctly; have you
tried enabling it from the ATI control panel? Other than that, you're
probably out of luck...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 18, 2008 11:49 pm Post subject: |
|
Yeah,
byuu's right. I use ATI Tray Tools to force vsync. At 60hz on my
monitor I get light crackling. At 75hz, I get no crackling. Slight
video stutter on both it seems, but tearing was gone.
The internal setting got frequent crackling at 60hz but had smooth
video. At 75hz, I gets no crackling and slight video stutter (dropped
frames?).
If you're running an LCD with DVI, you can't really get 75hz, so you're
probably unable or unwilling to get the better result. Anything over
60hz seemed to give the audio what it wanted, though. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Mar 19, 2008 12:10 am Post subject: |
|
But you want 60hz refresh since that is closest to the NTSC frame rate. Going to something like 75hz would ruin the whole idea.
It matters little though. I'll settle for the slight lowering of the
cpu cycle entry to get the best results I can with vsync on. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 12:12 am Post subject: |
|
FitzRoy wrote: |
Yeah,
byuu's right. I use ATI Tray Tools to force vsync. At 60hz on my
monitor I get light crackling. At 75hz, I get no crackling. Slight
video stutter on both it seems, but tearing was gone.
The internal setting got frequent crackling at 60hz but had smooth
video. At 75hz, I gets no crackling and slight video stutter (dropped
frames?).
If you're running an LCD with DVI, you can't really get 75hz, so you're
probably unable or unwilling to get the better result. Anything over
60hz seemed to give the audio what it wanted, though. |
Uh I can get 75hz with DVI just fine thanks for the misinformation.
_________________
Watering ur plants.
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Mar 19, 2008 12:16 am Post subject: |
|
byuu wrote: |
This
really needs to be fixed ... and I've been going about it the wrong
way. I should make a separate program that outputs nothing but a square
wave at 32040hz, and video at 61fps, then force that to output at 60hz
+ 32khz. Then we can all take a stab at it to find out what works, and
I can backport that into bsnes. |
Let me see if I have my facts straight. If you output at the exact same
speed as the SNES, but force video to the refresh-rate of the monitor,
you'll have to drop or double frames every now and then. Then for every
frame, you'll want to take 32040/[refresh-rate] samples and output
[output-frequency]/[refresh-rate] samples (forgetting about rounding
errors for a moment). Due to the nature of libco, the amount of samples
you have available at the right time varies wildly (?).
So, you add a buffer and a delay to ensure you always have enough
available to meet your quota (of 32040/[refresh-rate]), which you can
then resample; how big would this delay be/is this feasible?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 19, 2008 12:55 am Post subject: |
|
pagefault wrote: |
FitzRoy wrote: |
Yeah,
byuu's right. I use ATI Tray Tools to force vsync. At 60hz on my
monitor I get light crackling. At 75hz, I get no crackling. Slight
video stutter on both it seems, but tearing was gone.
The internal setting got frequent crackling at 60hz but had smooth
video. At 75hz, I gets no crackling and slight video stutter (dropped
frames?).
If you're running an LCD with DVI, you can't really get 75hz, so you're
probably unable or unwilling to get the better result. Anything over
60hz seemed to give the audio what it wanted, though. |
Uh I can get 75hz with DVI just fine thanks for the misinformation.
|
Limited to lower resolutions, right? Even then, 75hz support has been sketchy compared to CRT in any mode.
Quote: |
We logically came to ask ourselves about the optimum frequency of
normal LCDs. Most support 60 or 75 Hz. We did a blind test of 6
monitors at the two frequencies.
We found the following:
# 2 didn´t support 75 Hz and we would have a black or unstable image.
# 2 said that they supported 75 Hz, but when we measured the time
between images we realised that they were in fact at 60 Hz.
# Finally, the last two really ran at 75 Hz…partially. In fact the
monitors really displayed four images and then skipped the fifth. The
sixth one was displayed normally. When we looked at the results, we
realised that this skipped 5th image was to resynchronise the monitor
at 60Hz. In fact, it really displayed 4 images in 67 ms whether it was
at 60 or 75 Hz. We found the following. |
http://www.behardware.com/articles/641-5/1rst-lcd-at-100-hz-the-end-of-afterglow.html
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 12:59 am Post subject: |
|
FitzRoy wrote: |
Limited to lower resolutions, right? Even then, 75hz support has been sketchy compared to CRT in any mode.
of-afterglow.html |
If you call 1280x1024 a low resolution, it does 85hz.
_________________
Watering ur plants.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Wed Mar 19, 2008 3:37 am Post subject: |
|
byuu wrote: |

|
I hate to go off-topic, buuuuuuuuuuuuut...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 19, 2008 3:40 am Post subject: |
|
pagefault wrote: |
FitzRoy wrote: |
Limited to lower resolutions, right? Even then, 75hz support has been
sketchy compared to CRT in any mode.
of-afterglow.html |
If you call 1280x1024 a low resolution, it does 85hz.
|
Yeah, that's about as low as it gets for desktop LCD, barring 15" at
1024x768. All the 17 and 19 inchers are widescreen today at 1440x900.
My local stores haven't carried anything but widescreen for a long time.
...
Well, I missed getting in the surprise release, but here's the update...
|
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Wed Mar 19, 2008 3:43 am Post subject: |
|
creaothceann wrote: |
|
Yeah, my bad, mental hiccup there.
Quote: |
Let
me see if I have my facts straight. If you output at the exact same
speed as the SNES, but force video to the refresh-rate of the monitor,
you'll have to drop or double frames every now and then. |
Between tearing, audio crack and frame drop, I think frame drop would be the least annoying.
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Mar 19, 2008 5:03 am Post subject: |
|
I got a longer longcat:

Last edited by FirebrandX on Wed Mar 19, 2008 6:30 pm; edited 1 time in total |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Mar 19, 2008 5:38 am Post subject: |
|
ha
ha, I knew that last bit of the post was prolly unnecessary, I was a
bit mystified though because last installation of ubuntu I never had
that problem.
anyways, sorry for the mess, and
thanks for the tips, I'll get to it later, a friend from California
just dropped in by surprise for spring break so I've actually been
socializing for a change, anyways, thanks all again.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
denzilla Rookie
Joined: 26 Sep 2004
Posts: 45
|
Posted: Wed Mar 19, 2008 9:48 am Post subject: |
|
byuu wrote: |
bsnes will sync to vblank / page flip already, if you ask it to.
Go to the advanced panel and set video.(windowed |
fullscreen).synchronize to true, and then disable speed regulation from
the menu. Your audio will now crackle, but the video will be smooth.
You can either mute audio, or screw with the cpu.(ntsc |
pal)_clock_speed setting to try and tune it to your monitor. Audio will
still crackle every now and then, but the closer your CPU frequency
value, the less crackling you'll get.
This really needs to be fixed ... and I've been going about it the
wrong way. I should make a separate program that outputs nothing but a
square wave at 32040hz, and video at 61fps, then force that to output
at 60hz + 32khz. Then we can all take a stab at it to find out what
works, and I can backport that into bsnes. |
Are you saying that the SNES video output was 61fps? If that was the
case, wouldn't it have been incompatible with all NTSC TVs?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 19, 2008 12:43 pm Post subject: |
|
Well, spent my entire evening getting my Logitech G11 keyboard working under Xubuntu Linux.
Yes, you read that right. Setting up a fucking keyboard took me an entire day. With Xubuntu. The easiest Linux distro out there.
All I can say is -- if you're considering switching to Linux, you may want to read this article first:
http://byuu.cinnamonpirate.com/articles/logitech_g15/
Quote: |
Are you saying that the SNES video output was 61fps? If that was the case, wouldn't it have been incompatible with all NTSC TVs? |
The video output circuitry of the SNES controls the video timing, and
TVs, like monitors, are pretty tolerant to a wide range of settings.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 1:36 pm Post subject: |
|
FitzRoy wrote: |
pagefault wrote: |
FitzRoy wrote: |
Limited to lower resolutions, right? Even then, 75hz support has been
sketchy compared to CRT in any mode.
of-afterglow.html |
If you call 1280x1024 a low resolution, it does 85hz.
|
Yeah, that's about as low as it gets for desktop LCD, barring 15" at
1024x768. All the 17 and 19 inchers are widescreen today at 1440x900.
My local stores haven't carried anything but widescreen for a long time.
|
Uh... How about a math lesson?
1 400 * 960 = 1 344 000
1 280 * 1 024 = 1 310 720
You nearly have as many pixels as a widescreen. And I can run 1920x1080
at 85hz as well over DVI on a 24" panel. And for the lulz my 1280x800
res laptop screen is currently running at 75hz.
byuu wrote: |
Well, spent my entire evening getting my Logitech G11 keyboard working under Xubuntu Linux. |
Your fault for using Ubuntu to begin with.
_________________
Watering ur plants.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 19, 2008 3:13 pm Post subject: |
|
Single
link DVI has a bandwidth threshold and you might be able to run at a
higher refresh rate if you use a dual link cable, but the monitor and
video card first have to support it, and there's no guarantee that 75hz
is not simply going to skip or duplicate frames to get there. I don't
care what your monitor is telling you any more than if someone claimed
a record mile using teleporters. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 5:36 pm Post subject: |
|
FitzRoy wrote: |
Single
link DVI has a bandwidth threshold and you might be able to run at a
higher refresh rate if you use a dual link cable, but the monitor and
video card first have to support it, and there's no guarantee that 75hz
is not simply going to skip or duplicate frames to get there. I don't
care what your monitor is telling you any more than if someone claimed
a record mile using teleporters. |
Yes and I am using a dual link cable. There are no dropped "frames"
they are called fields for your information, it is progressive scan.
You are a moron if you think DVI is limited to 60hz and cannot support
higher you can do 1080p with a dual link cable which I do just fine on
my HDTV with my GeForce 8800. So please shut up unless you know what
you are talking about.
_________________
Watering ur plants.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 19, 2008 5:46 pm Post subject: |
|
Yeah,
8800's have built-in dual link support. I just got my 30" LCD to run at
2560x1600@100hz on one. Absolutely zero ghosting. All you need is a
high speed CCD camera to verify that it's really 100hz. Best of all,
the heat dissipation is even lower than the 35c I get on my Q6600 @
4.2GHz with stock cooler and 1.2V :D |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Wed Mar 19, 2008 6:26 pm Post subject: |
|
byuu wrote: |
Best of all, the heat dissipation is even lower than the 35c I get on my Q6600 @ 4.2GHz with stock cooler and 1.2V  |
Man I wish I could do that with stock cooling on my Q6600!
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 6:38 pm Post subject: |
|
byuu wrote: |
Yeah,
8800's have built-in dual link support. I just got my 30" LCD to run at
2560x1600@100hz on one. Absolutely zero ghosting. All you need is a
high speed CCD camera to verify that it's really 100hz. Best of all,
the heat dissipation is even lower than the 35c I get on my Q6600 @
4.2GHz with stock cooler and 1.2V  |
Impressive o/c. I am waiting on the 6 core CPU's myself for my next upgrade hehe.
_________________
Watering ur plants.
|
|
Johan_H Starzinger Addict

Joined: 17 Aug 2004
Posts: 715
Location: Sweden
|
Posted: Wed Mar 19, 2008 7:15 pm Post subject: |
|
FitzRoy wrote: |
 |
Nice, but I don't think the drop shadows from the buttons look natural, maybe blur them a little more?
_________________
There is always more than one way to look at things. Don't handicap yourself by only looking at it your way.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 19, 2008 7:41 pm Post subject: |
|
pagefault wrote: |
FitzRoy wrote: |
Single
link DVI has a bandwidth threshold and you might be able to run at a
higher refresh rate if you use a dual link cable, but the monitor and
video card first have to support it, and there's no guarantee that 75hz
is not simply going to skip or duplicate frames to get there. I don't
care what your monitor is telling you any more than if someone claimed
a record mile using teleporters. |
Yes and I am using a dual link cable. There are no dropped "frames"
they are called fields for your information, it is progressive scan.
You are a moron if you think DVI is limited to 60hz and cannot support
higher you can do 1080p with a dual link cable which I do just fine on
my HDTV with my GeForce 8800. So please shut up unless you know what
you are talking about.
|
Man, I'm confused. You seem so darned sure of yourself, but I thought
that fields were a product of interlaced content. Progressive scan like
LCD would thus update entire frames, not fields. I don't disagree that
proper reception of higher frequencies can improve perceived motion
smoothness in material that creates the new frames. What I'm trying to
say is that the internals of the monitor may not support it. Most
monitors today employ some kind of overdrive processing which are only
robustly designed for 60hz. I'm glad both you and byuu have really
high-end setups, but I just don't think this is the norm on which I
should take the other absolute.
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Wed Mar 19, 2008 7:44 pm Post subject: |
|
If it can be done then there is no reason to deny it.
_________________
Watering ur plants. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Mar 19, 2008 9:00 pm Post subject: |
|
Yes, I'll lay out the exceptions next time. |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Mar 19, 2008 9:10 pm Post subject: |
|
Regarding
the controller graphic (which is looking worlds better, nice work), the
longer you make the shadows below each button, the more it looks like
said button is floating above the controller, rather than being a pert
of said controller. More blur was one suggested option I think, but
really it seems like a much shorter shadow would help a lot. No reason
to have huge, stark visual effects on a nice, simple controller graphic.
And the buttons really are looking nicer. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Mar 19, 2008 9:38 pm Post subject: |
|
pagefault wrote: |
Impressive o/c. I am waiting on the 6 core CPU's myself for my next upgrade hehe. |
I hear Intel are working on 16-core processors. Imagine if, say, each
core ran at around 3ghz eventually. I think you should wait a a little
longer (seriously, imagine having a game that made use of 16 cores with
each one about 3ghz (and 32 logical cores btw), hardware optimizations
and all. Hell, imagine that many cores running at over 4ghz
(there are processors that at stock speed, go about 3.8ghz; and can
easily be overclocked to about 4.6 or beyond with the right cooling
system)). Sure, it would be expensive at first, but after a while it
would be quite affordable. And this will probably be a reality in about
5 years (think about what we had 5 years ago, and think about what we
have now; the rate at which hardware becomes more advanced, on it's
own, is always increasing).
Anyway yeah, I like to rant my incoherent thoughts.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Mar 19, 2008 10:01 pm Post subject: |
|
Franky wrote: |
I think you should wait a a little longer |
Except Nehalem is slated to be out later this year.
_________________
Why yes, my shift key *IS* broken.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Wed Mar 19, 2008 10:49 pm Post subject: |
|
Love the graphic!
One thing though, the buttons still look like orbs, while the real
buttons dip inwards. Anyways to reflect this? If so, then it'll be
perfect. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Mar 19, 2008 10:56 pm Post subject: |
|
King Of Chaos wrote: |
Love the graphic!
One thing though, the buttons still look like orbs, while the real
buttons dip inwards. Anyways to reflect this? If so, then it'll be
perfect.  |
Actually, the buttons are all convex on the SFC and PAL SNES
controllers. It's only on the US controller that two of the buttons are
concave.
FitzRoy - the buttons look MUCH better now, in my opinion. The shadow
from the D-pad might be a bit too big, though. I know I'm being picky
there, but it's only because the rest looks excellent!
_________________
Why yes, my shift key *IS* broken.
|
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 7:04 pm Post subject: |
|
I'm
getting a bit of audio static in the latest 0.029 (like it can't keep
up). I'm sure this has something to do with the changes in this
version. I noticed it in the character select screens of MK1 and MK2. I
still meet the recommended PC specs (C2D 2.4, 2GB etc. and latest
drivers). What strikes me is that some people say this version actually
runs faster (?). Using default settings.
_________________
"Change is inevitable; progress is optional" |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 7:12 pm Post subject: |
|
ShadowFX wrote: |
I'm
getting a bit of audio static in the latest 0.029 (like it can't keep
up). I'm sure this has something to do with the changes in this
version. I noticed it in the character select screens of MK1 and MK2. I
still meet the recommended PC specs (C2D 2.4, 2GB etc. and latest
drivers). What strikes me is that some people say this version actually
runs faster (?). |
Well.. have you tried disabling speed regulation and looking at the
frame rate you get? With your CPU it should be well above 60, so the
sound problem probably isn't related to that directly.
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 7:15 pm Post subject: |
|
I tried playing when disabled.
I'm getting 57/0 in the MK2 character select screen. Speed has
definitely been hit on my machine. No filters used and frameskip 0.
_________________
"Change is inevitable; progress is optional" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Mar 20, 2008 7:58 pm Post subject: |
|
Wow, that doesn't make sense. My 1.8ghz C2D pulls 60.
Got any background programs eating up cpu usage? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 8:16 pm Post subject: |
|
Yeah,
don't believe programs like BOINC or Folding@Home that say system
performance won't be effected. It may not effect it -much-, but
multitasking inherently has -an- effect. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Mar 20, 2008 8:33 pm Post subject: |
|
ShadowFX wrote: |
I tried playing when disabled.
I'm getting 57/0 in the MK2 character select screen. Speed has
definitely been hit on my machine. No filters used and frameskip 0. |
Sounds like a vsync/triple buffering issue.
_________________
Watering ur plants.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 20, 2008 8:41 pm Post subject: |
|
Quote: |
More blur was one suggested option I think, but really it seems like a much shorter shadow would help a lot. |
I hate to nitpick, but I'll have to agree. The shadow seems way too
large at the moment. But wow is the picture as a whole looking awesome.
It's going to present a real problem adding graphics in the future (as
they won't compare) -- I'll have to bug you to draw all of them or
something :D
Quote: |
I hear Intel are working on 16-core processors. |
Oh, good. I think that's the magic number where people will start
realizing that all of those extra cores are doing nothing but adding to
the price of their processors.
Quote: |
What strikes me is that some people say this version actually runs faster (?). |
It's odd to me, too. I get 5% slower speeds on every processor I try.
It's actually not even because of the CPU<>PPU changes, that sped
things up. The speed hit was from the pure C implementation of libco.
It still has ASM, but it's built with C. Since I can't use fastcall
(not portable to other architectures), it's a bit slower now. But
having libco as 100% C was very important for portability. For one, the
PS3 port should be directly compilable with no changes now. Just need
the libraries.
Eh, maybe I'll look into it a bit more. Speed is getting pretty bad
lately, I'm only getting ~80fps on Black Omen with my E6600 now.
Quote: |
I'm getting 57/0 in the MK2 character select screen. |
That's way too low. Do me a favor, try editing
Settings->Configuration->Advanced->system.video to
"directdraw" and restart. If that helps speed, let me know. It doubles
speed on this nVidia Vanta graphics card.
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 9:02 pm Post subject: |
|
FitzRoy wrote: |
Wow, that doesn't make sense. My 1.8ghz C2D pulls 60.
Got any background programs eating up cpu usage? |
Nothing significant. I also usually pulled 60/60 at least.
pagefault wrote: |
Sounds like a vsync/triple buffering issue. |
As far as I know, bsnes doesn't have these options. Neither is it forced through the Nvidia panel.
byuu wrote: |
That's
way too low. Do me a favor, try editing
Settings->Configuration->Advanced->system.video to
"directdraw" and restart. If that helps speed, let me know. It doubles
speed on this nVidia Vanta graphics card. |
No difference 
I'm using an Nvidia GeForce 7950GT with 169.21 drivers and DirectX Runtime March 2008 (Windows XP SP2).
Maybe it's an idea for you guys to check that particular spot (MK2
character select screen) I mentioned in my previous posts. I've already
seen it happening in more games though, so I guess it's 'system wide'
for me.
EDIT: I just tried to go back to v0.028 and everything is running perfect in this version!
_________________
"Change is inevitable; progress is optional"
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 9:28 pm Post subject: |
|
ShadowFX wrote: |
Nothing significant. I also usually pulled 60/60 at least.
As far as I know, bsnes doesn't have these options. Neither is it forced through the Nvidia panel.
I'm using an Nvidia GeForce 7950GT with 169.21 drivers and DirectX Runtime March 2008 (Windows XP SP2).
Maybe it's an idea for you guys to check that particular spot (MK2
character select screen) I mentioned in my previous posts. I've already
seen it happening in more games though, so I guess it's 'system wide'
for me.
EDIT: I just tried to go back to v0.028 and everything is running perfect in this version! |
Try to force vsync to 'off', also if you have anything like D3DOverrider running, turn the options off for bsnes.
Considering your graphics card, different scaling settings shouldn't matter as it's certainly good enough.
I don't suppose you have a motherboard with a ULi chipset and both an
AGP and a PCIe port and an AGP version of the GeForce card? (dunno if
there is one, but eh) If you do, do you have the motherboard drivers
installed? (specifically, the driver for the AGP bridge) Without them,
AGP will be limited to 1x.
Finally, how does your framerate change if you enable frame skipping? (with speed regulation off, obviously)
Oh, and just in case it could possibly, somehow matter, what's your soundcard? (or onboard sound chip)
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 20, 2008 9:38 pm Post subject: |
|
Quote: |
EDIT: I just tried to go back to v0.028 and everything is running perfect in this version! |
I'll look into it at home, but really ... not much has changed in
v0.029, just a few nicer options here and there. I'll have to recommend
staying with v028 for now. Or really, anything at or above v022, where
100% compatibility was reached. All the work I'm doing now is
theoretical. Fixing things that games don't use, to be that much more
faithful to hardware. And of course, nice little UI enhancements.
Or if you want, I can try sending you the WIPs to find out exactly
which version took the speed hit, to verify which change it was. Only
if you want to use v029, though. It doesn't seem to be affecting anyone
else, though I certainly don't mind tracking it down for you if you
like.
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 9:40 pm Post subject: |
|
Just to be more clear, it's not that I never reach 60/60, it's only in certain areas.
My motherboard only has PCIe and I have no tweak tools running in the
background of any kind. Vsync off didn't do anything also.
It seems that using anything but frameskip 0, results in 60/60 or
faster. Somehow, I can't pull full speed in certain areas of games on
frameskip 0 anymore in this version.
byuu wrote: |
Or
if you want, I can try sending you the WIPs to find out exactly which
version took the speed hit, to verify which change it was. Only if you
want to use v029, though. It doesn't seem to be affecting anyone else,
though I certainly don't mind tracking it down for you if you like. |
I'll be more than happy to try those out. I believe something happened
between 0.028 and 0.029 that resulted in this speed hit here.
_________________
"Change is inevitable; progress is optional"
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 10:21 pm Post subject: |
|
Thanks
for trying my suggestions. One thing I'm still curious about: what
framerate were you getting in 0.028? (uncapped obviously) Going by byuu
it should've been slightly higher than 80fps on Chrono Trigger's Black
Omen scene. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Thu Mar 20, 2008 10:43 pm Post subject: |
|
byuu wrote: |
That's
way too low. Do me a favor, try editing
Settings->Configuration->Advanced->system.video to
"directdraw" and restart. If that helps speed, let me know. It doubles
speed on this nVidia Vanta graphics card. |
Though this advice was for someone else, I tried it myself and now I
always get max speed (befrehand, it's drop down to about 57, and sound
would crackle, which was really annoying). Byuu, thank you.
Quote: |
Oh,
good. I think that's the magic number where people will start realizing
that all of those extra cores are doing nothing but adding to the price
of their processors. |
A program has to specifically run on a certain amount of threads, and
this has to be specified in the code. There's no way (yet) to make a
program detect how many cores are in a processor, and adjust itself to
run on that many more cores. But what if someone figures out how to do
that?
(PS: I've read this information elsewhere, so I don't know if it's accurate or not).
But then, think of the multi-tasking (though I agree with you that all
it's doing in the long term is make us waste our money).
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 20, 2008 11:29 pm Post subject: |
|
Franky wrote: |
A
program has to specifically run on a certain amount of threads, and
this has to be specified in the code. There's no way (yet) to make a
program detect how many cores are in a processor, and adjust itself to
run on that many more cores. But what if someone figures out how to do
that?
(PS: I've read this information elsewhere, so I don't know if it's accurate or not). |
In windows, one can use "%Number_of_Processors%" to find out how many
cores are installed. I'm sure there's a better way in code. Anyway, the
main problem is that not all code is easily parallelised, although
efforts are underway to allow compilers to take some of the effort away
from programmers. Even then, you face the law of diminishing returns.
For accurate emulation there's also the problem of synchronisation -
there's significant overhead to core-to-core communication currently,
though perhaps silicon photonics can alleviate this somewhat.
|
|
[vEX] Rookie
Joined: 03 Jun 2007
Posts: 49
Location: Sweden
|
Posted: Thu Mar 20, 2008 11:46 pm Post subject: |
|
Franky wrote: |
A
program has to specifically run on a certain amount of threads, and
this has to be specified in the code. There's no way (yet) to make a
program detect how many cores are in a processor, and adjust itself to
run on that many more cores. But what if someone figures out how to do
that?
(PS: I've read this information elsewhere, so I don't know if it's accurate or not). |
You decide what you what threaded and make it threaded (if possible),
then you let the OS worry about what CPU/core runs the thread.
Multi-threaded apps will run fine on single core CPUs, all threads are
just run on the same CPU. Can happen with multi-core CPUs as well, more
cores doesn't automatically means that each thread will be dedicated to
a core that runs that thread only.
_________________
MSI K8N NEO4-FI | AMD Athlon 64 3000+ 1.8GHz (Venice) | 2x1024MB PC3200
3-3-3-8 | Seagate Barracuda 7200.10 250GB SATA2 | MSI GeForce 7600GS
256MB | Pioneer DVR-112D | M-Audio DiO 2448 | Altec Lansing CS21 | Arch
Linux 64-bit
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 21, 2008 12:26 am Post subject: |
|
ShadowFX wrote: |
Maybe it's an idea for you guys to check that particular spot (MK2
character select screen) I mentioned in my previous posts. I've already
seen it happening in more games though, so I guess it's 'system wide'
for me.
|
Lowest dip in MK2 character screen, 1.86ghz C2D, speed regulation off:
.028: 60
.029: 65
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 21, 2008 1:37 am Post subject: |
|
MK2
character select screen: I get 81.5fps with v029, and 86fps with v028.
This is on an E6600. The Q6600 is in my roommate's PC. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Fri Mar 21, 2008 1:49 am Post subject: |
|
byuu wrote: |
Quote: |
I hear Intel are working on 16-core processors. |
Oh, good. I think that's the magic number where people will start
realizing that all of those extra cores are doing nothing but adding to
the price of their processors.
|
Except some of us actually do use the extra cores. I'm a professional
chess player and use multi-core chess programs for analysis of critical
positions. My current quad core is on average 13 times faster than my
old P4 for chess analysis.
So yes, if I had money falling out of my ass, you can bet I'd snag as many cores as I could.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 8:01 am Post subject: |
|
King Of Chaos wrote: |
Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. |
That exact spot is also giving me 57/60. What is going on here? We're talking a simple Mario game here.

Speed regulation Normal, Frameskip 0.
Using C2D E6600 2.4GHz (stock speed).
_________________
"Change is inevitable; progress is optional"
|
|
tcaudilllg2 Hazed
Joined: 20 Mar 2008
Posts: 78
|
Posted: Fri Mar 21, 2008 10:19 am Post subject: |
|
The
problem with multi-core is that the cores cannot communicate with each
other: they all have their own seperate little timelines. They're like
workers in an organization: you can delegate all you like, but in the
end everyone's going to have to do their own thing. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 21, 2008 10:54 am Post subject: |
|
ShadowFX wrote: |
King Of Chaos wrote: |
Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. |
That exact spot is also giving me 57/60. What is going on here? We're talking a simple Mario game here.
|
Doesn't stop the devs from being silly: It uses offset-per-tile values to show the lower right part of this tilemap.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 11:19 am Post subject: |
|
creaothceann wrote: |
ShadowFX wrote: |
King Of Chaos wrote: |
Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. |
That exact spot is also giving me 57/60. What is going on here? We're
talking a simple Mario game here.
|
Doesn't stop the devs from being silly: It uses offset-per-tile values to show the lower right part of this tilemap.
|
I'm not that good What does that all mean?
_________________
"Change is inevitable; progress is optional"
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Fri Mar 21, 2008 11:23 am Post subject: |
|
creaothceann wrote: |
ShadowFX wrote: |
King Of Chaos wrote: |
Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. |
That exact spot is also giving me 57/60. What is going on here? We're
talking a simple Mario game here.
|
Doesn't stop the devs from being silly: It uses offset-per-tile values to show the lower right part of this tilemap.
|
Jesus...
|
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Fri Mar 21, 2008 12:18 pm Post subject: |
|
Speed are fine here.

_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 21, 2008 12:26 pm Post subject: |
|
ShadowFX wrote: |
creaothceann wrote: |
ShadowFX wrote: |
King Of Chaos wrote: |
Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. |
That exact spot is also giving me 57/60. What is going on here? We're
talking a simple Mario game here.
|
Doesn't stop the devs from being silly: It uses offset-per-tile values
to show the lower right part of this tilemap.
|
I'm not that good What does that all mean?
|
Background modes 2, 4 and 6 have only 2 visible BG layers instead of 4
(Mode 0) or 3 (Mode 1). The space normally used for BG3 data contains
"H and V scrolling values individually for every tile on the scanline,
instead of globally for the entire scanline via the [scrolling]
registers" (quoted from anomie). This is what makes the "drugged Yoshi"
and "lava wave" effects of SMW2, the "individual column scrolling" of
Tetris Attack and the "Black Omen" effect of CT possible.
For the SMB2 title screen they could've just used the global scrolling
registers to show that part of the tilemap. Much easier to set up, and
better for emulation speed. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Mar 21, 2008 3:35 pm Post subject: |
|
Not
the title screen, the SMB2 character selection screen (and the bonus
level screens). Good news is I got a frame increase... bad news is it's
by one. 

It doesn't really bother me, since I get full speed on the rest of the game. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Fri Mar 21, 2008 3:54 pm Post subject: |
|
This is the lowest FPS I get for those specific character select screens with bsnes v0.029 without filters:
SMB2: 69 FPS with speed regulation disabled.
MKII: 66 FPS with speed regulation disabled.
This is with an Athlon64 X2 @ 2.5GHz.
_________________

ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Fri Mar 21, 2008 4:09 pm Post subject: |
|
o_O Why is everybody getting different frame rates?
SMB2 gives me a constant 108 FPS on the character select screen. MK2
gives me 103-108 on the character select screen. I'm running a Pentium
Dual-Core 2160(Core 2 based) at 3.0 GHZ. The chip normally runs at 1.8
GHZ.
2 gigs of DDR2 800 RAM running at 667 mhz. |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 4:17 pm Post subject: |
|
Clements wrote: |
This is the lowest FPS I get for those specific character select screens with bsnes v0.029 without filters:
SMB2: 69 FPS with speed regulation disabled.
MKII: 66 FPS with speed regulation disabled.
This is with an Athlon64 X2 @ 2.5GHz. |
Well this is certainly a surprise, an Athlon64 X2 beating my C2D with
those framerates? Either something is wrong with my setup (I recently
formatted though), or something unnoticed has changed since the last
bsnes version.
I tried it on my laptop which is also a C2D (T5500, 1.66GHz), and it
shows the same symptoms. If it's relevant, my PCs have Nvidia cards.
EDIT: Got my hands on a P4 3.0 GHz with a budget ATi X300 videocard and guess what, full speed and no framedrops under 60fps 
Also, I hope I didn't derail this thread too much with my posts. Thanks.
_________________
"Change is inevitable; progress is optional"
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Mar 21, 2008 4:59 pm Post subject: |
|
Guys,
posting results of one version is besides the point. The bug being
reported is why, for ShadowFX, the minimum fps on his box dropped
between .028 and .029 while for others it increased. If you want to
help, post what you get for both versions.
I am
using an Ati card with the latest drivers. Could this somehow be video
card related? Seems unlikely. But a good way to find out would be to
isolate the variable - install both types in the same box and compare
the results. Question is... who's got an nvidia and ati card? |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Mar 21, 2008 6:46 pm Post subject: |
|
Make sure you AMD guys get the "optmization" (microcode fix) for RDTSC on dual core Athlon 64s....
_________________
Watering ur plants. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 6:55 pm Post subject: |
|
Is that a hotfix for Windows or that 'Dual-Core Optimizer' AMD released?
On SMB2 I went from 69-71 on 0.028, to 68-70 on 0.029, on a 939 Athlon 64 X2 @ 2.5GHz.
My Core 2 Duo laptop I'm hesitant to test, as it's experiencing some stability issues.
Last edited by Verdauga Greeneyes on Fri Mar 21, 2008 7:19 pm; edited 2 times in total |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 7:33 pm Post subject: |
|
King Of Chaos wrote: |
Did a little tweaking...
...
All is well again.  |
Without telling exactly what you did. Maybe it'll be interesting for me too.
_________________
"Change is inevitable; progress is optional"
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 8:32 pm Post subject: |
|
King Of Chaos wrote: |
Simple. Changed the video filter from HQ2x to Scale2x and defaulted all advanced settings. |
Well I already had no filters on and the rest set to default. I guess my problem lies elsewhere.
_________________
"Change is inevitable; progress is optional"
|
|
Zelda64 New Member
Joined: 21 Mar 2008
Posts: 1
|
Posted: Fri Mar 21, 2008 8:44 pm Post subject: |
|
Hey
I was wondering when you can support the games that support the cheat
codes and also why can't I run this emulator on my EEE PC?
Thanks! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 21, 2008 9:20 pm Post subject: |
|
Zelda64 wrote: |
Hey
I was wondering when you can support the games that support the cheat
codes and also why can't I run this emulator on my EEE PC? |
Well for one thing the EEE PC is much too slow to run bsnes at full
speed. It should be possible to compile it for its operating system
though (Xandros Linux) if you're interested. And bsnes should support
cheat codes just fine, although I never really use them.. are you
having trouble?
Last edited by Verdauga Greeneyes on Fri Mar 21, 2008 9:22 pm; edited 1 time in total
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Mar 21, 2008 9:21 pm Post subject: |
|
Game Genie & Pro Action Replay cheat codes work fine for me. 
Out of curiosity, what game are you trying to cheat at, what format are
the codes, and what are the codes you're trying to use. I'll be glad to
test. 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Sat Mar 22, 2008 2:42 pm Post subject: |
|
Funny
thing; on the Mario 2 character selection screen, I get a full 60/60 on
version 0.21, but in version 0.29, it drops to 55/60 along with
crackling audio.
Edit 8:44AM - Weird. I did was King of Chaos did...changed the filter to ScaleX2 and the speed goes to 60/60!
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Mar 22, 2008 5:14 pm Post subject: |
|
Another
thing I've noticed on my system is that bsnes actually starts up slower
than 0.028 and below. The GUI is also a bit less responsive. This is
without running any skins of some sort.
Again, nothing strange is running in the background, as far as I know.
_________________
"Change is inevitable; progress is optional" |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sat Mar 22, 2008 5:32 pm Post subject: |
|
neo_bahamut1985 wrote: |
Edit 8:44AM - Weird. I did was King of Chaos did...changed the filter to ScaleX2 and the speed goes to 60/60! |
I think HQ2x is the culprit there. It might need some optimizing, or
it's probably too much for it to handle at full speed.
ShadowFX wrote: |
Another
thing I've noticed on my system is that bsnes actually starts up slower
than 0.028 and below. The GUI is also a bit less responsive. This is
without running any skins of some sort.
Again, nothing strange is running in the background, as far as I know. |
Interesting. Would you mind telling us your specs for your system? Like
what CPU, graphics card, operating system, etc. I might have some ideas
to try.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 22, 2008 5:54 pm Post subject: |
|
The
filter is already quite optimised, but it's pretty complex. It would be
nice if we could offload it to the graphics card, but from what I saw
it's a bit too complex to be speedy as a shader. So currently, after
facing the challenge of a frame in bsnes, your CPU must also apply the
filter.
Edit: by the way, perhaps we should move this to its own thread now that we can. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sat Mar 22, 2008 5:57 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Edit: by the way, perhaps we should move this to its own thread now that we can. |
Already tried, cannot allocate enough memory to moderate this thread (and hence split posts to where they belong).
What I *could* do is go back and erase EVERY unimportant post. Then the
thread would become fairly manageable, but the splitting would get
slightly pointless, since everything of no importance would be gone
already.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Sat Mar 22, 2008 6:38 pm Post subject: |
|
King Of Chaos wrote: |
Interesting.
Would you mind telling us your specs for your system? Like what CPU,
graphics card, operating system, etc. I might have some ideas to try. |
- Core 2 Duo 2.4 GHz (stock, I don't have it overclocked at this time)
- 2 GB DDR2-RAM (800)
- Nvidia GeForce 7950GT (not overclocked, 169.21 drivers)
- SB X-Fi Platinum soundcard
- Windows XP SP2 (Fully updated)
- DirectX Runtime (March 2008)
- Asus P5W DH Deluxe (BIOS 2606, latest)
- WD Raptor (for a bit faster OS booting etc.)
Hopefully that's enough.
_________________
"Change is inevitable; progress is optional"
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 22, 2008 6:49 pm Post subject: |
|
grinvader wrote: |
Already tried, cannot allocate enough memory to moderate this thread (and hence split posts to where they belong). |
Aah, so that's what you tried. Well, perhaps we could still start a new
thread, so long as the introductory post is good and everyone is aware
of it (i.e. people are reading our posts )
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Sun Mar 23, 2008 11:18 pm Post subject: DSP 1 and Filters |
|
Hi byuu,
I was just testing out the dsp snes games and came across Suzuka 8 Hours (U).smc.
I think that it is a dsp-1 game but I do not know if it used a newer
version A or B chip. Also I tried running it on hardware using either a
pilot wings or mariokart dsp chip and it did not run. The reason I
am asking about this is that the timer runs really fast in the time
trial, and the motor bike moves really slow, as if the timings for the
clock counter and the timer for the gfx have been swapped round!
I was wondering if anyone on this forum owns the original cartridge and
can test it out to see if indeed the clock counts that fast and the
bike moves that slow.
p.s you have to do 1 lap in time trial before the time starts counting up...
Also I was messing about with the scanline code src/lib/libfilter/scanline.cpp:
Code: |
for(unsigned y = 0; y < height; y++) {
uint32_t *out0 = output;
if(width == 512 && line[y] == 256) {
for(unsigned x = 0; x < 256; x++) {
uint16_t p = *input++;
*out0++ = colortable[p];
*out0++ = colortable[p];
}
input += 256;
} else {
for(unsigned x = 0; x < width; x++) {
uint16_t p = *input++;
*out0++ = colortable[p];
}
}
input += pitch - width;
output += outpitch * 2;
} |
As you can see I deleted the lines that plot the out1 scanlines for a
hefty speedup on my system, every other line is skipped and left black.
The problem is when I swap in and out of the filter none and scanlines
options, I can see garbage left on the screen (because I am skipping
the plotting of these scanlines).
This must be happening with every filter, but you will never see it
because you do not skip any scan lines when you are plotting the
filters.
Obviously if this is intentional, I am sorry for wasting your time, but
I thought it would be worth pointing this out to you if you did not
know...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 12:45 am Post subject: Re: DSP 1 and Filters |
|
This inspired me to get off my ass and write a simple scanline shader that matches bsnes' Paste the following into a file called 'fakehdr.fx' and place it in the same folder as bsnes. You'll need mudlord's modified d3d9.dll
there as well. Obviously, this will only work in Windows with DirectX 9
and a pixel shader 2 or higher supporting graphics card.
Code: |
texture tex1;
float2 rcpres;
sampler s0 = sampler_state{ texture = <tex1>; };
int ToggleKey = 107;
float4 NormalColourPass(): COLOR0{ return float4(0.,0.,0.,0.); }
float4 ScanlinePass(in float2 Tex : TEXCOORD0): COLOR0
{ float4 color = tex2D(s0,Tex);
float yCoord = floor(448.*Tex.y);
if(fmod(yCoord,2.) == 1.) color *= .5;
return color;
}
Technique T0
{ pass p0{ PixelShader = compile ps_2_0 NormalColourPass(); }
pass p1{ PixelShader = compile ps_2_0 ScanlinePass(); }
}
|
(don't ask me why p0 is needed.. It doesn't seem to matter what's in
there, but the shader does nothing if it doesn't exist in some valid
form)
|
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Mon Mar 24, 2008 5:46 am Post subject: |
|
Nice job on the shader!
I'll try it out in Rice Video when I have the chance.
The main issue with the 2 shader passes is due to how the internal
shader parser in my DLL operates. Mainly, its a side effect of the HDR
support which needs 2 passes (one on the normal rendertarget, the other
on the previous frame render buffer). If I can work out a way to filter
without relying on one pass to init the render targets, maybe we can
remove that requirement. I'm looking to add vertex shader support, too. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 10:21 am Post subject: |
|
mudlord wrote: |
Nice job on the shader!
I'll try it out in Rice Video when I have the chance.
The main issue with the 2 shader passes is due to how the internal
shader parser in my DLL operates. Mainly, its a side effect of the HDR
support which needs 2 passes (one on the normal rendertarget, the other
on the previous frame render buffer). If I can work out a way to filter
without relying on one pass to init the render targets, maybe we can
remove that requirement. I'm looking to add vertex shader support, too. |
Cool, thanks again for your work on this! I'll have to have a look at
that HDR shader to see how it works. Hmm.. it should be relatively easy
to make a 2xSaI shader now, based on the existing GLSL one I helped
optimise. Perhaps a new thread would be a good idea, to discuss
licensing issues as well as ease distribution.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 24, 2008 7:52 pm Post subject: |
|
Ok,
found a new slowdown for you guys to play with and test (happens even
with Scale2x enabled, and no filters at all). Load up Super Mario
All-Stars, select SMB3, and try the battle mode. The FPS drops down to
around 52/53/54.

_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 24, 2008 7:56 pm Post subject: |
|
Not happening here. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 24, 2008 8:30 pm Post subject: |
|
Let
me try to explain to people how to view speed in bsnes. Certain scenes
in games do things which are more processor intensive in the emulation
sense.
Let's say you've got a 1.6ghz Core 2 Duo,
and your speed regulation is not capped. In SMB all stars, the lowest
fps you get is 50, but in most scenes you get around 80. So your spread
is 50-80. When speed regulation is enabled, your spread is reduced to
50-60. Enabling speed regulation won't help your dip to 50, all it does
it cap anything above it.
Now let's say you had a 2.4ghz version of the same chip and your spread
becomes 75-120. You are still taking the same hit on that scene
relative to your processor speed. But since your processor is faster,
the minimum fps is above 60. So your spread with speed regulation
enabled is 60-60 - you don't get any drops below 60 even though the
performance hit is still happening.
So we know that games have intensive scenes that can hit performance.
That's why when we test, we use Chrono Trigger's intro "black omen"
scene as a benchmark. It's the slowest scene we know of. Unless you
find a game that performs worse than that scene on your system, we
really don't need to know. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 24, 2008 8:59 pm Post subject: |
|
Quote: |
Unless you find a game that performs worse than that scene on your system, we really don't need to know. |
Exactly. CT Black Omen should always be tested. If you can get > 60fps, then you won't have any speed issues.
All of these different games simply use OPT. You can't tell from looking at the pictures, but they do.
OPT is so slow because we have to fetch the BG tile once (for mode 4)
and twice (for modes 2, 6; 2 is the most commonly used) for each pixel
output. Though bg_get_tile is insanely well optimized, it's still slow
due to the sheer number of times it must be called per second.
Code: |
uint16 bPPU::bg_get_tile(uint8 bg, uint16 x, uint16 y) {
x = (x & bg_info[bg].mx) >> bg_info[bg].tw;
y = (y & bg_info[bg].my) >> bg_info[bg].th;
uint16 pos = ((y & 0x1f) << 5) + (x & 0x1f);
if(y & 0x20) pos += bg_info[bg].scy;
if(x & 0x20) pos += bg_info[bg].scx;
uint16 addr = regs.bg_scaddr[bg] + (pos << 1);
//vram_read(n) is inlined to vram[n];
return (vram_read(addr + 0) << 0) | (vram_read(addr + 1) << 8);
} |
With OPT off, bg_get_tile() only needs to be called once per tile. It's
cached because hoffset and voffset can be tested quite easily to
determine when we're on an actual new tile to fetch only then.
In reality, some optimizations can probably be performed on the OPT to
cache those fetches ... I haven't really looked into it. I'm hesitant
to optimize it much as it affects so few scenes, and the optimizations
may introduce new bugs.
Last edited by byuu on Mon Mar 24, 2008 10:15 pm; edited 2 times in total
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 9:05 pm Post subject: |
|
So the Black Omen you guys mention, is that the one you see in the intro of the game?
_________________
"Change is inevitable; progress is optional" |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 24, 2008 9:15 pm Post subject: |
|
It's the same effect either way, but obviously the intro is faster to test.
EDIT: Might be interesting to test the "drugged Yoshi" effect in
SMW2... although that would require SuperFX support.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 24, 2008 9:38 pm Post subject: |
|
Okay,
since OPT is dropping a lot of people just at the fringe of fullspeed
below 60fps, here's an optimized OPT routine, which will cache the BG
tiles whenever possible:
Code: |
//scrolling
regs are 13-bit, should not be possible to get current_N = 0xffff; so
this basically says "first tile is always going to be invalid (and thus
need to be fetched)"
uint16 prev_x = 0xffff, prev_y = 0xffff, prev_optx = 0xffff;
for(uint16 x = 0; x < width; x++) {
hoffset = mtable[x] + hscroll;
voffset = y + vscroll;
if(is_opt_mode) {
opt_x = (x + (hscroll & 7));
//tile 0 is unaffected by OPT mode...
if(opt_x >= 8) {
if((opt_x >> 3) != (prev_optx >> 3)) {
hval = bg_get_tile(BG3, (opt_x - 8) + (regs.bg_hofs[BG3] & ~7), regs.bg_vofs[BG3]);
if(regs.bg_mode != 4) {
vval = bg_get_tile(BG3, (opt_x - 8) + (regs.bg_hofs[BG3] & ~7), regs.bg_vofs[BG3] + 8);
}
prev_optx = opt_x;
}
if(regs.bg_mode == 4) {
if(hval & opt_valid_bit) {
if(!(hval & 0x8000)) {
hoffset = opt_x + (hval & ~7);
} else {
voffset = y + hval;
}
}
} else {
if(hval & opt_valid_bit) {
hoffset = opt_x + (hval & ~7);
}
if(vval & opt_valid_bit) {
voffset = y + vval;
}
}
}
} |
Results (left = CT scrolling text intro, right = CT black omen):
Code: |
before: 34.5 / 32.5
after: 42.5 / 39.5
result: +23% / +21% |
With OPT completely disabled, you gain +~30%, so I'd say that quite nearly mitigates the overhead.
Quote: |
EDIT: Might be interesting to test the "drugged Yoshi" effect in SMW2... |
Would be more interesting to add SuperFX support ;)
Last edited by byuu on Mon Mar 24, 2008 10:15 pm; edited 1 time in total
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 24, 2008 9:53 pm Post subject: |
|
And SA-1
Kirby needs some attention. 
Please forgive me if I'm taking the piss by saying this but:
Does the optimized RTO routine make things more accurate, less
accurate, or the same accuracy but just a little bit faster?
(I say I might be taking the piss because I'm basically questioning
your ability while not having any myself -- I've never even written a hello world program in my life >_< )
PS: What's RTO?
Also, I've played and completed Chrono Trigger many times, but what is the "black omen" scene?
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 24, 2008 10:06 pm Post subject: |
|
Ah,
is that why there appears to be 0 maximum frames per second when in
SMB3's battle mode? That's what kinda interested me a lot. Before going
into the battle mode, the max frames is 60, then it drops to 0 with a
52~ frame rate.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 10:08 pm Post subject: |
|
Franky wrote: |
... Does the optimized RTO routine make things more accurate, less accurate, or the same accuracy but just a little bit faster?
Also, I've played and completed Chrono Trigger many times, but what is the "black omen" scene? |
Just as accurate, but faster. Is RTO still disabled when we use frameskipping now that it's so much faster, byuu?
The black omen scene is the scene in the intro, and when it first
appears, and just before you fight Queen Zeal in her second form, where
the top of the floating ocean palace fades into view in a wavy motion.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 24, 2008 10:09 pm Post subject: |
|
Franky wrote: |
Also, I've played and completed Chrono Trigger many times, but what is the "black omen" scene? |
http://i31.tinypic.com/9k2q7l.png
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 24, 2008 10:14 pm Post subject: |
|
Quote: |
Is RTO still disabled when we use frameskipping now that it's so much faster, byuu? |
Oh, geez. I kept calling it RTO, didn't I? Sorry, this is OPT - offset
per tile, eg individually scrolled tiles. RTO is range/tile over, eg
sprite limitations.
RTO remains unaffected by this change. Still disabled with frameskip on
unless you re-compile and ask it not to do that.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 10:29 pm Post subject: |
|
byuu wrote: |
Oh,
geez. I kept calling it RTO, didn't I? Sorry, this is OPT - offset per
tile, eg individually scrolled tiles. RTO is range/tile over, eg sprite
limitations.
RTO remains unaffected by this
change. Still disabled with frameskip on unless you re-compile and ask
it not to do that. |
Aah. Was wondering why an effect integral to those scenes would be disabled when using frameskip Good to know what the acronyms stand for.
That maximum framerate being displayed as 0 looks rather odd..
Last edited by Verdauga Greeneyes on Mon Mar 24, 2008 10:30 pm; edited 2 times in total
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 24, 2008 10:29 pm Post subject: |
|
Hmm, funny, here's what I get:

This is on a 3.19ghz (hyper-threaded) Pentium 4.
ram - 1024mb
video - ATI Radeon x600 - 128mb
0 frameskipping, Linear interpolation with Scale2x filter enabled.
Byuu recommended to someone else that you set, in the advanced option, set "system.video" to "directdraw".
(apart from this, all other advanced options are set to default in my case)
Maybe that might speed things up?
I'll test this scene again later, with "system.video" set to default
("" i.e. nothing). EDIT: Just did, and there wasn't any different ...
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Mon Mar 24, 2008 10:36 pm; edited 3 times in total |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 24, 2008 10:31 pm Post subject: |
|
The
thing I notice right off the bat, is that it's saying 0 maximum frames
per second just like SMB3's battle mode in All-Stars does.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 24, 2008 10:33 pm Post subject: |
|
King Of Chaos wrote: |
The
thing I notice right off the bat, is that it's saying 0 maximum frames
per second just like SMB3's battle mode in All-Stars does. |
I have speed regulation disabled.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 24, 2008 10:42 pm Post subject: |
|
King Of Chaos wrote: |
Ah, there you go then. That's kinda confusing though.  |
All it means (having speed regulation disabled) is that bsnes doesn't
set a 60 fps limit, and just lets the game run as fast as it can on
your system.
... I get constant 60/61 fps on CT, apart from in this scene -- where the fps only drops a few frames >_>
How comes it slows down so much for everyone else?
EDIT:
Just on a hunch, I've noticed that all the people who get such big
slowdowns, that have posted screenshots, are all (mostly) Vista users.
Maybe it has something to do with our operating system's? (I have XP)
Funny thing is, I dual boot XP with Arch Linux, and on there it runs like shit.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Mon Mar 24, 2008 10:47 pm; edited 2 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 24, 2008 10:45 pm Post subject: |
|
Franky wrote: |
Byuu recommended to someone else that you set, in the advanced option, set "system.video" to "directdraw".
(apart from this, all other advanced options are set to default in my case)
Maybe that might speed things up? |
Nope.
EDIT: Hey, all these speed-related posts could be moved into their own thread...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Mon Mar 24, 2008 10:47 pm; edited 1 time in total
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 24, 2008 10:45 pm Post subject: |
|
Yea,
the directdraw setting fixed the speed drops in Chrono Trigger (but it
drops to about 57~ during that one scene) and SMB3's battle mode in
All-Stars. 

_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 24, 2008 10:51 pm Post subject: |
|
Quote: |
Funny thing is, I dual boot XP with Arch Linux, and on there it runs like shit. |
Yep, need to have OpenGL drivers and set system.video to "opengl", or
open source drivers and set it to "xv". Then you'll want to set
system.audio to "openal", and it should be no different than on Windows
XP.
Quote: |
That maximum framerate being displayed as 0 looks rather odd.. |
It shows a max framerate of zero when speed regulation is disabled,
otherwise it shows how many frames you should be getting. It can't be
blank for this mode, because then you'd see "59 / " which would look
tacky (remember, the string formatting is customizable), and I prefer
not to print --- because just printing an integer is easier. Zero
seemed like a good enough choice for "max framerate", since there isn't
one. Alternatives would be -1, 999, and 9999999999999999999999.........
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 24, 2008 10:51 pm Post subject: |
|
Here's another Black Omen picture for reference:
King Of Chaos, did you ever try my build? |
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Mar 24, 2008 10:57 pm Post subject: |
|
byuu wrote: |
Quote: |
Funny thing is, I dual boot XP with Arch Linux, and on there it runs like shit. |
Yep, need to have OpenGL drivers and set system.video to "opengl", or
open source drivers and set it to "xv". Then you'll want to set
system.audio to "openal", and it should be no different than on Windows
XP.
|
Hmm, I'll try it (though I don't know about opengl, that's always slow
for me aswell -- fglrx drivers suck). I use the opensource drivers, so
I'll try my luck with xv. I'll definitely try it anyway, thanks for the
info byuu.
EDIT:
Byuu, I've said this once and I'll say it again, you are a god.
It works.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Mon Mar 24, 2008 11:39 pm; edited 5 times in total
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 24, 2008 11:01 pm Post subject: |
|
King Of Chaos wrote: |
Ok,
found a new slowdown for you guys to play with and test (happens even
with Scale2x enabled, and no filters at all). Load up Super Mario
All-Stars, select SMB3, and try the battle mode. The FPS drops down to
around 52/53/54.
<img>http://img142.imageshack.us/img142/331/smb3battleqm1.png</img> |
Even though OPT is only used to select one static background area out of four (pic)... *sigh*
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Mar 25, 2008 1:09 am Post subject: |
|
Lucky...I don't get nearly that high...I'd show a screenshot of the framerate, but...whatever, I'll show one anyways; [/img][/url]
Note: I use the NTSC filter, so, maybe that's a factor.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Mar 25, 2008 1:36 am Post subject: |
|
I'm
sorry ... can we please get two or three more pictures of the CT Black
Omen screen? I'm not 100% sure on what it looks like just yet ...
But yeah, maybe just like two or three more ... oh, and the higher the multiplier, the better! Thanks in advance! :D
Kidding, of course. It's interesting seeing what framerates others get. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Tue Mar 25, 2008 1:48 am Post subject: |
|
neo_bahamut1985 wrote: |
Note: I use the NTSC filter, so, maybe that's a factor. |
Yep, that's the factor... picture with the NTSC filter...

_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Mar 25, 2008 2:58 am Post subject: |
|
King, we'll believe you if you just post the framerate. There's no need to scare the 56kers away. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Mar 25, 2008 3:56 am Post subject: |
|
Strangely enough; when I put on no filters, I get this 
(Linear/none setting in bsnes)
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Mar 25, 2008 4:21 am Post subject: |
|
STOP. |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Mar 25, 2008 4:31 am Post subject: |
|
why
are some pictures blurred and others are not? is it to do with the
filters? if yes then which image in each post uses what filter?
_________________
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. |
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Tue Mar 25, 2008 5:09 am Post subject: |
|
franpa wrote: |
why
are some pictures blurred and others are not? is it to do with the
filters? if yes then which image in each post uses what filter? |
Several of the screenshots are using different scale ratios, using
linear instead of point makes the whole screen blurry if you go up to
2x or 4x. The idea of Scale2x and HQ2X being to make it blur in an
appealing fashion. NTSC adds simulated color bleed which is a different
way to trick your eye into seeing detail that isn't there.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 25, 2008 6:58 am Post subject: |
|
FitzRoy wrote: |
King, we'll believe you if you just post the framerate. There's no need to scare the 56kers away. |
Aah, the couple of posts below this gave me a good laugh..
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Tue Mar 25, 2008 10:32 am Post subject: |
|
The "blurry" images just look bad to me. I'm quite happy I got me sharp output with scanlines back.
BTW I could be cruel and post the black omen image yet again with my
output, but I'll let you guys off the hook this time  |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Mar 25, 2008 1:17 pm Post subject: |
|
Sorry for blurry screenshots...
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Mar 25, 2008 2:36 pm Post subject: |
|
Don't
apologize for the blur of your screenshot, it's the fact that not only
does your screeenshot merely exist after they just asked people to stop
posting them, but that also your particular screenshot is the largest
screenshot I have ever seen in my entire life. That got you that
reaction. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Tue Mar 25, 2008 6:29 pm Post subject: |
|
Yeah, I didn't think using alt+printscreen while having Bsnes at 3x scale would make it so big on the forums. It is big, though.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Mar 25, 2008 9:07 pm Post subject: |
|
That's
why I always use Hidebehind for my screenshots. I'm sure they're not
the only ones to offer it, but their thumbnails are rather useful. |
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Wed Mar 26, 2008 12:04 am Post subject: |
|
just post a link for fucksake, then everyone is happy.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Mar 26, 2008 4:22 am Post subject: Windows OpenGL Ruby driver |
|
Hiya byuu,
After 2 failed attempts and 12 hours of work I have manged to make a loverly windows opengl ruby driver for bsnes 
It seems a fair bit faster than direct x on my system, and runs the
whole chrono trigger intro at 60FPS without any audio crackle (I have a
pentium4HT 2.8ghz, winXPSP2).
It is compatible with all of the filter/resolution options too 
I have PM'd the source files to you, so you can be the second person to try it out =D
If any one is interested I used this MS website to translate the GLX ruby driver to windows compatible commands:
http://msdn2.microsoft.com/en-us/library/ms537729(VS.85).aspx
I am gonna try out some cross platform GLSL shader goodness now! |
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Wed Mar 26, 2008 4:29 am Post subject: |
|
Nice, you made a simple port, while I tried to reinvent the entire wheel...heheh .
Quote: |
I am gonna try out some cross platform GLSL shader goodness now! |
You have added shader support? Splendid.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Mar 26, 2008 4:35 am Post subject: |
|
nah I havent added in shader support yet but some of my shader code lying about should plug straight into the source! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 26, 2008 4:43 am Post subject: |
|
krom, thanks a million. I'll try it out shortly.
In the meantime, do you know how I can get started? I have MinGW4, what
libraries / headers do I need to download and link against? |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Mar 26, 2008 4:56 am Post subject: |
|
You just need:
<GL/gl.h>
<GL/glext.h>
If you do not have "glext.h", you can grab the latest one from:
http://opengl.org/registry/
Copy glext.h into your main mingw include/GL directory.
I think all the other includes e.g include/GL/gl.h comes as standard in MinGW4 
Once you have these files just compile it after extracting the zip archive over the bsnes source.
P.S the text file in the zip I have given you explains the source differences.
Don't forget to set "opengl" as the video driver in your advanced settings config =D |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Mar 26, 2008 6:14 am Post subject: |
|
Done, wip posted with OpenGL support, see v030 release thread. Thank you again!
If you have any luck with shaders, let me know. OpenGL shader support in Windows+Linux would be awesome! :D |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Mar 27, 2008 12:30 pm Post subject: GLSL shaders |
|
I have had luck with shaders!
Got a GLSL greyscale shader to run.
no dll file needed in the bsnes directory any more.
no extra libs needed.
runs at no frame loss. (may even be faster...)
I have sent you the source link byuu =D |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 27, 2008 3:48 pm Post subject: Re: GLSL shaders |
|
krom wrote: |
I have had luck with shaders!
Got a GLSL greyscale shader to run.
no dll file needed in the bsnes directory any more.
no extra libs needed.
runs at no frame loss. (may even be faster...)
I have sent you the source link byuu =D |
Sweet deal. Does it support multiple passes?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Mar 27, 2008 5:27 pm Post subject: |
|
Excellent, thanks again, krom!
I'm going to be busy, so I probably won't get around to this one until
the weekend. Please keep the files up on your site until then.
In the mean time, mind covering how this works?
Does it support vertex shaders (or does it need to?) Does it use OpenGL
2.0 API functions, or ARB extensions to 1.x? My header and library
files with MinGW do not contain any glShader-style functions, so I was
unable to even attempt to add shader support myself. Does this support
PS 1.x? 2.x? 3.x or 4.x? Also curious about multi-pass, and if that's
necessary or why it matters (combining multiple PS source files in a
chain seems kind of overkill.) |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Mar 27, 2008 5:49 pm Post subject: |
|
byuu wrote: |
Also
curious about multi-pass, and if that's necessary or why it matters
(combining multiple PS source files in a chain seems kind of overkill.) |
I still have to look at how it's used in the hq2x shader mudlord
mentioned, but I think multiple passes allow you to run say a 2xSaI
pass, then do a Cubic interpolation on the result; you can't do this
without a massive speed loss using a single pass since you'd have to
calculate 2xSaI many times per pixel (for the surrounding pixels, which
a fragment cannot influence, only query) to make it work.
One thing I've always wanted to do, although I don't think multi-pass
shaders allow this specifically, is to have one pass scale the original
up to an exact number of pixels, feed that result into the next pass,
and so on and make only the final pass output to the final desired
resolution. This could be built into bsnes perhaps, so you get a menu
where you can chain shaders together and optionally select a target
size for the ones you care about. But I imagine that even if you like
the idea, it'd be pretty low on your priority list
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Mar 27, 2008 5:51 pm Post subject: |
|
Verdauga Greeneyes wrote: |
One thing I've always wanted to do |
... layer-dependant multipass filtering (pretty much like you defined,
i.e. several integer-upscaling filters capped with a single smoother at
the end to fit the user resolution).
And I so will pull it someday, somewhere. Eventually.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Mar 27, 2008 8:58 pm Post subject: bsnes GLSL shader info |
|
Quote: |
I'm
going to be busy, so I probably won't get around to this one until the
weekend. Please keep the files up on your site until then. |
Will do =D
Quote: |
Does it support vertex shaders (or does it need to?) |
Currently I only use a fragment shader for the colour output, but it will be easy to support vertex shaders too.
I have some ideas for 3d effects that could be generated from the snes
gfx in realtime so I think there would be some fun things we could do
with it.
Quote: |
Does it use OpenGL 2.0 API functions, or ARB extensions to 1.x? |
It uses GL ARB shader objects.
Quote: |
My
header and library files with MinGW do not contain any glShader-style
functions, so I was unable to even attempt to add shader support
myself. Does this support PS 1.x? 2.x? 3.x or 4.x? |
If you look inside the glext.h opengl extensions include file, you will se lots of nice shader stuff. If you don't see any, get the latest one from http://www.opengl.org.
It could support ps 1.0-4.0 with these extensions.
Quote: |
Also
curious about multi-pass, and if that's necessary or why it matters
(combining multiple PS source files in a chain seems kind of overkill.) |
I think that if we try to create shader versions of all of the current
filters in bsnes, it would be nice to be able to mix them together e.g
scanlines and ntsc. So yeah I think it would be nice to have multipass
stuff =D
The way I got this to work is years ago I converted all of the MSVC GLSL sources from http://www.codesampler.com, into mingw.
In those sources was a really simple glsl fragment shader example that
converts a classic mandrill picture into grey scale.
I used this old source code and plugged it into the bsnes wgl driver, and luckily it worked.
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Mar 28, 2008 12:10 am Post subject: |
|
Quote: |
I have had luck with shaders!
Got a GLSL greyscale shader to run.
no dll file needed in the bsnes directory any more.
no extra libs needed.
runs at no frame loss. (may even be faster...)
I have sent you the source link byuu =D |
Insane work! Bravo!
I'll look into possibly porting some of my HLSL shaders to GLSL form..
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Fri Mar 28, 2008 1:08 am Post subject: |
|
That krom, he's no rookie! Someone give this guy a title! |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 28, 2008 6:31 am Post subject: Re: bsnes GLSL shader info |
|
Quote: |
It uses GL ARB shader objects. |
Ugh, that takes way
too much code to set up ... I tried using the OpenGL 2.0 functions on
Linux and succeeded, but the GLslang compiler in the nvidia driver
apparently sucks or something. ~80% of shaders have no effect, and the
other ~20% do very, very little.
Mmm, but it's so much simpler ;_;
Anyone know how I can get OpenGL2 / glShader* functions working with MinGW4 ? :/
Code: |
GLuint program;
GLuint vertexshader;
GLuint fragmentshader;
//setup shader
vertexshader = glCreateShader(GL_VERTEX_SHADER);
fragmentshader = glCreateShader(GL_FRAGMENT_SHADER);
FILE *fp = fopen("/home/byuu/Desktop/test.vert", "rb");
fseek(fp, 0, SEEK_END);
int size = ftell(fp);
fseek(fp, 0, SEEK_SET);
char *buffer = new char[size + 1];
fread(buffer, 1, size, fp);
buffer[size] = 0;
fclose(fp);
const char *vbuffer = buffer;
glShaderSource(vertexshader, 1, &vbuffer, 0);
glCompileShader(vertexshader);
delete[] buffer;
fp = fopen("/home/byuu/Desktop/test.frag", "rb");
fseek(fp, 0, SEEK_END);
size = ftell(fp);
fseek(fp, 0, SEEK_SET);
buffer = new char[size + 1];
fread(buffer, 1, size, fp);
buffer[size] = 0;
fclose(fp);
vbuffer = buffer;
glShaderSource(fragmentshader, 1, &vbuffer, 0);
glCompileShader(fragmentshader);
delete[] buffer;
program = glCreateProgram();
glAttachShader(program, vertexshader);
glAttachShader(program, fragmentshader);
glLinkProgram(program);
glUseProgram(program); |
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Mar 28, 2008 7:03 am Post subject: |
|
Code: |
GLuint program;
GLuint vertexshader;
GLuint fragmentshader;
//setup shader
vertexshader = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB );
fragmentshader = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);
FILE *fp = fopen("/home/byuu/Desktop/test.vert", "rb");
fseek(fp, 0, SEEK_END);
int size = ftell(fp);
fseek(fp, 0, SEEK_SET);
char *buffer = new char[size + 1];
fread(buffer, 1, size, fp);
buffer[size] = 0;
fclose(fp);
const char *vbuffer = buffer;
glShaderSourceARB( vertexshader, 1, &vbuffer, NULL );
glCompileShaderARB(vertexshader);
delete[] buffer;
fp = fopen("/home/byuu/Desktop/test.frag", "rb");
fseek(fp, 0, SEEK_END);
size = ftell(fp);
fseek(fp, 0, SEEK_SET);
buffer = new char[size + 1];
fread(buffer, 1, size, fp);
buffer[size] = 0;
fclose(fp);
vbuffer = buffer;
glShaderSourceARB(fragmentshader, 1, &vbuffer, 0);
glCompileShaderARB(fragmentshader);
delete[] buffer;
program = glCreateProgramObjectARB();
glAttachShaderARB(program, vertexshader);
glAttachShaderARB(program, fragmentshader);
glLinkProgramARB(program);
glUseProgramARB(program);
|
Quote: |
Anyone know how I can get OpenGL2 / glShader* functions working with MinGW4 ? :/ |
If the above code didnt work out, I'll write up a mingw compatible code sample.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 28, 2008 7:22 am Post subject: |
|
Saw the ARB version at lighthouse3d.com ... they're not in glext.h, either. Thus, they won't be in opengl32.lib.
I want to avoid ARB, and I also want to avoid importing functions through *GetProcAddress ... very messy, that. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Mar 28, 2008 12:55 pm Post subject: |
|
I'd
like ARB to be available, at least. It does give you more control, and
I think it's the only direct way to take advantage of shader model 4
functions, if any of them should ever prove useful to us. Then again, I
guess there's no reason to take support for it out, is there? |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Fri Mar 28, 2008 10:12 pm Post subject: opengl 2.0 mingw4 |
|
Quote: |
Anyone know how I can get OpenGL2 / glShader* functions working with MinGW4 ? :/ |
I have been trying to get glShader functions to work.
I started by converting the ARB code I gave you, to OpenGL2 functions
using that lighthouse 3D link you gave. Mingw would not recognise any
of the functions until I defined this in the wgl.cpp file:
Code: |
#define GL_GLEXT_PROTOTYPES |
It then all started compiling right upto the program linking stage,
where I got a bunch of "undefined reference" errors matching the
functions 
Quote: |
I want to avoid ARB, and I also want to avoid importing functions through *GetProcAddress ... very messy, that. |
I agree, I wish I could get the linking stage above to work so that we have a much cleaner/simple shader source.
I am gonna keep cracking on with it though, it has to work somehow...
Last edited by krom on Fri Mar 28, 2008 10:46 pm; edited 1 time in total
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Fri Mar 28, 2008 10:34 pm Post subject: |
|
DancemasterGlenn wrote: |
That krom, he's no rookie! Someone give this guy a title! |
I have an idea. Why don't we call him "krom".
<|-_-|>
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 28, 2008 11:02 pm Post subject: |
|
I'm
actually rather disappointed by this whole thing. I had assumed it
would be as simple as there just being D3D shaders and GL shaders, and
they would just work across the board. The reality is quite different.
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only
OpenGL:
- Supports GLSL, ARB and Cg.
- GLSL is easy, but requires OpenGL 2.0; missing by default on Windows
(ships with 1.1, though video card drivers always have 2.0)
- GLSL has different bugs in every implementation; most shaders do not work at all, especially on Linux
- ARB requires crazy function pointer handles, and is already deprecated
- Cg is also very old and deprecated, also requires use of extensions; shaders are very uncommon for this
Direct3D and OpenGL:
- SM 1.1, 1.2, 1.3, 1.3, 2.0, 2.1, 3.0, 4.0, 4.1, ... they can't make
up their minds how to design a fixed standard that doesn't get usurped
within 3 months' time
Ultimately, this is all bullshit. Maybe it's better to just say fuck it
and multi-thread the video rendering to use another CPU core. Pure C++
is much more powerful, and much more stable, than this shader bullshit
anyway. Very few single core CPUs get 60fps with bsnes anyway.
Maybe someone can describe 2xSaI's algorithm to me so I can cleanroom
implement it. I'll then release my implementation as public domain so
everyone can use it. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 28, 2008 11:10 pm Post subject: |
|
byuu wrote: |
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only |
A number of those video cards don't even have shaders.
Quote: |
Direct3D and OpenGL:
- SM 1.1, 1.2, 1.3, 1.3, 2.0, 2.1, 3.0, 4.0, 4.1, ... they can't make
up their minds how to design a fixed standard that doesn't get usurped
within 3 months' time |
Well, there are two things at work: MS and hardware companies
You have standards for different versions of hardware at the time...
just stick with 2.0 and move up to 3.0 as needed. The complexity
between the 1.x versions is at best inconsistant, and not everyone is
using Vista, which eliminates SM4 under D3D to begin with.
You will have to end up using ARB extensions for OpenGL to be effective anyways.
_________________
FF4 research never ends for me.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Fri Mar 28, 2008 11:20 pm Post subject: |
|
Quote: |
Ultimately,
this is all bullshit. Maybe it's better to just say fuck it and
multi-thread the video rendering to use another CPU core. Pure C++ is
much more powerful, and much more stable, than this shader bullshit
anyway. Very few single core CPUs get 60fps with bsnes anyway. |
Yep you are right, it would make utter sense to multi-thread the video
rendering for maximum cross platform speed and stability.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Fri Mar 28, 2008 11:34 pm Post subject: |
|
Deathlike2 wrote: |
byuu wrote: |
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only |
A number of those video cards don't even have shaders.
|
What? Bullshit. All of those have shaders except for the vanta and maybe the mobility Radeon. Depends on which model it is.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 28, 2008 11:37 pm Post subject: |
|
Quote: |
A number of those video cards don't even have shaders. |
I didn't think the Radeon or Vanta would, but the rest definitely do.
Four supported cards and four crashes does not bode well to me.
But then, mudlord's solution is genius as it is universal to all D3D9
applications. I think it would be best to keep it external, and perhaps
I can link directly to his page on the bsnes download page.
Quote: |
Yep you are right, it would make utter sense to multi-thread the video rendering for maximum cross platform speed and stability. |
Okay, agreed. I'll leave ruby as is. It was a nice try, anyway.
So, for multi-threading, I'll need to write up something along the
lines of libco -- let's call it libpe (pe: pre-emptive / co:
co-operative.) Just need thread creation and deletion. Mutual
exclusions should be built-in via __thread. And we can update it to use
C++0x extensions when available.
The idea will be that once a video frame is rendered, to hand it off to
the other CPU core and mark it as busy. Then start the next emulated
frame. If the filter finishes first, no problem, continue as normal. If
the emulated frame finishes first, then wait until the filter thread
releases a lock.
Now, getting the video over ... bsnes' video buffer is pretty tricky.
It's basically one single 512x480@16bpp array. For lores, I just draw
the first 256 pixels, ignoring the rest. Using pitch compensates for
that. Hires just draws all 512. Now for progressive, I skip every other
scanline, and double the pitch width so that it effectively skips the
odd lines. For interlace, I give the true pitch so that it gets access
to all scanlines.
But I can't have the filter thread reading from this buffer while the
PPU is updating it. And I can't have a simple swap buffer in the PPU
for each frame drawn, because interlace relies on blending each field
into the same buffer.
So, I can do it the easy way and do a painful memcpy() to a special
buffer right before activating the filter thread; or the hard way, and
split up the PPU into two field buffers each with their own swap
buffers, which will greatly complicate rendering interlaced frames
inside the video filters themselves. Hmm ... I'll do some benchmarks
first to see what kind of speed hit a brute force RAM->RAM memcpy()
each frame will incur, bypassing it when using no filter at all,
obviously. Shouldn't be too horrible.
---
EDIT:
It takes ~15ms for 60 times 256x224x16bpp copies. It takes ~90ms for 60
times 512x480x16bpp copies. This is with no optimizations on a Pentium
IV 1.7GHz. It'd be about 3-4x faster on a Core 2.
Last edited by byuu on Fri Mar 28, 2008 11:50 pm; edited 1 time in total
|
|
mudlord VBA Developer


Joined: 11 Sep 2007
Posts: 268
|
Posted: Fri Mar 28, 2008 11:41 pm Post subject: |
|
Quote: |
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any
of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI
X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only |
Shit...It should work on any card that supports:
* Shader Model 2.0
* Multiple render targets (MRT)
I find it completely odd it doesnt work with you with that 8800GTS.
Oh well, if you wanna fuck the idea, its your choice.
Same goes for GLSL shader implementation.
Quote: |
But
then, mudlord's solution is genius as it is universal to all D3D9
applications. I think it would be best to keep it external, and perhaps
I can link directly to his page on the bsnes download page. |
And in that case, I'll write up a small homepage for it on my
serverspace. I'm sure Chrono Archangel won't mind (plus he gave me a
super cool project proposal with the GC emu Gekko, so im on very good
terms with him).
Last edited by mudlord on Fri Mar 28, 2008 11:42 pm; edited 1 time in total
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Mar 28, 2008 11:42 pm Post subject: |
|
I.S.T. wrote: |
Deathlike2 wrote: |
byuu wrote: |
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only |
A number of those video cards don't even have shaders.
|
What? Bullshit. All of those have shaders except for the vanta and maybe the mobility Radeon. Depends on which model it is.
|
I said "a number"... that number happens to be 1 (and maybe 2 if the Mobility Radeon info were more specific).
I don't really consider those video cards that are SM1.x to be any good
for this purpose though, which is what I meant anyways.
_________________
FF4 research never ends for me.
Last edited by Deathlike2 on Fri Mar 28, 2008 11:45 pm; edited 1 time in total
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Mar 28, 2008 11:42 pm Post subject: |
|
Franky wrote: |
DancemasterGlenn wrote: |
That krom, he's no rookie! Someone give this guy a title! |
I have an idea. Why don't we call him "krom".
<|-_-|>
|
he meant like under his name, like snes developer or something (just relaying what Dancemaster said)
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Fri Mar 28, 2008 11:43 pm Post subject: |
|
Deathlike2 wrote: |
I.S.T. wrote: |
Deathlike2 wrote: |
byuu wrote: |
Direct3D:
- Supports HLSL and Cg. mudlord's d3d9.dll trick does not work on any of the six computers I own (8800 GTS, 7950 GT, nVidia Vanta, ATI X300LS, ATI X600 SE, ATI Mobility Radeon somethingorother)
- Overly complicated, and Windows only |
A number of those video cards don't even have shaders.
|
What? Bullshit. All of those have shaders except for the vanta and maybe the mobility Radeon. Depends on which model it is.
|
I said "a number"... I don't really consider those video cards that are
SM1.x to be any good for this purpose though, which is what I meant
anyways.
|
Those are all 2.0 cards and up except for the vanta and mobility radeon.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Mar 28, 2008 11:56 pm Post subject: |
|
Quote: |
Shit...It should work on any card that supports:
* Shader Model 2.0
* Multiple render targets (MRT)
I find it completely odd it doesnt work with you with that 8800GTS. |
Yeah, it's extremely bizarre. I move the fakehdr.fx file to the same
directory as bsnes.exe and d3d9.dll, and bsnes just closes as soon as
it opens ... I only see the window appear for half a second or less. No
error message, nothing.
A real shame, I really wanted to try out the wave shader :(
nVidia Vanta = Win2k
nVidia 8800 GTS = WinXP SP2 / x86
nVidia 7950 GT KO SC = WinXP SP2 / x86
nVidia 6200 onboard = Ubuntu only, can't test
ATI Radeon X300 LS = Windows Vista / x86
ATI Radeon X600 SE = WinXP SP2 / x86
ATI Radeon Mobility ???? = WinXP SP2 / x86
Quote: |
Oh well, if you wanna fuck the idea, its your choice.
Same goes for GLSL shader implementation. |
Well, the OpenGL version is just out. It isn't going to work worth a
damn on Linux, and there's little I can do about that.
I really don't see it as being worthwhile to spend a lot of time
implementing a shader loading subsystem when it will only be utilized
by Direct3D9 and nothing else :(
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Mar 29, 2008 12:21 am Post subject: |
|
I
think the shaders are best left to the mudlord system, where those of
us who want them can put them in the directory ourselves. Byuu
shouldn't have to dick around with that right now. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 29, 2008 3:13 am Post subject: |
|
krom try to help me out. I get this error on make.
mingw32-g++ -O3 -fomit-frame-pointer -Ilib -DGZIP_SUPPORT -DJMA_SUPPORT -c ui/ma
in.cpp -o obj/main.o
process_begin: CreateProcess(NULL, mingw32-g++ -O3 -fomit-frame-pointer -Ilib -D
GZIP_SUPPORT -DJMA_SUPPORT -c ui/main.cpp -o obj/main.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [obj/main.o] Error 2
Press any key to continue . . .
Here is my run.bat file setup bellow.
@echo off
cd c:\bsnes\mingw\bsnes
set path=c:\bsnes\mingw\bin;
@make platform=win compiler=mingw32-gcc enable_gzip=true enable_jma=true
@pause
He send me these links bellow.
Here is a link to a full mingw4 install:
http://sourceforge.net/project/downloading.php?groupname=mplayer-win32&filename=MinGW-full-gcc-4.2.1.7z
This is the link to the mingw make:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=23918
I still think Vista refuse to run make fully.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 29, 2008 5:15 am Post subject: |
|
Dullaron wrote: |
mingw32-g++ -O3 -fomit-frame-pointer -Ilib -DGZIP_SUPPORT -DJMA_SUPPORT -c ui/ma
in.cpp -o obj/main.o
process_begin: CreateProcess(NULL, mingw32-g++ -O3 -fomit-frame-pointer -Ilib -D
GZIP_SUPPORT -DJMA_SUPPORT -c ui/main.cpp -o obj/main.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [obj/main.o] Error 2
Press any key to continue . . . |
Copy or rename the executables in your mingw\bin folder so they don't
have -sjlj in there. So 'mingw32-g++-sjlj.exe' becomes
'mingw32-g++.exe'. I'm not sure for exactly which ones you have to do
this, but I did it to most of them and it compiles fine now.
Edit: oh, and make sure the folder appears in your PATH environment variable.
Edit2: guess I should've looked at the link in your post before. It
seems this version of Mingw4 doesn't have the -sjlj thing, but the
executables still seem to have strange names. I'd suggest copying or
renaming 'i686-pc-mingw32-g++-4.2.exe' to 'mingw32-g++.exe' (and
similar for the others) and seeing if it works. If not, it's not that
hard to get the full pack from the MinGW website and do what I said
above.
Edit3: eh, this isn't part of your question, but make sure you also
have Microsoft's Platform SDK installed (either the 2003 or the
recently released 2007 one) and install the latest DirectX SDK and copy
the headers from that into MinGW, replacing the ones it has.
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Sat Mar 29, 2008 7:44 am Post subject: |
|
Panzer88 wrote: |
he meant like under his name, like snes developer or something (just relaying what Dancemaster said) |
Thank you. And you can just say Glenn if you want, it's easier than Dancemaster and less weird than Dance.
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 29, 2008 8:18 am Post subject: |
|
The source is up. But there no faq.
Some of us really don't understand fully. I don't get it.
Why not do what Aaron did? See bellow.
http://mamedev.org/tools/
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
Y~K Hazed

Joined: 22 Jan 2007
Posts: 52
|
Posted: Sat Mar 29, 2008 9:56 am Post subject: |
|
In unemulated hardware, you could add all types of action replay/game genie devices & the super gameboy
And is the sufami turbo emulated?
_________________
Join the United datters saving history for eternity

Official Community
Last edited by Y~K on Mon Mar 31, 2008 8:07 am; edited 1 time in total |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 29, 2008 11:12 am Post subject: |
|
I
don't have time to document how to compile bsnes, sorry. If you can't
figure out how to compile it (as in you probably don't program in C++ a
lot), then you probably won't be able to do much with the code anyway.
Sufami Turbo ... you could at least try running bsnes once and find out for yourself :/
Nobody is ever going to emulate the GG / PAR BIOSes. I'd give up on pushing that one. SGB would be nice once everything else is done. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 29, 2008 12:55 pm Post subject: |
|
Dullaron wrote: |
The source is up. But there no faq. |
It really isn't that hard though, as byuu said.
1.) Get Microsoft's Platform SDK and install it.
2.) Get Microsoft's DirectX SDK and install it.
3.) Get the relevant parts of MinGW (mingw-runtime, Core, C++, w32API,
BinUtils and Make) and extract them to an appropriately named folder
4.) Add MinGW's bin subdir to your PATH environment variable,
copy/rename the -sjlj files so they don't include that addition, and
copy/rename mingw32-make.exe to make.exe
5.) Copy the headers found in the DirectX SDK's Include directory to
MinGW's include directory, overwriting where necessary.
6.) Have a beer and throw a party
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Mar 29, 2008 3:05 pm Post subject: |
|
Dullaron wrote: |
The source is up. But there no faq.
Some of us really don't understand fully. I don't get it.
Why not do what Aaron did? See bellow.
http://mamedev.org/tools/ |
Perhaps sometime I'll
write a guide to compiling bsnes. I've been meaning to set up a
general-purpose MinGW build environment, for both bsnes and other
open-source programs.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
denzilla Rookie
Joined: 26 Sep 2004
Posts: 45
|
Posted: Sat Mar 29, 2008 4:18 pm Post subject: |
|
Probably
not important anymore, but figured out what my vsync issue is with
bsnes and Vista. When running the Aero interface, Vista vsyncs the
desktop to ensure everything is smooth and there is no screen tear when
dragging windows around. This was causing my issue with running bsnes
in a window. Disabling vsync in bsnes isn't enough. There is no screen
tear, but scrolling remains jerky. If you change Vista to use its
classic interface, then bsnes is smooth as butter using its own vsync
setting. What I don't understand is why bsnes still has problems when
running fullscreen with Aero enabled. I think Aero is disabled when an
app is fullscreen isn't it? |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Mar 29, 2008 9:12 pm Post subject: |
|
OpenGL
and DirectX applications should automatically use the vsync of DWM when
using Vista. That is my experience with it. If you wait for vsync in
your app you are synced to the desktop in windowed mode. But I don't
see how this would affect anything otherwise. You could always embed a
manifest to disable aero if you wanted to into the bsnes exe but it
shouldn't be necessary. I will take a look at the stuff tonight and see
if I can find a sensible solution to this without hackery.
_________________
Watering ur plants. |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Sat Mar 29, 2008 10:24 pm Post subject: |
|
The SGB did have some special things other than the GB chips.
Like that single game that accessed completely different code when played in a SGB.
But get the SA-1 and SFX done first. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 29, 2008 10:25 pm Post subject: |
|
Why we need Microsoft's Platform SDK when we have MinGW?
Doesn't make any since to me to have both programs that does the same
thing. Even those make different way. Are these hacking together?
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
Last edited by Dullaron on Sat Mar 29, 2008 10:38 pm; edited 2 times in total |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Mar 29, 2008 10:32 pm Post subject: |
|
MinGW is unnecessary and outdated. You can get a free compiler from Microsoft for windows.
_________________
Watering ur plants. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 29, 2008 10:38 pm Post subject: |
|
I can't find Microsoft's Platform SDK anywhere. I did found this. http://www.microsoft.com/express/download/ and it include it.
Just now downloading DirectX SDK - March 2008 Over 400mb
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
|
denzilla Rookie
Joined: 26 Sep 2004
Posts: 45
|
Posted: Sat Mar 29, 2008 11:17 pm Post subject: |
|
pagefault wrote: |
OpenGL
and DirectX applications should automatically use the vsync of DWM when
using Vista. That is my experience with it. If you wait for vsync in
your app you are synced to the desktop in windowed mode. But I don't
see how this would affect anything otherwise. You could always embed a
manifest to disable aero if you wanted to into the bsnes exe but it
shouldn't be necessary. I will take a look at the stuff tonight and see
if I can find a sensible solution to this without hackery. |
I guess the way DWM vsyncs doesn't jive well with some emulators
running windowed as I have the same issue with Ootake. As a work
around, you can just right-click on the exe ->compatibility and
disable desktop compostion. This will of course disable Aero but you
can run Windowed without the jerky scrolling/tearing via the emus
built-in vsync option.
bsnes v.30 seems play better with Vista in Windowed mode, but its still not as smooth as just disabling Aero.
Last edited by denzilla on Sun Mar 30, 2008 9:30 pm; edited 2 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sat Mar 29, 2008 11:21 pm Post subject: |
|
pagefault wrote: |
MinGW is unnecessary and outdated. You can get a free compiler from Microsoft for windows. |
As I recall from byuu's experimentation, MinGW 4 is faster than VC++.
This was, I think, comparing it to VS2005, so the situation may have
changed.
Dullaron wrote: |
Why we need Microsoft's Platform SDK when we have MinGW?
Doesn't make any since to me to have both programs that does the same
thing. Even those make different way. Are these hacking together? |
Actually, I don't remember whether it was strictly needed.. you could
of course try it without the Platform SDK first. But, I think bsnes
failed to compile for me the one time I tried it without the Platform
SDK.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 29, 2008 11:29 pm Post subject: |
|
I'm
suddenly reminded of someone suggesting to post a bug report on MS
forums regarding bsnes compiling issues. Did anyone do this yet? |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sat Mar 29, 2008 11:32 pm Post subject: |
|
Verdauga Greeneyes wrote: |
Why we need Microsoft's Platform SDK when we have MinGW? |
Wake me up when mingw supports 64-bit compiling (properly) and doesn't
have to hack my obj files from other compilers to get them to link with
it.
_________________
Watering ur plants.
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Sat Mar 29, 2008 11:33 pm Post subject: |
|
I'm
not going to worry about downloading all those anymore. Just waste of
time trying to get things together and make things work.
I deleted all those files and bsnes source. Not worth it. I just stick
on the bsnes.exe than messing with all that. Better off this way.
Sorry about wasting your time.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Mar 30, 2008 12:02 am Post subject: |
|
Quote: |
4.)
Add MinGW's bin subdir to your PATH environment variable, copy/rename
the -sjlj files so they don't include that addition, and copy/rename
mingw32-make.exe to make.exe |
You can actually just set compiler= to the name of the CC compiler now.
Eg compiler=i686-mingw32-gcc and it will infer the C++ compiler name
and tools now.
Quote: |
OpenGL and DirectX applications should automatically use the vsync of DWM when using Vista. |
Odd, my copy of Vista runs bsnes at >60fps with a 60hz refresh rate.
Quote: |
Wake
me up when mingw supports 64-bit compiling (properly) and doesn't have
to hack my obj files from other compilers to get them to link with it. |
64-bit would be nice. No need to hack obj files anymore. It was there
because they actually followed the spec, rather than real world broken
implementations. I've never had to use objfix, even with NASM objects.
MinGW4 outputs ~10% faster code at -O3 than Visual C++ at /GL /O2. But
I know you're a big fan of Microsoft and their tools, so that's cool,
too. After dealing with this G15 keyboard setup, I was half ready to
jump ship myself.
Quote: |
Sorry about wasting your time. |
Not at all, sorry I'm not more helpful with it.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Mar 31, 2008 1:08 pm Post subject: MinGW 4.3 |
|
Hi byuu,
Just to let you know, gcc 4.3 was released this month, so I went looking for a MinGW version...
I found this website that has an up to date gcc, g++ 4.3 replacement of the mingw packages:
http://www.tdragon.net/recentgcc/
I found it compiles bsnes noticably faster than the MinGW4 version we are currently using, which was nice to see 
If everyone can see a speed up, maybe the official windows bsnes executable should be compiled with this =D |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Mar 31, 2008 2:12 pm Post subject: Re: MinGW 4.3 |
|
krom wrote: |
I found it compiles bsnes noticably faster than the MinGW4 version we are currently using, which was nice to see 
If everyone can see a speed up, maybe the official windows bsnes executable should be compiled with this =D |
At a glance, the main menu in Seiken Densetsu 3 seems ~2 fps slower with this build of g++ 4.3; nice find, though 
I wonder if code profiling is fixed in this version.. (for those who
don't know, it was a bit overzealous for bsnes in 4.2.1, leading to
crashes and general instability)
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Mar 31, 2008 2:47 pm Post subject: MinGW 4.3 slower? |
|
Quote: |
At a glance, the main menu in Seiken Densetsu 3 seems ~2 fps slower with this build of g++ 4.3; nice find, though  |
Ah I just realised that I am using -mtune=nocona in my Makefile so maybe this new gcc is faster at building optimised builds...
I always reboot windows before I make a speed test for bsnes so that I
know I am running it in the same way every time.
I have noticed fps drops of upto 2fps on my system after loading lots
of applications, closing them down, and then running bsnes.
I will try to test out PGO in a sec to see if it is fixed...
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Mar 31, 2008 3:15 pm Post subject: PGO Test |
|
I just tested profiling and it still crashes, unfortunately. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 31, 2008 3:25 pm Post subject: |
|
Thanks for testing, krom. That saves me a lot of time.
A shame it still fails, though. I guess PGO and Windows wasn't meant to be.
Linux PGO gives a nice, free ~20% speedup, though. |
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Mar 31, 2008 4:58 pm Post subject: |
|
Quote: |
Thanks for testing, krom. That saves me a lot of time. |
Good to know I am helping out =D
Quote: |
Linux PGO gives a nice, free ~20% speedup, though. |
I can not believe I have not tried this out in linux yet! ~20% speedup would be ace!
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Mar 31, 2008 6:00 pm Post subject: |
|
I've
added two new $50 bounties to the compatibility thread. One is to find
a fix for the PGO issues, and the other is to find a fix for the
Direct3D scaling bug. Go now, mercenaries, hunt them down for these
paltry sums! A tank of gas for your troubles!  |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Mar 31, 2008 6:29 pm Post subject: |
|
I
wish I had money to offer as a bounty for actually increasing the
compability. Yes, you know what I mean, special chips and extension
controllers. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 31, 2008 10:01 pm Post subject: |
|
henke37 wrote: |
I
wish I had money to offer as a bounty for actually increasing the
compability. Yes, you know what I mean, special chips and extension
controllers. |
How can you go past 100% compatibility, not counting special chips and hardware like the mouse and super scope?
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 31, 2008 10:04 pm Post subject: |
|
Uh, I think you need to reread his post. |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Mon Mar 31, 2008 10:21 pm Post subject: Direct Scaling bug fixed! |
|
Hi FitzRoy & byuu,
You will be happy to know I have fixed the direct3d scaling bug.
The funniest thing is it actually took me longer to work out what you
meant by a "scaling bug at a size larger than 2X" than it took me to
solve it!
The problem was the u.v coordinates were being offset by 0.5 texels so
the snes colours were always going to be halfway along a pixel giving
it a sub pixel look.
You just need to edit the src/lib/ruby/video/direct3d.cpp file:
Delete all the -0.5 bits from the end of the 4 u.v coordinate lines, starting at line 91, and it will work correctly =D
Last edited by krom on Mon Mar 31, 2008 11:51 pm; edited 3 times in total |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Mar 31, 2008 10:23 pm Post subject: |
|
I.S.T. wrote: |
Uh, I think you need to reread his post. |
Blah, I blame the tornadoes in my area.
Oooooh, somebody just claimed a bounty.
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Mar 31, 2008 10:24 pm Post subject: |
|
Awesome. *Pretend this is a thumbs up smiley*
Edit: Used the thumbs up smile code from another forum.... >.< |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 01, 2008 12:00 am Post subject: |
|
Quote: |
One is to find a fix for the PGO issues, and the other is to find a fix for the Direct3D scaling bug. |
Meh, you paid way too much for the D3D issue :P
Quote: |
The
problem was the u.v coordinates were being offset by 0.5 texels so the
snes colours were always going to be halfway along a pixel giving it a
sub pixel look. |
Thanks again, krom! :D
Odd, I read somewhere that this was required. Even wrote a source code
note about it -- "(x,y) screen coords, in pixels (-0.5 for texel /
pixel correction)".
Now, you mentioned:
Code: |
Delete all the -0.5 bits from the end of the 4 u.v coordinate lines, starting at line 91, and it will work correctly =D |
Hmm? Line 91 is the mag filter selection. Inside set_vertex, we have:
Code: |
d3dvertex vertex[4];
vertex[0].x = vertex[2].x = (double)(x ) - 0.5;
vertex[1].x = vertex[3].x = (double)(x + w) - 0.5;
vertex[0].y = vertex[1].y = (double)(y ) - 0.5;
vertex[2].y = vertex[3].y = (double)(y + h) - 0.5;
double rw = (double)w / (double)pw * (double)tw;
double rh = (double)h / (double)ph * (double)th;
vertex[0].u = vertex[2].u = (double)(px ) / rw;
vertex[1].u = vertex[3].u = (double)(px + w) / rw;
vertex[0].v = vertex[1].v = (double)(py ) / rh;
vertex[2].v = vertex[3].v = (double)(py + h) / rh; |
So, it's using texel offset on x/y, and not on u/v. I assume you meant
to say to change the x/y lines in the above block of code to omit the
-0.5?
Well, that explains why I didn't see the bug, my video card supports
StretchRect, so it never even uses the triangle strip vertex code ...
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Tue Apr 01, 2008 12:36 am Post subject: |
|
Quote: |
I assume you meant to say to change the x/y lines in the above block of code to omit the -0.5? |
Yeah sorry I am well tired, have not slept for a bit...
This is the exact code I used to make it work:
Code: |
d3dvertex vertex[4];
vertex[0].x = vertex[2].x = (double)(x );
vertex[1].x = vertex[3].x = (double)(x + w);
vertex[0].y = vertex[1].y = (double)(y );
vertex[2].y = vertex[3].y = (double)(y + h); |
I took a screen shot of bsnes at 3X zoom, and used paint to zoom in, to see the bug happening.
When I applied this fix, the screen mode looked much more sharp without
the linear filter. I took another screenshot and zoomed in just to make
sure, and I could see that it was working fine =D
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Apr 01, 2008 2:27 am Post subject: |
|
Oh,
goody, an incentive finally worked! Thanks a lot krom. I will send the
money over as soon as byuu gives the okay and posts a WIP for the
change. I'd like to verify its effects on my own video card just to be
sure its kosher. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Tue Apr 01, 2008 5:09 am Post subject: |
|
byuu
can I test out your wips? Just let me know what you want me to test
out. I will send back reports and snapshots. Your the boss byuu.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Tue Apr 01, 2008 11:09 pm Post subject: Game Bug |
|
Hi byuu,
I have found a new bsnes v0.030.04 bug in the official game Mecarobot Golf (U).smc.
If you create a character and enter "Lesson" mode you can see the golf course flashes blue, it is using mode 7...
When the course zooms in at the start, you can see that the blue
flashing is the same mode 7 picture drawn incorrectly.
I hope this helps you track down the bug. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 3:59 am Post subject: |
|
Quote: |
I have found a new bsnes v0.030.04 bug in the official game Mecarobot Golf (U).smc. |
Congratulations, you found a bug I cannot fix.
http://byuu.cinnamonpirate.com/temp/mecarobot.txt
It attempts to disable HDMA right as it occurs. If it's off by even two
clock cycles, HDMA occurs anyway (due to the way the CPU is locked, the
HDMA disable won't happen until HDMA finishes.)
When this happens, it pushes the time too far ahead, and the IRQ it
sets for the next frame does not fire. That IRQ is what re-enables
HDMA. So once the IRQ is missed, HDMA is left off for the rest of the
frame and half of the next. Thus, you lose all HDMA effects. Both the
golf course and the translucent text window are a result of HDMA, so
those both go.
The timing requirements of this game are too tight ... there's most
likely many things in play here, bus hold delays on writes to the CPU
core, interactions with the single cycle after $420c writes and before
(H)DMA events fire, and HDMA sync timing. It isn't something I'm able
to fix.
The best I can do is re-apply the faulty HDMA sync timing I have now,
and allow the SoM intro + Street Racer mode 7 effects to break again.
It may not be perfect, but I have to get the timing more accurate if
this will ever work. I've been putting it off because it will take
months to perfect -- if I can manage it at all, that is.
For those lacking in technical knowledge, the fact that Snes9X and
SNESGT can run the game is irrelevant. They have HDMA timing issues in
other games, so it doesn't help me at all.
As a result of all this, I'm cancelling the v031 release I was planning for the weekend.
I've also verified that your D3D9 fix worked beautifully. It even
improves StretchRect mode, too! Now I really wish I knew where I read
the -0.5 thing, so I could go kick someone's ass for wasting FitzRoy's
money. So you get $50 and you get to break the long-standing 100% compatibility rating. Congrats again.
|
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Wed Apr 02, 2008 4:15 am Post subject: |
|
byuu wrote: |
As a result of all this, I'm cancelling the v031 release I was planning for the weekend. |
Booo! Hahaha
Oh well, discovery of new and obscure timing errors is always good/bad (depending on your perspective.)
Last edited by Palin on Wed Apr 02, 2008 4:33 am; edited 1 time in total
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 02, 2008 4:29 am Post subject: |
|
Mecarobot Golf sucks.
Solely because with a name like that, I expected some sort of giant
robot violence(sort of like Ninja Golf, but with mechs) and all I got
was golf. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Apr 02, 2008 5:57 am Post subject: |
|
byuu wrote: |
The
best I can do is re-apply the faulty HDMA sync timing I have now, and
allow the SoM intro + Street Racer mode 7 effects to break again. |
If you can't fix this issue then I'd say only one broken game is better
than two broken games. Especially with the popularity of the two.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 7:01 am Post subject: |
|
Redesigned
my site. Heavily based on FitzRoy's design, but I changed up a few
things here and there. Wanted to keep the image count and blank space
down.
Be sure to thank him if you like the new design. Or throw stones at him if you don't.
Oh, and I'm not bothering to fix it in IE6 anymore. Fuck IE.
Quote: |
If
you can't fix this issue then I'd say only one broken game is better
than two broken games. Especially with the popularity of the two. |
That's not the way I work. I know, I cheated with Uniracers. But the
thing there was that I didn't have any idea what the correct behavior
was. In this case, I mostly know. And I need this to be right to work
on fixing Mecarobot. Foundation, stepping stones, and all that.
In fact, it's quite possible the HDMA sync behavior is correct, and SoM is just hitting the same other bug that Mecarobot is hitting. I'll run some traces on it tomorrow to make sure.
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Wed Apr 02, 2008 7:16 am Post subject: |
|
byuu your website looking good so far.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 7:39 am Post subject: |
|
Looking
good, I see your aesthetic is simpler than mine (either that, or you're
trying to conserve bandwidth again). I'll have to at least make you
some new corners, yours are looking kind of rough since I didn't
originally design them against a transparent background (yeah, I see
what you did there.)
If anyone wants to see my fancypants version, you can dl it here:
http://www.megaupload.com/?d=1G2FHL6V
-------------------------
Sadly the new changes to the d3d renderer didn't help for me. I don't
know if it's because I'm using an ATI card, but I wouldn't be
surprised. I have created a hopelessly entitled comparison. Oddly,
certain modes like 2x unstretched appear fine, so it's like the math is
working in certain combos and making blurry remainders in others. Game
used was the title screen of "Jaleco Rally - Big Run - The Supreme 4WD
Challenge (SHVC-BR-JPN) (v1.0)"
 |
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Apr 02, 2008 8:44 am Post subject: |
|
byuu wrote: |
Redesigned my site. |
I still miss the dark blue theme you had with white text a while back
(maybe I'm the only one), but I do agree that this new one is brighter
and more inviting then the shades of purple you had previously.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Apr 02, 2008 12:57 pm Post subject: |
|
Another
redesign... Oh dear. A fixed width image so it can't even be 'fixed' in
Stylish too. If I had a stone, I'd certainly launch it in FitzRoy's
direction, retrieve it, and repeat. 
_________________
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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 1:13 pm Post subject: |
|
Well,
you must hate books then, because they're a fixed width, too. I think
it's better for reading not to have your left and right margins going
from one side of the monitor to the other, even more so on widescreen
monitors. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 2:35 pm Post subject: |
|
Quote: |
I'll
have to at least make you some new corners, yours are looking kind of
rough since I didn't originally design them against a transparent
background (yeah, I see what you did there.) |
Yeah, KolourPaint didn't have a translucency leveled pixel (that I
saw), and to hell with using GIMP. So it was 100% transparency or bust.
Just be sure if you do to keep the width at 720px, please :)
Quote: |
Sadly
the new changes to the d3d renderer didn't help for me. I don't know if
it's because I'm using an ATI card, but I wouldn't be surprised. |
Oh, crap. Looks like you're right. I get the same thing on my X300 LS.
It works fine on all my nVidia cards, though.
Only fails at 3x and higher. Very strange indeed ... we should
investigate, maybe it's a bug in their drivers that cannot be fixed.
Given that it works with nVidia, I wouldn't be surprised.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Apr 02, 2008 2:40 pm Post subject: New WIP incorrectly compiled |
|
Hi FitzRoy & byuu,
Quote: |
Sadly the new changes to the d3d renderer didn't help for me. |
I tested the new WIP bsnes v0.030.05 binary and the Direct 3D Scaling bug was still there even for me!!
I looked at the bsnes v0.030.05 source and it was correct to what I gave byuu.
byuu must have compiled it incorrectly, so all I did was compile it again from scratch and it works!
FitzRoy I have sent the link to the correct binary to your P.M so you can see it does indeed work =D
byuu you can compile the new WIP, after deleting all the .o object files, and it should work for you too =D
Last edited by krom on Wed Apr 02, 2008 3:02 pm; edited 1 time in total
|
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Apr 02, 2008 2:58 pm Post subject: Re: New WIP incorrectly compiled |
|
krom wrote: |
Hi FitzRoy & byuu,
Quote: |
Sadly the new changes to the d3d renderer didn't help for me. |
I tested the new WIP bsnes v0.030.05 binary and the Direct 3D Scaling bug was still there even for me!!
I looked at the bsnes v0.030.05 source and it was correct to what I gave byuu.
byuu must have compiled it incorrectly, so all I did was compile it again from scratch and it works!
FitzRoy I have sent the link to the correct binary to your P.M so you can see it does indeed work =D
byuu you can compile the new WIP after deleting all the .o files object and it should work for you too =D
|
That may well be the case. I noticed earlier while messing with bsnes
that if I changed the Direct3D driver code, using cc.bat would fail to
detect the change and I'd have to use clean.bat for it to work.
Edit: whoa, do I have a habit of starting new pages in this thread or what?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 3:01 pm Post subject: |
|
Quote: |
byuu must have compiled it incorrectly, so all I did was compile it again from scratch and it works! |
No, I recompiled the entire program before making the WIP release. I always
do that. I also saw the change in the nVidia output. After that, I made
several other changes, compiled it on Linux, and then switched back and
made the Windows release.
Maybe we have different SDK versions or something.
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Wed Apr 02, 2008 3:14 pm Post subject: |
|
Quote: |
No, I recompiled the entire program before making the WIP release. I always do that. |
That is what I assumed you would do, so I thought it very strange if it was that...
Quote: |
Maybe we have different SDK versions or something. |
I am using the direct x header/lib files from:
http://alleg.sourceforge.net/wip.html
I uncompress dx80_mgw.zip over the mingw/include and lib directories so that I can compile bsnes/mame etc...
I also use the define -DD3DVECTOR_DEFINED to get bsnes to compile correctly so maybe you could try using that...
I really do not understand why it does not compile right for you.
byuu I have sent you the P.M link to my binary for you to check out.
P.S I have a nvidia 6800 gfx card so when I checked out the new wip it did not work for me until I recompiled...
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Apr 02, 2008 3:38 pm Post subject: |
|
Hmm,
how can you force this problem to occur? I tried forcing
caps.stretchrect to false right after it tests for it, but don't see
any difference between 0.030 and 0.030 wip 5.. Although it does mess up
the screen if I toggle aspect ratio during runtime - but I guess you
can't blame it for something caused by my mutilating the code. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 4:36 pm Post subject: |
|
Okay, traced Secret of Mana (U) to figure out what was causing the flickering. More of the same.
Code: |
***********
*** bad ***
***********
008a6c stx $210d [$00210d] A:0107 X:00a4 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzC V: 82 H:1096
* M7HOFS = a4 @ 82,1126
* M7A = b6 @ 82,1144
* M7A = 01 @ 82,1152
* M7B = 51 @ 82,1168
* M7B = fe @ 82,1176
* M7C = ae @ 82,1192
* M7C = 01 @ 82,1200
* M7D = b6 @ 82,1216
* M7D = 01 @ 82,1224
* M7VOFS = 97 @ 82,1240
* M7VOFS = 01 @ 82,1248
008a6f sty $210d [$00210d] A:0107 X:00a4 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzC V: 82 H:1272
* M7HOFS = 02 @ 82,1308
************
*** good ***
************
008a6c stx $210d [$00210d] A:0007 X:00a5 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzc V: 82 H:1108
* M7A = b2 @ 82,1148
* M7A = 01 @ 82,1156
* M7B = 4d @ 82,1172
* M7B = fe @ 82,1180
* M7C = b2 @ 82,1196
* M7C = 01 @ 82,1204
* M7D = b2 @ 82,1220
* M7D = 01 @ 82,1228
* M7VOFS = 95 @ 82,1244
* M7VOFS = 01 @ 82,1252
* M7HOFS = a5 @ 82,1298
008a6f sty $210d [$00210d] A:0007 X:00a5 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzc V: 82 H:1298
* M7HOFS = 02 @ 82,1328 |
The game tries to write to M7HOFS by hand right at the same time HDMA
triggers. If it gets in one write to M7HOFS, then HDMA triggers, then
it gets the second write in to M7HOFS, it throws off the mode 7 latch
register and you get invalid values in the M7* registers, causing the
map to flicker.
The timing for this stuff is just insane. We're talking ~2-4 clock
ticks off somewhere, and it's just failing miserably as a result.
Sadly, it's extremely difficult to track down where the timing
discrepancy is. With MK2, it was easy because "wai" was the only opcode
being executed. Here, there's all kinds of opcodes. Any of them could
have some sort of timing flaw.
EDIT: a bit more verbose info ...
Code: |
008a6c stx $210d [$00210d] A:0007 X:00b7 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzc V: 83 H:1094
* HDMA begin @ 83,1110
* HDMA DMASYNC @ 83,1118
* M7HOFS = b7 @ 83,1124
* HDMA run @ 83,1124
* M7A = 74 @ 83,1148
* M7A = 01 @ 83,1156
* M7B = 17 @ 83,1172
* M7B = fe @ 83,1180
* M7C = e8 @ 83,1196
* M7C = 01 @ 83,1204
* M7D = 74 @ 83,1220
* M7D = 01 @ 83,1228
* M7VOFS = 75 @ 83,1244
* M7VOFS = 01 @ 83,1252
008a6f sty $210d [$00210d] A:0007 X:00b7 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzc V: 83 H:1276
* HDMA CPUSYNC @ 83,1276
* M7HOFS = 02 @ 83,1314 |
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 5:49 pm Post subject: |
|
Off
topic now (because it's already been discussed), but byuu, I really
like your new site design. It's a lot more pleasing on the eye, and it
seems like you've made much better use of space. Everything, while
having the same basic layout, just looks more organized.
However, to improve accessibility, you might want to increase font
weight (boldness), and make text slightly bigger. My eyesight is fine,
but my focus is terrible, so bigger text will help for me (and for
others with even worse eyesight, it will help immensely), and I'm sure
others might feel this way.
Also, the white background behind the text could be made a bit "grayer". Not too gray, only slightly.
I'm quite skilled with XHTML and CSS myself, maybe I might give some suggestions sometime...
(I've got a design that's really good that I might like to show you,
though I haven't looked at the code for a while and I need to edit some
of it, drop down menus, "dynamic" link menus, etc, all with CSS:
Though, it doesn't work at all in IE6 and below; I've implemented hacks
that are only detectable by IE6, and made IE follow different rules to
make it compatible, though the design is different. Also, IE7 fucks up
too, so I have to hack for that to work. I haven't tested IE8 yet (I
believe there's a beta, though I'm not sure it's available to the
public)).
Heh, at one time, just for fun, I played around with the CSS I wrote,
and added a few things to the markup, and made a "Ie detected, access
denied" hack. Basically, made IE not display div#content (the things
where everything is), and print that text. I modify the CSS so that
non-ie browsers don't disaply the "ie - access denied" text. Next to
the "access denied - ie detected" things, I put a picture of "the
scream" (you know, that painting of someone screaming in some orange
sky on what looks like some kind of balcony/boat/thing (this).
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Wed Apr 02, 2008 7:12 pm; edited 2 times in total |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Apr 02, 2008 6:11 pm Post subject: |
|
Franky wrote: |
I haven't tested IE8 yet (I believe there's a beta, though I'm not sure it's available to the public). |
There is
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 6:36 pm Post subject: |
|
Franky wrote: |
However,
to improve accessibility, you might want to increase font weight
(boldness), and make text slightly bigger. My eyesight is fine, but my
focus is terrible, so bigger text will help for me (and for others with
even worse eyesight, it will help immensely), and I'm sure others might
feel this way. (btw, I understand that I can increase font size in
my browser, but it might affect the page layout, which is why I'm
suggesting you do it in the code behind)
Also, the white background behind the text could be made a bit "grayer". Not too gray, only slightly.
|
??? The vast majority of the sites on the web use a default font size
as large or smaller than what he is using. I'd say you're having
technical difficulties on your end.
Moreover, black against white is THE LARGEST perceptible color
disparity. Nothing is more readable than that. Look at the quote boxes
in this forum. That's literally dark gray text on a light gray
background. Yet I haven't heard a soul complain about legibility here.
Last edited by FitzRoy on Wed Apr 02, 2008 6:41 pm; edited 2 times in total
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 6:39 pm Post subject: |
|
No,
I am not having technical difficulties. All I'm saying is that the font
could be made slightly bigger to make it easier to read.
(by "accessibility", I mean "how easy it is to read for all people,
including those who are visually impaired" -- I fall into that
category, somewhat (I have a lazy eye so I can't keep both eyes fixed
at one point; bigger text will be easier to read, likewise, people who
have blurred vision will be able to see it better).
I'm not saying there's anything wrong with it. It's absolutely fine.
In fact, increase text size too much and it will make the text look too
big. Just increase it slightly, like size 18px or something. Do that,
and instead of being fine, it will be super fine.
Quote: |
Moreover,
black against white is THE LARGEST perceptible color disparity. Nothing
is more readable than that. Look at the quote boxes in this forum.
That's literally dark gray text on a light gray background. Yet I
haven't heard a soul complain about legibility here. |
I know it's the best for readability; but pure white can make some
people's eyes hurt after a while, darken it down a bit (only slightly; almost pure white, with just a small hint of grey).
I'm not exactly saying byuu has to do it. It's only a suggestion.
Either way, I can read everything without problems. It's just that if
you make it that much better, it will be that much better, don't you think?
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Wed Apr 02, 2008 7:39 pm; edited 3 times in total
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 6:48 pm Post subject: |
|
I'm
sorry about your condition, but rather than trying to change the entire
internet for a minority affliction, you should probably just use your
browser's built-in font controls. It's not that complex of a site so it
shouldn't create any layout problems. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 6:54 pm Post subject: |
|
FitzRoy wrote: |
I'm
sorry about your condition, but rather than trying to change the entire
internet for a minority affliction, you should probably just use your
browser's built-in font controls. It's not that complex of a site so it
shouldn't create any layout problems. |
That's what I was doing anyway (I was just suggesting making the font
size a bit bigger so that it is done "automatically". It would help
people who need it, but won't make much difference for other people,
that way's everyone's happy).
I admit I'm being a little fussy. It's not like the bigger sizes and
the slight gray background is needed that much, it's just what I
prefer, really. <_<
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
Last edited by Franky on Wed Apr 02, 2008 7:05 pm; edited 1 time in total
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 7:02 pm Post subject: |
|
Will reply to others in a little bit.
In the mean time, I may have found the SoM issue:
Code: |
008a6c stx $210d [$00210d] A:0007 X:00d8 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzC V: 85 H:1096
1096 = opfetch
1104 = $0d fetch
* HDMA should begin here -- DMA sync begin
* cycle_edge() sees HDMA should start, logs HDMA begin correctly
* Sets to DMASYNC mode
1112 = $42 fetch
* DMASYNC complete -- HDMA should occur here
* Instead, set to DMARUN and we wait another cycle
1120 = $210d write <bus time = 1126>
1126 = next opfetch
* HDMA begin @ 85,1112
* HDMA DMASYNC @ 85,1120
* M7HOFS = d8 @ 85,1126
* HDMA run @ 85,1126
* M7A = 08 @ 85,1148
* M7A = 01 @ 85,1156
* M7B = d8 @ 85,1172
* M7B = fd @ 85,1180
* M7C = 27 @ 85,1196
* M7C = 02 @ 85,1204
* M7D = 08 @ 85,1220
* M7D = 01 @ 85,1228
* M7VOFS = 38 @ 85,1244
* M7VOFS = 01 @ 85,1252
008a6f sty $210d [$00210d] A:0007 X:00d8 Y:0002 S:01f1 D:0000 DB:00 nvMXdIzC V: 85 H:1276
* HDMA CPUSYNC @ 85,1276
* M7HOFS = 02 @ 85,1308 |
It looks like two clock cycles are occuring after HDMA triggers, when
only one should be. I will need to look into it further, though.
It doesn't fix Mecarobot Golf, but it would be nice to have SoM working again, obviously.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 7:03 pm Post subject: |
|
But
you don't want to make it more difficult for others. Large text can be
just as annoying to read for those who are capable of reading smaller
text, because it increases scrolling and eye movement by definition of
the text becoming larger. Should every site change to a 24 font size
because there are elderly people who can't see below that size?
You could also try darkening your monitor. Some people have LCDs with
highly intense backlights that need toning down. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 7:16 pm Post subject: |
|
FitzRoy wrote: |
But
you don't want to make it more difficult for others. Large text can be
just as annoying to read for those who are capable of reading smaller
text, because it increases scrolling and eye movement by definition of
the text becoming larger. Should every site change to a 24 font size
because there are elderly people who can't see below that size? |
Hmm, normal print size is about 16px. I'm not recommending anything
crazy like 24. 18px should do (though 20 would be nice). Just very
slight, subtle.
(Btw, my monitor isn't too bright.)
Maybe I forgot to mention this before, but I complain about the font
size on most sites, while most people have no problem. It's probably
just me, so you might want to take me 60% seriously, not 100.
I'm probably just being biased again.
"When possible, care for the minority, while not affecting the majority differently than before".
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Apr 02, 2008 7:50 pm Post subject: |
|
FWIW,
I wouldn't mind the text on byuu's homepage to be slightly bigger, if
it's not too much. The news post aren't really long enough that
scrolling should be a concern; perhaps use the current font size for
the longer articles? Mind you, I can read the text just fine, I'm just
saying a small change wouldn't bother me either way. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 8:00 pm Post subject: |
|
Franky wrote: |
Hmm, normal print size is about 16px. |
According to whom? Here in the states, all of my academic papers were 12.
How do you even read this forum, might I ask? Its text is basically the same.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 8:14 pm Post subject: |
|
Well, I'm only taking a guess that it's usually 16 (hence the "about").
...It's one of the common sizes people use
And like I said, I have problems with the text size on most places,
including here. Realistically, they're not going to increase the text
size, so usually I just do that myself on the browser.
I just thought I'd try and make it reality this time, through
suggestion....... (I usually just increase font size on my browser).
(PS: I can read the smaller texts just fine btw. My eyesight is fine,
but after a while (a minute or two minutes), my focus goes off (that's
what I means by lazy eye, it literally just looks in another direction,
and then obviously, my other eye (the good one) follows. That's when I
increase the text size if I haven't done so already). So really, I
shouldn't be complaining, and just learn to cope with the fact that I'm
retarded >_<
Maybe I should just quit complaining and get glasses <_<
Off-topic, but I've just noticed that everytime I try to make a
suggestion, it starts an argument (like when I posted what I thought
was a bug in bsnes, or as another example, the argument we're having
now).
>_<
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Wed Apr 02, 2008 8:29 pm Post subject: |
|
A
font size of 12 seems to be equivalent to a maximum character height of
16 pixels (the pipe symbol as an example) I dunno if this is just a
coincidence or a consequence of the difference between the 'pt' and
'px' units.. Mind you, actual character height does seem to be around
12 as well, so I dunno  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 9:27 pm Post subject: |
|
Okay, yeah, that was definitely the problem with SoM. Street Racer is working too, so now it's back down to just Mecarobot.
Without HDMA sync, I began HDMA immediately, which always forced M7HOFS
to write after HDMA. With HDMA sync, I was waiting two cycles instead
of one -- the extra eight clocks were enough to sometimes write M7HOFS
once before starting DMA.
With just one cycle delay, it works. And that's how it's supposed to
be. DMA is the same, I was just thrown off a bit.
Basically, (H)DMA has a few states: INACTIVE, DMASYNC, RUN and CPUSYNC.
When $420b is written, the mode is set to DMASYNC, and immediately
after, cycle_edge() is called which sets the mode to RUN right away.
Another cycle is executed, and cycle_edge() performs the DMA transfer.
One cycle delay.
Well, with HDMA, the test is inside
cycle_edge() -- since it's triggered based on time, and not based on a
register write. As a result, the function obviously doesn't get called
again right away. So it runs one cycle, then changes DMASYNC state to
RUN, just like DMA, then runs another cycle to actually perform the HDMA transfer.
Since I'm already in cycle_edge(), I just need to set HDMA init and
HDMA startup sync from INACTIVE to RUN, that way only one cycle will
pass.
That should hopefully get HDMA bus sync mostly correct now. Mecarobot
works better now -- it won't flicker when the map isn't moving, but
timing is still a tiny bit off somewhere. Unfortunately, the part it's
off at now is much harder to debug. Millions of instructions occurring
here -- no long wait loops abound. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 02, 2008 10:11 pm Post subject: |
|
What exactly was the problem with SoM?
I've completed that game on bsnes.
(Forgive me if I'm being ignorant again).
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
neo_bahamut1985 Trooper

Joined: 10 Sep 2007
Posts: 376
Location: USA - in front of the computer
|
Posted: Wed Apr 02, 2008 10:22 pm Post subject: |
|
Yeah,
strangely enough, I somehow was able to have no filtering (okay, the
nVidia filter), no scaling AND force-enable vsync, and be able to run
SoM at 60fps. Sure, I sometimes have a dip in fps, but, other than that, no speed issues. I can post a screenshot to show what I mean.
_________________
俺は手前の倒す男だ! お前は俺の剣を味わたいかな?
さあ, 戦え!! |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 02, 2008 11:18 pm Post subject: |
|
SoM's
mode7 intro was known to be timing sensitive and once flickered in the
same way that byuu's recent Mecarobot fix just reintroduced. Some games
are like see-saws for timing. If timing is off on one side, one game
breaks while the other appears fixed (but is merely working
serendipitously). Byuu didn't know Mecarobot Golf was broken until now,
so it reopened the HDMA case so to speak. If he can get all three known
games working, then it will be closed again. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Apr 02, 2008 11:36 pm Post subject: |
|
Mecarobot is going to be interesting ...
What ultimately happens is that it misses an IRQ here:
Good:
Code: |
009c6e lda #$40 A:0001 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:127 H:1332
009c70 sta $4207 [$194207] A:0040 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:127 H:1348
009c73 stz $4208 [$194208] A:0040 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:128 H: 14
009c76 lda $d7 [$0000d7] A:0040 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:128 H: 44
009c78 inc A:007e X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:128 H: 68
009c79 inc A:007f X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:128 H: 82
009c7a sta $4209 [$194209] A:0080 X:0006 Y:00be S:01e3 D:0000 DB:19 NvMxdIzc V:128 H: 96
009c7d rts A:0080 X:0006 Y:00be S:01e3 D:0000 DB:19 NvMxdIzc V:128 H: 126
008e4c ply A:0080 X:0006 Y:00be S:01e5 D:0000 DB:19 NvMxdIzc V:128 H: 168
008e4d plx A:0080 X:0006 Y:00be S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 204
008e4e pld A:0080 X:0060 Y:00be S:01e9 D:0000 DB:19 nvMxdIzc V:128 H: 240
008e4f plb A:0080 X:0060 Y:00be S:01eb D:0000 DB:19 nvMxdIZc V:128 H: 276
008e50 pla A:0080 X:0060 Y:00be S:01ec D:0000 DB:19 nvMxdIzc V:128 H: 304
008e51 xba A:0000 X:0060 Y:00be S:01ed D:0000 DB:19 nvMxdIZc V:128 H: 332
008e52 pla A:0000 X:0060 Y:00be S:01ed D:0000 DB:19 nvMxdIZc V:128 H: 352
008e53 plp A:0004 X:0060 Y:00be S:01ee D:0000 DB:19 nvMxdIzc V:128 H: 380
008e54 rti A:0004 X:0060 Y:00be S:01ef D:0000 DB:19 nvMxdIzC V:128 H: 408
* IRQ <requested @ 128, 64>
008e3d php A:0004 X:0060 Y:00be S:01ef D:0000 DB:19 nvMxdIzC V:128 H: 522 |
Bad:
Code: |
009c6e lda #$40 A:0001 X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 144
009c70 sta $4207 [$194207] A:0040 X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 160
009c73 stz $4208 [$194208] A:0040 X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 190
009c76 lda $d7 [$0000d7] A:0040 X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 220
009c78 inc A:007e X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 244
009c79 inc A:007f X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:128 H: 258
009c7a sta $4209 [$194209] A:0080 X:0006 Y:0232 S:01e7 D:0000 DB:19 NvMxdIzc V:128 H: 272
009c7d rts A:0080 X:0006 Y:0232 S:01e7 D:0000 DB:19 NvMxdIzc V:128 H: 302
008e4c ply A:0080 X:0006 Y:0232 S:01e9 D:0000 DB:19 NvMxdIzc V:128 H: 344
008e4d plx A:0080 X:0006 Y:0232 S:01eb D:0000 DB:19 nvMxdIzc V:128 H: 380
008e4e pld A:0080 X:00f8 Y:0232 S:01ed D:0000 DB:19 nvMxdIzc V:128 H: 416
008e4f plb A:0080 X:00f8 Y:0232 S:01ef D:0000 DB:19 nvMxdIZc V:128 H: 452
008e50 pla A:0080 X:00f8 Y:0232 S:01f0 D:0000 DB:19 nvMxdIzc V:128 H: 480
008e51 xba A:0000 X:00f8 Y:0232 S:01f1 D:0000 DB:19 nvMxdIZc V:128 H: 508
008e52 pla A:0000 X:00f8 Y:0232 S:01f1 D:0000 DB:19 nvMxdIZc V:128 H: 528
008e53 plp A:00f8 X:00f8 Y:0232 S:01f2 D:0000 DB:19 NvMxdIzc V:128 H: 596
008e54 rti A:00f8 X:00f8 Y:0232 S:01f3 D:0000 DB:19 nvmxdIzc V:128 H: 624
00a4fd cpy #$0166 A:00f8 X:00f8 Y:0232 S:01f7 D:0000 DB:19 nvmxdizc V:128 H: 676 |
It's either because IRQ behavior is slightly off; or because general
timing is off below, where the HDMA disable comes in just a bit too
late. Once the HDMA triggers, it throws off the time enough that the
above IRQ is missed. You can see that here:
Good:
Code: |
009b18 jmp ($9b1b,x) [$009b21] A:0006 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:127 H:1018
009c55 stz $420c [$19420c] A:0006 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:127 H:1064
009c58 lda #$07 A:0006 X:0006 Y:00be S:01e3 D:0000 DB:19 nvMxdIzc V:127 H:1094 |
Bad:
Code: |
009c55 stz $420c [$19420c] A:0006 X:0006 Y:0232 S:01e7 D:0000 DB:19 nvMxdIzc V:127 H:1096
* HDMA begin @ 127,1112
* HDMA run @ 127,1120
* M7A = f8 [f8ff] @ 127,1140
* M7A = 03 [03f8] @ 127,1148
* M7D = f8 [f803] @ 127,1172
* M7D = 03 [03f8] @ 127,1180
* M7B = 40 [4003] @ 127,1204
* M7B = 00 [0040] @ 127,1212
* M7C = c0 [c000] @ 127,1236
* M7C = ff [ffc0] @ 127,1244
* HDMA CPUSYNC @ 127,1260 |
Sigh, it's a shame there's nobody left to help with this stuff :(
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Apr 03, 2008 12:28 am Post subject: |
|
Perhaps
this discussion should go in a new thread? I say that because I
remember blargg mentioned that he'd given up on trying to follow this
one - dunno if he'd be able to help in this particular case, but it
might be true for other potential lurking geniuses  |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Apr 03, 2008 1:28 am Post subject: |
|
FitzRoy wrote: |
Moreover, black against white is THE LARGEST perceptible color disparity. Nothing is more readable than that. |
Actually black on yellow is the most perceptible difference. That's why
road condition signs have black text on yellow background. Its easiest
for the human brain to notice and read.
|
|
|
krom Rookie
Joined: 29 Sep 2007
Posts: 42
|
Posted: Thu Apr 03, 2008 1:30 am Post subject: Direct3D Scaling Bug |
|
Hi byuu,
I apologise for messing you about, your new WIP binary does work
perfectly for me, and all of the direct 3d scaling modes are sharp. I
have no idea why it was not working the first time I tested it...
At least we know we have sorted it for nvidia cards now =D
I do not have an ATI to test on so I would be coding in the dark. So
maybe you will have better luck at sorting that out, if you can see the
blurring that FitzRoy is seeing on your ATI setup.
P.S I am very impressed at the speed you fixed up SOM and Street Racer's HDMA  |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Apr 03, 2008 1:53 am Post subject: |
|
I tested the new wip on my ati card. The scaling is perfect on mine. I don't know what's wrong with FritzRoy's card. |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Thu Apr 03, 2008 1:55 am Post subject: |
|
FirebrandX wrote: |
Actually
black on yellow is the most perceptible difference. That's why road
condition signs have black text on yellow background. Its easiest for
the human brain to notice and read. |
We have white on reflective blue here (Holland)
Black on yellow may be easier to read (if appalling to look at), but
isn't something like white on dark blue easier to remember? Supposedly
staring at a bright image washes out your perceptual storage, although
they tested this by showing test subjects an image for a very short
time, then comparing their memory when the screen was bright afterwards
to when it was dark - so it may not transfer over to actually -reading-
larger amounts of text. It still seems like it would be more
comfortable though.
Edit: how recent is your ATI
card? If I'm not mistaken, this behaviour can only occur on cards that
don't support StretchRect, and all newer cards probably do. If you know
how to compile bsnes, you can forcibly disable it by placing a
caps.stretchrect = false; line right after it tests for the capability
in the init() function of Direct3D.cpp (sorry I don't have a line
number for you, messing with the code myself)
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 03, 2008 2:57 am Post subject: |
|
Regarding the street signs, yellow or orange might make for a more noticeable
sign in a gray, urban environment, but it technically doesn't beat
white for readability. That's just an application in which the
attribute of distinction made yellow the better choice despite its
small cost to readability.
I am using an ATI X600SE. I may have mistakenly said x300se earlier, but I just looked at my control panel. |
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Thu Apr 03, 2008 6:22 am Post subject: |
|
FitzRoy wrote: |
Regarding the street signs, yellow or orange might make for a more noticeable
sign in a gray, urban environment, but it technically doesn't beat
white for readability. That's just an application in which the
attribute of distinction made yellow the better choice despite its
small cost to readability.
I am using an ATI X600SE. I may have mistakenly said x300se earlier, but I just looked at my control panel. |
Research was done on human optical perception of colors, and that's why
they chose black on yellow. I am of course talking about reading signs
at night. Its not my "opinion", its simply the conclusions made from
tests. This what I had heard at least, as to why road warning signs
were black on yellow. That it was easiest to read and notice at night.
Also to verdauga, we also have white reflective on blue, but that
scheme is reserved for "information" signs. We also have white on red
for stop signs. The black on yellow I was referring to is used for
"warning" signs like the "slippery when wet" sign that shows the car
leaving curved tracks behind.
BTW my card is a fairly recent Radeon 3850 HD
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Apr 03, 2008 12:38 pm Post subject: |
|
FitzRoy wrote: |
Well,
you must hate books then, because they're a fixed width, too. I think
it's better for reading not to have your left and right margins going
from one side of the monitor to the other, even more so on widescreen
monitors. |
Yes, clearly you can tell me what the best width is on my monitor and
setup for readability and I don't need the choice to decide for myself.

And clearly, your fixed width must look the same and be optimal on all
monitors at all resolutions. Nobody would have any valid reason for
needing a different width since yours is obviously the best in all
cases. [/sarcasm]
At least the way the site was before without the image, it could be
overridden . Problem solved. Now, you can't even do that. FitzRoy FTL.
_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 03, 2008 1:44 pm Post subject: |
|
Quote: |
your fixed width must look the same and be optimal on all monitors at all resolutions. |
That's exactly why it's optimal, because regardless of the increasing
expanse of the monitor's width, the margins won't follow it into
absurdity.
Quote: |
At least the way the site was before without the image, it could be overridden. |
How do you hope to accomplish any kind of great looking design if you declare that your text margins must
be definable in all cases? And if text at a chosen size is confined in
a way that mimics standard document margins, what exactly have you lost?
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Apr 03, 2008 5:22 pm Post subject: |
|
FitzRoy wrote: |
Quote: |
your fixed width must look the same and be optimal on all monitors at all resolutions. |
That's exactly why it's optimal, because regardless of the increasing
expanse of the monitor's width, the margins won't follow it into
absurdity.
|
Yeah... You seem to assume nobody with a widescreen monitor (or
otherwise) knows how to use windows for browsing...
Secondly, with increasing resolution and monitor size, your design
simply gets smaller and smaller into absurdity.
The blank space keeps growing and growing. With other way around, the
user can view whatever size windows they wish. No FORCED absurdity.
Quote: |
Quote: |
At least the way the site was before without the image, it could be overridden. |
How do you hope to accomplish any kind of great looking design if you declare that your text margins must
be definable in all cases? And if text at a chosen size is confined in
a way that mimics standard document margins, what exactly have you lost?
|
The design should scale with size... Margins should be proportional.
See slashdot for reference of a scalable text based site.
Second example:
DeJap
It doesn't need to be, just scalable with resolution and screen size.
It's just inconsiderate to shove a fixed size to everyone just because
it looks good at your resolution and monitor.
I wouldn't even be complaining if you could simply use Stylish to
override the CSS. But thanks to the choice of using a 720px long image,
it won't work. All you need to do instead of having a big long 720px
image like that is break it up into a left/right corner image and
either have a repeating center piece that will repeat with to fill the
given width or just use white as a background color which would
probably look the same too. Simple as pie, you can keep your fixed size
design and still offer others a way to change it. I could think of a
few other alternatives as well to keep the site looking identical for
you and allow it to look better for others. Is it really necessary to
use a big 720px wide top and bottom bar images?
_________________
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 03, 2008 6:30 pm Post subject: |
|
So
essentially, you're not arguing that increased width of the window
afflicts the readability as 720 confined within that is perfectly
sufficient, but that for people who restore down and resize their
browser window to a width that is less than 720, it will require
undesirable scrolling. Yet that Dejap website uses fixed width images
for its menu bar to its aesthetic advantage, does it not? I'm not
seeing this perfect world in which the diversity of design is
sacrificed for a reduction in scrolling for a minority audience. |
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Thu Apr 03, 2008 7:28 pm Post subject: |
|
Fixed
width is useful if you want to maintain consistent visual appearance
between multiple resolutions. There are a few downsides, yes, but
probably not enough to justify the expenditure of time to rework it.
I mean, hell, Microsoft and Yahoo have fixed width pages.
Yes, you can split the corner images apart, the problem with that is
alignment. Getting the whole thing to line up correctly in all of the
major browsers is a serious PITA. I've done it before and I wouldn't
want Byuu to have to mess with it unless he has a real taste for CSS
hacking. |
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Thu Apr 03, 2008 7:48 pm Post subject: |
|
What
I don't get is how people keep talking about readability. For Firefox,
Opera and Internet Explorer you can change the text display size by
holding down CTRL and scrolling your mouse wheel.
Anyhow, I was digging around my old web development folders and I found
the test page I did with rounded corners and variable width. Has my
name and email address, but the information is several years out of
date, so I don't really care.
http://www.digitalannex.net/users/palin/rounded_test/
*EDIT* Damn, the XHTML spec changed slightly since the last time I validated it  |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Thu Apr 03, 2008 7:54 pm Post subject: |
|
Gil_Hamilton wrote: |
Mecarobot Golf sucks.
Solely because with a name like that, I expected some sort of giant
robot violence(sort of like Ninja Golf, but with mechs) and all I got
was golf. |
Lol I thought it's pretty decent for a 16bit era game game.
Anyway I've confirmed the bug doesn't happen on hardware.
Copier still works with some games for some reasons...and it doesn't
have anything to do with the game size either (the 32mb ram is divided
into 2 parts...so that might have been it)
As it is, the bug isn't particularly severe in bsnes in that it doesn't
prevent play but it does flash/flicker, which is not present on the
console.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Apr 03, 2008 7:57 pm Post subject: |
|
Palin wrote: |
What
I don't get is how people keep talking about readability. For Firefox
[...] you can change the text display size by holding down CTRL and
scrolling your mouse wheel. |
It's not perfect yet with the current version (but I've seen it being
greatly improved in the preview of the next one).
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Thu Apr 03, 2008 8:49 pm Post subject: |
|
Wow. That's freakin awesome. I'm surprised more sites don't have a
little toolbar like that. The font sizes could be handled by the
browser, sure, but that one-click fixed width button is wicked.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 03, 2008 9:41 pm Post subject: |
|
I
like that he's trying to sell it. Someone should tell him about the
view source option in web browsers. I'll see if I can add that to my
site. |
|
Palin Lurker

Joined: 08 Nov 2005
Posts: 106
|
Posted: Thu Apr 03, 2008 9:56 pm Post subject: |
|
It's
not that he's selling the code, exactly, he's selling a method to
generate the code (I pray.) If you actually pull up the CSS sheet for
that page it's barely human readable. I'm assuming its partially
generated after you hand it some criteria. |
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Thu Apr 03, 2008 11:52 pm Post subject: |
|
byuu wrote: |
I
like that he's trying to sell it. Someone should tell him about the
view source option in web browsers. I'll see if I can add that to my
site. |
Are you referring to the Joomlashack template I linked above?
Joomlashack ( http://www.joomlashack.com/ ) specializes in templates for Joomla, as does RocketThemes... http://www.rockettheme.com/
Joomla is a content management system and web application framework...
http://www.joomla.org/
The whole thing is database driven php with templates. It's a
completely different way to do it, but once you experience Joomla,
you'll never go back to building a website the old fashioned way.
With Joomla, you intall the default package, then upload templates and
modules and configure them using their administration UI. You never
have to touch HTML or CSS if you don't want to.
For my warcraft site, http://www.tankadin.com , I'm using the following:
Joomla
Rubicon 2.0 template
SMF forums (with my own custom style)
Community Builder
Joomlahacks SMF bridge
sh404sef (for search engine friendly URLs)
|
|
Panzer88 Zealot

Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
|
Posted: Fri Apr 04, 2008 1:52 am Post subject: |
|
FitzRoy wrote: |
Well,
you must hate books then, because they're a fixed width, too. I think
it's better for reading not to have your left and right margins going
from one side of the monitor to the other, even more so on widescreen
monitors. |
well, the thing is a book you can easily zoom in or out by holding it
closer or further away from your face, furthermore a book is not
software, and not adjustable, whereas software us built to be
adjustable for multiple peoples needs in multiple settings.
Palin wrote: |
I mean, hell, Microsoft and Yahoo have fixed width pages. |
ehy use them as examples, their websites are hidious
that's like saying internet explorer should be the standard for web browsers.
_________________
I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 04, 2008 4:06 am Post subject: |
|
Panzer88 wrote: |
FitzRoy wrote: |
Well,
you must hate books then, because they're a fixed width, too. I think
it's better for reading not to have your left and right margins going
from one side of the monitor to the other, even more so on widescreen
monitors. |
well, the thing is a book you can easily zoom in or out by holding it
closer or further away from your face, furthermore a book is not
software, and not adjustable, whereas software us built to be
adjustable for multiple peoples needs in multiple settings.
|
What does zooming have to do with sensible margin cutoffs and can you
not also zoom in to a screen with your face? Seriously, people need to
stop arguing with me on this. If you need "adjustability" below 720
pixels, the bsnes website is the least of your problems. The whole
godless internet is going to break in front of your eyes. No one is
going to impose design limitations for all because of a minority.
|
|
sinamas Gambatte Developer

Joined: 21 Oct 2005
Posts: 109
Location: Norway
|
Posted: Fri Apr 04, 2008 7:23 am Post subject: |
|
I'm
not at all interested in making web pages, but making the number of
words per line dependent on the DPI of your monitor/font size seems
pretty silly to me, especially if you can do things like specify
max-width in "m"s. But then again I've gotten allergic (from too much
exposure) to media designer/advertising ass hats who insist on making
all sorts of annoying constraints because they can make things
"fancier" and they just know better than the user. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Fri Apr 04, 2008 8:28 am Post subject: |
|
Quote: |
that's like saying internet explorer should be the standard for web browsers. |
That would be a cold day in hell.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Apr 04, 2008 12:32 pm Post subject: |
|
Yes, another example of an intelligent web site design indeed. Thumbs
up. I wish they went with strict XHTML or 1.1 though. Transitional
defeats much of the purpose of using XHTML to begin with. They're using
several presentation attributes rather than CSS that wouldn't be in
XHTMl strict such as 'align'. That makes me question their definition
of 'cutting edge CSS'. hehe
_________________
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.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Fri Apr 04, 2008 12:43 pm Post subject: |
|
FitzRoy wrote: |
So
essentially, you're not arguing that increased width of the window
afflicts the readability as 720 confined within that is perfectly
sufficient, but that for people who restore down and resize their
browser window to a width that is less than 720, it will require
undesirable scrolling. Yet that Dejap website uses fixed width images
for its menu bar to its aesthetic advantage, does it not? I'm not
seeing this perfect world in which the diversity of design is
sacrificed for a reduction in scrolling for a minority audience. |
You have no idea what I'm talking about. I'm not talking about
scrolling nor stifling diversity of design. Either I've done a poor job
explaining or you are too narrow minded to see my point. DeJap is a
scalable website to most resolutions, devices, DPI settings, monitor
size, and window size big and small. Same can be said for the joomla
template above. Your design is not. The larger the resolution for
example, the more EMPTY space around it and SMALL the column becomes
into absurdity as you like to call it. Readability becomes more and
more poor.
P.S. Microsoft and Yahoo though fixed are significantly wider making less of an issue at higher resolutions.
_________________
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.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Fri Apr 04, 2008 12:57 pm Post subject: |
|
Nightcrawler wrote: |
I wish they went with strict XHTML or 1.1 though. Transitional defeats much of the purpose of using XHTML to begin with. |
Sending a page as "text/html" so that Internet Explorer will render it defeats much of the purpose of using XHTML anyway.
Fitzroy: The thing about a book is that I can put it pretty much
anywhere in my 50-square-metre apartment and it still works fine, while
a website has to fit on an LCD panel that's maybe a quarter of a square
metre - and it has to share that LCD panel with whatever other stuff I
might be doing at the same time. Also, (and this doesn't really apply
to byuu's site, but in general) some people occasionally view websites
from phones or PDAs or other devices with small screens. Yes, limiting the width of the text column is a good idea for readability, and yes
nailing the text-column width to an arbitrary guesstimate like ~700px
is a quick and dirty hack that gets the job done, but why not do it
right, especially when "right" is as easy as "max-width: 40em;"?
And now, back to your regularly-scheduled SNES emulation thread.
|
|
|
wertigon Rookie
Joined: 07 Aug 2004
Posts: 24
|
Posted: Fri Apr 04, 2008 1:27 pm Post subject: |
|
Just
want to point out that I'm also a fan of using ems for width, and
flexible designs. That's from a guy whom has designed up quite a few
government- and EU-level sites, where accessibility is a major factor,
though contracts forbid me to discuss them.
I stopped using transitional in 2003-2004 sometime and haven't looked back. And my contractors love me for it. ^^ |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 04, 2008 1:41 pm Post subject: |
|
Nightcrawler wrote: |
FitzRoy wrote: |
So
essentially, you're not arguing that increased width of the window
afflicts the readability as 720 confined within that is perfectly
sufficient, but that for people who restore down and resize their
browser window to a width that is less than 720, it will require
undesirable scrolling. Yet that Dejap website uses fixed width images
for its menu bar to its aesthetic advantage, does it not? I'm not
seeing this perfect world in which the diversity of design is
sacrificed for a reduction in scrolling for a minority audience. |
You have no idea what I'm talking about. I'm not talking about
scrolling nor stifling diversity of design. Either I've done a poor job
explaining or you are too narrow minded to see my point. DeJap is a
scalable website to most resolutions, devices, DPI settings, monitor
size, and window size big and small. Same can be said for the joomla
template above. Your design is not. The larger the resolution for
example, the more EMPTY space around it and SMALL the column becomes
into absurdity as you like to call it. Readability becomes more and
more poor.
P.S. Microsoft and Yahoo though fixed are significantly wider making less of an issue at higher resolutions.
|
I know exactly what you're talking about, but you're blind to costs.
Sure, the joomla website will scale to infinity, but that creates
ridiculous margins in a maximized state, which is the state in which
most people browse (and yes, I know you use some special plugin to dick
with this, but let's get realistic). Depending on the way the site is
designed, it also creates just as much empty space, but in different
places. It doesn't help your argument that the joomla design is one of
those space-filler designs that fills what you find undesirable with
illogical fluff such as... a side and top navigation bar which serve
the same function, a massive banner and two boxes which push actual
content below my monitor's resolution, literally requiring me to scroll
down on every page just to get to the reading material if one were to
actually use this design.
That said, I'm not totally opposed to Thristian's suggestion, but it's
only really needed for people who browse on teeny devices, and byuu has
told me personally that he doesn't give two shits about those people,
so your beef is now with him if you want to argue for it.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 04, 2008 3:14 pm Post subject: |
|
Quote: |
so your beef is now with him if you want to argue for it. |
Please no. I'm not responding, and I don't even want to read about it anymore.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Fri Apr 04, 2008 3:28 pm Post subject: |
|
wertigon wrote: |
Just
want to point out that I'm also a fan of using ems for width, and
flexible designs. That's from a guy whom has designed up quite a few
government- and EU-level sites, where accessibility is a major factor,
though contracts forbid me to discuss them.
I stopped using transitional in 2003-2004 sometime and haven't looked
back. And my contractors love me for it. ^^ |
"I have a giant robot. But I can't show you."
Without proof, we won't believe you.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 04, 2008 9:10 pm Post subject: |
|
Well, that was a fun waste of time.
Yet another error in the w65c816s documentation:
Quote: |
8.11.1 When in the Native mode, the Program Bank register (PBR) is cleared to 00 when a
hardware interrupt, BRK or COP is executed. In the Native mode, previous PBR contents are automatically
saved on Stack.
8.11.2 In the Emulation mode, the PBR and DBR registers are cleared to 00 when a hardware
interrupt, BRK or COP is executed. In this case, previous contents of the PBR are not automatically saved. |
8.11.2 is bullshit. DBR is not cleared when an interrupt occurs in emulation mode.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Fri Apr 04, 2008 11:29 pm Post subject: |
|
Is it wise to put that kinda critical detail in the monster thread where it's easy to lose anything, byuu ?
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Apr 04, 2008 11:52 pm Post subject: |
|
Nothing gets lost in the monster thread. Nothing! |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Apr 05, 2008 2:13 am Post subject: |
|
byuu wrote: |
Well, that was a fun waste of time.
Yet another error in the w65c816s documentation:
Quote: |
8.11.1 When in the Native mode, the Program Bank register (PBR) is cleared to 00 when a
hardware interrupt, BRK or COP is executed. In the Native mode, previous PBR contents are automatically
saved on Stack.
8.11.2 In the Emulation mode, the PBR and DBR registers are cleared to 00 when a hardware
interrupt, BRK or COP is executed. In this case, previous contents of
the PBR are not automatically saved. |
8.11.2 is bullshit. DBR is not cleared when an interrupt occurs in emulation mode.
|
Alright, more discoveries and more accurate Snes emulation. Does that
mean that both Secret of Mana and Mecarobot golf works at the same time
now?
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Apr 05, 2008 2:26 am Post subject: |
|
No. Mecarobot is still broken, that one can't be fixed.
I just saw the DBR thing, never heard about it before, so I wrote a
test for it. The doc was wrong, but I had that right to begin with.
Hence, waste of time. |
|
Y~K Hazed

Joined: 22 Jan 2007
Posts: 52
|
Posted: Sat Apr 05, 2008 5:39 am Post subject: |
|
Why don't you lock this topic byuu? Let the forum expand. 
_________________
Join the United datters saving history for eternity

Official Community |
|
Snark Trooper

Joined: 31 Oct 2006
Posts: 433
|
Posted: Sat Apr 05, 2008 5:37 pm Post subject: |
|
Y~K wrote: |
Why don't you lock this topic byuu? Let the forum expand.  |
But a whopping 225+ page thread is cool!
I don't know, general info could go in the big thread and the more
specific issues or vital info (like byuu's recent discoveries in the
mecarobot golf thread) in more specifics threads. Seem to work so far.
All that of course supposing there' no technical server limitations
having been reached due to the size of the thread.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Apr 05, 2008 8:22 pm Post subject: |
|
Snark wrote: |
Y~K wrote: |
Why don't you lock this topic byuu? Let the forum expand.  |
But a whopping 225+ page thread is cool!
|
Reply to this thread.
At least documentation errors are logical and consistent. As opposed to
no-ops extending the IRQ initiation, which break brains. Damn
microprocessors acting fickle like humans.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Apr 07, 2008 12:45 pm Post subject: |
|
Thristian wrote: |
Nightcrawler wrote: |
I wish they went with strict XHTML or 1.1 though. Transitional defeats much of the purpose of using XHTML to begin with. |
Sending a page as "text/html" so that Internet Explorer will render it
defeats much of the purpose of using XHTML anyway.
|
That's certainly true. That's another problem on the Internet that
started thanks to Internet Explorer. It still applies with IE7
unfortunately (and IE8 beta 1). So, until MS ever gets their act
together it's unlikely the majority of XHTML will be served as text/xml.
However, IF you use XHTML 1.1, that already requires the proper PCDATA
escaping of <script> if I recall and forces presentation to be in
style sheets as all legacy HTML tag and presentation attribute support
was dropped. XHTML 1.1 is just a step further in the right direction
and there would be much less issue when converting to text/xml when
feasible.
So, it's a half step. That much I admit. XHTML will not truly be able
to be used to it's purpose until it is served with the correct XML MIME
type. I guess I'm an advocate for coming as close as possible in the
meantime which is XHTML 1.1 validation in my opinion. Or at least XHTML
1.0 strict. Transitional really isn't useful at all if you ask me. It
does nothing for presentation separation. At least it requires proper
tag opening and closing. That's better than nothing I guess!
P.S. Internet Explorer really seems to be the single handed cause of
most all of the set backs and problems web development has today. I
suppose some of us need to start having the brass to just shut out all
IE uses from our sites and do things the right way. I just would feel
bad for those who have to us IE at work, school, or library and would
be unjustly shut out. We don't always have a choice when browsing.
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 07, 2008 3:37 pm Post subject: |
|
My host updated his domain name, my site is now located at:
http://byuu.hellomynameisinigomontoyayoukilledmyfatherpreparetodie.com/
Quote: |
I suppose some of us need to start having the brass to just shut out all IE uses from our sites and do things the right way. |
That's pretty much what I do now. I added a text-align: center; to the
body for IE centering, and left it at that. I just get new layouts
readable (for those with no choice), and move on.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Apr 07, 2008 3:43 pm Post subject: |
|
byuu wrote: |
http://byuu.hellomynameisinigomontoyayoukilledmyfatherpreparetodie.com |
That looks like a belated April Fools joke ... Nice choice though
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 07, 2008 4:06 pm Post subject: |
|
Not April Fools, the link works ;)
Of course, if you still want to use the old .org or
.cinnamonpirate.com, you could. But why would you? The new domain is so
much cooler. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Apr 08, 2008 12:21 am Post subject: |
|
byuu wrote: |
My host updated his domain name, my site is now located at:
http://byuu.hellomynameisinigomontoyayoukilledmyfatherpreparetodie.com/
Quote: |
I suppose some of us need to start having the brass to just shut out all IE uses from our sites and do things the right way. |
That's pretty much what I do now. I added a text-align: center; to the
body for IE centering, and left it at that. I just get new layouts
readable (for those with no choice), and move on.
|
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Tue Apr 08, 2008 7:54 am Post subject: |
|
to be clear: you should not be using absolute units for media that has unfixed dimensions.
ie, stuff that is displayed in a window.. you use units like em, points
and picas for media that has fixed dimenisions, like paper, stuff like
larger, smaller and percentage is for use on stuff like the web.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Tue Apr 08, 2008 12:33 pm Post subject: |
|
Quote: |
Quote: |
I suppose some of us need to start having the brass to just shut out all IE uses from our sites and do things the right way. |
That's pretty much what I do now. I added a text-align: center; to the
body for IE centering, and left it at that. I just get new layouts
readable (for those with no choice), and move on.
|
What? No, your site doesn't even have a doctype. It won't validate on
any validator and is not guaranteed to display on ANY browser period.
It only works because they are all generous and fall back to something
that happens to display. Your page is broken man in a serious way. No
character encoding, no Mime type for parse mode, nothing...
Oh dear.. Fitzroy's design also has no doctype. What kind of web
designers are you guys? I think you contribute to a broken Internet. 
_________________
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 08, 2008 2:22 pm Post subject: |
|
Quote: |
What?
No, your site doesn't even have a doctype. It won't validate on any
validator and is not guaranteed to display on ANY browser period. It
only works because they are all generous and fall back to something
that happens to display. Your page is broken man in a serious way. No
character encoding, no Mime type for parse mode, nothing... |
Good.
Rather than spend my time adding all of those things to a webpage, so
that non-existent web browsers that require it will render my page;
I'll instead focus on more important things.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Tue Apr 08, 2008 2:46 pm Post subject: |
|
Sure,
it does not stop the browser from rendering the content, but all major
browsers does change their rendering mode to try to follow the
standards when they see it, while the alternative is to do it in other
ways. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Apr 08, 2008 4:59 pm Post subject: |
|
Nightcrawler wrote: |
Oh dear.. Fitzroy's design also has no doctype. What kind of web
designers are you guys? I think you contribute to a broken Internet.  |
If not having it in didn't work, it would be in there. You have to give
people the incentive and be willing to enforce it (you know, like tags,
either you follow them or it doesn't work).
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Tue Apr 08, 2008 5:51 pm Post subject: |
|
All
adding a doctype and whatnot does is ensure (assuming you get
everything else right) that your document validates. I'd say about 50%
of the web's pages are "invalid". Should browsers only accept "valid"
code, and shut out all sites that don't have it? (i.e. destroy the
internet).
That said, if you
haven't got anything better to do, or want a comfort blanket from the
w3c, then fine, clean up your code and make sure it validates.
Hell, you can write
Code: |
<title>Name of page</title>
<p>Hi, welcome to bsnes site
<a href="thingy.zip">Click here to download bsnes</a>
|
And all browsers will accept it.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Apr 09, 2008 8:36 am Post subject: |
|
Sure,
it is invalid, but that is not the main concern, the main concern is
that the browsers intentionally does not rend exactly according to the
standard. |
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 09, 2008 9:19 am Post subject: |
|
Franky wrote: |
All adding a doctype and whatnot does is ensure (assuming you get
everything else right) that your document validates. I'd say about 50%
of the web's pages are "invalid". Should browsers only accept "valid"
code, and shut out all sites that don't have it? (i.e. destroy the
internet).
That said, if you haven't got anything better to do, or want a comfort
blanket from the w3c, then fine, clean up your code and make sure it
validates.
Hell, you can write
Code: |
<title>Name of page</title>
<p>Hi, welcome to bsnes site
<a href="thingy.zip">Click here to download bsnes</a>
|
And all browsers will accept it.
|
They'll even render it consistently.
It's when things get more complex that you start running into issues.
If a site doesn't comply to a standard, the browser takes it's best
guess.
In a simple case, it's easy enough to figure out what was supposed to
happen. In a more complex application, it can be very difficult to
figure out the intent, and different browsers(or even different
versions of the same browser) will guess differently. Possibly one of
them will guess what you want. Possibly none of them will.
Certainly, a doctype or character encoding spec isn't going to be an
issue 9.9% of the time(I'd wager it's closer to 100 for doctype, though
character encoding helps a lot on some fringe cases). But doing it
right (almost) guarantees it renders properly, and makes it a lot
easier to debug when you change things.
Personally, I don't think it's worth preaching about. But it makes good sense to try and adhere to a standard.
But then, my background is more programming-oriented. Programming is a
lot stricter than web design. You tell the computer exactly what you
want done, or it just sits there and bitches at you. I'm always amazed
at how lenient web browsers are, and have a little trouble believing
that some of the things out there actually WORK.
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Apr 09, 2008 11:06 am Post subject: |
|
FitzRoy wrote: |
Nightcrawler wrote: |
Oh dear.. Fitzroy's design also has no doctype. What kind of web
designers are you guys? I think you contribute to a broken Internet. :P |
If not having it in didn't work, it would be in there. You have to give
people the incentive and be willing to enforce it (you know, like tags,
either you follow them or it doesn't work).
|
For me, the incentive for using standards mode is that the browser
won't wig out and do crazy stuff if I happen to accidentally produce
some HTML that happened to be interpreted in a 'special' way by
Netscape 4. Also, it's a *lot* easier to get things working
cross-browser when each browser is aiming for the same
(carefully-designed, well-thought-out) standard, rather than aiming for
some sort of weird accidental hybrid of IE4 and Netscape 4.
The most famous example is how standards mode makes IE and Firefox
treat the combination of 'width' and 'padding' the same way. (outside
of standards mode, IE says that width includes padding, and the
standard says that width excludes padding).
|
|
Thristian Hazed
Joined: 07 Feb 2006
Posts: 79
|
Posted: Wed Apr 09, 2008 11:14 am Post subject: |
|
Franky wrote: |
That said, if you haven't got anything better to do, or want a comfort
blanket from the w3c, then fine, clean up your code and make sure it
validates.
Hell, you can write
Code: |
<title>Name of page</title>
<p>Hi, welcome to bsnes site
<a href="thingy.zip">Click here to download bsnes</a> |
And all browsers will accept it.
|
And here's an HTML page that passes the W3C's validator with no warnings, errors or complaints:
Code: |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Name of page</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Hi, welcome to bsnes site
<a href="thingy.zip">Click here to download bsnes</a> |
If you delete the meta tag, you'll only get a warning and not an error.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Wed Apr 09, 2008 1:20 pm Post subject: |
|
byuu wrote: |
Quote: |
What?
No, your site doesn't even have a doctype. It won't validate on any
validator and is not guaranteed to display on ANY browser period. It
only works because they are all generous and fall back to something
that happens to display. Your page is broken man in a serious way. No
character encoding, no Mime type for parse mode, nothing... |
Good.
Rather than spend my time adding all of those things to a webpage, so
that non-existent web browsers that require it will render my page;
I'll instead focus on more important things.
|
You spent more time writing that response than it would take you to add a DTD to your web page.
I don't get why you think it's necessary to follow C++ standards when
you program, emulate the SNES the right way even if it's not required
to get all the games to run, yet somehow don't think developing to web
standards is worth doing.
It's just so distressing... 
_________________
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.
|
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Apr 09, 2008 1:51 pm Post subject: |
|
Thristian wrote: |
And here's an HTML page that passes the W3C's validator with no warnings, errors or complaints: |
That is completely legal to do in html, since both the start and the
end tag is optional for the html, head and body elements.
But they are still there.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 09, 2008 4:55 pm Post subject: |
|
By
the way, just for the record, I myself do adhere to the standard. I'm
merely stating that you don't have to go anywhere near it and your page
will probably display correctly.
I mostly use XHTML 1.0 Strict (in my own personal designs, pure CSS and no tables).
Now, what I really want to learn and become fluent with is PHP and Javascript.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 13, 2008 6:01 am Post subject: |
|
Some
of Verdauga's old image hosting choices which have expired are now
linking to pr0n, so anyone browsing old pages might get a NSFW
surprise. While I do have mod power to sift through the whole thread
and edit them out, I think it would be easier if someone just blocked
the site (http://hidebehind.com). |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Apr 13, 2008 11:45 am Post subject: |
|
FitzRoy wrote: |
Some
of Verdauga's old image hosting choices which have expired are now
linking to pr0n, so anyone browsing old pages might get a NSFW
surprise. While I do have mod power to sift through the whole thread
and edit them out, I think it would be easier if someone just blocked
the site (http://hidebehind.com). |
Erp, sorry about that; the website promises the links will never
expire, I'm sure. Perhaps I can do an in-topic search for all my posts
and edit the ones that need it? (though that'll have to wait 'till next
Friday, when I get home)
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Sun Apr 13, 2008 12:37 pm Post subject: |
|
Verdauga Greeneyes wrote: |
FitzRoy wrote: |
Some
of Verdauga's old image hosting choices which have expired are now
linking to pr0n, so anyone browsing old pages might get a NSFW
surprise. While I do have mod power to sift through the whole thread
and edit them out, I think it would be easier if someone just blocked
the site (http://hidebehind.com). |
Erp, sorry about that; the website promises the links will never
expire, I'm sure. Perhaps I can do an in-topic search for all my posts
and edit the ones that need it? (though that'll have to wait 'till next
Friday, when I get home)
|
They've changed into a full pr0n only site now.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sun Apr 13, 2008 10:11 pm Post subject: |
|
I never comprehended the no-table zealotry... if it woirks reasonably wel across all browsers, use it.
Divs don't work on IE, so thus...
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Sun Apr 13, 2008 10:34 pm Post subject: |
|
Metatron wrote: |
...Divs don't work on IE, so thus... |
WTF have you been smoking, dude?
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Mon Apr 14, 2008 12:18 am Post subject: |
|
...You
know damn well what I mean by that, remove the stick from your ass. IE
does not handle the various things you can do with divs+CSS
particularly well, mostly to do with width and positioning. A simple
google would provide you with plenty of complaints.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick |
|
85cocoa Rookie
Joined: 22 Jul 2006
Posts: 17
Location: USA
|
Posted: Mon Apr 14, 2008 12:52 am Post subject: |
|
I couldn't find this in the last few pages of the thread, so I thought I might as well ask here:
I
couldn't find any reference to a game titled "Macaron Golf" or
alternate spellings thereof in GoodSNES or GameFAQs. Is this an April
Fool's joke that needs to be cleaned up?
EDIT:
Sorry for not "doing my homework" a little better and/or thinking
harder about what an alternate spelling could be.
_________________
Dell Inspiron 9300: 1.86GHz Pentium M, 1GB DDR2 SDRAM, 80GB 7200RPM HDD, 256MB Nvidia GeForce Go 6800 (Specs are here only to facilitate bug reports)
Q: Can ZSNES run on a monkey? A: No, not enough RAM. I was -_pentium5.1_- until I screwed up
Last edited by 85cocoa on Mon Apr 14, 2008 4:39 am; edited 1 time in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Apr 14, 2008 1:48 am Post subject: |
|
85cocoa wrote: |
I
couldn't find any reference to a game titled "Macaron Golf" or
alternate spellings thereof in GoodSNES or GameFAQs. Is this an April
Fool's joke that needs to be cleaned up? |
Unless I'm very much mistaken, that's referring to this. According to FitzRoy's post here, it's 'Mecarobot Golf (SNS-TS-USA) / Serizawa Nobuo no Birdie Try (SHVC-TS-JPN)'
Edit: speaking of which, the status of soft-patching in that should be revised
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 14, 2008 2:13 am Post subject: |
|
Quote: |
Is this an April Fool's joke that needs to be cleaned up? |
I wish :(
Anyway, I was thinking about posting a UPS patch that will "fix" the
game temporarily. For those who are desperate to play some golf right now.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 14, 2008 2:49 am Post subject: |
|
Macaroni Golf?  |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Mon Apr 14, 2008 6:44 am Post subject: |
|
Metatron wrote: |
...You
know damn well what I mean by that, remove the stick from your ass. IE
does not handle the various things you can do with divs+CSS
particularly well, mostly to do with width and positioning. A simple
google would provide you with plenty of complaints. |
ie uses(used?) a different box model than the CSS standard. Mozilla has a seperate model if you wanted to use it.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Mon Apr 14, 2008 8:15 am Post subject: |
|
byuu wrote: |
Quote: |
Is this an April Fool's joke that needs to be cleaned up? |
I wish 
Anyway, I was thinking about posting a UPS patch that will "fix" the
game temporarily. For those who are desperate to play some golf right now.
|
thats actually a REALLY good idea, instead of adding pseudo hacks to
bsnes to fix games that have issues, you could simply post ups patches
for those games that have issues, that is untill you find a fix
ofcourse.
This approach could also be used to fix games that are buggy
themselves, which would automatically result in a list of games that
have bugs not related to emulation.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Apr 14, 2008 9:32 am Post subject: |
|
I can think of better ways to spend fifteen minutes than writing a patch for macaroni golf. |
|
Turambar Rookie
Joined: 04 Jun 2007
Posts: 21
|
Posted: Mon Apr 14, 2008 11:18 am Post subject: |
|
Turambar wrote: |
I wonder if this happens on hardware. I don't remember this happening ever on the console, and I can't test it right now.

Every time the enemy shoots the second spike thing, a black horizontal
line appers which covers Mega Man partially. This glitch is always
reproduciable. I also tested this with another enemy of the same type,
and it worked too. It's easiest to see in Crush Crawfish's stage (the
picture).
EDIT: The image was a bit bigger than I expected. Sorry. |
I confirmed yesterday that this bug occurs on hardware. I used the
European cart, but that doesn't probably matter.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Apr 14, 2008 5:13 pm Post subject: |
|
byuu wrote: |
Anyway,
I was thinking about posting a UPS patch that will "fix" the game
temporarily. For those who are desperate to play some golf right now. |
Hell yeah. Anyone up for some golf? 
_________________
Kega Fusion Supporter | bsnes Supporter | Regen Supporter
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Apr 14, 2008 5:23 pm Post subject: |
|
tetsuo55 wrote: |
thats
actually a REALLY good idea, instead of adding pseudo hacks to bsnes to
fix games that have issues, you could simply post ups patches for those
games that have issues, that is untill you find a fix ofcourse. |
NESTICLE ALERT
Cluenailbat time.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Apr 14, 2008 5:31 pm Post subject: |
|
grinvader wrote: |
tetsuo55 wrote: |
thats
actually a REALLY good idea, instead of adding pseudo hacks to bsnes to
fix games that have issues, you could simply post ups patches for those
games that have issues, that is untill you find a fix ofcourse. |
NESTICLE ALERT
Cluenailbat time.
|

tetsuo, you obviously did not understand byuu's sarcasm.
What you fail to understand is similar to what also happened in Mega
Man X v1.0 with OpenBus support. Before support existed, the ROM was
hacked to work with emus. Having a patch for it does the exact same thing as adding a hack for the game (in the emu). It simply has a different form in this instance.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Apr 14, 2008 6:53 pm Post subject: |
|
Not to split hairs, but I really wouldn't call it sarcasm, per se, as I wasn't responding to anyone. You're correct that it was mostly a joke, though. Even as a UPS patch, certain dipshits would index the patched game in their archives, which would be a very bad thing indeed.
But since it was brought up ...
Quote: |
Having
a patch for it does the exact same thing as adding a hack for the game
(in the emu). It simply has a different form in this instance. |
I wouldn't go so far as to say it's exactly the same. A patch has to be
manually activated by a user, and can easily be disabled. Whereas a
patch inside an emulator is usually hard-coded. Of course, ZSNES has
the -dh switch that disables some of the hacks, which is nice.
I absolutely agree with you that distributing even a patch would be a
bad idea, though. But no reason to be mean about it ...
tetsuo, if you'd like to play Mecarobot now, the best way would be via
the cheat code mechanism, and not via soft patching.
For example, try the following "cheat code" with bsnes v0.031:
Code: |
009c6f:50 = enabled, "bsnes temporary IRQ timing workaround" |
Evil, but it works. It's a lot less nasty than the Uniracers hack I have now, at least.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Mon Apr 14, 2008 6:58 pm Post subject: |
|
Quote: |
It simply has a different form in this instance. |
But since it's not in the emu, it won't break other games. It's a
game-specific hack basically, but it doesn't break other parts of
emulation since it's on the rom itself, only.
...The only problem is that it might make the rom stop working on other emu's.
Please, correct me if I'm wrong.
I suppose that every now and then, hacks are the only way to get things
working (if it's simply impossible to examine what would actually
happen in hardware).
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Apr 14, 2008 7:10 pm Post subject: |
|
byuu wrote: |
Not to split hairs, but I really wouldn't call it sarcasm, per se, as I wasn't responding to anyone. You're correct that it was mostly a joke, though. Even as a UPS patch, certain dipshits would index the patched game in their archives, which would be a very bad thing indeed.
But since it was brought up ...
Quote: |
Having
a patch for it does the exact same thing as adding a hack for the game
(in the emu). It simply has a different form in this instance. |
I wouldn't go so far as to say it's exactly the same. A patch has to be
manually activated by a user, and can easily be disabled. Whereas a
patch inside an emulator is usually hard-coded. Of course, ZSNES has
the -dh switch that disables some of the hacks, which is nice.
|
It's semantics and implementation of the same idea. You end up changing
original intended behavior of the game. This idea fundamentally does
not change.
Quote: |
I absolutely agree with you that distributing even a patch would be a bad idea, though. But no reason to be mean about it ... |
The intent was not to be nasty, rather to point out what the
distinction is. I don't care too much how this hack of a change gets
implemented.. just know that having a patch that modifies the ROM is
the next thing that will get cataloged by "your favorite tools". I need
not say more.
For those who don't understand this, you either add it (this specific
change) as an emu hack or you change the ROM's contents, which in the
end is changing what the data is in memory. How it is done is the
difference.
Franky wrote: |
Quote: |
It simply has a different form in this instance. |
But since it's not in the emu, it won't break other games. It's a
game-specific hack basically, but it doesn't break other parts of
emulation since it's on the rom itself, only.
...The only problem is that it might make the rom stop working on other emu's.
|
No kidding, the fact that it is a hack already been established. It's a still a hack for an emu.
Clearly, you don't understand the NESTICLE reference. Please do some research/searching on this board.
_________________
FF4 research never ends for me.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Mon Apr 14, 2008 11:22 pm Post subject: |
|
Deathlike2 wrote: |
What you fail to understand is similar to what also happened in Mega
Man X v1.0 with OpenBus support. Before support existed, the ROM was
hacked to work with emus. Having a patch for it does the exact same thing as adding a hack for the game (in the emu). It simply has a different form in this instance. |
Could you elaborate on that? I've never heard about that before.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Mon Apr 14, 2008 11:29 pm Post subject: |
|
I.S.T. wrote: |
Deathlike2 wrote: |
What you fail to understand is similar to what also happened in Mega
Man X v1.0 with OpenBus support. Before support existed, the ROM was
hacked to work with emus. Having a patch for it does the exact same thing as adding a hack for the game (in the emu). It simply has a different form in this instance. |
Could you elaborate on that? I've never heard about that before.
|
What part are you talking about exactly?
When this game was distributed, some of them were modified to work with
emus because people were confused on "why the hell does the game
restarts at the beginning"? (Search for those posts on this board,
you'll certainly find it). I get the feeling this modified ROM was also
catalogued in "some evil set"...
Unless you're talking about the hack part, just look up Nesticle.
_________________
FF4 research never ends for me.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Apr 15, 2008 4:41 am Post subject: |
|
Franky wrote: |
Quote: |
It simply has a different form in this instance. |
But since it's not in the emu, it won't break other games. It's a
game-specific hack basically, but it doesn't break other parts of
emulation since it's on the rom itself, only.
...
Please, correct me if I'm wrong.
|
Correction incoming:
A hack in the emu is a special-case alteration of the emulation behavior, not an alteration of the base emulator.
It only activates when a specific ROM image is loaded, and has no effect on other games.
To use the Megaman X example... there was, way back in the day, a
game-killing bug in the european and japanese versions of Megaman X
when played in ZSNES.
It wasn't anything unique to the E/J versions of the game, it was just
that the hack that made Megaman X work ONLY activated when a US Megaman
X ROM image was loaded.
Tangent:
There HAVE been cases where fixing emulation broke games that worked
because the new and improved emulation made a forgotten hack start
breaking the game instead of fixing it.
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Tue Apr 15, 2008 10:35 am Post subject: |
|
Well explained.
I agree that the patch thing would be a bad idea in retrospect.
This however does not change the fact that i am all for patches for
games that are broken to begin with (e.g bugs that also occur on
hardware)
If the patch is written correctly it should work on both hardware and
bsnes. That the patch will eventually be added to things like goodsnes
is really something we should ignore..... |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Tue Apr 15, 2008 11:40 am Post subject: |
|
tetsuo55 wrote: |
This
however does not change the fact that i am all for patches for games
that are broken to begin with (e.g bugs that also occur on hardware) |
That's different. If a bug occurs because of poor game programming,
then I have no issue having a patch (in fact, that is what some patches
are for those games to begin with). I'm just talking about patching the
game when the emu is having the problem, which is completely different.
_________________
FF4 research never ends for me.
|
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Tue Apr 15, 2008 3:06 pm Post subject: |
|
Deathlike2 wrote: |
tetsuo55 wrote: |
This
however does not change the fact that i am all for patches for games
that are broken to begin with (e.g bugs that also occur on hardware) |
That's different. If a bug occurs because of poor game programming,
then I have no issue having a patch (in fact, that is what some patches
are for those games to begin with). [b]I'm just talking about patching
the game when the emu is having the problem, which is completely
different.[b/]
|
While not being serious about actually doing it anyway, right?
Cheaters never prosper. They only win "now". They never win forever. The win runs out, fast.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 15, 2008 3:30 pm Post subject: |
|
My biggest beef with game-specific hacks are that they bypass the real problem.
Instead of focusing on solving the problem, we instead say "oh, well,
this works so let's be happy with it." and move on. Take a look at
SPC7110 decompression support for example. Nobody even cares anymore
because of the graphics pack support in ZSNES and Snes9x. I'd bet money
that had they refused to provide that solution to the public, there
would be a much stronger drive by all to figure out the algorithm.
Worse yet, some people are now wanting to translate the game now,
meaning they'll have to patch graphics packs. So if and when the
algorithm does get cracked, none of the English graphical changes will
work on emulators; and they'll never work on real hardware (for the
three people in the world that can make their own SPC7110 carts.)
Same for the Uniracers workaround. Absolutely no emulator should be able to play that game properly.
Once one emulator supports it through hacks, it greatly lowers interest in emulating it correctly.
There's also the emulator problem that you end up in the untenable
position of constantly breaking old hacks and never getting things
right for 100% of games, but that's more up to individual emu authors. |
|
wrdaniel New Member
Joined: 15 Apr 2008
Posts: 5
|
Posted: Tue Apr 15, 2008 4:11 pm Post subject: |
|
Sorry for not reading all 226 pages of this thread. so i got a question and maybe someone has a quick answer.
Is it possible that the fullscreen option switches the resolution, so
enabling it switches the screen to for example 256x224 resolution mode?
if not, will it sometimes be impelmented, or is that not an aim of
bsnes. commandline switch would be perfect.
and what most guys asking for low resolutions also ask for is an configurable exit key 
bsnes is an awesome emulator, keep up the good work,
tnx, wrdaniel |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Apr 15, 2008 4:51 pm Post subject: |
|
bsnes
doesn't have a "true" fullscreen and I don't think there are any plans
for one because it will kill the menu bar or something. Is there a
reason this is wanted? I can't think of anything it would do better. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 15, 2008 5:06 pm Post subject: |
|
It would help with refresh rate config, but that's about it.
That's easy enough though, a simple batch script that will set the
refresh rate, run bsnes, and set it back on exit. And now you can use
it in windowed mode, too.
A configurable exit key is easy enough. |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Tue Apr 15, 2008 5:24 pm Post subject: |
|
Why can't you just have more multipliers?
5x gets the video filling my screen perfectly (1280x1024). I imagine a
4x multiplier would fill a 1024x768 res nicely, 3x for 800x600.
Etc.
Just have insane multipliers like 3.5x, 3.25, etc.
Don't worry about widescreen -- it makes the image look stretched
anyway. It's much better to have it fill the vertical resolution and
just have pillarboxing on widescreen monitors.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
wrdaniel New Member
Joined: 15 Apr 2008
Posts: 5
|
Posted: Tue Apr 15, 2008 5:25 pm Post subject: |
|
Quote: |
Is there a reason this is wanted? |
fullscreenmode with native resolution is the best way to get it on a
rgb television/screen. and once the emulator is configured you dont
need the menu or statusbar anymore.
Quote: |
... a simple batch ... |
thats a good idea, i will try to find a small tool that switches the
windows resoultion. do you have such a tool in mind?
tnx, wrdaniel
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Tue Apr 15, 2008 9:19 pm Post subject: |
|
FitzRoy wrote: |
bsnes
doesn't have a "true" fullscreen and I don't think there are any plans
for one because it will kill the menu bar or something. Is there a
reason this is wanted? I can't think of anything it would do better. |
Well, if you have a CRT monitor, there's a significant advantage in terms of image quality if you can display 1:1 pixels.
As wrdaniel hints at, this is highly plausible with certain system
configurations, some of which are commonly used in MAME cabs.
|
|
ShadowFX Regular

Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
|
Posted: Tue Apr 15, 2008 10:01 pm Post subject: |
|
I
believe Gambatte is a perfect example of how it can be done. Is the
current code of bsnes unable to make use of this method? Is the
preferable support for multiple OSs the reason?
_________________
"Change is inevitable; progress is optional" |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Apr 15, 2008 11:05 pm Post subject: |
|
Gil_Hamilton wrote: |
FitzRoy wrote: |
bsnes
doesn't have a "true" fullscreen and I don't think there are any plans
for one because it will kill the menu bar or something. Is there a
reason this is wanted? I can't think of anything it would do better. |
Well, if you have a CRT monitor, there's a significant advantage in terms of image quality if you can display 1:1 pixels.
As wrdaniel hints at, this is highly plausible with certain system
configurations, some of which are commonly used in MAME cabs.
|
When bsnes had true fullscreen back in the day, I never noticed a
quality difference on my CRT. How does 1:1 stretched to fit look better
than 2:1 stretch to fit?
Though I do notice losing crispness in really high resolutions. I
suppose if he has a low-res monitor where bsnes wouldn't even have a
desktop environment to display the gui on...
|
|
wrdaniel New Member
Joined: 15 Apr 2008
Posts: 5
|
Posted: Tue Apr 15, 2008 11:54 pm Post subject: |
|
1:1
native resolution on an RGB CRT is simply identical to what you see if
you connect a real snes to the screen. it is not 1:1 stretched to fit,
it is 1:1 fit cause the original resolution is 4:3 fullscreen.
And for playing games you dont need a GUI in the emulator, choosing the
games is done with a frontend like this for example.
 |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Wed Apr 16, 2008 6:43 am Post subject: |
|
Please say that you didn't photoshop that picture just for that post... |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 16, 2008 7:22 am Post subject: |
|
FitzRoy wrote: |
Gil_Hamilton wrote: |
FitzRoy wrote: |
bsnes
doesn't have a "true" fullscreen and I don't think there are any plans
for one because it will kill the menu bar or something. Is there a
reason this is wanted? I can't think of anything it would do better. |
Well, if you have a CRT monitor, there's a significant advantage in terms of image quality if you can display 1:1 pixels.
As wrdaniel hints at, this is highly plausible with certain system
configurations, some of which are commonly used in MAME cabs.
|
When bsnes had true fullscreen back in the day, I never noticed a
quality difference on my CRT. How does 1:1 stretched to fit look better
than 2:1 stretch to fit?
|
Errr.... there's no such thing as 1:1 stretched to fit. It's an oxymoron.
1:1 means exactly that. One emulated pixel equals one real pixel.
If you have hardware that can DO 512*448 and a screen that can display it, it's a pretty nice option.
I used to advocate running ZSNES in 640*480 R, then adjusting the dials
on the monitor to correct the aspect ratio(since you had to redial
every time you switched resolutions ANYWAYS...). Exact same effect,
only it worked with standard hardware.
I still advocate it, if you happen to have a monitor with dials. Menus made it too much of a pain.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 16, 2008 4:10 pm Post subject: |
|
This
is where I'm confused. If he's running his monitor at 640x480, he has
to stretch the snes native resolution to fill the screen. AR correction
by itself is stretching. Since CRTs don't have pixel grids like LCDs,
what difference does one low resolution vs another make to quality
unless the display sucks ass? |
|
Franky Lurker

Joined: 15 Mar 2008
Posts: 117
Location: Pallet town
|
Posted: Wed Apr 16, 2008 4:36 pm Post subject: |
|
You know, I'm confused.
The snes is meant to be played on a TV. And as far as I'm aware, most of the TV's a snes gets played on are 4:3.
640x480 is a 4:3 resolution.
so, when playing on real hardware, the image would be stretched. I just really don't understand that all the fuss is about.
_________________
Knowledge is power.
Ignorance is submission.
But knowledge is only theory, not truth.
Be careful of what knowledge you choose,
and you will be wise. |
|
wrdaniel New Member
Joined: 15 Apr 2008
Posts: 5
|
Posted: Wed Apr 16, 2008 5:11 pm Post subject: |
|
the native resolution is 256x224 and the screen runs on that resolution too. its fullscreen and 4:3 on the screen. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Wed Apr 16, 2008 5:23 pm Post subject: |
|
wrdaniel wrote: |
the screen runs on that resolution too |
... nope. CRT TVs analog stretch everything to their resolution (either pal or ntsc).
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
wrdaniel New Member
Joined: 15 Apr 2008
Posts: 5
|
Posted: Wed Apr 16, 2008 5:46 pm Post subject: |
|
wrong
words chosen, as english is not my native language. what i mean is, the
graphic cards sends exactly the pixels of the native resolution. with
the analog stretch you dont have the same effect as with a digital
stretch like if you choose a 2:1 3:1 resolution on the computer screen.
there you get two, three, or more pixels and you see it. on the tv
screen its not 1 dot, but its still 1 element, but it does not need to
be square. the vertical resolution you get the original 224 lines, with
scanlines in between, and it is an noninterlaced mode so you dont get
flickering as with normal tv out on graphic cards. dont know if that
makes it clear.
and i also dont know if this is
the right thread to discuss this. so maybe a mod could cut it of and
put it where it belongs?
tnx, wrdaniel |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 16, 2008 10:16 pm Post subject: |
|
FitzRoy wrote: |
This
is where I'm confused. If he's running his monitor at 640x480, he has
to stretch the snes native resolution to fill the screen. AR correction
by itself is stretching. Since CRTs don't have pixel grids like LCDs,
what difference does one low resolution vs another make to quality
unless the display sucks ass? |
Because scaling within the computer at low resolutions looks like ass,
and I'm betting he's got a MAME cab-ish setup that can actually output
a 256*224 or 512*448 display natively. No scaling > any scaling.
Franky wrote: |
You know, I'm confused.
The snes is meant to be played on a TV. And as far as I'm aware, most
of the TV's a snes gets played on are 4:3.
640x480 is a 4:3 resolution.
so, when playing on real hardware, the image would be stretched. I just really don't understand that all the fuss is about. |
It wouldn't be stretched. It's better to consider it as the SNES using non-square pixels.
No matter how you look at it, it's not stretched in the same manner,
and generates a different appearance than a native res output. A VERY
different one at low resolutions.
My rules of emulation:
1. If you can, output the native resolution of the image and have any
aspect manipulation done in the analog domain.
2. If you can't do that, upscale it by integer multipliers only.
3. If you can't do that, upscale to the highest resolution you can to make the subpixels less visible.
3a. If you're using a digital display, upscale to the display's native resolution.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Apr 16, 2008 11:33 pm Post subject: |
|
Gil_Hamilton wrote: |
FitzRoy wrote: |
This
is where I'm confused. If he's running his monitor at 640x480, he has
to stretch the snes native resolution to fill the screen. AR correction
by itself is stretching. Since CRTs don't have pixel grids like LCDs,
what difference does one low resolution vs another make to quality
unless the display sucks ass? |
Because scaling within the computer at low resolutions looks like ass,
and I'm betting he's got a MAME cab-ish setup that can actually output
a 256*224 or 512*448 display natively. No scaling > any scaling.
|
Have you used a recent version of bsnes? The scaling is totally crisp
and indistinguishable between resolutions, as opposed to ZSNES' stretch
modes. And if he's using those resolutions natively, then that means
his display is 5:4 as well? I didn't think there were CRTs that existed
in that aspect. And even if there were, arcade games are wildly
different from one another in resolutions and some were designed with
flipped ratio displays (shooters). How does he overcome that?
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 16, 2008 11:45 pm Post subject: |
|
FitzRoy wrote: |
Have
you used a recent version of bsnes? The scaling is totally crisp and
indistinguishable between resolutions, as opposed to ZSNES' stretch
modes. |
I'm aware that aspect correction's come a long way.
Quote: |
And if he's using those resolutions natively, then that means his display is 5:4 as well? |
No.
Hook your SNES up to a TV some time. 256*224 on a 4:3 display.
Hell, set your PC to 1280*1024.
...
Has it really been so long since people owned CRTs?
Quote: |
And
even if there were, arcade games are wildly different from one another
in resolutions and some were designed with flipped ratio displays
(shooters). How does he overcome that? |
There actually ARE people that have built cabs with rotatable screens.
Anyways, you can actually get a LOT of resolution variance out of a
single card* and display. A good progressive-scan TV will merrily do
anything between 256*224(actually a bit lower) and 720*480(DVD
resolution, and pretty much the farthest NTSC sets got pushed).
Again, has it been so long since people owned CRTs?
*Especially with something explicitly designed for it, like this: http://www.ultimarc.com/avgainf.html
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Apr 17, 2008 12:27 am Post subject: |
|
Gil_Hamilton wrote: |
FitzRoy wrote: |
And if he's using those resolutions natively, then that means his display is 5:4 as well? |
No.
Hook your SNES up to a TV some time. 256*224 on a 4:3 display.
Hell, set your PC to 1280*1024.
...
Has it really been so long since people owned CRTs?
|
Now that I think about it, CRTs don't really have a native resolution, so that's what's confusing me.
Quote: |
No scaling > any scaling |
Even if the scaling is integer based and the source resolution matches
the outcome? So if I'm running a resolution of 512x448 and my scaling
is exactly double as well, that's going to look worse than running at
256x224 with an unscaled 256x224 input?
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Thu Apr 17, 2008 12:39 am Post subject: |
|
FitzRoy wrote: |
Quote: |
No scaling > any scaling |
Even if the scaling is integer based and the source resolution matches
the outcome? So if I'm running a resolution of 512x448 and my scaling
is exactly double as well, that's going to look worse than running at
256x224 with an unscaled 256x224 input?
|
Well... integer scaling's just costing you processor time, which is basically free. Not really worth worrying about.
Revised rules of emulation!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Apr 17, 2008 12:41 am Post subject: |
|
The
confusion is due to a misunderstanding of how CRT televisions render.
It's been mostly clarified at this point, but to reiterate ...
A CRT doesn't have fixed size width pixels like an LCD, so you can
stretch out existing pixel widths via monitor knobs / menu. Whereas an
emulator has to interpolate between pixels to stretch them out like
this, which will always look worse. Less so as the resolution increases.
Now, 256x224 is a well known video mode for old VGA graphics cards,
they used to call this mode and other lores modes "Mode X". I don't
know of similar resolutions for 512x448 and up, but they're possible in
theory. If you were to set such a mode and stretch it, it wouldn't look
much worse. There'd only possibly be infinitesimal aliasing if some
stretched pixels ended up being different sizes than others. But 8:7
video modes > 256x224 are indeed very rare.
All that said, CRTs are quickly going out of style. A mode change
feature would be nice, but I don't really want to spend all the extra
work on something with so many inherent problems, portability being the
least of which. |
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Thu Apr 17, 2008 4:13 pm Post subject: |
|
CRT televisions have a 4:3 aspect ratio.
For reference, here's a list of common resolutions...
http://en.wikipedia.org/wiki/List_of_common_resolutions
So to get a proper un-distorted image on a computer, you need to run at
a resolution with the same ratio. This was easy with analog CRT
monitors, but digital LCD monitors look best when run at their native
resolution. The problem is that many non-widescreen LCD monitors have a
5:4 native resolution like 1280x1024.
I knew this before I bought my LCD so I specifically looked for one
with a 4:3 ratio and found a 20.1 inch monitor with a 1400x1050 native
resolution...
Westinghouse LCM-20v5
http://www.westinghousedigital.com/details.aspx?itemnum=47 |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Apr 18, 2008 12:05 am Post subject: |
|
krick wrote: |
CRT televisions have a 4:3 aspect ratio.
So to get a proper un-distorted image on a computer, you need to run at a resolution with the same ratio. |
Sorta-kinda.
Most game consoles had non-square pixels. Most commonly-supported resolutions on modern PCs have square pixels.
Fixing the pixel aspect causes a different kind of distortion, which
can be more or less offensive, or even totally unobtrusive, depending
on how it's handled.
Quote: |
This
was easy with analog CRT monitors, but digital LCD monitors look best
when run at their native resolution. The problem is that many
non-widescreen LCD monitors have a 5:4 native resolution like 1280x1024. |
Many applications include aspect correction, and will letterbox or pillarbox as needed.
Decent video cards also include options in the driver to "fix" the LCD
problem by moving scaling to the video card(which does a MUCH better
job) or passing the non-native image in a frame instead of stretching
it.
So all your efforts were for naught, because you could've told the
video card to scale while keeping aspect, and then set your application
to a 4:3 resolution with the same vertical res as your LCD.
Also: Westinghouse LCDs suck by most counts.
|
|
krick Rookie
Joined: 17 Aug 2006
Posts: 12
|
Posted: Fri Apr 18, 2008 1:38 am Post subject: |
|
Gil_Hamilton wrote: |
So all your efforts were for naught, because you could've told the
video card to scale while keeping aspect, and then set your application
to a 4:3 resolution with the same vertical res as your LCD.
Also: Westinghouse LCDs suck by most counts. |
Video card scaling causes blurring.
And my Westinghouse LCD has the nicest image I've ever seen with the
exception of my old NEC multisync 17" LCD which was analog only, but
looks better than any CRT I've seen.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Apr 18, 2008 2:24 am Post subject: |
|
krick wrote: |
Gil_Hamilton wrote: |
So all your efforts were for naught, because you could've told the
video card to scale while keeping aspect, and then set your application
to a 4:3 resolution with the same vertical res as your LCD.
Also: Westinghouse LCDs suck by most counts. |
Video card scaling causes blurring.
|
But a far less offensive form of it than letting the LCD do it.
And what do you think happens when you set an emulator to output 1400*1050 instead of 512*448?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 18, 2008 3:24 am Post subject: |
|
Okay,
so relating this to bsnes... presuming that televisions are a physical
4:3 and that the source resolution was designed to be stretched to
match this aspect, let's see how bsnes' subjectively defined
corrections match up rounded to hundredths:
=====================
NTSC Desired Result AR: 4:3
4 / 3 = 1.33
NTSC SNES 256x224 Native AR: 8:7
8 / 7 = 1.14
Objective X/Y Correction: 1.33 / 1.14 = 1.17 (117/100)
Subjective X/Y Correction: 1.15 (54/47)
======================
PAL Desired Result AR: 4:3
4 / 3 = 1.33
PAL SNES 256x240 Native AR: 16:15
16 / 15 = 1.07
Objective X/Y Correction: 1.33 / 1.07 = 1.25 (5/4)
Subjective X/Y Correction: 1.39 (32/23)
======================
Did I do that right? |
|
augnober New Member
Joined: 18 Apr 2008
Posts: 6
|
Posted: Fri Apr 18, 2008 4:58 am Post subject: |
|
I
don't know what bsnes does currently (I'm not on my own computer right
now, so I won't try it), but here's my take on it. (in brief: my
suggestion is to use the largest possible integer for the vertical
scale, and to employ the corresponding horizontal resolution in NTSC
simulation so that you get the correct aspect without doing any actual
non-integer scaling)-
If you enable NTSC
simulation, then I suggest that the closest whole-number scale (without
exceeding vertical bounds) should be applied vertically, and that the
necessary non-integer scaling be applied along the horizontal
resolution. This may best disguise scaling artifacts (particularly
inappropriate blurring or uneven repetition, both of which can be a
nuisance) as compared to a genuine SNES on a television. This is
because with NTSC, there is always bleeding occurring horizontally
across display elements anyway, whereas there is a precise number of
horizontal scans down the vertical resolution... and not least, because
NTSC simulation can presumably benefit from any additional horizontal
resolution without issue.
Taking into consideration the wackiness of television, I'm not really
assuming that 4:3 is the best aspect to use (has anyone verified this,
and/or have reasoning for it? what about overscan?).. but for lack of a
better value, I'll use that in the following.
1. Calculate the floor of YHostRes/224. This is our YScale (for those
not familiar with C or math terminology, this is guaranteed to be a
whole number because we round down to the nearest whole number).
2. The vertical resolution of our display surface is equal to YScale*224. I'll call it YDispSurfRes.
3. The horizontal resolution of our display surface should be YDispSurfRes*(4/3). (assumes 1:1 host pixel aspect)
4. Center the display on the screen, leaving black borders (or whatever) on the outside.
Here are some common results-
For a 1024x768 host display:
YDispSurfRes=224*floor(768/224)=224*3=672
XDispSurfRes=672*4/3=896
896x672 display surface.
For a 1280x1024 host display:
YDispSurfRes=224*floor(1024/224)=224*4=896
XDispSurfRes=896*4/3=1194.666
1194x896 display surface. (or 1195 if you prefer)
For 1280x960? Also 1194x896 display surface.
If you're fortunate enough to have a 1200 vertical resolution, then
your YScale will be 5, and the surface would be about 1493x1120.
Total fullscreen is good in another way, so I'm not saying it's bad. I
just thought I'd throw this out there since this seems good to me too. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Apr 18, 2008 6:04 am Post subject: |
|
augnober wrote: |
Taking into consideration the wackiness of television, I'm not really
assuming that 4:3 is the best aspect to use (has anyone verified this,
and/or have reasoning for it? what about overscan?) |
Ideal
behavior. Sure you COULD run a variety of aspect ratios to include
everyone's specific miscalibration of their TV, but... why?
Also the SNES was designed to fill a 4:3 display.
You could also use circular objects as a reference and measure it out, if you were masochistic.
What aspect ratio do YOU think Nintendo was going for?
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
|
augnober New Member
Joined: 18 Apr 2008
Posts: 6
|
Posted: Fri Apr 18, 2008 4:20 pm Post subject: |
|
Gil_Hamilton wrote: |
Also the SNES was designed to fill a 4:3 display.
You could also use circular objects as a reference and measure it out, if you were masochistic.
What aspect ratio do YOU think Nintendo was going for? |
It's not quite this simple. I've seen guidelines for other consoles
(the ones that need to be met for a game to be approved and licensed),
and they typically denote a core area where you are allowed to display
critical information to the player, and an outer border area where you
must not (because on some peoples' televisions, the information would
be obscured by the borders and so they would miss out on seeing
critical gameplay information). So there ends up being a border area
around the outside where although you could display things there, you
need to assume the worst-case scenario and so you don't display a lot
of things there. Around the very outer edge, some developers may even
assume that most people aren't going to see it. Sometimes border color
rather than landscape is drawn outside the normal area, which it would
sometimes be better to not see.. and sometimes you can even find
garbage being drawn in the outer edges which actually happens on real
hardware.
What happens is that developers often design according to the
guidelines and to the expected average display, rather that to a
theoretical ideal display. When you design for a particular display, it
often turns out that it will look best on that display even when that
hardware is 'flawed' -- because you're constantly tweaking and
adjusting to make things look best on it. If the game developers were
targeting a display where the borders are cut off, then yes, I'd like
to play it with some of the border area obscured. Without a
consideration of which pixels are expected to be obscured, there is not
enough information to figure out how to best handle the aspect ratio. I
would expect that on most displays, more of the horizontal area would
be obscured than the vertical.. but that's just a guess.
Last edited by augnober on Fri Apr 18, 2008 4:43 pm; edited 4 times in total
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Fri Apr 18, 2008 4:38 pm Post subject: |
|
augnober wrote: |
I would expect that on most displays, more of the horizontal area would be obscured than the vertical.. but that's just a guess. |
I don't know if any games were designed specifically for PAL consoles
so it could just be a side-effect of conversion, but on PAL TVs you
usually get a small letterboxing effect. To anyone who was around back
then, did we ever look into whether that SoM intro had any overscan on
our TVs? I know we've got the aspect ratio right via some sort of
theoretical calculation that closely matches our results, but that's
obviously not the whole story.
|
|
augnober New Member
Joined: 18 Apr 2008
Posts: 6
|
Posted: Fri Apr 18, 2008 4:58 pm Post subject: |
|
That's a good idea. I've thought about that off and on for years. I
normally ruled it out, figuring that our displays aren't good enough to
display it properly. My thinking was that both the resolution and
brightness that we have is inadequate. I think that's not really true
however. To deal with the brightness, I suspect you would just have to
allow for values during processing which exceed output brightness
limits (which is essence would just be allowing for appropriate values
for bright phosphors) and eventually allow anything that comes out too
bright at the end of processing to saturate.
If you want a sneak peek at the possibilities of what you could get,
try taking some stable snapshots of a television screen (and/or arcade
monitor) with a digital camera and displaying them fullscreen on your
display. Then tweak it as much as you want to get it to look best (with
photoshop filters or color adjustment, etc.). That can give you some
idea of what you could theoretically achieve (it can't disprove its
feasibility, because the camera has its own limitations and cannot show
you the full range of what's possible -- but if it shows you something
nice, then that's a proof of concept at least as far as what your
display can do is concerned). I think something satisfactory could be
found.. and even if turns out that it can't look great fullscreen, it
could still look really cool when displaying a limited zoomed area.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Fri Apr 18, 2008 8:31 pm Post subject: |
|
augnober wrote: |
Gil_Hamilton wrote: |
Also the SNES was designed to fill a 4:3 display.
You could also use circular objects as a reference and measure it out, if you were masochistic.
What aspect ratio do YOU think Nintendo was going for? |
It's not quite this simple. I've seen guidelines for other consoles
(the ones that need to be met for a game to be approved and licensed),
and they typically denote a core area where you are allowed to display
critical information to the player, and an outer border area where you
must not (because on some peoples' televisions, the information would
be obscured by the borders and so they would miss out on seeing
critical gameplay information). So there ends up being a border area
around the outside where although you could display things there, you
need to assume the worst-case scenario and so you don't display a lot
of things there. Around the very outer edge, some developers may even
assume that most people aren't going to see it. Sometimes border color
rather than landscape is drawn outside the normal area, which it would
sometimes be better to not see.. and sometimes you can even find
garbage being drawn in the outer edges which actually happens on real
hardware.
|
Yup.
Overscan compensation makes good sense. Garbage isn't a very good idea, though.
Though I know for a fact that Nintendo wasn't enforcing overscan
compensation on the SNES, as Chrono Trigger's dialog boxes run right up
to the edge of the image, and I've had two TVs where one line end or
another would fall within the overscan area, chopping a character and a
half from every line of dialog in the game(or maybe not, in the case of
the one that clipped the right edge).
Quote: |
What
happens is that developers often design according to the guidelines and
to the expected average display, rather that to a theoretical ideal
display. When you design for a particular display, it often turns out
that it will look best on that display even when that hardware is
'flawed' -- because you're constantly tweaking and adjusting to make
things look best on it. If the game developers were targeting a display
where the borders are cut off, then yes, I'd like to play it with some
of the border area obscured. Without a consideration of which pixels
are expected to be obscured, there is not enough information to figure
out how to best handle the aspect ratio. I would expect that on most
displays, more of the horizontal area would be obscured than the
vertical.. but that's just a guess. |
The fact is every TV is different. The only assumption that makes sense
is evenly-proportioned borders(and on systems with a background color
"frame", this is what you see). Which, again, leaves you with a 4:3
display.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Apr 18, 2008 9:39 pm Post subject: |
|
Most
developers were smart enough to realize that, because overscan varied,
it was smarter to just draw the max without employing borders. You
don't want tvs with little overscan showing that crap. Certainly, you
wish that data was always there in emulation (wonderful FFVI had that
border stuff). I can't imagine it was typical for dialog boxes to be
cut off unless you had really bad set. These games were, after all,
tested on these kinds of displays before getting released. |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sat Apr 19, 2008 4:40 am Post subject: |
|
FitzRoy wrote: |
Most
developers were smart enough to realize that, because overscan varied,
it was smarter to just draw the max without employing borders. You
don't want tvs with little overscan showing that crap. Certainly, you
wish that data was always there in emulation (wonderful FFVI had that
border stuff). I can't imagine it was typical for dialog boxes to be
cut off unless you had really bad set. These games were, after all,
tested on these kinds of displays before getting released. |
Usually(at least on the post-NES stuff), developers struck a middle
ground. They drew to the edge, but all the core stuff had a good margin
around it. You very rarely see a status bar or HUD element positioned
right on the edge of the screen.
The NES, of course, developers often used the first and last tile row
as extra workspace, because "no one's ever gonna see it." They probably
would've done the same with the first and last column if they could've.
|
|
dvdmth Rookie
Joined: 14 Feb 2008
Posts: 14
|
Posted: Sat Apr 19, 2008 3:38 pm Post subject: |
|
Gil_Hamilton wrote: |
The
NES, of course, developers often used the first and last tile row as
extra workspace, because "no one's ever gonna see it." They probably
would've done the same with the first and last column if they could've. |
Some NES games do use the left/right margins, but they usually turn on
the "clip" feature that blanks out the left eight pixels on the screen
(enough to avoid tile artifacts, but not color artifacts). In general,
though, developers preferred to use the top/bottom of the screen
because it had the least impact in NTSC markets. (Due to NES PPU
limitations, it's difficult, in some cases impossible, to avoid
glitching on at least one of the four edges.)
|
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Sat Apr 19, 2008 8:11 pm Post subject: |
|
tetsuo55 wrote: |
FirebrandX wrote: |
Thankfully
I have perfect color vision, but instead I have near-sightedness. The
worst part about being nearsighted (other than everything getting
blurry 3 feet away) is the contant "floaters". This is where I notice
little molecule-looking structures swishing across my field of vision,
epecially when looking at a plain object like a wall. When I was a kid,
I didn't know what it was and assumed I was seeing dust on the surface
of my eye. It wasn't until years later I found out it was eye-jelly
clumps floating inside my eyes and not on them. |
holy shit so thats what that is! (20/20 vision, perfect colors, but i do see floaters)
|
Yeah I see those floaters too, so they are eye-jelly clumps? Is it
anything bad(guessing not)? I always kind of thought they were dust or
something too. Man you learn something new every day(didn't think I'd
learn about this on a discussion about an emulator)
|
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Sun Apr 20, 2008 5:38 am Post subject: |
|
Verdauga Greeneyes wrote: |
Here's another Black Omen picture for reference:
Perhaps you were taking the screenshot too early? It -does- flash, after all.
King Of Chaos, did you ever try my build? |
is
anyone else getting an animated picture of a porn movie? In this
picture and any other picture in the thread that uses hidebehind?
Last edited by joebells on Sun Apr 20, 2008 6:30 am; edited 1 time in total
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Apr 20, 2008 6:13 am Post subject: |
|
joebells wrote: |
Verdauga Greeneyes wrote: |
Here's another Black Omen picture for reference:
*picture removed*
Perhaps you were taking the screenshot too early? It -does- flash, after all.
King Of Chaos, did you ever try my build? |
is
anyone else getting an animated picture of a porn movie? In this
picture and any other picture in the thread that uses hidebehind?
|
The host changed hands or something. It's all porn now.
That's already been discussed. Without quoting the offending images.
|
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Sun Apr 20, 2008 6:29 am Post subject: |
|
sorry
I've been reading through its just so much. I'll take my quote away if
I can, I was actually hoping that I hadn't gotten infectd with some dns
redirector of some sort. |
|
augnober New Member
Joined: 18 Apr 2008
Posts: 6
|
Posted: Sun Apr 20, 2008 7:01 am Post subject: |
|
joebells wrote: |
Yeah
I see those floaters too, so they are eye-jelly clumps? Is it anything
bad(guessing not)? I always kind of thought they were dust or something
too. Man you learn something new every day(didn't think I'd learn about
this on a discussion about an emulator) |
I've got a persistent clump in the middle of one of my eyes. It
horrified me somewhat when it first appeared, but now I'm fairly used
to it (yes, it's the same damn clump permanently floating around in the
center of my vision ).
And as for whether or not it's bad.. An opthamologist told me that it's
just a floater and is harmless (which I suppose means that it's not
going to kill me, is not indicative of something progressively
degenerative, etc. -- since there sure is a dark clump in my vision and
I'd be somewhat interested in blasting it with a laser or something if
I could).
Edit: Well I'll be.. I just Googled it and apparently there is laser
treatment available for floaters. My opthamologist told me there was no
treatment available even when I asked, although that was years and
years ago..
Edit again: It seems that it probably doesn't apply to my floater. Ah well.
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 20, 2008 8:35 am Post subject: |
|
joebells wrote: |
sorry
I've been reading through its just so much. I'll take my quote away if
I can, I was actually hoping that I hadn't gotten infectd with some dns
redirector of some sort. |
These are all removed now. Went back something like a hundred pages. Yay.
But yes, my foresight strikes again. This is the second time a new
member has said "I read the whole bsnes thread, but couldn't find the
problem" as though they were expecting it to be this body of
everlasting relevance. In reality, 40% of it is talking about issues
that no longer exist or have been stickied, 30% is debating features
and concepts that have since been decided upon or superceded, and 30%
is random tangents about eye conditions, European street signs, long
cats, links so old they turn into porn, etc. Personally, I'd wipe it
out to prevent the newbies from inadvertently wasting their time, but
the historians want it preserved for the Smithsonian or something. 1 2
3 fight.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Apr 20, 2008 9:35 am Post subject: |
|
FitzRoy wrote: |
joebells wrote: |
sorry
I've been reading through its just so much. I'll take my quote away if
I can, I was actually hoping that I hadn't gotten infectd with some dns
redirector of some sort. |
These are all removed now. Went back something like a hundred pages. Yay.
But yes, my foresight strikes again. This is the second time a new
member has said "I read the whole bsnes thread, but couldn't find the
problem" as though they were expecting it to be this body of
everlasting relevance. In reality, 40% of it is talking about issues
that no longer exist or have been stickied, 30% is debating features
and concepts that have since been decided upon or superceded, and 30%
is random tangents about eye conditions, European street signs, long
cats, links so old they turn into porn, etc. Personally, I'd wipe it
out to prevent the newbies from inadvertently wasting their time, but
the historians want it preserved for the Smithsonian or something. 1 2
3 fight.
|
Let's ask Harrison Ford!
"It belongs in a museum!"
There you have it.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Apr 20, 2008 9:39 am Post subject: |
|
FitzRoy wrote: |
These are all removed now. Went back something like a hundred pages. Yay. |
Ah, damn. I completely forgot about removing them, though I got back a
few days ago; sorry to make you go through that.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Apr 20, 2008 9:49 am Post subject: |
|
Quote: |
These are all removed now. Went back something like a hundred pages. Yay. |
... whoa! Three cheers for FitzRoy :D
I can't handle more than three pages of this thread. Even the board
search doesn't point you to a specific page, so I just use Google to
search through it all.
Quote: |
30%
is random tangents about eye conditions, European street signs, long
cats, links so old they turn into porn, etc. Personally, I'd wipe it
out to prevent the newbies from inadvertently wasting their time, but
the historians want it preserved for the Smithsonian or something. |
Yes, look what you have created :P
Heh, seriously, I don't mind deleting the thread. The ZSNES SQL server
would no doubt love us for it. So, who's up for indexing the whole
thread and sticking it into a ZIP file somwhere for the Smithsonian? :P
The only real advantage in the thread is the bugfix solutions for a few
dozen titles. Would be a huge help to new emulator authors, as we all
seem to run into the same bugs.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Sun Apr 20, 2008 2:12 pm Post subject: |
|
byuu wrote: |
Quote: |
These are all removed now. Went back something like a hundred pages. Yay. |
... whoa! Three cheers for FitzRoy 
I can't handle more than three pages of this thread. Even the board
search doesn't point you to a specific page, so I just use Google to
search through it all.
|
Well, you can let it "display results as posts", which helps a bit.
_________________
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: Sun Apr 20, 2008 2:17 pm Post subject: |
|
search with the phrase containing...
zsnes or "running zsnes under DOS" and you will get a billion results most forums let you search for a phrase and not just each word in the phrase.
the reuslts would contain either ZSNES, RUNNING, UNDER and/or DOS...
_________________
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. |
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Sun Apr 20, 2008 2:24 pm Post subject: |
|
I'm
finding some decent info in here though. I found a spot that details,
somewhat, what is needed to compile it. Maybe leave it but lock it so
that it doesn't just keep growing? |
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Sun Apr 20, 2008 4:47 pm Post subject: |
|
The zip idea sounds good. Perhaps we could do it in stages.
As for compiling bsnes, it isn't as hard as it used to be:
1.) Get MinGW 4: runtime, win32api, make, gcc-core and gcc-g++
2.) Get the DirectX SDK or a minimalist implementation as mentioned
3.) Copy headers from SDK or w/e over to MinGW, overwriting the previous ones (look for the 'include' folder)
4.) Make sure you have Path set up correctly (i.e. it points to MinGW's
bin folder) and the executables have the right names (mingw32-make.exe
-> make.exe, remove -sjlj part from various files if needed;
alternatively you can edit bsnes' makefile) |
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Sun Apr 20, 2008 7:21 pm Post subject: |
|
franpa wrote: |
search with the phrase containing...
zsnes or "running zsnes under DOS" and you will get a billion results most forums let you search for a phrase and not just each word in the phrase.
the reuslts would contain either ZSNES, RUNNING, UNDER and/or DOS... |
Once again, you fail.
You see the radio buttons under the search box?
The ones that say "search for any terms" and "search for all terms"?
Do you know what happens if you check "search for all terms?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Apr 20, 2008 11:47 pm Post subject: |
|
byuu wrote: |
The only real advantage in the thread is the bugfix solutions for a few
dozen titles. Would be a huge help to new emulator authors, as we all
seem to run into the same bugs. |
Didn't you say you were planning on writing some modern documentation
after bsnes was finished? That would be the best thing, I think.
|
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Sun Apr 20, 2008 11:53 pm Post subject: |
|
Verdauga Greeneyes wrote: |
The zip idea sounds good. Perhaps we could do it in stages.
As for compiling bsnes, it isn't as hard as it used to be:
1.) Get MinGW 4: runtime, win32api, make, gcc-core and gcc-g++
2.) Get the DirectX SDK or a minimalist implementation as mentioned
3.) Copy headers from SDK or w/e over to MinGW, overwriting the previous ones (look for the 'include' folder)
4.) Make sure you have Path set up correctly (i.e. it points to MinGW's
bin folder) and the executables have the right names (mingw32-make.exe
-> make.exe, remove -sjlj part from various files if needed;
alternatively you can edit bsnes' makefile) |
Thanks.
It has to be dx9 right? I'd prefer to get away without the whole sdk if
possible so I was wondering if anyone might know where to get the
minimalist implementation? I've been searching just haven't found it
yet.
eh I just went ahead and downloaded the whole thing
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Mon Apr 21, 2008 5:04 am Post subject: |
|
Gil_Hamilton wrote: |
franpa wrote: |
search with the phrase containing...
zsnes or "running zsnes under DOS" and you will get a billion results most forums let you search for a phrase and not just each word in the phrase.
the reuslts would contain either ZSNES, RUNNING, UNDER and/or DOS... |
Once again, you fail.
You see the radio buttons under the search box?
The ones that say "search for any terms" and "search for all terms"?
Do you know what happens if you check "search for all terms?
|
"search for all terms" it searches using all terms and not the exact phrase you entered.
edit: ill take a snapshot to make it clearer to you if need be.
EDIT 2: http://i63.photobucket.com/albums/h133/franpa/untitled-9.png
http://i63.photobucket.com/albums/h133/franpa/untitled1.png
Note that there is thousands of posts shown that do not contain that phrase 
_________________
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.
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Mon Apr 21, 2008 5:37 am Post subject: |
|
I finally got bsnes.exe made. I download the MinGW-5.1.3.exe and dxsdk_march2008.exe. Install both of them.
Copy C:\Program Files\Microsoft DirectX SDK (March 2008)\Include and then paste into C:\Games\bsnes\mingw\include
My setup on make (run.bat).
@echo off
cd c:\games\bsnes\src
set path=c:\games\bsnes\mingw\bin;
@make platform=win compiler=mingw32-gcc enable_gzip=true enable_jma=true
@pause
clean
@pause
I found no errors so ever after run make.
I was stress out before and fail getting it set up the right way.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
henke37 Lurker
Joined: 10 Apr 2007
Posts: 131
Location: Sweden
|
Posted: Mon Apr 21, 2008 5:47 am Post subject: |
|
The solution to this topic being too big is to simply lock it. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Apr 21, 2008 5:48 am Post subject: |
|
henke37 wrote: |
The solution to this topic being too big is to simply lock it. |
_________________
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 Apr 21, 2008 5:54 am Post subject: |
|
The problem is not size alone, it is size and content. Newbies are assuming relevance and scouring it for solutions where they're unlikely to find any. Locking it doesn't help that. |
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Mon Apr 21, 2008 6:32 am Post subject: |
|
Dullaron wrote: |
I finally got bsnes.exe made. I download the MinGW-5.1.3.exe and dxsdk_march2008.exe. Install both of them.
Copy C:\Program Files\Microsoft DirectX SDK (March 2008)\Include and
then paste into C:\Games\bsnes\mingw\include
My setup on make (run.bat).
@echo off
cd c:\games\bsnes\src
set path=c:\games\bsnes\mingw\bin;
@make platform=win compiler=mingw32-gcc enable_gzip=true enable_jma=true
@pause
clean
@pause
I found no errors so ever after run make.
I was stress out before and fail getting it set up the right way. |
I believe that is just gcc 3.4.5 though and I believe it will run
faster with the 4 series of gcc(I may be totally off though). I also
downloaded the mingw 5.1.3 and the dxsdk_march2008 installed mingw,
unpacked the dx file and unpacked the file it created and copied the
files from the include folder into mingw include. But then I downloaded
gcc 4.2.1 and pasted it into my mingw folder and then went in and
changed all the old files to xxxx.exe.old and removed the sjlj from all
the new files but it won't compile for me it says
Code: |
mingw32-gcc -O3 -fomit-frame-pointer -Ilib -static -c lib/libco/libco.c -o obj/l
ibco.o
mingw32-gcc: CreateProcess: No such file or directory
make: *** [obj/libco.o] Error 1 |
am I off in changing gcc to 4.2.1? Should I just leave it as 3.4.5?
Should I be changing the version differently? Aye carumba. I was trying
the basic compile before I mess with any flags. Is x64 working under
windows, I understand mingw by itself can't do x64 in windows but I
have a mingw environment with some ms stuff added that allows
compilation of x64 mame.
Thanks for any assistance
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Apr 21, 2008 12:13 pm Post subject: |
|
I think you missed a small part of my post You need to either copy/rename mingw32-make.exe to make.exe, or change bsnes' makefile accordingly.
I'm not sure if bsnes compiles with GCC 3 at all, don't remember if the
problem it got with GCC 3 was ever 'fixed' (it wasn't really bsnes at
fault, just some strange implementation/behaviour by the compiler). |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Mon Apr 21, 2008 2:22 pm Post subject: |
|
3.4.5 is working fine here. I didn't use 4.2.1.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Mon Apr 21, 2008 2:44 pm Post subject: |
|
Verdauga Greeneyes wrote: |
I think you missed a small part of my post You need to either copy/rename mingw32-make.exe to make.exe, or change bsnes' makefile accordingly.
I'm not sure if bsnes compiles with GCC 3 at all, don't remember if the
problem it got with GCC 3 was ever 'fixed' (it wasn't really bsnes at
fault, just some strange implementation/behaviour by the compiler). |
oh yeah I changed that or else I do not think that it would of even started the compilation?
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Apr 21, 2008 3:11 pm Post subject: |
|
Did
you remember to set the Path environment variable and remove the -sjlj
from the mingw32-* files? (if you did all that.. I dunno. Maybe you're
missing some x64 specific mingw components?) |
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Mon Apr 21, 2008 3:23 pm Post subject: |
|
Dullaron wrote: |
3.4.5 is working fine here. I didn't use 4.2.1. |
I think that 3.4.5 won't be as fast though(I'm trying to get it just a bit faster than what it currently is)
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Apr 21, 2008 4:15 pm Post subject: |
|
How about a deadline:
This thread will die horribly in... 5 days. Get in archiving gear.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Mon Apr 21, 2008 10:14 pm Post subject: |
|
joebells wrote: |
Dullaron wrote: |
3.4.5 is working fine here. I didn't use 4.2.1. |
I think that 3.4.5 won't be as fast though(I'm trying to get it just a bit faster than what it currently is)
|
I didn't get any slowdown on make. I guest it depend how much computer
speed and memories. It done less than 30 seconds on my machine.
Is there anything running in the background on your machine? I only have AnyDVD, AntiVir and SnagIt running.
Edit. Heh 4.2.1 gave me an error. I will stick on what I been using. I think the newer files broken it.
Code: |
mingw32-g++ -O3 -fomit-frame-pointer -Ilib -DGZIP_SUPPORT -DJMA_SUPPORT -c ui/ma
in.cpp -o obj/main.o
mingw32-gcc -O3 -fomit-frame-pointer -Ilib -DGZIP_SUPPORT -DJMA_SUPPORT -static
-c lib/libco/libco.c -o obj/libco.o
mingw32-gcc: CreateProcess: No such file or directory
make: *** [obj/libco.o] Error 1
Press any key to continue . . . |
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Mon Apr 21, 2008 10:58 pm Post subject: |
|
Dullaron wrote: |
I
didn't get any slowdown on make. I guest it depend how much computer
speed and memories. It done less than 30 seconds on my machine. |
No, he meant that bsnes will run slower with GCC 3, which is correct.
|
|
|
joebells Rookie
Joined: 17 Apr 2008
Posts: 33
|
Posted: Tue Apr 22, 2008 1:34 am Post subject: |
|
Verdauga
Greeneyes would you have any advice to upgrade a working setup for
3.4.5 to 4.2.1? I went with the exe install from the website, I even
checked the developmental I think it was called but it still just
pulled in 3.4.5 for some reason. I then tried to copy over the gcc
4.2.1 files from the sourceforge website and renamed the files to get
rid of sjlj but it gives me the same error that dullaron is getting.
I appreciate any advice |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Tue Apr 22, 2008 6:56 am Post subject: |
|
Verdauga Greeneyes wrote: |
Dullaron wrote: |
I
didn't get any slowdown on make. I guest it depend how much computer
speed and memories. It done less than 30 seconds on my machine. |
No, he meant that bsnes will run slower with GCC 3, which is correct.
|
How is it slower? I getting 60/60 on most of the games. No lagging or
anything so far I can tell. Run just like byuu made. Can you explain to
me what is slower?

_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Apr 22, 2008 7:06 am Post subject: |
|
Disable the frame rate limiter. If a version could be made with GCC 4.x.x then you would see it running faster... higher fps.
_________________
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. |
|
Dullaron Hazed
Joined: 10 Mar 2008
Posts: 67
|
Posted: Tue Apr 22, 2008 8:54 am Post subject: |
|
I download the update. gcc-4.3.0-mingw-alpha-20080403.tar.gz This one works.
Only 2 things can't be change.
1. mingw\lib\gcc\i386-pc-mingw32 > Don't rename!
2. mingw\libexec\gcc\i386-pc-mingw32 > Don't rename!
The names have to stay like that other wise the error pop up on make.
Delete these folders. These are outdated.
1. mingw\lib\gcc\mingw32\3.4.5
2. mingw\libexec\gcc\mingw32\3.4.5
3. mingw\bin > Trash this file too. > mingw32-gcc-3.4.5 <
franpa here is the speed I get after disabled the frame rate limiter.

bsnes.exe is about 2mb.
_________________
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT |
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Apr 22, 2008 12:44 pm Post subject: |
|
You
know how waaaay back when i said BSNES does not run in a single thread?
according to Sysinternals Process Explorer, bsnes 0.31 uses 9 threads
when running Megaman x3
_________________
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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 22, 2008 12:50 pm Post subject: |
|
franpa wrote: |
You
know how waaaay back when i said BSNES does not run in a single thread?
according to Sysinternals Process Explorer, bsnes 0.31 uses 9 threads
when running Megaman x3 |
And I've explained it already. bsnes itself does not use more than one kernel-level thread -- period.
You see nine threads because bsnes loads lots of other stuff. Direct3D,
DirectSound, DirectInput, etc etc. Those libraries can create all the
threads they want.
But the fact of the matter is, I wrote bsnes. I know what's in the code. And there's no call to "CreateThread" in any
of my code. Hence, the bsnes source is not multi-threaded. The closest
you get is cothreads, which all run on the same CPU core, and are done
completely in userspace.
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Apr 22, 2008 12:53 pm Post subject: |
|
Stupid question:
I know multi-threading with one thread per SNES processor isn't viable
now for multiple reason. Would it be viable when you have like 12+
cores available?
I imagine not, but I'm no programmer... |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Apr 22, 2008 1:01 pm Post subject: |
|
It's not about the number of cores - communication between cores and and thread switches are too slow.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Apr 22, 2008 1:04 pm Post subject: |
|
creaothceann wrote: |
It's not about the number of cores - communication between cores and and thread switches are too slow. |
Ah.
Thank you, creaothceann.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Tue Apr 22, 2008 1:17 pm Post subject: |
|
byuu wrote: |
franpa wrote: |
You
know how waaaay back when i said BSNES does not run in a single thread?
according to Sysinternals Process Explorer, bsnes 0.31 uses 9 threads
when running Megaman x3 |
And I've explained it already. bsnes itself does not use more than one kernel-level thread -- period.
You see nine threads because bsnes loads lots of other stuff. Direct3D,
DirectSound, DirectInput, etc etc. Those libraries can create all the
threads they want.
But the fact of the
matter is, I wrote bsnes. I know what's in the code. And there's no
call to "CreateThread" in any
of my code. Hence, the bsnes source is not multi-threaded. The closest
you get is cothreads, which all run on the same CPU core, and are done
completely in userspace.
|
Why
then does BOTH my CPU cores get used by Bsnes? it occures with my old
Pentium 4 630 (3.00ghz) and Asus P5LD2 motherboard too.
_________________
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.
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Tue Apr 22, 2008 1:23 pm Post subject: |
|
franpa wrote: |
Why
then does BOTH my CPU cores get used by Bsnes? it occures with my old
Pentium 4 630 (3.00ghz) and Asus P5LD2 motherboard too. |
*facepalm*
byuu wrote: |
You
see nine threads because bsnes loads lots of other stuff. Direct3D,
DirectSound, DirectInput, etc etc. Those libraries can create all the
threads they want. |
..and those threads, which are likely to be spread among multiple
cores, show up in that simplified view as being part of BSNES. Hence,
BSNES "uses" multiple cores, according to that tool.
_________________
Why yes, my shift key *IS* broken.
|
|
Verdauga Greeneyes Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
|
Posted: Tue Apr 22, 2008 4:09 pm Post subject: |
|
creaothceann wrote: |
It's not about the number of cores - communication between cores and and thread switches are too slow. |
Although communication between cores is supposed to speed up in the
future, thanks to say HT 3.0 and the bandwidth gained by using optical
interconnects. I wouldn't hold my breath though. (besides, there's
still the necessary switches between user and kernel mode.. perhaps
future OSes will figure out a better way of doing that, but they'd have
to work together with CPU designers to pull it off and there probably
isn't enough interest)
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Tue Apr 22, 2008 6:10 pm Post subject: |
|
4 days left.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
I.S.T. Trooper
Joined: 27 Nov 2007
Posts: 350
|
Posted: Tue Apr 22, 2008 6:15 pm Post subject: |
|
Wha? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Apr 22, 2008 6:17 pm Post subject: |
|
Hehe, you guys are gonna be forced to make a thread. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Tue Apr 22, 2008 6:22 pm Post subject: |
|
>> 167017
>> 167037
>> 167118
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Tue Apr 22, 2008 6:53 pm Post subject: |
|
I figure at the last second someone's gonna play the song of time and we'll have another 5 days of discussion :P |
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
Posted: Tue Apr 22, 2008 7:57 pm Post subject: |
|
2.75 days left (EDT)
that is all
_________________

<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

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Apr 22, 2008 8:02 pm Post subject: |
|
Honestly, I was hoping to get the view count to one million before ending the thread. Someone start up a wget loop, stat! :P |
|
kode54 Veteran

Joined: 28 Jul 2004
Posts: 789
|
Posted: Tue Apr 22, 2008 11:06 pm Post subject: |
|
franpa wrote: |
Why
then does BOTH my CPU cores get used by Bsnes? it occures with my old
Pentium 4 630 (3.00ghz) and Asus P5LD2 motherboard too. |
Your P4 does not have two cores. Hyperthreading is nowhere near as
efficient as two real cores, so one thread can easily max out your
processor.
|
|
Gil_Hamilton Inmate
Joined: 12 Jan 2005
Posts: 1378
|
Posted: Wed Apr 23, 2008 12:54 am Post subject: |
|
byuu wrote: |
Honestly, I was hoping to get the view count to one million before ending the thread. Someone start up a wget loop, stat!  |
I can start poking F5...
|
|
ndru New Member

Joined: 30 Nov 2004
Posts: 8
|
Posted: Wed Apr 23, 2008 2:14 am Post subject: |
|
franpa wrote: |
Why
then does BOTH my CPU cores get used by Bsnes? it occures with my old
Pentium 4 630 (3.00ghz) and Asus P5LD2 motherboard too. |
This is also likely due to the OS scheduler. A single thread doesn't
necessarily stay on a single core all the time (unless you explicitly
set its affinity), so for example you might find on a dual-core CPU
that a thread spends 60% of its time on one core, and 40% on the other.
Either way the performance is the same as if it stayed on one core.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Apr 23, 2008 4:18 am Post subject: |
|
odditude wrote: |
franpa wrote: |
Why
then does BOTH my CPU cores get used by Bsnes? it occures with my old
Pentium 4 630 (3.00ghz) and Asus P5LD2 motherboard too. |
*facepalm*
byuu wrote: |
You
see nine threads because bsnes loads lots of other stuff. Direct3D,
DirectSound, DirectInput, etc etc. Those libraries can create all the
threads they want. |
..and those threads, which are likely to be spread among multiple
cores, show up in that simplified view as being part of BSNES. Hence,
BSNES "uses" multiple cores, according to that tool.
|
what are co-threads? didnt Byuu just say that all the 9 "threads" i see are run on the one core?
_________________
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.
|
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Wed Apr 23, 2008 6:11 am Post subject: |
|
franpa.
silly franpa.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
|
|
odditude Regular
Joined: 25 Jan 2006
Posts: 297
|
Posted: Wed Apr 23, 2008 12:43 pm Post subject: |
|
franpa wrote: |
didnt Byuu just say that all the 9 "threads" i see are run on the one core? |
No.
_________________
Why yes, my shift key *IS* broken.
|
|
franpa Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
|
Posted: Wed Apr 23, 2008 2:33 pm Post subject: |
|
I gathered that thanks to the extremely helpful article that creaothceann posted.
_________________
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. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Wed Apr 23, 2008 3:59 pm Post subject: |
|
3 days...
Hmm...
Dawn of
the First Day
(cue Termina theme)
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
DancemasterGlenn Regular

Joined: 21 Apr 2007
Posts: 331
|
Posted: Wed Apr 23, 2008 4:01 pm Post subject: |
|
Haha, yessssssssssss. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Apr 24, 2008 4:44 pm Post subject: |
|
Dawn of
the Second Day
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Thu Apr 24, 2008 5:30 pm Post subject: |
|
Is
there a way to make a printer-friendly version of this thread (all
posts would be in one page)? It would make the archiving process
simpler.
There are probably phpBB mods that do this. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Apr 24, 2008 5:51 pm Post subject: |
|
xamenus wrote: |
(all posts would be in one page) |
I can try and set the amount of posts per page to 5750 for a small
time... (not sure it would work without dying horribly, though)
_________________
皆黙って俺について来い!!
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: Thu Apr 24, 2008 6:52 pm Post subject: |
|
It's not even a question, it would die an excruciating death.
If I'm not mistaken, the server has a memory limit per query and has to
get other things beside the post data. It'll be agonizing.
_________________
"Dearly beloved, we gather here today to join this wooden stick, with
Aerdan's butt, in holy matrimony, and may they not part until death, or
perhaps extremely powerful bowel movements." - Metatron at the wedding
of Aerdan's butt and a stick
Last edited by Metatron on Thu Apr 24, 2008 8:46 pm; edited 1 time in total |
|
funkyass "God"
Joined: 27 Jul 2004
Posts: 1171
|
Posted: Thu Apr 24, 2008 8:20 pm Post subject: |
|
write a simple script to use wget and save it that way.
probably a firefox extension that do something similar.
_________________
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don't change the subject. |
|