UpdateRect does not work!

[GoogleCodeExporter]

I was porting Rocks'n'Diamonds to the Wii, and then I found out UpdateRect 
does not work! I tried replacing them with SDL_Flip but then the game 
lagged a lot, and it would be hard to make a timer to update it 1/60th of 
a second!

This is not a critical issue as I can try and do the timer, but I'd like 
it to be fixed. It will also help newbie Wii porters and generally improve 
perfomance IMO.

Original issue reported on code.google.com by asiekie...@gmail.com on 16 Jun 2009 at 12:24

[GoogleCodeExporter]

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

Original comment by iamsca...@gmail.com on 23 Jun 2009 at 6:49

• Changed state: Accepted

[GoogleCodeExporter]

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

Original comment by dborth@gmail.com on 1 Jul 2009 at 7:50

[GoogleCodeExporter]

nevermind, that was a bad idea.

Original comment by dborth@gmail.com on 1 Jul 2009 at 8:16

[GoogleCodeExporter]

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.

Original comment by asiekie...@gmail.com on 2 Jul 2009 at 5:51

[GoogleCodeExporter]

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?

Original comment by dborth@gmail.com on 2 Jul 2009 at 6:04

[GoogleCodeExporter]

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.

Original comment by iamsca...@gmail.com on 2 Jul 2009 at 5:34

[GoogleCodeExporter]

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.

Original comment by asiekie...@gmail.com on 3 Jul 2009 at 2:01

[GoogleCodeExporter]

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

Original comment by dborth@gmail.com on 3 Jul 2009 at 4:00

[GoogleCodeExporter]

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

Original comment by brijohn@gmail.com on 12 Jul 2009 at 5:21

Attachments:

• video_updaterects.patch

[GoogleCodeExporter]

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...

Original comment by dborth@gmail.com on 15 Jul 2009 at 4:50

[GoogleCodeExporter]

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.

Original comment by iamsca...@gmail.com on 15 Jul 2009 at 7:02

[GoogleCodeExporter]

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.

Original comment by brijohn@gmail.com on 16 Jul 2009 at 5:53

[GoogleCodeExporter]

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

Original comment by brijohn@gmail.com on 16 Jul 2009 at 2:20

Attachments:

• update_rects.patch

[GoogleCodeExporter]

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

Original comment by dborth@gmail.com on 16 Jul 2009 at 3:05

[GoogleCodeExporter]

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

Original comment by asiekie...@gmail.com on 16 Jul 2009 at 3:07

[GoogleCodeExporter]

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.

Original comment by dborth@gmail.com on 23 Jul 2009 at 6:26

• Changed state: Fixed

[GoogleCodeExporter]

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.

Original comment by dborth@gmail.com on 23 Jul 2009 at 7:08

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by dborth@gmail.com on 4 Aug 2009 at 7:20

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by dborth@gmail.com on 4 Aug 2009 at 8:53

• Changed state: Completed