The Future

[T-1]

I think the fact that Parrot is GPL ruins any hope of implementing it into ZDoom dur to licence conflicts.

Hmmm... well IIRC you can also technically use the Perl Artistic License for parrot instead... would that have less conflicts?

EDIT: Either that or it may be in general be worth it to A)

A) Rewrite the stuff taken from the build engine, or
B) Get Ken Silverman to GPL the Build engine.

[Bio Hazard]

Don't forget:
C) Remove Heretic and Hexen support including ZDoom-Hexen map format, ACS and polyobjects.

[Graf Zahl]

Don't forget:
C) Remove Heretic and Hexen support including ZDoom-Hexen map format, ACS and polyobjects.

Hexen map format and ACS were both done long before Raven's source release.

[T-1]

Hmmm.... Well... I wasn't that you should do it, I was saying, you could do it, and maybe it'd be worth it, considering all that this would allow for using lots of GPL stuff like parrot.

Also, would the Perl Artistic License be compatible?

[Graf Zahl]

The non-GPL'ed stuff in ZDoom is too valuable to be dumped.

[T-1]

The non-GPL'ed stuff in ZDoom is too valuable to be dumped.

Not dumped, but perhaps rewritten?
Hmmm... well, maybe I should download a copy of the source and see if I can compile and run it under Linux w/ GCC, and then try my luck at rewriting the relevant stuff. Hmmm... who am I kidding, I barely know any C/C++ at all... I'm more into Java, Perl, UnrealScript, and Parrot than anything else... but, I'll try.

Hmmm... or I could try to politely email Ken Silverman and plead him to GPL the source to build.

EDIT: Still no response about the Perl Artistic License? Specifically what is it that makes GPL'd stuff legally incompatible with the Build and Doom licenses?

[Graf Zahl]

The non-GPL'ed stuff in ZDoom is too valuable to be dumped.

Not dumped, but perhaps rewritten?
Hmmm... well, maybe I should download a copy of the source and see if I can compile and run it under Linux w/ GCC, and then try my luck at rewriting the relevant stuff.

Don't bother. You won't get rid of the licenses that easily. Some of the code is spread throughout many source files and in some cases not even rewritable. The biggest chunk is the monster AI anyway and once a good scripting language is out of the way it gets moved into the WAD where it no longer interferes with the source code itself.

[Hirogen2]

The way I see it, Artistic License is somewhat like LGPL, so that could be used. Though I would not do that, because I think that putting a general-purpose interpreter like Parrot in there an unnecessary enlargement of the binary's size.

[randi]

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.

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.

Oh, yeah, stuff from 2.0.96x is in the pipe for inclusion with 2.0.99. I even decided to include support for Pickup, Drop, and Use states, but only if you inherit from CustomInventory. Combined with being able to have autoloaded ACS libraries, that should hopefully cover everything you would want to use them for, even if they won't work if you inherit from existing items.

[Necromage]

Sounds like some really good stuff, especcially the 2.0.99 one

[Bio Hazard]

If it were my descion, I would go for a whole new map and class definition format. Not putting any thought twoards compatabillity with old WADs. Then I would expect the community to make patches for broken wads or converters to the new (well duccumented) format. Then ZDoom would be much less hack-filled.
(Is ZDoom hacky? It sure does a lot of things that there are better ways to do now. Why add special checks for the old hacks?)

For example: If I made a really nice map way back when and I used some crappy boom hack that will cause ZDoom to need special checks for in the future, when it finally breaks due to being old and hacky, fans of the wad would update it to use the new system and upload a patch to a wad patch archive somewhere. This would discourage trying to get around limitations by constructing dirty hacks. Sure innovative ideas will be pinched a bit, but imagine how much easier it would be to implement new features without needing to support every bleeding flat platform, voodoo-doll script and DEH nightmare (batman.deh).

Some of us programmers need to show up on the IRC or something and discuss a new map format. ZDoom needs an update very badly.

My view might sound self-destructive to the future of ZDoom, but it worked for a lot of the other projects I have worked on.

