www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OT: Leaving Rust gamedev after 3 years

reply ryuukk_ <ryuukk.dev gmail.com> writes:
https://loglog.games/blog/leaving-rust-gamedev/

Discussion here: https://news.ycombinator.com/item?id=40172033

We should encourage these people to check out D
Apr 26
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


why, we also have this types of rage quits?
Apr 26
parent Sergey <kornburn yandex.ru> writes:
On Friday, 26 April 2024 at 21:19:56 UTC, monkyyy wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


 why, we also have this types of rage quits?


Because without D they don't release anything :)

Have anyone heard anything about this D to Jai port?
https://www.yet-another-blog.com/porting_the_game_to_jai_part0/
Apr 27
prev sibling next sibling parent reply Matheus Catarino <matheus-catarino hotmail.com> writes:
On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


And what would be the selling point?

If GC were to receive more (offensive) criticism, compared to 
other languages, it wouldn't be worth it.

I'm not a game developer, but when it comes to graphics 
programming dealing with floating point, NaN will be a problem 
that not everyone has experience or patience in dealing with.
Apr 26
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 26 April 2024 at 23:14:41 UTC, Matheus Catarino wrote:

 I'm not a game developer


Therefore you should avoid commenting


 And what would be the selling point?


You have nothing good to say about D?

Please refrain from commenting if it's to say nothing interesting
Apr 26
parent Monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 26 April 2024 at 23:25:20 UTC, ryuukk_ wrote:

 On Friday, 26 April 2024 at 23:14:41 UTC, Matheus Catarino 
 wrote:

 I'm not a game developer


 Therefore you should avoid commenting


 And what would be the selling point?


 You have nothing good to say about D?

 Please refrain from commenting if it's to say nothing 
 interesting


What a healthy response to criticism, I'm sure this will prevent 
the type of behavior that the post is complaining about of "just 
learn the borrow checker"
Apr 26
prev sibling next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Friday, 26 April 2024 at 23:14:41 UTC, Matheus Catarino wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


 And what would be the selling point?

 If GC were to receive more (offensive) criticism, compared to 
 other languages, it wouldn't be worth it.

 I'm not a game developer, but when it comes to graphics 
 programming dealing with floating point, NaN will be a problem 
 that not everyone has experience or patience in dealing with.


Adding to that - practically no task specific libraries.

You need complex FBX scene importing setup to change things on 
import? good luck with that.
You need navigation and pathfinding? good luck with that.
You need physics engine that is not going to stuck on collision? 
right, you should've already guess it.

extern(C++) with all mess such as const applied to different 
parts e.g. `const foo* const` vs `const foo*` the former has a 
mangling scheme that is not supported by D, great.

---

Dealing with non-D libraries as well when using GC managed 
references(arrays, objects) is PITA, you have basically slap 
`__gshared` on every reference because as soon as it crosses 
thread boundary it is gone, very funny debugging awaits you in 
this path.

As was mentioned in another thread dealing with const and  safe 
is another level of PITA.

We also have our own  nogc and "GC bad" zealots.

---

Add to that compiler bugs, for example when working on 
godot-dlang compiler spits random error message in template with 
`return` scope, probably because there is loads of cyclic 
imports, but the message says something completely unrelated so I 
just given up on `return` and now it is basically leaking up 
refcounted reference leading to more bugs when used incorrectly.

Here is an example of such problem, getTexture returns Ref! 
wrapper that has leaky alias this, this means that getTexture 
immediately returns released instance.

Sure this is my problem, and I suck at programming.

```d
void setTexture(Mesh3D* mesh) {
     // let's assume we just want to invert colors
     Texture2D tex = mesh.getTexture;
     // code that inverts colors
     mesh.setTexture(tex); // oops
}
```

This all is just little annoying nuances, but how much it is 
really different from that "i'm done with rust" article?
Apr 26
parent reply Kagamin <spam here.lot> writes:
On Saturday, 27 April 2024 at 04:46:40 UTC, evilrat wrote:

 This all is just little annoying nuances, but how much it is 
 really different from that "i'm done with rust" article?


They don't quit programming, the point is that the problem is 
less severe in other languages.
Apr 27
parent Kagamin <spam here.lot> writes:
i.e. problem severity isn't boolean
Apr 27
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/26/2024 4:14 PM, Matheus Catarino wrote:

 I'm not a game developer, but when it comes to graphics programming dealing
