WMLONG transparent value

TonyB

"WMLONG writes longs, like WRLONG; however, it does not write any byte fields whose data are $FF. This is intended for things like sprite overlays, where $FF byte data represent transparent pixels."

Why FF instead of 00?

cgracey

TonyB wrote: »

"WMLONG writes longs, like WRLONG; however, it does not write any byte fields whose data are $FF. This is intended for things like sprite overlays, where $FF byte data represent transparent pixels."

Why FF instead of 00?

Because $00 is probably more useful than $FF as a data value.

potatohead

Yes, people may use it for other things. As for sprites, something needs to be transparent. Since we use color lookups, any value is fine as they will rarely be associated with a given color.

ie: $FE = white = $FF_FF_FF rgb

TonyB

Well this is the inverse of what I was expecting. I've come across bit = 0 or nibble = 0 or byte = 00 for transparent. FF not white and 00 not transparent makes no sense to me.

Is WMLONG only intended for writing data that's read from a LUT?

cgracey

TonyB wrote: »

Well this is the inverse of what I was expecting. I've come across bit = 0 or nibble = 0 or byte = 00 for transparent. FF not white and 00 not transparent makes no sense to me.

Is WMLONG only intended for writing data that's read from a LUT?

WMLONG can write data strings from cog registers (SETQ+WMLONG) or lut registers (SETQ2+WMLONG). Or, just one long at a time from a single cog register.

About $FF being the data pattern that is not written, it seems to me that you would not want to inhibit $00 values, since they are used for lots of purposes. $FF is at the other end of the spectrum for likely usefulness. Also, bytes are the low limit on hub memory granularity. To affect nibbles or bits, you would have to read, modify, and then write back bytes/words/longs, which are not atomic operations, all together. Byte writes are atomic, though.