ZDoom

Thanks everyone for the great information.

One note, much (or possibly all) of the copyright content in GZGPL's version of gzdoom.pk3 is replaced with "programmer graphics" or empty sprites (blank image), such as the rocket trail and the Player Crouch sprite.

xBRZ is a funny issue because I plan to completely disable it, and hqx, in my distribution, purging its code entirely once I safely figure out how. But anyone using it should replace the .jpeg with a copy of GPLv3.

Great news about MAME's relicensing, I would love to see its stuff make it back into the build! I was looking at some info and wondering why we couldn't have DOSBOX OPL (gpl) instead of MAME's, and not have OPL fully disabled, but I wasn't sure if that would be reasonable to even implement in the first place. In any case, I had made some Sega Genesis/Megadrive music in Deflemask awhile back, and wanted to try to make it work with the GZGPL game.

I'm sure I will have more questions. I'm assuming that GPL2 or 3 are my only options for licensing at this time, regardless of any smaller licensing changes.

Sorry if I'm misunderstood about anything!

About OPL, the issue isn't just the old MAME core (it could be removed entirely, we've got several other OPL cores available) but MUSLIB which is under a really weird license.

Those 20kb Muslib code, that's an actual problem - and sadly most is rather trivial stuff that will be very hard to refactor into something different.
The license for that is actually pretty close to Ken Silverman's license in that it allow free use unless no commercial exploitation.

Okay, I won't wait up for that one. Is there anything else I should know?

This may be out of scope but, out of curiosity, are there any GPL-compatible options for emulating FM synth of any kind, where I'd also be able to find a good editor to make them in? (Like old-school PC trackers etc.) I like Yamaha/Roland-esque stuff a lot so I'm openminded about what exactly to use. I have light experience in trackers and FM, and no experience in MIDI. I can try to find this myself obviously but someone else might have a better recommendation as to what could actually be implemented in GZDoom. Right now I am just using songs in .ogg format... sounds great but it really slows down the level loading times.

Graf, I have one more question, I've read that in the past GZDoom has had compatibility issues with ATI video cards, but today, that would just be an issue with very old ones, and not current-gen AMD GPUs and APUs? And is that even still an issue at all? I have been reading some very old information which doesn't offer any conclusion to the matter. I have an AMD APU I can test with anyway, just curious.

About ATI, there are some issues with old drivers. The known ones are:

- some old OpenGL 2.1 drivers show some graphical corruption. But the affected hardware has almost completely disappeared, so far I got one report about this problem
- some early GL 3.x drivers display no sprites, but all affected hardware can be fixed with a driver update - the affected drivers are in general obsolete.

Big news... Rachael asked Ken Silverman permission to allow the voxel code to be GPL, and the ladder said yes...

Danfun64 wrote:Big news... Rachael asked Ken Silverman permission to allow the voxel code to be GPL, and the ladder said yes...

What ?? Where is the democratic process here ??
The rungs have no say in this ?

But, that is great news.

These are not the droids you are looking for.

(incomplete - needs audit, and has run-time errors, but otherwise it compiles)

(voxel code used with special permission)

Spoiler: absolutely nothing to see here

---

Rachael wrote:These are not the droids you are looking for.

(incomplete - needs audit, and has run-time errors, but otherwise it compiles)

(voxel code used with special permission)

Spoiler: absolutely nothing to see here

---

This is so so soooo good.
Will qzdooms 32 bit rate make it in at some point, or are there licensing issues in the way?

As far as I know there are no licensing issues. One of the Doomworld licensing gurus probably could look at it just to be sure. It should be good for a straight pull, though, if Nash wants it.

Thanks to Rachael and dpJudas for allowing me to include QZDoom's software renderer with GZDoom-GPL.

GZDoom-GPL now officially has software rendering again. The latest (and only) devbuild will have it.

Happy game-making!

Nash wrote:Thanks to Rachael and dpJudas for allowing me to include QZDoom's software renderer with GZDoom-GPL.

GZDoom-GPL now officially has software rendering again. The latest (and only) devbuild will have it.

Happy game-making!

I ask, and I receive. Holy crap, that's awesome. Can't wait to try it out! (I'm at work now)

I pulled a GZDoom update (that had a merge conflict - easily resolved) and pushed a couple bug fixes that dpJudas just did. The fixes include dynamic lights on the span drawer, and screenblocks<9+vid_hw2d false crash.

Rachael wrote:(that had a merge conflict - easily resolved)

I panicked slightly a few minutes ago when I ran into this - fortunately with some resourcefulness, I managed to track down where the file is after dpJudas'ification and fixed it in my end. I hadn't seen your fix yet then, and crosschecking with your updated branch, it appears that I fixed the correct file. Hey, at this point I may learn something about the software renderer after all! XD

But thanks for the other QZDoom fixes too - merging in now!

The merge conflict was caused by Graf backporting one of my fixes to the old software renderer (that I pretty much do not touch anymore now anyway). Since that's long gone from your repository anyway, simply merging QZDoom (where it was already rejected previously since I don't have the file) fixed it automatically.