Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Raylin on September 13, 2010, 11:11:38 am
-
:.TEST
:<data>
:1->A->B
:ClrDraw
:Repeat getKey(15)
:Pt-Off(B/12,A/12,Pic1
:Pt-Off(B/18,A/18,Pic1+8
:Pt-Off(B/24,A/24,Pic1+16
:DispGraph
:ClrDraw
:C-getKey(2)+getKey(3)->C
:D-getKey(4)+getKey(1)->D
:B+C->B
:A+D->A
:End
My sprites don't appear. Why is this?
-
I think that is doesn't work because you use Pt-Off, and not Pt-On. Pt-Off will just only turn off the pixels which are black on the sprite, nad not turn on the pixels that are white on the sprite. perhaps u could use the combination of Pt-On( and RectI( ? like this:
:.TEST
:<data>
:1->A->B
:ClrDraw
:Repeat getKey(15)
:Pt-On(B/12,A/12,Pic1
:RectI(B/12,A/12,8,8
:Pt-On(B/18,A/18,Pic1+8
:RectI(B/18,A/18,8,8
:Pt-On(B/24,A/24,Pic1+16
:RectI(B/24,A/24,8,8
:DispGraph
:ClrDraw
:C-getKey(2)+getKey(3)->C
:D-getKey(4)+getKey(1)->D
:B+C->B
:A+D->A
:End
-
Didn't work. I believe it's erasing too fast.
-
I think that is doesn't work because you use Pt-Off, and not Pt-On. Pt-Off will just only turn off the pixels which are black on the sprite, nad not turn on the pixels that are white on the sprite.
Actually, Pt-Off is Replace logic.
At any rate, I think the problem is this code:
:C-getKey(2)+getKey(3)->C
:D-getKey(4)+getKey(1)->D
I think what you meant to do is:
:getKey(3)-getKey(2)->C
:getKey(1)-getKey(4)->D
Since C and D were uninitialized, they held random (probably very large) values that are added to B and A each frame.
-
But, wouldn't that cause whatever boolean value to by stored, not incremented?
-
But, wouldn't that cause whatever boolean value to by stored, not incremented?
Oh, so that is what you wanted to do? In that case, the solution is to initialize C and D to 0 (or whatever else you want them to start at)
-
Hmm... still doesn't produce the effect I want. How would I make the sprite 'wisp'-like? With the circles closely following the main sprite?
-
Hmm... still doesn't produce the effect I want. How would I make the sprite 'wisp'-like? With the circles closely following the main sprite?
I don't quite understand what this effect is supposed to be. What are the "circles"?
-
The wisp is supposed to be kind of tight. And while applying physics to the biggest circle, the other circles will follow suit and create a tail behind the main sprite.
-
Hmm... The way I would approach it is creating an array of the positions of the big circle over the last n frames (12 frames, for example). Then display the medium-sized circle at the position from 6 frames ago and the small circle at the position from 12 frames ago. I might try to get some code running myself when I get some time to play with Axe.
-
Hmm... The way I would approach it is creating an array of the positions of the big circle over the last n frames (12 frames, for example). Then display the medium-sized circle at the position from 6 frames ago and the small circle at the position from 12 frames ago. I might try to get some code running myself when I get some time to play with Axe.
This is exactly what you need. What you are doing right now is not going to produce the effect you desire. You have your coordinates, and then you have several other circles at different offsets, but they have no delay needed for the wisp effect you want. Since they are all offsets of the same coordinates, they will all move at the same time
-
I got some working code :D
:[3844828282443800->Pic1
:[0038444444380000
:[0000382838000000
:0->A->B->C->D->{L1}r
:Fill(L1,23
:Repeat getKey(15)
:ClrDraw
:Pt-On({L1+22},{L1+23},Pic1
:Pt-On({L1+12},{L1+13},Pic1+8
:Pt-On({L1},{L1+1},Pic1+16
:DispGraph
:Copy(L1+2,L1,22
:C-getKey(2)+getKey(3)->C+A->A/32->{L1+22}
:D-getKey(4)+getKey(1)->D+B->B/32->{L1+23}
:End
-
That looks quite nice actually ;D
-
yes, I like it!
-
Nice job! That's a really cool effect. :)
-
Interesting indeed. Calc84, can you explain your code? Like in plain English, so that I may learn?
-
I've got it. :)
:[3844828282443800->Pic1
:[0038444444380000
:[0000382838000000 //Store sprites to Pic1, Pic1+8, and Pic1+16
:0->A->B->C->D->{L1} //Make A,B,C,D, and the byte at the address of L1 0 (Yes, there is no need for the r there.)
:Fill(L1,23 //Copy those zeros so the first 23 bytes are zero.
:Repeat getKey(15) //Loop until clear is pressed
:ClrDraw //I forgot. Something about the buffer...
:Pt-On({L1+22},{L1+23},Pic1 // Draw the first sprite wherever L1+22 and L1+23 are
:Pt-On({L1+12},{L1+13},Pic1+8 // Draw the second sprite wherever L1+12 and L1+13 are
:Pt-On({L1},{L1+1},Pic1+16 // Draw the third sprite wherever L1 and L1+1 are
:DispGraph // Draw this on the screen
:Copy(L1+2,L1,22 // Shift all the bytes that were at L1+2 to L1+24 back 2 bytes. Ex: 1,2,3,4,5,6... becomes 3,4,5,6,?,?...
:C-getKey(2)+getKey(3)->C //C and D control momentum C is X momentum
+A->A // A and B control position A is X position
/32->{L1+22} // Divide by 32 and store to L1+22. These fill in at the end of the sequence.
:D-getKey(4)+getKey(1)->D //Pretty much the same as above, but for Y
+B->B
/32->{L1+23}
:End // End the loop
Pretty slick, huh. Nice code, Calc! ;D
-
I would say it might be cool eventually if someone wrote code examples of a program in BASIC and the same in Axe, so people can see the differences between Axe and BASIC, but my concern is that it may mislead Axe programmers at the same time, because many things done in Axe are not the same thing as in BASIC. Example, "HI"->Str1 in BASIC stores the string HI to string 1 variable, but in Axe, it stores the char "H" at the memory address pointed by Str1 and "I" at the next one, both stored in hex form (0 through 255).
-
both stored in hex form (0 through 255).
I believe they are stored in ASCII, so H would be 76 and I would be 77. :)
That's probably the most confusing thing about Axe. {Pointers.} :)
-
Yeah that's what I mean. I forgot the codes, though :P
-
$48 and $49, so 72 and 73 ;D
-
Oh, right. Sorry, wrong offset. :P
Thanks for the catch. :)