[simpits-tech] KEYSTROKE add on for BMS 0.98

[Mark Doran]

Ahh, isn't English fun...sorry Erwin, but you didn't understand what I
meant! ;-).

That's not what I meant when I said "reliable".  You read far more into that
than I intended.

Previous exe's provided updates to the values in the shared memory (that
would be "writes" from the game side) to the shared memory area that were
not consistent in time.  Some values were updated every frame, some others
only ever if you were looking at the cockpit art presentation of that
element.  Therefore, you could not rely on the values being consistent with
in-game state so it was "unreliable" as a source of data to read for driving
cockpit hardware over time.

That's the problem I believe I've fixed in the BMS code: the full set of
things that are in the shared memory are not updated consistently over time
so plus or minus a frame or so, the state written into the shared memory
matches the internal state data in structures in the game engine.

I can't imagine why you'd want to lock the shared memory from a reader.  You
want the reader to take a snapshot of what's the shared memory.  Given the
timings involved you can ignore the fact that data state might be a frame or
two off in sync terms...guaranteed frame-by-frame sync'ed values ("reliable"
in the sense you see to think I meant) aren't necessary, wouldn't add any
useful function and would be both hard to accomplish and expensive in
resources too.

So I agree, it's already good enough...provided the game side does updates
to every value consistently...and now it does where before it didn't.  This
is an improvement I believe.

Cheers,

Mark.


> -----Original Message-----
> From: Erwin Neyt [mailto:erwin at sim-instruments.com]
> Sent: Wednesday, December 03, 2003 2:01 PM
> To: Simulator Cockpit tech list
> Subject: Re: [simpits-tech] KEYSTROKE add on for BMS 0.98
> 
> 
> <snip>
> 'pit hardware, local or remote (like Erwin's F4DataMirror).  Now that the
> data in the shared memory file *is* reliable full time, well it's a much
> better facility than it used to be.  And yes, there's going to be an
updated
> header file here pretty soon.
> <snip>
> 
> Sorry Mark,
> 
> But that's incorrect, you can't lock the sh.mem for reading , so you never
> sure if the data is reliable.
> But because it is very fast, you'll probably never see the glitches.
> 
> Erwin.