Long night

Things have been going sluggishly lately due to some issues with a slew of cross references, inheritance, and multiple files. My BaseApplication class uses the Gob (Game Object) class which uses the BaseApplication . That went fine, no problems. But when I attempted to derive an Eye (Camera) class from Gob, putting the definition of Eye in it's own .h and .cpp files, the compiler whined about an undefined class Eye, despite the class Prototype I made. Anywho, the only solution I could come up with was to move all the code for the Eye into the Gob files.

Anywho, with that problem out of the way, I now have an Eye that can be attached to any other Gob. It will follow that Gob around the scene.

Misc. Update

Just got scene loading working. Well, most of it. One of the models in the scene is coming in at a different angle than it should be.

I also figured out zoom in orthographic mode. Which took longer than it should have due to some misleading forum posts.

First blog of the semester

As the semester began. I forced myself to rethink what I'm doing. The physics and collision stuff is fun, but I feel that maybe that's an area I could use a little guidance in if I want to understand and build on the techniques involved in it. Or maybe I really just need to read a book on it. I don't know.

At any rate, the physics and collision engine is still going to be developed on. But it's taking the back burner for now. Instead, I'm now attempting to focus on the actual game development part of the whole thing. I realize, given the amount of time I have left, that I probably won't make anything too fun or exciting. But I do wish to make something functional, at least.

In that regard, I chose Ogre to actually make the game. I have a decent sized code base for it, it's easy to use with only a bit of work to get set up, and the most important factor was that it has extensive model and animation features.

Development has went along pretty nicely so far. I've set up the base application, game object (Gob), and game state classes, and added in the framework for joystick support.

My goal(s) for next Monday are:

1. Add basic dotScene support. Have most of the code already. Just need to integrate TinyXML into the project and tweak the scene loader.
2. Using a 360 controller. Get something moving on the screen.
3. Implement line-circle collision.

Overall project update. Final blog of fall semester

I started this project by writing a very simple python version of a verlet system, modeled after a paper I read on the subject. I had been wanting to write my own physics and collision code for a while, and while I do want to use it for a game, it's my primary focus for senior project.

Jacobsons paper, Advanced Character Physics, was a great introduction paper to using verlet integrationg for physics. The concepts of Particles and Constraints was really easy to grasp, and turned out being very easy to model more complex shapes from; Like soft and rigid bodies.

The first "wave" of code came along pretty nicely. I had some trouble understanding a few things involving the math behind verlet particle integration, but they were worked out pretty quickly. Constraints math wasn't too much more difficult. The goal is merely to push the two the particles apart from one another by half of the distance they need to move to be exactly the rest length apart.

Once it was time to start testing, I had to decide what I want to use for my graphical back end. I really wanted to use something different than pygame, so I went with pyglet, an opengl module for python. Pyglet was decent when I first started, definitely easy to get started with. All I needed was to set up a window, get the fps, and draw a crate powered by my simple physics. Much to my dismay, once I got it working, I realized it couldn't handle much, even as simple as it was in comparison to everything that goes into a dynamics engine. There was a lot coming still(collision, friction, restitution, so I knew I needed to optimize.

Before optimizing, I wanted to clean up an refine some of the code I had. So I started a second version of my code, making a few minor changes while rebuilding everything. Next, I tried getting rid of the Vector2 class, just to get rid of that overhead. With most of the code being vector math, this turned out to be a bit of pain, and somehow, I managed to mess up the math at some point. Soon after, I just decided that it probably wouldn't be worth it to optimize a physics engine in python no matter how many optimizations I used, anyway. So, I rewrote the physics in C++, with the intentions of making it a module for python, though I never did. After finishing the first version and confirming the numbers, I decided that I should try to squeeze in a bit more optimization using simd instructions. I looked into simd for a while, had some trouble getting it to work because I'm an idiot who never set the proper compiler flags. I found out, after writing a simd Vector2 class with overloaded +,-,*,/ operators, that there wasn't much of performance improvement through overloading those particular operations when only dealing with two numbers. Instead, I would need to use simd only during the parts where a lot of that vector math is happening at once, like when solving constraints. Also, I could pack two 2D particles into a Vector4, and do two at a time. But that would only work during the integration step, not when solving the constraints.

Soon, I decided not to bother with most of the optimizations for a while, move on with writing the collision code. The collision code didn't go well at first, but is under way and should be roughly done soon into next semester. Afterward, I'll hopefully have my mind made up about what tools I'll be using to develop the game with, whether it be Ogre or OpenGL. Most likely Ogre, for it's animation utilities, but we'll see.

The future of this project relies on my getting my dynamics engine done. First and foremost, that is my goal, and after that, it's game time.

Goals for the week

Today, Poly and I worked out some discrepancies with the vision of our game, and have come to a conclusion, and hope to develop the following assets before next week:

- Stand in art for characters. For right now, just ninja, warrior, mage, and archer.
- Stand in level. Preferably wiener themed.
- Stand-in projectiles.
- Finish up bitmask intersection algorithm
- Get vector based movement implemented
- Start on collision. Probably going to require quad tree optimization first.

Updates! Blogs! Gads!!!

Today, I made my goal to write a simple Bitmask class. A bit mask is basically just a 2D array of booleans.

The class I made loads in an image, looks at each pixel and any pixel not transparent gets a 1. Any other colors and it gets a 0. Eventually, these will be used for alpha masking and per pixel collision.

Stuff to add to the bitmasks:
- Overlap detection: Report the maximum overlap of two bitmasks for each axis.
- Rewrite in C++, using the Python-C API, so it's more efficient. Right now, using python, each "bit" is really an int, taking up much more space than necessary. If I rewrite in C++, I'll actually be able to use booleans. Of course, that also means I either have to bust out some sort of png library for C++, or send to C++ huge multidemensial arrays. A png library would be much faster, but I'm not familiar with any, so who knows how complicated it could get.

OH! I could use SDL to load and parse the images. And I know SDL. I'll just have to see if you can load in an image without initializing all the root SDL stuff or creating a screen and whatnot.

Some technical babble

I decided to go with pyglet and python to develop the first iterations of my game. Pyglet is a multimedia and windowing system. It supports 2D and 3D and is built around OpenGL. The main reason I'm going to use it, though, is because it says that PyOpenGL is compatible with it without need for modification, which seems like it will be a huge benefit when or if it comes time for the switch to 3D.

By next week I hope to at least have a fair understanding of pyglet, a base application written, and some images moving around on the screen.