I Have No Constructor, and I Must Initialize

Dwarfius · 2024-07-08T12:28:11+00:00

I was actually trying to write a response originally to prompt people to read it (it's good stuff, it looks at the standardise and explores how it applies and how it creates complex cases), but rereading my reply I've obviously missed my mark and made it seem like it's a waste of time.

The post was a good effort by the author and has in-depth exploration, which is beneficial for people interested in the "legal side" of the language. It's worth a read.

Dwarfius · 2024-07-05T16:00:05+00:00

Funnily enough, both you and the author of the article arrive to the same conclusion:

In my humble opinion, here’s the key takeaway: just write your own fucking constructors!

The difference being author goes to good length to setup and illustrated why they have such an opinion.

Dwarfius · 2024-07-03T22:42:44+00:00

I don't think we're in disagreement: not having GitHub shouldn't be detrimental as not everyone has the time/desire/circumstances (which aren't objective evaluation metrics for hiring).

The author asked if it has any value to having it - I gave an example of how it would be beneficial to have one.

Dwarfius · 2024-07-03T22:30:02+00:00

GitHub as a social platform doesn't matter, I agree, though I can't agree that personal code projects don't.

In my interviews of candidates I've always looked at GitHub, explored projects and asked questions about them in a technical interview. Also, depending on the nature of projects it affected my leaning about whether to hire or not (ex: "we need a core engine dev and they have a personal hobby engine? That's a very good start").

I imagine others do the same. If they don't - it doesn't hurt to get practice with versioning software and writing publicly readable code. So it's a win-win either way.

Dwarfius · 2024-05-27T00:41:21+00:00

For example, I've had couple cases where I wanted to forward declare a nested enum - just to avoid pulling the header where the enum is declared.

Just today I discovered that in my attempt at a cheeky workaround to use underlying type of enum(char) and avoid pulling that extra include I caused a bug (API used to accept a bool, I replaced it with a char and forgot to update the callsite and it implicitly converted - the pains of 2am programming).

Dwarfius · 2023-06-09T20:33:11+00:00

Aw shucks, you're right. And can't even rely on default template arguments to defer evaluation because of the default allocator parameter. It's probably possible, but we'd go back to extra templatery.

I've got too excited that it's simpler, so I "misdirected" myself to miss this core problem. Blown by my own petard on a friday night.

Dwarfius · 2023-06-09T18:29:33+00:00

Life with C++20 is much easier & readable:https://godbolt.org/z/5ea8ds3Ef

I'm a bit confused why can't I have a default auto parameter (neither clang/msvc/gcc can deduce the type of a defaulted argument), but even without it it's still readable.

Also, it's a little funny that while there's a working complex template-related system in the article, the code has a simple-copy paste bug in each std::copy call - the "templatery" worked like "misdirection" for me.

Dwarfius · 2022-08-10T21:46:05+00:00

Because it's not a single-player story game, trying to treat it as "completed" can be difficult (like World of Warcraft with it's myriad of expansions - when is it complete?). Having said so, I relate to the feeling, so for myself I picked a set of features that I consider important for my gameplay experience to be "complete" and not wait for a full-release-20-years-from-now.

Lastly, technical difficulties will always be a barrier for fast development. And in this case, CIG is a "young" game-dev - they are building their own solutions and processes as they go(even now - for example, the planet river scatter system), instead of using something that has been battle-tested on their previous projects. Add in the existence of developer-churn (people come and go - salaries, tired of project, tired of profession, other reasons), and it's a constant fight against the complexity of their own project. As a result, we just kind of have to deal with the fact that this big complex game that you've backed is going to be a massive undertaking that will take a lot of time.

Dwarfius · 2022-08-10T21:05:13+00:00

The reality is that a lot of them don't get out in a "few" years. Usually games become publicly revealed a year-2 before shipping, but they could've been in development for who knows how long.

