Scrolling background?

Just wondering how one goes about implementing a scrolling background in a 2D game. In direct draw I learned to manipulate the pixels of an image directly. Thus I could place my background to the backbuffer in a way as to simulate it scrolling.

However, I'm not sure about how to implement this method in Direct3D at all (if it is even possible.. i don't know).

I tried a different approach. Can someone tell me if this is OK or if it is a very bad performance idea.

I have a .bmp 640x480 that I want to scroll. So I loaded it into a IPD3DXSPRITE structure and drew it to the screen twice. One right after the other as to simulate a 1280x480 texture and just moved it horizontally.

My second case is a .bmp 1280x182 that I also want to scroll. So I split it up into two 640x182 pieces and did the same steps as above.

Is this a good idea to do? Does drawing 3/4ths of a texture offscreen still require the computer to do stuff. (I.E. Am I wasting unnecessary computing?)

Cause it seems like my program is occasionally hiccuping and all I have is 3 textures loaded and four IPD3DXSPRITE calls per frame..

Should I be restricting my Render() calls via a timer or should I just let it call Render() as much as it can? Cause my program is using nearly 100% of the CPU constantly which doesn't seem kosher to me..

I tried to attach my 2 "scrolling" textures as well as an exe so you could get a visual of what I'm trying to do, but the upload feature is a real ..........' about size...

Anyways thnx for any help.

You could create a bitmap which is the length of the map, and have a variable storing the left and right coordinates. Scrolling is just adding to (scroll right), or subtracting from (scroll left) the two variables. The only other thing is you have to either make the bitmap wrap, or make sure the right and left coordinates are valid.

You can do per-pixel scrolling in many ways.

• Use a very large bitmap
• Use a per-pixel algorithm
• Use tiles/tile maps

The problem with using a very large bitmap is you will be limited by the maximum size of a texture accepted by your video card.

The per-pixel algorithm requires you to lock and unlock the back buffer which is extremely slow.

The tile version is the easiest to implement and the most robust. It is, however, a bit tricker to code.

I have the start of a 2D scroller and the scrolling portion is done, however spoon feeding it to you will not help. Try it on your own first and then come back and post about the problems you are having.

Quote:

---

You can do per-pixel scrolling in many ways.

* Use a very large bitmap
* Use a per-pixel algorithm
* Use tiles/tile maps

---

I guess I'm not getting the concept of tiles/tile maps.. I've tried to do some GOOGLING but didn't really find a lot of resources.

For a 2D game such as Age of Empires, Hex-based games I understand the use of tiles/tile maps to create a "world". To use repeating textures such as grass, trees, rocks, etc...

But what if I'm creating a sidescrolling shooter. (I.e. airplane stationary while background scrolling right to left). Are tiles/tile maps something I should be looking at? If I got a background image 640x480 should I divide it into vertical strips and then draw my background this way? when a vertical strip leaves the left of the screen I just draw it to the right side of the screen?

About a large bitmap size of my map. Its not a performance issue that at any given time 75% of the bitmap is drawn offscreen? (I haven't really divulged to much into how DirectX clips)

Quote:

---

About a large bitmap size of my map. Its not a performance issue that at any given time 75% of the bitmap is drawn offscreen? (I haven't really divulged to much into how DirectX clips)

---

DirectX doesn't have to do any clipping because you pass a rect of the coordinates in the bitmap you wan't rendered. So no, it's won't affect performance at all.

Quote:

---

Originally Posted by MadCow257

DirectX doesn't have to do any clipping because you pass a rect of the coordinates in the bitmap you wan't rendered. So no, it's won't affect performance at all.

---

Oh yeah I wasn't thinking there :) Geez.. I'm quite dumb..

So should I just use two RECT structures for a single background image that I wish to scroll?

Then just alter the two RECT struct values?

As one RECT shrinks the other grows.

Draw the shrinking one to the left side of the screen and the growing one to the right side... wouldn't this simulate scrolling background?

Then ones the shrinking one reaches 0 width just reset it back to the whole bitmap and start all over?

This good idea?

To scroll an image using u,v coordinated you just translate the u,v's and you will scroll the image. In Direct3D you can use a matrix to transform the u,v's but you could just as easily change the u,v's off all the vertices of the quad being used as the scrolling window.

Again you will be limited by the size of the texture.