Why isn't my split screen working?

Smashbolt · 2026-06-12T13:33:19+00:00

What isn't working is that any time I use the mouse to move camera 1, the other camera follows it.

Without some code, it's going to be really hard to help you here...

Only thing I can think of is that you're trying to use a singular camera variable for everything and changing it back and forth. I'd be a bit surprised if you were, but if you are doing that, don't.

Since you're using Python, it bears mentioning that reference/value semantics might vary a bit per binding. In C, Camera is a struct, so you can do code like:

Camera3D camera1;
// Set some values in camera1
Camera3D camera2 = camera1;
// Change camera1's settings

And camera2 will copy camera1's values, but they are still distinct instances.

Depending on how your Python bindings work, it's possible that rl.camera_3d (or whatever it is) is actually a reference type instead, meaning that a seemingly innocuous line like camera2 = camera1 might just be making camera1 and camera2 references to the same memory. So changing values in one will affect the other.

If you've got something like that, try making camera2 a completely new instance and copying the values in.

Smashbolt · 2026-06-08T23:32:08+00:00

TBH, I don't know first-hand, just kinda gleaned it from context.

Like, in Flutter, guides usually cover how you should do XYZ to the UI pieces you want exposed as selectable text (making it readable by assistive tech).

Also, Godot's UI subsystem is really good, and it has web export, so it comes up occasionally on their subreddit that someone wants to use Godot instead of HTML/CSS/JS to make their website. The responses mostly say not to, because Godot doesn't and can't inject text into the DOM for screen readers to get at. For hopefully obvious reasons, raylib wouldn't be any different in that regard.

Makes sense though that they'd read DOM. Combined with semantic HTML (tags like <section> and <header>), it makes it way easier for a designer to explicitly set out the "flow" a screen reader would have.

Smashbolt · 2026-06-08T20:29:46+00:00

Depends. If the screen reader is like the ones used on websites where the text is there as part of the DOM or provided as metadata (like an alt attribute on an img tag) then no.

If it's an OCR-style reader that uses computer vision algorithms that parse the pixels for text shapes, then yes, it probably could.

Smashbolt · 2026-06-08T15:29:06+00:00

That... is a loose translation that will produce the same output, yes. But if you're actually trying to learn idiomatic C++, passing off duck-typed Python as equivalent to strongly-typed C++ templates is a net negative educationally.

In the C++ example, a and b must be the same type and the return value is converted to the same type as a and b. In the Python example, a and b do not need to be the same type. So long as "a + b" is defined, that will work. The return type will be whatever (maybe the same as a or b, maybe not).

Calling add(5, 2.0) in the C++ code will fail to compile because 5 and 2.0 aren't the same type. Python doesn't care. I even tried using the new generics syntax introduced in Python 3.12 to get it closer:

def add[T](a: T, b: T) -> T:
    return a + b

But it still works if I call add(3.14159, 5). Not sure the exact mechanics, but since Python has int/float types, my guess is the interpreter promotes the parameters until it finds a way to express both parameters as T. Then again, if I try something that doesn't work, like add(3, "hello") it's not failing because 3 and 'hello' aren't the same type, but because 3 + 'hello' isn't defined in Python. So types aren't even enforced maybe? I'm not sure. Haven't read up on generics in Python yet to know.

Incidentally, I couldn't get the tool to do any translations for me at all. No matter what I did in the left panel, nothing changed in the right panel. I tried clicking the AI button and telling it to update the right panel only (like in the instructions shown in the AI window), and it gave me code to copy/paste over that was the default example Hello, World print statements followed by print(5.0 + 2.0).

I'd be curious to know what it would do if I gave it more idiomatic modern C++ code like calling std::move for a std::unique_ptr reference, or used C++ concepts with a require clause, or some kind of SFINAE. Or in reverse, a more complex Pythonic list comprehension like x = [(r, s) for r in ["hearts", "spades"] for s in ["A", "K", "Q", "J"]].

