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

[Woody Z. I. <woo...@sb...>]

On Friday, January 24, 2003, at 01:29  PM, Br'fin wrote:

> 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.

Yeah simple, the code that handles a replay examines the file, 
determines that it's a "traditional" film file, and sets up to use the 
MarathonFilmUnpacker.  Same deal on output (just use a 
MarathonFilmPacker, which writes M2-compatible films, when starting up a 
MarathonGame).

> 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.

Like I said, other (per-platform, presumably) objects can help take care 
of the translation of input to 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)

I believe the ActionFlags are pretty well used up in "normal" mode.  In 
"terminal" mode there is probably still plenty of room.

>> 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.

Why?  If the ActionFlags class is what knows which sorts of things it 
can represent and what types of values it can store for those things, 
why should it not be able to share that information with some kind of UI 
configuration object (which builds the configuration dialog/etc. based 
on what the ActionFlags class says)?

>> 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 :)

Good question.  Probably not too big though I would guess.  I mean, 
maybe you have to pay an additional 32 bits for a vtable pointer or 
something?  OTOH the benefits are many, I think - different ActionFlags 
representations, switchable on-the-fly, without any chance of getting 
them mixed up.

>> 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.

Well, where needed, of course.  One of the principal features of a 
circular queue is that a single enqueueing thread and a single 
dequeueing thread can safely communicate through it without any locking.

>> 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.

I'm not sure what you're saying here, or how it differs from what I 
suggested or how it differs from the current state of things.  (FWIW 
what I suggested is very close to the current state of things, overall, 
just cleaned up and modularized where possible and seemingly useful.)

> 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'

Yeah this is a restatement of what I suggested, right?

> I'm curious as to what you mean by smearing.

When the network code needs action_flags for the local player to share 
with the other machines (on ring packet arrival), but the local 
NetQueueingTask() (which is the Input Capturer) hasn't yet queued up an 
action_flags on the LocalQueue, the network code goes directly to the 
Input Capturer to get action_flags to fill in.  My suggestion lets the 
network code effectively make up those action_flags on its own, based on 
its recollection of the most recent action_flags it had for the player 
(and on the ActionFlags's GuessNextFlags() routine), so the Input 
Capturer's code doesn't have to worry about threading problems etc.

I think my overview of networking and input covers the role of 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'?

In this context does "thread" mean "discussion on the list"?

I think the current timing characteristics of M2/A1 are right on, but 
I'd be willing to listen to other suggestions.  (Moving to client/server 
may alter the desired timing, for example.)  I'd ask anyone planning to 
participate in the discussion to read my overview of the current input 
system at 
http://source.bungie.org/_enginedevelopment/reference/networking-
input.html

If the game core can't update faster than 30fps, we're hosed (if we're 
planning on playing in realtime that is ;) ).  There's no way around it.

OTOH not being able to render at 30fps is (obviously) ok.  And transient 
bubbles in the scheduling of the other elements are absorbed by the 
queues.

Ok, to make things clearer (maybe), I've created a PDF diagramming the 
flows of action_flags in a networked game, a single-player game, and in 
film playback.  (It illustrates how Marathon/A1 do it, which is the same 
way I am picturing things working for AM, albeit more loosely tied 
together and perhaps with different routines actually doing the work.)  
I'm sending it to Jesse and asking him to post it at s.b.o.

Woody