MMMMMMMMMmmmmmmmmmmmmMMHhhhhhhhhh and maybe more

La dernière minute enchaine sur des combos. Magnifique.

Un article plein de jurisprudence sur les injures au boulot et leurs conséquences.
C’est aussi drôle à lire que ca a du être dur pour les salariés (tribunal, licenciement,tout ca)
Je garde au chaud ces reflexions:

Un employé d’une usine de peinture industrielle a néanmoins obtenu gain de cause après avoir lancé : « Vous me faites chier et j’en ai marre de vos méthodes de kapo et de SS. »Des injures particulièrement blessantes pour le patron, mais l’employé ignorait « que la plus grande partie de la famille de monsieur A. avait péri dans les camps de concentration nazis » [...]

[...] après avoir déclaré à son chef : « Je ne suis pas là pour faire pute ! »
En effet, à en croire la jurisprudence, la gravité d’une injure varie selon les secteurs professionnels. Concernant les propos de ce chauffeur, les juges ont estimé « que leur vulgarité n’excédait pas les limites de ce qui est admissible dans l’univers professionnel des chauffeurs routiers ».

Je ne suis pas fan de WebSeries, je trouve ca en général mal fait et pas très drole.
Tout d’inverse de DRH. Bien rythmé, monté et tout.
Le pitch : “Nicolas Bertier, Directeur des Ressources Humaines, s’est fait repérer par une multinationale «Global Incorporation». Les dirigeants de ce grand groupe le prennent au piège : soit ils le dénoncent et il va en prison suite à toutes les plaintes pour harcèlement dirigées envers lui, les licenciements abusifs auxquels il a procédé et ses faux diplômes/CV’s, soit il intègre la «Global Inc.» pour licencier 1700 personnes.”

C’est du tout bon. Voici le 1er épisode.

Et le lien vers la chaine DailyMotion.

Le lien vers le téléchargement est plus bas.

Et oui, déjà V3.
Petite retrospective.

Physic V1 (de juillet 2007 à janvier 2009)

Physique entièrement codée par mes soins. Modèles de collisions simplifiés (sphere pour les vaisseaux et ‘couloir’ pour la piste).

Pros:
- tu obtiens ce que tu veux.
- Pas d’explosion de la physique: tu maitrise tout
- Rapide à l’execution

Cons:
- Des différences de comportement suivant la vitesse d’execution
- Rigidité globale du vaisseau
- Trop cadré (pas de sortie de piste)
- Imprécision dans les collisions (vaisseau/vaisseau et vaisseau mur)

Physic V2 (janvier 2009 à septembre 2009)
Les Cons de la V1 m’ont donnée l’envie de rajouter un vrai moteur physique pour améliorer les collisions vaisseaux/vaisseaux et vaisseaux/piste. J’ai opté pour Bullet Physics et celui ci ne me sert qu’a déterminer les collisions. C’est moi qui fait la réponse physique (compensation, forces,…). J’ai rajouté quelques raycast pour savoir si je quitte la piste.

Pros:
- De vrai collisions vaisseaux/vaisseaux
- Des collisions approximatives avec les murs qui s’affinent (- de temps CPU)

Cons:
- Réponses physics inapropriées(cogner contre un mur expulse parfois loin)
- Physique toujours rigide
- Parfois des problèmes suivant la vitesse de la machine

Impossible d’avoir un gameplay digne de ce nom avec autant de soucis. Dure de patcher continuellement. La seule solution est de passer à la V3.

Physic V3 (septembre 2009 à jourd’hui)
Tout passe par le moteur physique: détection de collision, réponse, intégration. J’applique des forces et des torques. Dans la pratique, je tweak un peu plus bas niveau en modifiant la matrice du vaisseau car Bullet autorise certaines choses que je ne veux pas avoir.

Pros:
- C’est fluide, ca bave pas, ca explose moins
- Les valeurs à tweaker par vaisseau sont plus naturelles (valeur de forces à appliquer, masse,…)

Cons:
- Faire un controleur qui transforme un rigid body en vaisseau futuriste
- Detecter et corriger certains cas limites

C’est ce controleur physique qui me fait peur depuis un jeu PS2. J’avais fait du forcing pour qu’on code nous même la physique. Le chef avait opté pour ODE. S’en sont suivies de longues semaines a pisser du contrôleur pour faire ressembler notre monde 3D avec physique à un jeu.

a,z,e,q,s,d pour les deplacement/freins. TAB pour changement de vue. ESC pour le menu. Configuration de la résolution et touches dans l’écran de config accessible depuis le menu. ALT-TAB, touche Windows,…et globalement le changement de fenêtre est super mal géré pour l’instant.

