Soft sprites moving in a clean Area

[José Pereira]

Using this XEO3 for simple understanding.

 

Normally Black would be BACKGR. colour register (00) and if soft sprites just go over this clean part it will be much less cycles need.

Now I am wondering if I decide to have the Black as PF0 (01) instead what's the difference in coding and cycles per byte spend?

 

By the way, how many cycles per byte if moving just over clean VS going over gfxs (16vs21)?

Edited December 11, 2011 by José Pereira

[Rybags]

You have to know that the target area is "clean".

 

In bitmap that's not really possible, unless you know certain ranges of X/Y will be blank or you have some underlying map/tile data structure which can flag it.

 

In character mode, 00 is normally a Space/blank so it's a simple test condition.

 

Another speedup - if you're rendering multiple objects to a blank screen then clearing each one, the mask/OR can be skipped for the first object. But that means a seperate routine is needed to do it.

 

For masking you have to: Load existing screen data, do masking, OR with new data, store to screen.

 

Going clean: Load new data, store to screen.

 

Those examples don't consider a "restore buffer" but it'd probably be the same overhead for either.

 

Not doing the masking typical saving is 8 cycles per byte of object.

 

It's all variable though due to different ways of doing rendering, e.g. Brute Force, Strip Sprites, and if it's in bitmap or character mode, and if the sprite/mask data is addressed by indexing or indirect.

Edited December 11, 2011 by Rybags

[José Pereira]

The thing here is, for example, I have the clean parts as (00) and use just soft sprites on the Enemy ships then they would be the same colour as the gfxs.

But if I have the clean dark area as (01) I could use the PMs for Underlays on the gfxs and then the ships would be different colour from gfxs.

 

Now the point is:

Over a clean Background, 48bytes wide screen and 25fps (sprites as 2x2chars size more shifting):

How many of those sized ships can I move if:

-> Over clean using (00)?

-> Over clean using (01)?

Edited December 11, 2011 by José Pereira

[TMR]

The thing here is, for example, I have the clean parts as (00) and use just soft sprites on the Enemy ships then they would be the same colour as the gfxs.

But if I have the clean dark area as (01) I could use the PMs for Underlays on the gfxs and then the ships would be different colour from gfxs.

 

Using players as underlays means you also have to allow for the multiplexing required and the grind needed to clear and write the underlay data as well as the juggling being done for the software sprites. Those overheads are hard to judge without writing a test engine and seeing what it actually needs.

[Rybags]

If you want PF1 as "clean" then it becomes the same as drawing over a detailed background, so the optimisations wouldn't be available.

 

A way around it would be to have a second set of softsprite images with the PF1 stuff added around them, but then that costs more memory, and the rendering would have to check each character to know whether to do the "clean" or "masked" method.

 

No masks needed for "clean" rendering so it doesn't double the memory need, only increases by 50%

[MaPa]

If you want PF1 as "clean" then it becomes the same as drawing over a detailed background, so the optimisations wouldn't be available.

Why not? IMHO it doesn't matter if the "clean" bits are 00 or 01 or 10 or 11 you just need to have soft sprite data prepared for it.

 

A way around it would be to have a second set of softsprite images with the PF1 stuff added around them, but then that costs more memory, and the rendering would have to check each character to know whether to do the "clean" or "masked" method.

Why it would cost more memory? Doest matter if you have soft sprite data 0000xxxx or 0101xxxx or did I miss something?

[emkay]

Well, if you use the PM shapes behind "Playfield 1" , you don't have to handle the background. Which is saving CPU cycles.

 

Set the shapes to the widest, and simply move them horizontally, you can colour up several moving software sprites with it. So no multiplexing of the PM is needed.

 

[José Pereira]

If you want PF1 as "clean" then it becomes the same as drawing over a detailed background, so the optimisations wouldn't be available.

Why not? IMHO it doesn't matter if the "clean" bits are 00 or 01 or 10 or 11 you just need to have soft sprite data prepared for it.

 

A way around it would be to have a second set of softsprite images with the PF1 stuff added around them, but then that costs more memory, and the rendering would have to check each character to know whether to do the "clean" or "masked" method.

Why it would cost more memory? Doest matter if you have soft sprite data 0000xxxx or 0101xxxx or did I miss something?

 

The green part it's PF0 (01) and the soft sprites will only be in those boundaries (there's no touch with spaceship gfxs), like MaPa is saying, the soft sprite would look like this:

01XXXXXX

Rybags says it's still the same because (01) would need the normal Bitmap masking and I understand that (LDA/AND/OR/STA).

