-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Sun Mar 16, 2014 11:04 am

AndyD wrote:Welcome back!
Thanks!
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Sun Mar 16, 2014 11:10 am

cleverca22 wrote:
-rst- wrote:Yes, SDL at the moment is not the best choice for performance on RPi - it lacks (afaik)...
i happen to be working on a port of SDL with proper hardware 3d support, so far all it can do is build a vertex list for a frame, but once i get a texture shader working, i can start to render a frame
Interesting! Forum fellow Vanfanel's dispmanx backed SDL is a very good start, but I suppose there is much more that can be done...
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Sun Mar 16, 2014 3:44 pm

A new post with a solution to the flicker-free animation using the framebuffer: http://raspberrycompote.blogspot.ie/201 ... rt_16.html
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

cleverca22
Posts: 202
Joined: Sat Aug 18, 2012 2:33 pm

Re: Low-level (Linux framebuffer) graphics programming tutor

Sun Mar 16, 2014 6:44 pm

so far, this is the output
Image

and this is what it should look like
Image

the mess of colors is to be expected, i don't have a texture shader yet, so its working as intended

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Fri Mar 21, 2014 3:59 pm

New blog post about animations /effects that do not necessarily require page flipping / v-sync: http://raspberrycompote.blogspot.ie/201 ... rt_21.html - includes the ever hot fire effect :mrgreen:
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

cleverca22
Posts: 202
Joined: Sat Aug 18, 2012 2:33 pm

Re: Low-level (Linux framebuffer) graphics programming tutor

Fri Mar 21, 2014 10:01 pm

and i now have full texture and color support, its able to render this one frame fully, only took a few weeks to get one frame, lol

Image

Boreal
Posts: 5
Joined: Sat Jan 04, 2014 8:48 pm
Location: Denver, Colorado USA
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Sun Mar 23, 2014 2:59 am

-rst- wrote:New blog post about animations /effects that do not necessarily require page flipping / v-sync: http://raspberrycompote.blogspot.ie/201 ... rt_21.html - includes the ever hot fire effect :mrgreen:
Greetings! And thanks -rst- for your Raspberry Compote. You've been very influential.

I have not been able to make your page-flipping fbtestXII program work and wonder if others have also had problems. I've had no trouble running all your other programs, including the latest fbfire and benchmarks. Here's what I've tried:

downloaded fbtestXII.c from github
downloaded vcio.h from github.
sudo mknod char_dev c 100 0
gcc -lrt -o fbtestXII fbtestXII.c

got message: try mknod mailbox c 100 0

now screen goes completely blank
Ctrl+C Ctrl+D don't do anything.
pull plug to reboot

tried with both LXTerminal and full-screen mode.
tried three versions of Rasbpian.
get same results on both model A and B.

tried two versions of vcio.h:
one says DEVICE_FILE_NAME "mailbox"
other says DEVICE_FILE_NAME "char_dev"

http://www.xpl0.org/rpi/index.html

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Mon Mar 24, 2014 1:43 pm

Boreal wrote:Greetings! And thanks -rst- for your Raspberry Compote. You've been very influential.

I have not been able to make your page-flipping fbtestXII program work and wonder ...
Hi Boreal! Thanks for the kind words - good to hear it's been useful. And sorry to hear the page-flipping did not work.

Not sure if it makes any difference whether one uses 'char_dev' or 'mailbox' - as long as the defines in .h file matches the mknod command parameters.

I could of course have been more specific with the vcio.h file path - this is the one I used https://github.com/raspberrypi/linux/bl ... ach/vcio.h - hope it works for you with this file!

I have noticed that sometimes (apparently after multiple resolution changes, but needs more investigation before logging a bug) the RPi blanks the screen and does not recover :| Sometimes it helps (blindly) typing "fbset -xres 800 -yres 600 -depth 16" or similar as long as it's different from the current mode...
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

Boreal
Posts: 5
Joined: Sat Jan 04, 2014 8:48 pm
Location: Denver, Colorado USA
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Mon Mar 24, 2014 3:11 pm

-rst- wrote:Sometimes it helps (blindly) typing "fbset -xres 800 -yres 600 -depth 16" or similar...
:D Ahh! Everything magically works if I type "fbset -depth 8" after booting.
Each run now says done in 49 s 999 ms.

Before, with the blank screen, I got impatient and started hitting Ctrl+C etc. and never waited the 49 seconds.

