Best way to implement a simple "Framebuffer"

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:

Black ($0)
White ($1)
Red ($2)
Cyan ($3)
Purple ($4)
Green ($5)
Blue ($6)
Yellow ($7)
Orange ($8)
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:

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 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, xPIXEL_SIZE, yPIXEL_SIZE, (xPIXEL_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.

Ok this is just going to be picky and maybe the compiler will catch these
sort of things for you but…

Why do you have a default case in the switch, it will never get there!

What is alpha a variable, the ‘a’. It only has one value ever. That could be
a constant.

In your drawing code you could rewrite it by swapping the x and y loops over
allowing the y*32 to be calculated less.

for(y = 0; y < 32; y++) {
y32 = y * 32;
for(x = 0; x < 32; x++) {
addr = graphix_address+x+y32; // 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
}
}

Ok this will draw the screen column by row rather than row by column (or is
it the other way around). But you should get a little speed up with this,
not sure if this is the sort of thing a compiler can catch - it would be
nice if it could.

Finally given that r, g and b as initially assigned the value 255 I would
remove them from the case statements.

As I said this is just nitpicking and will be of only marginal help but I’m
in that sort of mood today :slight_smile:

You should definitely try Benjamin’s suggestion.

**
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;
}

Use a lookup table here. You’ve got 16 colors, so create an array with 16
elements. Each element becomes the color. Then you can do:

unsigned int colorTable[16] =
{
0xFF000000; //black
0xFFFFFFFF; // white

....

};

In effect, the lowest 8 bits are the red color, the next 8 bits are the
green color, then blue, then alpha. Keeping it as a single unsigned int is
likely faster since most machines can write a 4-byte value about as fast as
they can write a single byte value. To use the table, you simply look up the
color in the table:

unsigned int colorEntry = colorTable[pxcol];

r = colorEntry & 0xFF;
g = (colorEntry >> 8) & 0xFF);
b = (colorEntry >> 16) & 0xFF;
a = (colorEntry >> 24) & 0xFF;

boxRGBA(screen, xPIXEL_SIZE, yPIXEL_SIZE, (xPIXEL_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
}
}

First off, reverse your inner/outer loop. This will immediately improve
performance, especially when doing >> 32x32 rendering areas. This is because
the pixels at (x, y) and (x, y+1) in memory are actually quite far away,
while (x,y) and (x+1,y) are literally right next to each other. You can
actually use that to your advantage by not computing the address every time.
For example, if you have a 32x32 image with each pixel being 32 bits (4
bytes), then (0,0) is 0 bytes from the start of the image, and (1,0) is 4
bytes from the start, (2,0), is 8 bytes from the start, etc. So to write a
row of pixels you don’t need to do:

for(x=0; x<32; x++) {
base_address + x + y*32;

}

Look at what changes in the for() loop. ‘Y’ doesn’t. The base_address
doesn’t. So you can precompute these like this:

for(y=0; y<32; y++) {

row_base = base_address + y*32;

for(x=0; x<32; x++) {

    pixel = row_base + x;

}

}

If you know the graphics address is absolutely fixed, then you don’t need to
use a variable and can just #define a constant like #define GFX_ADDR 0x200.

The address computation fix applies to set_px() – do you really need to
recompute the address each time? You could just take a point and add 4 to it
each time (assuming 32-bit pixels) to get the x+1 pixel.

Mainly, you just need to focus on things in terms of rows and how to do
absolutely minimal amounts of work to plot the next pixel. For example, a
clear screen sort of operation doesn’t need to be a double-nested for() loop
that sets each pixel to black, it can just be memset(framebuffer, 0,
3232sizeof(int)).

Finally, on a stylistic note, you probably shouldn’t be hard coding 32x32
all over your program. You’ll probably want to expand your screen some time
without changing every instance of 32. Use a #define for it – the compiler
doesn’t output any slower code for it, but it does make it much easier to
change stuff.

