CEGUI (Crazy Eddie's GUI) Forums

Hello all

I have been hacking a certain video game, hooking it's DirectX device, modifying ingame memory, hooking ingame functions, etc.
Until now I have been drawing pure text to the screen as debug output, however, the project has gotten to the point where I could really use an ingame GUI. The game in question uses DirectX 8.1, so imagine my excitement when I saw CEGUI 0.6.2 still supports DirectX 8.1
I've looked at the example code and tut's, and it seems CEGUI is perfect for my project. I've downloaded the 0.6.2 SDK, and immediately tried integrating CEGUI in my project.
However, when trying to compile, I get linker errors, and a quick look in the lib directory showed me why. Unfortunately, it seems DirectX81GUIRenderer.lib and DirectX81GUIRenderer_d.lib are missing

Is there any way some very nice user could upload these two for me?
Thanks in advance

EDIT: Ooh, and I just saw the DLL's are missing too, so it'd be perfect if anyone had these for me
EDIT2: I'm using MSVC++ 2003 btw

EDIT3: Well, I've gotten it to compile using the DirectX81GUIRenderer from CEGUI 5.0b, but it won't run at all..
The error I'm getting is:

Entry Point Not Found: The procedure entry point ??0Exception@CEGUI@@QAE@ABVString@1@@Z could not be located in the dynamic link library CEGUIBase.dll

Some help would really be appreciated

Hi,

Why not just compile CEGUI - and therefore the D3D 8.1 renderer yourself? It would save all this messing about Just grab the source and 0.6.x dependencies, set the options in the config.lua file you want, run the 2003 version batch file to generate the solution and hit build in MSVC++.

Failing this, I know there are some people using D3D 8.1 with CEGUI - pretty much for the same purposes - so perhaps you'll get lucky

CE.

CrazyEddie wrote:Hi,

Why not just compile CEGUI - and therefore the D3D 8.1 renderer yourself? It would save all this messing about Just grab the source and 0.6.x dependencies, set the options in the config.lua file you want, run the 2003 version batch file to generate the solution and hit build in MSVC++.

Failing this, I know there are some people using D3D 8.1 with CEGUI - pretty much for the same purposes - so perhaps you'll get lucky

CE.

I actually tried that first
I had to scout the web for a lot of header files, and eventually gave up because I could not find the dependencies.
I did not know about setting the options in config.lua, so that explains to me why I could not find it in the default solution

I tried again today with a fresh mind, and it worked The renderer compiled, and the game would load without any crashes. I've combined some stuff from the VC7.1 SDK because the main dish (CEGUIBase, etc) would not compile.

The main problem I have now is that the render command seems to fuck up transparancy in some way... I'm not exactly sure how to describe it... The problem seems to lie in a 2d drawing procedure..
It seems like stuff that should be deleted from screen, does not dissapear or something, I dunno.

If a picture says more than a thousand words, a video says more than anything..
I've uploaded a video of what happens here.
The menu looks all botched up, it should have a completely different background there. When I select some item, the previous menu won't dissappear, the green flickering, etc..
In-game the sky does not get drawn, instead whatever was on the screen previously gets drawn. This is best visible from 1:08.

UPDATE: I updated something which should fix things (call CEGUI before endscene), but it does not have much effect.
Here's the most up to date video of what happens

With regards to building the rest of the CEGUI package, the required prebuilt dependencies package is available from the same place as the SDK. i.e. here: http://www.cegui.org.uk/wiki/index.php/ ... oads_0.6.2

With regards to the issues, it is likely a state save/restoration issue. With the exception of OpenGL, [i]none of the CEGUI renderers will maintain (i.e save and restore) the previous render states during the call to System::renderGUI(). This means that if you want or need those states preserved, prior to calling the System::renderGUI funtion you need to save the D3D state into a state block, and then restore from that state block once the renderGUI call has been made. If there are issues of rendering CEGUI itself, then these are likely states that the CEGUI renderer assume to be at the default value but are not (due to the game having set them otherwise), in these instances, you need to identify those states and reset them to what CEGUI expects (do this after the state block save, but before the renderGUI call).

You may perhaps wonder why we rely on states being at 'default' values? Well the answer there is that otherwise we would have to set every possible render state setting every frame, which is frankly ridiculous - so we opted to set the essential states required for CEGUI rendering and to reset some of the other common states, but others are left the the user of CEGUI to deal with.

HTH

CE.

First of all, thanks a lot for your help! This project is really fun to do, and each time I get one step further. Thanks for your time and patience

I've tried capturing the known renderstates and restoring them afterwards.. The solution I found does indeed result in the game drawing properly again.
However, when I continued the tutorials and tried to draw the hello world example, nothing appears to be drawn by CEGUI.

The way I capture the games renderstate before calling CEGUI and restoring them afterwards atm is this:

Does this capture to much somehow? or could the fault be elsewhere?

Also, the way I am hooking into the game is by placing my own proxy d3d8.dll in the game folder. My dll requires the CEGUI dll's, and the renderer in turn requires d3d8.dll again, right? Could it be loading my proxy dll again?

Thirdly, this may be a n00b question, but would it not be possible to create a second d3ddevice for CEGUI, which draws to a texture or sprite or something which I can draw in the game?

The capture code looks fine to me.

There are many reasons why CEGUI may not be showing, although it's most likely - again - an issue of states. As I mentioned, CEGUI kind of assumes it is starting from a known state (that being the default state), however the issue you have when hooking an existing app is that you have a totally unknown state. What this means is that there is very likely to be a render state that is being set by the host game, which needs to be reset to some other value before rendering the CEGUI content. As mentioned, it's not feasible for us to reset every state every frame

You can see in DirectX81Renderer::initPerFrameStates the states we are already setting, which means the 'problem state' is not one of those. Of course it could be challenging finding the state that is causing the issue - ideally you would find a way of identifying all states that have been set and act accordingly.

Another option you have is this:
1) When D3D first starts up (states at default), set the CEGUI states from initPerFrameStates, and record a state block.
2) Rewrite initPerFrameStates so instead of setting states, it applies the state block recorded above.
3) Do everything else the same as now.
4) ????
5 Profit!

Also, the way I am hooking into the game is by placing my own proxy d3d8.dll in the game folder. My dll requires the CEGUI dll's, and the renderer in turn requires d3d8.dll again, right? Could it be loading my proxy dll again?

I think Win32 see's that the DLL is already loaded for the process and will not load it again - so it should be fine. However, this being Win32, you never can tell Seriously though, I think if you had that issue the app would hang or crash or something.

Thirdly, this may be a n00b question, but would it not be possible to create a second d3ddevice for CEGUI, which draws to a texture or sprite or something which I can draw in the game?

I'm not an expert on D3D, but I don't think so, no. I think this because mostly games and such will be looking for exclusive access to the hardware and this precludes you from using two devices in the way you want. I think if you had two devices, you'd need a device reset in order to switch between them

CE.

Another option you have is this:
1) When D3D first starts up (states at default), set the CEGUI states from initPerFrameStates, and record a state block.
2) Rewrite initPerFrameStates so instead of setting states, it applies the state block recorded above.
3) Do everything else the same as now.
4) ????
5 Profit!

Hmmm That seemed like a very good solution, however, when I tried it, it seemed to have no effect. Nothing gets rendered.
I set the render states the dx8 renderer normally sets, and captured the state of DirectX all before the first SetRenderState called by the game.
On each render, I capture the current state, apply the other state captured before, call CEGUI's render function and restore the state again.
Yet again, nothing is drawn

Hmmm, given the situation, that was my 'best guess' at the time. Are there any errors in the CEGUI log at all? As you might imagine it's extremely hard to debug these types of issue from afar

CE.

Yes, I can certainly imagine it being hard debugging with this little information, and I am already really thankful for your time. I wish my project was a stand-alone app since that would make debugging it easier, but then again that would defeat the point of me using CEGUI
I could not spot any errors in the CEGUI.log,
I've posted it here at Pastebin just in case.

The code I am using at the moment (almost exactly copied and pasted from your tut to minimize the chance of errors there..)
This should always draw something when it's executed once, right?

Info for people searching / those who might think this was not followed up on...

This issue was fixed on IRC, and basically the viewport size was not being detected properly (or the vp was not set at renderer creation time) and so required informing the system of the display size explicitly via the DirectX81Renderer::setDisplaySize function.

CE.

CrazyEddie wrote:Info for people searching / those who might think this was not followed up on...

This issue was fixed on IRC, and basically the viewport size was not being detected properly (or the vp was not set at renderer creation time) and so required informing the system of the display size explicitly via the DirectX81Renderer::setDisplaySize function.

CE.

Yes, this is the case. I still can not thank you enough for your help Thanks!

And if you had the same problem as I had, you will probably also notice the mouse cursor not moving anywhere. If this is the case, use the CEGUI::MouseCursor::getSingleton().setConstraintArea function to inform CEGUI where the mouse is allowed to go.