[Non officiel] Concours SCRIPT (GML CUP n°2)

Déjà, ce calcul n'était là qu'a titre indicatif, c'est pas dit que ce soit celui là qui sera utilisé.

Ensuite, désolé, une image toute les 32 secondes, il faut multiplier ta résolution par (1/32) soit 0,03125.

Donc, en reprenant tes calculs, tu obtient une note de :

199 600

et non

338 110 000

soit quasi 1700fois moins que ce que tu avait calculé ...
(pour info, un moteur de raycasting en 320*240 à 30fps aurait à peut près 2 494 000points...)

Donc, comme je le disait, il faudra surement revoir ce système de notation.

Soit dit en passant, je trouve ton rendeur vraiment sympa O.O

merci :p
Sinon y a qu'a faire la moyenne des deux note \o/ , vu que le fps c'est pas trop fait pour un render vu que le but n'est que d'avoir une seule image.
Pour la suite j'ai peur que les calculs soit beaucoup plus lents... genre si je veux ajouter des matériaux spéculaires.
Par contre je suis presque sur qu'en C++ j'arriverais a faire du temps réel.

Je pense que je vais faire un système d'édition de scènes ou on pourras ajouter des lampes et des sphères dans une room (et on auras une estimation du temps de rendu).
La sa pourrais être marrant. Le tout compatible a 100% GM Lite et red-error seras content

onilink_ a écrit:

Par contre je suis presque sur qu'en C++ j'arriverais a faire du temps réel.

lawl, imaginez un jeu avec ce sytle de graphique ce seraai magnifique !

Ouai par contre un jeux juste avec des sphères faut trouver le gameplay adéquat

onilink_ a écrit:

Hohoho j'ai enfin ajouté les ombres, et amélioré les reflets et quelques performances.
Résultat avec 3 spheres, 2 lumieres, et 32 secondes de calculs ...

heureusement que je n'ai pas participé à ce concours

après avoir vu ce que oni à fait, et ce que sekigo à fait, je pense que l'on va abandonner, XD

Ah non hein ? Pas de ça, sinon la prochaine fois je garde tout secret. En plus le raytracing c'est super simple. La plupart des calculs sont de niveau première :
-Équations polynomiales du second degrés
-Produit scalaire
-Opération vectorielles
+ un cerveau actif

Je mettrais mon projet open source dans script a la fin du concours, mais si y a personne qui participe sa n'auras aucun intérêt.
Au lieu de dire qu'on fait des truc cool, essayez plutôt de nous surpasser (ce qui n'est pas tellement difficile qui plus est).
On joue pour gagner, mais avant tout pour évoluer dans des domaines aussi étrange que ceux proposés ici, et surtout pour s'amuser :p
Sur ce bonne nuit/semaine (moi j'ai ma rentré demain...) donc @+

Bien dit onilink_ !

Je suis sur que vous pouvez beaucoup plus que vous ne le pensez.

je n'ai jamais nié ça, le problème c'est juste que je gère très mal mon temps libre (minus les études : 8h en moyenne) et pour en rajouter une couche, j'ai vraiment la flemme de me renseigner sur quoique ce soit pour le raycasting ou la programmation en général (pour les mathématiques, pas de commentaire.)... d'ailleurs, c'est pour ça que j'ai presque gardé le même niveau de programmation gml depuis ces 2 dernières année...
[/JERAKONTMAVAYLA]

bref, bonne chance à tous les participants.

Je vais essayer de faire quelque chose.
Mais avant, il faudra que je me documente beaucoup (parce que la je suis pas prêt d'arriver au même rendu qu' Onilink)

j'ai pas dit qu'on abandonner hein %)

juste que l'on à presque aucune chance, vu que dans le même genre, sekigo à mieux que nous XD

et puis, surtout, comme d'hab, je me retrouve seul car FJMC à une flemme infernal, et donc moi, avec mes petit doigt et mon niveau d'étude de seconde, bah, me débrouiller avec son truc, ou je comprend à peine quelque truc, et que si il 'explique, il y à 85% de chance que je comprennent plus rien ...

