I was reading over the javadocs for your engine, the zip file hasn’t even finished downloading yet and I am in love! Of what I can tell from the docs this is very well thought out and implemented. Great work, and I can’t wait to use it for my next game!
[edit] well i got everything set up and working, now where to begin. Perhaps a ‘make a standard game’ tutorial is in order. If I knew more about the implementation I would do it!
Hello! Is there any way you can write some documentation on this? This really seems comparable to slick2d and libgdx. I want to use to badly, but I’m not good at learning things by just looking at the source for micron. Once, I learn it, I can help you write lots of tutorials, though!
Also, Are you planning on updating this anytime soon? I want to use it, but I’m afraid it will become outdated because it hasnt been touched since it was released.
@8keep
I’m not the developer but here my two cents. If this lib acts as higher level (API helper) to lwjgl, then you can use this lib as long as lwjgl doesn’t change hardly their API. Mean you can update this lib by replace the lwjgl lib to newer version so you’ll gain the performance update. But if lwjgl’s API hardly changed like libgdx, there’s chance current version of RE can’t be used with new one.
Not really a fair comparison. A fairer version of 2) would be :
if (getParentGame().getKeyboardHandler().isKeyDown(Keyboard.KEY_X))...
another alternative would be to ‘push’ the keyboard handler to the client, rather than the getParentGame().getKeyboardHandler() ‘pull’. Which would give you client code of :
if (keyboardHandler.isKeyDown(Keyboard.KEY_X))...
The main benefits of an approach like this are :
1 Unit testing is easier - you can inject in different Test Doubles
2 Polymorphism. You could have different implementations of these classes. This could make your code more flexible.
The main cost being the extra overhead & complexity. I would say that this is quite small but definitely non-zero.
YMMV.
DK.