| |
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....
|
| |
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: 452 |
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: 1409 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ahahahahaah oh god, I just had a thought. If you had a spare most-of-a-bank for it you could hold the status display stationary by doing something along the lines of a sprite FLD routine.
Just change d018 every line to pick out the VM that points to the sprite definitions for that line of the status display (and have each sprite definition containing 21 repeats of the same line of graphics).
You could even mirror the top and bottom borders of the status area.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting knueI don't get how you can achieve constantly 8 sprites within the AGSP area.
OK, ascii art time.
Say the AGSP area is three lines high, sprites are 5 lines high, and you only want 3 sprites crossing the AGSP area. Then with two enemies entering top of screen, one of which starts halfway through the AGSP area and the other completely crossing it, you position a blank sprite above each of the first three enemies like so:
+----+
| |
| b1 |
| | +----+
+----+ | |
+----+ | b2 | +----+
+aaaaaaaaaa| |aaaaaa| |aa| |aaaaaaaaaa+
+aaaaaaaaaa| e1 |aaaaaa+----+aa| b3 |aaaaaaaaaa+
+aaaaaaaaaa| |aaaaaa+----+aa| |aaaaaaaaaa+
+..........+----+......| |..+----+..........+
+......................| e2 |..................+
+......................| |..+----+..........+
+......................+----+..| |..........+
+..............................| e3 |..........+
+..............................| |..........+
+..............................+----+..........+
+..............................................+
(e1-e3 are enemy sprites, b1-b3 are blank sprites, .... is the play area, aaaa is the AGSP area) You don't really need b1 for timing purposes, it's just easier to do the diagram that way, and possibly easier to code.
The blanks are precisely one sprite-height higher than any border crossing enemy, or positioned to straddle the AGSP area if their corresponding enemy has completely entered the screen.
All that ignores the status display issue of course. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Are the blank and enemy sprites different sprites? (ie B1 = sprite 0, E1 = sprite 1, B2= sprite 2, E2 = sprite 3, etc). Or do you intend to reuse B1 for E1 etc, because that would impact the linecruncher a lot, meaning a lot of code to handle the multiplexing, probably leaving you with enough memory for PETSCII level graphics.
Also, how about the VSP at the end of the line cruncher? I've never tried moving sprites over the VSP, but I suspect that's going to be another nice problem to solve. |
| |
lft
Registered: Jul 2007
Posts: 369 |
If the timing is consistent (i.e. all eight sprites guaranteed to be active), then doing VSP is no problem. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting CompyxAre the blank and enemy sprites different sprites? (ie B1 = sprite 0, E1 = sprite 1, B2= sprite 2, E2 = sprite 3, etc). Or do you intend to reuse B1 for E1 etc.
Reuse B1 for E1 etc. The whole point is to ensure the DMA timing is identical for each line of the AGSP routine regardless of enemy position, so any sprite ever used for any of the lines need to be used for all of them. Doesn't add that much to the multiplexor, cf earlier comments in this thread. (sprites would in practice be blank until the start of the play area for a start; no need to change sprite def mid AGSP area)
As for VSP timing, cf lft's remark. |
| Previous - 1 | 2 | 3 | 4 - Next |
