LINK II

[bitbot]

Link II: Link's X-Rated Adventure

Haha. It's in the little things... instead of a Sleepy Toadstool or a Wake-up Mushroom you simply get a magic mushroom. etc.

[bitbot]

It wouldn't be LINK without a platform level.

sidedung.gif (8.56 KiB) Viewed 16480 times

Commodore: This might be tricky in a Pharaoh's Tomb sort of environment.

[Dr. Dos]

http://www.i-mockery.com/romhacks/pimpdaddylink/ This is what we'll actually be getting.

[bitbot]

You're always good for a laugh, Doc.

I was thinking about putting a block of Lyons here just for you.

[Quantum P.]

Very nice screenshot! I especially like the torch and bricks.

[Saxxon]

Very nice screenshot! I especially like the torch and bricks.

YES. The art is looking fantastic.

[bitbot]

Very nice screenshot! I especially like the torch and bricks.

YES. The art is looking fantastic.

Thanks. I'm just copying Zelda. There's these moments where I keep it true to ZZT. That's what makes it interesting.
It'll be twice the game it would've been had I not come around the forums.

WEEK 13 - The end is near

TODO:
=====
Overworld+Fishing (now that inv works)
Story (a short essay's worth)
Battle 2 (1/2 done, rehash of battle 1)
Ending art
Bug squashing

[Commodore]

If you run out of memory for story, you could include it as a .hlp file and call it in-game with a minus on the normal select command. !-filename;Introduction. A user could read it though, so maybe it would only be good for the opening or intro, and not the ending.

[bitbot]

If you run out of memory for story, you could include it as a .hlp file and call it in-game with a minus on the normal select command. !-filename;Introduction. A user could read it though, so maybe it would only be good for the opening or intro, and not the ending.

The only lack of memory is in my head. I hope to overcome this writer's block.
I've been pondering the possibilities of .hlp but didn't think of this. Good hack!

All story placeholders and bulk data are in... fingers are crossed. I think I'll barely make the ???k limit.

[Commodore]

I like memory saving tips.

If you have an object that has lots of #ends or #restarts is more memory efficient to use labels like :e or :r that point to an #end or the beginning of the code. This is usually more important when trying to cram something in a single board, but is helpful over all.

Text is your friend when it comes to cheap decoration.

IIRC, ZZT boards use run length encoding. So a row of gems or something placed horizontally takes up less space in memory than the same number placed vertically. Horizontal fades take up less memory than vertical ones. Random tiles are very costly to memory.

ZAP has a few memory saving options to try (make backups!) so long as you don't need colored empties, it can turn all of them to the same. This really only usually saves a few bytes though.

In general, try not to use labels more than two characters long.

Something that needs to be shot a lot can do something like this
:shot
#s
:s
:s
...
:s
:s
#zap s
#end
:s
#die

[Quantum P.]

I second the suggestions for #end->#e and #restart->#r. Don't forget that the bottom of the program is an implicit #end, so you can write your program without using #end at all! It only saves a couple of bytes per #end, but it can add up if you have a complicated program with lots of code branches.

Changing :shot->:s and :touch->t are also favorites of mine, though I don't get to use them as much.

MadTom's guide to conserving memory, tip 6 (finite loops via #zap) is one of my favorites.

You can get rid of the #end at the top of a program by setting the instruction offset to -1 (using KevEdit, of course). IIRC a label doesn't work if it's on the first line. So if the next statement is a label, you have to add an empty comment before it:

Code: Select all

'
:touch
#gizmo:do
. . .

Here's an enlightening exercise if you've got a board that's getting too big. Open a text editor and, for each object on the board, write down a description of the object and its program size in bytes (I think KevEdit tells you this). If you're feeling really hardcore, you can pull out the ZZT board format and tally up bytes consumed by the board terrain, board info, and stat entries.

It doesn't save space by itself, but it gives you some perspective, and that can help guide your optimization effort. You can also do it in reverse by setting byte-budgets ahead of time, but that's usually more planning than I care to do. :)

[Saxxon]

Yay code tips. I have just one suggestion for MadTom's guide.

# marks the line as a command. If you are chaining IF statements, I've seen this:

Code: Select all

#IF ALLIGNED #IF ANY RED FAKE #GIVE AMMO 1

Only the first # is necessary. This is a perfectly valid command:

Code: Select all

#IF ALLIGNED IF ANY RED FAKE GIVE AMMO 1

Might save a few bytes when it comes down to the wire.

I might being work on a ZZT optimizer - it is meant to be a post-processing step on a completed world. It would obscure labels and object names that do not display messages, pre-bind all objects that had one-line #BIND command, etc. ZAP had preliminary work on this but it didn't quite reach the level of optimization I wanted.

ZAP is still somewhat broken. I don't suggest using it.

[bitbot]

Great tips fellas!
I tested the game again in Dosbox after weeks of Lyon and man, what a performance hit... but I went in and optimized the loops so all is well. ZZT is handling everything I could throw at it. You can even pickup and throw pots/bushes.

Today's a good day. I came up with a technique to buffer music by removing idles in the beginning of a ZZM, flooding the cache so that it plays across boards without interruption. Sort of like skip protection... it works beautifully.

The thing I have the most trouble with in terms of programming is multiple objects zapping each other multiple times... It makes my head spin. I just discovered #zap touch 1... Can anyone explain how this integer is used?

I might being work on a ZZT optimizer - it is meant to be a post-processing step on a completed world. It would obscure labels and object names that do not display messages, pre-bind all objects that had one-line #BIND command, etc. ZAP had preliminary work on this but it didn't quite reach the level of optimization I wanted.

ZAP is still somewhat broken. I don't suggest using it.

A ZZT optimizer would be great. The board and world limits are pretty respectable.

PC speaker music is actually really coherent but tedious. I love the idea of text becoming music.
I'm tempted to try and develop a full-featured ZZM studio... aren't you like the master musician Sax?

[Saxxon]

Speaking of optimization for speed:

Code: Select all

#cycle 1
#if a go
#restart
:go

Operates exactly the same as

Code: Select all

#cycle 1
#if a go
/i
#restart
:go

OOP will cycle through a maximum of 32 commands IIRC. This means the code at the top is going to max out the commands, while the second one is going to process the condition once. ZZT is an interpreted language so reading through all these bytes takes a lot of time. Since objects are processed in order, this is a great opportunity to optimize for speed. If your game is really slow and there are lots of such loops, try throwing a /i in there.

A #GO or a / command that an object fails will also cause it to use up the 32 commands before it is finished. That's why a /rnd very rarely fails - it runs up to 32 times in random directions until one works.

I wouldn't say I am a 'master musician' but it is blooming into a lucrative side interest :)

[Quantum P.]

Putting idles in loops is very important if you want your code to work well in DOSBox or on a slow computer. I've used both.