Bonsoir à tous, voilà, je cherche une bibliothèque pour python qui permets de faire de la 2D/3D. Je sais qu'il en existe tel que PyOgre, Py3D, PyQt4, PyGame,Soya, PyOpenGL et j'en passe, mais voilà, je ne sais pas ce qu'elles valent, alors j'aimerai que des membres me fassent par de leurs expériences avec ses bibliothèques si possible. Merci d'avance !
PS : Si quelqu'un a un bon tuto qui va avec ! Mais si y'a pas, c'est pas grave.
Tu pousses, je trouve qu'on en parle pas mal quand même.
Pygame, pyopengl, tu auras des mecs qui t'aideront c'est sûr. Pour ma part j'aime bien soya et pygame, mais les goûts et les couleurs tu sais, ça ne se discute pas!
J'ai beaucoup entendu parler de Soya comme une sorte de référence, à la fois complète et puissante. Après je n'ai jamais fait de tests par moi-même, mais j'ai cru comprendre que c'était un excellent choix.
Pour la 2D, Pygame et PySFML principalement, ça dépend un peu de ce qu'on recherche et de ses goûts.
Tu pousses, je trouve qu'on en parle pas mal quand même.
Pygame, pyopengl, tu auras des mecs qui t'aideront c'est sûr. Pour ma part j'aime bien soya et pygame, mais les goûts et les couleurs tu sais, ça ne se discute pas!
Biensûr que ça ne se discutent pas, c'est pour ça j'aimerai leur avis et en connaître le potentiel et me faire un avis final moi même. Des témoignages quoi. Par exemple maxibolt qui m'a parlé de Soya, toi aussi d'ailleurs tu m'as dis que tu avais une préférence pour Soya, donc ok, je vais faire des recherches sur Soya. Et pour être franc, ça m'a peut être mieux éclairé que ce que vous pensiez car moi, d'instinct j'aurais eu tendance à faire confiance à une bibliothèque qui commence par "py" ( je sais pas pourquoi, je l'avou )
salut,
je suis 100% pygame.
ok ... c'est plus bas niveau que tkinter par exemple, donc faut réinventer la roue que d'autres ont dejà reinventée...Genre les boutons cliquables, les menus, etc...
mais l'avantage c'est que tu réinventes la roue que tu veux ^^. c'est plus souple , plus facile à apprendre et plus facile à mettre en oeuvre.(ça n'engage que moi, hein)
Attention, ça n'a rien à voir. Pygame est une librairie 2D, TkInter est une librairie pour faire des GUI. Ce n'est pas la même chose. Tkinter n'est pas adapté à la création d'un jeu 2D, même si on peut en faire des très basiques de façon assez compliquée et peu satisfaisante, et Pygame n'est pas adaptée à la création de fenêtres avec des "boutons cliquables", même si on peut aussi en faire en réécrivant tout soi-même, pour arriver à un résultat moins bon et plus pénible à coder.
Citation
c'est plus souple , plus facile à apprendre et plus facile à mettre en oeuvre
Du coup ça tombe aussi, vu qu'on ne peut pas utiliser ces critères pour comparer deux outils qui ne font pas la même chose.
Sur le coup j'ai failli tombé amoureux de pygame, non j'abuse, mais j'étais prêt à faire une recherche, mais c'est vrai que je préférerais une biblio qui fait les deux, de préférence. Disons que j'aimerai par commencer avec l'option 2D d'un bibliothèque pour apprendre quelque base de celle-ci pour ensuite commencer la 3D petit à petit. Pas changer de bibliothèque et donc retrouver des fonctions totalement différente, même si je suis bien conscient qu'en prennant qu'une unique bibliohtèque j'aurais forcément des fonctions différente en passant de la 2D à la 3D
je préférerais une biblio qui fait les deux, de préférence
C'est une erreur. Une bilbio qui fait les deux, je n'en connais pas. Et qui fait les deux bien, je suis certain que ça n'existe pas. Et de toute façon la façon de penser les choses est différentes (c'est pour ça qu'il n'y en a pas une plus facile à apprendre qu'une autre : une fois qu'on comprend comment marche une GUI/un jeu 2D, il n'y a plus que des particularités, importantes peut-être, mais qui ne sont pas le gros de l'apprentissage).
Citation
Disons que j'aimerai par commencer avec l'option 2D d'un bibliothèque pour apprendre quelque base de celle-ci pour ensuite commencer la 3D petit à petit. Pas changer de bibliothèque et donc retrouver des fonctions totalement différente, même si je suis bien conscient qu'en prennant qu'une unique bibliohtèque j'aurais forcément des fonctions différente en passant de la 2D à la 3D
Ah d'accord, tu veux 2D et 3D en fait. Mon paragraphe précédent s'applique plus à 2D/GUI (GUI, c'est comme ton navigateur par exemple).
Mais pour 2D et 3D c'est pareil. Si je peux te donner un conseil, commence par la 2D, et ne te préoccupe vraiment pas de la 3D pour l'instant, je pense que c'est une mauvaise idée. Trouve toi une librairie 2D que tu aimes bien (Pygame par exemple) et apprend un maximum de choses. Quand tu connaîtras vraiment, tu pourras aller voir du côté de la 3D, avec quelque chose de vraiment fait pour (encore une fois, c'est pas le nom des fonctions qui va te poser problème).
Sur le coup j'ai failli tombé amoureux de pygame, non j'abuse, mais j'étais prêt à faire une recherche, mais c'est vrai que je préférerais une biblio qui fait les deux, de préférence. Disons que j'aimerai par commencer avec l'option 2D d'un bibliothèque pour apprendre quelque base de celle-ci pour ensuite commencer la 3D petit à petit. Pas changer de bibliothèque et donc retrouver des fonctions totalement différente, même si je suis bien conscient qu'en prennant qu'une unique bibliohtèque j'aurais forcément des fonctions différente en passant de la 2D à la 3D
une fenêtre pygame peut servir de support à rendu pyopengl.
comme l'a dit Maxibolt, ça dépend si tu veux faire du GUI ou pas.
voilà un exemple de code, livré avec la lib pygame dans le module 'example'...
un cube qui tourne sur lui-même.
#!/usr/bin/env python
"""Draw a cube on the screen. every frame we orbit
the camera around by a small amount and it appears
the object is spinning. note i've setup some simple
data structures here to represent a multicolored cube,
we then go through a semi-unopimized loop to draw
the cube points onto the screen. opengl does all the
hard work for us. :]
"""
import pygame
from pygame.locals import *
try:
from OpenGL.GL import *
from OpenGL.GLU import *
except:
print ('The GLCUBE example requires PyOpenGL')
raise SystemExit
#some simple data for a colored cube
#here we have the 3D point position and color
#for each corner. then we have a list of indices
#that describe each face, and a list of indieces
#that describes each edge
CUBE_POINTS = (
(0.5, -0.5, -0.5), (0.5, 0.5, -0.5),
(-0.5, 0.5, -0.5), (-0.5, -0.5, -0.5),
(0.5, -0.5, 0.5), (0.5, 0.5, 0.5),
(-0.5, -0.5, 0.5), (-0.5, 0.5, 0.5)
)
#colors are 0-1 floating values
CUBE_COLORS = (
(1, 0, 0), (1, 1, 0), (0, 1, 0), (0, 0, 0),
(1, 0, 1), (1, 1, 1), (0, 0, 1), (0, 1, 1)
)
CUBE_QUAD_VERTS = (
(0, 1, 2, 3), (3, 2, 7, 6), (6, 7, 5, 4),
(4, 5, 1, 0), (1, 5, 7, 2), (4, 0, 3, 6)
)
CUBE_EDGES = (
(0,1), (0,3), (0,4), (2,1), (2,3), (2,7),
(6,3), (6,4), (6,7), (5,1), (5,4), (5,7),
)
def drawcube():
"draw the cube"
allpoints = zip(CUBE_POINTS, CUBE_COLORS)
glBegin(GL_QUADS)
for face in CUBE_QUAD_VERTS:
for vert in face:
pos, color = allpoints[vert]
glColor3fv(color)
glVertex3fv(pos)
glEnd()
glColor3f(1.0, 1.0, 1.0)
glBegin(GL_LINES)
for line in CUBE_EDGES:
for vert in line:
pos, color = allpoints[vert]
glVertex3fv(pos)
glEnd()
def main():
"run the demo"
#initialize pygame and setup an opengl display
pygame.init()
pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
glEnable(GL_DEPTH_TEST) #use our zbuffer
#setup the camera
glMatrixMode(GL_PROJECTION)
gluPerspective(45.0,640/480.0,0.1,100.0) #setup lens
glTranslatef(0.0, 0.0, -3.0) #move back
glRotatef(25, 1, 0, 0) #orbit higher
while 1:
#check for quit'n events
event = pygame.event.poll()
if event.type == QUIT or (event.type == KEYDOWN and event.key == K_ESCAPE):
break
#clear screen and move camera
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)
#orbit camera around by 1 degree
glRotatef(1, 0, 1, 0)
drawcube()
pygame.display.flip()
pygame.time.wait(10)
if __name__ == '__main__': main()
Been... Dans tout jeu qui se respecte il y a une interface, donc de la GUI, comment on peut concevoir un jeu sans GUI ? oO
@josmiley : Tout ça pour un cube qui tourne Ca fait beaucoup, m'enfin, en même temps le cube est créé point par point.
Effectivement, littéralement, il y a de la GUI dans un jeu. Quand je parlais de GUI (et quand on en parle en général), c'est plus des fenêtres avec des menus en haut, des cases à cocher... Ce qu'on a l'habitude de faire avec Qt ou TkInter par exemple, ce que tu vois dans ton navigateur, dans ton client mail préféré. Ça utilise des concepts plus poussés et plus complexes qu'un simple menu de jeu, où un clic t'amène sur la section correspondante du programme (on peut aussi avoir des cases à cocher, des barres de défilement, tout ça, mais ça reste plus simple que ce qu'on peut faire avec une librairie comme Qt).
Sinon, un code OpenGL est souvent effectivement assez volumineux. La philosophie de la librairie est très différente de celle de Soya par exemple, qui est un moteur 3D. En soya, on aurait probablement quelque chose comme "import soya, dessiner cube (taille, origine, couleur), afficher scène" (je simplifie beaucoup mais ce serait dans cet esprit). En OpenGL, on te laisse dessiner le cube toi même. L'esprit est juste différent, il n'y en a pas un qui est plus complet que l'autre (d'ailleurs, quand on programme un jeu, on commence souvent par recoder son propre soya avec OpenGL ou quelque chose d'équivalent). La page Wikipédia Moteur 3D te donner quelques informations dessus (particulièrement la courte partie valeur ajoutée).
Enfin, bravo pour avoir essayé de comprendre le code qu'on t'a donné au lieu de juste constater qu'il avait l'air gros et compliqué, c'est comme ça que tu progresseras le mieux.
Ouais j'avais déjà vu du code openGL en C, c'était la catastrophe pour ouvrir une simple fenêtre.
Sinon merci oui, je pensais pas que c'était tant d'honneur d'avoir essayer de comprendre un code, je vais la jouer franc : oui j'ai essayé de pigé quand même, voir comment ça marchait, pas curiosité et savoir à quoi s'attendre, mais, je m'en voudrais de pas dire que josmiley l'a dis en donnant le code qu'il s'agissait d'un cube qui tournait autour de lui :$
Mais c'est encourageant
Sinon pour répondre auquel type de jeu je voudrais commencer, ben, enfaite, ce qui m'a poussé c'était le TP bien présenté de quelqu'un sur le forum python, celui du démineur :/ Je m'étais toujours dis que ca devait être un mal de chien à coder ça, mais quand j'ai vu le TP j'ai eu quelque idée pour commencer que j'aimerai bien exprimer.
Sinon pour le lien wikipédia, ouais je sais bien que les grands jeux recodent leur propre moteur graphique. Il me semble que j'avais déjà posé la question sur le SDZ de quel moteur graphique les grands jeux se servaient et que quelqu'un m'ait répondu qu'ils les codaient eux même ? Ou bien... On me l'a dit dans un autre topic que j'ai créé, ou alors je l'ai lu sur google, enfin bref je m'éternise
En tout cas maintenant je saurais que quand les gens parlent de GUI, ils pensent pas forcément aux interfaces dans les jeux, mais qu'ils ciblent plutôt les biblio du genres Qt. J'avais un doute mais bon :/
oui, je pensais pas que c'était tant d'honneur d'avoir essayer de comprendre un code, je vais la jouer franc : oui j'ai essayé de pigé quand même, voir comment ça marchait, pas curiosité et savoir à quoi s'attendre, mais, je m'en voudrais de pas dire que josmiley l'a dis en donnant le code qu'il s'agissait d'un cube qui tournait autour de lui :$
Mais c'est encourageant
Ce qui est bien, c'est d'avoir essayé de comprendre "comment il marchait", pas "ce qu'il faisait". C'est en lisant des sources que tu apprendras le mieux, et quand on lit des sources, on sait en général déjà à quoi elles servent. C'est suffisamment rare de voir quelqu'un avoir cette attitude, alors ça mérite d'être signalé, tant pour t'encourager que pour inciter les autres à le faire.
Citation
Sinon pour répondre auquel type de jeu je voudrais commencer, ben, enfaite, ce qui m'a poussé c'était le TP bien présenté de quelqu'un sur le forum python, celui du démineur :/ Je m'étais toujours dis que ca devait être un mal de chien à coder ça, mais quand j'ai vu le TP j'ai eu quelque idée pour commencer que j'aimerai bien exprimer.
On a souvent l'impression que les programmes simples vont être très difficiles à coder, jusqu'à ce qu'on découvre qu'en fait, une fois qu'in a les bons outils, ça se fait. Le danger est plutôt d'être persuadé qu'un "MMORPG en 3D" est facile à réaliser et de se décourager dès qu'on voit les premières difficultés.
Le démineur est à mon avis un jeu un peu bâtard, au sens où, en pratique, il est souvent programmé avec une librairie comme TkInter (pour l'exemple). C'est par exemple le cas du démineur Windows, qui est une sorte de GUI trafiquée. On pourrait parfaitement en coder un avec une bibliothèque 2D comme Pygame, mais souvent ce n'est pas le cas. Je t'invite à essayer si ça t'intéresse, tu pourras y apporter ce que tu ne peux pas faire avec quelque chose comme Tk.
Sinon, tu peux faire un Sokoban, c'est un jeu relativement simple à coder, et comme M@teo21 le présente dans son cours officiel, tu peux t'inspirer de la solution et la transposer en Python (il utilise la SDL, Pygame est l'équivalent Python).
Ensuite, tu peux t'intéresser aux jeux qui font intervenir le temps, ce qui engendre de nouvelles problématiques comme celles du mouvement (pour un sokoban, pas de problème, c'est case par case et chaque déplacement élémentaire est instantané. Comment faire pour un mario ou un snake ?).
Ensuite, si tu es toujours motivé, tu pourras commencer à aborder la 3D, qui apporte encore son lot de problèmes à résoudre.
Et surtout, n'hésite pas à venir nous dire où tu en es ou à poser des questions.
En tout cas merci pour tout ses encouragements
Sinon ben, un MMORPG 3D, finalement, rien que de se dire les ressources qu'il faut : c'est à dire graphisme/code : gestion déplacement, collision et gravité/les sons et musiques, sans parler du site web pour se faire connaître/télécharger le jeu, etc.
Ca parait déjà impossible seul
Bon je vais mettre en résolu et dès que j'ai un week end j'attaque, merci à vous !
Sinon j'avais pas pensé au sokoban, moi qui ai toujours voulu faire un éditeur de niveau
Juste trois légères questions :
-Il faut déjà connaître la SDL pour pygame ?
-Cette fois ci peu importe la bibliothèque utilisé : il est possible qu'il y ait des "incompatibilité" avec les versions ? J'utilise python 3
-J'ai trouvé sur le site officiel ( site officiel que j'ai trouvé avec josmiley ), deux tutoriels qui semblent différent, mais je vois pas trop... pourquoi ils en ont fait deux différents, si quelqu'un peut m'éclairer ? lien 1 lien 2
traduction de la documentation de pygame
disons que si on connait un peu le fonctionnement de SDL, ça aide à mieux piger pygame.
le lien 1 c'est la doc officielle dont tu as la traduction en lien ci-dessus.
le lien 2 c'est des tutos des membres.
-J'ai trouvé sur le site officiel ( site officiel que j'ai trouvé avec josmiley ), deux tutoriels qui semblent différent, mais je vois pas trop... pourquoi ils en ont fait deux différents, si quelqu'un peut m'éclairer ?
lien 1
lien 2
Les deux te serviront.
Citation
-Il faut déjà connaître la SDL pour pygame ?
Absolument pas, tout (bon ok presque tout) est expliqué dans ces tutoriels. Regarde aussi du côté de Wikibook, il y a un tutoriel sur Pygame.
Le seul problème, c'est qu'ils restent trop succinct, ils ne vont pas au fond des choses. Nohar entreprend de faire un tutoriel là-dessus, il se pourrait que quelques chapitres ne tardent pas à partir en validation, patience .
Non, pas la peine de connaître SDL pour connaître Pygame. C'est comme si tu demandais s'il fallait connaître Qt pour utiliser PyQt : c'est deux version différentes de la même chose (en simplifiant). Par contre, apprendre Pygame en suivant un tuto SDL et en adaptant peut être une bonne idée : si tu es fan d'ici, j'ai personnellement appris (les bases) avec le cours de M@teo21. Après, il va falloir se farcir la doc, parce que Pygame est plus qu'un simple binding de la SDL pour python. Mais une fois que tu as commencé à l'apprivoiser, c'est à mon avis plus simple.
Très bien merci pour vos réponses et les précisons, j'ai hâte aussi mais je vais essayer sans
Les bibliothèques 2D/3D en python !
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Python c'est bon, mangez-en.
Python c'est bon, mangez-en.
Python c'est bon, mangez-en.
Python c'est bon, mangez-en.
Python c'est bon, mangez-en.