EvoGUI 0.98 beta (with source)

[Lenn]

Following the -announcement- (please read it), here it is dear fellow TV3Ders!

After about 350 hours of development time, we've finaly reached beta release of version 0.98.

Download link: EvoGUI_098.zip (2MB)
Language: VB.NET
Solutions for VS 2005


Here are some screenshots :






There are no docs apart from the basic instructions released with this version 0.98. See the help098.htm for usage instructions.

There are some basic examples and the editor. The TPE (Texture Parameters Editor) is also very beta, and some parts of it are quite hacky. It wouldn't be the best example of non-standard use of some of the GUI systems (like the scrollbars on the image display window), but it may show you something for now.

Coding-wise, I am particulary proud of the word-wrappable text boxes (and input boxes) which are also layered with 8-bit alpha like everything else in the system. They are very fast and employ a sort of staged refreshing, which can be regarded as a kind of a stepped multi-threading system. They have been optimized beyond any reason, and about 90 hours has been put only into working on them.

The code is also a little odd, right now it isn't fully sorted out. Many of the methods have been left as public, but at least I took the time to take out all the debug stuff out of this release. It's still in development so you should understand this. Some other strange coding practices have also arisen due to the fact that the base of the system was done under influence from Xlnt GUI which I worked with in Blitz3D, but by now there are no traces left of Xlnt in EvoGUI apart from gadget names and some variables. There are also a lot of Me.something which i typed to get quick intellisense of that class (yes, i know...). But in general, I think the code is very optimized in the cruical parts. The few remaining optimizations can be done easily, and I will probably do them myself by v1.0. Some of the notes for planned optimizations have also been left in code comments.

There are also some minor bugs, but I'm not sure how noticable they will be. Tell me if you spot any bugs that you think make the system look really bad. The TPE has a lot of bugs (by my standards anyway), or should i say "unoptimized" features, but at least is serves the purpose for editing skins and bigtextures. Mouse cursors and animated strips features cannot be edited at the moment using TPE. Also, with older GPUs which cannot use non-power-of-2 sized render surfaces, the GUI will look wrong. I'm not sure if I should even add support for those GPUs (can be done tho), as I'm not sure how many users still have them.

Once i meet the minimum quality requirements for my project with v1.0 of EvoGUI , I plan to turn my attention elsewhere for my project and add stuff to the GUI only if the other parts of the development don't take too long, ie go within reasonable project schedule limits. I need to prioritise! However, if you ask me, chances are pretty good that EvoGUI will be improved with various additional features in the next 6 months.

The future additions are:

v1.0 will have:
-Animated mouse cursors
-Animated image class (animation strip)
-Shaders applied to windows for fade-in, fade-out and blurring effects.

Future versions are likely to have:
-Tabs
-Scalable window frames
-Tree structure display

May also be added if I get the time:
-Collapsable bars in window areas
-3d effects and more shaders (refraction, cubemapped windows,global lighting effects)
-Polygonal clickable areas with highlights

[ZaPPZion]

Thanks a lot Lenn, it means a lot giving 2 months of work away as open source!
BTW, the links are a bit broken, there's some syntax errors there

[rootsage]

Wow, how very generous. I have been wanting to see how others write their GUI systems, this is going to be a tremendous help for me to learn off of, thank you very much!

[Raine]

Thanks for sharing Lenn

[António Mateus]

Thank you very much for sharing.

I'm sure it will be very very usefull for everyone

Regards,
António Mateus

[Lenn]

You are all very welcome! I would be even more glad if you do truly find the system useful.

I have been wanting to see how others write their GUI systems, this is going to be a tremendous help for me to learn off of, thank you very much!

Maybe I'm wrong, but I think that EvoGUI is extendable enough for you to be able to easily write your own controls on top of the existing ones. It might perhaps save you time to understand how it works and extend it, instead of writing a whole GUI on your own. I think that a GUI system is absolutely THE most complex thing known to mankind to code properly....


