Frédéric Lopez a écrit 759 commentaires

Hum, j'ai oublié quelques petits détails, comme le modèle de ma carte par exemple :)

cat /proc/driver/nvidia/cards/0 :
Model: GeForce FX 5200
IRQ: 16
Video BIOS: 04.34.20.56.00
Card Type: AGP

cat /proc/driver/nvidia/agp/status :
Status: Enabled
Driver: AGPGART
AGP Rate: 8x
Fast Writes: Disabled
SBA: Enabled

grep VideoRAM /var/log/XFree86.0.log :
(--) NVIDIA(0): VideoRAM: 131072 kBytes

En même temps, comme il est dit dans ce journal, le score à glxgears ne veut rien dire, des cartes puissantes peuvent avoir un score inférieur à des cartes beaucoup moins puissantes.

Je pense qu'une meilleure technique serait de comparer le score avec la démo de Quake 3.

Procédure :
- lancer q3demo +set cd_nocd 1 +set s_initsound 0
- taper ~ puis timedemo 1 et valider
- taper demo q3demo1.dm3 et valider

- dans System choisir Fastest
- dans Demos choisir demo1 puis cliquer sur Play
- à la fin, taper ~ et noter le nombre de FPS
- refaire cette procédure encore 2 fois et garder le meilleur nombre de FPS
- répéter avec Fast, Normal et High Quality

Ma configuration :
cat /proc/driver/nvidia/ :
NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-6106 Wed Jun 23 08:14:01 PDT 2004
GCC version: version gcc 3.3.4 (Debian 1:3.3.4-2)
cat /proc/version :
Linux version 2.6.7-1-k7 (dilinger@toaster.hq.voxel.net) (gcc version 3.3.4 (Debian 1:3.3.4-2)) #1 Thu Jul 8 06:45:35 EDT 2004

Mes résultats :
Fastest 236.2
Fast 210.7
Normal 182.7
High Quality 139.6

> J'ajoute que j'ai une MDK 9.2 et que mon noyau est un 2.4 avec les
> pilotes assez anciens (je ne sais plus comment on fait pour en avoir
> la version).

cat /proc/driver/nvidia/version

> Pour ce qui est de la lenteur, tu peux essayer les applis de jgoodies.

Les applis clientes Java fonctionnent peut-être à une vitesse acceptable de nos jours (encore que j'aie quelques doutes), mais le problème de Java c'est qu'il traîne une mauvaise réputation depuis un sacré bout de temps. On est quand même passé en quelques années de PC à 133Mhz/32Mo à des PC à 2Ghz/512Mo et c'est vrai qu'à l'époque, Java c'était inutilisable sur le desktop.

> Mon pb c'est que pour moi il y a un manque sous linux c'est la
> disponibilité d'un langage de haut niveau type Java C# pour écrire
> des applis.

Tu blagues là non ? Ou alors je serais curieux de connaître ta définition d'un "langage de haut niveau"...

> Y 'a t'il parmis vous des devins pour me dire de quoi l'avenir sera
> fait ?

Oui, tu as de la chance, j'en ai justement un sous la main, et il me dit que l'avenir ne sera pas fait d'un unique langage mais d'une multitude, comme c'est le cas actuellement, et que ça n'aura toujours aucun sens de ne maîtriser qu'une seule technologie...

> Mono permet à Microsoft de se rapprocher de Linux et nul ne sait
> ce qu'il peut faire ensuite

Mono n'est que l'implémentation d'un language dont les spécifications ont été définies par Microsoft.

Faut arrêter la parano, c'est pas l'Etoile Noire de l'Empire non plus...

N'importe quoi...

> Far Cry est basée sur le moteur de HL2

Non, Far Cry dispose de son propre moteur (CryEngine) qui n'a rien à voir avec le moteur de Half Life 2 (SourceEngine). Il n'est donc absolument pas basé sur Half Life 2.

> (navrok ou un truc comme ça).

Havok (et pas navrok...) est le moteur physique utilisé dans Half Life 2, mais pas dans Far Cry, celui-ci disposant de son propre moteur physique.

> Donc pas de HL2 sur linux implique pas de Far Cry.

Bon, je viens déjà de montrer pourquoi cette phrase n'a aucun sens, mais en plus comme Far Cry est déjà sorti et Half Life 2 pas encore, ça la rend encore plus idiote...

D'autre part, le moteur Havok est également disponible sous Linux...

Et le papier, c'est les lecteurs ?

À quand le correcteur orthographique intégré dans DLFP ? ;)

Tant qu'on y est, y a eu Battlezone aussi (1980), mais bon, c'était ni texturé ni même en surfaces pleines (fil de fer)...

> La version 4 des navigateurs fait référence aux deux produits les
> plus connus IE et Mozilla (qui même en version 1.6 comme Firefox
> indique Mozilla/5.0 dans la fenêtre à propos).