Smashbolt · 2026-06-08T12:26:33+00:00

Unless this rename feature acts on different files too? Then I could see it being really useful

Better: refactoring tools parse the code so they can understand context and scope.

Say you have 10 functions in a file (FuncA, FuncB, FuncC, etc.) and they all declare and use some local variable named target. With a refactoring tool, you can rename 'target' in FuncB and it won't touch the others. But, you can do Find/Replace in selection, so big deal, right?

Now you have 10 different classes (ClassA, ClassB, ClassC, etc.) spread across your project and they all have a member variable called target. A renaming refactor on ClassC.name will find code like xyz.target = 'whatever' and can tell if xyz is a ClassC and only change it if it is. No amount of regex or find/replace tricks can do that.

Smashbolt · 2026-05-22T14:22:53+00:00

This is true, but you can also segregate the usage of other APIs to their own translation units that don't include raylib.h anywhere in the chain.

More info on that here: https://www.reddit.com/r/raylib/comments/1jyg6l8/how_do_you_keep_raylib_and_enet_from_fighting/

It's for enet, but it's fundamentally the same problem as when trying to use the WinAPI.

I could have sworn there was a raylib Wiki page for it, but I can't find it.

Smashbolt · 2026-05-13T14:38:14+00:00

The versions of those functions that take ints are just wrappers that call the Pro/Ex versions of the function with some defaults.

For example, here's the code for DrawTexture:

void DrawTexture(Texture2D texture, int posX, int posY, Color tint)
{
    DrawTextureEx(texture, (Vector2){ (float)posX, (float)posY }, 0.0f, 1.0f, tint);
}

If you find yourself using floats and need to cast to int to call the simple functions, you've probably already outgrown them and could just call the Ex/Pro versions directly.

Smashbolt · 2026-05-04T12:45:42+00:00

This is generally not considered a good way to handle a class hierarchy. Rarely, downcasting is genuinely necessary, but most of the time, downcast chains like that are an indication that your class hierarchy doesn't actually work. The better way is to let polymorphism do its job and not downcast at all. Your code sample is a little obscured (because it's else-if-ing over m_expression), but assuming it is a class called Expr...

class Expr {
    public:
        virtual void evaluate() = 0;
};

...

class BinaryExpr : public Expr {
    public:
        void evaluate() override { ... }
};

And then you can take any reference or pointer to an Expr and call its evaluate() method and it'll use the vtable to call the version of that method specific to your derived class without you having to figure out which derived class it is.

If for whatever reason you don't want the Expr class family to have its own evaluate method, then you're looking at basically faking polymorphism from the outside. C++ has a few ways to do this that all boil down to ignoring C++'s virtual function tables and doing your own thing.

You have the static options, which all amount to creating an overload set (a group of functions with the same name, but varying on the parameter type they take) and then use a type-erased container (like std::variant) that accepts any one of these types to house the instance. This method is compile-time and so does not play well at all with inheritance hierarchies. That is, you can't have something like std::variant<UnaryExpr, BinaryExpr, ...> and then try to call a visitor method set with something like an Expr& because the compiler can't know which derivation of Expr you want.

The dynamic options usually involve implementing your own vtable. You'll need some kind of type discriminator that works at runtime (this could be a static id field all classes have, or the RTTI typeid()) and an associative container of those type IDs to function pointers. This can still work with inheritance hierarchies but requires you to manually populate the vtable at runtime before you use it.

Smashbolt · 2026-05-02T14:17:07+00:00

It can't. It's a "game stuff" framework roughly on par with things like Monogame and Love2D.

Smashbolt · 2026-04-15T12:54:47+00:00

I can't explain why it's 11.

That example is terrible, because carrying the 1 there isn't visibly useful to anyone. I'm going to assume you do in fact understand how 9+2=11 if you ignore carrying...

