Le petit journal du pr0n

En lisant cette news, j'en viens à me dire que la PS3 semble inférieure à la XBOX360 parce que les studios de développement veulent absolument faire du multi-plateforme, et donc niveler leur core par le bas.

C'est ce qui semble ressortir de l'interview de John Carmack: « Oui OK, OK, la PS3 pourrait powner, mais bon, c'est tellement dur de comprendre toutes les specificités de la plateforme CELL que franchement... on a autre chose à faire ... ».

Cette partie semble me donner raison:

« Mais surtout, je cite, "(John Carmack) il est beaucoup, beaucoup plus facile de faire fonctionner quelque [chose] correctement sur X360[*1] que sur PS3". C'est pourquoi, si en théorie les CPU de la PS3 sont plus puissants que ceux de la X360, en pratique il est impossible d'en tirer partie. Carmack est catégorique : du point de vue d'un développeur, la X360 est largement supérieure à la PS3. »

En tant que dev, je le décrypte ce paragraphe comme-ci: « Il est plus facile et rapide de développer un cube qui tourne en faisant D3DMatrixRotationYawPitchRollFlanBlahTourneSurtoiMeme() et d'avoir un FPS de 12 que de rajouter 10 lignes de plus sous OpenGL et qui tourne à 100 FPS... »

Il faut avouer que Sony fait à chaque fois un pari audacieux: celui d'avoir probablement une architecture complexe mais qui possède une grosse capacité cachée (dans la limite du raisonnable) si on prend le temps de faire un peu de recherche (et en proposant une API très dur pour les développeurs).

