Last weekend I participated in the first edition of Slavic Game Jam. This year’s theme was “Just do it” (© Shia LaBeouf). I found a great team and we created a game called “CALL OF DO IT”. It’s a 3D drone operator simulator, created with Godot Engine.

I think that the final result is quite nice, especially regarding the visuals and audio. You can check out the intro/gameplay video on Youtube:

Downloads:

	Windows
	OSX
	Linux 64b
	Linux 32b

Project info & keys (Polish only, but you’ll get it ;))

So let’s talk about photography first. In a digital world, to capture a photo you need to store light reaching the camera’s sensor. You open the shutter (a mechanical element blocking the light), record light for a specific amount of time (eg. 1/2000 s), close the shutter – all done. Recording a movie is not really much different – only that the exposure time is constant (1/fps, eg. 1/24 s) and no shutter movement is required.

So, let’s take a look at a photo captured using “cinematic” settings (1/24 s):

As you can see, it is very, very blurry (regarding the moving parts)! And this is exactly what you see when you pause a movie. So, would “60fps” picture be sharp? Let’s see…

While it is sharper than 1/24 s picture, there is still a significant amount of motion blur. Of course the faster an objects moves, the more blurry it will appear in a picture – and depending on the speed there is an exposure time that would freeze the motion completely.

But, in reality, this actually can be good for watching animated content (movies, games, etc). Because let’s take a look at the alternative:

While this was not captured with infinite speed (1/800 s actually), it was enough to freeze the motion. While is is certainly sharper when looking at, this doesn’t provide visual clues about the motion. Does the car move or is parked? How fast does it move? From a single picture we simply can’t tell!

Also, this is much closer to hardware rendering that consoles and PCs use for games. With classic polygonal rendering you always render a single point in time. Yes, you can apply different kinds of motion blur (camera blur, vector blur, skinning based vector blur etc) later in the post-processing, but these are approximation methods that don’t always capture the 100% correct motion.

So, in theory the best experience would be gained with a movie (game) with FPS as high as possible, with correct motion blur applied. Of course the higher the FPS, the less visible the motion blur would be (except for really high velocities).

But there are also two other important factors to consider:

Input lag. While it’s not necessarily related to a specific FPS counter, it often is. Input lag measured how long does it take between you press a key or button and a relevant action is applied on screen. This is actually more complex than you might think, because of numerous steps in between (capturing input, processing input, processing game world/physics update, queueing and finally updating display buffer). In theory, a game with 30 fps visuals (and some motion blur perhaps?), 240 fps physics and immediate input processing could be perceived as smoother than a 60 fps game with 60 fps physics and 2-3 frame delayed input processing.

Time for processing a single frame. This actually applies to both gaming and photography. In the latter the shorter the exposure is, the higher sensitivity you must set on the sensor and as a result, get a noisier picture. In gaming you have less and less time as the FPS gets higher, and this is not an excuse from a lousy developer – doing everything in mere 16 ms (for 60 fps games) is a real challenge, especially if the game world conditions can rapidly change.

Finally, I’ve created a simple animation to demonstrate low FPS with motion blur vs high FPS without motion blur to give a better understanding of the whole “cinematic experience” thing. I’ve made a super simple Blender animation with 240 fps, rendered 2.5 s (600 frames) of it and then:

30 fps with motion blur (average 8 frames to create motion blur):

60 fps without motion blur (take every 4th frame):

This is of course a little different setup than car photos before (car is almost stable, the road changes), but you can see that correctly motion-blurred 30 fps can be actually easier to watch.

Also, two “corner cases”: really bad example (which probably causes this whole PC vs console, 60 vs 30 fps war), 30 fps with no blur:

And the “holy grail” (on 60 fps display, which is usually the case) which is 60 fps motion blurred version:

So, now you are properly equipped to fight 30 fps battles. Have fun with gaming on your favorite platform! :)

So, here you go: https://github.com/dabroz/csgjs-cpp

Single file, no dependencies outside STL. It’s able to do basic CSG operations, not super fast, no mesh optimization but only 0.5 KLOC which can be easily made into <0.2 KLOC by removing comments and replacing conversions with engine-specific data. MIT licence, as the original library.

So I’ve created a tool to help calculate required capabilities. You can grab it here: http://28byteslater.com/ios-compatibility/

Notes:

• I’ve been monitoring performance statistics for my first game Taste My Steel!
• currently it’s available on iOS devices and so are the stats
• this is a 2D game, OpenGL ES 2.0 with trivial shader
• uses texture atlas (game uses 2 physical textures + 1 additional for GUI) and client-side vertex buffer (not too many vertices)
• so, GPU side fillrate limited
• uses native resolution everywhere (so it doesn’t compare raw performance)
• works flawlessly on most devices, except for first iPad (HUGE leap between iPad 1 and iPad 2) and 4th generation iPhone/iPod touch (first devices with Retina resolution, 4x pixels but with the same GPU)
• soon I’ll have stats for another game (this time 3D)
• and for some Android devices (a.k.a. sea of madness)
• we use different texture sizes for each device. Base resolution for HDPI/Retina tablets, half for Retina phones/regular tablets and 1/4 for low-end devices like pre-Retina iPhones.

I’ve started my own company Rockhard. I’m going to create some fun games and at the same time turn some of the awesome technology I’ve build over the years into production-grade products. Having done that I’ll swiftly switch onto a cold fusion and rocket engines. Stay tuned!

I’ve also released my first game Taste My Steel! Not exactly a multi-platform AAA game one could expect, but I’ve learned many hard lessons on the way anyway. And apart from giving me countless topics to rant on this is also a really fun game which you’d have to be a grumpy cat not to like. Seriously!

And last but not least, I’ve changed this blog’s title and address. dabroz.scythe.pl had little semantic value given that scythe.pl never made it out. So now we are 28 bytes later. See semantics now?

Few examples: iteration time. With small and simple C++ codebase usage you can cut compilation, link and startup time to few seconds, and you need to switch between your game/app and IDE. With more dynamic languages you certainly can do better. Some languages like Lua (and, FWIW, Dab) allow easy hotswapping. I have a nice prototyping environment for Lua code – I have a game running on one screen, debugging info on another and the code itself (nothing fancy – Notepad++) on the third one. I trace changes in game source using WinAPI and simple Ctrl+S lets me to view my changes immediately (non-compiling code is rejected). This allows me to have like 3 iterations per second and when doing some finetuning every iteration counts. And I believe that I’d still be able to do better (like using some dedicated Lua editor). Code hotswapping in C++ is nontrivial and even with sophisticated framework with DLL swapping you probably won’t beat 0.3 IPS due to build time.

Another issue: language features. There is a lot that is easily doable with Lua and close to impossible for C++. While C++0x is picking up, most dynamic languages have had stuff like closures since always. You can have table proxies (have array of 20 enemies to update? update the array!) or functional programming stuff (map/reduce/filter etc -> beat enemies.max("x") with C++!). This do matter if your app have an expected lifespan of a mayfly.

Of course most of this stuff isn’t very helpful for large projects. With 400KLOC project, weak linking alone will make you cry and run for your life. But with 400LOC project it’s just cool. I would even love to quietly call nils like Obj-C for that matter, but I guess you shouldn’t be greedy.

If you’re experienced enough you’ll probably be able to code small project in C++ (or any other language) in few hours – not because you use C++, but because it’s a small project and you are experienced. If you weren’t, you’d probably spend 3 hours to fix linker errors alone. And don’t be afraid to try out new stuff – especially if it’s a short home project. For example, until recently I didn’t know I love Ruby as a shell scripting language – but I’ve tried it and won’t look back.

TL;DR: if you say you can code fast small game in C++, try Lua and keep it real!

It is worth noting that this site started as a ordinary WordPress blog, that was later switched to hand-made C# app. Well, C# is quite a cool language (and not only for web, I’ve prototyped a lot of games with it!). Way more sane than PHP and/or WordPress itself. But, sadly, finding a reasonable .NET web hosting for a page my size is tricky at best. I wasn’t very happy with my hosting company and when my account expired I thought it would be a good moment to have some fun.

So, we’re back with WordPress. I’m still not a fan, but I managed to do some stuff on Lvx website with it, so I gave it another chance. I made a new theme and decided to do some crazy WebGL. And with ThreeJS framework it’s actually quite fun! And there has been a long time since I’ve coded nice 3D stuff.

