| |
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....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
"I shudder to think of having to deal with sprites disappearing into the upper border when doing VSP/linecrunch."
That is not as nasty as one might think since all timing required is outside/before the sprite fetches. One thing though, when line-crunching sprite 0 interferes with the $d011 write so, in that area you may only use sprites 1-8.
In practice it's like any AGSP but instead of wasting cycles each line you do some $dc04 thingies to get it right. |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Like Jackie says, sprite zero becomes unusable because of the linecrunching. Then later, on one single line, you can't use sprite 1 either (I'm referring to the d018-trick I wrote about). But probably the multiplexer can take care of that, if it's altered a bit.
It only takes about 30 cycles to do the d018-interrupt-thing.
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Like Jackie says, sprite zero becomes unusable because of the linecrunching. Then later, on one single line, you can't use sprite 1 either (I'm referring to the d018-trick I wrote about). But probably the multiplexer can take care of that, if it's altered a bit.
It only takes about 30 cycles to do the d018-interrupt-thing.
Yeah, and I meant of course that only sprites 1-7 are available (not 1-8!, only crossbow and graham have 9 sprites!)
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Another idea: since there is no time wasted on screen copying, what about letting the sprite pointers stay fixed (for example $f8-$ff) and copying sprite & char data as necessary (possibly realtime-depack & flip sprites for more animations possible, MW4 already does this for all bullet/item sprites while also doing unaccelerated scrolling :))
Of course for multiplexed sprites, you'd need for example double or triple the chars.
Btw. there's one more downside to AGSP: it's either the status panel made with sprites and no smooth fading of sprites from the top screen edge, or no panel... |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
<Post edited by Oswald on 4/10-2007 19:28>
hmmm,
(edit, will be this one green too?:)
how about using a temp screen with pointers f8-ff and having 2 nmis to switch to the temp screen at the critical char row? benefits: sprite multiplexing can go the traditional way, also char bullets can go on without caring whatever is at 7f8-7ff.
edit: ok, the above needs some more thoughts, btw the vic reads the char pointers only once, this can be extremely useful! now thinking on it some more :) |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
is it possible to change screen _after_ sprite pointers been read in but _before_ vic fetches char pointers ? :) => split the char and sprite pointers between 2 screens, switch to correct chars screen after spr pointers been readed and before vic reads char data. switch back afterwards. this would rule. :) |
| |
Burglar
Registered: Dec 2004
Posts: 1033 |
it might be wise to already make a memorymap (as thats based on hard restrictions) and requirements specification. I'll leave the memorymap to the less crappy coders than me ;)
but I'll have a go with the requirements:
- 50 fps
- (near) fullscreen playfield
- scrolling in x+y directions
- max scrollspeed: 4 pixels (?)
- charmode with dynamic $d800 color
- 32 multiplexed and animated sprites
- char bullets
- ingame music + sfx (?)
- onscreen player scores (?)
putting up requirements usually helps a lot to brainstorm, as you know what you want.
anyway, please correct me if I'm wrong with any of the requirements, and if there need to be more.
now, the coding topics are getting a bit beyond my rusty skills, so no need to bore you with obvious nonworking suggestions ;) but keep it up! ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
you are right with the requirements. agsp would make 8pixels / frame scrolling or more possible tho :) btw sprite 0 is unavailable for the whole agsp area ? |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
A somewhat related article on codebase:
http://codebase64.org/doku.php?id=base:multidirectional_scrolli.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: is it possible to change screen _after_ sprite pointers been read in but _before_ vic fetches char pointers ? :) => split the char and sprite pointers between 2 screens, switch to correct chars screen after spr pointers been readed and before vic reads char data. switch back afterwards. this would rule. :)
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
