bsnes v0.039 released

[Verdauga Greeneyes]

Mmmhm byuu, I guess that puts the nail in the coffin for my development ideas. Since people can rant on about how thier software filters are evil, I cannot begin to fathom the absolute outroar if I go ahead and instead rewrite the filter system to operate entirely on the GPU. Sad (considering hardware graphics programming is my specialty Sad )

Least that idea completely avoids licensing issues.

I don't think anyone here dislikes -all- the software filters, it's just the ways to configure them that are being discussed. I still think putting a setting in each filter that says whether they work with non-integer scales is the easiest way to solve this debate, because why would you make the scale smaller than you have to in full screen mode?

[FitzRoy]

It's hard to say what aspects, known and unknown, affected art design. If the artists were displaying things on the target system and display, any aspects could have influenced the design.

I don't share your general uncertainty. I believe that there is plenty of evidence to make logical assertions concerning which CRT nuances were ignored and which weren't. For example, we KNOW the intended proportions of a game like Zelda by selecting an ingame object whose external art is known to have equidistant relationships (such as the the triangles in the triforce), and then seeing whether 4:3 correction or the average you constructed best accomplishes that relationship. The results may have surprised you, but they didn't surprise me.

If the games are tested on such televisions, they may very well be. By this I mean that the game might be showing things that wouldn't look as good on a TV without motion blur, but these don't get noticed because their TVs have motion blur.

I don't see designers holding back from... motion.

But eliminating the spaces between scanlines has more of an effect than simply eliminating the pinstripes. Removing them makes things more blocky, less rounded.

Adding rows of blocks does jack diddly at reducing blockiness on lo-res images blown up in size. You have to do bilinear filtration to haze out the pixel structure, and that's a hardware filter that can't even be avoided on certain APIs, so it's outside of the debate, which is whether scanlines are important enough to prevent a number of usage simplifications from taking place.

Lots of good gameplay elements also got scrapped when 3D came around, so something not being carried over isn't necessarily a good thing.

As evidenced by... Metroid Fusion, Warcraft III, Heroes of Might and Magic IV, Final Fantasy PSP, Castle Crashers, Street Fighter II HD, Prince of Persia HD, Bionic Commando HD, Mega Man 9, Cave Story, Ikaruga? Other than point-and-click adventures falling out of favor, I haven't seen abandonment of many concepts.

I don't think people are arguing that one would intentionally choose low-resolution with scanlines over high-resolution without them. I think they are arguing that the graphics at that time had scanlines, and rendering it without them causes issues.

You've got it reversed. Scanlines create issues, which PC games at the time avoided by having a display technology that was superior to televisions. It is the most out-of-hand myth in all of retro emulation that they perform some kind of magic on the image.

I don't think I ever said much about the artist's intentions, which aren't much relevant when the goal is reproduction of the gaming experience.

Which is why every NES emulator employs random hanging on game loading? Which is why every SNES has an analog filter for audio? Which is why every SNES emulator forces users to load cheats using the actual Game Genie piggyback? Stupid deficiencies that hurt the gaming experience back then are abandoned all the time. Scanlines are distinct, yet innocuous, they never really got questioned as being a part of this group.

If an artist is designing graphics for a PAL game and displaying it on the target system, he is making choices among actual options the system can do, like making an object 10 pixels wide versus 14.

One thing is for sure, your NTSC measurement is too close to 4:3 for any designer to have compensated. PAL might be different, but very few PAL-only games were made. Who cares, though, I don't know why you keep bringing up things we all know affected the artwork, it doesn't help your defense of scanlines one iota.

For PAL and NTSC, I imagine in most cases the game is designed for NTSC, and later ported to PAL with little attention given to the graphical proportion changes that occur.

Sure.

If a game were designed from the start with NTSC and PAL in mind, the artist might choose one set of graphics for both.

More likely they'd go for proper correction in the largest market (NTSC) rather than guaranteeing incorrect proportions on both. There's only one correction that can make an oval a circle.

[Gil_Hamilton]

... it makes areas that are supposed to be contiguous swaths of color ...

I'm just going to ignroe the personal attack and jump on that word "supposed".

It is SUPPOSED to have those dark lines. It was DESIGNED to output to a low-resolution CRT monitor with widely separated scanlines.

Why can't you see the fallacy in your shotgun approach?

If you can make "supposed to" claims, so can I.

Not all CRT characteristics affected the way the art was designed. That's like saying PS3 games today are designed for motion blur just because it exists on today's televisions. In reality, it is an unavoidable deficiency and its successor (OLED) exists in part to overcome it. No game has ever used it to its advantage, it's just a blotch on the era.

