Jackamikaz dev'

Dev d'un GTD

2010-09-04T20:42:00.006+02:00

Depuis que j'ai décider de coder mon moteur de jeu, il m'arrive la même chose qu'avec beaucoup de projets : la motivation du début tombée, je n'y touche plus.

C'est un beau problème psychologique commun que j'ai là. Heureusement, il y a des solutions qui existent.
En parcourant le net avec des mots clef du genre "motivation" "procrastination", je suis tombé sur pas mal d'articles donnant des conseils visant personnes à tendances dépressives. De très bon conseils la plupart du temps, que j'applique souvent déjà depuis longtemps. Mais le conseil le plus intéressant et récurrent que j'ai pu trouver est celui d'utiliser une technique Getting Things Done (GTD).

Bon OK. Pour un geek comme moi le meilleur moyen d'appliquer ca est d'utiliser mon ordinateur. Et donc on tombe sur pas mal de logiciels, du genre Remember The Milk.
Problème: j'ai déjà utilisé ce logiciel et déjà tenté de résoudre mon problème avec. Ca n'a pas du tout marché. Le problème, c'est qu'il faut se fixer soi-même des dates limites. Généralement, les dates limites marchent bien avec moi. Sauf que la façon dont je les gère est celle d'utiliser le stress généré par l'approche de la date pour me motiver à bosser. Et je stresse car j'ai des ennuis si jamais je ne fait pas ce qui est à faire. Donc quand c'est moi qui me fixe une date limite, qui plus est sur un projet totalement personnel (le moteur 3D ici), la date n'a donc aucun sens et je finis par n'avoir rien fait.

Donc je me pose un instant pour réfléchir. Ce que je veux, ce n'est pas rendre quelque chose mais faire quelque chose. Donc avoir un système qui me dise de devoir faire telle ou telle tache tel ou tel jour. Un emplois du temps quoi.

Et si au final je ne fait pas la tache? Je n'ai pas envie que cette tâche soit reportée tout comme c'est le cas avec Remember The Milk. De plus, si elle reportée avec l'état "en retard" et qu'elle s'accumule avec toutes ses jumelles suivantes, tout cela perds encore de son sens et je finis par effacer toutes les taches et oublier le projet.

Donc je veux une tache récurrente, qui puisse être ratée, même complétée à un certain pourcentage. Voilà ce que ca a donné!

Code couleurs des tâches :
- Vert : pas à faire ce jour là
- Bleu : complétée à 100%
- Orange : entre 20% et 80%
- Rouge : en dessous de 20% (ratée)
- Cyan : A rapporter

On se rend compte que je n'ai pas beaucoup bossé sur le projet depuis longtemps ... Mais j'ai une bonne excuse, c'était justement pour programmer ce GTD.
En tout cas, le résultat est probant pour le ukulélé! J'ai énormément progressé cette semaine. Sauf que raconter ce détail sort du contexte du blog.

Avancement

2010-08-19T21:05:00.003+02:00

Une note rapide pour présenter l'avancement du projet :

Rien de mieux qu'une image pour expliquer ça. Les classes entourées de bleu représentent celles avec un début d'implémentation. Cette couleur signifie que l'idée générale du rôle de la classe et son interface est présente dans le code, donc rien de complet, juste "prêt à être rempli".
D'autres couleurs sont à venir pour représenter un meilleur avancement, donc! Et puis le diagramme lui même peu changer parfois.
Ce qui est sûr, c'est qu'on se rend bien compte qu'il faut beaucoup de boulot pour achever tout ça. Car même ce petit bout d'avancement nécessite du temps.

Mes prochains objectifs sont:
- Implémenter quelques classes de graphismes
- Implémenter les classes InputDispatcher et InputUpdated
- Afficher deux ou trois cubes et pouvoir en contrôler un!

Ca demandera donc au minimum huit nouvelles classes. Ca fera donc probablement seize nouveaux fichiers. Raah, c'est pas le plus marrant d'écrire juste de la structure. Et ca prend du temps également. Allez, une grande inspiration et puis je m'y met.

Moteur de jeu 3D

2010-08-17T19:56:00.006+02:00

Allez hop-là un nouveau message ... parce que j'ai envie. Non pas que je suspecte ce blog de revenir à la vie mais bon, y'a des jours comme ca, on est d'humeur à faire des updates.

En réalité, la seule raison qui me pousse à faire ça est que je me suis remis à la programmation. Les examens de Teesside étant terminés depuis longtemps, la glandouille des vacances n'étant pas applicable (en plein mois d'Août, ah bon?), peu de choses sont donc en travers de ma route pour que ma motivation s'épanouisse.

