This project is read-only.

without xna, Nuclex UI or cegui#

Aug 8, 2011 at 3:58 PM

Hi, I ve done some custom UI with nuclex UI , drag n drop controls with icons (with custom renderers) 

Now i would like to (eventually) port the code from my xna project to a sharpdx project (if you dont'know sharpdx, consider it with slimdx, it would be the same challenge)

Do you recommend starting from nuclex UI or from the old cegui# on sourceforge ? latest activity over there being "merge cygon branch into trunk" 3 years ago ;)


Aug 9, 2011 at 9:51 AM

Difficult to say.

Porting the CeGui# renderer is probably a bit less work since it already contains the vertex batching and texture cache stuff that you'd have to write yourself if you ported Nuclex.UI. When I last worked on that branch, CeGui# was in a usable state, with only some small glitches here and there. The reason I decided to ultimately create my own GUI was that it seemed very difficult to support for game pad controls to CeGui#.

Apart from the SpriteBatch issue, Nuclex.UI should not be that difficult to port since all the rendering code is in the FlatGuiGraphics class. It will only start to become difficult if you try to remove XNA completely as I'm using its Vector2s and Key enumerations all over the place.

Aug 13, 2011 at 3:43 AM

Thanks for your answer. We have the old ceguisharp running, but its so old and difficult to customize that i m still looking into porting nuclexUI. With your nice framework on my xna game I had finished a full inventory system with custom draggablebuttons that drop on some containers and just link on some others ( = copy the icon). Re doing this with the old cegui seems really hard.

Key enumerations and Vector2 are not a problem, just a big search and replace of the usings was enough  .  What 's hard is trying to reimplement the gamemanager , defaultinputcapturer etc.. but  it seems possible. 



Aug 20, 2011 at 10:03 PM

Update : We successfully ported your nuclexUI to our non xna engine ! My custom renderers still works fine, the last bugs are unirectangle not working properly and some label alignment weirdness .

There was something strange,  on this line in the skin file :

<text font="default" hplacement="center" vplacement="center" yoffset="15" color="#3F3F3F" />

we had to remove the yoffset=15 to have labels centered on buttons, they were floating 15 pixels outside buttons ! Maybe we fixed a bug during porting ?

What was done :

- plug our input into screen injectInput methods ( took me some time to realize other input interfaces were not needed in our case, having made cegui run previoulsy helped  ! )

- implement our own spritebatch

- reorganize dependencies to get rid of the usual service locator antipattern mess, graphicsdevice passed through contentmanager this sort of things.

- Load everything through the resource(no content manager)

- Change all rectangles / vector2 to use our own or windows form

- Change all keys / mouse to use windows form instead of xna  ( mousebuttons custom enum with [flag] was needed, windows form is not a flag enum that was annoying )

- comment everything related to gamepads (for now ! )

I cant release the port as is, there are still bugs and our dependencies are not clean ( we had to pass our game instance to flatuigraphics, doh ! ) But I will try to release something or at least give you a detailed change log.

Aug 20, 2011 at 10:37 PM

we had to remove the yoffset=15 to have labels centered on buttons, they were floating 15 pixels outside buttons ! Maybe we fixed a bug during porting ?

Your font rendering system probably behaves the same way XNA's does (at least with Microsoft's SpriteFont content processor): fonts are drawn with the upper end of the text at the target location. I much prefer to have my text placed so that its baseline (the lower end of common characters, 'gpqy' being exceptions) is at the target location as this makes it easier to align text to symbols. To achieve that in XNA, I use a custom content processor for the fonts.

You could have just provided the required enums and implemented the IInputCapturer interface and assigned your custom implementation to the GuiManager.InputCapturer property. Would have saved you the trouble to manually manage on which screen you need to call the Inject...() methods in case you have multiple screens. But depending on your environment, maybe that was an conscious choice.