Please tell me how well you think it performs, once you play with it a little. I have only tested it on one of my machines which is a little faster than the average user's. If you think a certain part of the system causes a framedrop or a freeze which shouldn't be there, tell me.

The rotating 3d letters in the background aren't there just for show. They are to measure what the FPS counter often does not show, which is the small and short hickups which a lot of GUI systems are known to be able to cause.

Also, as time goes on, if you need documentation sooner rather than later, also let me know that, because for now I have a feeling that things are straight forward enough and I'm not even sure if anyone will need the docs, especialy with the examples in v1.0. However, complaining to me will generally have a positive outcome.

cheers

[GD]

Nice and professional! Very clean and tidy, imo much better than other quasi commercial guis I've seen.

[rootsage]

You are all very welcome! I would be even more glad if you do truly find the system useful.

Maybe I'm wrong, but I think that EvoGUI is extendable enough for you to be able to easily write your own controls on top of the existing ones. It might perhaps save you time to understand how it works and extend it, instead of writing a whole GUI on your own. I think that a GUI system is absolutely THE most complex thing known to mankind to code properly....

Yeah, that is what I meant Why re-invent when there is already 18,000 lines of code at your disposal. Again, thank you for this contribution.

[Lenn]

Here's a small update on the progress towards v1.0:

What has been done so far:
-Animation and cursor editing support completed within TPE
-Animated cursors introduced
-Animated image gadget class introduced
-Animated image button gadget class introduced
-Major optimization #1: Window.IsolatedRefresh (and each gadgets Refresh) no longer creates intermediary surface for drawing to window, but is instead being drawn directly to window. This eliminates a large part of the slowdown caused by decreased efficiency of CreateAlphaRenderSurface when the application is left running for longer (as per topic posted elsewhere on the forum)

Currently being worked on:
-Major optimization #2: Introduction of TemporarySurface class, so TextBoxes no longer destroy/create surfaces upon refreshing but instead use a big surface constantly stored in memory and drawn to accurate size by means of UV clipping to the window surface. Also, ListBox class and a few others use this to speed up clipping of text. This means only window resizing now recreates surfaces which if proven to cause a slow down in practical usage will be fixed in the same way.
-Applying shader effects to windows: fade in and fade out, both tested and work well, just need to put it into the EvoGUI code structure. I am having second thoughts on usability of blurring effects.

I expect to have v1.0 ready by the 15th.



And another few notes:

-I think this interested some of you: The license will be 20 euros, and you will have to share all modifications to the system with me, if not the public.

-I got very little feedback so far on the system. All of it was good, but please, if you find something you think can be improved - tell me! You don't have to do it in public, you can PM me or something, because otherwise I'll think the system is either perfect or that it sux so much no one wants to tell me... 

-I was thinking about working on documentation and examples, but since that takes so much time and yet nobody asked me for it, I'm not sure anyone needs it so I will probably not do comprehensive documentation until someone asks me to. After all, it is open source and I will provide more examples, so in that sense everyone will figure things out easily even without the docs. Right?

Cheers

[Brac]

Nice and professional! Very clean and tidy, imo much better than other quasi commercial guis I've seen.

Looks like this one is also quasi commercial, tho. 

@Lenn: Good job. Keep it up!

[Lenn]

Looks like this one is also quasi commercial, tho. 

@Lenn: Good job. Keep it up!

Thanks! Will do. 

But do you mean quasi commercial as in not fully usable by other commercial users, or as in half-free for being open source, or something else? 

[Soganatsu]

I really like your system and I'm surely willing to buy it once it's finished ^^

But there's some small bug or whatever that's disturbing me a bit..
I need to initialize the GUI system (loading windows, etc.) while there's already something being rendered on-screen.

Problem is: Somehow this corrupts the loading procedure so instead of a normal window after initialization I can't even see it's border. as soon as I click on it, it's border restores, but the rest stays fragmented.

