There are certain commands that aren't actually part of the code, and just insert data to the end of the program (like for RAM variables in ASM). You can "store" them to the GDBs, Pics, and Strs (they're really just labels) to use them as data. So in ACag's code, Zeros(2) doesn't do anything at all except reserve two more bytes in the program that he doesn't use.

Then, how would I dynamically expand the size of a variable, so that I can continue to throw data into it, without writing over the start of the next variable?

@Kerm: Axe's Zeros( command is the equivalent of assembly's insertMem command (is that the right one I'm thinking of).

Isn't Zeros() a that just adds zeros to the place specified in the program you are compiling? Zeros() doesn't work on external variables iirc.

Yes.

If I have 5 bytes of data in a program pointed to by Pic0, and use the command

Zeros(1)

Pic0 now holds the same data, but is 6 bytes (the last byte is 00). That allows me to go back later and add data to that pointer {Pic0+6} without writing over the data following it.

No, it isn't. It's completely equivalent to the line [00] -- meaning that it's a null byte added to the program memory during compilation. It has no effect whatsoever during execution. No inserting memory or anything.

You mean "nop", or ".db $00".

Yeah, exactly. .db $00 is [00] in Axe (except that it's added to the end)

So ACagliano, if you treated Zeros( as _InsertMem, you've probably corrupted some stuff already :-\

No wonder random tokens in my programs have changed. lol. It's ok. I keep backups.

Good stuff, now I know. I'm glad that you guys are running into Axe problems; you're starting to indirectly teach me Axe by simple adsorption.

Returned to Zelda today, looked at coding style. After much Aleeve, I am ready to proceed. However, need AI help in Axe. Silver Shadow may be helping.

Update

The first update in a long time!!

I did a complete overhaul of the game structure. First off, the game will be in z80, not Axe. Second, the map structure is different now. Instead of one large world map, I will split it into several areas for ease of coding. I also went from four dungeons to all dungeons...that's 7. There will be three item-giving miniquests. Finally, the enemy system is overhauled. I have enemy types now and they will have magic-based weaknesses, as they should. The enemy positions are written as tiles onto the map, but when a screen loads, the enemy positions get loaded into an array and handled from there. There may be other changes as well, but I don't remember them off the top of my head.

Project page: http://zelda.clrhome.tk

Umm, all of your screenshots are of TIOS, not Zelda.

Haha, yes that is default, courtesy of Deep Thought. I'll have screenies soon, I hope.

PS: For the items, magic powers, and weapons inventory, I will attempt bit-masking for the first time, rather than one byte per item.

That's excellent, and quite trivial to do, no less. I'm glad you'll be going the optimal route.

Update

The map system has been revamped slightly. Instead of one large main world map, I have it divided into several smaller sections. There will be three appvars for the maps...one for main map sections, one for dungeons, and one for the miniquests and village rooms. There will also be one appvar for the sprite data, and one appvar for the save file. Thus, a total of five appvars. I may even be able to destroy the sprite appvar when the game exits and recreate it when you open it again, as this data will not change. Thoughts?

Thus far, I have completed all main map sections and all three mini-quests. Just have the dungeons left, then the coding. Still need help with AI. Specifications in the z80 subforum.

This sounds great, and that's probably a smarter and more extensible plan for the long run. Why would you destroy the sprite AppVar? It still has to exist somewhere; is it that big?

All data exists in the APP itself. Maps and sprites. The maps cannot be discarded, as they will change dynamically as items are collected. So, at any given time, there will be two copies of the maps: in the APP, and in an archived AppVar. The copy in the APP will never change (thus can be used for a "reset". The appvars will be updated to reflect progress in the current game. The sprites, however, will never change so whenever the game starts up, they can be reloaded from the APP.

A Question: Can you copy sprite data directly from your APP to the display buffers? I remember that, with Axe, the data had to be in RAM, but that may be just because of the way Axe does sprite rendering.

I see no reason at all why even Axe would need that, to be honest, you can absolutely and very easily render sprites directly from your app.

I did that so there's something there. There's an actual screenshot now.

Kerm, it had to do with using bcall _PutS because it had to switch the pages to get to the routine, so your strings would be in the wrong place. As far as I'm aware, and this is probably outdated logic, Axe uses its own (or a shell's) iPutSprite routine to display sprites, so it should be fine to use in an app.