I'll work on that.  Both of those are fixable, but I'm not sure if there's any built-in OS calls for that.  I can write my own routine, but I'm trying to make sure these programs don't use too much memory.  Luckily, the subroutine support can really cut down on size of the overall program.  Even the most basic things like this save memory:


:If 2sub(1)
:'code here'
:End
:If 3sub(1)
:'code here'
:End
:Lbl 1:<A:Return


The routine above saves 5 more bytes than if you were to use the strait forward way below.


:If 2<A
:'code here'
:End
:If 3<A
:'code here'
:End

Thanks for the report.

When apps exit, they need special exit code so that what you're describing doesn't happen.  It sounds like there was a memory leak somewhere causing the app to exit early.  That's why it didn't reset the ram, because it wasn't actually frozen.  I'll let you know when I find the leak.  Thanks again.

EDIT: Okay found it.  Wow, that was a stupid mistake on my part.  To get around the error temporarily until the next version, don't use parenthesis in any place where they are not needed; if the order of operations is naturally going left to right anyway.  The compiler is supposed to ignore the parenthesis when you do this, but instead it exits early...

:If (K=4) and (B≠0
Change to this:
:If K=4 and (B≠0
Since K=4 is evaluated first anyway.

If you ever get this error again, just turn off your calculator and turn it back on and the problem will go away.  Nothing in memory should be affected.  Oh actually, maybe ram clear anyway since the "LOL" file will be corrupt.

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.

Quote from: 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.

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.

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.

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:
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.
[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.
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?

The new update 0.0.3 is here.  Finally got around to parenthesis, those things were Tricky!