The Future

[QBasicer]

You're right, any (major) changes to ZDoom would create yet another branch. Keeping old code inside ZDoom itself would be too Bloaty, so basically you have to have two copies of everything. One copy to maintain new format, and one to run the old format. If you go as far as a new map format, one could even just rebuild everything from scratch. Randy, nodoubtedly, has an intimate knowledge of Zdoom's thought process, so he could probably rebuild it (with much work). Would it run better? I don't know. Probably not worth it, but is any of ZDoom's code there for support on older machines that doesn't need to be there?

[Graf Zahl]

If you go as far as a new map format, one could even just rebuild everything from scratch.

Huh? The motivation behind a new map format is to make access to the existing features easier - and to add new ones that don't alter the game completely. Nobody wants to rewrite the engine.

Randy, nodoubtedly, has an intimate knowledge of Zdoom's thought process, so he could probably rebuild it (with much work). Would it run better? I don't know. Probably not worth it, but is any of ZDoom's code there for support on older machines that doesn't need to be there?

No. The only old thing that has added support are voodoo dolls. Everything else is just a side effect of the way things work.

[T-1]

B) Get Ken Silverman to GPL the Build engine.

That won't happen. And even if it did, there's other GPL-incompatible stuff in there too. Even the use of FMOD with GPL code is questionable, so to make a safely GPL ZDoom, you would also have to redo the sound code. Personally, I don't see the available library of GPL code as enticing enough to make it worth my time trying to make a GPL ZDoom.

Then perhaps the Perl Artistic License would be useable? Ahhh.... but then you wouldn't have the fun of writing a VM... Though, you could make your own VM to run parrot bytecode and then modders could use Parrot to compile the PASM/PIR into bytecode and then not have to worry about licensing issues and you still could have fun writing a VM AND you could have access to all the different languages that already have compilers for Parrot.

http://www.parrotcode.org/

I'm still planning on writing my own VM. (After all, that's half the fun! Heh heh.) But the link to this and the recent link to Pawn are making me rethink my choice of an interpreted machine. Initially, I was planning on having the VM execute a tree language (like Unreal) due to shear simplicity: Creating code for the VM would involve little more than creating a parse tree from the source code and writing it out. But after reading the above links and discovering that both languages offer JIT (and so does Quake 3), now I think being able to translate to native code would be cool. And to do that, an intermediate representation closer to the actual machine seems more appropriate. So I am now toying with using a MIPS-like instruction set for the VM. Even if I don't do a JIT for it, it would probably still interpret faster than a tree-based instruction set.

Yeah, in the case of Parrot Vs. Perl5, on short programs Perl5 is a bit faster, but on anything longer, Parrot runs circles around Perl5 mainly thanks to the JIT. How flexible do you plan to make the code? As flexible as UnrealScript where you can pretty much do ANYTHING, or just something like Decorate improved...

Anyway, I'm glad I could help out in some small way


There are some things that could be improved on the map format, but I wouldn't change it if... however if change IS being considered, I'll point out things that could be added/improved:

1) Choosing sounds for line activation (door open, lift raise, etc.), the continuing ambient sound, the sound for it ending.
2) For damage sectors, you could specify how much damage the sector does (integer 0-255) and how often damage is done in seconds (a float), whether you have to be touching the floor to take the damage and whether monsters take damage.
3) For light sectors you could have a setup where you could have up 255 light "states" that loop and each have brightness/color set using RGB and maximum and minimum time until it changes to the next state, and perhaps a choice to interpolate the light levels in between states...
4) More flexible ambient sounds, where we able to specify pitch, and add random one-shot sounds with minum and maximum pitch and amount of time between sounds.

[deathz0r]

Why restrict Zdoom's development and prevent it moving on to higher and higher things just to retain compatibility with some old projects that can still be run with earlier versions of Zdoom anyway.

I should not be forced to keep more than one version of ZDoom on my computer just because people want to remove "redundant" features like DEHACKED support and whatnot.

After going nowhere for far too long I have decided to go ahead and design something better - including a port independent DLL to load it.

You forgot to mention that it'll break cross-platform capabillities that prevents the userbase from expanding beyond the typical Windows users.

[Graf Zahl]

Only if the source can't be recompiled on other platforms or integrated into the main executable.

[deathz0r]

True, which is why releasing the binaries as a DLL is a bad idea.

[Graf Zahl]

Some people are easier to convince to use an external DLL rather than incorporate other people's code into their own. I'd do both: release a DLL and the source so everybody is happy.

[The Ultimate DooMer]

If the current version of Zdoom ceased to be a reliable port to play older or non-zdoom specific maps on, would it still be such a popular port? I suspect not. I also suspect people would not want to keep version "2.0.whatever" of Zdoom around to play anything they DL from idgames and a copy of "NewZdoom" for the newer mods only. I also suspect it would mean projects like Zdaemon and skulltag would be less willing to use Zdoom as a base. So I think dropping support for the hacks would, over all, be counter-productive for Zdoom's future as a Doom port.

Not to mention that all these old versions aren't readily available. I noticed 24-49 on the /files/old/ folder but the others are nowhere to be seen. I know a few wads need a specific version due to bugs with versions around it (including sonic of course, although I've not tested it with 97+ so it might be ok now)

ZDoom already gets a bashing from the demo people and the multiplayer people for no backwards compatibility and lack of a stable version to build on respectively, it would be suicide to drop it for single player wads too.

