Sprite Routine Development (for Atari 8bit)

[analmux]

Well, just to open the development thread for (software-)sprites on the Atari 8bit.....

 

Here we can discuss, post sourcecodes, show demos and other things, for optimization of sprite-routines.

 

The aim of this thread is to discuss the techniques for displaying a maximum number of sprites with reasonable coloring palettes and fastest (and smoothest) movements.

 

Think about character mode software sprites (antic 2, 4,5,6,7) or graphics (antic E,F).

 

Eventually when things become really constructive, we can organize some kind of contest for the best sprite routine, but this is just optional.

 

This is inspired on recent discussions on Bubble Bobble (port by Tezz), and there are some coders interested in working on this.

[Heaven/TQA]

i will post the source code of my sprite multiplexor based on c64 technique for hardware sprites and if it is still working my sprite routine for antic e based on my time pilot demos...

 

(if WOW will let me do... )

[Shawn Jefferson]

I'm wondering how you would move a software sprite in antic 4 that used a PM underlay. Would you use DMA mode, or stuff the GTIA player register yourself? You would also have the problem of moving DLIs around too, or use one big DLI (wasting a lot of time with wysncs?)

 

I wonder when the time taken by PMG DMA would exceed the time taken by having to deal with DLIs to stuff the player shape register?

[danwinslow]

I don't think you can do software sprites of any significance on a8 and still have any processor left over. The dang thing is just too slow.

[Jetboot Jack]

danwinslow - I uesss that rules out all the games done on the A8 that DO use software sprites from Donkey Kong to Joust by way of Spy vs Spy and Drol to The Eidolon and Koronis rift!!!!!!!!!!

[mariusz]

I'm very happy to see You here Jet! Almost every day I look at Your site>video game pages>old video games>Atari 8bit Projects – Independent Days>Last Ninja II – for System 3 (Coming Soon -- maybe) and I say to myself "..oohhh not yet" Will I someday scream YYEEESSSSS!!! I hope so. Still waiting.

[Wrathchild]

Remember, now we have the luxury of large bank switchable carts,

images can be pre-created at multiple X/Y positions and then the

correct image extracted directly when required, cutting out the need

for large numbers of shifts preparing the sprites.

[Shawn Jefferson]

Remember, now we have the luxury of large bank switchable carts,

images can be pre-created at multiple X/Y positions and then the  

correct image extracted directly when required, cutting out the need  

for large numbers of shifts preparing the sprites.

 

Yes! I was thinking this when I was reading the Out Run thread.

 

Still, if you are going to use software sprites WITH pm overlays, you still are left with the problem of positioning the pmg appropriately.

[Shawn Jefferson]

Remember, now we have the luxury of large bank switchable carts,

 

Sorry for the double post, but I was just thinking...

 

Emkay's ideas with regards to putting the fonts on the screen and then writing in the font area. One of the issues with doing this is the calculations required to position things properly. With a large bank switched cart, you could create tables for this. It would be a big table, but that would make your engine that much quicker... and no worries about running out of characters to refine.

[Wrathchild]

Think back (and find the thread ) for the W.C.Leaderboard work I did.

I think a good trick here is to use colour 3 as the background. This then

makes the usual background colour available for the foreground (?!)

The borders can then be made by overlaying the missiles, so you lose

in that respect. Conclusion - don't always go for black as the obvious

background colour.

 

Think further back and the Barbarian work shows that, with careful

design of the player's software sprite, the animation frame resolves

itself on char (4 pixel) boundries.

 

Food for thought.

 

Regards,

Mark

[danwinslow]

danwinslow - I uesss that rules out all the games done on the A8 that DO use software sprites from Donkey Kong to Joust by way of Spy vs Spy and Drol to The Eidolon and Koronis rift!!!!!!!!!!

 

Well...I guess I am wrong in my opinion. Although I was thinking of a *lot* of sprites, ie., 30 or so on one screen. I still think that would be pretty hard to do. And before you ask me wth anyone would need that many sprite for a game, there's plenty of examples from the gaming world.

[Sheddy]

I'm wondering how you would move a software sprite in antic 4 that used a PM underlay.  Would you use DMA mode, or stuff the GTIA player register yourself?  You would also have the problem of moving DLIs around too, or use one big DLI (wasting a lot of time with wysncs?)

 

I wonder when the time taken by PMG DMA would exceed the time taken by having to deal with DLIs to stuff the player shape register?

 

I'd think not a lot of point stuffing the data registers yourself - the DMA is very efficient at stuffing the data - only 1 cycle per player per scan-line. It can't do it automatically more than every scan-line though. The linear memory area of each player is quite quick to move around with the proc. You'd need to have a similar arrangement anyway to do it manually.

Also, doing it manually you going to have to keep tight reign on where in your prog you are for every scan-line - IE a 2600 type kernel. This zaps a lot of potential cycles.

 

Main problem I see with player overlays/underlays for sprites is what to do when you run out of them? 4 or 5 single colour, skinny players a line just won't cut it for a lot of games - you need to design something that is pretty contrived to make use of them that way. So, just don't display the underlays players when there's too many soft sprites on the scan-line?

[Jetboot Jack]

mariusz - well you'll be waiting a fair old time for that, and for the other unshown stuff...

 

My A8 collection has been officially retired in the face of relocating back to England to start a new job - and I doubt I'll ever get them out of moth balls - its nice to remember the past but not live there

 

I keep looking in on Atariage, just to see what new games are around, see what new ideas there are and who is still contributing, but I'm maintaining my offline status 98% of the time

 

