| |
Dano
Registered: Jul 2004
Posts: 234 |
Question: Sprites on whole screen height
it's me again with a problem regarding sprites in lower and upper border.
the plan is to have a sprite layer beneath char/bitmap grafix over the whole screen height from top to bottom. seamlessly ofcourse. it's the same 8 sprites repeated over and over again.
i'm using a nmi timer to advance sprite y position. easy stuff as it's the same sprites repeated all the time.
yet i'm facing the problem with a black area i get when the lower border changes to upper border again.
i guess the problem is that i'm starting with sprites at line 0, but the screen is not a round /21 lines height. to my knowledge vic wraps the sprites from lower to top border and will display sprites only when the new y position is 21 lines plus last y position. so i can't put the first line at line 0 as the last row is still displayed there..
so guys, can you help me? is there any trick to force vic to stop to display sprites?
or how could i avoid that black area else?
source for a peek is availabke here:
http://cloud.mburgst.de/public.php?service=files&t=cadc8ddac536..
just some plain kickass hacking, nothing special to see there yet.. ;) |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
If I'm understanding you correctly you want sprites over the screen area + the upper and lower border. Can't you just skip one row of sprites at the very bottom before flipping back to 0 (or 5...)?
There are quite a few lines that aren't even present in the output video signal, let alone in the visible area.
Assuming PAL: 312-21*14 = 18 left over lines. |
| |
Dano
Registered: Jul 2004
Posts: 234 |
yes, there should be a like a "wall" of sprites over the complete height. 8x1 repeated over and over again. no expansion, no opened left/right sideborders.
well yes, those 18 lines are most probably my "dead" area.
that would be my current idea to stop the timer before that very last row and just finish displaying after the last completely visible row.
leonardo reminded me on the double displayed sprites, so maybe it makes sense to start sprites later and (mis)use that double-display..?
just wanted to be sure i don't make a stupid mistake overlooking some stuff.. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
You could also let each successive frame trigger the sprites 3 pixels lower and change the sprite data to match that offset. (18+3 = 21)
Assuming it's always the same 8 sprites repeated this just requires 7 sets.
It won't make any difference visibly but perhaps it's good coderpr0n? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: You could also let each successive frame trigger the sprites 3 pixels lower and change the sprite data to match that offset. (18+3 = 21)
Assuming it's always the same 8 sprites repeated this just requires 7 sets.
It won't make any difference visibly but perhaps it's good coderpr0n?
This is what crossbow did in his part with the most number of sprites on c64 (non-spritecrunched, or was it spritecrunched?). Using moving the sprites to display more. Question is if they count as whole sprites, or only 18/21th of a sprite ;-) or as 0 (if you say that a sprite must start AND end to count).
IMO, the best way would be to fill your 18-pixel gap at the border by stretching and filling it with graphics by $d018 trickery.
Ofcourse the moving-by-3 can also be done, but you'd need all the graphics 7x in memory (21/3) which can get quite expensive memory-wise (but maybe it isn't if your sprites repeat). Also moving means that your IRQ's are moving, which can be nasty sometimes. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
This shows the sprite overflow trick, in case it's helpful
https://gist.github.com/og2t/956683 |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Depending on the actual gfx pattern you need for the "sprite wall" you could also go for y-expanded sprites repeated 8 times.
Doing the math this gives 8*42=336 lines, thus 24 lines "too much" (at least for pal with 312 lines in total).
To avoid this, switch off y-expansion during the display of the sprites at a suitable point of display. This would be during the 7th repeat of the multiplexing, right before the 19th spriteline.
Formular to make it clear:
6*42 (fully expanded)
+ 18*2 (expanded till spriteline 18)
+ 3 (3 spritelines unexpanded till sprite ends)
+ 21 (another unexpanded full sprite)
= 312
Equivalently, you could choose 14 repeats of unexpanded sprites and turn y-expansion on after the 3rd line of the last repeat of the sprites (13*21 + 3 + 2*18 = 312).
However, this puts certain rules on the possible patterns of your sprite wall. To work around this, you could do some $d018-trickery to switch between sprite pointers on every rasterline. Steals some rastertime but will definatly eat far less memory compared to the "7 times shifted sprite data"-approach mentioned above. |
| |
Mason
Registered: Dec 2001
Posts: 461 |
Quote: This is what crossbow did in his part with the most number of sprites on c64 (non-spritecrunched, or was it spritecrunched?). Using moving the sprites to display more. Question is if they count as whole sprites, or only 18/21th of a sprite ;-) or as 0 (if you say that a sprite must start AND end to count).
IMO, the best way would be to fill your 18-pixel gap at the border by stretching and filling it with graphics by $d018 trickery.
Ofcourse the moving-by-3 can also be done, but you'd need all the graphics 7x in memory (21/3) which can get quite expensive memory-wise (but maybe it isn't if your sprites repeat). Also moving means that your IRQ's are moving, which can be nasty sometimes.
I remember that part with the most possible sprites as I remember Hungry Hero did the multiplexer in the Showcase Bonanza demo where he complains about people cheating with the height |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that blank 18 lines on top/bottom is not visible on most CRT's, not even on emulators in default setting, so its not worth the trouble to do all the shit that was suggested above. IMHO. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Listen to Oswald |
| |
Dano
Registered: Jul 2004
Posts: 234 |
well that's exactly what i did. that comes out when you forget about those debug borders in vice.. ;)
but actually i really wasn't sure if there's some easy trick around for those blank lines to be filled.
so it's good to know that i'm not too stupid after all ;) |
