[Joseph Collins]

Back, again… with another wacky request.

MegaZeux has come a long way and made quite a lot of changes since the final "Software Visions" release in 1995.  As such, there have been a lot of new things added and new "quality-of-life" patches made.  In particular, there's been a lot of good stuff added that makes MegaZeux's "Robotic" language much more convenience to program with, such as easy shortcuts, the ability to type literally anything and not have the game yell at you, and for course, a built-in verifier/validation thingy. (Ooh, now we're getting technical~)

With all these technological marvels and additions, I can certainly understand why v2.51 is left to gather dust alongside several other MS-DOS classics.  However… as someone who's a fan of vintage MegaZeux games (I may even make one, someday…), something I would love to see implemented in a future release is a toggle, preferably in the editor, that would limit what you can do with your game world to the hard-coded limitations of v2.51.  That way, people who are interested in making "vintage" worlds, but don't like the limitations and frustrations (not to mention typos) of the original DOS versions, can take advantage of the ease-of-use stuff implemented in versions 2.51s1 to now while keeping worlds 100% compatible with v2.51 in every way!

I know this is an extremely niche request, I'm probably in the vast minority in wanting something like this and, for all I know, something like this already exists, so I don't expect any serious consideration out of this idea.  As I said, this is just something I'd like to see added.

Cheers!

[Lachesis]

DOSBox is available here and MZX 2.51 is available here. Alternatively, no one is forcing you to use newer features.

[Joseph Collins]

I… think you completely missed the point of what I was saying. The reply was a bit curt, too, if I'm being honest…?

I – and others – are more-than-capable of running v2.51 under DOSBox, absolutely. I'm sure I'm not the only one who has, too. I just think it would be nice if there were some version that either emulates the limits of v2.51, or actually is a version of v2.51, which has all the "ease-of-use" features that later updates have and only those features.

As for just using the newest versions and not using the new features, that's all fine-and-dandy, but the problem is that not everyone wants to take the time to read the ever-growing change log and see what all the new features are, especially to go out-of-their-way to avoid them. That said, if someone started a "retro" world in v2.92, it may end up doing things that v2.51 couldn't have, on top of being outright impossible to run in v2.51 entirely by accident.
(And, yes, I know that the internal world version would need to be hex-edited to get it running on older versions, anyway. That's actually something my prospective suggestion would do, automatically… in theory.)

This post has been edited by Joseph Collins: 08 December 2019 - 12:33 AM

[Galladin]

Man, you weren’t kidding...that is a wacky request!

[CJA]

I do understand that request though.

Sometimes I want to see the colors in message boxes and the debug menu screwed up again due to the palette, and stuff like that. I was just thinking about this what with MZX's 25th anniversary happening.

There's just so much that gets lost if you go back to the old versions though. Off the cuff, sure, I would want something like this, but I dunno if I'd ever use it or if it would be worth implementing.

Perhaps just diff the help files to see what's changed?

[zzo38]

If I make an external editor then I would allow using any world version from 2.51 to the current version, I think. Still, there are some features which have changed and may be incompatible with new version, such as:

• In version 2.51, using CHANGE CHAR ID to set the character code of a kind 0 to 127 to zero, if it is not one that is normally set to zero, would cause it to display the character for the direction the player is facing.
  
• In version 2.51, dragons sometimes go in a random direction (1/8 chance to move randomly) instead of directly toward the player. Later versions the dragon always tries to move toward the player (and stays still if it is blocked in that direction). Worlds of different MegaZeux versions may depend on one behaviour or the other.
  
• The new versions use a system palette and font for some menus (since it is no longer limited to the PC text mode, but now instead using an emulation which is enhanced with several new features).

Newer worlds may depend on the new behaviour and older worlds may depend on the old behaviour.

Also, I think that newer versions of MegaZeux use a ZIP archive as the world format, so hex editing a few bytes won't make it compatible. (Even disregarding that, there are some other differences where this matters.)

I am not sure if/when I would make external editor, but I would have the option to select the world version. In many cases this would disable unusable options in the editor. Still, there are a few things that you would need to read the documentation to know the differences between versions, such as Robotic counter names.

This post has been edited by zzo38: 08 December 2019 - 03:24 AM

[Terryn]

Hmm. It's nice to see at least some acknowledgement that MZX has done more than just "add complicated stuff". (Nevermind that a sizable chunk of that "complicated stuff" significantly simplifies things.) There are loads of editor improvements since the shrieking modem days. That said, this is... way too much work for a feature that will get little use. For futer future reference, this would likely involve shimming into the editor changes such as:

• Enforcement of strict 8.3 name length limitations
  
• Enforcement of strict subdir limitations (including forbidding board mods from a subdir altogether)
  
• Limiting Robot memory to ~60.3K for the entire board, on top of applying a 32K individual Robot mem limit
  
• Making signs/scrolls cut into that board memory limit instead of using their own memory
  
• Forcing max board dimensions to its original strict set of choices (60x166, 80x125, 100x100, 200x50, 400x25)
  
• Cleanly enforcing all of the old per-board limits for Robots/Sensors/Scrolls/etc, because we're not doing it the old way where it just breaks everything
  
• Cleanly enforcing the old global limits, mainly max board count
  
• Blocking load of all post-DOS file formats
  
• Removing every editor option that doesn't comply to the 2.51 featureset upon toggling this 2.51 editor mode, such as vlayer editor, MZM import/export, SMZX palette editing / mode selection, pre-set player locks, palette/char on load, extra char set editing, etc.
  
• Saving a worldfile/boardfile as a 2.51 file, and all the code that entails
  
• Making the counter debugger stop displaying values of several post-2.51 counters, since their functions don't exist in a 2.51 world and their display would just clutter and possibly confuse
  
• Re-supporting ANS, since we're being purists anyway
  
• Also password protection, for the same reason. can't half-ass purity
  
• Possibly making a compat layer for the old bad-practice limits we haven't done (or needed to do) yet, like key_pressed being signed in DOS vers (we haven't had to layer that yet, right?), since if we're going to actually devote an option to making ...new old games, they'd better work correctly
  
• Forcing extra words? "Authenticity."
  
• Probably something large I'm forgetting that someone will point out
  
• Other absolutely tiny (roughly femto-scale important) tweaks and concerns, but we're going for "100%" after all

There's also other concerns. If we're making a mode that caters to this, would we just throw those who want to use it to the winds, or would we be expected to code in accommodations? For instance, would we give warnings in test mode when the 50-counter limit is met, or when a Robot copy tries to go over the board mem limit? Would adding this feature in the first place just complicate things for possible newcomers, and if so, would that be worse on the whole than placating the people who complain about those "newfangled sprites"?

But hey, this list is at least a good launching point for making games in that style! Just stick to the limits yourself. Remember these, plus forcing the maximum of 4 simultaneous sfx, and that should be about 98%-99% of it. Why not an s3.2 restriction, though? You gain mouse control, 1000 counters, playerxy, local and mod *, among other things, and it remains conservative enough to where you can still have fun wasting entire lines on single-operation math commands, using the overlay / multiple robots for multi-char entities and dealing with only one string to use under very limited and jarring means.

[MicMotorhead]

I think it's much more important that new MegaZeux versions are as backwards compatible as possible with games made with all previous versions.

Making a game in 2.51 in DOSbox sounds like the way to go. I think the work that developers would have to put into making 2.51 emulation work in modern Zeux would be better spent making the current engine as stable, bug-free and compatible as possible.

[Lachesis]

Joseph Collins, on 07 December 2019 - 05:32 PM, said:

I – and others – are more-than-capable of running v2.51 under DOSBox, absolutely. I'm sure I'm not the only one who has, too. I just think it would be nice if there were some version that either emulates the limits of v2.51, or actually is a version of v2.51, which has all the "ease-of-use" features that later updates have and only those features.

As for just using the newest versions and not using the new features, that's all fine-and-dandy, but the problem is that not everyone wants to take the time to read the ever-growing change log and see what all the new features are, especially to go out-of-their-way to avoid them. That said, if someone started a "retro" world in v2.92, it may end up doing things that v2.51 couldn't have, on top of being outright impossible to run in v2.51 entirely by accident.

You don't have to read the changelog, you can just use whatever features you need and ignore the ones you don't. I think you're overestimating how widely used 2.51 is. Almost everyone uses the port now and I assure you literally no one is going to try to run a world from a newer version in 2.51. Modern MZX runs on pretty much everything.

Quote

(And, yes, I know that the internal world version would need to be hex-edited to get it running on older versions, anyway. That's actually something my prospective suggestion would do, automatically… in theory.)

As zzo38 mentioned the world format is completely different now and uses a ZIP container, so that wouldn't work (this wouldn't even have worked with 2.83/2.84X due to the board format having already been altered by that point). What would actually have to be done is the old save code would have to be restored (not a big deal) but then quite a few things would need to be changed across MZX's editor to enforce the 2.51 limits (see Terryn's post). I just don't think it's worth it, sorry.

