Switching ZDoom to Eternity's Cardboard renderer

[Michi]

I'm not making this as a feature suggestion but to start a discussion.

As we all know, ZDoom's biggest obstacle in becoming GPL compatible is the software renderer, which as anyone with some programming knowledge may confirm, is not only littered with problematic Build code but overall also quite messy and inflexible to change.

Looking at the rest of Doom ports one automatically will come across Eternity which seems to be the only engine that has dared to do a complete renderer rewrite, and not surprisingly, the results are probably the best among all source ports using software rendering.

So would it be feasible to switch to the Cardboard renderer in ZDoom? Does the engine use any features this renderer cannot do? And most importantly, what would have to be sacrificed to do this?

[Gez]

Things that Cardboard does not handle:
1. Voxels
2. 3D floors
(3. Camera textures?)

Everything else would probably be handled, or at least handleable with minimum work besides adapting it to ZDoom's codebase.

[Graf Zahl]

Camera textures are not an issue because they are not actually part of the renderer itself. All they do is render the camera's view to an offscreen surface and use the generated image as texture.

Voxels and 3D floors are indeed the big issues, but since the renderer supports portals it should be somehow possible to get 3D floors to work somehow.
Voxels, on the other hand, are a problem - not because there is no code handling them, but because the existing code is not GPL compatible.

Another roadblock would be Randi's rejection of OpenAL. As long as FMod remains part of the equation it won't look good.

That said, my personal interest is relatively low here, I'm more a hardware rendering type so if an attempt is ever started it'd most likely require an external contributor.

[Michi]

Hm, I didn't think about the 3D floors, that could indeed be a problem.

I think FMod is not worth it. Even if the OpenAL backend still has some problems they should be solvable.
Reading this though, is certainly not particularly encouraging. Such an attitude will cause more harm than good.

Seems like the only way getting out of this trap is to fork the code and make it as a separate project...

[edward850]

Reading this though, is certainly not particularly encouraging. Such an attitude will cause more harm than good.

How so?

[Michi]

How can we get rid of such a bad licensing obstacle as FMod if the lead developer outright says that he gives a shit about the only viable alternative?

I think the general consensus here in the community is that going GPL would be the best possible thing, yet ZDoom is dead set on keeping some code in that can't ever be GPL compatible - for more than questionable reasons.

I think we agree that both OPL and FMod shouldn't be the roadblocks they are, there's alternatives - and yet the decision does not go down to 'this has the better license' but 'this has the better API'. Which for supposedly free software is a killing blow.

[edward850]

You seem to be putting words into other peoples mouths there as to what's apparently killing things. I don't think ZDoom is in any risk of just up and dying if it doesn't suddenly up and drop the license it has had for the past 15 years with no issue.

[Arctangent]

I think the general consensus here in the community is that going GPL would be the best possible thing, yet ZDoom is dead set on keeping some code in that can't ever be GPL compatible - for more than questionable reasons.

To me, it seems like the opinion here is that it would be nice but not necessary. Especially with the advent of Gloome - if someone wants a GPL engine for game creation, then that's perfectly viable. ZDoom is ultimately an id tech 1 source port, not a commercial game engine.

and yet the decision does not go down to 'this has the better license' but 'this has the better API'.

I would imagine that usability is more important than a license, yes.

[Graf Zahl]

You seem to be putting words into other peoples mouths there as to what's apparently killing things. I don't think ZDoom is in any risk of just up and dying if it doesn't suddenly up and drop the license it has had for the past 15 years with no issue.

And you seem to confuse a few things.
What Randi said was 'I don't like OpenAL because the API sucks'. And quite literally.
What Randi did: Make it clear that he has no plans supporting OpenAL in future official builds.
Nobody said anything about a dying port, Michi's statement was 'does more harm than good.' - which includes discouraging others from working toward a GPL-friendly solution.
As for Gloome:

To me, it seems like the opinion here is that it would be nice but not necessary. Especially with the advent of Gloome - if someone wants a GPL engine for game creation, then that's perfectly viable. ZDoom is ultimately an id tech 1 source port, not a commercial game engine.

Don't forget that Gloome is a pure OpenGL engine and worse, intentionally being based on an obsolete code base (for supposedly 'better compatibility'), and that may be a major turn off for many, many users here.

and yet the decision does not go down to 'this has the better license' but 'this has the better API'.

