DEV Community: Beau

Being too ambitious

Beau — Wed, 24 Feb 2021 19:42:38 +0000

I willing to bet any developer who's been developing for longer than a few minutes has experienced something like this cycle:

Come up with new project idea
Get really excited about new project
Start working immediately, little to no planning
Work for a few days or weeks and get a lot done
Realize scope of project way too late
Try to put too many features in to meet expectations
Burn out, start to work much less
Go back to step 1

It's hard to avoid sometimes, a new project can be very exciting and you want to start making progress immediately. The problem is that sometimes it's difficult to realize how involved a project is going to be until you're already into it.

This happened to me recently with my graphics library, Nyx/Baphomet/Eos/Nyx. You'll notice there are 3 names there, 1 of them repeated because I went back to it, and that's because I started and restarted the project 4 separate times because of this cycle. Each time I'd start over I thought I'd solved the issue of why feature X was just not good enough, and I'd jump right back in and do the same thing again.

This last time, I decided to step back and examine why exactly I was failing each time. It's not that my code wasn't working, it did, and it worked well, I just always felt something was wrong with it once I got any substantial amount of functionality in. One time I even made it as far as making a basic Minesweeper clone to test it out, and still something felt off. I finally realized that the issue was the scope of the project, how much I wanted it to be able to do, and how calling it a "graphics library" wasn't even accurate at that point.

I wanted whatever-you-want-to-call-it-this-time to be capable of these things in no particular order:

OpenGL abstraction
Drawing primitives--points, lines, triangles, rectangles, ovals, etc
Drawing textures--static and animated
Window management
Keyboard/mouse/gamepad input--extra game-like features for these too
Sound/music
Particle systems
Timers
Tweening

Probably other things I'm forgetting...

Point is, it wasn't feasible. I'm a single person who hasn't even graduated college yet (almost, 2 more months), much less worked on a project with a scope that large. Each time I'd make it as far as managing the window, abstracting parts of OpenGL--though never as much as I wanted--events, timers, drawing primitives, sometimes textures, and then...nothing. I'd look at what I made and hate it. I'd think about how it's missing a specific feature, or you couldn't initialize a type in a convenient way, or whatever, and not know what to do.

Each time I restarted I'd use some of the code I wrote from the previous attempt. I figured that for some parts there was no reason to completely rewrite it--things like a utility file to get random numbers, or the timer class that didn't have any real dependencies. These things were portable enough that I felt like I could reuse them.

As you can tell from the list, calling it a "graphics library" is a bit misleading. Yes, it was definitely capable of that, but in all reality it had a graphics library buried under a lot of game development features. If someone wants to make a game, they're probably going to just use Unity or GameMaker or something already existing that's more mature, has examples, and can do a lot more. I was struggling to see the forest for the trees, and getting blinded by my own goals somehow at the same time.

Rather than trying again and hoping I somehow fix the problem, I'm going to go for a different approach. This time, I'll be focusing primarily on only a single goal in the list: abstracting OpenGL. While working on this project, I actually considered using Python instead of C++ because of a really nice library I found called moderngl. It abstracts the low level OpenGL concepts into much nicer to use pieces, and I realized quickly how useful something like that could be in C++. One of the big questions I kept asking myself while developing was "how can I implement feature X if I don't really want to use it myself but someone else might. How can I plan for that?" The answer is that realistically, by yourself, you can't.

And that's okay! Trying to please everyone isn't possible, you'll eventually have to make decisions and live with them, and if whatever you make isn't a good fit for another developer, then they'll just have to move on. Unfortunately that's just life.

Starting today I'll be working on a new project, hlGL - High Level OpenGL. The goal will be to create a library with a similar feel to moderngl, but in C++. I can still use some of the code from the previous graphics library/game engine/whatever as well.

Even better, the original goal isn't out of the question, it'll just be more than a single piece. hlGL should be useable as a dependency on its own to make something higher level still, and that can be a goal for the future. For now, I need to keep my goals lower so they're attainable.

Nyx: How to make a game loop

Beau — Wed, 20 Jan 2021 20:29:07 +0000

Design blog!

Whenever you create a program, you had to do some level of designing when you first started. This could have been small, like in the case of a throwaway script, or it could be much larger, like in the case of designing an entire library. This post is going to be looking into the design of Nyx, namely where the previous attempt, Aurora, failed, and what I've done with Nyx to--in my opinion at least--fix it.

SDL style

Aurora had a major flaw in that it put zero restriction on the structure of the program that was written. This was actually something I considered a feature of the library at the time: you could write your program however you want, and you'd insert the graphical stuff wherever it happened to need to go and be done with it. Unfortunately, in practice, this led to some pretty awkward things to deal with.

A lot of this stemmed from me unintentionally pulling from what I'd used in the past. The main library I used whenever I needed graphics was SDL2. SDL is great, I talked about that in the "libraries" article, but it has a lot of boilerplate code you are effectively required to put in place. For example, here's just opening a window in SDL2 (minus some initialization code):

#include <SDL2/SDL.h>