Alors que Microsoft, avec son DirectX/Direct3D moisi (je sais, je suis pas crédible), offre juste dans la balance une solution multi-plateforme opérationnelle (dans le sens: où y'a le plus de consommateur). Même si OpenGL est multi-plateforme, on le retrouve que dans ... la Wii, la DS, la PSP, la PS3 ... ah ouais ... ca fait du monde quand même.

Mais bon, face à un Microsoft qui pose ses 30kg de barbaque monté sur burnes sur la table des négociations (c'est à dire tout l'univers PC), la plupart des éditeurs disent "alleliuah à Direct3D". Une véritable connerie qui, si tous les constructeurs se mettaient à D3D, les enchaineraient à long terme.

Ca me ferait rire si un jour Nintendo, Sony, Microsoft et Sega se mettaient autour d'une table pour faire une console commune (ouais, et on utilise OpenGL, faut pas déconner)

Note1: John a oublié rapidement que pour son Quake 1 (cela nous rajeunit pas), il avait tester OpenGL versus Direct3D ... et trouvait plus clean l'API OpenGL ... bon, tout progresse, même l'API Direct3D, mais va falloir qu'il arrête son délire sur s'il veut développer sur l'iPhone.

LÖVE is an open-source 2D game engine which uses the versatile Lua scripting language to create dynamic gaming experiences. It relies on OpenGL graphics and the SDL interface library to allow for cross-platform implementation and is an all-encompassing gaming environment for the development and enjoyment of 2D games.

Hideo Kojima avoue sur GameSpot:

Les équipes occidentales ont désormais de l’avance sur les développeurs japonais. Plus précisément : « Il fut un temps où l'on disait que le Japon modelait l'industrie du jeu vidéo, mais c'est tout simplement en train de devenir de l'histoire ancienne. C'est triste, mais c'est la vérité. »
Le sieur Shigeru Miyamoto avait également tenu de tels propos récemment, auprès du magazine Wired.

Si c'est Hideo qui le dit ...

Source: GameSpot (UK), InpactVirtuel (FR)

« There have been rumors since last year that Valve may be serious about porting Source games to Linux after Valve Software began seeking a senior software engineer with the responsibility of porting Windows-based games to the Linux platform. Valve Software has yet to officially announce Linux clients for any of its software, but at Phoronix we have received information confirming that Valve is indeed porting its very popular Source engine to the Linux platform. »

Tout est dans le titre ... Les studios de Georges Lucas travaillent actuellement sur les 3 premiers épisodes des années 80 afin de les convertir en 3D-Relief.
Selon les plannings des équipes, le premier volet devrait sortir courant 2011-2012 dans tous les cinémas numériques de la planète (quoique .. avec un peu de chance ils vont en faire en 35mm...)

A vous les studios !

Nos chers amis de Valves Software (Half-Life) publient des choses intéressantes dans leurs grottes du Nord.

Vu sur OpenGL.org: « Using OpenGL and Ruby, you can now view real-time data and statistics from any logfile on any server with SSH, in an intuitive and entertaining way. Some features include Real-Time, Multiple logfiles on multiple servers, Configurable layout, Multiple logfile parsers, (Apache Combined, Rails, IIS, Postfix/spamd/clamd, Nginx, Squid, PostgreSQL, PureFTPD, MySQL, TShark, qmail/vmpop3d), and Custom events »

Un visualisateur de log en OpenGL ... y'a des fous partout ! : Fudgie

Note: sur le site, vous retrouverez une vidéo de la bête... c'est marrant comme tout.

Johnny Chung Lee est un petit malin... non seulement de ressembler à Hiro Nakamura, c'est un mec qui a eu une #%$&* de bonne idée !
Plus que des mots, je vous laisse avec la vidéo de son projet (Si vous êtes pressé, commencez un peu avant 2:30'')

Ca me donne des idées pour des projets, tiens ...

• Procrastineering
  
• CMU Edu: Johnny Zone
  

UPDATE: Franck, à ton avis, c'est pas une grosse évolution dans le monde du relief ?

Alors, dans le monde, y'a des fous: Et Vlad en fait partie.


C'est bien simple: Notre ami Vlad a codé un plugin Firefox pour l'implémentation de l'API OpenGL dans notre navigateur rouquin.
Le seul petit truc chiant, c'est qu'il faut Firefox 3.0 et supérieur, mais bon, c'est pas non plus extrême, d'ici 6 mois tout le monde y sera.

L'antre de Vlad: pr0n, OpenGL, Canvas3D, vazy-francky-c'est-bon et autres convivialités.

J'adore ce bout de code :

   <script id="shader-vs" type="x-shader/x-vertex">
      attribute vec4 vertexPos;
      varying vec2 Z0;
      
      void main(void) {
        gl_Position = vertexPos;
        Z0 = vertexPos.xy;
      }
   </script>

Vu pendant une compilation de notre ami Francky :

[colorus@color ezOpenGL]$ make
g++ -Wall -g -D GLX_GLXEXT_PROTOTYPES -D GL_GLEXT_PROTOTYPES -D DEBUG=1 -c src/glshaders.cpp -o objs/glshaders.o -I include
src/glshaders.cpp:8: erreur: « CShaderFactory » n'est pas un type patron
src/glshaders.cpp:25: erreur: « CShaderFactory » n'est pas un patron
src/glshaders.cpp:25: embrouillé par les erreurs précédentes, abandon
make: * [objs/glshaders.o] Erreur 1

Moi aussi, après quelques verres, je suis un peu embrouillé et je m'abandonne

Avec le temps qu'on a (ma bonne jocelyne), ca m'a donné envie de coder deux ou trois trucs.

Dans ma besace du jour, je vous propose libGLX3D: Une librairie pour l'utilisation des fichiers X3D dans un environnement 3D.

Cette librairie s'occupera - pour l'instant - des "Transforms Tags" (Objet) et des "Viewpoints Tags" (Cameras).
Je suis partie sur la base qu'avec trois lignes, vous êtes capable de l'utiliser dans un programme OpenGL sans difficultés.

Pour faire simple, munissez-vous d'un fichier x3d valide.
Vous en trouverez soit dans le tarball, soit en utilisant Blender et le plugin x3d.
(Notez cependant un léger bug lorsque vous créez une scène from-scratch: Après avoir sauvegardé le fichier, Editez-le avec un simple éditeur et supprimez <memory> dans le tag "Head")

Pour Initialiser :

glX3D *x3d;
x3d = new glX3D(string("my.x3d"));

Cela permettra de démarrer le parsing du fichier "my.x3d";
Puis, utilisez l'appel "load()" :

x3d->load();

Cela chargera en mémoire les informations sur les objets et les caméras.
À noter que "load()" renvoie le nombre d'objet chargé :

int nbObj = x3d->load();

Vous pouvez obtenir ses mêmes informations en utilisant les variables objects et cameras

x3d->objects.size();
x3d->cameras.size();

Sitôt le chargement effectué, vous pouvez utiliser la fonction "display()" qui se chargera de générer et d'afficher les primitives :

x3d->display();

Bien entendu, cette fonction est à appeler dans le Renderer Core.

Avec une implémentation OpenGL, cela donnerait ceci :

glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
camera(); // there is no gl function

// Light & Co.
GLfloat position[] = { 0, 0, 0.8, 1 };
glLightfv(GL_LIGHT0, GL_POSITION, position);
        
glPushMatrix();
       glEnable(GL_LIGHT0);
             x3d->display();
       glDisable(GL_LIGHT0);
glPopMatrix();
        
glutSwapBuffers();

C'est aussi simple que cela.


Bien entendu, vous pouvez utiliser certaines fonctions internes :

int  getTransforms();
void createTransforms();
void createTransform(int objectid);

getTransforms charge et définie les variables internes 'objects' et 'objectsRef'. Notez que "objects" sont les coordonnés pour chaque vertex et "objectsRef" est l'index de ces mêmes coordonnés (afin de retrouver le type de polygone)

CreateTransform utilise les variables objects et ObjectsRef et appelle les différentes fonctions OpenGL pour générer le rendu. CreateTransforms appelle - pour chaque object - la fonction createTransform avec l'ID de chaque objet. (sous-entendu: vous pouvez parfaitement n'afficher que certains objets)
getViewpoints est le pendant de getTransforms, mais pour les Viewpoints (Cameras)

