Omnimaga

Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on February 02, 2010, 04:16:50 am

Title: Features Wishlist
Post by: Quigibo on February 02, 2010, 04:16:50 am
If you have any requests for new commands post your ideas here.  also, it would be helpful if you provide what you think would be a good syntax for that command.  Keep in mind that if you redefine a BASIC command, it should either be useless or there should be a way to still perform the old command in a different way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 02:28:02 pm
True, I think it's essential to not completly ditch certain important commands for others.

As I suggested via yahoo a week ago, something like:

Text(Method,Y,X,string

For method:

-1=big fonts
0=small fonts
1=big inverted fonts
2=small inverted fonts

And obviously, for most drawing commands (maybe even Text(, if not too hard), store what's displayed in the graph buffer, not directly to the LCD, so people can update the display whenever they want (reducing flickering when sprites moves around for example)

EDIT: Not completly ditch pictures as support. Pictures as BASIC coders knew them I mean, else I don't think people will be very happy if their title screen takes 96 sprite slots and have to be displayed sprite by sprite
Title: Re: Features Wishlist
Post by: Silver Shadow on February 02, 2010, 03:25:44 pm
I want sprites. And possibly not only 8x8.
Title: Re: Features Wishlist
Post by: Quigibo on February 02, 2010, 04:28:18 pm
Sprites are absolutely an essential part of this.  I will probably only support 8x8 and 96x64 sprite sizes though.  If you need other sizes, you can write your own subroutines to display them.  For instance, in Pyoro, the bird is a 12x12 sprite, but I draw him using 4 8x8 drawing routines for each corner.  If I do end up supporting other sprite sizes, it will probably be very late into the development.
Title: Re: Features Wishlist
Post by: ztrumpet on February 02, 2010, 04:47:37 pm
This is so awesome!  I really like the different picture sizes.  :D
*ZTrumpet dosn't accually have a wishlist, as the other topic brought out all my suggestions. ;D
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 05:02:18 pm
The only feature i have to request right now is pixel editing and isKeyDown() to check whether or not a key is down :)
Title: Re: Features Wishlist
Post by: Galandros on February 02, 2010, 05:40:45 pm
A keyget command.
Use jim e routine (found in his grayscale lib) or the one in the WikiTI.

I can give a nifty routine to check only the arrows pad with multiple directions.
Title: Re: Features Wishlist
Post by: calc84maniac on February 02, 2010, 06:43:54 pm
With string parsing you should include an "escape character" like in most programming languages, so you can put quotes and sto (or even raw characters inputted as hex) into strings without hassle.
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 02, 2010, 10:23:13 pm
just out of random curiosity would/will there be like flashrom commands or somthing to interface with teh flash rom?


hmm trying to think of what else there could be XD
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 10:30:07 pm
Well for now i think we should just leave Quigibo in peace with what we have suggested so far, lets not let this get out off hand :P
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 02, 2010, 10:34:54 pm
hmm yeah probally a good idea :P 

hmm quigbo how much of the total app space have you used up so far??(out of teh whole thing :))
Title: Re: Features Wishlist
Post by: Quigibo on February 02, 2010, 11:28:09 pm
hmm quigbo how much of the total app space have you used up so far??(out of teh whole thing :))

Only like 4 or 5 kB so far I think.

Feel free to post all your ideas.  I just won't be able to implement them for a while, but its good to have a large collection of ideas for when I do.  I'm almost as the point where the commands and code for each command is completely templated, making adding new features a breeze.  After that point, the functionality will skyrocket.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 11:46:45 pm
Due to the recent increase in forum activity, let's just make sure to read through this thread before posting ideas to prevent reposting the same ideas many times when it gets big x.x, so it won't clutter the topic too much, altough if someone posted a confusing idea I could understand if someone posted the same idea worded differently, thinking it's something totally different
Title: Re: Features Wishlist
Post by: Eeems on February 02, 2010, 11:46:52 pm
A way to make intterupts would be nice. Like somehow registering a bunch and they disabling them at the end.
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 11:48:38 pm
Ooooh nice ^^  Well in that case here i go...

Screen Shifting (couldn't find a good token)
It could either be implemented, or you would use the simple hex codes, i hear its pretty short

Get()/Send()
Used for actual sending of bytes like in Omnicalc

OpenLib()
Import code form other programs (like include?)

DrawInv()
Inverts the screen

randInt(A,B
more support for random values.  From A to B

Func
Function support, like subs with arguments.

Output()
Similar function as in basic.  Makes text menus easier

Fill()
Fill/Outline rectangles

Recall/StoreGDb
Possible appvar storage?

Alright, those were all the ones i could think of.  Al the rest that i had in my head could be built of these pluss the graphics/sprites commands
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 11:50:05 pm
I never got the send commands in Omnicalc. What's the use of sending a byte to another calculator? What does that bit does that is so much special? It was always cryptic to me, even after having read the manual.
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 11:55:33 pm
It was so that you could make multilayer games using the link cables.  You could send a byte (0-255) to the other calculator which would recieve it if it was in get() mode.  You could set up a system where the calculators would be sending bytes back and forth that represent things like keypresses or positions, and have a multiplayer game set up.  I made a couple of games using this as a test, but mostly Basic was just too slow to handle the stress of having to take into account an extra player.  I made a few simple things like two players could move around on a screen and shoot things at eachother, but nothing ever was finished.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 02:10:21 am
yeah but how did you check what's the content of the byte? I mean if you wanted to send a keypress? Did you just put the variable name inside the command or could you just send a number from 0-255 to like the receiving calc ans var?
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 02:56:09 am
Well the send( command took a number as an argument, which could be any real from 0 to 255.  The get() command would return either a value from 0-255 in ans, or -1 if nothing was being sent at the time. 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:04:02 am
aaah ok, so i guess the -1 can be used to detect if the calcs are linked, right?
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 03:16:45 am
Yeah, and there was also a feature to have it wait indefinetaly for an incoming byte.  Once you get the calcs syncted up, it makes things a lot easier :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:42:55 am
Ah that's good. I guess in the future it could maybe be a good feature to add in Axe. I think dealing with linking in ASM is incredibly hard, though. Even ASM coders like Iambian or Calc84maniac have trouble with it.
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 05:05:07 am
Linking is easy.  Syncing is hard.  Really, no matter what routine I write for linking, it is up to the programmer to write code that will properly synchronize the calculators.  Lets say you need to send some critical data from calc A to calc B.  You have to send the byte, but calc B might not be ready to receive a byte, so you have to keep sending until calc B sends a confirmation byte back to calc A. When time is critical, you have to be very cautious about how often the calcs check to see if there are incoming bytes.  It needs to be frequent enough so there aren't long delays between sending, but sparse enough to not slow down the program.
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 10:26:05 am
Yeah, getting the calculators synced, and making them STAY synced with omnicalc was a real real pain.  I had a system that worked with omnicalc, but it made each program twice as slow because it spent half the time waiting for the other calculator x.x
Title: Re: Features Wishlist
Post by: Galandros on February 03, 2010, 12:18:20 pm
Could interrupts be suited to the task?
Implementing interrupts in Axe would be phenomenal.
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 03:14:36 pm
I actualy a command that I would like to see in the next release.  The ability to turn onblocl off.  It's a bit unhappy-making when you accidently get stuck in a loop durring testing and have to pull your bateries
Title: Re: Features Wishlist
Post by: Silver Shadow on February 03, 2010, 03:17:10 pm
Its even more horrible on the NSpire: you can't take out the batteries. The calc auto-shuts down before you have the time to do it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:55:11 pm
Oh yeah on block off might be a good idea, back in the days I had a basic program where I used an ASM lib that disabled ON and a bug in a getkey loop caused the game exit functions to not work and I lost everything x.x
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 04:35:31 pm
I assume you all mean that when you press the on button, it breaks the program.  Unfortunately this is nearly impossible since you'd have to break out of an unknown amount of subroutines and the stack would not return the program to the home screen.  Now, I could implement something that saves the stack size and creates an interrupt for exiting when the on button is pressed, but it would take up probably around 200 extra bytes or so and be very complicated.

You will be able to poll the [on] key as a direct key input though, so you can always manually check if it needs to exit.

I have a feeling that if I do implement interrupts, it will be towards the end of the development.
Title: Re: Features Wishlist
Post by: ztrumpet on February 03, 2010, 04:47:16 pm
You will be able to poll the [on] key as a direct key input though, so you can always manually check if it needs to exit.
You're not understanding the Why.  The use of Breaking a program allows the programer to exit the code from anywhere, not just where the code checks for it.  Could you have this in there as an option please?  The reason it helps is because basic programmers test on calc, vs using an emulator.  I think it's possible, as the TiOS does it.  Could you backup the Ram into xRam and then rewrite if the user presses On?  Mabey you could use the token ">Dec"  to serve as "Debug (On breaks) Mode On"?
Mostly people that program On calc want security. :)  In my opinion that is the worst thing about Asm, or any program that Blocks On.  Thanks! :D
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 05:02:09 pm
It is not possible to arbitrarily break a program from asm without using interrupts and special exit code.  BASIC is interpreted so that's why it can break anywhere.

Luckily however, the security is taken care of by Axe Parser itself.  It will give you the option of automatically archiving all the RAM including your source code before testing your program so that if it crashes, you have everything backed up and you don't lose anything.  I will start working on these features in a few weeks probably.
Title: Re: Features Wishlist
Post by: ztrumpet on February 03, 2010, 05:16:13 pm
Thanks!  I think that would work too. :D
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 05:43:49 pm
Oh that's too bad.  Out of curiosity, what happens if you try to break out of the program while within a sub?  Does it just crash then?
Title: Re: Features Wishlist
Post by: calc84maniac on February 03, 2010, 05:54:26 pm
Apparently you can't break at all, so it doesn't matter. But Quigibo, if you save the stack pointer somewhere at the beginning of execution, it should be no problem (this method is used quite a bit in asm programs iirc)
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 07:03:12 pm
So what would happen if you broke out of the program but didn't restore the stack pointer?
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 07:05:16 pm
Apparently you can't break at all, so it doesn't matter. But Quigibo, if you save the stack pointer somewhere at the beginning of execution, it should be no problem (this method is used quite a bit in asm programs iirc)
Yes I use this too.  But it would still require a special interrupt setup and interrupt routine which might prevent custom interrupts.  Regardless, I think I'll just worry about this later and focus on the more important stuff for now.

Quote
So what would happen if you broke out of the program but didn't restore the stack pointer?
It would return out of the subroutine without finishing it causing unknown consequences.  It would not exit the program either.
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 11:59:59 pm
Sorry to double post, but I've just started to add the "Output()" feature and I'd like to get some feedback on it.

I know that native BASIC uses Output(y,x) but I much prefer the form of Ouput(x,y).  Should I keep it the old way to less confuse people transitioning from BASIC to Axe, or should I change it to (x,y) so that its more consistent with "Text(" "Pt-On(" and the other drawing commands?
Title: Re: Features Wishlist
Post by: calc84maniac on February 04, 2010, 12:02:28 am
Sorry to double post, but I've just started to add the "Output()" feature and I'd like to get some feedback on it.

I know that native BASIC uses Output(y,x) but I much prefer the form of Ouput(x,y).  Should I keep it the old way to less confuse people transitioning from BASIC to Axe, or should I change it to (x,y) so that its more consistent with "Text(" "Pt-On(" and the other drawing commands?
I think you should keep the old way, but start counting at 0 instead of 1.
Title: Re: Features Wishlist
Post by: jsj795 on February 04, 2010, 12:13:30 am
Also, I think Text() is also (y,x) along with pixel-on/off/change/check.
It's only line(), Pt-On/Off that's (x,y)
I'll rather have it (y,x), since I got so used to it
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 12:17:14 am
Haha, i would suggest using x,y and starting at 0 :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 04, 2010, 12:24:39 am
I personally would suggest x,y and starting with 0, to be more consistent with every other functions. I myself easily get confused with the BASIC output cuz I am so used to x being first in graphical functions except Text x.x

It would also help people get more used to standards
Title: Re: Features Wishlist
Post by: Eeems on February 04, 2010, 12:39:53 am
(x,y)
because of aforementioned reasons.
Title: Re: Features Wishlist
Post by: Silver Shadow on February 04, 2010, 07:04:40 am
(x,y) and starting from 0
Title: Re: Features Wishlist
Post by: Galandros on February 04, 2010, 07:06:33 am
Yes I use this too.  But it would still require a special interrupt setup and interrupt routine which might prevent custom interrupts.  Regardless, I think I'll just worry about this later and focus on the more important stuff for now.
Just hook the program interrupt and the break interrupt. Not hard, I think. And yes, essential features first.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:50:20 am
Haha, i would suggest using x,y and starting at 0 :P
I'd have to agree here. =)
Title: Re: Features Wishlist
Post by: Quigibo on February 04, 2010, 03:53:57 pm
Alright, (x,y) at 0 it is!  I've finished that command.  Interestingly enough, "Output(" and "Disp" are nearly identical commands.  The only difference is that output first gets the coordinate position.  Then, after the second comma, the compiler treats whatever follows as if it were a Disp command.  Since my Disp command, unlike BASIC, does not have automatic line returns, they really are equivalent!  That also means that things like Output(x,y,Str1,"Hello",Str3) are valid.

Thanks for the feedback!
Title: Re: Features Wishlist
Post by: ztrumpet on February 04, 2010, 04:23:01 pm
Wow, that's really cool.  So it's like this (in basic and on the graphscreen in my example): Text(-1,8y,6x,Str1,"Hello",Str3

Excellent!
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 05:14:34 pm
Woot!  So when is the next release coming around?  

* Builderboy is eager to start making primitive ASCII games in asm ^^ *
Title: Re: Features Wishlist
Post by: ztrumpet on February 04, 2010, 06:39:46 pm
ACHII
Do you mean ASCII?
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 06:51:19 pm
Haha yeah oops :P
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:40:58 pm
Wow, self aware software is apparently a master of typos. j/k :P
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 07:42:47 pm
Its an imprecise technology >.>

Mostly the error was due to attempting to interface with such a device such as the iTouch using remotely controlled gerbils.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:48:12 pm
Mostly the error was due to attempting to interface with such a device such as the iTouch using remotely controlled gerbils.
Lesson learned: Never use gerbils for a job better suited to something with opposable thumbs!
I'd also like to second that at some point, linking would be uber cool.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 02:15:31 am
Can't iTouch spellchecker be disabled? I personally would disable it if it was gonna do such typos x.x
Title: Re: Features Wishlist
Post by: Builderboy on February 05, 2010, 02:57:06 am
Yeah I think it can, imma have to see I can find that.
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 04:03:53 am
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

Another option is to store pictures using Hex code.
Code: [Select]
[3C7EDBFFBDC37E3C]->Pic1A
It uses less space in the source, but it would require you to run an external program to convert a pic into Hex code.

A third option is to save the sprites as tiles on one of the picture files.
Code: [Select]
GetCalc(Pic1,8,16)->Pic1A
The biggest problem with this is that the source is dependent on the extra picture files and it is difficult to draw the sprites on-calc (although I guess you can still use an external helper program).

Does anyone have any other ideas for how to define sprites?  Or a better syntax?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 05:27:19 am
If an hex code is done, I think it might be best that someone writes a binary to hex converter or something else it will be hard to add 300+ sprites in a game x.x

Maybe it would be cool if you allowed sprites to be stored in a set of TI-BASIC pictures, for example pic1, 2 and 3, and upon compiling, the user would be asked how many sprites the program will include. Then it would store each 8x8 sprites contained in the pic in separate sprites, scanning the pic from left to right and top to bottom, storing them inside your compiled program
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 08:16:47 am
Whatever method you choose for sprites I would prefer if Axe did not have to rely on a seprate external program to implement sprites. However, if the most efficient way to handle sprites is by the use of an external program then I am all for it. Hmm... perhaps sprites could be stored in a user defined appvar and called from there?

Actually, now that I am thinking more about it, I think an external program would be the best way. It would be used to edit, view, and save sprites.

For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.

Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.

At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Title: Re: Features Wishlist
Post by: Eeems on February 05, 2010, 10:04:15 am
I'd rather do hex for small sprites, but for large ones, what art said is good.
@builderboy:there is an option in settings, but be carefully if you are a fast typed like me, it can actually hurt you to have it turned off.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 11:55:49 am
Actually now that you mention it, maybe the option of storing sprites to an external program might be an idea if the program is archived. That way games with a lot of sprites wouldn't be a big problem to be ran in 24 KB of RAM. The issue, though, is that running stuff from archive would be much slower
Title: Re: Features Wishlist
Post by: ztrumpet on February 05, 2010, 04:21:18 pm
Can you have "input" input at whereever the cursor is at, moved around with output?

------
Pictures:
I think you should have both Hex and external AppVars.  I think it would be easier like that.

If an hex code is done, I think it might be best that someone writes a binary to hex converter or something else it will be hard to add 300+ sprites in a game x.x
DJ, I wrote this a while ago.  It works for both 8*8 and 16*16 sprites.  You select what you want to do, and it will do exactly that.  It may take some trial and error, but I also have a screenie. ;D
Title: Re: Features Wishlist
Post by: Eeems on February 05, 2010, 04:36:43 pm
it could be slower unless at the start of the program it extracts the sprites to somewhere on the excess RAM and then run it from there (excess as in one of the extra pages, of course this could be limiting on newer calcs, who have way less extra ram...)
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 05:58:49 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 06:07:59 pm
To be clear I just meant the Appvar as storage to hold the sprites. When Axe compiles the program the sprite data would be copied from the Appvar to your new program. You'd only need the Appvar if you wanted to "build" the program. That way it wouldn't need to remain on calc after you complete your program. Although, If you release the source with your program, I'm sure you'd want to include the Appvar as well (so it would be buildable)
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 06:13:04 pm
To be clear I just meant the Appvar as storage to hold the sprites. When Axe compiles the program the sprite data would be copied from the Appvar to your new program. You'd only need the Appvar if you wanted to "build" the program. That way it wouldn't need to remain on calc after you complete your program. Although, If you release the source with your program, I'm sure you'd want to include the Appvar as well (so it would be buildable)
Why use an appvar?  Why not just a picture file?  The picture file would be less memory and in addition to that, it is more editable.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 08:23:55 pm
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

In your original post you mentioned that using Picture files would take up alot of space, so I was trying to find an alternate workable solution. Perhaps I misunderstood and you just meant the picture files themselves were large? If that's the case, I don't mind. Picture files don't take up that much space in my opinion.  Additionally, if someone wanted to make a really large game they wouldn't have to worry about having to use hacked picture files. An Appvar can also be named whatever the user wanted. If using hacked pictures isn't a problem then picture files would be a much better solution.
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 05, 2010, 08:36:51 pm
the only other reason i see y you would do as art said is that also there are only a small amount of pics and if your programming basic games as well at the time it could be hectic with remembering whats what X.x
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 09:43:34 pm
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

In your original post you mentioned that using Picture files would take up alot of space, so I was trying to find an alternate workable solution. Perhaps I misunderstood and you just meant the picture files themselves were large? If that's the case, I don't mind. Picture files don't take up that much space in my opinion.  Additionally, if someone wanted to make a really large game they wouldn't have to worry about having to use hacked picture files. An Appvar can also be named whatever the user wanted. If using hacked pictures isn't a problem then picture files would be a much better solution.

What I was referring to is drawing pictures in the program like you quoted.  "Pic1A" is just a name, not a picture file.  If you literally type out the 1s and 0s (or in this case, hyphens and asterisks) to make a sprite, that takes up about 10x more space than it needs to in the source.  But also, if you only have lets say ten 8x8 sprites in the game, and you store them in Pic1, then you are wasting 90% of that picture since you're not using all of it.  Also, if you include the size of the picture and the size of the source code needed to tell the calculator which part of the picture to use, then it really comes out to about the same memory usage as pure Hex code.

Edit: Actually, I take that back, you can archive the pictures.  But its still not that much more memory efficient than Hex.

BTW, is everyone aware that all the user variables: Labels, Strings, Sprites, Pictures, etc. all have 2 byte names similar to labels?  You are not limited to Str0-Str9, you actually have Str00-Str9Z, which is 370 strings total.  Same with sprites and everything else.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 01:25:15 am
mhmm nice to know ^^
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 06, 2010, 08:05:35 am
Ok, I see what you mean now. I think I'd prefer reading sprites from a Picture file, but hex sprites wouldn't be too bad either.
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 12:48:47 pm
I would like to have the option for both...and what about tokenized hex? That would decrease the size by half. Could you have like an option field so the user can enter where it wants it to grab the sprite from? And for hex, can it be from labels or something? That would be nicer for when you call the sprite more then once to cut down on source code size.
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 01:48:41 pm
This sounds really nice!
I think I'd write best in hex (My Preference). :D
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 02:09:18 pm
Yeah I'd prefer hex (unless I have a large amount of sprites) but with hex I'd rather have support for tokenized hex so I can save room. Tokenizimg hex is as putting the hex into a program doing the asmprog() on it, and then unlocking the program. Either that or justuse Celtic III's hex to bin function.
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2010, 02:24:29 pm
Hmmm, id rather not have tokenised hex, as then you would have to rely on other assembly programs besides Axe, and i think that would kind of defeat the purpose a little.  I personally would like either Pics or Pure Binary as the picture format storage, as they are the easiest to view and edit, a must while working on games.  Pics would be used when you have large ammounts of sprite data, and could be archived if needed.  And Binary would be used when you have a small amount of sprites or just want to play around a but.  And then when compiling the program, the pics/binary would be stored into the program itself so that there is no need for any pics/appvars to run your program.
Title: Re: Features Wishlist
Post by: Galandros on February 06, 2010, 02:44:54 pm
Base64 ftw. Kidding. ^^"

There are many ways to do the sprites storage...
I prefer a Appvar to store the sprites (and other data) in raw data (binary). Appvars can be any size we need, are compact and fast because we will store raw data. (this reminds CelticIII features...)
The only cost is we need some extra coding to edit the sprites and store to appsvars but it is definitely worth it.
Or just put it into the program file in the end after an special token with something like Data...
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 03:25:00 pm
@builderboy: what do you mean you would have to relly on other asm programs?? You would just recall the tokenized string/program into te source and then axe would parse it.
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 03:53:10 pm
@builderboy: what do you mean you would have to relly on other asm programs?? You would just recall the tokenized string/program into te source and then axe would parse it.
You somehow have to unlock the Asm program.  I'd use Oasis... ;D

After thinking about what Builderboy said, I think pure binary would also work nicely.  What do you think Quigibo?
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 04:02:40 pm
Well that's true, but you would usually have a shell or something on your calc. Or Quigibo could include something in axe that would let you do that.
I wouldn't like to use binary, it takes way too much room. But if you could let us have the option of with hex or binary that would work. 
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2010, 04:39:45 pm
As everyone will soon discover, later probably than sooner, all user defined variables are actually pointers.  Str1 and Pic1 will be able to be used anywhere the other can, they just point to where the data is.  So you can define a sprite with a string similar to tokenized hex, or vise versa if you need special characters.

Just to simplify things though, the next release will only support Hex sprites for now.  I'll get to the more complicated sprite formats later.
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 04:45:30 pm
ah ok, well that is good :D
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 05:30:50 pm
Yay Pointers!
Sounds good.  I can't wait for 0.0.4! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 05:42:18 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
Yep, that would be pretty useful. A lot of people use Paint/Photoshop to create their sprite sheets or they do them on calc and store as pics, so an editor like this would make it much easier for them to draw sprites, cuz creating sprites in hex can be quite hectic x.x
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 06, 2010, 07:31:07 pm
For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.

Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.

At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Pics would be used when you have large ammounts of sprite data, and could be archived if needed.  And Binary would be used when you have a small amount of sprites or just want to play around a but.  And then when compiling the program, the pics/binary would be stored into the program itself so that there is no need for any pics/appvars to run your program.
This is what I was saying as well. However change "Appvar" in my original quote to "Picture files".
Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 10:18:52 pm
Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?
I like that idea, but I think it would be compiled to the format the calc uses for storing assembly programs. (I think it's internal-binary.  Am I right?)
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 10:26:41 pm
Tokenized. I want that too.
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2010, 10:59:25 pm
So these are the currently wanted formats to store the source data in if i cam correct:

Pics: Easy to edit and easy to view/preview sprites.  Take up a lot of space however and source will not be in one file.  Pics may or may not be archived to save memory, and storage is efficient with 8 pixels per byte)

Binary: Just 1s and 0s in the program, easy to type and edit, and easy to preview, however this is VERY memory inefficient, at 1 byte per pixel.  Cannot be archived either, as it resides in the source program.

Hex: Similar to Binary but every 4 bytes is represented as a char from 0-F.  More memory efficient but harder to see what the sprite is supposed to look like, and harder to edit.  Cannot be archives. 4 pixels per Byte.

Tokenised: Taking Hex a step further, each 2 hex codes is tokenized by a program or the OS and recalled into the program.  Twice as efficient, but even harder to edit/preview.  Cannot be archived.  8 pixels per byte.  Same storage capacity as a pic, but can change size according to how many sprites you need.

Appvar: Data is stored in an appvar by some sort of sprite editing program and can be archived for memory uses.  This is memory efficient but makes for difficult previewing and multiple files for the source.  8 pixels per byte.

I personally am for Pics and Binary, if only because Hex/Tokens/Appvars are difficult to edit quickly and preview without external programs.  Also for making large amounts of sprites, like for huge tilemaps, it would be nice not to have a bunch of hex/tokens in your program, and be able to view the whole sprite map in one pic.  It also helps for sprites that are greater than 8x8, as they will have to combine multiple 8x8 sprites, which might be difficult to do/visualize with hex/tokens.
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2010, 11:23:28 pm
By the way, tokenized sprites will not be able to work properly now that I think about it.  How would you indicate the end of the sprite data since every combination of characters is possible?  I would either have to use escape characters, in which case you might as well use hex, or you would have to predefine the size of the block of data.

Either way, I think this is against the point of the program.  You should not need any tools to actually code which is something I find very annoying about the BASIC language (like trying to get special characters).  The only tools you should need are those that will come built into axe which will include symbol charts, a sprite editor, a help manual, and maybe some other stuff.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 11:44:07 pm
I never heard of tokenized sprite before x.x
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 11:57:53 pm
Well you could define how big it is and it would know. Also, you could provide a simple hex tokenizer for the developers.
Title: Re: Features Wishlist
Post by: Quigibo on February 07, 2010, 12:26:43 am
Don't forget, no matter what method you use to define sprites in the source, the assembled program will be the EXACT SAME SIZE.  And since you can archive your source files, and you can have more than one source file in the same project, efficiency is really a non-issue; they're just for the programmer's convenience.  Editing a sprite on-calc and then doing [rcl] [str1] or something for hex code seems, for me personally, to be the fastest and easiest way other than strait binary.  And also, I've already written code to read hex code used in the Asm() feature.  So only a slight modification will be necessary.  I can also modify my helper program so that 16x16 sprites can also be made easily.

The only advantages I see in using picture vars is that you can edit them on the computer and its easy to change an entire sprite set by just swapping a picture.  But I don't know how useful those features really are for most people.

By the way, I'm going to be very busy the next couple of days so the next update probably won't come until later in the week.

Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 07, 2010, 12:49:54 am
Keep in mind, though, that most of us have little to no asm knowledge, though, so it is hard for us to figure out why something will work and why it won't, and while it can be easy for some people to understand some stuff it can be much harder for others, not to mention there's a lot of info so eventually we forget some stuff. You have to understand that and make sure to not make people feel bad in any way. We don't want to scare away users from the forums (or from contributing to these project topics/ideas) after all. We welcome everyone, regardless of if they understand quickly or not.

That said good luck with your stuff including school and the like, I hope they won,t overload you with too much projects and stuff x.x
Title: Re: Features Wishlist
Post by: ztrumpet on February 07, 2010, 10:32:55 am
I never heard of tokenized sprite before x.x
DJ, this is what the calc stores Asm Programs in as AsmComp( takes them from Hex to Tokenized binary.
It basicly combines two hexadecimal numbers into one token.  Therefore, it's twice as small. :)

Have fun being busy. Good luck! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 07, 2010, 02:20:39 pm
Aaah that, I see. I always thought it was "compiled" or "squished" (the first is because of the Comp part of the AsmComp( command and the later is because some ASM programmers said "squished" ASM programs to define non-hex ASM program format.)
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 06:45:40 pm
I have a suggestion for the parser. You should have a character (I'm thinking "?") that acts as an operation modifier, for things that can possibly have more than one use. For example, "?>" could be used as signed compare, and "? or " would be bit-wise or, while " or " would be boolean or. It could also be used in strings as an escape character, for example ?" would put a quotation mark in the string and ?X41 would put the character 0x41 (or "A")
Title: Re: Features Wishlist
Post by: ztrumpet on February 09, 2010, 07:09:16 pm
Great idea!  I assume you mean strings would look like this: "Part 1"+?41+"Next Part"+Str1  If Str1 was "Hi" then it would result as "Part 1ANext PartHi".  Sounds cool. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 09, 2010, 07:19:46 pm
I'm confused what would it do x.x

I would need concrete examples of it in action to figure out x.x, as I am more visual
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 07:25:56 pm
Great idea!  I assume you mean strings would look like this: "Part 1"+?41+"Next Part"+Str1  If Str1 was "Hi" then it would result as "Part 1ANext PartHi".  Sounds cool. :D
Actually, I was thinking "Part1?X41Next Part"+Str1. The X might not be necessary I guess, but it might simplify parsing. To put a question mark in a string, you would use "??"
Title: Re: Features Wishlist
Post by: Builderboy on February 09, 2010, 07:29:59 pm
Usually what escape characters are for is for getting 'illigal' characters into strings, like -> or ".  Generaly speaking anything after an escape character is ALWAYS considered to be text, no matter what.  so "?->" would be a string containing the -> character.  It could also be used to access characters that are not type-able, like the percent sign or perhaps even the newline character.

Other uses it has is keeping up with the limited tokens that we have to work with.  If we wanted to be able to do both Bitwise OR and Boolean OR, without the escape character (which in this case can modify functions) we would need two different tokens for the two different functions.  With this escape/modifier, we could have individual tokens mean different things.

(And to get the ? character in your string, i guess you would have to do ?? in your string :P)

EDID: Ninja'd by Calc84
Title: Re: Features Wishlist
Post by: Quigibo on February 09, 2010, 08:16:10 pm
The next version has already taken care of getting 'illegal' characters into strings using standard tokens.

Let me just explain signed vs unsigned so it doesn't confuse anyone.  All the numbers are unsigned meaning they represent a number between 0 and 65535.  Negative numbers act just like the regular numbers counted backwards instead of forwards, that is -1 is really 65535, -2 is really 65534, etc.  This allows normal subtraction and addition with negative numbers that everyone is used to.

That's all well and good until you have a statement like -1<1.  That would actually be false since 65535 is not less than 1.  You can get around this by doing a 'signed comparison' which is what calc84maniac is talking about.  The limitations with signed comparison is that your numbers can only be half the size, that is -32768 to 32767.  So you would not be able to use the signed comparison (and get the correct answer) if the number is too large or too small.

This is an good idea to implement, but I think I would want it more intuitive than a question mark.  Maybe something like -1<<1 would be better?  Repeating any operation twice will do the signed version of the operation.  So -4<<2 equals 1 and -2**8 would equal -16.

Oh and by the way, bitwise and Boolean or are identical, there is no reason to separate the 2.
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 11:38:20 pm
The next version has already taken care of getting 'illegal' characters into strings using standard tokens.

Let me just explain signed vs unsigned so it doesn't confuse anyone.  All the numbers are unsigned meaning they represent a number between 0 and 65535.  Negative numbers act just like the regular numbers counted backwards instead of forwards, that is -1 is really 65535, -2 is really 65534, etc.  This allows normal subtraction and addition with negative numbers that everyone is used to.

That's all well and good until you have a statement like -1<1.  That would actually be false since 65535 is not less than 1.  You can get around this by doing a 'signed comparison' which is what calc84maniac is talking about.  The limitations with signed comparison is that your numbers can only be half the size, that is -32768 to 32767.  So you would not be able to use the signed comparison (and get the correct answer) if the number is too large or too small.

This is an good idea to implement, but I think I would want it more intuitive than a question mark.  Maybe something like -1<<1 would be better?  Repeating any operation twice will do the signed version of the operation.  So -4<<2 equals 1 and -2**8 would equal -16.

Oh and by the way, bitwise and Boolean or are identical, there is no reason to separate the 2.
But shouldn't << be shift left or something?

Also, bitwise and boolean OR are different.
5 | 2 = 7
5 || 2 = 1 (and the "2" expression isn't evaluated because 5 is non-zero)
Title: Re: Features Wishlist
Post by: Quigibo on February 10, 2010, 12:14:53 am
If you want 5 | 2, then you can do "5 or 2".
If you want 5 || 2, then you can do "5≠0 or 2≠0" since this is basically what a Boolean "or" would do for you anyway.  While I agree it could be made more efficient by a c style Boolean operator where the second argument may be skipped if it does not need to be checked, I don't think its worth it.  You're almost always going to use "or" and "and" when comparing two expressions that already have some type of equality operator.  I think the introduction of 2 different types of "or" will just confuse many programmers and make the coding more complicated since there would have to be some weird way to differentiate the two.

But now that I think about it, maybe I should make the regular "or" "and" "xor" the Boolean versions (like basic) and then add new commands for the bitwise operations.  I'm thinking to use the plot symbols for this.  The little dot will be "and", the little plus sign will be "or" and the little square will be "xor".
Title: Re: Features Wishlist
Post by: ztrumpet on February 10, 2010, 04:27:37 pm
But now that I think about it, maybe I should make the regular "or" "and" "xor" the Boolean versions (like basic) and then add new commands for the bitwise operations.  I'm thinking to use the plot symbols for this.  The little dot will be "and", the little plus sign will be "or" and the little square will be "xor".
I like this way, as I think all the basic programmers would wonder something like why dosn't "A or not(C" work right.  I really like booleans as " and " " or " and " xor ".  Also, are you using not( ?
Title: Re: Features Wishlist
Post by: Quigibo on February 11, 2010, 12:28:58 am
So I've redone a lot of the code.  You won't notice it, but it is much more organized on the inside now making it easier for me to add future features, and there's still a lot more that could be organized further.  Anyway, I've got a to-do list a mile high right now.  I still haven't actually made many of the mentioned corrections yet.  Most of these things are very minor, but very important like parsing order of operations, rewriting some code so that I will be able to handle pointers, the for loop, etc.

Although I could get to doing sprites right away, they're very easy to do, I feel I should finish these corrections first so that everything will just work better.  So either I will release the next version with sprites a little later than I anticipated, or I will release an intermediate version with some of the corrections and then the version after that will finish most of the corrections and include sprite handling.

btw, haven't made use of "not(" yet.  Its on my list.

Oh and I'd like some feedback on this: Should I continue to exclusively use multiblock "If" statements?  Or should I do what BASIC does and allow single or multiblock?  The disadvantage is that then you would have to add the token "Then" after every multiblock statement.  The compiled program will be the same either way, but what is more convenient, never needing the "Then", or sometimes not needing the "End"?
Title: Re: Features Wishlist
Post by: Builderboy on February 11, 2010, 12:32:05 am
Hmmm thats a good question.  I'm tempted to have it be done the way TiBasic has it, if only for readability.  Then again, i do see how usefully it is to not have the burden of a Then after each if (especially since it sometimes takes a whole line x.x)

Soooo i'm on the fence on this one, so I say keep it the way it is :P
Title: Re: Features Wishlist
Post by: Quigibo on February 11, 2010, 12:42:33 am
By the way, I am considering adding the ternary operator (http://en.wikipedia.org/wiki/Ternary_operation) to take the burden off of quick if statements.

The syntax will like this:

statement ?( expression1 , expression2 )

If the statement is true, the expression becomes expression1, if it is false, it becomes expression2.  So for instance:

A<B?(A,B)

Returns the minimum of A and B.  It is equivalent in BASIC like this:

:If A<B
:A
:Else
:B
:End

So quick things like

:If K=15
:A+1->A
:End

can be written like this:

K=15?(A+1->A,)
Title: Re: Features Wishlist
Post by: Eeems on February 11, 2010, 12:53:09 am
I like that!
I like the multiblock if statements, and then this works good for single statements.
Can't wait for more updates!
Title: Re: Features Wishlist
Post by: Builderboy on February 11, 2010, 01:04:17 am
Oh yeah! The Ternary operator! ^^ I remember that from Java and its lots of fun, especialy because its like an if statement that can be used in expressions :D
Title: Re: Features Wishlist
Post by: ztrumpet on February 11, 2010, 04:05:17 pm
Oh and I'd like some feedback on this: Should I continue to exclusively use multiblock "If" statements?  Or should I do what BASIC does and allow single or multiblock?  The disadvantage is that then you would have to add the token "Then" after every multiblock statement.  The compiled program will be the same either way, but what is more convenient, never needing the "Then", or sometimes not needing the "End"?
I'd keep it how it is now.  I don't like using all the ":Then"s that must be used in Ti Basic.

I've never heard of the Ternary operator.  It looks really cool, though. ;D
Side note: This is my 800th post. =)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 12, 2010, 05:03:16 am
Btw in TI-BASIC it's

If <Condition>
Then
<code>
Else
<code>
End

not

If <Condition>
<code>
Else
<code>
End

And you can also do

If <Condition>
Then
<code>
End

However I am lost now. I am a bit confused by that feature request, because it contains a lot of terms I never heard before, programming-wise. Are people implying that the ability to use multiple lines of codes inside If blocks will not be possible in Axe or the opposite?

it would suck to have to do like on the TI-81:

If A=1
<first code to run if condition is true>
If A=1
<2nd code to run if condition is true>
If A=1
<3rd code to run if condition is true>
If A=1
<4th code to run if condition is true>

or the opposite, having to do

If A=1
Then
D->B
End

instead of

If A=1
D->B
Title: Re: Features Wishlist
Post by: Quigibo on February 12, 2010, 06:18:15 am
Single line expressions can be executed by using the ternary.  In your example, you could either do it with blocks like this:

If A=1
D->B
End

or, because its a single expression, do this:

A=1?(D->B)

which is more compact than the regular TI basic.  I don't think I will use the "Then" token at all, maybe I'll re-code it do something else in the future.

Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 12, 2010, 09:07:00 am
aah ok thanks for clarifying.
Title: Re: Features Wishlist
Post by: ztrumpet on February 12, 2010, 04:49:03 pm
Sounds great!  I'm liking the more that I see of the ternary operator. ;D
Title: Re: Features Wishlist
Post by: Builderboy on February 13, 2010, 01:36:27 am
Indeed.   Mmmmm another question, are Boolean expressions going to be evaluated with short circuit evaluation?  For example withe if(A and B) if A is false, the program doesn't event bother to test B, and with if(A or B) if A is true you wouldn't need to evaluate B either.  I know java has this implemented, and was wondering how it is set up now.
Title: Re: Features Wishlist
Post by: Eeems on February 14, 2010, 12:53:14 pm
Hmm, I was wondering, could Celtic III style program control be added? So like, calling another program, getting a list of programs, creating a program, deleting a program, etc.
Also are you planning in adding string operators? Like sub() inString() and such?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 14, 2010, 03:00:27 pm
not sure, I think he only planned most pure-basic commands
Title: Re: Features Wishlist
Post by: Quigibo on February 14, 2010, 03:22:01 pm
Hmm, I was wondering, could Celtic III style program control be added? So like, calling another program, getting a list of programs, creating a program, deleting a program, etc.
Also are you planning in adding string operators? Like sub() inString() and such?

Its too soon to tell.  I'm not sure if I will have commands for program manipulation, but there will definitely be a way to create, save, and load application variables.

String handling is going to be very different since all strings are constant length.  It is very easy to get a substring if it ends at the normal ending, you can just do Disp Str1+A.  For anything else, you can write your own subroutine to copy part of the string to a buffer and then display the buffer instead of the string.  I can probably automate this but I would use a different command instead of sub().  Its still faster than the TI-BASIC sub() command.
Title: Re: Features Wishlist
Post by: Eeems on February 14, 2010, 04:41:06 pm
ah ok, hmm, interesting... Automated would be nice... Of course that isn't a priority right now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 14, 2010, 11:36:14 pm
can strings be used in a way that they can be tilemaps like some people do in TI-BASIC? See Illusiat 13 for an example. Illusiat 13 maps are  128 chars long each, btw, which fills the entire home screen
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 12:22:29 am
Data is data.  String = Picture = List = Hex.  It also equals executable code, but that part is my job  ;)

You can use strings however you like.  You would probably use decimal numbers or hex code for a tile map, but if its more convenient, then yes you can use a string as well.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 15, 2010, 12:37:32 am
Ah ok. What I like with strings is if we use ASCII maps (or dual layer like in Serenity/Elmgon, assuming we use Storepic/Recallpic too), is that each map rows are drawn almost instantly. Maybe with Axe, doing so with sprites won't make much of a speed difference anymore, though, since TI's text display routines are slow by nature compared to a third-party sprite routines :P
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 01:09:30 am
That's right, drawing 8x8 sprites is actually FASTER than drawing text.  Not only because the routine is faster, but also because it is drawn to the buffer instead of directly to the screen.  This is a paradigm you'll just have to get used to.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 15, 2010, 01:14:03 am
This is pretty much why now ASM programmers who make advanced games now make their own font displaying routines I guess
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 02:37:33 am
I had to do that in Pyoro for the scores.  The main reason was because regular font will not display correctly in the grayscale engine I made, and to make drawing as fast as possible in the least amount of memory, aligned 8x8 sprites are the way to go so I had to make my own number font to fit this size.  It was 7x8 instead of the standard 5x7.
Title: Re: Features Wishlist
Post by: ztrumpet on February 15, 2010, 09:44:23 am
That's pretty cool. (7x8) I had no iea text was so slow comparitivly.  Wow. ;D

By the way,very nice sig, Quigibo! :D
Title: Re: Features Wishlist
Post by: calc84maniac on February 15, 2010, 07:13:17 pm
I think a nice feature would be to expose the graph buffer as an array or pic or what have you. Could be useful for more complicated effects, if people want to write their own routines
Title: Re: Features Wishlist
Post by: Eeems on February 15, 2010, 09:28:17 pm
I was wondering...what about an arguement kind of thing, like with batch files, so you can call another program from it and pass it arguements, and then the arguements are pre defined variables tha can be used by the called program.
Code: [Select]
prgmAA arg1 arg2and then prgmAA could do something like this
Code: [Select]
output(0,0,%1
or we could just make the args the ans variable so that basic programs can pass stuff to it.

Edit: hmm I also had the thought while trying to port hunt to this (it's becoming my standard hello world :p) axe is still missing the basis of a good ai...random numbers within a certain amount...so how hard would it be to add a randInt() command?
Title: Re: Features Wishlist
Post by: Quigibo on February 16, 2010, 01:23:22 pm
randInt will come eventually.  The best way to get random numbers between A and B inclusive is like this: A+rand^(B-A+1) and this will basically be what that function will do.  So if you need a number 1-5, then simply do this: rand^5+1

Passing parameters is unnecessary complexity.  Saving into variables in the main program and then recalling them from the subprogram is about as efficient as it can get and is much simpler to understand for the programmer.  But like I said, I'm not sure if I will allow program modification tools.  You can embed an external program inside the compiled program and call it from there, but you will most likely not be able to call an arbitrary external program from the compiled code.  That would require error handling, something which I will add later, using the "Theta" variable.  0 means no error and all the other values represent different types of errors so you can check if some of the higher level commands executed properly.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 16, 2010, 02:13:39 pm
Just try to not change the syntax from TI-BASIC way too much, though. Just a suggestion, but this is what turned away people from most other BASIC-like languages on calc. They claimed themselves to be as easy as TI-BASIC+xLIB, but finally they weren't even that much easier, so people stuck with TI-BASIC.
Title: Re: Features Wishlist
Post by: Eeems on February 16, 2010, 04:24:07 pm
ah ok, well thanks that beats my method which was rather crude and ineffective.
Title: Re: Features Wishlist
Post by: Eeems on February 17, 2010, 07:28:47 pm
I was wondering if you could add in support for DCS headers and such? icons too?
Title: Re: Features Wishlist
Post by: Builderboy on February 17, 2010, 08:03:42 pm
Mmmm since it is not possible to compile archived programs, do you think you could remove them from the compile menu?  Just a little nag :P
Title: Re: Features Wishlist
Post by: Quigibo on February 18, 2010, 10:11:01 pm
It will be possible in a future version, so it I don't feel like adding something that will just be removed later.

A different idea though, is requiring all Axe programs to have a particular header in order to show up on the list.  That would remove the clutter of BASIC programs, would that be more or less annoying than the clutter?  What does everyone think about that?

Also, I am thinking in the far future to release a developer kit for asm programmers to add Axioms, which is a clever name for importable libraries to add new commands to extend the features even further.
Title: Re: Features Wishlist
Post by: Eeems on February 18, 2010, 10:37:39 pm
Hmm, the headers could work, and the Axioms idea. I had been thinking for a while about having an include statement so you can split your file into smaller more managable chunks for development.
How would these Axiom work? 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 19, 2010, 02:17:38 pm
I would like an header, it would make the list much less cluttered, especially that it's not in alphabetical order. In future versions I hope you also planned to let us choose the compiled program name :P
Title: Re: Features Wishlist
Post by: Quigibo on February 19, 2010, 02:31:02 pm
The include statement will just be inserting "prgmNAME" into the code somewhere.  I'm not sure how the Axioms will work, but they definitely won't be available on any time soon.

Just to give everyone a heads up, I am making a major change in the next version.  I ran into a problem.  When you display stuff, how does the compiler know in what format to display it?  How does it know if you want to display a string, a number (and if so, in what base?), or a character?  All three of those have a number as an argument, either as a pointer for strings, or a number for the ASCII value of the character and the plain old base 10 representation.  Therefore, I must add some way to tell how you want to display that number.

So in the future, you can display a string by omitting any additinal notation, as you have already been doing, but to tell it that that number is not a pointer to a string, you have to use >Dec at the end to tell the Disp or Output command that you intend to display that number as a base 10 representation.  Similarly, I might use >Frac to display the ASCII value of the number.

Sorry if this makes things a little inconvenient, but it will only reduce the size of the compiled program and add even more flexibility.  Its a very simple thing to fix to make older programs compatible with the next version.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 19, 2010, 02:59:56 pm
shouldn't be too much trouble to get used to I guess, if it can make it easier to compile and reduce size ^^
Title: Re: Features Wishlist
Post by: ztrumpet on February 19, 2010, 10:01:02 pm
Sounds great.  I like the header and Axioms ideas.  I also am fine with the changes to Disp.  Good luck! ;D
Title: Re: Features Wishlist
Post by: calc84maniac on February 22, 2010, 01:54:38 pm
I think we definitely need support for Else. Also, clipped sprites would be nice (I can help optimize if you want)
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 02:48:37 pm
Yeah, the sprites right now are not clipped.  I was thinking of adding that, but I was kind of in a hurry.  That would be great if you can optimize a routine for me!  I need it optimized for size, not speed though.

I'll get working on Else soon.  You can do this in the mean time:

If <statement>
<code to do if true>
Goto 1
End
<code to do if false>
Lbl 1
Delvar 1

The asm code generated from this will be identical to the code generated when using Else.
Title: Re: Features Wishlist
Post by: Galandros on February 22, 2010, 03:02:40 pm
True. But else is more readable.

The trouble coding the Else is worth for a cleaner source.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 03:28:22 pm
Does that cause a mem leak like in Basic?

I can't wait to try 0.0.5! ;D
 *ZTrumpet hurry's over to download...
Title: Re: Features Wishlist
Post by: Galandros on February 22, 2010, 03:47:21 pm
Does that cause a mem leak like in Basic?

I can't wait to try 0.0.5! ;D
 *ZTrumpet hurry's over to download...
No because it is compiled into assembly. There are leaks in assembly, though... But with different nature of the BASIC ones.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 04:17:03 pm
(Thanks Galandros!  ZTrumpet gives Galandros a cookie...)

I had an idea!
Can you make a "screen to buffer command", in which the buffer is updated with the current screen?
Also, where is the buffer? Is it the AppSaveScreen? (That's the only place I can think of now, but I've probably only got a 25% chance of being right...)
Thanks! ;D
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 06:11:06 pm
You can still leak in Axe Parser, but only by calling a subroutine that keeps calling itself in a non-terminating infinite loop.  I mean, you can have subroutines call themselves if you want to have a recursive subroutine, but it has to actually exit somewhere.  All the other commands are leak-proof unlike basic.

The next update will definitely have Else, but I'm not sure if it will have the Ternary operator since I have so many other things to do.

Btw, the buffer is stored in plotSScreen.  What would be the use of copying the screen to the buffer?  All of the drawing commands draw to the buffer anyway.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 06:34:27 pm
You can still leak in Axe Parser, but only by calling a subroutine that keeps calling itself in a non-terminating infinite loop.  I mean, you can have subroutines call themselves if you want to have a recursive subroutine, but it has to actually exit somewhere.  All the other commands are leak-proof unlike basic.
Great! :D
Btw, the buffer is stored in plotSScreen.
Thanks!
What would be the use of copying the screen to the buffer?  All of the drawing commands draw to the buffer anyway.
I was thinking that if you had a basic program that calls an Axe program, then somehow you'd want to be able to put the screen on the buffer.  This is to allow interactions with the screen with an Axe program as a subroutine.  Does this seem like a good idea/reason?  Thanks! ;D
Title: Re: Features Wishlist
Post by: Eeems on February 22, 2010, 06:37:30 pm
I was wondering, how hard would it be to let people name their labels with more then two letters?
hmm, it would be nice to have a secondary buffer that you could store too, but that would be easy to do with pictures...
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 08:52:41 pm
I wish I could name labels and strings and pictures of arbitrary length!  The problem is that the calculator has EXTREMELY limited memory.  Each individual label currently takes up 5 bytes.  That is 2 bytes for the location the label is pointing to, 1 for the type, and 2 for the letters.  I need these to be in a continuous array in ram.  The largest free ram is 768 bytes and so rounded to 750, that's exactly 150 Labels.  If each label was 7 letters, you would only be allowed 75 labels.  Unless I can somehow figure out how to read and write data directly to ROM, there really just isn't enough memory to keep track of long names.
Title: Re: Features Wishlist
Post by: Builderboy on February 22, 2010, 08:56:05 pm
Well I haven't worked with Axe or Assembly very much (not Assembly much at all) but is 150 labels/subs really very necessary?  Maybe its just my BASIC attitude towards labels but it would seem to me that you wouldn't need to use them that much.  
Title: Re: Features Wishlist
Post by: Eeems on February 22, 2010, 08:59:37 pm
Ah ok :/ well I was just thinking...you could set it up so that if it jumps to a label or calls it, instead of having labels stored you can parse the location of the label instead into the goto, kind of like assembly is done.
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 09:20:26 pm
Well I haven't worked with Axe or Assembly very much (not Assembly much at all) but is 150 labels/subs really very necessary?  Maybe its just my BASIC attitude towards labels but it would seem to me that you wouldn't need to use them that much. 
Its not that labels in particular that worry me, its the naming of strings, sprites, pictures, etc. that you often need to name a decent amount.
Title: Re: Features Wishlist
Post by: Builderboy on February 23, 2010, 10:28:53 am
Ah i see, so the same memory is used for variable names as well?  I can see where the problem might arise.
Title: Re: Features Wishlist
Post by: ztrumpet on February 23, 2010, 09:53:28 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
This is amazing!  I never realized i was in basic.  When I put it on my calc today, it errored because it is in Basic, and basic is not ran "Asm(prgmAHEX". ;D
Excellent job on this Quigibo! :D
Title: Re: Features Wishlist
Post by: Builderboy on February 23, 2010, 10:01:53 pm
The run indicator tipped me off ;) That is a good job though, good work :)
Title: Re: Features Wishlist
Post by: calc84maniac on February 26, 2010, 03:51:53 pm
The Asm( code parser needs a way to insert pointers to variables, methinks.
Title: Re: Features Wishlist
Post by: Quigibo on February 26, 2010, 04:01:17 pm
Sure.  Lets say you do this:

<asm code 1>
ld hl,(var_A)
<asm code 2>
ld (var_A),hl
<asm code 3>

You can do:
Asm(asm code 1):A
Asm(asm code 2):->A
Asm(asm code 3)

More generally, the variables are stored in saveSScreen in alphabetical order and then the random seed immediately follows.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 26, 2010, 04:56:18 pm
btw I do hope Asm( in axe will not have the slow loading that hinders the BASIC version of it x.x. In BASIC, the lower your RAM, the longer it takes for an ASM program to even startup at all with Asm( and it's even worse with many files on your calc. Again, thought, maybe you won't have this problem since the ASM code would most likely be included inside the Axe program, not as an external program, requiring searching the entire VAT for it (which is what slows down Asm( that much in BASIC, I think). An example of how slow Asm( can be is The Reign Of Legends 3 map loading. Each Asm(prgmCODEX instructions takes about 0.25 seconds to execute. Not too bad for a one-time execution, but it's another story when you are using it in a loop.
Title: Re: Features Wishlist
Post by: Builderboy on February 26, 2010, 07:57:18 pm
I believe the Asm() hex codes are added right into the program so there is no speed loss at all.

BTW: Did you find the weird error problem that was popping up?
Title: Re: Features Wishlist
Post by: Quigibo on February 27, 2010, 03:05:02 am
Unfortunately no, I haven't been able to spot a pattern in the errors yet, but I haven't done a rigorous debugging either.  I'll do that tomorrow probably.
Title: Re: Features Wishlist
Post by: Silver Shadow on February 28, 2010, 01:38:02 am
Could you possibly implement lists and/or matrices? It's the only way I've got to do my game engine for Crystal Defenders...
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 01:44:25 am
That's already been done.  It will be in the next release coming very soon.  You have to manually store data though since I haven't added automated data structure support yet.  I'll explain what I mean by that when I release it, but basically you have to keep track of the size of the array, dimensions of the array, and maximum size of the array yourself.
Title: Re: Features Wishlist
Post by: Raylin on February 28, 2010, 09:50:10 am
If time allows, the greatest feature you could add to Axe:

RICKROLLS MID-PROGRAM!





... Kidding.
I would personally like to see greyscale support and the speed of said function.
Perhaps an entire Pic (96x64) to Hex program...?
It would make those title screens easier on the calc.
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 12:37:55 pm
Yeah, you won't even need a title screen to hex program because when do I add splash screen support, it will just use the calc's pictures and copy the ones you choose into the program.  If you need more than 10 pictures you can always write them in Hex if you're really desperate, but I think there are some Pic-to-AppVar programs out there and I might support AppVars where you normally enter a picture.  Grayscale will take a while but I can't think of a good syntax for it yet...
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2010, 12:44:31 pm
When you say copy, you mean at compilation and not during running right?  It would be a tad bit silly if Asm programs were dependent on Basic Pic variables for execution ;D

I dont pretend to know how greyscale works, so this might be the complete wrong approach, but could it be as simple as using PxlOn(X,Y,V) where V is a value from 0 - 2 representing color?  Would it use automatic interrupts or some sort of manual graph buffer copying?
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 04:15:16 pm
Copy means copy during compile time of course :)

The way grayscale will work will be that all drawing routines actually draw to both buffers at the same time.  When you use DispGraph in grayscale mode, or maybe it will just be a different command, It displays the first buffer mixed with half of the second buffer.  Then the next time its called, it automatically switches to using the other half of the second buffer.  It will not automatically be gray.  You have to constantly redraw the screen in the main loop.

You can automate that when I add interrupt support, but I'm nowhere near ready for that now.
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2010, 04:42:24 pm
Thats genius!  :O
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 28, 2010, 11:47:43 pm
I am a bit confused, basically does it means it will quickly swaps back and forth between both buffers? I believe this is how TI-86 grayscale works, except on these one of the buffer is displayed for a shorter amount of time since they have 4 levels of gray. I think 3 levels should be enough for Axe (like in Pyoro, F-Zero and Reuben Quest)
Title: Re: Features Wishlist
Post by: calc84maniac on February 28, 2010, 11:56:55 pm
I think a nice feature would be something like the Switch statement in C, for when you have a lot of different values to check against (like colliding with a tilemap or handling various different types of objects). It should generate a jump table, and probably be forced to values from 0 to N (if you want A to A+N, just subtract A from the value you are switching).
Title: Re: Features Wishlist
Post by: Eeems on March 01, 2010, 09:42:56 am
Yeah a switch statement would be nice. Also it probably shouldn't be that hard to make.
Title: Re: Features Wishlist
Post by: Galandros on March 01, 2010, 09:46:29 am
I think a nice feature would be something like the Switch statement in C, for when you have a lot of different values to check against (like colliding with a tilemap or handling various different types of objects). It should generate a jump table, and probably be forced to values from 0 to N (if you want A to A+N, just subtract A from the value you are switching).
A vector table would save bytes if it is large enough. Speed is not substantially different.
Title: Re: Features Wishlist
Post by: ztrumpet on March 01, 2010, 05:39:17 pm
I like your plans for greyscale!  It sounds really cool! :D

Yeah a switch statement would be nice. Also it probably shouldn't be that hard to make.
I think Switch would be very nice indeed! ;D
Title: Re: Features Wishlist
Post by: Eeems on March 01, 2010, 10:35:45 pm
Adding in compoliler commands like .IF .ELSE .END etc that will allow for compiling based on which calc you are on and such.
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:29:27 pm
I'd reeealy like to see signed comparisons and operations.  It would make a lot of things a whole lot easier.  Also, would it be hard to add the 'step' optional argument to the For loop?  Its killing me that i cant go backwards XD
Title: Re: Features Wishlist
Post by: trevmeister66 on March 01, 2010, 11:32:04 pm
I don't know if it's been talked about, but 16x16 sprites possibly?
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:35:44 pm
I think its been mentioned, and its been said that you can just write your own routines to display 16x16 fairly easily in Axe.  And that if he ever does support it, it will be late in development.  For now you will have to settle for 4 8x8's :P
Title: Re: Features Wishlist
Post by: calc84maniac on March 01, 2010, 11:42:59 pm
I think NES and Gameboy display hardware had this limit too. Think retro! :D
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:49:55 pm
:P I know what there are no negative numbers in the calc, and I know of ways to do the correct math.  Its just weird that -(-D*2) is NOT equal to D*2, and it would be nice if it did ;)

Title: Re: Features Wishlist
Post by: trevmeister66 on March 01, 2010, 11:58:32 pm
I think its been mentioned, and its been said that you can just write your own routines to display 16x16 fairly easily in Axe.  And that if he ever does support it, it will be late in development.  For now you will have to settle for 4 8x8's :P
Gotcha. I figured that is what was going to be.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 01, 2010, 11:58:57 pm
Given how incredibly fast many alien ships moves around in the space invader Axe screenshot, I think having to use 4 8x8 sprites will not drain speed too much
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 01:04:13 pm
By the way, I added a 15MHz mode in the next version and its incredible!  Why didn't I know about this when making pyoro?  I could've had 8 level grayscale or something!  But the downside is that if you use this mode, your games will run 3 times slower with an 83+ than with the other calculators so compatibility becomes an issue.

Maybe I should just make all math signed... it would only cut the maximum number limit in half from 65535 to 32767 which is still probably big enough for most applications.  I think it will get confusing to have 2 sets of operators, especially for those not familiar with signed/unsigned math.  It would only affect multiplication, division, modulus, and inequalities I think.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 02, 2010, 02:10:11 pm
15 MHz would be cool, altough yeah it might cause incompatiblities issues. I think for simpler games I would probably stick to 6 MHz. Plus 8 level grayscale must take a lot of memory x.x

As for signed, would it be better to have unsigned integers? 32767 might be a bit small. For high scores, though, the person can simply add more zeros at the end, but if someone decided to make some small RPG, it might become an issue for gold pieces, especially if he's porting an older BASIC RPG to Axe.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 02, 2010, 03:44:57 pm
You absolutely need to add 15 MHz mode!
Compatibility isn't really a problem, if somebody really needs to make it work on the 8 MHz one,he could have 2 versions or a frame skip option...
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 04:26:23 pm
that could work
you could use the compiler commands I suggested for that so that it will compile the correct version on calc :)
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 04:38:29 pm
By the way, I added a 15MHz mode in the next version and its incredible!  Why didn't I know about this when making pyoro?  I could've had 8 level grayscale or something!  But the downside is that if you use this mode, your games will run 3 times slower with an 83+ than with the other calculators so compatibility becomes an issue.
Can we chose to have 6mhz if we want?  This would allow games to run the same, when speed is not an issue.

Could we do something like
.6MHZ
and
.15MHZ
to control the speed at the beginning?
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 04:52:31 pm
I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 04:53:52 pm
I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.
Awesome!
I can't wait for 0.0.7... ;D
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 05:20:14 pm
ah cool
well this does work, but it doesn't allow for what I had in mind. I was thinking something like this:
Code: [Select]
!If full
-code1-
Else
-code2-
End
would compile to -code1- on a 15MHZ calc and -code2- on a 6MHZ calc. This would allow for using different versions of code to allow for speed differences.
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 05:26:33 pm
I think the above way you just wrote is better.  Having a different program for each type of calculator is more annoying in my opinion than a single, insignificantly larger program that works for every calculator.  I might add a command that returns the exact type of calculator and operating system version, not just 15MHz support.
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 06:32:22 pm
I think the above way you just wrote is better.  Having a different program for each type of calculator is more annoying in my opinion than a single, insignificantly larger program that works for every calculator.  I might add a command that returns the exact type of calculator and operating system version, not just 15MHz support.
Cool.  I think there should be compiler directives.  Maybe something like a "CIf" statement:
CIf OS=2.53
code here compiled if OS=2.53
Else
other code here compiled if OS!=2.53
End

Would this work?
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 06:39:37 pm
That's kind of what I had in mind. We could use .If .Else .End and such fir that. How about also adding variables that the compiler uses? Like .VER would return te version of the device that it was compiled on? That would make some more nice little modifications to code possible. Also a Date one would work too so it would tell you what date it was compiled on (of course that would be 15MHZ only). 
Title: Re: Features Wishlist
Post by: Builderboy on March 02, 2010, 07:16:31 pm
Could there be a command to swap the buffers instead of just copying them?  That way one wouldnt have to be destroyed in the process.
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 07:20:04 pm
I was also wondering if you could add a third back-buffer, or have a buffer in the program (so like have a blank splash screen in the program that we can edit/read :D, although you would have to put checks in place so we don't accidentally corrupt the program with overflow from it)
Title: Re: Features Wishlist
Post by: calc84maniac on March 02, 2010, 08:12:48 pm
Hmm yeah, maybe instead of having plotSScreen always be the draw area, add a command to set a different buffer to draw to. You would only need to change immediate loads of plotSScreen to loads from a variable in memory. Heck, maybe you could use Theta for this purpose, and have it be accessible like a normal variable.
Title: Re: Features Wishlist
Post by: Builderboy on March 02, 2010, 10:11:40 pm
That would be very useful as well.  This made me thinking, since the LCD isn't memory mapped (right? D:) swapping buffers would be as simple as changing a pointer in the safeCopy routine right?  Or do I not know what I am talking about? ;D
Title: Re: Features Wishlist
Post by: calc84maniac on March 02, 2010, 10:26:17 pm
That would be very useful as well.  This made me thinking, since the LCD isn't memory mapped (right? D:) swapping buffers would be as simple as changing a pointer in the safeCopy routine right?  Or do I not know what I am talking about? ;D
You are quite correct. And it should only be 6 extra clock cycles per call when using a variable instead of a constant, which is not enough to make a difference.
Title: Re: Features Wishlist
Post by: Quigibo on March 03, 2010, 01:55:38 pm
That's actually a really good idea to use some variables as variable pointers that are looked up by some routines.  Maybe I will use the "u" "v" "w" variables for this since I'll probably need more than 1 of them.  The only problem with this is that the variables have to be initialized before the program starts.  Otherwise, it will just be something random.  The parser could do it automatically, but then its just adding extra bytes in case you decide to change it again to anything but the default.  It would be really annoying to start every program with L6->u to do any drawing and it might not make sense for beginners.

I could always make the variable location part of the self modifying code so it already starts initialized without using extra memory, but then that means it can never compile as an app.  Although I'm still not sure how feasible it is to compile apps on-calc.  Have other programmers been able to do it?

All those precompile headers use variables that have to be set somewhere.  That means I would also need preprossesor variables which would be very difficult to add and I'm already running out of memory.  There is no reason that the same program should compile differently on different calculators since only the executable would be distributed ideally.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 03, 2010, 02:33:44 pm
Well, I've never seen anyone make apps on-calc. That could be tricky...
Try asking Brandon, he's an expert in Flash unlocking.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 03, 2010, 02:57:48 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
Title: Re: Features Wishlist
Post by: ztrumpet on March 03, 2010, 08:43:00 pm
I like the Safe_Copy Pointer idea.  :)
Great idea!

Could you automatically initialize the pointer to the most common value of it, as it would be only be a little bigger and less prone to crashes?
Title: Re: Features Wishlist
Post by: Quigibo on March 03, 2010, 10:26:48 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 03, 2010, 10:37:43 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.
Fair enough. Do what you can, and I will gladly wait :)
Title: Re: Features Wishlist
Post by: Raylin on March 04, 2010, 02:32:54 pm
I second the on-calc APP compiling feature.
It is full of win.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2010, 04:13:33 pm
would it be even possible at all, though? I don't even think BrandonW did it and he's like nearly the best assembly programmer out there. It has something to do with app signing I think. Even signing apps on a computer is a major hassle sometimes. Remember the trouble Iambian had with bad signatures, preventing many people from sending Celtic III to their calc
Title: Re: Features Wishlist
Post by: Quigibo on March 04, 2010, 04:39:01 pm
Well, I'll wait on that then.

Anyway, I need to propose some safety features and I'd like some feedback.  Here is the idea.  If you select a "safety mode" in the options, the following will occur: All data in ram is archived and an application variable is created to keep track of what it archived (The appvar is also archived).  A dummy variable is also created and is kept in RAM.  Next, after the program is compiled, it is executed within axe parser itself rather than coming back to the home screen.  Once the program finishes, the ram is automatically cleared on the calculator so any corrupted data gets restored to the default.  Next, the appvar gets unarchived and unarchives the variables on its list.  So when the program quits, everything is back to normal.

Now, if the program crashed, and you need to pull the batteries, then the dummy variable gets deleted.  That means that the next time you run axe, it will notify you that you have recovered from a crash and automatically unarchive the programs from the save list to return the calculator back to normal.

This seems like the perfect system to prevent crashes, but its a little too perfect.  What I mean, is that if you start getting used to this, then if it corrupts the memory when safe mode is off, it will be very hard to find where the error is since the error would never be detectable in safety mode.

You might ask "Isn't it possible for axe to automatically detect when memory is corrupted?"  but the problem is that I would need a copy of the entire original RAM to compare it before and after the program is run and that really isn't going to be possible.  And even if it were possible, many assembly programmers often intentionally change non-safe areas of RAM to set flags, alter external variables, run self modifying code, etc.

I'm still going to add this mode anyway, but does anyone else have any other ideas about how to improve safety?
Title: Re: Features Wishlist
Post by: ztrumpet on March 04, 2010, 05:22:26 pm
It sounds really good!

The only idea I have requires hooks, and it's not even that good of an idea.  :)
Wait, never mind:  You're RAM is cleared; There are no hooks... :D
Title: Re: Features Wishlist
Post by: Raylin on March 04, 2010, 07:13:32 pm
I like the safety mode idea.

OMG.
I can has DEBUG mode!? :D

It would be nice if you could edit programs inside of Axe Parser instead of jumping back to Home and reprogramming and recompiling...
Title: Re: Features Wishlist
Post by: Eeems on March 04, 2010, 07:39:39 pm
well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...
Title: Re: Features Wishlist
Post by: calc84maniac on March 04, 2010, 07:47:15 pm
well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...
Actually, I'd think debugging would be pretty darn hard to pull off. Unless, of course, you might be able to build executables that allow debugging, but have larger code size?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2010, 10:06:25 pm
for safety mode, I hope the plan is gonna be to allow people to compile in unsafe mode, though. I personally would like to provide a version of my stuff that has no error checks so it runs faster. I wouldn't mind slower speed for debugging, though.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 05, 2010, 01:48:12 am
How about a sandbox mode where your RAM will be backed up, but won't be cleared after you run the prog, so that if it corrupts the memory, the user will notice it?
Title: Re: Features Wishlist
Post by: Quigibo on March 05, 2010, 11:25:31 am
Yeah that's essentially what I'm doing.  I have saftey mode, sandbox mode, and normal mode.

"Sandbox" is actually what I called safety before.

"Saftey" now means that all ram is archived, but ram is not cleared.  Programs remain archived after execution and it returns to the homescreen (so you will notice glitches but everything is still archived).  You'll have to manually unarchive everything you want to put back in RAM yourself (not recommended until a ram clear is performed).

"Normal" is obviously what has been done to date.
Title: Re: Features Wishlist
Post by: Galandros on March 05, 2010, 02:08:34 pm
Could you had any arbitrary way to time things? It doesn't need to accurately time seconds or miliseconds.
Just accurate enough to know if it is faster. (even if you need loops)
Title: Re: Features Wishlist
Post by: Quigibo on March 05, 2010, 02:32:15 pm
You can do that with interrupts, but I haven't implemented that yet.  And even with interrupts, a few routines like "DispGraph" disable interrupts for the duration of the command during execution.

In the mean time, you can run the codes you want to test in big for loops so they take a measurable amount of time; maybe enough looping to last 5-10 seconds.  That way if there is any difference, you can actually measure it with a stopwatch or clock.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 05, 2010, 02:38:42 pm
Yeah that's generally what I do with TI-BASIC. I move my character around, for example, or scroll down an entire menu, stop the chronometer, then retry with modified code, then compare. Not too accurate but still does the job.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 08, 2010, 02:06:02 pm
Question:

Do you think you will add the following in the future?

1) SMC or saving to external var/appvar/prog - useful for saving highscores and game progress

2) Letting us choose whatever name we want for the compiled program instead of just "LOL".
Title: Re: Features Wishlist
Post by: ztrumpet on March 08, 2010, 03:51:25 pm
He is planning both of these things.  I'm pretty sure this first will somehow be accomplished with the GetCalc( command. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 08, 2010, 11:14:47 pm
Yeah I was more curious about if it was coming in the few next releases, though, or if it was more near the end.

If it is near the end, I will probably just rely on password systems for saving (like Metroid for the NES and Demon Crest for the SNES), altough that might be a bit hard to make in a way that it's hard to crack
Title: Re: Features Wishlist
Post by: Quigibo on March 09, 2010, 11:56:32 am
VAT manipulation will come when I finish the user interface and safety stuff so I'd say in the middle, not the end.

Program naming I'm working on right now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 09, 2010, 02:19:25 pm
Sounds cool ^^

I assume the safety stuff is the option to compile a program with the developer mode with more error checks during execution, right?
Title: Re: Features Wishlist
Post by: calc84maniac on March 10, 2010, 10:15:08 pm
Another good feature would be a Fill( function, to quickly fill memory with a value. This could be especially useful in graphics where this must be done every frame, like if you want to clear part of the screen (such as after a Vertical command)
Title: Re: Features Wishlist
Post by: Builderboy on March 10, 2010, 10:26:09 pm
Couldn't you easily write that yourself though?  

PS: Yay on the update ^^
Title: Re: Features Wishlist
Post by: calc84maniac on March 10, 2010, 10:31:00 pm
Couldn't you easily write that yourself though? 

PS: Yay on the update ^^
Yes, but it would be way slower and more bloated. It would translate much more easily to a few ASM opcodes.
Title: Re: Features Wishlist
Post by: Eeems on March 11, 2010, 12:00:29 am
Fill() would be nice, and line() soon as well. If only you had uploaded sooner today when I could have sent it to my calc x.x now I'm stuck with the slow version for who knows how long x.x
Title: Re: Features Wishlist
Post by: Builderboy on March 11, 2010, 12:07:49 am
Yes, but it would be way slower and more bloated. It would translate much more easily to a few ASM opcodes.
As i see.  Well in that case get right on it Quigibo! :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 01:46:17 am
I fail at understanding the concept of fill x.x

Do you mean like in Paint when filling an area with a color or just like a rectangle routine?

rectangle routines would be cool
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 08:46:54 am
I fail at understanding the concept of fill x.x

Do you mean like in Paint when filling an area with a color or just like a rectangle routine?

rectangle routines would be cool
I mean like a pure data fill, which would work a lot like the TI-Basic version (except with any data area and any length)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 01:35:46 pm
Aaah ok, so like lists?
Title: Re: Features Wishlist
Post by: Quigibo on March 11, 2010, 03:41:33 pm
That's actually really freaky that you mentioned Fill() because I just so happened to have written that command last night  :o

I have working now the Fill() command to fill up data blocks with a particular byte, plus a copy command to copy a number of bytes from a source to a destination and an exchange command to exchange bytes between two ram locations.  The closest thing I could find to copy() was conj() and exchange is expr().  You'll see those in the next version, it should make data manipulation a lot easier, faster, and smaller, but still not as much as when I get arrays working.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 04:25:33 pm
I'm just gonna throw in my requests:
*Full picture drawing
*Access to user variables (programs and appdata)
*Port access
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 04:34:38 pm
*Port access
That can be done with inline ASM. Most people who would know how (or even need) to use ports will probably know ASM.
Title: Re: Features Wishlist
Post by: Builderboy on March 11, 2010, 05:25:13 pm
What would you want with Port access anyway? O.o Maybe linking?  But that i think is going to be supported in (much) later versions so i don't know.
Title: Re: Features Wishlist
Post by: ztrumpet on March 11, 2010, 06:54:57 pm
I like the conj(, expr(, and Fill( commands!  I know I'll end up using them. ;D

Yay, 0.1.1! ;)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 07:19:43 pm
Linking is something that you should be able to use in-line asm for, I agree.

Oh, and interrupts.  You should be able to stick one of your subroutines onto the interrupt.
Title: Re: Features Wishlist
Post by: Raylin on March 11, 2010, 07:37:35 pm
Did someone cover 'being able to use hexadecimal in normal calculations' using >Rect or something...?
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 07:42:59 pm
Did someone cover 'being able to use hexadecimal in normal calculations' using >Rect or something...?
I would really, really like being able to use hex.
Title: Re: Features Wishlist
Post by: Eeems on March 11, 2010, 07:45:55 pm
I would like that too...I would also like a way to store large amounts of data to pointers in none hex, so like a list would.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 07:46:21 pm
I think I may have figured out a way to draw a whole picture to the screen, and that's just something like this:

'Code goes here to move PC into L6
DispGraph
Lbl PC
[000AFF...] 'Pic data
Title: Re: Features Wishlist
Post by: Quigibo on March 11, 2010, 08:01:57 pm
One way to do that is conj(Pic1,L6,768) in the next version if Pic1 contains the hex code of the picture.  I'm still not 100% sure how regular picture support will work in the future though.

All of the other commands suggested so far I plan to add eventually.  School forces me to work slow.  Syntax changes take the longest to add while new commands take less than an hour usually.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 11:44:06 pm
That's actually really freaky that you mentioned Fill() because I just so happened to have written that command last night  :o

I have working now the Fill() command to fill up data blocks with a particular byte, plus a copy command to copy a number of bytes from a source to a destination and an exchange command to exchange bytes between two ram locations.  The closest thing I could find to copy() was conj() and exchange is expr().  You'll see those in the next version, it should make data manipulation a lot easier, faster, and smaller, but still not as much as when I get arrays working.
Maybe he lives very close to you and is stalking you in secret? :O

Also make sure to not have too much syntax changes in case it would break old Axe programs. So far, every example I tried seemed to work fine in latest versions, though.

As for entire pics, it would be cool to have that as feature, altough for now, since each sprite just takes 8 byte, I would tolerate using 96 sprites to display a pic, for example, plus then, if my pic is not even full screen (a logo, for example) I don,t need to use that many sprites.
Title: Re: Features Wishlist
Post by: Builderboy on March 12, 2010, 12:18:37 am
These new commands sounds great!  Could allow for some really nice effects and animations <(^.^<)

Mmmm out of curiosity are you planning String manipulation soon?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 01:24:31 am
Someone will have to show me examples using them in action once they are avaliable, because I am sorry but I seriously don't get it, even after explanation x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 09:35:47 pm
Suggestion:

-The ability to store directly to the back buffer, without having to go through storing the lcd to buffer first. It migth be very useful if we want to store to the back buffer but not want to lose our main buffer content
Title: Re: Features Wishlist
Post by: calc84maniac on March 12, 2010, 10:03:55 pm
Another neat feature would be one that draws the main buffer to the LCD and simultaneously copies the back buffer to the main buffer. So basically, Dispgraph and Recallpic at the same time. It would be a great way to use the wasted time waiting for the LCD.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 10:10:52 pm
I just remembered one more:

The ability to display the graph buffer using different logics other than OVERWRITE, like XOR.

Imagine, for example, you have a game with scrolling, but want to display a HUD. Everytime you scroll, you are forced to redraw the entire HUD, because it scrolls as well. In xLIB xLIB Revolution, the HUD is XORed right before scrolling, then XOR'ed again after scrolling (and other stuff) is done.
Title: Re: Features Wishlist
Post by: ztrumpet on March 12, 2010, 10:36:21 pm
I also think we need the And, Or, Xor, and Over-write commands when dealing with pictures. :)
Title: Re: Features Wishlist
Post by: trevmeister66 on March 12, 2010, 10:38:37 pm
I also think we need the And, Or, Xor, and Over-write commands when dealing with pictures. :)
+1

I do believe he will add that in eventually though.
Title: Re: Features Wishlist
Post by: Radical Pi on March 12, 2010, 10:39:04 pm
I second the last five posts :)
Title: Re: Features Wishlist
Post by: _player1537 on March 13, 2010, 02:26:41 am
I second the last 6 posts :P
Title: Re: Features Wishlist
Post by: Raylin on March 13, 2010, 09:15:38 am
[xLib TextMode Commands]
Inverted Text and the like.

[GRAYSCALE!]
Reiteration of what has already been said.

[Omnicalc Custom Font Support]
Think about it! :D :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 13, 2010, 11:04:06 am
I doN't think he is planning to add features involving support of external ASM lib for BASIC programmers such as Omnicalc, xLIB, Symbolic and Celtic, though, meaning most likely no Omnicalc fonts. Plus since text is much slower in ASM than graphics, partially due to TI's slow txt routines, it would nearly defeat the point of using Axe. Maybe a custom font routine reading from Omnicalc font files could be done, though, using a custom sprite routine.
Title: Re: Features Wishlist
Post by: Galandros on March 14, 2010, 10:47:56 am
Being away brings fresh new ideas!

If you have indirection support why not ports access? This can mean sound, linking, etc.. Just be careful to not mess with protected ports. See WikiTI for details on protected ports.
Title: Re: Features Wishlist
Post by: ztrumpet on March 14, 2010, 11:32:11 am
A ToneOut(length,frequency) command sounds awesome! :D
Title: Re: Features Wishlist
Post by: Raylin on March 14, 2010, 11:40:34 am
I CAN HAS EASTER EGGS? :P
Title: Re: Features Wishlist
Post by: Silver Shadow on March 14, 2010, 01:21:14 pm
Ion header support, maybe?
Title: Re: Features Wishlist
Post by: Radical Pi on March 14, 2010, 02:31:34 pm
I CAN HAS EASTER EGGS? :P
How exactly could easter eggs work for something like this? Pressing some random key sequence in the app lets you play a game of Tetris?
Title: Re: Features Wishlist
Post by: _player1537 on March 14, 2010, 02:41:29 pm
I CAN HAS EASTER EGGS? :P
How exactly could easter eggs work for something like this? Pressing some random key sequence in the app lets you play a game of Tetris?

I like that idea  :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 05:57:39 pm
i dont think space should be wasted by unnecessary features. It would suck if when finished this app became 4 pages large instead of maybe 3 just because an easter egg was added

Also I think he's planning Ion/Mirage support in later versions. I would prefer Mirage, though, because with Ion you are limited in terms of RAM. Remember when installing it you lose like 2 KB of RAM, which doesn't happen in MirageOs
Title: Re: Features Wishlist
Post by: Raylin on March 14, 2010, 06:47:15 pm
So...

Rotate(PIC, angle, velocity, direction).
Title: Re: Features Wishlist
Post by: Quigibo on March 14, 2010, 06:53:42 pm
I am definitely adding 90 degree sprite rotation as well as horizontal and vertical flipping.  I'm still looking for some intuitive commands for this though.  To use it, you will want to copy a sprite to free ram and then flip it and draw it from there, otherwise, you might loose track of what direction it has been flipped so far.
Title: Re: Features Wishlist
Post by: ztrumpet on March 14, 2010, 08:26:29 pm
Also I think he's planning Ion/Mirage support in later versions. I would prefer Mirage, though, because with Ion you are limited in terms of RAM. Remember when installing it you lose like 2 KB of RAM, which doesn't happen in MirageOs
Since Mirage shows Ion programs, you can use a ion header to make programs show up in both Mirage and Ion. :)


Can we have a backbuffer to screen command?  Please? ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 08:28:39 pm
Can Ion programs run fine in Mirage if Ion is not installed? If so, I guess that could work, too, altough I think I recall certain Ion programs crashed in MirageOs or vice-versa x.x
Title: Re: Features Wishlist
Post by: trevmeister66 on March 14, 2010, 08:33:47 pm
Can Ion programs run fine in Mirage if Ion is not installed? If so, I guess that could work, too, altough I think I recall certain Ion programs crashed in MirageOs or vice-versa x.x
Yeah, from what I've seen, they work fine in Mirage. I personally haven't ran across any Ion games crashing, but I'm sure it's possible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 09:00:13 pm
The Core Of Light is one

Also there are Ion games that will crash in Ion and works fine in Mirage, for some reasons. Final Fantasy v1.198 is one. ARPGCS also tend to crash a lot in Ion, especially any Ion version other than 1.4.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 15, 2010, 11:34:10 pm
Not really a feature suggestion, but I would suggest maybe not make upcoming commands too hard to understand. I mean, I noticed as the project advances, most stuff in your posts are explained in a lower and lower level way that practically requires us to learn ASM to understand how it works. It might be good to provide both very well explained documentation of these new commands (in particular, the ones added in v0.1.2), and not just in text, but also maybe examples with screenshots or 8xp files, even if they are not games and just useless programs, and maybe also explain the commands in TI-BASIC equivalent. And not change too much of the syntax for the old essential commands. I kinda like how Axe currently barely requires modification over pure BASIC programs to be compiled

EDIT:

Feature suggestion:

Switch back to old List(Element) syntax instead of the new {} thing, like L1(2)
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 01:11:08 am
I second the new List handling, as it could make the source a lot more readable, like Basic.  Although I understand that it is still in development and things like readability are in the works right now as features are being added :)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 08:21:34 am
I just had an idea:
For saving and loading games and such, you should try program write-back.  Make it so that you can add a token in your code, and it will enable write-back, saving your labels.
Title: Re: Features Wishlist
Post by: Quigibo on March 16, 2010, 11:19:13 am
I cannot use the BASIC format for list handling.  L1(X) is ambiguous in BASIC since you can't tell if you are multiplying by X or finding the Xth element.  This always bugged me.  Similarly, in Axe, it can't tell if you are starting a new expression or finding the element of a list.

Don't forget, axe interprets a command written like this:

:Disp {A*2+L1}

As this:


:A
:*2
:+L1
:{}
:Disp


Both of these compile exactly the same way byte for byte in the executable.  So you can see why the parenthesis notation would be too ambiguous.

But YES, I am definitely going to add a byte data structure so you can define values in base 10 integers instead of just hex and strings.  It will be the same syntax as BASIC lists, but I think I will need to use something other than the curly brackets.
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 12:38:27 pm
Mmmm thats an interesting insight to the way Axe parser works.  It makes more sense now that you have given those examples :).  It will be nice when we get list addition like normal though :P I think it would work very well, although i am at a loss as to what to put for the replacement of brackets :/
Title: Re: Features Wishlist
Post by: Quigibo on March 16, 2010, 12:44:59 pm
I'm thinking maybe ΔList() right now unless I find something better.
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 12:51:08 pm
Yeah that sounds good.  Thats one thing thats a bit bothersome, finding good tokens for functions that don't exist on the calculator :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 16, 2010, 02:04:11 pm
mhmm I see now why, I guess we might haev to leave things as they are now. However, I would really like to not have to store my list stuff in hex, because it can be annoying to modify the data or to convert it in the first place.

And I understand about trying to find tokens for non-existing TI-BASIC functions x.x. Multi-Platform Language for Calculators team in 2004-05 got around this by having commands typed in the BASIC editor using individual ALPHA letters, for example, like this:

Quote
#CLRS            - Clears the screen
#TEXT <x> <y> <text> <color>      - Displays text
#LINE <x> <y> <x> <y> <color>   - Draws a line
#PIXL <x> <y> <color>      - Draws a pixel
#PIXT <x> <y> <var>         - Stores in <var> the color at (x,y)
#DRAW            - Updates screen
#SHFT <x> <y> <type>         - Used for scrolling, <type> specifies looping state (-1 = Loop, 1-3 standard colors)
#STOP            - abbr. for Store Picture (saves all color layers)
#RCLP            - abbr. for Recall Picture, shows the last pict saved with #STOP
#RECT <x1> <y1> <x2> <y2> <border> <fill> - Draws a rectangle in either a filled un unfilled state (.5 for no fill)
#DBMP <name> <x> <y>         - Displays a bitmap a (x,y)
#DISP <name>            - Displays a sprite at its stored position

That's quoted from MLC readme for the Casio AFX version (the code was the exact same syntax accross the TI-86, 68K, Casio AFX and 9860G calculators, and was gonna be the same on teh 83+Silver too). But as you can see, EVERY MLC command took 5 bytes! This is why I kinda prefer tokens to type commands, not to mention they're easy to access in prgm menu and CATALOG. Most tokens take one byte, others, two.

I also recall MLC for both the 83+ and the 86 being plaggued with the 8.8 (or was it 8.1?) KB code execution limit thing.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 04:46:32 pm
I made a little program that will convert the graph screen into hex so you can paste it into Axe source.  Thought it might be useful.  What you need to do is run the program with your picture on the graph screen, wait about 5 or 6 minutes, and when it is done it will paste the hex into Ans.
Title: Re: Features Wishlist
Post by: ztrumpet on March 16, 2010, 05:03:51 pm
Looks nice Sircmpwn. :)

Personally, I like lists as they are.  I think once you figure them out, they will be no trouble, and they're vary nice as is.  I'd rather have better access to the hardware with {X*3+8+L1} than L1(X*3+7).  (Remember these are my views, and no one's views are wrong because of them. :) )
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 05:10:51 pm
Looks nice Sircmpwn. :)

Personally, I like lists as they are.  I think once you figure them out, they will be no trouble, and they're vary nice as is.  I'd rather have better access to the hardware with {X*3+8+L1} than L1(X*3+7).  (Remember these are my views, and no one's views are wrong because of them. :) )

A) Thank you
B) Agreed, it should stay that way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 16, 2010, 11:06:44 pm
Nice program,. it might be useful for those who dont want to use the computer (BMP to z80 for instance) to convert pics.

@ztrumpet, yeah I guess it might be better this way, as long as we don't have to define lists with hex data. I would rather be able to define them like in basic or close. Having to convert everything to hex before storing it to list would suck imho x.x
Title: Re: Features Wishlist
Post by: calc84maniac on March 16, 2010, 11:55:36 pm
I think getKey(0) should tell whether any keys at all are pressed. Here is an example of how you could do it (feel free to write your own though):
xor a
out (1),a
ld h,a
ld l,a
in a,(1)
inc a
ret nz
inc l
ret


Edit: I modified it so the output would make more sense considering how the rest of the getKey() operations work. Now it returns 1 if no keys are pressed, 0 if keys are pressed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:46:15 am
That reminds me, how many keypresses at once can we use in an Axe game? I noticed some games detects like 3 at once, like the shooter example. I could move diagonally and shoot at the sane time. In BASIC only one is possible at once and in xLIB two (only arrows, others = 1 keypress) and Celtic III a bit more than arrows
Title: Re: Features Wishlist
Post by: calc84maniac on March 17, 2010, 07:36:46 am
That reminds me, how many keypresses at once can we use in an Axe game? I noticed some games detects like 3 at once, like the shooter example. I could move diagonally and shoot at the sane time. In BASIC only one is possible at once and in xLIB two (only arrows, others = 1 keypress) and Celtic III a bit more than arrows
The limit is the same as in ASM, which is the limit of the keyboard itself. Just remember that if you press 3 keys that are the corners of a rectangle, the 4th corner of the rectangle will be detected pressed as well.
Title: Re: Features Wishlist
Post by: Quigibo on March 17, 2010, 01:36:06 pm
I'm almost positive that you can detect as many keys at one as you need.  I don't think there are actually any limits by the nature of the commands.

What is the effect of this though?
xor a
out (1),a
I've never seen this used.  I thought it only works when a in binary is a combination of all ones and a single zero.

getkey(0) is a good idea, but isn't getkey=/=0 basically the same thing?  I was actually planning on making getkey(0) detect the [on] button.

EDIT: wait nevermind, you were requesting an indefinite return.  Regular getkey only is true once and then gets reset back to zero.  I'll have to add that command.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:42:45 pm
Mhmm interesting

Also can both getkey commands detect multiple keypresses? And when multiple ones are pressed, what does one getkey command returns as number?
Title: Re: Features Wishlist
Post by: Quigibo on March 17, 2010, 01:49:35 pm
No, "getkey" tells you the last key pressed once and then gets reset back to zero.  Its essentially identical to the basic getkey but with different numbers.

"getkey(KEY)" tells you if that particular key is held down right now.  So you can chain these together like "getkey(1) and getkey(2)" notice I don't need the parenthesis on the and operation since they're boolean.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:52:05 pm
ooh ok I thought one single getkey command checked for all keypresses. In BASIC, if you do

If getkey=25
A-1->A
If getkey=24
B-1->B

good luck moving diagonally.

At least that's a good plus that Axe allows multiple keypresses ^^
Title: Re: Features Wishlist
Post by: ztrumpet on March 17, 2010, 04:34:52 pm
I was actually planning on making getkey(0) detect the [on] button.
Could you make the On button have a number?  That would be useful at times! :D
I don't know what number to use, but there are plenty to choose from. ;D
Title: Re: Features Wishlist
Post by: calc84maniac on March 17, 2010, 09:38:49 pm
I'm almost positive that you can detect as many keys at one as you need.  I don't think there are actually any limits by the nature of the commands.

What is the effect of this though?
xor a
out (1),a
I've never seen this used.  I thought it only works when a in binary is a combination of all ones and a single zero.

getkey(0) is a good idea, but isn't getkey=/=0 basically the same thing?  I was actually planning on making getkey(0) detect the [on] button.

EDIT: wait nevermind, you were requesting an indefinite return.  Regular getkey only is true once and then gets reset back to zero.  I'll have to add that command.
If you set more than one bit to 0, you can select more than one key group. All the pressed keys in the groups are ANDed together. Thus, you can test for the "any key" quite easily this way.
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 11:43:01 am
Mmmm i think i'd like support to compile the program with ON breaking enabled for debugging (since you said it takes up a +300 bytes to handle the interrupts) but it would be a huge plus for those not working with interrupts and not wanting to deal with them, especially for those who don't understand them.  It can be a huge lifesaver during debugging though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 01:39:04 pm
personally I like the idea of letting the user choose when compiling. Example:

Choose if you want ON to be enabled
CHoose if you want error checking ON
Choose for what shell to compile for
Choose to store the compiled program in RAM or Archive

I don't know if I forgot any

EDIT:

The ability to draw the back-buffer directly to the LCD
The ability to store the LCD content straight to the back-buffer
Title: Re: Features Wishlist
Post by: SirCmpwn on March 21, 2010, 07:15:48 pm
The ability to draw the back-buffer directly to the LCD
The ability to store the LCD content straight to the back-buffer

A) conj(L3, L6, 768) \ DispGraph      ; Backbuffer to LCD
B) conj(L6, L3, 768)                      ; LCD to backbuffer
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 07:24:27 pm
You would probably have to change them to this to preserve the actual LCD buffer.

A) expr(L3,L6,768):DispGraph:expr(L3,L6,768)

And do this, since he was asking to store from the LCD, not the buffer.

B) expr(L3,L6,768):StoreGDB:expr(L3,L6,768)

However, it could be nice to have some built in commands for this.  Perhaps StoreGDB # with different numbers meaning different  buffers?
Title: Re: Features Wishlist
Post by: ACagliano on March 21, 2010, 07:33:58 pm
I tend to prefer the TI Basic way of calling lists, though I believe it was said that that is not possible. And, my request is for various linking commands. One set of send/receive that waits for a response or times out, and a single send command that just fires away, but doesn't wait for a response (if this is possible).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 09:30:20 pm
You would probably have to change them to this to preserve the actual LCD buffer.

A) expr(L3,L6,768):DispGraph:expr(L3,L6,768)

And do this, since he was asking to store from the LCD, not the buffer.

B) expr(L3,L6,768):StoreGDB:expr(L3,L6,768)

However, it could be nice to have some built in commands for this.  Perhaps StoreGDB # with different numbers meaning different  buffers?
Is it still safe, though? I guess it might be since:

Quote
L3 = 768 bytes (appBackUpScreen) Volatility: MED (Saving to back-buffer will corrupt)
L6 = 768 bytes (plotSScreen) Volatility: HIGH (Any buffer drawing will corrupt)

But I want to make sure that before using your suggestion (or SirCmpwn's), I won't run in any further problems, later, doing some stuff with these pointers
Title: Re: Features Wishlist
Post by: _player1537 on March 21, 2010, 09:58:28 pm
on the next version, I think it would be helpful if the compiler told you what line was wrong, it wouldn't have to let you fix it right there just to tell what the line is.  Just my 2 cents  (great job so far :P)
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 11:23:57 pm
But I want to make sure that before using your suggestion (or SirCmpwn's), I won't run in any further problems, later, doing some stuff with these pointers

Well since L3 and L6 are the backbuffer and the main buffer, i should think so, but you'd have to check with Quigibo o.O Using built in routines would indeed be safer :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 11:43:13 pm
Yeah I guessed it might be safe, since they're buffer-related. I was just a lil bit unsure. I try to not take too many chances sometimes you know XD (you know what happened to Illusiat 2002)
Title: Re: Features Wishlist
Post by: Eeems on March 22, 2010, 12:38:10 am
I would really like some sort of fps counter or something, so you can see how your code handles differing amounts of objects and such.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 12:42:36 am
wouldn't that be 84+-only, tho? (clock)
Title: Re: Features Wishlist
Post by: Eeems on March 22, 2010, 01:22:49 am
True, though if there was some way to do that on 83+'s that would be nice, even an approximation.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 12:22:12 pm
Yeah, sure.
But is it true that there is no way to get vars from the calc like the Pic1-Pic0 vars and the real variables?
If (that's true), I would like to have the function GetCalc([var name]) manage that.
Else I would like to have an example for how to do it.

I also would like the ability to use ElseIf:

If EXP1
[code1]
ElseIf EXP2
[code2]
Else
[codeX]
End
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 12:26:42 pm
I also would like the ability to use ElseIf:

++ ElseIf
Also, speaking of ++, I would like to see ++ and -- implemented, and possibly +=, -=, *=, /=.

I've been meaning to write another routine for accessing user variables.  I'll post it when I get around to it.
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 01:52:01 pm
The ++ and -- are already supported.  You just write them as +1 and -1.  The compiler automatically optimizes them to the increment.  ElseIf is a possibility, I forgot about that.  A FPS counter is something you could do with interrupts.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 01:55:31 pm
The ++ and -- are already supported.  You just write them as +1 and -1.  The compiler automatically optimizes them to the increment.  ElseIf is a possibility, I forgot about that.  A FPS counter is something you could do with interrupts.

Okay on the +1 and -1, thanks.  Also, FPS requires you to know when a second (the S in FPS) has passed.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 01:57:07 pm
I also would like the ability to use ElseIf:

++ ElseIf
Also, speaking of ++, I would like to see ++ and -- implemented, and possibly +=, -=, *=, /=.

I've been meaning to write another routine for accessing user variables.  I'll post it when I get around to it.

OK, Nice!

*LC hopes to hear from you soon*
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 02:11:27 pm
Hi and welcome here ^^

A routine to access users variables (or even appvars) would be cool, altough I assume this feature will be built-in Axe pretty soon.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 02:32:54 pm
Hi and welcome here ^^
Thanks!
I would like to know why you assume that "the feature will be built-in Axe pretty soon."
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 02:46:19 pm
I think I mentioned I was was going to add it in a few threads before.  It will probably be in the next version.  I'm not sure how much of the calc will be accessible in that release, but we'll see what happens. :)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 02:55:59 pm
For which reasons do you assume that? Well, of course i hope so too, but it's always nice to have a ground for (some || every)thing
A) DJ Omnimaga is an admin
B) You have 3 posts.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 05:57:11 pm
yes, I'am sorry, I've chosen the wrong words. :-[
I just only meant to say that I would like to know why he assumes that "the feature will be built-in Axe pretty soon."
I think I mentioned I was was going to add it in a few threads before.
I'm also very sorry I haven't read the entire topic before posting this question, but it seemed to me to take lots of time to do that :) (yes I'm a little lazy ;D)

I've another question: is the command Input going to do the same thing as in BASIC, or will there be an other layout, or perhaps the possibility to draw the input-text in small font?
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 06:08:42 pm
Numerical and character input might be a possibility in the far future, but I doubt it will be anything like basic.  However, it may be possible to embed actual BASIC code into axe itself, kind of like how you can embed assembly.  Not sure if it will work, but I'm reading up on it.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 06:34:04 pm
OK, right now I'm coding an input (with Axe), and I am going to use that code as a subroutine in my other programs, but I need to read some user variables to read the settings for the input. But right now I will do just the basic coding, and later on the more user-friendly usable thing.

I think BASIC in Axe is not a very bad idea, but isn't it too difficult to implement?
Perhaps it could be just executing a BASIC program.
Title: Re: Features Wishlist
Post by: _player1537 on March 22, 2010, 07:03:58 pm
I've written one if you don't feel like writing it, or if you feel like optimizing.  Just thought I'd point out (sorry if it sounded rude at all) http://ourl.ca/4129/80803 (http://ourl.ca/4129/80803)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 10:51:32 pm
yes, I'am sorry, I've chosen the wrong words. :-[
I just only meant to say that I would like to know why he assumes that "the feature will be built-in Axe pretty soon."
I think I mentioned I was was going to add it in a few threads before.
I'm also very sorry I haven't read the entire topic before posting this question, but it seemed to me to take lots of time to do that :) (yes I'm a little lazy ;D)

I've another question: is the command Input going to do the same thing as in BASIC, or will there be an other layout, or perhaps the possibility to draw the input-text in small font?
i said that since I effectively seen Quigibo posts saying it will be eventually done. Also, in some occasions, I chat with him real time, altough not as frequently as I used to (since nowadays I am generally only on IRC), so I can discover some more progress.

Also I think so far he is doing a good job at Axe. The goal is to make a language that is similar to TI-BASIC but not necessarly 100% similar and mostly game-oriented. It might be difficult to implement everything but at the rate this is progressing, I am confident he'll succeed in implementing a lot more.

That said let's try to remain polite and respectful towards other people, though. That goes for both regular users and new people, but in case of new people, if they are rude or overly negative on their first few forum posts and did not even contribute anything else in the TI community so far, it is easier for their image to be tarnished.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 02:48:02 am
Also I think so far he is doing a good job at Axe. The goal is to make a language that is similar to TI-BASIC but not necessarly 100% similar and mostly game-oriented. It might be difficult to implement everything but at the rate this is progressing, I am confident he'll succeed in implementing a lot more.
I agree completely with you. Axe is realy a great 'invention.'
That said let's try to remain polite and respectful towards other people, though. That goes for both regular users and new people, but in case of new people, if they are rude or overly negative on their first few forum posts and did not even contribute anything else in the TI community so far, it is easier for their image to be tarnished.
Yes, I know, but when I typed my third post, I did not intend to be rude or someting, but it sounded rude because my english is not that good you know...:-[
Please forgive me? :'(
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 23, 2010, 02:51:24 am
Ooh sorry didn't know that x.x, actually English is not my native language either ^^, don't worry too much about it. I was just unsure since sometimes through text it can also be hard to interpret stuff. We eventually get used to each person's way of writing so everything is all good afterward. :)
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 11:58:30 am
OK. thanks for the encouragement ^^
Title: Re: Features Wishlist
Post by: Raylin on March 23, 2010, 04:40:34 pm
Linking capabilities must be implemented ASAP.
:D

This would be immensely helpful.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 05:13:52 pm
I almost completely agree with you, except that accessing user variables is perhaps a little more helpful :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 23, 2010, 08:14:26 pm
It would be good if we could save/load from other types of variable, though, like Appvars, because if reading directly from lists, for example, it's easy to hack game save files, like setting LV 99, 9999 HP and 65535 gold, plus the person could cause a game crash x.x
Title: Re: Features Wishlist
Post by: Raylin on March 23, 2010, 08:15:27 pm
++
Agreed and seconded.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 24, 2010, 02:45:57 am
yes, that's true.
but if you want to use ur asm prog within a BASIC prog, than it's easy to store some settings in a list, or in Ans.
BTW, In BASCI you cán edit the AppVars, when you convert them to a program (just one or two bytes different). But I assume that will not happen very often. And perhaps u sometimes just want to be able to check your game loading system, so then it is just usefull that lists or whatever can be accessed, i think...

My opinion: AppVars are usefull for game saves, and lists/Ans are/is usefull for settings to use in tour asm prog.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 24, 2010, 03:04:41 am
Oh yeah true about that, altough if the data saved is produced by Axe in ASM format, it will most likely be harder to dechiper for less experienced users, like hex. Plus if it's squished, the user may not even be able to dechiper anything, because try for example to unlock the program files for Ztris, Galaxian or Desolate in MirageOs and look at the junk that will show up in the BASIC editor.

But yeah I guess you have a good point.
Title: Re: Features Wishlist
Post by: Raylin on March 24, 2010, 01:47:24 pm
So.
Program Writeback to AppVars.
It must be done.
Title: Re: Features Wishlist
Post by: Quigibo on March 28, 2010, 11:14:14 pm
If you check the first post on this thread, I will be editing it constantly to give everyone an idea for the time frame in which I plan to add features.  It also keeps track of ideas already suggested.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 28, 2010, 11:31:19 pm
nice, good idea, it should actually guide people in what project (or parts of projects) to work on and which one to wait before starting working on so they wait for upcoming Axe releases to make their task easier. That's of course for less patient people, though, so these people will probably use or modify the premade ressources like those by SirCmpwn to get these features early :P

I really like the if counter idea, because it will make it much easier to create animations and the like
Title: Re: Features Wishlist
Post by: _player1537 on March 28, 2010, 11:33:40 pm
could there be another section that shows only completed routines and how they work, its sometimes hard to find a particular routine through all the pages
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 28, 2010, 11:35:31 pm
well they are included in html format with each Axe downloads. Check the documentation.html file.
Title: Re: Features Wishlist
Post by: _player1537 on March 29, 2010, 12:42:57 am
do you mean user made routines?
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 01:01:22 am
The user made routines I do not officially endorse because many of them will be added as built-in features in future versions.
Title: Re: Features Wishlist
Post by: _player1537 on March 29, 2010, 01:02:23 am
what about the development tools like sprite makers or pic2hex programs?
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 01:13:26 am
Probably those will come packaged with the parser when its completed either as a separate app or a submenu in the parser.  But right now, if anyone authors a useful helper program to make axe programming easier, feel free to submit it to me and I'll include it in future versions.  Its also a plus if you can write a short readme to go with the program.  Include proper credits to yourself as well.

EDIT: This includes help manuals and tutorials too!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 01:49:57 am
I think SirCmpwn was planning to rewrite stuff like pic2hex and tile2hex in Axe later (once Axe supports saving), in ASM or both, but I could be wrong
Title: Re: Features Wishlist
Post by: LordConiupiter on March 29, 2010, 09:07:23 am
can someone please explain how a counter statement will work?
perhaps I'll understand it when i see an example, but right now i don't know what it exactly will be.
Something like a for loop with multiple vars ???
Title: Re: Features Wishlist
Post by: Galandros on March 29, 2010, 10:26:21 am
I have one idea but is an important add in Axe Parser:

Use letters a-b (note the lowercase) to serve has 8-bit variables. You could most operations you can with the default 16-bit A-Z.
And be able to use the a-z numbers in the A-Z operations.

This would need a major rewrite in Axe Parser functions, I think, but could make it even faster.

I still would like the port access and indirection to places other than the equated in L1 to L6.
Title: Re: Features Wishlist
Post by: Raylin on March 29, 2010, 10:32:21 am
Wait.
What?

I read your post, Galandros.
I was like... .D.

Explain please.
Title: Re: Features Wishlist
Post by: Galandros on March 29, 2010, 10:42:04 am
Basically that you could handle numbers from 0 to 255 or -128 to 127 with lowercase letters.
You gain 26 fast variables for numbers.
Operations with them would be much faster (and maybe smaller, depending on the overhead to all functions needed) when translated to assembly.

An example usage of this:
1->a
If a<8
a+1->a
Disp a>Dec
Title: Re: Features Wishlist
Post by: trevmeister66 on March 29, 2010, 11:41:00 am
I think its a good idea, but how would it be smaller or faster?
Title: Re: Features Wishlist
Post by: calc84maniac on March 29, 2010, 11:46:28 am
I think its a good idea, but how would it be smaller or faster?
Because the z80 is an 8-bit processor, and by nature doing 16-bit operations is slower and produces larger code.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 29, 2010, 11:49:49 am
Ah ok I understand now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 01:53:49 pm
can someone please explain how a counter statement will work?
perhaps I'll understand it when i see an example, but right now i don't know what it exactly will be.
Something like a for loop with multiple vars ???
Quoted from Quigibo on a chat a few days ago, in BASIC you would do this:
Code: [Select]
A+1->A
If A=20
0->A
<do stuff>
End
In Axe you would be able to this equivalent:

Code: [Select]
IS>(A,20)
<do stuff>
End

Useful for animated tiles where the animation is not updated every frame
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 02:01:41 pm
Right.  It increments a variable (like a for loop) and then checks to see if it has reached a maximum.  If the maximum is reached, the code gets executed and the variable resets back to zero so that the process can start over again.  So if you put it in your loop like this:

0->A
While 1
  <Render Frame>
  IS>(A,20)
    SinReg 150,5000
  End
End

This would make a beep every 20th frame.

DS<(A,20) would do the same thing but counts downwards and reset to 20 when it gets to zero.

And the lowercase operations might actually be not too much overhaul since they can just use the low order bytes of the standard variables.  However, they would be totally incompatible with regular variables.  You couldn't mix the two very easily without using some weird conversions.  Also, I would need to add some type of modifier so the parser knows if constants are 8 bit or 16 bit.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 02:06:10 pm
I wonder if that could also help for example in an action game where the character has a sword and slash it to kill enemies, but still be allowed to move while slashing his sword? Without that it would be much harder to not make your character stop completly during the entire sword animation

Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 05:40:17 pm
Another feature idea, after Quigibo mentionned me might compress his title screen:  Compressed sprites routine

When compiling, you could have sprites be compressed and use a different sprite display routine to show them. It would prbly be slower but people could choose whether if they want to use compressed sprites or regular ones. I wonder if it would be hard to implement, though...
Title: Re: Features Wishlist
Post by: ztrumpet on March 30, 2010, 06:09:17 pm
Another feature idea, after Quigibo mentionned me might compress his title screen:  Compressed sprites routine

When compiling, you could have sprites be compressed and use a different sprite display routine to show them. It would prbly be slower but people could choose whether if they want to use compressed sprites or regular ones. I wonder if it would be hard to implement, though...
Sprites are already compressed at an 8:1 compression ratio (double the Hex, as they are stored in token-ized binary), so I doubt if they could get smaller.  However, if they could it's a really cool idea! :D

I really like Galandros' idea!  How much faster would that be, and how would it affect the code (bigger/smaller) if you end up doing it? ;D

The IS and DS commands look really cool!   Awesome idea! :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 06:17:05 pm
oh I suggested it cuz Quigibo comment about the Axe Parser title screen (which would be 768 bytes, in binary), left some indications that it could be compressed even more. What I thought about is for images with several lines of white pixels in a row as well as black. Instead of

00000011
11110000
00011110
00000000
01100000
00000111
00000000
11111000

it could maybe become stuff like 00000011
1x4 0x7 1x4 0x10 1x2 0x10 1x3 0x8 1x5 0x3

Idk what would be the format, though. Also with complex sprites, they may end up larger, actually x.x
Title: Re: Features Wishlist
Post by: ztrumpet on March 30, 2010, 06:20:57 pm
That's a really good idea! :D Could some type of RLE (Run Length Encoding) be used mabey? :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 06:34:48 pm
i wonder how does RLE works... i should maybe check out.
Title: Re: Features Wishlist
Post by: Builderboy on March 30, 2010, 08:19:14 pm
Heh, Dj what you just did is RLE :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 09:19:44 pm
really? lol ok :P

I still should read further into it to see how it's applied in code form, though :P
Title: Re: Features Wishlist
Post by: Quigibo on March 31, 2010, 04:40:50 am
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Title: Re: Features Wishlist
Post by: Raylin on March 31, 2010, 11:41:31 am
I'm liking where this is going. :D

So, will Axe have a complied compression mode for data?
Title: Re: Features Wishlist
Post by: _player1537 on March 31, 2010, 11:57:56 am
there could also be a way to compress it like this...um I can't seem to find the program, but what it did was take each letter and strip it down to 6 bits, then packaged each of those 6 bit letters into a couple of bytes and every 4 letters saved you one byte.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 31, 2010, 02:47:27 pm
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Wouldn't there be a way to make Axe do the compression/decompression for us?

I would like text compression, tho, it would be nice for games with loads of it
Title: Re: Features Wishlist
Post by: ztrumpet on March 31, 2010, 04:52:30 pm
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Wouldn't there be a way to make Axe do the compression/decompression for us?

I would like text compression, tho, it would be nice for games with loads of it
I agree here.  I think a longer compiling time would be better than having to compress things by hand.
Text compression sounds awesome too! ;D
Title: Re: Features Wishlist
Post by: Raylin on March 31, 2010, 05:16:54 pm
I agree with said statement.

However, it must be an OPTION.
I would hate to only have 'compressed compiling' available and not 'quick compiling'.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 31, 2010, 10:54:34 pm
what Raylin said. If auto compression/decompression was possible, I would still like to be able to use uncompressed sprites for stuff that need speed
Title: Re: Features Wishlist
Post by: Builderboy on April 01, 2010, 01:01:00 am
Yeah compression would be a great thing to add into axe, but i wonder...  different algorithms work best on different sets of data, i wonder how/if axe would chose different algorithms?  Then again it could always be up to the user to decide on one, or to write there own.  Hmmm its an interesting subject, i will have to think more on it...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 01, 2010, 01:35:25 am
you could maybe do one in axe but I want Portal X finished too D:
Title: Re: Features Wishlist
Post by: Builderboy on April 01, 2010, 01:42:25 am
Oh well i wasn't suggesting that i was going to write one, just that the option is open.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 01, 2010, 01:44:12 am
oooh ok lol :P
Title: Re: Features Wishlist
Post by: Raylin on April 01, 2010, 11:18:59 am
On that note, Portal X must be finished before Portal 2 comes out.
My soul will be ripped in two otherwise. D:
Title: Re: Features Wishlist
Post by: ztrumpet on April 01, 2010, 03:31:00 pm
On that note, Portal X must be finished before Portal 2 comes out.
My soul will be ripped in two otherwise. D:
On that note, Portal Gold, X, and 2 should all be worked on! ;D

I think using different commands for compressed data (vs uncompressed, normal data) would work. :D
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 10:48:37 pm
Find Value

inString(PTR, VALUE) || Searches the application variable the name points to for the designated value. Returns 1 if the value exists; returns 0 if the value doesn't exist.
Title: Re: Features Wishlist
Post by: calc84maniac on April 05, 2010, 10:49:49 pm
Find Value

inString(PTR, VALUE, MODE) || Searches the application variable the name points to for the designated value. Mode can be changed to decimal (1) or hexadecimal (2). Returns 1 if the value exists; returns 0 if the value doesn't exist.
Why are there different modes?

Edit:
I think maybe a better way to do this would be:
inString(PTR, VALUE, SIZE), which would return a pointer to the first value found, else 0 if not found.
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 10:54:38 pm
Oh yeah.
Brain relapse.

Edited.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:08:49 pm
would value be a specific byte in the appvar?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:30:23 pm
No.
It would be a value and Axe would search the AppVar for that value.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:43:01 pm
Mhmm...

Could you provide an usage example of what it would do, including Input and Outputted results as examples?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:47:25 pm
Code: [Select]
:"MYVAR->Str1
:"Saved.->Str2
:Select(Str1)
:GetCalc(50)->A
:45->{A+24}
:If inString(Str1,45)
:Disp Str2,i
:End

Something like that.

In this example, we put in two things. We told Axe to look in MYVAR (Str1) for the value 45.
It returned a 1 and as a result, it threw back a "Saved." message.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:47:51 pm
including Input and Outputted results as examples?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:51:22 pm
EDITED.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:57:22 pm
i still don't get it x.x sorry

Nevermind, then. It may just be way too low-level for me.

I think I will just stick to the functions from Axe 0.0.5 and a few of the 1.x ones and that's about it because the last time I checked the doc I forgot half of the commands :/
Title: Re: Features Wishlist
Post by: Silver Shadow on April 06, 2010, 03:11:15 am
That's why should always have a copy of the doc at hand when programming. I too find it difficult to remember all of the commands and their syntax. But the more you program, the more chances you have of remembering them.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 03:14:22 am
Well, I have it on my PC all the time and an older copy, but I stopped looking at it for a week and forgot a lot of commands. I had to ask Quigibo (via chat) to remind me what some do in more details x.x

I guess I'll really need to get coding again
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:08:31 am
I was planning to add an instr() command, but a little more general than what you are referring to.  It would be like this:

instr(START,BYTE<,SIZE>)

The last option is optional.  You give it a pointer, and it searches for the byte until it finds it and then returns the pointer to that byte, or it returns zero if not found.  That way, its not just limited to application variables, you can use it anywhere.

Its pretty easy to add, but I haven't yet because honestly, it really isn't as useful as it sounds.  There is a regular assembly instruction that does exactly this called "cpir" but I've never used it or needed to use it ever for anything.  I've almost never seen it used in other programs either.  It would only be needed for very specific applications, and even then its easy to write a subroutine yourself with existing commands.  But yes, I will support it eventually, but its in the back of my list.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:11:02 am
Just focus on the more essential commands for now I think ^^ (and bug fixes if any)

In such command, though, how would you specify (in this syntax) if you want to point to a byte in an appvar instead of inside the program?
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:15:00 am
In such command, though, how would you specify (in this syntax) if you want to point to a byte in an appvar instead of inside the program?

Select(Str1)
getCalc()->A
instr(A,'Z',100)

This would search for the character 'Z' in the first 100 bytes of the appvar.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:19:24 am
About getcalc() it returns what was selected with Select(Str1), right, then store it into A, then search from memory location A through the next 100 bytes, then return 1 if "Z" is found?
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:25:24 am
Yes, but just like the calc's instr(), it doesn't just return 1, it returns the location of the found byte if it is found (a pointer) because this is much more useful.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:39:37 am
oh ok, that's better then. Thanks for explaining

I will most likely have to code more soon to not forget half of Axe commands again in a month x.x

Btw you might want to update the first topic post with the recent changes in features
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 05:16:42 am
perhaps it could be usefull to be able to call the register values from the processor? like hl?

the following code would return the value of ans:
Code: [Select]
PwrReg HLor
Code: [Select]
ref(HL)or
Code: [Select]
Get(HL)
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 07:15:26 am
perhaps it could be usefull to be able to call the register values from the processor? like hl?

the following code would return the value of ans:
Code: [Select]
PwrReg HLor
Code: [Select]
ref(HL)or
Code: [Select]
Get(HL)
But HL is already, by default, "Ans". The other registers hold nothing useful, unless you use them with inline Asm (in which case you would just use the inline Asm to access the registers anyway)
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 09:00:33 am
U're (partially) right. On second thought this idea is pretty unusefull, but I thought that Axe perhaps could get the functionality of ASM on ur calc. Just like in C: u can use built in functions, but u can also use more 'native' commands.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 01:54:59 pm
It's better to not make Axe look too complicated by adding low level commands like this, though, or at least list those commands in a special area stating you need ASM knowledge to use them, not with the other commands, else people will look at the first commands in the doc and get the impression the language is not much easier than ASM as soon as they run into such command in the list.
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 01:56:59 pm
It's not really as complex as it looks.
It's just inString in essence.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 02:28:56 pm
Aaah ok, just making sure. Cuz Axe in the first place is meant to be kinda easy to learn and look user-friendly at first glance
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 02:34:39 pm
OK, perhaps reading registers is not one of my best ideas x.x
The more experienced programmers just should use inline ASM, thats a much better idea then I guess
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:37:31 pm
I dunno if I said it already but...

Pt-On(X,Y,PIC,<dimension1>,<dimension2>)

If <dimension1> and <dimension2> aren't found, automatically display the sprite in 8x8.

Also,

DS<(TYPE, X1, Y1, X2, Y2)

Begin drawing a shape of a certain TYPE (xLib commands 0-10) at (X1,Y1) and stop at (X2,Y2).
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 10:39:38 pm
I dunno if I said it already but...

Pt-On(X,Y,PIC,<dimension1>,<dimension2>)

If <dimension1> and <dimension2> aren't found, automatically display the sprite in 8x8.

Also,

Pen(TYPE, X1, Y1, X2, Y2)

Begin drawing a shape of a certain TYPE (xLib commands 0-10) at (X1,Y1) and stop at (X2,Y2).
The Pen token is unusable in programs, FYI
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:42:17 pm
Oh.
Oops.

I need to get more sleep.
EDITED.
Title: Re: Features Wishlist
Post by: Will_W on April 06, 2010, 10:42:47 pm
It's not a token at all.
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:45:40 pm
Changed the command to DS<().

It works, too.
:D

Draw Shape! :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 10:49:43 pm
Remember for sprite width, they would need to be multiples of 8, though.
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 10:59:34 pm
I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" value
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 11:04:36 pm
What about imag()?

Could that work?
Title: Re: Features Wishlist
Post by: SirCmpwn on April 06, 2010, 11:07:53 pm
^ I like that idea.
Also, you could easily do something similar to Celtic III for file access.  (I just realized Iambian is on this thread right now, lol)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 11:09:34 pm
I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" value
The If counter commands, IIRC. He explained it in a post somewhere but I don't remember in which thread. (Darn this sub-forum is getting big)

Also try to not use too many two byte tokens for commonly used Axe commands, such as ANOVA(
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 12:39:30 am
For sprites larger than 8x8, you can just use a subroutine:

:[your 16x16 sprite here]->Pic1
:0->X->Y
:Pic1sub(DS)
:DispGraph
:Return

:Lbl DS
:->A
:Pt-On(X,Y,A)
:Pt-On(X+8,Y,A+8)
:Pt-On(X,Y+8,A+16)
:Pt-On(X+8,Y+8,A+24)
:Return

This will draw sprites with any size from 9 to 16 pixels.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 12:57:21 am
Would LordConiupiter routine work as well too? He posted some weird sprite routines that apparently displays 16x16 sprites, using some r commands. Which one would be faster and which one would be smaller (in ASM form)?

http://ourl.ca/4129/83923
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 01:08:46 am
That's is basically a Pt-Off() routine, but it only works when the sprite is aligned to the 8x8 grid.  BUT, if you only need the sprite aligned anyway and are always using Pt-Off(), it sure does work.  Keep in mind though that the axe sprite commands are usually smaller and faster.  I haven't compared this one though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 01:43:17 am
Ah ok thanks for the info. To me, such routine would most likely be for both tiles and sprites, so having to align it might be an issue if I wanted smooth movement x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 02:56:08 am
Just updated the list fyi.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:10:54 am
Ok good ^^


Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.

Also, when Axe final version (or the one where old commands will have almost no more chances of changing) is out, do you think it may be best to split Axe routines into their own sub-forum and put them in a new sub-forum between TI-BASIC routines and ASM routines? As for now, they are getting harder and harder to find through the 1400+ posts in this sub-forum, even if a topic dedicated to them was made, but for now I would wait a bit to do such thing, though, since you said Axe syntax for some commands may change (unless this is not the case anymore?)
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 07:19:59 am
Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.

If you have a byte A with two 4-bit numbers packed in it, you can extract them with A/16 and A^16

Edit:
If you want greater speed, use A*16/256 instead of A/16 so it doesn't have to do any real division
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:12:37 am
Thanks I guess that works too and I didn't knew about the later x.x, I guess it might be a good thing to add to Optimizing Tips.txt.

As for A^16, I assume afterward it may be best to redivide it with A*16/256 (or A/16) afterward, right? I worry about having to use more If/then conditions for sprite/tiles displaying then x.x (since that sprite number would be multiplied by 16 unlike the one initially extracted with

Btw I would also find half bytes much easier to read than full bytes in map data since each tile would be one single character instead of two and as you know I am so used to work with text for sprites, so if I need to do a quick edit without wanting to dig up a tile/map editor, I can simply just edit the data directly easier.
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:17:33 am
Mmmm it would be nice for Axe to optimize division by any number multiple of 2 into a chain of bitshifts.  I was at first surprised how slow /64 was compared to /2 :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:18:47 am
yeah that might be a good idea too, even if it means slower compiling :P
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:21:14 am
Hah, at this point i dont think we even have to worry about compiling speed.  It might be the difference between 1 second and 1.1 seconds ^^ Gosh i love the Axe compiling speed, especially after having worked with the slow version for so long ;)
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:23:22 am
Yeah, Axe compiles super fast.  I love it.
Also, I would like to be able to retrieve the pointers to a label for normal math.  This could be useful in the Half Life game engine.  For instance:
Code: [Select]
AB->A
Disp A>Dec   ; Display the address of AB
Return
Lbl AB
Disp "Hello World"
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:41:38 am
Yeah true I guess. I think as long as it won't take 10 seconds to compile 5000 bytes of source we're fine. Plus those who used TASM to compile ASM on old computers are used to much slower compiling speed anyway. On my Pentium II 350 MHz, it took 4 seconds just to compile Hello World. I'm not sure how much faster it is on newer PCs, though.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 11:31:34 am
Hey, using OTBP Assembler, it takes about 30 seconds to compile Hello World.  Mosaic does the same program in less than one.  I'm excited to finish it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 12:17:33 pm
Lol, funny how a 6 or 15 Mhz calc can compile an ASM program faster than a computer. Plus you don't need to go through the process of loading the file on Wabbitemu all the time, meaning saving even more time and the only thing to worry about is making sure your data is safe on calc (CalcUtil I guess) in  case your program contains errors.
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 02:02:40 pm
Bit shifts are not the best way to go for division since it takes 4 bytes each shift.  That's why I didn't optimize higher divisions of 2.  But now that I think about it, multiplication as a method of dividing is small enough to optimize.  I'll add that next time.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:00:39 pm
Which kind of division is called bit shift? Do you mean the one going like A/2/2/2/2?
Title: Re: Features Wishlist
Post by: Silver Shadow on April 07, 2010, 03:09:31 pm
Hey, using OTBP Assembler, it takes about 30 seconds to compile Hello World.  Mosaic does the same program in less than one.  I'm excited to finish it.
"Mosaic"?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:10:45 pm
http://ourl.ca/4332
Title: Re: Features Wishlist
Post by: Silver Shadow on April 07, 2010, 03:20:55 pm
That's strange. I have no idea how I managed not to notice it...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 04:19:45 pm
Well on some days projects get posted in a lot and if one gets no updates for a few days, it drops in the list pretty fast. Half of the first project topics page has posts from 2010.

This is why the new double posting rule that was added in march on Omnimaga is 1 hour between posts for authors projects rather than 6

EDIT:

I have a suggestion for one of the future update, that is not for Axe app itself, but either the doc or another help file: a list of all compiling error codes possible, their descriptions and possible causes and possible solutions for most common cases.
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 08:34:04 pm
Definitely will add that doc when finished.  Currently, I have VERY non-descriptive errors like TI-Basic.  There are only about 15 possible errors right now, but I plan to have about 50-100 when finished to be really specific about the exact part of the code that has the problem.
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 08:38:22 pm
O_O

If you were to put a line number in that...

ERROR: BAD SYMBOL - LINE 6

OMG.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 08:40:27 pm
well, the issue, though, with line number, is that for massive programs it's hard to count until that line if the error is at like line 500 x.x
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 08:51:41 pm
What if it displayed the line in question on the screen?
Like in small text...?

ERROR: BAD SYMBOL - LINE 6
:"This is a test->Str1-><theta>
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 09:09:12 pm
that could work too
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:10:06 pm
I don't belive you can store to <theta> with Axe.  At least, I couldn't do it in version 0.1.2.
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 09:13:22 pm
I don't belive you can store to <theta> with Axe.  At least, I couldn't do it in version 0.1.2.

LOL. SirCmpwn, the point of that entire post was that <theta> was a bad symbol. It was just an example. :P

250th post. :D
FINALLY!
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:14:09 pm
...
I made a fail... where are the paper towels?
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 09:17:43 pm
LOL. In the bathroom. :P

[ontopic]I would like it if linking could be available through Axe soon. Get() and Send() are mocking me.[/ontopic]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 09:54:21 pm
However, wouldn't that be hard to implement? I heard something about how getting a calc variable/memory area while the calc is busy was rather hectic and that for it to be successful, the receiving calc had to receive at the exact picosecond the sending calc is sending. That,s how Omnicalc get/send commands works, IIRC.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:57:02 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 10:03:54 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Well, there are two link lines, but only one bit can be sent at once. The sending calculator pulls either line A or line B low, depending on the value of the bit being sent. The receiving calculator acknowledges by pulling the other line low. Then the sending calc lets its line up, and the receiving calc lets its line up.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:05:50 pm
^oh, i see.  Does the hardware ack or the software ack?
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:14:56 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:17:20 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Well, there are two link lines, but only one bit can be sent at once. The sending calculator pulls either line A or line B low, depending on the value of the bit being sent. The receiving calculator acknowledges by pulling the other line low. Then the sending calc lets its line up, and the receiving calc lets its line up.
just one bit, not even byte? Darn, now to send an entire byte...
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 10:17:40 pm
Whatever allows for real-time multiplayer games is good with me. :)
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:18:30 pm
Heh, yeaah once we write a bit sending routine, we use it to write a byte sending routine XD Haha the joys of asm ^^
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:18:31 pm
DJ, to send an entire byte require at 4 loops per byte, if I am correct.
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 11:06:42 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
The problem here is that bits may be skipped. Not good D:
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 11:09:31 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
The problem here is that bits may be skipped. Not good D:
that was my worry about linking stuff.

I wonder how does Ztris and Ztetris do their linking, though, to work so successfully. I never had issue with their linking failing unless both calc models were different.
Title: Re: Features Wishlist
Post by: Quigibo on April 08, 2010, 12:13:01 am
Linking is very easy.  I could add that feature literally in about 10 minutes.  I already made the routines when I made puyo puyo.  Actually coding it well with Axe Basic to get the link synchronized is going to be tricky on the programming side though.  I have spring break coming up next week.  I'll definitely finish the beta sometime around then and I'll have most of these commands working.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 08, 2010, 12:56:48 am
really? I guess it might need some small tutorials with example, though, I guess

I can't wait ^^
Title: Re: Features Wishlist
Post by: Raylin on April 08, 2010, 07:32:25 am
That is AWESOME, Quigibo!

:D

FORGE FORWARD!
(Also, I offer my writing skills for the tutorials.)
Title: Re: Features Wishlist
Post by: Quigibo on April 09, 2010, 04:14:40 am
Just want to take a little poll:

Should For() loops be signed or unsigned?  If they are unsigned, you can make loops as large as 65536 but you can not increment from a negative number to a positive one.  With signed For loops, you can do things like this:  For(A,-8,8) however it limits the maximum size to half of the unsigned max.  Also, the signed routine would probably be about 3-4 bytes larger each For loop and consequently slightly slower each iteration (usually negligible).  I could have an option to do either one, but I don't want it to get too confusing and I have no idea what type of syntax modifier I would use.  Maybe I can make the 'R' power thing the universal modifier where when you put it at the end of a command, it does the non-default version.
Title: Re: Features Wishlist
Post by: mapar007 on April 09, 2010, 05:52:38 am
Mmmh... A hard choice. I think having it as an option is the best. (do you have support for optional arguments in statements? It might be the fifth argument of a For() instruction)
Title: Re: Features Wishlist
Post by: Raylin on April 09, 2010, 08:12:19 am
^++
Agreed and seconded.
Optional unsigned For( loops.
Title: Re: Features Wishlist
Post by: mapar007 on April 09, 2010, 08:17:13 am
Yup, unsignedness should be the optional setting. You rarely need to go over 32K in a loop.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 09, 2010, 08:39:33 am
I like the idea of making R the universal modifier.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 09, 2010, 09:22:50 am
Maybe optional, altough I personally may not mind if unsigned is not supported. For which thing in particular would you need numbers higher than 32767 in For loops ?
Title: Re: Features Wishlist
Post by: Builderboy on April 09, 2010, 10:29:02 am
And if you really really needed to go higher than 32767 you could just do

For(F,-32767,32767

And you would get the full range there :)
Title: Re: Features Wishlist
Post by: Quigibo on April 09, 2010, 04:14:29 pm
The range is the least of my concerns.  The increase in file size is what I'm worried about because It will make all programs bigger that use for loops.  I think I will use a modifier to make it optional, probably the R again.  From now on, the R will stand for "Revised" and be a slight modification of the original command.

For instance, adding it to the end of any drawing command makes it do grayscale drawing instead of regular.  I'm sure I will find more uses for it soon as well.

Another thing I wanted to mention is that for signed math, I think I will make the default unsigned instead of my original idea of making it signed by default.  I have chosen this way for the following reasons


But the first of these reasons is the most important.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 09, 2010, 04:18:15 pm
I would go with what is smaller in size, or if adding the option to use alternatives won't increase the compiled program size, add options too.

I didn't knew unsigned was faster and smaller. I guess you should probably make them all default. You should also mention in the doc that signed will make the program larger so people are aware of that.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:45:46 am
Feature suggestion and question:

1) It would be nice if there was a command to return 0 if the calc it's ran on is a regular 83+, 1 if it's a 83+SE, 2 if it's a 84+ and 3 if it's a 84+SE.

2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot x.x
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:49:18 am
2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot x.x
It is meant to replace a bunch of If/Else statements with A=0, A=1, A=2, A=3, etc, replaced with a faster and smaller solution (or something like that)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:50:54 am
mhmm ok, would this make the compiled code smaller?
Title: Re: Features Wishlist
Post by: Builderboy on April 11, 2010, 12:52:01 am
The switch statement is this:  Sometimes you have data you want to be loaded, or specific things to do under specific circumstances.  Usualy you have to do this with a list of If statements like this:

Code: [Select]
If A=1
Blah
End
If A=2
Blalala
End
If A=3
Bluhuh
End
If A=4
Wooo
End
If A=5
Rickroll
End
If A=6
Grrrr
End

but with a switch statement you could do something like this

Code: [Select]
Switch(A)
1:Bla
2:Woooo
3:Grrrr
4:Rickroll
5:Chocolate rain
6:Lobser
End

Which is a lot easier on the eyes :) Although it probably would have zero affect on compiled size or speed.  Normaly it is just a feature to make things look nice
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:56:48 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:58:22 am
OOooh! ok I see! It would be MUCH handier this way! Much easier to read and to code.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 02:10:47 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Right, its much more efficient in an assembly program to do switch statements than a bunch of if statements.

Unfortunately, it would be way too hard to automate this into the parser since its not just simple templated code.  It would have to check all the conditions in the beginning (non-linear parsing) and then create a jump table to each of the switch labels.  It's just way too complex to code and it would need a lot of extra memory.  I mean I could just do it as something that just makes it "easy on the eyes" but I don't feel like its worth the extra effort.  ElseIf statements should take care of this for the most part anyway.
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 02:14:34 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Right, its much more efficient in an assembly program to do switch statements than a bunch of if statements.

Unfortunately, it would be way too hard to automate this into the parser since its not just simple templated code.  It would have to check all the conditions in the beginning (non-linear parsing) and then create a jump table to each of the switch labels.  It's just way too complex to code and it would need a lot of extra memory.  I mean I could just do it as something that just makes it "easy on the eyes" but I don't feel like its worth the extra effort.  ElseIf statements should take care of this for the most part anyway.
My idea was that it would be required to be from 0 to some number N, and the values must be typed in increasing order. Any missing numbers would jump to the "default" tag
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 02:41:50 am
hmm... If they are forced to be in order from 0 to N that would greatly simplify the statement.  But since the parser doesn't know how many labels are in the switch statement, I would have to dynamically expand the table in the end of program location.  And I think I would still need nonlinear parsing.

What I could do is have the switch statement require labels in the program which would take the burden off of the parser and into the programmer's hands.  Something like this:

Switch(A,J0,J1,J2,J3)

Lbl J0
...

Lbl J1
...

etc.

Here, if A is 0, it jumps to label J0, if A is 1, it jumps to label J1, etc.  You can choose any labels you want (including identical labels) and the variable you are comparing can be any expression.

Would this be useful to anyone though?  It does kind of limit the usage a little bit.
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 10:57:17 am
Hmm...

I can't really see the purpose of this command...

What are the benefits of having this over saying If A=0:End, etc... ?
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:28:43 pm
Hmm...

I can't really see the purpose of this command...

What are the benefits of having this over saying If A=0:End, etc... ?
It would produce faster and smaller z80 code.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 12:31:53 pm
Does the parser support conditional form:

While (A=0)(B=0)(C=12)

cuz i use that alot now.
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:35:21 pm
Does the parser support conditional form:

While (A=0)(B=0)(C=12)

cuz i use that alot now.

You will need to put an "and" between each of those statements (there is no implied multiplication in Axe, and you will want to avoid multiplication for speed reasons anyway)
Title: Re: Features Wishlist
Post by: _player1537 on April 11, 2010, 12:35:58 pm
well, you would have to put a '*' symbol in between those, but yes that would be valid (I'm pretty sure at least)

Edit: Yeah, what calc said would be better
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 12:56:38 pm
Yeah, multiplication can really destroy the speed of a program.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 01:35:05 pm
I assume this excludes multiplication by 2, right?
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 01:40:52 pm
Of course.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 04:08:24 pm
also excludes multiplication of 3,4,5,6,7,8,9,10,12,16,32,256 and more in the future. (see optimization tips)  Also, the multiplication is only optimized if the constant is on the right!  So 2*A is just as slow as regular multiplication.  You need to do A*2 to get the speed and size benefits.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 06:17:43 pm
So, wait. I can't even multiply this type of a function for attack power:

1.5*L [store] B

Where L is your level and B is your attack booster.


And can variables in Axe hold fractions (as in 1.34) as a value.
Title: Re: Features Wishlist
Post by: Builderboy on April 11, 2010, 06:27:56 pm
Nope, Axe does not have decimal support, so you can only have whole numbers.  You can kind of multiply by 1.5 by doing

L*3/2->B

But you wont get the precision of using floating point numbers, it will drop the decimal places.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 06:31:32 pm
Bah humbug.

It's ok, though. I'll figure it out. Axe still rocks.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 08:03:16 pm
Actually, you can do decimals (for the most part).  Since variables are 2 bytes, the low byte can be the decimal part and the high byte can be the integer part.  It requires some knowledge of hexadecimal though and the math might be a little confusing at first, but its almost the same as regular math.
Title: Re: Features Wishlist
Post by: Will_W on April 11, 2010, 08:09:30 pm
That's called 8.8 fixed point by the way if anyone wants to know more about it, and I have a (poorly coded) include file that does some stuff with it in z80 over at revsoft.
Adding two 8.8s is the same as adding two 16 bit numbers.  Multiplying two 8.8s results in a 16.16 which needs to be truncated differently (Keep the middle bytes) than if you had multiplied two 16 bit numbers(Keep the low bytes).
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 11:42:14 pm
Quigibo, I think you should have an operator to multiply by an 8.8 fixed point value (because this type of value is what sin and cos return, right?)
Title: Re: Features Wishlist
Post by: Will_W on April 11, 2010, 11:53:51 pm
8.8 multiplication would be niffty.  I can't think of it right now, but I'm pretty sure division is different too.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 01:27:25 am
Quigibo, I think you should have an operator to multiply by an 8.8 fixed point value (because this type of value is what sin and cos return, right?)
Kind of.  Since the range is 127 to -127 its really half of the actual sine value.  By the way, thanks for the sin routine!  I modified it a little to get it in the right range, but it's a pretty cool optimization.  I don't know if you were aware I used it.  Someone gave it to me in IRC and said you made it.

I don't know if 8.8 multiplication is really that essential.  There's already a way to multiply by fractions (a multiplication then a division like Builderboy's example) and I've never actually needed to use 8.8 it in any of my asm programs before.

A little off topic:  I'm trying to think of a way to make shell support and I'm not sure how to do the menu because I think it'll be too complicated to have that information built into the source.  There's a lot of information in descriptions and thumbnails, both of which are hard to input.  So unless I make it real simple: Description is the first comment in the program and the thumbnail is an Axe logo, I'm not sure how to go about this and still be easy to use.  I think I'll just go with the simple way for now and do the more complicated way later.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 01:35:08 am
Remember that Ion doesn't support thumbnails, tho, even when its programs are ran in Mirage. Maybe for now have the compiled program name as first line, description, and for now Axe logo for thumbnail if compiled for MirageOs. Later, maybe add support for custom logos?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:02:45 am
Remember that Ion doesn't support thumbnails, tho, even when its programs are ran in Mirage. Maybe for now have the compiled program name as first line, description, and for now Axe logo for thumbnail if compiled for MirageOs. Later, maybe add support for custom logos?
That's essentially exactly what I just said ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:07:01 am
I know, I was just stating it as what I think that should be the best idea...

Well this was my final Axe Parser suggestion/opinion statment. I'm going to let other people provide theirs and wait for the final version.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:12:55 am
You ended it with a question mark so I thought you were asking me if that was what I was going to do.  Sorry if I misunderstood...
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:15:34 am
Take a look at the DCS BASIC header:
::DCS6
:"64-char_hex_icon
:Program code
I can't think of a way to use sine values without 8.8 multiplication, since they are always between [0,1]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:19:13 am
You ended it with a question mark so I thought you were asking me if that was what I was going to do.  Sorry if I misunderstood...
Oh sorry for the confusion x.x

I sometimes tend to end my suggestions (especially short ones) with a question mark, especially when the person asks for some. x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:29:56 am
Its simple:


;A holds the value to be multiplied in the range 0 to 255
;B holds angle

sin(B)*A/256    ;You can do this right now, but its unsigned
sin(B)*A//256    ;You can do this in the future as signed


Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:36:03 am
is dividing by powers of two optimized so it uses shifting instead of division?
Or better yet, Shifting and rotation commands?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:41:52 am
Well, /2 is optimized and so is /256.  /4 is not since its 8 bytes.  A load and call to the subroutine is only 6.  If you want a speed optimized command instead of a size one, you can just do /2/2 and chain them for higher powers of 2.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:45:37 am
Very nice, multiplication too?  And rotation commands?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 03:28:18 am
Well, /2 is optimized and so is /256.  /4 is not since its 8 bytes.  A load and call to the subroutine is only 6.  If you want a speed optimized command instead of a size one, you can just do /2/2 and chain them for higher powers of 2.
So /2, /16, /256, *2, *16 and *256 are optimized, right?

I personally optimize for speed most of the time. Most BASIC programmers badmouthed me for large filesize in the past due to that, but I did not want Reuben Quest to run at like 1 fps on a SE for example. If size is really a concern, I would most likely go for the slower method, though.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 03:53:29 am
The full list is included in the zip file in the optimizations file.  I know its easy to miss, so here is a copy of it:

Code: [Select]
================================================
List of expressions with automatic optimizations
================================================
Expression______Bytes___________
+VAR            5
+CONST          4
+1              1
+2              2
+3              3
+256            1
-VAR            7
-CONST          4
-1              1
-2              2
-3              3
-256            1
*VAR            7 + sub
*CONST          6 + sub
*2              1
*3              4
*4              2
*5              5
*6              5
*7              6
*8              3
*9              6
*10             6
*12             6
*16             4
*32             5
*64             6
*256            3
/VAR            7 + sub
/CONST          6 + sub
/2              4
/128            5
/256            3
^VAR            7 + sub
^CONST          6 + sub
^2              5
^4              6
^8              6
^16             6
^32             6
^64             6
^128            4
^256            2
=VAR            12
=CONST          11
=SHORT          10
=0              8
=1              8
=/=VAR          12
=/=CONST        11
=/=SHORT        10
=/=0            7
=/=1            8

SHORT means less than 256 bytes
CONST means any size
=/= is a "not equal sign"

I'm aware there's more I can add, I'm just focusing on other more important things at the moment.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 04:01:50 am
Oh I didn't knew this is what it was about x.x. The second column confuses me. Is it the amount of memory each of those takes, or is it the amount of memory saved by using them over something else?

EDIT: nvm, looking at the multiplications, I think I get it, now. Some of those seems to take a lot of memory o.o does this means A/2 would take 4 bytes total or 4 bytes for the /2 plus the amount of bytes for the A part of the code?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 04:11:39 am
Yeah it doesn't account for the variable loading.  Its 3 bytes to load variables or constants before you actually do the operation.

Also Axe is much much much faster than BASIC.  Remember that it requires a whole new mindset.  The only time you ever have to worry about speed is with very intensive drawing and computation.  For instance more than 20 sprites with collision detection, event handling, and maybe some AI code.  And even then, the speed increase is usually a very small fraction of the total cycles.  Most cycles go into displaying sprites usually.  That's why I always optimize for size.

And of course I say "usually".  You can always optimize these things yourself even though its not automatic.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 04:17:19 am
Yeah speed wise I really meant games with a lot of stuff moving around like your space shooter. I guess the best way would be to try out and if I find the speed gain to not be signifiant enough (especially if I have to slow the game down) I will just go with size.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 11:46:05 am
Does Axe have rotation and bit logic?
Title: Re: Features Wishlist
Post by: Raylin on April 12, 2010, 01:18:13 pm
It needs to.
:D
:D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:03:51 pm
What would be bit logic?
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:08:44 pm
It means the "and", "or", and "xor" commands that work bit-by-bit (which is the default in Axe). I also assume he means bit shifting (which are *2 and /2 in Axe). There is no bit rotation command, though (but seriously, even C doesn't have that)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:10:12 pm
aaaah ok. Wouldn't that be complicated to use, though? x.x
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:11:12 pm
Oh?  I didn't know C didn't have that.  Guess there's no real need of it in Axe then.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:13:42 pm
What would be an example (maybe some sort of Axe pseudo code) of it in action and example of what it would do?
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:17:00 pm
Take the byte 11010100 and rotate it to the right one through carry, and you get 01101010. 
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:19:52 pm
Probably the most useful application is when working with bitfields. Say you wanted to have a variable that holds various flag bits, that are 0 or 1. You can use bitwise logic to change individual bits of the value.
A or 4->A would set bit 2 to 1, for example. A and 4 would be used to check whether bit 2 is 0 or 1. It's really a pretty low-level thing, but it can be useful (I sure wish TI-Basic had this)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:31:57 pm
mhmm ok so if for example

A=0 all 8 bits would be 0,
If A=1 the 8th one would be 1,
If A=2 the 7th one would be 1,
If A=3 both 7th and 8th one would be 1
If A=4 the 6th one would be 1,
If A=5 the 6th and 8th one would be 1

And so on?

I'm a bit confused, still. I don't know if I understadn what you mean.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:33:28 pm
mhmm ok so if for example

A=0 all 8 bits would be 0,
If A=1 the 8th one would be 1,
If A=2 the 7th one would be 1,
If A=3 both 7th and 8th one would be 1
If A=4 the 6th one would be 1,
If A=5 the 6th and 8th one would be 1

And so on?

I'm a bit confused, still. I don't know if I understadn what you mean.
Yeah, you've got it right (except we refer to the rightmost bit as bit 0, and the leftmost as bit 7)

Edit:
Example, setting pixel (0,0) of the graph buffer manually:
{L6} or 128->{L6}
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:36:05 pm
oh ok. My worry, though: wouldn,t it be very hard to do If conditions checking if certain bits are = to 1? Maybe it would need a special command to check each indidivual bit

I would love this feature, though, because it would make storing switches/treasure chests/items acquired flags much easier and smaller.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:38:20 pm
oh ok. My worry, though: wouldn,t it be very hard to do If conditions checking if certain bits are = to 1? Maybe it would need a special command to check each indidivual bit

I would love this feature, though, because it would make storing switches/treasure chests/items acquired flags much easier and smaller.
Hmm, this is true. Maybe there should be a command to return powers of 2 for quick bitwise operations.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:40:27 pm
To check a bit, you can mask it with And.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:43:04 pm
To check a bit, you can mask it with And.
Yeah, but the issue is with having to write each case of "and 1", "and 2", "and 4", etc. Having something that will check a given bit from 0 to 7 (or 15, since we are using 16-bit values) would be pretty useful to get rid of repetitive code.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:44:41 pm
Yeah, but its much more size and speed efficient to use bit checks.  I'll add auto-ops for "and" and "or" operations with powers of 2 sometime in the future so they can be used.  Maybe even a binary prefix, becasue that would really help with this.

EDIT: ninja'd!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:44:58 pm
Yeah this is what I meant (calc84 reply). Else we may end up with like if A=0 or A=2 or A=4 or A=6 or A=8 or A=10 or A=12 x.x

Or smaller stuff but still complicated x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 11:09:52 am
Something I've been curious about all of a suddent is: if Axe Parser had Line( support, could it be somewhat fast enough for someone with 3D experience to write a raycasting engine?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 01:51:11 pm
*gasp* :O

The possibilities are endless.
Title: Re: Features Wishlist
Post by: Quigibo on April 13, 2010, 03:22:51 pm
Raycasting wouldn't use the Line() command unless all the walls are pitch black, and then you can't see anything.  The actual algorithm is very complicated and although it could be made with Axe, it would either be too slow or very minimal.  However, by using Line() Axe is definitely fast enough for some realtime 3D wireframe renderings.

I won't promise anything, but it could be a possibility that I might add automated ray casting and mode 9 support in a very far future version.  I have no idea how it would work though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 04:33:49 pm
Aaah ok I see. I was not sure if raycasting used multiple sets of Line(-alike commands. For wireframe 3D I think it could be fast indeed, unless the models had an extreme amount of polygons. Maybe something like Space Dementia 1 for 68K calcs?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 07:46:56 pm
OH MY GOD...

AUTOMATIC RAYCASTING?
MODE 9 SUPPORT?

:D
:D
:D

GOD, I LOVE YOU, QUIGIBO.

nohomo
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 07:57:41 pm
Uhm, I missed the Mode 9 part. What would it be? I know about Mode 7 but not 9

I assume it would make both Axe parser and the compiled programs considerably larger, right, tho (if raycasting or the like were added)?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 08:00:40 pm
Yes, I'm sure. If the options were activated.
But, if the compressed-run mode feature is put in...

:D
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:13:51 pm
raycasting isn't used for polygons
ray casting is where you have a grid, and every cell on the grid either has a wall, or lacks a wall (it can be extended to give different heights to the walls).  Now, take a line with 96 evenly spaced segments (1 for each pixel the lcd is wide), and a point behind the line (the eye).  Draw a line from the eye, through the center of each of the 96 segments, and see where the closest intersection of that line and a cell that contains a wall is.  Now, from that distance, you calculate how tall the wall should look, and draw that in the vertical center of the screen.  Checking the ray for collisions is complicated, since you can't just test every time the line travels one unit (you could miss walls that way if the unit mark happens to not be in that cell), so you have to use DDA (digital differential analysis), where you check for a hit every time the x or y position of the line is a whole number.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:17:04 pm
Oh I didn't meant it was used for polygons, I was confirming that Line would be very useful to do actual polygon 3D routines.

For raycasting, if the map is stored in some sort of array/matrix/list/tilemap, can't you use some sort of tile-based collision detection instead?
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:18:33 pm
like what?  that's basically what DAA is.  Maybe if I ever feel like learning Axe I could port my 3D engine.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:19:30 pm
really? For some reasons, I gathered something totally different from your explanation, simply because you called it DDA instead of "tile-based collision detection" x.x. I am so used to hearing the later.
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:22:09 pm
http://www.student.kuleuven.be/~m0216922/CG/raycasting.html
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:24:47 pm
I kinda wish they would use similar game making vocabulary for every type of game. We would get less confused about what is what from a game to another and not mistake one thing in particular as two different things.
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 07:20:49 pm
I updated my to-do list.  I've pretty much finished everything I thought would be "essential" for the beta release, so I think I might just halt the new commands for a little bit and just focus on writing the user's guide.  Sunday I plan to release the next version: 0.2.0 but this time, it won't just be on omnimaga.  I'll be releasing it on ticalc.org as well as several other calculator forums to expand interest in the project.  So this will be a very big release.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 07:40:56 pm
Unless you are alerady doing so in reply to my other post asking so in the other thread, could you clarify how the pic absorbing feature would operate? Would it let us split 8x8 pics into individual tiles, sorted from left to right and top to bottom, compiled inside the program as data? That would be nice.
Title: Re: Features Wishlist
Post by: Raylin on April 15, 2010, 07:49:21 pm
That on top of the different dimensions for sprites and the DrawShape command.

(I'm going to keep bugging you about that.)
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 07:53:13 pm
It will work like this:

[Pic1]->Pic00 Will read the pic from RAM and copy it into the program.  Stores the pointer to the start of the data into "Pic00"

You can even chain it with regular hex:

[01AF3BPic1B10000]

The pics are NOT stored as a bunch of 8x8 sprites.  Its an array of 12x63 bytes.
Title: Re: Features Wishlist
Post by: Raylin on April 15, 2010, 07:55:05 pm
What's the command?
Or will it be something the Parser itself picks up?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 08:41:28 pm
It will work like this:

[Pic1]->Pic00 Will read the pic from RAM and copy it into the program.  Stores the pointer to the start of the data into "Pic00"

You can even chain it with regular hex:

[01AF3BPic1B10000]

The pics are NOT stored as a bunch of 8x8 sprites.  Its an array of 12x63 bytes.
Aaah ok.

In future versions, will there be a command to store the pics as bunches of 8x8 sprites? It might come handy since it would be considerably faster than any other way
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 09:42:23 pm
Actually, that would be kind of useful.  So most likely, yes. I guess that's what r is for :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 10:04:48 pm
YAY! Because personally it would be much faster doing so.

Plus, as several people here are used to Omnicalc, xLIB, CODEX and Celtic, we're also used to displaying sprites stored in pics, one after each others. It's so much easier to edit
Title: Re: Features Wishlist
Post by: _player1537 on April 16, 2010, 06:54:51 am
I'm not sure if this has been asked, but what about a line( routine, will we have that soon?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 16, 2010, 09:58:40 am
Yeah it's coming soon it seems. There will also be circles and rectangles, according to the updated first post
Title: Re: Features Wishlist
Post by: _player1537 on April 16, 2010, 04:34:11 pm
woops, forgot about the first post being updated
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 16, 2010, 06:32:16 pm
no problem :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 05:51:56 pm
Question:

How would somebody go about copying the entire content from an archived appvar/program into another, or parts of it? If for example, someone has a game with a lot of map data and it is spread between 3 appvars of about 7 KB each, currently, he has to use the Unarchive and Archive commands. However, in some cases, there would be a lot of archiving going on and loads of archiving means loads of defragmenting needed, wearing out both the player's set of batteries very fast and their Flash ROM as well (which happened to people, before, such as our last year TI-BASIC contest winner, Drummist).

If it is impossible, I wonder if it would be possible to implement a command that allows you to read bytes from an appvar stored in archive, or at least, something that can copy an entire program from archive into RAM?

For the later, you could ask Iambian if you could use XCOPY source for it if you need someone's routine. It may be useful in the future for people who wants to make slightly larger games (in terms of data, not executable code), but don't want to hinder the user with endless amounts of GarbageCollect messages (and risks of causing the game to crash/exit in improper ways due to him accidentally choosing No). Some of my old BASIC games got some bad reviews because of those.

Quote from: http://web.archive.org/web/20061012201308/www.ticalc.org/archives/files/fileinfo/338/33829.html
[...] Also, since the BASIC game engine is too big to fit in ram, this means that there is quite a lot of archiving going on as you play... so be prepared for garbage collects every six minutes or so.

[...]

Overall: 12/40.
Perhaps on a Silver calculator, this game would be playable, but on an original edition it's just too frustrating to complete, unless you're the kind of person who enjoys spending money on batteries to see them drained by endless garbage collects. If it wasn't for this one point, this game would probably rate “Reign of Legends: at least a 30/40.


There is an ASM RPG called Final Fantasy v1.198 that won't fit in RAM and is split in multiple archived files. It copies the needed data in temporary RAM rather than unarchiving it. I think Desolate requires the data to be in RAM all the time, though.
Title: Re: Features Wishlist
Post by: Raylin on April 23, 2010, 06:10:08 pm
Perhaps that should be a new feature. :D
Title: Re: Features Wishlist
Post by: Quigibo on April 23, 2010, 10:24:50 pm
Reading from archive isn't really that tricky, but it would certainly make the code a lot bigger and require new commands.  You can't just use a pointer; you have to switch pages, store data from that page to a register (temporary variable), switch pages back to the normal RAM, and then save the register into the RAM page at the desired location.  You have to do this for EACH byte or two byte combination you read which means its a lot slower than reading directly from ram.

I think it would really complicate things a lot and it would be about the same speed to unarchive it anyway as it would be to read all of the bytes from archive, although it would definitely be faster for individual bytes.  Putting the calculator in 15MHz mode during archive/unarchives is generally fast enough.  Reading a 6000 byte map by unarchiving would take less than a second to unarchive and especially for RPGs, a little loading bar once in a while isn't that big of a deal since it would never be in the middle of game play.  Just keep the data in ram until its no longer needed.

By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 10:37:55 pm
Well, my biggest issue about unarchiving the map data is that we have to re-archive it after usage. If in the RPG two areas that are linked together are in different files (for example a large dungeon where floor 1 through 4 would be in DARKDNG1.8xk and floor 5 through 7 in DARKDNG2.8xk), then when going back and forth through these areas, there will be a lot of archiving, unarchiving, archiving, unarchiving, archiving, etc, going on, and the player will be annoyed with Garbage Collect messages every 6 minutes or so (especially on a regular 83+ that only has 164 KB of archive). I don't mind archiving speed. Just one little appvar being archived will not even take a second on a 83+. The real issue is the constant Garbage Collecting messages that can take over one minute each.

Here's another scenario:

Player decides that once map finished loading, he needs to go in the menu. He starts holding down ENTER

GarbageCollect?
1: No
2: Yes

What does happen then?

Anyway just a feature suggestions, it's really up to you. Now that I look at your first paragraph, it seems like it may be more trouble than anything else x.x

I could maybe just have a warning during loading saying
"LOADING MAP
 PLEASE DO NOT HOLD ENTER!
 IF A GARBAGE COLLECT
 MESSAGE OCCURS, CHOOSE YES!
 ELSE THE GAME MAY CRASH!"

Or put it in readme altough people may miss it
Quote
By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.
Thanks for the trick. Question, though: when it comes time to exiting, do we need to run special commands to delete temporary data before unarchiving the program again? (so there's enough user RAM to unarchive it)
Title: Re: Features Wishlist
Post by: Quigibo on April 23, 2010, 10:42:56 pm
I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 10:56:33 pm
I am pretty sure if you archive stuff and there's not enough big enough free sectors available in archive that the GC message will pop up (providing you use the TI-OS routines/ROMcalls to archive/unarchive). The TI-83 Plus guidebook actually explains a bit about sectors. I am pretty sure BrandonW could maybe confirm this but he seems inactive lately
Title: Re: Features Wishlist
Post by: mapar007 on April 24, 2010, 04:49:37 am
I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.

I think you can trigger them in a call to _Arc_unarc, but I'm not sure. Anyway, I don't think the OS does 'sneaky' GC without warnings.
Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 09:30:05 pm
I'd like to ask about library files now.

First of all, I think they will be handled slightly differently than regular source files.  Their header will be in lowercase to distinguish them, and they won't show up on the compiling list to reduce clutter since they're never compiled standalone anyway.  The libraries will basically just be a big list of subroutines that can be called from the main program.

Next thing is how to reduce naming conflicts since the labels are only 2 letters.  Although I plan to eventually allow labels up to 8 letters, right now there is a high chance for duplicate labels, especially if there are multiple library files included in the main program.  To avoid this, I am thinking of having a prefix for the subroutines like this: sub(prgmMYLIB,DW) will call the subroutine "DW" from the "prgmMYLIB" library.

The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.  That means if a library has 25 different routines, but you're only using 5 of them, only the 5 that you use get put into the program.  There is going to have to be some slight restrictions to the subroutines however, mostly, they cannot allocate data or use regular goto's and sub's, only library subs (including itself).

I haven't written any of this yet, I want to get an opinion first.  Does anyone have any other ideas?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 24, 2010, 09:50:48 pm
mhmm, I'm a bit confused x.x I am not sure if I understand the concept well. What would be the benefit of libraries only including the sub routines you use in your compiled code when compiling a program normally alerady do this?

For example, if I have prgmA and it only contains .B in the code, the compiled version will be 13 bytes large (no-stub). In other words, stuff that is not used is not included, right?

I'm not sure if I get the concept x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 09:58:09 pm
I am also a bit confused about what you're asking about.  A library is just a list of subroutines.  Like if somebody makes a tile mapper or physics engine or something, then you can call those routines from your main program.  Like if your program was prgmA and you said sub(prgmTM,D) this would call subroutine D (lets say that's a drawing command for the tile mapper) from the tile mapper library.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 24, 2010, 10:10:39 pm
mhmm. Yeah I think I get it about the libraries. I guess they're like subroutines, but external?

I got stuck on the part saying this, though:

Quote
The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.

Since in the case of internal sub-routines, if there's a routine I don't need I just have to delete it altogether (and back it up elsewhere for later use), so there wouldn't be any advantage between using external and internal ones.

If it is unclear, I will probably move on for now, though, because it looks like there's something there that is way beyond my capacities of learning (of the moment) that I may be best waiting later to try to understand (at this point it will most likely be lost among 3 or 4 new pages of posts x.x)

Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 11:46:05 pm
Exactly.  But if someone writes a library, odds are you aren't going to use every single command in that library.  And its a huge hassle to keep track of which ones you use and which ones you don't need.  And what if you delete one but it turns out you need it later on?  In addition, its more organized to have the programs and subroutines in separate files.  Also, it would be a real annoyance to have to do a [Rcl] with someone's code into your main program.  And yet another thing!  You might have several source files that use the same libraries so it could potentially save space and make source files even smaller.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 25, 2010, 01:18:53 am
oh right I guess in terms of code management it might be better to have them external then.
Title: Re: Features Wishlist
Post by: Builderboy on April 25, 2010, 02:39:39 am
Hmmmm Using the program name might be good, although it would be cool to have some sort of Method overwriting like in higher languages :D that way if you are just using external subs to make cleaner code it wont be adding all this extra memory into the source

oh and what about the little E for accessing bits?  Like:

AE2 would access the 2nd bit of A, and you could store the same way?  It makes a bit of sense, since E is powers of 10 in Basic, and Powers of 2 in Axe ;D
Title: Re: Features Wishlist
Post by: calc84maniac on April 25, 2010, 03:41:59 pm
I really don't see why the "get/reset/set bit" commands should only be for constants, because that functionality is already available with the "and", "or", and "xor" commands. It would be incredibly useful to allow getting the Xth bit from the number with optimized ASM rather than having to use a For loop every time. Of course, using constants should still be auto-optimized like you were planning.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 01:19:05 am
Question, in the future, will there be a command to draw white lines?

(I guess an alternative for games where the entire gameplay screen is black could be to XOR the graph buffer, draw the lines then XOR it again, though :P)
Title: Re: Features Wishlist
Post by: Builderboy on April 26, 2010, 01:45:13 am
Lol, that would be an interesting workaround ;D I think there should be an alternitive 5th argument like in Basic that allows you to draw different 'Colors'

0:White
1:Black
2:Invert

and maybe others depending how greyscale is planning to be implemented.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 01:51:11 am
mhmm invert might be cool too, actually
Title: Re: Features Wishlist
Post by: Quigibo on April 26, 2010, 02:01:35 am
Yeah, that's actually exactly what I'm planning.  That's how the MOS routine works, so that would make the routines compatible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 02:22:20 am
Cool ^^

And good thing I just checked the first post, I was gonna ask if circles/squares were for next release (or close) x.x

One question, though:  what do you mean by binary support? Do you mean individual bit manipulation?

I'm also glad you're adding tilemap absorbing support. It will make it MUCH easier to insert tiles in a game.
Title: Re: Features Wishlist
Post by: Builderboy on April 26, 2010, 10:58:55 pm
Seeding the random number generator! ;D Simple but potentially useful

Seed->Rand
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 11:38:49 pm
lol. Well we could do this in BASIC, kinda :P

Title: Re: Features Wishlist
Post by: Quigibo on April 26, 2010, 11:47:37 pm
Binary support means all of the above.  Individual bit operations as well as a new number representation.

The only problem with tile mapping though is that you have to add the entire picture even if you only add a couple tiles.  Also what do I do about the last row of tiles?  Since pic vars are only 96x63, do I just assume the bottom bits are all zeros or do I ignore that whole row of sprites?

Random seed generation is not possible like basic becasue the random numbers have a real randomness factor to them that prevents any predictability with a given seed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 27, 2010, 12:32:32 am
I would just totally disregard the last row of tiles. It's gonna cause more problems than anything else anyway since so few ppl will use xLIB to store pics (which allows the usage of the 64th row). When trying to display a sprite from last row using a pic that only has 63 rows stored results in garbage at the bottom of it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 04:43:57 am
Question: In future versions of Axe Parser, will it be possible to import archived pics/tilepics?
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 08:01:50 am
I have a suggestion: could Horizontal be extended to allow scrolling 1 byte at a time instead of just 1 bit? I would think such code would be more optimized than 8 single-scrolls.
Title: Re: Features Wishlist
Post by: calc84maniac on May 04, 2010, 08:14:04 am
I have a suggestion: could Horizontal be extended to allow scrolling 1 byte at a time instead of just 1 bit? I would think such code would be more optimized than 8 single-scrolls.
I think that can be done with tricky use of the conj( operator.

conj(L6+1,L6,767 should scroll the screen left one byte, I think.

Quigibo, when I tried optimizations like this before, I noticed that there is no way to generate a LDDR to copy from a lower to a higher overlapping area.

Edit: Oops, changed to L6
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 11:30:37 am
I didn't know Horizontal scrolled only 1 bit at a time? o.o

In Axe Tunnel, it always seemed to scroll 1 pixel every frame for me

EDIT: Confirmed that Horizontal and Vertical both scrolls pixel by pixel.
Title: Re: Features Wishlist
Post by: Quigibo on May 04, 2010, 12:21:14 pm
Hmmm... that might be useful calc84, I think I will add conj()r to copy data from one place to another backwards where the bytes at the end get copied first and bytes at the beginning get copied last.

Not sure if I will add 8 pixel scrolling.  You can do it with other commands like calc84 mentioned, and usually when you have 8x8 tiles without smooth scrolling, you redraw them on the screen every frame anyway.

Scroll right by 8:
conj(L6+1,L6,767)
Scroll left by 8:
conj(L6+766,L6+767,767)r (not in 0.2.2)
Scroll up by 8:
conj(L6+96,L6,672)
Scroll down by 8:
conj(L6+672,L6+767,672)r (not in 0.2.2)

Not 100% sure if these are correct, but this is the strategy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 12:25:26 pm
Oh wait I forgot one bit for horizontal is an entire pixel... disregard my comment, then x.x

Do you think importing tilemaps/pictures from archive will be available in the future?
Title: Re: Features Wishlist
Post by: Quigibo on May 04, 2010, 12:30:20 pm
Yes, definitely.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 02:03:46 pm
Are you running down the Features list in order?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 02:17:42 pm
Glad to hear ^^

Oh and I also forgot, for Text(, will it eventually be possible to do something like

Text(X,Y,"HELLO"

(as for now this gives a ERR:BAD SYMBOL)

? Because it seems like a major PITA to have to store everything in memory to be able to display menu choices and if I decide to store all the text at one pointer, I still can't figure out how to display only parts of a string. ???
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 02:20:42 pm
^++
Agreed and seconded.
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 05:26:56 pm
Could the Pxl and Point commands be extended for drawing to the back-buffer? Could be useful for grey-scale.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:29:52 pm
mhmm sounds like a good idea actually. Maybe Pxl-On(X,Y)r[/sub] ?

That said I think he's planning to implement automated GS in the future, but your idea might be useful when we want to update individual parts of the screen like when a door is opened.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 05:47:17 pm
Pt-On(X,Y,PIC)r
Pxl-On(X,Y)r

AWESOMENESS!

The function of said commands can vary but I like the drawing to the back buffer idea.
Perhaps for greyscale?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:49:06 pm
yeah grayscale is what I thought

Used with Dispgraphr

Btw dispgraphr can also be used for sprite animation (you need to use DS<())
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 05:51:45 pm
Yeah.
That sounds awesome.

Also, I was looking in the PRGM menu for once.
Did you know there was a OpenLib() command and an ExecLib command?

Perhaps these could be used for the supposed Axe libraries?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:53:12 pm
these are 84+ only. Using them will cause the program to no longer be compatible with the calc most people use: the 83+
Title: Re: Features Wishlist
Post by: SirCmpwn on May 04, 2010, 06:11:08 pm
DJ is right.  The only library I know of that uses them right now is USB8X, which only works on models with a USB port anyway.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 06:17:52 pm
I understand.

Ah well.
Back to waiting for that geometry drawing.
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 06:21:48 pm
Yeah, nobody ever really made use of that feature.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 06:22:26 pm
What is it used for anyway?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 07:34:31 pm
This page seems to have some stuff related to those commands: http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:9B80

Title: Re: Features Wishlist
Post by: calcdude84se on May 05, 2010, 07:43:26 am
Actually, extension of all drawing functions to the back-buffer would be nice...
Title: Re: Features Wishlist
Post by: Quigibo on May 05, 2010, 02:06:07 pm
Yeah, I'm definitely going to be working on the grayscale commands this version.  What that means, is that every drawing command will eventually be able to draw to either buffer.  So if you want to draw a grayscale sprite, you first draw the black part to the first buffer and then the gray part to the second buffer.  Like this:

:Pt-On(X,Y,Pic1)
:Pt-On(X,Y,Pic2)r

However, just to save space, I am going to have the grayscale drawing and the regular drawing use the same routine, but just jump into the code with a different buffer.  This will unfortunately make the current drawing routines about 5 bytes larger even when you don't use grayscale, but it makes it much smaller when you do need it.  BUT, I might also share all the different sprite drawing routines with each other so that might actually reduce the size if you use different drawing methods in the same program.  I'm not 100% sure what is going to happen, but I will try to make them take the least amount of space possible.

I am also going to test a very limited and special case of look-ahead parsing for pointers.  I am estimating it will reduce executable size by about 2-5% in programs that use pointers frequently.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 05, 2010, 02:07:31 pm
would these new grayscale commands me kinda automated?

Also I think there may be a problem with tile importing. I'll try posting the code later if I can't seems to figure out if I did something wrong. I am fairly certain I did everything right. (tile data appears to be off completly) - EDIT: nvm there was a typo in the code x.x
Title: Re: Features Wishlist
Post by: Runer112 on May 05, 2010, 10:01:42 pm
I noticed you added conversion from binary to integer with 0.2.2, which is getting closer to bit manipulation, but are you planning to release more direct bit manipulation commands? Such as commands that get or set the nth bit of a byte? If not just say so, so I'll know to just make commands for that myself.
Title: Re: Features Wishlist
Post by: Quigibo on May 06, 2010, 03:22:23 am
I'll be adding it soon, I'm still looking for a good token for it...

DJ, I was at first thinking of making the revised drawing commands draw to both buffers, but I think it will be more flexible to do it separately.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 06, 2010, 08:17:17 pm
Mhmm I see, I guess it might be best maybe, and more flexible for the programmer, too. It's good to give him freedom, otherwise the command may not be used very much.
Title: Re: Features Wishlist
Post by: ztrumpet on May 06, 2010, 08:18:32 pm
I'm glad you're adding in both Asm-related and Basic-related commands.  Axe is going to be the best of both worlds! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 10, 2010, 02:42:42 pm
Not much of a feature addition request, more of a feature preservation request:

At the moment, Axe Parser compiled programs will run on both 6 and 15 MHz calcs at once. Even if you use the Full command, your program will still run on a 6 MHz calc fine. It will just run at different speed between each calc speeds.

I would like this cross-compatibility to not be removed in future versions of Axe, else it will suck to be forced to update two versions of your programs all the time because one crashes on 15 MHz calcs and the other crashes on 6 MHz calcs.

Same goes for TI-Nspire and the 48KB RAM TI-84+ calcs, altough I think compatibility with those was planned to be kept.
Title: Re: Features Wishlist
Post by: Raylin on May 10, 2010, 03:21:48 pm
The only thing I would want is the ability to have different sprite sizes.
Title: Re: Features Wishlist
Post by: Galandros on May 13, 2010, 05:11:36 pm
Flags support in Axe Parser could bring advantages in any circumstance? In assembly the use of iy is expensive, so I doubt it is advantageous.

I wish we had a small font TI-BASIC editor on calculator...

Axe Parser syntax takes some time to get used too because of using the TI-BASIC tokens and tokens are not always very descriptive. I imagine it is getting harder to choose the tokens.
Title: Re: Features Wishlist
Post by: calcdude84se on May 13, 2010, 05:17:29 pm
I wish we had a small font TI-BASIC editor on calculator...
I'm not alone, then. It would especially useful for things like ASM on-calc (beside Axe), since lines can get a bit long.
Edit: Sorry for the off-topic post. Here's a feature wish: it would be nice to be able to copy data from Archive to RAM, since Unarchiving and Archiving again puts wear and tear on the RAM.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:18:40 pm
I imagine it is getting harder to choose the tokens.
It is, when I suggest him new features via chat, he often comes up with "I would like to add this, but I would need to figure out a good token to use :P"
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 05:20:14 pm
Can we have a sign command that would return the sign of a number.  Like this:
sign -9 = -1
sign 9 = 1
sign -9001 = -1
sign 9001 = 1
sign 0 = 0
You could use the [2nd] [sin] button.

Is it possible to easily do this in Asm, or would it be the same as ( # > 0 ) - ( # < 0 ) ?
Title: Re: Features Wishlist
Post by: calcdude84se on May 13, 2010, 05:22:33 pm
just read the high bit, which carries the sign, and then differentiate between positive and zero.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:33:18 pm
I can't wait until Axe Parser supports reading/writing to individual bits
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 05:37:52 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:53:00 pm
Yeah I know, I checked WikiTI for most of the addresses. Not sure how it would help for binary stuff, tho :P
Title: Re: Features Wishlist
Post by: Builderboy on May 13, 2010, 08:54:07 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)

Bits not bytes ;) Yeah I cant wait for this either :) It will make a few things quite usefull.
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 09:00:57 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)

Bits not bytes ;) Yeah I cant wait for this either :) It will make a few things quite usefull.
Gah, my bad. :)  Now that I've read 'bits', I really want this to happen too.  It'll be fun to manipulate stuff in binary! ;D

Technically, you could use calculations to do this with the 'pixel' commands, but it would be a lot of useless calculations. ;D
Title: Re: Features Wishlist
Post by: Builderboy on May 13, 2010, 09:07:00 pm
You can also do it with some loops or lookuptables coupled with AND and OR commands, but its a hassle :P
Title: Re: Features Wishlist
Post by: _player1537 on May 13, 2010, 09:45:43 pm
I use 'and 1' or any other number to do this atm.  iirc there is an asm command like 'set 4,(1337)' or something like that.
Title: Re: Features Wishlist
Post by: Quigibo on May 14, 2010, 12:49:09 am
Just curious, would it be useful to set and get exact bits in the 2 byte number?  Like "get the 11th bit" and "set the 2nd bit" or is it more useful to have the Nth bit with N being variable?  Unfortunately, these routines with variable bits are kinda big.  Big enough where they wouldn't be inline like the constant bit checking and I would make it a subroutine to save space.

I might be able to do both, but I'll have to come up with some clever syntax.

By the way, I just coined a new term: "Axe Hax" for clever exploits of Axe commands. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 14, 2010, 01:07:58 am
mhmm not sure what you mean x.x sorry :(
Title: Re: Features Wishlist
Post by: calc84maniac on May 14, 2010, 01:44:10 am
You could optimize the AND/OR that will reset/set a single bit to a simple 2-byte RES/SET opcode. That way you won't even need extra tokens for constant bit commands.
Title: Re: Features Wishlist
Post by: _player1537 on May 14, 2010, 04:56:12 pm
hmm, could this even be remotly possible:
having a way to change the macro ourselves, ie I like using the "And/Or/Xor" commands bitwise.  I personally always use them this way and use them a lot like this.  If you compiled the new phoenix/raven game I'm making with the new version it would completly fail when running it. 
Title: Re: Features Wishlist
Post by: Quigibo on May 14, 2010, 07:44:45 pm
Those commands are still there, but they've just changed syntax.  It makes the code more readable too because now you're using and/or/xor as single character operators just like addition, subtraction, multiplication, and the others.
Title: Re: Features Wishlist
Post by: _player1537 on May 14, 2010, 10:25:50 pm
sorry, but what do you mean by single character operators?  and the main reason I'd want to change the syntax is because otherwise I'd have to change a ton of source for my program, and its harder to get to the new and/or/xor characters
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 12:16:59 am
By the way, the standard and/or/xor still work as bitwise functions as long as the numbers you're dealing with are both single bytes.  Only the double byte numbers require the new syntax.

What I meant by single characters is that it is more readable to write: "A*B" than it is to do "A times B"
Similarly, "A&B" is easier to read than "A and B" (the ampersand is not the actual symbol, I'm just demonstrating)
Title: Re: Features Wishlist
Post by: Raylin on May 15, 2010, 10:18:19 pm
Just a thought:

IIRC, Axe compiles all the code and skips all the data on the first pass. Then, on the second pass, it appends all the data to the end of the compiled program, creating space as it sees fit. What if these commands were made:

FnOn -  Activate BASIC command mode.
FnOff - Deactivate BASIC command mode.

Here's where my idea comes in.
What if Axe made three passes? The first pass would check to see if there are any FnOn or FnOff commands in the program, skipping everything else. The second and third passes would be the normal Axe compilation.

For example:

First Pass:
Check for any FnOn and FnOff commands. If so, save that line and skip over all code until the end of the program is reached or the FnOff command is reached.

Second Pass:
Compile programs.

Third Pass:
Append data.

So, penultimately, the program code is the ASM version of this.

Code: [Select]
:Asm(prgmAXE1
:<TI-BASIC code>
:Asm(prgmAXE2
 

tl;dr: Axe should compile subroutines and insert them into a large ASM program if BASIC commands are possible.

Of course, all of this is useless if Quigibo figures out a way to reuse commands for different purposes.
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 10:43:08 pm
I doubt I'm going to have a "Basic Mode".  Its more likely that BASIC programs will be token data just like strings are text data and sprites are hex data and then there will be a command to execute that data.

fnOn and fnOff are the enable and disable interrupts commands since there is also the fnInt command and they just go together so perfectly for this.
Title: Re: Features Wishlist
Post by: Raylin on May 15, 2010, 10:48:10 pm
Interesting.
How will hybrid programs be handled?
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 10:49:31 pm
I don't even know if its possible yet, so we'll see what happens when I get to that.
Title: Re: Features Wishlist
Post by: Raylin on May 16, 2010, 10:27:23 pm
Also...

The idea of custom fonts was brought up. [Personally, I think it would be very memory-intensive.]

This as well as the idea of sprite rotation by any angle. [I think that was brought up before...]

Also, SortA(), SortA()r, SortD(), SortD()r.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 18, 2010, 08:06:34 pm
Sort command would be nice

Something like

SortA(Pointer,Bytes

For example, if you did SortA(L1,27), it would sort the first 27 bytes of pointer L1 from lowest to highest number.
Title: Re: Features Wishlist
Post by: Quigibo on May 19, 2010, 12:00:19 am
Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 19, 2010, 12:06:57 am
Wow that's quite fast. The TI-BASIC Sort( commands takes two seconds to sort 100 elements on a regular 83+ and one second on a 83+SE/84+

And glad to see you're planning on adding Ans support. It will be very useful for people who make Axe games divided into multiple programs or libs for BASIC programmers.

Keep up the good work!

Btw next version will be 2 pages, right? I noticed the previous version was getting pretty close
Title: Re: Features Wishlist
Post by: Quigibo on May 19, 2010, 12:19:02 am
Don't know yet, but I haven't started optimizing the parser itself, so I think I can make it small enough to fit on one page, at least for the next couple updates.  Probably 0.3 will be the time when I switch to a 2 page app.  However, the parser will not be larger than 2 pages at any point.  If I want to add a suite of helper programs, I will add it as a separate optional app.
Title: Re: Features Wishlist
Post by: Raylin on May 19, 2010, 06:13:41 am
Strings?
You plan on putting restrictions of the static pointers?
Or are you making entirely new variables?
Title: Re: Features Wishlist
Post by: calcdude84se on May 19, 2010, 07:24:02 am
The TI-Basic variables, if I understand it correctly
Title: Re: Features Wishlist
Post by: Raylin on May 19, 2010, 07:34:50 am
Yeah, but the static pointers already take up the namespace for the variables.
How will he implement them?
Title: Re: Features Wishlist
Post by: calcdude84se on May 19, 2010, 07:42:22 am
Probably the same way appvars are: with storage into strings.
You'll have to ask quigibo for how he actually plans to do it, but it seems you'd have something like:
"Str8"->Str1
If GetCalc(Str1)->X
{X-2}r->S
X+S-1->E
For(A,X,E
Disp {A}->Frac
End
End
Disp i
Which would display Str8's contents on the homescreen, or nothing if non-existent/archived.
Title: Re: Features Wishlist
Post by: ztrumpet on May 19, 2010, 07:20:13 pm
Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.
Awesome!  I'm going to like these new commands. ;D

calcdude: Excellent visual. :D
Title: Re: Features Wishlist
Post by: Raylin on May 23, 2010, 11:15:15 am
-Linking
-SortA(),SortD()
-Geometry drawing (circles, squares, etc.)
-Interrupts
-xLib DRAWSHAPE
-Application Compiling
-Sprite sizes larger than 8x8
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 07:58:47 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.
Title: Re: Features Wishlist
Post by: ztrumpet on May 25, 2010, 08:02:09 pm
How will interrupts be handled in Axe?  It seems they would be very complex...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 08:04:58 pm
Interrupts would be nice for automated stuff, such as moving enemies, but I wonder if it wouldn't be a bit hard to work with and easy to mess things up?
Title: Re: Features Wishlist
Post by: Raylin on May 25, 2010, 08:19:39 pm
Actually, it could be really easy.

im 2 sets the calculator in a mode to accept a different interrupt routine.
Since Axe can already edit and use programs themselves, couldn't Quigibo just make a command to look for and run a custom program? From there, the compiler can absorb that custom routine as part of the entire program.

I think...
Title: Re: Features Wishlist
Post by: Quigibo on May 25, 2010, 11:09:38 pm
Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 11:23:50 pm
Mhmm, doesn't sound like a good deal x.x

Personally I don't use L1 that much but I imagine I will when I work on stuff with arrays and the like
Title: Re: Features Wishlist
Post by: Eeems on May 26, 2010, 12:13:38 am
D: well...i guess i could give up part of L1 for interupts...ill just have to learn how to compress my data.
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 12:21:52 am
It will only be taken up when you turn interrupts on though right?  So those who dont use them wont have to give up or mem :3
Title: Re: Features Wishlist
Post by: calcdude84se on May 26, 2010, 07:22:30 am
A custom interrupt sounds nice. That's obviously in im 2. Will the choices for interrupts in a program be either im 1 or im 2, or will you be able to disable them entirely or chain the standard interrupt to the end of the custom one?
Or, to put it more simply, how many choices do you get?
Title: Re: Features Wishlist
Post by: ztrumpet on May 26, 2010, 07:56:10 am
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Title: Re: Features Wishlist
Post by: TIfanx1999 on May 26, 2010, 10:20:54 am
Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.
That sounds really cool actually! =D That'll be fun to play with once you get around to implementing it. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 12:22:03 pm
If interrupts are implemented, I think the command index should be updated well before with enough explanation about what to do and what to not do, in details and maybe an example of what it could be used for, since it seems a bit complicated to use and might cause many people to accidentally cause a RAM clear more.

Also, I heard somewhere that interrupt speed varies when batteries are lower. Is it true?
Title: Re: Features Wishlist
Post by: Galandros on May 26, 2010, 01:38:35 pm
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Not that easy because the vector table has to be aligned in memory like every byte between $9900 and $99FF. And I think it is 257 bytes for some strange reason.
Title: Re: Features Wishlist
Post by: ztrumpet on May 26, 2010, 05:16:13 pm
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Not that easy because the vector table has to be aligned in memory like every byte between $9900 and $99FF. And I think it is 257 bytes for some strange reason.
Ah, okay. :)  How does this work, because wouldn't part of the program normally be there?
Thanks! :D
Title: Re: Features Wishlist
Post by: calcdude84se on May 26, 2010, 05:51:04 pm
yeah, it could be, but it would have to 256-byte aligned, like Galandros said. You're looking at a 257-513 byte increase in program size. The table would be where he said or between $9A00 and $9B00, $9B00 and $9C00, or so on.
It's 257 bytes because the i register, or the interrupt vector, serves as the high byte of an address where the lower byte is essentially random. (It has some structure, documented in AsmIn28, but I can't remember it). Because the read address could be anywhere between $xx00 and $xxFF, you need another byte to complete the two bytes it reads in case it reads from $xxFF.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 06:39:20 pm
Interrupts + SinReg() = BGM music?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 08:19:32 pm
is there a way to control the speed at which an interrupt is executed compared to the rest of the program? Otherwise I think sound might slow the game down way too much
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 09:25:07 pm
I would think not...
I don't know for sure.

In Axe, the interrupt's speed may or may not be affected by the Full command.

[ontopic]Geometry drawing (read: xLIB DRAWSHAPE)[/ontopic]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 09:28:50 pm
Mhmm Raylin you suggested this command about 4 times already. I think it is becoming clear it is not in his priorities since all you need to do is use Line() (altough I think this is larger). By now it is in his planned features I am certain
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 09:52:38 pm
I am only pestering because of the lack of inverted rectangles (which I use extensively).
I need inverted rectangles.

They are like drugs to me.
I NEED THEM.

Perhaps a Line()r for inverse? Or is that reserved for the back-buffer?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 10:26:02 pm
I think this will be for the back-buffer.

For inverted rectangles, do you mean white outline with filled black?
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 10:31:19 pm
I mean, real(12,8).

That means draw a rectangle and invert all the pixels inside.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 10:44:13 pm
I think that could be possible to do through a routine like I posted in the other thread, but I would need to think about a way to make sure it's fast enough
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 10:45:27 pm
well for using filled rectangles, you could always have a subroutine that does a lot of pixelChanging in 2 For loops.  I think that might be a bit slower than an alternative however...  Let me see if i can come up with a quicker version.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 10:47:02 pm
Woot. Many thanks, Builderboy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 11:11:07 pm
Yeah pixel changing is what I thought about. However, thiswould be slow. If your rectangles were multiples of 8, you could just use a bunch of 8x8 sprites
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:12:01 pm
Alright here is a super fast filled inverting recangle thingy.  It does use a fair number or variables though, if thats a problem you can always use memory locations instead.  So here is the code (its rather long)

Code: [Select]
Lbl RC
A^8->O
255->M
While O
M/2->M
O-1->O
End
C^8->O
255->N
While O
N/2->N
O-1->O
End
A/2/2/2->A
C/2/2/2->C
For(F,B,D-1
F*12+L6->J
{J+A} xor M->{J+A}
{J+C} xor N->{J+C}
For(G,A+1,C
{J+G} xor 255->{J+G}
End
End
Return

Its very fast, but if you want something smaller, you can use this:

Code: [Select]
Lbl RC
For(F,A,C-1
For(G,B,D-1
Pxl-Change(F,G
End
End
Return

For both, the input is A,B for top left corner and C,D for bottom right corner.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 11:15:45 pm
Oh right forgot about L6 x.x

I guess that could work, as long as Raylin isn't running low on memory, because that looks like it will compile pretty large
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:19:27 pm
It compiles to about 350 bytes on my calc, so not too bad.  But like i said, if memory is absolutely a problem, you can go with the pixel change option, which is only 170 bytes.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:21:04 pm
By memory locations, you mean something like {L1+X} or...?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:26:04 pm
Right, you would replace all the F variables with {L5+1} for example (although i dont think you can use them in for loops D:) and then choose a different location for each variable
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:44:06 pm
Timings?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:47:02 pm
What are you asking?
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:55:13 pm
How long do the routines take?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:59:31 pm
no idea, and i dont have any accurate way to time them since axe doesnt have any timer support.  You would try them out and see though.  For the loop method (the second) it takes about a full second to invert the screen though, while the first one does it almost instantly.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 02:29:20 am
Feature wishlist (unless already planned:)

-A new Axe Parser APP option to get rid of the scrolling when an error is found and you press PRGM to see where is the error located. In other words, an "instant Goto" feature. (like in DoorCS)

That might come handy for large programs. Otherwise having to wait one minute until the scrolling is done everytime there is an error can get extremly annoying when debugging
Title: Re: Features Wishlist
Post by: Raylin on May 27, 2010, 07:14:00 am
^++
Agreed and seconded.

Instant Goto debugging feature FTW.
Title: Re: Features Wishlist
Post by: Galandros on May 27, 2010, 07:19:11 am
is there a way to control the speed at which an interrupt is executed compared to the rest of the program? Otherwise I think sound might slow the game down way too much
You can set the frequency at which the interrupt code is called. The slowest is 110 Hz (executed 110 times per second) , I think. But you can for example, increase a counter, save it and if is odd, exit the interrupt and goes back to normal code.
Title: Re: Features Wishlist
Post by: ztrumpet on May 27, 2010, 07:54:17 am
-A new Axe Parser APP option to get rid of the scrolling when an error is found and you press PRGM to see where is the error located. In other words, an "instant Goto" feature. (like in DoorCS)
I think this would be a great option as well. :D

Builderboy, that's an awesome routine! :)
Title: Re: Features Wishlist
Post by: calcdude84se on May 27, 2010, 07:58:59 am
I agree that instant goto should be added. Axe just keeps getting better...
Title: Re: Features Wishlist
Post by: SirCmpwn on May 27, 2010, 09:54:46 am
I want to request a feature...
How about jumping to the address in a variable?  Such as Goto {A}, for instance, would jump to A.
And you could have something like [LB]->A to store the address of Lbl LB to A.  This would be useful for jump tables, which is something I really want :)

Also, user access to the stack would be nice as well.  I would really like to be able to push a variable onto the stack, then pop it off later.
Title: Re: Features Wishlist
Post by: ztrumpet on May 27, 2010, 10:26:17 am
I like both of those ideas!  Can you add these in Quigibo? :D
Title: Re: Features Wishlist
Post by: Quigibo on May 27, 2010, 01:22:20 pm
I want to request a feature...
How about jumping to the address in a variable?  Such as Goto {A}, for instance, would jump to A.
And you could have something like [LB]->A to store the address of Lbl LB to A.  This would be useful for jump tables, which is something I really want :)

Also, user access to the stack would be nice as well.  I would really like to be able to push a variable onto the stack, then pop it off later.

Both of these things are features I am purposely not adding.  The variable goto isn't really used that much in regular assembly and has very limited application.  Its also very easy to screw things up by accidentally jumping to the wrong place and completely messing up the calculator.  I am trying to make it as safe to use as possible, and this is really just an unnecessary danger.  You can do this with a 2 byte assembly code if you really need it.

Pushing and popping into the stack has the same problem.  If you push a variable in a subroutine for instance, then the subroutine cannot return and the program crashes becasue it jumps to the wrong location.  Also, forgetting to pop can lead to stack overflows which are also not good.


The instant goto I'd like to add, but I don't even have the regular goto error working yet so I don't even know how it would be done.  I can do a similar "faking it" sort of thing where it just displays the error instead of going into the editor I guess.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 01:28:16 pm
If you don't use the editor, would that require you completly code an entire BASIC code (well... Axe) viewer like Builderboy did? If so, then I guess it might be best to disregard the instant goto feature or wait completly at the end of development before attempting at adding it (to make sure you have enough space left, assuming such thing would take a considerable amount of memory in the APP)
Title: Re: Features Wishlist
Post by: calcdude84se on May 27, 2010, 05:28:57 pm
I managed to come up with a feature request. The sprite routines seem somewhat incomplete, only including OR, XOR, and full clear followed by OR (Pt-On, Pt-Change, and Pt-Off, respectively).
My two suggestions are:
add something corresponding to AND, or add a command to use two layers specifying what is cleared followed by what is OR'd
The second, though somewhat less useful one is: Allow sprite commands (except for Pt-Change) to have an extra argument (not required) that would save what's about to be written over. Basically creates a back-copy for later restoration, presumably when the other sprite moves.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 11:15:53 pm
AND would be nice for sprite masking.


For the second one, do you mean so we don't have to redraw the entire screen (or everything surrounding moving sprites) when stuff moves and instead we just redisplay what was behind the sprite? It sounds like it could be a nice feature.
Title: Re: Features Wishlist
Post by: Quigibo on May 27, 2010, 11:55:00 pm
That's what backbuffers are for so you don't have to save it every time you draw the sprite.

The AND thing I guess I can see how it would be used... but then you have to use AND followed by an OR to actually get masking.  That's the same amount of steps as doing an OR followed by an XOR (another way of doing masking) so it doesn't really add anything new, just more convenience.  Also, I'm all out of tokens for that.

Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.

Title: Re: Features Wishlist
Post by: TIfanx1999 on May 27, 2010, 11:58:50 pm
Sounds great! Go for it! =D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 28, 2010, 12:09:46 am
That's what backbuffers are for so you don't have to save it every time you draw the sprite.
My concern was more about grayscale. Where on the backbuffer and buffer do you store the area your sprite is gonna walk on to redraw it later after the sprite moved, since both buffer and back buffer are entirely used for the grayscale?

That said it is not a big hurry, though. Seeing how fast

Quote
Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.
Sounds like a good deal. I think it's better to improve the parsing and stuff before adding too many other features, so that makes less features code to change later once you optimize. Also, this would make it less overhelming for people who will participate in the programming contest. Since the contest will most likely only last 3 and half a month (or 4), not having to change our code syntax everytime an Axe update comes out will be very appreciated. (people could just use an old Axe version if they don't want to update their code, but that slows down their development considerably)

Also seeing how much you worked on this despite school and stuff, I think if you want to take a break at one point, you deserve it a lot. :)
Title: Re: Features Wishlist
Post by: _player1537 on May 28, 2010, 12:04:45 pm
yay, this sounds nice I can't wait for app compiling and on-breaks (which I hope will include interupts in general)

666th post in this thread >:D
Title: Re: Features Wishlist
Post by: calcdude84se on May 31, 2010, 09:16:51 pm
true, though it's more troublesome for greyscale, as DJ said. OR followed by XOR? Hmm... never realized that. Will use.
Yeah, the command freeze is a good idea. And as always, keep up the good work!
Title: Re: Features Wishlist
Post by: nemo on June 03, 2010, 04:01:23 pm
will there ever be a way to invert all 64 pixels of a sprite? like if i had a white 8x8 sprite with a black border, and i wanted to change it into a black sprite with a white border, will that be implemented? i know i can use two for( loops to do it with pxl-change(, but i'm wondering if it may be implemented in the future
Title: Re: Features Wishlist
Post by: _player1537 on June 03, 2010, 04:07:56 pm
you can also do "pt-change(x,y,pic22)" with pic22 being [FFFFFFFFFFFFFFFF]  You don't have to use pic22, just an example.  I believe our dear friend made a routine that does this with out using another sprite, but it goes along the same lines of two for( loops...only different
Title: Re: Features Wishlist
Post by: Builderboy on June 03, 2010, 05:58:44 pm
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.
Title: Re: Features Wishlist
Post by: calc84maniac on June 03, 2010, 06:01:01 pm
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.
Just remember that will only work as expected for no-stub programs. If it's for a shell, the sprite will be inverted every other time you run the program, and for an App the sprite wouldn't invert at all.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 03, 2010, 06:45:00 pm
wow didn't knew we could use this. x.x
Title: Re: Features Wishlist
Post by: Runer112 on June 07, 2010, 12:41:30 am
The following is a list of all screen/buffer commands, with the size of the routine indicated in parentheses:

The following is a list of the screen/buffer commands that do not utilize subroutines and the increase therefore in program size if the command is called 1, 2, 3, or n times compared to if it was called using subroutines:

Perhaps you could add an optimization feature that counts the number of references to commands such as these? This would either include the routine inline or in a subroutine that is called multiple times depending upon which method is more size efficient based on the number of times the routine is called.
Title: Re: Features Wishlist
Post by: Quigibo on June 07, 2010, 12:47:03 am
That's actually much more tricky than it sounds.  First of all, I would have to make another pass through the program at the beginning and its not just a matter of counting the tokens.  I have to make sure I'm not including strings, token values, and other uses that don't actually count as code.  I will optimize this eventually once I get long name labels.  The two are kind of related even though they sound like different features.

However, in the mean time, you are free to put them in subroutines yourself if you're trying to save space.

Lbl SP
StorePic
Return
Title: Re: Features Wishlist
Post by: Runer112 on June 07, 2010, 12:48:46 am
Yeah, I've been putting them in subroutines. But it just seemed like the kind of optimization that would be quite helpful to not have to manually do for every program.
Title: Re: Features Wishlist
Post by: Quigibo on June 07, 2010, 12:53:05 am
Well its a balance I try to maintain.  Generally, if its under 10 bytes, I don't make it a subroutine, but if its around 9-12 bytes, then it depends on how rare I expect the command to be.  Any more than that, I always use subroutines.  As I said before, eventually this will be optimized automatically.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 07, 2010, 01:08:15 am
I didn't knew DispGraph was this large o.o

But again I only really used it 3 times per program at most
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2010, 07:25:25 pm
If you ever get around to that optimization based on the number of times something shows up, make sure to hit equivalences or unequivalences too. I just went through and manually replaced things like _=16 (which seems to show up a lot) with _sub(16) which checks =16. Saved like 100 bytes.
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2010, 07:37:39 pm
Well, I don't want to do too many of those.  Even though it reduces the size, it also slows down the program a little each time it has to call a subroutine.  Normally, you don't notice this, but sometimes when you're doing very heavy math (like checking if any objects on one list collide with objects on another list) you can actually notice it.

That's an interesting optimization though.  It would be very difficult to figure out what to group though.  Like if you did _*2+1/8+L1 a bunch of times for instance, its convenient to group that whole operation into a single subroutine.  But unlike a computer compiler, Axe doesn't have large memory or fast speed, unless I use the extra ram pages maybe but it would still be super slow for larger programs, so its really not practical to keep track of all that.  Its going to have to be up to the programmer to do a majority of these optimizations.  There's always the computer compiler idea though...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 08, 2010, 07:59:35 pm
It might be good to leave optimizations where the smallest slows down the program up to the programmer IMHO. Just make sure to keep those possible optimizations as documented as possible.
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2010, 08:03:46 pm
Yeah, at the moment I'm making as many optimizations by putting mathematical or logical expressions used more than once (as long as it's size efficient to do so) into subroutines, because my program is at about 7.5k and I don't mind sacrificing some speed for space (it's a sprite editor after all, no need for speed)
Title: Re: Features Wishlist
Post by: ztrumpet on June 10, 2010, 05:58:00 pm
Can we have a command to store the current contrast to a variable?  For example:
ShadeF(->A
Would put the current contrast into A. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 10, 2010, 06:14:59 pm
Not sure if that was suggested before (I might even have suggested them myself XD):

Horizontal +r
Horizontal -r
Vertical +r
Vertical -r
ANOVA(666)r
Line(X1,Y1,X2,Y2)r

I couldn,t find those in the command list. It would let you scroll the back buffer, ANOVA(666)r would delete the entire calc OS certificate+OS the next time you recall the back buffer and you could display lines on the back buffer. White lines would also be nice, but I'M not sure if it's necessary. I simply do DrawInv, display my line then DrawInv again.
Title: Re: Features Wishlist
Post by: ztrumpet on June 10, 2010, 06:20:32 pm
White lines would also be nice, but I'M not sure if it's necessary. I simply do DrawInv, display my line then DrawInv again.
But white lines would be a lot faster.  I think Quigibo should add both while and inverted lines. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 10, 2010, 07:37:36 pm
yeah maybe. I was just saying in case he never adds them that they could be done that way too.
Title: Re: Features Wishlist
Post by: calcdude84se on June 11, 2010, 12:40:47 pm
zTrumpet: The current contrast is stored at $8447 and is in the range from 0 to 39 (decimal)
Title: Re: Features Wishlist
Post by: ztrumpet on June 11, 2010, 12:49:05 pm
Thanks!  So I'd do {E8447}->A to store the current contrast into A, right?
Title: Re: Features Wishlist
Post by: calcdude84se on June 11, 2010, 01:15:25 pm
yes, exactly. If you want the contrast level from 0 to 9, like when you press 2nd+up/down, a simple division by 4 seems like it would work (I may be wrong, but I think that's right)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 06:18:51 pm
Note that you cannot actually update the screen itself with the new contrast value, though. You need a bit of ASM code for that.
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 09:35:05 pm
I thought Quigibo added the Shade( command for that?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:10:51 pm
I don't think it was tied to the contrast level set in RAM, though. It just directly updated the screen. I could be wrong, though.
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 10:27:59 pm
you cannot actually update the screen itself with the new contrast value
It just directly updated the screen

Sorry, I don't understand what you were trying to say here. Though, if you want to update the OS contrast value so it doesn't "jump" when changing it after the program exits, you can store the new value to {E8447}.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:33:40 pm
In the first quote, I was talking about when you store 00h-27h to 8447h, it doesn't actually change the LCD contrast.

In the second one, I was talking about the Shade command. I thought it actually did the later without doing the former?
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 10:35:31 pm
Ah, yeah. Well, I was answering to your comment that you needed ASM code to update the screen.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:52:43 pm
aaah ok that's what I guessed. You needed to update a port or something I forgot (I should check the page on WikiTI again later)
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 09:32:53 am
Yeah, port 10h, with values C0-FF (or, rather, D8-FF, if the values are between 00 and 27 in (contrast))
Title: Re: Features Wishlist
Post by: guy6020665 on June 12, 2010, 12:42:20 pm
I don't know if someone has already requested this but i would really like the "randint(" command because it is beginning to get a bit annoying to put

Code: [Select]
While (A>100) or (A<10)
rand/1000->A
End
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2010, 01:06:14 pm
If you want a random integer between 10 and 100, you should do

Code: [Select]
rand^91+10
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 01:47:42 pm
It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 01:59:13 pm
It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot

To produce a random integer between start and end:
rand^(end-start+1)+start

For example, 1 to 10:
Code: [Select]
rand^(10-1+1)+1
rand^10+1

333 to 666:
Code: [Select]
rand^(666-333+1)+333
rand^334+333
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 02:02:26 pm
is it the smallest syntax, though? I really meant some sort of basic to axe rand converter, even if it means the start/end range is different in the Axe version. Just asking for size reasons
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 02:04:14 pm
What do you mean by "is it the smallest syntax?"

EDIT: If you mean is that the most size-efficient way to produce a random integer in that range, yes.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 02:05:42 pm
I am not sure how to explain it further. Sorry. Could anybody else explain to him for him?
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 02:23:32 pm
Like this?

EDIT: Wait hold on, fixing a bug.

EDIT 2: Attached.
Title: Re: Features Wishlist
Post by: Raylin on June 12, 2010, 02:51:58 pm
Good sir, I don't believe all of those commands in above program work.
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 03:25:07 pm
I didn't look at the program, but those commands listed above have a problem that might annoy some: not all numbers are generated with equal frequency. (Actually, they are if high-low+1 is an integer power of 2, but that isn't often the case)
Why? Let's use 4-bit random numbers, and generate a number between 0 and 2, with something like rand^3 (the Axe is rand^16^3, but whatever)
0: 0, 1: 1, 2: 2, 3: 0,
4: 1, 5: 2, 6: 0, 7: 1,
8: 2, 9: 0, A: 1, B: 2,
C: 0, D: 1, E: 2, F: 0
chances: 0: 6/16, 1: 5/16, 2: 5/16
Note that the maximum effect is at most one more occurrence, though that might be important to you. (If it isn't then the code others gave will work)
Besides trying multiple times (like an optimized version of what DJ had at first), I'm not sure of a way to keep it even... So I hope it isn't too big a bother (it is only slight) Anyone know of a good way to even the probabilities?
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2010, 03:30:06 pm
Well, for 16-bit, you would have:
chances: 0: 21846/65536, 1: 21845/65536, 2: 21845/65536.

There is not enough of a difference to matter, and there isn't really a way to do it better (except by increasing the number of bits, and even then it wouldn't be perfect), because the processor is working in binary.
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 03:32:49 pm
Yeah, it shouldn't bother anybody, but just in case :P
Actually, now that I think about it, there really isn't a "perfect" way to do it with a binary computer... Silly me...
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 03:51:01 pm
Good sir, I don't believe all of those commands in above program work.

See:

It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 11:29:36 pm
mhmm thanks for that converter program This is what I mean earlier ^^

Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 01:25:53 pm
By the way, are horizontal and vertical lines a feature that will come out in the next version or upcoming ones?

http://ourl.ca/4161/94886

I wonder what syntax it would use
Title: Re: Features Wishlist
Post by: Builderboy on June 13, 2010, 02:55:20 pm
Lol being that Horizontal and Vertical have already been taken.... Seems we have run into a predicament :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 02:59:52 pm
Yeah. Also In the future I assume he'll use Line()r for drawing lines on the backbuffer.

Maybe he could make the parser detect when X coordinates and/or Y coordinates are always identical (for example Line(A,15,A,85)) during parsing), or use Hline( or Vline (H and V being alpha letters of course)
Title: Re: Features Wishlist
Post by: Builderboy on June 13, 2010, 03:02:52 pm
Yeah both of those would be great i think.  Although im not sure how well the HLine() VLine() would work in his current parser, it might be completely token based right now, and hard to change o.O
Title: Re: Features Wishlist
Post by: calcdude84se on June 13, 2010, 03:40:27 pm
Why couldn't Horizontal and Vertical have multiple uses? With a '+' or a '-', they'd rotate scroll the screen (as they currently do). If they have a number/variable/expression after them, they draw the corresponding horizontal/vertical line. Or, as you said, would that not be possible in a token-based system?
Edit: They scroll the screen, not rotate it. My bad.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 11:00:58 pm
Mhmm actually they don't rotate the screen, they scroll it. We could do Horizontal (X1,X2,Y) and Vertical (X,Y1,Y2). My only worry is that it could eventually get confusing if a token is used for multiple purposes.
Title: Re: Features Wishlist
Post by: calcdude84se on June 14, 2010, 01:54:01 pm
Oops, yeah, I meant scroll... I'll edit that.
True, overloading a token with multiple commands can and will make things more difficult if overdone. A little wouldn't though, right? :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 14, 2010, 02:02:47 pm
Nope, but let's not overload them, else it will get confusing for sure. As for now, none of the commands are used for multiple things, I think. There is getkey but both usages are for similar purposes. THis is why I thought using Line( with a slightly different syntax might be best
Title: Re: Features Wishlist
Post by: ztrumpet on June 14, 2010, 05:44:38 pm
I think that all lines should use the same syntax, but Quigibo would detect in the the parser which routine is best to use and put that in the program. :D
Title: Re: Features Wishlist
Post by: calc84maniac on June 14, 2010, 06:33:30 pm
Suggestion:
Use Line(X1,Y,X2,) for horizontal and Line(X,Y1,,Y2) for vertical.

The empty arguments would tell the parser to use the optimized routines.
Title: Re: Features Wishlist
Post by: Quigibo on June 14, 2010, 10:18:55 pm
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
Title: Re: Features Wishlist
Post by: SirCmpwn on June 14, 2010, 11:02:30 pm
I agree with Quigibo.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 15, 2010, 12:53:32 am
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
You mean Horizontal X1,X2,Y1 or something like that, right?
/me hopes Quigibo was planning to actually let the user choose where to draw the line x.x
Title: Re: Features Wishlist
Post by: Raylin on June 15, 2010, 09:48:57 am
In the far future, I would be nice to have the ability to have automated BGM.
Using the interrupts, perhaps?
Title: Re: Features Wishlist
Post by: SirCmpwn on June 15, 2010, 10:33:24 am
Two feature requests:
In the menu for program selection, I would like to press Alpha+[Letter] to scroll to that letter
I would like to define the shell in the header.
Title: Re: Features Wishlist
Post by: ztrumpet on June 15, 2010, 01:17:51 pm
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
You mean Horizontal X1,X2,Y1 or something like that, right?
/me hopes Quigibo was planning to actually let the user choose where to draw the line x.x
I hope so too, otherwise it would be kind of like a BSOD/LCD Test Mode without the overload of electricity. O.o
Title: Re: Features Wishlist
Post by: mapar007 on June 15, 2010, 01:19:12 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.

@Raylin: lemme just explain why: the calc processor is too weak to handle all the cryptographic computations involving the signing of the app. (they still have to be signed, even when you already have them on your calc)
Title: Re: Features Wishlist
Post by: calc84maniac on June 15, 2010, 01:31:53 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.

@Raylin: lemme just explain why: the calc processor is too weak to handle all the cryptographic computations involving the signing of the app. (they still have to be signed, even when you already have them on your calc)
I thought they only had to be signed when transferring them to other calcs.
Title: Re: Features Wishlist
Post by: Quigibo on June 15, 2010, 02:01:11 pm
They don't have to be signed on-calc at all, you can sign them on the computer instantly.  I'll probably still add the on-calc signing though, but much later since I doubt anyone would really want to use it.  You'd have to be completely isolated from a computer and slightly crazy to want to do that.  Don't forget, the game will run fine without signing.  This is only for transferring the file to another calculator.

@SirCmpwn
The alpha scroll thing I can do.  The shell type in the header I don't think it necessary.  The app already saves the current shell to use every time you change it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 15, 2010, 03:40:02 pm
I will most likely sign them on the computer, personally. Much faster. That's providing it is even possible to send an unsigned APP from the calc to the computer, though. COuld anyone verify this? Also doesn't it require the app in .HEX format?
Title: Re: Features Wishlist
Post by: jnesselr on June 16, 2010, 10:27:33 pm
Hmm... Why not store the data as an archived appvar or something.  It shouldn't be hard to whip up a java app to convert it.  Can someone explain this signing thing better?  I know about RSA, but is it done on every byte, or the whole app?  I presume that if it was byte by byte, this would be a simple look up table problem, so I'm guessing that's not it.  If it's RSA, and the actual signing process was explained slightly better, I'm sure the app could sign it as well.  I wouldn't mind waiting ten minutes as long as it had a progress bar.  I really dislike the applications that do a process for 5 minutes with nothing to show for it but a blank screen.

Anyway... We could split it up into 4 appvars, each with 4096 bytes.  I bet you could do that in axe, too.  When is the app exporting version expected?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 16, 2010, 10:51:12 pm
I really dislike the applications that do a process for 5 minutes with nothing to show for it but a blank screen.
Yeah I remember that about MirageOs sorting in version 1.1 x.x with 100 programs it took 40 minutes and I thought my calc froze x.x. IN 1.2 it's not as bad.

I don't know much about app signing, but the 10-15 minutes signing process thing came from BrandonW mouth so I guess he knows how that stuff works pretty welland there might not be other ways. As for archived appvars, do you mean to reduce the signing time (since the app wouldn't be multiple pages anymore)? Also I am not sure if Quigibo was planning to implement reading data from archive except if stored in an APP. We would probably still need to unarchive, read data, archive when RAM is running low, unarchive another appvar if needed, load other data, etc. SOmething that would cause a lot of loading times (and wearing off the Flash chip with garbage collections, probably)
Title: Re: Features Wishlist
Post by: SirCmpwn on June 17, 2010, 12:31:03 am
@SirCmpwn
The alpha scroll thing I can do.  The shell type in the header I don't think it necessary.  The app already saves the current shell to use every time you change it.
That is fair, but I have several programs that I develop at the same time, and some use a shell and some I don't actually want to use a shell, so I don't like having to change it all the time.  Sometimes I even forget, and this gets quite frustrating.  For example, I have a prgmKEYS that displays the keycode when you press it, and I accidentally compiled it under MOS and deleted the source.  I'm too lazy to rewrite it, so it has bugged me ever since.  It would have been much easier to define it as nostub in the header.
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:13:50 am
DJ suggested a really cool idea.  I think If I use my hooks correctly, I can have the Axe Tokens automatically enabled whenever the basic editor detects the program it is editing is an Axe source file and then revert back to normal when you quit so that the tokens never get mixed up or confused when you're dealing with regular BASIC.

I'm just worried if I eventually want to switch to Axe Tokens as the default tokens, then computer coding might get more complicated since programs like SourceCoder only use the original tokens.
Title: Re: Features Wishlist
Post by: calc84maniac on June 17, 2010, 02:17:12 am
DJ suggested a really cool idea.  I think If I use my hooks correctly, I can have the Axe Tokens automatically enabled whenever the basic editor detects the program it is editing is an Axe source file and then revert back to normal when you quit so that the tokens never get mixed up or confused when you're dealing with regular BASIC.

I'm just worried if I eventually want to switch to Axe Tokens as the default tokens, then computer coding might get more complicated since programs like SourceCoder only use the original tokens.
You could always ask Kerm to add Axe support to Sourcecoder :)
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:21:23 am
While that is true, and he probably would, what about things like TI-GraphLink?  I don't know if anyone still uses that but that's what I used to use a lot for basic editing.  But I suppose as long as there is at least one computer editor that supports it, then it at least gives you the option.  Does anyone here code on the computer in something other than SourceCoder and would be uncomfortable switching?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 17, 2010, 02:23:48 am
Why not just keep things as they were? Sure, Conj() sounds weird, but think about new members who are gonna ask for help. They're gonna get told to copy bytes they need Conj. Experienced users all ggot used to Conj. I feel like you are forcing this on people and despite what I said regarding that stuff you did not care.

So for now I am sticking to Axe 0.2.6 and am no longer going to provide new feature suggestions.
Title: Re: Features Wishlist
Post by: Raylin on June 17, 2010, 02:30:02 am
Easy, DJ, easy.
Be cool.

Quigibo's obviously wants to evolve Axe into an independent language and if he's doing that, I say let him.
Besides, you can toggle the changes. They aren't really forced... :\
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 17, 2010, 02:32:09 am
True but he's planning to quit documenting the old commands...
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:33:49 am
I'm not planning anything yet.  This is just an experiment.  I'm going to see if people like it or not.  I've clearly got 1 vote for not.
Title: Re: Features Wishlist
Post by: meishe91 on June 17, 2010, 02:42:59 am
I like the idea of just being able to toggle them off and on when you want. That way both sides are happy. What you could do on like the command list to show what both names are is just have one column that says "TI Token" and then the other "Axe Token" and then just state in documentation or something which is which. Just a thought :)
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 04:46:49 pm
I have seen in disassembled code:
 ld ($8000),hl
 ld hl,($8000) ; $8000 is an example

Will that be optimized? Or is the user not optimized code that leads to that?

Also some push and pop of hl could optimize sometimes. Dunno how hard it could be.

When Axe Parser reaches final releases, I will like to see the compiled code for curiosity. :P
Title: Re: Features Wishlist
Post by: Quigibo on June 18, 2010, 04:54:31 pm
That would only be from unoptimized code by the programmer.  Like this:

Code: [Select]
A+1->A
Disp A>Dec

In the above example you first increment the value of A and then save it.  Immediately after, the next instruction is to load A again to display it.  Since you have just saved it and now are immediately loading it, that is obviously an inefficiency.  You can optimize it like this:

Code: [Select]
Disp A+1->A>Dec

So that way, it doesn't need to load the value of A a second time.  I might be able to have this be done automatically, I don't know how hard that would be though becasue that type of optimization is not dependent on the source, rather, it would need to make checks on  the assembly code written.  I haven't tried that yet, but it might be possible in the future.
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 05:04:53 pm
I see. I am still getting into Axe Parser details. :P
Since that only comes from user not optimized code, we can leave to the end or just forget it and instead document how to code optimized.

In the future would an Axe Parser optimizator be a viable project? Like a program that takes compiled code and tries to replace code by smaller or faster code.
Btw, programs (and appsvars) can be shrink directly and safely by changing its size word (it is the first 2 bytes that the VAT points to the program memory) to a lesser value?
Title: Re: Features Wishlist
Post by: Quigibo on June 18, 2010, 05:12:14 pm
I doubt you can shrink it that way because I think then the OS is unaware of the change and it will say you have less RAM available on your calculator than you really do and it will not correct itself until the next ram clear.

I hope to have the Parser itself optimize as much as possible.  The reason you don't really see C or Java optimizers is that its really really hard to optimize code at the higher levels, even for a medium level like Axe.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 18, 2010, 05:15:43 pm
Code: [Select]
Disp A+1->A>Dec
Gotta love how we can do that ;D . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 05:34:13 pm
Code: [Select]
Disp A+1->A>Dec
Gotta love how we can do that ;D . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)
Yes, I also like the syntax after understanding the implications.
It is bit like the Ans (some differences) but even faster. :D
I also wish in TI-BASIC we could do some expressions that did not change Ans for faster code. :D Like lines started with colons instead of enter did not change Ans. I see lots of optimization coming from this.

Even more important would be TI-BASIC be faster interpreting. I will experiment a simple interpreter that looks like TI-BASIC but adds some BBC BASIC, Axe Parser and some of my ideas to it. The floating point operations could be easily added later with bcalls to the TIOS routines. Until that I would use integers for numbers, lists, etc..
The main advantage of a interpreter against Axe Parser is stability and source code is also the code. It would be slower anyway, but I believe is possible to come with a bit faster than BBC Basic.
Also 1000th post. ^^
Title: Re: Features Wishlist
Post by: souvik1997 on June 20, 2010, 08:04:13 pm
Something that would be really cool would be the addition of matrices.
Title: Re: Features Wishlist
Post by: calcdude84se on June 20, 2010, 09:00:52 pm
You can do matrices already, albeit indirectly. For a matrix with X columns and Y rows, for example, you can access (A,B) (with A being the column and B the row, indexed from 0) with {B*X+A+GDB1} (assuming the data is ordered a row at a time, beginning at GDB1)
As for a direct method, it might cause too much overhead, though, even if it didn't (I can already think of an implementation where everything that can be figured out is at compile time), I'm not sure it would be added. That would be up to Quigibo.
So, rather, you would like a direct, simple-looking way to use matrices. (Actually, these are really just two-dimensional arrays, but w/e. You're not getting matrix multiplication in Axe except by your own subroutine :P)
Title: Re: Features Wishlist
Post by: Raylin on June 20, 2010, 11:08:45 pm
Perfect character spacing when displaying text one character at a time.
That is the feature I want.
Title: Re: Features Wishlist
Post by: Builderboy on June 21, 2010, 01:15:33 am
How would you propose this works though?  Since you are displaying it yourself one character at a time, you are specifying the arguments.  Maybe a table of constants that tell you the width of each individual character?
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 01:20:04 am
^ I'll get to that character thing  soon.

I'm thinking of allowing a new alternative syntax to make coding a little easier.  Just like you can do {L1+5} I am thinking of also allowing L1(5) like how BASIC does it.  You would also be allowed to do this with variables.  That is, A(2) becomes {A+2}.  The only downside to this would be that implied multiplication can never be implemented then becasue using parenthesis will ALWAYS imply pointing and never multiplication in order to make this unambiguous.  Not that I was planning to add implied multiplication, but thought I'd mention that.  Similarly, I would also like to be able to do the same with matrices.

What I was thinking is that you can store to a matrix at the beginning at some point.  So L1->[A](5,10) tells the compiler that you would like to start a Matrix at the position L1 and make it 5x10.  This would be completely a compiler command and would not contribute anything to the code.  The next step would be to use [A].  With the new syntax, you could say something like [A](2,4) and it will compile as {L1+2*5+4} since now the compiler knows where to store the matrix and how big it needs to be.

I'm still not sure how possible this will be to do since I still need to have it optimized automatically, but it would certainly be pretty cool.  It might allow me to implement some other commands like row and column swapping as well as well as filling with a single value, copying one matrix to another, etc.  All handled at compile time by the parser to translate into the current way of doing things so that its just as efficient.

I'm not planning to ever replace the old syntax, I'm just giving a new alternative to those who like the BASIC way of doing it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 02:00:48 am
I like the new syntax idea. It would become pretty handy for people who are switching from BASIC. I got an hard time getting used to {} syntax x.x

It would probably also make it easier to port some BASIC programs to Axe
Title: Re: Features Wishlist
Post by: Builderboy on June 21, 2010, 02:06:38 am
Wow that actualy sounds amazingly epic!  Automatic Matrices and Auto lists and all sorts of other magnificent things :D I wonder... if matrices could be 'initialized' to half byte in order to take the hassle out of using half byte code :O
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 09:48:55 am
Feature request: True logical and,or commands. (Not sure about xor, that might not work).
These would act similarly to Python (and maybe other languages too).

"A and B" would compile as:
Code: [Select]
ld hl,(var_a)
ld a,h
or l
jp z,_
ld hl,(var_b)
_

"A or B" would compile as:
Code: [Select]
ld hl,(var_a)
ld a,h
or l
jp nz,_
ld hl,(var_b)
_

So basically, "A and B" is the same as "If A:B:End", and "A or B" is the same as "!If A:B:End"
Title: Re: Features Wishlist
Post by: Magic Banana on June 21, 2010, 09:59:45 am
^ I second that request.
Title: Re: Features Wishlist
Post by: _player1537 on June 21, 2010, 10:06:53 am
sorry for being slow...but what will that allow us to do that the current code won't?
Title: Re: Features Wishlist
Post by: Ikkerens on June 21, 2010, 10:13:48 am
sorry for being slow...but what will that allow us to do that the current code won't?

It will allow us to change other if's.
Code: [Select]
:56→V
:If V
:Disp "V is not zero"
:End

Currently that would cause the parser to think, oh, its not a 1, so skip the block
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 10:16:21 am
Well, "5 and 2" will return 2 instead of 0, which is a non-zero value as expected. Of course, if you just use logical (0,1) values, it works as expected as well.
Title: Re: Features Wishlist
Post by: ztrumpet on June 21, 2010, 10:48:45 am
I think it needs real Booleans.  :)

I also like the matrix/list idea. :D
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 10:52:48 am
Here is another cool thing about this method: Short-circuit evaluation (http://en.wikipedia.org/wiki/Short-circuit_evaluation)

And I think this method would be more efficient than real booleans, because we don't need to waste the extra space making sure all logical operations end up as 0 or 1. Zero and non-zero are all we really care about.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 12:23:11 pm
I think it would be nice indeed if it worked like TI-BASIC. I always had trouble with If conditions otherwise x.x
Title: Re: Features Wishlist
Post by: ztrumpet on June 21, 2010, 12:26:32 pm
I think it would be nice indeed if it worked like TI-BASIC. I always had trouble with If conditions otherwise x.x
Me too. :)
Title: Re: Features Wishlist
Post by: FinaleTI on June 21, 2010, 02:03:39 pm
It would be nice if there was a way to delete appvars from within your Axe program.
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 02:46:23 pm
I'm confused why that code is any different than the current code:

Code: [Select]
"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a

It returns 0 if its false and non-zero if its true as well, and its the same size.  Unless your optimization is a speed optimization?

And Ikkerens, that code has always worked.
Title: Re: Features Wishlist
Post by: Ikkerens on June 21, 2010, 02:49:02 pm
Not on my calc, if I "If X" it will skip the containing code.
Only accepts a 1.
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 02:53:49 pm
That's not how "If" works.  X must have been 0 if it skipped the code.  This isn't something I've ever changed, its always been that true means non-zero and false means zero.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 10:55:00 pm
I noticed in the past that If X sometimes skipped the code if it was something else than 1, but I don't remember when exactly. It was a few versions ago and I forgot which. IN other words, is If with anything that is non-zero supposed to execute the code or will it just do it if it's equal 1?
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 02:45:28 pm
I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 02:50:37 pm
I'm confused why that code is any different than the current code:

Code: [Select]
"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a

It returns 0 if its false and non-zero if its true as well, and its the same size.  Unless your optimization is a speed optimization?

And Ikkerens, that code has always worked.
It is partly a speed optimization, yes. Also, I believe it could be smaller when using expressions, like
A=1 and B=2
wouldn't have to save/restore the result of "A=0".

Not to mention, If X and Y will not work as expected in some cases when using bitwise and.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 22, 2010, 02:52:44 pm
I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?
I believe they were added now. He probably just need to update the list. Keep in mind those bitmaps are slower than 8x8 sprites, though, since he uses a TI routine for them. If you need speed instead of size, I recommend using multiple 8x8 sprites instead
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 03:52:44 pm
OK, so sprites will perhaps be optimized in the future. Is it really that slow? How many time does Bitmap cost more than multiple 8x8 sprites?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 22, 2010, 04:03:21 pm
It's not incredibly slow. It's just a bit slower than regular ones. Bitmap uses a routine included in the TI OS, which means the code needed for it is not included in your Axe program, which is why your executable ends up slower. It's a BCall, I believe.
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 04:07:30 pm
there's a fairly big chance that it is a ROM call I think, but I don't understand why it can't be used in BASIC then?
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 04:09:06 pm
there's a fairly big chance that it is a ROM call I think, but I don't understand why it can't be used in BASIC then?
It's because there's no TI-Basic command for it. It's a routine intended for use in FlashApps and ASM programs.
Title: Re: Features Wishlist
Post by: Ikkerens on June 22, 2010, 05:19:41 pm
1 more thing to the wishlist:
15Mhz GrayScale
Title: Re: Features Wishlist
Post by: Magic Banana on June 22, 2010, 07:59:18 pm
I've got a feature request.

Would it be possible to make 'checkpoints' in the program editor and be able to jump between them using something like 2nd+Right/Left? Just wondering because my code is getting really long and it takes a while to scroll all the way to the bottom just to change 1 or 2 things before compiling again.

Also, for the Error scrolling, wouldn't it be better to scroll to 7 lines before the line with the error, so that it is at the bottom instead of the top? That's how the TIOS does it. I always have to scroll up to see what I wrote to cause the error.
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:02:20 pm
1 more thing to the wishlist:
15Mhz GrayScale
Actually this isn't a  bad idea, as it *would* result in smaller compiled code and because we don't have the Full and Normals to make it slightly faster. :)  Can we please have this Quigibo? ;D
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 08:04:55 pm
1 more thing to the wishlist:
15Mhz GrayScale
Actually this isn't a  bad idea, as it *would* result in smaller compiled code and because we don't have the Full and Normals to make it slightly faster. :)  Can we please have this Quigibo? ;D
The thing is, inside the display routines it would have to set 6MHz, run the code, and restore the previous clock speed. You really aren't saving space after all (especially if your code never sets Full in the first place).
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:07:14 pm
Couldn't you use a different length delay for the LCD?  Or would that not work right? =/
Title: Re: Features Wishlist
Post by: Quigibo on June 22, 2010, 08:26:05 pm
I've got a feature request.

Would it be possible to make 'checkpoints' in the program editor and be able to jump between them using something like 2nd+Right/Left? Just wondering because my code is getting really long and it takes a while to scroll all the way to the bottom just to change 1 or 2 things before compiling again.

Also, for the Error scrolling, wouldn't it be better to scroll to 7 lines before the line with the error, so that it is at the bottom instead of the top? That's how the TIOS does it. I always have to scroll up to see what I wrote to cause the error.

That's another direction I might be headed eventually.  I might just make full fledged editor improvements to the TI Program editor during Axe Edit sessions like "sprite previews" of hex code, "bookmarks" in the code (which is what you're talking about), maybe a "Condensed View" in which labels have little plus signs next to them that expand and hide the code for each subroutine, these are just ideas I'm throwing out there.  They are all possible with the clever use of Key Hooks.  I'm just not sure if I want to go that far until I finish more commands and features, it might be an Axe 2.0.0 thing.

In fact, I would like to turn this thread into a poll, so if any administrators reading this can do that, that would be great.  After each update, I will edit the poll to list several choices of major features to include in the next update so I can get a sense about what people want me to do first.  Also, while you're at it, could you unsticky the token poll since that's already been resolved.  Thanks!  :)
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:28:11 pm
Also, while you're at it, could you unsticky the token poll since that's already been resolved.  Thanks!  :)
Unstickied. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 01:58:40 am
At the bottom of the topic, you see the REPLY | NEW TOPIC | etc stuff, right? If you click the "ADD POLL" button you can append a poll to this topic. If that button doesn't show up, let me know in this thread about what you want the question to be as well as answers, and I may try to add it (or someone else could)
Title: Re: Features Wishlist
Post by: Quigibo on June 23, 2010, 03:24:26 am
Thank you, I didn't see that!  ;D

So anyway, I decided to pick 3 things that each will take a while and I'll try to include at least one of them in the next version.  I would like to know what people want to see next so I spend my time most efficiently.  I've generally just been doing the easy stuff first, but I realize that a lot of people are getting frustrated with waiting around for certain features and I feel like it would be a good idea if you finally get a say in it.  I mean none of this guarantees I will be able to finish the feature, but at least I'll know what everybody wants.  I'll edit the poll each time I finish one of the features.  I'm still working on other smaller commands on the side too by the way as well as bug fixing and optimizations.

Please Vote!
Title: Re: Features Wishlist
Post by: nemo on June 23, 2010, 07:13:31 am
can you elaborate on which each option really means in terms of axe growing?
Title: Re: Features Wishlist
Post by: Raylin on June 23, 2010, 09:41:58 am
If you make these Axioms things, would we be able to make our own?
Could we make something like geo drawing?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 10:55:06 am
Keep in mind Axioms would be against the contest rules, though (since they would not be Axe native code). Just as an head up for contestants.

Interrupts would be nice
Title: Re: Features Wishlist
Post by: ztrumpet on June 23, 2010, 10:57:17 am
I really want interrupts!  They'll be fun to work with. ;D
Title: Re: Features Wishlist
Post by: [email protected] on June 23, 2010, 10:59:47 am
What are these axioms ??

Oh and interrupts too
Title: Re: Features Wishlist
Post by: SirCmpwn on June 23, 2010, 11:35:46 am
Interrupts will be awesome.  Like no other.
Also, bumping my previous request to press a letter key in the compile menu to jump to that letter, like in the TIOS program selection.
Title: Re: Features Wishlist
Post by: calcdude84se on June 23, 2010, 02:15:50 pm
I voted for interrupts, as they will still be native Axe yet will be very awesome. (Interrupt routines ftw!)
What would also be nice is to be able if the interrupt was caused by the ON key or by something else (the hardware timer, etc.)
Title: Re: Features Wishlist
Post by: LordConiupiter on June 23, 2010, 02:32:32 pm
A small question: do you mean with 'native BASIC commands' that external basic prgm files can be executed, or that inline BASIC can be compiled? The last option is the most difficult one I think, while some tokens got a new 'mask' :)
Title: Re: Features Wishlist
Post by: yoman82 on June 23, 2010, 03:07:46 pm
I think inline BASIC is the most desired feature for me, it would make the transition a lot easier. However, how do you plan to address the homescreen, since it is unusable in regular axe?
Title: Re: Features Wishlist
Post by: calcdude84se on June 23, 2010, 03:17:33 pm
Hmm? The homescreen is usable in Axe. (Disp, ClrHome, Output(, etc.)
Also, bumping another feature request: read, write, and create any variable type. (Also deleting any variable, seeing as there is no deleting yet)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 03:18:18 pm
My guess is that he'll use some sort of code that will go back in TI-OS mode in a RAM area where BASIC code is inserted and execute that using the TI-OS BASIC interpreter, then at the end, it will go back to the Axe program again.
Title: Re: Features Wishlist
Post by: yoman82 on June 23, 2010, 03:18:51 pm
yes, I know, but things like input are not. Sorry if I was a bit confusing.
Title: Re: Features Wishlist
Post by: LordConiupiter on June 23, 2010, 03:48:03 pm
IMHO external variable handling is even more important than interrupts, Axioms and a new syntax for lists and matrices.

but that's just MHO :)
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 04:51:58 pm
Wait, i thought Axioms was just the ability to have some of your axe code in seperate programs?  Like subprograms.  Why is that considered non-native code?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 04:55:46 pm
In the poll it mentions it is ASM libs. If Axioms allow the running of non-Axe code, then such non-Axe libs would be disallowed for the contest.

Quote
Axioms (ASM libraries)
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 04:58:04 pm
Hmmm then i am confused.  What are Axioms Quigibo?
Title: Re: Features Wishlist
Post by: Quigibo on June 23, 2010, 05:46:43 pm
Axioms is an SDK for developers to write their own custom Axe commands in assembly.  They would be able to choose the tokens they want to use and an option to change the spellings if necessary.  Users can import the libraries into their programs using the new Axiom() command.  They aren't just slapped into the code, only the routines you use are put into the code just like native Axe commands.  It will support easy things like just inserting a piece of code into the program or more complicated things like subroutines with multiple arguments.  I think it will accelerate the development of Axe commands becasue once some ASM junkies like calc84maniac :P start writing these routines I can basically copy and paste them into the app to support them naively.  Also they can be written to support specific shells such as DCS or MirageOS.
Title: Re: Features Wishlist
Post by: ztrumpet on June 23, 2010, 05:55:25 pm
That's neat.  Does this count as Axe, DJ?
Title: Re: Features Wishlist
Post by: FinaleTI on June 23, 2010, 05:57:29 pm
That does sound cool.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 06:30:15 pm
That's neat.  Does this count as Axe, DJ?
Sadly, no, because I know this will get abused and people will write Axe games that has like 50% Axioms in them.

If an Axiom is included with Axe Parser download in the future, I'll accept it, though. But I am sure Quigibo would just integrate them in the language (and the APP) anyway.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 06:33:59 pm
Sadly, yes,

I think you mean no?  Ztrumpet was asking if they were Axe code (and therefore usable in the contest).  You said yes, but it sounds like you mean the opposite? o.O
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 06:35:47 pm
Er... my bad... sorry. Edited my post. Nah it wouldn't be considered as Axe code. However, if Quigibo decided to include Axioms with Axe Parser, thos Axioms could be used in the contest. Just not third-party stuff, to prevent abuse.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:00:12 pm
yeah that sounds good to me :) Hmm though... what if you wrote your Axioms in Axe?  Axe compiles to Asm, so i think you could theoretically use Axe Axioms :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:06:20 pm
well, the source code for those Axioms would need to be included, then.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:16:13 pm
Sounds good to me ^^ I personally voted for Axioms, just because of how much easier it would be to have several different subprograms instead of a single 8000 byte program to edit. 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:16:54 pm
yeah true, especially when working on mutliple projects at once that uses the same routines. Plus it makes the code less long to scroll
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:18:19 pm
Yeah, but it seems that interrupts are going to take the cake this time :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:20:35 pm
Well, I personally voted interrupts, since for now I can tolerate scrolling through large code, plus right now my programs are rather small. I guess I might be used a lot to Illusiat 13 :P
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:40:47 pm
Heh i remember when i was programing Portal and i was editing the last sequence.  I had to scroll through over 8000 bytes of Code to get to the buggy part ;D
Title: Re: Features Wishlist
Post by: souvik1997 on June 23, 2010, 08:13:40 pm
Axioms is an SDK for developers to write their own custom Axe commands in assembly.  They would be able to choose the tokens they want to use and an option to change the spellings if necessary.  Users can import the libraries into their programs using the new Axiom() command.  They aren't just slapped into the code, only the routines you use are put into the code just like native Axe commands.  It will support easy things like just inserting a piece of code into the program or more complicated things like subroutines with multiple arguments.  I think it will accelerate the development of Axe commands becasue once some ASM junkies like calc84maniac :P start writing these routines I can basically copy and paste them into the app to support them naively.  Also they can be written to support specific shells such as DCS or MirageOS.
Natively or naively?  :P

I voted for the new list syntax because I am used to the BASIC way of doing things
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 08:44:32 pm
I think he means natively, according to the context.
Title: Re: Features Wishlist
Post by: ACagliano on June 24, 2010, 12:00:18 pm
I don't know how complicated this would be, but maybe have Axe also serve as an on-calc version of BasicBuilder, compiling selected progs written in Axe into Applications.

I know there's probably a bus-load of problems with this, but its just a whim.
Title: Re: Features Wishlist
Post by: Builderboy on June 24, 2010, 02:24:42 pm
There really is no problem besides the fact that it would take about 15 min to sign the apps, and thats no good :(

(At least you would only have to sign them once however, since you can beta test all you want without signing them)
Title: Re: Features Wishlist
Post by: shmibs on June 24, 2010, 08:58:38 pm
i haven't gone and read through the last 55 posts so im sorry if it has been mentioned already, but reading data one byte at a time from the flash (from appvars and such) instead of unarchiving them in their entirety would be a huge help
Title: Re: Features Wishlist
Post by: calcdude84se on June 24, 2010, 09:00:24 pm
Yeah, doing that or creating a RAM copy of an appvar/program (IMO more useful) has been mentioned. No harm in bumping it, though. :P
That and more variable support are the things on my mind right now (besides interrupts)
Title: Re: Features Wishlist
Post by: Mighty Moose on June 24, 2010, 11:23:27 pm
I'm split between interupts and axioms.  Although I don't use Axe much (yet).  I think interupts would be nice, but I also think axioms would speed up development.

I know this probably has already been mentioned, but have we decided when geometry tools (circles, boxes, etc.) will be added?
Title: Re: Features Wishlist
Post by: Quigibo on June 24, 2010, 11:33:40 pm
They'll be in the next poll Moose.  That one will take particularly long to write though which is why I've been putting it off.  I have to write all those routines from scratch to meet the Axe super-standards.

I've been working on both Axioms and Interrupts and they might both be done by Sunday hopefully.  Just for future reference, I think I will make the interrupt vector table reside in L2 since mirage uses this for its own interrupts but I'm not 100% sure (do any asm programmers know another place to fit the table more tightly?)  Also, writing the Axioms has made me realize the importance of another major optimization that must be done to support the Axioms.  The Parser will have to make a 3rd pass most likely, so that is a 30% in time to compile, but its already pretty fast so I don't think anyone will mind.  The ~20-60 byte decrease to most programs will make it worth it anyway.
Title: Re: Features Wishlist
Post by: Mighty Moose on June 24, 2010, 11:41:40 pm
Oh, ok.  I was just curious.  I would imagine it would be somewhat difficult to draw geometric shapes w/o actual draw tools.

Good luck and happy coding!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 24, 2010, 11:51:25 pm
Good luck Quigibo!

Btw will the usage of L2 mess up MirageOS if we use Interrupts?
Title: Re: Features Wishlist
Post by: Builderboy on June 25, 2010, 01:26:56 am
I hope not D: I dont want MirageOS programs to be deprived of their interrupts :[
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 02:16:29 am
Or not being able to run our games that use interrupts in Mirage. A lot of people still use Mirage as their favorite shell.
Title: Re: Features Wishlist
Post by: Quigibo on June 25, 2010, 04:19:43 am
If you're using your own custom Interrupt, then you're not using Mirage's interrupt.  Therefore there's no conflicts.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 09:20:39 am
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Title: Re: Features Wishlist
Post by: calc84maniac on June 25, 2010, 11:10:58 am
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Well, it would overwrite Mirage's interrupts, but I'm quite sure that these interrupts are only used for those ON+button hacks during games, not in MirageOS itself.
Title: Re: Features Wishlist
Post by: _player1537 on June 25, 2010, 02:21:05 pm
desolate I remember used custom interrupts, and iirc it exited just fine.  Someone might want to double check me on that though
Title: Re: Features Wishlist
Post by: ztrumpet on June 25, 2010, 04:45:03 pm
Awesome!  Thanks Quigibo! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 06:33:07 pm
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Well, it would overwrite Mirage's interrupts, but I'm quite sure that these interrupts are only used for those ON+button hacks during games, not in MirageOS itself.
Ah, if that's the case, it might be fine, then. Some games disables those.
Title: Re: Features Wishlist
Post by: ztrumpet on June 25, 2010, 10:11:57 pm
I have a request:
Can we have include files.  For example if we had a routine for getting the user's name at "Lbl N" you could add this in your code in two ways:
1: Normally.  Have Lbl N somewhere in your program.
2: With the include.  Close to the top, put the name of the program where the subroutine resides.  When it's compiled it would get compiled with the main program and would run exactly the same.

Is this possible?  I think this would be helpful for better readability. ;D  Thanks! :D
Title: Re: Features Wishlist
Post by: Quigibo on June 26, 2010, 04:23:16 pm
@ztrumpet, I hope so.  I plan to eventually have external Axe libraries which is basically almost exactly what you're talking about, however, it is very difficult.  Much more so than Axioms.

I have reset the poll since I finished interrupts which are really awesome are surprisingly simple to use in Axe.  You're all going to be so spoiled [old man voice] becasue back in my day, we had to are our interrupts in assembly, and the tutorials were wrong and misleading, and I spent weeks before I realized I forgot to save the IX register, and get off my lawn you crazy kids! [/old man voice] :D .  I have replaced it with geometry drawing so please vote once again!
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 06:51:17 pm
will drawing a 8x8 black square be faster or slower than using an 8x8 sprite?
Title: Re: Features Wishlist
Post by: Builderboy on June 26, 2010, 07:18:03 pm
I would hope its faster since your not reading from any sprite data o.O We shall see
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 07:21:30 pm
i hope it is too.. that would come REALLY handy in my contest entry (: i'm waiting to place my vote until i know though.
Title: Re: Features Wishlist
Post by: SirCmpwn on June 26, 2010, 07:23:37 pm
I really want to use custom interrupts and Axioms.  That would be awesome.
Title: Re: Features Wishlist
Post by: Builderboy on June 26, 2010, 07:34:00 pm
I voted for Axioms again ^^
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 08:08:14 pm
i'd vote for string output if that was an option.

edit: would it be feasible to have a shortcut to incrementing a byte in RAM?
so rather than doing
Code: [Select]
{O+1*Y+X+L1}+1->{O+1*Y+X+L1}

you could do something like

Code: [Select]
{O+1*Y+X+L1}++

just like in C.
Title: Re: Features Wishlist
Post by: calc84maniac on June 26, 2010, 08:50:20 pm
That would probably be a good idea. In the meantime, you can use a ->var in the first set of brackets and use {var} in the second.
Title: Re: Features Wishlist
Post by: willrandship on June 26, 2010, 09:40:53 pm
I was going to vote asm libs, but voted Geo Drawing since asm libs will probably not be allowed in contests.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 27, 2010, 12:07:24 am
I suspect Raylin will vote for geometry drawing (noticing his signature says his Axe entry is on hold until such feature is added) :P
Title: Re: Features Wishlist
Post by: Raylin on June 27, 2010, 12:09:16 am
Damn right. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 27, 2010, 12:30:05 am
Another thing I wonder:

When you install a language localization APP (like Français, which I used a lot until I started using Omnicalc/xLIB, which screws it up), all the commands in the CATALOG are re-ordered in the new alphabetical order they are in French. Do you think this could be possible for the new Axe tokens? I sometimes have an hard time finding some of them there (except Copy() of course) x.x

You would need to make sure they are ordered properly on 83+/SE calcs, though, since they have fewer commands than the 84+.
Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:02:53 pm
Okay, I've finished Axioms for the most part, I just have a few more things to tweak and more testing to do.  I updated the poll.  I won't go any higher than 4 options otherwise it will spread out the votes too much.  The "Update Documentation" idea would take me a long time to do, but it would involve writing a detailed commands list in the doc itself with examples and tips and stuff like that.  I would still keep the old one though just for reference and to have a "printer friendly" version.

The linking and port I/O would involve automated linking features that basically send and get bytes through the link port as well as raw data for perhaps microphones, IR controllers, sensors, advanced sound, accelerometers, electronic circuits, etc.
Title: Re: Features Wishlist
Post by: nemo on June 29, 2010, 10:07:35 pm
quigibo, i don't recall this being answered. would an 8x8 sprite be faster or slower than geometry drawing an 8x8 black box?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:09:19 pm
I would still keep the old one though just for reference and to have a "printer friendly" version.
or TL;DR version ;D (if for example someone just seek info for one or two command and doN't know the name).

I voted geometry drawing, though, since it might make the creation of HUDs and interfaces faster and circles would be nice. Would this feature also integrate faster horizontal/vertical lines?

Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:09:38 pm
@nemo
Rect() would be faster for sure.  It's possible that it might be about the same speed if its aligned horizontally though.

EDIT:
@DJ
Yes, faster horizontal and vertical lines would be part of geometry drawing.
Title: Re: Features Wishlist
Post by: nemo on June 29, 2010, 10:12:25 pm
that makes my answer. let's go geometry drawing. where's raylin? we know his vote.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:16:40 pm
YAY! What commands will this be, btw?

Also, I wonder: when running Doors CS7 or Français APPs, will the new tokens still work afterward? (in other words, would there be hook conflict or not?)
Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:21:55 pm
As far as I am aware, neither of those applications use the Token Hook so there should be no conflicts.  However, I may eventually use the Catalog Hook to rearrange the catalog which would of course conflict with any Language Localization apps.  Its possible I would need to use the App Change Hook as well which could cause other conflicts.  I will see if its worth all the trouble or not and if there is any simpler way to do it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:29:29 pm
Aah ok. I am curious what does Français uses, though, as it changes almost every single TI-BASIC token names accross the entire calc (and swaps Int() with iPart()... stupid Texas Instruments...)

For Français, I would wait a bit, though. It's not a big hurry as long as Silver Shadow won't finish translating the doc in English. In long terms it might increase Axe audience because most french people won't even know a single word of English (as it is not one of the official language in France) and I believe most people use the Français APP there (especially the people with the blue 83+, which has the entire keypad in french)

Another thing is that language APPs adds a new option at the top of the CATALOG, above Abs(): Characters. In there you can easily type strings of text including greek and accent characters.
Title: Re: Features Wishlist
Post by: Runer112 on June 29, 2010, 11:15:30 pm
EDIT:
@DJ
Yes, faster horizontal and vertical lines would be part of geometry drawing.

Shit, didn't see that till after I voted for port I/O... :( If it happens to be a tie between geometry drawing and something else, let geometry drawing win? Lol


I made the poll so you can change your vote now

Oh yay
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 11:16:34 pm
I made the poll so you can change your vote now
Title: Re: Features Wishlist
Post by: TIfanx1999 on June 30, 2010, 12:08:08 am
Mmmmm.... linking. Now that sounds yummy! :D
Title: Re: Features Wishlist
Post by: LordConiupiter on June 30, 2010, 12:25:18 am
yes, I allways have liked connecting anything with anything else :P
Title: Re: Features Wishlist
Post by: ztrumpet on July 01, 2010, 11:54:37 am
GAH!  I really want linking, but I need speed for a HUD.  My vote was for linking, but then I changed it.  Needless to say, I really want both, I just want speed more. ;D
Title: Re: Features Wishlist
Post by: Builderboy on July 01, 2010, 12:09:43 pm
Same here, i was original linking, but i think geometry would be more useful right now.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 12:58:59 pm
quigibo, can i suggest putting storage to BASIC variables as an option in the next poll, since two of the four options currently have 0 votes?
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 02:11:22 pm
could you perhaps change L1 to L6 to something that makes more sense?
like L3 is AppBackUpScreen, in short ABS?
and L6 is plotSScreen, in short PSS?
I would like it, what do you think about it?

Can you also please copy a Pic depending on its size?
I have Pic vars with a size of 779 bytes, from my PC, which have full 64 rows of the screen, and i would like to be able to use all this info.
thanks in advance
Title: Re: Features Wishlist
Post by: Quigibo on July 01, 2010, 04:08:42 pm
Sure, I changed the poll.  You can always change your vote, but I think I will do geometry drawing next anyway since it will be something fun even if it does take a long time.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:11:43 pm
that's fair. i want both geometry drawing and OS pic/var etc. support anyway. guess i'll be a loner and change my vote to OS var support (:
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2010, 04:11:49 pm
Can someone reset the votes and remove geometry drawing from the poll? It looks like Quigibo has selected geometry drawing as the next feature he will work on already.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:12:41 pm
err.. i can't change my vote apparently.
Title: Re: Features Wishlist
Post by: Quigibo on July 01, 2010, 04:18:11 pm
Well, I haven't actually started it yet, but when I finish it I'll reset the poll.  Desires can change over a week like if you get to a point in a game where you realize you really need something or if you start a new project and find yourself inconvenienced.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:26:34 pm
quigibo: there's no option for me to remove my vote/change it. can you make this an option?
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 04:59:08 pm
There will be a new poll when he's finished. It doesn't matter whether you change yout vote right now or not. We just have got to wait till he's finished, and there'll be a new poll.

patience is a vitue... :P
Title: Re: Features Wishlist
Post by: ztrumpet on July 01, 2010, 05:20:04 pm
patience is a vitue... :P
No. :P

I changed it so you can change your votes now. ;D

[mini rant]Not fair!  I want all of these options!  Now! :P[/mini rant]
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 06:03:54 pm
haha ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 01, 2010, 07:32:15 pm
geometry drawing remains my vote for now.

Next, I'm sure to vote reading from archive. A must for large games ^^
Title: Re: Features Wishlist
Post by: Builderboy on July 02, 2010, 04:37:34 pm
When compiling to App, since it doesnt tell you program size, could it tell you how much free space is left in the App?  Just a suggestion :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 02, 2010, 04:54:00 pm
That would be nice indeed. On the computer you can get an estimate by taking the app computer file size and divide it by half, but it is not always very accurate
Title: Re: Features Wishlist
Post by: Runer112 on July 03, 2010, 12:52:29 am
That would be nice indeed. On the computer you can get an estimate by taking the app computer file size and divide it by half, but it is not always very accurate

>divide it by half
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 01:44:44 am
as I said, though, it is not 100% accurate. Doing this with Axe Parser APP shows a size of above 16384 bytes
Title: Re: Features Wishlist
Post by: Runer112 on July 03, 2010, 02:13:21 am
I meant to point out the wording, divide (/) it by half (1/2). ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 02:27:40 am
what's wrong with my wording?
Title: Re: Features Wishlist
Post by: Builderboy on July 03, 2010, 02:38:10 am
He's pointing out that dividing by 1/2 is the same as multiplying by 2  (well not really pointing out :P)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 02:45:53 am
oh ok x.x. Well I kinda dislike when people point out a mistake and do it in a so unclear way x.x. Thanks Builderboy for at least clarifying him
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 04:28:56 pm
I'm not going to read through all 59 pages and make sure this hasn't been posted before. I haven't tried programming in axe yet, but it always seems that everyone is afraid of losing their source.

Why doesn't axe archive/leave archived the source and use a temp program for compiling? This would eliminate the chance of deleting your program.
Title: Re: Features Wishlist
Post by: ztrumpet on July 04, 2010, 04:31:24 pm
Why doesn't axe archive/leave archived the source and use a temp program for compiling? This would eliminate the chance of deleting your program.
That's a really cool idea, but I'm sure people don't want a lot of Garbage Collects.  Personally I think it' an awesome idea.  Could this be an option... ;D
Title: Re: Features Wishlist
Post by: Quigibo on July 04, 2010, 04:33:15 pm
The source is never lost from compiling, the source can only be lost if the user creates a faulty program and runs it when important things are in ram.  I am probably going to add an option to auto-archive the source after the compile but I don't know how many people would use it since it is annoying to have to keep unarchiving the source every time you need to make a change to it.  Another option is to create a backup copy of the source and archive it before compiling, but there might not be enough ram to do that for larger programs.
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 04:39:12 pm
Ok that's good.

I don't know the inner workings of axe, but couldn't you change the last letter of the source name to something random, like B or %, archive it, remake the source program, and copy the source back from archive? That way, the backup would always be there and would not require any extra ram to create.

You could then have an option to restore backup.

Edit:
    Better yet, just change it's type to appVar, no name changing required.
Title: Re: Features Wishlist
Post by: kindermoumoute on July 04, 2010, 05:08:54 pm
This list is promising, I hope soon to have:
Quote
-Read and write to more calc variables (like Pics)
-Elseif
-Geometry drawing (circles, squares, etc.)
-Automated tile-mapping

good luck ;)
Title: Re: Features Wishlist
Post by: Quigibo on July 04, 2010, 06:13:00 pm
I don't know the inner workings of axe, but couldn't you change the last letter of the source name to something random, like B or %, archive it, remake the source program, and copy the source back from archive? That way, the backup would always be there and would not require any extra ram to create.

Yeah, that's what I was thinking.  The only problem with having it as an appvar though is that then if the ram clear does occur, it would be tricky to get the file back as a program.  You would either have to use an external tool or I would have to add some kind of option in Axe.  What I'll probably do is just always save the backup to the same file and call it "ZBackUp%" or something using illegal characters to guarantee that it won't already exist.  The Z so it always shows up at the bottom of the list.  Also I can give it a backup header instead of a regular one so that it can be restored to its original name.

Also, I'm not sure you can rename a file that's in archive without unarchiving it first.  The symbol table can be renamed, but a copy of the name is also in the archive which could lead to complications becasue during a ram clear when the symbol table gets wiped, it will be regenerated with the incorrect name.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 04, 2010, 06:33:33 pm
auto archiving would be cool. I am sure I would use it if I was on a SE calc and was messing around with stuff that can potentially crash the calc. In some occasions, I tend to forget to backup (normally I do)
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 06:35:57 pm
I was just assuming that the program was in ram. If it's in ram, you can do all you want to its name. By directly modifying the name, the program never has two instances in ram and is only archived once.

You also don't want to use % in a program name as it becomes invisible. I thought that making it an appVar would be the simplest because it wouldn't even require changing the file because the name is preserved as is.

The easiest way I see to back up programs in ram is:
change to appVar
archive
recreate original program
copy from archive

It would of course be different for archived programs.

On recovery, just unarchive, and change the type back to program.
Title: Re: Features Wishlist
Post by: Runer112 on July 04, 2010, 07:04:21 pm
Protip

At the start of the program:
Code: [Select]
"prgmPROGSRC"→Str0
Archive Str0

At the end of the program:
Code: [Select]
UnArchive Str0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 04, 2010, 07:05:47 pm
oh wait I forgot about that :D

Thanks for the tip :D
Title: Re: Features Wishlist
Post by: LordConiupiter on July 05, 2010, 10:59:47 am
a feature request: I would like to be able to execute external ASM/Axe programs or code snippets in AppVars, like external sub()'s. Perhaps u could use the command Func() for this, with the following syntax:
Func(PTR, arguments (r1 to r6))
The pointer has to be a label, and arguments are just only useable in Axe Funcs I think.
Title: Re: Features Wishlist
Post by: Builderboy on July 07, 2010, 02:46:32 am
I would like to be able to shift the backbuffer, currently there is no fast way to do it :(
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 02:56:50 am
yeah I suggested that some drawing commands be extended to back buffer usage too before. I think he said it might be hard for some, though. I hope for scrolling it is possible
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 04:18:13 pm
Question: Will the new geometry drawing additions also include the addition of faster horizontal/vertical line routine?
Title: Re: Features Wishlist
Post by: Quigibo on July 07, 2010, 07:02:55 pm
I'm still debating that.  Using the rectangle command to draw lines would be about the same speed anyway so I might just leave it at that to draw a rectangle with width 1.

The Rect() command is using the ref() token since that puts it in the catalog alphabetically.  Its easy to use and it takes as arguments the X,Y of the upper left corner followed by the width and height of the rectangle respectively.  Making the width or height 1 allows you to draw fast vertical or horizontal lines.

I'll try to extend more of the current drawing commands to the backbuffer as part of this geometry overhaul.
EDIT: I'll reset the poll now since I'm well into the geometry stuff.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 08:24:25 pm
Oh really? Nvm then :P altough it might pose problems if someone wanted to make a racing game like the one included with Axe due to lack of clipping (unless the person used min/max for clipping purpose)

I think the Rect token is fine. I do not remember if Ref was used much anyway and the name is pretty similar so it shouldn,t be too hard to find in the CATALOG.

Suggestion, you should rewrite your racing game using those :D

EDIT: Voted reading from archive.
Title: Re: Features Wishlist
Post by: Magic Banana on July 08, 2010, 01:16:53 pm
Hmm, tough choice between Read From Archive and OS Var Support, but I'm gonna go for the OS Var support so that I can use Axe programs along with Basic Programs.

Also, Saftey Features should be "Safety Features".
Title: Re: Features Wishlist
Post by: ztrumpet on July 08, 2010, 01:31:57 pm
Also, Saftey Features should be "Safety Features".
Good catch.  I got it fixed. :)
Title: Re: Features Wishlist
Post by: Builderboy on July 08, 2010, 02:33:01 pm
Lol looks like a pretty close race so far!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 08, 2010, 02:53:27 pm
Wow indeed o.o

Yesterday reading from archive was leading by far (and I was happy ;D)
Title: Re: Features Wishlist
Post by: ztrumpet on July 08, 2010, 02:56:49 pm
Wow. O.o  This is extremely close! ;D
Title: Re: Features Wishlist
Post by: calcdude84se on July 08, 2010, 03:05:00 pm
Nobody wants safety features :P
And until I voted, it was tied 4-4-4 (safety features not included).
Title: Re: Features Wishlist
Post by: LordConiupiter on July 08, 2010, 04:47:07 pm
I don't know why safety features would be wanted, cuz everybody just should learn to code safely, and safety slows down a lot, while it won't be used so much.
Until I voted, it was tied 5-5-5 :P
Title: Re: Features Wishlist
Post by: nemo on July 08, 2010, 05:48:05 pm
i'm hoping desperately that OS var/pic support wins. quigibo, in the event of a tie, what happens?
Title: Re: Features Wishlist
Post by: Quigibo on July 08, 2010, 06:11:26 pm
Even in the event of a win, that doesn't mean that's the feature I'm going to work on.  This just gives me a sense of what people want.  Unless there is a mass majority, I'm just going to do what I feel is most essential, or in some cases, whatevers easiest :P
Title: Re: Features Wishlist
Post by: nemo on July 08, 2010, 06:12:35 pm
makes sense. could you rank the 4 options from easiest -> hardest for some comparison?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 01:09:01 am
that said, I hope reading from archive is done at some point in the near future, it would come very handy if I ever made some sort of sequel to Supersonic Ball, since it would mostly not just include levels that are randomly generated and the game would be considerably larger.
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 01:38:40 pm
Indeed, DJ. Even if reading directly from archive isn't supported, it would be nice to be able to create RAM copies of variables.
Well, I guess I'll wait and see what feature is added next. Keep up the good work, Quigibo! :D
Title: Re: Features Wishlist
Post by: LordConiupiter on July 09, 2010, 01:55:25 pm
I don't understand why so many people think that OS Var/Pic/Strc etc. is so very important? for the contest it isn't even allowed to use them i thought, or am I wrong at this point?
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 02:09:18 pm
I don't remember about not being able to use them... Unless you mean to store data, which would be pretty pointless anyway. (So much faster just to have it in the program or in an appvar)
That wasn't my vote, at any rate, so I can't tell you why :P
Title: Re: Features Wishlist
Post by: LordConiupiter on July 09, 2010, 03:24:54 pm
OK, I see.
... Unless you mean to store data, which would be pretty pointless anyway. (So much faster just to have it in the program or in an appvar) ...
OS Pics would perhaps be handy, but I thought conversation with external non-Axe programs was forbidden, and OS things are just only handy for that OMHO.
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 03:31:30 pm
I agree w/you there, and yes, pure Axe only.
Pics and strings would be the two useful OS vars, IMO (Mainly for things like sprite/picture editors)
Title: Re: Features Wishlist
Post by: Quigibo on July 09, 2010, 04:04:07 pm
You're allowed to use OS variables and its even encouraged.  How else are you going to save your games?  Appvars are OS variables, but if you wanted, you can use pics, strings, or other things to save data but I don't know why you would want to.

But I have a feeling most people who voted did not vote because of the contest, but because they want to make some useful editors for sprites, tilemaps, music, and programs which are significantly more useful with more OS var support.
Title: Re: Features Wishlist
Post by: Magic Banana on July 09, 2010, 04:05:49 pm
Is there an efficient way to 'swap' the buffer and back buffer? If not, I'd be nice to have that.

Also, is there a better way to store an OS pic to the buffer besides
Code: [Select]
:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 04:08:51 pm
Just use expr( (well, now it's Exch(, but you get the point) like expr(L3,L6,768
Yeah, you can do it with conj(/Copy( like this:
Code: [Select]
:[Pic1]->Pic1
:Zeros(12
:.You need to fill in the last row
:Copy(Pic1,L6,768
Edit: some letter cases were incorrect
Title: Re: Features Wishlist
Post by: calc84maniac on July 09, 2010, 04:10:42 pm
Is there an efficient way to 'swap' the buffer and back buffer? If not, I'd be nice to have that.

Also, is there a better way to store an OS pic to the buffer besides
Code: [Select]
:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
I believe you are talking about the Copy() and Exch() commands.

To swap the main buffer and the back buffer, do:
Exch(L6,L3,768)

To copy picture data to the buffer, do:
Copy(Pic1,L6,768)
Title: Re: Features Wishlist
Post by: Magic Banana on July 09, 2010, 04:13:11 pm
Thanks guys. I've never really used the Exch() and Copy() commands before, but I guess they are really helpful. I should probably look into how they work.  :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 08:27:39 pm
I don't understand why so many people think that OS Var/Pic/Strc etc. is so very important? for the contest it isn't even allowed to use them i thought, or am I wrong at this point?
If any BASIC stuff is used by your contest entry, it has to be generated by Axe language (and executed with it). In other words, there wouldn't be much point in doing that for the contest since storing your save data in an APPVAR would be much smaller.
Title: Re: Features Wishlist
Post by: jnesselr on July 09, 2010, 09:09:11 pm
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string.
Title: Re: Features Wishlist
Post by: nemo on July 09, 2010, 10:25:05 pm
Quote from: graphmastur
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string.

Case in point. (http://ourl.ca/6241)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 10:32:04 pm
Keep in mind the BASIC data has to be created by the Axe entry during when we will test them, though. When the entry is submitted, external BASIC vars will be deleted.
Title: Re: Features Wishlist
Post by: nemo on July 09, 2010, 10:36:39 pm
another advantage of OS variable support would be if you were developing a basic program and had a routine that just managed/sorted data but took a long time because it's written in BASIC, you could write a quick axe program to do the same thing with the data in the basic variable, compile the program and then run the compiled axe program in the middle of your basic program to do its job in a quick way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 10:46:58 pm
True. Also, for people who want to stick with TI-BASIC because writing an Axe game is a bit too hard for them or they are more comfortable with BASIC, they can use OS variable support in Axe to write some small Axe routines that will perform stuff for their BASIC program much faster.

In the past, to do this, you either had to learn ASM or wait until someone does it for you. Now with Axe it's easier so it's much easier to write hybrid BASIC games.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 13, 2010, 05:26:53 am
Keep in mind the BASIC data has to be created by the Axe entry during when we will test them, though. When the entry is submitted, external BASIC vars will be deleted.
Is it allowed then to create a setup program to create all data? Or do we have to create a single program?

And Quigibo: could you add a fourth param to the for statement? for the step size? like:
Code: (Axe) [Select]
For(A,8,3,-1
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 05:58:35 am
Yeah I'm not sure what DJ is talking about.  Especially for large games, it will become impossible to keep all the data in a single program and it would be silly to have to package data in other axe programs just so they can be extracted.  Unless he is referring specifically to the BASIC language and not to the BASIC variables themselves which I think is what he is referring to but I'm not sure what the rules are about external data and if there are limits or not so please correct me if I'm wrong.  Its possible that external data might be forbidden, that is, entries must be a single program.

EDIT: Actually, after re-reading the rules, I think its pretty clear that you are allowed to use them as long as they're not being executed or interpreted by the OS.  So I think DJ just misspoke.

I might be able to do the increments in the for loops.  I will see if I can get them optimized enough.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 07:34:48 am
What I mean is if somebody's entry for the contest uses BASIC data that was created by a BASIC program prior the execution of his Axe entry.

External data is only allowed if it was created using Axe language.

That said, it would totally be pointless to use BASIC data in an Axe program anyway, because it would take a considerable amount of memory compared to its BASIC counterpart. I doubt someone would do this, but we never know, if for example, somebody decided to use map data in his Axe program that he previously used in a BASIC RPG, for instance, and did not feel like converting it to HEX.
Title: Re: Features Wishlist
Post by: yoman82 on July 13, 2010, 11:02:25 am
I'd say it would be my #1 concern for inline basic in axe. It'd really make the transition far easier.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 02:57:58 pm
In my opinion, we should not do anything with basic programming, because this is a new language, and it isn't a good idea to cling to the old language. The transition would be easier if you were to just learn how to use pointers. Besides, axe is a compiled language. Interpretted basic statements would not work.
Title: Re: Features Wishlist
Post by: Builderboy on July 13, 2010, 03:08:46 pm
When a program is compiled, could the compiler show how much of the program Memory and How much is Code?  This would help programers because they would know when they were reaching the executable limit, and it would help App builders to know how close they are to filling the App
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 03:19:48 pm
I can see it helping app members more.  That is not a bad idea.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 04:22:23 pm
It would still be cool to be able to use BASIC vars in Axe, though. Imagine if someone wants to create an image editor or a sprite editor that creates xLIB tilemaps, for instance, or an ASCII map editor for games like Illusiat 13. Some people may want to stick with BASIC but it would be nice if Axe utilities for BASIC programmers could be done to help them.
Title: Re: Features Wishlist
Post by: squidgetx on July 13, 2010, 04:29:40 pm
mrmrmmmrmrmm not really relevant to the current conversation, but I would like circle()r and line()r for drawing on the back buffer..:)
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 05:43:11 pm
DJ, I'm confused.  How would you be able to tell if a BASIC variable was created in Axe or not?  For instance, my music generator creates a BASIC program that can be imported into Axe but suppose someone ran out of room so just left that program in memory and read it from the main program to play the music.  That would be non-Axe generated file but definitely Axe compatible.  Or what if you typed your data file in the TI-BASIC editor and it had a similar format to TI-BASIC for whatever reason?  That would have to be allowed since its data.

The main problem with this is that Axe can generate ANY file with ANY combination of characters inside so technically all files are "Axe Created" and everyone will claim that they are.  It is extremely easy since you can just fill the Data() command with all the tokens you need and then Copy() them into the program.  I think what you're worried about most is that people will find a way to make a BASIC hybrid program somehow.  But let me reassure you this is impossible due to rule #1 since Axe will not support any commands to run BASIC programs or Assembly programs during the duration of the contest (other than the Asm() command which is forbidden).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 05:59:53 pm
If someone's data program looks like this for example:

PRGM:A
[[0,0,0,0,0,0][0,1,1,1,1,1][0,1,1,1,1,1][0,1,1,1,1,0]]

This is how you store a matrix in Ans, in BASIC. Axe data looks much different than that.

I guess you might be right that it shouldn't be a big problem, though. I just get worried because in the past, people tried to figure out loopholes in  my rules (in that case, to run ASM code without using Asm()) to use hybrid code, and I don't want something similar to happen again. I also try to take precautions in advance so when the contest ends, I don't have to disqualify full of entries because people thought they were allowed to do something.

Anyway, I noticed lately that I am getting harder and harder to be understood (including on IRC). I am not too sure why, but I am starting to question myself about my ability to communicate. I wonder if it wouldn't be best that I leave Axe help/features-related topics alone from now on?
Title: Re: Features Wishlist
Post by: Magic Banana on July 13, 2010, 06:12:22 pm
I've got a feature request: Sprite Transformations. Not the complex things like warping or skewing, but flipping and rotating tiles. I'm working on some maps, and I would like to save space by flipping tiles rather than create a whole new tile just for it. There doesn't seem to be any easy way to go about doing these things, so yeah. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 06:21:01 pm
Another feature request would be the ability to use Copy the following way, for example:

Conj(L1,L3+300)r

Instead of being forced to use pointers without any offset (like the +300), if you get what I mean.

Just an example.

The code above gives a BAD SYMBOL error, btw.
EDIT nvm, I forgot to define the size x.x, my bad
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 06:21:22 pm
The only problem with that, would be that it would most likely increase the length of the sprite routine.  I would just do another sprite.  It gives you more options that way.

[EDIT] @DJ What exactly would that do?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 06:27:36 pm
Nvm my post above, I forgot to define the size, which is why I got an error. my bad x.x
Title: Re: Features Wishlist
Post by: _player1537 on July 13, 2010, 08:16:27 pm
I seem to recall something on cemetech doing this...  I'll check real quick (in asm)

Edit: http://www.cemetech.net/forum/viewtopic.php?t=4264&sid=0d23df6917b27ead9b7f1052003327a1
Wasn't exactly what I thought it was (reverses HL, not just L) ... but meh
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:11:16 pm
@DJ, no you are being clear, I think it is me who is not being clear.  In the example you posted, if someone wants to format their data like that then that's their decision (although kind of a stupid one given you can get much higher efficiencies with your own formats).  My point was that you can't ban certain data layouts just because they resemble BASIC.

Sprite rotation is actually much trickier than flipping, those are both on the wishlist already.

Something I was wondering though, would anyone be interested in specialty sprite routines?  Sprite routines which are designed for very specific applications.  Some ideas I had were:


Would anyone be interested in any of these?  I would probably use the Plot1() - Plot3() tokens.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:13:53 pm
Can you explain the first one a little better?  I don't quite understand it.
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:25:21 pm
Here is the fruit sprite in Pyoro.

Layer 1 is 0 and Layer 2 is 0: Transparent, these pixels will be ignored when the sprite is drawn.
Layer 1 is 0 and Layer 2 is 1: A white pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 0: A gray pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 1: A black pixel will be drawn here.

Layer 1:
01110000
10001110
11100001
00010101
00111011
01101000
01111000
00110000
Layer 2:
01110000
11111110
11111111
00011111
00111011
01111000
01111000
00110000
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:28:40 pm
So would you still need to use the buffer and back-buffer?  If so, I thought this was already implemented.
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:30:54 pm
No, currently a 3 level grayscale sprite is drawn like this:
00 = White
01 = Gray
10 = Black
11 = Black

and there is no way to do transparency without adding an extra sprite layer.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:37:06 pm
So no buffer/back buffer, and transparancy.  Oh yes, please implement that!  I don't know about aligned 16x16 sprites, but unaligned would work.  I really don't think unclipped sprites is a good idea, because I will probably be the first one to corrupt something.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 10:06:51 pm
@DJ, no you are being clear, I think it is me who is not being clear.
Aaah ok, well I wondered because in the recent few weeks, there were often people being confused at stuff I said on IRC, so I wondered if something wrong was going on with me or something x.x. Maybe I am just a bit tired and not double-checking my stuff well enough.


3 level gs compact masking seems cool, btw. Idk about the others, though, because I expect to mostly use unaligned stuff most of the time, like in Supersonic Ball
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 01:36:13 am
All of those sprite features sound amazing! The 16x16 would definitely help for the bigger sprites, and the unclipped sprites sounds awesome for getting that extra speed. The clipping would also help and save space for making grayscale masking. Man, all of those sound great.  :D
Title: Re: Features Wishlist
Post by: squidgetx on July 14, 2010, 10:57:57 am
Unaligned sprites i think would be nice as long as they use a different command so then ppl who need to draw stuff offscreen don't get messed up w/ it.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 14, 2010, 11:10:24 am
I prefer the first, and the others I won't use very often I guess, but when it doesn't take too much time, they could also be very helpfull in certain circumstances, like you said.

BTW, how are you going to implement linking? Are you giving us the possibility to write to the linking ports like they where memory? Or will we get only the option of sending a variable item and then waiting while it is being send?

I was thinking by myself of using Send() for just writing data to the linkport, which would be usefull for music or selfmade things,
and Get() for requesting data from an other calculator, which should be in some Pause-mode or something with the command Rect(), which could be changed to React()
Title: Re: Features Wishlist
Post by: FinaleTI on July 14, 2010, 11:15:01 am
The special sprite routines sound awesome! I would love to see them implemented.
Title: Re: Features Wishlist
Post by: Quigibo on July 14, 2010, 01:14:08 pm
Ok, I think I'll just stick to the compact masking routine and not the others.  The second one is easy to make with the Axe language itself and the third is probably unnecessary.  But I did think of ANOTHER Dispgraph routine I might add.  I have too many r modifiers so it might be an o modifier but it would use the extra clock cycles, which are normally wasted, to clear the buffer at the same time as drawing to the screen so you never need a ClrDraw.  It would speed up programs using that a lot probably because ClrDraw is a slow OS routine.

Linking can work 2 ways.  You can either do manual linking; setting the individual lines high and low and writing the link routine yourself, or automatic linking; using my own assembly routines.  So I assume you are asking about my built in routine.  The way it works is that it is mostly controlled by the sender.  It is up to the receiver to check the linkport constantly to see if a byte is trying to be sent, if no byte is being sent, the linker proceeds as normal and does not wait.  The sender however will wait for the receiver to confirm that it got the message that it needs to receive the byte.  You will specify a timeout for the Send() routine so that the calculator doesn't freeze if you disconnect the other calculator.  The sending command will return a 1 or 0 depending on whether it was able to send the byte.  The receiver will return a -1 if no bytes were sent or the byte itself if one was.  I will explain it better when I actually have the commands added.
Title: Re: Features Wishlist
Post by: Builderboy on July 14, 2010, 02:19:32 pm
ClrDraw is slow?  Isnt it just a matter of 0->{L6}:Fill(L6,768)?

And automatic linking sounds like an excellent idea :) Kind of like a 1-up of Omnicalcs Linking features.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 14, 2010, 04:33:20 pm
Could u please change the Line() command to behave the same as the BASIC Line() command? I am namely converting my BASIC data to the Axe format, and I use the Line() command with it.

with 'behave', I mean which pixel is turned on when u draw Line(0,1,2,0) for example; pixel (1,0) or (1,1)
In BASIC this is just a little bit different, and therefore some of my converted graphics look ugly.

in BASIC the pixel which is nearest to the left top of the screen is set, so in my example BASIC would choose for (1,0), but Axe chooses (1,1) :(
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 05:37:54 pm
For the inverted Line, it' s a little tedious, but you can do:
Code: [Select]
DrawInv
Line(X1,Y1,X2,Y2
DrawInv
Or you can just do DrawInv once, draw all of your white lines, then use DrawInv again.
Title: Re: Features Wishlist
Post by: nemo on July 14, 2010, 08:13:51 pm
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 08:56:06 pm
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.
Eh, Pxl-Change?  ???
Title: Re: Features Wishlist
Post by: nemo on July 14, 2010, 09:04:13 pm
it already has a use, so it may be a bit confusing to use. i'm not sure what token would be used, just thought it seemed like a relatively simple operation. i imagine you could do this with the exch() command and some very tricky modular arithmetic in the free RAM area L6, if anyone wants to try... i'll probably attempt later.
Title: Re: Features Wishlist
Post by: Quigibo on July 14, 2010, 09:07:14 pm
Not inverting, swapping separate locations.  Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way.  I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 15, 2010, 01:36:48 am
Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:
Code: (Axe) [Select]
Exch(L3,L6,768)
Line(0,0,96,64)
Exch(L3,L6,768)
I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.
Title: Re: Features Wishlist
Post by: squidgetx on July 17, 2010, 08:32:19 pm
Not inverting, swapping separate locations.  Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way.  I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.

Damn.
Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:
Code: (Axe) [Select]
Exch(L3,L6,768)
Line(0,0,96,64)
Exch(L3,L6,768)
I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.

ummmm i guess...(a little sleepy right now)
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 02:19:11 am
I've always wondered, why does grayscale work on 6mhz, but not 15? It would seem like it would be so much better running on 15mhz, probably flickerless, but it just doesn't. Can anyone explain how that works? Since I'm here I guess I can request 15mhz grayscale if possible.
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 02:52:57 am
Nope, the LCD is so slow that if you try to write that data any faster than its slow speed, it causes weird graphical glitches.  Its more efficient to have the routines in 6MHz because then I don't need to add as much extra pausing code.  Even the 4 level grayscale that calc84maniac wrote was too fast for even 6MHz so I still need pauses, just not nearly as many as I would in 15MHz mode, so you end up with a routine that takes less memory.
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 03:04:11 am
Oh, that explains it. That's too bad, I could really enjoy the speed of 15mhz with grayscale graphics, but I guess I have to settle with monochrome for speed. While on the subject of grayscale, how much slower does adding extra shades of gray make drawing? Like going from 3 -> 4 or even other numbers such as 4 -> 5 and 5 -> 6?
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 03:25:02 am
All the routines are almost exactly the same speed since they are limited by the LCD speed rather than the CPU speed.  Even if I were to write an 8 level grayscale routine, odds are, it would be just as fast as the 4 level or the 3 level or the monochrome.  The only speed you would be gaining from monochrome is that you don't have to update the LCD as often.
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 03:44:00 am
Really? Interesting, I always that that it took more to draw out grayscale, with the buffers and all. So, if I were to run a program at 15Mhz, but clock it to 6Mhz when drawing, would there be a significant change in speed, or is it the drawing itself that slows the programs down so much?
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 03:50:24 am
Yeah, its the drawing itself since you're drawing twice as many sprites, each one to 2 buffers.
Title: Re: Features Wishlist
Post by: Darl181 on July 19, 2010, 04:16:31 pm
New request.
When ReturnIf is called, it would be nice if the Fix tokens were taken care of automatically.
Say the person called Fix 3.
ReturnIf could do the Fix 2 on its own.
Title: Re: Features Wishlist
Post by: nemo on July 19, 2010, 04:16:35 pm
Darl181 has a neat idea in the Your Projects Post and Critique thread. (http://ourl.ca/4161/103124) his idea is to have the statement ReturnIf (and presumably Return!If) automatically set Fix # statements to their defaults. So if in a program you had Fix 1 at the beginning, if you had a ReturnIf statement, the program would automatically set Fix 1 (large sized fonts) back to Fix 0 (small sized fonts). this way you wouldn't need to use If (EXP):Fix 0:Return:End.

ninja'd by himself.
Title: Re: Features Wishlist
Post by: calcdude84se on July 19, 2010, 04:18:23 pm
That might not work, since you wouldn't want those flags reset every time you returned from a subroutine. Better is to do as I suggested (in the same thread), or possibly have a token that adds the equivalent of this code automatically.
Automatic cleanup would be nice in any form, though.
Title: Re: Features Wishlist
Post by: Darl181 on July 19, 2010, 04:25:24 pm
Beat you to it ;)
Four seconds!? wow

The return descriptions confused me for a bit.
I think I'll print out that part of the thread and put it in my binder with my commands list.
Title: Re: Features Wishlist
Post by: Magic Banana on July 19, 2010, 06:44:35 pm
Hmm, I guess what they would be looking for would be a 'reset to default settings' kind of action, which would actually be really interesting actually. Maybe have a number (not sure if all of them are taken already) which resets all of those text and drawing commands to the TIOS default so that instead of remembering what you changed and then putting a bunch of Fix # and hoping you got them all so instead of putting a combination of Fix 0 Fix 2 Fix 4 Fix 6 Fix 8, you could just have Fix 10 (or something) to make sure that all of them are default.

I guess you can always make it part of ClrHome as well, seeing as the only reason you call it is when you are closing the program.
Title: Re: Features Wishlist
Post by: Quigibo on July 19, 2010, 06:45:23 pm
@Darl That would be a huge inefficiency, but you did remind me of the fix extender idea that I forgot about.  You can reset all the fix modes at once by chaining them together like "Fix 0246" for instance to set modes 0,2,4, and 6 in a single line of code for convenience.  I might have time to add that next release.

Also another feature I will be adding is "Temporary Pointers" which are similar to static pointers.  For times when you only need to use some data exactly once, you will be allowed to do things like Pt-On(X,Y,[0123456789ABCDEF]) to both create the data in memory and return the pointer to that data in a single line.  Its just as efficient as regular static pointers but has the advantage of not taking up any extra pointer names so you are less limited by the 150 name limit.  This also will apply to Strings, Data(), and the Zeros() commands which can also be used to return temporary pointers.
Title: Re: Features Wishlist
Post by: calcdude84se on July 19, 2010, 07:15:47 pm
Cool. We can already use it with strings for Disp, but a more general application will be nice. Fix extender could be useful too, even though it only saves source code space.
As for automatically resetting flags on exit, my idea was to have the program start with
Code: [Select]
sub(M
Fix 0
Fix 2
Fix 4
Fix 6
Return
Lbl M
which would automatically reset them on exit. (Or create a dedicated token for this)
Title: Re: Features Wishlist
Post by: Tribal on July 19, 2010, 09:54:38 pm
Would it be possible to specify multiple arguments for 'Fix' say using a comma to separate each one?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 19, 2010, 10:40:41 pm
@Darl That would be a huge inefficiency, but you did remind me of the fix extender idea that I forgot about.  You can reset all the fix modes at once by chaining them together like "Fix 0246" for instance to set modes 0,2,4, and 6 in a single line of code for convenience.  I might have time to add that next release.

Also another feature I will be adding is "Temporary Pointers" which are similar to static pointers.  For times when you only need to use some data exactly once, you will be allowed to do things like Pt-On(X,Y,[0123456789ABCDEF]) to both create the data in memory and return the pointer to that data in a single line.  Its just as efficient as regular static pointers but has the advantage of not taking up any extra pointer names so you are less limited by the 150 name limit.  This also will apply to Strings, Data(), and the Zeros() commands which can also be used to return temporary pointers.
Nice ideas, especially the pointers one. I always wished I could do stuff like Text(0,0,"HI PEOPLE", because otherwise it can be a bit annoying to have to store text to pointers just to use it in the title screen options, for example.
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 10:57:06 am
Tribal: Above, Quigibo mentioned that he plans (or will consider planning) to allow chaining them like Fix 0246, which is even better than using commas. :)
Title: Re: Features Wishlist
Post by: Darl181 on July 20, 2010, 02:36:23 pm
Maybe have a number (not sure if all of them are taken already)

Aren't there some tokens left in the VARS menu?
The Window ones, for example.

I may be really behind on the poll thing ↑↑↑, but it would be nice if you could also write to OS vars.  That way, a sprite editor could store the hex code in an OS string or a picture editor save to an OS picture.
Just a thought.

Oh, and I remembered this morning about the increase in sound quality, recompiled my old sound program, and inadvertently put the headphone in my ear.  And got blasted by the volume.
Might a volume control be possible?
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 03:08:32 pm
The poll option is OS Var support, not just reading. If you're talking about "reading from archive", then no. There are very few programs that write directly to archive.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 20, 2010, 04:03:34 pm
Darl181 was the sound really that loud? Was it from a real calc? Because if I remember correctly, even with really good headphones, sound coming out of the calc link port was usually very low. You had to use loud speakers to get decent volume.
Title: Re: Features Wishlist
Post by: Quigibo on July 20, 2010, 10:25:47 pm
I've finished the popular option "OS var support".  You are now able to Create, Read, Modify, or Delete pretty much any OS variable you can think of, even obscure ones like GDBs.  The only complication right now is that it is very difficult to read or write to any structure that uses floating points like Reals, Lists, and Matrices.  I will probably have to add floating point conversion commands to simplify this, hopefully it will be in the next version, I'm not sure yet.  But for now, strings, pictures, programs, and appvars are extremely useful as external variables.  The best part is, there is no new syntax, you use the same commands you're already used to and plus the addition of DelVar which is intuitive to use.

I am also half way done with linking and I'm just about to start working on reading from archive, just have to think of the simplest possible way to approach it so its easy to use and not very confusing.  It will probably consist of a CopyToRam command and a ReadByte command for the actual reading.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 20, 2010, 10:30:56 pm
Oooh nice to hear :D. Good luck with real/list/matrices. I think for now just string and Ans support would be very good, though, for making some libraries. I hope you can figure out something easy for the other features.
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 10:49:37 pm
I'll bump this, as it relates to reading directly from archive.
Can we have a command to create a temporary RAM copy of a variable in RAM?
Maybe something like token("string"), where the command takes a string that is the name of the variable and returns a pointer to the data of the temp var, or 0 if failed (not enough RAM, variable doesn't exist, etc.)
Title: Re: Features Wishlist
Post by: calcdude84se on July 21, 2010, 06:51:00 pm
This is more like a feature retainment request than a feature request, but you could you keep the single-argument Output(?
Even if 2-argument with constants is automatically optimized, it could still be useful with certain expressions involving variables.
While I can't think of a good example off the top of my head, I'm sure one exists :P
Title: Re: Features Wishlist
Post by: calcdude84se on July 22, 2010, 09:41:42 am
And, bumping another feature request. Can there be versions of sin( and cos( that support 8.8 FP?
Title: Re: Features Wishlist
Post by: ztrumpet on July 22, 2010, 11:18:12 am
This is more like a feature retainment request than a feature request, but you could you keep the single-argument Output(?
Even if 2-argument with constants is automatically optimized, it could still be useful with certain expressions involving variables.
While I can't think of a good example off the top of my head, I'm sure one exists :P
I'd like to see the one argument Output( as well.  I use it a lot, and it should be easy to keep.  Thanks! :)
  • 3 level grayscale compact masking for 8x8 sprites.  I used this in Pyoro, it basically allows you to use the unused bit combination as an extra transparency layer so you can have automatic grayscale masking without needing an extra mask layer. 00=transparent 01=white 10=gray 11=black
  • 16x16 aligned sprite drawing.  Its a super fast and small way to draw 16x16 sprites when they're aligned horizontally and also using a more convenient array for the sprite data than trying to make 4 8x8 sprites.
  • Unclipped unsafe 8x8 sprite drawing.  Speeds up sprite drawing significantly for sprites that are always drawn completely on-screen for applications where speed really matters.  But it would crash/corrupt data for sprites drawn partly or fully off-screen
Would anyone be interested in any of these?  I would probably use the Plot1() - Plot3() tokens.
I would like all three of these.  They all sound useful, and I really want the first one. :)
Title: Re: Features Wishlist
Post by: nemo on July 22, 2010, 09:28:52 pm
i second ztrumpet. the 3 sprite features he quoted would help so much. mainly the last one, but those would definitely be something to look forward to.
Title: Re: Features Wishlist
Post by: Quigibo on July 22, 2010, 10:56:56 pm
Well the first one for sure I will add since it can be used for monochrome masking as well, but I'm still not so sure about the other ones since the 2nd one can be written in Axe and the 3rd one seems like a bad idea.  They won't be a priority right now or in a near release.

I guess I'll keep the single line coordinate method for Output() and Text() just in case.  Also, there is no reason to have a separate 8.8 routine for sin because you can do basically the same thing with this: sin(A/256)*2 The only advantage of a separate routine is to use a little bit of the decimal part to get slightly higher accuracy, but its not going to be that much better.

In other news, I've got archive reading completed and I'm rewriting the tutorial about it because there is a lot of new information to learn about, but lucky no new commands.
Title: Re: Features Wishlist
Post by: calcdude84se on July 22, 2010, 11:06:39 pm
Can't wait till Saturday! ;D
Operator overloading seems fun...
And okay for not having extended sin( and cos(, I see what you mean
Keep up the good work! :D
Title: Re: Features Wishlist
Post by: ztrumpet on July 23, 2010, 10:38:58 am
Well the first one for sure I will add...
I guess I'll keep the single line coordinate method for Output() and Text()...
I've got archive reading completed...
Yay! ;D

I wish I was here tomorrow, but it looks like I have to wait an extra week... :(

3rd one seems like a bad idea.
I think the third one is an awesome idea, just make sure to offer plenty of warnings in the readme. :D
Title: Re: Features Wishlist
Post by: Raylin on July 23, 2010, 11:45:17 pm
Was sprite rotation coming in 0.4.0?
Title: Re: Features Wishlist
Post by: Builderboy on July 24, 2010, 01:16:49 am
Sprite rotation would be extra useful.  Rotating by angles other than multiples of 90 might be extremely difficult and slow, but 90 degree rotations, and flipping as well i think would be very useful, and hopefully not to difficult to implement.
Title: Re: Features Wishlist
Post by: SirCmpwn on July 25, 2010, 03:12:15 pm
Writing to new kinds of variables would be tedious, but is already possible if you know the right way to tickle the VAT.
Also, I have a couple feature requests that would be *very* nice for a project of mine, and would probably be quite easy:
Call/Jump to addresses defined at runtime, like sub(E9D95
Access to label values, like:
Lbl A
LA->A
Where A would end up containing 9D95.
Title: Re: Features Wishlist
Post by: Builderboy on July 25, 2010, 03:23:16 pm
That should be very easy to implement, since it has a direct assembly counterpart.  Also the Label thing might also be really nice.  Whaat say you Quigibo?
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 04:17:12 pm
Forming vector tables is a very useful application of this. Even if it's a more advanced use, I'd like to see it too :)
Title: Re: Features Wishlist
Post by: Quigibo on July 25, 2010, 05:51:24 pm
I still don't feel comfortable with arbitrary jumping because its generally dangerous and isn't really useful to the average programmer.  You would have to know a lot of assembly to be able to use it and that's not the goal of the project.  You can already do that anyway with Asm(C3<Label in little endian>).

I'll eventually have a switch statement though which will be a small vector jump table to jump to a list of possible labels based on a value, but its only for labels defined in the program itself.  For instance, Switch(A,L0,L1,L2,L3) will jump to L0 if A is 0, L1 if A is 1, L2, if A is 2, and L3 in all other cases (the default).
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 05:57:48 pm
Well, for using inserted opcodes, you assume we already know the label address, which we don't :P
Switch sounds interesting, but you might want to allow an alternate format that allows choosing the values as well.
But I can understand what you're saying, and switch seems like it will be sufficient.
Keep up the good work :)
Title: Re: Features Wishlist
Post by: Quigibo on July 25, 2010, 06:13:44 pm
That is true and I was thinking about that.  Maybe I can have special opcodes in the Asm() command (kind of like how you can use pic vars in the [] command to insert pictures) but in this case to directly insert labels.  For instance, some syntax similar to this: Asm(C3"AB") would be exactly the same as Goto AB.  I mean, the only time you would even need the labels as numbers anyway is in asm code and it would be super convenient to be able to insert labels directly into the code at multiple locations and its way more customizable.  I could have insertions for other things too like the Axe variables, buffers, and maybe even axe subroutines.
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 06:44:13 pm
That sounds nice. I'd like that. :)
Title: Re: Features Wishlist
Post by: _player1537 on July 25, 2010, 10:47:27 pm
ooh, not sure if anyone else would use this, but what about installing a hook that interprets when you press ON-something, and have the something be like one or likewise.  Then when you press that key combo, compile a specific program.  Maybe ON-Sto since they are right next to each other.
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:02:21 pm
On-demand compiling?

Wouldn't that be memory-clogging?
Title: Re: Features Wishlist
Post by: Runer112 on July 25, 2010, 11:04:10 pm
Drawing sprites to an arbitrary buffer would be nice. I'm working on a game that will require at least 2 extra buffers, and I'm sure that writing my own sprite routine in Axe would be nowhere near as compact/fast as your built-in sprite drawing routine.
Title: Re: Features Wishlist
Post by: _player1537 on July 25, 2010, 11:04:52 pm
I'm sorry, what do you mean?  Basically all the feature would do is skip through the process of opening axe and going through the menu to get to your program to compile

Edit: that was @raylin, not runer
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:08:58 pm
@Runer: What you just said is an action in Axe. Look through the documentation again. You'll see it.
If not, the command is EXP->DispGraph.

@_player: Oh. Okay. You want Axe to have a hook so that you can compile quickly. I like.
Title: Re: Features Wishlist
Post by: Runer112 on July 25, 2010, 11:26:13 pm
@Runer: What you just said is an action in Axe. Look through the documentation again. You'll see it.
If not, the command is EXP->DispGraph.

@_player: Oh. Okay. You want Axe to have a hook so that you can compile quickly. I like.

Drawing sprites to an arbitrary buffer, not drawing an arbitrary buffer to the screen.
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:36:02 pm
Ah. My mistake.

*Raylin cocks a shotgun and puts his temporary dyslexia in check.
Title: Re: Features Wishlist
Post by: calcdude84se on July 26, 2010, 10:51:00 am
Could we have more pointer-specific operations, especially since a "file" is just a page-address pair?
For example, could we have an "address-of" operator that could be used on A-Z and theta (an perhaps r1 to r6 and Y0 to Y9)? (The only real application I see here is that it would make token-drawing on the graph screen easier)
And perhaps with that we could also have other means to use the "files" as generic pointers to flash?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 26, 2010, 11:50:09 am
I'm a bit confused about how to read from the Archive.  Let's assume that I want to read data from AppVar MyAppV, which is archived.  How would I do this?  And could I exploit this, possibly with some dummy entries in the VAT, to force a page swap?
Title: Re: Features Wishlist
Post by: calcdude84se on July 26, 2010, 11:55:01 am
Code: [Select]
GetCalc("appvMyAppV",Y1
{Y1-2}r-1->S
For(X,0,S
Disp {Y1+S}>Char
End
Also, as far as I can tell, the actual reading is done with a bcall (that should probably be changed), which means the page would be switched back. It could be possible, but, as above, I'd like official support for page-address pointer pairs.
Title: Re: Features Wishlist
Post by: Runer112 on July 27, 2010, 03:39:10 am
By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.

Ah ha! I found it! I knew you posted something like this a while ago. It sounds like drawing sprites to an arbitrary buffer would be a pretty quick feature to implement  ;)
Title: Re: Features Wishlist
Post by: Quigibo on July 27, 2010, 03:58:16 am
Alright!  Alright!  I'll include it in 0.4.1 since you're helping me debug that other problem and since I need things to add and this is extremely easy.  The syntax will be Pt-On(X,Y,Pic1)→BUFF.  I can also use a similar technique with ClrDraw and DrawInv, but I'm not sure if I'll have time for that right now.
Title: Re: Features Wishlist
Post by: Runer112 on July 27, 2010, 05:19:50 am
Yay! :D I wouldn't worry too much about ClrDraw or DrawInv, as those can be done pretty easily and quickly anyways.
Title: Re: Features Wishlist
Post by: jnesselr on July 27, 2010, 10:51:25 am
yeah, clearing can be done by setting the buffer to 0, and inverting can be done by xor'ing all the bytes with 0xFF.  I don't really see the point, but I guess it could be useful.  So I'm guessing buff->DispGraph is for displaying?
Title: Re: Features Wishlist
Post by: qazz42 on July 27, 2010, 10:53:00 am
Safty features, I hate how if I make a disp A with no dec at the end, I am screwed with the eternal text displaying
Title: Re: Features Wishlist
Post by: SirCmpwn on July 27, 2010, 11:30:32 am
I still don't feel comfortable with arbitrary jumping because its generally dangerous and isn't really useful to the average programmer.

This is all fine, if you only want Axe to be used by the average programmer.  If you never want Axe to be used for advanced purposes, this is perfectly fine.  But getting label values with L and calling arbitrary subroutines would be quite useful for a myriad of purposes, and it would be useful for tons of competition purposes, too.  If you are concerned with people screwing it up, put it in an "Advanced Commands" section or something.  This kind of thing would open Axe up to serious programmers, for serious purposes.
Title: Re: Features Wishlist
Post by: Raylin on July 27, 2010, 01:28:39 pm
Shaky ground you treadin' on, SirCmpwn. Mind that post's sharpness.

In any case, I would suggest _player's idea of keyhooking the COMPILE command in Axe.
Title: Re: Features Wishlist
Post by: Eeems on July 27, 2010, 01:47:42 pm
That was a little sharp SirCmpwn, try to remember to remain polite. I do agree though I would like that feature.
I would also like the keyhook for compiling. :D
Title: Re: Features Wishlist
Post by: calcdude84se on July 27, 2010, 03:59:43 pm
Qazz, it only messes up what's displayed, it doesn't crash. Putting such features could be difficult because Disp A could actually be useful. Not much can be done there ;D
As for using labels literally, yeah, it probably should be reserved as an "advanced use."
The suggestions I've given (definitely "address-of" and less likely advanced operations for "files" (or what I'm calling extended pointers)) probably don't need to be given any "advanced" label, though.
I agree a keyhook to compile would be nice. :)
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 05:24:48 pm
This is all fine, if you only want Axe to be used by the average programmer.  If you never want Axe to be used for advanced purposes, this is perfectly fine. This kind of thing would open Axe up to serious programmers, for serious purposes.

Calm down SirCmpwn, this is Quigibo's program and he's going to support the features he deems necessary.  He is keeping in mind all of his users, and if he doesn't support a feature you want, dont get angry.  It really has very little practical support and could cause more trouble than its worth.  If you really need it super badly you can always write some Asm code to do it for you, Axe is as advanced as you make it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 27, 2010, 06:06:27 pm
I think if advanced commands are added, there should be an advanced section and a warning that those commands are only for experts. Maybe in a different readme file or something. Axe is meant for people who want an easy language like TI-BASIC, so hard commands should probably have a special section. That said, those commands are not a priority at the moment, I think, since Quigibo is focusing on the ease-fullness. I personally find fixed points hard enough x.x so I stayed away from them.

After the new token thing, I learned that it would be best to let Quigibo add features in order he decides to add them or that he wants the majority to add them (poll). I think it is already pretty good, else it would never have been featured on ticalc.org and it would not have 6000 posts. It's not a good idea to badmouth him for not wanting to add a feature, not that it would make the feature get added necessarly, anyway.
Title: Re: Features Wishlist
Post by: Quigibo on July 27, 2010, 06:17:36 pm
Well I didn't find it that rude, and its nice to see some criticism for a change, I was getting worried  ;)

There are a few technical considerations because its not as simple as a number substitution since the labels aren't actually well defined until the end of the first pass, so its a little more difficult.  That also means the "label values" start using up the available space for label names (there is a 150 name limit for labels).  Secondly, just getting the value of the label is not very useful unless you can actually jump or call to that address.  I'd like to see you propose an intuitive syntax for that since I can't think of a good one off the top of my head.  Lastly, it allows for arbitrary execution of assembly code which is against the rules of the contest if that's what you were planning to use it for.

EDIT: Also, I reset the poll since it was getting old and moldy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 27, 2010, 06:22:21 pm
Yeah it would be against the rules. There are actually other ways to run ASM, too, apparently, as player mentionned to me once, but that would still be against the rules, too (same for every potential exploits people find)

As for features, you should add 64 level grayscale, pixel shading/ambient light 3D textures and 150 MHz Nspire 84+ emulation mode to the poll.
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 27, 2010, 07:20:12 pm
I'm still waiting for mutliplayer linking, so I voted that way again. I expect that more people will want sprite rotation though. =)
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 07:24:41 pm
I chose sprite flipping :]
Title: Re: Features Wishlist
Post by: nemo on July 27, 2010, 09:16:53 pm
same with me, builderboy. two more features i can add to my tilemapping program (:
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 09:44:36 pm
I have another feature request.  Could it be possible to support every single character token in the String conversion routine? It would be handy to not have some of the characters change themselves while in Axe :]
Title: Re: Features Wishlist
Post by: jnesselr on July 27, 2010, 10:08:24 pm
What about USB support.  I know it would be difficult, but could you do it?
Title: Re: Features Wishlist
Post by: nemo on July 27, 2010, 10:18:25 pm
not sure if this is a relatively simple command, but could we have a Prompt/Input function? just like in BASIC, you have the user enter a number and it's stored to a program-specified variable.
Title: Re: Features Wishlist
Post by: alberthrocks on July 27, 2010, 10:20:28 pm
@graphmastur: Pretty sneaky. ;) Did you get any ideas for the calc side of things (assuming you know Z80 asm)?

@Quigbo: Oh yes, that's definitely a must. (nemo's idea)
That shouldn't be too hard to implement. ;)
Title: Re: Features Wishlist
Post by: Raylin on July 28, 2010, 12:06:32 am
Sprite flipping will be the $h!t.
On top of that, multiplayer linking will be so awesome...
:D

Now, if all of those features were in the next version (0.4.1)...

:D
:D
:D
Title: Re: Features Wishlist
Post by: SirCmpwn on July 28, 2010, 10:40:27 am
Well I didn't find it that rude, and its nice to see some criticism for a change, I was getting worried  ;)

There are a few technical considerations because its not as simple as a number substitution since the labels aren't actually well defined until the end of the first pass, so its a little more difficult.  That also means the "label values" start using up the available space for label names (there is a 150 name limit for labels).  Secondly, just getting the value of the label is not very useful unless you can actually jump or call to that address.  I'd like to see you propose an intuitive syntax for that since I can't think of a good one off the top of my head.  Lastly, it allows for arbitrary execution of assembly code which is against the rules of the contest if that's what you were planning to use it for.

I was just trying to make my opinion clear, not offend anyone.  Of course it is Quigibo's project, I just thought it would be cool and would open the doors to more advanced things.  This would be useful for a GUI engine, a physics engine, lots of different engines ;), and I can think of a practical application being using the Hatchet routines loaded in L1 (the code in L1 is pure Axe, by the way).  Hatchet could also use the label values to actually load the code.  It might be useful to programs to use my tilemapping routines and input routines, and all the other routines Hatchet would provide and still be valid for the contest.
As for a possible syntax, how about accessing label values with LLABELNAME (sort of like EHEX) and doing arbitrary calls with sub()r?

not sure if this is a relatively simple command, but could we have a Prompt/Input function? just like in BASIC, you have the user enter a number and it's stored to a program-specified variable.

There are a few routines that do this already, I can scrounge one up for you later today.
Title: Re: Features Wishlist
Post by: calcdude84se on July 28, 2010, 07:56:36 pm
For USB, even we ASM programmers don't completely know how it works. :P It's also significantly more complicated than the link port. (I wish Quigibo good luck if he undertakes it ;D)
With relation to an input routine, they are, well, whole routines. Since SirCmpwn said he'd make one for you, I'll leave it at that.
Title: Re: Features Wishlist
Post by: Quigibo on July 28, 2010, 11:27:41 pm
I just want to be clear about how sprite rotation and flipping will work because I don't want people thinking its something that its not.  The commands take 1 argument; the pointer to the 8x8 sprite and the return argument is a pointer to an 8 byte buffer in an unused safe ram area outside of L1-L6.  This area holds a copy of the "new" sprite after the transformation.

Code: [Select]
Pt-On(X,Y,FlipH(Pic1))
I was originally thinking of having a second argument allowing you to specify what area of ram to use as the temporary buffer, but then I realized that it would be easier to use, smaller faster code, and take up no extra visible memory with the single argument instead.  The only problem though is that you cannot  nest these routines together, maybe with an exception of the flip horizontal.  Like for instance RotCC(FlipV(Str1)) will fail because the input and output buffer are the same.  Therefore, I might still have the second argument, but it would be optional.

Also, the subroutines themselves that do the flipping are around 2 sprites in size and it costs an extra 3 bytes each time you call them and is obviously slower than just using a regular pointer so you'd have to be really desperate for space with massive amounts of sprites to even consider using this.
Title: Re: Features Wishlist
Post by: nemo on July 28, 2010, 11:31:58 pm
is the following code valid?
Code: [Select]
Copy(FlipH(L1),L1,8)
Title: Re: Features Wishlist
Post by: Quigibo on July 28, 2010, 11:36:17 pm
is the following code valid?
Code: [Select]
Copy(FlipH(L1),L1,8)

Yes, absolutely.  Although this is theoretical syntax.  I haven't even chosen tokens or names or even finished most of the routines.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 29, 2010, 04:00:35 am
I voted Sprite rotating, flipping. This might come handy when we have several sprites that can be flipped. Smaller file size (although executable code size might increase slightly if the routine is large)
Title: Re: Features Wishlist
Post by: program4 on July 29, 2010, 10:20:08 am
I voted sprite rotation/flipping, because most other people chose that ;). Also, it might come in handy when you make a game that requires rotating of an object (like a ship).

Besides, multiplayer linking is only useful when you have two people, so it can wait until a later version release.
Title: Re: Features Wishlist
Post by: imPersonator on July 29, 2010, 10:20:46 am
What kind of rotation will it be?  Will it be possible to rotate 1 degree?
Title: Re: Features Wishlist
Post by: program4 on July 29, 2010, 10:27:18 am
It would be impossible to rotate an 8x8 sprite by 1 degree, because the sprite is simply not big enough. Maybe a 1 degree rotation would work for a much larger sprite, but it wouldn't look that great.
Title: Re: Features Wishlist
Post by: nemo on July 29, 2010, 04:36:27 pm
i think the rotations will be by 90°. though i would like to see 45° if possible.
Title: Re: Features Wishlist
Post by: jnesselr on July 29, 2010, 04:37:20 pm
90 degrees would probably be the easiest.  How could you do 45?
Title: Re: Features Wishlist
Post by: calc84maniac on July 29, 2010, 04:38:41 pm
It's definitely 90 degrees, considering that the inputs and outputs are 8x8 sprites.
Title: Re: Features Wishlist
Post by: nemo on July 29, 2010, 04:48:17 pm
i'm not sure how you would do it, i'm just saying that if it's possible it'd be cool to be able to rotate 8x8 sprites 45°
Title: Re: Features Wishlist
Post by: Quigibo on July 29, 2010, 09:02:33 pm
Yeah they're just by 90 degrees.  I've finished all the routines, I just need to implement the commands now.  The output sprite needs to be at least sqrt(2) times larger else there will be clipping during the rotation.
Title: Re: Features Wishlist
Post by: Quigibo on July 31, 2010, 03:22:23 am
I decided to stop the poll since I will probably have time for all 3 of those features next version.  Instead, I've decided to ask a more interesting one for a feature I don't plan on adding anytime soon if at all, but I'm very interested in what everyone will think of this.  If you're not sure what each option is referring to, all examples are the Super Nintendo versions of the game, you can see some videos of the games on YouTube to clarify.
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 31, 2010, 07:46:41 am
I personally think mode 7 would be awesome to see. I am curious though, wouldn't polygons be a bit slow?
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 10:44:39 am
Any/all of these would be amazing, but I think the one that would work the fastest and therefore have more uses is Mode 7.
Title: Re: Features Wishlist
Post by: Raylin on July 31, 2010, 10:45:36 am
^ This.

Also, I'm looking forward to some Mode 7.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 31, 2010, 10:52:01 am
Mode 7 sounds like a cool idea. Voted for it. It would be nice to see more racing games for the 83+ and maybe RPG world maps like Final Fantasy VI or Secret Of Mana/Evermore:
 

If you add Mode 7, though, I would recommend allowing the user to specify the height and Y offset of the Mode 7 display too.
Title: Re: Features Wishlist
Post by: jnesselr on July 31, 2010, 11:14:25 am
raycasting or mode 7 would be the best.  But how would you set up routines to handle it?
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 11:25:49 am
This site is aimed at the GBA, but it still wonderfully explains/demonstrates Mode 7 and provides, albeit customized for C programming and the GBA, the math behind it:

http://www.coranac.com/tonc/text/mode7.htm (http://www.coranac.com/tonc/text/mode7.htm)
http://www.coranac.com/tonc/text/mode7ex.htm (http://www.coranac.com/tonc/text/mode7ex.htm)

For Mode 7, you'd probably need something like the following:

Or you could just have the routine require all these inputted as arguments, but that would require the programmer to either give up a lot of the existing variables for this or designate annoying extra variables like {711+L1}r, {709+L1}r, etc.
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 11:53:56 am
I'm for polygons and mesh.  This, folks, is the same kind of 3D you get on a computer!  I would vote there, too, if I were you.
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 12:14:36 pm
I'm for polygons and mesh.  This, folks, is the same kind of 3D you get on a computer!  I would vote there, too, if I were you.

The question is, could you get a polygon engine to run quickly?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 12:15:15 pm
Probably not.
But it would be *sick.*
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 12:20:44 pm
Admittedly, it would be sick. But unfortunately its uses would be limited due to its inability to be used in realtime games. That's why I voted for Mode 7, it's probably the most reasonable option in terms of realtime usage.
Title: Re: Features Wishlist
Post by: nemo on July 31, 2010, 12:22:34 pm
can quigibo or a mod give us the option to change our vote?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 12:50:35 pm
Done
Title: Re: Features Wishlist
Post by: Quigibo on July 31, 2010, 02:47:10 pm
Polygons wouldn't be that slow as long as there was a small count.  I'd imagine that you could get a decent real time game with 50 onscreen edges  with more off-screen.

By the way, I was working on a mode 7 engine myself in the actual Axe Language.  At first it was really slow, less than 1fps, but i kept doing more and more optimizations and now I can get the entire lower half of the screen in mode 7 grayscale at about 8-10 fps which definitely has game potential.  However, I don't have rotation, just translation, incline, and FOV.

If I implement any of the 3D modes, the routines are going to be gigantic (probably combined 500-1000 bytes) since I won't care about size, just speed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 31, 2010, 05:09:10 pm
I think it should be fine. Such thing needs to be fast enough so I think the space it takes is worth it.

Btw, are you gonna use Calc84maniac mode 7 engine or are you making your own? His ran at like 20-30 fps I think, if not more. I think it was on SE, though.
Title: Re: Features Wishlist
Post by: Builderboy on August 01, 2010, 05:45:14 pm
3D i like the idea of Mesh and filled things, just because :P

On a separate note, i would like a request for 2 things, Libraries pleeeeeeeases :( and maybe a way to jump to certian lables from inside programs?  Like if you had a comment that was .Goto LB and you put your cursor on that line and pressed On+[anykey] it would jump to that label?  Im not sure if thats possible, just throwing that out there as a possibility.
Title: Re: Features Wishlist
Post by: matthias1992 on August 01, 2010, 06:10:31 pm
As far as 3D stuff goes, I at first voted mode7 but then revoted for polygons. I think polygons can be done if you don't have too many at the same time. I think it is just awesome if we could work with them! I can already imagine a on-calc model creator-viewer that stores models into appvars. I guess using the OP registers for the vertices would be the fastest?

mode7 has my second vote if there is such a thing. In terms of speed I still do recon it faster then poly's but it is 'less 3D' then the poly's.

Now here I am just gonna suggest something that is maybe out of bounds but I'll say it anyway. How about a combined mode7 and poly's? can you imagine a character (poly) walking around in a mode7 world? All the structures and trees would be poly's but the basic ground texture could easily be a mode7 'texture"

I am really looking forward to this!

On a side note I personally would like different tokens for Axe then for basic, but that is just me having hard times switching between the two.
Title: Re: Features Wishlist
Post by: Quigibo on August 01, 2010, 06:28:21 pm
Libraries might be possible very soon, I just need to make my code sightly more modular so I can read from multiple places at once.  I realized a while ago how complicated it would be to implement library files, so it will instead be pretty much identical to the C #include feature that directly inserts the code at whatever position you put it.  You can even put each subroutine in its own separate program.  The include files will not need Axe headers and in fact should not have them so then it doesn't crowd your compiling list.  If its not included in 0.4.2, it will definitely be in 0.4.3

The jumping idea is something I'm planning to add later.  Much later.  I'm planning on using hooks to add tons of new features to the BASIC editor (only for programs with an Axe header) like label jumping, sprite previews, calculator window without exiting, hex - binary - decimal converters, etc.  Really cool stuff, but its something I'd probably write after 1.0.0 comes out.
Title: Re: Features Wishlist
Post by: SirCmpwn on August 01, 2010, 08:21:05 pm
If you are planning those, I've always wanted to use recall like the homescreen.
For instance, pushing [2nd]+Recall should open the same text dialog, but should let you type in more than one token and execute it, and recall the answer.  I've wanted to do [2nd]+Recall length(Str1 but have never been able to.
Title: Re: Features Wishlist
Post by: Builderboy on August 01, 2010, 09:09:56 pm
The include files will not need Axe headers and in fact should not have them so then it doesn't crowd your compiling list.  If its not included in 0.4.2, it will definitely be in 0.4.3

That sounds really sweet :) I've been waiting for libraries for a long time now.  Right now i have a different system in place to go through code quickly :D I have a set of Pointers that i initialize at the beginning of m,y program, one for each subroutine.  Each subroutine its pointer at the very beginning.  By commenting out the initialization of the pointer, i can scroll to the sub instantly, which is much more useful than scrolling for a min to get to the bottom. 
 
Plus using libraries means that you can upgrade sections of code while still keeping a backup of that particular subroutine.  It all makes me very excited :)
Title: Re: Features Wishlist
Post by: Quigibo on August 02, 2010, 06:41:49 am
I just thought of something really useful that I can't believe I didn't think of before.  Its the fact that 2563 = 644.  The reason that's so important is that the labels, subroutines, and pointer names were all being stored as 3 byte entries.  Once byte for the type and 2 for the characters of the name itself.  But since I'm only using a few possibilities; letters, numbers, and theta, I can get away with storing that data in only 6 bits per entry instead of the full 8 bits of a byte.  So now the 3 bytes I was using in memory can suddenly hold 4 entries!  That means that all labels and pointers can now be up to 3 letters long instead of 2.  That one extra character actually allows you to spell comprehensible pseudo-words like sub(BUF) or Lbl MOV.  This wasn't a feature I was planning to add, but I just couldn't stop myself once I realized how easy it would be to do.

I don't think I will ever have enough RAM for the 7 character label names like I was planning unless I use the extra ram pages so this will have to do for now, at least its an improvement.

Also, I changed my mind about the Axe include files.  They will need a special header beginning with 2 periods instead of 1.  That way, you still have the Axe Tokens and eventually the Axe Editor to use when writing the subroutines.  But the extra dot will conveniently make them invisible from the compile list.
Title: Re: Features Wishlist
Post by: SirCmpwn on August 02, 2010, 08:29:39 am
I would be devastated if you started using the extra pages, which I do not have :(
Title: Re: Features Wishlist
Post by: _player1537 on August 02, 2010, 08:31:40 am
Didn't I read a while back that you might support filenames with more letters if some of them were lowercase?  Like LoseTheGame could also be called by sub(LTG)
Title: Re: Features Wishlist
Post by: souvik1997 on August 05, 2010, 02:01:01 am
Didn't I read a while back that you might support filenames with more letters if some of them were lowercase?  Like LoseTheGame could also be called by sub(LTG)

No, I don't think so.
Title: Re: Features Wishlist
Post by: Raylin on August 05, 2010, 05:39:40 pm
Custom keyhooks. Nuff said.
Title: Re: Features Wishlist
Post by: Builderboy on August 10, 2010, 12:23:50 am
When you get an Error Lable, could it tell you which Lable its missing?  The jump to Error doesn't help because it just jumps to the end of the program.
Title: Re: Features Wishlist
Post by: Runer112 on August 10, 2010, 12:35:51 am
When you get an Error Lable, could it tell you which Lable its missing?  The jump to Error doesn't help because it just jumps to the end of the program.

Looks like you're having the same problem as me, label missing errors being thrown with no missing labels to be found.
Title: Re: Features Wishlist
Post by: Builderboy on August 10, 2010, 12:48:34 am
no it was a missing label actually, and it took me ages to search through every single label individually to find the one that was missing.
Title: Re: Features Wishlist
Post by: Runer112 on August 10, 2010, 12:52:51 am
Oh, at least you could find it and fix it.
Title: Re: Features Wishlist
Post by: LordConiupiter on August 13, 2010, 04:17:02 am
someting I would like to have: when you have "prgmA01" in your code, and when you hover that with your cursor, and then press [Enter], that then the program A01 is opened. Is this possible?
Title: Re: Features Wishlist
Post by: Builderboy on August 16, 2010, 12:38:25 am
Might it also be useful when an error is produced in an included program which is archived, to say which included program the error occurred in? Otherwise it might be difficult to track down which included program is misbehaving.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 16, 2010, 01:27:28 am
As for Mode 7, I think it should probably use Calc84maniac Mode 7 engine, assuming he's willing to give the source for it. Were you planning to have 3D stuff as axioms, btw?

EDIT: MWAHAHAHAHAHA! 55555th post on the forums :P
Title: Re: Features Wishlist
Post by: Quigibo on August 16, 2010, 01:39:42 am
Not sure yet.  Most likely 'yes' as a way to promote my updated Axiom engine (which isn't near finished yet).  Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.  Luckily I found a simpler source for a different mode 7 engine and after some major optimizations, you don't notice much speed difference between this and the F-zero engine.  I found enough optimization to offset the SMC removal with even more extra speed and the Axe routines seem to suffice for the multiplication with very little speed loss.  This will of course be a "15MHz recommended" command because I can't see it playable at a decent framerate without it.

@Builderboy its possible... I'll see what I can do.
Title: Re: Features Wishlist
Post by: calc84maniac on August 16, 2010, 07:52:34 am
I think some good features to add would be the "break" and "continue" control statements (for those who don't know, "break" will exit a For, While, Repeat loop immediately and "continue" will go immediately to the next iteration of a loop)
Title: Re: Features Wishlist
Post by: calcdude84se on August 16, 2010, 08:54:38 am
Break and continue can both be done with Goto's, though official support that allows us not to use Lbl's would be nice.
Basically, seconded :)
Title: Re: Features Wishlist
Post by: ztrumpet on August 16, 2010, 09:56:59 am
Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.
I thought F-Zero was an App...  So it isn't, or is there a way to make SMC work with an App?

I agree with the break and continue statements as well. :)
Title: Re: Features Wishlist
Post by: calcdude84se on August 16, 2010, 10:20:50 am
If it is an app (I don't know), he probably copied code to RAM and executed it from there.
Title: Re: Features Wishlist
Post by: TIfanx1999 on August 16, 2010, 05:55:56 pm
Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.
I thought F-Zero was an App...  So it isn't, or is there a way to make SMC work with an App?

I agree with the break and continue statements as well. :)
It is an app, and it does. There was some discussion about this on IRC. Apparently F-Zero itself wouldn't be adaptable simply because of how it was written.
Title: Re: Features Wishlist
Post by: Quigibo on August 17, 2010, 01:40:35 am
Well the demo that I downloaded was a program.  Its still available to download on his website I think.

I've been really busy this week so far and I'm leaving for school soon so I'll try to get a new version up soon, but not much new stuff will be added.  The one thing I have had time for though is a complete example game which I'm about halfway though, it will be the final example program and downloadable individually as well.  It's based on another game from Warioware that no one's heard of and its coming along very nicely.

Initially, I though I would have the final release nearly complete around this time, but I've decided instead to continue working on this a little more instead of compromising features.  Updates will be more sparse though since college is starting again but I plan to finish around the time of the contest deadline or shortly after.  There will still be updates after that, but I want a very stable, safe, and bug-free version out by then which will be 1.0.0
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 07:38:25 am
How about linking support for sending 2-byte numbers.
Title: Re: Features Wishlist
Post by: Builderboy on August 17, 2010, 03:52:48 pm
That could be easily written in Axe itself i would think, just send the 2 bytes of the 2 byte number.  However, it would be nice to automate the process :)
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 07:44:55 pm
Oh, so if I did

Send({L1},1000)
Send({L1+1},1000)

that would send the 2 byte number?

Would Send({L1}^r,1000) work?
Title: Re: Features Wishlist
Post by: SirCmpwn on August 17, 2010, 07:48:06 pm
The second one, I don't think would work.  Actually, I don't think the first one would, either.  I haven't played with this yet, but you can only muck around with the two available bits, if I remember correctly.
Title: Re: Features Wishlist
Post by: calcdude84se on August 17, 2010, 08:06:34 pm
Send( is a linking routine to send one byte :)
The first one is fine, and the second calc will have to do something like Get*256+Get to get the result, though the Send('s will need to be in the reverse order (high byte first)
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 08:18:53 pm
ok. No, what happens if I run send on sender but don't do Get on reciever. Will reciever still recieve data?

Note to Quigbo: Can we try for a command to send 2 byte data?

Also can someone give me the HEX for an asm subroutine that emulates Basic's Input command? And tell me where it saves the input so that I can access it using Axe coding?
Title: Re: Features Wishlist
Post by: nemo on August 18, 2010, 12:55:11 am
Cagliano, what sort of input are you looking for? there's a topic under the axe parser subforum i made that has some code that accepts numbers 0-65535, unless you need string and list support.

also, i'm still begging for a pxl-swap() command. i know it can be implemented easily, but i think some pretty neat effects could be achieved with it.
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 01:58:57 am
I forgot to address the break and continue idea.  Those are both definitely possible, it could even be used in If and Switch statements which would be cool.  Finding a token in a convenient menu might be a challenge though.

Sending multiple bytes is simple, I tested a program that sent the entire graph buffer from one calculator to the other and it took less than half a second.  In fact, it is easier and more reliable to send a section of ram than to send individual values so I would recommend that you store all your sending values in consecutive ram addresses to make it easier.

Pixel swap might be nice, but I don't have a good token for that.  Maybe I can put it in the same place as Pt-Mask.
Title: Re: Features Wishlist
Post by: Runer112 on August 18, 2010, 04:15:13 am
Goto r and Endr?
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 04:41:32 am
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
Title: Re: Features Wishlist
Post by: Runer112 on August 18, 2010, 05:12:27 am
The main reason I'm suggesting that is because, although custom Axe tokens are nice, it's always a pain in the ass to try to write Axe programs on a computer. Some tokens are completely unrelated to what they do. Like the Port command, I can't even remember it now despite having used it multiple times. I always have to look it up every time I want to use it.
Title: Re: Features Wishlist
Post by: ACagliano on August 18, 2010, 12:00:03 pm
Cagliano, what sort of input are you looking for? there's a topic under the axe parser subforum i made that has some code that accepts numbers 0-65535, unless you need string and list support.

I'm looking for string input actually. I want a user input string which i can then use in Axe's GetCalc( command.
Title: Re: Features Wishlist
Post by: ztrumpet on August 18, 2010, 01:13:52 pm
By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
I think this is a great idea.  I'll green light it. :)

Can we have Break, Continue, and, since you brought it up, can we please have Switch?  I'd love making Switch structures in Axe!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 18, 2010, 02:21:09 pm
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
That would be fine as long as those changes aren't too drastic. Example: no massive command changes making it even harder to search for commands in the CATALOG (like Rect() and RectI())
Title: Re: Features Wishlist
Post by: calc84maniac on August 18, 2010, 02:24:12 pm
I forgot to address the break and continue idea.  Those are both definitely possible, it could even be used in If and Switch statements which would be cool.  Finding a token in a convenient menu might be a challenge though.
I would say don't make Break exit just the If statement, but instead make it exit the loop outside. Otherwise you couldn't conditionally Break :P

Break should probably be required after each case of a switch statement of course, unless you want to the code to keep running into the next case (which might be useful actually).

Basically just do it like C, lol :P
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 02:40:14 pm
Well I was thinking of instead of having just "Break" and "Continue", I also have "BreakIf" and "ContinueIf" as well as their conjugates since then they can be used in conditionals because I think that feature would be nice and this way the assembly is more optimized anyway than having a separate conditional.  Also, I'm not even sure how I could make it break out of multiple levels of nested statements anyway with the way I currently handle nested blocks.

My switch command is going to be really different as well.  I need it to be optimized enough where it is much more favorable to use so I think there will be no switch statement, only case statements.  For instance:

Code: [Select]
:
:A*12+(B/8)         .The last expression used becomes the switch statement automatically
:Case 0
:  .Function1
:Case 83
:  .Function2
:Case -1
:  .Function3
:End
:

The look-ahead parsing to pregenerate a jump table would be messy and memory hungry so I'd have to see how feasible it is.  So that means I am still unsure if automatic breaks would need to be implemented or not.  I'm also unsure if I want to make this command a single byte only command since it could lead to a huge optimization
Title: Re: Features Wishlist
Post by: ztrumpet on August 18, 2010, 03:23:38 pm
I think doing switch, continue, and break like that are all good ideas.  My only request is to allow a "Default" case in the switch structure as well. :)
Title: Re: Features Wishlist
Post by: LordConiupiter on August 18, 2010, 03:37:34 pm
The "Default" could be written like "Case ?" or perhaps "Else"?
Title: Re: Features Wishlist
Post by: ACagliano on August 20, 2010, 07:25:18 am
See the TI-Basic code below:

Code: [Select]
"HELLO"->Str1
Str1+" WORLD"->Str1

Can this be done in Axe? How?


And, as for the Bitmap( command, it says the structure pointed to should be width x height x rows of img. What does this mean exactly? Let's say I wanted a blank sprite that is 7x7 pixels. How should my arguments for Bitmap look (The X and Y can be an arbitrary X and Y)?
Title: Re: Features Wishlist
Post by: calc84maniac on August 20, 2010, 08:25:50 am
See the TI-Basic code below:

Code: [Select]
"HELLO"->Str1
Str1+" WORLD"->Str1

Can this be done in Axe? How?


And, as for the Bitmap( command, it says the structure pointed to should be width x height x rows of img. What does this mean exactly? Let's say I wanted a blank sprite that is 7x7 pixels. How should my arguments for Bitmap look (The X and Y can be an arbitrary X and Y)?
Here's a way to do what you said, I think. Note that extra data bytes are inserted after Str1 is defined. This is important! Otherwise the new data at Str1 would overflow into other data.

Code: [Select]
.Data initialization
"HELLO"->Str1
Zeros(6)
" WORLD"->Str2

.Code to append Str2 to Str1
.Copies length(Str2)+1 bytes to include null terminator
Copy(Str2,length(Str1)+Str1,length(Str2)+1)

Edit:
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 09:42:32 am
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
O.o

I'd like them too, but only if they are used wisely.  I'll like the extra RAM. :)
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 12:03:26 pm
Here's a way to do what you said, I think. Note that extra data bytes are inserted after Str1 is defined. This is important! Otherwise the new data at Str1 would overflow into other data.

Code: [Select]
.Data initialization
"HELLO"->Str1
Zeros(6)
" WORLD"->Str2

.Code to append Str2 to Str1
.Copies length(Str2)+1 bytes to include null terminator
Copy(Str2,length(Str1)+Str1,length(Str2)+1)

So, that takes Str1 and adds it to Str2? Writing it into my calculator with a Disp Str2 doesn't return "Hello World"
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 12:07:22 pm
So, that takes Str1 and adds it to Str2? Writing it into my calculator with a Disp Str2 doesn't return "Hello World"
You need to do Disp Str1. :)

Before that the memory looks like this:
"HELLO",0,0,0,0,0,0,0," WORLD",0
After that, the memory looks like this:
"HELLO WORLD",0," WORLD",0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 20, 2010, 12:15:50 pm
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
To insert stuff at a memory address and offsetting some of the stuff below, right?
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 12:50:04 pm
You need to do Disp Str1. :)

Before that the memory looks like this:
"HELLO",0,0,0,0,0,0,0," WORLD",0
After that, the memory looks like this:
"HELLO WORLD",0," WORLD",0

I suspect something might be wrong with my calculator, then. The code I put in was

Code: [Select]
.AB
"Hello"->Str1
Zeros(6)
" World"->Str2
Copy(str2,length(Str1)+Str1,length(Str2)+1)
Disp Str1
While getkey=/=9
End

What I get back out is a blank line where Str1 should be displayed.
Title: Re: Features Wishlist
Post by: Quigibo on August 20, 2010, 01:35:59 pm
That code should work.  Are you sure you recompiled it after making changes to the source?

The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.

By the way, I happened to stumble upon an undocumented bcall on brandonw's website that is nearly identical to BASIC's "Input" function, and so I've added that functionality now.  The way it works is that it stores the input to a temporary string in ram and returns the pointer to it just like you would read any other external string.  The only difficulty is that similar to strings, its token based instead of character based so anything that's not a number or uppercase letter has to be converted.
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 01:43:28 pm
Yep, it was recompiled. Looks like I'll have to just hope other calculators can understand if I ever use that in a program.
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 01:58:18 pm
The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.
Yes but working at a fixed address would be faster, and I'm all for more speed. ;D
Title: Re: Features Wishlist
Post by: Runer112 on August 20, 2010, 02:40:28 pm
I'd really like InsertMem and DelMem. I'm currently working on a project that stores data in an appvar that can get very large and change size, and there may not be enough RAM to make a whole other appvar of the new size to coy the data into.
Title: Re: Features Wishlist
Post by: Builderboy on August 20, 2010, 05:18:13 pm
Break and Switch are great ideas in my mind.  I also was visualizing some sort of breakpoint command?  Where you could pause execution, view the variables, and do other sorts of things.  Its highly conceptual right now though, what do you guys think?
Title: Re: Features Wishlist
Post by: Deep Toaster on August 20, 2010, 05:36:10 pm
Switch would be a great addition, but don't know about break. We could always just Goto our way out of the loop.
Title: Re: Features Wishlist
Post by: calcdude84se on August 21, 2010, 11:29:00 am
That, however, requires extra labels, and remember, Goto is bad :P
Edit: It's less that Goto is bad than we have to come up with extra label names for somewhere we shouldn't need to :)
Title: Re: Features Wishlist
Post by: LordConiupiter on August 21, 2010, 02:11:53 pm
Could you perhaps impelement "Goto End" as Break? on this code it would jump to the next End that is read. Is that a good idea?
Title: Re: Features Wishlist
Post by: calcdude84se on August 21, 2010, 03:43:14 pm
That sounds like it could work. Though it wouldn't necessarily be the next End, since If's don't count, not being looping constructs.
Also, it would be nice to be able to specify how far out to go, possibly like "Goto End(3)" to break out of three loops. (This is constant, of course. "Goto End(X)" won't compile, just like "getKey(X)" won't.)
What token would work after Goto for a continue, though, since there's more than one looping construct?
Title: Re: Features Wishlist
Post by: calc84maniac on August 21, 2010, 05:02:59 pm
The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.
But this doesn't allow me to, for example, create a program and write a variable amount of data into it. I would have to create a whole new program every time, copy over the old data, and delete the original. I'd rather just like to be able to insert or delete memory as I need to.
Title: Re: Features Wishlist
Post by: LordConiupiter on August 23, 2010, 09:15:55 am
That sounds like it could work. Though it wouldn't necessarily be the next End, since If's don't count, not being looping constructs.
Also, it would be nice to be able to specify how far out to go, possibly like "Goto End(3)" to break out of three loops. (This is constant, of course. "Goto End(X)" won't compile, just like "getKey(X)" won't.)
What token would work after Goto for a continue, though, since there's more than one looping construct?
Can't "Goto End(EXP)" also be used for If's? that would perhaps be more convenient for the compiler, but of course I don't know how the compiler exactly is handling End commands...

perhaps the token "Connected" could be used for continue? and otherwise "IS>("? that would be handy because of it's location (prgm -> A)
Title: Re: Features Wishlist
Post by: calcdude84se on August 23, 2010, 09:48:04 am
An indexed Connected would be nice, and the name could be changed. As for "Goto End" taking If's into account, I guess that would be okay if it makes things easier for the compiler. I don't know how it works internally either ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on August 25, 2010, 02:01:12 pm
An indexed Connected would be nice, and the name could be changed. As for "Goto End" taking If's into account, I guess that would be okay if it makes things easier for the compiler. I don't know how it works internally either ;D

But then there's the problem of nested loops having the same expression. Stuff like
Code: (Axe BASIC) [Select]
...
:While U>4
:U-1→U
:While U>4
...

Obviously, this probably isn't the best example :P but there are times when someone'd need two loops with the same condition. It'd be a lot easier to just put an extra label at the end and Goto it when we need to for a break, or do it at the beginning of the loop for a continue. Labels don't add to the executable size, anyway, and I don't think there are any problems with Goto'ing out of a loop...
Title: Re: Features Wishlist
Post by: calcdude84se on August 25, 2010, 09:58:52 pm
I'm not sure how that would prevent it :)
As for just using Goto, yes, it's the same size, but it's more convenient to have break and continue :)
Title: Re: Features Wishlist
Post by: andrepd on August 26, 2010, 12:12:51 pm
Tilemapping is a must. Even though with good optimization it is possible in axe, programming it natively in Asm and implementing a command for it is, of course, easier and *much* faster...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 26, 2010, 12:49:54 pm
I think it depends, though. I recall some functions weren't much faster and smaller when done automatically rather than manually, simply because they were the exact same thing. However, writing a tilemapper can be hard, especially with half-byte compression, some people struggle at it and I feel that since Axe is game-oriented, it would be a very nice feature to add to 1.0.0 or 1.0.1
Title: Re: Features Wishlist
Post by: kindermoumoute on September 04, 2010, 06:39:24 pm
I wonder if we could manipulate variables Pic of the calculator, because it did not seem to have been added (from the documentation).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 06:43:47 pm
I am curious if this could be added as well. Right now it's possible to just use DispGraph then run a BASIC program to store to a pic var, but that won't let us store to hacked pics... not to mention it would be nice to do in pure Axe, too.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 07:20:45 pm
Yeah, storing hacked pics would be amazingly useful, especially if we could get them to store the 64th row. That would make Pokemon TI's tile data a heck of a lot smaller.
Title: Re: Features Wishlist
Post by: Quigibo on September 04, 2010, 09:44:25 pm
I'm not quite sure what you mean, you've been able to read/write/create/delete/modify pictures of any size for a long time now...

If you want to create a picture Pic1 that is 64 rows long, you can do this:
Code: [Select]
If GetCalc("Pic1",768)->A
  .Modify the picture here
End

You can even make the pictures ridiculous sizes and it should still work.
Title: Re: Features Wishlist
Post by: nemo on September 04, 2010, 09:46:22 pm
quigibo, we can even access others besides pic0 - pic9? also, can we make pictures that are 3072 bytes, or four screens large?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 09:47:08 pm
I think what he wants is to store actual 8xi files using Axe Parser. In BASIC you would do Storepic 0 through 9. He wants to be able to do the same in Axe. He didn't meant Pic1 as an Axe pointer, but rather the actual TI-BASIC files.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 09:53:46 pm
By hacked pictures I meant pictures number 11-255. They show up with random tokens as their names in the memory menu.
For example, Pic11 would be GDB1. You can use hacked pics with xLib and Celtic III, but currently they can only be stored without the 64th row. If Axe supported the ability to write to (or read) hacked pics, you can then use the full pic to store tiles and sprites, which would be extremely useful.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 09:54:47 pm
An example of game using them is Reuben Quest The Lost Mirror and Zelda Dark Link Quest. Only difference is that both games use Zpic to call them, as xLIB APP didn't exist back when they were made.
Title: Re: Features Wishlist
Post by: Quigibo on September 04, 2010, 10:08:46 pm
@FinaleTI
Oh I see.  Yes, you can read and write to hacked Pictures as well, but you have to use the hex codes since you can't type it in.

Code: [Select]
GetCalc([0760]Data(#,0))->A

To return a pointer to the hacked pic # (in decimal)

@DJ
I'm not talking about a static pointer either, that's the actual OS picture.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 10:22:26 pm
OK. Thanks.
This should be a big help with saving space with the tiles for Pokemon TI. ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 10:23:40 pm
Oh ok, sorry if I was confused. I haven't used Axe in a while x.x
Title: Re: Features Wishlist
Post by: Builderboy on September 04, 2010, 10:42:11 pm
Hey thats good to hear that Axe can support arbitrary sized hacked pictures :)
Title: Re: Features Wishlist
Post by: Deep Toaster on September 04, 2010, 11:16:51 pm
Hacked pictures! Are they allowed for the contest, seeing as we need to type pure hex?
Title: Re: Features Wishlist
Post by: Jonius7 on September 04, 2010, 11:24:26 pm
hacked pictures, that doesn't sound right for the contest, doesn't that bypass the hard work of typing code?
(now i have 20 posts! yay!!! now i can chat at the top of the page!)
Title: Re: Features Wishlist
Post by: calc84maniac on September 04, 2010, 11:25:16 pm
Hacked pictures! Are they allowed for the contest, seeing as we need to type pure hex?
Should be allowed, because the hex is not asm code.
Title: Re: Features Wishlist
Post by: nemo on September 04, 2010, 11:28:00 pm
Pitures just contain data... It wouldn't matter if it was allowed in the contest since they're just an alternative to using data() or [hex]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 11:38:48 pm
Yeah they are allowed, just as long as you aren't using any form of data to execute ASM code
Title: Re: Features Wishlist
Post by: nemo on September 06, 2010, 01:58:30 am
would it be unreasonable for an operator to get the half-byte of a location? maybe {PTR}#^r where # is 1-4, which half-byte you're trying to access?
Title: Re: Features Wishlist
Post by: calcdude84se on September 06, 2010, 02:45:48 pm
That could be made more generic :)
Perhaps something like EXPR!#, where EXPR is any expression, ! is the factorial symbol, and # is a constant or variable between 0 and 3 indicating what nibble.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 06, 2010, 02:54:13 pm
or perhaps EXPR[ # ], like arrays? EXPR would be the pointer to the data, and # could be any number/variable with any value. and when that's unrealizable, just constant 0 - 3.

a feature request: when I currently want to draw an Inverted Rectangle, I have to do:
Code: [Select]
Rect(X,Y,W,H
RectI(X,Y,W,H
could you change invT( in the 2nd DISTR menu to Inv, so that we can type InvRect(X,Y,W,H)? or would this be too much work?

another thing I suddenly thought of: could DelVar perhaps be changed to DelCalc(, since it is a member of the Calc var handling system? IMO it would be nice to have GetCalc( and DelCalc( look similar, because of the same Syntax and use.

and the PTR in the documentation used in the External Variables part for GetCalc(PTR) is not the same PTR as for float{PTR}, or am I wrong at this point? Else it would perhaps be more consistent to use EXPR in stead of PTR.

one last note: in the documentation it says: Sub(, but in the editor it is sub( with a lower case S.
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 12:39:56 am
It would be nice to be able to initialize a program whether Axe or BASIC without having the compiler put the code for the secondary program into the compiled code. For example, this would allow end users to install only the levels for a game that they have the memory to run. It would also open up the possibility of creating a base program to which one can add modules for different functions.

It's clearly possible in Assembly since BASIC is simply interpreted Assembly, but I don't know if it could be implemented efficiently in Axe.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 07, 2010, 01:41:16 am
ninja'd? or double post? ;) was the site acting weird, or is this message that important to you, so you posted it twice?
Title: Re: Features Wishlist
Post by: Builderboy on September 07, 2010, 01:45:24 am
That is an interesting double post o.O not sure what the site policies are about that XD
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 04:09:52 am
I think he might have hit Post twice. I think the site is a bit slower when sending posts, tho, nowadays, so people may click again when nothing happens.

Fixed
Title: Re: Features Wishlist
Post by: Ikkerens on September 07, 2010, 10:40:26 am
It would be nice to be able to initialize a program whether Axe or BASIC without having the compiler put the code for the secondary program into the compiled code. For example, this would allow end users to install only the levels for a game that they have the memory to run. It would also open up the possibility of creating a base program to which one can add modules for different functions.

It's clearly possible in Assembly since BASIC is simply interpreted Assembly, but I don't know if it could be implemented efficiently in Axe.

Seconded, running out of space on my app.
Title: Re: Features Wishlist
Post by: Raylin on September 07, 2010, 12:04:10 pm
Quintuple post?! o.o
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 12:16:05 pm
Fixed. Qwerty.55, when the forum doesn't respond when you reply, do not click submit again. Copy your post in your clipboard or in another application, then after 30 seconds, hit refresh in your browser. If your post won't show up on the last topic page, then paste your post and try submitting again.
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 03:08:19 pm
I'd try that advice if I hadn't already tried it. The last multiple post was the result of one submission. I pressed the button and didn't touch my phone until it had sent it. I mean that literally. I set the phone down on my desk and watched it. I think I'll just stick with a computer from now on.

PS: I tried to delete all of the extra posts I had made. Apparently I missed a few.

Sorry.


Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:09:45 pm
Weird, might be a bug or something with the phone app x.x

Don,t worry though, as some of us deleted the extra posts
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 03:23:37 pm
Wouldn't surprise me. My luck with software as of late has been less than desirable to say the least.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:24:28 pm
That happens x.x

In my case it's when I code site-related stuff or update. Usually it turns out to be a major failure x.x
Title: Re: Features Wishlist
Post by: Ikkerens on September 07, 2010, 03:37:27 pm
That happens x.x

In my case it's when I code site-related stuff or update. Usually it turns out to be a major failure x.x

Lol, thought you were quite capable of doing things (looking at what you've achieved already)
If you ever need help with PHP/HTML/CSS/JS, just say the word
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:45:14 pm
Oh I know how to code BASIC and some Axe, but site design is not my cup of tea. I don't like it much. I sometimes have an urge to do some artwork, hence the new forum theme, but it took me over 2 weeks to design the style sheet x.x

That reminds me, would triple buffering, at the cost of the 27 real variables, be easy to implement? (It would use L1, L3 and L6) Useful for 8 level grayscale
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 07:00:55 pm
That could be made more generic :)
Perhaps something like EXPR!#, where EXPR is any expression, ! is the factorial symbol, and # is a constant or variable between 0 and 3 indicating what nibble.

You could always use ^ and / ;)

But it might be a good idea to make things clearer. Maybe [PTR].[NUM], since periods aren't really used right now? It would make sense, anyway, since it kinda means a part of the number.
Title: Re: Features Wishlist
Post by: Builderboy on September 07, 2010, 07:13:25 pm
I think it would be useful only if it was the variable part?  Since if it was constant, using / or ^ would be a bit easier.  Using it as a variable could be useful for half byte tilemapping
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 07:26:59 pm
And even if it were a variable, / and ^ are pretty easy to use. For the high nibble, it's [EXP]^16, and for the low one, it's [EXP]/16. I think the original idea, though, was to make one that would be easier for two-byte numbers, since to get the low nibble of the high byte of A, it would be A^256/16 now. The only reason I can see of adding such a command would be to make things easier to figure out :P
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 08:19:33 pm
I think it would be useful only if it was the variable part?  Since if it was constant, using / or ^ would be a bit easier.  Using it as a variable could be useful for half byte tilemapping
Exactly. You can't really have something that returns the upper nibble if X is 0 and the lower if X is 1 inline in an expression, can you? ;D
Title: Re: Features Wishlist
Post by: Quigibo on September 07, 2010, 08:48:29 pm
What about an alternative half byte referencing command?  I imagine that's what it would generally be used for anyway, so just take out the middle man.

Say I call this command nib{} which uses angle brackets like int{} since it's a referencing command.

[C0FFEE123456]->Str1
nib{Str1*2}   .returns C (12 in decimal)
nib{Str1*2+1} .returns 0
nib{Str1*2+2} .returns F (15 in decimal)
nib{Str1*2+N} .returns the Nth nibble in memory


The only strange thing you might notice about this is that the pointer has to be multiplied by 2.  That's because wherever it points to is in bytes so if the pointer is at the 100th byte, it is actually at the 200th nibble.  That's done during compile time in this case so its not going to increase program size or anything.  But now there are 131,072 (2^17) possible addresses, and so that means you can only use this command for half of the memory.  Ram is in $8000-$FFFF which is exactly the range needed.  However that would suck for apps because they need the other half from $0000-$7FFF.  To remedy this, there would be 2 commands, one for programs/ram/archive and one for apps.  So nib{} and nib{}r would work.

Would this be suitable?

EDIT: Oh, there could also be a store-to version for ram, like 5->nib{Str1*2+2} for instance.
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 09:14:00 pm
That sounds like it'd work nicely :)
I say go do it! :D
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 10:08:49 pm
Yep, that'd be great. What token will this replace?
Title: Re: Features Wishlist
Post by: Runer112 on September 07, 2010, 10:10:23 pm
Any chance of grayscale routines that play nicely with interrupts? I don't really mind if they're slower. Slower but more regular is better as far as I'm concerned.

Edit: Perhaps this could be implemented with a toggle in the Axe options menu? There must be grayscale routines out there that don't kill interrupts, right? Maybe just grab one that looks decent, tweak it a little bit for Axe, and (hopefully) not have to work too much on it.
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 10:10:44 pm
What about iPart(? It's in the math menu near float{ and whatnot.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 10:15:28 pm
A nibble command would be nice. It would make it much easier to deal with half-byte tilemappers, especially those who have an harder time being experienced with Axe.
Title: Re: Features Wishlist
Post by: Quigibo on September 08, 2010, 12:34:33 am
@Runner, yes, I fixed that now.  I decided to keep the grayscale routine unchanged since that is most critical and just change the interrupt routine to push and pop the af register pair instead of saving it to a shadow register.  Its exactly the same size as before now and unnoticeably slower.

Just an fyi to all you asm programmers, I was able to save one byte from each call to Copy(), Fill() and Exch() using an optimization I hadn't considered before.
Code: [Select]
this:
  ld   b,h
  ld   c,l
  pop  hl

can become:
  ex   (sp),hl
  pop  bc

Its slightly slower, but its one byte less.

Oh, and I finally took care of another request: dereferencing.  The routine actually already existed so I only had to add about 6 lines of code.  The new syntax for that is the degree sign followed by the variable and it will return the variable's address.  For those familiar with C, its identical to the &.

A        Returns the variable A
{A}r     Returns what A points to
oA       Returns the address of A
{oA}r    Identical to the first example

So I don't want to see anymore of that {L1-52} nonsense and no one has any excuse for being mad if I change where the variables are in the future.  This works with all variable types including files and the subroutine variables.  Also, don't forget that any dereferenced variable is a constant address just like the L1-L6 addresses so any math you do to it is done during compile time for extra optimization.
Title: Re: Features Wishlist
Post by: calcdude84se on September 08, 2010, 12:39:50 am
Nice to see address-of! Very handy, I've been wanting that for a while.
The size optimizations are nice too.
Keep up the good work! :D
Title: Re: Features Wishlist
Post by: Builderboy on September 08, 2010, 12:58:55 am
I am perfectly happy with the dereferencing :) as long as they stay in the same order ;D and awesome on the optimization!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 08, 2010, 01:03:41 am
It should be fine with me too. I only use those variables the regular way personally (1->A for example).

Also I like the address command and optimizings. Nice job as always Quigibo.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 08, 2010, 08:00:15 pm
Addresses! That'll be useful. No more subtracting from L1 :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 08, 2010, 08:58:20 pm
ANother trick would have been to simply store directly to the memory address the variables are located to, but then the issue is if this location changes from an OS to another, you risk messing up people calc if they use a different OS.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 03:28:27 am
iPart( would be a nice token for nib{ I think. could you also add a bit{ command? min( could be replaced by it. the following syntax could be used:
Code: [Select]
.bit{byteaddress, bitnumber}:

[0B->GDB1            .00001011
If bit{GDB1,1}=1    .true
Disp "last bit on!"
End
If bit{GDB1,8}       .false
Disp "First bit on"
End
Title: Re: Features Wishlist
Post by: Raylin on September 09, 2010, 04:00:41 am
Can't you do that with the Euler's constant 'e'?
Title: Re: Features Wishlist
Post by: ACagliano on September 09, 2010, 08:01:10 am
How about support for DCS icons in Axe executables?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 11:04:52 am
Can't you do that with the Euler's constant 'e'?
ow yes, youre right! thanks!

could a command be added for changing the screen intensity? perhaps lcm( could be renamed to lcd(EXPR) with expr a value from 0 to 24 or something?
Title: Re: Features Wishlist
Post by: Raylin on September 09, 2010, 11:12:32 am
That can be done with Shade(EXP).
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 11:47:09 am
ow! how stupid am I today! perhaps I'm working too much for the contest, and sleeping too little :(

could you also add port reading in the future? I do not mean the I/O port etc, but ports like these: All ports by Address (http://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address)

EDIT:
another feature for the next Axe version after 1.0.0:
the Function command, for labels to be used as commands like subs. I'll explain what I mean with an example:
normally, when you want to use a subroutine, you do:
Code: (Axe) [Select]
sub(SUB,1,2,"HELLOL"
Return

Lbl SUB
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
but the idea of Function is that this could be done:
Code: (Axe++) [Select]
Text(1,2,"HELLOL")r
Return

Function Text(3)r
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
this is some kind of Axiom thing, but than in Axe itself, right?
could this be added in Axe++?
Title: Re: Features Wishlist
Post by: Builderboy on September 11, 2010, 06:51:43 pm
LordConiupiter, what would the advantage of using the Text() token be over using the regular sub() syntax?


Also, i just wanted to ask what the feasibility would be for Apps that have a second page for data?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 11, 2010, 07:02:39 pm
well, it is not just only for the Text token, it could be used for any token. it is just an example, which draws text to the buffer, using the r modifier. perhaps this was not the best example I could give, but it was meant to give the ability to write Axioms in Axe.
Title: Re: Features Wishlist
Post by: Quigibo on September 11, 2010, 07:29:25 pm
Probability of having a 2nd page of data is about 80% right now.  It's more difficult to find some allocated space for 2 pages and I also have several ideas of how I could implement it that I need to decide on.  Its also on the dangerous side, so I need to make sure I do a lot of debugging before I actually release it.  I think with all the things I still want to add, there might actually be more versions before 1.0 or several versions after 1.0 for followup.
Title: Re: Features Wishlist
Post by: Happybobjr on September 11, 2010, 07:31:38 pm
 me want nOOOw.... :P
:):D
Title: Re: Features Wishlist
Post by: calc84maniac on September 11, 2010, 07:33:15 pm
Probability of having a 2nd page of data is about 80% right now.  It's more difficult to find some allocated space for 2 pages and I also have several ideas of how I could implement it that I need to decide on.  Its also on the dangerous side, so I need to make sure I do a lot of debugging before I actually release it.  I think with all the things I still want to add, there might actually be more versions before 1.0 or several versions after 1.0 for followup.
For extra pages of data, you can just save directly to the flash. The data won't ever change after its definition. This way we can have apps as big as we want.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 11, 2010, 11:22:11 pm
I agree it will need a lot of debugging, in case it messes up people flash rom x.x. I assume it will be another closed beta testing run?

It would be awesome to have 2 flash pages, tho, because some people use APPs to get around the 8 KB code limit, but then have to split most of their data in appvars due to the 16 KB limit including data too x.x

Good luck Quigibo!
Title: Re: Features Wishlist
Post by: Builderboy on September 12, 2010, 02:32:14 pm
2 Page Apps sound awesome :D I cant wait for them to be implemented!! ^^ and if what calc84 says is true (and i think i have reason to believe so :P) then could this be a soon to come feature? 
Title: Re: Features Wishlist
Post by: kindermoumoute on September 13, 2010, 03:23:32 pm
I think it would be useful to more programs for example, because there was not much for last update and I found it very useful (at least there is no need to spend lot of time on the translator while someone (or record of commands) explains the function in English).

What do you think?

PS: and then I would have read all the forum omnimaga to know where to find the best such programs, but my English makes me go on google translation ^^.
Title: Re: Features Wishlist
Post by: ztrumpet on September 13, 2010, 04:00:49 pm
I can't wait for Multi-Page Apps (even if all pages != 0 are data).  RPGs can exist in Axe! ;D
Title: Re: Features Wishlist
Post by: LordConiupiter on September 13, 2010, 04:10:51 pm
well, I already have all my data stored to appvars, but now I'm running out of space :(
so I would realy like to see multipage apps with more than one page of code :)

another question I suddenly thought of: How is it going with WAVE support?
Title: Re: Features Wishlist
Post by: Quigibo on September 13, 2010, 04:32:20 pm
I will definitely have a new example program in the next version.  And it will be an entire game, not just a demo like the other ones.

Oh yeah, that WAVE support... I did try, but the quality was unacceptably low in 6MHz with any kind of compression.  It was something I wanted to add at one time, but after playing around with it, it doesn't seem practical.  Someone can always write an Axiom for it eventually but I don't think it will be supported natively.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 13, 2010, 04:59:58 pm
An axiom for it (15 MHz mode) would be cool. Not a big hurry, though. Can't wait to see what you have in store :)

Starcraft Axe Remake, by Quigibo
Title: Re: Features Wishlist
Post by: Builderboy on September 13, 2010, 05:16:01 pm
so I would realy like to see multipage apps with more than one page of code :)

I believe as some asmers have mentioned in the past that this is extremely difficult to pull off, and even seasoned asm experts can have trouble getting it to work.  Having an automated option might be out of the question, but you'd have to ask Quigibo
Title: Re: Features Wishlist
Post by: Raylin on September 16, 2010, 11:29:00 pm
I would like to see masked bitmaps in the next version of Axe. With greyscale support if possible.
Title: Re: Features Wishlist
Post by: Builderboy on September 17, 2010, 02:04:11 am
Bitmaps are an Os command so im not sure of the possibility of that option D:
Title: Re: Features Wishlist
Post by: calc84maniac on September 17, 2010, 03:08:54 am
I'd like the option of turning the homescreen cursor on/off. It would greatly help with making custom text input that doesn't use the "input" command (which ends up creating a temporary string each time it is run, and also uses tokens).
Title: Re: Features Wishlist
Post by: Builderboy on September 17, 2010, 03:19:32 am
well couldn't you just display the character 224?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 17, 2010, 03:22:17 am
well, the cursor is just a token, which you can use with the Output command. I thought it was 224>Char for the normal, 225 for the sencond cursor (with the up arrow), 226 for the alpha cursor (with the small A),  227 for the alpha cursor (with the small a), 228 for the insert cursor ( _ ), etc.

you could use this image to output aany char you want:
Spoiler For Spoiler:
(http://zastava.student.utwente.nl/linkguide/ti83/graphics/chars6x8.gif)

EDIT: ninja'd :P
Title: Re: Features Wishlist
Post by: calc84maniac on September 17, 2010, 08:56:12 am
But still, turning the real homescreen cursor on is only a 3-byte OS command, and the OS handles all of the cursor blinking itself in the interrupts. It's much more convenient :)
Title: Re: Features Wishlist
Post by: Deep Toaster on September 17, 2010, 07:18:15 pm
Maybe it could be a Fix function, if that's not filled already.
Title: Re: Features Wishlist
Post by: Quigibo on September 17, 2010, 08:32:46 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 17, 2010, 09:22:25 pm
Also is 3D still planned for Axe? If not, it might be a good idea to remove the poll maybe :P
Title: Re: Features Wishlist
Post by: ztrumpet on September 17, 2010, 09:44:06 pm
It may be helpful to look into some of ThePenguin's code that deals with this.  It's in most of his games. :)
Title: Re: Features Wishlist
Post by: Quigibo on September 17, 2010, 09:46:44 pm
3D is planned as an Axiom, not as part of the language itself.  I want to remove the poll, but it doesn't let me unless I start a new poll, which I don't really have any ideas for.  I guess I'll start a new one then.
Title: Re: Features Wishlist
Post by: nemo on September 17, 2010, 09:53:16 pm
Quigibo, could you post the source code to the mode7 engine in axe you made awhile back?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 17, 2010, 10:04:45 pm
3D is planned as an Axiom, not as part of the language itself.  I want to remove the poll, but it doesn't let me unless I start a new poll, which I don't really have any ideas for.  I guess I'll start a new one then.
Oh ok. I might have messed up the board settings x.x

I guess I'll wait then.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 17, 2010, 11:40:18 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.

Isn't it a b_call?
Title: Re: Features Wishlist
Post by: calc84maniac on September 19, 2010, 08:43:13 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.

Isn't it a b_call?

bcall(_CursorOn)
bcall(_CursorOff)
Title: Re: Features Wishlist
Post by: aeTIos on September 21, 2010, 03:03:19 pm
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?
Title: Re: Features Wishlist
Post by: SirCmpwn on September 21, 2010, 04:48:30 pm
Also, bumping my request for Alpha+Letter in the compile menu.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 21, 2010, 07:43:07 pm
Also, bumping my request for Alpha+Letter in the compile menu.

And numbering like in the TI-OS prgm list, if possible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:08:14 pm
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?

If this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs
Title: Re: Features Wishlist
Post by: Builderboy on September 21, 2010, 11:10:34 pm
Maybe a good idea for an Axe program used as a library?
Title: Re: Features Wishlist
Post by: _player1537 on September 21, 2010, 11:12:54 pm
Also, bumping my request for Alpha+Letter in the compile menu.

This^^^^
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?

If this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs

Possibly the DCSB sum(13 command, except ... with ASM calling it... idk, it would require a 3 page app to use the program then.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:15:27 pm
Yeah, but I think the person meant the TI-OS-like menus. Does the sum(13 command looks like TI-BASIC menus? Also yeah some people may not be willing to make their prog require the 3 pages app. :(
Title: Re: Features Wishlist
Post by: Quigibo on September 21, 2010, 11:28:05 pm
Ok, I'm trying to decide if it's better to list the programs with either instant shortcuts like the BASIC menu (but not just 1-9, it would continue onto A-Z) or I could just use letters to go to the first program starting with that letter.  Since I haven't updated the poll for a while, I decided to change it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:39:03 pm
1-9 then A-Z seems cool to me. It might make it faster to compile stuff sometimes when you remember where are located each source files :)
Title: Re: Features Wishlist
Post by: calc84maniac on September 21, 2010, 11:53:43 pm
It might confuse your muscle memory if you make a new source file though :O

Especially since Axe doesn't say which program was actually compiled (perhaps you could add this, Quigibo?)
Title: Re: Features Wishlist
Post by: _player1537 on September 21, 2010, 11:57:47 pm
I also vote (if there was an option) to be able to compile from the homescreen with a similar method, maybe On-Number or similar, and you could set what those were inside Axe :)
Title: Re: Features Wishlist
Post by: SirCmpwn on September 21, 2010, 11:59:46 pm
With the sheer amount of programs I have, combined with how often I make new ones to mess up the list, I voted for the first option.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 12:59:31 am
Ditto as the good Sir
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 02:08:32 am
I was just reminded about the ability to make custom icons for MOS and DCS instead of the default Axe logo.  I've been thinking about it but I'm having a hard time thinking of a good format for this that is easy to use and unambiguous.  I challenge anyone to think of a good format for this.  It should be:

1. Near or at the top of the header.  Must come before program and data.
2. Parsed as a comment or something that is ignored when its not needed.
3. Similar to existing commands/conventions.
4. Relatively simple to implement.
5. No new tokens.
6. Not simply a commented out sprite since many people comment sprites at the start of their code.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 02:12:29 am
Why not just add the sprite on the first line after the title and the alternative description?
Title: Re: Features Wishlist
Post by: meishe91 on September 22, 2010, 02:41:02 am
Ya, I like Builder's idea. Just have it detect the "[" or what ever in the first line after the title (with or without the description). The only other idea I had was to have it on the next line with a ".[" signifying it.
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 04:00:53 am
But what if the description needs a bracket in it?  The problem with just the .[ is that it's likely a commented out sprite rather than the actual header.  Maybe .( .< ..[ or .[[ might work.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 04:06:17 am
if the description just happens to be an open bracket followed by 16 characters of hex followed by a closing bracket and nothing else then i guess they are out of luck :P
Title: Re: Features Wishlist
Post by: _player1537 on September 22, 2010, 07:17:50 am
I like the .[[ idea, I was actually about to suggest it :)
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 10:04:00 am
I think that you should extend headers more, actually.  Perhaps you could use psuedo-xml, which couldn't possibly be mistaken for commented out code, and could be more extendable.  I was thinking:
Code: [Select]
.PRGMNAME
.<SPRITE>HEX</SPRITE>
.<TARGET>APP/MOS/DCS6/ION/NOSTUB</TARGET>
Of course, only PRGMNAME would be required.  Sprite would default to the axe one, and target would override the settings if present.
Title: Re: Features Wishlist
Post by: Raylin on September 22, 2010, 11:06:50 am
Oooor.

Code: [Select]
.PRGMNAME SPRITE TARGET DESCRIPTION
You could recognize each space before DESCRIPTION as something else. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:13:38 am
Oooor.

Code: [Select]
.PRGMNAME SPRITE TARGET DESCRIPTION
You could recognize each space before DESCRIPTION as something else. :D
The problem with that is that in Ion/Mirage, this is supposed to be the file description. Example: .ROL3 The Reign Of Legends 3 would show The Reign Of Legends 3 in MirageOS. Maybe we should use some sort of XML-style header, as Sir suggested. I like the icon idea personally. I think the default Axe icon should be used by default when not using any, though.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 11:20:07 am
I'm still for the .ProgramName Description SpriteData idea :P it just makes sense that all the information should be in the first line, since that's where it all has been up to this point.  Also I don't think target is needed?  Since the target is defined in axe, not in the program.
Title: Re: Features Wishlist
Post by: calc84maniac on September 22, 2010, 11:29:51 am
Also I don't think target is needed?  Since the target is defined in axe, not in the program.
It would actually be better if specified in the program imo.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:43:45 am
I'm still for the .ProgramName Description SpriteData idea :P it just makes sense that all the information should be in the first line, since that's where it all has been up to this point.  Also I don't think target is needed?  Since the target is defined in axe, not in the program.
What if the description is multiple words, though? Would it be like .ProgramName "Description" SpriteData instead?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 22, 2010, 01:43:59 pm
or to keep the Axe syntax: .prgmName "Description" [spritedata]. then you could also do .prgmName [spritedata] when you don't want a description for some reasons...
Title: Re: Features Wishlist
Post by: calc84maniac on September 22, 2010, 01:45:21 pm
Well, all MirageOS/Ion programs have a description of some sort, even if it is empty. So perhaps in that case you would do: .prgmName "" [spritedata]
Title: Re: Features Wishlist
Post by: LordConiupiter on September 22, 2010, 04:58:45 pm
well, it just that I would like to see one syntax in Axe, and not some xml-style thing on the calc, because of it doesn't fit on the screen very well. <prgmname> would fill one complete line, which has to be scrolled through when you want to edit your code.

now suddenly another idea occurs to me: coul the header info be in an external prgm? like this:
Code: (Axe) [Select]
Program:TESTSRC
.prgmHEADER
DiagnosticsOff
.and the rest of the code...

Program:HEADER
TEST "A little test prog" [8142241818244281]
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 06:18:41 pm
Oh, I like that idea!
But we need to make sure that it keeps compatibility with old programs.
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 06:31:14 pm
What about UNIX style headers?  For instance:

Code: (prgmTESTSRC) [Select]
:.TEST -T MOS -I [123...DEF] -D This is a description

Which can also be defined as:
Code: (prgmTESTSRC) [Select]
:.TEST -D This is a description -I [123...DEF] -T MOS

So the programmer can choose the arguments in any order they like.  And to keep reverse compatibility, if you don't specify a tag, then it defaults to a description.  Also, that escape character would most likely be the negative sign instead of the minus sign because dashes might be used in the description.  This allows for future expansions available for the header as well.
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 06:33:34 pm
I like that!
I also really want to define the type in the header.  I've compiled too many apps x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:48:23 pm
Unix style syntax seems good, as long as it is well documented in the command list or documentation.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 23, 2010, 07:13:16 am
I prefer to have as less extra tokens to be used as possible. And IMO it's more clear to use sybols instead of letters, like in the UNIX style you use a minus symbol and a letter and an extra space, while in the syntax I suggested it's more clear because of the use of tokens to indicate the type of header data.

for compatibility reasons this is my edited plan:
Code: [Select]
Program:TESTSRC
.HEADER prgm
DiagnosticsOff
.and the rest of the code...

Program:HEADER
TEST "A little test prog" [8142241818244281]
Title: Re: Features Wishlist
Post by: ztrumpet on September 24, 2010, 09:51:59 pm
Sounds great! ;D
What does that mean for the Compile for in the Axe menu itself?  Will it just default to that if you don't specify?
Title: Re: Features Wishlist
Post by: Aichi on September 25, 2010, 12:06:53 pm
It will be nice if you create a Framerate feature, what makes possible, that you can choose a  FPS value for every loop.
The prog waits at the end of the loop until the value is reached.
It will be helpful for loops, which have differently fast frames, for example by a space shooter, that would have lags by to much active objects.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 12:46:10 pm
I'm not sure how feasible that would be, though it could be helpful.
In the meantime, http://ourl.ca/7043 (http://ourl.ca/7043) is a topic where someone was trying to do a similar thing ;)
I just bumped it, so eventually there should be a response.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:02:30 pm
I wonder if it would be feasible... it would be cool indeed, though. Personally I just:

 1: add some artificial delay that depends on the amount of objects on the screen
or
 2: simply display those objects on the screen even when unused, like a blank sprite using the OR logic.

In both cases, for tilemaps that only use one wall tile and one floor tile, never do like I did in the BASIC game Illusiat and not display any sprite for floor, because then when walking through areas with few walls, it moves many times faster than when there are many walls.
Title: Re: Features Wishlist
Post by: nemo on September 25, 2010, 02:16:34 pm
is there any chance that bitshift operators will be implemented?
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:27:48 pm
It might be ready tonight, because as another last minute decision, I decided to add support for expression valued label jumping!  The main reason is I thought it would be cool to add function pointers (which point to routines instead of data) because then you can do A LOT of crazy stuff with that.  For instance, lets say you write a subroutine that takes every element in a list and does an operation to it.  You can call that with a subroutine that takes as arguments: a list and a function pointer.  The routine then would call that function on each member of the list.  Like a function that squares the number, doubles the number, adds 1 to the number, or something really complicated.  Plus, a lot of asm programmers have been bugging me to add it for their other diabolical uses :P.


By the way, the new syntax for recursive subroutines is now this: sub(LBLr,1,2,3)

Its becasue it makes it easier for the compiler to know what type of routine it is before evaluating the arguments.  Surprisingly though, you rarely need it. Tail calls don't need them so you can actually write a lot of recursive subroutines already without this new feature.  Like for instance, this:

Code: [Select]
:.RECFACT
:
:.Find 6 factorial
:Disp sub(F,6)>Dec
:Return
:
:.FACTORIAL
:Lbl F
:!If r1
:  1
:  Return
:End
:r1*sub(F,r1-1)
:Return

EDIT: @Nemo
Yeah, *2 is shift left and /2 is shift right.  They automatically optimize to the bit-shift instead of the multiplication.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:33:18 pm
Sounds cool! :)
What'll the syntax for getting the value of a function pointer be?
Can't wait, keep up the good work!
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:35:03 pm
EDIT: @Nemo
Yeah, *2 is shift left and /2 is shift right.  They automatically optimize to the bit-shift instead of the multiplication.
What about arbitrary shifts? That should be as simple as "ld b,shiftamount \ call shift_right", etc.
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:41:28 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds

EDIT: @calc84
That's actually exactly what the multiplications do with multiples of 2 so left shifting is already optimized this way.  Right shifting however I am not currently doing this becasue it takes 8 bytes whereas it only takes 6 to call the division with an argument.  Do you thinking that I should optimize this for speed instead of size?
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:42:42 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds
Does this work with sub() too?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:44:09 pm
Mhmm could you explain expression valued label jumping? In your code example I see no "Lbl". Could you post a more visual way explaining it? (maybe a screenshot of it in action or something) because I really don't get what you mean despite the explanation :/
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:49:02 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds
My main question was "If I have a label A, how do I get its address?" ;D
Also, couldn't it be {A} to be more consistent? (Also, will, say, (using brackets, not parentheses) {L1} jump to the beginning of the L1 saferam area, and will {{L1}} jump to the address at {L1}?)
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:51:23 pm
Also, couldn't it be {A} to be more consistent?
That implies a memory read from the pointer stored in A, which is not consistent. The official z80 syntax makes this mistake too, naming an instruction jp (hl) instead of jp hl
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:53:54 pm
It should work with sub(), but I'm not sure if it will work with the recursive sub().  By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?

I haven't started adding this feature yet so I can't really give any screenshots or visualizations, but I will provide an example when its released.  Its a fairly complicated and rarely used feature so don't worry too much about it.
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:54:44 pm
By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?
You are correct.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:57:33 pm
Also, couldn't it be {A} to be more consistent?
That implies a memory read from the pointer stored in A, which is not consistent. The official z80 syntax makes this mistake too, naming an instruction jp (hl) instead of jp hl
Ah, right, my bad. My questions about {L1} and {{L1}} become about (L1) and ({L1}), then :)
Quigibo, that seems about the best way to do it short of SMC.
Edit: Ninja'd with respect to Quigibo's question.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:59:39 pm
It should work with sub(), but I'm not sure if it will work with the recursive sub().  By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?

I haven't started adding this feature yet so I can't really give any screenshots or visualizations, but I will provide an example when its released.  Its a fairly complicated and rarely used feature so don't worry too much about it.
Oh ok.

I think in the final doc there should be some examples of most functions that are more complicated like in the TI-83 Plus manual. It might help a lot.
Title: Re: Features Wishlist
Post by: AngelFish on September 25, 2010, 04:44:22 pm
Is there a way to use the NOT() function in Axe? I've come across situations a few times where I want to test for a non zero value and a zero value in a conditional.

For example:

Code: [Select]
:If A and Not(B)
:Conditional code
:End

I can't figure out how I would do it in Axe, so I end up using
Code: [Select]
:If A
:!If B
:Conditional code
:End
:End
which would appear to be less efficient.

Basically, if there isn't a NOT() function for expressions in Axe already, it'd be nice to have one. Even if the function isn't more efficient, sometimes the End statements get a bit messy and it'd be nice to eliminate as many as possible.
Title: Re: Features Wishlist
Post by: Raylin on September 25, 2010, 05:05:09 pm
This is the wrong topic for that but you'd just:
Code: [Select]
:If A and (B<>EXP2)
Title: Re: Features Wishlist
Post by: AngelFish on September 25, 2010, 05:08:19 pm
Sorry about the topic , but wouldn't B<>EXP2 be false for all B≠EXP2. I see how that would work.
Title: Re: Features Wishlist
Post by: Builderboy on September 25, 2010, 05:19:11 pm
Wow the conditional routine jumping sounds really cool :D it does sound very confusing though, might have to take a while before its completely understood.  Does this mean that we are finally able to use labels as addresses?
Title: Re: Features Wishlist
Post by: ztrumpet on September 25, 2010, 10:44:28 pm
Wow, sounds awesome!  I can't wait for the new release! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 10:46:19 pm
I changed my vote because after seeing LordConiputer entry and having many others at once on my calc, and having used the CATALOG for a while, I feel that it might be better to have the list so when you type a letter, it goes to the first program that has that letter.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 09:40:28 pm
After compiling, I still think it would be nice, when compiling in program form, if Axe let us know how large is our executable code after compiling, so it give us a guide if we want to know if we are nearing the 8812 bytes limit and are trying to stay under it.
Title: Re: Features Wishlist
Post by: Quigibo on September 27, 2010, 09:59:38 pm
The main problem with that is the compiler doesn't know how big the output file is until it finishes compiling.  It would have to pause when its done somehow to allow the user to see the number which I think would annoy a lot of people who want speedy fast compiling, especially for smaller programs.
Title: Re: Features Wishlist
Post by: Michael_Lee on September 27, 2010, 10:01:32 pm
Maybe add an option that'll let you enable that?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 10:38:00 pm
Ah ok I see x.x

How are you gonna add a warning that the code exceeds 8812 bytes, though? If it is possible to do, then why at the end of the compiling wouldn't it be possible to tell a size other than 8812?
Title: Re: Features Wishlist
Post by: Quigibo on September 27, 2010, 11:41:10 pm
I'm not saying its impossible, I just mean that it would be annoying to happen every time you compile a program.  You definitely need to know when you're over the limit because that's a safety issue (potential crashes), but for smaller programs its not important since you cn check in the [2nd][Mem] menu anyway.

I like the idea of an option for it though.  I could display other statistics too like the number Axe subroutines used, percent data, tip of the day, etc.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 11:50:08 pm
would it absolutely slow down compiling, though? I thought it would simply be a matter of scanning through the file until the point where is located the data, then display the size, like when you compile an APP (although that displays the size including data).

If it's really inconvenient for smaller programs, I guess maybe it could be at least added as option, though.
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 12:21:38 am
It would be best to make a separate option [in OPTIONS] called 'Generate Report' that CALLS the compiler routine and but doesn't show the compile percentages. (The first pass and second pass thing.) Instead, it would say "Generating report..." and then display:

*Name of program:
*Bytes when compiled and warning if necessary
*Number of subroutines
*Composition percentile (how much is data, etc.)
*Tip of the day / "Did you know"

That's just my idea.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 28, 2010, 11:19:01 am
I like that idea! and I would name the option Compile in the OPTIONS menu, which could be set to report or percentage, and perhaps also both?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 11:40:32 am
It would be best to make a separate option [in OPTIONS] called 'Generate Report' that CALLS the compiler routine and but doesn't show the compile percentages. (The first pass and second pass thing.) Instead, it would say "Generating report..." and then display:

*Name of program:
*Bytes when compiled and warning if necessary
*Number of subroutines
*Composition percentile (how much is data, etc.)
*Tip of the day / "Did you know"

That's just my idea.
that could work too
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 11:42:08 am
I'd make it a separate option entirely. Compile seems too ambiguous.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 11:57:32 am
Yeah, and maybe I guess it is better if compiling is not too slow either. I tried contest entries and I know that some took quite a while to compile, and I was on a 15 MHz calc. NOw imagine on a regular 83+.
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 11:59:14 am
DJ, you run on a 15MHz? Which one?
And, I agree. Compiling needs to be fast.

Still voting for the compile keyhook inside of a program.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 12:03:24 pm
I usually run on my 83+. However, I slowly moved to my TI-Nspire because APP compiling doesn't work on my TI-83 Plus (hardware issue, I think).
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 12:08:33 pm
Awh... That sucks... :c
Isn't the Nspire slow and suckish for ASM? Or was that BASIC...?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 12:33:22 pm
Under OS 2.54 MP, everything runs at the exact same speed as on a regular 83+. In 15 MHz mode, the speed increase is much lower than it is on a real 84+, though.

Older Nspire OSes got incredibly slow speeds at times with ASM stuff.
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 09:56:56 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 10:06:53 am
that would be really easy to write in Axe! just send the info of the program first using the Send Command, while the other Calc is in Get()-mode.

I would do it this way:
1. give the sign: "I'm ready to send a program" with a certain command,
2. then send the length of the name,
3. then the name itself char by char,
4. and then perhaps the type of the data (prgm, locked prgm, appvar,pic etc),
5. and last but not least the data of the program itself.

I am willing to write this routine this evening, but not jet (it's just 16:00 o'clock over here)
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 10:07:15 am
Quigibo, this BCALL (http://wikiti.brandonw.net/index.php?title=83Plus:BCALLs:4E7C) may prove useful. I've never tried it though, so I don't know exactly how it works.
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 10:22:27 am
@ calc84maniac: Nice

@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:27:11 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.

If you want to call another Axe program, unless you desperately need them to be two separate compiled programs, this can already be achieved with included programs. Just call it as a subroutine in your main program without a Return, like this:

Code: (Your main program) [Select]
.PROGRAM

ClrHome
Disp "Hello "
sub(A)
Disp i
Return

Lbl A
prgmINCLUDE
       
Code: (prgmINCLUDE) [Select]
..

Disp "world!"
Return
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 10:32:22 am
@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
did you mean that! sorry, I misinterpreted your Post, for U suggested to use the Get command, and that's already used for data transfer between 2 calcs.

@Runer: how did you do that! those two code block next to each other?
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:53:31 am
@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
did you mean that! sorry, I misinterpreted your Post, for U suggested to use the Get command, and that's already used for data transfer between 2 calcs.

@Runer: how did you do that! those two code block next to each other?

A table:
Code: [Select]
[table][tr][td]Put one code block in here[/td][td]        [/td][td]Put another code block in here[/td][/tr][/table]
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 10:54:59 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.

If you want to call another Axe program, unless you desperately need them to be two separate compiled programs, this can already be achieved with included programs. Just call it as a subroutine in your main program without a Return, like this:

Code: (Your main program) [Select]
.PROGRAM

ClrHome
Disp "Hello "
sub(A)
Disp i
Return

Lbl A
prgmINCLUDE
       
Code: (prgmINCLUDE) [Select]
..

Disp "world!"
Return

@Runner: That method includes the CODE making up the included program and still compiles as one program. Think of what happens in the TI-Basic code

Code: [Select]
Disp "Hello"
prgmZCLRHOME
Disp "Goodbye"

I'm suggesting Axe have a way to do that. Like what calcmaniac said, using B_CALL ExecProg
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 12:15:37 pm
And I think ExecLib would be a nice token for it, which could be renamed to Exec, or ExecProg, with the following syntax:
Code: (Axe) [Select]
ExecprgmTEST
or
Code: (Axe) [Select]
ExecProg("prgmTEST"
.or
"prgmTEST"->Str1
ExecProg(Str1
just what would be easier for the compiler, and what fits the best to the other Axe commands. I personally prefer the second one, and perhaps even ExecCalc(, for there is the GetCalc command, and I like to see similar named commands is the language. I also like to see DelVar changed to DelCalc(, or GetCalc( to GetVar(
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 12:34:19 pm
Execlib only exists on 84+ OS, and only starting at a certain version I think. Not a good choice, I'd say.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 01:05:23 pm
ok, I didn't know that. perhaps e^( then? that's [2nd][LN]. or ExpReg, which can be found in the [STAT]->[CALC] menu as option [ 0 ].

but I still aim for syntax similarity for Calc files handling:
DelVar -> DelVar(
Archive -> ArchVar(
UnArchive -> UnArchVar(
GetCalc( -> GetVar(

and I wonder why input an float are in the external variables section, since float would fit better in the data/storage part, and input in the Text part.
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 01:55:24 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:

Title: Re: Features Wishlist
Post by: Ikkerens on October 05, 2010, 02:24:03 pm
Quote
Pt-Command()→BUFF   Performs any of the Pt-On(), Pt-Off(), or Pt-change() routines to an arbitrary buffer of your choice.

I would love the ability to use this with pxl-Test(
I have this pointer that points to a picture in the ram.
And I need to check wether a pxl is on or not within that picture.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 02:40:43 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:



But how would TIOS do it then? subprograms can be called in BASIC, or do BASIC programs not have to be copied to 959C?
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 02:44:40 pm
Basic programs dont have to be copied, thats the trick.  Since they are not assembled, they are interpreted, the TiOS can just read each line right out of the regular RAM where the program is located and parse it.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 02:48:14 pm
right! well, then it will become really very tricky I see...
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 05:14:35 pm
Dang, I just realized that Quigibo disabled Axioms with the last update... I'm guessing he's reworking them. But anyways, when they've been reworked and are enabled again, could someone (maybe even Quigibo as an example Axiom) make a fast sprite display routine? When I say "fast" I mean as fast as a sprite routine can possibly get: no aligning, no clipping, and with whichever display method/logic works fastest (it would be nice to be able to specify an arbitrary target buffer, though). The main reason I'm asking is because I've been working on something that uses an aligned tilemap system, but the tiles are animated, and updating the tiles constantly brings the program to a crawl.
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 06:10:37 pm
Why would animated tiles be any slower than regular tiles?  Don't you have to display them every frame anyway?
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 06:45:53 pm
Why would animated tiles be any slower than regular tiles?  Don't you have to display them every frame anyway?

Why would you need to display static tiles every frame? You can just draw them once and repeatedly display that rendered image. Whereas you'll need to render animated tiles over and over.
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 07:16:20 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:


I think this is handled completely by the BCALL. A copy of the program is inserted at 9D95, and then it is run. When the program returns, the copy is deleted and the program running beforehand should be exactly where it used to be, so the BCALL will return properly.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 05, 2010, 07:19:03 pm
Where is the original program stored while the sub runs?
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 07:20:26 pm
It should be located directly after the newly executing program in memory (since the memory insertion shifts it over)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 05, 2010, 07:22:11 pm
Oh, I get it.
Title: Re: Features Wishlist
Post by: Quigibo on October 05, 2010, 09:30:56 pm
I'll definitely check out that bcall.

@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly.  I'm pretty sure I've seen someone do that before but I can't recall the thread...  For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite.  Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:49:04 pm
I'll definitely check out that bcall.

@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly.  I'm pretty sure I've seen someone do that before but I can't recall the thread...  For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite.  Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().

Yeah, I realize the speed increase wouldn't be terribly much, but I could use all the speed I can get. For what I'm trying to achieve, I need to draw about 2,000 sprites per second. I might try my own hand at the routine, but I get the feeling I'd end up writing it in such an unoptimized way that it would even be slower then a full-featured routine. :-\

Is there just a basic, unaligned 8x8 sprite routine without clipping floating around somewhere that I could steal? :P

By the way, what happened to Axioms?
Title: Re: Features Wishlist
Post by: ztrumpet on October 05, 2010, 11:34:49 pm
How about an 8*n sprite display routine that would be just like the regular ones but with an extra argument (default is at 8)?

Ex:
Pt-Off(0,0,Pic1,12) would display the 8*12 sprite pointed to at Pic1 at (0,0).

Quote
<From IRC Logs, calc84 talking about the Gameboy's sprite routines...>
<@calc84> all sprites are 8x8
<@calc84> well
<@calc84> unless you select 8x16 mode
<@calc84> in which case two tiles are used per sprite
<@ztrumpet> Why isn't there an 8*16 mode in Axe?
<@calc84> lol
<@ztrumpet> I'm serious
<@ztrumpet> I've wanted that for a while and keep forgetting
<@calc84> I don't know why there isn't an 8xN sprite display in axe
<@ztrumpet> yeah
<@calc84> it's pretty much the standard for asm
<@calc84> and quigibo can make a default height=8
<@calc84> so existing code doesn't have to change
<@calc84> just add an extra height argument to the end
<@calc84> he would only really need to slightly change the clipping code
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 05, 2010, 11:37:37 pm
I assume this would be for example for characters and some enemies, right? I think that might be a good idea, IMHO. That way we don't need to use two sprites instead of one for stuff that moves around. For smaller sprites it might also save some space.
Title: Re: Features Wishlist
Post by: aeTIos on October 06, 2010, 06:55:04 am
a feature that I would like is to use the "goto" command as this:
224->X
goto{X}
end

this is much faster as
if X=224
goto 224
end

what does the omnimaga community think about this???
Title: Re: Features Wishlist
Post by: calc84maniac on October 06, 2010, 08:09:12 am
That seems more like a job for switch/case.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 06, 2010, 08:15:30 am
what is this command to do exactly? go to the label which has the name of the value stored in X? I think you should just write a handy subroutine for this, which could do the actions you would have placed in the label called [value of X]. like this:
Code: [Select]
244->X
Sub(LX,X

Lbl LX
If r1=224
.actions for label 224, or even:
Goto 224
ElseIf r1=225
.similar actions
ElseIf etc.
.and even more code, if you need it.
End

The switch-statement would be very handy for this in the future, but isn't implemented jet...

EDIT: kinda ninja'd, but not really IMO ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 06, 2010, 01:55:57 pm
Switch statements would be handy, but I don't know if Quigibo was still planning to add them in the future.
Title: Re: Features Wishlist
Post by: aeTIos on October 06, 2010, 02:53:15 pm
what is this command to do exactly? go to the label which has the name of the value stored in X? I think you should just write a handy subroutine for this, which could do the actions you would have placed in the label called [value of X].

The switch-statement would be very handy for this in the future, but isn't implemented yet...

yes, go to the value stored in X
uh, that code would be very long in my program, because there will be 111 if...goto routines.
Title: Re: Features Wishlist
Post by: Quigibo on October 06, 2010, 04:51:57 pm
The labels are just names, they don't actually exist in the executable so there would be no way to tell where you actually need to jump.  ASM jumps function differently than BASIC gotos becasue the ASM uses the actual address in memory which varies wildly as your code grows and changes.  I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.

The reason I don't have 8xY sprite drawing is because it will either make the existing routine larger and slightly slower or i would have to add a whole other sprite routine.  It gets complicated due to the clipping.

Title: Re: Features Wishlist
Post by: ztrumpet on October 06, 2010, 04:57:42 pm
or i would have to add a whole other sprite routine.  It gets complicated due to the clipping.
I vote for this option.  Personally, I don't think it would be a bad thing and it would make programs faster and smaller as an end result. :)
Title: Re: Features Wishlist
Post by: calc84maniac on October 06, 2010, 05:18:59 pm
I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.
You could possibly make Return break out of the switch statement (which could possibly be the smallest solution -- just 4 bytes to push the return location onto the stack and 1 byte per return, as opposed to no overhead and 3 bytes per break)
Title: Re: Features Wishlist
Post by: ztrumpet on October 06, 2010, 05:19:50 pm
I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.
You could possibly make Return break out of the switch statement (which could possibly be the smallest solution -- just 4 bytes to push the return location onto the stack and 1 byte per return, as opposed to no overhead and 3 bytes per break)
That's a really good idea!  I vote for this. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 06, 2010, 11:26:27 pm
Such sprite routine might be good, unless it really signifiantly make your program grow much larger (like 70-100 bytes larger).
Title: Re: Features Wishlist
Post by: Builderboy on October 06, 2010, 11:43:54 pm
But note that it will only make your program larger if you want to use it, and if you dont want the size increase, you can stick with the normal routine and just use two or more 8x8 :)
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 01:02:19 am
calc84maniac, I was thinking about that, and it's a great idea!

I also thought of an interesting new block type which is basically an anti-subroutine.  Instead of calling a routine and then returning from where you called it, you tell it the place you want to return to and then do the routine.  I'm wondering if that would be useful because I do that a lot in the actual parser code.  In Axe and assembly, it's basically this:

Code: (Axe) [Select]
SetRet(LBL)
...
Return
...
Lbl LBL

Code: (Assembly) [Select]
  ld de,LBL
  push de
...
  ret
...
LBL:

The switch statement itself would use something similar.  And since the return point is set to the end of the switch statement, I wouldn't need to add a new break command, you could just use "Return".  The main problem though is that this would actually create memory leaks if you tried to do a goto out of the switch statement from within the switch statement.  I think a common use of switch statements is branching to a bunch of labels though so I'd have to figure out another way to do that...
Title: Re: Features Wishlist
Post by: Ikkerens on October 07, 2010, 01:10:42 am
Hm... Quigibo, could you look into my suggestion on page 86 as well?
It seems to be totally forgotten, and its a feature I (and most likely alot of others) need.
http://ourl.ca/4057/124762
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 01:12:00 am
Yeah, I've already added that :)
Title: Re: Features Wishlist
Post by: Ikkerens on October 07, 2010, 01:13:06 am
Oh cool!
Thx :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 02:46:02 am
But note that it will only make your program larger if you want to use it, and if you dont want the size increase, you can stick with the normal routine and just use two or more 8x8 :)
One concern I got, though, is if you use both 8x8 and the others, wouldn't both routines be added? That might waste a bit of space x.x
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:38:50 am
I have many ideas for projects atm, but I lose the most possibilities by the memory which is avaible for a game.
How possible would it be to let Axe compile a code into an 32/65KB app?
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 11:48:12 am
You mean 64, not 65, right? s:
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:52:46 am
16384 B; 32768 B; 65536 B, or not?
Maybe youre right, I never saw an app with this size
Edit: I made KB to B.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 11:54:21 am
One MB is 1024 KB, not 1000 KB. 65536 KB is exactly 64 MB.
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:56:13 am
Damn, i mean Byte, not KB. x.x
Ok, that confused me. =D
Apps can have a size of 65KB.
What I wrote in the first post should be right.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 12:04:57 pm
Wait what. I think I confused myself there too. sS:

But I'm pretty sure the app is 64 and not 65, no matter if it's MB or KB.
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 12:10:53 pm
You should input
16384
Ans*2
into the homescreen.
Press ENTER by 2 times, then the TI outputs
16384
32768
65536.
That must be the avaible size (In Bytes) of apps.
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 12:11:01 pm
It's 65.5KB, or 64KiB
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 12:22:58 pm
What Runer posted is correct.

@ JosJuice
I think you meant kibibyte.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 12:26:13 pm
Yes, I probably did. I'm very used to using KB/MB when talking about the unit that is 1024.
Title: Re: Features Wishlist
Post by: ztrumpet on October 07, 2010, 07:29:52 pm
Quigibo, are you thinking of adding the new sprite routines or not? :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 07:33:43 pm
And another UI request: When it scrolls to the prgm, could it scroll into the included program if the error occurred there?
Title: Re: Features Wishlist
Post by: shmibs on October 07, 2010, 07:34:03 pm
/\yeah, 8*16 sprites would be absolutely invaluable in the things im working on right now

EDIT: ninja'd? that was referring to ztrumpet
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 07:35:49 pm
/\yeah, 8*16 sprites would be absolutely invaluable in the things im working on right now

EDIT: ninja'd? that was referring to ztrumpet

They'd just be two 8x8s, wouldn't they?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 08:05:50 pm
For games larger than 16 KB, the only solution right now is to split your code in multiple Axe executables that are under 8811 bytes of executable code and use a TI-BASIC program assisted by an ASM lib to launch them separately (kinda like Illusiat 13, but instead of launching BASIC programs you would launch Axe ones), but then it isn't pure-Axe programming anymore. It would be nice later to have multiple pages app support so the entire first page can be used for code. Alternatively there are appvars.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 08:20:00 pm
Or maybe you could hack it using GetCalc( to find the second prgm...
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 09:19:29 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:



EDIT: Wow, how did I miss this: the Line() command working on back/arbitrary buffers. The routine's already there, it's gotta only take like 10 seconds to modify it for this. I hear you already did it for the pixel commands, which is good.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 09:52:10 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:

  • InsertMem and DelMem bcalls. They would be invaluable for editing variables with a large amount of data in them. (If anything, this is the feature I would want the most, and it seems fairly easy to implement)
  • Case statements.
  • Reading from/storing to the Ans variable for things other than integers (namely strings).
  • Dialog (menu) bcalls.
  • General bcall support.

All b_calls can be accessed with Asm(EFXXXX).

I support using Ans for strings! It'd be really helpful, and I have no idea how to do it myself.
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:01:10 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:

  • InsertMem and DelMem bcalls. They would be invaluable for editing variables with a large amount of data in them. (If anything, this is the feature I would want the most, and it seems fairly easy to implement)
  • Case statements.
  • Reading from/storing to the Ans variable for things other than integers (namely strings).
  • Dialog (menu) bcalls.
  • General bcall support.

All b_calls can be accessed with Asm(EFXXXX).

I support using Ans for strings! It'd be really helpful, and I have no idea how to do it myself.

how might we use this? for example, i see insertmem is 42F7h. so Asm(EF42F7) would run the bcall, but how do you write to the registers? since HL is the amount to add, and DE is the address at which to add? also, what if there's something important in HL or DE?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:02:47 pm
HL is always Axe's form of "answer", so
Code: [Select]
:X+1
would leave the value of X+1 in HL. For the others I guess you'd need Asm( as well...
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 10:05:55 pm
In Axe you can only set hl, which contains the current value in the calculation. de is used sometimes in two-argument instructions, but that can't be done with Asm(.
Also, due to endianness, it would be Asm(EFF742), not Asm(EF42F7) ;)
Edit: semi-ninja'd
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:07:00 pm
In Axe you can only set hl, which contains the current value in the calculation. de is used sometimes in two-argument instructions, but that can't be done with Asm(.

Can't you load something to DE with Asm(, though?
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:09:51 pm
i'd assume anything you can do in asm you can do with asm().... also, would i need to then push every register onto the stack and pop them accordingly after the bcall, since insertmem destroys all registers? yeah... i would like insertmem+deletemem support.
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 10:11:27 pm
In the Asm( hex, yes. However, outside of Asm(, there is no way AFAIK to set de before invoking an Asm( command.
Sorry if I was confusing. :(
Edit: semi-ninja'd again
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:12:23 pm
i'd assume anything you can do in asm you can do with asm().... also, would i need to then push every register onto the stack and pop them accordingly after the bcall, since insertmem destroys all registers? yeah... i would like insertmem+deletemem support.

I guess they would make nice features, but should be highlighted in the docu as very advanced features.
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:16:17 pm
calcdude, would you be willing to write the hex string that would insert memory (as specified by HL) into an address specified by the axe pointer V?
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 11:29:42 pm
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.

bcalls aren't useful to implement becasue of the reasons you're discussing now.  bcalls require very specific register input and very specific register output.  There wouldn't be an easy way to translate that directly to Axe syntax.

InsertMem, DelMem, and EnoughMem are possible, I will look into some good tokens for them.

There is no bcall for making menus as far as I am aware.

EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I may support 8xY sprites, but I'm not sure yet.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:35:36 pm
Don't Bcalls location changes from an OS to another too?
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:36:35 pm
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.

GetCalc("Ans") returns 0 for me whether I use the Ans token or spell it out. Also, I believe storing strings to Ans involves a more complex method in which you need to create a temporary string variable in which to store the string, and then store that variable's name in Ans.

There is no bcall for making menus as far as I am aware.

Is this (http://wikiti.brandonw.net/index.php?title=83Plus:OS:Dialog_context) not it?
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 11:38:15 pm
Don't Bcalls location changes from an OS to another too?
DJ, not really. Normally they are only added.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:38:53 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 11:42:04 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:44:24 pm
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:45:29 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:50:50 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.

The garbage collect routine very well may have moved. But seeing as there isn't actually a garbage collect bcall and garbage collecting is handled entirely by the OS, unless you have a hacked OS with different parts from different versions, garbage collecting should work fine.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:52:14 pm
Ah ok. Well, in the GC talk with him, what we were discussing mostly are custom garbage collect messages and forcing a gc. GC'ing by itself seemed easy, but as long as you used the default one.
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 11:59:17 pm
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.

Usually for a UI you only need strait lines in which you should use rectangles with singular width or height.  Those can be drawn to the backbuffer.  The menu context is interesting, I hadn't seen that before (since its undocumented) but I will certainly check it out.  From the looks of it though, it seems really large and complicated if its implemented similar to the way BASIC does it.  I don't know how I'd be able to take any amount of arguments either.
Title: Re: Features Wishlist
Post by: alberthrocks on October 08, 2010, 12:05:16 am
Some features I'd love to see implemented:
1) Math specific functions - int( is something I'd love to see. :D Float math is also requested too...
2) input problem.. but I assume that is being fixed atm.
3) Mini input, either on screen, buffer, or backbuffer. Perhaps something like this?
Code: [Select]
minput(startx, starty, endx, endy)->Str1
Example:
minput(10,20,86,28)-> Str1
 (above: 8 units alloted for y, since 6 is height of tiny text, plus 2 for padding.)
Multiline: (If you decide to do so)
minput(startx, starty, endx, endy, multiline BOOL)->Str1
(Multiline is just multiple lines, within the rande of (startx, starty) and (endx, endy).)
Different buffers:
Buffer:
minput(startx, starty, endx, endy, multiline BOOL)ʳ->Str1
Backbuffer:
minput(startx, starty, endx, endy, multiline BOOL)ʳʳ->Str1

Just a thought. :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 08, 2010, 01:42:38 pm
Maybe Mirage-style input?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 08, 2010, 05:49:01 pm
As long as it lets you cancel, unlike in Mirage 1.1 x.x

Maybe Kerm could provide some routines from his Doors CS one? :D
Title: Re: Features Wishlist
Post by: Runer112 on October 09, 2010, 02:53:54 pm
It sounds like you're trying to implement switch statements, but perhaps vector/jump tables could also/alternatively be implemented? They would probably be simpler to code, as the user would end up writing the table for you, and could be activated with only one line. Another nice thing about a vector/jump table is that you can jump to pre-existing routines instead of having to do something like Case 0 / sub(A) with switch statements. Perhaps something like this to store it:

Code: [Select]
[[A,B,C,D,E,F,SUB,etc.]]→GDB0
And something like this to jump to an entry:

Code: [Select]
Goto GDB0,X
.or
sub(GDB0,X)

(The difference between the two being that Goto uses JP and sub() uses CALL.)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 09, 2010, 06:29:05 pm
Not that important, but a length()r would come in handy for me.
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 12:35:53 pm
Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 01:17:18 pm
I think an on-calc documentation of all the commands would be most excellent.
Title: Re: Features Wishlist
Post by: JosJuice on October 10, 2010, 01:18:39 pm
I think an on-calc documentation of all the commands would be most excellent.
That would take a lot of space... D:
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 01:19:38 pm
That's very true...

well, maybe it could be a separate file included for users who want to have it on hand.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 10, 2010, 02:43:47 pm
I think he planned a summary of documentation due to the Help option in the menu, but if I remember, it would more be like CtlgHelp, listing the syntax for each functions. Otherwise it would be very large. Included or not, I think it should be a separate file, though.
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:34:32 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:37:52 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D

Ah, an idea...

* Deep Blue adds that on his own features list

It's a nice idea for Axe as well. Maybe it could replace that Help option? It doesn't even do anything now anyway, so maybe it could be converted into an option to turn syntax help on/off?
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:39:06 pm
yeah, I'd be fine with a small yet complete doc on calc
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:40:11 pm
yeah, I'd be fine with a small yet complete doc on calc

That's not what ztrumpet suggested (I think), but it is what Quigibo will eventually add in place of that Help option in the main menu (again, I think).
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:41:21 pm
Like I said, anything would be fine for me.
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:44:37 pm
For me, i think an upgrade to the Fill() command is in order.  Usualy when people fill elements in RAM, they want to fill it with specific values.  But currently they have to put the value in the first element for fill to work, and this means you have to calculate the Address twice.  Wouldn't it make a lot more intuitive and useful sense (not to mention probably smaller) to do something like Fill(Address,Length,Number) ? that could even be an alternative syntax if you wanted backwards compatibility.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:46:00 pm
That sounds like a good idea...

How does the calc do it, though?
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:46:38 pm
That's a good thing too.  Plus, whenever you create an appvar, it is filled with random data from the start.  maybe in a new version you can clear variable's values at initiation?

Otherwise I have to set the fist element to 0 and do a fill()
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:47:54 pm
That's a good thing too.  Plus, whenever you create an appvar, it is filled with random data from the start.  maybe in a new version you can clear variable's values at initiation?
I do not support this idea, as it takes more code and is, therefore unoptimized in certain situations. :)  I think it should remain as is. :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:48:05 pm
Maybe if the calc needs to fill from a value that's already there, Fill(location, value, size) could put the value at the starting place and fill it from there? Again, I'm not sure how it works myself...

EDIT: Yeah, I agree, GetCalc( should not clear it for us. Programs often need to initiate it to something else, anyway.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:49:16 pm
yeah, that sounds better.  then you can zeroize it much easier if you want to.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:50:30 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:51:06 pm
The way the calc does it is with a Copy() command i believe.  It copies the 1st element onto the 2nd element.  The 2nd onto the 3rd.  Ect... and it works like a fill command.  There is a built in command for this, and its quite fast.

EDIT: And i believe it *does* take more code actualy.  Since at the very least you are loading the address of the location to be filled *twice* instead of once by combining both steps into one command.

EDIT2: Unless you were talking about the file clearing and not the Fill() command?

EDIT3: Ninjas ninjas everywhere!

EDIT4: Can i ever escape???

EDIT5: Help meeeeee :(

EDIT6: Finally, the light!
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:51:54 pm
EDIT5: no you're screwed my friend :D
EDIT6: by the ninja's that is
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:53:04 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
That's not how CtlgHelp works; if you're in a menu then you can press + on a command and see it's information. :)
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:54:02 pm
yeah, ztrumpet is right.  I think :?

but yeah, one of those would be great!
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:54:27 pm
Lol anyways i think we need Quigibo's input on the Fill() idea, and if it would take less code overall when using both setting and filling.

EDIT: And catalogue help would be cool :D But tricky o.O but i think its the best option.

EDIT2: Yeah Ztrumpet is right
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:55:05 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
That's not how CtlgHelp works; if you're in a menu then you can press + on a command and see it's information. :)

No, it's in the catalog :)
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:55:41 pm
Well, on the + key is the quotation mark, so no problems there. I'm just wondering '-' how it would work well...
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:55:45 pm
yeah.  I'm guessing it's like in Omnicalc, where in the extra prgm commands you press + and it displays the parameters.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:56:41 pm
yeah.  I'm guessing it's like in Omnicalc, where in the extra prgm commands you press + and it displays the parameters.

Yeah, that sounds like a better alternative to CtlgHelp's style.

EDIT3: Ninjas ninjas everywhere!

EDIT4: Can i ever escape???

EDIT5: Help meeeeee :(

/me calls Steve Jobs
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:57:07 pm
* ZTrumpet eats everyone... :P
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:57:55 pm
yeah, I mean, all you really need is the parameters, those usually speak for themselves.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:58:46 pm
I was aware of that; I was just wondering how it '-' could work well in the catalog with 'W' on it...
Edit: Directed at ztrumpet's post.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:59:44 pm
* ZTrumpet eats everyone... :P

Yeah, that's what I meant, it's in the catalog, not in the actual menus. I must have misunderstood what you said, sorry...

EDIT: Personally I think it'd be a better idea to use Omnicalc's syntax help, which is in the menu itself, instead of in the catalog, because a lot of catalog functions aren't used by Axe anyway.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 04:01:55 pm
Only about 20 of them are used by axe :P
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:02:40 pm
Only about 20 of them are used by axe :P

Exactly. So it would be far less confusing if the syntax help were in the menus.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 04:04:02 pm
I can't wait for this to be in a somewhat finished stage (yeah, I'm getting off topic now :P)

I won't have to carry around 5 sheets of paper to refer to the multiple commands :D
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:23:33 pm
The fill command needs only to look up the address once when using a variable pointer:

Fill(0->{A},10) will fill all the bytes from A+0 to A+10 with zeros.  This is becasue when storing to a variable pointer, it returns the address instead of what was stored there.  You usually have this situation when dealing with appvars.

As far as static addresses... it could be optimized if it were pure assembly, but the problem is that unless I could guarantee that all the arguments were constants (using look-ahead parsing), I would have to push and pop the extra argument and it would not be any more efficient that using the static address twice.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:27:04 pm
Oh, yeah, I guess Fill(0->{A},10) isn't that much more code than Fill(A,0,10)...

By the way, Quigibo, would 1->{E86EC}r be exactly the same (e.g. speed, size, etc.) as 1->A?
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:30:51 pm
Don't use that!  If I decide to move where the variables are located, that code will no longer work and be outdated.  Use 1->{oA}r instead as this will guarantee that you have the right address even if I move them.  And yes, it will be the exact same in the executable as 1->A byte-for-byte.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 04:31:38 pm
If you mean E86EC, and $86EC is the address of A, then yes. Note that you should be saying 1->{oA}r, though, to be future-compatible ;)
Edit: ninja'd
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:33:49 pm
So if I wanted to use SaveSScreen as a buffer, I should access it from {E86EC} onward, right?
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 04:38:09 pm
Maybe... I'm not sure, and if Quigibo changes anything...
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:40:15 pm
I suppose you could... but you would not be allowed to use the variables A-Theta in your program then.  You would have to use the r1-r6 variables and store the rest directly to another buffer which could be very confusing given that you have to write down what variable each address represents.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:43:50 pm
I suppose you could... but you would not be allowed to use the variables A-Theta in your program then.  You would have to use the r1-r6 variables and store the rest directly to another buffer which could be very confusing given that you have to write down what variable each address represents.

I've already moved all of my vars in-prgm. Bit more mem, but some of it's initiated, anyway. (That's why I asked the question, btw.)

What are r1-r6?

And another question: I noticed the GetCalc([NAME], [FILE]) syntax. Where are "files" stored?

And yet another question :D: Why is L1 SaveSScreen+56? A-Z and theta are only 54 bytes... I heard that the last one's used for random numbers, though. How is it updated?
Title: Re: Features Wishlist
Post by: Runer112 on October 10, 2010, 05:39:10 pm
Holy crap that was a huge storm of sudden posts :o Just to make sure you didn't miss it Quigibo, did you see my feature request (http://ourl.ca/4057/126388) for vector/jump tables?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 10, 2010, 11:53:23 pm
For me, i think an upgrade to the Fill() command is in order.  Usualy when people fill elements in RAM, they want to fill it with specific values.  But currently they have to put the value in the first element for fill to work, and this means you have to calculate the Address twice.  Wouldn't it make a lot more intuitive and useful sense (not to mention probably smaller) to do something like Fill(Address,Length,Number) ? that could even be an alternative syntax if you wanted backwards compatibility.
Yeah I think it should work like in BASIC. That's unless it is much larger of course.



Holy crap that was a huge storm of sudden posts :o Just to make sure you didn't miss it Quigibo, did you see my feature request (http://ourl.ca/4057/126388) for vector/jump tables?
I deleted it ;D

J/k, but the ironic thing is that there was a huge storm of posts, then now tonight, there's a huge storm of 500 Internal Server Errors, even thought almost nobody was posting x.x
Title: Re: Features Wishlist
Post by: LordConiupiter on October 11, 2010, 09:46:57 am
that's not so nice :O...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 11, 2010, 04:17:47 pm
Lol as said in my post I was kidding, unless you mean the 500 server errors?
Title: Re: Features Wishlist
Post by: LordConiupiter on October 12, 2010, 11:39:18 am
yes, that was what I meant :). i get them pretty often, well, let's say once a week. but when I reload, the error seems to be already solved :D
Title: Re: Features Wishlist
Post by: Darl181 on October 12, 2010, 07:56:49 pm
New request (I think):
Line(X1,Y1,X2,Y2,)r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)
Title: Re: Features Wishlist
Post by: ztrumpet on October 12, 2010, 08:43:57 pm
There is no way to have a third buffer just "added".  However, here are your options:
1) Do not use the variables A-Z or Theta or rand and use L1-56 as a third buffer.
2) Create an AppVar and use it as your third buffer.
3) Persuade Quigibo to add the Insert_Mem() and Delete_Mem() bcalls. :P

I hope you can use one of these.  Good luck and I can't wait to see what it ends up looking like. ;D

Edit: * ZTrumpet eats Runer... :P
Title: Re: Features Wishlist
Post by: Runer112 on October 12, 2010, 08:45:24 pm
New request (I think):
Line(X1,Y1,X2,Y2,)r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)

Ive already asked Quigibo for a line routine for the back buffer :P but maybe your second request for it will help better convince him to add it.

As for a third buffer, Quigibo is limited by the safe RAM areas that exist on the calculator and are big enough to hold 768 bytes, of which there are only three. L6 and L3 are two of them, and the third is at L1-56. The first 56 bytes of this screen storage area are used by the random number generator and the 27 variables. If you wanted to use this area, you would have to avoid the use of the rand function and allocate some other place in RAM for variables (and any other data you might have had in L1), possibly a different safe RAM area or an appvar. However, this is a bit of a pain, so what I would suggest is creating a 768-byte appvar for the third buffer when your program starts and delete it when exiting.


EDIT: How did I know I would get ninja'd on this one...
Title: Re: Features Wishlist
Post by: Builderboy on October 12, 2010, 10:04:12 pm
I have an interesting request.  I request that the user variables are moved into L2 so that L1 can be opened up into a 3rd full screen buffer, or a larger span of memory.  L2 *is* the location for some interrupt data for MirageOS and Axe alike, but MirageOS does not seem to use the last 56 bytes of L2 and i believe Axe could be restructured in itself.  What do you think?  Is this possible?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 12, 2010, 10:38:07 pm
1) Do not use the variables A-Z or Theta or rand and use L1-56 as a third buffer.
I thought those vars were moved elsewhere to allow the usage of both the 768 bytes there and the variables?
Title: Re: Features Wishlist
Post by: Builderboy on October 12, 2010, 10:51:21 pm
I just checked and they are still at L1-56 as of version 0.4.5.  Moving them is what i was suggesting :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 12, 2010, 11:20:14 pm
Ah ok. I thought Quigibo said he might move them before.
Title: Re: Features Wishlist
Post by: Darl181 on October 13, 2010, 01:50:19 am
I was able to work around it.  A bit of a slowdown, but oh well.
The line request still stands though ;)
Title: Re: Features Wishlist
Post by: Runer112 on October 13, 2010, 05:41:22 am
I have an interesting request.  I request that the user variables are moved into L2 so that L1 can be opened up into a 3rd full screen buffer, or a larger span of memory.  L2 *is* the location for some interrupt data for MirageOS and Axe alike, but MirageOS does not seem to use the last 56 bytes of L2 and i believe Axe could be restructured in itself.  What do you think?  Is this possible?

I second this.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:43:54 am
I agree with moving the variables to L2.
I also second the backbuffer line drawing request, but I want to extend it to allow lines to be safely drawn off screen.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 13, 2010, 10:03:03 am
I don't really care where the vars are located. I was using their locations to edit them in some old code, but I replaced that code with new code, so for me this is not a problem at all. I could become very handy in cases when you need to store the current screen to an extra buffer, though you could use an Appvar for that. But when L1 would become 768 bytes, then it will be faster to use that, but the difference in duration would be unnoticably small, I think.
Title: Re: Features Wishlist
Post by: Darl181 on October 13, 2010, 10:37:56 am
The reason three buffers would help--1st buffer:2nd and 3rd buffer write to and use for dispgraph--2nd buffer:use for static (not moving) map--3rd buffer:enemies
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 11:20:28 am
I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.
Title: Re: Features Wishlist
Post by: Runer112 on October 13, 2010, 12:49:32 pm
I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.

Seeing that there's a bcall called InsertMemNoUpdateVAT, I would have to assume that InsertMem (and DelMem) automatically update the VAT.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 01:48:26 pm
Oh, I see.

And yes, I second (or whatever this is) the request to move the vars to L2.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 13, 2010, 03:24:53 pm
I agree with moving the variables to L2.
I also second the backbuffer line drawing request, but I want to extend it to allow lines to be safely drawn off screen.
Would it cause problem with Mirage, though?
/me hopes Doors CS doesn't have those issues with L2...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 03:50:48 pm
Builderboy mentioned earlier that Mirage doesn't use at least the last 56 bytes of L2, so it should work. I don't think DCS has any built-in interrupts at all, so you can toy with L2 all you want.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 13, 2010, 03:56:50 pm
Ah ok, sounds good if it's the case.
Title: Re: Features Wishlist
Post by: kindermoumoute on October 13, 2010, 04:47:54 pm
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 04:51:11 pm
It has been asked, but apparently no one's taking that up yet. For now, just use Wabbit and export it (but wait until BuckeyeDude fixes the export function).
Title: Re: Features Wishlist
Post by: calc84maniac on October 13, 2010, 04:53:32 pm
I think he's talking about programs for the original TI-83 (no plus). I don't think that would be an easy task, though (one reason because TI-83 doesn't have the same saferam areas that we use for L1-L6)
Title: Re: Features Wishlist
Post by: ztrumpet on October 13, 2010, 04:55:38 pm
I agree with Builderboy on moving the Vars.  This would be immensly helpful to a program that I'm writing now.  Please do it! ;D
Title: Re: Features Wishlist
Post by: Builderboy on October 13, 2010, 05:22:46 pm
Yeah MirageOS uses only parts of the begining for its own variables and interrupts, but the last 56 bytes are safe.  As for Doors, it doesn't use any RAM space while a program is running, as it uses its own AppVar for storage, so it seems like the move to L2 would be fully safe :) Axe just needs to make sure that its own interupt routine doesn't use the last 56 bytes as well
Title: Re: Features Wishlist
Post by: calcdude84se on October 13, 2010, 05:37:33 pm
I must agree; the lack of another full buffer has been annoying me for a while ;D
So, seconded (or whatever number we're on... :P)
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 06:14:32 pm
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:29:16 pm
I think he's talking about programs for the original TI-83 (no plus). I don't think that would be an easy task, though (one reason because TI-83 doesn't have the same saferam areas that we use for L1-L6)

Misread, sorry :-\ Should be possible for the most part.

I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.

Ah, great! If you do it, may I suggest an option to compile to a program that can be run from the homescreen like with BASIC?
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:33:15 pm
What, like include a seperate TI-Basic launcher program?
Title: Re: Features Wishlist
Post by: calcdude84se on October 13, 2010, 08:35:37 pm
Forward references. I don't know how to add more to this... ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:38:52 pm
SirCmpwn: Here (http://ourl.ca/6481/105951).

If anyone includes that code as the header of any TI-83 ASM program, it can run from the homescreen, no launcher/Send(9 needed.

Of course, that's in theory (since I don't have an 83 to check).

Actually, if you wait a bit, I'll test it in Wabbit.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:44:41 pm
Does this work on an 83+?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:54:09 pm
Nope, because of $BB, $6D.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:55:19 pm
Thought so.  Then I probably can't do that...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 09:26:47 pm
Do what? It could work with the plain 83.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 14, 2010, 01:28:22 am
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.
That might be cool, as there are still 82 STATS/83 users (both the same calc) around in Europe.
Title: Re: Features Wishlist
Post by: Darl181 on October 14, 2010, 06:46:54 pm
New thing.  ERR: UNKNOWN ERR  Error code: 4535555  has to do with garbage collecting.  Maybe in 1.0 it could know what the code is and garbage collect.
On second thought, it seemed to miss it or something... I had tried it ~20 times and had given up on it.  I tried again just now and it asked.  Maybe have it garbage collect on that error.
Title: Re: Features Wishlist
Post by: nemo on October 23, 2010, 09:38:13 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 23, 2010, 09:39:14 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.

I'd say maybe putting it in parens so that it won't be confused for key number values.
Title: Re: Features Wishlist
Post by: Runer112 on October 23, 2010, 10:15:06 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.

I guess such a routine could exist, but because of how the keyboard hardware works, it would be fairly bulky and slow. It's probably better to just stick with preassigned keys.



EDIT: So as not to double post, I'll add the following as an edit. It is, however, entirely unrelated.

I guess this request is sort of a form of look-ahead parsing, which is generally difficult to implement, but I believe this is a very basic form that has already been similarly implemented with pre-calculation involving constants. I was wondering if statements such as A+{L1+4}r, which is currently parsed as:
Code: [Select]
ld hl,(A)
push hl
ld hl,(L?+4)
pop de
add hl,de
Could be optimized to be like normal variable addition:
Code: [Select]
ld hl,(A)
ld de,(L?+4)
add hl,de
The same goes for things like subtraction and any other things I may be forgetting that could be optimized this way.


EDIT 2: Oh, by the way, you misspelled "routines" in the fourth line of the Commands.inc file :P



EDIT 3: Man, this post is getting really big! But I promise this next feature request will be simple, I'll even give you the code for it!

Code: (Hexadecimal display (?Rect or ?Polar seems like the best choice)) [Select]
p_DispHex:
.db __DispHexEnd-$-1
ld c,h
call __DispHexByte
ld c,l
__DispHexByte:
ld a,c
rra
rra
rra
rra
call __DispHexNib
ld a,c
__DispHexNib:
or F0h
daa
add a,A0h
adc a,40h
B_CALL(_PutC)
ret
__DispHexEnd:

p_TextHex:
.db __TextHexEnd-$-1
ld c,h
call __TextHexByte
ld c,l
__TextHexByte:
ld a,c
rra
rra
rra
rra
call __TextHexNib
ld a,c
__TextHexNib:
or F0h
daa
add a,A0h
adc a,40h
B_CALL(_VPutMap)
ret
__TextHexEnd:



EDIT 4: Oh, and you haven't forgotten about this (http://ourl.ca/4057/126388), have you? Haha sorry for swamping you. ;)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 24, 2010, 09:42:51 am
Hex display, definitely :D Either ▸Rect or ▸Polar would work.

And this:

Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)
Title: Re: Features Wishlist
Post by: BlackRabbit on October 24, 2010, 12:01:08 pm
Mabe you could make it so you can insert program icons. (Like in Doors or Mirage.)

Code: [Select]
.PROGRAM Description
.[16*16 hex icon]
[i]program code[/i]
Title: Re: Features Wishlist
Post by: Runer112 on October 24, 2010, 12:13:23 pm
Hex display, definitely :D Either ▸Rect or ▸Polar would work.

And this:

Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)

If you urgently need a routine for that, you could do it with the following assembly:
Code: [Select]
Asm(AF474FEDB921FFFFED42)Just put the pointer value right before that.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 24, 2010, 04:27:13 pm
If you urgently need a routine for that, you could do it with the following assembly:
Code: [Select]
Asm(AF474FEDB921FFFFED42)Just put the pointer value right before that.

That's actually exactly what I'm doing right now (even the hex string, I'm pretty sure). I just thought it might be a feature that someone might need in the future, and length( doesn't take an r yet anyway.
Title: Re: Features Wishlist
Post by: BlackRabbit on October 24, 2010, 09:36:25 pm
Thanks for the help.  :)
Title: Re: Features Wishlist
Post by: JustCause on October 25, 2010, 10:08:25 am
Setting the rand seed (think K->rand in BASIC).

(Also, on another rand note, when I use the included Guess the Number program from Mirage, the number is always either 4 or 6. Another reason for this command.)
Title: Re: Features Wishlist
Post by: calcdude84se on October 25, 2010, 10:20:50 am
AFAIK the Axe rand seed is two bytes somewhere in RAM. Maybe using °rand could get us that address? at which point you could use something like S->{°rand}r.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 10:35:10 am
I think it's {L1-2}r, the two bytes after A-Z and theta vars.
Title: Re: Features Wishlist
Post by: calcdude84se on October 25, 2010, 10:48:31 am
Nice to know :)
However, just in case he'll decide to change where it is ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 05:15:05 pm
Mhmm interesting. Personally for a game I would kinda be relunctant about setting the seed, though, because then people can memorize random number patterns and abuse luck manipulation in games :P
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 07:41:07 pm
Axe uses a random number generation method that uses more than just a seed if i remember correctly, so its impossible to set the seed, since the random number actually has an aspect of randomness to it

On a related note, i just came across something that i think is very broken.  In a program that uses a lot of included files for easier coding, if one of the sub programs has a missing End, it brings you to the very end of the top program instead of into the program that caused the error.  So if i had ProgramA

Code: [Select]
.Axe
prgmSUB

and program SUB

Code: [Select]
..SUB
While 1
Output(0,0,"Ahhhh

and tried to compile, i would get an error block in program A :( This just killed some progress on the Zedd library since i have a bunch of subprograms and i'm getting an error but i literally have no idea where it is, not even the program, so now i have to go searching through 6000 bytes of source code   :'(

EDIT: Woo i'll use sourcecoder! ^^
EDIT2: Awww it doesn't do Axe syntax :(
EDIT3: Ahk part of my source got corrupted D: well at least now i know where the error came from...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 07:49:19 pm
And I've once gotten an ERR:BLOCK that was fixed simply by removing the Else between an If statement and an End, even though the block made perfect sense. I can't seem to recreate the bug, though :P
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 07:50:16 pm
Ooh yeah i got that too, seems that the elseIf still isnt working 100% D:

EDIT: Ok this is weird, i just got my source corrupted again O.O but it cant be the backup feature since its in a subprogram thats getting corrupted, and i even cleared my RAM from just before :(
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 07:52:35 pm
EDIT: Ok this is weird, i just got my source corrupted again O.O but it cant be the backup feature since its in a subprogram thats getting corrupted, and i even cleared my RAM from just before :(

Subprograms don't get backed up? Didn't know that...
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 08:04:17 pm
Nope, another thing that might be good as an option.

Oh also, it would be nice if Axe saved whether or not you like lowercase turned on, currently it just lets you swap between what you currently have and the other option.  If i turn on Lowercase letters, clear RAM, and then go to Axe the option has changed back to uppercase.  I think it would be nice if it just automatically saved your option and applied it when you start Axe.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 08:11:46 pm
Oh also, it would be nice if Axe saved whether or not you like lowercase turned on, currently it just lets you swap between what you currently have and the other option.  If i turn on Lowercase letters, clear RAM, and then go to Axe the option has changed back to uppercase.  I think it would be nice if it just automatically saved your option and applied it when you start Axe.

^ Agreed. Right now we have to go under Options > Alpha every time we RAM clear, which for me would be about 12 times a day.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 08:18:42 pm
Yeah backing up sub-programs would be good. I hope you didn't lose progress Builderboy, btw X.x.
Title: Re: Features Wishlist
Post by: Quigibo on October 25, 2010, 09:26:17 pm
As for the subprograms, they are not actual "sub" programs put part of the original code itself.  Thus you can make block abstractions within your code:

Code: [Select]
.MainProg
prgmFOREACH
.Do Stuff to element
prgmENDEACH

Code: [Select]
..ForEach
.Initialization
For(A,0,N)
.Setup

Code: [Select]
..EndFor
.Clean Up
End
.Destructor

I could check to make sure that the block level count before and after reading a subprogram is the same but then you wouldn't be able to use these abstractions.

Backing up subprograms would be a little awkward to compile.  It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume.  The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram.  But I will see if it is possible to have this as an option.  I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile.

Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe :P)
Title: Re: Features Wishlist
Post by: Runer112 on October 25, 2010, 09:46:21 pm
Ahh, Quigibo! Did you read my epic (http://ourl.ca/4057/131942) on the last page? ;)

Also, a new request for TI Program Editor users like me (although I'm probably the only one lol). When saving 8xp files, if a lowercase letter represents something special (u, v, w are equation variables and a, b, c, d, e, n, p, r, s, t, z are statistics variables), TI Program Editor parses these as these special tokens and not lowercase letters. Due to this, they turn into garbage when parsed inside strings by Axe. Could you make these tokens be parsed as the lowercase letters they actually represent?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 09:55:01 pm
Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe :P)
That might be a better idea. It would save some time when we get errors
Title: Re: Features Wishlist
Post by: jnesselr on October 25, 2010, 11:41:00 pm
I don't know if this has been requested, but 32 bit math would be awesome.
Title: Re: Features Wishlist
Post by: Runer112 on October 25, 2010, 11:47:48 pm
I don't know if this has been requested, but 32 bit math would be awesome.

It would. It would also require Quigibo to completely rewrite every math routine and auto-optimization for a 32-bit mode, as well as needing to create ways to interweave it with the normal 16-bit mode, both on the compiled program side and the parser side. It would be a long and difficult undertaking, and although it would be awesome, I think its sheer difficulty makes it a low priority.

An 8-bit mode has been requested too, and even though that would undoubtedly be a good deal simpler and easier to code, that's still the kind of thing Quigibo doesn't imagine implementing until the far future, like Axe 2.0.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 26, 2010, 02:48:28 am
Yeah if I remember it was gonna remain 1 and 2 bytes for a while. For RPGs you will probably need to have to use lower range of HP/EXP/Gold for now.
Title: Re: Features Wishlist
Post by: Builderboy on October 26, 2010, 02:51:19 am
Also it probably wouldn't be too bad to write a small 32 bit library for Axe, since we have all the multiplication routines we need, it could even be an axiom! :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 26, 2010, 02:59:20 am
True. I recall people tried to do this before but I don't remember if anyone succeeded. In score cases, one thing you can do is add a few artificial zeroes at the end of the number, like 6553500, on the screen. In that case the score would need to increase by 100 everytime, though.
Title: Re: Features Wishlist
Post by: Yeong on October 27, 2010, 04:01:58 pm
I hope that axe supports 4-layer(?) sound like quadplayer.(Or is it possible already and I just don't know how?)
Title: Re: Features Wishlist
Post by: Binder News on October 27, 2010, 08:02:11 pm
Here is a link to my idea. http://ourl.ca/7202/132891 (http://ourl.ca/7202/132891)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 27, 2010, 11:28:51 pm
I hope that axe supports 4-layer(?) sound like quadplayer.(Or is it possible already and I just don't know how?)
I'm not sure if this would be possible, but if it is, I have some doubts games could run fast enough while such complex sound is played.
Title: Re: Features Wishlist
Post by: Binder News on October 28, 2010, 09:29:26 am
If the calc had dual-processors maybe, but it obviously doesn't.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 28, 2010, 06:31:25 pm
Right now, the only way I can see it possible is if the sound plays for an incredibly short period of time every centisecond or something, letting an instruction be executed between every sound. However, that might sound really crappy.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 30, 2010, 06:50:56 pm
well, just don't try it. I'll just only get you disappointed, I think...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 31, 2010, 03:02:02 am
well, just don't try it. I'll just only get you disappointed, I think...
Well if we don't bother trying anything just because it may not work, we would never have seen Axe Parser, TI-Boy SE, Ndless and Geometry Wars for the calculators. This attitude was common in the community back in 2001-07 and nothing was getting done. Even if the end result is a failure, it doesn't hurt to try in the first place.
Title: Re: Features Wishlist
Post by: Quigibo on October 31, 2010, 05:55:17 pm
You actually can have multi-channeled sound right now using the "Port" command to get similar quality to quadplayer.  There is no way you'd be able to have much of a game going on in the background though, but if you're just doing this for the audio itself, it sure is possible, just a little tricky.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 31, 2010, 06:27:34 pm
well, just don't try it. I'll just only get you disappointed, I think...
Well if we don't bother trying anything just because it may not work, we would never have seen Axe Parser, TI-Boy SE, Ndless and Geometry Wars for the calculators. This attitude was common in the community back in 2001-07 and nothing was getting done. Even if the end result is a failure, it doesn't hurt to try in the first place.
yep, that's right. perhaps I've even gotta try it myself ;) I like tricky things, and this case is sounding particularly intresting!
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 06:59:05 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:00:24 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:01:29 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D

That's what we're talking about, though. Sound on calcs with Axe. There already are a lot of programs with sound on calcs, but you just need to find earphones to match.
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:02:11 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D

That's what we're talking about, though. Sound on calcs with Axe. There already are a lot of programs with sound on calcs, but you just need to find earphones to match.

WHAAAAAAAAAAAAAAAAAAAAATTTTTTTTTTTTT THEEEEEEEEEEEEEEEEEEEEEEEEEEEE FFFFFFFFFF*******************************************************************************????????


SOOOOUUUUUNNNNDDDD???????
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 07:02:29 pm
Calculators can't have sound, so guitar hero wouldn't be as cool.
Yes they can?
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:02:54 pm
Calculators can't have sound, so guitar hero wouldn't be as cool.
Yes they can?
OOOOH MYY GOOOD, I WANT HEADPHONES, WHAT TYPE?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:05:12 pm
Yeah, sound's been on calcs for quite a while. You need a 2.5 mm headphone, but you gotta find the right one. I don't know where to find ones that will work, though.
Title: Re: Features Wishlist
Post by: Runer112 on October 31, 2010, 07:30:34 pm
Yeah, sound's been on calcs for quite a while. You need a 2.5 mm headphone, but you gotta find the right one. I don't know where to find ones that will work, though.

The easiest thing to do is use normal headphones with a 2.5mm male to 3.5mm female converter. The converter should only be a few dollars, and you can probably find one at a Radio Shack (that's where I got mine) or a similar store. You can buy one online too.

A warning though: make sure it will actually fit into your calculator! The one I got just barely fits into the link port of my TI-84 Plus SE. If it were any larger I'm sure it would not have fit.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:49:10 pm
Hmm, isn't the iPod headphone 2.5 mm? Does anyone know if that'll work? I need to find it, though...
Title: Re: Features Wishlist
Post by: Happybobjr on October 31, 2010, 08:15:36 pm
if it 2.5 then it will work
Title: Re: Features Wishlist
Post by: calc84maniac on October 31, 2010, 08:17:12 pm
If you want to make sure you get an adapter that fits, you can get a 2.5mm-female to 3.5mm-female and connect it to a TI link cable. That's what I did (more or less)
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:18:50 pm
Mkay, I dug up an old 2.5 mm jack out of the attic, and it worked perfectly - better quality sound then I would have thought!  :)
However, my calculator becomes incredibly sluggish when it's plugged in, but works fine when I play the sample Axe sound program, so I have to run the program, then plug in, then remove the jack after I'm done.  Anybody know why this is?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 08:19:50 pm
The OS is probably checking constantly for link activity.

By the way, could you send me the source for that program? I lost it.

EDIT: Oh, wait, never mind. It's in the Axe .zip :D
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:20:27 pm
Oh.  How do I make it stop?
Title: Re: Features Wishlist
Post by: calc84maniac on October 31, 2010, 08:21:34 pm
You can just unplug it until you start running a program.
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 08:27:42 pm
Well, in theory you could install a hook to disable silent linking completely (or to try to auto-detect whether you have headphones plugged in) but it would still be draining the calculator's batteries.  I'd say just unplug the headphones when you're not using them.
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:31:26 pm
Aw.  Okay, I guess it's really not too much of a hassle.
Does anybody know of a good song or song player thing that I can add so I can show this off at school?
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 08:37:08 pm
Jim e wrote a program called "Real Sound" that packs a sound file into a Flash app.  The app will, of course, be huge for a song of any length, but it does work pretty well.

(I think it's one of those programs that relies on the extra RAM, so it won't work on recently-manufactured 84+es.)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 03:46:03 am
You actually can have multi-channeled sound right now using the "Port" command to get similar quality to quadplayer.  There is no way you'd be able to have much of a game going on in the background though, but if you're just doing this for the audio itself, it sure is possible, just a little tricky.
Hmm thanks for pointing that out. One more thing I need to try when I start experimenting with sound :)
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)
Yeah, the sound quality was really low, but it still demonstrates that sounds in-game is still possible :)

We can sacrify some frames per second for sound, I am sure. I don't think we really need 60 FPS, because it looks blurry on those LCDs, anyway. I think 12-20 FPS is just enough.

Jim e wrote a program called "Real Sound" that packs a sound file into a Flash app.  The app will, of course, be huge for a song of any length, but it does work pretty well.

(I think it's one of those programs that relies on the extra RAM, so it won't work on recently-manufactured 84+es.)
If I remember, one minute of sound is about 1.3 MB on calc. I had a rickroll APP on United-TI before they switched servers. I think such stuff isn't really practical in-game, though. The sound needs to be lower quality, because I don't think many people will want to play a 500 KB tunnel clone just because it plays through a 30 second segment of "Initial D - Feel The Power" until you die in-game or from the music (not that that song is bad, though).
Title: Re: Features Wishlist
Post by: LordConiupiter on November 01, 2010, 04:01:57 am
well, perhaps could Quigibo add some intruments? just like midi on-PC works: not just only the basic peep tone, but also tones of instruments! that would be really very cool! You could use following syntax of the renamed PwrReg command:
Code: (Axe) [Select]
Midi([INSTRUMENT NO],[FREQUENCY])
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 04:03:46 am
That might be hard to get such complex sound files to play with others at once, though. And music with only one instrument playing at once would be a bit simple I think.

Also I just noticed this topic got 100 pages! O.O
Title: Re: Features Wishlist
Post by: JustCause on November 01, 2010, 10:37:30 am
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)
Title: Re: Features Wishlist
Post by: LordConiupiter on November 01, 2010, 11:31:18 am
I would like to be able to use Apps as Libs, like we have ExecLib and OpenLib in BASIC!
(for use with USB8x)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 12:10:23 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)
What does happens with it? Does it just changes Symbolic tokens or does it simply overwrite its hooks? That seems like something Quigibo might want to check, but again, Symbolic is so old that it might be best to not bother, not to mention both apps have no relation to each others (one is math-oriented while the other is programming-oriented).

I would like to be able to use Apps as Libs, like we have ExecLib and OpenLib in BASIC!
(for use with USB8x)
That might be nice, but those games would not run on the TI-83+ and TI-83+SE :(

Also how do we use OpenLib/ExecLib anyway?
Title: Re: Features Wishlist
Post by: JosJuice on November 01, 2010, 12:32:01 pm
Also how do we use OpenLib/ExecLib anyway?
There's some information about it in the USB8x documentation (that program is pretty much the only one that uses these functions...)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 12:38:36 pm
Ah ok. Not even one TI app does? O.o
Title: Re: Features Wishlist
Post by: AngelFish on November 01, 2010, 12:52:36 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)

What exactly do you mean? I haven't noticed anything and I use both Symbolic and Axe quite frequently.

EDIT: I've mentioned this before, but a Not( function would be nice. There are times when you simply have multiple conditions for a conditional and one of them happens to be negated. It'd probably save a byte to have a token implement the function versus typing in "0=" and in any case, the TI-OS token is already there for the taking.

A way to execute the BASIC-interpreter (to allow external subprograms) would be nice too, although that might be a bit unrealistic since the interpreter is probably scattered around the OS.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on November 01, 2010, 02:04:21 pm
I wish that axe could run ASM programs that are already compiled.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 04:28:06 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)

What exactly do you mean? I haven't noticed anything and I use both Symbolic and Axe quite frequently.

EDIT: I've mentioned this before, but a Not( function would be nice. There are times when you simply have multiple conditions for a conditional and one of them happens to be negated. It'd probably save a byte to have a token implement the function versus typing in "0=" and in any case, the TI-OS token is already there for the taking.

A way to execute the BASIC-interpreter (to allow external subprograms) would be nice too, although that might be a bit unrealistic since the interpreter is probably scattered around the OS.
Strange, maybe it's an OS/calc-specific issue?
Title: Re: Features Wishlist
Post by: ztrumpet on November 01, 2010, 04:37:10 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.
http://ourl.ca/3610

Does anybody know of a good song or song player thing that I can add so I can show this off at school?
http://ourl.ca/6456
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 06:10:53 pm
There's also Mobiletunes over Cemetech, but I think you need to convert the songs to z80 then compile them to ASM files, so the process is a bit more complicated.
Title: Re: Features Wishlist
Post by: FloppusMaximus on November 01, 2010, 10:32:50 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.
http://ourl.ca/3610
Yeah, that's the one I was thinking of.  The UTI thread is now at http://www.unitedti.org/forum/index.php?showtopic=8917 .
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 10:38:05 pm
Ah right, 8 KHz quality. On my headphones, there was a big acute hiss. I wonder if that can be removed from such calc sound? I know the old Playwav from TCPA team and RealSound from Revsoft did that too
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 07:55:43 pm
A couple of feature requests:


Also, automatically converting While 1 and Repeat 0 into endless loops would be nice, if that's not added already.
Title: Re: Features Wishlist
Post by: squidgetx on November 04, 2010, 07:56:40 pm
A couple of feature requests:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

YES

Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 08:02:16 pm
Oh, and

Title: Re: Features Wishlist
Post by: calc84maniac on November 04, 2010, 08:07:24 pm
Oh, and

  • Allowing jumping to an arbitrary place in memory
That can be done using a simple Asm(E9), which will jump to the address of the last result
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 08:13:33 pm
Wow, I didn't think of that. Thanks!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2010, 11:21:35 pm
I like the For( idea.

Could you explain examples of usage of jumping to an arbitrary place into memory? I'm not too sure what it does exactly...
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 11:50:24 pm
I like the For( idea.

Could you explain examples of usage of jumping to an arbitrary place into memory? I'm not too sure what it does exactly...

Well, I'm working on a game where each level adds some new feature, and to save space, I'd like to store all the code for those features in the form of data, move it to L2 before the level starts, and just run the code from there. That way, it doesn't check for the level in a huge If -ElseIf -End statement each pass.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2010, 11:53:02 pm
Ah sounds cool, thanks for the info :)

By the way I'll create the sub-forum for it now so you can post :)
Title: Re: Features Wishlist
Post by: calc84maniac on November 04, 2010, 11:53:57 pm
This is why we need a switch statement.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 05, 2010, 10:40:51 am
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?

Ah sounds cool, thanks for the info :)

By the way I'll create the sub-forum for it now so you can post :)

The feature request was actually for a different (much smaller) game I'm working on. But thanks for the subforum :D
Title: Re: Features Wishlist
Post by: calc84maniac on November 05, 2010, 01:13:02 pm
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?
Nope, switch statement is supposed to do exactly what you were saying, jump to one of a bunch of routines using a table of addresses. It should take the same amount of time for any of the different cases. My plan to make it simpler for Axe to handle was to only allow switching of values 0,1,2,3,...,N, and a default case if the value is greater than N. So what if you wanted to switch and check for A=3,4,5,6? Well, just switch(A-3) and use cases of 0,1,2,3. I don't know if Quigibo will decide to do it this way, though.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 07, 2010, 12:28:55 pm
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?
Nope, switch statement is supposed to do exactly what you were saying, jump to one of a bunch of routines using a table of addresses. It should take the same amount of time for any of the different cases. My plan to make it simpler for Axe to handle was to only allow switching of values 0,1,2,3,...,N, and a default case if the value is greater than N. So what if you wanted to switch and check for A=3,4,5,6? Well, just switch(A-3) and use cases of 0,1,2,3. I don't know if Quigibo will decide to do it this way, though.

Oh, sounds like a good idea, then.

A couple of feature requests:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

YES



Or an alternative: allowing programs to define where the vars point.
Title: Re: Features Wishlist
Post by: calcdude84se on November 10, 2010, 05:06:45 pm
Or an alternative: allowing programs to define where the vars point.
Hm. I could see this being useful, but I'm not sure how you would define it, and I'm not sure how well the compiler could handle it...
Also, perhaps For( could just be redefined to take an address instead of a variable? (Use For( °A,S,E) instead of For(A,S,E). This would also make for a more consistent For(L1,S,E) instead of having to use {})
Edit: And you'd have to maintain backwards compatibility, as I just realized.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 10, 2010, 07:43:06 pm
I think something like E89F0→°A would be great. It should be a quick addition to Axe, and Quigibo could still keep the current values as default values and maintain backwards compatibility :)

And as for using addresses in For( loops, I don't think that's a good idea. It's not backwards compatible, as you mentioned, and it'll confuse TI-BASIC programmers who are used to having a var in For(.
Title: Re: Features Wishlist
Post by: nemo on November 10, 2010, 07:47:06 pm
I think something like E89F0→°A would be great. It should be a quick addition to Axe, and Quigibo could still keep the current values as default values and maintain backwards compatibility :)

And as for using addresses in For( loops, I don't think that's a good idea. It's not backwards compatible, as you mentioned, and it'll confuse TI-BASIC programmers who are used to having a var in For(.

For(ADDRESS,start,end)r

problems solved? that is, if quigibo feels like implementing it
Title: Re: Features Wishlist
Post by: Deep Toaster on November 10, 2010, 08:01:23 pm
I'd rather see that as a For( loop that counts backwards, kinda like how Copy( and Fill( work. Besides, it's only one less keystroke than For({ADDRESS},START,END) ;)

Whatever Quigibo decides, though. It's his language :)
Title: Re: Features Wishlist
Post by: Runer112 on November 11, 2010, 12:03:52 am
EDIT: Whoops. Ignore this lol.
Title: Re: Features Wishlist
Post by: Darl181 on November 11, 2010, 12:09:31 am
I've mentioned lines to back-buffer already, I'm pretty sure, but I just ran into a problem with a possible menu.
So, I was thinking...whatever you can do with a sprite (on, off, change) you could do with a line, to both buffers.
Something like this would help with filling a large, outline block-style font with grayscale and changing it back again (i.e. the flash TWHG's menu, grayscale-ified for the calc)

EDIT: it looks kind of like the poll's decided :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 11, 2010, 04:01:18 pm
Would it be possible/easy to change all the commands that can't be used in axe to "..." or something similar?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:03:33 pm
That would be very, very impractical, unfortunately. The token hook that allows Axe to replace the TI-OS tokens with Axe tokens literally checks to see if the token is in a table, then replaces it with the matching Axe token. If we were to change the 200 or so unused tokens to anything else, imagine how slow editing would be :P
Title: Re: Features Wishlist
Post by: Builderboy on November 11, 2010, 04:04:21 pm
Possible i imagine, although also it would probably take up an extremely large amount of space and/or make editing very slow D: but i don't pretend to be an expert in these token hooks so don't ask me ;D

EDIT: Ninja :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 11, 2010, 04:11:08 pm
:(

oh well, it was worth asking.
Title: Re: Features Wishlist
Post by: calc84maniac on November 11, 2010, 04:12:54 pm
Actually, if they were all changed to the same string "...", it wouldn't take much more effort. Instead of just returning if an Axe token is not found, pass that string instead.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:14:14 pm
Actually, if they were all changed to the same string "...", it wouldn't take much more effort. Instead of just returning if an Axe token is not found, pass that string instead.

Whoops :-[

Sounds like a good idea, then ;D Unless it gets too slow.
Title: Re: Features Wishlist
Post by: Builderboy on November 11, 2010, 04:14:26 pm
Would that work within a reasonable speed?
Title: Re: Features Wishlist
Post by: Munchor on November 11, 2010, 04:16:22 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:20:17 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*

What do you mean? Replacing Str1 with a new value? You can do that by

Code: (Axe) [Select]
:"Up"→Str1 .Original value
:[0000] .Two extra zeroes for padding because "Down" is two bytes longer
:"Down"→Str2 .Temporary pointer
:Copy(Str2,Str1,4)

The problem with doing it directly with "Down"→Str1 is that since Str1 is just a piece of memory in the program, you'd overwrite whatever came after it if you replace it with a longer string.
Title: Re: Features Wishlist
Post by: Munchor on November 11, 2010, 04:31:52 pm
So, I can do that with Pictures too?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:35:19 pm
Yeah, Str's, Pic's, and GDB's aren't really vars. They're just pointers to data inside the program, so they're completely interchangeable.

Except when you're accessing the actual variables with GetCalc(, but that's completely different.

EDIT: A feature request: Goto LBLIf CONDITION/Goto LBL!If CONDITION syntax.
Title: Re: Features Wishlist
Post by: calcdude84se on November 12, 2010, 09:38:52 pm
I second the request for "Goto LBLIf CONDITION" and Goto LBL!If CONDITION"
Makes things much more compact, and something tells me the assembly code might be more efficient.
Code: (Before) [Select]
;Using If CONDITION:Goto LBL:End
;Check for condition puts results in, say, z
jr nz,condition_false
jp label
condition_false:
;label is elsewhere
Code: (After) [Select]
;Using Goto LBLIf CONDITION
;Check for condition puts results in, say, z
jp z,label
;label is elsewhere
A vast oversimplification, probably, but I'm thinking it could make things more efficient. :)
Title: Re: Features Wishlist
Post by: Munchor on November 14, 2010, 03:45:36 pm
I'd like a few updates, however, not in the language itself:

In the Application:

You have four options, Compile, Options,Help and Quit.

*Maybe make that when you press up in Compile it goes to quit and the opposite.
*Make the same thing happen with the Compile list.
*Make the Help button give something lol.
*Make that AFTER YOU COMPILE, it goes back to the compile list, because sometimes I wanna compile +1 program, especially when I do RAM delete.


These should not be hard to make and I expect them in next version, so.

The first one is not really needed, it's just that it looks well.

Thanks!
Title: Re: Features Wishlist
Post by: Runer112 on November 14, 2010, 03:59:25 pm
These should not be hard to make and I expect them in next version, so.

Quigibo has been very busy with things in life besides Axe, and has just been trying to get out the next version of Axe as it is, without adding everybody's feature requests. There have been many feature requests, and there's no reasonable way he could get to all of them, especially with how busy he has been lately. I've made a few feature requests myself. For one of them I even gave him the exactly assembly code he would need for it. And I still don't expect that Quigibo has to include it in the next version, or any version for that matter. He will add features as he deems that they should be added, and when he has the time to add them. It's not any one of our calls but his to say that the features we want should be in the next version. Announcing that you expect features to be in the next version puts Quigibo in the unfair position of feeling that he needs to include these features in the next version or he will disappoint you.
Title: Re: Features Wishlist
Post by: Munchor on November 14, 2010, 04:27:53 pm
These should not be hard to make and I expect them in next version, so.

Quigibo has been very busy with things in life besides Axe, and has just been trying to get out the next version of Axe as it is, without adding everybody's feature requests. There have been many feature requests, and there's no reasonable way he could get to all of them, especially with how busy he has been lately. I've made a few feature requests myself. For one of them I even gave him the exactly assembly code he would need for it. And I still don't expect that Quigibo has to include it in the next version, or any version for that matter. He will add features as he deems that they should be added, and when he has the time to add them. It's not any one of our calls but his to say that the features we want should be in the next version. Announcing that you expect features to be in the next version puts Quigibo in the unfair position of feeling that he needs to include these features in the next version or he will disappoint you.

I know of course, it may look like an order now that I read it, sorry.

What I mean is that those are really easy to make since thei're not the language itself, just that.

The other day he said he had college tests a lot and the version 0.5 would take a long time to come, but I'm not worried, I totally understand him :D
Title: Re: Features Wishlist
Post by: squidgetx on November 14, 2010, 08:44:09 pm
Personally I like how it instant exits after compiling; saves a lot of time for debugging. More people will be compiling one program at a time than those who want to compile more than 1 program at once :P
Title: Re: Features Wishlist
Post by: Darl181 on November 14, 2010, 09:35:28 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*
"ERR:DUPLICATE"
And help doing something would help be useful...;D
Also, this was already mentioned I believe, but I second whoever asked for the size of the program* to be displayed on the "Compiling..." screen.
*like it does for apps, maybe?

"help working would help"...wow/me facepalms
Title: Re: Features Wishlist
Post by: calcdude84se on November 14, 2010, 09:49:11 pm
Ztrumpet mentioned something like this:
Code: [Select]
"Up"->Str1
"Down"->Str2
If CONDITION
Str1->A
Else
Str2->A
End
So A is your variable pointer :)
Title: Re: Features Wishlist
Post by: calc84maniac on November 14, 2010, 09:52:09 pm
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)
Title: Re: Features Wishlist
Post by: calcdude84se on November 14, 2010, 10:02:48 pm
Ah, right, forgot about inlining of data definitions x.x
Essentially the same thing, though.
Title: Re: Features Wishlist
Post by: calc84maniac on November 14, 2010, 10:05:14 pm
If you are going to use a string more than once, it is a good idea to give it a name, though. If you inline the string each time, the data will be added again and again. (Well, unless Quigibo made it check for duplicates, but I think that would be a waste of processing time)
Title: Re: Features Wishlist
Post by: lookitsan00b on November 14, 2010, 10:21:07 pm
If you are going to use a string more than once, it is a good idea to give it a name, though. If you inline the string each time, the data will be added again and again. (Well, unless Quigibo made it check for duplicates, but I think that would be a waste of processing time)

actually, it probably compiles to something like:

Code: [Select]
;getkey stuff here
 cp 4
 jq nz,lb1
 ld de,P_Address
 ld hl,str1
 ld (de), hl
lb1:
...
data_section:
str1:
 db "Up", 0
Title: Re: Features Wishlist
Post by: Runer112 on November 14, 2010, 10:33:16 pm
This is what disassembly is for :P

Code: [Select]
;getKey stuff here
ld hl,($8700) ;$8700 = K
ld a,l ;K=4 check
sub 4
or h
ld hl,$01
jr z,$+3
dec l
ld a,h ;Standard If statement code
or l
jp z,EndIf
ld hl,string ;If statement contents
ld ($870A),hl ;$870A = P
EndIf:
;Other stuff


string:
.db "Up", 0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 15, 2010, 02:49:38 am
I would like the option to return on the compile list after compiling a program or the menu. It would be best if we could also choose to exit, though. Some people may be working on multiple programs at once, but a lot of people will most likely only compile one program at a time. That said, it is not really a hurry, though.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 15, 2010, 02:25:08 pm
Quote from: calc84maniac
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)

Thanks, didn't know that. I don't understand how the parentheses work, though...
Title: Re: Features Wishlist
Post by: Builderboy on November 15, 2010, 02:28:15 pm
Wait calc84 is that an explanation or a request?
Title: Re: Features Wishlist
Post by: ztrumpet on November 15, 2010, 03:37:42 pm
Explanation ;)
Title: Re: Features Wishlist
Post by: Builderboy on November 15, 2010, 04:22:43 pm
Ah i understand it now, thats really useful!
Title: Re: Features Wishlist
Post by: calc84maniac on November 15, 2010, 05:22:13 pm
Quote from: calc84maniac
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)

Thanks, didn't know that. I don't understand how the parentheses work, though...

Well, try "Up"->P. Axe will give an error, because when a line starts with a double quote Axe is expecting it to be stored to a static pointer (like Str1A), or else just inserted at the end. Starting with parentheses tells Axe that you are actually evaluating an expression here, and thanks to the inline data support Quigibo added recently, a pointer is returned to the inserted string.
Title: Re: Features Wishlist
Post by: Quigibo on November 16, 2010, 05:40:25 pm
Actually, storing to a variable might be valid syntax in the next version, that is "Hello"->P will be parsed the same as ("Hello")->P
Title: Re: Features Wishlist
Post by: Deep Toaster on November 16, 2010, 07:09:06 pm
Actually, storing to a variable might be valid syntax in the next version, that is "Hello"->P will be parsed the same as ("Hello")->P

Would that be necessary, though? It might make people think P is the string, and "Hello"→Str1:Str1→P doesn't add any extra code...

EDIT: Actually, wait, never mind. It's a great idea!
Title: Re: Features Wishlist
Post by: Darl181 on November 17, 2010, 08:02:02 pm
Something like this would be great. (http://ourl.ca/4129/80700)
Title: Re: Features Wishlist
Post by: calc84maniac on November 17, 2010, 09:10:06 pm
Something like this would be great. (http://ourl.ca/4129/80700)
You can already compile for MirageOS. Check out the Options menu :)
Title: Re: Features Wishlist
Post by: FinaleTI on November 17, 2010, 09:14:05 pm
I think he meant built-in icon support, like you can define a description.
It's been requested before, I believe.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 18, 2010, 07:39:30 pm
I think he meant built-in icon support, like you can define a description.
It's been requested before, I believe.

That's a good idea, but I think it should not be added to Axe. Matching icons to each program would be too complicated.
Title: Re: Features Wishlist
Post by: squidgetx on November 18, 2010, 08:25:18 pm
Matching icons to each program would be too complicated.

??? In what way; I don't quite get what you mean. I think he's just looking for a way to just define the 16x16 icon in the header or something in a similar way that Sir's program gives you hex to paste into the first line of the program, but instead of using Sir's program, the new feature would allow you to do
Code: (for example) [Select]
.Program [hex for icon image] or something similar
Title: Re: Features Wishlist
Post by: Deep Toaster on November 18, 2010, 08:26:55 pm
Matching icons to each program would be too complicated.

??? In what way; I don't quite get what you mean. I think he's just looking for a way to just define the 16x16 icon in the header or something in a similar way that Sir's program gives you hex to paste into the first line of the program, but instead of using Sir's program, it would just be
Code: (for example) [Select]
.Program [hex for icon image] or something similar

Oh, like that. That sounds like a good idea. I was thinking that the icon wouldn't actually be in the program, which would make things complicated.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 18, 2010, 09:27:28 pm
Quote
[19:19:29] <nemo> anyone know how to add a DCS description in an Axe program?

Is that possible in Axe? If not, maybe as new feature in one of the upcoming versions?
Title: Re: Features Wishlist
Post by: nemo on November 18, 2010, 09:28:44 pm
Quote
[19:19:29] <nemo> anyone know how to add a DCS description in an Axe program?

Is that possible in Axe? If not, maybe as new feature in one of the upcoming versions?

and an Icon. of course it can probably be done by combining a little inline ASM as instructed here (http://dcs.cemetech.net/index.php?title=ASM_Header).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 18, 2010, 09:35:21 pm
Yeah true. It would be cool if it was implemented in Axe, though.

At first, I think it was not added because I suggested Quigibo to do some publicity for Axe by having the default icon, to attract more programmers, but I don't think this is needed as much anymore now that most Axe users put his credits in the readme.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 19, 2010, 08:46:02 pm
Not sure about this one, but as a feature request, could sin( and cos( be changed so that they output numbers in the fixed-point format that's used by **? It would be a bit easier to work with.

Also, instead of this:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

I have a different suggestion. How about POINTER→°VAR to set our own variables? It would be easier to work with than the one I posted earlier.
Title: Re: Features Wishlist
Post by: ztrumpet on November 20, 2010, 11:05:26 am
I would like a feature that changes the value of the org at that point.  This would be to get around the 8k code limit. :)
Title: Re: Features Wishlist
Post by: Munchor on November 20, 2010, 11:08:45 am
We can't use Pi symbol in Axe, can we?

If so, it would be cool if we could, because of a probable Formulum Axe Version and other programs too of course!
Title: Re: Features Wishlist
Post by: Deep Toaster on November 20, 2010, 11:16:06 am
Nope, no pi. I think Quigibo was thinking of adding it for a different purpose, though (quickly saving as temporary mem).
Title: Re: Features Wishlist
Post by: Munchor on November 20, 2010, 11:17:10 am
Nope, no pi. I think Quigibo was thinking of adding it for a different purpose, though (quickly saving as temporary mem).

We can also define pi like:
Code: [Select]
3.14159265358979323846264338327950288419716939937510->P
Title: Re: Features Wishlist
Post by: Deep Toaster on November 20, 2010, 11:17:59 am
Remember, no decimals in Axe. Periods signify comments, so all Axe sees in that line is the number 3.
Title: Re: Features Wishlist
Post by: Michael_Lee on November 22, 2010, 05:33:28 pm
You could just take your number, inflate it by multiplying it by 128 or something, then divide by 100, multiply by 314, then finally de-inflate by dividing by 128.
N*128*314/199/128->N
Title: Re: Features Wishlist
Post by: Deep Toaster on November 22, 2010, 06:38:12 pm
You could just take your number, inflate it by multiplying it by 128 or something, then divide by 100, multiply by 314, then finally de-inflate by dividing by 128.
N*128*314/199/128->N


For more accuracy, though, you might want to just keep N inflated (by 128 or 256). Then anything you add to or subtract form N would need to be inflated that same amount, and when you actually use N, just deflate it by N/128 or N/256.

And apparently I haven't actually posted this yet, so a feature request: Changing sin( and cos( so that they have a range of -256 to 256 instead of -128 to 128 so that they match the fixed point numbers used by **.
Title: Re: Features Wishlist
Post by: Runer112 on November 22, 2010, 10:42:36 pm
The current sine and cosine routines produce 1-byte outputs, which is why the range is from -127 to 127. It uses a basic approximation that already isn't completely accurate for the output range of -127 to 127, so expanding the output range would just inflate the inaccuracies as well. If you want to inflate the output values, it's probably not that difficult to do with Axe anyways. And if he were to modify the routine to be more accurate and produce 2-byte outputs, it would require a better approximation method and would surely be a much heftier and slower routine.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 23, 2010, 09:39:55 am
The current sine and cosine routines produce 1-byte outputs, which is why the range is from -127 to 127. It uses a basic approximation that already isn't completely accurate for the output range of -127 to 127, so expanding the output range would just inflate the inaccuracies as well. If you want to inflate the output values, it's probably not that difficult to do with Axe anyways. And if he were to modify the routine to be more accurate and produce 2-byte outputs, it would require a better approximation method and would surely be a much heftier and slower routine.

Oh, okay. It's fine the way it is, anyway (just multiply by two for fixed-point math).
Title: Re: Features Wishlist
Post by: Runer112 on November 23, 2010, 10:04:17 am
Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:
Code: (31 bytes) [Select]
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B

When the signed division auto-optimizations are fixed, a better way will be this:
Code: (15 bytes) [Select]
sin(A)*256//256
EDIT: Disregard all of that, the number comes out as fixed point after all.
Title: Re: Features Wishlist
Post by: calc84maniac on November 23, 2010, 10:11:25 am
Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:
Code: (31 bytes) [Select]
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B

When the signed division auto-optimizations are fixed, a better way will be this:
Code: (15 bytes) [Select]
sin(A)*256//256
Um, even though the outputs are in the range -127 to 127, they are still sign extended to 16-bits. All you have to do is multiply by 2 to get the range of about -256 to 256 which is -1 to 1 in 8.8 fixed point.
Title: Re: Features Wishlist
Post by: Runer112 on November 23, 2010, 10:58:57 am
Oh, nevermind then. I just glanced at the routine and didn't see any 16-bit register operations so assumed it was all 8-bit. But now I see the dec h.
Title: Re: Features Wishlist
Post by: Quigibo on November 23, 2010, 03:04:40 pm
The reason Sin and Cos are -128 to 127 instead of -256 to 255 is because that way, you can fit the result in a single byte.  Also its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2010, 03:13:56 pm
its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.

Curious i would think, it takes more memory to go one way than the other way?  I guess some operations don't have an equivalent inverse in asm?
Title: Re: Features Wishlist
Post by: calc84maniac on November 23, 2010, 03:17:23 pm
its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.

Curious i would think, it takes more memory to go one way than the other way?  I guess some operations don't have an equivalent inverse in asm?

Yep, it's add hl,hl vs. sra h \ rr l. If the add hl,hl instruction didn't exist, it would take 4 bytes to multiply by two as well, by using sla l \ rl h.
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2010, 03:19:21 pm
Ah i see, its a small optimization that allows you to double HL :) Gotcha, that makes sense ^^
Title: Re: Features Wishlist
Post by: Michael_Lee on November 25, 2010, 12:11:50 pm
Request:
Command to interact directly with bits, sort of like the nib{ command.
Also, I'm pretty sure this has been requested before, but a way to draw lines and write text to the backbuffer.  Please?
Title: Re: Features Wishlist
Post by: Yeong on November 25, 2010, 12:20:10 pm
Request:
Also, I'm pretty sure this has been requested before, but a way to draw lines and write text to the backbuffer.  Please?
Don't you add r to write at the back buffer?
ex) Line(a,b,c,d)r

My request
including compiled prgm/BASIC prgm in Axe source code
Title: Re: Features Wishlist
Post by: nemo on November 25, 2010, 12:23:33 pm
yeong, no, drawing lines to the backbuffer isn't supported. also, i *think* Asm(prgmCOMPILED) should work. not sure. but implementing BASIC would be far more difficult.

two relatively simple requests: BCalls InsertMem, DelMem, where the variable's size field is automatically updated and it checks to see if there's enough RAM.
Ex.
InsertMem([POSITION],[SIZE]) returns 0 if not enough RAM or 1 if successfully added.
same with DelMem.
Title: Re: Features Wishlist
Post by: Yeong on November 25, 2010, 12:24:41 pm
I thought the Asm( is for raw hex assembly codes only.
Title: Re: Features Wishlist
Post by: nemo on November 25, 2010, 12:26:43 pm
ASM programs are, essentially, hex. though i just realized it won't work because it'll try to read the prgmCOMPILED as source code.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 25, 2010, 09:23:43 pm
If Asm(prgmNAME) is supported, could there be risks of conflicts?
Title: Re: Features Wishlist
Post by: calcdude84se on November 25, 2010, 09:29:32 pm
This is only in Axe source ;)
However, including compiled code is just a bad idea (pre-compiled code won't run correctly), and to include source, we already have prgmPROGRAM.
As for including BASIC programs, I'm curious why you'd need that. Could you elaborate?
Note: This post to me seems it might be bordering on offensive. I do not mean it as such.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 26, 2010, 12:47:56 am
Ah, right. I wasn't sure. As for BASIC the issue is that when executed, it could mess thing up in your program when it goes back to ASM/Axe commands, since TI-BASIC messes with TI-OS data a lot. You may not even be able to use the back buffer and buffer when certain BASIC commands are used.
Title: Re: Features Wishlist
Post by: squidgetx on November 26, 2010, 05:13:06 pm
Ok, I have a feature 'wish':

When the parser runs into certain errors, mainly the Missing Label, Undefined, and Duplicate errors, could there be an option to 'skip' that line of code when compiling? As in, if this option was chosen, the line containing the offending error would be ignored completely by the parser (as if it were prefixed by a period) Error messages would then have a menu accompanying them (sort of like BASIC) with Quit, Goto, and Skip (if applicable)

This sounds kind of hard though, and so it's ok if it's not really realistically possible, but thanks anyway :P
Title: Re: Features Wishlist
Post by: calc84maniac on November 26, 2010, 05:17:44 pm
But ignoring errors would cause a bad program to be produced. I don't think we would want that.
Title: Re: Features Wishlist
Post by: squidgetx on November 26, 2010, 05:53:57 pm
Well, I think that in many situations, the user doesn't care immediately whether a certain piece of data will be included or not. Maybe they were typing quickly while making, for example, a menu, and defined Str1 twice :P But they really just want to test whether the code works and won't care if Str1 is defined incorrectly, and so this might make some debugging a little faster (maybe)

I hope I explained it well enough x.x

Also, I have another request/question: When you use InData(), the data is zero-terminated, but it seems that the 0 is included in the data to be searched: For example, if A=0, and you ran InData(A,Data(1,2,3,0)), it would return 4...Is it supposed to be like this? I think it might be better if the 0 was not included in the data to be searched...
Title: Re: Features Wishlist
Post by: jnesselr on November 26, 2010, 05:58:32 pm
I can understand try and catch, but if they have some syntax error (maybe they have Str1 where it should be Str2) they need to know of it immediately.
Title: Re: Features Wishlist
Post by: Quigibo on November 26, 2010, 06:57:18 pm
Also, I have another request/question: When you use InData(), the data is zero-terminated, but it seems that the 0 is included in the data to be searched: For example, if A=0, and you ran InData(A,Data(1,2,3,0)), it would return 4...Is it supposed to be like this? I think it might be better if the 0 was not included in the data to be searched...

Exactly.  You generally don't want to search for the zero case.  Usually what you do is handle that separately and then when you're sure the byte is non-zero, then use the inData() search.  Although you can search for it if you don't mind it being part of your data since I don't treat zero as a special case.  The reason it's setup this way is because I'm trying to use the smallest code with the fastest speed, and this was most efficient.
Title: Re: Features Wishlist
Post by: tehalynn on November 29, 2010, 12:50:21 am
I have a couple suggestions I think would save a little time when compiling.

1. On the compile screen, sort programs by most recently compiled. The most recently compiled program is at the top.
2. Have a way to automatically run programs after they're compiled. This could be an option, or just a different key to press (instead of enter). I guess this would only work if you're compiling for no shell though.

If both of these suggestions are made, then it should only take 2 keystrokes within Axe to compile and run whichever program you compiled last.

An alternate (or additional) idea is to have a button that compiles and runs the most recently compiled program from the main screen. That would only take 1 keystroke within Axe.
Title: Re: Features Wishlist
Post by: Munchor on November 29, 2010, 08:47:36 am
I have a couple suggestions I think would save a little time when compiling.

1. On the compile screen, sort programs by most recently compiled. The most recently compiled program is at the top.
2. Have a way to automatically run programs after they're compiled. This could be an option, or just a different key to press (instead of enter). I guess this would only work if you're compiling for no shell though.

If both of these suggestions are made, then it should only take 2 keystrokes within Axe to compile and run whichever program you compiled last.

An alternate (or additional) idea is to have a button that compiles and runs the most recently compiled program from the main screen. That would only take 1 keystroke within Axe.

I like those ideas, it'd be very fast to code/compile/test repeatedly.

Also, I don't know if this would ever be possible, but Axe inside Doors? For example, I program in Doors sometimes and I have to change Application to compile :( This is a very weird thing, but maybe you could find a way of getting throught it, Quigibo.

Nevertheless, it's good to see you're hearing to our prays in this long, long topic
Title: Re: Features Wishlist
Post by: Quigibo on November 29, 2010, 04:31:27 pm
I will probably do that; have a pointer in the app that points to a special parsing routine so that external programs like DCS can automatically know where to jump into the app to "externally" use Axe without having to quit the original application.  This is something that Kerm would have to add to DCS, and I'm sure he would if you request it, but I haven't added that functionality to Axe Parser yet.  However, its definitely planned.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 29, 2010, 07:05:11 pm
I will probably do that; have a pointer in the app that points to a special parsing routine so that external programs like DCS can automatically know where to jump into the app to "externally" use Axe without having to quit the original application.  This is something that Kerm would have to add to DCS, and I'm sure he would if you request it, but I haven't added that functionality to Axe Parser yet.  However, its definitely planned.

Would it work with ASM programs? Can't wait for that :D
Title: Re: Features Wishlist
Post by: Yeong on November 29, 2010, 08:31:46 pm
Feature request:being able to sign app more than 16384 bytes.
Title: Re: Features Wishlist
Post by: calcdude84se on November 29, 2010, 08:35:22 pm
I think multi-page apps have been on the list for a while :D
They're rather difficult, so it might be a while before we have them.
Edit: We should probably get a new poll soon :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 29, 2010, 09:00:22 pm
What makes multi-page apps so hard?
Title: Re: Features Wishlist
Post by: calcdude84se on November 29, 2010, 09:02:58 pm
Its not that I'm too busy (although that might be part of it).  Its mainly because the app compiling is VERY dangerous.  The only reason I understand how the code works now is mainly from BrandonW's help.  There are a lot of very tricky bcalls and formalities that TI uses when jumping around the flash pages.  Its already hard enough to allocate a single page for apps, but allocating 2 pages is really tricky because it sometimes involves swapping sectors if I remember correctly.  The point is, I could do it, but I would need a lot of help to make sure there are no rom corrupting bugs (which are really nasty).  Even if I did get it to work, it would still be data-only for the second page unless I create some kind of new syntax for off-page calls.

I do plan to make more of the code open source after the next few releases including the application compiling, error scrolling, and other potentially useful sections.  Tomorrow I will have a new update, I rewrote all of the archive reading code which took me about 4 days.  I'm not sure if there will be any new commands, but I fixed a lot of bugs, safety, optimizations, and looser syntax.
Title: Re: Features Wishlist
Post by: Happybobjr on November 29, 2010, 10:02:51 pm
...?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 29, 2010, 10:03:49 pm
...?

calcdude just posted a quote from Quigibo that answers your question ;)
Title: Re: Features Wishlist
Post by: calcdude84se on November 30, 2010, 06:16:22 pm
Here's the short version: it's dangerous and involves lots of complicated stuff ;D
Title: Re: Features Wishlist
Post by: Happybobjr on November 30, 2010, 07:00:30 pm
I had trouble understanding as i tend to read the users text before the quote. Thus my mind skipped over it...
Title: Re: Features Wishlist
Post by: tehalynn on December 01, 2010, 05:42:50 pm
Has anyone asked for automatic backup of program dependencies?

If I import prgmB into prgmA, then compiling prgmA would backup both prgmA and prgmB.
Title: Re: Features Wishlist
Post by: Deep Toaster on December 01, 2010, 06:22:53 pm
Has anyone asked for automatic backup of program dependencies?

If I import prgmB into prgmA, then compiling prgmA would backup both prgmA and prgmB.

^ Yep, I have, but IIRC Quigibo said that might get messy.

EDIT: Here:

Backing up subprograms would be a little awkward to compile.  It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume.  The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram.  But I will see if it is possible to have this as an option.  I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile.

Actually, since Axe now makes backups after the program is compiled, would this be possible?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 02, 2010, 12:23:24 am
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.
Title: Re: Features Wishlist
Post by: nemo on December 02, 2010, 04:23:00 pm
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
Title: Re: Features Wishlist
Post by: ztrumpet on December 02, 2010, 05:14:16 pm
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
I think this is a really good idea. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 03, 2010, 12:48:30 am
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
I think this is a really good idea. :)
Indeed. Just make sure it is not enabled by default, though, since someone may accidentally back them up and it would take ridiculous amount of times (especially if garbage collection is needed)
Title: Re: Features Wishlist
Post by: Quigibo on December 03, 2010, 01:16:58 am
But the problem is that I would need to keep a list of every program to backup while it compiles and I'm already just about out of memory without sipping into the extra pages.  It would either have to be done in the middle of compiling or there would have to be a limit to how many sub programs could be backed up during a "full backup".  I'm pretty sure I'm using the swap saferam area for parsing storage so the second option is more likely if I did decide to implement this.
Title: Re: Features Wishlist
Post by: Munchor on December 04, 2010, 05:04:22 pm
Ok, I have a doubt:

Is Application-making something you want to make in Axe? In 1.0.0, do you think that could be included?
Title: Re: Features Wishlist
Post by: Runer112 on December 04, 2010, 05:19:33 pm
You can already compile Axe programs as applications by selecting "Application" as the shell from the options menu.
Title: Re: Features Wishlist
Post by: Munchor on December 04, 2010, 05:26:49 pm
You can already compile Axe programs as applications by selecting "Application" as the shell from the options menu.

You gotta be kidding. I just found out... Oh my god! No way, this is EPIC!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 04, 2010, 09:27:19 pm
Note that on certain calcs, it may fail, though. It is very rare, but on my 83+ it doesn't work, even if it works fine on everyone else's calc. Someone else had this problem with his 84+, too. Also writing to Flash is dangerous, so always backup both your ARCHIVE and RAM on a flash drive before compiling apps when you have major updates.

Also you need to sign the app on the computer afterward.
Title: Re: Features Wishlist
Post by: AngelFish on December 05, 2010, 06:46:54 pm
I know this has been asked before, but can the variables A-Z and theta be relocated to another place in RAM so that L1 can be used as a buffer storage area?
Title: Re: Features Wishlist
Post by: Runer112 on December 05, 2010, 10:37:30 pm
Here's a sort of odd request: reverse modulus. Instead of returning the remainder of a division, it would return the original number minus the remainder. Perhaps it could use ^^ as its operator? For instance, 16^^7 would return 14 and 9001^^3 would return 9000. I've been trying to wrap my head around how to get a reverse modulus routine to work, but complex math routines aren't my specialty. But I figure the least I could do if you want to implement this feature is save you a few minutes and write the reverse modulus auto-optimizations (really just adjustments to the normal modulus auto-optimizations), which are what I would want the most anyways. I could actually do without a reverse modulus routine.

Code: [Select]
p_RMod2:
.db 2
res 0,l
p_RMod4:
.db 4
ld a,%11111100
and l
ld l,a
p_RMod8:
.db 4
ld a,%11111000
and l
ld l,a
p_RMod16:
.db 4
ld a,%11110000
and l
ld l,a
p_RMod32:
.db 4
ld a,%11100000
and l
ld l,a
p_RMod64:
.db 4
ld a,%11000000
and l
ld l,a
p_RMod128:
.db 4
ld a,%10000000
and l
ld l,a
p_RMod256:
.db 2
ld l,0
p_RMod512:
.db 4
ld l,0
res 0,h
p_RMod1024:
.db 6
ld l,0
ld a,%11111100
and h
ld h,a
p_RMod2048:
.db 6
ld l,0
ld a,%11111000
and h
ld h,a
p_RMod4096:
.db 6
ld l,0
ld a,%11110000
and h
ld h,a
p_RMod8192:
.db 6
ld l,0
ld a,%11100000
and h
ld h,a
p_RMod16384:
.db 6
ld l,0
ld a,%11000000
and h
ld h,a
p_RMod32768:
.db 6
ld l,0
ld a,%10000000
and h
ld h,a
Title: Re: Features Wishlist
Post by: nemo on December 05, 2010, 10:43:00 pm
couldn't reverse modulus be written like 16-(^7)?
Title: Re: Features Wishlist
Post by: Runer112 on December 06, 2010, 12:13:32 am
Indeed it could be. But, especially for the cases where the modulus is a multiple of 2, it would be both faster and smaller to actually have a reverse modulus function. For instance, whereas -(^16) would be 12 bytes, ^^16 would be 6 bytes. As an even more extreme example, whereas -(^2) would be 11 bytes, ^^2 would be 2 bytes.



EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
Title: Re: Features Wishlist
Post by: calc84maniac on December 06, 2010, 12:36:06 am
Couldn't you do and -16 for reverse modulus by 16? (16-bit "and" if applicable.) Bitwise and would supply exactly those optimizations you are requesting (or if not, I would certainly make those optimizations a suggestion to Quigibo)
Title: Re: Features Wishlist
Post by: Runer112 on December 06, 2010, 11:06:18 am
That would work too. It would be smaller than the -(^16) solution; every call with a modulo of 2-256 could use the 8-bit and operator and would be 6 bytes, and a modluo of 512-32768 would be 9 bytes. Reverse modulus optimizations would be, on average, about 60% the size of their and -CONST counterparts. Which I guess isn't too much, but if adding it wouldn't be too hard, why not add it and let people save a few bytes. And I think it would be especially useful for the 2-byte ^^256, which could come in handy in some situations.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 06, 2010, 01:15:11 pm
EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
;D
Title: Re: Features Wishlist
Post by: Builderboy on December 06, 2010, 01:55:45 pm
For reverse modulus 2, wouldn't #+1^2 be smaller and faster?
Title: Re: Features Wishlist
Post by: Deep Toaster on December 06, 2010, 02:23:10 pm
Hmm, how would that work? It would return only 1 or 0.
Title: Re: Features Wishlist
Post by: Builderboy on December 06, 2010, 02:24:13 pm
Oh wait never mind, lol i was reading the explanation of reverse modulus wrong.
Title: Re: Features Wishlist
Post by: LordConiupiter on December 08, 2010, 12:04:27 pm
EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
;D
o nohs!!! I lost the game :( ;D
Title: Re: Features Wishlist
Post by: Quigibo on December 08, 2010, 03:40:41 pm
Yeah, I'm going to have to add some auto optimizations for "and" "or" and "xor" and their 16-bit counter parts. I totally forgot about those.
Title: Re: Features Wishlist
Post by: Builderboy on December 08, 2010, 07:32:01 pm
Woot ^^ nothing is nicer than uploading a new Axe version onto your calculator and watching the file sizes shrink :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 09, 2010, 12:23:08 am
Cool to hear more optimizations are being added. I will have to compile my Axe TUnnel game with 0.4.6 to see the difference. It has been a while since I last updated it. It was using 0.2.6 I think.
Title: Re: Features Wishlist
Post by: Raylin on December 21, 2010, 09:12:33 pm
Progress?
Title: Re: Features Wishlist
Post by: jnesselr on December 21, 2010, 10:21:35 pm
It still amazes me that this thread is 110 pages long.
Title: Re: Features Wishlist
Post by: Quigibo on December 21, 2010, 10:33:27 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.
Title: Re: Features Wishlist
Post by: Runer112 on December 21, 2010, 10:38:55 pm
Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.

;D
Title: Re: Features Wishlist
Post by: Deep Toaster on December 21, 2010, 10:40:47 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.

Final release :o

Somehow that sounds ominous. But it's awesome!

As a suggestion, though, how about ! being used for not(? Just my opinion, since I'm used to !If  and Else!If  now ;D
Title: Re: Features Wishlist
Post by: Happybobjr on December 21, 2010, 10:40:59 pm
Just saw you changed your progress change to 70%.  Good job.
I wonder how many non-omnimaga users use axe.  I occasionally see something on ti-calc  from a non-omnigamian.

Anyways, great work, i can't wait.

request: what are the chances of two bytes for send( ?
Title: Re: Features Wishlist
Post by: calc84maniac on December 21, 2010, 11:00:23 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.

Final release :o

Somehow that sounds ominous. But it's awesome!

As a suggestion, though, how about ! being used for not(? Just my opinion, since I'm used to !If  and Else!If  now ;D
not()