I made this demo program and noticed that the blue circle looks a bit strange. It looks like there are some white pixels between the black outline and the blue area. My first thought was that the blue cones in the retina are slower than the red ones. But this is probably a hardware thing. I have a lcd screen. And no, the circle() and circlefill() are not two separate steps with a screen refresh inbetween. I use a buffer.
But the topic sounds more interesting this way and gets your attention to my demo! 
There aren't any white pixels in the blue circle...
No, not in the screenshot. But when one looks at the moving circles, one can see something white between the black (cutting) edge and the blue surface.
I haven't looked at your source code but it sounds like you're possibly seeing the delay between a pixel on your LCD going from the colour of the circle back to white. If you have a manual for your monitor, you might be able to read up what it's "Response Time" is, which is the maximum amount of time it will take for a pixel to go from full black to full white or vice versa.
Fun fact: Most active matrix LCD's are darker when showing black than when a pixel is simply off, which can look very weird given the right lighting conditions and changes in pixel colour. It's part of the reason I'm not a big fan of LCD.
One way to check this would be to manually slow down all the circles so that they don't move every single screen refresh. Another would be to run all the circles side by side.
Your monitor settings may also play a role in this, such as colour temperature settings and contrast. (Since contrast on LCD's is usually a change in signal interpretation rather than an actual contrast level change in the pixels themselves like in a CRT.)
LCD's are weird like that. And just so you know, the bigger or older your LCD, the longer the response time will be.
--- Kris Asick (Gemini)
--- http://www.pixelships.com
And whatever age your CRT is (in about the last 10 years), it will still be better quality than any LCD available. I mean 'response times' (which don't exist in CRT's), colour bleed (which is only really there in massive resolutions), and contrast ratio of two adjacent pixels.
Try drawing at integer positions and don't allow float positions, that should fix your problem.
I mean 'response times' (which don't exist in CRT's)
Although that's wrong, response times with CRTs are so fast that no one notices. Low end CRT monitors at least 15 years old have response times between 10 and 20 ms. Newer CRT monitors have response times of 5 ms or less. The average LCD nowadays has a response time between 10 and 50 ms depending on size and make, but back when CRTs had similar response times, LCDs had response times well over 500 ms! (That means it took over half a second for a pixel to change from full white to full black!)
DLP doesn't have a response time due to its nature. (I don't think it does anyways...) Plasma I don't know the response times of but I'm pretty sure its better than LCD.
Try drawing at integer positions and don't allow float positions, that should fix your problem.
That is a horrible suggestion. The only real issue with drawing to floating point coordinates is that you have to floor() or ceil() all coordinates to avoid rounding errors when going from -1.0f to 1.0f. Other than that, there's absolutely no reason to switch from floating point coordinates to integers unless you desire a headache. (Maybe back when FPUs weren't default in processors and integer math was faster, but that's not a valid reason anymore.)
--- Kris Asick (Gemini)
--- http://www.pixelships.com
Are you sure about those numbers? Aren't LCD monitor response time more in the range of 2-10 ms?
For the upper end.
My LCD claims a response time of 4ms.
Same here, and it was about 250€ (19").
4ms is only within a specific range. Consider it a non-linear weighted average. You'll find the black to white times in particular are a lot longer than that.. but the white to black should be similar. I believe different colours also have different IV curves and response times.
Also LCD's don't show dark colours well.. because of the, lets call it, power on current. It can't really "dim" enough to get a good range.
Most LCD monitors response time aren't a usefull number. They could mean anything.
As for black level, your average CCFL backlit LCD is going to have some rather bad contrast, and worse black level. The time of the LED backlit LCD is come! Its contrast and black level are superb. Color reproduction is a lot better too.
I'm part of a medical imaging research lab.. lcd's are known to offer really crappy contrast esp compared to medical film. There's a company here locally that a few people in the lab were involved with, that are trying to make HDR screens. Really though, its a hack, and is completely software processed but works very surprisingly well. I really cannot wait until we have true HDR, which means at least 12-bit per channel 
That is a horrible suggestion. The only real issue with drawing to floating point coordinates is that you have to floor() or ceil() all coordinates to avoid rounding errors when going from -1.0f to 1.0f. Other than that, there's absolutely no reason to switch from floating point coordinates to integers unless you desire a headache. (Maybe back when FPUs weren't default in processors and integer math was faster, but that's not a valid reason anymore.)
When I said integer coordinates I meant floor() ( == (int) ) the coordinates when drawing on screen.
Here's why (This is a quote from Shawn Hargreaves from my thread here: http://forums.xna.com/thread/8432.aspx about a similar problem)
This isn't a bug, it's just the way graphics works.
Fundamentally, there is no such thing as drawing to a fractional pixel location. Either you draw to a pixel, or you don't. Pixels are discrete, integer things.
When you ask for a fractional position, the graphics card emulates this by filtering your texture. It can't actually draw values from your texture to half way in between two screen pixels, but it can draw to a single screen pixel using a value that it computes by filtering from half way in between two pixels of your texture.
Usually this is a good thing because it makes everything appear to move with sub-pixel accuracy. It's particularly important for making 3D rendering look good.
Other times, though, you might not want this filtering. A prime example being if your texture actually contains several different images arranged next to each other: in that case you will get visual errors if the card tries to filter past the edge of one image to include data from the next one along.
Solution: if you don't want filtering, don't draw at sub-pixel positions. Round your coordinates to integers before you draw the sprite.
So perhaps my "horrible suggestion" makes sense. 
(that is if Allegro does the same kind of texture filtering as GPUs)
It doesn't.
The 3D space (entirely floating point) is projected onto a 2D plane. Sampling is done to pick pixels out from that space (with the interpolation going here.. might be wrong here gurus?). Undersampling causes aliasing (shannon-nyquist information theory.. # samples >= 2 times the peak frequency). Anti-aliasing and texture filtering are really clever ways of dealing with this.
void putpixel(BITMAP *bmp, int x, int y, int color);
No way the GPU can get any info about fractions through that function if you pass floats as x and y. Maybe in a future compiler...
graphix.cpp:154: warning: float passed as argument 2 and 3 in function putpixel(BITMAP*, int, int, int). Function overridden and floats passed instead directly to your fashion GPU!
CRT's do not have response times.
It takes exactly the same amount of time to change a pixel from black to white as it does to keep it white.
And the world is flat! Don't believe anything the man tells you! :D
Seriously; please explain.
EDIT: ignore me, i thought you said LCD
What's there to explain?
A CRT works differently to an LCD.
A beam moves back and forth and up and down throwing light at the screen. Once the light's been sent, the only reason it 'stays there' is because your eyes think it does. Therefore, the only time it takes to change is the time it takes light to reach your eyes.
Unless I'm very much mistaken and the big lump on the back is not full of magnets and is in fact just a weight.
EDIT:
Btw, the world could be flat. Nobody has proved nothing.
It could just be an illusion and there are actually teleporters at each end of the world (in the style of Asteroids). Looking at it with telescopes, the light is also teleported to make it appear round.
EDIT2:
Not that I believe in anything so crass as 'matter'. It's all just an illusion AFAIAC. I should probably go now...
Tin foil hat needs repairing.
I think a hole has appeared in the shoes too... 
(Only joking about the tin foil suit)
CRT's do not have response times.
It takes exactly the same amount of time to change a pixel from black to white as it does to keep it white.
They do have refresh rates though, which is what he's comparing (i.e. in this context, response time is simply (refresh rate)-1). Not that I've ever seen a consumer-grade 200 Hz CRT, but still.
A beam moves back and forth and up and down throwing light at the screen. Once the light's been sent, the only reason it 'stays there' is because your eyes think it does.
Almost. First off, the beam is not throwing light but electrons. It's only when they strike the phosphor that light (and X-rays!) are given off. Second, the phosphor has a quite significant memory effect (the glow persistence varies with the compound(s) used) - if it didn't, the refresh rate required to avoid perceptible flicker would be enormous.
Really though, its a hack, and is completely software processed but works very surprisingly well. I really cannot wait until we have true HDR, which means at least 12-bit per channel
Can you explain a bit more about this? It sounds interesting!
The phosphor has a quite significant memory effect.
Have you seen CRT on films? The flicker you see there is caused by the phosphor loosing its "memory". Sure, the pixels shine a bit longer than the time they were illuminated by the ray but not for too long. I'd say at most 20-40% of the CRT screen is illuminated at all times. It is our eyes that have hard time registering so fast brightness changes
[edit]
I really cannot wait until we have true HDR, which means at least 12-bit per channel
Have you heard of [url=http://www.dolby.com/promo/hdr/technology.html]this[/url]? They claim contrast ratio > 200,000:1 and 16 bits per color though I have no idea if it really is that much or is this simply some kind of marketing talk and it comes down to the same thing as 2ms LCDs
They still have a significant duty cycle, with τ measured in milliseconds.
Dolby purchased brightside.. so same thing. It's a local company here in vancouver.
If i remember from the tech demo (i wasn't there but someone in lab who was, talked about it, and this was almost a year ago i think), They basically ripped out the back of an lcd, and created some sort of modulated led background. The front of an lcd is basically made transistors that either allow light to pass through or not. In normal monitors there is a single light source that stays constant with "monitor brightness" across the whole plane. In this version the light sources can turn on and off. I believe this still has the issue of fine grained performance of the front of the monitor, but the black range in particular has a much better. I'm not sure about performance in terms of switching on and off but i'd suspect that it would be slightly slower. I'm also not sure how fine grained the back led's are. Quite large IIRC.
Since no video cards or media actually come in hdr (8bpp currently), they basically use software tricks to try and convert signals to it. THis will work wonders with medical imaging because lcd's give piss poor contrast ratios. Film is still better in that regard. But with medical imaging we do get datasets that are 12bit sometimes. In fact... my data all comes in floating point. As of today we have the data to display and practical uses (people are willing to pay big bucks for medical stuff). It will be quite a while longer though till cameras and video change. CCD's just aren't there yet and it'll clearly be a while till there is a commercial market.
I built some remote-diagnostic software for a company that serviced medical equipment (CT scanners, etc). As part of the diagnostics, the technicians needed to see the gray scale images because it was the easiest way for them to tell if something was wrong.
A lot of times the images were in 12-bit gray scale data, but of course I had to convert them to 8-bit PNGs for use in web browsers. They never complained about the quality, but I suppose it's what they were use to seeing. (That is, I doubt the technicians looked at the printed copies.)
But regarding LCD's... I'd take them over CRT any day. CRT's look so fuzzy to me, and any refresh rate less than 85Hz gives me headaches. I can noticeably see the refresh on anything less, although not nearly as pronounced as what you see on TV.
My eyes were always sore when I had my CRT, and I could notice a difference in sharpness and image quality when I got on my laptop. Now that I have an LCD for my main computer, my eyes are never sore, and everything looks so much better.
Yes, the CRT is brighter and has therefore better contrast. And therefore irritates your eyes more. It's not fun to watch a better screen with hurting eyes. In the end you don't win.
Jesus...
Did you guys not see the brightness knob...?