Tile-map performance

Major problem with tile maps and I'm not sure how to solve it.

My tile map uses a repeating grid of vertices. The only thing that changes is the starting texture in the first grid cell or the upper left corner. As you scroll right, the offset increases, down it increases by mapwidth, etc, etc.

Big problem. I'm using DrawPrimitive to draw 1 tile with a texture. This means I'm setting the texture for every single tile being rendered. Big performance drain there.

But is there any way around this?

Positioning each quad in world space would and drawing all quads that share a texture would not be a problem, but....determining which cells are visible might be. I could use a quad tree but I'm not so sure that would be any faster than my current method.

If you're using tiles, you already have a quad tree of sort, and you're probably already culling stuff treating it as so. Setting a texture context is one of the biggest bottlenecks on any card, so cutting down the number of times that gets done.

But why are you setting it each time?

Quote:

---

The only thing that changes is the starting texture in the first grid cell or the upper left corner.

---

Set the texture once at the beginning of a frame, then go through all of those DrawPrimative calls.

I would make some sort of arrays with pointers to the tiles which shares the same texture, and maybe cull them one by one or something. But as you say this might be a slow process. Would it maybe be a good idea to somehow render all of your textures into one big and place that on the smaller primitives and then cull as you currently do? But I wonder if that would drain a lot of memory perhaps.

I've thought about this as well for my terrain engine, but I decided that one big texture would look the best and be least work so I didn't look into this further I'm afraid.

I can't just set the upper left corner and go from there. The upper left corner determines the starting texture in the map.

If the map looks like this:

Quote:

---

1 2 3 4 5 6 7
8 9 1 2 3 4 5
....

---

Scrolling one cell to the right yields this:

Quote:

---

2 3 4 5 6 7 ...
9 1 2 3 4 5 ...
....

---

But you see with each change in value I must change the texture.

And no there is no quad tree here, just a simple ortho projection in screen space with a repeating grid. Movement is achieved by changing the start offset in the map. So it auto-culls everything because it only draw what it visible.

If you have a grid, you have a quad tree (sort of). But I see what you're trying to get at about the scrolling. Spending some extra cycles to order your drawing based on texture will probably still be faster than changing the context each tile.

Depending on the size of your textures and the way you draw them, you might be able to put a few textures into one. That way you don't have to change the context so often, but you will have to worry about setting up the correct uv's for the tiles. The biggest drawback with that though is that you can't wrap textures, and mip/mag filters can look funky if you don't set the texture up correctly.

Ok I think I've come up with a solution.

Instead of thinking old school tile maps I need to break it down into large primitives. Direct3D is very good at doing large primitives with one texture.

Solution:

No tiles at all
Only use tiles in the editor. When I save the tile maps, don't save them as data, but save them as 1024x1024 or 512x512 textures. In other words, save each portion of the map as one texture and stick that in the data file. At run-time I simply render a quad 1024x1024 (or whatever resolution we decide on) and use a quad-tree system to see which quads are on-screen. For those that are within screen limits, draw the whole quad. Hardware is very good at clipping large quads.

So this breaks the DrawPrimitive and SetTexture down from (Tilesize/ScreenWidth)^2 to 4 max for any one screen since it's possible that you could be at the intersection of 4 of these quads.

Tile-specific effects can still be done by using decaling, render to texture, etc, etc. I will still know where in the world the tiles are by just doing a little math based on the world scroll values.

I think this will be a major speed up and will take less memory than storing one instance of each tile. This will free up a lot of resources. It's an odd-way to do pixel perfect scrolling but other methods just don't work anymore.

Scrolling using texture transform flags
Using one large texture won't work either since you cannot fit a 4096x4096 texture in video memory and yet you could have a world size that large. The alternative to this would be to cache in portions of the texture at a time, but again, this requires locking surfaces which is what I want to avoid. I would love to just transform texture u,v's to scroll the picture because it would be uber fast......but I cannot do this. I would have to cache in a portion of the data, use D3DXCreateTexture to make it a texture, and then render it. This would happen at 1024x1024 boundaries and I believe it would cause slow downs. I may even try to store a 4096x4096 texture in a file and then create several smaller textures from it using my tile extraction code. They would just be larger tiles. Then perhaps I may try this image cache scheme and just scroll the u,v's.

For those of you interested in the tile extraction code:

CTextureManager

Code:

---

