Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: dinosteven on November 03, 2012, 06:09:32 pm
-
Here's my code:
:[00003C3C3C3C0000]?Pic1
:37?X
:53?Y
:5?D?C?F
:0?E?S?I?J?G?N
:Repeat (Y?56) or getKey(15) or (G=1)
:Pt-On(X,Y,Pic1)
:X+E?X
:Y-D?Y
:D--
:If (D>64) and pxl-Test(X+4,Y+7)
:C?D
:5?F
:4+X-B/2+E?E
:End
:If X<3
:4?X
:End
:If (X>64) and (X<99)
:63?X
:End
:If pxl-Test(X,Y+4) or pxl-Test(X+7,Y+4)
:?E?E
:End
:DispGraph
:EndI took off the stuff with the paddle movement and some more 'cause it doesn't affect the ball movement. But you can see all the code as attachment BOUNCSRC.8xp on the first post on this thread:
http://ourl.ca/17002
Anyways, the ball bounces around on a paddle 16 pxls long and the very left of it is B-8. I want to have a trail of dots like in the original game:
http://www.madebypixelate.com/games/mr-bounce
It'll describe how the ball will move until it gets to the bottom of the screen, and if the paddle is where the ball will end up, it'll describe how it'll move until it gets to the bottom again. It will also change dynamically with the paddle's movement.
Anyone have any idea how to do this?
I could make ball movement into its own loop and disp a pxl rather than the ball sprite and run it until the Y>56. But that would probably be pretty slow and take up lots of bytes.
-
I think that last thing is what you're going to have to do. Run a loop every frame drawing a pxl for where the ball would be assuming the paddle doesn't move. If you do it efficiently and at a low-ish sample speed, it shouldn't be too hard on performance.
-
Ugh... Is there a way to make subprograms like methods in Java? I'm running out of variables, so I want to have the subprogram use private variables and only output stuff on the screen and an x value it'll be at when it touches the ground. Something like:
public int max(int X, int Y, D, int E, int F) { that code except it's 'Repeat Y>56'; return X; }
-
Because Axe isn't object-oriented, you can't use private variables like that. What you can do is call #Realloc(, which moves your "variables" to a temporary space of free RAM. This allows you to still use A-Z for ease, but doesn't affect the "original copy" of those variables.
What you would want to do is something like:
<codecodecode>
#Realloc(L4) //moves your variable locations to L4
run subroutine, return values (maybe store to another free RAM location)
#Realloc() //resets to original location
-
Does it move the variables or copy them? I want them to stay there.
-
I was curious if it'd slow it down much or not, but really i don't see much difference. When there were 256 dots (there was a bug in my code :P) it slowed down a bit, but still not too bad. I just spend pretty much all day on this, getting the ball to jump to the height of the bar took forever (thanks Tari!) :P
(http://www.mirari.fr/fH6H)
Source code and demo .8XP attached :) What i've got here is it showing every other dot (ie, every other coordinate where the ball/block will go). Showing every coordinate looked really ugly (half of it was a solid line), i think you could even go for showing every third coordinate.
What i did for this is just build an array of coordinates everytime the ball bounces which then get drawn every frame. For the next part calculating where the next bounce will go that might cause a bit of slowdown, especially in my engine since the part that calculates the initial velocity of the ball is a little slow. I can try adding that in too if you want to get an idea of what it might look like...
-
Holy ****! That's nice. To calculate the height the ball will jump, just do ([initial velocity]+1)*[initial velocity]/2+base height.
It's just a sum of all that it'll move up, assuming the velocity decreases by 1 each time.
But if you want to calculate the initial velocity based on the height so the height levels are uniform, that's a lot more trouble.
Anyways, thanks!
-
Is there a command in Axe that lets me copy data rather than move it? My subprogram's gotta have the variables concerning the ball's location and velocities so it can predict...
EDIT: Sorry about the double posting...
-
Try Copy() (in the math menu)
Copy(source, destination,size)
-
What about for every variable?
-
Variables are data too, you can copy them just like any other data.
Copy(oA,wherever,56)
#ReAlloc(wherever)
would move the variable pointers to wherever but also copy their values there as well
-
What about for every variable?
The variable A is located at L1+714, and the 26 other letters (including theta) are after, until L1+768 :)
edit ninja'd :P
Also, I didn't think about °A -.-
-
How do you define 'whatever'?
-
Literally whatever. Wherever you want to back up those variables to. Could be L1, L2, L1+444, any area of free ram that's availabel.
-
This is going to sound stupid: I used Copy(oA,GDB1,56) and it had a compile error undefined. What do I have to do in the beginning to allocate 56 bytes of memory at pointer GDB1 so I can Copy there?
-
Put this at the beginning of the program to do exactly what you described: Buff(56)->GDB1
Note that allocating to GDB1 won't work if the program is an app, but otherwise it should be fine
-
And... um... how do you send data back from GDB1 to the variables?
I use Copy(oA,GDB1,56) to back all my variables up, then I change them for my path prediction, then I want to restore all the original variables.
-
Just realloc the variables back. Think of the realloc command as moving around a window. Usually this window is always looking at L1+714. When you realloc somewhere else, the window has moved to look somewhere else, but the data at L1+714 still exists. So all you have to do to restore your original variables is slide this window back to L1+714. Actually, you can just call ReAlloc with no arguments and itll do that for you.
Copy(oA,GDB1,56)
ReAlloc(GDB1)
code crap
ReAlloc()
-
I'm kind of understanding now. What if I want the original variables in both windows, so I can use them temporarily for path prediction, then switch back to the normal window with the variables unchanged?
I need the original variables in both windows.
-
That's exactly what the code does (I think). You're not moving the data when you copy it. When you copy it, then there are two places in data with the original variables. ReAlloc just changes where in memory A points to when you put "A" in your code. So in the code I gave you, you can do whatever you want to the vars in GDB1, but once you Realloc() back to the original variable setting, the variables there won't have changed.
-
OOOOOOOHHHHH. I finally get it. I'm gonna bookmark this page so I can remember. Thanks so much!
-
Correct me if I am wrong.
So basically, if I do Realloc(L5), then °A=L5, °B=L5+2,... etc and If then I do Realloc(), °A comes back to L1+741, etc ?
-
Correct me if I am wrong.
So basically, if I do Realloc(L5), then °A=L5, °B=L5+2,... etc and If then I do Realloc(), °A comes back to L1+741, etc ?
That's absolutely correct.
-
Correct me if I am wrong.
So basically, if I do Realloc(L5), then °A=L5, °B=L5+2,... etc and If then I do Realloc(), °A comes back to L1+741, etc ?
That's absolutely correct.
Erm, nope, I just reread my post and I made a typo, it is L1+714 not L1+741 -.-°
But yeah, I was asking about the idea, not the figures, thanks for answering :)