More texture space for bitmaps

[[Krogoth86]]

Why is the texture atlas just limited to a certain and rather small amount of textures the images from the bitmap folder get applied to? It's really easy to eat up all of your space especially if you include some animated bitmaps...

So why is the limit the way it is and can't we just allow the engine to handle as much as are needed? Imo it's sort of a big limitation...

[smoth]

animated bitmaps don't work.. don't include the frames. seriously those textures are tiny you most likely have a lot of unused textures.

ati cards are the reason for the limited atlas.

[[Krogoth86]]

Well using animated bitmaps is more efficent than trying hard to fake the same effect and then having dozens of particles with dozens of transparency work to do which will bring your PC to a crawl...

ati cards are the reason for the limited atlas.

ATI cards only are the reason why the atlas cannot consist of 4096x4096 textures (because some "older" ATI cards cannot work with that). I see no reason though why there has to be this little number of 2048x2048 textures (afaik they have that size now)...

[smoth]

umm that is what I am saying, IIRC the 3do animated textures do not work. If they do someone changed something.

[[Krogoth86]]

Ahhh now I see. Sorry I misunderstood you. You are right - those 3do animated stuff doesn't work. With animated bitmaps I meant something different though: I was talking of for example using bitmaps to do explosions which consist of several bitmaps for each frame and which you can call via your CEG...

[smoth]

that is a separate atlas iirc.

[[Krogoth86]]

So can any dev comment on allowing simply more textures to paste the bitmaps on? Would there also be a slight advantage in using like 1024 sized textures instead of the 2048 ones so the engine wouldn't need to handle that big textures just for a 128x128 sized bitmap? I guess especially not so fast and older cards might benefit from using more but less big textures (although I also can imagine that the difference might even be not measureable)...

[Kloot]

Why is the texture atlas just limited to a certain and rather small amount of textures the images from the bitmap folder get applied to?

Because the dimensions (2048x2048 for both atlases) are hardcoded.

Would there also be a slight advantage in using like 1024 sized textures instead of the 2048 ones so the engine wouldn't need to handle that big textures just for a 128x128 sized bitmap?

No, the engine does not allocate all memory for the atlas textures in advance but grows it (up to the maximum size) as needed.

[[Krogoth86]]

Because the dimensions (2048x2048 for both atlases) are hardcoded.

Yeah - the question is why can't it just create a second one if the first is filled up and then a third, a fourth and so on...

No, the engine does not allocate all memory for the atlas textures in advance but grows it (up to the maximum size) as needed.

I know that but let's assume we'd have one entirely filled 2048x2048 texture. So for every 64x64 tiny tidbit of bitmap you have to use your graphics card to access and work on the entire 2048 size texture. The question is if older or simply slower GPUs (up to OnBoard stuff without fast memory of their own) would benefit from splicing things up into several textures which are smaller so they don't have to work with big textures but can look up their stuff in numerous ones which in the end eat up the same memory but don't need to let the GPU deal with a huge texture for every tiny bit that has to get a texture...

I don't expect much of it though but when making multiple textures for the atlas possible it might be clever to shrink the individual texture size for that reason and that's why I brought it up...

[smoth]

that is how the map tiles work but imagine an image 10X larger

[jK]

Because the dimensions (2048x2048 for both atlases) are hardcoded.

Yeah - the question is why can't it just create a second one if the first is filled up and then a third, a fourth and so on...

No, the engine does not allocate all memory for the atlas textures in advance but grows it (up to the maximum size) as needed.

I know that but let's assume we'd have one entirely filled 2048x2048 texture. So for every 64x64 tiny tidbit of bitmap you have to use your graphics card to access and work on the entire 2048 size texture. The question is if older or simply slower GPUs (up to OnBoard stuff without fast memory of their own) would benefit from splicing things up into several textures which are smaller so they don't have to work with big textures but can look up their stuff in numerous ones which in the end eat up the same memory but don't need to let the GPU deal with a huge texture for every tiny bit that has to get a texture...

I don't expect much of it though but when making multiple textures for the atlas possible it might be clever to shrink the individual texture size for that reason and that's why I brought it up...

sorry but just no.

tiny textures aren't faster at all, they are WAYYYYYYYYYYYYYS slower and multiple atlases just need additional c++ code to handle them w/o any advantage for the modder. Just reuse your textures and don't oversize them ...

