| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Clipping background/sprites with open borders
Hello,
In my current game-project I have opened the top/bottom borders to display information using (all 8) sprites in the bottom border. However, for some levels I want to move sprites smoothly vertically off screen, while being correctly clipped by the border. For another level I need to mask the top/bottom row for adding the new row during vertical scrolling.
I wondered if you guys can give me some suggestions on what the best options would be to accomplish this?
I can think of several options:
- Enable an idle background mode at the correct raster line, so that only a black background is shown. Does this also clip sprites?
- Use X-expanded sprites to cover-up the top/bottom row. However, I need those sprites immediatedly again for the status info in the bottom border. I'm not sure if this is possible timing wise. Also, I then have only 1 gamesprite left that can be clipped.
- Do not move game-sprites in the border area, but software-clip them. I.e. keep the y-position constant, but copy the sprite image upwards/downwards. I think this is the best option, since only a few sprites (max 3) will have to be clipped at the same time.
What do you think is the best option?
Thanks,
PaulKo64 |
|
... 2 posts hidden. Click here to view all posts....
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
in this release I use open borders and vertical scrolling:
Bike64 Project - 0xAA Version
the black area between the bottom chars (green grass and rocks) and the "096" numbers is achived by changing $d018 at some raster line, so that it points to a new screen where empty chars are shown in the interested area and changes sprite pointers, so that empty sprites are shown. then y-sprite coords are changed for "096" sprites and $d018 is changed again. I think it was so, but I should check the code to be sure.
|
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Haven't tried it, but how about setting $3fff to #$ff (if you're using the default bank, 3) and at the beginning raster line of the open border, set the sprite-char priority to #$ff as well.
Then at the beginning line of where your "scoreboard" sprites are displayed, set the sprite-char priority back to #$00.
Works wonders if you have a black background. Other coloured backgrounds require another and more advanced way. |
| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Thanks for the suggestions...
If I'm going to "clip" the sprites with either switching to a different screen-adres (with empty sprite images), or using the $3fff method with correct priority, I think I will have a problem when reaching the "status"-sprites.
F.e. if I want to be able to fully clip a sprite in the bottom border, I need up to 21 rows before the status sprites can be shown (since new sprites will not be displayed unless the old one is completely finished)! I.e. I will always have a black seperation of minimal 21 lines, which is quite big I guess... However, now that I think of it, since the sprite is not shown during the clipping, one can already set up all the parameters (Y-position, X-position, color, pointer) before switching back to the old screen (at the correct raster line). I think this is what you mean Martin?
Another advantage I see is that I do not have to take care of the other screenadres to point to sensible data, since I'm in the border anyhow. This saves me the hassle&memory of having a backup of the screendata!
Thanks,
PaulKo64 |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
Suppose you have a game sprite that crosses the opened lower border, and you "fade it out" by changing the sprite pointer to an empty sprite data block. That looks fine. However, the now empty rest of the sprite is still "displayed" by VIC until all 21 sprite lines are "shown". You can set another Y-value before the sprite "ends", but VIC is going to start the next sprite only when the first sprite is finished. So yes, you need 20 black lines between the bottom game graphics and the start of the status line.
Maybe you could use only 6 or 7 sprites for the status line. Then you could have 2 or 1 game sprites that cross the lowed border, without negative effects to the status line. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Imo, it's better to not move your sprites inside the lower border, exactly because of the need for a 21 pixel gap between the start of the border and your status sprites..
It's better to plot your sprites realtime, so when your sprite is 10 pixels into the lowerborder, you have a sprite-y-co so that it's fully in the screen and copy the correct data into the sprite, so it looks scrolled..
this only costs 63 bytes to write, so unrolled it would only cost you 63*10 cycles = 630 cycles = 11 rasterlines...
and no problems with the gap..
|
| |
HCL
Registered: Feb 2003
Posts: 716 |
Agree with WVL and others for the sprites.
Screen clipping depends on gfx-mode:
- for char-mode you may switch $d018 to empty char-bank, or switch $d011 to idle-mode -> will show black (perhaps you have black background).
- for bitmap-mode the $d011-trick also worx (if black bg), but you may also use software-clipping (clear 0-7 lines at the top and bottom). The latter don't require any exact timing like the others, timing that may cause some troubles because of various amounts of sprites. |
| |
Skate
Registered: Jul 2003
Posts: 490 |
I'd use software-clipping as well. if your sprites are animated, best option is copying/shifting the datas in realtime. but for the static sprites, you can even use precalculated frames (you'd lose around $500 for each sprite). you should decide losing cycles or losing memory considering your needs on this project. |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
Yes, I agree with WVL, HCL and Skate.
A 21 pixel gap would be really ugly. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Quoting Paulko64 I think this is what you mean Martin?
Yes, that is pretty much it. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Agree with WVL and others for the sprites.
Screen clipping depends on gfx-mode:
- for char-mode you may switch $d018 to empty char-bank, or switch $d011 to idle-mode -> will show black (perhaps you have black background).
- for bitmap-mode the $d011-trick also worx (if black bg), but you may also use software-clipping (clear 0-7 lines at the top and bottom). The latter don't require any exact timing like the others, timing that may cause some troubles because of various amounts of sprites.
" or switch $d011 to idle-mode "
A bit nitpicking: The VIC is not idling in the illegal modes, only all pixels are black. Bad lines and some kind of gfx is still displayed, it can be checked with a 1 pixel sprite, and hardware sprite-background collision detection. |
| Previous - 1 | 2 - Next |
