Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: p2 on July 27, 2011, 11:11:26 am
-
I've made a little program in Axe language. (axe 1.0.2)
I've tried to make a program, where you (a ball) can walk on courved lines, and needed a bit more than two hours for it.
But the ball is standing in the air if the Y-coord is 14.
So I added
:if Y=14
:if getkey(2)+getkey(3)=0
:Y+1->Y
:End
:End
But why is the ball stopping there?
It's NOT a finished game.
-
I tried it, it's funny, good for a first program. I'd like to say though the performance would be boosted if it weren't for the grey shadows, they're unnecessary and only make the game slow. When I and DJ thought you how to make it, I told you the For loop was a slow idea, I recommend removing it.
Concerning the physics, it's really good for someone who is new to Axe. Nice job!!!
-
Although I couldn't figure out your problem, I did speed it up a lot by moving/deleting a few lines (mainly excess ClrDraw and DispGraph) and deleting the greyscale. Good job overall, and although I haven't worked with Axe much, it looks like a solid start to a game :thumbsup:
Here's my modifications, I only really made small changes.
-
Why don't you try this?
If Y=14
!If getkey(2) or (getkey(3)
Y+1->Y
End
End
Always, always, always remember Axe's order of operations - left to right.
So in Axe, 3+4*2 would return 14, but in school you are taught that the answer would be eleven. It takes some getting used to, but can used very much to your advantage.
-
ephan:
I'll remove the grayscales and make them new.
I'm working on my plan, that the Ball will be changed to a line, which will always rotate so that it's 90° from the platform, even if it's walking in a circle (not calculatet, only inserting the correct picture of the line)
chattahippie:
If you want to see the problem, remove the
:.FIX BUG
: If Y=13
: If getKey(2)+getKey(3)=0
: Y+1->Y
: End
: EndThen you'll see it.
buttsfredkin:
Thanx, I did not know that Axe is reading from left to right.
I'll change it.
Should I try to make a real game of it?
-
Yeah, I meant I couldn't see why it glitched out. Sorry for the bad wording.
You should totally make this into a game! Just remember, you only need one DispGraph and ClrHome, preferably DispGraphrClrHome.
It's much faster this way, since you aren't updating the screen after everything you do, plus DispGraphr is much faster than DispGraph, last I heard.
I've taken out greyscale, and moved your constants to a better place, as well as fixed the DispGraph problem in the attachment in my last post. It's much faster now. Feel free to look at/use those for examples. As I'm still a beginner too, I'm sure my modifications to your programs are still slower than they could be, but it was as best as I could do. :P
Good luck and keep us (me) posted on how this ends up! ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
By the way, why do you store .5 to M? Axe doesn't support decimals. That might be where the "Y=13" problem is.
-
Yes, that may be the problem.
I've planned that the ball can move faster hotizontal, if he's standing, than if he's falling.
But I've deleted that.
I've had:
X-M*getKey(2)+M*getKey(3) -> XBut of cause it hasn't worked, so I deleted it.
You may make it faster if you remove the part where it saves something as M and change in the whole code, that it should check A, and not M.
(A is defined by the large block of pxlTest( at the top of the code)
-
X-M*getKey(2)+M*getKey(3) -> X
That won't work. You're forgetting about the left-to-right order of operations.
M*getKey(3)-(M*getKey(2))+X->X
-
In the code it works:
X-getKey(2)+getKey(3) -> X
Yeah, I'm right! ;D
-
Even better, getKey(3)-getKey(2)*M+X->X :)
-
Oh, yeah...Of course!/me facepalms for not thinking of that...
-
I don't use the M.
It was if I wanted the ball moving horizontal slower while falling than while standing (So that it's more realistic)
But I think that would be possible, too.
-
You should totally make this into a game! Just remember, you only need one DispGraph and ClrHome, preferably DispGraphrClrHome.
Unless you need the speed of DispGraphClrHome , I wouldn't use it. It makes your code larger, and unless speed is of the utmost importance, I'd go with DispGraph : ClrHome . Good luck! :)
-
Yesterday, Ive written the complete code new, with a line with a lenth of 5 as object.
It was really not bad, but the line was a bit too small.
When I saved my progress in a group, it was a RAMCLEAR!
(while saving progress :banghead:)
Now, I'll write it all again.
-
:(
That's happened to me quite a few times too. Archive the source before you parse it, so ram clears don't delete it. And of course, I am required to say that you need to back it up to your computer to almost ensure no data loss, even if a full mem reset occurs
-
Do you have auto-backup on axe enabled? Auto-backup has saved my life more times than I can count.
-
Do you have auto-backup on axe enabled? Auto-backup has saved my life more times than I can count.
Archiving the program pretty much does the same thing except it requires less space
-
One time though (last night) I archived my source program, compiled it, and then had a ram clear so I lost the executable (no big deal) but still had the archived source program. When I tried to unarchive it, it gave me a BAD ADDRESS error, so I had to delete it and restore the backup I had (from auto-backup)
-
One time though (last night) I archived my source program, compiled it, and then had a ram clear so I lost the executable (no big deal) but still had the archived source program. When I tried to unarchive it, it gave me a BAD ADDRESS error, so I had to delete it and restore the backup I had (from auto-backup)
That's never happened to me ???
-
yeah, it was really bizarre. and I really hope it never happens again.
-
That's like a programmer's worst nightmare!
-
It was pretty bad. But, I didn't brick my calc, i just did the whole DEL + Pop a battery thing and reinstalled the OS, and since nothing important was in my RAM, I had everything in the user archive, it's fine now.
-
ERR: BAD ADDRESS, huh? It actually isn't as bad as it sounds. It should really only affect one program at a time, unless you really screwed up your calc.
http://ourl.ca/3687/67152 (http://ourl.ca/3687/67152)
Of course, the time I encountered that error, I reacted pretty drastically too. I actually ended up wiping my calculator's memory completely...
-
It only affected that one program. Things are all fine, now.
-
Who of you has never had any Errors, that seemed to be impossible.
(Can't delete OS, groups in the program menu, ...)
I've tried to write a completely new program.
But It doesn't work and I can't find the bug :P
The point flyes left-up if he should walk left.
EDIT:
Bug fixed.
New bug:
It's flying while walking left, but not while walking right.
-
WARNING: PROGRAM KILLED
EDIT: the program is now a lot faster than on the gif. and has no issues with walls, but there is no looping.
-
The main problem in your code is:
The system how it's all working!
I think it's a really great idea to make it like this, it makes the program smaller and faster.
but the proglem is, that this would make a few things impossible.
On the screenie, you can see why:
The point is going inte the wall at the red points.
Then it is going up in the walls (yellow)
At the blue points, It'll leave the wall.
the problem is the place on pic2
There you go into the wall, but if you go out of the wall, you're outside the circle.
Another problem is, that you can't see the point while going up.
there is no function to show the point while this.
But that would be fixable.
Hayleia, your code would be super for every map, if there is no looping.
Great work! :thumbsup:
-
Yeah, I saw that. I changed the code (but not the gif) so walls are supported. I also use the back buffer to make the game faster and now it is too much fast O.O, a "Pause 50" or something would be welcome.
EDIT: I put the code and the new gif here.