Game Engine: Update 27

Progress has been slow lately, but the things that did get done so far are pretty significant for long term development and goals.  I’ve been working on the GUI system and getting that framework down.  The Text Area field stuff was really annoying me so I figured it was just slowing me down.  I changed my focus from the Text Area to other more important areas.  I made some improvements to the looks of components.  You can now change the background, foreground and border color, of each component.  The foreground is only used for Text, although, certain components would probably be able to use it in some way.  All the GUI Components also have the “standard” Location and Dimension implementations.  I haven’t really started updating the rest of my classes but that’ll be on an as-needed basis until full development shifts to those classes again.  One fun fact though:  I just finished creating a GUIViewport component which encapsulates the Viewport class, so now I have a more “standard” way of creating a viewport into the game world.  I think it’ll relate to the actual game(s) themselves pretty well to as there is no actual drawing code inside the GUIViewport, just a pointer to the viewport it controls and a few helper methods that allows you to access the viewport (its private).

Click and Focus events aren’t yet implemented.  Click might be, actually, but Focus is definitely not as its functionality is more complicated.  The Hover events are completed though.  Which brings me to todays fun filled story.  While implementing the Hover events, I only started with one component to test with.  I then added a second, at first testing them individualy, but then testing them together.  The Location of the components are specified from the bottom up, while the Mouse coordinates are specified from the top down.  This isn’t really a big problem unless you forget this fact, which I of course, did.  Label A was on the 384 pixels mark on the Y-axis while Label B was on the 400 pixels mark on the Y-axis.  I tested Label A, hover worked wonderfully, but as soon as I went to Label B, it stopped working.  The “hover” area for Label B was slightly below it and has a much smaller area.  This confused me, and it led to several re-writes of the logic, which actually didn’t really need to be rewritten at all as it was “right”, but the inputs were wrong (mouse coordinates).  I moved Label B around and sure enough, it was not only broken, but the gap between Label B and its “hover” area grew.  I was ticked off now, and more confused than ever.  I then got the wonderful idea to move it to the same height as Label A.  It of course, worked.  It was pretty late (or early in the morning) by this time so I decided to go to bed.  I left my computer on in case I had one of those bright ideas that I usually get right before I fall asleep.

Sure enough, the bright idea came.  I went to bed thinking about a related issue.  First the mouse coordinates popped into my mind, where they are compared to everything else and then it suddenly popped into my brain.  Label A worked because it was directly on the half-way mark.  768-384 = 384, so no translation at all.  However, 768-400 = 368, definite translation.  Knowing this, I hapily went to bed.  The next day (and just this morning) I finished going through the code and standardizing it.  All the location vectors specify bottom up coordinates, instead of top down.  It’ll be useful to have both, but right now, it’ll only blow things up.  Thats all really.

Game Engine: Update 26

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.

Game Engine: Update 25

So I’ve done some more work to the horrible text area component of the GUI system.  I say horrible because it is very ugly and in need of love.  It gets looking even worse with the font I made too.  Right now, all it really does is let you type.  Text is wrapped around the width of the text area right now, and text that exceeds the height of the text area is displayed, but hiding text is on my to-do list.  Right now I’m trying to get the cursor to properly move.  Currently, you can move the cursor from the start of the text and down to infinite (after it passes the last character in the text, it disapears).  The goal is to cap the cursor at the last character in the text but its proving a little difficult.  The cursor postion is held in a vector.  While drawing characters, I calculate the character number that the X and Y components of the cursors position correspond to.  When I hit the calculated character while drawing the text, I also draw the cursor (which is why the cursor disapears after it goes past all the characters).  Getting the character position though is easy (or at least it didn’t take that long to come up with a working formula), but reversing that formula and solving for X is seeming awkward.  I need to solve for X because I need to find out the last X value that the cursor position can be set to.  Because text wraps around when it hits the width of the text area, the X value would reset back to 0 and the Y  value would increment on each wrap around.  I would like to calculate the X value of the last set of characters without having to loop through anything and I’ve been trying to use the same formula I used to get the character number but its proving to be quite buggy.

As for the GUI system in general, I’m thinking I’m going to borrow some concepts from Java where things like the Scrollbar aren’t built in, but can be added modularly.  The text area will have an option for a scrollbar and it will probably work seamlessly, ie. the end user won’t know that the scrollbar and text area are two seperate components.  This will hopefully allow me to keep equal logic centralized within one object instead of a dozen.  The scrollbar for a List will work exactly like that of a Text Area or Frame, for example.  Right now, the only object really fleshed out though is the Text Area and there isn’t a lot of functionality or customizability at all either.  Its getting there though.  Slowly, but its getting there.

