Zerosquare (./17) :

Brunni (./9) :
je me suis retenu surtout pour ne pas paraître comme un rip off de pico8.

C'est dommage. Enfin je comprends le scrupule, mais :
- utiliser le même langage de script que Pico8 est justement un (gros) avantage pour ceux qui débutent et qui ont déjà joué avec Pico8
- l'utilisation de Lua dans le JV n'est pas du tout une spécificité de Pico8, historiquement un certain nombre de jeux ont fait le même choix (par exemple Escape from Monkey Island, sorti une quinzaine d'années avant)
- Lua >>> JS

Oui je suis d'accord avec tes arguments pour Lua. Dans sa forme finale je pense que le truc utilisera ce langage (ou un autre similaire), mais ça ne changera pas fondamentalement du JS. Pour ce qu'on en fait, la syntaxe est très ressemblante, et parce que je garde ça en tête depuis le début

Zerosquare (./17) :
Sinon je pense que 4 bits par canal c'est un bon compromis, c'est assez pour faire de jolies images, et pas assez pour perdre le côté "pixel art optimisé à la main". 4 bits d'alpha c'est peut-être trop "facile" par contre. Tu pourrais utiliser les 4 bits restants pour des modes (addition, soustraction, moyenne avec quelques coeffs fixes...) à la place, pour rendre les choses plus intéressantes. Par contre c'est sûr que ça va compliquer tes shaders...

C'est pas vraiment possible malheureusement parce que dans les shaders tu n'as pas accès à la couleur du framebuffer. Donc seule l'addition et l'alpha blending ne sont réalistes. L'opération que je pensais réaliser c'était :
framebuffer := (1 - sprite.alpha) * framebufferActuel.rgb + sprite.rgb
L'avantage c'est que ça permet de faire des lumières (alpha=0 => addition de couleur), rien (alpha=1 => remplacement), des ombres (sprite noir et alpha=0.5), des fantômes (avec des sprites d'une demi-intensité et alpha=0.5, on a 0.5x destination + 0.5x source), et un peu d'entre deux avec un minimum de ressources. Comme le convertisseur permet d'appliquer des "filtres" aux sprites convertis, tu peux dire "ce sera un fantôme" et la palette de sortie sera d'une demi-intensité par rapport à l'image d'origine.

Mais tu as raison que c'est probablement trop… c'est pour ça que je cherche à limiter l'usage en ne permettant qu'un "plan" transparent. Une autre solution serait de permettre un seul paramètre de transparence pour la scène entière, et ignorer entièrement le canal alpha. Le BG serait transparent ou pas, et les sprites aussi (i.e. les 32 derniers utilisent toujours l'effet, pas les 480 précédents). C'est vraiment dommage de gaspiller quatre bits ainsi. On pourrait passer à du 5 bits par composante RGB dans ce cas, mais je préfère 4.

Zerosquare (./17) :
Pour les quads, est-ce que ça vaut vraiment le coup, sachant qu'aussi bien les outils 3D que le hardware (à ma connaissance) utilisent des triangles comme base depuis belle lurette ? Il me semble que même à l'époque, c'était pas super pratique.

Hmm merci. Je me disais que ça faisait partie du challenge… mais je note. Le but était que tu fasses ta propre géométrie, pas que tu importes un modèle depuis un outil 3D (que la console n'avalera probablement pas). C'est vraiment fait pour des trucs très simples ; au contraire ça m'emmerderait que tu te sentes obligé de sortir Blender pour faire un jeu PatrickBoy qui "claque". De la même manière si tu veux texturer le sol par exemple il te faudra utiliser un BG avec transformation affine, donc faite à partir d'un quad…

Note que je réfléchis encore à la possibilité d'appliquer une matrice 2x2 de transformation pour chaque sprite comme sur GBA, permettant rotation, scaling et parallélépipède. Dans ce cas on pourrait s'en servir comme quads (encore) texturés dans une configuration isométrique. D'ailleurs à ce sujet je ne suis pas du tout sûr : sur les arcades ils pouvaient scaler les sprites de façon arbitraire, par contre sur les consoles de salon pas du tout, sauf la GBA qui supporte scaling/rotation (matrice 2x2), au sein d'un rectangle faisant jusqu'à 2x la taille d'origine du sprite, ce qui empêche de faire des sprites qui remplissent l'écran. Je ne sais pas qu'appliquer pour la Patrickboy, des sprites pouvant être rotés et scalés arbitrairement sur tout l'écran ce serait probablement trop 🤔

Zerosquare (./17) :
Le Z-sorting auto je pense que ça serait un peu de la triche. Historiquement c'était coûteux et c'est apparu assez tardivement comparé au reste.

Hmm oui. Par contre les consoles depuis le début avait la gestion de la priorité, elle était juste manuelle. J'imagine que c'est de ça que tu veux parler ? Pour convertir ces priorités sur un GPU moderne il faut forcément réordonner en Z. Par contre je peux soit le rendre transparent pour l'utilisateur, soit lui laisser accès à ça via l'ordre d'exécution (comme toutes les consoles à framebuffer, comme pico8 quoi).