I just swapped it to another palette and cleaned up the gfx (stray pixels that looks out-of-place when colorized).
By the way - exactly HOW did you ’fix’ the short-comings of the original hack?
How I did it is explained in this thread:
http://www.romhacking.net/forum/index.php?topic=15989.msg358910#msg358910
/dACE
Both the graphics corruption and crashes came down to how he was doing the colorization. He was coloring the entire screen every frame in the interrupt handler, taking up to 10k cycles (if the screen was scrolling at the time). The time window for the interrupt is only 2k cycles, and after that VRAM becomes off limits and access will cause data loss or memory corruption. I moved the colorization code out of the interrupt handler and colored blocks in the update list (and in the interrupt handler made updates load color data as well), not the entire screen (reducing the work per frame from 1024 background tiles to 64). For convenience sprites are colored every frame, but that was moved outside the interrupt handler as there's a sprite memory buffer anyway and there are only 40 of them. Various additional things were done to implement fading, freezing, etc.
EDIT: After chatting with toruzz, it appears he had implemented the superior method I was planning to implement in the future. The above, where I color the tiles separately from loading the tile numbers from ROM, is one of several things I took an "if it ain't broke don't fix it" approach to, leaving data and algorithms from EJRT in place unless they needed to be changed to work properly (though all but a single EJRT function has been replaced with new code in EJRTQ). The superior method is to add color information to the metatile and metasprite tables themselves, rather than adding the coloring in a separate step later. This is the proper method and how Nintendo would have implemented it themselves if they'd actually produced a full color version; it will also allow modders to do more complex things in mods based on EJRTQ, which is the reason I'm going to implement this in the future.
January 21, 2019, 10:00:11 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
1st, the arm cannon has received a thorough redesign from the original game and IMO it looks off. Something about the coloration and that horizontal line down the middle doesn't work for me. I went back to the native graphics and saw that they are totally different for the cannon. I like the original better.
Also, the flying enemy--I think it's called a Yumbo. His entire body is blinking for some reason. The other enemies don't have that effect and he didn't blink in the original game.
Huuh. I never noticed the arm cannon thing, nor that, while testing it, I also noticed that the cannon looks different before you first switch to missiles and all other times during the game. It appears the horizontal line thing is due to the differing ways the GB and GBC prioritize overlapping sprites. There is actually no difference whatsoever in the sprites between the two (as can be seen when facing to the left), but in GBC the cannon is drawn on top of the tile to its lower left when facing to the right, resulting in a few more pixels of the cannon being visible than in the GB (in GB the cannon is behind the lower left tile). I'll add it to the list and see if I can fix it by reordering the sprites.
As for the Yumbo, my assumption is that that was intended by EJRT, so I have not changed it. In general I don't modify things that seem like graphic design decisions.
Topic: Metroid II EJRTQ Colorization (Read 22617 times)