“Cinematic” 30 fps explained

There is an ongoing debate on console vs PC, 30 vs 60 fps gaming experience. While there is a little doubt about what feels better, there is also a lot of misunderstanding about the actual rendering methods and the “cinematic” experience that 30 fps is supposed to provide (but doesn’t).

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): Continue reading

Simple CSG library for C++

csgI needed CSG operations for my engine. Having no interest in writing one, I started to look for existing solutions. However, I found virtually no CSG library for C++ that was both licence-compatible (LGPL sucks for mobile dev, GPL just sucks for anything not OS size) and reasonable in size. I love stb_-style single file libraries, but I can accept small solutions that I can just copy into my project workspace. Sadly, most CSG libraries I found were behemoths of several megabytes of code each. I’m not even trying to imagine what can they do besides the obvious. However, I found one neat solution: http://evanw.github.io/csg.js/ which only downside was the language choice. Javascript is not really friends with C++, but anyway I found csg.js quite easy to port to C++ as no weird JS features were used.

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.

iOS compatibility calculator

iosc-thumbiOS offers (via UIRequiredDeviceCapabilities) possibility to require specific device capabilities, like GPS or camera. Unfortunately it doesn’t allow to select devices manually. For most applications this is not a problem, but there are apps like games that require specific performance level. And performance varies on different iOS devices. So in order to exclude some devices you need to provide more device feature requirements. Similar or maybe even worse situation is on Mac App Store.

 

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

Relative iPhone/iPad performance (update)

ios-performance

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.

28 bytes later…

Many things happened recently.

lmvkwg_256_r

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!

 

ruagrk_256_r

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?

Fast coding with C++?

My friend Adam Sawicki posted an interesting blog post recently: C++ is Good for Fast Coding with which I couldn’t disagree more. While certainly you can do fast coding in C++ (especially being an experienced developer) there is just so much more in the world.

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!