Mercury: The Simple 2D Game Library | >> BETA coming soon <<

You do handle triangle-circle collisions, or rectangle-circle?

If you are using maven, which is a great choice. You shoul get rid of any project folders from any IDE, configurate everything in maven.
If you need help with a proper .gitignore file, go to: gitignore.io

I may be flat wrong on this, but aren’t most things limited by fillrate rather than vertices? Also, stating what hardware you accomplish those numbers on would be a good idea I think.

Otherwise, cool stuff going on here. :slight_smile:

Wow, I envy that nvdia 660 :point:. You have a really good machine. Right now I have about the same power in everything but the video card. I have a radeon 7750, it gets the job done but I need to upgrade for next gen titles and the 660 is what I’ve set my sights on.

Now about that stress test: Really nice. Do you plan on android and ios versions being released because that would be very nice. Also, since your machine is so good, try testing on a slower device like a laptop just to be sure of the. Performance. Really good job with this ;D keep up the good work!

That card is unlocked correct? I think I have the same one. :slight_smile:

The link in the front post is down.
http://weslgames.github.io/MERCury

But I read the wiki, nice work.
-ClaasJG

Don’t worry. The new site should be up soon.

  • Jev

Ok so I’m using this code in order to rotate a texture. I feel like I shouldn’t have to reload the image each time I want to rotate it so is there any other way of doing this?

sprite = Texture.loadTexture(Loader.streamFromClasspath(path),(int)deg,GL11.GL_NEAREST);

[Edit] Also this keeps popping up everytime i rotate the image in this way:

WARNING: The provided Texture is NPoT (non power of two). Non-pot Textures cannot use GL_REPEAT. 

My texture is 64x64 pixels and I’m not using GL_REPEAT so shouldn’t this not be happening?

I am also loading a 16x16 texture but I am not rotating that one

@Wessles
I was looking at your stress test. Does your stress test mean that I could render 100k moving quads at 60 fps?

From what I can see, you have static geometry, and your quads are really small.

Make the checkboxes’ texture change, when you mouse-over. That makes the UI look much better and make it much more usable :slight_smile:

We’re going to be including a default Look & Feel in the future, don’t worry… Those buttons are just for testing really. :stuck_out_tongue:

It should be really fun to make… For me. It’ll most likely suck for Wesley.
I don’t have an issue with that. :slight_smile:

  • Jev

For the last three options, they are a state rather than parameters, meaning that it is more intuitive to use radio buttons rather than checkboxes.

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

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.

I’d advise not to make up awkward terminology.

SubTexture.convertToTexture() makes much more sense.

Fixed.

  • Jev

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.

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.

[quote=“StumpyStrust,post:179,topic:44384”]
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.