CEImagesetEditor - Now official tool!

[drumicube]

Thanks for your help ScriptKid.
Your idea of hiding/showing CEGUI child windows for the 2 OpenGl surfaces seems to be to correct one, it helps me a lot !
I have also found another big rendering bug, obvisouly my rendering was wrong directly from scratch, but thanks to you, I have a better idea of how to achieve this now...

I will post an update version in few days:
So don't bother with this one, it's full of core bugs, and it was just to request help...

Thanks.

[scriptkid]

Okay i'm glad to hear this Just let me know if i can help you with anything else, such as testing or something.

[martignasse]

hy dremicub,

If you want my personnal opinion:
I would recommend you to post such nice comments after checking my code !
Even, if I'm quite ok with WxWidgets now, I'm really not confident at all when it comes to CEGUI, I need more experience on it !

funny, it was exactly the same when i decide to begin this imageset editor, plus the fact i never tried WxWidgets before...

and i can tel you, it's a good way to learn CEGUI internal

anyway, i have to look at you'r code, i want help and continu to see this appli growing.

keep up the good work

[LennyH]

This looks like some nifty and good work ^_^ Keep it up, I'll be interested in it...

[drumicube]

Ok, I have bad news !
I spent a long long time trying to get those 2 separate OpenGl windows rendered in only one application (one CEGUI::System and one CEGUI::Renderer as no more is allowed for 2 windows)
After hours and hours, I'm now thousand light years away from the editor code:
In fact I'm currenly customizing the OpenGLRenderer module itself, it helps a little by fixing the two different windows size switching for one rendering, but obviously it's not enough...
As you can see on the posted screenshot, I still have a problem with fonts !
Don't forget, depending on the targetted window, they are resized on the fly too...

One thing is sure for me now:
In the current state, CEGUI is not able to handle more than one window, a little patch is the renderer module is needed.
I'm still working on it, but if it's going to far, I will be force to wipe everything and start from scratch what i had in mind...

[drumicube]

And now, the good news !
If no font is choosen, using a customized OpenGLGUIRenderer, everything is working well !




As Lindquist was kind enough to help me, he pointed a possible problem, it seems to come code from CeguiSystem.cpp:

Code: Select all

/*************************************************************************
   Handler method for display size change notifications
*************************************************************************/
bool System::handleDisplaySizeChange(const EventArgs& e)
{
   // notify the imageset/font manager of the size change
   Size new_sz = getRenderer()->getSize();
   ImagesetManager::getSingleton().notifyScreenResolution(new_sz);
   FontManager::getSingleton().notifyScreenResolution(new_sz);

   // notify gui sheet / root if size change, event propagation will ensure everything else
   // gets updated as required.
   if (d_activeSheet)
   {
      WindowEventArgs args(0);
      d_activeSheet->onParentSized(args);
   }

   return true;
}


I suspect FontManager::getSingleton().notifyScreenResolution(new_sz) to be the reason of the trouble...
But honestly, I'm far from what I anderstand a little, I mean the editor...
Any help is welcome !
Thanks.

EDIT: More news about the font error.
Whatever the loaded layout and loaded font, It's exactly the same display error for the ImageSet window.
As you can see above, it seems to dump the character set !
Someone as an idea of the possible reason ?

[drumicube]

I have just updated, the binaries and sources:

Windows Binaries: http://yoyo2k1.free.fr/cegui/CEImageSet ... naries.zip
Sources: http://yoyo2k1.free.fr/cegui/CEImageSet ... ources.zip


- The size of both renderers is now fixed, thanks to a little patch in the OpenGLRenderer.
- You can now save your Imageset without crash if the Layout window was using it.
- If it's needed, the layout is reloaded and updated when you save your imageset.
- If the loaded test layout is not using the opened ImageSet, a little warning is displayed.
- Mouse pointers fixed.

For the first time we can see the Layout beeing updated after the Imageset is saved by pressing the save icon

