bsnes v0.039 released

Gil_Hamilton · Post by **Gil_Hamilton** » Wed Feb 25, 2009 9:18 am

byuu wrote:I'm not arguing that savestates are in any way a bad thing. I'd love to have them if I could.

gllt wrote:Well, unless I'm nuts, there was a device similar to a gamegenie or whatever that allowed you to kind of "save states" in games on the snes, I think
Some copiers did that. They worked ~30% of the time, and half of those times you got lots of graphical corruption and/or no sound.

There was a dedicated state saver too. GameSaver, from Naki.

http://www.gamersgraveyard.com/reposito ... saver.html

Actually saw them at retail, many moons ago.

They almost certainly worked about as well as the copier state saves.

byuu · Post by **byuu** » Wed Feb 25, 2009 12:32 pm

New WIP. This one's available here:
http://byuu.cinnamonpirate.com/temp/bsn ... ip.tar.bz2
http://byuu.cinnamonpirate.com/temp/qtdlls.zip

Please don't distribute to other news sites.

You will need to extract the Qt run-time DLLs into the same folder as the bsnes executable. And you'll likely need WinRAR or 7-zip to extract the WIP archive.

Please report any issues you can find that weren't present in v039. I'd like for v040's release to be as bug-free as possible.

Changes from wip19:

The new 'current directory' caching mechanism was caching after save RAM load, so it wasn't loading save files correctly on first run. Fixed.

I wasn't setting the internal renderer to match the requested video mode, so PAL mode wasn't showing the extra scanlines. Fixed.

Had to add a 50ms (very conservative) delay when toggling fullscreen mode to give Xorg enough time to complete the request. Before it was trying to query the window size too soon and not fully expanding fullscreen video to fit the screen. Because of this added delay, I made it clear the video output when toggling modes. Can't help the slight line redrawing issue in Qt. Not a bug in my code there.

After reading FitzRoy's comments and thinking more about it myself, I've decided against the 'intelligent' fullscreen auto-menu hide. Sorry. It'll still remember whether you were in fullscreen mode on the last run, but the menubar is always visible by default now. It doesn't change your menu visibility when you toggle fullscreen anymore.

I also added back the aspect adjust settings to the config file. This time I combined them to floating point values. So instead of the old:
video.ntsc_aspect_x = 54
video.ntsc_aspect_y = 47
You now have:
video.ntscAspectRatio = 1.14893617

It's an advanced feature not in the GUI, so I expect you to know how to compensate for the 256x224 vs your native monitor's resolution if you screw with that setting. Maybe someone can make a web script to calculate it ala those Xorg modeline generators or something.

Lastly, I removed the group boxes. Took advantage of every row having three options but one, and added a spacer to get everything aligned. Advanced panel looks a lot better now.

belegdol · Post by **belegdol** » Wed Feb 25, 2009 12:45 pm

I'm not sure if you are aware of that, but please keep in mind that qt-4.5 pre-releases are *not* LGPL yet. I checked that with Fedora Qt maintainers.

h4tred · Post by **h4tred** » Wed Feb 25, 2009 1:08 pm

Just noticed something:

* When resizing the emulator, the emulation thread pauses, regardless of the settings specified which control whether is emulation paused when the main window loses focus. Is this a Qt oddity or a real bug? I know SNESGT manages to work its way around this issue.....

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Wed Feb 25, 2009 1:36 pm

byuu wrote:I also added back the aspect adjust settings to the config file. This time I combined them to floating point values. So instead of the old:
video.ntsc_aspect_x = 54
video.ntsc_aspect_y = 47
You now have:
video.ntscAspectRatio = 1.14893617

I know this is a bit unorthodox and I can't remember if it's been suggested before, but wouldn't it be more intuitive to use the screen aspect ratio here? So the ntsc default becomes 1.31306991, and you can easily change it to 1.33333333 or even 1.6 should you want to without having to think too much about it.

The SNES has several horizontal and vertical resolutions anyway, so it doesn't really make sense to think of it as the 'pixel aspect ratio'.

FitzRoy · Post by **FitzRoy** » Wed Feb 25, 2009 4:59 pm

Would it be appropriate to equate a suspension of emulation with "0%" emulation speed? If so, it would be nice to have this activity state reflected and selectable in the menu.

It might also be better to have hotkeys for each speed selection rather than the up/down ladder. I'd personally set them to 0/1/2/3/4/5.

byuu · Post by **byuu** » Wed Feb 25, 2009 5:48 pm

belegdol wrote:I'm not sure if you are aware of that, but please keep in mind that qt-4.5 pre-releases are *not* LGPL yet. I checked that with Fedora Qt maintainers.

Oh? That's annoying. I'll remove it when I get home with FTP access, then. If someone wants to test the WIP, they should probably get it now.