bool CTextureManager::AddFromFileEx(std::string File,DWORD dwWidth,DWORD dwHeight,
                                    DWORD &dwOutWidth,DWORD &dwOutHeight)
{
  //Create base texture
  IDirect3DTexture9 *pSourceTexture=NULL;
  D3DXCreateTextureFromFile(m_pDevice,File.c_str(),&pSourceTexture);

  //Now lock the surface
  D3DLOCKED_RECT sourceRect;
  pSourceTexture->LockRect(0,&sourceRect,NULL,0);

  //Get surface desc
  D3DSURFACE_DESC sourceDesc;
  pSourceTexture->GetLevelDesc(0,&sourceDesc);

  dwOutWidth=sourceDesc.Width;
  dwOutHeight=sourceDesc.Height;


  //Pointer to surface (buffer)
  DWORD *pSourceBits=(DWORD *)sourceRect.pBits;
  DWORD dwSourceOffset=0;
  DWORD dwStartSourceOffset=0;

  //X and Y counters
  DWORD dwX=0,dwY=0;

  do
  {
    do
    {
      //Create new texture object
      CTexture *pTexture=new CTexture;
     
      //Create texture from buffer
      pTexture->CreateFromImageEx(m_pDevice,
                                  dwWidth,
                                  dwHeight,
                                  pSourceBits,
                                  dwSourceOffset,
                                  sourceRect.Pitch);

      //Add texture to vector
      m_vTextures.push_back(pTexture);

      //Update loop variables
      dwX+=dwWidth;
      dwSourceOffset+=dwWidth;
     
    } while (dwX<(sourceRect.Pitch/4));

    //Move down one cell size in source texture
    dwX=0;
    dwStartSourceOffset+=((sourceRect.Pitch/4)*dwHeight);
    dwSourceOffset=dwStartSourceOffset;
    dwY+=dwHeight;
  } while (dwY<sourceDesc.Height);
 
  return false;

}

---

CTexture.h

Code:

---

//Grabs a texture of width,height from pSourceBuffer
void CTexture::CreateFromImageEx(IDirect3DDevice9 *pDevice,
                          DWORD dwTargetWidth,
                          DWORD dwTargetHeight,
                          DWORD *pSourceBuffer,
                          DWORD dwSourceOffset,
                          DWORD dwSourcePitch)
    {
      //Create a blank texture
      D3DXCreateTexture(pDevice,
                        dwTargetWidth,
                        dwTargetHeight,
                        D3DX_DEFAULT,
                        0,
                        D3DFMT_A8R8G8B8,
                        D3DPOOL_MANAGED,
                        &m_pTexture);

      //Lock it's surface and get a pointer to it
      D3DLOCKED_RECT rect;
      m_pTexture->LockRect(0,&rect,NULL,0);
      DWORD *ptrBits=(DWORD *)rect.pBits;

      //Surface description
      D3DSURFACE_DESC desc;
      m_pTexture->GetLevelDesc(0,&desc);
       
      //Offsets
      DWORD dwOffset=0;
      DWORD dwStartOffset=0;
      DWORD dwStartSourceOffset=dwSourceOffset;

      //Start the copying
      for (DWORD i=0;i<desc.Height;i++)
      {
        for (DWORD j=0;j<desc.Width;j++)
        {
          //Copy from source to this texture's surface
          ptrBits[dwOffset]=pSourceBuffer[dwSourceOffset];
          dwSourceOffset++;
          dwOffset++;
        }
        dwStartSourceOffset+=(dwSourcePitch/4);
        dwSourceOffset=dwStartSourceOffset;
       
        dwStartOffset+=(rect.Pitch/4);
        dwOffset=dwStartOffset;
      }

      //Unlock surface
      m_pTexture->UnlockRect(0);
    }

---

Didn't they do something with boundaries in Morrowind? I'm not sure of the details, it just gets on my nerves that it hangs up a couple of seconds every 30 steps.

Great I messed up my own google search. A search for per-pixel scrolling yields my own thread on here about per-pixel scrolling. Unfortunately it's the method I'm dumping.

New method:

Old school algo. Lock all surfaces of textures and store pointers to them in a class member.

Lock texture representing screen.
Draw to surface using older algo from DOS days.
Unlock texture.

Draw quad the size of the screen using texture just created.

Require 1 texture and tile textures. Tile textures reside in the vector or list and all are unlocked. Since I'm not actually rendering the tile textures, leaving them unlocked should not cause any issues.

We will see.

