Book Review: More Effective C++

A blast from the past More Effective C++ by Scott Meyers is not just another C++ book, but touches on a number of features and concepts that should be talked about far more than you get from most C++ books.

Some of the topics include: smart pointers, lazy evaluation, preventing resource leaks in constructors, preventing exceptions from leaving destructors, understanding the cost of exception handling, understanding the origin of temporary objects, understanding the cost of virtual functions, base classes and RTTI and more.

One part I especially liked was avoiding gratuitous default constructors. This is more of a design decision, but still a useful one, in that if member functions have to test if fields have truly been initialized it complicates the design and can lead to bugs and more complicated behaviour in handling these uninitialized classes.

Meyers talks about a number of design decisions, and side effects of going too far with overloading methods, or operator new or operator delete (and the numerous hacks and design decisions that have to be considered if you do decide to handle your own new and delete (i.e. don't do it)).

The chapter on exceptions was particularly intresting, and is probably my favorite description of exceptions:

The addition of exceptions to C++ changes things. Profoundly. Radically. Possibly uncomfortably. The use of raw, unadorned poniters, for example, becomes risky. Opportunities for resource leaks increase in number. It becomes more difficult to write constructors and destructors that behave the way we want them to. Special care must be taken to prevent program execution from abruptly halting. Executables and libraries typically increase in size and decrease in speed... so why mess with exceptions, especially if they are problematic as I say? The answer is simple: exceptions cannot be ignored (pg 44).

When thinking about exceptions in this way (as something that cannot be ignored), it is a great mindset for the programmer to consider what they really consider unignorable. This is quite a bit different than return codes, or status variables, which can be ignored, although at the risk of potentially undefined behaviour. Exceptions are best used when something exceptional happens. For performance reasons, it is best to limit the usage of exceptions whenever appropriate (and exceptional).

There are also some good practical advice, such as program in the future tense. Consider how the code will grow in the future, or how it will be used. Provide complete classes, even if some parts aren't currently used. Make the class easy to use, and hard to use incorrectly. Generalize the code whenever appropriate to maximize reuse. This is not to say design and program things you aren't going to need, but rather create logically complete classes (if something can be set, it probably should also have a get, and if an entry can be added, it probably needs a way to remove that entry too).

The book even though it is not hot off the presses, still offers quite a bit of useful insight into C++ and fills a role that few books really delve into. If corners of your C++ knowledge are growing some cobwebs, this is a useful book to help dust some of them off.

Cheers,
Michael Hubbard
http://michaelhubbard.ca

Book Review: Cross-Platform Development in C++

I decided to look into some more books on cross-platform work to see what more professionals were doing in this field. The book Cross-Platform Development in C++:Building Mac OS X, Linx and Windows Applications by Syd Logan, describes some of the techniques used in creating the Mozilla/Netscape browser to multiple platforms, and the challenges involved in creating such a massive project.

The basic theme of the book is abstraction, especially when dealing with low level implementation details, file I/O, threads, byte order, any platform specific code etc. Logan recommends creating factory classes that returns a concrete class implementation of an interface for these types of problems. The code should NOT be sprinkled with #if defines as it makes coding and debugging these things a nightmare as nearly every line could contain one or more #defines. Instead creating an abstract factory for returning the necessary factory and concrete implementation is essential.

In this book Logan share tips and workflow processes that allowed these projects to succeed on multiple platforms. These included having multiple experts on each of the platforms for handling, requiring developers to test on all three major platforms (Windows, Mac OS and the target flavour of Linux) before commiting to the code base. Logan also suggests another requirement is to compile with different compilers, pay attention to warnings and consider whether the native compilers for each operating system are the best approach (whichever compiler makes the most sense). One scheduling requirement was that all functionality worked on all platforms at the same time, this was essential to keeping everything working and preventing features from only being implemented on a given platform (which goes against the application being entirely cross-platform).

The book goes into quite a bit of detail on setting up Makefiles for each of the platforms using Imake and having a cross platform make system. It is also suggested to use a cross platform bug reporting system (Logan uses Bugzilla and Tinderbox since they are other Netscape/Mozilla projects). CVS is used (although Subversion is mentioned) but it is also a requirement to have cross platform tools (while also relying on Cygwin to emulate a lot of Linux tools on Windows).

There are other tips such as consider using the NSPR platform abstraction library (Netscape Portable Runtime Library), being wary of what standards floating point calculations are done, avoiding serialization of binary data (unlss you are using a convention for the data), using the limits.h for any size information (instead of using sizeof), etc.

One particularly good example in the book was related to the floating point representation:

float x = 4.0/5.0;
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}

The above example will print out "Different", since floating point expressions are evaluated to the greatest precision representation available (in this case double). The example below will print out "Same".

double x = 4.0/5.0;
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}

