|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| My blue cones are slower than my red cones |
|
Johan Halmén
Member #1,550
September 2001
|
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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Years of thorough research have revealed that what people find beautiful about the Mandelbrot set is not the set itself, but all the rest. |
|
James Stanley
Member #7,275
May 2006
 |
There aren't any white pixels in the blue circle... |
|
Johan Halmén
Member #1,550
September 2001
|
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Years of thorough research have revealed that what people find beautiful about the Mandelbrot set is not the set itself, but all the rest. |
|
Kris Asick
Member #1,424
July 2001
|
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) --- Kris Asick (Gemini) |
|
James Stanley
Member #7,275
May 2006
|
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. |
|
Epsi
Member #5,731
April 2005
 |
Try drawing at integer positions and don't allow float positions, that should fix your problem. ___________________________________ piccolo: "soon all new 2d alegro games will be better. after i finsh my MMRPG. my game will serve as a code reference. so you can understand and grab code from." |
|
Kris Asick
Member #1,424
July 2001
|
Quote: 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. Quote: 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) --- Kris Asick (Gemini) |
|
Jonatan Hedborg
Member #4,886
July 2004
 |
Are you sure about those numbers? Aren't LCD monitor response time more in the range of 2-10 ms?
|
|
relpatseht
Member #5,034
September 2004
 |
For the upper end.
|
|
BAF
Member #2,981
December 2002
 |
My LCD claims a response time of 4ms. |
|
Jonatan Hedborg
Member #4,886
July 2004
|
Same here, and it was about 250€ (19").
|
|
Goalie Ca
Member #2,579
July 2002
 |
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. ------------- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
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. -- |
|
Goalie Ca
Member #2,579
July 2002
|
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 ------------- |
|
Epsi
Member #5,731
April 2005
|
Quote: 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) Quote: 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. ___________________________________ piccolo: "soon all new 2d alegro games will be better. after i finsh my MMRPG. my game will serve as a code reference. so you can understand and grab code from." |
|
gnolam
Member #2,030
March 2002
 |
It doesn't. -- |
|
Goalie Ca
Member #2,579
July 2002
|
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. ------------- |
|
Johan Halmén
Member #1,550
September 2001
|
void putpixel(BITMAP *bmp, int x, int y, int color); 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Years of thorough research have revealed that what people find beautiful about the Mandelbrot set is not the set itself, but all the rest. |
|
James Stanley
Member #7,275
May 2006
|
CRT's do not have response times. |
|
Jonatan Hedborg
Member #4,886
July 2004
|
EDIT: ignore me, i thought you said LCD
|
|
James Stanley
Member #7,275
May 2006
|
What's there to explain? 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: EDIT2: |
|
gnolam
Member #2,030
March 2002
|
James Stanley said:
CRT's do not have response times. 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. James Stanley said: 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. -- |
|
Richard Phipps
Member #1,632
November 2001
 |
Quote: 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! |
|
HoHo
Member #4,534
April 2004
 |
Quote: 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] Quote:
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 __________ |
|
gnolam
Member #2,030
March 2002
|
They still have a significant duty cycle, with τ measured in milliseconds. -- |
|
|
1
2
|
(that is if Allegro does the same kind of texture filtering as GPUs)
