Lovloss' Place

Me Being Helpful

2010-12-16T22:04:00.001-08:00

http://www.ogre3d.org/forums/viewtopic.php?f=5&t=61988

Sometimes if you want a job done, you have to do it yourself!

My Way or the Highway

2010-12-13T20:56:00.000-08:00

I have a big problem when I work on open source. It becomes similar to writing a novel or a short story for me. I see my audience, those who will look at and judge my code. And in my urge to please them, I make one mistake over and over again: I try to make my code expect everything.

I've been over it many times with people, and I know every programming book on the planet will tell you that swiss-army-knife code is bad, but I still do it. Here's a good example:

I was making a Java program that was supposed to help build text adventure games from easy script files. This project got cancelled for two reasons: one, I realized that Inform is already better suited towards creative writers, and two, if you wanted to make a text game in a readable scripting language, you have options already. That being said, I never got past designing the thing. Because the design just kept getting bigger!

First you were just going to script the thing and it would run in a console. Then I decided on a front end. But to have a front end, I needed some standards, like... during dialog, maybe pop up people's faces when they talk automatically. Hmm, I thought, but what if someone doesn't want to do that? Oh, I know, I'll make a super generic front-end and people can subclass it.

Then... maybe people could just subclass it, build the Java binaries and drop them in a folder for me to automatically pick up and add to a menu. Oh! And while I'm at it, they need to be able to do ANYTHING with their front end, so the game should be able to communicate with it via back-and-forth string communication. Now we're talking! I should have stopped at "I'll make a front-end". And I won't even go into my scripting language and its ability to accept commands out of order (good gravy.)

This is a pitfall of programming. Wanting to please your audience is normal, but its hard to remember that you -are- your audience in this particular industry. In all honesty, I pick up code and don't judge it much at all until it annoys me. I just figure out how to make it do what I want and then I do it, and there's always a way when you have the will. So on my current project - the first open-source phase of a commercial mega-project - I'm going to try and force myself to be stricter. I think I may get something done this way.

Advice to the X-Brained

2010-12-01T12:30:00.001-08:00

“Intellectual growth should commence at birth and cease only at death” – Albert Einstein

One thing I bring to the table when I program is the creativity I inherited from my years of writing. When I apply the mentality from one to the other, beautiful things happen every time. If there is one thing I have learned from this, it is that the concepts of ‘left brain’ and ‘right brain’ are things we tell ourselves to justify limiting our knowledge.

If you look back across the pages of history to people like Leonardo De Vinci, what we call “renaissance men”, you don’t see so much of that restrictive psychological theory being applied to genius. Even Lewis Carol, author of the whimsical and extremely creative “Alice in Wonderland” was an absolute master of math and logic, which may in fact be precisely why he so beautifully twisted those concepts in his writing.

I hear it all the time. “Oh, I’m X-brained, I can’t understand that.” Sure you can. “It is beyond me.” No it’s not. Now, some people may be more intelligent than others due to biology, or their abilities may be stronger one way than another. But this doesn’t mean we have half a brain alive and half rotting in our skulls. Our minds are not fettered by anything more than an inherently flawed notion of ‘logic verus art’, which is probably the fault of some Freudian philosophy.

The truth is, creativity serves you well in science and math. Without it, you can only repeat other scientists and nothing will advance. But without logic, you cannot apply structure to your creativity and - let’s face it - arbitrary jumbles of words or sounds have no value (some disagree and produce such things, but will always be statistically non-existent.) So, don’t be afraid to bring it all together.

Shadows

2010-11-22T12:45:00.001-08:00

Are evil.

WORK damn you.

Control System

2010-11-21T01:36:00.000-08:00

I finished creating the control algorithms for piloting your main character in the game I'm working on. Bit of matrix math, but the result is nice. You can take a peek at the following link:

http://www.youtube.com/watch?v=NiKG3gEpWNA

