[MathUser2929]

Nope, that was way long time ago that I made that hack, and it was on another computer. So I don't have the gps file. Anyway, gbcolorizer was pretty limited on my hack, I didn't get to pick many pallette sets and it didn't allow me to choose the colors for every single sprite. So the first worlds have more color than the later levels. If I could have chose what colors to use for every sprite I wouldn't have used red water in World 2. I guess the red water kind of makes sense for having dead fish in it tho, and the land fish I created that don't want to be in the water.

I don't think that guy was using gb colorizer on that page you linked. Heck, he might have just been recolorizing pictures as there don't seem to be links to any ips patches.

I dunno if the other guy got my pm's but here's a link to the enemy rearrangement hack. You can maybe use it to figure out where enemies are so you can restore them to their original arrangement.

http://www.angelfire.com/la3/goldenroad15/hacks.html

[Drakon]

All bugs fixed thanks to the amazing programming skills of spikeman.  I cleared the entire game on the real hardware using my devcart and there's no issues anymore.  I'm now editing the game ending text to include contributors.

I restored 97% of the stage layouts (the rest is so small I can't be bothered to find it) as well as some of the changed graphics.  I did a really quick restoration just copying and pasting hex from the black and white rom, I think doing this changed the pallettes assigned to certain tiles so a lot of graphics in world 3 have funky changing pallettes haha.

[MathUser2929]

If I'm included in the ending can you use my current username, MathUser instead? Thanks.

[Drakon]

This is a romhack of the marioland 1.1 rom turning the game into full colour.  I found a colorized version of the game on romhacking.net that had been made using the gb colorizer.  The gbcolorizer code is unfinished and games made using it don't run on real hardware or certain emulators.  With the help of bgb emulator, spikeman, and a lot of research into gameboy assembly language I give you this improved hack.  This version makes the colourized rom go from 1mbyte down to 128k, this hack runs on actual hardware and all emulators flawlessly.  All bugs and glitches that were in the previous release have been fixed (there were a lot of bugs and glitches).  There's the occasional drawing glitch giving you the wrong pallette on tiles once in a blue moon but the glitches are so small they're not annoying at all.  The reason why there's minor drawing glitches is because of the nature of the inserted colorizer code.  This's as good as you can get without completely disassembling the entire rom, and truthfully I never imagined we'd get it this good.

Testing on real hardware was done using my home-made gameboy dev carts.  I'll release the rom / patch once I get permission from all people who contributed (this was a big team effort).  The biggest contributor was spikeman he fixed all the programming issues I wasn't able to fix, he's one amazing assembly programmer.  This game only runs on a gameboy color, gameboy advance, or gameboy player, it won't run on a super gameboy or original gameboy since it's programmed as a gameboy color game.

[Drakon]

If I'm included in the ending can you use my current username, MathUser instead? Thanks.

Gah I put it as hiro1112, I can change it to mathuser since that's the same length.

[MathUser2929]

Remember to make a ips patch out of it, as direct ROM posting isn't allowed here. Zip up the patch, with maybe a readme, and submit some pics and the zip to the main site. Then you can track downloads and it'll be where people will see it without having to come in the forum.

[Artemis]

It looks very good, however, one question: The water in the water world is red whereas the lava in the pyramid as well as the fireballs are blue. Shouldn't it be the other way around?

[Drakon]

It looks very good, however, one question: The water in the water world is red whereas the lava in the pyramid as well as the fireballs are blue. Shouldn't it be the other way around?

I didn't do the colorization, and when I restored level layouts and graphics I may have also changed which tiles get which pallettes which is possibly why world 3 looks so funky.  If someone wants to make an improvement they're welcome to, I'm fine with this one how it is.

*edit*

Here's the patch, it's for the marioland 1.1 rom:

http://www.mediafire.com/?hh8682trdyeiey1

[RetroHelix]

Thank you very much for this. Will put this game on the gba in the bathroom so every family member or friend can enjoy this classic game in full color and get nostalgic

[bradzx]

I wonder if you can do Mario Land 2 in color.  Can you do that, Darkon?

[Drakon]

I wonder if you can do Mario Land 2 in color.  Can you do that, Darkon?

If it's already been colorized using the gbcolorizer then yes.  Really spikeman figured out all the difficult stuff.  I can't be bothered to spend the time colorizing an entire game.   If someone can colorize a complete game using gbcolorizer I'm confident me + spikeman can get it working right.

[Spikeman]

If I recall, someone colorized the first level of Marioland 2, but didn't get further than that. I'm confident I could get it working if someone wanted to take care of the actual colorizing work (I'd handle the asm work). This is something I'd be interested in doing, since Mario Land 2 is an awesome game, and I actually have a bit of experience hacking it.

Also, I may try to create an improved version of GB Colorizer that isn't super buggy, or at least publish a document on how we applied the fixes we did to this game. I think the main problem with Colorizer is that it tries to work for every GB game, where really each game draws graphics in a unique way. Currently what it does is insert colorizing code into the Vblank handler, and updates the colors of each tile and sprite every time Vblank happens (every 50 miliseconds or so). It doesn't need to happen nearly this often, which causes a lot of slowdown. Also, it's not very smart about finding what code/data in bank 0 can be replaced, which causes a lot of issues by overwriting important stuff. Ideally, I'd be able to come up with program that can relocate code/data in bank 0 in an intelligent way, but realistically, each game will probably have to be hacked individually with their quirks handled on a case by case basis. So to really colorize a game you'll probably need ASM experience or the help of someone who does.

Anyways, if I start work on a new colorizer I'll post a topic in Personal Projects, no need to derail this thread any further.

[MathUser2929]

http://www.romhacking.net/hacks/145/

I think this colored version of Super Mario Land 2 is done, but it has a problem. The graphics mess up when completing a level so you need to reset to fix it. So if you guys wanna work on that and fix that one problem then you can have another project.

And yes, a new version of the colorizer would be nice. Maybe there'd be more colorization hacks if the colorizer wasn't as glitchy.

[Drakon]

http://www.romhacking.net/hacks/145/

I think this colored version of Super Mario Land 2 is done, but it has a problem. The graphics mess up when completing a level so you need to reset to fix it. So if you guys wanna work on that and fix that one problem then you can have another project.

And yes, a new version of the colorizer would be nice. Maybe there'd be more colorization hacks if the colorizer wasn't as glitchy.

It's more interesting than metroid 2 I guess I'll look at marioland 2 next.  Also I burned and played marioland 1 colour on my mbc5 devcart it runs fine on that too.

[Spikeman]

I just submitted the patch to the hacks database, so it doesn't get lost in the depths of the forum.

Also, it looks like we're planning to work on Metroid 2 next, since the game is a bit simpler than Mario Land 2 (read: there's empty space in bank 0, so we won't have to move as much around to fix the bugs). Once we confirm that our method of fixing the colorizer code works we should be able to fix Mario Land 2, and I'll upload a document on how to apply these fixes for anyone who wants to Colorize a game in the future.

[Drakon]

It's still a lot of work uhg.

[MathUser2929]

I imagine playtesting Metroid 2 can get time consuming too, unless you are an expert at it. Unless you can use savestates to test it, not sure if that's possible.

[Drakon]

I imagine playtesting Metroid 2 can get time consuming too, unless you are an expert at it. Unless you can use savestates to test it, not sure if that's possible.

Yup bgb emulator recreates the real hardware well enough, I'd just savestate it.  Although once we relocate the colorizer code out of the main code it shouldn't even need a full test, since the original code will no longer be over-written.

[Zoinkity]

That's mighty impressive work!

About the only complaint I can think of is that it takes a few seconds before the colorizer kicks in on full-screen reloads (starting a stage, enterig or exitting pipe, etc) but it's not anything to even grumble about.

[Spikeman]

That's mighty impressive work!

About the only complaint I can think of is that it takes a few seconds before the colorizer kicks in on full-screen reloads (starting a stage, enterig or exitting pipe, etc) but it's not anything to even grumble about.

Yeah, unfortunately that's a side effect of the way the Colorizer works. In simple terms, it's because Colorizer is meant to work on many different games, so what the code does is basically look at the graphics loaded and see what palette is needed - and it does this every frame. Ideally, we'd have a custom implementation for every game that only updates the palettes when new tiles or sprites are drawn - eg. when an enemy is spawned, or when you scroll the screen.

I have some ideas for a toolkit that would help this, but as it stands, it would involve recoding the entire colorizer code, which isn't really worth it for such a minor complaint, no?