with 
 floating point, NaN will be a problem that not everyone has experience or 
 patience in dealing with.


When a NaN shows up unexpectedly in the results, it's indicative of a bug in
the 
program.
Apr 28
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 00:55:54 UTC, Walter Bright wrote:

 On 4/26/2024 4:14 PM, Matheus Catarino wrote:

 I'm not a game developer, but when it comes to graphics 
 programming dealing with floating point, NaN will be a problem 
 that not everyone has experience or patience in dealing with.


 When a NaN shows up unexpectedly in the results, it's 
 indicative of a bug in the program.


nans dont show up when programming video games they end in 
silently failed draw calls
Apr 28
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 01:44:20 UTC, monkyyy wrote:

 On Monday, 29 April 2024 at 00:55:54 UTC, Walter Bright wrote:

 On 4/26/2024 4:14 PM, Matheus Catarino wrote:

 I'm not a game developer, but when it comes to graphics 
 programming dealing with floating point, NaN will be a 
 problem that not everyone has experience or patience in 
 dealing with.


 When a NaN shows up unexpectedly in the results, it's 
 indicative of a bug in the program.


 nans dont show up when programming video games they end in 
 silently failed draw calls


If they're silent how do you know they failed?  Also, if you *do* 
know they failed why would NaN be unhelpful in localizing the 
problem?  It could be initialization, or it could be something 
else along the way.

Zero initialization has a few things to recommend it over NaN 
(consistency with our non-FP types, zero is often (not always) 
the correct initialization value anyway, aligns with zero fill 
new-page machinery, simpler if you write bug free code :-) ...).

OTOH, NaNs can be very helpful when trying to track down FP 
problems, with improper (unthinking) initialization probably near 
the top of the list.
Apr 28
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:


 If they're silent how do you know they failed?  Also, if you 
 *do* know they failed why would NaN be unhelpful in localizing 
 the problem?  It could be initialization, or it could be 
 something else along the way.



graphics development. In other Langs, if I mess up some code, I 
usually get a picture that is wrong. A wrong colour, wrong 
position on screen, etc. With NaN, all rendering pipeline 
silently fails if even a single number was uninitialised 
somewhere. So I can't even take a guess at what number exactly 
was not initialised, I have to run a debugger and start from the 
beginning to see where it went wrong. If floats initialize to 0, 
you can usually guess what was forgotten because you know the 
math.


 OTOH, NaNs can be very helpful when trying to track down FP 
 problems, with improper (unthinking) initialization probably 
 near the top of the list.


NaN was literally never helpful to me, because it removes 
indirect information from that allows me to take a guess. If you 
know what kind of math you're doing, you can usually assume where 
the code went wrong depending on the result you get. With NaNs, 
you only get one part of this information.
Apr 28
parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 29 April 2024 at 06:55:16 UTC, GrimMaple wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:
 NaN was literally never helpful to me, because it removes


New DIP should be "print all NaNs in the code"
Apr 29
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 29 April 2024 at 07:57:30 UTC, Sergey wrote:

 On Monday, 29 April 2024 at 06:55:16 UTC, GrimMaple wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:
 NaN was literally never helpful to me, because it removes


 New DIP should be "print all NaNs in the code"


It's an easy check to add in Dscanner.

     Is the variable of FP type ?
       NO  : return;
       YES : Is the variable explicitly initialized ?
               YES : return;
               NO  : emitt a warning;
Apr 29
parent Basile B. <b2.temp gmx.com> writes:
On Monday, 29 April 2024 at 10:12:38 UTC, Basile B. wrote:

 On Monday, 29 April 2024 at 07:57:30 UTC, Sergey wrote:

 On Monday, 29 April 2024 at 06:55:16 UTC, GrimMaple wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:
 NaN was literally never helpful to me, because it removes


 New DIP should be "print all NaNs in the code"


 It's an easy check to add in Dscanner.

     Is the variable of FP type ?
       NO  : return;
       YES : Is the variable explicitly initialized ?
               YES : return;
               NO  : emitt a warning;


Well you have also the verify void-initialization but that does 
not add much more complexity to the check.
Apr 29
prev sibling parent reply Monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 If they're silent how do you know they failed?


Because you get to debug a silent runtime error all the time, and 
at this point I just assume it's a float being nan

