GPFontMaker 2.0 W.I.P - Page 1

Je suis en train de travailler sur la version 2.0 de GPFontMaker.

A première vue, le programme à l’air d’être le même, mais en réalité il incorpore de nouvelles propriétés qui permettent de générer de fontes de bien meilleure qualité (si on veux bien se donner la peine de les traiter avec un éditeur d’images).
C’est dû surtout à la possibilité d’incorporer un masque a la fonte grâce à laquelle on peut réussir des effets d’ombres ou d’antialiasing
Mais il faut tenir compte du fait que GPFontMaker ne calcule ni le masque ni l’ombre, il nous prépare les bitmaps (principale de la fonte et celle du masque) pour que l’on puisse les traiter plus aisément avec un éditeur d’images comme PhotoShop.
En plus GPFontMaker continue à ne savoir générer que des fontes en 16bits.

Mais je crois que l’amélioration la plus importante, est que GPFontMaker est maintenant capable de générer un nouveau type de fichier que j’ai mis au point (.OKF = Oankali Font ;-) ) et qui contient toute l’information nécessaire pour bien afficher la fonte (bitmaps, type de fonte, tailles de chaque caractère, etc…)
Ce type de fichier a été pensé pour occuper le moins d’espace possible sur la carte SMC sans pour autant entrer dans des techniques poussées de compression. En effet, les bitmaps son codés avec un RLE fait maison qui tient compte de caractéristiques de la GP32. Avec ce système, une fonte 16bits peut occuper de 3 à 10 fois moins d’espace sur la carte SMC, en fonction du traitement qu’à subit la fonte et de si elle contient un masque.
Et si on le désire, GPFontMaker peut générer automatiquement les fichiers .H et/ou .C avec le fichier .OKF complet au cas où l’on voudrait l’inclure directement dans le .FXE.

Et bien sûr, tout sera accompagné d’une librairie complète de fonctions 16bits pour pouvoir traiter ces fontes. Le code source, totalement en C sera libre et le format .OKF documenté.

Je suppose que tout sera disponible dans 15 jours si je ne trouve pas d’autres problèmes à ceux déjà rencontrés. (J’ai refait plusieurs fois le module d’exportation pour améliorer la gestion des ombres et des transparences).

L’objectif de cette nouvelle version était de mettre au point un format de fonte standard de haute qualité pour la GP32 que nous pourrions tous inter changer, et qui pourrait substituer le système actuel de fontes de l’SDK officiel de la GP32.
L’objectif N’était PAS de créer un clone des fontes TrueType, vue que les fontes .OKF sont des fontes bitmap d’une seule taille et pas des fontes vectorielles de plusieurs tailles.
Quand je publierais mon travail, vous me direz si j’ai réussi mon paris.

Et maintenant, quelques questions pour la communauté:
1. Est-tu intéressé par ce système de fontes?
2. Penses tu l’utiliser?
3. Quelqu’un a-t-il jeté un coups d’oeil à la version actuelle de GPFontMaker?
4. Quelqu’un a-t-il utilisé la version actuelle de GPFontMaker pour générer des fontes?
5. Dans ce cas, comment améliorerais tu GPFontMaker?

Pour finir, si quelqu’un est intéressé à optimiser les fonctions de ma librairie avec de l’assembleur, qu’il se mette en contact avec moi.

Oankali.

L’objectif de cette nouvelle version était de mettre au point un format de fonte standard de haute qualité pour la GP32 que nous pourrions tous inter changer, et qui pourrait substituer le système actuel de fontes de l’SDK officiel de la GP32.

ça c'est vraiment une bonne idée vu que le systeme actuel est vraiment nul...

ca a l'air vraiment bien, j'attend la release!!

J'ai rien compris...

Excellente news Oankali! Merci pour ton super taff

Si vous voulez voir un exemple:
http://www.gp32spain.com/foros/showthread.php?s=&postid=53722#post53722

A oui, pas mal du tout

Pour l'instant je n'ai pas eu a utiliser de fontes. J'y vais barbare avec la fonte de base.
- pour la compression, c'est plus pour le fun, pour le defi de programmation que pour un reel gain de place, non ? Je dis ca parce que je ne pense pas que la fonte soit ce qui prenne le plus de place dans un soft.
- vraiment pas de 8bits ?
- je n'ai pas teste/utilise/debuge gpfontmaker. Je debute un peu en prog gp32 et je n'ai pas encore eu besoin d'un tel soft. Et la je rentre du ski, j'ai je ne sais pas combien de centaine de mails a lire et les tableaux de http://yaouank.gp32news.com a mettre a jour. Desole, je pourrai pas jeter un coup d'oeil sur ton soft tout de suite.

Bein non, pas de 8 bits, bien que j'ai quand même prévu le 8 bits dans le format de ficher .OKF, mais je n'ai pas l'intention de le programmer dans mon moteur.
Le 16 bits est plus simple à programmer et surtout celà voudrait dire que mon moteur de fontes aurait à gérer non seulement les couleurs de la fonte mais aussi les couleurs du reste de l'écran.
Avis aux amateurs.

Pour la compression ce n'est pas seulement pour le fun. 2 exemples que vous pouvez trouver dans le screenshot publié vendredi dernier:
La fonte en couleur: le fichier .OKF occupe 50Kb. Le bitmap principal non comprimé 45.7Kb, et le masque non comprimé 54Kb
La fonte en noir en bas: le fichier .OKF occupe 3540 octets (2983 octets pour le bitmap, le reste pour les tables). Le bitmap principal non comprimé 22260 octets. Il n'y a pas de masque.
Les deux fontes ont des tables de 130 caractères (accents, maj., min., chiffres, signes de ponctuation, etc..)
C'est sûr qu'on est pas obligé de préparer de fontes aussi complètes. Il suffit des fois de juste mettre les chiffres ou juste les lettres en majuscules.
En fait, l'idée que j'ai c'est que si quelqu'un prépare une belle fonte pour être réutilisée par d'autres applications, autant qu'il y ai de tout et qu'elle soit bien complète. Par contre si le but est de l'intégrer dans le .FXE, il s'agit d'y mettre le strict minimum.
Ça a l'air de rien comme ça, mais si le jeu a plusieurs fontes (Puzzle Mix en a 6 dont une assez grosse pour les menus et les opcions), bein ça fait un certain gain de place. Par contre il faut savoir qu'une fois le programme lancé, les fontes sont complètement décodées.

Pour le probleme des palettes, sa serait pas plutot aa chacun de prevoire la palette conrespondant au jeux en comptant les fonts ??

Si, si la fonte n'a pas de masque.
Car lorsqu'il y a un masque la couleur résultante est une combinaison de la couleur existante sur l'écran, de la couleur de la fonte et de l'intensité du masque.
Ça au minimun, puisque il est possible de modifier certaines propriétés au moment d'afficher un texte, comme par exemple la couleur ou l'intensité.
Ça va être chaud pour celui que voudra passer ça en 8 bits!!
À la rigueur il vaudrait peut-être mieux préprarer un moteur de fontes exclusivement 8 bits avec pas mal de restrictions. C'est à voir.

Oui, sa peut etre la solution ideal.

Bon, tout à l'air de marcher correctement.
Le format du fichier a l'air stable. Je pense que je ne vais plus le modifier.
Le moteur de fontes est prêt lui aussi mais je veux rajouter quelques fonctions de haut niveau qui ne sont pas indispensables mais qui peuvent servir, comme par exemple la duplication d'une fonte en mémoire pour pouvoir la modifier avant de l'utiliser.
Le programme de test des fontes est lui aussi bien avancé et permet de bien tester les fontes ainsi que connaitre les propriétés d'une fonte.
Je pense que dans une semaine à peu près je pourrais publier mon travail. On verra pour la documentation