I doubt it, as there is the 8.1 ish KB executable code limit on compiled Axe programs. You really need to be careful when adding features to your games then optimize as much as possible for size (since the speed decrease is generally insignifiant anyway).

The major issue regarding large size is if people who don't optimize enough starts splitting their games into multiple Axe programs and launch them with the combination of both BASIC and ASM libraries (such as XCOPY or xLIB/DCS real(10 function) without worrying about optimizing every byte they can anymore.

EDIT: THere is one other thing I hope too: Since Axe is so fast compared to BASIC but much easier than ASM, I hope it won't face the same problem as TI-BASIC always faced due to its high level language status: overloads of crappy games flooding ticalc archives. Quigibo was a bit concerned about that a while ago, too.
Good arguments all around, Kevin. I share your edited concern - perhaps artificially raise the learning curve? Laughing I look forward to seeing how the language and programs written using it evolve, respectively, at any rate.
Oh, don't worry. Trust me, I coded TI-BASIC (and hybrid) for almost 9 years now, and I had AN HARD TIME learning pointers in Axe. Today, I have yet to figure out how to make a decent tilemapper and I haven't even started to mess around with collision detection. Axe is easy to start up with providing you know BASIC, but there are some things (altough not 100% essential to make a game at all) that are a bit more challenging, especially if you almost got no coding knowledge.

Once you learn the pointer concepts, though, you can do awesome stuff, though. At that point it is rather hard to make a crappy game, unless you do it on purpose.

Also Axe has no floating point support yet, which saved us from an invasion of quadratic solvers, so far Smile
wouldn't it be fairly trivial to implement floating point by way of TI-OS bcalls? Or to use one of the floating point libraries here or here or even just rip the routines used by sdcc?
Yeah, but there's very limited tokens I have to play with. No Fadd() or Fsub(). They would have to be typed in some other way. Also, where would the numbers be stored? Either the user would have to carry around a pointers everywhere or I would have to steal some free ram for A-Z letter storage (can't use the OS since its too slow to search the vat). And then you would have to have a bunch of conversion commands to actually have some type of interaction with the floating points. Plus, there would need to be additional routines to display the floating point values. Not to mention how long it would take to add about 100 commands to deal with all these things including other advanced math, which is probably the main reason to use floating points in the first place.

So yeah, its a lot more complicated than just adding some bcalls. It has to be easy and intuitive to use otherwise you might as well use assembly.

EDIT: By the way, 99% of assembly games do not use floating points at all. Its generally considered bad practice. Although I can see the need for math applications, axe is mostly geared towards games.
The next update should be in a couple of days, I will be sure to release a copy here.

If anyone is really new to Axe, especially if you haven't actually used it yet, feel free to ask questions about how it works, what I'm planning, what optimizations are done, syntax, etc. I will be starting some new topics later to address other issues like bugs and maybe even some super secret testing if anyone wants to try some of the new features before they are public.
Fair enough, I'll start with a bunch of questions. I'm obviously new to Axe, and I noticed you're still at 0.3.0, or thereabouts. What additional features are you planning beyond the concept of "ASM speed with BASIC simplicity"? What's the precise mechanism behind it, is it sort of simple macro replacement, or does it do something more complicated? I hope it does some kind of code reuse; does it do optimization? Cheers on all your work thus far.
Depending on the size of the commands, some small things are just macro'd in like bcalls, some math, and other very simple things. The rest create subroutines in the program and then call the subroutine every time the command needs to be executed again like multiplication, sprite drawing, grayscale, etc.

Many mathematical commands are automatically optimized. For instance, adding one becomes an inc instruction and multiplying by 2 becomes adding it to itself. In fact, all addition, subtraction, multiplication, division, and modulus are complete in their optimization since there does not exists another way to do the operation in 6 bytes or less (6 bytes is enough to load the value and then call the subroutine).

Features I am adding very soon will be compiling directly to applications, scrolling to errors in the program editor, reading files from archive, reading and writing to system variables like strings and pictures, eventually some ray-casting perhaps, and of course more optimization. I'm about 50% done in terms of commands available.
Sounds like a good plan. I'll ask this, since I'm notoriously poor at keeping deadlines, at least with regard to Doors CS: do you have any timetable in mind, or are you doing it as you have time? What are your non-TI occupations: school, work?
I try to update weekly (usually Sundays), but sometimes things come up like finals or my quantum physics take home exam... but usually I'm pretty reliable. Full time student with an EECS major, I'm about to be in my 3rd year of college next semester, but I have the whole summer off for now.

I don't want the project to distract too much from my school work, so I am planning to release the final version 1.0.0 by the end of the summer for sure. After that, there won't be releases as often other than to fix bugs and very minor things.

Its especially easy for me to keep deadlines, becasue I just release what I have and comment out the features that aren't complete. Adding a new command I can do sometimes in under 10 minutes. But fixing implied parenthesis with negative signs for example took me 5 hours to get working. Its very often the seemingly simple things that are the hardest. Smile
quigibo wrote:
I try to update weekly (usually Sundays), but sometimes things come up like finals or my quantum physics take home exam... but usually I'm pretty reliable. Full time student with an EECS major, I'm about to be in my 3<sup>rd</sup> year of college next semester, but I have the whole summer off for now.
Nice, I just graduated with a 5-year bachelors of engineering and masters of engineering in EE myself.

quigibo wrote:
I don't want the project to distract too much from my school work, so I am planning to release the final version 1.0.0 by the end of the summer for sure. After that, there won't be releases as often other than to fix bugs and very minor things.
Definitely a smart move, I'm planning on releasing Doors CS 7 by the end of the summer or soon after as well.

quigibo wrote:
Its especially easy for me to keep deadlines, becasue I just release what I have and comment out the features that aren't complete. Adding a new command I can do sometimes in under 10 minutes. But fixing implied parenthesis with negative signs for example took me 5 hours to get working. Its very often the seemingly simple things that are the hardest. Smile
That's fair, personal preference I guess; I prefer fewer but more elaborate releases. And story of my life on those hard-to-trace bugs. Razz
Hmmm for some strange reason the hexpic generator caused a RAM reset on my Nspire....
This is strange. It shouldn't be happening, because it's a pure BASIC program
I know but I was able to duplicate it three times..
I've never had any complaints about that before... strange Confused

Maybe you have a BASIC interpreter that is conflicting with something in the program. Do you have xLIB, Celtic, or a newer beta of DCS installed?
Thrid one
qazz42 wrote:
Thrid one
This was because the HEXPIC program was using the Stop token. In Doors CS 6.6 beta and higher, Doors CS will catch and properly handle the Stop token. Smile
I think its fair enough for me to post here that 1.0.0 was released sometime last night. It adds new language features that coddle people used to functional programming languages very well, song with other many features. A worthy update, rather major change and deserving to be in Gold stance. Great job quigibo, and thanks for adding new functional aspects Smile
By the way, last night SirCmpwn vandalized the Omnimaga forums and deleted the entire Axe Parser downloads thread. Right now no admin are present to restore it from the suspended/thrash bin section and idk if he also edited out the attachments or stuff like that, so I do not know for how long that thread will be unavailable.

As a result, those who need Axe will have to download it from ticalc.org for the time being http://www.ticalc.org/archives/files/fileinfo/428/42813.html (It is the latest stable version)
This sucks. Sorry if your stuff is gone.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement