Unity : Résolution d’un problème d’affichage entre deux objets possédant des shaders transparents

J’ai réalisé aujourd’hui quelques correctifs sur mon jeu Bulldozer sortie sur Android l’an dernier, dont la correction d’un problème d’affichage sur les scores affichés quand le Bulldozer se déplace, mais uniquement si le score est affiché au-dessus de la mer.

Le problème survient entre la mer et les objets de type TextMeshPro que j’utilise pour afficher le texte des scores.

Constatation

  • La mer a son propre shader que j’ai récupéré dans un asset.
  • L’objet TextMeshPro utilise une police d’écriture sous forme d’image et son shader sert à définir la façon de rendre la police.

Pour les deux shaders, celui de la mer et celui de la police d’écriture, il y a utilisation du canal alpha. Le canal alpha c’est le canal qui est utilisé pour gérer la transparence. Le canal alpha n’est pas utilisé dans les shaders utilisés les cases, les bulldozers ou les arbres. Or j’ai des problèmes d’affichage uniquement entre la mer et le texte des scores.

Cet élément après de longue recherche m’a fait trouver qu’il y avait des problèmes d’affichages de ce type lorsque deux shaders utilisant la transparence sont paramétrés sur la même renderQueue.

La renderQueue selon la documentation unity c’est ce qui détermine dans quel ordre les objets sont rendus. Dans mon cas les deux étaient paramétrés sur 3000. En modifiant la valeur de la renderQueue de 3000 à 3000-1 soit 2999 pour le shader de mer j’ai résolu le   problème et mes objets s’affichent dans le bon ordre sans se marcher dessus l’un et l’autre.

En conclusion si vous avez des problèmes d’affichage entre deux objets qui utilisent la transparence alors vérifiez et modifiez la valeur de la renderQueue en fonction de l’objet que vous souhaitez voir afficher au-dessus de l’autre.

Télécharger le jeu Bulldozer pour Android

Fusion automatique de branches avec Github Actions

Un projet récent sur lequel je travaille dispose d’une branche, qui, lorsque celle-ci reçoit des modifications, déclenche un événement dans notre système de déploiement continue, afin de déployer le contenu de la branche sur notre environnement de développement. Avec l’augmentation des effectifs de développeurs sur le projet, et pour essayer de garder un environnement de développement le plus à jour possible et faciliter le test des nouvelles fonctionnalités ou des corrections, je me suis penché sur la question de la fusion automatique de branches avec les Github Actions.

Voici un exemple de configuration fonctionnelle:

name: auto-merge
on:
  workflow_dispatch:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron: '0 7 * * 1-5'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: master
          fetch-depth: 0
      - name: Merge on dev-env
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          git config --global pull.ff only
          git checkout dev-env
          git pull
          git merge master
          git push

Dans cet exemple, tous les jours du lundi au vendredi à 7h, la branche master sera fusionnée dans la branche dev-env et poussée dans le dépôt distant, déclenchant ainsi le processus de déploiement automatisé.

cmd#9 – Git: mise à jour « forcée » depuis le dépôt distant

Dans un script automatique, dont le but est de mettre à jour le code local d’un dépôt git avec celui du dépôt distant, sans prendre en compte ni même conserver les éventuelles modifications locales, l’enchaînement de commande git est le suivant:

git fetch
git reset --hard HEAD
git merge '@{u}'

Avec '@{u}', un raccourci pointant vers la branche upstream de la branche courante.

cmd#8 – sed et sudo

Récemment, j’ai été confronté à une erreur de droit sur l’une des étapes d’un script bash. Sans possibilité d’agir sur le contexte d’exécution du script, celui-ci utilise l’instruction sudo pour chaque opération. L’une des étapes utilise sed et un opérateur de redirection, afin de modifier un paramètre du fichier fournissant les variables d’environnement, seulement, le sudo associé à sed ne permet pas de procéder à l’écriture du fichier temporaire .env-tmp.

sudo sed 's/API_ENABLED=false/API_ENABLED=true/g' .env > .env-tmp
sudo mv .env-tmp .env

La solution, pourtant simple, consiste en l’utilisation de l’option -i, pour effectuer le changement voulu.

sudo sed -i 's/API_ENABLED=false/API_ENABLED=true/g' .env

Je m’étonne que nous ne l’ayons pas vu au moment de l’écriture du script.

Indisponibilité: une histoire de certificat

Quelques lignes ce soir, pour signaler que le problème de certificat expiré présent sur Unicoda depuis une quinzaine de jours est maintenant résolu. Lors de la dernière migration du site pour son retour vers OVH, j’avais malheureusement omis de noter la date d’expiration du certificat, pour vérifier que le renouvellement automatique fonctionnait bien.

Et bien, cela n’a pas manqué, les certificats n’ont pas été renouvelé automatiquement, et je n’ai constaté le problème qu’aujourd’hui. C’est une nouvelle preuve du manque de surveillance qui s’illustre ici. Le besoin s’oriente donc, vers un ou des outils de surveillance des performances du serveur, des logs et du bon chargement de la page, ou plus simplement des dates de validité des certificats.