Debugging is like farting — it’s not so bad when it’s your own code.

The Art of Daydreaming

Posted: October 20th, 2010 | Author: | Filed under: Tutorials | 1 Comment »
20070118_daydream

Daydreaming helps!

So for the past week or so, I’ve been feverishly working on Darwena. I got my platform-specific code up for the PC and OSX, got my OpenGL contexts working, integrated FreeImage and FreeType. And then I stopped. For the past day and a half, I have been doing nothing but dreaming and conceptualizing. Professionals would call this design, but no, it’s all in the head. It is something that very few novice programmers engage in.

So what was I daydreaming about? It was how to implement my material system. Give this task to any graphics programming student, and they’d be right at it. How hard can it be? All you need are textures, maybe color and alpha bias. That and throw in some shader support if you’re ambitious enough, right? So why am I sitting here thinking about it instead of going straight to implementation, like I would do for any school assignment?

The reason is that I have hit a critical section. No, I’m not talking about multithreading. What I mean is that any functionality I implement at this point is going to change the whole texture of my entire engine. It is going to affect its capabilities, ease of use, and generally the whole design philosophy. Yes, I have set down the design philosophy ahead of the whole project, but subtle nuances at this stage of development can heavily influence the interpretation of this philosophy. This makes it worth a taking the time to put a little thought into it, no?

So how do you go about this daydreaming process? First thing I do is clarify all the design objectives of this particular subsystem, and how it will affect the texture of the whole engine. What do I want from it both now and in the future? My first milestone is a 2D engine, so it seems rather trivial. But when I want to extend to 3D and beyond later, I had better have a system that can either be extended or is already capable of that, yes? Also, there is a reason why I chose a 2D engine as my first milestone. I want to have a very dynamic fluid organic material system. If we focus on 3D straight away, this is usually glossed over. In a 2D game however, you do pay attention to animated textures, sprite systems and other things that will make your overall material system more robust.

That done, I start of with the most obvious solutions. Step through each one in my head, and weight the advantages, disadvantages and perceived problems. I also envision how this implementation will affect the design of other systems. It can be a bit much, but it is a system of thinking that I have developed over the years. Visualizing the code running in my head and seeing what leads to what. Then you start tweaking. How different are the results from what you can achieve? Can you make subtle changes to make things go the way you want them to?

Finally, after doing all that, it’s time to do some research. Hit the web and the periodicals to see how everybody else tackled these design issues. Note that this is done only after running through things myself. Most fresh programmers would go straight to the altar of the Google God, pick the first feasible solution they come across, and copy-paste the code, massaging it into their own code base. They then end up with the ideal solution for somebody else’s project. At the very worst, they have a piece of code that they do not understand and just seems to work like a magical black box. This is not good. Not good at all. Instead, what I do is see what others have done, and what benefits they get from doing it their way. Then I look at my own original solution, and fit together ingredients from the ideas I gathered from the wild till I am happy with the concept, and how it will fit in with the rest of my codebase.

And then after all that, I finally start writing code. This is actually the easy part because you already know what to do. All you are doing is translating the ideas into a language that the computer understands, like C++. If you have been doing this long enough, it’s a fairly relaxed and enjoyable process. You don’t have weird design bugs popping up because everything was thought of and conceptualized beforehand.

And that my friends, is what the art of programming is all about!


Webbifying Darwena

Posted: October 11th, 2010 | Author: | Filed under: Tutorials | 2 Comments »
Darwena

Darwena

As posted previously, I am working on a new OpenGL game development framework. Since it is my own personal project (at least for now), I get to decide how to go about documenting it. Like every other programmer out there, I hate documentation. Can there be a greater waste of brain power? However, it is a necessary evil that needs to be done. So since I’m a tech person (or why would I be in this industry?), I decided to go about automating it as much as I can.

The first thing I did was put up the wiki at http://www.darwena.com. I just used Mediawiki. The good folks at Dreamhost handily have a one-click install in their control panel. So I fill in a bit of information, click “Go”, and voila! I have a wiki!

