Sprite transparency

Hardware Hacking, Programming and Game Solutions/Cheats
Post Reply
pser1
Posts: 1211
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Sprite transparency

Post by pser1 » Fri Dec 30, 2016 8:33 pm

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

sixxie
Posts: 1067
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Sprite transparency

Post by sixxie » Fri Dec 30, 2016 10:19 pm

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

pser1
Posts: 1211
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Sprite transparency

Post by pser1 » Fri Dec 30, 2016 10:41 pm

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

User avatar
Bosco
Posts: 287
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Sprite transparency

Post by Bosco » Sat Dec 31, 2016 12:59 am

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.

pser1
Posts: 1211
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Sprite transparency

Post by pser1 » Sat Dec 31, 2016 10:01 am

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

User avatar
robcfg
Posts: 1223
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Re: Sprite transparency

Post by robcfg » Tue Jan 10, 2017 11:01 am

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:

sixxie
Posts: 1067
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Sprite transparency

Post by sixxie » Tue Jan 10, 2017 3:47 pm

Yeah it's a winner. Having your sprites "compiled" so that all the sprite data is immediate is a pretty obvious win too.

pser1
Posts: 1211
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Sprite transparency

Post by pser1 » Tue Jan 10, 2017 4:49 pm

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

sixxie
Posts: 1067
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Sprite transparency

Post by sixxie » Tue Jan 10, 2017 8:34 pm

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

pser1
Posts: 1211
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Sprite transparency

Post by pser1 » Tue Jan 10, 2017 9:50 pm

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

Post Reply