tsoding/olive.c

Simple 2D Graphics Library for C

Olive.c

IMPORTANT! THIS LIBRARY IS A WORK IN PROGRESS! ANYTHING CAN CHANGE AT ANY MOMENT WITHOUT ANY NOTICE! USE THIS LIBRARY AT YOUR OWN RISK!

Simple graphics library that does not have any dependencies and renders everything into the given memory pixel by pixel.

Visit https://tsoding.github.io/olive.c/ to see some demos.

The library is not concerned with displaying the image. It only fills up the memory with pixels. It's up to you what to do with those pixels.

The name is pronounced as "olivets'" which is a Ukrainian word for "pencil" ("олівець").

The library itself does not require any special building. You can simply copy-paste ./olive.c to your project and #include it. (Because the truly reusable code is the one that you can simply copy-paste).

Olive.c is a classical stb-style single header library. That is by default it acts like a header, but if you #define OLIVEC_IMPLEMENTATION prior including the library it acts like a source file. The .c extension might be confusing, but it's a part of the name of the library (why JavaScript people can use .js as part of the name of a library and I cannot?)

Quick Example (Flag of Japan)

This example also uses stb_image_write.h to create the PNG image

// flag_jp.c
#define OLIVEC_IMPLEMENTATION
#include "olive.c"

#define STB_IMAGE_WRITE_IMPLEMENTATION
#include "stb_image_write.h"

#define WIDTH 900
#define HEIGHT 600

uint32_t pixels[WIDTH*HEIGHT];

int main(void)
{
    Olivec_Canvas oc = olivec_canvas(pixels, WIDTH, HEIGHT, WIDTH);
    // Taken from https://upload.wikimedia.org/wikipedia/en/9/9e/Flag_of_Japan.svg
    olivec_fill(oc, 0xFFFFFFFF);
    olivec_circle(oc, WIDTH/2, HEIGHT/2, 180, 0xFF2D00BC);

    const char *file_path = "flag_jp.png";
    if (!stbi_write_png(file_path, WIDTH, HEIGHT, 4, pixels, sizeof(uint32_t)*WIDTH)) {
        fprintf(stderr, "ERROR: could not write %s\n", file_path);
        return 1;
    }
    return 0;
}

Building the Tests and Demos

Even though the library does not require any special building, the tests and demos do. We use nobuild build system:

$ clang -o nobuild nobuild.c
$ ./nobuild

Tests

Run the tests:

$ ./build/test run

If the expected behavior of the library has changed in the way that breaks current test cases, you probably want to update them:

$ ./build/test update

For more info see the help:

$ ./build/test help

Demos

The source code for demos is located at demos. Each demo is compiled for 3 different "platforms" that is 3 different ways to display the generated images:

1. SDL -- displays the images via SDL_Texture.
2. Terminal -- converts the images into ASCII art and prints them into the terminal.
3. WASM -- displays the images in HTML5 canvas

To run the SDL version of a demo do

$ ./build/demos/<demo>.sdl

To run the Terminal version of a demo do

$ ./build/demos/<demo>.term

To run the WASM versions of the demos from https://tsoding.github.io/olive.c/ locally do

$ python3 -m http.server 6969
$ iexplore.exe http://localhost:6969/

Virtual Console

The support for several platforms is provided by Demo Virtual Console. It is implemented in two files:

• ./demos/vc.c -- the C runtime required by all platforms.
• ./js/vc.js -- the JavaScript runtime for running in a browser when compiled to WebAssembly.

