 No.07594
Fujix Administrator
Jun 30, 2011, 01:14
edited on: Jun 30, 2011, 01:39
|
Probably because nobody has had your issue until today, nobody has reported it. It doesn't reporduce at all in any conditions (full screen, windowed, combination of some options, 1920 x 1200 display). What do you mean with "tearing" for? Usually we say the "tearing artifact" for a scrolling background and it is caused by the difference between a display refresh rate and in-game one. Does your ship disappear or blink when accelerate it? Or vector components of the ship breaks up? |
|---|---|
 No.07601
biobern Tester
Jun 30, 2011, 12:40
edited on: Jul 1, 2011, 10:52
|
I know it's very hard to describe the 100s kinds of tearing/jerking. That's why I did not report the bug earlier. But yesterday I tried out which was the last MAME version without this bug and now I report it. The objects do not disappear, but kinda make a bigger step every 0.7 second or so (I used a stop watch and counted about 30 bigger steps in 20 seconds). You can see this best if an object moves fast (like your fully accellerated ship). Yes, it looks as if the game refresh rate would not match the display refreh rate. But that should not be a problem in asteroids, right? BTW: I spent hours and days in the last years fiddling with vsync, triplebuffer, syncrefresh and refreshspeed. :-( The effect appears always since many years on different PCs, XP and Windows7 32bit, windowed or fullscreen. I really hope someone will fix this before the beautiful HLSL-vectorglow appears to enlighten us... :-) Bern |
|
No.07604
Fujix Administrator
Jun 30, 2011, 17:33
edited on: Jun 30, 2011, 17:33
|
I can't tell if your issue is a MAME bug or not so far, but I suspect it depends on your PC display or CPU speed or anything else. Because everything moves smoothly for me, I don't think up what is going on. Your PC spec, a movie of the display, verbose output and more may help us to seek out the cause of the problem, although, it will be a normal MAME question as seen in the MameWorld forum.. What is your CPU and graphic board? Using CRT or LCD? How is your mame.ini? Also, please try clean setup and play. |
|
No.07605
biobern Tester
Jun 30, 2011, 21:00
|
My PC spec at the moment: Core2Quad@2.4Ghz Monitor: Dell 2709 LCD@1920x1200 Nvidia Geforce 250 Asteroids emulated with MAME up to 0.108 or AAE runs very smooth. I tried every kind of different mame.in-files, I also re-installed MAME many times in the last years to have a clean mame.ini. Don't you think that a movie will be rather useless, cause the movie's 25 or 30 images per second cannot reproduce the tearing? I will also try a different monitor tomorrow, but a friend of mine claims to have the same tearing problems on his CRT monitor. Cheers Bern |
|
No.07607
Fujix Administrator
Jul 1, 2011, 04:23
|
"tearing" is an obscure word to describe the situation, none of us imagine what is happening exactly only with it, so we cannot do anything. Please provide anything that will visualize and help others to understand what's happening. When we don't know the cause of the problem, we have to eliminate every possibility one by one. We need objective information such as -verbose output. To be honest, I think this is 99% not a MAME bug. A lot of people have tested vector games since 0.108, if there were an obvious problem caused by MAME core, some of us should have had reported it at the head. To overcome this situation, you have to prepare informative materials for your report whatever possible. |
|
No.07608
biobern Tester
Jul 1, 2011, 10:02
|
OK, here is my "verbose". Can you see something unusual in it? C:\neu\mame>mame asteroid -verbose Parsing mame.ini Parsing mame.ini Video: Monitor 002F0305 = "\\.\DISPLAY1" (primary) Direct3D: Using Direct3D 9 Direct3D: Configuring adapter #0 = NVIDIA GeForce GTS 250 Direct3D: Using dynamic textures Direct3D: YUV format = RGB Direct3D: Device created at 1920x1200 Direct3D: Max texture size = 8192x8192 DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels RawInput: APIs detected Input: Adding Mouse #0: Logitech Marble Mouse (USB) Input: Adding Gun #0: Logitech Marble Mouse (USB) Input: Adding Mouse #1: HID-konforme Maus Input: Adding Gun #1: HID-konforme Maus Input: Adding Kbd #0: Standardtastatur (PS/2) Input: Adding Mouse #2: Logitech Marble Mouse (USB) Input: Adding Gun #2: Logitech Marble Mouse (USB) DirectInput: Using DirectInput 7 Starting Driver Device 'root' (missing dependencies; rescheduling) Starting M6502 'maincpu' Starting Video Screen 'screen' Starting Speaker 'mono' (missing dependencies; rescheduling) Starting DISCRETE 'discrete' Starting Driver Device 'root' (missing dependencies; rescheduling) Starting Speaker 'mono' Starting Driver Device 'root' Average speed: 100.01% (17 seconds) |
|
No.07609
biobern Tester
Jul 1, 2011, 10:36
edited on: Jul 1, 2011, 10:44
|
Maybe I should say "jerking" instead of "tearing". My english is not perfekt, sorry. OK, I just verified the jerking in my MAME cabinet _again_. I normally emulate Asteroids with AAE there because of the jerking problems. Result: Jerking very visible if you accellerate your ship! Hardware of my MAME cabinet: Cheap AMD Sempron@2.7 Ghz Old, very bright IBM CRT Monitor from the year 1990@640x480 Geforce 9500 GS Windows XP slimmed down with "nlite" "Verbose" of my MAME cabinet: C:\mame>biomame-amd64 asteroid -verbose Parsing mame.ini Parsing mame.ini Parsing vector.ini Video: Monitor 00010001 = "\\.\DISPLAY1" (primary) Direct3D: Using Direct3D 9 Direct3D: Configuring adapter #0 = NVIDIA GeForce 9500 GS Direct3D: Using dynamic textures Direct3D: YUV format = RGB Direct3D: Device created at 640x480 Direct3D: Max texture size = 8192x8192 DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels RawInput: APIs detected Input: Adding Mouse #1: HID-compliant mouse Input: Adding Gun #1: HID-compliant mouse Input: Adding Mouse #2: HID-compliant mouse Input: Adding Gun #2: HID-compliant mouse Input: Adding Kbd #1: HID Keyboard Device Input: Adding Kbd #2: HID Keyboard Device DirectInput: Using DirectInput 7 Adjusting target speed to 99% (hw=60.00Hz, game=60.00Hz, adjusted=59.40Hz) Average speed: 99.01% (11 seconds) Sound: buffer overflows=1 underflows=0 |
|
No.07610
AWJ Developer
Jul 1, 2011, 11:30
edited on: Jul 1, 2011, 11:54
|
I don't fully understand vector hardware, but as far as I can tell this is "working as expected", and not really a bug... In 0.108u5, the vector emulation was rewritten and the CPU and interrupt frequencies in the driver were updated to accurate values based on the actual crystal on the board. The CPU is now getting NMIs at (12.096MHz / 4096 / 12) = 246.1 Hz (it used to be an even 240 Hz) I'm assuming the game program updates the position of the player's ship once every four NMIs, or 61.5 Hz. Since the (raster) monitor is refreshing at 60 Hz, you get a "beat" every 1 / (61.5 - 60) s, or 0.66 s, where the game program moves the player's ship twice before the simulated vector display is redrawn. I'm not sure if there's any way to "fix" this. Even if you changed the REFRESH_RATE in the driver to 61.5 Hz, I don't think many video cards or monitors (especially modern LCD monitors) can sync at such an odd (for a raster-based display) refresh rate. Also, the correct term for this sort of visual artifact is "juddering", not tearing. |
|
No.07615
biobern Tester
Jul 1, 2011, 15:40
|
Thanks AWJ, your explanation is very feasible. A jump every 0.66s is exactly what I measured with my stop watch. So it seems that this is another example for MAMEs "looks totally wrong, but is emulated perfectly"-philosophy. (Another example for this philosophy is that the shoots in Asteroids became even smaller and less visible, i think somewhere between 0.107 and 0.108. But I'm pretty sure that everybody at MAME would say "It's not a bug, it's a feature"). But after all, Fujix, I'd still call this a bug, cause "refreshspeed" does not work here to avoid the juddering. And it really should, right? I mean, really, this "feature" makes some games nearly unplayable on large high resolution monitors IMHO...... Cheers Bern |
 No.07616
Tafoid Administrator
Jul 1, 2011, 16:03
|
To be fair, the -refreshspeed behavior has been suspect for a couple revisions (since 0.139u3) and there is a bug currently in for issue related to that command - 04396 |
|
No.07617
Fujix Administrator
Jul 1, 2011, 17:18
|
As long as we don't use the original arcade vector monitor, what we look at is expedient. -refreshspeed is broken now although, the 61.5 hz game won't work "correctly" on a 60 hz monitor for you. Even when -refreshspeed is fixed, and you get what you were looking for, others would complain about the incorrect sound pitch with refreshspeed enabled. Do you still think it is a bug of MAME too? It is not a malfunction nor a fault of MAME. That's the way emulation works. |
|
No.07618
biobern Tester
Jul 1, 2011, 18:08
|
Fujix: I'd be perfectly fine with a slightly incorrect sound pitch, cause it does not destroy my eyes. ;-) Tafoid: I just tested 0.135 with (waitvsync or triplebuffer) and refreshspeed and the juddering is still there! Maybe it's slightly better, I don't know. By far the best solution would be to go back to the pre 0.108u5 driver. But I am just dreaming.... :-) BTW, speaking of an arcade vector monitor: I just purchased an original Asteroids at ebay. YES!!! Lucky me!!! No more juttering!!! :-) Bern |
|
No.07620
Fujix Administrator
Jul 2, 2011, 03:30
|
You are always on your selfish purpose, won't understand what I mean. Sorry but I'm tired to provide generous customer service for you.. Please remember that MAME is not a commercial product for general users, it seeks out the correct internal behaviours, and not for the sake of your playing experience. This consistent principle has made MAME unique and alive. |