Lyon

[Smilymzx]

In the Future, But Not Now:

* Make optional SDL compatible build

* Font Mania has the option to adjust the size of the font, and is usable in ZZT. so CHR files need to use a new format extention: *.F(number), where (number) is at least 6-16.

* Restore *.PAL/PLD Palette file functionality

* One last reminder: Still need to implent a MZX-style Status Screen and border functions after completion of the first final build of Lyon (after INI support is implented and a few other changes).

[Commodore]

After ending a game, and pressing "P" to play again:

System.IO.EndOfStreamException
at System.IO.__Error.EndOfFile()
at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
at System.IO.BinaryReader.ReadInt16()
at Roton.File.Load(Stream Source)
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()

then trying to save over a existing save file.

System.NullReferenceException
at Roton.File.SaveRLE(ZZTBinaryWriter Target, Tile[] Tiles, Library Library)
at Roton.File.SaveZZTBoard(ZZTBinaryWriter Target, Board B, Library Library)
at Roton.File.SaveZZT(ZZTBinaryWriter Target, Environment Source)
at Roton.File.Save(Stream TargetStream, Environment Source)
at Lyon.MainForm.FileSave(Environment E)
at Lyon.MainForm.SaveGameHandler(Environment E)
at Roton.Environment.ActPlayer(Int32 Index)
at Roton.Environment.Act(Int32 Index)
at Roton.Environment.PerformBoardCycle()
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()

using the same game: http://zzt.org/zgames/k/ksaga.zip
playing it from the zip file.
looking at the game in the editor, it seems to spam the play command and it is also a locked file.

Also look at this "game". It has a scroll that you have to touch right after you press "P", in lyon the hyperlinks do not work.
http://zzt.org/zgames/g/gfight.zip

[Saxxon]

After ending a game, and pressing "P" to play again:

System.IO.EndOfStreamException
at System.IO.__Error.EndOfFile()
at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
at System.IO.BinaryReader.ReadInt16()
at Roton.File.Load(Stream Source)
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()

This is a bug that is present in ZZT- when the world's internal name does not match the filename, you will get this error. As for the crash in saving the game, this is due to having a corrupt board. I'm patching this up so that it does not crash. ZZT unpacks and repacks boards dynamically when switching boards. When a corrupt board is never visited, it is never unpacked, and therefore does not crash ZZT. However, Lyon unpacks all boards.

[Saxxon]

I am working on the editor now. Making the game and editor classes inherit from a base form that contains the sidebar, input handling, etc. Should make it very easy to reuse code.

At the core, I'm looking to make it operate just like the ZZT internal editor. When this part gets finished, I'll step out from there and start to add other functionality, especially with the mouse.

Also, a few other changes:
- Palettes are now loaded. It'll only look for certain extensions (PAL, PLD).
- Font loading has been adjusted so that .F6 through .F16 are considered as fonts, with preference on .F14.
- When loading raw data (not .com files) the palette and font routines will not be picky and load pretty much anything that could be considered appropriate data: if palette file length is a multiple of 3 and there are at least 48 bytes, it will load the first 16 colors. If the font file size is a multiple of 256 and there are between 6 to 16 blocks of 256, it will read this as font data. None of this will crash Lyon; in the worst case, you'll just end up with weird colors or characters if the data is somehow corrupt.
- Roton's board handling is being overhauled to how ZZT works: to conserve memory, ZZT will leave all boards packed and only unpack them when they are being displayed. This means corrupt boards are left alone- when the world is saved to disk again, the corrupt data will be placed there unchanged.

[Saxxon]

Sneak peek. Only able to navigate around the board with the cursor at this time.

[Smilymzx]

Thanks for implenting some of them, And Awesome job on the editor too, It is great to see some action!

EDIT: One of my Romhacking tools support both RAW 1-bit 8x8 and 8x16 fonts (YY-CHR, by a Japanese ROM hacker named YY), Other DOS (RAW CHR) font editors will do as well.

This is why it is needed, But if using normal ZZT/SZZT, Using TSRs will do, but it is hard for some people to make.

[Saxxon]

Thanks for implenting some of them, And Awesome job on the editor too, It is great to see some action!

EDIT: One of my Romhacking tools support both RAW 1-bit 8x8 and 8x16 fonts (YY-CHR, by a Japanese ROM hacker named YY), Other DOS (RAW CHR) font editors will do as well.

This is why it is needed, But if using normal ZZT/SZZT, Using TSRs will do, but it is hard for some people to make.

Most people would include a .com file with their ZZT games, which is why this is supported. However, I don't know all the font editors used out there and I'm sure there are still some used in ZZT games that Lyon doesn't support. Luckily, most people used Font Mania.

