It is currently Mon Dec 11, 2017 12:12 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sun May 04, 2014 7:33 pm 
Offline

Joined: Sun Jan 19, 2014 5:15 pm
Posts: 50
Shonumi's Game Boy Enhanced emulator project can replace graphics in Game Boy games.

Kirby's Dream Land gets a color makeover here:
https://www.youtube.com/watch?v=kbd7lGXfRxI

http://code.google.com/p/gb-enhanced/
http://6bit.net/shonumi/2013/07/18/emul ... d-sprites/
https://forums.dolphin-emu.org/Thread-p ... ad?page=18


Top
 Profile  
 
PostPosted: Wed Oct 15, 2014 5:43 am 
Offline

Joined: Mon Apr 07, 2008 6:08 pm
Posts: 327
Location: Missouri
Here's a crazy thought: Could that emulator be used to take the color out of GBC games?


Top
 Profile  
 
PostPosted: Wed Oct 15, 2014 5:48 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19328
Location: NE Indiana, USA (NTSC)
R = G = B = .3R + .6G + .1B also takes the color out of games for any platform that uses RGB color.


Top
 Profile  
 
PostPosted: Wed Oct 15, 2014 1:42 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
But that wouldn't be the same as using original GB palettes, right? (I imagine that's the idea here)


Top
 Profile  
 
PostPosted: Wed Oct 15, 2014 9:34 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 266
It would also be possible to do something like:

1) Examine each of the color palettes, calculate the brightness of each color
2) Based on the brightness, try to map this to an equivalent DMG shade of gray when drawing
3) Hope for the best

It's something that crossed my mind, although I'm not certain how well that would or wouldn't work. Can't say until I've tested it.

BUT, I think strat was asking something more along the lines of "can GB Enhanced replace a game's original colorized graphics with my custom grayscale graphics?" The answer is complicated. Yes, in practice one should be able to dump the game's colorized graphics, convert them to grayscale in an editor, and have GB Enhanced upload them when it plays a GBC titles. GB Enhanced doesn't care whether the uploaded images are grayscale or not; it's just pixels to the program, so any style will work (neon, pastel, metal, etc).

However, GB Enhanced can only experimentally dump and load sprites from GBC titles (and BG dumping/loading hasn't been implemented at all). The whole process of adequately hashing GBC tiles is more involving than DMG tiles, and I never got around to finishing custom graphics support for GBC games. The work is mostly complete in a separate branch, but I started working on the successor to GB Enhanced (unsurprisingly called GB Enhanced+, or GBE+). I'm aiming on making it a DMG/GBC/GBA emulator with the ability to replace graphics for all 3 handhelds. I'm knee-deep in GBA emulation at the moment, but rest assured GBE+ will improve upon GB Enhanced. It'll also have a GUI, which is somewhat essential for extensive editing. So what strat is looking to do will be possible, eventually.


Top
 Profile  
 
PostPosted: Tue Dec 16, 2014 8:45 pm 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
I've been working with games on GBE for quite awhile now. Yesterday I found a way around the duplicate tile problem but it's pretty much a chr hack. It works well enough though. I've also edited the source to package everything into a nice little way for releases. There are some glaring issues that I can't figure out how to fix which is disappointing. LCD brightness I think it is. The tiles dump but don't load. Not sure why...

Anyways here's an unofficial build of Game Boy Enhanced from August.
https://drive.google.com/file/d/0B5aZT1MLfWJsY185RTF3TDZBZ0U/view?usp=sharing

Looking forward to GBE-plus!


Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 7:47 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 266
When you say duplicate tile issue, I assume you're talking about the issue brought up on Google Code (involving Metroid II?) I'd love to know (on a technical level) just what exactly is causing that and how to reliably reproduce it myself. I think root may be an issue with XORing the palette data onto the tile's hash. That may not be enough to gaurantee that collisions don't happen.

In the end though, I may just have to prefix the hash with the DMG palette represented in hex (which should have been my 1st choice anyway). This is similar to what's required for dumping and loading GBC sprites (which need color palette data to be prefixed to the base hash to create a unique hash). I'll look at the code you posted later and see what's up. I may just have to break compatibility in GBE+ (but it's simple enough to add an option to for backwards compatibility).

GBE+ is going well btw. Almost 90 days of constant commits to the project have lead to a lot of progress. A lot of GBA games boot up and run just fine, and I haven't even emulated all of the DMA channels, interrupts, or timers. I never expected to get this far this soon. To put things in perspective, this time last year, I was struggling with GB sound emulation, hadn't touched the GBC yet, and didn't even have the foundations worked out for HD/replacement graphics.


Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 10:25 am 
Offline
User avatar

Joined: Thu Jan 19, 2006 5:08 pm
Posts: 748
Location: Shelton, Washington.
I would love support for SNES as well, Because I may want to enhance the graphics as an option for my SNES hacks (currently focused on SMW). Assuming 256 (255+Transparent), 16 (15+Transparent) and/or 4 (3+Transparent) greyscale colors depending on certain modes.

That is, Without killing backwards compatibility.

NES is already done by someone else, but could be better, so that's redundant, unless completion is required to a degree!

