[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