Additional Miscellaneous Events [Input & Screen Change]

[GenericException]

Key-Press, struct as:

int key //lwjgl const
bool down //event is key-down, false for key-up
bool repeat //repeat events for holding down key

Mouse-Press, struct as

vec2 pos //x,y - typically mouse center for in-game, but diverges for when GuiScreen is open and user clicks slots
vec2 dPos //difference in position from last event
int button //m1, m2, m3 or custom button for advanced mice
bool down //event is btn-down, false for btn-up

Screen-Display, struct as

screen new //screen to display, perhaps can be overridden so users can change existing UI behavior 
screen current //screen currently on

[haze]

shouldn't screen-display be

screen new
screen old

because you can already get the current screen.

couldn't you condense repeat and down into enums? and assume if it's repeating it's down?

up. down, repeating

i think it'd be easier to differentiate events this way

Also, why throw in deltaPos? Can't we calculate that ourselves if needed? I don't see a lot of use cases for that.

[GenericException]

because you can already get the current screen.

Also, why throw in deltaPos?

Quality of life / quick reference. Don't have to include if you don't want.

couldn't you condense repeat and down into enums?

You can, personally I wouldn't. I'd like to be as clear as possible without having the user needing to learn the any developer quirks. It also makes it more of a mirror image to the keyboard counterpart, and consistency is typically a good thing.

[haze]

If we want to avoid developer quirks we can rely on how the JDK defines these input events (i.e javafx mouse & keyevents). Would using those events make more sense?

[feature]

Great issue, we definitely need some way to consume user input. However I'd prefer the terms pressed and released over up and down. In my opinion this terminology is slightly more intuitive.

I agree with @hvze that input type (pressed, released, and repeated) should all be combined to in an enumerated type. This would also make it harder for the user to handle repeated event for key presses unintentionally.

Personally I cannot really find any good purposes for passing the mouse position in the input struct, except for completeness. There's a card for adding a GUI screen API. Though the card has not yet been reified as an issue, I want GUI screens to have methods for handle key and mouse inputs, including the mouse cursor position.

I'll look into making an event for GUI screen changes, along with the proposed GUI screen API mentioned above.

[haze]

Moving screen change into #7 (GUI related)