z2

do you want Tyger to be compatible with actual ZZT games

town has centipedes

get back to work

if you wanted to cut corners I don't think you'd get much complaints if you just turned all the segments into heads.

but that would make "warlord's temple" fundamentally broken

If Infestation isn't playable what's the point

I'm hearing implications that there is a ZZT game called "Infestation"

I am intrigued and wish to learn more

Also Tim Sweeney got centipedes to work when he made ZZT back in 1991, why is it so hard now

Now much smaller due to me discovering py2exe was including lots of things it really didn't need. (Unless I am wrong)

January 1

Tyger Specific
+ Game changed to run at 10 frames per second. This is slightly faster than ZZT usually runs but makes the timing more accurate as the ~9.1 fps rate would lead to cycles being dropped.
+ Grabbing an energizer on a board without a time limit will make the minimal HUD show the time left on your energizer instead.

Graphics
+ Support for custom graphics and palettes correctly implemented and very poorly.

ZZT Support
+ The player can now die. The game also speeds up as if everything was cycle 1 and attempts to run the game at 10 times the current framerate limit.
+ Ricochets are fully implemented.
+ Water fully implemented.
+ Boulders and sliders are implemented.
+ Pushers implemented.
+ Bombs implemented.
+ Energizers implemented.
+ Basic cheating implemented. You'll have to launch Tyger from a console to use it.
+ Dark boards implemented. Torches half implemented. The player emits light regardless of having any torches in a dark room.

ZZT-OOP Support
+ #Char implemented
+ #Clear works
+ #Cycle not perfectly implemented
+ #Die works
+ #End works
+ #Endgame works
+ #Give works
+ #Lock works
+ #Unlock works
+ :touch works but I spent little time on it so I wouldn't be surprised if I didn't consider something. For example I just realized if you included the phrase ":touch" in a message tyger would jump to that! Basically what I am getting at here is that ZZT-OOP support is very error prone.
+ Messages will be displayed in a console window for now.

+ Additional support has been added to the #give command. These lines are ignored in ZZT and will not give errors.
+ #give seconds <number> will add <number> seconds to the timer as opposed to ZZT's #giving of time causing the time to approach zero.
+ #give key <color> will immediately add one of the 8 (black counts) keys to the player. Note that black keys do not show up on the HUD so the player will not know he has been given this key if not alerted.
+ #give light <number> will add <number> torch cycles to the counter. This can easily be looped for an infinite torch.
+ #give energizer will immeditately make the player invincible as if he just touched an energizer.
+ #give invuln <number> will give <number> cycles of invincibility for custom length energizers.

Known Issues

+ Pushing things with stats has issues when you are pushing diagonally or multiple spaces at a time with tweaked X/Y-steps.

Source: http://zzt.org/dr_dos/tyger/Tyger5src.zip (38k)
Binary: http://zzt.org/dr_dos/tyger/TygerComp5.zip (7MB)

If you run this at all I HIGHLY recommend that you do through a terminal as until I implement proper messages everything gets output into said window.

Oh and on that note I still have left click instantly close the program, I really should get rid of that since in order to cheat you have to click into the terminal, type the cheat, then click Tyger to give it focus. Click on the title bar and it won't exit.

Haha guys did you know

#go north
#go south
#go east
#go west
#go idle

are all valid commands?

The best part is if you #go idle, the object sees it is blocked by its own existence so it will never move on in its code

That bit about #go idle is crazy, especially because it means that / is not equivalent to #go. I mean, wouldn't it be easier just to reuse the same movement code?

The original ZZT source code must have been something horrific.

You know what else is a valid command?

#idle which works like /i

maybe it has to do with the way you can send messages with #try but not ?

At this rate, it might just be easier to standardize and make everything work, and then go back and have an option for specific ZZT un-fixes (like hard-coding it to check if you're trying to #go idle and make it specifically not work or something) for legacy/compatibility/faithfulness/whatever.

Scaling is easy, but ASCII was not meant for it.

Looks good to me, but then again, you know I like pixels, hence all my blown-up pixelated LJ icons and the fact that I yelled at you for applying all those weird NES emulator filters that make it look like a freaky flash game instead of pixels the way God intended them.

Which reminds me, the main screen here looks good but the HUD at the bottom is way too smooth, needs more hard pixeling options.

Edit: wait, do those solids have rounded corners? What is this, I take it back, I object.

EMULATOR FILTERS?

pygame.transform.scale2x

specialized image doubler
pygame.transform.scale2x(Surface, DestSurface = None): Surface

This will return a new image that is double the size of the original. It uses the AdvanceMAME Scale2X algorithm which does a 'jaggie-less' scale of bitmap graphics.

This really only has an effect on simple images with solid colors. On photographic and antialiased images it will look like a regular unfiltered scale.

An optional destination surface can be used, rather than have it create a new one. This is quicker if you want to repeatedly scale something. However the destination must be twice the size of the source surface passed in. Also the destination surface must be the same format.

But I like jaggies.

I think. Maybe I'm thinking of the wrong thing. Your post is a bit technical and you kind of lost me.