[Scummvm-devel] GSoC Student Introduction
Johannes Schickel
lordhoto at scummvm.org
Wed Apr 28 18:28:58 CEST 2010
On 04/28/2010 07:26 AM, Angus Lees wrote:
>
> There are a number of things that can be done to make it perform
> better (GLES1.1 pbuffers and DrawTex). I'm also looking forward to
> trying a GLES2 version that uses fragment shaders to reimplement
> old-skool 8-bit palette hardware in the GPU ;)
> This is also my first real attempt at GL coding, so I'm sure there are
> plenty of other things that can be improved.
>
> There are also a few core ScummVM changes that could have a big impact
> on a GL(ES) based backend. In particular:
> - Things that read the screen like grabOverlay and lockScreen() are
> either slow (copy from graphics memory), or memory intensive (maintain
> a second copy in main memory)
> - CopyRectToOverlay currently doesn't batch groups of writes at all -
> which makes it hard to do a single texture conversion/upload. This is
> quite different to the main game screen with periodic calls to
> updateScreen().
>
Hi,
I am not sure what you exactly mean with "copyRectToOverlay", actually
also the overlay content should only be updated when updateScreen is
called, thus I am unsure whether you mean that you just currently
implement copyRectToOverlay differently or whether you think that
copyRectToOverlay does update the overlay immediately.
// Johannes
PS: I just checked our documentation, it seems not clear about the exact
behavior, but copyRectToOverlay shouldn't update the overlay directly
and updateScreen should definitely also update the overlay. That is the
behavior of the SDL backend at least, which is more or less our
"reference" implementation.
More information about the Scummvm-devel
mailing list