Hello, I am developing an engine for a game that I want to create. Though I have hit a wall. So far, I have created many classes that implement vertex arrays, vertex buffers, shaders and textures. Though I am unsure how to organise these classes in to a working engine. I can construct single vertex arrays and buffers to display a simple textured quad, but I could not imagine how to manage a whole game's worth of objects. Any suggestions? Here is my code so far: https://github.com/Harris6310/Novum

I was thinking along the lines of having a Sprite class that would contain it's own vertex buffer. Though I wouldn't know how to go about this.

I'd create an Image class to abstract what you have, so you can just do something like Graphics.drawImage(Image), and then you can have your Object class that contains an Image, as well as all the moving logic and whatnot.

I'd create an Image class to abstract what you have, so you can just do something like Graphics.drawImage(Image), and then you can have your Object class that contains an Image, as well as all the moving logic and whatnot.

Okay, what would be the best way to access a vertex buffer from the Image class?

Take a look at LibGDX, specifically the SpriteBatch class. It's not the best-organized class (it fails to separate the GLES2 renderer from the other with anything other than a bunch of if/else statements sprinkled throughout) but you still get a good idea of how to do geometry batching. You don't have to clone it, it's just an example of how you might do one particular sort of object management.

Object management is pretty specific to the sort of game you're writing, and it's one of the things that distinguishes a good engine from a great one (just ask princec about managing VBOs). OpenGL makes it a lot harder than DirectX (where you have things like swap chains managed for you) but on the other hand, being forced down to a low level means you at least get control at that low level.

Take a look at LibGDX, specifically the SpriteBatch class. It's not the best-organized class (it fails to separate the GLES2 renderer from the other with anything other than a bunch of if/else statements sprinkled throughout) but you still get a good idea of how to do geometry batching. You don't have to clone it, it's just an example of how you might do one particular sort of object management.

Object management is pretty specific to the sort of game you're writing, and it's one of the things that distinguishes a good engine from a great one (just ask princec about managing VBOs). OpenGL makes it a lot harder than DirectX (where you have things like swap chains managed for you) but on the other hand, being forced down to a low level means you at least get control at that low level.

Okay, I am going through the class but I cannot tell what is going on. The SpriteBatch has a draw method which calculates vertices and then passes them to a mesh. Then the mesh has a render method which calls glDrawElements. I can't see were the vertex arrays and buffers are bound.

I have been going through the code and the tutorials by mattdesl. Do they do it by loading new vertex data to the buffers at every frame? That's all that I can figure from it. Wouldn't that be very slow?

Well given that libgdx is also an android platform and there are plenty of games and there is years of development behind the framework, I think it's quite safe to say that the performance is quite okay if not very good and those kind of obvious bottlenecks should come out very very fast.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Well given that libgdx is also an android platform and there are plenty of games and there is years of development behind the framework, I think it's quite safe to say that the performance is quite okay if not very good and those kind of obvious bottlenecks should come out very very fast.

Yeah, I figured that, that's why I don't think I have worked out what's going on in the code properly.

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