belegdol, since you're our resident license guru, could you tell me if I'd be allowed to statically link with Qt 4.5? I distribute the source code, so that obviously allows creation of object files and re-linking with modified versions of Qt and such.

h4tred wrote:Just noticed something:

* When resizing the emulator, the emulation thread pauses, regardless of the settings specified which control whether is emulation paused when the main window loses focus. Is this a Qt oddity or a real bug? I know SNESGT manages to work its way around this issue.....

Windows itself blocks the window thread whenever you enter a menubar or resize the window. Linux doesn't have these glaring design flaws and works as expected.

SNESGT uses two threads, one to run the emulator and one to run the user interface.

The most important thing to me in the Qt rewrite was allowing one to enter the menubar without freezing the emulator, as that's something I expect people to do a lot. Qt manages that by drawing its own menubar control.

Resizing the window is kind of pointless in bsnes anyway, as I don't allow arbitrary scaling of the video content. All it does is add black borders to the sides. So I'm not worried about it enough to screw with cross-platform multi-threading and all the issues that causes.

I know this is a bit unorthodox and I can't remember if it's been suggested before, but wouldn't it be more intuitive to use the screen aspect ratio here?

It's an X:Y ratio. I can't accept eg 1.333 or 1.6, because that would require me to know the X:Y pixel ratio of the monitor in question. For 1280x1024 on CRTs, that is ~1.2:1. For the same on LCDs, it's usually 1:1.

It should be a simple calculation to get 16:10 anyway, for people who want their sprites to look obese.

The SNES has several horizontal and vertical resolutions anyway, so it doesn't really make sense to think of it as the 'pixel aspect ratio'.

This affects the output size only, which is always N*(256*224) for NTSC, and N*(256*239) for PAL.

It might also be better to have hotkeys for each speed selection rather than the up/down ladder. I'd personally set them to 0/1/2/3/4/5.

I agree the ladder is annoying. If I had support for modifier keys, that'd be awesome to do Shift+1-5. Since I don't, I didn't want to tie up five keys for that. Especially the ones most emulators use to toggle BG layers (a hangover from the days when SNES layer priorities weren't well understood.)

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Wed Feb 25, 2009 6:32 pm

byuu wrote:It's an X:Y ratio. I can't accept eg 1.333 or 1.6, because that would require me to know the X:Y pixel ratio of the monitor in question. For 1280x1024 on CRTs, that is ~1.2:1. For the same on LCDs, it's usually 1:1.

It should be a simple calculation to get 16:10 anyway, for people who want their sprites to look obese.

Surely 1280x1024 on CRTs is the only widespread (and dwindling) example of this? Even then, with the current situation people with that pixel ratio -already- have to change the setting by multiplying the default aspect ratio by 1.06666667 (1024/960). And that's just the simplest adjustment - for 4:3 they currently have to do (1024/960) * (4/3) / (8/7) (NTSC)... and that's assuming they can figure it out at all. The bottom line is: they're already screwed because of their non-square pixels, and I don't see how they'd be worse off if bsnes had an 'output aspect ratio' setting that assumes square pixels.

FitzRoy · Post by **FitzRoy** » Wed Feb 25, 2009 7:05 pm

byuu wrote:I agree the ladder is annoying. If I had support for modifier keys, that'd be awesome to do Shift+1-5. Since I don't, I didn't want to tie up five keys for that. Especially the ones most emulators use to toggle BG layers (a hangover from the days when SNES layer priorities weren't well understood.)

Okay, but what about the initial question? Why is suspension out of the loop instead of in Emulation Speed as 0%? It would make more sense if it was in there inheriting the check.

I also agree with Verdauga, anyone with a 4:3 frame CRT screen should be running at 1280x960 over 1280x1024. Unless there's an OS or OS app somewhere out there that was designed for rectangular pixels, 5:4 on a 4:3 frame is pure error, a historical blip with no modern relevance.

belegdol · Post by **belegdol** » Wed Feb 25, 2009 8:06 pm

byuu wrote:
belegdol wrote:I'm not sure if you are aware of that, but please keep in mind that qt-4.5 pre-releases are *not* LGPL yet. I checked that with Fedora Qt maintainers.
Oh? That's annoying. I'll remove it when I get home with FTP access, then. If someone wants to test the WIP, they should probably get it now.

Actually it seems that the code is lgpl since yesterday, but there will be no more snapshots until the final release:
http://labs.trolltech.com/blogs/2009/02 ... of-an-era/

h4tred · Post by **h4tred** » Thu Feb 26, 2009 12:04 pm

SNESGT uses two threads, one to run the emulator and one to run the user interface.

Thanks byuu for the relevant info. Just found it odd that the menus where fine but the window resizing wasn't

.

