+- Forums (http://www.scratchpadgames.net/forums)
+-- Forum: Main Forums (http://www.scratchpadgames.net/forums/forumdisplay.php?fid=1)
+--- Forum: Scratchpad Games (http://www.scratchpadgames.net/forums/forumdisplay.php?fid=2)
+--- Thread: Optimizations (/showthread.php?tid=16)
Optimizations - Brian Beuken - 02-20-2018
Readers of the book will have noted that many times I pointed out that there were better ways to do many of the concepts raised.
In fact the way most of the code was written it is very obvious that there are better ways, but I took a decision not to go into much detail on that, simply to allow new users the chance to get totally comfortable with getting their code to work. Forcing people to optimize code before they have fully understood what they are doing is a recipe for disaster, so for me it made sense not to get into that in the book, just show the basic code, get it working and once its working, then is the time to explore how to make it work better.
It would be nice to have a discussion here on how we can improve the performance of our projects (by quite some amount) if we were to use a more effective render system, and implement some multi core work. I'd love to hear your thoughts on how you can improve things, and show some results to inspire others to really get that code moving.
RE: Optimizations - Brian Beuken - 04-14-2018
I was asked on a Facebook forum what design patterns were used in the book.
I explained I was using a simple baseobject/derived from format, commonly known as Flyweight. I then was criticized for using an outmoded and inefficient pattern!!! Oh well its the internet and everyone has an opinion on whats best and is happy to tell you.
But it's true.... I have never ever denied that the code in the book is very inefficient, but....
It is very easy to follow. I mean very easy to follow, which is what the books intent was, to create an easy to follow path of progress, despite the acknowledge inefficiencies.
But what are those inefficiencies? Well one relates mainly to the fact our OpenGLES2.0 GPU is not able to handle instances of objects, (well not directly) Meaning that though our code is easy to follow and expand, when it comes to sending it to the GPU the 1 group of draw calls per model is a bit of a frame killer.
Also if you don't produce a good quality base class and carefully design your classes, you can find yourself constantly adding content to the base class.. resulting in bloat, and redundancy in the base class which some/several derived classes don't need.
But I don't personally feel these are major issues, flyweight is easy to implement, easy to debug, and importantly easy to visualize. It tends to be my goto method for smaller projects.
Game programming patterns is a popular topic with coders who have gone past the beginner/intermediate steps of their development, there are many good books on it Robert Nystrom's Game Programming Patterns, is pretty much an industry standard. Feel free to read about flyweight (ignoring the suggestion to use instancing) on Roberts site, here, http://gameprogrammingpatterns.com/flyweight.html, and check the rest of the site out for other options you might try. His entire book is online, not sure I'd be that brave
RE: Optimizations - Brian Beuken - 04-21-2018
Why no indexing on our vertex data? Its showing in the simple 2D stuff but not the 3D.
So you can do it....that's honestly the only reason, I want the reader to discover indexing and change all the demo's to use it. It will immediately give you a performance boost, and you can take all the credit.
RE: Optimizations - Brian Beuken - 04-25-2018
Why am I doing shader setups and renders on a per model basis?
Yes indeed....why am I
For those who still don't get it, that's a HUUUGE clue to some potentially impressive optimization options.
Still need a hint? Remember the less you communicate with the GPU at run time the better, but there's no harm in spending time during a game init setting important (slow) things up.