Gestion de l'écran

Salut,
je viens proposer des nouvelle fonctions:

-Modifier le ton de l’écran
-Modifier le ton de l’écran (Zone)
-Flasher l’écran
-Trembler l’écran

Merci :smiley:

Je suis quasi-sûr que l’on ne peut pas faire trembler l’écran, ni le flasher.
De plus, si on modifie le ton (d’ailleurs qu’entends-tu exactement par “ton” ?) de l’écran, ça ne peut pas être fait sur une zone. :wink:

Trembler l’écran tu dois pouvoir le faire toi-même en étant débrouillard…
Si tu entends par flasher, faire un blanc : idem que remarque précédente…
Le ton pareil (zone ou pas)…

Avant de demander un évènement pour faire une chose qui n’est pas forcément prioritaire, réfléchis à une manière de la faire par les évènements actuels et proposés…

PS : je me permets de dire cela car j’ai pour les 3 demandes des idées comment les réaliser sans nouveaux évènements/conditions.

Après cela n’est pas contre toi :wink:

Tout est déjà possible avec des images/objets ou en bougeant la/les caméras.

raahh 4ian je voulais qu’il cherche XD

Faudra expliquer parce que ces fonctions m’intéresseraient.

Pour le flash, c’est facile : une image blanche de 800x600 qu’on fait apparaitre et disparaitre pendant deux secondes, sur le calque le plus haut.

Pour le ton de l’écran : une image de couleur unie qu’on rend plus ou moins opaque selon le ton voulu, sur le calque le plus haut aussi.

Pour le tremblement, c’est déjà nettement plus compliqué : comment contrôler plusieurs caméra en même temps, sur plusieurs calques, tout en gardant le focus sur leur acteur respectif ?
Ex : dans mon jeu, la caméra du calque de base suit le vaisseau joueur, les autres caméras suivent leurs calques inférieurs et supérieurs à leur manière.
Comment je fais pour que dès que mon vaisseau est touché, tous les calques tremblent à l’unisson, mais que tous gardent leur objet de référence ?
Bien sûr, il faut aussi que le jeu se poursuive pendant ce tremblement, et que le joueur puisse contrôler son vaisseau durant ce laps de temps.

Le problème ici est, je pense, qu’on ne peut pas agir directement sur les caméras.
Il faut toujours passer par un objet, sur lequel la caméra centre en permanence.
Ce serait plus simple, si on pouvait diriger les caméras comme un sprite classique.

En effet, pourquoi dupliquer inutilement les fonctionnalités ? ( Ce qui implique augmenter les poids des jeux, les risques d’erreurs, les risques d’oubli de mise à jour si je modifie quelque chose, la difficulté de faire des modifs importantes au niveau du code… ). Une bonne technique est d’utiliser un objet ( Sprite par exemple ) permettant d’accéder automatiquement à tout ce qu’offre les objets : Test de position, de distance, de vitesse, ajout de forces, mise en rotation, automatismes… C’est pour ça que les fonctions relatives au caméra n’ont que le “minimum”, ce qui permet de conserver des actions simples, claires et efficaces.

  1. Il suffit d’ajouter un évènement au début pour centrer la caméra dessus un objet, invisible, servant de représentation de la caméra sur la scène.
  2. Ensuite, quand on souhaite bouger la caméra, on bouge cette objet
  3. Si on veut un petit tremblement, une technique est de faire par exemple :

Faire +Random(2)-Random(2) à la position X de MonObjet Faire +Random(2)-Random(2) à la position X de MonObjet

Pour faire trembler différents calques à l’unisson, même technique en stockant auparavant les valeurs aléatoires créés dans deux variables, puis en les appliquant à la position des objets suivis par les caméras.

Parce que ça permet de reproduire sur un nouvel élément ce qu’on a appris avec un précédent ? :stuck_out_tongue:
Imagine que le VBA Word soit différent du VBA Excel.
Pas cool pour le processus d’apprentissage …

L’autre souci avec l’objet sprite comme camera, c’est qu’il faut le créer dans la bibliothèque d’objets avant de pouvoir s’en servir.
Ce qui élimine de fait l’utilisation d’évènements externes, et par extension les templates.
Templates qui seraient tout à fait indiqués pour ce genre d’usage (fonction simple et utile pour tout type de projet, à appeler ponctuellement).

