Hello guys, SharpMid here!
I know that there are some other programmers out there in the forums. Most of you are JavaScript script kiddies that have never heard of a pointer and some of you might be familiar with Java, C# or C/C++. If you are you are also familiar with Object Oriented Programming (OOP) which is what this post is about.
Object Oriented Programming:
If you have gone to school or will go to school studying programming or computer science your teacher will probably spoonfeed you with information regarding OOP, Object Oriented Analysis (OOA) and different patterns or design principles. They will tell you to go through the process of modelling your programs after the real world (Domain Model) and from your Domain model construct software classes and doing several different diagrams in the process using the Unified Modelling Language (UML). This is something I was spoonfed everyday when going to University and I would like to take some time explaining why it is all a load of bullshit.
Lets look at some some examples that display some really basic OOP design, The examples are in C++:
[image: i.imgur.com]
In the code above we define a class Entity which could be the foundation object within a game or something similar. We want all our objects to inherit everytihng within the Entity object so within it we define properties that all elements should have which is a position, orientation some flags and a update function.
Then we define two new objects that inherit everything from the Entity which then becomes the Parent object. Let's take Human for example, the Human in our case will have all the properties defined for the entity and also have a name property and for the Human we override the Entity's update function with its own.
What happends here in C++ is that C++ creates a virtual function table that keeps track of which update function to call for each object so when calling update on a Human the Humans update function is called instead of the underlying Entity.
This is pretty cool since we can treat every object as an Entity and have shared functions such as:
do_something(Entity* entity) {
entity.update();
}
This is pretty cool since the function doesn't have to just operate on Entitiy objects but also on the child objects such as Human. In this case if we would pass a human to the do_something() function the Human's update function would be called instead of the Entity one.
Problems with OOP:
The code above may look really cool and very neat but there are some issues regarding it and it is that all different objects will be of different sizes and we cannot use simple data structures like arrays to manipulate our game objects because of it. This will result in our heap with our allocated objects being completley cluttered with objects being allocated in very different places. Which will result in cache misses, etc..
You might think that this is fine for your small projects but even for simple projects around 50 classes or so will suffer of performance issues because of this. This is why we bring in Data oriented design into the image which is here to help us write a lot better code.
Here is a visualisation of how the heap could look comparing object oriented design OOD and Data-oriented design DOD:
[image: i.imgur.com]
The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, getting rid of virtual functions and vtables, easier parallelization, no (or minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.
I strongly suggest you to watch the following YouTube video and I've included some more link for the ones interested in Data-oriented Design.
https://www.youtube.com/watch?v=rX0ItVEVjHc
Resources:
https://github.com/dbartolini/data-oriented-design
https://mollyrocket.com/casey/stream_0019.html