[Scummvm-devel] Adding splashscreen to ScummVM

Max Horn max at quendi.de
Mon May 24 21:20:12 CEST 2010


Am 23.05.2010 um 03:40 schrieb Angus Lees:

> On Sat, May 22, 2010 at 04:23, Max Horn <max at quendi.de> wrote:
>> The splash screen code I have in mind would essentially need some image data (which it could store inside the code, in form of a byte array), and a pointer to a Graphics::Surface (a very light weight structure which works as long as you have a "framebuffer" to write graphics data to). No backend requirements necessary. A backend could use it long before e.g. an OSystem instance is created, or before scummvm_main is called.
>> 
>> If a "framebuffer" approach is not viable, tell me what *is* viable on your device and we can think about a solution that works with that, too. E.g. if you prefer to give the splash screen code a pointer to a "putpixel" or a "blit" callback, we can certainly do that, too. How does your current splash screen code work?
> 
> My current splash screen code uses basic Android framework features to
> display as easily and as early as possible:
> - Orange (gradient) background, big "ScummVM" png centered on the
> screen, with a progress widget underneath.  All basic Android GUI
> widgets used in the usual Android way (XML file describing screen
> layout).
> - Unpacking code and progress bar callbacks are Java.
> - After everything is unpacked it replaces the screen with a basic 2D
> framebuffer widget and jumps to scummvm_main.

OK, makes sense.

> In order to reuse some ScummVM-provided splash screen code, I could
> have a separate (small) native library (C or C++) that was already
> unpacked onto the system at package-install time.

Hm... so if I wanted to remove the splash, I just would have to replace that small library by my own? Without modifying any source code? Hm.

Maybe we should simply agree on a how a splash screen should look, turn this into a "specification" on the Wiki (of course a flexible one. Must work on all kinds of screens ;). Then provide a default implementatin (to be used by the SDL port, and any other port that can use it), and allowing other ports to implement it in a different way, if they need to -- as long as they make it look close to what the specification requires. 

>  Framebuffer, blits,
> whatever are fine and I'll just convert it something the system
> understands - avoiding unnecessary animations and full-screen redraws
> would be good since it would reduce performance requirements.  I would
> definitely want to be able to feed it additional progress information.

That was my original plan, mostly, yes!

> It would also be easier for porters if there were no need to share
> state between the loader/splashscreen and ScummVM-proper (they might
> be separate processes, for example).

Yes, that would be a no-go.

Bye,
Max



More information about the Scummvm-devel mailing list