[Scummvm-devel] Kyrandia engine loading is slow on the DS

[Max Horn]

Am 25.08.2008 um 16:33 schrieb Neil Millstone:

> Max Horn wrote:
>> Folks,
>>
>> I am confused: You are talking about a "rev 33529 from athrxx" fixing
>> issues in Kyra -- but over here, that rev is a commit by buddha to
>> CINE on August 2:
>> <http://scummvm.svn.sourceforge.net/viewvc/scummvm?view=rev&revision=33529 
>> >.
>> Could somebody tell me which commit you are actually talking  
>> about? :)
>>
>>
>> Cheers,
>> Max
>>
>
> Sorry, I must have made a mistake, I meant rev 34083.
> http://scummvm.svn.sourceforge.net/viewvc/scummvm?view=rev&revision=34083

Ah, thanks for the clarification! :)
>
>
> Hopefully this can stay, because from my point of view, it makes a  
> huge
> difference.

Unless we come up with a "better" fix, sure, I see no reason why not?  
Johannes?


> I commited a fix to a crash in Kyra 2 which was due to updateScreen()
> not being called while waiting for input (could possibly crash other
> ports).

If I understand it correctly, Johannes commited a different fix in  
revs 34158 & 34159 ?



>  I also #ifdef'd out the code which retries fopen with various
> different uppercase/lowercase combinations, because it has no effect  
> on
> the DS port and gives a nice speedup.

Fair enough. On trunk, this code will eventually completely go, as  
part of the "File" code rewrite that was discussed here in various  
threads (see also the ongoing work on patch tracker item #2034983 <https://sourceforge.net/tracker/index.php?func=detail&aid=2034983&group_id=37116&atid=418822 
 >).


> Unfortunately, I have had bug reports of crashing in Lure of the
> Temptress on my latest beta, Inherit the Earth also has palette
> corruption during the intro, which then crashes, and if the intro is
> skipped it later runs out of memory and crashes there.  I think these
> bugs have been introduced in the last couple of weeks because I tested
> these games when 0.12.0 was branched, and they worked fine, and I  
> really
> doubt if it's anything to do with the DS backend.  So it's certainly
> possible these bugs occur in other ports.

Hm, I don't see any lure specific change in the 0.12.0 branch. But of  
course it's still possible that the regression was introduced after  
the branch. Can you test with a build from the branch point?

As for ITE / the sage engine: There were 4-5 that touched SAGA, but  
none touched the intro, in fact most should not even be triggered at  
all (one is for cleanup when exiting; one only does something if  
"save_slot" is set, which shouldn't be the case on the DS; one adds  
some extra mutex locking; some add some new strings/detection data).  
The only I am not completely sure about is rev 33491, but it does look  
innocent enough to me.
But again, it's certainly possible that some of the infrastructure  
changes caused a problem. Again, it would be best to first confirm  
that the issue does not happen during branch time, then do a few  
"binary search" builds to narrow down when the issue first happened.


> Well, I'm going out today so it looks like I'm not going to be able to
> release the DS port along with the others.  Feel free to tag the build
> tomorrow and I will have to release the DS port when I've finished a
> long printf-powered debugging session.  Ideally I'd like to have a few
> weeks to release betas and test the games once everything is  
> stable.  I
> really wish I didn't have to do all this.


Well, we all know how frustrating it is to have to track down late  
regressions. OTOH, our time table was clear cut from the beginning:

  July 21th: Start of playtesting
  August 18th: All ports should be frozen, prerelease binaries built
  August 25th: Tagging, Binaries uploaded to sf.net
  August 31th: Release

That's four weeks for testing, and one extra week, just in case -- do  
you mean we need more?


Cheers,
Max