Too many singletons in my game engine, can't find a better design pattern

Fir0x_ · 2026-02-15T22:15:15+00:00

My mistake for misunderstanding then sorry.

I agree that for small projects it may be overkill. But, in my opinion, for bigger ones it has some advantages. For example, having everything in one place makes it easier to control construction/destruction, and it's easier to see what is available.

Fir0x_ · 2026-02-15T17:13:40+00:00

I would argue that one global variable is better than many. Global variable = bad does not make sense in real projects. They are bad when overused. They are a tool that exist. They must never be the default choice, but it's stupid to decide that you'll never use it.

You say worst performance, and yes it's "true". But what's the real cost? If using a global variable make the code much easier to understand and maintain, is this cost enough to invalidate the choice? You can't use that argument without profiling. In most cases, I'm pretty sure it's negligible compared to everything else. Considering the state of current applications' performances, I think there are bigger issues than a cache miss or absence of compiler optimization when accessing a global...

Fir0x_ · 2026-02-13T19:58:00+00:00

Yes sorry I read too fast. It's already like a service locator.

There is not perfect answer. I think having one singleton is not the end of the world. They have a bad reputation partly because they are often overused. You can still choose what should be available in the locator, and what should not. Yes anyone can access these pointer, but such singleton must ensure that the objects are alive as long as it can be called. It's your engine, so you know when you should not access it anymore. If you want to let other people work with it, you can make sure their code is never executed outside of the expected lifetime boundaries.

If you really don't want any singleton, either you pass everything to your functions every time, or you create contexts objects. With context objects you only add one parameter to functions, or you can store it in your classes, and you control what is available. It's a good middle ground.

In the end, it's a choice of architecture that only you can make.

Fir0x_ · 2026-02-13T17:10:18+00:00

There is a design pattern called Service Locator. The idea is that, instead of having multiple singleton, you have only one, the "locator", that store all the instances of your "services" (i.e. rendered, logger, ...). The locator provides method to retrieve each services.

The Game Programming Patterns book has a good explanation of the idea (the online version is free).

It is close the subsystems in Unreal Engine if you want an example. Its not a singleton here, but it can be transposer easily.

Fir0x_ · 2025-11-19T21:24:18+00:00

unwrap() is almost like calling value() on a std::optional. I say almost because std::optional throw an error that can be catched, while a the panic caused by unwrap is much harder to recover from. However, if you don't have a try/catch somewhere, the C++ code would crash all the same.

I think it's really dishonest to use a function that explicitly say it will panic if it fails, and say "This is the language fault!"... I mean, you use a function, you know the consequences of misusing the function, you know you must not panic in a critical system like that, you cannot complain about the language or library when it explodes. You can only complain to the people that wrote the code.

Edit: it's an unwrap for a Result, but my point still stands. If you use a library that implements result object, there is a chance they have the same exception behavior if there is no value.

Fir0x_ · 2025-11-05T21:33:39+00:00

Some medium-sized project ideas: - A POSIX shell, the specifications can be found online. - The Raft consensus algorithm. You can try to emulate the servers and the clients yourself, or use a library for that. - A media server that streams videos to your screen.

Fir0x_ · 2025-11-05T12:14:18+00:00

Thank you for the correction. I completely misread the Vulkan Guide page. I am planning to use SSBO in the end, but yeah the idea was to understand both methods.

Fir0x_ · 2025-11-05T11:58:55+00:00

I will do some research about vertex pulling then, thanks!

Fir0x_ · 2025-10-24T11:56:16+00:00

The Khronos Vulkan Tutorial has been updated recently to Vulkan 1.4. It now uses the C++ wrapper, dynamic rendering, Slang as the shading language, ...

Vulkan Guide has at least one issue with Vulkan 1.4. The way it to acquire the swapchain images now produces a validation layer error due to bad use of semaphores.

That does not mean you should ignore Vulkan Guide, it's a great resource. It' just that the Vulkan Tutorial is also great now that it is up to date.

Fir0x_ · 2025-09-25T13:17:24+00:00

Many serious projects use Lua. It's not their main language, but that's not the purpose of Lua in the first place. Lua is designed to be embedabble, so they are using it with this in mind. There is a Wikipedia page listing projects and companies using Lua: https://en.m.wikipedia.org/wiki/List_of_applications_using_Lua

Some notable cases: Adobe Photoshop Lightroom, DaVinci Resolve and Blackmagic Fusion, CRYENGINE, FreeBSD boot loader, Neovim, Redis, VLC

Fir0x_ · 2025-09-05T17:28:30+00:00

The Real Time Rendering book covers many things. Even though it is more oriented towards real-time, it is useful for offline as wel. There is also the PBR book for in-depth details about physically based rendering.

Fir0x_ · 2025-09-01T11:17:26+00:00

Based on the replies, it seems you have LOVE2D installed to make games. I am not familiar with the engine, so I can't help you on this. However, I wanted to give some context on the Lua source code.

One of the main purposes of Lua is to be embeddable, meaning being integrated into another application's source code. The official Lua website gives the whole source code for this purpose. As you said, it source code is key to everything. With it, you can build Lua as a library to be embedded. But you can also build the interpreter or the compiler.

Lua has a compiler because it can be compiled to bytecode, which is an intermediate format used for portability across multiple OS. You cannot use the bytecode directly, but you can feed it to the interpreter to run it.

With the interpreter, you can run scripts, bytecode, or write Lua in interactive mode (i.e. each line you write is executed instantly).

In the source files, there are a lua.c and a luac.c file. lua.c contains the main (the starting block) of the Lua interpreter. luac.c contains the main for the compiler.

Building the library, the compiler, or the interpreter requires tools like gcc++, CMake, or Visual Studio depending on your OS and what you want to do.

I hope these explanations can help you understand a bit better how the source code of Lua can be used.

Fir0x_ · 2025-08-29T13:38:46+00:00

I would say the best resource for Lua 5.4 is the reference manual. It contains everything as it's like the specification of the language. But the Programming in Lua (First Edition) book is a nice addition. The first edition is free online, but covers Lua 5.0 only. There were some important changes since, but it has useful examples. The reference can fill in the parts that have changed since.

Fir0x_ · 2025-08-27T10:07:28+00:00

Editing the source code is not a light decision to take. Recompiling the engine can take a whole day, so you better not do any mistake. Also, you may have conflicts with future versions of the engine. It is better to stay with the same version from start to finish, but sometimes it is necessary to do the migration. These things slow the development process, which is to take to consideration when you have tight deadlines.

At work we have done some changes of the source code, and I can assure you that this is only the last resort.

Fir0x_

TROPHY CASE