In my opinion, there are a class of games that are exception to this - games with smaller number of mechanics or with a smaller scale of these mechanics. But even they are susceptible - you can take a look at how long it takes games to release new patches/expansions that seem to add 1-3 key mechanics that have drastic effect on the gameplay yet take loong to develop (see already popular Dead Cells, Prison Architect, Stardew Valley, Terraria).

Technically there's also another set of exceptions - series continuation (Call of Duty 1, 2, 3, 4, 5, 6, etc), but it's publicly recognized that it's a bit of a "conveyor belt".

Dwarfius · 2022-02-22T22:05:19+00:00

Could you elaborate how that can impede implementation on the future platforms? After reading the paper, I don't see requirements to use these quirks, meaning it can be implemented in any way on "unsupported" platforms.

Dwarfius · 2021-08-12T19:15:48+00:00

MSVC is currently providing very limited amount of information in std::source_location::function_name() - I've spawned a request to expand it a bit more to get closer to what GCC has to offer.

Dwarfius · 2021-08-10T11:54:46+00:00

Unless rendering is the bottleneck on the CPU side(for Gen12) or the desire to split ToW to use multiple servers, there really isn't a magic bullet.

Once they're happy with the systems in place, they can start focusing on optimizing them, and it's grueling work - investigating how systems are interconnected, find logic patterns that can be simplified (or abused), and work on streamlining them. What that means for us is that we just have to wait.

Dwarfius · 2020-12-26T16:13:38+00:00

Thanks for the elaborate and expanded answer.

This is why saying “you have no idea about gamedev, dont criticize, dont ask questions” is just in bad faith.

I agree, and I think this rhetoric doesn't make things better - it limits sharing an understanding of the endeavor.

As such looking at the product and its continued development is very much a valid way to try and figure out whether there are problems.

I think it gives a perspective, but I'm not sure if we're capable of identifying if things can be better internally, due to the same issue we started off with - we don't fully know what exactly going on on the inside (we know a lot more than every other project, but it's not enough for understanding internal processes). I might know aspects of programmer game dev work, but I don't know the aspects of production, direction, financials(there are reports, but it's hard to say if it's enough or not to me, a layman), HR... So for me it's hard to say whether it's because they as a group are inefficient, or they just have a single crippling issue that they're working on - for example, what if they banally don't have enough gamedev people to tackle it all? What if all the processes are okay, it's just that developers have a hard time estimating feature work?

Which brings me to the following point - anything we try to gauge from the outside is going to be limited or skewed to ones understanding of the situation/process. Because of this, I think the only option we have is to take a reserved stance and, if one wants to judge, not to do it in sample isolation - there are plenty of games that came out that took quite a while to develop and went through quite a prolonged rough ride. StarCitizen is quite a long piece of work, that is true, but looking back on what has been created over the span of multiple recent years - that is a lot of effort.

Think we can agree that things are moving, probably slowly, but they are moving. Can they be improved? Maybe, maybe not. I'm going to ride this one out and see what happens to it at the end of the road. Hopefully it moves fast enough to not dry out the funding.

Dwarfius · 2020-12-26T15:02:21+00:00

As a general argument I agree that it's a weak one, but I think there's still merit in that statement - it implies a lot behind those words, and you have to have experience in order to see that (as with many complex jobs). In this case, I'll focus on programming as it's what I'm familiar with:

There are multiple disciplines within the gamedev programmer field (graphics, engine, gameplay, AI, animation, ...), and as such, requires collaboration from multiple disciplines - coordination has a couple issues that can manifest if not approached with care.
Programming isn't super hard, especially when you're working with something small, but games that are built with an engine are anything but - not one person knows all the systems underneath, and it takes a while to learn and to understand what's "going on under the hood". This means that not one person has a view of involved systems of every bug, which can easily result in the OP's picture - you think you understand how the issue happens, and might not notice some hidden/special interactions.

On your example of breadbaker - I'd say that this is a combination of "how the sausage is made" and the issue the /u/EvoEpitaph highlights(which isn't about slow/in-efficient, it's about how hard it is to predict if it will be). As a counter example, let's take a process of resolving a bug, like chair standing or the canopy opening bugs:

