Nazara Engine

Bonjour,

Présentation

Je m’appelle Jérôme et j’ai 21 ans à l’heure où j’écris ces lignes (il paraît que ça change chaque année).
Plongé dans la programmation avant même mon adolescence, elle est devenue une partie importante de ma vie et avec le temps j’ai sympathisé avec le C++, qui est devenu mon langage de prédilection dans la réalisation des jeux vidéos (une autre de mes passions).
Mais ça tout le monde s’en fout.

Je suis (J’étais?) un grand habitué de feu site du zéro (inscrit en 2005), site avec lequel j’ai commencé à perdre contact il y a deux ans pour des raisons bien connues (que je qualifierais de "grande trahison"), je visite également régulièrement developpez.com et progdupeu.pl, bien que ma participation soit moindre.

J’ai connu ce site via un ami, et je me suis dit que je pourrais y retrouver les valeurs perdues sur le site du zéro, sans oublier la communauté dont une bonne partie a migré ici.

C’est donc tout naturellement que je me suis dit que j’allais présenter mon projet sur ce site (tout en espérant apporter un plus à la communauté).

Mon projet

Il s’agit donc d’une bibliothèque écrite (et pour l’instant utilisable uniquement) en C++11, divisée en plusieurs modules servant différents usages.
Voici donc la liste des différents modules présents dans le moteur:

• Le noyau (Offrant des outils génériques pour gérer des chaînes de caractères, des fichiers, des dossiers, l’Unicode, etc…)
• Le module utilitaire (Extension du noyau ainsi que gestion du fenêtrage)
• Le module physique (Intégration d’un moteur physique)
• Le module de scripting (Intégration d’un langage de scripting, le Lua)
• Le module de rendu (Intégration d’OpenGL)
• Le module graphique (Rendu 2D/3D via plusieurs techniques comme le Deferred Shading)
• Le module audio (Intégration d’OpenAL)
• Le module de bruits mathématiques (Développé par OveRdrivR, extension de la bibliothèque mathématique du noyau pour gérer les bruits)

Bien que l’intérêt principal du moteur est de faire un jeu vidéo 3D, il est tout à fait possible de s’en servir dans d’autres domaines, par exemple le noyau peut être utilisé pour fournir des outils utiles en complémentarité avec n’importe quelle autre bibliothèque.

Le moteur (ainsi que tous les modules qui le composent) est libre et sous une licence très permissive (MIT), il est à vocation portable (le code spécifique à chaque plateforme est séparé du reste, mais seule l’implémentation Windows est complète car je n’ai pas d’expérience suffisante du monde Linux et encore moins d’OS X).
À noter aussi que le moteur étant libre et modulaires, n’importe quelle personne est susceptible de me soumettre un module à rajouter dans la branche principale (Cela a déjà été fait par plusieurs personnes).

Lien vers le GitHub du projet

Les objectifs de Nazara sont:

• De faciliter la vie des développeurs.
• D’être un moteur complet et performant.
• D’être facile à prendre en main et de ne pas être une boite noire.

Je m’explique sur ce dernier point: Beaucoup de développeurs (dont je fais partie) n’aiment pas utiliser de bibliothèque sans comprendre les mécanismes en jeu derrière, je ne parle pas ici des détails mais du fonctionnement global (Par exemple simplement savoir que le Bloom extrait les pixels les plus lumineux pour les flouter avant de les appliquer à l’image est suffisant).
Nazara a été conçu dans l’optique d’être facile à comprendre, j’espère simplement avoir atteint mon objectif.

Ironiquement, le moteur est actuellement en alpha-test et donc il n’y a pour l’instant pas de versioning, pas de garantie que l’interface ne sera pas cassée lors d’une mise à jour (même si ça devient rare) et le plus embêtant: Pas de documentation ni de tutoriel.
Tout ceci devrait changer lors du passage en beta, qui est l’un des objectifs à court-terme que j’ai actuellement.

Néanmoins, le moteur est déjà capables de gérer des techniques avancées, telles que l’éclairage dynamique, le skinning (Multi-CPU, GPU à venir), les particules (WIP), le Deferred Shading (et des effets comme le Bloom).

À terme, il est prévu qu’un SDK, un framework unifiant les modules et fournissant des logiciels pour aider à la conception d’un jeu vidéo, soit développé et sera totalement dédié à la création de jeu vidéo (Là où le moteur en lui-même fait abstraction de l’objectif).

