Recently I needed to call a function in the background of a C++ program periodically. I decided to use the STL for the task.
During research, I found a nice article about periodic processing with C++11. The sample code has helped me to quickly put together a solution for my project. However, I noticed that the author was showing average wakeup errors of 20 microseconds on Windows and 96 microseconds on Linux. Running the sample code on macOS yielded errors of up to 2000 microseconds! That is a big margin. I was a little disappointed. My favorite OS is getting worse results… oh no.
But then I remembered that newer versions of macOS employ “timer coalescing“, which tries to save energy by reducing timer accuracy and “bundling” wakeups together to let the CPU sleep for longer periods of time.
Nice, but thankfuly we can turn it off for more accurate testing:
sudo sysctl -w kern.timer.coalescing_enabled=0
After that the errors went down to about 40 microseconds on average. I have yet to look up the proper way to tell the OS that my app needs this, regardless of the global setting, but my curiosity is satisfied for now.
Note: the source code from the article is only provided as a PDF from which it is hard to extract in a usable form, so I took the liberty to make a plain-text copy on Github.
simple clean code that works according to the current requirements
“flexible” over-engineered code that does the same thing as (1) only in a more complicated way and has not yet turned into (3).
a total mess
Flexibility almost always means adding complexity. Complex code is harder to reason about, harder to change, harder to optimize.
The goal should be to write clean code that separates logical components of the program. Well-structured, non-repeating and easy to understand code is the best you can do.
Any attempt to make a prediction of the future and somehow make the code “ready” for it makes it worse. You don’t know the future requirements.
If you do, then what you write is not really flexible code, it’s just written according to the spec, version 2.0.
There may be a requirement for a plug-in architecture of some components. For example, you may want to have an easy way to add new types of enemies, weapons, special effects or even game modes. This needs to be part of the specification. Code that enables such things should still do so in the most simple way possible.
As I’ve been working on Devastro 2 I thought it would be great to be able to see and adjust properties of the in-game entities in the level editor.
Properties can be generic ones such as position, angle or color but there can also be ones specific only to certain types of objects – for example a “crate” object can have a (bool) property that defines if a pickup item should appear when the crate is broken. An enemy ship can have a property that defines how much damage it can take.
But how does the game know what types of objects have what properties? I guess we’ll need some kind of system for that.
A property system is a way to inspect and modify the properties of objects at runtime.
Implementing this is quite easy to do in languages such as Java or C# because reflection (aka introspection) is part of their runtimes. Also, custom annotations can be used to further describe how we want the properties to be published. But being the stubborn person I am, I’m writing this game in C++, so… how hard could it be? Maximum effort…
Serialization – read/write properties to a file when saving and loading levels
Editing – interactively adjust properties using sliders, checkboxes etc in a GUI.
Debugging – inspect objects at runtime
We need to:
Get a list of properties for each class in the game
For each property, get its type, name and additional info for editing & serialization purposes
For a given object instance, get/set the value of each property
I defined several constraints for the system:
No custom preprocessing steps (looking at you, Qt)
Don’t use C++ RTTI
Non-invasive – objects don’t need to register or add getters/setters; this is hard to avoid completely but currently there’s only 1 line of boilerplate declaration to be added to each class
No runtime overhead for objects with properties (allow direct access to values when type is known)
Simple setup (all properties for all objects defined in single location, DRY for subclasses)
And some compromises:
OK to do string lookups but only when editing/loading, not in main game loop
Limited set of property types (int/float/bool/string/enum)
Limited amount of validation (can set a property to any value, object must deal with it; a value range can be defined as a hint for editor UI but is not enforced internally)
As of now the property system is up and running. Phew! I went through several iterations before settling on a design and it took a lot of effort to flesh it out for all the use cases and integrate it into the game.
Bottom line: Interesting challenge; looking forward to using Jai.
I took two screenshots from the scene as the camera moves in towards the house.
I decided to do all my modeling based on those. I started by adding two cameras and attaching a screenshot to each of them using Blender’s “image empty” object.
Matching the camera views and the model to both screenshots at the same time was quite difficult. Matching the lighting was even harder since it’s a night scene with lightning effects.
Reference shot #1 for comparison:
Subtle shadow mismatches show that my model isn’t 100% accurate, especially when it comes to depth. But let’s be honest, this is Ed Wood we’re talking about, so they probably had the lighting all wrong.
If I could devote any more time to this project I would probably model the terrain around the house a bit, add some trees, grass and dynamic lighting to match the movie scene. Also the texturing is pretty basic and not very accurate – another pass with manually painted details and wear & tear would be nice. Next time!
iOS 10.3 (currently in beta) converts the filesystem to APFS. This happens transparently during the update and without changing any data or installed apps. Impressive.
But the APFS in-place conversion probably isn’t happening on iPhone 5 devices at all. I have an old iPhone 5 and was curious to see if there was a way to check for that programmatically. One of the features advertised for APFS was higher resolution for file timestamps. So I wrote a little test app and ran it on different devices. It quickly creates a series of files and compares their “modified” timestamps. It seems like the time resolution for iPhone 5 running iOS 10.3 beta is still 1 second, which would suggest it’s still using HFS. Link to the app: https://github.com/catnapgames/TestIOSAPFSCheck. If you have Xcode installed on your Mac you can build and run it yourself – developer account is no longer required for running apps on your own device.
it’s easier to #include <sys/mount.h>, call statfs and check the f_fstypename of the struct statfs result: it will be hfs or apfs.
it is “hfs” on the iPhone 5 with 10.3 release
it is “apfs” on an iPad Mini4 with 10.3 release
Thanks to @jakepetroules for the tip. No APFS on iPhone 5 = 2x confirmed.
Here’s a 3D rendering of a scene from Superforce, made with Blender. If I ever release another update (or sequel) to Superforce, I might get back to this, add some explosions & other SFX and use it as a proper cover image.
And here’s a quick animation. It’s just a concept so the 3D scene doesn’t match the screenshot but I see some potential for this kind of presentation.