Page 1 of 1

Sprite transparency

Posted: Fri Dec 30, 2016 8:33 pm
by pser1
Hi,
I am kidding on a 'potentially' new project that involves moving a sprite along the screen ...
I have the background drawing, the sprite in four images to show in sequence to move it right or left
This has worked with a rectangular sprite, but as soon as I changed it for a real character
problems arose!
The figure has the external part white color (it is in PMode4) and so it overprints the background.
The background gets restored as soon as the figure moves, no problem.

Is there any way to make these white parts *transparent*?
I would appreciate any idea, solution or any url to learn how to do it!
Testing it in assembler right now
Thanks in advance!

cheers
pere
Happy new Year 2017

Re: Sprite transparency

Posted: Fri Dec 30, 2016 10:19 pm
by sixxie
You have to AND the background data with a mask, OR in the sprite data, then store it back.

(Mask is 0s for the shape of your sprite, else 1).

Tip: modifying 16 bits at a time, you can use ADDD instead of two OR instructions:

Code: Select all

	ldd	,x
	anda	#$0f
	andb	#$fc
	addd	#$0aa8
	std	,x

Re: Sprite transparency

Posted: Fri Dec 30, 2016 10:41 pm
by pser1
Hi Sixxie,
thanks a lot.
So there is no better way ...
As my sprites are surrounded with white color (bit=1), I will need
to change them to zero so that when I add the sprite to the background byte
that has been previously anded with the mask, it ends up with *only* the real
character bits added.
And of course it implies double RAM size for the each sprite.
All in all it is a a good solution despite it implies quite some previous work to do.
Again, thanks a lot!

cheers
pere

Re: Sprite transparency

Posted: Sat Dec 31, 2016 12:59 am
by Bosco
Sounds intriguing Pere. :)

As for sprite masking, I do it exactly the same way sixxie suggested although I have seen examples where sprites are simply EOR'd against the background to save memory at the cost of not looking as nice.

My current game requires a fair bit of memory for sprite data and also needs to run in a frame so I limit masking to the player character as that's where the player's focus will be most of the time. I also store each sprite shifted four times per direction so that I can quickly draw sprites at any pixel offset within a byte. In some cases a sprite isn't needed all of the time so I store it once in one direction and then copy it into a sprite bank, shift it, mirror it etc at the start of a level when it's required.

Re: Sprite transparency

Posted: Sat Dec 31, 2016 10:01 am
by pser1
Hi Steve,
thanks a bunch for this explanation.
I will use the mask trick for the main character creating an interleaved table
with mask and sprite data to allow faster access.
I need to practice a lot on these tricks as I had never attempted anything on
the graphics area

Happy new Year for all of you and your beloved ones
cheers
pere

Re: Sprite transparency

Posted: Tue Jan 10, 2017 11:01 am
by robcfg
sixxie wrote:You have to AND the background data with a mask, OR in the sprite data, then store it back.

(Mask is 0s for the shape of your sprite, else 1).

Tip: modifying 16 bits at a time, you can use ADDD instead of two OR instructions:

Code: Select all

	ldd	,x
	anda	#$0f
	andb	#$fc
	addd	#$0aa8
	std	,x
That's indeed quite a good optimization! I managed to reduce the time taken by a sprite routine I'm working on by 42% :mrgreen:

Re: Sprite transparency

Posted: Tue Jan 10, 2017 3:47 pm
by sixxie
Yeah it's a winner. Having your sprites "compiled" so that all the sprite data is immediate is a pretty obvious win too.

Re: Sprite transparency

Posted: Tue Jan 10, 2017 4:49 pm
by pser1
sixxie wrote:Yeah it's a winner. Having your sprites "compiled" so that all the sprite data is immediate is a pretty obvious win too.
Hi Ciaran,
thanks for that ... I will try to have a look at that, too
But when I hear about 'compiled' sprites, I don't get the idea that lies behind it. I will explain, I have created a table for each sprite that contains (interleaved)
data for the mask and for the sprite itself.
The mask is a rectangle that has the actual sprite in color black (zeros) and the surrounding white (ones) so that it doesn't overwrite the background except
for the 'real' sprite drawing.
The 'actual sprite' is the sprite as is (B/W) and the surrounding to zeros (black) so that when adding/oring it doesn't destroy the not overprinted background.
Of course, the sprite keeps a copy of the overprinted background so that it can restore it when leaving that area ...
Should I think that 'compiled sprite' means a bunch of code that doesn't read the interleaved tables ... because everybyte in them has been added to the
'sprite code'? Say everuthing is immediate AND - OR - ADD applied to the background / buffer
Sorry, but I am an absolute newcomer for graphics
cheers
pere

Ps The tests I am doing with only one big sprite (32x56 pixels) moves great and really needs a delay loop after each step to show smooth movement

Re: Sprite transparency

Posted: Tue Jan 10, 2017 8:34 pm
by sixxie
pser1 wrote: Should I think that 'compiled sprite' means a bunch of code that doesn't read the interleaved tables ... because everybyte in them has been added to the
'sprite code'? Say everuthing is immediate AND - OR - ADD applied to the background / buffer
Yep, that's basically it: you end up using far more RAM (using code like in the snippet above), but things are a *lot* quicker. Basically pick your tradeoff.

Compiled sprite can obviously still save out the old background data somewhere, but more tradeoffs: the extra code size gets multiplied by the amount of manipulations...

That sprite compiler code is what I use for the common graphics in this demo. It'll include code that pushes background data onto the stack by default (though the format it uses is obviously custom to the game...)

Re: Sprite transparency

Posted: Tue Jan 10, 2017 9:50 pm
by pser1
Hi,
thanks again Ciaran!
I have 4 sprites (steps) to move a character to the left and 4 to move it to the right.
Then I use 2 extra to move up and down in both directions, so that character
is using 4+4+2+2 = 12 sprites 32x56 and 4 of them affect five horizontal bytes
instead of only 4 bytes (32pixels) because I move it four pixels each step.
So it seems a bit intimidating going for the 'full compiled' version, by now
it doesn't show speed problems ... if they should appear, it is always good to
know that compiled sprites could reduce to half cycle-count (hopefully)

cheers
pere