In this so-called new age of web design, there appears to be an underlying trend in “Web 2.0″ websites. Something about it makes me cringe, because wherever you look, especially in websites showcasing portfolios or whatever, the language style is exactly the same. Informal speak, as if you’re talking to the visitor as a friend, I guess. To me, it’s pure cheese.

HELLO. MY NAME IS BOB SMITH. I MAKE GOOD WEBSITES, AND STUFF.

You know what I’m talking about. The HUGE TEXT THEY USE TO SHOUT AT THE USER ON THE HOMEPAGE. Okay, so why? Well, you could argue it draws in the user’s attention, and that it instantly tells the user what the website is about. Fair enough. But I get bored when browsing CSS design showcases, only to find almost all of them follow this trend. Admittedly, even I fall victim to this nonsense. I get a feeling design showcases discriminate websites that don’t. Perhaps it’s just another internet phase.

My 5 minute browsing results:

http://paiko.de/
http://www.baeck.no/
http://www.sergionoviello.com/
http://nathan-sanders.com/
http://www.shannonmoeller.com/
http://www.jamisonbanham.com/
http://www.jasonreedwebdesign.com/
http://sprawsm.com/
http://www.postmachina.com/

I could go on… Forever.

Changelog:
6th January 2010
- Updated application walkthrough for Ogre 1.7.

Overview

Howdy! This is my little FAQ and troubleshooting guide for anyone new to the Ogre engine. I will be expanding it over time to cover as many problems and questions as possible. The following assumes that you are using Visual Studio C++ 2005/2008 and have built the latest Ogre.

If you haven’t yet built Ogre, see my Building Ogre with Visual Studio guide.

Can you walk me through setting up an Ogre application?

Sure!

1. Open up Visual Studio C++.
2. File -> New -> Project…
3. Make sure the project type is “Win32″ and the templated “Win32 Console Application” is highlighted.
4. Enter the name and location of your project in the respective fields. I named mine “OgreTestProject”.
5. An application wizard will pop up. Click “Application Settings” and check “Empty project” then click finish.
6. Right click the “Source Files” folder in the Solution Explorer. Then Add -> New Item…
7. Select “C++ File (.cpp)” and enter “main” in the Name field. Add “\src” to the end of the Location field value.
8. Go to Project -> Properties.
9. In the top left hand corner of the Properties window change the Configuration to “All Configurations”.
10. Select General in the Configuration Properties. Copy the “Output Directory”. Select Debugging and paste this in the “Working Directory” field.
11. Expand C/C++ -> General
12. In the “Additional Include Directories” click the “…” button and a dialog should pop up. Again, click the “…” button, navigate to YourOgreRoot/YourBuildDir/sdk/include and select the subfolder “OGRE”. Click ok twice.
13. Change the Configuration drop-down in the top left to “Debug”
14. Expand Linker -> General
15. In the “Additional Library Directories” navigate to YourOgreRoot/YourBuildDir/sdk/lib and select the subfolder “Debug”.
16. Go to Linker -> Input
17. In “Additional Dependencies” add “OgreMain_d.lib”.
18. Change the Configuration drop-down in the top left to “Release”
19. Go to Linker -> General
20. In the “Additional Library Directories” navigate to YourOgreRoot/YourBuildDir/sdk/lib and select the subfolder “Release”.
21. Go to Linker -> Input
22. In “Additional Dependencies” add “OgreMain.lib”.
23. Click ok.
24. Enter the following code in main.cpp:


#include <Ogre.h>

int main(int argc, char* argv[])
{
    Ogre::Root* root = new Ogre::Root("plugins.cfg", "ogre.cfg", "Ogre.log");
    delete root;
    return 0;
}


25. In the toolbar at the top next to the green arrow is a drop-down list. Make sure this is set to “Debug”.
26. Click the green arrow.
27. Oh no! You got “This application failed to start because OgreMain_d.dll was not found. Re-installing the application may fix this problem”.
28. Navigate to the location of your Ogre SDK and head to the bin folder, then the debug folder. Copy “OgreMain_d.dll”.
29. Go to your project directory, there should be a new folder named “Debug” paste “OgreMain_d.dll” in there.
30. Press the green arrow in Visual Studio again.
31. Congratulations! You just ran your first Ogre application!