I'm pretty sure this is just the gpus reaction to nan, draw calls 
being ignored
Apr 29
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 If they're silent how do you know they failed?


 Because you get to debug a silent runtime error all the time, 
 and at this point I just assume it's a float being nan

 I'm pretty sure this is just the gpus reaction to nan, draw 
 calls being ignored



add zero initializer for float/float arrays.

Very few libraries handle nans correctly from my limited 
experience.
Apr 29
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 10:15:46 UTC, evilrat wrote:

 On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 If they're silent how do you know they failed?


 Because you get to debug a silent runtime error all the time, 
 and at this point I just assume it's a float being nan

 I'm pretty sure this is just the gpus reaction to nan, draw 
 calls being ignored



 always add zero initializer for float/float arrays.

 Very few libraries handle nans correctly from my limited 
 experience.


If you live in a world where no one checks for NaN at any point 
at any time and/or where a default zero will never hide an error 
then yep, you're gonna dislike NaN init.
Apr 29
next sibling parent reply Monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

 On Monday, 29 April 2024 at 10:15:46 UTC, evilrat wrote:

 On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 [...]


 Because you get to debug a silent runtime error all the time, 
 and at this point I just assume it's a float being nan

 I'm pretty sure this is just the gpus reaction to nan, draw 
 calls being ignored



 always add zero initializer for float/float arrays.

 Very few libraries handle nans correctly from my limited 
 experience.


 If you live in a world where no one checks for NaN at any point 
 at any time and/or where a default zero will never hide an 
 error then yep, you're gonna dislike NaN init.


So, if you live in the current world you should dislike nan?

A little convoluted but I'll accept it your surrender
Apr 29
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 13:29:40 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

 On Monday, 29 April 2024 at 10:15:46 UTC, evilrat wrote:

 On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 [...]



 always add zero initializer for float/float arrays.

 Very few libraries handle nans correctly from my limited 
 experience.


 If you live in a world where no one checks for NaN at any 
 point at any time and/or where a default zero will never hide 
 an error then yep, you're gonna dislike NaN init.


 So, if you live in the current world you should dislike nan?


If that's the extent of your "world", yes.


 A little convoluted but I'll accept it your surrender


Useful discussion is more about understanding than win/lose.  My 
understanding of the pros and cons of NaN initialization has not 
changed.
Apr 29
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 14:17:41 UTC, Bruce Carneal wrote:

 My understanding of the pros and cons of NaN initialization has 
 not changed.


despite being in a thread of 4 people saying "yes nan init is a 
huge annoyance [specif use case and terrible work arounds]"?
Apr 29
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 29 April 2024 at 17:40:54 UTC, monkyyy wrote:

 On Monday, 29 April 2024 at 14:17:41 UTC, Bruce Carneal wrote:

 My understanding of the pros and cons of NaN initialization 
 has not changed.


 despite being in a thread of 4 people saying "yes nan init is a 
 huge annoyance [specif use case and terrible work arounds]"?


If this is so annoying...

```d
double x = 0;
```

why not

```d
struct MyDouble
{
     double x = 0;
     alias this = x;
}
```
Apr 29
parent reply bachmeier <no spam.net> writes:
On Monday, 29 April 2024 at 17:52:55 UTC, jmh530 wrote:


 If this is so annoying...

 ```d
 double x = 0;
 ```

 why not

 ```d
 struct MyDouble
 {
     double x = 0;
     alias this = x;
 }
 ```


This made me realize you *can* force the compiler to throw an 
error rather than initializing variables:

```
import std;

void main() {
     MyDouble z = 1.0;
     writeln(z);
}

struct MyDouble {
     double x;
     alias this = x;

      disable this();

     this(double _x) {
         x = _x;
     }
}
```

The same can be done to prevent ugly bugs like we discussed in an 
earlier thread:

```
struct Foo {
     struct Bar {
         double x;
     }
     Bar bar;

      disable this();

     alias this = bar;
}

// Neither line will compile now
void main() {
   Foo foo;
   auto foo = new Foo;
}
Apr 29
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, April 29, 2024 1:10:35 PM MDT bachmeier via Digitalmars-d wrote:

 This made me realize you *can* force the compiler to throw an
 error rather than initializing variables:

 ```
 import std;

 void main() {
      MyDouble z = 1.0;
      writeln(z);
 }

 struct MyDouble {
      double x;
      alias this = x;

       disable this();

      this(double _x) {
          x = _x;
      }
 }
 ```

 The same can be done to prevent ugly bugs like we discussed in an
 earlier thread:

 ```
 struct Foo {
      struct Bar {
          double x;
      }
      Bar bar;

       disable this();

      alias this = bar;
 }

 // Neither line will compile now
 void main() {
    Foo foo;
    auto foo = new Foo;
 }



