Drawing Pixels With Dart

 

Stefan Matthias Aust

·

Follow

10 min read

113

1

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

Inspired by the videos of OneLoneCoder I wanted to play around with simple pixel graphics. Instead of using C++ or Swift (as I’m using a Mac) I wanted to use Dart. And in the spirit of OLC I wanted to create the most basic solution that could possibly work. Therefore, I figured that adding SDL to a Dart console application might be the right way to go. And all I want to use from SDL is some basic commands to for drawing colourful pixels.

Unfortunately, so it seems, nobody went this route before, and when I tried to create a native Dart extension for SDL, I found out that at least on macOS, it doesn’t really work because I couldn’t figure out how to make the extension use the main thread which is the only thread that may control the UI. There was an extension for GLFW (a similar technology) but again without support for macOS.

Because of this and because creating native extension for the Dart VM isn’t that fun, I came up with the following plan:

Why not create a minimal console application in C that opens an SDL window, reads drawing commands from stdin and displays them until stdin is closed. This application is then started by my Dart command line application and fed with as much drawing commands as I like.

First steps with SDL

After installing SDL on my system via Homebrew, I created the following C code, derived from an example. It was an interesting experience to write this without any kind of IDE support, but I figured, that the C part should be simple enough to write that code in any text editor.

The application initialises the graphics subsystem, opens a small window somewhere on the screen, and waits for the user to close the window. Then it correctly shuts down.

#include <stdio.h>
#include "SDL2/SDL.h"SDL_Window *window;int main(int argc, char **argv) {
  SDL_Init(SDL_INIT_VIDEO);
  
  window = SDL_CreateWindow(
    "SDL Test",
    SDL_WINDOWPOS_UNDEFINED,
    SDL_WINDOWPOS_UNDEFINED,
    320,
    200,
    0
  );
  if (!window) return 1;  SDL_Event e;
  while (SDL_WaitEvent(&e)) {
    if (e.type == SDL_QUIT) break;
  }  SDL_DestroyWindow(window);  SDL_Quit();  return 0;
}

I compiled the application and successfully tested it:

$ cc -I/usr/local/include -L/usr/local/lib -lsdl2 -Wall console.c
$ ./a.out

Drawing Stuff

To draw something, I went for directly using the window’s surface instead of recreating everything on each frame (using renderers). It seemed easier to do this way. That surface must be explicitly updated, though. After realising, that drawing single pixels can be generalised as filling rectangles, I shall present my next experiment:

  ...
  if (!window) return 1;  SDL_Surface *screen = SDL_GetWindowSurface(window);
  if (!screen) return 1;  SDL_Rect rect = { 20, 40, 60, 80 };
  Uint32 rgb = SDL_MapRGB(screen->format, 240, 120, 0);
  SDL_FillRect(screen, &rect, rgb);
  SDL_UpdateWindowSurface(window);  SDL_Event e;
  ...

Compiling and running it revealed a small but beautiful orange rectangle.

Putting It Together

Next, I decided that I want to specify the window title and the window position and size using command line arguments. Optionally, I also want to specify the pixel size, aiming for a retro pixel look on my 5K monitor. In hindsight, it might be easier and more efficient to let SDL scale the surface.

I came up with the following list of graphics commands:

• c rgb set the fill color
• r x y w h draw a filled rectangle with the current color
• u update the window

I implemented them in process_command() shown below. The function will return 1 if the application shall quit and 0 otherwise. In main() I evaluate the command line arguments, retrieved the SDL_Surface to draw on, and read lines using fgets() from stdin to process them. This function will return NULL on EOF.

#include <stdio.h>
#include "SDL2/SDL.h"SDL_Window *window;
SDL_Surface *screen;
int pixelsz = 1;int process_command(char *buf) {
  static Uint32 rgb;  if (!buf) return 1;
  switch (buf[0]) {
  case 'c': {
    int c;
    sscanf(++buf, "%d", &c);
    rgb = SDL_MapRGB(screen->format,
      (c >> 16) & 255, (c >> 8) & 255, c & 255);
    return 0;
  }
  case 'r': {
    SDL_Rect rect;
    sscanf(++buf, "%d%d%d%d", &rect.x, &rect.y, &rect.w, &rect.h);
    rect.x *= pixelsz;
    rect.y *= pixelsz;
    rect.w *= pixelsz;
    rect.h *= pixelsz;
    SDL_FillRect(screen, &rect, rgb);
    return 0;
  }
  case 'u':
    SDL_UpdateWindowSurface(window);
    return 0;
  default:
    return 0;
  }
}int _pos(int i) {
  return i < 0 ? SDL_WINDOWPOS_UNDEFINED : i;
}int main(int argc, char **argv) {
  if (argc < 6) return 1;  if (argc >= 7) pixelsz = atoi(argv[6]);  SDL_Init(SDL_INIT_VIDEO);
  
  window = SDL_CreateWindow(
    argv[1],
    _pos(atoi(argv[2])),
    _pos(atoi(argv[3])),
    atoi(argv[4]) * pixelsz,
    atoi(argv[5]) * pixelsz,
    0
  );
  if (!window) return 1;  screen = SDL_GetWindowSurface(window);
  if (!screen) return 1;  SDL_Event e;
  while (SDL_WaitEvent(&e)) {
    if (e.type == SDL_QUIT) break;
    
    char buf[64];
    if (process_command(fgets(buf, 64, stdin))) break;
  }  SDL_DestroyWindow(window);  SDL_Quit();  return 0;
}

