Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: matthias1992 on July 14, 2010, 09:39:17 am
-
Yesterday was my first hands on experience with Axe, and I love it! despite the compiled files being nearly 2x larger then the source it is incredibely fast! I do have one problem however, moving sprites. I used this code
.SPRITE
DiagnosticOff
10->X->Y
[FFFFFFFFFFFFFFFF->Pic0
Lbl DR
Pt-On(X,Y,Pic0)
Return
Repeat getKey(15)
If getKey(2)
X-1->X
sub(DR)
End
If getKey(3)
X+1->X
sub(DR)
End
End
now instead of moving one pixel left or right the sprite moves 8 pixels. How can I make this one pixel? Am I doing something wrong?
And on a slightly off topic note: I was trying to read The Complete guide to effective Axe by SirCwmp but after page 3 or so there are only blank pages (except the titles of the chapaters) can someone either verify this or upload a non-corrputed version (assuming it is not meant to have those blank spaces)
edit:just another question, how do I display sprites bigger then 8x8 at once? or do I have to make, say, a 32x32 sprite from four 8x8 sprites?
Thanks in advance.
-
One at a time. :P
AFAIK, SirCmpwn never actually released it. What you're probably talking about is just a bit he wrote up so we could give feedback on formatting.
As for larger sprites, you have two options. The first one is to use the Bitmap( command, which is a bit slower (being an OS call) and somewhat inflexible. Your other option is two draw multiple sprites, though, for 32*32, that would be 16 8*8 sprites.
Now to your main question.
First of all, the subroutine DR you have should be at the end of your code, because otherwise your program will right after drawing the sprite once. Also, you need to erase the sprite at its original location when you move it because the edges get left behind. Depending on what else you're doing, you could erase the whole screen, backup the entire screen to the backbuffer, or you might have some other option that I can't think of right now.
Also, that said, are you sure it's exactly 8 pixels? That shouldn't happen. If you haven't realized yet, the direct key commands (of the form getkey(9)) are much faster than just using getkey, and it's probably just moving very quickly.
(Note that some of my criticisms of your code may not be valid, as I'm unsure if what you posted is just an example)
Good luck in Axe! :)
-
Eh, just woke up, but let's see what we got here.
Yeah, calcdude basically covers it. I'm not seeing a DispGraph, so this program doesn't seem to be doing anything. If you don't want the sprite leaving a trail, then make sure you ClrDraw after using DispGraph. Both of those should be put after you've done all the drawing on the screen, so after sub(DR) is called. Oh, it's not really needed, but when closing a program, having ClrHome right before the program ends will clean up your screen when you exit out of it. Otherwise it seems ok. You don't really need to worry about optimizing right now so you should be fine. Just don't forget to make If statements for the Y coordinate. :)
-
In the subroutine DR, before Pt-On(, put ClrDraw for, well, clearing the screen, and after Pt-On(, put DispGraph so the sprites show after you've drawn them. And see if it works
-
Oh, one more thing, you should probably pull the sub(DR) out of the if loops and have it call the sub after all the button presses so that if there are multiple button presses (diagonal movement) it will only make the draw command once instead of multiple times, preventing any weird mishaps. Kind of like:
If getkey(1)
blah
End
If getkey(2)
blah
End
If getkey(3)
blah
End
If getkey(4)
blah
End
sub(DR)
DispGraph
ClrDraw
@jsj795
Hmm, clearing the screen right before drawing to it might not be the best thing, considering that he could draw something else to the buffer before sub(DR) is called. Usually it's best to have it right after you display the contents of the buffer to ensure that you got everything that was needed to be displayed to be uh, displayed.
-
Ooh Yea i made some mistakes indeed so it should be:
.SPRITE
DiagnosticOff
10->X->Y
[FFFFFFFFFFFFFFFF->Pic0
[0000000000000000->Pic1
Repeat getKey(15)
If getKey(2)
X-1->X
sub(DR)
End
If getKey(3)
X+1->X
sub(DR)
End
End
Lbl DR
Pt-On(X-(getKey(3))+(getKey(2)),Y,Pic1) .I have not included Y movement yet for simplicity's sake.
Pt-On(X,Y,Pic0)
DispGraph .no return needed
I always try to avoid ClrDraw, maybe a bad habit in Axe but a good one on BASIC. I don't know with what logic the sprites are drawn so I am not sure if the Pic1 sprite will do what I want it to do, erase the previous position of Pic0...
I have no calc at hand so i am jsut doing this from memory and the commentary you made...
it should work now...
@magic banana
in your example code you dispGraph and then Clrdraw, shouldn't it be the other way around?
-
@magic banana oh... Thanks for the advice lol I'm so used to clearing screen before displaying :p I was also ninja'd by you before
-
@magic banana
in your example code you dispGraph and then Clrdraw, shouldn't it be the other way around?
Then you will draw a white screen all the time, and I guess that is not what you want :P
ClrDraw crears the buffer, and dispGraph writes the buffer to the screen, so when you want to draw something, most times you have to clear the buffer, draw everything you want on it, and then write it to the screen with the dispGraph command.
-
I always try to avoid ClrDraw, maybe a bad habit in Axe but a good one on BASIC. I don't know with what logic the sprites are drawn so I am not sure if the Pic1 sprite will do what I want it to do, erase the previous position of Pic0...
I have no calc at hand so i am jsut doing this from memory and the commentary you made...
it should work now...
@magic banana
in your example code you dispGraph and then Clrdraw, shouldn't it be the other way around?
In Axe, DispGraph will display everything that has been drawn in the buffer onto the LCD and ClrDraw will clear the buffer, but NOT the screen. Axe is a little different than BASIC, so it will take some getting used to, but (almost) everything, unless specified, is drawn to the buffer while in BASIC, everything was drawn straight to the screen (or rather automatically updated to the screen whenever anything on the buffer was changed). In Axe, the LCD will only display what's on the buffer when you tell it to, so that is why you use DispGraph after you have drawn all of your sprites onto the buffer.
LordConiupiter is right about what you said. Deleting everything you draw on the buffer before it is displayed onto the screen = blank screen.
Also, in your sub you use Pt-On(X-(getKey(3))+(getKey(2)),Y,Pic1) do display a white block to which I am assuming to clear out the old space of where your sprite was before. There is no need for this, because your program isn't updating the screen until it gets to DispGraph, and even so, using that white block would erase anything behind your first sprite if there was anything. That is what ClrDraw is for. Unlike BASIC, everything get's drawn extremely fast because it's drawn to the buffer. Once you draw everything you need to, you simply call DispGraph once and BAM - everything is displayed on the screen all at once.
Before I get carried away about the differences between BASIC and Axe syntax, let me just revise your code a bit so you can see what I mean.
.SPRITE
DiagnosticOff
10->X->Y
[FFFFFFFFFFFFFFFF->Pic0
Repeat getKey(15)
X+getkey(3)-getkey(2)->X
Y+getkey(1)-getkey(4)->Y
sub(DR
DispGraph
ClrDraw
End
ClrHome
Lbl DR
Pt-On(X,Y,Pic0
-
.SPRITE . header
DiagnosticOff . turn off indicator/done
10->X->Y . initialize sprite position
[3C7EFFFFFFFF7E3C->Pic0 . squares are for squares. therefore, a black circle is stored to pic0.
Repeat getKey(15) . repeat until clear is pressed
X+getkey(3)-getkey(2)->X . movement
Y+getkey(1)-getkey(4)->Y . code
Pt-Change(X,Y,Pic0 . draw sprite to buffer
DispGraph . display what's on the buffer
Pt-Change(X,Y,Pic0 . draw same sprite to buffer. since it's pt-change, the sprite is erased on the buffer, leaving no
End . residue from movement.
ClrHome . clear the screen, move cursor to upper left corner of the screen.
ClrDraw . clear the buffer.
you can use a subroutine for pt-change() if those 10 bytes you save are really important to you.
-
a subroutine is nice when you use a routine more than once in your program but otherwise they should generally be avoided as they add size and make the program more difficult to read
also, nemo's ptchange method is useful if you want a background image without having to store it in the backbuffer and do swapping(freeing up more RAM for storage)
-
.SPRITE . header
DiagnosticOff . turn off indicator/done
10->X->Y . initialize sprite position
[3C7EFFFFFFFF7E3C->Pic0 . squares are for squares. therefore, a black circle is stored to pic0.
Repeat getKey(15) . repeat until clear is pressed
X+getkey(3)-getkey(2)->X . movement
Y+getkey(1)-getkey(4)->Y . code
Pt-Change(X,Y,Pic0 . draw sprite to buffer
DispGraph . display what's on the buffer
Pt-Change(X,Y,Pic0 . draw same sprite to buffer. since it's pt-change, the sprite is erased on the buffer, leaving no
End . residue from movement.
ClrHome . clear the screen, move cursor to upper left corner of the screen.
ClrDraw . clear the buffer.
you can use a subroutine for pt-change() if those 10 bytes you save are really important to you.
Thanks! but how comes it doesn't flicker? because every time Clear is not pressed it redraws the sprite...
-
that is because you don't clear the screen, but send directly the new data you want to it. The buffer flickers, but the screen just displays the bufferdata when it is sent to it.
-
but doesn't that eventually cause memory fatigue?
-
The only time the screen changes is when you use "DispGraph". The buffer itself is not the screen, its just a place in memory like a program or a variable. Since the majority of commands draw things to this buffer location instead of the screen nothing actually happens to the LCD screen at all. It just stays the way it is (no flickering). The only time the display physically changes is when you use the DispGraph command which looks at the buffer and copies whatever's there to the screen. It copies the data so fast in fact, that it appears the entire screen was updated instantly. Once the screen has been updated with the DispGraph command, it will stay that way until the next DispGraph command so you are free to do whatever you want to the buffer in the mean time including clearing it and redrawing all the sprites.
-
My second noob question is this: how do I use pointers to make animated sprites? Say I have this sprite [FFFFFFFFFFFFFFFF] and this one [3C7EFFFFFFFF7E3C] and both are stored into Pic0 thus making: [FFFFFFFFFFFFFFFF3C7EFFFFFFFF7E3C]. Now everytime I hit the <right> or <left> key I want to alter between them, thus creating the illusion of animation. I am pretty usre this can be done through pointers but I seem unable to figure it out. I do not request a entire example (albeit that would be useful) but some guidance would be very much appreciated!
And thanks so far already for the great and fast help.
-
try this:
.SPRITE . header
DiagnosticOff . turn off indicator/done
10->X->Y . initialize sprite position
[FFFFFFFFFFFFFFFF]→Pic0 . squares are for squares. therefore, a black circle is stored to pic0.
[3C7EFFFFFFFF7E3C] .add more data after the spritedata
Repeat getKey(15) . repeat until clear is pressed
X+getkey(3)-getkey(2)->X . movement
Y+getkey(1)-getkey(4)->Y . code
Pt-Change(X,Y,8*getKey(2)+Pic0 . draw sprite to buffer
DispGraph . display what's on the buffer
Pt-Change(X,Y,8*getKey(2)+Pic0 . draw same sprite to buffer. since it's pt-change, the sprite is erased on the buffer, leaving no
End . residue from movement.
ClrHome . clear the screen, move cursor to upper left corner of the screen.
ClrDraw . clear the buffer.
the '8*getKey(2)' points to 8 bytes further than Pic0 when key 2 is pressed (getKey is 1) and has no effect when any other key is pressed...
-
ok thanks. I actually figured that doing walkcycle can not be done through pointers, it needs indexing so I will give that a try...
-
question no3!
.ATST
11->N
0->O
DiagnosticOff
ClrDraw
[0000000000000000]->Pic00
[FFFF03030303FFFF]
[FFFFC0C0C0C0FFFF]
[386CD6AAFED6D67C]
[FFFFE7C3C3E7FFFF]
[FFE7C38181C3E7FF]
Data(1,4,4,4,4,4,4,4,2,1,1,1,1,1,4,4,4,4,2,4,1,2,4,4,3,3,1,2)->GDB1 .this is just random and the fact that it is, is irrelevant
repeat getKey(15)
N+(getkey(3))->N
O+(getkey(3))->O
N-(getkey(2))->N
O-(getkey(2))->O
ClrDraw
For(A,O,N)
pt-on((A*8),56,((({GDB1}+A)*8)+Pic00))
DispGraph
End
Now this doesn't work. I get strange and random sprites whenever I move too far to the left or right. It is supposed to do this:
Iterate 12 times through GDB1.
If the element is 1 then draw the 8x8 sprite 8 bytes after pic00
If the element is 2 then draw the 8x8 sprite 16 bytes after pic00
If the element is 3 then draw the 8x8 sprite 24 bytes after pic00
etc.
If the right key is pressed then look up the values in GDB1 corresponding to the new X coordinate (e.g. when you start the program it shows the sprites that are reffered to by the data in GDB1 from 0 to 11, if you go right once then you have to look at 1-12, one more time to the right is 2-13 etc until the end of the list. So actually you move trough the list and the display is updated accordingly)
If the left key is pressed do the inverse of the right key si pressed action
If the clear key is pressed stop else go to the beggining.
Now this is not what it does. on a side note I don't think I need pic00 and I yet have to include the feature that stops you from "stepping" outside the list (GDB1) by pressing left or right too often but I can't seem to get the "Length()" command to work...
O yes, this is for my Axe contest entry so I am not sure to what extend you may help me..(but if I don't get help there won't be a entry :P)
Tyvm
-
It seems like it'd be legal. To use Length, you'll have to add a meaningless 0 to the end of GDB1. (Length searches for a zero) You'd also have to make sure none of the other bytes in GDB1 are 0.
Since I don't feel like comprehending your code, I'll just tell you that the lines with getkey's on them can be N+getkey(3)-getkey(2)->N and O+getkey(3)-getkey(2)->O. Actually, because the keys might be released just in time to be different (I've had this problem) you should use the lines
N+(getkey(3)-getkey(2)->T)->N
O+T->OProvided you don't need T elsewhere, of course.
I might try to resolve your main problem later.
Good luck with your entry!
Edit: For clarification, that code stores the result of the keypresses in T, then reuses the value. (Embedded store statements are allowed, and can often be more optimized)
-
Instead of {GDB1}+A you want {GDB1+A}. Also, you're using way too many parenthesis, they actually do add to the code size usually. The getkey's don't need the extra pair, A*8 doesn't, and the thing after it has a lot. Axe reads strictly left to right for its order of operations so most of those parenthesis are unnecessary.
-
problem is still unsolved. thanks for the optimizations though. Let me try to explain it again. I have a list (GDB1) which contains numbers. Each number represents a tile. Now the first value in GDB1 is the first tile the second value the second tile etc. The thirteenth tile is not drawn because only twelve fit on the screen. The thirteenth tile is drawn when you press the <right> key, however the first tile is NOT drawn then (because all the tiles shifted left once. So basically the list contains the tiles and now I want to be able to scroll through the tiles by pressing left or right. By pressing right the tiles shift to the left once and by pressing left the tiles shift right once. This is what I am trying to accomplish and so far has failed epically :(.
-
Instead of {GDB1}+A you want {GDB1+A}. Also, you're using way too many parenthesis, they actually do add to the code size usually. The getkey's don't need the extra pair, A*8 doesn't, and the thing after it has a lot. Axe reads strictly left to right for its order of operations so most of those parenthesis are unnecessary.
What Quigibo means by 'Strict Order of Operations' is that when doing a series of operations, instead of worrying about the 'normal' order like you were taught in school (PEMDAS) Axe will read the equation starting from the left and doing each operator as it reads it, which is very helpful to remove all the parentheses that otherwise plague large equations.
Example:
7+8*3-9*2=13
7+8*3-9*2=72
Keep in mind though that Axe still supports parentheses and will calculate those before anything else, so if you are a little confused about the strict order of operations, you can still use:
7+(8*3)-(9*2)=13
Although, that kinda ruins the point of using strict order of operations to optimize code. :P
EDIT:Hold on, let me see what's going on in your program and I'll get back to you.
EDIT2:Okay, can you post your source code, because I seem to be getting something completely different than what you described. ???
-
OK this are getting slightly out of hand here, this:
problem is still unsolved. thanks for the optimizations though. Let me try to explain it again. I have a list (GDB1) which contains numbers. Each number represents a tile. Now the first value in GDB1 is the first tile the second value the second tile etc. The thirteenth tile is not drawn because only twelve fit on the screen. The thirteenth tile is drawn when you press the <right> key, however the first tile is NOT drawn then (because all the tiles shifted left once. So basically the list contains the tiles and now I want to be able to scroll through the tiles by pressing left or right. By pressing right the tiles shift to the left once and by pressing left the tiles shift right once. This is what I am trying to accomplish and so far has failed epically :(.
is what it is SUPPOSED to do/what I want it to do.
and this is my source (which doesn't do what i want it to do):
.ATST
11->N
0->O
DiagnosticOff
ClrDraw
[0000000000000000]->Pic00
[FFFF03030303FFFF]
[FFFFC0C0C0C0FFFF]
[386CD6AAFED6D67C]
[FFFFE7C3C3E7FFFF]
[FFE7C38181C3E7FF]
Data(1,4,4,4,4,4,4,4,2,1,1,1,1,1,4,4,4,4,2,4,1,2,4,4,3,3,1,2)->GDB1 .[s]this is just random and the fact that it is, is irrelevant[/s] [i]not entirely random each number is a sprite but it is random in the sense that i choose the numbers randomly (within a range from 1-5)[/i]
repeat getKey(15)
N+getkey(3)-getKey(2)->N
O+getkey(3)-getKey(2)->O
ClrDraw
For(A,O,N)
pt-on(A*8,56,({GDB1+A}*8)+Pic00)
DispGraph
End
What I get is this. There is one sprite showing in the bottom right corner bu as soon as I press either left or right it fills up. Clearly all kinds of other sprites are drawn over it (this can be better seen if you make pt-on() into pt-change()). Now that is NOT what I want it to do but I can't find my problem, this is what I need help for.
-
Hmm, Well when I run it, I get a line of sprites that blink at the bottom. when pressing left, they seem to be shifting to the left, but once the right end of this line of sprites hits the end, then the random garbage comes up and I have to pull the battery.
First off, can you change the variable 'O' to something different? It's very hard to distinguish it from zero in the code. Also, why is there no 'End' to end the Repeat getkey(15)? with the code you posted, it won't even compile. Also, what exactly are you trying to get done with this code? Perhaps there is another way of going about doing it.
-
.ATST
0->C . Since we're always displaying 12 sprites on the screen, you only need one var to keep track of position in the data.
DiagnosticOff
ClrDraw
Zeroes(8)->Pic1 . just a different way of writing it.
[FFFF03030303FFFF]
[FFFFC0C0C0C0FFFF]
[386CD6AAFED6D67C]
[FFFFE7C3C3E7FFFF]
[FFE7C38181C3E7FF]
Data(1,4,4,4,4,4,4,4,2,1,1,1,1,1,4,4,4,4,2,4,1,2,4,4,3,3,1,2)->GDB1 . unchanged data.
Repeat getKey(15)
C!=16 and getKey(3) - (C!=0 and getKey(2))+C->C . "!=" is does not equal. they're used to be boundaries, so we don't scroll into undefined data.
Pause 150 . pauses for 150 milliseconds to slow the program down.
ClrDraw
For(A,C,C+12
pt-On(A-C*8,56,{GDB1+A}*8+Pic00 . A-C instead of A so we always start displaying the sprites at (0,56).
End
DispGraph
End
i think this gives the desired effect. i got the 16 as a boundary from the number of pieces of data in GDB1 (there are 28). since in the for loop i have the ending value 12 higher than C, the maximum boundary before we start scrolling into random data is the amount of data (28) minus how far in front of our counter variable (C) we're going to use. (12). therefore the boundary of C is 16. you can adjust the pause to make the program scroll faster/slower. one last thing to explain, {GDB1+A}*8+Pic00. {GDB1} returns 1, because it's the first number in the sequence in Data(). it's also defined as the number starting at the static pointer GDB1. {GDB1+A} returns whatever number is A spaces after the beginning of Data() so if A is 3, {GDB1+A} returns a 4. We multiply by 8 because each sprite takes up 8 bytes of space. Since {GDB1+A} returns the byte at the pointer (think that it returns the number A spaces in front of the 1 in Data() if you're confused on pointers), we multiply by 8 to skip through the sprites. I think you already understand this, matthias, i'm just checking anyway.
-
Thanks i'll try that...well i get some sleep whether it works or not but it surely looks good! I ahve new hopes :P
-
no problem. what exactly are you trying to make?
-
this: http://ourl.ca/6342
-
Here is my latest noob question. I succeeded once in writing to appvars but I lost the program somehow, I have no notes of it either and the Axe documentation doesn't give a appvar specific writing example.
I tried this:
"vPBWMAP1"->Str0
Getcalc(Str0,16)->P
If P
[FFFF03030303FFFF]->{P}
End
I also tried
For(A,0,15)
1->{P+A}
End
Neither of which works. Any suggestions?
-
Each one is half way right, you just have to combine the 2.
"vPBWMAP1"->Str0
Getcalc(Str0,16)->P
If P
For(A,0,15)
1->{P+A}
End
End
-
Quigibo, with 0.4.0, can you do something like "Copy([0123456789ABCDEF],P,8" ?
That might be useful.
-
Yeah, you can do that too.
-
tyvm, I have 3.3 though, does the copy() method calcdude84se suggested work on that version as well?
-
No, but you can upgrade ;D
The ability to use values directly rather than storing them to pointers first was added with version 0.4.0
-
Interesting new use of data i see! That should prove to be very useful in the future :)
-
Of course, it's still more optimized to do "Str1->Str1 and use Str1 multiple times than using "Str1" multiple times, since each occurrence of "Str1" adds size to the program, while assiging it to a pointer just does it once.
I think the intended use was with text and other data that would only need to be used one time.
-
Right, but for things like
GetCalc("Str1",5)->A
Its very very useful :) *dances*
-
No, but you can upgrade ;D
The ability to use values directly rather than storing them to pointers first was added with version 0.4.0
Keep in mind by version 0.4.0, Axe takes 32768 bytes instead of 16384, though, so be sure to save some of your stuff on the computer if you run out of space. The larger size should not be a problem considering it's an entire programming language compiling tool, though.
Also nice update to Copy and Getcalc
-
And Text( too ... I like consistency :)
-
Yeah, it was language-wide, IIRC
You can even do
Disp "Hello World"+6theoretically. (I haven't checked yet, though) It should display "World"
-
Yeah I am happy we no longer have to do
"HI"->Str1
Text(1,1,Str1
Much easier to do option menus, now
-
checked it, and it's true. This is real fun!!!