ZStandard
104→Xmax
72→Ymax
ZIntegerZStandard
104→Xmax
-72→Ymin
ZInteger
I think i'd prefer size in this position. After all its not like you need uber fast speed when resizing the windows :PMe too. I just threw the routine out there. :)
TROLL.
J/k.
Pretty good, nice job. Hope you can fix those bugs...
EDIT: IMO you should go for the faster option. It's going to be used inside TI-BASIC programs, anyway.
TROLL.
J/k.
Pretty good, nice job. Hope you can fix those bugs...
EDIT: IMO you should go for the faster option. It's going to be used inside TI-BASIC programs, anyway.
Well you have to remember it's only a fraction of a second faster.
TROLL.
J/k.
Pretty good, nice job. Hope you can fix those bugs...
EDIT: IMO you should go for the faster option. It's going to be used inside TI-BASIC programs, anyway.
Well you have to remember it's only a fraction of a second faster.
Yeah, but in games if you call it often enough even a fraction of a second make a huge difference ;)
If H(</=)9:E30->{Z+S}:S+1->S:End
If H(</=)19 and (H(>/=)10):E31->{Z+S}:S+1->S:H-10->H:End
If H(</=)29 and (H(>/=)20):E32->{Z+S}:S+1->S:H-20->H:End
If H(</=)39 and (H(>/=)30):E33->{Z+S}:S+1->S:H-30->H:End
If H(</=)49 and (H(>/=)40):E34->{Z+S}:S+1->S:H-40->H:End
If H(</=)59 and (H(>/=)50):E35->{Z+S}:S+1->S:H-50->H:End
If H(</=)69 and (H(>/=)60):E36->{Z+S}:S+1->S:H-60->H:End
If H(</=)79 and (H(>/=)70):E37->{Z+S}:S+1->S:H-70->H:End
If H(</=)89 and (H(>/=)80):E38->{Z+S}:S+1->S:H-80->H:End
If H(</=)99 and (H(>/=)90):E39->{Z+S}:S+1->S:H-90->H:End
can definitely be optimized to this:!If H/10->F:E30->{Z+S}:S+1->S:End
If F=1:E31->{Z+S}:S+1->S:H-10->H:End
If F=2:E32->{Z+S}:S+1->S:H-20->H:End
If F=3:E33->{Z+S}:S+1->S:H-30->H:End
If F=4:E34->{Z+S}:S+1->S:H-40->H:End
. et cetera...
and *might* be able to be optimized into this, depending upon the circumstances of the program:E(H/10+30)->{Z+S}
S+1->S
H-(H/10*10)->H
just one huge optimizing technique. this mammoth:thanks i'll try those ^Code: [Select]If H(</=)9:E30->{Z+S}:S+1->S:Endcan definitely be optimized to this:
If H(</=)19 and (H(>/=)10):E31->{Z+S}:S+1->S:H-10->H:End
If H(</=)29 and (H(>/=)20):E32->{Z+S}:S+1->S:H-20->H:End
If H(</=)39 and (H(>/=)30):E33->{Z+S}:S+1->S:H-30->H:End
If H(</=)49 and (H(>/=)40):E34->{Z+S}:S+1->S:H-40->H:End
If H(</=)59 and (H(>/=)50):E35->{Z+S}:S+1->S:H-50->H:End
If H(</=)69 and (H(>/=)60):E36->{Z+S}:S+1->S:H-60->H:End
If H(</=)79 and (H(>/=)70):E37->{Z+S}:S+1->S:H-70->H:End
If H(</=)89 and (H(>/=)80):E38->{Z+S}:S+1->S:H-80->H:End
If H(</=)99 and (H(>/=)90):E39->{Z+S}:S+1->S:H-90->H:EndCode: [Select]!If H/10->F:E30->{Z+S}:S+1->S:Endand *might* be able to be optimized into this, depending upon the circumstances of the program:
If F=1:E31->{Z+S}:S+1->S:H-10->H:End
If F=2:E32->{Z+S}:S+1->S:H-20->H:End
If F=3:E33->{Z+S}:S+1->S:H-30->H:End
If F=4:E34->{Z+S}:S+1->S:H-40->H:End
. et cetera...Code: [Select]E(H/10+30)->{Z+S}
S+1->S
H-(H/10*10)->H
I'd like to see a screen to see what it gives, but it could very well be a joint project (it would probably a better result). I did post an update soon with viewing from 2 to 3 superimposed image color levels.Do you mean 3 and 4 level grayscale? THat seems like a cool feature :D
Look and comment here (http://ourl.ca/6291/116825).
(http://www.omnimaga.org/index.php?action=dlattach;topic=3694.0;attach=3525;image)
Just thought of this but a nice feature with this program would be to give the option of putting the Line( command number into a compressed list or string and then put a extraction loop into the code too. Just thought that might be handy since you're going for optimization.
Edit:
Also, just a thought, but would having a separate button for points and lines be possible? That way you don't have to click twice to do a point. I just think some people may forget and put a point down, thinking its a point, and then click to make another point and BOOM, there's a line.
Well just because someone uses a point doesn't mean it will be just a single point. Some people just use single points to make their drawings.
As for the line thing you could make all the circle, point, and other commands first. Then when you get to the lines you can just put those all in at once. I mean instead of pointing them as Line(+#+,+#+,+#+,+# it would be {+#E6#E4#E2#+,+...
Though, I don't know how hard that is in Axe.
Ok, let me see if I can rephrase what I said. Some people, like me and I'm sure some spriters and such, go pixel-by-pixel when created images and such for the calculator because we control exactly where things are. Using lines can be unpredictable. So having a point button would be handy. However, just because a point is being drawn doesn't mean the end result won't end up in a line or something. Make more sense?
Actually, compression like that would be very easy in Axe, as TI's floating point format has each number as a hex character, so the number 1243 would look like 00h 83h 00h 00h 00h 00h 00h 00h 00h 12h 43h. The 00 out front determines if it's real/complex and negative/positive. The 83 means 1.243 * 10 to the 3rd power.
Please note that negative numbers have 80h as the first byte. :)
Also note that these numbers are all in hex. ;D
Edit: ninja'd ^-^
Well if you can't do that then you need to make sure to say that you have to push twice to make a single point.
TROLL.
J/k.
Pretty good, nice job. Hope you can fix those bugs...
EDIT: IMO you should go for the faster option. It's going to be used inside TI-BASIC programs, anyway.
Well you have to remember it's only a fraction of a second faster.
Yeah, but in games if you call it often enough even a fraction of a second make a huge difference ;)
But when do you need to constantly change the window? I don't think I've ever seen that before.
Ya, I've been thinking of ways to convert the graph screen into drawing commands in TI-BASIC but I couldn't think of the math to correctly do it, though I didn't try to hard.
Well what his is doing is you draw your picture and then the output is the program. What I will, if I decide to do it, will be to just take what is on the graphscreen and will convert it into optimized drawing routines, hopefully, that is stored into Str1 and then all you have to do is recall that into a program and delete the quotes. The problem with TI-BASIC is that the window would have to be:
Xmin: 0
Xmax: 94
Ymin: -62
Ymax: 0
That is unless I figure out a way to convert the graphscreen dimensions into what the user wants to window to be.
Hmm, could it potentially keep the window the same, if you let the user input the graph coordinates he'll be using? It might be hard at first to get Axe to accurately calculate the numbers to use for each line, but theoretically it's possible. If it is, it would be extremely useful.
Ya, I've been thinking of ways to convert the graph screen into drawing commands in TI-BASIC but I couldn't think of the math to correctly do it, though I didn't try to hard.
Isn't this what the project does, anyway, though? Maybe just write a more general routine to find the numbers, and it could work.
Floating points might be hard to work with, though :P
??? ^ sorry once again for my noobishnessWell what his is doing is you draw your picture and then the output is the program. What I will, if I decide to do it, will be to just take what is on the graphscreen and will convert it into optimized drawing routines, hopefully, that is stored into Str1 and then all you have to do is recall that into a program and delete the quotes. The problem with TI-BASIC is that the window would have to be:
Xmin: 0
Xmax: 94
Ymin: -62
Ymax: 0
That is unless I figure out a way to convert the graphscreen dimensions into what the user wants to window to be.
Exactly, that's my suggestion. It would be pretty hard, but if he could figure out to calculate the floating-point numbers, he could make the output programs not clear the screen every time, and it could potentially be used simply as a sprite drawer or similar subroutine.
simple division would work wouldn't it?
If you want to write that for me... :P
I'll work on it when/if i finish the rest of this. I am swamped with homework today
Commands:Are circles gone completly from the program or are they just accessible differently?
* 2nd- Puts point/line on screen at location of the pointer.
* CLEAR- Ends program.
* Alpha- Will switch you between Line mode and Circle mode
Change Log
*Circles removed
*Fixed 00 bug.
*Optimized code slightly
Nice, butQuoteCommands:Are circles gone completly from the program or are they just accessible differently?
* 2nd- Puts point/line on screen at location of the pointer.
* CLEAR- Ends program.
* Alpha- Will switch you between Line mode and Circle mode
Change Log
*Circles removed
*Fixed 00 bug.
*Optimized code slightly
Why not use the Axe circles? Are they just buggy or something?
Nice, butQuoteCommands:Are circles gone completly from the program or are they just accessible differently?
* 2nd- Puts point/line on screen at location of the pointer.
* CLEAR- Ends program.
* Alpha- Will switch you between Line mode and Circle mode
Change Log
*Circles removed
*Fixed 00 bug.
*Optimized code slightly
Sorry about that, I was copy and pasting from 1.2.2 and I guess i missed that.
There are circles in 1.2.2 but then removed in 1.3 because Axe and Ti-basic draw their circles differently.
If someone were to locate the yay that ti-basic draws their circles, that would be great, and i would put it back in axe if it is possible to wrote in.
Nice, butQuoteCommands:Are circles gone completly from the program or are they just accessible differently?
* 2nd- Puts point/line on screen at location of the pointer.
* CLEAR- Ends program.
* Alpha- Will switch you between Line mode and Circle mode
Change Log
*Circles removed
*Fixed 00 bug.
*Optimized code slightly
Sorry about that, I was copy and pasting from 1.2.2 and I guess i missed that.
There are circles in 1.2.2 but then removed in 1.3 because Axe and Ti-basic draw their circles differently.
If someone were to locate the yay that ti-basic draws their circles, that would be great, and i would put it back in axe if it is possible to wrote in.
What do you mean? Circles are drawn with Circle([center X],[center Y],[radius],{i in TI-BASIC. Check out http://tibasicdev.wikidot.com/one-byte-tokens (http://tibasicdev.wikidot.com/one-byte-tokens) if you need the token values.
except that axe won't work well with floating points, which the command uses a ton of.
Thats why, when i figure a couple of bugs out with EAS, I am planning on useing Pxl_On to make a circle if i can.
For( M,(some equation),(some equation)
Pxl_On(N,O
end.
Note: I just chose random variables, in no way do they correspond with the program.
Thats why, when i figure a couple of bugs out with EAS, I am planning on useing Pxl_On to make a circle if i can.
For( M,(some equation),(some equation)
Pxl_On(N,O
end.
Note: I just chose random variables, in no way do they correspond with the program.
But even that might not match perfectly with the BASIC circle (you noticed how it overlapped some pixels, right?). You should probably use the OS routine, but you'd need to use the Asm( command for that.
Yeah, got it.
Are you talking about the random tokens when you ask for input?
But this project creates a BASIC program that draws the pic for you, like a subroutine, so it couldn't be used for Axe... Not sure what you mean, though.
I am very sure mine is unique though ;D
I am very sure mine is unique though ;D
True. It's pretty useful, too :)
A really awesome but much harder feature would be to make it automatically parse a picture var into lines, circles, and points...
Circles could be complicated, though, since there are multiple ways the TI-OS draws circles (on-screen, homescreen, etc.). But if you could pull that off, it'd be pretty awesome. And the extra pixels that don't fit into a shape can be drawn with pixel plotting.