Vespertino world racing

Encore plus d’angoisse :slight_smile:

Seulement 2 questions :

  • on sait que le jeu sortira au format cartouche avec un adaptateur CPC standard et gamme Plus, c’est bien ça ?
  • Une version numérique est-elle prévue pour les émulateurs ou les systèmes FPGA ?
18 « J'aime »

Encore de la bouillie d’IA…

:Allongé par terre en train de pleurer:

1 « J'aime »

Pas de mode 4 joueurs sur le même écran ? Rendez-moi mon argent que je n’avais pas encore dépensé…

Rhino, franchement, je suis sans voix.

RESPECT à toi personnellement et à tous les gars qui ont participé à ça.

Depuis Batman Forever en 2011, tu as vraiment redonné un coup de boost à la communauté CPC de tant de manières différentes.

Merci !

3 « J'aime »

Le jeu incontournable est arrivé comme promis.

Merci.

1 « J'aime »

Je peux seulement dire :

wesh / c’est quoi ce bordel.

1 « J'aime »

À défaut de le voir sur un vrai CPC, ça a l’air impressionnant, plus que quelques jours à attendre :alien::cool_button:

2 « J'aime »

Tout simplement magnifique !

1 « J'aime »

Tout simplement i n c r o y a b l e !!!

1 « J'aime »

Ça a l’air impressionnant, mais pourquoi avoir laissé la machine à bouillie faire cette bande-annonce pourrie ?

Trente secondes de vidéo tournant sur du vrai matos auraient été bien plus efficaces.

1 « J'aime »

vieux grincheux va grincher :smiley:

Pas convaincu par World Racing dans le titre. Real Racing Simulator sonne quand même bien mieux. Et tant qu’on y est, pourquoi ne pas ajouter Gran devant Vespertino ? Et voilà ! C’est dans la boîte !

OMG, imagine une version sur une cartouche Plus standard, jouable entièrement à la manette sur une GX4000 moddée 128K :face_with_tongue: ! Tu imagines ?

1 « J'aime »

Vidéo intéressante. Elle semble confirmer mon intuition.

Voici ci-dessous mes intuitions et mes suppositions. Je ne juge pas et n’essaie pas de minimiser l’exploit. Le résultat est très impressionnant. Bravo !

La stratégie globale repose selon moi sur deux axes

  • :chipmunk: Le Z80 n’a pas de cache d’instructions. Chaque instruction coûte très cher (par rapport au i386 et aux processeurs ultérieurs où les instructions exécutées plusieurs fois dans une petite boucle sont beaucoup plus rapides). Un code Z80 rapide est un code qui exécute moins d’instructions par octet écrit. Par conséquent, une règle d’or de l’optimisation de code sur Z80 est : supprimer toutes les instructions qui n’écrivent pas d’octets dans la destination. Supprimer (dérouler) les boucles. C’est surprenant de voir tout ce qu’on peut supprimer en poussant une telle approche à l’extrême. C’est d’ailleurs en explorant ces idées à fond que j’ai réussi à coder Sunny Day (for A Shadow Party) :: pouët.net
  • :optical_disk: Une stratégie extrême de compromis mémoire/CPU. Normalement, le CPC n’a pas assez de mémoire pour pousser cette approche à l’extrême. Si l’on dispose d’une ROM externe aussi volumineuse qu’on le souhaite, on peut aller encore plus loin. Détails ci-dessous.

