Open Game Creator

master47 a écrit:

vivicool a écrit:

merci c'est gentil
D'ailleur c'est un projet open-source donc quand il sera fini je publirai tout mais petit fichier cpp et h.

HAHAHAHA répète-moi ça?

Le jour où tu publie les sources d'un tel projet sans copyright, je peux te dire que j'en met un dessus et je me fais plein de thune sur ton dos.

Sois sérieux un peu

um... c'est certain (dumoins j'espère pour lui) qu'il parle de le publier avec une licence GNU GPL (ou peu importe le nom exact) qui dit que t'as pas le droit de foutre un copyright dessus, d'le vendre, etc... Ça m'étonnerait quand même qu'il compte distribuer ça sans license, sinon c'est sûr que c'est pas trop fort.

Pis euh, gm8 compatible Wii? Ça m'étonnerait quand même qu'un programme commercial comme GM se mette dans la scène homebrew Wii que Nintendo n'aime pas... Où t'as vu ça?

vivicool a écrit:

Voila ça fait un certain temps que j'ai pas posté donc je vais faire plusieur réponse en une. Bon la raison pour la quelle je fait ce programme... Bin je sais pas trop, en même temps on va ajouter des fonction qui sont pas dans gm et qui seront pas dans gm8 et puis la programmation ce fesant en C++ il y a certaine possiblilitée qui s'ouvre. Sinon pour le rendu SDL merci de l'info, je savais pas, mais enfaite je pense pas qu'on va utiliser SDL, vu que je maitrise de plus en plus Qt je me rend compte que ce serai bien mieu de l'utiliser pour le rendu, ça permetrait par exemple d'avoir un canal alpha aux sprites. Fin bon voila quoi... Pour l'instant je programme la création de room (c'est pas de la tarte), ensuite je vais voir pour la compilation mais à mon avis ce sera pour juillet. A oui pour l'open source, il a plein plein de programme open source et je crois qu'il y a jamais eu de vole de code fin bon étant donné que je suis sur l'OS du pinguoin pour moi ça me semble normale de distribuer les source (même pour un logiciel payant, si si ça ce fait)
Sur ce bonsoir (ou bon matin, je sais pas trop)

Utiliser Qt ou SDL pour le rendu revient un peu au même ... Ils utilisent chacun un moteur de rendu logiciel. Je ne dis pas que ça ne peut pas fonctionner mais ça va être considérablement moins performant que GM qui utilise DirectX. Même si GM utilise un langage interprété, il reste que son rendu ce fait de façon matérielle via DirectX. Tu peut laisser tomber la SDL et utilisé un QGLWidget qui permet d'utilise OpenGL dans un contexte Qt. Il te faudra apprendre quelques bases sur GL si tu en a pas mais c'est un peu nécessaire si tu veut faire de quoi de performant. Je te conseillerais d'acheter ce livre : http://www.amazon.fr/Open-GL-2-0-Guide-officiel/dp/2744020869 . Après environ 180 pages de lus ta déjà une bonne base pour faire de jolie trucs :fier:

Rendu logiciel => processeur.
Rendu matériel => carte graphique.

(pour ceux qui arrivent en cours de route ^^)
Moi franchement je m'en fiche, mais autant mettre un rendu logiciel car certaines personnes (comme Nicoulas ) ont un bon processeur et une mauvaise CG.

M'enfin bon si tu veux vraiment un avis, je vais acheter une GTX295 à Noël donc un rendu matériel serait avantageux (mais fais tes fonctions en assembleur, c'est plus rapide ^^).

moi j'ai un proc en carton a genre 1.9ghz et une GC hyper forte a genre 512mo de vram
bref je fiat tourner beaucoup de jeu mais aliaser a fond

J'ai pareil que toi en CG sauf que le proc' c'est un Core 2 Duo à 3,85 Ghz.

bibi675 a écrit:

(mais fais tes fonctions en assembleur, c'est plus rapide ^^).

LoL en assembleur... Faut bien le connaître pour faire du code performant, puis je trouve cela pas très adapté à ce genre de projet, programmation plus longue et plus difficile et surtout faut savoir bien programmer en assembleur pour que cela soit plus performant(un peu dans la plupart des cas) que du C++ ou du C parce que sinon ça devient même moins performant vu les optimisation faite par les compilateurs C++/C. L'assembleur est adapté à d'autre truc et surtout pas celui là. À moins que tu parlais de coder soit même son moteur de rendu là c'est plus adapté.. si tu regarde dans la source de la SDL il y existe plusieurs partie en assembleur.

Non les fonctions en assembleur je parlait des fonctions de moyennes, calcul des angles, etc... les fonctions très courtes qui sont sont utilisés très souvent, là il y aurait un gain en performance à les faire en assembleur.

T'es sûre pour le rendu logiciel de Qt ??? alors c'est plutot embêtant par ce que commencer à apprendre l'open GL ça me tente pas vraiment. Je vais me renseigner, mais il y avait pas moyen de choisir avec SDL de mettre le rendu en Open GL ? (si oui le code change ?) (sinon pour les cartes graphique mon père à acheté une 9800GTX+ à genre 150€ et il fait tourné crysis en very high sans ram, c'est bluffant mais il a de la bonne ram et un très bon processeur ( 2 Quad 3 Ghz)) voila voila.

vivicool a écrit:

T'es sûre pour le rendu logiciel de Qt ??? alors c'est plutot embêtant par ce que commencer à apprendre l'open GL ça me tente pas vraiment. Je vais me renseigner, mais il y avait pas moyen de choisir avec SDL de mettre le rendu en Open GL ? (si oui le code change ?) (sinon pour les cartes graphique mon père à acheté une 9800GTX+ à genre 150€ et il fait tourné crysis en very high sans ram, c'est bluffant mais il a de la bonne ram et un très bon processeur ( 2 Quad 3 Ghz)) voila voila.

Faire le rendu avec OpenGL dans une fenêtre SDL le code change radicalement puisque tu n'appelle pas les mêmes fonctions. Les fonctions OpenGL commence toute par gl*. Pour le rendu de Qt je suis sure à 99.99% qu'il est logiciel puisque qu'il faut que les applications Qt fonctionnent sur tout les types de configuration. Tu peut utiliser le rendu Qt par exemple pour ton éditeur de room, sprite et background, c'est parfait pour ce type de traitement. Si tu veut un exemple comment utiliser Gl dans la fenêtre SDL regarde la doc de SDL il te montre un exemple et ensuite il te faudra acquérir un minimum de connaissance pour te débrouiller. Ce n'est pas si compliqué que cela GL... quand on ne fait que des trucs basiques. Le mieux c'est vraiment d'acheteur un bon livre :-D

bibi675 a écrit:

Non les fonctions en assembleur je parlait des fonctions de moyennes, calcul des angles, etc... les fonctions très courtes qui sont sont utilisés très souvent, là il y aurait un gain en performance à les faire en assembleur.

Ouais tu a surement raison :fier: . Mais je crois qu'il veut mieux utiliser les fonctions de la librairie standard du C/C++, et ensuite si la fonction désirée n'existe pas l'écrire en assembleur. Moi perso, je l'écrirais en C/C++ avec les ordinateurs puissant que nous avons et nos compilateurs qui optimisent grandement le code. C'est sure qu'un compilateur ne peut pas optimiser autant qu'un bon programmeur assembleur, mais je crois qu'ils peuvent en faire souvent autant.

Pour l'assembleur, c'est pas très utilie dans la plupart des cas en C, vu que le C est relativement proche de l'assembleur (ou alors t'as vraiment un compilo pourri, ou alors c'est vraiment quand la fonction a besoin de précision à la nano près, mais la plupart de l'optimisation ce fait au niveau du C). Sinon ça ne me pose aucun problème d'aprendre de nouvelles choses, je me suis déjà intéressé à l'open GL et on plus j'avais envie d'en savoir plus donc d'un côter ça m'arrange.

Delphi aussi compile directement en assembleur et sur des calculs qui bouclent très souvent tu peux avoir de très bons gains, en Delphi comme en C.

Comment avance ton projet?

vivicool a écrit:

(sinon pour les cartes graphique mon père à acheté une 9800GTX+ à genre 150€ et il fait tourné crysis en very high sans ram, c'est bluffant mais il a de la bonne ramé et un très bon processeur ( 2 Quad 3 Ghz)) voila voila.

Pas possible il me semble. Pour avoir 60fps en véry high, il te faudrait au moins un sli de 9800GTX. Et encore, même avec cela il te faudrait retirer l'antialiasing et que ta résolution soit de 1280x1024.

Je rappèle que même avec un processeur i7@4Ghz et un 3waysli285GTX, on est à peine à 60fps en 1920x1200. Environs.

PS:le very high pompe énormément plus que le high. Deplus, au lieu du véry high, il y a des customs ultra et custom very ultra qui rendent bien mieux en consommant pas forcément plus.

Topaze22 a écrit:

Je rappèle que même avec un processeur i7@4Ghz et un 3waysli285GTX, on est à peine à 60fps en 1920x1200. Environs.

Source ?

Topaze22 a écrit:

Pas possible il me semble. Pour avoir 60fps en véry high, il te faudrait au moins un sli de 9800GTX. Et encore, même avec cela il te faudrait retirer l'antialiasing et que ta résolution soit de 1280x1024.

ça a l'aire assez juste je trouve

bibi675 a écrit:

Topaze22 a écrit:

Je rappèle que même avec un processeur i7@4Ghz et un 3waysli285GTX, on est à peine à 60fps en 1920x1200. Environs.

Source ?

Hum, j'ai dis ça de tête, attend, je vais t'en trouver des sources.
Appelé moi "Maitre du benchmarking" ^^

https://www.youtube.com/watch?v=8Orsk65ib5c&feature=channel

C'est Crysis avec 3waysli280. pour avoir un résultat éxacte avec des 285, il suffit de rajouter très précisément 10% de fps. Le truc, c'est que sur cette vidéo il y a un antialiasing 8X donc fait le calcul et tu dois être vraiment au alentour de 60fps.
Et quand je dis qu'il faut un i7, c'est évident puisque un intel 4core à 3Ghz sature et fait plafonné les cartes graphiques qui dépassent la puissance d'une 285gtx.
[source : http://www.guru3d.com/article/core-i7-multigpu-sli-crossfire-game-performance-review/11]

Quelqu'un a encore un doute sur mes propos ?

(cette video est complêtement débile, les gens ont pas encore compris que le problème vien de crysis et non pas de la config, c'est le jeu le moin bien optimiser, tu lance Warhead sur sa config et tu tourne au moin à 5000000 fps :lng: https://www.youtube.com/watch?v=SdEv-sM_WpI) pour l'avancement, bin ça suit son court, la je suis dans la programmation des room, mais j'ai quelque petit problème pour savoir où on a cliqué, fin bon. Je crois que je vais un petit peu calmé la prog pendant quelque semaine à cause de mes exams qui approchent (et en plus je dois finir mon projet (à savoir un lecteur mp3, si si)) fin, je dis ça mais je suis sûr que je vais programmer encore plus que d'habitude...

edit : à oui, j'ai regarder pour l'open GL enfaite avec Qt si tu utilise QGraficsScene tu peux choisir le mode Open GL et t'as rien à changer donc je crois que le vais utiliser Qt pour le rendu du jeu, ça apporte pas mal d'avantage comme le réseau et donc le multi-joueur facillement implantable, mais ça apporte aussi un énorme inquonvénien pour nos chers utilisateur de windows à cause du poid des DLL de Qt... à méditer

edit edit : Yahoo 100 messages

Si tu utilise QGraficsScene ça ne sera pas aussi performant que du vrai OpenGL et t'aura pas accès à autant de possibilité, le mieux c'est d'utiliser QGLWidget...

Citation :

la je suis dans la programmation des room, mais j'ai quelque petit problème pour savoir où on a cliqué, fin bon.

Parles-tu de quelle est l'item sélectionné dans un QTreeWidget? si oui dans ce cas il faut tu connect le signal itemDoubleClicked à un slot pour chaque item(QTreeWidgetItem).

Je travaille présentement sur un projet de ce type et l'interface est faite avec Qt et le moteur en tant que tel utilise SDL et OpenGL. Cependant ce projet ne se veut pas d'être un réplique de Game Maker comme par exemple Enigma. Je veut faire différent avec des nouvelles idées.

ok, merci, mais ce que j'est besoin c'est de savoir là où l'utilisateur a cliqué dans la room pour créer on object.

vivicool a écrit:

ok, merci, mais ce que j'est besoin c'est de savoir là où l'utilisateur a cliqué dans la room pour créer on object.

Cela peut t'aider: La fonction à implémenter void QWidget::mousePressEvent ( QMouseEvent * event ) dans ton widget. Ensuite avec event tu peut savoir la position de la souris au moment du clic.

Oui, j'avais lu ça dans la doc mais ça ne fonctionne pas... (je l'applique à un QGraphicdScene et il y a une histoire de drag item, pas tout compris là dessus)

Topaze22 a écrit:

Quelqu'un a encore un doute sur mes propos ?

Nope merci je me souvenais plus que Crysis pompait autant. ^^

Pis on voit que tu as une bonne mémoire en passant.

Essaie en implémentant les autres fonctions aussi:

void mousePressEvent( QMouseEvent * );
void mouseReleaseEvent( QMouseEvent * );
void enterEvent( QEvent * );
void leaveEvent( QEvent * );

si ta besoin:

void keyPressEvent ( QKeyEvent * event );
void keyReleaseEvent ( QKeyEvent * event );

J'ai déjà eu ce problème en fessant un jeu de démineur il a fallu j'implémente les autres à ce que je me souviens...

bibi675 a écrit:

Topaze22 a écrit:

Quelqu'un a encore un doute sur mes propos ?

Nope merci je me souvenais plus que Crysis pompait autant. ^^

Pis on voit que tu as une bonne mémoire en passant.

J'ai aucune mémoire, une mémoire de poisson rouge, c'est à dire de 3s.
Sauf dans les trucs qui me passionne comme Super Mario et le Benchmarking ^^

Grrrrrrr , il y a toujours rien qui ce passe, je comprend pas... (a, faut pas mettre une macro dans l'object en question, je vais essayer...)

edit :
Non toujours rien :snif2: .
t'aurai pas un exemple avec un QGraphicsScene ?

La macro Q_OBJECT c'Est pour les objets manipulant les signals et les slots. Je vais essayer de mon coté pour le QGraphicsScene et si ça fonctionne je vais t'en faire part.

vivicool a écrit:

(cette video est complêtement débile, les gens ont pas encore compris que le problème vien de crysis et non pas de la config, c'est le jeu le moin bien optimiser, tu lance Warhead sur sa config et tu tourne au moin à 5000000 fps :lng: https://www.youtube.com/watch?v=SdEv-sM_WpI)

WareHead plus optimisé que le Crysis original ?
Pas possible, les deux utilisent le même moteur ^^
Strictement même.

La différence, c'est que dans Warhead, les éditeurs de map se sont calmés sur les décors (de fond plus particulièrement), alors si Warhead est plus fluide en very high, c'est uniquement parcequ'il y a moins de chose dans la vue.

Crysis est pas plus mal optimisé, il est sorti tôt comparé aux config PC éxistante (fin 2007), sauf que comme il est magnifique, il ne sera toujours pas démodé dans deux ans. Il a été prévu à la foi comme jeu qui sera vendu sur le très long terme, et aussi comme vitrine technologique pour les studios intéressé par la Crytec Engine.

Deplus, il est excellemment optimisé puisqu'il peut tourner à 60 fps sur les "vieux PC" et que l'on peut choisir les configurations.

Mais que demande le peuple bon sang !?
Et le 2Sli et le 3sli marche pour le mieux jamais vu.


Ca me fait déliré ceux qui disent qu'ils pompent beaucoup trop sur leur PC de 10 ans d'âge en very high. (je parle pas de toi, mais des nombreux commentaires que l'on trouve sur le net "Crysis ça pompe trop...", parceque c'est complètement stupide et ça me met hors de moi ^^)
Et pour l'optimiser mieux, comme la confi est "customisable" à fond, cherche "mode Ultra". Ca retire des trucs qui pompent beaucoup pour augmenter d'autres effets.

Et si tu as envi de te suicider, cherche "very ultra", tu vas perdre tes yeux [je suis devenu aveugle].

J'ai dit qu'il pompait beaucoup (en very high) pas qu'il pompait trop.

Nuance...

Bon ok, je vais chercher pour le very ultra, mais je reste persuadé que warhead est plus optimiser que le normal.

edit :
Pour mon prob de prog, c'est peut-être les QGraphicsView qui permettent de faire ça...

edit edit :
effectivement, problème résolu, merci Codeave

Comment ta fait pour régler?