Version imprimable
Juste une petite news pour tout les amateurs de Quake 3 et d'OpenGL.
Le code source est en licence GPL.
J'ai déjà recompilé le code source sans problème. Par contre, il faut récupérer les données d'un cd du jeu. Je vais regarder un peu ce moteur.
Si vous avez des informations intéressantes, faites signes. Le code semble déjà très documenté :D
Bonne lecture :wink:
Pour une bonne nouvelle, c'en est une ! ca va engendrer un sacré lot de travail ! va falloir dissequer ce teriible moteur qu'est celui de QIII
Salut,
Je vais sûrement dire une connerie mais he... pourquoi quand je regarde le code de se moteur, je ne voie aucune instruction OpenGL ni Glu ni Glut si même SDL...
Utiliserai t'il sa propre librairie graphique ?
Merci
Si, c'est de l'opengl.
jette un coup d'oeil au repertoire CODE\RENDERER\
Ha oui exacte !
Aussi pourquoi ils font toujours 30 milles fichiers source, on s'y retrouve plus après :'(
C'est parceque c'est un vrai jeu, un super jeu avec un moteur 3D ultra performant.
En plus, Quake est aussi un moteur de jeu, et inclut bcp d'outils et de parsers et bla bla bla ...
lol, c'est plutot parcequ'il est structuré, il faut comprendre la logique de développement derrière et surtout le fait de travailler en équipe oblige encore plus à partitionner les sources
c'est aussi pour diminuer le temps de compilation, tu modifies un truc dans un fichier .c et tu n'as pas besoin de recompiler 15000 trucs
un .h par contre tout dépend des routines qui l'incluent
Au contraire, c'est très bien !Citation:
Envoyé par Ekinoks
Avoir un fichier avec 30 milles lignes de code, c'est pas génial pour s'y retrouver !
J'ai commencé à regarder un peu le code mais je n'arrive toujours pas à lancer le jeu. Donc je debug au fur et à mesure mais c'est long.
Déjà faut savoir ou mettre les fichiers du cd.
Dès le début, il veut lire default.cfg qu'il faut mettre dans le répertoire demota :
Si quelqu'un arrive à lancer le jeu, qu'il me fasse signe :-)Code:
2#define DEMOGAME "demota"
Sinon, je sais pas si vous avez vu la protection CD, mais ca me semble bizarre quand même. Il teste juste si un cd est présent avec l'exe de quake3 :?:
Code:
2
3
4
5
6
7
8
9
10
11
12
Oui, c'est vais, découper son code en plusieurs fichier c'est cool... mais la, on sait même plus ou le code commence... et le découpage est un peu abusif a mon goût...
Enfin, faut dire que je n’ai pas passé beaucoup de temps à essayer de comprendre sa méthodologie... c'est peut-être pour ça aussi ;)
après tout pourquoi pas ?Citation:
Envoyé par SteelBox
de mon point de vue pourquoi se casser le q alors que n'importe quelle protection sera craquée par les pirates en quelques heures maxi
quand je pense qu'il y a des boite qui dépensent des fortunes pour créer ou acheter une protection logicielle au plus proche de l'infaillible :?
là il a du passer 2mn à taper le code lol
à côté de cela il y a aussi la clef CD
et on ne peux pas jouer sur le net avec la même clef qu'un autre
bref il n'y a pas que la protection CD dans tout ça
C'est un découpage tout à fait normal qu'on retrouve dans beaucoup de moteurs. Y'a pas de quoi s'affoler et c'est pareil pour tous les gros projets Open source (Firefox, Open office,...).
Faut pas croise qu'il va vous suffir d'ouvrir le projet puis de tout re-coder en 30 secondes. Il vous faudra surement plusieurs semaines pour comprendre un peu le code et pouvoir faire des choses correctes !
a mon avis, la protection CD original a due sauter car etant tres probablement proprietaire et crée par une autre boite... Sinon j'aime beaucoup l'utilisation du stencil buffer pour reperer les zones d'overdraw... tres classe comme methode...
bafman, Est ce que tu peux expliquer un peu cette histoire d'overdraw stp ?
depuis toujours Carmack a chercher à reduire l'overdraw dans tout ses moteurs. En gros l'overdraw est simplement le fait d'ecrire plusieurs fois le même pixel (par exemple en affichant 2 faces qui se superpose), plus un moteur a d'overdraw, plus il traite de pixels inutilements, et c'est donc pour ca que sont utilisé des algo comme les PVS et autre clipping de geometrie (en plus de reduire la quantitée de donnée envoyée au GPU).
Dans le moteur de quake 3, Carmack utilise simplement le stencil buffer en incrementation pour pouvoir voir ou les pixels sont traité plusieurs fois, comme ca il peut analyser precisement l'efficacitée de ses algo de clipping. c'est tout simple mais pas bête du tout...
Merci pour la précision.
C'est vrai que c'est ingénieux.
bafman, tu sembles très bien connaitre la question. Afin de faire une petite analyse du moteur, pourrais tu donner des extraits du code source qui te font penser que l'overdraw est assez réduit.
Merci :D
Tu sais, bafman, pour le test de l'overdraw en utilisant le stencil buffer,
apparamment, ce n'est pas Carmack qui l'a inventé, c'est même au tout début de l'histoire
du stencil buffer que ça remonte, pour t'en convaincre
http://www.opengl.org/resources/feat...alk/sld046.htm
heu... au tout debut du stencil buffer, la je ne suis pas d'accord...
comme son nom l'indique, le stencil buffer est... un stencil, comme sur les vieille imprimantes a stencil. en gros un stencil est une feuille qui est perforée en fonction de l'endroit ou on veut ecrire et ensuite il ne reste plus qu'a le poser sur un feuille et a encrer le tout, comme une sorte de pochoire... et bien le stencil buffer a la base c'est pareil. D'ailleur c'est une ineptie que d'avoir des buffer stencil qui font plus d'1 bits par pixel (mais c'est bien pratique quand même :wink: )
Pour en revenir au moteur de quake 3, il y aura toujours de l'overdraw, le but etant d'equilibrer entre limiter l'overdraw et ne pas faire d'algo de limitation d'overdraw qui consomme trop... si vous vouler voir l'intitialisation du stencil buffer pour l'overdraw, c'est dans la fonction RE_beginFrame()
D'ailleur un autre truc qui est marquant dans ce moteur c'est la relativement petite taille du renderer notamment la lib pour charger les textures...
Je confirme pour le chargement des textures, puisque les programmeurs n'ont pas voulu créer un DevIL ou FreeImage, ils ont fait juste ce que dont ils ont besoin, je ne me rappelle plus, je crois que c le tga, et 2 ou 3 autres formats : c'est comme tout dans Quake : simple et fichtrement efficace !
Et je crois bien que cet article date dès les débuts du Stencil buffer : il cite la TNT2 !
le stencil buffer date... houla au moins des année 70 quand on a commencer à s'interesser à la programmation 3D sur ordinateur... la preuve : l'algorithme de base de shadow volumes a été inventé en 77 et utilisait deja un buffer stencil... et oui la 3D ne date pas des année 90 :wink:
bien entendu a l'epoque ca tournait sur des super calculateurs de folie mais c'etait bien de la 3D...