I would imagine that usability is more important than a license, yes.

Not if it gets in the way of not being able to use other code one may like to use but can't because the license won't allow it.
This is a typical effect of focussing on the details, rather than the big picture.

[Michi]

Nobody said anything about a dying port, Michi's statement was 'does more harm than good.' - which includes discouraging others from working toward a GPL-friendly solution.

Indeed. I think Randi's reaction to the OpenAL branch finally being done was quite disappointing. Instead of some positive remark and maybe some outlook how this may continue, all we get is a stupid rant about the admittedly strange *API*! As if that wasn't the most inconsequential part of a module that's mostly finished and done with...

[Kinsie]

As if that wasn't the most inconsequential part of a module that's mostly finished and done with...

It's not inconsequential when you have to deal with it as part of your hobby project.

[Blzut3]

For most of the users the choice in license makes no difference. The effect of ZDoom not being GPL is that a handful of people can't trivially sell their mod? I think that shows a bit of arrogance or at least entitlement. Some vague fear that the licensing terms might technically not be 100% in line? ZDoom has been around for 17 years and I'm fairly certain it's (or at least one of its children) is the most popular Doom source port out there. It's not exactly operating under the radar.

Yes, being able to use FMOD and build code is more important than the license. Just think for a moment that the reason ZDoom has historically had better audio and was the first to implement voxels is entirely due to being able to use the best tool for the job. Not artificially limiting ourselves based on some vague ideal. The licensing situation of ZDoom doesn't hurt the project at all since as a result the code we do write is actually even more liberally licensed than the GPL ports. To put it another way, I don't think losing Randi is worth fixing a super minor licensing issue.

[Graf Zahl]

To put it another way, I don't think losing Randi is worth fixing a super minor licensing issue.

Not that I care much about the software renderer - but doesn't that 'super minor licensing issue' actually get in the way of the topic of this thread???
I haven't spent much time investigating Cardboard but the one thing I can immediately tell from the source is that it far less relies on global variables which are a massive problem with ZDoom's renderer and blocked implementation of quite a few features because I was unable to figure out how to handle them. What immediately comes to mind is per-tier colored lighting or sector/wall color transfers similar to light level transfers.

(You also got to convince the GPL mafia over at Doomworld that it's super-minor. If you read their discussions sometimes one can get the idea that it's a massive problem... )

[Enjay]

For most of the users the choice in license makes no difference. The effect of ZDoom not being GPL is that a handful of people can't trivially sell their mod? I think that shows a bit of arrogance or at least entitlement. Some vague fear that the licensing terms might technically not be 100% in line? ZDoom has been around for 17 years and I'm fairly certain it's (or at least one of its children) is the most popular Doom source port out there. It's not exactly operating under the radar.

This is pretty much how I see it.

GPL is utterly irrelevant to me. I don't get why it is such a big issue to some people in this particular, very small, very specific branch of hobby coding. What real difference wouold it make to anything?

From what I've seen of the Doomworld discussions (before I fall asleep reading them /yawn), I get the impression that GPL actually causes as many problems as it solves. I know that it is meant to free things up, but it seems to come with so many strings and restrictions (and hang-on zealots too) that it doesn't seem worth it to me. Indeed, most of the ZDoom "problems" when certain code inclusions are suggested come from lack of GPL compatibility. Now you could say that's because ZDoom should be GPL compat or you could look at it from the other side and say it's because GPL is too damned restrictive to allow code licensed under it to be included with certain other licenses.

And I like what Randy has done with FMOD too.

[edward850]

I haven't spent much time investigating Cardboard but the one thing I can immediately tell from the source is that it far less relies on global variables which are a massive problem with ZDoom's renderer and blocked implementation of quite a few features because I was unable to figure out how to handle them. What immediately comes to mind is per-tier colored lighting or sector/wall color transfers similar to light level transfers.

It got me thinking, and it would seem the marginal globals and the fact that the rendering input/output points are largely the same would mean this wouldn't be too hard to test. The only key limitation would be being unable to make a single public commit or build at all with it until permissions could be sorted out.
However it would be useful to at least test it to compare performance properly. It's a higher precision renderer, and it doesn't rely on assembler extensions for even transparency, so getting a proper bench comparison between the two would be nice to have.

Do we know the Eternity team's stance on the licensing? It certainly wouldn't be impossible to ask, as even SoM hangs around on IRC from time to time.