> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev).
You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
It's also industry standard to do so. I don't think I've ever seen a team outsource something like pathfinding. Maybe in the Unity/Unreal space, which I'm very unfamiliar with. Dependencies are generally speaking not viewed as a good thing. They become vanishingly rare outside of certain things like physics engines, sound engines, vegetation, etc. And usually higher quality proprietary ones are chosen over OSS (though this is changing with physics engines in particular, mostly thanks to Bullet)
NIH is a cultural pillar. Even scripting layers are relatively split on if they're in-house or not. It's not uncommon to find both an in-house fork of Lua + a few other completely custom scripting engines all serving their own purpose.
Pathfinding middleware has traditionally been a thing though, e.g. apart from the mentioned ReCast (which is the popular free solution) the commercial counterpart was PathEngine (looks like they are even still around: https://pathengine.com/overview/).
If you need to do efficient path finding on random triangle geometry (as opposed to running A* on simple quad or hex grids) it quickly gets tricky.
What has undeniably declined is the traditional "10k US-$ commercial middleware". Today the options are either free and open source (which can be extremely high quality, like Jolt: https://github.com/jrouwe/JoltPhysics) or fully featured engines like Godot, Unity or UE - but little inbetween those "extremes".
I did mention this was changing in particular with physics engines. That being said, proprietary dependencies still reign supreme in places like audio engines. Something like OpenAL isn't really a replacement for FMOD or Wwise. I know those off-the-shelf engines roll their own replacements, but then they also roll their own pathfinding and navmesh generation as far as I know.
It's not a terribly long list, it seems, even if it's non-exhaustive.
> I see the industry is of full double standards
Absolutely, and that's why it's so great. No two companies are going to look the same. The culture of the video games industry is a rather unique one that's kept its archipelago syndrome alive against all odds. It'll be a sad day if that ever changes.
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).
GDScript is not very maintainable as the code base grows. It lacks proper refactoring tools (e.g. the ones from Jetbrains Rider), static type checking, flexible object system and many 3rd party libraries which might be needed
You likely won't need to do manual memory management nor think about undefined behavior. If your writing basic c++ to handle the simulation in a game, it's going to be pretty orthodox and these problems likely won't manifest.
The purpose of recommending c++ here is:
If GDScript is too slow, reach directly for C++.
I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.
The author "teaches workshops on AI development for engineering teams". This is nothing but a selling post for companies. I don't know what to discuss here honestly, this is more primitive bait than an average video preview picture on YouTube.
If only Lisp had better presense in modern code editors. Emacs is not enough, especially on Windows where it is super slow. I think this is what actually stops newcomers to start with Lisp and not Python
> I think this is what actually stops newcomers to start with Lisp and not Python
What stops newcomers is knee-jerk reactions about the (lack of) syntax, it's scary to see something that doesn't look like Algol, because everyone who does mainstream programming uses Algol-like languages.
Introduce lisp to anyone who knows programming since earlier, and 99% of them will have a adverse reaction to s-expressions, before they understand what's going on. Once they understand, it makes a lot of sense obviously, but not everyone even has that kind of open mindset where they could understand if they wanted to.
Symbolic expression is one thing, I would personally find it rather cool to have more first class expression as building block everywhere. However I'm not found of using explicit parentheses all around. Even mandatory curly/square brackets are superfluous with a properly defined syntax ruleset.
My crackpot theory is that what stops newcomers is how unergonomic "(" and ")" are to type on typical keyboards. If mainstream lisp dialects used square brackets instead, we'd all be programming in it!
> If mainstream lisp dialects used square brackets instead, we'd all be programming in it!
You've almost convinced/nerd-sniped me to write a(nother) new lisp where we'll be using brackets for forms and lists and no parenthesis in sight. It's a wild theory.
I've had way more issues with proper indentation in Python and YAML than I have with parenthesis in lisp. Meaningful whitespace is about the worst idea I've seen in a programming language.
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
$ git checkout feature-1
$ git rebase --update-refs main
Successfully rebased and updated refs/heads/feature-1.
Updated the following refs with --update-refs:
refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev). You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
Same for Zig, Odin, C3 etc.
reply