Dolphin, the GameCube and Wii emulator - Forums

I figured out cout eventually, and went ahead and started a bruteforce solver. After some calculations, I decided it would take at least 10^34 years to test all possible keys, so I gave up.

I finally solved a month's-long problem with my GB emulator. For the longest time I thought it was something wrong with my emulated CPU (it wasn't I should have trusted Blargg's tests when they said everything was ok). Turns out the issue was with the way I was emulating the LCD. Apparently the way a game scrolls the background is applied per-scanline (just like the Window). Up until now, I was able to get away with just rendering the whole LCD frame at every VBlank and applying the scrolling then. Changed some code, and boom, games like Super Mario Land play perfectly (well, almost, still no DAA instruction). I need to come up with a better method of generating the background tile data, but otherwise it's all good for now.

Also implemented one type of MBC1 (no RAM banking, no battery saves), so more games can boot. Just need to get 8x16 sprites working, and then I can finally play games like Battle Arena Toshinden (a classic game I was introduced to by my friends way back before any of us had a GBA). Also booting Bomberman GB (spent hours on this one as a kid). My GB emu's advanced enough where I feel like I'm programming my own nostalgia Lastly decided on a name: Game Boy Enhanced (uncreative, I know). Gonna focus on accuracy (duh), and enhancements like scaling filters, possibly custom palettes, a thorough debugger, and other stuff.

Sweet!!

Please allow custom sprites. Custom 4x-16x original resolution colour sprites. Nothing would be too hard to redraw, and you could probably find some way to detect them as a post processing system and then overlay them, as opposed to injecting them.

Custom sprites shouldn't be too hard, in theory, as long as the person making them knew which sprites they want to replace. :p

Since every game is different, the original sprite data sitting on the ROM isn't always going to be in the same place, so DMA transfers to OAM won't be the same either. Because of this, injection into the ROM itself would be a hassle, and would be per-game most likely. Generating a hash of the sprite pixel data when it reaches OAM and then changing that pixel data if the hash matches the sprite we want to replace would be fine. But instead of doing any injection, you're quite right, it would be easier to just "paste" the new sprite on top of things. If the hashes matched, we could just not draw that sprite, but load up the custom sprite at the X, Y coordinates. Custom sprites would definitely be down the road, but a cool feature nonetheless

Right now, my emulated LCD needs a bit of TLC and clean-up. I've been breaking and bashing together parts on a local branch I set up. Ultimately I need to revamp a lot of the code to be more readable and reusable, especially if I want to get scanline rendering working properly. As I said above, I implemented per-scanline rendering for the background, but the Window and sprites are done per-frame atm (which is not how a real GB does rendering btw, which is why some graphics aren't 100% correct yet). I'm getting there though.

So I've made a local branch to deal with custom sprites. It's highly experimental, but I've at least taken the first step. I've been able to dump sprites to image files named after their hash. The list of known sprite hashes is currently stored, so now all I have to do load the data from modified image files. Nothing to show now (I mean really, all I have is a folder full of 8x8 BMPs) but if I do this right, it should be possible to completely colorize GB games with no limits on the amount of colors (aside from being 32-bit ARGB). Games could be colorized to an even greater extent than the Super Game Boy, or even regular GBC games. I could do this for background tiles as well. Pictures of this tomorrow, probably, if all goes well.

EDIT: *Laughs maniacally* It's finished, and it was easier to implement than I expected. Pictures incoming tomorrow for sure, blog post about this as well.

EDIT 2.0: Time for a fake bump. I've gotten it where Game Boy Enhanced can dump and load both sprites and background tiles, so it's possible to completely recolor games (the ones that work anyway). It takes a while to get everything right, since I'm only dealing with 8x8 sprites (Game Boy Enhanced doesn't support 8x16 sprites yet), so I have to really know what pattern I'm looking at when I'm editing these. Only had enough time today to do a bit of Tetris, but it's working for other games. And so today I have achieved something that no other Game Boy emulator has done before (to my knowledge, at least)



On second thought, a video would be better proof, but that's gonna have to wait until I write a blog entry on this.

That is amazing! Great job Would this allow sprites out of the color limitations of the gba, I'm sure it would but I'm just checking.
Edit: Not gba, gb/gbc.

With this method, you're only limited to however much color information you can represent with 32 bits of data (16,777,216 colors for RGB's 24 bits and then add in alpha transparency for the remaining 8-bits). It would definitely exceed the color limitations of the GBA. The only issue is the sprite size (the GB screen is only 160x144 btw) since some games have really tiny characters, but you could work something out if you're creative enough. Backgrounds are definitely more flexible since they're larger and often take up tens of 8x8 tiles, whereas a sprite usually has 4 or 5 8x8 or 2 or 3 8x16 sections.

And don't forget, it's more than just recoloring games; these sprites are completely custom and can represent anything you want on-screen. It leaves the ROM's code completely untouched, so no hacking is necessary. You could come up with some pretty nifty mods if you had the time

Well that's good. I'm sure there are some people who wouldn't mind recreating games in their own artwork.

Here it is in action:

http://www.youtube.com/watch?v=3f3KbOF5hsY