Fixed regression where txt files were baked as HBOs.

HURRRR !
Tron Le 18/10/2016 à 22:23 Respirer aussi, je crois.
Et naitre, hein, naitre.
Il en dit un peu plus que ça quand même, et je suis plutôt d'accord avec lui.
Pen^2 Le 18/10/2016 à 22:30 C'est peut-être un peu exagéré tout de même, et surtout ça manque un peu de références : il faut se méfier des "naturopathes" qui sortent leur discours d'on ne sait où. Ils virent parfois assez vite dans le n'importe quoi au détour d'une phrase.
very Le 19/10/2016 à 12:37 Je compatis. En trouver qui ont un cerveau MAIS qui ne sont pas casse-couilles relève de l'exploit
«Les gens exigent la liberté d’expression pour compenser la liberté de pensée qu’ils préfèrent éviter.» - Sören Kierkegaard
La République, c’est comme la syphilis : quand on l’a attrapée, soit on se fait sauter le caisson, soit on essaie de vivre avec.
(par contre attends pas trop avant de le boire ou de le melanger, ca va sentir la weed partout dans l'open-space apres)

HURRRR !
Tron Le 19/10/2016 à 15:49 C'est bon ça...
N’empêche, je reste sur SSHD histoire d'avoir au moins un fallback mécanique en cas de défaillance de la flash.
How does it scale to other memory layouts than the 'page model' ? (IE: GPU storages), the fact that it's per-page, and localized or not is an implementation detail that ideally should not leak to the user if we want a scalable, transparent system.
Having such a thing will mean the user, if he/she uses an explicit "per-page engine query", is designing this layer for CPU sim only, and it won't scale conceptually to GPU (or the GPU sim will just have to discard the whole idea, because it has no concept of pages (and forcing the GPU storage to use larger pages is an easy option I'm not eager to take)).
I'd much prefer a higher-level concept such as a "LOD-able" engine query, not "per-page".
The CPU sim would translate such a LOD-able" query to per-particle for close pages, to per-page for far away pages, GPU sim would be able to safely do whatever it likes as well (think slicing of particle storage in the sim buffers directly maybe, although it only works for a single cam, or z-ordering of the particle buffers, allowing to run stuff at a lower granularity per-wavefront, as wavefronts would be localized)
Taking this further, it could be unified with the concepts of lower-rate execution for a sub-node graph.
Lower-rate execution is a time-domain decimation.
Per-page or distance-based execution is a spatial-domain decimation.
Unifying those concepts would allow users to tell the runtime how it's acceptable to decimate the execution for a sub-graph: across the time domain, spatial domain, or both, with different metrics / weights.
ie: user says to PopcornFX "you are allowed to run this part less often spatially, it won't make a big difference"
This doesn't leak implementation details, the concepts remain valid across different simulators that work differently, and allows them to implement it in the most effective way for their underlying data representation.

HURRRR !
<ApplicationDataDir>$(******SdkContentDirectory)</ApplicationDataDir>
(ah ouais tiens ^^)

HURRRR !
Vous avez utilisé le Sortilège : ANALYSE ANATOMIQUE sur kremdetroll (509)
Niveau : 60
Points de Vie : Inimaginable (entre 230 et 250)
Blessure : 60 % (approximativement)
Dés d'Attaque : Inimaginable (supérieur à 24)
Dés d'Esquive : Jamais vu (entre 20 et 22)
Dés de Dégât : Inimaginable (supérieur à 24)
Dés de Régèn. : Jamais vu (entre 9 et 10)
Dés d'Armure : Fort (entre 6 et 8)
Vue : Fort (entre 6 et 8)