Pour faire court, j'ai commencé un nouveau projet. Un moteur de jeu 3D, rien que ça. Ceci n'étant pas une mince affaire, j'ai d'abord commencé par m'organiser un minimum. Alors j'ai produit ce diagramme de classes :

Pour les curieux ignorants, c'est fait avec le logiciel StarUml.
Les normes UML ne sont pas totalement respectées, il y aura certainement plus de classes que ça au final, mais l'idée générale est présente.

La plupart des composants habituels sont là pour un moteur 3D standard. On distingue plusieurs groupes :
- Le coté matériel
- Les graphismes
- L'acquisition de données
- Le monde virtuel

Il ne pas confondre le matériel vidéo et les graphismes ici (même principe pour le son et input). Les classes "device" sont là pour faire abstraction du système utilisé. Pour "VideoDevice" par exemple, j'utiliserais certainement OpenGL. Mais il pourrait être remplacé par n'importe quoi, comme DirectX. Les classes de graphismes utilisent seulement la même interface.

Là où ça devient curieux, c'est que les graphismes sont actualisés (héritent de la classe "FrequentlyUpdated") en dehors du monde virtuel. J'ai voulu séparer clairement ces choses là. Et c'est même plutôt logique d'après moi. Mais il faut quand même qu'ils affichent quelque chose, d'où l'idée d'une classe "Feedback", qui contiendrait tout ce qu'il y a à savoir sur le coté visuel de ce monde virtuel.
Voilà un petit diagramme pour mieux comprendre :

