Autour du jeu.

Un nouveau blog sur Wefrag le blog de Jol.

ecotone: Passage en fullscreen souci N°1 bugs de png

Parce qu’il y’a des trucs qui se voient et d’autres moins (genre reprendre la moitié du code….) voilà un des problèmes rencontrés lors du passage au fullscreen. Premier article d’Alain donc sur le sujet!

Et si on parlait un peu des aspects techniques d’ecotone ? Ok j’en vois déjà qui tournent les talons, attendez, je ne vais pas rentrer dans des détails trop techniques non plus, vous pouvez revenir…

Non on va rester simple, je vais vous parler de comment nous avons traité un problème que nous avons eu en passant d’un jeu fenêtré avec une résolution définie à un jeu plein écran avec une résolution variable.

C’est un problème connu, certains développeurs en herbe ou en d’autres matières sont sûrement déjà tombé dessus.

Des images valent mieux qu’un long discours, voyons donc ça avec nos amis les vers :

window1

Pas de soucis particulier en mode fenêtré, tout va bien.

Passons en mode plein écran et voilà ce que nous obtenons :

full1

Ah. Sympa. Mais d’où sortent donc ces traits verticaux et horizontaux ?

Regardons de plus près l’image png du ver :

8311

A priori rien de spécial, on a un rectangle de terre et de la transparence autour, on voit que les bords de l’asset coïncident avec les traits noirs mais pas de trace de noir. Alors qu’est-ce qui se passe, d’où sortent ces traits ?

La réponse vient de la couleur derrière la transparence. Car chaque pixel du png possède une couleur et un niveau de transparence et si on fait abstraction de la transparence, voilà à quoi ressemble notre image

color1

Du noir comme par hasard. C’est pas un délire de notre cher artiste, c’est plutôt un délire de Photoshop. Pour les pixels transparents, Photoshop met du noir, du blanc, c’est un peu selon son humeur. Il met aussi des petits ziguiguis bizarres, c’est cadeau, ça lui fait plaisir. Mais bon du coup, on commence à avoir une idée d’où peuvent sortir les traits noirs de tout à l’heure.

Alors qu’est-ce qui se passe en plein écran et pourquoi on l’a pas en fenêtré ? En fenêtré, si on n’agrandit ou ne rétrécit pas notre ver, 1 pixel écran est un pixel de texture, donc pas de soucis au niveau du rendu, la carte graphique se contente d’aller chercher le pixel qu’il faut dans la texture.

Par contre en plein écran, Stencyl retaille notre image de ver pour qu’il soit plus gros et qu’on profite de la résolution de notre écran. Du coup on est plus sur 1 pixel écran est un pixel texture mais un mélange de plusieurs pixels textures voisins.

Du fait pour nos pixels autour du bloc de terre, on a plus comme avant soit un pixel opaque marron, soit un pixel transparent noir, mais on a des pixels entre deux semi-transparent qui sont un mélange de noir et de marron.

Voilà donc d’où viennent ces fameux traits ! Il n’y a plus qu’à trouver une méthode pour y remédier. En fait la méthode que nous avons mise en place est toute simple il suffit de colorier les pixels transparents avec la couleur des pixels opaque d’à côté et le tour est joué !

Bon on peut se faire ça à la main dans photoshop ou gimp, qui est bien plus pratique sur ce point, mais vu la quantité d’assets, on n’est pas maso non plus, un tool vaut mieux que deux tu l’auras.

Alors qu’est-ce qu’il fait ce petit tool ? tout simplement il prend les pixels un par un et pour ceux qui sont transparents ou très peu opaque, et uniquement ceux là, il regarde qui sont ses voisins.

Prenons un pixel transparent, par exemple celui-là, il a l’air sympa et comme par hasard il est sur le bord de notre bloc de terre.

pixel11

On voit qu’il a des voisins transparents et des voisins non transparents. Ceux qui nous intéressent se sont ses voisins les moins transparents… ou les plus opaques, c’est selon votre humeur.

Si on regarde sans la transparence, ça nous donne ça :

pixel21

On comprend bien que ce sont les pixels opaques qui nous intéressent, si c’est pour choper le noir de son voisin transparent, aucun intérêt. On choisit le plus opaque et le plus proche dans un rayon de 2 pixels et on donne sa couleur au pixel transparent.

Et hop on fait ça pour tous les pixels, on regénère un png, et voilà ce que ça nous donne :

pixel11

Ok vous voyez pas de différence ? c’est normal. Mais si vous regardez la nouvelle couleur des pixels transparents, regardez donc notre pixel de tout à l’heure

pixel31

Et oui il est devenu couleur terre, ce qui fait que lorsque qu’on va avoir notre gloubiboulga de pixels sur le bord lors du retaillage en plein écran, la carte graphique ne mélangera que de la couleur terre pour ses pixels semi transparent du bord. Et donc tout ira pour le mieux dans le meilleur des mondes !

Une fois ce soucis résolu, il n’y a plus qu’à mettre quelques effets de brumes, glow et autres et voilà le résultat :

apres1

Voilà, j’avais envie de partager cette expérience. Si ce genre d’article vous intéresse faite le savoir, si ça ne vous intéresse pas aussi et s’il y a des amateurs pour avoir du plus pointu genre le détail du shader de god rays animé du monde aquatique ou comment faire des lucioles pas trop gourmandes en ressources, y a qu’à demander, je me ferai une joie de faire un petit article dessus !

… enfin si j’arrive à trouver un moment entre deux correctifs sur le jeu, c’est pas comme si on était en early et qu’il nous restait un peu de travail avant le launch !

5 commentaires pour “ecotone: Passage en fullscreen souci N°1 bugs de png”

  1. Caroline dit :

    Intéressant !

  2. skaven dit :

    Stencyl ne supporte pas le premultiplied alpha?

  3. Nioub dit :

    skaven a dit :
    Stencyl ne supporte pas le premultiplied alpha?

    J’allais poser la même question.

  4. Jol dit :

    j’ai posé la question à notre dev, j’attend sa réponse.

  5. Jol dit :

    Visiblement il y’a toujours le bug des commentaires en guest qui ne passent pas. Voilà donc sa réponse:

    “Voilà le dev ! Pas pu répondre car sur la route tout le week end ;)
    Alors non il n’y a pas de premultiplied dans Stencyl, il prend des png et basta. Il semble que la sous-couche OpenFL devrait pouvoir le gérer (mais à vérifier) mais se lancer la dedans casserait sûrement Stencyl du côté gestion des assets. Malgré tous les détournements et bidouilles faits sur Stencyl, un des objectifs était de le garder assez fonctionnel pour permettre de continuer à bosser sur le LD sans devoir créer de nouveaux outils, du coup, on est plutôt parti sur cette solution qui fonctionne bien et qui se passe en amont de l’intégration à Stencyl.”

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>