Why did my application crash?

So you’ve managed to get your application to compile, but something is wrong, it crashes when you run it! Here’s a step-by-step process to help you through it:

1. Make sure your Working Directory (Project -> Properties -> Debugging -> Working Directory) is the same as your Output Directory (Properties -> General). This is a common cause of confusion, because without it set, Visual Studio cannot see any local files. This means it cannot find plugins.cfg or resources.cfg, so you might get resource or DLL not found errors.
2. Make sure the compiler is set to “Debug” (the drop-down next to the green compile button in the top bar)
3. The compiler will generate Debug and Release directories according to where and how your Output Directory (Project -> Properties -> General) is set (for example “.\bin\$(ConfigurationName)”). In your Debug folder you should have debug DLLs, and in the release folder you should have release DLLs. Debug DLLs commonly have the suffix _d at the end of the filename. Likewise, check that in your Debug configuration you are linking to Debug libraries with a _d suffix (Properties -> Linker -> Input -> Additional Dependencies).
4. Run the application through Visual Studio (by clicking the green “Start Debugging” icon in the toolbar). Don’t run it by clicking on the exe.
5. If something is wrong with your code, usually Visual Studio will point to the line that caused the crash. If this is the case, a yellow arrow pointing directly at the line means that it is that very line which caused the crash. If it is a green arrow, that means Visual Studio could only trace the crash up to that point, and the root of the crash is deeper.
6. Check your stack trace. This is in a box on the bottom right named “Call Stack”. This shows the last lines the application stepped through before a crash. (Sometimes people will ask for this if you need help with a crash)
7. Check the Ogre.log file for any abnormal messages like errors. This is generated in your application directory by default. Lines starting with OGRE_EXCEPTION are ones to look out for especially.
8. Do you have all the required DLLs? Ogre on it’s own requires OgreMain(_d).dll, but there may be other libraries that you are linking to which the application requires. For example, if you’re using any CG shaders, make sure you have cg.dll, AND load the Plugin_CgProgramManager(_d).dll. You may use CEGUI, which requires the following: CEGUIBase(_d).dll, CEGUIExpatParser(_d).dll, CEGUIFalagardWRBase(_d).dll and OgreGUIRenderer(_d).dll. If you’re using OIS for input, you’ll need OIS(_d).dll.
9. Search the Ogre forums, or Google, to see if anyone has had a similar problem.
10. Post your problem in the Ogre forums. We’re happy to help. :)

Other things to check:

• Are the contents of your plugins.cfg and resources.cfg correct? Make sure the paths are correct.
• Do you have any referenced but undeclared pointers? The compiler is blind to this problem. If you have not initialised the pointer, and try to reference it, the application will crash at runtime. See here.

I get errors when compiling!

error: SomeHeader.h: No such file or directory
The compiler cannot find the header file(s) you specified. If these are library headers that it cannot find, you need to tell Visual Studio where to find them. Go to: Project -> Properties -> C/C++ -> General -> Additional Include Directories and add the include directories where the headers can be found. (In Ogre’s case that would be C:\OgreSDK\include)

fatal error LNK1104: cannot open file “SomeLibrary.lib”
Similarly, Visual Studio cannot find the file you’re trying to link against. Go to: Project -> Properties -> Linker -> General -> Additional Library Directories and add the directory where the library can be found.

error LNK2001: unresolved external symbol
These are a pain for beginners, and they look daunting. What it means is that the compiler cannot find the implementation of a function (.cpp) that was specified in a header file (.h). Your application may build fine, but when the compiler starts to pull all of the application together (linking), it spits out those errors. Almost ALWAYS, this is to do with not linking a certain library. According to what the unresolved external errors are suggesting, is the library that you need to link to. e.g. if it’s a load of Ogre functions, that means you haven’t linked to OgreMain.lib. Go to Project -> Properties -> Linker -> Input -> Additional Dependencies and add it.

