Please be patient with this project; progress may be slow at times due to college and life in general.

I have begun work on a Legend of Zelda fangame for the color TI-84 models. In terms of gameplay and graphical style, I'm looking to achieve something between the original NES release and Oracle of Ages/Seasons.

Project folder: Google Drive
The linked Google Drive folder contains my most recent in-development release (potentially unstable), developer tools, and an archive of previous stable versions. Any help or suggestions you can offer would be greatly appreciated, especially with optimization and debugging.

Version History/Todo (summary):
+ a0.10: First Release, just the title screen and non-functional main menu
+ a0.11: Flood-Fill is now skippable and less redundant.
+ dev1.00: Map Editor (under Development Tools)
+ a0.15 Main Menu Functionality
+ a0.15 Settings Menu
* Tileset
* Map Compression/Decompression
~ Credits
~ Plot
~ Map Design
~ Dungeons - Argus
~ Dungeon Items
- ReadMe / Documentation
- Movement Code (I'll probably just port from another project)
- Enemy AI
- Boss Design/AI
- Sprites
- Cutscenes
- Inventory
Title Screen Caching

Color Code:
+ vx.xx: Complete, Released
* Complete but Unreleased
~ In Progress
- Incomplete
Scrapped

Screenshots:

Looks great but I do think it would only be appropriate for use if you could make it faster - I can imagine users not wanting to wait around for it every time.

I would also think the player should be able to skip it as well - so a both of those options for me.

Thanks! I will definitely allow the users to skip the flood-fill. That's the easy part (at least for me).

As far as speed, that was the fastest I could get it to run, but I know some of you are absolute wizards with optimization. I would greatly appreciate any help on that front.

And if anyone can point me in the direction of an equivalent Assembly or C routine, that's probably the best option.

Fantastic looking graphics! I ran into the exact same issue you're having with one of my past projects. I opted to allow the user to skip the intro if they wanted.
I think instead of using a floodfill routine, it would be much faster to use PlotSprites or use lines for the majority of the fill. Although it'll make your program bigger, the end result will be much faster.
Keep up the great work!

Thanks!
Maybe I could do some sort of hybrid and use horizontal lines to fill each area, and only test for/detect the ends. Would that be any faster than the current method?

I don't want to give up on having a reusable routine if I don't need to. I'm trying to balance both speed and size.

Edit:
I was unable to get the hybrid "scanline fill" to work properly. My attempt (which partially works) is available in the Google Drive folder linked on the first post.

To test it for yourself, download Fill.8xp and fill3.8xp, modify Fill to call fill3 instead of fill2, and call it with the following code:

Code:

The closing "}" can be omitted without consequence, but I included it here for syntactic correctness.

Edit 2: I will eventually cache the title screen in one of the Pic vars, so users will only need to sit through the slow flood-fill if the cache is overwritten.

MINOR UPDATE (a0.11):

I found and fixed a few redundancies in the flood-fill routine.
The filling process also can now be skipped by pressing any key while it is in progress (jumps to the main menu) or disabled (jut draws outline) by changing
Code:
to
Code:
in the main program.

The new routine is admittedly slower due to the skip code, but the older, faster version is still 100% compatible, just replace FILL2.

C controls the color of the outline on the word "ZELDA."
M controles the line thickness (do not change this if flood-fill is still enabled).

version a0.10:

version a0.11:

Is "if [condition]=0" any faster than "if not([condition])"?

the not( command is actually faster based on this website: http://tibasicdev.wikidot.com/timings#toc3

The section you are looking for is called "Relational Operators"

Thanks!

UPDATE (a0.15):

The main menu is now fully functional, with simple placeholder text replacing the unimplemented options.

There is now a settings menu, which currently only controls the appearance of the title screen. Flood-fill is now disabled by default (I will admit that the current algorithm is painfully ssslllooowww), but it can be re-enabled via this menu. If you manage to bypass the the menu's protections against combining flood-fill with thin outlines (a compromise I had to make to get it under 10 minutes!), deleting the list _LZSET will restore the default settings.

Screenshot:

Hey the menu looks really cool, I particularly like the little toggle switch for the options.

Thank you. I was wondering if they might be too small, and I'm glad to hear that that isn't the case.

Hopefully I can come up with more options to add as development progresses (maybe some UI customizations?).

I began working on the default map layout and wanted to get your advice before continuing.

Click to view full-size images:


As you can see, I completed about half of Hyrule (including the Lost Woods) and the base layout for two of the dungeons. My goal is to make the map reminiscent of the one from the original Legend of Zelda (NES) without completely replicating it. I don't think the original map would even fit on a CSE with my very basic compression scheme!

Nice! Is it in pure BASIC, or is there going to be any assembly in there?

At the moment, it's about 98% pure BASIC. The current version uses a single assembly routine to invert the text colors; without it, all text would have to be on a white (or grey, for white/yellow text) background or have ugly borders around it. I want to write much of the program as I can in BASIC (definitely all game logic), but I am open to using small assembly routines for things that are otherwise impossible or impractical.

Source code is linked in the first post if you want to take a look.

So that's how you did the "blank background" text! I was wondering how that could be done.

I'm glad this project helped you with your projects / programming knowledge. If you need the specific routine, I found it here:
https://www.cemetech.net/forum/viewtopic.php?t=11735&start=0

Do you have any suggestions to improve the tileset shown below? I designed it to offer an appropriate balance between speed and detail when rendering in pure TI-Basic, but the player will also have the option to draw basic rectangles for most of the blocks if they decide the detailed versions are too slow.

Also, the magenta tile will represent rupees, I just haven't come up with a good design yet. Unfortunately, these tiles are 14*14 (so I can use color-inverted text sprites for the background colors), not the standard 16*16, so recoloring the original sprites won't work.

I've planned out the rest of the overworld map, but the eastern half (excluding the upper ridge and death mountain) feels incomplete. Does anyone have any suggestions to improve this area or the map in general?

Click to view full size:


Edit: As soon as I finalize the map format, I will release a more user-friendly version of my map creation program so you can start releasing custom maps if you want (dimensions are hardcoded to what is shown above).

I finalized the data format and am working on the official map editor. Unfortunately, the original one (only meant for testing; will be deleted) is no longer compatible since I switched from colum-major to row-major ordering to squeeze a little bit more efficiency out of my compression algorithm. I don't foresee any further changes to the data format, so custom maps made with the upcoming first release should theoretically work in the final game.

Current progress:
Editor interface: 99%
Compression: 100%
Temporary Storage: 100%
Permanent Storage (Export): 50%
Instructions/warnings: 25%

For those interested in the technical details:
4 "banks" of maps:
- Overworld
- Subworld 1 (default: dungeons 1 and 2)
- Subworld 2: (default: dungeons 3 and 4)
- Subworld 3: (default: Hyrule castle)

Rooms:
- Each bank consists of 11 * 5 "rooms" each containing 17 * 8 tiles.
- Rooms can have any layout, provided the "doors" (gaps in the perimeter tiles) align between any 2 adjacent rooms.
- Exceptions are made for the left and right edges to allow for "one-way" doors.

Due to storage limitations, each column (5 "rooms") will be stored in its own list. Since this means each map will require 44 lists, I will recommend that mapmakers bundle them into a single group variable or zip file for distribution.

Map data format:

Code:

Where:
rm = row-major list of tile color codes in each room (0 = empty), compressed using rle compression; rm 1 = bottom "room" in column, rm 5 = top "room"
[warp dest] = {bank, row, column} (only if a "warp door" exists in this "room" on the map; places Link in the center of the destination, one row from the bottom.

preview editor