Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 12
  ignore  |  Print  
  Mercury: The Simple 2D Game Library | >> BETA coming soon <<  (Read 30951 times)
0 Members and 1 Guest are viewing this topic.
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Posted 2013-09-29 00:24:11 »





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.






Links

Official Website
Community Forum
Documentation
GitHub
Wiki



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

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #1 - Posted 2013-09-29 00:32:57 »

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!

Offline HeroesGraveDev

JGO Kernel


Medals: 292
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #2 - Posted 2013-09-29 00:42:21 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #3 - Posted 2013-09-29 00:48:20 »

Yeah, I heard about HashMaps for this. Other people recommended using ArrayLists, now I see why they were wrong.

Offline Agro
« Reply #4 - Posted 2013-09-29 00:49:15 »

its a key value object.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #5 - Posted 2013-09-29 00:56:30 »

Thanks, Heroes! That was a very informative response! I just fixed 1 and 2. Thanks for informing me about HashMaps.

3. Your triangle class doesn't work.

Please elaborate.

4. I think your VAOGraphics class 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.

What should I do? What if the values of the arrays are constantly changing, like with the player?

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

What else should it do?

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 138
Projects: 4
Exp: 3 years



« Reply #6 - Posted 2013-09-29 01:08:19 »

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.
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #7 - Posted 2013-09-29 01:12:16 »

Alright, I have a list of fairly okay alternatives:

- Visuals
- Renderer
- Drawer
- Painter

The names aren't perfect nor even practical though. I wanted this to have an easy and recognizable interface for people switching over from Slick2D and Java2D. Guess not though?

Offline Troncoso

JGO Coder


Medals: 20



« Reply #8 - Posted 2013-09-29 01:29:15 »

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.
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #9 - Posted 2013-09-29 01:39:54 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline HeroesGraveDev

JGO Kernel


Medals: 292
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #10 - Posted 2013-09-29 02:24:00 »


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

Quote
EDIT:
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()
And also:

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

5) Which one is shorter?

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

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #11 - Posted 2013-09-29 03:00:46 »

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

Offline HeroesGraveDev

JGO Kernel


Medals: 292
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #12 - Posted 2013-09-29 03:10:58 »

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  Tongue! 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.

VBOs are even better for this kind of stuff.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #13 - Posted 2013-09-29 03:13:38 »

Wow. Blew my mind. I am totally doing those. I feel like an idiot now.

Quote
Creating your own sprite batcher is not easy, and requires understanding of shaders, vertex buffers, and basic matrix math.

This was very misleading.
I'll get started right away.

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #14 - Posted 2013-09-29 03:14:55 »

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)

Offline HeroesGraveDev

JGO Kernel


Medals: 292
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #15 - Posted 2013-09-29 03:15:06 »

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.

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #16 - Posted 2013-09-29 03:20:41 »

Your logo needs some heavy re-working.

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

- Jev.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #17 - Posted 2013-09-29 03:36:01 »

It wasn't pixel art, but I had to scale it up. It used to be microscopic on JGO and Imgur and imageshack for some reason...
And yes, thought does go into it, I know.

Hope you try it out when it doesn't have a ton of stuffs to work out!

Online SHC
« Reply #18 - Posted 2013-09-29 03:55:03 »

On Line 48 of
Runner.java


1  
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

I don't see the need for clearing the depth buffer for a 2D engine.

Offline Simn
« Reply #19 - Posted 2013-09-29 11:31:42 »

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

- Simn
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #20 - Posted 2013-09-29 21:22:42 »

@SHC
Thanks! Sorry, I 'borrowed' a lot of code from a simple 3D game I was working on... will remove!

@Simn
I think that that is what sprite batching is. I am already working on it, but thanks for asking!

Shader support(?) and sprite batching coming soon.

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #21 - Posted 2013-09-29 21:29:08 »

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!

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #22 - Posted 2013-09-30 00:13:27 »

Yup. I already made the Shader class. Before I stick it in the GitHub repository, do you think that it should be bind() / unbind() or use() / release()?

I'm not too good with naming.

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #23 - Posted 2013-09-30 00:22:05 »

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.

Offline davedes
« Reply #24 - Posted 2013-09-30 02:15:10 »

If you were trying to mimic OpenGL it would just be
use()
. 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)
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.
https://github.com/mattdesl/lwjgl-basics/tree/master/src/mdesl/graphics/glutils

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #25 - Posted 2013-09-30 02:39:58 »

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

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.

Offline davedes
« Reply #26 - Posted 2013-09-30 04:58:27 »

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.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #27 - Posted 2013-09-30 20:44:23 »

Oh, and before I change graphics to something else I think I should just keep it at graphics. Shouldn't cause too much confusion anyway.

Offline Troncoso

JGO Coder


Medals: 20



« Reply #28 - Posted 2013-09-30 20:50:28 »

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.
Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #29 - Posted 2013-10-01 21:19:16 »

[snip]

- Jev

Pages: [1] 2 3 ... 12
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (29 views)
2014-11-22 12:13:56

xFryIx (71 views)
2014-11-13 12:34:49

digdugdiggy (50 views)
2014-11-12 21:11:50

digdugdiggy (44 views)
2014-11-12 21:10:15

digdugdiggy (38 views)
2014-11-12 21:09:33

kovacsa (62 views)
2014-11-07 19:57:14

TehJavaDev (67 views)
2014-11-03 22:04:50

BurntPizza (64 views)
2014-11-03 18:54:52

moogie (80 views)
2014-11-03 06:22:04

CopyableCougar4 (80 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!