devnewton 🍺 a écrit 8785 commentaires

Les façons de sortir dart et asm.js apparaissent effectivement comme des tentatives de domination. L'une est propre, l'autre est une bidouille et malheureusement c'est cette dernière qui va probablement gagner.

Je pense aussi à une chose: maintenant que la boite de pandore est ouverte et si d'autres bytecodes javascript faisaient leur apparition? Certains mieux pris en charge par webkit, d'autres par Trident, etc…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Souvent, mais pas toujours.

Heureusement il est encore possible d'acheter des jeux jouables offline.

Ce que je crains avec html5, c'est que les développeurs rendent la connexion obligatoire sans faire exprès ou par paresse.

Rendre un jeu html5 jouable hors ligne, ça demande un développement bien particulier: http://smus.com/game-asset-loader/

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Je n'ai compris cette référence, c'est certainement un message codé pour Eux.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Oui et j'ai du mal à voir autre chose qu'un mauvais bytecode.

La compatibilité avec l'existant est juste une tactique géniale pour forcer les autres à l'implémenter puisque du point de vu de l'utilisateur, le ressenti ne sera pas ce site est nul, le jeu ne se lance pas, mais mon navigateur est nul, le jeu est lent avec.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Du coup, ils font un coup de force en imposant un bytecode pour lequel il va falloir écrire un VM spécifique.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

asm.js tourne déjà aujourd'hui sur tous les navigateurs

Seulement ceux qui le prenne en charge ou alors ça doit être inutilisable.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Un peu comme ECMAScript 6, mais en changeant encore plus ?

Je préfèrerais un vrai langage, mais oui pourquoi pas :-)

L'approche de Dart était sympa, je n'ai pas compris pourquoi Mozilla a boudé.

Il y a des gens qui codent des jeux en java et il semble que ne pas avoir de mot clef delete ne les dérange pas trop.

C'est LE problème majeur quand tu fais des jeux en java : comment gérer les ressources (textures, buffers sons) et empêcher ce $!*! de ramasse miettes de se faire gros lag au beau milieu de la partie.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu es bien le dev d'un petit jeu 2D, tu va pas me faire croire que 3 sprites qui se batte duel ont besoin de 10 giga opération par seconde pour être fluide. Surtout que la partie graphique est native !

Je cherche du monde pour m'aider à le porter sur d'autres plateformes, si tu veux essayer d'en faire une version html5, je fournirais toute l'assistance nécessaire!

On parle tout de même d'unreal engine 4 (c++) qui tourne à 50 fps !

Sur quelle machine?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

mais comment est-ce que ça va se faire

Il y a deux autres voies pour avoir la portabilité du web et de meilleurs performances:

• rester sur le web et étendre javascript (ou utiliser un langage) avec des primitives faites pour les jeux (RAII, opérations sur des vecteurs ou des matrices, définition de structures "à la C", gestion de la mémoire manuelle…).
• créer une sandbox spécialisée dans les jeux.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et en pratique, soit tu fais un dev spécifique, soit tu as un jeu si lent qu'il est inutilisable?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Quels sont les avantages pour les joueurs? Avoir une bonne excuse pour acheter un nouveau PC?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Python?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Mettre les jeux "sur le web" pose pas mal de problèmes:

• même avec les bidouilles à la asm.js, on n'atteindra jamais la vitesse du code natif.
• le navigateur bouffe une quantité non négligeable de RAM.
• ça va encore plus inciter les développeurs à rendre les jeux injouables hors ligne.
• le web, c'est aussi une excellente plateforme de tracking et de publicité.
• donner un accès direct au matériel à une page web est un trou de sécurité énorme. Rien qu'aujourd'hui j'évite les démos webgl, car elle provoque souvent des plantages et autres écrans bleus.

Alors oui, les jeux natifs peuvent aussi être lents, buggés, bourrés de pubs ingame et demander une connexion permanente.

Mais j'ai l'intuition que le web va augmenter fortement la tentation des studios à suivre Voie Du Mal.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu devrais au moins libérer le code et un niveau pour permettre aux gens d'installer ton jeu ou recevoir de l'aide des empaqueteurs.

Parce que fournir des binaires pour toutes les combos OS/CPU, c'est juste impossible aujourd'hui.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

j'aime la couleur quand je fais un diff

fossil settings diff-command colordiff

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

A part pour faire vraiment retro, rappelons que le standard de l'animation sur le web, c'est nanim apng mng webm!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tes remarques sont tout à fait valables pour des projets en entreprise où la stabilité est un critère et dont les résultats sont mesurables objectivement.

Maintenant pour un jeu…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

C'est ce que je m'étais dit en commençant Newton Adventure: autant prendre git, c'est la référence et si mon projet grossit, je serais prêt.

Et puis j'en ai eu marre de passer plus de temps sur la gestion de version et la maintenance du site que sur le code tout en ayant un historique dégueu, car ça se terminait souvent en rage commit.

git est très bien, mais il y a des projets auxquels je ne remonte pas mes corrections juste parce que ça me gonfle de passer une soirée à me battre avec pour faire un commit propre.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Si le projet est chargé, tu sors du cadre d'utilisation de fossil (petit à moyen projet, petite team qui se connait bien, quelques contributeurs occasionnels).

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Évidemment, quand on est un minimum soigneux on est forcément un obsédé de la pureté.

On peut être soigneux tout en conservant les erreurs dans l'historique. Tout dépends de comment tu conçois ce dernier: est-ce un roman ou une chronique?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Faire des historiques propres c'est avoir compris

Je suis complètement d'accord, mais ça ne vaut que le projet où une grosse gestion de version fait gagner du temps.

Sur un projet de taille moyenne avec quelques codeurs principaux et des contributeurs occasionnels, le jeu n'en vaut pas la chandelle.

A ton avis pourquoi la plupart des projets libres fonctionnement par patch atomiques dont tu publies les révisions successives jusqu'a ce que ca soit mergé à un moment ?

Le créateur de fossil et sqlite explique dans le lien que j'ai donné plus haut comment travailler comme ça avec fossil.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pour les obsédés de la pureté de l'historique et autres révisionnistes, fossil n'est pas adapté.

Il y a deux besoins:

• une gestion de version simple: archiver, partager, revenir en arrière en cas de bêtise, faire quelques branches pour la maintenance ou les évolutions.
• une gestion de version au cœur du développement: pouvoir gérer des milliers de contribution, avoir un historique/documentation, gérer 42 variantes.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

La philosophie de fossil pour ce genre de cas est de créer une branche: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02143.html

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Installer redmine et git, je ne vois pas en quoi c'est "beaucoup plus complexe".

Pour l'installation, fossil c'est juste UN exécutable.

A l'utilisation Git est beaucoup plus compliqué à utiliser.

Ensuite si je veux maintenir plusieurs sites et les synchroniser, ça va marcher pour git mais pour redmine?

Enfin, une fonctionnalité que j'apprécie beaucoup avec fossil: j'ai accès à tout même sans connexion internet, donc je peux écrire de la doc ou des rapports de bug même si je suis dans le train.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

On compare souvent fossil à git ou mercurial.

Certes, on peut faire la même chose (DVCS+wiki+bugtracker) en combinant d'autres outils, mais c'est toujours beaucoup plus complexe et plus difficile à maintenir.

Pour l'autohébergement de petits projets, fossil n'a pas de concurrent.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.