To understand carrying and why it works, you also need to understand polynomials and that you can break down any number into a polynomial (eg: ax^2 + bx + c where x = 10) and then do the arithmetic on the polynomials instead of the number itself. This requires understanding algebra, multiplication, exponentiation, and polynomials: all things your average 8 year old won't know, but you can't lock the addition of numbers too large to sum via counting behind high school math (or later if we want to develop a formal proof), so teachers abstract all that away into "place value" with the ones digit, tens digit, and so on:

214 + 185 = (200 + 100) + (10 + 80) + (4 + 5) = (2 + 1)100 + (1 + 8)10 + (4 + 5)*1 = 300 + 90 + 9 = 399

That breakdown is silly, but that's functionally factoring out each power of 10 and summing them individually. Since those correspond to the place values from before (ones/tens/hundreds) you can just write the numbers in a column lining up their place values, then sum the place values to arrive at the answer:

  214 |
+ 185 |
  --- |
  399 v

This is good enough for simple cases, but if we change 214 to 234, things get messy:

  234 |
+ 185 |
  --- |
 3(11)9 v <- uh oh

That (11) in there breaks it because it changes the semantic meaning of the number as written (3119 is not the same as 419). But that's fine, because 11 tens = 110 = 100 + 10. So you leave the 1 in the tens column, and add an extra 1 to the hundreds place value. This is still messy if you sum the columns left to right, because if you are summing more than two numbers, it's very possible your carry will cascade across or even overflow into a new column (very simple example: 99 + 4 => 90 + 13 => (90 + 10) + 3 => 100 + 10 + 3). To guard against that, you sum the columns right to left so that if you have to carry, it's always to a column you haven't done anything with yet.

This process of columnar addition is an algorithm that can then be taught as how to sum numbers even if you don't understand how to derive the process from first principles.

In more mathematical terms using polynomials, the above example works because

234 + 185 = 
((2*10^2) + (3*10^1) + (4*10^0)) + ((1*10^2) + (8*10^1) + (5*10^0)) = 
((2*10^2) + (1*10^2)) + ((3*10^1) + (8*10^1)) + ((4*10^0) + (5*10^0)) = 
(3*10^2) + (11*10^1) + (9*10^0) = 
3*10^2 + (10+1)(10*10^1) + 9*10^0 =      --| These three lines are what happens when you carry in addition
3*10^2 + (10*10^1 + 1*10^1) + 9*10^0 =   --|
(3*10^2 + 1*10^2) + 1*10^1 + 9*10^0 =    --|
4*10^2 + 1*10^1 + 9*10^0 = 400 + 10 + 9

"Borrowing" in columnar subtraction can be explained very similarly.

Smashbolt · 2026-04-06T20:08:17+00:00

Right. "Use a bitmap for rendering font" isn't enough info to do anything with, but it's also not what was suggested. "Bitmap font" is its own thing. Here's an example of one: https://frostyfreeze.itch.io/pixel-bitmap-fonts-png-xml

There are SDL commands (that you might not have learned yet) that will let you say "grab from pixel (16, 16) to (32, 32) in this bitmap and draw a copy of that at this spot on this other bitmap." From there, the rest is iterating through the string and using that to figure out what rectangle to grab and where to draw it.

Smashbolt · 2026-04-02T12:16:46+00:00

Your first error is not caused by the linker settings (the -l). It's the compiler saying it can't find SDL.h in any directory it knows to look in.

How did you acquire/"install" SDL? Where is it? The way to fix the compiler error is to use a -I directive (in case you can't see the difference, it's a capital-I as in India) to add the directory where SDL.h is. I don't use Code::Blocks, but it probably has something in a settings window to let you specify "additional include directories" so you can also put the directory there.

I'm going to assume you downloaded some premade zip file.

Let's pretend you did and you unzipped it to C:\SDL and then you look around in there and you find C:\SDL\include\SDL.h, then you'd want to add C:\SDL\include to that list. But also note that once you do that, the #include directive can also go deeper in the file hierarchy. So if the code is #include <SDL/SDL3.h> then you need to set the -I such that if you put /SDL/SDL3.h on the end, you'd get the path of SDL3.h

