Am 23.05.2010 um 03:40 schrieb Angus Lees:
> On Sat, May 22, 2010 at 04:23, Max Horn <max@...> 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
> - 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.