Now I would like to write a little bit about my recent and distant projects and update some infos. Hope it won’t take me another 6 months to do so. There is a LOT of stuff to cover.

And, last but not least, I would love some feedback about new site/theme.

Bye old blog. Hello new blog.

Console opened at 02:58:46 09-Dec-11
        GL_CLAMP_VERTEX_COLOR_ARB is clamped.
        GL_CLAMP_FRAGMENT_COLOR_ARB is clamped.
        There are 0 constants bound by this program.
        Texture 0 uses an 32 bit floating point format.
        Texture 0 is bound to texture target GL_TEXTURE_2D.

If you are wondering what is it, it seems that recent NVidia drivers added this feature if you enable debug flag in your OpenGL 3+ context. Also, debug output quality seems to be improving:

OpenGL message 131218: Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches. [source: API] [type: performance] [severity: medium]

It’s nowhere near DirectX debugging tools, but hey, that’s still better than 4-color LED.

Few weeks passed since first release of Dab. I’ve been working on the codebase, refactoring a lot of code and adding static compilation (i.e. creating executable files). And finally I can introduce to you first standalone game written in Dab.

JIT Shooter is a project that I was using to create first usable version of Dab. And now you can download its .exe binary that doesn’t need Dab IDE.

Download JIT Shooter Standalone

However there are few issues:

• you need OpenGL 3.2+ (to save additional functions calls shaders use explicit attrib locations)
• you need MS C runtime 7.1 (you can get it here, game uses few functions like fopen/fread)
• game uses STB image to load textures, those are compiled as DLL

But still, there is massive work ahead. I’ve removed few hacks just to add different hacks. However, next version (0.3) will feature proper handling of function pointers and few other modifications that will allow to reduce number of hard-coded tricks. Version 0.2 should happen in next few days.

BTW: I’m very happy with executable size. 39KB for playable native game is really not much. And with better loader (now all CRT/OpenGL calls are resolved in runtime very naively) it can be even smaller.

Other news: I’ve set up this blog as I’m not very happy with existing Dokuwiki site. I’ll probably experiment with wordpress wiki plugins instead.

I’ve also created Dab Google+ profile. Feel free to like+1!

In late ’70, there was a computer called TRS-80 (from Wikipedia):

Level I Basic was based on Li-Chen Wang’s free Tiny BASIC, additional functions added by Radio Shack.[8] It achieved a measure of noteworthiness due in large part to its outstanding manual,[5] written by David Lien, which presented lessons on programming with text and humorous graphics, making the subjects very easy to understand. It had only two string variables (A$ and B$), 26 numeric variables (A – Z) and one array, A(). Code for functions like SIN(), COS() and TAN() was not included in ROM but printed at the end of the book. The only error messages were: “WHAT?” for syntax errors, “HOW?” for arithmetic errors such as division by zero, and “SORRY” for out of memory errors.

Rings a bell?

Now, results are somewhat shocking. Much more people participate in short compos than the long ones. But the best part is that quality of games created is just the same, no matter if the games was made in 2 hours or 4 weeks. Why?

1. Well, creating game in 4 weeks doesn’t usually mean neither 672 nor 224 working hours. In extreme cases 4 week compo is just a 2-hours compo, with 2 hours located at the very end of 4 weeks.
2. A lot of game value is an idea. Fact: you won’t come up with better idea in 4 weeks than in 10 minutes.
3. Development process for 2-hours game is very dense. And most of the time is spent on improving core features (because there are no others).
4. On the other hand, in long-term projects people start to focus on insignificant features. The moment you start improving abstract communication between task pools, adding GUI widgets so that you can make a built-in MP3 player or making splash screen data-oriented, your project is screwed to hell.

And this is probably the most important lesson to remember. If you need to do something very quick, code will be horrific, but also short, simple and fixable. With no time constraints, code will get new levels of complication, features and bugs. Time spent on maintaining won’t justify the result.

In 4 weeks, you can make several iterations of speed-coding, each time improving core features of the game. If you start with future proofness in mind, writing code and fixing bugs will consume most of the time. Sure, in 4 weeks you can make a ton of assets/levels, but how good are they is core gameplay is not good enough?

