Portage de Doom sur carte d'évaluation STM32

Règles du forum
Cette section est dédié a vos projets, descriptions et demandes d'aide.
Merci de limiter le nombre de sujet par projets.
Lorsqu'un sujet deviens long vous pouvez éditer le premier message pour maintenir à jour le descriptif et garder en lisibilité
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 08 janv. 2020, 13:46

Doom !
DOOM !!
DOOOOOOOOOOM !!! :diable:

Je suis fasciné par ce jeu, son gameplay, son histoire, sa technique ... Et il se passe encore plein de choses autour de ce vénérable, culte et révolutionnaire titre sorti en 1993, dont le code source du moteur a été publié en open-source en 1997, et dont la communauté est encore très active. La publication en open-source a ouvert la voie à une multitude d'évolutions et d'expérimentations, allant de la simple adaptation ou amélioration au portage sur à peu près n'importe quoi : calculatrice programmable (les vraies grosses un peu modernes, je ne parle pas des knock-off sur Ti-83+), consoles de salon, distributeur de billets (no joke), tableau de bord de voiture (no joke !!), écran d'imprimante jet d'encre (no joke !!!), oscilloscope numérique (:|), thermostat (wtf ?) barre OLED de MacBook Pro (non mais wtf Doom en 640 x 12 ???) ...
If it exists and has a microprocessor and a screen, it can run Doom !

Mon moi du passé lointain (2 mois, une éternité ...) avait laissé à l'intention de mon moi du passé récent (2 semaines) un onglet ouvert sur le navigateur : https://github.com/floppes/stm32doom
Doom (plus exactement Chocolate Doom) pour carte d'évaluation STM32F429. Carte dont je dispose (qui n'est pas chère d'ailleurs, on la touche à ~$30) ... Ho ho ho ... :D
J'ai testé : ça marche, c'est ... dingue ! Et tellement cool :P

Par contre il y a quelques limitations (le portage a été fait par un mec tout seul en 2015), que je suis bien motivé pour essayer de faire sauter ou contourner:
- Pas de son.
- Pas de musique.
- Contrôles de merde. Le tactile, sur du FPS, comment dire ... Il me semble impératif de faire honneur à ce jeu en permettant d'y jouer avec les contrôleurs recommandés par la PC Gaming Master Race : le clavier et la souris !
- doom1.wad only. L'intégralté du WAD est chargée dans la RAM externe de la carte dévaluation, qui fait 8Mo. De fait, cela limite la taille du WAD à 8Mo, et dans les WAD "courants", il n'y a que celui de l'épisode 1 shareware (doom1.wad donc) qui rentre (il fait ~4Mo).
- Pas de sélection du WAD au démarrage, le nom du WAD à charger est écrit en dur dans le code.

Pour le son, il faut dire qu'il n'y a pas de sortie audio sur cette carte, mais ça peut s'arranger, il suffit de faire du PWM ou du PDM sur une sortie, voire du DAC (les DAC sur les STM32 tournent à 50kHz, pour pouvoir générer du 48kHz). Par contre, il faut faire un driver pour ça. Idem pour la musique, avec une contrainte supplémentaire : la musique est en MIDI, cela va de soi. Ce qui sous-entend qu'il faut interpréter les fichiers MIDI, et surtout synthétiser les sons des instruments :o Là on est pas dans le simple ...

Pour le contrôleur il y a deux approches : ajouter le support clavier souris, ou faire un contrôleur DIY spécifique. Pour le support du clavier / souris, il n'y a qu'un seul port USB (micro) en host sur la carte (et de toutes façons il n'y a qu'un seul USB possible en host sur cette gamme de STM32, que je sache). Donc il faut de toutes façons multiplexer, donc utiliser un HUB. Or, le support des HUB n'est pas natif dans les libs / stack USB "standard". En tous cas pas dans les couches ST, utilisées ici. Certaines stack implémentent le support des HUB, mais la grande majorité sont des libs non-free et payantes. La seule free que j'ai vu c'est emCraft. Je n'ai aucune idée de ce que c'est et de ce que ça vaut. Par contre, après avoir cherché un peu sur les forums, il semblerait qu'ajouter le support des HUBs USB soit loin d'être complexe, et que ça prendrait ~400 lignes de code, ce qui est non-négligeable, mais tout à fait raisonnable.

