SilverLining 1.94 includes a new “custom renderer” sample project, illustrating how to tie SilverLining into your own rendering engine directly. You no longer need to let SilverLining render directly via OpenGL or DirectX; you can wire our drawing calls directly into any engine you’d like now. This opens up possibilities such as using SilverLining as a numerical engine on console platforms.

All of the platform-specific code for OpenGL or DirectX in SilverLining is isolated into renderer code that may be loaded dynamically at runtime. This means the core of SilverLining is platform-agnostic; you may substitute our renderer implementations for your own, and tie SilverLining directly into your own rendering engine. Licensed users receive the full source of SilverLining, which essentially means you can use SilverLining on any system with a C++ compiler with STL, such as gaming consoles.
In this mode, you can essentially think of SilverLining as a numerical engine that calls back into your own renderer to do the actual drawing, texture loading, setup of vertex buffers, etc.

Bear in mind that if your rendering engine is built on top of OpenGL or DirectX, it’s easier to use SilverLining’s native support of OpenGL or DirectX. Even though it’s going “behind the back” of your engine to render directly at a lower level, you don’t need to worry about SilverLining interfering with your engine. We’re careful to restore any state that was set prior to calling SilverLining API’s, and since we do our drawing at the very beginning and very end of the scene surrounding your own frame update code, our drawing stays out of the way of the rest of your scene. Our sample integration code for OpenSceneGraph, Gamebryo Lightspeed, and Ogre3D all work in this manner without any problems.

However, if you’re using SilverLining on a system that’s not built on standard OpenGL or DirectX (such as Playstation, Wii, or XBox,) you’ll need to implement hooks into your system’s renderer. We provide sample code to get you started.

If you’re tying into your own renderer, use the “static” version of the SilverLining libraries (for example, lib/vc9/win32/SilverLining-MT-static.lib/) These libraries do not attempt to dynamically load a renderer at runtime, and do not include any rendering code of their own. You then need to implement all of the functions defined in the header file “SilverLiningDLLCommon.h.” SilverLining is able to operate with some of these functions stubbed out; the comments indicate when this is the case. Essentially, you need to provide hooks for loading and activating shaders, vertex buffers, index buffers, and textures, as well as code to draw triangle strips and lists of points using these resources. When initializing your Atmosphere object, pass in CUSTOM_RENDERER as the renderer type.

The SampleCode/CustomerRendererExample folder contains a project that illustrates how to tie SilverLining into your own renderer – in this case, it ties it back into DirectX9 directly. It’s similar to our DX9 sample code, but implements its own DirectX9 renderer that you could swap out with any other renderer instead. Licensed users may also examine the source of our native OpenGL, DirectX9, DirectX10, and DirectX11 renderers as further examples. If you’re evaluating SilverLining and need one of these other renderers as a starting point for your own integration, drop a note to support@sundog-soft.com and we’ll be glad to help.

Don’t be intimidated by the amount of code in our sample DirectX9 renderer – a good portion of the functions actually aren’t required for SilverLining to run (see the comments in SilverLiningDLLCommon.h for guidance,) and you can likely implement the required functions in far fewer lines of code when you’re coding against a rendering engine that abstracts away the complexity of DirectX or OpenGL.