After compiling, this kind-of works:

$ ./a.out 'Hello World' -1 -1 160 100 4
c 15759360
r 20 30 40 50
u
^D

Unfortunately, reading from stdin blocks the event loop and makes the window unresponsive. I unsuccessfully searched for some way to also listen for file descriptors (similar to select) within SDL’s event loop. Then I tried to made stdin non-blocking and switched to SDL_PollEvent which worked, but consumed 100% CPU.

Therefore, I eventually used another thread and a user defined SDL event like this:

Uint32 command; // custom SDL event typeint command_loop(void *data) {
  SDL_Event e = {};
  e.type = command;
  do {
    char buf[64];
    if (fgets(buf, 64, stdin)) {
      e.user.data1 = strdup(buf);
    } else {
      e.user.data1 = NULL;
    }
    SDL_PushEvent(&e);
  } while (e.user.data1);
  return 0;
}...int main() {
  ...  if ((command = SDL_RegisterEvents(1)) == (Uint32)-1) return 2;
  if (!SDL_CreateThread(command_loop, NULL, NULL)) return 2;  SDL_Event e;
  while (SDL_WaitEvent(&e)) {
    if (e.type == SDL_QUIT) break;
    if (e.type == command) {
      if (process_command(e.user.data1)) break;
      free(e.user.data1);
    }
  }  ...
}

Now, the application automatically quits when stdin is closed and stays response so that closing the window with ⌘Q or by clicking the close button works, too.

Last But Not Least, Dart

Let’s start with an abstraction for RGB values. Right now, it only wraps a 32 bit integer, but I could imagine to later add methods to derive lighter or darker shades of colours or supports different colour spaces like i.e.HSL.

class Color {
  final int value;  const Color(this.value);
  
  const Color.rgb(int red, int green, int blue) 
    : value = (red << 16) | (green << 8) | blue;  int get red => (value >> 16) & 255;
  int get green => (value >> 8) & 255;
  int get blue => value & 255;
}

Then I created some constants with the same names as Flutter uses, only because I know and often use them. It took me five minutes or so to copy all hex values from the Material Design specification.

class Colors {
  static const black = Color(0x000000);
  static const white = Color(0xFFFFFF);
  static const red = Color(0xF44336);
  static const pink = Color(0xE91E63);
  static const purple = Color(0x9C27B0);
  static const deepPurple = Color(0x673AB7);
  static const indigo = Color(0x3F51B5);
  static const blue = Color(0x2196F3);
  static const lightBlue = Color(0x03A9F4);
  static const cyan = Color(0x00BCD4);
  static const teal = Color(0x009688);
  static const green = Color(0x4CAF50);
  static const lightGreen = Color(0x8BC34A);
  static const lime = Color(0xCDDC39);
  static const yellow = Color(0xFFEB3B);
  static const amber = Color(0xFFC107);
  static const orange = Color(0xFF9800);
  static const deepOrange = Color(0xFF5722);
  static const brown = Color(0x795548);
  static const gray = Color(0x9E9E9E);
  static const blueGray = Color(0x607D8B);
  Colors._();
}

Later, I also want to abstract points and rectangles, but for now, without further ado, let’s implement the Console class which wraps and drives the SDL command line application created above (still called a.out).

class Console {
  final Process _process;
  final int width;
  final int height;  Console._(this._process, this.width, this.height) {
    clear();
  }  void close() {
    _process.stdin.close();
  }  Color _color = Colors.white;
  Color get color => _color;
  set color(Color color) {
    _color = color;
    _process.stdin.writeln('c${color.value}');
  }  void clear([Color color = Colors.black]) {
    _process.stdin.writeln('c${color.value}');
    _process.stdin.writeln('r0 0 $width $height');
    _process.stdin.writeln('c${_color.value}');  
  }  void point(int x, int y) {
    _process.stdin.writeln('r$x $y 1 1');
  }  void rect(int x, int y, int width, int height) {
    _process.stdin.writeln('r$x $y $width $height');
  }  void update() {
    _process.stdin.writeln('u');
  }  static Future<Console> create(
    int width, int height, [int scale = 1]
  ) async {
    return Console._(
      await Process.start(
        './a.out',
        ['Dart', '-1', '-1', '$width', '$height', '$scale'],
      ),
      width,
      height,
    );
  }
}

