The year began with a review of terms that we need to know and so will I. The most important things that I now know are:
Heap
- Essentially this is a specialized tree-based structure that is not ordered in any particular manner. The highest item (or lowest, depending on how you look at it) has first priority in regards to the tree's accessibility and is commonly referred to as the root of the tree - or root node in more common coding terms.
Stack
- Works much like a pile of plates. A stack can see what is on the top of the pile, and can remove the top object or place an object on the top, but cannot access any items in the middle or on the bottom until the ones above it have been removed.
A pointer
Base *b;
Can be set as:
Base *b = new Der(); **Where Der() is the class the Base is derived from.
BUT
A pointer
Der *b;
Can NOT be set as:
Der *b = new Base();
That was something I already had a good idea about, but having the information solidified in my mind by a professor of mine was a nice confirmation to have.
Smart Pointers
- Unlike raw pointers that invalidate other pointers when they are assigned to the same data, and then delete that data, smart pointers keep track of the number of pointers that are pointing to the same data. This helps us to keep track of whether or not we can delete the information being pointed to without ramifications, and if one of the pointers for a specific piece of data wants to delete the data it is pointing to, that pointer itself is removed, the data remains because other pointers are pointing to it, and the other pointers remain unaffected and continue on as if nothing happened.
-The only downside, and it's a very small one, is that smart pointers have to keep track of a counter of how many pointers there are that point to the same data. This harms performance, but the effect is VERY minuscule.
Something that I learned that I needed to 'facepalm' over due to having made this mistake many times in previous years, is that a declaration of "using namespace <namespacenamehere>" should never be used inside of a header (or .h) file. I had no idea that this was such a poor practice or structure for a program and have learned not to do so very quickly.
Entity Component Systems
Scene Graphs vs Tables/Containers of Data
The problem with scene graphs is that they are too easy to use, and are not optimal for machine translation (ie inefficient/slow). Being too easy to use is a downside due to our human understandings and perceptions of this concept being so incredibly different than that of a computer's.
Scene graphs are essentially a type of tree that looks like this:
http://archive.gamedev.net/images.gamedev.net/features/programming/scenegraph/image001.jpg
This is a very basic idea, where at the center of a galaxy/solar system there would be a star. That start would be linked with planets through a rotational value of some sort that would make the planets spin around the star. Connected to those planets might be a moon or two, also connected through rotational values. This is how the human mind perceives a solar system setup whereas a computer would much rather have that information organized in a simple list because all it needs is raw data, instructions on how that data should be organized, and the means to do so. If the data is already pre-organized in a way that the computer is set up to recognize and it is fed to the computer in that way, the efficiency of that program increases drastically, and that is optimal for all code.
The Key Model
Essentially the key model is a way of looking at an entity component system and how all of it's parts fit together to perform the actions they are made to perform.
A blank key shaft is what we would consider an "entity" or object. That is all it is, and it can't be used for anything until is has components that it can insert into a system for use.
Components that are added to an entity in relation to game development are things such as adding health, a position, a velocity, and a sprite to a player entity.
A system is a set of calculations or instructions that when given components to use in their specified instruction sets, will return new values to those components. An example would be taking the previous player entity's position and velocity, using them in a movement system that would enter them in a calculation to make the player change locations in the world, and return those components their new values that would result in the player having a new position and a new velocity.
Small/Short Tidbits that are very helpful:
Pointers = Low Level Programming = FAST (ie use pointers often! but well)
Professor Khattak loves to drill points into our brains, which is good because repetition helps the mind remember better than anything.
Avoiding the "Virtual" keyword, inheritance (because it leads to doubly linked/included items and that causes way too many problems to want to deal with), and making classes extensible (small more organized classes that work together for bigger pictures are more efficient and clean).
Refactoring -> remaking code to do the same thing but BETTER (preferably :P)
I also learned that professor Khattak started by referencing an engine I didn't even know existed, and that doesn't surprise me, but I found it interesting and so I plan on doing the same.
I hope you learned something from this, or that you at least found something you didn't know, OR it was just a nice refresh.
Thanks for reading,
Brayden M.
No comments:
Post a Comment