Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
scifista42

Does texture tiling and multipatch texturing slow down rendering?

Recommended Posts

My questions are directed towards people knowledgeable about Doom's renderer. Primarily the software renderer, but I'd be interested to know about the hardware renderer's qualities too. I'll explain what I wanted to know in simple examples:

1. Let's say that I have a huge and elaborate map, textured with 128-units wide, single patch textures. Now I change texturing everywhere to 8-units wide, single patch textures. Will it cause slower rendering, even if slightly?

2. The same as 1, but regarding vertical tiling? (not assuming tutti-frutti bug)

3. Let's say that I have a huge and elaborate map, textured with single patch textures. Now I change texturing everywhere to textures of the same width and height, but consisting of 64+ patches that don't overlap each other (but they're placed both vertically and horizontally next to each other). Will it cause slower rendering, even if slightly?

Share this post


Link to post

1. I don't think so, IIRC the game determines what part of a texture to draw by taking the distance from the vertex and calculating the modulus of the texture's width to know what column it should be on.

2. Dunno? If you're disregarding tutti-frutti then you're already into a source port, which could probably do any number of things.

3. It would make the level use somewhat more RAM, and render SLIGHTLY slower at the beginning. When setting up the game, the engine loops through every texture, and flags every column in each texture that has multiple patches in it. If it does, it waits until the renderer wants to draw that column, and then constructs the column out of the patches and caches the result. Every successive time it tries to draw the column, it will use the cached one, which ought to be equally as fast as drawing a single-patch texture.

Share this post


Link to post
Linguica said:

1. I don't think so, IIRC the game determines what part of a texture to draw by taking the distance from the vertex and calculating the modulus of the texture's width to know what column it should be on.

Does calculating a modulus (by a number that is a power of 2) always take exactly 1 operation (minimum time unit)? Is calculating "12345 % 8" as fast as calculating "12345 % 128"? (Probably yes, but I better ask.)

Share this post


Link to post

There is always some overhead in handling multiple patches.
The calculations for the starting position, the texture position, and the stepping has to be done for each texture. This is repeated for each patch within a texture.

As a wild guess, the combined overhead for a texture is equivalent to about 16x16 pixels. Each patch adds the equivalent of about 8x8 pixels.
That is mostly the time to go through a sea of conditional tests, offset calculations, and scaling multiplications. It is a little hard to estimate this because I expect the time for conditional branch waits to be significant and that depends strongly on cache hits.

Older ports like PrBoom draw their textures one patch at a time.

DoomLegacy combines patches into a composite texture at texture load time. The hardware render makes use of this feature too.
So in DoomLegacy the number of patches does not matter, patch positioning has no effect on render time, it is one large texture.

1a. Tiling small textures has only a small difference. The code is already there and already testing, which is most of the cost.
1b. More short linedefs means a much larger state to store and the cache will suffer, slowing everything. There is also the additional overhead of discovering, testing, positioning and scaling the texture on each linedef.
3. Very port dependent. Also renderer dependent. For vanilla style renderers, YES.

Small textures may not tile properly, or may tile badly.
A small texture tiled over a large wall generally looks bad because of the repetition and may produce drawing artifacts (moire patterns, sampling artifacts, or worse). The same texture manually tiled over a larger texture can have a slight variation of color, position, or grain pattern.

Share this post


Link to post
wesleyjohnson said:

Small textures may not tile properly, or may tile badly.
A small texture tiled over a large wall generally looks bad because of the repetition and may produce drawing artifacts (moire patterns, sampling artifacts, or worse). The same texture manually tiled over a larger texture can have a slight variation of color, position, or grain pattern.

I was actually thinking about a texture that's a solid colour (for example pitch black), and wondering if it would matter whether the patch was 8 pixels wide or 64 pixels wide, if I wanted to use the texture extensively in an enormous map.

Share this post


Link to post

I have wondered the same thing. I made a flat white texture for DoomLegacy. My previous answer is still the best I can do.
I kept changing the size of my white texture and could not discern any difference. All my testing was on DoomLegacy.

I worry more about other Ports handling a small texture, like 16x16. Something about textures not tiling right if they were smaller than 128, but I cannot remember what the circumstance was.
If I remember right, I finally just made mine 64x64, then later eliminated the need for it altogether.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×