Bonjour à tous ! Je suis nouveau sur ce forum.

Voilà, j'ai demandé à un ami un moteur de jeu gratuit pour créer des jeux vidéo, il m'a tout de suite dit : Irrlicht. C'est pour cela que je suis ici.

J'ai une idée de projet, mais je ne sais vraiment pas programmer, je suis juste un graphiste.

Est-ce que quelqu'un pourrait m'expliquer, assez rapidement ce que je dois faire (télécharger...) pour pouvoir commencer facilement. Parce qu'apparemment, c'est n'est pas un programme Irrlicht...

Merci d'avance.

Oulala, moi aussi suis débutant sous Irrlicht, mais j'ai déjà bien testé 2 autres moteurs (Ogre3D et CrystalSpace) et je programme depuis 24 ans... Tout ce que je peux te dire, c'est qu'IrrLicht me semble être le moteur DE RENDU (pas de jeu) le plus simple à mettre en oeuvre et un des plus aboutis. Mais de là à dire que tu pourras faire un jeu avec... Vois plutôt ça comme une librairie de rendu graphique. Reste beaucoup à programmer pour faire un jeu, à moins de faire un truc très basique.
Le mieux est peut-être d'utiliser Irrlicht CP .NET de DeusXL car très simple à utiliser

1) Il te faut downloader SharpDevelop par exemple, et Irrlicht CP.NET (http://irrlichtnetcp.sourceforge.net/in … /Main_Page)
2) Ensuite, tu crées un nouveau projet sous SharpDevelop (mode console), et tu fais Projet->Ajouter une reférence->Browser d'assemblie .NET et tu importes Irrlicht.NET.dll
Tu n'as rien d'autre à faire, pas d'include en bataille, pas de librairie ou quoi que ce soit, c'est le pied .NET
3) Tu remplaces le code de ton Main par un des tutos sur le site http://irrlichtnetcp.sourceforge.net/in … :Tutorials

Tu auras besoin d'Irrlicht 1.2 aussi ne serait-ce que pour réccupérer des médias de test
Tu verras, très simple à mettre en oeuvre par rapport aux autres moteurs de rendu.
Ton repertoire éxecutable doit contenir les DLLS : irrlicht.DLL, irrlichtW.DLL, Irrlicht.Extensions.dll et bien sûr, Irrlicht.NET.dll

PS: désolé si tu es sous Linux, mes explications sont pour Windows... faudra adapter pour Linux, mais c'est quasi pareil.

Maintenant, comme je te dis, c'est pas un moteur de jeu. Le mieux serait peut-être par commencer par faire des MOD à partir d'éditeur de jeu (Valve Hammer, Unreal, ...). La programmation d'un jeu, sans moteur de jeu, n'est déjà pas toujours facile, mais si tentes de faire un jeu avec un moteur de rendu, tu risques de t'arrêter pas plus loin que les tutoriels...).

Si tu veux rester dans l'OpenSource, essaye CELStart de CrystalSpace, tu peux faire un jeu directement sous Blender avec quasiment aucune prog, à partir du moment où tu ne demandes pas plus de fonctions qu'offertes par le moteur.

Dernière modification par benicourt (14-02-2007 12:37:31)

Salut,
Je pense qu'attaquer directement au C++ si tu n'as aucune notion de programmation, va te décourager très vite et tu finiras par abandonner.
Personnellement, j'ai commencé la programmation "3D" il y a 7 ans sur des langages Basic.
Jai ensuite migré vers le C# pour enfin passer au C++ il y a tout juste 5 mois.
Je ne dis pas que c'est infaisable, mais c'est une tache très difficile qui demande beaucoup de temps libre et de motivation personelle.
J'en suis encore au stade de l'apprentissage dans se langage, mais c'était le but que je m'étais fixé il y a longtemps (apprendre le c++).

Donc je te conseillerai la même chose, éventuellement regarder du côté du C# avec Irrlicht CP.Net, ça reste dans le raisonnable et surtout dans le réalisable si tu n'a aucune notion.

Donc comme le dit Benicourt, SharpDevelop + Irrlicht CP .Net me semble bien adapté.

