site banner
ArjinFerman  Tinfoil Gigachad  1d ago (text post)   417 thread views

Tinker Tuesday for November 19, 2024

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service

1
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

How have you been doing @Southkraut?

Lots of time wasted on engine switching and reconsideration. Better focus more on disassociation from engine even at cost to performance. Said this before, but optimization always draws me towards tighter integration - need to not do that. A cleaner separation with minimal engine specificity (is that a word?). Don't let the siren song of premature optimization lure me from the good path.

Is there a way to do C++ without header files? I realize it's incredibly petty, but having two files per class just keeps turning me off of Unreal.

Other than that, I keep comparing engines.

Unity:

  • C# as a scripting language.
  • Single-precision coordinate system only.
  • Messy development, priorities of the Unity company are unclear, future is uncertain.
  • Documentation is pretty decent.
  • Has a live scene editor.
  • Many features are semi-maintained only and better not used.

Unreal:

  • C++ as scripting language. Big meh. I just don't find it fun to work with.
  • Overengineered editor and blueprint system keeps getting in the way.
  • Huge file size and memory footprint.
  • Amazing features; would anyone contend that this is the most powerful engine?
  • Double-precision coordinates out of the box.
  • Documentation is OK, but surprisingly thin on many features. Seems to live mostly in youtube videos.

Godot:

  • Does support C# scripting AND double-precision coordinates...but good luck getting that to compile, nevermind getting support for it when it bugs out.
  • Engine
  • Documentation is OK.
  • Community is very actively woke.
  • Has a bunch of bugs.
  • Amazingly small file size and resource consumption.
  • No live editor.

Redot:

  • Like Godot, minus the politics but I'm not sure how long it'll live.

Stride:

  • Engine written in C#, open source, and scripting is in C#. C# versions are up to date. It's a dream come true.
  • No live editor.
  • No double-precision coordinates.
  • Very buggy.
  • The documentation is completely worthless.
  • The community is agreeable but doesn't have the manpower and/or time to bring the engine up to scratch.
  • Even if I don't use the engine itself I can cannibalize many utility classes of theirs and even learn a thing or two about efficient C#!

No idea where I'm going with this. Right now I'm trying to fiddle some dev time into my new routines. Not yet sure how to. Maybe I'll just get used to the job and end up being less weary by the end of the workday so I can get something done in the evenings, or maybe I'll follow a friend's recommendation and just get up even earlier to do some coding in the mornings. Or maybe I'll find a way to take a few short breaks (legitimate breaks, not slacking off.) during work to...I don't know, dictate code to my phone?

Is there a way to do C++ without header files?

I wouldn't recommend it as a permanent process, but when I'm sketching things out I often define functions within class definitions in headers. You can almost get to a point where you only have header files, but there are a few caveats (circular dependencies, static member initialization, inlined code size) that prevent me from liking it for bigger projects. But it can be helpful if you haven't finalized interfaces since there is only one place they are defined.

Is there a way to do C++ without header files? I realize it's incredibly petty, but having two files per class just keeps turning me off of Unreal.

If you're creating an application or something like a dynamic library using someone else's API, technically you can put every single thing into one giant .C file with no header files and it'll work. If you're creating a library for others to use, either it needs to be "header-only" (i.e. it all gets recompiled by every user, which really only makes sense for pure-template code where the user does every instantiation) or it needs to have separation between declarations in headers (for the users' compiler) and definitions in source files (for the users' linker). Technically you can mark all your definitions as inline and put them in headers and just have one file per class even if you're not doing fancy template tricks, but people don't do this, just to avoid longer recompile times.

It's common to have more than one class declaration per header file, but for big projects it's just easier to keep everything organized if you have one class per header.

It's not uncommon to do "unity builds" (no relation to the game engine), where a bunch of source files get batched together so that (because of include guards) the header files only have to get parsed once per batch rather than once per file. This is just to reduce compile times and allow for more Inter-Procedural Optimization in a single compiler pass, AFAIK.

Complaining about two files per class isn't petty so much as weird, though. Partly I say this because I love having two files per class (the declarations are "what does this do", which is easier to read when removed from "what messy tricks does this use to do it" definitions), but mostly I say this because there's so much more in C++ to complain about. I'd have imagined a C# fan would have been most annoyed by having to manually manage heap allocations, with no garbage collection.

would anyone contend that this is the most powerful engine?

I thought that was the general consensus. People also think it's the hardest engine to use (which is why I played with Godot with my kids, despite C++ experience myself), but AFAIK it's had the most features for forever and people manage to wring out the most performance from it too.

I thought that was the general consensus.

It is. I posted late at night and was tired and got dumb and messed up my Englisch to the point of stating the opposite of what I intended. Contend, contest, contradict...Nach Müd kommt Blöd.

I'd have imagined a C# fan would have been most annoyed by having to manually manage heap allocations, with no garbage collection.

Modern C++ is much less painful in this regard. The days of new() and delete() are long gone.

find /usr/include/c++/14/ -type f | xargs grep '= new' still shows me nearly a hundred uses in standard library headers, so "long gone" is a bit of an exaggeration. If libstdc++ authors are still at that point, imagine where your average coworkers are. ;-)

I admit that shared_ptr was nice, and the development of "like auto_ptr, but you can put it in containers" was a godsend. Pointing grep at my own favorite project I still see 6 invocations of new in non-deprecated code, versus about 800 invocations of make_unique.

But I'd still argue that even modern unique_ptr best-practices count as manual management and are thus more annoying than "the programming language will just figure it out". Even if you try to mimic garbage collection behavior with shared_ptr you still have to worry about leaking unreachable cycles of pointers that a garbage collector would have been able to detect. This is all a useful sort of annoying if you write any sort of interactive code where big a garbage collection sweep might drop a frame or add input latency or whatever, and even garbage collected code can leak memory because "I forgot to remove a reference" isn't a drastically different bug from "I forgot to delete an allocation", but heap management is still the thing I notice the most complaints about when users of other languages first move to C++.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats