[Scummvm-devel] Adding splashscreen to ScummVM

[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.


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.  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.
 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).

 - Gus