Unity 2D : Les pièges à éviter...

[Roscopolo]

Sous quel format dois-je exporter mes sprites ? SVG ? Png 8 ou 24 ? Doit/Peut-on utiliser des Jpeg pour les fonds opaques ?

Unity se chargera de tout convertir au format natif de la plateforme ciblée (DDS par ex). Donc utilise le format qui t'arrange le mieux parmi ceux supportés. Moi je prendrais PNG plutôt que JPEG, pour éviter les artefacts de compression. Quant à SVG il n'est pas reconnu je crois, en revanche PSD l'est.

[Ashley TOUCRU]

Merci pour vos réponses. Je vais faire simple et me contenter de Png. J'avais vu cette vidéo que j'avais trouvée intéressante étant donné que j'ai l'habitude de bosser nativement en vectoriel, mais ça risque d'être compliqué et comme c'est pas donné...

[Enyss]

Tiens, les grands gourous d'Unity (boing boing), j'ai un petit problème de collisions...

voici la situation :


Le problème c'est que de temps à autre, lorsque le perso longe le mur, il se coince sur le bord. Chaque tile a sa BoxCollision2D, vu que les niveaux vont être générés procéduralement (et seront dynamiques)

Si vous avez des idées de solutions...

[Louck]

Ahah le bug classique . Un bug un peu idiot (made in unity) mais très pénible.

En gros, même si les zones de collisions sont bien côté à côte et sans espaces, le moteur du jeu considère (au fixedupdate près) que ton personnage touche le recoin d'une de ces zones, et qu'il entre en collision. Et étant donné que la hitbox de ton personnage est un BoxCollider, il s’arrête net.

C'est pire pour les jeux de plateformes, où la gravité force le protagoniste à entrer en collision.


Il existe deux solutions à ce problème:

- Ne pas utiliser plusieurs BoxColliders pour les collisions de map, mais plutôt un seul (ou quelques-uns) EdgeCollider. L’intérêt est de ne pas surcharger le jeu de colliders (optimisation, tout ca). Cependant, le EdgeCollider est très limité en terme de collision (étant donné que ce n'est qu'un "fil"), donc sauf si le jeu n'utilise pas des entités à haute vélocité, il faut faire attention avec ce collider (ou attendre une mise à jour d'Unity).

- Solution plus simple: Arrondir les recoins de la hitbox du personnage en utilisant le PolygonCollider, de façon à ce que le contact avec le recoin des autres colliders n'immobilisent pas le personnage (par contre, il faut juste s'assurer que le personnage ne se retourne pas en cas de collision).
Comme ca:

[Grhyll]

Encore plus simple et économique (mais éventuellement limité en fonction de ce que tu projettes de faire), utiliser un Circle (ou Sphere) collider !

[Enyss]

Merci ! c'est grosso-modo ce que j'avais envisagé comme solutions... Déjà je suis content d'avoir correctement deviné la cause.

