iOS 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.
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?
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!
Wow, I haven’t posted anything here since last year. Really, shame on me. And sure, posting meta entries just to keep blog alive is not the best way to go, but I have few technical rants as well.
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.
Today I run my game and was very surprised about mysterious window:
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.