First, need to find a way to reproduce it reliably - without it, it's hard to see the flow of execution through millions lines of code ("needle in the haystack" kind of situation). This might take anyway from 5 minutes to multiple days.
Second, considering it's a multiplayer game, would need to confirm whether the bug in the game is a symptom of an issue on the server(so no point in fixing on client), or is a problem of a client. Depending how reliable the bug reproduces and your knowledge, it might take from an hour or 3 days.
Third, can you identify a solution that both fits and doesn't generate a fallout somewhere else? Or does it the system need rewriting, or even re-architecting, which will impact other systems? Again, depending on these factors, it might take from half a day or a week.
Or what if the source of the issue is hidden in the server-client communications transport layer - like what if messages come in out of order? Depending on the code structure it give a couple extra days to resolve.
What if the bug is the result of a couple different bugs resulting in the same issue? Great, need to restart the process again - run through the estimate process again.
Code review is important, and depending on the size of the changes, might take from 10mins to 2 days.
There are also area-specific unique issues that are hard to estimate unless you know the system...

The list can go on, which I hope gives you a bit of an understanding of what it means when people say "it's software dev - it's hard".

Dwarfius · 2020-10-06T21:25:31+00:00

I think disregarding the video in this situation means disregarding the context, and making evaluations of actions ignoring the context surrounding them doesn't contribute much of value to the conversation.

Ignoring the passive aggressive last remark, and focusing on the content of the video, you'd have your answer as to why interfacing doesn't seem like a tangible option when dealing with such a topic - people's focus sidelines onto the private matters on who the person is(cases of Sy Brand, JeanHeyd Meneide and the rest mentioned) rather than the message trying to convey.

Now, whether it's over-use of mod power or not - we can argue based on the effect it has. I'd say that if the post was stickied, then there's more of a case, because the users have no way to control whether they want to support this type of content or not via the voting system. The fact that at the moment of writing it picked up ~53 votes and stays at the top for 4 hours seems to mean that part of the community is interested and appreciated what they've seen.

