Mojo Status
Community Forums/Monkey2 Talk/Mojo Status
| ||
| Hi, I've been diving deeper into Monkey2 recently, and have been wondering what's the current status of Mojo. Some things are quite different now, like everything being done inside a Window instance (instead of an App instance), there's no OnUpdate() or OnCreate() (as far as I can tell from the examples), etc. Is this the new direction, or should I wait a bit more so Mojo is more refined before I dive in and start converting Monkey1 code? Thanks! Leo. |
| ||
| I believe the basic architecture is in place now, so "the new direction" is settled, I think. Though to be certain you could wait until the V1 release (due soon?). In any case, I'm having fun porting a few things, modifying them to take advantage of MX2's new approaches. In the git releases there are some samples in the monkey2->modules->mojo->bananas folder. The documentation also has some information about the mojo module (monkey2->docs->index.html). |
| ||
| > Is this the new direction Yes! You should now extend Window, not app. There is no OnCreate method - you should stick your 'create' code in the window constructor. I'm just adding timers now, which will allow you to implement a 'fixed' OnUpdate method. |
| ||
| Great to know, thanks! What about App.KeyHit()? I can only see App.KeyDown(). Should I implement my own? Seems like it's useful enough to be inside App. Another one that I always miss is MouseReleased(), since in most GUIs the mouse click is only registered if the mouse is released inside a button. Cheers! |
| ||
| I may add keyHit, but probably not MouseReleased. You can use event handlers to detect the full range of key/mouse events, eg: Method OnKeyEvent( event:KeyEvent ) Select event.Type Case EventType.KeyDown Case EventType.KeyUp End End Mouse OnMouseEvent( event:MouseEvent ) Select event.Type Case EventType.MouseDown Case EventType.MouseUp Case EventType.MouseEnter Case EventType.MouseLeave End End |
| ||
| Sounds unflexible, you want both options (functions and events) handling input. |
| ||
| I guess it wouldn't be hard to make a module that adds the functions we are used to. |
| ||
| I'm a big fan of including the few functions/method we use all of the time. KeyHit(), KeyDown(), MouseDown(), Hide/ShowMouse() and the rest that we have now with MX1. Not including them will add extra effort to MX1-to-MX2 conversion especially if you have a lot of code to convert. As it is now I have maybe 10k lines to convert so anything Mark can do to smooth this transition is welcome. I suppose I could roll-my-own but then I would have to include that in every thing I write (well most things). I'm having deja vu as I think I recall this discussion when Mark was developing MX1. :) |
| ||
| I've had a bit of a rethink about the 'simple input' issue and have come up with a system that should be both pretty easy to use and flexible. What I've done is add KeyboardDevice and MouseDevice classes that provide an 'immediate mode' style interface, along with global vars called Keyboard and Mouse so you can use them easily. This has also allowed me to rip out a bunch of hacky code from App which is a good thing! So KeyDown() is now Keyboard.KeyDown(), MouseX is Mouse.X etc (for existing projects it should be a simple find/replace in files). I know some people hate the whole 'Keyboard is an object' approach, but it is a very tidy way of doing this and provides a lot of flexibility, eg: I'm planning on adding a GameController class (based a bit on SDLs) that could potentially wrap keyboard or joystick or both keyboard/mouse etc. So player1, player2 etc can each have their own GameController without knowing what's being wrapped. |
| ||
| So KeyDown() is now Keyboard.KeyDown(), MouseX is Mouse.X etc (for existing projects it should be a simple find/replace in files). That sounds like some middle ground I can stand on. :) Thanks, this should help make conversions easier. |
| ||
| I like that approach. Thanks Mark! |
| ||
| @marksibly: I don't know why people would dislike that, that's essentially what's going on behind the scenes in MX1. As for the lack of 'KeyHit', it's not an issue if we could easily make our own equivalents anyway. The way I see it, Mojo should evolve into its own thing in MX2 and have a community developed wrapper for the legacy APIs. This is similar to my 'mojoinmojo2' module, which takes Mojo 1's graphics API and redirects calls to Mojo 2. Honestly, I think that should be a community project with a different name (And namespace), because an official solution could cause confusion. |
| ||
| > As for the lack of 'KeyHit', it's not an issue if we could easily make our own equivalents anyway. Immediate mode inpout handling can be a little messy to implement though, basically because there are so many ways to implement things like KeyHit, each with subtly different semantics. For example, does calling KeyHit clear the 'hit' flag (ala bmx) or is it cleared next 'frame' (ala monkey1 - but what's a frame in monkey2? There is no such thing right now). And how are the keyhits generated in the first place? From KeyDown events or from polling keystate? Either way is gonna give subtly different results. I definitely like having OnKeyEvent() in there as it removes all this confusion (and allows you to write purely event driven code), but I also get why people are reluctant to use it - it's just so very easy/convenient to be able to poll game controllers in update code, so it's something I think monkey2 should support as well as it can. |
| ||
| +1 for event-driven callbacks/function variables. |
| ||
| monkey2 = games related tool = games = interactivity = input If monkey2 needs a module for handling basics like input in convenient ways already, i doubt it will have a chance to succeed. Iteration and experience normally lead to better, not worse, results. Confusing when looking at SDL2 as well. |
| ||
| Indeed, polling on update is a pretty common strategy in games (even if the update is going to be driven by a timer event), and IMO it is good to support it directly if that's what the libraries are going to be used for a lot. Games tend to be relatively monolithic and it is often logical to start each update with a decision: did the user click a button, did the game end, did the user make a standard game input, did nothing happen? Then you know exactly where you're going until the next update. |
| ||
| Started using the Keyboard class from the latest code on Github. Nice! I like how the Input classes feel more organized now. One little thing bugs me: now that there's a Keyboard class, wouldn't it make more sense to call "Keyboard.Hit()" or "Keyboard.Down()", instead of "Keyboard.KeyHit" and "Keyboard.KeyDown()"? Seems a little redundant saying "Key" three times, if you consider a typical command "Keyboard.KeyHit( Key.Left )". Same thing for "Mouse.ButtonDown( MouseButton.Left )", could be simplified to "Mouse.Down( MouseButton.Left )". Or even better, how can I use something like an Alias command to override that just in my code, without editing Mojo's source code? I know, I know, noob question... |
| ||
| > wouldn't it make more sense to call "Keyboard.Hit()" or "Keyboard.Down()", instead of... I prefer KeyHit/KeyDown here - a KeyBoard is not a Key, so I prefer the added 'Key' prefix. I did breifly consider making Key a struct with 'Pressed' etc methods, eg: If Key.A.Pressed Print 'A' is pressed! Endif ...but that's just pointlessly clever! But I do think these should be renamed, as KeyDown currently has a double meaning. In the case of events, KeyDown means 'Key transitioned from unpressed to pressed' (which is actually closer to what 'KeyHit' reports) but in the case of Keyboard.KeyDown it means 'Key *is* pressed'. We're also still missing 'KeyUnHit'...will think about this some more, but I'm happy with the Keyboard.blah approach for 'polling' so I think it's going in the right direction! |
| ||
| Adding a method for a bit of raw keyboard data processing wouldn't go amiss either. |
| ||
| Not sure what you mean here... |
| ||
| We're also still missing 'KeyUnHit' You mean, KeyReleased ? :-) |
| ||
| That's the obvious one I guess as long as everyone's happy with KeyDown (sure they will be). So how about: KeyDown KeyHit (or KeyPressed?) KeyReleased ? KeyDown still feels a bit 'wrong' to me here, as it has quite a different meaning to 'KeyDown' events, but it's not worth stressing over I guess! |
| ||
| State - down, pressed, released Event - pressed, released That way the pressed state is just signaling that a pressed event occurred. But really "down" for event and state is fine. The event down causes the state down (or vice versa the state down causes the event down). |
| ||
| @Mark Adding a method for a bit of raw keyboard data processing wouldn't go amiss either. Let's say a method so that non U.S. keyboards can be handled. And an overloaded KeyDown/KeyHit function for checking a key and the key modifier at the same time. |
| ||
| From those mentioned i like KeyUp, KeyDown (autofire) and KeyHit, KeyReleased. There are a few ways to get this right. Needs to make sense throughout all input options too. |
| ||
| I too prefer KeyUp to KeyReleased... Might just be because it matches the old VB / WinForms convention... |
   |