Per-pixel scrolling? I still don't see why you can't scroll the uv's.

Quote:

---

Originally Posted by skorman00

Per-pixel scrolling? I still don't see why you can't scroll the uv's.

---

That would require one large texture.

How many tiles are you going to have and what size are they going to be? How many tiles are you going to have displayed at the same time? Unless it's very very many I don't see any reason why you would have performance problems, all geometry and textures should be uploaded to the graphics card already, you should at worst have to regenerate the tiles at the borders...Do you have any pictures of what you're doing?

1. Thousands
2. 1024x768 (32x32)
3. Multiple Sprites (any size)
4. GUI and HUD
5. Special effects sprites

I got it working.

No you cannot just regenerate the tiles at the borders. Let's say you have a vertex buffer with a grid. As you scroll the grid vertices you must reset their position when :

(iScrollX % iCellSize ==0) && (iScrollY % iCellSize==0)

However what do you do if the screen being displayed is smaller than the actual screen? You must re-create the vertex grid and/or regenerate it. Solution is do not use a vertex grid.

My new algo simply draws pixel by pixel. It retrieves a pixel for:

Code:

---

DWORD dwTileID=m_pMapMgr->GetMapValue(dwCurMapLayer,dwMapOffset);

---

It gets the pixel from:

Code:

---

DWORD *ptrSurface=m_pTexMgr->GetBuffer(dwTileID);

---

So:

Code:

---

D3DLOCKED_RECT rect;
m_pScreenTexture->LockRect(0,&rect,NULL,0);

DWORD *ptrScreen=(DWORD *)rect.pBits;

...
...
ptrScreen[dwSourceOffset]=ptrSurface[dwDestOffset];


....
m_pScreenTexture->UnlockRect(0);

---

Draws the screen.

Then I set texture to m_pScreenTexture and render a quad the size of the screen.

1 Lock
Several memory accesses
1 Unlock

1 Triangle strip
1 Primitive
1 Screen texture

All textures in the texture manager class are already unlocked and remain this way for the duration of the game.

I clear the screen texture using:

Code:

---

__asm {
  //Pointer to screen
  mov edi,ptrScreen
 
  //size = surfHeight*(surfPitch>>2)+surfWidth
  mov eax,surfHeight
  mov ebx,surfPitch
  shr  ebx,2
  mul  ebx
  add  eax,surfWidth
 
  //Size is ecx
  mov ecx,eax
 
  //Color is 0
  mov eax,0

  //Set [EDI+ECX] to EAX for ECX count
  rep  stosd
}

---

Using aggregated data types in inline asm is such a pain. I wish they would change that.

Now you must do this:

Code:

---

struct Foo
{
  int x;
};

Foo Test;

__asm {
  mov ebx,OFFSET Test
  mov ecx,[ebx].x
}

---

But you can get away with this since access restrictions are a compiler side mechanism. I DON'T recommend this. :)

Code:

---

class Foo
{
  private:
    int value;
  public:
    Foo():value(0) { }
};

int main(void)
{
  Foo Test;
  __asm {
    mov ebx,OFFSET Test
    mov [ebx].value,0FFh;
  }
}

---

Even though value is private to Foo, in inline asm blocks there are no access restrictions to data members. However you cannot call member functions. Actually I could call a member function by using it's address rather than it's name. Also could make a pointer to the VTABLE and parse it as well, but no need.

Haven't coded D3d for ages, can't say I follow your code...

So you have a large texture that shows your tiles?

And then you update that texture pixel by pixel?

I would have done the tiles as polygones with u,v coordinates indexed into a larger texture. What I would do is basically a chunk based terrain engine but without any elevation data or LODing, (look at Thatcher Ulrichs stuff) or do I misunderstand the purpose of why you do your tiles?

And how are you going to fit a 4096x4096 texture in video memory?

You cannot just scroll u,v's and expect this to work. It will work fine until you reach the end of the texture. Video drivers do not allow for anything larger than 2048x2048 and you are lucky if they allow that. Besides the tile map is in memory as a linear array and we are drawing according to the map. I would have to make several separate 1024x1024 textures and cache them in accordingly at run time. Since 4 textures could be intersecting at any one time this would be non-trivial code. I could use IDirect3DTexture9's copy method but it has many restrictions.

And if you want a dynamic tile map you will either have to use decaling which requires culling primitives, etc., etc. You could also do real-time texture writes using render targets but again most of this is far too complicated for a simple tile engine.

I can do lighting of each tile by performing additive blending in assembly code and then placing the resulting pixel in the screen buffer. In fact since I have per-pixel access to the texture representing the screen....I can do a lot.

The article on GameDev about doing 2D with 3D is nice, but it fails to address the problem of setting the texture for every single tile. This can be reduced since most tile maps are repetitive, but it is still a bad approach. Creating an entire vertex grid in memory is one approach but it would have to be software and not hardware vertex buffers. Since my vertices are using D3DFVF_XYZRHW you cannot run them through translation and expect anything to happen. So to move the vertices you must lock, move, and unlock. Not your best case scenario there.
Rendering could be sped up by using a quad-tree, but for updating the scroll position you must update every single vertex in the map or it won't look right. I can think of ways to optimize this as well, but see.......you are working against yourself.

So I went with the old-school per-pixel algo.

I'm not suggesting you should do the scrolling by updating the u,v coordinates of each polygonvertex, transforming the vertex positions by hardware takes care of the scrolling. Setting the clip area so you can render the map inside a smaller area.

For 10000 different kind of tiles you could upload 10 1024x1024 textures containing the tiles to the graphics card and then rendering the visible tiles onto the screen. Sorting the tiles rendering order so you don't do more than 10 texture switches and you should have very decent performance and without too much work.

I haven't read the GameDev article you mention, but I think you are doing this overly complex, switching between 10 different textures is not going to kill you as long as you sort the polygones properly.

@Bubba: Out of interest, what kind of performance are you getting out of this method?

Ok then fractality....show me some code.

First thing that comes to my mind, is if the texture calls are what's causing your bottleneck and not necessarily the polygon pushing, why not slap all of your tiles in to a list and sort them by texture ID, then render them accordingly. You'd be pushing more vertices, yah, but as I said: if the texture binding is causing the largest problem, this should fix it (assuming you're not drawing millions of tiles).

I agree with Jverkoey and Fracticality. If the texture must be that big, then yes, kudos for finding a way to handle it. But I disagree that would be easier to manage or even faster than breaking it down into smaller textures and improving your algorithm to sort geometry by texture changes.

If you break the big 4096x4096 texture into say 4 2048x2048 textures, then ordering by texture shouldn't be terribly difficult

Code:

---

int numTextures = 4;
for(int i = 0; i < numTextures; ++i)
{
    SetTexture(tileTextures[i]);

  for(int tile = i; tile < numTiles; tile+=numTextures)
  { 
      DrawTile(tileList[tile]);
  }
}

---

Breaking the texture down smaller will change numTextures. With this algorithm, you could actually have any number of breakdowns of the large texture, just calculate numTextures accordingly.

Maybe we still don't fully understand your situation, Bubba?

You are thinking incorrectly.

Textures just wont work here. You must think old-school 2D. It's been done before and even in Direct3D you can do it. Think Command and Conquer, Zelda, etc, etc.

You're pushing polygons to the card, each with a specified texture and uv texture coordinate, correct? I don't see why sorting by texture ID can't work then, unless I'm still confused as to what you'd like to do.

Bubba, I don't know if it's we who don't understand you or you who don't understand us, but I'm old-school enough to have done pure tile based games on the amiga and if I where to do it today I would do it the way I said since modern graphics cards are all about polygon pushing. I doubt you'll run into fill rate problems since you should have almost no overdraw with your 2d rendering style.

About the code showing, it would take too much of my time to do it, sorry, fulltime work and girlfriend takes up enough of my time, I rather do my spare time coding on my own things.
If you get your tile rendering to work then great, I was just trying to suggest an alternative way without so much work involved.

You have to ask yourself if you're on the right track when your problem is that you need to render a fraction of the available texture memory on the graphics card onto the screen...I'm not trying to sound like a git, but I really think there are better ways to do this =)

English is not my prefered choice of language, so misinterpret my words in the nicest way possible =P

Quote:

---

Originally Posted by fractality

Bubba, I don't know if it's we who don't understand you or you who don't understand us, but I'm old-school enough to have done pure tile based games on the amiga and if I where to do it today I would do it the way I said since modern graphics cards are all about polygon pushing. I doubt you'll run into fill rate problems since you should have almost no overdraw with your 2d rendering style.

About the code showing, it would take too much of my time to do it, sorry, fulltime work and girlfriend takes up enough of my time, I rather do my spare time coding on my own things.
If you get your tile rendering to work then great, I was just trying to suggest an alternative way without so much work involved.

