Duke4.net Forums: Question about EDuke32's liscense - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Question about EDuke32's liscense

User is offline   Striker 

  • Auramancer

#1

I posted a feature request for on-disk texture cache for Zandronum, and referenced EDuke32 as a good example of how it should be done. One of the developers wants to know how EDuke32 does it, and is confused about EDuke32's liscense, so I'm going to link to the request, and hope someone like TerminX or another developer can help clarify things: http://zandronum.com...iew.php?id=1266
0

User is offline   Plagman 

  • Former VP of Media Operations

#2

The game code of EDuke32 (eg. Duke3D and its CON compiler) is under the GPL. The engine code of EDuke32 (eg. BUILD + its renderers) is under BUILDLIC. The two are separate components that link together, but my understanding is that when 3DR released the Duke3D source code under the terms of the GPL there was an understanding that they allowed it to be linked against the BUILD engine, because.. well it would be useless otherwise.

Anyhow, what EDuke32 does is that it loads a texture from disk using a lossless format like PNG, generates mipmaps from it, compresses them to DXT and writes the compressed mipmaps level back to disk such that next time it loads the texture, it doesn't have to do any of that and can just upload all the compressed levels of the texture directly into GL. In essence it's exactly the same as if it was shipping its assets as DDS, which is pretty much what all modern games already do, but allows for more flexibility since you can modify the base stuff and have it replicate automagically to the "compiled" asset.

The core functionality it uses to achieve this is glGetCompressedTexImage(). It wouldn't have to do this if it used an offline DXT compiler like libsquish, but right now it relies on the OpenGL driver to perform the compression. The problem with this is that some drivers simply do not support compressing texture on-the-fly and only accept pre-compressed textures for implementation (AMD drivers) or intellectual property (open-source Linux drivers) reasons.
0

User is offline   Plagman 

  • Former VP of Media Operations

#3

BTW, question for the developer: what code of ZDoom was taken from BUILD? I remember seeing a Doom port trying to use the Polymost code a while back, but I don't know if that ever panned out.
0

User is offline   Player Lin 

#4

http://zdoom.org/wiki/Build
http://zdoom.org/wiki/ZDuke
http://zdoom.org/wiki/Polymost

It's just too bad ZDuke got abandoned due the DooM engine and game logic problems.


Those BUILD code did cause some problems to prevent (G)ZDooM get GPLed(also have a other one problem, which is FMOD). And cause some of stupid dramas on the DooM community.

This post has been edited by Player Lin: 30 January 2013 - 09:52 PM

0

User is online   Hendricks266 

  • Weaponized Autism

  #5

Isn't it also because ZDoom is based on the original restrictively licensed Doom source release?
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options