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

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

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

> On Sunday, January 26, 2003, at 04:10  PM, Br'fin wrote:
>
>> On Sunday, January 26, 2003, at 01:08  PM, Woody Zenfell, III wrote:
>>
>>> 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.
>
> ... but now you're satisfied?  :)

Doubtful, but we're making progress. :)


>> 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.
>
> I think they were originally implemented that way because
>
> 1)  Bungie knew they could fit everything they wanted to into a 32-bit 
> value
> 2)  Copying 32-bit values is easy
> 3)  So why take more?
>
> I'd tend to think that we don't know how much storage someone using AM 
> will want for their ActionFlags at some arbitrary point in the future. 
>  So it makes sense to me to completely hide the storage inside an 
> object.

That part is fair enough to me. Right now I don't think there's even a 
typdef for passing the flags around, it's just an int32.


>> 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.
>
> So custom scenarios are generally going to have to provide a custom 
> build for every AM platform?  And scenarios won't be able to take 
> advantage of later AM enhancements because they've broken away from 
> the trunk?

Well, at the point where they are adding custom flags you have someone 
who needs the inputs and knows how to add the corresponding control 
code to the other end of the game in the game core.

You also have someone who is doing significantly more work than 'just 
another scenario'. Since scripting isn't even on our table yet (too 
many other things going on) there is no way to utilize new flags 
without compiling support into the game.

I want to support this kind of beyond the scenario development. But we 
need to recognize it as that as well. They've forked the project to 
build off of and develop their game. It is up to them to keep track of 
further AM development and fold it into their version of the project 
should it fit their needs.


>> 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>.
>
> You could compile in (via templates) support for various vector<> 
> instantiations, wrap them in subclasses of some superclass, and have a 
> factory dish out various subclass instances in the guise of a 
> superclass pointer.
>
> All that said, it may prove to be significantly more straightforward 
> _to_ use pointers.  Shrug.  Just pointing out that there is an option.

That just sounds like it getting out of hand. :)


>> 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)'
>
> Whereas it seems perfectly natural to me to think that nobody knows 
> better what an ActionFlags object is capable of representing than the 
> ActionFlags object (or its class - but the general lack of support for 
> runtime class stuff in C++ is quite a liability).  How is an external 
> object going to know?  Does someone have to match the correct external 
> object to the correct ActionFlags object?  Why make them do that?

I think part of it is just my point of view. I see there being two main 
components. The ActionFlags itself being a carrier of information (And 
being really dumb about what it carries, mind you) and the encoder of 
the information, the object that creates new ActionFlags based on the 
current input. The encoder in this view isn't any old external object, 
its tied to the Action Flags.

The ActionFlags itself would be fairly dumb. Somewhere in a class 
shared by all action flags is this lookup table. Masked lengths and 
shift values for each index (flag)

	Actionflags flags;

	flags[_trigger_1] = 1; // 1 bit value
	flags[_absolute_positioning_yaw] = 1; // 1 bit value
	flags[_absolute_yaw_value] = 30; // 7 bit value

With an implementation just for cramming values in.

Another object (the ActionFlags configuration reader? The encoder?) 
would be responsible for building that lookup table and perhaps have 
more description information. Labels or tool tips for each field and 
the like. Things irrelevant to the flags itself, but useful for setting 
up the encoder or showing the user the options to control.


>> 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. :)
>
> Believe it or not, I never had any classes on object-orientation... so 
> I didn't "get it" until much later, principally from the two sources 
> cited.  :)  Please try to take my comment about learning about OO in 
> this context, rather than as some kind of slight or something.  (But I 
> think you did anyway.)
>
> Of course I still probably don't *really* "get it", I just think I do. 
>  Sort of like before.  But I get it better now than I did before.  :)

I think part of the reason why I'm kicking myself now is that I didn't 
really grasp the notions at the time. So I've been exposed to them, I 
know they're out there, I've read some of the materials, but am still 
wrestling with trying to understand the OOAD and apply it.

>> I honestly don't know how many threads we may have going on.
>
> All the more reason to have separate queues for separate tasks.  :)

Heh, accepted.

>> For decent Carbon control, I already feel a need to be able to invert 
>> the relation of input thread and rendering/game update thread.
>
> This is because, essentially, parse_keymap() cannot be implemented in 
> a way that will work in the non-main thread?

Yeah, between the mouse and the issues with get_keys. Mouse polling 
latched to rendering speed kills all the smoothness when frames drop.


> If the problem's principally with the mouse control, it might be 
> interesting to see how SDL (I mean SDL at least as much as A1/SDL) 
> does it.  IIRC the A1 Carbon version had this problem where the 
> pointer could reach the end of the screen and would refuse to go 
> further... but the Mac OS X SDL version had no such problem.  At the 
> least, in the Carbon version I'd end up starting Screen Effects a lot 
> which was not a problem in Mac OS X SDL A1.

SDL might have already discovered such effects and might already have 
yet another thread or way of separating the carbon based input with 
where it's needed. Hmm, I don't even know which set of libs SDL is 
using. Might not be using much of Carbon anything at all...

The screen effects stuff is more likely my fault. In A1/Carbon, the 
mouse is tracked via mousemoved and mousedragged events. Which have 
full deltas even if the absolute position of the mouse is crammed into 
the bottom corner of the screen. I do know how to warp the mouse 
position, but I don't think that's in the current A1 code.


>> 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)
>
> This is exactly right.  In fact, there's a fourth task, but it doesn't 
> run all that often.
>
> In any circumstance, you at least have:
>
> Main thread - update/rendering
> Periodic task - capture input (or, in film playback, just move it from 
> the recording_queues to the player_queues).  In a netgame on the 
> server, this may also send out network packets.
>
> In netgames you also have:
> Reactive task - runs code in response to packet arrival (often results 
> in packet send)
> Periodic task - resend unacknowledged packet (in practice this is 
> usually reset - in response to getting an ack - before it gets a 
> chance to fire and run)

Ahhh, ok then.

-Jeremy Parsons