avarsh / ape2d Goto Github PK

Returning references to components is bad, since we can run into reference invalidation. This is when the vector reallocates its memory in order to grow, meaning all the components are reallocated, causing the references to be invalid. The following test:

gives this output:

most likely as a result of the original reference pointing to an invalid block of memory. Obviously an easy solution is to just not do something like this in your code, i.e. do not use a component retrieved from the list before you add a new component. However I'd also like to look at some alternatives.

Note: this issue was originally opened on the ape2d-ecs repository.

The window system is currently very limited. In particular, it lacks the following features:

• Window modes, such as fullscreen and borderless
• Window control options, such as close button only or no minimise
• Window events, such as window close event, resize event

The Makefile as it currently stands does not actually function in a way that is any better than a shell script recompiling the entire library, even for small changes. This should be fixed so that, for example, when working on examples, the entire engine does not need to be recompiled.

Use FYTS to implement a better update loop.

As this is a game engine, window resizing should be handled as a automatically as possible, e.g. adapting to different aspect ratios, giving options for black bars or widescreen. Viewports should allow the user to define what areas of the screen content is displayed on.

Colour modulation is a useful technique in games for changing colour of sprites. We can use SDL_SetTextureColourMod and SDL_SetTextureAlphaMod along with a colour attribute in the sprite component to achieve this. Since it is applied to a texture, we must remember to save the current colour and restore it after drawing a sprite, as a sprite may be a subsection of a texture.

We can also support other types of modulation using SDL_SetTextureBlendMode and SDL_SetTextureAlphaMod

Currently the renderer is based upon Open GL, but is only a prototype - it has issues such as having a max buffer size for vertices. An SDL based renderer would still be somewhat low level but allow the rendering system to be more functionally complete.

It is a good idea to add OpenGL error checking using glGetError(). Checking for _DEBUG or NDEBUG macros could be used to prevent reduced performance in release modes, but some error checks should always be enabled - e.g. shader compilation, program linking, file loading, as they are needed at release as well (e.g. if the file cannot be found).

Here is a checklist of features I'd like to implement in the graphics module:

Essential

• Sprites and Texturing, as well as a SpriteBatcher for efficient rendering
• Primitive convex shapes
• Font loading and text
• Camera

Preferred

• Builtin sprite animations
• Borders on shapes and lines - this seems to be quite difficult, since you have to essentially de-construct the line segments into triangles, and then add some kind of a join, such as a mitre, bevel or round join.
• Scene graphs

Advanced features

• Lighting and shadows
• Particles

To implement mouse input, we need a system for detecting and transmitting mouse events such as mouse position and clicks.

Mouse positioning

Generally, elements such as interface items (e.g. buttons) or game items within the world which may be clickable require mouse position input. A proposed approach is as follows: entities may hold a mouseover component which has as its data the bounds (either in terms of the window, or the game world) which the component wants to "watch". A system then iterates through all mouseover components and checks the mouse position in that tick. It calculates both the absolute position relative to the window and to the center of the world, by converting the position into world coordinates by taking the position of the viewport and adding the position of the mouse relative to the window (adjusting for scaling). The system accordingly invokes a callback if the mouse is inside relevant bounds.

Mouse clicks

Similarly to above, entities may register a mouseclick component to watch for clicks. When a click occurs, all clickable entities are looped over and a callback function is fired.

It is additionally important to consider the z-index of indices so that overlapping entities' actions are not both executed. We may be able to utilise the scene graph for this, or we may let the user develop their own system; for example by adding layers and checking which layers are visible.

Currently in the input branch, callback functions are not being called, even though equality and hashing is equal on the unordered map keys and the event being used as an accessor.

Currently, the input event hashing function utilities 32 bits for all the information - however SDL key codes in themselves are 32 bit, meaning that we may have to switch to a 64 bit value.

From profiling, we can see that almost 20% of the program is spent within the std::type_info::hash_code() const function - this is invoked in the ECS system, when dealing with components using type_info. It would be ideal to optimise this potentially by finding an alternative filing system which does not rely on type_info.

While components are stored within a contiguous vector for fast iteration, some systems do not iterate upon the entities in this order. The rendering system uses a scene graph traversal, for example. Hence, it could be beneficial to store entities within a custom container which inherits a base class providing interface methods. By default, the existing implementation may be used, but some systems may then provide such a container to allow iteration to be equally fast.

In particular, the component manager may take a class as a template parameter which is used to store the components. This class needs to support the following operations:

Component addition
Component removal
Component retrieval

Difficulties may arise during removal - currently there is some interfacing between the world and component manager as there is a mapping between component indices and entities.

Currently the scene graph system allows for visual ordering of entities through a depth-first search (of what is actually a scene-tree, not a graph). Additionally, there is a requirement to allow the following unimplemented features:

• Removal and insertion of nodes
• Collation of transformations
• Ability to apply local updates (i.e. updates transformation matrices for all sub nodes)
• Iterative traversal (we don't want to overflow the call stack if we have a deep tree)

We may want to have transform nodes, which add their transformation to the current transformation matrix. Pre-render functions may apply a transformation to a node before the node and it's children are processed, and post-render functions apply a transformation after all children are processed.

A spatial partitioning system allows grouping of entities. It is highly relevant for the following purposes:

• Broad phase collision detection
• Mouse events, e.g. detecting if an entity is below the mouse when a hover or click occurs
• View culling (simply excluding entities outside the camera view from the drawing process)

The partitioning algorithm does not need to be extensive - I believe a simple grid based system should work, or at most a quadtree.

Since the engine is being rewritten/cleaned up, here is a checklist of which features should be present within the rewrite:

ECS

• Entity creation and deletion
• Component creation, retrieval and deletion
• Component enabling and disabling
• Entity tagging
• Blueprints
• Default components
• Exclusive components

Core

• 2D Vector
• Transform component
• Rects
• Callback based Events
• Event Queue
• Timer or frame counting functionality

Graphics and Windowing

• SDL based rendering (See: #4)
• Window management
• Viewports and automatic view scaling

Scenes

• Scene graphs with node insertion and removal
• Transformation cascading

Input

• Reading input from JSON files
• Space partitioning for mouse input

An input system is essential to the engine. Initially, it should support keyboard and mouse input. The approach taken will be similar to the one described in this article. Essentially, a "context" will be a mapping of low level hardware commands to callbacks which are executed. Multiple contexts can exist in the system, with priorities. Any input cascades down the context chain. A context can either observe the input signal and pass it on to the next context or can eat the signal, in order to prevent multiple actions occurring on one input.