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 2010/4/4 Mitchell Stokes <[email protected]>: >> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
