Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: SamTebbs33 on January 18, 2014, 11:43:16 am
-
Hi!
Is it at all possible to change Xmin, Xmax, Ymin, Ymax, Xscl and Yscl from within an Axe program? I have tried several methods such as GetCalc("varXmin") but none seem to be doing what I need, is it at all possible and if so, what am I doing wrong?
Thanks!
-
IDK, sorry :( I tried several methods too but couldn't get it. Why do you need to do that in an Axe program?
-
I'm trying to draw a shape using lines but I can't change the variables, so I'm stuck with very little space to draw with (-10 to 10)
-
Oh, no, on axe you have coordinates from 0-95 in x and 0-63 in y direction, so you can draw all that stuff without having to change xmin etc
-
Someone will have to translate this to Axe, but those variables are stored at constant addresses. To see the addresses, CTRL + F "Xmin" on this page (http://brandonw.net/calcstuff/ti83plus.txt) (it's the 5th instance).
I'm going to assume that GetCalc() returns the address of the variable, so using Xmin is probably as easy as replacing GetCalc() with 0x8F50.
Edit:
I don't know if the goal of this thread is actually to change Xmin anymore, but, if anyone wants to do it.
####AXE####
:E8F50->A
:1337->float{A}
This will store 1337 to Xmin
-
Oh, no, on axe you have coordinates from 0-95 in x and 0-63 in y direction, so you can draw all that stuff without having to change xmin etc
Sorunome's right, you don't need to change xmin in Axe. instead of a 10 by 10 grid, the screen is set up (like the basic text command) so that you program what pixel to draw the line on not what coordinate.
-
Thanks guys! I didn't know that the screen dimensions were preset to exactly what I wanted them to be! :)
-
Also, as a note, this is how the coordinate system works at the hardware and assembly level. TI-BASIC converts coordinates for all of its drawing commands to pixel coordinates which takes up a lot of time. This is nice for math purposes, but inefficient for graphics.
To give you an idea, you could probably draw a line in Axe a few dozen times in the time TI-BASIC can draw a single Pt-On( command since it has to convert the inputs, then transform the inputs into pixel coordinates, then it converts those float values to integers that can actually be used directly, then it uses those coordinates to a pixel location and plots it. Axe only needs to do the last step (which is the fastest one).
-
Oh ti, what were they thinking! ::)
-
Also, as a note, this is how the coordinate system works at the hardware and assembly level. TI-BASIC converts coordinates for all of its drawing commands to pixel coordinates which takes up a lot of time. This is nice for math purposes, but inefficient for graphics.
To give you an idea, you could probably draw a line in Axe a few dozen times in the time TI-BASIC can draw a single Pt-On( command since it has to convert the inputs, then transform the inputs into pixel coordinates, then it converts those float values to integers that can actually be used directly, then it uses those coordinates to a pixel location and plots it. Axe only needs to do the last step (which is the fastest one).
Also, in BASIC the LCD is updated on every line/pixel command, while in Axe you choose if you want the LCD updated or not during drawing. Updating everytime causes flicker in some cases and it's much slower.
-
Also, in BASIC the LCD is updated on every line/pixel command, while in Axe you choose if you want the LCD updated or not during drawing. Updating everytime causes flicker in some cases and it's much slower.
Back when I did BASIC I hated that so much...
-
Also, in BASIC the LCD is updated on every line/pixel command, while in Axe you choose if you want the LCD updated or not during drawing. Updating everytime causes flicker in some cases and it's much slower.
Back when I did BASIC I hated that so much...
That is what i found so awesome when i found xLib, the whole update LCD stuff :)