InFine And Doomsday 2.0

DaniJ

<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Blog, Engine, Games, Version 2.0.</i>

Lets discuss the future of InFine and its place in Doomsday 2.0 In my opinion the way forward is to move the "backend" of InFine (i.e., object management and element drawing) into the engine where they can be tied in with stuff like the composite fonts and SVG (plus splines when I get around to it). The script interpreter should obviously be folded in with Doomsday Script but that can wait until after Beta 7.

(Edit) Progress update on this project:
Ok, well InFine is now in the engine and working as it did previously bar a couple of smaller rendering niggles.
<ul>
<li>When ending a game the color buffer is not cleared until the following tic. This is due to the game basically doing "nothing" for a tic other than start the title loop. We have a choice of fix for this; a) update the game state logic to remove the wait b) implement presim or rewind functionality to the finale script interpreter or c) simply draw something in the background.</li>
<li>A similar problem exists when transitioning between the end of intermissions and a finale briefing (note: this issue was present before the move).</li>
</ul>

I've now begun work on generalising the object model used by InFine so that it can potentially be used with the game menu, HUD and other displays. Ultimately the same system will be integrated with the control panel too. Obviously the immediate work will be on making the system suitable for use with the menu and addressing the composite font texture management.

Btw: Something I'd like to see at some point is InFine doing the busy and engine start/shutdown animations.

skyjake

Yes, I think that the current InFine scripts should be only supported as a legacy feature. In 2.0 the script engine will provide access to graphical and other objects that allow creating much more interesting animations. Obviously this is tied to the UI Scripting proposal.

DaniJ

I raised the issue "now" because I'm now in need of a UI object management mechanism for things like the compsite fonts and menu/HUD widget visualizers. I propose that InFine be moved into the engine as-is (adding any necessary callbacks, state vars etc) so that I can quickly wrap up the recent 2D drawing cleanup work.

skyjake

OK, InFine shouldn't be too difficult to move into the engine. How about defining a plugin hook for the "if" command so that the game plugin can check the condition if the engine doesn't know how to handle it?

The biggest hurdle with the UI object management is that it needs to tie into the scripting system *and* the new graphic objects/animations system (neither of which are very complete at the moment in the trunk).

DaniJ

Adding an "if" command hook would be a good idea yes.

With the new UI objects I've tried to keep the visual side as independent from the object model as I can, so hopefully this won't be too big of problem (when both systems are more refined that is).

Something we need to make a decision on though is how UI pages are going to be constructed - presently all UI pages are entirely static (i.e., the number of and position/dimensions of objects do not change). The new game menu and HUD in particular must be able to dynamically reposition/scale UI objects when the main window dimensions change or in response to other objects changing dimensions.

So we can't simply init pages from a set of fixed/relative object coordinates.

DaniJ

InFine has a large (16) state stack however from what I can tell this is never actually made use of.

All Finales are done in Local mode other than anything started while in a map (Overlay mode). In local mode only one script can be active at any time. While overlay mode allows for many concurrent script states, this it is not used because other subsystems have no use for it presently.

Am I missing something or is that correct?

Can you remember why you made this a stack? I see it's elements have members that hold various game state values - do these really need to behave like a stack?

skyjake

I can't remember the exact reasoning for a stack. Probably it isn't actually needed for any of the original games' animations. I most likely used a stack to allow flexibility for custom animations: nested InFines, maybe for some interactive purpose?

As to the size (16), it probably should've been a dynamically allocated stack without a fixed size -- lazy programming...

DaniJ

I can certainly see the benefits of stack-like behaviour however the problem with the implementation is that the controlling logic is part of the InFine system itself (i.e., the game states and condition branching).

Naturally this controlling logic had to remain game-side so I've since re-factored the API and reworked things so that InFine itself does not care about the game state.

So now that its no longer behaving like a stack I'm thinking of replacing it with a simple list (forcing the caller to do any stack-like maintenance as required).

DaniJ

I've completed moving InFine into the engine and *should* now be working exactly as it did previously. It will need more testing and QA but I'm leaving that until the API is final.

Presently this code remains in a private branch because I didn't want to commit yet more half-finished code to the Beta6 branch. Though I could create and switch it to a new branch if you'd like to see it.

Now, lets discuss the design of the API. Things are still a bit messy at present but here is how it looks currently:

On the engine side, the public (exported) parts of the function-level interface is mostly contained in <i>engine/api/dd_infine.h</i> and here are the important bits:

<code>boolean FI_Active(void);
void FI_ScriptBegin(const char* scriptSrc, infinemode_t mode, void* extraData);
void FI_ScriptTerminate(void);

void* FI_ScriptData(void); // Returns a mutable pointer to the engine-allocated "extra" data.
</code>

There are also a few new hooks:
* HOOK_INFINE_SCRIPT_BEGIN = 7 // Called as a script begins.
* HOOK_INFINE_SCRIPT_TERMINATE = 8 // Called as a script stops.
* HOOK_INFINE_SCRIPT_TICKER = 9 // Called each time a script 'thinks'.
* HOOK_INFINE_EVAL_IF = 10 // Called to evaluate an IF conditional statement.

On the game side I've put together a little support lib in plugins/common/fi_lib where the hooks are made and the callback function definitions reside. In addition to these are a couple of functions that deal with (de)serialization (into an "extra" memory buffer allocated engine-side) of the various bits of game state needed client-side.

The <strong>GPT_FINALE2</strong> packets themselves are now (de)serialized engine-side with help from the game-side callbacks mentioned in the above paragraph.

As yet there is no object-level API at all.

DaniJ

HOOK_INFINE_SCRIPT_TICKER is redundant as all it does is stop a script when the game state changes, so it can be refactored away with a game-side mechanism to call FI_End in G_SetGameState instead.

DaniJ

Added progress update to first post.