HD Pack : 32-character hex string support for all Tile Data, not just CHR RAM games

[torridgristle]

Some games, like Shatterhand, are CHR-ROM but have a lot of repeated content due to having multiple CHR banks where everything but one or two actors have different animations. This leads to big trouble, especially combined with the decimal tile positions but that's another issue submission.

There's already support for replacing tiles that match a given 32-char hex string, this should be available for everything because there are bound to be games that do things like Shatterhand does.

An option to use the 32-char hex string method for all hires.txt entries instead of the original tile position in the ROM in the HD Pack Builder would be fantastic.

I'm not sure if it'd actually speed anything up, but perhaps hashed tiles could be useful for it? Generating it on your own when adding entries to an HD Pack via text editor would be a hassle I imagine, so it can't be the only method of matching tiles by the tile data, but if it makes something simpler then an option to use it couldn't hurt.

Also some sort of HD Pack optimization tool that could look at the <tile> entries that use tile positions, check if that tile exists anywhere else as a duplicate, and replace the tile position with a 32-char hex string, would help with cleaning up existing HD Pack projects and also add a way for users to quickly convert a bunch of tile definitions to 32-char hex strings without hunting them down in a hex editor and copy / pasting them into the hires.txt file.

[SourMesen]

Couldn't the problem be solved by making the HD Pack Builder slightly better and making it refer to the same PNG data for multiple tiles? The tag could also be modified to apply it to multiple tiles at once? e.g: <tile>0,100+1100+2200,0F01010F,144,144,1,N Internally, the code assumes that packs use either the tile number, or the hex string representation, but not both. Doing it this way instead would require a lot less changes (essentially only changes to the code used to load hd packs would need to be modified)

One problem with using the hex representations is that it is slower than the tile numbers. Part of this is because the "key" for the tile is bigger (20 bytes vs 8 bytes), and part of it is because it requires additional data to be kept in memory for each pixel on the screen, on each frame. Both of these are optimized for CHR ROM games, and so changing this would essentially force me to make all CHR ROM packs slower.

FYI, you can right-click on a tile in the PPU viewer to copy the tile's "key" in its HD Pack format to the clipboard (e.g: TileNumber,Palette or TileHexCharString,Palette depending on chr rom/ram games)

[SourMesen]

I've started working an another slightly different idea that should give the same result. Essentially, I added some logic to the hd pack recorder to merge any identical tiles for CHR ROM and assign them lowest tile number (out of the duplicate tiles). The end result is that only 1 rule appears in the hires.txt per unique tile+palette.

So for example with the data you posted in the other issue, you would end up with just:

<tile>0,1022,FF0F2130,0,0,1,N
<tile>0,1023,FF0F2130,8,0,1,N
<tile>0,1024,FF0F2130,0,8,1,N
<tile>0,1025,FF0F2130,8,8,1,N

This behavior would be controlled by an option flag (e.g: <options>mergeIdenticalTiles).

This seems like the simplest solution to me - it keeps the hires.txt files as simple/concise as possible and has no runtime performance impact. That being said, I'm still open to suggestions if you think this wouldn't work for your scenario?

[torridgristle]

As long as you can do something like set the merged tiles entries to be the default replacement for those identical tiles, but still be able to specify a replacement for a duplicate tile afterward just in case one of the duplicates is loaded in a situation where it would look nice with different graphics.

Though if it has to be on or off with no overrides then I'm fine with having merge identical working that way. The memoryCheckConstant would let me detect the situation that would have used an identical duplicate tile and use that byte to control the graphics rather than a tile address. Though that may be slightly more involved than some people are prepared to go, as I've observed while working with someone on an HD Pack, so my own opinion on that isn't too important.