bsnes v0.039 released

Nekokabu · Post by **Nekokabu** » Mon Jan 19, 2009 12:50 pm

byuu wrote:
Nekokabu wrote:Japanese Localization File:
http://nekokabu.s7.xrea.com/locale.zip
Hmm ... it seems this file was missing the new cheat editor window strings, so I marked it as v038-039 on the webpage. Hope you don't mind. It's only a few small strings, so it's nothing to worry about. Thanks again for making it

It is written in the terminal part of the language file:P

tetsuo55 · Post by **tetsuo55** » Mon Jan 19, 2009 1:35 pm

FitzRoy wrote:
henke37 wrote:There is a point where usability meets accuracy. Yes, it should be possible to force stupid combinations, but the defaults should be sane.
Autodetecting the system from the rom header has as much legs as autodetecting the board from the rom header. They should both be wiped out. If I made a homebrew game and had no region in the header, would it even work in bsnes right now? I wouldn't consider it more annoying, either, to have to set this. Auto-detect actually makes more sense as a developer option than a user option. It's the devs and testers who are loading lots of games indiscriminately. A real user probably plays 5 different games a month and PAL games without superior NTSC counterparts are a small fraction of games. I don't think people are switching between PAL and NTSC games with such frequency that an autodetect option saves them something. Compared to the hoops emulators like Nestopia and Nintendulator make me jump through, this is truly insignificant.

Anyways, this has nothing to do with the issue of having hidden options begetting an advanced option begetting an entire column to address the fact that the advanced option can't be sufficiently descriptive to tell users what it hides. And for what? Showing them doesn't harm anything, if anything it informs people that, yes, the system had an expansion port and the BS-X was the only thing made for it. So what, we've made users smarter.

We added the option to select PAL/NTSC instead with the menu redesign.
The reason for this is exactly what you just typed.

I agree that bsnes should only have one view, enable advance should be enabled by default and the option removed.

byuu · Post by **byuu** » Mon Jan 19, 2009 3:47 pm

I'm already impressed, it fixed the 16x16 icon resampling issue, too, and you'll probably be able to bold notes now. If you ever did an install/uninstall exe, wouldn't it be nice to specify single user mode (cfg location)?

Yeah, we could do that in the installer easily. If set to single user mode, spit out a blank bsnes.cfg file next to the EXE.

Showing them doesn't harm anything, if anything it informs people that, yes, the system had an expansion port and the BS-X was the only thing made for it.

It has an infinitesimal chance of interfering with ordinary games, if they ever try touching those ports. It can also change the behavior of the BS-X base cart. Not much now because we barely emulate the thing.

What I'd like to do is make an emulator config tab that lets you control the niche-interest dev stuff:
- CPU, PPU1, PPU2 revision
- CPU / SMP clock rates
- partial support faking controls (eg ALU delay); things we fully support like VRAM writes outside vblank failing we won't offer here
- expansion port connector
- perhaps the region auto-detect stuff

It makes sense to hide this from normal users, hence that one option. Unless you think labeling the section "Advanced Settings" is enough to scare off people. We could put that in place of the current Firefox-style editor. The CFG file is clean enough now for people to edit by hand if they need to.

Hmm, maybe a one-time explanation of the panel with an "Ok" / "I accept" button before actually showing the panel contents?

For things like joypad calibration and such, we could maybe put "advanced" or "show advanced options" buttons on the respective panels to let them control that stuff. I'll just remove the excess color filter options (sepia, grayscale, invert).

By the way I got some warnings too:

They're all worthless. It's obvious that double->unsigned will lose precision. Try -Wnone, or at least not -Wall.

I had to patch my Qt beta with #pragma GCC system_header to get it to shut up about a confirmed compiler bug it has with friend templates, because there's no other way to selectively disable junk warnings from source code.

I just tried to compile the latest WIP, but it failed. Obviously it was because of Qt. Perhaps I'm doing something wrong, but anyway I'll ask.

Look in /usr/lib for the names. Maybe it's -lqtcore or -lQtCore4 for you. Wonder if there's a pkg-config for Qt like there is with GTK+. I had to comment out the qfiledialog->setNameFilters for the version with Hardy, myself.

I'm asking if all those extra packages are really necessary just for bsnes.

They shouldn't be ... I had pure Xfce and all I had to install was libqt4-dev. It was about 50-60mb. Probably would look better loading qgtkstyle somehow too.

