Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 1 sur 4 1234 DernièreDernière
Affichage des résultats 1 à 30 sur 110
  1. #1
    Vous l'avez lu dans le Canard PC 282, cette année nous allons développer un jeu en HTML5/JavaScript.

    Ce post sera étoffé sous peu. En attendant vous pouvez télécharger le "squelette" du code source ici : http://cpc.cx/808

    Contenu nécessaire aux leçons :
    Introduction (CPC 282) : "Squelette" du code source
    Leçon 1 (CPC 283) : joueur.png (à mettre dans le sous-répertoire "media")
    Leçon 3 (CPC 285) : ciel0.png, ciel1.png, ciel2.png (à mettre dans le sous-répertoire "media")
    Leçon 4 (CPC 286) : saucisse0.png, saucisse1.png (à mettre dans le sous-répertoire "media")
    Leçon 6 (CPC 288) : boing.mp3, boing.ogg, music.mp3, music.ogg, pouet.mp3, pouet.ogg (à mettre dans le sous-répertoire "media")
    Leçon 7 (CPC 289) : panpan.mp3, panpan.ogg, tir.png (à mettre dans le sous-répertoire "media")
    Leçon 12 (CPC 293) : joueur_hit.png (à mettre dans le sous-répertoire "media")
    Leçon 13 (CPC 295) : saucisse2.png (à mettre dans le sous-répertoire "media")
    Leçon 17 (CPC 299) : bombe.mp3, bombe.ogg, levelup.mp3, levelup.ogg (à mettre dans le sous-répertoire "media")

    Code source des leçons 1 à 6 :
    Pour les retardataires et ceux qui auraient raté un épisode, voici le fichier script.js tel qu'il était au terme de la leçon 6 (CPC n°288) : script.js

    Liens :
    Les bases du JavaScript : http://www.w3schools.com/js/ (et en français : http://javascript.developpez.com/cours/)
    Le site de CreateJS : http://www.createjs.com/#!/CreateJS
    Dernière modification par L-F. Sébum ; 04/06/2014 à 22h29.

  2. #2
    Je me suis dis "tiens pourquoi ne pas essayer ce Développez Couché, saison 03, ça peut être intéressant et je mourrai moins bête" ...
    Bah c'est mal barré, les mots COIN COIN ! ne s'affichent pas sur la page index après avoir recopier bêtement (et surement très mal) le code d'échauffement dans script.js (si c'est bien là, hein?).

    J'ai du me tromper dans les espaces et retour à la ligne dans le code ...

  3. #3
    J'ai eu le même souci. En relisant le code je me suis aperçu que j'avais oublié les guillemets à

    Code:
    var text = new createjs.Text("COIN COIN!", "36px Arial", "#777777");
    Vérifie donc que ce ne soit pas ça qui bloque
    Citation Envoyé par cooperman Voir le message
    Faut etre serieux quand même !!
    Steam ID

  4. #4

  5. #5
    Un petit jeu d'arcade à la con, un peu comme le Canardage de la saison 1.

  6. #6
    Citation Envoyé par Babelfish Voir le message
    J'ai eu le même souci. En relisant le code je me suis aperçu que j'avais oublié les guillemets à

    Code:
    var text = new createjs.Text("COIN COIN!", "36px Arial", "#777777");
    Vérifie donc que ce ne soit pas ça qui bloque
    Cette partie là était bien recopier apparemment ...
    Rien à faire, ça veut pas .

  7. #7
    Citation Envoyé par n0ra Voir le message
    Cette partie là était bien recopier apparemment ...
    Rien à faire, ça veut pas .
    Essaye avec un autre navigateur au pire.

  8. #8
    Je conseil d'installer firebug (une extension pour firefox).
    Ca permet bien souvent de savoir ce qui cloche quand on fait des trucs en javascript.

    https://addons.mozilla.org/fr/firefox/addon/firebug/

  9. #9
    Sous firefox, crtl + maj + I ouvre la console qui a bien évolué. Je ne sais pas si elle est au niveau de firebug, mais elle ne doit pas en être loin. Toutes les fonctionnalités de trace d'erreurs, d'exploration de code, styles, et profilage réseaux sont là.
    Et petit plus, la console native de firefox est beaucoup plus légère et réactive que l'usine a gaz firebug
    "Dans le doute, frappe d'abord." _proverbe orque

  10. #10
    Sinon, sous chrome, c'est F12, et pas besoin d'addon. Mais c'est bien de switcher entre les deux pour comparer et vérifier que ce qui marche sur l'un marche aussi sur l'autre.

  11. #11
    Excellente idée ce développez couché version web.
    Juste une petite remarque, bien que n'ayant pas vraiment d'ide clef en main, un netbeans ou éclipse offre un certain confort qu'on a pas avec notepad++
    Je découvre create.js ça a l'air surpuissant, je me suis amusé a faire défiler le coin coin façon intro de star wars (la perspective applatie en moins) en quelques lignes, c'est assez jouissif.

  12. #12
    Bonjour.
    Citation Envoyé par Karedas Voir le message
    Je me suis amusé a faire défiler le coin coin façon intro de Star Wars...
    Le code, svp !
    Citation Envoyé par Karedas Voir le message
    La perspective applatie en moins.
    Ce canard est un scandale !

  13. #13
    Bonjour LFS

    j'ai décidé de suivre sérieusement la saison 3, l'HTML5 m'intéresse. Aurais-tu des conseils de lectures ou de sites pour s'initier en parallèle ? L'offre ne manque pas en librairies, c'est un peu difficile de s'y retrouver quand on n'y connaît rien... Voilà, si tu as des conseils... Merci

  14. #14
    J'ai rajouté quelques liens dans le premier post.

  15. #15
    Merci bien, je n'ai plus qu'à m'y mettre

  16. #16
    Citation Envoyé par RedGuff Voir le message
    Bonjour.
    Le code, svp !

    Voilà, c'est loin d'être parfait, et ça saccade, mais ça m'a amusé 10 minutes
    Code:
    function startGame()
    {
    
    	var stage = new createjs.Stage(document.getElementById("gameCanvas"));
    	var text = new createjs.Text("COIN COIN !", "40px Arial", "#777777");
    	stage.addChild(text);
    	//on place le texte au milieu et en bas
    	text.x = 360;
    	text.y = 400;
    
    	//on crée un tick (et tack ranger du risque) qui appelle la fonction tick() 
    	// à une fréquence de 40 fps
    	createjs.Ticker.addEventListener("tick", tick);
    	createjs.Ticker.setFPS(40);
    	
    	//variable pour logger la taille de la police histoire de pas la changer pour rien
    	sizeLog = 40;
    	
    	function tick(event) { 
    		//on fait legèrement remonter le texte
    		text.y -= event.delta/1000*100;	
    		//s'il est trop remonté, on le calme, euh non, on le replace en bas
    		if (text.y < 0) 
    			{ text.y = 400; }
    		
    		//on calcule la taille de la police en fonction de la hauteur dans le canvas
    		//(40px en bas, 1px en haut)
    		var size = (Math.ceil(text.y / 10));
    		if (size < 1)
    			{ size = 1;}
    			
    		//on ajuste la police si besoin
    		if (sizeLog != size)
    			{
    			sizeLog = size;
    			text.font = size+"px Arial";
    			}
    	
    		//on update le rendu du canva
    		stage.update();
    	}
    }

  17. #17
    Comme, je vis dans les bois, je viens seulement de lire le premier article de cette saison...
    A propos de XNA, ce n'est pas plutôt positif si MS a abandonné XNA au profit d'une version OpenSource ( MonoGame ) ?

  18. #18
    Citation Envoyé par SeanRon Voir le message
    Comme, je vis dans les bois, je viens seulement de lire le premier article de cette saison...
    A propos de XNA, ce n'est pas plutôt positif si MS a abandonné XNA au profit d'une version OpenSource ( MonoGame ) ?
    Il faut voir si l'équipe derrière monogame a les épaules pour tenir face aux autres solutions libres (java et libgdx, C++ et SDL2...).

  19. #19
    je suis allé faire un tour sur les demos de createJS.

    Ancien flasheur, et même si je comprend les nouveaux avantages du html5 par rapport à flash, je m'interroge sur l’intérêt de passer au html5 pour faire des jeux du point de vue performances.

    Parce que, à l'heure actuelle, j'ai l'impression, à la vue des demos techniques, qu'il semble impossible de pouvoir réaliser un jeu utilisant un nombre important de sprites en mouvements sans mettre à genou l'ordinateur générant le script, et provoquer des saccades ou une chute de fps et c'est doit vite être limitant:
    Par exemple, pour un shooter avec scrolling + parallax + plein de bullets dans tous les sens.

    Bon par contre pour des petits jeux simples et des applications interactives, ça a un potentiel énorme.


  20. #20
    Parce que, à l'heure actuelle, j'ai l'impression, à la vue des demos techniques, qu'il semble impossible de pouvoir réaliser un jeu utilisant un nombre important de sprites en mouvements sans mettre à genou l'ordinateur générant le script, et provoquer des saccades ou une chute de fps et c'est doit vite être limitant.
    Comme le dira ton comic:
    Don't brag, it's only a matter of time.
    Les premiers moteurs de jeux qui utilisent HTML5 ne semblent pas exploiter cette techno à 100%.

  21. #21
    Citation Envoyé par SeanRon Voir le message
    Parce que, à l'heure actuelle, j'ai l'impression, à la vue des demos techniques, qu'il semble impossible de pouvoir réaliser un jeu utilisant un nombre important de sprites en mouvements sans mettre à genou l'ordinateur générant le script, et provoquer des saccades ou une chute de fps et c'est doit vite être limitant:
    Par exemple, pour un shooter avec scrolling + parallax + plein de bullets dans tous les sens.
    Je ne sais pas quelles sont les perfs des canvas, mais dans la mesure où tu as accès au WebGL en HTML5 tu es virtuellement sur un pied d'égalité avec les jeux vidéos triple A au niveau du rendu graphique.
    Rust fanboy

  22. #22
    Je ne connaissait pas webGL.
    ya des trucs deja sympa en webGL

    http://hexgl.bkcore.com/

    http://skycraft.io/

  23. #23
    Citation Envoyé par SeanRon Voir le message
    Parce que, à l'heure actuelle, j'ai l'impression, à la vue des demos techniques, qu'il semble impossible de pouvoir réaliser un jeu utilisant un nombre important de sprites en mouvements sans mettre à genou l'ordinateur générant le script, et provoquer des saccades ou une chute de fps et c'est doit vite être limitant.
    Hum hum...

    http://www.babylonjs.com/

    Citation Envoyé par Tomaka17 Voir le message
    Je ne sais pas quelles sont les perfs des canvas, mais dans la mesure où tu as accès au WebGL en HTML5 tu es virtuellement sur un pied d'égalité avec les jeux vidéos triple A au niveau du rendu graphique.
    Voilà.

  24. #24
    Citation Envoyé par SeanRon Voir le message
    Je ne connaissait pas webGL.
    ya des trucs deja sympa en webGL

    http://hexgl.bkcore.com/

    http://skycraft.io/
    Sur mon PC, avec la dernière version de firefox, skycraft prend 100 Mo et 15 % du CPU en ne faisant quasiment rien, et il y a manifestement de la fuite mémoire quelque part, parce que la RAM consommée augmente régulièrement. Pas très engageant tout ça...

    Edit: en supprimant l'onglet, la RAM revient à une valeur "normale", et n'augmente plus.

    Et pour info, Don't Starve sur Chrome (la version browser du jeu utilise WebGL) avait de gros problèmes de perfs sur des machines qui n'avaient aucun problème à le faire tourner en version native (Steam).

  25. #25
    Sur mon PC, avec la dernière version de firefox, skycraft prend 100 Mo et 15 % du CPU en ne faisant quasiment rien
    Comme n'importe quel jeu en 3D qui met à jour ses entités, ses tests de collisions, et l'affichage....
    Et encore 15% de CPU, c'est assez soft pour un jeu. Et la mémoire utilisée semble "normale" (le jeu génère le terrain au fur et à mesure).

  26. #26
    Citation Envoyé par lucskywalker Voir le message
    Comme n'importe quel jeu en 3D qui met à jour ses entités, ses tests de collisions, et l'affichage....
    Et encore 15% de CPU, c'est assez soft pour un jeu. Et la mémoire utilisée semble "normale" (le jeu génère le terrain au fur et à mesure).
    Quand je parle de "sans rien faire", je parle au lancement avec quasiment rien à afficher. Et je pense que Firefox aurait fini par crasher tout seul, si j'avais laissé tourner le jeu sans rien faire. Pour moi ce n'est pas normal. On va m'expliquer que c'est de la faute de Firefox, et pas de WebGL, mais le résultat c'est que c'est encore une technologie instable. Par ailleurs j'ai du mal à comprendre le besoin auquel elle répond, sauf permettre à des boîtes de vendre des jeux directement dans le navigateur.

    Parce qu'en l'état, que ce soit dû à WebGL, à son implémentation dans les navigateurs, ou à Javascript, c'est instable et ça consomme bien plus que les mêmes trucs en natif.

  27. #27
    Firefox est connu pour ses memory leaks.
    En faisant une petite recherche google, je suis tombé sur un site qui indique que 100 à 150 Mo de mémoire est une consommation "normale" pour ce logiciel.

    WebGL n'est pas une technologie instable. C'est juste un "pont" vers OpenGL, le truc qui existe depuis des décennies et qui fait tourner bon nombres de jeux Windows ainsi que 100 % des jeux Mac et Linux (notamment les portages de tous les jeux Blizzard et Valve).
    À chaque fois que tu utilises une fonction WebGL, elle est simplement redirigée vers ta carte graphique. Il est extrêmement peu probable y ait un memory leak ou un bug à ce niveau là puisqu'il n'y a normalement aucune surcouche.

    En revanche il est plus probable que ce soit le javascript ou la grande quantité de ressources nécessaire au jeu qui produit ce que tu décris. Mais ça on ne peut pas dire que ce soit des technologies naissantes, et on ne peut que blâmer les navigateurs si leur moteur javascript consomme la moitié de ta RAM.
    Rust fanboy

  28. #28
    Citation Envoyé par Tomaka17 Voir le message
    En revanche il est plus probable que ce soit le javascript ou la grande quantité de ressources nécessaire au jeu qui produit ce que tu décris. Mais ça on ne peut pas dire que ce soit des technologies naissantes, et on ne peut que blâmer les navigateurs si leur moteur javascript consomme la moitié de ta RAM.
    Le résultat est le même. Et on revient au problème précédent. Quel intérêt d'exécuter un jeu dans un navigateur si au final on consomme bien plus de ressources que le même jeu en natif ? Tout en ayant les mêmes problèmes potentiels de drivers.

    Et ce genre de problèmes n'est pas spécifique à firefox. Les problèmes dont je parlais concernant Don't Starve concernaient Chrome.

  29. #29
    L'intérêt c'est qu'il n'y a rien à installer et que tu gardes tes sauvegardes entre différentes machines. Imagine les jeux via navigateur type Travian, Cookie clicker, etc. mais avec de la 3D, c'est un peu ça le genre de jeu qui serait visé par HTML5.

    Effectivement les jeux triple A ne seront jamais portés sur navigateur, parce que c'est plus lent et que je me vois mal télécharger 20 Go à chaque fois que je veux jouer.
    Mais on parlait de Flash plus haut, et pour moi HTML5 est largement gagnant niveau perfs par rapport au Flash qui rame dès qu'on utilise une boucle for
    Rust fanboy

  30. #30
    Citation Envoyé par Tomaka17 Voir le message
    L'intérêt c'est qu'il n'y a rien à installer et que tu gardes tes sauvegardes entre différentes machines. Imagine les jeux via navigateur type Travian, Cookie clicker, etc. mais avec de la 3D, c'est un peu ça le genre de jeu qui serait visé par HTML5.

    Effectivement les jeux triple A ne seront jamais portés sur navigateur, parce que c'est plus lent et que je me vois mal télécharger 20 Go à chaque fois que je veux jouer.
    Mais on parlait de Flash plus haut, et pour moi HTML5 est largement gagnant niveau perfs par rapport au Flash qui rame dès qu'on utilise une boucle for
    C'est sur que par rapport à Flash, HTML5 + WebGL est une bien meilleure solution. Et pour le genre de jeux dont tu parles, je suis d'accord, c'est sans doute une bonne technologie.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •