Moteur de terrain 3D

Oui vraiment génial ça, et encore en compressée en zip (niveau de compression normal), elle pèse 4.5 ko
Ce soir j'ai pas eu le temps de l'inclure, mais demain sans soucis je vais pouvoir l'inclure dans mon moteur, je vous tiens au courant des nouvelles perfs dès que les premiers tests seront faits :nezrouge:

et moi qui ne peut plus avancer mon projet faute de temps :snif2:

nicoulas a écrit:

Oui vraiment génial ça, et encore en compressée en zip (niveau de compression normal), elle pèse 4.5 ko
Ce soir j'ai pas eu le temps de l'inclure, mais demain sans soucis je vais pouvoir l'inclure dans mon moteur, je vous tiens au courant des nouvelles perfs dès que les premiers tests seront faits :nezrouge:

non mais c'est pas la peine de réduire votre dll a des tailles ridicule, ça me rend jaloux

Lol shm, je crois que tu prog en Delphi toi en plus. Ce qui est bien avec l'assembleur inline dans Delphi c'est que tu n'as pas besoin de SysUtils donc je me suis chargé de déclarer moi-même le type Real et le poids du fichier s'en fait ressentir. (j'ai rien dans les uses)

PS : sources disponibles si ça intéresse quelqu'un.

Vasy, distri

Vlà : http://www.edgar-fournival.fr/obj/CBNA/turbo_heightmap_src.zip (772 octets).

Bon après beaucoup de tests, les dlls n'accèlèrent pas mais au contraire ralentissent légèrement le temps de calcul, donc je ne vais pas pouvoir gagner beaucoup de temps de calcul

Aussi, le moteur est maintenant 100% compatible GM6 et j'ai encore amélioré un peu le vitesse de calcul d'un terrain.

J'ai encore un problème de transparence avec les surfaces que je n'arrive pas à résoudre, mais j'ai toujours une solution de secours (bien que 'bancale' ^^).

Si tes Dll n'améliorent pas ta vitesse, il te reste une solution :
Met tes calcules en drag and drop, le drag and drop est compilé sous GM
[je plaisante pas]

Ah tiens je le savais pas ça !

Le seul problème ça va être d'appeler du D&D dans un script en GML

Bah autrement que par une alarm... Ou sinon tu pet le début du script dans l'objet, la fonction drag and drop et tu continues derrière.
Sinon le temps de calcul des dll vient, je pense, du temps d'accès. J'avais essaye de programmer une dll pour faire du bbox mas en lui envoyant plein de
Coordonnées a chaque step, ça ramais plus que en faisant les calculs sous gm.

Oui, et il doit y avoir d'autres moyens.

Si j'ai bien saisis, le code que l'on tape dans GM, c'est une exécute string...
Donc c'est très lent...

Par contre le drag and drop serait vraiment compilé.

M'enfin, si je devine juste, GM8 sera vraiment compilé donc ce que l'on écrit dans les morceaux de code, ce devrait être vraiment compilé.
D'ou la "puissance dû à une meilleur compilation" dont je vous parlais sous GM8.

Ce dernier point reste à vérifié, mais j'y crois à 90%. (car Mark a dit quelque part... je ne sais plus quoi, mais je crois que c'est ce que je viens de dire...)

Donc gm8 va être une vraie turie qui mettra 2 jours a compiler un truc. Plein de bonnes nouvelles.
Je dec bien sur

Tu es sur que le D&D est compilé ? Car j'ai décompilé une vieille application que j'avais faites il ya longtemps avec GMDecompiler et le D&D apparaissait normalement...

Sincèrement, vue tout ce que j'ai lus dessus, venant même des écrits et commentaires de Mark...

Je ne suis pas sûr à 100% car ça remonte, mais je le pense assez fortement car les plus calé de la communauté anglophone semblaient le pensé ainsi aussi.

Ce serait bien si un jour, Mark nous accordait un interview, pas pour le coincer sur des infos qui sont confidentielles, mais pour mettre au claire certaines.

boah on est quand même l'une (si ce n'est pas la) communauté française sous game maker la plus importante...
faudrait faire un topic où l'on pose nos question, un admin/modo les rassembles et les lui envoie... Ca marchera peut-être :oui:

On essayera en juillet

