Hey everyone.
Sorry I haven't been around. I've been busy, plus my desktop PC died. I'll be buying a few bits and putting a new one together soon. Work takes up a lot of my time, but I really enjoy it, and I love the paychecks.
I'll be announcing hiatus on Alven over at VasilisaGames, because of an email I got saying that someone's looking forward to Bwock. No one cares about Alven so much, and it is in need of some restructuring. Bwock, however, is very fast to design and program, and it's fun, so I'm giving it love. I have to say though, I need Windows on my next desktop. Trying to install libraries and development apps on a laptop is a pain in the ass, and I want this program to be cross-platform. Especially a vista laptop. Plus I'm using Gosu, which requires the use of Boost. I love Boost, but I won't get too cozy with MSVC, so I have to install it in a round-about fashion for Code::Blocks/MingW.
Of course, in Linux its just "aptitude install boost" but hey, Windows is the easy operating system, right?
I also have a future project in my head. Having used an Industrial UML program that creates flowcharts to and from source code, I am sickened by the lack of acceptable replacements in the open source world. I mean come on, Dia? ArgoUML? Please. The latter doesn't even have a way to scope Enums in classes. *FACEPALMS* I know they're rough programs to make, UML being extremely complicated, but I want to give it a shot. It sounds fun, and I'd love to show up the proprietary UML developers. So that's something I'm looking forward to.
I'll finish up the 3D engines thing a bit later. Till next time.
Monday, December 22, 2008
Friday, December 5, 2008
Game Engines Part 5
Effects
I mentioned before that 3D and 2D programming (with engines) only differ slightly in their approach to the problem, which is to create an illusion of realistic space. This ceases to hold true when it comes to effects. Almost everything I'm about to discuss is done entirely different in 3D than 2D, so I'll set out those differences for each one.
Particles
For those who don't know, particle animation means drawing a lot of tiny little images or sparkles onto the screen to simulate less dense materials than meshes. Smoke, fire, rain, fireworks and magic are all done using particles. Because of this need, most libraries have something built in specifically for doing particles.
In 3D, the movement and shape of a particle cloud differs depending on how the player is looking at it. Recent advances have allowed the use of particles to do almost anything, like shading and distorting meshes. One of the best open engines for the newer techniques is called Horde3D. I recommend looking it up on youtube for an example of particles gone wild. For an example of how it looks in 2D, play Baldur's Gate.
Shadows
In 2D, shadows are pure illusions. They're fast, low-memory effects that basically paste a dark shape over the ground under a sprite. Sprites can also have the shadows drawn directly on as part of the player's image. Now, there have been 2D games where shadows are actually cast, but without some invisible 3D model this almost gets more advanced than simply doing it in 3D$. For example, how does it determine that a shadow should stop at a corner of the floor and start moving up a wall, when 2D has no concept of "up"?
In 3D, Shadows are easy. Most engines use some advanced, recursive math, but all you have do is place your lights and define what sort of approach the engine is supposed to take. In a program like Ogre3D, you can choose what method of shadows you want, such as additive, modulative, stencil and texture (in combination with one another ). You can also use other shadow libraries alongside Ogre3D if you're not satisfied.
I recently discovered that additive stencilling causes problems on some older ATIs, namely mine, which is why Irrlicht shadows flickered wildly when I attempted to use that engine. Using Ogre3D's modulative stencil shadows, I was able to have beautiful shadow effects without the flickers. Another cause of flickering with shadows is a wide "near to far" ratio, which causes an ugly problem called ZFighting. In simple terms, if you have the game processing a whole lot of shadows at a time in a very large world, it will have trouble figuring out what the proper drawing order is. The defaults are usually pretty safe, but eventually you'll need to learn how to control that.
WATER
In 2D, water is an animation. You're pretty much stuck with that. Sometimes that can be a generated animation, but its always just an animation. In 3D, you have a lot of choices. You can make one flat rectangular polygon, animate water on top of it, and be done with it. You can also go so far as to give it generate polygons for wave effects ( Ogre3D has something for this ). You also get to mess with the way water distorts objects moving inside it, the way it picks up light, and so forth. There's even a lighting effect for drawing wavelike movements on nearby walls, like real water does when light hits it. Again, I'm going to promote Ogre3D and say to check out its Fresnel and Water demos, if you can.
MAPPING
Environment mapping has been done for a long time. It really only works in 3D, since it's based on the angle that the user's camera is facing it. Environment mapping is a reflective effect that makes an object seem mirror-like while cylindrical. It uses a snapshot of its environment, which it maps across its polygons depending on the facing of the camera. Since it uses a given snapshot, it has the problem of showing the wrong location when used in a tile set sometimes. For example, in Neverwinter Nights a player's helmet is mapped to show the sky, so if you're indoors and zoom in, your helmet still reflects clouds.
The gist of all this is this: since 3D adheres to the way physical space really works for human perception, effects can be approached with the real world as a model. 2D, on the other hand, has to be approached the way you'd approach a painting.
I mentioned before that 3D and 2D programming (with engines) only differ slightly in their approach to the problem, which is to create an illusion of realistic space. This ceases to hold true when it comes to effects. Almost everything I'm about to discuss is done entirely different in 3D than 2D, so I'll set out those differences for each one.
Particles
For those who don't know, particle animation means drawing a lot of tiny little images or sparkles onto the screen to simulate less dense materials than meshes. Smoke, fire, rain, fireworks and magic are all done using particles. Because of this need, most libraries have something built in specifically for doing particles.
In 3D, the movement and shape of a particle cloud differs depending on how the player is looking at it. Recent advances have allowed the use of particles to do almost anything, like shading and distorting meshes. One of the best open engines for the newer techniques is called Horde3D. I recommend looking it up on youtube for an example of particles gone wild. For an example of how it looks in 2D, play Baldur's Gate.
Shadows
In 2D, shadows are pure illusions. They're fast, low-memory effects that basically paste a dark shape over the ground under a sprite. Sprites can also have the shadows drawn directly on as part of the player's image. Now, there have been 2D games where shadows are actually cast, but without some invisible 3D model this almost gets more advanced than simply doing it in 3D$. For example, how does it determine that a shadow should stop at a corner of the floor and start moving up a wall, when 2D has no concept of "up"?
In 3D, Shadows are easy. Most engines use some advanced, recursive math, but all you have do is place your lights and define what sort of approach the engine is supposed to take. In a program like Ogre3D, you can choose what method of shadows you want, such as additive, modulative, stencil and texture (in combination with one another ). You can also use other shadow libraries alongside Ogre3D if you're not satisfied.
I recently discovered that additive stencilling causes problems on some older ATIs, namely mine, which is why Irrlicht shadows flickered wildly when I attempted to use that engine. Using Ogre3D's modulative stencil shadows, I was able to have beautiful shadow effects without the flickers. Another cause of flickering with shadows is a wide "near to far" ratio, which causes an ugly problem called ZFighting. In simple terms, if you have the game processing a whole lot of shadows at a time in a very large world, it will have trouble figuring out what the proper drawing order is. The defaults are usually pretty safe, but eventually you'll need to learn how to control that.
WATER
In 2D, water is an animation. You're pretty much stuck with that. Sometimes that can be a generated animation, but its always just an animation. In 3D, you have a lot of choices. You can make one flat rectangular polygon, animate water on top of it, and be done with it. You can also go so far as to give it generate polygons for wave effects ( Ogre3D has something for this ). You also get to mess with the way water distorts objects moving inside it, the way it picks up light, and so forth. There's even a lighting effect for drawing wavelike movements on nearby walls, like real water does when light hits it. Again, I'm going to promote Ogre3D and say to check out its Fresnel and Water demos, if you can.
MAPPING
Environment mapping has been done for a long time. It really only works in 3D, since it's based on the angle that the user's camera is facing it. Environment mapping is a reflective effect that makes an object seem mirror-like while cylindrical. It uses a snapshot of its environment, which it maps across its polygons depending on the facing of the camera. Since it uses a given snapshot, it has the problem of showing the wrong location when used in a tile set sometimes. For example, in Neverwinter Nights a player's helmet is mapped to show the sky, so if you're indoors and zoom in, your helmet still reflects clouds.
The gist of all this is this: since 3D adheres to the way physical space really works for human perception, effects can be approached with the real world as a model. 2D, on the other hand, has to be approached the way you'd approach a painting.
Monday, December 1, 2008
My First day as a Programmer
Ever since I was 7 years old I was tinkering with code. I spent my childhood in QBasic, making space games and dreaming bigger than the language really went. Then it was on to ZZT, where I developed my first full length projects. I have always referred to myself as a “programmer”, because after all, I program. But it is only today that I can honestly say that I am, really and truly, a programmer.
I have a cubical with dual screens, I’ve been to a company lecture, I’ve reviewed private source code for which I’ve signed non-disclosure agreements, and I’ve finally been given a true standard to adhere to. It’s all very exciting.
The company I work for is called EDAS. They prepare products for engineering companies for testing equipment The software I’ll be working on uses test models that can be given different levels of vibration and pressure, then animated real-time. Extensive readouts are returned from this process, showing a map of stress levels throughout the blade as it is bent and abused. Pretty hardcore stuff!
The CEO of this organization is very driven by ethical standards. I will not have to feel like I’m in a place that undermines my own standards for business ethics, which are high. They also like Linux here, and every product is made cross-platform for Windows and Linux already. It’s not open source, of course… I doubt the companies that buy this software would want it to be since they can afford it, and need a guarantee of support.
At the moment I have nothing to do, so I typed this blog entry up. Hopefully I’ll still keep it well updated despite this 40-hour work week ( at 18$/hr ! )
Friday, November 28, 2008
Game Engines, part 4
Physics
Games today require physics. I think it's safe to say that only a handful of genres are safe from this now. But never fear. Although messing with physics has been one of the more difficult things I've done, in many ways it has been the most fun and rewarding. In a 3D environment, humans like to see things move the way they're supposed to, enemies fall and collapse realistically, and objects explode with real-time shrapnel. It's fun to look at, and it changes the way a game is played.
There are a great deal of physics engines out there. This is one field where proprietary, pay-to-use engines practically don't exist. While they're out there, they're not market-domineering like in other fields, and if they are sold, they normally are packaged with a graphics engine. You might have heard of Newton, the engine used in Portal, Half Life 2, Penumbra, and a ton of other physics-oriented games. While not open source, it's free to use as long as you show off the Newton logo on your product. It works in Linux, Mac and Windows.
Of course, you've probably guessed that I don't recommend it. Closed source software is not as "yours" as open source. You cannot modify it or look to see how it works. So I suggest any of many free alternatives: ODE, Bullet, Squirrel, and a billion more. I recommend Bullet. It's being used with the Blender game engine, and is picking up popularity very fast. It's also continuously updated.
Going into physics, I was a bit unsure about one thing. I knew that I had meshes in my program, and they draw to the screen based on their location and the camera's location. I got how that worked. But how was the physics engine supposed to look at the picture? Do I have to use mesh file types that work for both libraries? And how does the physics engine forcefully move objects in my 3D world?
It took me a bit to figure it out on my own, so hopefully this explanation will be helpful. It works like your average kitchen plastic wrap. Say you have a whiffle ball that you wrap up in that stuff; what shape is the wrapping after you've completely enclosed the object? Essentially, it's a sphere. In other words, it is not exactly the same as the object it is covering, but it outlines it. The holes aren't considered, unless you need them to be for some reason.
Because of this, physics bodies are less complex than the meshes they represent. Most physics engines use this trick ( among many others ) to minimize their cost. This is important, because every time you give an object physics you are basically cloning it in the same scene. This can take more memory, but not a whole lot of extra processing. After all, the invisible "wrapping" mesh is not being drawn, not being textured, not being shaded, and it's got significantly fewer polygons than the mesh it's connected to.
For Bullet, every dynamic object has a STATE. That state is its location and rotation. Every time you "step" the scene, which means applying about half a second worth of physics for a frame, or so, those states change. Overload the state class, edit it to contain a link to the mesh object, and have it move the mesh whenever IT moves. Thus, the wrapping tugs its mesh along with it, giving the illusion that the object itself has physics.
Didn't I say it was all an illusion?
Games today require physics. I think it's safe to say that only a handful of genres are safe from this now. But never fear. Although messing with physics has been one of the more difficult things I've done, in many ways it has been the most fun and rewarding. In a 3D environment, humans like to see things move the way they're supposed to, enemies fall and collapse realistically, and objects explode with real-time shrapnel. It's fun to look at, and it changes the way a game is played.
There are a great deal of physics engines out there. This is one field where proprietary, pay-to-use engines practically don't exist. While they're out there, they're not market-domineering like in other fields, and if they are sold, they normally are packaged with a graphics engine. You might have heard of Newton, the engine used in Portal, Half Life 2, Penumbra, and a ton of other physics-oriented games. While not open source, it's free to use as long as you show off the Newton logo on your product. It works in Linux, Mac and Windows.
Of course, you've probably guessed that I don't recommend it. Closed source software is not as "yours" as open source. You cannot modify it or look to see how it works. So I suggest any of many free alternatives: ODE, Bullet, Squirrel, and a billion more. I recommend Bullet. It's being used with the Blender game engine, and is picking up popularity very fast. It's also continuously updated.
Going into physics, I was a bit unsure about one thing. I knew that I had meshes in my program, and they draw to the screen based on their location and the camera's location. I got how that worked. But how was the physics engine supposed to look at the picture? Do I have to use mesh file types that work for both libraries? And how does the physics engine forcefully move objects in my 3D world?
It took me a bit to figure it out on my own, so hopefully this explanation will be helpful. It works like your average kitchen plastic wrap. Say you have a whiffle ball that you wrap up in that stuff; what shape is the wrapping after you've completely enclosed the object? Essentially, it's a sphere. In other words, it is not exactly the same as the object it is covering, but it outlines it. The holes aren't considered, unless you need them to be for some reason.
Because of this, physics bodies are less complex than the meshes they represent. Most physics engines use this trick ( among many others ) to minimize their cost. This is important, because every time you give an object physics you are basically cloning it in the same scene. This can take more memory, but not a whole lot of extra processing. After all, the invisible "wrapping" mesh is not being drawn, not being textured, not being shaded, and it's got significantly fewer polygons than the mesh it's connected to.
For Bullet, every dynamic object has a STATE. That state is its location and rotation. Every time you "step" the scene, which means applying about half a second worth of physics for a frame, or so, those states change. Overload the state class, edit it to contain a link to the mesh object, and have it move the mesh whenever IT moves. Thus, the wrapping tugs its mesh along with it, giving the illusion that the object itself has physics.
Didn't I say it was all an illusion?
Wednesday, November 26, 2008
Series break: Hex editing fun
I was over at a friend's house a while back, trying to get Ogre3D installed on his computer. Unfortunately, they made an "oops" with the binary package for Windows, and it kept looking for resources on the cd drive. In order to fix it, he opened something I hadn't seen before: a hex editor. In a few simple moves he turned all the "D:/" instances to "C:/" and it was fixed. I was so impressed I decided to try it myself.
I remember being a little kid and playing with Norton Commander in DOS. The program had a file viewer, and if you opened binaries you got gobbity gook. I remember thinking that someone actually programmed in those smiley faces and spades, and thinking "Oh wow, someone is really smart!". Funny thing; as it happens, I wasn't completely wrong.
I've used khexedit for a few small tasks this past week. One of them was to crack the uneditable worlds of an old game/programming tool I used to love called ZZT. I found out that a character on the second line was a '01' in locked games, and a '02' in unlocked games ( or maybe vice versa... anyway... ) Voila! I can edit locked games... or lock one. All on the binary level.
I found this fun, so I turned to script. Unfortunately most text gets compressed, such as with most of the Quest for Glory series and... (sob)... Commander Keen. What's more, on console roms it isn't even proper ASCII sometimes. However, N64 seems to be the simplest text to access, and of all the N64 games they picked the best one to make easy:
The text in Ocarina of Time is completely uncompressed. It's out of order, but its in plain text ( to a hex editor ). It's also possible to color sections using specific symbols, as above. I'm decoding it slowly. The important thing is that any unused space stays unused, so you have to use text that fills in the space as exactly as possible. I'm still not sure if I can control the creations of new lines and things like that, but I haven't spent much time with it.
I'd like to fiddle with FF7. Some people have been able to remake entire scenes in the game, changing characters, creating new dialogue, and so forth. I'm not clear whether they're using a ROM or the PC version, but I'm hoping its the former since I am using linux here. If anyone knows anything about this, please drop me a line.
This isn't really something I'd say is teaching me much, it's really just kind of fun. But you never know what you can learn doing weird things like this. Certainly teaches you a bit about security, and how binary gets read.
Guess this is another case of me going "Hmm, what can I discover in this cave?" and poking my head in.
I remember being a little kid and playing with Norton Commander in DOS. The program had a file viewer, and if you opened binaries you got gobbity gook. I remember thinking that someone actually programmed in those smiley faces and spades, and thinking "Oh wow, someone is really smart!". Funny thing; as it happens, I wasn't completely wrong.
I've used khexedit for a few small tasks this past week. One of them was to crack the uneditable worlds of an old game/programming tool I used to love called ZZT. I found out that a character on the second line was a '01' in locked games, and a '02' in unlocked games ( or maybe vice versa... anyway... ) Voila! I can edit locked games... or lock one. All on the binary level.
I found this fun, so I turned to script. Unfortunately most text gets compressed, such as with most of the Quest for Glory series and... (sob)... Commander Keen. What's more, on console roms it isn't even proper ASCII sometimes. However, N64 seems to be the simplest text to access, and of all the N64 games they picked the best one to make easy:
The text in Ocarina of Time is completely uncompressed. It's out of order, but its in plain text ( to a hex editor ). It's also possible to color sections using specific symbols, as above. I'm decoding it slowly. The important thing is that any unused space stays unused, so you have to use text that fills in the space as exactly as possible. I'm still not sure if I can control the creations of new lines and things like that, but I haven't spent much time with it.
I'd like to fiddle with FF7. Some people have been able to remake entire scenes in the game, changing characters, creating new dialogue, and so forth. I'm not clear whether they're using a ROM or the PC version, but I'm hoping its the former since I am using linux here. If anyone knows anything about this, please drop me a line.
This isn't really something I'd say is teaching me much, it's really just kind of fun. But you never know what you can learn doing weird things like this. Certainly teaches you a bit about security, and how binary gets read.
Guess this is another case of me going "Hmm, what can I discover in this cave?" and poking my head in.
Tuesday, November 25, 2008
Game engines, part 3.
The API
I am not making this blog into a tutorial for one library or another. Blogs aren't really good for that. Since you're here reading on your own accord, I think you have the will and ability to teach yourself anything. There's plenty of tutorial documentation out there, anyway. What I'm offering in this series is more of a stepping stone - an understanding of the mindset you need to quickly and efficiently conquer the library of your choice.
You have the tools. A brain. Community. But there's something else that's equally useful in becoming self-taught; three letters that every programmer should know: API. Indeed, if you intend to use ANY library, whether for games or for any other project you can imagine, then you'll need to become familiar with this term. It's a bit of a strange, ambiguous acronym, but also very simple.
An API is simply the interface for programming with a library, or anything else. It stands for "Application Programming Interface". It is the vocabulary of what you want to program with. For example: in Allegro, "blit" is the function you use to draw an image on the screen. Just now, I am talking about Allegro's API. Turns out you can also use draw_sprite, and the arguments get reversed when you do ( which is ugly, I believe they're fixing that in the newer versions. ) So now I'm discussing problems with the API. That's a subject that gets talked about a lot, for any library.
A lot of different libraries use very similar APIs, to make migration easier. Ogre3D and Irrlicht, for example, both work the same way:
1. Every object in a Scene is a Node.
2. The Scene Manager controls Nodes.
3. Programmer directly controls Scene Manager
Because they share these similarities, it is easier to jump from one library to the other. They aren't usually exactly the same, however. If you want to use two libraries together, it's best that they use slightly different APIs, or at least enclose the similarities in different namespaces. But they're close enough.
The API is not normally something you have to just up and learn, nor are you required to go in and figure it out by reading the source code. There are programs such as Doxygen which go through source code and efficiantly document the API into web pages. This is almost always done. In fact, here's Ogre3D's:
http://www.ogre3d.org/docs/api/html/
This is a huge library, so it gets an equally huge API. But using the API, you can quickly figure things out. For example:
Q: How do I rotate a 3D object?
A: Well, its basic knowledge that all 3D meshes are attached to Node objects. So what you must rotate is a Node. In the Ogre API, click 'classes' at the top. Under 'N' is Node(Ogre), which means the Node class in namespace Ogre. Click 'Node'
Presto, all the methods you can call on a node object. And only a few pages down, or if you do a find for Rotate, there's yaw, roll, pitch, and two (complicated ) rotate methods. They also show you what arguments they need! Don't know what an argument means? Click it. And if you click on the method name itself, it jumps down to the special comments from the source code in a neat blue box. Very organized, isn't it?
The Allegro API is especially nice. You can download it as a .chm file ( Windows help, but Linux can view it too ), or you can view it online. Allegro has a really solid, easy to read API, with lots of description, and a comfortable theme. You hardly need to look at another tutorial.
There are some languages that are too young to have a great API. If you chose to work with Gosu, you'll have some trouble. Their API is more a series of tutorials, but if you work with Ruby, someone threw one for you together on the Wiki. Thats a good example of why you want to pick a library that favors your particular programming language - stinks to be an odd one out, when you're looking for help. But Gosu's also easy enough that you hardly need references.
The point of all this is that when you're looking into a library you might want to use, go first to its API. You are often tempted to start by looking for a tutorial. Don't do that. There are always tutorials, but APIs that are neat and well documented are vastly superior. Besides, one person's way of coding might just make you more confused ( though there's nothing wrong with looking ).
API Links to look at:
Allegro
Ogre3D
Irrlicht
JMonkey Engine
I suggest you peek at all these links for examples :)
I am not making this blog into a tutorial for one library or another. Blogs aren't really good for that. Since you're here reading on your own accord, I think you have the will and ability to teach yourself anything. There's plenty of tutorial documentation out there, anyway. What I'm offering in this series is more of a stepping stone - an understanding of the mindset you need to quickly and efficiently conquer the library of your choice.
You have the tools. A brain. Community. But there's something else that's equally useful in becoming self-taught; three letters that every programmer should know: API. Indeed, if you intend to use ANY library, whether for games or for any other project you can imagine, then you'll need to become familiar with this term. It's a bit of a strange, ambiguous acronym, but also very simple.
An API is simply the interface for programming with a library, or anything else. It stands for "Application Programming Interface". It is the vocabulary of what you want to program with. For example: in Allegro, "blit" is the function you use to draw an image on the screen. Just now, I am talking about Allegro's API. Turns out you can also use draw_sprite, and the arguments get reversed when you do ( which is ugly, I believe they're fixing that in the newer versions. ) So now I'm discussing problems with the API. That's a subject that gets talked about a lot, for any library.
A lot of different libraries use very similar APIs, to make migration easier. Ogre3D and Irrlicht, for example, both work the same way:
1. Every object in a Scene is a Node.
2. The Scene Manager controls Nodes.
3. Programmer directly controls Scene Manager
Because they share these similarities, it is easier to jump from one library to the other. They aren't usually exactly the same, however. If you want to use two libraries together, it's best that they use slightly different APIs, or at least enclose the similarities in different namespaces. But they're close enough.
The API is not normally something you have to just up and learn, nor are you required to go in and figure it out by reading the source code. There are programs such as Doxygen which go through source code and efficiantly document the API into web pages. This is almost always done. In fact, here's Ogre3D's:
http://www.ogre3d.org/docs/api/html/
This is a huge library, so it gets an equally huge API. But using the API, you can quickly figure things out. For example:
Q: How do I rotate a 3D object?
A: Well, its basic knowledge that all 3D meshes are attached to Node objects. So what you must rotate is a Node. In the Ogre API, click 'classes' at the top. Under 'N' is Node(Ogre), which means the Node class in namespace Ogre. Click 'Node'
Presto, all the methods you can call on a node object. And only a few pages down, or if you do a find for Rotate, there's yaw, roll, pitch, and two (complicated ) rotate methods. They also show you what arguments they need! Don't know what an argument means? Click it. And if you click on the method name itself, it jumps down to the special comments from the source code in a neat blue box. Very organized, isn't it?
The Allegro API is especially nice. You can download it as a .chm file ( Windows help, but Linux can view it too ), or you can view it online. Allegro has a really solid, easy to read API, with lots of description, and a comfortable theme. You hardly need to look at another tutorial.
There are some languages that are too young to have a great API. If you chose to work with Gosu, you'll have some trouble. Their API is more a series of tutorials, but if you work with Ruby, someone threw one for you together on the Wiki. Thats a good example of why you want to pick a library that favors your particular programming language - stinks to be an odd one out, when you're looking for help. But Gosu's also easy enough that you hardly need references.
The point of all this is that when you're looking into a library you might want to use, go first to its API. You are often tempted to start by looking for a tutorial. Don't do that. There are always tutorials, but APIs that are neat and well documented are vastly superior. Besides, one person's way of coding might just make you more confused ( though there's nothing wrong with looking ).
API Links to look at:
Allegro
Ogre3D
Irrlicht
JMonkey Engine
I suggest you peek at all these links for examples :)
Sunday, November 23, 2008
3D ( And 2D ) Game Engines, Part 2
What is true of all game engines?
1. The more you understand simple geometry and graphing, the better. Coordinate systems are the way to present things to the human eye. This should be pretty obvious, but as you go from novice to pro, you'll quickly learn that there are things about your own perception that you never noticed.
2. Collisions and physics always use the same basic principles. As a matter of fact, advanced physics libraries such as Bullet and Newton ( ala Portal ) can be just as beautifully applied to 2-D as 3-D. One big difference is that in 2D, you can get away with collision using rectangles more easily, or even do a check on pixel overlapping.
3. Everything is an illusion. There is no physical space occupied by the hero of your game. Consequently, you will need to use a number of tricks that don't really fit reality. In 3D, we use a system called "Paging" to erase polygons that are hidden behind other polygons, so that the system has to do less work. There are also texture tricks that make it appear as if surfaces are reflecting ( called "environment mapping" ) when they're actually doing very little work. 2D has its own set of eye tricks.
4. You must care about your resources. This relates to the paging concept in 3. If you've only worked with text based applications, you're probably used to being able to do whatever you want. With even the most basic 2D graphics, however, this is not so. You have to watch your memory usage, only load what's needed, unload what you're done with, and above all, have a solid data structure to manage these operations.
1. The more you understand simple geometry and graphing, the better. Coordinate systems are the way to present things to the human eye. This should be pretty obvious, but as you go from novice to pro, you'll quickly learn that there are things about your own perception that you never noticed.
2. Collisions and physics always use the same basic principles. As a matter of fact, advanced physics libraries such as Bullet and Newton ( ala Portal ) can be just as beautifully applied to 2-D as 3-D. One big difference is that in 2D, you can get away with collision using rectangles more easily, or even do a check on pixel overlapping.
3. Everything is an illusion. There is no physical space occupied by the hero of your game. Consequently, you will need to use a number of tricks that don't really fit reality. In 3D, we use a system called "Paging" to erase polygons that are hidden behind other polygons, so that the system has to do less work. There are also texture tricks that make it appear as if surfaces are reflecting ( called "environment mapping" ) when they're actually doing very little work. 2D has its own set of eye tricks.
4. You must care about your resources. This relates to the paging concept in 3. If you've only worked with text based applications, you're probably used to being able to do whatever you want. With even the most basic 2D graphics, however, this is not so. You have to watch your memory usage, only load what's needed, unload what you're done with, and above all, have a solid data structure to manage these operations.
Friday, November 21, 2008
3D Game Engines, part 1
While I was in college, I worked ahead of my classes with a 2D graphics library called Allegro. After I graduated, I proceeded to work with SDL, Gosu, Irrlicht, and Ogre3D (in that order. ) Any field of computer science is an unending journey of learning, but I would still consider myself enough of an authority on graphics engines to write on the subject. In fact, that's why my friend Matt suggested that I start this blog.
This will be part 1 of a series, as there's a lot of ground to cover and I want to be detailed. I want to teach the aspects of this subject that slowed me down, so that other programmers won't have to muddle through it like I did.
For part 1, I'm just going to go over all of the engines I've fiddled with and describe them to you, so that you can decide what you want to mess with. This won't help much in terms of use, but it will allow you to pick a starting place and give you time to get familiar with its community. If you've never installed a library before, I suggest asking google since that's a fairly lengthy subject, but it generally goes something like this:
Step 1: In Windows, download/install the SDK. In Linux, compile the source code, or look for a package ( for example, in Ubuntu a lot of libraries are in the repositories, all you have to do is apt-get install the one you want! ) Sometimes you have to compile source in Windows, too. Don't worry, it's not that hard, and you have more control over the result. I always reccomend doing the compiling if you can, but if you're an absolute beginner you can pick something with a package or SDK.
Step 2: Link to it. A library is compiled ( or packaged that way ) not because its a program, but because all of its source code does NOT need to be compiled over and over every time you want to test your program. You just link to it. This speeds up development significantly. You usually link to one or more dll or object files, which is either placed in your system's path ( /windows/system32 or /usr/lib ) or in the folder of your project. Actually, you can put it anywhere, as long as your project can find it! Most IDEs, for example, CodeBlocks, are good about setting up directories. Just go to the build option and pick where you stashed your object files. Again, this is not required if you have it in your path.
Step 3: Include the headers. The rules are the same. The headers will be in a folder somewhere, and they tell the program what the API (syntax) of the library is. These have to be found by the compiler too. Like the binary, this can either be via the system path, or a preferred location.
And that's all, you just have to include the headers you need into your project and it should work. Each library has its own documentation for how to do this.
Without further ado, The libraries!
ALLEGRO: Allegro is programmed in C, but it's pretty high level. It does have a few globals, but it wraps well in C++ if you intend on using classes. All of this aside, Allegro is a fantastic library that is made to be easy and fun. It's mostly 2D, but very fast and very high quality. http://www.allegro.cc shows just how many wonderful projects have been made in it. Some of them are extremely impressive!
Please note that this library has recently undergone some serious renovations, so if you get the latest version, it will be a totally different library from the one I've been using. I reccomend it though, because it's more standardized and simpler to read.
SDL: It's faster than Allegro, and uses OpenGL, but it's harder. It doesn't come with a lot of easy functions like flipping and rotating, filling, drawing primitives, and so forth. There are modular libraries that can be added to SDL to make it do these things, but they dont come bundled. SDL does have a lot of documentation, and using it will teach you more about 2D than Allegro will, since Allegro does the work for you. SDL has been used commercially quite a bit. It's a C library, like Allegro.
Gosu: Easy as it gets. Gosu is designed to be very strict in form, simple, and elegant. Development in Gosu is FAST. I had a whole engine working from scratch in under 3 days. The downside is that it hides everything for you. You can't, for example, directly alter loaded images. So if you want to animate an explosion within the program, you're out of luck - you'll have to do that as a little animation that gets imported. This isn't usually an issue.
Gosu is C++ all the way, and forces the use of Boost pointers, so to use this library you'll need to get Boost too. But this is a good thing; boost pointers delete themselves! No memory leaks :) And it's going to be added to the C++ standard eventually anyway, so it wouldn't be a bad idea to learn how Boost works.
Irrlicht: My first 3D graphics engine. Actually, my first was CrystalSpace, but that one is way too complicated to start with. Irrlicht, however, is the easiest I've messed with. It has built in collision detection, physics, and shadow effects. However, it's buggy. The stencil shadows have a lot of issues that are still needing correction. On some ATI linux machines they flicker wildly. It's also just not very powerful, and doesn't offer you as many options as the next library. But for beginners, that may be a good thing. Irrlicht is C++.
Ogre3D: This is what I finally decided upon. Ogre3D is easy, powerful, flexible, and MASSIVE. As an example, Irrlicht has just one shadow type, but Ogre3D has six. It is also made to be modular. It does not come with physics, or collision detection, or anything like that, but the massive community has contributed code that lets you link it up easily with other libraries. Ogre3D also comes with a sample framework that lets you jump right into programming a scene without any setup, all in a single function. Used in conjunction with the tutorials on the website, this is quite powerful. Also C++
If you're a Java user, look into JMonkey. If you prefer python, Disney's Panda3D is your weapon of choice. And I should mention, if you're a fan of Ruby, most of the Gosu community uses that instead of C++ ( but there's support for both ).
This should help you get started. Using this information and a little google-fu, you should be able to pick a library and set it up fairly easily. I'll be writing on Allegro and Ogre3D, since those encompass the 2D and 3D programming provided in the list. If you choose something else, you should be able to apply anything I say. Libraries aren't all that different, really.
Anyway, good luck, and see you next time!
This will be part 1 of a series, as there's a lot of ground to cover and I want to be detailed. I want to teach the aspects of this subject that slowed me down, so that other programmers won't have to muddle through it like I did.
For part 1, I'm just going to go over all of the engines I've fiddled with and describe them to you, so that you can decide what you want to mess with. This won't help much in terms of use, but it will allow you to pick a starting place and give you time to get familiar with its community. If you've never installed a library before, I suggest asking google since that's a fairly lengthy subject, but it generally goes something like this:
Step 1: In Windows, download/install the SDK. In Linux, compile the source code, or look for a package ( for example, in Ubuntu a lot of libraries are in the repositories, all you have to do is apt-get install the one you want! ) Sometimes you have to compile source in Windows, too. Don't worry, it's not that hard, and you have more control over the result. I always reccomend doing the compiling if you can, but if you're an absolute beginner you can pick something with a package or SDK.
Step 2: Link to it. A library is compiled ( or packaged that way ) not because its a program, but because all of its source code does NOT need to be compiled over and over every time you want to test your program. You just link to it. This speeds up development significantly. You usually link to one or more dll or object files, which is either placed in your system's path ( /windows/system32 or /usr/lib ) or in the folder of your project. Actually, you can put it anywhere, as long as your project can find it! Most IDEs, for example, CodeBlocks, are good about setting up directories. Just go to the build option and pick where you stashed your object files. Again, this is not required if you have it in your path.
Step 3: Include the headers. The rules are the same. The headers will be in a folder somewhere, and they tell the program what the API (syntax) of the library is. These have to be found by the compiler too. Like the binary, this can either be via the system path, or a preferred location.
And that's all, you just have to include the headers you need into your project and it should work. Each library has its own documentation for how to do this.
Without further ado, The libraries!
Click the name for a link to the official website
ALLEGRO: Allegro is programmed in C, but it's pretty high level. It does have a few globals, but it wraps well in C++ if you intend on using classes. All of this aside, Allegro is a fantastic library that is made to be easy and fun. It's mostly 2D, but very fast and very high quality. http://www.allegro.cc shows just how many wonderful projects have been made in it. Some of them are extremely impressive!
Please note that this library has recently undergone some serious renovations, so if you get the latest version, it will be a totally different library from the one I've been using. I reccomend it though, because it's more standardized and simpler to read.
SDL: It's faster than Allegro, and uses OpenGL, but it's harder. It doesn't come with a lot of easy functions like flipping and rotating, filling, drawing primitives, and so forth. There are modular libraries that can be added to SDL to make it do these things, but they dont come bundled. SDL does have a lot of documentation, and using it will teach you more about 2D than Allegro will, since Allegro does the work for you. SDL has been used commercially quite a bit. It's a C library, like Allegro.
Gosu: Easy as it gets. Gosu is designed to be very strict in form, simple, and elegant. Development in Gosu is FAST. I had a whole engine working from scratch in under 3 days. The downside is that it hides everything for you. You can't, for example, directly alter loaded images. So if you want to animate an explosion within the program, you're out of luck - you'll have to do that as a little animation that gets imported. This isn't usually an issue.
Gosu is C++ all the way, and forces the use of Boost pointers, so to use this library you'll need to get Boost too. But this is a good thing; boost pointers delete themselves! No memory leaks :) And it's going to be added to the C++ standard eventually anyway, so it wouldn't be a bad idea to learn how Boost works.
Irrlicht: My first 3D graphics engine. Actually, my first was CrystalSpace, but that one is way too complicated to start with. Irrlicht, however, is the easiest I've messed with. It has built in collision detection, physics, and shadow effects. However, it's buggy. The stencil shadows have a lot of issues that are still needing correction. On some ATI linux machines they flicker wildly. It's also just not very powerful, and doesn't offer you as many options as the next library. But for beginners, that may be a good thing. Irrlicht is C++.
Ogre3D: This is what I finally decided upon. Ogre3D is easy, powerful, flexible, and MASSIVE. As an example, Irrlicht has just one shadow type, but Ogre3D has six. It is also made to be modular. It does not come with physics, or collision detection, or anything like that, but the massive community has contributed code that lets you link it up easily with other libraries. Ogre3D also comes with a sample framework that lets you jump right into programming a scene without any setup, all in a single function. Used in conjunction with the tutorials on the website, this is quite powerful. Also C++
If you're a Java user, look into JMonkey. If you prefer python, Disney's Panda3D is your weapon of choice. And I should mention, if you're a fan of Ruby, most of the Gosu community uses that instead of C++ ( but there's support for both ).
This should help you get started. Using this information and a little google-fu, you should be able to pick a library and set it up fairly easily. I'll be writing on Allegro and Ogre3D, since those encompass the 2D and 3D programming provided in the list. If you choose something else, you should be able to apply anything I say. Libraries aren't all that different, really.
Anyway, good luck, and see you next time!
Thursday, November 20, 2008
And so it starts...
Before I became passionate about computers, I was a writer ( and I suppose I still am ). As such, I've had a lot of experience with blogging, but it's always been personal; a hodge-podge of poetry, politics, and other mundane matters. Then a friend of mine, also a geek, suggested that I begin a blog that shares some of my self-taught programming knowledge. It's a bit more accessible, and it's something I've flirted with doing for some time. So I'm doing it.
This is my geek blog. Here, I will give out programming tips, source code, discoveries, opinions in the field ( of which I have many ), and so forth. I'm a Linux user, so there will be an open source slant to all of this, but I do believe in reaching across the aisle with cross-platform programming and the like. I also do like games, though I'm a tad behind ( I'm playing FF7 on an emulator currently ). I will occasionally do a game review if something impresses me.
Last, I may discuss music now and then as I'm a huge J-Rock fan ( Japanese rock, in case you don't know what I'm talking about ). I can see a lot of my friends rolling their eyes at my irrepressible fandom, but this ~is~ a geek blog, and J-Rock is pretty damn geeky. My free time is a fairly simple rotation of fancies: J-Rock, Games, Programming, J-Rock, Games, Programming, J-Rock... etc. And a little bit of internet fun on the side.
So a bit about myself.
I'm Joseph Austin, and I live in Nashville, TN. Great people here, but also ass-hats. And no jobs. I'm a recent college graduate and I'm feeling the heat of this ruined economy. I have yet another interview next week, but even so I'm getting up early tomorrow to go apply at another ten places. Hurry up and fix things, Obama, hit the undo button!
I like to program, and my dream is to do games. Thats the cute fantasy of a lot of would-be programmers, but the difference is that I actually like to code. To me, programming games would be the ultimate mix of creative story telling and pure geekiness - a convergence of my two main personalities. I grew up on Adventure games, where stories and puzzles helped hammer logic into my brain. I discovered early that no medium could draw me into a plot like one where I'm the hero, and I still have yet to lose that feeling. I want to one day create a universe so exciting, original and interesting that it actually inspires players, the way games like Gabriel Knight and Final Fantasy does for me.
I have a website: http://www.vasilisagames.com
There's a game on it, but it's REALLY old. I'm touching up the source a bit, but it's filthy. I was still in school when I wrote it. I can't wait to upload some good code, and I have some moderately good stuff almost ready for launch. The date for release on my latest project was for Saturday, but I got sick a week and a half, so I'm extending it. I'll be posting that on the site soon, maybe tomorrow.
Well, that's all I have to say for now. I'll be thinking about what to write tomorrow :)
This is my geek blog. Here, I will give out programming tips, source code, discoveries, opinions in the field ( of which I have many ), and so forth. I'm a Linux user, so there will be an open source slant to all of this, but I do believe in reaching across the aisle with cross-platform programming and the like. I also do like games, though I'm a tad behind ( I'm playing FF7 on an emulator currently ). I will occasionally do a game review if something impresses me.
Last, I may discuss music now and then as I'm a huge J-Rock fan ( Japanese rock, in case you don't know what I'm talking about ). I can see a lot of my friends rolling their eyes at my irrepressible fandom, but this ~is~ a geek blog, and J-Rock is pretty damn geeky. My free time is a fairly simple rotation of fancies: J-Rock, Games, Programming, J-Rock, Games, Programming, J-Rock... etc. And a little bit of internet fun on the side.
So a bit about myself.
I'm Joseph Austin, and I live in Nashville, TN. Great people here, but also ass-hats. And no jobs. I'm a recent college graduate and I'm feeling the heat of this ruined economy. I have yet another interview next week, but even so I'm getting up early tomorrow to go apply at another ten places. Hurry up and fix things, Obama, hit the undo button!
I like to program, and my dream is to do games. Thats the cute fantasy of a lot of would-be programmers, but the difference is that I actually like to code. To me, programming games would be the ultimate mix of creative story telling and pure geekiness - a convergence of my two main personalities. I grew up on Adventure games, where stories and puzzles helped hammer logic into my brain. I discovered early that no medium could draw me into a plot like one where I'm the hero, and I still have yet to lose that feeling. I want to one day create a universe so exciting, original and interesting that it actually inspires players, the way games like Gabriel Knight and Final Fantasy does for me.
I have a website: http://www.vasilisagames.com
There's a game on it, but it's REALLY old. I'm touching up the source a bit, but it's filthy. I was still in school when I wrote it. I can't wait to upload some good code, and I have some moderately good stuff almost ready for launch. The date for release on my latest project was for Saturday, but I got sick a week and a half, so I'm extending it. I'll be posting that on the site soon, maybe tomorrow.
Well, that's all I have to say for now. I'll be thinking about what to write tomorrow :)
Subscribe to:
Posts (Atom)