Jump to content
IGNORED

Software sprites: too much complicated on Atari 8-bit


Qwe

Recommended Posts

Zone Ranger uses eored sprites. Same routine draws and clears sprites. No need for wasting time and memory backing up background.

Works quite well when background is mostly empty.

 

In shooting games with lots of things flying around and exploding all the time color 'mixing' effect of sprite over background is not a problem.

 

Great speed of this approach can be seen in this Cybernoid port:

  • Like 3
Link to comment
Share on other sites

Yeah zone ranger uses "demo coders tricks" means it has so called collum speddcode or unrolled loops for copy data.

 

Shapes are preshifted data, go so as Rybags mentioned... It does a simple load Sprite byte eor with background store result.

 

So it draws sprites in order 1-10 as an example and then erasing it with the eor drawing in order 10-1 and voila... Everything restored.

 

Eor Sprite drawing is common... Look at donkey kong, joust (eggs), drol, gremlins, centipede 5200 etc.

 

What makes zone ranger special is that it used unrolled collum based speed code with dynamic inserting an RTS.

 

Pop... Did I missed that cybernoid port??? Quite fast.

  • Like 1
Link to comment
Share on other sites

Heaven, I think with EOR sprites you can draw and erase in any order, no? I.e. you could draw all objects in any random order and then draw/erase them in a different random order and the background would still be restored.

Think you are right. As long as each sprite is drawn exactly twice (once to draw it, second to erase) order doesn't matter.

Even better, you don't have to draw-erase all sprites every frame. You can leave half of sprites untouched for example and move other half around without problems.

 

Effect is seen clearly on this Amstrad Cpc version of Cybernoid:

 

Hughh.... Wish Atari had 4bit per pixel 160 resolution :)

  • Like 3
Link to comment
Share on other sites

Xuel.... Oh... I thouht that order matters? I could be wrong.... My eor Sprite experiments are from beyond evil times...

 

Think of Sprite 0 eored into background... Then Sprite 1 eored, too... Overlapping partly 0 and background...

 

Now when I am removing Sprite 0 by eor again... Sprite 2 goes there and then I remove Sprite 1 and next frame Sprite 2 it is all intact???

Link to comment
Share on other sites

Consider any individual bit of the display. Say you draw the following with EOR:

 

A = background

B = sprite 0

C = sprite 1

D = sprite 2

 

So, the value of the bit is A^B^C^D. No matter what order you draw, the value of the bit will always be equivalent to A^B^C^D because EOR is commutative.

 

Now say you erase sprite 1. For EOR sprites, this just means you draw sprite 1 again. So, now you have:

 

A^B^C^D^C

 

Rearranging we get:

 

A^B^D^C^C

 

The C^C cancels out to 0 leaving A^B^D^0 or just A^B^D which is the same as if you just drew sprite 0 and sprite 2. So you can see that I didn't have to erase sprite 2 before I am able to erase sprite 1.

  • Like 5
Link to comment
Share on other sites

Now it's my time to say something :grin: , what do you mean by EOR/XOR?

Only moving over [00] at the start you only need an AND then next to restore the background again what?

From that Amstrad CPC version of Cybernoid haven't we also parts that go over the gfxs like our ship add-ons weapons? Then here is what? Something pre-defined/pre-shifted?

 

P.s.- Thanks to Jac! I discouvered sometime ago that on C64 version of Cybernoid(s) there is an interesting 'way of doing'.

Using their nice bitmap multicolour mode they could have lots of sprites because they are gfxs tiles when they are not moving and then when they move they turn into hardware sprites. This way you can have lots that indeed aren't more than 8 hardware sprites when they are moving.

This seems the reason why our ship and enemys ships have the same three colours because maybe they didn't want and probably wouldn't look good that with that lilac/blue enemys each had a 3rd own colour (I only see this own colour probably be their darker gray in the enemys outside/contour of their shapes like for example we have on many C64 shoot'em'ups).

Still never got anyway this method could and would be usefull in A8 with ours only 2multicoloured sprites and not possible to have different colours per char.

Edited by José Pereira
Link to comment
Share on other sites

Humm I think that the C64 technic I refered is, maybe, only only in Cybernoid II, in I they seem to have sometimes multiplexing of the enemys ships hardware sprites.

But in I there's still the same 3colours in our ship and all enemys hardware sprites that are blue, lilac and white.

In II they have on enemys the C64 one own colour per sprite as gray instead of our ship lilac.

Still interesting that they're changing of the enemys from gfxs to hardware sprites in II when given them the possibility to freely move and have different colours over the gfxs :).

