| |
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....
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
How about having the sprites 'pop in', but when clipping is required, copy only the lines of the sprite that needs displaying into the temporary popped-in sprite.
Takes a bit of rastertime, but at least avoid a lot of timing issues and leaves sprites free on the linecrunch area for a score display.
Once the sprite has gone down enough, switch pointer to the normal sprite. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting knue@ChristopherJam: That's a really cool idea. But I guess this also means, that I can't use sprites for displaying game infos like life, points and so on because I'll need all sprites (assuming I can have 8 enemies coming from the top) to fight the clipping.
Thanks! But yes, losing sprites you could have otherwise used for status display is definitely an issue. I was wondering about plotting the status into the blank sprites at a corrected height, but to do that the sprites would need to be unexpanded, so you'd have to set Y at least once per sprite within the AGSP area.
Quoting CompyxHow about having the sprites 'pop in', but when clipping is required, copy only the lines of the sprite that needs displaying into the temporary popped-in sprite.
Takes a bit of rastertime, but at least avoid a lot of timing issues and leaves sprites free on the linecrunch area for a score display.
Once the sprite has gone down enough, switch pointer to the normal sprite.
I was considering that for Hysteron Proteron. It does limit your sprite density, mind. Consider a dense formation of 2x2 sprite enemies; the blank area pushed down from the first row then overlaps the next... |
| |
knue
Registered: Dec 2012
Posts: 37 |
dynamically copying stuff costs too much rastertime for a game.
BTW: Fred's back is having the same problemm. You can see that sprites pop in at the top of the screen.
Even Ghost'n'Goblins (although using a traditional scroller) sort of hast this problem. In level 2 when you climb up the ladders, you can see the halfs of the big goblins popping in out of nowhere at the bottom of the screen. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
True, when you add 2x2 sprite 'enemies', you'd indeed get overlap, unless you also render the second line of sprites, having them 'pop in' at 21 pixels from the top sprites.
But that'll take even more rastertime and specialized code, and will seriously screw with multiplexing. So things will get out of hand soon.
So yeah, my suggestion might work for simple sprite patterns (ie single sprites for enemies etc), but not for more complex stuff.
I'm also wondering about how to fix the sprite-pointers showing up in the AGSP-adjusted screen, at those locations (ie $x[37bf]f8-$x[37bf]ff) you can only use colorram and background, not vidram (assuming mc bitmap here). |
| |
Digger
Registered: Mar 2005
Posts: 437 |
Could 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 ;-) |
| |
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. |
| Previous - 1 | 2 | 3 | 4 - Next |
