[source] GZDoom-GPL - GPL'ed GZDoom for indies

[Nash]

tl;dr get it here

What is this?

GZDoom-GPL is a GPL-compliant fork of GZDoom derived from LavenderMoon's GPLZDoom codebase.

I'd like to give a HUGE shoutout to LavenderMoon who did the bulk of the initial work which makes it possible for this thing to exist today. I am merely just doing grunt work to keep his work constantly updated with the official source code.

Goals

- To be in perfect (or near-perfect) synchronicity with mainline GZDoom, so that means engine features will stay up-to-date and bleeding edge.
- Provide indie developers who are interested in using GZDoom for their game a clean and up-to-date codebase upon which to start building their game from.
- Clean commits when updating the codebase (no mega commits (meaning one issue at a time), descriptive commit messages, etc)

Difference between GZDoom-GPL and other similar projects?

- GZDoom-GPL will not implement new features that are not implemented mainline. This is to ensure synchronicity with GZDoom's source code.

y u do this?

I did this for myself initially; I wanted a clean GZDoom codebase to work from that is up-to-date with mainline and benefit from the bug fixes. I've decided to put this online because I am sure there are other aspiring developers who would find this useful. It is up to the individual to take the source from here and implement whatever custom features they want for their game.

Please understand

To ensure GPL-compliance, these features had to be removed and are not available in GZDoom-GPL:

- ZDoom's software renderer
- FMod Ex sound system
- OPL synthesizer

This is currently on-going work; I will further investigate the source code and find anything else that could be removed to ensure GPL compliance.

There are currently no binary builds because it would be pointless from a player's perspective; it behaves exactly like GZDoom on the outside. This is more of interest to indie developers who want to make standalone projects.

Where to get it?

> Github source repository <

You will need these to build the source code (consult the wiki for more details on building for Windows/Linux/Mac OSX/Solaris):

