Add some system that allows us to automatically define and allocate different
application states at runtime without having to manually make the entries into
our game state structure.
It's basically an array of pointers determined by the app states defined in the
appstate enum. This is necessary since different modes, (start menu, options,
game world) have different data and we'd like to be able to define them
uniquely.
Reduce the number of files in project by merging texture and shaders into
assets/renderer file. It's better to keep code local to where it is rather than
splitting them into "self-contained modules". It becomes easier to understand
reading top-to-bottom and there's is less jumping around which can increase the
difficulty of comprehending the code.
Convert names to use more of a <namespace>_<object><Action> format.
Fix reading one shot inputs not working due to prematurely clearing out state
data tracking input changes between one frame and another. The transition count
used to track this now stores difference between each frame in the input flags.
This also solves requiring at the end of the frame to update the transition
counts at the end of each update loop.
Switch to something of smaller scope in aim to be able to finish a project from
start to finish. Also allow refreshed eyes to review the existing API and see
what can be improved on after taking a short break from the project.
No longer repeatedly invoke malloc for retrieving memory. Some operations still
leak memory (notably audio streaming). We introduce notion of Transient and
Permanent storage. Transient memory is used for data in memory that is
temporarily allocated (i.e. graphics for that frame's output), and permanent as
more like game state storage.
We now give out pointers from a pre-allocated block of memory, so we have no
allocation cost and benefits of reduced memory leaks. The transient block gets
reset every frame. Any memory allocated within is cleared at no cost simply by
rearranging the base pointer of the memory block.
Until engine architecture can clearly be separated from the game, i.e.
notion of entity storage belonging to game and concept of entity belonging
to engine, worlds/scenes belonging to game or engine- the project will
only refer to Dengine.
Audio can be played with 1 call, audio_beginVorbisStream which
encapsulates the initialisation of the renderer and release on finish.
OpenAL is quoted to have a limitation of around 32 sources. Audio
renderers hence acquire a source slot on playback and immediately release
on finish. This ensures that sources are held optimally and minimises the
possibility of saturating the available sources.
Renderers hold an index to the source list, which the index reveals the
source ID for their use.
Mobs battle in real-time with the hero when in range. Start encapsulating
logic into entityStateSwitch() to organise entity properties changing
between different states.
Introduce basic concept of memory management in MemoryArena. Begin passing
around a memory object to track memory usage and eventually delegate
memory allocations through. Remove the old memory tracker in the debug
object and incorporate into engine primarily.
Add a debug console for logging information and events to the screen in
a console-like fashion. Debug is now initialised after the game, this is
so that you can pass the game's memory arena and font file to the debug
services. Debug services now properly initialise debug element positions
from this information and not through the update routine.
Mixing and matching V2 int and float types in the code creates too much
necessary work when an integer implementation has to interact with float
implementation. Let V2i create the cast for us and use floats for all
vector operations since they are mostly mathematic.
