So I'm teaching myself OpenGL ES since I want to use it in Android game development. Prolem is... I over-analyze things, thus I keep questioning myself about whether I'm thinking about things the right way. I started my endeavor by doing a simple 3D cube from the book "Hello, Android!" - the base elements of which I am expanding upon for the sake of learning OpenGL stuffs. Now, the lesson required me to create a cube - GLCube was the class name, a renderer - GLRenderer, which implements GLSurfaceView.Renderer, and a new view - GLView which extends GLSurfaceView. For the lesson I followed I declared a GLCube in the GLRenderer class and handled that, but I thought... if I was going to use OpenGL for games, I gotta handle things differently - time to experiment with different ideas. For the sake of extending that which I've already done, I instead of declaring a GLCube in the GLRenderer class declared a linked list object that takes in GLCubes, put in a function that takes in GLCube objects, and pushes them onto the linked list I created. I then changed my onDrawFrame function so it didn't do anything if the linked list was empty, and if it was not empty, called the draw function for my GLCube class, pops that off the linked list, and rinse/repeat until the linked list is empty, that way it only draws/renders objects that need to be - which will be pushed onto the linked list when updated in such a way where re-drawing them is required. Obviously if I were to do serious game development, the linked list would take whatever type I want rendered, again I'm only extending what I've learned so far, but I wonder if my thought processes are at the least on the right path/track. I mean, reducing onDrawFrame's behavior to when it has stuff to draw, making it so you add objects for it to draw seems like a logical step - and more efficient than what I started with, but again I over analyze the shit out of things since this is not so much learning OpenGL as an issue with program structure that IMO at least partially comes from how it is explained.
In a typical situation you have a class that has the model's geometry as an array of Vector3's, texture coordinates, normals, index to the texture(s) used and material properties. Then from the arrays(polygons, texture coordinates and normals) you generate Vertex Buffer Objects which are a way to draw all polygons in the mesh with 1 draw call. Now for starters you may want to start with only geometry VBOs, and then gradually expand your knowledge/codebase when you get the need for that, when you want to put textures on the models, or for them to not look flat when rendered, or to have different materials. You might want to decide what you are going to learn at first, ES 1.1 or 2.0. 1.1 is fixed function only, 2.0 is shaders. 2.0 is not backwards compatible, though you got the option which to use on all devices that support 2.0. 3.0 is backwards compatible with 2.0. Don't overengineer stuff or think if its right or wrong to do certain way. Do it in a way that does the job. When you get a performance drop(dropping to a 3 digit FPS does not count) or want more features, you'll profile and improve the bottlenecks. I've seen too many people trying to make "the best engine" and moaning about things like L2 cache misses which may theoretical degrade performance, yet the mandatory driver calls that surround that code are orders of magninute slower, making the optimization meaningless.
There's this thing in the English education system, which may or may not be getting stamped out by Michael Gove, where rather than teach useful skills which you can apply to real-life situations, lessons degrade into teaching you how to pass a specific test. I managed to get through GCSE German without being able to have a meaningful conversation - you just had to know where to find the train station, because there was guaranteed to be a question about directions and a list of possible destinations (LIBRARY! SUPERMARKET!) Online tutorials like these are often exactly the same thing - it's literally a guide on how to (I'm guessing) make an app showing a rotating cube or whatever, not really how to build a rendering engine because... there's a weird perception that you already know how to do this. Being able to piece bits of code together is something you tend to grow into, but things can be enormously frustrating if you're not at that level yet, and it takes a while for lots of people to get to that stage. And there's the OpenGL 1.1 =/= OpenGL 2.0 noise and that ever present question as to why modern devices don't implement full OpenGL so we can abandon ES altogether. I've not spent too long messing with this sort of thing, but basically you want a renderer class with the express purpose of drawing triangles (with colour/texture/whatever data) on the screen. Other classes would house lists of triangles and pass this data to the renderer in some form. You'll have to work out the specifics of that. 2D might be easier to get your head around. The plus side is if done properly, you could exchange that OpenGL ES renderer for something else (say, a Direct3D one), which too would just take triangles, and you wouldn't have to adjust any other code. Also watch out for stupid coding conventions. Like here, someone's called it a "GLCube" class, when in reality it has nothing to do with OpenGL. And classes declared within classes might come back to bite you at a later date.
Not if I wanted to program on the Android or iOS platforms I bet... unless they somehow got an implementation of D3D which I doubt. :P Yeah, I really should correct my post - I declared an instance of the class in the renderer instead of keeping such declarations outside of the renderer - and passing said object from wherever it was declared from to the renderer like I do now. I guess my real question is if I am starting on the right foot in taking it out of the limited confines of what I've been shown and into more functional uses by doing what I've done - make it so you pass objects with the data to be rendered to the renderer AND changed the renderer so it only redrew when it had stuff to redraw instead of redrawing everything every bleeding frame, when most if not all of those things may be doing nothing.
What are your reasons against redrawing every frame from scratch? Performance concerns? It takes more effort programming wise to draw only some parts instead of everything, and you likely wont see a change in framerate. Also it is only applicable to static 2D board games(poker?), some hud and some UI.
Pretty much cutting out as many unnecessary tasks, as much unnecessary work as possible - which for me includes, perhaps moreso in a 2D game using openGL - re-rendering more than what is absolutely necessary. It's just how I learned programming, how I was taught - to cut out as much unnecessary shit as possible, and make things perform as efficiently as possible... and when it comes to graphical stuff, rendering is very expensive, so if I can cut out what isn't absolutely necessary - so long as it doesn't make performance WORSE, of course - why not? The other problem is with target phones of those who may want to use my apps. Actually, the problem mroeso is with the bloatware that carriers [T-Mobile, Verizon, etc] put on - without rooting, some can't be removed at all, just disabled, some can't even be disabled ON TOP OF not being able to uninstalling them. Not everyone is gonna have the know how, or will to learn how, to root their phones to remove them, or even disable them, meaning they will sit on their phones eating up more memory and CPU time than if you could disable and/or remove them. This certainly will affect performance, and while not something I can actually change, it is something I can adapt to in some way/to some extent.
