CEGUI on OGRE 2.1

[lucebac]

Updating PRs does only work as long as they are open - once they get merged you have to create a new one.

[Ident]

If your previous PR has been merged fully then you can simply make a new PR on the same repo of yours.

[Jayray]

OK, thanks for your answers!

The changes I had to make to have the GUI displayed with D3D11 included setting the TU_DYNAMIC flag on the textures instead of the TU_DEFAULT flag (TU_DEFAULT = TU_AUTOMIPMAP | TU_STATIC_WRITE_ONLY).
The cause of this change is likely to be a bug in the D3D11 render system in OGRE 2.1 (to be confirmed). Anyway, this makes me wonder: should the TU_DEFAULT flag be kept for textures if possible, or would the TU_DYNAMIC flag better?

From what I have understood, the TU_STATIC flag (included in the TU_DEFAULT flag) has better performances for textures that are not updated often but is slower to update a texture.
So I guess the questions are:
- In CEGUI, are most of the textures updated often or rarely?
- Is it better to have a higher update time but better performances when the texture is not updated, or the contrary?

The details of the impact of setting the dynamic flag can be found in this post.

PS: as for the previous PR, these changes are between macros and will only affect CEGUI on OGRE 2.1.

[Ident]

The textures are never changed after resource setup normally

[Jayray]

OK, so this means that the static flag must be kept and that the issue in the D3D11 render system must be fixed in Ogre 2.1.
Thanks for your help!

[Ident]

Just to reaffirm: By updating you meant changing the texture itself (uploading a subset of texels or an entirely new image as texture) and not the usage, as in texture-binding

[Jayray]

Yes, this is what I meant

[Ident]

Yea that is very static

[Jayray]

I managed to fix the issue, it was indeed a bug in the Ogre D3D11 render system \o/
I have made a new pull request here: https://bitbucket.org/cegui/cegui/pull-request/156/ogre-renderer-updated-to-be-compatible/diff

Thanks for your help!

[Ident]

I merged it without testing. It looked fine on first glance and I trust that you tested it sufficiently.

[Jayray]

Thanks!
Yes, I have tested it
I just did not try to compile it against a previous Ogre version, but I have double-checked that all my changes only affect the code inside the macros dedicated to Ogre 2.1.

I will try to report these changes in the default branch when I can, but it may take some time as I do not have a project working with the default branch, and I have seen that the Ogre renderer has changed a lot since the 0.8 branch.

[123iamking]

It's been 2 years and Ogre 2.1 has changed a lot CEGUI still not officially support Ogre 2.1. So the reason because CEGUI only support the official Ogre version or CEGUI may never support Ogre 2.1 (for break ABI API reason). And if it's the break ABI API reason, Is it safe that I manually tweak it to eliminate build error and use it (I mean even the creator of CEGUI afraid of it, presumably ...) . I don't mean to underestimate anyone's effort, I just ask this out of curiosity
Thanks

[Jayray]

Hi,

It's been a long time since I have not developped on OGRE / CEGUI (2 years approximately... ), but I think the ABI / API break can be avoided by using the CEGUI_USE_OGRE_HLMS define, like I have done in my pull request (this one).
IMHO, it is safe to manually tweak CEGUI to make it build with OGRE 2.1 if all your code is between #ifdef CEGUI_USE_OGRE_HLMS.

[123iamking]

I see that Kohedlo is trying to fix for CEGUI to work with DirectX in Ogre 2.1. Hope soon CEGUI can be used easily with Ogre 2.1

[123iamking]

I don't know but do you think it would be a good idea to have a working branch for Ogre 2.1, just like MyGUI.