Reading from Archive

[Waave]

I've been working on a new platformer.  The physics and collision detection are finished, so I am now doing level design.  I have written the engine in such that rooms can be added easily.  Each room has two unique 'programs' (written in separate programs to make accessing them easier), one that draws the room and one that deals with any actions unique to the room.

The size of the engine is 2-3 kb, but with just 1.5 finished rooms added it is 6 kb.  I want to add many more rooms, and I know I will run out of RAM at this pace.

So, is there any way I can put these files in a group and read them from archive?  I have a feeling someone will suggest Appvars, I haven't looked into those yet because I don't want to have to learn about them right now :p  However, if they are the best solution, I will use them.  Also, can Axe archive/unarchive files and is it practical in a game?  Any other suggestions on how to reduce this program's size in RAM by storing level data in ROM would be appreciated!


tl;dr:  I need to store level data in ROM, how do I do this?

[Deep Toaster]

Code: (Axe) [Select]

"prgmPROG"→Str0
Archive Str0

[calcdude84se]

Code: (Axe) [Select]

"prgmPROG"→Str0
Archive Str0

That's how you can archive a program/appvar/etc. Unarchiving is similar.
Moreover, Axe has a feature known as "files" that allows you to read directly from ROM. It's a bit slower, but it might be fast enough, and you could always copy the data to a saferam location.
For example, this code prints (or at least tries to) the string in the archived appvar STRING, which should be at most 768 bytes lest this overwrite something important, and which should end in a null so it doesn't display more than it should:
Return!If GetCalc("appvSTRING",Y₁)
Copy(Y₁,L₃,{Y₁-2}^r)
Disp L₃
To my knowledge files support Copy( and dereferencing ("{}")

[Waave]

Thanks, I will play around with this.

----

These both seem to deal with data.  Is there any way access archived code at runtime?  Is there any difference?

[calcdude84se]

Archived code...
Well, you have two options for that, if you really need to do it.
The first option is to make your program an app. That gives you almost 16KiB total space for in-program code and data.
You can store code in appvars if you really want to. You wouldn't be able to run it directly from flash; you'd have to copy it to RAM first. Since Axe doesn't have the ability to compile to a base address other than $9D95 (programs) or $4080 (apps), any code would have to be in assembly. That said, such an appvar could be run like so:
Return!If GetCalc("appvCODE",Y₁)
Copy(Y₁,L₃,{Y₁-2}^r)
(L₃)()
I highly recommend that you use an app, though.

[Waave]

Perhaps I have a different problem than I thought.

The way I am including these programs into the main code is with prgmI0, which as I understand inserts the code from the sub program directly into the main program, as if it were all typed into one long program.  I suppose that for this reason, the code must be unarchived at compile time and is contained in one file during runtime.

I am unsure of whether or not this can be done in Axe, but perhaps a system where the files remain separate after compilation would enable me to achieve the results I am looking for.

As of now, I would like to stay away from an App if at all possible.

[calcdude84se]

Oh, you mean storing the source code in multiple programs. The source can be either unarchived or archived, it doesn't matter.

[Waave]

Right, but once it's compiled, the executable code from each individual program cannot be archived/unarchived independently.  I realize that the source doesn't need to be present for the compiled program to run.

[calcdude84se]

Runer112 offers another solution for running archived code, in contrast to my earlier idea:
Say that the largest subprogram is 256 bytes. At the very beginning of the program, put Asm(0000...0000), where there are 256 00s.
Then, your subprograms can be run like this:
GetCalc("prgmSUBPRGM",Y₁)
Copy(Y₁+2,_E9D95,256)
(_E9D95)()
There are some limitations to this method, though.
Axe's more complicated built-in routines only get included in the compiled program once when they are used. This way, they'd be included once in every subprogram.
You'll have to treat each subprogram as a blob. That is, you can only run it from the beginning, not use any routines in it. Same for trying to run routines in the main program from a subprogram. No can do. The first problem is actually a specific instance of this one.
If you want more capability/flexibility, you'll have to use assembly. That, or manually calculate addresses.

[Waave]

Well, thanks for all the help.  I'll see what I can do.

This is why I want to learn how to make games with a computer :p

[Quigibo]

If you're trying to separate code from data to create very large programs with huge levels, Axe has a framework for that using files.  But if you're trying to separate individual executable code, there really isn't a way to do that without some major hacks, and I recommend using assembly for something that advanced.  It would have to involve adding a VERY large amount of bulk to both the routines themselves and calls to them, far more restrictions in the coding (like you can't have one archived routine call another), and it would be incredibly complicated to code.  All of this is regardless of if you use Axe or assembly.

So the question is, do you really need it?  Apps can be up to 16KBs of executable code and the crabcake Axiom allows regular RAM programs to approach 20KB executables.  Moving level data to archived appvars or programs can increase the total size much larger as well.

[DrDnar]

Reading data directly from the archive with the files feature and {} is a little slower than reading the data from RAM with {}. So, it's probably best to copy an entire room or chunk or something from the archive (using Copy()) into safe RAM (r1-r6) and read from there using {}. In other words, buffering data from the archive into RAM is often faster than always reading from the archive. On the other hand, not buffering is a lot easier. You'll need to learn to balance the two.

By the way, the OS enforces an 8 K limit on nostub assembly programs (for no good reason, of course), so if your program is larger than 8 K, you might as well make it an Ion program.