J’ai commencé l’écriture d’un tutoriel pour utiliser le moteur sur progdupeu.pl, et j’ai dans l’idée de le rendre accessible également sur ce site pour rendre le moteur accessible à un maximum de monde

Si le projet vous intéresse, un commentaire (quel qu’il soit) sera le bienvenu.

Avant de vous laisser, voici ce qu’il est possible de faire avec le moteur (à noter que c’est par ordre chronologique): Précision supplémentaire: les modèles et textures utilisés n’ont aucun lien avec le moteur et viennent de différents coins d’Internet

Screenshots

Vidéos

Démo technique

Téléchargement

Version 0.1.0 - Précompilés Windows

Voilà, si vous avez des questions n’hésitez pas

(Quant à moi je file améliorer le rendu des particules !)

Bonne journée et merci d’avoir lu.

Ton topic était encore l'une des rares raisons pour moi d'aller sur OC, je peux maintenant me désabonner de ton topic sur OC pour te suivre ici.

Merci d'être venu parmi nous !

Merci !
Désolé de la réponse un peu longue, j'attendais d'avoir quelque chose à présenter (voir fin du post)

@Andr0: Merci, ça me touche car c'est pour retrouver la communauté que je suis venu ici !
Mais même si j'ai bien l'intention de montrer l'avancement du moteur sur tous les sujets que j'ai ouvert (OC, progdupeu.pl, ZdS), il arrive dans ces topics qu'on me pose des questions auxquelles je réponds en donnant des détails intéressants (qui ne sont alors pas partagés sur les autres). Donc pour ceux qui veulent en savoir plus, qu'ils me posent des questions ou qu'ils regardent sur les autres sujets

@Gwenn: C'est une excellente idée, le moteur est capable de faire un rendu plus intéressant que tout ce que j'ai montré mais mon objectif est (actuellement) le côté technique. Cependant j'ai prévu de faire un petit jeu une fois les particules et le rendu de texte implémentés, ce sera je pense l'occasion pour moi de faire équipe avec un ou deux artistes ce qui fera évoluer le moteur pour le mieux !
Sans parler de la conception de quelques outils pour le SDK, mais ça ce n'est pas encore à l'ordre du jour.
Bref, wait & see

Et voici la dernière image des particules (work in progress):

Je suis ton projet depuis le tout début (avant que tu le rebaptises) et je dois dire que ça envoie toujours autant du pâté, si tu me passes l'expression.

Continue ainsi !

Je viens de passer quelques jours sur un bug (encore merci à Ziple au passage), et j'ai repris le travail sur les particules.

Et je suis assez content du résultat (images de développement dans l'ordre chronologique):

(La flamme carrée volante dans les deux premières images est un test de billboard indépendant des particules)

À noter que j'ai également commencé le travail sur Freetype, je compte bien tenter une implémentation (douteuse) pour faire une vidéo, et peut-être une démo

Désolé d'avoir été si long:

N'oubliez pas d'activer les annotations pour les détails techniques si ça vous intéresse.

Bonne nuit !

Bonjour Lynix,

Sympa le moteur, on sent le travail derrière. (je cache mon admiration ;]) Mais moi, savoir qu'il existe encore un autre moteur 3D libre (sans vouloir vexer) me perds encore plus dans mon choix d'un de ces moteurs!

La première possibilité qe j'ai connu, ce fut le BGE (Blender) que je n'ai jamais réussi à faire fonctionner, autant parce que cela me semblait très difficile de faire fonctionner l'API en Python qui pouvait d'ailleurs changer entre deux versions, mais surtout parce que je n'obtenais que des rendus moches et ternes avec pas de réflexion ni de radiosité ou d'occlusion ambiante ni des éclairages sympas, ou encore de Parallax (je ne dis pas qu'il est incapable de le faire je dis juste que je n'y arrivais pas ! Exemple Eclairage Sympa ou Belles Reflexions).

Puis il y a eu Ogre mais la courbe d'apprentissage doublée de celle du C++ (langage différent du C, à un autre niveau d'abstraction) a suffit à casser mon enthousiasme surtout que de l'autre coté, les rendus de Ogre avaient peu de sex-appeal (genre du QuakeIII). Même chose pour Irrlicht.

