Sortie de TIC‑80 version 0.80

Posté par  . Édité par Davy Defaud, palm123, Pierre Jarillon, Xavier Claude et Xavier Teyssier. Modéré par Ysabeau. Licence CC By‑SA.
Étiquettes :
37
2
nov.
2020
Jeu

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.

Démo de TIC-80

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 !

Aller plus loin

  • # Super !

    Posté par  . Évalué à 4 (+4/-0).

    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  . Évalué à 4 (+2/-0).

    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  . Évalué à 5 (+3/-0).

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

      • [^] # Re: Config

        Posté par  . Évalué à 3 (+2/-0).

        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  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 03/11/20 à 16:23.

          les premiers Atom étaient aussi des veaux

          ç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  . Évalué à 1 (+0/-1).

          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

          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  . Évalué à 0 (+0/-1).

            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  . Évalué à 1 (+0/-1).

              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.

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

              (à fréquence équivalente, un Intel est plus lent qu'un processeur d'architecture RISC en général)

              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  . Évalué à 1 (+1/-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.

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

                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.

                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.

                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.

                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  . Évalué à 2 (+1/-1).

                  À l'époque du EEEpc701, comme déjà dit, il n'y avait pas de pilote pour Linux

                  Mais on parle de l'utilisation avec une distrib Linux récente, pas d'il y a 12 ans.

                  Je ne vois pas pourquoi tu nous parles de Windows on est sur Linuxfr et on parle de machines sous Linux

                  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.

                  Il comportait un processeur celeron m 900 à 630MHz, donc effectivement pas un Atom, mais pas non plus un core-m, j'ai mélangé,

                  Moi aussi j'ai mélangé core et celeron, ça arrive. :)

                  (Mali-400 MP2, je sais pas si le R8 est MP1 ou MP2)

                  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.

                  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 ?

                  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  . Évalué à 0 (+1/-2). Dernière modification le 05/11/20 à 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  . Évalué à 1 (+1/-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  . Évalué à 2 (+1/-1).

                        Plein de supposition sur ce que je voulais dire, c'est intéressant.

                        Non c'était qu'une seule et ça n'obnubile que toi.

                        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.

                        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.

                        Sur le site indiqué, il n'y a pas les caractéristiques du R8, c'est donc une supposition, pas un fait

                        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.

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

                        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.

                        Quant à Phoronix, [blablabla]

                        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.

                        je comparait le AllWinner A20, au R8, parce qu'assez proche,

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

                        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.

                        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.

                        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.

                        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  . Évalué à -1 (+0/-2).

                          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.

                          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 :

                          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.

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

                          Sinon on s'en fiche totalement de big.LITTLE et des SoC Rockchip, ça n'a aucun rapport avec le sujet.
                          Je ne sais pas pourquoi tu es venu parasiter le sujet si cela ne t'intéresse pas…

        • [^] # Re: Config

          Posté par  . Évalué à 2 (+1/-0).

          Comme souligné, c'est pas mal basé sur OpenGL

          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  . Évalué à 5 (+3/-0).

            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)
            Titre de l'image

            • [^] # Re: Config

              Posté par  . Évalué à 2 (+2/-1).

              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  . Évalué à 5 (+3/-0).

            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 ?

            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.

            Ce n'était que du monochrome mais avec la différence de puissance des processeurs on devrait quand même pouvoir passer à 16 couleurs.

            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  . Évalué à 2 (+1/-0).

              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.

              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.

              La NES et la SMS

              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  . Évalué à 2 (+1/-1).

                On a surtout besoin de copier des pixels un peu partout, un CPU n'est pas si mauvais pour ça.

                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.

                un surcoût énorme comparé à un rendu logiciel naïf qu'on aurait pu écrire soi-même.

                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.

                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.

                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  . Évalué à 0 (+0/-1).

                  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  . Évalué à 1 (+0/-1).

                    Faux,

                    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.

                    les PC étaient alors inabordables pour la majorité des gens et étaient limités à 2 ou 4 couleurs…

                    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  . Évalué à 0 (+0/-1).

                      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.

                      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…

                      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.

                      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  . Évalué à 0 (+0/-1).

                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.

                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  . Évalué à 1 (+2/-1). Dernière modification le 05/11/20 à 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  . Évalué à 1 (+1/-1).

            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.

            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  . Évalué à 4 (+1/-0).

    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  (site Web personnel) . Évalué à 6 (+4/-0).

      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  . Évalué à 3 (+2/-0). Dernière modification le 04/11/20 à 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  . Évalué à 4 (+4/-0).

      • [^] # Re: pareil mais en moderne ?

        Posté par  . Évalué à 2 (+0/-0).

        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 !

    • [^] # Re: pareil mais en moderne ?

      Posté par  (site Web personnel) . Évalué à 5 (+2/-0).

      Tu peux faire un jeu avec des technos "normales" et d'autoimposer des limites.

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: pareil mais en moderne ?

        Posté par  . Évalué à 3 (+0/-0).

        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  (site Web personnel) . Évalué à 6 (+3/-0).

          Pour un petit jeu 2D, il n'y pas besoin de 36 APIs:

          • si tu fais du C/C++: la SDL ;
          • pour javascript: Canvas, Gamepad API et quelques trucs pour l'audio.

          Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: pareil mais en moderne ?

          Posté par  . Évalué à 5 (+3/-0).

          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)

    • [^] # Re: pareil mais en moderne ?

      Posté par  . Évalué à 2 (+2/-1). Dernière modification le 04/11/20 à 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  . Évalué à 4 (+1/-0).

        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é"

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.