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

[Onaryc]

j'avais choppé cette adresse (surement sur ce thread d'ailleurs, la flemme de vérifier) http://x15khz.hp.infoseek.co.jp/

Advance mame 106 avec ce que j'imagine être la mise en conformité des sets de mame récents .

Je pensais l'utiliser avec l'interface de mameplus (y aura surement des options pas pris en compte...).

J'ai bon avec ça?

[UltramanU]

Advancemame n'a d'intérêt que pour faire un mamecab, c'est à dire avec un écran CRT low res. C'est le seul build conçu pour reproduire avec beaucoup de précision les vraies résolutions et fréquences comme en arcade.

Sur moniteur pc CRT son intérêt est vraiment limite, alors sur LCD n'en parlons pas.

Par contre oui ce site est très intéressant, Advancemame 'plus' j'en avais pas entendu parler, ce build est probablement intéressant, dommage que la page soit en jap. ^^

Bref pour une utilisation PC simple tu n'as besoin que d'un Mame avec GUI pour windows, comme MameUI, Mame Plus, Mame FX, Wolfmame, etc...

Les vieux 'plus' sont les plus équilibrés à mon avis, il y a même des versions optimisées qui se trouvent être utiles sur certains vieux pc ou autres netbooks faiblards.

Mame Plus 0.106u1 est le plus complet mais il a un défaut: 1 frame de lag en trop !
Et c'est très dommage.
Il faut redescendre jusqu'à une v0.99 pour ne plus avoir ce défaut. C'est pas très grave vu qu'on y perd qu'une poignée de jeux et pas forcément les meilleurs.

Par contre pour les roms tu auras qqes problèmes oui, mais on est quelques-uns sur le forum à avoir le set 0.106 complet (parfaitement compatible avec la 0.99 au passage).
On reconnait ces 'anciennes roms' facilement, ce sont des fichiers zip en majuscules, comme DDONPACH.ZIP par exemple.

[Onaryc]

Effectivement advancemame est souvent cité quand tu veux faire une mamecab (je ne l'ai jamais essayé, mameplus et soft15hz me suffise ) mais les infos sur la page officielle font référence aux moniteurs LCD...
Je me disais que ça pouvait ptet passer, pour faire un 1er test avant éventuellement de partir en quête des jeux qui m'intéresse issus du set 106...

Et pour les jeux, je ne me rappel plus quand ils ont intégré l'émulation du CPS3 mais si j'ai pas mon ptit SF3 je vais faire la tête

[un ptit HS]
Pour la frame en trop, même si j'adore avoir des controles le plus réactif possible (du lag dans les commandes d'un shoot c'est tout simplement injouable, y a qu'a essayer les dernieres versions SVN de PCSX2 avec dodonpachi, espgaluda,... pour pleurer des larmes de sang!!), sur mon astro, mameplus, jpac, soft15hz et tout le toutim, ça ne me saute pas aux yeux (mais bon je ne suis qu'un amateur éclairé).
[/un ptit HS]

En tout cas, merci pour les précisions.

[UltramanU]

Pour le défaut de la frame de lag en trop c'est tous les builds de Mame de la v0.100 à la 0.125 il me semble.

Donc les builds actuels n'ont pas ce défaut (même s'il y a tjrs un peu de lag).

Advancemame est vraiment inutile sur les moniteurs pc et surtout lcd, ça ne changera pas.
Soft15KHz est moins précis qu'une vraie mamecab avec advancemame mais c'est la meilleure alternative oui, c'est loin d'être nul.

