CGDoom pour Graph 90+E : série Doom et autres jeux 3D
Posté le 26/07/2021 18:34
CGDoom est un port du moteur DOOM créé par Id Software (1993) et qui permet de jouer à un grand nombre de jeux en 3D, avec non seulement la série Doom, mais aussi beaucoup de dérivés, titres indépendants, et même homebrew.
Le moteur est issue de nDoom (port TI-Nspire) et est passé entre pas mal de mains. La première version de CGDoom est de Martin Poupe, et cette version Graph 90+E est de Computer_Freak_2004 et moi. Il y a tout un topic sur Cemetech.
Visualisation d'un démo de E1M1 en 1:08 par Lephe (*)
Pour jouer, il vous faut à la fois l'add-in et un jeu Doom (sous la forme d'un fichier .wad). Les WADs font plusieurs Mo, pour les plus gros la copie sur la calculatrice prend 10-15 minutes, soyez patients !
Autres jeux
Pas mal d'autres jeux sont susceptibles de marcher, n'hésitez pas à lancer les WADs et voir ce qui se passe ! Il y a plein de titres en attente de test que je rajouterai au fur et à mesure.
Lancement et options
Le menu principal cherche automatiquement les WADs dans la mémoire de stockage, pour jouer sélectionnez l'une des options "Play ..." en haut de l'écran. Vous pouvez commencer directement sur un épisode/niveau choisi, ou bien lancer le jeu par le menu principal et commencer du tout début.
L'option Use experimental RAM est assez importante. La Graph 90+E a une puce de 8 Mo de RAM, alors que l'OS n'en utilise en général que 2 Mo (comme sur la Prizm). Si vous activez cette option, CGDoom utilisera une partie jugée safe des 6 Mo restants (même si on ne sait pas vraiment), ce qui fait une très grosse différence en jeu (et est nécessaire pour les plus gros jeux comme Doom II).
Le sous-menu Customize controls... permet de modifier les contrôles. Il y a plusieurs configurations par défaut, dont Thumbs only qui se joue avec deux pouces, et Full hands qui se joue avec les deux mains à plat sur le clavier.
Les options et les contrôles sont sauvegardés automatiquement dans CGDoom.cfg dans la mémoire de stockage donc ils restent d'une partie à l'autre !
Contrôles principaux
Le menu principal en jeu s'ouvre avec [MENU], et on valide dedans avec [EXE] ; chosissez Quit Game pour sortir.
Dans le mode Thumbs only :
Déplacement avant/arrière avec les touches directionnelles, déplacement latéral avec [X,θ,T] et [log]. Pour courir, [tan].
Tourner vers la gauche/droite avec les touches directionnelles.
[ALPHA] pour tirer, [x²] pour interagir avec les portes/boutons/etc.
Les 7 armes sont sur les touches [F1]...[F6] et [7].
Dans le mode Full hands :
Déplacement avec le pavé directionnel formé de [OPTN], [ALPHA], [x²] et [^] (main gauche). Pour courir, [cos].
Tourner vers la gauche/droite avec [F5]/[F6] (main droite).
[DEL] pour tirer, [×] pour interagir avec les portes/boutons/etc (main droite).
Les 7 armes sont sur les touches [1]...[7].
Toute la rangée de la touche de fraction à [→] contient des paramètres d'ajustement/debugging, dont un ajustement de luminosité sur [Frac], un compteur de FPS sur [(], une touche pour tricher sur [,] et une autre pour passer à travers les murs (noclip) sur [→].
Sauvegardes et démos
CGDoom supporte la sauvegarde des parties. En jeu, ouvrez le menu principal avec MENU puis choisissez Save Game. Vous pourrez alors entrer le nom de la partie. Il y a 6 emplacements de sauvegarde pour chaque WAD, chacun correspondant à un fichier comme doom_0.dsg. Les fichiers sont enregistrés dans la mémoire de stockage quand vous quittez l'add-in, pour des raisons techniques.
Plus tard, vous pouvez relancer le même WAD et charger la partie avec Load Game.
CGDoom supporte aussi l'enregistrement de démos, qui sont des fichiers contenant toutes vos actions clavier et qui permet de rejouer les parties après coup (c'est ce qui a été utilisé pour faire la vidéo en haut de ce topic).
Pour enregistrer un démo, indiquez un nombre dans l'option Record on demo slot sur le menu principal. Un fichier dans le genre doom_demo01.lmp sera créé. Toutes les actions du moment où vous entrez en jeu (après le menu principal) jusqu'au moment où vous quittez (en utilisant l'option Quit Game du menu) sont enregistrées. Comme les sauvegardes, le fichier démo est créé quand vous quittez l'add-in.
Vous pouvez ensuite rejouer votre propre démo, ou les démos des autres (celui en haut du topic est ici), en utilisant le sous-menu Replay demo.... Bien sûr, il faut que vous ayez le WAD du jeu correspondant, puisque la démo ne contient pas le jeu (que les entrées saisies).
Leaderboard de speedruns
Vous n'imagineriez pas jouer à Doom et ne pas partager quelques démos de speedruns quand même !
Ultimate Doom E1M1 (Ultra-Violence max)
1:08 par Lephe (démo ; overclock, frameskip 0, Full hands)
1:23 par Computer_Freak_2004 (démo ; overclock, frameskip 0, Thumbs only)
2:00 par Lephe (démo ; pas d'overclock, frameskip 1, Full hands)
Amusez-vous bien avec cette gemme unique de la Graph 90+E.
(*) La partie a été entièrement jouée sur la calculatrice, avec overclock, et le démo est visualisé sur PC uniquement pour la capture vidéo. La calculatrice maintient 30-35 FPS tout le long, seul le chargement initial est invisible sur la vidéo.
Merci, j'avais vu, très beau, et relativement fluide sans overclock contrairement aux fx-CG10/20, superbe.
Pour les petits bémols, cela semble malheureusement ne marcher qu'avec le seul fichier .wad de Doom1 "shareware".
Tous les autres fichiers .wad format Doom1 ou Doom2 génèrent des erreur/freeze/reset au chargement, et pourtant plusieurs d'entre eux ne sont pas bien plus gros : https://tiplanet.org/forum/archives_list.php?cat=Jeux+Doom+Nspire
Je ne sais plus, mais si le code de CGDOOM est basé sur la publication de celui de Doom1 pour DOS, les modifications pour gérer un large éventail des fichiers .wad, dont l'évolution Doom2 du format .wad, avaient été faites du côté du portage TI-Nspire CX à la même époque : https://tiplanet.org/forum/archives_voir.php?id=3889
@Lephenixnoir
Détail également, au cas où tu n'aies pas remarqué à côté de l'impressionnant affichage de tout le reste.
Quand tu arrives aux 'fenêtres' à partir de 0:20, il me semble noter que l'image de fond n'est pas affichée correctement.
Cela n'enlève rien à cette réussite technique déjà absolument colossale, mais si corrigé cela permettra de la rendre encore plus formidable.
Merci Critor. En effet, je n'ai pas du tout essayé d'autres fichiers .wad pour l'instant, ce sera quelque chose à tenter volontiers une fois que ça marchera un peu mieux. Ce serait cool si on pouvait le coder plus large que la version originale (plusieurs niveaux par exemple).
Le code de CGDOOM découle déjà de celui du portage Nspire CX en fait, on le retrouve dans les commentaires. Peut-être que c'est déjà dans le code et qu'il y a simplement des bugs sur la partie spécifique à la Graph 90+E (le système de fichiers) ?
La meme chose que ce qui il y a sur ta vidéo mais plus prononcé
Ah la barre de statut ! Oui la texture ne se charge pas bien, je l'avais remarqué. Mais pour l'instant je n'ai pas réussi à tracer le problème (j'allais m'y mettre la dernière fois mais vous aviez des soucis plus urgents !). Il semble à peu près clair que c'est encore une fois les accès aux fichiers dans la mémoire de stockage.
Merci. Tout dépend de quand date la reprise du code.
Pour le portage TI-Nspire, il avait été fait en 2 temps :
- une première version pour TI-Nspire monochrome,
- puis une deuxième version compatible avec les nouvelles TI-Nspire CX couleur (~2011-2012)
C'est moi qui m'étais occupé de cette deuxième version, et c'est à cette occasion que le support du format .wad avait été grandement amélioré pour accepter autre chose que les 2 seuls .wad de Doom 'shareware' et 'registered'.
L'ensemble des .wad que j'ai liés plus haut sont gérés (ou gérables avec de légères modifications à apporter si ce que tu as est plus proche de la version MSDOS que de la version Nspire CX), c'est-à-dire la totalité des jeux officiels (shareware, versions complètes, ou extensions) utilisant les moteurs Doom ou Doom2.
Ne sont pas gérés les .wad du jeu Heretic (utilise sous licence un moteur Doom modifié - il y est possible de voler par exemple). Cela aurait été sympa, j'avais d'ailleurs commencé, mais le peu de téléchargements au-delà de 2013 avait terminé de me décourager (faut dire qu'avec la manie de TI de bloquer Ndless tous les 6 mois, parfois pendant des mois/années, ça n'aidait pas).
Quelques .wad communautaires sont fonctionnels , mais très peu. Car beaucoup sont conçus pour être joués sur des outils qui ont fait évoluer le format.
Si aujourd'hui nous devions refaire une adaptation de Doom sur calculatrice, je pense que plutôt que de reprendre et étendre le vieux code de Doom pour MS-DOS, il faudrait partir d'un moteur/lecteur de .wad plus récent et polyvalent, gérant d'origine l'ensemble de la famille de jeux Doom / Doom 2 / Heretic, comme par exemple zDoom.
Aaah, je ne savais pas que tu étais derrière une partie du port ! Je suis à peu près sûr que c'est ta version que j'ai du coup, puisqu'il y a pas mal de commentaires "// CX port" dans le code.
Je suppose donc que c'est un bug de chargement lié à la mémoire de stockage (de toute façon tant que la texture de la barre de statut, et comme tu l'as correctement pointé du ciel, ne s'affichent pas correctement, c'est qu'il en reste).
Je ne pense pas opportun pour moi de me lancer dans un gros projet, donc je pense en rester pour l'instant à adapter le code de Martin Poupe. Si je peux me débrouiller pour ajouter d'autres niveaux du DOOM original (ce qui ne devrait pas être trop difficile en termes de gestion des wad je crois ?) ce serait sympa. Sinon, je vise surtout de tester des optimisations du démarrage, ajouter une barre de chargement, et quelques autres potentielles optimisations auxquelles je pensais. Plus du détail mais qui me paraît sympa pour polir le port.
Alors tous les .wad liés devraient pouvoir marcher une fois les erreurs de mémoire(?) au chargement corrigées.
Un truc qui pourrait être pratique, en tous cas pour les tests de différents fichiers .wad, c'est rajouter de quoi sélectionner la map à lancer au démarrage :
- pour les .wad format Doom1 : n° épisode + n° map dans l'épisode
- pour les .wad format Doom2 : n° map
Sinon il y a peut-être une façon de contourner les erreurs de mémoire, c'est de scinder les fichiers .wad. Pour les .wad Doom1, de façon évidente on pourrait découper par épisode.
J'ai tenté quelques éditeurs de .wad, je ne les ai pas trouvés bien conçus pour ce genre de chose (faut dire que hors calculatrices les utilisateurs ne doivent pas en avoir besoin).
Je n'ai pas réussi à obtenir de .wad fonctionnel, sans pouvoir dire pour le moment si ça vient de ma modification ou bien de CGDOOM. Je pourrai retenter quand tu estimeras avoir quelque chose de plus robuste.
J'ai nettoyé un peu le code et principalement ajouté une option pour utiliser BFile pour accéder au fichier au lieu du mécanisme personnalisé de lecture directe dans la ROM. Bien sûr, c'est plus lent durant le jeu et ça crée des micro-délais partout au point où c'est injouable par moments, mais ce sera une bonne référence pour le chargement des textures et la lecture des WAD plus musclés.
D'abord, comme tu l'as fait remarquer, la texture du ciel. Elle marche quand je lis avec BFile, et en fait elle marche aussi quand je fais la lecture directe. Je suppose que c'est grâce au bug que j'ai corrigé hier avant de publier le topic (la vidéo est plus ancienne et date du premier essai fonctionnel). Je classe ça dans la catégorie réglé.
Ensuite, le bug de la barre de statut. En fait elle ne s'affiche pas même avec BFile donc ce n'est pas un problème de chargement. Du coup je suis retourné voir ce que j'avais déjà cherché avant, à savoir la logique de rendu à l'écran. Il se trouve que DOOM a deux buffers de dessin, FG et BG, et CGDOOM n'affiche à l'écran que FG. Devinez sur lequel la barre de statut est dessinée.
Je ne sais pas exactement comment les deux buffers sont supposés interagir ensemble (et se composer), mais si je fais pointer BG sur les 32 dernières lignes de FG j'ai la barre de statut affichée correctement (plus quelques glitchs). Ce qu'on voit sur la vidéo en fait c'est de la mémoire non initialisée, d'où l'aspect vraiment exotique. Je vais voir si je peux trouver dans le code original la façon dont les deux buffers sont supposés marcher, mais en tout cas il y a du progrès
Critor si tu veux tester les WAD je peux te passer un build avec BFile, histoire de voir si ça charge. Si non, c'est peut-être un problème de trop peu de mémoire ou ce genre de limites matérielles ?
J'ai fini par trouver dans le code original qu'il y a 5 écrans (FG, deux BG pour deux modules différents, et deux écrans pour l'effet "wipe" qui est désactivé sur CGDOOM), et que la barre de statut gère normalement son propre écran qui est de hauteur 32 (et pas toute la hauteur). J'ai donc modifié pour lui laisser allouer et gérer le buffer, ce qui économise un peu de mémoire.
J'ai ensuite trouvé le coeur du bug qui était que la copie BG→FG plantait parce qu'elle utilise memcpy() sur chaque ligne et que le memcpy() dont je dispose est le syscall, qui pour la deuxième fois d'affilée a l'air vraiment buggé (la première fois étant durant la copie Flash→RAM pour charger les objets du wad).
J'ai utilisé une boucle naïve pour l'instant ; on est sur la bonne voie, comme le montre la photo ci-dessous (de qualité discutable).
Désolé, pas de progrès de mon côté, aucun .wad testé ne marche en hors de celui de Doom 'shareware'.
Messages d'erreur, crash, freeze, parfois rien du tout (drapeau occupé qui s'active puis s'arrête), c'est très varié.
Des "%s" qui apparaissent dans les messages d'erreur fait qu'ils ne sont pas très éclairants sur la ressource non trouvée, mal gérée, ou dont le chargement a échoué.
Mais entre autres des messages semblant relatifs à la mémoire.
En dehors du .wad shareware, la plupart des .wad tournent autour de 10 Mo.
Les versions sur TI-Planet sont un peu allégées (ressources audio retirées, même si on pourrait imaginer utiliser la prise mini-Jack sur Graph 90+E).
Autant commencer par se fixer un objectif, voici le .wad complet "Ultimate Doom", qui ne compte pas parmi les plus gros : https://tiplanet.org/forum/archives_voir.php?id=3868
9,84 Mo pour cette version allégée, 11,9 Mo pour la version originale.
4 épisodes pour 4*9=36 maps.
Le 1er épisode est le même que sur la version shareware. C'est donc au plus proche du .wad qui marche actuellement.
Si c'est la mémoire qui coince, à voir donc si il y a possibilité de découper ce .wad en 4 .wad distincts, un par épisode (ou 3, puisque le shareware correspond déjà au 1er épisode).
Merci beaucoup. Je soupçonnais que le chargement était au point depuis ma dernière mise à jour, donc ça m'arrange d'une certaine façon que tu n'aies pas observé de changements.
Les %s c'est casse-pieds oui, pour une raison que j'ignore Martin Poupe a désactivé tous les printf et remplacé les usages par des fonctions plus simples, mais on y perd dans ce genre de cas. Je réfléchis à le remettre, c'est pas comme si quelques ko de code allaient changer un G3A qui fait déjà 300 ko.
J'ai encore quelques objectifs dans ma TODO list, notamment une barre de chargement et d'autres petits détails utiles, et ensuite je regarde ton wad, merci beaucoup.
J'ai réussi à réduire pas mal le temps de chargement pour le doom.wad original en optimisant la recherche des données dans la Flash (5.2s → 3.4s, sachant qu'en passant à 512 octets/page c'était monté à 9.8s), mais j'ai encore quelques idées. Je sais pas trop jusqu'où on peut descendre, en tous cas ça devrait être plus agréable.
Bon, j'ai fini ma petite passe d'optimisation. Le commit a tous les détails, mais en gros pour doom.wad sur ma calto :
Le chargement va 2.7x plus vite (5.2s → 1.4s)
Le jeu va 35% plus vite
C'est tout des optis sur les accès à la Flash, à la fois algorithmiques (priorités, index), et d'implémentation (cache, memcmp aux petits oignons sauce assembleur). Je vous cache pas que je suis assez fier du résultat.
J'ai repéré que la texture de l'écran de fin de niveau est pas bonne, je vais y jeter un oeil avant de continuer sur le support des WADs suggérés par Critor.
Ah et aussi comme les perfs sont solides je testerai peut-être de mettre le jeu en résolution complète (384x216 voire 396x224) au lieu de la taille actuelle qui est 320x200.
Bonne nouvelle de mon côté. J'ai testé ton WAD, @Critor (edit: qui prend ~4.5s à charger avec les optis !)
L'erreur en question se produisait durant l'allocation d'un tableau pour stocker les informations sur les lumps dans le chargement du WAD. Avec le WAD plus gros, ce tableau, qui est normalement dans le tas OS, ne rentrait pas (en partie à cause de la fragmentation).
J'ai tordu un peu la séquence d'allocation pour l'allouer avec la fonction Z_Malloc de DOOM, qui dispose d'un tas plus grand (toute la pile OS qui fait environ 450 ko), ce qui m'a permis de progresser. En principe le jeu fait une première lecture du WAD pour déterminer le type de jeu (shareware, retail, etc) avant d'initialiser l'allocateur. Mais le code de l'allocateur est très simple donc j'ai avancé son initialisation, je suis largement confiant que ça ne posera pas de problème.
Avec ça, j'arrive à charger le WAD et à arriver dans le jeu. Cela dit, ça ne dure pas très longtemps parce que j'ai beaucoup d'échecs de Z_Malloc, simplement parce qu'on est à bout de mémoire (ce qui me donne des écrans blancs un peu tout le temps). Si je ne bouge pas trop je peux les ignorer et forcer, ce qui permet de jouer un peu, mais dès que je bouge autour dans Hangar il finit par en arriver un de fatal et le jeu freeze.
Je vais voir ce que je peux faire donc pour ajouter de la mémoire. On ne manque pas de petites zones utilisables, la difficulté principale c'est que Z_Malloc ne marche qu'avec une seule région unique. Si c'est nécessaire j'essaierai de l'étendre pour en supporter plusieurs, ce qui n'est pas outrageusement difficile.
Pas mal de nouveautés à signaler, je pense qu'on gagne pas mal en qualité. Je ferai un résumé dans le post principal à l'occasion (avec une nouvelle vidéo à l'occasion).
J'ai ajouté une barre de progression pour le chargement du fichier, c'est un peu plus agréable.
J'ai étendu l'allocateur interne de DOOM dans z_zone.c pour supporter plusieurs zones, et ajouté la partie non utilisée du tas utilisateur. L'utilisation de Z_Malloc pour allouer le tableau d'information des lumps poussait le tas à sa limite dans le WAD shareware, et l'allocateur échouait sur l'écran de fin de Hangar (niveau 1). Avec la modification, je peux jouer sans problème jusqu'à la fin de Command Control (niveau 4), où une autre erreur se produit ; j'enquête. Une texture se charge mal aussi semble-t-il.
L'ajout du tas supplémentaire permet aussi de charger le WAD de DOOM Ultimate que Critor a lié et d'y jouer. Je n'ai pas encore déterminé jusqu'à où ça marche. Là aussi quelques textures semblent mal se charger.
J'ai modifié l'icône pour que ça aille dans le style de menu de la Graph 90+E.
Et enfin j'ai modifié la façon dont les contrôles fonctionnent pour pouvoir appuyer sur plusieurs touches en même temps... ce qui est important dès qu'on essaie de jouer pour de vrai (s'arrêter pour tirer c'est limitant).
Wow, je n'y croyais plus trop et hier je réinstalle la nouvelle version et... ça marche !
C'est juste TROP bien !!!!!!
J'ai une erreur de Z_MALOC quelque part, je vais essayer de la reproduire et j'envoie ca !
En tout cas, bravissimo, c'est génial !
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 26/07/2021 18:46 | #
Ca marche sur ma calto, si on ignore les problemes sur le menu
Citer : Posté le 26/07/2021 18:47 | #
Merci, j'avais vu, très beau, et relativement fluide sans overclock contrairement aux fx-CG10/20, superbe.
Pour les petits bémols, cela semble malheureusement ne marcher qu'avec le seul fichier .wad de Doom1 "shareware".
Tous les autres fichiers .wad format Doom1 ou Doom2 génèrent des erreur/freeze/reset au chargement, et pourtant plusieurs d'entre eux ne sont pas bien plus gros :
https://tiplanet.org/forum/archives_list.php?cat=Jeux+Doom+Nspire
Je ne sais plus, mais si le code de CGDOOM est basé sur la publication de celui de Doom1 pour DOS, les modifications pour gérer un large éventail des fichiers .wad, dont l'évolution Doom2 du format .wad, avaient été faites du côté du portage TI-Nspire CX à la même époque :
https://tiplanet.org/forum/archives_voir.php?id=3889
Citer : Posté le 26/07/2021 18:47 | # |
Fichier joint
Excellent ! C'est un progrès déjà, avant ça ne marchait que chez moi.
Quels problèmes sur le menu ?
Citer : Posté le 26/07/2021 18:49 | #
> Quels problèmes sur le menu ?
La meme chose que ce qui il y a sur ta vidéo mais plus prononcé
Citer : Posté le 26/07/2021 19:00 | #
@Lephenixnoir
Détail également, au cas où tu n'aies pas remarqué à côté de l'impressionnant affichage de tout le reste.
Quand tu arrives aux 'fenêtres' à partir de 0:20, il me semble noter que l'image de fond n'est pas affichée correctement.
Cela n'enlève rien à cette réussite technique déjà absolument colossale, mais si corrigé cela permettra de la rendre encore plus formidable.
Citer : Posté le 26/07/2021 19:20 | #
Merci Critor. En effet, je n'ai pas du tout essayé d'autres fichiers .wad pour l'instant, ce sera quelque chose à tenter volontiers une fois que ça marchera un peu mieux. Ce serait cool si on pouvait le coder plus large que la version originale (plusieurs niveaux par exemple).
Le code de CGDOOM découle déjà de celui du portage Nspire CX en fait, on le retrouve dans les commentaires. Peut-être que c'est déjà dans le code et qu'il y a simplement des bugs sur la partie spécifique à la Graph 90+E (le système de fichiers) ?
Ah la barre de statut ! Oui la texture ne se charge pas bien, je l'avais remarqué. Mais pour l'instant je n'ai pas réussi à tracer le problème (j'allais m'y mettre la dernière fois mais vous aviez des soucis plus urgents !). Il semble à peu près clair que c'est encore une fois les accès aux fichiers dans la mémoire de stockage.
Citer : Posté le 26/07/2021 20:15 | #
Merci. Tout dépend de quand date la reprise du code.
Pour le portage TI-Nspire, il avait été fait en 2 temps :
- une première version pour TI-Nspire monochrome,
- puis une deuxième version compatible avec les nouvelles TI-Nspire CX couleur (~2011-2012)
C'est moi qui m'étais occupé de cette deuxième version, et c'est à cette occasion que le support du format .wad avait été grandement amélioré pour accepter autre chose que les 2 seuls .wad de Doom 'shareware' et 'registered'.
L'ensemble des .wad que j'ai liés plus haut sont gérés (ou gérables avec de légères modifications à apporter si ce que tu as est plus proche de la version MSDOS que de la version Nspire CX), c'est-à-dire la totalité des jeux officiels (shareware, versions complètes, ou extensions) utilisant les moteurs Doom ou Doom2.
Ne sont pas gérés les .wad du jeu Heretic (utilise sous licence un moteur Doom modifié - il y est possible de voler par exemple). Cela aurait été sympa, j'avais d'ailleurs commencé, mais le peu de téléchargements au-delà de 2013 avait terminé de me décourager (faut dire qu'avec la manie de TI de bloquer Ndless tous les 6 mois, parfois pendant des mois/années, ça n'aidait pas).
Quelques .wad communautaires sont fonctionnels , mais très peu. Car beaucoup sont conçus pour être joués sur des outils qui ont fait évoluer le format.
Si aujourd'hui nous devions refaire une adaptation de Doom sur calculatrice, je pense que plutôt que de reprendre et étendre le vieux code de Doom pour MS-DOS, il faudrait partir d'un moteur/lecteur de .wad plus récent et polyvalent, gérant d'origine l'ensemble de la famille de jeux Doom / Doom 2 / Heretic, comme par exemple zDoom.
Citer : Posté le 26/07/2021 21:05 | #
Aaah, je ne savais pas que tu étais derrière une partie du port ! Je suis à peu près sûr que c'est ta version que j'ai du coup, puisqu'il y a pas mal de commentaires "// CX port" dans le code.
Je suppose donc que c'est un bug de chargement lié à la mémoire de stockage (de toute façon tant que la texture de la barre de statut, et comme tu l'as correctement pointé du ciel, ne s'affichent pas correctement, c'est qu'il en reste).
Je ne pense pas opportun pour moi de me lancer dans un gros projet, donc je pense en rester pour l'instant à adapter le code de Martin Poupe. Si je peux me débrouiller pour ajouter d'autres niveaux du DOOM original (ce qui ne devrait pas être trop difficile en termes de gestion des wad je crois ?) ce serait sympa. Sinon, je vise surtout de tester des optimisations du démarrage, ajouter une barre de chargement, et quelques autres potentielles optimisations auxquelles je pensais. Plus du détail mais qui me paraît sympa pour polir le port.
Citer : Posté le 26/07/2021 21:21 | #
Merci pour ta précision.
Alors tous les .wad liés devraient pouvoir marcher une fois les erreurs de mémoire(?) au chargement corrigées.
Un truc qui pourrait être pratique, en tous cas pour les tests de différents fichiers .wad, c'est rajouter de quoi sélectionner la map à lancer au démarrage :
- pour les .wad format Doom1 : n° épisode + n° map dans l'épisode
- pour les .wad format Doom2 : n° map
Sinon il y a peut-être une façon de contourner les erreurs de mémoire, c'est de scinder les fichiers .wad. Pour les .wad Doom1, de façon évidente on pourrait découper par épisode.
J'ai tenté quelques éditeurs de .wad, je ne les ai pas trouvés bien conçus pour ce genre de chose (faut dire que hors calculatrices les utilisateurs ne doivent pas en avoir besoin).
Je n'ai pas réussi à obtenir de .wad fonctionnel, sans pouvoir dire pour le moment si ça vient de ma modification ou bien de CGDOOM. Je pourrai retenter quand tu estimeras avoir quelque chose de plus robuste.
Citer : Posté le 27/07/2021 12:22 | #
J'ai nettoyé un peu le code et principalement ajouté une option pour utiliser BFile pour accéder au fichier au lieu du mécanisme personnalisé de lecture directe dans la ROM. Bien sûr, c'est plus lent durant le jeu et ça crée des micro-délais partout au point où c'est injouable par moments, mais ce sera une bonne référence pour le chargement des textures et la lecture des WAD plus musclés.
D'abord, comme tu l'as fait remarquer, la texture du ciel. Elle marche quand je lis avec BFile, et en fait elle marche aussi quand je fais la lecture directe. Je suppose que c'est grâce au bug que j'ai corrigé hier avant de publier le topic (la vidéo est plus ancienne et date du premier essai fonctionnel). Je classe ça dans la catégorie réglé.
Ensuite, le bug de la barre de statut. En fait elle ne s'affiche pas même avec BFile donc ce n'est pas un problème de chargement. Du coup je suis retourné voir ce que j'avais déjà cherché avant, à savoir la logique de rendu à l'écran. Il se trouve que DOOM a deux buffers de dessin, FG et BG, et CGDOOM n'affiche à l'écran que FG. Devinez sur lequel la barre de statut est dessinée.
Je ne sais pas exactement comment les deux buffers sont supposés interagir ensemble (et se composer), mais si je fais pointer BG sur les 32 dernières lignes de FG j'ai la barre de statut affichée correctement (plus quelques glitchs). Ce qu'on voit sur la vidéo en fait c'est de la mémoire non initialisée, d'où l'aspect vraiment exotique. Je vais voir si je peux trouver dans le code original la façon dont les deux buffers sont supposés marcher, mais en tout cas il y a du progrès
Critor si tu veux tester les WAD je peux te passer un build avec BFile, histoire de voir si ça charge. Si non, c'est peut-être un problème de trop peu de mémoire ou ce genre de limites matérielles ?
Citer : Posté le 27/07/2021 12:28 | #
Merci, je veux bien, je te dirai ce que ça donne.
Citer : Posté le 27/07/2021 13:26 | # |
Fichier joint
Voici ci-joint.
Citer : Posté le 27/07/2021 14:38 | # |
Fichier joint
J'ai fini par trouver dans le code original qu'il y a 5 écrans (FG, deux BG pour deux modules différents, et deux écrans pour l'effet "wipe" qui est désactivé sur CGDOOM), et que la barre de statut gère normalement son propre écran qui est de hauteur 32 (et pas toute la hauteur). J'ai donc modifié pour lui laisser allouer et gérer le buffer, ce qui économise un peu de mémoire.
J'ai ensuite trouvé le coeur du bug qui était que la copie BG→FG plantait parce qu'elle utilise memcpy() sur chaque ligne et que le memcpy() dont je dispose est le syscall, qui pour la deuxième fois d'affilée a l'air vraiment buggé (la première fois étant durant la copie Flash→RAM pour charger les objets du wad).
J'ai utilisé une boucle naïve pour l'instant ; on est sur la bonne voie, comme le montre la photo ci-dessous (de qualité discutable).
Citer : Posté le 27/07/2021 19:35 | #
Désolé, pas de progrès de mon côté, aucun .wad testé ne marche en hors de celui de Doom 'shareware'.
Messages d'erreur, crash, freeze, parfois rien du tout (drapeau occupé qui s'active puis s'arrête), c'est très varié.
Des "%s" qui apparaissent dans les messages d'erreur fait qu'ils ne sont pas très éclairants sur la ressource non trouvée, mal gérée, ou dont le chargement a échoué.
Mais entre autres des messages semblant relatifs à la mémoire.
En dehors du .wad shareware, la plupart des .wad tournent autour de 10 Mo.
Les versions sur TI-Planet sont un peu allégées (ressources audio retirées, même si on pourrait imaginer utiliser la prise mini-Jack sur Graph 90+E).
Autant commencer par se fixer un objectif, voici le .wad complet "Ultimate Doom", qui ne compte pas parmi les plus gros :
https://tiplanet.org/forum/archives_voir.php?id=3868
9,84 Mo pour cette version allégée, 11,9 Mo pour la version originale.
4 épisodes pour 4*9=36 maps.
Le 1er épisode est le même que sur la version shareware. C'est donc au plus proche du .wad qui marche actuellement.
Si c'est la mémoire qui coince, à voir donc si il y a possibilité de découper ce .wad en 4 .wad distincts, un par épisode (ou 3, puisque le shareware correspond déjà au 1er épisode).
Citer : Posté le 27/07/2021 20:11 | #
Merci beaucoup. Je soupçonnais que le chargement était au point depuis ma dernière mise à jour, donc ça m'arrange d'une certaine façon que tu n'aies pas observé de changements.
Les %s c'est casse-pieds oui, pour une raison que j'ignore Martin Poupe a désactivé tous les printf et remplacé les usages par des fonctions plus simples, mais on y perd dans ce genre de cas. Je réfléchis à le remettre, c'est pas comme si quelques ko de code allaient changer un G3A qui fait déjà 300 ko.
J'ai encore quelques objectifs dans ma TODO list, notamment une barre de chargement et d'autres petits détails utiles, et ensuite je regarde ton wad, merci beaucoup.
Citer : Posté le 27/07/2021 23:11 | #
J'ai réussi à réduire pas mal le temps de chargement pour le doom.wad original en optimisant la recherche des données dans la Flash (5.2s → 3.4s, sachant qu'en passant à 512 octets/page c'était monté à 9.8s), mais j'ai encore quelques idées. Je sais pas trop jusqu'où on peut descendre, en tous cas ça devrait être plus agréable.
Citer : Posté le 28/07/2021 23:12 | #
Bon, j'ai fini ma petite passe d'optimisation. Le commit a tous les détails, mais en gros pour doom.wad sur ma calto :
C'est tout des optis sur les accès à la Flash, à la fois algorithmiques (priorités, index), et d'implémentation (cache, memcmp aux petits oignons sauce assembleur). Je vous cache pas que je suis assez fier du résultat.
J'ai repéré que la texture de l'écran de fin de niveau est pas bonne, je vais y jeter un oeil avant de continuer sur le support des WADs suggérés par Critor.
Ah et aussi comme les perfs sont solides je testerai peut-être de mettre le jeu en résolution complète (384x216 voire 396x224) au lieu de la taille actuelle qui est 320x200.
Citer : Posté le 29/07/2021 12:00 | #
Bonne nouvelle de mon côté. J'ai testé ton WAD, @Critor (edit: qui prend ~4.5s à charger avec les optis !)
L'erreur en question se produisait durant l'allocation d'un tableau pour stocker les informations sur les lumps dans le chargement du WAD. Avec le WAD plus gros, ce tableau, qui est normalement dans le tas OS, ne rentrait pas (en partie à cause de la fragmentation).
J'ai tordu un peu la séquence d'allocation pour l'allouer avec la fonction Z_Malloc de DOOM, qui dispose d'un tas plus grand (toute la pile OS qui fait environ 450 ko), ce qui m'a permis de progresser. En principe le jeu fait une première lecture du WAD pour déterminer le type de jeu (shareware, retail, etc) avant d'initialiser l'allocateur. Mais le code de l'allocateur est très simple donc j'ai avancé son initialisation, je suis largement confiant que ça ne posera pas de problème.
Avec ça, j'arrive à charger le WAD et à arriver dans le jeu. Cela dit, ça ne dure pas très longtemps parce que j'ai beaucoup d'échecs de Z_Malloc, simplement parce qu'on est à bout de mémoire (ce qui me donne des écrans blancs un peu tout le temps). Si je ne bouge pas trop je peux les ignorer et forcer, ce qui permet de jouer un peu, mais dès que je bouge autour dans Hangar il finit par en arriver un de fatal et le jeu freeze.
Je vais voir ce que je peux faire donc pour ajouter de la mémoire. On ne manque pas de petites zones utilisables, la difficulté principale c'est que Z_Malloc ne marche qu'avec une seule région unique. Si c'est nécessaire j'essaierai de l'étendre pour en supporter plusieurs, ce qui n'est pas outrageusement difficile.
Citer : Posté le 29/07/2021 21:18 | # |
Fichier joint
Pas mal de nouveautés à signaler, je pense qu'on gagne pas mal en qualité. Je ferai un résumé dans le post principal à l'occasion (avec une nouvelle vidéo à l'occasion).
J'ai ajouté une barre de progression pour le chargement du fichier, c'est un peu plus agréable.
J'ai étendu l'allocateur interne de DOOM dans z_zone.c pour supporter plusieurs zones, et ajouté la partie non utilisée du tas utilisateur. L'utilisation de Z_Malloc pour allouer le tableau d'information des lumps poussait le tas à sa limite dans le WAD shareware, et l'allocateur échouait sur l'écran de fin de Hangar (niveau 1). Avec la modification, je peux jouer sans problème jusqu'à la fin de Command Control (niveau 4), où une autre erreur se produit ; j'enquête. Une texture se charge mal aussi semble-t-il.
L'ajout du tas supplémentaire permet aussi de charger le WAD de DOOM Ultimate que Critor a lié et d'y jouer. Je n'ai pas encore déterminé jusqu'à où ça marche. Là aussi quelques textures semblent mal se charger.
J'ai modifié l'icône pour que ça aille dans le style de menu de la Graph 90+E.
Et enfin j'ai modifié la façon dont les contrôles fonctionnent pour pouvoir appuyer sur plusieurs touches en même temps... ce qui est important dès qu'on essaie de jouer pour de vrai (s'arrêter pour tirer c'est limitant).
Citer : Posté le 30/07/2021 11:13 | #
Wow, je n'y croyais plus trop et hier je réinstalle la nouvelle version et... ça marche !
C'est juste TROP bien !!!!!!
J'ai une erreur de Z_MALOC quelque part, je vais essayer de la reproduire et j'envoie ca !
En tout cas, bravissimo, c'est génial !