It is useful to have all types registered before they are allocated
because the memory needed for them can then be allocated before any of
it is required, speeding up allocations because a pool may have been
created beforehand.
The pool allocator would only allocate one item and then stop, its
allocation wasn't reset correctly because of a comparison operator
being the wrong way around.
A window can now be closed by clicking on the X in the title bar. The
input controller is already running in its own thread, calling the
handler-functions given to it on an event's arrival.
The gitignore now contains endings of common executable and object
code files on Windows and Linux, as well as some image file endings
and, for the sole need of being complete, moving picture file endings.
Those vectors are needed for storing a position that is only on fixed
points on a grid. The position and size of a window must be expressed
as integer vectors, for example.
The GLAD function loader library is necessary for the renderer. While
it is possible to write one by hand, GLAD gets generated out of the GL
specification and works just fine.
The ini parser will come in handy for configurations, for example once
the time has come for adding shader packs.
The parser isn't tested yet; writing some (automatic) tests would be a
really good idea.
The utilities are grouped into the following categories:
- Math
Matrices, vectors and special rounding functions are included in the
math category. This still is severely lacking in functionality.
- Containers
Datatypes for storing arbitrary data in a special way, for example
for being able to search through it quickly, in the case of a map.
Currently the only function in this category is for testing how long
a string is, with a maximum number of bytes to check.
- Allocation
Special-purpose memory allocators with restrictions on what they can
allocate. The restrictions are used to be faster in those use cases.
- UUID
Universally-unique identifiers are used to identify one specific
object within the engine's lifetime.
The key for getting the path of the own module in the includes.txt is
no longer '{self}', but rather '{module}', as that is a little easier
to understand.
The include statements generated from the 'includes.txt' have'nt been
correct because of a prefixed string 'modules/' infront of the project
path. The local includes were also not working because the 'modules/'
path element was missing between the project path and the module name.
The build-script assumed that it was nested two levels deep from the
project's root directory, even if it is only nested one level deep;
that bug is now fixed.
Eric-Paul Ickhorn