I decided to give the wiki a very simple structure. The bulk of the wiki will be tied to the “Project Roadmap”. So as each module is completed, I just click on the link and add a little writeup about what it does. Easy. I imagine that as I begin incorporating more things, the wiki page itself will grow naturally.

For API documentation, I pick my favorite tool… Doxygen. I downloaded the frontend to my PC to generated the doxyfile (i.e. the configuration file). I then sshed to the webserver, downloaded the Doxygen source, and compiled it there. I had a bit of a problem with the language translator, but I found the right place to disable that. Don’t really need documentation in Norwegian anyway, do I?

I then made simple sh script to update my Mercurial repository, run doxygen and copy the contents to my web fol.. directory. (folder is Microsoft-speak!). Put up a cron job to run that every day and perfect! I did mess up a bit on this step though. The first time I did this, I enabled their “File Browser” thing, and all my ugly code got published to the web. OMG! OMG! I quickly fixed that. Hopefully Googlebot didn’t peek in while that was up.

Oh, I mentioned Mercurial didn’t I? Yes, that is indeed how I am managing my source control. Mercurial over ssh. Can I be more secure? What’s better is that I can push it to my portable hard disk for yet another backup copy.

I’m sure any company or organization could easily implement what I have on an internal web server. Not only do you end up spending less time writing documentation (well, it only seems that way), but it also automatically becomes available to the rest of your development team.

One last shout out for those of you who are not aware or who have forgotten about the Darwena Logo Design challenge. Make me a logo and win fifty bucks. What could be more easy? It ends at the end of this week, so hurry with the submissions.


Setting Up Your Macbook Pro For Development

Posted: September 25th, 2010 | Author: | Filed under: Tutorials | 1 Comment »
My new Macbook Pro!

My new Macbook Pro!

Recently (last night in fact), I had my new Macbook Pro delivered. This 15″ beauty was augmented with a matte anti-glare screen and a 7200rp 500GB drive. Boasting a 2.53GHz i5 processor and 4GB worth of RAM, it is truly a worthy development platform. However in order to convert it to that, a fair amount of preparation must be done. Sure, you could just install XCode and say you are good to go, but you can’t really say you are working at maximum productivity, can you?

This first thing I install, as with all Mac machines, is Quicksilver by Blacktree. This allows you to bind a hotkey that calls up quicksilver. Once done, you just type in the first few letters of the application, music, url, xcode project, etc. that you want to open. Autocomplete will find it for you, then you just press enter to launch it straight away. Not only is it tremendously useful, it is also extremely stylish with its bezel interface and all.

The next thing to go in is Visor, also by Blacktree. This provides me with a full-screen Terminal which I can toggle at the touch of a button. I bind this to my F12 key. Since it messes with OSX internals, it needs a bit of setup. You have to install SIMBL, and then copy the Visor Bundle in to a specified location. Once that is done, run Terminal and set up the preferences to whatever you like. At this point, I would create my .bash_profile and .vimrc files. The .bash_profile is mainly to customize my prompt. The .vimrc file of course, is for Vim, my text editor of choice.

Once the basics are in, everything else follows. I grab the latest version of Xcode from Apple’s Developer Site. In my case, I grab the one with the iPhone SDK. For source control, I install Mercurial. Subversion and CVS already come bundled with OSX. I prefer Mercurial as my primary source control for a few reasons. Firstly, it’s dead easy to set up. No weird config files or hooking up through Apache. Merging is also much better supported. Second, I can sync via SSH. Quite a few times, I failed to sync with SVN over http because of messed up proxy-servers on whatever ISP I’m connected to. Lastly and most importantly, I can sync to multiple locations. So I can have master copies on my server, as well as on my portable hard drive, and sync with either one of them. Of course, being a freelancer, you work with whatever your client uses. So having all three is good.

For my productivity suite (I wonder why they call it that), I use iWork. It’s cheap, compared to Microsoft Office. It is also simpler and easier to use, and more impressive to look at. There’s really no reason why I would want to use the travesty called MS Office because simple developers like myself have no need for mail merge or the other 1001 esoteric features that nobody uses anyway. Also, it means that for presentations, I get to use my cool apple remote (that came with my previous Macbook but is not included with this one).

