Game Engine: Update #19

Things I need to get done within the next 24 hours:

1. Finish Input Controller component
2. Take that logical next step and implement multimesh models.

I found a neat program called tree[d] earlier today in my link follow fest.  Its beautiful.  It allows you to generate any type of tree imaginable – and then you can export it into a model or as a texture!  How fracking awesome is that?  Well… its amazingly awesome but there might be some limitations to it.  When I first read through the license, I thought it said that any tress generated by the program can’t be used in any commerical products that you intend on selling, but after reading it over again, I think it may just mean that I can’t sell the tree models seperately or within a model pack.  Maybe I’ll need to do some asking around.  Anyways, it only exports into DirectX and Blitz3D model formats so I had to editing.  After some hard labor I found out that I only grabbed a few tiny leaf triangles.  So when I finish #2 on the above list, I’ll write a converter from DX models to my model format or maybe even Blitz to my model format.  Whichever is easier.  I am no modeler though something like this would really be awesome.  The first game I want to make is a space-based game though, so maybe I won’t require the use of trees for awhile.

Game Engine: Update #18

EDIT:  A simple key input system is almost done being implemented.  A major problem though has surfaced its ugly head.  A technical problem?  No.  A  design problem?  Nope.  NS2 is releasing there editor in the next couple of hours.  The major problem is I may abandon work on my own engine because I’ll be playing hours after hour with that thing.
Just joking, but its going to be fracking awesome.

 

I hate having battles with implementing functionality.  The code looks awesome but it just doesn’t work properly.  You spam the internet search utilities looking for a solution to your perceived problem.  All the solutions you find either work partially or don’t work at all.  You take several breaks out of frustration, only to come back to try the same things again but with subtle variations hoping that one variation will solve all of your issues, but it never does.  Then you decide to try an alternative implementation to achieve the same level of functionality and you promise yourself you’ll go back and make things right “someday” and while implementing this functional yet impractical solution you come across something that makes you want to throw your keyboard out the window.

I just had such a moment.  I decided to take a break from getting panning on my othorgraphic viewports to work properly and I decided to work on getting mouse input ready for Zooming and eventually the Panning when I get to it.  To activate the zooming functionality, I wanted to be able to hold down Control and use the mouse wheel (which may just be simplified to using the mouse wheel but I may actually use the mousewheel for other functionality – note we’re talking about just the editor here).  So I started small and just went with trying to get mouse wheel input as keys were already handled elsewhere.  So I wrote some relatively simple code… check for a mouse down event, check to see if it was the mouse wheel, handle according to whether it was going up or down.  Results.  Except there weren’t results.  Well, there were, but they were sporadic.  Sometimes a mouse up event would work fine, othertimes it would take 2 or more complete rotations for it to be registered.  I went all over the internet only to find code that was relatively the same, but I tried it anyways.  Sometimes the code worked somewhat better, othertimes it didn’t work at all and still other times it just did the same thing. 

Frustrated, I figured that perhaps working with the mouse wheel was more complicated than I thought so I decided to go with a more complex implementation, but simple solution.  Pressing Control+Left Mouse Button then moving up+down would zoom in/out respectively.  The code was all in place… and sporadic results still.  What was more frustrating was that to register even a single mouse click, I had to press many times… and button release events were being caught once in a blue moon.  Something was clearly up.  I kept looking at my code, debugging, going through line by line until it kind of hit my like a punch to the face.  To capture keyboard input, I made a function that polls the events, checks to see if a key was pressed, and then it added the keypress to a list (which was passed to any classes requiring input).  There is also a seperate function in my main method that polls the events looking for the ESCAPE keypress.  These methods were being called before my mouse input method and it finally clicked.  SDL_PollEvent() takes the next event and puts it into the passed in SDL_Event object, which you do all your validation on.  So, many of the events were getting validated by the keyboard methods previously mentioned – including the mouse events.

I have had issues with my keyboard input but I never knew why.  Sometimes when you moved left and released the key, it would keep going left until you sent a few other keyboard events.  So my ESCAPE polling was “stealing” keyboard events from my main keyboard input function and both of those functions were “stealing” mouse input events.  Anyways, temporarily disabled the keyboard polling and voila, works beautifully.

Now I’m going to have to create an input object to store the states of keys and mouse input.  Sweet.

Game Engine: Update #17

It took me awhile but I eventually got an editor with 4 different view ports now.  Renderered (perspective) as well as three orthographic viewports for the Front, top and left side (although I’ll allow swapping between front/back, top/bottom and left/right.)  There is one more problem that remains however, related to the orthographic views…. and its funny that I should mention it because I think I just found the problem.