No denying that GNOME users are the worst off with the GTK->Qt switch. I can continue to offer the hiro wrapper for a year or so (make -f Makefile.hiro)

I guess everything could work fine with an older version, but wouldn't it create some problems with the licensing? Qt 4.3.3 is still GPL.

Here's my understanding of it all. The GPL is a distribution license, and my emulator core is completely separate from the UI, eg you can build without Qt at all. They're essentially two parts. So from your side, if you want to compile the two together, even statically linking them, that should be legal so long as you don't distribute it to anyone. So no Qt-based repository packages until everyone has 4.5, sadly. I doubt they'll make the LGPL change retroactive. I'm not going to post any official releases with the new UI until 4.5 final is out, either, just to be safe.

It is written in the terminal part of the language file:P

Ah, my mistake x.x
Fixed the version number.

I agree that bsnes should only have one view, enable advance should be enabled by default and the option removed.

There will be more options like this in the future. Are you sure you want them all exposed to everyone? Someone screwing with CPU frequencies could break games.

you'll probably be able to bold notes now

Sure, I can use any HTML styles. Also going to start bringing back the debugger now that it's trivial again. Not having to double-backport all of these options (and triple for a Cocoa version) is very nice. Will give me a chance to write some Core* wrappers for ruby, too.

Realistically, this won't be suitable for OS X users anyway. Most hate anything not pure Cocoa / Apple HIG. Can't say I blame them, the consistency of OS X was unparalleled to anything I've ever used. But it's there at least. Hopefully Richard Bannister won't mind continuing his port for all the EE stuff and native look and feel.

tetsuo55 · Post by **tetsuo55** » Mon Jan 19, 2009 4:10 pm

byuu wrote:
I agree that bsnes should only have one view, enable advance should be enabled by default and the option removed.
There will be more options like this in the future. Are you sure you want them all exposed to everyone? Someone screwing with CPU frequencies could break games.

Just add a revert everything to default settings button somewhere.
I think advanced panel with a little warning is enough

Panzer88 · Post by **Panzer88** » Mon Jan 19, 2009 8:24 pm

tetsuo55 wrote:
byuu wrote:
I agree that bsnes should only have one view, enable advance should be enabled by default and the option removed.
There will be more options like this in the future. Are you sure you want them all exposed to everyone? Someone screwing with CPU frequencies could break games.
Just add a revert everything to default settings button somewhere.
I think advanced panel with a little warning is enough

took the words out of my mouth, a return to default should be completely adequate.

tukuyomi · Post by **tukuyomi** » Mon Jan 19, 2009 8:24 pm

bsnes v0.039 french locale.
Some strings are not accurately translated because there is not much space available ("Simulate TV gamma ramp" and "Merge fields for NTSC filter" and a few others).
Anyways, Congratulations for this release, byuu! :)

FitzRoy · Post by **FitzRoy** » Mon Jan 19, 2009 8:56 pm

byuu wrote: It has an infinitesimal chance of interfering with ordinary games, if they ever try touching those ports. It can also change the behavior of the BS-X base cart. Not much now because we barely emulate the thing.

What I'd like to do is make an emulator config tab that lets you control the niche-interest dev stuff:
- CPU, PPU1, PPU2 revision
- CPU / SMP clock rates
- partial support faking controls (eg ALU delay); things we fully support like VRAM writes outside vblank failing we won't offer here
- expansion port connector
- perhaps the region auto-detect stuff

It makes sense to hide this from normal users, hence that one option. Unless you think labeling the section "Advanced Settings" is enough to scare off people. We could put that in place of the current Firefox-style editor. The CFG file is clean enough now for people to edit by hand if they need to.

Most of those aren't menu options and are outside the conversation. But yes, it's never been a problem that people can see the cpu settings where they are. Maybe if there were a bunch of game bugs in bsnes, someone would dick with them in the hopes of fixing something, but there aren't.

byuu wrote:There will be more options like this in the future. Are you sure you want them all exposed to everyone? Someone screwing with CPU frequencies could break games.

The CPU frequencies have nothing to with it, I just want the menu to be static for choices users made with real systems. Nestopia and Regen do it, do they have smarter users than you? And if you want something like the debugger hidden, it's better that it have its own option (show_debugger_in_menu) than some nondescript grouping.

AamirM · Post by **AamirM** » Mon Jan 19, 2009 9:03 pm

Wow, you made that Qt based GUI pretty fast.

Man, you can use HTML, including CSS style attributes -- even on labels. Wild stuff.