For the most part, we haven’t had much to show or talk about since the last post. We’ve been hard at work writing code since our change of plans with TidalEngine, which I’ll explain below. That said, there’s been plenty of interesting stuff going on recently, so here’s a roundup of what we’ve been up to since.

TidalEngine
TidalEngine is being developed alongside Project Utopia. We decided to transform it into a generic game engine that can be reused for other projects. It was a tough move, and has reduced development speed drastically. But hopefully the hard work will pay off.

We designed it to be extensible, using a modular and add-on architecture. It is multi-tiered depending on what you need. At the bottom level is the utilities – math, events, templates etc. which can be used for pretty much any application. Next is the core engine which abstracts graphics input, GUI, physics etc. Standalone it can be used to create a wide range of offline games. It uses a plugin system, allowing dependencies to be hot-swapped. For example, we have an OpenAL and FMOD plugin – either can be loaded at runtime. At the highest level is networking. This is where all the online operations will be handled.

Mobile Gaming
For a long time we have been carefully planning our pursuit of mobile development. Recently we started to put these plans into practice. We bought a brand new 24″ iMac especially for iPhone development. It will be a steep learning curve, as we’re PC junkies, but this is where most of our attention will be focused for the next few months. We plan on developing multiple titles, each increasingly challenging and complex. That’s about all we can say for now; we also put up a new page.

Websites
We have a number of clients in discussions for possible websites, and a couple more which we’re beavering away at. I’m pleased with the positive response we’ve received until now, so fingers crossed! We’re actively trying to expand our portfolio, so if you have a project in mind let us know!

TidalWare.com
Since my last blog post, I also took the opportunity to redesign our own website. It looked fine already, but until I’m 110% happy, I’m not happy. So back to the drawing board it was, and I came up with something even more minimalistic, and a better menu system to squeeze in our increasing number of pages.

Shortly after, I submitted it to CSS Design Yorkshire, and what do you know, it got featured! :D (There’s quite a few, so just search for ‘tidalware’ or ‘June 08, 2009′)

Conclusion
As you can tell, we’re always busy! If you want day-to-day updates of what we’re up to, be sure to follow us on Twitter. In the meantime I will try my best to blog more often. We removed the news page, so now every TidalWare news tidbit will be posted here.

I think it’s time we started filling this blog with interesting stuff like development updates, screenshots, ideas, and anything related to the projects we have under the hood. Namely TidalEngine and Project Utopia for the moment.

What better way to start than to post some screenshots? :) It’s screenshot-fever over here at TidalWare. We can’t stop taking them. Still, not much has changed on the graphics front since we implemented 3D ocean technology. But it’s always nice to tweak things and show the engine from a different perspective.

The avatar you see here is Mr. Roboto. He’s our crash test dummy for now. Since we have no real artists working on the project, it has to make do! It’s not easy for us programmers to make things look visually attractive, we are simply displaying the sheer power of our engine! Just imagine how things will look with real 3D art!

You may be wondering “what happened to night time?” – well, for a start it’s not easy to see a screenshot at night time. It’s also a cheat so we don’t reveal that the terrain doesn’t actually have dynamic lighting yet. We’ve put it off for now, since a new system is in the works by the Ogre Team. So right now, despite it being very advanced and capable of supporting an unlimited landscape, in the meantime the ground looks visually poor.

“Show us some video!”, I hear you screaming. We’re working on it! Us ourselves are desperate to pull together a video, but unfortunately there’s a few things we need to sort out first – bugs and the like. Dynamic light-mapping on the terrain is one thing, there’s also a couple of issues with the foliage and 3D ocean that you don’t see in the screenshots. Plus we really want to get our dynamic weather system spic and span. Trust me, it will be worth the wait. There’s 3D environmental sounds, the clouds move across the sky, the foliage waves in the wind, the 3D ocean has dynamic waves and caustics, all of which you don’t see in the screenshots.

There’s also a lot going on in the backend that you don’t see. The sky, the foliage, the water, the terrain, the objects, the avatar – it’s all being streamed live from one of our server applications. It’s just the sad reality that people tend to be more impressed with fancy graphics, so that’s what we tend to showcase. More details on the server architecture in a future post.