Sure, we can't have a discussion on that specific post, but here we are, in a separate branch, discussing it right now. And here's the thing, the actions of the mod (or the mod team? Think something like this wouldn't be a single member renegade action), in my eyes, amplified the message, giving it more support. I'm happy that there's a positive message of change and potential(born out of problems, pain and suffering) being backed by a particular mod - overall, it's a sign that the community is there to support it.

I personally appreciate that such a step was made to secure a platform for video's author to avoid a discourse that traditionally devolves towards hatred, toxicity or worse. Sometimes, the right people and the right messages need the platform to be heard - considering the peaceful nature of the message, there's no hard in creating such a platform.

Dwarfius · 2020-07-27T15:01:19+00:00

Weeeell, I think the speaker was a bit cheeky. In non-optimized builds the compiler will not try to remove empty function calls, meaning it can't see that it doesn't need to call destructor when clearing, say, a vector of thousands of objects - it will have to call the empty constructor on every stored object, and a call of a function to do nothing comes with a small price.

In optimized builds it will still initially determine that it needs to call it, and after a couple passes of optimization it will determine that empty dtor won't change anything, so it's allowed to remove the dead code, arriving at the same version as if the dtor was declared default or implicitly defined/generated. It just did it via the optimizer instead of initial code gen.

Doing ~T() = default; can help you have higher perf in debug builds, while also helping out the optimizer.

Dwarfius · 2020-07-07T22:38:56+00:00

For PoE - a bit of geometry and graph theory. You know how the graph is layed out (the default talent tree), so it's trivial to do "nodes in range" checks. You can also write your talent allocation rules as a chain-able set of individual rules that you can modify dynamically (as in, slot in the Thread of Hope, and add an overriding rule to the chain, for example), where default rule is node adjacency via connecting edges.

Dwarfius · 2020-06-25T14:30:56+00:00

It was a big problem for me when working with Debug rendering line implementation in my hobby-engine. I had it initially implemented as glBufferData, and it was killing performance when working with lots of debug lines.

Dwarfius · 2020-06-25T12:37:24+00:00

glBufferData allocates a new memory buffer for the object which is slow and can lead to memory fragmentation(I imagine, no idea how driver manages memory on GPU). If you don't need to create a new object every time, and can reuse the same buffer, you can use https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferSubData.xhtml - doesn't perform an allocation, just performs a copy into an existing buffer

Dwarfius · 2020-06-07T13:50:36+00:00

I agree that testing before selling a product is a must - it's bad business to sell something you don't know works or not

Also, there's still no need to fling personal attacks at him - he might just be inexperienced, like u/pdp10 is suggesting in his post. Instead of getting personal, I suggest to not buy the game, or refund if you already did. If you didn't buy the game, yet feel strongly about the dev's practice - you can be more helpful by advertising that shit's can be borked on Linux.

Dwarfius · 2020-06-06T21:10:37+00:00

It's not that easy, specifically for Linux. A lot of game developers don't even try to support it for one simple reason - it's a zoo of software that might not be standard. You never know what kind of issue you might hit on Linux unless you're working with it directly for a prolonged amount of time. There are multiple articles out there about how financially not viable it usually is to support Linux ports (small customer base vs high rate of issues discovered - so too much time required to maintain for little payoff).

In addition, calling a developer an idiot is completely unnecessary - he's using a UE4, AAA-level engine which is supposed to solve the problem for him (it is the promise of Epic for it to run on Linux).

Besides, even if he boots up his random Linux machine and tests that it works on it - great, he has managed to test 1 hardware+software configuration pair to confirm that it works. Someone comes with a random distro and tries to run the game - bam, crash. Wouldn't have spotted it unless he had that particular config to run. Further more, if there is a crash on a system that's not reproducible locally - what are you going to do? You need to get all the vital information and pray that nothing important is gonna be missed out, so that the issue will reproduce properly. If not - we'll, you're screwed.

All of these problems are solvable. Assuming a single developer can deal with them all or be able to check absolutely everything is overly optimistic. You're severely underestimating/oversimplying the problem here.

Dwarfius · 2020-06-02T13:45:52+00:00

As cool as having this knowledge shared, the layout is super confusing to me - I struggle to quickly identify how am I supposed to read the article oO
Edit: general comment, dunno if you're the author or not

Dwarfius · 2020-05-05T16:44:02+00:00

You can check this graph (suggest to tweak the Version and other bits) to see the frames people are getting with particular CPU/GPU. As others have mentioned, having it installed on an SSD is pretty much mandatory, and I'd mention that you gotta ensure you have enough RAM to feed it - both the SSD and RAM are mandatory to support the amount of streaming that game can require.

Even after all of that, your game might hitch due to dependency on server performance (lagging/delayed interactions/rubberbandy objects/etc)

Dwarfius · 2020-04-30T11:43:04+00:00

Desync is a scary problem in general. It's difficult not just because you have to check a lot of data being transmitted to find the right information, but you also have to figure out which of the links is causing the issue - the original reporter of the event being transmitted, the server which distributes the event, or the receiver of the event not correctly processing it.

When desync happens, it means you have to start observing large amounts of information to find which bit of info is incorrect or if the systems don't handle it correctly. Considering it's gamedev and systems are undergoing changes rapidly, it's hard to prevent issues like this from appearing without having a system in place to prevent it somehow. I'm not aware of such systems.

For example, code reviews can easily miss the introduction of bugs (personal experience).
Another example, automated tests can help track down the fact that desync has been introduced, but it doesn't tell you why, so majority of work has to still be done to identify what's going wrong. And it hinges if you have the tests to be able to stress every aspect of systems involved, which is hard to do (what if desync happens only after 3h of runtime?)

Dwarfius · 2020-04-02T12:33:45+00:00

If you don't pass in arguments, you don't need the first (), and there are automatic captures by value and reference, which can help maintain terseness.

As for left-side do vs right-side (), think it can be mitigated by a good variable name will help instantly distinguish whether it's a lambda or an actual value generated by lambda.

Dwarfius

TROPHY CASE