[SDL] Best way to implement a simple "Framebuffer"

[Patrick Baggett]

Wait, if he's not using an SDL surface, why is he posting here? This is the
cult of SDL. SHUN THE DISBELIEVER. :D

But seriously, yeah, don't plot pixels directly to the hardware -- the
hardware is designed to do stuff in batches and can apply transformations
like scaling. So in other words, batch all of your pixel operations by doing
them on a SDL surface then use the hardware to perform scaling.

On Mon, Sep 26, 2011 at 9:36 AM, Benjamin Shadwick <benshadwick at gmail.com>wrote:

> Maybe try creating a 32x32 pixel SDL surface and set individual pixels on
> that, then have SDL stretch it to the desired size when blitting it to the
> screen surface.
>
> On Mon, Sep 26, 2011 at 7:31 AM, nils.stec <nils-stec at spectra-light.de>wrote:
>
>> **
>> For a 6502 emulator i'm writing at the moment i'm searching for a
>> efficient way to use SDL with it.
>>
>> This emu has a 64k address space, starting at 0x200 there are 1024 bytes.
>> The graphics screen is 32x32 pixels in it's size. Every byte is a one color.
>> It's compatbile to the online-emu located here:
>> http://www.6502asm.com/beta/index.html
>> If you want to try it, choose an example from the drop down list, click on
>> compile and then click on run. you will see the graphics output on the
>> window to the right.
>>
>> The color defines are:
>>
>>
>>
>>  Quote:
>>
>>
>>
>> Black ($0)
>> White ($1)
>> Red ($2)
>> Cyan ($3)
>> Purple ($4)
>> Green ($5)
>> Blue ($6)
>> Yellow ($7)
>> Orange ($[image: Cool]
>> Brown ($9)
>> Light red ($a)
>> Dark gray ($b)
>> Gray ($c)
>> Light green ($d)
>> Light blue ($e)
>> Light gray ($f)
>>
>>
>>
>>
>> At the moment i have a function which calculates the pixel position, the
>> corresponding sdl color value in RGBA format and draws a filled box of 8x8
>> pixels for one pixel in this 32x32 byte memory space.
>>
>>
>>
>>
>>  Code:
>>
>>
>> int set_px(int x, int y, unsigned char pxcol) {
>>    unsigned char r,g,b,a=255;
>>    pxcol &= 0x0f;
>>    switch(pxcol) {
>>       case 0:      // black
>>          r = 0; g = 0;   b = 0;
>>          break;
>>       case 1:      // white
>>          r = 255; g = 255; b = 255;
>>          break;
>>       case 2:      // red
>>          r = 135; g = 0;   b = 0;
>>          break;
>>       case 3:      // cyan
>>          r = 40; g = 240; b = 255;
>>          break;
>>       case 4:      // purple
>>          r = 200; g = 70; b = 200;
>>          break;
>>       case 5:      // green
>>          r = 0; g = 255;   b = 0;
>>          break;
>>       case 6:      // blue
>>          r = 0; g = 0; b = 255;
>>          break;
>>       case 7:      // yellow
>>          r = 230; g = 220; b = 10;
>>          break;
>>       case 8:      // orange
>>          r = 230; g = 155; b = 85;
>>          break;
>>       case 9:      // brown
>>          r = 100; g = 70; b = 0;
>>          break;
>>       case 10:   // light red
>>          r = 255; g = 120; b = 120;
>>          break;
>>       case 11:   // dark gray
>>          r = 50; g = 50;   b = 50;
>>          break;
>>       case 12:   // gray
>>          r = 100; g = 100; b = 100;
>>          break;
>>       case 13:      // light green
>>          r = 170; g = 255; b = 100;
>>          break;
>>       case 14:   // lblue
>>          r = 10; g = 160; b = 240;
>>          break;
>>       case 15:   // light grad
>>          r = 180; g = 180; b = 180;
>>          break;
>>       default:
>>          r = 0; g = 0; b = 0;
>>          a = 255;
>>          break;
>>    }
>>
>>    boxRGBA(screen, x*PIXEL_SIZE, y*PIXEL_SIZE, (x*PIXEL_SIZE)+PIXEL_SIZE,
>> (y*PIXEL_SIZE)+PIXEL_SIZE, r, g, b, a);
>>
>>    return 0;
>> }
>>
>>
>>
>> This isn't very efficient. On my Core2Duo with an onboard Intel card
>> running Linux with the opensource drivers i get about 30 frames per second,
>> on my Phenom II with an Radeon 3000 running Linux with the closed source
>> ATI-Drivers (fglrx) i get around 300 frames per second.
>>
>> On my Pentium 4, 1,4Ghz, Nvidia Geforce 4 MX440 64MB, i get with the
>> closed source nvidia drivers about 20 frames per second.
>> This is the screen updating routine:
>>
>>
>>
>>
>>  Code:
>>
>>
>>       for(x = 0; x < 32; x++) {
>>          for(y = 0; y < 32; y++) {
>>             addr = graphix_address+(x+(y*32));  // calculate address
>> starting at 0x200, 1 line is 32 bytes in size, 32 lines on screen
>>             set_px(x,y, get6502memory(addr));    // give set_px the byte
>> in "graphics" memory
>>          }
>>       }
>>
>>
>>
>>
>> I hope anyone of you know a better and faster solution for this.
>>
>>
>> ------------------------------
>>
>> If you're interested in Embedded Linux and Microcontrollers have a look at
>> my (german) page:
>> http://krumeltee.wordpress.com/
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>>
>
>
> --
> - Ben S.
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110926/0fbbf83e/attachment.htm>