Today, I saved the Universe with boolean logic. What did you accomplish?

Mutators and Accessors (Setters and Getters) are, in my opinion, quite a debatable thing.  Personally, I’ve always been in the school of thought that you don’t -need- them, but are needed for certain things like access control, security, etc.  For example, if you have a Person object with an Age property, you would typically never want the age of that person to be less than 0.  If you didn’t have a mutator, you would have check for Age being less than 0 and respond accordingly in all of the code that uses the Age variable.  With a mutator, this requirement is essentially lifted because you can assume that anything that uses the class Person has to use the mutator to set the Age property (which means you can check for the “<0″ condition and respond when the Age property is set, rather than everytime you want to use the Age property in your code).  This assumes also, that the Age property is private, of course, because if it wasn’t then having a mutator or accessor at all would be pretty useless.

I typically ignore mutators or accessors for a variety of things though.  One big example is linked lists.  I typically never make the Next and Previous fields in a linked list of objects private and I don’t make mutators/accessors for them.  Two reasons for this is:  Mutators and Accessors just complicate things unnecesarily and the second reason is that its just a habit, good or bad, from working with UnrealScript.  If I remember correctly, UnrealScript just had Next and Prev or rather (NextPawn, NextController, etc.) but they were just variables.  I think as far as security goes, its a bad idea, especially within UnrealScript where if you would have set NextPawn to something else while iterating through the list, you could destroy the entire rest of the list and bad things would happen then.  Thankfully, UnrealScript had the “next…” property as constants, which basically meant that only the underlying engine could set them.  Adding to the linked lists was done by the engine itself, and AFAIK couldn’t be done manually.  This added the needed security I suppose.  I’ve always liked  how that worked though, because an Accessor here would be useless, although a mutator might be a good idea.

I bring this up now only because of what I’m working on at the moment.  The GUI framework has given me an excellent opportunity to set the “standards” for the code base.  At the beginning, I just wrote code and wrote more code until what I wanted was achieved, giving some thought to “the future” but it was mostly “code until it gets done, then I’ll come back and fix it.”  I think now is that time.  I read somewhere, either an article on the internet or somewhere in a textbook (actually, it could have been Beautiful Code), that an accessor and mutator where you passed around the actual underlying object was pretty useless and stupid.  For example, if one of your classes is comprised of several other classes, having an accessor return one of those objects isn’t very “wonderful” for lack of better word.

The article goes on to say that instead of writing accessors that simply return an object, you should instead write a method that returns a useful part of that object.  For example, instead of writing a method that returns a Person object, you would write a method that returns some useful information about that object, like that Persons Age, Name, etc.  This encapsulates that Person object completely but still allows external communication about that person that is needed.  This type of things isn’t directly applicable, but the security aspect is.

Because C++ doesn’t handle pointers the way I’d like them to (i.e. garbage collection) I’ve been forced to make some decisions.  Some are stupid but needed, others really make sense in the long run.  One such example is the Location property that appears in nearly all of my classes, game related or not.  Before fixing the memory leaks, I passed around objects left and right, and set them accordingly.  If I had a Vector Location that I needed to set to another Vector, the shorthand I would use was “A.Location = NewLocation”, rather than going through all the components and setting them individually or creating a mutator that did it for me.  The result was a memory leak because the memory referenced by A.Location after the assignment turned into a dangling pointer.  The quick solution to this was to add a method to my Vector class called Set that acted as a mutator.  It simple took X, Y and Z coordinates and set the vectors components accordingly.  This solved the memory leak.  This is actually the way that its setup in the .Net framework (I… think) and even Java, except in .NET I think its really just hidden behind language features.  In Java, at least with the GUI system, you have to use setLocation to either set the X,Y coordiates, or an overload method accepts a Point object which will override the private point field with the one you specify.  You can’t actually access the Point variable, its encapsulated.  This benefit becomes more apparent without a garbage collector.

