# 3 Rules to Make You Image Looking Good on a Projector
As I go to conferences (and sometimes present my slides), do music visualizations on parties and attend demoscene parties, I started noticing what looks good and what doesn't when presented on a big screen using a projector. It's often not the same thing as you expect when preparing your content and see it on a monitor. The problem is that while monitors usually do pretty good job in representing all shades of colors and brightnesses and we adjust them to see the image from the right distance and in good lighting conditions, with image presented from a projector it's often not the case. You never know what to expect from the quality of the image before you actually enter the venue where you are going to present. That's why I have prepared three simple rules to follow if you want your content to look good on a projector:
1. Use High Contrast
White (or almost white) objects on black background are OK. Black (or almost black) objects on white background are also OK. Gray objects on gray background are not OK. In other words: don't rely on subtle differences in brightness.
Why? Because they may not be visible on the big screen. Sometimes the projector is not powerful enough to ensure sufficient contrast and so everything looks very dark. Sometimes the lighting conditions are such that everything looks very bright. Sometimes the gamma of the image is very different than you experience when preparing your content. (By gamma, I basically mean the curve showing how perceived brightness depends on the brightness value of a pixel.) As a result, all the dark colors may be indistinguishable and completely black, or all the bright colors may be indistinguishable and completely white, or conversely - small difference in pixel brightness can make large difference on the big screen.
So basically use high contrast for all your images. Using subtle differences in pixel brightness for adding some details is OK, but make sure the image looks good and conveys all the key information also without them, relying only on the difference between black and white.
2. Don't Rely on Colors
Monitors can represent most of the colors from sRGB space more or less correctly, but you shouldn't expect the same from a projector. Some colors may seem brighter or darker than expected. Sometimes colors just look completely different on the big screen.
That's why you shouldn't rely on them. Showing some details using colors is OK, but make sure your image looks good and conveys all the key information also without them, relying on brightness alone.
I can remember watching a business presentation where some data was shown on a graph using a yellow line on white background. It was completely invisible on the big screen, so the presenter turned his laptop for us so we could see it. Another time I needed to present on a screen that was lit by a blue lamp and there was no way to turn it off. All parts of the image looked more or less blue and there was no point in using any colors. I even seen a situation where one of RGB components didn't work at all because of the broken cable!
3. Use Big Objects
Use only large font size, prefer big objects of uniform brightness/color and make all lines thick. Don't show any important things as small objects or characters and don't use single-pixel width lines.
Why? Because they may not be readable or visible at all. Sometimes the screen is too small or some viewers sit too far from it. Some people have bad vision and might forget their glasses. Sometimes the image gets downscaled. Many projectors have low resolution. The image quality may just be bad - for example long VGA (D-sub) cable introduces some horizontal blur. I sometimes connect my laptop to a HDMI video switcher that presents itself to the laptop as Full HD (1080p) display, while its output is actually connected to a projector having native resolution of 1024 x 768. I once needed to present on an old projector that didn't have either D-sub or HDMI input, only Composite, S-Video and... a DVD player. Not only I needed a special converter, but also image quality was very bad because standard definition PAL TV signal is only 576i.
For good examples, see demos from Cocoon group (see the group on pouet.net, search YouTube). I think they are not only masterpiece of both technology and art, but they are also deliberately prepared to look great on a big screen by following the rules similar to what I described here.
# Nonbreaking Space and No-Width Optional Break
Wrapping text on word boundaries instead of single character boundaries is a great invention. A text looks so much better when inserted to Word:
Than when printed in oldschool console:
But there are places where we may not want a line break to be possible despite we insert a space. For example, in Europe we use space as thousand separator (and comma as decimal mark) when writing down numbers.
A special character called "nonbreaking space" is very helpful in such cases. You can insert it in Word by clicking: Insert > Symbol > More Symbols > Special Characters > Nonbreaking space. This character looks like space, but it doesn't cause line break.
You can actually see this "invisible" character when you press Ctrl+*. It looks like a small circle or a degree sign.
In HTML you can specify a non-breaking space as:
I have discovered quite recently that there is also an opposite special character, called "no-width optional break" or "zero-width space". It is useful in cases where you have a long sequence of characters (like a file path) and you want it to be broken across lines despite it doesn't contain any spaces. It is especially important when you use text justification, because such a long text moved to separate line as a whole can cause an ugly effect:
You can insert this special character in Word (e.g. after every backspace in the path) by clicking: Insert > Symbols > More Symbols > Special Characters > No-width optional break. It occupies no space, but it tells the word processor that a line can be broken at this point. Now it looks much better:
When you press Ctrl+*, you can see this special character depicted as a rectangle.
In HTML you can also use it by typing:
​. It's Unicode "Zero Width Space" character.
# Operator New and Delete - Unnecessary Conditions
I've seen following constructs many times in C++ code:
MyClass* obj = new MyClass();
if(obj == nullptr)
// Handle allocation error.
if(obj != nullptr)
Both of these conditions are unnecessary. Strictly speaking they are not a bug - program will run correctly, but they make no sense. If you used to write any of these, you should know that:
new doesn't return null on failed allocation. By default it throws an exception of type
std::bad_alloc in this case, so this is what you should handle if you really care about the state of your program after it runs out of memory (or if the allocated object is particularly big).
There is also special
nothrow version of the
new operator that returns null on failure, but you must call it explicitly. An alternative would be to overload
new operator (global or for particular class) to change its behavior. But again, this is not what happens by default.
Note this is different behavior than
malloc function from C. Obviously there are no exceptions in C language, so this function just returns null on failure.
delete doesn't crash when you pass null pointer to it - it just does nothing, so the check for not-null is already inside, you don't have to write it. Of course trying to delete object from any non-null address that was already freed or is just invalid address still crashes, or causes other undefined behavior.
Note this is the same behavior as
free function from C - it also accepts null pointer.