Linux port of reconstruction, now in C/C++

NOTE: I HATE A LOT OF YOUR ZZT GAMES, SO WATCH OUT!

Moderators: Commodore, Zenith Nadir

zzo38
newcomer
Posts: 22
Joined: Sun Dec 15, 2019 11:25 pm

Re: Linux port of reconstruction, now in C/C++

Post by zzo38 »

My own recommendation is that any out of bounds elements should be considered undefined behaviour, and should not be used in any world file (except for testing purposes) (you may emulate this if you wish, although in my own opinion, I consider it unnecessary and probably undesirable). If you require elements with specific attributes (visible in dark, pushable, etc) and/or behaviour, consider using the FreeZZT format, which allows these things to be customized. Larger buffer sizes should probably be implemented regardless of the world format, since that does not affect compatibility with world files that do not rely on undefined behaviour. If you do not require the features of FreeZZT or other variants, then you should use the standard ZZT format without any extensions. (If you wish to emulate WeaveZZT or other variants, then you will need some way to identify it as a WeaveZZT world file, and as far as I know it doesn't include such a thing (one possibility is to use a command-line argument, or perhaps a file with a .VAR extension to denote the variant to emulate). If you wish to emulate FreeZZT and/or SuperZZT, then it can be easily detected by the contents of the world file (and, in the case of SuperZZT, also the file name), so no other mechanism is needed.) Maybe it is difficult sometimes to determine which behaviour is "undefined behaviour". My own opinion is, anything that depends on accessing memory that is not part of the correct part of memory in order to make decisions (not simply display) is "undefined", although other parts of the same structure or array are not considered to be "not part of the same part of memory" (even if the index is unexpected), so they are still considered to be defined. Since the current number of gems and keys are part of the same structure (TWorldInfo), this is not considered to be undefined behaviour (it is defined), and it must be emulated. Use of elements beyond MAX_ELEMENT is undefined behaviour since it involves access to memory outside of the array that it is trying to access (ElementDefs) in order to make decisions. (Executing any native code that isn't one of the procedures in the game engine (including the run time library as part of the game engine for this purpose), or trying to use arbitrary data (including data that comes from outside of the game engine) as a subroutine address or memory address, is also undefined behaviour.) Runtime errors (other than I/O errors) may also be considered as undefined behaviour (for example, this includes division by zero).
I have set up a NNTP to discuss ZZT and other stuff.
The Mysterious KM
newcomer
Posts: 18
Joined: Wed Mar 25, 2020 12:59 pm

Re: Linux port of reconstruction, now in C/C++

Post by The Mysterious KM »

After thinking about this a bit more, I'd suggest two modes, call them strict and quirky. Perhaps like this?

Quirky mode: Hanging or crashing ZZT is not allowed. Things that freeze the player and keyboard input but keeps the rest of the game going (e.g. player with cycle 0, or overwriting the monitor on the title screen) should be considered a hang. Reading or writing out of bounds is allowed as long as it can't be used for arbitrary execution. Malformed data should be interpreted as best as possible (e.g. recover Super Locked final boards), but provide a visible/loud error on loading to indicate that it would crash or hang ordinary ZZT.

Strict mode: As quirky, but nothing out of bounds is allowed. Basically, all the checks that my fuzz branch does. The mode would probably need some sort of formal definition of what happens out of bounds (do the x/y/xstep/ystep parameters just get clamped, does the board behave like it has an infinite number of uncopyable tiles outside of the playing area, etc).

Things that can currently only be done by hacking could be added to future versions of ZZT to make them easier.
asie
1 full minit uv 1 secend mesiges
Posts: 67
Joined: Sun Mar 17, 2019 4:55 pm

Re: Linux port of reconstruction, now in C/C++

Post by asie »

This is very close to what I was planning myself for my modern source port, so I think it checks out.
elninbo
newcomer
Posts: 10
Joined: Tue Jun 10, 2008 3:30 am
Location: Morgantown WV

Re: Linux port of reconstruction, now in C/C++

Post by elninbo »

this looks nothing like ZZT-OOP
Where ever you go, there you are.
Post Reply