Look for your page flipping to be added to the XPL0 programming language soon ... and thanks again for all your help.

http://www.xpl0.org/rpi/index.html

cleverca22
Posts: 202
Joined: Sat Aug 18, 2012 2:33 pm

Re: Low-level (Linux framebuffer) graphics programming tutor

Mon Mar 24, 2014 8:02 pm

Boreal wrote: Before, with the blank screen, I got impatient and started hitting Ctrl+C etc. and never waited the 49 seconds.
i did the same thing and broke a terminal window, alt+f2 got a new one, but there are only 6 available by default

then i read the source and found that it will restore the modes upon exit, if you let it exit cleanly

needs a sigint handler to catch ctrl+c

Boreal
Posts: 5
Joined: Sat Jan 04, 2014 8:48 pm
Location: Denver, Colorado USA
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Tue Mar 25, 2014 1:19 am

Boreal wrote:Everything magically works if I type "fbset -depth 8" after booting.
Each run now says done in 49 s 999 ms.
Lest anyone is concerned about the 49 seconds, when I compile fbtestXIII.c is with optimization on (-O2), it runs in 9 seconds! :o

Also, as mentioned by -rst- it doesn't seem to matter what fbset changes the depth to, as long as it changes it. For example, changing from 8 back to 16 doesn't cause fbtestXIII to display a blank screen.

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Thu Apr 10, 2014 2:41 pm

Boreal wrote:
Boreal wrote:Each run now says done in 49 s 999 ms.
Lest anyone is concerned about the 49 seconds, when I compile fbtestXIII.c is with optimization on (-O2), it runs in 9 seconds! :o
At first look I was a bit startled to see that but I guessed this might have been the explanation ;)
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Thu Apr 10, 2014 2:43 pm

There is a new blog post up: drawing simple shapes
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Fri Apr 18, 2014 5:49 pm

And another one on displaying simple text
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

User avatar
bleep42
Posts: 129
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed May 28, 2014 9:04 am

Hi rst,
Thanks very much for your blogs, I found them by accident while googling. I've used your example code around about part 8 to implement a version of Life. I had been using a library from http://www.cl.cam.ac.uk/projects/raspbe ... intro.html, but this was relatively slow, I could see that the screen buffering and updating was taking more time than the Life generation, (admittedly in a window, which will be slower) so I put it on hold till I saw your blog. I've now reworked it and am very pleased to be getting almost 400 generations a second, with a 704x450 buffer. My next task is to load in a bitmap for the start generation, at the moment I hard code a few cells, which multiply up.
Thanks again for all your work, very useful. :-) Kevin.

User avatar
AndyD
Posts: 2320
Joined: Sat Jan 21, 2012 8:13 am
Location: Melbourne, Australia
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed May 28, 2014 12:07 pm

bleep42 wrote:... getting almost 400 generations a second, with a 704x450 buffer...
That is pretty amazing. I wrote a version of life using DispmanX to demonstrate double-buffering. I am limited by the refresh rate of the display (60Hz for PAL), but can only maintain 60 iterations per second with a 500x500 cell grid. Any larger grid and the iterations start to take more than 1/60 of a second.

User avatar
bleep42
Posts: 129
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed May 28, 2014 9:25 pm

AndyD wrote:
bleep42 wrote:... getting almost 400 generations a second, with a 704x450 buffer...
That is pretty amazing. I wrote a version of life using DispmanX to demonstrate double-buffering. I am limited by the refresh rate of the display (60Hz for PAL), but can only maintain 60 iterations per second with a 500x500 cell grid. Any larger grid and the iterations start to take more than 1/60 of a second.
Hi Andy.
Give it a try. :-) My Pi is overclocked and I used -O2 compile flag to optimise it, but I would think 300 generations on a standard Pi, let me know. It's best to run it from a normal shell, outside X as your X windows will be written over. I'm afraid I only hacked it together and haven't tidied it up, or properly commented it yet. :-(
Regards, Kevin.

Code: Select all

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>

void set_cell( unsigned int, unsigned int );
void clear_cell( unsigned int, unsigned int );
void put_pixel(int, int, int);

#define X_MAX 704 // 1440
#define Y_MAX 450 // 900
unsigned int length_in_bytes = (X_MAX * Y_MAX);
unsigned char field[X_MAX][Y_MAX]={0};
unsigned char field_new[X_MAX][Y_MAX]={0};
char *fbp = 0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;


