R-type II et émulateurs
15 sujets de 1 à 15 (sur un total de 18)
- 1
- 2
-
En échangeant sur un autre fil de discussion au sujet des performances des machines reproduisant le fonctionnement d’un Amiga, je me suis décidé de vous questionner sur le sujet suivant:
Savez-vous pourquoi R-Type II rame comme un malade sur UAE dés que la configuration de la machine hôte n’est pas bien costaud?
Par exemple, un RPI 2 n’est pas suffisant pour ce jeu alors qu’il est largement suffisant pour plein de jeux assez gourmands. Je me demande même si un PI 3 est capable de l’émuler proprement.
En général, ça rame à fond dés qu’on quitte la vague d’ennemis rouges dés le début du jeu et qu’on rentre dans le décore aux tons beige.
Je me demande bien quelle partie du code de ce jeu fonctionne si bien sur un simple A500 de base et rame du cul sur un émulateur.
RyZen Rulez 😉
Question que j’avais abordé à l’époque avec un des DEV sur la Rpi des portage comme UAE.
Il faut bien comprendre plusieurs choses :
– Les RPI and co ne sont pas machines destinée à donner de la puissance.
– Une émulation correcte demande beaucoup de ressource machine.
– Ce que tu trouves sur RPI and co ne sont ‘que’ des portages, pas le code sources.
– Rare quand il sont optimisé pour le Hardware en question (donc pour la RPI)Si tu bricoles un peux linux, lance donc ton émulateur sur RPI2 ou 3 et regarde un peut comment se comporte l’OS (consommation mémoire sur chaque process, utilisation des procs, etc…)
Tu risques d’être surpris et pas dans le bon sens.Alors ensuite pourquoi plus sur des jeux comme R-type, là je te dirais que c’est sans doute a cause du code de R-type qui n’est pas optimisé et qui fonctionne correctement sur un vrai Amiga mais qui consomme trop de ressource sur un Emulateur.
Et encore plus sur une version ‘porté’ et sur un hardware ‘limité’ comme les RPI.
est-ce que des jeux équivalents à rtype-2 rament autant, ou bien c’est spécifique à ce dernier ?
Si c’est spécifique, il utilise surement intensivement une technique difficile à émuler sur une machine peu puissante. Sinon, eh bien c’est l’émulation des coprocs de l’amiga qui posent problème aux petites machines 🙂
Avec un copper capable d’une précision de 4 pixels sur le balayage pour réaliser un MOV, je ne serais pas étonné que cela mette à genoux les petites configs.
(pas de problèmes avec mon core i5 qui va sur ses 8 ans, mais ça n’a rien à voir avec un rasp qui est plus sur des technos d’il y a 20 ans).
Le rasp n’a pas de techno de 20 ans…
Juste que comme a dit giants, le code de l’emulateur est un code non optimise.
Il peut fonctionner correctement sur plusieurs jeux, et planter sur certains. R-Type affiche pas mal de sprites en meme temps…Le rasp peut decoder des mkv sans sourciller alors qu’un ordi de 20 ans ne les decoderais meme pas (toute machine intel avant le socket 775, et meme les cpu non core 775). idem sur amd avec tout ce qui est post amd64 (genre socket 462…)
Ce qui fait qu’un amiga n’est pas aussi evdent que ca a emuler, c’est qu’il a des coprocesseurs. Donc on emule plus d’un truc sur amiga, alors que sur st, ben on emule un 68000 et c’est quasiment fait :p
Personne n’a jamais dit que le raspberry pi etait l’amiga ultime pour jouer. Il ’emule mieux le workbench 🙂
Amuses toi bien.
PS : si r-type amiga rame, essaie la version arcade, qui si cela se trouve sera bien mieux emulee, et plus jolie. Ou les versions PC-Engine (qui gereront 2 boutons)
Amiga + CPC + PC = La meme passion !
C’est pas si simple, il n’y a pas ‘un seul’ fautif.
D’un coté tu as un jeu qui à du code pas optimisé : Le jeu lag sur un Amiga à certain passage.
Et de l’autre on a on hardware qui n’est pas ‘performant’.
Un code d’émulation pas adapté à l’hardware en question.
Un portage du code original et non le code original.Autant sur un PC puissant tout cela est comblé par la puissance du proc (et de plus on aura le code original pas un portage)
Autant sur une Rpi c’est ce genre de détail qui va plomber l’émulation.Je le répétè mais, à la base les cartes ARM de type RPI n’ont pas été prévu pour l’émulation, loin de la.
Coder un emulateur d’ordinateur (et pas uniquement d’un proc, ex le 68000) c’est la misère.
Si on veut faire quelque chose de performant il faut maitriser l’hardware source et l’hardware où l’on code.
Connaitre chaque composant et l’intrication qu’ils ont entre eux.Faut pas croire mais derrière WinUAE c’est du code de fou.
En fait pour moi la question initial est une non-question.
On ne peut pas faire de chose performante en état avec la RPI, comprendre il y a peut d’outils qui sont codé pour utiliser la RPI.
On est a quoi, 95% de portage au niveau émulation sur la Rpi ? Quelque chose comme ça.De plus, si tu regardes la RPI2 ou 3, rien de bien exceptionnel non plus niveau proc.
Pas de grosse fréquence, ce n’est pas une structure de monstre comme l’on trouve sur les proc Intel Core I5, I7 …
Et c’est normal, ce n’est pas des cartes faites pour ça.
C’est un compromis entre prix et puissance sur autour d’une structure ARM.Pourquoi les codeurs ne sont pas plus intéressés à coder directement sur la RPI ?
à la vitesse où évolue les cartes (on en est à la RPI3) et le temps que prendrais a coder from scratch un emulateur, ça serait du temps perdu.
Même en pissant du code à gogo, on arriverait jamais à avoir quelque chose de nickel AVANT qu’un nouveau modèle de carte sorte et rende notre travail ‘dépassé’.Concernant la question sur R-type, si vraiment on voudrait répondre ‘exactement’ à la question il faudrait analyser COMPLÉTEMENT le code de R-type (bonne chance) ainsi que le code source de UAE sur RPI et comprendre qu’elle partie prends plus de ressource que d’autre.
Je pense que ca serait le travail d’une vie et… honnêtement pas super intéressant au final. @ modulo : c’est un problème spécifique à R-type II.
Le soucis n’est pas spécifique à l’émulation sur RPI. Les premiers UAE sur MorphOS et Amiga OS4 avaient le même soucis. Mes premières émulations de R-Type II sur mon vieux PC AMD de 2000 avait ce même problème.
Le souci vient clairement du code qui exploite le hardware de manière extrême. Je le souviens même que R-Type II en disquette originale boguait sur A1200 exactement au même moment de rentrer dans ce décore beige comme il rame sur UAE.
J’avais l’espoir de tomber sur un connaisseur qui aurait l’explication.
Modulo pointe l’utilisation intensive du copper et ça semble très probable que le scrolling du fond soit ainsi conçu. C’est une première piste très intéressante.
@ thor1230: l’idee d’utiliser la version arcade est bonne puisque R-Type II sur MAME sur des petites configurations ca fonctionne très bien, néanmoins, j’aurais aimé comprendre ce qui se passe sur l’amiga.
RyZen Rulez 😉
Comprends pas…. Si tu penses avoir la réponse, pourquoi poser la question tel qu’elle ? Ou tu l’a mal poser.
Perso je persiste sur l’idée que ‘ce n’est pas si simple’ et qu’il n’y a pas qu’un fautif.
Après… Tu crois ce que tu veux 😉
Mais à moins de desassembler tout ca, je ne vois pas comment en être sur. @serge: Le copper est surement une plaie à émuler, car lors de la composition du buffer il faut relancer les routines du compositeur tous les ‘n’ pixels.
Mes connaissances du hardware de l’amiga sont très limitées, mais il me semble que le cas extrème serait de 4 pixels, en monochrome cependant (un seul playfield).
il serait intéressant de pouvoir chronométrer l’usage des des différents elements avec un raster. Par exemple: copper change le fond en rouge, blitter en vert, cpu en bleu.
Avec cette simple mesure, nous pourrions au moins vérifier l’endroit où l’émulateur passe tout son temps. Je penche pour une copperlist bien fournie.j’ai fait une recherche avec fs-uae que j’utilise , étant sous linux, mais ça n’a pas l’air possible. Si quelqu’un sait comment s’y prendre…
Quelle est la base du UAE fournit avec ta distrib rasp ?
fs-uae et winuae sont écrits en c++ (en fait du C, avec des fichiers qui ont l’extension C++ 🙂 ). Ils possèdent un JIT, mais uniquement x86. On peut désactiver le jit lors de la compilation, ce qui permet le portage de fs-uae vers des plateformes non x86. On peut aussi désactiver le jit à l’exécution, mais ça ne compilera surement pas sur du non x86.
Il y a une version d’UAE avec un jit ARM: https://github.com/Chips-fr/uae4arm-rpi/tree/master/src/jit
Donc le paquet s’appelle surement uae4arm. Si c’est celui que tu utilises , as-tu le jit actif dans la config ? Par défaut ce n’est pas activé dans fs-uae (tu m’excuseras si je dis ds trucs qui te paraissent évidents, mais je ne sais pas ce que tu as essayé et configuré).
Ou les gars vous mettez le doigts dans quelque chose qui va vous bouffer tout votre temps.
Mais j’aime, j’aime ce genre de chose 🙂Si tu réussi à brancher modulo dessus, ça va vite devenir intéressant cette histoire.
Clair, ca lag pas mal.
@ Leo, je parle du premier niveau dès qu’on quitte l’espace avec les deux vagues d’ennemies rouges et qu’on rentre dans la structure artificielle aux tons beige.
C’est de toute évidence le fond qui fait cet effet.
Je rappelle que le jeu original, non patché par WHDLOAD plante sur les amiga AGA en arrivant à cet endroit, comme si ce plantage pour l’AGA se traduisait par un ralentissement monstrueux dans les emulateurs.
La version WHDLOAD a été patchée et ne provoque plus ce plantage sur A1200 mais continue à ralentir drastiquement les emulateurs.
A modulo, j’ai utilisé plein d’emulateurs, que ce soit WINUAE, UAE sur amigaOS4, sur MorphOS, même fellow si les souvenirs sont bons avait ce problème.
Actuellement, sur le rasp c’est l’emulateur présent dans recalbox. Il me semble que c’est Amibery
RyZen Rulez 😉
concernant l utilisation du copper sur R-Type 2 => http://codetapper.com/amiga/sprite-tricks/r-type-2/
15 sujets de 1 à 15 (sur un total de 18)
- 1
- 2
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Émulation et autres OS › R-type II et émulateurs