One of the things I hate about my own code base is that the familiarity present in .NET and Java isn’t currently present in my engine.  What I mean to say is the Location field, present in the majority of my codebase is usually called Location, but there are certain cases where I chose a different name.  If I aim to move to a more “secure” type of framework, one complete with accessors and mutators where needed, then I accessors and mutators are a must for most of the variables however, I don’t want to copy and paste code here, there and everywhere.  Thats the only thing that bothers me in the OOP world.  If you want something from a completely unrelated class, you have to either make it part of the base class and derive all of your classes from that base or… well…  typically “or” doesn’t exist.  Interfaces are annoying, and don’t help in that situation either.  They help with the whole naming and familiarity thing, but the functionality -has- to be implemented in a class that implements that interface.  If I were to use Interfaces, I would still have to copy and paste the same implementation across a dozen classes.    Multiple Inheritance in C++ might make my life easier though.  I could create a few classes with some basic functionality (like a class with a Location field and accessors/setters to go with it) and have all base class roots inherit that.  That might work.

The accessor problem is still there though.  If I create an accessor that simply returns a component how useful is it?  Given that the only use of the object is to specify a coordinate in 3D space there are a variety of things that can happen if I return the Location object.  Because its pointer based, they can do all sorts of horrible things to it, like free the memory, which will destroy the Location object in whatever class it belongs to.  If I return a new vector with the same values as the Location object, then I have a memory leak on my hands.  I wonder if I can solve that problem without making my code 100% more complicated.  I’m okay with establishing a rule book for myself to follow, but if someone else wants to addon to the engine ever, what stops them from breaking all the rules in the book?

Hmm.

Somewhere between stopping work on my GUI system and completely fixing the memory leaks in my applications, the work I had completed so far on my GUI system had broken.  The particular problem confuses me both because I could have sworn it was like this before I started fixing memory leaks, at which point it was working fine, and because I didn’t know it would ever happen.  I have a method that draws a specific character from a font onto the screen at location X,Y.  Whenever I pressed a letter (or printable character) on the keyboard it would draw the character until it had one line left to draw and then it would crash.  Somewhere between pressing a key and it drawing a key, the segments making up that character would get corrupted.  The printable characters of a font are put into an array (which actually makes me thing “What if the character code isn’t in the array?”  The way I grab it now, it would crash.  I should revert to the way I had it before me thinks.) which I then grab and put into a temporary variable so I don’t have to access the array everytime I need something out of the character object.  This sounds awesome in theory but because (one other thing I don’t understand) items you get out of an array become references and not pointers (doesn’t make sense because its an array of pointers), I decided just to use a reference variable instead of a pointer to the character object.  I did this because the “address-of” was giving me mixed results in the rest of my code and was annoying me greatly.  So I have something like this:

(Soure code removed.  The tags just aren’t working.  A WYSIG editor for typing in programming language source code is bad.  Please make a better way.)

Note that that the declaration and assignment are on two different lines and that the assignment is in a for loop which is looping through all of the line segments in the character object.  Drawable is a pointer to the character object in question.  Now, in the for loop, it basically just sets up glVertex for each line segment (which should actually be converted to my wrapper for that, so I don’t have OpenGL code running about, when and if I decide to convert to OpenGL 3.1.  So the method just goes through the array of segments and the line segment gets drawn around the character origin.  Good so far, except that it crashes on the last line segment.  The endpoint array (each segment is comprised of two vectors, a start and end point) ends up getting freed.

The only place I “free” the end point array (and the only place I ever need to) is in the destructor of the FontSegment object.  One breakpoint later, and sure enough the destructor is being called.  So here’s what is happening.  The seg variables is assigned to each line segment.  Reference variables are automatically freed when they go out of scope (at least, as far as I understand it) so, when the last line is drawn the seg object goes out of scope and the last thing it is set to is the last segment.  So what happens?  The memory is freed.  The assignment isn’t by-value, as far as I can tell, its by-reference and so as the seg variable is freed from memory, so is the last segment in the array.  Then the next time the character is drawn on the screen (next cycle) the character is drawn up until the last segment and then it crashes because the memory was freed.  I changed the seg variable to a pointer and all is well again.  And now I have a new reason why reference variables are not what I should be using for a Game Engine.

Pow!

After I fixed the memory leaks in my font editor application, I started to work on fixing the memory leaks in my level editor application. I have a method that accepts a few pointers to a Vector class (not std::vector). It basically draws a line from VectorA to VectorB with the specified color VectorC. In my font creator, the Line Color was known to be constant, i.e. When you’re in the process of drawing a line segment, the line segment appears Red, and all other line segments that have already been drawn are Black. Because of this, I don’t waste lines of code by declaring a variable to store these constant colors. I simply declare the vector as I’m calling the method. I.e. MyMethod( new MyClass(…)); To my surprise, this actually causes a big problem. In “modern” programming languages, doing something like that is no problem at all. I might argue that it is, in many cases, the suggested way of doing things. In many cases, it might be a good idea to store a constant like that anyways, to make future changes to that constant a non-issue if there are 100 instances where it is used. In this case however, that isn’t a problem at all. The font creator application is small, and will remain small, for its lifetime, however long that may be, and at most, it requires one change for Black and one change for Red. If you pass in a parameter like that in a modern language, it eventually gets properly freed. I don’t know why that is, but I assume it is the garbage collector who you can thank for that. If that is the case, then I would argue that Ownership of variables (and freeing said variables) is immediately transfered to the Garbage Collector. In C++, there is no such thing as a Garbage Collector. I’m going to go on a bit of ramble now, but just for a bit.

“Raw” pointers are apparently a C thing. I say this because I’ve first read people saying this and the C++ standard libraries give you access to “auto pointers” which apparently handle freeing of themselves. According to some posts on a Stack Overflow question I made, C has no concept of Ownership at all, hence pointers not caring who frees them, just that they’re freed by someone. C++ however has all of this Ownership in place, or should at any rate. The developer needs to decide how Ownership is used. When calling a method, do you let them Borrow the objects passed in, or do you give it to them and let them deal with them. This becomes a problem with myMethod( new myClass(…)) because in that case, the Caller can’t possibly obtain ownership of that variable, and if you give the Callee the Ownership then something is going to break if an object stored by the Caller already is passed in.

So if you ignore the standard libraries (which I have tried hard to do… regardless of best practices, maybe I’ll discuss why at the end) and then ignore Boost (Which I don’t think is part of the standard library still) then you’re left with Four options. The first two aren’t really options, as your application might break at some point.

1. You can assume the Caller owns the objects being passed him and let indeal with the management issues.
2. You can assume the Callee owns the objects being passed in, and let it deal with the management issues.
3. You can use reference types instead of pointers and pass in the address-of each reference type (or completely change my codebase to only allow reference types)
4. You can create your own Garbage Collector

The second option sort of is valid, but that would require me to enforce a “rule” that pretty much counters what you should be able to do.  I would have to force all of my code to conform to a rule that I don’t like very much in the end anyways.  Then there is also the fact that pretty much every method I call uses the “create object in parameter” syntax.  This is because passing pointers around is sometimes a bad idea.  I generally don’t need change data in variables passed in, but when I do, its generally not changes that need to be permanently made.  So I make copies of the objects that I need to pass in, instead of passing in the actual object.  If I followed option 2, I would have to make temporary variables then free them right after the method call.  I think that is particularly bad and it just bugs me.

The third option would require a great deal of work in converting over all of my code and even then… besides the memory management “benefit” which I don’t fully realize as a benefit, but apparently its a “good thing”, it will probably create problems in the long run.  I need to dynamically create objects because thats pretty much how the game engine will work.  Need a weapon to be spawned at location A?  I’ll spawn a weapon for you.  I could be very wrong, but I don’t think reference variables are a good idea for something like that.  Aren’t they imutable too?

So that leaves option 4.  I’m all for doing large and complex tasks JUST BECAUSE.  This particular complex task would be very educational though, and I could say “I did that.”  Not to mention when I start working on my language again, I’ll have something to use for that if I decide to make it from scratch, rather than use an existing language to facilitate it.  In my mind, writing a garbage collector would “easy” and “fun” but in reality, I think it would be the exact opposite.  But here is the general idea that I’ve come up with in my head.

If I were to build it, it would hold a linked list of “memlocation” objects.  Each memlocation object would have the pointer, and a string denoting a variable name?  Not sure actually.  But each time a pointer is allocated, it’ll be added to the list.  Each item in the list will have its own sub list.  Each list will essentially be the pointer and each item in their sublist would represent a variable that is referencing that memory location.  When the sublist is empty and a garbage collection is taking place, the memory is freed and the pointer item is removed from the list.  Sounds simple, but I don’t quite understand the theory behind what I’ve read… at least not about how to identify whether memory needs to be freed.  How do you decide when a pointer isn’t being used if the whole point of garbage collection is to get rid of the need to manually free memory?  I think I’ll need to do more reading before I decide on anything.  A garbage collector would make things easier, if it worked right and was fast/efficient/awesome.  It seems like the more work and the more insane, but if I’m working on a game engine that will eventually have its own scripting engine, a garbage collector is probably neccesary, no?

It is becoming more and more apparent why independent developers turn to existing development solutions for their games and other software. Designing an Engine is extremely easy… on paper. Implementing it is another thing. Sure it might be extremely easy at the start and you’ll be having fun, but it is turning out to be something I wasn’t really hoping for. Designing this GUI system – something that is supposed to be very simple and wouldn’t provide too much functionality (yet). Just something in place for me to get some development applications prototyped with a nice user interface. For some additional fun, I made the decision to make my own font system, rather then implement an interface for TrueType, etc. which probably would have been a lot easier than making my own given the material for such things on the internet.

Its not that writing my own font system is hard really. I like the one I have really. Its not the font system I despise, but the fact that you actually have to make that font. The whole font system is still in prototype-mode, so the font editor app I have has no real User Interface except for clicking and dragging of the mouse (to make lines) and the use of the keyboard to go to the next character and then to save. I also have (or had, I think I fixed it) an intermittent bug where at some point while making line segments for a character, the heap would get corrupted. This happened to me while I was halfway through characters 32 to 126. I was not happy. The quality of the characters produces is also very horrible. This is partly because I have no grid or size-comparision method whatsoever, and because I didn’t want to put a lot of effort into making test characters that will be replaced with better looking characters in the future anyways. Bottom line: My font creation application needs an Undo, a grid, and “previous character” keystroke, a GUI (which I can do right, now that I have a full-ish font to use) and I should implement bezier curves.

Back to GUI talk, designing it just seems to be very difficult. It should remain seperate from the rest of the code yet still play nice with everything. First you need to think about how the developer will add and use the GUI components (textfield, label, button). In Java, if you want a button, you need to create a frame first to put the button on. It has that affordance because its primary use isn’t as a 3D engine, but after it plants that rule down, a 3D engine can easily be built with full GUI functionality. A 3DFrame class or 3DPanel class can be used alongside any other GUI Component. I don’t have the same good luck. Creating an OpenGL Window wouldn’t be the same as a Frame. My GUI system has to exist within the context of OpenGL so I can’t open up any frames that exist outside the bounds of that Window, so in reality, the OpenGL Window -IS- my frame.

Right now I can add as many GUI components as I would like to but the components must be drawn within a corresponding “GUIRenderer” statement (i.e. the openGL renderer needs to be set to a decent Orthographic) which really isn’t a requirement if I wanted to create 2D controls in 3D space. Components can be moved around at will, i.e., there is no layout format that needs to be used. Each component is absolutely placed on the screen, not something I’m terribly fond of, but it’ll probably change at some point. Its still all in prototyping/testing mode. I love absolutely placing things, like the way Visual Studio etall, but I also love Java’s layout system occasionally (although Love turns into Hate very quickly sometimes)

The bigger implemenation issue I’ve come across however is the “focus” mechanism. If I have 20 components on the screen in my application, all of them text fields, which one should get focus? I know the answer is “whichever one you have tabbed to or have clicked on most recently” but implementing that decently is a bit of a challenge. I’m not sure how Java or VisualStudio handles it, but I imagine it has something to do with the Frames/Forms that the components must be added to. So, I created a class called GUIBaseOverlay which simply holds the head of a linked list of components. This class will be responsible for determining focus, click, etc. as well as to order the drawing of all the components in the linked list. (Here I chose a linked list over a dynamic array because dynamic arrays are huge pain to implement in C++.) This won’t stop you from drawing each component seperately, but your application just wouldn’t work right unless you kept track of certain things (like focus) yourself.

The text field component is another area of annoyance. I figure most input systems like that merely take in all keyboard input and add what it can to the text field and ignore the rest. Due to the fact that my Input System hides SDL events (it doesn’t really, just provides a mechanism for trapping key/mouse/whatever events) getting keyboard input like that is a bit tricky. I don’t have a method for direct input, unless one reverts to straight SDL (which should all be wrapped) which you can’t really do if you use my input system because we would run into the problem I had near the beginning where I was checking events three times in my application but events get removed as they’re inspected so by the time “event checker a” tried to catch a mouse down event, it woundn’t find one. So I might list of keydown sequences that occur and manage it within my InputSystem’s update method. Then using this list, I could check to see if a valid character is present and add it to the text area. Actually, that might work.

Right now, I have a long series of if statements, one set if any of the shift keys are down and another set if they aren’t. I’m not trapping all the printable characters, but most of them, and it works just fine, but I really, really want to trim those if-statements down to like… 5 statements max if possible.

Anyways, thats the rant for today.

On a side note, the OpenGL 3.0 and 3.1 books I ordered just arrived. I really think they were stupid to just mush everything together, 3.0 and 3.1. The least they could do is give them both absolutely separate sections in the book instead of add the “COMPLIANT MODE” side note crap. If you’re going to write for 5 pages about something I can’t even use in 3.1 and then not suggest the new alternative method of doing the same thing, than what was the bloody point?

I’ve recently moved all the source code from my seperate project folders into on large folder for source and header files. This will improve my own organization and will aid in any changes I need to make. This however, caused a lot of issues with Visual Studio. Sometimes it grabbed the wrong version of the source. At one point, all of my projects decided to start failing at the Linker phase. The different apps I have right now (The game, editor and font creator apps) all use mostly the same set of source code and header files. Before, the core source files were in my game project folder so any headers/source files were added as existing items to my other projects and each project had its own compiled source. This was only because I thought DLLs were my only option as far as shared libraries go, but I guess LIBs (static libraries) can be used just as well as DLLs. I haven’t really seen a LIB that shipped with a Windows application, only DLLs so I wasn’t quite sure. DLLs looked like I had to do a whole lot of extra stuff just to make it work and when I looked at it initially, I didn’t have two other projects to deal with that used the same source code so I decided not to waste the energy.

Now, having the same source code used over a variety of projects has created just a head ache. Visual Studio’s default project directories are just a mess really. Recently, I was spending a lot of time on my Editor app. One thing that came up that I needed was File IO and GUI objects. So, I create the headers and start working on the source. The problem is that if you don’t pay attention with the “New Item” dialog, you’ll end up putting all new headers/source in the folder of the currently selected project tree. This causes the unneeded stress of having to either move over these “core” source files (File IO and GUI stuff is needed for both the editor all other apps) into the “core” folder (at that moment in time, it was just the Game app folder) or I could leave these files in the Editor project folder and add them normally to the Game project solution. The problem with the first solution is that it means adding the source and headers to Project A then removing and re-adding them to Project B (as the files would be moved breaking the existing entries). This is just a large hassle. The second solution means that you have common source files and headers seperated into two distinct folders that house projects for two distinct applications. If I for some reason decided to delete my editor folder, the core files would also be lost, breaking Project A anyways.

So I decided to finally get a working library and because I decided this after I moved all source and header files into a common directory, it made setting up a library a lot easier. Now however, I’ve realized a lot of things I need to still change. For example, the game architecture is similar to a lot of game engines. Each level is represented by a level object which holds all of the information about the level. This is potentially a common class, i.e. it’ll be used in the workings of the game, but will also be needed for the level editor. The class workings of this however was put into “GameComponents” which, even though poorly named IMO, is actually only game-specific items that will only be used by the game itself. Specifically, the game driver class, which sets up the engine and gets everything ready for the game application. The Level class may have been better placed in the GameObjects file, where all the game specific engine objects, not really tied entirely to the game itself, are held. An example of one would be the PhysicsAffector object which places some sort of Phyics-based effect on physics object that comes into contact with it (i.e. a player going into a low gravity room.). Now this sort of stuff will only ever be fully utilized in the game(s) themselves, but will also be needed for the Editor and for scriptable-object support later on. I tend to rant on far too often. Short store: GameComponents should only include things related to the required classes needed to initialize the game itself. Because it had other needed classes (Level class), my projects yelled at me about linking issues. It confused me greatly until I remembered that GameComponents wasn’t being built into my central Lib. Which brings me to…

Header files are beautiful. All “core” headers in one single “loader” header makes things nice and happy. That is all.