Fusion 3, Exportation, Optimisation et Gestion de Ressources

Bonjour tout-le-monde! :)

Aujourd'hui, je ne vais pas vous demander de l'aide ou des explications en rapport avec Fusion 2.5 comme on à mon habitude (ah bah ça va changer un peu tiens), mais pour parler et disserter sur un sujet qui m'apportent pas mal de réflexions actuellement sur les logiciels Clickteam !

Depuis quelques temps, je me pose pas mal de questions en rapport avec Fusion 3, qui avance bien dans son développement, la question d'un point qui serait très intéressant à réfléchir. La question au niveau de l'optimisation de nos applications exportés, de sa lecture et de sa gestion des ressources.

En effet, je ne sais pas si vous le savez, mais Clickteam Fusion 2.5, tout comme Multimedia Fusion 2, et tout comme The Game Factory ont un système de compilation plutôt particulier, et bien à eux !

En effet, les IDE classique permettant de coder un programme à partir d'un langage de programmation conventionnel (C++, Java et j'en passe) permettent de compiler le code directement en binaire en créant une application avec généralement un dossier externe contenant la plupart des ressources. (les fameux dossiers data).

Car oui, je sais que quasiment tout le monde ici doivent le savoir, mais un ordinateur n'est capable de lire uniquement le langage binaire afin de faire fonctionner une application. La compilation à donc une étape de conversion du langage de programmation utilisé par le programmeur, en binaire, pour que le PC puisse le "lire" !