Il te faudra le framework .Net 2.0 pour programmer en .Net dispo ici :
ICI

Sharpdev dispo ici :
ET ICI

et le sdk dont on t'a déjà donné le liens au dessus.Ensuite je t'invite à aller faire un tour du côté de dotnet.developpez.com sur lequel tu trouveras un tas d'info concernant les langages .Net.

Voilou bonne chance.

Merci à vous deux pour vos réponses très rapide.

J'ai beaucoup de motivation pour créer mon idée. Evidemment, je sais bien qu'il va falloir que j'y travail beaucoup, et que ça ne va pas se faire du jour au lendemain.

Je vais essayer tout ce que vous m'avez conseillé.

Edit : Je viens de lancer tout les programmes... Je ne comprend décidément rien.

N'existerait-il pas un tutorial qui expliquerai la programmation pour les débutants qui ne connaissent rien du tout ?

Mathieu.

Ben si ça existe, mais ce que tu as à apprendre est si vaste ... que je crains que ta motivation ne tienne pas assez longtemps, sans essayer de te juger - je l'ai vu tellement souvent.

Le mieux est souvent de commencer à un haut niveau d'abstraction (là où on utilise un soft et qu'on programme pas) et de descendre en fonction des besoins. C'est pour cela que je te conseillais le GameBlend, qui te permet de faire des jeux avec Blender et avec Python d'étendre tes besoins. Celstart te permet ainsi d'avoir des jeux "compilés" programmables en XML.

Dans quelques temps, on aura peut-être suffisamment de docs et d'outils pour Irrlicht, je n'en doute pas - mais c'est pas encore le cas, faut être assez baroudeur et un pas trop novice en prog pour passer par là.

Salut !
Tu as une autre solution.

Torque de GarageGame. C'est un moteur de JEU, lui. Il gère les applications client/serveurs, les animations, le scripting, etc, etc... Plutot bien foutu comme truc. l'adresse, si mes souvenirs sont bon... (Oui, ils sont bons finalement ! ) c'est http://www.garagegames.com/.

Ils proposent une foultitude de ressources. Le blème : faudra mettre la main a la poche. Mais je ne trouve pas que ce soit excessif, cela dit.

Mais surtout n'hésite pas a mettre la main a quelque chose comme irrlicht, que ce soit en c#, en c++, en java ou autre. Toute expérience que tu gagneras dans le domaine t'aidera plus tard.

Torque y'a de la prog aussi.Tu peux utiliser son langage de script au début qui reste plus simple d'emploi, mais y'a toujours et encore du code.Les propositions de Benicourt sont pas mal je trouve pour apprendre, et je pense qu'il sait de quoi il parle car il a une grande expérience en programmation.La première chose que j'ai appris dans se milieu, même si c'est dur avec mon sale carractère c'est d'apprendre à reconnaitre quand j'ai tord, et par dessus tout écouter les anciens !

+1 pour benicourt.

@Copland : Vrai que c'est dur de reconnaitre ses torts, au début, mais quand on vois que ça avance mieux après, c'est de plus en plus facile.

@Mathieu : La programmation, quel que soit le langage, est certainement complexe au début, mais quand on commence a avoir ses premiers bon résultats, que le truc chiant fini par fonctionner au quart de poil, on ressent une certaine fierté. Honnêtement j'éprouve aujourd'hui bien plus de plaisir à concevoir un jeu qu'a y jouer. Maintenant, quand je vois un jeu, ma question n'est plus : Comment on joue ? mais plutôt : Comment ils ont codé ça ?

En levant les yeux de mon écran, pour boire ma 5 ou 6ème cafetière de la journée, j'ai vu que le soleil aller se coucher... mais en fait, c'était le lever... Aucun jeu ne m'a jamais fait oublier de dormir, la programmation : si !

Dioxy on voit les mecs intox par la programmite aigüe, va donc expliquer ça à ma femme...Nous sommes des incompris

le pire c'est quand tu reveille en pleine nuit, tu sais pas quoi faire, alors t'allume l'ordi, tu regarde tes mails, rien .. et la tu commence a coder ..

