What

• [x] Proper file structure
• [x] Split .h files into .h and .cpp files so it can be compiled into binary
• [x] Make sure it compiles on Windows

Why As of now, Ducktape can't really be called a library as, well, it's not a library. People can't even compile it on windows, neither can it be compiled into binary. So I made an issue to track all of the stuff that needs to be done.

More tasks to finish:

• [x] Link against all the binaries
• [x] Provide a .so, .dll, .a, and .lib binaries

What In the Vector2.h header file, replace the static Vector2 Down, Left(), NegativeInfinity(), One(), PositiveInfinity(), Right(), Up(), Zero() methods with static variables that replace the methods. Why Seperate methods for this is unnecessary as all those methods do is return a specific Vector2() value. This can be done with just static variables.

Write documentation for all the classes, methods, and members, that's all. :) Here's a checklist for all the files: Engine:

• [x] Component.h
• [x] MeshRenderer.h
• [x] DirectionalLight.h
• [x] PointLight.h
• [x] Tag.h
• [x] Transform.h
• [x] Configuration.h
• [x] Debug.h
• [x] Engine.h
• [ ] Entity.h
• [ ] LoopManager.h
• [ ] Macro.h
• [x] Scene.h
• [x] Time.h
• [x] Window.h
• [x] Input.h
• [x] Key.h
• [ ] Serialization.h
• [x] UserPointer.h
• [x] Camera.h
• [x] Cubemap.h
• [x] Mesh.h
• [ ] Renderer.h
• [x] Shader.h
• [x] Texture.h
• [x] Vertex.h

Editor:

• [ ] Editor.h
• [ ] EditorModules.h

Is your feature request related to a problem? Please describe. There is no particle system that would let me create special visual effects.

Describe the solution you'd like A flexible particle system component.

Is your feature request related to a problem? Please describe. As of now, the engine loads sprites from local directories literally every frame. This is not performance-friendly at all. According to SFML:

Using as few textures as possible is a good strategy, and the reason is simple Changing the current texture is an expensive operation for the graphics card. Drawing many sprites that use the same texture will yield the best performance. Additionally, using a single texture allows you to group static geometry into a single entity (you can only use one texture per draw call), which will be much faster to draw than a set of many entities. Batching static geometry involves other classes and is therefore beyond the scope of this tutorial, for further details see the vertex array tutorial.

source: SFML tutorial

Describe the solution you'd like Use a set<pair<string,sf::Texture>> to hold all of the loaded textures. If a sprite requires the engine to load from x (temporary name) directory, go through the set to check if the asset x has been loaded before. If it has, use that texture. If not, load the texture and add this newly loaded texture to the set for reusing.

Is your feature request related to a problem? Please describe. A File Explorer-like Window that could be used to navigate through the Resources (assets) used by the current project, with options to rename, and delete the files/directories. It'd be great to also allow for searching for files based on their name, and for copying and pasting files between directories.

Similar to Unity's Asset window: Or Unreal's Asset Browser window:

Implementing the Physics engine had started in #4, but never got actually finished. This issue will be used to track all of the upcoming features that need to be added. ~~For now this issue is only focusing on basic collision. Physics joints will be tracked in another issue.~~ Nevermind, the issue seems very short, so I'll be adding physics joints as well. And I almost forgot, methods like "OnCollisionEnter" need to be added as well, I'll be adding them soon, once the ones below are finished. Here we go:

• [x] (1) Simple Rigidbodies (No Colliders attached)
• [x] (2) Box colliders
• [x] (3) Circle colliders
• [x] (4) Edge colliders
• [x] (5) Custom polygon colliders
• [x] (6) Revolute Joint
• [x] (7) Distance Joint
• [x] (8) Prismatic Joint
• [x] ~~(9) Line Joint~~
• [x] (10) Weld Joint
• [x] (11) Pulley Joint
• [x] (12) Friction Joint
• [x] ~~(13) Gear Joint~~
• [x] ~~(14) Mouse Joint~~
• [x] ~~(15) Wheel Joint~~
• [x] ~~(16) Rope Joint~~
• [x] (17) OnCollisionBegin
• [x] (18) OnCollisionEnd
• [x] (19) AddForce
• [x] (20) Friction, Drag, etc. properties
• [x] (21) Raycasts
• [ ] (22) Collision Shape Overlap
• [ ] (23) Finishing (fix bugs, etc.)

This website would be helpful in working on these.

What Remove UpdateEssentials. Why It was implemented as a carrier-struct that contains sf::RenderWindow and etc. variables related to the engine, that is used while calling functions. I think there isn't a need for this, as all of these variables are already available from the DT namespace.

Until now, I had been following a Vulkan tutorial, so the rendering system was not very scalable, and it could only render one mesh, one texture, and alot other limitations. But since I'm done with that tutorial now, it's time to restructure this. I plan to have the following classes:

• [ ] Texture
• [ ] Shader
• [ ] Mesh (component) And the rendering system should then loop through the Mesh component every frame and render the mesh stored in it.

Describe the bug The window by default opens into the resolution of 800x500, but the wm (window manager) forces it to open in full screen, making it stretched out. And since the wm is forcing it to go full screen, the engine itself is not aware of the fact that the resolution has been changed, and is not resetting the view to the appropriate values. And resizing the window fixes this unresponsive issue, as the engine is notified about the resizing, and is aware.

To Reproduce Steps to reproduce the behavior:

1. Run the flappy bird example while using a window manager like i3

Can I try making this?

[Edit] This is a Pixel art editor inside the Game Engine, which makes users easy to use the engine! So, we can make sprites easier and prolly faster! I guess we have some plans to make DuckTape for phones.. In those cases, this idea would be so helpful i guess! :)

Describe the solution you'd like Allow multi-texturing, having multiple diffuse/specular/etc. textures in a single mesh. This would also allow for merged textures, for grass/dirt effects etc.

Is your feature request related to a problem? Please describe. As of now, there does not exist a way to "group" multiple Entities together, such as Meshes of a single Model.

Describe the solution you'd like Implement Parent-child Relationship system using Components. The whole system would run on a component:

class Relationship
{
public:
    Entity parent;
    std::vector<Entity> children;

    SetParent(Entity parent);
    AddChild(Entity child);
    RemoveChild(Entity child);
};

Here's a sample usage:

Entity parent = scene.CreateEntity();
Entity child = scene.CreateEntity();

scene.Assign<Relationship>(parent).AddChild(child);
// OR Alternative method:
scene.Assign<Relationship>(child).SetParent(parent);```