🎤 INTERVIEW : Comparaison des différents systèmes graphiques sur Ordinateurs 8 bits, avec Laurent 🎤
HTML-код
- Опубликовано: 24 апр 2024
- Nouvelle vidéo exceptionnelle, où l'ami Laurent nous explique les différentes contraintes graphiques qui existent sur les principales machines 8 bits du marché (Apple 2, Atari 400/800, ZX Spectrum, Oric, Commodore 64, MO5/TO7, MSX, Amstrad CPC)
Une nouvelle fois passionnant et très instructif : vous ne regarderez plus vos anciens jeux de la même façon ^^ 
Игры
Merci à vous deux. Les interventions de Laurent sont passionnantes. Le genre de vidéo que j'aurais rêvé de voir quand j'avais 12 ans. C'est dingue youtube. 😄
Content que ça te plaise 😀
Je confirme, c'était très intéressant. Vivement la suite !
Merci beaucoup 😁
Excellent!
Merci 😃
Une video passionnante ! Je suis programmeur passionné par tout ce qui est encodage, et Laurent a donné là un cours formidable ! (Parfois on voyait que tu ne comprenais pas tout, huhu ^^).
Par rapport a l'encodage des lignes de l'Amstrad, beaucoup de chargements de jeux affichaient l'image avec un effet "rideau" qui justifie totalement l'adressage des lignes de 8 en 8 : en réalité ils chargeaient la memoire de maniere lineaire et ça donnait cet effet !
Merci. Oui j'ai appris bcp de choses, même si je suis programmeur moi-même (mais pas du tout vas niveau, c'est d'ailleurs pour ça que pour moi les programmeurs de l'époque sont des héros et des magiciens à la fois 😄)
Je regarderai plus tard passionnément.
Excellente vidéo, très pédagogique ! Merci messieurs
Merci beaucoup !!!
Je ne pourrai être présent, je regarderai la rediffusion avec intérêt. Effectivement ça a l'air passionnant.
Super recap. Merci beaucoup. J ai bien perçu à travers vos explications la galère que cela devait être de programmer ces bécanes 8 bits en manque de VRAM. Si j ai tout suivi, les programmeurs qui bossait sur l amstrad étaient de vrais privilégiés !
J'ai hâte pour l épisode 2, Boulder Dash, un de mes jeux 8 bits préférés ^^ ( sa remise au gout du jour sur GBA est également très amusante)
Même 64 Ko de RAM peut être rapidement rempli. J'ai cru comprendre que vers la fin des jeux 8-bits, ils en étaient parfois à enlever 12 octets dans la musique pour la mettre dans l'animation (j'avais lu ça dans un Tilt à l'époque, mais je ne me rappelle plus lequel)
Pour ce qui est de l'Amstrad je ne connais que peu cette machine, mais c'est sans doute plus facile de bosser sur un Commodore 64 qui a autant de RAM mais plusieurs mécanismes pour faire des animations rapides.
Merci à toi, et à Laurent 😃
C'est possible qu'avec ce genre de vielle bécanes les accès à la cassette du jeu soit impossible en cours de jeu, et donc qu'il faille charger tout le moteur du jeu + le niveau du jeu en mémoire. Si c'est le cas, oui ça devait être une vraie guerre pour réussir à faire de bons jeux, c'était le temps des braves
Visiblement le CPC à lui aussi 64Ko de RAM. En revanche, il n'a pas visiblement été pensé pour le jeu, mais plus pour réduire les couts au max avec une architecture plus rustique que celle du C64. Cependant, étant plus récent, le CPC 464 pu bénéficier d'un processeur plus rapide tournant à 4 Mhz ! (contre 1 Mhz pour le C64), ainsi, j'imagine que cela a pu compenser en partie les faiblesses de son architecture du point de vue des performances attendues.
De mémoire, les jeux étaient plus ou moins dispo sur les deux machines, et relativement comparable en termes de qualité, avec des différences probablement liées aussi au hardware, soit potentiellement : un meilleur son et une animation plus fluide sur le C64, des couleurs plus chatoyantes sur le CPC.
Du coup, quand je joue sur émulateur, je choisis entre ce duo de bécane vraiment AU FEELING, et c cool d'avoir le choix (comme pour le duo SNES/Megadrive d'ailleurs)
@@user-sr6gc9ip5h il est très difficile de comparer les performances de processeurs différents. Le MOS 6502 est extrêmement performant et permet d'exécuter beaucoup d'instructions en 2 cycles seulement. Le Zilog Z80, de son côté est plus lent (certaines opérations sont exécutées en 4-bit) avec beaucoup d'instructions demandant 4 cycles ou plus. Donc un Z80 à 4MHz n'est pas 4 fois plus rapide qu'un MOS 6502 à 1 MHz.
@@ecdhe Oh okay, j'ignorais cela et là je lis que l'article wikipedia :
"Instructions per second"
confirme tes dires, d'après l'article, le C64 et le CPC 464 ont à peu près la même valeur MIPS malgré l'énorme différence de fréquence processeur !!.
c'est très étonnant, je ne m'attendais pas à un tel écart, c'est dingue
Quoi qu'il en soit, merci bcp pour l'info
Décidément l'univers des 8 bits est complexe et recèle bien des mystères
Passionnant. Je veux un livre de tout ça avec illustrations!
Je veux.
Ah ah, très bonne idée ça 😃
Whaou .... Ca donne envie. J'y serais
Merci pour cette vidéo. J'ai eu l'Oric Atmos et le CPC 464 puis 6128.
Merci pour le commentaire 😃
Merci pour ce format très intéressant avec Laurent. J'espère qu'il y aura d'autres vidéos du même genre. (décorticages et "secrets" de programmation des gros hits, etc...)
Merci, et oui c'est prévu 😃
On a quelques trucs dans les tuyaux. Maintenant, certaines machines risquent d'être plus privilégiées que d'autres. Pour les machines qui n'ont pas de systèmes d'accélération graphiques, expliquer les optimisations en assembleur risquent de barber tout le monde. Et il y a la contrainte de trouver des debugger puissants qui permettent de comprendre comment l'animation est programmée.
Cela dit, je suis ouvert aux suggestions, même si je ne promet rien
@@ecdhe Ok. Concernant les suggestions, si on prend par exemple l'Amiga, je pensais évidemment à des "gros" jeux comme Shadow Of The Beast, Unreal, Agony, Lionheart etc. Ces jeux dont on disait qu'ils poussaient vraiment la machine dans ses derniers retranchements.
Mais bon, pour ma part, software ou hardware, tout m'intéresse (et donc merci d'avance pour ce que vous nous montrerez).
@@zooropa9673 sur Amiga je n'ai pas encore trouvé de bon debugger qui permette de bien montrer les ressources graphiques. Utiliser un debugger en mode texte pour montrer la copperlist d'un jeu célèbre est certes instructif mais va barber tout le monde. Ou alors je reprend les ressources graphique d'un jeu et recode l'animation (comme je l'ai fait pour Pacmania dans la vidéo sur l'Amiga) mais ça prend *beaucoup* de temps. Par contre j'ai trouvé un tel debugger sur Commodore 64 - affaire à suivre!
@@zooropa9673 je ne sais pas pourquoi, mais mon commentaire a disparu. Sur Amiga je recherche un debugger graphique. Utiliser un debugger texte pour montrer la copperlist d'un jeu peut montrer beaucoup mais ça va barber tout le monde. Cela dit j'ai trouvé un superbe debugger sur C64 qui permet vraiment de décortiquer les astuces graphiques de certains jeux sur cette machine - affaire à suivre.
Très intéressant. Ça explique les différences de rendu qu'on trouvait entre les machines au final.
Pour le CPC, je crois me rappeler que Roland Perry avait expliqué que le format très bizarre de la vidéo était dû au fait qu'il avait détourné un processeur de son usage normal pour lui faire décoder de la vidéo en bitmap. Le processeur était prévu pour des caractères, il me semble.
C'est aussi pour ça qu'on pouvait faire des défilements matériels avec l'Amstrad, mais qu'ils étaient limités à des palliers de 8x8 (en mode 1). D'où certains jeux qui bougeaient beaucoup trop vite pour être jouable (à mon avis). Paradoxalement, pour faire défiler moins vite, il fallait redessiner avec le microprocesseur Z80, ce qui était très lent en comparaison.
Oh merci pour ton commentaire, et je n'etais pas au courant des ces spécifications pour le CPC, super intéressant !!!
@@GENERATIONMICROS Avec plaisir. Comme je dis tout cela de mémoire, je laisse les spécialistes me corriger et compléter.
Super série de video ❤
Merci Olivier 😉
Très intéressant merci.
Merci à toi 😊
Super vidéo ! Très technique pour ceux qui n'y connaissent rien mais moi j'ai adoré même si je ne suis pas spécialiste en dehors de l'Apple II ... le mode "entrelacé" de l'Amstrad (comme quoi les X octets en mémoire après la ligne 1 concernent la ligne 8 au lieu de la ligne 2) se retrouve d'ailleurs aussi sur l'Apple II (mais au lieu de la ligne 8 c'est la ligne 64) ... graphiquement l'Apple II était une des machines les plus tordues (pas compliqué une fois qu'on a pigé mais tordu) à programmer ... et malgré tout les programmeurs ont trouvé 1001 astuces pour ne pas trop en demander au CPU (6502) pour obtenir les effets escomptés.... ceci dit chaque choix fait par Steve Wozniak en 1977 était le bon pour l'époque.... sauf que les programmeurs ont du se coltiner les contraintes consécutives à ces choix jusque fin 1993 environ ... allez ... 15 ans pour un micro 8 bit c'est une belle vie ...
Je ne sais pas si chaque choix de Wozniak était le bon, mais c'est clair qu'il a dû créer un processeur graphique sans grand repère. Il n'y avait à ma connaissance aucun autre micro avec un mode graphique pour prendre comme référence, et Woz a conçu l'Apple ][ en grande partie tout seul (il aurait eu un coup de main sur l'alim). Cela dit si tu connais certaines astuces utilisées par les programmeurs sur l'Apple ][ je suis intéressé.
Merci à toi ... et oui l'Apple 2 a une vie extrêmement longue ...
Super intéressant. Fais en plus lol
Merci. C'est prévu 😃
Excellente video
Merci à toi !!!
6:18 Wozniak a inventé ce système génial en exploitant la norme d'affichage couleur du NTSC. Le signal de chrominicance utilisé par les télé pour encoder les différentes couleurs utilisait des fréquences élevés qui se rajoutait sur le signal Noir&Blanc. L'idée de Woz fut d'utiliser le va et vient des pixels allumés et éteint comme source de fréquence simulant le chroma. Avec ça il a été capale de coder 4 couleurs: 00 noir, 01 vert, 10 magenta, 11 blanc (les preniers modèles d'Apple II n'avaient que 4 couleurs). Un peu plus tard il a découvert qu'avec juste un circuit de ratard, il pouvait décaller les pixels d'une demi-phase en utilisant le bit de poids fort de l'octer, ainsi, il captait les 2 autres couleurs pour juste le coût de deux inverseurs.
L'autre astuce de Woz, était de disposer les lignes vidéo de telle sorte que le flux continu pour générer l'écran, touche toute les lignes (signale RAS) des mémoires vives, ainsi la vidéo se chargeait de rafraichir les RAM dynamique automatiquement sans avoir besoin d'ajouter une circuiterie de rafraichissement (horloge, générateur d'adresse, bloquage du bus etc.).
On ne se rend pas compte à quel point Steve Wozniak était astucieux.
Tout ce que j'ai lu sur Woz suggère qu'il s'était spécialisé dans l'optimisation de circuits pour utiliser le moins de composants possibles. Par contre, programmer des graphismes sur Apple II devait être coton...
Woz est un dieu, sans lui Apple n'existerait pas. C'est un grand maître de l'optimisation électronique.
merci
Mais de rien, avec plaisir 😃
Très bien
Merci 😃
La vidéo est très sympa. J'adore. Merci.
Une petite explication sur le Commodore 64, dont les résolutions sont complexes et mal expliquées dans les ouvrages de base. La résolution la plus utilisée est le mode texte (et non pas bitmap), qui est toujours de 25 ou 24 caractères par lignes. Chaque caractère peut avoir une couleur différente possible sur 16 disponibles, pour une résolution de 8x8 sur 40/38 colonnes (équivalent d'un 320 x200). Chaque caractère peut sinon avoir une résolution de 4x8 (de 3 couleurs + fond) ou 8x8 (d'une couleur sur 8 possibles + fond) sur 40/38 colonnes... Le bit 3 des octets en mémoire couleur va déterminer la résolution du caractère en mode multicolore. Ce n'est donc pas exactement 160x200.
Les sprites font 24x21 en mode "classique", avec une couleur principale et celle du fond d'écran. Ils sont définis par 3 octets sur 21 lignes, d'où ces 63 octets. Huit sprites peuvent être affichés toutes les 21 lignes, lors d'un balayage de l'écran, mais vous pouvez en afficher jusqu'à 212 simultanément à l'écran.
Merci pour ces prévisions. Je pensais que la limite était 4 sprites par scan line, autant pour moi. Les 212 sprites à l'écran, je suppose que c'est en réutilisant des sprites par le biais des raster interrupts?
Merci, super intéressant tes précisions !!!
@@ecdhe c'est bizarre, ma réponse initiale a disparu.
Les 212 sprites sont différents (forme et couleur). Les interruptions IRQ ou NMI sont hautement recommandées, mais pas forcément nécessaires, si le timing est bien géré. J'ai fait un tuto récemment sur les 212 sprites.
@@Commodoreretro-programming j'ai remarqué que si tu mes des liens le commentaire a la fâcheuse tendance à disparaitre. Il est dispo qqpart ton tuto? (YT ou autre)?
@@ecdhe Oui ! Deux tutos très courts avec le code source. Ils sont dans mes dernières vidéos de 1:15 sur YTP.
3:00 deux grosses exceptions à ce schéma. L'Atari VCS 2600 qui n'avait pas de frame buffer (il avait tou juste 128 octets de RAM) mais manipulait en temps réel le faisceau par programme et le Vectrex qui utilisait un système vectoriel. Là, non plus, pas de Frame buffer mais une liste de points et de vecteur.
Mais bon, ce sont tous les deux des consoles, pas des micro.
Tout à fait, mais pour la VCS c'est couvert dans la vidéo dédiée à ce système d'il y a quelques semaines
Les liens ne sont pas autorisés sur ces vidéos?
J'avais posté un commentaire sur l'Oric, mais ca à disparu 😥
Alors desolé ce n'est pas moi, c'est automatiquement RUclips qui refuse une fois sur deux les liens. Tu peux réessayer, peut être en enlevant le http ?
@@GENERATIONMICROS C'est surtout chiant que les messages ne soient pas conservé quelque part, j'avais mis des notes sur la vidéo le jour de la sortie, maintenant il faut que je me souvienne du contenu :-/
Bon j'abandonne, j'ai fait 4 tentatives et ca ne marche pas, donc j'ai du me retrouver "shadowbanned" ou un truc du genre...
@@DbugII Arf désolé, j'ai été voir si j'avais des commentaires mis dans la partie 'en cours d'examen', mais il n'y a rien. RUclips les a donc directement supprimés sans même me demander de les confirmer, ce qui est très souvent le cas malheureusement ...
Poste sur le groupe face de bouc?
Bonsoir à vous tous, en prévision d' un projet professionnel, se servir de nos bases des années 80 et les utiliser 45 ans plus tard, Est-ce une mauvaise idée ??? . Des suggestions pour mon projet futur sont et seront toujours les bienvenues autant positives que négatives. Merci à vous j'attends vos vommentaires
Bonsoir, disons que ça risque d'être compliqué rien que pour les formats non ? Ceux-ci sont-ils toujours identiques, réutilisables ou convertissables ?
@@GENERATIONMICROS Merci de votre réponse, j en saurai plus le 29/04. Et si bonnes nouvelles, je vous tiendrai au courant
Bonjour, quel est votre projet ? Refaire des modes graphiques limités comme ça ?
Car actuellement avec la mémoire qu'on, le mode graphique standard a une profondeur de pixels de 24 bits (32 si on compte un alpha) ce qui arrive aux limites de l'oeil humain, et des résolutions de plus en plus fines, avec chaque pixel indépendant.
D'une certaine manière, on est arrivé au bout de ce qu'on peut faire en rendu graphique, toutes les machines marchent comme ça depuis 25 ans et ça restera ainsi....
Ce que je n'ai jamais compris c'est pourquoi faire du 160x200 alors que la logique aurait été de faire 200x160 ??? Les écrans verticaux pour les shmup en arcade pourquoi pas mais en ordi domestique ...
La raison des 200 lignes est que les écrans de TV (du moins les NTSC) ont à peu près 192 lignes visibles (plus ou moins selon les modèles). Afficher 160 lignes serait complexe. On aurait par contre pu avoir un mode 320x100 qui aurait pris autant de mémoire.
@@ecdhe En effet les 192/200 lignes c'est logique mais c'est surtout le fait d'avoir moins de pixels horizontalement que verticalement qui me chiffonne vu que les tv ou moniteurs étaient en 4/3 ou carré, donc on devrait avoir plus de pixels horizontalement, sinon ca créer cet effet étiré qui rends, je trouve, les graphismes assez moches, surtout quand il y a une palette limitée comme celui de la C64 (une résolution de 320x100 serait catastrophique ceci dit).
Pour moi la résolution idéale est donc le 256x192/212 ou 256x240 (NES) ou la 320x240/256.
@@colonelkomarov622 l'utilisation de 200 lignes maxi remonte au moins à l'Atari 2600. Et je crois que la crainte à l'époque était que certains téléviseurs n'affichent pas certaines lignes si tu utilises un mode 256x240. Pour ce qui est du choix des pixels étirés, ça fait partie des compromis qui ont sans doute parus acceptables à l'époque.
Effectivement, la technologie des télés d'avant contraignent à 200 lignes, et comme on a peu de mémoire, on est obligé de sacrifier des colonnes.
Mais rapidement avec davantage de mémoire, on est passé en 320x200 ou 320x240 qui a un rapport de 4/3