Post by DarkKobold on Jan 16, 2020 4:52:19 GMT
Thanks, this is really helpful. I have a couple questions about your STM implementation:
Similarly with the STM capability (that HuC 3.21 doesn't support) ... it is just an optional alternative to using MAPPY files, and the data produced, and the way that you use it hasn't really changed since HuC 3.21.
What *has* changed is the new last parameter to set_tile_data(), which is used to tell the map functions whether you're using 8x8 or 16x16 tiles ... but you can use another HuC library call to set that.
Anyway ... back to the actual question ...
#inctile(leveltiles,"maps/tileset_vacuum.png");
#inctilepal(leveltable,"maps/tileset_vacuum.png");
here's the code to load them:
set_tile_data(leveltiles,228,leveltable,11);
load_tile(0x800);
Somehow, load_tile(address) also sets some flags as to where the tiles start in memory? (esp because we use 16x16 tiles)
So now I replace these with cd_loadvram(int ovl_idx, int sector_offset, int vramaddr, int bytes);
So, if I'm understanding the code and method, you would create an assembly-language file, let's call it tileset_vacuum.asm, with one line in it ...
.inctile "maps/tileset_vacuum.png"
Then you assemble/convert the data with pceas -raw -s tileset_vacuum.asm and the assembler will produce the file tileset_vacuum.pce and show you how much data you've created.
You then add tileset_vacuum.pce to your list of files that you add to isoLink, and note which overlay number it is.
To use the data in HuC ...
#inctilepal(leveltable,"maps/tileset_vacuum.png");
set_map_pals(leveltable);
set_map_tile_type(16);
set_map_tile_base(0x800);
cd_loadvram(<your_overlay_number>, 0, 0x800, 228 * 128);
You can store and use lots of different tilesets in the same overlay file by using the sector offset parameter to cd_loadvram(), but figuring out those offsets can be a PITA when you start to deal with a lot of tilesets (or other assets) in a single file. That's when developers either start using container-file formats, or you do what punch has done, and you process a list of data files and output a header file that you can include, just so that you know where data is within an overlay.
Does that make sense?
Heck, I'm writing this off-the-cuff from looking at the HuC and library source ... does it even actually work if you try it?
Below shows the tile graphics data for both - looks identical for relevant tiles.
However, the palette data is not getting used properly, and some tiles just aren't getting referenced properly. This image shows three different scenarios -(left) The code loaded as is, for CD. (middle) the way it should look, directly from the HuCard. (right) the code with all palettes forced to be the same, since the background *currently* only uses palette 0.
Here's the code, it's not very complex.
#ifdef CDVER
cd_loadvram(OVL_BACKGROUND, 0, 0x1800, 154 * 128);
set_map_tile_type(16);
set_map_pals(backtable);
set_map_tile_base(0x1800);
#else
set_tile_data(backtiles,154,backtable,1);
load_tile(0x1800);
#endif
for (temp1=0; temp1<16; temp1++) load_palette(temp1,back0pal,1);
EDIT: This code is brain-dead in its implementation, but it works good enough! THANKS A TON! (and yeah, diamondspr is just a 32x32 sprite. HuC wouldn't let me use a null).
#ifdef CDVER
set_tile_data(diamondspr,154,backtable,16);
load_tile(0x1800);
cd_loadvram(OVL_BACKGROUND, 0, 0x1800, 154 * 128);
#else
set_tile_data(backtiles,154,backtable,16);
load_tile(0x1800);
#endif
load_palette(0,back0pal,1);
I'd also like to note that I'd only used the last argument of the set_tile_data as the number of palettes. It's apparently the 8/16 bit switch. It.... doesn't seem to really do anything, because I clearly wasn't setting it properly.