démarrer en prog (orientée jeux/3D)

démarrer en prog (orientée jeux/3D) - Programmation

Marsh Posté le 08-04-2002 à 01:22:55    

Bonjour!
Je voudrais profiter de mon temps libre pour démarrer en programmation 'pur newbie pour l'instant en la matière ;) ). j'ai donc tous un tas de questions que je me pose! je souhaiterais m'orientée vers le dev' openGL ou D3D (conseillez moi la dessus SVP! :) )...
donc, les plus importantes:
-quel language effocace et abordable?
-Quel envrionnement de dev'? (gratuit si possible, sinon, je me débroullerai bien, mais bon...
des livres ou revues intéressants?
-OpenGL ou D3D?
bref, des questions qui doivent revenir souvent, mais bon... ;)  
merci!

Reply

Marsh Posté le 08-04-2002 à 01:22:55   

Reply

Marsh Posté le 08-04-2002 à 02:25:51    

vi, ca revient souvent :D
 
Avant decommencer ogl / D3D familiarise toi avec un langage
le plus courant pour ce genre de blague doit etre le C++, m'enfin de l'ogl ca se fait aussi avec C/delphi et du DX avec vb
 
alors bon, c toi qui voit ; T'en choisi un, pis tu te lance et vala
 
perso j'ai fait C puis C++

Reply

Marsh Posté le 08-04-2002 à 10:00:18    

un supoer site pour debuter en OGL (serieu, il est vraiment top de top ! ça commence au niveau le plus simple pour finir sur des trucs de fou) : http://www.gamedev.net/

Reply

Marsh Posté le 08-04-2002 à 10:54:12    

Un pote va me passer une beta de visual studio .NET (qu'il a eu avec un mag' de dev' américain)
c'est un bon environnement de dev'? (mircosof, j'ai un peu peur que ce soit un peu "directeur" en terme de choix du language...)

Reply

Marsh Posté le 08-04-2002 à 10:56:21    

je ne connais pas visual .NET, mais son incarnation précédente (visual c++ 6) est L'outil de développement des jeux (sur pc tout du moins, xbox aussi j'imagine).

Reply

Marsh Posté le 08-04-2002 à 11:07:58    

youdontcare a écrit a écrit :

je ne connais pas visual .NET, mais son incarnation précédente (visual c++ 6) est L'outil de développement des jeux (sur pc tout du moins, xbox aussi j'imagine).


Ouais, pour faire du DirectX. Parce que pour faire de l'OpenGL, la plate-forme SDL me paraît un rien plus adaptée (et un rien moins chère, aussi).


---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book
Reply

Marsh Posté le 08-04-2002 à 11:11:48    

pour .net, c'est une beta, gratuite et légale ;)  (peut limitée ds le tps, faut que je vérifie)
autrement, le dev ogl est il plus accessible que le dev d3d, ou ça se vaut?

Reply

Marsh Posté le 08-04-2002 à 11:12:51    

Jar Jar a écrit a écrit :

Ouais, pour faire du DirectX. Parce que pour faire de l'OpenGL, la plate-forme SDL me paraît un rien plus adaptée (et un rien moins chère, aussi).


pour faire du n'importe quoi. le jeu opengl le plus connu est sûrement quake, et carmack programme avec vc++.
 
pour opengl, le plus adapté me paraît être opengl. pourquoi rajouter un layer sur une api clean et simple ? et pourquoi confondre lib / compilo ?

Reply

Marsh Posté le 08-04-2002 à 11:14:40    

webzeb a écrit a écrit :

autrement, le dev ogl est il plus accessible que le dev d3d, ou ça se vaut?


l'intérêt d'opengl : les exemples bien documentés, cf le lien sur nehe filé plus haut. directx s'est considérablement assoupli niveau d'utilisation, mais opengl reste (un poil) plus simple pour débuter.
 
par contre pour des fonctions plus avancées, d3d est plus simple.

Reply

Marsh Posté le 08-04-2002 à 11:15:22    

pour dx et ogl, je sait que ce sont toutes deux des librairies, mais je suppose qu'elle n'ont pas la m^me philosophie, et que par conséquent elles ne sont pas aussi faciles à comprendre l'une que l'autre..

Reply

Marsh Posté le 08-04-2002 à 11:15:22   

Reply

Marsh Posté le 08-04-2002 à 11:17:03    

par fonctions avancées, tu veux dire pour des effets, genre le bump dot3 par ex'?

Reply

