Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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 ... 11
  ignore  |  Print  
  MERCury - 2d Game Library | Experimental release in development; test it out!  (Read 22276 times)
0 Members and 1 Guest are viewing this topic.
Offline wessles

JGO Wizard


Medals: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


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


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.

This is an experimental project, so you should expect to find a few issues and bugs in it.



Links

MERCury on GitHub
Our Wiki on GitHub
Our Subreddit

We also have a website currently in development. It should be done soon!

Give us your thoughts!
Got some ideas for improvements? Found a couple of bugs? Post about them here!

Have a great day,
- Wessles

Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #1 - Posted 2013-09-29 02: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: 238
Projects: 11
Exp: 2 years


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


« Reply #2 - Posted 2013-09-29 02: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


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

Yeah, I heard about hashmaps, but when I mentioned them to a friend of mine they said to just use arraylists. I see now why he was wrong.

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

its a key value object.

Offline wessles

JGO Wizard


Medals: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #5 - Posted 2013-09-29 02: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: 128
Projects: 4
Exp: 3 years



« Reply #6 - Posted 2013-09-29 03: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


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

Alright, I have a list of fairly okay alternatives:

- Visuals
- Renderer
- Drawer
- Painter

The names aren't perfect, I wanted this to have an easy and recognizable interface for Java2D 'veterans.' Guess not though. Sad

Offline Troncoso

JGO Coder


Medals: 20



« Reply #8 - Posted 2013-09-29 03: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #9 - Posted 2013-09-29 03: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: 238
Projects: 11
Exp: 2 years


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


« Reply #10 - Posted 2013-09-29 04: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #11 - Posted 2013-09-29 05: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 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?'

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: 238
Projects: 11
Exp: 2 years


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


« Reply #12 - Posted 2013-09-29 05: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


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

Wow. Blew my mind. I am totally doing those. I feel dumb 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: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #14 - Posted 2013-09-29 05: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: 238
Projects: 11
Exp: 2 years


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


« Reply #15 - Posted 2013-09-29 05: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 Wizard


Medals: 75
Projects: 4
Exp: 3 years


Radirius Software Developer


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

Your logo needs some heavy re-working.
Pixel-Art isn't just art scaled down, there are many things to think about while making it.

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

- Jev.

Check out #JGO on EsperNet IRC! | Check out the MERCury 2D Java Game Library! | Also, Check out My Site
Offline wessles

JGO Wizard


Medals: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #17 - Posted 2013-09-29 05: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!

Offline SHC
« Reply #18 - Posted 2013-09-29 05: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 13: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


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

@SHC
Thanks! Sorry, I 'borrowed' a lot of code from a simple 3d game I am 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: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #21 - Posted 2013-09-29 23: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #22 - Posted 2013-09-30 02: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: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #23 - Posted 2013-09-30 02: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 04: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: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #25 - Posted 2013-09-30 04: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 06: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: 64
Projects: 4
Exp: 3 years


Radirius Software Developer


« Reply #27 - Posted 2013-09-30 22: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 22: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 Wizard


Medals: 75
Projects: 4
Exp: 3 years


Radirius Software Developer


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

[snip]

- Jev

Check out #JGO on EsperNet IRC! | Check out the MERCury 2D Java Game Library! | Also, Check out My Site
Pages: [1] 2 3 ... 11
  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.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (26 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!