You have to ask yourself if you're on the right track when your problem is that you need to render a fraction of the available texture memory on the graphics card onto the screen...I'm not trying to sound like a git, but I really think there are better ways to do this =)

English is not my prefered choice of language, so misinterpret my words in the nicest way possible =P

---

I like the way you sneaked in "girlfriend" to prove you have one. :p

Ha ha, nerds and girls, always a hot topic =P
But I'm 30 years old and have been together with her for the last couple of years yes.

Sweet.

Quote:

---

You are thinking incorrectly.

---

How so? *inquisitive, not snarky*

Ok this is the best I have so far. I scrapped the per-pixel algo and went with my old one, but I spiced it up a little bit.

Instead of retrieving ID, draw quad, etc, etc. it now retrieves the ID. If the ID is not the same as the last ID then it sets the texture to the last id and renders primCount number of primitives. Then I increment a pointer in my software vertex buffer based on vertexCount.

For scrolling, I have an ugly section of code but it's so much faster to increment a pointer than to use the array indexing.

Here is the code. There are still some bugs but this thing renders rather fast.

Code:

---

void CScreenGrid::RenderSoftware(float fTimeDelta)
{
 
  //m_pDevice->SetRenderState(D3DRS_FILLMODE,D3DFILL_WIREFRAME);
 
  //Set FVF
  m_pDevice->SetFVF(TLVERTEX_FVF);

  //Texture ID
  DWORD dwTexID=0;
  //Previous texture ID
  DWORD dwLastID=0;

 
  //Variables for loop
  DWORD dwStartOffset=m_dwCurrentOffset;
  DWORD dwOffset=dwStartOffset;
  DWORD dwRow=0;
  DWORD dwCol=0;

  //Vertex buffer pointer
  TLVertex *pSVB=m_pSVB;

  //Vertex and primitive Counters
  int vertexCount=0;
  int primCount=0;

  //Draw flag
  bool bDraw=false;

  //Loop through all layers - bottom up
  for (DWORD map=1;map<m_pMapManager->GetSize();map++)
  {
   
    dwTexID=0xFFFFFFFF;
    dwOffset=dwStartOffset;
    dwStartOffset=m_dwCurrentOffset;
    dwRow=0;
    dwCol=0;
    primCount=0;
    bDraw=false;

    //Set to equal to start system
    dwLastID=dwTexID;

    //Loop through all vertices
    for (DWORD i=0;i<m_dwTotalVerts;i+=6)
    {
      //Get texture ID from map
      dwTexID=m_pMapManager->GetMapValue(map,dwOffset);
   
      //Increment vertex and primitive counters     
      primCount+=2;
      vertexCount+=6;

      //Is this ID the same as the last?
      if (dwTexID==dwLastID)
      {
        bDraw=false;
      } else bDraw=true;
     
      //If it is, draw the batch of primitives that share lastID's texture
      if (bDraw)
      {
       
        m_pDevice->SetTexture(0,m_pTexManager->GetTexture(dwLastID));
        m_pDevice->DrawPrimitiveUP(D3DPT_TRIANGLELIST,primCount,pSVB,sizeof(TLVertex));
       
        //Increment the vertex buffer pointer
        for (int v=0;v<vertexCount;v++)
        {
          *pSVB++;
        }
               
        //Reset state
        primCount=0;
        vertexCount=0;
        bDraw=false;
        dwLastID=dwTexID;
       
      }
     
      //Map housekeeping
      dwOffset++;
      dwCol++;

      //Map counter
      if (dwCol>=m_iNumTilesHoriz)
      {
        dwCol=0;
        dwRow++;
        dwStartOffset+=m_pMapManager->GetWidth(map);
        dwOffset=dwStartOffset;
      }
   
     
    }
  }

}

---

And the ugly scroll code:

Code:

---