If you really want to control what's going on, you could make a floating
point equivalent to std.checkedint's Checked.

- Jonathan M Davis
Apr 29
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 17:40:54 UTC, monkyyy wrote:

 On Monday, 29 April 2024 at 14:17:41 UTC, Bruce Carneal wrote:

 My understanding of the pros and cons of NaN initialization 
 has not changed.


 despite being in a thread of 4 people saying "yes nan init is a 
 huge annoyance [specif use case and terrible work arounds]"?


Yes.  As is apparent in this and any other NaN init discussion 
that I've been part of, there are pros and cons that people weigh 
differently.  The weight I place on being able to more readily 
isolate potentially difficult FP bugs is higher than the weight I 
place on the auto-zero benefits combined.

I can and have worked without NaN init.  The world didn't end nor 
did I call for a NaN init crusade, but I prefer NaN init to zero 
init and either to undefined init.
Apr 29
prev sibling parent reply bachmeier <no spam.net> writes:
On Monday, 29 April 2024 at 13:29:40 UTC, Monkyyy wrote:


 So, if you live in the current world you should dislike nan?


Programming is a big world.

For the things I do, nan works well. I've had to point out many 
times here and elsewhere that 0 is a great default if you're 
going to calculate a sum. If you're taking a product, it's an 
absolute disaster, and it's hard to detect unless you end up with 
something like a division by zero. At least nan doesn't work its 
way through the system silently, and it's easy to test for 
errors, unlike the case of 0.

If nan is a problem, then `double x;` shouldn't compile. Setting 
x to 0 is no better for correctness than setting it to a random 
number. Either way, you're pretending the compiler knows what it 
should be, and that's impossible.
Apr 29
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 14:58:00 UTC, bachmeier wrote:

 Setting x to 0 is no better for correctness than setting it to 
 a random number. Either way, you're pretending the compiler 
 knows what it should be, and that's impossible.



 *no better*


trade offs and downsides do not imply relativism

"different countrys use different drinking ages, lol laws have no 
right answers, better legalize cannibalism"

0 is correct for sum, 1 is correct for products, random numbers 
are even ok; yes so there tradeoffs between any of these; but nan 
is a black hole specifically designed to break everything

For real time systems the end up making calls to gpus that do 
nothing with nans; all floating point math will have 1000's of 
math operations that will probably never have a type error or a 
crash where partial solutions such damping math break only for 
nans.
Apr 29
parent reply bachmeier <no spam.net> writes:
On Monday, 29 April 2024 at 17:52:12 UTC, monkyyy wrote:

 On Monday, 29 April 2024 at 14:58:00 UTC, bachmeier wrote:

 Setting x to 0 is no better for correctness than setting it to 
 a random number. Either way, you're pretending the compiler 
 knows what it should be, and that's impossible.



 *no better*


 trade offs and downsides do not imply relativism

 "different countrys use different drinking ages, lol laws have 
 no right answers, better legalize cannibalism"


This misses the point. You don't use drinking ages to determine 
the "correct" age at which drinking should be allowed to start. A 
computer program should produce the correct answer every time it 
runs. Having variables initialized to a particular value is 
better than nothing, but better than that is if `double x;` fails 
to compile and you explicitly set it to what you need.


 0 is correct for sum, 1 is correct for products, random numbers 
 are even ok; yes so there tradeoffs between any of these; but 
 nan is a black hole specifically designed to break everything


It's no more of a black hole than 0 or 1. It can be used to 
represent missing data, which is just as valid as 0 or 1. Does 
that mean it's a good choice for initialization of a double? I 
don't think so, but that does not justify using 0.
Apr 29
next sibling parent claptrap <clap trap.com> writes:
On Monday, 29 April 2024 at 18:53:24 UTC, bachmeier wrote:

 It's no more of a black hole than 0 or 1. It can be used to 
 represent missing data, which is just as valid as 0 or 1. Does 
 that mean it's a good choice for initialization of a double? I 
 don't think so, but that does not justify using 0.


There's only one correct value to initialise the float too and 
only the programmer knows what that is. The chances are that 0 is 
alot more likely to be correct by accident than NaN is.

So the only argument for NaN is that it's easier to trace 
forgotten initializations. (my experience is that it's no better 
than 0)

But if you buy that argument then it logically follows that a 
compiler error on missing initialization would be **far** more 
effective at locating the bug.

Walters argument against that is that people will just slap zero 
in there to silence the error. I would argue that they will do 
exactly the same if it's NaN initialized, it'll just involve a 
lot more effort to actually trace back to find out where to slap 
the zero in.
Apr 29
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 29 April 2024 at 18:53:24 UTC, bachmeier wrote:

 A computer program should produce the correct answer every time 
 it runs.


not in videogames and rendering; the goal is often make pretty 
colors; bugs are often features


 0 is correct for sum, 1 is correct for products, random 
 numbers are even ok; yes so there tradeoffs between any of 
 these; but nan is a black hole specifically designed to break 
 everything


 It's no more of a black hole than 0 or 1.


In dynamic systems, as as the usual example of foxes and rabbits 
where a fox needs to eat 3 rabbit every year and every year 
rabbits double, therefor blah blah blah write out some math

given a vector field there are sources, sinks and black holes; 
theres some equaliumlam where foxes and rabbits are in balance 
and there will be an rough orbit around a "sink", theres also 
sources such as when rabbits are out of balence with foxes

then there are black holes of 0 where either int went extinct/0

nan is a black hole for basically every primitive function (by 
design) and therefor as I pull dynamic systems out of my ass and 
hope they make nice animations or systems or pretty colors, nan 
is basically *always* a black hole unless I specifically designed 
each and every pathway to avoid it in a way 0 or 1 never are, 0 
is only a black hole for multiplication and its an identity for 
adds, so its not even comparable
Apr 29
parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 20:01:18 UTC, monkyyy wrote:

 On Monday, 29 April 2024 at 18:53:24 UTC, bachmeier wrote:

 A computer program should produce the correct answer every 
 time it runs.


 not in videogames and rendering; the goal is often make pretty 
 colors; bugs are often features


If you're fine with bugs I imagine you'd be in the zero-init 
camp.  Not much point to NaN as a debug aide if FP correctness is 
defined loosely enough.


 0 is correct for sum, 1 is correct for products, random 
 numbers are even ok; yes so there tradeoffs between any of 
 these; but nan is a black hole specifically designed to break 
 everything


 It's no more of a black hole than 0 or 1.


 snip...

 then there are black holes of 0 where either int went extinct/0

 nan is a black hole for basically every primitive function (by 
 design) and therefor as I pull dynamic systems out of my ass 
 and hope they make nice animations or systems or pretty colors, 
 nan is basically *always* a black hole unless I specifically 
 designed each and every pathway to avoid it in a way 0 or 1 
 never are, 0 is only a black hole for multiplication and its an 
 identity for adds, so its not even comparable


I agree, they are not comparable.  NaN was designed to be a 
universal "something went wrong" return value, a sticky one.  If 
you don't need/want that then you're probably a zero-init 
devotee.  If you do want it, to represent general failure as well 
as failure to init, then you're gonna want NaN init.  A single, 
reliable, automatic, unambiguous, "black hole".
Apr 29
prev sibling parent reply claptrap <clap trap.com> writes:
On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

 On Monday, 29 April 2024 at 10:15:46 UTC, evilrat wrote:

 On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 If they're silent how do you know they failed?


 Because you get to debug a silent runtime error all the time, 
 and at this point I just assume it's a float being nan

 I'm pretty sure this is just the gpus reaction to nan, draw 
 calls being ignored



 always add zero initializer for float/float arrays.

 Very few libraries handle nans correctly from my limited 
 experience.


 If you live in a world where no one checks for NaN at any point 
 at any time and/or where a default zero will never hide an 
 error then yep, you're gonna dislike NaN init.


If you're converting float to int, which is essentially all the 
time for a software rendering, then NaNs usually end up as 
0xFFFFFFFF, which is no better than zero.

And you literally dont want to litter the fast path with NaN 
checks. You probably could do with asserts but it'd be far more 
useful to just get a compiler error on uninitialised floats.

