Reprise du message précédent :

Bah non, si tu fais du real time (e.g. embedded), tout spécialement hard real time, c'est toujours ça

C'est juste que toi tu préfères faire de l'oracle et du C#

Et même en JV, quand t'as un budget de 16ms pour le rendu intégral de ta frame en HD, ben t'as intérêt à comprendre le code qui sort de ton compilo

je sais, je suis un faible
ceci dit, il m'est arrivé de trifouiller le code MSIL sorti par C# pour optimiser 2-3 trucs

Ouais enfin c'est du MSIL, ça fait tapette quand même

Si t'es branché, tu peux en trouver d'autres (certains avec le code source) par là : http://pouet.net/prodlist.php?type[]=256b&order=views

Merci  

tu materais juste l'url qui me semble avoir été broyée ...
pouet.net/prodlist.php?type[]=256b&order=views

It's a feature

en zieutant le source, on voit que les mecs ne sont pas rock'n'roll, ils ont tout codé à la FPU, y compris les transferts mémoire de buffer vers écran
pas de virgule fixe, pas de précalcul des sinus, des multiplications dans tous les sens...
ça aurait augmenté la taille de l'éxecutable, mais aussi le challenge, dommage

 
SolVBE ou VDMSound ? (J'exploite le premier pour le boulot, et effectivement j'utilise aussi l'assembleur pour des parties d'interface ou de driver, toujours pour le boulot, donc oui l'assembleur x86 ca peut être utile)