Présentez ici vos projets de jeux avec Construct 2.
Avatar de l’utilisateur
par Squale
#10799 Esaaye de remplacer touching par touched pour voir.
Avatar de l’utilisateur
par absolu
#10812 Ça marche, mais là, c'est le muted / unmuted qui semble fonctionner que sur le web et pas sur smartphone.

J'ai remis une nouvelle version en ligne.

Est ce que ça vient de mon tel uniquement ?
Avatar de l’utilisateur
par absolu
#10821 Voilà le code :

Image

Uploaded with ImageShack.us

Si je mets stop ou play, d'un point de vue tactile, ça marche. Mais si j'utilise la fonction mute / unmute, ça ne fonctionne pas.

Vous avez une idée ?
Avatar de l’utilisateur
par purpleunicorn
#10822 tu remet l'animation frame à 0 avant de unmute je pense
Avatar de l’utilisateur
par absolu
#10823 C'est le cas déjà ? avec le else.
Avatar de l’utilisateur
par The_Lord_King
#10825
purpleunicorn a écrit:tu remet l'animation frame à 0 avant de unmute je pense


Si j'ai bien compris le pourquoi de ta remarque : ca va bien jusqu'au bout du Else, donc ca devrait unmute quand même.

Après tu peux toujours essayer de les inverser mais je doute que ca marche. :mrgreen:
Avatar de l’utilisateur
par naelian
#10830 Un problème type "iphone" probablement ... le premier son doit être initialisé par une commande play lié à une action utilisateur, c'est pourquoi cela marche quand tu remplaces le unmute par un play car le système "voit" que celui ci dépend d'un touched ... à l'inverse dans ton exemple le play est forcé et non lié à une action utilisateur donc il n'est pas actif et ignoré et donc mute et unmute ne fonctionnent pas plus.

Essaye cela :

la première fois que l'objet est touché dans le jeu fait un play et ensuite suivant le cas un mute/unmute, tu peux créer une instance de variable dans l'objet touché et tester sa valeur pour vérifier si c'est la première fois ou pas ...

Exemple avec une variable d'instance "status" dans ton objet touché (blabla) avec une valeur par défaut de -1

si blabla touched
.... si blabla.status = -1 => set blabla.status = 1 puis play et blabla.animation.frame = blabla.status donc 1
......... sinon
... si blabla.status = 1 => set blabla.status = 0 puis mute et blabla.animation.frame = blabla.status donc 0
......... sinon
... si blabla.status = 0 => set blabla.status = 1 puis unmute et blabla.animation.frame = blabla.status donc 1

tu peux éviter la variable aussi en créant une frame en plus dans l'objet touché de valeur 2 et correspondant à une image de son non permis (mettre alors par défaut animation.frame à 2 dans ce cas) et tester modifier uniquement cette valeur comme ci dessous :

si blabla touched
.... si blabla.animation.frame = 2 => play et blabla.animation.frame = 1
......... sinon
... si blabla.animation.frame = 1 => mute et blabla.animation.frame = 0
......... sinon
... si blabla.animation.frame = 0 => unmute et blabla.animation.frame = 1

La différence à noter est que par défaut le son est inactif et non actif, c'était d'ailleurs le comportement normal ios/safari qui considère le son comme une potentielle nuisance nécessitant une action explicite de l'utilisateur au même titre qu'un passage en plein écran par exemple.

Une fois un son lancé de cette manière tout les autres sons utilisés ensuite marchent sans contraintes voilà pourquoi en général un jeu demande avant toute chose de toucher l'écran (voir exemple spaceblaster) afin de lancer le play d'au moins 1 son.
Avatar de l’utilisateur
par absolu
#10835 Ouaww !

Merci pour cette explication. Je comprends la philosophie, mais je ne vois pas trop comment traduire cela en syntaxe construct 2 ?

Tu aurais un exemple stp ?
Avatar de l’utilisateur
par naelian
#10836
absolu a écrit:Ouaww !

Merci pour cette explication. Je comprends la philosophie, mais je ne vois pas trop comment traduire cela en syntaxe construct 2 ?

Tu aurais un exemple stp ?


Déjà ne fais pas le play dans ton "on start layout", si j'ai vu juste il est ignoré ... essaye de le remplacer par un "preload" ... si il marche cela évitera un temps d'attente la première fois que le son sera joué.

(un event ) Touch > On touched audiosique

(ensuite sous event du premier touch) audiosique > animation frame = 2
=> (avec action ligne 1) Audio > Play (pareil que ton code actuel dans ton Play)
=> (et action ligne 2) audiosique > set animation.frame to 1

(ensuite sous event du premier touch) system > else
("ET") audiosique > animation frame = 0
=> (action ligne 1) Audio > Unmute (pareil que ton code actuel dans ton unmute)
=> (action ligne 2) audiosique > set animation.frame to 1

(ensuite sous event du premier touch) system > else
("ET") audiosique > animation frame = 1 (cette ligne est normalement pas nécessaire !)
=> (action ligne 1) Audio > Mute (pareil que ton code actuel dans ton mute)
=> (action ligne 2) audiosique > set animation.frame to 0

Ton sprite "audiosique" dans ce cas doit avoir 3 images et non 2, càd n° 0 1 2 qui suivent la logique suivante :

0 sera l'image affichée quand le son est en pause
1 sera l'image affichée quand le son est en play
2 sera l'image affichée quand le son n'est pas autorisé ce qui doit être le cas par défaut, donc dans les propriétés de l'objet "audiosique" placer frame à 2

Regarde bien c'est finalement très proche de ton code actuel mais avec un test en plus.
Avatar de l’utilisateur
par absolu
#10848 Merci pour ta patience Naelian !!

Je vais m'attaquer au son demain. Faut absolument que je termine ces problèmes d'interface.

Là, j'ai intégré le PAD analogique, pour une utilisation sur écran tactile et il y a le bouton rouge à droite pour les coups de massue.
En allant vers le bas, le player met un coup de pied (ce qui est utile pour reprendre de la vitalité avec les fleurs en surface et sous-sol).

http://graphicwindows.fr/paleotheque/

Toute la partie interface sera refaite sur le graphisme, donc je ne fais pas de la dentelle, pour l'instant.

Demain, j'aimerai bien résoudre les problèmes audio d'interface, pour après me relancer dans le vif du sujet :

Ajouter les règles du jeux aux différentes conditions de collisions avec tel ou tel objet, scoring, etc...
Ajouter des chek-points pour les reprises de vie / arrivée au boss, etc...

Ensuite faudra tout débugger.