(01) it would need the second sprite (the 'inverse' copy)

 

But now I am wondering.

If the sprite just go over (01) then we can just place soft sprites (at least the enemy ones) just like chars.

But because soft sprites move then we can have the 2x2chars (3x3chars with shifting) and then 3copies of them for movement/shifting (preshift).

This way wouldn't be just like changing gfxs chars on screen?

(only more Kbs used because of more Data)

 

This way how many cycles per byte or per char?

Edited December 11, 2011 by José Pereira

[Rybags]

Not going over the non-background stuff means the softsprite can't enter any part of the character.

 

So that means up to 7 pixels vertical or 3 horizontal where there will have to be a gap.

 

In that case a game would need carefully worked movement tables to make sure no overlap could occur, or some sort of test / reversal which would add time and probably make it look ridiculous because objects could just get stuck in places.

[José Pereira]

Not going over the non-background stuff means the softsprite can't enter any part of the character.

 

So that means up to 7 pixels vertical or 3 horizontal where there will have to be a gap.

 

In that case a game would need carefully worked movement tables to make sure no overlap could occur, or some sort of test / reversal which would add time and probably make it look ridiculous because objects could just get stuck in places.

 

Not necessarily, the soft sprite it's always in the chars boundaries.

 

As an example:

-> SS moving right has one more byte for shifting (2bytes wide + 1byte shifting) and it goes one colour clock at a time untill he covers the rightest byte (the shifting one) and it's now close to gfxs. Where's the the mess with the gfxs?

When it fully covered the righest byte, the left one is empty.

 

If the sprite will avoid the gfxs and move up then you still have the right shifting bytes close to the gfxs that step by step will be used for moving it up.

Edited December 11, 2011 by José Pereira

[emkay]

Chosing the shapes with bitmap graphics (or charmode) you could do very much smaller enemies with their "special" colour, apart from the visual background...

The picture has no multiplexed PM, thus no DLI used yet. Vertically you could fill the screen up with "endless" enemies ....

 

[emkay]

Actually, working on "blank" background, you can EOR the sprites and reposition the PMs with some DLI code.

Colourful and "fast as hell" even in ANTIC E....

[José Pereira]

Emkay but the EOR would only work if Blank it's (00) and if it's (00) then there's no way to use large PMs underlays in gfxs nor in the Enemys

[+Eagle]

2bytes wide + 1byte shifting

Jose, I just want to mention that in this case you can use the 9 pixels width for the object.

[José Pereira]

From my previous post:

(soft sprite) EOR (clean space) if (01) as 'clean space':

(00) EOR (01) = (01) K.O.

(01) EOR (01) = (00) K.O.

(10) EOR (01) = (11) K.O.

(11) EOR (01) = (10) K.O.

[José Pereira]

2bytes wide + 1byte shifting

Jose, I just want to mention that in this case you can use the 9 pixels width for the object.

 

Thanks I know that.. you can always use one more (horizontal and vertical)

[emkay]

Emkay but the EOR would only work if Blank it's (00) and if it's (00) then there's no way to use large PMs underlays in gfxs nor in the Enemys

 

It's a little late now

At least you could straight copy the sprite Data on the Screen...

[José Pereira]

Returning to this thing of having PF0 as the clean sky.

 

If the Enemys move in the clean sky and use the PM2&PM3 expanded in quadruple width to get large underlays for the Enemys ships:

Here we have:

Green as P2

Lilac as P3

Pale Green as M2&M3 Multicolour

 

Leaving PM0&PM1 free for our ship as an Hardware sprite only

OR

Our main ship as P0 overlays soft sprite

Weapon Add on as P1 overlays a soft sprite

M0&M1 Multicolour for some laser shots

 

32pixels wide quadruple size PM could get many Enemys but it would need to move PMs but if, like Armalite they always came and move at the same x,y Pos then I don't see a problem, or there is?

Still the same question(s):

How many soft sprites can I move?

(They have always a scripted movement and can this be good to have more soft sprites?)

Edited December 13, 2011 by José Pereira

[José Pereira]

If you want PF1 as "clean" then it becomes the same as drawing over a detailed background, so the optimisations wouldn't be available.

Why not? IMHO it doesn't matter if the "clean" bits are 00 or 01 or 10 or 11 you just need to have soft sprite data prepared for it.

 

A way around it would be to have a second set of softsprite images with the PF1 stuff added around them, but then that costs more memory, and the rendering would have to check each character to know whether to do the "clean" or "masked" method.

Why it would cost more memory? Doest matter if you have soft sprite data 0000xxxx or 0101xxxx or did I miss something?

 

Yes, exactly that.

You don't need to AND & OR. You only need to EOR with the right prepared Data.

 

CLEAN AREA uses 01

then your soft sprite it's 00,10,11

 

But you prepare your Data.

Instead of having two copies of this soft sprite (real & masking) you just need to have one Data of it.

A prepared Data:

SOFT SPRITE EOR SKY:

00 EOR 01 = 00 (transparent gives you sky around soft sprite)

01 EOR 01 = 00 (gives you real soft sprite: 00)

11 EOR 01 = 10 (gives you second real soft sprite: 10)

10 EOR 01 = 11 (gives you third real soft sprite: 11)

 

See, just LDA/EOR/STA,

It also works the same way if the clean area would be other bit-pairs then you always need is to have a prepared soft sprite data

 

 

 

This is only working if your sprite moves in clean area.

But it also works the same way if you touch gfxs with your 'prepared' shifting/transparent that is 00

GFXS are using same bit-pairs as the as the real soft sprite (00,10,11) so it will be:

SOFT SPRITE 'PREPARED DATA' transparent/shifting EOR GFXS:

00 EOR 01 = 01 (gives you sky around gfxs)

00 EOR 00 = 00

00 EOR 10 = 10

00 EOR 11 = 11

(always gives you gfxs)

Edited December 14, 2011 by José Pereira

[Rybags]

EOR looks like arse if it overlaps anything.

 

And if the area is clean, it wastes cycles.

[José Pereira]

EOR looks like arse if it overlaps anything.

 

And if the area is clean, it wastes cycles.

 

About EOR I know, i read it somewhere sometime ago, but, for example Armalyte and many of these type games have that pre-calculated x,y/ scripted movements of Enemys and like that you only would have is the 'transparent/shifting' that can touch gfxs.

Then you have 'our ship' as Multicolour PMG only.

 

And why waste cycles?

If your cleaning area it's (00) and you put your soft sprite above isn't it only OR?

Here you still have the same, just one logical operation that it's EOR/XOR.

OR/AND/EOR don't take the same cycles (isn't it 4cycles?)

 

I see it the same: LDA/EOR/STA that it's 13cycles and not 17cycles (OR/AND instead of just EOR.

If you save 4cycles in each byte then, for 10 soft sprites of 3 x 3chars=3bytes x 24scanlines=72bytes

10soft sprites x 72bytes=720bytes

And that it's 720 x 4cycles = 2880cycles more to use

Edited December 14, 2011 by José Pereira

[MaPa]

If the background is clean, you will do just LDA sprite_data, STA screen (when sprites does not overlap). There is no difference if the background is 00 or 01 or 10 or 11. You will just fill all pixels around the sprite with this "color" when preparing sprite data.

[José Pereira]

If the background is clean, you will do just LDA sprite_data, STA screen (when sprites does not overlap). There is no difference if the background is 00 or 01 or 10 or 11. You will just fill all pixels around the sprite with this "color" when preparing sprite data.

But that was I tried to explain yesterday: http://www.atariage.com/forums/topic/191366-scrolling-shoots-and-attacking-waves/

 

And if sometimes the Attacking waves also have Enemys overlaping others?

[MaPa]

If the background is clean, you will do just LDA sprite_data, STA screen (when sprites does not overlap). There is no difference if the background is 00 or 01 or 10 or 11. You will just fill all pixels around the sprite with this "color" when preparing sprite data.

But that was I tried to explain yesterday: http://www.atariage....ttacking-waves/

 

And if sometimes the Attacking waves also have Enemys overlaping others?

When some objects overlap, then you need full LDA,AND,ORA,STA or shorter LDA,EOR,STA but then the overlapping parts will have strange changing colours.

[José Pereira]

If the background is clean, you will do just LDA sprite_data, STA screen (when sprites does not overlap). There is no difference if the background is 00 or 01 or 10 or 11. You will just fill all pixels around the sprite with this "color" when preparing sprite data.

But that was I tried to explain yesterday: http://www.atariage....ttacking-waves/

 

And if sometimes the Attacking waves also have Enemys overlaping others?

When some objects overlap, then you need full LDA,AND,ORA,STA or shorter LDA,EOR,STA but then the overlapping parts will have strange changing colours.

 

Strange colours only if EOR, right?

Then, we would have always LDA/STA and just do the LDA/AND/OR/STA when there's interaction between the sprites

 

But why is Rybags saying that we have some troubles?

(including the possible sprite and gfxs intereaction even if they don't overlap gfxs it could exist some pixel in one of the bytes touching bytes of the gfxs?)