Important notice on the future of the project

Quote

Hello.

Me and Jev have decided that it would be best if we started to branch out from JGO, so we are going to stop updating this thread. There have been many changes to the forum’s rules regarding game engines and game libraries, and with respect to those changes we are officially moving all updates regarding the project elsewhere. This project is not dying, but we are moving all updates and news to our own site and other social media outlets so that we can spread to other communities as well.

We hope this change will leave more room for actual games to be posted, and I suggest all other engine developers do the same with their projects so JGO can get back to a cleaner state and focus more on video games.

Once Mercury hits beta, we’re probably going to start posting more of the games we’re making with it to JGO, but updates on the library itself will all go on the new blog.

About the project

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.

How it started

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.

What this is

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.

What this isn't

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.

Have a say

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. :-PThe older posts in this thread are quite irrelevant now and do not, in any way, represent how the library is now.

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!

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.

The idea that sometimes one method would not want to have to pass in some variables, and want to access that variable without it lengthening the amount of arguments they have. In the end, it is your choice whether or not to use the static capabilities of it all. I choose to, but you can just pass it into your objects. Free choice FTW!

The only place where you need to use static, is if you want to change the graphics object, which you cannot even do right now, as there is only one.

4: what should I do? What if the values of the arrays are constantly changing, like with the player?5: what else should it do?

4) 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).

4) 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).

4: SpriteBatching? I just looked that up, and it requires extensive knowledge of shaders, matrices math, and other stuff I probably haven't even heard of ! Are there any alternatives to what I am doing that are a little more 'on my level?'

5: Sorry. I just like to wrap things. To me it looks more organized than alternating between utilities and GL. I don't see that that is a flaw though, wrapping it...

4: SpriteBatching?! I just looked that up, and it requires extensive knowledge of shaders, matrices math, and other stuffs I haven't even heard of ! Are there any alternatives to what I am doing that are a little more 'on my level?'

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.

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)

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!

. 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)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org