@LarsG :
i must have misunderstood then. i actually based some of my work on an example from these boards. the example was one that showed how to do a "tiled" map, except that the example showed how to draw the tiles to the buffer, then create an image to be used statically, until the boundaries of the "view" changed, at which time, the example would redraw the backbuffer with the changed set of tiles, capture the image, and store the result.
in my implementation, this seemed to have the effect of being very fast when scrolling around on top of the captured image, but would come to its knees when the map was scrolling, because it was doing a capture every time an edge moved passed the image boundary.
this was without any optimization on my part, so i know it could have been better.
in any event, i quickly realized that this methodology wasn't quite what i thought i wanted for my game.
i wanted a more colorful and diverse background for my scroller.
i wanted a "map" for my top down shooter that was more like a painting of the terrain, rather than being an assembled set of tiles.
so, this is where i am now.
trying to understand the pros/cons of having "one big image" as the "lowest layer" of my shooter.
i still don't understand the "texture sizes" issue.
i've seen folks talk about "texture size" and what video cards can handle.
how does this affect me ?
i'm pretty sure for instance, than even with my "scrolling tiles" code that i had working, that i was exceeding 4k and/or 256x256 for the captured image.
this seemed to have no effect on how my code worked.
i assume that generally, "^2" sizes of things probably makes the computer/video crad more effecient, and not exceeding the amound of memory on the video card for texes is a good thing, but other than those issues, how important is it for me, the developer, to have to worry about the details of how a given video card deals with textures.
thanks for all of the input so far.
Tony
i must have misunderstood then. i actually based some of my work on an example from these boards. the example was one that showed how to do a "tiled" map, except that the example showed how to draw the tiles to the buffer, then create an image to be used statically, until the boundaries of the "view" changed, at which time, the example would redraw the backbuffer with the changed set of tiles, capture the image, and store the result.
in my implementation, this seemed to have the effect of being very fast when scrolling around on top of the captured image, but would come to its knees when the map was scrolling, because it was doing a capture every time an edge moved passed the image boundary.
this was without any optimization on my part, so i know it could have been better.
in any event, i quickly realized that this methodology wasn't quite what i thought i wanted for my game.
i wanted a more colorful and diverse background for my scroller.
i wanted a "map" for my top down shooter that was more like a painting of the terrain, rather than being an assembled set of tiles.
so, this is where i am now.
trying to understand the pros/cons of having "one big image" as the "lowest layer" of my shooter.
i still don't understand the "texture sizes" issue.
i've seen folks talk about "texture size" and what video cards can handle.
how does this affect me ?
i'm pretty sure for instance, than even with my "scrolling tiles" code that i had working, that i was exceeding 4k and/or 256x256 for the captured image.
this seemed to have no effect on how my code worked.
i assume that generally, "^2" sizes of things probably makes the computer/video crad more effecient, and not exceeding the amound of memory on the video card for texes is a good thing, but other than those issues, how important is it for me, the developer, to have to worry about the details of how a given video card deals with textures.
thanks for all of the input so far.
Tony