nasso / ige Goto Github PK

Right now, OpenAL/libnyquist pointers and data structures are stored in AudioClip, AudioSource and AudioListener. A better implementation would store this elsewhere to make it easier to change the audio backend in the future.

Related: #22

std::unordered_map is a good candidate for optimisations as it is used extensively by the engine. A better implementation would be very beneficial in many cases.

It forces a ->get() indirection that can get confusing, i.e.:

auto a = app.world().get<SomeResource>()->get().some_value;
auto b = entity.get_component<SomeResource>()->get().some_value;

They are required because std::optional doesn't support reference types.

Possible solutions:

• Using raw pointers, nullptr indicating the absence of a value.
• A custom ige::Option wrapper type with special support for references.

Some headers are getting way too hard to read because of all the inline code (e.g. World.hpp).

We could instead implement all the functions in a separate .inl file that is included at the bottom of the header file. This should make the code easier to read and document.

See also: https://stackoverflow.com/questions/1208028/significance-of-a-inl-file-in-c

Currently, there's no proper way to manipulate an entity tree as a whole. Some mechanism to do so would allow us to:

• Create and destroy an entity tree all at once
• Look up entities in a subtree (by component, name, id...)
• Spawn/instantiate a group of entities (aka "prefabs"?)

Due to the complexity of a game engine, logging is pretty much required to keep track of what's going on. Currently, everything is written directly to the standard outputs using std::cout and std::cerr. A proper logging system would instead allow us to write log messages anywhere (e.g. to a file on disk, send them over the network, or display them in an in-game console).

Most game engines have some way handling logging with various levels of verbosity. The most common levels available are:

1. Critical error messages
2. Warning messages
3. General purpose information
4. Debugging messages
5. Trace (very verbose)

These levels are commonly identified by an integer like in the ordered list above. The logger then has routines to filter messages to the ones we are interested in only.

Proposed interface

Setting the current log level should probably be just a function call with an enum value:

using ige::log::LogLevel;

ige::log::set_log_level(LogLevel::DEBUG);

An idiomatic C++ interface for logging messages could look like the following:

ige::log::error << "Error";
ige::log::warn << "Warning" ;
ige::log::info << "Information";
ige::log::debug << "Debug message";
ige::log::trace << "Low level trace that won't be shown";

However, some logging libraries prefer C-style IO for performance reasons.

Either way, effort should be made to be as lazy as possible for disabled log levels. Writing to ige::log::trace should be as light as possible when the current logging level is lower than TRACE.

Some popular logging libraries in the C++ world:

• glog, by Google
• spdlog, by Gabi Melman
• loguru, by Emil Ernerfeldt

When copied, the AudioEngine object does not move its internal openAL handles causing a crash as they are being double freed on destruction.