We’ve made a lot of progress last month and it was time for a performance patch! We’ve dedicated ourselves to make Caffeinated3D more stable, perform faster with less resources! We’ve managed to reduce project size by 97% along with cutting the build times in half and drastically reduce the CPU usage from built projects inside the Engine. Alpha Testers have also gotten involved and are bug testing so that we can eliminate all problems they come across!
ANNOUNCEMENT - Forums and Alpha Testing Stage 1
Caffeinated 3D has come a very long way in its development and is getting closer and closer to it’s release so on November 21st, Stage 1 Alpha Testing started. Several developers from various backgrounds (Unity, Unreal, NuclearBASIC, RealmCrafter & Esenthal) have already started working with Caffeinated 3D getting an early head start with their projects while also being awesome and bug testing everything even more rigorously than we have. To accommodate these awesome developers the Caffeinated3D forums are now LIVE, free for anyone to join and become a member of the C3D family!
There is still no set date for the Public Beta however we are planning sometime in the first quarter of 2017. If you want to stay informed join the forums for the most up to date news or simply to ask questions to the developers!
NEW TOOL - Key Frame Mapper
In preparation to the testing of the 3D systems, we had a chat about how to handle model animations and came up with a very straight forward model, consisting of about 10 functions giving the user complete control.
Different animations for a player model (eg, walk, run, jump etc.) need to be defined by their keyframes before being called, this makes life a lot easier in the long run of your project. To help you with the initial step of setting up animations the Key Frame Mapper is a simple tool that allows you to create these Key Frame sets quickly and stores them away so that you can access or edit them at any time from within any project.
UPDATED - CPU Performance
A huge problem that we have somehow missed until now was the terrible CPU performance of games built on Caffeinated3D. An idle game would use on average 16% CPU when it’s not even rendering anything! This is obviously unacceptable, and after discovering this problem we set out to find the source and fix it. Now an Idle game uses 0%, and around 2-4% when rendering away. Performance is something that needs to be done right from the start otherwise lots of problems will start happening later down the line. To help performance even more, we’ve introduced some basic Accelerated Hardware features which will continue to get more and more advanced as we go allowing the GPU to get involved with all the rendering!
UPDATED - Project Building Speed
As part of our performance patch we also took a look on how to improve build times of your projects inside Caffeinated3D. They were already being built fairly fast with an average speed of 10-15 seconds but an issue we found was on the first build of your project whenever you started up the engine the build would take significantly longer. This has now been fixed and average build time has been reduced to only a handful of seconds! It’s almost Instant!
UPDATED - Project Architecture
With lots of libraries and mechanics going on in the background projects with C3D started to get really messy! Caffeinated3D is split into multiple libraries to keep the system organised and while it certainly helps us manage our code a lot better it resulted in your projects having about 7 .dll files in your project Bin folder. As part of our mission to improve the performance of Caffeinated3D these past weeks we’ve restructured the library architecture of our system so now all secondary libraries are linked statically into one dynamic library C3D.dll. This resulted in the huge decrease in build times along with a cleaner project folder.
Furthermore another problem we came across was project size. Since the Engine is essentially a glorified IDE with lots of visual editors, it needs a compiler to build your code and assets into an exe. However this meant the compiler needed to be in your project folder as well, and while this would not affect your final game memory size, it did mean that new projects would be ~970MB without a single asset involved! This is…. well it's awful, so we re-thought how to handle this problem. The compiler is now a library instead of a program, which means that now it can stay inside the install directory instead of having to go in each project. This increased the install size but it means that any new project is now only 50MB.
UPDATED - Vulkan Rendering
Caffeinated3D uses a OpenGL, Vulkan Hybrid rendering system and until now, we’ve set it up to only use OpenGL. This was due to when we first implemented Vulkan it had only just been released and had several problems. Feeling that it wasn’t quite ready we pushed it to the side and temporarily disabled it. Since then Vulkan has come a long way and we’ve re-activated it inside Caffeianted3D. You are now free to choose which renderer you want your projects to use by simply writing one line of code. With that now back in the picture we’ve also started preparing our PBR shader & lighting pipeline. It won’t be long until beautiful graphics finds it way back into the engine!
We’ve had a few questions about why we decided to go with Vulkan over DirectX12. While implementation of DX12 is certainly on the agenda for the future, as it stands Vulkan is a much better choice for rendering. It’s cross platform allowing developers to use Linux as well as Windows, works very nicely with our OpenGL platform and is capable of rendering beautiful scenes. This is obviously merely our opinion but it is also the opinion of Gabe Newell so we’re fairly certain we made the right choice.
“We are extremely pleased at the industry’s rapid execution on the Vulkan API initiative. Due to Vulkan’s cross platform availability, high performance and healthy open source ecosystem, we expect to see rapid uptake by software developers, far exceeding the adoption of similar APIs which are limited to specific operating systems.” - Gabe Newell, Valve (https://www.khronos.org/vulkan/)
UPDATED TOOLS - Function Library, User Options & Console
The function library is a rather nifty tool for storing functions which you may want to re-use elsewhere, however it had some underlying flaws in the system which led to quite a few problems, so we’ve touched it up a little. The interface got a slight touch up along with a more stable backend that results in less strange occurrences.
Last patch we introduced a user settings window which gave you a lot more control on how the engine looks and feels. We’ve expanded it a little further giving you more styling options along with some convenience options for loading up your projects faster on startup!
The Console is something which every programmer needs and now it just got better. Originally it simply printed out text telling you where the errors are which is extremely useful but we’ve taking it a little further and made it a bit more dynamic. You are now able to simply double click on the error and it will take you to the file and line in question. We also toned down the colors. Originally if an error occurred then the console would light up red letting you know immediately that something was wrong, where as now, to stop your from searching through the outputs, only lines with details of errors get highlighted! The updated User Options now also allow you to change the color of outputs to whatever you desire!
Fixed Functions
- LoadMesh
- LoadShader
- Log
- Include
(See full list: Docs.google.com)
Bug Fixes
- Fixed Bug where multiple window application weren’t rendering the 3D viewport (Windows Only)
- Fixed Bug where window memory lists weren’t being stored correctly resulting in Null pointer crashes.
- Fixed Bug where opening a new project while having a file open from another caused a crash.
- Fixed Bug where projects stored inside “Program Files (x86)” weren’t able to be read by the engine.
- Fixed Bug where certain functions reliant on file paths weren’t able to actually read the file paths because they became scrambled between the engine and the compiler.
What’s Next?
With 2D systems on the verge of being completed, it’s finally time to bring 3D to life. We’ve certainly been doing a lot of work with 3D in terms of getting the backend working with Vulkan and now that everything is all linked up along with all the matrices calculated, it’s time to start testing everything!
Audio is also on the agenda, research and concepts are finished so now it's time to implement it into the engine. However we don’t want to just give you the basics of a play/stop sound system, you’ll be getting an entire suite of functions to create some really wacky effects with effects such as reverb, compressors, specialized filters etc. this means you can have truly reactive sounds to your environments rather than “out-of-place” audio.
