Question sur les limites de GameMaker de BigBoris

Hello les gars !
J'ai reçu une question par mail de BigMoris, je poste sa question et ma réponse ici au cas où ça intéresserait quelqu'un.
Je me permets aussi de dire que ma mémoire flanche, ce n'est peut être pas des "long float". N'hésitez pas à donner votre avis et vos corrections si j'ai fais un "couac".

Citation :

Salut je suis nouveau sur la CBNA et je me suis lancer sous game maker depuis peu et j'ai vue un poste parlant de limite absolue. J'aurais aimer ton opinion si tu le veut sur cette fameuse limite... Je programme en pascal depuis un moment mes j'avais envie de créer des jeux sous game maker pour sauver du temps, mes projet risque de contenir beaucoup de contenu et j'aimerais ne pas frapper un mure si je tombe sur cette fameuse limite dont pratiquement personne connais.

J'ai plus cru voire sur le forum officiel que game maker a tendance a corrompre les fichier projet avec le temps pour certaine personne et qu'il suffit de tout transférer dans un nouveau projet pour régler le problème. J'ai remarquer que beaucoup de personne sur ce forum semble posséder une version cracker de game maker et je me disait que le problème venait sans doute de la, j'avais tester la version cracker un moment avant de l'acheter et je n'est eu que des soucis alors que maintenant je n'est plus aucun problème.


Enfin bref merci a l'avance pour ton avis sur le sujet.

Bonjour BigBoris !
Bienvenu parmi nous ^^

-Ces fameuses limites sont du genre inatteignable, ce sont des limites dû à la taille des variables de GM. (toutes des long floats, je crois), donc par exemple, la taille d'une room ne peut pas dépasser la valeur maximal qu'une variable peut atteindre en "long float".

-Ou sinon, de façon plus rationnelle (et sans rapport avec les long float), une texture ou un background ne peut pas dépasser les 1600pxl en x ou en y.

M'enfin, ces deux points ne sont guerre des limites bien limitantes puisque rien ne nous empêche d'avoir x room qui se suivent ^^

Les vrais limites de GameMaker, celles que l'on ressent, c'est :
-performance en 3D mauvaise
-les instructions classiques du genre "x=x+1;" sont bien plus rapide qu'en flash, mais moins performante qu'en C ou en C++ (un peu à cause du faite que toutes les variables sont des "long float").


