玩PC低解240p老游戏的玩家，分享一下AMD的GPU和APU的成功例子吧。

羽神比肩

powerh3 发表于 2018-8-25 20:14
感觉是色差的绿同步信号没被正确识别。。。

试了下，把PC低解的RGBHV拔了就好了.......奇怪啊，明明WII都没影响，难道是PSP电流太小，视频输出信号不够强？

该用户已被禁言

羽神比肩 发表于 2018-8-26 17:23
试了下，把PC低解的RGBHV拔了就好了.......奇怪啊，明明WII都没影响，难道是PSP电流太小，视频输出信号不 ...

Wii色差下不受干扰？

彩监能接受Wii的色差信号中的绿同步信号，而不出现上下滚动和左右偏斜抖动的现象？（同时接入PC的RGBs的s同步信号到Ext Sync端口）


那比较奇怪哦。。是不是PC当时是关闭的？所以RGBs的s同步信号没有了，导致没有串扰到彩监？

该用户已被禁言

羽神比肩 发表于 2018-8-26 17:23
试了下，把PC低解的RGBHV拔了就好了.......奇怪啊，明明WII都没影响，难道是PSP电流太小，视频输出信号不 ...

也可能是你的彩监是有s复合同步信号线接在Ext Sync头上，彩监感知到后，切换到RGBs模式了。。你接PSP的色差时，彩监也认为有RGBs信号，而没有切换到色差的绿同步模式，丢掉色差的同步信号。


而你拔掉RGBHV后，彩监就侦测到此时是色差模式，然后绿同步信号认出来了。。


其实可以把RGBHV的H线（即RGBs的s同步信号线。而RGBs模式下V没信号的，不用接）拔掉就行。RGB可以一直连在彩监上。

该用户已被禁言

powerh3 发表于 2018-8-25 10:08
着重、补充说明一下，超级马里奥世界  Super Mario World，SFC版。。。哈哈。。

240x180（像素数目比4:3）是不少256x224（像素数目比8:7）游戏过扫后在CRT电视里显示的实际分辨率啊，这样人物和各元素也能保持不变形。实际FC和SFC游戏按照240x180来做（周围添加一部分像素防止过扫不够而导致有黑边）是最省资源的方式啊。


终于明白为何GBA是240x160了，为了保持游戏移植到液晶屏幕上各元素比例不变形。任天堂还是更注重人物等各元素的比例。这样移植也很简单了，不用重新为修正比例正确 而 调整大量像素，节约了成本。

GBA是240x160是像素数目比3:2的宽屏。。只要把240x180（像素数目比4:3）的FC和SFC正确比例的像素画面的上下共20个像素截掉，就可以完美保持人物等各元素的比例不变了，保持距离感和手感。。

还有一点是，在相同屏幕尺寸下240x180（像素数目比4:3）比256x192（像素数目比4:3）显示的人物比例（同像素数目制作）更大。。缺点是比256x192显示的场景要小些。。


还有GBA的液晶像素块应该是接近正方形的，才能保证比例和CRT的一致啊。。



超级马里奥兄弟3 Super Mario Bros. 3，SFC版。

整张图是SFC的256x224（像素数目比8:7），粉色是GBA的像素截取部分，240x160（像素数目比3:2），再把数值显示等提示部分做到GBA的240x160的上部。。

SFC的256x224。
GBA的240x160。

GBA版叫：超级马里奥GBA版4 - 超级马里奥兄弟3   Super Mario Advance 4 - Super Mario Bros. 3。


来源这个网站，有更多图详解：
https://themushroomkingdom.net/smb3_snes2sma.shtml




蓝色是CRT的像素截取部分，240x180（像素数目比4:3），蓝色边框外过扫掉，保持人物、砖块等各元素比例正确。
粉色是GBA的像素截取部分，240x160（像素数目比3:2）。


CRT也可以按256x192截取像素。红色是CRT的像素截取部分，256x192（像素数目比4:3），红色边框外过扫掉，保持人物、砖块等各元素比例正确。在CRT上，同尺寸屏幕显示的人物比240x180（像素数目比4:3）更小，但显示的场景范围更广。
粉色是GBA的像素截取部分，240x160（像素数目比3:2）。

该用户已被禁言

原来PS版月下的上下黑边是正确的，留着是为了过扫掉，保持人物、物体等各元素比例正确啊。。。


恶魔城 - 月下夜想曲   Akumajou Dracula X - Gekka no Yasoukyoku/Castlevania - Symphony of the Night，PS版。

原图是256x240，上下大黑边，以前不知为何留大黑边。钟表盘等圆形是趋向立着的鸡蛋式的椭圆。
256x240
有效彩色像素实际是256x207，上下截掉黑边后为下图。
256x207
真实的CRT有的还要过扫掉一些256x207的图像，可能是240x194了。
240x194



CRT以4:3显示256x240图时，如果不过扫掉上下黑边，这样比例不对。看时钟表盘是压扁的椭圆了，还有左上角的圆盘也一样。

256x240（带上下黑边）在640x480（像素数目比4:3）下显示效果，模拟一下CRT上的人物和各元素比例。

