[Scummvm-devel] Adding splashscreen to ScummVM

John Willis John.Willis at Distant-earth.com
Fri May 21 13:16:46 CEST 2010


All,

> > I'm all for making some standardised graphics, etc available that ports
could
> show on their splash screens - but I suspect even legitimate ports would
> have a reason to want to disable a "standard" splash screen.
> 
> Of course we should not have a double splash screen. My vision would be to
> write the splash screen code so that it can be easily used by a backend as
its
> custom splash screen -- i.e. the splash screen code would optionally show
a
> progress bar, and would work with arbitrary resolutions. Think of a tiny
> SplashScreen object which gets a surface to render to, and has a display()
> method, maybe also an updateProgress() method.
> 
> Anyway, there is no reason for code duplication nor for splash screen
> duplication, that's for sure :).

Can't say I have any strong feelings on splashscreens. I guess I veer a
little to 'don't mind if they are optional as I hack them out while
developing' but I can understand the reasons and they seem valid. If it's
consistent (maybe half a sec. tops plus whatever overhead a backend would
like to hide in it) I would not mind.

That said, I am with Max in so much that if we go for a splashscreen then
please, please, please design it in such a way that it really needs the
absolute minimum of ScummVM up and running before it is shown.  At least
then low ports can get the screen shown before the hard slog of getting
ScummVM's main code loading is kicked off. 

We may also want to look into ways that a pre-ScummVM stub could pass in a
progress level into the splashscreen so there pre-init splashscreen can
neatly integrate with the ScummVM (using the same graphics etc.). I am
thinking of Android and the likes but historically I had to do a fair bit of
pre-processing on the old GP32 port that was hidden behind a splashscreen
long before we went anywhere near initBackend() and I am sure these will not
be the only examples of this sort of need.

Cheers,

John






More information about the Scummvm-devel mailing list