GZDoom 3.3.0 released

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)] [Official News] [Downloads] [Discord]
[🔎 Google This Site]

Moderator: GZDoom Developers

Post Reply
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: GZDoom 3.3.0 released

Post by Csonicgo »

Chris wrote:
Graf Zahl wrote:Debug or optimized? I haven't even had problems with a debug build and libADL.
Mostly optimized (RelWithDebInfo). Given about a minute under perf, I see:

Code: Select all

  Children      Self  Command      Shared Object               Symbol
+   30.18%    29.98%  gzdoom       gzdoom                      [.] OPL3_Generate
...
+   12.73%    12.59%  gzdoom       gzdoom                      [.] OPL3_EnvelopeCalc
...
+    3.64%     3.62%  gzdoom       gzdoom                      [.] OPL3_EnvelopeGenOff
+    3.32%     3.30%  gzdoom       gzdoom                      [.] OPL3_EnvelopeGenRelease
30% of the entire execution time is devoted to OPL3_Generate, almost 13% to OPL3_EnvelopeCalc, etc. This is using a very recent version of this GENMIDI bank: https://github.com/sneakernets/DMXOPL/b ... GS%29.wopl (renamed to GENMIDI.wopl, loaded with the -file command line option, and setting libadl to use it via its option). I don't know how much of an effect the sound bank can have on performance, but it's still a very severe hit.
Is ADLMIDI using the nuked emulator? There is an option in the original ADLMIDI code to use Dosbox emulation instead, which is much faster. I'll admit Nukey's core, while accurate, is very CPU-intensive, and may not be the best option.

I'll talk with Wohlstand about getting my latest version included in the bank select so you don't have to do that all the time.
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: GZDoom 3.3.0 released

Post by Chris »

Csonicgo wrote:Is ADLMIDI using the nuked emulator? There is an option in the original ADLMIDI code to use Dosbox emulation instead, which is much faster. I'll admit Nukey's core, while accurate, is very CPU-intensive, and may not be the best option.
I don't see a core option under the ADLMIDI options menu. There is one under the OPL Synthesis menu which was already set to DOSBox OPL3, but I don't know if the same cvar affects ADLMIDI.
I'll talk with Wohlstand about getting my latest version included in the bank select so you don't have to do that all the time.
The DMXOPL bank stays selected, I just need to ensure the the wopl file is loaded as the GENMIDI lump for it to be available.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.3.0 released

Post by Graf Zahl »

Yes, it does use the Nuked core. That is hard coded into the player.
User avatar
NightFright
Spotlight Team
Posts: 1343
Joined: Fri May 02, 2008 12:29 pm
Location: Germany

Re: GZDoom 3.3.0 released

Post by NightFright »

What I would like to know: We have at least three different synths in GZD which seem to do pretty much the same thing: Timidity++, GUS and Wildmidi. I guess GUS is meant specifically for using the original GUS patches, but I dunno if there is any substantial difference if you run those through one of the two other synths.

Don't get me wrong - it's great that GZD offers so many options to make it right for anybody, but I'd be interested to know the differences between these three synths. Timidity can run patches and soundfonts and therefore seems to be a bit superior to me.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.3.0 released

Post by Graf Zahl »

If they didn't sound different they would have been removed already. Just try a few songs and listen for yourself.
User avatar
NightFright
Spotlight Team
Posts: 1343
Joined: Fri May 02, 2008 12:29 pm
Location: Germany

Re: GZDoom 3.3.0 released

Post by NightFright »

Well, I guess it's a matter of finding patches/soundfonts that are optimized for the specific synths. For all I can tell, EAWPats should go with Timidity++ (or Wildmidi), GUS patches with GUS and Wildmidi... well, tbh I don't know anything specifically created for that. Guess it's just an alternative.

I used EAWPats for a really long time before I switched to the Yamaha S-YXG50 (which is basically an SC-55 emulator for free, just even better). The integration of Timidity into GZD may tempt me to switch back to EAWPats for a while, even though the Yamaha VSTi plugin still sounds much more powerful. I can't help but religiously adore it.

