z2

Found a bug already. #zap target:label will zap it for every object, not once per matching code. Doh. Going to patch up and upload tonight. This should fix Burger Joint.

Uploaded build 3. Changed timing a little. You can now hide both the status bar (which is hidden by default) and the menu bar. Fixed a freeze when a player clone attempts to use a board edge and is unsuccessful. "#zap target:label" only zaps the label only once per code (bound objects will not zap these labels multiple times anymore).

- Target .NET framework changed from 4.0 to 2.0. This should not affect performance. This will simply enable older OSes to run Lyon and increase compatibility with non-windows .NET software like Mono.
- FORCED and FREE from ZEOL should work. Anything that uses a game mechanic that would take the player to another board from the title screen will now start the game properly.
- When scrolls are displayed you can now scroll very quickly regardless of game speed.

are you going to make scrolls scroll open? a minor detail.

I'll have time to give it a good work over sunday to hunt for bugs.

_________________
*POW* *CLANK* *PING*

I suppose I could make scrolls open just for the aesthetic value alone :)

- Working on adding sound. I've tried the .NET managed sound playback routine and the PlaySound API. Both of them sound exactly the same, and before any drums or new notes get played there is a delay. I don't know much about waveOut but I may end up having to do all the sound processing myself. Either that or I'll try using an external library like BASS.
- Another timing change, this should make the game speed scale a lot different - max speed (0) is 64 frames/sec, standard speed (4) is 9.1 frames/sec, and highest setting (8) is 4.05 frames/sec. The standard speed should be very close to ZZT. Max speed makes Angelis a lot more fun to play (but I don't know if it was intended to work even faster)

I have had different experiences with max speed and angelis on different setups. Angelis uses a trick where a blank message is constantly sent to artificially retard the speed a step below the max, which was too fast iirc.

_________________
*POW* *CLANK* *PING*

ZZT's internal tick counter wraps around at 420. That would be a multiple of a lot of numbers (1-7 at least) for cycle values that ZZT uses in its built-in objects. It has to be above 255 because otherwise objects with cycles over this value would have a chance to never execute at all. 2*3*5*7=210 is half of the value used, the first four primes.

ZEOL-1 "Wipeout/Color Flashes" leaves a bunch of statless lions and I am really puzzled as to why. Same pattern every time too. And lions aren't even in the code of anything on the board!

EDIT: I fixed that lion bug. In ZEOL-1 on the color flashes board there are stat empties with under-elements as lions. When trying to #CHANGE them, there was a bug in SpawnThing. Fixed that one, might fix other problems when creating stat objects using OOP.

ZEOL-1's "activated fades" will not work well because the screen is not updated as it is changed. It is updated after all stats have executed. There isn't a /I in between the #CHANGE commands.

Decided to use DirectSound for sfx and music playback. It seems to work well. Because of the small size of the drum sounds, the sound driver was putting up a fit, so I had to force software mixing. It doesn't like sampling higher than 192khz (I am using a 44khz wave for the base octave so that's not terribly hard to reach.) Might consider sampling the waveforms for each octave so they sound somewhat crisp and don't kill the renderer.

Edit: It sounds a lot better with one waveform per octave (for a total of 7). I don't think that 7th one is used though. Tested with #PLAY v5 and the songs all sound correct.

Going to wrap up what I've got and put out Release 4 either tonight or tomorrow.

ZZT has only so much memory set aside for #PLAY commands, but that is a limitation of the way the original game was written. I haven't decided whether or not #PLAY commands should be removed if there are too many. Lyon does not currently impose a limit.

Build 4 uploaded. Should have fully working sound and music. Both are individually controllable, so you can turn off built-in sounds and/or music if you want. Changed framework to 2.0, this should enable you to use it on Windows machines as early as 98 if you have the .NET framework installed. Music and the game are on separate timers so game speed will not affect music playback, but on standard speed it *should* sync just like the original game. The built-in sounds don't have exactly the same priority as the original game, if there's more feedback I will certainly fix the sound errors. Music and sound effects won't perfectly be quantized because of how DirectSound buffers work, and I don't really feel like coding my own mixer.

Tested with about half of the #PLAY v5 world, sounds good to me. If you get any errors when loading a world that cause the game to crash, it's probably the sound engine, and I need to know if it works well on everyone's machine before making it final. Any other sound engine would involve messing a lot more with the Windows API, and so far, I've been good about avoiding P/Invoke calls (at this time, there are ZERO). Portability is kept in mind (but definitely not the main focus here).

Commodore, scrolls don't roll open just yet but maybe later :)

daymare uses #/w and similar movement commands which are not recognized by lyon.

It doesn't display ammo on #take ammo

I'm missing how to change the speed.

_________________
*POW* *CLANK* *PING*

Going to grab Daymare now.

The only notifications are health changes (+/-) and torches (- only). I could make them customizable and add ammo as well.

To change the speed, use / and * on the numpad for faster and slower, respectively.

Edit: Uhh, wow. The coding in that game is pretty nasty. Some of it doesn't even work in ZZT.

At this point I think the project is getting pretty close to the original game. I want to take what's there and refine it. This won't change anything cosmetically, but it will have a large impact on performance and future code.

In my opinion, Lyon's code could be better written. Originally, I just tried to imitate the functions from the original game. While it does a great job of simulating the experience, it takes away from good code structure. I'm going to spend a while refactoring. The behavior code will be separated from Board. The boards will be separated from World. All game processing will be done in a GameContext. The sound playback code will be separate from World (in regards to how it's actually played via DirectSound). The ASCII grid will be separate from the display code so that graphics updates can be controlled more precisely with the board behavior. I want to keep the in-game text as bytes instead of converting to string so I don't lose anything when .NET wants to convert everything to unicode.

I need all this to be done before I start integrating an editor. I also need all this done if I ever plan to continue adding features that don't pertain specifically to ZZT's behavior (better notifications and status window, etc).

Lots of changes ahead. I know what I'm in for and know fully what's required to do it. Since it will take hours of sifting through code, there probably won't be any builds until after Wednesday next week.

Storage has been decoupled from what's being stored. This opens up the possibility to support more formats and even direct ZIP archive access in the near future. The game only sees elements, it does not see ID#. This makes the code easier to unify. Additionally, I have an extended format ready that supports all ZZT and Super ZZT elements, plus metadata (optional). This extended format is for debugging purposes, although eventually it may become something you can load and save (format identifier FD FF, following numbers that ZZT and Super ZZT used).

Lyon's base code is being separated from its UI code. I plan on making Lyon's code into a .NET class library which can be referenced by any other .NET code (VB, C#, maybe even ASP, who knows). The UI will still be developed, it'll just demonstrate what can be done with the class library. On top of that, it will also allow me to develop an editor completely separately from the game, without risking breaking either the game or the editor by any changes.

That's nice,

Ever since I rediscovered EZZT, I was going to make a format based off both MZX, ZZT and SZZT using it, But I may use the newer format you suggested!