A command that gets a sprite off a buffer.

I honestly don't think this will be included... Because it's not really about Axe.. But you already have an amazing compiler right here. I think it may take an entire extra App Page, but...
Do you think one type of compile could be made for Axe code (traditional) and then have another feature to compile pure Ti-Basic or library'd Basic into pure ASM, so it runs faster (not interpreted) and it can still be.. ya know.. Basic..?

Quote from: Dapianokid on April 27, 2013, 01:59:39 pm

I honestly don't think this will be included... Because it's not really about Axe.. But you already have an amazing compiler right here. I think it may take an entire extra App Page, but...
Do you think one type of compile could be made for Axe code (traditional) and then have another feature to compile pure Ti-Basic or library'd Basic into pure ASM, so it runs faster (not interpreted) and it can still be.. ya know.. Basic..?

As you said, this has nothing to do with Axe, and that entire app page you are talking about will most likely be a separate app, rather than part of the Axe Parser.

Also, that is not the fact that it is interpreted that makes TI Basic slow. Look at Grammer, it is interpreted and still very fast.

I just thought Basic could be faster. I'm just nowhere near skilled enough to do it, and those that work on Axe are exactly the people who could.
Meh, it was a request none the less.

A menu command!!!! So you can quickly create a menu without going through all the hassle; this would be extremely useful!!!! Please do consider this Runer112!!!
Also some other features that are not as neccesary, but would make this language even better are:
-a tutorial!!!! Axe REALLY, REALLY needs a tutorial that is made for beginners, as there are not to many GOOD tutorials for axe at the moment, which is pretty rediculous considering what a popular language it's become...
-a command for sprites such as Gif(X,Y,[],[],[],[],[] it would allow you to have up to maybe around ten sprites(of which you write in hexadecimal in the brackets and the command annimates the sprites from left to right at the X Y coordinates specified. Along with this there should be a command like GifRepeat(X,Y,[],[],[],[],[] that will do exactly the same as Gif( but instead of stoping after the animation is over it should loop around and repeat the animation forever. You could also have ones that repeat it a certain amount of times, execute it until its False and one until its true. Do consider this as it would be pretty cool in my opinion.
-an easier alternative to tilemapping(tilemapps are extremely hard)
-an on-calc bitmap creator; they are not worth the time to make manually
-there are plenty more features, but ill start with these; please do consider these Runer112 and whoever else is working on axe!!!

A menu command!!!! So you can quickly create a menu without going through all the hassle; this would be extremely useful!!!! Please do consider this Runer112!!!

I will likely eventually want to create a command that creates OS-style menus. I've added this to my todo list for Axe, which is unfortunately very massive already, though. But for any different or more graphical menus, you'll have to write the code for them yourself. There is no one universal code that could render and control any menu a programmer could want.

-a tutorial!!!! Axe REALLY, REALLY needs a tutorial that is made for beginners, as there are not to many GOOD tutorials for axe at the moment, which is pretty rediculous considering what a popular language it's become...

Have you fully read through the Documentation.pdf file included with Axe? It's a little outdated and only covers the basics, but it does so fairly well. To help with the outdated-ness, I'd also recommend reading the attached Changes.pdf, which details some of the big changes that were introduced in Axe 1.0.0 and haven't found their way into the main documentation yet. After that, you should have enough basic knowledge of Axe to begin reading through the Commands.html file and learning/trying any commands which seem useful for you and your projects. And if you have any questions about how perform specific tasks or how commands work, just ask!

As for an actual tutorial, I'm not sure if it's really possible to make a complete "tutorial" that will teach you how to do everything with a whole programming language. I think the closest approximation would be learning the dictionary and grammar of the language and learning how many regular tasks and algorithms would be handled with the language.

By far the most complete tutorial I know of for Axe, by kindermoumoute (where'd you go? ), can be found here. It goes very in depth on an amazing breadth of topics, has tons of examples, and even has quizzes. I am extremely pleased with the work he put into it, and I think it's far better than I could ever do. There's a catch, though: it's written in French. For now, the best solution is to use something like google to translate each page (Chrome should offer to translate it automatically when you visit pages). The translation is mediocre, so take it with a grain of salt. And I've found it can mess with example code, so I usually keep an untranslated view of the page in another tab for looking at code.

-a command for sprites such as Gif(X,Y,[],[],[],[],[] it would allow you to have up to maybe around ten sprites(of which you write in hexadecimal in the brackets and the command annimates the sprites from left to right at the X Y coordinates specified. Along with this there should be a command like GifRepeat(X,Y,[],[],[],[],[] that will do exactly the same as Gif( but instead of stoping after the animation is over it should loop around and repeat the animation forever. You could also have ones that repeat it a certain amount of times, execute it until its False and one until its true. Do consider this as it would be pretty cool in my opinion.

It sounds like you believe that the calculator/Axe has some sort of underlying rendering engine, but unfortunately there isn't one. Every ounce of rendering logic has to be provided by the programmer/user. Drawing commands simply draw the one thing you tell them to draw, and that's it. They don't have memory areas that can keep track of animation progress for arbitrary sprites; they're stupid. The programmer is what makes programs smart, providing logic about how to act and what different things to display.

-an easier alternative to tilemapping(tilemapps are extremely hard)

For drawing 2D maps of tiles, there really is no other way than tilemapping. Tilemapping is, by definition, the method of rendering a map composed of tiles.

-an on-calc bitmap creator; they are not worth the time to make manually

This is the kind of thing that would be a completely separate program/application for image editing, or perhaps integrated into an IDE. It wouldn't be part of the Axe compiler, and the Axe bitmap format is publicly available so such a tool doesn't have to be made by an Axe developer (me). Anyone can make such a tool, even you!

-there are plenty more features, but ill start with these; please do consider these Runer112 and whoever else is working on axe!!!

Feel free to keep suggesting!



EDIT: Why didn't anybody tell me I forgot to attach Changes.pdf?

Tables, structures and other object oriented stuff would come in really handy. As of right now making the data structures for enemies, bullets etc. are pretty much hardcoded. If I want to add an extra variable to an object I'd have to change around a lot of code just to be able to do that. For my game HeroCore I simply forgot to increase the amount of bullets that can be drawn on screen and now I'm stuck with 6. If I want to increase it I have to increase 6 to x every time it occurs in the code.

Tables and structures are big asks. However, I completely agree that they would be very useful. I'll certainly be investigating the possibility of implementing such language features for the next major revision of Axe. But that may be (read: is) a long way off!

Example for possible implementation of very basic structures:
[A,B,C,D]->structureToken1    // preprocessor returns the pointer to the first element in the structure (structureToken1.A)
10->{structureToken1.A}          // store 10 in memory location structureToken1.A (same as pointer structureToken1)
{structureToken.A}++           // increase value at memory location structureToken1.A
disp >dec                   // display result: 11