Solene Rapenne <sol...@perso.pw> writes:
> 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.
Ok by me.
Timo
