Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (748)
Games in Android Showcase (226)
games submitted by our members
Games in WIP (834)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
  Mercury: The Simple 2D Game Library | >> BETA coming soon <<  (Read 136571 times)
0 Members and 1 Guest are viewing this topic.
Offline Coldstream24

JGO Ninja


Medals: 81
Projects: 1
Exp: 4 years


You can fill that void inside with programming, but you'll never return a value.


« Reply #180 - Posted 2014-07-08 06:22:40 »

Looking good. That said, the title text of the window looks a bit off-centre for me.
Also, with the close button, I think that if you want it to remain a circle, it's too big currently. OS X-size buttons may make it look nicer, and captions that appear when you mouse over (like an X) would look nice and shouldn't be too hard to implement.

Are you planning on adding event listeners to components and so forth (like mouse over, etc?)

My website: http://www.onedropgames.com/
My soundcloud: http://www.soundcloud.com/coldstream24
Creator of the Morningside Engine, co-founder of Onedrop Games.
Offline kpars
« Reply #181 - Posted 2014-07-08 06:26:55 »

Heh, those textures are just temporary until I get the time to work on the default look and feel. The reason why I'm not doing that right now is because I'm in the middle of getting the MERCury website done, which has been quite time consuming.

Expect a large post from me later regarding those two things.

- Jev

EDIT: Also, the reason why the text looks off-center is because the width that the text is centered with takes in both the width of the window AND the width of the close button. Sorry if I didn't word that too well, but you get the idea.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1335
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #182 - Posted 2014-07-11 08:57:57 »

I'd advise not to make up awkward terminology.

SubTexture.convertToTexture() makes much more sense.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kpars
« Reply #183 - Posted 2014-07-12 00:38:31 »

Fixed.

- Jev
Offline StumpyStrust
« Reply #184 - Posted 2014-07-15 07:05:59 »

Well ignoring whatever was going on in this thread, I tried out the lib and it really gives a java2D flavor. That is good as doing basic things in java2d is very easy.

However I wanted to see how easy it would be to port my particle lib and well...the batcher was kinda bad or more of missing things. I couldn't figure out how to specify rotation, scale, mirroring, etc. So I never made t very far. It took me a few minutes to port to libgdx and I was hoping it wold be the same for this lib but things I guess are still too immature.

Keep working on this if you like. I made my own engine'ish stuff and it was really fun for a while.

Requested feature that would really help game devs and greatly speed up rendering. Automatically adding textures onto an atlas unless specified not to.

PS: Look into using a geometry shader for sprite batching. I got about 100-150k particles or in your terms like 400-600k verts with basic batching. With a simple geometry batcher I made it p to 500k particles. It also has the advantage of smaller bandwidth.

Offline StumpyStrust
« Reply #185 - Posted 2014-07-15 21:16:10 »

The batcher is just to batch everything into one draw call ideally.You can batch things like rotation, scale, mirroring, etc for sprites. The next thing that could hit performance is texture switches which really do not matter if you are using an atlas or modern opengl. The geometry shader allows you to just give a single point and color and then the shader creates the geometry. Let me put it this way. You should try and batch everything.

This is how my render method works in no particular order.

drawImage(x, y, scaleX, scaleY, rotation, color, mirror up, mirror down)

The x and y will be the center of where the image is drawn. So drawImage(0,0,4,4) would be an image at the origin and a half width/height of 2. This I think is the most logical way for people to render a sprite. You give the location in the world where the sprite will be centered at and then some attributes like scale and rotation.

I would really look into doing a spritebatcher using the technique riven poste on here a while ago. People may use the graphics object for some stuff but when they want performance, they use a batcher. Heck I would make the backend of the graphics object batch everything.

Offline Riven
Administrator

« JGO Overlord »


Medals: 1335
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #186 - Posted 2014-07-16 06:37:04 »

This I think is the most logical way for people to render a sprite. You give the location in the world where the sprite will be centered at and then some attributes like scale and rotation.
You typically want to rotate around the 'origin', which could be anywhere in the sprite. This is a good reason to create a Sprite class, to store all these variables, instead of having to deal with a method call that takes more and more parameters, as the library matures.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline StumpyStrust
« Reply #187 - Posted 2014-07-16 11:11:09 »

Indeed Riven you should create a sprite class to abstract much away but we are talking about just the batcher here which will need to know all that information in order to render properly. The sprite class would pass everythin into the batcher. That is a step ahead of making the batcher. Would also be nice to specify where you would like to rotate around I suppose.

