Ok.
In fact, I was thinking that if one of those numbers was not "useful to the action", you could put it elsewhere. For example, you don't really need to know how many rupees you have when you are in the middle of a dungeon, but you constantly need to know how many bombs and keys you have, so the number of rupees could be put in the menu for example (if you compress things a bit in the menu )

To be honest i don't really like how this looks like with the large gap at the top. Plus in all Zelda games you see your money in the main HUD, so removing it would be kinda inconsistent. What could possibly be done, though, is removing the total keys althogether and move it to the menu somewhere, such as above orbs but inside an area with white background, but not at the top .

Sadly not much progress due to being busy, sleepy (especially since the last month or so) and doing other things, although I recently experimented with more advanced wall graphics for the overworld. However, I'm not sure if I'll use them because the program that generates them is 800 bytes large.

Regardless of if I use it or not, however, I might need help optimizing, because before the 84+CSE was announced last Winter, I didn't use TI-BASIC for 3 years, plus I am mostly familiar with tricks from 1999 to 2003 or so. The main issue right now is that I have to use a crapload of Line()/Pt-On commands, with some For loops, but when I'll have to code map generation further to check for doors, items, etc, I worry that my code will turn into a big cluster of if/then/else spaghetti code.

Anyway, here is the new overworld dungeon layout idea I had, with walls inspired from Link's Awakening (slightly less complex in order to fit the half horizontal resolution and to save RAM):



It actually checks if the next maps are linked to the current one to open pathways, but only horizontally. What will make map checking file size skyrocket is the fact that there are 4 ways to check and I'm unsure about how to do it efficiently when there are like 9 different types of entrances/exits (meaning 36 potential If blocks)

Indeed, that is great
However, as you said, this is pretty slow to draw
Couldn't you draw the "walls pattern" once for all at the beginning of the program, StorePic it then when entering a room, you just RecallPic it then put the holes where the doors should be ? That could be an interesting gain speed imo

I don't feel it's actually that slow, although it's slower than the other dungeon walls and slower to switch between rooms (although a temporary picture can come to the rescue for such thing). I was actually surprised at how fast I can draw graphics this complex, considering the walls are from a game boy game.

However I won't use one pic per possible room layout (for example with blocks, rocks, doors, etc), else the game will require 3 MB of archive to run (22 KB per pic). What happens is when reloading a game or entering a dungeon, the walls are drawn, then whenever I need to draw a door or path, I simply erase parts of the wall, then when Link goes to another room, only those parts are refreshed rather than every wall as a whole. Using one pic would be nice, even if it costs 22 KB of archive per pic, because I would just recall the pic then redraw new doors/paths. The problem though is if I use a pic, I would have to redraw the menu everytime I switch to another dungeon, since I can't store it into the pic (else redrawing the dungeon walls would screw up the menu)

Because if during the game, for example, I acquire a new item, lose HP (or regain some), get rupees, use bombs, recalling a picture will revert back those HUD/menu changes to when I entered the dungeon. The best scenario would be to draw the entire dungeon and menu borders then store the picture before displaying the rest, so that whenever I recall the pic, those parts aren't overwritten. Of course using such technique means I cannot use ClrDraw, though, but I could possibly do the dungeon layout in a way so that I don't ever need to ClrDraw.

On the TI-84+CSE, white doesn't act as transparent like on Z80 calcs, btw. If for example you use a yellow background then draw one horizontal line of the same color on top of it, even though the colors are the same, the line will be the only part that isn't transparent (pixels are turned ON)

Thanks . Now if only I can do more progress on this soon. At least vacations are coming (and I have two more vacation weeks after the summer fest).

And yeah drawing isn't too bad. What is bad is updating the entire screen at once, though, so one could not, for example, create an epileptic animation with For(Z,0,99:DispGraph:Disp:End like we could do on older models, plus pics are really large (although they take no RAM).

If this game uses temporary pics it will probably use hacked pics rather than the 10 standard ones, since Devpic still works fine on the 84+CSE (it lets you use 30 extra pic tokens). I need to check if such program transfer fine from a calc to another, though. That would prevent pics from overwriting people's pics, which is a reason why some people dislike basic programs.

That would be nice actually, although while at it, the size issue should probably be solved, since pics are already really huge

That is quite nice. How large are the pics?