Some nice things just so far:
- program icon detection is automatic, no more ugly icons on Win2k / Win7
- labels allow hyperlinks, about window can finally have a homepage link
- font selection is now trivial, showing off in the panel for now (not planning to keep the section titles, or at least not with that big of a font)
- windows can be dynamically resized now
- emulation doesn't freeze when you enter menus
- the odd gap on the left of listbox controls is gone
- free skinning support. The wood grain one is just crazy. Should definitely take advantage of that somehow

*drools* Awesome features

. Though, the last time I looked at doing some Qt stuff, its "qmake" stuff annoyed me to hell. Anyways, congrats on the release

.

Post by **grinvader** » Mon Jan 19, 2009 9:15 pm

The qmake step can be removed if you include the needed step in a classic makefile. You can have a look at zsnes' Makefile.in to see the compiling rules we use, and that was done in mere minutes.

AamirM · Post by **AamirM** » Mon Jan 19, 2009 9:29 pm

grinvader wrote:The qmake step can be removed if you include the needed step in a classic makefile. You can have a look at zsnes' Makefile.in to see the compiling rules we use, and that was done in mere minutes.

Damn. Anyways, not interested in Qt anymore since GTK+ works for me and I am not much of a consistency zealot (though I do envy bsnes' consistent UI). Heck, I am actually looking at making Media Player 10-style toolbar in the Windows port because those menus are starting to look old and boring.

burning shadow · Post by **burning shadow** » Mon Jan 19, 2009 10:01 pm

byuu wrote:- ZIP archive w/DLLs included

This one, please...

DataPath · Post by **DataPath** » Tue Jan 20, 2009 3:14 am

Byuu, offer's still good for a bsnes windows installer if you want to take me up on it.

85cocoa · Post by **85cocoa** » Tue Jan 20, 2009 4:43 am

Could you clarify again what the status of the priority queue (delta queue?) is currently? You said on your site on 2009-01-04 that you couldn't get it to work, but the 0.039 changelog mentions the use of a priority queue. How exactly is it being used?

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Tue Jan 20, 2009 5:47 am

Basically it queues all the timed events, but tests IRQs every -second- clock (it was testing it every single clock before which is the cause for the speedup), rather than range testing them when necessary. I've realised I don't understand the 'range testing' enough to make it happen, but it would essentially skip testing IRQs except when necessary, which would provide another speedup.

So the priority queue is still a nice and clean way to handle timed events, it just didn't lead to the range testing byuu was hoping for.

creaothceann · Post by **creaothceann** » Tue Jan 20, 2009 11:10 am

http://rapidshare.com/files/186466822/b ... locale.rar

Changed some things too, compared to the last version.

henke37 · Post by **henke37** » Tue Jan 20, 2009 1:13 pm

About the warnings, are you per chance using the -I compiler flag for library files? Don't do that, use -isystem instead, it marks it as a system include and it gets the same filtering as those headers.

neviksti · Post by **neviksti** » Tue Jan 20, 2009 2:04 pm

Now that it sounds like you're settling into a final choice for a UI library, any chance the debugger will show up again?

byuu · Post by **byuu** » Tue Jan 20, 2009 4:16 pm

Woke up late, only had an hour or two, and I spent all of it fighting with getting child widgets to take the full height of their parent widget. Way harder than it should have been, but I got it working.

And for FitzRoy ;)

Already running late to work, so I'll have to update the new locales tomorrow. I also have Chinese - Simplified and Chinese - Traditional in my mailbox for those interesting.

Thanks again for these.

About the warnings, are you per chance using the -I compiler flag for library files? Don't do that, use -isystem instead, it marks it as a system include and it gets the same filtering as those headers.

Interesting, I'll give that a try, thanks.

Now that it sounds like you're settling into a final choice for a UI library, any chance the debugger will show up again?

Yes, absolutely.

FitzRoy · Post by **FitzRoy** » Tue Jan 20, 2009 5:45 pm

Cool, however I wonder if resize ability is practical to allow. What happens when one you resize a window with less contents and then switch to a section with more? Does it cut off those contents or snap the window back to accommodate it?

byuu · Post by **byuu** » Tue Jan 20, 2009 6:08 pm

If it wasn't obvious, the white box at the bottom is an empty listbox for demonstration purposes. Won't be there in the final version.

As for the section label ... I really like having the fancy font there. I know it's semi-redundant, but we aren't hurting for space due to GTK+ list item heights anymore, either.

