| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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....
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
johncl: Or just multiplex using interrupts? :-) |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
Quote: 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).
Yes, it would take around 80 lines. I would do this in the background, and the multiplexer with raster irqs.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
<Post edited by Oswald on 4/10-2007 11:31>
lda d800,y
sta d800,x = 9 cycles *1000=9000 / 63 = 142 lines.
they way of splitting you advise doesnt helps on the speed, as it just moves the place of the operation to be across 2 frames. it's only good to avoid frame update bugs. ;)
as you see for a freedir fullscr game there's only 170 lines are left for whatever a game wants to do per frame. (spritesort,multiplex, etc etc)
counting with a worst case scenario 32 sprites multiplexed would take about another 60-100 lines away. you are left with ~ 100 lines for char bullets drawing, collision checks, movement logics, spawning enemies, etc.
(and now this will be what color? ;) )
and another edit: doing the d800 copy while the screen is displayed is pretty nifty though, allows software bullets to be done outside the visible screen ;) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Quote: Yes, it would take around 80 lines. I would do this in the background, and the multiplexer with raster irqs.
Ah well, I do all my code in the raster irqs and using the good old border color trick to measure the time used and see all the time what I have available. Atm I would get in trouble with sprite multiplexing if I needed more than 3 levels in my little scroller (but its easy for me to split up the copy to insert some sprite multiplexing code if needed). But I am quite sure my game could be immensely improved in that sense since this is my first go at making a 100% asm game on the C64. :)
Atm I am wondering what the best way is to set up the sprite multiplexing, or general reuse of the available sprites as they enter and leave the screen. I might have to maintain a list of "mobs" per column so I know where they left the screen the last time and easy check on when they should reappear. But that might be wasting a lot of memory with "empty spots". |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
indeed, it's annoying in fex. turrican that you can kill enemies by having them go offscreen ;) how about having a list of all enemies with x/y coords, and notoriously checking the list wether some of them came onscreen, then setting the ones going offscreen back to inactive state. you can also divide all these computation amongst several frames, so full list check is only done every 4 frame or so. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
<Post edited by WVL on 4/10-2007 13:34>
Maybe a different idea.
-dynamic charset.
You just have your agsp screen, and sprite multiplexer.
Now, what you do is that you check what the value of the spritepointers will be at the rasterlines where $07f8-$07ff is displayed. And now (here comes the dynamic part), you change the charset so the correct charshapes are displayed.
This doesnt give you total freedom though.. f.e. for optimal flexibility you need to have all sprite pointers a different value.
Maybe it's a good idea to make _all_ chars in the problematic charrow unique. Say #$00-#$27.
Now, if your sprite pointers are always in the #$00-#$27 range, you can make sure you can display everything correctly.
Ofcourse at a cost.. You need to copy 40*8 bytes every frame = 320 bytes. But still less than copying the screen around.
Maybe this works for you? Or else I'd go with Pernod's idea, you only need fixed timing in 8 rasterlines..(too bad about the 6 sprite limit (is this really so? I'd guess you have exactly 1 cycle left in a badline in the correct position, and plenty of cycles left in the other lines?)
urgh. Stupid me : you only need to have fixed timing in the badline (and maybe the line before too, when the sprite data is being fetched), then quickly set 07f8 to stay at the spritepointers.. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
great idea, but messy to realize :/ I'd restrict chars to 00-7f and sprites to 80-ff (or some other tradeoff), then there would be no need for the extra irq and rewrite of 40 chars, instead we loose a lot of gfx space :) a problem you havent adressed here: now we need to temp what chars 7f8-800 should have. -> extra mess around in the char bullet code :/ |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
WVL:
Switching between charsets at the very beginning and end of a char-row should be easy enough. But you'd be in trouble if two sprites happened to share the same frame, plus the you'd waste almost a full 2k in the VIC bank for the extra charset.
I figure it'd be easier just to reserve eight fixed sprites and switch charsets (to one with new sprite pointers) instead. You'd probably want an extra charset for double buffering anyway, and updating the visible portion of the sprites (max 192 bytes) is probably still faster and easier than juggling the unique chars.
Also it'd probably be a good idea to tweak the multiplexer to disallow having to deal with more than eight sprites in that row.
I shudder to think of having to deal with sprites disappearing into the upper border when doing VSP/linecrunch. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: great idea, but messy to realize :/ I'd restrict chars to 00-7f and sprites to 80-ff (or some other tradeoff), then there would be no need for the extra irq and rewrite of 40 chars, instead we loose a lot of gfx space :) a problem you havent adressed here: now we need to temp what chars 7f8-800 should have. -> extra mess around in the char bullet code :/
<Post edited by WVL on 4/10-2007 14:27>
Hey! it's a solution ;) It ain't perfect :D But neither is Pernod's idea, or working around the problem by level-design. :)
that's life :D
Quote:I shudder to think of having to deal with sprites disappearing into the upper border when doing VSP/linecrunch. That's nasty, yeah. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I'm starting to leaning against that the traditional way presents less problems :) maybe if the living shit is optimised out of it, it can do some miracles :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
