Vavoom and GPL

[Ralphis]

Vavoom's site says that it is GPL. Is the engine actually compatible with the license? Have they re-written Zdoom code in order to be compatible with ZDoom features? Does it have build code for boundary calcs? Can anybody answer these question?!?!

Thanks in advance!

[Gez]

There's a lot of parts that are taken from ZDoom wholesale, with just a few minor changes to account for differences in underlying architecture, and the license changed from BSD 3 points to GPL. Definitely not rewritten from specs. Randy is generally okay with relicensing his code to GPL (e.g., Odamex exists). So what matters is whether any of the troublesome bits are there in Vavoom.

On a cursory glance, I don't see the asm files from Build, and Vavoom no longer features a software renderer so pretty much nothing from Build seems to be there. I also don't see the MAME-derived OPL emulator.

So it seems okay, considering the original code from Id and Raven is GPL already.

[tempun]

Gez said:

On a cursory glance, I don't see the asm files from Build, and Vavoom no longer features a software renderer so pretty much nothing from Build seems to be there.

It was Quake-derived anyway.

[Ralphis]

To be less cryptic, here is why I am asking:

I am still looking for an existing alternative to build's boundary calculations (used by ZDoom since 1.23). A GPL compatible alternative to these would likely be very useful to a variety of engines for movement on slopes and other surfaces. Engines like Odamex would be able to backport the actual slopes from 1.23 (actually written by Randy), Eternity would have an easier time (as far as I've heard) as well since they already actually render slopes.

So to be more specific, how did software Vavoom approach these calculations (assuming software vavoom had slopes, which if I remember correctly, it did)? Does anyone know off hand without a lot of digging?

[Graf Zahl]

Software Vavoom was just like a hardware renderer - with the only difference that the actual rendering was done in software.

But all the important stuff was completely different from Doom's renderer and in no way compatible.

Regardless, it's not really clear what you are talking about. It sounds like you are referring to the movement code. What part in there do you think comes from Build? All related code is in p_map.cpp which doesn't have any Build code to my knowledge because Build's and Doom's physics code is completely incompatible.

I think the only thing in there that has some Build roots is the secplane_t class but since that's just basic math there's no way it could ever be copyrighted.

[natt]

Graf Zahl said:

but since that's just basic math there's no way it could ever be copyrighted.

For now...

[Ralphis]

Pardon my ignorance as I'm no programmer, but I will do my best to explain the situation as I understand it.

I asked Randy two years ago: "Are the slopes in 1.23 from Build?"

He replied:

The slopes themselves were (and still are) entirely my own code. The part that's from Build is the wall boundary calculations. The way Doom did it was too imprecise for any useful sloping, so I was in the process of rewriting it to use the standard perspective divide equations, then Build's source was released, and I saw I was going in the same direction as it, so I just used its code to save myself some time. I don't think I ever released anything with slopes but without Build code, however, and thanks to Seagate's crappy firmware, I no longer have any archived source code beyond what's already on available from zdoom.org/files, so here's a list of Build-touched functions (in the current release; some of them, I'm sure, aren't present in 1.23):

*R_AddLine: Everything before

backsector = line->backsector

*R_RenderDecal: Uses the same projection code as R_AddLine. It's just standard perspective divide stuff, so anything you rewrote it with would probably look like basically the same thing.

*wallscan/maskwallscan/transmaskwallscan: multicolumn rasterizers straight from Build

*OWallMost/WallMost: calculate top and bottom edges of walls, also straight from build

*PrepWall/PrepLWall: calculate texture coordinates and scales along a wall, for use with wallscan

*a.asm: everything in here (probably called a.nas in 1.23)

There might be others, but I'm pretty sure that's all of it. The wallscan prep routines are basically all for splitting up R_RenderSegLoop so that it can draw four columns at a time instead of just one, which can be significantly faster depending on your processor's cache. You could remove those and go back to the old R_RenderSegLoop without affecting slopes, but there will be a significant performance hit.

Long story short: I'm trying help search for a possible way to get slopes implemented in Odamex sometime in the future while using code that is compatible with its license.

[Graf Zahl]

I think you'd be better off using all of Eternity's renderer then.

If there's one thing in ZDoom I mostly consider a lost cause it's the software renderer. It's a hopeless mess of code that can never be made to work again without removing all the Build code in there.

I wouldn't hesitate a second to dump all of it in GZDoom if I could change its license to GPL.

[Ralphis]

The problem (and excuse me if I seem to be explaining this incorrectly, someone else on the Odamex team like manc has a better handle on this) is that although Eternity has slopes as of now, you pretty much walk right through them because there is no boundary detection. Essentially, they're purely visual as of now and I've heard little to indicate that Quasar has found or begun to implement a solution. The problem is the lack of precise clipping, not the actual rendering of the slopes. It is possible that I'm wrong about this but it is how I understand the current situation at a layman level.

With Odamex, porting the zdoom 1.23 slopes back would be a much easier solution as the code base is relatively similar (compared to Odamex/EE at least). Ultimately, the goal behind all of this is to be able to support the standard competitive CTF maps that ZDaemon/Skulltag currently run. The only obstacle really left in the way are slopes.

I hope I haven't come off as a broken record!

[tempun]

Ralphis said:

The problem (...) is that although Eternity has slopes as of now, you pretty much walk right through them because there is no boundary detection. Essentially, they're purely visual as of now and I've heard little to indicate that Quasar has found or begun to implement a solution. The problem is the lack of precise clipping, not the actual rendering of the slopes. It is possible that I'm wrong about this but it is how I understand the current situation at a layman level.

I *think* that the Randy's list of where the Build code is contains only renderer stuff. If this is correct, then you have no problem - you just use ZDoom's physics code and Eternity's renderer (don't you use it already?). You need to ask someone competent. "Perspective divide equations" suggest that it's about renderer, not physics.

[Graf Zahl]

Ralphis said:

The problem (and excuse me if I seem to be explaining this incorrectly, someone else on the Odamex team like manc has a better handle on this) is that although Eternity has slopes as of now, you pretty much walk right through them because there is no boundary detection. Essentially, they're purely visual as of now and I've heard little to indicate that Quasar has found or begun to implement a solution. The problem is the lack of precise clipping, not the actual rendering of the slopes. It is possible that I'm wrong about this but it is how I understand the current situation at a layman level.

Slopes have 2 parts of implementation which are completely separate.

The physics parts in the play engine and the rendering part in the renderer.

The physics parts can be used without problems in Odamex and it should be possible to combine them with Eternity's renderer. It's just the rendering part that's GPL-incompatible.

[Quasar]

For the record, slopes in EE are SoM's project until such time he indicates he is not interested in working on them any more. The currently active clip-branch is meant to have functional slope plane clipping/physics by the time it's ready to merge back with trunk.

[tempun]

Quasar said:

For the record, slopes in EE are SoM's project until such time he indicates he is not interested in working on them any more.

Does this mean that no other port can use them?

[Gez]

Why? It's GPL. The only active ports with an incompatible license already have working slopes; so any port interested in getting EE's slope code is perfectly able to do so.

By the way, EDGE also already has "detail slopes" as andrewj calls them; that is to say slopes rendered by the graphics engine but ignored by the physics engine.

[Quasar]

tempun said:

Does this mean that no other port can use them?

Nnnnnno.

It means that people shouldn't phrase things about them in terms of "when Quasar does so-and-so", as I am not currently working on slopes because they are SoM's baby.

[hawkwind]

Gez said:

By the way, EDGE also already has "detail slopes" as andrewj calls them; that is to say slopes rendered by the graphics engine but ignored by the physics engine.

Since EDGE is now hardware only I thought to mention that Risen3D also supports slopes for both rendering and physics, albeit a different method to other ports is used.