Pol Jeremias

New material developed at USC! These are some screenshots from our finale project for the Game Engine Development class.

The idea for this project was simple, build an editor (GGE Live Editor) for an existing engine written in C++. As it is well known, the user interface written for this language is not the best one. After testing some open source frameworks such as wxWidgets or QT we quickly decided that C# and the windows framework was the perfect choice. This decision brought us a new challenge, how do we communicate both applications. One option was to write a wrapper around the engine in C++ so that we could fully access the engine’s features from C#. The second approach was to embed the C++ application into a C# control and communicate both applications using sockets. Since we just had around 12 weeks to develop, test and publish the editor, we decided that the second technique was more suitable for our requirements.

The approach worked really well and we had the first prototype working in just one week, it is quite straightforward to implement and the results are impressive. Of course, we had some problems, basically related with the synchronization but nothing important.

This is the list of basic features implemented in the editor:

• Create, edit, and delete entities, scene nodes, lights…
• Viewer: static meshes, animated meshes, particle systems
• Edit and save scenes with different screens
• Different cameras (top, side, front, perspective)
• Grids, picking, maya controls…
• Scene manager and properties editor.
• Edit and execute the game inside the editor with different controls (edit or game controls)
• And much more!

The following gallery shows the final aspect of the editor:

Why is so hard to follow coding guidelines?

Have you ever thought about that? How many times have you found code that, either doesn’t follow any rule or, simply, there is no rule for that case? So far, I have been working for different companies and, I have found these kind of problems. There could be different reasons, incomplete coding guidelines, misunderstood guidelines…

This week I have found this interesting article written by Nathan Myers (he has participated in the ISO/ANSI C++ Standard committee since 1993). He explains several cases that are not usually handled by all the style guidelines out there.

C++ Style Guidelines - A coding standard for C++ software developers and maintainers.

Good luck !

Have you ever been confused about the different strings types?

Today, I’ve had some free time and I have been researching and gathering information. The result is this cheat sheet with information about some (all of them would be crazy) well-known string types.

C Language

• char* : This should be null terminated. You can use encoding such as UTF-8 but generally each byte corresponds to one characters.
• wchar_t* : Basic Unicode string type null terminated. Generally it indicates UCS2 encoding.
• TCHAR* : A null terminated array, contains wchar_t if UNICODE is defined, otherwise uses chars.
• LPSTR : Win32 typedef for char*.
• LPWSTR : Win32 typedef for wchar_t*.
• LPTSTR : Win32 typedef for TCHAR*.
• LPCSTR, LPCWSTR, LPCTSTR : Const versions.

C++ Language

• std::basic_string<T> : The native C++ type. This is just a template.
  • std::string : Class that contains an array of bytes. It assumes that you’re looking at ANSI here without any encoding.
  • std::wstring : Contains an array of wchar_t. UCS2 encoding is assumed.

Managed C++

• System::String^ : I know this is not C++ but If you’re working with Managed C++ (I do), you can use this UTF-16 string.