Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
Oh et pour la musique chiptune faite "à la main": https://www.linusakesson.net/hardware/chiptune.php