In the past week I’ve been working on the design and implementation of the 2D rendering API that will be used as an extension to TinyGL.
I already listed all the features that I wanted to expose in the API and here’s the result:
Blitting api header:
struct BlitTransform { BlitTransform(int dstX, int dstY); void sourceRectangle(int srcX, int srcY, int srcWidth, int srcHeight); void tint(float aTint, float rTint = 1.0f, float gTint = 1.0f, float bTint = 1.0f); void scale(int width, int height); void rotate(float rotation, float originX, float originY); void flip(bool verticalFlip, bool horizontalFlip); Common::Rect _sourceRectangle; Common::Rect _destinationRectangle; float _rotation; float _originX, _originY; float _aTint, _rTint, _gTint, _bTint; bool _flipHorizontally, _flipVertically; }; struct BlitImage; BlitImage *tglGenBlitImage(); void tglUploadBlitImage(BlitImage *blitImage, const Graphics::Surface &surface, uint32 colorKey, bool applyColorKey); void tglDeleteBlitImage(BlitImage *blitImage); void tglBlit(BlitImage *blitImage, const BlitTransform &transform); // Disables blending explicitly. void tglBlitNoBlend(BlitImage *blitImage, const BlitTransform &transform); // Disables blending, transforms and tinting. void tglBlitFast(BlitImage *blitImage, int x, int y);
The API is pretty simple but effective: it allows you to create and delete textures and to blit them. Its implementation under the hood is somewhat more involved: I only have a generic templated function that takes care of blitting, this function has a few parameters that allow me to skip some computation if they’re not needed (skipping pixel blending, sprite transformation or tinting etc).
Since everything else is hidden the implementation can always be expanded and this can allow some aggressive optimizations like RLE encoding or just memcpy-ing the whole sprite if I know it’s totally opaque and blending is not enabled and so on.
For the next week I will keep on refining the implementation to add all those optimized cases and I will also work into integrating this new API on the existing engines: some work has already been done on myst3 engine but there’s still a lot to do for the grim engine as it is way more complex compared to myst3.
I will keep you updated in the next posts as I will probably post more updates this week, stay tuned!