sTeVE

[Heaven/TQA]

ok... here is an old source code written dec 2003...

 

it moves randomly players around...

 

the flickering is because when there are more than 4 virtual sprites on a scanline. at the moment the mapper does not disable them...

 

www.student.oulu.fi/~loorni/covert/rants/sprite.htm

plex4_16.zip

plex4_8.zip

[Heaven/TQA]

forget the last one...

plex5.zip

[Heaven/TQA]

here is another debugg version (oh... have some coding time while i am waiting for download completion of the german world of warcraft patch...)

 

just for the guys who are not familiar what i am doing...

 

i am searching for a flexible player missle engine which would be possible to use the hardware sprites as clever as it can for displaying more sprites than possible...

 

the white lines are the DLI zones where the engine is setting DLI bits... in this zones it then mappes the virtual players into the 4 available hardware sprites... it checks if there are conflicts in terms of overlapping and then should skip sprites who overlapp...

 

a good reference for this method is the one link i have posted... this method (which sorting) is also used on gameboy (GB;GBA,SP) and amiga or C64...

 

but i found a similar hardware with this 4 sprites per scanline restriction and this is the MSX-1... if you search the net or the atariage forums i have mentioned years ago the so called "ring buffer concept" konami is using in their gradius games f.e.

 

on atari i can just recall one game which i am trying to analyse and understand now for more than 10 years (and basicly this is why i want to ocde an engine similar to this as well)... is joust... the joust are players and the spikes are missles... the background is antic e so are the eggs... and you see the "ring buffer flickering" when more than 4 players are in one scanline... this ring buffer method is still missing in my engine...

plex5.zip

[Heaven/TQA]

damned...forgot to mention that the hardware players are filled with no. 1-4 so you can see how the engine is projecting the virtual sprites on them... in general you would not notice that the engine is using different players but you just see the sprite moving around...

[Heaven/TQA]

try to play joust at expert level right from the beginning...soon you have more than 3 enemies per line and you see how the engine starts to flicker through the virtual sprites...you can press space to stop the action (but the gfx engine is still working...so it gonna flicker in pause mode as well...)

 

entering the monitor by browsing through the dlist via DLIST command you gonna see the DLI bits...

 

now lets have a look @ $0200 where the DLI routine is... and voila... there is the position code... ($a4ca)

 

now play around with the DLI via build in assembler... it's interesting that when f.e. switching off players or whatever the joust engine is working internally with the sprites only...so the visible part is "just for the viewer"... f.e. you can see collisions even there is no sprite there (but you can notice it via the spikes which are missles)

 

and when watching closer the DLI routine you gonna see that there is no DMA code for feeding GTIA the player data...

[Heaven/TQA]

at $0f00 you have the sprite data for joust... just enter F 0f00 0fff aa and you see just line instead of the sprites...

[Heaven/TQA]

ok... 58% of wow patch downloaded... aarg... so here more joust revers engineering:

 

at $a2d9 there is lda #$0b = 12 bytes per sprite to copy...if you change this value f.e. to 6 than you realise that one sprite is just copied half... but it its interesting... the joust engine seems to work similar to my engine as when flying around you see how this "half sprite" is flipped through the players on screen...

[Heaven/TQA]

new version v6:

 

- handles 16 virtual 8x8 sprites

- each one has it's own adress field so can have unique shape

- ring buffer (flickering) not implemented yet for more than 4 sprites per scanline

- timing issues cause some garbage on screen due to non optimised code

 

i hope you get my idea...

plex6.zip

[danwinslow]

By 'ring buffer' do you mean a way to cycle through the sprites and only display them when you can? Ie., if 8 sprites on one pass you show 1-4 and on the next 5-8.

[Heaven/TQA]

yes. exactly. not sure how to handle this in a nice way.

[emkay]

Emkay's ideas with regards to putting the fonts on the screen and then writing in the font area.  One of the issues with doing this is the calculations required to position things properly.  With a large bank switched cart, you could create tables for this.  It would be a big table, but that would make your engine that much quicker... and no worries about running out of characters to refine.

 

 

Why "a big table"?

 

As I mentioned in the 8-bits board, you can always use DLIs...

 

You have a starting position for the "Sprite" , and you have to move the shape of a player ....

Setting the player-shapes for 8, 16 or even 200 lines would only cost 10 cpu cycles each player... no DMA-> no Cycle stealing here, and no memory is used.

The most complex thing would be, to set the used dli's by the y-coordinates of a sprite. Even this can be done by a simple sorting routine(switching every 8th scanline) , or by some Level data.

Having a look at the C64.... every screen that uses up to 16 colors, has to do the same calculations. And, mostly the C64 program fit into the 64k while on the ATARI the level have to be loaded from disk.

 

Having another look at this picture:

You see 8 violet bats... they are softwaresprites already in the original game.

To have them violet, player and missile 3 are used for all 8 bats. This means 10 cpu cycles to have the screen more colorful here.

The shots are underlayed by P&M2 . So if the shot crosses the bats, it stands yellow-red, because the pm priority is set.

to have the shots coloured, every shot with pm underlay uses 10 cycles:

5 to set the postion, 5 to set the position new.

The shots would even look fairly enough, if they were eor sprites, which saves several cpu cycles, because the pm shapes are stable in their colour.

[Heaven/TQA]

Emkay, can you please post a screenshot of g2f mockup screens just the antic 4 screen and just the pm data separate?

 

it makes it more visible how the pm data is handled in your example.

 

thanks.