A few issues with the imageset

[Treize]

Ok, this is my first time experimenting with CEGUI, but I'd studied the .scheme, .looknfeel and .imageset files before so already kinda knew what to expect. I thought it was going to be a walk in the park trying to make a simple new skin based off Taharez, but obviously.. not so much.

I changed all the occurences of 'Taharez' in all the related files to my own name, lets call it 'Teletubby' for sports. I also just copied the .tga from taharez and renamed it in the imageset file. Then i resized the .tga to 512x512 (from the 256x256 original) thinking i should just add my own images and leave the old taharez images intact, so i could skin one component at a time (changing the coordinates in the imageset file). My first try totally blew up in my face. I extracted the coordinates in photoshop using the selection tool and enterred them, but all i got was what seemed to be random taharez-look control textures spread across my framewindow (I was just trying to reskin a framewindow).

Which leads me to my other problem, I noticed i actually had to change the LAYOUT files too just to get it to work with my skin. I mean, i understand that one skin may not have some widgets another does have, but come on, for flexibility's sake why should i have to alter my layout's just to switch skins? Any widget that's not available should just be discarded or something.. In my opinion layout should be independent of theme/skin. Anyway that's just my opinion, i'm willing to just deal with that fact.

But my biggest problem is by far this:
Like i said my textures wouldn't show and it was using random control textures all over the place. So i thought, maybe it's the size of my .tga, so i made it 256x256 again, removing all the taharez look stuff (i also changed the coordinates accordingly in my imageset). Now i get nada, zit, nothing. Just a completely transparent gui with some text. So I'm thinking, well i should at least get SOMETHING if i just make the background color of my .tga grey. So i do this and now bingo, some of my gui textures actually pop up, but with grey borders all over the place (btw this doesn't make any sense to me, it means that cegui is taking different coordinates for the textures just because i changed the background color from white (which it sees as transparent i'm guessing?) to grey). So i'm like wth are the grey borders doing there, so i change the width/height of my widgets in the imageset and fiddle with them subtracting 1 to 2 pixels from each and manage to get rid of some of the borders. But come on, a pixel is a pixel, i measured those dimensions pixel-perfect in photoshop, so why isn't it just taking my 22x22 pixels surface?
And even after that, some of the surfaces don't even line up right with eachother, they're like off 1 to 5 pixels at times.

It's just, if i have to fiddle this much just to get something crappy looking, i don't know.. it's killing me here.

If someone could please make me see some light?

Thanks (I didn't mean to be negative, i think cegui is a great initiative, it's just that i didn't expect this much resistance )

Oh yea btw I'm using the GUI sample from the latest Ogre 1.4 (dunno what cegui version that is exactly).

[CrazyEddie]

Hi,

would it be possible to post the image and the work-in-progress imageset xml? I couldn't fathom what was going on from the description

As far as making a layout 'theme independent', this can be achieved by defining an alias scheme - mapping from a neutral widget name to a specific type. While this may not be suitable for all uses and scenarios, it does offer some flexibility and removes the need to update the layouts (just load or define the appropriate aliases).

CE.

[Treize]

Of course. Here are some screenshots, the .tga i'm using and part of the imageset file.

.tga image: http://www.noirscape.org/test/MyLook.tga

Imageset:

Code: Select all

<?xml version="1.0" ?>
<Imageset Name="MyLook" Imagefile="MyLook.tga" NativeHorzRes="600" NativeVertRes="600" AutoScaled="false">
   <Image Name="ClientBrush" XPos="62" YPos="56" Width="36" Height="36" />
   <Image Name="WindowLeftEdge" XPos="4" YPos="38" Width="10" Height="72" />
   <Image Name="WindowRightEdge" XPos="150" YPos="38" Width="10" Height="72" />
   <Image Name="WindowTopEdge" XPos="44" YPos="1" Width="74" Height="36" />
   <Image Name="WindowBottomEdge" XPos="69" YPos="111" Width="22" Height="22" />
   <Image Name="WindowTopLeft" XPos="4" YPos="1" Width="39" Height="36" />
   <Image Name="WindowTopRight" XPos="116" YPos="1" Width="44" Height="36" />
   <Image Name="WindowBottomLeft" XPos="4" YPos="111" Width="22" Height="22" />
   <Image Name="WindowBottomRight" XPos="138" YPos="111" Width="22" Height="22" />
   <Image Name="ButtonLeftNormal" XPos="68" YPos="20" Width="12" Height="16" />
   <Image Name="ButtonMiddleNormal" XPos="82" YPos="20" Width="12" Height="16" />


Photoshop screenie, as you can see the selection info states the XY coordinates and the width and height. But when using these some white still shows up. In photoshop, the first pixel is X1;Y1.



As rendered in ogre with the white smudging:



Please keep in mind I don't care about anything but the leftedge, rightedge, bottomleft, bottomright and bottomedge window parts at this moment. I know why the top is white, cause of the titlebar mappings, but that's not my concern. My concern now is why my coordinates seem to be wrong, and why i have to add 2 at one time and 1 another to get the white to disappear.
Also, some pieces sometimes appear stretched, how is that possible? I looked in the .looknfeel file but the imageset seems to be the only place to specify any real dimensions.

[CrazyEddie]

Thanks, I did not have a chance to look at this yet, but will so and get back to you soon

CE.

[CrazyEddie]

Hi,

I've tried to write this response in such a way to teach the correct procedure and explain some of what is going on in the imageset and looknfeel (skin) files, as opposed to "just fixing it" which is what I sometimes do. I think this might be a more beneficial approach in this case (teach a man to fish and all that...)

Anyway. some of this may be "obvious" to you. I'm not attempting to be condescending; if it comes across in that way then you'll need to excuse me

The intention of the imageset is to define regions of a larger image that can be referred to later by a given name; it's not particularly the intention of the imageset to state where or how large the named images should be drawn (for the sake of this discussion image offsets are being ignored).

From an imagery standpoint, within the looknfeel, three things happen; areas are defined as (generally) portions of the window being skinned, the name of an image to be drawn for an area is given, and formatting/alignment options are given which tell the system how the image should be drawn within the area - for each axis an option can be given stating if the image should it be placed as-is at an edge of the defined area, or if the image should be stretched to fill the defined area or if the image should be tiled across the area.

There is also a predefined 'frame' definition for the skin files that can take up to nine images that will be drawn using predefined formatting options (corners are drawn as-is, edges are stretched in between the corner pieces and the background is stretched or tiled to fill the area between the edges).

An unmodified TaharezLook.looknfeel kind of uses a mish-mash of these approaches for the FrameWindow.

Now, due to the way imagery is filtered by the 3D hardware, when stretching images an additional pixel is required either end of the imagery in the stretched dimension - if this is not provided and allowed for in the imageset definitions of the images, then "whatever happens to be there" will be used.

Finally, to try and make sense of some of this information in this case

In the imageset snippet you gave, (at least) some parts that are normally stretched - the edges - do not allow the required pixel for the filtering to occur, hence "whatever is there" is used; the white background. For these parts that will be stretched you need to move the location by +1 and reduce the dimesion by -2. So for the WindowLeftEdge, for example, you have this:

Code: Select all

<Image Name="WindowLeftEdge" XPos="4" YPos="38" Width="10" Height="72" />

This is exactly the size of the image and will not work if the image gets stretched by the skin definition, to allow for this, the image definition should be:

Code: Select all

<Image Name="WindowLeftEdge" XPos="4" YPos="39" Width="10" Height="70" />

Note that only the y axis is adjusted since normally the left/right window edges are not stretched in the x; only the y (and the opposite is true for the top/bottom edges).

Hope this is kind of useful.

CE.

[Treize]

Wow, and you said all that without flinching?

No, seriously though, don't you think that's even a bit odd behaviour?

I mean thanks for explaining i understand perfectly now, but i can't say i feel like a fool for not realising that, because well.. noone would! It's just totally unintuitive behaviour.

If i specify those coordinates, and this width and height, i don't expect cegui to snatch up some surrounding pixels. That's just madness. I now see why you're called crazy eddie, heh, jk.

But to give you an idea, what i as unsuspecting user/artist (and i'm normally not, just in this case, i'm actually a programmer by profession) would expect is that if i specify that it should stretch in the way you described, it doesn't just snatch a few pixels outside of the region specified by me in the xml, but it'll just take these pixels from inside the region, or just repeat the border pixels and then the artist making those images should just make sure that he's keeping that in mind. But you have to understand that it is impossible for me to wrap my head around the fact that cegui would use pixels OUTSIDE of the regions specified by me in the xml.

I guess it's a matter of opinion but that's how i see it.
I'm going to try and finish the skin with this new knowledge in mind, but i guess i'll have to fiddle with the looknfeel then, which i wanted to avoid.

Thanks for explaining. And if this was documented somewhere already I now officially owe you a beer.

[CrazyEddie]

This is, as I said in my other reply:

...due to the way imagery is filtered by the 3D hardware...

CEGUI does not grab those other pixels to use - it's the nature of the way the 3D hardware works. Perhaps you should take your issues to the guys at NVIDIA and AMD?

CE.