bsnes v0.034 released

[byuu]

The emulator's speed is based on the ROM itself. If you load a PAL game, it plays at 50hz; if you load a NTSC game, it plays at 60hz.

Both NTSC and PAL allow 240 scanlines of video output, but they act differently. The menu options displays the video output as though you were hooked up to that type of TV. With NTSC and overscan on, the top and bottom 8 pixels are cut off, the video output is vertically centered. With PAL and overscan off, the bottom 16 pixels are black. NTSC without overscan, and PAL with overscan (the norm) fill the entire screen with no clipping.

You can switch video output mode in the emulator, and it has no effect on emulation itself, just on what you see on the display.

So, load the same ROM in slot A and B?

Not quite. The Sufami Turbo was a cartridge with two cartridge slots on it. You could plug any game into any slot. Or you could plug in two games. With some games, you could combine two and unlock new things. For your purposes, you just want to specify the base cart ("BIOS"), and one cart ("Slot A").

It was a neat idea, but unfortunately only one game for the system was even mildly worth wasting your time on.

Thanks for making it so far in testing :)

[I.S.T.]

NP, byuu. I'll start on E in a half hour.

Edit: It's S I am fearing. Fucking Super pre-fixed games!

Edit2: Got E done. Will do F(Over 130 games... *Shudder*) tomorrow.

Edit3: Got all the F games taken care of in one block. All work fine.

Will start G in a little bit.

Edit4: Make that later today.

[I.S.T.]

Sorry, got to make a new post.

I was testing the G games, and ran into this: http://i218.photobucket.com/albums/cc17 ... rd01-3.jpg

No input would work. I checked the Compatibility thread, and found nothing referring to it.

Edit: found another one.

http://i218.photobucket.com/albums/cc17 ... creen2.jpg

Edit2: On Gradius 3(both versions), a checkerboard-like pattern is displayed before the Konami logo/animation. I don't think this is normal, as I sure as hell don't recall seeing one when playing it on my snes. Mine is stuck in a closet. Can anyone here verify this?

[tetsuo55]

What games where those exactly, if i remember correctly the first one needs a series of key-presses to get passed that screen, maybe even from the second controller

not 100% sure though

[I.S.T.]

What games where those exactly, if i remember correctly the first one needs a series of key-presses to get passed that screen, maybe even from the second controller

not 100% sure though

if you look at the status bar on the bottom of both pictures, you'll see.

However, because I have no idea how good anyone here's eyesight is, I'll just list the names anyway. >.> Ganso Pachinko Ou and Get In The Hole.

Edit: Tested all G games. Other than the ones already mentioned, all work.

[byuu]

IST, those are both controller warnings. It's wanting special controllers for the second port, not regular controllers and/or Multitaps.

The first wants the Pachinko controller, the latter wants the "Sensor Mat", which I've never even heard of. Get in the Hole ... maybe it's the Lasabirdie game? It'll probably work if you set controller port 2 to "None", but you might still get the warning.

I believe that Gradius 3 thing happens on hardware. Pretty sure this is the game I spent a lot of time fixing input on after rewriting the S-CPU core long ago. I'd think I would've noticed something like that, heheh. I'll let others confirm or deny, I guess.

[beender]

i just verified on hardware that the lines are there on gradius 3

[I.S.T.]

Thanks, both of you.

[odditude]

several of the early konami games have the screen-test grid.

[I.S.T.]

Ah.

[byuu]

For those not on Linux, I thought you might like to see how badly SDL is programmed.



Isn't that nice?

[I.S.T.]

For those not on Linux, I thought you might like to see how badly SDL is programmed.

<quoting large images is bad, mmm'kay?>

Isn't that nice?

...

[Deathlike2]

That's the closest to the idiots who want "texture/sprite" replacements as part of the emu are going to get.

[byuu]

I mean, I do know what the problem is. I assign a 32-bit visual to windows when they are available, so that I can paint the background with cairo, creating a really neat glass effect like this:



My SNES video renderer outputs 32-bit X8R8G8B8 pixel data, and SDL is expecting 32-bit A8R8G8B8. But it's not even alpha blending properly, as that would mean the video output would be completely transparent, showing the background fully.

But since it's SDL, it can't even get that right. It looks like it's faking things by performing clamped color addition, instead. Like a Super Nintendo, ironically.

And I obviously can't just tell SDL I want to feed it 24-bit data in 32-bit format. That would be too easy.

Anyway, I did fix it, using another loop to set the alpha value to 255 for each and every rendered pixel. I'd make the 16-bit lookup tables set D24-31, but I want ruby to be useful for more than bsnes, so the kludge stays. Meh, at least they got the pixel order correct. More than GTK+ can manage.

Yes, that's right. Minor speed hit to one crappy driver in return for useless eye candy. Deal.

That's the closest to the idiots who want "texture/sprite" replacements as part of the emu are going to get

:D

[DancemasterGlenn]

Hey, I have that background too :D

I'm a bit glad the big was present, since as you saw I'd totally forgotten to type "glx" instead of "opengl". A convenient time for me to try it out, for sure.

[diminish]

Excuse me, I'm not very familiar with Linux, what is the desktop environment being used and what theme? It's very simple and pleasant to the eye .

[byuu]

Alright, here's the new driver selection window. No more fucking with system.video.



The reason I require a restart is because I now hide all UI elements and such for unsupported features of drivers. No more "why doesn't point / linear do anything when I'm using DirectDraw" questions. I don't have a way to hude menu items after creation on Windows menus just yet, so I can't do it dynamically. And it's also part of the way the crash handler works.

I show the current driver caps, rather than the selected driver caps, because it's possible that some caps can only be detected after driver initialization. The device drivers also perform some setup on construction, and the cap() functions cannot be static and virtual at the same time. It's also a nice way to remind one what the active driver is in case they change it and go back to the panel.

And yes, there's a "None" driver for each in that list. No, I really don't care that nobody will ever play bsnes without video / sound / input. They stay, they're very useful for determining how much overhead each driver adds, and there's always a chance there's a system that has issues with all drivers, eg OpenSolaris not having audio support right now, or something. The name says "None", if someone is too stupid to understand what that means, TFB. You can't even see the option unless you drop down the combobox, so you can hardly call it clutter.

Also, I can't make the text black for the checkboxes. GTK+ will auto uncheck the boxes when clicked if they're left enabled. Windows, you can at least stop it. And I'm not going to auto re-check / uncheck boxes to what the values should be. Nor do I want idiot users thinking you can add capabilities to your hardware by toggling checkboxes.

Haven't looked on Windows, hopefully they're smart enough to not gray out the text, too.

So, don't ask me to change that stuff. Not going to happen.

You can try and talk me out of the second text line in the note section, if you like.

Next up, the crash handler itself.



If you select a driver, and bsnes crashes on startup, then you can start the emulator again and you get the above window. It's only that window, the main window is not visible. You can change the driver, close the window (which closes the program), and then restart bsnes.

No, I'm not going to resume the program after closing the crash handler window, because the GUI setup depends on the drivers chosen, and the drivers chosen might be the ones crashing things in the first place. I avoid initializing the drivers, and thus all the menu / window setup, to avoid the crashing.

Again, much more work to get around than it's worth. I imagine ~1% of users will ever even see this screen anyway.

Note that this window isn't for my own 'buggy' code crashing, it's for the driver APIs themselves crashing. Xorg is really bad at that. You get a valid adapter, pass it a valid value, and it crashes with a BadMatch. Yes, I know those can be caught. But it shouldn't by default hard crash your app. That's what return codes are for. I'll work on hooking the Xorg crash handler in the future to avoid it, but for now -- this is a nice backup plan.

It's needed because if your driver crashes, then you restart, it'll just keep crashing in a loop, forcing you to edit the config file by hand. That sucks, so this avoids that.

Also, yes I could hide the driver list on the left and resize the window and change the titlebar text ... again, it's too rarely used to screw with all of that. This is beyond good enough. I don't know of any other emulators for any system that do anything like that at all (probably because their driver swaps don't crash the program, hah) so this should be good enough.

---------

Next up, my audio resampling calculations were completely wrong. I can't believe I got it working before at all. It's now:

Resample output rate = Sound card frequency
Scale = (0.5 slowest, 1.0 normal, 2.0 fastest)
Resample input rate = SNES input frequency * scale
Resample ratio = input / output

That means the SNES input rates we were using before were actually backwards. Oops. So now you move the slider left to prevent audio underruns, and right to prevent video duplications. 31960hz seems to be working well for me here.

Speaking of which, I changed the value printed to show as -N to +N, where 0 is 32000hz. So you would see -40, rather than 31960. However, with advanced.enable, it prints both for you.

Next, volume is clamped from 10 - 100 (not going to zero, sorry) with advanced.enable off, and 10 - 200 with it on.

Latency stays from 20ms - 200ms. I get too close to 150ms for comfort on Windows. If people try setting it to 200ms thinking it's a good thing, then they deserve what they get.

PC output frequency loses 22050hz, but keeps the other four.

And of course, SDL video output on Linux with a compositor enabled is fixed. Xv + compositor is not. I can't find a matching adaptor for the 32-bit window. Will work on it, though Xv sucks anyway.

Oh, and it turns out that the nvidia binary driver does allow you to specify whether or not OpenGL syncs to vblank. But if you uncheck "sync to vblank" in nvidia-settings, it ignores the setting. So you can now toggle sync to vblank from the GUI. Neat, feature parity with Windows at last.

Hey, I have that background too :D

Yeah, Interfacelift is a nice site. Not my actual wallpaper though. Didn't want to hear people bitching / poking fun at it :P
Funny timing, 99% of the time my wallpaper is a solid color.

Excuse me, I'm not very familiar with Linux, what is the desktop environment being used and what theme?

Xfce 4 with Gelly theme. It's the closest to Plastik I've found. Like hell I'm using KDE for Plastik, though.

[FirebrandX]

Nice work!

I guess this means instead of 32130 working for me, I'd go the other direction now, right?


BTW, were you able to look into that status bar bug? The one I mentioned where closing bsnes with the menu hidden causes the status bar to be counter-toggled from the menu bar on next startup of bsnes?

[byuu]

Code: Select all

http://byuu.org/temp/bsnes_v034_wip05.zip

OpenGL/Linux now destroys the window and colormap it creates, and it also avoids allocating 16MB of memory when only 4MB are actually needed. Forgot to remove the * sizeof(uint32_t) from the buffer allocation after changing it from malloc to new. I use 4MB because the internal buffer size is 1024x1024@32bpp. I make it larger than needed to support both present and future filter requirements (eg HQ4x would need 1024x960 minimum.)

The X-Video driver will now look for XV_SYNC_TO_VBLANK and add the video synchronize option when it exists. Unfortunately, that doesn't stop the binary nvidia driver from ignoring the setting anyway, but it should be nice for those using the nv driver or somesuch, especially as it lacks OpenGL support.

For whatever reason, I was able to get my latency in DirectSound down to 70ms. Not sure if it's related to these changes or not, but I won't complain. I also needed to set 32150hz / -50 for the input frequency adjustment. Probably just differences between the monitor timings on Windows and Linux.

That said, let's get some averages. With the new WIP, be sure to reset all of your audio and driver settings. It may even default to no driver at all if you were using a custom one before.

From there, please post the video driver, audio driver, latency and SNES input adjustment values that work best for you.

BTW, were you able to look into that status bar bug?

Thanks for pointing that out. The status bar properly restored its state, but the menu bar did not. Rather than save the menubar state (I wanted to avoid that for people who accidentally hide the menubar and then close the app, and don't remember how to re-enable it), I just made it not save the status bar state at all. Apologies to those who hate the status bar, you'll have to turn it off more frequently now. Direct your pitchforks at FirebrandX :P

[I.S.T.]

Got H and I taken care of. Will do J and possible more in the next 24 hours.

[FirebrandX]

That said, let's get some averages. With the new WIP, be sure to reset all of your audio and driver settings. It may even default to no driver at all if you were using a custom one before.

From there, please post the video driver, audio driver, latency and SNES input adjustment values that work best for you.

Video driver: Direct3D
Audio driver: DirectSound
Latency: 80ms (extensively tested as minimum clean sound)
SNES input: -130 (extensively tested as always in sync, -125 gives one jump every 5 minutes)

[diminish]

Video driver: OpenGL
Audio driver: DirectSound
Latency: 200ms
SNES input: -200
This results in slightly hiccup every ~40 seconds, but it's a bit less audible than in v0.034.04. Lower latency means more frequent serious hiccups, higher SNES input means more frequent small hiccups. Comboboxes seem a bit too big:

Checkboxes are grayed out in every case, their text also. With OpenGL and GDI there's no Sync to Video option (when vsync set to 'Off by Default' in Riva Tuner for OpenGL - app toggled, it isn't there - only 'Always On' automatically works in bsnes, but like I said there is no Sync to Video).
Btw, I tested Super Metroid in SNESGT and with my crap Realtek ALC268 it isn't possible to achieve no crackling with vsync and even the highest buffer available, but Super Mario World is ok with 67ms already .

[I.S.T.]

Found some games that seem to require a controller or something. Two different games, with each of them having two revisions.

JRA PAT - Wide Baken Taiyou (Japan) (TJDJ)
JRA PAT - Wide Baken Taiyou (Japan) (TJEJ)

JRA PAT (Japan) (TJAJ)
JRA PAT (Japan) (TJBJ)

I'll continue with my testing and won't delete these.

Edit: Got J taken care of aside from those games and some SA-1 chip games.

[FitzRoy]

Found some games that seem to require a controller or something. Two different games, with each of them having two revisions.

Those are cartridges that use a modem kit. They're not really "games," it was a way to bet on horse races or something. The server it connected to no longer exists, just like x-band and bs-x.

[I.S.T.]

Thank you.