Oui, enfin ça c'est quand même la notation interne pour les développeurs. C'est comme si on disait d'un logiciel qu'il ne fonctionne que sur Windows > 4.0. Ca va pas parler à grand monde...

> Mais qu'une société ait à payer 1500 € pour utiliser une bibliothèque
> de qualité ça ne me choque pas du tout.

Ca n'a rien de choquant effectivement, mais si la version Windows était disponible sous GNU GPL, ça ne changerait rien à l'affaire.

Si une boîte voulait utiliser QT dans un logiciel propriétaire, elle ne pourrait de toute façon pas utiliser la version GPL et devrait donc payer 1500 €.

Libérer QT sous Windows ne pourrait donc normalement pas leur faire perdre de clients et devrait leur faire gagner des utilisateurs...

> en plus, doom 3 est programmé en C lui ...

Non, en C++ :
http://archive.gamespy.com/e32002/pc/carmack/(...)

Extraits :
"Especially after our move to C++, there is very little code remaining from the Q3 codebase at this point."

"We have not yet decided exactly where we are going to break the source code for mod making, but it is certain that it is going to be a C++ DLL."

http://www-rali.iro.umontreal.ca/Reacc/Reacc.fr.cgi(...)

Résultat sur le premier paragraphe :

Voilà, les RMLLs viennent de se terminer, après l'annonce officiel de leur tenue l'an prochain à Dijon, comme on le suspectait déjà un peu (voir http://lsm2004.abul.org/article84.html(...(...)) pour plus d'informations).
J'en profite pour parler du mode d'élection de la localité des RMLLs qui a été fixé de manière a savoir à la fin des RMLLs de l'année N, la localité des RMLLs de l'année N+1, en partant des candidatures déposées avant le 31 janvier de l'année N.

En tout cas, merci pour ce petit aperçu des RMLLs...

> Et puis à propos de patterns, ne pas oublier les classiques de
> Gamma et al qui restent souvent pertinents dans le cas particulier
> des jeux.

Voir aussi :
http://www.gamasutra.com/patterns/(...)

Malheureusement le forum n'est plus accessible depuis quelques mois, il y avait quelques discussions intéressantes dessus :/

> Pour ogre, faudra le compiler à partir des sources (bonne chance si t'a une NVidia).

Pourquoi bonne chance ? Je l'ai compilé chez moi (Debian/unstable, Geforce FX 5200) et je n'ai eu aucun problème.

Les exemples et l'application de référence fournis avec Ogre sont très utiles pour apprendre à s'en servir. Sinon, voilà d'autres liens sur le sujet que j'avais glanés à l'occasion :

Setting Up an OGRE Project Using the GNU Autotools :
http://temas.obelisk.net/ogre/LinuxSetup.html(...)

The Ogre-engine: how to-list :
http://home.hccnet.nl/w.vdongen/Ogre-How%20to-list.html(...)

Quelques projets de jeux écrits avec Ogre (avec sources) :
http://graphics.tudelft.nl/~mkt4/(...)

Un lien sur le forum à propos de la gestion d'un projet sous Linux :
http://www.ogre3d.org/phpBB2/viewtopic.php?t=4672&highlight=sco(...)

Il y a également pas mal de monde sur IRC et sur le forum en cas de problème.

Bon courage...

Euh, tu es sûr que le paradigme MVC est bien adapté à ton cas ? En général ça s'utilise surtout dans les applis classiques avec interface graphique, car elles sont principalement gérées par événements et le système ne fait rien tant qu'il n'a pas à traiter d'événement.

Dans le cas d'un jeu, en général le fonctionnement n'est pas basé sur une boucle d'attente d'événements, mais sur une boucle qui met à jour en permanence les différents objets. Ca ne me paraît pas trop adapté d'utiliser le MVC dans ce cadre.

Surtout que c'est pas forcément avantageux :

entaîneur -> entraîneuse
professionnel -> professionnelle
coureur -> coureuse

Sa question portait sur l'utilisation du z-buffer en rendu 3d software, pas en rendu 3d hardware. Le z-buffer est très utilisé en rendu hardware parce qu'il est peu coûteux (câblé en hard), mais ce n'est pas le cas en rendu 3d software.

En rendu 3d software, la technique à utiliser dépend du type de données à afficher. Dans le cas des FPS par exemple, le moteur de Quake 1 en mode software reposait sur la technique du BSP (Binary Space Partition) et des portals, car la technique du z-buffer était beaucoup trop lourde. Elle génère en effet de nombreux accès en lecture et écriture dans la mémoire vidéo ce qui était extrêmement lent sur les cartes de l''époque. Le z-buffer n'était utilisé que pour des cas particuliers comme les billboards et les sprites.

L'avantage du BSP est qu'il minimise les recouvrements de poygones et au besoin les divise, il n'y a pratiquement pas d'overdraw donc pas d'accès superflus en écriture sur la carte graphique. Cette technique n'est maintenant quasiment plus utilisée car le z-buffer hard est très rapide et l'utilisation du BSP est assez gourmande en cycles CPU. Les BSP sont néanmoins toujours utilisés dans la détection de collision.

La technique des portals est une technique de plus haut niveau qui permettait de découper une scène en plusieurs zones et de ne retenir que celles susceptibles d'être visibles en fonction de la position de la caméra et des informations de connectivité entre zones. Cette technique n'est utilisée que dans les jeux "indoor" et elle l'est d'ailleurs de moins en moins. A l'heure actuelle, on utilise d'autre technique comme les octrees (pour les environnements extérieurs), le hierarchical occlusion culling, etc.

Il y a aussi un (télé-)film sympa sur la courte histoire de la micro-informatique : "Les pirates de la Silicon Valley". Il était passé sur TPS il y a quelques mois.

C'était avec Noah Wyle (Dr. Carter dans Urgences) dans le rôle de Steve Jobs et Anthony Michael Hall (vu notamment dans "Une créature de rêve") dans le rôle de Bill Gates. C'est un film assez sympa et qui me semble pas mal coller avec la réalité, sans incohérences et assez proche de ce qu'on pouvait lire dans les quelques revues et bouquins de l'époque. D'ailleurs il me semble que Woz avait dit que c'était bien dans l'esprit de ce qui s'était passé à cette époque, à quelques détails près. On y apprend pas mal de choses d'ailleurs.

Bref, à voir...

Y a GollyGee Blocks aussi, pour les enfants de 6 ans et + :

http://www.gollygee.com/(...)

Mais ça tourne que sous Windows et Mac et c'est pas libre. Par contre, c'est pas axé sur la modélisation mais sur la combinaison de primitives 3d pour créer des petites scènes.

J'espère que les américains que tu rencontres ne réagissent pas comme toi, parce que vu ton ouverture d'esprit, ça doit pas donner une très bonne image des français...

(WW) R128(0): Static buffer allocation failed -- need at least 17227 kB video memory

mode : 1400x1050 en 24/32 bits (4 octets/pixel)
1400*1050*4*3/1024 = 17227 Ko, normal

2ème message :
(EE) R128(0): [dri] R128DRIScreenInit failed (depth 8 not supported). [dri] Disabling DRI.

DRI n'est pas supporté en 8 bits, normal.

3ème message :
(WW) R128(0): Static buffer allocation failed -- need at least 8663 kB video mem

mode : 1400x1050 en 16 bits (2 octets/pixels)
1400*1050*2*3/1024 = 8613 Ko, normal

A priori tu as 8Mo de mémoire pour ta carte graphique, donc il est logique qu'aucun des deux modes ne passent (8Mo = 8192Ko). Les seules solutions à mon avis sont :
- ne pas utiliser le double buffer (commenter Load "dbe" dans XF86Config)
- ajouter de la mémoire vidéo
- baisser la résolution

Mes 0,2 €

Oui, les carrés définis dans le quadtree ne peuvent pas se chevaucher, c'est le principe de la construction. Mais je ne vois rien qui empêche des régions rectangulaires de se chevaucher. Les noeuds du quadtree ne fournissent que la liste des régions rectangulaires qui lui sont associées (par recouvrement ou inclusion), il n'y a pas de lien direct entre les régions.

Enfin, c'est peut-être juste un problème de vocabulaire, pour moi le mot région à le même sens que celui utilisé dans la formulation de la question d'origine.

> les zones ne peuvent pas sa chevaucher

Ah bon ? Qu'est ce qui empêche une région d'appartenir à plusieurs carrés du quadtree ?

> ça n'est adapté qu'à des données statiques, une modification risque
> d'être _très_ coûteuse (ça n'est ptet pas important ici)

Oui, il faudra sans doute regénérer le quadtree entier à chaque insertion, mais comme la lenteur de l'insertion ne semblait pas être un problème...

Et ceux-là ?

http://www-fourier.ujf-grenoble.fr/~parisse/giac.html(...)
http://perso.wanadoo.es/antlarr/kalamaris.html(...)
http://www.ginac.de/(...)
http://www-spi.lip6.fr/foc/index.html(...)
http://www.octave.org/(...)

Faut voir s'il y a vraiment besoin d'optimiser, parce que les comparaisons pour tester si un point est dans un rectangle, c'est quand même particulièrement rapide, à moins qu'il y ait énormément de régions. Il vaut quand même mieux faire des tests avec des données réalistes pour voir si ça vaut le coup de se prendre la tête.

Sinon, tu peux peut-être utiliser des quadtrees (voir http://www.flipcode.com/tutorials/tut_octrees.shtml(...) ) pour ta structure de données.