[TI-84+ Series Hybrid BASIC] Sorcery of Uvutu (Released!)

[123outerme]

Oh I see now. Isn't cooled lava dark gray normally, though? Or is the red color due to being a very large area with lava causing the entire area to have a red hue overall?

And I see. I guess you could show STEVO AT DRAGON DEN or something, but that won't leave much space for text.

Yeah, that last one. And also if it was dark gray idk if maps would look as good. I guess, but I'm probably moving the STEVO and replacing it with LVL 1 or 50/50 or something.

[Dream of Omnimaga]

By the way, I wonder how large enemies can be? Will the final boss be 8*8?

[123outerme]

By the way, I wonder how large enemies can be? Will the final boss be 8*8?

I only intend to use one sprite slot per enemy, but I can use multiple sprites if I absolutely must. Although, I haven't even designed most of the bosses yet.

[Dream of Omnimaga]

Ah ok I was wondering, since peerhaps if the game is long, having every single enemy, including the bosses, only take 1 slot, might make the game a bit boring near the end. But it depends, since a lot can be done in 8x8 with 256 colors.

[123outerme]

I've hit another size issue. I just can't have the scope of the game I want. I either have way fewer maps per world or just release it now how it is. I've completed two worlds and their bosses so far. I'll give you the choice. Just know that the quality will be lower and the game will feel more rushed if I have fewer maps, but if I release it as it is now it'll feel as if it was just cut off suddenly. I'm sorry to have to do this but it's the only way. I've even put a ton of the code into a subprogram. I just can't do it all. I'm also thinking about handing it over to someone else, so if you would like to take the reins of this project, just PM me.

[Dream of Omnimaga]

Could you explain what are the size issues you have encountered? Did you run out of RAM? I'm thinking you might be doing something wrong, because ROL3 had 6 times more dungeons and used even more outdated Archive libs, yet it still managed to fit.

I wouldn't mind seeing a game with fewer features. I think magic spells should be generic, as in, flashing between 3 bits and 8 bits mode, inverting the LCD, and there are possibly ways to reduce code size or improve program management.

I think this project can survive in some ways given its lower lenght compared to some of the 84+ BASIC RPGs out there (Illusiat, ROL, Reuben, etc), and you have an even bigger advantage with the fact your entire sprite data can be archived at any time.

I would say post the 8xp files, but make a new topic in the programming help section about running out of RAM in large xLIB games. But I hope you don't give up, especially that people can help

[123outerme]

Could you explain what are the size issues you have encountered? Did you run out of RAM? I'm thinking you might be doing something wrong, because ROL3 had 6 times more dungeons and used even more outdated Archive libs, yet it still managed to fit.

I wouldn't mind seeing a game with fewer features. I think magic spells should be generic, as in, flashing between 3 bits and 8 bits mode, inverting the LCD, and there are possibly ways to reduce code size or improve program management.

I think this project can survive in some ways given its lower lenght compared to some of the 84+ BASIC RPGs out there (Illusiat, ROL, Reuben, etc), and you have an even bigger advantage with the fact your entire sprite data can be archived at any time.

I would say post the 8xp files, but make a new topic in the programming help section about running out of RAM in large xLIB games. But I hope you don't give up, especially that people can help

I'm running out of RAM, yes. But I think the problem lies in that when loading a map, it has to copy the Appvar I'm using into RAM. These are pretty big, 600 bytes each. And since I copy them out of the Appvar and into Str9, then store it into Str1, it doubles the size. What I think I need to do is put the map loading code in the subprogram, load the map to Str1, and delete Str9. Since whenever it crashes, it always crashes there. If you would like to take a look at the code and try to find other causes, I will send you the most recent build.
Edit: So that workaround worked, but the question is for how long. I have one 250 or so byte subprogram which holds the map loading code. This gives at least 10000 more bytes of map data to work with. That would probably be enough for 3 or 4 more worlds. So I'll have to cut down on the number of maps each world uses by a few, but that'll give enough room to complete the project, hopefully.

[Dream of Omnimaga]

Oh I forgot that maps were much larger than on monochrome calcs by that margin. I'm sure there are ways around it. A calc RPG cannot be smaller than 10-12 files for those reasons, most of the time.

Adding extra worlds shoudln't permanently take RAM normally.

[c4ooo]

The maps are stored as tilemaps, right?

[123outerme]

