NitroPaint Bug Hellscape

Lately, I have been working to make NitroPaint's editor more intuitive. Namely, removing the restriction of only being allowed to have one file of each type open at a time (for 2D formats). This restriction exists mostly for historical reasons (from NCEditor) and that the relationships between different files that use each other (e.g. NCGR to NCLR) becomes more confusing. I think that now, though, this can be resolved with the concept of "active files."

Active files are merely just an open file that is marked as active, and this file will be used for displaying higher-level files. For example, with multiple palette files open at a time, the other graphics windows need to use one of these open palettes. Under this new system in the works, they will use the palette that is marked as active. This way, multiple palette files can be open at a time, and the user can switch which palette is active without having to bump the other one out of the editor.

Currently, I have been working to lift the restriction of screen files. Quite honestly, the restriction did not make sense for these files, and it really only exists since it did in NCEditor. Because of this, it made the most sense to me to try to tackle first. I wrote up some code for enumerating editor windows to pick out editors of specific types, and used this in places where a single screen editor were hardcoded.

While testing the code for multiple screen files, though, I uncovered a bug while testing image importing over screen files of nonzero palette base. This situation shows up, for example, in the menu backgrounds of Mario Kart DS. The fact that this went unknown thus far honestly surprises me. The actual cause of the crash though was unknown, and it manifested itself as a heap failure while freeing the color tree after creating the color palette. This fact could have been quite concerning, potentially indicating a core color reduction flaw. To find the real cause of the bug, I switched on Page Heap to catch out of bounds pointer accesses easier. In doing so, a new bug showed up in the file detection code. The specification file parser that runs when detecting files had a misplaced condition in a loop that would cause the file to be read out of bounds by a byte. Fixing this then, I was able to sort out that the bug was really in the screen bitmap import code. It really looked like this code had not been updated in quite a while, having remnants of some very old character map color reduction code left over. The code was faulty, calling on createMultiplePalettes with a palette base, while its internal palette buffer was not allocated to accommodate. Setting this to 0 then stopped it from writing the palette out of bounds, and order was restored to the world.

This isn't even to mention a bug recently pointed out to me by BagBoy of Pokemon ROMhacking, pointing out an issue in the cell bitmap import feature. I've yet to thoroughly investigate why this happens, but I do suspect the issue may have something to do with mapping modes, which have historically given me a rough time trying to get graphics to display correctly for all games.

This all goes to show that there are still plenty of subtle issues that may be lying under the surface, just waiting to rear their ugly heads.