I want to use it for more verbose descriptions:
"Drivers" -> "Driver Configuration Note: You must reboot for changes to take effect."
"Video" -> "Video Settings"
"Audio" -> "Audio Settings"
"Input" -> "Input Configuration"
"Paths" -> "Default File Paths"
"Cheat Codes" -> "Cheat Code Editor"
"Advanced" -> "Advanced Configuration Settings Warning: bla bla bla!!"

I'll make the font much smaller at least. Maybe put a red background on it to make it stand out more like a titlebar.

I do really want to get some icons in there, too. I really think we can beat even SNESGT's slick UI design now.

FitzRoy wrote:Cool, however I wonder if resize ability is practical to allow. What happens when one you resize a window with less contents and then switch to a section with more? Does it cut off those contents or snap the window back to accommodate it?

If you're on a smaller window, and you shrink it all the way, then when you switch back to the bigger window, the window expands again so that no content is cut off.

If you check wip02, what I did there was set a minimum size on the window. I can do the same with this to ensure the content always fits so the window won't ever grow on you.

Also new to wip03, I'm clipping the main window to 256x224 minimum, you can see how that works there.

bobthebuilder · Post by **bobthebuilder** » Tue Jan 20, 2009 6:31 pm

So with qt would true full screen be possible now

byuu · Post by **byuu** » Tue Jan 20, 2009 6:53 pm

Man ... Qt is incredible.

Code: Select all

  QLabel label("&nbsp;<u>Video Settings</u>&nbsp;");
  label.setStyleSheet(
    "background-color: qlineargradient(x1:0, y1:0, x2:1, y2:1, stop: 0 #c00000, stop: 1 #000000);"
    "color: #ffffff;"
    "font: 18pt 'Segoe Print';"
    "font-weight: bold;"
  );

Not only can you use HTML right inside your code, you can apply your own CSS stylesheets(!!)

Oh, and there's one for QApplication, too:

http://doc.trolltech.com/4.3/stylesheet ... heet-usage

Code: Select all

qApp->setStyleSheet("QLineEdit { background-color: yellow }");

So for bsnes, I'm going to make it look for style.css. If it exists, then you can do whatever you want. Hide the section text labels, make controls bigger, change their colors, whatever.

Combine style.css with locale.cfg, and we can finally please everyone :P

So with qt would true full screen be possible now

I'm not adding true fullscreen support, sorry. There's just no need for it anymore with hardware accelerated blitting. I already have smooth video, just match your monitor to it, which is only a problem for legacy CRTs.

And once OLED monitors come out, refresh rate won't even matter anymore. They have ~0.01ms response times.

FitzRoy · Post by **FitzRoy** » Tue Jan 20, 2009 8:09 pm

byuu wrote:As for the section label ... I really like having the fancy font there. I know it's semi-redundant, but we aren't hurting for space due to GTK+ list item heights anymore, either.

Option menus may be plain, but there is beauty in having uniformity between programs, and we should maintain that. When you say we're not hurting for space, I'm perplexed. You were bothered by sections that had too much space even at the minimum, and you created stuff to fill it up. There is a conflict going on here that we have to balance. Not all sections are going to have the same amount of stuff, that's something we have to accept. The idea then is to eliminate VAST swaths of empty space and ridiculous button/listbox elongation by only giving the larger ones what they need. With all this new empty space from unlimited resizing, you're subconsciously readding in the redundancies we removed before. I think we should stick with the scheme we had before and not go crazy on the new capabilities just because they're there.

I do really want to get some icons in there, too. I really think we can beat even SNESGT's slick UI design now.

I'm very picky and I might be able to do this. Keep in mind that I generally think in-program icon art is reserved for programs with toolbars. Scissors is an obvious representation for cut, but many of the larger toolbars I've used run into problems where the command has no clear graphical representation and it ends up being something generic: a mechanical gear, a little window, a little stick man, something that looks like a pelican. I make no promises, but if you agree to keep the old scheme, I'll make some.

King Of Chaos · Post by **King Of Chaos** » Tue Jan 20, 2009 8:21 pm

Why not through a little bit of Vista/7's Aero Glass into that interface?

creaothceann · Post by **creaothceann** » Tue Jan 20, 2009 8:35 pm

byuu wrote:Not only can you use HTML right inside your code, you can apply your own CSS stylesheets(!!)

Does it compile webkit into every application or what?