[Scummvm-devel] ScummVM 0.12.0: Missing builds

[Neil Millstone]

Max Horn wrote:
>
> Am 04.09.2008 um 09:47 schrieb Neil Millstone:
>
>> Max Horn wrote:
>>>
>>> Am 02.09.2008 um 22:32 schrieb Neil Millstone:
>>
> [...]
>>
>>>> My current issue is that Inherit the Earth is now about 100Kb over 
>>>> the available memory.  This seems to be mostly code size gained 
>>>> since 0.11.0.  While we can't really prevent the binary from 
>>>> growing, I can't imagine that I'll be able to get this game working 
>>>> if the same happens next time.  If anyone knows how I can save 
>>>> 100Kb in this game, please let me know!
>>>
>>> To repeat what Filipppos wrote: This is the first time I hear about 
>>> this :(. Well, I assume you found out about this only recently, else 
>>> I'd now start with my "we need to communicate more and better" 
>>> jingle *g*. Anyway, now that we know, the SAGA folks can also look 
>>> into the issue; given that they know the engine best, they might be 
>>> able to help.
>>>
>>
>> Yes, I only discovered this in the past few days.  I found a fix 
>> which reduces the peak memory usage by changing how sound resources 
>> are loaded so that the data is not stored in memory twice, as it is 
>> now.  I'll send the patch for this to filippos so he can check it 
>> doesn't break anything.  The game seems to work fine with the patch.
>
> Good start. Did you already send the patch? Actually, it might be 
> better to submit it to the patch tracker, that way, more people can 
> review it, and it'll probably be quicker overall.
I'll do that as soon as I've found some time to tidy it up.  Anyway, 
since I posted a new beta which includes this patch, someone found that 
it was still possible to make ITE run out of RAM.  So I now need another 
chunk of RAM (it's impossible to say how much would be needed to make 
the game run in all circumstances) so if anyone has any ideas on how ITE 
could run in less RAM, please let me know.

The RAM could be saved in executable size or static data as well as 
runtime allocations.
> [...]
>> The thing is, I tend to assume that the engine authors may not be 
>> interested in fixing bugs which only show up for low-memory/low-CPU 
>> devices.  For an example, see the discussion on the thousands of 
>> fopen calls for Kyra. That was fixed in the end, but the team's 
>> initial response was to handle it in the backend, even though other 
>> ports were affected.
>
> What? Wow, that's quite different from how I recall things... :) So I 
> just went back through that thread ("Kyrandia engine loading is slow 
> on the DS"), and read it, and I really don't know how you come to that 
> conclusion -- maybe you can tell me what exactly there made you feel 
> as if you were left alone? Let me briefly sketch how that thread looks 
> to me:
>
>
> The *first* reaction was by LordHoto, the man behind our Kyra engine, 
> and included a patch which tried to improve the situation. If that 
> doesn't show willingness to cooperate and solve the problem, I don't 
> know what does *g*.
>
> A bit later, Betrand and me suggested that it might be possible to 
> solve the issue by caching stuff at some point. I pointed out that the 
> code peres and me are working on would provide that for free, *in the 
> frontend*, but that you might be able to hack this into your fopen 
> quickly in the meantime. Again, that doesn't sound like rejecting the 
> responsibility for fixing this,
>
> Other people chimed in, and we got a patch. BTW, initially, we knew of 
> *no* other port that was affected, to the contrary DJWillis told us he 
> was not aware of problems on the GP2x.
>
> And then rev 33529, by arthrxx, the other man behind Kyra, fixed it. 
> So, again the engine people were doing the fix. Nice. Oh, *after* 
> that, we were told that PS2 was having problems, too. Luckily, we 
> already fixed the issue, regardless of whether it was DS specific or 
> not... :)
Well, maybe I misread things there, but it did seem like the general 
view was that it should be fixed in the backend, something I didn't 
agree with.
>
>
>> The DS has 4Mb of RAM.  After the code and global data has been 
>> allocated, there's anything between 1.9 and 2.3Mb of memory available 
>> for the game to allocate.  That's not very much.
>
> Aye.
>
> Look, man, I understand it's frustrating to have to chase after 
> ever-growing engine binary sizes, and all. But I really thing it's 
> rather unfair to claim that this is because engine authors are 
> unwilling to help. Rather, it seems to me that there is a certain lack 
> of communication by porters, who don't tell us about problems. Maybe 
> fearing the report will be ignored, or no solution will be possible... 
> But actually, my experience is that those issues get fixed quickly, 
> *if* they are reported. Sadly, they often are not :(.
>
Well, I do remember having emailed people about issues and receiving no 
response in the past, although I can't find the specific mail now (it 
was quite a while ago).

The thing is, my time on ScummVM is almost entirely taken up with 
responding to changes in the rest of the code in order to get a build 
working, and then trying to get the RAM usage down, and it feels like 
I'm slowly losing this battle.  I think some of the common code is 
getting a little bloated and I think some effort could go into reducing 
this, because otherwise there will only be a few more versions that a DS 
port is practical.

- Neil