Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Apr 2011
Offline Last Active Feb 19 2016 05:52 PM

Posts I've Made

In Topic: Procedurally-regenerating identical content on different machines (floating p...

19 February 2016 - 05:15 PM

Thanks for the replies.


STREFLOP is worth a look.
Though I don't see any particular barrier to designing new noise functions using integer math, and it's certainly possible to write them with a fixed-point math library.


Cheers, I'll take a look at that, and will investigate creating modified noise algorithms.


Have you considered using fixed point numbers rather than floating point?


Yep. I don't have a sense of how that would affect performance though. I think I'm going to have to simply experiment with this and come to my own conclusions.


Sometimes you can get away with dropping the requirement for bit-for-bit identical results in the later stages of generation, as long as the early stages are perfectly identical.  Depending on the particular kind of procedural generation you're doing, this can possibly make things much easier.  Perhaps most of the numerical instability exists during the early/mid stages of generation, and so you can deal with that by using fixed point math, while a bunch of the heavy number crunching happens during the later stages, so you can switch to floating point and perhaps offload some of the work to the GPU.  Even if different GPUs produce different results, if the late-stage algorithms are numerically stable, they might still be close enough to work.


Yeah I'd considered that, and it is certainly applicable with respect to the projecting of source data into client-side game assets. The problem is that the "server" component must be able to canonically represent all game state, including the results of positional changes due to physics. Because those tend to use compounded floating operations, I have a feeling they're going to be a problem for me. Perhaps there's an opportunity to get creative with physics code...


The guys over at Epic actually created a custom floating point class for both 16 and 32bits. Their reasoning marked up in the comments was that a floating point was not always the same across systems.


Sounds interesting, I'll look further into that, thanks.

In Topic: Procedurally-regenerating identical content on different machines (floating p...

17 February 2016 - 11:42 PM

Thanks for the reply, and what you have said sounds pretty much like what I've been anticipating is going to be a problem, particularly with respect to the fact that my design wants to facilitate a significant number of community-driven add-ons.


The most safe route is to use a software-based numerics library that guarantees deterministic results and does not rely on CPU-implemented functionality. They can potentially also be faster if the optimizer is allowed to hit them, whereas using the processor's floating point requires many pessimizations and constant validation that the system is still in the proper state.


Any you'd recommend?

In Topic: An appeal to programmers and artists from a Melbourne Kid

16 November 2015 - 01:25 PM

I'll just leave a couple of things here:

In Topic: Thoughts on the Boost.Build system? (as opposed to CMake?)

06 October 2015 - 08:48 PM

Personally I like to place my build directory as a 'build'-subdirectory of my source directory and set that directory to be completely ignored by source control. Others require the build directory to be completely separate (for example 'D:\projects\myproject' and 'D:\projects\myproject-build'.


Yeah I do this too, irrespective of build system. I guess I just need to learn CMake a bit more than I have.

In Topic: Thoughts on the Boost.Build system? (as opposed to CMake?)

05 October 2015 - 05:14 PM

I don't think I ever had that problem. Maybe you are doing something wrong?


Very possibly. All I know is that when I run CMake on various different projects that are not mine, I end up with loads of solution files, with extra solutions like ZERO_CHECK and so forth, and a bunch of other accompanying files and folders, all cluttering up the root directory.


If you do an out of source build, you can isolate the generated cmake files to a build directory tree and avoid polluting your source.


That sounds ideal. I'll look into that, thanks.


I use the Qt Build Suite (Qbs) with Qt Creator on Windows


I must admit, the ugliness of the QT IDE makes my inner snobby designer twitch a bit... I bet it's really good though. Maybe I should look into it a bit more than I have...