Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Orpheum

perf ? about blting

This topic is 6598 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am working on some optimizations for my tile based engine. This is my first engine so the road has been rough, but so far I am very happy with what I''ve put together. I have a couple questions for you tile engine veterans. 1. My engine supports 3 layers of tiles - ground, objects, and decals. Currently Render() goes through the visible area and blt''s the correct number of tiles to each map point. Example: Tile 10x10 has 3 tiles, and tile 10x11 has just 1. Render() comes through and draws 3 tiles at 10x10 and then moves over 32 pixels to 10x11 and then draws 1 tile, etc. Would it be faster to draw the whole layer at one time rather than cycling through the tiles to be drawn for each point? 2. Do long names produce additional overhead? Example: World[iY][iX].iTileIndex[TEntries[iIndex].iLayer] versus int iLayer = TEntries[iIndex].iLayer; World[iY][iX].iTileIndex[iLayer]; Certainly the second one is more readable, but is there any difference performance wise? Thanks!!

Share this post


Link to post
Share on other sites
Advertisement
I''m not sure about your first question, and I haven''t played with 2d in a long time (since before windows).

As for your second question, there''s nothing _wrong_ with the first line, unless you''re doing repeated queries to the same structure. Like if you were grabbing lots of values from World.[iY][iX], it''s better to cache a reference to that object and use it instead of derefercing the array mutliple times.

Simply put, there''s nothing wrong with deep-nested calls, unless you''re doing it repeatedly. Some compilers may be able to cache values automatically, but I wouldn''t count on it.

Morbo

Share this post


Link to post
Share on other sites
1) In my experience yes, in the following code, method 2 is faster.

    
Method 1:
for(x=0;x<27;x++)
for(y=0;y<20;y++)
{
//each tile

for(j=-;j<3;i++)
//each tile layer

Tiles[x][y][j].blt();
}

//Method 2:

for(j=0;j<3;i++)
//each tile layer

for(y=0;y<20;y++)
for(x=0;x<27;x++)
{
//each tile

Tiles[x][y][j].blt(...);
}


Here's why: In mehtod 2, less code is executed; the number of iterations is exactly the same but there is less loop overhead. You generally want the smallest loop on the outside. You can use QueryPerformanceCounter to time the methods.

2) The length of the name doesn't matter at all, the number of indirection does. You should move as much as possible to outer loops if you can. You shouldn't use any indirection in the for loops either. In theory a compiler could optimize these things for you, but it would have to build some sort of dependance tree to deterimine if it really can remove/replace/move those indirections around. I do not believe MSVC does anything like this, though the borland ones might; I know they build dependance trees with delphi.

Actually, to make a significant difference in the speed of the code, rearrange your tile storage to be something like this:
Tiles[TileType][Yidx][XIdx], that way it parralells method2 and you can dereference the tiletype once for each tile type, & the y column once for each column (instead of everytime).

Lastly, since it is a tile engine, only certain tiles change each frame, so you could keep track of which tiles have changed and only render those ones. This could actually cause a performance decrease if many tiles change each frame.

Edited by - Magmai Kai Holmlor on November 24, 2000 10:48:00 PM

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!