Gambatte 0.5.0-wip2 released

[DataPath]

Gambatte has been ported to Maemo (Nokia Internet Tablets). The current setup uses gambatte_sdl, and a python frontend. I'm writing a GTK UI to make it integrate better with the whole system.

Just thought I'd say I think it's really cool if you're able to make it run well on something like that. I'm actually kind of surprised it runs full speed at all (and software scaled even).

It's not as fast as gnuboy, but it runs at decent speeds. I plan on sticking with the gambatte core, though, as long as it's being actively developed.

After I get the tablet version finished, I might take out the Nokia-specific stuff and make a generic debian package, too.

Just for you, Nach.

[Nach]

I will have to send hit men after you DataPath. For every app that uses a built in GTK file dialog, a dozen computer users commit suicide (or 500 kittens get killed, or whatever metaphor you like).

Do not be part of the problem.

[DataPath]

I will have to send hit men after you DataPath. For every app that uses a built in GTK file dialog, a dozen computer users commit suicide (or 500 kittens get killed, or whatever metaphor you like).

Do not be part of the problem.

Actually, the Nokia Internet Tablets use the Hildon UI, which builds on GTK, but has it's own file dialog.

The straight GTK idea was a special one-off build just for you.

[grinvader]

(or 500 kittens get killed)

All my apps now have gtk open dialogs.

[Nach]

(or 500 kittens get killed)

All my apps now have gtk open dialogs.

The kitten line was for people who don't like kittens, these rules are generally the opposite for those that like them.

So in your case, you might to substitute for something like, "Every time you create an app with a GTK file dialog, a cat that grinvader sees transforms into a patriotic Frenchman who believes in enforcing the Frenchmen way onto others, and even more so if they're already French."

[judge]

Sinamas,

great work on all those tests. I've been using a lot of them to improve little details in MESS.

On what systems did you test all those test roms? I found that several of the gbc tests have incorrect checksums (0xC0 difference) for instance and there are sometimes subtle differences between a dmg, mgb, or cgb.

[sinamas]

Most of them are only tested on a cgb-001. Some tests were tested with a flashcart bootrom (in the cases where that was deemed unlikely to affect the results). I've probably forgotten to correct the header checksum for some of those.

[sinamas]

