I am hard at work on my Zelda game. I need some help from u guys, tho. I need a routine for the calc that can convert data into RLE. And I need another routine that converts RLE back into standard data formatting. Those, while preferred in Axe, can be written in inline assembly as well. I tried to do one myself, but it failed. I'll try to post it when I can. The last request, is simply for some assistance, collaboration, on Zelda's AI routines.


In other news:

I just taped together four pieces of graph paper, to prepare to draw out the final, official version of the Legend of Zelda "Ganon's Rage" world map. There will be the main quest (the dungeons, fighting Ganon), and three side quests (the first one you kind of have to do, unless you want to go through most of the game without a sword). The second two give you, respectively, the hookshot and the longshot, which can be used to access dungeons as opposed to using magic power to cross lakes or lava.

Also in this game is the smart-save feature. When you first unpack the map file from the RLE compressed appvar into the uncompressed appvar, a 2 or 4-byte checksum (whichever would be more sensitive) of the uncompressed map is saved. As you play the game and collect pieces off the map, obviously the values of the tiles change. When you exit the game, a new checksum is calculated. If it is different than the original checksum, the map is recompressed and overwrites the original appvar. If the checksum has not changed, the current map files are deleted, leaving only the compressed file, which, theoretically, should not have changed.

The main map is now done. And the Kakariko village rooms are done. Now I'm on the dungeons.

Sorry for this kinda pointless post, but I couldn't resist.

omg. thats sooo stupid. lol. but funny.

Congrats, keep up the good work! Do you still need that RLE routine?

I am going to see how much space this takes up without compressing the maps first. If it is too large, yes, I will need to do that.

The problem with the construction of these routines, is that, depending on which map is being utilized, the source appvar for decompression may vary. Likewise, the output appvar for compression may vary. Follow? Hopefully it won't be too complex to implement.

Progress Report

main map fully coded
3 miniquest maps fully coded
all building maps fully coded
dungeons in progress
save file format layed-out
walking engine 40% done

Impressive, keep up the swift progress (as long as it doesn't interfere with real life or with schoolwork)! Got any nifty screenshots for us yet?

Not yet, Kerm. Once I get the graphics engine done. That comes after the walking engine.

Ok. The walking engine is partially done. It has two parts, the offset collision engine, which causes the routine to exit without changing your position if the object you are moving into cannot be walked onto, and the on-site collision engine, where the object can be moved on to, but doing so triggers some sort of event (like lava inflicting damage or dungeon entrances taking you to dungeons). The offset collision engine is done. Now starting the on-site collision engine.

Once that is done, then I need to do the graphics engine. Once that is done, it's screenshot time.

The first screenshot of the game. Of the splash screen.

Why does it spazz out like that? o.o

Good question. It is just an emulator thing. It doesn't do that on real hardware.

New screenie for the splash screen::

Cool! Why is the "A" thinner than the other letters?

lol. i dont know. i guess i got a bit lazy.

I second the wish for that A to be the same width as the other letters. Would you welcome edits on your proposed titlescreen? Also, fun fact, the Zelda franchise is 25 years old, older than me!

Go ahead. Edit it as you wish. I'll upload the pic file.

http://www.mediafire.com/?68i7y4inpls82o3

Here's my mockup:

I think it would look a little bit better if E, L and D are moved one pixel to the left, because right now the D and A are closer to each other than the other letters are.