avarsh / ape2d Goto Github PK
View Code? Open in Web Editor NEWA data driven, entity-component-system based 2D game engine.
License: MIT License
A data driven, entity-component-system based 2D game engine.
License: MIT License
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:
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:
To implement mouse input, we need a system for detecting and transmitting mouse events such as mouse position and clicks.
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.
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:
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:
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.