But would I want to have GZDoom without OpenGL? No, of course not (there would be little point).

At the moment there is, since it combines 96x stuff with fixes from 97+. (well, if you're a mapper and you can't run GZDoom in OpenGL)

btw how would the 96x states be used in 99? Do we simply change the inherited type from Inventory to CustomInventory? And will this be altered in GZDoom too?

[Graf Zahl]

(including sonic of course, although I've not tested it with 97+ so it might be ok now)

The only problem with .96 is the buggy DEHSUPP lump in there. That issue has been fixed in the mean time and .98 should work properly.

ZDoom already gets a bashing from the demo people and the multiplayer people for no backwards compatibility and lack of a stable version to build on respectively, it would be suicide to drop it for single player wads too.

I'd have to agree with that, although I don't care about the demo people who mostly lack any understanding why there is no demo compatibility. But it's not just multiplayer. Right now Randy is sitting on a huge change to the code apparently without any intention to release it any time soon. In August he did an unofficial source release but since then he released 2 new versions of ZDoom still based on the old code.
And since he is doing even more changes to that unreleased code I fear that a gigantic problem is arising. Instead of fine tuning and fixing the available code base (which can't be done because the code isn't available and as a result nobody is testing it) more changes that introduce more problems are added and additionally the bugs forum doesn't get cleaned up.
This has become a huge issue for me by now. I can't develop GZDoom in the direction I'd like because half of the code I'd do would be wasted anyway so I'm stuck to simple maintenance and bug fixed for the foreseeable future.

btw how would the 96x states be used in 99? Do we simply change the inherited type from Inventory to CustomInventory? And will this be altered in GZDoom too?

Since the general handling for all inventory types requires several small changes throughout the code I will copy ZDoom's behavior once it is out.

[Scuba Steve]

Randy, so the way I understand it and correct me where I'm wrong, the current decorate method all the way through 96x will be included in future releases of ZDoom, with only the newer 96x stuff maybe needing some repairs after the inclusion?

[Graf Zahl]

According to the 2.1.0 source release there is one breaking change.

Currently you can reference parent states by specifying:

Death Parent Death+5

That option has been removed in the latest code.

[Scuba Steve]

Sounds like a minor change, but if the rest stays in tact, that will be excellent news. I think a lot of people have come to depend on those features thinking there were going to be incorporated into ZDoom and would only hurt the users of ZDoom and tear the ZDoom community greatly if they were left out.

[Graf Zahl]

Do you think there will still be a ZDoom community if the stuff ultimately doesn't find its way in?

[rpeter]

I think Randy is doing the right thing. He maintains the current release while working on a new major version in his workshop. He will release his new stuff when it gets to beta stage only. This can reduce the number of engine versions needed to play EVERY ZDoom wad there is, because authors have less engine deficiences to exploit. Yes, I hate those hackages, too. If the readme mentions such "cool stuff" I know I'd better find the corresponding engine by looking at the wad's creation date.

And I think Graf is also right.
First: a new map format that is well defined, does not allow ugly hacks, etc. would be cool.
Second: a major version change WILL make his project suffer. Who knows how much the next codebase will change, he might even need to start again from scratch. Such version change killed Kokak's ZDoomGL.

[Graf Zahl]

I think Randy is doing the right thing. He maintains the current release while working on a new major version in his workshop. He will release his new stuff when it gets to beta stage only. This can reduce the number of engine versions needed to play EVERY ZDoom wad there is, because authors have less engine deficiences to exploit. Yes, I hate those hackages, too. If the readme mentions such "cool stuff" I know I'd better find the corresponding engine by looking at the wad's creation date.

For developers that depend on the code it is an utter nightmare. The code has changed enough already and by the time he releases it it has changed even more - in the worst case to a degree that can't be updated anymore.

Furthermore, since nothing is released nothing is tested. (Testing by the programmer himself doesn't count.) So in the end we get a version that has so many interacting changes that potential bugs are hard to track down. There is one huge rewrite (floating point) waiting to be tested but it probably will only get tested after the next huge rewrite (The new DECORATE interpreter) Anyone with even some decent programming experience will see the problem with that. You finish one thing first before starting the next if possible. I see it all the time at work that this rule is violated and the result we have now is a complete mess of code nobody understands anymore and nobody can maintain - and nobody has the time to clean it up so it will degenerate further. Luckily it's only an internal development tool which is used by 50 people at most.

And I think Graf is also right.
First: a new map format that is well defined, does not allow ugly hacks, etc. would be cool.
Second: a major version change WILL make his project suffer. Who knows how much the next codebase will change, he might even need to start again from scratch. Such version change killed Kokak's ZDoomGL.

That's why it needs to be tested NOW, not when it has been changed even further. If the changes are too severe chances are that some may become unrevertable and the incompatibilities are there to stay.

BTW, you don't have to look further then Doom Legacy for a project that did a complete rewrite in private and doesn't see a non-beta release. That's most likely because now in the testing phase all the bugs that accumulated over the years are found at once and giving the programmers a hard time fixing it all.

So what does this all mean for ZDoom? My suggestions:

1. Make 2.0.98 the official version
2. Any new version should be declared 'Beta'.
3. Test this beta version and release new revisions as frequently as possible
4. Get rid of all the bugs.

Once all this is done a new 'official' version can be released and the DECORATE improvements should be started - not now with a completely untested version that may contain several undiscovered problems.