judge sent me some test results on DMG (a while ago actually, I've been a bit absent) which indicate that there are differences (between DMG and CGB) in more areas than anticipated.

It'll probably be some time until I can get DMG accuracy up to par with CGB, so for now I'd just like to make it clear that CGB emulation in Gambatte is likely to be more accurate than DMG emulation.

I haven't done any releases in a while, but SVN tends to be quite usable for those that can manage to get it compiled on their own. Browsing the SVN logs probably gives a good hint of what's going on development-wise.

[DancemasterGlenn]

Glad to hear that activity continues. Can't wait for another release, whenever it happens.

[sinamas]

I recently got a mail from someone wanting to use the hwtests in Gambatte SVN to compare emulator accuracy. I think maybe my reply to that could be of some general interest, so I'll post it here too:

The hwtests aren't really meant for comparing emulator accuracy. They're mostly intended as a help to myself to protect against regressions. They focus mainly on edge cases and one would have to know how to use them right and interpret their output to make sense of them. Currently they mainly reflect the behaviour of a CGB-01, I'll probably be adding tests that cover a DMG model sometime in the future. Please don't bug any other emulator authors if you find tests that seem wrong on their emulators. Emulator development isn't generally driven by competition, so setting up comparison tables or similar things is more likely to put some authors off than make them want to make improvements to their emulators.

[sinamas]

Gambatte SVN Snapshot Exam Special!

Don't expect these to work or anything, they were spontaneously compiled in a moment of extreme exam preparation boredom.

gambatte_qt_svn146_linux_i386.gz -- built on debian testing
gambatte_qt_svn146_macx_ppc.dmg -- don't expect this to work an an intel mac, built on OS X 10.3 PPC, requires OpenAL
gambatte_qt_svn146_win32.exe
gambatte_qt_svn146_win32_d3d9.exe -- this one isn't really dependent on d3d9, but vmware craps out badly on the runtime linking/loading of d3d9 for some reason, so try the other one (which excludes the Direct3D blitter) if this one fails.

gambatte_svn146.tar.gz -- source code

[erise]

Thanks for the Mac OS X snapshot. I actually ran it on my Intel Mac mini on Mac OS 10.5 at full speed. There was one crash, but other than that it was perfect. Very impressive!

[exdeath]

A bug found in gambatte.

If you run the gambatte and load a rom, the rom will to the list of recently played games.

If you then, close the gambatte, and get the same rom file, grab and put in the gambatte.exe file, the emulator will start and the rom start too, the rom will be placed again in the recently played games list. If you had a gamesave in this rom, the gamesave will be not there anymore. You will need to enter in gambatte load the rom again to use the savedgame.

[sinamas]

Thanks for the Mac OS X snapshot. I actually ran it on my Intel Mac mini on Mac OS 10.5 at full speed. There was one crash, but other than that it was perfect. Very impressive!

Cool! Does Rosetta generally have high compatibility or is it largely hit and miss?

How did it crash? Is it reproducable? If it's not Rosetta-related I'd have my bets on it being OpenAL-related as I'm not terribly impressed by what I've seen from OpenAL so far. For instance the linux library has a several years old bug that causes a segfault if you close the device properly (meaning you set the current context to NULL, and destroy the previous context) and open it again. Granted, the library itself doesn't seem to have been updated in a couple of years either (which hardly makes the situation any better). Last I heard it needed lots of cleaning up and rewriting and I guess noone ever got around to such a large task, and noone wanted to work incrementally on it in its current shape. Well, the other implementations may be in better shape, but from what I've seen the querying of buffer status seems to be pretty unstable on all ports (sometimes inexplainably reporting nonsense number of buffers) making it far from ideal for low-latency streaming purposes at least. I'm sure I'll get around to writing a proper Core Audio backend or similar eventually. There's otherwise plenty of room for incompatibilities between a G3 iBook running Panther and an x86 Mac running Leopard (and the emulator through emulation no less).

A bug found in gambatte.

If you run the gambatte and load a rom, the rom will to the list of recently played games.

If you then, close the gambatte, and get the same rom file, grab and put in the gambatte.exe file, the emulator will start and the rom start too, the rom will be placed again in the recently played games list. If you had a gamesave in this rom, the gamesave will be not there anymore. You will need to enter in gambatte load the rom again to use the savedgame.

Ah, foiled by backslashes. QFileInfo to the resque. Good find!

[erise]

Thanks for the Mac OS X snapshot. I actually ran it on my Intel Mac mini on Mac OS 10.5 at full speed. There was one crash, but other than that it was perfect. Very impressive!

Cool! Does Rosetta generally have high compatibility or is it largely hit and miss?

How did it crash? Is it reproducable? If it's not Rosetta-related I'd have my bets on it being OpenAL-related as I'm not terribly impressed by what I've seen from OpenAL so far. For instance the linux library has a several years old bug that causes a segfault if you close the device properly (meaning you set the current context to NULL, and destroy the previous context) and open it again. Granted, the library itself doesn't seem to have been updated in a couple of years either (which hardly makes the situation any better). Last I heard it needed lots of cleaning up and rewriting and I guess noone ever got around to such a large task, and noone wanted to work incrementally on it in its current shape. Well, the other implementations may be in better shape, but from what I've seen the querying of buffer status seems to be pretty unstable on all ports (sometimes inexplainably reporting nonsense number of buffers) making it far from ideal for low-latency streaming purposes at least. I'm sure I'll get around to writing a proper Core Audio backend or similar eventually. There's otherwise plenty of room for incompatibilities between a G3 iBook running Panther and an x86 Mac running Leopard (and the emulator through emulation no less).

I have Intel-native versions of everything I use, so I don't have a ton of experience with Rosetta, but I think compatibility is good for most things. Before I got Office 2008 though, I ran Office 2004 in Rosetta and everything worked fine. It was slower than on my PowerPC laptop, however. If you add more high-end features in the future (like HQ4x graphics filters, for example), I doubt that Rosetta would be fast enough for Gambatte on Intel Macs. It takes about 8 bounces in the dock to start on my 1.66 Core Duo Mac mini compared to about 3 for the Intel-native KiGB.

The crash occurred when I was playing a Game Boy game in Gambatte then opened a Game Boy Color game. The game didn't start playing, however, and the cursor turned into the spinning beach ball cursor. I waited about 20 seconds before I just force quit Gambatte. I couldn't reproduce the crash, however.

[sinamas]

New snapshot.

The rough SVN log is available here.

gambatte_qt_svn150_linux_i386.gz
gambatte_qt_svn150_macx_ppc.dmg
gambatte_qt_svn150_win32.exe
gambatte_svn150.tar.gz

EDIT: Windows binary updated. Direct3D9 should work now.

[franpa]

what does the normal windows build use? direct x 8?

Direct x 9 build crashes... i have direct x 9.0c june 2008.


EDIT: In zelda oracle of ages/seasons, links sprite jitters when moving diagonally.

[sinamas]

what does the normal windows build use? direct x 8?

Direct x 9 build crashes... i have direct x 9.0c june 2008.

Which means it's not just my vmware setup being bitchy. And... after some poking around I found the problem. The function pointer typedef for Direct3DCreate9 was missing the WINAPI macro, which for some reason didn't matter when I built it on a different setup a few months ago.

I've uploaded a new binary and edited the previous post. This one should work on everything from win95 with dx7 but still support Direct3D9 if available.

EDIT: In zelda oracle of ages/seasons, links sprite jitters when moving diagonally.

Yeah, it does that on my CGB too, unless you're referring to something more severe than what I'm seeing.

[DancemasterGlenn]

In help->about these versions say Gambatte Qt svn, would it be possible for them to show revision numbers as well? I know it's written right in the filename, but I'm shortening it back down to gambatte_qt for no necessary reason and having the revision number in that menu would be super-cool.

Also, thanks so much for putting these builds out, I've missed seeing gambatte updated (on the forum, at least).

[Nach]

would it be possible for them to show revision numbers as well

If someone can come up with a way to autoscript that, I'd like to know how they did it.

[DancemasterGlenn]

Bah, I should have known it wasn't that simple. If it's too much trouble then there's no need to bother... I should really remember stuff like that anyway.

[sinamas]

would it be possible for them to show revision numbers as well

If someone can come up with a way to autoscript that, I'd like to know how they did it.

Well there's SVN keyword substitution, but that only works with per file revisions.

You could always just do this before packaging:

Code: Select all

sed s/Gambatte\ Qt\ svn/Gambatte\ Qt\ SVN\ revision\ `svnversion`/ gambatte_qt/src/gambattemenuhandler.cpp > gambatte_qt/src/gambattemenuhandler.cpp

It would probably be more convenient to just write a simple script that copies everything to a properly named directory, does the SVN revision replacement, and puts everything into a properly named tar-archive that you would build from and release as source archive.

I'll do this if I remember to the next time I do a snapshot.

EDIT: in case it wasn't clear, "`svnversion`" is automatically replaced by the output of the svnversion program (in bash at least). If you prefer you can use "$(svnversion)" instead. With a non-international US keyboard layout you probably would.

[Nach]

Yeah I know about that, but I'm looking for something fully automated as part of the build process, so I can give out binaries that contain the version number, and have it automatically included, and also work right when I pack it up for release.

[DancemasterGlenn]

If it doesn't exist it should... obviously I thought it existed for some reason ^_^()

[creaothceann]

I can't configure the keys... the value is almost instantly overwritten with this:



Even unplugging the mouse doesn't help. (WinXP SP3, Logitech mouse)