kyle-emmerich / blueshift-engine Goto Github PK
View Code? Open in Web Editor NEWHigh performance C++ game engine in early development
Home Page: https://noxastra.com/engine
License: BSD 3-Clause "New" or "Revised" License
High performance C++ game engine in early development
Home Page: https://noxastra.com/engine
License: BSD 3-Clause "New" or "Revised" License
There is an experimental class under Experiments/EventStream that can store event objects for another system to read. Right now, it supports basic synchronization in that it can only read OR write; not both.
Features:
Since this will be a very core concept for Blueshift, it needs to be very fast and must avoid cache misses when possible. Much of this is dependent on user code though; slow event processing will lead to a lot of thread preemption by the operating system and will thrash the cache.
The engine core needs to be finished before all else. This includes the runtime loop, subsystem instantiation, and configuration loading.
Blueshift should be limited in model format support in order to keep codebase size down. Very seldom will anyone actually need to load any format at runtime. Models should be compiled to the simplest binary form and loaded almost 1 to 1 to the GPU for maximum runtime performance; perhaps even gzipped.
Therefore, Blueshift will support exactly one model format: its own compiled binary format. For everything else, there will be command-line tools to compile other formats into this.
The math library is an important part of any game engine and has a profound effect on the game developer's impression of the engine. Our API must be good, and it also must be fast.
Therefore, C++11 and greater will be used for full effect.
Issues are useful for keeping a roadmap but can be a hassle to keep up with. It is worth it to maintain this though.
Gotta bind it all!
Math library:
Core:
Scene graph:
Physics:
Graphics:
Input:
Platform:
In order to provide photorealistic rendering in Blueshift, an extensive shader library is in order. It should provide things like functions to produce realistic lighting on a surface or process reflection data.
The Blueshift Binary Model format is a simple 3D model format that is designed for minimal runtime processing in order to maximize performance. As such, it may be sent to the GPU almost straight from storage.
The format will begin with a "magic" combination of four bytes:
'B', 'B', 'M', 0x0
The last byte denotes the revision number; the format is not expected to be compatible across revisions as it is compiled from other formats.
After the magic header, the info header will follow. It will be a simple structure, defined as follows:
struct BBMHeader {
uint64_t SizeInBytes;
uint16_t NumGroups;
uint8_t Flags;
};
One may infer that there are more information structures following this one. However, for the sake of brevity, please see the code to see their definitions.
I'm currently writing Doxygen comments for everything in the engine. This is likely to be quite a long project.
The input subsystem is important because a game without input is just a simulator. It goes without saying that the input subsystem should be at least in a prototype stage before the first usability test occurs.
There are multiple input devices that the game engine should register and provide access to:
(in order of importance, descending)
However, exposing access to individual input devices is not enough. Games typically have actions triggered by input. By implementing this at the engine level and doing it properly, game developers can be saved a lot of headaches. However, this is one of those things that most devs don't trust the engine to do, so it has to be really damn good.
The input system implements devices as generic interfaces implementing certain capabilities. Because of this, devices may be passed unsafely at runtime to a manager that can read the capabilities implemented and allow action triggers to be fired by the device. The manager should handle bindings in a generic way and allow any action to be bound to any device capable of triggering it in one way or another.
The input system must also save these bindings in a configuration file that can be copied for each user profile. By providing these tools, the game developer must only develop a compatible interface for modifying bindings and the rest will be simple.
The rendering subsystem encompasses a lot of different things and serves as an abstraction layer between the rendering library (bgfx) and the game engine's scene management.
Since Blueshift is intended to be of extreme performance with photorealistic graphics, special considerations must be made that are as of yet undecided. However, certain things are universal and will be parameterized below:
In order to maximize serialization performance for networking and storage of data, the engine must include a mechanism for turning game objects into raw data.
Usually, one could simply transfer data to a C++ Plain Old Data (POD) type, but we want to be able to apply extra functionality to these types. To demonstrate this, review the parameters for a POD type in C++:
A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.
The important parts here:
Essentially, a plain C++ struct; not very useful. For networking objects, we'll definitely want a user-defined destructor and copy assignment operator. For everything else, we definitely want non-PODs as members.
The existing solutions out there are not that great. Google's protobuf is one of the best, but it suffers from being difficult to setup, and the bindings are written in separate files. This is okay if you're writing an application that uses it, but a middleware level piece of software like a game engine can't do that.
Therefore, Blueshift will have its own inline reflection, much like Unreal Engine 4. We will also be using an automated build tool that will run before compilation in order to expand special macros and generate runtime-usable reflection data from classes.
This means low overhead during runtime, but slightly longer compilation times. If the tool is sufficiently optimized, this is unimportant.
I've learned a lot developing this project, and now it's time to apply said knowledge. The input subsystem needs to be redesigned with a better API and better consciousness of thread safety and performance.
However, there are still a few things that need to happen before this. Most importantly, the event stream system. I will revisit this issue and assess the situation when that's done.
http://www.gdcvault.com/play/1022249/SIMD-at-Insomniac-Games-How
Review this later and see how it can fit in to make the engine super fast.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.