---

Download: libglx3d-0.5.tar.bz2

Dans le tarball se trouve une implémentation, appelée 3dview.
Son utilisation est simple :

./3dview <x3dfile>

Utilisez les exemples stockés dans le répertoire samples/.
Après, cela s'utilise grâce à la souris: Clic droit et déplacement de la souris pour faire des rotations, clic du milieu pour faire un zoom-in&zoom-out

---

Note: Cette librairie est a titre expérimentale, si vous voulez une librairie plus avancée, utilisez X3DLib

Merci Papa, Merci Maamaaaannn... ... *kh0f*
Pardon, je m'égare ...

En allant voir Mère-Grand, j'ai rencontré Uncle Ben's qui m'a proposé du riz complet qui-sent-bon-l'inde-du-bas-vers-les-terres-sans-OGM-et-sans-pesticides.
En discutant un peu avec lui, il m'a refilé un manuscrit, juste avant de se cacher derrière des buissons avec Alice (oui, je sais, je suis sale...)

Je vous donne l'index du manuscrit quand même :

Conception 3D :

• Comprendre la 3D : le filtrage des textures
• Comprendre la 3D : Truform et High Order Surfaces
• Comprendre la 3D : Bump Mapping et compagnie
• DirectX : Techniques de compression des textures
• Comprendre la 3D : les effets visuels (1ère partie)
• Trousse de secours pour comprendre les Pixels shaders
• Parallax bump mapping
• Les différentes formes d'aliasing et leurs solutions
• Longueur des pipelines et performance
• Langage C : l'optimisation de code
• Langage C++ : l'optimisation de code
• D-loop : nouvelle technique d'optimisation des boucles
• Les calculs de physique dans les jeux : le temps du choix est a rrivé
• Les pénalités de branchement et prédiction matérielle

Mathématiques :

• Quaternions et développement 3D (généralités)
• A quoi servent les matrices dans un moteur 3D ?
• Half-Life 2 et les bases du calcul différentiel
• Théorie des nombres : la fonction de Möbius
• Théorie des nombres : la fonction de Legendre
• Les chaînes de Markov
• La zoologie des nombres
• Les bases de la trigonométrie

Physiques :

• Zoologie des particules élémentaires
• Matière, molécules et atomes
• Accélération des sondes spatiales : l'effet de fronde
• Le principe d'Archimède

Et on ne se finit pas sur son voisin !

Raah... ces sales gosses ...