int main(int, char *[]) {
  /* initialize the window and renderer */

  bool running = true;
  SDL_Event e;
  do {
    while (SDL_PollEvent(&e)) {
      switch (e.type) {
      case SDL_QUIT:
        running = false;
        break;
      }
    }

    /* update game state */

    SDL_RenderClear(/* ... */);

    /* draw stuff */

    SDL_RenderPresent(/* ... */);
  } while (running);

  SDL_Quit();
}

SDL is first and foremost a C library, and you can see that in the coding style. Everything is procedural, and it's up to you to call everything in the right order. Some things can be mixed around, but not much.

Now here's that same thing in Aurora:

#include "aurora/aurora.h"

int main(int, char *[]) {
  auto engine = aurora::Engine({"Example", {800, 600}});

  do {
    engine.update();

    /* update game state */

    engine.window->clear();

    /* draw stuff */

    engine.window->flip();
  } while (engine.is_running);
}

Sure, it's shorter, but you can see the parallels between the two snippets of code. Open your window, then start your game loop. Within the game loop, run your events through, clear the window, draw, then flip. Check your exit condition, and either stop or continue. There's nothing wrong with this loop, and in fact basically every game library in existence--no I did not fact check this--likely works in a similar way. Why, though, is it up to the user to code that in? If it's the same every time, you just have boilerplate, and that's not reasonable.

LÖVE

Some libraries don't work this way, and take a more structured approach. LÖVE is a great example of this--being still pretty low level in terms of what the programmer is responsible for, but taking that boilerplate part of the code out of the equation. To make an application in LÖVE, your code will look something like this:

function love.load()
  -- initialization code
end

function love.update()
  -- update game state
end

function love.draw()
  -- draw stuff
end

There are the 3 main callback functions in a LÖVE program, and they allow you to do quite a lot. They are called in a loop similar to this:

love.load()
while game is running:
  love.update()
  love.draw()

The callback way of doing things keeps the focus on the content of the functions, rather than how they're structured in the code. Even better, it doesn't need to be rewritten every time, and and the library developers don't need to add in some new thing to update backend structures that the user has to call: they'll just add it to their existing game loop. This is less cognitive load on the developer, and requires less knowledge of the backend of the library--something that arguably you shouldn't need to know about especially for simple programs.

Nyx

I drew inspiration from LÖVE heavily for how I implemented the game loop--taking into consideration, of course, that C++ is a very different language with a different way of making programs. Here's that same example as above where a window is opened and simply cleared and flipped until the user closes it:

#include "nyx.hpp"

class Example : public nyx::App {
 public:
  Example(nyx::AppCfg const &cfg) : nyx::App(cfg) {};
  ~Example() = default;

  void update(double time, double delta) { 
    /* update game state */ 
  }

  void draw() {
    clear_window();
  }
};

int main(int, char *[]) {
  Example({"Example", {800, 600}}).mainloop();

  return 0;
}

Admittedly, there's a lot going on here, but that's mostly because of C++ boilerplate, not because of the library itself. To create an application in Nyx, the App class is overridden, and at least the void draw() function must be implemented. The void update(double time, double delta) function is optional if you don't need it for some reason, but I showed it here to show that it exists. mainloop does a lot behind the scenes, but effectively boils down to doing event handling and assorted update functions, calling your update function, drawing the screen, then presenting it automatically. You also inherit some functions like clear_window than can be used in your draw loop or elsewhere that are needed for full functionality. This removes the need for the user to have to manually structure their program, as a structure is enforced this way.

You may argue that the way I've done this adds in its own boilerplate code, and to some degree I'd agree with you. Overriding a class in C++ isn't that short, and it is somewhat annoying that there's no way to really get around this without doing some GL3W style function callbacks. Working a few different ideas, I think this is the best balance between solving the issue I described with manually creating a game loop, and also having it still be relatively convenient to use. In a larger program, the extra code associated with this method is negligible.

Final remarks

Lack of structure plagued Aurora from all sides, but I'm not allowing those same mistakes to happen again with Nyx. I want an easy to grok, understandable structure in all programs written with the library--allowing me to add as much extra functionality as I want behind the scenes. In another post I'll go into what those behind the scenes things are. Soon I'll make a post about "stickies", which are mostly meant for debugging but have been incredibly valuable for development.

Nyx is coming along quite well--primitives are almost implemented--and then I'll be starting on implementing more and more drawing functionality. Stay tuned!

Nyx: 3rd party libraries

Beau — Wed, 13 Jan 2021 18:35:07 +0000

Don't reinvent the wheel

This is already a somewhat hypocritical statement as I've already mentioned that there are many existing libraries that are great for graphics in C++, but it really is true in most cases.

Do not reinvent the wheel, you will likely do it worse than those who came before you.

Obviously I have some level of hubris here in that I think I can do better than what's out there, but that's okay! What I'm referring to here is that it's okay to take advantage of the work of others (with permission, of course), especially when you're doing something as complicated as a whole framework. There are many things that I do not want to write myself, and I have employed libraries where appropriate.

SDL2 [link]