Link to comment
Share on other sites

There is one notable drawback to this approach.

No matter what order you draw your sprites, they really don't appear over the top of each other.

The color just changes.

Yeah it does, but as in Zone Ranger, when movement is fast and most of background is black - you don't see those wrong colors, most of all when you keep dying a lot ;)

 

This Eor method was very popular on Spectrum because it's super fast compared to proper masked sprites. No need to save background, no need to think about drawing order, no need for masking, you just draw sprites anywhere and delete them when they move or need to disappear.

  • Like 1
Link to comment
Share on other sites

Yeah it does, but as in Zone Ranger, when movement is fast and most of background is black - you don't see those wrong colors, most of all when you keep dying a lot ;)

 

This Eor method was very popular on Spectrum because it's super fast compared to proper masked sprites. No need to save background, no need to think about drawing order, no need for masking, you just draw sprites anywhere and delete them when they move or need to disappear.

Yeah, I wish I had known about that when I was a kid. I used double buffering, saving the background, all sorts of stuff and I could have just drawn and erased my sprites very simply.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

Probably because the PMG is not powerful enough?

I couldn't imagine to make a game these days without soft-sprites :)

  • Like 3
Link to comment
Share on other sites

Very true but for the 8 bit Atari it took a tremendous load off the processor. It sounded like his intent was to program for the 800 or 5200. PMG was a hardware based sprite that really made the Atari much more powerful than the Apple II or Commodore in it's day.

Link to comment
Share on other sites

Really? I can.. none of my games uses soft sprites and I don't think they are that bad ;) Btw. your MJO does not use soft sprites either I think?

Then you haven't far enough :) There are some spiders which use soft-sprites. Although very very basic. Not so fancy stuff as Heli, Ditch and HAR'em :)

Are you sure that RGB dosen't use soft-sprites? Or is your definiotn of soft-.sprites "freely moveable over teh background with saving and restoring the background"?

I was refering to any rendering of moveable objects with chars or bitmap. :)

 

 

Very true but for the 8 bit Atari it took a tremendous load off the processor. It sounded like his intent was to program for the 800 or 5200. PMG was a hardware based sprite that really made the Atari much more powerful than the Apple II or Commodore in it's day.

In the beginning of the 80's that is correct. Some month ago I have played some games of that area. In a time when one colored objects with a coarse resolution is acceptable, PMG is the bomb. But mid/late 80's I think this wasn't acceptable anymore.

 

 

 

EDIT:

Let me rephrase my statement from above. Games I want to make ATM are unthinkable without soft-sprites. :P

Edited by Creature XL
  • Like 2
Link to comment
Share on other sites

...In the beginning of the 80's that is correct. Some month ago I have played some games of that area. In a time when one colored objects with a coarse resolution is acceptable, PMG is the bomb. But mid/late 80's I think this wasn't acceptable anymore.

Agreed. 5 Players x 8 pixels in one color couldn't compete on any level with what coders on other machines were doing in late 80s.

 

Fortunately, there are still some tricks left unused in A8s arsenal, and most of them are using some sort of PM+bitmap graphics.

 

Imho, simple xor sprite routine can be simpler than PM based one, and can produce much more than 5 sprites in line in more colors.

Guess it's time to code something or shut up :)

  • Like 2
Link to comment
Share on other sites

Then you haven't far enough :) There are some spiders which use soft-sprites. Although very very basic. Not so fancy stuff as Heli, Ditch and HAR'em :)

My bad, probably I didn't get that far in MJO then as I don't remember any spiders

 

 

Are you sure that RGB dosen't use soft-sprites? Or is your definiotn of soft-.sprites "freely moveable over teh background with saving and restoring the background"?

Your definition in quotes may be applied only to enemy robots shots (char bullet) which is saving and restoring background char. But the robots are lazy to do even that as there is no background behind them. It's pure copying of 8 predefined chars per robot to video RAM, no char redefinition on the fly :)

 

To me software sprites means interaction with background, EORing, masking etc. not just pure copying data around (you do that with PMG too if you animate them or move in vertical direction).

Link to comment
Share on other sites

But the robots are lazy to do even that as there is no background behind them. It's pure copying of 8 predefined chars per robot to video RAM, no char redefinition on the fly icon_smile.gif

 

To me software sprites means interaction with background, EORing, masking etc. not just pure copying data around (you do that with PMG too if you animate them or move in vertical direction).

 

I understand why you're differentiating, but there should be a common term you can use to discuss them. They're not hardware sprites.

 

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