Il y a un peu plus d’un an de cela, j’avais publié une dépêche sur Pico‑8, TIC‑80 et les consoles imaginaires, laquelle avait eu un certain succès.
Ces « consoles imaginaires » sont des systèmes pour la création de jeux, basés sur des caractéristiques définies, et reprenant un look vaguement rétro, sur le modèle des ordinateurs et consoles 8 bits du siècle dernier. Il s’agit de logiciels et non pas de machines physiques, même si l’on peut s’en rapprocher, comme on le verra plus bas.
Cette fois‑ci, je ne vais pas parler de Pico‑8, qui est très bien en soi, avec notamment une importante communauté (c’est un des premiers logiciels de ce type), mais qui n’est malheureusement pas libre, et plutôt me concentrer sur une alternative entièrement libre, sous licence MIT, et franchement enthousiasmante : TIC‑80. En effet, Vadim Grigoruk, le développeur principal, a annoncé la sortie de la version 0.80 le 25 septembre 2020 dernier, et c’est donc l’occasion d’en faire la promotion via cette dépêche. Il y a d’ailleurs eu beaucoup de changements par rapport à la version 0.70 sortie plus de deux ans auparavant.
Rappelons les spécifications internes de TIC‑80, qui sont les suivantes :
- affichage : écran de 240 × 136 pixels, palette de seize couleurs ;
- entrées : deux contrôleurs de jeu avec huit boutons, la souris est optionnelle ;
- sprites (éléments de base) : 256 sprites en premier plan (taille 8 × 8) et 256 sprites en arrière‑plan (taille 8 × 8) — il est possible de combiner ces sprites pour en réaliser de plus grands, mais cela en diminue d’autant le nombre maximum ;
- carte (de jeu) : cellules de 240 × 136 pixels (par écran) et 1 920 × 1 088 pixels maximum ;
- sons : quatre canaux avec des ondes sonores configurables ;
- code : 64 Kio maximum (512 Kio dans la version « pro », qui est libre également, mais qui sert surtout à aider le développeur) ; programmation en Lua, MoonScript, JavaScript, Wren ou Fennel.
On notera également que l’EDI pour développer est entièrement contenu dans les contraintes énoncées plus haut, si bien que l’immersion est totale, et le parallèle avec un ordinateur de l’époque 8 bits est d’autant plus pertinent : on fait comme si la machine se suffisait à elle‑même, et il n’est pas nécessaire de recourir à des outils extérieurs, même s’il reste possible d’importer du contenu généré ailleurs, images ou code.
Nouveautés
Depuis la 0.70, l’interface a été un peu modifiée et peaufinée, et les couleurs par défaut optimisées, en utilisant dorénavant la palette Sweetie 16. Il est également possible d’augmenter le nombre de sprites en réduisant le nombre de couleurs.
Le son passe en stéréo, il y a de nouveaux effets sonores et, en plus d’un éditeur de musique sous forme de Tracker, cette nouvelle version propose une sorte de « piano roll » (rouleau de piano pneumatique), où l’on peut entrer les notes sur un clavier de piano, comme dans certains éditeurs MIDI.
Bonne nouvelle pour les joueurs adeptes des consoles physiques, puisqu’un portage de TIC‑80 pour la Nintendo 3DS a été réalisé, ainsi qu’une version pour Libretro (une API qui sert de base au système d’émulation RetroArch), ce qui ouvre de nouvelles perspectives.
Rappelons que TIC‑80 fonctionne sous GNU/Linux et autres dérivés UNIX, Windows, macOS et Android, et l’on peut également exporter en version HTML pour des jeux depuis un navigateur. Il existe également une version Raspberry Pi « bare metal » (utilisant les bibliothèques circle et circle-stdlib) démarrant en quelques secondes, ce qui en fait presque une console matérielle, même si ce n’est pas sur du matériel dédié.
Prise en main rapide
Pour utiliser TIC‑80, c’est facile, on exécute le binaire, on tape la commande surf, et l’on peut accéder directement à des jeux en ligne (8 Bit Panda, est très chouette par exemple). Appuyez sur z pour sélectionner un jeu. Jouez un peu, puis appuyez sur Échap. Choisissez « close game », z pour valider, vous revenez sur l’interface de « surf », qui permet de sélectionner un autre jeu. Mais si vous appuyez de nouveau sur Échap, vous entrez dans l’interface en ligne de commande. Appuyez sur F1, vous avez accès au code et pouvez le modifier. Appuyez sur F2, vous avez accès aux sprites. Faites vos modifications, appuyez sur Échap de nouveau, tapez run, et vous pouvez jouer avec votre version modifiée !
En conclusion
Le développement de TIC‑80 semblait au point mort l’année dernière. Mais depuis quelques mois, il a repris de plus belle, laissant présager de nombreuses améliorations futures.
L’équipe de développement est d’ailleurs à l’écoute et accepte facilement des contributions de code.
Cet écosystème grandissant, cela encouragera à créer toujours plus de contenu sous forme de nouveaux jeux, de démos et d’outils amusants.
L’essayer, c’est l’adopter !
# Super !
Posté par negatif . Évalué à 4.
C’est vraiment fou ce projet !
J’adore ça … un retour à mon C64 mais soft :-)
Je m’en vais télécharger ça !
# Config
Posté par gUI (Mastodon) . Évalué à 4.
J'ai un eeePC 701 (premier du nom) qui dort dans le placard. Aujourd'hui il a une Debian uniquement en ligne de commande (ça m'a servi de console SSH en fait).
Est-ce que ça peut tourner dessus ? Il y a deux questions cachées :
- a-t-on besoin d'un serveur X ?
- faut-il un CPU un peu musclé ?
Merci
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Config
Posté par zurvan . Évalué à 5.
je crains que malheureusement ta config soit un peu juste pour TIC-80.
J'ai un pocketchip, qui est plus puissant que l'eeepc 701 (que je possède également). Et tic-80 ne tourne pas super dessus. Je crois également que ça utilise des techno récentes et gourmande genre Mesa / opengl et compagnie.
La version précédente semble tourner plus vite :
https://github.com/nesbox/TIC-80/issues/1205
après, il faudra aussi réussir à la compiler sur le vieux eeepc 701
Certains jeux tournent mieux que d'autres aussi :
https://github.com/nesbox/TIC-80/issues/1215
Après, selon l'utilisation, ça peut passer ou pas. Par exemple certaines jeux tournent plutôt pas mal sur la version 3DS, qui est pourtant moins puissant (800 mhz, 256 mo de ram) que l'eeepc. Bon a priori l'eeepc n'a pas un processeur vraiment mieux que la new 3DS : Celeron M ULV 900 Mhz fonctionnant à 630 mhz, mais avec 512 mo de ram.
En plus a priori il faut un serveur X, mais c'est peut-être possible de s'en passer : https://github.com/nesbox/TIC-80/issues/1084
Peut-être que pico-8 sera moins gourmand (mais ce dernier est non libre et payant).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Config
Posté par tao popus . Évalué à 3.
Comme souligné, c'est pas mal basé sur OpenGL, hors le processeur graphique de l'eeePC 701 est un GMA 900, les pilotes 3D de ces générations n'était pas ouverts à l'époque, certains de ces chips graphiques sur les Atom sont des PowerVR, Intel à commencé à travailler sur des pilotes libres en 2006 vers la sortie des HDGraphics en tout cas. Peut être que le pilote i915 gère celui du EeePC 701 aujourd'hui ? Pour les EeePC suivant, PowerVR (d'Imagination Technologies), c'est mort; aucun pilote à ma connaissance. La FSF à mis ça sur les choses prioritaires, mais ils avait fait ça également sur la technologies Flash, résultat, un morceau de décodeur partiel qui ne pouvait que lire certaines vidéos (Gnash, parfois utilisé pour importer des fichiers flash dans les logiciels vecto cela dit).
Bon, les premiers Atom étaient aussi des veaux, je pense qu'à peut près n'importe quel ARMv7 (les ARM Cortex 32 bits) va plus vite
[^] # Re: Config
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 03 novembre 2020 à 16:23.
ça et la carte MMC (ou SDcard) qui fait freezer toute réactivité quand en écriture intensive… (j'ai un eee pc 901
même si crackattack et kobodeluxe fonctionnent bien
[^] # Re: Config
Posté par Anonyme . Évalué à 1.
C'est pas si évident que ça.
Si le PocketChip (un Allwinner R8 à peu près équivalent à un vieux A10 à 1 cœur 32bit) galère il y a des chances qu'un atom 1st gen fasse mieux.
Après le R8 manque d'accélération 2D par rapport à un A10, c'est peut-être ça qui fait ramer le PocketChip.
[^] # Re: Config
Posté par tao popus . Évalué à 0.
Le Cortex-A8 à 1 GHz intégré à un SIMD, il est aidé par un processeur 2D, capable de géré 4 calques et de l'alpha blending + des effets, il y a un GPU 3D ARM Mali 400 et un décodeur vidéo x264,VP8,AVS, sur le AllWinner R8. Le Mali 400 est géré sous Linux par le driver Lima (au sein de Mesa 3D), il fait donc de l'OpenGL (GL ES avec pilote propriétaire, Full GL avec pilote libre), donc ça peut faire largement l'affaire pour TIC-80 (pas la version Web). Le décodeur vidéo doit être un Cedrus, également géré par pilote libre. Je vais me compiler tic-80 sur un A20 pour voir tiens.
La première génération d'Atom n'avait pas de décodeur vidéo, les intel n'ont jamais eu de processeur 2D. Il tournait à 900 Mhz (à fréquence équivalente, un Intel est plus lent qu'un processeur d'architecture RISC en général). Donc, non, le R8 est beaucoup plus puisant.
[^] # Re: Config
Posté par Anonyme . Évalué à 1.
À part Diamondville, même Silverthorne (la série Z très basse conso) possède un GPU avec accélération 2D et 3D.
Le GMA900 propose du pixel shader, OpenGL ES est dispo dans Linux avec i915. Le manque d'accélération 2D n'est qu'une limitation des pilotes Windows, pas du matériel.
Certes la conversion en micro-ops pénalise x86 mais on est pas tout à fait dans la même gamme non plus en terme de fonctionnalités (rien que le SMT ou la mémoire ça peut pas mal changer la donne). Va consulter les nombreux comparatifs de SBC sur Phoronix, le RPi2 (un peu plus faible qu'un A20 donc plus puissant qu'un A10) se retrouve très souvent à la traine face à de vieux Atom.
Sinon pas besoin d'ajouter des liens sur Allwinner et de parler des pilotes ou du décodage vidéo. Ça ne fait qu'alourdir inutilement ta réponse.
Déjà que je comprends pas pourquoi tu as commencé à parler des Atom alors que son netbook possède un Core-m de génération précédente.
[^] # Re: Config
Posté par tao popus . Évalué à 1.
À l'époque du EEEpc701, comme déjà dit, il n'y avait pas de pilote pour Linux, l'Eeepc701 était un des premiers ordinateurs vraiment commerciaux sous Linux, avec distribution Xandros et un bureau un peu spécial pour son tout petit écran.
Je ne vois pas pourquoi tu nous parles de Windows on est sur Linuxfr et on parle de machines sous Linux ??? Je t'invite à relire le fil de la discussion depuis le début, j'ai l'impression que tu l'as lu en diagonale.
Il comportait un processeur celeron m 900 à 630MHz, donc effectivement pas un Atom, mais pas non plus un core-m, j'ai mélangé, en tout cas un processeur vraiment lent, et n'importe quel ARM Cortex-A est plus rapide et j'en ai un sous le bureau pour confirmer. Les Atom qui ont suivit n'était pas des flèches non plus. j'ai pratiqué aussi sur un boîtier compact. Le truc à lâché rapidement, carte mère HS, mais c'est peut être un coup de malchance.
Bon, mais enfin, peu importe, pour revenir à nos moutons, j'ai compilé la dernière version de TIC-80 (il y a un problème à la détection des chemins include de GTK (utilisé uniquement pour le sélectionneur de fichier, mais j'ai contourné). Donc Tic-80 80, marche très bien sur AllWinner-A20 (Mali-400 MP2, je sais pas sirle R8 est MP1 ou MP2) avec le pilote libre Mali, sur un écran 800x600, en plein écran, bureau XFCE en désactivant le compositing. Avec l'état actuel du pilote ça a tendance à bouffer sur les perfs 3d des autres applis. ARM à fini par donner les docs des GPU aux développeurs du pilote Panfrost, je ne sais pas si ils ont donné les docs des premières séries pour Lima ?
J'ai essayé avec WITCHEM UP, WCQ NO.6 et la démo BANANAPARTY!.
[^] # Re: Config
Posté par Anonyme . Évalué à 2.
Mais on parle de l'utilisation avec une distrib Linux récente, pas d'il y a 12 ans.
Parce que j'ai eu l'impression que tu te reposais sur les capacités de Windows alors qu'il n'a jamais vraiment eu de pilotes à jour contrairement à Linux qui depuis quelques années exploite correctement ce matériel.
D'ailleurs il me semble avoir lu que les premiers pilotes béta sur GMA900 faisaient tourner Aero sur Vista et que ça a été retiré par la suite.
Moi aussi j'ai mélangé core et celeron, ça arrive. :)
Les Allwinner monocœurs sont en MP1
Donc oui c'est pas forcément étonnant que ça passe bien avec un A20 ayant le double de pixel shader et de cœur du R8 qui est un peu limite.
Aucune idée, ça fait un moment que je ne scrute plus le redéveloppement de Lima. Ça juste marche sur un A20 avec Armbian.
ÀMHA c'est déjà assez miraculeux pour Panfrost, vu comment ils ont snobé Lima dès le départ, donc je n'y compterai pas pour Utgard ou la série précédente.
[^] # Re: Config
Posté par tao popus . Évalué à 0. Dernière modification le 05 novembre 2020 à 10:40.
Plein de supposition sur ce que je voulais dire, c'est intéressant. Il faudrait relire ce que j'ai écrit avant de supposer de ce que tu parlais et dont il n'a pas été question. C'est un peu navrant de ne pas pouvoir parler sereinement, de l'efficacité de telle ou telle solution, lorsque quelqu'un n'a qu'en tête les méfaits de windows, et que le reste devient déni. Je me contrefout complétement de windows et je n'ai pas envie de perdre de temps avec ce truc, il y a plein de choses à faire de mieux.
Quand j'ai commencé le sujet j'ai bien dit à cette époque il n'y avait pas de pilote, les générations suivantes, le GPU était un PowerVR, il n'y avait pas de pilote libre et il n'y en a toujours pas.
Sur le site indiqué, il n'y a pas les caractéristiques du R8, c'est donc une supposition, pas un fait, et c'est bien pour ça que j'ai dit :Je ne sais pas. Il n'y a pas forcément de corrélation entre les cœurs des puces graphiques et des microproceseurs, on trouve par exemple un Mali-400 2 cœurs sur un A64 (4*Cortex-A53, 64 bits, sur les 64b on voit plus généralement des Mali Txx ou Gxx).
Quant à Phoronix, autant les informations sur les évolutions sont parfois intéressante autant son porn-bench, ou un article sur deux on voit un titre du genre « une amélioration excitante », parce qu'un comparatif donne 2 % de plus dans 60% des cas et 1 % de moins dans d'autres soit très pertinent. Par plusieurs fois, les bench que j'ai vu, ARM vs x86, utilisaient des ARM de deux ou trois ans plus vieux, surtout quant il s'agissait de SBC de hackers. Dans ces conditions, je ne vois pas ce que ce genre de test apporte non plus. Je parlais ici de cas concrets, c'est à dire est-ce que c'est suffisamment réactif ou non pour être utilisable.
[^] # Re: Config
Posté par tao popus . Évalué à 1.
Ah sinon, autre chose où il serait bon de me relire, je comparait le AllWinner A20, au R8, parce qu'assez proche, pour essayer d'évaluer sa puissance et non, pas pour dire qu'il était plus efficace. Hors l'Allwinner A20 à 2 cortex-A7 comme processeurs, orienté très très basse consommation (LITTLE), tandis-que le R8 à un Cortex-A8, deux générations plus anciennes donc, mais orienté vers plus de puissance de calcul. De la même façon le Rockchip RK3288 qui à cœurs Cortex-A17 (big, 32 bits orienté puissance de calcul), est plus puissant que le RK3328, 4*Cortex-A53, (LITTLE, 64 bits, orienté basse consommation), mais les big de sa génération (comme le RK3399) sont bien plus puissant.
C'est un peu dommage de ne pas bien lire, de surinterpréter et d'ajouter du bruit, ça ne va pas améliorer la lisibilité du fil de discussion.
[^] # Re: Config
Posté par Anonyme . Évalué à 2.
Non c'était qu'une seule et ça n'obnubile que toi.
OSEF des générations suivantes, on parle pas de ça et aucun besoin d'en reparler parce que c'est de notoriété publique, surtout par ici. Je comprends pas pourquoi tu t'obstines à ajouter cette info plusieurs fois dans la discussion.
Le site indiqué c'est quand même le wiki de la communauté de hackers qui bosse sur le portage Linux pour les SoC Allwinner. Si tu avais creusé un peu, tu aurais pu voir que l'ancien nom du R8 c'est le A13 et que c'est grosso modo un A10 light.
C'est bien mais ça aussi osef et je pense que n'importe quelle personne s'étant déjà intéressé aux specs de SoC ARM savait que c'était un jeu de Lego.
J'ai jamais dit que c'était une source fiable à 100%, je suis le premier à critiquer sa méthode de travail.
Néanmoins c'est une source intéressante quand on sait séparer le bon grain de l'ivraie.
Bah non. Le R8 c'est l'équivalent d'un A10 allégé face à son grand frère A20 avec deux fois plus d'unités de calcul. À aucun moment on peut appeler ça "assez proche".
Mec, le Cortex-A7 est l'héritier direct du A8. Il y a des différences architecturales mais en pratique les deux cœurs sont équivalents en terme d'IPC. Le A8 n'est pas un cœur "haute performance", je suis même pas sûr que le concept existait à sa création.
Sinon on s'en fiche totalement de big.LITTLE et des SoC Rockchip, ça n'a aucun rapport avec le sujet.
Là c'est vraiment l'hôpital qui se fout de la charité. La lisibilité est déjà polluée par tes propres messages bourrés de trucs totalement hors-sujet. Regarde les tartines que tu ponds à chaque fois.
[^] # Re: Config
Posté par tao popus . Évalué à -1.
C'est tout le problème. Tu le cite, sans citer le bench, forcément tu n'aimes pas les liens qui permet de vérifier de quoi on parle, visiblement opposé à toute rigueur, la paroles en l'air étant un meilleur atout dans le sophisme :
Les liens intégrés alourdiraient plus la réponse que des paroles en l'air donc… Si déjà tu ne sais pas quelle est la différence entre un PC et un micro-ordinateur… (voir plus bas).
[^] # Re: Config
Posté par tao popus . Évalué à 0.
Pour parler plus technique, d'après l'Allwinner R8 est en fait un Allwinner A13 renommé, une version light du A10 réservé aux tablettes, c'est pour ça qu'il est déjà directement géré par le noyau Linux mainline, qui gère le A13 depuis longtemps, mais qu'il n'est pas mentionné. il gère moins de mémoire que les Allwinner A10 et A20 (512M au lieu de 2GB), il n'a également qu'un seul core Mali-400. n'a pas de G2D (un blitter 2D relativement limité), et c'est bien un VPU Cedar, ce qui en fait un chip intéressant pour la vidéo.
J'ai ensuite refait des tests avec TIC-80 sur ma Cubieboard-2 (et on arrive à la même conclusion sur n'importe quelle machine). Il n'utilise qu'un seul cœur, il est donc mono-thread et on doit arriver à des perfs identiques entre le Cortex A8 (processeur le plus puissant à son époque) d'un R8, et un seul Cortex-A7, plus récent, mais surtout orienté meilleur ratio calcul/énergie :
on a 2 DMIPS/Mhz pour le Cortex-A8 contre 1.9 pour le cortex-A7). Donc, au niveau du CPU, ça se vaut, l'A7 à été principalement une simplification et (donc par la même) une optimisation énergétique par rapport à l'A8. Probablement, en se basant sur l'expérience des Cortex-A9, et surtout Cortex-A5 sorti entre les deux ?
Donc le GPU (qui est le même, avec un cœur au lieu de 2), doit jouer en fonction du nombre de « sprites » ou de polygones à l'écran, mais cela devrait être, pour pas mal de jeux/démos de TIC-80, une expérience identique sur le AllWinner R8 et le AllWinner A20.
Au passage, presque hors sujet, mais, dans le mainline Mesa (sera dans la 20.3, d'ici à la fin du mois), les VBO (vertex Buffer Objet) ont été |intégrés pour la majorité des formats le mois dernier](https://gitlab.freedesktop.org/mesa/mesa/-/commit/12128fb1351eee6ec681039fe8483b3c39db7c8e) au pilote Lima pour ces GPU, ce qui devrait sensiblement améliorer les perfs (réductions des opérations à chaque tracés :) ).
[^] # Re: Config
Posté par tao popus . Évalué à 2.
Donc, comme dit ci-dessus, n'utilisant qu'un cpu, et le cpu du Cortex-A7 étant très légèrement inférieur (on peut dire équivalent), 1.9 DMIPS/Mhz à celui du Cortex-A8 2.0 DMIPS/Mhz. on devrait avoir des performances toute à fait raisonnables sur un AllWinner A10 ou R8 avec TIC-80, du moins sur les jeux simple (1 seul GPU), il faudra peut être un peu plus pour les jeux avec beaucoup de sprites et d'effets, mais ça n'est pas non plus ce qui est recherché en 1er sur TIC-80.
Au passage, la console Gameshell qui utilise un AllWinner-R16J (4cortex-A7) dont il était question ici https://linuxfr.org/news/construisez-et-programmez-votre-console-de-jeux-open-source possède visiblement TIC80 par défaut (la capture décran est le Tetris de TIC-80), il y a le logo pour leur version aussi pour la Clockwork Pi fabriqué par les mêmes comporte le Logo de TIC-80 dans la partie apps.
[^] # Re: Config
Posté par Clément V . Évalué à 2.
Vu le type de dessin, ça devrait être possible de faire ce genre de rendu en logiciel sur n'importe quel processeur du 21ème siècle, non ?
À une époque j'ai pas mal programmé sur TI-89 (Motorola 68k à 12MHz, 256Ko de RAM), il n'y avait pas d'accélération matériel graphique mais ça ne posait pas trop de problèmes pour faire des jeux 2D simples. Ce n'était que du monochrome mais avec la différence de puissance des processeurs on devrait quand même pouvoir passer à 16 couleurs.
[^] # Re: Config
Posté par zurvan . Évalué à 5.
c'est vrai. J'imagine que l'auteur utilise un framework de programmation qui nécessite tout ça, peut-être parce que c'est ce qu'il connait le mieux. Après, ils travaillent au portage sous Sokol, qui nécessite peut-être moins de ressources que SDL. Et puis l'affichage "3D" permet aussi de donner un rendu "écran CRT" assez sympa (accessible depuis la touche F6)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Config
Posté par tao popus . Évalué à 2.
Il n'y a pas vraiment d'API 2D généralisée, à la fois au niveau processeur graphique, pilote et système. L'utilisation d'OpenGL, reste donc la solution la plus efficace dans la majorité des cas, d'opération géométriques 2D. Surtout quand il s'agit de gérer de nombreux bitmap, de faire des zoom/rotation/translation avec transparence. Dans le pire des cas, Mesa le gérera très efficacement en logiciel avec LLVMpipe. La majorité des frameworks de ce genre, LÖVE et Godot (pour la 2D) compris choisissent donc cette solution, ça permet aussi de bénéficier des shaders pour certains effets.
[^] # Re: Config
Posté par Anonyme . Évalué à 5.
Oui c'est comme ça qu'il y a des consoles libres à base de microcontroleurs 8bits. Mais c'est du temps processeur de pris donc ça peut facilement ramer si le jeu a un rafraichissement rapide ou exige beaucoup de changements de pixels par image. C'est l'une des raisons de la disponibilité de différents modes d'affichage sur les vieux ordis.
Sinon pas nécessaire d'aller si bas niveau pour une console virtuelle conçue pour des ordinateurs actuels de 32bit ou plus qui possédent tous un GPU gérant au minimum OpenGLES.
La NES et la SMS avaient déjà une palette bien plus large et davantage de capacité d'affichage simultané de couleurs. Mais le but de ce genre d'environnement minimaliste est surtout de fournir des limitations artificielles drastiques permettant de se concentrer sur le gameplay ou le level design.
Théoriquement on pourrait même passer à une palette 8bit de 256 couleurs. En réalité dans les vieilles machines on parle de 8-16-64 couleurs mais c'est surtout le nombre de couleurs affichables simultanément et il y avait souvent 2 bits en plus pour gérer la luminosité donc on pouvait avoir une palette bien plus étendue.
Dès le début des années 80 certains PC 8bit de milieu-haut de gamme avaient même des puces graphiques qui permettaient de gérer les couleurs sur plus de 8bit (jusqu'à des palettes de 18bit de profondeur pour 16bit de couleurs simultanées sur les derniers FM7 de Fujitsu).
[^] # Re: Config
Posté par Clément V . Évalué à 2.
On est quand même sur du dessin très simple : rotations à 90 degrés et étirements par des facteurs entiers pour les opérations les plus complexes. On a surtout besoin de copier des pixels un peu partout, un CPU n'est pas si mauvais pour ça.
Et OpenGL, c'est aussi du temps CPU pour envoyer les données et commandes à chaque image. Et sur un eeepc avec une implémentation logiciel d'OpenGL, on doit se retrouver avec un surcoût énorme comparé à un rendu logiciel naïf qu'on aurait pu écrire soi-même.
Des machines avec des processeurs très très faibles mais compensés par des GPU spécialisés dans le dessin de sprites. J'aurais plutôt comparé aux vieux jeux DOS qui faisaient mieux que le TIC-80 mais sans accélération matérielle.
[^] # Re: Config
Posté par Anonyme . Évalué à 2.
Pour avoir testé des affichages relativement simples sur microcontroleurs, ça dépend vraiment de la puissance du processeur et de la résolution de l'écran piloté.
Celà dit, ça fonctionnerait certainement sur un EeePC.
C'est peut-être implémenté comme ça dans le portage "bare silicon" pour RPi mais pour l'extrême majorité du parc actuel et la diffusion multiplateforme et multiOS ça a plus de sens de faire avec les capacités GPU via OGL.
J'ai nommé des machines 8bit un peu plus conçues pour le jeu pour signifier qu'on parle à tort de graphismes 8bit pour des contraintes colorimétriques qui n'étaient réellement présentes que sur des PC pour particuliers vraiment d'entrée de gamme du début 80.
Et aussi parce qu'avec les processeurs, hors MCU, on pourrait certainement aller bien au delà en terme de couleurs affichées avec un rendu software.
[^] # Re: Config
Posté par tao popus . Évalué à 0.
Faux, de toute façon, les PC étaient alors inabordables pour la majorité des gens et étaient limités à 2 ou 4 couleurs…
Les micro-ordinateurs des années 80 (les ordinateurs utilisés par tout le monde), avait déjà des palettes de 8 couleurs (ZX Spectrum (1982), Oric 1 et Atmos (1984)), 16 couleurs (Vic-20 (1980 avait un mode bidouille 16 couleurs), MSX 1 (1983), Amstrad CPC (1984), etc…) ou plus (MSX 2, 1985, 256 couleurs parmi 512). Il y avait par contre en général des problèmes de proximité, et des processeurs vidéos (pour la gestion des sprites ou de cartes de blocs graphiques (comme pour les décors du TIC-80) plus ou moins avancés. et pas ou peu de processeurs graphiques (utilisé pour la copie de blocs ou des tracés géométriques). La véritable révolution étant l'Amiga, avec d'abord l'Amiga 1000 (1985, hors de prix), puis le 500 1987, abordable au grand public, qui possédaient des processeurs graphiques et vidéos avancés, mais n'avaient pourtant vraiment pas la puissance de microcontrôleurs d'aujourd'hui comme le STM32 (les Atmega 8 bits étant lui derrière).
[^] # Re: Config
Posté par Anonyme . Évalué à 1.
Plutôt que de passer du temps à tartiner tes messages de liens, tu pourrais mettre en contexte tes réponses en citant ce à quoi tu réponds. C'est la base.
Déjà tu entends quoi par PC ? parce que ce comme tu le cites les VIC20, C64 ou CPC464 affichaient déjà 16 couleurs simultanées.
Ce que je dis c'est qu'assez rapidement vers mi-80 même ces appareils low-cost avaient au moins des palettes plus importantes que les 16 couleurs de ces fantasy consoles et que les consoles de salon avaient elles aussi davantage de capacités dès début 80.
[^] # Re: Config
Posté par tao popus . Évalué à 0.
Tu réponds par ce que je répond, en le contredisant en même temps, bravo, belle pirouette, j’espérai qu'on parlerait technique, qu'on ne s'arrêterait pas aux sophisme ici. ce qu'on appelle un PC, en informatique c'est un IBM PC ou compatible. Ce que je cite, ce sont des micro-ordinateurs comme je l'avait dit. Après pourquoi pas redéfinir tous les termes d'informatique pour le plaisir de dire n'importe quoi…
Non, justement ça n'est pas ce que tu disais. Tu interprète de travers ce que disent les autres, mais également ce que tu dis, ça n'a peut d’intérêt, j'ai l'impression de perdre mon temps, j'arrête là.
[^] # Re: Config
Posté par tao popus . Évalué à 0.
A tiens, effectivement, la 80 ne fait plus que des mises à l'échelle en entier, c'est un peu dommage. j'avais fait un test où les mises à l'échelle n'était pas entières (mais toujours exactes au niveau du pixel).
Mais les opération d'affichage de sprites ou de copie de blocs d'images sont pour le moment plus efficaces, en utilisant des textures en OpenGL, déchargeant ainsi le CPU, qu'en copiant tout au CPU.
Et sinon, il y a également les fonctions tri (demo bananaparty) textri (demo textri),
[^] # Re: Config
Posté par lym . Évalué à 1. Dernière modification le 05 novembre 2020 à 16:52.
J'ai toujours mon EeePC901 avec son Atom 1er du nom si "poussif", actuellement avec une Debian 10 et bureau Mate qui n'est pas le plus léger qui soit. Ca reste utilisable. La seule modif avait été de lui payer une barrette de 2GB à la place de celle d'1GB d'origine (+, sans impact ici, carte wifi Ubiquity plus sensible que l'originale et pouvant cracher très au dessus des 100mW autorisés, import US oblige, qui accrochait sans problème des points d'accès à 500m, malgré les antennes internes, en vacances avant la baisse des forfaits data mobiles).
Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.
Là si c'est un problème, c'est pas l'Atom qu'il faut blâmer!
Le plus incroyable avec cette petite machine comme on n'en fait hélas plus: Son autonomie, avec une batterie d'origine chargeant encore à 85% de sa capacité théorique. Du Asus de la décennie 2000, en résumé, même pour ce modèle alors low-cost.
[^] # Re: Config
Posté par tao popus . Évalué à 1.
Doom à aussi des adaptation 8 bits sur les premier micro-ordinateurs des années 1980 (bien limités certes), Il tournait déjà sur PC (signifiant compatible IPM PC) dès 1993, 15 ans avant le premier Atom (2008.
Cela paraît peut être incroyable, mais techniquement, Tic-80 est beaucoup plus avancé que Doom. Il permet comme Doom d'afficher des polygones texturés mais que l'on peut faire tourner dans tous les sens. Doom utilisait une astuce, il n'y a pas de rotation sur l'axe z, il n'y a que des plans verticaux et horizontaux, et pas de rotation verticale de caméra, c'est un cas particulier qui simplifie énormément les calculs. Les personnages sont des images toujours face à la caméra (différentes images les représentes dans différentes positions), donc pas de calcul 3d, uniquement du zoom.
La première carte 3D grand public (encore un peu chère est la Matrox Mystique 220, 1997, mais le premier grand succès c'est la 3Dfx Voodoo Graphics, une carte spécialisée, où l'on reliait la sortie vidéo de la carte graphique principale et qui ensuite était reliée à l'écran, permettait d'afficher ses rendus 3d dans une fenêtre d'un bureau 2d calculé par la carte graphique, ou en plein écran.
Tic80 en plus des polygones texturés, affiche une grande quantité de sprites (plus précisément émulés par des polygones texturés ici, pour bénéficier de la puissance des GPU), ce qui aurait été impossible sur les PC de l'époque de Doom.
Sinon, le EeePC 901 utilise un chipset 945GME donc un GPU GMA 950. Je serais curieux de savoir comment il est géré sous Linux ? Est-ce que glmark2 fonctionne avec et quels sont ses résultats ?
# pareil mais en moderne ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le look 8bit a ses "limites visuels" mais à l'avantage d'être léger à prendre en main.
Est-ce que quelqu'un a eu déjà l'idée de faire la même chose en version plus moderne ? Comme limiter le jeu à 100 objets 3D + une map en "niveau". L'idée est de garder l'api ultra contrainte, mais d'avoir un rendu 3D sympa (ou même spécifique genre cell shading, par exemple).
"La première sécurité est la liberté"
[^] # Re: pareil mais en moderne ?
Posté par jseb . Évalué à 6.
Il y a «Nico» (utilise le langage Nim) :
https://github.com/ftsf/nico
Il permet de faire de la 3D : https://impbox.itch.io/vektor2089
Avec une belle palette de 256 couleurs (allez, le VGA c'est un peu plus moderne que l'EGA rencontré habituellement sur ce segment ;) )
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: pareil mais en moderne ?
Posté par tao popus . Évalué à 3. Dernière modification le 04 novembre 2020 à 17:05.
C'est plus un framework qu'un-e fantasy computer/console. Ces derniers embarquent aussi les éditeurs(code/audio/musique/tableaux) dans leur interface. Mais ça n'est pas inintéressant. Le fait que ça soit compiler permet certainement d'avoir une meilleur efficacité, et donc d'avoir plus de chance de fonctionner sur les petites machines.
Par contre, la course, ça n'est pas de la 3D, ça semble être de la 2D vectorielle, mais pas de la 3D. Sur toutes les consoles, ont voit de la pseudo 3D, ou de la 3D limitée avec les moyens du bord.. Ces machines utilisent l'accélération 3D, mais n'ont pas d'API 3D).
[^] # Re: pareil mais en moderne ?
Posté par jromang . Évalué à 4.
Pas libre hélas :
https://www.lexaloffle.com/voxatron.php
[^] # Re: pareil mais en moderne ?
Posté par zurvan . Évalué à 2.
pour la petite histoire, c'est le même créateur qui a développé PICO-8 par la suite. Et effectivement voxatron fonctionne aussi comme une console imaginaire, avec des voxels !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: pareil mais en moderne ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Tu peux faire un jeu avec des technos "normales" et d'autoimposer des limites.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pareil mais en moderne ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est possible ça, sans connaitre une grosse quantité d'API pour tout faire ?
"La première sécurité est la liberté"
[^] # Re: pareil mais en moderne ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Pour un petit jeu 2D, il n'y pas besoin de 36 APIs:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pareil mais en moderne ?
Posté par zurvan . Évalué à 5.
il y a love2d qui n'a pas de contraintes spécifiques, utilise lua également et a une bonne API (qui change parfois d'une version à l'autre malheureusement), il y a pas mal de bons jeux qui l'utilisent (y compris des jeux en pseudo 8bit / pixels)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: pareil mais en moderne ?
Posté par tao popus . Évalué à 2. Dernière modification le 04 novembre 2020 à 13:48.
Les limites visuelles du 8 bits, sont aussi un genre esthétique, ou plutôt un ensemble de genres esthétiques, qui peut, comme toute esthétique, plaire ou déplaire, et qui donc plaît à certains. Le minimalisme a parfois du bon.
En 3D, il y a le low poly (peu de polygones) qui reprend des principes de limites volontaires de ressources, avec souvent, des formes pleines sans, textures, ou uniquement sur certains détails. Donnant un style épuré et minimaliste. On y retrouve l'esthétique de Virtua Racing de Sega (1992), volontairement repris à l'identique en 2004 sur PS2, sous le nom de Virtua Racing: FlatOut. Je trouve, très personnellement, que c'est plus agréable à regarder que de la 3D comportant des textures sans recherche esthétique, mais tentant juste de ressembler à peu près à la matière.
Il y a A Short Hike, qui mêle gros pixels, low poly, mais également des textures minimalistes, qui ont un impact important. Une très bonne utilisation de la gestalt (prononcer geshtalte). J'ai appris ce terme hier soir, il est vraiment très précis dans son concept et fondamental en ergonomie. La base est que l'esprit voit d'avantage la forme globale que ses détails et que les détails doivent être placés à bon escient pour influer sur la vision globale. La gestalt défini également les critères d'influence psychologique des différents types de détails.
[^] # Re: pareil mais en moderne ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'avoue que la 3D texturé ombré mais avec des lignes droites de partout lorsqu'il s'agit de voir un objet devant un autre, je trouve cela hyper moche.
Je regrette les jeux qui avait leur propre rendu, comme un vieux jeu d'hélicoptère qui a inventer le principe de map avec altitude ou le jeu de tapie volant avec des objets uniquement fait avec des ellipses ou des ovoïdes.
"La première sécurité est la liberté"
[^] # Re: pareil mais en moderne ?
Posté par jseb . Évalué à 5.
Respectivement Comanche (qui a popularisé le voxel) et Magic Carpet (qui a … euh… qui était un super jeu!)
Pour le voxel, réimplem avec démo et explications ici:
https://github.com/s-macke/VoxelSpace
Comme le sujet a l'air de t'intéresser, je me permets de te suggérer de passer sur freenode/#gamedev-fr , nous adorons y causer de toutes ces choses (et accessoirement de la fabrication du meilleur pain).
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: pareil mais en moderne ?
Posté par zurvan . Évalué à 4.
y'a justement un remake de Comanche en TIC-80 : https://www.lexaloffle.com/bbs/?pid=52441#p
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: pareil mais en moderne ?
Posté par tao popus . Évalué à 2.
C'est du Pico-8
[^] # Re: pareil mais en moderne ?
Posté par zurvan . Évalué à 4.
arf mon clavier (ou plutôt mon cerveau) a fourché, je voulais justement préciser le logiciel parce que c'était pas le thème initial du journal.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: pareil mais en moderne ?
Posté par zurvan . Évalué à 4.
Voici enfin un simulateur de Voxels en TIC-80 !
https://tic80.com/play?cart=1532
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.