Je n’avais pas prévu au départ d’ouvrir le site publiquement avant d’avoir un éditeur complet et stable, mais la version de développement ayant été relayé sur LearningWebGL, il en a été autrement !

Finalement, j’ai réussi rapidement à avoir quelques rendus sympathiques, mais mes connaissances restent trop limitées pour arriver à optimiser mon code pour les différentes versions de Firefox et de Chrome.
Aujourd’hui les dernières versions de ces deux navigateurs proposent WebGL activé par défaut, et sont plutôt bien introduites. De plus Three.JS proposent aussi un moteur de rendu en Canvas et en SVG, bien que les performances en sont bien moindres.

Malgré cela, je pense qu’il y a de bonnes applications pour les jeux par navigateur, et pour des applications en ligne. On peux tout à fait imaginer des plateaux de jeux en 3D, des cartes, des interfaces, des pages d’accueil…

Il me reste encore quelques ajustements à faire pour sortir l’éditeur publiquement, mais le travail est en bonne voie ! Actuellement j’ai réussi à implémenter une grande majorité des blocs du jeu, et je dois m’attaquer aux objets avec une orientation, ainsi qu’à plusieurs travaux d’optimisations, surtout sur des constructions de plus de 2000 blocs.

• Minification des fichiers JS et CSS
• Compression avec le mode deflate des fichiers JS et CSS

Faciles et rapides à mettre en place, ces solutions permettent souvent d’économiser au minimum 75% de la bande passante utilisé par le serveur en mode normal.

Voici un petit récapitulatif des solutions que nous avons mis en place et de leurs économies associées.

Pour la minification, je vous laisse voir de votre côté, personnellement, j’ai plusieurs scripts qui tournent avec YUICompressor, mais d’autres solutions sont possibles.
Par exemple: JSmin, CSSminifier, DOJO Compressor… C’est au choix, je pense qu’elles ont toutes leurs avantages et leurs inconvénients. YUICompressor est, dans mon cas utilisé en local avant upload des fichiers.

Pour le DEFLATE, un simple copier/coller suffit dans un .htaccess à la racine, ces lignes ayant déjà été donné dans mon .htaccess par défaut, cette méthode doit normalement resté active le plus souvent possible, et être activé de façon transparente. Notons que si le mod_deflate n’est pas initié par Apache, la ligne est purement et simplement ignorée.

<IfModule mod_deflate.c>
	<FilesMatch "\.(js|css)$">
		SetOutputFilter DEFLATE
	</FilesMatch>
</IfModule>

Pour montrer la bande passante économisée, je prend les logs d’accès du mois de juillet. Je vais effectuer la comparaison sur deux fichiers CSS et deux fichiers JS.
Sur Tarschool, les plus utilisés sont :

Pour le mois de Juillet, voici donc le nombre d’accès total, dans lequel nous allons séparer les fichiers effectivement transmis et ceux dont le cache a été utilisé.
En effet par défaut, on peux déjà économiser une quantité significative. Pour contrôler un peu mieux ce cache, il existe différentes solutions qui ne seront pas abordées ici.
Pour ma part je rajoute simplement un time de la dernière modification du bootstrap lors de l’appel des fichiers à mettre en cache. Je laisse le reste à Apache et pour le moment cela me convient.

En ne prenant en compte que les fichiers effectivement transmis, je peux donc calculer la bande passante utilisée avec la compression, la bande passante théorique (basée sur la taille réelle du fichier source), et les pourcentages de gains réalisés :

En conclusion, l’apport du module deflate, couplé à une minification des fichiers permet d’économiser d’énormes quantités de bandes passantes, généralement de l’ordre de 75%.

Voici quelques captures des simulations photoshop :

Essai de déformation d’un hexagone orthonormé pour la 3d Isométrique.
Afin d’obtenir une meilleure contenance de la surface, seule la texture de la tuile est convertie, et l’on depose sur cette tuile une deuxième couche en 2D classique.

Une simulation d’agencement des tuiles, pour valider mon modèle de base.
On constate que les tuiles s’imbriquent parfaitement entres elles.

Cette simulation illustre l’empilement des tuiles de fonds et des différentes tuiles de couches sur la carte

J’ai réalisé le test, en 1h30, une nuit d’insomnie, suite à une question sur JeuWeb

Le tout est visible ici : jQuery PlayCards

L’appel se fait toujours de la même manière. Une nouvelle démonstration vous permet de voir le rendu de ces deux nouvelles options.

Le temps d’animation correspond maintenant au temps total de l’animation pour parcourir la totalité de la barre de progression, ainsi l’animation garde une vitesse constante quel que soit la modification de valeur effectuée.

Il dispose de nombreuse options de personnalisations, ainsi que d’une compatibilité avec le plugin MetaData.
Il est bien sûr totalement non obstrusif et fonctionne donc sur n’importe quel configuration.

Voir la page dédiée pour plus d’informations.

J’utilise jQuery, un back-office interne pour le traitement de la base de données, et le tout se recompose aléatoirement en suivant l’ordre des produits !
3 modèles d’animations sont proposées.