Topaze22 a écrit:

le drag and drop est compilé sous GM
[je plaisante pas]

Objection!

http://willhostforfood.com/access.php?fileid=64774

2000 milliseconds en D&D
500 milliseconds en GML

HOHOHO.

Très très étrange.
Mais le constat semble évident.

sauf s'il a truqué les résultats
le fourbe !

edi9999 a écrit:

Topaze22 a écrit:

le drag and drop est compilé sous GM
[je plaisante pas]

Objection!

http://willhostforfood.com/access.php?fileid=64774

2000 milliseconds en D&D
500 milliseconds en GML

Tu pourrais mettre un peu plus de chose dans l'action à répéter stp ?
Genre une boucle for qui incrémente une valeur tant qu'elle est plus petite qu' un million.

Yep nicoulas Ca en est où l'avancement ? Pour savoir si je peux espérer imaginer ma bataille navale en 3D ou pas Car vu que je la commence me faudrait savoir quelle optique je prends ^^

Enfin voila j'espère que cela sera que de bonnes nouvelles

J'ai pas beaucoup avancé depuis la dernière fois, faudrait que je m'y remette (mais j'ai un bug avec les surfaces, je peux le contourner facilement mais en faisant du "bricolage" et du coup cette méthode est plus lente).

Je vais essayer de faire le système de fluides puis je poste une nouvelle version

Un exe ?
Chic ^^

Alors, ou ça en ait ?
C'est en pause, mais ce n'est pas abandonné n'est ce pas ?
Je ne serais pas contre un petit .Exe comme tu nous l'avais promis ^^

Bah écoute, grâce à toi je viens de trouver le courage d'implémenter la gestion de fluides (quasi-fini, je rajoute un script et c'est bon), et le bug de texture splatting est résolu, bref, le moteur est vraiment pas loin d'être fini.

Je poste la source sûrement aujourd'hui, puis je complèterai plus tard avec des exemples, un manuel, etc.

Ho tu postes la source ?
Très intéressant ça

Oui je vais poster la source, je rajoute encore un truc (expliqué ci-dessous) et le moteur est fini ! (enfin même si je rajoute d'autres fonctions au fur et à mesure, je ferais en sorte que les fonctions ne changent pas d'arguments pour que quelqu'un qui utilise ce moteur puisse utiliser la dernière mouture sans avoir besoin de changer quoi que ce soit dans son code ).

Playboy a écrit:

Yep nicoulas Ca en est où l'avancement ? Pour savoir si je peux espérer imaginer ma bataille navale en 3D ou pas Car vu que je la commence me faudrait savoir quelle optique je prends ^^

Enfin voila j'espère que cela sera que de bonnes nouvelles

Tu es toujours intéréssé Playboy ?
Si oui tu va bientôt pouvoir utiliser mon moteur, car la gestion des fluides n'est pas trop mauvaise (je trouve ^^), même si je n'ai pas encore implémenté la gestion des remous dûs à la chute d'un corps dans le fluide.
On peut déjà gérer la hauteur des vagues, la fluidité du liquide (plus il est fluide, plus les vagues seront rapides et inversement) ainsi que le défilement d'une texture sur le fluide

Je viens de terminer le script simulant la chute d'un corps dans un fluide (vague en cercle partant de l'objet et s'en éloignant petit à petit).

Pour illustrer, le script fait grosso-modo ça (en moins beau bien sûr vu qu'il n'y a pas d'effet d'éclaboussement ni plusieurs vagues successives mais une seule) :

Spoiler:

J'ai juste à ajuster les paramètres et cette fonctionnalité sera terminé, mais je compte en rajouter encore une dernière (très simple et rapide à rajouter).

Si tout se passe bien, demain je poste la source

PS : Je poste pas de screenshot parce que poster une screen de quelque chose qui a seulement de l'intérêt en mouvement, c'est pas top ^^

Woaaaww de la physique qui tue couplée à du Ray-tracing//Je plaisante


Playboy est parti deux semaines en Corse (me laissant seul sur Toulon...), il revient dans une semaine.

Dis moi, tu gères l'eau à part///Donc en théorie, elle se superpose à ta matrice sur lors de l'affichage non ? PS : ça doit bouffer un max, les vertex dynamique, ça bouffe beaucoup !?