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.
Adding a start screen led to cleaning up some initialisation processes. Dengine
now formally initialises subsystems from the respective .h files instead of
ad-hoc from the main game file.
On delete entity, old entries were not being cleared out causing bullets being
the most commonly spawned object to inherit unusual behaviour from "dead"
entities. Fixed by ensuring on entity delete the entity entry is cleared out.
Also add rendering guard against malformed vertex points. The renderer has
a strict requirement that all polygons passed in are CCW. Bullets were being
formed with the mindset of a triangle strip causing it to render incorrectly.
Now renderer checks ordering of polygons points and asserts if incorrect. It
works based off calculating the bounding area polygons, where in CCW order this
will produce a negative result and positive for CW order.
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.
If one interval were completely contained within another then the logic would
not correctly identify the overlap. Instead check the length of the intervals
and ensure the smaller interval of the two is compared against the larger one.
Triangle strips were originally by chance were rendering correct for most cases
until collision detection was implemented. Incorrect assumptions about
specifying triangle strip winding order meant that on occasion the last triangle
in a polygon would not be rendered.
This has been amended by strictly ensuring that on rendering of polygon the
order is correct from the vertices that are passed in.
We need to generate interim vertex points during the collision detection loop
that includes rotation to check for collision. During collision detection,
vertex points are rotated and positioned in placed for checking.
We also re-create this vertex list in the renderer suggesting that we could
cache the list in the entity or look at coupling rendering and collision
detection.
Fundamental mismatch between rotation and offset of polygons. Polygons can be arbitrarily ordered in terms of vertices as long as they are in a CCW order.
However there should be no restriction on the starting vertex position.
Since this is the case, the entity offset for a polygon should offset from the
starting vertex to the perceived "entity origin". This entity origin is where
collision detection, rotation and movement is based off.
Occasionally with the right orientation, degenerate triangles will appear as
they are no longer zero-area triangles which OGL can cull during rendering. The
issue comes from having to manually ensure each primitive in the rendering
pipeline sent to the render groups were correctly marked with degenerate
vertexes.
Instead, we can now just pass the vertex points straight through, using
a begin() and end() structure which will append the start and ending degenerate
vertexes for us.
Asteroids move and are a part of the entity sytem. Added some debug markers for
memory usage and fixed a bug in logic causing degenerate triangles to show up
depending on the angle of approach towards the origin.
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.
Premultiply transformation matrix onto vertices before sending onto GPU to
preserve transformation properties of entities before being batched into
a general group. This removes the model matrix from the shader pipeline- instead
in rendering code we deal in world space (which works out to be more intuitive).
Only in the last step in GLSL we convert back to normalised coordinates.
Incorrect assumption that strings only needed degenerate vertexes at the start
and end of each string instead of characters causing render "wings" between
separate strings.
Fix render-group not switching to next group if current group is full.
Degenerate triangles allows a single triangle strip call to be called on
multiple independent triangles without "connecting" strips inbetween the
triangles.
Render all entities with the same texture in one call. Currently only
implemented for humanoid entities. Since we are rendering using triangle strips,
between entities there is invalid rastered data between entities. Using
degenerate triangles this may be mitigated, by indicating to OGL which triangles
it can skip in the rendering process.
Attempting to add child weapon data to an entity has revealed the need for an
entity origin to which children start transformations from. Worth exploring
scene graphs in the future.
