GZDoom 3.3.0 released

[Korell]

Timidity++ is now built as part of GZDoom.
You do not need external libraries for ADLMIDI/OPNMIDI - they can be used as-is.
Only Fluidsynth and OpenAL itself still requires an external file and that's included with the distribution.

Thanks Rachael, that's great. I just gave them all a try and all options play now. I wasn't a fan of how ALDMIDI and OPNMIDI sounded, though, so I'll stick with either Fluidsynth or Timidity++. I noticed that the soundfont has been moved into its own folder now. Do we need to specify the soundfont within the gzdoom.ini file, as it still plays even if this is not set? Only if I choose to use a different soundfont and put it in the soundfont folder will I need to specify the soundfont folder within the path or just the SF2 filename?

[Graf Zahl]

(would still like to be rid of that error popup though... which also says "errors" for 1 error and doesn't identify the offending file correctly, really if we need to have this thing a big copypastable box showing the console output would be vastly preferable)

What are you talking about?

[Graf Zahl]

Thanks Rachael, that's great. I just gave them all a try and all options play now. I wasn't a fan of how ALDMIDI and OPNMIDI sounded,

Both are FM synths, not wave table, so they are more like OPL. Some people actually like that, strange as it sounds...

though, so I'll stick with either Fluidsynth or Timidity++. I noticed that the soundfont has been moved into its own folder now. Do we need to specify the soundfont within the gzdoom.ini file, as it still plays even if this is not set? Only if I choose to use a different soundfont and put it in the soundfont folder will I need to specify the soundfont folder within the path or just the SF2 filename?

You can dump as many sound fonts as you like into that subfolder and they will be listed in the selection menu for the synths. It will also fall back to something that can play if the settings are not correct, so normally with only gzdoom.sf2 present it will pick that up. There have been quite a bit of changes under the hood to make the music interface easier to use than it was before.

[Graf Zahl]

BTW, user engagement for the hardware survey is roughly 50% so far. A bit low, I have to say.

[Matt]

(would still like to be rid of that error popup though... which also says "errors" for 1 error and doesn't identify the offending file correctly, really if we need to have this thing a big copypastable box showing the console output would be vastly preferable)

What are you talking about?

This:
[imgur]https://i.imgur.com/cTUTnQx[/imgur]
Where I could just glance at the console window and see the problem, now my entire workflow is thrown off having to look at this thing and click on it. Which isn't too bad, except that looking at it is of totally no value at all since it doesn't correctly identify the source of the error or anything close to it.

I can only imagine how annoying this would be for a user who doesn't use the console.

[Graf Zahl]

This doesn't happen on Windows. Was something changed in the Linux backend?

[Korell]

You can dump as many sound fonts as you like into that subfolder and they will be listed in the selection menu for the synths. It will also fall back to something that can play if the settings are not correct, so normally with only gzdoom.sf2 present it will pick that up. There have been quite a bit of changes under the hood to make the music interface easier to use than it was before.

Ah, I see. I just found that Doom 64 Retribution wasn't playing the correct soundfont (the ini file I have for it was pointing to the folder where I have the mod files for the DOOMSND.SF2 soundfont). So I had to copy the file into the soundfont folder and then select it from the Fluidsynth MIDI settings, and now it plays fine again.

EDIT: On returning to Doom 1 (with the soundfont not set as per the default settings) it now tries to use the Doom 64 Retribution DOOMSND.SF2 instead of GZDOOM.SF2. If I rename DOOMSND.SF2 to zDOOMSND.SF2 then it does use the correct GZDOOM.SF2 soundfont, so it looks like it is using the first soundfont alphabetically. Wouldn't it therefore be better to have the default fluid_patchset set to GZDOOM.SF2 so that this doesn't happen if you add extra soundfonts into the folder?

[Indecom]

Is there documentation on the implementation of shaders somewhere? Are normal maps and the like built in or will I have to write my own routines?

[Gez]

For materials? There's some (barebones) documentation on [wiki]GLDEFS[/wiki]. You'll need to provide the various maps yourself, they're not automatically generated. Only use them if you have a real reason to use them, rather than just because it's technically possible.

Also it's not advised to mix and match texture rendering styles. Normal+specular can work okay when mixed with classical Doom textures, but PBR works differently enough that it will not coexist gracefully with non-PBR textures. The way lighting works would be inconsistent.

[Indecom]

Oh definitely. I've been working with advanced materials for several years in unity and unreal. I've got some pretty awesome ideas for GZD. Curious, are screen based shaders supported now as well, for things like post processing effects?

[MakelYT]

I was wondering if GZDoom will ever get Multi-threading?

[wildweasel]

I was wondering if GZDoom will ever get Multi-threading?

It technically already has it - the sound system runs on a separate thread from the renderer.

To be a bit more serious, though, the renderer for the Doom engine is really not terribly conducive to multi-threading, given how much of the game logic is tied to the rendering, and vice versa; this is not an easy thing to decouple, especially not if you want to ensure that multiplayer, demo-recording, and saved games all continue to work as expected.

[phantombeta]

Actually, the software renderer is multithreaded. The OpenGL renderer isn't, though.

[_mental_]

I can only imagine how annoying this would be for a user who doesn't use the console.

This window was added for such users. Its usefulness in case of fatal script error is a different story.

[Graf Zahl]

Multithreading for OpenGL is on the list, but it's definitely not compatible with OpenGL 2.0, so we'll have to see how this will work out. A lot here depends on the survey's results.
There's two possible outcomes:
- We have to separate out the legacy renderer and stop feature development for it.
- The survey shows us that it is no longer needed and it can be removed.