There's still a lot of problem in this version, mostly coming from the Dual Rendering:
I'm still fighting to death to make those 2 windows displayed together, and as you can see, it's still far from beeing fixed !
I must also admit, I'm spending most of my time on this problem, and I still don't even know if it can work with the current CEGUI API.

PS: To avoid your imageset rendering not to be corrupted, simply don't load a font.

Main ImageSet: TaherezLook.imageset
Font file: nothing
scheme file: TaharezLook.scheme
Layout file: Demo8.layout or Demo7Windows.layout

[Habba]

Windows Binaries: http://yoyo2k1.free.fr/cegui/CEImageSet ... naries.zip

The file is corrupted. Atleast I couldn't load it, even though I tried several times (with and without getright). And no way I'm touching the source-package (One has to be a rocket scientist to figure out the logic in building these packages..)

[drumicube]

Arf... You're right !
I didn't check them as usually there's no problem, but this time the file was less than 1Ko size !
Ok, I just uploaded them again, and checked: Everything should be ok now !
Sorry, for this !

Concerning the font bug:
I can inform you it's related to the FontGlyph buildings, when a trueType font is created or resized, a picture map of all needed character is created from it. It looks like there's a problem with this CEGUI code when more than one Window is rendered.
It makes sense as a character set of the loaded font is displayed instead of the ImageSet itself in the editor.

I'm trying to contact the author of this part to know if he could help me.

There's also an easy way to get rid of this bug:
put AutoScaled="false" in your .font files

this AutoScaled="false" is already set for all .font files in the binary package.

[drumicube]

Ok, I managed to avoid the font problem by adding a dirty hack:
I simply set by code the font Autoscaled to false before an ImageSet Rendering, I also reactivate it to it's initial state just before a Layout Rendering.
It's working fine, and you're now allowed to use Autoscaled=true again.

So it's now time for the big news:

The Dual window CEGUI Rendering is now working fine!

It took me a long time, it wasn't really easy, and this trick has also a cost:
The render function is really a dirty hack. I need to hide or show correct sheets, scale windows, change fonts attributes and all this is really needed before rendering.
On the other hand, all of them make senses in a single rendering context, there's no strange behaviour !

One word about the next CEGUI release:
I know you're planning a multi rendering system.
As far as I can tell (meaning not much) I think it will be easy to achieve.
The current API is clean enough to support it, but there's also a lot of chance for you to face the FontGlyph problem too!

COMING NEXT:

It's back to business now, I mean the editor itself !
I'm currently dividing the work in 4 parts:

• Cleaning the controls. (I mean the Layout mess in the left property panel)
• Improve the mouse selection in the ImageSet (I hate the autoselect from the List when the mouse enter a box, a click to update the list would be better)
• Checking all this under Linux.
• The most important part: Cleaning the code, and synch back to prepare SVN commits.

ONCE UPON A TIME FAR IN THE FUTURE

Ok this is just an idea, but as now all kind of possible CEGUI data is loaded by the ImageSetEditor, I'm really wondering if moving it from an ImageSet editor to a full skin editor is not such bad idea ?
Currently, the main document is an ImageSet, what about replacing this by a project document, which declare all the data needed for a full skin ?
We could then, slowly fill the editor with all the needed part to create or customize fonts, schemes, looknfeels etc...
I really think this is what everybody is waiting for: A full skin editor, and of course it should be delivered in only one tool, or it will be a total nightmare to work with !
Of course I'm not including Layout in this. It's not related to skinning itself, and the Layout Editor is doing this job fine !
Anyway, it's just ideas, I have far more urgent and basics things to complete first !

One last word regarding the CEGUI team:

Thanks for all your help on IRC, it really helps me a lot !
You rock guyz

[martignasse]

wow, you'r making good job

and you'r TODO list seem's fine.


