youki Posted March 2, 2009 Share Posted March 2, 2009 (edited) Hi, How many sprites 16x16 can i display on the same screen? i thougth, it was 32 sprites (no more than 4 on the same row of course) But in the game i'm programming , it seems i can only display : 8 ! So i guess it is because in that you can display : 32 sprites (8x8) , it would mean : 8 sprites (16x16). Is it correct? Thanks #post edited : it was late, my sprite count was wrong... Edited March 3, 2009 by youki Quote Link to comment Share on other sites More sharing options...
+5-11under Posted March 3, 2009 Share Posted March 3, 2009 Yes, that is correct: 32 8x8 or 8 16x16. 5-11under Quote Link to comment Share on other sites More sharing options...
youki Posted March 3, 2009 Author Share Posted March 3, 2009 Yes, that is correct: 32 8x8 or 8 16x16.5-11under thanks for confirmation. It seems i will have to change my approach for my game. I started with 32 sprites in mind but 16x16. not good... I will see if if for certain i can use flickering without degrading to much the visual. I suppose we can not do sprite multiplexing as we do on C64 as it seems very difficult to get scan line information. (i saw a "proof of concept" a video on youtube (Here) that do that with TMS9918 VDP but... not really exploitable i think ) Is there a way to manage to do sofware sprites on the coleco in mode 2 ? I don't think as it seems not possible the video memory being character based and so not really possible to access directly pixel in a efficient way. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 3, 2009 Share Posted March 3, 2009 Yes, that is correct: 32 8x8 or 8 16x16.5-11under Sorry, but that is incorrect. There is enough space in VRAM to store 256 8x8 patterns, which is just enough for 32 16x16 sprite patterns. The smaller sprite attribute table in VRAM is capable of containing 32 sprites (x,y,color and pattern number), so one can therefore display up to 32 16x16 sprites on the screen. Quote Link to comment Share on other sites More sharing options...
+5-11under Posted March 3, 2009 Share Posted March 3, 2009 Interesting. Maybe I was limiting myself to loading 256 bytes by using "char" variables, or something. I'll have to try that again. 5-11under Quote Link to comment Share on other sites More sharing options...
youki Posted March 3, 2009 Author Share Posted March 3, 2009 Sorry, but that is incorrect. There is enough space in VRAM to store 256 8x8 patterns, which is just enough for 32 16x16 sprite patterns. The smaller sprite attribute table in VRAM is capable of containing 32 sprites (x,y,color and pattern number), so one can therefore display up to 32 16x16 sprites on the screen. humm.. interresting. I uses SDCC kit from Newcoleco . Would it be a limitation due to libraries here ? Because clearly, if i have 8 sprites(16x16) on screen and try to display 9 , the sprite 9 appears and another one (the 8 i think) disappears. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 3, 2009 Share Posted March 3, 2009 Sorry, but that is incorrect. There is enough space in VRAM to store 256 8x8 patterns, which is just enough for 32 16x16 sprite patterns. The smaller sprite attribute table in VRAM is capable of containing 32 sprites (x,y,color and pattern number), so one can therefore display up to 32 16x16 sprites on the screen. humm.. interresting. I uses SDCC kit from Newcoleco . Would it be a limitation due to libraries here ? Because clearly, if i have 8 sprites(16x16) on screen and try to display 9 , the sprite 9 appears and another one (the 8 i think) disappears. Either you're doing something wrong, or there's a bug in the library, because that's not supposed to happen IF all your sprites are not aligned vertically. Are you sure you are correctly inserting the "y=208" value at the end of the sprite attribute table in VRAM? Quote Link to comment Share on other sites More sharing options...
youki Posted March 3, 2009 Author Share Posted March 3, 2009 Either you're doing something wrong, or there's a bug in the library, because that's not supposed to happen IF all your sprites are not aligned vertically. Are you sure you are correctly inserting the "y=208" value at the end of the sprite attribute table in VRAM? I use y=207 to hide sprites. But in that case i'm sure they are all on screen area. do you mean i should put after the last sprite , a kind of Dummy sprite with his Y=208 ? But i will double check , it possible i'm doing something wrong here. Another question, can we use on the same screen freely : 8x8 sprites and 16x16 sprites ? Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 3, 2009 Share Posted March 3, 2009 Either you're doing something wrong, or there's a bug in the library, because that's not supposed to happen IF all your sprites are not aligned vertically. Are you sure you are correctly inserting the "y=208" value at the end of the sprite attribute table in VRAM? I use y=207 to hide sprites. But in that case i'm sure they are all on screen area. do you mean i should put after the last sprite , a kind of Dummy sprite with his Y=208 ? Yes, that's the way the sprite attribute table works in VRAM. So if you have 8 sprites to display on screen, the 9th sprite should be a "dummy sprite" with y=208 (the x, color and pattern number are not important). Of course, if you use all 32 sprites, there's no need (or even room) for a dummy sprite in VRAM. Another question, can we use on the same screen freely : 8x8 sprites and 16x16 sprites ? Nope. You can set the sprites in 16x16 or 8x8 mode, not both simultaneously. I think the default setting is 16x16 when you use the standard graphic mode setup functions, but newcoleco would need to confirm that... Quote Link to comment Share on other sites More sharing options...
Kurt_Woloch Posted March 3, 2009 Share Posted March 3, 2009 (edited) Yes, that is correct: 32 8x8 or 8 16x16.5-11under Sorry, but that is incorrect. There is enough space in VRAM to store 256 8x8 patterns, which is just enough for 32 16x16 sprite patterns. The smaller sprite attribute table in VRAM is capable of containing 32 sprites (x,y,color and pattern number), so one can therefore display up to 32 16x16 sprites on the screen. Sorry, but that is incorrect too. The VDP allows for 256 different patterns in 8x8 mode, or 64 different patterns in 16x16 mode. Since a 16x16 pattern takes up four times the memory of an 8x8 pattern (32 bytes instead of 8 ), 256 8x8 patterns take up the same memory as 64 16x16 ones do, not 32 16x16 ones. Oh, and I can confirm that the video chip IS able to display 32 sprites on screen. There's only a limit of four sprites per scanline, so if you try to put more than 4 sprites on the same scanline, only four of them will be displayed (I think those which come first in the sprite attribute table). Maybe this is how the 9th sprite of youki disappeared... Edited March 3, 2009 by Kurt_Woloch Quote Link to comment Share on other sites More sharing options...
youki Posted March 3, 2009 Author Share Posted March 3, 2009 (edited) There's only a limit of four sprites per scanline, so if you try to put more than 4 sprites on the same scanline, only four of them will be displayed (I think those which come first in the sprite attribute table). Maybe this is how the 9th sprite of youki disappeared... No, sprites when they diseapear are not at all on the same row. The problem is not here. The limit seems clearly 8 sprites 16x16 , i don't know why. i have checked, put a y=208 where it should . But nothing change. Only 8 sprites at the same time. Did somebody tested that with the SDCC kit from new coleco? May be it is a limitation of the 4k lib or something like that?? #Edit: i have figured out the problem. It was due to my call to updatesprite that was wrong. I have to understand exactly how it works. Now i have all my sprites but with lot of flickering if more than 8... #Edit 2 : Ok, i fixed all It was well a problem with my updatesprite. Now it works like i expect! thanks to all Edited March 3, 2009 by youki Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted March 3, 2009 Share Posted March 3, 2009 Sorry, but that is incorrect too. The VDP allows for 256 different patterns in 8x8 mode, or 64 different patterns in 16x16 mode. Since a 16x16 pattern takes up four times the memory of an 8x8 pattern (32 bytes instead of 8 ), 256 8x8 patterns take up the same memory as 64 16x16 ones do, not 32 16x16 ones. Oops! You're right! I wrote that comment too quickly! I stand corrected. Quote Link to comment Share on other sites More sharing options...
newcoleco Posted March 5, 2009 Share Posted March 5, 2009 TO UPLOAD DIRECTLY YOUR SPRITES TABLE (x,y,pattern,colour) TO VRAM : put_vram(0x1b00, sprites, N); /* where N is equal = nbr_sprites * 4 (+ 1) */ I usually use this instead of updatesprites or uptade_sprites... it's fast and allow me to use the flag bit in the colour byte to offset the X coordinates when needed. sprites[0].y = ...; sprites[0].x = ...; sprites[0].pattern = ...; sprites[0].colour = ...; sprites[1].y = 208; /* end of sprites */ ... put_vram (0x1b00,sprites,5); /* where 5 = 1 * 4 + 1 */ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.