[new] gzdoom-3.6.0

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[new] gzdoom-3.6.0

Timo Myyrä-6
Hi,

Here's updated version for the gzdoom to latest version.
The fluidsynth isn't forced dependency, if user wants to use it, it must be
installed and configured with soundfont separately.

Timo


gzdoom.tar.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Frederic Cambus
On Thu, Nov 08, 2018 at 10:22:13AM +0200, Timo Myyrä wrote:

> Here's updated version for the gzdoom to latest version.
> The fluidsynth isn't forced dependency, if user wants to use it, it must be
> installed and configured with soundfont separately.

Thanks for your efforts on gzdoom. I would like to get this moving
forward and see the port finally imported.

A couple of comments:

- The BUILD_DEPENDS should be removed, they are pulled by devel/sdl2
- pkg/PLIST.orig should be removed
- portcheck complains that pkg/README does not have $OpenBSD$ RCS tag at
  the top
- We should probably mention in the README that an IWAD file is needed,
  you can have a look at games/prboom for an example

Also, it seems that the two patches are unnecessary? And that we can
also remove the following line from the port Makefile?

CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"

Lastly, I wonder if it wouldn't be better to link against fluidsynth,
add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
This would result in a fully functional port playing music out of the
box, without requiring any manual fiddling. Any thoughts on this?

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Timo Myyrä-6
On Sat, Dec 8, 2018, at 13:30, Frederic Cambus wrote:

> On Thu, Nov 08, 2018 at 10:22:13AM +0200, Timo Myyrä wrote:
>
> > Here's updated version for the gzdoom to latest version.
> > The fluidsynth isn't forced dependency, if user wants to use it, it must be
> > installed and configured with soundfont separately.
>
> Thanks for your efforts on gzdoom. I would like to get this moving
> forward and see the port finally imported.
>
> A couple of comments:
>
> - The BUILD_DEPENDS should be removed, they are pulled by devel/sdl2
> - pkg/PLIST.orig should be removed
> - portcheck complains that pkg/README does not have $OpenBSD$ RCS tag at
>   the top
> - We should probably mention in the README that an IWAD file is needed,
>   you can have a look at games/prboom for an example
>

Good point, I'll look into it when I have few moments.

> Also, it seems that the two patches are unnecessary? And that we can
> also remove the following line from the port Makefile?
>
> CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
>
> Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> This would result in a fully functional port playing music out of the
> box, without requiring any manual fiddling. Any thoughts on this?
>

Yeah, the patches are only there to keep fluidsynth as optional dependency.
The music works without fluidsynth, fluidsynth sounds a bit better. If we add fluidsynth as mandatory dependency, how about timidity? Thats why I added only those that are strictly needed to run the game as dependency. The game could probably be patched so that it only shows the available sound / music backends in the menus.

Timo

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Frederic Cambus
On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:

>
> > Also, it seems that the two patches are unnecessary? And that we can
> > also remove the following line from the port Makefile?
> >
> > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> >
> > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> > This would result in a fully functional port playing music out of the
> > box, without requiring any manual fiddling. Any thoughts on this?
> >
>
> Yeah, the patches are only there to keep fluidsynth as optional dependency.

When testing, it worked without patches both when linking against
fluidsynth and when keeping it as an optional dependency.

> The music works without fluidsynth, fluidsynth sounds a bit better. If we add fluidsynth as mandatory dependency, how about timidity? Thats why I added only those that are strictly needed to run the game as dependency. The game could probably be patched so that it only shows the available sound / music backends in the menus.

I see, I was indeed able to get music playing without fluidsynth by
selecting the OPL synth emulation, it wasn't enabled by default.

I don't think patching the game to only show available backends would
be worth it, but if it's not too much work, having OPL synth emulation
be the default would be nice.

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
Frederic Cambus <[hidden email]> wrote:

> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
> >
> > > Also, it seems that the two patches are unnecessary? And that we can
> > > also remove the following line from the port Makefile?
> > >
> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > >
> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> > > This would result in a fully functional port playing music out of the
> > > box, without requiring any manual fiddling. Any thoughts on this?
> > >
> >
> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
>
> When testing, it worked without patches both when linking against
> fluidsynth and when keeping it as an optional dependency.
>
> > The music works without fluidsynth, fluidsynth sounds a bit better. If we add fluidsynth as mandatory dependency, how about timidity? Thats why I added only those that are strictly needed to run the game as dependency. The game could probably be patched so that it only shows the available sound / music backends in the menus.
>
> I see, I was indeed able to get music playing without fluidsynth by
> selecting the OPL synth emulation, it wasn't enabled by default.
>
> I don't think patching the game to only show available backends would
> be worth it, but if it's not too much work, having OPL synth emulation
> be the default would be nice.
updated tarball.

