bsnes board bsnes and other SNES related stuff

FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Wed Aug 31, 2005 4:13 am Post subject: bsnes thread bsnes is a super-accurate, cross-platform SNES emulator by byuu. You can read all about it and download new versions at: http://byuu.org. The title of this thread will change to reflect new releases. All commercially released games have been tested (~3000) and it is currently believed that 99.9% of games without special chips play with 100% perceived accuracy. The emulator contains no game-specific hacks and makes almost no compromises to compatibility for speed gains. This means that bsnes has very high minimum requirements: at least a 1.8ghz Core 2 Duo to achieve 60fps without frameskipping. bsnes' PPU is scanline-based rather than dot-based. A scanline-based renderer is technically a general hack that most emulators use to simplify the PPU and achieve massive speed gains with virtually no sacrifice to compatibility. Without it, bsnes wouldn't even come close to reaching 60fps on modern CPUs. That said, only a few obscure games have issues with a scanline-based renderer, and the issue is usually very minor and takes the form of an incorrectly displayed horizontal line on a menu screen (thus the .1% deduction above). Several advanced options have been created to make the scanline-based renderer behave closer to a dot-based one, improving accuracy without resorting to game-specific hacks. byuu has stated that he may in the future begin writing a dot-based renderer out of a desire to document the SNES' PPU. ORIGINAL POST: As some of us may or not know, byuu released a new version of his snes emulator last week. byuu, although I'm sure the resources for help are better today than in the past, you ARE a code monster. Seriously, the level your emu is at now from when you started is crazy. I am also pleasantly surprised by how often you post updates, and the detail with which you blog. It's interesting to see your train of thought in the progress of your emu. So yeah, just wanted to let you know that you rock since I've never seen anyone post a bsnes update here yet. I read your recent log and... until now I had no idea that you knew next to nothing about sound. Naturally, my hopes for a 1-2 punch emu were once again somewhat dashed. As an outsider who knows not much at all about code, I can only be so critical and frustrated with the stagnance in snes sound emulation right now. A lot of great, accurate emus out there, but the same ol "sound is a real bitch" issue that just puts a grinding halt to the possibility of snes ultimacy. I've pretty much given up hope of zsnes ever getting the sound issues fixed. We're lucky to get a gamefix at all anymore in the wips. Understandably, but true. Anyways, I'm sure TRAC knows how godlike his sound code is, and probably has his reasons for not wanting to entrust it to other emulators. Additionally, he probably knows that if he doesn't, any hope of snes ultimacy will continue to be snuffed out. I guess what I'm getting at here is: WHO IS THIS TRAC!? : 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	Posted: Mon Sep 05, 2005 2:50 am Post subject: http://board.zsnes.com/phpBB2/viewtopic.php?t=4352 _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
adventure_of_link Locksmith of Hyrule Joined: 08 Aug 2004 Posts: 4533 Location: 255.255.255.255	Posted: Mon Sep 05, 2005 4:41 am Post subject: IIRC pagefault will be porting ZSnes to XBox, if and when he gets one You'll have to have it modded though, nothing we can do about that -_- _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu bsnes Developer 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	Posted: Thu Sep 15, 2005 6:58 pm Post subject: More news: http://byuu.cinnamonpirate.com/?page=bsnes_news _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Fri Sep 16, 2005 5:29 am Post subject: Some of it bad news, too. My 2.4ghz works hard to get ~50fps in bsnes as it is right now. I guess it goes to show how difficult it is to have fast and accurate code. Help the BYUU!!! By the way, it must be pretty exciting for byuu to see his emu almost becoming fully playable with sound and everything. *waits patiently for new versions*
Nach ZSNES Developer 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	Posted: Tue Sep 20, 2005 2:48 am Post subject: I'm excited to try out your next release. Can you highlight some games that your emulator runs better than ZSNES/snes9x/SNEESE? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
byuu bsnes Developer 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: DMV27 wrote: Der Langrisser SPC Soundtrack Nifty, which track is the problem?
kode54 Veteran Joined: 28 Jul 2004 Posts: 789	Posted: Tue Oct 04, 2005 12:48 pm Post subject: I find that even with Direct3D9, I either get cracking sound, or I get a picture that doesn't sync perfectly all of the time. There seems to be an issue with the number of samples generated and the sound output. ( Taking a running average, with NTSC, it seems to average ~31947.3 samples per second, assuming 60 frames per second. ) Needs more work... ( PS. You should be able to delete your own posts, if you check the "Delete this post." box. If that box is not present, somebody shoot the phpBB devs for allowing regular users to edit their own posts, but not delete them. )
Noxious Ninja Dark Wind Joined: 29 Jul 2004 Posts: 2713 Location: teh intarwebs	Posted: Tue Oct 04, 2005 1:10 pm Post subject: kode54 wrote: ( PS. You should be able to delete your own posts, if you check the "Delete this post." box. If that box is not present, somebody shoot the phpBB devs for allowing regular users to edit their own posts, but not delete them. ) Regular users can't delete their own posts. It sucks. _________________ #577451
adventure_of_link Locksmith of Hyrule Joined: 08 Aug 2004 Posts: 4533 Location: 255.255.255.255	Posted: Tue Oct 04, 2005 6:33 pm Post subject: Besides, there is no "Delete this post" box. It's a nice little letter X box next to the word "EDIT." Editing/deleting posts is adjusted through the permissions by the admin(s), right ? _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
byuu bsnes Developer 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	Posted: Mon Oct 24, 2005 8:31 pm Post subject: If you don't plan on asking Lik-Sang for the Super SmartJoy, I could order you a gamepad of your choice. Let me know. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
p00f Lurker Joined: 17 Sep 2005 Posts: 186	Posted: Mon Oct 24, 2005 8:32 pm Post subject: I'll donate you a gamepad if needed as well.
byuu bsnes Developer 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	Posted: Tue Nov 01, 2005 4:52 pm Post subject: Maybe he already HAS a girl, who DOES dig his l33t skillz. Hey byuu, get your girlfriend to sign up on the board! _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
vigi_lante Hazed Joined: 15 Nov 2004 Posts: 65	Posted: Wed Nov 02, 2005 12:03 am Post subject: ArcadeVGA does (true) 512x448. I think the best way would do something like Snake did with Kega Fusion... http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=40418&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1121281319 You just write what kind of resolution you want to use for each game that have a specific resolution, and it will automatically change your resolution, according to what the game displays. And the resolution change process also is very smooth. By the way, the vertical x224 resolution of SNES output signal are actually still 240 lines, with blank borders which make up the difference from, for example 224 lines to 240. This is because TVs cannot display resolutions lower than 240 lines.
FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Wed Nov 02, 2005 1:57 am Post subject: I'm confused by this whole resolution thing. If the higher one were to be implimented, and it were stretched to fill a 4:3 screen, would we then have black bars around the whole image? Or is there actual picture data that bsnes could gain from this "more accurate" res?
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Wed Nov 02, 2005 2:35 am Post subject: No, not around the whole thing. Just on the top and bottom. Apparently, the difference is (240-224)=16. So, I assume 16 split between the top and bottom, so a whopping total of 8 lines above and below the image. Apparently some PAL games have output on 15 of those 16 lines? I get the sense that there would be no additional output for any NTSC games. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
grinvader ZSNES Plasma Prinny 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	Posted: Mon Nov 14, 2005 3:56 am Post subject: FitzRoy wrote: You know how to use it right? Yeah, it was working for me in 0.013. I'll reconfigure everything and try again. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
Pepper New Member Joined: 08 Sep 2005 Posts: 6	Posted: Mon Nov 14, 2005 4:54 pm Post subject: Hmmm.... The game from the following thread doesn't seem to work past the start screen. http://board.zsnes.com/phpBB2/viewtopic.php?t=5407
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Mon Nov 14, 2005 6:01 pm Post subject: It may be a special-chip game that is not (yet?) emulated in bsnes. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Mon Nov 14, 2005 6:50 pm Post subject: Rendering Ranger R2 isn't a special chip game, but it is one of those "special timing" games. It was broken in zsnes for a really long time as I recall. Super Double Dragon is more of a mystery. I always thought that was one of the earlier games for the system. I guess it does something wierd as well.
ThunderClaw I know where you live. Joined: 19 Aug 2004 Posts: 744	Posted: Mon Nov 14, 2005 11:13 pm Post subject: OK, I tried it out on my newer computer; the extra guts did indeed fix the framerate problem. (Athlon XP 2500+, Radeon 9700 PRO, nForce2 integrated sound) I have two bugs to report. 1) Really fucking weird; the Y button appears to be nonfunctional in Romance of the Three Kingdoms 4, Wall of Fire. On creating a ruler, the Y button is used to deduct 10 stat points from a certain area; it completely fails to register. I know the button is mapped correctly, because I immediately loaded up Megaman 7, and I could fire just fine. 2) As a direct result of 1, I realized that MM7's sound crackles even when the framerate is at a constant 60. I'll continue to look into this to see if it could be my end. _________________ FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that. phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin. I smell spray paint.
byuu bsnes Developer 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	Posted: Sat Nov 19, 2005 12:48 pm Post subject: -_pentium5.1_- wrote: BTW byuu, when will the news of this release make it to the major emulation news sites? I don't mean to be pushy, but I still haven't figured out why my computer can't correctly download bsnes from your site. The latest bsnes is mirrored at Emulation64 as always: http://www.emulation64.com/files/info/489/ _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
adventure_of_link Locksmith of Hyrule Joined: 08 Aug 2004 Posts: 4533 Location: 255.255.255.255	Posted: Mon Nov 21, 2005 1:43 am Post subject: byuusan: If you still need a forum, I've got one: http://linksadventure.no-ip.org/phpbb2/viewforum.php?f=8 _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
creaothceann Seen it all Joined: 03 Jan 2005 Posts: 2324 Location: Germany	Posted: Mon Nov 21, 2005 8:33 am Post subject: -_pentium5.1_- wrote: BTW byuu, when will the news of this release make it to the major emulation news sites? I don't mean to be pushy, but I still haven't figured out why my computer can't correctly download bsnes from your site. What about AEP? _________________ savestate editor: vSNES latest public version FitzRoy wrote: Seriously, people need to stop arguing with me on this.
byuu bsnes Developer 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	Posted: Tue Nov 29, 2005 5:44 am Post subject: Hey Byuu, any chance you would want to use this snes pad for your mapping image instead? It's even 1/4 the size. http://home.mchsi.com/~s.daystrom/snespad.bmp
byuu bsnes Developer 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	Posted: Mon Dec 05, 2005 11:32 pm Post subject: Yes. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
adventure_of_link Locksmith of Hyrule Joined: 08 Aug 2004 Posts: 4533 Location: 255.255.255.255	Posted: Mon Dec 05, 2005 11:46 pm Post subject: That's what I thought, thanks Clements. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Mon Dec 05, 2005 11:46 pm Post subject: byuu wrote: I didn't fix any CPU errors in the last release (that I remember), so Rendering Ranger R2 is still broken. And I just confirmed, it freezes at the start of a new level. Ace is a DSP-1 game.' Thank you for taking the time to prove that I'm retarded. "SuPAr NinTeNdO derrrrr..." I stand firmly behind the rest of my bug list... I think.
byuu bsnes Developer Joined: 12 Oct 2004 Posts: 2414	Posted: Tue Dec 06, 2005 10:33 am Post subject: Quote: DirectInput Pad2 It can now poll the first 256 joypads in your system, and 128 buttons on each one (+4 for directional pad). So you can have up to 32k joypad buttons, plus your keyboard, to map to all 12*2 SNES buttons. Now I just need to add support for my PCTV Pro remote control (serial device with an IR sensor), and we're good. Also lowered the strength on the x/y axes for the d-pad, makes doing combo moves in fighters a hell of a lot easier when using the thumb stick. Also mapped the POV hat to the d-pad, so now digital and analog mode both work fine. Genjuu Ryodan is another game that doesn't work right. HDMA problems.
Shinrin Hazed Joined: 19 Jan 2005 Posts: 73 Location: 127.0.0.1	Posted: Wed Dec 07, 2005 4:15 pm Post subject: byuu wrote: Quote: DirectInput Pad2 It can now poll the first 256 joypads in your system, and 128 buttons on each one (+4 for directional pad). So you can have up to 32k joypad buttons, plus your keyboard, to map to all 12*2 SNES buttons. Now I just need to add support for my PCTV Pro remote control (serial device with an IR sensor), and we're good. What the hell, is a hell of a lotta buttons you can use.. This emulator is getting on par with zsnes. _________________ Get Fire Fox now! If not, get ready to put up with spy-ware and ad-ware!
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: Nach wrote: pagefault wrote: You haven't heard anything yet... How about this? http://nsrt.edgeemu.com/topintro.rar Well, bsnes still sounds better in my opinion. But that's probably mostly due to the fact that your avi has lossy audio. Even with the lossy audio though, it's sounding a lot better than it old ZSNES builds. Great work, pagefault! The only way we're going to be able to prove who the victor is now is by capturing the raw digital sound output from a real SNES and comparing :) <evil> Now let's compare sounds in Earthworm Jim 2 ... </evil> Quote: byuu, in your eventual implementation of save states, do you have any interest in doing something like this? Not really, but I don't think it'd be that hard to do...
pagefault ZSNES Developer Joined: 17 Aug 2004 Posts: 887 Location: In your garden	Posted: Thu Dec 15, 2005 10:23 am Post subject: byuu wrote: Nach wrote: pagefault wrote: You haven't heard anything yet... How about this? http://nsrt.edgeemu.com/topintro.rar Well, bsnes still sounds better in my opinion. But that's probably mostly due to the fact that your avi has lossy audio. Even with the lossy audio though, it's sounding a lot better than it old ZSNES builds. Great work, pagefault! The only way we're going to be able to prove who the victor is now is by capturing the raw digital sound output from a real SNES and comparing <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	Posted: Wed Feb 01, 2006 5:25 am Post subject: byuu wrote: to prepare for the dot-based renderer Sweet Jesus! (Now with more sodium!) _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
Nach ZSNES Developer 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	Posted: Sun Feb 12, 2006 4:09 am Post subject: Leave your puerile feature requests out of this thread. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
error999 New Member Joined: 07 Feb 2006 Posts: 5	Posted: Sun Feb 12, 2006 4:20 am Post subject: Jipcy wrote: Leave your puerile feature requests out of this thread. Maybe you have a reading problem, let me quote my self. "Are you gona add filters like HQ2X or openGL. also, save states? love the emu great work!" key word ARE!. Pointing out the obvious.... I can bash you all day long, but i have no time for little forum trolls. _________________ The 2 cowboys have emerged. beware of forum trolls. Joined: 28 Dec 2004 Posts: 605 <------ Last edited by error999 on Sun Feb 12, 2006 7:29 am; edited 1 time in total
DataPath Lurker Joined: 28 Jul 2004 Posts: 144	Posted: Sun Feb 12, 2006 4:35 am Post subject: Error - just to update you - the main goal of bsnes isn't to have a fancy, pretty emulator to take the place of Snes9x or ZSNES, but to have an extremely accurate emulator with good debugging facilities. In concept, bsnes is aimed at romhackers.
Deathlike2 ZSNES Developer 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	Posted: Thu Feb 23, 2006 4:30 am Post subject: He's gonna do both. One's going to be very accurate and very slow, the other is going to be much faster, and playably accurate. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
DataPath Lurker Joined: 28 Jul 2004 Posts: 144	Posted: Thu Feb 23, 2006 4:52 am Post subject: And being able to swap one CPU core out for another, keeping the APU and PPU units the same should make it possible to debugging and tweaking an opcode-based emulator pretty effective
Starman Ghost Veteran Joined: 28 Jul 2004 Posts: 991	Posted: Thu Feb 23, 2006 4:59 am Post subject: Would it be stupid to code Clockcycle based emulator in basic?
byuu bsnes Developer 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	Posted: Sat Mar 11, 2006 4:49 pm Post subject: Deathlike2 wrote: I have seen two Game Genies.. and boy... it is kinda funky. I remember seeing the Game Genie for the NES and SNES. I had a Game Genie for the original Gameboy. That was one heavy combination. You can see what it looks like: http://en.wikipedia.org/wiki/Image:Game_Genies.jpg _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
DMV27 Rookie Joined: 27 Jan 2005 Posts: 32	Posted: Mon Mar 13, 2006 10:42 am Post subject: byuu wrote: I don't see the Sprite+Y priority code. This fix I really don't follow, other than that I see now that anomie's document was assuming OAMaddr was a word index and not a byte index. What's up with y-1 when oamaddr&3=3? I thought sprite+y was when oamaddr&0xf=0xa? And firstsprite is reset on each scanline? anomie's doc says it's done once per frame... guess not :/ The y-1 is used instead of just y because sprite RTO is calculated one scanline before it is rendered. For example, bsnes will render sprites on line 1 that were setup on line 0 (bsnes will actually setup the sprites on line 1, so the y-1 is basically a hack). The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'. "oamaddr&3==3" is used because regs.txt says "e.g. so the next byte written would go to the last byte in the 4-byte sprite record". Firstsprite must be reset on each line, otherwise sprite+y priority wouldn't do anything (y would always be zero). Also, Uniracers 2-player mode updates oam mid-frame. Quote: So it does, so it does... when an enemy hits you there was some minor crackling sounds, now it's crystal clear. Awesome. No other intensive APU game is affected, as far as I can tell. Chrono Trigger, Tales of Phantasia, Star Ocean, Final Fantasy VI and Dai Kaijuu Monogatari all sound find. Might I ask where you got your bugfix information from? Just want to make sure it's definitely sound (hehe) before I remove the old code entirely (it's commented out for now). I can't test anything on a real SNES, but I got the info from sfsound.txt. In the ENDX section it says "When BRR decode of the block having the Source end flag is completed, the DSP section sets up a "1" 00-7 correspond to Voice0-7." This means that ENDX is only set when the BRR decoding for an end block is finished. For non-looping end blocks decoding stops immediately, so ENDX gets set as soon as the block header is read. For looping end blocks decoding does not stop until the block is fully decoded, so ENDX must wait until the end of the block before it gets set. I should have more patches for you soon. I have been going through the 65816 code and have found quite a few minor timing and open bus bugs. I also noticed that you do not handle stack overflow properly for 65816-only opcodes (see anomie's ob-wrap.txt). I can fix that too if you want, although it will require many changes to the cpu code.
byuu bsnes Developer Joined: 12 Oct 2004 Posts: 2414	Posted: Mon Mar 13, 2006 1:13 pm Post subject: Quote: The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'. Ah, I see. Also, I don't think Uniracers would quie work yet, doesn't that actually expect the OAM address to be updated by the PPU while the line is rendering? I recall we don't know how that address updating works. Quote: I should have more patches for you soon. I have been going through the 65816 code and have found quite a few minor timing and open bus bugs. I also noticed that you do not handle stack overflow properly for 65816-only opcodes (see anomie's ob-wrap.txt). I can fix that too if you want, although it will require many changes to the cpu code. Sounds awesome, thanks! If you want to just explain what's wrong with my stack overflow I can try and correct it, or if you prefer to patch it instead that's fine too.
creaothceann Seen it all Joined: 03 Jan 2005 Posts: 2324 Location: Germany	Posted: Mon Mar 13, 2006 2:44 pm Post subject: DMV27 wrote: Also, Uniracers 2-player mode updates oam mid-frame. Almost all split-screen games should do that (e.g. Contra 3) ... _________________ savestate editor: vSNES latest public version FitzRoy wrote: Seriously, people need to stop arguing with me on this.
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Wed Mar 15, 2006 12:09 am Post subject: The new update looks great byuu! I can't wait to try out the next release. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
FitzRoy Zealot Joined: 04 Aug 2004 Posts: 1078	Posted: Wed Mar 15, 2006 1:33 pm Post subject: Indeed, and DMV27 = bughunter extraordinaire. Eternal thanks. Keep up the great progress, everyone.
Sith Trooper Joined: 19 Jul 2005 Posts: 358 Location: Belgium	Posted: Wed Mar 15, 2006 3:43 pm Post subject: I've just read the 'Bsnes news' update. This is only getting more awsome. 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	Posted: Thu Mar 16, 2006 2:23 pm Post subject: Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
kieran_ Mugwump Joined: 30 Jul 2004 Posts: 2966	Posted: Thu Mar 16, 2006 2:31 pm Post subject: Clements wrote: Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. Why? I know nothing of these things, other than anythng less than 85Hz kills my eyes.
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Thu Mar 16, 2006 2:49 pm Post subject: @byuu: On the video settings page, where you have "Select video mode to configure: Mode 0", this is the 10 customizable resolution modes? This seems *kinda* like a misnomer, since there is also the SNES-internal Modes 0-7. Maybe you can think of a different word to use? I know it confused me at first glance. herzog wrote: Clements wrote: Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. Why? I know nothing of these things, other than anythng less than 85Hz kills my eyes. Because LCDs don't flicker, no matter what the refresh rate. The screen still updates at only 60Hz, whereas a CRT would update at 120Hz if you had the resolution set to that. But LCDs don't flicker even if the refresh rate was 1Hz. You would just have mouse trails. 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	Posted: Fri Mar 17, 2006 3:52 pm Post subject: AWESOME! _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Fri Mar 17, 2006 3:54 pm Post subject: I am definitely in favor of a transparent options windows. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
Dmog Trooper Joined: 31 Aug 2004 Posts: 417	Posted: Fri Mar 17, 2006 6:07 pm Post subject: Awesome indeed. So much control over the display settings...Custom resolution...'per Snes display mode configuration' (KegaFusion has something similar actually) plenty of filters,Blargg's amazing NTSC filter.. And the transparent windows effect is great imo.
Jipcy Inmate Joined: 03 Feb 2005 Posts: 1368 Location: Shenandoah Valley	Posted: Fri Mar 17, 2006 6:32 pm Post subject: Dmog wrote: 'per Snes display mode configuration' What? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
Dmog Trooper Joined: 31 Aug 2004 Posts: 417	Posted: Fri Mar 17, 2006 6:46 pm Post subject: Jipcy wrote: Dmog wrote: 'per Snes display mode configuration' What? ...The Snes has many display modes. And it looks like you can configure them individually in bsnes. In the display settings it says: Select video mode to configure. Unless I misunderstood something that means for example that you could apply a filter to say mode 7 and not mode 1.
adventure_of_link Locksmith of Hyrule Joined: 08 Aug 2004 Posts: 4533 Location: 255.255.255.255	Posted: Fri Mar 17, 2006 6:49 pm Post subject: Hey Byuu, that's pretty cool. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
creaothceann Seen it all Joined: 03 Jan 2005 Posts: 2324 Location: Germany	Posted: Fri Mar 17, 2006 7:32 pm Post subject: Dmog wrote: ...The Snes has many display modes. And it looks like you can configure them individually in bsnes. In the display settings it says: Select video mode to configure. Read again: byuu wrote: The ten video modes can be cycled via ctrl+[1-0] or Menu->Settings->Video Mode->[1-0] SNES has only 8 modes. _________________ savestate editor: vSNES latest public version FitzRoy wrote: Seriously, people need to stop arguing with me on this.
MajereDB8 Rookie Joined: 08 Oct 2005 Posts: 18	Posted: Fri Mar 17, 2006 10:40 pm Post subject: byuu wrote: I also added in all the back-end code, so this is now completely functional. If anyone has a better name for the video mode thing at the top (so that it's less confusing), let me know. I'd suggest the label "Video Preset," with each combobox items called "Preset n." If possible, it might also be a good idea to add a tool tip when you put the mouse over the label stating that bsnes allows users to store up to 10 video configurations that can be cycled during use. This would likely cut down on questions from people who don't RTFM. It's a bit wonky I admit, but most people have probably used a media player that uses the "preset" nomenclature. Back to minding my own business now...
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	Posted: Mon Mar 20, 2006 6:31 am Post subject: You're going to have to start writing documentation for your emulator now that you have all these complicated options. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Mon Apr 03, 2006 10:18 pm Post subject: Where is the RC1 release available, even if I can't run it? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
KingHanco Lurker Joined: 26 Feb 2006 Posts: 152	Posted: Mon Apr 03, 2006 11:05 pm Post subject: Here you go. They have it upload here at - http://www.emu-france.com/?page=fichiers&idFile=3126 - The download works. _________________ "Zsnes is the best one there is."
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	Posted: Sun Apr 16, 2006 2:50 pm Post subject: http://www.gba-video.com/
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	Posted: Mon Apr 17, 2006 7:14 pm Post subject: byuu wrote: In fact, Nach says hardware exists that can play CD audio on the SNES, but I've never heard of it nor seen it. I once had better info on the subject, right now here's what I got: Emit advertising special "remote control" Back of box with CD mentioned and an interesting device shown. Finally for Emit, some info I found a side which mentions it syncs CD audio in time with the game: http://www.insertcredit.com/wiki/doku.php?id=emit I just wish I still had those other pics... It showed another game with an SNES cart, a CD, and an interesting device hooked up to an SFC. Edit: grinvader dug up some more info: http://www.famicom.biz/all/htmls/4988615006203.html http://www.proc.org.tohoku.ac.jp/~hoshi/voicer/ Edit: Another page: http://www.segagagadomain.com/saturn8/emit-vol1.htm _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding
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	Posted: Wed Apr 19, 2006 10:01 am Post subject: My bad. I read your code incorrectly http://users.tpg.com.au/advlink/temp/keybtest.rar I posted this on CR for reverse engineering the X-Band keyboard but you might also find it useful.
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	Posted: Thu Apr 20, 2006 5:20 am Post subject: Took me a little while to work out how to set up the Fullscreen modes, but once I figured that out, it works great. I'm using the D3D9 renderer here. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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	Posted: Fri Apr 21, 2006 3:57 pm Post subject: This is weird...... _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Fri Apr 21, 2006 11:05 pm Post subject: Still a little late for April Fools day. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Sat Apr 22, 2006 8:03 pm Post subject: MajereDB8 wrote: Is there any way bsnes can butter my toast? Please die. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Mon Apr 24, 2006 3:35 am Post subject: DMV27 wrote: D3DX9 problems: http://www.toymaker.info/Games/html/d3dx_dlls.html You can also get it from Microsoft here. _________________ 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 Apr 24, 2006 4:59 am Post subject: Jipcy wrote: DMV27 wrote: D3DX9 problems: http://www.toymaker.info/Games/html/d3dx_dlls.html You can also get it from Microsoft here. Unfortunally I've done all that, and I still can't use D3DX9 for this... _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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: DMV27 wrote: D3DX9 problems: http://www.toymaker.info/Games/html/d3dx_dlls.html 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	Posted: Mon Apr 24, 2006 2:07 pm Post subject: djohnson wrote: Does it work in Win98 yet ???? Get with the times. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Tue Apr 25, 2006 10:43 pm Post subject: Deathlike2 wrote: Did any of my earlier input reach deaf's ears or something? What specific input is that? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
Deathlike2 ZSNES Developer Joined: 28 Dec 2004 Posts: 5599	Posted: Tue Apr 25, 2006 11:13 pm Post subject: Jipcy wrote: Deathlike2 wrote: Did any of my earlier input reach deaf's ears or something? What specific input is that? http://board.zsnes.com/phpBB2/viewtopic.php?p=109068&highlight=#109068 _________________ FF4 research never ends for me.
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	Posted: Wed Apr 26, 2006 9:47 pm Post subject: I'm not really surprised. Never download the bi-monthly DX9 refreshes unless you have to. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Mon May 01, 2006 12:54 pm Post subject: Triple buffering is bugged right now, as noted right next to the checkbox for it. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Tue May 02, 2006 5:07 am Post subject: Whatever the reasons for omitting subtitles, I think it is more important to give each ROM a sufficiently unique name, which in some cases is obviously impossible without subtitles. But let's not get off-topic here. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Tue May 02, 2006 9:17 am Post subject: Wow! Thanks byuu! I can't wait for the next release, as always. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Thu May 04, 2006 9:26 am Post subject: Can any x86 assembler programmers take a look at my post here? http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=73286&page=0&view=expanded&sb=5&o=&fpart=1&vc=1 If I get help with this, I can potentially greatly increase the code readibility, speed, and accuracy of bsnes.
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	Posted: Thu May 11, 2006 9:05 am Post subject: blackmyst wrote: speedup or slowdown I don't think those are dependent on save sates. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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 : Code: call cpu_run 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: Quote: Athlon 64 3200 X2 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	Posted: Fri May 26, 2006 12:15 am Post subject: http://cvs.winehq.org/cvsweb/wine/dlls/kernel/fiber.c?rev=1.7&content-type=text/x-cvsweb-markup Heh. In pure c++, too. Confusing code. 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.
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	Posted: Tue Jun 06, 2006 4:16 am Post subject: byuu wrote: Ok, 2 hours and 300mL of 80 proof vodka later ... I like the way you work. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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: kick wrote: Wild Arms? 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: kick wrote: Wild Arms? 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. Quote: I normally keep a copy at http://users.tpg.com.au/advlink/temp/pcb.pdf 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	Posted: Fri Aug 04, 2006 4:06 pm Post subject: Works for me, out of box. I just unzipped and ran the EXE. I haven't loaded a game yet or done any speed tests yet. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Fri Aug 04, 2006 10:52 pm Post subject: for whoever doesn't have .net 2.0 installed: http://rapidshare.de/files/28215411/Microsoft.VC80.CRT.rar.html just extract the whole folder in there into where bsnes is, it should work. you're very welcome. whatever. _________________ abusing your punk ass since 2006
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: OutrightOwnage wrote: for whoever doesn't have .net 2.0 installed: http://rapidshare.de/files/28215411/Microsoft.VC80.CRT.rar.html just extract the whole folder in there into where bsnes is, it should work. you're very welcome. whatever. 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: OutrightOwnage wrote: for whoever doesn't have .net 2.0 installed: http://rapidshare.de/files/28215411/Microsoft.VC80.CRT.rar.html just extract the whole folder in there into where bsnes is, it should work. you're very welcome. whatever. 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: Quote: Done. 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	Posted: Thu Aug 17, 2006 6:49 pm Post subject: byuu wrote: Only problem is it requires msvcr80.dll, and I have no idea how common that file is. Microsoft Visual C++ 2005 Redistributable Package (x86) http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE Microsoft Visual C++ 2005 Redistributable Package (x64) http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B There's also this but I think it's kinda old... Visual C++ 2005 Runtime Libraries Package Beta 2 http://www.microsoft.com/downloads/details.aspx?familyid=25ae0cd6-783b-4968-a841-38a2743307d9
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	Posted: Sun Aug 20, 2006 6:02 am Post subject: Linux/FreeBSD users will like this :D http://byuu.cinnamonpirate.com/images/desktop082006.png
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	Posted: Wed Aug 23, 2006 12:14 am Post subject: Maybe looking at the fix zsknight did can help Check out Revision 1.39. http://zsnes.cvs.sourceforge.net/zsnes/zsnes/src/vcache.asm?sortby=log&view=log
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	Posted: Wed Aug 23, 2006 2:50 pm Post subject: Zsknight fixed more than that. This is the correct fix: https://zsnes.bountysource.com/svn/!revision/419
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	Posted: Thu Sep 07, 2006 5:04 am Post subject: T-Doomdays: http://board.zsnes.com/phpBB2/viewtopic.php?p=125859&highlight=mouse#125859 _________________ FF4 research never ends for me.
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	Posted: Tue Sep 12, 2006 7:59 am Post subject: All "G" (J) games tested. Problems found: 1 possible issue. Ganso Pachinko Ou (J) - Appears to show an error message. ZSNES as well. Super Sleuth plays the game okay. Special cart? NSRT lies? "Get in the Hole (J)" also has an error message, but I found out why. Here's why http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%203.jpg http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%202.jpg Didn't even know that thing existed.
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: FitzRoy wrote: "Get in the Hole (J)" also has an error message, but I found out why. Here's why http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%203.jpg http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%202.jpg Didn't even know that thing existed. 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: FitzRoy wrote: "Get in the Hole (J)" also has an error message, but I found out why. Here's why http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%203.jpg http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%202.jpg Didn't even know that thing existed. 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	Posted: Tue Sep 12, 2006 7:38 pm Post subject: byuu wrote: 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. is this it? http://cgi.ebay.com/SFC-SNES-PACHINKO-SLOT-CONTROLLER-RARE-NEW_W0QQitemZ8275056164QQihZ020QQcategoryZ3592QQssPageNameZWDVWQQrdZ1QQcmdZViewItem not to good of a pic though. BTW thanks for the great emulator!!
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: ２コントローラのコネクタには、 対応パチンココントローラ以外、接続しないで下さい。 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: Quote: is this it? http://cgi.ebay.com/SFC-SNES-PACHINKO-SLOT-CONTROLLER-RARE-NEW_W0QQitemZ8275056164QQihZ020QQcategoryZ3592QQssPageNameZWDVWQQrdZ1QQcmdZViewItem 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: Quote: is this it? SFC SNES PACHINKO SLOT CONTROLLER RARE NEW 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: byuu wrote: 128. 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	Posted: Mon Sep 25, 2006 6:48 am Post subject: If anyone is interested: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=8286480888 _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Mon Sep 25, 2006 7:36 am Post subject: There are some cheaper ones available: http://search.ebay.com/search/search.dll?satitle=satellaview _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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? Quote: Yes. 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: Quote: There is some new discussion about this at nesdev http://nesdev.parodius.com/bbs/viewtopic.php?t=2174 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: Quote: There is some new discussion about this at nesdev http://nesdev.parodius.com/bbs/viewtopic.php?t=2174 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: EMu-LoRd wrote: 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 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	Posted: Mon Oct 23, 2006 3:58 pm Post subject: Here you go, in full glory: http://www.xs4all.nl/~vdnoort/misc/snes_controller.jpg _________________ "Change is inevitable; progress is optional"
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: EMu-LoRd wrote: Here you go, in full glory: http://www.xs4all.nl/~vdnoort/misc/snes_controller.jpg 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	Posted: Thu Nov 02, 2006 9:39 pm Post subject: I'd be interested in seeing what you can do with a raster-based UI. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Thu Nov 02, 2006 11:28 pm Post subject: byuu wrote: sPPU is going to be really, really really really hard to make. In brief, why? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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! Quote: In brief, why? 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	Posted: Fri Nov 03, 2006 2:00 am Post subject: byuu, why is a dot-based PPU any harder than a scanline PPU? Or, conversely, why are scanline PPUs comparatively easy to create? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Sat Nov 11, 2006 8:40 am Post subject: The J version of RPM Racing shows the same behaviour. I have used the audio log of bsnes and have uploaded a short sample (72 kb packed). Can anyone check this please? http://www.file-upload.net/download_11.11.06_u3s87.rar.html
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: Code: bool is_solid(); _________________ 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	Posted: Tue Dec 26, 2006 5:07 pm Post subject: Reverse Hyperthreading does not exist - it was a rumour initially spread by The Inquirer that they later debunked: http://www.theinquirer.net/default.aspx?article=32885 _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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	Posted: Sun Dec 31, 2006 9:49 pm Post subject: Found some interesting info: http://news.com.com/A+peek+at+faster+Power6%2C+Cell+chips/2100-1006_3-6146309.html?tag=nefd.lede A bit old,but still an interesting read.
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	Posted: Wed Jan 17, 2007 5:50 pm Post subject: Quote: Audio Opened. Driver: OSS audio driver output Channels: 2 Rate: 32000 _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
tetsuo55 Regular Joined: 04 Mar 2006 Posts: 301	Posted: Thu Jan 18, 2007 12:53 pm Post subject: Cool! sound in linux. Byuu i dont know if you knew this already http://www.slack.net/~ant/libs/ntsc.html#nes_ntsc blargg relased a new version of his ntsc filter
Deathlike2 ZSNES Developer Joined: 28 Dec 2004 Posts: 5599	Posted: Thu Jan 18, 2007 3:23 pm Post subject: tetsuo, obviously you hadn't been following this thread: http://board.zsnes.com/phpBB2/viewtopic.php?t=6433 _________________ FF4 research never ends for me.
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	Posted: Sun Jan 21, 2007 7:27 pm Post subject: The NeHe tutorials are at: http://nehe.gamedev.net/
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	Posted: Tue Feb 20, 2007 8:25 am Post subject: I think this mode may satisfy your concern: byuu wrote: "scale, but only by even multiples, as much as possible" _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Fri Mar 09, 2007 2:17 am Post subject: I think this thread needs this.
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: byuu wrote: This is what has been keeping me busy lately: http://byuu.cinnamonpirate.com/articles/freebsd.txt 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	Posted: Sun Apr 01, 2007 3:55 pm Post subject: That's a vey small filesize. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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: fsf.org gpl faq wrote: If a program combines public-domain code with GPL-covered code, can I take the public-domain part and use it as public domain code? You can do that, if you can figure out which part is the public domain part and separate it from the rest. If code was put in the public domain by its developer, it is in the public domain no matter where it has been. 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. Nach wrote: `xvinfo` 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	Posted: Sun Jun 03, 2007 4:48 am Post subject: bsnes v0.020 has been released. You can view the release notes + changelog here: http://byuu.cinnamonpirate.com/?page=bsnes_news And download the new version here: http://byuu.cinnamonpirate.com/?page=bsnes --- FitzRoy, incredible ... you actually managed to update the topic title before I could even finish posting the new version online o.O Many kudos, and thanks for the quick response :)
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	Posted: Thu Jun 07, 2007 8:34 pm Post subject: Every track during the game seems to have at least one instrument/channel missing. Even the Capcom logo. Here's a comparison wav: http://upload2.net/page/download/3Bj637HFi9cvBmr/kod20vs19.rar.html
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	Posted: Fri Jun 08, 2007 11:14 am Post subject: i found the difference between our tv's see more here http://en.wikipedia.org/wiki/Image:Shadow_mask_vs_aperture_grille.jpg
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	Posted: Sun Jun 10, 2007 10:29 am Post subject: Thank you for the help. However, this is the function I was looking for: http://www.xfree86.org/current/XGetKeyboardControl.3.html Specifically, XQueryKeymap.
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	Posted: Fri Jun 29, 2007 12:34 pm Post subject: In other news: It seems that nestopia is trying to go for the rom+xml in a zip system to solve the pcb problem It looks very promising: http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=30761&page=1&nt=2&fpart=1 i believe this is also a chance to do the same thing for snes What do you guys think?
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	Posted: Sat Jun 30, 2007 4:56 am Post subject: hahaha... Since when did Dennis Miller start posting Edited to add the funniest Dennis Miller parody I have ever seen. http://www.milkandcookies.com/link/59367/detail/
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	Posted: Wed Aug 01, 2007 1:23 pm Post subject: Yeah, I generally agree with FitzRoy and Nightcrawler on this. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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. qwerty` wrote: ... !!! 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	Posted: Mon Aug 06, 2007 3:17 pm Post subject: In the worst case you could still write external utilities to watch the bsnes process memory. (example: http://tasvideos.org/forum/viewtopic.php?t=4466) _________________ 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 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 Quote: -SPC ripping 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: Quote: -SPC ripping 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	Posted: Tue Aug 07, 2007 12:39 am Post subject: Wow. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Tue Aug 07, 2007 10:28 pm Post subject: A half-bell curve is called an S-Shaped Curve. That's not what you want though. It looks like an Exponential distribution: http://en.wikipedia.org/wiki/Exponential_growth _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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	Posted: Thu Aug 09, 2007 8:18 am Post subject: byuu wrote: I've been busy reinventing CSS2 for IE6. Let someone else do most of the work for you: http://dean.edwards.name/ie7/. Also: http://trolltech.com/products/qt/gplexception _________________ #577451
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: Also: http://trolltech.com/products/qt/gplexception 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	Posted: Fri Aug 17, 2007 10:59 pm Post subject: How does it compare to http://www.codeproject.com/cpp/ImpossiblyFastCppDelegate.asp and http://www.codeproject.com/cpp/FastDelegate.asp ?
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	Posted: Thu Aug 30, 2007 10:32 am Post subject: 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. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
DancemasterGlenn Regular Joined: 21 Apr 2007 Posts: 331	Posted: Thu Aug 30, 2007 4:57 pm Post subject: Jipcy wrote: 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. 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	Posted: Thu Sep 20, 2007 8:44 am Post subject: http://i63.photobucket.com/albums/h133/franpa/performance.png this is a image of CPU performance while BSNES runs the introduction stage of MegaMan X1. http://i63.photobucket.com/albums/h133/franpa/performance2.png this is a image of CPU performance while BSNES has no game image loaded. _________________ 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 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	Posted: Thu Sep 27, 2007 6:42 pm Post subject: This reminds me of something. RPS works with more then 3 gestures. In fact, someone has been mad enough to design a 101 gesture variant. Btw, I stumbled on an interesting article: http://www.codeproject.com/cpp/FastDelegate.asp Somebody actually put those member function pointers to good use.
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!" Quote: http://bbs.emu618.com/thread-37641-1-1.html ... 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	Posted: Fri Oct 05, 2007 8:15 pm Post subject: at the snes test the test got an update for bsnes 0.024 3 games (WWF Super WrestleMania, F1 ROC II - Race of Champions, Poi Poi Ninja World) were promoted to http://www.aep-emu.de/Sections-req-viewarticle-artid-115.html
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	Posted: Mon Oct 15, 2007 5:00 am Post subject: Oct. 14 also happens to be the 10th anniversary of the first public release of ZSNES, interestingly enough. http://zsnes-docs.sourceforge.net/html/history.htm#v0150
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. Quote: SNEM... 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: byuu wrote: http://i73.photobucket.com/albums/i221/byuusan/bsx.png Well, that was easy enough. Just need a custom PCB mapper. 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: Panzer88 wrote: http://wakoopa.com/software/bsnes WTF? 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: Panzer88 wrote: http://wakoopa.com/software/bsnes WTF? 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: Panzer88 wrote: http://wakoopa.com/software/bsnes WTF? 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: Nach wrote: Found a bug. Battletoads in Battlemaniacs Level 4 part 2 has the sprite priority wrong. http://img339.imageshack.us/img339/8494/bsnesbtbugua3.png The snake is supposed to be going through the hole, not behind it. 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: Nach wrote: Found a bug. Battletoads in Battlemaniacs Level 4 part 2 has the sprite priority wrong. http://img339.imageshack.us/img339/8494/bsnesbtbugua3.png The snake is supposed to be going through the hole, not behind it. 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	Posted: Thu Oct 18, 2007 9:52 am Post subject: Here's a video on how to beat level 3 I just made: http://rapidshare.com/files/63387311/custom.avi.html _________________ 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: 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: Nach wrote: Here's a video on how to beat level 3 I just made: http://rapidshare.com/files/63387311/custom.avi.html 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	Posted: Fri Nov 02, 2007 1:13 am Post subject: Re: Can you point me! krom wrote: 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... Try this: http://sourceforge.net/project/downloading.php?groupname=mplayer-win32&filename=MinGW-full-gcc-4.2.1.7z _________________ 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 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: Quote: Whoops, my bad. 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. Quote: tommowalker released NeuSneM v0.01. http://www.geocities.com/tommowalker/snem.html Worth supporting, we need all the SNES developer interest we can get. 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	Posted: Sun Dec 16, 2007 3:39 pm Post subject: Uh no, no, no, and no, and another no for good measure. The URL in itself is a script. http://byuu.cinnamonpirate.com/*.* http://byuu.cinnamonpirate.com/*/*.* http://byuu.cinnamonpirate.com/*/*/*.* Will all take one to the same page. http://byuu.cinnamonpirate.com/images/a.a http://byuu.cinnamonpirate.com/images/Nach.txt http://byuu.cinnamonpirate.com/images/ByuuEatsGrasshoppers.avi http://byuu.cinnamonpirate.com/Mushrooms.wav http://byuu.cinnamonpirate.com/NSRT/Download/NSRT34W.ZIP http://byuu.cinnamonpirate.com/Lots/of/free/stuff/list.htm Etc... is all the same thing. Can't even get a 404 unless the last component isn't a file and doesn't exist, or it's a filename, but lacks an extension. _________________ 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 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: Nach wrote: 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. 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	Posted: Wed Jan 02, 2008 5:11 pm Post subject: FitzRoy wrote: What is Xv? http://en.wikipedia.org/wiki/X_video_extension _________________ 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: 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	Posted: Wed Jan 02, 2008 11:43 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 not a picture, but this guy has some interesting information, check out the sidebar for more info http://www.gamersgraveyard.com/repository/ it's not on a learning add on, there is one about the playstation beta, and one about a laser disk player used to show demos of games in stores. also for kicks here is some playstation beta images http://www.engadget.com/2007/06/08/prototype-super-famicom-playstation-console-unearthed/ http://gizmodo.com/gadgets/what-is-this/super-famicomplaystation-prototype-267268.php and a controller http://www.nintendowiifanboy.com/2007/12/28/now-in-an-alternate-universe-youre-playing-with-power/ this one is actually on ebay for an absurd amount of money but it's relatively useless. _________________ 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 Jan 03, 2008 4:42 am; edited 1 time in total
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: Quote: ROM: 48 Mb 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: Quote: ROM: 48 Mb 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	Posted: Sun Jan 13, 2008 5:15 am Post subject: ok http://www.fileden.com/files/2008/1/9/1688344/prophetsguile.srm there it is, and this time it's right. _________________ 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 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	Posted: Sun Jan 20, 2008 11:52 pm Post subject: I started a new thread to discuss the save state implementation: http://board.zsnes.com/phpBB2/viewtopic.php?p=159317
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. Quote: Does GtkSocket not do what you're looking for? http://www.gtk.org/api/2.6/gtk/GtkSocket.html 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	Posted: Fri Feb 01, 2008 5:48 am Post subject: Maybe you should test the analog sticks too, just to see how their output relates to the d-pad's output. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Sun Feb 03, 2008 12:57 am Post subject: Bitches can't find mah Higgs boson _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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: byuu wrote: 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. *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: byuu wrote: 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. 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	Posted: Mon Feb 04, 2008 9:25 pm Post subject: Not to mention huge black PAL border support. You would have to be a real masochist to request that particular feature. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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: Code: if(1) { 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: byuu wrote: 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/ 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: Code: p = lookup[p]; 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	Posted: Wed Feb 13, 2008 3:40 pm Post subject: It looks pretty good. Doesn't noticeably darken the screen like some other attempts I've seen. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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	Posted: Fri Feb 15, 2008 7:42 pm Post subject: the filter looks okay About the fosfors simulation, here are a bunch including screenshots from mame http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=92158&page=0&view=expanded&sb=5&o=&vc=1 this image would closely match my tv if the effect was 3x smaller EDIT: maybe if the edges of the mask where lighter the image would be almost perfect Last edited by tetsuo55 on Fri Feb 15, 2008 8:32 pm; edited 5 times in total
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. Quote: is it Red-Green? 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: blargg wrote: EDIT: Cool, found an image that only the colorblind can see: http://www.collisiondetection.net/mt/archives/2006/06/anticolorblindn.html 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: blargg wrote: EDIT: Cool, found an image that only the colorblind can see: http://www.collisiondetection.net/mt/archives/2006/06/anticolorblindn.html 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: Code: -mdynamic-no-pic 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: byuu wrote: Orthostatic Hypotension 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. byuu wrote: Sleep Paralysis 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	Posted: Sun Feb 17, 2008 4:40 pm Post subject: Quote: That's just a cramp. Most skeletal muscles can get them, submandibulars are no exception. actually its not a cramp, its a form of TMJ http://en.wikipedia.org/wiki/Temporomandibular_joint_disorder
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: Code: -mdynamic-no-pic 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: Code: -mdynamic-no-pic 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: byuu wrote: New WIP. 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: byuu wrote: bsnes with XP/Vista themes: http://img257.imageshack.us/img257/7342/99918115xi4.png 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	Posted: Thu Feb 21, 2008 1:02 am Post subject: Hmm, here's an example of a hybrid between blargg's dual timers and my pin edge detection. I think it's tenable ... http://www.geocities.com/byuu64/timing.cpp.txt
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	Posted: Tue Feb 26, 2008 9:11 pm Post subject: And byuu, in case you missed it: http://vba-m.ngemu.com/personalfiles/shaderexample.zip there's the shader example you asked for.
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	Posted: Thu Feb 28, 2008 5:42 am Post subject: *cough* raster gui *cough* _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/
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	Posted: Fri Feb 29, 2008 11:48 pm Post subject: http://vba-m.ngemu.com/personalfiles/error.txt
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	Posted: Tue Mar 11, 2008 10:38 pm Post subject: Ah, thank you very much. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Wed Mar 12, 2008 1:15 am Post subject: In that case, I feel sorry for those with the entire SNES GoodSet. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Sat Mar 15, 2008 3:16 am Post subject: http://byuu.cinnamonpirate.com/ is dead. Did they delete your page byuu? _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Sat Mar 15, 2008 4:46 pm Post subject: I create a shortcut to that particular folder in the bsnes directory for quickness. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group
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	Posted: Sun Mar 16, 2008 12:56 am Post subject: I feel the buttons should dip in some, like the actual thing. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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: Quote: 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 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	Posted: Mon Mar 17, 2008 9:02 pm Post subject: byuu wrote: Hahaha. Awesome. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Mon Mar 17, 2008 10:37 pm Post subject: byuu wrote: You know, it's even funnier that his other hand is hidden. I thought Terranigma was alright, but I give the nod to IoG. Who else bought IoG when it came out and got the t-shirt? :P http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=310013785303
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: FitzRoy wrote: Who else bought IoG when it came out and got the t-shirt? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=310013785303 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: Snark wrote: NSRT filter _________________ 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: Snark wrote: NSRT filter 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	Posted: Wed Mar 19, 2008 10:59 pm Post subject: Ah, thanks for informing me of that. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Fri Mar 21, 2008 3:15 am Post subject: Interesting. I get a slowdown on the character selection on SMB2 in the Super Mario All-Stars game with 51/52fps. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Fri Mar 21, 2008 7:00 pm Post subject: Did a little tweaking... SMB2 in All-Stars MK1: MK2: All is well again. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Fri Mar 21, 2008 8:08 pm Post subject: Simple. Changed the video filter from HQ2x to Scale2x and defaulted all advanced settings. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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 krom wrote: Long post 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	Posted: Mon Mar 24, 2008 10:26 pm Post subject: creaothceann wrote: 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 _________________ 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: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	Posted: Mon Mar 24, 2008 10:35 pm Post subject: Ah, there you go then. That's kinda confusing though. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Mon Mar 24, 2008 11:03 pm Post subject: Verdauga Greeneyes wrote: King Of Chaos, did you ever try my build? Yes, and almost full frame rate in that area... _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter
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	Posted: Sat Mar 29, 2008 11:06 pm Post subject: Cry cry cry. It's over 400mb because it has a ton of demos with source and binaries in it. The actual SDK of headers and libs is ~20mb. And since you can't search: http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en It works on XP and Vista before you even ask. If you get VS2008 Express installer it would have grabbed all this for you. _________________ Watering ur plants.
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	Posted: Thu Apr 03, 2008 7:41 pm Post subject: This is how all websites should be... http://demotemplates.joomlashack.com/simplicity/ ...check out the buttons in the upper right to toggle fixed/fluid width and crank the font size up and down. I love Joomla templates. I went with their Rubicon template for my warcraft site... http://www.tankadin.com/
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: krick wrote: This is how all websites should be... http://demotemplates.joomlashack.com/simplicity/ ...check out the buttons in the upper right to toggle fixed/fluid width and crank the font size up and down. 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: krick wrote: This is how all websites should be... http://demotemplates.joomlashack.com/simplicity/ ...check out the buttons in the upper right to toggle fixed/fluid width and crank the font size up and down. I love Joomla templates. I went with their Rubicon template for my warcraft site... http://www.tankadin.com/ 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	Posted: Mon Apr 07, 2008 4:18 pm Post subject: http://byuu.youkeepusingthatwordidonotthinkitmeanswhatyouthinkitmeans.com _________________ 皆黙って俺について来い！！ 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 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: On http://byuu.cinnamonpirate.com/bsnes/ , byuu wrote: Known bugs: Macaron Golf (U) - Training mode background flickers 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	Posted: Fri Apr 18, 2008 9:54 am Post subject: i'vw written quite a bit about this subject here, this discusion is important because it relates to all consoles and also a lot of arcade cabinets: http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=142782&page=1&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1203617203
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: tetsuo55 wrote: i'vw written quite a bit about this subject here, this discusion is important because it relates to all consoles and also a lot of arcade cabinets: http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=142782&page=1&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1203617203 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: I.S.T. wrote: Wha? >> 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	Posted: Wed Apr 23, 2008 7:08 am Post subject: franpa wrote: what are co-threads? http://byuu.cinnamonpirate.com/programming/libco/ ("Basic Concept of Multithreading") _________________ 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: 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.