That’s it for this development post, hopefully it has cleared a few things up on the graphics front. We’ll try our best to roll out one of these posts on a regular basis, but don’t expect reems of new stuff to talk about. Some of the things we do are kept quiet for obvious reasons; and don’t forget the boring stuff nobody cares about. :)

At TidalWare, we have not spent a single penny on production tools. Not because we are cheapskates, but because we have no need to satisfy a corporate ego that leads companies into spending thousands, even hundreds of thousands on commercial tools. It is common for companies to think that quality = money. While this may be true in many cases, the amount of investment ploughed into fancy software could be better spent in other areas of the production process.

Today, the line between commercial and free in terms of software is narrowing drastically. The introduction of open source has lead to many quality projects being produced as a result of community effort. At the end of the day, it’s the consumer that will use the software. To have the consumer develop the very software that they use leads to productive and user-friendly tools. Even you can contribute to its development. Commercial software is developed behind closed doors, and its functionality stems from a company’s own priorities. You have little to no say as to what goes into the software, and you end up waiting for new, single large releases that you can only hope has the features you want.

The use of open source software in the commercial world has grown significantly in recent years as companies realise its benefits. However, even today the number of game development businesses large or small embracing open source technology is minimal. Most continue to reinvent the wheel, developing proprietary tools that often already exist. Today, with all the technology readily available there is no excuse for neglecting areas of your game due to time wasted on unnecessary development.

So, what tools are currently available that allow for free development? Well, below is a list of some of the free and commercial quality tools, software and libraries that we recommend for game development.

Tools

Compilers

We recommend:
Visual Studio Express – Visual Studio is the most widely used compiler for games development. It’s reliable, and has everything you need to compile your application, including unparalleled debugging and streamlined programming. While the commercial version offers more bang and titivation, Visual Studio Express has everything you need to compile and debug your game.
Code::Blocks – Our recommended choice for cross-platform development. It’s solid, has plenty of great features, is customizable, and can integrate with any number of compile types from MingGW to GCC.

3D Modelers

We recommend:
Blender 3D – Blender is fast approaching the standard of commercial tools, and studios are beginning to consider Blender as a serious option for art production.

2D Graphics

We recommend:
GIMP – The best free graphics package. An alternative to Adobe Photoshop.

Animation

CharacterFX
Pacemaker

C++ Libraries

Graphics

We recommend:
Ogre3D – In our eyes, the number one free graphics engine. Many commercial games have been produced with Ogre3D. It has an intuitive interface, workflow and a fantastic community with many child projects which are also open source.

Other:
Irrlicht
Crystal Space – Rendering engine used in Blender 3D.

Physics

We recommend:
ODE – ODE is an open source high performance physics engine for rigid body dynamics. We found it great for simulating vehicles.
Newton – Newton, while not being open source, is robust and has all the features you would ever need for physics in games.
Bullet – Reasonably new physics library with a rapid development speed. Used for physics in Blender 3D.
PhysX – Free for non-commercial use. This is a commercial-quality physics engine that is great if you don’t plan to sell your game. Requires a redistributable package.

Networking

We recommend:
RakNet – High level networking library with many out-of-the-box features for networking in games.
cURL – File transfer library.

Other:
ENet – A very lightweight UDP network library.
OpenTNL – Another high level network library.

Audio

We recommend:
OpenAL – Low level cross-platform audio featuring 3D sound and more.
Ogg Vorbis – A free quality audio filetype.

Input

We recommend:
OIS – A lightweight, cross-platform input library.
SDL – SDL is a heavy cross-platform input library.

GUI

We recommend:
CEGUI – A free graphics library providing a windowing and widgets API for in-game.
wxWidgets – A cross-platform GUI library for developing software. Create editors for your games without MFC.

Other

We recommend:
Boost – Hundreds of portable C++ source libraries.
TinyXML – A small but powerful XML library.

Game Republic is an organisation which develops, funds and promotes the Yorkshire games industry. They have recently launched a brand new website which contains news, blogs, events and more. For those of you involved in the games industry living in the Yorkshire region, or simply have an interest in game development, we recommend you sign up and take advantage of the many opportunities on offer.

Visit: http://www.gamerepublic.org/