CRT以4:3显示256x240图时，应该过扫掉上下黑边，显示有效像素256x207。这样比例对了。看时钟表盘是圆的了，还有左上角的圆盘也一样。

256x207（去掉上下黑边）在640x480（像素数目比4:3）下显示效果，模拟一下CRT上过扫上下黑边后，人物和各元素比例。


240x194在CRT上显示比例模拟。这样人物在CRT上会放大，占屏比更多，视觉效果更好。显示的图像范围会变小，但月下的图像周围都是砖头、石头等，显示这些过多，视觉上没什么用了，甚至有些多余。。但是有可能把某些必要元素过扫到画面外，根据具体情况调节吧。。。




有一种上下满屏的补丁实际对CRT显示没用的，因为都过扫掉了。对高清电视和掌机有些用吧。不过像素块横竖以1:1等比或点对点显示时，比例也是不对的，圆形是趋向立着的鸡蛋式的椭圆（看本楼的前两张图），要左右拉伸一些才行。

该用户已被禁言

C大在这贴简单解释了frame slice（帧切割）的原理，可以一帧内轮询（Poll） 输入（Inputs）的信号。普通模拟器是一帧后，即224行扫描完整个屏幕后，才开始轮询输入信号。
http://forum.arcadecontrols.com/index.php/topic,157930.0.html
理论上CPU越快，轮询甚至可以达到扫描的一行内。。1/240x60（行数x帧数）=1/14400（14400就是14.4kHz，即行频啊），0.00006944s（秒）即0.06944ms（毫秒），不到0.1ms啊。

不过又说以现在的电脑性能来说，是科幻小说。。

一帧是16.67ms左右，frame slice若能一帧内切十次，就是1.667ms。也很低的延迟了。。老游戏机实机好像也要2ms以上输入延迟。即1秒要切60x10（帧数x切割数），等于一秒大概切600次了，不知道要多高主频CPU可以胜任哦。。



34楼及以下几楼。。还说了一点frame slice 和 frame delay的区别和关系。。
Frame slice and frame delay implementations are mutually exclusive.

Normal emulation runs the emulated CPU for a whole frame, say 224 scanlines, then it draws the screen and polls inputs.

With frame slice 1, the same cycle is done for scanlines 0-111, then for 112-224. Inputs are polled in the middle and in the end.

The higher you set frame slice, the finer the CPU slices and the input granularity. In theory you could slice at the scanlines level or even more but this is still science fiction on nowadays computers.

yuuyuubaishu

powerh3 发表于 2018-8-30 13:30
C大在这贴简单解释了frame slice（帧切割）的原理，可以一帧内轮询（Poll） 输入（Inputs）的信号。普通模 ...

c大有0.195的帧切片版本的mame，没有试过。
现在这种技术怎么弄都是接近实机的下一帧数输入反应。要么和实机相同，要么比实机慢一针。
还是期待mame的run ahead技术，目前不被支持，而且比frame delay 和frame slice省机能。
ra的垂直同步技术目前正在改进，到时候win版的ra也有了c大的gm的同步技术，延迟大大降低。

该用户已被禁言

yuuyuubaishu 发表于 2018-8-30 20:40
c大有0.195的帧切片版本的mame，没有试过。
现在这种技术怎么弄都是接近实机的下一帧数输入反应。要么和 ...

现在的USB上的摇杆芯片，说可以达到1ms延迟，实际效果真这么好？

还有一种USB to Jamma 或 PC to a JAMMA ，说延迟很低。。J-PAC什么的。。



那LPT打印并口还有必要么？

yuuyuubaishu

powerh3 发表于 2018-8-30 22:02
现在的USB上的摇杆芯片，说可以达到1ms内延迟，实际效果真这么好？

还有一种USB to Jamma 或 PC to a JA ...

lpt打印机口延迟大概2.5ms左右，没有brook品牌的1ms芯片表现好，老外评测过的，看来lpt被神话。
你可以找下lpt switch的资料，直接lpt接摇杆和按钮，都不用芯片的，性价比极高，表现还好。
360的芯片统一表现为4ms延迟，无论是什么品牌芯片，估计微软的xinput驱动就是这副德行。
国内的苍炎格斗芯片表现不错，和brook四合一的那个芯片差不多。
1ms的那个usb摇杆芯片已经到极限了，只有从模拟器和显示器上面入手减少延迟才是大方向

该用户已被禁言

yuuyuubaishu 发表于 2018-8-30 22:10
lpt打印机口延迟大概2.5ms左右，没有brook品牌的1ms芯片表现好，老外评测过的，看来lpt被神话。
你可以找 ...

1ms，已经够了。。。1000分之一秒，人类应该感觉不到差别了。。1秒刷60帧的一帧是16.67ms。

LPT Switch是直接接在LPT口上，然后装上驱动就行？。。国内找不到啊。。


我还有两套LPT口转PS手柄的转换器，和这个LPT Switch原理类似吧。。也是直接接，不用芯片，然后上手柄驱动即可。。