[Caligari87]

I think Graf has a thread for map data definitions in the GZDoom forums...

[Graf Zahl]

Oh, yeah, stuff from 2.0.96x is in the pipe for inclusion with 2.0.99. I even decided to include support for Pickup, Drop, and Use states, but only if you inherit from CustomInventory. Combined with being able to have autoloaded ACS libraries, that should hopefully cover everything you would want to use them for, even if they won't work if you inherit from existing items.

That compromise seems acceptable. At the time I added this stuff it seemed like a good idea but it didn't take long to see the problems involved. Today I wouldn't do it the same way anymore so it is probably the best idea to limit it to a subclass like this. At least then it doesn't clash with predefined behavior of standard items.

[Graf Zahl]

If it were my descion, I would go for a whole new map and class definition format. Not putting any thought twoards compatabillity with old WADs. Then I would expect the community to make patches for broken wads or converters to the new (well duccumented) format. Then ZDoom would be much less hack-filled.
(Is ZDoom hacky? It sure does a lot of things that there are better ways to do now. Why add special checks for the old hacks?)

No class format? Why? I think DECORATE is fine as it is but only needs some programmability. But that is being addressed by Randy's plans.
New map format: Have you read that discussion over at Doomworld? 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.

For example: If I made a really nice map way back when and I used some crappy boom hack that will cause ZDoom to need special checks for in the future, when it finally breaks due to being old and hacky, fans of the wad would update it to use the new system and upload a patch to a wad patch archive somewhere. This would discourage trying to get around limitations by constructing dirty hacks. Sure innovative ideas will be pinched a bit, but imagine how much easier it would be to implement new features without needing to support every bleeding flat platform, voodoo-doll script and DEH nightmare (batman.deh).

The dirty hacks will continue because the mappers using them don't specifically target ZDoom. In ZDoom maps I haven't seen any crude hacks for a long time. The things you list are all required to be supported in the future. Bleeding flats are a side effect of the renderer and I even managed to get them to work quite well with my hardware renderer, VoodooScript is trivial to support and why drop DEH? Granted, Batman is indeed a nightmare but I think that WAD is beyond repair anyway

Some of us programmers need to show up on the IRC or something and discuss a new map format. ZDoom needs an update very badly.

Yes, it does. But so far any discussion has gone nowhere because people like Deep are constantly torpedoing any discussion that doesn't go into the direction they prefer. The only thing that works is to actually do something. I think I have worked this out to a degree that can handle everything ZDoom needs. But I have no desire to discuss this further. I want to implement it and when that is done it can be fine tuned.

My view might sound self-destructive to the future of ZDoom, but it worked for a lot of the other projects I have worked on.

Only the part of abandoning old features. That would indeed be self-destructive. ZDoom doesn't live in a world of its own. It is still part of the Doom community and large parts of that need compatibility.

[Enjay]

@Bio - what you are saying is very similar to something I was trying to say a while back. 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. Throw out anything that is a barrier to Zdoom's development and go with the new features. Ensure basic playability but only slavishly retain backwards compatibility for various tricks, hacks and odd situations if there is no harm in doing so.

However, I think I have come (almost) full circle on this. 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.

The reason I say "almost" full circle is that already there is a port (a few actually) that cannot support all the tricks and hacks. Ironically the one I have in mind is by the person who argued so strongly and well against me when I brought this up a year or more ago - Graf Zahl. GZdoom by its very nature cannot do some things. A simple and obvious example is that mid textures and sprites cannot be set to extend into the floor/ceiling. Now, whilst this example is unlikely to break the ability to play a map to the exit line, it does spoil a few things - fake reflective floors don't work, barons and hell knights quite often get the tops of their heads chopped off in short rooms, etc. But would I want to have GZDoom without OpenGL? No, of course not (there would be little point). I'm happy to sacrifice backwards compatibility with certain WADs and tricks to have the full benefits of hardware rendering. So the principle is established there already, from a certain point of view.