Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Vile Smile on October 19, 2010, 10:41:30 pm
-
How do I draw a sprite so that the white part of the image isn't transparent?
-
I think Quibigo created the "Pt-Mask(" command for this. Sadly, I never looked into how it works. If you want to search the Axe Parser thread, he explained it in detail how it works.
-
http://ourl.ca/5980
I believe Builderboy explains it pretty well. :)
-
I think you guys might be overthinking this... I think all he wants is Pt-Off() instead of Pt-On().
-
Oops lol :P You are correct Runer112.
-
Whoops, yup. I believe you want Pt-On() instead of Pt-Off(). :)
-
Ztrumpet, backwards.
-
How do I draw a sprite so that the white part of the image isn't transparent?
Either I'm backwards, or the "isn't" is throwing me off. :P
-
Are you sure, though? I think the first post might have a typo, noticing the title. I think he meant is, but I'm not sure.
-
Sorry if I wasn't clear.
I meant a wanted certain white parts of the sprite to be solid, not just a black outline. I want to prevent backgrounds from appearing inside my player.
-
with the pt-Mask(x,y,sprite) command, you can take a masked spritee and draw it on the screen so that certain parts are white, certain parts are transparent.
How a masked sprite works: there are two parts; the normal sprite and it's back buffer sprite. the front sprite defines what is black and what is white; then the back buffer decides what is filled white, and what is transparent. a black dot on the front buffer is always black (in monochrome mode, no grayscale) if a dot is blank in the front buffer sprite, then if there s a pixel behind it that is black it will show up filled with the pt-mask() command.
a sprite data like this (in binary -- easier to visualize)
11000000
00001100
if the first byte is front buffer and the second is back buffer, then the first two pixels drawn will be black, the next two transparent, the next two filled white, he last two transparent.
if you still don't understand, look in the axe parser documentation for a better idea. ;)
-
with the pt-Mask(x,y,sprite) command, you can take a masked spritee and draw it on the screen so that certain parts are white, certain parts are transparent.
How a masked sprite works: there are two parts; the normal sprite and it's back buffer sprite. the front sprite defines what is black and what is white; then the back buffer decides what is filled white, and what is transparent. a black dot on the front buffer is always black (in monochrome mode, no grayscale) if a dot is blank in the front buffer sprite, then if there s a pixel behind it that is black it will show up filled with the pt-mask() command.
a sprite data like this (in binary -- easier to visualize)
11000000
00001100
if the first byte is front buffer and the second is back buffer, then the first two pixels drawn will be black, the next two transparent, the next two filled white, he last two transparent.
if you still don't understand, look in the axe parser documentation for a better idea. ;)
Actually the Pt-Mask() command (accessible as the Plot1() token) has different logic, as it was designed for 3-level grayscale masked sprites. Each sprite would have 2 8-byte buffers of data. The bits in each byte in the buffers would correspond to a pixel color as follows:
Second buffer
1 0
First 1 Black Gray
Buffer 0 White Transparent
-
umm....
It works for monochrome as well. I tested it and it says so in the documentation as well.
-
Yeah in monochrome you simply just have to not use any gray :P. It's also the same size as you need the second buffer for the transparency
-
Yes, you can use the Pt-Mask() routine for masking monochrome sprites, but you didn't quite define the logic of how things are drawn correctly. You got how to draw white and transparent pixels correctly, but black pixels need to have their corresponding bit be on in both buffers of sprite data, not just the first buffer. Having the bit on in just the first buffer was designed for gray, which turns the pixel on in the back buffer (not used in black and white displaying) but turns the pixel off in the front buffer.
-
Er what do you mean? I just went by your previous post, where you posted this:
Second buffer
1 0
First 1 Black Gray
Buffer 0 White Transparent
I did not imply anything different. All I said was that you simply just had to not bother using any gray in there. In other words, what I meant was
Second buffer
1 0
First 1 Black
Buffer 0 White Transparent
-
Yes, you can use the Pt-Mask() routine for masking monochrome sprites, but you didn't quite define the logic of how things are drawn correctly. You got how to draw white and transparent pixels correctly, but black pixels need to have their corresponding bit be on in both buffers, not just the front buffer. Having the bit on in just the front buffer was designed for gray, which turns the pixel on in the back buffer (not used in black and white displaying) but turns the pixel off in the front buffer.
Not true, runer. If you use Dispgraph with no r at the end it does it with only black on the first buffer...
-
Sorry for the confusion, my last post was directed towards ASBAD_ALVIN, not you DJ.
Yes, you can use the Pt-Mask() routine for masking monochrome sprites, but you didn't quite define the logic of how things are drawn correctly. You got how to draw white and transparent pixels correctly, but black pixels need to have their corresponding bit be on in both buffers, not just the front buffer. Having the bit on in just the front buffer was designed for gray, which turns the pixel on in the back buffer (not used in black and white displaying) but turns the pixel off in the front buffer.
Not true, runer. If you use Dispgraph with no r at the end it does it with only black on the first buffer...
Take the following program for example:
.TEST
[FFFFFFFF00000000]→Pic1
[FFFF0000FFFF0000]
ClrDraw
DrawInv
Pt-Mask(0,0,Pic1)
DispGraph
Repeat getKey
End
That sprite has both bits set for the first two lines of data, only the first buffer bits set for the third and fourth lines, only the second buffer bits set for the fifth and sixth lines, and all of the bits unset for the seventh and eighth lines. You get the result displayed in the attached picture. The first two lines are black, because both bits are set in the sprite data, but when only the first buffer bit is set in the sprite (lines three and four), the result is white. This is because the Pt-Mask() command is doing what would be gray, which means the back buffer pixels are on but the front buffer pixels are off.
EDIT by DJ: post was messed up due to additional code tag at beginning. Fixed :P
EDIT by me: I think I might have fixed it first, in which case you would have been edit ninja'd :P
-
Ah ok I see x.x
Basically, Pt-mask() does the masking work for you, but the downside is that you cannot have 4 level grayscale masked sprites (although in many cases it doesn't matter much plus it saves space)
EDIT: Btw your post was messed up but before I clicked edit I went to check it and it still showed the original post so I clicked edit anyway. We must have clicked at the same time :P
-
You can still have 4 level grayscale by using 4 level backgrounds and 3 level foreground sprites. I think this is what the original game boy used for the same reason. But be aware that when you use the Pt-Mask routine for monochrome, data will still be written to the back-buffer even when you're not displaying it. So you can't use L3 to store additional variables and data structures since they can easily get corrupted.
-
Ah, okay. Now that I see what you're asking, either use this:
http://ourl.ca/5980
I believe Builderboy explains it pretty well. :)
or Pt-Mask(). Whichever you want to use will work. ;D Good luck. :)
-
You can still have 4 level grayscale by using 4 level backgrounds and 3 level foreground sprites. I think this is what the original game boy used for the same reason. But be aware that when you use the Pt-Mask routine for monochrome, data will still be written to the back-buffer even when you're not displaying it. So you can't use L3 to store additional variables and data structures since they can easily get corrupted.
yeah that's what I meant. To get 4 level grayscale masked sprites and backgrounds, you need to use about 3 or 4 sprite for each 4 level masked sprites I think. That might be slow with many at once and a tilemapper...
-
Sorry for the confusion, my last post was directed towards ASBAD_ALVIN, not you DJ.
Yes, you can use the Pt-Mask() routine for masking monochrome sprites, but you didn't quite define the logic of how things are drawn correctly. You got how to draw white and transparent pixels correctly, but black pixels need to have their corresponding bit be on in both buffers, not just the front buffer. Having the bit on in just the front buffer was designed for gray, which turns the pixel on in the back buffer (not used in black and white displaying) but turns the pixel off in the front buffer.
Not true, runer. If you use Dispgraph with no r at the end it does it with only black on the first buffer...
Take the following program for example:
.TEST
[FFFFFFFF00000000]→Pic1
[FFFF0000FFFF0000]
ClrDraw
DrawInv
Pt-Mask(0,0,Pic1)
DispGraph
Repeat getKey
End
That sprite has both bits set for the first two lines of data, only the first buffer bits set for the third and fourth lines, only the second buffer bits set for the fifth and sixth lines, and all of the bits unset for the seventh and eighth lines. You get the result displayed in the attached picture. The first two lines are black, because both bits are set in the sprite data, but when only the first buffer bit is set in the sprite (lines three and four), the result is white. This is because the Pt-Mask() command is doing what would be gray, which means the back buffer pixels are on but the front buffer pixels are off.
EDIT by DJ: post was messed up due to additional code tag at beginning. Fixed :P
EDIT by me: I think I might have fixed it first, in which case you would have been edit ninja'd :P
kk