In my opinion, it's still a good idea to release any game you make with a TSR, since not everyone will be able to use Lyon- DosBox is widely supported on many platforms.

I found out that the method I'm using for text entry supports ALT+# codes. So you can actually get all 256 characters this way!

[Smilymzx]

That is true.

I even made (and lost) a ZZT mod that does not need TSRs to load, though it screws with the ZZT intro screen (where you push K and C.) I may do something to prevent that by using a patch that's from KevEdit!

[Saxxon]

That is true.

I even made (and lost) a ZZT mod that does not need TSRs to load, though it screws with the ZZT intro screen (where you push K and C.) I may do something to prevent that by using a patch that's from KevEdit!

KevEdit throws K-C-Enter into the keyboard buffer and immediately starts ZZT. It doesn't actually do anything to the program itself.

[bitbot]

Nice screenshot! I'm torn between the classic interface and a ZAP-like GUI. A maximized bird's-eye view of SZT worlds could be a nice feature, but a console editor is probably more efficient.

I've discovered just how buggy Superz is. ZAP allows me to import/export object code from regular ZZT worlds using the tile buffer, which is a huge feature! Now I'm up to the challenge of working on a little project...

I'd be happy to test the new editor when it becomes available. Thanks and good luck!

[Saxxon]

I've discovered just how buggy Superz is. ZAP allows me to import/export object code from regular ZZT worlds using the tile buffer, which is a huge feature! Now I'm up to the challenge of working on a little project...

Reading this inspired me to consider implementing a "global buffer". That is, you would be able to decide whether you would like individual buffers for the editor or a buffer from which all editor windows use.

[Smilymzx]

I've discovered just how buggy Superz is. ZAP allows me to import/export object code from regular ZZT worlds using the tile buffer, which is a huge feature! Now I'm up to the challenge of working on a little project...

Reading this inspired me to consider implementing a "global buffer". That is, you would be able to decide whether you would like individual buffers for the editor or a buffer from which all editor windows use.

I would like all editors to use the global buffer, but if there is a element not featured in a certain format, give the user an option to either erase the element, make it use white text with the element's character or use a replacement element in place of it.

[Saxxon]

I've discovered just how buggy Superz is. ZAP allows me to import/export object code from regular ZZT worlds using the tile buffer, which is a huge feature! Now I'm up to the challenge of working on a little project...

Reading this inspired me to consider implementing a "global buffer". That is, you would be able to decide whether you would like individual buffers for the editor or a buffer from which all editor windows use.

I would like all editors to use the global buffer, but if there is a element not featured in a certain format, give the user an option to either erase the element, make it use white text with the element's character or use a replacement element in place of it.

Elements that are exclusive to one engine will not show up in another. ZZT and Super ZZT use different element #s to define elements, so I use enumerations. The global buffer will store element IDs. When you want to plot from the global buffer, it will check in with the game's library, basically say "hey, do you have the information for ElementID.Torch?" And if it's a ZZT library, it'll find it and you will be able to use it. But if it is a SuperZZT library, there will be no matching element, because none of the elements are marked as Torch. Every element has an affinity to internal ZZT behavior: there are two bear presets (ZZT and Super ZZT) but they both identify as ElementID.Bear. So if you want to transplant one between games, the libraries will respect the difference.

My solution? Items that are not present in the currently edited engine simply won't be selectable from the global buffer. ZZT's standard library doesn't even know what a stone of power is, and in fact, doesn't even know how to treat it! Element lists are very strictly enforced.

[Smilymzx]

True: This is why I suggested Equivlent Elements will use replacements, such as ZZT Water->SZZT Lava.

The Text replacements are what ZZO38 did for his MZX Converter Package, but it is for Megazeux!

At least make sure the element buffer implents the following dialouges:

''Want to replace [ElementID] with [ElementID]?''
[Replace] [Erase]

or in the case of elements specific to the format:

''Want to replace [ElementID] with a temporary White Text?''
[Replace] [Erase]

[Saxxon]

True: This is why I suggested Equivlent Elements will use replacements, such as ZZT Water->SZZT Lava.

The Text replacements are what ZZO38 did for his MZX Converter Package, but it is for Megazeux!

At least make sure the element buffer implents the following dialouges:

''Want to replace [ElementID] with [ElementID]?''
[Replace] [Erase]

or in the case of elements specific to the format:

''Want to replace [ElementID] with a temporary White Text?''
[Replace] [Erase]

A dialog every time this happens would be pretty intrusive to the editor flow, it would probably be best left to a user setting :)