Lyon

[bitbot]

Hey Saxxon! How about a debug option that displays the flags? This would be a big help.

[Saxxon]

Hey Saxxon! How about a debug option that displays the flags? This would be a big help.

Definitely useful. I'm thinking about doing a toggle on-screen for it, that way you can look at multiple games' flags if needed.

[bitbot]

Hey Saxxon! How about a debug option that displays the flags? This would be a big help.

Definitely useful. I'm thinking about doing a toggle on-screen for it, that way you can look at multiple games' flags if needed.

Sounds good. I can't seem to plug this memory leak. I'll put it aside for now...
Hope it won't be too much trouble. Thanks.

Edit: Okay, I fixed my flag issue but it only works in dosbox. It seems that Lyon has a problem after 5 flags and a 400k world. Otherwise, it's pretty stable.

[Saxxon]

Edit: Okay, I fixed my flag issue but it only works in dosbox. It seems that Lyon has a problem after 5 flags and a 400k world. Otherwise, it's pretty stable.

What kind of issues do you run into?

[bitbot]

Thanks, I fixed the issue on my end.
The memory leak was not specific to Lyon. It was sporadic, so it took a while to pinpoint.

I completed my project and after thorough testing, I can say that Lyon is a remarkable piece of work. Way to go!

[Saxxon]

I completed my project and after thorough testing, I can say that Lyon is a remarkable piece of work. Way to go!

Thanks :) I'm still reworking how OOP is stored so that #zap target:label works like it does in ZZT. Almost there..

OOP is loaded and a pointer is assigned. ZZT has its own garbage collection mechanism- whenever an object is deleted, it checks all other objects to see if the code is referenced. If it is not, it is removed from memory. When an object binds another object, it just copies this pointer and the length is set to the code's length. This proves that how the board is stored on disk is NOT how it is stored in memory- which is what Lyon is doing now (albeit its behavior is really close).

I'm separating Lyon and Roton in the binary now. Future distributions of Lyon will have Roton.dll. This should make it easier for me to develop other utilities that share code. I'm also doing this because I am developing the editor separately from Lyon. When the time comes, I might integrate them together.

[Saxxon]

Still have a known issue with #ZAP TARGET:LABEL and #RESTORE TARGET:LABEL. But here's the latest I've got so far. Some of the OOP stuff needs work. But overall I think the way it handles object deletion is a lot more accurate.

As usual, please let me know if you find any bugs.

[Commodore]

I got hit by a centipede head playing link's adventure (older) and was given this short clipboard dump.

System.IndexOutOfRangeException
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()

The super fast blinkwalls in the room before that (4th board into the game) do not appear, even though they seem to work properly. Also, after you adjust the speed to superspeed, normal speed settings seem accelerated.

[Saxxon]

Bah, the dumps are going to be missing a lot of information because of the doubly-thrown exception. Oh well. Looking into it.

The superfast blink walls will be missing because of how they work. What a blink wall does is detect if the first tile is an appropriate wall. If it is, it will be destroying the wall. If it's not already a wall, it will be creating one. In ZZT, updates to the screen are instantaneous (and can happen during video scanlines) however Lyon runs a fullscreen update after everything has processed. So in Lyon, the wall is being constructed and torn down on the same frame.

That crash was caused by how stars were handled under the new object system. I've fixed it. And I learned something new- since stars use the same Push function as pushers, they actually kill enemies the same way! Wondered why all those tigers were disappearing against walls..

Edit: Updates beep beep. I did not fix the superspeed bug you mentioned yet. Next release probableh

[Commodore]

Aha, that star things explains a bug I just experienced in ZZT: The player was destroyed after being killed and the keyboard commands stopped working so I couldn't quit/load/etc.

[Saxxon]

I've changed Thing.Code into Thing.Pointer. Since it is supposed to be a reference type and string is treated as a value type, I had to wrap it in an object. To get to the Thing's code, it will now be Thing.Pointer.Code instead of Thing.Code.Code (which looks stupid.)

Some objects are being drawn on top of the purple fade when it is processed. Going to get that fixed. Also going to fix the superspeed glitch.

Edit: I've also fixed the "warning" scroll effect in ZEOL-7. Before, the new board would be displayed before the scroll was shown (instead of after.) It even replicates the bug where the new board will be drawn when the scroll closes.

Edit 2: I have removed dependencies to DirectX from Roton.dll and put all DirectX related presentation plugins into RotonDX9.dll. It's better that way since DX9 won't be required if your program is just going to manipulate some worlds.

Edit 3: Board fading works properly on Super ZZT games now.

[Saxxon]

Treats.

[Commodore]

If the player gets thrown around by spinners in the dark with a torch on, the illumination screws up.


Also try to figure out this bug from the original zzt. The lions and stars (i'm sure it's star related) push through the walls. Then something must be placed off screen in the upper left since the line wall disconnects from the edge of the board.
http://youtu.be/rvxIlm49pvo

[Saxxon]

If the player gets thrown around by spinners in the dark with a torch on, the illumination screws up.

Will fix this one for next release.

Also try to figure out this bug from the original zzt. The lions and stars (i'm sure it's star related) push through the walls. Then something must be placed off screen in the upper left since the line wall disconnects from the edge of the board.
http://youtu.be/rvxIlm49pvo

Wow! That one is really weird! I suspect it has something to do with the way objects are handled- it looks like the properties from a star are being transferred to the tiger that gets thrown through the wall. You can tell by how fast the tiger moves and shoots that it inherits cycle 1 from somewhere. Stars are buggy. What ZZT world is that video showing?

Edit: I found out why. When A_Star is called, it grabs the pointer to the star's data. A_Star calls Push when it is blocked by something it cannot destroy. When Push is called and it destroys an object, A_Star's pointer points to something other than the star. It then calls MoveThing using its (now incorrect) index. Most ZZT functions that use Push have something to safeguard against this, but A_Star does not.

Edit 2: Looks like duplicators have the same bug as the star code! Strangely, pushers have code for this situation.

Edit 3: A further look at the pusher code reveals something I missed: there's code for pushers to push in a chain. That is, if a pusher executes and finds a pusher with the same x/y step behind it, it will activate that pusher as well! I have added this functionality.

[Commodore]

It is still the legendarily buggy Link's Adventure.