(là pas de secret, c'est fait avec Paint)

Ca a l'air on ne peut plus logique non? C'est un cycle symétrique! (j'invente, ca sonne bien) . Le principe "une entité communique avec le monde" en ressort. L'intelligence est séparée de la réalité. L'intelligence stimule la réalité et la réalité stimule l'intelligence en retour. "L'intelligence" ici étant une entité, comme le joueur ou une IA.
Malgré mes faibles connaissances de communication réseau en temps-réel, je vois là le potentiel d'adapter facilement ce système pour du multijoueur en ligne.

Bon mine de rien je m'emballe un peu. Je suis certainement en train de réinventer la roue, comme toujours. Sauf que je n'ai pas vraiment lu, vu ou entendu quoi que ce soit qui ressemble à ce principe de "feedback". Si vous lisez ce post et que vous connaissez un quelconque article traitant de cette idée, faites-le moi savoir!

Portage du jeu et anecdote

2010-01-25T20:54:00.006+01:00

Cela fait un petit moment déjà que je n'ai pas posté de nouveau billet.
La raison est que j'ai n'ai pas vraiment de nouvelles choses à dire, si ce n'est que j'ai travaillé énormément sur mon projet GS1. Il est terminé, c'est sûr, mais dans le cadre des études. Je n'ai ajouté aucun élément de gameplay ou autre fonctionnalité, loin de là.

Non, le plus intéressant est que maintenant il marche totalement avec SDL comme librairie graphique, et FMod pour les sons. Le renderer software est toujours présent et marche parfaitement avec SDL (sauf que ce n'est certainement pas codé proprement, j'ai eu la flemme de faire les appels aux fonctions lock surface pour écrire directement dans le buffer).

J'ai également amélioré le renderer software en ajoutant les plans de clipping de la caméra. Ca a permis de supprimer quelques bugs d'affichage de triangles, produisant des aberrations dans le depth buffer parfois (par exemple, dans the death corridor, si vous vous collez sur les bords vous remarquerez que les murs s'affichent partiellement par dessus le vaisseau avec une forme ronde). J'ai d'ailleurs une anecdote intéressant sur le sujet :
Au départ, j'ai voulu trouver une solution pour le clipping moi même (comme toujours, j'ai envie de réinventer la roue. C'est dans quel contexte déjà? Ah oui! Je fais un renderer 3D en software ... réalisé un millier de fois par un million de personnes depuis déjà 20 ans au moins). J'avais beau retourner le problème dans tout les sens, le clipping semblait fonctionner mais certains polygones disparaissaient toujours mystérieusement ... A force de tourner en rond je finis par m'avouer vaincu et décide d'adopter une méthode déjà existante : l'algorithme de clipping de Sutherland Hodgman. Je l'implémente, tout fier de moi, et j'obtiens le même résultat! En fait mon propre clipping marchait parfaitement, c'est juste que j'avais oublié un détail en dehors de cet algorithme. Mon code ressemblait à ca:

récupérer le triangle T à afficher
appliquer la matrice de transformation à T
clipper T pour obtenir un polygone P
appliquer la matrice de projection à T
test du backface culling en fonction de T
...
appliquer la matrice de transformation à P
afficher P

Vous voyez le problème? Un indice : les aberrations surviennent lorsque la projection est appliquée sur des points situés hors caméra. Toujours pas? Autre indice : le backface culling vérifie si un triangle doit être affiché ou non (mon problème vient de polygones qui ne s'affichent pas). Je saute quelques lignes pour éviter de spoiler la réponse ;)

Le problème était que je testais le backface culling avec T, non clippé, qui pouvait donc avoir des valeurs totalement fausses après l'application de la matrice de projection. La solution consistait donc à ignorer totalement T cette fois (car d'autres calculs étaient faits dessus) en le remplaçant par l'un des triangles que compose P .

Le clipping en lui même marche bien maintenant, mais il nécessite encore quelque optimisations. Le fait est que j'implémente l'algorithme de Sutherland-Hodgman avec des std::list. Du coup pleins d'allocations et désallocations mémoire en plus de copies inutiles sont effectuées. Ce qui donne un fort ralentissement lorsque la caméra passe à l'intérieur d'un polygone (au début de fighting above the earth). Mais le soulagement d'avoir enfin trouvé et réparé ce bug, précédé par quelques crises de nerf, m'ont incité à passer à autre chose :

Le portage du jeu vers OpenGL.
Cette fois, je garde SDL comme base, mais je remplace toutes mes opérations de rasterisation et calcul de matrice fait main avec des appels à l'API. Le plus dur n'est pas vraiment savoir quoi utiliser, mais plutôt savoir quels réglages appliquer pour obtenir le bon affichage. Voilà l'état d'avancement en images :

L'affichage de mes modèles fonctionne correctement, le chargement des textures aussi (sauf que c'est mal paramétré dans ce cas là donc on ne voit rien, juste un carré blanc pour les astéroïdes). Mes astéroïdes sont affichés en tant que billboards (ce qui fera certainement l'objet d'un prochain billet), et il reste à ajouter l'éclairage. Enfin, je n'aurais plus qu'à remettre en place le fond étoilé puis la planète et le tour sera joué.

Quand le portage OpenGL sera effectué, je tenterais de porter tout ca sur DS! Je suis trés confiant pour OpenGL, mais en ce qui concerne la DS, j'ai beaucoup de choses à apprendre et ca risque de prendre beaucoup de temps. Mais j'avoue que voir son propre jeu en 3D tourner sur sa petite console est une grande motivation.

Shooter 3D

2010-01-15T21:16:00.005+01:00

Et le voilà! L'aboutissement du module à Teesside, Game Software Development 1.
Comme je vous l'ai dit à propos du moteur 3D sur un post précédent, j'ai développé un jeu 3D pour un projet qui en demande un en 2D et interdit toute librairie graphique. C'est comme ca que j'en suis venu à faire un moteur 3D en software.

Donc voilà le résultat!

Si vous devenez ultra fan de ce jeu, jetez un oeil aux fichiers xml, et si vous en comprenez le fonctionnement vous pourrez créer vos propres niveaux. Bon ok il faudra faire ça à la main mais ça peut devenir amusant.

Par ici pour le télécharger

Génération procédurale : Perlin

2010-01-09T12:30:00.005+01:00

Tout geek dans la programmation jeux vidéo qui se respecte doit forcément en venir là un jour : la génération procédurale.
Premièrement, ca simplifie et accélère le processus de création dans un jeu vidéo. De deux, ca consiste seulement à utiliser de la programmation pour prétendre qu'on est créatif. De trois, "génération procédurale" ca sonne bien et ca donne l'air intelligent.

Le point de départ lorsqu'on s'intéresse à la génération procédurale, c'est Perlin. Vous n'allez peut-être pas le croire, mais même si son nom ressemble à un de ces vieux grecs (Thalès, Pythagore...) qui sont toujours aussi utiles de nos jours, Perlin lui, n'as pas 2000 ans d'avance. Il est même encore en vie.

Ce qu'il nous a apporté, c'est le bruit de Perlin. C'est à dire une fonction aléatoire pas si aléatoire. On peut dire aussi du bruit cohérent. Bon alors c'est quoi la différence entre un bruit non cohérent et un autre qui l'est? Rien de mieux qu'une image pour expliquer:

Une belle texture pour un nuage!
Ca peut également servir de heightmap.
Avec ça comme base, on peut générer des tas d'autres choses.

Vous voulez faire pareil?
Alors vous aurez besoin de la fonction de bruit de Perlin, ici sur son site. Attention, ça ne donne pas le résultat nuage que je vous ait montré.
Pour avoir ce résultat, il faut combiner plusieurs bruits de perlin. Ici il y a un tutorial qui explique bien comment faire.

Attention! Si vous voulez utiliser la fonction du bruit de perlin, celle qui est donnée sur son site retourne une valeur entre -1 et 1. Alors que pour produire une image les composants red green et blue sont entre 0 et 255. L'erreur serait de multiplier uniquement par 255, mais ca donnerait quelque chose entre -255 et 255. Soit ca fait bugger votre programme, soit vous obtiendrez une image avec des zones noires uniformes (car les valeurs entre -255 et 0 sont transformées en 0).

Pourquoi je vous parle de ça? En 3GS on a commencé les textures générées procéduralement, et comme je vous l'ait dit, il faut bien commencer par le commencement. Et donc chez moi ça donne ceci :

Liens

2009-11-18T22:38:00.005+01:00

Voilà quelques liens que je tiens à partager :

Toymaker : le site de mon prof en Game Software Development. Il est remplit d'enormement d'informations sur la creation de jeux et propose aussi quelques articles comme par exemple "trouver un boulot dans l'industrie du jeu video" ou encore "les jeux videos sont bons pour la sante".

Kromatyk : le blog d'un gars encore plus geek que moi. Et également mon seul lecteur régulier à l'heure actuelle xD (yep bro, dédicace!!)

Teesside : là où j'étudie en ce moment. Super endroit, vraiment.

Me concernant :
Jackamikaz' Games : un petit site qui regroupe mes jeux.
Twitter : ma page twitter
Voyage en Nouvelle Zélande : le récit inachevé de mon stage en Nouvelle Zélande

Faire un renderer 3D basique en software

2009-11-18T17:05:00.009+01:00

note : HAPI est une API qu'on est obligés d'utiliser en Game Software Development. En gros ca permet juste de créer une fenêtre, et manipuler le buffer de celle-ci. Aucune autre librairie externe n'est autorisée (à part STL quand même). Son but est de nous apprendre les bases des graphismes 2D, comme le blitting, le background scrolling, les sprites, les animations ...

Etant pas mal en avance sur la plupart de mes modules en ce moment, et après une discussion avec un camarade de classe sur "faire un jeu en mode 7 avec HAPI" ... l'envie m'est pris de faire coder un renderer 3D avec.
"Ca peut sembler dingue" pensais-je, mais pour obtenir quelque chose de basique, il ne faut pas grand chose!

Les pré-requis
Ils sont surtout mathématiques, et pas si dur que ça, on peut trouver et comprendre tout ça très rapidement sur wikipedia :

1) Les vecteurs :

Addition
Soustraction
Produit vectoriel
Produit scalaire

2) Les matrices :

