Well I shall be staring at the source code for quite a while 
EDIT: I gotta say, this is extremely well done. The game, the engine, the code, the organization…you sir have accomplished a great feat. However, I feel like you have overused static classes just a bit 
Obviously you need tutorials and stuff
[quote]Place your games in AWT and Swing applications
[/quote]
This is relevant to my interests.
Using Slick Canvas, for applications in which you want OpenGL rendering, is a pain; that canvas is unstable as hell.
[quote]
[/quote]
I noticed that, and have no clue what caused it. It should be working now.
[quote]I gotta say, this is extremely well done. The game, the engine, the code, the organization…you sir have accomplished a great feat. However, I feel like you have overused static classes just a bit
[/quote]
Thank you VERY much for the compliment. It means a lot to know that 1.5+ years have been worth it. 
And yes, using so many static classes did concern me, but it seemed like the best idea at the time for a number of reasons:
1: They offer functionality which is best if universal.
Consider the input code: KeyboardHandler and MouseHandler. For each instance of the game, there will only be one keyboard and one mouse. Additionally, virtually any section of the game may need to access input data. Thus, I make the input data static, so that it can be accessed from anywhere in the engine and will always be consistent.
2: I wanted the API to be as simple as possible.
It seemed simpler to be able to say
if(KeyboardHandler.isKeyDown(Keyboard.KEY_X))...
than something like
if(this.getParentGame().getInput(Input.KEYBOARD).getState(Keyboard.KEY_X) == KeyState.KEY_DOWN)...
which seemed to me to be the logical extension of not using static classes.
Maybe this is just due to my inexperience, though. That’s why I wanted it to be open source, actually.
[quote]Obviously you need tutorials and stuff
[/quote]
I do need tutorials, I agree. The reason I don’t yet is from juggling college classes, a programming internship, and a general desire to finish this project up.
However, I’ll see what I can do. Don’t expect them right away, though.
[quote]This is relevant to my interests.
Using Slick Canvas, for applications in which you want OpenGL rendering, is a pain; that canvas is unstable as hell.
[/quote]
Perhaps I should add the caveat that I support using a single AWT Canvas. The current functionality is basically some utility functionality based upon Display.setParent(). I’ve worked with AWTGLCanvas before (which is how you obtain multiple OpenGL views), and it is truly a pain. I didn’t include it because it is so unstable.
However, if you simply want a single canvas, go right ahead with jRabbit.
I uploaded the generated Javadoc for people who don’t want to download it:
pretty cool game. It runs very smooth.
Graphics are cool and the game runs smooth. But it is too hard to play.
This is relevant to my interests.
Using Slick Canvas, for applications in which you want OpenGL rendering, is a pain; that canvas is unstable as hell.
[/quote]
From my experience with 2.7.1 lwjgl, it doesn’t mix well with Swing components in the same window and the AWT event queue is borked on Windows (i.e. you won’t be able to attach any kind of listener to the canvas). It really is meant to run in its own window/fullscreen and use its own input handling (and at this it excels).
For all the bad rap that it gets on these forums, I think JOGL is more suitable if you want to embed one or more OpenGL canvases into a traditional Swing app with lots of Swing controls. Likewise if you want to use AWT event handling, call Graphics2D to paint on top of the canvas, and/or do passive rendering on the EDT.
That LockingList class looks really interesting! O_O
I know, it is very hard. But it is open source! Modify the settings and see if you can find a more suitable difficulty level! 
Yes. The LockingList class is probably the crowning effort of the engine. I was going to start a separate topic about it, actually.
Hi
The source code seems to be well documented. Thank you for sharing your source code Where is the SVN repository? I have found only several archives containing the whole source code.
I have created a discussion about LockingList, jRabbit’s core iteration data structure, here: http://www.java-gaming.org/index.php/topic,24726.0.html
It doesn’t work for me!
[quote=“Micron Applet”]An error has occurred while loading the applet.
Please contact support to resolve this issue.
Unable to load logo and progressbar images
[/quote]
[quote=“Java Console”]Unable to load logo and progressbar images
Unable to load logo and progressbar images
[/quote]
What is your system/whatnot?
Wow looking gooood…
and the Micron is just a great game XD
well done
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.