I mean if the whole argument is default init to NaN helps catch 
uninitialized variables, there's a far more effective solution. 
That would **actually** be useful.

Default init to NaN is not useful, its not worse than zero, but 
it's not better. And you might actual want to init to zero 
sometimes.
Apr 29
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 19:22:54 UTC, claptrap wrote:

 On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

 

 If you live in a world where no one checks for NaN at any 
 point at any time and/or where a default zero will never hide 
 an error then yep, you're gonna dislike NaN init.


 If you're converting float to int, which is essentially all the 
 time for a software rendering, then NaNs usually end up as 
 0xFFFFFFFF, which is no better than zero.


Yes, if you transform away from FP you either check beforehand or 
lose any benefit.


 And you literally dont want to litter the fast path with NaN 
 checks. You probably could do with asserts but it'd be far more 
 useful to just get a compiler error on uninitialised floats.


Yeah.  I don't think anyone does NaN checks in the fast path 
(unless they're trying to locate the index of some NaN after 
being alerted with a less localized NaN).  NaN being designed to 
be sticky/cumulative helps.


 I mean if the whole argument is default init to NaN helps catch 
 uninitialized variables, there's a far more effective solution. 
 That would **actually** be useful.

 Default init to NaN is not useful, its not worse than zero, but 
 it's not better. And you might actual want to init to zero 
 sometimes.


It may not be useful to you, sure, but it is useful to others.

I would join the zero-init contingent if I never planned on using 
NaN, not even as a weakened backstop in unit testing; if I exited 
the FP domain before getting any use of it, say, or if all my 
programs worked correctly with zero init (or at least I *thought* 
they did) or ...?

Also, as noted earlier, people weigh the pros and cons 
differently.  As for me, I'm happy that we have NaN init.
Apr 29
prev sibling parent Hipreme <msnmancini hotmail.com> writes:
On Monday, 29 April 2024 at 19:22:54 UTC, claptrap wrote:

 On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

 [...]


 If you're converting float to int, which is essentially all the 
 time for a software rendering, then NaNs usually end up as 
 0xFFFFFFFF, which is no better than zero.

 And you literally dont want to litter the fast path with NaN 
 checks. You probably could do with asserts but it'd be far more 
 useful to just get a compiler error on uninitialised floats.

 I mean if the whole argument is default init to NaN helps catch 
 uninitialized variables, there's a far more effective solution. 
 That would **actually** be useful.

 Default init to NaN is not useful, its not worse than zero, but 
 it's not better. And you might actual want to init to zero 
 sometimes.


My main problem against NaN is that it puts NaN on registers 
instead of checking and throwing.
Apr 29
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

 On Monday, 29 April 2024 at 03:51:09 UTC, Bruce Carneal wrote:

 If they're silent how do you know they failed?


 Because you get to debug a silent runtime error all the time, 
 and at this point I just assume it's a float being nan


OK, so "silent" here means that the function you invoked did not 
report the error rather than that the error went undetected (and 
that the fix is simple if annoying to the "never NaN" contingent).
Apr 29
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Friday, 26 April 2024 at 23:14:41 UTC, Matheus Catarino wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


 And what would be the selling point?

 If GC were to receive more (offensive) criticism, compared to 
 other languages, it wouldn't be worth it.

 I'm not a game developer, but when it comes to graphics 
 programming dealing with floating point, NaN will be a problem 
 that not everyone has experience or patience in dealing with.



These sort of statements are ridiculous considering there are 
many AAA games (including open world games) written in JavaScript 
using Webgl.

Dagon (check dub repository) has so many samples written using 
the engine. D can do noGC, GC, and RC so it'll be more of a skill 
issue than a language barrier.
May 03
prev sibling next sibling parent Kagamin <spam here.lot> writes:
I think it also demonstrates shortcoming of safety by default. 
Agility in rust should be possible with unsafe blocks, but you 
can't use unsafe blocks because it's anathema, and simply beyond 
your reasoning ability.
Apr 27
prev sibling next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


I think what is meant by AAA is a concept related to the game 
world, isn't it? Or is it about Rust Programming Language?

SDB 79
Apr 27
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, April 27, 2024 9:49:34 PM MDT Salih Dincer via Digitalmars-d 
wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


 I think what is meant by AAA is a concept related to the game
 world, isn't it? Or is it about Rust Programming Language?

 SDB 79


