Zig sometimes doesn't cache stuff correctly.
In the presence of this bug the game might be recompiled in the second compiler command.
This doubled compile times in the worst case.
This allows using the StackAllocator for more data structures and library functions.
Fixes#268Fixes#95 (at least to the point where I can't do anything about it)
This is done by reusing the lightQueue instead of allocating new ones(→less locking in the allocator) and by avoiding too frequent task priority updates(→less locking when adding new tasks).
The remaining 30% will hopefully be done by improvements to the zig GPA.
To let the rest of the code know about this decision I implemented a wrapper over the Allocator interface which cannot fail.
This is just the first step in the upcoming refactoring attempt.
* Rename run_release scripts to run_OS (#241)
* Update README with new script names (#241)
* Fix run_windows infinite loop
* Make debug_linux more verbose.
* Make windows script errors match linux
* Automatically set working directory (#252)
* Remote quotes from echo commands in run_windows
* Replace zig run with zig build run
* Replace spaces with tabs in run scripts.
* Make 'Building Cubyz' message more accurate
* Have run scripts check the machine architecture.
* Add failsafe for unrecognized architecture; erase scratch work in debug_windows
* Replace more spaces with tabs in debug_linux
* Linux run script: don't pause if debug build or NO_PAUSE
* Windows run script: do not pause in debug builds or if NO_PAUSE
* Escape a paren
* Fix x64 typo
* Delete logs about failing to build
* Use `call` to call the batch script on windows
Without `call` windows won't execute the lines after calling the batch script.
---------
Co-authored-by: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com>
Moving the mesh update at high priority into the threadpool, allows for faster and more efficient(previously meshes may have been updated multiple times in a row) updates.
fixes#223
A CircularBufferQueue means that we might revisit some points, for example when there is a dim and a bright light source.
However in practice the performance impact of using a PriorityQueue is huge, so this edge case doesn't matter really.
This makes light propagation about 20 times faster and should help with #223, but it doesn't seem to actually make a difference. There is likely something else going on here.
Emission now work as a base light, rather than adding to the ambient light.
This makes them produce the same light strength and bloom regardless of the environment.
