Indeed Riven you should create a sprite class to abstract much away but we are talking about just the batcher here which will need to know all that information in order to render properly. The sprite class would pass everythin into the batcher. That is a step ahead of making the batcher. Would also be nice to specify where you would like to rotate around I suppose.
Just a little side note Stumpy, I think rendering the sprite at its center is just confusing. I think its far easier to render from the corner. In fact I don’t think I’ve ever worked with a library that “auto” renders from the center.
What about libgdx? I think it render in the center.
Nope, LibGDX (as far as I know) renders from the bottom left corner (which makes sense as the drawing origin is the bottom left corner) or vice versa if the drawing origin is the top left corner.
Just render from a corner (it makes most sense in the low-level code) and let the Sprite class define the origin (around which to rotate), and make the necessary conversions in the code that renders the Sprite using the batcher - the ‘SpriteBatcher’. Keep in mind though, that the ‘rotation’ parameter in the batcher is pretty much useless, if the callsite determines the point of rotation, as you’d need sin/cos to calculate the x/y offset, prior to the actual rotation - when using this approach.
It’s not always best to build in layers of abstraction, as - as just described - it may introduce a lot of overhead. Especially in a SpriteBatcher, it’s essential for performance to get as ‘close to the metal’ as possible, at the expense of (object oriented) code structure. My humble advice would be to refactor it beyond recognition.
I’ve been coming up with a concept for a 2D game recently anyway, maybe I’ll try to use this to prototype it! 
I wish the utility class you made for damping was self contained and not static.
Something like this,
EasingValue easedValue = new EasingValue<float>(0 /* StartValue */, 1 /* EndValue */, 200 /* DampingTime in milliseconds */);
float x = easedValue.get(); // Get the eased value, EasingValue class keeps its own time.
easedValue.reset(); // Reset to it's StartValue.
easedValue.pause();
easedValue.resume();
easedValue.setSpeed(1); // Set the speed of the easing to 100% it's normal speed.
easedValue.setStartValue(0 /* New StartValue */);
easedValue.setEndValue(1 /* New Target Value */);
I’d make the class for you, but I lack the time : (
Done. 
Thanks for the great idea.
In this past month, we’ve been working pretty hard on 4 requested things, and I’m happy to say that they’re finally ready.
Here are 4 new places where you can go to learn about and discuss MERCury.
1. The MERCury Website
A portal to all things regarding MERCury. Link.
2. The MERCury Forum
A place to discuss game development with MERCury and improvements to the library. Link.
3. The MERCury Wiki
A carefully written place to learn how to use MERCury and how MERCury works. Link.
4. The MERCury IRC
A place for general chat and discussion about MERCury. Webchat Link.
So join the forum, get in the IRC channel, enhance the wiki, and do whatever you can to enhance the project!
Thanks for helping with everything.
- Jev
Nice job, it’s coming along well.
libgdx renders from the corner, but also has convenience methods for setCenterPosition(x, y);
Hello, Everyone.
Me and Wesley had a long talk about the noise in the thread, and I think it’s safe to say that there won’t be any more chitchat from now on.
I actually have a big announcement to make regarding the project… Quite a few of them actually.
The project is officially over a year old now, and a lot has happened in the past year that we’ve been developing this.
The original goal, a full year ago, was just to make a game library for shits and giggles.
In the past few months, our project’s goal has completely changed. Now we’re actually making a game library that intends to just stay simple and avoid the unnecessary. That’s pretty much it. We figured that if we want others to recognize this mindset, we need to turn our entire development philosophy around. To get a head start, we’re officially going to rename the project to something much simpler and recognizable.
From now on, the project is just going to be called… Mercury.
That’s right, I’m serious. From now on there will be no more of those 3 annoying capitalized letters.
[sup][sup]Incase you were wondering what they were there for, it was supposed to be a cheesy recursive acronym:
“MERCury’s Easy, Reliable, (and) Capable!”[/sup][/sup]
Enough said about that, let’s move on to the code itself!
For the past week and a half I’ve been tinkering around and fixing many kinks and bugs in the library. (Changelog here) And honestly, there is a lot of stuff wrong with it right now. Currently, our main issue is the staggering amount of leftover code in the library from its early days. In-case some of you hadn’t known, Mercury had originally started out as a 3D library and ‘downgraded’ to 2D about a week in for the sake of making things less time-consuming. There were still a few tools built into the library to deliver not-so-good support for it, and now they’ve finally been removed in my latest commit.
I’m also proud to say that the way Core’s are setup now has been completely reworked as well. I’m just going to let the code explain for itself.
Here is what your average class would be like, using Mercury just but a couple days ago:
public class MyClass extends Core {
Runner runner = Runner.getInstance();
public MyClass() {
super("Hello");
runner.init(this, 800, 600);
runner.run();
}
public void init() {}
public void update(float delta) {}
public void render(Graphics g) {}
public void cleanup() {}
public static void main(String[] args) {
new MyClass();
}
}
While this is extremely short when compared to class setups in things like Slick2D, I figured that we could do this better and in a much more simplistic manner.
Here’s how the basic layout of a Mercury program looks now:
public class MyClass extends Core {
public MyClass() {
super("Hello", 800, 600);
}
public void init() {}
public void update(float delta) {}
public void render(Graphics g) {}
public void cleanup() {}
public static void main(String[] args) {
new MyClass().start();
}
}
This is perfect in my opinion. Now the user doesn’t have to do anything with the Runner nor know exactly what it does to get a basic program going. Not the biggest change in the world, but still pretty awesome I feel.
Granted, a bit of hackery was required to get this to work. All of the code for it should be cleaned up very soon, probably by Me or Wesley.
With that out of the way, there’s still even more to discuss. Remember that awful Color class? We’ve already gotten some complaints about that one. I’m very happy to say that now it’s much easier to use, yet less buggy too. I’ve additionally added new g.setColor(); functions that simply take in 1, 3 and/or 4 variables containing each component. So now you have the choice of either creating a new object for your colors or passing in all of the variables for one right there. Pretty neat stuff IMO. I’ve also re-done the color palette entirely. This time, I’ve decided to do it with easy-on-the-eye colors that I feel are and will be very delightful to use in different projects.
Demos of the library are also now in development, and most of the classes in the test package have been removed for the sake of keeping the library clean. The code for them tends to be very awful. I’ve also made a few changes regarding splash-screens, now you don’t have to manually display them in your render function. I’ve also brought back the drawRectangle() function, for it was gone a while back and replaced with drawPolygon(). (Still not replacing drawPolygon() though)
We’re only about 80% done with the renaming process and going through all of the files to make sure we don’t miss anything. Right now we’re still in the middle of having to update splash screens, leftover documentation, GitHub-related things, and a bunch of other junk. Feel free to contact me or Wesley to report any files/code that still uses the ‘MERCury’ name. The Wiki will also be updated later. So don’t worry about that.
That’s pretty much it really. A lot of other things have been changed, but they’re not significant enough for me to need to mention them in this post. 
Again, check the (horribly-written) change-log if you really want to know all of what happened.
TL;DR Update:
Core’s are now much easier to setup,
We’ve changed the project’s name to ‘Mercury,’
We’ve turned our entire development philosophy around,
1.0.1 Beta, our first official release, will be released later within the next 1-2 months with various changes,
Many bugs have been, will be, and are being fixed.
You can download the latest build here:
[dead link]
The code is still really hackish right now and everything is still a bit buggy, so don’t expect a stable build out of this.
Thanks, hopefully that can give you guys a bit of an idea of what we’ve been doing lately.
I’ve probably made a ton of grammatical errors in this post and may have not worded things too well, I’m tired from having worked on the project all night. I’ll probably just make a second edit later with some typo-fixes.
Happy coding,
- Jev
EDIT: Yep, I know the versions on the JARs are all messed up. Fixed.
Is this project still in development?
Yep!
We’ve officially been going for over a year now, still chugging along.
Also, I’ve fixed all of the links on the website, and as well fixed an issue in the GitHub repository where language stats wouldn’t show up.
Recently we’ve been working on adding better controller support, making games with the library, better versioning, and cleaning up code so we can add even more features!
We’re aiming for a beta release in either December or January.
- Jev
EDIT: I’ve edited the download link in my previous post.
I would just like to remind everybody here, the official website’s domain has been changed to http://www.mercurylib.com/.
http://merc.radiri.us/ has been set to a redirect, so no existing links should be broken.
I also got http://www.mercury2d.com/, for people who don’t like typing one extra character.
- Jev
Seems you’ve made quite a lot of progress in a year! I do wonder if you plan on including a state based system in the future?
It’s been a while since we’ve said anything big about the library lately, so here’s a post that’ll hopefully give people a better perspective as to what’s been happening recently.
General Updates & Reminder
It’s ~2 months until the libraries first beta release.
We’ve been going for over a year and three months now, getting close to 500 commits.
December is going to be an interesting month for us. We’re going to be releasing the first beta version of the library, launching one of the games we’re making with it, giving the website and forum a slight makeover, lots of stuff really.
Here’s the thing; to get a stable build out by the end of december, we need more people working on the library with us. If you’re willing to join the team, contact either me or wes on JGO and we will get back to you as soon as possible.
Requirements:
- Must have at least 4 years of Java and overall programming experience.
- Must be actually dedicated to working with us on the project.
- Must be familiar with git and have a GitHub account.
In your message you should also tell us what you would be specializing in on the library’s development.
Samples of your code are mandatory.
Code Updates
GUI might be put on hold for a bit; not entirely sure. I have a lot of code-cleaning to do on it.
Shape rendering has also had some massive updates, now you can texture any shape in the library with no hassle. Plus they have more accurate boundaries now as well, so that should improve collision and intersections.
Camera rotation is also finally in; no idea why it took us so long to toss that in there.
TMX Loading might be in before December. We’ve gotten a lot of request to add it in, so hopefully Tiled users will be happy about this.
We might not get full-blown networking support in before the release, mainly to prevent awful code from spawning. If there are any networking guys out there wanting to contribute, send us an email.
I’m also in the middle of writing a document based on the Google Style Guidelines for Java, which we will be officially following as of the release.
The default font will also be changed from Open Sans to Roboto, just a little side-note for the typography geeks out there.
Wiki Updates
Yep. We haven’t worked on it as much as we should’ve lately.
The wiki will be updated after the release. It would be a waste of time to write a bunch of pages that we’re just going to have to update in two months anyway. Sorry to the newcomers who probably have no clue how to use the library. 
We have so many new articles to write for it though, mainly regarding the particle engine, GUI toolkit, scene-graph, game state manager, etc.
Hold up… Did you just say…
Yep. There’s a game state manager and scene-graph now. Both are very simple to use
The implementation of both of these are still a bit rough, so don’t expect anything too fancy yet. The scene-graph is still pretty bare-bones and the game state manager isn’t perfect, so there’s still more to come.
But regardless, I’ll show you what I can.
Using the scene-graph is pretty simple. You just take any random class that extends GameObject (in this case, [icode]Thing[/icode]) and pass in the object into the ‘addObject(…)’ function of GameScene.
public void init() {
GameScene.addObject(new Thing());
}
The rest of the updating/rendering is done for you automatically.
Adding child nodes and controlling the current objects in the graph is a whole other thing; I’ll talk about that in the wiki article.
GameState is also pretty simple. It’s like any other Mercury component except it has [icode]onEnter()[/icode] and [icode]onLeave()[/icode] functions that are called when entering and leaving the game state. The rest will be included on the wiki article.
Game Updates…?
Yep. We’re actually making games with this. We aren’t that bad!
We’re in the middle of making this little twitch game called RFLEX. More info on it will come about later.
The website for it will be fully available once the game itself is ready for JGO to critique and play around with.
This is also why Wes hasn’t been on development much lately; he’s doing most of the work on this.
Let us know if you have any questions or concerns.
Happy Coding,
- Jev
Hi
In my humble opinion, some classes have too much static methods, for example com.radirius.mercury.scene.GameScene and com.radirius.mercury.resource.Loader. Maybe you do that to simplify some things but it drives the API more rigid and harder to extend. Good luck.
About the experience cap on who can apply: it shouldn’t be based on the number of years the person has been programming. While it can give you an idea, this rarely indicates the total amount of skill someone has.
It’s difficult to plan in which environment the developers use the libraries. For example, a developer might need to use a custom resolver for URIs and URLs. If you don’t use this class internally, you can leave it unchanged, otherwise you should allow the use of custom loaders. In general, I avoid writing classes with tons of public static methods and I know that it can be a limitation in multi-threading. It becomes a real problem when those static methods don’t do trivial things and when they are called very often internally. I have to fix this kind of limitation in another engine and it’s easier to deal with that earlier. I prefer using classes with no field than classes with only public static methods.
This is to notify you guys that I’ve successfully converted the code to use OpenGL core profile. Here’s a screenshot showing you the tests that are along with the library being run on core profile.
To do this, I’ve made two new classes, [icode]Matrix4f[/icode] and [icode]GraphicsUtils[/icode]. I’ve removed the [icode]VAOUtils[/icode] class completely, as it has no use, since the new code is relatively small. This [icode]GraphicsUtils[/icode] class, is used to emulate the Matrix stack, to provide the an easy way to keep the matrices for every frame.
I’ve also modified a lot of shader code, and the default shader uses 330 version of the OpenGL Shading Language. Everything is working, and we are currently assuming that most people will use the standard shader, have made the process of using the shader difficult with [icode]VAOBatcher[/icode] since we hard-code the names of the uniforms we use, and also the locations of the attributes is fixed.
I also made modifications to the [icode]Graphics[/icode] and [icode]Batcher[/icode] interfaces to include another void method called [icode]cleanup[/icode] to clean the handles for OpenGL objects generated in the constructor and I’ve called those methods in the [icode]end[/icode] method of the [icode]Runner[/icode] class to ensure that they get cleaned every time.
Anyways, I’m proud to say that these changes doesn’t effect the library, any existing code using this library runs fine just without porting.
Happy Time Users!!