Your counter-example is poor, as motion blur does not exist on ALL displays a PS3 will be used on.
You could more easily make the argument for the PSP. And I've seen games that take advantage of it, as well as games that ignore it totally.


There WERE measures that could have been taken to minimize the scanline effect at minimal performance and hardware expense, such as using an interlaced line-doubled image.
They were not done for whatever reason, be it tradition, flicker concerns, or that large solid chunks of color look dull without SOMETHING breaking them up(sure a solid blue sky looks good, but those bricks would look pretty bland, as would that concrete wall).

It's also worth noting that most scanline emulation falls a bit short of real scanlines since there is no phosphor flare to blur the lines.

It's also supposed to be a 4:3 image

According to the same logic you tried to use against me, not it isn't. Actual CRT televions deviated slightly from this and byuu and blargg believe that artists accounted for it based on the fact that that's what the technology did. They also believe that artists intend for the same art to be stretched differently on NTSC and PAL based on what the technology did. This was disproven by

(a) FirebrandX's triforce comparisons.
(b) My logical assertion that the degree of difference would have been too small for artists to recognize over standard at that low of a resolution.
(c) My logical assertion that art, being comprised of shapes with set proportions, cannot possibly be intended for two different corrections.

This was another perfect example of technological "accuracy" coming before the accuracy of intent. Is this some kind of revelation for you that in some regards emulation can achieve greater precision and consistency than what was possible in the past?

Fine... they expected it to be a more or less 4:3 image, within the typical calibration tolerances of the average display(be it an arcade monitor or a home television set).
For an arcade display, that amounts to "fiddle with the knobs until there's no black frame on the screen." In other words, it was adjusted until it overfilled a 4:3 display on all 4 sides.

As far as I know, NTSC/PAL differences don't come into play on arcade cabinets, though they wouldn't be near as visible given the vertical height adjustment would eliminate the squashing problem.


I don't believe ANYONE has asserted that poor PAL conversions were the game as the developers intended.


I KNOW that I never saw a CPS cab displaying a game in widescreen, and any game artist that was assuming square pixels on a system that would (almost) never display them that way wasn't a very good one. It's immediately obvious to anyone that ever saw an arcade cabinet that that is NOT how it was supposed to display.

[blargg]

I don't see designers holding back from... motion.

It is the most out-of-hand myth in all of retro emulation that they perform some kind of magic on the image.

Which is why every NES emulator employs random hanging on game loading? [...] Which is why every SNES emulator forces users to load cheats using the actual Game Genie piggyback?/quote]
Your discussion tactics leave a bad taste. Not worth continuing, sorry.

Gil_Hamilton]

Not all CRT characteristics affected the way the art was designed. That's like saying PS3 games today are designed for motion blur just because it exists on today's televisions. In reality, it is an unavoidable deficiency and its successor (OLED) exists in part to overcome it. No game has ever used it to its advantage, it's just a blotch on the era.

Your counter-example is poor, as motion blur does not exist on ALL displays a PS3 will be used on. You could more easily make the argument for the PSP. And I've seen games that take advantage of it, as well as games that ignore it totally.

Reminds me of how lots of older GB games used flicker to generate transparency, but then looked bad on the CGB and AGB due to their color screens having much less blur. One that comes to mind is Zelda: Link's Awakening.

Fine... they expected it to be a more or less 4:3 image, within the typical calibration tolerances of the average display(be it an arcade monitor or a home television set).

That's the thing; if the artist isn't paying attention to math, rather just looking at the image on the target system, he WILL take into account its deviation from 4:3 or whatever, since it will never come into play. A circle might look too oval, and he'll redraw it until it looks right. That takes into account the actual system hardware. Even if the pixels are twice as wide as high, that will be taken into account by just looking at it on the target system.

[Gil_Hamilton]

Fine... they expected it to be a more or less 4:3 image, within the typical calibration tolerances of the average display(be it an arcade monitor or a home television set).

That's the thing; if the artist isn't paying attention to math, rather just looking at the image on the target system, he WILL take into account its deviation from 4:3 or whatever, since it will never come into play. A circle might look too oval, and he'll redraw it until it looks right. That takes into account the actual system hardware. Even if the pixels are twice as wide as high, that will be taken into account by just looking at it on the target system.

I assume they set whatever software they were drawing with to a pixel ratio that more or less matched the SNES'.

But yeah, I never thought they were working it mathematically. Just that they weren't working with square pixels anywhere in the art development.

[byuu]

New WIP. Adds menubar/statusbar toggle, defaults fullscreen to max scale with no menu/status (you can change the scale and it will remember your settings in the future), and I re-added all the audio panel options.

