| |
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 |
|
| |
TWW
Registered: Jul 2009
Posts: 545 |
Not sure if I understand you correctly but here goes:
#1: Moving sprites smoothly vertically off the screen
I am assuming the sprite you want to move smoothly off the screen is not supposed to be shown in the lower border since that is where you have your stats etc (meaning you are using the same sprite as the one you are moving down).
I don't think this is a problem at all. At the giver R-Line where you want the sprite to smoothly dissappear, vhange the settings for it ($07f8++) while the raster is in the sideborder and it should dissappear smoothly as you say while the oter sprite should also show correctly in the lower border
#2: You are scrolling the screen up/downwards and want to figgure out how to mask the "rows" og gfx appearing on the screen (simmular to $d016 masking 40/38 width creen)?
There is more screen then is visible. just add another layer of sprites in the bottom / top untill you are outside the visible area and do your gfx-clipping there. 8 pixels scroll (adjust your raster splitts) and reset + add gfx (same as you would with $d016 and horizontal scrolling).
Not sure if this is what you meant? |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Turn on illegal screen mode to get black chars, useful if you are scrolling vertically. Change screen address and optional bank which is a faster way to update the sprite pointers to blank sprites. Then you have as long as you like to setup your new sprites in the border. Change ypos first so you can get the border sprites to display higher up if needed.
Or the dynamic clip method is good if you can spare the time for the copying. |
| |
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: 849 |
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: 902 |
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: 728 |
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: 494 |
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. |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
