Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Kira

Make a GPL fork of GZDoom?

Recommended Posts

Making GZDoom GPL is a sensitive matter because the licensing is a mess and removing or replacing code will ultimately impact the user.

So, I was wondering: is it possible to make a fork of it and mess with the code without impacting the current state of GZDoom and make a proof-of-concept of a zdoom/gzdoom derivative that can be relicensed as GPL?

It would be ugly, but it could be a basis for future works.

In order to do that, and if I'm correct, we'll need to:

- remove Build code (mscinlines.h, gccinlines.h, asm_ia32/a.asm, r_polymost.cpp, r_things.cpp, r_segs.cpp, r_draw.cpp) => according to Ken Silverman, the opengl rendering doesn't use his code. Thus we'll have to disable the possibilty to set software rendering if we make a mess by removing it, right?

- remove oplsynth code => another ugly thing to do if I'm not mistaken.

Edit : *As fraggle mentionned, we could replace the OPL synth with the equivalent code from Chocolate Doom*

- replace FMOD Ex by OpenAL => perhaps the hardest task and the one that will impact the fork the most. Is it even possible? Will we have to ultimately dump out all of the sound thingies like SNES playback, reverb stuff or the music slider?

According to Randy back in 2008:

IMO, you don't need to separate the FMOD code into a separate module. Just make the FMOD DLL delay-loaded and provide a fallback if it can't be found. Also make the code conditional so it isn't required for compilation. As long as a library it isn't required for a GPL program's operation, the library doesn't need to be GPL-compatible. That's my understanding of it, anyway.

Wouldn't it be a start before other steps? I mean, the FSF wouldn't be happy but couldn't it make easier to finally dump out FMOD Ex?