As much as I was talking down to SDL2, it actually makes a great windowing library. I won't use anything out of it that actually draws things onto the screen, but it's great for creating a window and getting an OpenGL context ready. The event handling is also pretty good--it's a very C-ish idiom, but polling events to me is way nicer than using callbacks--and it'll even enable me to add gamepad support in the future if I really want to.

Glad [link]

You have to have an OpenGL context open to do anything, and that's where Glad comes in. For those unaware, OpenGL has two major profiles, compatibility and core. The compatibility profile is deprecated since 2008/9 and should not be used, but is there so old software doesn't break. Unfortunately, when we make an OpenGL context, it only actually loads compatibility functions, so we need an OpenGL loader to load the new things for us. That's where Glad comes in, it loads those functions after we've created our context. There are a lot of loaders, none of them are really good or bad, they just sort of are. The one thing I don't like about Glad is that I don't know how to use it with CMake, but I wrote a script to update dependencies like Glad that don't work with the rest of my system.

ImGui [link]

ImGui is definitely more a nicety than a necessity, but it'll allow for adding in text onto the screen before I'm able to draw it with the library. It's great for quick tests if you want to be able to interact with what you've made, and I'd highly recommend it.

{fmt} [link]

fmt is the definition of extraneous, but it's so nice that I can't not use it. It's an I/O library that is actually an implementation of things that are going to be added into C++20. C++20 is a bit too new for me to feel comfortable putting my project on it yet, but using fmt for now is much nicer than the fresh hell that is iostream.

fmt::print("Isn't this nice?\n");

stduuid [link]

I use UUIDs on the timers, so I needed a way to generate them. I could do it myself--but we're trying to not reinvent the whole wheel only some it.

stb [link]

The stb headers are great, they're single file units that each do some specific thing--in this case I use the ones for reading and writing images to disk. Great libraries, never done me wrong, I recommend them.

glm [link]

You need matrices to deal with anything in code OpenGL, and I'm not going to write that library myself. glm is a mature library for dealing with all the matrices and vectors that you have to use, including building projection matrices, and they are also very easily upload-able into vertex buffers. Neat!

Wrap up

That's all the 3rd party stuff that Nyx is using for now. If I add more libraries in the future I'll add them here.

Nyx: A Graphics Library for C++

Beau — Wed, 13 Jan 2021 18:10:35 +0000

Ugh, how many of these do we need?

I'm tired of using the same old graphics libraries in C++. I want something simple, something as easy to use as LÖVE or Pyglet. I could use these in their respective languages but I quite honestly just like the speed of C++. Also, modern C++ isn't nearly as painful to use as I think some of us may have learned in school (aka doing C with classes).

A lot of the existing libraries that are out there aren't really C++ at all, but simply C. These are fine if you're coding in C, but they tend to be unnatural and clunky when it comes to C++. A good example would be SDL2: totally functional, but dated naming conventions and a less than stellar build process (I just want CMake support!).

Some of those libraries are also pretty feature incomplete, in my opinion. Ragging on SDL2 again, why are basic primitives not really a thing it supports? To be fair, primitives are mostly used in the early stages of the development process, not in a final product, but why not have them available anyway? It doesn't make much sense to me. Yes, you can use SDL2_gfx, but I feel like it should be something the base library has included.

That's why I've decided to start my own graphics library instead, taking advantage of everything I can to make it a one-stop-shop for your graphics (and some game development) needs.

Okay but like have you considered X?

Probably! I've tried out many different things over the years, none of them come even close to the simplicity of libraries you find in higher level languages. I don't see why they can't, and I'm tired of waiting for someone to make it for me. Plus, this is just a great project to put on my resume given that I do have an actual interest in engine development as a career.

That said, I haven't tried everything, if you really would like me to check out some other library, I'll probably at least take a cursory glance at its git repo.

Introducing: Nyx

Nyx is the name of a graphics library that I'm currently developing. There isn't any particular inspiration behind the name, it's just really short, which makes it nice for a namespace, and mythology is cool.

For now, it's in a private repo until I think it's at least useable for something. As of now, it's quite literally useless as it basically just opens a screen and can draw an FPS counter and memory usage indicator on the top. This isn't nothing, and there's actually quite a bit of code to handle some events and everything as well, but I'll make another post for those.

This is actually a rewrite of a project I had been working on for a while--that's why there's that seemingly random functionality in there already, it's just copied over. I have a scrapped project called Aurora that had the exact same goal, but I hit a wall when I realized I had structured it pretty poorly. The way the library was set up, certain things were hard to access, or all had to go through a central object I called "Engine". This was all well and good but added a lot of unnecessary noise to the code. Then, I remembered how LÖVE does it. I'll discuss what happened there in the next article.

Anyway, this was just a quick intro post. I'm hoping to document the process as I go along, don't expect 100% consistency with me writing these, but it shouldn't be terribly slow either. I tend to try and get a little something done on it every day, though I likely won't write an article every day, that feels a bit excessive. If somehow this gets popular, I'll consider doing live coding streams, that's always seemed like a fun idea to me, though I'm not sure how exciting it would be to watch me do it. :)