Spring RTS Engine

I honestly didn't think I'd ever get around to releasing an update, but here it is .

Copied from README:

==== FEATURES =====
- scalable windows with child windows
- speed and responsiveness
- acts as any other widget; no need to overwrite the general widget manager
- window manager to handle most low-level call-ins
- function hook interface to add features to any window
- easily addable title bars
- edit mode for windows w/o title bars
- three demo windows: a simple reload Lua button, a slightly more complex camera selector, and a debug output window


==== CHANGES =====
v0.1->v0.2
- uv/xy coordinates now behave properly
- edit mode (press ctrl-alt-f11)
- title bars (only if you want them)
- created debug and reload windows
- updated documentation w/ new section on creating windows
- REMOVAL of window creation helper functions (they only made things more complicated)
- So many other bugfixes I lost count

==== FUTURE VERSIONS ====
I'm daring enough to predict a v0.3, though it really depends on how much free time I have/ how bored I am. If I do release a new version, expect me to start creating some more windows matching Icexuick's UI design, as well as any features requested on the forums.

Specifically, look for these future features:
- new control handlers for tabbed windows, button boxes, edit bars, and progress bars
- helper function for creating complex table layouts
- game speed control window, player info window, and resource bar window



PS: This system is mainly my vision of what the Spring UI should be/ feel like. Apologies to Meltrax if I'm on his turf here, but he seems to be inactive recently and I have had a ton of free time because I just graduated from high school ('07 Baby ).

PPS: Here's a screenshot:

nice job i think the header files should be bundled with next spring version, to allow anyone to create gui components with minimal effords


there is an issue:

you binded CTRL + ALT + F11 to edit mode, it's a system key for linux, it switches to another grafic session (any ctrl +alt+ F1-F12, is a system key) , please change it to ctrl F11 (wich is the standard lua edit mode key)

EDIT: when the window system is on, i can't seem to be able to access the widget selector window (F11 key)

also, could the debug window be moved to a separated widget?, it would be the best to keep the headers as pure non-grafic enviroment, and add grafic stuff as widgets (debug could be redirected to the game's console when a gfx widget handler is off)

Good catch Brain Damage... I should have noticed that.

Trepan: If and when you read this: How hard would it be to have .svg support in the engine? It would make scalable interfaces look a ton nicer. There are tons of open source projects that display .svg online. I'm sure you can find at least one that converts .svg files into a list of textured OpenGL vertices.

This is great! Exactly what I was looking for.

It doesn't run on the SVN version of Spring, though. I god rid of the first couple of errors by replacing all "gl.ListCreate" with "gl.CreateList", but then I got this: [string "LuaUI/Headers/window.h.lua"]:408: attempt to call a table value.

This is a great step forward.

I actually want to move the debug window to a separate widget... the problem is atm I have no clue how to communicate between two widgets (i.e. send debug text from the camera widget to the debug window widget). If someone (looks at trepan) could enlighten me on how to do this, I will move it to an entirely separate widget.

I think I know why the widget manager won't show up, and I'll fix this and the linux keyboard bug in the next release. Both of these bugs stem from my flawed implementation of widget:KeyPress, and both will be easily fixed.

quantum... I haven't tested this on the SVN build, because I currently don't have the SVN build (I gave up after it still wouldn't compile after an hour of effort). The error message you're reporting troubles me, cause it sounds like trepan somehow disabled calling functions stored in tables, which is an integral part of my system. Maybe trepan can weigh in on this.

You don't need to compile Spring yourself. You can use one of the automatically compiled builds or installers here.

Yay, I got it to run! Lua 5.1.2 is used in the SVN, so "for i in table" is not allowed anymore. It should be replaced by "for i in pairs(table)".

Here is the diff of the changes:
[code]--- C:/Documents and Settings/Admin/Desktop/AlfaWindows_v02/LuaUI/Headers/window.h.lua Thu May 31 17:26:34 2007
+++ A:/mods/CALua.sdd/LuaUI/Headers/window.h.lua Sat Jun 02 07:52:54 2007
@@ -65,8 +65,8 @@
local function MakeCircleList(type)
gl.Shape(type, {{v={0,0},t={0,0}}, {v={0,1},t={0,1}}, {v={1,1},t={1,1}}, {v={1,0},t={1,0}}})
end
-local circleLineList = gl.ListCreate(MakeCircleList, GL_LINE_LOOP)
-local circlePolyList = gl.ListCreate(MakeCircleList, GL_TRIANGLE_FAN)
+local circleLineList = gl.CreateList(MakeCircleList, GL_LINE_LOOP)
+local circlePolyList = gl.CreateList(MakeCircleList, GL_TRIANGLE_FAN)

local function DrawLists(px, py, sx, sy, t)
gl.PushMatrix()
@@ -74,7 +74,7 @@
gl.Scale(sx, sy, 1)
for k,v in pairs(t) do
gl.Color(v[2])
- gl.ListRun(v[1])
+ gl.CallList(v[1])
end
gl.PopMatrix()
end
@@ -387,7 +387,7 @@
-- now iterate through each child window
if hWindow.index then
local i=0
- for i in hWindow.index do
+ for i in pairs(hWindow.index) do
tCurrent=tCurrent.children[hWindow.index]
uvAbsScale=xytouv(tCurrent.xySz)
uvAbsPos=xytouv(tCurrent.xyPos)
@@ -405,7 +405,7 @@
if hWindow.index then
local tCurrent=hWindow.tParent
local i=0
- for i in hWindow.index do
+ for i in pairs(hWindow.index) do
tCurrent=tCurrent.children[hWindow.index]
end
return tCurrent
[/code]

Whee, off to play with the new toy!

Hey alfa..

As a matter of fact I also continued my work on IceUI a week ago and will post a new version (for SVN only) in the next days..

I think we both want the same result but have a different starting point .. I go with an object-oriented approach which allows more flexibility but doesn't have the performance yet that your system probably has (haven't tried 0.2 yet)..

The problem with communication between widgets is exactly the reason why I chose "to overwrite the general widget manager" (and because one widget couldn't disable another) .. You can communicate in the current Spring version (0.74b3) by reading/writing the Game-table.. Though in the SVN builds of Spring this is no longer possible and trepan implemented several ways to do stuff with other widgets (like disabling) and I think there's a global table now to share stuff between widgets..
Another thing: Your Lua reload button won't work with SVN builds of Spring because "/luaui reload" was never meant to work from inside LuaUI.. It did in 0.74b3 and because I also used it, I noticed it crashed Spring and after I told trepan it now throws an error like "Can't reload from within LuaUI..".

The question is what we will do from here on.. We can just both work on our window systems and have a competition going or we could merge them somehow.. Because of the good feedback in this thread I think you guys don't like something of my approach. Don't get me wrong, it's cool that AlfaSub continued his system but I would like to know what you don't like about mine .. Is it the speed? Is it the fact that it's all in one widget? Is it that I don't have titlebars (yes, I know AF.. I will add them..) ? My best guess is that noone can make their own stuff with it atm because there is no documentation.. I just wanted to add all critical stuff before I write the docs..

BTW: I totally agree with that svg stuff.. Would make it a lot easier..

PS: AlfaSub

EDIT: I just spoke with MelTraX in the lobby, and it seems that the only issue is documentation

when the window system is on, i can't seem to be able to access the widget selector window (F11 key)

Same here.

[quote="MelTraX"I would like to know what you don't like about mine [/quote]

i think you should split the abstracted grafic functions to header files, just like alfasub is doing, put them in the headers folder and give them access to every widget maker that would feel like to.
Would be best if those headers would be included in spring, so would start building a "standard lib" wich most common functions that would save lot of effords to any lua scripter.

said that, if you 2 can find a common point and work togheter , it would be great; just a small note:

since what you're gonna make is going to have a wide audience span, i'd suggest to implement both quick-easy & complicated-flexible functions, to allow anyone to get what he needs

First: Now I tried it. I see the same small errors and when I tried to resize the reload button while holding shift it just disappeared. Probably nothing big.. Apart from that it's pretty cool and you already have some nice features I don't have..

After chatting with quantum for quite some time, I think I need to explain some stuff about IceUI though.. Sorry that it's in your thread but there seems to be some misunderstanding.

IceUI consists of two things (as said in the first post of my thread):
- a general purpose window system
- content for this framework (similar to IceXuicks GUI design)

Each window in IceUI is one file in the IceUI/ directory (not in sub-dirs). The rest of the files belong to the framework.

Since AlfaSub included an example implementation of the little camera window, you can easily compare my system with his. Just download IceUI from UF and open the file Widgets/IceUI/camera.lua and AlfaSubs example file. This is a bit unfair though because in his file are also two other windows but you can compare the two systems pretty good.

Regarding performance it's pretty unfair to compare IceUI as offered for download with AlfaSubs window system. I already implemented almost all of the old GUI (and my player info widget) and AlfaSub only gave an example how to use his system. Still, with the current SVN build of Spring I have an FPS decrease by only ~5% activating all of IceUI and this will get better once I use some new features trepan implemented. So I think the performance issue is pretty much sorted out.

What's really missing - as quantum already said - is some documentation on how to make windows with my framework. I didn't write one yet because I wasn't sure about some core stuff yet but I will start after one or two important features were implemented. If you are interested you can look at Widgets/IceUI/*.lua to see how the current windows are being made.

AlfaSub, I'm really sorry to take apart your thread like this.. But I also put a hell of a lot work into this and it seems there was some misunderstanding about what IceUI is and where it's going..
It would have been really cool if you'd just chatted with me before continuing your window system just to see where we're going.. Because now we have two systems and we would both be pretty disappointed if noone uses them ..

But still.. I only chatted with quantum.. All the others please tell me what you don't like about my framework..

This post is going to be a volume in and of itself, skip to the end if you find yourself bored (not you Meltrax, you gave me a ton to read, now you must read what I have to say )

Meltrax, I agree with ~90% of the things you say.
I think we need to work on some sort of merge project, as it sounds like our systems are very similar. Here's some minor corrections/rebuttals to your previous two posts.
- My window system is object-oriented as well, though it isn't handled as nicely as your stuff is.
- I was planning on overwriting the widget handler at some future point. If we can merge our projects, this effort would be redundant.
- I have an objection to SVN-only releases, because many people (myself included) don't have the effort to dedicate to getting the SVN version to build. Currently I've spent 2 hours working on it and still am plugging along when I have time.

With these general comments aside, I have some comments pertaining to a possible future merge project. Upon cursory examination of your latest released code, I have several comments on what I think you did well, and what I think you did poorly.
==CONS==
- As a fish-out-of water c programmer, the most confusing initial problem was the lack of an entry point in some of your files. i.e. it took me a bit to realize that the entire text of your widgets is run like an initialization function. I'm used to all code in a file being wrapped in at least one function (main, WinMain, widget:Init, etc). I really think you should change this in your next release.
- The second problem I have is the apparent lack of child windows. I know you have frames, but imo my child window system is better because it allows for better compartmentalization.
- I don't think you have co-existing absolute and relative coordinates fleshed out in your system. It is important to be able to define both so you can have, for example, a title bar of fixed height 18px attached to a window with variable height 0.5.
- In the sample below I have some minor syntactic changes that imo will make the code more intuitive to the untrained eye. I'm not trying to get in a religious debate over bracket placement here, so comment on what you see.
==PROS==
- I think your class-based implementation is much better than my table system, though we could work a bit to reach a happy medium between the elegance of the former and the simplicity of the latter.
- Your different components are much more well-defined than mine.
- Your dedicated window manager is an obvious plus

Without further ado, I present a possible merged code sample. Everyone who's made it this far, chime in on your opinion of how intuitive the code looks:
The dud functions here (NextCamera, etc.) are just to save space and would be replaced w/ real code in the actual widget.

The best code is its own documentation.

PS: To everyone posting here, I HAVE ALREADY RESOLVED THE KEYBOARD F11 bug. The keybinding in the next version is now SHIFT-F11 (overwriting the edit mode key binding). The problem was the keyboard handler was unconditionally capturing the F11 event, meaning that it was never passed back to the widget manager for handling. Really a rather silly oversight by me .

Thanks for bearing with me to the end, those that did.

Thanks for that explanation/statement, Alfasub.. I think we will find a good compromise somewhere in the middle.

First regarding SVN: It is really simple to get a SVN build of Spring working. You don't have to build it yourself. Quantum already posted a link. If you use the "Parent directory" link on that page you can also find the installers. It's as simple to install the latest SVN build as it is install the latest release.
Having only SVN-only releases would of course be stupid as noone would ever be able to use it in normal games. With the release of 0.75 I will start a stable branch in my own SVN that works with the current release and in the trunk I will adept to Spring SVN changes.

Now to your content .. I also agree to most of the stuff and will just comment on things where I don't say "true"..

First of all thanks for your honest opinion.. That's the only thing that will improve our situation..

• Making the code readable would be cool .. I don't think the "class-definitions" should be in the Init function though..
• By "child windows" you mean something placed freely into the window with it's own x/y and height/width, right? It can be done (kind of) with a margin.
• Absolute and relative coordinates can co-exist in the framework. Maybe we need to make it a bit easier though.

Now some comments to your "merged code":

• Giving most stuff names seems like a nice idea. I was only planning to give windows names.
• The Load/SaveWindowPos calls aren't needed when you use the framework though.. That will happen automatically..
• I guess your four coordinates are 2 for absolute and 2 for relative size/pos. Assuming it's not needed to position/size windows with fractions of one pixel, those can be merged to one value. Currently my framework uses these size values: <1 - relative to parent, >=1 - absolute, <0 - relative/absolute substracted from parents size, nil - 100% relative since 1 is ambigious
• I assume the DefaultStyle() call determines stuff like color and if the window should have a titlebar. We can add that as an Init-state. I was planning to make them changeable in the options though (colors already are). And then I will make setting-profiles which can be saved and some will be shipped with the GUI (ie a default one for different resolutions). Hmm, I still think your call is a good idea ..
• How about having style flags for some stuff and making constants out of them (like in most languages): text:New("label", "str", TEXT_CENTERED & TEXT_TRIM) or something like that. There is no bit-and though but I think we can come up with something. That would at least be better than my current system, I think: text:New({ text="str", align="center", trim=true })

I think that's it for now ..

If we really want to merge our efforts (and I think we do), we can't sort out all stuff in this thread anyway. It would be cool if you could let your TASClient idle in the lobby when you have time so we can chat.. I don't know what timezone you live in though..

Brain Damage: Sorry, I just saw that you posted. As AlfaSub also realized, it's kinda hard to have windows communicate with each other if they are widgets with header files included. Doing something like snapping windows (moving stops if they are side-by-side) would be nearly impossible if they were widgets on their own.

The idea behind my framework is kind of this: Like trepan distributes the call-outs for widgets, I distribute callouts for GUI-widgets and those GUI-widgets are in the folder Widgets/IceUI.. So if you want to make some function and have a GUI to control it, I would suggest you make a normal widget with the functionality offering commands ("/luaui mycommand") and make a seperate GUI widget that uses these commands. Or you just make the GUI widget that also implements the functionality.

My hope is that if all main features of the framework work it will be included in Spring and everyone can just release their GUI-widgets.. Since 0.75 is still about two months away maybe we can even focus on this next release.

Hmm, that was another looong post ..

edit: AlfaSub, I think you should thumbnailize your screenshot. It's fine with my resolution but people having <= 1024*768 will have a hard time reading this thread because of the horizontal scrollbar and quite a bit of text

For anyone wondering about the future status of this project, Meltrax and I have been talking over the Spring client PM system and have decided we will merge our projects for the future.

I appreciate all of the support and comments here, and both Meltrax and I are working to ensure that the future window system has the combined simplicity and power of both of our projects. If you are interested in helping with the next release of the windowing system, PM me (or Meltrax) in the spring client or on the message boards (this means you quantum )

Once again, thanks for all your comments and support everyone, and look forward to a new merged release soon!

Yep, we hopefully will create some cool stuff here :D..

We just chatted and haven't merged anything yet but I released a new version of IceUI today: Post, File

Please setup SVN with public read access so I can see what you are doing? :)

SVN is up under https://meltrax.homeip.net/svn/IceUI...

You can use the bundled updater though as it automatically downloads the latest commits and shows the SVN log.. Whatever you want, the files are the same.. I'm also planning to write an updater (as a shell script) for Linux but that's not the first priority atm.. So if you're using Linux you should just check-out the SVN..

The reason I made the updater in the first place is because not everyone wants to install SVN and the more important reason: it's difficult to have one check-out (IceUI) inside another one (Spring)..