je vais essayer, mais moi, je m'occupe de la partie programmation du jeu avec le moteur, pas du moteur, comme d'hab quoi ... (c'est rare que je fasse le moteur, l'un des seuls que j'ai fait étant Puppet Magic ...)

Pour les maths tout ce que tu as a savoir :

-Second degrés
résoudre ax² + bx + c = 0
tu pose D = b² - 4ac
et avec sa deux solutions si D>0 , une si D=0 et aucune(réelle) si D<0
s1 = (-b-sqrt(D))/2/a
s2 = (-b+sqrt(D))/2/a

-Produit scalaire (un truc qu'on apprend très tôt)
u et v des vecteurs : u(a,b) , v(c,d)
u scalaire v : u.v = a*c + b*d

Donc c'est pas très hard :/
Mon raytracer ce résume presque qu'a sa xD ( a part le système d'illumination avec des formules de Lambert)
Rien qu'avec le second degrés tu peut détecter les sphères, ce seras pas super joli mais ce seras la base. Ensuite t'applique les formules de Lambert et hop t'as des spheres toutes jolies. Reste a faire les ombres et reflets mais c'est pas la mort non plus.

ouai, mais notre truc est plus proche de ce qu'a fait sekigo, mais, avec la seul différence que nous, on peut même pas afficher les poly correctement, et que ça devient des dpnc des rectangle X(

en plus on a une 3D déformé d'après FJMC ...

mais bon, là, ce que j'ai à faire, c'est un script de labyrinthe pour tableau à 2 dimension, et la notion der point, j'ai réussi le niveau, je l'ai gagné, ensuite, on s'arrache les cheveux sur comment corriger le problème des polys XD

Le truc dont je me suis inspiré pour démarrer

Alors, évidemment, faut voir que ce n'est pas exactement pareil en GM, il faut adapter le truc, et surtout, c'est juste une base. Parce que le système sur la page n'est pas super modulable, avec tout écrit en dur dans le code, et ça, c'est sale.

MAIS c'est un bon début pour plonger dans le RayCasting. Les liens qu'à filer TDT sont plus intéressant, et plus complet, mais ils sont un peu plus "coriace" pour comprendre le principe si on est à sec en programmation. Là, c'est du code simple, et en suivant "l'histoire" du programme, on comprend mieux comment afficher de la simili 3D en RayCasting. Et en quatre script, on a un mini-moteur.

Et aussi, n'hésitez pas à aller voir dans les codes sources des différents projets open-source utilisant le RayCasting. Ils sont là pour ça.

Ça fait certes un peu "pillage", mais il ne faut pas rêver, inventer un algo de A à Z, surtout pour de la "3D", ce n'est pas à la portée de bcps de monde ici. Et de toute manière, la prog GM à ses spécificités qui font que l'on est obligé de "broder" un nouveau truc.

Je sais que mes calculs sont faux, que mon moteur est buggé, mais je m'en fiche je comprends rien aux sources et ça donne pas mal déjà.
►Ancien lien
↑↓→← pour se déplacer (si vous vous éloignez trop ça bugge), molette pour faire tourner la vue. (+ et - pour montrer les limites de mon système obsolète. )

Donc si j'ai bien compris ce que j'ai fait c'est du raycasting non pas avec des lignes verticales mais horizontales, et au lieu de pouvoir se rapprocher des murs mais de ne pas sauter je peux sauter mais pas me rapprocher de mes objets. Dans le tas il doit y avoir des trucs pas nets.
Je crois que je vais laisser tomber le moteur inachevé là, et commencer à travailler le jeu. :nezrouge:


Edit : Merci des encouragements Gabin. :nezrouge:
Optimisé (30 fps avec des murs en 4 tiles) ! moteur de niveau entamé (editeur en tableau de chiffres) ! volonté d'avancer entamée ! moteur de collision basique fonctionnel (saut, déplacement, collisions par tableau 3D) ! par contre le moteur est toujours aussi merdique.

Image du projet:

tu sais c'est un bon debut ! juste a l'ameliorer un peut pour la rapidité et autre et c'est bon

Oui, ne vous inquiétez pas, vous avez largement le temps de faire un truc bien !

Et même regarder un code source déjà fait, ça peut toujours être utile (puisque c'est pas le même langage, on apprends quand même)

Puis ton jeu sera fort agréable à jouer, j'en suis sur !

moi je cherche à faire mon propre moteur 3D en utilisant pythagore.
j'ai passé l'après midi à trouver les formules, maintenant me reste plus qu'à prier pour que ca marche \o/.

C'est normal que les ds_grid soient aussi lente à initialiser ?

Code:

for (i=0;i<string_length(level_string);i+=1)
    {
    ds_grid_set(level, i mod level_sqrt, i div level_sqrt, real(string_char_at(level_string, i+1)));
    }

Ce petit bout de code me prend bien ~15 secondes à remplir. Pour info, la chaine de caractère fait 100 de coté.
Il me semblait que les grids étaient pourtant optimisées pour la vitesse. Je vais essayer avec des tableaux normaux.

Ça me fait mal de voir que c'est même plus lent que calculer des cos et des sins par centaines par step.

Edit => Non, même avec des tableaux, ça me fait le même truc.

première tentative, échec:

Zebdal, ce n'est pas du codeBarring que l'on fait, hein...

Bon courage en tout cas.

Edit => Bon, pour le truc précédent. Ce n'est pas le fait de remplir ds_grid qui est lent.... C'est de convertir un caractère en réel ( real(chr) ). Ça va être super pour optimiser.

Edit2 => Oulà, juste en virant le real(), je passe de 15 secondes de chargement à moins d'une seconde ( presque instantanée en fait). Bon, après, faut que je change le moteur pour réaliser des tests en string au lieu d'en réel.

Sekigo Le Magnifique a écrit:

Zebdal, ce n'est pas du codeBarring que l'on fait, hein...

Bon courage en tout cas.

lol

seconde tentative, bon ca ressemble déja plus à quelque chose, même si c'est n'imp:

zebdal a écrit:

Sekigo Le Magnifique a écrit:

Zebdal, ce n'est pas du codeBarring que l'on fait, hein...

Bon courage en tout cas.

lol

seconde tentative, bon ca ressemble déja plus à quelque chose, même si c'est n'imp:

j'ai aussi pensé à faire un truc de ce genre en voyant le sujet.
Mais après, je me suis renseigné sur le raycasting et je me suis dit que ça devait pas être ça.

Et aussi jerry de onilink qui fait des rendus de 32s
comment tu vas implémenter un gameplay?

on aura 32 secondes pour TROUVER LA BOULE ROUGE ET CLIQUER DESSUS

XD j'adore...

Ceci dit, oui, un jeu en Raytracing, ça va pas être de la tarte ...

En plus il a dit que ça fonctionnerai en lite, le grand fou. :gniah:
Sekigo : juste par curiosité, tes tableaux font quelle taille ? En 3D ?

image:

J'avance... J'ai commencé un système de collisions par tableau, un éditeur de niveaux paramétrable, mais le moteur visuel est vraiment horrible... Et il fait du 7 fps avec une map de 32*32 plate, je n'ose imaginer si je commence à faire des niveaux...


En tout cas, y'a beaucoup de variantes dans les rendus des 3D du topique.

j'ai enfin trouvé pourquoi game maker voulait plus se lancer ! (seven le coupait, il pensait que c'était un virus --')

je vais donc pouvoir vous montrer un peux ce que j'ai

j'ai aussi résolu un bug que l'on avait, qui faisait que l'on pouvait en bidouillant beaucoup, sortir du labyrinthe XD

les collision sont géré, ainsi que la possibilité de création de d'autres blocs, et de superposition d personnages à un autre bloc (porte par exemple)

manque juste la gestion de perspective, et c'est bon !

des screens :

Spoiler:

ça tourne à 52 fps en mode viewer 3D, 37 en viewer lettré 2D (c'est juste pour les test suis là) (sur 60)
sur 999 : view3D :|56| view2D :|39|
0.02go de mémoire vive utilisé, peu de performance de processeur utilisée aussi, avec firefox et jasc paint shop pro 7 en fond

juste comme ça, avant, on avait pu avoir des images buggué magnifiques !

un truc que je doit faire, intégrer l'horizon !

le calcul pour l'instant :

(résolution * fps) + ((8-version de GM)*100 000) - (poids en Ko de l'EXE*10)
donc
(600*600*52) + 0 - (23050)
=18 720 000 - 23 050
=18 696 950

j'ai un bon score quand même !

cadeau : Labynav.exe

Je franchis une étape symbolique. Je m'attaque aux textures actuellement.

Donc, le moteur de RayCasting "tout nu" donne ça :


Au niveau des fps, je n'en sais strictement rien. Suivant la résolution et le "niveau de détail", c'est plus ou moins rapide. Dans cette vidéo, en 640x480 avec le LOD au max, ça tourne autour de 15fps, sur un netbook et un seul coeur ( sachant qu'il en a deux ). Pour que ça soit au dessus de 30 fps, il faut avoir environ un LOD de 3 ( soit 3 pixels par bande ) sur la même réso. Maintenant, doit encore y avoir moyen d'optimiser, mais ce qui me pompe le plus, c'est le dessin proprement dit.
Bon, je ne l'ai pas fait dans cette vidéo, mais on peut changer la map en temps réel. Ce qui est sympa.
Maintenant, je me demande si les perfs ne vont pas être trop plomber par les textures.

red_error => Je n'ai pas très bien compris ta question. Si tu parles du tableau de niveau ( le plan de sol et les murs quoi ), qu'il soit de 10*10 ou de 100*100, à priori, ça ne change rien. Mais ce n'est pas de la réelle 3D comme dans ta démo. On ne peut pas tourner autour d'un élément sur tout les axes. Seulement faire varier les axes X et Y. Le Z, je l'oublie pour le moment. Mais je zieute dans les sources de Doom en ce moment, pour peut-être plus tard.
En tout cas, beau travail. J'ai réellement été impressionné.

Gosc => J'ai essayé ta démo. Comme tu l'as dis, ça manque de perspective. Mais contrairement à moi, ça sent l'algo fait maison. Et ça aussi, c'est impressionnant.

gg sekigo

Ha oui, vraiment bien cela.