perf ? about blting

Started by
1 comment, last by Orpheum 23 years, 5 months ago
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!!
There is no spoon.
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
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 tilefor(j=-;j<3;i++)//each tile layerTiles[x][y][j].blt();}//Method 2:for(j=0;j<3;i++)//each tile layerfor(y=0;y<20;y++)for(x=0;x<27;x++){//each tileTiles[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
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

This topic is closed to new replies.

Advertisement