[Bf-committers] Patch for BGE Keyboard and Mouse Python types
dfelinto at gmail.com
Tue Apr 13 21:23:56 CEST 2010
I gave some for thoughts to that.
I think that mouse position should definitively be normalized. Since
changing that for current Mouse Sensor would be a disaster (breaking
old files) I think that if we are pushing the API is the right time to
make it better (according to my definition of better, but well).
My current suggestion is:
1) to have mouse and keyboard as read-only attributes instead of get methods
2) to have mouse coordinates of bge.logic.mouse.position as normalized coords
3) to replace mouse.show() with mouse.visible r/w attribute
If you can make the patch to incorporate that you have my 100% +1
(despite the so called feature freeze I wouldn't mind commiting bge
api improvements. would love to hear from other devs though)
2010/4/4 Mitchell Stokes <mogurijin at gmail.com>:
>> 1) What is the advantage of this over mouse and keyboard sensors?
>> You will still need to check the events every frame and will end up having
>> to reproduce the same functionality present in the sensors (mouse over,
>> mouse click, ...). I may be missing something here.
> The idea is to be able to utilize the mouse and keyboard without
> needing logic bricks to do it. The end goal is to have a Python api
> that does not rely on logic bricks. After that, the logic bricks can
> be redone to use the Python api, which is one of the first steps to
> nodal logic.
>> 2) I was thinking if it would be possible/interesting to have callback
>> functions to be linked with the events. E.g.
>> bge.events.keyboard.addListener('QKEY', quit_function),
>> bge.events.mouse.addListener('LEFTCLICK', mouse_click).
>> Something similar with having the sensor linked to a module, but 100% done
>> in python. That would justify to have the keyboard and mouse exposed in my
> Although my intent was to expose existing functionality and not add
> new things, it would not be difficult to add event callbacks.
>> 3) what to do with the Rasterizer functions? (showMouse, setMousePosition) mark them as deprecated?
> I was thinking this could be done. I find it a lot nicer to handle
> mouse methods through a mouse object rather than a drawing module.
>> 4) bge.events.mouse/keyboard does sound neat ;) On the other hand
>> GameLogic.getMouse/Keyboard() looks odd to me ...
> I wasn't all to certain about putting them in GameLogic, but it seemed
> the most likely place. GameKeys is currently only storing event
> constants, although it could easily have a couple of methods too.
>> * - what about to send normalized values for the mouse position in this patch? even if the mouse sensor uses absolute coordinates?
> Normalized as in 0.0 to 1.0? It could be added as another method. ie,
> either having mouse.setNormalizedPosition() or
> mouse.setAbsolutePosition(). However, I would like to keep absolute
> positioning as an option.
> Thanks for the review,
> Mitchell Stokes (Moguri)
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers