Ois buffer and non-buffer input mode

Many people on the Internet have said this kind of problem, but I always think some of them are inappropriate. So I tried it myself.

Below are the notes:

1. Only buffer Io can be used for keylistener/mouselistener,

That is, the listener set by keyboard: seteventcallback.

2. When I/O is buffered, two events are detected: pressing and releasing.

3. Separation of Io events and frame rendering facilitates management, but easily leads to redundancy.

You can set mylistenerdata to a friend of the listener to share data (such as frame | key | mouselistener) and encapsulate attributes in mylistenerdata.

4. Implementation class:

Mylistenerdata: data related to control attributes (note that this is control information, not entity information)

Mykeylistener: operations related to key control

Mymouselistener: operations related to mouse control

Myframelistener: operations related to rendering of each frame

If the keyboard is set to non-buffered, the listener set for keyboard: seteventcallback () does not work. Similarly, if you set the mouse to be unbuffered, the mouse callback function will also fail. In this way, only related control operations can be performed in real rendering, which may lead to unclear Design of classes.

Because the mouse-and-mouse listener always detects the button status, the process changes such as movement and rotation, and the instantaneous changes such as button switching are different from the processing of non-buffering and frame rendering events. Therefore, the mouse listener always processes the press and release events to change the status. Unlike the frame event, you only need to consider whether to press the key. For this reason, three different time states of framestated/framerenderingqueued/frameended are available for processing. For example, if a variable needs to be 1 when the mouse moves, otherwise it is 0, you can set 1 in mousemoved and 0 in framerendingqueued, I don't know if the next frame of the mouse is still moving.