The silent refactor

I’ve been busy. Very busy. The year is coming to its end and I had the need for one more refactor. One big refactor. One that has been in my list for quite some time. And I called it the “silent” refactor.

As my other project is moving forward, so are the needs for new things. Improved text rendering, shadows, better input methods, physics… Alas, most of the newest features had some kind of impact in the general performance of the engine. And at some point the game was no longer playable at 60fps.

Enters the silent refactor: a series of low-level changes with a single purpose in mind: improving performance. While I tried to avoid changing the high-level APIs, some of them got broken in the way because of the updates. For example, I went back to using C++ smart pointers and the majority of the function signatures got changed as a side effect. It wouldn’t have been fun otherwise 😉

Anyway, the biggest change of all is probably multithreading support. Yes, I just said the “M” word. Simulations now run in two threads: one for window management, rendering and input stuff and another thread for the actual simulation pass, including updating components and physics.

The render pipeline suffered some adjustments too. Now it’s material-centric, meaning the render queue organizes primitives based on the material they’re using, thus avoiding a lot of redundant draw calls due to state changes. This is a huge performance gain if there are several objects sharing materials or primitives.

Maybe the most visible change is the support for Retina displays in OSX. There was an aliasing problem in older versions caused by a difference between the window size and the frame buffer size. For Retina displays, the later is twice the size of the requested window size. So, for example, a 1280×720 window size needs a 2560×1440 frame buffer in retina-based monitors. The fix required me to upgrade GLFW to the latest version, which had some side effects in other subsystems, but nothing too worrisome.

The code is a bit unstable as I still need to clear some concurrency issues, but the performance gain is noticeable. Even with shadows enabled, the simulation is back to 60 fps.

That’s all, folks. The last refactor of 2014.

Happy New Year!

Advertisements

3 thoughts on “The silent refactor

  1. Do you think it’s possible to use Crimild to view/rotate a 3d object (.step, .fbx, or .3ds file)?

    I’m familiar with SDL and have an existing project that rotates a 2d .png image using the arrow keys. Now I’d like to do the simplest version of that in 3d.

    I’d prefer to keep it simple and not use a massive new tool for the job (unity, assimp, glut, tinyobjloader, etc).. and Crimild is the first project I’ve seen that mentions SDL as part of it’s foundation!

    Any suggestion?

    • Actually, Crimild is no longer using SDL. I need to update the About page, sorry. In recent versions, Crimild makes use of GLFW for anything related with window management and input.

      If you really want to use Crimild in your project, you can use just the Core classes, which are plain C++ with OBJ support, and implement a custom Simulation and Renderer objects using SDL+OpenGL. But I think that’s overkill if you want to keep things simple and just have a rotating object. Alternatively, you can try and integrate a third-party library for just loading the models and then implement a custom render. There are plenty of tutorials for that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s