Identité
Produit matriciel

3) La combo des deux : le produit vecteur fois matrice.

4) Une expérience avec DirectX ou OpenGL ne fait vraiment pas de mal!

Les points à dessiner
C'est pas tout ca, mais il faut bien quelque chose à afficher!
Pour tester mon programme, j'ai commencé par créer un cube avec ces coordonnées :

p1( 1, 1, 1)
p2( 1,-1, 1)
p3(-1,-1, 1)
p4(-1, 1, 1)
p5( 1, 1,-1)
p6( 1,-1,-1)
p7(-1,-1,-1)
p8(-1, 1,-1)

L'étape suivante, c'est de transformer ces points pour obtenir leur position à l'écran.

Les matrices de transformation
Mais avant ça, il faut obtenir des matrices de transformation, qu'on va combiner entre elles pour obtenir une matrice de transformation finale, laquelle va être appliquée à nos points (d'où la multiplication de vecteur par matrice).

Vous pouvez trouver comment les produire avec la documentation OpenGL (que j'ai évidemment utilisée!).
Un autre lien intéressant, qui explique le principe de ces matrices, sur le site du zéro.

Il n'y a pas besoin de plus que ces matrices là, vraiment :

Translation
Rotation autour d'un axe (X, Y, Z ou même quelconque)
Perspective
LookAt (pour la caméra)
ViewPort (pour adapter à la taille de l'écran)

Catégorisation des matrices
Pour obtenir la matrice de transformation finale, il est bon de savoir quelle matrice de transformation utiliser, à quel moment et dans quel ordre. C'est là qu'on voit trois catégories apparaître :

La matrice de projection
La matrice de la caméra
La matrice "du monde"

Pour la première, c'est généralement celle où on applique la matrice de perspective. C'est pas obligé en temps normal, mais pour avoir de la 3D c'est indispensable (or c'est le but ici!). Dans notre cas, pas comme dans DirectX ou OpenGL, il faut aussi prendre en compte la taille de l'écran. Donc on la combine aussi avec une matrice view port. Ce qui donne (précisément dans cet ordre) :

Projection = ViewPort * Perspective

Pour la caméra, un bon vieux LookAt reste toujours très efficace. Mais rien n'empêche de la bouger à coup de translate et/ou rotate. Si on choisit de fait comme ca, il faut garder à l'esprit que la position de départ de la caméra correspondrais à ce LookAt :

LookAt( 0,0,0, 0,0,-1, 0,-1,0)

Pour la matrice du monde, c'est celle qui est utilisée pour transformer les objets qu'on veut afficher. Donc essentiellement du rotate et du translate. C'est aussi là que push et pop sont utiles pour les transformations locales.

Projection des points
Enfin, lorsqu'on veut afficher un objet, il faut commencer par projeter tout ses points sur l'écran. Et là, rien de plus simple, à part qu'il ne faut pas négliger l'ordre de multiplication des matrices :

pointProjeté = point * projection * caméra * monde
// ou pour être encore plus précis :
//(j'insiste sur l'ordre!)
pointProjeté = point * ViewPort * Perspective * LookAt * matriceMondeCourante

Dans le cas du cube, on applique ceci pour p1 jusqu'à p8. Dans des points à part c'est mieux, histoire de ne pas avoir à redéfinir la position de base à chaque frame (question d'optimisation).

Dessin du triangle
Vous avez suivi? Si vous voulez expérimenter comme moi, le mieux serait d'abord d'afficher uniquement des points pour voir si la projection fonctionne.
En tout cas, maintenant on prend ces points projetés trois par trois, et on affiche un triangle à partir de ceci!
Si vous voulez un algorithme, réfléchissez-y vous même ou bien cherchez sur Google avec le mot clef "rasterize". Personnellement j'ai cherché de cette façon mais je n'ai pas trouvé quelque chose d'acceptable. Alors je me suis posé devant une feuille de papier et j'ai créé un algorithme. Ce n'est pas si compliqué, mais pas forcément le plus optimisé (j'utilise uniquement des nombres flottants, mais vu la puissance des processeurs actuels et le but de ce renderer c'est pas si grave je pense).

Le depth buffer
Le depth buffer est un tableau à deux dimensions de la même taille que l'écran. Chaque position correspond à une profondeur pour chaque pixel. A chaque fois qu'on ajoute un pixel, on vérifie si sa profondeur est plus ou moins grande que celle du depth buffer à cette position. Si la nouvelle profondeur est "plus profonde" alors on ne l'affiche pas, sinon ... ben on l'affiche.
Cette technique permet de régler le problème d'ordre d'affichage des triangles. En l'utilisant, on se fout de l'ordre et même deux triangles peuvent être en intersection. C'est aussi très facile à implémenter. N'oubliez pas d'interpoler la valeur z également lors du dessin du triangle!

Optimisation
On a maintenant assez pour afficher quelque chose de correct à l'écran! Mais on peut aussi ajouter un "backface culling", c'est à dire ne pas prendre en compte les triangles qui ne sont pas "tournés vers" la caméra. C'est utile pour l'affichage de formes fermées (comme le cube), mais ca implique de devoir spécifier les points du triangle dans le sens inverse des aiguilles d'une montre.
Implémenter un backface culling n'est pas dur non plus :
1) on récupère la normale du triangle avec ses points projetés
2) on vérifie si la valeur z est négative (ou positive, je sais plus...)
3) si oui, on l'affiche
Ce qui donne :

