FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: The reasons for the texture chunks  (Read 2782 times)

helios

  • Developer
  • Jr. Member
  • *
  • Posts: 61
    • View Profile
The reasons for the texture chunks
« on: October 03, 2010, 12:35:11 pm »

Hi guys,
I looked into the last changes and found a few problems/misunderstandings.
The history behind the chunking code is that we need it for two reasons, first to ensure that the texture is power of two and second to support textures which are larger as the hardware supported size. The most video cards support maximum 4096x4096 or 8192x8192 texture size if your texture is larger it can't be displayed.
The old chunking size variable in the engine settings defined the maximum size for a chunk, not the real size. The real size of the chunk is defined in chunk_width and chunk_height. We may use glGetIntegerv(GL_MAX_TEXTURE_SIZE, &max_tex_size); to obtain the maximum texture size and use it as chunking size, so we don't need the chunking size variable in the engine settings and the chunking size would be set correctly.
I found also that the new code use the same chunk size for width and height, thats not optimal, because e.g. you have a texture with 33x23 pixels then the new code makes a 64x64 texture but the old code makes a 64x32 texture.

Oh, before I forget...
The new stuff in fife_math.h is a bit inaccurate due to the limited precision of float or double. Example: PI = 4.0*std::atan(1.0) is inaccurate after a few digits, more accurate is PI = 4*std::atan(1).


Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: The reasons for the texture chunks
« Reply #1 on: October 03, 2010, 03:18:27 pm »

I removed the texture chunking because
1) I can still guarantee the chunk is a power of 2 for the texture
2) You're right.. it's not optimal but we can still optimize the texture chunk size.  Just have to add a col chunk size and row chunk size.  Pretty easy mod.
3) Only one call to render needs to happen
4) Drawing primitives on the texture should now become possible/easier

OH and if you see any problems with the new math stuff feel free to fix it.
Logged

helios

  • Developer
  • Jr. Member
  • *
  • Posts: 61
    • View Profile
Re: The reasons for the texture chunks
« Reply #2 on: October 03, 2010, 04:43:10 pm »

1) I can still guarantee the chunk is a power of 2 for the texture
The old code guarantee it, too.
2) You're right.. it's not optimal but we can still optimize the texture chunk size.  Just have to add a col chunk size and row chunk size.  Pretty easy mod.
Why optimize? The old code used two chunk sizes.
3) Only one call to render needs to happen
Yeah as I said before, if you configure the chunk setting right, it needs one call to render, with the old function. Only if the texture is larger as the maximum texture size you need more chunks also more render calls. The new code can't display these large textures.
4) Drawing primitives on the texture should now become possible/easier
It's already possible. And I see no reason to remove the support of large textures only to draw primitves on textures.
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: The reasons for the texture chunks
« Reply #3 on: October 03, 2010, 08:35:25 pm »

1) I can still guarantee the chunk is a power of 2 for the texture
The old code guarantee it, too.
So I think it's fair to say that this is a moot point

2) You're right.. it's not optimal but we can still optimize the texture chunk size.  Just have to add a col chunk size and row chunk size.  Pretty easy mod.
Why optimize? The old code used two chunk sizes.
True but the point I was making was that the new code can be fixed to use both chunk sizes...   again this is a moot point because it really doesn't matter as both code performs as well except when the textures are larger. 

The benefit from the new code here is it will only use one chunk no matter the size of the original texture and reduce the number render calls.

3) Only one call to render needs to happen
Yeah as I said before, if you configure the chunk setting right, it needs one call to render, with the old function. Only if the texture is larger as the maximum texture size you need more chunks also more render calls. The new code can't display these large textures.
True but I think setting a limitation of the maximum texture size to 4096x4096 is reasonable IMO.

4) Drawing primitives on the texture should now become possible/easier
It's already possible. And I see no reason to remove the support of large textures only to draw primitves on textures.
That's incorrect as the SDL image was being used to render primitives and then converted to an OpenGL texture by re-generating the chunks.  The next TODO would be to remove the SDLImage stored in GLImage altogether.


In the end we are all on the same team here...  I'm just trying to make FIFE better.  The texture chunk code was convoluted and complicated and really unnecessary IMHO so I removed it.  Vtchill and I had a short conversation about it and I decided to commit the code I was testing.  IF these changes do prove to be a problem we can revert it back easily enough.  So far I haven't heard that anyone had issues so I'd imagine no one uses very large textures anyway.

In any case I'm open to reverting back to the old code if that is the consensus...  what does everyone else think?
Logged