TAO: Unleashed (Progress)

[DJ Omnimaga]

Ah ok, sorry to hear it is not suitable to Axe. Are you ditching Axe completly btw?

Also I hope you still plan to post progress here despite the wiki.

[graphmastur]

Of course I'm not ditching axe.  Quigibo would just have to add support for 1 program page and 3 data pages.  eg. Not gonna happen.  I did a bit of math today, and basically, all enemies go on one page, along with most attack data. All names for enemies/characters/items/attacks goes on another page with all the text they say and scene data (Maybe. Scene data might go on the last page which is...).  And the last page is for sprite data and possibly scene data.  And, all the other fun little misc stuff.  The reason I am organizing like this, is because just a single enemy type is 50 bytes long.  So yeah, did I mention this game is huge.

The wiki is just for my notes, and will have a "new" thread, but I will also post important updates here as well.  So. Anything you want to know about TAO now, since its mostly planned. (Just a few more engines to do specifics on.)

[DJ Omnimaga]

Darn that's a lot of enemies and attack data o.o

I didn't realize the game was so large. In Illusiat 13 the enemy data is 7000 ish bytes including battle floors, and that's because commas takes 1 byte annd numbers made of more than 1 digits take additional RAM as well. In ASM/Axe, I am fairly sure that the data would be much smaller

I think in my game what would have taken the highest amount of data are map data and text (about 100 KB in Illusiat 13.)

[shmibs]

cant you just use external vars?
it would be a little weird, but doable

[graphmastur]

Maybe, but it would have to be archived/unarchived, plus it would not be aligned. To the byte I need it to be.  It needs to be aligned to a constant byte whatever it is, and that cannot change.  Its actually to limit the amount of space I do.  Also, Each text is going to be null terminated, and start with the id of who is saying what.  Plus, there is so much explaining and such.  Once I get the entire story outlined, and finish the map and text engines along with the Scene engine, I can actually start planning the exact dialog and such, and get a better estimate. If it is in ASM, I will release the source code, along with a bunch of comments. (The comments mainly being for me) This is to study of what NOT to do. ;-)

Besides, 4 app pages worth in appvars? Seriously? Not really a good idea IMHO.

[DJ Omnimaga]

Didn't Axe add reading from archive? If it's the case, then I don't see why having that many appvars is such a problem, though. It comes back to people being narrow-minded about the amount of files that comes with a game (like Illusiat 13 being forced to be split into 24 sub-programs due to not fitting in RAM), which would be even worse in this case considering appvars won't clutter the PRGM/APPS menu.

[graphmastur]

True, but the point about them needing to be at known addresses is final and unchanging. It cannot be changed because it would sacrifice time and speed. I'm not being narrow minded about it. I had already thought of it and decided it couldn't work. 24 programs sounds like a lot for an rpg, but not insanely bad either.

[DJ Omnimaga]

Yeah the game is 135 KB at 90% completion, so that's to be expected

Why do you absolutely need the files to be at the right addresses, though? Does reading appvars really cause this much of a slowdown or is it just a game that is extremly speed-intensive? (which would surprise me if it's a turn-based RPG) I wonder if this would cause issues in future OS updates? I migth be missing something here

[graphmastur]

Well. It's not entirely a turn based rpg either. There is more than just the battle engine.  They have to be at constant addreses, because of the way they are accessed with the massive ammount of lookup tables. For the appvar with user data I'm storing all the individual pointers to it to L1 at known locations in L1. You could find all the appvars, and store pointers in L1, but you would have to refind it each time. Besides, after the Start, they could no longer move, unless I refound it again, dealt with differences between the two start addresses, and find the offset again.

[Raylin]

So, there's absolutely no way for you to move your data around?

[graphmastur]

So, there's absolutely no way for you to move your data around?

Only the one appvar for semi-permanent user data. Everything else must be constant. For the record, I've found out about multpage apps, and think I can program one.

[DJ Omnimaga]

Ah ok I see. I wish you good luck then, especially that now you will need to learn another language to continue your project.

[Raylin]

Indeed. Good luck, sir!

ALSO, 1000^th post, boi!

[graphmastur]

congrats raylin!

@DJ
Thanks. I am already learning asm again.

[DJ Omnimaga]

One reason why I was afraid that you ditch Axe for this project was because I was sure you were new at ASM and it is generally recommended to start with smaller projects when you are new to a language. First of all you should try to manage a demo to practice, then when you are comfortable with assembly, you can go larger. I saw so many ambitious projects fail in the past because its author did not have the experience required to work on such game (typical forum post was "Hai, Im working on a massive grayscale RPG in xLIB that will pwn every other RPG on ticalc.org. Could someone teach me how to use Getkey?"). Again, some large projects by new coders DID succeed back then: Desolate, The Verdante Forest, etc. The code was extremly large and unoptimized, though, because it was old unoptimized code patched with newer, more efficient code. Do not fall into the endless-rewriting loop either, though, although going back through the code and rewriting some parts can help, sometimes.

Good luck again with this project