Ah, houlà ! ouais ça m'étonnerait que Groovy existe encore pour XP, en tt cas pas des version à jour, cet OS n'est plus supporté par grand monde dans le monde de l'émulation AFAIK.
Officiellement Groovy en effet c'est destiné à W7/10/11 et Linux/GroovyArcade.
Concernant l'intégration à des trucs préconfigurés comme Crossbox et compagnie je ne me prononcerais pas parce que je n'en suis pas familier, mais vu les échos sur le forum byoac c'est parfois galère de mettre à jour ouais.
Les mamecabs avec Groovy n'aiment pas toujours les frontends et le très vieux hardware peut avoir été rendu incompatible avec les versions récentes des Groovy.
Tiens je vais poster un pâté sur le sujet Groovy, ça faisait longtemps que je n'avais pas noirci le forum
Comme Groovy est basé sur le MAME officiel il supporte la même liste de jeux. Après il y a les builds persos avec quelques petits hacks et jeux ajoutés comme en effet celui de b4nd1t0 (attention il y a aussi des modifs de résolution pour la neogeo et qqes autres, on aime ou pas...)
Je crois que pas mal de gens compilent leur propre Groovy. *
Les caractéristiques officielles de Groovy c'est toujours :
_résolutions originales (pour CRT) et framerates originaux (pour CRT
et certains LCD 'normaux' qui officieusement peuvent faire du VRR made-in-Groovy)
_avec réduction du lag 'lossless'
_avec synchro sans tearing
_avec réduction du lag audio en simultané avec les autres features
_integer scaling customizable au détail pour ceux que ça intéresse
_sauvegarde des sliders overclock CPU% (pour cv1k principalement) et géométrie CRT (position, largeur)
_puis tt un ensemble de trucs genre support jusqu'à 4 moniteurs à configs différentes etc
Il faut toujours une carte AMD pour Emudrivers...
_cela dit la nouvelle fonction
allow_hw_refresh combinée à 'monitor : lcd' et 'lcd_range' est intéressante pour les écrans plats ; elle permet d'obtenir le même résultat qu'avec Emudrivers, mais plus besoin d'installation, on utilise les drivers AMD officiels, ça marche surtout sur des moniteurs PC (oui oui, en gros c'est ça le "VRR maison" made in Groovy) et la config est
automatique !
Si vous n'avez pas une thune pour vous offrir un équipement FreeSync ça vaut la peine d'essayer sur votre vieux moniteur lcd, mais pas trop d'enthousiasme car peu sont compatibles avec cette fonction.
Pour moi ça a marché en partie sur un vieux lcd 4:3 de 2007 (nickel de 50Hz à 60Hz) et complètement (50Hz à 75Hz) sur un lcd 16:9 basique de 2014~2015.
Aucun des deux moniteurs n'est FreeSync ni Gsync et pourtant ça marche.
NB: ce truc est expérimental et beaucoup plus limité avec les CRT.
Voilà, même si je ne joue plus que rarement j'adore Groovy : presque toujours à jour, techniquement le meilleur MAME sur CRT
et LCD, fidèle aux pcb autant que MAME le permet et au delà, tant que Calamity continuera à le développer et que MAMEdev ne casseront pas trop de trucs de leur côté (il y a continuellement des progrès dans MAME officiel bien sûr, mais aussi des régressions et changements qui ont tendance à me taper sur les nerfs, je sais pas vous mais des jeux ou des features qui
une fois marchent, une fois marchent pas, à la longue ça me gonfle le teston)
Je kiffe le 'VRR maison' made in Groovy et sa réduction du lag est 'lossless' en ça qu'elle permet de réduire le lag dû à l'input et à la synchro vidéo, mais ne touche pas au lag propre au jeu lui-même comme il est sur pcb (contrairement à run ahead dans RA en mode 'feuque the police' qui élimine le lag naturel du jeu en priorité, sans forcément s'occuper du reste proprement, bref c'est brouillon, gâche la fidélité de l'émulation, et en pratique peut permettre au joueur de tricher en jouant avec moins de lag que les pcb. Avant j'aimais bien RA mais depuis j'ai changé d'avis. Les shaders sont toujours au top cela dit mais c'est à peu près son seul avantage)
Et je kiffe les sliders qui sauvegardent vos réglages essentiels (frame_delay, vsync_offset, CPU% et aussi sur CRT position et largeur)
Par contre, ouais, avec Groovy sur écrans plats pas de jolis shaders dernier cri, il n'y a que le vieux HLSL de mémé (
oui on ne doit surtout pas utiliser BGFX avec Groovy, ça désactive tous les avantages, donc par défaut Groovy est en D3D9ex et il ne faut pas changer ça, on laisse 'video' sur 'auto')
Je m'y suis habitué et j'ai des réglages HLSL satisfaisants aujourd'hui, mais ça n'égale pas un CRT Royale hein...
Pour les Cave cv1k donc, et pour en revenir au topic principal, on a tout intérêt à passer à
0.256 quel que soit le build MAME, puisqu'il intègre la version la plus à jour du driver avec la contribution de '
buffi' qui émule les ralentissements des pcb CV1000 plus fidèlement.
Exit le 'blitter delay' qui ne sert plus à rien.
On a encore besoin d'ajuster l'overclock CPU% (activer 'cheat' dans mame.ini à 'core misc options' pour faire apparaître ce slider)
et autant que je sache pour le moment il n'y a que Groovy qui sauvegarde ce réglage d'overclock CPU tout en ayant ce driver cv1k à jour.
Ne me demandez pas quelles sont les valeurs exactes de CPU% à mettre, je crois que ce n'est pas encore connu mais en gros quelque part entre 50% et 40% ?
Enfin côté alternatives j'ai pas regardé du côté de
Final Burn Neo, il me semble la dernière fois que j'ai jeté un œil qu'il nécessitait RA du moins sous Windows, donc ss forme de core, et qu'ils ont choisi run ahead pour la réduction du lag bien sûr, donc bof.
Je ne sais pas non plus si FBN sauvegarde l'overclock CPU% pour les cv1k...
Mais je dis p-ê portnawak faudra que j'aille vérifier l'état de cet ému.
Quoiqu'il en soit, ça aurait été bien d'avoir des émulateurs arcade aussi avancés il y a 10 ou 15 ans, n'est-ce pas ?
* en fait je vais essayer de compiler Groovy 256 avec seulement le rajout de akatana et sdoj
les builds perso comme celui de b4nd1t0 c'est bien mais j'aime pas toujours les changement de résolution sur certains jeux neogeo