Software sprites: too much complicated on Atari 8-bit

[Qwe]

Hi friends.
I like coding on Atari 8-bit but it's very complicated respect other platforms.
Coding sprite on Atari ST is very easy; the CPU has instructions for making divisions and calculate the coordinates of the sprite in memory is a breeze.
I found several examples for Atari 8-bit but are not suitable for beginners, I don't like sources that use the pseudo instructions of MADS compiler.
Does anyone know where to find any good tutorials to make sprite?
Thank you

[Rybags]

It's not that much harder. And I don't see the logic in using division instructions, they take lots of cycles.

On both 6502 and 68000 all that's needed is bitshifts, AND instructions and additions to calculate addresses and offset for the softsprites.

 

What 6502 is lacking is instructions to do multiple operations or to do post-incrementing. But really, the principle of doing softsprites is virtually the same. The main differences being that the memory layout for bitmap is linear on the A8 rather than interleaved bitplanes on ST, and that A8 also has character modes.

Softsprites are more complex to render in character mode but the restore process is much easier and faster.

 

There's various threads around, there are multiple levels of complexity of programming for softsprites with the criteria generally being how much memory do you want to spend and how much CPU do you want to save... the obvious tradeoff being that the more memory you devote the faster you can make the process.

[Franco Catrin]

I'm sort of beginner on software sprites, from that perspective and without going into to much technical detail, here are some advices:

 

• First and most important: Don't mix math code with sprite code. It will be easier to program and optimize when the time comes if they are separated. The following advices are just derivates from this approach.
• The Atari/6502 doesn't have mul/div, but the factors are always the same, for example 40 bytes per scanline. Use precalculated tables for screen positions, then you need to setup one register index to read the multiplied result.
• Rendering at pixel precision can be hard too. Precalculate the rotations needed, then the rendering code will be straightforward

[Grevle]

I wonder how one would define a softsprite ? Can a softsprite move over backround graphics without erase the backround ? Maybes theres different types of software sprites ? Softwares sprites collision detection ? all based on the position of the softsprite ?

[Bryan]

I wonder how one would define a softsprite ?

 

Something moved around the screen by drawing and erasing it in the playfield.

 

 

 

Can a softsprite move over backround graphics without erase the backround ?

 

No, a software sprite requires management of the background (if there is one).

 

 

 

Maybes theres different types of software sprites ?

 

Sure. People have made hundreds of sprite routines for the A8.

 

 

 

Softwares sprites collision detection ? all based on the position of the softsprite ?

 

Only if you write the code to do it. It's the same thing as writing an Apple II, Spectrum or VGA game. There are no sprites on those systems, so you do it all with code.

[landondyer]

Why would you need multiply or divide to position a sprite? (If you're using floats for coordinates you're probably leaving a lot of performance on the table. Consider using fixed point).

 

Actually doing the masking and rendering operations is similar on both CPUs, though the 68000 can do them faster. On both platforms you probably want to pre-shift images, unroll loops, etc.

 

I found collision detection based on multiple bounding boxes to be cheap and good for tuning the player experience. Pixel-perfect collision detection isn't very friendly (for instance, every time I saw someone lose a life in Caverns of Mars when one of the ship's pixels hit the cavern walls, I died a little inside; what an awful way to treat a player).

Edited September 9, 2015 by landondyer

[Rybags]

Agreed on the lack of generosity - what that game and many others needs is a "persistent collision" policy - ie, for the player to die you need contact for 2 frames.

Though such a method wouldn't work in many cases, especially those where motion is fast enough or the size of objects is small enough that they'd only ever contact for a single frame in most cases.

[pirx]

You could get *mads* http://mads.atari8.info/- there is a nice software sprite engine there ready to use. It's a perfect starting point.

[Grevle]

So a software sprite is basically using assembler and the playfield colors plotting pixels in certain shape and moving it around withing the VBI for smooth movement, And if there is background graphics to move over it has to be managed by software, and one can use Players or missile layover to add some more colors ?

[Wrathchild]

Can a softsprite move over background graphics without erase the background ?

 

 

 

No, a software sprite requires management of the background (if there is one).

 

There are cases where it doesn't have to.

 

Factors from the rest of a program's display routines are going to affect the implementation of the software sprite engine employed. Three examples of these would be scrolling, buffering and colour choice.

 