Edit : *As Trasher][ mentionned, we could take a look on the active experimental branche of ZDoom that change the sound code to make a switch between FMOD Ex and OpenAL*

kmxexii said:

Here is the OpenAL in ZDoom thread.

Here is the OpenAL branch.


Speaking of that, I'd like to know how does this code interact with GZDoom... In short, a detailed roadmap to make this ugly proof-of-concept a reality. I'm not a programmer and my understanding of it is very limited (and I guess it shows!), but I'm eager to learn more about the possibilities.

Share this post


Link to post

IIRC this is something Graf wants to do at some vague point.

There's a fork on the ZDoom SVN working on adding a switch between FMOD Ex and OpenAL so that the engine can use either one as preference and licensing allows. I'd recommend looking into that.

The SNES stuff is part of the Game Music Emu library, which is LGPL.

Share this post


Link to post

It is a great idea fraggle, I'll take a look into it.

Trasher][ said:

There's a fork on the ZDoom SVN working on adding a switch between FMOD Ex and OpenAL so that the engine can use either one as preference and licensing allows. I'd recommend looking into that.

Do you remember the name of the fork? It is interesting!

Share this post


Link to post
K!r4 said:

It is a great idea fraggle, I'll take a look into it.


Do you remember the name of the fork? It is interesting!


Here is the OpenAL in ZDoom thread.

Here is the OpenAL branch.

Share this post


Link to post

It might be worth mentioning that Odamex is actually a GPL fork of ZDoom 1.22. It uses SDL + SDL_Mixer + Portmidi for music. Also there is no BUILD code because it uses a version of ZDoom before the code was implemented. Odamex is reimplementing features from future versions of ZDoom while trying to dodge code that is potentially GPL incompatible.

Odamex is not using the GZDoom OpenGL renderer code, but it did have a fork for its own custom OpenGL renderer that was never finished.

Share this post


Link to post
K!r4 said:

In order to do that, and if I'm correct, we'll need to:


I already had my thoughts about that, too.
Here's what needs to be done:

- remove the entire software renderer. It's littered with Build code throughout. No way to save it as it depends on said code completely. I already separated all of this inside the project so that taking it out won't be a big issue. This includes the Build-based asm modules, too.

- mscinlines may be an issue but not a big one. It only contains relatively trivial math and the only other way to write it in asm would be to replicate it. So I'm wondering, how much copyright anyone can claim on it at all. When in doubt, use the C version.

- OPL synth needs to be replaced, as mentioned.

- And of course the big issue that has held this license change back: Get rid of FModEx. If OpenAL was a somewhat decent sound management library, maybe. However, the reality looks different. It got a crap interface, no callbacks whatsoever and works completely counterintuitive to how sound is used in games. As a result it's hard to find programmers that can deal with it. The guy who did the OpenAL branch is a Linux developer with no Windows experience and as a result crucial parts of the whole system depend on stuff that's taken for granted on Linux but a mess to install on Windows. As a result streaming music doesn't work. (That includes SNES and module playback as well because they are implemented as custom streams. The good thing here is that if someone manages to get streaming to work with OpenAL the entire music system is good to go, including the more exotic music formats.)

K!r4 said:

Speaking of that, I'd like to know how does this code interact with GZDoom... In short, a detailed roadmap to make this ugly proof-of-concept a reality. I'm not a programmer and my understanding of it is very limited (and I guess it shows!), but I'm eager to learn more about the possibilities.


Find me a qualified OpenAL programmer and the whole thing should be good to go. The rest is peanuts.

And please, nobody mention SDL_Mixer. That abomination is a dead end.

Share this post


Link to post

The biggest incentive to use SDL_mixer, for me and I think others as well, has always been its cross-platform native MIDI support. Even that has been rather buggy, though. I've often wondered if it might save a lot of trouble if we simply created a new native MIDI wrapper library to do the job instead. Having looked at DOSbox's native MIDI code in the past, it actually looks pretty straightforward.

Share this post


Link to post

I've seen that OpenAL is used in the Doom 3 engine which is now under GPL v3. Couldn't we get some insight from it?

Share this post


Link to post
fraggle said:

I've often wondered if it might save a lot of trouble if we simply created a new native MIDI wrapper library to do the job instead.


I found PortMidi easy to work with.

Share this post


Link to post
fraggle said:

I've often wondered if it might save a lot of trouble if we simply created a new native MIDI wrapper library to do the job instead.

Oh my GOD somebody please do it >_>

Share this post


Link to post
K!r4 said:

I've seen that OpenAL is used in the Doom 3 engine which is now under GPL v3. Couldn't we get some insight from it?



It depends. The problems are not normal use as a sound library. That part pretty much works in the ZDoom OpenAL branch. The big issue is music streaming. I have no idea how to implement that with OpenAL's messed up interface and in addition we need to provide all the decoding functionality for supported sound and music formats.

Share this post


Link to post

Too much iPhone specific Objective C code in there. My god, that 'language' tends to make code completely incomprehensible...

Anyway, I wonder why this has to be coded by the application. Any good sound lib has streaming threads and callbacks as part of the core. But not OpenAL. There the application has to do it and deal with all the weirdness that's better encapsulated deep within the lib itself.

Well, it doesn't really matter. You'll have to find someone who can deal with all this and make it work on both Windows and Linux. So far I haven't found such a person.

Share this post


Link to post

Too bad... It seems that we have a lot of litterature on the subject on french forums, like how to stream .ogg with OpenAL on Windows... I guess I could read all of this and try things when I'll be in vacation in two weeks. Just for the sake of understanding how the heck it works.

Share this post


Link to post

Hi,
Sorry to bring up an old thread but..any news on this.

Would like to add GZDOOM to "Doom Touch" for Android, the license is stopping this.

Am I right in thinking it's now just a case of removing software mode (Build license stuff) and sorting out FMOD?

Cheers!

Share this post


Link to post

I vaguely remember talk of OpenAL not supporting the reverbs that can currently be used in ZDoom. Is this correct? It would be a shame to lose that feature if so.

Share this post


Link to post
Enjay said:

I vaguely remember talk of OpenAL not supporting the reverbs that can currently be used in ZDoom. Is this correct? It would be a shame to lose that feature if so.

I guess "reverbs" is a feature that could jauntily get sacrificed if that would pave the way to get the whole GZDoom source code relicensed under the GPL.

Share this post


Link to post
beloko said:

Hi,
Sorry to bring up an old thread but..any news on this.


Have you checked how much time has passed?
Have you counted the number of offers to help? (Hint: it starts with 'z' and ends with 'o'.

In other words: There hasn't been any progress whatsoever.


The main roadblock is still the same as two years ago. I still haven't found any OpenAL based music streaming code that actually WORKS!

Share this post


Link to post

Unfortunately it's utterly useless because it sidesteps all the issues with multithreaded streaming by doing it in the main thread's sound update function.

ZDoom implements a rather complex callback based streaming interface but so far nobody I know has managed to do something comparable with OpenAL. The problem is not just start a streaming sound but to do it in a way that actually works as it needs to.

Share this post


Link to post
fabian said:

I guess "reverbs" is a feature that could jauntily get sacrificed if that would pave the way to get the whole GZDoom source code relicensed under the GPL.


I think that it might be enough for me to jauntily ignore the GPL branch actually. I love the reverb effects and find them to be a hugely atmospheric and important feature of (G)ZDoom. Losing them to get a GPL version of the game (something that is pretty irrelevant to me when it comes down to it) would be disappointing to me to say the least.

Share this post


Link to post

If a working OAL implementation ever materialized I'd rather dual-license the code because I wouldn't want to lose the FMod based effects, too.

Share this post


Link to post
Graf Zahl said:

Unfortunately it's utterly useless because it sidesteps all the issues with multithreaded streaming by doing it in the main thread's sound update function.

ZDoom implements a rather complex callback based streaming interface but so far nobody I know has managed to do something comparable with OpenAL. The problem is not just start a streaming sound but to do it in a way that actually works as it needs to.


I've done stuff with OpenSL on Android (not OpenAL), OpenSL does use callbacks though.

Would getting this to work be a case of creating a thread to mimic the call back and shift data to OpenAL? Or is it more complex than this?

Share this post


Link to post

Unlike OpenAL, which was apparently designed by imbeciles, OpenSL looks to be a nice and sane API. But they seem to be completely incompatible (not surprising, because that'd bring back OpenAL's insanity. :D )

Any work done for OpenSL would be of no help with OpenAL.

And the fact that OpenSL only appears to exist for mobile devices surely doesn't make it appealing to me as an FMod replacement. GPL with sound only working on Android is of no use to me.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×