Pour avoir les jeux dans leur beauté originale sur mame!

[Ryusenshi]

Voici ce que j'obtiens, avec un facteur multiplicatif 3,5 verticalement et 4,167 horizontalement et des scanlines perso, le tout réglé à coup de "sliders control" :



Plutôt convaincant, non ?

[UltramanU]

Sparda, si tu relis tout le topic du début tu comprendras.

Bon enfin je résume:

Shinnen l'explique très bien dans les premières pages, en gros c'est juste des lignes dessinées sur des fichiers PNG et plaquées par dessus l'image, absolument sans distinction.

C'est en commençant comme ça que j'ai découvert que c'était useless de se prendre la tête avec, et ensuite me suis rendu compte que dans les 'anciens' Mame (jusqu'à la v0.106) la simulation des scanlines était gérée à la racine, dans le 'moteur/coeur' video de Mame, sans erreurs.

C'est loin d'être l'idéal Shinnesque, mais ça bat allègrement le système des 'effets' en PNG qu'on trouve tan tous les autres Mame à partir de la v0.107 jusqu'à aujourd'hui.

Pour jouer sur un LCD ou autre écran haute résolution, c'est encore ce qu'il y a de mieux à l'heure actuelle.

Voilà.

@ryusenshi: ou alors tu peux utiliser le plugin 'Scanline TV' dans Kega Fusion et t'auras de suite quelque chose de plus agréable.
Laisse béton les PNG, il faudrait en dessiner autant qu'il existe de résolutions et de jeux, c'est des calculs parfois très difficiles, voire irréalisables.
Ça te prendra des années avant de pouvoir jouer peinard avec une image regardable.

[Ryusenshi]

@ryusenshi: ou alors tu peux utiliser le plugin 'Scanline TV' dans Kega Fusion et t'auras de suite quelque chose de plus agréable.
Laisse béton les PNG, il faudrait en dessiner autant qu'il existe de résolutions et de jeux, c'est des calculs parfois très difficiles, voire irréalisables.
Ça te prendra des années avant de pouvoir jouer peinard avec une image regardable.

Si j'ai pris Streets of Rage, c'est uniquement pour pouvoir comparer le même jeu sur une console et sur Mame (peu de jeux sont vraiment exactement identiques). Le but c'était quand même d'utiliser Mame, de loin le plus polyvalent.

Et non, ça ne me prend pas des années, à part le PNG du facteur 3,5 qui m'a posé problème, ça prend 5 minutes à tout casser à en faire un de 4,5 et 5,5, et les calculs ne me prennent guère plus d'une minute par résolution. En plus ce sont souvent les mêmes résolutions qui reviennent : 256x224, 320x224, 320x240, 384x224, plus les mêmes en vertical, et tu as couvert 95% des jeux.

[UltramanU]

As you wish !

[Sparda]

J'ai voulu teste la 0399 Lagless et bizarrement, mon EX2 Full sanwa ne fonctionne pas avec, il n'est pas reconnu et joy2key n'arrive pas a trouver les directions du stick, bizarre comme probleme , surement un soucis de gestion de stick propre a Mame, car sur la 2.2 aucun probleme.

Par contre, etrangement, qd je lance Guwange sur la 2.2, cest pixelisé a mort , alors que sur la 0.99, cest parfait...alors que j'ai les meme reglages et options pour les deux...j'y capte que dalle la

Edit: En fait, jetais en direct3D et pas DirectDraw sur la 2.2...dsl ^^

[UltramanU]

Dans default game options -> controllers -> cocher 'enable joystick input', puis dans la dropbox en dessous -> P1: ID1

Tu redémarres Mame et tu vois si ça marche.

Pas garanti, mais c'est un 'problème' connu sur les anciennes versions.

Au pire une mise à jour complète de DirectX, un redémarrage de l'ordi, puis un nouvel essai...

[jehuda]

Coucou ici est ce que quelqu'un pourrait me donner un lien pour le lagless mame 0.99 je ne trouve plus de liens correspondant .

Les Save states marchent vraiment pour DDP Guwange et les vieux Cave ?

Comment se choisissent les scanlines dans ces versions, c'est une autre méthode qu'un répertoire remplie de .png ?

[skateinmars]

Coucou ici est ce que quelqu'un pourrait me donner un lien pour le lagless mame 0.99 je ne trouve plus de liens correspondant .

Les Save states marchent vraiment pour DDP Guwange et les vieux Cave ?

