| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
(oh, and if you're deferring this until later, it might be worth positioning half a dozen or so blank sprites in the AGSP area anyway, so at least that way you know you have the DMA time available?
Hysteron Proteron used sprites in the AGSP area for the HUD, or would have if I'd ever finished it..) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting ChristopherJamIt's a little messier because AGSP is taller than that; you need to have all your blank sprites initially double height, and zero d017 when you leave the region.
Or you could use magic sprite stretch (i.e. sprite crunch). But that would involve some timing-critical stuff before the AGSP area, so it would just move the problem.
One thing that I thought was a bit unclear in ChristopherJam's suggestion is this: Suppose you have a y-expanded blank sprite, followed by the actual sprite at, say, line $40. And suppose the visible part of the display begins at $4a. It would be kind of messy to turn off y-expansion at line $40, especially if there are several sprites at different y-positions. So what you should do is to also expand the hidden part of the actual sprite! It will now be located at $36, and the first 10 lines (fetched from a blank sprite) are y-expanded. Then, after the VSP, you turn off y-expansion for every sprite simultaneously. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
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? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting lftSo what you should do is to also expand the hidden part of the actual sprite! It will now be located at $36, and the first 10 lines (fetched from a blank sprite) are y-expanded. Then, after the VSP, you turn off y-expansion for every sprite simultaneously.
Sorry yes, that's what I was attempting to suggest! Thanks for clarifying :)
I started drawing some ascii art, but it was getting too bulky. Time to bump that request for a media area for the forums? I still need to fix the half dozen dropbox hosted images I've posted to other discussions :-/ |
| |
knue
Registered: Dec 2012
Posts: 37 |
@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. |
| |
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: 1370 |
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: 421 |
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 ;-) |
| Previous - 1 | 2 | 3 | 4 - Next |