Offline Opiop
« Reply #188 - Posted 2014-07-16 11:37:12 »

Just a little side note Stumpy, I think rendering the sprite at its center is just confusing. I think its far easier to render from the corner. In fact I don't think I've ever worked with a library that "auto" renders from the center.
Offline trollwarrior1
« Reply #189 - Posted 2014-07-16 11:39:01 »

Just a little side note Stumpy, I think rendering the sprite at its center is just confusing. I think its far easier to render from the corner. In fact I don't think I've ever worked with a library that "auto" renders from the center.

What about libgdx? I think it render in the center.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Opiop
« Reply #190 - Posted 2014-07-16 11:41:01 »

Nope, LibGDX (as far as I know) renders from the bottom left corner (which makes sense as the drawing origin is the bottom left corner) or vice versa if the drawing origin is the top left corner.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1335
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #191 - Posted 2014-07-16 12:12:54 »

Just render from a corner (it makes most sense in the low-level code) and let the Sprite class define the origin (around which to rotate), and make the necessary conversions in the code that renders the Sprite using the batcher - the 'SpriteBatcher'. Keep in mind though, that the 'rotation' parameter in the batcher is pretty much useless, if the callsite determines the point of rotation, as you'd need sin/cos to calculate the x/y offset, prior to the actual rotation - when using this approach.

It's not always best to build in layers of abstraction, as - as just described - it may introduce a lot of overhead. Especially in a SpriteBatcher, it's essential for performance to get as 'close to the metal' as possible, at the expense of (object oriented) code structure. My humble advice would be to refactor it beyond recognition.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline cebarks

Senior Newbie


Projects: 1
Exp: 7 years


Wannabe Software Engineer


« Reply #192 - Posted 2014-07-30 21:48:27 »

I've been coming up with a concept for a 2D game recently anyway, maybe I'll try to use this to prototype it! Cheesy
Offline saucymeatman
« Reply #193 - Posted 2014-08-02 23:02:10 »

I wish the utility class you made for damping was self contained and not static.
Something like this,

1  
2  
3  
4  
5  
6  
7  
8  
EasingValue easedValue = new EasingValue<float>(0 /* StartValue */, 1 /* EndValue */, 200 /* DampingTime in milliseconds */);
float x = easedValue.get(); // Get the eased value, EasingValue class keeps its own time.
easedValue.reset(); // Reset to it's StartValue.
easedValue.pause();
easedValue.resume();
easedValue.setSpeed(1); // Set the speed of the easing to 100% it's normal speed.
easedValue.setStartValue(0 /* New StartValue */);
easedValue.setEndValue(1 /* New Target Value */);


I'd make the class for you, but I lack the time : (
Offline kpars
« Reply #194 - Posted 2014-08-04 00:53:33 »

@saucymeatman:

Done. Smiley
Thanks for the great idea.



@Everyone:

In this past month, we've been working pretty hard on 4 requested things, and I'm happy to say that they're finally ready.

Here are 4 new places where you can go to learn about and discuss MERCury.



1. The MERCury Website

A portal to all things regarding MERCury. Link.

2. The MERCury Forum

A place to discuss game development with MERCury and improvements to the library. Link.

3. The MERCury Wiki

A carefully written place to learn how to use MERCury and how MERCury works. Link.

4. The MERCury IRC

A place for general chat and discussion about MERCury. Webchat Link.



So join the forum, get in the IRC channel, enhance the wiki, and do whatever you can to enhance the project!
Thanks for helping with everything.

- Jev
Offline CogWheelz
« Reply #195 - Posted 2014-08-04 01:01:50 »

Nice job, it's coming along well.
Offline jrenner
« Reply #196 - Posted 2014-08-04 13:41:49 »

libgdx renders from the corner, but also has convenience methods for setCenterPosition(x, y);
Offline kpars
« Reply #197 - Posted 2014-09-16 16:25:34 »

Hello, Everyone.

Me and Wesley had a long talk about the noise in the thread, and I think it's safe to say that there won't be any more chitchat from now on. Smiley

I actually have a big announcement to make regarding the project... Quite a few of them actually.

The project is officially over a year old now, and a lot has happened in the past year that we've been developing this.
The original goal, a full year ago, was just to make a game library for shits and giggles.

In the past few months, our project's goal has completely changed. Now we're actually making a game library that intends to just stay simple and avoid the unnecessary. That's pretty much it. We figured that if we want others to recognize this mindset, we need to turn our entire development philosophy around. To get a head start, we're officially going to rename the project to something much simpler and recognizable.

From now on, the project is just going to be called... Mercury.
That's right, I'm serious. From now on there will be no more of those 3 annoying capitalized letters.
Incase you were wondering what they were there for, it was supposed to be a cheesy recursive acronym:
"MERCury's Easy, Reliable, (and) Capable!"


Enough said about that, let's move on to the code itself!

For the past week and a half I've been tinkering around and fixing many kinks and bugs in the library. (Changelog here) And honestly, there is a lot of stuff wrong with it right now. Currently, our main issue is the staggering amount of leftover code in the library from its early days. In-case some of you hadn't known, Mercury had originally started out as a 3D library and 'downgraded' to 2D about a week in for the sake of making things less time-consuming. There were still a few tools built into the library to deliver not-so-good support for it, and now they've finally been removed in my latest commit.

I'm also proud to say that the way Core's are setup now has been completely reworked as well. I'm just going to let the code explain for itself.

Here is what your average class would be like, using Mercury just but a couple days ago:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
public class MyClass extends Core {
   Runner runner = Runner.getInstance();

   public MyClass() {
      super("Hello");

      runner.init(this, 800, 600);
      runner.run();
   }

   public void init()              {}
   public void update(float delta) {}
   public void render(Graphics g)  {}
   public void cleanup()           {}

   public static void main(String[] args) {
      new MyClass();
   }
}

While this is extremely short when compared to class setups in things like Slick2D, I figured that we could do this better and in a much more simplistic manner.

Here's how the basic layout of a Mercury program looks now:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class MyClass extends Core {
   public MyClass() {
      super("Hello", 800, 600);
   }

   public void init()              {}
   public void update(float delta) {}
   public void render(Graphics g)  {}
   public void cleanup()           {}

   public static void main(String[] args) {
      new MyClass().start();
   }
}

This is perfect in my opinion. Now the user doesn't have to do anything with the Runner nor know exactly what it does to get a basic program going. Not the biggest change in the world, but still pretty awesome I feel.

Granted, a bit of hackery was required to get this to work. All of the code for it should be cleaned up very soon, probably by Me or Wesley.

With that out of the way, there's still even more to discuss. Remember that awful Color class? We've already gotten some complaints about that one. I'm very happy to say that now it's much easier to use, yet less buggy too. I've additionally added new g.setColor(); functions that simply take in 1, 3 and/or 4 variables containing each component. So now you have the choice of either creating a new object for your colors or passing in all of the variables for one right there. Pretty neat stuff IMO. I've also re-done the color palette entirely. This time, I've decided to do it with easy-on-the-eye colors that I feel are and will be very delightful to use in different projects.

Demos of the library are also now in development, and most of the classes in the test package have been removed for the sake of keeping the library clean. The code for them tends to be very awful. I've also made a few changes regarding splash-screens, now you don't have to manually display them in your render function. I've also brought back the drawRectangle() function, for it was gone a while back and replaced with drawPolygon(). (Still not replacing drawPolygon() though)

We're only about 80% done with the renaming process and going through all of the files to make sure we don't miss anything. Right now we're still in the middle of having to update splash screens, leftover documentation, GitHub-related things, and a bunch of other junk. Feel free to contact me or Wesley to report any files/code that still uses the 'MERCury' name. The Wiki will also be updated later. So don't worry about that.

That's pretty much it really. A lot of other things have been changed, but they're not significant enough for me to need to mention them in this post. Tongue
Again, check the (horribly-written) change-log if you really want to know all of what happened.

TL;DR Update:
Core's are now much easier to setup,
We've changed the project's name to 'Mercury,'
We've turned our entire development philosophy around,
1.0.1 Beta, our first official release, will be released later within the next 1-2 months with various changes,
Many bugs have been, will be, and are being fixed.

You can download the latest build here:
[dead link]

The code is still really hackish right now and everything is still a bit buggy, so don't expect a stable build out of this.

Thanks, hopefully that can give you guys a bit of an idea of what we've been doing lately.

I've probably made a ton of grammatical errors in this post and may have not worded things too well, I'm tired from having worked on the project all night. I'll probably just make a second edit later with some typo-fixes. Tongue

Happy coding,
- Jev

EDIT: Yep, I know the versions on the JARs are all messed up. Fixed.
Offline saucymeatman
« Reply #198 - Posted 2014-10-09 17:17:18 »

Is this project still in development?
Offline kpars
« Reply #199 - Posted 2014-10-09 17:46:51 »

Yep!

We've officially been going for over a year now, still chugging along.

Also, I've fixed all of the links on the website, and as well fixed an issue in the GitHub repository where language stats wouldn't show up.

Recently we've been working on adding better controller support, making games with the library, better versioning, and cleaning up code so we can add even more features!

We're aiming for a beta release in either December or January.

- Jev

EDIT: I've edited the download link in my previous post.
Offline kpars
« Reply #200 - Posted 2014-10-10 18:56:33 »

I would just like to remind everybody here, the official website's domain has been changed to http://www.mercurylib.com/.
http://merc.radiri.us/ has been set to a redirect, so no existing links should be broken.

I also got http://www.mercury2d.com/, for people who don't like typing one extra character.

- Jev
Offline Ashedragon

JGO Coder


Medals: 27
Projects: 1
Exp: 4 years


The best person you could possibly be is yourself.


« Reply #201 - Posted 2014-10-25 17:11:51 »

Seems you've made quite a lot of progress in a year!  I do wonder if you plan on including a state based system in the future?

boo
Offline kpars
« Reply #202 - Posted 2014-11-08 08:12:27 »



It's been a while since we've said anything big about the library lately, so here's a post that'll hopefully give people a better perspective as to what's been happening recently.



General Updates & Reminder

It's ~2 months until the libraries first beta release.
We've been going for over a year and three months now, getting close to 500 commits.

December is going to be an interesting month for us. We're going to be releasing the first beta version of the library, launching one of the games we're making with it, giving the website and forum a slight makeover, lots of stuff really.

Here's the thing; to get a stable build out by the end of december, we need more people working on the library with us. If you're willing to join the team, contact either me or wes on JGO and we will get back to you as soon as possible.

Requirements:
  • Must have at least 4 years of Java and overall programming experience.
  • Must be actually dedicated to working with us on the project.
  • Must be familiar with git and have a GitHub account.

In your message you should also tell us what you would be specializing in on the library's development.
Samples of your code are mandatory.



Code Updates

GUI might be put on hold for a bit; not entirely sure. I have a lot of code-cleaning to do on it.

Shape rendering has also had some massive updates, now you can texture any shape in the library with no hassle. Plus they have more accurate boundaries now as well, so that should improve collision and intersections.

Camera rotation is also finally in; no idea why it took us so long to toss that in there.

TMX Loading might be in before December. We've gotten a lot of request to add it in, so hopefully Tiled users will be happy about this.

We might not get full-blown networking support in before the release, mainly to prevent awful code from spawning. If there are any networking guys out there wanting to contribute, send us an email.

I'm also in the middle of writing a document based on the Google Style Guidelines for Java, which we will be officially following as of the release.

The default font will also be changed from Open Sans to Roboto, just a little side-note for the typography geeks out there.



Wiki Updates

Yep. We haven't worked on it as much as we should've lately.

The wiki will be updated after the release. It would be a waste of time to write a bunch of pages that we're just going to have to update in two months anyway. Sorry to the newcomers who probably have no clue how to use the library. Sad

We have so many new articles to write for it though, mainly regarding the particle engine, GUI toolkit, scene-graph, game state manager, etc.



Hold up... Did you just say...

Yep. There's a game state manager and scene-graph now. Both are very simple to use Smiley

The implementation of both of these are still a bit rough, so don't expect anything too fancy yet. The scene-graph is still pretty bare-bones and the game state manager isn't perfect, so there's still more to come.

But regardless, I'll show you what I can.

Using the scene-graph is pretty simple. You just take any random class that extends GameObject (in this case,
Thing
) and pass in the object into the 'addObject(...)' function of GameScene.

1  
2  
3  
public void init() {
   GameScene.addObject(new Thing());
}

The rest of the updating/rendering is done for you automatically.

Adding child nodes and controlling the current objects in the graph is a whole other thing; I'll talk about that in the wiki article.

GameState is also pretty simple. It's like any other Mercury component except it has
onEnter()
and
onLeave()
functions that are called when entering and leaving the game state. The rest will be included on the wiki article.



Game Updates...?

Yep. We're actually making games with this. We aren't that bad!

We're in the middle of making this little twitch game called RFLEX. More info on it will come about later.
The website for it will be fully available once the game itself is ready for JGO to critique and play around with.

This is also why Wes hasn't been on development much lately; he's doing most of the work on this.



Let us know if you have any questions or concerns.

Happy Coding,
- Jev
Offline gouessej
« Reply #203 - Posted 2014-11-08 11:57:57 »

Hi

In my humble opinion, some classes have too much static methods, for example com.radirius.mercury.scene.GameScene and com.radirius.mercury.resource.Loader. Maybe you do that to simplify some things but it drives the API more rigid and harder to extend. Good luck.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Slyth2727
« Reply #204 - Posted 2014-11-08 15:36:58 »

About the experience cap on who can apply: it shouldn't be based on the number of years the person has been programming. While it can give you an idea, this rarely indicates the total amount of skill someone has.
Offline gouessej
« Reply #205 - Posted 2014-11-08 17:16:48 »

Care to elaborate on what you want done with the Loader?
It's difficult to plan in which environment the developers use the libraries. For example, a developer might need to use a custom resolver for URIs and URLs. If you don't use this class internally, you can leave it unchanged, otherwise you should allow the use of custom loaders. In general, I avoid writing classes with tons of public static methods and I know that it can be a limitation in multi-threading. It becomes a real problem when those static methods don't do trivial things and when they are called very often internally. I have to fix this kind of limitation in another engine and it's easier to deal with that earlier. I prefer using classes with no field than classes with only public static methods.

Julien Gouesse | Personal blog | Website | Jogamp
Offline SHC
« Reply #206 - Posted 2014-11-15 16:25:09 »

This is to notify you guys that I've successfully converted the code to use OpenGL core profile. Here's a screenshot showing you the tests that are along with the library being run on core profile.




To do this, I've made two new classes,
Matrix4f
and
GraphicsUtils
. I've removed the
VAOUtils
class completely, as it has no use, since the new code is relatively small. This
GraphicsUtils
class, is used to emulate the Matrix stack, to provide the an easy way to keep the matrices for every frame.

I've also modified a lot of shader code, and the default shader uses 330 version of the OpenGL Shading Language. Everything is working, and we are currently assuming that most people will use the standard shader, have made the process of using the shader difficult with
VAOBatcher
since we hard-code the names of the uniforms we use, and also the locations of the attributes is fixed.

I also made modifications to the
Graphics
and
Batcher
interfaces to include another void method called
cleanup
to clean the handles for OpenGL objects generated in the constructor and I've called those methods in the
end
method of the
Runner
class to ensure that they get cleaned every time.

Anyways, I'm proud to say that these changes doesn't effect the library, any existing code using this library runs fine just without porting.

Happy Time Users!!

Offline SHC
« Reply #207 - Posted 2014-11-17 16:11:49 »

Ported Framebuffer API to Modern OpenGL. Here's a small snippet showing how to use the framebuffer.

1  
2  
3  
4  
5  
6  
7  
8  
frameBuffer.use();
{
    g.setColor(Color.CRIMSON);
    g.drawRectangle(100, 100, 100, 100);
    g.setColor(Color.CLOUDS);
    g.drawString("This is rendered to framebuffer!!", 0, 0);
}
frameBuffer.release();

That renders to the framebuffer. Then you can simply get the rendered texture by calling
frameBuffer.getTextureObject()
and use it while rendering. The test renders the texture to a rotating rectangle.

And here is the FrameBufferTest running under Mac with OpenGL 3.3 (A crappy gif I could record)

Click to Play


And also fixed a small bug that caused rendering of
SubTexture
s to cause an NullPointerException. Anyways, this is so small right now.

We plan to release this somewhere between 20th and 30th of December, and there is a lot more to do. Jev is currently working on a TMX map loader, and it's going on pretty well, that should be available in his next commit. Till then, I'll be working on the documentation, and will be testing to find any bugs that might crept in.

Happy Time Folks!!

Offline kpars
« Reply #208 - Posted 2014-11-17 16:19:33 »

I'd also like to clarify that right now I'm giving the website and forum a huge makeover.

There's also going to be a showcase video for the library in roughly a week from now, so stay tuned! Smiley

- Jev
Offline saucymeatman
« Reply #209 - Posted 2014-11-17 19:45:49 »

Great work, I love the FrameBuffer API : )
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
 
 

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

xxMrPHDxx (111 views)
2017-12-31 17:15:51

xxMrPHDxx (160 views)
2017-12-28 18:11:33

Ecumene (354 views)
2017-09-30 02:57:34

theagentd (505 views)
2017-09-26 18:23:31

cybrmynd (557 views)
2017-08-02 12:28:51

cybrmynd (488 views)
2017-08-02 12:19:43

cybrmynd (462 views)
2017-08-02 12:18:09

Sralse (424 views)
2017-07-25 17:13:48

Archive (1347 views)
2017-04-27 17:45: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!