| |
knue
Registered: Dec 2012
Posts: 37 |
sprite clipping at the top while using AGSP
Hi all,
I'm currently coding a game using an AGSP scroller. Since enemies are supposed to enter the screen from all sides, I have to clip the sprites entering from the top as the first 25+8 raster lines are used for the AGSP stuff. The question is: What is the best way to do this?
I can think of the following:
1) don't clip at all.
The sprite would simply pop up at full height when it enters from the top. This one is a bit ugly but wouldn't be the first game suffering from such problems...
2) set sprite pointers to a zeroed sprite.
While this basically works, the timing in the AGSP stuff gets incredibly complicated. I don't know whether this is even possible (without going insane). I mean I would need an immense amount of logic to time various areas in the AGSP stuff correctly depending on how many sprites are visible in this raster line.
Are there other options on the table or is 2) doable with some fancy lookup table or sth?
You can find the code here if someone is interested:
https://github.com/leissa/c64engine
Thanks in advance for any help. |
|
... 25 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 885 |
Quote: You might wanna check how we did it in Pinball Dreams. Can't remember right now, but the top paddles must have been properly clipped against the AGSP-area.
@WVL: Do you remember?
Yes, the paddles never go into the AGSP zone :-) They only go in the lower border, never in the AGSP area.
The levels are designed that way (well, we were just lucky..) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Oh!! I thought the upper paddle on Ignition would go under that area when furthest down |
| |
Tom-Cat
Registered: Apr 2003
Posts: 20 |
What upper paddle? All four Pinball Dreams tables only have lower two paddles... :)
Now PLEASE re-start the work on PD C64 because bloody CPC camp is getting an upper hand. And their ball has a black outline, for christ sake. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Couldn't you put 8 sprites at the top that are essentially empty or otherwise invisible, but are highest prio, never flicker. So that they will clip off the incoming pixels of the sprites coming from the top.
There are several NES games that make use of similar techniques, should be doable on C64 too, I think.
But then again, I am not a coder. |
| |
knue
Registered: Dec 2012
Posts: 37 |
ChristopherJam already suggested this solution. It could definitely work. However, I wouldn't have sprites left to display points, life and other status info on the top because I would need all sprites to fight the clipping. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Ah, I see, so you could not have stuff in the borders. Makes sense. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
This just randomly popped into my mind, but why can't you have your point/lives/whatever display up in the border, make sure it is 8 sprites for all lines, and then have those at a higher priority setting as the stuff that comes floating onto the char screen? That would work just fine, no? |
| |
knue
Registered: Dec 2012
Posts: 37 |
I don't get how you can achieve constantly 8 sprites within the AGSP area. |
| |
Mixer
Registered: Apr 2008
Posts: 421 |
What about hiding the sprite to sideborder when you wish to clip it. Or vice versa, change x to visible when you wish it to be seen. Or is the timing in the first lines the problem? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Thinking about this a bit more, once you use sprites in the border for your point/lives/whatever display, it already becomes challenging to scroll enemies off the top even if you aren't doing AGSP.
Assume that at some point in time you have the bottom line of pixels of an enemy visible at the top of the play area. Then unless you have a 20 pixel gap between the top of the play area and the bottom of the status area, the Y position of that enemy's sprite will be within the status area.
You could possibly mitigate this a little using sprite-crunch, but the shortest possible sprite is still 17 pixels high (cf short sprites).
Only other options I can think of are either to limit the total number of status-display sprites plus border-leaving sprites to eight, or to soft scroll at least some of the status display elements within the sprites you use to display them. |
| Previous - 1 | 2 | 3 | 4 - Next |
