gamedevtecnico / cubos Goto Github PK

• Spot Lights
• Directional Lights (CSM)
• Point Lights (Cubemaps)

Info

Instead of having options for using submodules or not, we can use find_package by default. If find_package fails, the submodule is used as a fallback.

The README.md file is missing the contribution guidelines:

• pull requests should have a clear description of what they add
• code must be formatted using clang format
• camelCase is used for functions, methods, local variables and fields (no underscore prefixing on private fields)
• PascalCase is used for class names
• UPPER_CASE is used for macros
• snake_case is used for namespaces, folders and files
• each file should have an #ifndefinclude guard
• when closing a namespace the namespace name should be added as a comment, the same goes for if macros (#ifdef, ...)
• namespaces should match the directory structure, except namespace impl, which can be used to hide implementation details (check cubos::gl::impl)
• everything should be well documented (/// style, check already existing files)

There should also be a mention to the gh page with documentation.

• 3D Grid representation
• Triangulate 3D grid
• Draw Object
• Camera Implementation

Change cubos-engine to be library, "entry point" should change to a cubos::init(...) function

Depends on #15.
Implement loading and storing settings.

• Base Stack implementation
• Test with SSAO
• HDR Tonemapping
• Bloom

What do you think about this? I think it is a more fitting name.

Since we'll start working on the engine systems, we now need to separate the core sources from the engine sources.
The current src and include folders should be moved to a core folder.
A new engine folder should be created which contains the engine sources.

With this change it makes sense to also move the samples and tests folders to the core folder.

• Light Classes -> LightData struct
• Offscreen Rendering
• Camera Class

Properties for each voxel in a model will be defined using a palette.
Palettes can use different index sizes (8-bit, 16, 32) depending on how many materials are needed for the model.
Palettes can be shared between models.

First Implementation of voxel structures:

• Simple 3d grid (Array)
• each slot in the grid contains index of the material within the model's palette (first index (0) will be considered as empty)

(IDEA)
2 Different palette types:

• Gpu Only: data sent to shaders (only properties needed to draw the model)
• Engine: Contains other properties of the voxels, such as physics info, metadata, etc.

This issue is a follow up of #9
A OpenGL implementation of cubos::gl::RenderDevice will be provided on includes/gl/ogl_render_device.hpp.
The targeted OpenGL version will be 3.3, since it has wide support.

• class RenderDevice
• class ShaderStage
• class ShaderPipeline
• class ShaderBindingPoint
• class ConstantBuffer
• class Texture1D
• class Texture2D
• class Texture3D
• class CubeMap
• class Sampler
• class VertexBuffer
• class VertexArray
• class IndexBuffer
• class RasterState
• class DepthStencilState
• class BlendState
• class Framebuffer

• Pool allocators
• Stack allocators

Implement the Stream interface for a compressed stream.
The usage should be similar to this:

Stream& originalStream = ...;
CompressedStream compressedStream = CompressedStream(originalStream);

Such that when any data written to/read from the compressed stream is first compressed and then written to the original stream/read from the original stream and then decompressed.

The Zlib library may be used to implement the compression/decompression.
This feature will be useful for implementing compressed archives for loading engine resources.

The settings functionality needs to be enhanced:

• other settings types should be added (ints, doubles, booleans).
• make it so that there are both a global settings object and local settings instances.

Allowing local setting instances will be useful for reading/storing settings separately for the engine and the game.

The building pipeline should be able to generate:

• cubos-core (library) - includes all the core modules of the engine that will be used by the systems. This should be easily testable
• cubos (executable) - links cubos-core with an entrypoint that is responsible to load all assets into a game. Also includes all the systems necessary to execute the game (e.g. rendering, input, etc...)
• cubos-editor (executable) - a standalone application that links cubos-core and helps creating assets that will then be loaded by cubos

CMake fails with:

include could not find load file:

googletest

Even if googletest was found (or added as a submodule).

We should provide an implementation of Archive for mounting compressed files/directories to the virtual filesystem. This would require adding an external dependency such as zlib.

• Input
• Settings

SCons may be a better alternative to CMake.
We should discuss it in the next milestone.

• Utility function for sending vertex data to GPU (for testing).
• Function to register models, should return an identifier so that the rendering of the model can later be requested.
• #87
• #88
• #89
• #90

Since .qb files mix voxel and palette data, they must first be converted to their equivalents in the engine's core (palettes and grid/octree as described in #83)

Just like the GLFWWindow was moved to the src folder, the OGLRenderDevice should too.

• class RenderDevice
• class ShaderStage
• class ShaderPipeline
• class ShaderBindingPoint
• class ConstantBuffer
• class Texture1D
• class Texture2D
• class Texture3D
• class CubeMap
• class Sampler
• class VertexBuffer
• class VertexArray
• class IndexBuffer
• class RasterState
• class DepthStencilState
• class BlendState
• class RenderTexture
• class DepthStencilTexture
• class Framebuffer

• Octree memory implementation
• Analyse Compile time / Runtime drawbacks/advantages of octree
• Triangulate Octree
• Draw Octree object

https://github.com/jbeder/yaml-cpp/

Use an option to determine the executable being generated.
By default the engine should be run as the game engine: invoking entry.cpp's main function.
In the other cases, it should run the test executable.

Properties of each triangle:

• 3 positions (one for each vertex), can be defined as indexes of the grid, to then be converted by the renderer into local/world space.
• Normal is sent in local space as a vector.
• Material index in palette

As it is, the Window class isn't abstract and the implementation is chosen using macros. This should be changed to having an abstract Window, and another class GLFWWindow which implements the previous one.

This way we can switch between different window implementations (eg.: GLFW vs WinApi) at runtime which would also allow us to easily switch from OpenGL to DirectX, without recompiling the engine.

• Log on request
• Logging levels (Critical, Warning, Error, Info, Debug)
• Error Reporting
• Directing logging output

Consider SPDLOG

talk about vscode, vs, emacs
compiling toolchains
cmake

• Create windows
• Input Bindings
  Hardware that is connected to specific actions (WASD, Spacebar, left joystick, etc.)
• Input Actions
  Specific actions that result from a player's input (move, jump, etc.)

- [ ] Parse Settings File

• Retrieve Settings on request with required defaults
• Update Settings values