Ensuite, il y a les autres moteurs libres moins cités mais qui semble a priori plus facile d'accès Urho3d, Tesseract Engine, Maratis, GamePlay, … (Un peu plus complet )

Je suis donc assez perdu face à tous cela !

PS : J'ai ouvert un sujet sur Urho3D mais au fond je me pose la question pour tous les autres vu que je ne suis pas très connaisseur

PS2: Je ne peux pas m’empêcher : Allons-y Allonso!

Tout est dit.

Je me pose juste une question : "Tu cherches un moteur 3D certes, mais pour faire quoi ?"

1. Apprendre les bases du Rendu ?
2. Apprendre les bases du GamePlay (mécaniquede jeu, sans forcement avoir de projet en tête) ?
3. Faire un jeu ?
4. Faire un jeu 100% libre ?

Si c'est pour la 2eme ou 3eme raison, dans ce cas tourne toi vers une solution clé en main, comme l'a supposé Stranger dans ton post sur Urho3D (Unity3D / UE4 / Cryteck). Que ce soit pour apprendre ou faire un jeu, il y a suffisement à faire pour ne pas se prendre la tête avec toute la partie Engine (moteur de jeu).

En revanche si tu recherches à faire du rendu 3D, déjà laisse moi te souhaiter bonne chance. Ensuite je te conseillerai de d'abord tester un moteur de jeu pour voir ce qui se fait avec et jusqu'ou tu peux aller en bidouillant les shaders. Puis si tu en as toujours l'envie, lance toi dans du plus bas niveau avec OpenGL / DirectX.

Note: Ca se détourne un peu de "Nazara Engine", je t'invite donc à poursuivre cette discution sur ton post sur "Urho3D" si tu as d'autres questions.

Bonjour !

Je me permets de donner quelques nouvelles sur l'avancement du moteur (qui a fêté ses trois ans il y a peu, un récapitulatif de l'année écoulée est à venir).

Alors pour commencer, je sors de dépression, c'est une autre façon de dire que je n'ai pas été très productif ces trois derniers mois.
Cependant j'ai récemment avancé mon travail sur les polices de caractères.

J'ai donc créé la classe NzFont qui permet de charger et de récupérer des informations sur une police de caractères, comme son nom, son style, et bien entendu, le kerning et les glyphes.
Le moteur est agnostique par rapport au loader utilisé, et fourni un loader FreeType2 par défaut.

Les glyphes sont donc extraits et stockés dans des atlas, regroupant tous les glyphes d'une même police dans une image.
Ces images sont évidemment destinées à être utilisées comme textures lors de l'affichage de texte.

Voici le prototype de la méthode:

1

bool NzFont::Precache(unsigned int characterSize, bool bold, const NzString& characterSet) const;

Et le code d'exemple:

1
2
3
4
5
6
7
8

    NzFont font;
    font.OpenFromFile("Roboto-Regular.ttf"); // Normalement on devrait vérifier le retour de la fonction

    std::cout << font.GetFamilyName() << std::endl; // "Roboto"
    std::cout << font.GetStyleName() << std::endl;  // "Regular"

    for (int i = 900; i >= 15; i -= i/15)
        font.Precache(i, false, "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 !\"#$%&'()*+,-./:;<=>?@[\\]^_{|}~"); // Tous les caractères affichables de la table ASCII

À noter qu'il s'agit ici d'un stress test: 6392 glyphes sont chargés et stockés, venant de 68 tailles de polices différentes (de 15 à 900, ce qui est juste énorme comme taille de police !).
Voici le résultat en image, des atlas composés par la classe:

La classe a créé trois atlas (étant donné que je lui ait imposé une limite de taille de 8192x8192 par atlas) qui sont occupés (% espace rempli par des glyphes) respectivement à _99%, 98% et ~55%. Comme vous pouvez le constater, les glyphes sont agencés de manière extrêmement efficace grâce à l'algorithme de binpacking Guillotine intégré récemment dans le moteur. Merci d'ailleurs à Jukka Jylänki.
Il a d'ailleurs travaillé sur plusieurs autres algorithmes de binpacking intéressants, que j'envisage de tester pour remplacer celui utilisé pour l'instant, mais c'est loin d'être la priorité surtout au vu des performances actuelles.

Donc concrètement, toute police est créée avec un atlas de taille 512x512 dans lequel on insère les glyphes grâce à l'algorithme de packing, lorsque l'algorithme ne trouve pas de place, il va alors simplement augmenter la taille de l'atlas (pour le moment, ça se résume à la doubler) et réessayer.
Cependant, il y a une limite à la taille de l'atlas (si le Renderer est initialisé, elle est par défaut limitée à la taille de texture maximale supportée par le GPU). Et lorsque l'atlas ne peut plus grossir, un second atlas est créé (de 512x512), et le cycle continue.

Cela signifie donc qu'il n'y a pas de limite "en dur" au nombre de glyphes pouvant être stockés (il sera cependant possible de retirer des glyphes du cache, voire de vider le cache complètement).

D'ailleurs voici le résultat si j'augmente la limite de la taille des atlas au maximum supporté par mon GPU (16384x16384): Les trois atlas ne font ici plus qu'un, utilisé à ~63%.

Tout ça pour dire que de la place, on n'en manque pas, et que l'immense majorité des polices ne dépassera jamais un seul atlas.
Je commence même à réfléchir à une solution pour partager les atlas entre les polices, pour diminuer l'empreinte mémoire et améliorer le batching.

Par ailleurs, si on applique maintenant un cas un peu plus "traditionnel", c'est-à-dire tous les caractères ASCII affichables de la taille 96 à la taille 8:

1
2

    for (int i = 96; i >= 8; --i)
        font.Precache(i, false, "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 !\"#$%&'()*+,-./:;<=>?@[\\]^_{|}~");

Voici ce qu'on obtient:

Il y a ici 8366 glyphes utilisant ~53% d'un atlas 4096x4096, ce qui représente à peine 3% d'un atlas 16384x16384.
Vous avez aussi pu constater que certains glyphes sont stockés retournés, c'est une façon de mieux les emboîter, ça n'aura aucun impact sur les performances du rendu (les coordonnées de textures sont adaptées).
À noter qu'il existe un padding d'un pixel entre chaque glyphe pour éviter des problèmes lors du filtrage.

Les atlas sont stockés au format A8, nouvellement introduit dans le moteur (avec le retour des formats L8 et LA8 pour les textures).

J'ai encore un peu de travail avant de pouvoir afficher du texte sans peine avec le moteur, mais je pense que le plus gros est fait

Enjoy !

Je me vois obligé de le préciser, suite à quelques incompréhensions, je n'ai sans doute pas été assez clair: les atlas ne sont pas faits pour être affichés en l'état.

Concrètement ce qu'il va se passer c'est qu'une classe future du moteur (NzRenderedText ? NzTextSprite ?) va se charger de l'affichage du texte, en construisant des sommets/coordonnées de textures qui associés à l'atlas, formeront alors le texte affiché.
Dans la pratique néanmoins le moteur va utiliser de façon extensive le batching, aucun vertex buffer ne sera composé à l'avance pour un texte, c'est très probablement la ForwardRenderTechnique qui va se charger de reconstruire un vertex buffer commun à tous les textes utilisant le même atlas, afin de minimiser les draw calls et changement d'états

Je suis également en train de me renseigner sur la possibilité d'associer des polices entre-elles (pour gérer le gras, l'italique, etc.) dans une même instance de NzFont, tout en gardant l'API buvable

