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


Forums > C64 Coding > AGSP - how to use sprite pointers for both sprites and char gfx
2013-06-10 08:47
Oswald

Registered: Apr 2002
Posts: 5094
AGSP - how to use sprite pointers for both sprites and char gfx

just wondering, would it be possible to change screen after sprite pointers have been loaded and before badline operation ? that would solve the problem of visible sprite pointers :)

badline + 8 sprites that is. there is maybe 1-2 free cycle with RMW but where in the line? cant find vic article with google.

or maybe one could write a multiplexer which only allows 7 sprites where critical.
 
... 17 posts hidden. Click here to view all posts....
 
2013-06-11 17:44
Oswald

Registered: Apr 2002
Posts: 5094
Quote: @Doynax+oswald: I know I'm being lame and stupid now, but how does that solve the problem of visible sprite pointers in the GFX while AGSPing?

you keep the sprite pointers constant, and change the sprite data instead, also redefine the constant chargfx as needed.
2013-06-11 17:48
Oswald

Registered: Apr 2002
Posts: 5094
Quote: Quote:
generic ingame sprite multiplexing is a very cool problem to tackle, also having a player interacting with the level and other sprites, and bullets.

multiplexing is not hard - collisions are what gives you grey hair =P


which kind ? player - level, sprite-sprite, sprite char bullet?
2013-06-11 18:13
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Oswald
mayhem had to copy d800 after scrolling 40 chars, thats quite a bottleneck, tho I dont see it doing anything that it really needed that VSP code. It could have been done with a couple of half unrolled screen&color copy code.
Huh.. I always assumed they did something more clever.
I've given AGSP a bit of thought myself but never managed to work out how to spread out the video matrix and color scrolling work very far.
I did have some success generating a 8x16 char-mode, allow for colour double buffering and halving the amount of data to copy.

Quoting Oswald
there's not even more than 8 sprites on screen at once I think - and that tells a lot - having a rasterline where the sprite limit is 6 is certainly not a bad compromise.
Yeah, you're probably right. Mayhem is very pretty but looking beyond that there isn't much tech behind it aside from the VSP.

Quoting Oswald
btw not even 16 bit games kept track of actors offscreen (except some limits) for the usual platformer, thats an overkill imho. usually you just run through the world, you dont need them to have their on lives in it, you kill them or leave them behind and thats it.
I was thinking more along the lines of maintaining "full" physics states for every actor on screen.

You can pretty easily special-case something like an enemy patrolling between two points on a piece of land with simple, fixed, animation in a minimal amount of cycles. Things get rather more expensive when you decide to allow the player to shoot them off of a cliff.

Quoting Oswald
which kind ? player - level, sprite-sprite, sprite char bullet?
Simply detecting basic bounding-box collisions between sprites is fairly easy. You've already got the sprites sorted for the multiplexer so parallel traverse the array looking possible collisions.
For bonus points read out the hardware collision register after each multiplexer IRQ and use that to filter candidates, if you're not doing overlays that is.

Reacting to the collisions in a clean way is a bit trickier but hardly insurmountable.

I've found background collision detection/handling rather more involved.

Quoting Oswald
you keep the sprite pointers constant, and change the sprite data instead, also redefine the constant chargfx as needed.
What Oswald said. To be more specific you reserve a couple of overlapping chars/sprites and use those as the visible pointers by copying in the appropriate graphics as-needed.

Hence the need for efficient caching. Obviously this only works in (non-ECM) char mode.
2013-06-11 20:26
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:
which kind ? player - level, sprite-sprite, sprite char bullet?

i found player-background the most annoying. eg walking on ground that isnt flat. and managing edges properly so you either dont get stuck, cant walk into the background, and dont hoover in the air. YUCK. special cases galore :(
2013-06-11 20:55
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Groepaz
i found player-background the most annoying. eg walking on ground that isnt flat. and managing edges properly so you either dont get stuck, cant walk into the background, and dont hoover in the air. YUCK. special cases galore
Amen :(

You start out thinking you'll just implement a simple, generic, scheme. A height-map for every character type indicating where the ground lies.
But gradually you get bogged down in details of handling objects with width and height, diagonal tile transitions, fast movement, animation glitches, and so on.

Feel free to share any tips on doing this cleanly and/or efficiently, I could certainly use them.

One cute, albeit rather limiting, trick if you've got a separate collision attribute map is to manually extrude the edges ahead of time and pretend that the player is a point-size object.
2013-06-11 21:04
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: Quoting Groepaz
i found player-background the most annoying. eg walking on ground that isnt flat. and managing edges properly so you either dont get stuck, cant walk into the background, and dont hoover in the air. YUCK. special cases galore
Amen :(

You start out thinking you'll just implement a simple, generic, scheme. A height-map for every character type indicating where the ground lies.
But gradually you get bogged down in details of handling objects with width and height, diagonal tile transitions, fast movement, animation glitches, and so on.

Feel free to share any tips on doing this cleanly and/or efficiently, I could certainly use them.

One cute, albeit rather limiting, trick if you've got a separate collision attribute map is to manually extrude the edges ahead of time and pretend that the player is a point-size object.


Brr yeah, classic problem. Extruding the edge is what we did in Pinball Dreams! Anyway, I can only recommend implementing the algo in a simulator in a higher level language that works flawlessly, then port to asm. It requires a great deal of fiddeling.
2013-06-12 00:43
chatGPZ

Registered: Dec 2001
Posts: 11386
one particular annoying thing to get working right was having platforms on which you can jump by standing under them and jumping up through the gfx. this creates some great deal of interesting problems, considering the player can move horizontally at the same time, or hits an enemy on the platform (which throws him down or something like that). very easy to miss something there and then you can suddenly walk through gfx or get stuck or warped up a dozen pixels (because you hacked another problem away like that...)
i think we solved a bunch of things by fixing the leveldesign around the engines shortcomings there ..... =)
2013-06-12 08:35
Danzig

Registered: Jun 2002
Posts: 440
Quoting groepaz
i think we solved a bunch of things by fixing the leveldesign around the engines shortcomings there ..... =)


Cheater! =)
2013-06-12 08:49
Stone

Registered: Oct 2006
Posts: 172
I don't think that's cheating at all. You can spend your entire life thinking up and fixing pathological cases. It's time consuming enough already to write an engine for the c64...
2013-06-12 15:14
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:
Cheater! =)

hehe. i think if you take a closer look at a couple of games... you will find out that all of them do it in one way or another =D
Previous - 1 | 2 | 3 - 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
Magic/Nah-Kolor
Linus/MSL
JonEgg
grip
rikib80
rexbeng
Guests online: 102
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.059 sec.