Ce programme est fourni totalement sans garantie. L’auteur ne peut être tenu responsable des dommages éventuels causés par ce logiciel.
Click ici pour Test Physic V0.1

en mode photo, tu peux prendre des screenshots en appuyant sur ‘o’. Les images sont sauvées dans le répertoire image du compte (mes documents/mes images)

Il y a 2 maps (hardcodées). On peut en changer dans le menu, en cliquant la combobox
en mode photo, tu peux prendre des screenshots en appuyant sur ‘o’. Les images sont sauvées dans le repertoire image de ton compte (mes documents->mes images)

l’installeur met a jour les DLL runtime pour visual 2008 ainsi que DirectX.

Les plus téméraires pourront tweaker la physique du vaisseau en modifiant le fichier XML situé dans Prototype/Teams/Wipeout/Feisar

Il n’y a pas de lighting, et globalement, peu de features montrés ces derniers mois. C’est déjà la misère pour sortir une telle version light. Alors, essayer de releaser une version complète aurait été un suicide. Rien que pour ca, il y a tellement de petits trucs a régler…

Critiquez! pourvu que ce soit constructif et réfléchi. Si vous avez des soucis (écran noir et rien qui se passe, crash,…comportement chelou), mettez votre config (carte graphique, CPU, OS, mémoire,…) en commentaire.

Trip de ce midi: ‘faire’ Outrun dans un shader pour que ca ressemble à ca:

Globalement, afficher et déformer une route avec une voiture dessus.
En contraintes: le faire avec seulement 2 triangles dans FX composer 1.8, et en moins d’une heure.
J’obtiens ca:

Et j’ai procédé ainsi:
Je prépare mes textures (merci google image):

Et

Préparation du bouzin: La projection inverse, les textures, samplers, 3 sliders pour les paramètres de route et une valeur de temps:

float4x4 projInverse : ProjectionInverse;

float time : Time;


Les clampings/wrap des textures ne sont pas faits au hasard.
Dans FXComposer, on a 1 quad (2 triangles) dont les UV vont de 0 à 1. Le vertex shader transforme ca en fullscreen quad. On laisse les UV inchangés.


vertexOutput VS_TransformAndTexture(vertexInput IN)
{
vertexOutput OUT = (vertexOutput)0;
OUT.hPosition = mul( float4(IN.position.xyz , 1.0) , worldViewProj);
OUT.texCoordDiffuse = IN.texCoordDiffuse;
OUT.hPosition = float4((IN.texCoordDiffuse.xy-0.5)*2, 0.5f, 1.f);

return OUT;
}


C’est dans le pixel shader que tout est fait.
En gros, on multiplie les coordonnés écrans (coordonnées de texture XY, et le Y en positionZ) par la matrice inverse de la projection.

float2 entryval = IN.texCoordDiffuse.xy;
float4 inverted = mul(float4(entryval-0.5 + virage, IN.texCoordDiffuse.y, 1.0), projInverse);

Le -0.5 est la pour centrer la route sur le milieu de l’écran.

On simule la différence de hauteur en modulant le w. J’ai fait ca comme un porc, histoire que ca soit pas tout plat. L’idéal serait de piocher dans une autre texture.

float theight = sin((IN.texCoordDiffuse.y+bosse)*5)*0.2;
inverted.w += theight;


Avec tout ca, reste plus qu’a calculer les U et V de la coordonnée de texture:

float2 tex = (inverted.xy)/inverted.w + 0.5 + float2(rightleft-0.5,
fmod(time,1)) ;


Un petit coup de fog, histoire de:

float4 fgocolor = float4(1,0.8,0.8,1);

float4 diffuseTexture = tex2D( TextureSampler, tex );
float4 route = diffuseTexture * lerp(1, fgocolor, ((inverted.z*0.2)/inverted.w));// * diffuseTexture + IN.specCol;


Je passe m’explication du calcul du virage qui est bien foireuse.
On va rajouter le sprite de la voiture. Attention, valeur empirique total pour le placement/scale de la voiture à l’écran:

float4 salope = tex2D(SalopeSampler, (float2(entryval.x, 1-entryval.y)-0.5)*float2(5,5) + 0.5 + float2(0,-1.4));

On mixe le sprite avec la route et on passe au pixel suivant:

return lerp(route, salope, salope.w);

Done.

Le résultat dans FXComposer:

Et en close-ups:

Conclusion, il y a des distorsions et les virages ne sont pas top. Mais pour un proof of concept, ca me suffit.

… espoir

