| |
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. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I wouldnt mind popping if otherwise it has good playability. You'll get some ppl explaining how 2) can be made working, but you'll need to pay for it with either memory or cpu time or flexibility or some of those combined I guess. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
second option seems extremely tricky (doable, sure...) - for a game anyway (you probably dont want to spend a lot of memory just on this)
if i had to do this, i would probably try something with d017 based sprites stretching.... ie *always* have a certain number in all lines of the agsp area (stretched down), which gives you constant timing. then to make a sprite appear under the agsp switch pointer to whatever you want at the bottom of the agsp, and keep stretching for more lines.
another way would be to simply animate the sprite, that should be much simpler to code, but will either limit your number of sprites a lot, or need a bit of CPU to copy the data into an empty sprite |
| |
soci
Registered: Sep 2003
Posts: 480 |
Do 1) first, then finish off the rest of the game. Now if you're still motivated you may try 2). Then you'll still have something releasable after getting bored trying to get it working.
I only did VSP with variable number of sprites (in Grubz) and it was doable by counter adjusting the delay. The required delay may be looked up in a 256 byte table. There was no need for clipping there.
Try to clip by using a screen which points to all empty sprites while in the AGSP area instead of changing sprite pointers. |
| |
knue
Registered: Dec 2012
Posts: 37 |
thanks for the inpur so far. so to be clear, the clipping itself is not so much of a problem. it's just a matter of:
; enter AGSP region
inc CIA2_DATA_PORT_A
; do AGSP...
; leave AGSP region
dec CIA2_DATA_PORT_A
It's just that the timing within the AGSP region is screwed up.
However, I think you guys are right. I should concentrate on getting the game itself done than concentrating on this detail... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
As an alternate to doing sprite stretching (two d017 writes every line!), you could just precede each sprite with a blank instance.
If the AGSP region was less than 21 lines high this'd be trivial; just put a blank sprite 21 lines above each edge-crossing sprite, add blank sprites to the AGSP area to bring the total up to the max than can cross (I assume no more than seven, if you also have a sprite player), and change VM to unzero all your data pointers as you leave the region.
It'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. The starting position of the empty sprite then runs from y0-84 to y0-42 as y0 goes from AGSP_end_y-21 to AGSP_end_y; a lsr or table lookup will sort that.
The AGSP timing itself is then constant - you always have seven sprite fetches (or whatever your max_enemies_per_line is). Could even drop that to 5 or six if that's too many cycles, and just have only the bottom-most N entering the screen smoothly, with any extras popping in. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
(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: 2014 |
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: 1409 |
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. |
... 25 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 - Next |
