Hot reloading C++
Here is one approach to hot reloading of C++ that I use on my side project.
It is specific to Visual Studio.
This is useful if you want to rapidly iterate on some code, and don't enjoy continually restarting and navigating the program to whatever state it needs to be in to test the change.
It is based upon swapping DLL's and requires the ability to serialize state.
Overview:
1. User modifies a C++ source file
2. File monitoring detects the change
3. Determines which projects are effected by the change.
4. Moves the existing DLL/PDB for those projects(they cannot be deleted as they are in use).
5. Fires up MSBuild to compile projects
6. Once Build Completes:
It is specific to Visual Studio.
This is useful if you want to rapidly iterate on some code, and don't enjoy continually restarting and navigating the program to whatever state it needs to be in to test the change.
It is based upon swapping DLL's and requires the ability to serialize state.
Overview:
1. User modifies a C++ source file
2. File monitoring detects the change
3. Determines which projects are effected by the change.
4. Moves the existing DLL/PDB for those projects(they cannot be deleted as they are in use).
5. Fires up MSBuild to compile projects
6. Once Build Completes:
- Build Fails:(
- Build errors are propagated into the Visual Studio IDE
- Have MSBuild dump out a text file containing the error msg
- I use this command: /fl2 /fl3 /flp2:logfile=JustErrors.log;errorsonly /flp3:logfile=JustWarnings.log;warningsonly"
- The msg is formated in a way that VS understands:)
- Load the file in your game(JustErrors.log)
- Use OutputDebugStringA to print it, this propagates it to VS, the error is now visible in the errors view
- Old DLL/PDB moved back
- Build Success:
- Serialize state contained within relevant DLLs(into process owned memory)
- Serializing and then unserializing the entire game state is the simplest route and avoids any potential conflicts with mixed state between DLL's.
- Destroy state associated with DLLs, and then unload the DLLs
- Load new DLLs, create new state
- Unserialize old state into the new state
- Resume game
Rebuilds triggered by this process generally take about 1-2 seconds for my application, the exact time will depend your code.
**Visual Studio has a bug where it keeps the PDB loaded even if you unload the associated DLL. So you can't delete the old PDB for any DLL you previously loaded, at least not while your game is running. Hopefully they fix this at some point.
**Visual Studio has a bug where it keeps the PDB loaded even if you unload the associated DLL. So you can't delete the old PDB for any DLL you previously loaded, at least not while your game is running. Hopefully they fix this at some point.
Modify faster
I've been working on completing the compute shader path.
This is used to calculate the color, shadow, and ambient.
If a discrete and integrated GPU are present, both are used.
After writing both an AVX & compute shader pipeline..
AVX is more flexible and avoids the tedium of using a terrible API.
I hope we get AVX to 1024+ bit soon.
Compiling C++ quickly in Visual Studio
Ensuring fast C++ build speed requires some effort--
Modules should improve the situation, but that is some years off(C++17 if we are lucky).
Modules should improve the situation, but that is some years off(C++17 if we are lucky).
Here is what has worked for me(using Visual Studio)
This is intended for a rapid iteration build, a build you intend to ship would not use these settings.
This is intended for a rapid iteration build, a build you intend to ship would not use these settings.
- Enable /MP Multiprocessor builds.
- Disable Global optimizations
- Incremental Linking (/INCREMENTAL) and Use Library Dependency Inputs(Yes)
- Add /Zc:inline to command line of compiler
- Linker->Optimizations: References(No), COMDAT Folding(No)
- Pre-Compiled Headers(PCH). Put rarely modified files in the PCH, but include everything you can possible include. Test the compilation times of files that use the PCH. You can enable this in Visual Studio(*2). Try to get it as low as possible.
- Limit the headers you include, especially avoid including headers within headers
- Forward declare everything that can be, even types passed by value can be forward declared
- Do not create "registry files". *example: a file containing an enum with an entry for each type of component in your engine. If you do this, you will need to add an entry to this file each time you create a new component, which will result in a large and often triggered rebuild cycle.
- If you find yourself calling from Module A to an object in Module B, but only doing so once, think about wrapping that access in a C function call. The C function can be placed in Module B, then either declared extern within Module A, or a separate header can be created if it is likely that this C function will be called multiple times. This reduces coupling between files. Changes to A will not trigger a recompilation of B.
- /PDBCOMPRESS slows the linker down, should probably not use this
- Use type erasure to reduce coupling & generate less code. For none performance critical paths, a single type erased path can be preferable to a template path per type.
- Focus on optimizing the build speeds of any commonly used templates. There are multiple things you can do here.
- Some templates can be simple wrappers around a none templated type or function, which is itself implemented in a .cpp file, and thus not inline.
- Use variadic templates to replace old style overloads based on # of arguments.
- If there exists a finite set of types that the template can be instantiated with, try explicit template instantiation.
Templates are commonly accused of killing build times.
This is not very accurate, the real culprit is headers. Since templates exist in headers it gives the false impression templates are at fault.
Once you have solved the exponential build time issue caused by headers, templates have a only a small effect on build times.
This is not very accurate, the real culprit is headers. Since templates exist in headers it gives the false impression templates are at fault.
Once you have solved the exponential build time issue caused by headers, templates have a only a small effect on build times.
*2: To enable build timings:
Tools -> Options -> Projects and solutions ->VC++ Project Settings->Build timing->yes
**Tools -> Options -> Projects and Solutions -> Build and Run and set the MSBuild project build output verbosity to "Normal"**
Carving
Various voxel landscapes I made recently.
The carving tool is still pretty basic so I can't do anything impressive yet.
You basically can select from 5 shapes + 4 blend ops.
But it works in real time so I can fly about and apply these ops and see the result immediately.
Chile & Argentina
Here is a link to my friends blog detailing our three month trek in South America.
Photos include famous stuff like Torres Del Pine, Tierra Del Fuego, and Fitz Roy.
Probably the most memorable bits:
-trekking through lava flows created by the 2011 eruption of Volcan Pueyhue; 40 mph winds filled with ash, visibility was almost nothing, we would stumble to the edge of chasm, gaze down, and have no idea how deep it was:) Had to use GPS/compass to navigate our way.
-living in a tiny hut on a glacier for five days crammed with 12 people, waiting for a storm to pass--
Lots of nice photos on his blog
Photos include famous stuff like Torres Del Pine, Tierra Del Fuego, and Fitz Roy.
Probably the most memorable bits:
-trekking through lava flows created by the 2011 eruption of Volcan Pueyhue; 40 mph winds filled with ash, visibility was almost nothing, we would stumble to the edge of chasm, gaze down, and have no idea how deep it was:) Had to use GPS/compass to navigate our way.
-living in a tiny hut on a glacier for five days crammed with 12 people, waiting for a storm to pass--
Lots of nice photos on his blog
![]() |
| Snowfall in Tierra Del Fuego |
![]() |
| Poking my way across a glacier |
color
Coloring algorithm is dead simple.
Eventually I want to incorporate the elevation & slope.
It is using a (mostly) physically based lighting model, but the input materials were typed at random by me, and don't match any real world data.
Current input signals to lighting: red, green, blue, roughness, spec, ambient, shadow
bad colors
Sculpting Voxels In Monocrome
Modifying the world at run time is now possible. The primary difficulty was minimizing which parts of the world needed to be rebuilt.
![]() |
| Yeah, I made this- what is it? No idea. |
![]() |
| Giant letters, hoarding tiny balls |
![]() |
| Voxel balls barreling down the mountains side |
Unfortunately for this project I am heading down to South American for a few months and won't be working on it during that time. Ciao.
let there be noise--
Was on a trip for about a week so didn't get much done. Added basic noise support. The noise is applied to the sphere here.
Graphics are pretty bland right now, but I've got more important things to work on for at least a few months. Might touch up the graphics early next year.
![]() |
| Some parts have noise, some parts don't. Formula:(min (add sphere noise) (repeat donut (repeat hexigon (repeat sphere)))) |
![]() |
| Everything has noise here Formula:(add (add sphere noise) (repeat donut (repeat hexigon (repeat sphere)))) |
![]() |
| Formula:(min (add sphere noiseRMFBillow) (repeat donut (repeat hexigon (repeat sphere)))) |
![]() |
| Formula:(min (add sphere noiseRMF) (repeat donut (repeat hexigon (repeat sphere)))) |
![]() |
| Formula:(sub (add sphere noiseRMF) (repeat donut (repeat hexigon (repeat sphere)))) |
Graphics are pretty bland right now, but I've got more important things to work on for at least a few months. Might touch up the graphics early next year.
LuaJIT info & links
LuaJIT
- Size of coroutine: 400 bytes
- Each VM requires ~10k physical, 128k virtual memory
- JIT disabled on iOS because Apple doesn't support run time code generation
- JIT disabled on Windows 8 for ARM for the same reason
- LuaJIT interpreter(no JIT) is ~3x faster than standard Lua
- LuaJIT with JIT enabled is ~20x faster than standard Lua
- Lua C API prevents JIT compilation
- LuaJIT FFI is much faster if compiled, but if not compiled(like on iOS), it is slower than the Lua C API
- LuaJIT FFI cannot be safetly sandboxed, do not use for user scripts(Mike Pall recommends process isolation)
- LuaJIT GC considerations by Mike Pall
- 1 to 2GB/ memory limit(depending on OS and x86/64) for current LuaJIT, extended to 2-4GB whenever the new GC arrives , but you wouldn't ever want to allocate that much memory
- All LuaJIT allocations must be within first 2GB of address space
- LuaJIT 3.0 will have a brand new GC, optimized for real time applications
- Tracing compiler discussion with Mike Pall(LuaJIT) and Brenden Eich(Javascript), worth reading the entire thing
- Design of LuaJIT: optimization, register allocation
- Lua 5.2 __gc metamethod not support for tables yet in LuaJIT, can use newproxy, an undocumented Lua function, to work around this
- LuaJIT bytecode 40% smaller than standard Lua
C++ Variadic Templates
I've been using Visual Studio 2013 RC which supports C++ 11 variadic templates.
Here are a few things I've noticed.
Good
edit: Looks like there is a proposal to fix my last point- N3728
Here are a few things I've noticed.
Good
- Compile time reduced. Replacing my N duplicates of a template with a single instance means less work for the compiler
- Less code. Is some cases *way* less code. This is great! Can replace manually duplicated templates with 1 instance, can also replace Boost Preprocessor generated templates with variadics
Bad
- If you step into a variadic function in the debugger it does not always allow you to see what values were passed into the function. I did see it work once, so perhaps it is just buggy/incomplete and the final release for VS 2013 will fix this.
- The following code does not compile, to work around it, as far as I can tell, you must resort to C++ 03 code(boilerplate). You couldn't instantiate this type because it doesn't map to a struct/class, but it would make it easier to pass type information around.
CDT
So I walked into Canada on September 5th. To see all the places from Mexico to Canada along the Continental Divide was pretty amazing.
In the New Mexico desert always on the hunt for the next water source(cow troughs mostly)
In the Colorado San Juan mountains struggling to make 20 miles per day in the snow and altitude.
In Wyoming the Wind River Range is possible the best mountains I've seen, and I've seen many
In Montana crushing out its 900 miles with my friends SweetAs and Aquaman.
And then walking into Canada with Balls and Sunshine, whose journal you can read if interested
My first Grizzly bear encounter was about 10 miles from the monument that marks the US/Canada border. Only saw three bears on this trail, half as many as on the PCT.
Here are a few pictures, nothing can really capture a 4.5 month/3000 mile hike, but this will have to do
Another hiker this year kept a detailed blog of her hike. Her name is Wired and she was a few days behind me for most of the trail(until Montana). You can find her blog here. It has tons of pictures and is high quality.
In the New Mexico desert always on the hunt for the next water source(cow troughs mostly)
In the Colorado San Juan mountains struggling to make 20 miles per day in the snow and altitude.
In Wyoming the Wind River Range is possible the best mountains I've seen, and I've seen many
In Montana crushing out its 900 miles with my friends SweetAs and Aquaman.
And then walking into Canada with Balls and Sunshine, whose journal you can read if interested
My first Grizzly bear encounter was about 10 miles from the monument that marks the US/Canada border. Only saw three bears on this trail, half as many as on the PCT.
Here are a few pictures, nothing can really capture a 4.5 month/3000 mile hike, but this will have to do
![]() |
| Cirque of the Towers in the Wind River Range |
![]() |
| SweetAs and I in the Wind River Range |
![]() |
| Climbing up to the top of the Divide |
![]() |
| Fetching water from a cow tank in New Mexico |
![]() |
| Hiking with Breeze in Burglar across the wasteland around Lordsburg, NM |
![]() |
| Grapple and Thunder along the CDT in southern Colorado |
Subscribe to:
Posts (Atom)
















