[[Krogoth86]]

sorry but just no.

tiny textures aren't faster at all, they are WAYYYYYYYYYYYYYS slower

You're sure that it's also the case for the lower end stuff like OnBoard GPUs with very little memory bandwidth and performance?

multiple atlases just need additional c++ code to handle them w/o any advantage for the modder. Just reuse your textures and don't oversize them ...

Without any advantage? Currently it seems there is one atlas for the bitmap folder. So in order to translate it: If I didn't miscalculate you aren't allowed to use more than 67 256x256 textures. I now have two explosion animations consisting of 128x128 frames which pretty much eat up 40% of the entire bitmap space and that's just two different explosion animations. So in the end I'm going to be stuck really soon - I might shrink a tad of the bitmaps I took over from BA in my case but it won't bring me too far as the atlas already was full when I tried to import one of the animations in 256x256 size in order to test if there's a reasonable visual difference...

I think it's a quite harsh limitation simply saying: If you want to do explosion animations via bitmaps (which are so many times more efficent than pumping out dozens of particles and can inherit effects hardly possible for particles) you have a limit of like four different ones and that's it. I also know that I'm not the first to encounter the problem of having a filled atlas...

[lurker]

I think quite a lot of computers around here can't use 4096, and multiple textures is simply a lot of work.

67

Is that a joke, or should I mock you?

[jK]

sorry but just no.
tiny textures aren't faster at all, they are WAYYYYYYYYYYYYYS slower

You're sure that it's also the case for the lower end stuff like OnBoard GPUs with very little memory bandwidth and performance?

I am 101% sure.

.. If I didn't miscalculate you aren't allowed to use more than 67 256x256 textures. I now have two explosion animations consisting of 128x128 frames which pretty much eat up 40% of the entire bitmap space and that's just two different explosion animations. ...

256 is totally oversized ... and 64 of those are more than enough.
So you are doing something wrong. Don't think commercial games would use more/larger sprites. You can do with 32x32 already extreme fancy fx's.

PS: A new atlas for a new animated CEGs system would be imaginable.

[[Krogoth86]]

Is that a joke, or should I mock you?

Well I don't have my calculator with me so I had to use the oh so wonderful Windows calculator and I might have had a typo in there...

Although I'm rather sure the number is correct as 2096/256 is something around 8 giving you a bit more than 64 256 sized textures. I'm not talking of using that size for anything (although it still makes sense for some things that might make it on the screen in big size like groundflashes) - it's about simply naming the precise number of max textures...

Oh wait now I see. I used 2096 instead of 2048 for some reason - sorry it was like 2 am here...

PS: A new atlas for a new animated CEGs system would be imaginable.

That would be a nice solution too. It's not that the atlas is too small for basic bitmap stuff but it simply get's too small when you want to do some bitmap animations and i.e. not just one or two and no OTA style five-framer or something like that. In the end I'm fine with any solution that comes up in order to make this possible although I'd still go for more than just another 2048x2048 texture if it's not too much work so you simply have a solution you don't have to worry about anymore in the future...

[rattle]

You can do with 32x32 already extreme fancy fx's.

What he said... one of the few things that hasn't changed over the years.

Oversized sprite textures are the number one reason for framerate drops.

[[Krogoth86]]

What he said... one of the few things that hasn't changed over the years.

Oversized sprite textures are the number one reason for framerate drops.

As I said: I'm satisfied with the atlas for bitmaps but for animations there either should exist an alternative solution than pasting the frames on the same atlas or simply more space to do so...

[smoth]

how can we see what our CEG atlas looks like? I suspect I must be pushing that fuckin' thing by now.

[jK]

how can we see what our CEG atlas looks like? I suspect I must be pushing that fuckin' thing by now.

Code: Select all

spring /textureatlas

What he said... one of the few things that hasn't changed over the years.

Oversized sprite textures are the number one reason for framerate drops.

As I said: I'm satisfied with the atlas for bitmaps but for animations there either should exist an alternative solution than pasting the frames on the same atlas or simply more space to do so...

You are using 256x256 sprites period!

[[Krogoth86]]

You are using 256x256 sprites period!

Ehm - no I'm not. I just tried to import them once in that size to see what the difference would look like but the atlas already was full when trying to do so...