26 réponses à ce sujet

[Monsieur Spi]

Bonjour tout le monde

Depuis un moment je vois passer des sujets traitant de la mort de Flash sur le forum, mais je ne vois personne qui propose d'autres sources d'amusement...

Moi j'ai envie de continuer à jouer, même tout seul... et tant pis pour Flash (que je ne dénigre pas du tout), ce qui m'intéresse c'est de faire des jeux, peux importe avec quoi... J'ai donc commencé la traduction de tous les exercices à propos des jeux vidéo en AS3 que j'ai rédigé dans le Wiki (voir ma signature), en leur version HTML5/JS.

On commence tout doucement avec Pong et du pur Javascript, puis on va avancer au cours de la petite trentaine d'exercices qui devrait suivre (en fonction de mon emploi du temps....) et qui , je l'espère, aidera ceux qui veulent s'y mettre.

Ça se passe par là : http://forums.mediab...s/exercice_pong

Welcome dans mon nouveau terrain de jeu

[dldler]

Hello Mr Spi.

Bonne initiative ! Ça m'intéresse beaucoup… sauf que je pars en vacances ce soir :-) (je ne vais pas me plaindre, j'en ai besoin). J'essayerai de penser à regarder ça en rentrant.

[Monsieur Spi]

Coucou Didier,

J'espère que tout roule pour toi
Je vais essayer d'avancer la semaine prochaine sur les prochains exercices, ça te fera de la lecture à ton retour
Bonnes vacances.

PS : n'hésitez pas si vous avez des remarques, questions, ou remontées de bugs à faire

[JRB]

Pour moi ce n'est pas Flash qui a un pied dans la tombe, c'est seulement le format SWF…

Super tuto, il ne me reste plus qu'à essayer de l'adapter en PDF-JavaScript.

[Monsieur Spi]

Coucou JRB,

Merci
Je veux bien voir ce que ça donne en PDF-Javascript, tu nous fais un mini tuto dessus si tu y arrive ?

[JRB]

Peut-être après les vacances…

[pol2095]

Bonne idée.
ça serait bien d'utiliser TypeScript pour des projets plus complexe.

[draad]

Coucou,

Moi j'aurais juste une remarque sur la structure du code,peut-etre n'en parles-tu pas pour ne pas perturber tout le monde (et du coup je vais mettre le bazar ^^), mais est-ce qu'on ne devrait pas gérer seulement l'affichage en javascript et gérer le coeur du gameplay dans un language plus protégé comme du php afin d'eviter les tricheries (mouvement de la balle, detection des collisions balle/raquette, comptage des points)

[Monsieur Spi]

Hello Draad,

Tout dépend de l'objectif de l'exercice, là c'est plus pour apprendre Javascript et voir les similitudes avec AS, j'utilise les jeux parce que c'est ludique, mais ta remarque est judicieuse.

