The code to process .chr files is very messy. Mostly...

The code to process .chr files is very messy. Mostly because I was fumbling trying to compute how many pixels I needed to jump for plotting a color and how many bites I needed to jump for reading data.

Kinda makes me wish uxn packed pixels using a simple "4-pixels per byte" scheme instead of a "two-channels per tile" format. Both pack the same information in the same space (2-bits per pixel), but 4-pixels per byte is easier to process, imo.

Like 27 March at 5:15 | Open on scalie.zone

3 comments

Devine Lu Linvega

@capital it's the famicom format, one of the advantage for 2-bit is that you can draw the layers independently when needed.
https://www.nesdev.org/wiki/PPU_pattern_tables

27 March at 14:59 | Open on merveilles.town

Capital

@neauoire I assumed there was some relationship with your past work in the Famicom. However, I don't quite understand the layering advantage? Is it faster to do since the bits for each channel are separated?

(I don't have much historic context for .chr formats and the Famicom)

27 March at 15:13 | Open on scalie.zone

Devine Lu Linvega

@capital For example in Oquonie, I have the outline and fill for player assets as chr tiles, if I want to make the fill color of the character blink, I can draw only the second half of the chr tile for just repainting the fill, or both at once.

27 March at 15:15 | Open on merveilles.town