Haha. It's in the little things... instead of a Sleepy Toadstool or a Wake-up Mushroom you simply get a magic mushroom. etc.Commodore wrote:Link II: Link's X-Rated Adventure
LINK II
- bitbot
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
- bitbot
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
It wouldn't be LINK without a platform level.
Commodore: This might be tricky in a Pharaoh's Tomb sort of environment.
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
Re: LINK II ZZT
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.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
- bitbot
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
You're always good for a laugh, Doc.
I was thinking about putting a block of Lyons here just for you.
I was thinking about putting a block of Lyons here just for you.
- Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
Re: LINK II ZZT
Very nice screenshot! I especially like the torch and bricks.
Re: LINK II ZZT
YES. The art is looking fantastic.Quantum P. wrote:Very nice screenshot! I especially like the torch and bricks.
- bitbot
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
Thanks. I'm just copying Zelda. There's these moments where I keep it true to ZZT. That's what makes it interesting.Saxxon wrote:YES. The art is looking fantastic.Quantum P. wrote:Very nice screenshot! I especially like the torch and bricks.
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
Re: LINK II ZZT
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*
- bitbot
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
The only lack of memory is in my head. I hope to overcome this writer's block.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.
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.
Re: LINK II ZZT
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
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*
- Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
Re: LINK II ZZT
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:
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. :)
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. :)
Re: LINK II ZZT
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:
Only the first # is necessary. This is a perfectly valid command:
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.
# 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
Code: Select all
#IF ALLIGNED IF ANY RED FAKE GIVE AMMO 1
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
- Official Clamp School Defender
- Posts: 328
- Joined: Thu Mar 01, 2012 3:00 am
- Location: earthbound
- Contact:
Re: LINK II ZZT
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?
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?
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?
A ZZT optimizer would be great. The board and world limits are pretty respectable.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.
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?
Re: LINK II ZZT
Speaking of optimization for speed:
Operates exactly the same as
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 :)
Code: Select all
#cycle 1
#if a go
#restart
:go
Code: Select all
#cycle 1
#if a go
/i
#restart
:go
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.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
Re: LINK II ZZT
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.