void CScreenGrid::ScrollSoftware(int irelScrollX,int irelScrollY)
{
  //Scroll flag
  bool bScroll=true;

  //Map offset change for scroll
  int iOffsetChange=0;
   
  //Scroll vars
  m_iScrollX+=irelScrollX;
  m_iScrollY+=irelScrollY;
 
  //World scroll
  m_iWorldX+=-irelScrollX;
  m_iWorldY+=-irelScrollY;

  //Test for +X 
    if (m_iScrollX>=(m_iIncrementX-1))
    {
      irelScrollX=-m_iScrollX+irelScrollX;
      m_iScrollX=0.0f;
      iOffsetChange=-1;
   
    }
 
    //Test for -X
    if (m_iScrollX<=(-m_iIncrementX+1))
    {
      irelScrollX=-m_iScrollX+irelScrollX;
      m_iScrollX=0.0f;
      iOffsetChange=1;
    }

    //Text for +Y
    if (m_iScrollY>=m_iIncrementY)
    {
      irelScrollY=-m_iScrollY+irelScrollY;
      m_iScrollY=0.0f;
           
    }
 
    //Test for -Y
    if (m_iScrollY<=-m_iIncrementY)
    {
      irelScrollY=-m_iScrollY+irelScrollY;
      m_iScrollY=0.0f;
   
    }
 
    //Bounds check X
    if (m_iWorldX<0)
    {
      bScroll=false;
      m_iWorldX=0;
      iOffsetChange=0;
    }
   
    //Bounds check Y
    if (m_iWorldY<0)
    {
      bScroll=false;
      m_iWorldY=0;
      iOffsetChange=0;
    }

    if (bScroll)
    {
      //Change map offset
      m_dwCurrentOffset+=iOffsetChange;

      //Buffer pointer
      TLVertex *pSVB=m_pSVB;

      //Increment pointer and change values
      for (DWORD i=0;i<m_dwTotalVerts;i+=6)
      {
        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;

        *pSVB++;

        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;
       
        *pSVB++;

        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;

        *pSVB++;
       
        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;

        *pSVB++;
       
        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;

        *pSVB++;
       
        pSVB->x+=irelScrollX;
        pSVB->y+=irelScrollY;
     
        *pSVB++;
      }
 
    }

}

---

I think it's pretty. Could do with a few more spaces between operators / operands but I guess my thumb gives up after a while too :)

EDIT: Yes, I realise this has nothing to do with the topic at hand. Sue me. Unless you're a moderator who actually can do something about it...

Meh.

Hmm, do you have each tile in a separate texture?
It looks like it but without knowing how the internals of the TexManager works it's hard to say...
Do you update all the vertex positions when you do the scrolling?
Those two things look a little fishy to me, perhaps that's why you have had problems with speed? What CPU/Gfx card/resolution and speed do you get from this routine?

BTW, what are you doing here? Am I just tired or is this weird? No, time to watch movie, cu.

Code:

---

 
        //Increment the vertex buffer pointer
        for (int v=0;v<vertexCount;v++)
        {
          *pSVB++;
        }

---

Quote:

---

Originally Posted by fractality

BTW, what are you doing here? Am I just tired or is this weird?

---

You are not just tired. That code is equivalent to "pSVB+= vertexCount;".

Quote:

---

Hmm, do you have each tile in a separate texture?

---

Yes. They are extracted from larger textures.

Quote:

---

Do you update all the vertex positions when you do the scrolling?

---

Yes. This should be apparent from the posted code.

Quote:

---

Those two things look a little fishy to me, perhaps that's why you have had problems with speed?

---

This revised function was not the one suffering from speed.

You don't understand *pSVB++?

Now that's fishy.

No, He was saying why are you putting that in a loop when you can just add vertexCount to it.

But without you saying how well it's running it's hard to know if it's running good or not...It doesn't look to me like nearly the best way if you want it to run fast, but without any profiling feedback from you it's pointless to try to dig any more in it.

I'm afraid that this might sound a little mean, but I think you have lots of things you could improve in your code, since you're evidently trying hard to make it run, you could at least be a little more open for helpful suggestions.

No, as Sang-drax said, I don't understand why you use a loop for something that looks like it should be a one line addition assignment and the 2 points I raised are things that I think reduces the speed of your rendering (you are doing unnessesary many texture binds and poking around in vertex data that could equally well lie untouched in the graphics card memory if you used a transformation before rendering it instead), however don't poke in it without profiling, D3d is not my thing.

I hope you take this as constructive critisism and nothing else, I'm a very nice person, promise, feels like I'm been jumping up and down on you on this board. Keep on coding...

The reason for the *pSVB++ is that each triangle in the code is 6 vertices. I'm not using indexed buffers and I'm not using a hardware buffer.

DrawPrimitiveUP is not in hardware which means you don't have to lock it to access it. Yes, you take a little bit of a hit with it but it's not too bad. It takes more of a hit with locking and unlocking a Video RAM vertex buffer than a software system RAM buffer.

So my point in doing 6 *pSVB++ is to increment the pointer, change the variables, and increment the pointer.

The actual first version was pSVB[vert].x+=irelScrollX.

But in profiling this was actually slower than *pSVB+=vertexCount which was my second version. The optimized version actually does 6 vertices at a time by incrementing a pointer which means the loop actually is faster. So instead of changing variables 1 at a time in a single increment loop, I change 6 at a time and increment by 6. I just unrolled the loop.

I tried to also unroll the loop on the vertexCount loop inside of the render function, but it was causing issues that I couldn't quite figure out so I changed it to what worked.
I'm trying to process 6 vertices in one loop, or one complete quad in one loop.

Now the reason for NOT using indexed buffers. First, this is in software RAM so memory is not an issue. Second, it is much easier to do special effects on a per-quad basis when you are not using indexed buffers. So for screen dissolves, wipes, fades, and/or other special effects like screen shattering, etc, it's much easier to use 6 vertices per quad. In this way I can literally tear apart the screen and do some rotational effects on each triangle without having to lock a hardware vertex buffer, without having to de-couple the index buffer from the vertex buffer, etc., etc.

If this was for a 3D rendering system then, yes, what you have said would be correct. In 3D I would never do any of this and don't, but for 2D I just need more control of the screen and of the sprites than Direct3D's and D3DX's API allows for.

Even ID3DXSprite has 1 complete glaring oversight in that you can not access the vertex buffer. This means that bounding boxes cannot be computed post-transformation for sprites and you pretty much have to compute that for yourself. I'm not sure why this is so or why they don't at least let you specify a bounding volume and allow you access to those. The way I do bounding boxes is to first create the bounding volume. Second, after the object is transformed I re-compute the bounding box from the transformed vertices. Just transforming the bounding box does not work correctly as explained in Real Time Rendering and Game Coding Complete. Moller and Haines provide an extremely detailed explanation of why this does not work.

There is a method to the madness.

Whats with all the offsets?
The reason for all of the offsets are so I can linearilly traverse the map in memory. I detest doing any multiplies in a loop such as that so to prevent it I pre-compute the offset. But in order to do this properly you must have two variables.
Here is why.

Code to traverse a 2D array (pArray) in linear fashion.
This is using array indexing and not manual pointer addition.
Slower, but it works.

The row and col counters are so I can track the width and height without using (dwOffset % width), which is slower since it is a divide.
[code]

DWORD dwOffset=0;
DWORD dwStartOffset=dwOffset;

int row=0,col=0;

int value=0;

do
{
pArray[dwOffset]=value;
value++;
dwOffset++;
col++;

if (col>ArrayWidth)
{
//Start offset is the beginning of the current line
//dwOffset is at the end of the current line
//Increment dwOffset by ArrayWidth puts dwOffset at the END
//of the next line, instead of the START of the next line
//So we increment StartOffset and then set dwOffset to
//equal that value
dwStartOffset+=ArrayWidth;
dwOffset=dwStartOffset;

//Reset column counter
col=0;
//Increment row counter
row++;
}
} while (row<ArrayHeight);
[code]

So for this loop we increment a 2D array in linear fashion and we have this:

Code:

---

  pArray[dwOffset]=value;
  value++;
  dwOffset++;
  col++;

---

1 indexed array access //add esi,dwOffset
3 integral additions //inc [ebp+stack_position_of_var]

Code:

---

if (col>ArrayWidth)

---

I'm not sure exactly how the compiler will treat this w/o looking at the asm source. I would do it this way which is prob not the fastest way. I would use ecx as the column counter.

1 comparison with a parameter on the stack.

mov eax,[ebp+stack_pos_of_ArrayWidth]
cmp eax,ecx
ja MOVEDOWNROW
jmp STARTOFLOOP

Code:

---

    dwStartOffset+=ArrayWidth;
    dwOffset=dwStartOffset;
   
    //Reset column counter
    col=0;
    //Increment row counter
    row++;

---

Again we have (in order)

1 Addition
1 Assignment
1 Assignment
1 Addition

Code:

---

} while (row<ArrayHeight);

---

Here is 1 comparison with a possible 2 register loads for row and ArrayHeight, again, depending on register/stack usage.

So the entire loop comes down to:

1 indexed array access
1 integral addition
1 integral addition
1 integral addition
1 comparison with a parameter on the stack.
1 integral addition
1 assignment
1 assignment
1 integral addition
1 comparison

