| |
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. |
|
... 30 posts hidden. Click here to view all posts....
|
| |
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 |
