mame2010 tests on pi3

[voljega]

@gkralicek2 du coup t'as pas réussi gaiapolis et monster maulers non plus ? en plus il me semble que gaiapolis fonctionnait auparavant sous fba (peut me tromper)

[gkralicek2]

@voljega Non rien de rien avec Gaiapolis et Monster Maulers. Même en plaçant le bios konamigx, les jeux ne se lancent pas. Idem avec la version plus ancienne .30 et .32 de FBA :=((. Par contre, j'ai testé avec MAME et çà fonctionne sans souci.

[voljega]

@gkralicek2 ok, bon ben c'est dommage, je pensais pas (idéalement :D) qu'il y avait de différences de compatibilité entre une même version de fba_libretro x86 et arm

[gkralicek2]

@voljega Je pense qu'il y a toujours un risque d'incompatibilité à certains niveaux quand on fait un portage d'appli d'une infra à l'autre. Il n'y a qu'à voir ce que çà donne pour les jeux vidéos lorsqu'on part d'une version développée et optimisée pour une plate-forme donnée et qu'on tente d'en effectuer un portage sur d'autres supports, le résultat et la compatibilité ne sont pas toujours au rendez-vous :=(
Après je pense que @barbudreadmon pourra nous renseigner plus en profondeur sur le portage ARM de FBA-Libretro puisqu'il connaît quand même très bien le sujet

[barbudreadmon]

@gkralicek2 @voljega

"There is no support for MIDWAY hardware in this port", c'est indiqué sur le github de libretro-fbalpha (https://github.com/libretro/fbalpha), plusieurs raisons à celà :

1. le code est écrit en c++11, ce qui pose des soucis avec certaines plateformes supportées par retroarch/libretro
2. Le code semble de toute façon avoir été écrit pour fonctionner uniquement sur du x86_64, malgré tout je n'ai pas réussi à faire fonctionner ces jeux sur mon x86_64 (neige à l'écran, le son c'est pire)
3. Le support est toujours considéré en beta et comporte également des bugs sur fba standalone (je crois notamment qu'il n'y a pas de son, et je pense que c'est ce qui cause le 2.), de plus le développeur qui avait commencé à implémenter le support est inactif je crois.
4. Le hardware est gourmand (et c'est d'ailleurs pour çà que du code spécifique à x86_64 a été utilisé), même en réglant tout les problèmes il ne tournera pas sur un rpi3 (même le b+)

Pour toutes ces raisons, j'ai préféré retirer purement et simplement le support plutôt qu'investir du temps pour au final avoir un résultat décevant.

Gaiapolis et Monster Maulers se lancent très bien chez moi (après un écran d'initialisation de la borne un peu long), par contre gaiapolis semble un peu trop lourd pour mon rpi3 (comme Martial Champion du même driver, qui n'est pas konami GX d'ailleurs : http://www.system16.com/hardware.php?id=573). Erreur de romset ? Après je n'exclu pas un bug dû à une spécificité de recalbox, vu les commentaires dans le code le driver semble être à la limite de la beta sur fba.

[voljega]

@barbudreadmon j'ai vérifié le romset avec clrmamepro et @gkralicek2 a la même erreur... donc l'explication de ta dernière ligne est plus probable.

et les deux Hunchback, Choplifter et Tournament Arkanoid ?

[barbudreadmon]

@voljega said in mame2010 tests on pi3:

et les deux Hunchback, Choplifter et Tournament Arkanoid ?

Pour les 2 premiers, on est typiquement dans le cas que j'ai évoqué à plusieurs reprises (parent ne fonctionne pas, il faut utiliser les clones). Arkatour semble en effet avoir un soucis, je vais checker la version standalone ce week-end et rapporté le bug si il est présent aussi.

[voljega]

@barbudreadmon ok merci

[voljega]

@barbudreadmon ceci dit a priori Choplifter et les deux Hunchback marchent tous les trois en rom parent sous mame2010 dont le romset est a priori bien plus ancien ?

[gkralicek2]

@voljega Voilà, j'ai testé à mon tour les jeux qui te posaient problème sous Mame 2010 et j'ai exactement les même résultats à quelques détails près. Le problème de Lag sous Outrun se retrouve également avec Moonwalker (pas pendant le jeu mais durant les phases de transition entre deux niveaux, là le framerate passe de 60 à 45 fps et le son crachote). Egalement chuintement dans les aigus sur Space Harrier (le son est plus propre avec Mame 2003 sur ce jeu). J'ai la vague impression que le support Sega System 16/18 sous MAME2010 est plus gourmand en ressources et met un peu le pi à genoux.
Par contre mes contrôles fonctionnent sur Hydra hydra d'Atari et sur Smash TV de Williams à la condition que j'utilise un pad avec des sticks analogiques (le pad bluetooth de la PS3 fonctionne très bien). Si j'utilise un pad filaire USB de base type SNES, cela ne fonctionne pas et rien ne bouge à l'écran en utilisant la croix directionnelle (par contre les boutons, eux, fonctionnent). J'ai le même souci avec Arkanoïd lorsque je le lance sur FBA, la raquette ne bouge que lorsque j'utilise un pad avec stick analogue.

[voljega]

@gkralicek2 hmmm bizarre je teste généralemen les deux, et justement pour moi le premier Arkanoid de mémoire marche au pad sur FBA mais pas le deuxième

[gkralicek2]

@voljega yes bizarre tout çà. Après, il faut avouer que j'ai quand même pas mal bricolé au niveau des confs manettes au fil du temps et des essais? De ce côté là je ne suis pas du tout en réglage par défaut au sortir d'une install toute fraîche. Ca doit jouer aussi

[barbudreadmon]

@voljega said in mame2010 tests on pi3:

ceci dit a priori Choplifter et les deux Hunchback marchent tous les trois en rom parent sous mame2010 dont le romset est a priori bien plus ancien ?

Tu veux dire le driver ? J'imagine que les parents ont des protections qui ne sont pas correctement émulées par fba.

Concernant arkanoid :

• Je confirme que Tournament Arkanoid ne fonctionne pas sur fba, j'ai signalé le bug.
• Les bornes d'arcade arkanoid étaient toutes en contrôle analogique (un spinner pour être plus précis), c'est pareil sur fba mais vous pouvez utiliser l'option dans "Quick Menu > Controls" qui mappe le stick analogique gauche sur le d-pad, même si çà n'a aucun intérêt (car injouable de mémoire)

[voljega]

@barbudreadmon sous mame ça marche pas mal le mappage sur le pad, mais en l'absence de réglage de sensibilité, ça dépend des jeux...

[voljega]

@gkralicek2 @barbudreadmon

Bon sinon j'ai quelques questions pour les jeux verticaux que ce soit sous mame ou fba_libretro :

• beaucoup ne prennent pas toute la place en hauteur, parfois jusqu'à ne prendre que la moitié de celle-ci
• pour l'immense majorité des jeux verticaux, le rendu des scanlines est vraiment immonde, elles ne sont pas uniformément disposées du tout

Y a t'il quoi que ce soit de faisable pour résoudre ces deux problèmes ? déjà essayé de supprimer l'intergerscale mais ça ne change rien

[gkralicek2]

@voljega Pour un écran horizontal, les scanlines n'ont un rendu correct que si la résolution verticale d'affichage (ou le viewport) est un multiple entier de la résolution verticale d'origine (ce dont se charge l'integer scale normalement).
Par exemple si je veux afficher un jeu comme pacman sur un écran horizontal avec des scanlines parfaites (réso originale 224 * 288), il me faut un viewport avec une résolution verticale multiple de 288. Si mon écran est un LCD 5/4 avec une réso en cours de jeu de 1280 x 1024 alors mon viewport doit avoir une réso verticale de 864 (288 * 3) pour conserver les scanlines dans toute leur régularité. Le hic, c'est que dans ce cas l'écran n'est pas rempli complètement dans le sens de la hauteur (je n'utilise que 864 pixels sur les 1024 affichés par l'écran). C'est le prix à payer pour conserver un affichage "scanlines perfect".
Pour un jeu comme donkey kong par contre (réso origine 256 x 224), la totalité de l'écran sera rempli en vertical car 1024 est un multiple entier de 256 (256 x 4) et on aura de belles scanlines avec un affichage sur la totalité de la surface verticale.
Après si l'on veut à tout prix que l'affichage occupe l'intégralité de la hauteur de l'écran dans tous les cas de figure, on peut activer le lissage de pixel (bilinear filter) pour minimiser l'irrégularité des scanlines en contrepartie d'un léger floutage des contours (mais perso je ne trouve pas le résultat très satisfaisant)

[voljega]

@gkralicek2 ok mais là non seulement l'écran n'est pas rempli en hauteur mais les scanlines sont aussi foirées en même temps

[gkralicek2]

@voljega Ah ben là ce n'est pas normal du tout :=((... Tu utilises les scanlines "de base" intégrés à recalbox ou un autre shader ?

Après, il faut se dire une chose c'est que les shaders scanlines utilisent souvent un "shadow mask" (grille de calage des scanlines) optimisé pour les jeux horizontaux ce qui provoque un "rainbow effect" (sorte de moirage coloré entre les lignes) lorsqu'on les applique sur les jeux verticaux. Il y a quelques shaders (comme CRT-Pi que je trouve plutôt convaincant au niveau du rendu) qui disposent d'une version à base de "shadow mask" vertical permettant un rendu quasi-impeccable sur les jeux verticaux.

[voljega]

@gkralicek2 oui j'utilise juste le paramétrage 'retro'

[gkralicek2]

@voljega Essaye le shader CRT-Pi (tu peux passer d'un shader à l'autre en utilisant la combinaison de touches Hotkey + R3 lorsqu'un jeu sous retroarch est lancé) en désactivant le lissage et en activant le integer scale et dis-moi si le résultat est bon . Si OK alors c'est le shader selectionné par le mode retro qui ne convient pas aux jeux verticaux, si pas ok alors il faudra voir d'autres réglages