Remarque que même une config advancemame (DOS) est dépassé par une config advancemame (ou autre build aussi c'est possible) sur Linux, bien tweakée et incompréhensible pour le commun des mortels.

[Onaryc]

alors j'ai fait un ptit test avec dodonpachi et j'ai fait des impressions écran :

Mameplus 0.99, direct3D, scanline à 90%, filtrage bilinéaire...
http://img193.imageshack.us/i/mameplus99.png/

Et c'est très bien.

Maintenant mameplus 0.135 avec filtrage bilinéaire, direct3D et scanline TV :
http://img704.imageshack.us/i/mameplus135.png/

Et c'est... très bien aussi, je vois pas trop la diff en fait... Mes réglages ne sont ptet pas optimaux...

PS : j'ai fait ça un peu à l'arrache, les images sont grosses, désolé pour les ptites connections
PS2 : on fait pas gaffe au aïescore, c'est pas mon mame de compet (bon chui pas exceptionnel non plus )

[UltramanU]

Eh ben en fait fallait pas utiliser Direct3D !

C'est les scanlines dispo en DirectDraw qui assurent.

Enfin on en parlera plus tard si tu veux parce que là je vais grailler.

[Onaryc]

Alors je suis passé en direct draw, scanline 75, stretch hardware et ça donne ça (j'ai essayé plein d'autres config, mais je pas trouvé mieux...) :
http://img707.imageshack.us/i/mameplus99dd75.png/

La différence me parait pas énorme mais elle existe (j'ai ptet pas encore bon sur la config ), c'est un ptit peu plus net et les couleurs sont ptet un peu différentes mais dans le feu de l'action je vois pas la diff. Ce qui est marrant, comme tu l'as précisé dans le topic, c'est qu'on peut inverser les scanlines...

Un autre truc, je pense que c'est du à la rémanence de mon écran (un iiyama 3ms), mais avec des scanlines horizontal et un scrolling vertical (l'inverse et ptet vrai aussi), les scanlines disparaissent sur les éléments en mouvement ( j'ai observé ça sur les décors de gigawing). Je pense que la vitesse de scrolling intervient également dans le phénomène... Et c'est valable pour ma config de mameplus 99 et le scanline tv de mameplus 135.

Bref, je reste sur mon mameplus 135 d'autant qu'il n'y a pas SF3 sur la version 99 (ptet la 106)

Mais bon on est d'accords, ce rendu reste le meilleur pour apprécier au mieux les graphismes de l'époque (en attendant un système "à la shinnen").

Enfin on en parlera plus tard si tu veux parce que là je vais grailler.

Quoi tu vas manger au lieu de me répondre, mais c'est insupportable ça

PS: gros boulot au niveau de l'interface depuis la 0.99 quand même

[UltramanU]

Bah tu vois j'ai même comaté devant une série TV au lieu de te répondre !

Plusieurs points en vrac:

- C'est difficile de voir vraiment ce que ça donne sur des screenshots mais bon, c'est toi qui peut dire ce qui es le plus agréable vu que tu es devant ton écran. ^^
Je joue en tate sur un LCD 4:3 assez bon donc les conditions sont certainement différentes, en yoko peu importe l'écran, les effets sont toujours moins bien gérés.

- Même en Direct3D il existe une configuration qui peut plaire si on n'est pas trop collé à l'écran: "scanlines 60 + bilinear filtering + prescale 2"
Le prescale réglé à 2 diminue beaucoup le flou, ce qui fait que ça ne 'bave' pas, l'image est très nette, mais il faudra des scanlines plus sombres pour harmoniser le tout.
Le truc bien c'est que là, en Direct3D tu as un curseur qui te permet de régler l'intensité des scanlines au degrès près, tu n'es plus limité à 75 ou 50.
J'aime bien à 60 dans cette config, bon compromis.

- La différence entre l'émulation des scanlines dans une vieille version de Mame comme la 0.106 ou 0.99, et le filtre 'scanlines tv' dans les Mames récents, c'est la fidélité de l'alignement et la régularité.
Pour faire l'expérience il faut faire le test comparatif:
1. Mame 0.99 en Direct3D, avec des scanlines et sans filtrage bilinéaire.
2. Mame Plus 0.135 en Direct3D, avec le filtre 'scanlines tv' et encore sans filtrage bilinéaire.
Tu verras ce qui saute aux yeux. ^^

- La 'disparition' des lignes ça dépend bien des écrans et des jeux oui, honnêtement j'ai rarement ce problème probablement parce que je joue en tate et que les effets sont mieux gérés grâce à la grande résolution.
Mais en effet comme tu le dis on peut choisir des lignes verticales ou horizontales... attention quand même à l'option '75% vertical scanlines' qui n'est pas au point.
(vaut mieux utiliser sa carte graphique pour tourner l'image et l'écran, puis utiliser le '75% scanlines' normal dans ce cas)
Il y a en effet plusieurs possibilités, parfois des scanlines dans le 'mauvais sens' peuvent être bien plus agréables.

- Autre astuce: en DirectDraw on perd un peu de couleurs, Shinnen m'avait conseillé de baisser le gamma et en effet en mettant 'gamma correction' à 0.90 ça a redonné du peps aux couleurs. Jouer légèrement sur les autres curseurs peut aussi aider.

- Dernière chose: je note quand même sur ton screenshot que l'aspect a l'air incorrect, dans les cases prévues à cet effet tu devrais mettre 16:10.

Voilà, beaucoup de choses à dire mais comme tu peux le constater les possibilités sont nombreuses avec les 'vieux' Mame, il faut prendre le temps de trouver les bons réglages et ça peut devenir vraiment très agréable, quand même toujours un brin supérieur au filtre 'scanlines tv' (tu le sais déjà si tu as fait le 'test' ^^).
Pas de SF3 dans les 'vieux' mais rien n'empêche d'avoir deux versions de Mame sur son PC, c'est mon cas avec MP 0.99 et MPXT 0.135.
Enfin pour SF3 j'utilise le 'CPS3 Emulator v1.0a' par l'auteur de Nebula, qui demande beaucoup moins de ressources que Mame. ^^

PS: pour le fun j'uploaderai des screenshots du résultat de mes configs quand j'aurai moins la flemme.
PS2: je préfère la vieille interface de Mame Plus, très claire, légère et sans bugs (j'ai piqué une crise de nerfs sur MP 0.135).

[Onaryc]

- C'est difficile de voir vraiment ce que ça donne sur des screenshots mais bon, c'est toi qui peut dire ce qui es le plus agréable vu que tu es devant ton écran. ^^
Je joue en tate sur un LCD 4:3 assez bon donc les conditions sont certainement différentes, en yoko peu importe l'écran, les effets sont toujours moins bien gérés.

C'est sûre, je suis sur un 24, 16/10... pas en tate. En tate avec un grand écran, le flou de scanline TV sera sans doute plus visible.

- La différence entre l'émulation des scanlines dans une vieille version de Mame comme la 0.106 ou 0.99, et le filtre 'scanlines tv' dans les Mames récents, c'est la fidélité de l'alignement et la régularité.
Pour faire l'expérience il faut faire le test comparatif:
1. Mame 0.99 en Direct3D, avec des scanlines et sans filtrage bilinéaire.
2. Mame Plus 0.135 en Direct3D, avec le filtre 'scanlines tv' et encore sans filtrage bilinéaire.
Tu verras ce qui saute aux yeux. ^^

Ouaip j'ai essayé et c'est un peu le bordel avec scanline TV sans filtrage. Mais, même si avoir un rendu respectant le plus possible ce qu'un CRT afficherait est interessant en soi, ce n'est pas ce que je recherche. J'essaye plutôt d'avoir un rendu qui me permette d'avoir des graphismes clairs sans avoir une bouillie de pixel.

- La 'disparition' des lignes ça dépend bien des écrans et des jeux oui, honnêtement j'ai rarement ce problème probablement parce que je joue en tate et que les effets sont mieux gérés grâce à la grande résolution.

oui, la taille d'affichage doit clairement jouer. J'attendrais d'avoir un écran en dalle ips, paske le TN, j'ai essayé et c'est pas terrible en tate.

- Dernière chose: je note quand même sur ton screenshot que l'aspect a l'air incorrect, dans les cases prévues à cet effet tu devrais mettre 16:10.

Je t'avouerais que j'aime bien pour certains jeux ne pas respecter les ratios (par exemple GGX passe très bien en 16/10).

Voilà, beaucoup de choses à dire mais comme tu peux le constater les possibilités sont nombreuses avec les 'vieux' Mame, il faut prendre le temps de trouver les bons réglages et ça peut devenir vraiment très agréable, quand même toujours un brin supérieur au filtre 'scanlines tv' (tu le sais déjà si tu as fait le 'test' ^^).

J'étais passé à coté à l'époque, mais le filtrage bilinéaire c'était pour moi le top, comparé à la bouilli de pixel qu'il y avait sans. Pis je me focalise en général sur la fluidité d'affichage (et une vitesse qui corresponde à peu près, j'était trop content de pouvoir jouer en 50hz sur Winuae sur mon LCD, scrolling fluide ET jeux à la bonne vitesse).

Pas de SF3 dans les 'vieux' mais rien n'empêche d'avoir deux versions de Mame sur son PC, c'est mon cas avec MP 0.99 et MPXT 0.135.
Enfin pour SF3 j'utilise le 'CPS3 Emulator v1.0a' par l'auteur de Nebula, qui demande beaucoup moins de ressources que Mame. ^^

oui oui j'en ai quelques un aussi, mais j'aime bien l'idée d'avoir un minimum de logiciel pour émuler les jeux. Ce qui est génial dans Mame c'est qu'on peut faire des configs par jeux, par driver, ... quand je suis sur un autre émulateur qui ne permet pas ce genre ce chose, c'est un peu énervant (PCSX2 pour ne pas le citer).

PS: pour le fun j'uploaderai des screenshots du résultat de mes configs quand j'aurai moins la flemme.

Ce serait intéressant, le top ce serait d'avoir des pages wiki à disposition sur les différents site d'arcade/émulation histoire d'organiser tout ça (quand je vois la tonne d'info un peu perdu dans les forums, je trouve ça dommage, mais bon ça représente pas mal de boulot supplémentaire d'administration et de mis en place...).

PS2: je préfère la vieille interface de Mame Plus, très claire, légère et sans bugs (j'ai piqué une crise de nerfs sur MP 0.135).

Elle n'est pas parfaite, mais ce que j'apprécie bien, entre autre, c'est la vérification des fichier beaucoup plus rapide. Et la séparation du gui et de l'exe qui permet de lancer d'autres versions de mame avec la même interface (pratique pour faire des ptits tests rapide).

[raphael]

le filtrage bilinéaire c'était pour moi le top, comparé à la bouilli de pixel qu'il y avait sans.

Hérétique !

[UltramanU]

même si avoir un rendu respectant le plus possible ce qu'un CRT afficherait est interessant en soi, ce n'est pas ce que je recherche. J'essaye plutôt d'avoir un rendu qui me permette d'avoir des graphismes clairs sans avoir une bouillie de pixel.

Voilà c'est tout à fait comme ça qu'il faut le voir, on sait très bien que l'émulation de scanlines est actuellement trop éloignée du rendu d'un crt pour être vraiment réaliste.
Ces options/filtres dans les émulateurs sont là pour permettre une image plus clean, qui se rapproche un peu plus de la réalité que l'infâme bilinéaire ou autre 2xSaI, qui déforment trop les graphismes et les couleurs.

[Onaryc]

le filtrage bilinéaire c'était pour moi le top, comparé à la bouilli de pixel qu'il y avait sans.

Hérétique !

hehe, en fait c'est en voyant certain jeux sur ma borne que j'ai commencé à me replonger dans les scanlines (en particulier SF3).

Pis, à choisir entre les pixels brutes et les pixels filtrés, je choisi le filtrage .

D'ailleurs, sur demul, y a un system de shader repris de ce qui se fait sur les plugin graphique de epsx (enfin j'ai pas remonté la chaine plus loin), et c'est du filtrage qu'est loin d'être dégueu (tu peux paramétrer l'intensité du shader, ptet qu'on pourrait programmer l'effet de shinnen avec des shaders...).

[UltramanU]

Avec les shaders c'est peut-être possible de faire quelque chose de sympa oui.
J'avais déjà essayé d'en faire un pour ePSXe mais les résultats étant affreux même après des semaines de prise de tête, j'ai laissé tombé.

Je n'ai pas complètement renoncé à essayer d'intéresser un vrai connaisseur sur emuforums...à suivre, comme d'hab.

[Shinnen]

j'me suis demandé ce que cela donnerait si on modélisait le comportement du canon sur l'écran, je m'explique:
J'imagine ca en plusieurs caractéristiques:
- La transition horizontale entre les couleurs d'un pixel à l'autre
- La transition entre les différentes intensités des canons (leurs épaisseurs respectives).
- La "douceur" des bords horizontaux, le dessus et le dessous du faisceau quoi (visible sur une forte intensité).

La combinaison des trois devrait redonner naissance à cette rondeur de spot, cette douceur d'attaque, les débordements de couleurs, bref, une approche plus authentique et organique que les froids et artificiels pixels carrés.

Concernant la première caractéristique, considérons les trois pixels suivants, chacun étant de 256 pixels de côté (comme par hasard):



La courbe représente ici le niveau de rouge de chaque couleur de pixels, et j'ai choisi un scaling x4 pour l'exemple. La transition interpixels est aisément réglable. Le but est de représenter sous forme de courbe chacune des lignes de pixels permettant ensuite de la segmenter à souhait. Il suffit alors de calculer l'aire de la courbe de chaque segment pour obtenir la valeur de la composante couleur pour chaque pixel de la nouvelle résolution ! Bien que les scaling entiers donneront de meilleurs résultats que d'autres plus batards car les transitions tomberont pile au milieu de deux pixels, cette méthode s'adapte à n'importe quelle résolution !

Je bosse encore sur les deux autres caractéristiques, un peu plus chaudes à modéliser, mais voilà, l'idée est là. Je vois pas comment faire quelque chose de plus précis et d'aussi ambivalent...

J'y ai pensé, le problème vient de la compensation du gamma. Si tu retranscris de façon "brute" le comportement du spot d'un CRT (qui je le rappelle n'a pas un gamma linéaire), selon ses informations, et donc avec en destination un écran matriciel (avec un gamma linéaire), tu te retrouves avec une image sombre et délavée. Et le procédé ne s'adapte pas à toutes les résolutions, parce que en matriciel, on ne bosse que avec des adresses fixes, on ne fait pas de demi-pixel ou de trois-quart de pixel.
Et à ça s'ajoute encore le fait que on est dans un éventail de résolutions trop faibles (en gros, de 720p à 1600x1200). Il faut vraiment "gruger" sur certains aspects pour tenter d'obtenir un équivalent des variations du spot.
Dis toi que même en 1600x1200, t'as en fait que CINQ pixels (indivisibles !) par ligne pour tenter de restituer 256 valeurs (tous les diamètres possibles du spot). Il faut donc gruger avec la diffusion des couleurs pour tenter de simuler plus d'épaisseurs différentes.
C'est dans ce but que j'ai utilisé différents calques avec Photoshop, avec des niveaux de transparence, un ordre précis, et des ajustements de luminosité précis. Mais de toute façon, je n'ai mis l'accent que sur la partie explicite de la courbe gamma du CRT . En gros, je me suis focalisé sur la partie basse (teintes sombres) et la partie haute (teintes lumineuses), à hauteur de 10% pour chaque. Mais ça suffit à restituer un comportement très similaire au tracé du spot. Pour attaquer d'autres niveaux, il faut monter en résolution, sinon la différence n'est pas perceptible (limites de l'oeil humain).

Pour l'instant, je me concentre à effectuer un rendu final le plus proche possible d'une photo équivalente (redimensionnée à la même résolution), et avec un niveau lumineux global proche du screenshot de base.
De là, je fais mes "échantillons" qui incluront d'office la bonne taille de scanline (la bonne épaisseur du spot) et la bonne correction gamma.

En fait, il s'agit d'une interprétation, pas d'une conversion.
En gros, t'as un pixel qui arrive, et le programme doit choisir le "cliché" équivalent (et ajouter des clichés les uns à la suite des autres). Minimum de calculs, une seule passe. C'est la seule façon de bosser en temps réel , sinon, on se trouve dans le cas d'une mise en mémoire, et de post-traitements coûteux ( = LAG !!) .
Je dis ça donc pour le cas d'un scaler hardware, mais c'est sur ce principe que je vais bosser pour un traitement software.
L'émulateur lâche une trame brute, et le code scrute point par point, de haut en bas, de gauche à droite, chaque pixel et envoi le cliché correspondant, dans une image de la résolution de l'écran de l'utilisateur.
Y a pas de scaling (même en accélération hardware), de flou horizontal, de correction de luminosité,contraste,gamma etc. , il faut vraiment un coup de baguette magique pour transformer chaque pixel d'origine en son résultat final, directos .

C'est sur ce coup de baguette magique que je bosse.

La grosse difficulté, ce sont les scalings irréguliers. On ne peut pas se permettre de livrer une trame finalisée "régulière" (ex: transformer 320x240 en 1600x1200) puis la redimensionner à la résolution de l'écran ( 1600x1200 en 1080p). Ca voudrait dire LAG plus artefacts du redimensionnement.

[UltramanU]

Ça semble sans fin comme problème.
Surtout que ça:

Dis toi que même en 1600x1200, t'as en fait que CINQ pixels (indivisibles !) par ligne pour tenter de restituer 256 valeurs (tous les diamètres possibles du spot). Il faut donc gruger avec la diffusion des couleurs pour tenter de simuler plus d'épaisseurs différentes.

..., avec la linéarité du gamma, ça fait peur, ça paraît impossible.

[raphael]

Pour les applications de courbe de gamma CRT. La solution est probablement de générer une LUT 3D qui fasse la conversion entre un écran de borne de qualité (je ne sais pas, une Blast City par exemple) et un moniteur avec profil calibré Adobe RGB (1998) D65 G2.2 (ou même un simple sRGB pour plus de polyvalence, mais une richesse moindre) . Il suffit d'une sonde standard et d'un logiciel capable de générer la LUT 3D. C'est pas la mer à boire ensuite d'en faire un profil colorimétrique adaptable sur tout les ordis. La limite étant forcément que pour un bon résultat chacun doit avoir un écran calibré au départ. Il me semble que le mapping de plages d'adresse couleur se fait en temps réel sur Mac comme sur PC. Mais c'est peut être là que je me trompe.

[MoonZ]

J'y ai pensé, le problème vient de la compensation du gamma. Si tu retranscris de façon "brute" le comportement du spot d'un CRT (qui je le rappelle n'a pas un gamma linéaire), selon ses informations, et donc avec en destination un écran matriciel (avec un gamma linéaire), tu te retrouves avec une image sombre et délavée.

C'est pas vraiment un problème en soi, la méthode permet une compensation à la volée.

Et le procédé ne s'adapte pas à toutes les résolutions, parce que en matriciel, on ne bosse que avec des adresses fixes, on ne fait pas de demi-pixel ou de trois-quart de pixel.

Justement ! Avec cette méthode, tu as directement la meilleure approximation possible ! (en supposant qu'on ait des réglages suffisamment proches du CRT, comme les temps de transition, etc).

Et à ça s'ajoute encore le fait que on est dans un éventail de résolutions trop faibles (en gros, de 720p à 1600x1200). Il faut vraiment "gruger" sur certains aspects pour tenter d'obtenir un équivalent des variations du spot.
Dis toi que même en 1600x1200, t'as en fait que CINQ pixels (indivisibles !) par ligne pour tenter de restituer 256 valeurs (tous les diamètres possibles du spot). Il faut donc gruger avec la diffusion des couleurs pour tenter de simuler plus d'épaisseurs différentes.

Si tu modélises un carré blanc sur fond noir d'une taille inférieure à 1 pixel affichable à l'écran, sa traduction sur le LCD sera juste un pixel dont la couleur sera inférieure au blanc pur. Tu peux donc traduire bien plus d'une seule taille avec un seul pixel. Et l'approximation, pour peu que ton modèle soit pas trop mal foutu, devrait pouvoir tromper l'oeil de manière convaincante (qui a dit antialiasing ? )

Minimum de calculs, une seule passe. C'est la seule façon de bosser en temps réel , sinon, on se trouve dans le cas d'une mise en mémoire, et de post-traitements coûteux ( = LAG !!)

Le fait que ca doit consommer le moins de CPU possible, j'suis d'accord, mais pour provoquer du lag, ~16ms entre l'affichage de deux frames, ca laisse de la marge. Alors je sous-estime peut-être la charge à traiter, mais de premier abord ca parait faisable, même en incluant une compensation gamma.

La grosse difficulté, ce sont les scalings irréguliers. On ne peut pas se permettre de livrer une trame finalisée "régulière" (ex: transformer 320x240 en 1600x1200) puis la redimensionner à la résolution de l'écran ( 1600x1200 en 1080p). Ca voudrait dire LAG plus artefacts du redimensionnement.

Complètement d'accord, tailler direct dans la résolution finale est le meilleur moyen, et le seul logique.

Tout ca pour dire qu'on utilise la méthode de modélisation pour plein d'autres choses et depuis très longtemps pour justement avoir une représentation la plus conforme possible sans avoir à se préoccuper de la résolution finale (comme tracer un joli cercle antialiasé). Arrête-moi si je me trompe, mais y'a pas 15000 possibilités affichables différemment pouvant rendre la restitution la plus fidèle ?
Après la mise en oeuvre, j'suis bien d'accord, c'est tout autre chose... Connaître les propriétés des CRTs à fond est probablement indispensable pour y arriver...

[Shinnen]

Justement ! Avec cette méthode, tu as directement la meilleure approximation possible ! (en supposant qu'on ait des réglages suffisamment proches du CRT, comme les temps de transition, etc).

C'est là où je suis sceptique !...

Sur d'autres forums, j'ai vu des gars tenter ce genre d'approche, avec des résolutions élevées, puis un redimensionnement à la réso visée, pour espérer la "meilleure approximation possible".

http://board.byuu.org/viewtopic.php?p=3820#p3820

http://img338.imageshack.us/i/20x.jpg/

Le dernier cas redimensionné à 1200p:



Mouais ...........


Pour la modélisation, tu peux pas faire mieux qu'un vrai CRT bien réglé, avec une vraie photo prise dans les meilleurs conditions possibles.
C'est ma "modélisation" de référence, et je suis sûr de pas me tromper.
Après, je bosse directos à la résolution finale, c'est moi qui juge des "meilleures approximations possibles", et pas les calculs d'un redimensionnement. Comme ça, j'évite les artefacts (ex: les résidus d'une maille de phosphores), et j'optimise chaque "sous-ligne" qui compose une ligne finale.

Si tu modélises un carré blanc sur fond noir d'une taille inférieure à 1 pixel affichable à l'écran, sa traduction sur le LCD sera juste un pixel dont la couleur sera inférieure au blanc pur. Tu peux donc traduire bien plus d'une seule taille avec un seul pixel. Et l'approximation, pour peu que ton modèle soit pas trop mal foutu, devrait pouvoir tromper l'oeil de manière convaincante (qui a dit antialiasing ? )

C'est justement ça dont je parlais plus haut. Oui, je comprend bien l'astuce de la "couleur inférieure" pour simuler une épaisseur moindre, mais c'est justement ça qui va quand même aboutir à une image sombre et délavée. Et la compensation gamma, même à la volée, elle est directement limitée par la gestion numérique des couleurs, qui plafonnent à 255 (pour chaque composante). Tu peux "tricher", mais jusqu'à un certain point, après ça fausse vraiment les couleurs, ou on perd en nuances.

Même si dans la réalité, physiquement, le spot peut atteindre un diamètre vraiment réduit (teintes sombres), qui correspondrait par exemple à un peu moins d'un pixel de haut dans le cas d'une ligne finale qui fait quatre pixels de haut (scaling x4), il ne faut pas placer un équivalent de 1 pixel de haut, avec une correction d'intensité moindre.

Pour être clair, regarde ce screenshot:

http://raster.effect.free.fr/15khz/emul ... e3_d02.jpg

regarde dans la "crête" de la gargouille (complètement à droite, juste à coté de la mer), les pixels rouges sur fond noirs. Les pixels sombres ont l'air plus petits que les pixels rouges vif. C'est exactement l'effet recherché, et c'est très proche de ce qui se passe dans la réalité.
Pourtant, tous ces pixels ont la même taille.

Ils font tous quatre pixels de haut, et 6 de large.

Ici un pixel sombre:




Et là, un clair:
(bon, là il est jaune pour l'exemple, mais c'est pareil pour tous les pixels clairs)





Et c'est moi qui ait choisi cette interprétation, non seulement en fonction de l'effet recherché, en fonction de la fidélité avec le rendu CRT, mais aussi pour des raisons purement pratiques.

Le "coeur" de chaque pixel se situe en 3C et 3D (avec sa correction), chaque pixel de base se trouve reproduit dans les colonnes B,C,D,E, la ligne 1 représente l'interstice entre chaque ligne affichée, les lignes 2 et 4 sont similaires, elles assurent à la fois la rondeur du spot et ses différents diamètres. Les colonnes A et F assurent les transitions entre chaque pixel d'origine, avec une comparaison nécessaire avec le pixel précédent (donc, si c'est le même, à la suite on ajoute juste les colonnes B,C,D,E, mais si il est différent, y aura un "mix").

Chaque "sous pixel" de ce tableau a des relations précises avec le "coeur" (3C,3D), dans trois gammes: pixels lumineux, moyens, sombres.

Avant d'arriver à un modèle aussi simple, cohérent et efficace, t'as le temps de bien galérer à créer un modèle virtuel de CRT.

Ceci dit, cette approche est intéressante dans le cadre d'une étude de la technologie, et quand il s'agira de restituer à plus haute résolution (quadri-HD par ex).

Tant qu'on bosse entre 720p et 1200p, la bidouille et l'optimisation sont vraiment plus simples à mettre en oeuvre.

Le fait que ca doit consommer le moins de CPU possible, j'suis d'accord, mais pour provoquer du lag, ~16ms entre l'affichage de deux frames, ca laisse de la marge. Alors je sous-estime peut-être la charge à traiter, mais de premier abord ca parait faisable, même en incluant une compensation gamma.

C'est 16ms pour une frame, entre deux frames, y a beaucoup moins de temps dispo !
C'est d'ailleurs pour ça que chaque post-traitement bouffe une frame (on se cale à la suivante).

Et ça, ça sous entend une mise en mémoire.
Pour un scaler temps réel, il faut bosser plus vite que l'horloge pixel, qui est d'environ 8 mHz ... Donc faut vraiment taper directos et le plus simplement possible dans la résolution finale, de sorte que quand le signal débite son dernier pixel en bas à droite, le temps de retrace du spot (pour aller en haut à gauche) qui s'effectue au cours des lignes supplémentaires "dummy" , et bien on transfère une image toute prête vers l'écran, à la bonne résolution.


C'est tout con: UNE comparaison (avec le pixel d'avant), et une petite flopée d'additions/soustractions (de 15 à 30, suivant la résolution de destination), avec des valeurs prises dans un zoli tableau.

Je bosse sur ce fameux tableau.

[MoonZ]

L'exemple là, le rendu est hideux avec l'émulation de la couche phospho, et le spot ne varie pas en taille. Par contre le fondu des couleurs sur le plan horizontal n'a pas l'air mal du tout...
Concernant ton modèle de rendu, effectivement, ca devrait consommer un minimum de ressources. A voir

[Shinnen]

Pour la couche de phosphore, les gus n'en démordent pas, ils la veulent !
Ils n'arrivent pas à comprendre qu'on peut pas la restituer même à 1600x1200, et que le seul résidu qu'on obtient après redimensionnement, c'est des pixels parasites.

Regarde une tof' d'une maille classique:



En réduisant ça au strict minimum, on obtient ceci :



Ici: zoomé à 1600% :



En partant de là, et en visant un CRT moyen de 25", on obtient une résolution de destination de ......5760x7660 (.png, 330 ko)

Donc, les phosphores, c'est pas pour tout de suite !...

et le spot ne varie pas en taille

C'est pourtant LA grosse caractéristique du rendu 15 kHz et c'est la seule chose à devoir être réalisée en priorité !
Y en a qui ont bien sûr remarqué ce phénomène, mais j'ai encore rien vu de probant à ce sujet.
Normal, quand on perd son temps avec les phosphores, les défauts de convergence, le focus foireux etc.

Par contre le fondu des couleurs sur le plan horizontal n'a pas l'air mal du tout...

Oui, mais pour ça pas besoin de modélisation de ouf' ou de bosser dans des résolutions de dingue, un simple flou horizontal (motion blur à 0°) suffit ...


Pour l'instant je bosse sur trois chiffres clé : 3, 4 et 5.

Ce sont les facteurs d'agrandissement visés mais aussi l'ensemble de toutes les tailles de pixels possible, selon les résolutions d'origine (les jeux qui n'ont pas un pixel "carré", dont il faut corriger le ratio), et aussi pour greffer un up-scaling propre quand il s'agit des résolutions de destination non multiples (768p, 1080p etc.).

Par exemple, pour transformer 224 lignes en 1080 lignes, on pourrait avoir des screens finaux avec 42 lignes qui font 4 pixels de haut (les 21 premières et 21 dernières), et les 182 lignes entre qui font 5 pixels de haut, ce qui nous fait (42x4)+(182x5) = 1078, avec une marge de 1 pixel en haut et en bas pour aller à 1080, ce que personne ne verra.
Chacune de ces lignes aurait des pixels d'origine qui seraient traduit en 5 ou 6 pixels de destination, suivant la résolution d'origine.

Le tout, c'est d'éviter de changer sans arrêt de taille de pixel, comme c'est le cas avec un redimensionnement logiciel (qui calcule les meilleures approximations possibles ... hum !).
Il faut grouper les pixels de même dimension aux bords de l'image. On aura donc une légère déformation, mais on gagnera nettement en cohésion et en précision de ligne.
Sans compter que sur CRT, la linéarité n'est jamais exactement parfaite, les lignes n'ont pas toute la même épaisseur de partout (et en fait, surtout sur les bords de l'écran !).

[raphael]

Par exemple, pour transformer 224 lignes en 1080 lignes, on pourrait avoir des screens finaux avec 42 lignes qui font 4 pixels de haut (les 21 premières et 21 dernières), et les 182 lignes entre qui font 5 pixels de haut, ce qui nous fait (42x4)+(182x5) = 1078, avec une marge de 1 pixel en haut et en bas pour aller à 1080, ce que personne ne verra.
Chacune de ces lignes aurait des pixels d'origine qui seraient traduit en 5 ou 6 pixels de destination, suivant la résolution d'origine.

Le tout, c'est d'éviter de changer sans arrêt de taille de pixel, comme c'est le cas avec un redimensionnement logiciel (qui calcule les meilleures approximations possibles ... hum !).
Il faut grouper les pixels de même dimension aux bords de l'image. On aura donc une légère déformation, mais on gagnera nettement en cohésion et en précision de ligne.
Sans compter que sur CRT, la linéarité n'est jamais exactement parfaite, les lignes n'ont pas toute la même épaisseur de partout (et en fait, surtout sur les bords de l'écran !).

Merde alors, j'avais jamais pensé à ça. C'est excellent.

[kakusai]

Bonjour,

J'ai trouvé la roms de raiden2 mais je n arrive pas le lancer sous mame32. Avec quel emulateur arrivez-vous a l'emuler?

[UltramanU]

Pas le sujet idéal pour ça mais voici la réponse:

Raiden 2 et Raiden DX ne sont pas émulés par Mame ni aucun autre émulateur arcade.

Les versions Playstation en revanche...

[kakusai]

ok merci

[rikimaru_rkm]

Ultramanu, pourrais-tu remettre en ligne la version de mame v0.99 ?
Le lien est mort apparemment (2 ou 3 pages precedentes).
Merci d'avance.

Je joue a vs.mario bros, sur un mame106 et je ressens un lag (surtout que jpeux comparer directement car j'y joue sur pcb a la salle arcade), j'espere le diminuer avec la version 0.99, comme tu l'as evoque. Objectif one life, donc tendu avec du lag...

[UltramanU]

Ouaip les liens sont dead, voici déjà Mame Plus 0.99:
http://www.megaupload.com/?d=A26M6F4Y

J'en remettrai d'autres au fur et à mesure.

[rikimaru_rkm]

merci

[sisi]

Ah, c'est beau de voir que ce topic, fierté de ce forum, est à nouveau vivant!
Je viens de remarquer très récemment un truc qui auparavant ne me gênait pas (forcément-puisqu'avant je ne le remarquais pas... comme le capitaine Haddock avant qu'on lui demande s'il met sa barbe en dessous des draps ou au dessus quand il dort...)
Bon, voilà le truc un peu désagréable: quand on met des scanlines "pures" (c'est à dire a sans les options 50% ou 75%), il y a une espèce de tremblotement des sprites et du décor dès qu'il y a des déplacements qui ne suivent pas le sens des scanlines.
C'est un "tremblotement", ou je devrais dire un "effet peigne" qui ne se produit que sur les pixels en mouvement ( difficile d'en faire une photo donc).
J'avais remarqué ce phénomène la première fois avec l'émulation Xbox, et sur raiden fighters ace de la Xbox 360 sur ma TV 15khertz mais hier, je l'ai noté sur mon CRT 31kz avec les belles scanlines "directdraw" des anciennes versions de Mame.
Pour l'instant, le meilleur compromis que j'ai trouvé est "scanlines 75%", même si elles sont discrètes, on les voit et il n'y a pas les tremblotements dont je viens de parler.
Quelqu'un connaît un moyen d'avoir à la fois de "vraies" scanlines et surtout d'éviter l'effet peigne? C'est peut être un problème propre aux crt, et il est peut être présent également en arcade, si ça se trouve...
Voilà ce que c'est que d'être ultra attentif a tous les détails graphiques...

[UltramanU]

Je suis pas sûr de comprendre ce que tu appelles 'pures'...

En DirectDraw c'est 'flouté' (interpolé) puisqu'il s'agit d'un 'zoom', et en Direct3D il me semble que c'est du pur scaling, avec la possibilité de choisir le filtrage ou de régler l'intensité des lignes au % près.

Malheureusement comme il ne s'agit dans aucun cas de 'vraies' scanlines mais simplement du 'masquage' d'une ligne sur trois (enfin je crois) il est évident que les limites au 'réalisme' sont nombreuses.

Les résolutions, le scaling, l'intensité, le filtrage/interpolation, les performances de l'écran même, etc, influent sur le résultat.

Évidemment il faut aussi savoir maitriser au mieux la configuration de son Mame.
(Avec le temps je me rends compte qu'il y a pas mal de confusion... aurais-je le courage de refaire un tuto complet ? )

[sisi]

Ce que j'appelle des scanlines "pures", ce n'en sont pas des vraies, bien sûr, mais celles qui forment vraiment une ligne noire (les autres sont plus ou moins translucides), disons que ce sont les plus visibles.
Quant à refaire un tuto de config, n'hésite surtout pas! ton nom s'enorgueillira d'une gloire nouvelle O grand Ultramanu!