(un p'tit schéma fait par mes soins)

Et c'est en ça que Fusion 2.5, comme ses prédécesseurs fonctionnent totalement différemment.

En effet, Fusion 2.5 créer et incorpore lors de la compilation de l'application son propre moteur de rendu software (son célèbre Runtime). Il génère des applications « pseudo-compilées » qui sont ensuite exécutées et émulée par le biais d'une machine virtuelle qui est ici intégrée à l’exe final et qui ne nécessite donc aucune installation préalable de l’utilisateur. Et qui permet en plus de créer des applications dites "autonome" dans la plupart des exportations (sans les fameux dossiers data en sommes)


(Je ne sais pas si j'ai fais des erreurs dans ce schéma, je ne suis pas un expert en la matière, et j'ai peut-être inversé (voir trompé) sur des étapes. Quoiqu'il en soit, ce schéma sert principalement à démontrer que la création / lecture d'une application créée par Fusion est plus longue et laborieuse que dans la plupart d'autres moteurs)

Ainsi, cette méthode est fonctionnel ! Elle permet à l'utilisateur de ne pas à devoir utiliser de programme d'installation dans la plupart des cas, il y a pas non plus de dossiers data embêtant vu que tout est compilé dans un seul et unique fichier qui sera lu par émulation. De plus, le Runtime de Fusion permet de lancer des applications sans avoir recours à une carte graphique évoluée (enfin, c'est ce qui est dit, mais j'suis pas super super d'accord avec ça).

Cependant, cette méthode de compilation est, selon moi, l'un des plus gros points faibles de Fusion 2.5 !
En effet, si cette méthode présente des avantages, mais elle n'en regorgent pas moins de plusieurs défauts.

La première étant l'optimisation, la vitesse de l'application et sa fluidité. Autant avec l'exportation sur Windows, on à une sacré marge avant de souffrir d'une perte de performance, mais il est extrêmement difficile et laborieux de concevoir une application, même simple, dans les autres exportations dans des plateformes qui sont beaucoup plus réduite en terme de puissance.

En effet, même dans le plus simple des jeux, rares sont ceux fonctionnant sur les navigateurs ou les mobiles qui ne souffrent pas de lag, de ralentissement, de perte de vitesse, ou des chargements de scène un peu trop chargé qui sont soit trop long, soit font planter l'application.

Émuler une application dans un Runtime, c'est cool, mais ça demande pas mal de puissance, et les exportations hors-PC (ou console de salon) ne nous permettent pas d'avoir accès à cette puissance sans en pâtir au niveau performances. Ce qui fait qu'on nous devons parfois faire soit des jeux très simple sur ces plateformes, soit s'arracher la tête en trichant au niveau des ressources pour optimiser à mort notre application pour qu'il puisse être un poil élaborer sans qu'il perte de vitesse.

De plus, Clickteam est obligé de recréer un nouveau Runtime de A à Z différent pour chaque plateforme différente, ce qui leur demande un temps monstre, et ce qui expliquent aussi pourquoi il est très difficile d'essayer d'exporter nos jeux sur les consoles de salon par exemple.


Alors, après cette longue explication sur le méthode de compilation et de fonctionnement des applications avec Fusion et ses prédécesseurs. Viens ainsi ma question :

Est-ce que Fusion 3, ce tout nouveau moteur apparemment recréer à partir de zéro (contrairement à Fusion 2.5 qui est une évolution basés sur le code de Multimedia Fusion 2), changera t'il sa manière de compiler les MFA conçu avec lui ? Utilisera-il selon vous le même système de Runtime et d'émulation pour faire fonctionner les applications ? Pensez-vous donc que ce sera la fin des applications autonomes, et que donc on gagnera en optimisation et en puissance pour toute plateforme d'exportation ?

Moi je ne sais pas comment Clickteam va procéder, mais ce serait vraiment cool si on avait le droit à plus de puissance et de fluidité ! Bien sûr, ce sera toujours au programmeur de se démerdé pour optimiser au mieux son application, et de trouver des astuces pour mobiliser le moins de ressources possibles. Mais avoir un coup de pouce du logiciel pour nous donner plus de marge et de manœuvre d'action, ce serait chouette !

Qu'en pensez-vous ?

Il faut prendre Fusion comme un langage interprété.  La runtime est déjà un programme en lui même qui va juste décoder des "actions" pour en réaliser d'autre. Il n'y a pas de 2nd compilation en binaire xd C'est déja fait.

C'est pour ça que ça peut être "lent".
Par contre quand on exporte sous android, flash, ios... C'est autre chose. La runtime c'est plus vraiment un interpréteur mais une série de script déjà codé. Et fonction pré créer.(Bon ça revient au même mais voila) on  transforme tout ça en fichier de programmation du langage cible, et c'est pour ça qu'il faut "compiler" cette fois avec les logiciels de compilation dédié à la cible pour re faire le fichier binaire lisible sur la machine voulu. Pareil avec le module XNA pour PC on recompile ça pour du X86 avec d'autre couche. mais bon. 

Normalement fusion III sur PC sa devrait être du native à ce que j'ai compris.

J'ai envie de dire que sous android,ont est quand même de plus en plus a l'aise niveau puissance et qu'a moins d'avoir un appareil bas de gamme d'il y a 10 ans,il en faut pour que ça rame quand même.
Sinon je suppose que clickteam va forcement revoir la façon dont les programmes sont gerer en sortie,c'est evident,ça doit forcement faire partie des nouvelles fonctionnaliter sinon ça n'aurait pas de sens de tout changer comme ils le font,ont se retrouverait avait des programmes encore plus lent.

Il faut prendre Fusion comme un langage interprété.  La runtime est déjà un programme en lui même qui va juste décoder des "actions" pour en réaliser d'autre. Il n'y a pas de 2nd compilation en binaire xd C'est déja fait.

Oui, je me doutais que j'avais fait une erreur à ce niveau-là! Quoiqu'il en soit, et comme tu l'as dit aussi, ça reste plutôt lent au final au niveau de l'optimisation ! ^^

J'ai envie de dire que sous android,ont est quand même de plus en plus a l'aise niveau puissance et qu'a moins d'avoir un appareil bas de gamme d'il y a 10 ans,il en faut pour que ça rame quand même.

Hmm autant je suis d'accord que les mises-à-jour de Clickteam / d'Androïd et les nouveaux téléphones nous accordent parfois un peu plus d'optimisation et de stabilité, autant je suis pas d'accord sur le fait qu'on à aucun problème de perte de puissance sur un téléphone récent ! Va essayer de faire un mini-RPG sur téléphone avec Fusion, c'est quasiment impossible qu'il fonctionne de manière fluide sans ralentissement ! A moins de se casser la tête comme un Rubik's Cube en trichant sans arrêt sur les ressources !

[quote]A moins de se casser la tête comme un Rubik's Cube en trichant sans arrêt sur les ressources ![/quote]

Ça s'appelle programmer un jeu vidéo...

Salut,

:D

Programmer un "petit" rpg réclame des compétences, on a depuis le début "triché" sur les ressources, le contraire serait étonnant.

:jesors

A+++

[quote] Va essayer de faire un mini-RPG sur téléphone avec Fusion...[/quote]
Cela fonctionnera à merveille. Pixner fonctionne, je ne vois pas pourquoi un rpg ne fonctionnera pas.

[quote]A moins de se casser la tête comme un Rubik's Cube en trichant sans arrêt sur les ressources !

Ça s'appelle programmer un jeu vidéo...
[/quote]

Alors oui, je suis d'accord ! Je n'ai pas tout à fait été assez clair, alors oui on passe très souvent du temps à réfléchir comment faire pour optimisés ses ressources, réussir à consommer le moins de puissance possible. Ce n'est pas ça que je critique. Ce que je critique, c'est juste que la méthode de compilation de Fusion nous bride en puissance, et qui peut nous compliqué le développement, ou rendre très dur l'exportation d'un jeu fonctionnant normalement sur PC sur téléphone ! :)

[quote] Va essayer de faire un mini-RPG sur téléphone avec Fusion...

Cela fonctionnera à merveille. Pixner fonctionne, je ne vois pas pourquoi un rpg ne fonctionnera pas.
[/quote]

Alors, oui, tu marque un point ! Pixner et Super Pixner marche à merveille ! J'ai jamais dit que c'était impossible de ne pas faire de RPG, mais un petit point que j'aimerai souligné, c'est que Pixner / Super Pixner est un jeu qui fonctionne avec pas beaucoup d'objet actif par niveau, et c'est pour ça qu'il est rapide sur tout les support ! :)

Quand je parlais de RPG, j'ai utilisé ce terme grossièrement, j'avais surtout en tête les RPG style les premiers Final Fantasy qui ont des map assez grande avec pas mal d'actif à gérer, et dont là le problème de puissance risque de se faire sentir sur les plateformes mobile / navigateurs, à contrario des supports PC ! :)


Après, je tiens à préciser ! Je ne cherche pas non plus à dénigrer notre bon Fusion non plus hein ! xp

Heum dans ma mémoire chaque tiles de 16px c'est une image active. Petite résolution certe  mais il y a de l'active et c'est pas si bien programmé que ça.

[quote]Quand je parlais de RPG, j'ai utilisé ce terme grossièrement, j'avais surtout en tête les RPG style les premiers Final Fantasy qui ont des map assez grande avec pas mal d'actif à gérer, et dont là le problème de puissance risque de se faire sentir sur les plateformes mobile / navigateurs, à contrario des supports PC !

Afficher la map entière c'est une connerie sur tous logiciel de toute façon. Le mieux c'est d'afficher la map visible, et quand tu déplaces ton perso à droite par exemple, tu affiches ta bande à droite hors écran, et tu déplaces ta map à gauche !

Tu ne déplaces pas ton sprites PJ qui reste la ou il est est ! Le tour est joué xd

Et oué de la vrais programmation ou vrais technique de programmation sur Fusion ! Cela facilite la tache dans énormément de truc.

[quote] Super Pixner est un jeu qui fonctionne avec pas beaucoup d'objet actif par niveau,

Heum dans ma mémoire chaque tiles de 16px c'est une image active. Petite résolution certe  mais il y a de l'active et c'est pas si bien programmé que ça. [/quote]

Certes, mais dans un espace assez bien délimiter (il y a pas de scrolling), et le taille de la scène ne dépasse pas celle de l'application, et la petite résolution des tiles permettent un affichage très rapide comme tu l'as dit ! Tu as réussir à faire un jeu plutôt bien fichu et avec peu de ressources c'est cool ! :')

Après, en effet, ta technique pour les RPG peut p'tet permettre de libérer plus de puissance, en affichant les éléments uns à uns !

Il existe de nombreuses techniques, afin de limiter le nombre d'objets actifs.

Néanmoins un phone, est quand même plus performant qu'un Amstrad CPC 464 à k7 (lol).

Hahaha oui, c'est vrai ! xD
Mais les attentes sont plus exigeant aussi ! :')