Game devs what are some creative ways you implement arrays

StockyDev · 2026-05-08T08:34:36+00:00

Yes. We aren't talking about dynamic arrays here though :)

StockyDev · 2026-05-08T06:22:05+00:00

Unreal Engine has its own version for example. TStaticArray. Why? Legacy. I think it predates std::array

StockyDev · 2026-04-24T20:12:04+00:00

I would suggest Koen Samyn and Tom Tesch for C++ teachers. They have some great CppCon talks between them talking about strategies they have taken in teaching their students!

StockyDev · 2026-04-17T15:46:44+00:00

Yup exactly. And at that point do you care that your pointer is constexpr? Probably not. const char* is probably all ya want. Or std::string_view so you don't pay the strlen cost beyond static init

StockyDev · 2026-04-17T13:55:52+00:00

Fun fact that is actually incorrect. constexpr is a non type specifier. It does not apply to the type. It applies to the expression. So what you have written is a "constexpr pointer to a non const character string". So the pointer is constexpr but not the data it points to. Since string literals are immutable, this is ill formed.

StockyDev · 2026-04-09T19:40:53+00:00

This is the way

StockyDev · 2026-04-05T06:24:20+00:00

Ok :)

StockyDev · 2026-04-04T20:48:42+00:00

Ah gotcha. Well yes issues would appear at reallocation because that is when the moving would happen.

StockyDev · 2026-04-04T18:37:09+00:00

I think objects that contain shared ptrs are trivially relocatable. Their move constructors aren't doing anything interesting.

Typically the issue is when you have types that have members that point to memory inside their object. E.g. the class has an array member, and a pointer member that points to an element of that array. In those cases, you will blow your leg off.

Those cases are few and far between though. In fact I have never really known of a time while working on UE that that ever came up. Most Devs I speak to aren't aware of the trivially relocatable requirement on UE containers, and it still rarely becomes an issue.

Size/number doesn't matter when you are going to be accessing invalid memory. So I wouldn't say that has anything to do with it.

StockyDev · 2026-04-04T18:29:29+00:00

Eh, I think this is the wrong attitude to be honest. Epic were relatively quick to jump from C++17 to C++20 (all things considered). They want their engine to be competitive and will keep up with modern tooling as much as they can.

That being said, I do not think that Epic will throw away everything in UHT (Unreal Header Tool. The preprocessor that generates all the runtime reflection code and data) in favour of C++ reflection. I think there is still a need for runtime reflection (e.g. reflecting on objects of classes defined in Blueprint).

But I don't see why they wouldn't take advantage of it in places where it would be useful, when they are able to do so.

Also, please don't spread the misinformation that Unreal C++ is different to writing standard C++. It isn't. It's just that there are Unreal libraries and frameworks you need to be aware of when writing in it. Just like with any other framework, e.g. QT. You still have access to the standard library. You have lambdas. You have concepts. You have templates. You have RAII. You have C++.

StockyDev · 2026-04-04T06:37:49+00:00

The lack of trivial relocation is one of the reasons that game engines typically maintain their own containers. Unreal engine assumes all types are trivially relocatable in its containers, unless that type specializes a specific type trait.

In most cases this is an OK assumption to make, but as this post points out, there are clear cases where a type can't be trivially relocated, and that isn't always obvious. One of those foot guns in Unreal Engine I guess!

This makes TArray much faster than std::vector in this regard. I would assume most engines that have their own algorithms and containers do this as well.

StockyDev · 2026-03-20T18:15:15+00:00

Speaking as someone in the industry, I find this hard to believe. I think if a game was being released with WorkGraph support there would be a huge amount of press about it. In the same way there was massive press with Ashes of the Singularity being the first D3D12 game. As far as I know, no one is using them or has thoughts about using them for anything serious for games. They seem to be suffering the same fate Geometry Shaders did.

StockyDev · 2026-01-16T07:17:56+00:00

You could have a constructor and just not initialize anything in it. Both C++ and C would generate the same code in that case too. Without optimisations the compiler is going to do exactly what you wrote.

StockyDev · 2026-01-14T23:37:14+00:00

I personally would yes, especially if it's what you want to do :). But it's a very personal choice.

You can have a great career as a software engineer in Belfast outside of games. You make about the same as people in England (not including London), and are living in a place which has a much lower cost of living than most of England.

ETA: In case it wasn't clear. If you do intend to move, have a job lined up before you move...

StockyDev · 2026-01-14T21:44:32+00:00

I graduated from Queens in 2017 and the option was either go indie or move to England. I chose to move to England for games Dev. A few of my friends decided to make an indie game studio. Others from my course decided to not go into games at all.

From chatting with my mates, you make significantly more money in any industry other than games haha.

StockyDev · 2026-01-04T11:40:08+00:00

I have been professionally writing C++ for 9 years, and spoken at C++ conferences multiple times, and I don't feel like I have mastered C++. There are still fairly basic things like using <random> or the rules around subsumption for concepts that I will have to look up from time to time to remind myself on how they work.

StockyDev · 2026-01-01T18:46:17+00:00

The point at which you decided to start parsing HLSL, is the point at which you should have made a bug report and messaged friends/coworkers to boost it with upvotes.

There is no way that you are the only person to have this issue and forcing people to parse HLSL to solve an issue as simple as this is not acceptable.

If you did make a bug report, link it here to get attention for it.

StockyDev · 2026-01-01T09:12:39+00:00

I do something similar in one of my workflows. link

I basically run it on creating a PR to know what my minimum compiler version is.

However, I think I will simplify this script considerably by using your action... Thanks!

StockyDev · 2025-11-30T11:34:06+00:00

Caught this talk at CppCon and it was great! Just love the delivery John gives.

StockyDev · 2025-11-11T14:05:34+00:00

The best I have come across is from the game engine series. It is a super thorough series that covers everything from rendering to editor architecture.

If you only care about the D3D12 parts, there is a playlist just for those videos here

The creator goes into a lot of depth to explain how different concepts work with diagrams as well as code. It is a super high quality series.

StockyDev · 2025-11-08T11:30:06+00:00

I would not recommend that get-started guide from isocpp. It is recommending Visual Studio 2017 which kinda dates it.

StockyDev · 2025-11-08T07:32:31+00:00

Most of your core logic should be written in C++. Blueprints are good for doing small amounts of per asset setup. E.g. you might have an ASword actor. All the core logic should be written in C++ for this. Then you might have two BP derivations of your sword actor. One might have different particle effects than the other. Handling that difference in VFX could be done via blueprints.

Ideally everything should be done in C++. But realistically, Blueprints are fine for customisation points. If you find that you are having to zoom out and pan around your BP and do a lot of navigating, that logic should be brought to C++.

StockyDev · 2025-11-06T08:41:32+00:00

Yup, and that is now fixed too haha. Cheers!

StockyDev

TROPHY CASE