FitzRoy · Post by **FitzRoy** » Fri Feb 27, 2009 7:02 pm

Nitpick alert: some NP games were NP exclusive (EEPROM) and did not have ROM counterparts. Off the top of my head: Picross series, one of the Ogre Battle versions, one of the Fire Emblem versions. Maybe you weren't aware of this, but that's why I listed both sources under the SFC filetype.

byuu · Post by **byuu** » Fri Feb 27, 2009 7:26 pm

and that's assuming they can figure it out at all

I still don't want to make assumptions about the source system, even if 5:4 resolutions are rare. Few have even asked for this feature. We should just post constants for 4:3, 5:4, 16:9 and 16:10 that will effectively fill the entire monitor. Problem solved.

Okay, but what about the initial question? Why is suspension out of the loop instead of in Emulation Speed as 0%? It would make more sense if it was in there inheriting the check.

I see where you're coming from, but I like having it separate. Like how we have mute and audio volume separate. Sure we can merge these things, but they're functions intended for different purposes:

Mute - you want to listen to something else, or nothing
Volume slider - it's a bit too loud, but you still want to listen (technically I'd like volume to go above 100% as the SNES has anemic volume levels, but yeah)
Speed down / up - you're trying to make the game easier or more challenging, or using it to speed through boring parts
Pause - you're saying you won't be using the emulator for a bit, maybe to multi-task or hibernate the PC

Fast access to mute and pause are nice for me. If I could bind the pause key reliably on Linux, it'd make perfect sense to use that as the default key for it.

Nitpick alert: some NP games were NP exclusive (EEPROM) and did not have ROM counterparts.

