| Home | Forums | What's new | Resources | |
| Interlaced (hires) sprite prob |
| RockinB - May 3, 2006 |
| RockinB | May 3, 2006 | |||
I do have 2 8bit screens at 640x480, too. Maybe a 3rd 8bit is possible. The thing is that the kind of scroll image I'm talking about doesn't use any tile twice, which means that it takes 300 kB for cels. There is no 2nd screen possible with 512 kB VRAM. Adding scrolls in this case is difficult, since the cels span 3 vram banks and you only got 4 cycle pattern slots and the corresponding patterns for the 3 banks must be the same. Not to forget the data alignment in vram, and at least two more restrictions. It's a pain. <!--QuoteBegin-c gfm2@Wed, 2006-05-03 @ 04:46 PM As for the color problem, make sure the ECD bit is *set* in the CMDCTRL word of each sprite entry. Otherwise it will interpret color $FF as transparent (as well as clipping sprites horizontally when pixel $FF is found) [post=146051]Quoted post[/post] [/quote] AFAIK I've disabled both, end code and transparency code in SGL. Strange... | ||||
| RockinB | May 4, 2006 | ||
| The paletted sprite code displayed black is NOT white, it is 0xFE (254)! I have determined the code by overwriting the color with blue and when I display that image as sprites, these dots are black, if I display it as nbg1 scroll, these dots change to blue. I don't know if this code is ignored by the VDP1 (and it is palette code 0, the frame buffer erase data), or if the VDP2 ignores it, such that the back color shines through. Well, I actually don't have a clue why it doesn't work as desired | |||