Détails

  • :alien_monster: En observant la vidéo image par image, on remarque que les voitures sont affichées avec une granularité d’un octet. La largeur s’étend vers la gauche et la droite par sauts de deux pixels. Quand l’un d’eux n’est pas désiré, il est gris. Invisible sur les portions grises de la route. Visible ailleurs. Cela permet d’avoir des routines d’affichage plus simples et plus rapides : il suffit d’écrire des octets, pas de masque ni de manipulation de bits.
  • :high_voltage: Pourtant, une routine d’affichage extrêmement rapide reste indispensable. Appliquez la règle d’or ci-dessus.
  • :left_right_arrow: Si la voiture ne monte ni ne descend (la voiture du joueur en particulier), la routine est encore plus simple et plus rapide.
  • :optical_disk: Pousser ces choix à l’extrême, quel qu’en soit le coût en stockage. C’est pourquoi cela ne fonctionne qu’avec une cartouche ROM. D’immenses zones (en lecture seule) sont nécessaires.
  • :window: Les énormes voitures qui tournent sur l’écran de sélection, c’est de la simple compression delta. La plupart des pixels ne changent pas et les modifications sont connues à l’avance, ce qui rend la chose très rapide. Quand on a des tas d’octets de ROM disponibles, il suffit de faire ça. Encore une fois, c’est similaire à ce qui a été fait dans Sunny Day (for A Shadow Party) :: pouët.net où l’ensemble des octets réellement écrits est n fois plus petit que ce qu’il paraît (si je me souviens bien, n=6).
  • :high_voltage: Tous les éléments animés sont dessinés via du « graphisme sous forme de code » (graphics-as-code). L’affichage n’appelle pas une routine générique de type « dessiner quelque chose » à partir de « données spécifiques ». À la place, « dessiner quelque chose » signifie appeler une routine spécialisée (par exemple, une routine pour chaque voiture dans chaque orientation spécifique, une routine pour chaque objet à chaque distance). Les routines sont du code Z80 prégénéré, conceptuellement très simple : on écrit juste des octets, sans boucle, sans rien. (La technique n’est pas nouvelle, elle a été utilisée dans un certain nombre de prods. J’ai fait ça pour les animations de transition de niveau dans Just Get 9).
  • :optical_disk: Un indice révélateur de la stratégie « une fois qu’on part du principe qu’une énorme ROM est disponible, ce n’est pas grave d’avoir d’énormes besoins en ROM », c’est le nombre de vues de chaque objet. Dans la vidéo, les auteurs annoncent plus de 5000 sprites. À partir du moment où l’on dispose d’un milliard d’octets et qu’on peut générer des milliers de sprites avec le rendu d’un modèle 3D de voiture, autant le faire. Le résultat est un rendu d’une fluidité et d’une clarté impressionnantes pour les positions 3D des voitures sur la route.
  • :motorway: Ceci s’applique à mon avis au tracé de la route. Avoir une immense liste de routines spécialisées qui dessinent simplement une section horizontale entièrement terminée de la route. Appeler la routine appropriée pour chaque ligne. Ce sera plus rapide que le moteur déjà véloce de Chase HQ, qui dessine des sections grossières puis les affine pour les bandes blanches. C’est bien sûr plus complexe qu’un motif répétitif comme dans Sub Hunter, mais ce jeu démontre bien que d’immenses zones de l’écran peuvent être animées avec fluidité en écrivant directement (pushant) des octets.
  • :window: Il y a aussi du double buffer, mais pas pour tout l’écran. Un écran plein en overscan représente 24 ko d’octets utiles. Avec des réglages spécifiques du CRTC et peut-être une coupure d’écran (screen split), ces 24 ko peuvent être « compactés » (laissant le reste de la mémoire pas trop fragmenté). Deux buffers représentent 48 ko. Il reste ainsi une zone entière de 16 ko commutable pour le bank switching. On bascule les innombrables banques de mémoire pour accéder à la ROM physique de la cartouche. Même le code peut être dupliqué dans les ROMs.

Et… je ne suis pas sûr à 100 % que cela couvre tout. Il y a peut-être (probablement) d’autres secrets.

3 « J'aime »

Merci beaucoup pour vos mots !

1 « J'aime »