The Demo Virtual Console is not part of the main library and is designed specifically for demos. (I do consider including it into the main library, 'cause it looks pretty useful. The library is still in development).

olive.c's Issues

font8x8 suggestion / request

The in-built font could become about 1/8th the size, by using a system like font8x8 does.

Instead of having a font that looks like so:

0, 0, 0, 1, 1, 0, 0, 0
0, 0, 1, 0, 0, 1, 0, 0
0, 0, 1, 0, 0, 1, 0, 0
0, 0, 1, 1, 1, 1, 0, 0
0, 0, 1, 0, 0, 1, 0, 0
0, 0, 1, 0, 0, 1, 0, 0
0, 0, 1, 0, 0, 1, 0, 0
0, 0, 1, 0, 0, 1, 0, 0

It could look like so:

0b00011000,
0b00100100,
0b00100100,
0b00111100,
0b00100100,
0b00100100,
0b00100100,
0b00100100,

Only being 8 bytes instead of 64.

I've used this system myself and it works really well for having small fonts, which are still easy to process, since it only requires a little amount of bitshifting.
I have my own function from a little engine, which draws some multiline text, while using 8x8 bitfonts.

how to find the url about the first live broadcast of olive.c,

This is not a bug, I just want to ask for help, I want to learn the first live broadcast of olive.c, but I can't find the video of the first episode now, maybe the live broadcast video has expired. Can you again provide a first live video about olive.c? Now the first episode of Olive Live is lol

unrecognised emulation mode: i386pep

$ ./build.sh

C:\MinGW\bin\ld.exe: unrecognised emulation mode: i386pep
Supported emulations: i386pe
clang.exe: error: linker command failed with exit code 1 (use -v to see invocation)

[Optimization]: Optionally adding restrict keyword when possible (depending on the minimal C standard requirement you want for this library)

Hello tscoding,

First, I really think you did a nice job by providing this library (funny part: I was doing exact same rasterizing stuff myself as a side project when you started olive on streams ;) ).

I don't know what's your minimum requirement for this library to be (maybe C89?), but if targetting standard C99 as minimal requirement, maybe you could add some restrict keyword when it's appropriate.

For example, in this kind of function:

OLIVECDEF bool olivec_barycentric(int x1, int y1, int x2, int y2, int x3, int y3, int xp, int yp, int *u1, int *u2, int *det)
{
...
}

The compiler can't really guess that u1, u2 and det won't alias to each other. With restrict keyword provided, I guess it would make some compiler optimization possible (actually I need to do some benchmark to check that point).

There are several cases in the olive library where that could fit pretty well.

Anyway, thanks again for your streams, it's really cool to watch them some time to time when chilling on youtube/twitch.

Nope. giving up.

Hi,
read about this on HackerNews and it sounded great and exactly what I need. You might want to have stable and development versions (new code needs a "stride" parameter for instance) but even then the development version should work from the demo on the front page. And what should I expect when I get the front page demo code to compile and run it? I think flag_jp.c produced flag_jp.png? .. and index .html? ... Nope. Could you say what we should expect from doing the first demo perhaps.

Alpha blending bug

It appears the bug from "Programming in C in 2022" is still present.

This is because when blending colours you use the alpha value of the "incoming" colour to calculate the new blended RGB colour components for the pixel, but the alpha component of the pixel is never updated.

So if the canvas initially starts filled with zeroes, then each pixel will always have alpha 0. And blended colour writes will never modify this. So the final exported image will have the correct R/G/B values, but always have alpha 0 in every pixel.

You probably want to "accumulate" the alpha from both the current colour on the canvas, and the "incoming" colour. For example, if the canvas contains a pixel with 25% alpha, and you draw a pixel with 50% alpha on top, the resulting alpha should be greater than 25%. But the current code will never modify it.

Weird teapot geometry

Isn't there something funny going on with the teapot?
The handle and the spout don't quite seem on opposite sides of it.

This is what it should look like, right?

I think it is particularly noticeable in the term version where without the shadows

Arbitrary color bit depth

It would be nice to be able to run olive.c on 8 bit pixels, for example.

The example code of Japan flag

I am not really sure about the mechanism of this project, but I can definitely tell that there is a parameter called Stride is missing (I don't know if it is suppose to be a variable that require us to define the value, since the result of the same stride value is varies in different computers, if it is not, then there should be a problem, for me I set the number of stride to 900)

SDL ERROR: Invalid rectangle dimensions for LockTexture. [FIXED]

Complies fine. Tests pass.
All the SDL demos return the error in the title:
SDL ERROR: Invalid rectangle dimensions for LockTexture.

I'm on OS X and that's probably part of the issue. :/
I've worked with SDL just a bit, but not on a mac