int main(int argc, char *argv[])
{
unsigned int generations, x, y;
unsigned int cell_count, cell_count4;
unsigned int group, screensize = 0;
unsigned char *cell_ptr;
unsigned long *cell_ptr4;
int fbfd = 0;
char *pixel;
struct fb_var_screeninfo orig_vinfo;


  // Open the file for reading and writing
  fbfd = open("/dev/fb0", O_RDWR);
  if (!fbfd) {
    printf("Error: cannot open framebuffer device.\n");
    return(1);
  }
  printf("The framebuffer device was opened successfully.\n");

  // Get variable screen information
  if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
    printf("Error reading variable information.\n");
  }
  printf("Original %dx%d, %dbpp\n", vinfo.xres, vinfo.yres, 
     vinfo.bits_per_pixel );

  // Store for reset (copy vinfo to vinfo_orig)
  memcpy(&orig_vinfo, &vinfo, sizeof(struct fb_var_screeninfo));

  // Change variable info - force 8 bit and resolution
  vinfo.bits_per_pixel = 8;
  vinfo.xres = X_MAX;
  vinfo.yres = Y_MAX;
  vinfo.xres_virtual = vinfo.xres;
  vinfo.yres_virtual = vinfo.yres;

  if (ioctl(fbfd, FBIOPUT_VSCREENINFO, &vinfo))
  {
    printf("Error setting variable information.\n");
  }
  if (ioctl(fbfd, FBIOPUT_VSCREENINFO, &vinfo))
  {
    printf("Error setting variable information.\n");
  }
    
  // Get fixed screen information
  if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo))
  {
    printf("Error reading fixed information.\n");
  }

  // map fb to user mem 
  screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
  fbp = (char*)mmap(0, 
        screensize, 
        PROT_READ | PROT_WRITE, 
        MAP_SHARED, 
        fbfd, 
        0);

  if ((int)fbp == -1)
  {
    printf("Failed to mmap.\n");
  }
  else
  {
    // draw...

    // fill the screen with blue
    memset(fbp, 1, vinfo.xres * vinfo.yres);
    /* Set a few pixies */
    set_cell( 13, 10 );
    put_pixel(13, 10, 15);
    set_cell( 13, 11 );
    put_pixel(13, 11, 15);
    set_cell( 13, 12 );
    put_pixel(13, 12, 15);
    set_cell( 12, 12 );
    put_pixel(12, 12, 15);
    set_cell( 11, 11 );
    put_pixel(11, 11, 15);
    set_cell( 100, 100 );
    put_pixel(100, 100, 15);
    set_cell( 101, 100 );
    put_pixel(101, 100, 15);
    set_cell( 102, 100 );
    put_pixel(102, 100, 15);
    set_cell( 202, 150 );
    put_pixel(202, 150, 15);
    set_cell( 203, 150 );
    put_pixel(203, 150, 15);
    set_cell( 204, 150 );
    put_pixel(204, 150, 15);
    set_cell( 303, 199 );
    put_pixel(303, 199, 15);
    set_cell( 304, 199 );
    put_pixel(304, 199, 15);
    set_cell( 305, 199 );
    put_pixel(305, 199, 15);
    
    /* loop round for each generation */
    for( generations=0; generations < 4000; generations++ )
    {
      memcpy(&field[0][0], &field_new[0][0], length_in_bytes);

      cell_ptr4 = (unsigned long*)&field[0][0];     // first cell in cell map

      /* Loop for each row and column */
      for( cell_count4=0; cell_count4 < (X_MAX * Y_MAX / 4); cell_count4++ )
      {
        /* Is there an active cell in the next 4 cells */
        if( *(cell_ptr4 + cell_count4) )
        {
          /* Individually check the next 4 cells */
          cell_ptr = &field[0][0] + (cell_count4 * 4);
          for( group=0; group < 4; group++ )
          {
            if( *cell_ptr )
            {
              /* Check if existing cell survives */
              cell_count = *cell_ptr >> 1;
              if( *cell_ptr & 0x01 )
              {
                if( cell_count != 2 && cell_count != 3 )
                {
                  y = ((cell_count4*4)+group) / X_MAX;
                  x = ((cell_count4*4)+group) - (y * X_MAX);
                  clear_cell( x, y );
                  /* kill the cell on screen */
                  put_pixel(x, y, 0);
                }
              }
              else  /* See if new cell created */
              {
                if( cell_count == 3 ) 
                {
                  y = ((cell_count4*4)+group) / X_MAX;
                  x = ((cell_count4*4)+group) - (y * X_MAX);
                  set_cell( x, y );
                  /* set the cell on screen */
                  put_pixel(x, y, 15);
                }
              }
            }
            /* Move on to next cell */
            cell_ptr++;
          } // end group loop
        } // end if
      } // end cell loop

    } // end Generations loop

    // wait for 2 seconds to give us a chance to see the changes
    sleep(2);

  }

  // cleanup
  munmap(fbp, screensize);
  if (ioctl(fbfd, FBIOPUT_VSCREENINFO, &orig_vinfo))
  {
      printf("Error re-setting variable information.\n");
  }
  close(fbfd);

  return 0;
}


