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

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

On Sunday, January 26, 2003, at 01:08  PM, Woody Zenfell, III wrote:

>> 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.
>
> Right, Tim is right on, sorry I thought it was pretty clear how it 
> would work out.

I know I'm being a pest about it.  But no one (myself included) seems 
to have explicitly jotted anything down in terms of mixed file support 
Replays are just one case.

> An ActionFlags object encapsulates one player's inputs for one 
> game-tick.  That is my definition.  With 'inputs' here meaning 
> anything that affects the course of the game (i.e. helps to determine 
> a game-state).  (Thus, things like changing the sound volume on the 
> local computer have no business being in ActionFlags - and of course 
> they're not, at the moment.)

Agreed upon on the 'out of game' keys.

>> 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.
>
> Compact and concise may on may not be important.  Packing the flags 
> for film files or network packets etc. should produce a concise 
> representation to save disk space or packet space, respectively.  But 
> I don't see any particular reason they need to be concise within the 
> game engine.

Much of my reasoning for compact and concise is that the action flags 
were implemented initially as flags on a 32bit word. And I would think 
they were implemented that way for a reason. AM is probably going to be 
a touch thicker and slower than the original code design. But I would 
prefer more of the processing to go towards the rendering and gameworld 
updating of things. Please read on by the way.

> Well you're right, if there's a strict lineage of 
> less-powerful-to-more-powerful (in terms of representational ability) 
> ActionFlags objects, then yes anything done in one representation can 
> be done in the most recent (and thus most powerful) representation.
>
> But if one person takes AM in one direction, and develops his own 
> ActionFlags representation with, I don't know, 'spitting', and 
> somebody else takes AM in another direction and has ActionFlags for 
> 'levitation', how do you handle that?  It seems obvious to me that 
> when AM is playing the 'spitting' scenario, it uses the 
> 'spitting'-capable ActionFlags.  When AM is playing the 'levitation' 
> scenario, it uses the 'levitation'-capable ActionFlags.  It seems 
> quite useful to me to allow the type of ActionFlags to change.  
> (Though as noted in my other message, it doesn't seem useful to me to 
> have different ActionFlags types in the course of a single game.  Thus 
> queues can depend on holding homogeneous ActionFlags.)
>
First, we don't have one person taking AM in one direction and someone 
else taking AM in a second direction.

Secondly, they are more than welcome to fork AM and create their own 
project tailored for their game and needs. If one project has feature A 
and another has feature B. Neither necessarily has to be folded into 
the main codebase.

Thirdly, my current impression is there's too much 'hard coding' in 
your thinking of ActionFlags. (Again, continue reading, I have no idea 
where to group my proposal around this)
By 'hard coding' I mean explicitly putting everything into the 
ActionFlags or subclasses thereof.

>>> 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.
>
> 1.  Who ever said anything about storing pointers?  I was picturing 
> the queues etc. storing the ActionFlags objects directly in their 
> chunks of memory, a la STL vector et al.  This is possible since every 
> ActionFlags object in use at a given moment is of the same type.

AM, is, alas, C++. To my knowledge C++ starts breaking down when you 
start trying to pass a subclass by value to a class expecting the 
master class. I think this is why Java implicitly treats every object 
as essentially a pointer to that object.

I didn't know you could ask for a vector<I don't know what class to use 
until runtime>.


Ok, here's the point I was asking you to read on to:

What if ActionFlags was 'soft coded'. Rather like the physics model, 
where there is a base definition, and then the definition can be 
altered externally to add new controls. So everything uses the same 
ActionFlags object everywhere, but the encoding can be altered by 
changing that definition file.

That also seems to provide a reasonable case for why you would need to 
be generically creating your control configuration lists.

BTW, I'm saying 'file' for lack of a better term. The new definition 
would most likely come from some aspect of the Bios.

I don't find the concept of dynamically displaying available control 
flags and tying controls to them a bad idea, just querying the 
ActionFlags itself to be unusual. Even in this soft code case I would 
lean towards either a separate class or the encoder (parse_keymap (and 
mice!) object) handling the exposition of 'there's flag _trigger_1 with 
name "Trigger 1" and it is a toggle-switch (No mouse or other analog 
input need apply)'

> If you don't see the benefits of object-orientation, perhaps you have 
> not read _Design Patterns_ or worked in Cocoa.  I recommend both; I 
> didn't understand OO prior to them (though I thought I did ;) ).

I agree with the benefits of object-orientation. But they aren't the be 
all and end all of everything too. I don't have a problem applying OO 
to most things in AM, just specific things.  ActionFlags with its 
initial bias to flags within a 32bit word feels like one of those. 
Though I do agree isn't as horrid as trying to fit OO into the heart of 
the renderer.

Also, OO doesn't necessarily mean classes. Marathon has things 
sectioned off (ala portable_files.h/files_macintosh.c) itself.

Unfortunately for cocoa, I only seem to be able to focus on learning 
code when I have something to do in it. AM is certainly being a great 
learning experience. I have read Design Patterns and really wish I 
could remember more of the one class I did take on Object Orientated 
Analyses and Design.

I swear that seemed like the only Computer Course I took in school that 
defined why it was useful to know and I kick myself that I can't 
remember more of it. :)

> Whatever starts up the game 'wires up' flag producers and consumers 
> (which communicate with one another via ActionQueues).  Flag producers 
> and consumers then just do their job with no knowledge of what's on 
> the other side of the Queues it's using.

Ahhh, ok.

>> 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'.
>
> I don't know what you mean by 'dangerous'.  Both are entirely 
> necessary to account for clock drift between machines (and may be 
> useful in coping with changing latency conditions).

Dangerous. As in, with my imperfect understanding of the way things 
work currently, it sounds like it could aid in creating out of sync 
errors. I accept your (and Bungie's) reasoning here.

>> 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?
>
> No, the idea is that any given queue has only one writer and one 
> reader, to keep synchronization simple.  While it may be the case 
> currently that the readers of the RealActionQueue are both in the same 
> thread, and thus have a natural mutual-exclusion property, I don't 
> think we want to unnecessarily bind ourselves to that arrangement.

Ok about the synchronization and the reading issues.

>  And, as pointed out, I don't think we want to protect every queue 
> access with a mutex.  (We have different ideas about what kinds of 
> overhead are acceptable apparently.  ;) )

I honestly don't know how many threads we may have going on.

For decent Carbon control, I already feel a need to be able to invert 
the relation of input thread and rendering/game update thread.

It's my impression with A1 that during network play, the usual input 
thread is skipped, instead relying on a network input thread. For 
Carbon would this then mean 3 threads going on? (rendering/update, 
Carbon input, network tasks)

I admit I could just be being thick.

> Also with each reader (the recording film-dumper and the game-state 
> updater) having its own copy of the flag data, they can operate more 
> independently, each handling the data at whatever rate it feels like 
> without worrying about what the other guy's doing.  For example, the 
> current film packing code waits for something like 256 flags to 
> accumulate in its queue for each player, then writes them out in 
> interleaved, RLE'd chunks.  How would the code do that if it were 
> trying to look over the game-updater's shoulder?  Make a copy of all 
> the flags?  :)  (Yeah yeah this may not be the best way for us to 
> produce our films, but it's an example of a specific use...)

Heh, we really should deal with that, or have a way for the replay to 
say 'last block is shorter than normal' so it can finish off the replay 
properly at point of exit from the game. :)

-Jeremy Parsons