Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it
Ola Fosheim Grostad
ola.fosheim.grostad at gmail.com
Fri Nov 27 21:08:28 UTC 2020
On Friday, 27 November 2020 at 20:41:33 UTC, Guillaume Piolat
> really), I'm saying that the traits that make people switch to
> a new language are desirable properties of the _library they
> want to use_, more than the language.
Yes, or the service it runs on. Which is why I think D ought to
encourage separating framework from app. Let the framework do
the multithreading and let the app author write simple single
threaded tasks. So basically the framework deals with shared and
app authors can mostly ignore that... That would be a good reason
to have single threaded GC, which also would enable fast 100%
precise collection and correct destruction and RAII. I think we
could even get the destructor order right.
However, ARC is more generally useful... For me.
> Soft disagree. This sounds to me like a high-debt solution.
> If you make a game engine for example, cost of making N games
> is O(N), but cost of having a new platform is O(1). If added
> value flow to the game engine properly, you _will_ end up
> having support for all platforms needed.
Godot does not even support Metal or Direct X?
For web I actually only want really efficient debuggable wasm.
The browser is the framework and apps should load and run in 1
second. Flutter is a bit bloated, but probably less bloated than
unity/godot... And better UI support... But generally speaking...
Frameworks are more a hindrance for what I want to achieve.
Anyway, my point was more: if your goal is to build a framework,
then you would not do it to promote a specific language. So I
dont think the D community can decide this to be a focus.
We can only focus on the enabling language features, getting rid
of the irritatiting pain points.
(Why is typing on ipads so... Nggh?)
More information about the Digitalmars-d