|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
|
|
Re: Difference between Mac OS X and Windows render resultsHey. Here's our theory:
http://bugzilla.libsdl.org/show_bug.cgi?id=868 Here's a test gradient to try: http://m8y.org/tmp/Sky.png This one shades from FFFFFFFF to 00FFFF00. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render results
Unfortunately, while the effects of screwing up channel would look like what we're seeing, and while our test gradient seemed to work, further testing with Red held at 100% didn't seem to support the hypothesis. Testing removing of iCCP/cHRM/gAMA next. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsOk. We seem to have two issues.
One is an issue w/ PNG colour correction that is apparently being loaded by SDL and doesn't work well with our hardcoded colours. pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB seems to solve this. Unfortunately it is completely different from the gradient problem. Still trying to figure out what is up with that one, but about to verify that the SDL Surface values match what we think they should be before passing 'em to OpenGL. Wondering if it could be some glBlendfunc thing. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsOk, dumping the first column of a buggy SDL surface, we noticed an interesting pattern:
A B G R SDL on OSX 206 | 177 | 131 | 125 GIMP 206 | 220 | 163 | 155 SDL on OSX 14 | 8 | 5 | 4 GIMP 14 | 157 | 92 | 84 Pattern seems to be that if you take: 177 * (255/206) ~ 219 and 8 * (255/14) ~ 146 Now, that 2nd one is not so accurate. But. 157 / (255 / 14) = 8.58 which if truncated is 8. 220 / (255 / 206) = 177.72 = 177 So we could be dealing with some curious modification proportional to alpha and a floor operation to boot. Fortunately the fix for that is fairly trivial, until SDL is fixed, we can ifdef DARWIN to reverse the damage. The truncation means some accuracy is lost, but hopefully not too much. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsNow, if I take the image in GIMP, and merge it against an all-black layer, I now get the same values as OSX (not including the alpha of course):
B G R 8 5 4 instead of 157 92 84 So the bug appears to be that whatever is loading the surface is acting as if it is loading the image blitted against all black, then reapplying the alpha. Just a WAG - anyway, the symptoms are the same. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsConfirmed.
When we dumped under Linux, the values were correct. Furthermore, due to different people editing the image, some transparent areas were: A B G R 0 | 255 | 255 | 255 and some were 0 | 0 | 0 | 0 On different parts of the file, presumably due to different editors touching the png. This is fine, we've always handled this in past where we needed to check fully transparent by checking the high byte, not the entire word. Perhaps someone got the idea of normalising the two to 00000000 but did it in an odd fashion. So the workaround for now is indeed to take the OSX RGB values and brighten them proportional to the alpha in the surface. This will have an unfortunate performance cost, but is luckily trivial. Hopefully this bug will be fixed quickly. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsFinal workaround:
{$IFDEF DARWIN} tmpP := tmpsurf^.pixels; for i:= 0 to (tmpsurf^.pitch shr 2) * tmpsurf^.h - 1 do begin tmpA:= tmpP^[i] shr 24 and $FF; tmpR:= tmpP^[i] shr 16 and $FF; tmpG:= tmpP^[i] shr 8 and $FF; tmpB:= tmpP^[i] and $FF; if tmpA <> 0 then begin tmpR:= round(tmpR * 255/tmpA); tmpG:= round(tmpG * 255/tmpA); tmpB:= round(tmpB * 255/tmpA); end; if tmpR > 255 then tmpR := 255; if tmpG > 255 then tmpG := 255; if tmpB > 255 then tmpB := 255; tmpP^[i]:= (tmpA shl 24) or (tmpR shl 16) or (tmpG shl end; {$ENDIF} This is not as accurate at the low end due to the initial truncation. A slight bias could be introduced to help a bit. Anyway, it works "good enough" Hopefully this will be fixed soon and we can remove it. _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsHmm.
I should process the loaded SDL_Surface in this way, right? _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||
|
|
Re: Difference between Mac OS X and Windows render resultsyes, and if you get swapped colors you just have to convert the surface like this
http://www.idevgames.com/forum/showpost.php?p=85954&postcount=9 bye Vittorio On Fri, Oct 30, 2009 at 12:19 PM, Dmytro Bogovych <dmytro.bogovych@...> wrote:
-- Pablo Picasso - "Computers are useless. They can only give you answers." _______________________________________________ SDL mailing list SDL@... http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
| Free embeddable forum powered by Nabble | Forum Help |