Red Hammer Engine

Citation :

une communauté est actuellement en train de recréer toutes les fonctions de GM, mais en C++ (en open source en plus).

yeaaaah

dites, c'est puissant le java?
j'ai du mal à comprendre le concept de puissance...
je voudrais faire tourner un jeu 3D, disons niveau ps1. en java c'est faisable?
ou carrément pas

edit: lol personne sait

Chulien a écrit:

Citation :

une communauté est actuellement en train de recréer toutes les fonctions de GM, mais en C++ (en open source en plus).

yeaaaah

dites, c'est puissant le java?
j'ai du mal à comprendre le concept de puissance...
je voudrais faire tourner un jeu 3D, disons niveau ps1. en java c'est faisable?
ou carrément pas

edit: lol personne sait

Java c'est moins puissant parce que c'est du code "semi-compilé". Son code est compilé en byte-code qui est lu par la machine virtuel java. L'avantage du java est d'être multiplatforme.

Topaze22 a écrit:

Une performance technique assez importante, dommage que ton quadtree ne soit pas sous GM, il aurait alors peut-être pu en intéresser quelques-uns.

Je crois qu'à l'interne de Game Maker il y a déjà un QuadTree ou bien un système de la sorte.. qui est transparent aux programmeurs tout comme le mien pourrait l'être.

Si quelqu'un pourrait dire qu'il n'y a pas de quadtree ou autre je pourrait très bien faire une dll pour ça. Mais je pense vraiment que GM est optimisé de ce coté la.

Au fait, Red Hammer, c'est arrêté ? Ou ça continue ?

Ça continue. Mais ces derniers mois j'ai moins eu de temps à cause de mes études! Mais il avance tranquillement. Je veux qu'il fonctionne avant cette été parce que je vais probablement participé à un concours de programmation de jeux video.

daccord merci pour java

game maker semble pas complètement compilé non plus, jme trompe? (on peut lancer des scripts à partir de chaines de caractères...)

En effet, GM est un langage interpreté.

Et non, il n'y a pas de quad tree sous GM, je ne pense pas en tout cas, l'instance activate est juste un while avec tout les objets actifs qui regardent leur x et y.

Et en ce qui concerne le moteur de collision, je pense que c'est pareil, un while(all) qui regarde tout les pixels de tout les objets. A moins qu'avec un peu d'optimisation, il ne s'agisse d'un tableau à deux dimensions dont l'index est regardé astucieusement, mais j'y crois moyen.

Si il y avait du quad tree dans l'air, on le s'aurait je pense ^^

Topaze22 a écrit:

En effet, GM est un langage interpreté.

Et non, il n'y a pas de quad tree sous GM, je ne pense pas en tout cas, l'instance activate est juste un while avec tout les objets actifs qui regardent leur x et y.

Et en ce qui concerne le moteur de collision, je pense que c'est pareil, un while(all) qui regarde tout les pixels de tout les objets. A moins qu'avec un peu d'optimisation, il ne s'agisse d'un tableau à deux dimensions dont l'index est regardé astucieusement, mais j'y crois moyen.

Si il y avait du quad tree dans l'air, on le s'aurait je pense ^^

S'il n'y a pas de quadtree c'est à 100% sure que GM fasse au moins du bounding box check! Sinon ça serait vraiment très ridicule... Pourquoi regarder les pixel de deux objets dont leur bounding box ne se touchent même pas! C'est la première optimisation à faire et la plus importante! Ensuite vient le QuadTree ou autre forme d'optimisation.

Citation :

Pourquoi regarder les pixel de deux objets dont leur bounding box ne se touchent même pas!

ah tu veux dire que la bounding box est quelquechose de plus "à peu près" que le mask avec les pixels? que cest pas la même chose?


