Tyger

Post by **Dr. Dos** » Sun Feb 28, 2010 8:48 pm

Jasc animation studio. It's shareware!

I just have a record variable in Tyger to capture every frame to a screenshot and then use that to make a gif out of it.

Also I fixed a bunch of little timing bugs and things and now was actually almost able to finish the first board of Burger Joint, being stopped only when the bathroom door to the passage to the next board couldn't do anything since #put doesn't work yet.

Post by **Zenith Nadir** » Mon Mar 01, 2010 10:36 am

Dr. Dos wrote:

>:O

Post by **Dr. Dos** » Sun Mar 21, 2010 2:05 am

I'm starting to work on #become, since once I get that working it's not much of a stretch to apply it to #change and #put.

Now I need to make lists of everything's default color and also handle stats properly.

Post by **zamros** » Sun Mar 21, 2010 3:42 am

you should rename Tyger to "Def Cyan Lion"

Post by **Zenith Nadir** » Tue Mar 23, 2010 2:26 pm

so types like ammo and torches aren't bound to specific colours anymore? sweet

you should probably make it so "#become ammo" and "#become torch" default to teal/brown, though, a lot of programming tricks rely on it (ditto energizers, sharks, etc)

also i've been meaning to ask, is the 20kb per board/~300kb per .zzt file limit still a thing in tyger?

Commodore · Post by **Commodore** » Tue Mar 23, 2010 5:16 pm

wouldn't make much sense, I don't think size limits can be used for any crazy programming tricks. it would only be important if you wanted to use the tyger editor for making worlds that run in zzt. then maybe an option to check the world for zzt compatibility (catches extended code commands and checks file/board size)

I like the use of any to randomise things.

how about #become ammo or torch to have a 50/50 shot of getting one of them?

Post by **Dr. Dos** » Tue Mar 23, 2010 9:34 pm

Zenith Nadir wrote:you should probably make it so "#become ammo" and "#become torch" default to teal/brown, though, a lot of programming tricks rely on it (ditto energizers, sharks, etc)

They will! The reason there's so much red in that example is that I have "bright red on dark red" for the default colors in case you throw an invalid color at it. Since it's only partially done some things aren't yet valid colors.

also i've been meaning to ask, is the 20kb per board/~300kb per .zzt file limit still a thing in tyger?

Board size limit will be 64kb since ZZT uses two-bytes to store board size and I don't want to break the world format. I think the ~300kb is just a result of how much memory ZZT lets itself access so there should be no limit to the size of a world.

For some reason ZZT uses 2 bytes for the number of boards so you can have 60,000 boards in a world which is probably enough to make every ZZT game ever in a single file.

Commodore wrote:wouldn't make much sense, I don't think size limits can be used for any crazy programming tricks. it would only be important if you wanted to use the tyger editor for making worlds that run in zzt. then maybe an option to check the world for zzt compatibility (catches extended code commands and checks file/board size)

As it stands right now I don't have solid plans for an editor. Kev-edit and ZZT (and I'd assume ZAP and ZZTAE) do cap the number of stats on a board so I've considered messing around with HTML5's Canvas tag to make an editor with it and Javascript.

A good example of how awesome <Canvas> is can be seen here: http://www.chromeexperiments.com/detail ... -world-js/ It runs much better in Chrome than Firefox but something as simple as a ZZT editor would be no issue.

As for checking for if a ZZT file can only be played properly in Tyger you can easily do with with flags since there is no limit in Tyger as to how many can be set.

On the first board set 11 different flags and then check that they are all set. If they are Tyger, if not ZZT.

I like the use of any to randomise things.

"Any" in this case isn't used to mean "any random color" but "any color used by this tile right now". You'll notice the white on dark purple object became white on dark purple ammo with "any any". "any" takes on the color of the tile like how you can #put dir gem and depending on what's already there will determine the gem's color. Though using "rnd" for a random color might be worth adding.

The other non-color color is "def" which is default. If you don't specify a color it will use default and look up with colors to use. This is what I'm currently working on now. #become ruffian gets interpreted as #become def def ruffian (or DDR for short). It will (eventually) look up what color is associated with ruffians for the foreground and background (in this case purple and black). This is so you can specify just background color if you wanted to with #become def color thing.

Default colors can also link to "any" which is why #putting a gem without specifying a color would properly have the gem take on that tile's colors.

how about #become ammo or torch to have a 50/50 shot of getting one of them?

I don't really see the use of that in the case of #become/#change/#put, but it might have purpose for #give to simplify making a random treasure chest.

One other issue with Tyger's extended oop and no current editor is long lines of code. If you manually hex edit a zzt file you can have commands that are more than ~40 characters and it would be nice to be able to do this without one.

#if any dyellow dpurple invisible #change dyellow dpurple invisible dpurple dyellow energizer

should be a valid Tyger command, but has no chance of fitting.

Basically new ZZT-oop should either

- Make tedious and difficult ZZT engines simpler such as plans for me allowing the "i" key to instantly #set i to make inventory games play much more smoothly or having torches automatically light in dark rooms so you don't have to stop and hit T in the middle of a dungeon exploration game

- Make things that just barely can't be done in ZZT be done such as a #copycode command that works like #bind but doesn't share labels.

Commodore · Post by **Commodore** » Tue Mar 23, 2010 10:52 pm

there are source codes for both kevedit and zap, maybe a tyger-flavor editor is not far off.

Post by **clecky** » Thu Mar 25, 2010 10:23 pm

hey, just popped in to say good job Dos! keep yiffin' in the free world.

Post by **Dr. Dos** » Thu Mar 25, 2010 11:24 pm

clecky wrote:hey, just popped in to say good job Dos! keep yiffin' in the free world.

Oh wow it is Clecky.

:whole:

Post by **zamros** » Fri Mar 26, 2010 3:21 am

CLICKY!!!! I MISS YOU

Aplsos · Post by **Aplsos** » Fri Mar 26, 2010 4:09 am

there is a clecky-shaped hole in the heart of each and every one of us.

Post by **clecky** » Fri Mar 26, 2010 11:54 am

Zaphod Zaphod Zaphod love

Post by **Dr. Dos** » Fri Mar 26, 2010 11:24 pm

Killing some time for a bit before I start playing TF2 I added a few tiny features of convenience.

- Sticky Clones toggle, allowing you to make it so that player clones can touch objects, shoot, and go through passages but not cause the player to warp to their position.

- Proper Double Resolution, no smoothed pixels which look awful with ZZT.

- Point Blank Shooting toggle allowing you to never again be pinned by objects in a corner that you can't shoot without room to spawn a bullet normally.

Post by **Zenith Nadir** » Sat Mar 27, 2010 11:50 am

Dr. Dos wrote:Killing some time for a bit before I start playing TF2 I added a few tiny features of convenience.

- Sticky Clones toggle, allowing you to make it so that player clones can touch objects, shoot, and go through passages but not cause the player to warp to their position.

- Proper Double Resolution, no smoothed pixels which look awful with ZZT.

- Point Blank Shooting toggle allowing you to never again be pinned by objects in a corner that you can't shoot without room to spawn a bullet normally.

HELL yes

does the passage/duplicator instant teleport hack work? i forget if you mentioned this but if not i'm asking again.

also, would it be possible for you to make it so spawning the player in a new board does not mess with any fake walls beneath it. i'm sure it is. possible