Thank you! The background stars are a texture that I found on solarsystemscope.com, and _should_ correspond to the actual orientation of the firmament WRT your frame of reference. I'd love to add labels for salient stars.
The Book of Shaders [1] perhaps? It's about fragment shaders rather than geometry but it felt to me like a good introduction to generating things programmatically.
We make extensive use of sequence diagrams using PlantUML at my work. We don't rigorously adhere to the correct UML arrow types and so on, instead preferring it as a fast way to clearly communicate data flow over time. The fact that it's in a text format means it can be conveniently edited and stored in source control.
I've had less success with component diagrams to represent our systems because the layout engine in PlantUML is (or used to be) quite limited. This resulted in diagrams that didn't communicate the system as well as if I manually drew boxes and lines.
There is a fantastic plugin for Jetbrains IDEs that generates the diagrams in real time which is great for fast feedback, and can be used for driving out diagrams while presenting video calls.
Overall, my conclusion is that you can pick the parts that are useful to you and the people you communicate ideas with.
I found using groups, colors and direction hints gets mostly around the issues. Enough that the benefits outweigh the downsides of switching to something else (that doesn't get source control, requires separate edit/export steps etc).
> There is a fantastic plugin for Jetbrains IDEs that generates the diagrams in real time which is great for fast feedback, and can be used for driving out diagrams while presenting video calls.
That's exactly how I use it!
> We make extensive use of sequence diagrams using PlantUML at my work. We don't rigorously adhere to the correct UML arrow types and so on, instead preferring it as a fast way to clearly communicate data flow over time. The fact that it's in a text format means it can be conveniently edited and stored in source control.
I'm curious about the target demographic for this and other re-releases (Doom for example). I played first time round and am more than happy to play this for the nostalgia, but are there also new players? What would make someone growing up now pick this up over Fortnite or Call of Duty? Is there demand, or is it just that making content for older games is less expensive than creating a new AAA title?
What's tricky is some old classics are probably still worth playing, but some are unplayable by modern standards. I was looking into old games, and Descent just seems too hard, Myst-style point-and-clicks don't work. Older RPGs feel like too much work. I also have zero interest in playing the same level for two hours because of some especially hard gameplay element.
For FPS, see if you enjoy Doom 4. If you enjoy Doom 4 then you should be able to enjoy the whole line of Doom 1/2 - Duke Nukem 3d - Quake 1/2 - Unreal that I consider as the golden age products. Unreal has the most advanced engine and the community releases a few patches back in the day, so you might want to watch a few videos and decide which one(s) to play.
For RPG, there are a few "ages". Check out Ultima 1/2/3/4, Wizardry and Bard's Tale which I consider still fun to play despite the oldskool graphics. If you can't stomach the style or graphics, check out SSI Golden Box products. If you still can't go through any of the above, I'd suggest you try out Fallout, Baldur's Gate and Neverwinter nights (Both Neverwinter nights and Baldur's Gate have an enhanced edition that you can purchase).
Even back in the day Descent was more of a niche game. I played a crap ton of it on the Kali ladder as well as modem death match with a buddy, but we were the only ones out of our extended friend group that liked it vs everyone that was into doom, quake, etc. A lot of people got motion sickness issues from it and couldn't really do anything about that.
If you're interested in Myst style games but want to play a modern spiritual successor, check out The Witness. It's an astoundingly well designed game, though some of the last puzzles will take some persistence.
C takes the middle road -- variables may be declared within the body of a function, but they must follow a '{'. More modern languages like Java and C++ allow you to declare variables on any line, which is handy.
I know this is not the case in C11 for example, but is there a compile-time speed-up when declaring variables in this way, or any other benefit?
Old C compilers would first parse declarations, then allocate space on the local stack (usually by subtracting the number of bytes needed from the stack pointer), and go on to compile code, knowing that - from that point on - there's a well defined stack structure (and very often in those days, even a constant offset from the "frame pointer" or "base pointer" which would be copied from the stack pointer at that point)
Introducing additional variables later, means that if you emit code "as you go", you'll be less efficient - which makes no difference today, but was a big thing in the days C was designed; Most compilers back then were single pass, emit-as-you-go. There are relatively simple ways to deal with that even under the single-pass constraint, but in those days and the common compiler construction techniques prevalent at the time, it was considered harder.
There was always an issue of fixups with scope-exiting control transfer like break and goto - however, they are simpler, and don't harm emit-as-you-go compilation to the same extent.
On the other hand, one nice thing about C compilers is that they are _fast_. I always inwardly shudder when I see a C++ file including Boost, because I know the compiler is going to have to chew on it for several seconds every time there's a change.
In assembler, the function prologue has to set up the stack frame with enough space to store local variables. Having all local variable declarations come at the beginning of the function was an extension of that - keeping C closer to assembler and perhaps making compilation conceptually easier. With modern optimizing compilers, though, we're not necessarily directly translating to assembler line for line, and might optimize out some variables entirely, so it doesn't matter as much.
EDIT: Looks like beagle3 beat me to it while I got coffee.
I suspect it may have helped very slightly with the parsing in early compilers to not mix declarations and other statements, but with SSA-based compilation which is quite common now, it doesn't matter where you declare variables as long as you do so before you use them.
> I was listening to a friend's music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to abuse that connection so they can buy themselves a boat.
It's called I Hate Music. [0] I really enjoy it, and I think some folks around here would, too, but I'm really a poor barometer of what others might enjoy. My assessment is also maybe a bit clouded by my affection for the guy.
Are the background stars randomly generated or do they correspond to the actual galaxy? Distant points of reference would be interesting to see.