Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
hello guys,
what is the best way to copy a picture's tile data and map data when background display is from $8800 ? (signed)
1. generate signed map data with the graphics tools (I did not find this option in any of the tools) and copy tile data starting at $8800
2. generate unsigned map data with graphic tool and then convert somehow map data to signed in a second step and copy tile data starting at $8800
3. generate unsigned map data with graphic tool and copy tile (16x128=2048) data starting at $9000 and the rest starting at $8800
4. ?
Offline
it's a bit strange question. everything depends on your data format. there are some relative offsets in your tile data (which can be signed or unsigned)? in most cases unpacked tile data contains just pixel data and tile maps - just numbers of tiles. there is no much difference in copying this data by incrementing or decrementing the pointer, else if you are using some special technique like "ldpush" or similar.
Offline
Tomi wrote:
hello guys,
what is the best way to copy a picture's tile data and map data when background display is from $8800 ? (signed)
1. generate signed map data with the graphics tools (I did not find this option in any of the tools) and copy tile data starting at $8800
2. generate unsigned map data with graphic tool and then convert somehow map data to signed in a second step and copy tile data starting at $8800
3. generate unsigned map data with graphic tool and copy tile (16x128=2048) data starting at $9000 and the rest starting at $8800
4. ?
A large part of the problem is the tile data you want to convert. In my experience, RGBGFX is better for images that only contain a single palette (= DMG and single-palette CGB), whereas SuperFamiconv is better at multi-palette images.
SuperFamiconv handles "signed" map data just fine, you "simply" need to specify an offset of 0x80 when generating the tilemap. (It's a bit complex to use, but I can point at Makefile fragments for this)
RGBGFX only handles unsigned tile data, but you can get around this using "partial" INCBIN (though I'll agree it's not ideal), or a "bit 7 flip" script. The former is as simple as
INCBIN "file.2bpp", 16 * 128, 16 * <remaining amount of tiles> ; Include the "second half" of tiles INCBIN "file.2bpp", 0, 16 * 128 ; Inlcude the first 128 tiles
The big problem with this is that there is a gap between both "halves", which is not ideal... so I prefer the other solution, which is to use a script that flips bit 7 of the tilemap data. If you need help with that, I can provide code fragments.
I don't like copying both halves separately, because that comes at a runtime cost, and I prefer to defer computations to compile-time when possible.
Last edited by ISSOtm (2020-04-27 09:33:18)
Offline
Cool, thanks for this very complete answer. I had a sub which added 128 to data when copying, but you are right flipping bit 7 is more efficient. I will try superfamiconv also.
Offline
@issotm: i have downloaded superfamiconv. I do not find the option to offset map data. Could you help me on this, pls?
Offline
From the documentation:
Usage: superfamiconv map [<options>]
[...]
Settings:
[...]
-T --tile-base-offset Tile base offset for map data
This should be what you're looking for.
Last edited by ISSOtm (2020-04-30 15:01:16)
Offline
Aaaaaaaaaaaaaaaaaaaafrh: I got an old version where -T was « maximum number of tiles ». I have version v0.9.2 now with the option you described. Thank you again
Offline