Re: [Alephmodular-devel] Input architecture (ActionFlags)

[Br'fin <br...@ma...>]

Well, my initial fears of messing with the action flags involve 
breaking the M2 Films. If you're going to talk about changing how the 
action flags are stored, then you better detail how to identify and 
handle replays from different versions of the code. I don't care so 
much if our films don't run under Marathon, but we should be able to 
handle theirs, always.

Input-wise, parse_keymap and other input gathering needs its own 
abstraction. After some of the problems I've had with GetKeys under 
MacOS X (It has a high tendency to just plain not work after you have 
to enter a Keychain or admin password into an application) I want some 
other mechanism in there. This can be separate from translating the 
inputs into the actual ActionFlags.

Also, how much room for growth does the current ActionFlags allow? A 
quick glance seems to reveal 0 currently. (Though I must say I don't 
know what all the bits do)

> It would be nice if the ActionFlags class could help the 
> configure-controllers UI figure out what controls should be configured 
> and what type of input they expect (boolean or numeric, etc.).

Perhaps beyond the scope of the ActionFlags class. but I agree on the 
concept of something converting raw input into an ActionFlags.

> If the frequent use of virtual functions instead of inline code makes 
> anyone queasy, refer to my previous post about optionally selecting a 
> specific subclass at build-time rather than at runtime.
What is the impact/overhead going to be of going to a class instead of 
just going to a 64bit value for more flags? I do accept the value of 
optimization in this case, BTW :)

> Queues would likely be implemented as they are now - as circular 
> queues - to control memory allocation and to simplify communication 
> between a pair of threads.  (Note that one thread must be consistently 
> the 'enqueuer' and one (potentially different) thread consistently the 
> 'peeker'/'dequeuer' - or else that multiple threads trying to work the 
> same half mediate their access on a mutex or something - for this to 
> work safely.)

Aim for the mutex locks, methinks.

> So these elements should all be configurable with "what queue should I 
> read from" and "what queue should I write to"; when starting a netgame 
> or a single-player game or a film replay etc. they're all wired up the 
> way they ought to be.

I don't know about a recording queue per-se. I forget when it's hooked 
into the scheme of things right now (Especially for network games) But 
I think Something along the lines of 'record player quests' for the 
current set of actions before updating the current world based upon 
those sync'd actions is acceptable.

As for the others it seems like when you start a game you setup the 
current 'flag pipe' that every 30 times a second pulls from a source 
queue and throws to the player queues. A replay would be 'read from 
file, pipe to player queues' and a network flag pipe would be 'read 
from input queue, handle networking, put all player flags on player 
queue'

> Random note that didn't fit anywhere else: currently the Input 
> Capturer code (parse_keymap() at the moment, basically, I think) must 
> be safe to run in both the input-capture thread (for normal use) and 
> in the network thread (in case the network code needs a "smear").  
> Using mostRecentActionFlags->GetPredictedNextFlags() for smearing, 
> instead of tripping back to to the Input Capturer directly, makes the 
> scheduling behavior a little simpler and thus probably a little safer.
>
I'm curious as to what you mean by smearing. Or should we just be 
starting up a thread to cover networking, the game core, animation, and 
'what the heck do we do if the game core can't update faster than 30 
fps. and can't even manage that under networked situations'?

-Jeremy Parsons