CEGUI (Crazy Eddie's GUI) Forums

Hi altogether,

I'm developing an overlay application for TS3 (http://ts3overlay.r-dev.de).
Basically the UI consists on two different windows which are shown all the time: The one where you can see relevant content of the TS3 server (channels, users, ...) and a small icon. There are also two windows, that are not always shown: A context menu, and a notification, that the overlay now accepts mouse input.

The overlay so far works in most games that use D3D8 or higher or OpenGL (so it's Windows only)
However, with one game, I ran into a strange problem when injecting the overlay.
The small logo is visible on the screen, however the window isn't.
The context menu itself also isn't showing.
If I move the mouse where I know the window should be, the cursor changes to the resize-cursor, so I know, the window IS there, it's just not being painted.

I experienced similar things in the past and I always messed up some rendering states, but in these cases I simply saw nothing. This case now is somewhat different.

This is the initialization of the logo, that is visible:

as well as the hint window:


While these two windows aren't visible:

and


The mentioned game uses D3D9:


The CEGUI version is basically on 0.7.5 but is slightly modified to link all different renderer modules into one single DLL (important if you try to inject the DLL into a game that uses a CEGUI DLL of another version), a D3D8 Renderer, some speed improvements in the Tree widget, as well as the fix for ticket #445.

Before rendering, I try to put the D3D9Device into a reasonable state, and did an output of the rendering states after modifying those, just in case it helps (which I doubt) ^^


I already checked with PixWin, if they did some weird stuff, but couldn't find anything.
Does anyone have some ideas?

Strange. To state the bleeding obvious - if one window shows up, they all should!

If you position the absent windows so that they overlap where the logo shows, do they then - at least a part of them - show up?

CE.

Nope, already tried that. If I swap the positions of the small icon and the main widget, the effect stays the same: The icon is shown, while the main widget isn't.

I also tried rendering right before the call to ID3D9Device::EndScene(), as well as right before ID3D9Device::Present(), but this doesn't make any difference.
Just thinking loudly:
Could this be a depth issue? D3DRS_ZENABLE is set to FALSE, but I'm not sure whether this also applies to the viewport's Z-range.
Probably the different windows are rendered with different Z values, while the main window is outside the viewport's range. Need to check how the game set's its viewport...

Probably the different windows are rendered with different Z values, while the main window is outside the viewport's range.

Hmmm. We used to do that, but not any more. By default all window rendering has the same Z value, which is 0.

CE.

In this case, I'm totally out of ideas. Do you have an idea how to debug such an issue?

I could imagine that other users also could run into the same problem sooner or later, so would it make sense to submit a patch for "enhanced device state restoration", at least for the stuff I do have now?

CrazyEddie wrote:If you position the absent windows so that they overlap where the logo shows, do they then - at least a part of them - show up?

MarkR wrote:Nope, already tried that. If I swap the positions of the small icon and the main widget, the effect stays the same: The icon is shown, while the main widget isn't.

There is a huge difference between the terms overlap and swap. Did you mean to say you tried both, or did you not actually try overlapping the windows? It is important to clarify since there may be some kind of clipping taking place which only affects the area outside the logo; I presume this is what CE was getting at.

Yeah, you could also try attaching another window to the logo window, changing the size of the logo window, not drawing the logo window to see if another window appears.

Also, for the frame window you create, you could disable the AutoRenderingSurface by setting it to False and seeing if that changes anything

CE.

Jamarr wrote:There is a huge difference between the terms overlap and swap.

Ah, sorry, didn't make it clear enough.
What I did was swapping the initial positions of the two windows (normally the main window is in the top left corner, while the small icon is in the bottom left corner) as well as moving around both windows (including dragging the window over the icon and vice versa).
I did however not yet try to initialize them both at the same position. I'll check that.

CrazyEddie wrote:Yeah, you could also try attaching another window to the logo window, changing the size of the logo window, not drawing the logo window to see if another window appears.
Also, for the frame window you create, you could disable the AutoRenderingSurface by setting it to False and seeing if that changes anything.

Thanks for all those hints, I'll try that tonight.

It took a while, but I finally had the time to try these things.
setUsingAutoRenderingSurface(false) did the trick.

I would mark the thread as solved, but there are still questions remaining:
I checked the documentation and found, that disabling the AutoRenderingSurface might lead to a performance penalty (as the cache is disabled). Is that right?
If it doesn't affect performance, I'll disable the AutoRenderingSurface for any game, but I don't want to do that if this leads to (notifiable) performance loss.
In this case, is there any possibility to find out whether disabling the AutoRenderingSurface is required? Or would it be more feasable to generally create an own RenderingSurface and set this one to the FrameWindow?

AutoRenderingSurface basically provides a texture cache for Windows. It speeds up rendering in cases where the contents don't change (you only render a texture mapped quad instead of rendering all characters and widgets inside). I think it's definitely safe to disable and you shouldn't have major issues.

Great

Thanks for all your help