[Scummvm-devel] ScummVM 1.0.0: Release status 2009-08-11 -- Full feature, freeze

[Filippos Karapetis]

I'm not really familiar with the pathfinding code in SAGA, and I managed to steer clear of it during development. The pathfinding code does exactly what the original did, but I believe that Andrew Kurushin (ajax16384/h00ligan) might know a bit more about its inner workings.

Your fix looks to be harmless enough, but I would not be comfortable applying it to the 1.0 branch without testing. The places that I know which stress the pathfinding code a lot are in the hangar zone in ITE (towards the end), the rat maze, and perhaps the faire and overhead map (which are at the beginning). In IHNM, I believe that the places which should be tested are the vortex in the final chapter of the game, as well as Helen's chapter. There is a pathfinding test code which can be enabled with the ACTORPATH_TEST define (or something like that, I can't remember it off the top of my head). This can be used to display the findings of the pathfinding algorithm visually using F4 (?) if memory serves well.

I'm currently in vacations, so I can't really test this. Please, submit it as a patch to the tracker, and I'll try to playtest it in a week or so when I get back from vacations. If you can, please play the game as much as you can, as changes to the pathfinding algorithm can really make the game uncompleteable (which is the reason why I'm reluctant to put this in the stable version without testing).

Regards
Filippos


> Date: Sun, 16 Aug 2009 03:08:35 +0100
> From: neil at millstone.demon.co.uk
> To: lordhoto at scummvm.org
> CC: scummvm-devel at lists.sourceforge.net
> Subject: Re: [Scummvm-devel] ScummVM 1.0.0: Release status 2009-08-11 --	Full feature, freeze
> 
> Neil Millstone wrote:
> > Johannes Schickel wrote:
> >> Johannes Schickel wrote:
> >>>
> >>> I remember DrMcCoy moved some video player code from gob into 
> >>> graphics/. I just asked him and the tables for the video codec of 
> >>> (yet unsupported) the game Urban Runner take up 72kb. He also says 
> >>> it's enabled even when gob is disabled. So I guess this might be the 
> >>> cause for the ~80kb increase. A proper solution would be to only 
> >>> enable that code when GOB is enabled or when a build supporting 
> >>> plugins is made. I guess that might fix up the size increase.
> >>>
> >>
> >> Just to be sure you all noticed it. DrMcCoy made a patch for that:
> >> http://sourceforge.net/tracker/?func=detail&aid=2836424&group_id=37116&atid=418822 
> >>
> >>
> >> // Johannes
> >>
> >
> > I was looking at the Saga memory usage again today.  By poking around 
> > stack dumps when it crashed, I tracked down the ~200Kb alloc which 
> > makes the game crash to the path finder in Actor::fillPathArray().  
> > This function sometimes causes a 16384 element Common::Array of 
> > PathDirectionData to be created while it is in operation.  This comes 
> > to 196608 bytes.  My (bad) fix for this was just to change the 
> > PathDirectionData structure in engines/saga/actor.h from this:
> >
> > struct PathDirectionData {
> >    int8 direction;
> >    int x;
> >    int y;
> > };
> >
> > to this:
> >
> > struct PathDirectionData {
> >    int8 direction;
> >    s16 x;
> >    s16 y;
> > };
> >
> > This causes the struct to be only 8 bytes (after padding) instead of 
> > 12 and therefore the large array shrunk to 131072 bytes.  This made it 
> > fit into RAM.  I'm not really certain that the struct doesn't use the 
> > full 32 bit range, but the game seems to work fine to me with this 
> > fix.  Perhaps someone with knowledge of this code could comment?
> >
> > Also, the game is still close to the end of memory, but a lot of RAM 
> > seems to be freed after the first scene with the chess tournament.  Of 
> > course, I'm not sure if there are more memory intensive sections of 
> > the game later on, but this is also the case with every other game 
> > that I run on ScummVM DS.
> >
> > I also played around with the automatic expansion algorithm of 
> > Common::Array.  This template doubles the number of elements it can 
> > hold each time it runs out of memory, which strikes me as a little 
> > inefficient with RAM.   I had a go at some alternatives but 
> > unfortunately the performance of the pathfinder suffered way too much 
> > if the array resizes itself too often.
> >
> > So, if this is okay with everyone else, and it won't break the game, 
> > I'll commit this fix.
> >
> > Thanks,
> >
> > - Neil
> >
> 
> ...one more thing before anyone comments.
> 
> I of course didn't mean to use the type 's16' which is only available on 
> the DS, I should have used 'signed short' in the struct definition above.
> 
> Thanks,
> 
> - Neil
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

_________________________________________________________________
Hotmail® is up to 70% faster. Now good news travels really fast. 
http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090816/0e6322ae/attachment.html>