Interlaced (hires) sprite prob

[RockinB]

Because of limited VDP2 RAM and limited cycle patterns, you can't display 2 arbitrary (!) fullscreen image scrolls (8bit palette) at the same time.

But you can use the sprite gpu VDP1 to display a scroll, too. Each tile becomes a sprite. This makes 1200 sprites with 640x480 (if I'm correct), so quite a lot.

I did that, my screen resolution is double interlace, I guess (640x480) and I think the display problem you see below must have something to do with that (and possibly with the high number of sprites, too).

left: vdp2, right: vdp1

[attachmentid=1833]

Note that the text not displayed on the right is a priority bug in yabause. On Saturn when turning on vdp1 rendering, the bottom half of screen flickers, being almost completely black.

I remember when using double interlace with vdp1, you have to precisely meet the framerate, because vdp2 reads from both framebuffers for one image. (or something like that)

Any help?

 

[RockinB]

Both things are fixed.

The distortion is due to one 16x16 tile being actually made of 2x2 characters of 8x8 each.

The flicker was indeed due to too long drawing time and asynchronisation with screen. I do now convert the screen into 4 textures, because max texture size is 504x255.

Works and looks fine, except for a few pixels being black(VDP2 back color?) instead of white....

 

[cgfm2]

Originally posted by Rockin'-B@Wed, 2006-05-03 @ 07:59 AM

Because of limited VDP2 RAM and limited cycle patterns, you can't display 2 arbitrary (!) fullscreen image scrolls (8bit palette) at the same time.

My window test program did four 4-bit tiled backgrounds at 640x480, and I'm fairly certain I had tried an 8-bit version of that at least had two NBGs showing, if not more. I could be wrong, but I feel doing 2+ 8-bit backgrounds in the hi-res mode is possible. Same thing with the super-hires (EDTV) modes.

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)

 

[RockinB]

Originally posted by cgfm2+Wed, 2006-05-03 @ 04:46 PM--><div class='quotetop'>QUOTE(cgfm2 @ Wed, 2006-05-03 @ 04:46 PM)</div><div class='quotemain'>My window test program did four 4-bit tiled backgrounds at 640x480, and I'm fairly certain I had tried an 8-bit version of that at least had two NBGs showing, if not more. I could be wrong, but I feel doing 2+ 8-bit backgrounds in the hi-res mode is possible. Same thing with the super-hires (EDTV) modes.

[post=146051]Quoted post[/post]​

[/b]

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-cgfm2@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]

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