kubic-c / spock_engine Goto Github PK

Now that most of the engine has been smoothed out and redesigned, we must turn to the main purpose: Tiles.

Tiles:

1. A free floating entity or part of a tilebody entity
2. contains some arbitrary data for end-user's game (e.g. health, callbacks. etc.)
3. Occupies at least 1 or more units

Tilebodies:

1. A grid of tiles that can be as assigned fixtures to a b2Body
2. Divided into chunks
3. Works directly with Rigidbody components

Currently, the internals of spock engine are unclear from misorganized data to unclear naming or lack of clear naming standard.
This leads to an odd access pattern with in data/variables.

Solution:

• Provide a Markdown/Text file on naming conventions and other programming conventions.
• Remove the usage of contexts in ECS systems and access them directly via global variable.
• Remove components that must not be copy constructed and replace them with a component that instead points to it; this allows external allocation outside of flecs. Reason being that if flecs must move a component in memory, it will copy construct a new one, and then delete the old one via its deconstructor; if a components has a memory pool or some heap allocated variable/controller its deconstructor will be called leading to an issue like wild pointers.
• Rename "state_t" to a more purposful name such as "internal_t" to mirror that it is internal access only, and make it so that it acts as private interface rather then a "state" only getters and setters structure. This will allow a more clear sense for the resource manager, ECS world, and other misc. data that is in the engine_t interface to be merged or incorperated into it. Leading to an overall increase in structure/data comprehensibility within the project.

refer to commit 661e43b's description.

Currently spock engine's UI canvas's design is slightly cluttered and includes a lot of boiler blate user side.

Solution:

1. Redesign the ui canvas' elements to be addable through functions calls by the main ui_canvas_t class.
2. Create system through which all elements are controlled by restraints, which controls size and position of ui_element_t through restraints.
3. opitional- if an element already exists on screen and a new one is added, it should be automatically moved. So both can be visible and one is not not clipping inside of another.

// 1. && 2. example
ui_canvas_t* canvas = scene.canvas;

// this will make the element display in the middle of the screen
canvas->add_text("hello_world").add_horizontal_constraint(SPK_MIDDLE).add_vertical_constraint(SPK_MIDDLE);

Adding ways to debug render lines, circles, and other polygons onto to entities will allow end-users to debug render positions and other things.

Solution:

• A component that holds information about a line, circle, or box named comp_shape_t
• A renderer that renders comp_shape_t(s)

vvv Straight to the point vvv

Changes:

• Rendering and meshing are now both entirely in the render folder, meaning no random render related code in the systems/ folder. This allows much more easier focus on tile logic and such

• Rendering and meshing systems are held in lists and then called by a new class called "render context". So instead of being called through a flecs pipeline, theyre managed directly. This was largely for readability and allowing them to be "tooken away" from the systems/ folder

• Removed old UI systems, will need to be redone, wasnt really satisfied with how they were done, and plus TONS of messy logic interpolated with rendering code together.

• Cameras components now no longer have a View-Projection matrix, it is now stored in rendering context. The camera compoents now just holds things like pos, scale, etc. and then the VP in the rendering context is updated with the current cameras config via 'recalculate'. This also prevents rendering systems having to call get_mut or get_ref which is ugly.

Changes to come in the main branch directly:

• adding ways for the user to render lines, circles, etc. for debug purposes or what have it via entities with a set destruction timer and tags.
• UI redesign.. duh

Input detection/management within spock engine is all over the place and not well planned out.

Making a object oriented interface for input management (within the window class) is the best way to go about making a fully fledged input detector

Example below:

spk::window_t& window = spk::window();

window.is_pressed(SOME_KEY_NUM);
window.mouse_click_pos();
window.mouse_pos();
window.mouse_is_pressed(SOME_MOUSE_BUTTON_NUM);

Currently spock engine gives the user no ability to play sound

Solution:

• Add a sound manager, or some sort of method to play sound using SDL

// example

const char* sound_file = "sound_file.mp3"

uint32_t sound_id = spk::load_sound(sound_file);

spk::play_sound(sound_id);

Further development of the UI design, im pushing this off later to go work on the primary focus of the engine which would be tiles.

To get to the point: allow a FLECS style creation of a UI element.

The reason I want to add this is it would simplify creation of UI elements, and reduce boiler plate. (PS i hate boiler plate)

example below

// this will make the element display in the middle of the screen
canvas->add_text("hello_world").add_horizontal_constraint(SPK_MIDDLE).add_vertical_constraint(SPK_MIDDLE);