Game Engine: Update #15

So I can rotate objects around their local coordinates and can properly move models around and have independent rotations.  There is one small problem with it right now.  Well, two problems really.  When I first made my cube model (vertex by vertex painstakingly and foolishly hard coded) I made some temporary x,y,z values to help me with creating the vertices.  So something like “x=32″ and then I also had a variable called size, so my first “face” or vertices was a vector of Vector(x,y,z), Vector(x+size, y, z), Vector( x+size, y+size, z) etc.  When I created my secondary level, I added size to the z value.  So the model basically had an offset.  I somehow got it in my head the OpenGL would ignore the offset and draw the object at the origin anyways, as in, drawing the origin of the model at the origin.  This created the whole rotation problem issue – which led to great frustration.  So models need to placed around origin of Vector(0,0,0) when they are created.  Which leads to the next problem.

Complex models might be a bad idea.  And by complex models I mean anything that isn’t a Sphere or Cube.  Last time I checked (although that was before I fixed it all completely), Rectanges didn’t even work properly with regards to rotation.  So, I want the option to create an origin for my models so if a model has an origin at their head, I want the option of changing that origin to their feet or center of mass/volume.  I saw a couple of posts about this – it involves taking the average of the vertices or something – at least for the “true” center.  I’ve tried the “true” center and it didn’t seem to work… whats more, I’m not really sure how to pull what I want off.  To set the origin, I have to translate to the origin minus the average for all vertices and then I would have to do my rotation and then translate to the actual location of the model.  The whole model origin override will be a per-class thing so the actual model won’t be touched.

There is another huge problem though.  I can color my cubes just fine but texturing them has some issues.  I noticed these issues awhile ago and I didn’t really want to investigate, but I had a good idea of what my problem was.  I assumed Texture Coordinates were per-vertex, that is, because my triangles all share from the same pool of vertices, I figured it wouldn’t be a bad idea to save even more space by just storing the texture coordinates for a vertex with the vertex.  Turns out, I was pretty wrong about the whole thing and now I’m paying dearly for it.  Because I stored my texture coordinates with my vertices, it was merely 8 extra lines for me to add.  I actually have two cubes right now, which are exactly the same in every way but rotation and location in the game world, but I had plans for the second cube, maybe to mess around with it and turn it into a rectangle to test stuff and what not.

My first cube was put into a class called TestModel where it had a unique variable called pModel.  I inherrited from my BaseObject, but at the time I didn’t have Models implemented in there yet (now it is.)   Because I wanted to later change my vertices, I just created another class called TestModelB and basically did a copy and paste.  So back to the texture coordinates, because I have 2 cubes to fix (the second cube isn’t quite the same as the first anymore so I can’t just do a copy and paste again) I need to add a grand total of 72 lines of tedious code.  So, here comes my next goal:

I need to get a Model Importer up and running.  I don’t care what format, hand-crafting a model is becoming WAY too tedious for my liking.  Its in my belief that burning through long and plentiful lines of code, rather than copying and pasting, builds character, but this is…  SUICIDE.  After I get the texture coordinates all fixed up (And I’ll be discarding the second cube me thinks… I think one triangle is broken anyways) I’ll look into getting multiple mesh support up and then from there, looking at uber easy model format.  I’ll be making my own model format I think, one that will be optimized for the engine, but that’ll come after I start working on the tools, ie. Level Editor, Modeller/UV Mapper, and whatever else I figure I’ll need.

EDIT( 4 hours later ):

So I gave up on the whole texture coordinates thing.  I could only get 2-3 faces to be texture correctly and that was after I tried to calculate S+T myself and after I let OpenGL itself  have a swing at it via some function that didn’t work.  Anyways, this is a good thing really.  I got so fed up that I started working on an importer for models.  Currently I’ve just exported a Cube… yes just a cube, into the “simple model format” (Text option from the export menu).  It had some crap in it I could have done without, so I trimmed it down to just vertices, triangles and then I added some color information.  So here are the results.

*face palm*

Need I say more?  Something is definitely up.

 

EDIT #2:  Yay!  Don’t you love when things just work?

