- 155comments
- 515comments
- 76comments
- 192comments
- 51comments
- 57comments
- 568comments
- —discuss
- 19comments
- 10comments
- 139comments
- 123comments
- 16comments
- 129comments
- 201comments
- 301comments
- 364comments
- 1comments
- 27comments
- 46comments
- 93comments
- 20comments
- 25comments
- —discuss
- 51comments
- 16comments
- 49comments
- 283comments
- 128comments
- 11comments
This looks really nice.
I still remember when I worked in game development back in 2004 or so, that I made extensive use of Visual Studio's "Edit and continue build" feature at work, and how it really helped with the feedback loop. It was a little buggy but worked very well considering it was only a "debug" feature.
A few years later I worked on an even bigger game with an even bigger loading time, and "Edit and continue build" no longer worked at all due to the platform architecture of the game. It really, really hurt my productivity (and motivation). I wish this project all success, it could help many people!
(Does Unity have something like this yet? I remember last time I worked with it I loved being able to change the properties of objects at runtime, but still missed being able to change the actual code...)
It looks like Unity does support runtime editing, or rather, "hot reloading": https://docs.unity3d.com/Manual/script-Serialization.html
I didn't know that prior to you raising the question, so I can't say how well it works unfortunately.
The last time I used Unity (about 1~2 years ago), hot reloading was basically useless and I tried to avoid it as much as possible (some people actually disable to disable this feature to avoid any "accidental" runtime recompilation.) It messes with serialization too much that it only works with very, very simple cases.
In my experience, it only reliable works for singleton objects which have changes in their method bodies. Any change in the memory layout creates random null reference exceptions on each frame update.
It also depends on how you've designed your MonoBehaviours. If you have anything dependent on resources retrieved in your Awake event, those references will not be restored and the Awake event will not re-occur. So you either have to check and reacquire the references in your Update event (which is costly), or design everything around serialized fields that are set in the editor, with no objects acquired during Awake (which is intractable for anything but the most basic projects).
Unity is designed to get the basic demo feature of whatever you're doing done as quickly as possible. But building a production-scale product is actually harder than just writing from scratch, as there are a lot of stupid design decisions in Unity that get in the way.
Unreal also has similar support for C++.
Yes it does, and recently they made Live++ free for Unreal users. I maintain a list of alternatives to RCC++ on the wiki: https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...
It's not always reliable however, if you add/remove variables in your UCLASSES or USTRUCTS, or the values in your UENUM, it can fail or have unpredictable results, or at least it did as recently as 4.18/4.19.
Otherwise if you're just adding/removing code from classes it works extremely well and saves a lot of time restarting the editor.
For me, the most memorable chapter in the excellent book Coders at Work was the Dan Ingalls one, in which he made the case for interactive development.
Does this have any applications other than hot reloading?
The purpose of Runtime Compiled C++ is robust 'hot reloading'.
I suppose I'm the only person who wondered if "DirectX11" meant that MS had finally ported their flagship game APIs to the venerable Unix graphics system.