Graphics

Introduction

Inanity Graphics API is trying to abstract from any underlying hardware and software implementation differences. This includes different operating systems, display devices, graphics API's (such as DirectX or OpenGL), and even shader programming languages.

Principles

All graphics code is under Inanity::Graphics namespace.

Every graphics class is interface, general or system-dependent.

• Interface is an abstract class which defines well-known interface for system-dependent implementations.
• System-dependent class is a subclass of some interface class, and provides an implementation for it. Instances of such classes can be created only by calling methods of other system-dependent classes. Note that an instance of system-dependent class belonging to some graphics system couldn't be given as argument for method of some other graphics system! Several different graphics systems could be used simultaneously until they don't interchange instances of their system-dependent classes. Note that system-dependent classes in most cases are (in addition) device-dependent which means they should be used with only one instance of Device class.
• General class is a class which doesn't depend on a kind of graphics system.

Interfaces

System is a root class which represents a kind of graphics system. System gets a list of Adapters, creates Devices, Contexts, ShaderCompilers and ShaderGenerators.

Adapter gets information about particular graphics adapter installed in system. The exact meaning of adapter depends on graphics system, but usually adapter is a hardware graphics card, a group of hardware cards (united via SLI or CrossFire), or a software (reference) driver. This class is not about using the device, it is purely informational. Adapter knows his ID, name and a list of Monitors.

Monitor gets information about particular display device, such as LCD monitor or TV screen. Every monitor belongs to a particular adapter. Monitor knows his ID, name and a list of MonitorModes.

MonitorMode represents screen mode of the monitor. For now the only useful monitor mode properties are resolution and refresh rate. Any other parameters of monitor mode are supposed to be selected by user by looking at monitor mode's name (which describes the mode in implementation-dependent way).

Output is abstract class represents some place where graphics output can be done. Output can represent a window in Windows, a window onto connection with X.org server, whole TV screen, etc.

Device represents active graphics device. Device contains methods to create resources, such as textures and vertex buffers. Device also creates Presenters.

Presenter is an object performs presenting graphics onto an Output. Presenter usually controls two or more image buffers, which flips every frame. Presenter also processes resizing of Output it connects to.

Context is an object performs actual drawing. Context works as a command queue with current state. Context's state is represented by instance of ContextState struct (more about that below). Context is able of clearing render buffers and depth buffers, pushing data to dynamic buffers, and issuing drawing commands.

RenderBuffer, DepthStencilBuffer. Should be clear :)

Texture is a piece of graphics data loaded into device.

SamplerState, BlendState are states of graphics pipeline used by Context when drawing. Note that states are mutable.

VertexShader, PixelShader represent shaders loaded from binary (or not so binary) blobs. Format of binary shaders depends of graphics system.

Binding Vertex Data

In order to draw some vertices, you have to create several objects.

VertexLayout keeps format of vertices in vertex buffer. There should be only one instance of that class for every vertex format. Vertex layout consists of several VertexLayoutElements. Each such element have a type of the data, and offset in bytes from the beginning of the vertex.

AttributeLayout knows what the vertex shader want to get. It consists of several AttributeLayoutSlots, and several AttributeLayoutElements. Slots are actually placeholders for the vertex buffers, so vertex shader can use several vertex buffers simultaneously. Each slot have independent divisor. Zero divisor means indexed slot, non-zero divisor means per-instance slot.

Creation of AttributeLayoutElement requires VertexLayoutElement.

Those classes are general. But to use them with a particular device, you need to create device-dependent AttributeBinding. This object holds all information needed to attach vertex buffers to required slots of the vertex shader. AttributeBinding is created by Device from only AttributeLayout.