[CSDb] - User Forums - sprite clipping at the top while using AGSP

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > sprite clipping at the top while using AGSP

2017-04-26 23:07

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....

2017-06-13 08:28

ChristopherJam

Registered: Aug 2004
Posts: 1370

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..

2017-06-13 08:49

ChristopherJam

Registered: Aug 2004
Posts: 1370

Quoting knue

I 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.

2017-06-13 17:06

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.

2017-06-13 18:55

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.

2017-06-14 07:44

ChristopherJam

Registered: Aug 2004
Posts: 1370

Quoting Compyx

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.

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

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

CA$H/TRiAD
AMB/Level 64
rexbeng
deetsay
Earthshaker/Silicon ..
kbs/Pht/Lxt
Guests online: 190

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Webmasters

1 Slaygon  (9.7)
2 Perff  (9.6)
3 Morpheus  (9.5)
4 Sabbi  (9.5)
5 CreaMD  (9.1)

Page generated in: 0.051 sec.