[Bf-committers] Patch for BGE Keyboard and Mouse Python types

Campbell Barton ideasman42 at gmail.com
Tue Apr 13 22:04:11 CEST 2010


On Tue, Apr 13, 2010 at 9:23 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
> Hi Mitchell,
> 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)
>
> Dalai

+1 for Dalai's suggestions, though I'd like to make sure we take care
when adding another method to access events.
Assume 'events' includes events since the last logic tick? (as opposed
to accumulating events and having the developer remove?)

> 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
>>> opinion.
>>
>> 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
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list