Dolphin, the GameCube and Wii emulator - Forums

Cycle-accuracy for the GBA is more like a long-term goal. I would still have to come up with a host of hardware tests that determine whether an emulator is accurate to the original handheld or not. It certainly isn't going to happen overnight, but that's the end direction I want to take GBE+. GBE+ is far from cycle-accurate atm however. DMAs aren't clocked at all (so they happen "instantly" as far as the emulated game is concerned), some instructions don't have any timing at all, not all Wait States are emulated, and SWIs happen "instantly" too. But the system for emulating the GBA cycle-by-cycle is already established; it's just a matter of clocking things correctly.

When I import the old GBE project, the GB and GBC systems will not immediately be cycle accurate, but I do want to make it as cycle-accurate as possible. The code needs to be revamped and reworked to run on a cycle-by-cycle basis (like GBE+ does now for GBA emulation). Like most emulators, the old GBE project was cycle-based (but not cycle-accurate), in that it executed stuff, then counted how many cycles it took, then take actions like such as memory accesses later instead of on the specific cycle it should happen on.

Now, I know people like mudlord would take me to task for pursuing cycle-accuracy, but in reality, it's just easier for me to deal with emulating a system cycle-by-cycle (and for that matter, pixel-by-pixel). I've found it doesn't cover up nearly half the mistakes I made when it comes to timing. It's not like cycle-accuracy will suddenly improve the emulator with magic and rainbows (it could conceivably help with some demos) but for the most part it isn't going make the emulation experience any better. Internally, code-wise, it just makes for a more structured emulator, at least that's my opinion.

This week: so many RPGs!!




I killed a really nasty series of CPU bugs, mostly handling how the Program Counter (PC) needs to change before and after interrupts. Fixed a number of games (yeah, mostly RPGs) and made others (like Megaman & Bass) stable and playable. Final Fantasy I&II: Dawn of Souls now works without blowing up repeatedly. Lufia: The Ruins of Lore has been working for a while, but I just needed more pretty screenshots (the game is subpar btw, don't play it, even if you're a Lufia fan...) The big prize this week is GOLDEN SUN! It works pretty well, except for a host of graphical glitches due to unimplmented aspects of LCD emulation. But for the most part, it's very playable. It doesn't crash, and that's half the battle. Lunar Legend (the game with the flying cat as my sister calls it) works without major issues as well.

(12-13-2014, 01:36 PM)Shonumi Wrote: [ -> ]This week: so many RPGs!!




I killed a really nasty series of CPU bugs, mostly handling how the Program Counter (PC) needs to change before and after interrupts. Fixed a number of games (yeah, mostly RPGs) and made others (like Megaman & Bass) stable and playable. Final Fantasy I&II: Dawn of Souls now works without blowing up repeatedly. Lufia: The Ruins of Lore has been working for a while, but I just needed more pretty screenshots (the game is subpar btw, don't play it, even if you're a Lufia fan...) The big prize this week is GOLDEN SUN! It works pretty well, except for a host of graphical glitches due to unimplmented aspects of LCD emulation. But for the most part, it's very playable. It doesn't crash, and that's half the battle. Lunar Legend (the game with the flying cat as my sister calls it) works without major issues as well.

These screenshots look vivid does this emulator have an option for bright 'true' colours like VBA-M ?

If by "True Color" you're referring to using 24-bit color depth for RGB values, then yes, that's what GBE+ already does. 8-bits per color. 24-bit color helps with many of the algorithms necessary for replacing the graphics with HD equivalents, and by default it just looks nice. I currently don't have a mode that washes out the colors to make it look more like the original hardware. I'll probably enable washed out "original" colors as a pixel shader though.

(12-15-2014, 02:27 AM)Shonumi Wrote: [ -> ]If by "True Color" you're referring to using 24-bit color depth for RGB values, then yes, that's what GBE+ already does. 8-bits per color. 24-bit color helps with many of the algorithms necessary for replacing the graphics with HD equivalents, and by default it just looks nice. I currently don't have a mode that washes out the colors to make it look more like the original hardware. I'll probably enable washed out "original" colors as a pixel shader though.

Is it possible to implement even deeper color like 30 or 48bit ? Some new panels have 1.07 bilion colors.

I don't think monitors even support that

Even for monitors with greater than 24-bit color, I am not sure if SDL handles more than 8-bits per color channel.

(12-15-2014, 07:04 AM)Shonumi Wrote: [ -> ]Even for monitors with greater than 24-bit color, I am not sure if SDL handles more than 8-bits per color channel.

I don't know about SDL but newest Qt can. http://qt-project.org/wiki/New-Features-in-Qt-5.4

Cool, another reason Qt is cool

Ideally, though, I'd save non-8-bit color depths as a job for pixel shaders (that way SDL can handle it as well). GBE+ is going to have a GUI-less version (SDL only) and a GUI version (Qt+SDL), and I'd like to keep feature parity for both as close as I can. Though I'm not sure how much vividness you can expect from increased bit depths, since the values used in the end result are taken from the game's original 15-bit values. An unfiltered image will still give you only 32,767 distinct colors, until you start doing fancy blending that the GBA never did.

I'm trying to do one of my christmas holiday tasks, which is to make ML spit out images of Mandelbrot sets. Technically I've already completed the task, but it looked ugly, so I decided AntiAliasing was necessary. I've now written a function to average together pixels, and it won't compile, and the Incredibly Useful Error Message is pointing at a working bit instead of the broken bit, just as it always does.

Of course, it works if I remove the bit that tells it explicitly that the input to the colour averaging function is a colour list and let it work out it's a colour list on its own, but not otherwise. It's such a stupid language sometimes, and it's a shame we have to use it.