bha...

Le C et la 3D n'ont pas beaucoup de points communs :gniah:

de toutes façons, tout ces calculs sont en double, la vitesse ne changera pas ...

Si tu peut faire de l'assembleur, ça sera plus rapide.

[TheDarkTiger] a écrit:

Si tu peut faire de l'assembleur, ça sera plus rapide.

plus rapide en exécution.

Oui pas de problèmes pour l'assembleur mais si on s'occupe des nombres à virgule va falloir que j'utilise le co-processeur arithmétique et ça va être joyeux. :gniah:

2261 cycles = 0.000000588 secondes.

Et c'est quoi au juste les "2261 cycles" ? :hehe:

Enfin en tout cas ça à l'air plus rapide que l'essai de DLL que j'avais fait ^^

bibi675 a écrit:

2261 cycles = 0.000000588 secondes.

c'est lamentablement lent ton truc :non:

nicoulas a écrit:

Et c'est quoi au juste les "2261 cycles" ? :hehe:

C'est le nombre d'impulsions que prend l'addition des deux nombres sur les 3 847 550 000 impulsions que mon processeur peux traiter par seconde.

@ shm : ouè l'ascenbleur c tro naz é pi c trop lon :non: :non: :non:

mais tu fait de l'assembleur avec quoi ?
delphi ?

Ouaip.

Merci pour l'explication des cycles ^^

Je te donne les formules dont j'aurais besoin pour la dll :

nx = (y2-y1)*(z3-z1)-(y3-y1)*(z2-z1);
ny = (z2-z1)*(x3-x1)-(z3-z1)*(x2-x1);
nz = (x2-x1)*(y3-y1)-(x3-x1)*(y2-y1);
divide = sqrt(nx*nx + ny*ny + nz*nz);
nx /= divide;
ny /= divide;
nz /= divide;

(sérieux je vois pas trop comment passer ça en dll pour qu'elle renvoie les trois valeurs à la fois )
En input, j'ai besoin de spécifier x1,x2,x3,y1,y2,y3,z1,z2,z3 et j'ai besoin en output de nx,ny et nz (logique ^^)

Puis après si tu arrive à faire un calcul de moyenne plus rapide que dans GM (attention je parle pas de la fonction mean(); je parle de faire le calcul 'manuellement') :
(il faut que je calcule la moyenne de 6 arguments et ce ne sont pas des nombres entier)
donc : (arg1+arg2+arg3+arg4+arg5+arg6)/6
Mais si c'est pas plus rapide que dans GM c'est pas la peine :lng:

Au fait, pour ces calculs, j'ai pas besoin d'une précision géniale (je pense qu'une précision au centième ou au millième serait suffisante), donc après je sais pas si tu peux obtenir une moins bonne précision que sur ton screenshot pour accélérer encore les calculs).

nicoulas a écrit:

Mais si c'est pas plus rapide que dans GM c'est pas la peine :lng:

Ça dépend si GM gère bien les DLLs ou pas mais si la gestion est correcte ça va être 3 à 5 fois plus rapide.

Et pour les calculs, c'est cool je vais pouvoir utiliser des types de variables plus compacts donc plus rapide, je m'y met de suite.

Yeah génial !
Le meilleur compromis vitesse/qualité serait une précision au millième près (parce que centième serait peut être un poil juste vu que ce sont des coordonées de vecteurs), mais si tu peux faire qu'au centième te tracasse pas non plus ^^

Le format le plus léger accepte 4 décimales donc on va pas s'en priver par contre je ne gère pas les nombres négatifs (j'espère qu'il n'y en a pas).

Malheureusement, si ...


J'en profite pour une nouvelle screenshot qui montre un exemple de texture splatting : vous spécifiez entre 2 et 6 textures qui s'appliquent au terrain en fonction de la hauteur, et c'est une fonction qui mappe les texture spécifiées et qui en fait une texture (ça prend plus de RAM et de Vram, mais ça utilise moins de processeur que de dessiner tout ça en temps réel, puis on peut choisir la taille de la texture que l'on veut).

Bref :

Spoiler:

nicoulas a écrit:

Malheureusement, si ...

Et ben justement après 5 heures de travail acharné, la fonction est prête et elle supporte les nombres négatifs ! Je coderais la DLL demain maintenant je vais me coucher. :oui:

PS : maintenant faut faire des prières au roi banane pour que GM fasse des appels de DLLs performants.

