I’m convinced Mario is a hobo.
He wakes up everyday in the same clothes, runs around in sewers, and collects coins for a living.
At the end of the day, he uses the coins to buy mushrooms
Disabling vsync means that scrolling doesn't look well anymore.
But however, it's not about lagging per se. The thing that confuses me: It seems that the same game on the same MAME version with the same options lags more in Direct3D than in DirectDraw. Is that really the case and if yes, why is it like that?
By the way, did anybody ever make some tests about lagging in MAME? Checking how many frames MAME needs to respond on a monitor set to 60Hz according to various options: Vsync enabled/disabled. Double buffering enabled/disabled. DirectDraw/Direct3D. Game that runs on - 60.0 Hz (like "Vs. Super Mario Bros.") - 59.x Hz (like "Street Fighter II") - 60.x Hz (like "Pac-Man")
OK, seriously: How come that my last few posts were pretty much ignored? When I registered here and asked a question, I always got an answer pretty quickly. But since a certain time, whenever I ask anything (except for that short answer in this thread) it's completely ignored. Even though the questions that I ask (like input lag or color palettes) should be quite easy to answer for people who know MAME well enough. Did I do anything to piss you off or why do you suddenly ignore every single thread of me?
> Input lag in MAME is a subject with a certain history, that's just begging to turn > into a shitstorm.
Why? It's something that can objectively be measured. It's not anything that has to do with a personal opinion, so how can this be a controversial topic?
> Why? It's something that can objectively be measured. It's not anything that has to > do with a personal opinion, so how can this be a controversial topic?
Yes. There was some moron who complained about input lag without providing any real details and then everything went into a flamewar. And? Does that mean that we can never talk about this topic anymore?
Especially since my intention is not to complain in general that MAME input apparently lags. I just want to talk about the different settings that can influence the amount of lag. So, I don't want to talk about input lag as an absolute thing, but about the amount of input lag that is relative to various options.
For example, if your monitor's Hertz rate equals the one of the game (like 60 Hz), then triple buffering will always produce lag. That's not flaming, that's not insulting or a subjective view, it's a fact: If MAME renders two more images in memory while displaying a scene, then the game will always be off by at least two frames. If in a game you run toward a cliff and jump in the last possible moment, with enabled triple buffering you will fall off the cliff. Because the image you see on the screen is the one that was rendered two frames ago and is only visibly shown now. That's why the input will always appear to be delayed. If you disable triple buffering, you won't get this because the current scene is drawn to the game instantly.
And now I wanted to talk about what other issues might influence the amount of lag. I even did some measurements about it and wanted to hear your opinions. So, I'm not just making things up, I actually tested the input lag with fairly objective, reproducable methods and I thought that maybe someone might be interested in it.
There are several brutal rapes of the MAME codebase floating around in the name of reducing lag; this does not improve the reputation of people who wish to talk about the subject, however honestly.
Basically it's a long-running shitstorm with a lot of history fueled by peoples' varying psychological perception (different people have wildly different thresholds as to what feels wrong). Smart people stay far, far away.
> There are several brutal rapes of the MAME codebase floating around in the name of > reducing lag; this does not improve the reputation of people who wish to talk about > the subject, however honestly.
That's why I don't want to talk about the lag in itself, but about the question what options produce more lag compared to other options. Like if mame is the basis, how much does mame -triplebuffer lag in comparison to the base options?
> Basically it's a long-running shitstorm with a lot of history fueled by peoples' > varying psychological perception (different people have wildly different thresholds > as to what feels wrong).
That's why I measured the input lag with reproducable means. That has nothing to do with individual perceptions.
> Smart people stay far, far away.
If people aren't able to discuss it on a factual level, then they're probably not as smart as you might think. That's like saying: "There are many political nuts in the world, so smart people stay far, far away from discussing politics."
I've never seen anyone figure out all the best settings to reduce it meaningfully. If you figure it out let us know but I don't think anyone here has figured it out, thus you not getting an answer. People who are serious about it being an issue with certain games often buy the real pcb and play on a crt monitor or use hacked mames like shmupmame. Also sometimes the real game boards had it, though not often.
> I've never seen anyone figure out all the best settings to reduce it meaningfully. If > you figure it out let us know but I don't think anyone here has figured it out, thus > you not getting an answer.
Well, as I said: It's not about reducing input lag from an absolute point of view. If someone thinks that the games already lag with the default settings, then I can't help him either. What I was referring to: If we take MAME with its default options as the basis, how will other options increase input lag?
An example: If you say that mame suprmrio plays fine for you, input-wise, but you want to remove the tearing when the game scrolls, then you might ask yourself what options to set without adding input lag. And that's what my tests were about.
My results:
If you have your screen set to 60 Hz and play "Vs. Super Mario Bros." (which is also set to 60 Hz) and Mario stands on the ground and you press the jump button, then it will take 3 frames until he jumps. So, from pressing the button to the first jumping animation on the screen it's 3 frames. That's our basis. And now we see how many frames the whole procedure needs with additional options.
At first: Don't use triple buffering. Triple buffering is deadly. Using triple buffering adds 2 to ~3.5 frames to the general 3 frames before the output reflects the input. As I said above (and if I've understood triple buffering correctly), that's natural: If you render two screens in memory before displaying them, the visible output is always two frames behind the actual game scene. Even the most perfect hardware cannot do anything against it: If MAME shows scene 1 while rendering scene 2 and 3 in memory, then the input will refer to scene 3 while you are seeing scene 1 on the screen. That's why you shouldn't use triple buffering. Input lag is an integrated part of it and my tests confirmed it.
The other option to remove tearing: vsync. Here, it is a bit strange: If you use Direct3D, vsync will produce about ~3.3 additional frames. (So, since the duration without any options is 3 frames, with vsync in Direct3D, Mario will take ~6.3 frames until he jumps.) But if you use vsync with DirectDraw, then the lag will merely be ~0.3 frames, i.e. less than a single frame on average.
I don't know why that's the case. I don't know why vsync in Direct3D lags so much more than vsync in DirectDraw. My PC is from 2010, an Intel QuadCore, 2.33 GHz, 4 GB RAM, which should be more than enough to run MAME smoothly, so it's probably not the hardware. I even checked the stuff with MAME 0.127 from 2008. It must be a Direct3D issue. I also noticed input lag in the NES emulator Nestopia when vsync is enabled while there doesn't seem to be any noticable input lag in FCE Ultra. And guess what: FCE Ultra is DirectDraw, Nestopia is Direct3D.
Conclusion: If you want to play a game without tearing when the game scrolls and without relevant input lag, the best option is mame -video ddraw -waitvsync -notriplebuffer Triple buffer always lags. And Direct3D lags if you combine it with vsync. Vsync with DirectDraw is almost as good as with standard options.
How did I measure it? Quite easy. Everybody can do this and check the results for himself: You need a video camera that can shoot videos with 60 FPS. Set your monitor to 60 Hz. Start MAME with "Vs. Super Mario Bros." (or any other game you want to check) and map the jump button (or whatever button you need) to either the Num Lock, Caps Lock or Scroll Lock key. Those are the keys that are connected to a small LED on the keyboard. Now position the video camera in a way that the keyboard LEDs and Mario on the screen are in good view. Record it and let Mario jump a few times. And now watch the video frame by frame. As soon as the LED starts glowing, count the frames to see how long it takes from the keyboard physically registering the key press to the first jump animation. That's it.
About the relationship between MAME and an actual arcade board: Well, you would need an input device with an LED and could do the same. I don't know if "Super Mario Bros." on an actual arcade board or on an NES would need three frames from button press to output or if it reacts even quicker. But that's something that someone who owns this stuff and who knows how to connect an LED to a controller could find out quite easily. That's why I don't really understand how there can be so much controversy about it. Get a camera, put it to 60 FPS and then record the screen and your input device LED. Do this 20 times and you should have quite a reliable average value which you could check against MAME. Then you know if the complainers are right or if they just imagine an input lag. This guy did it with the PlayStation "Street Fighter" games and he's the one where I got the method from: www.youtube.com/watch?v=JoJzobmdGzU
Regarding D3D, was that on an ATI/AMD Radeon card? Those currently have a series of 3D driver bugs which causes framerate wobble (also called "micro-stuttering") and other anomalies when recorded with a high-speed camera.
> Regarding D3D, was that on an ATI/AMD Radeon card?
Indeed, it's an ATI Radeon HD 4550.
> Those currently have a series of > 3D driver bugs which causes framerate wobble (also called "micro-stuttering") and > other anomalies when recorded with a high-speed camera.
Just to make this clear, so that there are no misunderstandings: While recording, the camera was not connected to the PC. It had nothing to do with software that does screen grabbing or anything like that. I just held the camera in the screen's direction and filmed my monitor and how I press a key on the keyboard. I'm a bit confused because you specifically mention the anomalies in the context of recording instead of just saying that there are bugs in general. So, do you just mean: "The drivers have bugs that are noticable when recording the screen with a high speed camera" or do you mean: "The drivers have bugs when a high speed camera is connected to the PC and something is done with the camera"? Because the latter is not the case. I just did the same stuff as the guy in the video: Just manually filming the monitor in my room.
If you were speaking generally: Are there any ways to fix those bugs? Anything to remove the ATI-Diect3D-specific lag, so that vsync in Direct3D works like vsync in DirectDraw?
Microstutter is a phenomenon where the time between frames doesn't remain even. It actually doesn't have anything DIRECTLY to do with a camera, but I'll explain what RB meant after I define Microstutter a little better:
At 60FPS, every frame should be 16.666~ms apart. (1000ms/60frames=16ms/frame)
So, your frames should look like:
16ms, 16ms, 16ms, 16ms, 16ms, 16ms..
Microstutter will exhibit situations where MAME and other games will show 50FPS, but the time between varies like this:
8ms, 8ms, 8ms, 8ms, 24ms, 8ms, 8ms..
As you can see, they're not evenly interspersed. It will cause the game to not look fluid at all.
It's a known issue with ATi's drivers. While it hits SLI cards particularly bad, I do not believe it is limited to SLI. It seems to be able to hit any card from the last year or two that ATi has put out.
Now, RB was telling you that it's particularly noticible with a camera; this is because the high speed camera picks up the differences in the frame timing extremely well. It has nothing to do with screen capture. just the nature of recording off an uneven source.
Also, I hate to break this news to you, but most of your findings will only be applicable to you in the end. There are a lot of factors that affect input lag, but the one thing you cannot actually control are video driver issues. I know of at least one issue with nVidia drivers, or instance, that will trigger insane amounts of input lag on a completely inconsistent basis and may even cause multimonitor MAME to refuse to take input at all if VSync is turned on with some versions of nVidia's drivers.
These uncontrollable factors make it impossible to actually come up with a single relevant lag test for every combination of OS, video card, and setting.
> Also, I hate to break this news to you, but most of your findings will only be > applicable to you in the end. There are a lot of factors that affect input lag, but > the one thing you cannot actually control are video driver issues. I know of at least > one issue with nVidia drivers, or instance, that will trigger insane amounts of input > lag on a completely inconsistent basis and may even cause multimonitor MAME to refuse > to take input at all if VSync is turned on with some versions of nVidia's drivers. > > These uncontrollable factors make it impossible to actually come up with a single > relevant lag test for every combination of OS, video card, and setting.
Well, that just means he has to have a large number of OS's and video cards and video drivers at his disposal for benchmarking
To be fair I think his solution thus far for objective measurement is pretty creative...
> I'd test it with an NVidia card and if that doesn't suffer from direct3d vsync lag > then report the problem to ATI.
ATI is promising to have the issues fixed for single-card configs in the July timeframe and multi-card setups in the Fall. On the positive side, they said several of the contributing bugs were also wasting frame time, so once everything's fixed up the cards will perform better for free.
> To be fair I think his solution thus far for objective measurement is pretty > creative...
Nvidia released and open-sourced a measurement tool for it: there's a Fraps mod that timestamps each frame by adding a small flat-color rectangle (and changing the color each frame), and then you use a high-speed framegrabber to capture and check if the flat color changes with the correct timing. (Unsurprisingly their own cards don't have the problem, including in SLI).
Thanks for posting this article. However, after reading it, as far as I understand, it's talking about 3D stuff, like any other article on graphic cards these days. So I'm not sure if this would apply to MAME, where all rendering is 2D-based, so there shouldn't be major differences on gpu requirements between frames.
I'd say that what the OP is seeing is the effect of ATI's flip queue size, so that the drivers are rendering some frames ahead without even asking. Nvidia drivers do something similar. There was a program named ATI Tray Tools that allowed you to tweak the "FlipQueueSize" value. I don't know the situation with current drivers, but back in Cat 9.3 the minimum value for FlipQueueSize was hardwired as 2, according to the disassembly of the drivers. Provided this was the issue, it's interesting, however, that according to the OP's tests this only seems to apply to Direct3D, not DirectDraw. It would be good to know the exact OS and drivers versions for these tests.
On the other hand, you have the well known triple buffer issue, which is not MAME's fault but a DirectX feature: DirectX arranges back buffers in a circular queue (sequential), rather than a proper triple buffering model. A good explanation for this is here: http://www.anandtech.com/show/2794/4 (scroll down to the "UPDATE" section).
EDIT: Microsoft does allow to drop frames in the queue in DirectX version 9ex on Windows 7, so a real triple buffer could be implemented nowadays.
> Thanks for posting this article. However, after reading it, as far as I understand, > it's talking about 3D stuff, like any other article on graphic cards these days. So > I'm not sure if this would apply to MAME, where all rendering is 2D-based, so there > shouldn't be major differences on gpu requirements between frames.
MAME's usage of D3D and OpenGL is indistinguishable from "3D stuff"; we are submitting textured triangles, with shaders attached in the HLSL case, at varying Z depths. So yes, any "3D" driver bug is also applicable to -video d3d.
All right, I understand. But you'll agree with me that microstuttering as described in the article wouldn't cause a consistent delay of 3 frames as reported by the OP.
> All right, I understand. But you'll agree with me that microstuttering as described > in the article wouldn't cause a consistent delay of 3 frames as reported by the OP.
Depends on the OP's exact methodology, and what bugs cause longer frame times in the driver. I agree in general it's unlikely to skew it that far, but you never know.
Thanks for all the answers. I feared that nobody will be interested, but it's nice to see that so many people contribute to it.
@R. Belmont:
Now that I've understood microstuttering a bit better thanks to Firehawke, I doubt that this is the phenomenon in my case. As Calamity already said: The delay is pretty constant. For Direct3D I did it 20 times, 10 times with SMB and 10 times with SF2. And it was always a pretty constant rate. Also, is microstuttering limited to vsync and triple buffering? Because without that, Direct3D works perfectly fine.
Another interesting thing: I believe that Direct3D and vsync work fine in windowed mode. Only in fullscreen do I feel a delay. In the moment it's just a feeling, but I will do more tests about it. Last time I only used fullscreen mode, so this time I will check with window mode also. That means my next tests will be: Direct3D with no filter, with vsync and with triple buffering in fullscreen mode (for reference purposes and to see that the results are still the same as last time) Direct3D with no filter and with vsync in windowed mode I won't do DirectDraw anymore because we already know that it doesn't produce lag on my system. And the combination window + triple buffer doesn't remove any tearing, so it's unnecessary. I will post the results as soon as I'm finished.
@smf:
> I'd test it with an NVidia card and if that doesn't suffer from direct3d vsync lag > then report the problem to ATI.
I will have access to an NVidia card in two weeks. I'll do tests with it too and post it here. Additionally, I can check the stuff on an Intel card.
> Thanks for all the answers. I feared that nobody will be interested, but it's nice to > see that so many people contribute to it. >
well im grateful for your thread because i went off and did some tests of my own with the game galaga'88 (which regardless of mame settings already has a delay of 4 frames when you move your ship left or right*)
.... so, i did some tests (note: fullscreen tests only, both directdraw and direct3d were tested) with galaga'88, first of all using just vsync, and then just triple buffer.
the game plays as normal with vsync on (ie. i personally didnt notice a difference with vsync turned on or off). however, triple buffer is a different story. moving the ship left and right with triple buffer on was not good. you can really feel (and see) the input lag when you move your ship left and right.
so, i for one am gonna stick with vsync from now on.
ps. tests were done under winxp 32bit, basic onboard intel gma gfx (laptop). i tested both directdraw and direct3d, and got identical results.
> well im grateful for your thread because i went off and did some tests of my own with > the game galaga'88
How did you do your tests? The same way I did it?
> .... so, i did some tests (note: fullscreen tests only, both directdraw and direct3d > were tested) with galaga'88, first of all using just vsync, and then just triple > buffer.
Did you also do tests without vsync and without triplebuffer to have a basic refernce value?
> however, triple buffer is a different story. moving the > ship left and right with triple buffer on was not good. you can really feel (and see) > the input lag when you move your ship left and right.
Yeah, triple buffer as implemented in Direct3D seems to have inherent lag due to the method of pre-rendering frames. If a game renders two additional frames while displaying one, that means the one displayed is always two frames behind. I don't know why anybody would ever use this option.
> ps. tests were done under winxp 32bit, basic onboard intel gma gfx (laptop). > i tested both directdraw and direct3d, and got identical results.
Since I have different results with Direct3D and DirectDraw and you don't, I guess I'll do some more thorough tests with my card, installing the ATI tools and seeing if I can influence the lag with Direct3D and vsync somehow.
> How did you do your tests? The same way I did it?
no, i dont have any special equipment, but even so i can see/feel more lag in galaga'88 at normal gameplay speed if i have triple buffer turned on
> Did you also do tests without vsync and without triplebuffer to have a basic reference > value?
yes, and i didnt notice a difference (using both direct3d and directx) with vsync turned on or off. so, if vsync is adding any lag, im guessing it isnt more than 1 frame at worst (which my eyes are not good enough to pick up!)
ps. i havnt done extensive testing of vsync yet, as i have always used triple buffer. does anyone know, is vsync as reliable as triple buffer on modern pc's, when using CRT tv's/monitors ? ie. with vsync do you still get the same smoothness of triple buffer with no stuttering/tearing etc? ... or instead if there are a number of advantages of triple buffer over vsync id be interested to hear 'em
Vsync is, as far as I see it, just as smooth as triple buffering. No tearing or stuttering. I haven't seen anything that triple buffering can that vsync can't. Assuming of course that the refresh rate of your monitor approximately equals the one in the game. If you set your monitor to 75 Hz and play a 60 Hz game, it will stutter, no matter what you do.
> > Assuming of course that the refresh rate > > of your monitor approximately equals the one > > in the game > > yea im cool there as i use mameuifx and force all games to run at 60hz anyway, via > the soundsync feature (im using a standard crt tv, ntsc 60hz)
That would also be why you get different results from the OP.
OP: Please ignore his "data" - you'll notice it's entirely by subjective "feel" anyway, plus he's using UI (not endorsed by MAMEdev) FX (*really* not endorsed by MAMEdev).
Yesterday, I did some more tests. And it's true what I assumed: Direct3D with vsync lags only in fullscreen mode. If I use windowed mode, the results are fine.
Is there any reason for it that you can think of?
I guess it doesn't have anything to do with micro stuttering because my results are always pretty constant. And apart from triple buffering, which already lags by design, the only combination that doesn't produce results that are alright is Direct3D/vsync/fullscreen. The other combinations, DirectDraw/vsync/fullscreen, Direct3D/vsync/window and anything without vsync is o.k.
Unfortunately, Direct3D/vsync/fullscreen is exactly the configuration I want to use. Vsync prevents tearing. And with DirectDraw you can't use all that artwork stuff properly, so it should be Direct3D. And fullscreen of course so that I don't have the windows borders and part of my desktop visible.
I looked in the ATI control center to find some options, but there was nothing that helped me. Then I downloaded the ATI Tray Tools and looked for the flip queue size option. But it was already preset to 0 anyway. And even setting it to the highest value didn't make a difference, so it didn't make it worse either. I also downloaded the latest drivers for my graphic card from the ATI website, but it's still the same.
Today I wanna see if Nestopia has the same phenomenon: That vsync lags only in fullscreen mode. And then I want to try out the old MAME version, 0.106, with the old rendering system, to see if there are any differences. Also, I will try MAME with DirectX set to version 8. Let's see if this makes a difference. On Monday, I can try an Intel card and next weekend, I can try an nVidia card, even though it's an older one.
But in the meantime, I'm grateful for every suggestion where the lag in this specific combination might come from. Alternately, if you can tell me a workaround to run MAME in window mode, but still have all of the unused parts of the screen that aren't used blacked out, this would also work.
> Yesterday, I did some more tests. And it's true what I assumed: Direct3D with vsync > lags only in fullscreen mode. If I use windowed mode, the results are fine. > > Is there any reason for it that you can think of?
It may have to do with how the D3DPRESENT_INTERVAL_ONE parameter behaves in full screen mode for that combination of OS & drivers. What OS are you using to run these tests?
If this is the case, and the drivers are creating an undesired flip queue internally, then there's nothing that can be done from MAME's side, as long as D3D v-synced flipping is used (D3DPRESENT_INTERVAL_ONE).
You'll likely see different windowed behavior between XP and Vista/7/8, given the newer OSes use D3D to draw the desktop and (as far as I know) enforce Vsync while doing it.
> I use Windows XP for this. > > If the D3DPRESENT_INTERVAL_ONE issue is really the problem, can this be changed > globally for the ATI card or for DirectX?
I'm afraid there's nothing that can be done. Well of course you can force v-sync off from the control panel but that defeats your purpose.
Anyway, in case you wanted to test, I can compile a MAME binary that bypasses the normal D3D flip method by manually waiting for v-sync and then using D3DPRESENT_IMMEDIATE. Do you need 32 or 64 bits?
> Anyway, in case you wanted to test, I can compile a MAME binary that bypasses the > normal D3D flip method by manually waiting for v-sync and then using > D3DPRESENT_IMMEDIATE. Do you need 32 or 64 bits?
Hi again. I'm just compiling MAME by myself, so you don't need to bother to make a version for me.
Well, I've been doing some tests and for the life of me I can't get a reliable vsync in D3D without using the standard D3DPRESENT_INTERVAL_ONE present method.
I do get good results with a CRT and native (low) resolutions with D3DPRESENT_INTERVAL_IMMEDIATE after manually waiting for vsync, but as soon as I test this on a LCD or a CRT at higher resolutions I start getting static tearing by the top of the screen. I guess these functions are not fast enough to catch vblank reliably unless you use the encapsulated Present method, too bad.
Anyway, I've attached the patch in case you want to test. Just use -waitvsync with the rest of standard settings. If you want smooth scrolling at any refresh make sure to add -nothrottle -nomt.
if (video_config.waitvsync || video_config.syncrefresh) etc.
In my version, I just replaced the D3DPRESENT_INTERVAL_ONE in d3d->presentation.PresentationInterval = ... with D3DPRESENT_INTERVAL_IMMEDIATE and that's it.
Isn't -nothrottle the stuff that lets the game play as fast as it can so that, on a good PC, you see the game like if you did fast forward?
That code is an attempt to v-sync right before displaying the new frame. If you just switch D3DPRESENT_INTERVAL_ONE to D3DPRESENT_INTERVAL_IMMEDIATE, it won't perform any sort of vertical synchronization (lots of tearing), it's just the same thing as if you run MAME without -waitvsync.
The interest of this test is to check whether making the v-sync external to the D3D Present method bypasses the ATI built-in flip queue or not. It's just an experiment, because this patch doesn't provide a reliable v-sync method for most machines/setups.
Yes, using -nothrottle makes the emulation run full speed, but if you have a reliable v-sync enabled then this one locks the speed at the video card's refresh.
Well, the good news are: The patch actually works on my system. Again, I changed the versions back to back:
mame suprmrio -waitvsync still just reacts after 6-7 frames as always.
mame_patch -suprmario -waitvsync with your new source code reacts after 3 (and sometimes, but rarely, 4) frames, just like the DirectDraw vsync and the Direct3D window vsync.
The bad news: Yes, I see the tearing. It's only on top of the screen (unlike without vsync where it's all over the screen), but it's there.
What about the following idea? It's rather mundane, but it should serve its purpose:
As I said and as I tested again, in window mode, it works fine.
mame suprmrio -waitvsync -window doesn't produce any further input lag.
So, wouldn't it be possible to use the window mode, but in the way that the window is a boderless window of the size of the screen resolution? We don't give it borders or a title bar and we put it at position 0,0 of the screen. Its width and height equal the desktop with and height.
In this case, from a technical point of view, MAME would run in window mode and would circumvent the input lag in Direct3D/vsync. But visually, it would look just like fullscreen, so you don't need to see your desktop when playing a game. Is there any disadvantage to it? Except for the fact that triple buffering can't be used in window mode, is there anything that would be missing with such a solution?
> If you have your screen set to 60 Hz and play "Vs. Super Mario Bros." (which is also > set to 60 Hz) and Mario stands on the ground and you press the jump button, then it > will take 3 frames until he jumps. So, from pressing the button to the first jumping > animation on the screen it's 3 frames. That's our basis. And now we see how many > frames the whole procedure needs with additional options.
As another data point, I tested using a 60 fps camera on my Macbook Pro Retina with SDLmame 0.148. I couldn't use Vs. Super Mario Bros because apparently my ROM set is too old for that game. However, using Donkey Kong and 1943, I found that the time from the caps lock LED coming on to the first apparent on-screen action (first jump sequence frame, or first fired shot frame) was consistently 3 frames.
I also tried my desktop Linux system with an integrated AMD graphics card (on the motherboard) and SDLmame, can't remember what version, but a few versions old at least, and the delay was a consistent 7 frames.
I do wonder what the 'minimum' achievable delay is, I suspect it's not possible to do better than 3 frames; and I also wonder what the delay would be with the real hardware. It's quite possible that the game itself only samples inputs every 3 frames, or samples every frame but doesn't apply the action immediately for whatever reason.
> However, using Donkey Kong and 1943, I found that the time > from the caps lock LED coming on to the first apparent on-screen action (first jump > sequence frame, or first fired shot frame) was consistently 3 frames.
The important thing now is: How does it react when you use vsync in window and in fullscreen mode? Using it without any special options is just the base value. To check input lag, it's interesting to know how much longer it takes for vsync (and maybe triple buffer) in both, window and fullscreen.
> I also tried my desktop Linux system with an integrated AMD graphics card (on the > motherboard) and SDLmame, can't remember what version, but a few versions old at > least, and the delay was a consistent 7 frames.
That's much too long.
> I do wonder what the 'minimum' achievable delay is, I suspect it's not possible to do > better than 3 frames
From a purely software point of view you can easily test it: Pause the game, then press Shift + P + jump button. (That means: While in pause mode, MAME advances one frame and on this frame, the jump button is pressed.) Then continue pressing Shift + P (further frame advance) until Mario jumps. This way you can see how the game is programmed. In "Vs. Super Mario Bros.", it takes one frame to jump: If the moment where you press Shift + P + Jump counts as frame 0, then the jump occurs at frame 1. At the character selection screen of "Street Fighter II" it doesn't even take this one screen. Press the button and the fighter changes immediately, at frame 0. So, yes, the game itself on a software level reacts immediately.
However, this still doesn't explain how much it would take for an actual physical gamepad in real world time to send the signal. I'd be really curious if three frames is the actual delay or if the real arcade is faster.
One possible way to verify this: As far as I see it, the Vs. system is basically nothing more than an NES. Same with the PlayChoice-10. So, even if we don't have an actual arcade machine to alter, couldn't someone who knows a bit about that stuff connect an LED to an NES controller that lights when you press a certain button? Then the test could be done with the actual "Super Mario Bros." on a real NES. Then we can see if Mario needs three frames to jump or if the actual hardware is faster. The same results should apply for the arcade version.
> The important thing now is: How does it react when you use vsync in window and in > fullscreen mode? Using it without any special options is just the base value. To > check input lag, it's interesting to know how much longer it takes for vsync (and > maybe triple buffer) in both, window and fullscreen.
Have you played with the usb polling rate? It might not make a difference as MAME only reacts to inputs once per frame, but it would be interesting none the less.
> > However, using Donkey Kong and 1943, I found that the time > > from the caps lock LED coming on to the first apparent on-screen action (first jump > > sequence frame, or first fired shot frame) was consistently 3 frames. > > The important thing now is: How does it react when you use vsync in window and in > fullscreen mode? Using it without any special options is just the base value. To > check input lag, it's interesting to know how much longer it takes for vsync (and > maybe triple buffer) in both, window and fullscreen. > > > > I also tried my desktop Linux system with an integrated AMD graphics card (on the > > motherboard) and SDLmame, can't remember what version, but a few versions old at > > least, and the delay was a consistent 7 frames. > > That's much too long. > > > > I do wonder what the 'minimum' achievable delay is, I suspect it's not possible to > do > > better than 3 frames > > From a purely software point of view you can easily test it: Pause the game, then > press Shift + P + jump button. (That means: While in pause mode, MAME advances one > frame and on this frame, the jump button is pressed.) Then continue pressing Shift + > P (further frame advance) until Mario jumps. This way you can see how the game is > programmed. > In "Vs. Super Mario Bros.", it takes one frame to jump: If the moment where you press > Shift + P + Jump counts as frame 0, then the jump occurs at frame 1. > At the character selection screen of "Street Fighter II" it doesn't even take this > one screen. Press the button and the fighter changes immediately, at frame 0. > So, yes, the game itself on a software level reacts immediately. > > However, this still doesn't explain how much it would take for an actual physical > gamepad in real world time to send the signal. I'd be really curious if three frames > is the actual delay or if the real arcade is faster.
Well I also wrote a program that does nothing but print out what key was pressed the moment the key press is detected and that also took 3 frames from the caps lock LED coming on to the screen updating. However, my program was not optimized for lowest possible latency:
- It may be possible for a program to acquire user input events faster than the normal Cocoa event loop - possibly using more low level functions for watching HID events or something like that
- I defer rendering to a different thread than the thread that receives input, so there is some overhead in passing a message to the other thread to tell it to update the window with the text for the newly pressed key. I would expect it to be measured in microseconds but who knows.
I think I'll write a program that tries to update the screen as quickly as possible (using the shortest coding path possible from event detection to screen update) and see what I can get.
Also, I have tried various programmatic settings in my program for adjusting the 'vsync' and buffering settings of OpenGL rendering but they didn't seem to accomplish anything, on OS X at least. On Linux I've experienced wildly different behaviors depending on graphics card, driver, and version of GLX being used.
OK I realize this doesn't exactly address your situation because we're on such different hardware and have different purposes, but still it might be interesting just to track the data.
I wrote a very small program that tries to detect a keypress and update a window as quickly as possible in response. It can be run:
- In full screen or window - With double-buffering disabled or enabled - If double-buffering is enabled, with lock-to-vsync enabled or disabled - If lock-to-vsync is enabled, with adaptive vsync enabled or disabled
Right now I just have an X11 version (for Linux), I haven't written the OS X version yet and I certainly haven't written the Windows version yet (Windows programming, ewww).
Anyway, whereas before I wrote that SDLmame appeared to have a 7 frame latency on my desktop Linux system, using my simple latency tester program got much better results. I was able to achieve a 1 - 3 frame latency. There are a few specific details:
- I notice that my caps lock LED takes more than 1 frame to fully illuminate (between 1 and 3 frames, typically 2). I start my latency count at the first visible illumination level (i.e. as soon as there is any illumination of the caps lock key, even if it's not completely illuminated yet)
- I notice that my ancient DELL LCD display (it's an old - circa 2008 or so - IPS or PVS or something) seems to take a few frames to fully ramp into a change. My program just alternates clearing the window to full black or full red in response to a key press, and when going from black to red, for example, it takes typically about 3 frames to go from a just barely pink version all the way to the full red version. So I see something like - Caps lock light starts to illuminate - Nothing for 1 - 2 frames - Window goes pink for 1 frame - Window goes redder for 1 frame - Window goes fully red
- I also notice that when going from caps lock on to caps lock off, the window updates exactly at the same time as the caps lock LED turns off, and sometimes even before it does. I have no idea what is going on here - is it possible that the keyboard doesn't turn off the caps lock light until the operating system has already serviced the key press and then tells the keyboard to turn the light off? Not sure.
- On this particular Linux system, the crummy OpenGL drivers on this system don't support enabling or disabling swap-on-vsync ("vsync") or adaptive vsync, so I couldn't test those at all. I found that if my settings were double-buffering windowed or full-screen, or single-buffered full-screen, my program was limited to updating the screen at the display refresh rate (60 Hz). Only if my program were single-buffered in a window was it not locked to the screen refresh rate. At no point did I witness tearing.
Anyway, I am not sure how to explain the 1 - 2 frames between caps lock LED illumination and screen update. Is it input latency in the monitor? Latency in the keyboard driver? Latency in the OpenGL implementation? All three? Not sure, but I suspect that it's monitor input latency, not surprising on a pretty old DELL LCD monitor ...
Thanks for testing this, seriously, it's been long since I wanted to know about some real measurement of the flip queue size issue, rather than the typical "I feel it lags" crap.
> The bad news: Yes, I see the tearing. It's only on top of the screen (unlike without > vsync where it's all over the screen), but it's there.
Yes, unfortunately. I even tested creating a DirectDraw dummy device to invoke waitvsync from it while rendering with Direct3D, and it worked, but showed exactly the same static tearing. Considering the DirectDraw waitvsync method works great when combined with blitting or flippling from DirectDraw too, this means that the problem is *inside* the Present method, it just reacts too slow even with the D3D_INTERVAL_IMMEDIATE flag set, so the vblank is missed.
It's just too bad that as soon as D3D_INTERVAL_ONE is activated, an unwanted flip queue seems to be created by ATI drivers. Unfortunately this, again, tips the scales in favour of the -deprecated- DirectDraw interface.
> So, wouldn't it be possible to use the window mode, but in the way that the window is > a boderless window of the size of the screen resolution?
Well, this is certainly possible. I admit it's an unexpected result, as it's a well known fact that modern visual features like Aero make windowed mode based emulators laggy, and you have to move to exclusive mode to avoid it. But this wouldn't apply to XP. What I wonder is if you're getting a good quality vsync while in windowed mode. Anyway, what you're suggesting should be possible, but you'd be limited to the desktop resolution, so in order to switch resolutions (to run games on their native video modes) you'd need to use ChangeDisplaySettings instead of relying on DirectX mode switching and exclusive mode, which would be rather messy.
My keyboard isn't USB, it's the old style. Do you think this could have any influence? Are PS2 keyboards slower in fullscreen with vsync?
@Bryan Ischo:
Yeah, strange indeed those discrepancies.
> Thanks for testing this, seriously, it's been long since I wanted to know about some > real measurement of the flip queue size issue, rather than the typical "I feel it > lags" crap.
Ironically, when I first came into contact with input lag, it was when I played Nestopia. When I enabled vsync for smooth scrolling, I actually noticed the lag just by "feeling" it. So, I did a Google search and I actually found other people who experienced it as well. I just find it strange that nobody ever got the idea with using Caps Lock and the LED. But, o.k., I didn't think about it either until I saw the person in the video testing input lag in the different "Street Fighter II" versions for PlayStation, PlayStation 2 and Saturn.
> It's just too bad that as soon as D3D_INTERVAL_ONE is activated, an unwanted flip > queue seems to be created by ATI drivers. Unfortunately this, again, tips the scales > in favour of the -deprecated- DirectDraw interface.
In the meantime, DirectDraw has become unacceptable for me. Not only does it decrease artwork size only to increase the small image again. But with bilinear filtering, it even mixes the artwork and the game screen image. For example, if you use an all black artwork image file and play a game with a white background, the border of the game and artwork will be gray since they are put into a single low resolution image and that image is then rescaled.
> Well, this is certainly possible. I admit it's an unexpected result, as it's a well > known fact that modern visual features like Aero make windowed mode based emulators > laggy, and you have to move to exclusive mode to avoid it. But this wouldn't apply to > XP.
Even on Windows 7, I don't use Aero.
> What I wonder is if you're getting a good quality vsync while in windowed mode.
Yes, I do. DirectDraw fullscreen, DirectDraw window, Direct3D window and everything without vsync is fine. Direct3D fullscreen vsync is laggy.
> Anyway, what you're suggesting should be possible, but you'd be limited to the > desktop resolution, so in order to switch resolutions (to run games on their native > video modes) you'd need to use ChangeDisplaySettings instead of relying on DirectX > mode switching and exclusive mode, which would be rather messy.
Doesn't MAME keep the native resolution as well? When I play "Street Fighter II" and my desktop is 1360x768, then MAME's fullscreen resolution is still 1360x768 with the actual game's screen increased by MAME. It doesn't switch to a real screen resolution of 384x288. Would this even be possible? Doesn't a monitor have just a few predefined resolutions anyway? Like 640x480, 800x600, 1024x768, 1360x768? And isn't MAME configured to not change the screen's resolution unless you explicitly set it with -r and -switchres? Or am I completely wrong here? Or maybe I misunderstood what you were saying.
So, do you know where exactly the window is created, so that I can change it in the source code and don't need to search for it first?
What do you think, could the fact that I use a PS2 keyboard instead of USB have anything to do with the lag?
> Doesn't MAME keep the native resolution as well? When I play "Street Fighter II" and > my desktop is 1360x768, then MAME's fullscreen resolution is still 1360x768 with the > actual game's screen increased by MAME. It doesn't switch to a real screen resolution > of 384x288. Would this even be possible?
it doesn't change resolution by default, but if you change mame.ini
Oh, right. I didn't know that. But it's still not really the native resolution of the game. For example "Vs. Super Mario Bros." goes to 640x480. And if you change resolutions on an LCD monitor, it's up to the monitor to do the filtering. And this one looks worse than the bilinear filter done by DirectX and the graphic card. So, I wouldn't want to change resolutions anyway. And if I did, I could do it in Windows itself.
I implemented a Cocoa (Mac OS X) version of my latency testing program. A few points:
- With swap-on-vsync enabled, the lag was around 2 - 3 frames - With swap-on-vsync disabled (but still double buffering) the lag was around 2 - 3 frames also. I suspect that you can't really disable swap-on-vsync in Cocoa. - With double-buffering disabled, the lag was around 1 - 2 frames. One would expect tearing but I was hard pressed to see any. - The same issue where it would take multiple frames for the LCD pixels to ramp up to their final values (i.e. going from black, to pink, to red, over the course of 2 frames instead of straight from black to red in 1 frame) was present on the retina display. Could this actually be an artifact of the video camera's capture method? It's a Cisco Flip UltraHD ... - I noticed that the LED on the caps lock key on the Macbook doesn't illuminate when the key hits the bottom of its travel. If the bottom of the key travel corresponds to the key being pressed, then the LED doesn't even start coming on for 2 - 3 frames ...
> Doesn't MAME keep the native resolution as well? When I play "Street Fighter II" and > my desktop is 1360x768, then MAME's fullscreen resolution is still 1360x768 with the > actual game's screen increased by MAME. It doesn't switch to a real screen resolution > of 384x288. Would this even be possible? Doesn't a monitor have just a few predefined > resolutions anyway? Like 640x480, 800x600, 1024x768, 1360x768? And isn't MAME > configured to not change the screen's resolution unless you explicitly set it with -r > and -switchres? Or am I completely wrong here? Or maybe I misunderstood what you were > saying.
I don't know how you would do this on Windows, but on Linux it's possible to compute new video timing modes on the fly and update the video card to use those modes. The CRT monitor has to actually support the mode of course (which is to say, the timings have to be within the monitor's spec, but they can be any weird resolution and refresh rate that you want), but it's possible. I have some code that I intended to incorporate into my front end (should I ever actually get far enough in the thing to start adding these kinds of features) that does this. If the game was originally 384x288 @ 59.97 Hz, it would compute video timings to support this, and switch the monitor to those timings, before starting the game.
However, some really low spec timings like that can be unachievable for "modern" PC CRTs. They simply won't sync to a scan rate that slow. My test rig has a Mitsubishi Diamondtron 21 inch monitor, circa early 2000's in age, and it couldn't sync to the natural resolution and refresh rate of some games that I tried this technique on. I ended up choosing a refresh rate that was a multiple of the original game rate to get the scan rate high enough that the monitor would do it (for example, 384x288 @ 119.94 instead of 59.97).
And then what I found was that the phosphors of the CRT weren't really designed with the level of bloom needed to make 384x288 look good. I ended up with really, really skinny lines of video alternating with really think black empty spaces. I expect that the thickness of the scan lines is a function of the width of the beam and also the bloom of the phosphors. I guess it shouldn't have been surprising that a 'modern' CRT made to excel at rendering small pixels at 1600x1200 resolution wouldn't easily adapt to rendering big and chunky pixels at really low resolutions.
An alternative could be to double the resolution and render the scan lines manually, by explicitly drawing black on every other line. I didn't try that though, I kind of gave up eventually and decided to return to the problem later.
Also, as an aside - what's up with the vaguely racist graphics being used on this site now ("EmuChat? Ain't nobody got time 4dat")? Kind of makes me embarrassed to be posting here ...
> Also, as an aside - what's up with the vaguely racist graphics being used on this > site now ("EmuChat? Ain't nobody got time 4day")? Kind of makes me embarrassed to be > posting here ...
I think it's cute. She'd probably say that to your face if you asked her what she thinks about this board. She's got her priorities straight.
I can't imagine what makes the image "vaguely racist" to you, or why you'd be embarrassed to post because there is a funny picture of a black woman talking shit about emuchat. I really can't, and I'm glad that I can't.
> Oh, right. I didn't know that. But it's still not really the native resolution of the > game. For example "Vs. Super Mario Bros." goes to 640x480. And if you change > resolutions on an LCD monitor, it's up to the monitor to do the filtering. And this > one looks worse than the bilinear filter done by DirectX and the graphic card. So, I > wouldn't want to change resolutions anyway. And if I did, I could do it in Windows > itself.
It is technically impossible to run 15KHz arcade games at their native resolution on a regular LCD monitor.
When switchres=1 is set, MAME changes resolution to the best possible match available from a list of resolutions provided by your video card drivers. In most cases 640x480 will be the lowest res available. If you want MAME to go lower than that you'll have to make these resolutions available yourself. How to do this depends on which video card you have. The nvidia control panel has a section that lets you add new modes but your options will be limited when using an LCD display, they only really have a single resolution, any other resolution scales to full screen resulting in artifacts, or at 1:1 becomes a tiny image surrounded by black nothing. You really need a multisync CRT monitor for this.
Changing your "desktop resolution" will not accomplish anything because if switchres is set to 0 that means everything will now run at that resolution. If switchres is set to 1, it doesn't matter what your "desktop resolution" is, MAME will change resolution anyway.
> I can't imagine what makes the image "vaguely racist" to you, or why you'd be > embarrassed to post because there is a funny picture of a black woman talking shit > about emuchat. I really can't, and I'm glad that I can't.
We have a black woman:
- Standing in front of a building that looks like "the projects" - With a gleaming gold tooth - In a do-rag - With a "gossipy" facial expression - Behind a caption that suggests she's speaking Ebonics
The image and text were carefully chosen. They represent a caricature of a negative racial stereotype. It's a little racist in my opinion. And embarassing. But that's just my opinion.
Perhaps someone should make an image of a white guy in blackface saying "Gee missuh, I ain't seen no emuchats 'round here." It wouldn't be racist either, I suppose, because if it's funny, it can't be racist. Or something.
> > I can't imagine what makes the image "vaguely racist" to you, or why you'd be > > embarrassed to post because there is a funny picture of a black woman talking shit > > about emuchat. I really can't, and I'm glad that I can't. > > We have a black woman: > > - Standing in front of a building that looks like "the projects" > - With a gleaming gold tooth > - In a do-rag > - With a "gossipy" facial expression > - Behind a caption that suggests she's speaking Ebonics
I swear I didn't even know that any of those things were in any way significant.
> The image and text were carefully chosen. They represent a caricature of a negative > racial stereotype. It's a little racist in my opinion. And embarassing. But that's > just my opinion.
Maybe it's a "racial stereotype" but what's negative about it? She's there, she exists and she'd say the same thing to your face. I don't see anything demeaning. You decided that it's negative. "negative" is when someone calls it racist.
> Perhaps someone should make an image of a white guy in blackface saying "Gee missuh, > I ain't seen no emuchats 'round here." It wouldn't be racist either, I suppose, > because if it's funny, it can't be racist. Or something.
I must be immune to these things, I don't understand. I suppose nearly anything could be construed as racist if you're wearing the right glasses. "white guy in blackface", I don't know. Joni Mitchell is "in blackface" (and dressed as a man) on the cover of one of her 70's albums, I'm sure she's not a racist or a transvestite.
Either way, like the lady said, this is a waste of time. I'm glad I don't see racism everywhere, neither literally nor figuratively.
> > > I can't imagine what makes the image "vaguely racist" to you, or why you'd be > > > embarrassed to post because there is a funny picture of a black woman talking > shit > > > about emuchat. I really can't, and I'm glad that I can't. > > > > We have a black woman: > > > > - Standing in front of a building that looks like "the projects" > > - With a gleaming gold tooth > > - In a do-rag > > - With a "gossipy" facial expression > > - Behind a caption that suggests she's speaking Ebonics > > I swear I didn't even know that any of those things were in any way significant.
Combined together they form a caricature, is all I'm saying. It's not in-your-face racist but it's somewhere on the edge of poor taste, in my opinion.
> Either way, like the lady said, this is a waste of time. I'm glad I don't see racism > everywhere, neither literally nor figuratively.
I am also glad that I don't see racism everywhere, and gladder still that I can see it when it's there.
> OK that's actually really well done. I still find the subject matter a little on the > edge of tasteful but it's definitely cleverly put together. > > I didn't realize that the still shot at the top of this page was from some internet > meme youtube video thing. Shows how out of touch I am.
I can't speak for the meme's taste but ever since this forum went down last year and came back up under new administration ... and those admins notoriously surf the edge of tasteful if not purposely blast through it in The Loony Bin subforum... and one of these admins enjoys editing the header and footer of each subforum almost weekly... well, best prepare yourself for the occasional trickle-down effect.
It'd be different if these were official MAME forums. (No such thing.)
> I am also glad that I don't see racism everywhere, and gladder still that I can see > it when it's there.
The only racist thing here is that you consider a random person who says a random thing racist just because the person happens to be black.
A man in blackface is something to actually make fun of black people. And if you show a black person and put a caption below it that has actually to do with her race, then it might be racist. But if you show a black person saying something that isn't tied to her skin color at all, in how far is that racist?
Even if it wasn't an original quote: The sentence is still nothing that is tied to her skin color. Anybody could have said it. So, you wanna say that black people shouldn't appear in random images?
And she's a black stereotype? Well, guess what: She's not a white person dressed as a black person, she's an actual black person. So, if you say that she's a stereotype, if you call an actual, real-world person a stereotype, then you are the one that insults her.
That banner neither comments on her skin color, nor does it put any words in her mouth that are stereotypical for blacks. But you call her a black stereotype. So, who's the racist now?
> > They represent a caricature of a negative racial stereotype. It's a little racist > in my opinion. And embarassing. > > Maybe you should tell her that she is a cariacature of a negative racial stereotype > and that you find her embarassing. Maybe she'd sue you too.
Can you explain to me why the focus was paid to her interview segment? Why music videos were created out of it? Why someone would take a still shot from the video and put a caption on it?
Just give me any explanation at all. Anything to identify what the motivating force was to pick *that* interview with *that* person saying *those* things. Anything.
I suspect that you cannot give any non-hand-waving reason that doesn't come down to how "funny" it is to see someone "act that way" and "say those things". Why is it funny? BECAUSE IT IS A CARICATURE. Because in that interview segment she looked and sounded like the prototype of a specific vision of black Americans.
I mean these arguments about "it can't be racist because it's true" are so self-serving. Hey I can find a Chinese person who happens to be a bad driver and then make a whole funny video out of showing how bad a driver they are with funny captions and stuff. But I guess it's not racist because that person actually was a bad driver, even though the entire reason that I focused on that person was because of the racist stereotype that "Asians are bad drivers"?
Racism is a complex subject and I'm not saying that people who engage in this kind of humor are akin to ku klux klansmen ready to lynch the first minority person they see. But let's not kid ourselves. This kind of humor is motivated by a form of racism. Maybe it's an "OK" level of racism for alot of people; I mean it's just humor after all. Myself, I find it somewhere on the edge of tastelessness, due to the racist implications. I wouldn't actively try to stop someone from making these kinds of jokes, but I would find it uncomfortable enough to want to get away from it.
Which is what my original point was. It's tasteless enough in a racially-charged way to be embarrassing to me to be "associated" with it, i.e. to post on a forum where it's actively accepted. If I was writing a post on this forum and someone came up to my computer saw the page with that image on it, I'd feel embarrassed.
> > I am also glad that I don't see racism everywhere, and gladder still that I can see > > it when it's there. > > The only racist thing here is that you consider a random person who says a random > thing racist just because the person happens to be black.
If that's all you think it is then you haven't read a thing I wrote. The absolutism of your statement and the wilful disregard for the subtleties of the issue lead me to believe that you're not actually worth talking to about it.
> I suspect that you cannot give any non-hand-waving reason that doesn't come down to > how "funny" it is to see someone "act that way" and "say those things". Why is it > funny? BECAUSE IT IS A CARICATURE. Because in that interview segment she looked and > sounded like the prototype of a specific vision of black Americans.
I think she's funny for various reasons, but none are because of her race.
Are you suggesting that we're supposed to check before we laugh that they aren't a black american? Because that sounds racist.
> Can you explain to me why the focus was paid to her interview segment? Why music > videos were created out of it? Why someone would take a still shot from the video and > put a caption on it? > > Just give me any explanation at all. Anything to identify what the motivating force > was to pick *that* interview with *that* person saying *those* things. Anything.
Because it's funny in itself. Not funny because it comes from a black person.
A typical stereotype of the stupid white teenager. Whoa, this image is so racist! Seriously, was this necessary? I'm all for funny pictures, but do they have to insult a whole race? That's not funny, it's just disgusting. As if all white people were dim witted morons.
See what I mean?
> I suspect that you cannot give any non-hand-waving reason that doesn't come down to > how "funny" it is to see someone "act that way" and "say those things". Why is it > funny? BECAUSE IT IS A CARICATURE. Because in that interview segment she looked and > sounded like the prototype of a specific vision of black Americans.
Oh shut up. Racism is when some cunt I've never seen before spits at me and tells me to go home to my own country. Racism is not when some random white kid asks if I ate curry for breakfast today. Racism is not when I put on an exaggerated Mumbai accent and talk about the evils of toilet paper. It's important to be able to laugh at yourself.
> Oh shut up. Racism is when some cunt I've never seen before spits at me and tells me > to go home to my own country. Racism is not when some random white kid asks if I ate > curry for breakfast today. Racism is not when I put on an exaggerated Mumbai accent > and talk about the evils of toilet paper. It's important to be able to laugh at > yourself.
I was just expressing an opinion. It seems impossible on forums like this to try to have any discussion in earnest as there will always be people who can't manage to communicate on that level.
> > Oh shut up. Racism is when some cunt I've never seen before spits at me and tells me > > to go home to my own country. Racism is not when some random white kid asks if I ate > > curry for breakfast today. Racism is not when I put on an exaggerated Mumbai accent > > and talk about the evils of toilet paper. It's important to be able to laugh at > > yourself. > > I was just expressing an opinion. It seems impossible on forums like this to try to > have any discussion in earnest as there will always be people who can't manage to > communicate on that level.
You know, I'm beginning to think that people who try to see racism everywhere are worse than actual racists. It's just another arm of the PC brigade trying to guilt people into a certain way of thinking to satisfy their own guilt. Are you going to wage war on all caricatures? Great way to kill comedy. Now don't get me wrong, IMO most of what passes as comedy is unfunny shit, but laughing at superficial differences between people is a hell of a lot better than actual racial/religious/political/regional violence.
Index 
Threaded 
Input lag
Reply
[Re: 