Because I checked over my code again and again and found nothing wrong, I assumed it was something wrong with MilkShakes exporter.  I tend to do that a lot.  “It can’t POSSIBLY be MY code!  It looks like it is working in THEORY.”  Oh… if I had a quarter for every time I thought that.  So I typed out my known-to-be-working cube model that is hard coded into the new format to see if maybe it really was just the exported file or perhaps my understanding of the extremely simple (hence why its called “Simple Model Format”  *face palm*).  Unfortunately, it was neither, and my cube didn’t work any better.  In fact, it worked less so (which is kind of funny, no?)  After some tinkering, I found out the problem was actually with the way I was grabbing data from the file stream.  After working with C/C++ for this short amount of time, I have fallen in love with it.  Its become to me like Lua or Java, where pretty much anything is possible.  Unfortunately, it is extremely lacking.  Because C/C++ is so old, I don’t think anyone is really updating the standard anymore.

With things like Lua and Java, they’re constantly being updated, new features added, bugs fixed, etc.  One “feature” that I feel should be built-in (and by built-in, I mean not having to go to lousy extended libraries) and not require one to do messy, ugly work arounds (like for example, when you are required to use a const char * when you only have a const *, at which time you can either pack up the bags or do an incredibly ugly maneuver which involves creating a stream and “streaming” the char* over to a const char*, rather than typecasting it.)  And thats where I’m going with this really.  I’ve never really understand the need to have const char* and char*.  Why not have just one, or provide built-in, beautiful facilities to turn one into the other.  Shouldn’t it be as simple as taking data at the end of one pointer, converting it, then placing it at the end of another pointer?

Anyways, so was using getline(…) to grab data from a fstream.  Eventually I got to the point where I got a char* and I had to use the ATOI method to turn that char into an integer as well as ATOF for the vertices.  A given line is like the following:  “-10 10 -10″.  Me in my infinite wisdom though the c_str() method of a string returned every character in a char*.  So when i used ATOI, I skipped over the whitespace index.  Long story short, everything was wrong about what I was doing.  It all appeared fine until it decided it was going to pull values from elsewhere in the char*.  So, after looking at some code, I moved over to fopen and fscanf which is the best fracking thing ever.  It is of course, deprecated, but there is the alternative of fopen_s which returns an error status rather than the file handle, so its more secure.  I’ll look into that later though, I’m happy with the progress I’ve made so far.  After maybe a couple of modeling tests, I may start work on a smalllll level designer.

Game Engine: Update #14

Persistence.

Sometimes, it really does pays off.

Game Engine: Update #13

 

[rant]

I’ve finally hit a brick wall so hard that all of this may be for naught.  I think the last update was about how I couldn’t get the cube to render correct… but if it was about me finally getting rendering of my cube done, then I guess I’ll update that notion.  Using glOrtho I had properly rendered a 3D cube.  At that point the problem was how I was going to rotate it on the models local origin rather than the world origin (or camera origin… still not really sure what it decides is what.)  Well…  I eventually gave up on that idea and looked at the bigger of picture of me needing a “camera” that I can move around and look around the 3D object.  I posted on StackOverflow.com… um… I think last night.  All the replies I got basically told me what I already knew about but one post was a little more detailed (just a little more though)  on the direction I needed to go in.  It was either create my own matrix and manipulate it, or create one using an openGL call and then use translations and rotations to setup the camera.  Time and time again I have tried.  I’ve looked up countless algorithms, equations, Googled my fracking heart out.  Eventually, I decided that people were idiots not to put this kind of information blatantly on the internet.  Why is there practically ZERO information out there for setting up an FPS-style camera without the use (and I mean absolutely without the use of) GLUT?  At some point I caved (by heart broke at this point… nights and nights of staying up late… well… not nights and nights, but I haven’t had a proper sleep for awhile) and used gluPerspective along with glRotate and glTranslate.  In the end, I got it working… sort of.  When I drew the model I passed in the location of and the yaw/pitch/roll components of the Camera object I have.  Guess what happened?  It drew.  There is still that fracking problem with the CUBE being drawn as a looong rectangle going down the Z-axis but it still drew.  I was so happy that I decided to spend work on the rotation of the camera.. and after a long battle, I got that working.