I haven’t actually given much design thought to the planned game though.  I know the general idea.  I know what I want to incorporate into it.  I know what I want it to do.  As far as deep, complex game design documents though, I’ve got nothing.  After reading a lengthy post about an economic prototype someone was working on for Infinity, I figured I’d better get on that now, so when my engine is nearly done, or done enough that I can start working on the game, then I’ll be ready.

Game Update: #24

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!

Game Engine: Freeing Memory Part 2

I did some looking around for existing garbage collectors.  I found one that looked very good, but has the downside requiring me to modify all of my classes to use the pointer wrapper it requires.  The GC I’m referring to is in the book “Art of C++” by Herbert Schildt.  In Chapter 2 (which is the only chapter I can find freely on the interweb) he describes and gives the source code for Garbage Collector that uses reference counting.  TBH, I don’t care what method the garbage collect I end up with has, just that it works.  I saw some people complaining about how it has a few bugs or that it was innefficient, but I’m not bothered with that.  I am however, bothered with the fact that I need to modify all of the variable types in my classes so I can support the proposed Pointer.  Also, there is a small problem with arrays.  It has a stupid declaration requirement for declaring a pointer that is to be used as an array.  It requires you to specify the size of the array prior to actually initializing it, which is fine if you were only using it for local variables, but absolutely not fine if your array variables are stored at the object level.

I also found a another garbage collector that actually looked very nice, and then I found the comments section of the page it was on and there were lots of comments about bugs.  The first one only had one or two minor bugs that didn’t affect me, but this one had quite a few.  It wasn’t compatible with arrays, but it did have a somewhat nice interface for using it, where all you had to do was extend the pointer wrapper.  One other bug was that due to the way reference counting works usually, where if you assign two pointers to each other in a certain way, it would decrement the reference count for the pointer before incrementing it and then the object was essentially gone.

I’ve decided that I’m going to use std:vector for arrays so I’ll only need to implement a GC to handle singular objects.  Right now, the first one I found is my best bet.  Other than that, it is implementing one on my own.  I could look at both sources and see if I can’t find a happy medium though.  I would like something that is nearly automatic and compatible with the existing source code of the main programs I have.  I also decided that I’ll have to start making copies of objects instead of directly passing in dynamically created objects too, unless my own implementation accounts for this.

Auto pointers apparently aren’t what I want either as “Ownership” is actually transferred, which probably isn’t what I want 90% of the time.

Heck, maybe I could just std:vector for my arrays and just manually deal with memory.  The only problem I’ve run into at the moment anyways is dynamically creating objects while passing arguments into methods, but that problem is gone, now that I’ve decided not to do that ever.  A neater way to delete objects might be what I’m looking for though.  Perhaps something like “myObject.destroy()” like in UnrealScript.   Actually, on second thought, that may be something to have in the scripting language, and not in the engine code.

Yeah, I think I may just do manual memory management for now, and implement/use a GC when the actual scripting part comes.

Game Engine: Freeing Memory

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?

Game Engine: Nothing but Grief

I was writing a fairly lengthy post about memory leaks, how they suck, and the problems I’m having with them. But I decided that the following will sum it up.

Ugh.

Game Engine: Update #23

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?

Game Engine: A Text Area

The first actual GUI component that I’ve been working on has been a simple text area. Or rather it should be. I didn’t really realize how much thought must have gone into all the text fields out there today. Their designers have made several design and implementation decisions when creating the text field. I’m not talking website designers plopping down a text area onto their website and doing something special with it via Javascript. I’m talking about the people who designed how that text area works in the first place. How the internal system works. How the text is stored, how the text is manipulated, everything that the average user just doesn’t see. Everything just happens for them, whether they’re selecting a section of text, deleting a section, or simple typing in some text.

I’ve been using char* or const char* for text pretty much since I started working on this engine. I knew STD::STRINGS existed, but I figured that I should stick with const char* and char* for the sake of simplicity as the old C code that I have to work with (OpenGL and SDL) use char* and const char* in a lot of places. I know .c_str() will convert Strings to const char* but I don’t think that’ll work for char*, but I may be wrong. Anyways, I have been working on a text area. Up until now, I had been using a char* to store an array of characters that it would draw. Actual input of text wasn’t implemented yet so it was basically just a multi-line label at this point. I got it to the point that I wanted to get actual input working. It seems to me that doing something like that with char* is suicide. strcat kept crashing (probably due to size issues) so I decided that it probably wouldn’t hurt very much if I started using Strings now (although I’ve tried to avoid the “standard libraries” like the plague) and I’ll upgrade the rest of my code as time goes on. But, working with the String type for something like this is so far, nice.

Game Engine: Libs And Gibs

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.