- added stuff to pkg/README from prboom README
- removed BUILD_DEPENDS
- removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"


gzdoom.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Jeremie Courreges-Anglas-2
On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:

> Frederic Cambus <[hidden email]> wrote:
>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
>> >
>> > > Also, it seems that the two patches are unnecessary? And that we can
>> > > also remove the following line from the port Makefile?
>> > >
>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
>> > >
>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
>> > > This would result in a fully functional port playing music out of the
>> > > box, without requiring any manual fiddling. Any thoughts on this?
>> > >
>> >
>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
>>
>> When testing, it worked without patches both when linking against
>> fluidsynth and when keeping it as an optional dependency.

By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
This works because that's the major version currently shipped by our
fluidsynth port:

  SHARED_LIBS +=  fluidsynth           1.0      # 6.2

Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
with no version; this allows supporting fluidsynth as an optional sound
backend, without having to sync gzdoom with the major bumps of
libfluidsynth.  I think this is the right way to handle it.

>> > The music works without fluidsynth, fluidsynth sounds a bit better.
>> > If we add fluidsynth as mandatory dependency, how about timidity?
>> > Thats why I added only those that are strictly needed to run the
>> > game as dependency. The game could probably be patched so that it
>> > only shows the available sound / music backends in the menus.
>>
>> I see, I was indeed able to get music playing without fluidsynth by
>> selecting the OPL synth emulation, it wasn't enabled by default.
>>
>> I don't think patching the game to only show available backends would
>> be worth it, but if it's not too much work, having OPL synth emulation
>> be the default would be nice.
>
> updated tarball.
>
> - added stuff to pkg/README from prboom README
> - removed BUILD_DEPENDS
> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"

If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
patch-src_CMakeLists_txt is used:

 ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"

so fluidsynth support *won't* work.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Timo Myyrä-6
Jeremie Courreges-Anglas <[hidden email]> writes:

> On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
>
>> Frederic Cambus <[hidden email]> wrote:
>>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
>>> >
>>> > > Also, it seems that the two patches are unnecessary? And that we can
>>> > > also remove the following line from the port Makefile?
>>> > >
>>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
>>> > >
>>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
>>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
>>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
>>> > > This would result in a fully functional port playing music out of the
>>> > > box, without requiring any manual fiddling. Any thoughts on this?
>>> > >
>>> >
>>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
>>>
>>> When testing, it worked without patches both when linking against
>>> fluidsynth and when keeping it as an optional dependency.
>
> By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> This works because that's the major version currently shipped by our
> fluidsynth port:
>
>   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
>
> Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> with no version; this allows supporting fluidsynth as an optional sound
> backend, without having to sync gzdoom with the major bumps of
> libfluidsynth.  I think this is the right way to handle it.
>
>>> > The music works without fluidsynth, fluidsynth sounds a bit better.
>>> > If we add fluidsynth as mandatory dependency, how about timidity?
>>> > Thats why I added only those that are strictly needed to run the
>>> > game as dependency. The game could probably be patched so that it
>>> > only shows the available sound / music backends in the menus.
>>>
>>> I see, I was indeed able to get music playing without fluidsynth by
>>> selecting the OPL synth emulation, it wasn't enabled by default.
>>>
>>> I don't think patching the game to only show available backends would
>>> be worth it, but if it's not too much work, having OPL synth emulation
>>> be the default would be nice.
>>
>> updated tarball.
>>
>> - added stuff to pkg/README from prboom README
>> - removed BUILD_DEPENDS
>> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
>
> If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> patch-src_CMakeLists_txt is used:
>
>  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
>
> so fluidsynth support *won't* work.
Hi,

Here's updated port tarball with bump to version 3.7.0.
The new version adds JIT functionality in game which requires the use of
libexecinfo for backtrace / backtrace_symbols functions.

Note that I can't playtest this currently, my e485 doesn't have audio nor
graphics drivers for this port so testing would be welcome.

timo


* Would dialogs be needed?
  Now gzdoom must be started from cli as it polls which WAD to use on
  it. Graphical menu items / dmenu etc. won't have a way to ask the WAD file to
  use.

  GTK flavor so menu can be seen

* Dependency listing

  sdl2 is LIB_DEPENDS and it pulls in libsamplerate and libsndfile so are those
  worth listing in BUILD_DEPENDS?

