Save state sur une vraie console - Page 1

Quelqu'un a suggéré l'ajout d'une fonctionnalité pour mon simili-ODE pour Neo CD: pouvoir enregistrer et reprendre une partie n'importe où et n'importe quand, comme avec les save state sur émulateur.

Au premier regard ça pourrait se faire: il "suffirait" de geler le jeu, et d'enregistrer tous les états et toutes les mémoires dans un fichier. Chemin inverse pour reprendre la partie.
Le sieur en question m'indiqua que certaines Everdrive ont cette fonctionnalité.

Cependant: sur NeoCD, le jeu décide de lui même où charger les fichiers qu'il souhaite dans les 7Mo de cache.
Alors je ne vois que deux choix:

• Je dump et recharge absolument tout sans réfléchir. Sachant qu'écrire toute la RAM, la VRAM, les registres, et le cache entier (~8Mo) va demander aux joueurs beaucoup de patience (un peu dommage pour un mod qui est censé accélérer les chargements). Pareil dans l'autre sens, ça sera l'équivalent de charger un jeu entier.
• J'essaye de trouver un moyen de suivre la fragmentation du cache, pour savoir quels morceaux de quels fichiers utiliser pour le reconstituer. Il n'y aurait dans ce cas qu'à enregistrer une liste de noms de fichiers et quelques pointeurs / tailles de copies.
  

Qu'en pensez-vous ? Quelle voie devrais-je tenter ? La bête et lente, ou la casse-tête et rapide ?
Auriez-vous une autre idée ?

Commence par faire la bête et méchante pour essuyer les plâtres, fais tester le résultat par des utilisateurs, et tu verras ensuite si c'est la peine de te casser la tête pour améliorer

Une idée comme ça : je sais pas si c'est possible, mais tu pourrais effacer le cache avant de lancer le jeu en remplissant avec des zéros. Ensuite quand tu fais la sauvegarde, tu découpes le cache en blocs (de 1 Ko, par exemple). si un bloc ne contient que des zéros, tu ne le sauvegardes pas (et tu gardes une table quelque part pour dire quels blocs sont effectivement utilisés). C'est moins compliqué que de tracker les chargements, et ça devrait déjà aider.

En version un peu plus évoluée, tu peux aussi utiliser un algo de compression simple et rapide : en plus des zones vides, ça devrait aider aussi pour les trucs qui se compressent bien, comme les tiles et les maps. À voir cependant si le temps de compression/décompression ne rend pas ça contre-productif.

Putain mais oui !
je me porte volontaire pour les tests !

merci et bon courage a toi et kuk , je scrute l'avancement des travaux

La version bête et méchante a été implémentée avec un minimum de succès, c'est à dire que j'arrive à stocker et récupérer l'état d'une partie de League Bowling (super intéressant...)

Par contre au chrono j'ai 3 minutes 10 pour la sauvegarde, et 1 minute pour la restauration

La longueur s'explique bien sûr par la quantité de données transférées. J'ai cependant espoir que ce soit réduit grâce aux suggestions de Zerosquare.

Par contre, la (grosse) différence entre l'aller et le retour s'explique par le fait qu'il n'y a pas de FIFO dans le sens console -> loader.
Ça oblige le code de transfert à attendre que le loader acquitte chaque mot de 16 bits. C'est pas long, l'acquittement se fait la plupart du temps lors de la première itération de la boucle d'attente, mais sur 8Mo ça chiffre...
Il n'y a pas de place dans le CPLD pour ajouter un deuxième FIFO, donc la possibilité d'implémenter les save states va vraiment dépendre de comment palier à ça :/

Moi je vois ça comme une feature permettant d'éviter l'abus de savestates qui rendent les jeux trop faciles. Ça dissuadera Kuk de tricher honteusement à ses jeux de... mahjong. Et puis la Neo-Geo c'est une console d'arcade, alors c'est déjà un luxe de pouvoir sauvegarder à n'importe quel moment !

Tu n'a pas moyen d'utiliser le même FIFO pour les deux, avec des muxes pour changer le sens suivant ce qu'on veut faire ?