z2

nuero wrote:you'll also find that that joke is obvious and not funny

that's like being funny like "hey funky knock knock" "who's there" "amber" "amber who" "a million hamburgers for you to eat because you're so god damn fat"

lol

:emo:

Also, really that was really funny. I was crying from laughing and this is not sarcasm. The boys at school liked it too.

funky gives it to his boys

Revvy wrote:funky gives it to his boys

:sex:

\m/

Nuero is too funny for his own good

I toke this little thingy home to my old computer (it's the one I mainly run anything that's ZZT, or angband) and to my shock...

RUNTIME 202 093:3595 from some stange reason when I ran tour to test it, and...
RUNTIME 203 0B40:1B42 from files over 300k instead of 360k?!:slavedriver:

...and it had a stroke when I transport a board into it.

it's suck'n and that's sad.

anyway yes. that release turned out ot be buggier than i anticipated. i fixed it though, 4.1 that i'm building now appears to not crash when you run tour, also you can have 63.5k board instead of 32k, also transporting boards is not messed up. I started with zzt 3.2 again and totally redid all the changes i did before, since i must have changed something that led to the other crashes that i wasnt' aware of. I may release a 50k or so exe so it won't be smaller than the other exe, but you might have better luck loading bigger files. The file size thing is gonna be a problem until I can get XMS memory working.

wil, i hope you're using a disassembler in addition to your hex editor.

i have my doubts about getting xms working through editing the executable directly. you'd have to pretty much completely rewrite some functions, and zzt running in real mode doesn't help much either.

something that could work is converting the disassembly back to pascal (not too difficult, but it would take ages). i started doing this a while ago, but lost interest after doing the music, control & video modules, plus a small part of the window module. i have no doubt that you could stay interested long enough to finish that. :p

once you have the pascal code you could use something like freepascal to compile it natively for windows, and have all the memory you could ever want.

Woah, woah, where'd you come from?! I inquired about you, like, 3 or 4 months ago and suddenly you show up? Where have you been all this time?! Also, hi. Pleasure to meet you (I hope).

shutup.

that is directed to no one in particular.

By "no one in particular" you mean Jazzy, right

Realizing that I wasn't going to get anywhere with trying to hex-edit the executable, especially since there isn't any way to increase XMS memory, for the past while I have redirected my efforts to a remake of ZZT, with a slick editor and including backwards compatibilty with ZZT files in both playback and editing. This remake has been called PLASTIC, and a release candidate has been uploaded to http://plastic.daveanddave.net so that all may have a look. I have made a quick demo of a sort of capture-the-flag game there. Some more information about plastic and ZZT is to follow in another post, but maybe in a few hours when i'm not so busy.

Seems grand!

Oh, it is DAMN grand.

That's a nice start! It seems to emulate ZZT very well, but I did notice that the speed is inconsistant with that of ZZT (Burger Joint is virtually impossible on the default speed on my Athlon XP 2200+-powered lappy) and the palette is a bit off (though that seems like a cmd.exe issue). The drum hits (#play "notes" 0-2 and 4-9) are held for too long.

But holy cow, this is the closest thing we've seen to a true ZZT clone in years! VERY fine work -- I'm very interested in seeing how this project turns out.

Edit: To make sure that the palette and character set stays consistant between different systems (and give PLASTIC/ZZT games built-in character/palette editing abilities) why not utilize text mode emulation (via SDL) like what the 32-bit port of MegaZeux uses? It would take a bit more work to implement but would probably be better in the end.

Also, I was kind of wondering how PLASTIC is going to handle some of ZZT's oddities, such as changing the cycle of the player or making constructs such as diagonal blinkwalls. I, admittedly, haven't played too much with the editor, but those are kind of exotic behaviors as far as ZZT is concerned.

The speed of ZZT can be emulated fairly well by taking the speed down one notch in the title screen. The natural speed of plastic is 12.5 frames per second, and by takign it down one notch you adjust it to the natural ZZT speed of 10 frames/sec.

The drum notes are emulated ZZM style because we felt they were more versatile than the original ZZT indistinguishable ticks.

In the distribution zip for plastic, there should be a registry key (plastic.reg) that fixes the pallette for your C:\plastic\plastic.exe file. Because this uses the native Windows console, the colors are going to be the default Windows text colors unless specifically changed. At the moment, the plastic.reg file does this. Just create the directory C:\plastic, put your plastic data in that directory, and run the plastic.reg file. The colors should be set to proper colors, including a nice grey, dark grey and brown.

(I am supposing to myself as I'm writing this that you can in fact alter the pallette and create your own custom pallettes for games by distributing your own .reg files with differnt data, and people can run plastic.reg to return their colors to their original state. At the moment I'm not going to
think too much about it, though.)

Plastic is more flexible where the player is concerned. As I continue to expand documentation, More information will be available concerning the player and, particularly, the playerthink command, custom code which can be inserted into the player object. We're going to be developing small tutorial files to explain how this works, as well as updating the existing .HLP documentation, much of which is still just adaptations of the current ZZT docs out there.

Concerning other exotic behaviour, there are certain hacky things in ZZT (player clones and board edges for example) which, while we as ZZTers understand them, are not intuitive and have been made obselete by the advent of key input. Since the goal is to capture the spirit of simplicity and accessibility that ZZT is all about, these hackier elements are not supported. Diagonal blinkwalls are an excellent example of a construct that we have chosen not to support.

Hopefully that clears up a few things. There's a lot of new documentation and plenty to be gained by just fooling around with different ZZT games. Also, you can look in LOGIC.HLP for key input information. I think I'm going to make that other post now.