So:

1 indexed array access
5 integral additions
2 comparisons

As opposed to something like this:

Code:

---

for (int i=0;i<ArrayHeight;i++)
{
  for (int j=0;j<ArrayWidth;j++)
  {
    Array[i][j]=value;
  }
}

---

2 loops.
1 inherent multiply executed once each iteration of the nested loop.
1 Array access inside of nested loop.
2 inherent comparisons, increments

Array[i][j] works out to:

Array[i*width+j]

Which is what I want to avoid as well as the nested loops.
So I unroll the loop and eliminate the multiply.

Attached is the profile of this code - profiled for function timing.

Here is the render function:

Quote:

---

222.486 0.8 500.899 1.8 173 CScreenGrid::RenderSoftware(float) (cscreengrid.obj)

---

Here is the scroll function:

Quote:

---

305 0.0 4.305 0.0 34 CScreenGrid::ScrollSoftware(int,int) (cscreengrid.obj)

---

This was computed by running the app, selecting new project, and then opening a bitmap and adding several tiles. Then I scrolled the map left and right 3 or 4 times.

Keep in mind this is inside of MFC where most of the time is spent in the msg loop and rendering is not constantly updated. It is inly updated when:

Invalidate() is called which calls
CZeldaEditorView::OnDraw() which calls
CEditor3D::RenderMainView() which calls
CScreenGrid::RenderSoftware().

A pure Direct3D app would not be this convoluted, but I'm using my engine DLL inside of an MFC CWnd object so it get's messy.

Quote:

---

So my point in doing 6 *pSVB++ is to increment the pointer, change the variables, and increment the pointer.

---

That's not the part of code they're trying to point out Bubba, they're looking here:

Code:

---

      //If it is, draw the batch of primitives that share lastID's texture
      if (bDraw)
      {
       
        m_pDevice->SetTexture(0,m_pTexManager->GetTexture(dwLastID));
        m_pDevice->DrawPrimitiveUP(D3DPT_TRIANGLELIST,primCount,pSVB,  sizeof(TLVertex));
       
        //Increment the vertex buffer pointer
        for (int v=0;v<vertexCount;v++)
        {
          *pSVB++;
        }
       
               
        //Reset state
        primCount=0;
        vertexCount=0;
        bDraw=false;
        dwLastID=dwTexID;
       
      }

---

This is in the first code snippet you posted most recently.

Well I tried pSVB+=vertexCount and it fired off an error. I thought you could increment a pointer this way as well. Perhaps something else caused the error.

Changed the loop to pSVB+=vertexCount. I think I might have tried *pSVB+=vertexCount which is incorrect.

Are you using "*pSVB++;" instead of the equivalent "pSVB++;" to emphasize that it is a pointer being incremented? You are already doing that with hungarian notation.

No I incorrectly used *psvb+=<some_value> which didn't work. Then I used the loop.

However I have now changed it to pSVB+=vertexCount.

Incase you haven't already done so, shouldn't your last loop (the unrolled one) also have the same changes?

Yes it should.

You gotta give me some credit here. I've taken quite a bit of criticism, some helpful, some not and developed my own algo that runs faster than all the suggestions.

I like my RLE-type rendering algo.

:D

The pointer suggestions - many thanks.
The graphic suggestions...thanks but no thanks.

Unless you code your own tile renderer in Direct3D you probably will not understand the issues I'm encountering which is understandable. Some of you that know Direct3D probably do realize the issue at hand and I think I've come up with an efficient feasible solution.

I have made a tile based rendering system, a few actually, and each time I did it a bit differently =) May the force be with you for whichever method you choose.

As far as order your rendering order based on texture: that would speed any code up using DirectX 9. in DX10, might not be an issue depending on how you use the pipeline. I mention that because I know you're big into forward movement Bubba (or at least think so).

And what's one more bit of criticism on the code?

Code:

---

      //Is this ID the same as the last?
      if (dwTexID==dwLastID)
      {
        bDraw=false;
      } else bDraw=true;

---

bDraw is only used to control the next if block, so having it only confusimicates things (unless you're planning for future features)

I just got your PM Skorman. The board said it was sent 4/15 but I was never notified. Quite odd.

I was interested to see that ptr method actually is faster, even though it uses more asm. It most certainly comes down to the fact that the multiply on a non power of 2 array to retrieve the memory offset is slower than the added instructions used in the ptr method.