OT: Leaving Rust gamedev after 3 years

[claptrap]

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
>>
>> Yep, rule #1 for me, when see extern C/C++ type/function - 
>> 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.