Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
Send me the most detailed screenshot you possibly can, showing as much game assets as possible - and I will make a colormap/playpal pair for you - royalty free.
COLORMAP
PLAYPAL
I would just use freedoom's one and gg
And I Always used the doom settings, I don't see that as a bad thing.
EDIT: Is there a point to use COLORMAP/PLAYPAL if you're only going to use png sprites/textures/font and opengl render?
ibm5155 wrote:COLORMAP
PLAYPAL
I would just use freedoom's one and gg
And I Always used the doom settings, I don't see that as a bad thing.
EDIT: Is there a point to use COLORMAP/PLAYPAL if you're only going to use png sprites/textures/font and opengl render?
it makes sense, though not large. Anyway if the game menu consists of images as in my case.
And it looks like the graphics in the menu depends on the palette.
Numbers are derived using Sbarinfo into a HUD, using the PLAYPAL.
And yet there is an option in the settings to "use the palette", interesting effect =)
GZDoom-GPL's first official, stable release. version 2.3.2 (based off GZDoom 2.3.2) is out now!
I am hereby changing my build and release models to mimic that of GZDoom - so there is a clear distinction between unstable devbuilds and "game-ready" stable releases (the latter being the ones you'd most probably want to ship your game with)
Would it be fair to assume none of the following elements still remain in GZGPL?
ZDoom borrows some elements from Ken Silverman's Build engine and tools, namely inline fixed point multiplication functions (mscinlines.h and gccinlines.h), some assembly code (asm_ia32/a.asm), voxels rendering (r_things.cpp) and part of the decal and wall rendering code (r_segs.cpp, r_draw.cpp). The Build license is non-commercial only and requires the following text to be placed in the code: -https://zdoom.org/wiki/license
I am rewriting the README.TXT in LICENSES folder, to include no mention of Build or Ken. This is appropriate?
The Readme that comes with GZDoom-GPL, in both the binaries and in src/docs are already up-to-date.
The only thing from Ken Silverman left in GZDoom is the voxel drawer, but even that's only in the software renderer - GZDoom-GPL doesn't have software rendering so that bit about voxels in GZGPL's Readme is irrelevant (note to self, will have to remove that).
I also just noticed that Doom License is still there. Since the entire package has been relicensed to LGPLv3, I'm wondering if it's a good idea to just remove any mentions of the original Doom License.
Edit: looked up some stuff about GZDoom LGPLv3 relicense
Okay so GZDoom is LGPLv3 now, will GZGPL remain GPLv3?
Is the Voxel code purged from the codebase, or just dormant/disabled due to the exclusion of the software rendering? It's still in the source somewhere?
I would scrape all questionable code(again I'm sorry, I'm unclear on the situation here, whether there are things lying dormant and disabled or not) and yes, delete mention of the deprecated licenses and unused resources. AFAICT, with dual licensing you can choose one or the other right?
Doom should specifically have its GPL2 license used, yes? I don't think I'd want any mention of the noncommercial license unless there's some legal reason i'd need to include it alongside its GPL2 version?
Parts of the voxel code in the software renderer use code from the
BUILD engine by Ken Silverman. See buildlic.txt.
This license file is gone but its reference remains.
xBRZ license is still a jpeg which only applies to Zdoom, and, noncommercially.
EDIT: I see that xBRZ itself has been removed.
I'm pretty bad with this licensing stuff but slowly learning the glut of GPL variants. It would be very helpful to have a guide on what it means when you have so many different licenses used and what the dev should do to keep everything clean, which variants are simple to release under, (I can still use GPL3?) etc. I know I'll have to get a clearer understanding of all this stuff myself but maybe we could get a "Dev's licensing guide README?" that would help a ton. This is the first time I have worked with open source software, or worked on a game, period.
I like the new logo. =)
Last edited by agenten on Mon Feb 06, 2017 12:37 am, edited 1 time in total.
Only the renderer is LGPL, there's still parts under problematic licenses. And you cannot release any Doom port under the LGPL, because id's code is either Doom Source License of GPL.
The remaining problem parts are one single function for software voxel rendering (true black magic code, unfortunately), the OPL music player and FModEx. FmodEx can theoretically be removed without consequences with the OpenAL backend, the OPL code needs some investigation about how a player with a better license can be integrated here, and the voxel function means that you'd have a software renderer without voxels.
Another issue is the content in gzdoom.pk3, there's some stuff in there based on id's original assets - you cannot use that in a free game.
xBRZ license has no meaning for GZDoom-GPL because all that JPG contains is some text allowing a linking exception for GZDoom to use that code despite not being GPL itself.
Graf Zahl wrote:the OPL code needs some investigation about how a player with a better license can be integrated here
MAME was re-licensed under GPL 2.0 a little under a year ago. If GZDoom were to go full-GPL (barring the pk3), there probably wouldn't be a whole lot of elbow-grease needed to make this part of the engine kosher.
That helps a lot indeed, because it allows 2/3 of the critical code to be kept. Although the MAME file has changed quite a bit, nearly all the parts in ZDoom can be fully reidentified, except for some changes possibly made by Randi.
There's 3 files left, altogether 35kb source which are from MUSLIB need to be reviewed. Some of that code is Randi's, my guess is that there maybe approx. 20 kb left, but this still needs to be replaced by free code.
Speaking of MAME chip emulation, maybe it'd be a good time to reconsider that revision to Game Music Emu I brought up in this long-since-[No]'d suggestion? Specifically, kode54's follow-up. IIRC its relicensing under GPL was the hold-up at the time.