Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Axe Programmer on September 17, 2013, 10:54:58 am
-
Whats up guys. Axe Programmer here. Does anybody know if you can make bigger sprites than 8x8? I am looking for something ligit, not displaying a bunch of 8x8 sprites together. Thanks.
Axe Programmer ???
P.S. Please include a code if you can...
-
then... you can draw 4 sprite 8x8 for make one sprite 16*16 !
-
then... you can draw 4 sprite 8x8 for make one sprite 16*16 !
I am looking for something ligit, not displaying a bunch of 8x8 sprites together.
Anyways, did you have a glance at the Bitmap command ? Read the Commands.html to know how to use it.
-
I think that the Bitmap( command does what you are looking for. Next time RTFM.
I got ninja'd
-
Next time RTFM.
I second that. You should consider taking a look at commands.html one of those times.
-
the bitmap command will work, but displaying as a group of sprites should be faster, so if speed is required just deal with cating them together.
-
Bitmap(X,Y,BMP);Bitmap(X,Y,BMP)ʳ;Bitmap(X,Y,BMP,BUF);Bitmap(X,Y,BMP,BUF,MODE) Key:Tangent(): Draws a bitmap to (X,Y) on the main buffer, back buffer, or specified buffer respectively. The bitmap data should have in order: width (1 byte), then height (1 byte), then the rows of the image padded with zeros to the nearest byte. Mode 0 is "Pt-On" logic and Mode 1 is "Pt-Change" logic. Mode 0 is used if unspecified.
-
I think that the Bitmap( command does what you are looking for. Next time RTFM.
although I get your point, the RTFM part is considered rude and frowned upon by Omnimaga rules. There are more polite ways to get your point accross (see examples above).
-
First you need your Bitmap data.
so for example lets draw a 14x19 bitmap
Data(14, 19) -> GDB1
[FFFC
first row but the two pixles in the end should be zero (this is because you can't end the row with just half a byte
(this is meant by the "the rows of the image padded with zeros to the nearest byte."
FFFC
FFFC
... now you have three rows of black
complete the 16 other and throw a ] at the end
...
FFFC]
Your Bitmap is now stored at GDB1
To display it just call
Bitmap(X,Y,GDB1
I don't use the Bitmap() often, so correct me if I made a mistake somewhere <_<
-
Also I once wrote a set of routines that draw bigger sprites with multiple 8*8's. I could make an axiom for it. ;)
-
First you need your Bitmap data.
so for example lets draw a 14x19 bitmap
Data(14, 19) -> GDB1
[FFF3
first row but the two pixles in the end should be zero (this is because you can't end the row with just half a byte
(this is meant by the "the rows of the image padded with zeros to the nearest byte."
FFF3
FFF3
... now you have three rows of black
complete the 16 other and throw a ] at the end
...
FFF3]
Your Bitmap is now stored at GDB1
To display it just call
Bitmap(X,Y,GDB1
I don't use the Bitmap() often, so correct me if I made a mistake somewhere <_<
You did, but it's not related to the bitmap command :P You should have used [FFFC] instead of [FFF3] to keep the 2 last pixels off, since C is 1100 and 3 is 0011.
-
You're right, I did. ;D
Just corrected it
-
Thanks to everyone
-
Well actually it doesn't matter what you have in the last pixels as the Bitmap( command will crop it anyway. ;)
-
Well actually it doesn't matter what you have in the last pixels as the Bitmap( command will crop it anyway. ;)
It does matter. :P For efficiency reasons the routine only keeps track of the byte width (pixel width/8) of the sprite when drawing it, so really it always draws sprites that are some multiple of 8 pixels wide, meaning all 8 bits of the final byte are drawn. That's why the documentation says that the end of each row should be padded with 0 bits, as drawing the extra 0 bits with OR or XOR logic doesn't actually change anything. The fact that the width specifier in the sprite data is in pixels really just for convenience purposes, although I see how it could be misleading.
-
You should change it then, it could even make it slightly faster in tight loops.