Communications. For mail, I install Postbox Express. It is hands-down, the best free IMAP mail program out there. There’s both Windows and Mac versions, so I have it installed on my desktop as well as my Macbook. If you’re stuck with POP, default Apple mail works. For messaging, I use Adium. Why Adium and not the tonne of other messaging clients out there? Because it looks cooler. It’s not good enough to be awesome. You’ve got to be awesome with style!

The only thing left is a decent image editing program. The best, of course, would be Photoshop. However, given that I have the artistic talent of a gerbil, I can’t really justify the price. A free alternative is the Gimp. It looks as ugly as sin, but it gets the job done. My preferred choice would be Pixelmator. It’s just barely affordable, looks great, and has everything you need for programmer art and more. Alternatively, if you are expecting to get a Wacom for any reason anytime soon, Photoshop Elements and Corel Painter Sketchpad would probably fill whatever gaps you have.

System tweaks. Dump all your music into iTunes. Can’t code without good music, can you? Surf DeviantArt to look for nice-looking wallpaper. Open up your system preferences. Under Account settings, go to startup items and remove iTunes Helper. This prevents iTunes from annoyingly popping up everytime you hook up an iPod/iPhone/iPad. Disable Time Machine. Set up Expose and Spaces to work the way you want it to. Modify power settings to be less annoying. Require a password on login and when you exit a screensaver. Got to do your dues for those NDAs!

Now that you’re done with OSX, it’s time to look at Windows. You didn’t really think you could get away from that, did you? I bought VMWare Fusion for $10 (an upgrade since I seem to have been suckered into buying an early version long time ago). Set up a virtual machine with 100GB disk space 1GB RAM and 1 core, and installed an old copy of XP on it. Why XP? Fusion doesn’t support anything above DirectX 9 anyway, so why spend money on another Windows 7 license when XP will do fine? If you are into hardcore Windows development, a better approach would be to set up a BootCamp partition and install Windows 7. It means you have to reboot to get into windows, but the performance is better. Either way, after windows is installed, I install Microsoft Visual C++ 2010 Express. That’s probably the only reason why I need Windows, so I leave it at that.

And with that done, you are all set to dive into the code and do a few laps. If you get bored while waiting for things to install, why not blog about it? I did.


Taming Visual Studio

Posted: March 3rd, 2010 | Author: | Filed under: Tutorials | No Comments »

This is a guide to setting up Visual Studio to make use a folder structure that is flexible and portable across multiple machines. It is intended for students, which is why no templates are included. After all, you are supposed to understand what each of the settings do!

Stay Away!

A lot of SDKs have tutorials and guides on installation, and advise that you make changes from the Tools > Options  screen as shown here. Don’t do it! What this does is make global changes to Visual Studio so that all your projects will use the same copy of the SDK. This means that you will find it difficult to use different versions of the SDK on different projects on the same computer. Also, if you pass your code to anybody else, they will need to get a copy of the exact same version of the library you are using and install it on their machines in a similar way in order to compile your code. The only SDK where it is permissible to touch this menu at all is DirectX, and that is because it is installed in an anal OS-monopolistic fashion. For anything else, follow the procedure below.

Our target is to get a working folder structure something like what follows. The bin folder will contain your executables. The lib folder will contain all your SDKs. The obj folder will contain all your object files so they may be discarded later. The project folders will contain the source code and project files of the various projects you have in the solution. This allows you to distribute your work in the following ways:

  • For end users, just give them a copy of the bin folder. That is all they need to run the program.
  • For source code inspection, just give them the project folder(s). Useful if you have quick questions on code snippets.
  • For distributing your source code, delete the obj folder and the intellisense file, and send the rest. This will ensure the end user can compile a copy of their own. This is what I expect to be submitted to me for assignments.

Creating a new project

So let’s get started. First thing is to create a new project from the File > New > Project menu. This will give you a choice of various types of projects to create. What you want to create is either a Win32 Console Application, or a Win32 Project. The Console App will provide you with a DOS box that you can cout to at whim. The main entry point for this would be main(). The Win32 project, on the other hand, makes a standard windows application without any console (unless you hack it in). The main entry point for this would be WinMain(). Make sure to tick the “Create directory for solution” checkbox.

