Indentation personnalisable ! / Résolution

🇫🇷 Forum français (French Forums) Demande de nouvelles fonctionnalités
1

Bon voilà, ce que je penses qui serait pratique, j’ai pas vue d’autres sujet comme cela alors désolé si il y en à un ou si ça a déjà été évoqué ailleurs.

Ce qui serait bien c’est de créer un système automatique d’indentation pour chaque type d’évènement/sous évènement.
Je vais prendre le cas le plus simple

Evènement si la souris est sur l’objet X
sous evnmt si clic gauche
sous evnmt si clic droit
soussous evnmt si variable A = Y
soussous evnmt si variable A > Y

Imaginons qu’on a ça, ça serait cool de pouvoir réduire le groupe Evènement principal (on aurait plus que l’évènement premier qui apparait, les autres sont masqués.
Si on clique sur une petite croix qui apparait, ça ouvre l’évènement.

"Un peu comme l’explorateur de dossier en général, on a un + pour ouvrir les sous dossier, et un - pour refermer.

Comme je suis quelqu’un d’un peu gourmand :stuck_out_tongue: je penses aussi que ça serait super pratique de pouvoir inclure des commentaire en sous évènements, ou des sous-évènements à des commentaires.
De même pour les fonctions, lien , chaque objets, au démarrage de la scène.

:exclamation: En effet peut être que dans un cas précis il peut être plus intéressant de déclarer une fonction selon la valeur d’une variable et donc la mettre en sous évènement et déclarer 2 fois la même fonction selon le cas précis (mais là par contre je pense que c’est plus tendu vue que lors de la compilation les fonctions doivent être connue :neutral_face: )

Mais sans aller jusqu’à quelque chose d’aussi compliqué (qui sera aussi compliqué à utiliser proprement) le simple fait de pouvoir les mettre en sous évènement d’un commentaire permettrait une relecture/recherche plus aisé !

J’espère que mon idée à été saisie dans le bon sens :mrgreen:

J’ai cru voir aussi que tu annonçais (4ian) que il y aurait bientôt une gestion de la résolution qui retoucherai les images à l’échelle.
Je voulais savoir si il y aurai pas la possibilité d’avoir un module qui permet de connaitre les résolution disponible au joueur (dans le cas d’un plein écran par exemple) afin qu’il puisse régler la résolution manuellement et que on ne lui propose pas des résolution impossible pour son écran :mrgreen: qui au final le laisserai avec un beau plantage du jeu :unamused:

2

J’avais déjà proposé cela à 4ian, mais c’est pas dans ces priorités. :wink:

3

Pour ton idée d’arborescences, c’est pas bête, a condition que ça soit bien intégré et que ça rame pas si y a un certain nombre d’évènements…
Perso je suis pour :smiley:

Pour ton idée de résolutions:
Pour les images a l’échelle, c’est bien, ça existe, mais dommage que ça ne déplace pas la position X, ou que ça ne réduise pas de façon a tout ramener vers le coin en haut a gauche de l’objet (sprite…) et ça serait peut être bien de revoir ça justement :smiley:

Et connaitre la résolution système, si c’est ce que tu as proposé, je trouve ça super comme idée. (si c’est pas ce que tu as proposé je le propose…), parce que connaitre la résolution de la fenêtre du jeu, pourquoi pas, mais le plus important c’est la résolution système. :slight_smile:
(Histoire de s’adapter au joueur…)

4

Oui oui c’est bien ce que je propose, comment proposer aux joueurs des résolution impossible pour lui ? (vieux CRT 17" cathodique et on lui propose du 1920*1024 Oo)

Après pour la mise à l’échelle, je sais pas trop si il faut tout remettre à l’échelle car si tu as fait un petit sprite à la base, il risque d’être minuscule en full hd !
A voir, soit on fait comme “dofus” quand on redimensionne la fenêtre tout est “zoom/dezoom” (ce qui donne super bien au passage et est un bon exemple je pense), soit on s’occupe juste de recadrer la caméra ce qui donnera un avantage aux joueurs avec des grosse résolution :confused:

Personnellement moi pour les résolution là, je suis en train d’essayer de faire un petit algorithme qui calcul le redimensionnement à faire selon la résolution mais, c’est pas évident ^^’

Si l’indentation n’est pas une des priorités à 4ian ce n’est pas grave, mais c’est aussi pas très compliqué à intégrer par rapport à un codage demandant de tout redimensionner à l’échelle :stuck_out_tongue: et qui apporte un vrai plus à l’ergonomie du programme !
Après si faut choisir, résolution d’abord :unamused:

Sinon y a t’il un post où est notifié l’avancement des maj ? J’ai cherché et pas trouvé ^^

5

Faire du Full HD pour de la 2D, je suis pas sûr que ce soit pertinent.
Ca alourdit le jeu, augmente les ressources nécessaires pour le faire tourner et impose un travail plus soigné aux graphistes du jeu.

Le 800x600 me semble déjà bien comme base.
Même sur un 16/9, la déformation n’est pas trop gênante.

Le vrai problème, sera plutôt comment faire zoomer/dezoomer plusieurs caméras sur plusieurs calques, déjà en zoom/dézoom les unes par rapport aux autres.
Ce sera aussi un souci avec les décors de fond, car ils deviendront plus petits que l’ère de jeu.

6

Non, si on redimensionne tout, l’ère de jeu aussi.

Par contre un problème auquel je viens de penser, c’est pour les forces, il va falloir les modifier là aussi :mrgreen:

Et du full HD en 2D ca alourdit un jeu tu crois ? Où ça le rend juste plus beau et éventuellement mieux fini ? Moi personnellement je travail mon jeu en 19201080, la majorité des gens on des 20" maintenant ou des télé plate (30" mini) comme écran d’ordi, ça permet de le faire tourner auprès de plus de personne que simplement les amateurs de jeux amateurs. Du moins, quand on montre un jeu fait avec RPG maker (en 800600) étiré en full screen sur un 27" par exemple, de 1 ça pique, de 2, si t’es pas un amateurs de jeux comme ça, tu dis simplement “mais c’est moche” (réflexe con, mais vrai)

Après c’est une question de choix aussi mais pourquoi brider les gens qui veulent avoir de la qualité en leur imposant des résolution obsolète ?? Moi si je suis là en premier, c’est parce que aucun RPG maker ne gère la full hd et qu’il sont bridé comme pas possible niveau qualité.
Là, si je veux foutre une image qui fait 40Mo ba ça passe (c’est lourd mais ça passe) après à moi de juger si je baisse la qualité ou pas (ou de programmer une fenêtre réglages te permettant d’afficher ou pas certain truc qui vont réduire la lourdeur du jeu)

PS : moi mes sprite je les travail en 700*700 au moins, je les mes à l’échelle en jeux (à ben oui ça fait faire des calculs et du travail en plus) mais au moins je suis certain de ne pas abimer mon travail, et de pouvoir travailler sur quelque chose de grand (car en graphisme il faut toujours travailler grand, et réduire après)

7

Donc, pour fait du HD, il faut produire des images en HD x 2.
C’est un coup à passer trois heures sur un brin d’herbe.
Déjà que pour produire des images correctes pour du 800x600, j’y passe des nuits …

Sinon, 40 Mo dans la mémoire vive pour gérer une seule image, je trouve que ça fait beaucoup.
A moins de faire un point’n click, ça va faire des centaines de Mo d’images en rendu temps-réel pour chaque frame.
Les vieilles config n’aimeront pas.
C’est donc se couper d’un certain public (celui qui n’a pas un PC à 4000 boules sous la main, netbook, iPad, et autres machins portables).

Autre problème, le temps de download : un jeu amateur à 200 Mo, ça fait tirer la tronche.

Sinon, oui, pouvoir gérer les différentes résos de jeu simplement serait un plus.

8

Concernant l’indentation :
Ca avait déjà été proposé en effet, et ça serait très intéressant, mais tout ce qui touche au rendu des évènements est pas simple à gérer. Mais ce serait intéressant.
( Notez que ce que vous proposez d’ailleurs ne s’appelle pas l’indentation, Game Develop indente déjà les évènements en insérant des espaces aux sous évènements, mais du “folding” ou “pliage de code” en programmation ).

Pour les sous évènements d’un commentaire :
Non, car le truc c’est que les sous évènement correspondent en gros à un bloc de code dans un langage traditionnel comme le C++.
Ca n’a pas trop de sens d’autoriser des commentaires à posséder des sous blocs de code. D’ailleurs, les commentaires sont virés dès qu’on lance le jeu : Même si ils ont des sous évènements, ceux ci seraient aussi virés.

Concernant la résolution :

La prochaine version proposera de mettre automatiquement les nouvelles caméras à la taille de la nouvelle résolution.
C’est à dire que actuellement, quand on change la résolution, tout est étiré, même si on change de scène. Dans la prochaine version, en mettant “oui” à un paramètre de l’action, les caméras des nouvelles scènes auront par défaut la nouvelle taille, augmentant l’espace “filmé”.

9

Génial, Merci beaucoup 4ian !
(A part ça, tu as une idée de la sortie de la prochaine version? (et de la prochaine version linux?)
Merci :slight_smile: )

10

Ce qui veut dire que, si j’ai une image de décor en 800x600, si mon jeu passe en 1600x1200, mon écran sera composé d’un décor de 800x600 et le reste à vide ?
Même chose si mon image de décor est d’origine en 1600x1200, mais à l’échelle 800x600 dans le jeu, elle restera à 800x600 lors du changement de résolution ?

C’est pas un peu dangereux, ça ?
Dans le sens “ça va ouiner un max sur le forum”.

Ou alors, ce “oui” sera indépendant pour chaque caméra.
Ce qui permettra d’avoir des calques qui se redimensionnent, et d’autres qui s’étirent, dans la même scène de jeu.

Mais même là, ça fera bizarre quand même …

11

Apparemment c’est indépendant a chaque caméra :slight_smile:

12

Non, non.
Il s’agit juste d’un paramètre pour savoir si le jeu doit considérer qu’il est toujours à une résolution (par exemple) de 800*600, dans quel cas il va étirer l’image sur toute la fenêtre, ou si il doit considérer que la fenêtre a effectivement la taille indiquée, dans quel cas les caméras montreront plus d’espace de jeu, comme si vous aviez réglé dès le départ la fenêtre du jeu à la nouvelle taille.

Non, ça veut dire que le jeu sera étiré comme actuellement.
Et que si tu coche le paramètre, au prochain changement de scène, la scène aura l’allure qu’elle aurait si tu réglais toi même ta fenêtre à la nouvelle taille directement dans l’éditeur.

13

Parfait ! :slight_smile:

14

Et si on prend l’effet inverse, qu’on a une résolution de base de 1080p et qu’on la reduit en 800*600, ça va réduire l’échelle des objets et des calques ? Et si on active l’option, ça tronquera la zone de jeux ?

15

Oui, mais sache que pour l’instant ça fait pareil, mais y a pas l’option.

16

J’espère cette semaine, j’ai passé du temps sur une fonctionnalité assez spéciale qui va sans doute rester un peu expérimentale mais qui devrait être dans la prochaine version.
Pour la version Linux, j’ai pas réussi à corriger grand chose de ce que tu m’a dit jusque ici. Je remettrai une version de test en ligne après avoir mis la version Windows.

Voilà.

17

On peut savoir ce que c’est ? :blush: :smiley:

18

Comme je l’ai dit, ça reste très expérimental et pas encore très utilisable.
Le but serait à terme de pouvoir permettre une intégration simple du C++ dans Game Develop. Non pas pour remplacer les évènements ou pour colmater des manques à Game Develop, mais plutôt pour permettre d’adapter des évènements en C++ pour profiter de performances accrues, pour utiliser des algorithmes déjà existants, je pense par exemple si l’on souhaite utiliser une méthode de cryptage voir pour s’initier au C++ dans un environnement qu’on connait pour les débutants, ou au contraire pour pouvoir coder son jeu en C++ pour les plus puristes, tout en pouvant aussi déléguer certaines tâches à Game Develop.

Actuellement, l’implémentation de tout ça nécessite que l’utilisateur télécharge le SDK de Game Develop et les bibliothèques/compilateurs associés. Par contre, une fois ceci fait, il suffit d’indiquer les chemins des fichiers à Game Develop et d’activer l’utilisation des sources C++ dans son jeu. On peut ensuite commencer à coder des évènements intégrés au jeu en C++.
J’ai notamment intégré un système qui gère la compilation des fichiers sources, compilation refaite à la volée à chaque test de scène suivant les fichiers qui ont été modifiés, ainsi qu’une éditeur de texte très basique ( On peut choisir d’utiliser un éditeur de texte externe ).

On perd par contre l’aspect cross compilation de GD ( A savoir que si on veut compiler pour Linux, il faut lancer l’éditeur et le jeu sous linux ). ( Bien sûr, ça n’affecte pas les jeux qui n’utilisent pas de sources C++ ).
J’ai amélioré la documentation de GDL ( Bibliothèque interne de Game Develop ) en prévision.
Le codage reste quand même pour le moment trop ardu à mon gout et le système est pas encore finalisé et tout à fait stable.

[attachment=0]CppCodeAndPtTranslation.png[/attachment]

Vous remarquez au passage la jolie traduction en Portugais qui m’a été envoyée. :slight_smile:

19

Bonne nouvelle, et donc:

ça veux dire, qu’avec juste GD on peux pas compiler de sources?
Mais qu’as termes, ça sera de plus en plus facile de compiler des extensions pour GD?

Aussi, je vois un magnifique bouton pour arrêter la compilation.
Pourrais tu en rajouter un pour arrêter la compilation d’un jeu (quand on se plante, c’est rageant, surtout si c’est long…)

Aussi, pour les erreurs de compilations de GD (du jeu) genre les fichiers introuvables, ça serait bien que l’on puisse enregistrer ça sous forme de log, comme ça, on peux facilement avoir accès aux problèmes :slight_smile: (sans re-compiler :slight_smile: )
Merci :slight_smile:

HS: Tu as une idée de date pour la prochaine version? :slight_smile:

20