PatrickBoy: fantasy console 16 bits par Brunni - Page 1

Je voulais présenter un petit projet perso que je développe depuis 2-3 semaines. C'est une fantasy console qui tourne dans un browser. Nom temporaire en référence à un ancien projet.



L'idée est venue alors que je voulais faire quelques jeux rétro pour m'amuser et refaire mon portfolio. Je pensais à un shooter comme Fantasy Zone, un platform/puzzle game sur un tableau, voire peut-être un racer basé sur Highway Runners. En faisant joujou avec divers frameworks, j'ai vu qu'ils ne permettaient pas vraiment de faire des effets rétro style linescroll, reprogrammation de palette (voire palette tout court d'ailleurs), modifier les maps/tilesets dynamiquement…

Alors je me suis dit que j'allais faire un "GPU virtuel" en me basant sur une borne d'arcade des années de ma naissance, permettant nativement ce genre d'effets un peu oubliés, quitte à mettre des contraintes. Et que pour le défi, j'allais "émuler" entièrement la machine sur le GPU avec des shaders. L'idée est venue de le faire pour le web car il y a un intérêt à réduire la taille des ressources, avoir le GPU qui fait un max pour limiter l'usage du Javascript, et la facilité ensuite de distribuer les jeux faits par la communauté. Et j'ai pris la borne d'arcade car ça m'a toujours fait rêver de travailler avec la puissance et les fonctions supplémentaires qu'elles avaient comparé aux consoles de salon.

L'idée technique c'est d'avoir un accès facile en lecture/écriture à la mémoire vidéo pour les maps, tilesets/sprites et palettes, qui sont en interne des textures séparées. La mémoire est adressée en 2 dimensions, ce qui permet de facilement se la visualiser mais aussi extraire des parties des sprites/maps/palettes existantes et les réutiliser. Un outil de conversion avec un langage simple permet d'empaqueter des objets sur ces textures, qu'on re-crée rapidement en cas de modification.

palette Persos {
	sprite mario: 'mario.png'
	sprite luigi: 'mario-luigi-2.png' [rect(80, 20, 96, 36)]
}

palette Level1 {
	map mainbg: 'mainbg.tmx'
}

palette Level1-brighter {}

Ensuite dans le jeu on peut accéder facilement à ces ressources, automatiquement toutes chargées au démarrage (puisque sur la texture principale) en 3 requêtes HTTP.

function *main(vdp) {
	while (true) {
		vdp.drawBG('mainbg');
		vdp.drawObj('mario', 0, 0);
		// Wait VBLANK
		yield 0;
	}
}

Mais aussi:

function *main(vdp) {
	// Modify palette
	const colors = vdp.readPalette('Level1');
	colors.forEach( (col, index) => {
		colors[index] = color16.multiply(col, 2.0);
	});
	vdp.writePalette('Level1-brighter', colors);

	// Copy tile 2 over tile 1 (simulates arbitrary DMA)
	const tile2 = vdp.readSprite(vdp.tileset('mainbg').tile(2));
	vdp.writeSprite(vdp.tileset('mainbg').tile(1), tile2);

	while (true) {
		// Normal intensity
		vdp.drawBG('mainbg');
		// x2 color intensity
		vdp.drawBG('mainbg', { palette: 'Level1-brighter', scrollX: 2 });
		yield 0;
	}
}

Pour donner une idée des specs, on a 4 BGs, 512 sprites, 16 couleurs par sprite/tile parmi 4096 (12 bits), 256 palettes. Les sprites sont simples & rapides (et batchés) et peuvent être étirés individuellement. Les BGs sont plus complexes, supportant notamment une matrice de transformation affine (2x3) permettant la translation/rotation/scaling qui peut être reprogrammée à chaque ligne de balayage (qui peut être horizontal, ou vertical comme à l'époque) permettant à peu près tous les effets 16-bits qu'on imagine, de Mario Kart aux tremblements de terre de Gynoug. Par défaut il n'y a pas d'effets de transparence sauf pour les 32 derniers sprites, qui supportent un packing addition de couleur + ombres, histoire de pouvoir tout dessiner en 3 drawcalls.

Au début je ne voulais pas forcément mettre de limitations arbitraires. Il faudrait forcément en avoir, vu que tout tient sur une texture, mais je les ai mises assez haut pour que ça ne gêne pas. Après tout c'est un outil pour aider à faire ce que tu veux, pas pour te limiter. Pour ça j'ai 2 versions : une "web", sans limitation (résolution arbitraire, effets de transparence sur tous les objets, support de l'alpha blending "bête", palette 32 bits "true color", tilesets/sprites 8 bits (256 couleurs), infinité de BGs et sprites dessinés dans l'ordre d'invocation, pas de système de priorités) et une version "home" qui met des limites permettant une signature "16 bits", et force à l'utiliser un minimum correctement histoire d'avoir des performances excellentes sur toutes les machines, un truc auquel je tiens particulièrement vu qu'on parle d'un navigateur web.

La version "web" serait pour mes petits jeux, mais je pensais à développer et distribuer la version "home". L'idée est de permettre de s'amuser avec des effets simples mais désormais oubliés, d'apprendre comment fonctionnaient les consoles à l'époque, se challenger, d'avoir une communauté où on se partage "ah comment tu fais tel ou tel effet?" et d'essayer d'obtenir des effets créatifs, ou au contraire exactement identiques aux arcades (cette fausse 3D).

Qu'est-ce que vous pensez de l'idée ? Est-ce quelque chose qui pourrait avoir un intérêt ? Des remarques, suggestions ? Voire envie de comprendre comment on fait/ferait telle ou telle chose ? Ca m'intéresse beaucoup, histoire d'orienter le développement (vers la poubelle au pire) et offrir quelque chose qui ait un intérêt

C'est méga cool ! ça me fascine les gens qui de façon hyper casual crééent un moteur/framework juste parce que les autres ne leur conviennent pas, genre comme si c'était une broutille de développer ça ! Chapeau j'en serai tout à fait incapable !
Une petite question en passant, j'imagine que tu as testé la console virtuelle Pico8 ? SI oui c'est quoi qui te bloquait vis-à-vis de celle-ci ? La résolution ? Ou peut-être ne dispose-t'elle pas des effets de scrolling ?

Merci pour le commentaire oui je connais la pico8, d'ailleurs je pensais demander l'avis de l'auteur avant d'en parler publiquement mais y a pas de picotachi ce mois-ci donc je me suis dit que j'allais pas attendre ;P

J'aime beaucoup et je trouve ça super sympa. Je respecte notamment le travail d'intégration, comment il entretient la communauté, écoute les utilisateurs, et les libertés (par exemple on peut dessiner des cercles, chose qui n'était pas possible à l'époque, mais qui est cohérent avec l'idée de base qui est de faire des jeux avec des contraintes pour un design simple).

Dans mon cas l'idée ressemble, un peu. Déjà je voulais jouer avec plus de puissance, plus de "technique pure", sans limiter trop agressivement la taille de la carte ou les couleurs. Ensuite j'avais mon idée de convertisseur qui mange des fichiers externes pour construire et linker la ROM, pour faciliter le travail à plusieurs en game jam. Ca n'empêche pas de faire un "OS intégré" par la suite (j'ai des idées là-dessus, avec des gros clins d'oeil à notre jeunesse) mais le découplement des outils différentie beaucoup l'usage, même par rapport à un framework de jeux web classique. J'ai aussi des idées pour la couche sonore (idéalement un synthé FM, car j'adorerais que des gens composent pour de nos jours, et ça me permettra aussi de me lancer). De la même manière, les possibilités techniques sont dans la continuité de pico8, mais le fait que ce soit implémenté sur le GPU et pensé pour créer un jeu efficace, qui tire pleinement partie de la plate-forme cible, le positionne plus comme un outil technique, utilisable pour sortir un jeu autonome. En résumé disons que ça vise des jeux un peu plus "grands" (normal vu que l'idée initiale est venue de la réalisation de mes propres jeux), tant d'un point de vue des capacités que méthodes de travail.

Mais connaissant la pico8 justement je me suis retenu de certaines idées que j'avais normalement. Notamment c'est pour ça que je suis parti sur le Javascript, même si je pense qu'à terme ce serait vraiment bien de passer sur qqch comme Lua et des instructions / mémoire limitées.

Bien sur qu'il etait possible de dessiner des cercles, du moment que tu avais un framebuffer.

PICO-8 differe des consoles d'epoque parce que c'est une machine a framebuffer.

Les fonctions de lignes, cercles et rectangles n'existe sur aucune *consoles* 8-bit d'epoque, Par contre des ordis oui.

Oui, disons qu'il n'y a pas vraiment de jeux qui dessinaient des cercles en temps réel et qui avaient un look 8 bits, et encore moins remplis, même sur PC, parce que c'est CPU intensif (et plus tard on a pu faire mieux alors les cercles étaient plutôt le symbole des early "jeux" en Win32/GDI ). Et je dis pas ça pour critiquer, au contraire, une console n'a pas à être exactement comme à l'époque, ça a même moins d'intérêt potentiellement.

(Je ne critiquais pas hein, et sur vieumicro c'etait assez utilisé il y a eu pas mal de gens qui ont planché sur les fast circle, mais bien sur sans framebuffer pas de fastcircle)

comment tu fais pour garantir que t'utilises juste 16 bits en javascript?

Très beau projet ! Fais-moi signe si tu as besoin de coup de main sur la partie sonore

Par contre le choix du JS... je comprends pourquoi d'un point de vue technique, mais perso c'est quelque chose qui me refroidirait. Outre mon opinion sur le langage en lui-même, je trouve ça vraiment anachronique pour quelque chose qui est censé évoquer l'époque des consoles 16 bits (alors que le Lua de Pico-8 est finalement assez proche du BASIC qu'on trouvait sur les ordinateurs des années 80).

Pour l'implémentation, tu as prévu que ce soit web only ? Tu as regardé ce que ça donne au niveau perfs sur un Raspberry Pi par exemple ? Un des attraits de Pico-8 c'est qu'il peut tourner même sur des petites configs (par exemple la console portable que Godzil a, dont le nom m'échappe en ce moment). Une console virtuelle c'est bien, mais pouvoir faire tourner son jeu sur du "vrai" hardware proche d'une console, c'est encore mieux

Clairement. Bon je vais reformuler plus clairement ce que je voulais dire plus tôt : oui j'ai naturellement pensé à prendre Lua parce qu'il est simple à utiliser et quand même rapide et convient bien pour des opérations un peu bas niveau comme celles que j'ai là, en plus je l'ai déjà vu tourner dans des trucs liés à mon travail (notamment https://gamebrew.org/wiki/Micro_Lua_DS, et pour le moteur de script de Highway Runners) donc je sais que *c'est bien*. Mais je me suis retenu surtout pour ne pas paraître comme un rip off de pico8.

Javascript n'est pas mauvais hein, avec les extensions pour WebGL (Uint8Array, etc.), mais je peux comprendre les a priori. Mon gros problème avec c'est que la VM n'est pas portable du tout, et que je n'ai pas moyen de throttler le CPU, ce qui confine le jeu au web ou à des apps Electron / similaire, qui font l'affaire mais contre lesquelles beaucoup de gens ont une dent, à juste titre. Lua c'est genre 10 fichiers source, pouf ça tourne partout (par contre il faut un GPU OpenGL (ES) 2.0 ou plus, les autres auront besoin d'un rendu software).

Mais pour le début je voulais faire une version débridée ("pro" que je vais renommer en "web") qui permette de voir rapidement si le modèle lui-même est agréable pour faire des jeux et ajuster un peu. Là encore, je voulais faire ces jeux pour moi et pour mon portfolio, donc c'est la techno idéale. L'intérêt que je veux sonder, c'est celui d'une version "home" qui là utiliserait un autre moteur de scripting, qui aurait des limitations un peu plus équilibrées (16x15 couleurs parmi 4096, 4 BGs, 512 sprites, priorité et transparence custom, 4 Mo de ROM, instructions/seconde et RAM limités, son FM+DAC obligatoire, etc.) et qui serait garantie de tourner sur Switch. C'est là qu'il y a beaucoup à réfléchir d'ailleurs, parce que c'est là où les limitations prennent vraiment sens. Ça paraît simple, mais on ne peut pas faire ce qu'on veut en matières de perfs, même sur des GPUs récents (bas de gamme).

Merci pour la proposition sur le son, c'est sûr que je vais avoir besoin d'aide ne serait-ce que pour déterminer les outils nécessaires, les contraintes qui ont du sens et gardent le truc fun.

En fait je pense que je vais utiliser ce topic comme un blog. J'aurais beaucoup d'éléments techniques à partager, et de questions à poser, mais c'est mieux de le faire au fil du temps 🤔

squalyl (./7) :
comment tu fais pour garantir que t'utilises juste 16 bits en javascript?

Je le fais sur le GPU (car c'est tout du float 32 bits qui transite malheureusement… donc faut se limiter à des entiers 16 bits pour avoir une précision parfaite au pixel).

Je comprends rien mais je suis pour et j'encourage

brunni: je vois

squalyl (./12) :
brunni: je vois

Mais pour répondre autrement à ta question, si tu veux des 16 bits tu peux utiliser un Int16Array aussi. Les nombres que tu manipules à l'intérieur seront toujours 16 bits. Il y a pour tous les types, et aussi Uint8ClampedArray par exemple, qui "clampe" les valeurs entre 0 et 255, assez génial pour travailler avec les couleurs

(🔽 dans le style blog post donc 🔽)

Pour la suite je réfléchis et hésite beaucoup pour les contraintes. Je pensais à priori limiter l'espace de couleur à 12 bits (4 par composante). 4 bits c'est équivalent à la Sega System 16 (un peu ma référence), et ce qu'aurait dû être la Mega Drive (finalement 3 bits + shadow/highlight qui grattent un "bit" analogique supplémentaire). C'est facile car actuellement tous les pixels passent par la "master palette", vu qu'ils sont indexés, donc je peux la faire soit en 32 bits, soit 16 (4 bits rouge, vert, bleu et 4 alpha).

← exemples de dégradés limités par le nombre de bits par composante. En haut on a 3 (Mega Drive), au milieu 4 (System 16, ma proposition) et en bas 5 (Super Nintendo).

Le but c'est que les graphismes n'utilisent pas trop de dégradés "doux" et paraissent plus "dessinés à la main". D'ailleurs la limite de 16 couleurs par tile/sprite allait déjà dans ce sens, donc pas forcément nécessaire d'avoir les 2… mais on peut tricher en faisant plein de tiles avec de petites gradations (genre 16 tiles de 16 couleurs chacune pour avoir un dégradé 8 bits), sauf que c'est compliqué et que celui qui se fait chier à faire ça pour un écran aura ensuite quelque chose qui clashe avec un reste en couleurs limitées. En plus si le convertisseur permet des couleurs 32 bits il ne fera plus la postérisation à priori donc risque de gaspiller en empaquetant des couleurs très proches.

Je pensais aussi à utiliser un framebuffer 15 bits, histoire de permettre un bit supplémentaire pour les ombres / alpha blending comme la MD et la System 16, mais c'est probablement over-engineeré (si j'écris direct dans le buffer 24 bits du browser ça m'évite une conversion à la fin, mais ça permet de tricher en superposant plein de plans semi-transparents pour obtenir un pseudo 24 bits ).

L'autre truc c'est que je réfléchissais à inclure la possibilité de dessiner des polygones (quadrilatères) non-texturés comme la Sega Model 1, sans gouraud shading (car en couleurs 12 bits ce serait moche… à reconsidérer si on passe en 24, mais du coup le look trop lisse clasherait). L'idée serait d'aider à faire des trucs comme Starfox ou Virtua Racing. Mais il y a un certain nombre de questions avec ça : combien de polygones max ? (voir la sprite limit en bas du post) Ensuite, comment ça s'insère dans la chaîne de rendu ? (§ ci-dessous)

Concernant la chaîne de rendu, j'hésite vraiment à maintenir le modèle de l'époque, où tu déclares un certain nombre de backgrounds / objets avec une priorité affectée, et le machin se débrouille pour les ordonner. L'autre possibilité c'est de la faire à la moderne, avec une liste de "commandes", genre "dessine un sprite", et l'ordre de dessin détermine le résultat final. C'est un peu plus intuitif, mais moins dans l'esprit, et on perd les avantages de pouvoir gérer les priorités manuellement (là il faudra sûrement une sprite list intermédiaire dans le programme utilisateur, qui va écrire les sprites dans l'ordre à la fin).

L'idée originale devait procéder comme suit, avec le z-testing activé (la valeur Z est la priorité du BG/sprite, entre 0 et 4) :

• Dessiner le backdrop (clear buffer d'une couleur quoi)
• Dessiner tous les sprites du plus proche (en avant) au plus loin
• Dessiner tous les BGs du plus proche au plus loin
• (Dans le design original les tiles devaient avoir un bit de priorité qui inverse la valeur Z pour cette tile de BG)
  

Ca permettrait de bénéficier du z-buffer pour ne dessiner qu'une seule fois chaque pixel de l'écran, en 3 commandes au GPU (drawcalls). Ça ne permet pas la transparence, mais ce n'est pas grave, c'est pas très 16-bit de toute façon (et rarement beau si pas fait comme il faut ). Pour ça j'ai simplement rajouté 32 sprites qui supportent la transparence par addition + shadow, dessinés en dernier du plus loin au plus proche. Ils ne pourraient que blender entre eux et au-dessus de tous les BGs/sprites existants.

Mais après test, j'ai remarqué qu'en pratique, il ne sert à rien dans ce cas d'utiliser le z-buffer avec des sprites (un discard dans le fragment shader désactive l'early depth test, et il va donc quand même rendre tous les pixels, juste ne pas les écrire s'ils sont derrière un pixel existant). De plus, l'alpha blending ne change virtuellement pas les performances*. Résultat ma contrainte ne sert à rien techniquement, et de ce que je comprends, il vaut autant tous dessiner les sprites de l'arrière à l'avant, avec un support de la transparence pour chacun. Par contre après ça devient la foire, et le look 16 bits il finit un peu aux toilettes…**

Avec ce nouveau modèle, la seule chose qu'on veut éviter c'est de switcher constamment entre le dessin d'un sprite ou d'un BG, car ce sont des shaders différents, et le switch est coûteux. En limitant à 4 BGs on "supprime" le problème (max 8 drawcalls). Mais il peut rester avantageux pour limiter l'usage de la transparence de ne pas interfolier les sprites et BGs (donc, dessiner tous les BGs d'un coup, puis tous les sprites, seulement s'ils sont au-dessus d'un pixel de BG/sprite précédent). On aurait alors les BGs qui peuvent être transparents entre eux, et les sprites aussi, au-dessus des BGs composités, mais on ne pourrait pas avoir un BG semi-transparent recouvrant un sprite. Pour éviter que les gens se servent alors des sprites pour tout, on limiterait la transparence aux 32 derniers sprites (et peut être à un seul BG désigné).

Pour comprendre l'importance de l'ordre de dessin, considérez ceci :


L'ordre de priorité est : BG1 (fond), Mario, BG2 (buisson). On dessine dans l'ordre suivant : [BGs opaques], [sprites opaques], [BG transparent], [sprites transparents].
Dans la scène de gauche, ça donne : BG1, Mario, BG2. Notez que grâce au Z-buffer, ça aurait aussi donné ce qu'on voulait même si Mario avait été dessiné avant le BG1, car au moment d'écrire les pixels du BG1, on aurait comparé leur valeur en Z, et on ne les aurait pas écrits car il y avait déjà un objet plus proche (valeur Z plus grande) sur l'écran à cet emplacement, conservant Mario intact.
Dans la scène de droite, Mario et le BG2 sont transparents. On dessine alors BG1 (opaque), BG2 (transparent), Mario (sprite transparent). Le BG2 va se mélanger comme souhaité avec BG1 lorsque dessiné, car il est en avant et dessiné par après. Ensuite vient le tour de Mario : comme il a une valeur de Z le mettant en arrière du BG2 (mais en avant du BG1), les pixels transparents de Mario ne seront écrits sur l'image qu'au-dessus des pixels du BG1, et non ceux du BG2, car BG2 est sensé obscurcir Mario ! Note qu'écrire les pixels de Mario dans ce cas n'aurait pas résolu le problème : il aurait vraiment fallu qu'on dessine le BG2 après Mario, ce qui implique d'ordonner précisément l'ordre de dessin, chose que les machines de l'époque ne faisaient pas.

A titre d'info, la Game Boy Advance aurait eu le même souci. Dans le premier cas si on avait défini BG1 et OBJ (Mario) comme "target" de la transparence et BG2 comme "source", et dans à droite si on avait défini BG1 comme "target" et BG2 et OBJ comme "source". Mais il est impossible d'avoir le rendu qu'on cherche (BG1 opaque, Mario transparent, BG2 transparent par-dessus).

Bref ça paraît pas trop mal, qu'en pensez-vous ? Le souci par contre c'est après où j'insère les quadrilatères dans la chaîne si je le fais, s'ils ont un shader séparé.

* Sauf si… je veux proposer une émulation en software de la machine pour les GPUs n'ayant pas OpenGL 2+. La transparence en soft est super coûteuse.

** Il ne faut pas oublier qu'à l'époque, la transparence ne se faisait pas par objet, mais entre "plans", et pas plus de deux "plans" ne pouvaient être mixés : par exemple on pouvait dire "le BG1 se mélange avec BG2", ou "les OBJets se mélangent avec le BG2" mais pas plus. Alors, si pour un pixel déterminé, le sprite "gagnant" (au-dessus, voire le premier remplissant la "case") était en mode transparent, alors il se voyait mixé avec le BG2, sinon on part sur le circuit de priorité qui va afficher soit l'un soit l'autre en fonction de leur priorité. Mais si 2 objets sont superposés, seul celui le plus à l'avant sera conservé et utilisé dans le calcul de transparence avec BG2. C'est pour ça qu'on ne pouvait pas faire n'importe quoi avec la transparence.

Je réfléchissais aussi à mettre une "sprite limit", qui ne peut plus être par ligne mais sur l'image entière, pour éviter de tuer les perfs en dessinant des sprites semi-transparents étirés sur l'écran entier. Je pensais à mettre un nombre max de pixels dessinables par frame, et les 2 premiers BGs ne compteraient pas dedans pour encourager les gens à s'en servir correctement (mais donner un avantage à ceux qui veulent désactiver les 2 derniers, 2x plus coûteux qu'un sprite plein écran, pour faire de la 3D avec un max de sprites/polys). En cas de dépassement, les primitives supplémentaires sont ignorées et un warning est affiché dans la console.

Tu ne t'es pas trompé dans l'ordre de dessin des BG?

C'est plus logique de faire plus loin au plus proche que l'inverse.

En fait habituellement (pour prendre la NES et SNES que je connais le mieux) tu ne fait pas BGs puis Sprites, mais tous deux en meme temps et le pipeline via l'ordre de chaque et bit de prioririté va choisir quel couleur est est effectivement affiché sur le pixel courant.

L'idée originale était de dessiner de l'avant à l'arrière toute la géométrie opaque, comme ça une fois un pixel dessiné, il est inutile de dessiner ce qu'il y a derrière, puisque il est obscurci par ce qu'il y a à l'avant.

Je pensais que ça allait améliorer les performances, car il n'y aurait pas à invoquer le fragment shader (vu que le pixel allait forcément être dismissed), coûteux puisqu'il émule le tilemap system. Mais comme je l'ai vu selon mes tests, le GPU ne fait apparemment pas cette opti dès qu'un pixel à l'avant est écrit conditionnellement (et autant un polygone peut être complètement opaque, un sprite n'est jamais un rectangle complètement opaque… du coup on a besoin d'une condition "écrire le pixel du rectangle du sprite seulement s'il n'a pas la couleur 0, définie comme transparente").

Oui pour le pipeline de la SNES. C'est probablement similaire à la GBA, qui peut ensuite mixer (additionner + multiplier) le résultat de 2 sources (ex. BG2 + OBJ) pour composer la couleur finale

Note que je pourrais faire la même chose dans mon shader, mais ça devient super engineeré pour le coup (et ça limite à un nombre fixe de BGs, et je ne suis toujours pas fixé entre 2, 4 ou 8, d'ailleurs votre opinion est bienvenue ), et pas réaliste pour un grand nombre de sprites.

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

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...

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.

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.

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).

Je comprends toujours rien, mais j'attends la sortie avec impatience

Avec quelques jeux de qualité qui montrent bien le potentiel du bazar et une bonne pub, y a moyen que ça cartonne (jeu de mots inclus )

Résultats des benchs préliminaires sur mon MacBook Pro de 2015 avec GPU intégré :

• Jusqu'à ~50000 sprites par frame (3.4 GHz).
• 20% d'usage GPU pour des sprites de 8x8, 25 Watts
• 75% d'usage GPU pour des sprites 16x16, 35 Watts
• 100% d'usage GPU, 40 FPS pour des sprites 32x32, 45 Watts
• Virtuelle mort du GPU et du browser (moins d'1 FPS, tout le système bloqué) pour des sprites 256x256, 25 Watts (le CPU est inactif)
  

Nhut: merci c'est ambitieux, mais ce serait cool par contre c'est de la communauté que va dépendre tout ça !

Brunni (./18) :
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.

Ouais j'y ai pensé aussi après avoir posté. En fait c'est de l'alpha pré-multiplié, et ça permet effectivement de faire pas mal d'effets (sauf la vraie translucidité colorée, mais on ne peut pas tout avoir).

Brunni (./18) :
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.

Brunni (./18) :
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…

Oui, c'est vrai que ça peut se défendre aussi comme point de vue.

Brunni (./18) :
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.

Ça ça peut être sympa

Brunni (./18) :
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 🤔

La Jaguar supporte le scaling arbitraire de ~0.03x à ~7.97x en temps réel, avec un coeff séparé pour X et pour Y. En non temps-réel, il y a aussi un copro qui gère entre autres les scalings et rotations, et écrit le résultat dans un buffer.
Sur Lynx il me semble qu'il y a des trucs similaires, mais Vince pourra t'en dire plus.
Donc c'est pas forcément si anachronique que ça, tout dépend de l'époque que tu vises.

Brunni (./18) :
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 ?

Oui voilà, c'est ça. L'idée est que ce soit le développeur qui soit responsable de la gestion des priorités, soit en utilisant des layers dont la priorité est prédéfinie, soit en jouant sur l'ordre de rendu.

Merci beaucoup de tes avis

J'ai pris tout ça en compte et quelques nuits blanches plus tard je crois que je suis arrivé à quelque chose de bien équilibré et assez cool je suis en train d'implémenter une première version histoire de pouvoir tester au plus vite ce que ça donne. C'est en particulier la réflexion sur la semi-transparence qui a été difficile, comment limiter fortement tout en gardant des possibilités intéressantes et même un peu uniques, et garder une performance correcte, y compris pour le cas où j'avais à implémenter un software renderer, et intégrer ça correctement avec le circuit de gestion de priorités (et pour le coup c'est assez proche de l'engineering hardware, avec juste la contrainte que ça reste implémentable raisonnablement avec OpenGL). Je compte faire un petit blog post là-dessus quand j'aurai un peu de temps.

Une question, pour organiser mes priorités, qui serait intéressé de tester une première version en Javascript pour faire joujou avec l'archi générale du truc ? L'API devrait rester compatible et les jeux portables moyennant l'adaptation de la syntaxe mais bien sûr si on trouve des trucs qui sont trop cheatés, ça pourrait changer

Sur ces derniers temps j'ai passé encore beaucoup de temps à implémenter les limites. C'est vrai que c'est un peu plus complexe (et peut-être le cas de dire, tarabiscoté) que ça en avait l'air sur le papier. Par contre le renderer est au final aussi simple qu'imaginé, et avec des performances déjà au top (comparé à Pixi), alors qu'il y a encore beaucoup de place pour optimiser. Ce n'est pas bien important dans ses limitations la PatrickBoy est très loin de mettre à genou ni le GPU ni le CPU, mais ça rend le framework compétitif en soi.

En effet, après avoir eu les retours j'ai relégué la version initialement prévue (sans limitations) au second plan, et me suis dit que j'allais faire mes petits jeux avec les limitations simplement. Comme ça ils auraient une bonne excuse pour avoir l'air super simples & rétro (mais ce serait aussi l'occasion de tenter de pousser la machine, et vérifier qu'il ne manque rien ou qu'il n'y a pas de bug). Et au final je vois que je vais pouvoir faire une version non-limitée en repartant sur la base existante, et avec les seules modifications suivantes :

• Ajouter des options pour augmenter le nombre de BG/Sprites, ce qui redimensionne le "batch" de vertices pré-alloué.
• Passer la master palette à 32 bits (au lieu de 12)
• Ajouter des options d'alpha blending tirant partie du canal alpha (alpha et premultiplied alpha, qui sont objectivement moins cool que la translucence utilisée dans le modèle limité, mais pratique dans les cas usuels)
• Surtout, permettre de "plotter" sur l'écran à tout moment en l'état. Donc si tu remarques que tu as besoin de plus de niveaux de transparence, tu peux configurer la transparence telle-quelle, ajouter les sprites que tu veux, plotter ainsi, et ensuite modifier la transparence, ajouter d'autres sprites et les plotter avec ces paramètres. A ce moment là ça ressemble plus à une API classique (style OpenGL) et c'est moins performant car tu ne bénéficies plus du batching, mais c'est ce que les autres frameworks ont à faire de toute façon en interne. Dans ce mode tu bénéficies aussi du Z buffer, ce qui permet de dessiner ta scène à peu près dans n'importe quel ordre.
  

Ca me simplifiera pas mal le développement et place l'API l'API aux premières loges question performance.

Ensuite concernant la PatrickBoy elle-même, on a donc maintenant la translucence. En fait vous ne pouvez définir qu'une seule option de transparence pour les objets, et une autre option pour le BG transparent. La formule est la suivante. L'opérateur peut être '+' ou '-'.

pixelDestination := pixelsOpaques * blendDst <operator> spriteTransparent * blendSrc

// Semi-transparence (0.5 + 0.5)
vdp.configOBJTransparency({ op: 'add', blendDst: '#888', blendSrc: '#888' });
// Simple addition de couleur
vdp.configBGTransparency({ op: 'add', blendDst: '#fff', blendSrc: '#fff' });
// Fluo vert
vdp.configOBJTransparency({ op: 'add', blendDst: '#0f0', blendSrc: '#fff' });
// Soustraction bête (peut être utilisée pour les ombres, ou un plan entier qui cache une partie de l'écran comme dans les caves de Yoshi's Island
vdp.configBGTransparency({ op: 'sub, blendDst: '#fff', blendSrc: '#fff' });

Les couleurs peuvent maintenant être définies en 12 bits (3 composantes) ou 32 bits (comme en HTML quoi). Le BG et les objets peuvent blender entre eux, mais le BG est toujours derrière (les priorités ne sont pas appliquées ; si vous réfléchissez en hardware ça n'aurait pas été possible de faire sans une grosse complexité).

Tout est batché (drawcall) correctement, les sprites transparents peuvent être sacrifiés pour servir comme "masque" (qui cache tous les pixels qui y appartiennent à moins qu'ils aient une priorité plus élevée).

Le plan de sprites peut être rotationné en entier (les sprites ne peuvent qu'être scalés). C'est prévu pour être utilisé dans des séquences de shmup, des bosses, etc. mais une over-utilisation de la rotation c'est juste moche. On s'était déjà fait la réflexion au temps de la GBA, en plus ça rendrait super difficile à implémenter la sprite limit.

Nouvelle feature aussi d'ailleurs, la sprite limit. On peut dessiner 512 sprites avec 2 BGs actifs, 384 avec 3 BGs et 256 avec 4 BGs. Un sprite ne fait pas plus que 32x32 ; ils peuvent être plus grands et sont rendus de façon transparente, mais ils consomment autant de sprites qu'ils n'occupent de "cellules" de 32x32. Donc un sprite plein écran en 256x256 consomme 64 "sprites". Les sprites qui dépassent la limite sont dessinés partiellement, pour coller à la tradition.

Il y a une gestion du framerate correcte maintenant : si ta machine a un refresh rate proche de 59.94 Hz (standard NTSC) alors aucun "frameskip" n'est opéré : un refresh de l'écran = 1 frame. En cas de dérivation, le nombre d'exécutions de la boucle principale de jeu est ajusté pour conserver la vitesse (i.e. plus de fois si ton ordi est lent, moins sur un écran 120 Hz, etc.).

Bref voilà ça avance. Je devrais avoir une version utilisable vraiment bientôt. N'hésitez pas à faire part de vos avis et suggestions

Un traducteur programmeur => grand public ne serait pas de trop dans ta future communication commerciale (un vulgarisateur programmique quoi)

Tu n'as pas l'option ?

Bon plus sérieusement c'est pas une communication commerciale, plus comme un blog technique le format. Merci de l'info, je prendrai un peu plus de temps pour vulgariser la prochaine fois ceci dit, avec des schémas et un peu plus d'explications sur le pourquoi (créatif / artistique) derrière les décisions

Ah mais il fonctionne nickel ton traducteur

Sinon oui j'ai conscience que pour l'instant tu t'adresses avant tout à tes camarades programmeurs et c'est tout à fait normal car à ce stade du développement leurs avis sont beaucoup plus pertinents que ceux d'un type qui n'y comprend rien en prog

Je peux donc juste dire: bravo, continue et courage

Désolé pour l'absence de news, je me suis concentré sur la roadmap pour avoir un truc à présenter. Et le voici : des démos, qui incluent le moteur et tout.

Je serais très intéressé de vos tests, si ça tourne, ce qui se passe (avec n'importe quelle démo, je pense que si ça ne marche pas, aucune ne marchera) et quelle est votre config (navigateur/version, matériel, en particulier CPU et carte graphique).
Un peu plus tard viendra le paquet pour développer avec, et la doc, mais d'abord j'aimerais des retours sur comment ça tourne avec les démos.

http://mobile-dev.ch/tmp/patrickboy-samples/

Il y a une dizaine de petites démos pour montrer des effets typiques du temps 16-bit comme le mode 7, les dégradés de couleur verticaux, le texte proportionnel, etc. et une petite démo de clone de Mario pas finie. A noter que les graphismes utilisés par toutes les démos font 80 ko (tous rassemblés dans 3 images), et les scripts font généralement moins d'un 1 ko. C'est vraiment un format old school, pratique pour faire des petits jeux web

Merci en avance pour les retours

Ici, ça fonctionne comme attendu avec Chrome. Avec Edge, il y a un anticrénelage qui est appliqué. Je ne sais pas si c'est voulu.
Par contre, ça ne fonctionne pas avec Internet Explorer 11. Le carré reste noir.

Machine i9-7980XE, Titan V.

Merci pour le test tant mieux. Pour Edge ouais c'est parce que le canvas est redimensionné en HTML, ça pourra se corriger par la suite.