We need a simple way to attach the mouse to the camera about pi3d HOT 5 OPEN

It would be good to pull all the movement code out into a library, with hooks back into the application to allow the movement to be overruled. That way we can have a consistent user interface that works with mouse, keyboard and gamepad/joystick, and can be customised.

It would mean that the demos would lose a lot of excess wordage, leaving just the interesting stuff.

It would work well with first-person, but third-person requires playing with the camera position to avoid trying to look through walls. There are simple fixes, but even they add complexity and require knowledge of the surroundings.

from pi3d.

Well, there seem to be two styles of usage of interfaces, both of which appear in the demos.

There's the case where you get specific events as they happen - for example, you get a "K pressed" command. This could be handled with a callback.

But there's an alternate way of doing things where, in your update loop, you check to see e.g. what key is being pressed. This is more what you want for video games - you want to keep going forward as long as you press the "forward arrow" for example.

Setting an autorepeat isn't the same - you really don't want multiple key events, because they won't match up with your poll cycle.

from pi3d.

See my comment to #47
This can be easily arranged using a key handler function in InputEvents.
The InputEvents object has a dict giving the current state of every key and every button on every conceivable device, so that matches your second requirement. However every change of state also calls a callback, and that callback can filter out everything but the key-down event and pass it to an event buffer for the main loop to read. (It is part of the main loop too, not a separate thread, so it could just action it.)

from pi3d.

Oh, right on!

We need to be a little careful about CPU consumption here (rare for me to
say in a project!) as the keyboard scanning code is called every frame, the
RP is not particularly speedy, Python function calls are fairly expensive,
and we've noticed fairly large changes in frame rate for even small
optimizations and pessimizations.

But - correctness first, speed second!

On Tue, Jan 15, 2013 at 1:46 PM, rurwin [email protected] wrote:

See my comment to #47 #47
This can be easily arranged using a key handler function in InputEvents.
The InputEvents object has a dict giving the current state of every key
and every button on every conceivable device, so that matches your first
requirement. However every change of state also calls a callback, and that
callback can filter out everything but the key-down event and pass it to an
event buffer for the main loop to read. (It is part of the main loop too,
not a separate thread, so it could just action it.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-12282482.

 /t

http://radio.swirly.com - art music radio 24/7 366/1000

from pi3d.

It's fairly efficient at the moment. The state is fetched from a dict keyed with a small integer. There's a call there, but we could make it a single call per frame at the expense of adding complexity to the API. The event occurs at the key repeat rate.

There is a select call every frame, which could take significant time, but we could throttle that back if it proved to be a limitation without losing events.

from pi3d.