/* Check all 8 cells around cell */
void set_cell( unsigned int x, unsigned int y )
{
int xoleft, xoright, yoabove, yobelow;
unsigned int wi = X_MAX;
unsigned int hi = Y_MAX;
unsigned char *cell_ptr = &field_new[0][0] + ( y * wi ) + x;
   
  // Calculate the offsets to the eight neighboring cells,
  // accounting for wrapping around at the edges of the cell map
  xoleft  = (x == 0) ? wi - 1 : -1;
  yoabove = (y == 0) ? length_in_bytes - wi : -wi;
  xoright = (x == (wi - 1)) ? -(wi - 1) : 1;
  yobelow = (y == (hi - 1)) ? -(length_in_bytes - wi) : wi;

  /* Clear this cell & decrement the counts of the surrounding cells */
  *(cell_ptr) |= 0x01;
  *(cell_ptr + yoabove + xoleft) += 2;
  *(cell_ptr + yoabove ) += 2;
  *(cell_ptr + yoabove + xoright) += 2;
  *(cell_ptr + xoleft) += 2;
  *(cell_ptr + xoright) += 2;
  *(cell_ptr + yobelow + xoleft) += 2;
  *(cell_ptr + yobelow) += 2;
  *(cell_ptr + yobelow + xoright) += 2;
}

/* Check all 8 cells around cell */
void clear_cell( unsigned int x, unsigned int y )
{
int xoleft, xoright, yoabove, yobelow;
unsigned int wi = X_MAX;
unsigned int hi = Y_MAX;
unsigned char *cell_ptr = &field_new[0][0] + ( y * wi ) + x;
   
  // Calculate the offsets to the eight neighboring cells,
  // accounting for wrapping around at the edges of the cell map
  xoleft  = (x == 0) ? wi - 1 : -1;
  yoabove = (y == 0) ? length_in_bytes - wi : -wi;
  xoright = (x == (wi - 1)) ? -(wi - 1) : 1;
  yobelow = (y == (hi - 1)) ? -(length_in_bytes - wi) : wi;

  /* Clear this cell & decrement the counts of the surrounding cells */
  *(cell_ptr) &= ~0x01;
  *(cell_ptr + yoabove + xoleft) -= 2;
  *(cell_ptr + yoabove ) -= 2;
  *(cell_ptr + yoabove + xoright) -= 2;
  *(cell_ptr + xoleft) -= 2;
  *(cell_ptr + xoright) -= 2;
  *(cell_ptr + yobelow + xoleft) -= 2;
  *(cell_ptr + yobelow) -= 2;
  *(cell_ptr + yobelow + xoright) -= 2;
}

/* Function to 'plot' a pixel in given color */
void put_pixel(int x, int y, int c)
{
  // calculate the pixel's byte offset inside the buffer
  unsigned int pix_offset = x + (y * finfo.line_length);

  // now this is about the same as 'fbp[pix_offset] = value'
  *((char*)(fbp + pix_offset)) = c;
}

User avatar
AndyD
Posts: 2320
Joined: Sat Jan 21, 2012 8:13 am
Location: Melbourne, Australia
Contact: Website

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed May 28, 2014 10:38 pm

bleep42 wrote:... Hi Andy. Give it a try. :-) ...
Yep, impressive. I put some timing code around your loop. I measured around 278 iteration per second for your code on my Model B with no overclocking. I never thought of keeping the neighbour counts! Good stuff.

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Fri Jan 16, 2015 5:18 pm

Cleaned up 'pure fb' version of the double-buffering example and some info on the display blanking issue:
https://github.com/rst-/raspberry-compo ... btestXIV.c
and
http://raspberrycompote.blogspot.ie/201 ... -part.html
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