newproj2

After you fill in a suitable name for the project and click OK, you will come to this screen. Do not Finish immediately. Instead click on Application Settings. The top 4 options lets you change your mind and build a console app or Win32 project or even a library… talk about redundancy. In the checkbox below however, you want to tick “Create Empty Project”. If you do not do this, Visual Studio will create a lot of junk for you that you will need to clear out later. After you are done, click Finish.

Once you are done, the project will be created. I personally like to delete the “Header”, “Source” and “Resource” folders so I can implement my own structure, but that is up to your preference. What you must do, is add a blank .cpp file to your project. It doesn’t matter what you call it or what’s in it. What this does is tell Visual Studio that this is indeed a C++ project, so it will show you all the relevant C++ options. Never mind that the application I installed was Visual C++ Express. After you have done that, go to Project > Properties to configure your project.

ProjSet1

The first thing you should do here, change the configuration to “All Configurations” so that you affect both the release and debug builds. Next, expand “Configuration Properties” on the left, and select the “General” category. Here you will change the output folders, to comply with the specifications we have above. These are the changes I made:

  • Output Directory, this is where all the exe files are made. Set it to $(SolutionDir)bin
  • Intermediate Directory, this is where all the obj files are made. Set it to $(SolutionDir)obj/$(ProjectName)/$(ConfigurationName)
  • Character Set, this changes all your strings to wide character strings. For game projects, you really shouldn’t be depending on the compiler for implementing unicode anyway. So set it to “Not Set”.

ProjsSet2

After that, click on the “Debug” category. Here, there is only one change to make. However, this setting needs to be set up for every single computer you move the project to. This is because Microsoft, in their infinite wisdom, decided that this particular setting should be personalized to each user. So don’t forget this every time you copy the project from one computer to another.

  • Working Directory, this is where your application will launch from when run from Visual Studio. Set it to $(OutputDir)

Include Folders

Next, click on the C/C++ category. If you do not see the same screen as in the screenshot, expand it out and click on general. Here, you will only change one setting, which is the “Additional Include Directories”. You will set this up to point at the include folder of whichever SDK(s) you are using. Multiple folders can be included by separating them with a “;”. Alternatively, doubleclick on the box and you can browse to each of the individual folders. Make sure that all your folders are set up relative to your Solution folder. This will ensure that your project, when copied over, will still be able to find the include files it needs. This means that every single one of the entries here should begin with $(SolutionDir)lib/

Examples:

  • $(SolutionDir)lib/ogre/include
  • $(SolutionDir)lib/hge/include

Linker Options

Next, expand out “Linker” and click on “General”, which is just under it. Here, just like the include folders, you will tell Visual studio where all the lib folders are by changing the entry “Additional Libarary Directories”. The setup is exactly the same. All entries are seperated by “;”. Examples:

  • $(SolutionDir)lib/ogre/lib
  • $(SolutionDir)lib/hge/lib/vc

Still on the same tab, the next bit is tricky. First, you will want to set the configuration to Debug, so that you only affect the debug build. It may prompt you to save settings, which you should agree to.  After that, change the “Output File” from “$(OutDir)\$(ProjectName).exe” to “$(OutDir)\$(ProjectName)_d.exe”. After that, apply your changes and set the configuration back to “All Configurations”. What this does is make sure that all your debug builds have a “_d” at the end of the exe names, so you can readily identify if your binaries are debug or release.

Additional Libraries

Next, still under “Linker”, switch to the next subcategory, “Input”.  Here, under “Additional Dependencies”, you will list down the .lib files that your SDK requires you to link into your project. These, in a great show of consistency, are not separated by a “;” like everything else, but are instead separated by a single space. Once you have added those in, you are done with project settings and can click OK. Your project is all set up… almost.

Do not forget to copy an .dll files that your SDKs might need into your bin folder. Also, if you need to include any additional assets in your project like artwork or sounds, the bin folder is where it’s all at. That is your base. And that… is all!