Jump to content
IGNORED

Software sprites: too much complicated on Atari 8-bit


Qwe

Recommended Posts

The term "software sprites" just means anything that moves around independetly that is rendered in software rather than using hardware, that can be anything from a single character object moving around from cell to cell like early Jeff Minter VIC 20 games to fully masked, objects with pixel accurate positioning... and pretty much everything in between really.

Edited by TMR
  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

I'm kind of curious why you want to use soft sprites, unless it's for ease of porting games. One of the reasons I got the A800 to start with was PMG, which was pretty much unique at the time. I don't think I could have written the one game I did get published with soft sprites. (Cosmic Defender in Analog)...

 

On the 400/800, "Soft sprites" (heck, it's just bitmap animation) potentially give you more colors, and more objects on a line. For instance, in Super Pac-Man pretty much everything is done by animating character graphics cells (all the ghosts, the fruit, etc.), and Pac-Man uses two players and one missile (a 17-pixel wide circle looks way better than a 16-pixel wide one). I think that the eyes of some of the ghosts are done with missiles positioned over the ghost, an effect that nobody ever noticed, but kind of fun to do (and it probably got an extra color).

 

Restricting your moving objects to the hardware sprites is pretty limiting, and I saw a lot of games that fell into the trap of "welp, we've animated all we can with those things, and we're done," the result being a title that looked kind of spare and unengaging. Those objects are just tools, and sometimes you're better off using them as "flair" rather than the primary vehicle for your animation.

Edited by landondyer
  • Like 8
Link to comment
Share on other sites

  • 2 years later...

 

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.

 

i am to a point. working with static variables (sega genesis) is a nightmare

Link to comment
Share on other sites

But then you can copy straight.

 

Lda (sprite),y or lda sprite,x

Sta (screen),y

 

But then you can not overlap sprites.

 

Even without background you can not avoid the eor clashes.

 

Eor sprites are nice because draw them in again and they restore magically the background or prior screen state.

 

Gremlins is a good example how it looks good.

Link to comment
Share on other sites

But then you can copy straight.

 

Lda (sprite),y or lda sprite,x

Sta (screen),y

 

But then you can not overlap sprites.

 

Even without background you can not avoid the eor clashes.

 

Eor sprites are nice because draw them in again and they restore magically the background or prior screen state.

 

Gremlins is a good example how it looks good.

It's a question of game design. If your sprite moves over a fixed platform or else, it looks "not so good" when the bit mixing happens.

When moving objects overlap that way, it won't disturb the presentation that much.

  • Like 2
Link to comment
Share on other sites

You just need to take care that it doesnt get a mess... good examples are on VIC20 most Tom Griner games... esp Predator.

On the VIC20. But the Atari HAS hardware overlay. And it is still not to understand why most people use the part of the hardware that has only low details available for high details , and to use low details where high details would be simply there.

 

A nice multiplexed background via PMG plus a lot of detail moving objects using EOR sprites, would always result in a nice game.

  • Like 1
Link to comment
Share on other sites

On the VIC20. But the Atari HAS hardware overlay. And it is still not to understand why most people use the part of the hardware that has only low details available for high details , and to use low details where high details would be simply there.

 

A nice multiplexed background via PMG plus a lot of detail moving objects using EOR sprites, would always result in a nice game.

Yup. Some Amiga games used multiplexed Sprites for background.

Link to comment
Share on other sites

Didn't know that, but it's a logical thing.

Well, on the Atari the PMg isn't as powerful as the "sprites" on the Amiga.

Ever seen a game, using the PMg for a "scrolling" screen, and a lot of Hires "Sprites", for example?

If people accept some "EOR" clash here and there, using the PMg for the main background... everything is possible. Even using character modes would be possible.

Link to comment
Share on other sites

 

I wonder how one would define a soft sprite?

 

See first post on this page (page 3):

 

The term "software sprites" just means anything that moves around independetly that is rendered in software rather than using hardware, that can be anything from a single character object moving around from cell to cell like early Jeff Minter VIC 20 games to fully masked, objects with pixel accurate positioning... and pretty much everything in between really.

 

I think that covers it nicely ..

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

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.

Good Day! Would it be easy to fix this code to work with TurboBASIC XL or Fast Basic, calling it with a USR? I've just started studying assembly in the last few days and could never do it on my own, unfortunately.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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