The only way to create an instance of Console is the static method Console.create(...). And becauseProcess.start() uses futures, this method is also asynchronous.

Just for fun, I also implemented line() using Bresenham’s algorithm, which took longer than expected because I failed to correctly copy the code from Wikipedia and didn’t find the mistake as fast as I would have liked. It might be an interesting exercise to also implement an algorithm to fill circles or triangles (or polygons). But I digress.

Random Rectangles

Let’s put Console to use with this example application:

void main() async {
  final r = Random();
  final c = await Console.create(160, 160, 8);  while (true) {
    c.color = Color.rgb(
      r.nextInt(256),
      r.nextInt(256),
      r.nextInt(256),
    );
    final w = r.nextInt(40) + 10;
    final h = r.nextInt(40) + 10;
    final x = r.nextInt(c.width - w);
    final y = r.nextInt(c.height - h);
    c.rect(x, y, w, h);
    c.update();
  }
}

Running the application with the C a.out binary in the same directory as the Dart source code will result in a colourful window:

Too, bad, that my approach doesn’t work as expected.

After a few seconds, the window stops drawing rectangles. I tried to debug the Dart application and it works as expected. The C application also works as expected. My guess is, that because the Dart VM normally runs on a single thread, the endless while loop makes it impossible for the I/O subsystem to send more data from the Dart VM to the C application.

Here is a (somewhat unsatisfying) workaround I found: Instead of using an endless loop, I’m using a periodic timer that fires 60 times a second. This way, the Dart runtime seems to work as expected.

void main() async {
  final r = Random();
  final c = await Console.create(160, 160, 8);Timer.periodic(Duration(milliseconds: 1000 ~/ 60), (_) {
    c.color = Color.rgb(
      r.nextInt(256),
      r.nextInt(256),
      r.nextInt(256),
    );
    c.line(
      r.nextInt(c.width),
      r.nextInt(c.height),
      r.nextInt(c.width),
      r.nextInt(c.height),
    );
    c.update();
  });
}

Now my “engine” works as expected, drawing blocky lines consisting of tiny little rectangles, sending all commands to the C process.

An Animation Only I Can See

Because I’m using a periodic timer, I can create a simple animation demonstrating moving circles (which I implemented using the Bresenham mid point algorithm). Because circles are somewhat complex, I cannot display more than, say, 20 or again the Dart process fails to send everything to the C application.

class Circle {
  double x, y, vx, vy;
  int r;
  Color c;  Circle(this.x, this.y, this.r, this.vx, this.vy, this.c);  static const colors = [
    Colors.red, Colors.blue, Colors.green, 
    Colors.brown, Colors.yellow];
}void main() async {
  final r = Random();
  final c = await Console.create(160, 160, 8);  final circles = List.generate(15, (index) {
    final ra = r.nextInt(28) + 3;
    return Circle(
      (r.nextInt(c.width - ra * 2) + ra).toDouble(),
      (r.nextInt(c.height - ra * 2) + ra).toDouble(),
      ra,
      (r.nextInt(11) - 5).toDouble() / 2,
      (r.nextInt(11) - 5).toDouble() / 2,
      Circle.colors[index % 5],
    );
  });  Timer.periodic(Duration(milliseconds: 1000 ~/ 60), (_) {
    c.clear();
    for (var circle in circles) {
      circle.x += circle.vx;
      circle.y += circle.vy;
      if (circle.x < circle.r || circle.x >= c.width - circle.r)
        circle.vx *= -1;
      if (circle.y < circle.r || circle.y >= c.height - circle.r)
        circle.vy *= -1;
      c.color = circle.c;
      c.drawCircle(circle.x.toInt(), circle.y.toInt(), circle.r);
    }
    c.update();
  });
}

Unfortunately, the screenshot below also reveals that the algorithm I copied from Wikipedia has some problems with drawing small circles (the red one looks more like a rectangle than a circle).

When (or if) I find out why my idea of communicating via file streams have some limitations, I will update this article.

Update (05.01.2019)

After some debugging, I found the cause for why the window stopped drawing after a few seconds. The SDL event queue, I’m using to pass the commands sent from the Dart process to the C application’s main thread, can hold only up to 65535 events. Here is a new version of command_loop() which checks whether SDL_PostEvent will fail to retry after a short moment:

int command_loop(void *data) {
  SDL_Event e = {};
  e.type = command;
  do {
    char buf[64];
    if (fgets(buf, 64, stdin)) {
      e.user.data1 = strdup(buf);
    } else {
      e.user.data1 = NULL;
    }
    Uint32 ms = 1;
    while (SDL_PushEvent(&e) < 0 && ms < 1 << 10) {
        SDL_Delay(ms);
        ms <<= 1;
    }
  } while (e.user.data1);
  return 0;
}

Now, everything works as expected.