When I minimize the Window and Maximize it again, it's completely visible again with no fragmentation.

Could there be any problem during your loading procedure?

Cya,
Philipp

[Lenn]

I'm glad you like it, thank you!

Ah, I see. Well yes, you are supposed to initialize it at the start of your application. I can't see why you would really want to initialize it during a render?

When you say "initialize" you mean: MyGUI = New EvoGUI(Inp) ?

Or do you mean to initialize the windows (in the example the function is called InitiateWindows), meaning create new windows and add gadgets to it? If that's the case, then all you need to do is call MyGUI.RefreshWindow("YourWindowName") after adding all of the gadgets to it and it should appear normal. In both cases you should try calling MyGUI.RefreshWindow, as that should fix it.

On the other hand, if you are New-ing it during a render loop (which you really shouldnt do), try to New it at least outside of a tv.clear - RenderToScreen section. Ie, make sure it's either before or after the part where tv is drawing to screen.

Hope that helps. If not, give me more details (preferably the exact code) and I'll help you out.
Cheers.

[Brac]

Thanks! Will do. 

But do you mean quasi commercial as in not fully usable by other commercial users, or as in half-free for being open source, or something else? 

Oh i was just refering to GDs statement there. The tag "open-source" got me thinking it would be free software, but since you give away commercial licenses it's quasi commercial.
No big thing really.

[Soganatsu]

Hey Lenn!

Thanks for the fast reply And yes - I am new-ing Windows inside the Render loop, as my Update Commands for each GameState are lying inside it.

What I'm gonna try for now is add an Update GUI Sub before TV Clear.. hopefully that'll help.
My main problem is that I really want to load windows at run-time (e.g. evertime a new GameState launches, initialize it's GUI inside it's New Sub).

[EDIT]

Okay, thanks, loading the Windows outside of the Clear-RenderToScreen Part seems to work pretty good

[Lenn]

Ok, i'm glad you got it working.

Keep in mind, you really shouldn't need to New() the GUI more than once except in rare circumstances. Just like you shouldn't New() the TV engine or Screen2dImmediate, and so on. You should New it at the beginning of the application, and from then on access it by passing it along in any way you prefer. Whatever problems you might have in the future, it's always best to try to copy the sequence of the given examples as closely as you can.

The only time you would for example have two separate GUIs assigned is when you are modifying some critical GUI-based variables or rendering two GUIs to two separate render targets - such as if you want one GUI to display on a 3d object (i'll show this in an example soon). Otherwise, calling MyGUI.New too many times will only waste memory since unlike TV, the EvoGUI class isn't set up as a singleton.

[Soganatsu]

Like I said, I wasn't newing the GUI, I added new Windows (bla = new EvoGUI_Windows(blabla))

[Lenn]

Oh, sorry, we mixed up the terms - i thought we reserved "newing" for GUI and "adding" (or initializing) for windows, so i wasnt sure what you meant. heheh 

Either way, when a window is created and gadgets added to it, you should always refresh it using Gui.RefreshWindow() at the end.

Cheers 

[Soganatsu]

Now here's what I tried:

Create a window inside the Render Loop. After creation, refresh it.
Didn't work, still displays a mostly corrupted Image.

Cheers,
Philipp

[Lenn]

Well that's the thing, if you create a window mid-render, then of course it will be corrupt because the window cannot be rendered to as the renderer is already working on rendering to screen. Window creation warrants the use of a Window.Surface.StartRender() in order to draw it, and if you call that between the TV.Clear - RenderToScreen section, of course it wont work! All game loops should be able to accomodate an Update function, just like you need to have a place for the MyGUI.Update which is right before TV.Clear in the provided examples. You should create the window(s) at the same spot, ie right before TV.Clear. It's just a question of coding preference where you put it in your loop, so there should be no problem. Meaning, it can be in your game loop just not in the rendering part of your game loop.