Objects and Graphics

From Croquet Consortium

The Croquet graphics architecture was designed around three principles – simplicity, performance, and extensibility. The design is somewhat different from most graphics engines you might encounter. For one thing, it is much smaller than what you typically see in most game engines. This is because the focus of the design was on the architecture itself and not on the multitude of features that other engines provide. The idea is that if the architecture is simple and extensible enough, it will be easy to add the additional features as needed.

Another difference is that the programmer has direct access to OpenGL throughout the architecture. But this is not just a simple layer on top of OpenGL. It was designed to allow an infinite degree of extensibility at the component/object level, while maintaining a flexible and high performance hierarchical framework within which to place these objects. We sometimes call this a semi-retained architecture, with the idea that it offers all the advantages of both a retained engine, with its rich structures and internal relationships, while offering the advantages of an immediate engine where any rendering effect can easily be reproduced.

One thing that people are often surprised to learn is that the entire engine (outside of the OpenGL library of course) is written in Squeak! The reason we could do this, instead of resorting to a lower level – higher performance language like C++ is because Squeak is pretty fast already, and it is rarely the bottleneck in good graphics design. More important are the abilities of the underlying hardware and the quality and performance of the algorithms. A well-designed algorithm will almost always outperform a brute force calculation, often by orders of magnitude. Though it is true that a fast algorithm can be made even faster by resorting to low-level coding, this is typically unnecessary, and even when it is, Squeak has some very nice extensions that allow the programmer to turn any piece of the system into a high-performance plug-in.

This section is focused on rendering, but it is important to understand that that is just one aspect of the functionality of a component. Rendering tends to be a good place to start the description, because it has a nice context where the other two component elements, events and behaviors/simulations can be better understood.