(Cliquez sur l'image pour l'agrandir si vous n'arrivez pas à lire).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

// Note: Il ne sera pas obligatoire d'utiliser cette classe directement
NzDefaultFontDrawer drawer(1200); // Longueur d'une ligne en pixels (0 signifie que ce sera la ligne la plus longue)
drawer.SetFont(font);
drawer.SetCharacterSize(48);
drawer.SetAlign(nzTextAlign_Middle); // Ligne positionnée au milieu
drawer.SetStyle(nzTextStyle_Bold); // Caractères affichés en gras
drawer.Append("Bonjour tout le monde !\n"); // \n représente un saut à la ligne explicite
drawer.SetStyle(nzTextStyle_None); // Désactivation du gras
drawer.SetCharacterSize(30);
drawer.Append("C'est avec une certaine fierté que je vous montre cette image,\nrésultat de la première implémentation de la classe DefaultFontDrawer.\n");
drawer.SetCharacterSize(26);
drawer.Append("Cel");
drawer.SetCharacterSize(24);
drawer.Append("le");
drawer.SetCharacterSize(22);
drawer.Append("-ci");
drawer.SetCharacterSize(20);
drawer.Append(" vous");
drawer.SetCharacterSize(18);
drawer.Append(" permet");
drawer.SetCharacterSize(16);
drawer.Append(" d");
drawer.SetCharacterSize(14);
drawer.Append("e ");
drawer.SetCharacterSize(36);
drawer.Append("composer un ");
drawer.SetStyle(nzTextStyle_Bold);
drawer.Append("texte");
drawer.SetCharacterSize(26);
drawer.SetStyle(nzTextStyle_None);
drawer.Append(", en changeant les paramètres à votre bon vouloir.\n\n");
drawer.SetAlign(nzTextAlign_Left);
drawer.Append("On peut également changer l'alignement des lignes (ici à gauche).\n");
drawer.SetAlign(nzTextAlign_Middle);
drawer.Append("Au milieu.\n");
drawer.SetAlign(nzTextAlign_Right);
drawer.Append("Et à droite.\n");
drawer.SetAlign(nzTextAlign_Left);
drawer.Append("Les glyphes sont chargés à la volée dans un atlas (affiché en arrière-plan).\n\n");
drawer.SetAlign(nzTextAlign_Middle);
drawer.Append("^ ici ^\n");
drawer.SetAlign(nzTextAlign_Left);
drawer.Append("Le FontDrawer supporte également le changement de couleur, de police, de style (gras, italique, soulignage, texte barré), ainsi que le saut automatique de ligne.\nEn revanche je n'ai pas encore écrit le code supportant l'affichage de ces dernières fonctionnalités.\n");
drawer.Append("L'affichage de caractères est donc découpé entre la gestion logique (FontDrawer) et l'affichage graphique (Nom à définir):\n");
drawer.SetAlign(nzTextAlign_Right);
drawer.Append("NzRenderedText ?\n");
drawer.Append("NzTextSprite ?\n");
drawer.SetAlign(nzTextAlign_Middle);
drawer.SetCharacterSize(36);
drawer.SetStyle(nzTextStyle_Bold);
drawer.Append("Et je manque de place, n'hésitez pas à laisser vos avis et bonne soirée !");
drawer.Finish(); // Effectue l'alignement des lignes et génère les positions finales des caractères

J'en profite pour ajouter quelques détails sur une autre amélioration liée, ici l'entièreté du texte est rendue en un seul draw call grâce à un travail effectué sur le rendu des sprites.

Désormais la RenderQueue gère les sprites comme un ensemble de sommets et rien de plus, qu'elle va envoyer au GPU sans se poser de question.
La classe NzSprite peut maintenant se permettre de mettre en cache ses sommets et les envoyer à la RenderQueue (sans copie) en un appel lors du rendu.

Sans oublier que la RenderQueue supporte maintenant le chaînage de sprites (des sommets contigüs en mémoire) et agira de façon efficace, par exemple le texte du screenshot (qui représente quelques centaines de sprites) n'est copié qu'une seule fois par frame, vers le GPU en un seul appel à std::memcpy.

Pour comprendre ce qui a changé ici, imaginons qu'on fasse un jeu Mario/Zelda/Pokémon (dont le décor est constitué de nombreux sprites) avec Nazara.
Pour cet exemple, disons donc que chaque tile du jeu fait partie d'une même texture.

Soit nous représentons chaque tile par un NzSprite (Au plaisir de se retrouver donc avec des centaines de sprites dans la scène), soit nous représentons le décor entier à l'aide de quelques tileset (comprenant chacun des dizaines de tiles).

Dans le premier cas, le moteur n'affichera que les tiles visibles à l'écran (grâce au culling), cependant il devra les copier un par un dans le buffer de rendu.
Dans le second cas, le moteur sera obligé d'effectuer le rendu de certains tileset qui sont à peine visibles à l'écran, mais qui seront transférés plus rapidement vers la carte graphique.

Juste histoire d'être clair: grâce au batching il n'y aura aucune différence du point de vue du nombre de draw calls ou d'instructions GPU, tous les sprites partageant le même matériau sont réunis dynamiquement de toute façon, peu importe leur origine (donc même en cas de mélange sprite/tileset).

Quelle serait donc la méthode la plus efficace ? Tout dépend de la taille du tileset (ex: un tileset 2x2 diviserait par 4 le nombre de tests de visibilités et serait plus efficace à transférer que quatre sprites).
Ça mériterait un petit benchmark tiens, et je suis tenté par la création d'un petit jeu du genre comme exemple d'utilisation du moteur.

Bref, le moteur avance pas mal ces derniers temps, et cette année de merde se termine, que de bonnes nouvelles.

Bonsoir tout le monde,

Le moteur est très proche de la beta, je posterais le résumé annuel (qui a maintenant un mois et huit jours de retard, héhé…) dans les prochains jours.
L'implémentation est donc fonctionnelle, mais je me rends compte que le plus gros problème du moteur en ce moment est au niveau de l'interface: elle n'est pas pratique à utiliser.
Je ne sais pas encore exactement comment je vais m'y prendre, soit je vais réussir à visualiser l'interface idéale, vous la présenter et modifier le moteur en fonction, soit je vais poster un nouveau topic pour chercher des solutions aux problèmes auxquels je suis confronté.

Quoiqu'il en soit, il y a un autre problème sur lequel vous pouvez certainement m'aider, j'ai décidé d'intégrer une police par défaut dans le moteur (pour faciliter l'utilisation du moteur), je suis parti d'une liste d'une petite dizaines de polices (qui me plaisaient, purement et simplement), et j'ai réduit mon choix à deux polices: Cabin et Sansation.

Cabin est plus classique, Sansation plus originale, et aimant l'originalité je vote en faveur de Sansation.
Mais vos avis m'intéressent !

Je me permets également exceptionnellement de faire une petite parenthèse sur ce qui s'est passé ces derniers jours en France:

Ce n'est pas grand chose mais je ne pouvais pas me résoudre à ignorer cet évènement qui me touche tout autant que vous.
Courage de la part de la Belgique, une fois.

Personnellement, je pense qu'intégrer de base une police classique est plus logique : elle est faite pour rendre le moteur plus accessible, inutile d'en réduire l'impact avec une police plus originale qui a moins de chances de servir

D'un point de vue strictement personnel, je préfère nettement la police Cabin. Je la trouve plus classique et donc plus "professionnel".

Sinon, bravo pour le travail que tu accomplis. Je poste pas toujours mais je suis toujours l'avancement avec grand plaisir.

J'ai aussi une préférence pour Cabin car elle se rapproche du conventionnel. Après, je serai du même avis que Phigger, pourquoi ne pas intégrer une police classique par défaut ? (Arial / Helvetica) et laisser l'utilisateur le choix de la customisation ?

Ce n'est qu'un avis En tout cas, bravo pour ton boulot, ça fait déjà un long moment que je le suis en restant plutôt silencieux également

Merci pour vos encouragements, ça fait toujours plaisir

À la question "pourquoi ne pas distribuer une police classique du style Arial/Helvetica", je réponds que je ne peux pas, tout simplement.
Le fruit de mes (maigres) recherches m'indique que ces polices sont sous licence (et que par exemple l'achat de Windows vous permet d'utiliser ces polices, mais en aucun cas de les redistribuer gratuitement).

Source 1
Source 2
Source 3

C'est pourquoi je me suis tourné vers des polices de caractère libres comme Cabin et Sansation (Dont la seule obligation est de faire circuler le texte de licence avec le fichier de la police, moi je m'en fiche mais ça m'emmerde d'obliger les utilisateurs du moteur à se promener avec un .txt, il faudrait que je l'intègre quelque part dans le moteur lui-même…).

Pour Cabin et Sansation, je trouve simplement que Sansation rend mieux (traits plus fins) et donne une certaine identité au moteur, une certaine originalité. En revanche l'argument "Cabin est plus classique, plus professionnelle, elle contentera plus de monde" est tout simplement imparable.

Ainsi soit-il.

Edit: Oh, j'oubliais, si vous trouvez une autre police qui ferait très bien l'affaire et qui n'ait pas de licence chiante (comme Liberation Sans qui est malheureusement sous GPL…), n'hésitez pas !

Avec seulement un mois de retard:

Je vous invite à lire le résumé annuel sur le forum du moteur (sur lequel je vais essayer de basculer progressivement).

Concernant la police, Cabin sera intégrée dans le moteur par défaut, merci pour vos retours !

Tu pourras me compter dans les bêta testeurs Bonne chance pour cette année !

Est-ce que tu comptes publier ton (ou tes) tutoriel(s) sur Zeste de Savoir ?