FORTH take some getting used to. Learning to manipulate the stack to do exactly what you want without pondering it for a couple minutes will require you to seriously dive into the language and do some real work in it. After that it's not too bad.

In some ways forth is actually easier. For one thing, the language has relatively few operations and no pointer management.

Yes it does. Though not used nearly as often as in other languages, FORTH has variables, and they are used as pointers (declaring a variable defines a word that pushes the address of the variable to the stack, and you can manipulate it like any other number on the stack).

I *think* Ahelper was saying there might be a way to get SDCC to output code that was compatible with TI-OS (is this what you mean by AOS?). I think if you release this as a GlassOS exclusive, your audience will be next to zero. IIRC, it can't be dual booted with TI-OS, and as far as I know, it is pretty far from a release. Nothing against GlassOS, but if anything, I'd suggest a dual release.

Yeah, I know. I'm fine with no audience. However, you bring up a good point with the dual release. with a bit of conditional compilation and a separate rel file, it should be possible to compile it for multiple targets.

Using an appvar (or any other variable but appvars are best since you can name them as you want and have them the size you want) is not really processor demanding. And you only need to provide its name once in the program since then it is repered by a pointer and no longer by its name (except if you lost that pointer and need to find it back). Here is an excellent tutorial about appvars (and external vars in general). Also, as StreetWalker said, when you need a lot of RAM, you don't really have the choice, you have to use those if you don't want you array to be in parts.

what I mean is that you can't really use GetCalc as malloc in situations like these:

entity **collision(entity e) {
  entity **es = malloc(sizeof(entity *) * 16);
  int cursor = 0;
  for (int i = 0; i < num_entities; i++)
  if (collision_exists(entities[i], e)) {
      es[cursor++] = &entities[i];
  }
  return es;
}
Which is the primary use of malloc in modern C.

GetCalc is mainly used if you need persistant data (I don't), or if you need more ram than you can get away with statically allocating with Buff (I do).

I suppose it's possible to use a hack and dynamically generate names for appvars, store the name somewhere in the pointed memory block, and free it with DelVar using that name, but that's inefficient and unrealistic.

This is an off-topic discussion, and I feel like this isn't really the place for it.

Quote from: Streetwalker on June 05, 2013, 10:31:37 pm

Quote from: adrusi on June 05, 2013, 09:59:24 pm

I'm thinking of writing it in C on computer first where it's a lot easier to make changes, then porting it to axe.

Lolwut ? This prolly isn't a good idea because Axe is way different than C.

Axe is missing a lot of higher-level features that C has, like types and structures, but the low-level features of C and Axe like program flow, arithmetic, and memory access make them quite similar. C is probably the most similar major programming language to Axe.

If you want to write something in C and later port it to Axe, just be careful not to rely too heavily on features that Axe doesn't support or that you can't easily enough mimic with your own code.

right, I'm thinking in axe, but writing in C. I'm not using stuff like malloc which don't exist in axe. It's all fixed length arrays and such. C just helps keep it organized, so I don't have to think about name conflicts at the same time as I think about algorithms and such (and I can see more of the code at once).

I'm hosting the code on github in case anyone's interested. I'm trying to simulate the environment on calc as realistically as practical without using an emulator or something. Maybe some of the functions I write will be handy for others approaching an axe or asm project similarly. https://github.com/adrusi/Isaac

Maybe you could have preset rooms, but selected via a random number...
So, if you have 13 room layouts, then each room could be assigned to a number? Not sure what calculator you're programming it for though.
Also, have a number stored to memory, and after, say, 3 rooms or so, it would put the entry to the next level in a room that you have not entered.
That eliminates the fact that you could just go into 1 room and find the way to the next level. Still though, not sure what calc your using.

Yeah, it will have 16 or 32 room presets, just like the original game has preset room configurations, but what I'm concerned about is arranging the rooms on the map of the floor.

Every room has to be reachable, each floor has to have certain types of special rooms (item room, boss room, shop, maybe secret room). Some rooms also need to be placed specially on the map. The boss and item room have to share exactly one side with another room, secret rooms (if I implement them) can't block the way to the rest of the floor (there has to be a way to get from one side of the floor to the next without breaking into a secret room).

suggestion: make it auto-create the os pic vars on starting if they don't exist

other than that, nice update

Fixed. Just for the hell of it, I also included a executable compiled for no shell.

I also made it a bit safer at the cost of long startup and exit times. It used to keep the OS picvars in RAM while the program was running, this of course makes ram clears during the program's execution a problem. Now it operates on a temporary buffer which is copied to and from archived picvars on startup and exit. Even with fast mem timings enabled, it can take upwards of 10 seconds (since if has to write to the archive).

Personally I think it's worth it. The primary intention for the tool is making sprites for games, and if you loose your game's sprites, it might just ruin your day.

Edit: the program prefixed with a theta is the Axe source, and the other one is the executable.

Sorry, I should have put this in the original post. It expects the OS vars "Pic3" and "Pic4" to be defined. If they're not it should display an error message, but it might have gotten erased immediately, I haven't tested that since I wrote that code yesterday when I started. The screen glitching out is probably it trying to display the undefined picvars.

Just do StorePic 3:StorePic 4 before running it. I guess the program should do that by itself, but whatever. It will work with the picvars from archive though.

The program file with the theta is the Axe source code and the other one is an actual runnable assembly program.