CEED on C++

[niello]

Hi.

I migrated my engine to CEGUI default branch. Prebuilt CEED snapshot 11 has problems with it. It doesn't support fonts format v4 and saves strange (v0-8?) properties to widgets so that the game crashes with the 'unknown property' exception.
Building CEED for Windows turned out to be so much pain that I gave up.
Also the layout editor itself requires some improvements to become really convenient (or I just use it wrong).
There is a v0-8-cpp branch but all files are just empty autogenerated stubs and the last commit was in 2017.

The question is: will it be useful if I will port CEED to Qt 5 C++ and the latest CEGUI data? Doesn't someone do the same thing right now?
I can't promise the exact matching but can do something that is better than nothing. I planned to implement Qt-based game editor anyway.

[Ident]

I migrated my engine to CEGUI default branch. Prebuilt CEED snapshot 11 has problems with it. It doesn't support fonts format v4 and saves strange (v0-8?) properties to widgets so that the game crashes with the 'unknown property' exception.
Building CEED for Windows turned out to be so much pain that I gave up.
Also the layout editor itself requires some improvements to become really convenient (or I just use it wrong).

That sucks, unfortunately I have no idea about the issues you mentioned but it is likely that there are differences between CEED based on CEGUI v0-8 as compared to CEED based on CEGUI default branch.

There is a v0-8-cpp branch but all files are just empty autogenerated stubs and the last commit was in 2017.

The question is: will it be useful if I will port CEED to Qt 5 C++ and the latest CEGUI data? Doesn't someone do the same thing right now?
I can't promise the exact matching but can do something that is better than nothing. I planned to implement Qt-based game editor anyway.

Porting CEED's QT core to C++ would be very valuable and currently no one is doing it. The v0-8-cpp branch of CEED is there for this reason but we got stuck on it very early, shame on us (especially me) and it is not being worked on atm.

I have some files lying around for that branch that were WIP but I do not fully understand what I was doing there. I think the next steps were to rename existing python files to header/cpp files and start converting code. The sooner we can get anything to build and run in C++ the better, then the rest can be migrated on top of that step by step.

CEED default branch should be ignored for now, only v0-8 is important and if you look at the history you will see that default became v0-8 and then default only got merges from v0-8, nothing particular happened on default branch.

So yes v0-8-cpp is the way to go. And it will make the whole process of compiling CEED much much much less annoying. There is some magic involved in PyCegui based CEED currently that only Kulik knows about.

If you are willing to progress with v0-8-cpp I will support you as much as you can. Keep in mind that this is a big task.

[niello]

Then I will try to accomplish it) This will be an interesting experience.
I started working on editor a couple of days ago locally, and I personally prefer git over hg, but it doesn't make the code itself better or worse. As soon as I have something roughly working I'll share the repo with you and we'll see what to do with it. I'm working in a Qt Creator 4.8.2 (Qt 5.12) to minimize developer setup required. Hope it works on other OS'es as good as it does on Windows.
Any help will be greatly appreciated, and twice as much will be the help with CMake setup, testing on non-Windows platforms and design/code reviewing.
If there is any developer chat active I can join it for runtime discussions, forum is a slow place for this.

[niello]

Just for information. I started porting CEED here:
https://github.com/niello/ceed-cpp

There is still much work to do. I will post here when it's done.

[Ident]

Great, I hope this will be a success

[niello]

CEED port is almost usable now. I wait for a new version of a QtnProperty library to fix some major problems with properties and add multiproperty support for multiselection.
I've ported a framework, an imageset editor and a layout editor.
I started to port looknfeel and animation editors but they are experimental and I have no need in them in a current stage, so it probably will take much longer. If someone wants to get them working, please do that and send me a pull request.
Instead of porting experimental editors I try to improve layout editor with anchors like in Unity3D and some shortcut layout functions. Not sure how much time it will take though.
I delayed porting of metaimageset because I don't use it and I don't know if anyone does. Probably the old prebuilt CEED is enough for now.
I decided not to port tests and compatibility layers at all. Old formats can be edited with an old editor. I lack knowledge of them and I doubt that someone needs support of them in a new editor.

I plan to add prebuilt CEGUI at least for Windows x86 as a downloadable zip to make developer setup as easy and fast as possible.

The sooner we can get anything to build and run in C++ the better, then the rest can be migrated on top of that step by step.

I think the current state of the port matches this 'anything' If you or someone you know want to contribute to the port then the time has come.

[Ident]

It would be nice if we could integrate this into the bitbucket hg repo for C++ CEED, so it is part of the official CEGUI repositories
https://bitbucket.org/cegui/ceed/src/v0-8-cpp/
What do you think? Would you be okay with this? When would be a good time to do that?

[niello]

I am much more comfortable with git when developing actively. When property problems are fixed and major functions are tested we can clone the repo to CEGUI bitbucket. If git is available there I would recommend using it.

There is another big problem with Qt and OpenGL. As Florian reported, VAOs are not shareable and therefore we can't render CEGUI to Qt widgets. Can we disable VAO for CEED either with runtime option on renderer creation or with a #define?

[Ident]

There is another big problem with Qt and OpenGL. As Florian reported, VAOs are not shareable and therefore we can't render CEGUI to Qt widgets. Can we disable VAO for CEED either with runtime option on renderer creation or with a #define?

Shareable between what and what? Do you mean OpenGL Contexts?
Can you workaround this by doing RTT and sharing the texture instead?

[niello]

Yes, I mean OpenGL contexts. I thought about that but didn't succeed in switching context in the middle of Qt widget paint(). I will try it again but if for no success then I see no other way than disabling VAO for CEED.

[niello]

Thanks for an idea. I just didn't put enough effort into this direction due to the lack of OpenGL knowledge. Now OpenGL 3 renderer works in CEED. As a side effect there are screenshots available by pressing 'Pause' key when focused on a layout editor (PrintScreen is oftenly used by smart third-party screenshot tools). Produces an unscaled screenshot of the current CEGUI context no matter what transform the view has and what Qt items are in a scene. Must be handy when you want to share or discuss your work etc etc.

[Ident]

Does that mean you got it to work?

[niello]

Yes, as I wrote, OpenGL 3 CEGUI renderer now works in CEED

[Ident]

Nice! Good job

[niello]

I just merged my latest work to the master. It includes OpenGL 3 rendering, layout editor fixes making it functional, unity-like anchors and some minor improvements like tooltips over widgets and automatic expansion of the root widget to the whole context area.

Known issues:
1.
open layout
select some anchor
close layout and open it again
select anchor and drag it
rendering of numeric % values attached to the selected anchor breaks

If someone wants to investigate these issues, you are welcome.