SegsEngine
SegsEngine copied to clipboard
Segs
The engine that will become the basis for client/editor/server components.
Seems that some TypeInfo instances are not exported :/ Likely will need to rethink the way type-system is done.
Maybe instead of glue plugin telling the engine which assembly to load, the assembly should embed some meta-data that will tell us that a `glue` library needs to be loaded...
Right now we have references to Mono in 2 places: - engine module - glue plugins It would be nice if glue plugins only used 'services' provided by engine module...
At the minimum we need: Release Editor [ TOOLS + DEBUG_ENABLED ] - used for development and as part of Segs tooling. Engine - distributed with Segs releases Debug Editor...
Right now many of the components accessible from the scripting language are made available through the following pattern: 1. Store a pointer to script instance in the object `ScriptInstance *script_instance;`...
Right now GridMap supports only a single MeshLib, it would be cool if it supported more :) A good first step would be converting `GridMap::mesh_library` to a vector of `Ref`...
I'm not very happy with the approach the original Godot engine took to tooling/testing/executables: Namely that all functionality is embedded in a single file, for example: * unit tests are...
This interface should allow reading a specific number of bytes into dynamically allocated memory. Function prototype should look like this: ```cpp Vector FileAccess::get_buffer(uint32_t count); ```
Right now there are a few places in the codebase where temporary buffers are created like this: ```cpp { PODVector buf; buf.resize(REQUIRED_BUFFER_SIZE); use_buffer(buf.data(),buf.size()); // exiting this scope frees the buf...
The generated binding glue is pretty hefty, it might be nice if it was a separate dll ?