The book deals a lot with user interfaces as well (which are often a major issue with portability). Logan goes into some detail of the MVC (Model-View-Controller) paradigm, but also covers wxWidgets http://www.wxwidgets.org/, some of Netscape/Mozilla's XML-based GUI toolkit XUL https://developer.mozilla.org/En/XUL and his own open source project Trixul http://www.trixul.com/.

Trixul is an interesting project and some of the functionality of a browser (like embedded Javascript to interact with the DOM) are concepts that would be interesting to apply to a game engine, although perhaps in a slightly different way. Serializing in XML for the UI is incredibly valuable, although likely something that individuals will have to write themselves (see my post on XNA Serialization for this). Trixul allows C++ components to be written that can be accessed through a Javascript component manager to extend the functionality, within the SpiderMonkey Javascript engine. I won't go into too much detail about Trixul here, but if you are interested check out the links (and the book).

All in all, I think this book gives a great insight into the complexities of cross-platform development, especially in working in a large team. I still stand by my post about indie game developers should not initially target multiple platforms: http://gameprogrammertechnicalartist.blogspot.com/2011/08/indie-multi-platform-game-development.html as the amount of effort involved in making this work, the number of experts involved and the time it takes to get just three major platforms to work can be significant. If possible try to use tools that are platform independent, and see about abstracting all platform specific code, test on all systems as you write the code, and realize this is going to take some time.

Best of luck,
Michael Hubbard
http://michaelhubbard.ca

Coffee Break Hero 14 Day Sprint.

This is cool, a complete RPG in 14 days, with 24 hour live streaming a day, to raise money for Child's Play Charity: http://www.bigblockgames.com/games/coffeehero/challenge/

The live streams are at: http://www.twitch.tv/bigblockgames
More info on the charity is here: http://www.childsplaycharity.org/

Looks like this is shaping up quickly. They are only a few days in, but it will be interesting to see the end results.

This is a great idea for charity, and if you are reading this I'm sure they would also appreciate any donations for their game.

I look forward to seeing their end results, and hope they raise a lot.

Best of luck guys,
Michael Hubbard
http://michaelhubbard.ca

Book Review: Write Portable Code

There are not a lot of books on portable code, but Write Portable Code: An Introduction to Developing Software for Multiple Platforms by Brian Hook does a good job handling many of the topics.

There are a number of rules for portability:

