Dev meeting minutes 2011-03-21

[hoijui]

Date: 24-3-2011
Present: Kloot, jK, hoijui, Tobi

__ Agenda _____________________________________

• GameFrame question
• assimp merge?
• do we want librocket?

GameFrame question
<Tobi> jK, do you happen to know any reason why Lua GameFrame is executed *before* gs->frameNum is incremented, while everything else in a frame is done later?
<jK> because it expects a GameFrame==0?
<jK> duno
** Kloot joined the channel
<Tobi> well I'd say that is *because* it happens to start at 0 now
<Tobi> I want to change it to increment frameNum *before* calling Lua GameFrame (but still pass in the 0-based frameNum)
<jK> so you want to pass the zero gameframe before gamestart?
<Tobi> no
<Tobi> I want essentially to do frameNum++; GameFrame(frameNum - 1)
<Tobi> although I don't really care, but that seems like a good fix to my problem that doesn't break too much :)
<hoijui> woops... hello
<Tobi> hey
<Tobi> I just ask a sort of pre-meeting question (although I put it in agenda)
<hoijui> *** repeated what Kloot missed ***
<hoijui> abma will not come
<Tobi> the problem with the current behaviour is that any engine code called from within GameFrame will see the stale frameNum
<Tobi> so for example EmitSfx'ing a CEG in GameFrame has ttl 1 lower than specified
<jK> oh
<Tobi> possibly same for other things though I didn't really check
<hoijui> maybe just change it, and see what happens? :/
<Tobi> ya I will
<Tobi> not even sure it will really fix it, the EmitSfx thing might remain simply because GameFrame runs before PH
<Tobi> master is supposed to be quite broken right?
<Kloot> ya, there is a memory corruption bug somewhere in sound code
<Tobi> hmm I didn't even notice that yet :)
<Kloot> in that case I'm worried about what I didn't notice
<Kloot> if it qualifies as quite broken :]
<hoijui> :D
<jK> eh?
<hoijui> what is broken for you, Tobi?
<Tobi> first disclaimer: I didn't build spring in quite a few months, so some things might simply be broken on my end
<Tobi> or some things might be features :)
<Tobi> I noticed F11 doesn't pop up widget selector in S44 anymore, while it does in same S44 in latest release
<Tobi> actually LuaUI looked completely not present, but there wasn't any error in infolog
<Tobi> the other thing I noticed was way too bright lighting on Aquatic Divide (could be map bug?)
<hoijui> (i have not run master spring since some weeks either)
<jK> that's the dynsun bug mentioned in earlier meetings (possibly caused by another commit in the same timerange)
<Tobi> and imo the scrolling direction for middle click scroll is broken but I guess that was discussed long ago already <_<
<jK> was it?
<jK> don't remember to saw a commit with that change btw
<Tobi> really quite a while ago I think
<Tobi> also released iirc
<Tobi> but I'll figure how to set the speed to a negative value
<jK> was just the default value changed?
<jK> or was the code itself changed?
<Tobi> no clue, I just notice that its counterintuitive everytime I run spring
<Tobi> i.e. move mouse to right, camera moves to left
<Tobi> ofc map moves to right, so in that sense it could be considered correct
<Tobi> minor things tho compared to LuaUI not working.. although I suspect that is a configuration problem somewhere (assuming you don't have it)
<Tobi> so just ignore me for now and do the other parts of the meeting

main points:

• Tobi will make a change to Update gs->frameNum before calling GameFrame call-in; already done by now in: https://github.com/spring/spring/commit ... 2034298a16

assimp merge?
related forum thread: http://springrts.com/phpbb/viewtopic.ph ... 47#p477147
<jK> any volunteers?
<hoijui> abma and me tried it... it looks good for us. (it compiles, git history is ok, CMake stuff is ok, the test mod runs)
<jK> as long as it doesn't fail terribly, merge it imo
<hoijui> i cant say anythign abotu how the stuff is done, ..
<hoijui> mm ok
<jK> any smaller bugs can be fixed later
<hoijui> true yeah
<jK> making those commits know will make them sure more obfuscated
<hoijui> there are really few changes to already existing source files
<jK> *now
<hoijui> mm
<jK> -sure
<hoijui> i can do the merge
<hoijui> next?
<hoijui> should i ask spliff if he want to be an engine dev?
<hoijui> that would sure be ok with me
<jK> kloot might ask: "what happens with my obj loader code?" -> iirc in the froum thread it was noted that it's keeped atm (still deactivated)
<jK> spliff said already that he had enough of c++ for a while
<hoijui> yeah, he did not remove anything
<hoijui> ok :D

main points:

• hoijui will merge Spliff's assimp-rebuild branch into master

do we want librocket?
related forum thread: http://springrts.com/phpbb/viewtopic.php?f=21&t=25589
<hoijui> .. though he also siad he woudl probably do this
<jK> -1
<hoijui> +1
<hoijui> i guess you see no need for it, jK?
<jK> also the forum thread seems quite redundant to me, because 99.9% of the ppl there don't know _anything_ about chili
<jK> also I smell an anti-lua complot
<Tobi> lol
<jK> ^^
<hoijui> :D
<hoijui> well.. i know that if i want to write a simple GUI for a widget, and i dont want it to run in every mod, i have to write my own lua stuff to draw buttons and such
<jK> not true
<hoijui> i read that chilli can be made to run as widget
<jK> chili is done as an api and should work fine with any other GUI (lolUI, iceUI, ...) as long as they aren't doing strange stuff
<hoijui> but that is not what i want to do, and if the mod itsself uses somethign else hten chilli, it is also not good
<jK> only problem currently is that it needs a modified widgethandler
<hoijui> ok
<jK> but I am working on a new one for some while now
<hoijui> could librocket be integrated into chilli? :D
<hoijui> nonsense
<hoijui> but well ... you should try to explain it in the thread then
<jK> so with 0.83 widgets & gadgets should be game independent and work everywhere w/o modifying the handler
<Tobi> wrt librocket I think the reuse existing designers is a decent argument, although I don't know how well website design transfers to game ui design. doesn't really seem like the same domain to me :)
<hoijui> if everyone would be ok wiht widgets using chilli for GUI, even if they use other GUI stuff in theri mod, it would be a viable alternative to me
<Tobi> otoh I'd personally prefer less features at a higher quality
<Tobi> (i.e. in the engine project as a whole)
<hoijui> yeah.. that argument will probably always be a pro oof librocket over chilli, though to me personally it is not important...
<hoijui> does chilli have some sort of separation like HTML + CSS?
<jK> not yet, but planned
<hoijui> and is the HTML part similarly easy like HTML?
<hoijui> ok
<jK> and it near when not more flexible than css
<jK> +is
<jK> (for positioning gui elements)
<hoijui> mm
<hoijui> well... for my example, the guy writing the widgets Lua logic (non GUI) nad the one writing the GUI (HTML part, not CSS part) is the smae oen anyway, so he has to know Lua, and would only have to learn chilli
<hoijui> and i guess it is not muhc more complex then HTML, for basic stuff
<jK> adding xml support isn't a problem at all, still when I see all the xml implementations in WOW & unity ... wuah
<Tobi> xml implementations?
<Tobi> don't they just use stock xml libs?
<hoijui> meaybe he means the interfaces?
<jK> I mean their GUI structure format written in xml
<Tobi> ah
<hoijui> yeah.. i guess this can go on in the forum maybe, in spiffs thread
<hoijui> so we are done for today
<hoijui> would be
<Tobi> ah one other noob question: can one now give orders to units in GameFrame(0) ?
<jK> never encountered any problems like that, neither explicitly remind doing so
<Tobi> ok

