[Scummvm-devel] PS2 ScummVM 0.11.x updates!

[Eugene Sandulenko]

Hi Max,

I'd like to address some of your questions.

On Thu, 14 Feb 2008 01:29:00 +0100
"sunmax at libero.it" <sunmax at libero.it> wrote:

> Sure thing! Is there a scummvm-place when I can upload them?
> Or should I send their tarball to you together with the PS2 patch
> in a few days?
In our svn tree we have special vendor/ module which contains some of
the upstream sources. So you may put those there and even build from
that place.

> >> we are moving towards using DXA instead of MPEG2.
> 
> Got it. I am still catching up through the scummvm forum topics,
> can you tell me which was the main reson for that? Copyrights?
> Performance? Quality?
Performance and quality. DXA is a lossless format, it is 8-bit format,
and finally, it is even gives better compression ratio than Smacker.
MPEG2 was really a hack, and we are dropping down its support
eventually.

> Now a (likely) dumb question: what about the cutscenes in the other
> games? E.g. the .san in The DIG? Are they doing any YUV -> RGB in SW?
> Or are they just palettized? How are they handled by SmushPlayer?
The reason why we introduced mpeg2 and DXA later is that there were no
open source decoder for SMK (Smacker) videos. All other videos run in
their original format, thus pertaining exact original quality. However,
speaking of .san videos, there is a compression tool for those which
add zlib compression to each frame. This gives huge size decrease. And
yes, those videos are palettized, DXA too.

> How many type of videos are used by scummvm games?
Depends on what you consider a video. Most of the games have cutscenes,
all games have 'videos' for actor animations. Speaking of stand-alone
video formats, Gob engine has VMD, Kyra has WMA and VQA and those come
from top of my head.

> I saw that we have some flexibility with sound files,
> they can be .mp3 .ogg .wav. You name it! Would it be
> possible to have the same kind of flexibility with
> videos?
We use that compression mainly for uncompressed or extremely poorly
compressed WAV files with originally good quality. I.e. in cases where
it really gives us size gain. There is no real advantage in reencoding
videos, as our rule of the thumb is to run with original game data when
possible.

> Or is there a technical reason to keep the videos of a
> certain game in a certain format? (cause maybe it
> already comes with the best quality/size ratio)
Yes, original used those video formats. Also pretty often they sit in
huge container files, so it is really time consuming and unnecessary
step to reencode them. Only thing which could justify the efforts is
that it really will give us to save significant amount of space, and
from the other hand, will have minimal speed impact.

> The PS2 backend (like the PSP) contains a do-it-all makefile,
> it's that an accepatable solution for now?
Yes, this is acceptable. It just puts additional burden on you, to keep
in sync with our file layout changes. However, as you may saw, we
already support 8+ different building tools with different building
scripts.

> Should we on the long run port it to a 'configure'-friendly
> build process or it really does not matter?
That is a preferable of course, but here you should take into account
how difficult it would be to achieve.

> What I am supposed to do? To #ifdef it for the PS2? Or could
> we just add an extra letter to _open (you choose it!) Well
> it could be something like _ps2sdk_sucks_open too ;-)
I recommend to rename this variable. This is a routine situation for
us, many platforms and compilers brought us similar surprizes.

> I think I got exists / isReadable / isWritable / lastPathComponent in
> place.
> 
> Do I have a way to test it? Or the fact itself that the games I tested
> (Dig, Sam&Max, MI1/2 for now) are working is a sign that I got it 
> right?
Go to http://www.wyrmkeep.com/ite/, downloads section and get Inherit
the Earth demo. Try to run it in your port. Without proper exists()
implementation games just do not start.

> I saw "listSavefiles" changed too (now it returns Common::StringList),
> but some backends (e.g. 'ds') have just stubs for it. And others
> (e.g. 'palm') they are still using "void ... ::listSavefiles(const
> char *prefix, bool *marks, int num)" version. Who wins?
common/savefile.h wins.

> 
> Can somebody describe the semantics of the new "Common::StringList ...
> ::listSavefiles(const char *pattern)"? Is it as simple as returning
> a list of files that match the pattern? Is that in cwd? What happened
> to 'prefix' and 'num' arguments?
Reference implementation lives in
backends/saves/default/default-saves.cpp

So if you have different implementation, it would be better if you put
it to backends/saves/ps2. The reason of mixture of implementations you
mention above is that not all backends are converter to our new in
0.11.x modularized structure.

> 3) cleanup on exit
>    [btw: what is scummvm supposed to do on exit? On a PS2 it should
>          get back to the game launch menu, otherwise you have to
>          reboot all the times... does this require a core change
>          or is it doable just in the backend?]
Return back to launcher is our ever-demanded feature. Unfortunately it
is not possible now, as engines do not clean up memory after them
properly. This is an IMHO good GSoC 2008 task.

> 5) test as many games as possible
>    [of course I cannot play all of them from start to end,
>     even if I would like to ;-) - is there anybody aware of
>     some game / engine that used to crash with the previous
>     releases of ScummVM/PS2 ?]
I suggest to have set of demos for each and every supported engine and
at least start and play for couple of minutes each of them.

> 7) timididy ?
> 
> Max, I did not get what you mean with "It's", does it mean
> that we -must- have it in place for ScummVM PS2 0.11.1 to happen?
I don't think so. The good goal would be to have PS2 port in 0.11.1,
but timidity is too big change.


Eugene