This post has been edited by Lachesis: 08 December 2019 - 08:10 PM

[Spectere]

On top of what everyone else mentioned, bear in mind that this is something that would need to be supported moving forward. As features continue to be added to MZX, this would have to be continually tested to ensure that nothing breaks for the strict 2.51 compatibility mode.

If this were something that were steadily added and maintained throughout MZX's development it wouldn't be quite as bad, but at this point the amount of work would be astronomical. Between numerous refactors, as well as converting a bunch of 8086 ASM to C, even attempting to compare the 2.51 and 2.92* source trees would be futile. Please bear in mind that the post-SV MZX lineage dates back over 20 years, having released in early 1999.

For something like this I'd say that 2.70 (the last DOS version to be released) is a much more realistic target, but even that would be a mountain of work and something that very few people would make any use of. I think it's safe to say that more people run MZX on their 3DS than DOS.

I think you may also be underestimating the number of QoL features that exist in the Robotic language itself. In many cases, I daresay the only person really being affected by a compatibility mode switch is the person creating the game. As an exercise, try creating a multi-cell enemy using nothing but Robotic and the overlay (remember, 2.51 didn't have the vlayer). Now, do the same thing using sprites. Assuming your 2.51 implementation is relatively bug-free, the two should play about the same from the player's perspective, but the latter would have been substantially easier for you to create. It's like how most newer classic-style games are created using engines like Unity or Game Maker—it lets the creator achieve the same basic effect without having to learn how to program a VGA card (or the graphics hardware on the SNES, Genesis, etc).

Another thing to bear in mind is that MZX doesn't have an issue like what Doom has. In Doom it's sometimes desirable to restrict things to certain compatibility levels (i.e. "vanilla-compatible," "Boom-compatible," etc) since there are so many different ports, each of them containing a variety of differing features. MZX has had very few forks (MZXAK, PZX, etc) that there's been no need to set up feature gates like that. About the only one that makes any sense, IMO, is 2.70, but at this point I'd say there are more people that run MZX on their 3DS than on a DOS rig.

[zzo38]

Even not concerning the editor or the limitations (it is not necessary to implement most of the old limitations, nor the old editor features), I think the minor differences in behaviour should be implemented based on the world version. As I mentioned, one of them is the dragons movement. (System menus should continue to use the system colours/palettes even in compatibility mode, with the exception of the keys display, which should use the game palette instead. Popup menus created by the game itself (using scrolls, signs, or Robotic commands) should also use the game palette and game font, at least for worlds running in compatibility mode.) (The case of the dragons is one thing that I actually know that both some old worlds depend on the old behaviour and some new worlds depend on the new behaviour, at least. I am not sure about the difference with CHANGE CHAR ID, though.)

This post has been edited by zzo38: 09 December 2019 - 01:10 AM

[KKairos]

Echoing/following on the heels of what others are saying:

I encourage you to make a game respecting the 2.51 limitations if you want. Gemini made a point of doing that for a project or two back-in-the-day when we were still in the...Spider version days? Granted, it was easier to track at the time.

If you decide to do this, consider starting a journal or posting here: https://www.digitalm...showtopic=15548 which is a community screenshot thread that sees far too little use and hype nowadays.

And if you finish this, consider letting us know here: https://www.digitalm...showtopic=15871 so we can track your awesomeness.

I'm not the programmer of any of this, so I certainly don't want to tell you what's reasonable as if I am; I think the case made by development team folks about the feasibility of this speaks for itself.

(And of course, if it turns out you want to shoot for the 2.51s3, 2.70, or 2.92x limitations instead, I promise I won't judge. For yea, the measure I use will be measured to me, and I use those features all the time.)

[Lachesis]

zzo38, on 08 December 2019 - 06:08 PM, said:

Even not concerning the editor or the limitations (it is not necessary to implement most of the old limitations, nor the old editor features), I think the minor differences in behaviour should be implemented based on the world version. As I mentioned, one of them is the dragons movement. (System menus should continue to use the system colours/palettes even in compatibility mode, with the exception of the keys display, which should use the game palette instead. Popup menus created by the game itself (using scrolls, signs, or Robotic commands) should also use the game palette and game font, at least for worlds running in compatibility mode.) (The case of the dragons is one thing that I actually know that both some old worlds depend on the old behaviour and some new worlds depend on the new behaviour, at least. I am not sure about the difference with CHANGE CHAR ID, though.)

I'll go ahead and put the dragon behavior in the list of things to look into. There's another bug that needs a version check where slime blobs weren't implemented correctly (this bug seems to be as old as MZX is). The Robotic message box should be correctly using the game palette and charset as of (I think) 2.91j. With signs/scrolls I could go either way but something needs to change sooner or later (what they're doing now definitely shouldn't be happening e.g. try pressing F1 on the title screen of Demon Earth).

[Joseph Collins]

Huh. After getting shot down, I really wasn't expecting this topic to get any attention. I'm very glad that it did, though! There's been a lot of really good replies! Thank you all for taking the time to read and reply to this!

Terryn, on 08 December 2019 - 03:25 AM, said:

Hmm. It's nice to see at least some acknowledgement that MZX has done more than just "add complicated stuff". (Nevermind that a sizable chunk of that "complicated stuff" significantly simplifies things.) There are loads of editor improvements since the shrieking modem days. That said, this is... way too much work for a feature that will get little use. For futer future reference, this would likely involve shimming into the editor changes such as:

[many-many things]

See now, this is the kind of reply I was hoping for when I initially made this topic.  It's quite informative and maintains a certain level of respect, and I feel much more knowledgeable about modern MegaZeux than I did, a few days ago.

That being said, good lord, I can see why Lachesis reacted the way she did.  I genuinely had no idea that something like this would be such a headache to try and implement.  As I said, I knew a lot of stuff had been changed, both under-the-hood and right upfront, but I think I grossly overestimated just how much had changed and how many things would, basically, get wrecked by such a suggested mode.  I, uh… I think this post, alone, has convinced me that it's just not worth the trouble.  Thank you, Terryn, for taking the time to make this sizable list!

Also…

MicMotorhead, on 08 December 2019 - 05:27 AM, said:

I think it's much more important that new MegaZeux versions are as backwards compatible as possible with games made with all previous versions.

Making a game in 2.51 in DOSbox sounds like the way to go. I think the work that developers would have to put into making 2.51 emulation work in modern Zeux would be better spent making the current engine as stable, bug-free and compatible as possible.

I strongly agree with this. If I remember correctly, there was some level of weirdness I experienced with certain v2.51 titles, the last time I played them through modern MegaZeux? Of course, I was probably just running the game at a higher speed than expected, or something because it was nothing game-breaking. Just… something didn't work as expected, when it came to the robots?
(I think it was with Spirit Revenge…? Sheesh, could I be less helpful?)

Lachesis, on 08 December 2019 - 02:54 PM, said:

You don't have to read the changelog, you can just use whatever features you need and ignore the ones you don't.

Again, I'd like to point out that, as someone who hasn't (extensively) used the editor since the Spider versions of the game – not to mention having a general rustiness with Robotic code – I have absolutely no idea what's new, what's old, and what's what. Ergo, if I was wanted to make a truly "retro" game explicitly using modern versions, I would be half-clueless and probably accidentally break limits, or something.

Quote

I think you're overestimating how widely used 2.51 is. Almost everyone uses the port now […]

No. No, I am not. I'm well aware that it's a relic.

Quote

[…] and I assure you literally no one is going to try to run a world from a newer version in 2.51.

Probably not, but you never know. After all, I kind of expect a game labeled "retro" to work under the original versions of the game. But, perhaps, I'm expecting too much of the community?

Quote

As zzo38 mentioned the world format is completely different now and uses a ZIP container, so that wouldn't work (this wouldn't even have worked with 2.83/2.84X due to the board format having already been altered by that point).

Now, that… I did not know. Huh.

Spectere, on 08 December 2019 - 05:03 PM, said:

On top of what everyone else mentioned, bear in mind that this is something that would need to be supported moving forward. As features continue to be added to MZX, this would have to be continually tested to ensure that nothing breaks for the strict 2.51 compatibility mode.

Which just adds to the growing headache that implementing something like this would be… Like I said, I had no idea. I probably should have, but I absolutely did not.

Quote

I think you may also be underestimating the number of QoL features that exist in the Robotic language itself.

I genuinely don't know. I just feel like there's some new functionality that helps with the creation process, in there. But, uh… in retrospect, the "Verify" feature that I mentioned is kind of redundant as older versions did verification on-the-fly. With horrible, annoying error boxes. Still, I don't guess there's a huge lot of difference, there…

Quote

In many cases, I daresay the only person really being affected by a compatibility mode switch is the person creating the game. As an exercise […]

Well, this suggestion was entirely for the Editor, not the actual "play" engine. But, I get what you're saying.

Quote

Another thing to bear in mind is that MZX doesn't have an issue like what Doom has.

Okay, now, you're speaking my language. In fact, I was going to use this as a comparison/"diving board" for such a mode for MegaZeux. But, as you (essentially) pointed out… old worlds work just fine in new ports with some very rare exceptions, and there aren't that many ways to make a MegaZeux world, unlike with Doom. (Doom, Doom in Hexen mode, Boom, etc.) So… yeah. That just puts another point in the "just use DOSBox" solution that Lachesis pointed to.

zzo38, on 08 December 2019 - 08:08 PM, said:

[…] I think the minor differences in behaviour should be implemented based on the world version. […] (System menus should continue to use the system colours/palettes even in compatibility mode, with the exception of the keys display, which should use the game palette instead. Popup menus created by the game itself (using scrolls, signs, or Robotic commands) should also use the game palette and game font, at least for worlds running in compatibility mode.)

Just wanna say, that was definitely one of the "weird issues" I experienced while playing old games in new MegaZeux. I know why the interface uses the default character set, nowadays, but sometimes, it's nice to just see the menus and scrolls/signs display as they were "intended."

KKairos, on 08 December 2019 - 08:25 PM, said:

[kind words~]

I'm not the programmer of any of this, so I certainly don't want to tell you what's reasonable as if I am; I think the case made by development team folks about the feasibility of this speaks for itself.

(And of course, if it turns out you want to shoot for the 2.51s3, 2.70, or 2.92x limitations instead, I promise I won't judge. For yea, the measure I use will be measured to me, and I use those features all the time.)

This might be the most encouraging post, yet. I mean, only one-or-two people were inadvertently making me feel like a dummy or an old fogey for wanting to "revive" v2.51… but, I think you're the only person who's actually shown some level of positive encouragement (rather than neutral) in wanting to make a retro game world. I greatly appreciate you taking the time to write this. Thank you.

This post has been edited by Joseph Collins: 10 December 2019 - 04:13 AM

[Terryn]

You can check out counter.c in the source code. Near the middle is a table that lists what built-in counter was introduced in what version, so you can avoid using anything past 2.51 if you wish. Most of the things added since 2.51 should be fairly apparent (expressions, sprites, file access, subroutines, vlayer, MZMs, custom strings, yada yada), but some of the other post-2.51 changes that are generally extremely old but perhaps easy to forget about are mouse support, having worlds set mzx_speed, setting commands-per-cycle, any local counter simply called "local", robot_id, having seamless music continuation upon changing a board (aka "mod *"), and pretty much any counter that blocks a default menu. MZX 2.51 only ran MOD/GDM/SAM, for the most part, so you'd limit your sound to those.

If you do find an incompatibility between how DOS MZX and current MZX runs a game, let us know in a detailed report in the tracker at the top. Compatibility is one of the foremost concerns the devs have, as this thread helps exhaustively demonstrate.

As for your point about "retro", I think you're defining it more specifically than most. I mean, is Shovel Knight not worthy of being called retro because it doesn't come on an NES cart? You Have to Win the Game not retro because it doesn't run in CGA-mode DOS? Strikey Sisters because it's not on a Turbo Grafx Super-CD? Maldita Castilla because it's not on an arcade board? I get that there are still people who release games that run on the actual consoles, and that's still a fun and interesting pursuit! At least one MZX-affiliated person has made one (SEE HERE)! I just don't think that this condition is a strict requirement to have a game be considered "retro".

Also, since MZX isn't a console, or even a "fantasy console" (if it were, or if we could feasibly call it that, maybe people would actually pay attention to it), there's far less of a reason to stick to a certain set of parameters while developing. There's far less gravitas attached to a specific version of an often-updated piece of software than to a mostly-static piece of hardware or to a software suite set emulating the limitations of that kind of hardware.

[MicMotorhead]

I personally think of retro games as being games that emulate the feel or design sensibilities of older games. A few devs are making games that run on the actual old hardware, but mostly, people that make retro games don't even strictly stick to original color palettes and certainly not horrible stuff like memory limitations. Shovel Knight gets the feel right, but allows itself to use more memory, have better sound quality and more colors.

If I was making an NES-like game, for example, there's no way I'd wanna suffer under the limitations that caused sprite flickering back in the day. Sprite flickering sucks!
(...I do understand the desire to make a 2.51 MZX game. But I'd die if I had to do without MZM files myself . )

Also, since the game was mentioned, I thought I'd point out that Strikey Sisters is one of my favorite games on Steam

This post has been edited by MicMotorhead: 10 December 2019 - 07:32 AM

[hseiken]

Just add "fantasy console/fantasy computer" to MZX description already. Even though it started before this trendy term was popularized/coined by Pico8 and it's bazillion imitators, it fits the bill and might actually attract new users and thus have the side effect of interesting new games being made at a higher frequency. That's speculation, of course, and maybe there's some integrity to be maintained by not just pulling in pop terminology when convenient, but I find MZX actually fits Fantasy Console constraints far more than a lot of these programmer in-joke projects like 'here's a fantasy console that works only in 4 bit and all of the commands are actually z80 assembler!'...when the actual point of a fantasy console was to act more like a GCS like MZX is...yeah it's got limitations, but it's more artist friendly and removes a lot of technical hurdles to making a game.

IDK...I hate everything and simultaneously love everything so I'm likely making contradictory statements at any given time.