- Minimal DirectX SDK (only 4.25 MB! Use this if you don't want to download the full SDK)
- OpenAL
- libsndfile
- libmpg123 (optional)

Notes: once GZDoom officially goes GPL, this fork will be obsolete and will be removed.

Hey, ur code is outdated!!!11

I do my best to keep this fork as close as possible to GZDoom, but if it appears to be left behind, feel free to tweet me at @NashMuhandes and I'll get right to it!

[Hetdegon]

So many attempts of making a distributable (publishable?) gzdoom engine lately. How is this different from that GLOOME one that has been mentioned often as of late?

Now, I agree with the idea, and might even use it. Having more multiplatform engines for devs to use is always convenient, but just to play devil's advocate for the sake of discussion, since this seems to be a recurring idea lately...
If this is something that would allow someone to say publish a game on Steam or similar, what advantages do you feel it has over an engine such as Unity3D or Unreal? (maybe Godot if you count underdogs). Doom-style mapping requires a lot more manual effort to look wholesome, and careful tweaking to avoid FPS drops, and many potential players look away from "blocky games" even if the gameplay is wonderful.

Now don't get me wrong, I think it's totally viable to make a full game in GZDoom, as I am doing one myself (freeware and for the love of the craft, no plans to make it commercial), but to do something in Doom I need to spend more time to make it look presentable than in the other engines, and deal with more quirks and limitations as well. A hobbyist gamedev picking up Doom is going to spend more effort than in other engines, and only people that are already GZDoom users/modders will be really interested on working around the limitations because they are "emotionally invested" with it. ACS and DECORATE are competent systems, but they are only usable in Z, and they aren't not languages you can take with you for further adventures in development, even if ACS is C-ish. Model support is perhaps the largest disadvantage, as it's locked on a very outdated format that features no special effects (other than lightmaps that only seem to work reliably on MD2 models, unless that was fixed recently) and not all axes can be rotated on demand.

So what's your take on this? Again, I don't mean to be antagonistic or undervalue your work, I've seen the stuff you do and I fully respect it, I just want to know your opinion.

[raymoohawk]

iirc gloome uses an older code base to keep zandro compatability (dont quote me on this XD)

anyways its nice to see an effort like this, i wish you luck nash hopefully more and more indie games for doom engine will appear

[Nash]

Hetdegon - your question on "how is it different than GLOOME" is clearly already answered in the original post.

[PillowBlaster]

Ohhhhh yes, colour me and another few people interested!

[Hetdegon]

You mean it's more up-to-date with gzdoom's current code? (I see no reference of GLOOME in the original post here, and the GLOOME main post is more a declaration of intentions than a technical review, so forgive me if it's something that needs to be asked, as that post only lists a lower base version).
Well in that case what I don't see is a reason to go with GLOOME at all. GZDoom fixed a lot of things post 1.8.x, so...yeah.

Still, I'd like to know your take on the whole ease of use and convenience compared to other available engines for indies, which was the main body of my post. Now, again I reiterate that I find this interesting and usable. But that's because I am already invested in GZDoom. Again, this is no master troll question and I am just curious about your opinion, I feel that as a "product" it's going to be limited to people in these forums, and indies wanting to make something commercially distributable (because the concept of freeware died like 5 years ago in the scene at large) have other options available for free and use more "industry-wide" skills (C#/Mono, Lua, modeling stuff more advanced than MD3, shaders...) that can be used for a "career". Maybe I am reading too much in the "GZDoom for indies" tagline?

[Nash]

I have gotten a lot of negative vibes from naysayers on that... I'm done justifying why I still use ZDoom instead of Unity or Unreal (both of which I also use today actually). Let's just leave it at "because that person just wants to". You can do whatever you want with your time and efforts, no one can tell you otherwise.

GLOOME, although based on an older GZDoom codebase (therefore missing out on bug fixes) has some really advanced features that would never make it into mainline out of fundamental principles - read/write file access, INPUT scripts (so you can do in-game journals), flat sprites like in BUILD, among other things... so GLOOME is more feature-rich. But anyone who's serious enough with programming can easily merge that stuff into GZDoom-GPL's codebase themselves.

EDIT: all of your concerns are valid and I agree with most of them at any rate

Maybe check out Total Chaos, a standalone GZDoom-based project for a rough idea on why one would choose ZDoom over other engines.

[VGA]

Oh so GLOOME is GzDoom 1.8.10 with extra features and GzDoom-GPL is a continous fork.

Interesting, I hope someone tries to take off with some indiegogo crowdfunding maybe.

[Hetdegon]

Ah, okay I get it now. Since there have been a few attempts trying to make GZDoom attractive for random indies, I just wondered what the fuss was about.

As I said I am using GZDoom for a game, so it'd be hypocritical of me to be a naysayer, it was just legit curiosity.

[raymoohawk]

i really hope someone fuses the new features of glooome into a fork of this gpl'ed gzdoom

[kodi]

A good "justification" for doing indie games(or generally modding) in zdoom family engines is that the limitations Hetdegon mentioned breed creativity, and they also force you to focus on aspects that work in a simpler environment. Compare making a drawing with a stick of coal vs. painting with oil on canvas.

[TerminusEst13]

iirc gloome uses an older code base to keep zandro compatability (dont quote me on this XD)

Well in that case what I don't see is a reason to go with GLOOME at all. GZDoom fixed a lot of things post 1.8.x, so...yeah.

Oh so GLOOME is GzDoom 1.8.10 with extra features and GzDoom-GPL is a continous fork.

I don't know where you're pulling 1.8.10 from, GLOOME is faaar faaaaar faaaaaaaaaaaaaaaaaaar further than that. Zandronum compatibility isn't even a consideration at all.

That being said, Nash is a cool guy and more options on the market is always a good thing--I don't know why there needs to be comparison, people should be able to pick and choose based upon their preferences.
Marrub and I are definitely interested in seeing where this goes.

[Hetdegon]

I don't know where you're pulling 1.8.10 from, GLOOME is faaar faaaaar faaaaaaaaaaaaaaaaaaar further than that. Zandronum compatibility isn't even a consideration at all.

That being said, Nash is a cool guy and more options on the market is always a good thing--I don't know why there needs to be comparison, people should be able to pick and choose based upon their preferences.
Marrub and I are definitely interested in seeing where this goes. :D

Oh, because of:

GLOOME:

GLOOME is a commercial-friendly GPL-compliant rebrand of the GZDoom 1.8.10 engine, which is based on the ZDoom engine, which in turn is based on id Software's Doom engine.
It's a little bit incestuous.

My bad then.

[TerminusEst13]

Oh, I understand now. GLOOME forked from that originally, but there's been a lot of our own fixes, tweaks and adjustments since then, going in a different direction.

My mistake, sorry for the misunderstanding (and slight derail).

[Nash]

Term (and everyone else who seems to be confused):

This was never meant to be a competition to GLOOME. In the OP, under "y u do this", I wrote that I did this for myself because I wanted a clean slate to work from. GLOOME is amazing and as of this post, I am actually still using GLOOME for my project... but as time goes on, GZDoom is constantly being updated with official new features and fixes and I really needed those... and I find that I think it's better if I work off the official GZDoom codebase and just go from there (removing and adding stuff as necessary). This was impossible for me to do with GLOOME's codebase because, as has been said, GLOOME goes in a different direction by adding more (very useful) features... making managing and merging the codebases just confusing and difficult for me.

I put this up because I'm sure some people would find it useful to work with what basically boils down to "latest version of GZDoom but in GPL". People who can't be bothered to build their own programs will definitely prefer GLOOME because it is more feature-rich and generally just more "ready for mass consumption" so to speak. On the other hand, what I put up here is purely bare-bones.

Marrub and I are definitely interested in seeing where this goes. :D

I will continue to update this as soon as GZDoom gets updated. If I find anything GPL-unfriendly code that may have been missed, I will clean it up. If Graf Zahl makes GZDoom fully GPL, I will delete this project. That's all that's going to happen I think. :P