When playing games, you never really realize what the controls are doing, yet you expect them to act a certain way. For my game I modeled the controls after Final Fantasy 10, which I feel has very comfortable controls. The biggest challenge was not making movement relative to camera position, but doing so without annoying the player. When a camera angle changes, so do the relative forward, back, left and right directions. If you're already mentally moving in a particular tangent, you do not expect it to suddenly switch on you. So I made it wait until you release the keys, so that camera changes don't send your player the opposite direction unexpectedly.

Project Pandemonium

2010-11-18T13:31:00.001-08:00

I have not seen enough feedback to warrant its continuation of Bwock at this juncture. So begins Project Pandemonium, which is going to be a little bit different. The 2D puzzler was fun, and the game really is nice to play in its current state. But now I'm moving into the modern age with a fully 3D, Japanese-style roleplaying game (JRPG). This blog will be dedicated to the creation of the game.

What I can say about it now is the following:

1. It will be both commercial and open source. I have a solution for that which I think is pretty freaking clever, but I'm keeping it on the hush.

2. It won't be expensive. However, donating additional funds to the game price will be available to those who wish to show their generosity to independent game development. You don't get more indie than this.

3. It will be cell shaded

4. The story will be both fun, and subversive.

5. The battle system will be very traditional. I'm tired of Square trying to come up with obfuscated ways to do what we play those games to do.

6. There will be freely available modding tools, and a solution for doing your own RPG (or whatever) using elements from my engine without any royalties. Yay!

If you are thinking to yourself that you might like to assist, you are not unwanted. While I have no money to spend on assembling a team for this project, nor have I any guarantees regarding what kind of cash flow it might bring in, I am willing to negotiate splitting income with anyone who wants to contribute their time. I am a generous person.

BWOCK

2010-05-30T00:23:00.000-07:00

I've been spending quite some time lately working on and promoting an open source project of mine, Bwock. It's a 2D top-down puzzle game thingy. I would love contributers, but just getting clicks would be nice for now. Please feel free to visit / link to the following locations:

Google Code Site: http://code.google.com/p/bwock
Vasilisa Games Site: http://www.vasilisagames.com

The google code site has demo executables for Linux and Windows if you want to see the game run. A mac version may be coming soon. :)

My brain needs a quad core.

2009-03-06T10:39:00.001-08:00

I am so restless lately in my programming. You'd think 8 hours a day of it at work, 5 days a week, would turn me off on doing the same thing in my spare time. But no, it doesn't. Instead, I've become enthusiastic from the things I've learned at work, and when I go home I try to apply them to my projects. The problem is, there isn't just one project on the table.

I received requests to finish Bwock, a puzzle-pusher game in the style of Adventures of Lolo. I really, really need to get that done. But something else has also nabbed my attention, folks - something much bigger. Something that could potentially get my name OUT there, and get vasilisagames.com some serious hits. I wish I wasn't doing it alone, but if it works then I may not have to in the future.

I'll say a few things. It's going to be open source, Java, and similar in some ways to a popular project called "Inform". It's for interactive fiction, but it's so flexible that even I'm not sure what it's limits are yet, and I only have the basic engine partially done. I've had to create my own scripting language for the thing, which was some of the best fun I've had behind a keyboard. I think people will like the simplicity of it.

I'm debating the license for it, but currently it's documented as MIT, which means it's ultra free. This could potentially mean a big company can modify it into their own program and sell it, but they couldn't stop anyone else from doing the same thing. I might switch the core to LGPL, if I can make it work with java correctly, and let interfaces be MIT so that the project itself can't just be yanked out from under me. I'm still thinking.

I'm not a huge fan of java, but it's really great for open source. Every platform can run the exact same file, it generates beautiful javadocs, etc. Besides, this is not a process-heavy program - no heavy math, no polygons, no massive data trees. Its just text parsing... with a twist ;)

And now lunch is over, so I'm getting back to work. Fare thee well.

Mmm minty

2009-02-20T11:01:00.000-08:00

