’Cause all games were better on the GBC

You are not logged in.

#1 2017-05-17 20:46:47

Registered: 2015-12-05
Post 41/71

Palette Maps / Tileset Palette loading code?

Hello! I'm currently working on a large scale hack using Pokered, and one of the main things I wanted to do was add color (no disrespect to the existing full color hack, but I wanted to keep SGB features and do a few other things a little different) So far, I've been able to get the game to load pallets no problem using some code heavily based off the yellow disassembly (modified to handle object palettes a bit differently) ... but the main issue I'm having is applying palettes to tilesets.

Now, I've done a fair bit of research on this. To the best of my knowledge, I understand that the palette map for the colors on screen are stored at the same location in VRAM as the tilemap, but in Bank 1 as opposed to Bank 0. I've also read that the palette map data is meant to be loaded before the tilemap data (please correct me if I'm wrong on this) ... and have learned what the various attribute bits do for the values in this palette map (in the case of Pokemon, we wouldn't want to set anything more than the palette) As an experiment, I created just a massive array and was able to apply a single palette map across the whole screen by loading it in to VRAM Bank 1 at $9800 (similar to how Yellow does it, I guess), which you can see below:

(please ignore the sprite weirdness, my object palette code is a bit wonky at the moment)

Anyways, I've looked at both the disassembly of Pokecrystal and Pokered-GBC...both seem to have one principle in common, and that would be the palette maps. This seems pretty simple's a list of color values to be assigned to each individual tile in a tileset. The problem is, looking at the disassemblies of both of these things, I have no real idea how these palette maps are actually loaded or put in to practice. I've seen functions which seem to load them in to various memory adresses and attribute maps and all kinds of stuff, and for this part the two disassemblies seem to do this very differently...but truth be told I'm not seeing anywhere how this palette map is actually used to form a background tilemap. I'm actually not even sure where to begin on this sort of thing, doubly so since no debugger I've seen seems to be able to view anything other than VRAM Bank 0 in memory... I've been doing experiments for a few days now, but I decided to finally just bite the bullet and ask for help, since I think you guys have a much better understanding of how this works.

So far, I have modified the tileset header and its loading code in red to have an extra field to point to a palette map definition just like Crystal, but that's as far as I've taken that. To my knowledge, Crystal seems to use very different map loading code than Red, and Pokered-GBC appears to do things in such a weirdly hacky way that I'm just having a difficult time understanding how that all even works at all (again, zero disrespect to the hack creators on this---you at least made something that works, which is more than I can say right now!) ... again, I just don't even know where to even begin tackling this thing. I'm really lost, but feel like I'm so close :(

Super appreciate any insight I could get on how to go about this....thanks a ton.

Last edited by KeiTaRo (2017-05-17 20:49:31)


#2 2017-05-28 23:20:43

Registered: 2015-12-05
Post 43/71

Re: Palette Maps / Tileset Palette loading code?

just wanted to update on this:


I was able to get it working!


....sort of. Currently it does not scroll the colors and only applies the map for the current section of the screen that it is on :P but I think know how to go about fixing that, looking at some code in Crystal. it also gets overwritten when the start menu is opened, so I will have to look in to that too...

Main issue I think I'm going to run in to is that currently, I have the Attribute Map for the colors being stored to the exact same place as wTileMapBackup2 ... since it takes up the exact same amount of space I need. Problem is that I presume wTileMapBackup2 is overwriting it whenever I enter a new warp, which is a problem. I'm curious if wTileMapBackup2 is actually really used much by the game at all? As in, couldn't I just have it exclusively use the normal TileMapBackup? I'm having a really hard time finding enough empty space in wram (360 bytes, or 20 * 18) to create an all new entry for my AttrMap, but equally having a hard time finding anything I can safely overwrite...would anyone have any advice for this?

Last edited by KeiTaRo (2017-05-28 23:22:39)


Board footer

Powered by FluxBB