Menu
▾
▴
#6227 WME: DeadCity - purple areas on the screen
I\'m playing through The Dead City and it seems some textures are not loaded the right way.
Note that they do not appear at random times. They always affect the same scenes, as you can see in my screenshots.
On the text console some warnings appear:
WARNING: JPEGDecoder::readJFIF() Non-v1.1 JPEGs may not be handled correctly! (<--- this appears MANY times)
WARNING: BaseRenderOSystem::DrawLine - doesn\'t work for dirty rects yet! (<--- this appears just ONE time)
The bad issue is, due to these missing textures, a particular location is not playable at all (it\'s at the bridge) so the game is not completable.
Discussion
the apartment (the beginning)
street view
the bridge, the blocking location
OS: ubuntu precise 12.04 with gcc 4.6
scummvm --version gives:
ScummVM 1.6.0git (Jan 12 2013 19:17:36)
Features compiled in: TAINTED Vorbis FLAC MP3 ALSA SEQ TiMidity RGB zLib FluidSynth Theora AAC FreeType2
the game is provided with different languages, I'm playing the ita version.
The JPEG warning is irrelevant and I have removed it so it won't be in future builds. (I was worried about version issues, but the version differences are solely related to thumbnails, which we don't use)
I just had a look at some of these broken JPEGs.
sprites\neon2.jpg (the neon sign in the apartment) shows broken (i.e. purple) with my system's image viewer... seems like the image itself is somehow badly encoded?
I haven't progressed further to check the other two, but they seem to suffer from the same issue, IMHO
Since neon2.jpg looks like a solid FF00FF rectangle, this is more likely to be a colourkeying/transparency/alpha problem, I think. This same neon2.jpg is used in multiple sprites in frames that should "light up".
I would like to see those jpegs too!
Which tool are you using for extracting resources from `data.dcp' ?
With the new jpeg decoder work going on I took another brief look at this, and any potential rounding errors in there do not seem to be responsible. Hardcoding a 254-to-255 postprocessing step does not fix the visual problem.
Clarification: it's not _exclusively_ responsible.
needsColorKey is determined to be false by BaseSurfaceOSystem::finishLoad() for this image. Haven't looked at how/why.
The needsColorKey part is fixed by e5f9cb3cbbc047a1359354475c1128454491f331.
The remaining issue is indeed that this JPEG is decoded as FE00FF which makes it fail the colorkeying.
The remaining part was fixed a few weeks ago by using libjpeg.