LINK II

Housing for low income families.

Moderators: nuero, Ando

User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by bitbot »

Commodore wrote: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.
XD
Image Image
User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by bitbot »

It wouldn't be LINK without a platform level.
sidedung.gif
sidedung.gif (8.56 KiB) Viewed 12034 times
Commodore: This might be tricky in a Pharaoh's Tomb sort of environment.
Image Image
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Re: LINK II ZZT

Post by Dr. Dos »

http://www.i-mockery.com/romhacks/pimpdaddylink/ This is what we'll actually be getting.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by bitbot »

You're always good for a laugh, Doc.

I was thinking about putting a block of Lyons here just for you.
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: LINK II ZZT

Post by Quantum P. »

Very nice screenshot! I especially like the torch and bricks.
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: LINK II ZZT

Post by Saxxon »

Quantum P. wrote:Very nice screenshot! I especially like the torch and bricks.
YES. The art is looking fantastic.
User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by bitbot »

Saxxon wrote:
Quantum P. wrote: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
Image Image
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Re: LINK II ZZT

Post by 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.
*POW* *CLANK* *PING*
User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by bitbot »

Commodore wrote: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.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Re: LINK II ZZT

Post by 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
*POW* *CLANK* *PING*
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: LINK II ZZT

Post by 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. :)
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: LINK II ZZT

Post by 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.
User avatar
bitbot
Official Clamp School Defender
Posts: 328
Joined: Thu Mar 01, 2012 3:00 am
Location: earthbound
Contact:

Re: LINK II ZZT

Post by 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?
Saxxon wrote: 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?
Image Image
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: LINK II ZZT

Post by 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 :)
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: LINK II ZZT

Post by 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.
Post Reply