aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohannes Schickel2011-04-19 15:05:18 +0200
committerJohannes Schickel2011-04-19 15:05:18 +0200
commit8ff527ac4ef4237e63c0802a22eb0f942089e6c4 (patch)
treedfee67cb0fc390926165661c8371cadb5710d7cc
parent53d982b24f9cec69e6ce35ccaab7ad1a62556c5b (diff)
downloadscummvm-rg350-8ff527ac4ef4237e63c0802a22eb0f942089e6c4.tar.gz
scummvm-rg350-8ff527ac4ef4237e63c0802a22eb0f942089e6c4.tar.bz2
scummvm-rg350-8ff527ac4ef4237e63c0802a22eb0f942089e6c4.zip
GROOVIE: Replace TODO about YUV data with a comment.
Since the surfaces in question are never used outside the ROQ code it is fine to use a faked RGB pixel format even when they are actually YUV data.
-rw-r--r--engines/groovie/roq.cpp8
1 files changed, 5 insertions, 3 deletions
diff --git a/engines/groovie/roq.cpp b/engines/groovie/roq.cpp
index fe5d05f65d..b671cbd0a8 100644
--- a/engines/groovie/roq.cpp
+++ b/engines/groovie/roq.cpp
@@ -328,9 +328,11 @@ bool ROQPlayer::processBlockInfo(ROQBlockHeader &blockHeader) {
_prevBuf->free();
// Allocate new buffers
- // TODO: According to the comment below these are actually YUV
- // surfaces, thus we can not setup a proper PixelFormat here.
- // Think of a proper way to indicate that it is YUV data.
+ // These buffers use YUV data, since we can not describe it with a
+ // PixelFormat struct we just add some dummy PixelFormat with the
+ // correct bytes per pixel value. Since the surfaces are only used
+ // internally and no code assuming RGB data is present is used on
+ // them it should be just fine.
_currBuf->create(width, height, Graphics::PixelFormat(3, 0, 0, 0, 0, 0, 0, 0, 0));
_prevBuf->create(width, height, Graphics::PixelFormat(3, 0, 0, 0, 0, 0, 0, 0, 0));