That leaves a few more GUI shortcut key assignments, mouse support + binding, BS-X / ST ROM loaders, readme/license windows, and a few new controls to replace the old Firefox-style advanced screen with something more user-friendly. After that, the rewrite should be complete.

Trying to move my string lib to a more OO-approach: removed overloaded strcpy,strcat in favor of =,<< or .assign,.append. Will be trying to remove more global functions (replace(foo -> foo.replace(, etc) in the future. Taking it slow so I don't break xkas too badly.

I also want to shave as much excess functionality as I can from it. Its main purpose is to be a streamable, implicit-castable alternative to std::string with a few built-in special functions unique to my needs (eg qsplit,qreplace.)

[FitzRoy]

Couple of issues I've noticed:

-Empty space in fullscreen is gray instead of black.
-Paths boxes aren't modifiable from within, but aren't grayed out anymore.
-Custom window resize makes it very easy to unintentionally resize the window when you're only attempting to move it (by dragging the title bar). It's happened to me twice already. If you could avoid this somehow, and lock the aspect (which is impossible to eyeball), it might be worth keeping.

[blargg]

Since I spent the time writing this response before finding the thread locked, I'm going to post this here. Sorry.

Summary of FitzRoy's excellent points:
- All programs have a particular interface, which influences how useful it is to a given user.
- For each user, there is an optimal interface that serves him best, but serves most users less-well.
- No interface will serve everyone well, but some interfaces will serve more users much better than other interfaces.
- Every user will fight for his optimal interface.
- Without a central designer, the interface will be neither the optimal for any user, nor optimal for most users.
- A central designer can examine users and choose an interface that serves most well.

That "simple" option [in Nestopia of confirming quit] forces the supermajority of users to dig in the configuration and disable it. That inconvenience outweighs the inconvenience of the few who want it to do the opposite. It's a perfect of example of not understanding cost/benefit relationships that are supposed to guide all program designs.

What if Nestopia had a checkbox in the confirmation dialog, labeled "Don't ask again"? I'm thinking that data-loss-prevention options should in general default to the safe settings.

[Thristian]

That "simple" option [in Nestopia of confirming quit] forces the supermajority of users to dig in the configuration and disable it. That inconvenience outweighs the inconvenience of the few who want it to do the opposite. It's a perfect of example of not understanding cost/benefit relationships that are supposed to guide all program designs.

What if Nestopia had a checkbox in the confirmation dialog, labeled "Don't ask again"? I'm thinking that data-loss-prevention options should in general default to the safe settings.

How's this for a third possibility: when the close-box is clicked, open a "Do you really want to quit" dialog unless SRAM has been written to in the past 10 seconds, or a save-state has been saved within the past ten seconds. I imagine most people intentionally quitting an emulator will want to save their game first, in which case there's no data-loss and hence no need for a prompt.

Also, while you're around, Blargg: I notice you brought up QuickNES in that other, now-locked thread. It greatly impressed me, back when I was using OS X (I'm even in the 1.1b3 Readme, credited as 'Screwtape'), but these days I'm on Linux - what chance is there of a Linux port being available someday? I understand that getting a high-performance, attractive GUI under Linux is difficult, but byuu, sinamas, BearOso and AamirM have all been attacking that particular problem for a while now...

[ZH/Franky]

How's this for a third possibility: when the close-box is clicked, open a "Do you really want to quit" dialog unless SRAM has been written to in the past 10 seconds, or a save-state has been saved within the past ten seconds. I imagine most people intentionally quitting an emulator will want to save their game first, in which case there's no data-loss and hence no need for a prompt.

You know, that's actually a brilliant idea. Though I think it should be within the past 30 seconds, not 10.

Or, you know, there could be a 0 second threshold; that is, the emulator ALWAYS makes a savestate when you close the emulator.

I understand that getting a high-performance, attractive GUI under Linux is difficult, but byuu, sinamas, BearOso and AamirM have all been attacking that particular problem for a while now...

Qt?
A large majority of KDE-based apps?

[tetsuo55]

How's this for a third possibility: when the close-box is clicked, open a "Do you really want to quit" dialog unless SRAM has been written to in the past 10 seconds, or a save-state has been saved within the past ten seconds. I imagine most people intentionally quitting an emulator will want to save their game first, in which case there's no data-loss and hence no need for a prompt.

You know, that's actually a brilliant idea. Though I think it should be within the past 30 seconds, not 10.

Or, you know, there could be a 0 second threshold; that is, the emulator ALWAYS makes a savestate when you close the emulator.

I would image that that would either be:

Create a savestate before exiting/Quiting? YES/NO

Or when you reload the game:
A savestate was made for this game at DATE:TIME last time you quit, want to load it?

The whole point is moot because bsnes does not have savestates, but it think its quite nice for emulators that do

[Verdauga Greeneyes]

While we're on the subject, how about an 'undo' button for when you accidentally load a savestate?

[ZH/Franky]

The whole point is moot because bsnes does not have savestates, but it think its quite nice for emulators that do

Well, I was referring to other emulators, and not bsnes.
I understand why bsnes does not (and currently cannot) support savestates, though.

While we're on the subject, how about an 'undo' button for when you accidentally load a savestate?

I suppose the emulator, when pressing/clicking the button to load the state, could always make a save of the current state, before loading the new state (and have a special key to load back).

Dibs on the del key.


... These ideas all seem so simple. I'm surprised most emulator's don't have features like what we've been describing.

[grinvader]

Not really trying to make a point, but...

- save a state on exit without warning (auto state save/load)
- load it on resume without warning (auto state save/load)
- cancel an accidental state load (rewind)

[byuu]

-Empty space in fullscreen is gray instead of black.

This was intentional for now. It's just showing off where the video is for now. I'll most likely make it black for release.

-Paths boxes aren't modifiable from within, but aren't grayed out anymore.

That's a UI toolkit style. Not much I can do. I suppose I can disable the controls if it really matters. Breaks copy/paste, but that's not a huge concern anyway. A label works too for this part, but it looks bad. They tend to imply static text more than user settings.

-Custom window resize makes it very easy to unintentionally resize the window when you're only attempting to move it (by dragging the title bar).

Can't change that Windows gives you a horizontal resize at the top of the window. I also can't disable resize on all platforms. Qt doesn't have the commands to do that for some reason. And that was also a major point of the rewrite ... a constrain-proportion scale would be amazing, I'd love that for the main window too. Just don't know how to pull that off. The resize hints don't seem to work on Qt/Win, but I bet they do on OS X where that effect is more popular.

How's this for a third possibility: when the close-box is clicked, open a "Do you really want to quit" dialog unless SRAM has been written to in the past 10 seconds, or a save-state has been saved within the past ten seconds.

Writing to SRAM doesn't mean the user saved their game. Games can write to SRAM all the time, they can even use it as scratch RAM.

The only shortcut I could think of was to not show the prompt when you close games that lack SRAM entirely, eg Street Fighter Alpha 2. But they still might not want to lose their 80% completion when they go to maximize. It's probably best that if the user wants the nag option, that it always shows up.

I understand that getting a high-performance, attractive GUI under Linux is difficult, but byuu, sinamas, BearOso and AamirM have all been attacking that particular problem for a while now...

Sadly, GNOME/Xfce users are going to see a major hit in UI aesthetic with the Qt rewrite. Even QGtkStyle looks terrible there. But I suppose it won't be any worse than using k3b and Amarok now. And the split between KDE v GNOME et al is roughly 50/50 anyway. KDE users will at least be happier.

[FitzRoy]

What if Nestopia had a checkbox in the confirmation dialog, labeled "Don't ask again"? I'm thinking that data-loss-prevention options should in general default to the safe settings.

That's not a bad idea, but I'm imagining to myself if every program did that, people would still be getting a lot of unwanted popups. You'd need an actual option anyway if you wanted it to be reversible. Nestopia has the right idea, I just think the default against the documented risk is not warranted.

Originally, we had to ask ourselves which is worse: a few people accidentally losing save progress, or a whole lot of people having find/disable the popups. You made the decision harder by making the costs much more comparable.

[byuu]

New WIP.

I guess we've tested the container resize enough, at least for Windows. Set fullscreen container color to pure black.

To avoid the accidental mouse assignments from v039 and earlier, I went with UI buttons to assign mouse axes / buttons. Keyboard and joypads assign the same as before. The extra 1-3 buttons are for six-button mice like my MX518.

Also re-added mouse capture: load a game, and have a mouse/scope set as an input device, click in the window and it captures. Press escape to release. I blocked mouse buttons without capture now, too. That was allowing a fire shot to go through in previous versions without it when you first gained focus.

Fixed up hiro/GTK+ to compile again. Should give GNOME/Xfce/Qt4.4 distro packagers some reprieve for a while. Not going to be improving it anymore, though.

Qt/Linux now uses pkg-config, rather than hard-coded paths. No such luck for Windows users. There's a Win port of pkg-config, but not many will have it so the path to Qt will remain hard-coded.

Ditched a few more global nall::string functions (count, find, (q)replace, (q)split) and moved them inside classes. Fixed the resultant compile errors in bsnes, hiro and xkas.

The rest of the nall::string functions are also useful on char* arrays, eg strtr, strlcpy, trim, etc; so it doesn't make a lot of sense to put them inside the string class.

Not entirely impressed with how the code looks mixing class functions and global functions, but meh. At least it will reduce mistakes in trying to pass char*s to string-only functions like replace.

[blargg]

What if Nestopia had a checkbox in the confirmation dialog, labeled "Don't ask again"? I'm thinking that data-loss-prevention options should in general default to the safe settings.

That's not a bad idea, but I'm imagining to myself if every program did that, people would still be getting a lot of unwanted popups.

Programs already do this already; it's the "Do you want to save changes?" dialog. That's the essence of Nestopia's model: game progress is the unsaved document, and the confirmation is to be sure you want to lose your "changes". As others have commented, if you've made a save state within the past minute or so, it probably shouldn't confirm quitting.

Originally, we had to ask ourselves which is worse: a few people accidentally losing save progress, or a whole lot of people having find/disable the popups. You made the decision harder by making the costs much more comparable.

The decision becomes more minor, as it lessens the potential benefit/loss from making the right/wrong choice. I do agree with your general principle of not even adding features unless they benefit most users, even if they're conceptually sound. This feature may be one that should never have been added.

[FitzRoy]

Programs already do this already; it's the "Do you want to save changes?" dialog. That's the essence of Nestopia's model: game progress is the unsaved document, and the confirmation is to be sure you want to lose your "changes". As others have commented, if you've made a save state within the past minute or so, it probably shouldn't confirm quitting.

Nestopia will ask to confirm exit regardless of whether a game is loaded or has sram. I can't infer from the program itself what he's trying to prevent over there. There is no "Would you like to save your state on exit" Y/N/C prompt.

The main problem with savestates has been (a) accidentally saving instead of loading and (b) accidentally loading instead of saving. It's not like Word, people use these things as time warps, thousands of times, and eventually they do the opposite of what they intend.

To address (a), you'd need to covertly create a "backup" savestate file that updates on every overwrite with the data to be overwritten. To address (b), you'd need to covertly create a "lastevent" file being updated every second during gameplay behind the scenes. These two files would always exist somewhere in the program's folder, so when the mistakes are made, the user can load them to restore his data. The files don't have to be game specific, because mistakes should be recognized before a different game is loaded.

Consequently, this solution to (b) would also solve the phantom problem of closing the emulator without intending to.

[Verdauga Greeneyes]

To address (b), you'd need to covertly create a "lastevent" file being updated every second during gameplay behind the scenes.

It would probably be easier to save the state every time the user loads a savestate.

And I think you should keep both these backup savestates in RAM rather than making files out of them, though it might be a good idea to save one to a file automatically when you close the emulator so you can restore its state when you open it again.

Then if you really want to get extreme you could indeed update this file every now and then (say every thirty seconds) in case of a crash. Of course these files should be separate from the 'undo' savestates that are kept in RAM.

[FitzRoy]

Okay, I just realized that (b) wouldn't work because as soon as you load instead of save, the contantly updating file would update to the state of the game you just loaded to. Duh, should have seen that. Rather, the behavior would be to update that backup file before every load. Call it "statebeforeload" and the other one "antioverwrite".

Course, in creating this system, the user would have to know it's there and understand how it works, which isn't likely. If he starts flipping out and loading other states, it will screw up everything.

I think people just need to be careful and not save progress exclusively with savestates. Sometimes a hard lesson is what it takes.

[byuu]

And I just realized bsnes will never have savestates anyway :P

So should we add an option to display an "Are you sure you want to quit? <[ ] Don't show this again> [Yes] [No]" box when closing with a game loaded with SRAM, or no? If so, should it default to on or off for new users? On seems nicer, they'd only have to don't show it once. Whereas finding the enable option in the advanced panel would be trickier.

I'll go with whatever gets the majority opinion.

[FitzRoy]

And I just realized bsnes will never have savestates anyway

Well, the topic was Nestopia and blargg was trying to convince me that the option had something to do with savestates. That's the one good part about bsnes not having them. Certainly, no one posts in here complaining about lost progress. Very clever forcing people to use sram like that, byuu.

[byuu]

Very clever forcing people to use sram like that, byuu.

Hey, I'm just trying to deliver a hardware-accurate experience ;)

[creaothceann]

So should we add an option to display an "Are you sure you want to quit? <[ ] Don't show this again> [Yes] [No]" box when closing with a game loaded with SRAM

Yes.

bsnes doesn't have hundreds of unsorted options either, so I don't see a problem there.