Après pour les calculs, ce ne sont justement que des calculs, effectivement on pourrait passer cette responsabilité à PHP (ou n'importe quel autre langage serveur) mais alors JS ne servirait plus à grand chose dans le cas du Pong et on s’orienterait clairement PHP. D'autre part cela implique l'utilisation d'un environnement Apache et quid du local ?

Gardons ça pour plus tard, ou alors si tu te le sent, pourrais-tu faire un petit tuto annexe qu'on pourrait linker dans nos tutos comme une bonne pratique pour éviter la triche ? Il te suffirait de reprendre le Pong et d'en faire une version avec PHP/JS.

[Monsieur Spi]

@pol2095> Merci, d'ici quelques exercices on s'y met, je compte aussi passer par Jquery, EaselJs, NodeJs, etc... en fonction des jeux.

Si d'autres ont envie de rédiger quelques tutos, la section Javascript du Wiki ( http://forums.mediab...iaux/javascript ) manque cruellement d'infos je trouve, ne serait-ce que des trucs simples comme on avait en AS, n'hésitez pas à vous lancer.

[dldler]

Hello, me voilà de retour.

Et je commence à creuser le pong (même si le taquin m'intéresse beaucoup plus).

J'ai déjà 2 remarques et quelques questions :

- le nom des dossiers ou tu ranges tes fichiers est écrit en majuscules, mais en minuscules dans le code. Comme je suis un garçon courageux et que j'ai construit mon projet sans télécharger les sources, je suis tombé dans le panneau. Ce n'est pas trop dur de trouver quand on sait afficher les erreurs Javascript, mais sinon, j'aurais peut-être perdu du temps. A ce propos, un petit article sur le débugage serait un plus, indispensable dès qu'on veut bidouiller dans le code. Afficher la console ? Tracer un message, une variable ? Pas forcément plus…

- l'usage des variables W et H n'est pas généralisé dans les tests de dépassement et de collision. La première chose que j'ai faite étant de modifier la valeur de ces variables, je me suis retrouvé assez vite perdu… En même temps, je comprends que ça obscurcirait tout de suite la partie Math (je suis en train de tout construire à partir des dimensions des images et c'est un peu chaud pour mon niveau actuel) mais je me dis que : soit on joue le jeu et ça montre l'intérêt des variables, soit on se dit que c'est un premier exercice et on fait tout en tailles fixes ?

Sinon :
- y-a-t-il vraiment besoin de définir la taille du canvas (ça marche sans, j'ai testé) ? Quel est (ou quels sont) le(s) plus ?
- pourquoi stocker les variables x et y des objets graphiques plutôt que de les utiliser directement (optimisation d'exécution ?) ?
- y a-t-il un objet Javascript se rapprochant du Sprite pour dessiner les objets graphiques plutôt que d'utiliser des images ?
- y-a-t-il moyen de récupérer la position du pointeur sans passer par un écouteur mousemove ?
- parleras-tu bientôt des classes (au vu de mes recherches je suis un peu très effrayé par le sujet) ?

Et enfin, (oserais-je critiquer l'algo ?) la recherche de collisions à toutes les boucles me semble un mauvais choix, perso je vais faire 5 cas de positions de la balle en x ( x < 0 ; x > W ; x < p1.x ; x > p2.x ; autres cas } avec le test de collision p1 dans le 3^e cas et collision p2 dans le 4^e.

Pour l'instant, je vais essayer de me réapproprier le code.
Phase 2, j'ajoute un peu de physique sur les rebonds.

Un grand merci à toi pour le soin que tu apportes à tes tutos et au temps consacré. J'avais abandonné l'idée de recycler mes connaissances en code et je retrouve l'envie d'essayer.

[Monsieur Spi]

Coucou,

Merci beaucoup d'avoir pris le temps de parcourir et étudier la chose

Citation

le nom des dossiers ou tu ranges tes fichiers est écrit en majuscules, mais en minuscules dans le code

Exact, erreur de ma part, je vais corriger ça.

Citation

A ce propos, un petit article sur le débugage serait un plus, indispensable dès qu'on veut bidouiller dans le code.

Tout à fait d'accord, c'est aussi pour ce genre de "petites" choses que j'aimerai que d'autres écrivent quelques tutos/retours d'expérience pour qu'on puisse combler ces manques rapidement. Si je me lance là dedans je n'aurais plus le temps de faire des exercices sur les jeux malheureusement.

Citation

l'usage des variables W et H n'est pas généralisé dans les tests de dépassement et de collision

Hop là, là j'ai pas tout suivit.
Il y a deux types de collisions, une entre la balle et les raquettes, et une entre la balle et les limites de la zone de jeu.
Entre la balle et les raquettes c'est une formule de collision standard où W et H n'ont pas à intervenir.
Entre la balle et les murs j'ai mis des valeurs fixes, pour la simple raison que ça évite une opération supplémentaire.
A ce niveau effectivement on aurait pu utiliser la hauteur du terrain de jeu et y soustraire une valeur mais je ne suis pas sur que ça serait plus simple, sauf si on veut modifier la taille du jeu.

Citation

- y-a-t-il vraiment besoin de définir la taille du canvas (ça marche sans, j'ai testé) ? Quel est (ou quels sont) le(s) plus ?

Typiquement dans cet exercice ça ne sert pas à grand chose car on a la taille du terrain qui rempli toute la zone de dessin, mais dans un autre cas cela aurait été indispensable. Le plus c'est montrer qu'on peut modifier la taille de la zone de rendu, cette taille peut aussi être dynamique et s'adapter au besoin.

Citation

- pourquoi stocker les variables x et y des objets graphiques plutôt que de les utiliser directement (optimisation d'exécution ?) ?

Séparer graphismes et calculs
On fait le rendu dans la fonction render, grâce à la méthode drawImage du contexte et à l'aide des résultats des calculs.
Une fois tous les calculs faits, on prend chaque image qu'on doit afficher et on la trace au bon endroit en fonction des résultats.
Bonne pratique et évite d'avoir à interroger l'affichage pour savoir où se trouve un objet.

Citation

- y a-t-il un objet Javascript se rapprochant du Sprite pour dessiner les objets graphiques plutôt que d'utiliser des images ?

Canvas ou plus précisément son contexte.
C'est là un des points qui change pas mal de l'AS, en fait Canvas est un Sprite, voire un Shape dans lequel tu dessine.
Mais rien ne t'impose d'avoir un seul Canvas dans ta page HTML, et de les superposer si tu le souhaite.

HTML = support global (sources et structure)
Canvas = zone de dessin
CSS = habillage et positions des éléments

Tu peux faire du setPixel avec Canvas (j'en découvre tous les jours), par exemple :

function setPixel(imageData, x, y, r, g, b, a) {
                var index = (x + y * imageData.width) * 4;      // index du pixel de la surface à dessiner
                imageData.data[index+0] = r;
                imageData.data[index+1] = g;
                imageData.data[index+2] = b;
                imageData.data[index+3] = a;
        },

Dans cet exemple tu balance à la fonction un tableau de bits (BitmapData en AS) que tu récupère de où tu veux, par exemple :

var bitmapData = monCanvas.context.getImageData( 0, 0, monCanvas.canvas.width, monCanvas.canvas.height);
setPixel(bitmapData, 0,0, 250, 200, 200, 255);
 

Après tu peux utiliser des libs qui vont s'approcher du comportement de l'AS, par exemple EaselJS qui est vraiment très proche dans la construction, j'y viendrai sous peu pour un exercice justement.

Pour info tu peux aussi créer des Canvas dynamiquement dans ta page HTML, par exemple :

// a = lien vers ton image
function createTexture() {
        this.canvas = document.createElement("CANVAS");
        this.context = this.canvas.getContext("2d");
        this.context.drawImage(a, 0,0, textureWidth, textureHeight, 0, 0, this.canvas.width, this.canvas.height);
        this.img =  this.context.getImageData( 0, 0, this.canvas.width, this.canvas.height);
}

Ici je crée une nouvelle texture à laquelle je peux passer tout un tas de paramètres supplémentaires, mais j'y crée surtout un Canvas, je récupére son contexte et j'y dessine l'image que je veux manipuler.

Citation

- y-a-t-il moyen de récupérer la position du pointeur sans passer par un écouteur mousemove ?

A ma connaissance (je débute aussi dans le passage de l'AS à JS), tu es obligé de déclencher un événement pour récupérer les coordonnées de la souris, puis :

function positionSouris(event) {
   var posX = event.clientX;
   var posY = event.clientY;  
}

- parleras-tu bientôt des classes (au vu de mes recherches je suis [s]un peu[/s] très effrayé par le sujet) ?

Oui c'est prévu
Tu peux lire ça en attendant : https://developer.mo...en_d%C3%A9tails

Etonnament, créer une classe ou un objet en javascript est assez simple.

Citation

Et enfin, (oserais-je critiquer l'algo ?) la recherche de collisions à toutes les boucles me semble un mauvais choix, perso je vais faire 5 cas de positions de la balle en x ( x < 0 ; x > W ; x < p1.x ; x > p2.x ; autres cas } avec le test de collision p1 dans le 3^e cas et collision p2 dans le 4^e.

Et si on admet que la balle se déplace plus vite que la largeur d'une raquette ?
Par exemple dans le cas 3 : x < p1.x
On teste si il y a collision si la position de la balle est inférieure à la position du joueur, c'est à dire lorsque la balle à dépassé la raquette (selon sa vitesse) ?
Je pense que dans l'ensemble tu as raison, on pourrait limiter le nombre de tests de collisions, ne serait-ce qu'en regardant de quel côté du terrain est balle, mais je ne suis pas sur que ça ne compliquerai pas inutilement les choses pour un tout premier exercice

Citation

Pour l'instant, je vais essayer de me réapproprier le code.
Phase 2, j'ajoute un peu de physique sur les rebonds.

Hâte de voir ça

Citation

Un grand merci à toi pour le soin que tu apportes à tes tutos et au temps consacré. J'avais abandonné l'idée de recycler mes connaissances en code et je retrouve l'envie d'essayer.

Merci surtout à toi, pour ta relecture, ton application et tes remarques.
Franchement je suis content si ça peut te permettre de passer le cap, tu verra que ce n'est pas compliqué, il faut juste apprendre à travailler avec une autre structure, mais c'est vraiment très proche. J'ai eu un peu de mal au début et là j'ai presque fini de remonter mon moteur de Raycasting et j'ai réussi à l'optimiser par rapport à ce que j'avais fait en AS.
Bon courage, tiens nous au courant et n'hésites pas à partager ou poser des questions, qui nous ferons tous réfléchir
Moi de mon côté j'ai un objectif, traduire les 30 tutos de l'AS en JS, go !

[JRB]

Moi je suis stupéfait d'apprendre qu'on peut tricher à Pong…

[dldler]

Merci pour les réponses Mr Spi.

2 autres remarques :
- je suis passé en mode strict, ça me semble un indispensable pour la sécurité. As-tu un autre avis ?
- pour l'usage de variables de calcul ≠ variables graphiques, j'ai compris. Mais du coup, je dirais que tu peux en profiter mieux que ça. En effet, tu utilises des variables de calcul totalement calées sur la vue graphique (marges, largeur et hauteur des éléments) et je suis presque sûr que ça te complique les Maths. Perso, je profiterais de cette distinction pour gérer une zone de jeux beaucoup plus virtuelle. Par exemple tu pourrais avoir un W = fond.width - marge - marge; et un H = fond.height - marge - marge; les coordonnées des raquettes seraient leur centre, idem pour la balle. Tout tes calculs seraient ensuite fait par rapport à un coin supérieur gauche à (0,0)… (Perso, je vais même tenter de positionner le (0,0) au centre de la zone de calcul du jeu). Ensuite, c'est la fonction de rendu graphique qui corrige le décalage entre la zone de calcul et la zone graphique… Vois-tu ce que je veux dire ?

[Monsieur Spi]

Coucou,

Citation

- je suis passé en mode strict, ça me semble un indispensable pour la sécurité. As-tu un autre avis ?

A lire à ce sujet : https://developer.mo...nce/Strict_mode

C'est mieux oui, mais attention les deux modes ne sont pas forcément compatibles entre eux.
Je pense que ça devrait faire partie d'un tuto plus généraliste, cela s'inscrirait par exemple tout à fait dans le tuto sur le déboggage.
Pour le Pong cela ne sert pas à grand chose et complique la prise en main de ce tout premier code.
Par la suite j'essaierai de rester en mode strict, mais j'ai peur que ça fasse beaucoup d'infos pour un premier exercice.

Citation

- pour l'usage de variables de calcul ≠ variables graphiques, j'ai compris. Mais du coup, je dirais que tu peux en profiter mieux que ça.

Tu as raison
Mais encore une fois c'est lié au fait que ce tuto est un tout premier pas, un "Hello World" du jeu vidéo en somme
On va avoir 30 tutos pour faire progresser les algos et optimiser le code (attend qu'on arrive au Rogue Like avec la génération de labyrinthes... si tu t'en souviens on avait bien joué là dessus ). Mon objectif ici est double, par un exercice tout simple donner envie à ceux qui viennent de l'AS de passer à JS en douceur, donner envie à ceux qui veulent apprendre quelques bases du jeu vidéo de s'y mettre.
Comme je le disais dans la version AS (que je n'ai pas repris dans la version JS), le code est très court et je pense qu'on peut encore largement optimiser et réduire, que ce soit en opti ou en écriture de code, mais laissons cela pour la suite, et profitons de cet "amuse gueule" pour prendre en main la base, puis viendrons les optimisations par la suite.
Par contre ça empêche pas de proposer des version différentes, plus optimisées, mieux écrites, plus stables et sécurisées, bien sûr, au contraire même je dirais que je les attends (ces versions) avec impatience
J'ai posé la base, appropriez-vous le tout et jouez avec, je veux bien voir le résultat de vos propres recherches et tests car ce serait super intéressant de voir comment vous vous y prendriez.

Mais revenons à ta dernière remarque :

Citation

Par exemple tu pourrais avoir un W = fond.width - marge - marge; et un H = fond.height - marge - marge;

Pas tout à fait d'accord, en faisant ça tu te fixe sur un élément graphique, ton jeu dépend donc de cet élément pour ses calculs, mais si je veux faire une zone de tracé plus grande pour ajouter un HUD par exemple pour compter les points en dehors du terrain, je ne peux pas avec ta version, en ce sens je la trouve plus restrictive.

Citation

Ensuite, c'est la fonction de rendu graphique qui corrige le décalage entre la zone de calcul et la zone graphique

Là aussi pas tout à fait d'accord, on impose à la fonction de rendu d'effectuer des corrections, donc des calculs, pour moi la fonction de rendu ne fais qu'une chose, tracer en fonction des calculs déjà effectués. Ainsi cette fonction peut devenir une méthode d'une classe plus générique réutilisable dans d'autres jeux. Avec ta solution on devrait réécrire ou adapter cette fonction selon les paramètres du jeu, là aussi je trouve ça plus restrictif, mais j'ai peut être mal compris ce que tu voulais faire ceci dit.

[Monsieur Spi]

@JRB >

Citation

Moi je suis stupéfait d'apprendre qu'on peut tricher à Pong…

Bah comme à tous les jeux en fait, la base de la triche sur Pong c'est de jouer sur l'IA de l'ordi, très simple, il suffit de modifier sa vitesse de réaction et on gagne à tous les coups, mais il existe d'autres méthodes, comme par exemple faire ralentir le jeu, bref il y a toujours moyen de tricher

[dldler]

Et hop !
 pong.zip   12.92 Ko   4 téléchargement(s)

Première version, pas top du tout mais j'ai restructuré le code à ma façon (je ne dis pas que c'est mieux, c'est bancal entre nos deux façons de voir je pense). Tout est relatif, on peut donc changer le format du jeu juste en changeant les images… ou presque (les calages verticaux des raquettes sont à l'arrache mais je sais pourquoi, donc pour moi ce n'est pas grave).

- juste une petite remarque : tu crées deux "instances" de l'image de la raquette, une pour chacun des joueurs. Mais j'ai l'impression que ce n'est pas comme en action script. Les images sont ensuite dessinées (draw) sur le contexte. D'où une seule raquette semble suffire, avec par contre 1 localisation par joueur. Un comportement plus proche du bitmapdata que du bitmap AS3.

Pour la zone de jeux centrée (ou pas) : c'est vraiment mon truc à moi, ça, pour faire de la géométrie sans les Maths et c'est pour ça que j'ai besoin de conteneurs. Pour l'instant, j'ai délégué l'affichage des éléments de la zone de jeu à une fonction offset_render(); ça ne me semble pas absurde (c'est surtout que je cherche à reproduire une logique AS3 qui me convient, à tort ou à raison) et ça n'empêche pas de gérer d'autres éléments sans offset (je pourrais passer un offset null au pire) ou d'autres offset…

Cette idée ne sera sans doute pas claire avant que j'ai un peu d'expérience et fait quelques tests.
Mais avant, je passe à l'étape 2 et je repars d'un code complètement vierge pour voir si je tiens le choc pour la physique un peu plus poussée.

[Monsieur Spi]

Coucou,

Passage rapide pour dire que je ne pourrais m'y pencher avant lundi prochain, je pars en balade pendant quelques jours
Mais dès mon retour je regarde ta source et te fais des retours

[dldler]

Dans, ce cas, je pense qu'il y aura une nouvelle version plus intéressante à ton retour.
Elle est déjà bien avancé : pong phase 2.
Au menu :
- dessin de l'interface au lieu d'import d'images // fait
- zone mathématique pour le jeu centrée et optimisée // fait
- raquettes pseudo concaves // fait
- accélération progressive de la balle // fait
- transfert de la vitesse de la raquette vers la vitesse de la balle // à faire
- délai entre la perte de la balle et le départ d'une nouvelle // à faire

Je tenterais bien aussi un effet de traînée derrière la balle mais je vais peut être le garder pour une troisième version finalement. Ça se passe assez bien côté code. Je suis très lent, mais je me sens moins perdu que ce que je pensais.

D'ici là, bonne ballade.

[dldler]

La voilà…
Version 2 finale
- dessin de l'interface au lieu d'import d'images
- zone mathématique pour le jeu centrée et optimisée
- raquettes pseudo concaves
- accélération progressive de la balle
- transfert de la vitesse de la raquette vers la vitesse de la balle
- délai entre la perte de la balle et le départ d'une nouvelle
- léger repère pour la position du pointeur (ça évite de sortir du cadre au mauvais moment)
- décalage de la position de départ de la balle pour mieux la voir venir
- modification des dimensions des raquettes en fonction de l'écart du score

Je n'ai pas mis de gestion d'angle (juste une gestion basique x/y) pour la physique, mais je vais bien devoir le faire si je me lance dans une version 3.
J'ai déjà imaginé l'aspect : l'idée, c'est d'avoir un terrain en bosse, donc une balle qui va ralentir en montant vers le milieu puis accélérer en redescendant.

Je devrais pouvoir ajouter :
- début de partie
- fin de partie
- rejouer…
et on verra ce qui me viendra pendant la réalisation.

En tous cas, c'est un très bon tuto qui pose bien les bases, juste assez complexe et très ouvert aux modifications/évolutions.

[Monsieur Spi]

Coucou,

J'ai un problème avec ta version 2 finale, chez moi elle ne marche pas, ma raquette part vers le haut de la zone de jeu puis disparait totalement.
En tout cas le rendu que tu as posté semble superbe
Du coup je suis curieux de voir le résultat

Sinon, j'ai récupéré ton archive précédente.
Pour les collisions, je ne suis pas d'accord avec toi, pour moi cette méthode doit rester telle qu'elle est, simple histoire de réutilisation du code, pour moi cette méthode ne sert qu'à vérifier la collision (valable pour tous les jeux) et en fonction de son résultat on effectue les calculs utiles. Là tu as mélangé les deux et pour moi ça me semble contraignant.

Ok pour l'offset, ça me semble aussi tout à fait logique si tu veux pouvoir placer ta zone de jeu, bonne info merci

Pour le reste, par goût personnel j'essaye d'éviter de mettre des valeurs numérique dans mes calculs, j’entends par là que je préfère utiliser des variables que je réutilise dans les calculs, ceci pour deux raisons, premièrement pouvoir faire des modifs sans avoir à chercher dans les calculs, la seconde pour la ré-utilisabilité selon la formule utilisée.

Niveau optimisation, d'accord avec toi pour limiter les tests à la demi zone de l'écran où la balle se trouve et sur la raquette du joueur concerné, ça me semble mieux, pas très utile pour le tuto (l'opti n'est pas importante pour un pong simple), mais très utile pour comprendre comment limiter les tests et optimiser le programme, merci

[dldler]

Hello.

Pour le code, la première version n'était pas top top.

Voilà l'archive de la version 2.
 pong_3.zip   7.27 Ko   7 téléchargement(s)
Dommage si elle ne marche pas chez toi. peut-être que c'est dû aux coordonnées de la souris dans certains navigateurs et en fonction de l'offset de la page (de mémoire j'ai supprimé le cas particulier de Firefox, d'ailleurs, ça peut expliquer). J'ai vu passer une formule à ce sujet assez complète à ce sujet, je vais tenter de l'utiliser mais si je n'arrive pas à reproduire le problème, je ne saurai pas si j'ai résolu le truc…

Pour la collision : effectivement, si on a un besoin fréquent de collisions, autant en faire une et s'en servir.
Pour le pong, ça m'intéressait de tout réecrire et, en plus, pour moi il n'y a pas collision si on considère uniquement la surface de la raquette et pas son épaisseur.

[Monsieur Spi]

Re,

Je confirme, la dernière version ne marche pas sur FF, la raquette se barre en haut de l'écran et disparaît.

Ok pour le mode Strict, mieux mais attention à ne pas mélanger (comme avec AS3 en fait).
Bien le compteur d'attente, je n'y avait pas pensé
Pas idiot non plus de se servir d'objets pour regrouper les variables.
A quoi te sert l'offset au final ?
Pour moi c'était pour placer le Canvas ( ce qui peut être fait en CSS), mais en fait non.

Citation

Pour le pong, ça m'intéressait de tout réecrire et, en plus, pour moi il n'y a pas collision si on considère uniquement la surface de la raquette et pas son épaisseur.

A mon avis il faut que tu te l'approprie à ta sauce complétement oui, si tu as chopé les mécanismes de base ça ne devrait pas te poser de problème, et je suis curieux de voir comment tu visualise la chose, c'est déjà pas mal modifié depuis la base de l'exercice

[dldler]

Voilà la version 2 patchée pour FireFox.

Fichier(s) joint(s)

•  pong_3_2.zip   7.35 Ko   4 téléchargement(s)

[Monsieur Spi]

Re,

Oki mieux
Là ça marche, ce qui me permet de voir le résultat.
J'aime assez le fait d'avoir une inertie sur la raquette.
Par contre j'ai des bugs.

La balle ne semble pas rebondir sur la raquette, mais la traverser, toucher le mur du fond et si a ce moment elle touche aussi la raquette alors la balle rebondis. Ça te prive de certaines évolutions comme bonus/malus (options de jeux genre ériger un mur cassable derrière le joueur comme bonus de protection) ou avancée de la raquette, ou même jeu en double avec deux raquettes de chaque côté dont une est plus proche du centre de la zone de jeu, etc...

Autre bug, la taille de la raquette du joueur est fluctuante (voir capture), a chaque fois que la balle sort la raquette grandit et fini par dépasser de la zone de jeu puis se bloque.


Pour les rebonds sur les raquettes, on (je dis on car j'ai le même problème) a des cas particuliers selon l'incidence et l'effet avec laquelle la balle frappe et repart, parfois la balle arrive avec un angle de mettons 35 degrés, et repart exactement suivant le même angle (au lieu de partir vers l'angle opposé).

C'est tout ce que j'ai noté pour le moment, mais un truc viens de se casser dans mon appart et je file voir ce que c'est (un pot de fleur je pense)...

[Monsieur Spi]

Re,

Suite de mon message précédent....

Bon j'ai compris en lisant le code que c'est volontaire d'agrandir la taille de la raquette lorsqu'on perds un point :

j1.ra = u * (10 + ecart);// Taille de la raquette joueur 1
j2.ra = u * (10 - ecart);// - - - - - - - - - - - joueur 2
 

Par contre des fois elle reste bloquée dans le décor, lorsqu'elle dépasse de la zone de jeu.

[dldler]

C'est vraiment le bazard JS.

Fanchement, être obligé de développer une version par navigateur ça va vite me fatiguer.
Tes soucis viennent de la formule spéciale Firefox qui renvoie des valeurs même quand le pointeur est en dehors du canvas, alors que l'autre formule ne le ait pas. Donc, je devrai ajouter un bornage en plus dans la formule dédiée… :-(

Pour la position de la balle, ça m'étonne davantage, par principe ça me semble impossible.

Pour les rebonds qui t'étonnent, c'est voulu
En fait la vitesse verticale de la raquette est en partie transmise à la balle. Ça permet de chercher à faire des zigzags, des tirs dans les coins, comme un coup lifté au ping-pong).

En tout les cas je note toutes tes remarques et j'essaye d'en tenir compte dans la prochaine version.