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
knue

Registered: Dec 2012
Posts: 11
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....
 
2017-04-27 08:13
JackAsser

Registered: Jun 2002
Posts: 1217
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?
2017-04-27 08:37
ChristopherJam

Registered: Aug 2004
Posts: 601
Quoting lft
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.


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 :-/
2017-04-27 16:17
knue

Registered: Dec 2012
Posts: 11
@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.
2017-04-27 16:58
Compyx

Registered: Jan 2005
Posts: 233
How about having the sprites 'pop in', but when clipping is required, copy only the lines of the sprite that needs displaying into the temporary popped-in sprite.

Takes a bit of rastertime, but at least avoid a lot of timing issues and leaves sprites free on the linecrunch area for a score display.

Once the sprite has gone down enough, switch pointer to the normal sprite.
2017-04-27 17:44
ChristopherJam

Registered: Aug 2004
Posts: 601
Quoting knue
@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.


Thanks! But yes, losing sprites you could have otherwise used for status display is definitely an issue. I was wondering about plotting the status into the blank sprites at a corrected height, but to do that the sprites would need to be unexpanded, so you'd have to set Y at least once per sprite within the AGSP area.

Quoting Compyx
How about having the sprites 'pop in', but when clipping is required, copy only the lines of the sprite that needs displaying into the temporary popped-in sprite.

Takes a bit of rastertime, but at least avoid a lot of timing issues and leaves sprites free on the linecrunch area for a score display.

Once the sprite has gone down enough, switch pointer to the normal sprite.


I was considering that for Hysteron Proteron. It does limit your sprite density, mind. Consider a dense formation of 2x2 sprite enemies; the blank area pushed down from the first row then overlaps the next...
2017-04-27 19:04
knue

Registered: Dec 2012
Posts: 11
dynamically copying stuff costs too much rastertime for a game.

BTW: Fred's back is having the same problemm. You can see that sprites pop in at the top of the screen.

Even Ghost'n'Goblins (although using a traditional scroller) sort of hast this problem. In level 2 when you climb up the ladders, you can see the halfs of the big goblins popping in out of nowhere at the bottom of the screen.
2017-04-27 19:04
Compyx

Registered: Jan 2005
Posts: 233
True, when you add 2x2 sprite 'enemies', you'd indeed get overlap, unless you also render the second line of sprites, having them 'pop in' at 21 pixels from the top sprites.
But that'll take even more rastertime and specialized code, and will seriously screw with multiplexing. So things will get out of hand soon.

So yeah, my suggestion might work for simple sprite patterns (ie single sprites for enemies etc), but not for more complex stuff.

I'm also wondering about how to fix the sprite-pointers showing up in the AGSP-adjusted screen, at those locations (ie $x[37bf]f8-$x[37bf]ff) you can only use colorram and background, not vidram (assuming mc bitmap here).
2017-04-27 19:55
Digger

Registered: Mar 2005
Posts: 240
Could you use one of the illegal modes for $d011 in the upper AGSP area to turn off the screen and hide the sprites behind? Then just switch the sprite priority after the line crunch.
I guess this might not work for some reason, otherwise someone would have already suggested it ;-)
2017-04-27 20:12
knue

Registered: Dec 2012
Posts: 11
I'm already using the illegal screen mode to blank out the garbage you'd normally see when doing AGSP. And no, sprites are nevertheless displayed in illegal screen mode. You can see this effect in my demo I linked in my first post.

EDIT: current version uses a zero-sprite to do the clipping in software - but this screws up the timing at discussed. So you can't really see this effect in action in my current demo.
2017-04-27 20:31
Compyx

Registered: Jan 2005
Posts: 233
You could try to use a DYSP over the linecrunch area. Unfortunately that'll take up most/all of the linecrunch area, so no scoreboard in that area.

I did a write-up on DYSP using cycle-counting via a table: http://codebase64.org/doku.php?id=base:dysp_cycle_table

If you adjust the $d011 table, you should be able to force line crunch. (right now it does a simple FLD).

Switch $d018 to point to 'empty sprites' before the line crunch, switch $d018 to proper sprite pointers after the line crunch.

This will require to do the VSP _before_ the line crunch.
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
Advanced
Users Online
Guests online: 39
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 The Shores of Reflec..  (9.6)
4 Coma Light 13  (9.6)
5 Lunatico  (9.6)
6 Comaland 100%  (9.5)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.5)
2 Daah, Those Acid Pil..  (9.5)
3 Treu Love [reu]  (9.4)
4 Dawnfall  (9.3)
5 SidRok  (9.3)
6 Achtung 5 Years Mayd..  (9.3)
7 One-Der  (9.2)
8 Tunnel Vision  (9.2)
9 Globe 2016 [reu]  (9.1)
10 Safe VSP  (9.1)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.4)
3 Censor Design  (9.4)
4 Crest  (9.3)
5 Arsenic  (9.3)
Top Fullscreen Graphicians
1 Veto  (9.8)
2 Joe  (9.8)
3 Mirage  (9.7)
4 Jailbird  (9.6)
5 Hein  (9.5)

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