l'ennui c'est que dans ces conditions, c'est fun mais on code assez mal


pour répondre a la question de départ de Matthieu, ce que tu peut faire, c'est trouver un codeur, et faire équipe, beaucoup de codeurs recherchent des modeleurs, parce que ce sont deux domaines completement différents, qui prennent tout deux beaucoup (le mot est faible) de temps, et que en général les codeurs n'aiment pas modeler, et vice versa

en tout cas, si j'avais du temps, je voudrai faire équipe avec un modeleur ^^

Dernière modification par Jerry Kan (14-02-2007 16:56:24)

Héhé, oui, on se retrouve bien tous là ... Le seul problème, c'est qu'il y a 10 ans encore, j'arrivais à faire des programmes et des jeux complets, et à les vendre... Aujourd'hui, je ne bosse que sur certaines parties et ça m'énerve ! J'ai pas envie de me spécialiser, j'aime bien toucher à tout. Mais les technologies vont si vites... la 3D en est un bon exemple, qu'il faudrait presque ne faire que ça pour avoir une chance de bien gagner sa vie dans ce domaine...

Si quelqu'un veut apprendre la  prog pour développer des jeux, je lui souhaite vraiment bon courage ! Dans tous les  cas, il vaut mieux s'appuyer sur le travail des autres, car vouloir tout refaire de zéro, c'est partir pour 10 ans de développement ou refaire un pacman même pas amélioré.

Pour ma part, je crève d'envie de réécrire un  moteur 3D, mais ce n'est que pure vanité. Quand je vois déjà ce qu'on peut extraire d'un OpenGL et d'un DirectX, le travail est déjà bien prémaché - mais il reste considérable...

A ce propos, j'ai une petite question pour les Irrlicht Fans : Si on omet l'aspect Mutliplateforme, est-ce qu'il n'est pas plus simple de bosser directement avec DirectX qui est superdocumenté, que de bosser avec Irrlicht ?

je dis ça parce que je trouve des codes sources complet, assez simples d'approche, et permettant de faire des trucs super alors que j'ai l'impression qu'on rame avec Irrlicht sur des choses assez simples (animations bones, shaders, etc.) ?

Dernière modification par benicourt (14-02-2007 17:20:43)

Je répondrais un truc con : Je trouve l'OpenGl plus "élégant". Mais c'est une impression parfaitement subjective. Si je devais choisir la simplicité, je prendrais XNA que j'ai testé. Le framework xna simplifie vraiment la vie du codeur, mais je ne sais pas pourquoi, je n'accroche pas alors que j'aime beaucoup le c#. Ca doit être mon côté linuxien (Ubuntu).

En plus, xna est vraiment très peu cher et permet de développer des jeux xbox360...
Je dois être zarbi...

benicourt :

A ce propos, j'ai une petite question pour les Irrlicht Fans : Si on omet l'aspect Mutliplateforme, est-ce qu'il n'est pas plus simple de bosser directement avec DirectX qui est superdocumenté, que de bosser avec Irrlicht ?

Ouaou... J'ai jamais codé en dx directement, mais c'est pas le même monde... Irrlicht a déjà un haut niveau d'abstraction par rapport aux autres engines C++, alors par rapport à dx (même si il est aussi documenté que tu le dise)

C'est justement ça le problème, c'était d'autant plus vrai il y a quelques années, mais aujourd'hui, on est capable de faire plein de choses rapidement sous DirectX, comme charger des objets, avec bones, gérer des anims et même si toutes les fonctions ne sont pas directement disponibles, un simple copier-coller du SDK vers notre prog permet de gérer des choses très complexes.
Je dois rater quelque chose d'important, sinon SIO2 ne s'ennuierait pas à porter les exemples du SDK sous Irrlicht, à moins que cela ne soit pur exercice de style.
Vous les pro d'Irrlicht qui connaissez bien DirectX, donnez-moi les bons arguments pour avoir envie de rester sous Irrlicht tout en étendant ses fonctions via le directX.