Where a double-buffered technique is used and assuming the background is re-drawn or more cleverly replaced where required - then soft-sprites can be drawn using just their mask and data.

If the colour choices permit, then a mask may not even be required but this could be very limiting, e.g. you'd have a background colour, one playfield colour and two for the sprite or vice-versa.

 

With regards to masking, there is also the option/trade-off of (a) storing masks of all sprites in memory or (b) deriving a mask from the sprite data.

e.g. a factor in this could be 'does the sprite data include the background colour'.

If, yes - the mask needs to erase the background for that point. If no, - masks can be obtained from a page long lookup table.

 

For (a) the trade-off is more code space vs faster processing

For (b) savings on code space vs potentially slower processing

 

Your target platform also can influence this. Using more than 48/64K you can store more sprite/mask data so permits (a). Similarly if you use a bank-switching cartridge.

 

A third option if space isn't a problem is to 'un-roll' the code for the drawing of the sprites, which can reduce indirect and indexed lookups and hence provides a faster routine.

This is where clever macros, such as those supported in MADS, can assist as they can be used to generate code or data memory from data read from other files.

Edited September 9, 2015 by Wrathchild

[Heaven/TQA]

coding sprites on ST with interleaved bitplanes???

 

I guess concept is on both the same...

 

you have shifted versions of data to position pixel precise, you got an AND mask to erase background.... etc... I guess it's "easier" on ST because the 68k is faster... so penalties are not that quickly hit...

 

 

but where is the difference of

 

LDA screen,y

AND mask,x

ORA spritedata,x

STA screen,y

 

compared to

 

move.w (a1),d0

and.w (a0),d0

ora.w (a2),d0

move.w d0,(a1)

Beware, I am not so familiar with 68k.

Edited September 9, 2015 by Heaven/TQA

[Qwe]

My problem is that I haven't found examples for beginners.
I don't need optimized code, I need an example that explains how things run on 6502. The sprite engine written by mads team is very good but it is commented in polish and code is very advanced.
There is a big difference between a tutorial and a sample code.

The learning curve is very steep if you need to do the reverse engineering of an algorithm.

Probably I found good tutorials for Atari ST but I think that coding a 68000 is easier.

[Heaven/TQA]

1. setup bitmap screen (e.g. gr.8 or gr.15), 40 bytes per line (320x res)

2. assuming a 32x32 sprite, means 8 pixel per 1 byte... so 4x32 bytes

set sprite to coords 0,0 without restoring data

 

lda data

sta screen

lda data+1

sta screen+1

lda data+2

sta screen+2

lda data+3

sta screen+3

lda data+4

sta screen+40 ;next line

lda data+5

sta screen+41

....

 

same like

 

LEA data,a0

LEA screen,a1

 

move.b (a0)+,0(a1)

move.b (a0)+,1(a1)

move.b (a0)+,2(a1)

move.b (a0)+,3(a1)

move.b (a0)+,40(a1)

 

I guess this will throw bombs on ST and Guru on Amiga as byte adressing on odd adresses but you should get it...

 

[Heaven/TQA]

fire up Turbo basic...

 

try this and type

 

gr. 8

 

poke dpeek(88)+x+y*40,$ff

 

so you get a feeling for the adress space of a standard bitmap screen.

[Jetboot Jack]

Qwe - try starting with this: http://www.atariarchives.org/agagd/chapter8.php

 

One of the best books from way back when I started playing with making my own games - Atari Graphics & Arcade Game Design By Jeffrey Stanton with Dan Pinal

 

sTeVE

[kiwilove]

What games serve as good examples of this technique? Say - simple use of, and complex use of, and use of both hardware and software sprites used cleverly together.

 

ANALOG magazines did have machine code games with their source code published - but I don't know of any game of theirs that used this technique that was published?

 

Harvey

[FifthPlayer]

If you'd like a tutorial on software sprite programming, an excellent one ran in Creative Computing back in 1982 and 1983.

 

David Lubar, a developer of several games on Apple and Atari platforms, wrote a series of articles called "The Graph Paper" about programming arcade games on the Apple II - including software sprites.

 

Since assembly code was the only way to produce fast sprite animation on the Apple, it goes into considerable detail for all the 6502 tricks that were employed for speed. I remember reading these articles BITD and they were very enlightening.

 