- Never assume anything (memory, size of built in types (int, float etc.)).
- The code will likely have to have non-portable elements to run efficiently.
- Establish a reasonable baseline of platforms, (not both PS3 and Commodore 64).
- Never read or write structures from memory or cast raw bytes to a structure.
- Always convert to or from a canonical format when moving data in or out of memory.
- Develop good habits and use tools and platforms that cooperate to strong practices.
- Avoid new langages or library features.
- Integrate testing.
- Use compile time assertions and strict compilations (avoid excessive conditional compilations).
- Write straightforward code.
- Understand anything can change between compilers (floating point can work different).
- Leverage portable third party libraries, but be careful.
- Performance and resource usage must be as portable as your features.
- Portability also means supportin other cultures, regions and languages.
- Consider using a language more suited to the task (python, C#, etc. are easier than C++).
- Systems are becoming more secure (folders, ports etc.).

Brian Hook also has a POSH (Portable Open Source Harness) at http://hookatooka.com/poshlib/ that demonstrates some examples of portability and a good stepping stone for those looking at porting C++.

I think the book was useful it demonstrates a number of source code examples for his Simple Audio Library (SAL). Brian Hook also goes through a number of examples of the different standards including the IEEE 754, C8 and C99 standards, which are interesting to look at from a portability focus, and it would great if more books looked at the standards in their work.

Bye for now,
Michael Hubbard
http://michaelhubbard.ca

Indie multi-platform game development

Often indie developers get caught up in following the "big boys" and trying to do as they do. With a large company, there is a lot of focus on releasing on multiple platforms, in multiple languages, on their first release, and to create a big splash. My advice is: don't do it.

Focus on one platform, make the best possible game and go from there. If you are using a third party engine that already does that for you fine, but if you have to pay extra licenses, and do a lot of extra development, you could very well be wasting your time. If you do not make enough money on your (first) target platform to support moving your game onto another platform, your game will not likely be a success anyway.

Look at Angry Birds and Plants vs Zombies, two of the most successful smart phone games of all time. Both originally only coming out for limited platforms first (just iOS for Angry Birds, PC/Mac for PvZ). Neither of these companies tackled all the platforms that they are now running on, and are likely only ported to those platforms because of the success of the original.

It is worthwhile to focus on trying to write customizable code, and wrapper classes and functions for things that you know will could be or will be swapped out. Obvious things include the graphics API wrapper classes are essential if you need to support both OpenGL and DirectX or some other graphics API. It is also worth having a default functionality for things that could be a problem (like if a platform does not support pixel shading or a limited number of textures on the gpu, make sure your game does not rely on this too heavily).

If you really want your code to be portable, port early and port often. In a larger team I have seen it work where different developers run different operating systems and graphics cards in an attempt to guarantee that most of the functionality will work with a daily build. It is often easier to catch issues as they crop up, then to hunt for hours, days or weeks for all the differences that is not making it run on the other platforms. This introduces other workflow issues, and will sometimes require those developers that broke the build to access to other machines so they can fix it. This does help guarantee that the code written is more portable, and if it works for two very different architecture chance are more likely it will run on those inbetween. The problem for indie developers is they do not usually have this luxury of multiple machines, dedicated developers and perhaps this time.

If you believe that the market has shifted and you really should be focused on another device or platform, that is different, but chances are, your first assumptions about developing for that platform or device were well founded. If your game was not a real success on your ideal device or platform, chances are not very good you will see a huge difference in success if you spend the time to port to the other platforms. This can be frustrating, but instead, focus on improving your original game first, or making your next game even better. If you want to take a lesson from the console developers, consider this: if your game is really that good, people may even buy the platform to run it :P.

Best of luck,
Michael Hubbard
http://michaelhubbard.ca

Siggraph 2011 Part 3

It is over! I thought I would add some closing thoughts.

I managed to check out the Blender display (back in the far corner) and they had some cool stuff going, but could not help thinking that the Autodesk slogan "Don't blend in, stand out" may have some additional marketing subtext. I like Blender, and with their latest updates they are the best open source 3D modeling package out there, and while they are a few steps behind all Maya can offer, free is hard to beat when you are selling something. It was just a though, I still prefer Maya and really like Autodesk in general, but it was just a curious thought that passed my mind.

Otherwise, I think that Siggraph is a great pool of knowledge, but next time I go, I think I will try and spend the majority of my time in the talks, rather than the exhibition and galleries. I learned quite a bit, but I wouldn't say my mind was blown or anything like that. I felt like the exhibition and gallery were focused more on beginner to intermediate information, which is great when showing off a new technology, feature or process, but there is only so much detail you can go into in those kinds of demonstrations before you start losing people. The more formal presentations would likely not be as interested in attracting a crowd as exploring the depth of the ideas, and this, I think, would be very appealing.

Overall, I am very happy to have attended, and saw some neat things, learned some new technologies, and generally made me excited to work in this industry.

Can't really ask for more than that,
Michael Hubbard
http://michaelhubbard.ca

Siggraph 2011 Vancouver Part 2

So, I went to the exhibition and some of the galleries and ballrooms today. Losts of neat stuff. If I was to sum it all up, it would be Motion Capture, 3D printers, Autodesk, Maya and NVIDIA. Those seemed to be the major players, although not surprising since they are also some of the more expensive technologies, so would do well to advertise.

Some of the talks I went to include:

World Creation in CryEngine: I am awaiting for the release of the free version of CryEngine 3 SDK which will likely be this month (I checked and no mention of it on their webpage yet). The demo was ok, a bit simplistic in talking about the interface, but looks impressive nevertheless.

Photoshop 3D texture map integration: This was interesting talking about how 3D height maps can be created (and tested in 3D) in Adobe Photoshop CS 5.5. an intersting talk, with some good examples and neat features I will have to try out.

Real World Camera Rig Creation: The focus of this talk was to improve the use of a camera in Maya. This was a little different, the basic concepts here was to try and build a crane, dolly or curve path rig and attach a camera to it, to mimic real life cameras. By setting up and constraining the camera in this way, it allowed for more traditional movements alongside the free flowing camera that is so easy to misuse in a 3D animation or game.

Zbrush: Creation of Venom and Carnage from Spiderman. This was just very impressive to see how talented the artists were in creating these characters from a simple head (sculpted and painted in less than an hour) and with amazing results. Just seeing how some of the artists work give ideas for how to improve your own workflow, but really nothing but lots of practice can get you to that skill level.

Adobe Premiere Pro Integration: Shows how Premiere Pro can integrate with After Effects and Encore by sharing the same project information can allow all the programs to interact and update in sequence automatically. This will allow things like a project to be open in After Effects and have an effect added to it (like rain or snow) which will automatically update the same project in Premiere so it can be viewed and editted as necessary. This encourages experimentation, and allows for quick results to be seen immediately.

ILM Transformers 3 Colossus: The stats on the Colossus Transformers (the giant worm robot) in Transformers 3 were very impressive. Over 16 million polygons, 13 separate pieces and was the equivalent to 2 and a half Devestators (from the previous movie). It took a machine with 12 cores and 48 gigs of RAM over 40 minutes to load the shot where Colossus is tearing apart the building, which has multiple layers of complexity and physics (with skin based building model) to get the shot of the building falling over.

Nvidia Parallel NSight: http://developer.nvidia.com/nvidia-parallel-nsight is a very impressive tool integration for Visual Studio, that breaks apart the scene into different draw calls and gives a lot of previously difficult information about the rendering process back to the developer. A tool that allows a developer to select a pixel onscreen and not only track it, but see what draw calls have gone into its creation is amazing. I will definitely be spending some time further investigating this tool, and since it is free, I recommend everyone interested in 3D graphics programming to check it out, it looks like it will be a new favorite to many developers.

Siggraph Dailies: This was a one-minute segment of many different studios, backgrounds and styles. It was nice to see only a brief but intersting clip and a short (sometimes only a few sentences) of the challenges in getting that shot, techniques used, or ideas behind the shot. Ovearll, there are (as expected) a lot of cheats that go into a shot to get the desired effect. One interesting technique used in Tangled (from Disney) was running simulations on the hair in reverse than running the frames backward.

Lots of fun, the exhibition was pretty neat, the art was interesting, the technology was cool and I learned some neat stuff.

Hope you also made it there,
Michael Hubbard
http://michaelhubbard.ca



http://www.3dtotal.com/siggraph_diaries/exhibitor_golaem.html