Texplay Compositing Problem

By RavensKrag Date 2010-08-13 21:24 Edited 2010-08-13 21:33

I am building a game where the sprite of a character changes to reflect the equipment applied to that character. To this end, I wanted to store the "pieces" of the character (such as weapons and armor, as well as features like hair and eyes) on different "layers" which are composited at runtime. I have been using Texplay to composite the images, but there has recently been a problem. When the images are composited, the colors become altered.

This is basically the code that I am currently using to composite the image.
@spritesheet.splice(subsprite, 0,0, :alpha_blend => true)

Where @spritesheet represents the image that will eventually hold the composited sprites, while subsprite is the hair, or clothing, or whatever.

The actual code can be seen on github
http://github.com/RavensKrag/eternity/blob/master/Animations.rb

Here's a picture for reference. I have drawn both a "precomposited" version assembled in photoshop, as well as the version composited using Texplay.

By banister Date 2010-08-14 10:46

hmm, when you say recently a problem do you mean you never had this problem before, and so it's due to a bug introduced by a recent commit?

Is it possible you could provide a minimal code sample that illustrates this problem, so i can work on that?

thanks :))

By RavensKrag Date 2010-08-15 06:08 Edited 2010-08-15 06:33

EDIT
I'm pretty sure it's not me now. So here it is. I think the problem occurs when you try to call Gosu::Image::load_tiles on an image that has been edited by Texplay. This error does not occur when calling that method on a image loaded directly from a file.

I think this should be a simple example of what's going on.
http://gist.github.com/525155

Just replace the paths to the images with the images here
http://github.com/RavensKrag/eternity/tree/master/Sprites/People/

Hmm, I looked at my code again and now I think the problem lies somewhere around the part where the spritesheet is split into sprites, not when the layers are composited. I'll take a better look to make sure it's not something I did without realizing it.

By lol_o2 Date 2010-08-15 09:42 Edited 2010-08-15 09:58

You are right. The problem is with splitting. Just try to draw the sheet before making array and you'll see.

Tested, working, but bad code for it:

@spritesheet = Image.load_tiles(self, "Body/1.png", 40, 80, false) #load body in tiles
id=0 and image=Image.load_tiles(self, "Hair/1.png", 40, 80, false) #set id to 0 and pre-load image to splice (it's needed, don't know why)
@spritesheet.each{|img| img.splice(image[id], 0,0, :alpha_blend => true) and id+=1} #calling splice for each image in array

By banister Date 2010-08-15 11:44

ok cool.

unfortunately i wont have time to look at it for a few days, is there an ok workaround in the meantime?

By banister Date 2010-08-15 14:44 Edited 2010-08-16 05:33

I'm not saying for sure, but i think this isn't a TexPlay issue but a Gosu::Image#to_blob issue. I tried reverting from Gosu::Image#to_blob to the old TexPlay#to_blob by going: class Gosu::Image; remove_method :to_blob; end but im strangely getting segfault (in windows).

EDIT: and in linux everything seems to work ok, i dont get any color distortions and both Gosu::Image#to_blob and TexPlay#to_blob work fine :/
EDIT EDIT: ok, it is broken in linux too, sorry

By Spooner Date 2010-08-15 16:35 Edited 2010-08-15 16:42

I think you are right. I just checked to_blob and it is a little broken, on Windows, at least. I used to_blob and my own from_blob (which just creates a new image with a duck-typed fake image-magick object) to see if there is a change and there was a similar colour-shift. I think I had the same problem when I tried to save a screenshot with Devil, but I assumed it was something else.

Yellow (FFFF00) => cyan (00FFFF) and vica versa
Red (FF0000) => Blue (0000FF) and vica versa
Green (00FF00) => Green (00FF00)
Black => black

Obviously, red/blue is switching somewhere along the line!

By jlnr (dev) Date 2010-08-15 18:28

Wow, I think this fix actually makes the code five lines shorter.. Does anyone here happen to build Gosu from source to verify the fix? :)

By RavensKrag Date 2010-08-15 18:49

Wait... everyone said that this was a Windows problem, but I got this error on Ubuntu Linux o_O; However, I applied the code to remove Gosu::Image#to_blob, and it is now working fine.

As to the code becoming shorter, are you referring to your code, or mine?

By jlnr (dev) Date 2010-08-16 03:45

I'm referring to the code in Gosu::Image#to_blob, or actually Gosu::Texture::asBitmap internally. This code is used on all platforms except PowerPC Mac OS.

By banister Date 2010-08-16 05:21

ok i take it back, Gosu::Image#to_blob is broken on linux too :( But it looks like jlnr is rolling out a fix soon

By jlnr (dev) Date 2010-08-16 06:07

I plan to publish the current state of Gosu during this week (in time for LD). I just don't have time to verify the fix. I wish you guys luck though. ;)

By jlnr (dev) Date 2010-08-15 18:25

I am proud to announce that Gosu is the first library with auto-zombification of human characters!

By Spooner Date 2010-08-16 08:44

Conversely it auto-humanises zombies! :(