https://en.wikipedia.org/wiki/AAA_(video_game_industry)

- Jonathan M Davis
Apr 27
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 https://loglog.games/blog/leaving-rust-gamedev/

 Discussion here: https://news.ycombinator.com/item?id=40172033

 We should encourage these people to check out D


This reminds me of my experience of converting a simple 
imperative-style Monte-Carlo simulation program from D to 
Haskell, to learn and test the limits of the latter.

It took far more time than writing the D program.

Contrary to the stereotype, Haskell can 100% imperative 
programming and raw mutable arrays. With the right library 
abstractions, it's even good at that. But, to do that efficiently 
you have to be experienced and understand a lot of abstractions 
inside out.

This is because the language primitives are immutable and pure 
mathematics-style entities, I/O and mutability is treated as a 
special library abstraction. At least in principle, I feel it's 
the correct way to go about things. Pure code is the recommended 
default in pretty much any language after all, when there is no 
specific reason to do otherwise.

But man does that steepen the learning curve for some tasks. 
Ironically, you don't need to know monads nearly as well to excel 
pipes-and-filters-style programming as you have to excel with 
mutable arrays.

That's what Haskell is like: you have to jump through many hoops 
to understand how you can get things done, but when you finally 
do the solution is almost without fail extremely powerful and 
to-the-book, and usually there is a solution no matter what 
you're trying to achieve. By the way, that also what Nix package 
manager is like, compared to the traditional alternatives.

To me the article reads like Rust is pretty similar. Whether 
that's a good or a bad thing, comes mostly down to preference.
Apr 30
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 We should encourage these people to check out D


Can you point to some games made with D?
May 02
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Thursday, 2 May 2024 at 09:25:39 UTC, Ogi wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 We should encourage these people to check out D


 Can you point to some games made with D?


Not entirely in D but a major one - Quantum Break.
The engine itself is in C++ but all game logic is in D AFAIK.

The rest is like more of a indie game jam projects or a mini 
games, I remember there was some portal clone related with dagon 
engine https://github.com/gecko0307/electronvolt

which seems to be formerly this game
http://dlanggamedev.blogspot.com/p/atrium.html

Another relatively known game - vibrant, unfortunately i'm not 
100% sure if it is written in pure D or even has any D in it.
https://www.auburnsounds.com/blog/2017-02-13_Vibrant-2.0-released-free-demo.html

And that's probably it, there is probably more but authors 
probably never announced it here.
May 02
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 2 May 2024 at 09:41:33 UTC, evilrat wrote:

 Another relatively known game - vibrant, unfortunately i'm not 
 100% sure if it is written in pure D or even has any D in it.
 https://www.auburnsounds.com/blog/2017-02-13_Vibrant-2.0-released-free-demo.html


Yes I did many times, it was full D of course.
I've an outdated list of games in D here: 
https://p0nce.github.io/d-idioms/#Games-made-with-D there is 
probably more now
May 02
parent Guillaume Piolat <first.name gmail.com> writes:
As for the original topic: this sort of blog post that 
essentially says "X is unpractical" is the kiss of death for 
practical people that care about productivity and flow... 
Software exist in crowded niches and must win the heart of the 
user before having the right to exist, and the way to do that is 
with quickness not a more "correct" way.
May 02
prev sibling next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Thursday, 2 May 2024 at 09:25:39 UTC, Ogi wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 We should encourage these people to check out D


 Can you point to some games made with D?


One of the best games ever made was made with D. Link: 
https://kapendev.itch.io/a-short-metamorphosis


 We should encourage these people to check out D


There are some problems though. I would say that it's not really 
easy for a new D user to find game dev related stuff for D. I am 
talking about libs, blogs, videos and everything similar that can 
help someone at the beginning.
May 03
prev sibling parent Kenny Shields <mail kennyshields.net> writes:
On Thursday, 2 May 2024 at 09:25:39 UTC, Ogi wrote:

 On Friday, 26 April 2024 at 18:41:11 UTC, ryuukk_ wrote:

 We should encourage these people to check out D


 Can you point to some games made with D?


Made this game using a 2D engine that I've been working on for a 
while: https://kenny-shields.itch.io/imperium-scenario-system. 
Both projects are written in D.
May 03