main points:

• this needs reevaluation in the forum, due to new info given by jk that chilli will likely be extended in the future to overcome some of its shortcomings over the librocket approach

[AF]

You completely glossed over my mention of Berkelium? No XML files, no custom flavour of css/html, just a full webkit browser, with all the features and optimisations of Google Chrome, and a full javascript engine, and html5 video etc.

If someone wants to build a UI from scratch, they're forced to learn opengl basically. There's nothing stopping with berkelium from using photoshop and a copy of dreamweaver to develop, and using a normal install of google chrome to do their development. No reloading all the lua etc, no engine anything, and access to a huge amount of debugging tools, firebug/dragonfly/webkit inspector.

With Berkellium, there's a JS api from C++ and classes to allow compositing to an OpenGL texture/rendering context. You can then put the rendered webpage wherever you want and manage its updating/redrawing and input as you'd like.

Just imagine, a kbot lab with a panel on the side showing a working google homepage XD

[FLOZi]

I'll cast my lot in with Chilli and a -1 to librocket (not that my opinion on this has any relevance whatsoever )

[smoth]

<3 chili but honestly don't know where I stand with librocket. Would it be possible to steal the html support from librocket and add it to chili? I mean if the licenses are compatible then possibly the logic at least could be stolen?

[SpliFF]

