Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
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 ... 8
  ignore  |  Print  
  Mercury: The Simple 2D Game Library | >> BETA coming soon <<  (Read 143871 times)
0 Members and 1 Guest are viewing this topic.
Offline wessles
« Posted 2013-09-29 00:24:11 »

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.

Relevant links for those interested:
 - Project Website
 - Update Blog
 - Official Forum

Thank you for your support,
- Wes & Jev






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 Opiop
« 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: 382
Projects: 11
Exp: 4 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 Agro
« Reply #3 - Posted 2013-09-29 00:49:15 »

its a key value object.

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 167
Projects: 5
Exp: 6 years



« Reply #4 - 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 Troncoso

JGO Coder


Medals: 20



« Reply #5 - 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 HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


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


« Reply #6 - 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 HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


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


« Reply #7 - 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 Opiop
« Reply #8 - 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: 382
Projects: 11
Exp: 4 years


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


« Reply #9 - 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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kpars
« Reply #10 - 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 SHC
« Reply #11 - 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 #12 - 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 Opiop
« Reply #13 - 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 Opiop
« Reply #14 - 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 #15 - 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 Opiop
« Reply #16 - 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 #17 - 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 Troncoso

JGO Coder


Medals: 20



« Reply #18 - 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
« Reply #19 - Posted 2013-10-01 21:19:16 »

[snip]

- Jev
Offline Opiop
« Reply #20 - Posted 2013-10-02 02:59:10 »

Name your classes something obvious, yet simple. Sprite, BaseGame, Quad, VertexBuffer etc... The easier the names are, the easier they are to remember, especially if they actually explain what the class does. So something like Render isn't a good name because well, what can it render? Anything? You don't know, so you don't know what to expect. Just my thoughts.
Offline kingroka123
« Reply #21 - Posted 2013-10-03 02:24:05 »

Dang bad luck, but this may give google a time to prove its worth.  Hope you find the files
Offline SHC
« Reply #22 - Posted 2013-10-03 08:04:10 »

I think, you can recover your files by booting into live disk. Also, did you tried to change any grub related files? I don't think FloatBuffers cause that problem.

Offline Troncoso

JGO Coder


Medals: 20



« Reply #23 - Posted 2013-10-03 10:59:39 »

You're files aren't gone. If linux won't boot, it's just a bad configuration file. Everything in Linux is a file. I would look into resetting your xorg configuration, as that's a common cause of this. Otherwise, as SHC said, you could use a live boot CD (can go on a USB drive) and you can access files that way.
Offline Opiop
« Reply #24 - Posted 2013-10-03 11:48:10 »

I always managed to screw up my Linux install, booting into a live boot always worked when I tried to recover my data. I would also recommend getting committing changes to a repo every time you leave your computer for a while. It's just good practice if you're working on something really valuable!
Good luck!
Offline SHC
« Reply #25 - Posted 2013-10-03 12:29:39 »

Hope you successfully recover your files. Good luck.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #26 - Posted 2013-10-03 17:16:01 »

If you mount your windows partition under linux, a system crash will cause the windows partition to become uncleanly unmounted.  Then on the next boot instead of just running ntfsck, it drops you into emergency mode.  How's that for user-friendly?  You can either run ntfsck by hand, but doing one windows boot ought to force a check and reset the flag so your linux box boots again.

It's why I don't auto-mount /win in my fstab anymore :p
Offline Troncoso

JGO Coder


Medals: 20



« Reply #27 - Posted 2013-10-03 19:09:53 »

Depends on the Linux distro. I'm guessing you are using Ubuntu. They usually have a live CD option, so you can probably just use that disk.

But, no. You can use any live CD of any Linux distro. The entire OS is running off the CD, so there is no dependency on the hard drive and what's already on it.
Offline Phased
« Reply #28 - Posted 2013-10-05 15:34:03 »

aslong as the drive is not dead, use the drive as a secondary hard drive (pretty much like a usb that is always plugged in). then just transfer the files you need.

if the hard drive is dead, then I doubt you will be able to get them your self, but it is not impossible.

EDIT:

If you boot into your cd, and have the hard drive plugged in, you should see the hard drive in Ubuntu's equivalent to "My Computer" most likely in the same place the hard drive use to be in. havnt really used linux so I am unfamiliar with it.
Offline Troncoso

JGO Coder


Medals: 20



« Reply #29 - Posted 2013-10-05 15:52:45 »

I didn't say you couldn't access the hard drive. Go into the live CD and open GParted. See that your disk is actually in there. If it is and you can't get to it, you may need to mount the disk to gain access(I'm sure you can look that up). If it's not, then your hard drive isn't being recognized. The live CD won't treat the hard drive as a system drive, but rather as a removable drive, so you wouldn't necessarily access it the same way you would root or home.
Pages: [1] 2 3 ... 8
  ignore  |  Print  
 
 

 
ivj94 (580 views)
2018-03-24 14:47:39

ivj94 (44 views)
2018-03-24 14:46:31

ivj94 (371 views)
2018-03-24 14:43:53

Solater (60 views)
2018-03-17 05:04:08

nelsongames (107 views)
2018-03-05 17:56:34

Gornova (147 views)
2018-03-02 22:15:33

buddyBro (690 views)
2018-02-28 16:59:18

buddyBro (90 views)
2018-02-28 16:45:17

xxMrPHDxx (492 views)
2017-12-31 17:17:51

xxMrPHDxx (728 views)
2017-12-31 17:15:51
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
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!