* Dynamic loading of fluidsynth

  this requires some extra setup and is optional dependency so I think this

  the CMakeLists.txt patching should be improved a bit
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Timo Myyrä-6
In reply to this post by Jeremie Courreges-Anglas-2
Jeremie Courreges-Anglas <[hidden email]> writes:

> On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
>
>> Frederic Cambus <[hidden email]> wrote:
>>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
>>> >
>>> > > Also, it seems that the two patches are unnecessary? And that we can
>>> > > also remove the following line from the port Makefile?
>>> > >
>>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
>>> > >
>>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
>>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
>>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
>>> > > This would result in a fully functional port playing music out of the
>>> > > box, without requiring any manual fiddling. Any thoughts on this?
>>> > >
>>> >
>>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
>>>
>>> When testing, it worked without patches both when linking against
>>> fluidsynth and when keeping it as an optional dependency.
>
> By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> This works because that's the major version currently shipped by our
> fluidsynth port:
>
>   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
>
> Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> with no version; this allows supporting fluidsynth as an optional sound
> backend, without having to sync gzdoom with the major bumps of
> libfluidsynth.  I think this is the right way to handle it.
>
>>> > The music works without fluidsynth, fluidsynth sounds a bit better.
>>> > If we add fluidsynth as mandatory dependency, how about timidity?
>>> > Thats why I added only those that are strictly needed to run the
>>> > game as dependency. The game could probably be patched so that it
>>> > only shows the available sound / music backends in the menus.
>>>
>>> I see, I was indeed able to get music playing without fluidsynth by
>>> selecting the OPL synth emulation, it wasn't enabled by default.
>>>
>>> I don't think patching the game to only show available backends would
>>> be worth it, but if it's not too much work, having OPL synth emulation
>>> be the default would be nice.
>>
>> updated tarball.
>>
>> - added stuff to pkg/README from prboom README
>> - removed BUILD_DEPENDS
>> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
>
> If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> patch-src_CMakeLists_txt is used:
>
>  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
>
> so fluidsynth support *won't* work.
Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
build depends.

timo


gzdoom.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
[hidden email] (Timo Myyrä) wrote:

> Jeremie Courreges-Anglas <[hidden email]> writes:
>
> > On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
> >
> >> Frederic Cambus <[hidden email]> wrote:
> >>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
> >>> >
> >>> > > Also, it seems that the two patches are unnecessary? And that we can
> >>> > > also remove the following line from the port Makefile?
> >>> > >
> >>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> >>> > >
> >>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> >>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> >>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> >>> > > This would result in a fully functional port playing music out of the
> >>> > > box, without requiring any manual fiddling. Any thoughts on this?
> >>> > >
> >>> >
> >>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
> >>>
> >>> When testing, it worked without patches both when linking against
> >>> fluidsynth and when keeping it as an optional dependency.
> >
> > By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> > This works because that's the major version currently shipped by our
> > fluidsynth port:
> >
> >   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
> >
> > Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> > with no version; this allows supporting fluidsynth as an optional sound
> > backend, without having to sync gzdoom with the major bumps of
> > libfluidsynth.  I think this is the right way to handle it.
> >
> >>> > The music works without fluidsynth, fluidsynth sounds a bit better.
> >>> > If we add fluidsynth as mandatory dependency, how about timidity?
> >>> > Thats why I added only those that are strictly needed to run the
> >>> > game as dependency. The game could probably be patched so that it
> >>> > only shows the available sound / music backends in the menus.
> >>>
> >>> I see, I was indeed able to get music playing without fluidsynth by
> >>> selecting the OPL synth emulation, it wasn't enabled by default.
> >>>
> >>> I don't think patching the game to only show available backends would
> >>> be worth it, but if it's not too much work, having OPL synth emulation
> >>> be the default would be nice.
> >>
> >> updated tarball.
> >>
> >> - added stuff to pkg/README from prboom README
> >> - removed BUILD_DEPENDS
> >> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
> >
> > If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> > patch-src_CMakeLists_txt is used:
> >
> >  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
> >
> > so fluidsynth support *won't* work.
>
> Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
> build depends.
>
> timo

I can't start gzdoom with the last version

GZDoom <unknown version> -  - SDL version
Compiled on Jan  1 2019

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /usr/local/share/games/doom/gzdoom.pk3, 635 lumps
 adding /usr/local/share/games/doom/zd_extra.pk3, 132 lumps
 adding /usr/local/share/doom/DOOM2.WAD, 2919 lumps
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
  Family 6, Model 142, Stepping 10
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 HyperThreading
I_InitSound: Initializing OpenAL
  Opened device SndIO Default
  EFX enabled
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 229.90 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Could not initialize SDL video:
No available video device

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
Solene Rapenne <[hidden email]> wrote:

> [hidden email] (Timo Myyrä) wrote:
> > Jeremie Courreges-Anglas <[hidden email]> writes:
> >
> > > On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
> > >
> > >> Frederic Cambus <[hidden email]> wrote:
> > >>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
> > >>> >
> > >>> > > Also, it seems that the two patches are unnecessary? And that we can
> > >>> > > also remove the following line from the port Makefile?
> > >>> > >
> > >>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > >>> > >
> > >>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> > >>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> > >>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> > >>> > > This would result in a fully functional port playing music out of the
> > >>> > > box, without requiring any manual fiddling. Any thoughts on this?
> > >>> > >
> > >>> >
> > >>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
> > >>>
> > >>> When testing, it worked without patches both when linking against
> > >>> fluidsynth and when keeping it as an optional dependency.
> > >
> > > By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> > > This works because that's the major version currently shipped by our
> > > fluidsynth port:
> > >
> > >   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
> > >
> > > Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> > > with no version; this allows supporting fluidsynth as an optional sound
> > > backend, without having to sync gzdoom with the major bumps of
> > > libfluidsynth.  I think this is the right way to handle it.
> > >
> > >>> > The music works without fluidsynth, fluidsynth sounds a bit better.
> > >>> > If we add fluidsynth as mandatory dependency, how about timidity?
> > >>> > Thats why I added only those that are strictly needed to run the
> > >>> > game as dependency. The game could probably be patched so that it
> > >>> > only shows the available sound / music backends in the menus.
> > >>>
> > >>> I see, I was indeed able to get music playing without fluidsynth by
> > >>> selecting the OPL synth emulation, it wasn't enabled by default.
> > >>>
> > >>> I don't think patching the game to only show available backends would
> > >>> be worth it, but if it's not too much work, having OPL synth emulation
> > >>> be the default would be nice.
> > >>
> > >> updated tarball.
> > >>
> > >> - added stuff to pkg/README from prboom README
> > >> - removed BUILD_DEPENDS
> > >> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > >
> > > If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> > > patch-src_CMakeLists_txt is used:
> > >
> > >  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
> > >
> > > so fluidsynth support *won't* work.
> >
> > Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
> > build depends.
> >
> > timo
>
> I can't start gzdoom with the last version
>
> GZDoom <unknown version> -  - SDL version
> Compiled on Jan  1 2019
>
> M_LoadDefaults: Load system defaults.
> W_Init: Init WADfiles.
>  adding /usr/local/share/games/doom/gzdoom.pk3, 635 lumps
>  adding /usr/local/share/games/doom/zd_extra.pk3, 132 lumps
>  adding /usr/local/share/doom/DOOM2.WAD, 2919 lumps
> I_Init: Setting up machine state.
> CPU Vendor ID: GenuineIntel
>   Name: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
>   Family 6, Model 142, Stepping 10
>   Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 HyperThreading
> I_InitSound: Initializing OpenAL
>   Opened device SndIO Default
>   EFX enabled
> V_Init: allocate screen.
> S_Init: Setting up sound.
> ST_Init: Init startup screen.
> Checking cmd-line parameters...
> S_InitData: Load sound definitions.
> G_ParseMapInfo: Load map definitions.
> Texman.Init: Init texture manager.
> ParseTeamInfo: Load team definitions.
> LoadActors: Load actor definitions.
> script parsing took 229.90 ms
> R_Init: Init Doom refresh subsystem.
> DecalLibrary: Load decals.
> M_Init: Init menus.
> P_Init: Init Playloop state.
> ParseSBarInfo: Loading custom status bar definition.
> D_CheckNetGame: Checking network game status.
> player 1 of 1 (1 nodes)
> Could not initialize SDL video:
> No available video device

I did reboot the system, this fixed the issue and I can start the game
correctly and play it. The laptop was up since some times, played with ports,
did suspsend/resume multiple time. Something was wrong I think.

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
Solene Rapenne <[hidden email]> wrote:

> Solene Rapenne <[hidden email]> wrote:
> > [hidden email] (Timo Myyrä) wrote:
> > > Jeremie Courreges-Anglas <[hidden email]> writes:
> > >
> > > > On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
> > > >
> > > >> Frederic Cambus <[hidden email]> wrote:
> > > >>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
> > > >>> >
> > > >>> > > Also, it seems that the two patches are unnecessary? And that we can
> > > >>> > > also remove the following line from the port Makefile?
> > > >>> > >
> > > >>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > > >>> > >
> > > >>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> > > >>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> > > >>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> > > >>> > > This would result in a fully functional port playing music out of the
> > > >>> > > box, without requiring any manual fiddling. Any thoughts on this?
> > > >>> > >
> > > >>> >
> > > >>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
> > > >>>
> > > >>> When testing, it worked without patches both when linking against
> > > >>> fluidsynth and when keeping it as an optional dependency.
> > > >
> > > > By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> > > > This works because that's the major version currently shipped by our
> > > > fluidsynth port:
> > > >
> > > >   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
> > > >
> > > > Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> > > > with no version; this allows supporting fluidsynth as an optional sound
> > > > backend, without having to sync gzdoom with the major bumps of
> > > > libfluidsynth.  I think this is the right way to handle it.
> > > >
> > > >>> > The music works without fluidsynth, fluidsynth sounds a bit better.
> > > >>> > If we add fluidsynth as mandatory dependency, how about timidity?
> > > >>> > Thats why I added only those that are strictly needed to run the
> > > >>> > game as dependency. The game could probably be patched so that it
> > > >>> > only shows the available sound / music backends in the menus.
> > > >>>
> > > >>> I see, I was indeed able to get music playing without fluidsynth by
> > > >>> selecting the OPL synth emulation, it wasn't enabled by default.
> > > >>>
> > > >>> I don't think patching the game to only show available backends would
> > > >>> be worth it, but if it's not too much work, having OPL synth emulation
> > > >>> be the default would be nice.
> > > >>
> > > >> updated tarball.
> > > >>
> > > >> - added stuff to pkg/README from prboom README
> > > >> - removed BUILD_DEPENDS
> > > >> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > > >
> > > > If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> > > > patch-src_CMakeLists_txt is used:
> > > >
> > > >  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
> > > >
> > > > so fluidsynth support *won't* work.
> > >
> > > Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
> > > build depends.
> > >
> > > timo
> >

I finally found the origin of the issue when loading brutal doom (and some
others mods I hope). When loading assets and making animations, it looks for
duplicates.

I don't fully understand the logic here, I read that in case of duplicate,
it free the old one and replace it with the current object?

It's a dirty hack but commenting the free instruction permit to play mods
(having duplicates in their animations I think?) with no noticeable memory
usage change. I added a puts("duplicate") to see if this happens often, it
was like 7 duplicates for brutal doom. As it's only happening at load time,
I would say it's pretty safe to not free this.

What do you think?

Index: src/textures/animations.cpp
--- src/textures/animations.cpp.orig
+++ src/textures/animations.cpp
@@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
  if (mAnimations[i]->BasePic == anim->BasePic)
  {
  // Found one!
- free (mAnimations[i]);
+ //free (mAnimations[i]);
  mAnimations[i] = anim;
  return anim;
  }

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
Solene Rapenne <[hidden email]> wrote:

> Solene Rapenne <[hidden email]> wrote:
> > Solene Rapenne <[hidden email]> wrote:
> > > [hidden email] (Timo Myyrä) wrote:
> > > > Jeremie Courreges-Anglas <[hidden email]> writes:
> > > >
> > > > > On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
> > > > >
> > > > >> Frederic Cambus <[hidden email]> wrote:
> > > > >>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
> > > > >>> >
> > > > >>> > > Also, it seems that the two patches are unnecessary? And that we can
> > > > >>> > > also remove the following line from the port Makefile?
> > > > >>> > >
> > > > >>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > > > >>> > >
> > > > >>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
> > > > >>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
> > > > >>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
> > > > >>> > > This would result in a fully functional port playing music out of the
> > > > >>> > > box, without requiring any manual fiddling. Any thoughts on this?
> > > > >>> > >
> > > > >>> >
> > > > >>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
> > > > >>>
> > > > >>> When testing, it worked without patches both when linking against
> > > > >>> fluidsynth and when keeping it as an optional dependency.
> > > > >
> > > > > By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
> > > > > This works because that's the major version currently shipped by our
> > > > > fluidsynth port:
> > > > >
> > > > >   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
> > > > >
> > > > > Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
> > > > > with no version; this allows supporting fluidsynth as an optional sound
> > > > > backend, without having to sync gzdoom with the major bumps of
> > > > > libfluidsynth.  I think this is the right way to handle it.
> > > > >
> > > > >>> > The music works without fluidsynth, fluidsynth sounds a bit better.
> > > > >>> > If we add fluidsynth as mandatory dependency, how about timidity?
> > > > >>> > Thats why I added only those that are strictly needed to run the
> > > > >>> > game as dependency. The game could probably be patched so that it
> > > > >>> > only shows the available sound / music backends in the menus.
> > > > >>>
> > > > >>> I see, I was indeed able to get music playing without fluidsynth by
> > > > >>> selecting the OPL synth emulation, it wasn't enabled by default.
> > > > >>>
> > > > >>> I don't think patching the game to only show available backends would
> > > > >>> be worth it, but if it's not too much work, having OPL synth emulation
> > > > >>> be the default would be nice.
> > > > >>
> > > > >> updated tarball.
> > > > >>
> > > > >> - added stuff to pkg/README from prboom README
> > > > >> - removed BUILD_DEPENDS
> > > > >> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
> > > > >
> > > > > If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
> > > > > patch-src_CMakeLists_txt is used:
> > > > >
> > > > >  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
> > > > >
> > > > > so fluidsynth support *won't* work.
> > > >
> > > > Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
> > > > build depends.
> > > >
> > > > timo
> > >
>
> I finally found the origin of the issue when loading brutal doom (and some
> others mods I hope). When loading assets and making animations, it looks for
> duplicates.
>
> I don't fully understand the logic here, I read that in case of duplicate,
> it free the old one and replace it with the current object?
>
> It's a dirty hack but commenting the free instruction permit to play mods
> (having duplicates in their animations I think?) with no noticeable memory
> usage change. I added a puts("duplicate") to see if this happens often, it
> was like 7 duplicates for brutal doom. As it's only happening at load time,
> I would say it's pretty safe to not free this.
>
> What do you think?
>
> Index: src/textures/animations.cpp
> --- src/textures/animations.cpp.orig
> +++ src/textures/animations.cpp
> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
>   if (mAnimations[i]->BasePic == anim->BasePic)
>   {
>   // Found one!
> - free (mAnimations[i]);
> + //free (mAnimations[i]);
>   mAnimations[i] = anim;
>   return anim;
>   }
Last version in tarball, including my patch. I've been able to play and did not
encounter any issue. From my code reading, it will wastes a few MB of memory if
a mod make heavy use of animated textures and have duplicates.


gzdoom.tgz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Timo Myyrä-6
Solene Rapenne <[hidden email]> writes:

> Solene Rapenne <[hidden email]> wrote:
>
>> Solene Rapenne <[hidden email]> wrote:
>> > Solene Rapenne <[hidden email]> wrote:
>> > > [hidden email] (Timo Myyrä) wrote:
>> > > > Jeremie Courreges-Anglas <[hidden email]> writes:
>> > > >
>> > > > > On Wed, Dec 19 2018, Solene Rapenne <[hidden email]> wrote:
>> > > > >
>> > > > >> Frederic Cambus <[hidden email]> wrote:
>> > > > >>> On Sat, Dec 08, 2018 at 01:52:26PM +0200, Timo Myyrä wrote:
>> > > > >>> >
>> > > > >>> > > Also, it seems that the two patches are unnecessary? And that we can
>> > > > >>> > > also remove the following line from the port Makefile?
>> > > > >>> > >
>> > > > >>> > > CONFIGURE_ARGS +=       -DFLUIDSYNTHLIB1="libfluidsynth.so"
>> > > > >>> > >
>> > > > >>> > > Lastly, I wonder if it wouldn't be better to link against fluidsynth,
>> > > > >>> > > add audio/generaluser-gs-soundfont in RUN_DEPENDS, and finally patch
>> > > > >>> > > src/gameconfigfile.cpp so it automatically finds the SoundFont banks.
>> > > > >>> > > This would result in a fully functional port playing music out of the
>> > > > >>> > > box, without requiring any manual fiddling. Any thoughts on this?
>> > > > >>> > >
>> > > > >>> >
>> > > > >>> > Yeah, the patches are only there to keep fluidsynth as optional dependency.
>> > > > >>>
>> > > > >>> When testing, it worked without patches both when linking against
>> > > > >>> fluidsynth and when keeping it as an optional dependency.
>> > > > >
>> > > > > By default, ie without any patch, "libfluidsynth.so.1" is dlopened.
>> > > > > This works because that's the major version currently shipped by our
>> > > > > fluidsynth port:
>> > > > >
>> > > > >   SHARED_LIBS +=  fluidsynth           1.0      # 6.2
>> > > > >
>> > > > > Timo patched the port so that the dlopen'd name is "libfluidsynth.so"
>> > > > > with no version; this allows supporting fluidsynth as an optional sound
>> > > > > backend, without having to sync gzdoom with the major bumps of
>> > > > > libfluidsynth.  I think this is the right way to handle it.
>> > > > >
>> > > > >>> > The music works without fluidsynth, fluidsynth sounds a bit better.
>> > > > >>> > If we add fluidsynth as mandatory dependency, how about timidity?
>> > > > >>> > Thats why I added only those that are strictly needed to run the
>> > > > >>> > game as dependency. The game could probably be patched so that it
>> > > > >>> > only shows the available sound / music backends in the menus.
>> > > > >>>
>> > > > >>> I see, I was indeed able to get music playing without fluidsynth by
>> > > > >>> selecting the OPL synth emulation, it wasn't enabled by default.
>> > > > >>>
>> > > > >>> I don't think patching the game to only show available backends would
>> > > > >>> be worth it, but if it's not too much work, having OPL synth emulation
>> > > > >>> be the default would be nice.
>> > > > >>
>> > > > >> updated tarball.
>> > > > >>
>> > > > >> - added stuff to pkg/README from prboom README
>> > > > >> - removed BUILD_DEPENDS
>> > > > >> - removed CONFIGURE_ARGS += -DFLUIDSYNTHLIB1="libfluidsynth.so"
>> > > > >
>> > > > > If you remove -DFLUIDSYNTHLIB1="libfluidsynth.so" then the value from
>> > > > > patch-src_CMakeLists_txt is used:
>> > > > >
>> > > > >  ... -DDYN_FLUIDSYNTH -DFLUIDSYNTHLIB1=\"libfluidsynth.so.0\"
>> > > > >
>> > > > > so fluidsynth support *won't* work.
>> > > >
>> > > > Update to gzdoom-3.7.0, upstream added jit support which requires execinfo as
>> > > > build depends.
>> > > >
>> > > > timo
>> > >
>>
>> I finally found the origin of the issue when loading brutal doom (and some
>> others mods I hope). When loading assets and making animations, it looks for
>> duplicates.
>>
>> I don't fully understand the logic here, I read that in case of duplicate,
>> it free the old one and replace it with the current object?
>>
>> It's a dirty hack but commenting the free instruction permit to play mods
>> (having duplicates in their animations I think?) with no noticeable memory
>> usage change. I added a puts("duplicate") to see if this happens often, it
>> was like 7 duplicates for brutal doom. As it's only happening at load time,
>> I would say it's pretty safe to not free this.
>>
>> What do you think?
>>
>> Index: src/textures/animations.cpp
>> --- src/textures/animations.cpp.orig
>> +++ src/textures/animations.cpp
>> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
>>   if (mAnimations[i]->BasePic == anim->BasePic)
>>   {
>>   // Found one!
>> - free (mAnimations[i]);
>> + //free (mAnimations[i]);
>>   mAnimations[i] = anim;
>>   return anim;
>>   }
>
> Last version in tarball, including my patch. I've been able to play and did not
> encounter any issue. From my code reading, it will wastes a few MB of memory if
> a mod make heavy use of animated textures and have duplicates.

Ok by me.

Timo

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Jeremie Courreges-Anglas-2
In reply to this post by Solene Rapenne
On Mon, Jan 14 2019, Solene Rapenne <[hidden email]> wrote:
> Solene Rapenne <[hidden email]> wrote:
>> Solene Rapenne <[hidden email]> wrote:

[...]

>> I finally found the origin of the issue when loading brutal doom (and some
>> others mods I hope). When loading assets and making animations, it looks for
>> duplicates.
>>
>> I don't fully understand the logic here, I read that in case of duplicate,
>> it free the old one and replace it with the current object?
>>
>> It's a dirty hack but commenting the free instruction permit to play mods
>> (having duplicates in their animations I think?) with no noticeable memory
>> usage change. I added a puts("duplicate") to see if this happens often, it
>> was like 7 duplicates for brutal doom. As it's only happening at load time,
>> I would say it's pretty safe to not free this.
>>
>> What do you think?
>>
>> Index: src/textures/animations.cpp
>> --- src/textures/animations.cpp.orig
>> +++ src/textures/animations.cpp
>> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
>>   if (mAnimations[i]->BasePic == anim->BasePic)
>>   {
>>   // Found one!
>> - free (mAnimations[i]);
>> + //free (mAnimations[i]);
>>   mAnimations[i] = anim;
>>   return anim;
>>   }
>
> Last version in tarball, including my patch. I've been able to play and did not
> encounter any issue. From my code reading, it will wastes a few MB of memory if
> a mod make heavy use of animated textures and have duplicates.

No opinion regarding the workaround.