Dans mon cas, ça me fait 5 cameras en sprite à gérer au minimum, et juste pour un effet Tremblement.
Et il faut aussi que j’adapte mon vaisseau pour qu’il suive la caméra invisible, et non plus qu’il réagisse directement aux contrôles.
Ca demande une gymnastique supplémentaire.

Dans RPG Maker (pour continuer les comparaisons obscures :sunglasses: ), ça se gère en une ligne d’instruction.

Par contre, l’instruction +Random(2)-Random(2) est intéressante.
Je n’avais pas pensé à cette combinaison pour avoir un +/- aléatoire. :smiley:

Il suffit de créer l’objet dans toutes les scènes qui utilisent cet feuille d’événements externes ou alors de créer un objet aléatoire. :wink:

On peut tout à fait utiliser des objets dans les évènements externes, il faut sélectionner la scène qu’on souhaite en haut quand on édite les évènements externes afin d’accéder à ses objets/variables.

Pour les templates, un simple paramètre “Objet caméra” et ça le fait. Encore mieux, le modèle d’évènement s’étend alors aux objets.

C’est exactement ce que je prône par l’utilisation d’un objet :
En mettant le strict “minimum” aux caméras, ça incite à utiliser un objet pour diriger la caméra, ce qui permet d’utiliser tout ce qu’on sait des objets sur les caméras.

La beauté de la réutilisation des connaissances dans son plus bel état. :slight_smile:

Je ne suis pas d’accord, il s’agit ici d’un langage. Dans notre cas, il s’agit de recréer ou non des fonctionnalités qui peuvent être reproduite en ajoutant un simple objet.
Au contraire, en utilisant un objet, tu utilise exactement ce que tu connais, et non pas des actions spécifiques aux caméras qui pourraient être légèrement différente et tromper l’utilisateur.

Juste un effet Tremblement au départ peut être, mais quand tu va vouloir faire tourner ta caméra autour d’un point, va tu me demander d’ajouter une action pour faire tourner la caméra autour d’un point ?
Non, car l’action sera déjà disponible.
Et quand tu voudra tester la vitesse de la caméra ? Nouvelle action ? Non, il suffira de tester la vitesse de l’objet. Idem pour les tests de distance. Idem pour tester dans quelle direction la caméra va.

Comment on fait pour faire trembler un personnage dans RPG Maker ?
On ne peut pas. Dans Game Develop, ça se gère en une ligne d’instruction. :wink:

Vraiment, le principe d’utiliser un objet pour diriger une caméra est quelque chose qui permet d’apporter toute la puissance déjà existante des objets aux caméras, sans devoir dupliquer le code ou réapprendre des actions similaires mais pas pareils.

Ah la la, toujours le dernier mot notre petit 4ian
mais le pire c’est qu’il as raison

Avec RPG Maker on étais très vite limité et falais passer par monsieur Ruby
alors que la c’est carement plus simple puisque on peut tous faire ou presque
c’est sa la force de game develop je trouve

C’est parce que je n’avais pas vu qu’il avait répondu. :stuck_out_tongue:

Utiliser un objet pour manipuler indirectement un autre objet, je trouve ça quand même un peu bricolé.
Dans Blender (comparaison obscure inside :sunglasses: ), l’objet caméra est manipulable de la même manière qu’un cube ou qu’un nurbs.
Pas besoin de créer un cube, de le lier à la caméra, et de le rendre invisible à chaque fois qu’on veut un rendu de la scène.
La caméra Trans/Scal/Rot comme si c’était un objet 3D classique.

A la limite, ce serait plus logique d’avoir un objet Camera dans GD, qui fonctionnerait comme un objet Sprite, sauf que ce serait un No de caméra et non plus un fichier image, qui serait géré.

Car dans le système actuel, il y a quand même de la redondance.
Devoir recréer pour chaque scène, chaque projet, le même objet que l’on a déjà créé des dizaines de fois avant, et tout ça pour un effet “basique” … :neutral_face:
L’idée des Templates, ce n’est pas “J’importe et ça marche tout seul” ?
Ce serait bien de pouvoir ajouter à la bibliothèque des objets depuis les évènements.
Ca résoudrais déjà ce problème de redondance de création à chaque scène.

Mais bon, ça n’empêche la Terre de tourner, et GD de compiler. :wink: