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

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

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

... but now you're satisfied?  :)

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

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

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

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.

> 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.
>
> 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 think something along these lines could work.

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

Now as for actually presenting a UI, or handling key-configuration 
preferences in storage, etc. etc. yes external objects are entirely 
appropriate - and the same external object is useful with a variety of 
ActionFlags objects.

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

Right, just as classes don't mean OO.

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

True.  I was interested in learning about Cocoa for quite some time, but 
did not really get into it until I actually had a project to work on.  
(Once I did, though, I got spoiled fast.  ;) )  OTOH I might have become 
a real Java convert if I had worked in it much (and if most Java 
resources out there weren't about putting some cutesy animation on your 
Web page).  It seems to have many of the nice features of Cocoa, _plus_ 
a built-in strategy for limiting the capabilities of code (not just the 
'sandbox' restricted-applet idea, but the fundamental design with the 
SecurityManager object).  But, I never really got to know it as well.

> 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 honestly don't know how many threads we may have going on.

All the more reason to have separate queues for separate tasks.  :)

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

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.

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

Woody