bsnes v0.039 released

franpa · Post by **franpa** » Mon Feb 09, 2009 1:24 pm

he mistyped, not misspelled. You repeatedly spelled vertical as virtical because you thought that was how it was spelled. creaothceann made a "mistake" because he was typing quickly.

creaothceann · Post by **creaothceann** » Mon Feb 09, 2009 2:12 pm

And I didn't correct it because at that time editing was broken. Anyway, feel free to point out mistakes.

(Yeah, should've PMed you...)

byuu · Post by **byuu** » Mon Feb 09, 2009 8:20 pm

I've decided to go ahead and keep developing hiro after all.

The Qt interface on GNOME/GTK+ is simply terrible, even with QGtkStyle. And many aren't going to want to add Qt dependencies, eg 2G SSD users.

Plus, compilation on Windows is significantly simplified when using the native UI, rather than requiring users to build / download pre-built Qt.

And all of my other apps really can't afford something like Qt, with its 4MB DLL dependencies. Things like tsukuyomi and bview.

But I'm not going to keep the two ports in sync. Most specifically, I won't be adding the future debugger to it. The simplified API makes things like an in-place memory editor and pixel-perfect font sizing too complex. But it's still a great library for small apps.

------------------------------------------------------

Also, licensing discussion time again.

I want to release a future version under the LGPLv2, but I don't want to allow others' contributions to the core library to be released under the full GPLv2. Is there any way I can do this?

If not, is there a license I can choose that has the same effect, but is compatible under the OSI and/or FSF? (unlikely the latter.)

What I want:
- anyone can use my code, in an open or closed app
- they can statically link my code
- if they make changes to my code, they have to release those changes
- those changes follow the same rules: people can use them in closed apps

What I'm afraid of:
- someone doing something really cool that I want to add back, but without losing the ability to release this new combined code under LGPL in the future

I prefer non-commercial only, but I know not letting others profit off your work makes your work "proprietary and non-free." Meh.

FitzRoy · Post by **FitzRoy** » Tue Feb 10, 2009 10:16 pm

I'm just curious at how bad Gnome looks, got a photo? Is it worse than what happens to the Window port of hiro (which is like 90% of the market)?

I mean, it seems like no matter which library you choose, one OS or another is going to look bad.

Edit: sorry, not KDE, Gnome.

burning shadow · Post by **burning shadow** » Wed Feb 11, 2009 8:50 am

byuu wrote:I've decided to go ahead and keep developing hiro after all.

Yes!

henke37 · Post by **henke37** » Wed Feb 11, 2009 7:10 pm

Just write your own license and say "screw you guys, I will just do it on my own". I have yet to release something with a stock license.

byuu · Post by **byuu** » Thu Feb 12, 2009 7:41 pm

FitzRoy wrote:I'm just curious at how bad Gnome looks, got a photo?

Sorry, been a bit busy lately. I'll try and get up a comparison tonight or tomorrow.

FitzRoy wrote:Is it worse than what happens to the Window port of hiro (which is like 90% of the market)?

Hard to say ... probably yes.
You don't have the "way too tall" controls thing going on; but you lose things like the groupbox frame, and the controls themselves really stand out compared to other apps.

Dullaron · Post by **Dullaron** » Thu Feb 12, 2009 9:27 pm

If it the worst thing to have then don't added it at all.

byuu · Post by **byuu** » Fri Feb 13, 2009 8:20 am

Finally, a new WIP.

I redid the spacing / margins on all windows, it should match the old bsnes/hiro port better now.

Removed all instances of QGroupBox, to work around the problem with QGtkStyle ignoring the frame entirely, as well as getting around the ridiculously large margin-top in it that you can't remove. Using horizontal spacers in its place. Quite a bit more annoying to code for, but it looks better than even the working frame, at least in my opinion.

Modified the config panel listbox trigger to use currentRowChanged() instead of itemSelectionChanged(). This fixes an annoying glitch where if you clicked down on an item and dragged the mouse, it'd be off-by-one in the list.

The code editor and cheat code panel both disable buttons when actions aren't allowed, ala bsnes/hiro. There seems to be a bug in QTreeWidget::itemSelectionChanged() on Linux, the returned QTreeWidgetItem::isSelected() value is inverted. Too tired to work around that tonight.

Improved automatic window resize for the input config and ROM add-on cart loader windows. They should fully shrink as much as possible now, rather than leaving blank space.

Dropped the Segoe Print font for titles, as it only looks good on Vista+.

Removed the sort stuff from the cheat core class and hiro UI, since the Qt UI can sort by header clicks.

Scale Nx items are checked again according to config file setting.

Stuff left to do:
- work around Qt/Linux bug on edit/delete enable on cheat code panel
- cheat codes don't seem to be saving to disk
- need to re-add screensaver disable code

FitzRoy, it's hard to show you the Qt rendering issues on GNOME, if you're not familiar with how it should look ...

http://byuu.cinnamonpirate.com/temp/clearlooks.png
http://byuu.cinnamonpirate.com/temp/qgtkstyle.png

Clearlooks is the KDE default style. Looks good, but doesn't match GTK+ apps.

QGtkStyle is the Qt wrapper that tries to use your GTK+ theme. Biggest annoyance would be the buttons. There's this red box in the middle that shows up when a button has focus. With the real GTK+, the entire button turns red (no border) when you click it, but with just focus alone it shouldn't have any color. The fonts are also much uglier, like it has really poor anti-aliasing and slightly wrong sizes.

Thristian · Post by **Thristian** » Fri Feb 13, 2009 11:25 am

byuu wrote:Clearlooks is the KDE default style. Looks good, but doesn't match GTK+ apps.

Actually, Clearlooks is the standard GTK+ theme since 2.12, that Qt has tried to emulate since 4.2.

The fonts are also much uglier, like it has really poor anti-aliasing and slightly wrong sizes.

Perhaps they're copying the GTK+ defaults rather than using your current settings, or maybe they're trying to read the current setting from wherever GNOME puts them rather than wherever XFCE puts them. Still, as one who has used GNOME exclusively for years, I'd rather put up with the slight oddities of QGtkStyle or even the weird Cleanlooks theme than have you spend more time on boring coding that other people are being paid to do anyway (viz. writing cross-platform GUI toolkits). And hey, maybe one day somebody like BearOso might pop up one day with a native GTK+ port, for the best of both worlds.

Also: yay, licensing thread!

What I want:
- anyone can use my code, in an open or closed app
- they can statically link my code
- if they make changes to my code, they have to release those changes
- those changes follow the same rules: people can use them in closed apps

The trouble here, as I understand it, is that copyright law works on the concept of a 'derived work'; that is, an idea based off a previous idea. Whether the modification is 'edited the source-code to change how it works' or 'ran the source through a compiler' is immaterial; the law treats both the same way, which makes it difficult to write a licence based on copyright law that distinguishes them.

For example, if somebody was using a non-ISO-C++ compiler to make some product and had to adjust the order of fields in some headers in order to link some bsnes component with the rest of their code, or to modify your makefiles to call their special compiler at a particular path, would your hypothetical licence require them to release those changes or not? On the one hand, they're minimally invasive changes as anyone who wants to use an open-source library might expect to make, on the other hand they are technically changes to your code. Distinguishing between significant and insignificant changes might be difficult for a human to do on a case-by-case basis; writing static legal code to reliably distinguish them would be practically impossible.

What I'm afraid of:
- someone doing something really cool that I want to add back, but without losing the ability to release this new combined code under LGPL in the future

This is not so much a legal opinion as an observation of life in general, but so far as I can tell, either I can share what I have with people and accept that some people will be bastards unfit for human society, or I can keep everything to myself. The hypothetical third option of 'only share with people I like' works out to be the same as 'keep everything to myself', since very few people will want to invest the time to establish a personal relationship with me and gain my trust so they can ask for and be reasonably confident of receiving permission to use my stuff, especially since we might just never get along, or have a fight some time later.

I prefer non-commercial only, but I know not letting others profit off your work makes your work "proprietary and non-free." Meh.

Like the "how significant does a change have to be before it's required to be shared" problem, "non-commercial use" is difficult to reliably define. For example, I'd assume that playing games in the privacy of my basement would be OK while selling bsnes CDs on eBay would be not OK. However, what about if I publish modifications to bsnes and an employer who sees them decides to hire me because of them? Is that commercial use of the bsnes code, since I'm commercially benefiting from it? What about a video-game museum who uses bsnes to demonstrate SNES games without endangering antique SNES hardware? Visitors are being charged money to come in and play SNES games (among other things), does that become commercial use of the bsnes code? Even something simple like using bsnes in a university course about embedded programming would be problematic - you might think that academic would be the opposite of commercial use, but those students are paying an awful lot of money in tuition fees...

(You might be interested to know that the Mozilla Public Licence defines "commercial use" as "distribution or otherwise making the Covered Code available to a third party.")

I don't really have any good licensing suggestions to offer, I'm afraid, but I hope you can find a balance you're comfortable with between the rights of yourself, your current contributors and potential contributors in the future.

Gil_Hamilton · Post by **Gil_Hamilton** » Fri Feb 13, 2009 11:54 am

Thristian wrote: What about a video-game museum who uses bsnes to demonstrate SNES games without endangering antique SNES hardware? Visitors are being charged money to come in and play SNES games (among other things), does that become commercial use of the bsnes code?

The only video-game museum exhibit I know of uses real hardware. It also focuses on arcades, but... *shrug*.

I'm skeptical that any museum exhibit taking itself seriously would use an emulator when the original thing is so readily available.

It's easy to make SNES-compatible controllers, and that's the only part likely to be endangered in a museum exhibit.

</tangent>

Thristian · Post by **Thristian** » Fri Feb 13, 2009 12:12 pm

Gil_Hamilton wrote:I'm skeptical that any museum exhibit taking itself seriously would use an emulator when the original thing is so readily available.

Passing lightly over the fact that I was just making a hypothetical example, byuu has mentioned a number of times that bsnes tries to preserve the structure and behaviour of the SNES hardware so that there'll be a record of it when the hardware and cartridges are no longer working. As for "readily available", here in Australia the oldest "readily available" gaming hardware is the PS2; for anything else you have to hunt on eBay. And don't forget things like the BS-X that are difficult to come by even today.

Also, on GameSetWatch today I came across this press release about the EU spending €3.15m on game emulation...

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Fri Feb 13, 2009 1:01 pm

Thristian wrote:Also, on GameSetWatch today I came across this press release about the EU spending €3.15m on game emulation...

Interesting article. I wonder if byuu should contact them

KEEP will address the problems of transferring digital objects stored on outdated computer media such as floppy discs onto current storage devices. This will involve the specification of file formats and the production of transfer tools exploited within a framework, and taking into account possible legal and technical issues. KEEP will address all aspects ranging from safeguarding the original bits from the carrier to offering online services to end-users via a highly portable emulation framework running on any possible device.

PCB format anyone?

belegdol · Post by **belegdol** » Fri Feb 13, 2009 3:11 pm

I just tried wip13 and it seems I've found a small bug: when you build the qt port with gzip and jma enabled, the file extension filter will not get updated with .zip, .jma and friends.

byuu · Post by **byuu** » Fri Feb 13, 2009 7:05 pm

I've added drag-and-drop support to the main window. You can now drag a ROM onto it, and it will load it.

Code: Select all

void CanvasWidget::dragEnterEvent(QDragEnterEvent *event) {
  if(event->mimeData()->hasUrls()) {
    QList<QUrl> list = event->mimeData()->urls();
    if(list.count() == 1) {
      event->acceptProposedAction();
    }
  }
}

void CanvasWidget::dropEvent(QDropEvent *event) {
  if(event->mimeData()->hasUrls()) {
    QList<QUrl> list = event->mimeData()->urls();
    if(list.count() == 1) {
      utility.loadCartridge(list.at(0).toLocalFile().toUtf8().data());
      event->acceptProposedAction();
    }
  }
}

I can actually parse multiple files this way, but it seems like a really obscure way to load BS-X and ST multi-part images. So instead, I just accept only one file at a time, and it'll pop up the loader if needed.

Actually, Clearlooks is the standard GTK+ theme since 2.12, that Qt has tried to emulate since 4.2.

Ah, hm. I will have to try setting my main GTK+ theme to that, and see if it matches better. Though I like Murrina more.

Still, as one who has used GNOME exclusively for years, I'd rather put up with the slight oddities of QGtkStyle or even the weird Cleanlooks theme than have you spend more time on boring coding that other people are being paid to do anyway

Appreciate it. It's not terrible by any means, just a slight step down. The Qt file dialogs are definitely better, but you can always use QGtkStyle and get the GTK+ native ones, too.

I'm thinking the UI will be good enough for most OS X users, too. I even use the Qt menubar hints to put about / preferences in the right spots in the menu.

The trouble here, as I understand it, is that copyright law works on the concept of a 'derived work'

Yeah, licensing gets ridiculously complex. That's why I'd like to use LGPL v2.1 with one tiny change. But I image the FSF won't be too keen to me adding one clause to it and calling it something else.

This is not so much a legal opinion as an observation of life in general, but so far as I can tell, either I can share what I have with people and accept that some people will be bastards unfit for human society, or I can keep everything to myself.

I release the source already, and people already do ignore the license. Not much we can do.

But I'd like a nice license for people who do respect them, eg nice people and corporations that don't like getting sued :P

(You might be interested to know that the Mozilla Public Licence defines "commercial use" as "distribution or otherwise making the Covered Code available to a third party.")

Then they're stupid. Yeah, refute that ad hominem :P

Also, on GameSetWatch today I came across this press release about the EU spending €3.15m on game emulation...

Nice way to con the EU govt out of 3.15 million hair combs.

Unless they have some way to preserve their chosen programming language for all of time, and have a future-proof hashing algorithm to verify their game images are bit-perfect, then they're just re-inventing the wheel.

I just tried wip13 and it seems I've found a small bug: when you build the qt port with gzip and jma enabled, the file extension filter will not get updated with .zip, .jma and friends.

Slight oversight. Thanks for pointing it out.
Suppose that means the Qt port is working okay for you on Fedora, cool.

------------------------------------------------------------

Edit: good news! Profiling works with MinGW / GCC 4.3.2. It was crashing before when I was using 4.1.0.

On my E4500 system:

Zelda 3 Link's house: 104fps normal, 115fps profiled (+~10%)
Bahamut Lagoon title screen: 107fps normal, 123fps profiled (+~15%)
IRQ test: 141fps normal, 168fps profiled (+~20%)

Keep in mind, GCC's PGO is not as powerful as Visual C++'s, but it also creates binaries that are ~10% faster with no profiling on either. Combining the two, it's a ~20-25% advantage over unprofiled Visual C++.

So yeah, free ~10-15% speedup for the next release.

byuu · Post by **byuu** » Sat Feb 14, 2009 10:05 am

Okay, another new WIP.

Drag-and-drop is in, and it works in Windows and Linux. Tested with Thunar under Xfce, but it should be fine with any freedesktop.org-compatible app/WM.

Worked around the Qt bug ... either qtreewidget->currentItem()->isSelected() returns the true current item and the Xlib port has a bug, or it returns the previous and the Windows port has a bug. I'm using qtreewidget->selectedItems().count()==1 in its place. Works on Windows and Linux, so the cheat editor should be fine now.

Forgot to add assign / unassign key disable in the last WIP, so I took care of that this time.

Added back the readme and license viewers. Used QTextBrowser, which lets me use HTML formatting plus anchor hyperlinks. Not terribly useful with such small documents, but meh. We can grow "readme" into "documentation" in the future. Maybe even add a section listbox on the left ala CHM files. Throw in a custom CSS stylesheet to make it prettier. Whatever, not worried about it right now, but we'll get it ironed out before v040 official.

Got too tired (Red Bull having no effect either), forgot to add the .zip,.gz,.jma file extensions; and didn't check if cheat codes are saving on Linux. Also need to work on getting window show commands to put the windows in the foreground. If they're already visible, they aren't raising to the top / gaining focus.

Still need to add a bunch of GUI hotkey bindings back, and I think that'll do it for the rewrite. From there it's all adding stuff the hiro port lacked.

belegdol · Post by **belegdol** » Sat Feb 14, 2009 12:13 pm

byuu wrote:Suppose that means the Qt port is working okay for you on Fedora, cool.

Yes, it is. I have managed to build it, I only needed to change moc to moc-qt4 in the Makefile.
If I understand correctly, both hiro and qt UIs are going to be updated, so I think I'll try to provide both in an RPM package, probably renaming binaries to bsnes-qt and bsnes-gtk.

FitzRoy · Post by **FitzRoy** » Sat Feb 14, 2009 5:28 pm

byuu wrote:Added back the readme and license viewers.

Looking better. I will add that the "okay" buttons in all your help sections aren't necessary, you don't need more than one way to close a window. I agree about the section links.

byuu · Post by **byuu** » Sat Feb 14, 2009 9:44 pm

FitzRoy wrote:Looking better. I will add that the "okay" buttons in all your help sections aren't necessary, you don't need more than one way to close a window. I agree about the section links.

Yeah, and they get kinda stupid long again. Will either have to go with fixed button sizes and blank space, or growing hot dogs. UI design says the latter makes for easier usage, but when it's so difficult to even perceive the advantage, we should probably go for aesthetics instead.

Suppose we can drop them.

So ... were you planning to make the readme part more documentation-like, as well? May as well start discussing that a bit. What sections would we need?
- video, audio, input setting descriptions
- maybe driver troubleshooting
- unsupported chips should be there
- known inaccuracies probably isn't that useful, but maybe keep it
- should keep contributors
- maybe windowed / fullscreen functionality explained

We can also split things up with a contents list on the left, and unique pages for each section. Or go with the anchor links.

blargg · Post by **blargg** » Sat Feb 14, 2009 10:08 pm

byuu wrote:Yeah, licensing gets ridiculously complex. That's why I'd like to use LGPL v2.1 with one tiny change. But I image the FSF won't be too keen to me adding one clause to it and calling it something else.

If you use one of the standard licenses, potential licensees can find good coverage of its meaning and compatibility. If you use a non-standard one, even if just a standard one with a minor change, potential licensees don't have those resources for understanding it. Not that you weren't aware, just that "one tiny change" implied that it wouldn't make it non-standard.

FitzRoy · Post by **FitzRoy** » Sun Feb 15, 2009 2:42 am

So ... were you planning to make the readme part more documentation-like, as well? May as well start discussing that a bit. What sections would we need?

Okay, so I created a mockup and let's start with my reasoning for why some things shouldn't exist:

- video, audio, input setting descriptions

Almost every feature's purpose is self-evident. Nothing needs explaining here except a few things for which I've created a section called "Inevident Features."

- unsupported chips should be there

Listing chips and peripherals is expecting the user to know off-hand what games used them. Support also isn't a black/white thing, it's a very variable thing from hardware to hardware. I think a general warning about special hardware is needed here, you're never going to be able to document every little game that has problems in the readme.

- maybe driver troubleshooting

What is there to troubleshoot? Some drivers have limitations, but anyone familiar with them should know them and anyone not familiar with them shouldn't be using them.

- known inaccuracies probably isn't that useful, but maybe keep it

The average user doesn't need told the specifics, he doesn't understand what "mul/div delays" and "FirstY priorities" are.

- should keep contributors

Yep.

- maybe windowed / fullscreen functionality explained

First thing in ambiguous features. When this gets in, I highly recommend removing the toggle in the menu. Now that the menubar no longer shown in fullscreen by default, nobody should be capable of going into fullscreen without knowing the existance of the hotkey to get out. I also recommend changing BS and ST to BSX and SFT, because those were the acronyms used in the serial system.

So with that said, here is what I constructed:

Code: Select all

Inevident Features:

- Toggling in and out of fullscreen mode is a hotkey action assigned to "F11" by default.
- Toggling the presence and absence of the menubar and statusbar is a hotkey action assigned to "Esc" by default.
- When emulation speed is synced to both audio and video, audio and video distortions can be minimized by adjusting the input frequency setting.
- Configuration data is automatically stored in the active user account's home folder so that each user account can access a common executable while retaining its own settings.
- The language in which the user interface appears can be changed by obtaining a localization file from the website and placing it in the same folder as the executable.


Known Limitations:

- Some hardware is still partially or completely unemulated, causing certain games to malfunction.
- Savestates will never be supported due to the way in which the program handles processor parallelism.
- Compressed archives with non-ANSI characters in the filename require UTF-8 support and will fail to load on Windows.
- Netplay is not yet supported.


Supported Filetypes:

- SFC: Representative of program data on the ROM chip of a standard cartridge or on the EEPROM chip of a "Nintendo Power" flash cartridge.
- SMC: Different only in name from SFC, this extension was used by the "Super Magicom" unlicensed copying device.
- SWC: Different only in name from SFC, this extension was used by the "Super Wild Card" unlicensed copying device.
- FIG: Different only in name from SFC, this extension was used by the "Pro Fighter X" unlicensed copying device.
- BSX: Representative of program data on the EEPROM chip of a "Broadcast Satellaview-X" flash media cartridge.
- SFT: Representative of program data on the ROM chip of a "Sufami Turbo" media cartridge.
- SRM: Representative of save data on the SRAM chip of a cartridge.
- RTC: Representative of states on the real-time clock chip of a cartridge.
- UPS: Representative of patch data intended to modify original program data.
- CHT: Representative of cheat codes in the spirit of "Game Genie" and "Pro Action Replay" unlicensed cheating devices.


Contributors:

Andreas Naive, anomie, blargg, DMV27, FitzRoy, GIGO, Jonas Quinn, kode54, krom, Matthew Callis, mudlord, Nach, neviksti, Overload, RedDwarf, Richard Bannister, tetsuo55, TRAC, zones.

Edited: renamed ambiguous features to inevident features.

byuu · Post by **byuu** » Sun Feb 15, 2009 3:30 am

If you use a non-standard one, even if just a standard one with a minor change, potential licensees don't have those resources for understanding it.

I figure if they can understand the legalese of the LGPL fully, that a clause "your contributions must also be released under the LGPL, and not the GPL" should be easy enough. At least, it would be an improvement over the custom license I have now.

But yes, I agree it's definitely not ideal and adds a whole host of other complications (not being GPL-compatible a big one).

Sigh, licensing stuff is tough. I really don't want to be in a position where others can build off my code, but I can't build off of theirs -- eg I don't want to compete against myself. And I don't want to be forced to always use the GPL myself.

So with that said, here is what I constructed:

Interesting stuff. Yeah, the basic features are probably explanatory enough. It'd just fit in with the idea of it being "documentation", rather than just a "readme". Eg we could expand upon "Use gamma ramp".

"This setting attempts to simulate the darker luminance levels seen on television sets, as compared to computer monitors. It helps with eliminating the appearance of 'washed out' colors, but may obscure finer details in already dark imagery. By default, this option is enabled."

It's not like we have a size limit here. We can put the most important stuff first.

Next, BSX and SFT. I like using the N.3 format over .bs and .st, but where do you get SFT from? I get SuFami Turbo, but I've never seen that acronym used before. What is this serial system you speak of? Thought BST (Bandai Sufami Turbo) sounded a bit better.

I also want it to jive with what ZSNES and Snes9X are doing.

I think a general warning about special hardware is needed here, you're never going to be able to document every little game that has problems in the readme.

There's only ~30-40 games bsnes won't run, and we aren't aware of bugs in any other games. I just mention a few popular games as they'd be the most commonly run. I still see a lot of forum posts out there where people are confused as to why SMW2 won't run. True, they probably won't check the documentation. Hopefully v040's new popup alert will help out there.

FitzRoy · Post by **FitzRoy** » Sun Feb 15, 2009 7:45 am

Changed ambiguous to inevident, better word.

byuu wrote: Interesting stuff. Yeah, the basic features are probably explanatory enough. It'd just fit in with the idea of it being "documentation", rather than just a "readme". Eg we could expand upon "Use gamma ramp".

It's not like we have a size limit here. We can put the most important stuff first.

I think the gamma is fairly clear. The option plainly states "Simulate TV gamma" and its darkening effect is evident when you play with it.

Doing writeups for things like volume and brightness and reset would truly be a waste of space. We're trying to get people with no patience for instructions to read this thing, I give us 30 seconds max. I really tried to condense it. It would help if you showed it on first run, too.

Next, BSX and SFT. I like using the N.3 format over .bs and .st, but where do you get SFT from? I get SuFami Turbo, but I've never seen that acronym used before. What is this serial system you speak of? Thought BST (Bandai Sufami Turbo) sounded a bit better.

SFT was the acronym used for the catalog codes. For example, Poi Poi Ninja World had SFT-0103 on the cartridge. So there is some historic precedent for it at least. BSX, not so sure, but I figured everything else was three letters.

There's only ~30-40 games bsnes won't run, and we aren't aware of bugs in any other games.

They're not going to memorize a list from the readme, so the popup warning is necessary. Gundam GX and Exhaust Heat 2 still bug out, I believe, despite running. There may also be some minor problems in TG3K. The Super Scope isn't fully emulated, I could have put X Zone on the list. How about the BSX? Total crapshoot with that one, some run well, some poorly, some not at all. I ain't documenting that.

byuu · Post by **byuu** » Sun Feb 15, 2009 8:23 am

Okay, new WIP. To my knowledge, the Qt port now matches or exceeds the feature-set / quality of the hiro port in every regard, sans things I've intentionally removed.

- added back all the UI shortcut keys
- started using Qt's resource compiler, rcc, to embed files into the binary on all platforms; not as efficient as my base56+LZSS method, but much more standardized and avoids string length limits in Visual C++
- Linux port now sets the program icon from bsnes.png @ 48x48 (any larger and the filtering makes it look bad)
- Windows port uses embedded 16x16, 32x32, 48x48 or 256x256 icon as before
- all windows now rise to the top when they are shown
- replaced about screen -- it's just a placeholder for now so that it's not modal. Want to put the logo on there, with the rest of the info and a webpage link below
- removed 'Ok' button from document viewer window
- killed icon48.h and controller.h, ~100kb worth of source. Right now, hiro port shows black boxes in their place. I'll do something nice with it later; but I don't want to grow the source that big for the non-standard target
- added .zip, .gz and .jma to filter, based on compilation flags

Thinking about killing src/data, putting the necessary stuff in each platform folder. Just a slight issue with windres taking a relative path to the working directory, so it won't allow easy renaming of the ui folder names if I do that. Can work around it with 'cd' command in the Makefile, I suppose.

Would be nice to take advantage of rcc a bit more: it's very easy to use 16x16 / 32x32 icons inside the UI for eg menu and config panel list icons. Just going to be tough to make nice icons for them.

Stuff removed from hiro:
- controller graphic:
I love this graphic and want to have it in the official binary, but it looks really odd when it's only there for one controller type ... should we keep it anyway? If so, I'll embed it with rcc.
- trace logging hotkeys:
Want to replace these with a real debugger that will have buttons for them. That will be a long-term goal, of course. May add shortcut keys for the debugger functions too at that time.
- frameskipping:
Probably the biggest one, I didn't want to re-add this as the new PPU will make it pointless anyway. If we do add this back for the fast PPU, I'll probably keep the option hidden from the UI side.

SFT was the acronym used for the catalog codes. For example, Poi Poi Ninja World had SFT-0103 on the cartridge. So there is some historic precedent for it at least. BSX, not so sure, but I figured everything else was three letters.

Sounds good, but I'd like to check with Nach first. He seems to be on extended leave at the moment.

Exhaust Heat 2 still bug out

Wasn't aware ST-0010 had any problems. Not sure if it's bit-perfect or not anymore, but it definitely has no DSP timing.

henke37 · Post by **henke37** » Sun Feb 15, 2009 9:34 am

I find the current bad chips list in the read me fine, just move it to the documentation.
Yes, the individual chip names could just as well be random garbage for end users, but combined with the game listings that they act as headers for, they does serve a purpose.