_________________
AKA SmilyMZX/AtariHacker.


Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 10:50 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 266
That reminds me, I still haven't published my general theory about Tile Replacement for systems with tile-based graphics (the SNES included). The paper I'm working on outlines the methods I used, how they are implemented, the specific challenges that require more advanced algorithms and techniques to overcome (dealing with color is a big one) and stuff of that nature. Whenever I got around to publishing it, I had hoped it would help others create support in other emulators (Sega Genesis, Wonderswan, whatever floats your boat). As it concerns emulation, I'm pretty much dedicated to working with Nintendo's portables, but my work could easily be applicable to any other tile-based console. Currently I'm laying out how the theory needs to be improved to account for some challenges specific to the GBA, and from what I can tell it is graphically similar to a lot of what the SNES was capable of, so anyone willing could hack SNES9x or higan if they had the time.


Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 11:09 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19328
Location: NE Indiana, USA (NTSC)
How do you plan for your technique to handle text in Hamtaro for GBC and GBA, Pokémon for GBA, or RHDE for NES in PocketNES on GBA?


hint: non-8x8 fonts


Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 3:00 pm 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Here is a proof of concept for pack releases. It's very hacky. IPS patching random pixel noise data over the CHR to ensure all tiles have a unique hash resulting in garbage data if played without loaded sprites. However with the new custom tiles it works as intended. Working with it graphically to make new art is very time consuming though.
v0.1 https://drive.google.com/file/d/0B5aZT1MLfWJsbFF4cDdaTDhEV1U/view?usp=sharing

edit: I will be periodically updating the demo. Maybe


Last edited by GGuy on Thu Dec 18, 2014 11:49 am, edited 4 times in total.

Top
 Profile  
 
PostPosted: Wed Dec 17, 2014 5:11 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 266
@Teeples - Unfortunately, there is no cute way to handle those cases. If the games split the text between OBJ and BG tiles, that's how the emulator will dump them and that's how users have to edit them. That would potentially result in hundreds of unique tiles. Ideally, any sort of mass editing will be through batch processing.

There is a very WIP idea I came up with as an alternative solution. This method involves post-processing the final layers to identify specific patterns. Whenever that pattern is encountered, the emulator replaces that pixel on the relevant layers. The patterns can be letters or any symbol really, so it could work regardless of whether the font character is split between tiles. After replacing the pixel data, the layers could be merged, accounting for things like transperencies and stuff like that.

It has several drawbacks in that scaled, rotated, and scrolled text may not match the pattern, rendering this method ineffective. It would also be CPU intensive, so it would better be suited as a pixel shader. But even without this method, GBE is able to handle games like Hamtaro just fine for replacing text. It's just that it might not be entirely user friendly.

@GGuy - The cumbersome nature is to be expected. You're essentially working with the CLI and/or a basic text file. I mean, if you want to dump the whole BG, you have to click on it tile-by-tile! The usability is pretty rough without a GUI.


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 12:17 am 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Oh yeah Shonumi the duplicate tile issue I was talking about is the solid color one and duplicate tiles in the CHR that are the exact same but used elsewhere in the game. I'm not sure if the door and leg thing still happens with Metroid II since that was awhile ago and I believe you changed the hashing method since then. I will check it out using the latest source build and update you.

Edit: Nope still happens.
Image

These two are hashed the same it seems.
Image

How to reproduce the issue: Dump the sprites and walk a few frames, load the dumped sprites, walk and that's it!
Output file is 993993993993993993993993


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 9:10 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19328
Location: NE Indiana, USA (NTSC)
Congratulations on finding a hash collision. There are two ways to resolve this: chaining and quadratic probing.


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 10:08 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 266
The thing is, it doesn't look like a hash collision at all on closer inspection. It's just that the hashing itself is incorrect. That is to say the algorithm generates two separate hashes (in stand-alone tests) but for some reason when applied in real-time it generates the same hash for the sprites GGuy pointed out (which I've reproduced now, thanks GGuy!).

The hashes are actually an entire recreation of the pelleted pixel data (in string format) for each 8x8 or 8x16 tile and it uses the two OBJ palletes as a 16-bit salt. Hash collisions are theoretically possible, but most likely only if you tried to match up garbage data with the real graphics. The issue seems to be that the tile in question (Samus' leg) has an OBJ tile number of $5F (data is then at $85F0), and the door has an OBJ tile number of $F5 (data is then at $8F50). For whatever reason, the code is then trying to look at one but not the other.

EDIT: On even closer inspection, it appears that GBE finds the hash for one (the door) and thinks it's similar enough to the next (Samus' leg) that it just ignores the latter. To avoid needlessly re-dumping existing tiles, GBE stores a list of which hashes have been dumped, so if it encounters the hash, it skips the dumping process. The door sprite is actually loaded into OAM (but not drawn) when you start the game right after the title screen. GBE sees this first and dumps it, the stores the hash in its list. It encounters Samus' leg sprite, hashes it, but sees that it's similar to an existing one and passes it up. The solution was to change the salt to account for OBJ palettes AND sprite tile numbers. So you were right all along GGuy :D

The solution breaks compatibility with existing dumped tiles, since the hashes are now completely different, although a feature for backwards compatibility can be added in GBE+.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group