| |
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....
|
| |
knue
Registered: Dec 2012
Posts: 37 |
I'm already using the illegal screen mode to blank out the garbage you'd normally see when doing AGSP. And no, sprites are nevertheless displayed in illegal screen mode. You can see this effect in my demo I linked in my first post.
EDIT: current version uses a zero-sprite to do the clipping in software - but this screws up the timing at discussed. So you can't really see this effect in action in my current demo. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
You could try to use a DYSP over the linecrunch area. Unfortunately that'll take up most/all of the linecrunch area, so no scoreboard in that area.
I did a write-up on DYSP using cycle-counting via a table: http://codebase64.org/doku.php?id=base:dysp_cycle_table
If you adjust the $d011 table, you should be able to force line crunch. (right now it does a simple FLD).
Switch $d018 to point to 'empty sprites' before the line crunch, switch $d018 to proper sprite pointers after the line crunch.
This will require to do the VSP _before_ the line crunch. |
| |
knue
Registered: Dec 2012
Posts: 37 |
Thank you so much for all your helpful input. I'm now doing the following in this order for the AGSP:
* fld
* line crunch
* VSP
After the VSP I have naturally 8 raster lines where timing is not that critical. I do the software zero-sprite-frame trick in that area. So the remaining 21-8=13 raster lines the sprite just pops out. Some sort of middle ground.
As others have suggested, when everything else runs, I can come back to this and see whether I can come up with sth even more sophisticated. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting DiggerCould you use one of the illegal modes for $d011 in the upper AGSP area to turn off the screen and hide the sprites behind? Then just switch the sprite priority after the line crunch.
I guess this might not work for some reason, otherwise someone would have already suggested it ;-)
This could work if you ensure that only foreground pixels are emitted. Use for instance the ECM+multicolour mode, and select a font bank with two pages' worth of $ff.
But you would still have to deal with the timing problems, so there is no improvement over the empty-sprites approach. |
| |
knue
Registered: Dec 2012
Posts: 37 |
Quoting lftQuoting DiggerCould you use one of the illegal modes for $d011 in the upper AGSP area to turn off the screen and hide the sprites behind? Then just switch the sprite priority after the line crunch.
I guess this might not work for some reason, otherwise someone would have already suggested it ;-)
This could work if you ensure that only foreground pixels are emitted. Use for instance the ECM+multicolour mode, and select a font bank with two pages' worth of $ff.
But you would still have to deal with the timing problems, so there is no improvement over the empty-sprites approach.
ah, didn't know that. In my case memory consumption is even worse since I'm using bitmap mode. |
| |
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. |
| Previous - 1 | 2 | 3 | 4 - Next |
