Meilleur façon de faire de la 2D sur PC ?

[Risike]

Voici une question que je me pose souvent. Quelle est le meilleur langage et la meilleure bibliothèque pour faire de la 2D sur PC ? Je parle du rapport (simplicité et ergonomie) / performances. Pas de trolls entre pro .NET ou JAVA d'un côté et nerds sectaire accro au C++ de l'autre SVP.

Les cartes graphiques d'aujourd'hui ne permettent pas d'afficher de la 2D si j'ai bien compris. Tout est de la 3D sur un seul plan. Théoriquement une machine comme la DS est donc bien plus puissante en 2D qu'un PC de fou. L'hardware gère l'affichage de sprites, de background, gère le scrolling, le scalling, les rotations...Etc. Ce que ne sait pas faire un PC sans logiciel.

Jusqu'à peu, je ne jurais que par Python + pygame + ma surcouche perso qui me permet d'afficher des sprites animés en 2 lignes et des maps en 2 lignes. C'est ultra simple, c'est orienté objet, c'est plein de librairies excellentes, on écrit très peu de lignes pour faire beaucoup de choses. Mais je me suis rendu compte en essayant d'afficher une grosse map de plusieurs centaines de tiles, que je ne n'arrivais pas à avoir un framerate constant honorable (60 fps). Donc impossible par exemple de développer un danmaku (c'est pas dans mes projets je vous rassure) dans une résolution sympa (720p par exemple), même avec une machine de compèt' ! Python ne suit pas... Et la SDL qui sert à afficher les graphismes non plus... Forcément, quant on multiplie les couches...

On a aussi des librairies foireuses en JAVA censés afficher de la 3D (donc de la 2D aussi), qui sont over-merdiques...

On a la solution de passer par du C/C++ et d'utiliser une librairie graphique. Mais franchement, utiliser un langage aussi bas-niveau pour afficher de la 2 c'est utiliser un bazooka pour flinguer une mouche ! Quant au librairie je ne m'y connais pas. J'ai essayé la SDL et les performances sont honorables mais pas excellentes. Et la syntaxe est très lourde.

Il reste la solution du XNA censé simplifier grandement la vie des développeurs. Que nennie !!! C'est bien plus complexe que pyame. Certes c'est plus performant et l'IDE (Visual Studio) et carrément énorme. Mais la syntaxe n'a rien d'innovante (contrairement ce que M$ avait annoncé) et les projets ne peuvent être portés sur d'autres OS.

Sinon le premier qui me dit Flash je lui fourre un lampadaire dans le c** !

EDIT : je n'ai jamais essayé DirectX, ça vaut quoi ?

[Gunny]

directx ou openGL en couple avec c/c++, c'est le plus répandu, ca doit surement pas etre juste une question de nerd accroc pro élitiste.

D'un point de vue performance entre les deux, c'est le développeur qui fait la différence. Les deux ont leurs points faibles et leurs points fort.
Sachant qu'openGL permet une plus grande portabilité.

C'est surtout une question de gout quand la portabilité n'est pas un critère de dév.
De toute facon, les deux sont des usines à gaz ^^

directx et openGL ne font pas que du graphisme... y a les inputs, et tout un tas d'autre truc.

Y en a qui utilisent du basic aussi ( mais lequel je sais plus... )

[Risike]

Je trouve ça con d'utiliser des librairies aussi complexes pour faire "juste" de la 2D alors que dans certains langage, pour afficher un sprite on a une ligne pour le charger et une ligne pour l'afficher. Là sans notion de 3D (vecteurs, matrices...etc) on ne peut même pas afficher un sprite... A moins qu'il n'existe une librairie pour faire de la 2D sans se faire chier avec OpenGL ou DirectX mais je doute.

Mame utilise quoi au fait ? DirectX ?

[Gunny]

Bhaaaaaaaaaaaaaaaaaaa.

Chope des vieux DX6/7 ou vieux openGL ^^
Par contre, tu va être limité en effet graphiques "évolués" ( je pense notement au cell shading, particules )