hglm
Posts: 30
Joined: Fri May 31, 2013 8:24 pm

Re: Low-level (Linux framebuffer) graphics programming tutor

Tue Feb 24, 2015 12:45 am

You might be interested in this:

I experimented with the kerrnel fb layer driver for the Raspberry Pi 1/2 and it turns out it is pretty straightforward to extend the framebuffer visible to console applications from one screen buffer to three buffers. This makes double or triple-buffering possible for regular console graphics, without resorting to dispmanx or EGL/GLES2.

The syscall used for PanDisplay (FBIOPUT_VSCREENINFO) works correctly and can be used for triple-buffering. I also extended the DMA-accelerated CopyArea that is available in the kernel to cover all buffers. This can be used to blit large regions (also from off-screen pages) pretty fast, especially on an overclocked RPi. The CopyArea syscall only returns when completed, however it does free up the CPU when doing large transfers, so there's potential for getting more work done with multiple threads.

The kernel patches for this (which are relatively straightforward, requiring only a few minor changes) are available at https://github.com/hglm/patches/tree/ma ... /extend-fb and as a git branch of a kernel fork at https://github.com/hglm/linux/tree/extend-fb.

In order to test this functionality I also wrote a small graphics library called "DGL" which supports page flipping and DMA accelerated copyarea as well as general software blits and fills. It is available at https://github.com/hglm/dgl. It includes a demo program that tests various kinds of blit and smooth animation with triple buffering (the latter is only available when running a patched kernel).

One disadvantage is that in order to use display panning/multi-buffering, the console has to be switched to graphics mode (KD_GRAPHICS), which requires root/super-user priviledges. KD_GRAPHICS mode can also cause text input to be invisible, for example when a program crashes or is interrupted, requiring action to restore textmode (for example, blindly executing a command that restores textmode or reboots the system). The DGL library takes measures to prevent this from happening.

I've made available kernel images incorporating the patches for Raspberry Pi (http://www.file-upload.net/download-103 ... b.img.html) and Raspberry Pi 2 (http://www.file-upload.net/download-103 ... b.img.html).

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Thu Feb 26, 2015 4:41 pm

Very much interesting - will take a look. Thanks.
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

dr_when
Posts: 1
Joined: Tue Mar 17, 2015 11:59 pm

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed Mar 18, 2015 12:10 am

RST,

Thank you so much for your graphics tutorial in Raspberry Compote. It has certainly helped me get off the ground with something I am working on. So far, I don't know if my approach is the best.

I have a need of taking some Windows print files (.prn) that have small Microsoft DIB images embedded inside. I would like to be able to simply plug in a flash drive into the PI and then display these b/w images one by one. Where I have been having a problem is just figuring the least painful way of doing this. I hav e studied Python and PIL thinking that might be a way to go. But then again using C on the PI and rendering these images to memory mapped video might be a faster option but then of course I lose the ease of a gui in Tkinter. I am just a newbie enough to get a lot of these details confused.

Any idea's from the pros on this forum? I hope I made clear what I am attempting!

Thanks!!

Bob

jehamann
Posts: 35
Joined: Sun Jun 16, 2013 11:36 pm
Contact: AOL

Re: Low-level (Linux framebuffer) graphics programming tutor

Thu Mar 19, 2015 3:40 am

has anybody been having a problem with the program window size???
Attachments
pi20150223_012240_opt.jpg
pi20150223_012240_opt.jpg (43.62 KiB) Viewed 3549 times

User avatar
cyberbrain6
Posts: 1
Joined: Fri Nov 13, 2015 6:41 am

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed Nov 18, 2015 12:09 am

@ -rst-
(not sure the best way to contact you so trying here)

are you aware that comments are disabled on
http://raspberrycompote.blogspot.com ?

Just wanted to give you a heads up in case this was unintentional.

Really love these tutorials,
thanks so much for them!

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Low-level (Linux framebuffer) graphics programming tutor

Wed Nov 18, 2015 6:41 pm

Thanks cyberbrain6, nice to hear the blog has been of use!

The reason I disabled the comments is that unfortunately I cannot guarantee I have time to read and respond - and I would feel bad for the unanswered messages. Was sort of hoping to direct the traffic here where the wider community could participate in answering...
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

Return to “Graphics programming”

Who is online

Users browsing this forum: No registered users and 1 guest