Sunday, August 28, 2011
See you there!
PS: this blog and all its posts will stay here as an archive.
Monday, July 11, 2011
Monday, June 27, 2011
- The single-threaded method does everything on the main thread and is just for reference.
- The GCD method uses a display link on the main thread to kick off the rendering on a serial GCD queue that runs on another thread. Display link events may get dropped if the main thread is busy.
- The threaded method uses a display link on a separate thread that kicks off the rendering on the same thread. Display link events may get dropped when the rendering takes too long.
- The threaded GCD method combines the GCD and threaded methods. It runs a display link on a separate thread and kicks off the rendering into a serial GCD queue that runs on yet another thread. It is completely decoupled from the main thread, and the rendering doesn't block the display link either. Hence, the display link should be very reliable.
- Run the game update and the rendering in parallel. This requires double buffering of the game data, either by flip-flopping, or by copying the data before every frame. Interestingly, this works well with the threaded GCD approach from above. We can just kick off a game update task for the next frame into a separate serial GCD queue at the same time we render the current frame, and they both run in parallel.
- After the game update is done (this should only take a fraction of a frame unless you do some fancy physics), we can pre-compute some rendering data:
- View Frustum Culling, Occlusion Culling, etc
- Precompute skinning matrices, transformations
- CPU skinning. Instead of handling the forward kinematics skinning in the tiler on the GPU, we could run it on the cpu. This is more flexible, since we're not bound to the limits of the vertex shaders (limit of the number of matrices comes to mind). I'm uncertain about the performance benefits here. It's a trade between CPU and DMA memory bandwidth vs tiler usage. I think this may pay off very well in situations where one mesh is rendered several times (shadow mapping, deferred shading without multiple render targets, multi-pass algorithms in general). One of the biggest drawbacks is that the memory usage is (#instances of mesh * size of mesh) versus just one instance.
- Precompute lighting with methods such as spherical harmonic lighting, where the results can be backed into the vertex colors. This could even run over several frames, and then only be updated at a certain rate (eg. every 10 frames)
- Procedural meshes and textures. This is interesting, and mostly depends on a fast memory bandwidth, which the A5 should provide.
- Asynchronous loading of data (textures, meshes). This is mostly limited by IO though, but some interesting applications (such as re-encoding, compression) come to mind.
Wednesday, June 15, 2011
Monday, June 13, 2011
- Clean implementation
- Fires exactly at display refresh, using CADisplayLink
- As simple as possible, trying to avoid any low-level multithreading if possible
- Since a single EAGLContext can only be used on one thread at a time, ideally everything should be only on the secondary thread, and no code should run on the main thread.
Monday, May 30, 2011
Monday, May 16, 2011
since I have got very little time, due to the fact that I'm leaving for Palo Alto in a few hours, the start of this years WWDC trip, I have asked my fellow Limbic co-founders Iman and Arash to write a little guest post. They're writing about the problems we face as a company working in two timezones with 9 hours in between, and being almost "purely virtual". Here it goes:
Unlike many startups, Limbic operates as a virtual company. In our case, we collaborate with team members in seven locations across the globe (Palo Alto, Davis, San Diego, Burbank, Germany, the Netherlands, and New Zealand). As one can imagine, operating in this fashion brings many challenges, but in our experience it comes with substantial benefits as well.
In order to support this arrangement, some degree of planning is essential, as meetings across multiple time zones must be coordinated. For our projects, we use a slew of tools for communication and task management:
* Skype, IRC, and iChat for voice and video conferencing
* Skitch and Dropbox for sharing images and videos
* BananaScrum and Lighthouse for project planning and task management
* GitHub for source code hosting and collaborative development
* Doodle.com for scheduling
The most common problem with working across multiple time zones is finding overlaps in the availability of US and European team members to meet. This leads to inevitable late night or extremely early morning meetings. When working on dependent project tasks, we have found it is important to sync up daily and hand off to other team members to ensure smooth and continuous development. If a voice or video meeting cannot be attended for a particular day, individual members communicate their progress via email to the team. Also, because team members aren't able to casually communicate throughout the day and all discussion happens during meetings, they tend to run quite long in order to cover all issues.
One of the difficulties with virtual collaboration is that it can be slower than face to face communication for rapid iteration. We minimize this by using screen sharing, chat, and video conferencing whenever necessary. A tremendous advantage to working virtually is that it allows everyone to work from their own favorite environment (coffee shop, home, etc.). In addition to the environmental benefits, commute time is reduced or eliminated in many cases, allowing more productive time for work. FInally, with no office expenses to pay, the operational overhead of the company can be reduced.
Recently at Limbic, we have moved towards capturing the benefits of a shared workspace by establishing a small studio in Palo Alto as a hub for physical collaboration, while maintaining the flexibility provided by continuing to operate primarily virtually. We also like to bridge the gap between all team members by periodically planning retreats where we all meet up face to face to have fun, brainstorm, and help kick-off new projects.
That's it! I'm rather exited for the next post, as it's going to be one week after we launch our new game, Nuts!