Looks fine ports-wise except for libexecinfo which should go to
LIB_DEPENDS instead of BUILD_DEPENDS, and "execinfo" should be added to
WANTLIB.

With this addressed, ok jca@ to import.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Timo Myyrä-6
Jeremie Courreges-Anglas <[hidden email]> writes:

> On Mon, Jan 14 2019, Solene Rapenne <[hidden email]> wrote:
>> Solene Rapenne <[hidden email]> wrote:
>>> Solene Rapenne <[hidden email]> wrote:
>
> [...]
>
>>> I finally found the origin of the issue when loading brutal doom (and some
>>> others mods I hope). When loading assets and making animations, it looks for
>>> duplicates.
>>>
>>> I don't fully understand the logic here, I read that in case of duplicate,
>>> it free the old one and replace it with the current object?
>>>
>>> It's a dirty hack but commenting the free instruction permit to play mods
>>> (having duplicates in their animations I think?) with no noticeable memory
>>> usage change. I added a puts("duplicate") to see if this happens often, it
>>> was like 7 duplicates for brutal doom. As it's only happening at load time,
>>> I would say it's pretty safe to not free this.
>>>
>>> What do you think?
>>>
>>> Index: src/textures/animations.cpp
>>> --- src/textures/animations.cpp.orig
>>> +++ src/textures/animations.cpp
>>> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
>>>   if (mAnimations[i]->BasePic == anim->BasePic)
>>>   {
>>>   // Found one!
>>> - free (mAnimations[i]);
>>> + //free (mAnimations[i]);
>>>   mAnimations[i] = anim;
>>>   return anim;
>>>   }
>>
>> Last version in tarball, including my patch. I've been able to play and did not
>> encounter any issue. From my code reading, it will wastes a few MB of memory if
>> a mod make heavy use of animated textures and have duplicates.
>
> No opinion regarding the workaround.
>
> Looks fine ports-wise except for libexecinfo which should go to
> LIB_DEPENDS instead of BUILD_DEPENDS, and "execinfo" should be added to
> WANTLIB.
>
> With this addressed, ok jca@ to import.
Ok, here's new 3.7.2 version with changes added.

timo


gzdoom.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] gzdoom-3.6.0

Solene Rapenne
[hidden email] (Timo Myyrä) wrote:

> Jeremie Courreges-Anglas <[hidden email]> writes:
>
> > On Mon, Jan 14 2019, Solene Rapenne <[hidden email]> wrote:
> >> Solene Rapenne <[hidden email]> wrote:
> >>> Solene Rapenne <[hidden email]> wrote:
> >
> > [...]
> >
> >>> I finally found the origin of the issue when loading brutal doom (and some
> >>> others mods I hope). When loading assets and making animations, it looks for
> >>> duplicates.
> >>>
> >>> I don't fully understand the logic here, I read that in case of duplicate,
> >>> it free the old one and replace it with the current object?
> >>>
> >>> It's a dirty hack but commenting the free instruction permit to play mods
> >>> (having duplicates in their animations I think?) with no noticeable memory
> >>> usage change. I added a puts("duplicate") to see if this happens often, it
> >>> was like 7 duplicates for brutal doom. As it's only happening at load time,
> >>> I would say it's pretty safe to not free this.
> >>>
> >>> What do you think?
> >>>
> >>> Index: src/textures/animations.cpp
> >>> --- src/textures/animations.cpp.orig
> >>> +++ src/textures/animations.cpp
> >>> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
> >>>   if (mAnimations[i]->BasePic == anim->BasePic)
> >>>   {
> >>>   // Found one!
> >>> - free (mAnimations[i]);
> >>> + //free (mAnimations[i]);
> >>>   mAnimations[i] = anim;
> >>>   return anim;
> >>>   }
> >>
> >> Last version in tarball, including my patch. I've been able to play and did not
> >> encounter any issue. From my code reading, it will wastes a few MB of memory if
> >> a mod make heavy use of animated textures and have duplicates.
> >
> > No opinion regarding the workaround.
> >
> > Looks fine ports-wise except for libexecinfo which should go to
> > LIB_DEPENDS instead of BUILD_DEPENDS, and "execinfo" should be added to
> > WANTLIB.
> >
> > With this addressed, ok jca@ to import.
>
> Ok, here's new 3.7.2 version with changes added.
>
> timo

I choosed to import 3.7.1 as it was tested and approved. I didn't want to delay
it longer...

I tried the 3.7.2 version and no issue so far. Ok solene@ for update.

I've seen a gzdoom-lite version is now released, it targets older computers and
will not receive any graphical enhancements anymore, is there someone
interested in it?