Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: Galandros on May 30, 2010, 03:37:58 pm
-
I did a long time ago. I experimented a lot to get this optimized routine. I added this to TI|BD some time after discover...
And because I see unoptimized versions of this in lots of programs, I decided to share on the forums.
I still need to spread this optimized version through other entries of the wiki.
Here's the code:
//// Prepare graph screen to be used in TI-BASIC
StoreGDB 0 // save the current graph screen, user friendly
FnOff // we don't want functions to bloat
PlotsOff // plots too
GridOff // rare but just in case
AxesOff // no axes please :)
// miss here the coordinates setup...
///main code
RecallGDB 0 // restore the graph screen, user friendly
DelVar GDB0 // clean up
//The following code sets up an integer square window with (0,0) in the center:
:ZStandard
:ZInteger
//An integer window with (0,0) in the bottom left corner
:ZStandard
:84→Xmin
:72→Ymax
:ZInteger
//An integer window with (0,0) in the top left corner
:ZStandard
:84→Xmin
:-72→Ymax
:ZInteger
And a alternate version of preserving user setting with a few drawbacks:
ZoomSto // store the zoom
FnOff // we don't want functions to bloat
PlotsOff // plots too
GridOff // rare but just in case
AxesOff // no axes please :)
// miss here the coordinates setup...
///main code
// restore
ZoomRcl // restore the zoom
AxesOn
Maybe ZPrevious could be used for further optimization. I need to test. Tested. It is not great use for restoring graphics setting after more than 1 command that changes the graph settings.
For curiosity here's the good old straightforward but larger code:
:0→Xmin:94→Xmax
:0→Ymin:62→Ymax
can be
:0→Xmin:1→ΔX
:0→Ymin:1→ΔY
Good use!
-
I still remember seeing this before. That was interesting. Did it work on every calc OSes, though? I think I recall this failed before when I tried the :0→Xmin:1→ΔX stuff
That said, for the Y part, I don't really like this much, though, because generally people will want Y coordinates to look similar to if they used Pxl-On or Text(). I prefer having -62->Ymin:0->Ymax instead of 0->Ymin:-62->Ymax. I think it might cause programs to grow in file size, though, so if you really want to optimize your programs, you might have to adapt to the inverted coordinates instead
-
-62->Ymin:0->Ymax
Thats the window setting i use as well ^^ I find its most useful when mixing window based drawing and screen based drawing. haha i remember when i used to use the Integer window setting, and i had to do math in order to draw accurately ;D
-
I usually use 0->Ymin:62->Ymax... Nowadays, some of the inverted coordinates comes natural and the harder ones I just need to subtract the number from 62... I don't like working with negatives too much :P
-
I use the 2 setups you are discussing. It just depends on the program I use. The conversion on Y for the -62->Ymin:0->Ymax is just -Y.
For the other you do something like 62-Y.
And in movement/physics things you have the change the code accordingly to the setup.
-
:ZStandard
:84→Xmin
:-72→Ymax
:ZInteger
Wow, that is optimized. Thanks.
Thats the window setting i use as well ^^ I find its most useful when mixing window based drawing and screen based drawing. haha i remember when i used to use the Integer window setting, and i had to do math in order to draw accurately ;D
Me too. And before that, I just left the window in ZStandard and tried to work with the decimals. It was horrible.
EDIT: Especially for a game like checkers.
-
Indeed. Some of my old games use Zstandard but only because everything involving drawing doesn't need much pixel precision. Still hectic at times, though.
-
What's worse and what I did until I figured out how to use GDB's is to use the window as is. That code got messy quickly.
A pixel Y,X (such as used with Pxl-On) becomes Xmin+^X*X,Ymax-^Y*Y (yes I'm using carets for deltas) and conversion back is even uglier, with rounding involved. *shudder*
But then I learned about GDB's, and I became happier. :)
Also, nice code, Galandros
-
I assume GDBs stored all graph equations and window settings, right?
-
Yeah, they do, which can be useful if you need to draw an equation for some reason...
-
cool, thanks for the info. Are they generally smaller too?
-
cool, thanks for the info. Are they generally smaller too?
They can be, just remember it's one more thing (like a pic) that must be included with your program. =/
-
Yeah true :S
-
Indeed. Some of my old games use Zstandard but only because everything involving drawing doesn't need much pixel precision. Still hectic at times, though.
A pixel Y,X (such as used with Pxl-On) becomes Xmin+^X*X,Ymax-^Y*Y (yes I'm using carets for deltas) and conversion back is even uglier, with rounding involved. *shudder*
In my early TI-BASIC coding I tried to code a program to convert any graphs setting to another. I will give it a try again but I believe there is rounding issues that throw away the use. The idea is to ease convert old code to the code in Friendly Graphics Settings.
I shared exactly to make everyone save a few bytes (not that important but in TI-BASIC we turn many times in optimization freaks) and also for the curiosity of existing a even smaller alternative. ^^ I also like the alternative movement code seen in TI|BD.
-
Maybe ZPrevious could be used for further optimization.
Checked. It is not great use for restoring graphics setting after more than 1 command that changes the graph settings.
It can be used during your mathematical equations view, though.
-
yeah it only saved one setting if I recall. Kinda like Notepad's Undo function on Window$