If there is no need for ECG's advanced features, like resizable pixels and variable aspect ratio then Excel's other rendering subsystem -- the Office-level Graphics Abstraction Layer -- is a possible choice.
OGAL provides additional functions (polygon drawing, filling, etc), higher performance and compatibility with other applications of the MS Office package. This compatibility can be extremely useful if the 3D application has to be ported to (e.g.) Word.
A curiosity of the rendering process is that rendering is performed on a separate layer in front of the worksheet, so the subsystem can work without modifying the existing content of the worksheet.
This feature makes it possible to run OGAL and ECG side by side, or show the background calculations and their results on the same screen -- which helps the debug process. A screenshot of the running OGAL subsystem can be seen below (Figure 8).
The separate rendering layer in front of the worksheet is easily observable on the picture: while the rotating cube is rendered on this layer, the 3D calculations performed by the engine can be seen in the background.
A typical example of the OGAL subsystem's refinement is the available polygons: whereas the current 3D engines operate with triangles, the OGAL supports other polygons (like quadrangles, pentagons, etc.) as well.
There is no need for a separate background buffer because it is handled by OGAL. Colors can be set by the usual 24 bits and the subsystem provides an additional alpha channel for the transparency as well. Again, the demonstration file is available in our example Excel engine files - for those who shun real-time, here's a video of it in action:
Warning: Only for very-very determined experts!
Sequentiality essentially influences our actual programming paradigm. It can be found in every corner of the programming vocation: day by day thousands of programmers code their algorithms row-by-row, create the executables step-by-step (as defined in the makefiles), debug the executables command-by-command.
Thousands of different programs and billions of source code lines were created with this sequential approach. Sequentiality pervades our current programming paradigm so much that programmers don't question its reason for existence and take its limitations for granted.
Note: Please don't underestimate the power of habit! Probably you have a QWERTY keyboard in front of you which has intentionally the most uncomfortable button layout!
It's not a joke: the QWERTY layout was originally created for the typewriters in the 1860s when the jam was a difficult technological problem. The QWERTY layout ensures that successive keystrokes alternate between sides of the keyboard. This layout helps to solve the typewriters' jam problem but it causes the greatest possible demands on your fingers and joints. The wind of change has blown away the typewriters and their 150 year-old technological problems but we still use the most uncomfortable keyboard layout these days!
It is the power of habit.
(For further information visit http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard)
Excel breaks with this habit and exceeds sequentiality. Its revolutionary approach can be observed in the following fields:
It is commonly accepted among developers that source code (and the algoritms encoded in source code) handled by the current development tools require a sequential top-down reading and interpretation. Figure 9 illustrates this sequential top-down interpretation.
We accepted this sequential, top-down mentality so much that interpretation of an unusually formatted (but syntactically correct) source code can be immensely hard. If you would like to test your thinking then you can find some challenging examples at http://www.textrush.com/code-formatting.htm. These examples are suitable only for the very determined readers, as they contain unusual line-breaks and tabulators as well.