Mais c'est vrai qu'en amateur ( le projet pas la personne ), faire appel a du openGL ou Dx, c'est utiliser une turbine d'avions pour passer l'aspirateur...

C'est aussi la faute des constructeur... Je peux meme plus jouer convenablement à un monkey island sous XP alors que sous windows 2000 j'ai aucun soucis...

Un problème de drivers et ca, on ne peut l'empécher...
Si tu tourne sous XP vista ou seven, je te recommande chaudement de tester sous 2000 ou linux qui devraient eux, avoir une gestion native de la 2D et pas utiliser des couches et surcouches logiciel et faire appel en plus à Dx pour juste afficher des fenetres ( et pourtant, les grosse CG sont capable de faire de la 2D et correctement en plus ! dingue la différence de perf sur jeux 2D quand je passe de 2000 à XP et ca, c'est le techicien réseau informatique qui le dis pas le développeur geek pro élitiste du C )

[niluge]

Si tu veux faire simple en C/C++, il y a Allegro aussi. Une antique librairie qui marche aussi bien sur linux que sur Windows. Tu rajoute un fmod pour le son et c'est bon ^^

Ne developpant pas en C a la maison depuis quelques temps, je ne pourrais pas trop te dire ce que ça vaux niveau perf, mais c'est simple, robuste ,c'est compilé et relativement portable.

[Onaryc]

Perso, c'est c++/SDL/OpenGL pour mon framework de jeu 2D (enfin le projet perso que je finirais jamais ).

Pour l'instant j'affiche juste des rectangles sans texture (l'équivalent du sprite quoi), mais je ne pense pas que ce soit extrêmement compliqué à faire...

En utilisant des lib 3D pour faire de la 2D tu bénéficies aussi de certains avantages :
* Déformation de sprite (zoom, rotation, ...), profondeur, ajout de ptits effets 3D sympa possible (lumière, ...), beaucoup de doc, ...
* Pour la gestion de la physique/collision, y a Box2D (pour l'instant je l'ai pas intégré mais les démos fournies sont vraiment sympa).
* accélération matérielle (à voir si c'est vraiment utile...)
* ...

Côté simplicité, je ne connais pas très bien python mais je développe en tcl/tk au boulot et c'est sûre que c++/SDL/OpenGL, c'est plus verbeux, le c++ il faut être... rigoureux mais c'est pas forcément super compliqué non plus...

[Gunny]

Sinon, gamemaker est créé en delphi.
Ce qui plombe les perfs, c'est que c'est un langage scripté pour codé les jeux et non compilé ( par contre, il faut voir ce que certains sont capable de faire avec gamemaker en connaissant bien les optimisations possibles )

Gamemaker utilise Dx et il est question qu'il passe à openGL pour une question de portabilité ( macOS, linux )

[Risike]

Ce qui plombe les perfs, c'est que c'est un langage scripté pour codé les jeux et non compilé

Dans le cas de python + pygame ça joue mais dans d'autres cas non ! Ce qui coûte cher en temps c'est les appelles de fonctions.
J'ai adapté LUA sur DS en y ajoutant des tonnes de fonctions dont le graphisme 2D. Si à chaque boucle je faisais un appel à chaque fois que je voulais afficher une image, j'en affichais max une cinquantaine. Après j'étais limité à cause de la "machine virtuelle" de LUA qui trainait. Mais pour afficher une Map de centaine de tiles, il me suffisait d'apperl une seule fonction par boucle (genre DrawMap(paramètres)) et des centaires d'images étaient affichées sans perte de performance. Je suis monté à 1600 images à 30FPS, ce qui est la limite hardware (quand on passe par de la 3D). J'avais donc les mêmes performances graphiques que si j'affichais ça en C.

Je pense que si avec pygame on utilise toutes les librairies de base (sans passer par du code perso pour animer les sprites par exemple), on peut avoir de très bonnes perfs ! Mais si c'est pour avoir du code qui ressemble à du C + SDL...

Bon je crois qu'il vaut mieux développer sur Neo Geo et faire tourner Mame

[yenshin]

humm je sais pas trop quoi te dire car je dev un danmaku en python et je constate vraiment peu de probleme de performance.

Je n'utilise pas de planche (tiles si j'ai bien compris) toutes mes images sont séparées et loadées juste une foie au demarrage du jeux avec leur mask associer.

Ce qui fait lagguer pygame a mort c'est le calcul du mask. A cause de ca au debut j'etais limiter a 300 sprite à 60 fps maintenant, je sais pas encore j'ai pas terminer mon module de cache si ca t'interesse je pourrai te donner les résultat une foi fini.

mais theoriquement ca devrait passer sans probleme.

a oui le multithread peux aider si jamais tu n'ya pas penser. ça complexifie pas mal les choses mais si tu gere bien le truc tu peux reelement gagne en fluidité.

[Risike]

Intéressant !

Qu'est-ce que tu appelles mask ? Là je ne connais pas !

[Gunny]

C'est la "hit box" dans le jargon des shooteux si je dis pas de bétise

[Risike]

Ahhh il parlait du masque de collision. J'avais pas pigé !
Ah ouais j'imagine que le calcul de collision entre le "héros" et toutes les boulettes ça doit pomper ! Faut un algo bien pensé...

[yenshin]

edit:
rien que calculer le mask de collision pour pouvoir plus tard tester si tu entre en collision avec un truc ca prend du temps
cette fonction (que j'utilise) prend du temps elle sert juste a cree un mask de collision
pygame.mask.from_surface()

une foi que ta les mask c'est rapide les calculs sont rapide a faire
vu que tu n'est pas censé le rechargé a chaque foi.

fin edit


ouaip carrement il te faut un bon algo, moi pour simplifier le truc je calcul le mask de toutes les images a la creation du jeux, ca evite de les recalculer in game.

mais bon comme je te l'ai dit c'est en cours ^^ je ferai un test de perf une foi qu'il sera terminer (l'algo),je devrai pouvoir faire tourner le jeux bien vite.

Ensuite pense que si tu utilise la même image souvent (boulette par exemple) il faut charger l'image qu'une seul foi (dans l'ideal) car charger une image ca prend du temps.

une foi que ta un objet qui gere tout, image et mask ta juste a faire pointer tes sprites
vers ces images, comme ca les images sont indépendante du sprite.

gain de perf absolument enorme.

mais du coup il faut que tu conçoive ton code en conséquence, tu peux difficilement partir à l'arrache.

un uml(ou un dessin perso qui represente ton code) ça aide.

[niluge]

Question bête pour tes masques de collision (je suppose donc que tu fait du pixel perfect, sinon je ne vois pas l'intérêt) :
Pourquoi tu ne les pré calculerais pas une fois pour toute, les sauvegarderais dans un fichier binaire une fois pour toute que tu n'aurait plus qu'a charger au lancement du jeux ?

Sinon, pour du danmaku avec masque de collision réduit, je pense qu'une simple hitbox rectangulaire ferait tout aussi bien l'affaire. Le calcul d'intersection est simple et rapide, et de toute façon tu es déjà obligé de le faire pour ton algo pixel perfect (enfin pas tant obligé que ça, mais si c'est un minimum optimisé... ^^) Donc tu ne peux que gagner en perf (et augmenter le nombre de boulette yeahhhhh)

[yenshin]

Question bête pour tes masques de collision (je suppose donc que tu fait du pixel perfect, sinon je ne vois pas l'intérêt) :
Pourquoi tu ne les pré calculerais pas une fois pour toute, les sauvegarderais dans un fichier binaire une fois pour toute que tu n'aurait plus qu'a charger au lancement du jeux ?

Et bien c'est simple les graphismes sont loin d'être fini, on prototype tout ca on test c'est la merde, du coup autant charger à la voler au lancement du jeux.

Code : Tout sélectionner

Sinon, pour du danmaku avec masque de collision réduit, je pense qu'une simple hitbox rectangulaire ferait tout aussi bien l'affaire. Le calcul d'intersection est simple et rapide, et de toute façon tu es déjà obligé de le faire pour ton algo pixel perfect (enfin pas tant obligé que ça, mais si c'est un minimum optimisé... ^^) Donc tu ne peux que gagner en perf (et augmenter le nombre de boulette yeahhhhh)

bien pour le joueur oui effectivement un ptit carre c'est cool. Par contre contre les enemy c'est plus cool de pouvoir toucher de n'importe quel petit bout de pixel, mais c'est pas encore figé, je ferai ça une fois que j'aurais tous les graphisme pour l'instant je reste sur du chargement a la vole (juste au demarrage du jeux)
Et puis les boulettes c'est sympa aussi si TOUT le sprite peux t'avoir.

Bon c'est un avi perso mais je changerai ptet d'avi d'ici deux semaine quand j'aurai fait un test de charge de bullet hehehe

[Henes]

Bhaaaaaaaaaaaaaaaaaaa.

Chope des vieux DX6/7 ou vieux openGL ^^
Par contre, tu va être limité en effet graphiques "évolués" ( je pense notement au cell shading, particules )

En fait une particule = un triangle ou un point... Difficile de faire plus basic :)

[-SGN-]

Excellent topic

Je me permets juste de glisser ceci trouvé sur danstonchat (ex bashfr):

<mimi> comment on fait pour faire un jeux video
<sebastienb> mmm
<sebastienb> tu le programme tu fais les graphismes les sons les scripts et tu assemble tout
<sebastienb> et ca fait un jeu
<mimi> mais on click ou

[Y^nO]

Excellent topic

Je me permets juste de glisser ceci trouvé sur danstonchat (ex bashfr):

<mimi> comment on fait pour faire un jeux video
<sebastienb> mmm
<sebastienb> tu le programme tu fais les graphismes les sons les scripts et tu assemble tout
<sebastienb> et ca fait un jeu
<mimi> mais on click ou

Ca fait du bien tiens.

[chaos]

Tien un topic que je n'avais pas vue . Pour les 2D lovers il y a SFML qui est dispo pour C/C++ et .NET(pour les manchots mh mh) ! C'est une jolie librairies qui interface OpenGL et permet de d'afficher des sprites en une dizaine de ligne.

C'est simple on ouvre la fenêtre, on charge les images , on démarre la boucle et on affichage les images chargées.


http://www.sfml-dev.org en plus la doc est dispo en français ! (en même temps c'est développé par un français !)

[djvinc]

C + SDL, c'est ce qui est utilisé dans Stepmania par exemple (source disponible).
Je ne comprends pas trop pourquoi le C te rebute par rapport à un autre langage ? Avec les bonnes librairies pour gérer les trucs pénibles (allocation mémoire, chaînes de caractères...), c'est rapide à utiliser, et au moins ça ramera pas à la fin..

[Risike]

Pour faire un petit jeu 2D, je trouve ça complètement inutile d'utiliser un langage aussi bas niveau que le C (pourquoi pas l'ASM tant qu'à faire !). Sur console ok, si je voulais faire un jeux bourrin ok, mais franchement, coder un jeux 2D sur un PC récent ne nécessite pas beaucoup de mémoire.

Et puis se faire chier pour gérer les fichiers, les collections...etc alors que dans d'autres langages tu le fais en 4 fois moins de code, et 8 fois moins de temps... même si tu maitrises les deux... Sans parler des probables soucis d'allocation de mémoire...Etc.

[yenshin]

yop voila le moteur de jeux 2D sur lequelle je taf il est en python avec pygame uniquement. (je l'ai rajouter en edit dans mon topic, shmup indépendant)
C'est une version de dev donc ya rien, le niveau n'est pas construit c'est juste pour tester la réactivité du moteur tout ca, dès que je peux j'attaque la partie son car ça manque vraiment.


lien:


http://www.youtube.com/watch?v=Xk04MvR5TaA&sns=em

[MsK`]

Les cartes graphiques d'aujourd'hui ne permettent pas d'afficher de la 2D si j'ai bien compris. Tout est de la 3D sur un seul plan. Théoriquement une machine comme la DS est donc bien plus puissante en 2D qu'un PC de fou. L'hardware gère l'affichage de sprites, de background, gère le scrolling, le scalling, les rotations...Etc. Ce que ne sait pas faire un PC sans logiciel.

Pure connerie, même en théorie la DS se fait éclater par n'importe quel PC possédant un GPU. Le GPU est capable de rasterizer des millions de triangles texturés, si tu veux afficher un sprite, t'affiches 2 triangles texturés et basta, tu veux du scrolling, scaling rotation ? multiplie les coordonnées de ton triangle par la matrice qui va bien et t'auras même plus. Tu veux afficher un BG ? au choix, un gros quad (enfin 2 gros triangles), un tas de quads si tu veux tiler, un quad fullscreen avec un shader de mode 7 si ça t'amuses.
Pour rappel, la DS c'est 128 sprites par ligne, avec des tailles très limitées. (64x64 maxi)
Ah, et le PC fait tout ça en full HD.

Je te conseille de mieux regarder du côté d'XNA, c'est ce qu'il y a de plus simple pour tirer partie correctement d'une machine moderne. (c'est comme direct3d mais en plus user friendly)
Et : OUI, ce n'est pas simple.

[Gunny]

Il te reste la solution Game Maker.
Alors oui, c'est pas un moteur 2D du feu de dieu configurable comme on veut...
Mais il permet de faire de très bonne choses.

Le langage de script est relativement simple, et tu ne te prend pas la tête avec les allocation mémoire comme tu as pu t'en plaindre avec le C un peu au dessus

( J'ajouterai que le C n'est pas un langage bas niveau vu qu'il ne peut-être directement interprété par la machine au contraire du binaire ^^ )

Il est utilisé par une large communauté, et certains jeux commerciaux "indie" sont fait avec ca. Et bientot, il y aura un gamemaker pour mac ! ( donc la possibilité d'etre multi-plateforme, il y a une RC mac de gamemaker 7 )

[niluge]

Pas bas niveau le C ??? En info, il n'y a pas l'asm et le haut niveau non plus, c'est un peu moins manichéen que ça tout de même. Faut pas oublier qu'en C, selon comment est configuré ton compilo, tu peux aller taper direct dans la mémoire video par exemple (c'est d'ailleurs comme ça qu'on faisait a l'époque du VGA. Routine asm pour passer en mode 13h et ensuite hop un pointeur sur la mémoire vidéo en rentrant la bonne adresse au format hexa hein, pas un truc préprogrammé... Ahhhh le bon vieux temps ).

Le C EST un langage bas niveau. Un peu moins que l'asm c'est sur, mais beaucoup plus que les java, C#, python etc. Ce n'est pas pour rien que la plupart des drivers et programme embarqué sont fait en C (même si souvent couplé avec un peu d'asm; mais pas forcément). Bon après il y en a qui font de l'embarqué avec du java mais ça c'est autre chose (java card par exemple. Pas top comme techno niveau performance d'ailleurs)

[Risike]

Et bientot, il y aura un gamemaker pour mac ! ( donc la possibilité d'etre multi-plateforme, il y a une RC mac de gamemaker 7 )

Pour être poli : je m'en bat la race des utilisateurs de mac...

[niluge]

Rohhhh spice de méchant va... N'empeche, quand tu as un mac (comme c'est mon cas) t'es bien comptant qu'on pense a toi. Je pense que ce doit être la même chose pour les linuxiens. Il n'y a pas que crosoft et windows dans le monde boudiou. Il y a de la place pour les autres. Vive la concurrence tout ça ^^
(Bon en même temps je peut pas encaisser la politique de mac sur les i-phone/pod ne me prenez pas pour un steve jobs sexuel non plus)

[djvinc]

Pour faire un petit jeu 2D, je trouve ça complètement inutile d'utiliser un langage aussi bas niveau que le C (pourquoi pas l'ASM tant qu'à faire !). Sur console ok, si je voulais faire un jeux bourrin ok, mais franchement, coder un jeux 2D sur un PC récent ne nécessite pas beaucoup de mémoire.

Et puis se faire chier pour gérer les fichiers, les collections...etc alors que dans d'autres langages tu le fais en 4 fois moins de code, et 8 fois moins de temps... même si tu maitrises les deux... Sans parler des probables soucis d'allocation de mémoire...Etc.

C'est ton impression, mais ce n'est que partiellement vrai : les codeurs professionnels ont une réponse par rapport à ce que tu dis : les librairies. Tu te doutes qu'ils ne gèrent pas tout à la main en utilisant les fonctions de base de la libc, ou des fonctions natives style win32, ou autre.
C et C++ sont hyper souples pour définir/surcharger des opérateurs, afin de traiter, avec les bonnes librairies, l'ensemble des cas que tu décris ci-dessus.
Ok au final ça peut être un peu cryptique et il est préférable de savoir ce qui se passe derrière, mais C, C++, avec les bonnes librairies et les bonnes surcharges d'opérateurs, sont, je pense, plus puissants et simples à utiliser que n'importe quel langage haut niveau de logique similaire (i.e. pas orienté liste style lisp, etc.)
Ce n'est pas pour rien que c'est encore (très) largement utilisé... Le seul pré-requis c'est de s'y mettre, et aussi de ne pas rester sur préjugés.

Pour la 2D, je n'ai pas compris ton délire, ça se fait très bien sur PC et par les cartes graphiques même modernes. Après que ce soit de la vraie 2D, et les performances brutes en 2D comparées à du hardware d'avant, c'est un autre débat, et à moins de vouloir faire du pixel art à l'ancienne ce n'est pas un débat.

[psychogore]

Pour faire un petit jeu 2D, je trouve ça complètement inutile d'utiliser un langage aussi bas niveau que le C (pourquoi pas l'ASM tant qu'à faire !). Sur console ok, si je voulais faire un jeux bourrin ok, mais franchement, coder un jeux 2D sur un PC récent ne nécessite pas beaucoup de mémoire.

Et puis se faire chier pour gérer les fichiers, les collections...etc alors que dans d'autres langages tu le fais en 4 fois moins de code, et 8 fois moins de temps... même si tu maitrises les deux... Sans parler des probables soucis d'allocation de mémoire...Etc.

C'est ton impression, mais ce n'est que partiellement vrai : les codeurs professionnels ont une réponse par rapport à ce que tu dis : les librairies. Tu te doutes qu'ils ne gèrent pas tout à la main en utilisant les fonctions de base de la libc, ou des fonctions natives style win32, ou autre.
C et C++ sont hyper souples pour définir/surcharger des opérateurs, afin de traiter, avec les bonnes librairies, l'ensemble des cas que tu décris ci-dessus.
Ok au final ça peut être un peu cryptique et il est préférable de savoir ce qui se passe derrière, mais C, C++, avec les bonnes librairies et les bonnes surcharges d'opérateurs, sont, je pense, plus puissants et simples à utiliser que n'importe quel langage haut niveau de logique similaire (i.e. pas orienté liste style lisp, etc.)
Ce n'est pas pour rien que c'est encore (très) largement utilisé... Le seul pré-requis c'est de s'y mettre, et aussi de ne pas rester sur préjugés.

Pour la 2D, je n'ai pas compris ton délire, ça se fait très bien sur PC et par les cartes graphiques même modernes. Après que ce soit de la vraie 2D, et les performances brutes en 2D comparées à du hardware d'avant, c'est un autre débat, et à moins de vouloir faire du pixel art à l'ancienne ce n'est pas un débat.

Petit HS, parceque le sujet m'en donne l'occasion : en français, le mot anglais "libraries" (pluriel de library), se traduit par bibliotheques. C'est un detail, mais cet abus de langage se generalise, et c'est dommage.

[djvinc]

En même temps, tous les développeurs disent ça depuis plus de 20 ans... désolé pour les académiciens
En théorie, on dit "fiche", et pas "fichier" ! Un fichier, c'est plus un répertoire qui contient des fiches !!