Shading "realtime", terrain pixel-per-pixel

Hello

I wrote a few functions to gouraud-shade polygons and so i thought i could use it on a test-terrain. I'm talking about 2D now, and so I used a Pixmap the size of the screen (640x480), created an array of the PixelPtr Data and change the colours that way.
It's just a major problem that it's bloody slow. YFlipping the pixmap in DrawPixmap nearly halves the FPS from 60 to 35, but I have no idea to "plot" pixels realtime.

Buffering the stuff in an image is fast, but the problem appears again while scrolling, because I have to edit the pixmap of the image and save the changes, where UnlockImage slows everything down as well. Not a good idea for scrolling, thought.

The drawing itself is somehow slow as well for the entire screen, so I have to store the graphic in an image. Dunno how to edit it then as I said before.

Any suggestions from your side?

Thanks in advance

When you draw a pixmap to the screen, it's actually sending a whole load of commands to the graphics card - it tells the card to draw each pixel individually. This is slow.

Drawing an image is much faster because it stores the image data on the graphics card before-hand so it your program only needs to say "draw that image there". The disadvantage is that it's difficult to draw to a texture that's already on the video card.

OpenGL polygons are Gauraud shaded anyway, by the way. Software rendering's fun, but if you've got an accelerated graphics card it's much quicker to give the card a list of steps to perform and let it do what it's good at.

glBegin GL_QUADS
    glColor3b(255,0,0)
    glVertex2f(100.0, 100.0)

    glColor3b(0,255,0)
    glVertex2f(200.0, 100.0)

    glColor3b(0,0,255)
    glVertex2f(200.0, 200.0)

    glColor3b(255,0,255)
    glVertex2f(100.0, 200.0)
glEnd

Should draw a Gauraud-shaded square with a different colour for each corner.

I saw on one of the tutorials in the BlitzMAX OpenGL forum that it is possible to upload small parts of a texture, rather than having to upload the whole texture on one go. If this is correct, perhaps modifications to LockImage and UnlockImage could be made to speed things up.