sinon moi j'ai essayé de faire un place_free_3D(x,y,z) en script gm et ça rame pas mal quand on l'utilise souvent (bon ça ne m'étonne pas)
déjà je devrais remplacer la vérification en x,y avec place_free tout court ^^
plutot que dle faire avec des variables

Chulien a écrit:

Citation :

Pourquoi regarder les pixel de deux objets dont leur bounding box ne se touchent même pas!

ah tu veux dire que la bounding box est quelquechose de plus "à peu près" que le mask avec les pixels? que cest pas la même chose?


sinon moi j'ai essayé de faire un place_free_3D(x,y,z) en script gm et ça rame pas mal quand on l'utilise souvent (bon ça ne m'étonne pas)
déjà je devrais remplacer la vérification en x,y avec place_free tout court ^^
plutot que dle faire avec des variables

Le bounding box c'est le carré qui engloble la sprite. C'est un test rapide qui sert à savoir si les deux objets peuvent réellement se toucher avant de faire des tests couteux en performance.

pour un jeu simple, les carrés suffisent
mais tu viens d'illuminer ma vie

Chulien a écrit:

pour un jeu simple, les carrés suffisent
mais tu viens d'illuminer ma vie

LOL en quoi ?

lol non ca va, mais c'est intéressant de savoir que les vérifications ne se font pas directement pixel par pixel

Chulien a écrit:

lol non ca va, mais c'est intéressant de savoir que les vérifications ne se font pas directement pixel par pixel

C'est sure à 100% sinon je trouverais Mark Overmars bizarre XD Mais de toute façon nos jeux serait très lent et Game Maker ne serait pas aussi populaire juste à cause de ça

Bon Codecave, ton projet il est super interressant. Ignore les commentaires qui te disent que tu "copies" et tout ça car ce que tu fais c'est à toi et à personne d'autres.

Je peux voir totue de suite que ton engine sera beaucoup plus sécuritaire (pas de décompilation) et rapide que Game Maker. Plus flexible, (capacité d'inclure son code c++).

Mais je me demande comment tu compte t'y prendre par rapport aux scripts, à la compilation, et a l'ide.

Devras-tu inclure ton propre colorateur syntaxique ainsi que vérificateur ? Ou allons nous pouvoir coder avec notre editeur préféré et tout simplement inclure les fichiers .cpp, .c

Ce serait mieux, je crois, que l'ide ne serve pas du tout à coder. Mais, qu'il serve seulement à inclure les ressources et les gerer ainsi que compiler le code de l'usager avec le code de ton engine.

Merci de l'encouragement Cérénade

Pour répondre à ta question, oui le code serait coloré et vérifié par gcc lui-même. Il serait aussi possible d'utiliser le moteur avec simplement votre IDE préféré tout comme vous pourriez l'utiliser avec son propre IDE.

Donc la compilation se fais via un compilateur déjà existant gcc mingw32.

J'ai souvent songer à simplement faire un éditeur de ressources au lieu d'un IDE complet et j'y songe encore. Ce n'est pas encore choisi définitivement. L'avantage de d'un IDE complet serait d'éviter les allez-retour entre l'IDE C++ et l'éditeur de ressources. Mais un des désavantages serait que la parti pour coder de l'IDE complet serait moins complète et bien faite qu'un vrai IDE C++ développé depuis des années...

Tu me fais pencher plus vers l'option d'un éditeur de ressource mais encore la je dois peser le pour et le contre avant de décider. Pour le moment, je continue à coder le moteur qui est déjà assez complet pour faire des petits jeux d'ailleurs. Mais il reste encore du travail.

CoDeAVE a écrit:

Merci de l'encouragement Cérénade

Pour répondre à ta question, oui le code serait coloré et vérifié par gcc lui-même. Il serait aussi possible d'utiliser le moteur avec simplement votre IDE préféré tout comme vous pourriez l'utiliser avec son propre IDE.

Donc la compilation se fais via un compilateur déjà existant gcc mingw32.

J'ai souvent songer à simplement faire un éditeur de ressources au lieu d'un IDE complet et j'y songe encore. Ce n'est pas encore choisi définitivement. L'avantage de d'un IDE complet serait d'éviter les allez-retour entre l'IDE C++ et l'éditeur de ressources. Mais un des désavantages serait que la parti pour coder de l'IDE complet serait moins complète et bien faite qu'un vrai IDE C++ développé depuis des années...

Tu me fais pencher plus vers l'option d'un éditeur de ressource mais encore la je dois peser le pour et le contre avant de décider. Pour le moment, je continue à coder le moteur qui est déjà assez complet pour faire des petits jeux d'ailleurs. Mais il reste encore du travail.

Une fois le nouveau site en ligne on pourrait faire un IDE à la base d'eclipse CPP, cela permettrait de bénéficier de toutes les facilités de colorisation, gestion des compilos etc. en y ajoutant les systèmes d'édition de ressources.

Pour l'édition de ressources on pourrait utiliser le bind de Qt Jambi afin de faire un système de dessin etc. performant. Je dis on, parce qu'on avait parlé il y a longtemps que je pourrai t'y aider, mais vu mon workload ça n'était pas possible et ça ne l'est avant la sortie du site toujours pas...

Continues ce projet, it is a good one! ^^

Intéressante l'idée que tu apporte ici de faire un IDE à la base d'Eclipse CPP. Si tu sais comment t'y prendre pour faire ce genre de truc je suis peut-être partant pour essayer d'en faire un en ta collaboration. Bien que l'éditeur de ressources est déjà commencer rien n'empêche de repenser cette partie du projet.

On s'en reparlera A+!

Contrairement a sekigo, je trouve justement l'horrible barre de fichiers a gauche exellente. en un coup d'oeil, on a un aperçu clair et précis de l'avancée et du contenu de son jeu. certes, ça fait vraiment GM, mais c'est vraiment pratique.

Ya pas longtemps j'ai un peu tâté Construct, un concurrent de GM. ce moteur est très intéressant : langage puissant, et ouverture directe a directX -> effets de shaders disponibles, et autre. malheureusement, l'interface m'a bloqué.

Et rien n'empêche que je peux programmeur plusieurs dispositions d'interface pour l'utilisateur. Par exemple, je pourrais mettre aussi une disposition en onglets pour chaque type de ressource. je trouve cette dernière moins pratique que celle à la GM.

Je viens juste annoncer que le système de collision du moteur sera probablement le même qui est utilisé dans le moteur physique Box2D.

http://www.box2d.org/

De cette façon, le moteur permettra d'utiliser de la physique 2D dans un jeu qui n’en a pas au départ très facilement. Par contre, la détection de collision au pixel près (Per-pixel collision detection) ne sera plus vraiment possible. S'il en est ainsi, mon système de quadtree tombe à l'eau pour celui de Box2D qui est probablement bien plus performant puisque testé et optimisé à maintes reprises. Enfin bref, je fais de tests pour valider tout ça ^^

Dev' les deux? jveux dire, l'utilisateur choisi?

En fait par défaut tout les objets seraient statiques et le calcul de la physique serait désactivé. Il y aurait alors que la détection de collision manuelle comme on le fait avec GM par exemple: place_meeting. Si on active la physique au milieu du jeu rien ne va se passer de spécial tant qu'il n'y aura pas d'objet dynamique dans la room. Je m'explique probablement mal mais c'est un peu dure à expliquer d'autant plus que je suis en train d'explorer tout ça. Mais l'idée général est là: ajouter n'importe quand de la physique au jeu déjà programmé (avec le moteur) sans trop changer de code.

salut

Il y a des nouvelles pour ton moteur ?

Je trouve toujours très intéressants ces moteurs de Jeu.

Sera t-il plus sécurisé que Gm( moins facile de décompiler les exe) ?
Je crois que oui, si tu utilises un compilateur comme gcc ou autre.
Ce qui pourrait être fabuleux ce serait de générer du code c++ (comme un éditeur html génère du code html) et ensuite de pouvoir compiler avec code::Block ou un autre compilo

Y'a ti-il une démo pour le tester car le lien en première page ne marche pas ?

En tout cas, je te souhaite de poursuivre ce moteur et je peux te dire que s'il tient ses promesses, il reste d'être utilisé par beaucoup de monde .

Et si tu l'orientes pour les jeux 2D (et qui plus est 2D iso), alors, c'est clair que je serai l'un des premiers à l'utiliser .

A bientôt.