I quickly made up viewport classes and two projection methods, one for glFrustum and one for glOrtho (Oh, perhaps I didn’t mention this… I got rid of my dependence on GLUT, finally…).  Anyways, I was passing in the coordinates of the Model to my projection function of the ortho viewports when I really meant to use the camera coordinates.  I have Zooming of the orthographic view done through scaling the desired Zoom  with each cull boundaying (left, bottom, right, top).

I did it up really fast in perhaps a messy way though.  I assume the smallest ratio of the Width/Height to be 5 and 3.75 and I set this as the origin of the viewport.  Then I add or subtract the appropriate location value (x/y) to the left, right, center, and top boundaries, then I multiply by the zoom factor, which is clamped between 1 and 512 (which will obviously change somewhat as I mess around with values.)  This zooms fairly well (although there is one problem that might be related to me using the models location rather than the cameras location). 

Zooming was never my real problem though - it was panning.  I can pan “decently” right now, although it is incredibly fast and awful (which may also be due to my lousy implementation of keyboard input).  Clamping the pan has proven extremely annoying though.  I can’t quite figure out a good formula to calculate in the effects of the zoom.  If I’m zoomed in all the way, I would obviously like to pan to at least the edge of the grid.  If I’m zoomed out all the way so that the entire grid is visible, I would still like to be able to pan a small amount past each edge.

 

Game Engine: Editor To-Do List

Just a list.  To be added to and updated as time goes on.

Grid object(s)
+Functionality to draw grids on the screen with varying grid sizes, etc.
+Snap-to-Grid functionality
+XY, XZ, YZ Perspectives

Level Creation System
(Decide on how to go about creating levels.)
+BSP approach?
+Simple vertex + triangle approach?  (which might seem logical for a completely dynamic environment.  I also want to be able to edit the models on a per-object basis so each model because part of the level, but has the ability to change in an instant.  For example, the model of a tree could be customized by adding a base tree object, setting the desired tree model for that tree object and then turning on a “Model Edit” option which would allow you to change the vertices of the actual model for the tree object like like you would part of the level.)
+How will a level be built up?  Similar to UED 1-2 with Subtract brushes or Additive brushes?  Should the concept of brushes even be applied?

Mouse Interaction
+Need to implement mouse properly for rotating of camera.
+Need to create an interface of sorts for the editor to allow the designer to move around objects, rotate them, etc.

Updated Last:  November 12th, 2009.  GridObjects apparently need tweaking.

Game Engine: Update #16

My room is a disaster and I have no intention on cleaning it tonight, so its downstairs programming on my lappy (which is lightly annoying.)  I’ve just started working on a simple level editor… and by just started I mean just started.  My first (and current) task was to get a grid thing working.  I created another project for the level editor but right now I’m just putting everything in my actual Engine project so I don’t have to waste time putting things together to get the editor initializing.

I’ve decided that instead of building the functionality directly into the level editors code, I’ll build it into unrelated objects.  My first object therefore, is a grid, which may seem like such a simple thing.  To have an object whose only task is to draw a grid on the screen?  Well, I think I’ll cram more functionality into it, like snapping to points all that.  So all I’d have to do is somthing like SnapToGrid(myModel) or something.  Anyways, I initially made a grid that drew a 2D grid – the kind that you would see in a top down/side/front view.  This was by mistake, of course, as I really wanted to make a 3d grid or “perspective” grid as I’m calling it.  This is the one that’ll be used on the 3D rendering viewport.

I then started thinking that I needed both types of grids right?  If I was working with Java, I probably would have just stuck an integer or boolean flage called “iMode” or “bPerspective” and had all of the code in one spot.  After some more thinking, I decided that it would be in my best interest to just make a base Grid object and subclass that for different functionality revolving around a grid.  The initial object is simply called PerspectiveGrid.  The other type of grid though, the one to be used for the top-down/sides/front viewports, is a bit harder to name.

That has always been a problem of mine.  Naming simple classes is extremely hard.  In the grand scheme of things, you can call a class anything right?  class ABC.  class 123.  class MyNameIsProbablyTooLongForAClassName.  But you should always have a name that is short, to the point, and describes what the class is all about right?  Class 2DGridisn’t exactly correct or rather, unique because the perspective grid is just as 2D.  If you put a “2DGrid” object inside a 3D rendering space it will appear to be 3D.  I was thinking of “XYGrid” also because those are the axis’ that the lines are drawn on, where the PerspectiveGrid could also be called an XZ grid because those are the axis’ that it uses.  XYGrid versus PerspectiveGrid sounds odd though, so either I need to rename the one grid, or find a better name for the other.

So thats whats stopped me from working for a bit.  Deciding on what to name a bloody class.

*face palm*

 

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.