True, I was just trying to keep the section terse. The EEPROM in this case might as well be ROM, since the emulator will never write to it like you can with the BS-X flash carts (even though I don't yet support that.)

In actuality, there's probably a command sequence to program NP carts, too. But I don't know of any reason to emulate something like that.

And I know using terms like EEPROM at all are just flat-out confusing to novices. Have to draw the line somewhere I guess.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Fri Feb 27, 2009 7:41 pm

byuu wrote:even if 5:4 resolutions are rare

Apparently most LCDs with 5:4 resolutions still have square pixels, so it's really only some rare CRT users you're catering to here. And I think most people still using CRTs are either people who are computer savvy (i.e. build their own PCs and haven't upgraded, or really really hate lag), or don't have computers new enough to run bsnes. I guess it's your choice in the end though, and with the aspect ratio setting only in the config file I guess non-tech savvy people won't find it anyway.

FitzRoy · Post by **FitzRoy** » Sat Feb 28, 2009 1:45 am

byuu wrote:I see where you're coming from, but I like having it separate. Like how we have mute and audio volume separate. Sure we can merge these things, but they're functions intended for different purposes:

That's why I suggested giving each speed its own hotkey, and notice where 0 is relative to 12345, and fullscreen. It's nowhere near them but it's just as fast as F12. -/+ get used for frameskip on every emulator, so I didn't understand your argument there anyway.

byuu wrote:And I know using terms like EEPROM at all are just flat-out confusing to novices. Have to draw the line somewhere I guess.

Easily found on wikipedia, more than I can say for stuff like SMC.

Gleasonator · Post by **Gleasonator** » Sat Feb 28, 2009 2:03 am

Novices use ZSNES.

kick · Post by **kick** » Sat Feb 28, 2009 6:03 am

Verdauga Greeneyes wrote:I think most people still using CRTs are either people who really really hate lag or those who don't have computers new enough to run bsnes.

Nope.They don't like the current state of LCD monitors: very short (16:9), low-res,low DPI screens with bad color accuracy.

Good CRT monitors have over 130 dpi = you can get 2048x1536 pixels in a small 18" (visible) screen area.That gives you a really sharp picture without the need to use anti-aliasing.

CRTs are better for browsing the net and CAD work.Very few LCD monitors have a VESA stand that can rotate the monitor 90 degrees to compensate for the "short screen".

Screen scaling is perfect on CRT monitors. LCDs which have high quality scaling are often plagued by terrible processing lag.

CRTs can give you infinite colors (smooth gradients),while most LCD screens use 6-bit color + dithering.
Have you ever compared the yellow tones of a CRT and a high-quality LCD? The LCD colors are dull and lifeless.

adventure_of_link · Post by **adventure_of_link** » Sat Feb 28, 2009 6:46 am

Gleasonator wrote:Novices use ZSNES.

Shut up.

Panzer88 · Post by **Panzer88** » Sat Feb 28, 2009 6:56 am

kick wrote:
Verdauga Greeneyes wrote:I think most people still using CRTs are either people who really really hate lag or those who don't have computers new enough to run bsnes.
Nope.They don't like the current state of LCD monitors: very short (16:9), low-res,low DPI screens with bad color accuracy.

Good CRT monitors have over 130 dpi = you can get 2048x1536 pixels in a small 18" (visible) screen area.That gives you a really sharp picture without the need to use anti-aliasing.

CRTs are better for browsing the net and CAD work.Very few LCD monitors have a VESA stand that can rotate the monitor 90 degrees to compensate for the "short screen".

Screen scaling is perfect on CRT monitors. LCDs which have high quality scaling are often plagued by terrible processing lag.

CRTs can give you infinite colors (smooth gradients),while most LCD screens use 6-bit color + dithering.
Have you ever compared the yellow tones of a CRT and a high-quality LCD? The LCD colors are dull and lifeless.

QFT

I have several LCDs and several CRTs, I keep the CRTs around for the above mentioned reasons, highest resolution and also zero lag, etc.

Mednafen · Post by **Mednafen** » Sat Feb 28, 2009 7:07 am

Are there any dual-DVI 19-20" CRT monitors that can do something like 1280x1024@120 Hz?
Anything less that 120Hz-ish gives flicker for me, or did when I last checked. 100Hz is tolerable, at least.

FirebrandX · Post by **FirebrandX** » Sat Feb 28, 2009 7:12 am

kick wrote:
CRTs are better for browsing the net and CAD work.Very few LCD monitors have a VESA stand that can rotate the monitor 90 degrees to compensate for the "short screen".

I agree with most of your points except this one. WTF do you mean "short screen"? My LCD is just as tall as my CRT, but is wider (16:10). Are you somehow equating a rectangle as being shorter than a square? You can't really claim that out of context of the heights of both screens.

kick · Post by **kick** » Sat Feb 28, 2009 7:39 am

Mednafen wrote:Are there any dual-DVI 19-20" CRT monitors that can do something like 1280x1024@120 Hz?
Anything less that 120Hz-ish gives flicker for me, or did when I last checked. 100Hz is tolerable, at least.

1600x1200 @ 100Hz for the high-end models

On the lower resolutions you can go up to 200Hz

You can find complaints like these all over the net:

Whats with all these 'full HD' low resolution monitors being released today? My 2 year old Dell 24" has a better res than these.

This is a step back not forwards, Even 22" monitor's these days should be 2048X1152 at least.

A good 22" 16:9 LCD monitor should have at least 2133x1200 pixels (that's 1200p),Until affordable screens like these (with LED backlighting) become available,I'm still using my trusty ol' 1536p CRT.

kick · Post by **kick** » Sat Feb 28, 2009 7:52 am

FirebrandX wrote:
kick wrote:
CRTs are better for browsing the net and CAD work.Very few LCD monitors have a VESA stand that can rotate the monitor 90 degrees to compensate for the "short screen".

I agree with most of your points except this one. WTF do you mean "short screen"? My LCD is just as tall as my CRT, but is wider (16:10). Are you somehow equating a rectangle as being shorter than a square? You can't really claim that out of context of the heights of both screens.

By short,I mean a modern 22" 16:9 LCD has LESS vertical screen height than a 19" (18" visible) flat CRT

Gil_Hamilton · Post by **Gil_Hamilton** » Sat Feb 28, 2009 7:56 am

kick wrote:
Verdauga Greeneyes wrote:I think most people still using CRTs are either people who really really hate lag or those who don't have computers new enough to run bsnes.
Nope.They don't like the current state of LCD monitors: very short (16:9), low-res,low DPI screens with bad color accuracy.

Good CRT monitors have over 130 dpi = you can get 2048x1536 pixels in a small 18" (visible) screen area.That gives you a really sharp picture without the need to use anti-aliasing.

...

Screen scaling is perfect on CRT monitors. LCDs which have high quality scaling are often plagued by terrible processing lag.

CRTs can give you infinite colors (smooth gradients),while most LCD screens use 6-bit color + dithering.
Have you ever compared the yellow tones of a CRT and a high-quality LCD? The LCD colors are dull and lifeless.

What he said.

I actually tried setting a CRT up alongside my LCD recently, just for giggles(I don't currently have enough space for the CRT on my desk, but damned if I wasn't gonna try).

The LCD looked "cartoony" once it was next to a DECENT screen.

CRTs are better for browsing the net and CAD work.Very few LCD monitors have a VESA stand that can rotate the monitor 90 degrees to compensate for the "short screen".

Actually, a pivotable LCD is fairly easy to come by.

Though I don't really WANT web pages that long. My LCD is horizontal, and the browser's not maximized horizontally or vertically.

I make no claims to CAD knowledge.

kick · Post by **kick** » Sat Feb 28, 2009 8:29 am

There's one additional (bonus) feature you get by using a CRT monitor - free scanlines at low resolutions

Set the res to 640x480 and play your emulators "the way they're meant to be played"