z2

What's your overall goal with Lyon?

-=solidfrog=- wrote:What's your overall goal with Lyon?

Lyon is an interface built on top of a library called Roton. Roton aims to emulate ZZT at the core. I'm doing this by way of reverse engineering. The ultimate goal is to create something that will replicate the behavior of both ZZT and Super ZZT, and contain a complete workstation for creating games for them.

Roton contains interfaces for a lot of stuff so you can customize how things appear on screen. Scroll display, message display, sound output, video output, player input, etc.. pretty much anything that can be separated from ZZT without changing what ZZT fundamentally is. Roton won't play sound or draw graphics on its own. It has default built-in interfaces that can be used.

I am creating this black box that handles everything to do with ZZT behind the scenes.

Saxxon wrote:

-=solidfrog=- wrote:What's your overall goal with Lyon?

Lyon is an interface built on top of a library called Roton. Roton aims to emulate ZZT at the core. I'm doing this by way of reverse engineering. The ultimate goal is to create something that will replicate the behavior of both ZZT and Super ZZT, and contain a complete workstation for creating games for them.

Roton contains interfaces for a lot of stuff so you can customize how things appear on screen. Scroll display, message display, sound output, video output, player input, etc.. pretty much anything that can be separated from ZZT without changing what ZZT fundamentally is. Roton won't play sound or draw graphics on its own. It has default built-in interfaces that can be used.

I am creating this black box that handles everything to do with ZZT behind the scenes.

So after you complete this build, do you have plans to expand on it's functionality,
I.e multiplayer support, high(er) resolution graphics, etc.

Your work is incredible and maybe a step forward in preserving ZZT.

-=solidfrog=- wrote:I.e multiplayer support

Nope.

-=solidfrog=- wrote:high(er) resolution graphics

This could happen if a new video interface is coded - the very core of ZZT still operates on 16 colors and 256 characters however. I only implement a standard text mode with variable character height currently.

To add to that, video interfaces are easily swappable. The only thing the video interface gets from Roton is a grid of colors/characters. It's up to the video interface to actually produce a picture.

SolidFrog:

Since a Freebasic port using Roton is possible after it's all finished, more colors like in Freebasic's enhanced/fake Text Mode with more colors than ZZT will allow can be done (see the Graphics function in the Freebasic manual to see what I mean)

It could also support Freebasic's other Graphics Modes, though a bunch of new functions should help

When a world crashes it goes to dos over the existing graphics, with the prompt colors taking the colors of the background, maybe you could have this "emulated". Just an arbitrary(or not) error message, a frozen game and a fake dos prompt that always gives you "bad command or file name"

For another forced crash, look at Fl!msy's Town of ZZT in the Bank of ZZT. DOS doesn't even give an error on this one, nor does it actually go to a command prompt (yet you can still enter text) Lyon does not crash on this board (kill ruffian, then select some scroll options).

Never you mind what I said about window speed, I must have been seeing things. Playing Fl!msy's town showed me that your dialogue box size is about one char thinner on the left than zzt's.

Enjoying Lyon very much, thanks for your wonderful work. It seems to crash though when I try to play a game a second time. Sorry, that's not very clear. What I mean is, I load a game file, press 'P', play for some time, die, or quit (or win?) or whatever, and return to the title screen... then when I press 'P' again I get:

Game: DRZEEBO
Unable to read beyond the end of the stream.
Would you like to see a stack trace?

(Y)

Stack trace:
at System.IO.__Error.EndOfFile()
at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
at System.IO.BinaryReader.ReadInt16()
at Lyon.Roton.File.Load(Stream Source)
at Lyon.Roton.Environment.ExecuteInit()
at Lyon.Roton.Environment.Execute()

If it helps, I'm running Windows 7 64-bit.

Thanks
grim

Is there future plans to have the keyboard for the editor, using tab to draw?

-=solidfrog=- wrote:Is there future plans to have the keyboard for the editor, using tab to draw?

There are plans to make the editor keyboard-friendly and have all the same shortcut keys as ZZT.

Enjoying Lyon very much, thanks for your wonderful work. It seems to crash though when I try to play a game a second time. Sorry, that's not very clear. What I mean is, I load a game file, press 'P', play for some time, die, or quit (or win?) or whatever, and return to the title screen... then when I press 'P' again I get:

Game: DRZEEBO
Unable to read beyond the end of the stream.
Would you like to see a stack trace?

This is the world loader failing. Is the world filename still DRZEEBO? If so, I think I might know what's going on. I plan to release a new build tonight that addresses this issue.

For another forced crash, look at Fl!msy's Town of ZZT in the Bank of ZZT. DOS doesn't even give an error on this one, nor does it actually go to a command prompt (yet you can still enter text) Lyon does not crash on this board (kill ruffian, then select some scroll options).

Never you mind what I said about window speed, I must have been seeing things. Playing Fl!msy's town showed me that your dialogue box size is about one char thinner on the left than zzt's.

Lyon's scroll implementation in the latest uploaded build is broken due to a fix I did. I'll take a look and see if this crashes Lyon in the new build.

Which side is the scroll thin - left or right?

I ordered a Raspberry Pi. Their programming language of choice is Python, which I want to learn to dev on it. It's also been established that PyGame runs fine on it. What does this mean for Lyon? Possibly a port of the whole thing to Python, which would essentially open it up on many other platforms. It's pretty much limited to Windows at the moment.

Once I achieve what I believe to be a "finished" project, I'll begin porting.

The crash in Fl!msy's Town is due to ZZT's limit on scroll size: 4kb is the maximum. The crash generated puts out way more than that (about 19000 bytes). I've implemented this limit now.

I fixed the world re-loading bug, the file extension was missing. Also verified this works with the ZEOL-11/NEWWORLD swap. Note that if you change a world's filename, the name in the file will not change - this will cause read errors like you have seen if you try to play these renamed worlds again.

The scroll is not thin. It is actually shown one tile to the right. I use a mathematical formula to determine the center of the screen - guess that doesn't match up with ZZT. Going to patch that up too. I was using ((ViewWidth \ 2) - (ScrollWidth \ 2)) but that was incorrect, I needed to use (ViewWidth - ScrollWidth) \ 2. This is actually more efficient!

When Lyon crashes, the prompt now asks you if you would like the stack trace put in your clipboard. This should make it a lot easier to report problems.

Here you go. This should work nicely. I won't emulate that bug in Fl!msy Town because of the way it works. When you open "con", that is handled specially by Pascal. I don't think it's really used in any game to great effect ;)

I just realized something - when testing with other worlds, ZZT is capable of displaying scrolls over 4kb. In fact I'm sure some legitimate games use over this in some scrolls. What I did find however was that when ZZT tries to free memory over 32kb, the engine does strange things.

If you downloaded the Lyon link above, grab it again since this was just a minor update :)

I made a little video of the work in progress for my youtube account (advertising campaign). Right now it's private in case you have reservations, viewable through this link only but just give me the OK and I'll make it public.

http://youtu.be/V256p-5xy30

That is pretty cool, Commodore :) Go ahead and make public. It's cool to see this stuff in action, despite it being unrealistic that anyone will be running more than 1 game at a time (although a concurrent game/edit session wouldn't be unheard of)