Je ne suis pas d'accord sur le fait de dire qu'avec directX tu peux programmer des choses très simplement et rapidement. Pour moi que se soit irrlicht, ogre, tv3d, crystal space, ils ont tous le même interret : Permettre un développement rapide et simplifié.
En 3 lignes de code sous Irrlicht, tu as chargé ton modèle 3D et tu ne te préocupes pas de savoir à quel moment tu vas l'afficher, tu n'as pas 500 lignes à spécifier pour afficher simplement sa texture etc...Jette un oeil au source des moteurs 3D pour charger simplement un modèle 3D non animé, ça fait peur quand tu vois la taille du code et les problèmes à gérer derrière.

Oui, c'est ce que je constatais à  une certaine époque (notamment en version 5), mais prenons un exemple en version 9: Regarde le code de SimpleAnimation Direct3D Sample : (SDK root)\Samples\Managed\Direct3D\SimpleAnimation
Le code source complet (hors shader) fait peu plus de 600 lignes (50% de commenatires et lignes vides). Mais la partie ne doit faire que 100 lignes. On imagine fort bien qu'en quelques minutes on a encapsulé le code de gestion des évenements, du choix de l'affichage, etc. En 3 coups de cuillère à pot, on a plus beaucoup de lignes - Et il s'agit tout de même de la gestion d'une anim avec Bones ! ET tu as vu le reste, toutes les capacités présentées sous DirectX... J'ai l'impression qu'on est plusieurs années à la  traine sous Irrlicht ! Bien sûr, sous DirectX, pas d'OpenGL, pas de mode Software, et uniquement sous Windows - je ne dis pas qu'Irrlicht n'a pas son bon coté, mais pour celui qui veut développer sous Windows, est-ce qu'il a vraiment intérêt à bosser sous Irrlicht plutôt que de se regrouper quelques gfonctions utiles avec des copier-coller et faire son mini-moteur sous DirectX.

Pour l'instant, je dois dire que rien de ce que j'ai vu ne m'a convaincu totalement sous Irrlicht (mais sur les autres moteurs non plus, c'est pas une critique comparative) : par contre, j'ai vu des trucs assez avancés sous directX (Gesttion des anims via le GPU, Chargement de terrain en streaming, etc.) avec des vitesses assez impressionnantes... Et ne connaissant pas assez Irrlicht, je me demande si je ne vais pas galérer à vouloir implémenter cela dessus comme le fait SIO2... Je sent bien au fond que je dois avoir tord, mais j'ai besoin qu'on m'explique.

Je vais aussi tourner le problème dans l'autre sens - et là je vais avoir de ceux qui ont déjà réalisé leur propre SceneNode comme le WaterSceneNode de DeusXL - est-ce difficile de fouiller au coeur d'Irrlicht, peut-on vraiment lui  ajouter des éléments maison sans trop de difficultés. Je pense toujours à SIO2 et sa façon d'intégrer des exemples du directX SDK sous Irrlicht, est-ce un travail énorme ? Par avance, merci

PS: je lis actuellement  "3D Game Engine Programming" de Stefan Zerbst et Oliver Duvel (chez Thomson Course Technology) - Y-a tout pour créer son moteur sous DirectX 9. Le livre aborde un max de sujet : de l'architecture générale du moteur, les optimisations pour les calculs, la gestion du rendu, les shaders, les modèles  animés (bones et keyframes), les interfaces, le son, le réseau; la gestion du temps, les scenes managers (BSP, octree, etc.). D'autres bouquins comme celui d  Morgan Kauffman (3d Game Engine Architecture Engineering Real Time Applications) proposent des sujets assez pointus comme La gestion des collisions, la gestion de la physique, etc. Tout cela pour dire que les moteurs  de rendus font moins gagner de temps qu'avant, vu la documentation qu'on possède. D'où ma réflexion.

Dernière modification par benicourt (15-02-2007 12:29:11)

