A C++ 17 library for producing 2D games.
Home Page: https://www.nerdthings.dev/ngine
License: Apache License 2.0
I'm Reece Mackie (by the handle Rover656), a .NET Placement Software Engineer and 4th year Robert Gordon University student who is passionate about game development and tooling.
These are languages I have used in the past or am learning.
Middle mouse button cannot be detected.
When using a tileset canvas, alt-tabbing from the game when the state is not active causes the framebuffer to render completely blank.
Steps to reproduce the behavior (on Nvidia hardware only from what I can gather):
The framebuffer should NOT be blank.
Not available.
We need to properly integrate the Box2D physics engine as right now, it simply uses it for collision checking.
This should be added as it takes a massive load off a developer, allowing them to focus on building the game, not the physics engine.
None foreseeable.
The renderer at the moment is very stable and works well with the current engine structure. The problem is that the renderer is not very expandible and while looking at implementing a HTML UI engine (RmlUI), due to the structure we'd not be able to have the renderer run this. The problem is the Renderer's support for indices, currently only a vertex buffer exists making indices extremely slow (We'd need a system similar to the vertex conversion code).
Rework the renderer to support indices (optionally) and have an index buffer alongside the vertex buffer. In order to ensure that the renderer does not slow down due to writing another buffer, we need to investigate ways of multithreading the renderer where possible (such as processing vertex conversions or buffer writing). This would both allow indices to be used in the renderer and could also speed up the conversion process (Currently only quads and triangle fans to raw triangles) and would involve far less data being passed to the GPU. This implementation shouldn't break anything that is currently in the Engine, but would change (again) the API for pushing batches of vertices.
In addition to this change, the matrix stack should be made available to the batch Add function to allow for easier translations of massive vertices.
The update loop can be moved to a second thread (for release builds) to allow for drawing to be uncapped to an FPS (If options allow for this). This will allow for updates to use a full frame and drawing to use a full frame, not whatever ratio there is currently for both in one frame (i.e 2 parts of the frame to update, 1 to draw).
UWP Support is still to be added to Ngine, this is available in raylib. This will need to be done through a bootstrapper App, this will be added as part of raylib in the platform specific code namespace.
This is a planned feature, so it is being added to the issues system for tracking.
N/A
Want to help out with this? Feel free, this is a medium priority issue as we need to get platform support to a good standard, and it would be a great help!
The resource manager could be rewritten to allow fine tuning of what assets are loaded and/or skipped. This will make loading of assets more trivial and easier to refine.
None foreseeable.
We need to create documentation for Ngine to make it more easy to use. This would involve either
This is required as currently the engine has a large number of classes, structures, enums and methods that sometimes can be unclear in their actions. This may also require a rework of class, struct and method naming conventions to make this more clear and predictable.
A new, panel based user interface system should be introduced into the engine. This panel based system will allow for all current input methods to work effectively. This will be heavily events based but will also be highly customisible.
Specific concepts will be added once features/spritebatch is merged as this will be heavily dependent on the new spritebatch system.
Raylib just added a project that allows a windows game to run under ANGLE. We can try to support this.
There is nothing further to say at this time
A canvas should be introduced. This will contain a render target and will only be redrawn when the contents of the canvas are modified. This will improve performance of large, more complex shapes or compositions by a substantial amount. This will also allow tilesets to be drawn with little to no overhead.
This should be added as it allows much more flexibility and performance benefits. For example if you were drawing the terrain for a game, each chunk can be contained within a canvas, and only when the terrain was modified in that chunk would the canvas be redrawn. This would have immense performance benefits.
There are no trade-offs for this feature if used correctly. It must be made clear that the redraw method, whatever it may be, should NOT be called unless the canvas is changed, not each frame. This would be done within the update loop, protected by an if statement of some description.
There are no alternatives to this idea, as this does not fix any existing issues, but introduces a completely new concept.
When a control is larger than the panel it is inside, the dimensions of the control begin to go wrong and will begin to misalign.
Create a control within a panel that is larger than the panel.
The control should be constrained to a maximum size.
I've selected for refactoring 17 lines of code which are duplicated in 1 file(s) (1, 2, 3). Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Code Once guideline rating! 👍
Here's the gist of this guideline:
You can find more info about this guideline in Building Maintainable Software. 📖
ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁
Good luck and happy coding! 
✨ 💯
The engine currently allows for developers to do basic save systems, but this should be integrated into the engine to allow this to be more seamless throughout the engine.
Rendering large tilesets with the canvas system results in massive textures being stored on the GPU. An alternative must be found, and the canvas system should be reserved for smaller sizes.
This is a tracker to allow me to see what needs to be done this quarter.
UPDATE: As we are proceeding with #15, many of these will be completed there, and the timescale has been pushed back. Closed as a result
I've selected for refactoring 12 lines of code which are duplicated in 1 file(s) (1, 2). Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Code Once guideline rating! 👍
Here's the gist of this guideline:
You can find more info about this guideline in Building Maintainable Software. 📖
ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁
Good luck and happy coding! ✨ 💯
Currently, the SpriteBatch added in commit 4234942 has a large impact on processor usage and therefore has an overall impact on the game's performance as a whole.
We should redesign the spritebatch to be built away from raylib's drawing functions, and take a more Monogame approach. The files that we can base off of can be seen here:
If we were to implement this kind of system on top of the rlgl module (in more basic terms as Monogame has 3D support too) the we will be will (theortetically) be able to both fix all of our performance issues and add depth support. In addition to this, the default shader must have an alpha test added to it (https://www.khronos.org/opengl/wiki/Transparency_Sorting) to allow transparency to work to an acceptible level (This could be improved in a future PR, but for the moment we will not worry about true transparency).
Drawing shapes will not be available through the SpriteBatch, this will need a separate canvas class. An advantage to this is the potential future support of SVG file types. Either way, this is a small trade-off for proper sprite batching.
The current SpriteBatch will be removed from master, and the new SpriteBatch will be built and tested in the feature/spritebatch branch.
This will then be reviewed as part of a PR and then merged to ensure all correct testing has taken place. This testing will be run to ensure that this will not introduce game-breaking modifications to the engine past the usual API changes.
Another alternative that could be implemented instead of this is the ordering of entities within the scene. This would mean we would have to remove the event based draw events, but it would mean the current Drawing class can still be utilised while having proper transparency and depth support. This would allow shapes to be drawn in the same way that they currently are. This would potentially be less work and will mean the performance issues of ordering will be minimised as every single reordering will be run upon a change of depth of an entity, instead of every single frame. I feel this is the more preferred option as less modifications to the code will be needed and overall there are significantly less features lost through this implementation. I will try this system in an alternative feature branch feature-alt/entity-ordering.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