avec p1,p2 et p3 les points PROJETES du triangle :

// c'est à cause de ce cacul
// que le sens dans lequel
// les points sont spécifiés est important
normale = produitVectoriel( p2 - p1, p3 - p1 )
si (normale.z < 0)
{
dessinerTriangle(p1,p2,p3)
}

Et plus encore!
Prendre en compte des lumières! Dans mon cas, je me suis limité à une seule lumière directionelle. Une lumière ne fait que modifier la couleur d'une surface (d'un triangle quoi). Pour la lumière directionnelle, on multiplie la couleur qu'on veut attribuer au triangle par un produit scalaire entre les vecteur unitaires de la normale du triangle et de la direction de la lumière. En résumé :

n = vecteurUnitaire(normale)
d = vecteurUnitaire(directionLumière)
// j'appelle cette variable dot
// parce que produit scalaire
// en anglais donne dot product
dot = produitScalaire(n,d);
si (dot > 0)
{
couleurFinale = couleur * dot;
}
sinon
{
couleurFinale = noir;
}

Obtenir les vecteurs unitaires est très important.

Le mot de la fin
Voilà! Tout est dit! Je trouve ce sujet tellement passionnant que j'en suis même arrivé à en faire un tutoriel...
Je ne sais pas s'il est très clair, alors commentez-moi tout ca si vous voulez qu'il s'améliore! (le tutoriel hein)