Finalement, j'utilise la deuxième solution de Louck, ça saute légèrement au lieu de bloquer, mais c'est déjà moins gênant (surtout que c'est en vue de dessus, donc on ne passe pas son temps à longer les colliders).

[Ashley TOUCRU]

Encore plus simple et économique (mais éventuellement limité en fonction de ce que tu projettes de faire), utiliser un Circle (ou Sphere) collider !

Ouaip. C'est ce qu'explique Casanis dans cette vidéo. Je trouve ses tuto super bien foutus. Je pense grandement m'en inspirer pour mon mini-projet :



J'espère que j'ai linké la bonne vidéo, sinon regarde dans sa playlist.

[Enyss]

Voilà à quoi je suis arrivé :



Bon, je suis con, j'ai oublié de montrer la collision du player ^^

[Ashley TOUCRU]

Voilà à quoi je suis arrivé :



Bon, je suis con, j'ai oublié de montrer la collision du player ^^

J'espère en arriver bientôt à peu près là sans trop de difficultés. Ce serait déjà bien !

[saroumana]

Question bête : comment faire pour avoir un scrolling fluide avec une camera 2d ?

En fouillant, j'ai tenté diverses méthodes

transform.position = new Vector3(transform.position.x +( speedX * Time.deltaTime), transform.position.y +( speedY * Time.deltaTime), transform.position.z);

En modifiant directement la position de la camera

transform.position = Vector3.Lerp(transform.position, target, 1);
transform.position = Vector3.MoveTowards(transform.position, target, Time.deltaTime * speed);

Avec la commande Lerp ou MoveTowards. Mais a chaque fois y a de légère saccade, c'est loin d’être le scrolling fluide qui ne fait pas mal au yeux.
Du coup, j'ai aussi tenté sans synchronisation verticale, puis en la réactivant et en réglant le framerate a 60fps. En déplaçant la fonction sur LateUpdate, FixedUpdate ou Update, mais rien n'y fait, le déplacement de la camera n'est pas propre.

[Grhyll]

J'ai déjà eu des soucis du genre. Est-ce que tu utilises la physique dans ton jeu ? Parfois le déplacement de la caméra en lui-même est clean, mais le déplacement d'objets dans le jeu n'est pas synchro avec, et ça donne l'impression que c'est la caméra la fautive. Si tu utilises la physique, alors tes objets vont être bougés dans la FixedUpdate mais ta caméra est rendue dans l'Update. Je suis à peu près certain qu'il y a des solutions, mais je n'en ai plus en tête, là de suite, je refouillerai dans mes vieux projets si personne ne sait te dire.
(Note que mon explication est potentiellement foireuse, mais je suis à moitié endormi, là de suite ^^')

[Louck]

Il y a de ca, mais c'est aussi un peu plus subtil.

Tout d'abord, l'idéal pour la caméra, est de faire son déplacement dans le LateUpdate (qui est exécuté après tous les updates des composants, et après tous les tests physiques, juste avant la génération de la frame).

Ensuite, comme dit au dessus, il faut s'assurer que l'objet, que suit la caméra, se déplace bien de façon monotone: si dans une frame il se déplace de 10 pixels, alors que dans une autre il ne bouge que de 8 (ce qui peut se produire avec la physique du moteur), ca va créer une saccade au niveau de la caméra. Sinon il faut utiliser le Lerp pour éviter le saccade, pour "fluidifier" le mouvement.


D'ailleurs, tu as fais une erreur:

transform.position = Vector3.Lerp(transform.position, target, 1);

Ca équivaut à dire :

transform.position = target;

Car tu as fixé l'interpolant T à 1.

Essayes quelque chose comme ca, plutôt:

transform.position = Vector3.Lerp(transform.position, target, Time.deltaTime * POWER);

Où "POWER" définit si le Lerp doit être rapide (avec une grosse valeur) ou lent (avec une petite valeur, strictement supérieur à 0).

[saroumana]

En fait, j'avais deja appliqué le Time.DeltaTime sur la target avec

target = transform.position + new Vector3(Input.GetAxisRaw("Horizontal") * speed * Time.deltaTime, Input.GetAxisRaw("Vertical") * speed * Time.deltaTime, 0);

J'ai tenté en rajoutant deltatime * speed sur le lerp / movetoward. Faut augmenter la valeur de speed pour que le déplacement se fasse a la même vitesse, mais pareil. Ça avance presque de manière fluide puis ça saccade un coup. Presque toutes les secondes. J'ai vérifié avec process explorer mais j'ai rien qui sature le cpu.

J'ai déjà eu des soucis du genre. Est-ce que tu utilises la physique dans ton jeu ? Parfois le déplacement de la caméra en lui-même est clean, mais le déplacement d'objets dans le jeu n'est pas synchro avec, et ça donne l'impression que c'est la caméra la fautive. Si tu utilises la physique, alors tes objets vont être bougés dans la FixedUpdate mais ta caméra est rendue dans l'Update. Je suis à peu près certain qu'il y a des solutions, mais je n'en ai plus en tête, là de suite, je refouillerai dans mes vieux projets si personne ne sait te dire.
(Note que mon explication est potentiellement foireuse, mais je suis à moitié endormi, là de suite ^^')

non c'est très clair.
Je fais que tester un peu unity pour voir son potentiel. Et dans la scène, il n'y a que 100*100 sprites qui ne bougent pas. Seul la camera se déplace. Il n'y a rien d'autre, ni aucun script hors camera et génération des sprites au départ.

[Grhyll]

Ah ben punaise, avec une scène aussi simple je vois pas bien ce qu'il peut se passer :/ Tu peux éventuellement aller checker dans le Profiler si tu n'as pas des pics, mais je vois pas ce qui pourrait les provoquer sans script dans la scène...

[saroumana]

J'ai regardé avec le profiler et rajouté un compteur FPS. Niveau fps je suis constamment a 59fps. Le profiler ressemble a un oscilloscope pour la mémoire même lorsqu'il se passe rien. Le son bouge légèrement alors qu'il en a pas. Pour la section graphique, il a des pics mais vers un frame plus rapide, ce qui devrait normalement ne pas affecter le scrolling.
Le mystère reste donc entier.