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!

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.

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:

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

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.

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.

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 spritesheetSpriteSheetuniversal_spritesheet = SpriteSheet.loadSpriteSheet(mytex, allofmysubtextures);// And just as innocently creating a panel with said spritesheet.Panelmypanel = newPanel(myboundingrectangle, mybodytex, mybordertex);

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 .

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.

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.

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.

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.

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!

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