@AF: Glossed over? I made it pretty clear it's too big. TOO BIG! Spring is not a goddamn web browser! There's a perfectly good reason why librocket cuts back from even attempting a full HTML5/CSS3 implementation.

How are you going to feel when Spring doesn't compile and/or runs like crap because some idiot embedded a web browser in it? Show me one live action 3D game that comes with a builtin HTML5/CSS3 browser and Javascript engine.


@Everyone else: As far as the Chilli vs librocket thing I don't understand why people think there's even a decision to debate. The assumption that chili and librocket are mutually exclusive is based on what exactly?

Perhaps it's the fanciful notion that Spring devs will stop working on chili in favour of librocket? Which devs would that be exactly? From what I can tell the only dev who works on the engine AND chili is JK and he's already made it plain he wants to keep working on chili. It's a completely baseless argument which in reality appears to be the opinion of people who have already committed to chili and seem to be assuming - based on exactly what I can't tell - that librocket will degrade their game in some way.

It seems like exactly the same kind of crap I got when I suggested existing content should be migrated to Collada+Assimp so S3O/3DO pipelines in the engine could be retired. A little effort by some content devs in order to avoid years of supporting legacy crap in the engine. Except this time I NEVER said anything about retiring chili or removing any single piece of existing functionality.

The ONLY issue is whether librocket will degrade the engine in some way and right now that is totally unknown. The only way to know is to try it. The only issue is whether anybody will.

[smoth]

neither flozi nor I said anything remotely like that spliff.

[SpliFF]

Jk's comments in the meeting (a question about librocket immediately became a discussion of chili) and FLoZI's post implies there's a vote going on between librocket and chili. Your post happened while I was typing mine, I wasn't responding to it directly. The suggestion that developers should work on chili rather than librocket was made in the librocket thread. As I said it isn't clear to me why the discussion of librocket involves chili (or iceUI or redUI or anything else).

I can understand why people who have already written a chili-based GUI would have no interest in librocket. What I'm trying to establish is why they would then feel the need to vote against an alternative that other people might use when none of the impacts of the library on the engine are known at this time. It seems like more of a religious war thing going on than a sensible debate.

[hoijui]

the way i see it (and i think jk too), is that if chilli will have all features that librocket would bring, there would be no use for librocket anymore, and then the time spent to integrate it (most likely your time, spliff) would be wasted. not necessarily for spring, but for sure you.
to me it was clear, that librocket has quite some benefits over chilli, but with the info (new to me at least) that jk gave in this meeting, this may need rethinking. i do not understand this outcome as we do not need librocket, i just though this might also be news to you, and maybe you would also have to reconsider if you would still want to use librocket for your own project(s).
in the end, it comes down to what you already said...
if you do the work, and it does not vastly complicate the engine, i don't think that there will be a veto form the engine devs.
We still have OSC support in, which was never used by any public project at all, but it does really not hurt, as it does not cause any pain really, and is very loosely coupled with the engine.

[jK]

@Spliff
We had something similar already:
Auwaschbar wanted to implement his own GUI framework in c++ for the mod/map selector when starting the spring binary w/o a script.txt. I told him multiple times that we already got chili and other frameworks and we only need a new Lua instance running pre-game for it.
But he wanted to add his framework no matter what ...
Now we got his AGUI for the startscreen, and what? Yeah it is a bit nicer, but it isn't modular nor is it seen by 99% of the players (you just see it when starting the binary directly).
So I am still forced to implement the LuaLoadScreen/PreGame instances, which make his AGUI 100% redundant!

So if you want to work on the engine then don't do things twice! There are more than enough things ppl can work on.

[hoijui]

well... i cant see how you have shown that librocket would be 100% redundant soon. this post is explaining how you see it, but you do not give out the information that is required so others could see your reasoning.
librocket would be better then chilli, even after what is planned (as much as we (the public) know) is done, in these aspects:
* it uses a sub-set of HTML + CSS (compared to eg. a custom XML format), which is well known/needs no learning/has lots of editors
* it is always available under all mods, without having to bundle the framework in the widget, or in an additional widget, or risking conflicts if each widget uses its own bundled chilli version
* is probably easier to implement (comparing integration of librocket and add the mentioned, planed stuff to chilli)

maybe it is a total waste, but with what you told us so far, it does not look so, and even the info we have now did not come out easily from you. you only came out with it through the meeting, not in the forum.
maybe stuff like this is why Auswaschbar wanted to have better communication (among devs).

[zwzsg]

gl.Rect(x1,y1,x2,y2)
gl.Text("Blah",x1,y1)

zomg you got custom GUI!

I would say Spring default Lua OpenGL command are enough to build your own GUI. Framework are supposed to help you make complex GUI faster, but in practice they just make think overcomplicated.

Auwaschbar wanted to implement his own GUI framework in c++ for the mod/map selector when starting the spring binary w/o a script.txt. I told him multiple times that we already got chili and other frameworks and we only need a new Lua instance running pre-game for it.

Yeah, +1. I really wish Auwaschbar had added a customisable pre-game & loading Lua instance instead of hardcoding his menu.

[CarRepairer]

gl.Rect(x1,y1,x2,y2)
gl.Text("Blah",x1,y1)

zomg you got custom GUI!

I would say Spring default Lua OpenGL command are enough to build your own GUI. Framework are supposed to help you make complex GUI faster, but in practice they just make think overcomplicated.

Not really...

myWindow = Chili.Window:New{ x=x1, y=y1, width=w1, height=h1 }
Chili.Label:New{ parent=myWindow, caption="BLAH" }

[zwzsg]

Also a framework like Chili add tons of functionality like moveable resizeable nested windows that keep their setting and etc... that would like loads of times to redevelop.

But my point was that I'm not convinved adding librocket would make it easier for fresh modder to make custom GUI, as they'll just be a little more confused about what needs to be done.

[Forboding Angel]

Also a framework like Chili add tons of functionality like moveable resizeable nested windows that keep their setting and etc... that would like loads of times to redevelop.

Librocket does that from the getgo irrc.

[Licho]

Chili GUI does not have problem with designer unable to do work atm!

It has problem with coders being unable to make sensible widgets :)

Chili already has plenty of skins and its easy to switch them. To make new skin you only need someone with photoshop skills who knows how to match and mix colors.

Librocket seems like a waste of work.

Who will convert existing widgets to librocket and why would anyone do that?

Making GUI for existing chili framework took ZK team full year. About 0% of that time was "design", because chili already had several nice skins. If someone wants to make new GUI with new framework he might need to spend similar time + some design time. I don't see that hapening in foreseeable future considering how lua active various projects are.

Finishing assimp sounds MUCH more valuable both short and long term.

[hoijui]

assimp is quite finished already, that is why we decided to merge it.

if there was ZK only, indeed librocket would not make sense at all.
the idea never was to convert existing stuff, but to make work easier, especially for widget devs, or game devs that start from scratch and prefer the librocket approach over chillis.

[AF]

[Pxtl]

Not a stakeholder, so I can be safely ignored - but if I had to choose between getting lua access to bones in Assimp models so we can get scripted skeletal animations and finally have real organic models vs. supplying an easier way to make GUIs, I'd take animation in a heartbeat.

But that's just me.

[knorke]

I dont think its a question of chosing between animations or gui

Who will convert existing widgets to librocket

why would anyone do that? It would be for new games. (<-haha as if)

[SirMaverick]

What I'm trying to establish is why they would then feel the need to vote against an alternative that other people might use when none of the impacts of the library on the engine are known at this time. It seems like more of a religious war thing going on than a sensible debate.

You want to add librocket. I loled at that bloat but didn't care further. Somehow some vote cam up, we have to decide between the two.
Now you talk about unknown impacts. Unknown as in content devs don't know weather they have to redo their GUIs from scratch?

You just wanted to add a feature to the engine? Change your marketing!

the idea never was to convert existing stuff, but to make work easier, especially for widget devs, or game devs that start from scratch and prefer the librocket approach over chillis.

SpliFF, that's how you communicate/sell it.

@AF
Several reasons why your post doesn't contribute anything to the discussion.
1. google returns result for "chilli documentation", as do other search engines
2. it's called "chili", single L
3. chili doesn't have a website and doesn't need one as it has afaik no use outside spring
3.a) ppl make random claims about it - so it's well known inside spring community
4. this listing is less biased than your screenshot
5. it's an one man project (some other ppl contributed) that has about 5 costumers
6. it's documented via source code and examples