I want to come on here and sing praises for something known as Linux Mint. I've been a user of the Ubuntu flavor for quite a while now ( a few years, to be sure. ) I've come to favor Kubuntu, but I was disenchanted with Intrepid Ibex because it basically undid everything I had found convenient about the previous versions. Well, KDE did anyway. I backtracked to Hardy Heron and was there for a little while, but then I got a new, powerhouse machine with an XP partition for my gaming. So I decided to start over and look for a new flavor to try.

There must be a different version of linux per user of the actual operating system, because hunting one down is not easy. I realized what I wanted was something that was ready for me, from the instant I installed it. I love the Debian approach to repositories, but their GPL-only ethos is a pain. For example, who ISNT going to install mp3 support? Seriously, now. I wanted that hot-and-ready feeling you get from Windows, except without the eventual meltdown. This brought me to look at linux mint.

Mint offered what I was looking for, but they did better than that. Their system is based off Ubuntu directly. That means that I am instantly comfortable in the new environment, because I know it. There are some new things to look at, but nothing is missing. And everything just works, even wireless detection - which usually sucks in linux. I seriously think I could give this OS to my mom and she'd get cozy in just a few minutes. It uses gnome, but the mint desktop is configured to have a sort of KDE feel to it in a lot of ways. As you might expect, everything's really green, including the many wallpapers you get by default. I think the offset of green and black/grey they use is calming. Reminds me of a 7-Up can.

I've gotten quite comfy and I just wanted to reccomend it, since I have a small voice here. You can find out more at: http://www.linuxmint.com/

Oh, and for those of you who don’t know already… it’s 100% free. In more ways than one.

Cool Programming Tricks Episode 2: Anonymous structs

2009-02-06T10:33:00.001-08:00

This is a C++ trick that I learned at work. Similar concepts must exist in other languages, but I do not know of any. Additionally, this won't do much for EMACS or vi users who don't have auto-completion. How do you live by the way?

Anyway. You may be used to viewing structs as an inferior form of a class. Actually, they're technically the same in C++ with visibility differences, but in practice they are totally different! A struct is made for organization. Try thinking of them as tables inside a document, with several fields apiece that you can change separately. The uses of such might seem limited in programming, where you want to cut down on the amount of variables in each scope to simplify your efforts ( i.e., a new class with private variables. ) However, you will always wind up having a lot of things to choose from regardless of this simplification. Sometimes making a class to hold your many variables is not the answer. After all, what's the point of a class that's all accessors and mutators?

My sorting trick is an anonymous struct. I didn't even know these existed. They wear no type name, therefore you cannot instantiate it, ever. It exists once and only once: in the scope it's created in. Take a look:

class Game {
private:
struct {
BITMAP* player;
BITMAP* enemy;
BITMAP* background;
} graphics;

struct {
SOUND* music;
SOUND* hit;
} sfx;
}

These structs, graphics and sfx, ONLY exist inside this class. So they become like folders of data, and thanks to the power of IDEs, you can take advantage of this. For example, if you start designing a level for this game, you need to remember what the bad guy's BITMAP pointer was. Well you don't have to go to the header if you remembered 'graphics'. Simply type "graphics."(with the dot) and any IDE worth ten cents will pop up a box listing each of the images. If you don't want to have to memorize all these structs, put THEM in a struct called "media", and remember that. It's just like managing your desktop. You could take this really far and have every single one of your classes put all its private data in an anonymous struct called 'pdata', and never look through your headers again. A real time saver!

I do this frequently since learning at work. No problems so far. Do let me know what you think!

Cool Programming Tricks Episode 1: The “It’s me again!” technique.

2009-01-27T10:26:00.001-08:00

I thought I’d divulge some of the coding tricks I use most often for my fellow programmers visiting this blog. Mainly I would like to get some opinions on them; after all, I’d like to know if I’m walking on a short pier. However, I think they’re fairly useful little tricks and I’m proud of how they’ve worked out for me so far.

By the way, I’m not familiar with ALL the major design patterns, so some of my tricks might have names I don’t know of, in which case – fill me in!

Now, on to my favorite trick by far. You can do this in just about any language that supports inheritance.