Il est clair que si tu veux te tourner vers un rendu poussé avec des shaders de Glow,Hdr,Reflection,Refraction et companie, tu vas avoir de sérieux problèmes sur irrlicht, pas pour les implémenter mais plustot sur la vitesse de rendu au final.
Mais ça n'empêche que je ne suis pas d'accord sur le fait de dire qu'il est plus simple de charger un modèle animé avec managed DirectX plustot qu'avec Irrlicht.
Irrlicht = max 10 lignes de code.
Directx managed = minimum 150 lignes de code.
Perso, je n'ai ni l'envie, ni le temps, ni l'expérience pour programmer un moteur 3D.Même les plus talentueux des programmeurs qui s'aventurent dans cette tache, bien souvent sous estime le temps de développement et se rendent compte au bout de 6 mois qu'il vont y passer 5 à 6 fois le temps prévu au départ.Il suffit de prendre l'exemple sur Truevision 3D.Son programmeur avait annoncé la version release freeware 6.5 pour l'année 2005...Nous sommes en 2007 et le moteur n'en est qu'au stade de béta, et il a toujours pas mal de bugs à corriger.
Sinon pour te reprendre, Irrlicht n'est pas à la traine loin de là, je pense que son plus gros problème vient du fait qu'il est multiplateforme Win/Linux et surtout OpenGL/DirectX.
Je n'ai encore à l'heure actuelle, pas vu de moteur 3D qui soit cappable d'afficher de l'openGL et du DirectX rapidement.Je présume que ça provient du fait qu'il y a des restrictions à s'imposer vis à vis du développement pour que cela reste compatible.

