I expect that most graphics cards have some kind of maximum texture size limit. Some older cards can't do a texture bigger than 256x256. Apart from hitting those kind of limits, if you can work around that I dont see any problem why you cant have a bigger image and scroll it around.
Scroll techniques with OpenGL and such can be a bit trickier than the old-school methods. It's mainly because you don't have a hardware pointer that you can just change to scroll the screen, and usually the whole backbuffer has to be reassembled every frame because it gets trashed.
There are several different scrolling techniques.
One that you might consider is to have a texture (image) which is a little taller and wider than one full screen, e.g.640+64 x 480+64 (or whatever is the next nearest multiple of 64 depending on whether you break things up into smaller tiles). Then, when you scroll, let's say down and to the right, you just move the coordinates of where your `top left` is, in the image. You of course then have to draw your image in four parts. You let things wrap off the right and left edges and the top and bottom edges. You then use the `hidden` extra strip down the edges to copy strips of new graphics from main memory or from another texture. So if you are moving down and to the right, you replace the strip at the top and left with new graphics and it eventually scrolls into view. You keep the memory upload stuff to a minimum by only uploading the least amount of strip possible each frame, which if important cus the bus bandwidth is low and uploading (to the existing texture) uses the CPU.
I don't think there's any problem with using a really big bitmap if that's what you want to do. It's the only way to go for games like Worms and Scorched Earth, for exmaple. You can't really use repetitious tiling there.
As far as changing that superbitmap and storing changes goes, you would have to spool those off to main memory as they occur - or have your own software drawing routines which draw in main memory on an identical bitmap and then upload parts of it as it scrolls.
Scroll techniques with OpenGL and such can be a bit trickier than the old-school methods. It's mainly because you don't have a hardware pointer that you can just change to scroll the screen, and usually the whole backbuffer has to be reassembled every frame because it gets trashed.
There are several different scrolling techniques.
One that you might consider is to have a texture (image) which is a little taller and wider than one full screen, e.g.640+64 x 480+64 (or whatever is the next nearest multiple of 64 depending on whether you break things up into smaller tiles). Then, when you scroll, let's say down and to the right, you just move the coordinates of where your `top left` is, in the image. You of course then have to draw your image in four parts. You let things wrap off the right and left edges and the top and bottom edges. You then use the `hidden` extra strip down the edges to copy strips of new graphics from main memory or from another texture. So if you are moving down and to the right, you replace the strip at the top and left with new graphics and it eventually scrolls into view. You keep the memory upload stuff to a minimum by only uploading the least amount of strip possible each frame, which if important cus the bus bandwidth is low and uploading (to the existing texture) uses the CPU.
I don't think there's any problem with using a really big bitmap if that's what you want to do. It's the only way to go for games like Worms and Scorched Earth, for exmaple. You can't really use repetitious tiling there.
As far as changing that superbitmap and storing changes goes, you would have to spool those off to main memory as they occur - or have your own software drawing routines which draw in main memory on an identical bitmap and then upload parts of it as it scrolls.