Si j'en ai éventuellement le courage, je rajouterais peut-être quelques probables images pour illustrer le tutoriel. (en gros comptez pas dessus)
Ce qui est certain par contre, c'est qu'il y aura des images du jeu que je fais avec ce petit moteur! Et p't'êt' même que je mettrais les sources! Mais pour ces dernières, ce ne sera pas avant Janvier, car à Teesside ils sanctionnent violemment le plagiat, et moua je veut une bonne note. Rassurez vous tout de suite! Il ne m'ont jamais demandé de faire un moteur 3D, c'est juste mon esprit tordu qui m'a poussé à le faire, donc si vous envisagez de faire vos études là bas, que cela ne vous freine pas :P (et foncez même, elle est géniale cette école)

Shader showcase

2009-11-06T20:47:00.002+01:00

Le boulot devient de plus intéressant en 3D Graphic Shading!
Voilà ce que je suis capable de faire après un peu plus d'un mois :

Teesside

2009-10-09T19:09:00.004+02:00

Voilà, je viens de commencer mes études à Teesside. Titre du "degree" : "BSc Computer Games Programming".

Voilà mes cours :
- Algorithmic and Data Structures
- Game Software Development
- 3D Graphics Programming
- 3D Graphics Shaders
- Animation and Simulation Programmation

Que du bon qui s'annonce! Ca me permettra de remplir ce blog de choses intéressante :)

Easy Animation Editor

2009-08-26T20:34:00.000+02:00

lien sourceforge

Depuis le début des vacances d'été, j'ai une grosse envie de faire un jeu vidéo en C++. Mais je suis une grosse merdouille en graphismes. A chaque fois je me dis "tiens si je fesait ca ..." puis "hey! ca serait marrant de faire ca". Mais à chaque fois, le problème est le suivant : je n'ai pas de graphismes pour ces jeux. Alors je me dit que je pourrais juste faire des cubes. Mais ca me démotive énormément.Aprendre à utiliser Blender? Déjà essayé, déjà tout oublié, pas assez intuitif pour moi, une dizaine de fonctions réunies dans 10*10 pixels ... De plus, il faudrait créer un importeur ou exporteur de données qui conviendrait à mon jeu, et j'ai la flemme d'examiner leur structure de données (bon ya assimp que j'ai pu maîtriser dans mon stage mais bon).

Alors j'ai voulu me débloquer tout seul en me créant un éditeur pour graphismes en 3D, que j'ai baptisé : Easy Animation Editor.
Le principe, c'est qu'il soit dédié à l'animation de modèles en 3D uniquement. Avec une interface épurée et intuitive.
Pour l'instant, il n'est pas exploitable tel quel, mais ca va bientôt venir! Ce qui est sûr c'est qu'on peut déjà le tester et avoir les sources. Pour cela, il faut utiliser le repositery svn de sourceforge (lien ci-dessus).

Il a une particularité : l'interface graphique (ou GUI) a été totalement programmée de A à Z avec le gestionnaire d'évennements SDL. L'affichage est en OpenGL (je kiffe la combinaison SDL-OpenGL et je ne pense jamais la quitter).
Pourquoi cette particularité? J'ai d'abord pensé utiliser java (que je maîtrise pas mal également) pour sa facilité à créer une interface graphique. Mais j'avait besoin de la 3D. Sauf qu'elle n'est pas dans les package de base de java! Moi j'aime bien développer en java en ligne de commandes ("javac *.java" puis "java nomprogramme" c'est tout ce qu'il y a à connaître). Mais c'est ultra compliqué d'utiliser un package externe de cette façon, et j'ai d'ailleurs toujours pas réussi. J'ai fait l'effort d'utiliser un IDE pour java. Donc Eclipse. Mais en fait c'est juste tout joli joli avec de belles fonctionnalités, mais dur à comprendre et à faire marcher (comme Vista en fait).
Ensuite j'ai pensé utiliser Qt. C'est plutot pas mal, mais j'avait la flemme de me documenter et de découvrir un nouveau logiciel. Alors j'ai pas beaucoup accroché. Il y a des chances que je m'y remette certainement.
Enfin, ultime raison, j'adore réinventer la roue. Ca me fait progresser dans mes raisonnements et ma programmation.