Oh I forgot that maps were much larger than on monochrome calcs by that margin. I'm sure there are ways around it. A calc RPG cannot be smaller than 10-12 files for those reasons, most of the time.

Adding extra worlds shoudln't permanently take RAM normally.

The Appvar I use to store map data has to be loaded into RAM temporarily to be accessed, and that's where the crash occurs. 10k bytes of that +14k bytes of the main program loaded and I easily excel 21k bytes. That's why I load the map in a seperate subprogram now, so that instead of 14k bytes of a program loaded it's just ~250 bytes. But that only gives me about 20k bytes total for the map data Appvar. I will have to cut a few maps, about 1-2 each for each world. That means about 6-7 maps for the first world, when there was 8 in the demo.

The maps are stored as tilemaps, right?

Yeah, they are.

[Dream of Omnimaga]

You have to split your map appvar into multiple ones. Metroid II and Reuben series used about 20 different sub-programs for map data each. Also I think the map appvar should be split as well, because Celtic II CSE had issues reading appvars larger than 4-8 KB IIRC.

[123outerme]

You have to split your map appvar into multiple ones. Metroid II and Reuben series used about 20 different sub-programs for map data each. Also I think the map appvar should be split as well, because Celtic II CSE had issues reading appvars larger than 4-8 KB IIRC.

They seem to be working so far, but I'll have to see where that goes. Thanks for the input! Now, I'm starting on the third world.

[Dream of Omnimaga]

Personally, I try to pre-emptively fix memory issues when I start, then once I am done I merge sub-programs back when I can, but that's just me I guess. Hopefully your memory problems will remain in the past now and you can add more worlds. The trick is to make sure that everything is data, so that when you add extra worlds, it doesn't increase RAM requirements considerably.

[123outerme]

Personally, I try to pre-emptively fix memory issues when I start, then once I am done I merge sub-programs back when I can, but that's just me I guess. Hopefully your memory problems will remain in the past now and you can add more worlds. The trick is to make sure that everything is data, so that when you add extra worlds, it doesn't increase RAM requirements considerably.

In hindsight, I should've realized the amount of space such a project would take up. Although personally, I prefer the air to make modifications such as subprograms as necessary, to prevent confusing of where everything is. The program can be named to say what it is, but the program can't have a name longer than 8 characters, so if I can't fit two descriptions I'll have to go hunting for it.

[Dream of Omnimaga]

I know that my programming skills were absolute crap in 2001-03, but the following might still be a good reference. Here is the approximate file size of my past calculator RPGs, excluding temporary files and Omnicalc/xLIB/DCS:

First, the minimal graphic or ASCII art ones.
-Illusiat: 5 KB
-Illusiat 2: 6 KB
-Illusiat 3: 10 KB
-Illusiat 4: 18 KB
-Illusiat 6: 17 KB (Nemesiat takes 16)
-Illusiat 7: 22 KB
-Illusiat 8: 18 KB
-Illusiat 9: 26 KB
-Illusiat 10: 32 KB
-Illusiat 11: 35 KB
-Illusiat 12: 78 KB
-Illusiat 13: 135 KB (was projected to take 150)
-Mana Force: 18 KB (would have taken 15 with proper coding)
-Mana Force 2: 58 KB
-Mystique: 45 KB
-The Reign of Legends: 80 KB
-The Reign of Legends 2: 95 KB
-Zelda: Dark Link Quest: 125 KB
-First Fantasy: Mana Force: 27 KB (the remake of Mana Force, over 75 KB with DCSE8)

And now here are the most graphical RPGs (that relies only on sprites)
-The Reign of Legends 3: 120 KB
-Reuben Quest: Ev Awakening: 60 KB (grayscale. Close to 80 KB with Omnicalc or 110 with DCS7)
-Reuben Quest: The Lost Mirror: 100 KB (grayscale. Close to 120 KB with Omnicalc or 150 with DCS7)

If you have played those games, then this should give you an idea of how large a monochrome game can get. Since in your case you have a larger screen, then your maps are inevitably much larger, so they take much more space. Add to that graphics data which is over 8 times larger than on monochrome calcs and the fact you can't use 8xi files for map collision detection with pxl-test (like in older Illusiat games and ROL series), so your map data is much larger.



Also, if finding programs in the program menu is a serious issue, then I think Celtic2CSE libs have tools to copy a program into an appvar and vice-versa, but I never figured out how to use it. Otherwise, another trick is to use Doors CSE browser, where only lauch programs have custom icons and are thus easier to find.