Lyon

[bitbot]

This is absolutely incredible guys! Keep up the good work.
I wanna try but it doesn't work for me :(

The application failed to initialize properly (0xc0000135)

[-=solidfrog=-]

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

How the heck did you do some of those scrolling screens? I'm honestly shocked and amazed.

I think you guys are on the brink of something amazing

-=solidfrog=-

[Saxxon]

This is absolutely incredible guys! Keep up the good work.
I wanna try but it doesn't work for me :(

The application failed to initialize properly (0xc0000135)

You will need to install the .NET framework. Lyon requires 2.0 at least.
http://www.microsoft.com/download/en/details.aspx?id=19

How the heck did you do some of those scrolling screens? I'm honestly shocked and amazed.

I think you guys are on the brink of something amazing

-=solidfrog=-

The scrolling screens are SuperZZT. That engine has boards that are 96x80 scrolled with wide characters.

[-=solidfrog=-]

This is absolutely incredible guys! Keep up the good work.
I wanna try but it doesn't work for me :(

The application failed to initialize properly (0xc0000135)

You will need to install the .NET framework. Lyon requires 2.0 at least.
http://www.microsoft.com/download/en/details.aspx?id=19

How the heck did you do some of those scrolling screens? I'm honestly shocked and amazed.

I think you guys are on the brink of something amazing

-=solidfrog=-

The scrolling screens are SuperZZT. That engine has boards that are 96x80 scrolled with wide characters.

Oh haha. I never used super zzt. I didn't think it was very popular. But maybe I should check it out.

[Saxxon]

It isn't :) But that's mainly because you see far less of the game board and the editor was super buggy.

Even the code is full of weird hacks. Dragon Pups don't really do anything but sit there and Pairers have zero code (they aren't even found in any of the official worlds)

[Commodore]

Also despite larger boards, SZZT has stricter memory limitations. I imagine these limitations wouldn't exist in Lyon, of course it's meant to be accurate, i.e. the scroll limit crash (but really, who wants to read more than 4k of scroll?) So I assume if these limitation were eliminated, it that it would be the only point of incompatibility between Lyon worlds and ZZT worlds, since otherwise it's not an extension.

Being a C64 nerd, I'm sort of biased to original software on original hardware, but that's a little unrealistic for zzt. So lyon is definitely (already) the future. The future is now!

[Saxxon]

The technical explanation is that ZZT builds a string using Pascal routines. 4kb is guaranteed to ZZT, the rest is allocated as needed. If ZZT requests more than available, it will crash. Pascal can handle string lengths longer than 32k. When the scroll is closed, ZZT tries to free that memory. However, it uses a signed short int to keep track of the number of bytes to be freed. If the scroll is over 32kb, ZZT requests that Pascal free a negative amount of memory. This causes the game to freak out. But this is why a long scroll can be shown, and crashes only when it is closed.

I could see why forced runtime errors would be desired - anticheat mechanism for example. Some runtime errors are due to the way the code is written (for example a Push function with zero vector calls itself until stack overflow). I want to implement the ones from bugs in ZZT itself, but I'm really on the fence about memory limits. Personally, I would prefer not to put in hard memory limits. The scroll size is one exception I'm willing to make due to it being a desired runtime error in certain situations.

[Saxxon]

I think it's time to start working on more cosmetic stuff. Blinks are really overdue. I may consider the option of switching between blinks and full color mode.

Help file support is in. ZZT.DAT will be embedded within the executable.

[Commodore]

Stars can be thrown through walls. To reproduce surround an object with walls and make it #throwstar n. It seems to be limited to real directions and not "seek."

I know you are reworking the editor, but a game window does not properly regain focus when you click on the editor first (which does not come to the front when you click on it) In a session where I was switching between worlds and editor, somehow I lost the ability to save: the menu option was grey.

I was thinking about the editor. I'm thinking a cursor controlled by both mouse and keyboard, capable of moving into the sidebar to select things. It would mean locking the mouse to the current window, but I think it could be easily released with ESC and/or a button. With a clickable side bar, it should have a further menu to cover things a deeper editor does with keyboard shortcuts. (highlight all objects, modify stats, object list), but I still ought to be able to push "f2 B" to make a bear. The color selector ("k" in kevedit) is awesome but with mouse control might not be necessary. And shift-left click should erase, not right click. (left-click:space, right click: enter)

[Saxxon]

Good catch on the stars. I will investigate. Bullets and stars share the same spawn code so bullets may be affected as well. Directions shouldn't matter since all directions are translated into a vector before spawning takes place. If you have a ZZT file that reproduces this, please attach it.

The editor in its current state is pretty much abandoned; I am using it to test certain cases in ZZT but ultimately it is going to get redone. I am saving this for last as there are other excellent editors that can do the work for now. I do plan to keep the same keyboard shortcuts as ZZT (maybe KevEdit too) but expand on it with mouse functionality. Thanks for the suggestions though :)

[bitbot]

I've got a few suggestions from an end-user perspective but here's a couple issues:

There seems to be a bottleneck in audio/video output. (quality is good though)
Maybe support overlay for anything above 1:1/fullscreen?
#change fake monitor produces a crash.
(I use these hidden fakes to lock the player throughout the game)

I can keep you posted on others as I'd like to ensure Lyon compatibility for my game.
This is a very ambitious project, and you're making great progress!

[Saxxon]

There seems to be a bottleneck in audio/video output. (quality is good though)

What kind of bottleneck? If you're talking about performance, video is output using .NET GDI+ so naturally it's going to suffer until I get DirectDraw implemented. DirectSound is already in, that was the easy part :)

Maybe support overlay for anything above 1:1/fullscreen?

I don't really follow..

#change fake monitor produces a crash.

Will investigate this one.

[bitbot]

Maybe support overlay for anything above 1:1/fullscreen?

I don't really follow..

Excuse me. Direct draw performs moderately well and preserves the pixels, but could Overlay speedup scaling and fullscreen?
Compare performance with ZZTBOX in the upload folder... Two video modes are in that config file (fastest/accurate)

My suggestion is that an option B video mode may be beneficial. :)

[Saxxon]

I had to look at the DOSBox source to know what you were talking about - SDL, specifically.

Surface and Overlay both use GDI. This is a little different than GDI+ which is built into the .NET framework. Essentially, I am currently using an equivalent to Overlay. I read somewhere that GDI isn't hardware accelerated in Vista and later, so this could cause some performance issues.

Implementing DirectDraw would be hardware accelerated on all platforms and would be the ideal video interface for Roton. I still need to provide the GDI+ one for compatibility however.

[Commodore]

Just a quick thought I had about an editor was that you could make toolkits useful again if you allowed the buffer to carry over or could somehow link buffers between open editor windows.