Yeah merci beaucoup, j'espère que grâce à ta dll on pourra gagner au moins quelques dixièmes de secondes

Je vais faire des tests en cyclant le code avec GM puis avec ma DLL, on sera fixé.

tu génère ta texture puis tu l'applique normalement c'est bien ça ?

tu crée une texture appropriée hein?

sinon, je vais élever des chèvres dans le larzac moi ..

Bon je suis déçu, ma fonction n'est que 2 fois plus rapide. Enfin c'est toujours ça...

Je vais m'attaquer à la racine carré maintenant.

@ TDT : Oui c'est bien ça, t'inquiètes pas, je suis pas le messie

@ Bibi : Bah deux fois plus vite ce sera déjà énorme ! A mon avis y'a de quoi gagner entre 0,2 et 0,5 secondes

Toutes les fonctions sont implémentées, ma fonction de racine carrée va 1,7 fois plus vite que celle de GM.

EDIT : sinon dans tes fonctions "get_height", tu m'avais pas parler de ça :

Code:

a = (-d*y2*z3-d*y1*z2-d*z1*y3+d*z1*y2+d*z2*y3+d*y1*z3)/D;
b = (-d*x1*z3-d*z2*x3-d*z1*x2+d*z1*x3+d*z2*x1+d*x2*z3)/D;
c = (-d*x1*y2-d*y1*x3-d*x2*y3+d*x3*y2+d*x1*y3+d*x2*y1)/D;

En tout cas la DLL fait 10 Ko, tu peux la télécharger ici. Je l'ai appelé Turbo_Heightmap et j'ai inclue un GMK d'exemple où tu peux voir comment l'initialiser.

Bon courage pour la suite !

Le rendu de la texture en fonction de l'altitude, c'est une excellente idée.

Je reste con, quand je vois que vous arrivez à faire des matrices de plus en plus ... belles et performantes :gniah:

bibi675 a écrit:

Hum à mon avis si, draw_getpixel() bouffe vraiment beaucoup de perfs... Je vais regarder de mon côté en attendant ton optimisation.

La solution en fait est de tout dessiner sur une surface, puis d'utiliser la fonction surface_getpixel() qui est beaucoup plus rapide.

@ Bibi : éventuellement, si t'as rien à faire, je veux bien, mais je suis pas sûr que le gain de vitesse se fasse beaucoup ressentir (enfin peut être que si si on doit calculer la hauteur en de nombreux points) vu que là ce n'est pas dans un boucle comme dans la génération.

Donc si tu sais pas quoi faire, je veux bien car ça améliorera toujours au moins un peu les perfs ^^

@ Topaze : Merci ^^ (que dire d'autre ^^)

@ Master : Quoi ?! Tu es fou ? La fonction surface_get_pixel(); est vraiment immensément plus lente que draw_getpixel() ! (enfin faut dire que mon ordi a une mauvaise carte graphique, mais bon au lieu de 3 secondes de génération, je passe à environ 15 secondes !)

houla... très bizarre, c'est l'inverse chez moi... pas grave.

Sinon il y a tj ca :

http://covac-software.com/download.php?id=3

nicoulas a écrit:

@ Bibi : éventuellement, si t'as rien à faire, je veux bien, mais je suis pas sûr que le gain de vitesse se fasse beaucoup ressentir (enfin peut être que si si on doit calculer la hauteur en de nombreux points) vu que là ce n'est pas dans un boucle comme dans la génération.

Ah ok je croyais que c'était dans une boucle... Sinon elle marche ? Ya pas de soucis particuliers ?

@ Matser : Je vais voir ça mais si c'est une dll ça va finir par poser problèmes d'avoir 27 dll pour le moteur quoi
(en plus pas sûr que ça marche avec une dll)
Edit : ok c'est un script ça peut être intéressant, merci

@ Bibi : Désolé là mon ordi est surchargé là (trucs ouverts) donc j'ai pas encore testé, je regarderais sans doute ce soir, merci beaucoup à toi

Ok ^^ et de rien (ça m'a permit de bien comprendre le FPU, c'est très dur au début mais au fur à mesure, ça vient tout seul).

Je viens (enfin!) de tester ta dll, ça a l'air vraiment parfait !
Juste une petite précision, les 3 arguments pour la racine carrée correspondent à nx, ny et nz de mon code c'est bien ça ?

Ouaip, le coprocesseur les doubles automatiquement. :fier:

PS : et t'as vu, je me suis appliqué : la DLL ne fait que 9 Ko. ^^