If there was any way to natively support that plugin (even if it's required to have it in the GZD root dir or something), I'd be willing to pay for that even.
vanfanel
Posts: 97
Joined: Thu Mar 24, 2016 6:04 pm

Re: GZDoom 3.3.0 released

Post by vanfanel »

I am getting an error on exit with this version. 3.2.4 would not produce this error. This on GNU/Linux ARM (Raspbian) on a Raspberry Pi 3. This is build against latest stable SDL 2.0.8, using Raspbian's default gcc 6.3.0.
The error occurs as I confirm the exit with "y":

Code: Select all

*** Error in `/home/pi/doom/gzdoom': corrupted double-linked list: 0x02847468 ***
[New Thread 0x75489400 (LWP 6208)]
[Thread 0x75489400 (LWP 6208) exited]
[New Thread 0x75489400 (LWP 6209)]
[New Thread 0x75489400 (LWP 6210)]
[Thread 0x75489400 (LWP 6209) exited]

Thread 1 "gzdoom" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x76afb824 in __GI_abort () at abort.c:89
#2  0x76b34f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x76b3bad4 in malloc_printerr (action=<optimized out>, str=0x76bedfb4 "corrupted double-linked list", 
    ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049
#4  0x76b3cd28 in _int_free (av=0x76c0a794 <main_arena>, p=0x2847100, have_lock=0) at malloc.c:4052
#5  0x00b8060c in M_Free (block=0x2847398) at /home/pi/src/gzdoom-g3.3.0/src/m_alloc.cpp:208
#6  0x00b2c200 in TArray<VMFunction*, VMFunction*>::~TArray (this=0x21fc7d4, __in_chrg=<optimized out>)
    at /home/pi/src/gzdoom-g3.3.0/src/tarray.h:215
#7  0x00b29838 in PClass::~PClass (this=0x21fc7a8, __in_chrg=<optimized out>)
    at /home/pi/src/gzdoom-g3.3.0/src/dobjtype.cpp:320
#8  0x00b294b8 in PClass::StaticShutdown () at /home/pi/src/gzdoom-g3.3.0/src/dobjtype.cpp:284
#9  0x006d9a80 in call_terms () at /home/pi/src/gzdoom-g3.3.0/src/posix/sdl/i_main.cpp:131
#10 0x76afcdd4 in __run_exit_handlers (status=0, listp=0x76c0a4ac <__exit_funcs>, 
    run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:83
#11 0x76afce34 in __GI_exit (status=<optimized out>) at exit.c:105
#12 0x006e0034 in ST_Endoom () at /home/pi/src/gzdoom-g3.3.0/src/posix/sdl/st_start.cpp:353
#13 0x00ebe9c8 in <lambda()>::operator()(void) const (__closure=0x0)
    at /home/pi/src/gzdoom-g3.3.0/src/menu/messagebox.cpp:119
#14 0x00ebe9f8 in <lambda()>::_FUN(void) () at /home/pi/src/gzdoom-g3.3.0/src/menu/messagebox.cpp:120
#15 0x00ebe65c in AF_DMessageBoxMenu_CallHandler (param=0x21753a0, defaultparam=..., numparam=1, 
    ret=0x7effda40, numret=0) at /home/pi/src/gzdoom-g3.3.0/src/menu/messagebox.cpp:57
#16 0x01000c9c in VMExec_Checked::Exec (stack=0x76ff44c8, pc=0x1cca708, ret=0x7effded0, numret=0)
    at /home/pi/src/gzdoom-g3.3.0/src/scripting/vm/vmexec.h:702
#17 0x01000d44 in VMExec_Checked::Exec (stack=0x76ff44c8, pc=0x1ccaa00, ret=0x7effe3cc, numret=1)
    at /home/pi/src/gzdoom-g3.3.0/src/scripting/vm/vmexec.h:721
#18 0x0101b2b0 in VMCall (func=0x26be4bc, params=0x7effe398, numparams=3, results=0x7effe3cc, numresults=1)
    at /home/pi/src/gzdoom-g3.3.0/src/scripting/vm/vmframe.cpp:463
---Type <return> to continue, or q <return> to quit---
#19 0x00eae458 in DMenu::CallMenuEvent (this=0x275e6f0, mkey=6, fromcontroller=false)
    at /home/pi/src/gzdoom-g3.3.0/src/menu/menu.cpp:219
#20 0x00eb0864 in M_Responder (ev=0x13ddb10 <events+96>) at /home/pi/src/gzdoom-g3.3.0/src/menu/menu.cpp:690
#21 0x00aff4c4 in D_ProcessEvents () at /home/pi/src/gzdoom-g3.3.0/src/d_main.cpp:304
#22 0x00b0f450 in NetUpdate () at /home/pi/src/gzdoom-g3.3.0/src/d_net.cpp:986
#23 0x00b12708 in TryRunTics () at /home/pi/src/gzdoom-g3.3.0/src/d_net.cpp:1841
#24 0x00b01a7c in D_DoomLoop () at /home/pi/src/gzdoom-g3.3.0/src/d_main.cpp:1066
#25 0x00b073e0 in D_DoomMain () at /home/pi/src/gzdoom-g3.3.0/src/d_main.cpp:2757
#26 0x006da318 in main (argc=5, argv=0x7efff754) at /home/pi/src/gzdoom-g3.3.0/src/posix/sdl/i_main.cpp:263

I did a manual debug build (-O0 -ggdb) because passing -DCMAKE_BUILD_TYPE=Debug does not work, either.
User avatar
Wohlstand
Posts: 73
Joined: Sun Dec 17, 2017 3:22 am
Graphics Processor: nVidia with Vulkan support
Location: Moscow, Russia
Contact:

Re: GZDoom 3.3.0 released

Post by Wohlstand »

Chris wrote:I don't see a core option under the ADLMIDI options menu. There is one under the OPL Synthesis menu which was already set to DOSBox OPL3, but I don't know if the same cvar affects ADLMIDI.
`OPL Synth Emulation` and `ADLMIDI` are different synthesizers and there are different independent libraries. ADLMIDI does usage of Nuked OPL3 only and has no ability to choose emulation core yet. I have the plan to add switching between of DosBox and Nuked OPL3. For now, that is togglable on build side only. By default Nuked is in use, and the DosBox is in use when declaring a special macro. I using DosBox emulator on mobile devices as it is quick and optimized. Nuked is well for PC usage where CPU is usually powerful.
Chris wrote: The DMXOPL bank stays selected, I just need to ensure the the wopl file is loaded as the GENMIDI lump for it to be available.
For this I have an idea to implement direct OP2 -> WOPL converter (or even natively parse OP2 format together with WOPL) to allow using of existing banks from old iWADs. Don't forget that here is another OPNMIDI synthesizer which uses WOPN format which is different as OPNMIDI uses emulator of another chip, and is no way except of auto-porting of instruments from OPL3 to OPN2 (which possibly result a crap-sound) to handle OP2 banks into OPNMIDI.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: GZDoom 3.3.0 released

Post by Gez »

It would be cool if the ADLMIDI implementation in GZDoom could share the cores from the OPL synth emulator, so that they wouldn't need to be duplicated, and we could also use the MAME OPL2 or Vintage Tone OPL3 cores.
SuaveSteve
Posts: 76
Joined: Sat Jul 05, 2014 7:38 am

Re: GZDoom 3.3.0 released

Post by SuaveSteve »

WorldLinePreActivated

May we please get some docs on this?

https://github.com/coelckers/gzdoom/blo ... s.cpp#L418

Does shouldactivate mean the line could have activated but the actor was not suitable for it?
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 3.3.0 released

Post by _mental_ »

If you set WorldEvent.ShouldActivate to false inside the handler, activation of special will be canceled.

Code: Select all

version "3.3"

class WorldLinePreActivatedTestHandler : StaticEventHandler
{
    override void WorldLinePreActivated(WorldEvent e)
    {
        Console.Printf("Ha-Ha!");
        e.ShouldActivate = false;
    }
}
User avatar
Wohlstand
Posts: 73
Joined: Sun Dec 17, 2017 3:22 am
Graphics Processor: nVidia with Vulkan support
Location: Moscow, Russia
Contact:

Re: GZDoom 3.3.0 released

Post by Wohlstand »

Gez wrote:It would be cool if the ADLMIDI implementation in GZDoom could share the cores from the OPL synth emulator so that they wouldn't need to be duplicated, and we could also use the MAME OPL2 or Vintage Tone OPL3 cores.
Then I would support all those cores on side of ADLMIDI with an ability to toggle them at runtime. For now, I have support for two cores only are switchable at compile time only.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: GZDoom 3.3.0 released

Post by Gez »

If the cores are "black boxes" with a shared API, it's just a question of switching an object pointer for another.

I'm thinking of how the OPL synth in ZDoom has a base class for OPL cores. Then the synth code is written to have object pointers to these base class. The synth itself basically just says chip->WriteReg() and let the core object, whatever it is, handle it.

This makes it very simple to add or remove more core types, and even to swap them dynamically at run-time. So if you adopt the same approach for ADLMIDI, then the cores could be commonalized in GZDoom. ADLMIDI itself wouldn't need to explicitly support these cores, just use the same object interface.
User avatar
Wohlstand
Posts: 73
Joined: Sun Dec 17, 2017 3:22 am
Graphics Processor: nVidia with Vulkan support
Location: Moscow, Russia
Contact:

Re: GZDoom 3.3.0 released

Post by Wohlstand »

Gez, Yeah, I gonna to make the base class for all emulators to set up the sample rate, pass registers data, and fill an audio buffer with the generated sound, and make each emulator be the child of that. I already use this strategy for different graphical engines in my game engine project: OpenGL 3, OpenGL 2 and Software render through SDL2's API.
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: GZDoom 3.3.0 released

Post by Csonicgo »

Gez wrote:It would be cool if the ADLMIDI implementation in GZDoom could share the cores from the OPL synth emulator, so that they wouldn't need to be duplicated, and we could also use the MAME OPL2 or Vintage Tone OPL3 cores.
If MAME OPL2 is to be made available to ADLMIDI, it needs to be stated that not all banks will work. DMXOPL is a prime example of a bank that wouldn't work with the OPL2 core at all due to its use of features that the OPL2 simply doesn't have. If that means that some banks need to be greyed out in the Bank selection screen, then so be it - I'd rather have that than someone trying to get a patch for the OPL3 to play on the OPL2 core, then writing the whole thing off due to how awful the resulting sound would be.

I've heard the results before in testing on real hardware, and it sounds as if someone sat on a car horn.
Post Reply

Return to “ZDoom (and related) News”