Irrlicht = max 10 lignes de code - ben  non, puisqu'il ne gère pas nativement les animations avec bones ! (à priori, pas trouvé jusqu'à maintenant).
Oui, d'accord avec toi concernant TrueVision : le tout est de savoir si on veut utiliser la 3D pour soi, ou si on a  envie de refaire un moteur générique utilisé par d'autres ! Moi, perso, y-a certainement pleins de fonctions d'Irrlicht que je n'utiliserai pas (mais je suis bien content qu'elles existent... juste au cas où). C'est juste qu'à l'instar d'Ogre et de Crystal Space, on est tout content quand on démarre parce que cela annonce plein de belles promesses  et qu'une fois qu'on gratte un peu on déchante. Mes déceptions actuelles sont situées sur les animations, sur la gestion du LOD, sur les scene Managers pas apatés aux vastes mondes, etc... Et encore, je ne fais que découvrir...
je ne disais pas qu'Irrlicht était à la traine par rapport aux autres moteurs, mais concernant la technique, DirectX semble tellement plus fouillé qu'OpenGL, que si Irrlicht souhaite garder sa portabilité, il risque comme il semble actuellement de n'intégrer que des technologies dépassées depuis plusieurs années. C'est ça qui est dommage !

Je ne vois pas pourquoi tu dis qu'il ne gère pas les Bones, le modèle que je t'ai envoyé à été animé par un Biped sous max hors l'export d'un biped c'est tout simplement des Bones.Ton personnage bouge bien, et tu peux récupérer les positions des Bones de chaques membres.
Je comprends pas ce que tu entends par "gérer les bones nativement".

Après c'est un choix... Il y a pas mal de moteurs dx only qui ont toutes ces nouvelles possibilités. Copland évoquait le "problème" d'irlicht qui est son aspect multiplateforme et multirenderer. C'est un problème du point de vue de la rapidité de developpement et des techs récentes qui seront implémentées moins rapidement. Après, ce "problème" est aussi le principal avantage d'irrlicht. Si tu veux utiliser les dernières techs de directX9 et enchainer sur la v10 juste après c'est ballot à dire mais c'est pas irrlicht qu'il te faut. Vu que tu codes déjà pas mal pourquoi pas coder directement en directX 9 comme tu le dis mais c'est réinventer la roue... D'après moi tu va vite fait déchanter mais peut-être que je me trompe Va voir sur devmaster il y a que ca de vrai

Copland :

Je ne vois pas pourquoi tu dis qu'il ne gère pas les Bones, le modèle que je t'ai envoyé à été animé par un Biped sous max hors l'export d'un biped c'est tout simplement des Bones.Ton personnage bouge bien, et tu peux récupérer les positions des Bones de chaques membres.
Je comprends pas ce que tu entends par "gérer les bones nativement".

Oui, ça doit fonctionner, en  mode non-hardware, sauf que j'ai pas été fichu de l'animer le tiny_4anim.x qui normalement a 3 animations dont le "WALK" et que je  n'ai pas réussi à faire marcher en Irrlicht CP NET. Irrlicht sait-il utiliser le format .X avec plusieurs animations...

Bonjour tout le monde.

Commencer par un simple pong en 2d...et ensuite la 3d...

Déjà un pong demande du talent et surtout bien connaitre son langage...

Le seul adapté pour les jeux ...le c++...pour avoir une vitesse d'affichage  assez bien en FPS

Le moteur de irrlicht est tres bien pour connaitre le c++...

Mais il faut acheter un livre de 1000 pages sur le c++...sinon ce n'est pas la peine de commencer

Tu prends l'exemple 01 de irlicht et tu regardes bien comment c'est construit...

Tu raproche ton bouquin des exemples et tu piges beaucoup plus vite...

Les exemples sont une mine d'informations...

Affiche déjà une image sur ton écran...c'est déjà un premier pas...important

Le but est d'avoir un FPS qui tienne la route ...le reste c'est du pipeau...

cordialement

Commencer par un simple pong en 2d...et ensuite la 3d...
Déjà un pong demande du talent et surtout bien connaitre son langage...

C'est bête, j'ai fait l'inverse moi^^

Là où je veux en venir c'est : personne n'a conseillé DarkBASIC Pro ?

DBPro c'est vraiment le top du top pour débuter, un langage BASIC orienté jeu, très facile à maitriser et qui permet d'avoir un résultat motivant tout en découvrant des notions de progr comme les pointeurs (pas forcement utiles en DBPro mais bon...)

C'est une solution que je conseille toujours aux débutants, puisque c'est par là que j'ai commencé.

Le seul adapté pour les jeux ...le c++...pour avoir une vitesse d'affichage  assez bien en FPS

Cela fait un moment que le C++ n'est plus le seul qui soit adapté. Que fais-tu du C# ?
Hey, même en DarkBASIC les jolies scènes avec pleins d'effets et de shaders descendent pas en dessous de 70 FPS.
Non le langage n'est plus vraiment un problème de nos jours, tant que tu es à l'aise avec.

Mais il faut acheter un livre de 1000 pages sur le c++...sinon ce n'est pas la peine de commencer

Objection !
Réfutation de l'idée reçue !
Pourquoi diable faudrait-il un bouquin de 1000 page sur le C++ pour commencer ? Au contraire, je trouve ça ridicule.

Oui j'ai ma bible du C qui tourne autour des 1000 pages dans mes étagères, mais elle fait office de référence, pas de bouquin d'apprentissage.

Il n'y a pas besoin d'avoir un livre pour apprendre le C++, ma méthode à été celle du "bon comment je peux faire ça en C++, sachant que je faisais comme ça en BASIC", puis ensuite "y'a pas une meilleure façon de faire ?".
C'est peut-être long, certes, mais à la fin on connait vraiment le langage pour s'être battu avec, et non avoir juste recopié dans l'IDE les concepts du bouquin sans vraiment comprendre leur intérêt.

Les exemples sont une mine d'informations...

Bien d'accord, j'utilisais déjà Irrlicht même sans connaitre le C++ tellement les exemples sont simples et la compilation aisée.
Faire la guerre à un moteur 3D simple peut être une bonne façon de découvrir les concepts du C++.

Le but est d'avoir un FPS qui tienne la route ...le reste c'est du pipeau...

Objection #2 !

Avoir un bon FPS est important, oui (quoique au dessus de 70, ça sert plus à rien), mais le reste c'est pas du pipeau.

Pour moi la priorité c'est que l'application soit bien construire, qu'elle soit facilement maintenable et évolutive, même si c'est au détriment du FPS. (et puis je rappelle que Shadow of the Colossus sur PS2 fait des pointes à 15 FPS et personne ne le remarque grâce au motion blur >_< )



Mais bref, de toute façon je déconseille à Mathieu le C++, si c'est un graphiste qui veut faire des jeux, s'emmerder avec la programmation est pas super...
Donc je lui conseille un langage simple, à la portée de tous, et orienté jeu : le DarkBASIC, voir le BlitzBASIC (mais je connais moins celui là).

Je réponds pas bien au sujet mais à ce que j'ai lu :
Je suis assez choqué de voir qu'il existe plein de moteurs OpenGL/DirectX (généralement OpenSource), des moteurs DirectX only mais pas de moteur OpenGL...
J'ai vraiment l'impression que les services de presse de Microsoft ont fait des merveilles de désinformation... Comme par exemple le fait que DirectX permet de faire des choses qu'OpenGL ne permet pas... C'est une énorme bêtise... Par exemple le Shader Model 4.0 est déjà disponible sur OpenGL depuis que les premières cartes l'exploitant sont sorties... Et ce sur Linux, Windows, ou n'importe quoi... Alors les gens qui clament que les Geometry Shaders sont l'exclusivité de DirectX10 sur Vista...

Aussi, au sujet du FPS :
On a longtemps dit qu'un fps de 60 devait être obtenu sur la machine de test. De nos jours ce n'est plus vrai.
Les développeurs bourrent leurs jeux d'effets en tout genre, ainsi un jeu comme Oblivion qui tourne souvent à 30 fps ne semble pas lagger du tout, ça fait presque même "professionnel" le lag maintenant.

DarkBASIC :
J'ai commencé par là et franchement je ne le conseille pas trop... Si quelqu'un n'a strictement aucune connaissance en programmation ça peut l'aider à comprendre comment marche un programme (avec les IF, WHILE, les booléens très importants...) mais ça donne de très mauvaises habitudes, dont il faut se débarasser après.

Apprendre le C++ :
Personellement, avec de ridicules connaissances en programmation, j'ai acheté un livre de 1000 pages, je n'ai suivi que les 500 premières mais ça m'a suffit pour comprendre assez vite... Un livre de 1000 pages peut très bien être un cours.

Tous les gens qui préfèrent programmer avec DirectX/OpenGL directement plutôt qu'avec Irrlicht :
Pur masochisme je trouve.
Pourquoi ? Tout simplement parce que si vous aimez tant utiliser ces deux APIs, allez plutôt modifier le code d'un moteur solide... Non seulement Irrlicht est rempli des connaissances de centaines de personnes au niveau physique, algo de partitionnement, gestion multi-plateforme... Mais en plus il est très facilement modifiable.
Je ne vois pas l'utilité de coder un moteur à zéro, si on aime les APIs bas niveau (c'est le cas pour moi avec OpenGL) autant modifier le moteur que l'on utilise, croyez-moi vous obtiendrez un très bon résultat !

Dernière modification par DeusXL (21-02-2007 07:27:04)

Le DarkBasic c'est bien pour faire mumuse, mais y'a pas pire niveau langage.Il est fourré de bugs et surtout de memory leaks, je parle par expérience car je viens de terminer le concours NVidia dessus, et le nombre incalculable de petits bugs qui m'ont fait chier deviennent vite pénible pour développer des applications propre.A la rigueur, je conseillerai plustôt le Blitz3D qui est peut être moins évollué niveau technique, mais qui à le mérite d'avoir moins de bugs et d'intégrer un langage plus propre et un peu moins merdique.
Comme le dis DeusXL, le FPS n'est plus le plus gros des soucis vu qu'on peut descendre jusqu'a 30, cela dit même si ça parrait assez fluide, je préfère me fixer une base à 60, cela me laisse une réserve pour être sûr que ça marchera à peu pret bien partout.
D'ailleurs sur mon livre de programmation DirectX9 le mec conseille carrément de se baser à 100 Fps, ce que je trouve un peu exagéré mais bon, comme je l'ai eu dit dans un post, chaques programmeurs à sa façon de coder et à ses propres bases.Le principal c'est qu'au final le rendu soit pas désagréable à l'oeil.