Solene Rapenne <sol...@perso.pw> wrote:
> Solene Rapenne <sol...@perso.pw> wrote:
> > Solene Rapenne <sol...@perso.pw> wrote:
> > > timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> > > > Jeremie Courreges-Anglas <j...@wxcvbn.org> writes:
> > > >
> > > > > On Wed, Dec 19 2018, Solene Rapenne <sol...@perso.pw> wrote:
> > > > >
> > > > >> Frederic Cambus <f...@statdns.com> 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
Description: application/gzip