I've included Archive.org links for the later articles in the series, which focused on software sprite programming. Other than the Apple's weird 7-bits per byte pixel packing, and strange memory layout for its hi-res frame buffer, just about all the techniques for sprite animation are applicable to the Atari. Of course many techniques described in these articles, such as scrolling and sound effects, are much better done with the A8's hardware support.

 

July 1982 - Introduction

August 1982 - Shape tables

September 1982 - Shape table animation, page flipping

October 1982 - Collision detection, controllers, last column to focus on BASIC

November 1982 - Assembly language overview, calling BASIC routines for lines and shapes

December 1982 - Assembly language bitmap (sprite) rendering

https://archive.org/stream/creativecomputing-1982-12/Creative_Computing_v08_n12_1982_December#page/n379/mode/2up

January 1983 - Text, scrolling

https://archive.org/stream/creativecomputing-1983-01/Creative_Computing_v09_n01_1983_January#page/n293/mode/2up

February 1983 - Sprite animation with pre-shifted shapes

https://archive.org/stream/creativecomputing-1983-02/Creative_Computing_v09_n02_1983_February#page/n247/mode/2up

March 1983 - Fractional motion calculations, sound effects, overall game structure (Archive.org is missing the first page of the article in the scan)

https://archive.org/stream/creativecomputing-1983-03/Creative_Computing_v09_n03_1983_March#page/n265/mode/2up

Edited September 10, 2015 by FifthPlayer

[ac.tomo]

 

To be fair, software sprites aren't the easiest things to code, I mean for a beginner machine-language coder it's not on the 1st thing to accomplish list (ability wise) that's why. for this reason, over the years, ever since the 80's people have tried to increase the capabilities of the Atari's hardware sprites and something that helps improve them, namely; DLI's. One can accomplish quite a lot with just these 4+4 hardware sprites & DLI's, & at that end, it can all be done via BASIC. That's not to say you can't use software sprites, it's just, because they are not the easiest thing to accomplish, there are many, many articles in many magazines explaining the subject of hardware sprites and how to get the most from them, which usually require DLI's & hardware timers in order to achieve things, that initially you might think impossible.

[MaPa]

IMHO software sprites are not that complicated. It's just simple LDA, AND, ORA, STA sequence for each byte and just calculating the right position to video memory and softsprites data.

 

I attached simple softsprite routine in graphics mode (not character mode). Actually it's my first test on software sprites which I did 8 years ago (in 2007). I just replaced all (at least I hope) XASM specific instructions to pure 6502 language. it uses just some specific directives for tables and data generating. The sprite data at the end are that each line is 4 bytes for sprite data, 4 bytes for mask data of that sprite and then 3x the same shifted.

 

But till today I think that I didn't use real software sprites (object moving over background) in any of my productions.

 

Best would be if you specify what exactly you have problem with.

softsprite.zip

Edited September 14, 2015 by MaPa

[popmilo]

IMHO software sprites are not that complicated. It's just simple LDA, AND, ORA, STA sequence for each byte and just calculating the right position to video memory and softsprites data.

Yeah, that's basically it. Problems begin when you want to draw dozen of them, scroll screen, want to make it faster and need to fit hundred frames in limited memory Edited September 14, 2015 by popmilo

[Heaven/TQA]

Yeah... Then you turn to c64 or Amiga....

[+Stephen]

Yeah... Then you turn to c64 or Amiga....

Shame as we have Veronica, Rapidus, VBXE, etc.

[Heaven/TQA]

true...

[+therealbountybob]

We're playing Zone Ranger in the HSC - great game with loads of moving graphics that seem to float over the playfield (watch on title screen as they go over the titles).

The game is very slick and no slowdowns, like in Drol etc, when there's a lot on screen - take the warp to level 7 on the first level to see more items sooner

 

Would this game be a contender for the best example of software sprites?

 

[Rybags]

Heaven posted a thread about Zone Ranger. It uses a brute-force Ram based method for rendering the softsprites.

Costs a fair bit of Ram but the return is you get almost the fastest rendering possible.

 

From memory there's a routine that covers every possible Y position with the load/store operations embedded. Before calling, an RTS is inserted at the relevant point and the entry point is variable depending on Y start position. Then once returned, restore the RTS to what was previously there.