|
Orrery
A GPU-accelerated N-body gravitational simulator
|
A window with an OpenGL context, and the controls that drive the camera. More...
#include <cstddef>#include <memory>#include <string>#include "orrery/viz/camera.hpp"#include "orrery/viz/gl_api.hpp"Go to the source code of this file.
Classes | |
| struct | orrery::viz::WindowOptions |
| How the window is created. More... | |
| class | orrery::viz::ViewerWindow |
| A window, its context, and an orbit camera the mouse drives. More... | |
Enumerations | |
| enum class | orrery::viz::Key : std::uint8_t { kQuit , kPause , kBrighter , kDarker , kReset , kCapture } |
| The keys the viewer asks about. More... | |
A window with an OpenGL context, and the controls that drive the camera.
This is the only file in the project that knows a window system exists, and it exposes none of it. No GLFW type appears here: the window hands out a function that resolves OpenGL entry points, its own size, a camera the mouse has already moved, and the answer to a short list of questions about keys. Everything else stays in the implementation.
That boundary is worth the small amount of translation it costs. The renderer beneath it is a class that draws into whatever context is current, and the viewer above it is a loop; neither has any reason to see a GLFWwindow*, and once one of them does, the choice of window library has reached into the rest of the program.
A window can be created invisible, which is how the offline export gets a context without putting anything on the screen. It is not a headless context: there is a window, the compositor simply never shows it. A genuinely headless context needs a platform-specific path on each of the three platforms, and this project's export is something a person runs on a machine they are sitting at.
|
strong |
The keys the viewer asks about.
An enumeration rather than character codes, so that the mapping to whatever the window library calls them lives in one function in the implementation.