| |
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.
|
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
Hey Ossie,
why didnt you ask on IRC? :)
Nothing tricky going on. I have fixed sprite pointers, and adjusted the bitmap (and sprite pointers) to make everything work out.. simple as that. (like, when i needed red+pink+blue, i'd chose $2a,$a2,$62,$6a,$26 or $a6 for spritepointer..)
AFAIK, there's no holy grail :( except only using $d800 colors, which nullifies the use of bitmap. I wonder how Fred's Back is doing it?
Oh.. about $d800 copying, I only have to copy one single line each frame and never a full screen.
How does it w0k?
Imagine you have a fixed screen, and you're starting to scroll up. everythings fine. Now, line 26 starts with data that is located at $1f40 in the bitmap, and there's only $c0 bytes left there, ie, not a full line.
So at that point i do a $dd00/$d018 switch and jump to the next bitmap. Now, this one starts at $1f40, ($c0) bytes and then continues from $0000.
When bitmap 2 hits the top of the screen, I have to stop linecrunching and I switch to first bitmap = bitmap 2. But suddenly my $c0 offset disappears! So I correct for that with DMA-delay.
That's all there's to it.
So i use :
- offsetted bitmaps (or rather one continuous bitmap, depending how you look at it :D)
- whenever I need to start the screen with one of the offsetted bitmaps, I need to dma-delay the screen to scroll it sideways aswell.
BTW, i think if you're only scrolling vertical, you can keep going on like this (i think) without ever having to copy a full $d800 screen and only single lines.. |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
"why didnt you ask on IRC? :)"
well, checking... hmm... wvl is not online ;)
thx for the explanation, someone rumoured something like you revsp the screen in place or sth like that, so I thought you have something ;) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I bet Fred's Back has blue sky where there's spr-pnts. Since it's bitmap, the gfx just needs to be cleared, then the spr-pnts don't matter. |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
the problem is char bullets here, to compensate the opposite should be as fred's back: spr pointers should be enclosed in platforms and stuff (instead of making them 'sky'), so soft bullets cant run on them... this is the easyest solution, but its hard to imagine how good levels can be designed around this. |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Maybe my memory is a bit rusty, but I think Exilon/Hz showed me a trick he used for a game (unfinished, of course) around 1990. He used some timer interrupt trick, like setting d018 before every badline, then setting it back before the sprite fetches in the right area of the screen. It is only possible to use six sprites per raster line though.
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Maybe my memory is a bit rusty, but I think Exilon/Hz showed me a trick he used for a game (unfinished, of course) around 1990. He used some timer interrupt trick, like setting d018 before every badline, then setting it back before the sprite fetches in the right area of the screen. It is only possible to use six sprites per raster line though.
brrrrr that sounds really nasty... i guess it works, but wouldnt call it the holy grail :) |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Quote: brrrrr that sounds really nasty... i guess it works, but wouldnt call it the holy grail :)
Come on, don't be a wuzz! This is where macho coding begins. ;-)
|
| |
Burglar
Registered: Dec 2004
Posts: 1033 |
if there is no holy grail, maybe a fixed $d800 color for the whole screen would work, you lose a color per char, but you gain loads of rastertime. if you use a medium color, good graphicians will know how to use it and make stuff look pretty anyway. dunno how that would affect char-bullets though. |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
working the levels around the spr pointers seems to be better :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: if there is no holy grail, maybe a fixed $d800 color for the whole screen would work, you lose a color per char, but you gain loads of rastertime. if you use a medium color, good graphicians will know how to use it and make stuff look pretty anyway. dunno how that would affect char-bullets though.
<Post edited by JackAsser on 3/10-2007 20:10>
"...I'd like to have char mode..."
Fixed $d800 in char-mode => fixed 4 colors always.
Sprite-pointers are a LOT worse to handle in char mode since the gfx also changes.
Another thing, "revsp" is not possible. VSP happens when you go from idle state to badline state too early. badline to badline == FLI and will not VSP. I.e. to "revsp" you will need one raster line with idle-state graphics.
Sorry for not adding any solutions to your problem Ossie. Just wanted to shed lights on a few things regarding this.
To be a bit off-topic: I played with FLI-VSP yesterday and came to the conclusion that you can't VSP a FULL FLI image (with all 200 lines visible simultaneous). I.e. all 200 lines can't be FLI. IMO the first and last line will be corrupt (198 lines in total). Any one who can prove any different?
I can perhaps see someone like crossbow manage 199 lines, but not 200 imo. Not without cheating the last bad-line.
=D
|
... 60 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