Quoi de beau depuis le dernier billet?
Une iso-fonctionnalité (je cotoie trop de commerciaux de SSII) entre win32 et Minux. Les shaders passent de l’un à l’autre (même shaders entre DX9 & OGL). J’en ai donc profité pour mettre un joli cubemap. Trouvé sur l’excellent site de Humus ( http://humus.name ) et modifié sous toshop.
La physique s’est bien améliorée aussi. Avec (enfin) le support du per-triangle pour les collisions. On peut toucher aile à aile les autres vaisseaux. La réponse mérite quelques itérations supplémentaires.
A ce titre, ca m’a donné une idée:
Il y a quelques mois, des jeunes (cons) s’amusaient a faire une course de voiture dans un village. A 50/60Km, 2 voitures cote à cote; les chauffeurs essayant de se faire toucher les retroviseurs. Ils se sont plantés et un des conducteurs est mort. Bref. Le concept du mode de jeu. 2 équipes. Le dernier dans l’ordre de départ de chaque équipe a sur son aile un paquet. Celui qui a le paquet doit le transmettre (comme au relai 4×100m) au suivant en faisant touche-touche entre les 2 ailes. Sauf qu’a chaque passage de relai, la vitesse minimale pour l’echange augmente. En 3/4minutes, l’equipe qui a fait le plus d’échange, gagne.
A part ca, j’ai ré-intégré les aerofreins, l’ecran de chargement, la serialisation des paramètres physique et quelques autres petites choses.
En terme de performances, je ne regrette pas d’avoir repris ‘de zero’. en win32, sur un dual core 1.8Ghz (charette) avec une GF9800GT, je tourne a 2000FPS en 1280×720. Il y a de la marge et quelques petits points encore pour améliorer les performances. Mon système de serialisation/RTTI/mem tracker ne m’indique aucun memory leak. Je tiens le bon bout.
Quelq’un a un vieux mac a me preter/vendre?

News piquée sur Jeuxvideo.com.
“il s’est donné la mission de “retirer tout le fun dans le processus de création des jeux vidéo” afin de façonner une culture d’entreprise qui “récompense le profit et rien que le profit”. Pour arriver à ses fins, Bobby Kotick avoue ouvertement cultiver “le scepticisme, le pessimisme et la peur” face à la chute de l’économie, avant de conclure “Nous sommes très bons pour garder l’attention des gens centrée sur la grande dépression”.”

Ca choque quand ca touche le Jeu Vidéo, industrie montée par des geeks avides de fun. Mais comment on peut devenir aussi inhumanisé? Je ne doute pas que des grands groupes utilisent déjà la peur comme moyen de pression voire même d’organisation. C’est pas possible que ce système dure. Je me demande si je tire pas à gauche mais tout de même. Un tel cynisme.

2ème version de la physique. Un poil meilleur (j’espère). En tout ca, c’est rapide. Je tourne a 1100FPS en 1280×720 sur une 8600M et C2D de portable.
La physique utilise Bullet Physics pour les collisions et raycasts. La dynamique du vaisseau est toujours faite par moi.
Demain j’attaque une génération procédurale de circuit. Ca me travaille depuis les travaux de Darkstryder.

Version HD sur Youtube en cliquant sur la vidéo (Gagagou!).

ps: ceci est mon 300ème article.

On parle beaucoup de FPS, tuer, zombies, etc… faut savoir a quoi ca ressemble en vrai (ou pas).

Comme vous le savez, je refais .the rush (quasiment) from scratch. Alors voici quelques commandements que j’applique pour ne pas foirer mon developpement.

- Le milestone

Avant de pisser la 1ère ligne de code, j’ai fait un doc (fichier texte) contenant une 30aine (pour un 1er lot) de milestone. Chaque milestone est un ensemble de fonctionnalité et une unité de test. En gros, réponde à la question: “qu’est ce que je veux voir?”. Chacun doit être court (2 à 3 jours de developpement), clairement identifié, avec les classes à créer, les librairies à intégrer etc. Et on ne fait pas plus que ce milestone. On ne passe au milestone suivant que si on est 100% satisfait de ce qu’on a fait. A la fin de chacun, on vérifie les résultats de performances et de memory leaks. (cf points suivant). Je n’ai pas fait les milestones pour tout le jeu. J’ai une 20aine de milestone d’avance. Dur de prévoir tout le jeu malgré ce que j’ai déjà fait.

- Augmenter le rendement ligne de code/features

Tim Sweeney disait qu’il préférait 10% de rendement dans le codage que 10% de performances en plus. C’est encore plus vrai dans des projets amateurs. Ca passe par tout le merdier ‘commercial’ des langages à objet. Généricité, encapsulation,…blabla. En gros, utiliser des templates. La STL pour moi plus quelques uns de ma composition. Au début du développement, tu fais une unité de tests avec les trucs classiques (liste de reference, iterer sur un tas d’objets,…) et tu itère quelques fois pour faire la même chose avec le moins de lignes possibles. J’ai un peu partout des std::vector<smart_pointer<ZMeshInstance> >. Quand c’est en membre, tu ne t’en occupes plus. Le destructeur est ton ami et pense toujours à nettoyer derrière lui. utiliser des iterators (++iter plutôt que iter++ pour ne pas faire de copie sur la pile), etc etc. Ce jeu de le faire le ‘mieux’ possible deviendra vite un reflexe au fur et a mesure du developpement.

- Un bon memory leaks est un memory leak absent

Un coup de valgrind de temps en temps(ou 1 autre soft) pour detecter les memory leaks est une bonne habitude. Mieux vaut regler 5 memoryleaks par semaine que 250en fin de prod. En outre, VisualStudio ne vous fera pas chier a dumper dans le output tous les buffers perdus. J’ai un systeme de reporting qui me sort quand je quitte le programme les classes dérivées de ma classe de base que je n’ai pas libérer. Chaque classe de base ayant un nom (nom du fichier ressource qui l’a créé), c’est assez rapide pour nettoyer le programme.

- Garder un oeil sur les performances

Attention à ne pas confondre avec ‘Early optimization is the root of evil’. On ne parle pas d’optimisation ici mais de code sous-performant. Il m’est arrivé de faire un bout de code et quelque temps plus tard de me rendre compte que mon bouzin ramait. Je faisais environ 2000000 de strcmp( comparaison de chaines) parce que mon ancien bout de code ne marchait pas bien avec le nouveau. Avec de tels appels, je m’en suis rendu compte mais parfois, un bout de code mal écris mais qui marche fait qu’a la fin tout le bordel rame. J’ai un systeme de PROFILER_START(xxx) / PROFILER_END(). A la sortie du programme, je dump le nombre d’appels, le temps moyen/min/max. Des que j’ai un truc louche, je me penche dessus. C’est en général assez rapide à corriger puisque je l’ai codé recemment.

- VirtualBox est ton ami

Dans le cadre d’un développement multiplateforme, on a toujours une plateforme préférée (moi c’est Windows). Pour verifier que tout marche bien sous linux, j’utilise VirtualBox (gratuit sur le site de Sun). Il y a l’accélération Hardware pour Linux. Ca marche super bien. Il y a beaucoup de différences entre GCC et le compilo Visual. Avec un peu d’expérience on apprend à coder pour que ca passe sur les 2 compilo. Au début, tu pestes. En plus, ca m’a permis de m’habituer à Linux. Dommage que MacOSX ne se virtualise pas (je suis preneur d’une solution).

- Penser au jeu avant la technologie

Efficacité, efficacité. Faire du code pour le jeu, pas pour toute la technologie. Certains vont dir alors:”pourquoi ne pas utiliser des trucs comme Unity?”. Déjà Unity et autre, on commence à voir les limites à l’utilisation et ensuite, il faut coder ce qui a de la valeur ajoutée. Une GUI par exemple n’apporte pas grand chose au jeu. Un moteur audio non plus. Par contre, coder le moteur 3D pour le jeu permet d’avoir un pipeline mieux adapté, coder plus facilement les effets, etc etc..

- Eliminer les craintes avant l’intégration

Avec la visibilité des milestones, je vois quelques semaines/mois avant le développement des features ou morceaux de code que je ne maitrise pas. Ca peut être l’intégration d’une librairie, une fonction dispo sous Windows qui a un équivalent un peu différent sous Linux, ou une structure de données (template) un peu complexe. Pour tout ca, la solution passe par une unité de test. Un nouveau projet séparé ou non du tronc. Et on code la fonctionnalité. Ca parait con mais ca élimine pas mal de soucis tout en n’ayant pas la lourdeur du jeu derrière. En général, c’est en mode console que je teste ca. En outre, ces ensembles de tests units sont à garder dans un coin. Dans vos projets persos ou professionnels futurs, vous pourriez en avoir besoin.

Vous voyez autre chose?

Depuis hier j’écoute ce morceau:

Lundi, j’arrête de fumer. J’ai les gommes a macher et un minimum de volonté. Wish me good luck comme on dit.

J’ai fait un post dans les forums, je me repète donc: Je suis sur Rennes en semaine. Qui est interressé par se boire 1 bière 1 midi ou 1 soir entre  nofragés de pédicré?

Et je vous invite tous à aller voir ‘District 9′. Un très bon film de SF avec de l’humour, de l’action et un peu de mélo (mais pas trop).