0 Members and 1 Guest are viewing this topic.
Quote from: Streetwalker on June 05, 2013, 10:31:37 pmQuote from: adrusi on June 05, 2013, 09:59:24 pmI'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.
Quote from: adrusi on June 05, 2013, 09:59:24 pmI'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.
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.
In Axe you have getCalc which is equivalent to malloc.
Quote from: Streetwalker on June 06, 2013, 04:22:15 pmIn Axe you have getCalc which is equivalent to malloc.but you can't use getCalc without providing a name for an OS var, right? That's not really practical for anything other than global arrays, and besides, it's best to avoid dynamic memory allocation if possible, I'm sure it's quite expensive on the calculators.
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.
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;}
If you write it in C on the computer, will you try to update the Axe version simultaneously too so we don't have to wait until the C version is completed before the calc version even starts being worked on? Else, another idea could be to use SDCC (like AHelper is doing for his TI-84+ OS on Cemetech) so you can write the calc version in C as well. I heard that calc C is a bit slower, but nobody really ever tried making the same program in both calc languages to compare afterward.
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.
Author
Topic: [Planning] The Binding of Isaac (Read 11423 times)
