CEGUI on OGRE 2.1

[Jayray]

Hi all,

I am currently trying to port my project to OGRE 2.1, even though this version is still a work in progress.
As there were a lot of important changes between OGRE 2.0 and OGRE 2.1, the CEGUI OGRE renderer need some adjustments to work on OGRE 2.1.

For now, I have successfully ported CEGUI 0.8.4 to OGRE 2.1 on the OpenGL3+ renderer with these changes:
- Some OGRE classes are now in a "v1" namespace => renaming needed in CEGUI
- All the functions that were used to pass the texture / rendering / blend options to the render system do not exist any longer => I used the new HLMS blocks to pass these options
- The scissors test has been moved to another class => changes required to use it
- The GL3+ shaders were not "allowed" in the CEGUI OGRE renderer => I allowed them for OGRE 2.1.

However, atm CEGUI is only working on the OpenGL3+ renderer in OGRE 2.1. I still have to update the shaders for them to be compatible with the D3D11 renderer.

Can I upload the source codes of the updated CEGUI OGRE renderer anywhere? Or should I make a pull request?
I have put all my changes between #ifdef macros, but I did not test it on a previous OGRE version, and I do not know if my code is "good" enough to be merged in the 0.8 branch...

But as this porting has taken me a certain amount of time (and headaches ), I would be glad if other persons wanting to use CEGUI on OGRE 2.1 could benefit from my work

PS: I have seen that there has been a lot of changes lately in the CEGUI OGRE renderer in the default branch, so a porting work will be needed again to make the default branch compatible with OGRE 2.1.

[lucebac]

CEGUI default branch is already compatible to OGRE 2. Henri Hyyryläinen did a great job on that already.
Making CEGUI 0.8.4 compatible to OGRE 2 in the official repo is not possible, though. It definitely breaks ABI and, if I remember correctly, also API.

I do not underestimate your work, I just wanted you to show the current state of development.

[Ident]

Maybe we can make an exception as long as all changes are done in the OgreRenderer. It would suck to not be able to support 2.0 and 2.1 in 0.8.X at all.

But lucebac is right: the default branch is where it already works, and most work should probably go there right now, in either case.

[Jayray]

I had seen the latest developments before starting my work. The default branch is compatible with OGRE 2.0 but unfortunately not with OGRE 2.1
As I said in my first post, there have been important changes between OGRE 2.0 and OGRE 2.1, and the OGRE renderer from the default branch still uses the functions that have been removed from OGRE 2.1.

I agree that the new work should go into the default branch, but:
- I need OGRE 2.1 for the performances upgrade and the new features.
- If possible, I do not want to port my project to a new version of CEGUI, especially because the 0.8.4 suits me well and there is no official release on the default branch yet.

Also, these changes are limited to the OGRE renderer and should not break the compatibility with previous OGRE versions since the changes are between #ifdef macros (based on the version of OGRE).

EDIT: I will try to make it work with D3D11 as well and I will make a pull request on the 0.8 branch. Then it is up to you to decide whether you will merge it into the 0.8 branch or not

[Ident]

We will discuss this internally in the dev team. I am in favour of adding it, as long as it is API compatible. ABI breaks for the Renderers should be acceptable in crucial cases, such as in cases where support for the Renderer is otherwise impossible - which is the case here.

[Ident]

Kulik said "but we have to keep API and ABI compat for old Ogres"
We would be very glad about a pull request with your work (be sure to target v0-8 not default!). If you make one I can look at it and tell you if it is ABI compatible or what can be done to make it so or what we can do to work around it etc.

If it seriously breaks abi we can make an Ogre2_1Renderer out of your work and add it to 0.8.x .

[Jayray]

Here it is: https://bitbucket.org/cegui/cegui/pull-request/150/changes-to-make-cegui-08-compatible-with/diff

I used the CEGUI_USE_OGRE_HLMS define to avoid breaking the ABI, I hope it will be okay.

I will be waiting for your instructions about what to do next
Meanwhile, I will try to make it also work with the D3D11 Ogre rendersystem.

Also, please note that all the code using the CEGUI_USE_OGRE_COMPOSITOR2 is not my work, I have taken it from an old commit in the default branch

[Ident]

Lucebac made some excellent replies.

In general: Can you explain how "CEGUI_USE_OGRE_HLMS" is supposed to work? Is it supposed to be False for newer versions of Ogre?

[Jayray]

CEGUI_USE_OGRE_HLMS means that the HLMS (High Level Material System IIRC) component of Ogre is present and shall be used instead of the "old" functions.
For example, to set the blending options in previous Ogre versions (< 2.1), the function Ogre::RenderSystem::_setSceneBlending was used.
In Ogre 2.1, this function does not exist any longer. To set the blending options on Ogre 2.1, a HLMS blend block must be used.

CEGUI_USE_OGRE_HLMS will be automatically defined on Ogre versions >= 2.1 using this code in Renderer.h:

Code: Select all

#if (CEGUI_OGRE_VERSION >= ((2 << 16) | (1 << 8) | 0))
// The HLMS has to be used since fixed pipeline is disabled
#define CEGUI_USE_OGRE_HLMS
#include <OgreRenderOperation.h>
#include <OgreHlmsSamplerblock.h>
#endif


That means that, if I have made no mistake, these changes should be transparent: the pre-processor macros depending on the Ogre version will be automatically set when building, and the Ogre renderer should build on all Ogre versions without any adjustment.


By the way, this is the first time I am doing a pull request. What is the way to change it? Should I make another commit with the new changes? Will the new commit automatically be added to the pull request, I will I need to make a new pull request?

[Ident]

Yea make a new commit, push it on your repo, then reload the page of the PR and it will ask you to update it (1 click) and you are done. It is a pretty fast process if you have done it once, knowing whats going on.

I am not sure if we guarantee ABI compatibility if the macro breaks ABI compatibility in case it is activated/deactivated.

We suggest making Ogre2Renderer and going with that. You can entirely change it. Any files from OgreRenderer that dont need changes should be reused 1:1.
If you copy your OgreRenderer files to the new folder you can then undo the changes on the original OgreRenderer files in a new commit and it is fine. In the DIFF (only in the PR) you will clearly see if any of the original OgreRenderer files have been altered.

[Kulik]

I think using the macro is fine. We never supported Ogre 2.1 anyway so if we "break" ABI for Ogre 2.1 it's not really a break.

[Jayray]

OK, good news, this will be a lost faster!
I will make a new commit to take the other comments into account as soon as I have some time.

Thanks for your help!

[Jayray]

Thanks for merging my pull request

As soon as I get CEGUI working with the OGRE 2.1 D3D11 rendersystem, I will make another pull request.
But it may take several weeks as this is not my current priority (the OpenGL 3+ rendersystem is great for now )

[Ident]

Thanks for your PR again. Sure, feel free to make another PR any time

[Jayray]

Hi!

I finally managed to have CEGUI working on OGRE 2.1 with the D3D11 render system
There are still some details to settle before I can make a pull request (cf. this post), but I can already prepare the pull request on my local repo.

But before this, I would like to know which solution would be best: make a new pull request or update the first one? (I do not know if updating is possible for a merged PR, I am still not very experienced in creating PRs )

Thanks!