PatrickOn Mon, Sep 26, 2011 at 9:31 AM, nils.stec wrote:

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

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

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 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 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, xPIXEL_SIZE, yPIXEL_SIZE, (xPIXEL_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

Here is what I would do:

  • create a color map as array of SDL_Color once
  • in display loop
    – get emulator screen data as a byte array
    – convert into surface using SDL_CreateRGBSurfaceFrom
    – assign color map with SDL_SetColors
    – scale surface using SDL_gfx’s zoomSurface function or use
    DirectX/OpenGL hardware scalingOn 9/26/11 7:31 AM, nils.stec 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 ($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, xPIXEL_SIZE, yPIXEL_SIZE,
(xPIXEL_SIZE)+PIXEL_SIZE, (yPIXEL_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

Personally this is how I would approach it, assuming we have an SDL_Surface that has been created to point at our unsigned int fb[1024] array…

We can just convert the pixels like this.

Then we can scale up using the appropriate SDL blit function.

I could easily have written this routine to do the scale-up while processing pixels but it would be less efficient (assuming a hardware implementation of the SDL blit is used).

// this is in BGRA order (suitable for PC), regardless of native endian order.
const unsigned char colortable[16*4] =
{
0,0,0,255, // black
255,255,255,255, // white
0,0,135,255, // red
40,240,255,255, // cyan
200,70,200,255, // purple
0,255,0,255, // green
255,0,0,255, // blue
10,220,230,255, // yellow
85,155,230,255, // orange
0,70,100,255, // brown
120,120,255,255, // light red
50,50,50,255, // dark gray
100,100,100,255, // gray
100,255,170,255, // light green
240,160,10,255, // lblue
180,180,180,255, // light grad
};

// optimized routine for pixel conversion
const unsigned char *pixin = 6502memory + graphix_address; // get the base address of the pixels in the VM
const unsigned int *pal = (const unsigned int *)colortable; // get the palette we’ll decode it with
unsigned int pixout = fb; // get the output address (we have an SDL_Surface whose pixels pointer is this)
for (i = 0;i < 32
32;i++)
pixout[i] = pal[pixin[i]];–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Changing the update routine to this (swapped x/y and removed the calculating of the address) got me about 50fps on my Phenom, not bad, but should be more :wink:

Code:

addr = 0x200;
for(y = 0; y < 32; y++) {
for(x = 0; x < 32; x++) {
set_px(x,y, get6502memory(addr));
addr++;
}
}

Accessing the memory via get6502memory is necessary, because of portability and for the use in other planned emus/changing the output interface. if i access the memory directly by it’s pointer it makes ~~ +20fps.

Next step should be the use of a lookup table for colors, but this gets me a weird gfx output…:

this is what it looks like with my switch/case:
[Image: http://s2.postimage.org/2kfveu1wk/gfx_switchcase.jpg ] (http://postimage.org/image/2kfveu1wk/)

And this is with the lookup table (code following):
The skier starts to skiing and goes upwards instead of downwards. it seems the y coordinates is “negative”, i don’t understand, i simply changed from boxRGBA to boxColor. The wrong colors can be, i think i have some mistakes inside the lut…
[Image: http://s2.postimage.org/kaj2klw38/gfx_colorlut.png ] (http://www.postimage.org/)

After i get this working i will change the code to use a 32x32 surface and use rotozoom to zoom it by factor 8.

No pixel sizes are hardcode, i think, everything should be done with #defines, i want to compile it for my mobile later, so everything needs to be portable ;)[/img]------------------------
If you’re interested in Embedded Linux and Microcontrollers have a look at my (german) page:

I’m not seeing any images – can you double check you’ve attached them and
resend?

PatrickOn Mon, Sep 26, 2011 at 11:42 AM, nils.stec wrote:

**
Changing the update routine to this (swapped x/y and removed the
calculating of the address) got me about 50fps on my Phenom, not bad, but
should be more [image: Wink]

Code:

addr = 0x200;

for(y = 0; y < 32; y++) {
for(x = 0; x < 32; x++) {
set_px(x,y, get6502memory(addr));
addr++;
}
}

Accessing the memory via get6502memory is necessary, because of portability
and for the use in other planned emus/changing the output interface. if i
access the memory directly by it’s pointer it makes ~~ +20fps.

Next step should be the use of a lookup table for colors, but this gets me
a weird gfx output…:

this is what it looks like with my switch/case:
http://postimage.org/image/2kfveu1wk/

And this is with the lookup table (code following):
The skier starts to skiing and goes upwards instead of downwards. it seems
the y coordinates is “negative”, i don’t understand, i simply changed from
boxRGBA to boxColor. The wrong colors can be, i think i have some mistakes
inside the lut…
http://www.postimage.org/

After i get this working i will change the code to use a 32x32 surface and
use rotozoom to zoom it by factor 8.

No pixel sizes are hardcode, i think, everything should be done with
#defines, i want to compile it for my mobile later, so everything needs to
be portable [image: Wink][/img]


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

I can see them, but here are the direct links:

The first image (switch/case for colors):
http://postimage.org/image/2kfveu1wk/

Here the second (the weird):
http://postimage.org/image/2khdzki78/------------------------
If you’re interested in Embedded Linux and Microcontrollers have a look at my (german) page:

Ok, now i have it. I used the wrong byte order in the lookup table, so it seemd to go upwards, because not every pixel was visible.

Now i’ll work on the rest, i’ll give you feedback later.------------------------
If you’re interested in Embedded Linux and Microcontrollers have a look at my (german) page: