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

[BurntPizza]

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. 

[wessles]

Whoopse, forgot to mention that.

PCPartPicker part list / Price breakdown by merchant

CPU: AMD FX-6300 3.5GHz 6-Core Processor  ($109.99 @ Newegg)
Motherboard: Asus M5A78L-M LX PLUS Micro ATX AM3+ Motherboard  ($50.79 @ Amazon)
Memory: G.Skill Sniper Series 8GB (2 x 4GB) DDR3-2133 Memory  ($84.98 @ OutletPC)
Storage: Western Digital Caviar Blue 1TB 3.5" 7200RPM Internal Hard Drive  ($58.99 @ Amazon)
Video Card: Asus GeForce GTX 660 2GB Video Card  ($182.98 @ SuperBiiz)
Case: NZXT Source 220 ATX Mid Tower Case  ($53.96 @ TigerDirect)
Power Supply: Corsair Professional 650W 80+ Gold Certified Semi-Modular ATX Power Supply  ($105.98 @ Newegg)
Optical Drive: Asus DRW-24B1ST/BLK/B/AS DVD/CD Writer  ($21.80 @ Amazon)
Monitor: HP W2072a (A3M50AA#ABA) 60Hz 20.0" Monitor  ($117.58 @ Newegg)
Total: $787.05
Prices include shipping, taxes, and discounts when available
Generated by PCPartPicker 2014-06-16 19:54 EDT-0400

[kingroka123]

Wow, I envy  that nvdia 660  . 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    keep up the good work!

Games published by our own members! Check 'em out!

[wessles]

Yes, I saved up for quite a while to get this machine. Very good for gaming in general. My machine is not a good test for this, but think about it: 400K. That is a very large number. A VERY large amount of vertices. If anyone needs 400K vertices for a 2D game, they are either A) aiming pretty high, or B) doing something wrong in their code.

As for Android? That is for a whole other release (2.0 perhaps?)! I don't even have a backend system yet! That should be... interesting to make, though.

-wes

[Longarmx]

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

[wessles]

Played around more with the particles, and found that they were kind of difficult to work with. I decided to make them a tad more easy to use, and added in both Textured Particles and Rotating Particles.

The result is more than satisfactory:

Along with that, there is a nice little feature I added in. You'll notice there is a little bit of debug text at the top-left. It will stay there, no matter how you scaled the graphics. FPS and Vertices are default, but if you want to add in more debug information, call this every frame:

1	Runner.getInstance().addDebugData("Name", value);

And it works like a charm .

EDIT:
And in case you want to disable the debug, all you must do is this:

1	Runner.getInstance().showDebug(false);

-wes

[ClaasJG]

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

But I read the wiki, nice work.
-ClaasJG

[kpars]

The link in the front post is down.

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

- Jev

[kingroka123]

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?

1	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:

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

[wessles]

Texture is just data. You can rotate it while it loads, but that is not how you primarily rotate. You render the Texture to a Rectangle to rotate it. Here is how:

1   2   3   4   5   6   7   8   9

Rectangle bounds = new Rectangle(0,0,10,10); @Override public void render(Graphics g) {     // Rotate by 1 degree every frame.     bounds.rotate(1);     // Render the texture to a rectangle.     g.drawTexture(texture, bounds); }

-wes

EDIT:
That shouldn't be happening. Are you loading any other Textures with it?

Games published by our own members! Check 'em out!

[kingroka123]

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

[trollwarrior1]

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

[wessles]

@trollwarrior
No, it means that they could render 71K moving quads. ~400K vertices though.

@kingroka123
That, chances are, is the Texture of a font that is being loaded. I think I'll add an option to ignore that warning.

-wes

[wessles]

Worked on a new component today, to celebrate being back from my 8 day absence.

Meet the checkbox! _{EDIT: Now with radiobuttons!}

-wes

[matheus23]

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

[kpars]

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

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

- Jev

[wessles]

I worked on floating elements in panels today (although the changes are not pushed, as they are untested/buggy). Lots of fun/confusing maths that should be simple but continue to be a pain. Also, panels. Basically, these are invisible Rectangles that contain a bunch of Components, and organize them based on their respective FLOATS. There currently are

FLOAT_LEFT

FLOAT_CENTER

FLOAT_RIGHT

Here is a modified demo to demonstrate (I have drawn a Texture in the back to symbolize where the Panel will be).

Here is the code. Fairly simple.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15

panel = new Panel(new Rectangle(30, 30, Runner.getInstance().getWidth()/1.5f, Runner.getInstance().getHeight()/2.8f), 20);         // Add checkboxes (or any component really) to the panel         panel.addChild(foocheck, barcheck);         // Sort them into neat lines.         panel.sortChildren();         ...         // Updates all children         panel.update(delta);         ...         // Renders all children         panel.update(delta);

Window system in the future (maybe) so stay tuned.

Happy 'Murica day.
-wes

[NegativeZero]

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.

[wessles]

Oh, sorry! I probably should have emphasized that those actually are RadioButtons. Probably should have some different sprite. But I guess we will get to that when Jeviny can work on the default theme.

[wessles]

Windows!

_{Sorry for the crappy scaling on this.}

It is a Panel that is draggable, and closeable. Not much else to say!

-wes

EDIT:
Sorry, none of this is up to github. Too buggy and unstable as of now.

[Coldstream24]

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

[kpars]

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.

[wessles]

There actually wasn't much visual updating (aside from movement-based particle emission) here, but there was a mini-crisis, made worse by insomnia.

For a while now, there have been SubTextures, and Textures. SubTextures are a type of Texture, and can be rendered in much the same way. They do, however, lack the capability to clamp, and are not PoT Textures. This puts the SubTextures under incapable Textures, while real Textures go under capable textures. The idea here, however, is that SubTextures should be able to be passed in as real Textures, as one may wish to use a sprite-sheet for speed/convenience. The problem rises here, where you need capable Textures for a job, such as a repeating background.

So I now announce a new feature that will help fix these problems in a convenient way:

SubTexture.convertToTexture(): This new method can be used to convert a SubTexture into an actual Texture. This is useful for when you still want one spritesheet image, but you want a repeating Texture pulled from inside of it.

For example, the issue that caused this in the first place: the body of a Panel! It needs to be fully capable, so in order to use a Texture from the spritesheet:

1   2   3   4

// Just innocently loading a spritesheet SpriteSheet universal_spritesheet = SpriteSheet.loadSpriteSheet(mytex, allofmysubtextures); // And just as innocently creating a panel with said spritesheet. Panel mypanel = new Panel(myboundingrectangle, mybodytex, mybordertex);

1   2

// This is bad. java.lang.IllegalArgumentException: Body Texture has to be fully capable. This requires PoT size, and not being a SubTexture.

1   2

// The body texture needs capability! Quick, make it capable! Panel mypanel = new Panel(myboundingrectangle, mybodytex.convertToTexture(), mybordertex);

And with that, you may get gold like you see here:

Thanks, and sorry if this post made no sense; it is 3:30AM here .
-wes

And yes, it is on github .

[Riven]

I'd advise not to make up awkward terminology.

SubTexture.convertToTexture() makes much more sense.

[kpars]

Fixed.

- Jev

[wessles]

Well, I added in TextFields. I think I like how they turned out (functionally of course, for risk of being beheaded by Jev).

There are a few different modes of input. Here, you see signed integers, which allows numbers, and hyphens. In full, there are strings, signed floating points, unsigned floating points, signed integers, and unsigned integers.
For those unaware, signed means that both negative and positive numbers are allowed, while unsigned means that only positive values are allowed.

The GUI artwork is temporary, and is completely different than how it will look in the end. Ask Jev any questions about that; I am just writing the code .

-wes

[StumpyStrust]

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.

[wessles]

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.

I only wrote the Batcher to do low level vertex processing. The Graphics object does most rendering work. Textures are drawn to Rectangles, and so all you need to do to rotate is manipulate the geometric object. Same goes for scaling. If you meant a graphical scaling, then you can, again, go to Graphics.

Is the batcher supposed to handle these things?

[StumpyStrust]

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.

[Riven]

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.