Un petit screen pour vous faire baver ( j'espère :S )

Ma "traversée du désert"

2009-08-26T19:07:00.000+02:00

Voilà les raisons pour lesquelles j'ai semblé ne pas avoir l'air actif depuis quelques années dans le monde du développement amateur. A la base je voulais expliquer pourquoi j'ai commencé le développement de Easy Animation Editor, mais c'est tellement long que j'en ai fait un billet à part. Ca prend la forme d'une sorte d'autobiographie tellement j'ai des choses à dire, et c'est pour ca que j'ai mis ce titre xD

Si je programme c'est par passion pour les jeux vidéos. J'ai déjà créé quelques jeux (qu'on peut voir sur http://jackamikaz.free.fr/) avec Game Maker. J'ai adoré ce logiciel, je l'ai tourné dans tout les sens pour en extraire chacune de ses fonctionnalités. Il vint un temps où mes ambitions grandissaient de plus en plus, de faire des projets de plus en plus faramineux. C'est là que je me suis rendu compte de plusieurs problèmes :

Je suis une grosse merde en graphismes (cf TCA sur mon site). J'ai un projet que je trimbale dans la tête depuis plusieurs années. J'ai voulu faire quelque chose d'agréable à jouer, avec un gameplay qui me semblerait totalement original. Mon but est là : le gameplay. Mais c'est une idée de jeu de combat. Le personnage a donc beaucoup de mouvements, ce qui implique beaucoup de sprites, étant chacun visuellement compréhensibles. Alors j'ai réfléchi à quelque chose de simpliste vu mon niveau : un personnage tout rond sans bras ni jambes (à la Rayman). Je me suis vite aperçu que ce n'était pas du tout suffisant pour différencier les mouvements du personnage. Alors je me suis tourné vers la modification de sprites. J'ai pris des sprites de Megaman X, et j'ai transformé le robot en une sorte de ninja tout noir, en affinant les jambes et en ajoutant des cheveux. Mais (je suis une grosse merde en graphismes) j'utilisais paint. Cela m'a pris un temps inconsidérable, juste pour faire des actions de mouvements et de sauts. Je me suis mis à programmer un moteur en me servant de ces graphisme. J'étais assez satisfait, mais je devais continuer à perdre mon temps sur des graphismes plus que moyens. De plus, ayant des idées de grandeur, je pensait faire ce jeu online avec possibilité de customization de son personnage. Autant dire qu'avec des sprites de cette qualité, c'était peine perdue.

Alors j'ai décidé de faire quelque chose de plus "vectoriel". En restant en 2D, j'ai programmé un éditeur de personnage squeletique constitués de plusieurs points qui sont les articulations. En déplacant les points, cela formait plusieurs positions, qui donnait des animations. Ensuite, entre chaque points, j'affichait un membre : une jambe, un bras, la tête ... Ca donnait quelque chose d'un peu carré, mais l'image était unique et les animations faciles à réaliser. Ca m'a fait un gain de temps considérable dans l'édition des graphismes. J'étais sur la bonne voie.

Seulement, dans la foulée, Game Maker avait sortit la possibilité d'utiliser la 3D. Je me suis dit que j'allait faire un Gameplay 2D, avec le personnage en 2D, tout en gardant des décors en 3D, c'était pas le plus joli, mais pour moi c'était un résultat extraordinaire compte tenu de mes capacités à faire des graphismes en 2D. Mais c'est là que tout se complique. Pour avoir ce résultat, je me retrouve dans les méandres de Game Maker et je bidouille énormément pour obtenir mes résultat. Du coup mon code est pas franchement clair et c'est dur de s'y retrouver. En plus, quand je fais tester le jeu à d'autres gens, des problèmes de compatibilité apparaissent. Rien de plus décourageant, sachant que ce logiciel est sensé marcher de façon égale sur toutes les machines. Alors j'ai recherché à taton des subtilités d'une machine à l'autre sans avoir une seule idée d'où cela peut venir. De plus quand l'autre machine est celle d'un correspondant internet qui n'a pas la version enregistrée de Game Maker (qui ne peut donc pas compiler le projet) ca fait que je dois renvoyer le projet à chaque fois ... Au bout de deux essais c'est l'abandon et l'espoir que ce problème ne soit que particulier.

Il a aussi le fait que l'animation des personnages, bien que beaucoup plus rapide, réduisait énormément l'intérêt de Game Maker, qui est de concentrer le développement d'un jeu vidéo en un seul logiciel, avec sprites et niveaux intégres etc; parce que mon système d'animation utilisait des fichiers textes externes. Game Maker permet l'utilisation de tels fichiers, mais n'est totalement pas adapté pour. Tout doit se faire par code, et le code c'est deux endroits possible seulement : les objets ou les scripts. Les animations étant spécifiques aux personnages, et n'ayant pas encore totalement l'intérêt des scripts à l'époque, j'ai choisi de le metre dans les objets. La lisiblité était donc beaucoup diminuée, à nouveau. Suite à tout ces problèmes, j'ai fini par abandonner ce jeu ...

La raison ultime qui me fit décrocher de Game Maker est le C++ !
En effet, j'étais en train de le découvrir et de l'aprendre par moi-même, et j'avais un autre projet original en tête sur Game Maker : Bactérie (cf mon site à nouveau). Dans la description, j'explique que j'ai abandonné ce jeu à cause d'un bug de Game Maker. En réalité j'ai dit ca pour faire simple, ce n'est pas vraiment un bug, mais un problème de performances. Au bout d'un certain de jeu, il y a plus d'une centaine de bactéries sur le terrain, et toutes doivent éviter d'avoir une colision avec une autre. Cela fait donc 100 x 100 = 1000 colisions à gérer à raison de 30 fois par secondes. Le tout en GML qui est un langage script interprété à partir de fichiers, donc non compilé. Le résultat est là : ca rame. Et C++, est plus proche du langage machine, donc plus performant. Ceci me décida à me concentrer davantage sur ce langage, entrainant un abandon progressif de Game Maker.

Me voilà donc à utiliser C++. Mais forcément, c'est beaucoup moins intuitif que Game Maker, et cela demande une réflexion plus intense pour la création de jeux. Au fur et à mesure que je progressais dans ce langage, je me suis rendu compte de plus en plus de la complexité de création d'un jeu. Mes idées de projet sont les mêmes, mais à chaque fois je me dis que je ne suis pas encore prêt. Deux ou trois fois, j'essaie quand même. Et bien croyez moi, c'est ce qu'il faut faire! Essayer! De cette façon j'ai entamé deux gros projets personnels. Le premier c'est Bactérie 2, avec un gameplay mieux pensé. Mais c'est la première chose sur laquelle je me suis lancé, et je n'était pas encore tout à fait prêt pour le réussir. Ca a donné quelque chose de peu exploitable, mais j'ai appris plus en quelques jours seul là dessus qu'en deux ans d'IUT informatique (je savais tout avant tout le monde là bas d'ailleurs, j'ai même tendance à m'en vanter et j'ai certainement du vexer beaucoup de gens). Le deuxième gros projet, c'était il y a 5 mois, lors de mon stage en Nouvelle Zélande (là huhuh =D ). Evidemment le stage lui même m'a beaucoup appris, mais j'étais arrivé tout seul là bas. En bon geek, je me suis peu socialisé, et j'ai passé beaucoup de mon temps libre à tenter la création d'un moteur 3D. Le résultat, une maîtrise accrue du C++, et un moteur ... plus un moteur de jeu tout cour que de 3D.

Avec cette expérience, maintenant je me sens prêt pour me remettre à des projets de jeux. Seul blocage, comme je l'ai expliqué : les graphismes. Ce qui nous amène à la note suivante : Easy Animation Editor.

Heure des messages

2009-08-26T19:03:00.001+02:00

Comme je viens de créer le blog, je suis en train d'y mettre deux trois touches personnelles de mise en page etc.

Mais je me rend compte d'un problème, l'heure du message est totalement incorrecte! Pour celui ci par exemple, cela marque 10:03 alors qu'il est 19:03!

Pourtant dans mon profil, je dis bien que je suis en France, et je ne trouve pas non plus d'option pour définir le fuseau horaire.

Si quelqu'un a une explication, il peut laisser un commentaire. :)

Mise à jour : ayé trouvé, fuseau horaire dans Paramètres puis Mise en forme.

Présentation du blog

2009-08-26T19:01:00.002+02:00

Bienvenue sur mon nouveau blog!

Celui-ci n'a rien d'exceptionnel, il servira avant tout à moi-même : il me donne une motivation de plus pour mes projets de programmation. Je m'en servirais donc pour montrer, partager, et commenter mes créations.

Bonne navigation!