Pour un contrôleur DIY, je m'inspirerait bien du contrôleur que Roul et 3ds ont fait pour la brodeuse :)
Par contre pour la souris ... je pense qu'il faut une vraie souris.
Pour l'interface, soit on fait un contrôleur USB qu'on multiplexe (cf point précédent) soit on le connecte à des GPIO ou un bus de com du MCU.

Pour la RAM ... Vaste sujet. plusieurs options s'offrent à nous.
- Porter le projet sur une carte qui a plus de RAM (en Discovery yen a pas, même sur les cartes d'évaluation "chères")
- Ajouter une RAM supplémentaire (SPI ?)
- Changer la gestion du chargement des datas

Ce dernier point me semble plus intéressant. Il faut noter que 8Mo de RAM, en 1993 ('back in the days' comme on dit), c'était assez standard dans les PCs. Par contre, Vanilla Doom (et donc Chocolate Doom) sont des sourceports plus récent, dont l'objectif est de reproduire l'expérience de jeu la plus proche de l'original, tout en rendant l'utilisation simple sur les OS récents. Donc, comme beaucoup de sourceports, ils tirent parti des ressources disponibles sur les PCs récents, et entre autre la RAM illimitée (en comparaison de 93). Donc, à mon avis, le fait qu'il charge l'intégralité du WAD dans la RAm est un choix de design du sourceport utilisé, choix fait par commodité pour les PCs desktop, mais contraignant ici, vu que l'on est sur une plateforme donc la quantité de mémoire disponible est similaire aux PCs de 93. Par contre niveau puissance de calcul, on est à 180MHz, looooiiin devant les 486SX33 de l'époque :P et je ne parle pas des temps d'accès, vitesse des bus de com' ... Donc je pense qu'il serait pertinent de charger dynamiquement les datas dans la RAM, pour limiter le taux d'occupation à un instant t. Et je suis persuadé que c'est ce qu'ils font dans le moteur d'origine, donc il va falloir que je checke ça. Par exemple, garder en mémoire l'intégralité des niveaux n'a pas de sens, vu qu'on ne joue que dans un seul niveau à la fois. Donc quand on finit un niveau il faudrait vider les données du niveau qu'on vient de finir, et mettre la place les données du niveau suivant avant de le lancer.

(A noter que le portage sur d'autres cartes peut avoir un autre intérêt : un écran plus grand :) par exemple sur cette carte-ci ou celle-là, qui peuvent aussi bénéficier d'autres périphériques sympathiques, genre un codec audio ...)

Pour aller plus loin sur le sujet des performances mémoire, je me demande comment étaient chargés les assets graphiques et sonores dans le jeu d'origine, et s'il y aurait un intérêt à faire un chargement dynamique là aussi. Pour les sons (sfx), je pense que ça a clairement un intérêt, parce que même s'ils sont à un samplerate assez faible, ça serait bien d'éviter de les avoir en permanence en RAM. Pour les assets graphiques je ne sais pas trop. On pourrait se dire qu'au chargement du niveau on checke quels sont les textures et sprite requises, et qu'on ne charge que celles-là, mais je doute que ça soit vraiment faisable sans modifier radicalement le code d'origine, et je ne suis pas persuadé qu'on gagne tant que ça, car ça suppose que les niveaux utilisent peu d'assets. Et quand à les chager dynamiquement en temps-réel, c'est-à-dire au fur et à mesure qu'on en a besoin pour afficher un frame ... Hum, ça me semble overkill. Mais ptet ça a du sens ? En tous cas ça ferait sauter quasiment toutes les limitations, car on ne chargerait que ce qu'on a besoin pour la frame à afficher en cours (à moins d'avoir un design de niveau qui oblige à afficher plein d'assets en même temps sur la même image, c'est peu probable - quoique avec certains slaughterWADs ...). Bon, là on est dans le suplice des diptères.

Le vrai gros sujet, à mon avis, c'est la musique. Parce qu'on parle quand-même de faire du General MIDI sur un STM32, donc un synthétiseur polyphonique multi-timbral. Ce n'est absolument pas trivial, c'est même un projet à lui tout-seul 8|
Mais ... Ben ça m'intéresse quand-même, parce que la synthèse ça me parle :coeur: Mais c'est vraiment un gros truc.
l'un des sous-sujets qui va avec c'est de savoir si on fait de la synthèse algorithmique (ce qui va demander beaucoup de temps de dev, à moins de trouver des algos déjà-faits) soit on fait des wavetables. Dans le deuxième cas (plus facile à mettre en oeuvre à mon avis), il va falloir stocker les wavetable quelque part, et donc éviter de remplir la RAM avec, donc il y a de l'archi à faire.

Oublions un instant la musique. Si on arrive à faire sauter la limitation sur la taille du WAD, ça voudra dire qu'on pourra charger d'autres fichiers que doom1.wad. De base, Chocolate Doom, comme beaucoup de sourceports, va chercher les IWADs "officiels" connus : Doom shareware, Doom retail, Doom 2, Heretic, FreeDoom ... On pourrait se limiter à ça, mais j'aimerais bien pouvoir charger des WADs custom (yen a quand-même plein de bien qui sont compatibles avec les sourceports vanilla), mais pour ça il faut pouvoir les sélectionner. Par ordre croissant de confort d'utilisation:
- Écrire le nom du fichier dans le code en dur et re-compiler à chaque fois :erk:
- Écrire le nom dans un fichier de config dans la clé USB (c'est comme ça que marchent la plupart des sourceports actuels)
- Faire un explorateur de fichiers
La troisième solution est bien Roxxor mais bien user-friendly, et étonnamment je n'ai pas trouvé d'exemple d'explorateur de fichier "standalone" pour STM32. Alors soit j'ai mal cherché, soit c'est considéré comme inutile ou overkill. En tous cas ça me surprend car il y en a un dans le programme d'exemple qui est chargé d'origine dans la carte. Bon, ben si je me mets sur ce sujet je commencerais par dépiauter cet exemple.

Gros gros gros sujet. J'ai vraiment très envie de bosser dessus. Et j'ai vraiment très pas le temps.
Fuuuuuuu ...

Quelques liens intéressants si le sujet vous intéresse :
https://doomwiki.org/wiki/Entryway
Un tutoriel sur le fonctionnement du moteur
Le blog de Fabien Sanglard, une mine d'or !
https://www.doomworld.com/
Le repo Github de Chocolate Doom
Le repo Github du code Doom tel que publié par John Carmak en 1997. Ses notes sont assez marrantes d'ailleurs.
Avatar de l’utilisateur
Airman
Electrolab::CA
Messages : 349
Enregistré le : 13 oct. 2016, 22:04

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Airman » 09 janv. 2020, 10:11

On va porter Doom sur la brodeuse ?
Ou sur les contrôleurs de domotique ?
:-)
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 09 janv. 2020, 13:16

Pourquoi pas ? :)
F4HTQ
Messages : 76
Enregistré le : 24 janv. 2019, 16:00

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar F4HTQ » 28 janv. 2020, 23:36

Pour la musique, si je me rappelle bien, c'était de la simple synthèse FM qui fonctionnait sur une soundblaster. C'était conçu pour bouffer que dalle en temps de calcul, c'était la même techno que les synthé yamaha du début des années 80.
j'ai trouvé ça : https://bisqwit.iki.fi/source/opl3emu.html

Sinon pour ce qui est de streamer les données graphiques j'y crois pas trop. Il y avait beaucoup de réutilisation des textures, ce n'est pas fait pour être chargé en secteurs. Il ne me semble d'ailleurs qu'il n'y avait pas d'algo de portals et autres logiques PVS qui auraient pu rendre ça possible ( pour déterminer la visibilité c'était un simple algo de BSP en 2D).
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 29 janv. 2020, 13:00

Okay, merci pour ces infos ! :merci:
Effectivement, il y a une lib OPL dans Chocolate Doom. Il faut que je checke ce qu'elle fait exactement, mais ya ptet moyen que ça soit connectable sans trop de douleur au HW. Si à la sortie c'est des échantillons analogiques, ça va être facile à gérer.

Pour le streaming des assets graphiques, oui après réflexion je pense aussi que ça n'est vraiment pas pertinent. Quand on regarde les différences de taille le WAD shareware et le WAD retail, sachant que les assets graphiques sont quasiment les mêmes entre les deux, la seule chose qui change, c'est le nombre de niveaux, donc on peut se douter qu'ils sont prépondérants dans l'encombrement. Donc n'en charger qu'un seul à la fois devrait vraiment permettre d'économiser de la RAM. Bon, ça posera des soucis sur les slaughterWADs "architecturaux" qui ont des niveaux très chargés en géométrie. Genre Sunder, Sunlust, Toilet of the gods, ce genre de trucs. Mais bon, déjà ça sera pas mal de gérer les megaWADs "normaux".

Et, oui, dans le moteur de Doom les niveaux sont gérés avec des BSP, et pré-processés par l'éditeur. Duke Nukem 3D par contre utilisait un système de portals, ce qui permettait de ne pas avoir besoin de pré-process les niveaux. C'est plus gourmand en ressources, mais plus flexible, ce qui permettait entre autres d'avoir un éditeur de niveaux qui affichait en temps-réel le niveau avec le moteur du jeu :P
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 04 mai 2020, 16:04

Hey !

J'ai profité du confinement pour avancer sur ce sujet. Voici le niveau où j'en suis.

Côté support des hubs USB, j'ai regardé quels middlewares supportent la classe HUB, et il faut avouer que ce n'est pas courant. Il y a quelques libs payantes, souvent payantes, et les gratuites sont liées à un OS (Nuttx et EmCraft). Or, il n'y a pas la place de mettre un OS - ce qui est dommage parce que ça s'y prêterait. Donc, pas le choix : il faut le faire à la main.
J'ai trouvé un projet sur Github qui se propose d'implémenter la classe HUB via un bricolage sur le middleware fourni par ST. Je n'ai pas réussi à le faire compiler, et de toutes façons l'implémentation ne m'a pas trop plu. Trop de modifications éparpillées aux quatre coins des couches, il me semble plus sain de restreindre les ajouts à la classe. C'est un peu illusoire vu qu'il y a tout de même une grosse modification d'architecture - les couches d'origine sont conçues pour un seul device - mais j'ai tenté le coup quand-même.

J'ai donc repris les couches de middleware "vanilla" fournies par ST, pour y ajouter la classe HUB, en me basant sur le code du projet sus-linké. J'ai acheté un petit hub à trois franc six sous à Boulanger, et j'ai bien avancé, j'arrive à le détecter, identifier que c'est un hub, charger la classe correspondante, et quand je connecte une clé USB dessus, il détecte un device et le transmet au MCU. Par contre, j'avais un problème d'énumération à partir de là, c'est le hub qui répondait visiblement, pas la clé. Et si je branche une souris il ne la détecte pas du tout. J'ai passé plusieurs jours à bricoler pour essayer de comprendre l'origine du problème, sans succès. Puis j'ai eu la présence d'esprit de tester si le hub fonctionnait correctement, je l'ai donc branché sur mon PC sous Windows. Et là patatras ! Windows voit un device mais ne le reconnait pas et me met une erreur, et il ne voit même pas le device que je branche dessus. Je pense donc soit qu'en fait c'est de la daube, soit que je l'ai brické en faisant une fausse manip, deux options tout autant probables l'une que l'autre.

Grmpf ... Je m'achèterai un autre hub plus tard, et je le testerai *avant* de faire des manips avec. En tous cas, ça me force à comprendre comment marche l'USB, et c'est pas plus mal.

Pour le chargement partiel, j'ai fait quelques stats sur les WADs "courants", pour voir combien j'avais besoin de RAM "en vrai" si je ne charge que les données communes et celles relatives à un seul niveau (donc géométrie + musique). Et là, mauvaise surprise, je ne gagne pas tant que ça, et dans al RAM de 8Mo il n'y a que le Doom retail et Heretic qui bénéficient suffisamment de ce traitement pour que ça passe :pleur4: Bon, c'est pas si nul que ça, mais quand-même. J'ai fait un script Python que j'ai passé sur une dizaine de IWADs / PWADs pour voir un peu les ordres de grandeur, et tous requierent entre 8Mo et 16Mo de RAM. Donc j'ai plusieurs options, soit j'arrête là, soit j'upgrade la carte avec une puce de RAM de 16Mo (ça existe, c'est dispo et c'est pas cher, mais c'est en TSOP44 et ça fait un truc beaucoup moins reproductible, du coup), soit je regarde ce que je peux éviter de charger comme textures qui ne soient pas dans les niveaux. Sachant qu'il n'y a rien de garanti, vu que ce sont les mappers qui choisissent quelles textures ils utilisent et qu'il n'y a pas de limite intrinsèque au moteur sur le nombre de textures utilisables dans un seul niveau. Je vais modifier mon script Python de parsing de WAD pour calculer le poids en textures de chaque niveau, pour voir ce que je peux gagner en faisant ça. Je n'y crois pas trop, mais ça m'incite à comprendre comment les données sont codées dans les WADs, donc je pense c'est utile, ne serait-ce que pour ma culture personnelle :)

Côté son, j'ai trouvé les fonctions qui vont envoyer les samples vers la carte son, il faut donc que j'intercale un driver qui génère du PWD / PWM, je pense que faire un truc à base de DMA sera plus simple pour avoir un sample rate bien propre et bien fixe. Pas encore avancé concrètement sur ce sujet.

Côté musique, je n'ai pas trouvé de solution évidente, et je pense que je vais séparer ce sujet pour en faire un projet séparé sur une carte dédiée. Dans tous les cas le plus simple me semble de faire un convertisseur MUS -> MIDI, et un expander SW derrière. Je n'ai pas encore regardé dans le détail, il faut que je farfouine dans le code de Timidity, Mame, et les synthés FM sur STM32 qu'on trouve sur Github (il y en a quelques uns).

Voilà voilà. Je prépare les articles détaillés sur mon blog, mais j'attends d'avoir des résultats un peu plus concrets avant de publier.
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 20 nov. 2020, 11:38

Petit update de mon état d'avancement.

Je me suis lancé bille en tête sur l'intégration du support des hubs USB dans les couches ST, et ça ne se passe pas très bien. J'ai réussi à bricoler avec les projets que j'ai trouvé sur Github autour de ça, et j'arrive à énumérer un hub, détecter des devices dessus, mais l'énumération des device connectées sur le hub se passe mal. Dans le détail : les requêtes de lecture de descripteurs de configuration sur une souris me renvoient un nombre insuffisant d'octets, qui ne correspond pas à ce qui est demandé dans la requête, alors que la souris en direct renvoie bien le bon nombre d'octets, et je n'arrive pas à l'expliquer. Je commence à douter d'arriver à aboutir sur ce sujet, et j'ai bien envie de changer mon fusil d'épaule pour ne pas m'embourber. Je vais tâcher de ne pas laisser ce mystère irrésolu, mais je vais surtout travailler à d'autres moyens d'ajouter des contrôles dignes de Doom, et d'avancer parce que là c'est trop frustrant.

Plusieurs possibilités:
* Contrôleur custom à base de joystick indus' + touches de clavier Cherry, mais pour Doom le joystick c'est bof bof ... Mais ça serait marrant quand-même, donc je vais le faire, au moins pour le fun. Et qui sait ? Si je décide un jour de travailler sur d'autres portages de jeux plus adaptés au joystick, ça serait top :)
* Pour la souris, bricoler une souris pour chopper des signaux I²C ou SPI en direct, mais les souris récentes utilisent de plus en plus des circuits tout intégrés qui incluent le capteur et sortent direct en USB, donc ça va dépendre de ce que j'arrive à chopper comme souris.
* Récupérer une souris PS/2, le PS/2 est assez facile à décoder / gérer vu que c'est proche d'une SPI.
* Faire un convertisseur USB HID vers UART / SPI avec une autre carte, et entrer en UART / SPI sur la carte principale.
Je n'ai pas encore décidé ce que j'allais faire exactement, tout dépend entre autres de ce que j'arrive à trouver comme "vieille" souris. Dans tous les cas, je ne pense pas utiliser un "vrai" clavier USB ou PS/2, je vais faire un contrôleur custom, ya que la souris que vraiment je ne vois pas comment je peux la remplacer.

Pour la partie contrôleur custom, je vais partir sur des contacteurs Cherry, on peut en acheter chez Farnell :) Bon, ya un seul des nombreux modèles qui existent, mais on fera avec. Pour le joystick j'ai jeté mon dévolu sur un petit joystick industriel APEM à base de potentiomètres, qui est vraiment beaucoup trop cher pour ce que c'est, mais bon ... J'assume. S'il fallait en refaire d'autres, je pense qu'il ne faudrait pas hésiter à aller chercher des équivalent moins chers chez d'autres distributeurs moins "indus" pour éviter de payer des sommes folles, parce que là ça devient déraisonnable :-/ Je vais donc commencer à travailler sur l'ajout des mesures analogiques pour gérer le joystick. On va bien voir ce que ça done.