D'un autre coté, Yoyogames vient d'optimiser un peu plus la 3D sous GM (la rendant plus performante), et vient de porter GM sous PC(xp,vista,7,,MAC,iphone,ipad,PSP,HTML5,android. Donc en un clic, tu peux compiler vers toutes ces plateformes, et même d'avantage encore dans l'avenir (PSPvita, j'en suis presque sûr) (et peut être vers les futures consoles, ça c'est moins sûr mais ça reste plutôt bien possible).

En ce qui concerne la corruption des fichiers, il y a une option qui permet que, quand tu fais une sauvegarde, il y a d'autre sauvegarde qui se crées à coté, avec juste le nom de l'expansion qui change.

Et comme maintenant, ce n'est plus une personne qui code GM, mais tout une entreprise, ils ont corrigés beaucoup de bug dans leurs dernières version, dont au moins un sur les corruptions il me semble.




Et concernant le fait que tu vas avoir beaucoup de contenu dans ton projet, tu ne devrais pas rencontrer de barrière spécifique propre à GameMaker à ce sujet. Il faudra juste que tu apprennes à te servir des fonctions pour les "ressources externes". L'histoire de ne pas mettre de MP3, ou de background dans ton .Exe.

Des 'double', soit 8 octets pour un nombre décimal.

Sinon la plupart des limites ont rien a voir avec ça, c'est juste que GM c'est de l'interprété, et l'interprété c'est lent et c'est pas fait pour les calculs.

J'invite BigBoris a aller ici d'ailleurs : https://cbna.forumactif.com/t11022-ce-qu-il-manque-a-gm

Merci pour t'est réponses qui me rassure et confirme ce que j'ai pu voire sur les forums officiel et donc du coup gm devient pour moi très pratique malgré sa puissance 'Qui semble très acceptable pour la plus part des projets' et certaine limite plus ou moins contournable.

Citation :

''-Ou sinon, de façon plus rationnelle (et sans rapport avec les long float), une texture ou un background ne peut pas dépasser les 1600pxl en x ou en y.''

J'arrive a afficher une room de 4084 pixel avec un background de la même taille et a créer un path avec l'aide de mp_grid 'La Planification des Mouvements' et ce sans aucune chute de fps a 60 step par seconde. J'ai vue d'autre projet sur le forum utilisant facilement des room de 6000.

Citation :

Et concernant le fait que tu vas avoir beaucoup de contenu dans ton projet, tu ne devrais pas rencontrer de barrière spécifique propre à GameMaker à ce sujet. Il faudra juste que tu apprennes à te servir des fonctions pour les "ressources externes". L'histoire de ne pas mettre de MP3, ou de background dans ton .Exe.

Je compte bien tout faire en gml et du même coup charger des ressource externe, je me suis taper pratiquement toute la doc au complet et le gain de temps que je vais gagner en utilisant gml au lieu de delphi vas tout simplement être colossale. C'est un peu un choix personnel, soit me taper des dizaines/centaines d'heure supplémentaire pour rendre le jeu plus performance avec delphi ou me simplifier la vie et créer un jeu demandant plus de ressource.

A l'heure ou la moyenne des gens possède des processeurs double coeur et 1gig de ram je ne voix plus trop la nécessité de me compliquer la vie pour des gens possédant encore des dinosaure

En fait tout dépend du type de jeu que tu veux faire. Certains jeux sont juste infaisables avec GM, bon pc ou pas.

J'ai commencé le dev de jeux avec GM, et a l'époque j'avais un ordinausore avec win98, et GM tournais bien.
Fallait juste faire gaffe a la ram utilisée et optimiser pour pas passer sous les 60fps.
A vrai dire c'est justement sur ces vieux pc qu'on apprend bien a programmer, car la moindre connerie a des conséquences directes,
alors qu'avec un bon pc les conséquences peuvent se faire sentir au bout d'un long moment, et pourrir un projet.

De toute façon y a un truc qu'il faut comprendre, c'est qu'il y a deux types de programmeurs :
-ceux qui programment bien, qui ne sont pas pressés, et même avec GM ils arriverons a faire de très bon truc.
C'est juste qu'a un moment ils se sentirons limités et souhaiterons passer a autre chose (mais bon GM est suffisant pour de nombreuses choses).
-ceux qui programment a l'arrache, se foutent de la ram utilisée sous prétexte qu'on a de nos jour au moins 1Go de ram et tout et tout.
Ben ceux la font pas long feu (et encore moins leurs projets). Et même sous GM ils n'arrivent pas a faire grand chose d'acceptable.

La bonne programmation n'a rien a voir avec le langage ou l'environnement utilisé. C'est une façon de procéder. Et si tu viens sous GM pour aller plus vite
c'est une très bonne chose que de te bouffer de la doc, et ne pas essayer de bruler des étapes.

Quoi qu'il en soit pour ceux qui ont des doutes sur GM suffit de regarder le moteur smartlight de Bast.
Ça montre que les capacités d'un GM bien maitrisé sont énormes.

Citation :

-ceux qui programment a l'arrache, se foutent de la ram utilisée sous prétexte qu'on a de nos jour au moins 1Go de ram et tout et tout.
Ben ceux la font pas long feu (et encore moins leurs projets). Et même sous GM ils n'arrivent pas a faire grand chose d'acceptable.

Quand je parle d'aller rapidement je veut simplement dire que game maker offre des outils déja tout prêt qui m'aurais pris un temps fou a programmer seule et qui viendrais s'ajouter au temps finale du projet. Quand je parlais des pc actuel c'était pour expliquer qu'avec la puissance des pc de la moyenne des utilisateurs actuel, il est possible d'avoir un bon résultat sous gm avec la plus part des joueurs.

Citation :

La bonne programmation n'a rien a voir avec le langage ou l'environnement utilisé. C'est une façon de procéder. Et si tu viens sous GM pour aller plus vite
c'est une très bonne chose que de te bouffer de la doc, et ne pas essayer de bruler des étapes.

Je fait toujours des testes et m'informe avant de me lancer dans un projet ou dans un mécanisme important d'un projet et je crois que prendre le temps de s'informer/réfléchir/planifier est le minimum syndical quand ont compte mener a bien un projet. Ça évite de ce retrouver bloquer un peu plus loin car on a pas vue venir les éventuel problème et c'était un peu pour sa que je me suis interroger a propos des limites de game maker et des possibilité qu'il offre.


Sinon mon projet est un Tactical Turn Based Game avec un coté rpg pour l'évolution de l'escouade, donc rien d'impossible sous gm de ce que j'ai vue.

Pour ceux qui programment a l'arrache t'était pas concerné, c'était juste un exemple de ce qu'il ne faut pas faire :p

BigBoris a écrit:

Sinon mon projet est un Tactical Turn Based Game avec un coté rpg pour l'évolution de l'escouade, donc rien d'impossible sous gm de ce que j'ai vue.

Oui c'est faisable. Par contre pour ce qui est gestion des données ça va être assez ******, vu que les structures n'existent pas sous GM (mis a part si t'en code dans une dll).

Citation :

Oui c'est faisable. Par contre pour ce qui est gestion des données ça va être assez ******, vu que les structures n'existent pas sous GM (mis a part si t'en code dans une dll).

Effectivement sa risque de poser problème et j'hésite entre un dll en pascal qui seras relativement facile a programmer ou trouver une solution en gml, sauf que bon tu semble avoir mentionner dans un autre post un instabilité aléatoire des dll sous gm alors j'hésite encore entre la dll et la solution brouillon.

Au pire t'as les ds_map qui te permettent d'associer une clé a une valeur.
Ça pourrais remplacer une structure si t'en fait pas un usage intensif (car c'est pas aussi rapide que de simple variables).

Sinon pour ce qui est de l'instabilité des dll j'ai cru comprendre que c'est que pour certaines dll qui essayent de faire des trucs complexes, du genre toucher aux surfaces de GM.
Faire une dll avec une structure de données ne devrais poser aucun soucis, et tu gagneras en perfs.

Citation :

Au pire t'as les ds_map qui te permettent d'associer une clé a une valeur.
Ça pourrais remplacer une structure si t'en fait pas un usage intensif (car c'est pas aussi rapide que de simple variables).

Oui j'avais vue cette possibilité dans la doc mes j'avais des doutes sur la rapidité et la mémoire qu'il utilise, je risque d'avoir beaucoup d'objet contenant plusieurs valeur. C'est un peu dommage de ne pas pouvoir créer de classe.

Citation :

Sinon pour ce qui est de l'instabilité des dll j'ai cru comprendre que c'est que pour certaines dll qui essayent de faire des trucs complexes, du genre toucher aux surfaces de GM.
Faire une dll avec une structure de données ne devrais poser aucun soucis, et tu gagneras en perfs.

C'est bon a savoir et je risque de prendre cette méthode qui risque d'être plus efficace et plus plaisante a utiliser.