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

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

On Friday, January 24, 2003, at 04:57  PM, Woody Zenfell, III wrote:

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

Given the importance of this, I want more detail than this. This cannot 
be a "magic happens here." I want to know *how* you determine it to be 
what kind of film file it is.

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

One thing that occurred to me is just to start off your document with a 
discussion of the perceived role of ActionFlags to begin with. Just to 
make sure we're all on the same page with what they are and what they 
should be. And what they definitely are not.

To me they are a compact and concise way of passing encoded input data 
to the game engine. I can see how it would be useful to expand upon the 
allowable number of action flags. I haven't grasped why we need to be 
using multiple different kinds of ActionFlags in your queues.

As to UI configuration support, that could be a role for the encoder, 
but seems out of scope for the ActionFlags themselves.

Another thing on ActionFlags. They strike me as something that should 
always be constant for a particular version of the game. There could be 
flags to say 'if in M2 mode, ignore action feature X', but that's in 
the game core and not in the action flag itself. Compatibility of 
things like replays is the responsibility of the replay loader and it 
works by munging the prior ActionFlags into the current internal 
version.

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

32 bits for the pointer to CActionFlags as well. In addition to 
whatever other overhead it being a class adds to the memory usage. This 
appears to be deviating from compact ActionFlags.

>> 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 not sure. Or else I wouldn't have said it like I did. I wasn't 
quite understanding what you had written up before.

>> I'm curious as to what you mean by smearing.
[snip]
> I think my overview of networking and input covers the role of 
> smearing.
>
Ok, just read up on that. Ditching and smearing both look like 
dangerous behaviors. In general I presume whenever this happens that 
the local machine's gameworld is only updated with the final set of 
flags that the network stuff 'found'.

>> 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"?

Yes. Darn multiple meanings of words and network threads on the brain.

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

I don't know if it can. I haven't looked into it. But I would presume 
the 30fps game core is
fairly fixed in the logic and calculations of all the elements in the 
game. I think there's a way to pretty things up so they appear to be 
running faster than 30fps, but it doesn't allow things to be processed 
faster than that.

> 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.
>
Why the distinction between RealActionQueue and the recording queue 
when playing (single or network)? Can't a recording task just peek at 
the RealActionQueue for what it needs?

-Jeremy Parsons