You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it better to provide a single PRNG as part of the API and ignore any PRNG impls provided by platforms (current design)? If so, the API would require an init hook to obtain at least a seed value from the adapter (which always has to be sourced in a platform-specifc way).
Some benefits of a single PRNG would be: 1) de-duplication of effort and 2) potentially improved portability of variations between platforms using different PRNGs (which wouldn't matter anymore). On the other hand, different platforms will also use different seed values/mechanisms, but this would only apply to platforms/deployments outside the artist's control (i.e. if I publish pieces on my own website "platform", I can control and ensure the same seeds are used for variations I already created during development)
If opting for a single PRNG:
handling should be similar to time providers, i.e. supply a default implementation, but allow artists to override it
seed format of the PRNG must be standardized (e.g. using the 128 bit seeds (4x 32bit uints) currently used for SFC32/Xorshift128)
platform adapters would require a getSeed() function to obtain a standardized seed value
The text was updated successfully, but these errors were encountered:
I have no strong opinion on this, but for whatever it's worth, in my artworks I most often use multiple PRNGs, e.g. one for colors, one for geometric shapes calculation, and so on (I typically have 4-5 of them). This makes it easier, when experimenting, to e.g. keep the colors in an output but alter the code that generates the shapes.
The different PNRGs are seeded from a "main" PRNG, so I guess my case can be still be framed as using a single PRNG ?
Thank you, @robertoranon — I'm also doing the same, using several sub-PRNGs, all seeded by the main one at startup — and yeah, I'd still file this under "single PRNG"... Here, I was more thinking about portability between different platforms (and their different PRNGs algorithms) and aiming for reproducibility of pre-curated variations when switching platforms. Personally, I'm thinking that, if this reproducibility is an actual concern, this can be ensured using your own per-artwork PRNGs internally, but I'm also sure there're different points of view... :)
Is it better to provide a single PRNG as part of the API and ignore any PRNG impls provided by platforms (current design)? If so, the API would require an init hook to obtain at least a seed value from the adapter (which always has to be sourced in a platform-specifc way).
Some benefits of a single PRNG would be: 1) de-duplication of effort and 2) potentially improved portability of variations between platforms using different PRNGs (which wouldn't matter anymore). On the other hand, different platforms will also use different seed values/mechanisms, but this would only apply to platforms/deployments outside the artist's control (i.e. if I publish pieces on my own website "platform", I can control and ensure the same seeds are used for variations I already created during development)
If opting for a single PRNG:
getSeed()
function to obtain a standardized seed valueThe text was updated successfully, but these errors were encountered: