Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > C64 Coding > sprite clipping at the top while using AGSP
2017-04-27 01:07

Registered: Dec 2012
Posts: 21
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:

Thanks in advance for any help.
... 25 posts hidden. Click here to view all posts....
2017-04-29 21:54

Registered: Sep 2005
Posts: 233
Ah, I see, so you could not have stuff in the borders. Makes sense.
2017-05-16 16:37

Registered: Sep 2005
Posts: 233
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?
2017-06-12 15:12

Registered: Dec 2012
Posts: 21
I don't get how you can achieve constantly 8 sprites within the AGSP area.
2017-06-12 20:37

Registered: Apr 2008
Posts: 227
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?
2017-06-13 10:25

Registered: Aug 2004
Posts: 655
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.
2017-06-13 10:28

Registered: Aug 2004
Posts: 655
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 10:49

Registered: Aug 2004
Posts: 655
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 19:06

Registered: Jan 2005
Posts: 271
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 20:55

Registered: Jul 2007
Posts: 303
If the timing is consistent (i.e. all eight sprites guaranteed to be active), then doing VSP is no problem.
2017-06-14 09:44

Registered: Aug 2004
Posts: 655
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
RefreshSubscribe 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
Users Online
E$G/I-IokutO ForcE
Fix/[HF] + [ONS]
Guests online: 73
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Lunatico  (9.6)
6 Quad Core 100%  (9.5)
7 Comaland 100%  (9.5)
8 Incoherent Nightmare  (9.5)
9 Wonderland XII  (9.5)
10 Comaland  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.6)
2 Synthesis  (9.6)
3 Dawnfall V1.1  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Field Sort  (9.4)
6 Treu Love [reu]  (9.4)
7 Dawnfall  (9.3)
8 Globe 2016 [reu]  (9.3)
9 KAOS 64  (9.3)
10 Hardware Accelerated..  (9.2)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 Oxyron  (9.4)
4 Crest  (9.3)
5 Finnish Gold  (9.3)
Top NTSC-Fixers
1 Horizon  (9.7)
2 Pudwerx  (9.6)
3 Stormbringer  (9.6)
4 Fungus  (9.6)
5 Moloch  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 1.117 sec.