We need to be able to easily add arguments, so we can add them, instead of searching for an alternate way, which is often less intuitive.

It should be a class with static methods AddArgument(...) and ParseArguments(). I would suggest an std::map<std::string, ArgumentInfo*>, which would let us create one ArgumentInfo structure/class and then add all options (e.x. '-r' & '--resolution') to the map with a pointer to it. Less redundant data and easy checks whether arg exists or not (just check for nullptr).

Proposed example sketch of what an element of ArgumentParser should contain:

short: -r
long: --resolution
arg number: 2
verification func: [](auto w, auto h)->bool{ return IsNumeric(w) && IsNumeric(h);};
argument callback: GameManager::GetInstance().GetWindow()->SetSize();

All should be added dynamically via ArgumentParser::AddArgument() method. It should return self-reference, to make adding arguments in a batch easier, like so:

ArgumentParser::AddArgument(...)
               .AddArgument(...)
               .AddArgument(...);

It looks like we shouldn't keep Google Test on our repository. Remove it from repository and provide instructions on how to build it and install on both platforms inside README.md.

A MUST HAVE for terrain generation.

Features:

• Should generate a cloud of points in 3D space (only points - turning them into voxels and drawing will be renderer's job)
• At one "generate" call we should create an entire chunk of data (16x16x256 points). Then, Game Manager will decide which chunks should have genrated data.
• Generated data must be continuous throughout chunks - the game will not generate new chunks if it is not necessary, entire map will be created on as-needed basis.

We need some class that will take care of logging & will be platform independent. I was thinking about either class with static log methods or a singleton.
Either way we need #defines to simplify calls to logger to 'LOG_ERROR(just like printf);' (same with LOG_INFO and LOG_WARNING).
It needs to log to stdout and to file. Windows version should log to OutputDebugString as well.

• Logger skeleton
• Different log types
  • Log error
  • Log info
  • Log warning
• Defines
• Different platform versions
  • Windows
  • Linux
• Substitute all // TODO log comments with LOG_x macros

We will also need final documentation, when we return our project.

Requirements (from Mr. Biedrzycki's page):

• Overall it should fulfill following sentence, roughly translated from Polish: "Final documentation should present the project from its best possible side, however a good look at met problems is very important as well and it means, that the team properly understood the task. So, on one hand "good PR", on the other a critical approach to the work done."
• A sheet with task list and its real manhours, compared to the one delivered at the very beginning of the project
• List of realized features
• App architecture description (description of which modules cooperate with each other, description of main classes and their role in the system)
• App should be buildable and launchable on clean system after following instructions put inside a README file.

We need to display our game somewhere - this will be module that manages window and all of its properties. Not sure if we'll use X11 or Wayland - need research.

TBD:

• Check availability of Wayland/X11
  • X-Server
    • Xlib
    • XBC
  • Wayland
• Class
  • Skeleton
  • Proper class
• Window display
  • Creation / deletion
  • Fullscreen / windowed
  • Resizing
  • Title
• Player input capture
• Simple demo

Basic things to do:

• Main repository directory tree
• Solution and project files
• CMake files

Moreover, some TODOs to keep in mind:

• UTF16-to-UTF8 and 8-to-16 code in Window.hpp (should be in a common source file)
• OGL Context to create (depends whether it should be done in Renderer, or in Window - needs investigation)

Picking will be one of most crucial algorithms to implement. It will be used to update chunks by adding new voxels to the area.

Research: http://www.opengl-tutorial.org/miscellaneous/clicking-on-objects/picking-with-custom-ray-obb-function/

Create a proof of concept, because we don't know for shit yet, what we are doing...

Implementing VR requires some adjustments to Math and rendering engine:

• Add Quaternion class and base rotation-related calculations on it
• Optimize the renderer! We must be able to hit magical 90FPS limit when rendering in stereo
• Integrate Oculus 1.3 SDK

pragma once directives are not ISO-conformant. Remove all and replace with classic #ifdef ... #endif directives.

Macros should reflect file location on repostiory for uniqueness. For example, when a header is in Renderer/Common.hpp directory, create a block:

/**
 * typical boilerplate
 */

#ifndef __RENDERER_COMMON_HPP__
#define __RENDERER_COMMON_HPP__

// contents of header

#endif // __RENDERER_COMMON_HPP__

Renderer part with following features:

• Drawing whatever is provided to the renderer
• Handling any OGL-specific resource generation (VBs, IBs, shaders, etc)

Terrain Generator with following features:

• Terrain mesh generation from voxel cloud
• Efficient memory management
• MOAR MOAR (look at spreadsheet and rewrite here).

We are indeed bravely documenting the entire code, however none of this was generated.

What is needed:

• Doxygen configuration file
• Script which will call Doxygen and generate documentation of the entire project for us
• Fixes if during generation there are errors/warnings from Doxygen.

We need a way to measure FPS in our game. The problem is, we don't have (and probably won't have) any form of text rendering inside the game.

Our second best option would be printing the FPS value to console from current Timer object mFrameTimer (created as a part of GameManager), however this will flood our logs.

As a solution to this problem, create an AverageCounter class, which will measure an average FPS value and return it for printing inside GameManager.

Features:

• Average of last X values (ex. after inputting 300 values the class will return the value, not the best solution, but a good start point)
• Average from last X seconds (the class would have to measure 5 seconds with Timer and after 5 seconds it would return an average FPS count).

There will probably be some surprises along the way, so I suggest rethinking the task and, most importantly:

• Implement the class together with tests.

Terrain Manager is responsible for creating cloud of points via Perlin Noise Generator, storing them in vertexBuffer, maintaining its copy on HDD and forwarding vertexBuffer to the renderer.
It holds enum class with different cube types.

• Pre-work (after this point Map will be generated, but it will be slow/laggy/not-optimized-at-all):
  • Generating map chunk
  • Storing map chunk in vertexBuffer
  • Communication with Renderer
• Advanced features (speed up work for map; after this point the project should run smoothly and have a lot of free GPU for advanced renderer features):
  • Fast culling of invisible voxels
  • Greedy Meshing (should convert voxels into small number of triangles. Should be fast - it will be called often).
  • Multithreaded map generation (additional thread generating all chunks as needed)
  • Proper map chunk updating (when its needed)
  • Memory management improvements (keep some chunks in memory until they are not needed / player is too far away from them / there is not enough place for new chunks).
• Additional work, aka. bonuses:
  • Save/Load map chunk functions

A main class which will handle everything in the game.

Features:

• Handling entire game loop (below are in preferred order of update):
  • Gathering player input
  • Determining which chunks should be drawn
  • Rendering request from Voxel Renderer
• Keeping all other managers:
  • Window Manager
  • Terrain Manager
  • Renderer
• ...

• Add main Exception class that inherits from std::exception.
• Declare exceptions for all used classes

Right now Game Manager launches the game in default 800x600 window. This definitely needs to be changed.

Support following scenarios:

• Startup set resolution
  • Launching in different resolution (maybe command line arg --resolution/-r followed by two integer values? Lack of the argument would create a window with default 800x600)
  • Launching in fullscreen (--fullscreen/-f, launches in native )
• Dynamic switching when application is working
  • Switching to fullscreen (Alt+Enter is a default combination, so we should use it)
  • Resizing the window to new resolution by dragging its borders (it works on WindowManager part, but OpenGL does not resize it internally; new resolution values must go to glViewport function and to perspective matrix in shader, which might require minor reorganization in Renderer).

There is no easy way to test it, so we will skip tests for now.