As we all know, a pointer to an interface or base class can be assigned to any children of said class, provided you use only the methods available in the pointer’s type ( if you don’t know what I’m talking about, get a design patterns book FAST! ) One of my favorite things to break up into small encapsulated classes is the program’s interface. A game’s loading screen, game play, credits, score board, etc, are often crammed into a single driver class or even called in the main loop with a ton of conditionals. I prefer them to be in separate classes.

So try this. You have your main class with its main loop. There are a series of functions that get looped through in any mode, usually draw() and update(). Whatever the current mode is, the loop delegates to that mode and it runs until a switch is needed. Normally, programmers will have some kind of return value or other check to see when to make the switch. But I prefer to have the MODE do the switching. If update() gets called once a loop, why not have it return the next mode to switch to?

mode * nextMode = curMode->update();
if( nextMode != curMode ) {

delete curMode;

curMode = nextMode;
}

If you have some way of only keeping one of each mode ( singleton, or something else, ) simply don’t delete. This is even easier with boost’s smart pointers or your chosen language’s garbage collection. Long story short, your current mode will keep returning itself ( “ITS ME AGAIN” ) until it needs to switch, in which case it returns an instance to the appropriate mode. You can even have one return NULL for something else, say, ending the program.

This trick does not stop at game modes. Anything which delegates functionality to different child classes using the strategy pattern can use this in some form. For example, a game I am currently working on nests the use in two cases. The game’s mode is done this way, but within one of them I use the trick again, for dialog boxes. In the case of my game I don’t even need singletons or such.

I have yet to run into even a small amount of trouble doing this. Tell me what you think.

The Windmill of Quixotic Code

2009-01-09T06:37:00.000-08:00

When you program, are you a perfectionist? Do you take to heart all the lessons you learned from your shelf of computer books - lessons like, "always make your code reusable"? Coming into my recent job, I truly felt like being that way was going to help me exceed all their expectations. I was going to give them the ideal code - a comment for every variable and function, everything in a class structure, no globals. Then I opened up the project I'd be working on for the first time, and saw a "goto".

What you learn when you leave school is that perfect code doesn't exist for large projects. It's a pie in the sky, and if anyone preaches it to you, they are trying to make themselves seem like better programmers than they probably are. In the actual "biz", you get three adjectives for computer software, of which you may only have two at any given time:

Efficient.
Good.
Cheap.

My workplace, EDAS, is strictly the first two, but even then there are tradeoffs between "efficient" and "good". I consider "good" programming to be modular, since new features only need to affect certain elements of the code. But nothing's as "efficient" as code created with a specific purpose. So we have to keep things about 50/50 if we want a good name in our industry. Sometimes that means a goto, or a global variable.

If you go into a project charging at windmills, you'll quickly find very little accomplished. Seek what is useful, not what is ideal. If you are a hobbyist, I encourage you to try everything in your code. Try all the things you've been told not to try, and attempt to figure out where they're most useful. You'll get an occasional geek on a soapbox telling you that your code's inferior, but if nothing else it will be YOU and not them that actually knows why something must be avoided, rather than doing so dogmatically.

This is a lesson I myself have learned, and thought neccessary to share. I wish I had fully understood it myself when I came aboard with this company. But, at least I'm doing a good job now, and luckily I unlearn as quickly as I learn.

Blah blah

2008-12-22T13:23:00.001-08:00

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.

Game Engines Part 5

2008-12-05T20:28:00.000-08:00

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.

My First day as a Programmer

2008-12-01T10:08:00.001-08:00

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 ! )

Game Engines, part 4

2008-11-28T20:30:00.000-08:00

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?

Series break: Hex editing fun

2008-11-26T21:01:00.000-08:00

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.

Game engines, part 3.

2008-11-25T13:51:00.000-08:00

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 :)

3D ( And 2D ) Game Engines, Part 2

2008-11-23T21:20:00.000-08:00

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.

3D Game Engines, part 1

2008-11-21T07:45:00.000-08:00

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!

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!

And so it starts...

2008-11-20T19:30:00.000-08:00

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 :)