Marsh Posté le 08-04-2002 à 11:19:00    

webzeb a écrit a écrit :

par fonctions avancées, tu veux dire pour des effets, genre le bump dot3 par ex'?


oui, ou du simple multitexture. sous dx c'est implicite, sous ogl il faut chopper un pointeur sur la fonction, copiercoller des #define, etc.  
 
l'autre (gros) problème est que maintenant dx est plus 'standardisé' qu'ogl. pour les vertex shaders, tu as le même code sous dx avec une ati ou une nvidia, sous ogl tu as du code qui doit gérer deux extensions différentes.

Reply

Marsh Posté le 08-04-2002 à 11:20:34    

youdontcare a écrit a écrit :

pour faire du n'importe quoi. le jeu opengl le plus connu est sûrement quake, et carmack programme avec vc++.
 
pour opengl, le plus adapté me paraît être opengl. pourquoi rajouter un layer sur une api clean et simple ? et pourquoi confondre lib / compilo ?


Carmack compile peut-être sous Windows avec vc++, mais il développe à la base sous Linux, si je ne m'abuse (au moins depuis Quake 3).
 
Et la SDL apporte une couche d'abstraction qui facilite l'emploi d'OpenGL, rien de plus. Pour gérér les périphériques d'entrée, c'est quand même appréciable. Pour ajouter des scènes 2D (cinématographiques, par exemple) sans se faire chier, aussi. Après, je ne connais pas suffisamment pour juger vraiment ce que ça apporte, mais on m'a dit que c'est aujourd'hui ce qui se fait de plus simple.

 

[jfdsdjhfuetppo]--Message édité par Jar Jar--[/jfdsdjhfuetppo]


---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book
Reply

Marsh Posté le 08-04-2002 à 11:44:03    

>> Carmack compile peut-être sous Windows avec vc++, mais il développe à la base sous Linux, si je ne m'abuse (au moins depuis Quake 3).
 
cf le message de robert duffy http://slashdot.org/articles/01/02/22/1744231.shtml  
 
"We do use Visual C++ as our primary platform, and in general we try to stay away from any Microsoft specific syntax. The editor which is now integrated with the engine still uses MFC but I am about to start weeding out all of the MFC code. "
 
etc.
 
>> Et la SDL apporte une couche d'abstraction qui facilite l'emploi d'OpenGL, rien de plus.  
 
ce que je voulais dire c'est qu'opengl est _déjà_ simple, donc pourquoi compliquer :). ceci dit je n'ai jamais utilisé non plus, donc pas d'opinion sur la chose.

Reply

Marsh Posté le 08-04-2002 à 11:49:32    

"We do use Visual C++ as our primary platform, and in general we try to stay away from any Microsoft specific syntax. The editor which is now integrated with the engine still uses MFC but I am about to start weeding out all of the MFC code. "
Au temps pour moi.
Cela dit, comment ils arrivent à compiler ça sous Linux s'ils utilisent les MFC ?


---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book
Reply

Marsh Posté le 08-04-2002 à 11:53:15    

je suppose qu'ils utilisent ça comme prototype pour le moment. si tu lis tout le message, tu vois que duffy est justement en train d'éliminer le code mfc.
 
comme c'est noyé dans la masse, je copiecolle :
 
Just a couple of additional notes in this area. We do use Visual C++ as our primary platform, and in general we try to stay away from any Microsoft specific syntax. The editor which is now integrated with the engine still uses MFC but I am about to start weeding out all of the MFC code. This is not going to be pleasant but the results should be very good. Graeme used at least three maybe more compilers getting the demo to run on the different Apple OS', each one presented it's own unique challenges in functionality and standard adhesion. As expected, even with a standard for C++, none of the compilers are quite on the same page. Microsoft seems to be the most compliant but I'd have to go back and read the draft to back that up. We (we being Grame :-) hit a bunch of little syntax gotchas in the form of for (int i = 0; i blah; i++) { // later at same scope for (int i = 0; i blah; i++) { where I believe the GNU stuff moaned about the second use of i, I forget which is compliant. John surely has opinions on the move to C++, but in general I think it has gone very well. There are times when it is just plain difficult to figure out why inlines are not working or why something is suddenly faster or slower but overall I don't think we have seen a speed drop in retail code. In debug code, the non-inline expansion really bites us, still looking at some solutions for that. All in all the Apple demo got all of our cross platform ducks in a row probably much sooner than we would have done normally. robert...

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed