The speed was driving me crazy, so I chanced by the NVidia website and got the latest drivers... the speed has increased rapidly now, even using glDrawPixels. I'm guessing that there was some issue with my drivers from the crash I had a few weeks back (computer has never been right since).

I'm going to revisit this again in a few days and implement the glTexSubImage2D solution properly. It was a similar speed to the glDrawPixels before the driver update, so hopefully I'll get the full speed I can out of my crappy card by keeping the texture in VRAM.

Cheers guys, you all just made my credits page =)

ooo i've just come up with a genius idea [grin]

Instead of drawing it as once huge texture, break it up into smaller textures so that you have textures which are say 32*512, so you'll probably need 23 of them to make it smooth.
Then, as you draw you draw then strips on screen, scrolling as you need (thus 23 instead of 20 strips to cover the overlap and provide some left/right buffering) and when something falls off left of the screen you refill it with new data from the right.

The overall update frequency of the data is reduced and so is the data transfered, which means any stress will be on the drawing and not on the update.
More strips would mean less requirement to update as often, but higher memory overhead, so you might want to experiment to get a balance.
Also, keep in mind that if you are filtering you'll want a 2 pixel overlap between each strip and a slight inset in the texture coords to ensure things line up, i'll leave the details as an exercise for the reader.

edit:
Just seen your post above, glad to see you've got some speed increase, depending on the whole update method's speed you might want to investigate this idea as well, but thats your call.
Good luck with it [grin]

I just realised, the way my data is sotred in memory doesn't seem to be compatible with either glDrawPixels or glTexSubImage2D... I'm loading from TGA with the data stored as RGBA, but annoyingly the image becomes 'corrupt' when the image is bigger than the screen size. I'm guessing it's because of the way the TGAs are saved *sigh*. This is annoying me now :/

But I'll get there!

_the_phantom_, I had that idea myself (indeed that's what I meant by panelling). I wonder how well it'd work in practice.. Worth giving it a shot though [grin]

Edit: How does OpenGL expect the data to be store in memory for glDrawPixels?

If you had a 2 x 2 image, would the data be represented as:

RGBA1 RGBA1 RGBA2 RGBA2

or

RGBA1 RGBA2 RGBA1 RGBA2

I think this is what my problem is...

You can change how it expects it using the glPixelStore() function, look up chapter 8 in the red book (pgs 307,313,315 and 319, for those with the 4th ed, are all relivent starting points)

Yeap, I solved this during the GDNet downtime. The problem was indeed down to the GL_UNPACK_ROW_LENGTH (or whatever), it needed to be the width of the bitmap.

Thanks all who helped, this is now working very nicely :)

good good, I did infact try to post that answer above pre-down time, so if gdnet hadnt have died it might have saved you a few mins [grin]

The glPixelStore() function and related bits seem to be one of the most overlooked and non-understood functions out there, even I was guilty of ignoring it until recently..