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?Rachael wrote: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.
GZDoom 3.3.0 released
Moderator: GZDoom Developers
Re: GZDoom 3.3.0 released
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.3.0 released
What are you talking about?Matt wrote:
(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)
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.3.0 released
Both are FM synths, not wave table, so they are more like OPL. Some people actually like that, strange as it sounds...Korell wrote: 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,
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.Korell wrote: 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
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.3.0 released
BTW, user engagement for the hardware survey is roughly 50% so far. A bit low, I have to say.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: GZDoom 3.3.0 released
This:Graf Zahl wrote:What are you talking about?Matt wrote:(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)
[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.
Last edited by Rachael on Sun Mar 25, 2018 2:41 pm, edited 1 time in total.
Reason: shrunk image
Reason: shrunk image
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.3.0 released
This doesn't happen on Windows. Was something changed in the Linux backend?
Re: GZDoom 3.3.0 released
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.Graf Zahl wrote: 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.
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?
Re: GZDoom 3.3.0 released
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?
Re: GZDoom 3.3.0 released
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.
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.
Re: GZDoom 3.3.0 released
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?
Re: GZDoom 3.3.0 released
I was wondering if GZDoom will ever get Multi-threading?
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Re: GZDoom 3.3.0 released
It technically already has it - the sound system runs on a separate thread from the renderer.MakelYT wrote:I was wondering if GZDoom will ever get Multi-threading?
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
- Posts: 2089
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: GZDoom 3.3.0 released
Actually, the software renderer is multithreaded. The OpenGL renderer isn't, though.
Re: GZDoom 3.3.0 released
This window was added for such users. Its usefulness in case of fatal script error is a different story.Matt wrote:I can only imagine how annoying this would be for a user who doesn't use the console.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.3.0 released
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.
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.