Jump to content
Qwe

Software sprites: too much complicated on Atari 8-bit

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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
  • Like 1

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by landondyer

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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 by Wrathchild
  • Like 2

Share this post


Link to post
Share on other sites

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 by Heaven/TQA

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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
January 1983 - Text, scrolling
February 1983 - Sprite animation with pre-shifted shapes
March 1983 - Fractional motion calculations, sound effects, overall game structure (Archive.org is missing the first page of the article in the scan)
Edited by FifthPlayer
  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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 by MaPa
  • Like 6

Share this post


Link to post
Share on other sites

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 by popmilo
  • Like 1

Share this post


Link to post
Share on other sites

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).

zone_ranger.gif

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?

 

  • Like 4

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...