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 ! )
Subscribe to:
Posts (Atom)