Portalized (GUI update)

[nullsquared]

The real question I wanted to know was what happened once one was detected? A game over screen, or maybe a simulated tear in space-time (which is the ultimate portal I suppose)?

Well, since the game knows the history of all the objects, if a paradox is detected, time can reverse until the player is back to when he entered the time portal, and he can be told to avoid the paradox.

[Praetor]

Oh that's a good idea. Reminds of Sands of Time, back up try again.

[mkultra333]

After you lay down the second time history, you could have the option of going back and changing the first one, overwriting it and having to avoid paradoxes with the second history. Allow the player to add as many time histories as he wants, plus re-write already existing histories. I don't know, might work, might not.

Be an interesting two player game, where they are competing at completing some goal and take turns adding new histories, always having to avoid paradoxes.

[nullsquared]

See OP for an update involving me blabbing about the GUI in Portalized (another GUI wheel has been reinvented)

[subquantum]

That's really sweet, especially how you've got it working through Lua. If I've guessed right how you're doing it, that's a really elegant system. Does lua handle the drawing at a low level too, or does that call to Update on the gui sheet change some state in C++? It looks like you do a -lot- in scripts.

[nullsquared]

Actually, the widget system has a very generic "update" method that takes a parameter name and a boost::any argument. It's not exactly the safest thing around, but if you try to pass an invalid or incorrect parameter it'll just log an error. Anyways, this maps out to Lua very nicely - you simply pass a Lua table to a proxy update() function, which then iterates over the table and calls update(key, value)

Come to think of it, the GUI doesn't really know anything about Lua. To bind a Lua function as a callback to a GUI event, I just use a proxy function and boost::bind, like so:

Code: Select all

void proxyWidgetCallback(const gui::event &e, luabind::object luaCall)
{
    luaCall(e.caller, e.misc);
}

void proxyUpdate(...)
{
    for (...)
    {
        if (type(value) == LUA_TFUNCTION)
            widget.callback(key, boost::bind(&proxyWidgetCallback, _1, value));
    }
}

And that lets you do stuff like:

Code: Select all

someButton:update({
    onClick = function(this, misc)
        log("clicked on button " .. this:name())
    end
})

[jacmoe]

Wow, Nullsquared - you're blowing me away!
When I see you in action, I come to think of a young Carmack.

[KungFooMasta]

Don't worry about offending people. Writing your own solution allows you to easily make additions and changes whenever you need it, instead of digging around and making another solution work for specific scenarios you want to support.

IMO, what your GUI is really missing are transition effects. For example you should give some visual feedback when you hover over widgets, something simple like the button enter/down/leave events should show different graphics to feel more interactive.

[nullsquared]

IMO, what your GUI is really missing are transition effects. For example you should give some visual feedback when you hover over widgets, something simple like the button enter/down/leave events should show different graphics to feel more interactive.

Like I said, it's barely done yet