On Mon, Jan 14 2019, Solene Rapenne <sol...@perso.pw> wrote:
> Solene Rapenne <sol...@perso.pw> wrote:
>> Solene Rapenne <sol...@perso.pw> 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
