[Scummvm-devel] status of new smush player integration.

Xavier Trochu xavier.trochu at wanadoo.fr
Sat Aug 17 17:01:15 CEST 2002


Hello everyone !

I wanted to give you some feedback about the integration of the new 
smush player inside scumm, and ask a few questions.

Removal/rewrite of everything that was unneeded or unwanted (STL and 
exceptions) has been finished. This has introduced a few bugs in the new 
code, some of them I've not yet found. This modifications introduced a 
dependency on locale C library (calls to isdigit() and atoi()). I hope 
it's not a problem for some ports.

Mostly, at home, the new smush player works but without sound. My 
original smush player implemented a sound mixer which is not needed 
anymore, so the different interfaces to mixer and channels must be rewrote.

I need information concerning how sound works in scummvm.

In Full Throttle, 8 bit samples are mixed in stereo using a balance 
parameter. From what I saw, the current mixer implementation does not 
support this. Am I right ? Do I need to implement a subclass of 
Mixer::Channel for this ? If yes, what is basically needed to create 
such a subclass ?

In several animations, samples can have differents sampling rates : 
22050 Hz, 11025 Hz and also a more difficult 22222 Hz. Can I assume that 
they will be correctly handled by the mixer ?

If you took a look at the original code, you'll see that it is split in 
several source files. For integration, I put them in a "smush" subfolder 
of the scummvm base source folder. So you have :

/path/to/scummvm/smush/player.cpp
/path/to/scummvm/smush/renderer.h
...

It seemed to be a good idea, and even more with the recent thread 
concerning the source tree structure.

Something that is going to go high in the todo list as soon as the 
integration is validated, will be to make the code endianess-aware.
Right now, it is little-endian only. AFAIK, endianness in scummvm is 
handled in the Scumm instance. I find this not a very good solution, 
because that means keeping a pointer to this instance in a lot of code 
that only needs it for endianness handling. Are there plans to change 
this ? I think a better idea would have something like a 
"endian.h"/"endian.c" file that implements functions like :
unsigned short ReadBigEndianWord(FILE *), unsigned int 
ConvertLittleEndianDWord(unsigned int), ...
some of them could then be set as void macro if host endianness is known 
at compile time.
What do you think about this ?

Well, that everything I can think for today...

Greetings,

Xavier





More information about the Scummvm-devel mailing list