[Scummvm-devel] Minimal screen updates and possible OSystem improvements

[Max Horn]

Am 10.11.2009 um 17:44 schrieb Vladimir Menshakov:

> So another real world example, allowing quick porting of the  
> TeenAgent engine to the new api.
>

[...]

> No backbuffer in engine, no extra surfaces allocated in engine,  
> removing custom tricky logic from each engine. Less code - less bugs.
> PROFIT
> :)

Vladimir,

seems we keep misunderstanding each other :). Neither this nor the  
MADE example you gave earlier answer my question about real world  
*benefit*. So to repeat the question: Is there a particular device  
(e.g. PSP, NDS, ...) where the the MADE engine or the TeenAgent  
example you just gave suffer from issues which your changes are likely  
to solve but which are hard or impossible to solve with the current  
code base?


In principle, I like factoring out common code for exactly the reasons  
you gave -- less code, meaning less chances for bugs. BUT in this  
case, we'd have to modify lots of well-tested and debugged code -- in  
that case, the chance of introducing *new* bugs seems much higher than  
the chance of this resulting in a fix for some so-far unfixed bug.

So maybe this would be nice because it reduces memory usage and helps  
some specific engine on some specific backend. But that seems rather  
vague. And the added code size required for backends to support this  
API might offset it again.

This leaves a single advantage that I see (maybe I am missing  
something, though): *New* and under-development engines (such as your  
teenagent engine) might benefit from this new API. Fair enough.  
However, it would still require modifying all backends. Now if we can  
augment the OSystem API in a way that allows what you want but also  
allows backend authors to adapt it with minimal changes to their  
backend (making "native" backend support for things like colorkey or  
lockRect optional, emulated by default), we could investigate this  
further.

In that case, I would propose you suggest a specific OSystem API  
extension, in (pseudo) C++ syntax, as well as a brief description (if  
it's not obviously clear) how each change/addition to OSystem could be  
mapped to the existing API for emulation (with the implied loss of the  
performance boost one would get by "natively" implementing the change).


I am sorry for appearing to be such a spoil sport. I actually totally  
appreciate your enthusiasm for this new feature. But we have to  
carefully balance new features against the cost they incur on the  
existing code base, and that includes backends (not just engines).  
This is the very reason why it took so long to add 16/32bit support to  
OSystem -- doing that by itself was relatively trivial, the tricky  
part always is to come up with a way that is mostly backward  
compatible, does not penalize low spec systems, does not force us to  
make major changes to *all* engines or backends, etc.

This is sometimes annoying (believe me, I am often frustrated by  
it ;), but it's the reality of such a relatively big project with many  
contributors.

Anyway, my point is: Don't get discouraged if I seem to put many  
stones in your path, it's not meant to kill your ideas, just trying to  
refine and channel them. ;)


>>
>> Like, can you name some specific
>> specific combinations of devices and games which currently have  
>> issues
>> which cannot be resolved in the current OSystem design, or which are
>> hard to solve with it; and which would become "easy" to resolve  
>> with a
>> hypothetical revised API as you propose it ?
> Why hypothetical? It is widely used. Direct3d for example.

I was referring to *our* API -- so it is "hypothetical" because  
ScummVM does not yet provide such an API. As you know, Direct3d is not  
a ScummVM API :)


>> You named engines which might benefit from a colorkey enabled  
>> blitting
>> API, etc., but it is not clear to me whether any of those actually  
>> has
>> issues which the new API would resolve.
> Please grep scummvm sources by "lockScreen". In most cases  
> lockScreen is localized in rectangle and do not requires any  
> fullscreen update.


Yes, I know how to use grep, and I introduced many of those "evil"  
lockScreen calls myself :). And I know it's inefficient (I introduced  
the API, fully aware of all its drawbacks -- and its advantages  
compared to what we had before it ;).

However: That doesn't mean it is *too* inefficient :). And no amount  
of grepping will determine whether we need to do something about it or  
not. You'll have to provide some real world evidence, were "real  
world" does not mean code, but rather "a physical device running an  
actual game too slow" ;)


Bye,
Max