[Scummvm-devel] Adding splashscreen to ScummVM

[Willem Jan Palenstijn]

On Thu, May 20, 2010 at 06:18:46PM +0300, Eugene Sandulenko wrote:
> On 20 May 2010 17:58, Willem Jan Palenstijn <wjp at usecode.org> wrote:
> > Do we really have a visibility problem that needs to be addressed?
> Unfortunately we do. Like recent story with DotEmu.com when they
> silently shipped our binaries as part of their games but gave
> absolutely no visibility to us. Of course there were direct GPL
> violations, but at least it would be easier to spot if there was a
> splash.
> 
> > I'm guessing "Illegal borrowings" would already have to strip out things
> > like the in-game About dialog, so stripping out a splash screen as well
> > won't be much extra deterrence, I think.
> Skipping display will clearly show bad intentions. Easier to go to the
> court. Simply as that. And also that is a definite source code
> modification, so the source changes will have to be published.

I think I see your point, but I really don't think 'negative' reasons like that
are the right reasons to add features. It's potentially annoying a lot of
people for some kind of deterrence. It's nowhere near on the same level of
annoyance, but it's comparable to unskippable things at the start of DVDs.


> > Also, a large part of the point of specifying a target on the command line
> > is to speed up launching the game, while a splash screen would only slow it
> > down.  (And the slow-down it causes would possibly be even greater when
> > running in debuggers like valgrind.) I don't know the length of the one in
> > dosbox, but it's definitely long enough to annoy me (and so I have it
> > disabled in my local copy).
> In dosbox it is about same 0.6secs, and I believe that developers are
> proficient enough to disable it anytime, but anyone who is going to
> grab the sources, compile and distribute will either modify the
> sources or we will get the visibility which also users can report.

Sure, but it's a pain to have persistent local patches around that can't
ever be committed. Especially for things like bisecting for regressions, when
extra startup time is doubly annoying because you're already doing the same
thing over and over again. (And the mere need for useful but uncommittable
patches like that shows that something isn't entirely optimal.)


I won't make an issue of it, but I still don't think it's a good idea.


-Willem Jan