Just now I was looking at my code and adding stuff and noticed the Location vector I have in my BaseObject class (which my TestModel extends from).  I looked at my Model drawing code.  I thought to myself, should the Model drawing code really be drawing with the coordinates of the camera and its rotation?  I of course changed it up to match the location of the model and its rotation instead.  It the preceded to break.  I tried then also doing the rotation/translation in my Update method for the Cameras location/rotation (thinking that may the openGL camera needed to be translated for the game camera.  It broke even more.  A few minutes ago, I got fed up and ripped out all of the rotation, translation and other stuff.  The end result?  Yeah, still doesn’t work.

Here is what I want.  Every object in the game engine has its own Location and Rotation.  The in-game Camera also has its own Location and Rotation and it will ultimately be attached to a players character (meaning that the location of the camera will almost be identical to that of the player.)  All I want to do is be able to draw all of the objects I need to draw at the specific coodinates in the game world, with their specific rotation and be able to move the Camera around the environment.  Now if only I could find a tutorial that showed exactly how to pull that off without the use of GLUT.  I think even the OpenGL books (The Red and Blue book) use GLUT extensively.  WHY!?

[/rant]

Quick Test

Just a quick test to see this Publicize doohicky!

Game Engine: Update #12

I delved into the world of drawing models just this evening.  There is a lot more I need to understand but I have a basic cube model being drawn… well… being half drawn.  I forgot about the importance of Normal vectors and I think thats why it stops rendering when you rotate it (not quite though, you can still see each individual triangle, they just aren’t being drawn.)  And the cube isn’t actually textured either.  I’m going to have to figure that one out as well.  Since I’m only doing preliniary tests at the moment, I don’t have a full blown model system and therefore the model I have currently (the cube) is one full mesh.  I figured I could apply the same texture to all of it but something just isn’t working out very well.  If I bind the texture, the cube is white.  If I don’t bind the texture you can’t even see the cube.  The texture isn’t white though, its thats yellowish brick you may find if you look through the archives.  While looking at the cube, I had all other rendering disabled (the 2D image stuff.)  I decided to turn it back on and found that glRotate rotated all of the 2d images as well.  Very fun to watch.

Anyways, my only real adversary right now is my bloody arm!  I think I have carpal tunnal brought on by playing Titan Quest.  Its really annoying actually.  A few years ago, I had a problem with it as well, and that was when I mostly played UT.  This past year, I’ve grown to love Counter-Strike again, but it hasn’t caused any problems with my arm.  Suddenly, I get a this game where to move around effectively, you need to click and hold the mouse trigger in the direction you want to move.  This involves clicking the mouse and moving it at the same time.  In CS, you don’t have to do this 100% of the time, but in Titan Quest, it becomes necesary.  I think thats what blew up my arm.  Anyways, it hurts a hell of a lot – a growing pain that will never, ever go away.

EDIT:  So after taking a break to do some gaming, I started thinking about how I was going to implement the different drawing types for all the game objects.  The UnrealEngine (of which I’m borrowing many of my engine principles from as I’ve worked a great deal with it and UnrealScript) had what they called DrawTypes for every object.  Note, I haven’t really looked at UnrealEngine 3.0+, but I am away that they have changed a great many things.  AFAIR, a game object could only be drawn to the screen in one way whether that be a static mesh (optimized models.  they were copies to the hardware and just duplicated whenever they popped up again, rather than creating the entire mesh from scratch, if I remember correctly) or a simple sprite.  I figured to make myself happy, I wouldn’t go down this road exactly.  I’ve thought of a different approach.

Each game object will have an array of drawing methods.  So currently, the two methods would be as a sprite or as a model.  This opens up several possibilities, I think, for easier and more open object creation.  Each drawing method will have its own set of variables ranging from Location (relative), Model, Texture (for the sprite), Rotation, etc.  This means you could create a robot as several different pieces, rather than one big model, but every piece would really be one object.  Each object would be controlled by the logic of the object and each model/texture would have its own rotation/location/etc. completely seperate from the main object – or completely dependent on the main object – the choice would be up to the object designer.  I am getting ahead of myself though, me thinks.

NTS:  Don’t forget about future scripting-language integration for external class manipulation/creation!!!

 

EDIT #2:  Finally after fiddling with rendering a simple cube properly, I found out that I actually sort of was rendering it properly… or at least all the vertices/triangles were correct (I may need to look at the Normals as I don’t think the rendering is any different when I set the normal or not).  Anyways, what I was initially seeing was a cube that was rotating about the Y-axis and it seemed like only one face was being rendered and that the face being rendered was changing from the outer face, facing the camera, to the inner face, facing the came, so… it looked like it was rendering and outside surface then as it rotated the cube, it started to render only the inside surface of the cube.  The point is, I only saw one surface.  I decided just now to actually set the color (texture loading wasn’t working for some reason) of each triangle to a different color.  The result?  Success!  It appears that either it wasn’t rendering the other surfaces because it had no material/color to apply to them, or they were indeed being rendered just with a black color.  I also found that one of my triangles was wrong, so I quickly fixed that.  So… now I’m excited about all of this again.

But my arm is still hurting.

Game Engine: Update #11

So its getting late but I decided to take a look at the engine now that I have some more free time.  The point where I left off was messing around with drawing polygons (experiments that didn’t end with happy results).  One thing that didn’t happen though was complete and utter failure.  Now that I’ve decided to start taking a look at drawing simple SDL surfaces into OpenGL (which involves some conversions and what not) I’ve run into a problem that has me somewhat puzzled.

I can’t load images properly anymore.

Yes I’m angry about this and no I still haven’t found the cause of this inexplicable problem.  Maybe I should start leaving comments on every line and make a step by step list of what I do right down to the character deletions.  My head hurts.

EDIT (3:10 AM):  Yeah.  So…  I may not know EVERYTHING about C/C++ but there are certain things that seem like they should be correct and that you KNOW should work but just don’t.  Case in point, my setter method.  Since wrapping my SDL Surfaces inside a Surface class, I’ve had to make a setter and getter for the actual SDL_Surface so I can handle a few things like variable setting etc.  My setter had a bunch of stuff but of note is the following line:

Surface::surf = surf;

Surface::surf would be the actual surface variable for whatever instance of Surface the set method is being called on, and surf is just the supplied surface.  AFAIK, that line is no different than doing “this.surf = surf”, which works perfectly well in Java and I suppose one might assume that particular line of code in C++ would work also (haven’t tried it yet) but difference could there possibly be between “this” and “Surface::” ?  Anyways, the drawing code still doesn’t work, but now I at least know its because my comprehension of everything involved with drawing an SDL Surface onto an OpenGL window isn’t very good.

 

EDIT (11:17 PM October 30th, 2009):

So… after finally finding a beautiful resource, I got textures to draw properly on the screen.  I had put everything into a test method so I would mess with my existing drawing code while trying to get things to work and I just moved over everything.  I currently have about 4 brick objects on the screen and then the player controllers brick.  Cursor keys move you around (or rather, move the camera around.  The players brick is actually stationary right now.).  Before I moved my code from my test draw method into my actual draw method, things were going okay.  I could move around the screen and the bricks would hide properly etc.  When I moved everything over into my main draw method, all hell broke lose.  Well, maybe I’m exagerating just a bit.

Before this OpenGL stuff, I had a starfield in the background that panned to the bottom right.  The point was, with the panning and moving, things were still relatively fast but sometimes the movement keys got stuck going in one direction until you changed the direction manually, which I assume is a problem with my code.  When I started my engine to see the changes that drawing everything properly would make, I got depressed quite quickly.  SLLOOOOWWWWWW. 

Like… really slow.  So I figure its a problem with one of two things.  First, it could be my code.  Entirely plausible, no?  Secondly, it may be a timing issue.  I may have to implement Timing faster than I would have liked.  Anyways, there is an update.

Game Engine: Update #10.5

I’ve been meaning to make an update for awhile but I haven’t had the time and to be honest, there hasn’t been much progress on the engine (also due to time.)  You see, my course was almost over so there were a few final projects that needed to take precedence. One of which I’m going to talk about later on, but first I’ll just recap some stuff.  Before I started working overdrive on school projects I decided to implement OpenGL sooner, rather than later, upon suggestion.  I’m happy I did as it got me thinking about a lot of stuff.  Up until now there was a vast difference between my game/engine code and the actual components that made up the engine, which was mainly SDL.  I accessed SDL through a wrapper for a few methods so I could shield my game-specific code from having to access anything SDL related – or even anything not specific to itself.  When I created the wrappers however, I didn’t even think about making them C++ like (which I guess more object-oriented than C) as at that point I just working with C++ and I thought it was “supposed” to be like that.  So when I created a video surface for intance, I just made a call to SDLCreateVideo (which was initially called through my main method).  There was a… global… although I’m still not entirely sure what that means in the world of C++ because you can’t directly access “global” variables in another source file because it’ll have a different value…  but I had an accessor to a global variable inside my wrapper source file.  Any SDL wrapper or external source that needed to interact with the video surface (either to blit to or for some other reason) called this accessor.  So basically I treated my wrapper source file as a static utility class, which was pretty much the case anyways.  Everything worked and I was happy.

Then OpenGL came in with his crew and ruined everything for a bit.  After reading some OpenGL + SDL information and tutorials, I quickly came to the conclusion that enclosing my SDL stuff inside actual classes really would be the best, sexiest decision.  So now… I think I have a video class that handles the video initialization and drawing and we also have an SDL Surface class as well as a couple of others if memory serves (haven’t actually opened up the source since… a week or two ago?) and this change required a lot of other minor changes but these changes were all for the better.  Now it seems more like an engine with a common focus rather than a mish-mash of awesomeness.  I worked on that to the point of drawing basic shapes to the screen and then school projects reared their ugly heads and that was that.  I hope to figure out how to get SDL Surfaces into OpenGL stuff soon.  I’ve also decided that SDL_net might be the better solution versus WinSock for two reasons:  1.  I can’t for the life of me find information on the native winsock (that is, the one that comes with Windows from the get-go) that turns socket blocking off and 2.  SDL_net is cross-platform compliant.  So yay.

So now on to the class projects or project really, as I only want to discuss one.  At the beginning of this semester we were given a client/server framework in our Java class and we used it to build up a chat program from simple client to client console communication to a decent client/server GUI system.  At that point we were given our final project which was to break off into groups and plan+implement enhancements to the chat program.  Me and a classmate started with the usual.  When we started, clients automatically joined the global room but from there they could join other rooms.  We decided we wanted a user list for each room.  These rooms behaved like IRC where you can join almost any room on IRC and if it doesn’t exist it is “created”.  Initially I wanted a client to be able to join as many rooms as they wanted to further mimic IRC however my classmate didn’t really want to but now we decided to put it in.  There were other changes and what not but the only one I wanted to really talk about was voice communication.  My group member wanted to implement voice communication like Ventrilo (and I guess thats why he wanted only one room at a time per client) and he said he had looked at some stuff but we both got busy and nothing came of the voice stuff until around this or last week when I took a look at JavaSound.  Firstly, I would like to say that I didn’t really like how JavaSound was implemented.  I would have much rather had classes I could instantiate rather than “get” from an abstract class.  Anyways, after looking at some documentation I had a Voice Capture and Voice Output system working pretty nice… but that was only locally.  At this point our chat program had nothing to do with it, but that was the next step.

After a day or two I got around to implementing this on the client and server.  Right now however the client uses their mic and it comes out of the servers speakers but that will be modified so it comes out of the speakers of the other client as well.  Again, not what I wanted to talk about but its some info before I talk about an issue I’m having.  When you start the client and start the voice capturing, the bytes received from the mic are packaged into a class and send to the server.  When the server receives a voice package, it initializes its voice output thread and continually writes incoming voice package bytes to the speakers.  This works for anywhere from 10-15 seconds (and if the client is being run on the same computer as the server than it’ll work for a bit longer) but soon after you get a dreaded EOF exception and the socket to the server is closed which then creates a connection exception on the server (which is handled but more grace is needed).  Now after some experimentation I end up getting an out of memory exception on the client right about when the EOF exception should be received.  On the client I have two threads, one that grabs the input from the microphone and one that packages the input and sends it to the server.  These two processes could be combined I suppose, but I wanted to have some classes that could me moved around to a different project if desired so I didn’t want to have my input/output classes (that implement Runnable instead of extending Thread) tied to my chat stuff.

Anyways, this poses two questions that I’ve been trying to answer since I got this error.  1.  Is the EOF exception happening due to the OutOfMemory error and experimenting simply cause the causing exception to reveal itself? and 2.  How the hell do you fix it?  I’ve never received an OutOfMemory error before, or at least not one I couldn’t find the cause to within a minute, and I haven’t really done anything this involved with threading for awhile.  The OutOfMemory happily told me exactly what thread was causing the memory exception and it was the one that was sending the voice bytes to the server so I used JConsole to check how many threads were actually being created and sure enough, only two were being created on the console, the Mic Input and the Mic Transmit threads.  So I tried to find the cause of this issue the hard way.  I emptied the run method of this thread and sequentially added on the needed items until I was left with the statement that is creating the memory leak.  Surprisingly, it was the method that sent the voice package to the server.  Client/Server communication involves a socket (TCP, however I would like to experiment with using a UDP socket for voice communication.  I have a suspicion that it might be better) and a set of ObjectOutput and ObjectInput streams.  This Saturday I’ll be working on it hardcore though so hopefully I’ll figure this out.  Its getting very frustrating because it just doesn’t make sense.  Why would sending bytes through a socket cause a memory leak and ultimately an out of memory exception?  Even if the ObjectOutputStream in the framework isn’t being flushed, it would be overwritten with the new bytes, for the most part, right?  (I had to add the flush command to the Objectoutputstream which modified the framework which is also a no-no but that didn’t seem to have any effect), so why isn’t the byte away getting garbage collected!?!?!

Game Engine: Update #10

When I first started this project, I was going at it from the perspective of “Hey!  I can use this to make a whole series of games that’ll run as a single player game.”  Multiplayer opportunities were something of a future goal, but none of that was even put into the plans for any game I was thinking of making – and if it was, no consideration was given to the fact that I was using C++ and not Java or C# (where networking is easy, peasy due to managed classes).  After the Alpha release of Love (yay Eskil, but unfortunately, I can’t access the account associated with my paypal ATM) I looked over his tech demos again.  I immediately started thinking about Verse again, and how cool I thought it was.  I immediately began thinking of changing the shift of what I wanted with this game engine… no longer is it just about single player games, but its about an MMO type game.  This presented two problems.  One, I would perhaps have to change things around to account for the fact that this will be an online game…  Replication.  Secondly, how do you connect to something through the internet in C++?

I haven’t really looked at or solved the first problem yet (if its even a problem… Replication could just be built on top of what I have, which is admitedly not a lot) but the second problem has been solved with a couple of days of looking around.  I started looking with the hopes that I would find material on how I could write my OWN socket… that is, write a socket completely from scratch and at the same time, ensure the ability to maintain platform independent-ness or the ability to turn my platform-dependent socket into an independent one without much trouble.  How easy is it to find such material, do you think?  I would have thought it would have been a piece-of-cake.  Sure writing my own socket might be “stupid”, but so what?  Maybe I’ll digress a little here  I have a big problem with the programming world in general.  How should I word thid…  Code reuse, frameworks… I think they’re flawed ideas. 

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” –Larry Wall (Programming Perl)

Now I think Larry is write for the most part… the only problem I have is the world “great.”  Laziness can get you to do a great many things to speed up productivity, but it can also make you do things that might not be so awesome.  Frameworks are by definition, incomplete.  We have them to ensure a common set of APIs accross a variety of applications that use the Framework (if Project A and B both use Framework C, then they should be able to swap the source for Framework C amongst eachother and both projects should be able to compile just fine) but they are also supposed to somehow speed up development of the actual project, rather than fiddle with stuff that the Framework has already implemented.  I think frameworks are nice, but only nice to the point where the Framework doesn’t do what you want it to do.  Then you have two options.  The first, to modify the Framework which is typically a no-no (if a new version of the Framework comes out and you -have- to upgrade, have fun)  or you can overwrite existing functionality from the Framework within your own project.  This is where I sort of get grumpy with UnrealScript and other related languages where every function is practically either an overwritten function, or an extension to the same function that exists in the parent class.  The point I’m getting to is that when 50% of your code base is just overwritten functions… especially overwritten functions that do everything the framework version of the function does except yours goes left, when its goes right, it just looks UGLY and probably becomes hard to manage at some point.  My motto is that if I can write something from scratch that gets the job done, is somewhat beautiful and is correct, then why use someone elses code that could perhaps contain a million bugs, looks awful, or does some funky with memory that I need to account for?

For example, I am using SDL and SDL_gfx because I have to, not because I particularly want to.  Whats wrong with SDL?  Nothing in particular… in fact, it has worked beautifully for me so far (and I hope the same goes for OpenGL when I implement that) however;  I’ve had to make several erm… I’ll call them interfaces… between my code and that of SDLs code for the simple reason that some function calls are unnecesarily complicated or don’t do everything I need at once.  For example, color keying has to be done in a few steps but my interface does it in a single call (which ultimately does the normal few steps, but all of that is done behind the scenes… and if I ever need to change something, its easily doable.)

So back to what I was talking about with Sockets and all of that fuzz.  I wanted to write my own socket because it was something I’ve never done before, its very interesting, and I wanted to hopefully create a platform independent Socket.  After some looking about, I find that there are a great deal of Sockets floating around from different providers (at least for Windows.)  I also found out that WinSock is the actual socket for Windows (I always thought it was an auxiliary socket that one could use) and *nix uses a different type of socket (Berkeley only, I think?).  Now I think behind the scenes WinSock is somewhat different than the other Sockets out there (and there are different implementations from various third-party developers too).

So whats the problem?  Well for one, it seems I can’t just simply write my own socket (because that would be TOO easy), I need to use WinSock on Windows and use the “standard” socket for all the other platforms.  I joined that other engine project some time ago and I was tasked to write a WinSock… unfortunately I knew no C++ at the time and I eventually faded away because I got very busy with school and what not.  I’m not sure if he knew one already existed, but he was fed up with Windows a lot.  Anyways,  WinSock… this requires another set of interfaces as well as using the Windows header, which I’m sure SDL uses for compiling, but I didn’t want to have to touch the thing in my code.  I already had to rename my Rectangle struct because it was already defined somewhere in there.  Anyways, took me a couple of minutes to understand it but I got a Socket binded to the localhost and connected to a listening server, so I guess I’ve got it working.  Now I just have to write the interfaces now to make my life easier.

Also:  Socket Test is BEAUTIFUL for testing Sockets.

Game Engine: Update #9

A week or so ago, I made a fairly large change with the engine.  For the time being, I’ve removed all of the Lua-related code.  Implementing the most simplest of things became a monotonous task – a task that usually took way too much time.  As a result, the progress on the engine was very slow and places I wanted to go were farther off than I would have wanted.  With the removal of the Lua component, things have sped up considerably.  I have the rough workings of a player in the game now (which is just a block ATM) and am currently working on the Camera system.  While implementing the player movement, I had to take a closer look at the Physics Engine.  Unfortunately, the Physics Engine in its current state is… well, not really a Physics Engine at all.  In fact, it doesn’t even follow real physics calculations (but a lot of game engines don’t, right?.)

You see, after some fumbling about with getting the player class moving “properly”, I implemented something as close as possible to real physics.  The problem however was that it seemd WAY too fast.  After some tinkering, I realized that it might not be a problem with the physics per-say, but my frame of reference.  I had been working with a resolution of 640×480 and the game area was the same size.  I sort of disabled a lot of the Physics Engine so I could just move the player around without any physics interactions, but then I decided to start work on the level system a bit further.

The camera is the players view into the game world.  They will only be able to see a small section of a given level at a time as they move through it.  As game objects/scenery comes into the rendering threshold, it is rendered onto the video surface every tick.  When the game object/scenery moves out of the rendering threshhold, it stops being rendered.  Simple.  The only thing that might be -slightly- advanced is how I plan on moving the camera.  I’m thinking of just attaching the Camera to the player object.  Currently the Camera is a seperate game component and not really an object.  Its like the Level class or PhysicsEngine class… these things are created once.  I may however make the Camera an actual game object.  This would allow an easier transition from using the game engine for a specific 2D game to using the game engine for any other game.

Nothing really else to talk about.

Game Engine: Update #8

I haven’t been able to work on the engine for a few days.  Sometimes real life has to take precedence and all.  I did just start thinking about the engine and the problems I’m having with it so I figured I’d get my thoughts “down on paper.” 

The biggest issue is that testing even the smallest of changes is becoming somewhat difficult.  This isn’t neccesarily a problem with my code as far as how it is set up and implemented, but has more to do with what isn’t set up and implemented.  Since each Lua script will typically affect changes to one class, there needs to be a way to indirectly change the C++ version of the class.  The only way I see of doing this is having a table of all the classes that are “editable” and associated those classes with the functions that can be changed.  Then, each script has to be loaded and added to a table along with the functions that they override of the specific class.  If I do the first table statically then its a piece of cake… dynamically will make everything difficult.  Loading the Lua scripts will actually be very easy as the code that runs the engine at the moment looks for a specific Lua file, checks to see if a specific function is inside of it, and then executes that function.  Modifying this to add the script to a table wouldn’t take very long.

The real problems have to do with the metatable for Lua.  Each object will have to have an index in metatable along with all the callable functions and variables it owns.  This will all have to be synced up so that all variables referring to a specific object actually refer to the same object.  Implementing this is going to be very difficult and when I get some free time its going to have to suck it all up until I figure it out.

I wanted to talk about more, but I’ll save those things for a rainy day.