mattguerrette/vixenengine

Open Source C++ Game Engine

# Vixen Engine C++ Open Source Game Engine

About

Vixen Engine, is an attempt to develop a completely free and open game engine for use in commerical, academic, and personal projects.

Development started on Vixen Engine in 2014 at Rochester Institue of Technology.

Platforms

Vixen Engine currently targets the following platforms:

• Windows ( Windows 10, Windows 7 )
• Linux ( Ubuntu )

Dependencies

• SDL2
• GLEW
• DirectX (DirectX 11)
• OpenGL (OpenGL 3.3+)
• Assimp
• FreeImage
• tinyxml2
• Lua
• lua-intf
• bullet3
• inih

Building

Build instructions are available for Ubuntu Linux and Microsoft Windows

Windows (64-bit) CMake

Included in the repository is a CMake lists file along with a configure batch script. The script is setup to run cmake and output a Visual Studio 2015 x64 solution with project files for each subsystem of Vixen Engine.

All you need to do is run the configure script and locate the generate solution in the _build directory.

NOTE: All dependencies have been included prebuilt targeting x64 with VC++14 compiler in the repository for building on Windows.

Linux CMake

Vixen Engine is being developed on Linux using CMake.

All you need to do to setup development for Linux is navigate into the Linux directory of the repo, and run the supplied configure shell script. It will run cmake and output the Makefile to the _build directory which will function as your testbed for development.

NOTE: All Vixen libraries will output to /usr/local/lib as specified in Makefile.

vixenengine's Issues

[VGraphics] DirectX instanced rendering of geometry.

Currently, there is a significant performance issue with the rendering using DXRenderer. Multiple instances of the same model should be instance rendered as to alleviate some of the rendering overhead.

[VixenEngine] License Change to LGPLv3

License for project will be changed to LGPLv3

[VGame] Need a way to capture SDL_TextInputEvent for text input from scripts.

We need to capture the SDL_TextInputEvent into a buffer that we can send to scripts. This way we can effectively capture user text input when requested.

Here is the SDL sample documentation:
https://wiki.libsdl.org/Tutorials/TextInput

[All] Administrative - the boring bits

I have a few items that may need attention, unfortunately, to do with everything except the code, which happens to the the fun bit.

First, I was wondering whether it would be prudent to have a universal coding style written up, possibly added to a wiki of some sort, simply for consistency within the project. Additionally, the wiki may contain an upcoming features list.

Second, a mode of communication would be helpful in discussing minor items that aren't classified as issues for general communication, at the very least.

The items listed above are little things that will certainly prove useful in creating a project team, and creating an engine that will be almost indispensable for use in popular games, and in education. Cheers

[VixenEngine] Offline resource database solution. Potential integration with Git database.

Currently there is only a runtime resource solution for VixenEngine. There needs to be an offline (not runtime) resource management solution that can transform DCC content into the content packages loadable by the game engine itself. This system will be needed for VixenEditor at some point to be able to compile content.

Features:

• manage multiple types in consistent manner
• create new resources
• delete resources
• inspect / modify existing resources
• change resource file location on disk
• resources must have built in cross-reference dependency checking to assist in resource building and loading process
• maintain referential integrity across all resource operations such as deleting or moving
• maintain revision history of resource changes, with comments for changes
• query system for developers or artists to know where resources are being used in the game

How do we implement such a feature?

• content compilers will be written as subsystem VixenEngine
• leverage the libgit2 C-api to develop a resource database.
• utilize the XML file format to serialize database entries and maintain the relational database
• develop and integrate a GUI front-end into VixenEditor for developers to easily manage resources.

Comments

Please let me know if you have any questions or concerns involving this project. It is no small task to create such a resource system, but I believe developing such a feature for Vixen will greatly improve the engine.

Need a Release build target.

All current dependencies need to be built in release mode, as well as all Vixen library projects need to be setup to build Release.

In doing so, the code base should factor out (using macros) any debug specific logic to increase runtime performance of release builds.

[VGraphics] ID3D11DeviceContext state system

There needs to be a collection of common render states that can easily be created and set on the device context.

[VGame] Lua scripting needs to be optimized.

Currently, there is significant overhead with the current implementation of Lua in Vixen. Analyzing the data outputted by visual studio's performance profiler shows that the most expensive operations seem to be accessing the C++ bound objects from their lua tables and calling any C/C++ functions bound to them.

The possible solution and one I am currently exploring is using LuaJIT to precompile all scripts and hopefully increase runtime performance through loading and executing the bytecode.

[VixenEngine] CMake build system

VixenEngine needs to be setup using CMake which will generate the correct Makefile for Linux and Visual Studio solution/project files for Windows.

GameObject Lifecycle needs update

Currently the GameObject Lifecycle is buggy and unreliable. The code should be refactored to follow this graph.

Time should be a singleton.

Instead of passing (float dt) around everywhere in the update and render loops, time should be a singleton that contains get methods for all of the relevant values (deltaTime, totalTime, FPS, etc.).

[All] documentation comments need to be added for doxygen

Vixen needs to have its code documented. This way, we can generate doxygen documentation that can eventually be linked to on developer site.

[VGraphics] Render multiple meshes.

Currently the implementation of DXModel only renders using the first mesh received from Assimp after loading the model file. There needs to be a new IMesh interface and corresponding DXMesh class to hold per mesh data, which DXModel will use to render each mesh

[VGame] Scene loading needs to be reworked and made better

Currently, there are evident race cases and unknowns involved with interaction between lua scripted game logic and scenes because issues with scene state. The lifetime of a scene and all of its objects needs to be made more concrete.

For example:

LoadScene -> Scene is now created -> initialize all gameobjects -> call initialize (scripting) on all objects -> continue with gameplay.

There was an issue with the current scene not being set correctly in SceneManager due to the current scene loading code, and trying to create or delete objects before a scene has been initialized or made current causes issues. This needs to be addressed.

Optimize removal of GameObjects from the scene.

Objects are currently being added to a list for deletion, which is really slow and inefficient. They should instead be marked for removal from the scene. If they are marked for removal, they will be removed as the update loop iterates over them.