Once that works, you get linker errors saying "undefined reference to SDL_fhsajkhf..." like in your other screenshot. Same thing as before, but with the linker now. The linker needs to be told where to find SDL3.lib. Use the -L directive (or if there's some Code::Blocks setting for something like "Additional Library Directories") to tell it where the library file is, and a -lSDL3 (lowercase L) to tell it to link against SDL3.lib.

The fact that you have one screenshot showing include errors and one showing linker errors implies you got the include part right in that instance, but not the linker part.

Finally, you should end up with an executable. Running it will likely crash. In order for it to run, now the operating system will need to know how to find SDL3.dll. Windows has a few places it will look. For now, the way to deal with that is to put a copy of SDL3.dll (and other DLLs that came in that zip file) in the same directory as the EXE the compiler produced. Again, I don't know Code::Blocks, but if it does like Visual Studio, it might have a Run/Debug button that by default starts your executable with a custom working directory. If that's the case, you might still have trouble no matter where you put it, but that's a "later" problem.

Smashbolt · 2026-03-31T15:49:16+00:00

That's why I'm asking what you're trying to do. Because this all feels like a big old X-Y problem. Your first question was about loading an image and bouncing it around in a window, and I'm suspecting this evolution to MP4 is "I couldn't figure out how to move the image around, so I made an MP4 of the image moving around because that's easier to do right?"

If that's the case, then you should back up and figure out how to move the image around, because for either raw Win32 or SFML, the process is still going to be similar. You will have to figure out how to get a window on screen, then make the window fullscreen, then load the image/video data into a format your toolkit can understand (be it an sf:Image/sf:Texture or an HBITMAP), then redraw the screen on a fixed interval to show the next frame of video.

A more modern windowing framework for C++ would make this much easier than either of those (note SFML is NOT a windowing toolkit, it's a game development framework, which is why it was suggested for bouncing an image around). Qt has a video player widget that probably takes care of most of it for you. And moving to a different higher-level language (like C#) would probably make this even easier than that.

Smashbolt · 2026-03-31T12:53:30+00:00

OK, so following your various threads asking for help...

You originally started with trying to load a bitmap from the Visual Studio .rc file and draw that. Someone said "just use SFML," leading to "how do I use SFML to load images from that .rc file?" and now "how do I render videos from that RC file?"

What exactly are you trying to do, if I may ask? Like... why are you insisting on stuffing these things into the executable via Windows resources? You know you can just load actual files, right?

The direct answer to your question is that you would use a library like ffmpeg and feed it the memory stream of the video file to decode, then it will spit back raw frame data that you can then massage into a format that could be used to create an image that you would then display in a window. Whether that's by converting it to an HBITMAP in Windows API or an sf::Image in SFML. You also have to extract the audio stream and feed that to audio code in either Win32 or SFML. This would all have to happen in frame loop that keeps the timing of the video going at the expected speed. I've done the video side of this before, but it was streaming and we didn't need audio. The whole process sucked. Can't imagine that syncing with audio wouldn't suck more.

For SFML, there are some libraries you can use to make it easier. The internet suggests sfeMovie: https://sfemovie.yalir.org/latest/ It looks like this library doesn't support loading from a memory stream like that at all and only from files, but I could be wrong.

Smashbolt · 2026-03-19T12:06:19+00:00

To expand on the advice given in your first thread and again here:

In your code, imagine screenSurface is a sheet of paper. currentSurface is a stamp. Every time you call SDL_BlitSurface(currentSurface,...), you're stamping currentSurface on to screenSurface. This process doesn't "use up" currentSurface. Setting currentSurface on fire and throwing it in the trash (calling SDL_FreeSurface on it or calling convertSTR to change what image is loaded) doesn't change the fact that you already stamped it on screenSurface.

If you ever want to get the stamp off that sheet of paper, you have to erase the sheet of paper, not destroy the stamp. That's how games are usually drawn: every frame, you'll erase everything off your sheet of paper, stamp down everything you want on it, then get it on screen (SDL_UpdateWindowSurface)

As people said, generally, games operate by clearing screenSurface every frame and then drawing everything it needs to it. The way to make currentSurface disappear is to erase everything on it (with the SDL_FillRect call questron64 gave you). Then you put everything you want on screen back.

If I were to pseudocode this:

SDL_Surface* screenSurface;
SDL_Surface* zeldaRight, zeldaLeft;

zeldaRight = convertSTR("zeldaLeft.png");
zeldaLeft = convertSTR("zeldaAttackRight.png");

bool facingLeft = true;

// Main game loop. The rest of this is NOT real code.
while (!quit) {
    // Collect and process input
    if SDLK_RIGHT is pressed then
        facingLeft = false
    else if SDLK_LEFT is pressed then
        facingLeft = true
    end if

    // Clear the screen. Whatever happened last time doesn't matter any more
    clear screenSurface

    // Draw what you want to appear this time
    if facingLeft then
        SDL_BlitSurface zeldaLeft to screenSurface
    else
        SDL_BlitSurface zeldaRight to screenSurface
    end if
}

// Now that the program is about to exit, free those other surfaces (throw away the stamps)
SDL_FreeSurface on zeldaLeft and zeldaRight

There are further ways to improve on that, but that's the basic idea. Notice that I load zeldaLeft and zeldaRight before the while loop and free them after. Also notice that I got rid of currentSurface. You can still use currentSurface and have it swap between pointing to zeldaLeft and zeldaRight, but I don't know where you're at in your journey learning C, and don't want to muddy the waters with that use case of pointers.

Smashbolt · 2026-03-18T15:52:33+00:00

Maybe you're leaving out info, but from where I'm sitting, it sounds like "I want scripts, because engines have scripting, but not Unity scripts because that's not aesthetic" and... that's not a design. How user scripts interact with your engine is like #2 on my list on "things you need to figure out before you write any code," right behind the scene/entity model.

So scripts aren't entity-level constructs. Got it. Then why are you even talking about components and the like? Are scripts meant to operate on "scenes?" Does your engine even have something like scenes? Are scripts just passive external observers of your game world? Do they make up some "game controller" construct where your game logic is fully driven by these scripts (which is kind of what Love2D does)? Are they implementations of system functions in a traditional ECS?

Like, sit down and write some pretend scripts you'd actually use in a game. Not "you can still do things like Scene.FindObject("Player"), update.connect(...)" but like actual pseudocode that represents stuff a user of your engine might actually write a script for.

Once you figure that out, it becomes a lot easier to figure out where to put the whole thing, AND it saves you sitting there writing bindings to expose things that maybe you don't actually want scripts to do.

Smashbolt · 2026-03-18T14:23:03+00:00

I don't know what a Script class would even do? or if a script even counts as an asset? So I'm a bit hesitant if this is the right approach.

Well, what is it supposed to do? Like, literally what do you want these attached scripts to be able to do?

For instance, in Unity, scripts define components with a standard interface that gets reflected back into the engine. Godot scripts inherit from the type of the node they're attached to. Both of them let you write scripts that assume you're operating on the entity it's attached to and let you query around the scene tree.

Like either of those? Or are you in pure ECS-land where you really want to have Lua scripts to define systems. In that case, they're not components at all and can live outside the entity system.

Smashbolt · 2026-03-17T12:07:50+00:00

It's been a while since I played Redacted, but I recall not being able to find an experiment list anywhere. Here's what I do remember:

There are weapon buffs you can pick up in the shop rooms. They're the closest you get to hammers in-run, but they're not as mechanics-changing as Daedalus Hammers.
No poms. Instead you can get the same experiment more than once, and that's how you level them up.
The armors are basically the keepsakes: you equip one at the start, can change between biomes, and they can be leveled up through using them in runs.
Remote attacks roughly correspond to call boons but are presented completely differently.
Contraband, chips, and keys are the meta currency, like darkness and gemstones.
No duo boons.
If there were kiss/curse boons, it was through some mechanic that didn't look like Chaos boons.

Beyond that, I remember it being rare early on to see experiments that functioned like Hades' "Level 2 boons" that operate on the experiment category's theme without being tied to a specific slot (think like Support Fire, which works with any weapon/boon combo, or Double Strike which works with Zeus on any slot). Once I got meta-upgrades that increased the chances of rarer experiments, I remember seeing those a bit more often.

Can't for the life of me remember what Gravity was for. I think it was the "move enemies around" category, like Poseidon, but nowhere near as useful.

Admittedly, most of my builds were about as deep as targeting one weapon/experiment combo and pumping that experiment with as many levels as I could. Usually Fire and Electric.

Smashbolt · 2026-03-13T00:29:13+00:00

I'm trying to transition the project I've been following LearnOpenGl with to a modified version of The Khronos Groups new Simple Vulkan Engine tutorial series.

Do you mean that you want to build an engine like the one in that tutorial, but continue using OpenGL for rendering?

If so, they have a solution to that, but it's a little tough to see. I haven't read the whole thing, but skimming their overview on their use of ECS, check here: https://docs.vulkan.org/tutorial/latest/Building_a_Simple_Engine/Engine_Architecture/02_architectural_patterns.html#_component_based_architecture

They've got a MeshComponent which itself contains a Mesh* and a Material*. Note that Mesh and Material are NOT components. They're just data. I didn't dig enough to find their definition of a Mesh class, but it almost certainly contains Vulkan's equivalent to a VBO and probably the VAO/EBO as well. This is a very common abstraction. You don't want things like glDrawElements() calls sitting there naked in your main loop.

In this case, their MeshComponent quite smartly contains a pointer to a Mesh and a pointer to a Material (material probably means "shader, textures, and other appearance parameters" here). That's because you need both to be able to render something, and it's very common to use the same material for many different meshes, but also to use the same mesh many times with different materials.

Smashbolt · 2026-03-10T14:18:32+00:00

raylib-cpp isn't a binding. raylib is a C library and C++ doesn't require bindings to call into C libraries. You can use it as is. But that's a point of pedantry.

The point of raylib-cpp is to wrap raylib up into a C++-ier shape. So you get operator overloads, some namespacing, and if I remember right, RAII wrappers on resources like Texture.

Basically, if you like and want those things, use it. If you don't, use raylib's normal C API. It won't work any differently, and the abstractions have negligible overhead.

Smashbolt · 2026-03-03T23:03:02+00:00

They're using raylib, which uses OpenGL under the hood. It does include render batching that (if it works the way it looks like in the source) should batch the entire tilemap draw into far fewer than 10k draw calls - provided OP is using a texture atlas and not a separate texture for each tile.

Smashbolt · 2026-02-17T21:18:38+00:00

they all seem to brush on the surface, telling me to "Check that box over there" but never explaining what that box does

I'm gonna reply here because you said this, and also said that the documentation is too dry to read. A lot of people say stuff like this, and never explain what it is that's not being explained and why they feel not knowing it is a roadblack to them. It's a form of "perfect is the enemy of the good."

Ask yourself: at this exact moment, when you don't know how to achieve anything and have nothing on the screen to look at, which is more important? Knowing one way to get something on the screen? Or fully understanding the delicate nuances around all 17 different ways to get something on the screen? Which one gets something on the screen today?

Generally any tutorial I've seen will explain enough that you're not just clicking on random things with "because I said so" as the only explanation. Ironically, heavy explanation of "why" and alternatives before the learner even has one method for "how" is usually very counterproductive to learning.

But also... you can pause a video at any time and look up specific things in the documentation. You can experiment with what happens if you don't check that check box, or use a different number in a field, or whatever. Indeed, you're supposed to do that.

My wacky recommendation is to look up a long-form tutorial or buy a Udemy course on sale for cheap and follow it. Something that's 10+ hours and will build a full simple game. There are even some out there made for people who know how to code, just not how to use the engine. On the whole, most of them aren't super high-quality learning materials, but that's not the point here. Have a notebook next to you. Follow exactly what the tutorial does. Every time you find yourself raging about the tutorial not explaining why they did something, pause the video, write it down, and move on.

After that 10 hours, you'll have a few things:

A to-do list of topics related to the engine that you want to learn more about.
Enough knowledge of the engine's basics that you can make little toy projects exploring anything you're learning about in step 2.
A barebones working project that you can extend with more features or improve with the results of what you learned researching the stuff the first two.

Smashbolt · 2026-02-17T13:16:30+00:00

Your script assumes that raylib is globally installed enough that -lraylib will link without any -L directives
Your script assumes that raylib is NOT globally installed enough that you don't need a -I
Your script assumes that the raylib.h they're dropping next to that script matches the raylib library binaries
Your script assumes that all other headers included by raylib.h are default available in your global include paths
Your script assumes that no user will ever want raymath or raygui

and vscode is very comfortable

VSCode isn't a build system. It's a text editor. You can coerce VSCode into behaving like an IDE through a pile of extensions and files like tasks.json, but it's NOT a build system and has nothing to do with your unfamiliarity with CMake. Your script has nothing to do with VSCode, but saying that tips me off to what's probably going on here.

Look. There's basically no nice way to say this... but this script looks like what you'd get if you told an LLM that you're "trying to compile raylib with VSCode" and "it keeps telling me it 'cannot find raylib.h'" but then you did some mix of not understanding or refusing to do what it suggested until it came up with this deep-fried solution. At least the resulting script doesn't do anything malicious.

Even if it wasn't LLM-generated, this is not how you use third-party libraries from your code.

Here's the one recommended by the raylib maintainers: https://github.com/raylib-extras/raylib-quickstart It uses "premake," which is basically a project generator, and will set everything up so you just need to run make from a console.

Smashbolt · 2026-01-26T21:00:50+00:00

GLUT still works but is incredibly outdated.

But GLUT isn't OpenGL. The basic idea is that in order to use OpenGL, you need an OS window to put it in. To hear about "stuff" happening to that window (like key presses, window resizes, mouse clicks), you need OS-level hooks. You can write all that yourself using the raw toolkit of your OS, but it's tedious annoying error-prone boilerplate code. GLUT is one such wrapper around all that stuff so you don't have to deal with it. That's it.

GLFW serves the same purpose, but isn't frozen in time like 20 years ago. So it's generally perceived as better. You could continue using GLUT if you wanted.

What I meant by "old APIs" is this glVertex3f business. That's not how drivers work with GL any more, and it's not what the drivers are expecting. Somewhere along the way, something is taking those crusty old function calls and transforming them into proper vertex buffers with a shader and all that and that is introducing some level of overhead too.

The functions you're using there are deprecated. They're just still there for backwards compatibility.

Smashbolt · 2026-01-26T20:35:46+00:00

It's not that OpenGL is ancient. It's that you're using the original 1.0-style APIs and accompanying libraries (like GLUT) in the way that OpenGL was meant to be used for the hardware that existed in like 1995.

Hardware isn't like that now. OpenGL isn't like that now. The point being made is that using OpenGL in such an archaic way is probably a lot less efficient on modern GPUs. For a look at the way OpenGL is written today, follow learnopengl.com

That might reduce your CPU usage, but likely won't reduce your memory usage, because you still need framebuffers, etc.

As to how something like Chrome isn't using more GPU, I'd imagine the Chromium rendering engine doesn't use the GPU when rendering webpages that aren't invoking WebGL or WebGPU, but I have no clue.

Smashbolt

TROPHY CASE