cjdb / doge Goto Github PK

The HID interface currently uses init functions to establish a relationship between the run-time and the devices being interfaced with. This is both expensive (users who don't use the keyboard still need to pay for it), and terrible style.

They need to be replaced with constructors, but I can't figure out how to properly do it for these two interfaces.

Vertex array objects are important for rendering objects on-screen. At present, the VAO abstractions are workable, but not elegant.

Completed pre-issue logging. Added for tracking only.

The current project requires programmers to manually download all external dependencies. This is unacceptable for a useful project.

The current CMake files are out-of-date (possibly pre-CMake 3.3?). They should be updated so that they take advantage of the new CMake 3.11 features.

uniform should be able to support contiguous ranges, such as uniform<array<T, N>> and uniform<vector<T>>.

Adding support for arrays should be trivial; adding safe support for vectors in OpenGL 4.3 will be tricky.

Support for the following operators (where semantically valid):

• a &= b, a & b
• a |= b, a | b
• a ^= b, a ^ b
• !a, ~a
• a >>= b, a >> b
• a <<= b, a << b

Completed pre-issue logging. Added for tracking only.

doge currently relies on GLFW3. This is not guaranteed for the future, so it is important that all GLFW3 details are replaced with doge equivalents.

Completed pre-issue logging. Added for tracking only.

Completed pre-issue logging. Added for tracking only.

Completed pre-issue logging. Added for tracking only.

Element buffers are important for rendering objects with overlapping vertices. Current support for them is workable, but not ideal.

There is a serious lack of documentation in this project. Adding documentation will be a boon for future use.

Pre-GCC 8 doge implementations cannot use the Filesystem library due to an internal compiler error crashing on even the simplest programs that mix the Filesystem library and the Ranges TS reference implementation (see GCC bug 84139). This appears to have been fixed in

The current intention is to change path types from std::string to std::filesystem::path (aliased, of course), when GCC trunk is tagged as gcc_8_1_0, and can be built for MinGW-w64. As doge does not currently have a notion of backwards-compatibility, the abandonment of GCC 7 is a non-issue.

Jason Turner recently challenged C++ programmers to construe the least-efficient program they could, using string, string_view, filesystem::path, char const*, and implicit conversions on Twitter. I did not participate in his challenge, although I remarked that it would be a good idea to investigate whether blindly switching from string to filesystem::path is a good idea. This investigation hasn't happened yet, and it must occur before any pull requests with filesystem::path are accepted.

The project is migrating from west-const (const auto) to east-const (auto const). This will mostly be a clean-up-as-you-touch-the-file process, but it will also be a good first issue.

Turn on -fstrict-aliasing -Wstrict-aliasing.

The use of GLM is an implementation detail; not something that the user should concern themselves with. If the project changes its maths library, or it implements its own, the user should remain largely unaffected (except for possibly needing to install a new dependency).

Most of the types are defined in include/doge/types.hpp, but they are rarely used. It would be great if all uses of glm::* were confined to the internal workings of doge, and the external interface was reflected as doge::* instead.