| |
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....
|
| |
Hein
Registered: Apr 2004
Posts: 933 |
24 chars is not an option here? (I know, that is for sensitive people only, but a game is about playability first.) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: 24 chars is not an option here? (I know, that is for sensitive people only, but a game is about playability first.)
@Hein: If you refer to my (as I said) off-topic post about 200 lines of VSPing FLI I just asked out of curiosity, certainly not for a game. ;D
Now, if you refer to Oswalds original question 24 chars doesn't solve anything etc. |
| |
Hein
Registered: Apr 2004
Posts: 933 |
ah, right.. I thought it was VSP only. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
A trick to reduce the $d800 work is to only change colours every second (or third, fourth etc) column. Then you only have to $d800-scroll the columns where the changes take place. |
| |
Fungus
Registered: Sep 2002
Posts: 624 |
If your planning to scroll the screen at a fixed rate, why bother with dma scrolling? Seems you can just do as you say and split the scroll up into several frames. I can understand the color memory being a problem, but like Burgie suggested why not set it to a static color. If it's a space shoot em up, just set it to black, etc... ?
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
(Applies for rows when scrolling vertically, of course...) |
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
the evil of the d800 that you can not split the copying of it into several frames, so it doesnt matter how clever you are d800 has to be done in one frame, and as a game should be opted for worst case scenario, this will limit the speed.
I have 'decided' to design the levels around the sprite pointers (remember char bullet problem), as it gives me full d800 freedom, and no more screen shifting around -> there's 2x the time to do stuff compared to any other freedir scrolling games.
dont forget tho, that so far this is just a theoretical thinking about how a game in 2007 could be done better than anything so far :) |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
It is possible to split the d800-copying into two frames in stead of one.
The first frame you copy the upper half of the d800 area. Start doing this around rasterline 100. The next frame you copy the lower half. Also start this on rasterline 100 or so. Do the copying row by row starting with the uppermost line. That way the copying will never interfer with VIC.
|
| |
Hein
Registered: Apr 2004
Posts: 933 |
<Post edited by Hein on 4/10-2007 10:21>
oh, but my theoretical game is always 1% better than yours. ;) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
As pernod says, the copy can be split up somewhat. But I guess the biggest problem with this is that your copy can still take too much raster time making it e.g. hard to do a sprite multiplexer (unless you interleave that code with the copy which certainly is possible). |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
