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...)

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)

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.

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.

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.

This sounds really nice!
I think I'd write best in hex (My Preference).

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.