Finally, one solid C(++) tip: when adding new features, start with the smallest of available guns:

1. Global function — if you need to display score, don’t hesitate to add void DisplayScore() somewhere. If your game is single-player, store score as a global variable. See? You have just saved 10 minutes of writing getters, setters and designing communication between modules. If your game is multi-player then you will need to store and display scores per-player. But there is no reason to be able to display arbitrary score of arbitrary player if your game is not yet multiplayer. Believe me, you’ll have bigger problems than displaying score with that.
2. If your functions share common code or require helper functions, group them somewhere, possibly in separate file. Remember about static functions and variables — contrary to “OO” static, file static is about visibility. But it’s cool, because you can have a file for all font-related operations and store internal data in static global variable. Helper functions can be static, and public ones go to one shared header (if you write simple code, compilation time is never your enemy).
3. Promote functions to classes only when it’s relevant and useful. Remember, classes means objects, objects mean relations and relations means complexity. Is your gameplay so cool that you have time for code complexity?
4. Any design patterns or other exotic stuff is the last resort if none of above is good enough. Personally? Never got there.

(from #altdevblogaday)

We have a String class. It is a reference-counted, immutable string. Typical data structures in C++ would look like:

struct string
{
  string_data * data;
};
 

struct string_data
{
  int refcount;
  int length;
  char * data;

};

So, string is merely a reference to actual string_data. Creating new string objects (string foo = "hello world") looks like:

1. string_constructor(const char *)
2. allocate string_data
3. string_data_constructor(const char *)
4. allocate char[]
5. copy data, set all other members

In memory, it would actually look like:

So, we have one stack allocation, two dynamic allocations and our data is in three different places in memory. But in C++ terms it seems impossible to improve it. However, we can go C way and change string_data definition:

struct string_data
{
  int refcount;
  int length;

  char data[1];
};

Array of one character? I must be crazy, right?

Most C++ courses are not very precise about pointers and arrays. Especially, what is the difference of following instructions?

const char * string1 = "hello world";

const char string2[] = "hello, C++!";

And what is the difference of those?

int foo(const char *) { printf("*\n"); }

int foo(const char[]) { printf("[]\n"); }

Unfortunately, in C++ world where really various things can be static, answers are different. In first case, string1 and string2 are something else. In second case, there is no difference — actually, that code won’t compile due to non-unique overload.

Maybe little investigation? Let’s print some data:

printf("%p %p %s\n", string1, &string1, string1);
printf("%p %p %s\n", string2, &string2, string2);

What we do is printing expression as a pointer, address of this expression as a second pointer and null-terminated string pointed by expression. Results:

0x08048650 0xbfddbfa4 hello world
0xbfddbf98 0xbfddbf98 hello, C++!

Now you see magic behind it. 0xbf…… are stack addresses while 0×08048650 comes from somewhere else (likely from static, read-only data section). So, while pointer types hold address inside, arrays points to themselves. And we can abuse it!

“Typical” C++ allocation of string_data would look like this:

string_data * foo = new string_data;

It would allocate sizeof(string_data) bytes (9 + padding, probably 12). But in fact, we can allocate as much as we want! For example:

string_data * q = (string_data*)malloc(2 * sizeof(int) + 12);

new (q) string_data;

In this case — 2 ints and 12 bytes of string data. After successful allocation we need to manually invoke constructor, using placement new. Similarly, regular delete q won’t work — following code will:

q->~string_data();
free(q);

Of course if data type is simple (built-in datatypes, relaxed POD, whatever) there is no need to call constructor and destructor (although those calls probably would be simply optimized away). And malloc/free can be replaced with custom allocation routines.

And after such allocation, we can use data like it was not a char[1] array but rather a char[as much as we have allocated] array! How does memory look like with this data structure?

And there are numerous benefits of such approach:

• one dynamic allocation less
• data is less scattered in memory
• we saved some memory (how much? size of the pointer + size of allocation metadata)

In the next part, I’ll show how we can save even more allocations/memory.

(from #altdevblogaday)

Typical output:

[23:12:26] CPU : 8 x 2806 (2806) MHz (Intel(R) Core(TM) i7 CPU         930  @ 2.80GHz, FPU MMX SSE SSE2 SSE3 SSSE3 EST SSE4.1 SSE4.2 POPCNT HTT)
[23:12:26] RAM : 7956MB/12278MB
[23:12:26] GPU : NVIDIA GeForce GTX 460 [8.17.12.6658, 1-7-2011] :: NVIDIA Corporation GeForce GTX 460/PCI/SSE2 using OpenGL 4.1.0
[23:12:26] OS  : Windows 7 (6.1 Service Pack 1) 64 bit

Many folks complain on Windows API, it’s backwards compatiblity and overall misery. But while working on sysinfo program, I’ve actually learned how powerful it is. Few examples:

Memory

On Windows there is GlobalMemoryStatusEx function that returns accurate results, in 64-bit format even for 32-bit applications.

On Linux there is /proc/meminfo but its results are very hard to interpret and are different than results of free command. In the end, I’ve used free -mo | head -n 2 | tail -n 1. Pure magic (and pure hope that free output format won’t change).

Mac OSX amused me. As you may or may not know, I’m an iOS developer. I thought that Mac will be quite similar to its iOS counterpart, maybe with API like [[NSSystem sharedSystem] freeMemory]. Hell no! To obtain memory statistics, you need to access Mach (Mac OSX kernel) layer, like this:

mach_port_t host_port;
mach_msg_type_number_t host_size = sizeof(vm_statistics_data_t) / sizeof(integer_t);
vm_size_t pagesize;
vm_statistics_data_t vm_stat;

host_port = mach_host_self();
host_page_size(host_port, &pagesize);        
   
if (host_statistics(host_port, HOST_VM_INFO, (host_info_t)&vm_stat, &host_size) != KERN_SUCCESS) return;

natural_t mem_used = (vm_stat.active_count + vm_stat.inactive_count + vm_stat.wire_count) * pagesize;
mem_free = vm_stat.free_count * pagesize;
mem_total = mem_used + mem_free;
    
mem_free /= 1024 * 1024;
mem_total /= 1024 * 1024;

GPU

On all platforms I query OpenGL for vendor, renderer and both (OGL and GLSL) version strings. But this doesn’t include driver information. And each vendor/platform has his own vision of those strings.

So, on Windows I use SetupAPI to obtain precise GPU information. With SetupDiEnumDeviceInfo I search for FILE_DEVICE_VIDEO devices. This is useful, because it allows to check multi-GPU configurations or to bypass additional layers of (OpenGL) emulation (like for example screen capturing applications). And with SetupAPI there is standarized driver information available.

But on Linux it’s not so easy. I have no Linux-specific programming knowledge (not that I’ve used SetupAPI before). I didn’t even search for kernel API for this. I’ve just used lspci command and searched for VGA compatible controller. For NVIDIA cards I’ve found that I can obtain driver info from /proc/driver/nvidia/version. For ATI or other vendors — I have no idea. Fortunately, ATI seems to include driver information in OpenGL version string (like 3.3.10237 Compatibility Profile Context) so this should not be a problem. But if you know better solution, please let me know.

On Mac OSX I didn’t even try. In fact you can’t install or update GPU drivers on Mac, because those are not provided by NVIDIA or other IHV, but by Great Apple itself — and that also means that OpenGL stopped at 2.1 version. Hate you, Apple. There is a magic number in OpenGL version string: 2.1 NVIDIA-1.6.26 but I have no idea how could I compare this to Windows/Linux driver version.

Conclusions

There is other data as well, but as complex as examples above. For example to obtain OS data there is GetVersionEx and GetNativeSystemInfo in WinAPI (Native flavour returns 64-bit information for 32-bit apps on 64-bit Windows). On Linux/OSX I just use uname -a (Mac OSX have no variations, and on Linux it would be hard because each distribution has its own vision of versioning). CPU was fortunately mostly cross-platform, because I focus on __cpuid data (BTW — do you know how to obtain HTT and/or number of cores from __cpuid?).

So my verdict is: Windows rocks, other platforms are pure chaos. At least in grabbing system information. But really, WinAPI may be awkward or "too backward compatible" but at least is simple and powerful.

BTW, if you want to test sysinfo program on your PC, you can grab Windows,
Linux or
Mac OSX version and share results in comments. This is not the most recent version but results would be helpful.