A terme je compte bien faire une borne d'arcade "PC gaming master race" avec Doom dessus :diable:
"No cheat, no save, start Doom, select ultra-violence difficulty and slay some hellspawns !" 8|
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 14 déc. 2020, 12:53

Bien bien bien, point d'avancement.

J'étais parti la fleur au fusil pour bricoler le code de stm32doom, et je n'ai pas réussi à le lancer en debug :( Ce qui est un no-go si je veux faire du dev dessus. N'ayant pas réussi à contourner ce problème, je suis parti dans une ré-implémentation, pour utiliser les libs HAL ST, qui sont pourries, certes, mais qui ont l'avantage d'avoir un semblant de documentation, d'être documentées et commentées en anglais (et pas en allemand comme les libs de stm32doom), et de s'intégrer correctement dans CubeIDE, qui est quand-même vraiment plus pratique pour le debug. Objectif : arriver au même niveau que stm32doom (lancer Doom dans le même état) mais en utilisant les libs ST, et dans un projet CubeIDE qui débugue.

J'ai vraiment passé énormément de temps là-dessus, problèmes avec le FatFS, problèmes avec l'allocation mémoire dans le SDRAM et script de link, galères (pas encore finies) avec les routines d'affichage du LCD ... Mais j'approche d'un prototype fonctionnel. Je n'ai pas encore publié l'article épisode 2 qui parle de ça, car j'attends de corriger mes derniers problèmes, mais j'arrive à lancer Doom en débug :ghee:

Donc ... Ça avance, lentement mais ça avance. Et je comprend de mieux en mieux comment utiliser ces cartes compliquées avec de la RAM et des afficheurs. Et avoir ce projet fonctionnel devrait ma permettre de faire plus facilement un portage sur une autre carte, pour disposer d'un écran plus grand, parce qu'il est très petit quand-même sur l'actuelle.

Par ailleurs j'ai acheté des switch Cherry pour le clavier et le petit joystick - qui est vraiment petit - et j'ai récupéré de la vieille souris PS/2 au rebus du taf, donc je pourrai attaquer l'intégration des contrôles, une fois que j'aurais définitivement déverminé les routines d'affichages et que je n'aurais plus de trap quand j'appuie sur le bouton user.

Mon objectif à moyen-terme est de contacter Fabien Sanglard quand j'aurais un proto qui a un peu de la gueule, pour voir si il serait chaud pour faire ou participer à une conf' sur BBB sur Doom ou sur des sujets connexes jeu vidéo / développement, comme il est francophone, ça serait pas mal. Mais là je tire des plans sur la comète de teeeeellement loin ...

Stay tuned ...
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1358
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Portage de Doom sur carte d'évaluation STM32

Messagepar Flax » 02 août 2022, 22:53

Hey,

Je relis mes messages précédents, j'étais motivé à l'époque dites-donc. EN fait à un moment ça m'a saoulé et j'ai abandonné, ça me bouffait trop de temps de me battre avec l'USB, et j'avais l'impression que j'avais un souci sur le rendu graphique en passant du projet d'origine avec des libs custom à un projet pour STM32CubeIDE. Donc je n'y ai quasiment pas touché depuis le message précédent.

Mais il y a eu du nouveau entre-temps : quelqu'un s'est attelé à faire un portage basé sur les libs ST, et sur un projet CubeIDE, ce qui est tout de suite vachement plus facile à manipuler que le projet de floppes. Ca se trouve ici sur Github, ça fonctionne un peu comme le projet de floppes, avec les contrôles sur l'écran, donc c'est injouable, mais étant donné que la partie chiante de conversion en projet Cube est faite, ça va peut-être me re-motiver à mettre le nez dedans :) En attendant, je partage cette trouvaille. C'est basé non pas sur Chocolate Doom mais sur un autre projet qui s'appelle genericDoom et qui vise à réduire au maximum les éléments à modifier pour faire le portage de Doom sur une nouvelle plateforme, et visiblement il est pas mal utilisé dans les challenges "does it run Doom ?". Maintenant, il y a toujours les mêmes problèmes qu'avec le STM32DOOM de floppes : pas de support clavier souris, pas de son.

Autre trouvaille, qui prouve qu'il y en a des beaucoup plus énervés que moi, ces gens ont porté Doom sur un dongle USB-BT acheté 13€ sur mamazon ... Bon, ya sûrement 50€ d'accessoires à côté (écran, clavier custom ...) mais le tour de force est intéressant. Ce qui est aussi intéressant c'est qu'ils ont fait une analyse ultra-poussée des optimisations possibles en s'adaptant au plus près du hardware et en exploitant au max chaque bout de mémoire sur la puce. C'est un peu ce que je voulais faire avant de réaliser à quel point c'était compliqué et pas gratifiant, bon ben eux ils ont fait encore plus pointu, et ils l'ont fait en vrai. Stupéfiant. Et ils ont aussi implémenté la gestion du son, ce qui manque sur les autres projets du même type.

Bref : Doom forever !

Retourner vers « Les Projets »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité