UpdateRect does not work! about sdl-wii HOT 19 CLOSED

Confirming that SDL_UpdateRect does not seem to work :(  Changing status to 
accepted.

I set SDL_UpdateRects() to call the flip, is this sufficient?

nevermind, that was a bad idea.

dborth: I actually changed all UpdateRects to Flips. But, the point is, 
UpdateRects 
updates only PARTS of the screen, and Flip updates the entire screen. And 
imagine 
flipping 1024 times in a frame.

yes but with this implementation we're never going to let you update the screen 
directly, it has to work a bit different. it should only be drawn only once per 
frame, which I believe is what UpdateRects is supposed to be for, kind of 
the "equivalent" of the Flip() function, if you're using UpdateRect calls 
instead?

With SuperTux it does update the screen tile by title using SDL_UpdateRect(). 
Basically I just changed this to SDL_Flip() which seems to work fine.  I'm 
really not
sure of the performance hit is though.

I think the simplest is to just flip instead.  It's probably what needs to 
happen to
blit the GX texture to the screen anyway.  The other option is to dynamically 
create
a GX texture per UpdateRect request which is probably much slower than doing a
straight flip.

It is sometimes a big perfomance hit, especially if you do 50 updaterects/frame 
in 
comparison to 50 flips/frame which makes it 50 frames. Can't you just set up a 
thread that every 1/60th of a second (or 1/50th on PAL) flips? This is a 
workaround 
but a good one.

Well that's what I was thinking to do in UpdateRects(), but I guess maybe I 
can't do 
it there

How about the following for implementing UpdateRects.

First spawn a thread during SetVideoMode that will take the current texture 
memory
and copy to the screen. Then when UpdateRects is called copy the specified 
pixels
into texture memory. Now text time the tread executes our display will be 
updated
with the correct image. FlipHWSurface can then just call UpdateRects with a 
rectangle
that specifies the entire screen.

Attached is a patch that actually implements this idea as well as includes 
support
for 32bit surfaces as well. It seemed to work reasonable well in my initial
testing.with my port of ONScripter

The patch looks great, but it's a bit problematic in terms of performance. 
After a 
few changes, Super Mario War will run at about 90% speed on this patch. I'm not 
sure 
if it has to do with the video thread or the new conversion code (and switching 
from 
RGBA8 from 565), or something else...

Can't we just update the rect in texturemem and flip whole buffer to the 
screen. 
Maybe not optimal but it would not affect the performance of anything else and 
would
be faster that a complete blit as we'd only update the texturemem specified by 
the rect.

The patch I posted does just update the specified rectangle in the texture 
memory and
then use a thread to continually blit the current texture to the screen. I can 
modify
it so that 8 or 16bit surfaces use RGB565 while 24/32bit ones use RGBA8 and see 
if
that helps the performance any.

I've updated the previous patch to improve performance somewhat. 

* 8 and 16bit surfaces use RGB565, 24 and 32bit use RGBA8
* removed memcpy's from UpdateRect functions
* inlined both Set_RGBA8Pixel and Set_RGB565Pixel

Together with the increase of thread priority I am now able to get decent movie
playback using some code I'm working on to play movies using SDL YUVOverlays

great, I will test this patch out when I get a chance.

Thanks for help, I may start finishing my ports now! :D

ok, I've committed this patch (with a few small changes). there's still a 
slight 
performance decrease noticeable on Super Mario War, when compiled with this 
patch 
vs. without it.

hmm actually I spoke too soon. Something's wonky still, on dosbox the bottom 
part of 
the screen is partly cropped. also the performance hit is even more noticeable 
there. I'm going to roll back until we work out the bugs.

ok, I've combined the submitted patch with the current codebase, UpdateRect is 
now 
supported.