diff options
author | Johannes Schickel | 2011-04-19 15:05:18 +0200 |
---|---|---|
committer | Johannes Schickel | 2011-04-19 15:05:18 +0200 |
commit | 8ff527ac4ef4237e63c0802a22eb0f942089e6c4 (patch) | |
tree | dfee67cb0fc390926165661c8371cadb5710d7cc | |
parent | 53d982b24f9cec69e6ce35ccaab7ad1a62556c5b (diff) | |
download | scummvm-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.cpp | 8 |
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)); |