View Full Version : Problem with 2D polygon animation
06-05-2007, 05:56 AM
I have animated a square polygon , but what I've found is that the outer edges of the square I'm animating is "fuzzy". However, when the animation stops, it's smooth. The problem only affects the outer most pixels on the edge of the object.
Does anyone have any idea on what the problem is and how I can fix it? I was thinking that it might be related to subpixel accuracy, but if that was the case, wouldn't the problem exist after the object stops moving? Also, can sub pixel accuracy problems even occur on an edge is perfectly vertical? I made sure the double buffering is working correctly.
Any help is greatly appreciated.
06-05-2007, 06:24 AM
If your display is LCD-based, I would say the response time of the screen is too slow.
Do you have a screenshot ?
06-05-2007, 07:28 PM
I wasn't able to capture any images that illustrate the problem. This seems to point to something related to the actual process of refreshing/displaying the image and not the image itself. My display is an LCD. How could I tell if the response time is too slow? What could I do to fix the problem?
06-05-2007, 08:22 PM
How could I tell if the response time is too slow? What could I do to fix the problem?You're on an LCD. Unless you bought one with an especially fast response time, it's probably slow. It's one of the drawbacks of LCDs, and one of the advantages of CRTs.
There's really nothing you can do about it outside of buying a monitor with a fast response time. At best, you can play with the foreground and background colors to find one that still provides good color separation, but isn't as bad on your monitor.
06-05-2007, 09:01 PM
I was searching the internet and came across the following piece of code:
long sync = 1;
CGLSetParameter(CGLGetCurrentContext(), kCGLCPSwapInterval, &sync);
I don't fully understand how it works but I think it ties the context refresh to the display's refresh rate. Would this code help my problem?
06-06-2007, 06:10 AM
vsync /*SwapInterval only help reduce the "tearing", that is, horizontal cuts due to difference between display refresh rate and drawing refresh rate.
I wasn't able to capture any images that illustrate the problemSo you can't fix that by code. As korval said, try using similar colors (gray/lightgray). Try faster or slower animation.
Are you coding on a Mac ?
06-06-2007, 02:49 PM
Originally posted by whippet0:
How could I tell if the response time is too slow?
Google the make of monitor and see the refresh time. LCDs for a quite a while have actually been good enough for games (16ms was around a couple of years ago and was acceptable). However if it's not a full screen render like most FPS games then the effect will be more noticeable e.g. the worse case scenario is probably something like a white square moving across a black background.
Watch that sometimes they give stupids values like 1ms refresh when they are talking about changing a grey pixel to black. If it's a popular monitor you should find lots of info on it or at least on refresh times and how they affect the display.
06-06-2007, 02:59 PM
That's for sure!
White lines on a black background really looks bad, lots of flicker, even on my Samsung SyncMaster 204B, which has a reported response time of 5ms. The way they measure response time can vary, so sometimes the numbers can be a little misleading.
While the worst case is kind of nasty, I hardly ever notice ghosting in games or anything else for that matter, just the wireframe stuff mostly.
Think of it as free motion blur :)
06-06-2007, 05:26 PM
Are you coding on a Mac ?Yes, I'm using an iMac (17" G5). Does using a Mac make any difference?
06-06-2007, 05:31 PM
Originally posted by Stuart McDonald:
However if it's not a full screen render like most FPS games then the effect will be more noticeable e.g. the worse case scenario is probably something like a white square moving across a black background. That's exactly what I was trying to do! I was moving a square across a black background. :)
Is the problem worse when it is not in full screen mode? Do you know why that might be?
06-06-2007, 11:45 PM
Originally posted by whippet0:
Is the problem worse when it is not in full screen mode? Do you know why that might be? Sorry I was a little unclear. The problems with LCDs is the time to change a pixels colour. So the worse case is probably going from all on (white) to all off (or vice versa). It wasn't the full screen part that affects it, just that in a game everything is changing so much that there generally isn't an obvious sharp edge to look at and see the effect (as in your scenario).
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.