| |
Oswald
Registered: Apr 2002
Posts: 5023 |
the holy gray of HW scroll: how to avoid spr pointers becoming visible
Hi!
Lately playing with game coding ideas fascinated me. However scrolling games are hitting the wall of the evil non-bufferable $d800, not to talk about the time needed to copy around scr ram even when buffered. I have thought up ways to divide the scr ram copy into several frames, but $d800 must be moved in one frame no matter what.actually it takes about 126 rasterlines to move all the $d800 data, even using a speedcode!
full hw scrolling is nice, and char bullets are even nicer (ie: I'd like to have char mode for my theoretical game). but this is where something horrible happens: the sprite pointers will become visible, and unless we accept the 8 char wide bug on the screen I see no way around.
or is there ?
I heard there's something tricky going on in WVL's PD to circumvent this. Jack, WVL, whats that ? I'm afraid not something usable in a freescrolling game.
the closest I came is to build a screen with stretching a full char row down in bitmap mode, and shuffling around VIC's scrram pointers to get the colors working. this is the best one I could come up with, but the memory layout and the code is messy (multiplex sprites on that baby, and where are my char bullets?)and needs a lot of mem.
sorry this became quite lengthy :) waiting for suggestions.
|
|
... 60 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Seriously Oswald... Implementing my bro's trick is not that difficult at all and will give you most bang for the bucks imo. It's just at ONE raster line (the one just before the sprite-pointer bugs) you have to be tricky on. On that particular line you may only have 6 sprites but that's it. Also, around this line you will need to switch $dd00/$d018 anyways because of linecrunching so the extra job needed is quite small...
Also the splitting of the $d800 across two frames is not just a delay of the $d800 copy, it actually gives you raster time free in the middle of the two copies. Of course in the end it's just as much copy as usual, BUT you gain quite alot of raster time in between those copies so that in reality you can treat it as worst case being half of what u said before.
<Post edited by WVL on 5/10-2007 09:38>
I have to agree with jackie here..
but if you use AGSP, there's no need to ever copy a full $d800 screen IMO. (except when you've only implemented a linecruncher or only dma-delay. You need both to avoid $d800 copying) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I have to agree with jackie here..
but if you use AGSP, there's no need to ever copy a full $d800 screen IMO. (except when you've only implemented a linecruncher or only dma-delay. You need both to avoid $d800 copying)
When the VSP wraps from 39 -> 0 you may decrease the linecruncher by one row to avoid $d800 copy.
When the VSP wraps from 0 -> 39 you may increate the linecruncher by one row to avoid $d800 copy.
However, when the linecruncher wraps due to a VSP-adjust I think you still must copy the $d800 area or maybe not... Feels that there must be some case when you actually need to copy but perhaps not. ;D Must do a test-implementation tonight or so. ;D |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
looking at the vic article timing diagrams, it seems like you can have up to 3 cycles (RMW) on a bad-line with 8 sprites on, and those cycles happen exactly when I need them to (afer sprite reads, before charptr fetches) are you sure only 6 sprites is possible ? with an nmi interrupt, and nmi timers to stable things this -in theory- is possible.
https://sh.scs-trc.net/vic/vic_article_3.6.htm
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: looking at the vic article timing diagrams, it seems like you can have up to 3 cycles (RMW) on a bad-line with 8 sprites on, and those cycles happen exactly when I need them to (afer sprite reads, before charptr fetches) are you sure only 6 sprites is possible ? with an nmi interrupt, and nmi timers to stable things this -in theory- is possible.
https://sh.scs-trc.net/vic/vic_article_3.6.htm
First you need to switch in the correct gfx after the sprite fetches, exactly as u say. Then you must wait until the DMA has fetched the 40 correct chars, then you must switch in the correct sprite pointers again. Thus you need to switch twice.
Thus you may use the 2 RMW cycles available for the first switch, but then you need to lda+sta/inc/dec directly after (6 cycles). You have 3, but u need 3 more. Bye bye with two sprites, #0 and #1.
Also, due to sprites over linecrunch area sprite #0 is a no no anyways, at least "up there".
|
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Quote: looking at the vic article timing diagrams, it seems like you can have up to 3 cycles (RMW) on a bad-line with 8 sprites on, and those cycles happen exactly when I need them to (afer sprite reads, before charptr fetches) are you sure only 6 sprites is possible ? with an nmi interrupt, and nmi timers to stable things this -in theory- is possible.
https://sh.scs-trc.net/vic/vic_article_3.6.htm
No, I am not sure how many sprites that are possible on that line, but the best I could remember was six. Please come back and tell me when you've tried it out! ;-)
|
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Quote: First you need to switch in the correct gfx after the sprite fetches, exactly as u say. Then you must wait until the DMA has fetched the 40 correct chars, then you must switch in the correct sprite pointers again. Thus you need to switch twice.
Thus you may use the 2 RMW cycles available for the first switch, but then you need to lda+sta/inc/dec directly after (6 cycles). You have 3, but u need 3 more. Bye bye with two sprites, #0 and #1.
Also, due to sprites over linecrunch area sprite #0 is a no no anyways, at least "up there".
It would be nice to have a multiplexer that can display eight sprites per line, seven at the top and six(?) where the sprite pointers are visible. My gut feeling says it's only a small modification to a sorting routine.
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: It would be nice to have a multiplexer that can display eight sprites per line, seven at the top and six(?) where the sprite pointers are visible. My gut feeling says it's only a small modification to a sorting routine.
Hmmm, now that I think of it MAYBE 7 sprites are possible. Must do an experiment to verify the idea though. |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
<Post edited by Oswald on 5/10-2007 11:10>
jack, preload a register, then do RMW, then write register. one sprite is crippled for one rasterline -> acceptable, you cant have everything :)
you must have 1 cycle even without RMW on a badline+8sprites. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: jack, preload a register, then do RMW, then write register. one sprite is crippled for one rasterline -> acceptable, you cant have everything :)
you must have 1 cycle even without RMW on a badline+8sprites.
<Post edited by JackAsser on 5/10-2007 11:28>
All sprites will be crippled. You need to reset the sprite pointers directly after the char fetch. Problem is that you only have RMW-cycles there hence you won't be able to fit your STA with the preloaded value there. If you remove sprite #0 you'll have 2 normal cycles there though, exactly enough for an RMW-write operation to fit if started just before the char fetch. Now, the problem is that u've already used that when u made the first switch. This means you have to remove yet another sprite. Now you've freed up 4 cycles and have 3 RMW-cycles. It's enough for an LDA+STA.
Although, maybe you can use the 2 freed up cycles from the first sprite to the the sta actually. If the sta-opcode is RRWW it'll fit nicly. If it's RRRW though u're fucked though since the last read-access will hit the RMW-cycle => Cpu stalled. |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
well, but still this will only happen when 8 sprites on a row on that particular line. I think I can live with that :D |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
