🔒 Locked

2d Background stretched

Started by Milkies Oct 10, 2006 at 3:40 AM 2 replies 600+ views

Original Post

Oct 10, 2006 at 3:40 AM

Hi all. Im using directx9 The screen resolution i am using is 1024x786. I wish to load the same size image from a file onto the screen as a background image (as the image is the same size as the screen it will be static). What I have done so far is to create a 2d rectangle using customvertex to hold the image like so

[SOURCE]
  struct CUSTOMVERTEX t_vert[] =
    {
		{512, 384,0, 0xffffffff, 0, 0,},
		{-512, 384,0, 0xffffffff, 1, 0,},
		{512, -384, 0, 0xffffffff, 0, 1,},
		{-512,-384,0, 0xffffffff, 1, 1,},
      };

[/SOURCE]

and then render the rectangle to the screen. The problem is that the rectangle doenst fit the entire screen even though it is the same size as the screen. The width takes up the whole screen but the height doesnt. So i recoded the above structure like so

[SOURCE]
  struct CUSTOMVERTEX t_vert[] =
    {
		{512, 512,0, 0xffffffff, 0, 0,},
		{-512, 512,0, 0xffffffff, 1, 0,},
		{512, -512, 0, 0xffffffff, 0, 1,},
		{-512,-512,0, 0xffffffff, 1, 1,},
      };

[/SOURCE]

this turns the rectangle into a square and does take up the whole screen. However since the image isnt a square (1024x768) the image is slightly stretched vertically. EDIT: Sorry my explanation seems really bad. I'll try again. The image I want to map to the screen is 1024x768 which is 4:3. The screen resolution is also 1024x768, 4:3. I created a 4:3 rectangle to map the image onto. The image is perfectly in proportion but strangely the 4:3 rectangle doesnt map perfectly onto the 4:3 screen resolution (when the width of the rectangle takes up all the width of the screen the height of the rectangle is smaller than the height of the screen). When i change the rectangle to a square (1:1) it does take up the entire screen but the 4:3 image is then being mapped onto a 1:1 squre which causes the image to stretch vertically. What technique do I use to successfully map the 4:3 background onto the 4:3 screen without it stretching? Thanks

reana1

Oct 10, 2006 at 10:53 AM

Sounds like a powers of 2 issue. If the image is actually 1024x768, then it may be stretched to the next largest power of 2. I can't recall the details (depends on video card) - looking for a link now...
The width and height descriptions here explain a little:
D3DXCreateTextureFromFileEx
Try taking the 1024x768 and making it 1024x1024 then drawing it so that the the bottom (part you don't care about) is cut off at the bottom of the screen like you want.

[Edited by - reana1 on October 10, 2006 11:53:12 AM]

reana1

Oct 10, 2006 at 6:46 PM

Yeah, it may not be the powers of 2 if you are handling it right. But after testing in my code with a full screen image, I saw a difference in the u/v calculations. See my code below.

      // these are computed or inputs, but for a 1024x768 image at upper left corner of screen:      screenX = -512;       // upper-left sceen coord to draw at      screenY = 384;      intXTextureTL = 0;    // coords of texture in file      intYTextureTL = 0;      intXTextureBR = 1024;      intYTextureBR = 768;      m_batchTexWidth = 1024;  // size of texture loaded from file      m_batchTexHeight = 1024; // note converted to 1024 when loaded since not power of 2      screenWidth = 1024; // not actual screen res, but pixels on screen of quad to be drawn      screenHeight = 768; // but in this case they happen to be the same      m_batchVertices[m_numBatchVertices].color = color;      m_batchVertices[m_numBatchVertices].x = screenX - 0.5f;      m_batchVertices[m_numBatchVertices].y = screenY - 0.5f;      m_batchVertices[m_numBatchVertices].z = 1.0f;      m_batchVertices[m_numBatchVertices].u = intXTextureTL / m_batchTexWidth;      m_batchVertices[m_numBatchVertices].v = intYTextureTL / m_batchTexHeight;         m_batchVertices[m_numBatchVertices + 1].color = color;      m_batchVertices[m_numBatchVertices + 1].x = screenX + screenWidth - 0.5f;      m_batchVertices[m_numBatchVertices + 1].y = screenY - 0.5f;      m_batchVertices[m_numBatchVertices + 1].z = 1.0f;      m_batchVertices[m_numBatchVertices + 1].u = intXTextureBR / m_batchTexWidth;      m_batchVertices[m_numBatchVertices + 1].v = intYTextureTL / m_batchTexHeight;         m_batchVertices[m_numBatchVertices + 2].color = color;      m_batchVertices[m_numBatchVertices + 2].x = screenX + screenWidth - 0.5f;      m_batchVertices[m_numBatchVertices + 2].y = screenY - screenHeight - 0.5f;      m_batchVertices[m_numBatchVertices + 2].z = 1.0f;      m_batchVertices[m_numBatchVertices + 2].u = intXTextureBR / m_batchTexWidth;      m_batchVertices[m_numBatchVertices + 2].v = intYTextureBR / m_batchTexHeight;         m_batchVertices[m_numBatchVertices + 3].color = color;      m_batchVertices[m_numBatchVertices + 3].x = screenX - 0.5f;      m_batchVertices[m_numBatchVertices + 3].y = screenY - screenHeight - 0.5f;      m_batchVertices[m_numBatchVertices + 3].z = 1.0f;      m_batchVertices[m_numBatchVertices + 3].u = intXTextureTL / m_batchTexWidth;      m_batchVertices[m_numBatchVertices + 3].v = intYTextureBR / m_batchTexHeight;

It's been too long since I coded this so I'd have to read up on it, but I think I did it like that to handle non-powers of 2. Normally, my u and v are 1's and 0's like yours (for a single sprite in a file), but in this case it has to be a fraction of the full texture since you don't want the bottom part from 768 to 1024 (since it's been scaled up). So in your code, it would be the following:

// I think this is right, but I'm usign a TRIANGLELIST and you must be using// one of the other options, so I'm not sure.// Whichever coordinates (u/v) corresponds to the lower edge of the texture// needs to be scaled down to 768/1024.  struct CUSTOMVERTEX t_vert[] =    {		{512, 384,0, 0xffffffff, 0, 0,},		{-512, 384,0, 0xffffffff, 1, 0,},		{512, -384, 0, 0xffffffff, 0, 768/1024,},		{-512,-384,0, 0xffffffff, 1, 768/1024,},      };

Of course, it still may be something else since your video card might handle powers of 2 (but I think you have to tell DX to let it use non-powers of 2). So the problem might still be elsewhere.

Oh, and the -0.5 terms are to handle direct texel to pixel mapping issues, which usually works fine for me. The one exception is when I'm writing to the top of the screen (as in this case) and the image is off by 1 row. So I've got something messed up somewhere with the -0.5s (I think) or I need to handle the edge of the screen differently, but it's on my TODO list (EDIT: Actually I think the 0.5s are fine. I think my problem is elsewhere. Probably has to do with getting ranges mixed up (i.e 0 to 1024 should be 0 to 1023 or vice-versa). But that's got nothing to do with your issue.).

[Edited by - reana1 on October 10, 2006 7:46:27 PM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.