If the dot crawl alternates between two fields rather than the usual four, "smart" deinterlacing algorithms as found in progressive TVs will detect the area as static. It doesn't have so much to do with the fact that the screen is progressive, as it does with the screen's internal signal processing. If you were to simply "dumb bob" the signal, it would still crawl just like on a real interlaced display.
The progressive dispalys i'm talking about are A) a commodore 1702 composite monitor. [noparse][/noparse] every video capture card i've ever gotten my hands on. On the composite monitor, there is no bobbing at all, and no dot crawl. But different video game systems display very annoying artifacts. The NES phase shifts the colorburst. and it's output is full of highly visible diagonal lines. The Genesis doesn't do this. Instead you get thin vertical streaks everywhere that looks very ugly. The TG-16 and the jaguar often have a "monitor mode" toggle" in the games. I strongly suspect that this toggle is whether or not the colorburst is messed with. Monitor mode ON always looked better on the monitor.
Oh. If you're talking about CRTs, TVs and home computer monitors are equal-- they both display 240p. That is to say, your NES might output NTSC, but it will be progressive by nature of the signal (not the monitor). Modern progressive TVs don't "know" 240p and treat it as 480i, with the deinterlacing behaviour I described above. Interesting.
This monitor is a simple job. On the back it takes separated luma and chroma, and mono audio. effectively a form of svideo i think. This gives a clear, artifact free display from an 8 bit computer with composite out. No diagonal lines, no nothing. pure perfect 60fps (about) progressive. On the front it instead takes standard yellow/red mono composite, which the NES can output. On CRT tvs, the composite output of a NES is subject to dot crawl. On the 1702, it is not. it's a potluck which way the artifacts end up. The difference is readily visible on the super mario bros title screen. the mushroom by 1 player game will look either rounded OR angular at the top. perhaps the monitor has a dot crawl remover? PS: you want a game that really abuses NTSC, try True Pinball for ps1. it actually offsets the entire picture horizontally every other field to try and make everything line up perfectly. problem is it gets it wrong 50% of the time, and then you get a flickery double image. but once the table is loaded, if it is synched it stays synched.
Sounds like a comb filter, yes. I'd wager that when Mario starts moving and the screen scrolls, dot crawl shows up again (but it might appear static because of the scrolling).
Perhaps it's simply because it's a native ntsc crt, but i've never seen any combing on the display ever, as opposed to the usual result with a capture card. It's been a while, but as I recall the diagonal lines are completely static, provided there's enough space to see them, so scrolling causes a barber pole effect.
A common misconception. A comb filter actually has nothing to do with combing artifacts (interlaced weaving). It's the name given to a type of filter with a comb-like frequency response. http://en.wikipedia.org/wiki/Comb_filter
Better late than never! http://www.mametesters.org/view.php?id=4662 and http://www.mametesters.org/view.php?id=4663 I also want to report more graphical bugs in TGM1, but the guidelines prevent me from doing so because the game is flagged for inaccurate emulation. It seems kind of counter-intuitive to prevent people from reporting bugs on something when the game is broken and nobody is doing anything about it. A bit of circular reasoning going on there, if you ask me. EDIT: I ranted too soon. I've been given the go-ahead to file the TGM1 graphics glitches: http://www.mametesters.org/view.php?id=4664 http://www.mametesters.org/view.php?id=4665 http://www.mametesters.org/view.php?id=4667
TAP is fixed! Woohoo! I'll see if I can compile a new version of MameTGM based on 0.158. TGM still needs to be fixed, but the difference is much smaller there.
The question isn't ever "is there lag?" - it's "how much lag is there?". Even with the PCB and arcade hardware and a CRT there's still input latency. Shmupmame usually gives another frame or two of lag compared to the PCB, with regular MAME another frame or two on top of that the last time things were measured I don't think anyone has explicitly re-measured with a high framerate camera for the new MAME version, but given that historically it's always been worse and I've not heard any song and dance about it being fixed, I don't see any reason to assume it's better. Would probably no longer be all that easy to intuitively try and detect if it's laggier with just how it feels, now that they're no longer running at the same game speed.
I feel like regular MAME is better than it used to be. I only really notice the delay when I get to 300 or 400 in Death.
This is the only real alternative to a PCB. Dedicated 15khz CRT version of Mame. The AMAZING GroovyMame + CRT_Emudriver. http://forum.arcadecontrols.com/index.php?topic=133194.0
Or maybe it just feels slightly more responsive because the frames themselves are shorter. That's probably it.