Oui
Regarde sur le topic dodonpachi ProMeTheus a du le mettre en lien une bonne dizaine de fois

[Ryusenshi]

Je reviens sur ce sujet pour vous dire que je travaille toujours sur un dossier concernant l'affichage sous Mame (enfin, les versions récentes). Voici où j'en suis :
http://dl.free.fr/ei4nmsKOv/affichage.txt

Pour l'instant ce n'est qu'un fichier texte, je ferai quelque chose de plus détaillé par la suite, avec des screenshots et tout et tout. Pour l'instant, qu'en pensez-vous ? Shinnen, en particulier, jettes-y un coup d'oeil !

[yoZencolere]

C'est illisible un pavé comme ça. Essaye d'aérer ton texte un minimum et fais des paragraphes.

[Shinnen]

En lisant sous wordpad avec l'option retour à la ligne, ça reprend une gueule convenable. Je me suis fait eu aussi en ouvrant direct le fichier avec le simple lecteur de txt. ^^'

C'est pas mal, je reprendrais juste quelques détails, mais qui ont leur importance.

[Ryusenshi]

C'est illisible un pavé comme ça. Essaye d'aérer ton texte un minimum et fais des paragraphes.

Euh, désolé, j'ai tapé ça avec l'éditeur de base de Linux et de base ça passe bien. Il doit suffire d'activer "retour à la ligne sur règle" ou quelque chose du genre, avec des lignes de 80 caractères. De toute façon je vais passer ça en LaTeX un de ces jours.

C'est pas mal, je reprendrais juste quelques détails, mais qui ont leur importance.

Mais je n'attends que ça !

[wasabi]

Bonjours

Justement puisque que l'on parle du meilleurs rendu possible sous mame , je recherche un logiciels capable de changer la fréquence de mon moniteurs TV ...

nan , ba enfaite la carte nvidia le fait tres bien . desolé pour le derangement .

[MoonZ]

C'est illisible un pavé comme ça. Essaye d'aérer ton texte un minimum et fais des paragraphes.

Euh, désolé, j'ai tapé ça avec l'éditeur de base de Linux et de base ça passe bien. Il doit suffire d'activer "retour à la ligne sur règle" ou quelque chose du genre, avec des lignes de 80 caractères.

C'est juste que sous les systèmes Unix, les transitions entre chaque lignes se font avec un seul caractère, "Nouvelle Ligne", alors que Windows utilise deux caractères, "Retour Chariot" et "Nouvelle Ligne". Du coup sous le notepad de Windows, on ne voit qu'un énorme bloc indigeste.

Mais bon, des éditeurs de texte comme Notepad++ gèrent néanmoins ca très bien automatiquement.

[Shinnen]

la différence entre la résolution verticale de 240 et 224 : la seconde occupe-t-elle une plus petite zone à l'écran, ou bien la même zone en bidouillant la synchronisation du balayage ? Question liée, y a-t-il une raison pour laquelle autant de consoles et de systèmes d'arcade (NES, SNES, Neo Geo, Mega Drive, CPS...) utilisaient la même résolution verticale de 224, plutôt que 240 ? Bon, évidemment moins de lignes = moins de calculs à faire, moins de place en mémoire, etc. Ça n'explique pas pourquoi avoir choisi la même résolution verticale alors que la résolution horizontale, elle, est très différente d'un système à l'autre (de 256 à 384).

Je poste ici, histoire que d'autre puissent en profiter (et dès que j'ai le temps, je réponds en détail au sujet de l'article de Ryusenshi ^^' ) .


Alors, quoi qu'il arrive, un signal lo-rez (dit "240p") comprend 262 lignes, qui durent chacune 64 micro-secondes (à 60 Hz s'entend, pour l'instant on s'en fout du PAL à 50 Hz).

Ces lignes occupent la place réglée par le technicien en bout de chaine de montage. On peut également intervenir soi-même en modifiant la géométrie de l'image ( taille verticale ) de façon à ce que les lignes actives (l'image) occupent toute la hauteur visible du tube. Un tube arcade est prévu pour une utilisation plus souple (pour s'adapter à la multiplicité des résolutions des jeux) qu'une TV dédiée principalement à l'affichage de contenu broadcast (dont la résolution ne varie jamais). Sur TV, on a prévu des marges bien définies (overscan), et il se trouve que le contenu visible ("safe" dans le jargon) tourne à 448 lignes en NTSC (donc 224 pour le cas lo-rez).

Mais ça ne suffit pas à expliquer la différence 240/224 (il s'agit plus qu'une séparation du monde arcade et domestique), puisqu'après tout, moults systèmes arcade même récents diffusent aussi 224 lignes au lieu de 240.
Ceci tient au fait que pour 262 lignes dans tous les cas de figure, on a moins de lignes dédiées aux infos de synchro quand il s'agit d'en afficher 240. Pour le cas des 224 lignes, on se retrouve avec 16 lignes "vides" de plus, ce qui constitue un laps de temps non négligeable (à prendre en compte pour le temps qui sépare deux images), sachant que les machines de jeux profitent de cet intervalle de temps pour diverses opérations. Donc, pour la donnée verticale, le "changement" de résolution correspond à un gain de temps (calcul) avant d'être un gain de mémoire (capacité).
Bien sûr, 224 c'est pas un chiffre au hasard, ça correspond à une rangée de tiles (de 16 pixels). La différence ne se fait pas trop sentir entre 240 et 224 lignes. Par contre, à 208, ça serait limite.

Pour ce qui est de la résolution horizontale, c'est différent, puisque quelque soit le contenu, les lignes durent invariablement 64 micro secondes (et les machines de jeux ne tiennent guère compte du laps de temps entre deux lignes). On peut afficher n'importe quel nombre de pixel par lignes, puisque le signal analogique de chaque ligne (scanline) peut être divisé "à l'infini" (puisque c'est un signal analogique, et non échantillonné). Dans les fait, on s'arrête à une horloge pixel de 14 mHz, pour séparer au maximum 768 points.

Donc, pour afficher des graphismes plus fins tout en restant dans la même gamme de fréquence (soit 15 kHz), il est judicieux de passer à 224 lignes et d'augmenter la résolution horizontale (il ne s'agira qu'une question de mémoire, et pas de "mémoire+augmentation de fréquence vidéo" qui est nettement plus coûteux).

Ainsi, on trouve des systèmes comme le CPS (384x224) ou le PGM (448x224) qui affichent des graphismes plus fins tout en ayant une résolution verticale légèrement moindre. Y a d'autre systèmes comme le hardware des Street Fighter Ex qui lui diffuse à 512x240, là on atteint la limite de ce qui est possible d'afficher avec le meilleur rendu ( il faut vraiment un tube de 29" avec un pitch faible pour afficher correctement plus de 512 points par lignes, en évitant le phénomène de moiré, qui est d'autant plus contraignant pour les images de jeux vidéo, constituée de lignes bien verticales par rapport à une image vidéo broadcast ).

[sisi]

Intéressant, je commence à comprendre un peu cette histoire de "ligne active" 240p ou 224p etc...
En lisant le manuel de l'UVC,on voit les résolutions qu'il peut sortir:
"The uVC board supports multiple output resolutions
· Mode 1 - Low Resolution - CGA - (std resolution)
o Horizontal Pixel Clock 73.626 ns
o Horizontal Active Pixels 640 pixels 47.121 µs
o Horizontal Total Pixels 864 pixels 63.613 µs
o Horizontal Front Porch 64 pixels 4.712 µs
o Horizontal Sync Width 60 pixels 4.418 µs
o Horizontal Back Porch 100 pixels 7.363 µs
o Horizontal Scan Rate 15.72 KHz 63.613 µs
o Vertical Line Clock 63.613 µs
o Vertical Active Lines 240 lines 15.267 ms
o Vertical Total Lines 262 lines 16.667 ms
o Vertical Front Porch* 3 lines 0.318 ms
o Vertical Sync Width 3 lines 0.191 ms
o Vertical Back Porch 14 lines 0.891 ms
o Vertical Refresh Rate 60 Hz 16.667 ms"

Si je ne dis pas de conneries, ce truc peut gérer l'émulation d'un PC en 31 khz tout con en donnant un rendu très proche de l'arcade, non?
Soft 15khz le fait aussi très bien, mais j'ai pu remarquer que certaines résolutions ne peuvent être affichées (en cause aussi les fréquences verticales bizarres avec des virgules) et dans beaucoup de cas, on doit utiliser des modelines permettant de ne pas faire saccader l'animation ou le son. Les moyennement chanceux comme moi qui ont une Nvidia devront se contenter de 32 modelines, pas plus, mais bon, y a dejà de quoi faire .

J'aimerais savoir si l'UVC n'altère pas trop le rendu arcade, comme Pseudoname semblait le dire en parlant de l'arcade VGA (je le cite:

L'arcadeVGA est la solution la + simple et rapide (rien à faire ou presque).
Bon nombre de réso disponibles (quasiment les mêmes que les modes défauts de soft-15khz).

Mais selon les réso, l'image ne sera pas toujours pile-poil bien centrée (et même peut-être rogné). Ça dépendra beaucoup aussi du type de moniteur/écran (de l'un à l'autre les timings ne seront pas forcément "traités" de la même façon.

Autre (petit) inconvénient avec l'Avga, ce sont certaines fréquences verticales avec certaines réso (justement pour les CPS, qui en réalité sort du 384x224@59,6Hz), la neogeo (304 et 320x224@59,2Hz), pareil avec les midway (400x254@54,7Hz).
Bref ces petits écarts (perceptible à partir d'environ 0,4Hz) feront apparaître de légères saccades son ou vidéo (selon si l'on active ou non le throttle). C'est surtout visible dans les scrolling.
Pas très génant pour la plupart, mais peut aggacer les ultra-maniaques soucieux d'une émulation 100% fluide et fidèle à l'animation/vitesse originale.

Pour le 240p ça peut être dangereux si l'on oublie de désactiver les options de stretch (hardware stretch dans Mame), ce qui aura comme résultat d'étirer l'image en vertical, et donnera des pixels foireux/déformés, bref plus rien avoir avec le rendu net et précis d'origine.
Si le stretch est désactivé, pas de souci, Mame (ou tout autre émulateur, rajoute des lignes noires pour compenser.

Donc pour avoir les réso natives au chromosome près, c'est soft-15khz + modelines.

N'oublions pas que le titre de ce topic: Pour avoir les jeux dans leur beauté originale sur mame!, je ne vois pour l'instant pas mieux que Soft 15khz+ tube cathodique 15khz...

[Shinnen]

En lisant le manuel de l'UVC,on voit les résolutions qu'il peut sortir:
"The uVC board supports multiple output resolutions
· Mode 1 - Low Resolution - CGA - (std resolution)
o Horizontal Pixel Clock 73.626 ns
o Horizontal Active Pixels 640 pixels 47.121 µs
o Horizontal Total Pixels 864 pixels 63.613 µs
o Horizontal Front Porch 64 pixels 4.712 µs
o Horizontal Sync Width 60 pixels 4.418 µs
o Horizontal Back Porch 100 pixels 7.363 µs
o Horizontal Scan Rate 15.72 KHz 63.613 µs
o Vertical Line Clock 63.613 µs
o Vertical Active Lines 240 lines 15.267 ms
o Vertical Total Lines 262 lines 16.667 ms
o Vertical Front Porch* 3 lines 0.318 ms
o Vertical Sync Width 3 lines 0.191 ms
o Vertical Back Porch 14 lines 0.891 ms
o Vertical Refresh Rate 60 Hz 16.667 ms"

Pour le cas décrit au dessus, il s'agit des timings standard de la résolution 640x240@60Hz (en progressif ou "240p"), qui sont les mêmes que pour le mode entrelacé 480i (640x480).

On s'aperçoit de la taille énorme des porchs et autres infos de synchro. Pour 640 pixels visibles, on a en fait un signal de 864 pixels.
Pareil en vertical, avec 14 lignes de back porch (et 30 dans le cas 224 lignes actives).

Ca date de l'époque où l'électronique était plus lente. Dans les faits, selon les écrans, on peut avoir des timings nettement optimisés, histoire de gratter en bande passante pour afficher plus de lignes et plus de pixels en conservant un taux de rafraichissement élevé (dans le cas d'un jeu à résolution custom).

Si je ne dis pas de conneries, ce truc peut gérer l'émulation d'un PC en 31 khz tout con en donnant un rendu très proche de l'arcade, non?

Ce bidule (l'UVC) est sensé être un downscaler je suppose (parmi ses fonctions). Seulement, là, à vue de nez, je dirais qu'il transforme de façon brute le 640x480 31 kHz du PC (en entrée) en 640x240 en sortie (à 15 kHz donc). Donc, le problème se situe en amont, au niveau du PC, avec le problème pour gérer l'affichage de autre chose que 320x240 pour les émulateurs (qui est le cas le plus simple qui comporte le moins de degradation, puisqu'on peut faire un agrandissement x2 sans artefact).

Maintenant, supposons que sur ton PC, tu émules du CPS (384x224), le résultat final dépendra de la façon dont tu as étiré l'image. Manque de bol, 384 pixels, c'est pas un multiple de 640 (il aurait fallut pouvoir afficher 768 pixels à l'horizontal). Et faut faire gaffe à pas étirer les 224 lignes pour qu'elles se transforment en 480 lignes (avec floutage dégueux ou lignes irrégulières).

Je m'étais penché sur le cas de la contrainte de la fenêtre 640x480. Pour un résultat optimal, on en revient à ma méthode du flou horizontal seul, et du doublage strict du nombre de lignes. Bref, étirer 384 points pour qu'ils deviennent 640, mais obtenir 448 lignes (avec bordure noir en haut et en bas, donc). J'avais fait des photos comparatives avec des screens de SF 3.3 (un en 384x224 pur, et l'autre en 640x240 correctement traité), faut que je les retrouve. La différence était peu notable, à part pour un oeil impitoyable.

Ceci dit, il s'agit du cas idyllique (sortie PC directe à 15 kHz), dans la réalité, il faut en plus ajouter la dégradation du signal lié à la conversion du boitier. Bref, pas arcade perfect, mais valable si son émulateur peut gérer le flou unidirectionnel........... Ha merde, non, c'est toujours pas à l'ordre du jour !

Soft 15khz le fait aussi très bien, mais j'ai pu remarquer que certaines résolutions ne peuvent être affichées (en cause aussi les fréquences verticales bizarres avec des virgules)

Ca vient des limites du chassis de l'écran qui reçoit le signal. Les chassis récent ont des marges très faibles ils décrochent facilement (on est vite hors tolérance). Ca ne dépend pas en soi de soft15khz.

et dans beaucoup de cas, on doit utiliser des modelines permettant de ne pas faire saccader l'animation ou le son. Les moyennement chanceux comme moi qui ont une Nvidia devront se contenter de 32 modelines, pas plus, mais bon, y a dejà de quoi faire .

Un écran, c'est un périphérique de streaming, il faut lui fournir les infos correspondant au contenu vidéo.

Si t'as que 32 modeline de dispo, il faut en utiliser certaines pour plusieurs résolutions proches. En jouant sur les porchs, tu attribues l'espace pour afficher l'image, et il suffit de corriger sur l'écran pour être en full screen. Tu peux utiliser deux modelines pour 288x224 et 256x224, ou bien utiliser la modeline de 228x224 pour afficher du 256x224, et étirer l'image depuis l'écran. Enfin, à condition qu'il y ait le même taux de rafraîchissement vertical. En fait, c'est ça la grosse contrainte.

[Shinnen]

J'aimerais savoir si l'UVC n'altère pas trop le rendu arcade, comme Pseudoname semblait le dire en parlant de l'arcade VGA

Le soucis, c'est que l'amplitude du signal vidéo n'est pas identique d'une carte graphique à l'autre. Souvent, on se retrouve avec un signal qui dépasse 1V (pertes d'infos dans la partie lumineuse). De plus, une conversion, ça implique nécessairement du bruit. Sans compter que avant ça, comme écrit plus haut, y a un problème crucial à la source, à gérer comment l'image lo-rez va devoir être calée dans une fenêtre 640x480. Pour éviter ça, il aurait fallut prévoir un boîtier qui supporte plus que 640 pixels (qui peut supporter un doublage parfait de 384 et 448 pixels en 768 et 896), et qui puisse aussi supporter moins (512 pixels, pour le doublage de 256). Bref, ça serait plus onéreux et complexe à concevoir. Là il s'agit certainement d'une division stricte après mise en mémoire, qui conserve le nombre de pixels par ligne d'origine (640, quoi), donc qui impose un traitement optimal à la source, de façon software.

Donc pour avoir les réso natives au chromosome près, c'est soft-15khz + modelines.

On peut pas faire mieux en terme d'émulation.

Reste le soucis que personne n'évoque jamais (à part moi bien sûr), à savoir que la sortie vidéo des cartes graphiques produit trop souvent un signal trop fort (supérieur à 1V, qui est pourtant la norme). C'est pour ça que malgré tout, on perd un peu en qualité par rapport au signal qui sort d'un appareil 15 kHz pur (qui ne dépassent pas 1V, et sont même légèrement en dessous).

Il faudrait soit au niveau hardware avoir de petits potards pour rester à 1V mesuré, soit au niveau software avoir une option dans soft15khz et affiliés pour contrôler l'affichage à la manière des panels des cartes graphiques, qui autorisent de contrôler contraste, luminosité et gamma.
Mais bon, c'est pas à l'ordre du jour, parce que personne n'a constaté le problème, et que c'est un détail insignifiant pour la majorité des utilisateurs. (sauf moi qui s'acharne à optimiser les voltages des canons et qui a donc besoin d'un signal vidéo strictement compris dans la norme, de 0.3 à 1.0 V exactement).

[sisi]

éh éh, je savais que tu allais développer comme d'ahbitude, c 'est très intéressant, et avec cette petite touche d’orgueil qui te caractérise

Reste le soucis que personne n'évoque jamais (à part moi bien sûr).

Juste pour info, mais je doute que ça change grand chose, l'UVC peut prendre plusieurs résos
Input resolutions
· 640x480
· 800x600
· 1024x768

MAis bon, pour le doublage, c'est sans doute raté (je crois pas qu ' il y ait des résolutions arcade 400x300...)

A propos d'ailleurs:

Maintenant, supposons que sur ton PC, tu émules du CPS (384x224), le résultat final dépendra de la façon dont tu as étiré l'image. Manque de bol, 384 pixels, c'est pas un multiple de 640 (il aurait fallut pouvoir afficher 768 pixels à l'horizontal). Et faut faire gaffe à pas étirer les 224 lignes pour qu'elles se transforment en 480 lignes (avec floutage dégueux ou lignes irrégulières).
Je m'étais penché sur le cas de la contrainte de la fenêtre 640x480. Pour un résultat optimal, on en revient à ma méthode du flou horizontal seul, et du doublage strict du nombre de lignes. Bref, étirer 384 points pour qu'ils deviennent 640, mais obtenir 448 lignes (avec bordure noir en haut et en bas, donc). J'avais fait des photos comparatives avec des screens de SF 3.3 (un en 384x224 pur, et l'autre en 640x240 correctement traité), faut que je les retrouve. La différence était peu notable, à part pour un oeil impitoyable

Si je ne m'abuse, on pouvait, en appuyant sur "y" au démarrage, avoir un résultat assez sympa sur Street Fighter third strike sur Dreamcast: on passait d'un "fake low res" à un "true low res", mais avec une tout petit défaut sans doute due à l’impossibilité de la Dreamcast à obtenir du 384x224: on obtient un résultat un chouia plus flou que le même jeu émulé sur PC+Soft 15khz avec bons modelines. Ceci dit, j'ai pu constater amèrement que si l'émulation sur le plan visuel est vraiment impeccable, il en ait pas de même avec le lag: dans un jeu de baston, ça ne pardonne pas, pour ce SF3.3, c'est assez frappant: Visuellement, la version Dreamcast est un poil en dessous de l'émulation, mais niveau lag, c'est cette version qui est la meilleure.
Pareil pour la version PS2 de KOF 2003 et le même jeu sur MAME, c'est le jour et la nuit: sur la première version, les combos sortent ultra facilement, sur l'autre, c'est laborieux et ça donne l'impression de ne marcher qu'une fois sur trois... Bon, mais ça c'est un autre souci...

Reste le soucis que personne n'évoque jamais (à part moi bien sûr), à savoir que la sortie vidéo des cartes graphiques produit trop souvent un signal trop fort (supérieur à 1V, qui est pourtant la norme). C'est pour ça que malgré tout, on perd un peu en qualité par rapport au signal qui sort d'un appareil 15 kHz pur (qui ne dépassent pas 1V, et sont même légèrement en dessous).

Concrétement, qu'est ce que qui peut gêner à l'écran? personnellement, je trouve le résultat très beau, même si les scanlines sont peut être un tout petit peu moins présentes que sur un "vrai" jeu d'arcade.

Citer:
Soft 15khz le fait aussi très bien, mais j'ai pu remarquer que certaines résolutions ne peuvent être affichées (en cause aussi les fréquences verticales bizarres avec des virgules)


Ca vient des limites du chassis de l'écran qui reçoit le signal. Les chassis récent ont des marges très faibles ils décrochent facilement (on est vite hors tolérance). Ca ne dépend pas en soi de soft15khz.

bonne nouvelle,ça, je vais pouvoir jouer à Ghost and Goblin's sur un écran arcade Hantarex (passque sur ma TV de 2002, c'était pas possible).