Une analyse intéressante, je ne dirai pas si elle est exacte ou non ! :slight_smile:
Mais j’ai une question… Dans ce type de jeux, la largeur de la route est généralement bien supérieure à celle de l’écran visible, car la route se déplace lorsque l’on bouge latéralement. Les routines que tu proposes, qui tracent chaque ligne horizontale, ne rendraient-elles que la zone visible ? Si c’est le cas, combien de routines seraient nécessaires pour chaque ligne horizontale afin d’obtenir un défilement horizontal au pixel près ? Merci !

C’est absolument bluffant, tout simplement incroyable !

Toutes mes félicitations à toute l’équipe pour cette avancée phénoménale.

@Rhino

Y aura-t-il prochainement des discussions autour de certaines techniques utilisées dans le jeu ?

1 « J'aime »

Quand j’ai appris que le jeu allait utiliser des milliers de sprites pré-rendus stockés sur ROM, j’ai tout de suite su que le redimensionnement et les rotations offriraient une fluidité bien supérieure à tout ce qui avait été tenté jusqu’ici — et maintenant que je le vois enfin en mouvement, je ne suis vraiment pas déçu. Le CPC peut accomplir des prouesses quand on lui adjoint beaucoup de mémoire, mais cela demande un travail colossal pour l’exploiter correctement.

Ce qui m’a vraiment bluffé, c’est le soin et l’attention portés à l’interface, aux menus, etc. C’est une étape longue et pas toujours amusante dans le développement d’un jeu, et pourtant tout semble aussi soigné que possible, avec une cohérence visuelle qui harmonise l’ensemble.

Avec une telle somme d’efforts, on ne peut qu’espérer que la jouabilité soit à la hauteur du rendu visuel. Je vois pas mal de voitures à l’écran en même temps, ce qui est très prometteur. Ils n’ont pas lésiné sur les véhicules adverses.

4 « J'aime »

Eh bien, toi, le maître codeur du Batman Group, tu me poses une question de code ? Il doit y avoir un piège. :sweat_smile:

Et effectivement, je n’ai fait aucun calcul, c’est d’ailleurs pour ça que j’ai stratégiquement écrit « un zillion d’octets », ce qui apporte un « flou » bienvenu.

Bon, laisse-moi réfléchir et essayer de répondre à ta question. Avoir des routines spécialisées qui écrivent une ligne entière de route dans tous les cas de figure serait simple (temps constant, écriture de 80 ou même 96 octets en plein overscan), mais cela demanderait un nombre extrêmement élevé de routines. Une façon de réduire ça pourrait être de PUSH des octets de couleur de sol depuis la droite, puis d’appeler des routines spécialisées pour tracer la route elle-même, et enfin de PUSH d’autres octets de couleur de sol. Ce modèle limite un peu le nombre de combinaisons, mais il ne peut pas afficher les cas où la route déborde des bords de l’écran à gauche ou à droite. Mmmh, il y a une autre option qui limite encore le nombre de routines, tout en maintenant une vitesse globale rapide. Que dirais-tu d’une table à deux niveaux en cascade : pour une géométrie de ligne donnée, on consulte une liste de routines plus courtes, et on appelle ces routines. Elles contiennent des valeurs d’octets précalculées pour afficher tous les pixels et leur nombre est beaucoup plus restreint. Cela couvrirait même les situations où la ligne de route déborde de l’écran à gauche et à droite, sans calcul au runtime. J’ai vu juste, @Rhino ?

(attention, blague en approche :police_car_light:) Coup de théâtre : au fil des ans, les teasers de Vespertino étaient bidonnés, les auteurs posent des questions sur les forums, rassemblent les réponses au fil des années jusqu’à ce qu’une IA assez puissante voie le jour, pour lui donner les réponses et obtenir le vrai boulot. :exploding_head: Je rigole. :smile:

Redevenons sérieux : félicitations à toute l’équipe pour cette prod impressionnante !

Après tout ce temps et tous ces teasers, j’ai vraiment hâte de voir et de jouer enfin à Vespertino !

1 « J'aime »