Hello, fellow members of Cemetech...

In the year or two I've learned TI-BASIC, I've found it fiendishly irking how difficult it is for graphics and UI design. I've seen some "shortcuts", such as ASM libraries, stored pics, etc., but the ASM libraries were too static for what I was doing and the stored pics always got deleted somehow from the curious hands of colleagues.

Maybe its the years of these frustrations that have led me to my first "big" project, which I have dubbed "CalcGL".

Objectives of CalcGL:
▪ Simplify UI/graphics design
▪ Support a wide and versatile set of uses
▪ Be easy to understand even for rookie programmers

Accomplished so far:
▪ Given endpoints, draw line
▪ Given endpoints, draw rectangle
▪ Basic error handling: exit if syntax/parameters

Todo:
▪ Draw rounded rectangles
▪ Draw "tabs"

Pros:
▪ Pretty easy to use...for now...and forever, hopefully...
▪ Written in TI-BASIC! Can be modified to suit your own needs easily.

Cons:
▪ Doesn't store pics as configured right now! All objects need to be drawn as they are loaded, hope to fix this soon...
▪ Written in TI-BASIC. Not as fast nor capable as ASM

How to implement it into a program:

1. Define a variable "Z". This variable is going to be your "parameter". Why use "Z"? Because most programs don't use enough variables to get to Z.

2. Define any other necessary variables (e.g. endpoints of lines, positions, etc.)

3. Call the CalcGL program by inserting "prgmCALCGL" into your code.

4. CalcGL will execute the parameter given the variables. It will NOT cleardraw unless you specify to do so. Control is then returned to calling program.

► Last updated: 1/1/13

This sounds like a very fun project, Alebcay. I'd be happy to provide some feedback, but I also have a suggestion: have you explored the DCS GUI API for TI-BASIC programmers, a la:
http://dcs.cemetech.net/index.php?title=DCSB_Libs

It might do what you need.

How will you be JIT-ing the code?

I meant that the calculator interprets/compiles the code "just in time" for execution, unlike with ASM programs, which are already compiled.



I've looked at the DCS GUI API before, and my aim with this project is to make a liable alternative for people less inclined to working with DCS. CalcGL will likely never be as complex as DCS GUI API. With my past experiences, DCS API had a steep learning curve, despite its immense potential, and only when utilized properly.

That's fine, I won't argue that there's a fair bit of stuff to learn to take full advantage of the DCS GUI API. So let's talk more about the functions you'll be offering to programmers.

Indeed, that's what JIT-compiled means, but how will you be pulling it off? Since none of the mainstream languages for the platform are JIT-compiled, I'm also a bit curious as to how you're managing this aspect.

Right now, for starters, I'm looking into making a tab control, similar to that used in the Alpha-menus in the 84 family.


I thought that TI-BASIC was JIT-compiled, maybe I didn't get my facts straight. Hmm...well my point was that TI-BASIC is still not as capable and maybe just a tad slower than ASM.

Nope, TI-BASIC is interpreted, which is not the same as JIT-compiled. A JIT language is compiled down to bytecode, which then runs on a real or emulated processor. An interpreted language is interpreted at a significantly higher level, where each command or token is executed by a function written in a lower-level language. Depending on what you're trying to do, pure BASIC can be quite capable, but it certainly carries a huge speed penalty, particularly with integer math and graphics.

Ah. Thanks for the clarification! Well then, what I meant was that the GL will run on TI-BASIC, and therefore undergo any interpretation and speed penalties...