Mercury: The Simple 2D Game Library | >> BETA coming soon <<

WIP games, tools & toy projects Archived Projects
#1

[h1]Important notice on the future of the project[/h1]


http://i.imgur.com/0slGpSV.png

[h1]About the project[/h1]

Mercury is a small game library designed to simplify the complex and shorten the tedious for both beginners and veterans alike. With it, you can use the best aspects of OpenGL in a super easy and organized way optimized for game programming. It is built around the concept that beginners should be able to start with the basics and then move up onto a more complex plane of development with the veterans, all on the same platform.

Mercury puts all of its resources into keeping things short and simple. The initial setup of a game consists only of making a single class; then you are done. The interface is entirely documented for easy and fast learning, so once you are started, there is nothing between you and the end result but coding and creativity.


http://i.imgur.com/2WL3UOQ.png

http://i.imgur.com/a5Q3al5.png

http://i.imgur.com/d0wXRzm.png

Links

Official Website
Community Forum
Documentation
GitHub
Wiki

[h2]How it started[/h2]
Mercury started out about over a year ago as a simple personal project that I intended to use for my own games. After eventually forming a team of like-minded people to work on the library with, I started taking things much further. This is so far the biggest accomplishment I have made in my game development years, and I hope people love using it just as much as I (and the rest of the people on the team) have enjoyed working on it. It’s officially two months until the projects first debut release, and it’s come a long way since the day it has started.

[h2]What this is[/h2]
A game library intended for use by both people who are new to game development and hobbyists who are trying to explore ways in which they can (literally) step up their game as developers. Use it for whatever you wish. Just about anybody can download the project, start messing around with its features, and create something amazing.

[h2]What this isn’t[/h2]
Another ‘Über Simple’ library that sacrifices most of the common necessities of game development just to stay ‘easy’ for the user. Libraries that do this are terrible for people who want to actually get something done. Luckily, Mercury isn’t like that.

[h2]Have a say[/h2]
This is still an experimental project, so you should expect to find a few issues and bugs in it.
If you do happen to find an issue or bug, post to the project’s forum or create an issue on our GitHub.

There are also a few flaws in the library that get ignored over time; we can’t remember everything.
If you find something that seems odd or a bit out of place in the code, let us know.

You can also request features and contribute some code if you wish!
Just make a pull request on GitHub with your changes and we’ll try to look over the code as soon as possible.

Have fun with this.

Happy Coding,

  • Wesley & Radirius
This post was last updated on November 8th, 2014

Ignore any of the older posts calling it an engine. This is, indeed, a library. :stuck_out_tongue:
The older posts in this thread are quite irrelevant now and do not, in any way, represent how the library is now.
#2

Spritebatching! So important, if that’s one of the only things you do, do it. Also, support for easy to load and bind textures and mipmapping. Oh and lots of math helpers like vectors and matrices and cameras are very useful. Easy shader loading… I could go on all day but just get the basics working right now!

#3

Okay, I’ll just highlight a few problems in the code:

  1. ObjectUR is duplicate code. Just implement Renderable and Updatable. Or if for some reason you need to know that it has both, simply make ObjectUR extend Renderable and Updateable, then you don’t have to implement so many interfaces.

  2. Use HashMaps in ResourceManager. Your code in that class is an inefficient mess.

  3. Your triangle class doesn’t work.

  4. I think your VAOGraphics is less efficient than immediate mode. You seem to be setting up all the complicated (and processor time consuming) pointer calls for every single shape you draw.

  5. Your pointbuffer method requires more code than just calling gl___Pointer()

Apart from that, it looks like a reasonable start. Your code layout is decent enough.
It just needs a bit of work, and some fixing of the above problems.

#4

its a key value object.

#5

Don’t have time to look through all the code right now, but I would refrain from naming your classes the same as their Java2D counterparts (ie Graphics), just to avoid confusion.

#6

What’s the logic behind making the entire Runner class static? It seems like you are trying to make it a singleton. If so, that’s not really the right way.

#7

You can’t specify a triangle by passing in 4 values. You need 6 (X&Y for each corner).

  1. The problem isn’t that. The problem is that you are using one VA per quad. With the overhead from the pointer setup, I would think that drawing 4 vertices with immediate mode is more efficient. You need to use spritebatching (if that’s the official term).

  2. Which one is shorter?


GL11.glVertexPointer(2, stride, buffer);
VAOUtils.pointBuffer(VAOUtils.VERTEX_ARRAY_POINTER, stride, buffer);
#8

All a spritebatcher needs to do is buffer draw calls together and then flush them together in order to minimize GPU calls.

Instead of drawing the rectangles straight away, store the vertex/texcoord/colour data in a buffer or arraylist, depending on how you want it to work.
Once you are finished rendering everything, call a draw function, which takes the data, stores it in a buffer if it isn’t already in one, and then draws it all in one glDrawArrays() call.

VBOs are even better for this kind of stuff.

#9

You could even go further and make two spritebatchers, one for vertex arrays and one for vertex buffer objects. VBOs are better for static geometry(tiles) and VAs are better for constantly updating an changing geometry(mobs, particles)

#10

Depends on your requirement of a spritebatcher.

Ideally, it has all that stuff, but you can’t not call it a spritebatcher just because it doesn’t use shaders/matrix math etc.

#11

Your logo needs some heavy re-working.

Other than that, I’d love to try it out!

  • Jev.
#12

On Line 48 of [icode]Runner.java[/icode]

[url=https://github.com/weslgames/MERCury/blob/master/MERCury/src/com/wessles/MERCury/Runner.java#L48]


glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

[/url]
I don’t see the need for clearing the depth buffer for a 2D engine.

#13

Cool project!

Have you thought of having a scene (which has a VAO) where you add primitive types and they all get rendered from the same VAO? It will boost performance quite a lot. :wink:

#14

Shader support should be pretty easy, just write a parser and a way to bind and unbind shaders and then apply them to the geometry. Other than that, there’s basically nothing else to do I think. It should take you like 30 minutes to an hour to learn how to do it!

#15

Just stick with the OpenGL way of doing things and use bind and unbind. There’s no point in changing things around in a wrapper class.

#16

If you were trying to mimic OpenGL it would just be [icode]use()[/icode]. In OpenGL you can’t “unbind” a shader. Binding shader zero just binds an invalid program.

But it’s often better to be consistent with the rest of your library. That’s why LibGDX uses begin() and end() for things like SpriteBatch, ShapeRenderer, and ShaderProgram.

[quote]You could even go further and make two spritebatchers, one for vertex arrays and one for vertex buffer objects. VBOs are better for static geometry(tiles) and VAs are better for constantly updating an changing geometry(mobs, particles)
[/quote]
Probably better to use a single SpriteBatch class and abstract the vertex data transport. This is what LibGDX does with Mesh; it can use vertex arrays or VBOs. I’ve also started (sort of) doing this in LWJGL-basics, but I only implemented vertex arrays.

#17

Oh, crap I forgot shaders in LWJGL used “use”. Oops! I was thinking of Slick-utils texture bind function for some reason :confused:

Can you explain a little more about what you mean by a vertex data transport? Thats the first time I’ve ever heard that term, but it sounds interesting and technical.

#18

Sorry, just some jargon I cooked up to mean “abstract class that gives vertex data to GL” – could be vertex arrays, VBOs, or even immediate mode if you are feelin’ crazy.

#19

I don’t honestly see what the confusion would be… and considering it’s supposed to be mostly for your personal use, definitely name it whatever makes the most sense to you.

Big takeaway: I think the naming of your classes is probably the least important thing you could possibly be worrying about.

#20

[snip]

  • Jev