WMLONG transparent value

Comments

• cgracey Posts: 14,133

  2017-04-21 20:41

  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 Posts: 10,253

  2017-04-21 21:38 edited 2017-04-21 21:46

  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 Posts: 73

  2017-04-21 22:54

  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 Posts: 14,133

  2017-04-22 00:38 edited 2017-04-22 00:39

  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.