did the link are updated with the last exe and soucre ?
(i even didn't take time to look at the other.... )

for the idea of a "total" skin editor, for sure it's a good one, and effectivly a natural continuation after the imageset part

anyway, keep up the good work

[drumicube]

Yes and No:
Yes, the source and binary packages are updated since the first release, but no they are not the latest !

I will surely update them again before the end of this week:
There's also two little things I have added to my TODO list, it's not really addons, and it's more going with the cleaning stuffs:

- Replace the save config system taken from the LayoutEditor, by a native WxFileConfig system.
- Ability to Build using the unicode Wxwidgets libraries for a true Unicode Editor.

So feel free to check, but it will be updated soon.
By the way, I love working on your tool.

[scriptkid]

Hi drumicube,

i have played around with the new binaries; it looks nice

The only thing which worries me (also happened in the original version) that it might take quite a long time to load an imageset. Especially the TaharezLook one. Mmm i didn't check, but i think it's because the call to Render() after each definition.

About unicode: i tried building your sources to unicode as well and found some problems. One was that if you use 'wxChar*', you should also use 'wxT' when setting a value. Besides that i don't think there were too many problems.

I didn't know about wxFileConfig. I had a quick glance and it looks good to me

Regarding an update to a complete skin editor, a new thread might be started with ideas? The cegui team already had a tool-discussion a while ago, but we didn't conclude anything yet. WxWidgets seems good because of its common functionality such as file dialogs, toolbars and a friendly look & feel. Using cegui itself would be a cool showcase, but difficult to setup a tool basis.

If wxWidgets would become the winner, i would like to have a kind or 'sharedLib' or something, with all common tool stuff. My idea would be to have a base View- and Document class based on the wx classes, which handle all communications with cegui. And a way of creating projects. That would already save a lot of redundant code. But those are just ideas...

[drumicube]

The long loading time for an imageset is coming from the ElasticBox cegui extension (it manages boxes in the ImageSet window)... I have played a little with them and I know the loading time can easily been reduced... I will have a look at it as soon as my TODO list is completed.

Unicode is working in my latest sources, as you explained, it was mostly done by using wxT().

Concerning wxFileConfig:
I decided to replace the old system for a lot of reasons:
It's WxWidgets native, there's far more methods available to handle config files, and most of all: Managing new groups or entries is as simple as myConfig->Read and myConfig->Write.
One little note: WxConfig is the default on WxWidgets but it rely on windows Registry to save configs for Win32 users, that's why I have choosen WxFileConfig, it's implemented for all platform and it always use a text file to save the config data.

Regarding the Update for a complete skin editor:
It's really to soon for me, and I have enough things to handle right now:
I'm still need to polish what I'm on !
So, it's surely not before 2007, which is not bad as CrazyEd will be back.

[Dalfy]

Regarding an update to a complete skin editor, a new thread might be started with ideas? The cegui team already had a tool-discussion a while ago, but we didn't conclude anything yet. WxWidgets seems good because of its common functionality such as file dialogs, toolbars and a friendly look & feel. Using cegui itself would be a cool showcase, but difficult to setup a tool basis.

If wxWidgets would become the winner, i would like to have a kind or 'sharedLib' or something, with all common tool stuff. My idea would be to have a base View- and Document class based on the wx classes, which handle all communications with cegui. And a way of creating projects. That would already save a lot of redundant code. But those are just ideas...

I think we can go for a sharedLib with a common basis for all tools even using the same build process for both or combine all tool in a single bundle based on a common lib. I think that wxWidget is the tool to go in order to bring easly tools to the communauty. But we must try to go for a CEGUI based tool framework for several good reason :

CEGUI is used in game and it's good to be able to add editing facilities in game for nowdays game. This framework can speedup the development of such tools. Creating such framework will make us (the dev team) use deeper CEGUI itself and is a good way to test CEGUI itself. This framework can be a good knowledge base for any CEGUI user.