C# Port

[leedgitar]

Todays latest additions: Titlebars, double/triple clicks, window rollup, window dragging, close button.

No font rendering currently (so you can see the height of the titlebars in the pic were hardcoded ), but I consider that to be partially done already since I wrote some dynamic font bitmap generation code for Axiom that uses built in .Net functionality, so that should be a snap to fit into this GUI.

Edit: Pic removed, updated one later in the thread.

[CrazyEddie]

Hey hey! Starting to look like the real thing now

I would imagine that the Font classs will be your last big hurdle, it was the last part of the base system that I implemented too When I wrote it, it did seem silly to re-implement what was kind of already available in many of the rendering systems I would be targetting, especially the likes of Ogre and also Arnaud Storq wrote to me about DevLib (which has it's own font support too) as a renderer. Ultimately, to remain independant, I rolled my own - and I'm glad I did as I could then make it do lots of things that otherwise would either have been left out or not implemented so cleanly.

Sometime I'm probably going to add another couple of drawText overloads that assign a passed reference with the extent of the rendered text (saves doing a getTextExtent immediately after rendering, but is only relevant for single line text).

[leedgitar]

Since the last update, I've got the checkbox, radio buttons, and progress bar (1 of the 2 variations) done, albiet without the text (same as the previous update). I've got some of the Font stuff coded, but I knew I could whip through a few widgets tonight so I went ahead and did them for fun

Note the widgets look much crisper than before now that some filtering is applied, and it uses Paul's most recent imageset update.

Edit: Image removed

[leedgitar]

Tonight I got the the font bitmap generation working for the first time. There is still a bit of work left to do before I will be able to use it, but at least the core functionality is working. For instance, I still have a method in D3D to implement for loading raw image data, although the GL version is done and working. Having the GL version working at least allowed me to blast a quad on screen using the font texture to verify the glyphs were added correctly.

Over the weekend, these are what I hope to finish:
- Get dynamic Font rendering at least 90% working.
- Implement the base and Taharez slider, as well as the alternate Taharez progress bar.
- Add buffered input in the Axiom input reader, which is something I need before keyboard events will work properly.
- Maybe even get the C++ version of the GUI compiling (I actually haven't tried yet ) so I can run side by side with the C# version, in case I need to compare results at runtime.

[CrazyEddie]

Tonight I got the the font bitmap generation working for the first time. There is still a bit of work left to do before I will be able to use it, but at least the core functionality is working. For instance, I still have a method in D3D to implement for loading raw image data, although the GL version is done and working. Having the GL version working at least allowed me to blast a quad on screen using the font texture to verify the glyphs were added correctly.

Sounds very similar to what I did. The C++ version is using FreeType which I had never used before, and I really didn't know what I was doing, so just being able to see what was being put onto the texture was a great help, and a great boost to confidence.

Over the weekend, these are what I hope to finish:
- Get dynamic Font rendering at least 90% working.
- Implement the base and Taharez slider, as well as the alternate Taharez progress bar.
- Add buffered input in the Axiom input reader, which is something I need before keyboard events will work properly.
- Maybe even get the C++ version of the GUI compiling (I actually haven't tried yet ) so I can run side by side with the C# version, in case I need to compare results at runtime.

Cool Someone's going to be busy Compiling the C++ version shouldn't be too bad - people have done it, so my initial estimates of how much messing about would bre required may have been a little exaggerated

[leedgitar]

Another update (no screenshot this time, although the slider is done, heh).

Tonight I finally got around to implementing the real Window management code, which I had me sitting on the fence for awhile as to whether to go with a whole new .Net approach, or stick with a straight port of the existing code. So of course, I chose the former
(Note: Prior to this, I was simply creating widgets manually like window = new TLFrameWindow(bla bla) in my testbed for quick and dirty widget testing.)

In my current testbed, the custom Taharez widgets are actually now treated as scripts, and are compiled at runtime. The Window manager compiles all scripts in a particular directory, grabs all types that are subclasses of Window and adds them to a map that maps the type name to the assembly that was generated. In CreateWindow, it checks the type is valid and that the name of the window is unique, then creates an instance of the type via the Assembly reference. The end result is that I can now edit the widgets without having to recompile anything myself. At the moment it is a nice mix of scripting (using C# itself) and is almost "data driven" in the sense that I can very easily tweak everything in an external file, with the extra benfits of having a full fledged language at my disposal

I have a few more tweaks to make to the code yet, but it is fully working and I think it is pretty slick . I also intend to abstract out the actual compilation code, to allow for using various languages (including VB or J#), in addition to using either the Microsoft or Mono compilers (which I have to read into to see how CodeDom type stuff is implemented in Mono).

Of course, it will also be able to load prebuilt assemblies. Perhaps it can even generate the assembly from scripts. save the assembly, and only recompile on startup if the widget scripts are changed. Either way, the dynamic compilation takes next to no time on my laptop.

I wanted to get this in order before releasing a first demo, so that the code in the test app was more representative of what it would like like in the completed API. I will try to aim for a first demo download this weekend.

[CrazyEddie]

That sounds awesome Can't wait to see the first demo of this.

Seems that maybe I'll be playing catchup with the C# version

I'll get these base widget classes and the taharez set done ASAP now so that the system is completely 'usable', then spend some time on some features that will hopefully take things to the next level (not made any decisions on what this will mean yet, but it does involve the Lua scripting support)

[leedgitar]

The last update about text rendering was when I first got the font bitmap created successfully. However last night after implementing some of the DrawText functionality, I spent plenty of time pulling my hair out trying to figure out why the text "123" got rendered as "V12" (amongst other oddities), even though I knew all the texcoords were calculateded properly. I wrote out both my bitmap and the D3D surface to file, and noticed that what should have been the rightmost columns of glyphs had found its way to the first column of the bitmap in the D3D texture.

Long story short, when writing raw image data to a texture, it might be a good idea to skip past the bitmap header first

Anyway, after wrestling with GDI+ to get accurate font metrics, I believe everything is in good shape now textwise. Thats the last thing I wanted done before I put up a demo, so after I spice up the demo a little bit, expect to see it Sat or Sun.

[CrazyEddie]

Excellent work I'm really looking forward to playing around with this

[CrazyEddie]

Leedgitar is working on the c# port, progress is coming fast but there are no downloads for this version yet. Leed is supposed to be releasing an early demo very soon.

[leedgitar]

The good news:
- It is packaged up and ready to go with a decent demo.
- Static text with word wrapping works.

The bad news:
- I sent the package to Randy Ridge to have him smoke test it first, and discovered the fonts look quite odd on his desktop PC, which I also found was the same on my desktop PC. They look fine on my laptop however (as seen in my screenshots).

So, I'm gonna play around on my desktop (GeForceFX 5700) and try to square that away first since it takes away from the quality of it all. Maybe another day or 2

Update: I found that the font bitmap does look much crisper when generated on my laptop, which I can understand if XP takes ClearType into account when rendering the fonts. So, since I need to implement the the non-dynamic font loading functionality anyway, I will go ahead and code it up, then use the bitmap generated from my laptop in the demo rather than generating on the fly for now. I will get that ready for tomorrow night, then look into getting font consistency on different systems.

[leedgitar]

Alright, it's time to deliver the goods!

http://axiomengine.sf.net/tmp/AxiomGuiDemo1.zip

Notes:
- A VS.net 2003 solution is included. I didn't have time to complete the project file generation script for it, but I will have that for the next demo.
- Requirements are the same as Axiom.
- All source is included (not in CVS yet).
- Code for Taharez widgets is under bin/Scripts/TaharezLook. Feel free to hack the code and rerun the .exe to see the changes implemented before your eyes . If there is a compile errror, you won't see squat in the demo except a debug message saying "Script compilation failed". The CEGUI.log file will contain compilation errors returned from the C# compiler.
- You can generate docs using NDoc or the Xml comment doc generator of your choice, I didn't have time to do it myself.

There are a few quirks, such as a stray pixel appearing under instances of the letter "i". Feel free to list anything you find so I can take note of it if I am not already aware of it.

Have fun!

[CrazyEddie]

This is so cool. Especially your dynamically compiled widgets (it's not fair!)

I did see the strange dot that accompanies the 'i' but everything else seems to be spot-on. If I do notice anything else later on, I'll obviously let you know.

This is really excellent work

[leedgitar]

Thanks

There is also a problem with the ordering of a windows child windows, but it is just a small mistake somewhere, patiently waiting to be fixed. (you can see this by adding 2 FrameWindows as a child of a parent frame window, then noticing the MoveToFront functionality when clicking one does just the opposite )