Non-standard console graphics

[Klarth]

Looking for people to share experience with non-standard, uncompressed console graphics and in-particular answer a few questions about how common the following are in actual games:

1. Tiles that are not of integer byte size. (Say 16 bytes and 4 bits instead of 16 bytes)
2. Tiles that are stored at non-byte boundaries. (0x10000 and 4 bits instead of 0x10000)

I'm leaning towards both of those being uncommon enough to not be supported in a graphics editor and simplifying things for me fairly significantly, but want some extra opinions before the final decision.

[FAST6191]

I will have to look into this as I have never really considered it. Anyway the GBA and DS have a method of what is technically compression but in reality still reads as 1 bit per pixel (the BIOS functions that handle it call it bitfilter and bitunpack) and thus can be edited in a tile editor.  Fonts are a common user of it for obvious reasons and they are often not power of two width and height, and differences within the same font/glyph to glyph are an option here as well (the classic it is 8x16 but software defined smaller is still seen but pure custom size from glyph to glyph is also a thing).
I am trying to think whether I would have usefully seen this at ROM level as well (huffman compression could do this but in a straight tile editor that is probably not so useful). Space is cheap enough though that I often see files on those systems go in for considerably higher than simple byte or 16 bit alignment for data, and a few read/copy and compression functions mandate 8, 16 or even 32 bit alignment for various aspects.
Related to this is I have had a font, if memory serves it was a Dragon Ball Z game on the DS and it would probably have a description somewhere on GBAtemp DS ROM hacking section, define the upcoming tile and then have the tile data, this made the byte skip function of crystaltile2 quite nice, but that is possibly a different matter to what you are covering here.
You may also wish to look at 3d textures as it could possibly happen there and a lot of those are definitely still tile editor country. http://problemkaputt.de/gbatek.htm#ds3dtextureattributes

Space is cheap though and I have never really considered whether it appears as ROM or fileystem, sub section I could possibly lacking padding to keep alignment but I am going to lack examples at this point. Obviously there is the classic slider in the tile editor that shuffles pixels one way or the other when it comes to drawing, but if it is about your read functions not needing masks and whatever else then that is not terribly relevant.

[BlackDog61]

I've never seen 1 nor 2. But my knowledge is very limited.
Too bad you rules compression out - RLE (8 or 16) seems to be not so uncommon on the PSP. Nothing out of the ordinary, so if you have some time at hand later down the road, please consider a compression / decompression plugins interface.

(Note: I'm more or less done onmy side graphics-wise on my current project.)

[Klarth]

Fonts are a common user of it for obvious reasons and they are often not power of two width and height, and differences within the same font/glyph to glyph are an option here as well (the classic it is 8x16 but software defined smaller is still seen but pure custom size from glyph to glyph is also a thing).

Fonts are definitely the main focus of this potential issue. I don't remember seeing any that were non-integral sizes per tile, but I haven't worked with many nasty fonts. Tile sizes that vary from glyph to glyph could be supported in a roundabout way if they are on byte boundaries.

define the upcoming tile and then have the tile data, this made the byte skip function of crystaltile2 quite nice, but that is possibly a different matter to what you are covering here.

I was planning to add a stride for linear formats anyways. Maybe I'll do the same for tiled formats.

[/quote]Obviously there is the classic slider in the tile editor that shuffles pixels one way or the other when it comes to drawing, but if it is about your read functions not needing masks and whatever else then that is not terribly relevant.
[/quote]
I just checked TileLayer Pro and the finest adjustment you can do is +/- 1 byte. Bitwise may be overkill.

Too bad you rules compression out - RLE (8 or 16) seems to be not so uncommon on the PSP. Nothing out of the ordinary, so if you have some time at hand later down the road, please consider a compression / decompression plugins interface.

I think adding a codec plugin system for compression is too niche for the amount of effort it would take to implement. I prefer external tools to do the compression work and to just edit the uncompressed version. The editor will have features to make this kind of workflow to not be a pain once everything is properly setup.

I'm not familiar with PSP, is the PGF format actually common? I'm not against adding specific file loaders, but they would certainly not be in an initial release.

[BlackDog61]

I'm not familiar with PSP, is the PGF format actually common?

I haven't seen any yet. But as I said - I haven't browsed a lot of the console's library. KingCom may be a good source of info on this?