No more chunked sprites?
by Michael Woerister · in Torque Game Builder · 04/21/2006 (12:29 pm) · 14 replies
Hi,
Is it true that chunked sprites and chunked imagemaps will not be supported in the level editor? Because they are quite handy for creating background images.
-Michael
Is it true that chunked sprites and chunked imagemaps will not be supported in the level editor? Because they are quite handy for creating background images.
-Michael
#2
04/21/2006 (12:56 pm)
Yes, that's were I read it at first...
#3
04/21/2006 (1:00 pm)
You can probably take it that they will be deprecated in the Level Builder then. Perhaps they might be replaced with something better? :)
#4
04/21/2006 (1:03 pm)
That's what I wanted to know. I don't care if they are taken out as long as their functionality is covered by something else. 
#5
04/21/2006 (2:10 pm)
You can use a t2dScroller and set the repeat :)
#6
04/21/2006 (2:36 pm)
No, that won't work. A t2dScroller only takes t2dImageMaps with FULL image mode. That means I am restricted to image sizes not greater than the texture hardware limit. 
#7
04/22/2006 (12:03 pm)
Isn't the "split up loading" taking care of such a thing anyway?
#8
04/22/2006 (3:01 pm)
What do you mean by "split up loading"? If you mean the new ImageMap functionality that is in since the 1.1 alpha versions then the answer is no. Non power-of-two images can be loaded since then but the maximum cell size is restricted by the maximum texture size. If you want one big image, say like the background of the grav demo, then you need something like chunked sprites. A workaround would be to load the image in CELL modeso it gets split up to several textures and then create a tilemap or as many static sprites as image frames. But thats quite inconvenient to work with (I did that in the grav demo, split the background up in 256x160 cells. I had to create 10x6 = 60 sprites and set each single one to the right frame - very tedious).
#9
Just my $.02.
04/23/2006 (6:55 am)
How many cards these days don't support 1024x1024 textures, though? 256x256 is Voodoo-era, isn't it? Are there a lot of Voodoo cards out there still among people who buy games (even casual ones)? I've been selling two T2D games for a year and never ran into anyone with problems of that type.Just my $.02.
#10
*so far I haven't found the time to dig through all the code especially the rendering related parts*
04/23/2006 (8:26 am)
Michael: And how did chunkedimage work with textures larger than the GPU limit if not by splitting up to subtextures and drawing each part correctly aligned? (which I thought is what the new autosplitting does as well, just with a different algorithm behind the scene to decide the split)*so far I haven't found the time to dig through all the code especially the rendering related parts*
#11
@Jason: Obviously there are cases where bigger textures are needed. Take a look at
http://www.garagegames.com/mg/forums/result.thread.php?qt=42987. This image (2560x960 pixels) is just too big for almost every graphics card on the market today.
04/23/2006 (8:50 am)
@Marc: I haven't looked at the code either but guess it does exactly that. But it further puts those subtexture together again automatically when rendering. It's just a question of usability. @Jason: Obviously there are cases where bigger textures are needed. Take a look at
http://www.garagegames.com/mg/forums/result.thread.php?qt=42987. This image (2560x960 pixels) is just too big for almost every graphics card on the market today.
#12
With that rather obvious statement out of the way, I can describe what the key differences are between a chunked-sprite and a "packed" image-map.
A chunked-sprite does indeed use an internal core feature called a "ChunkedTextureObject" which is controlled by the "ChunkedTextureManager". This sub-system loads an image from disk and uploads it to the graphics card as seperate textures which describe regions no more than 256x256. In this way, a potentially huge image can be loaded into graphics hardware, well over and above the maximum supported texture size. Of course, the downside here is that to render this "image", you have to render multiple textures (and live with the texture swaps etc) which can be very costly if abused.
A "packed" image-map does a similar thing in that it loads an image from disk but it doesn't upload lots of fixed-size textures. An image-map will first calculate where the frames are (as described by the image-map mode/arguments) and then it calculates the best way to arrange (pack) these logical areas into a minimal set of supported (by the current hardware) texture sizes. When it has this list, it then copies these regions from the original image into the respective texture pages. This process is fast and is much more efficient than what the chunked-texture tries to achieve.
Of course, the "packed" image-map is there not to allow massive frames (that are not supported by the current hardware) to be rendered but rather to ensure that the minimal texture space is used as well as removing the neccessity to conform to the power-of-two restriction on some cards. Also, the "pack" routine can be made more intelligent for different hardware that does allow non-power-of-two etc.
If you want to render very large imagery into a TGB scene and have that image moving, you'll still need to use the chunked-sprite but if you just want a background then the core "GuiChunkedBitmapCtrl" is probably better. The difference is that the chunked-sprite uses an image-map whereas the "GuiChunkedBitmapCtrl" uses a direct reference to the image.
I believe the chunked-sprite was deprecated because its functionality simply overlapped the core "GuiChunkedBitmapCtrl" but this was based upon the assumption you wouldn't want to move the background or use zoom on it. It's also a very costly object to use and we saw many instances of it being abused or being simply confused with what the image-map packing was trying to achieve.
It's possible that deprecating it might not be the best thing to do but we'd need to evaluate the situation here and possibly come up with a better way of supporting such behaviour.
Hope this helps,
- Melv.
04/27/2006 (12:57 pm)
Ultimately, using TGB, you're restricted to using the maximum texture size on the current hardware. Because of this, the basis-limitation in TGB is the "frame". By this I mean that the maximum size of any "frame" is the maximum supported texture size.With that rather obvious statement out of the way, I can describe what the key differences are between a chunked-sprite and a "packed" image-map.
A chunked-sprite does indeed use an internal core feature called a "ChunkedTextureObject" which is controlled by the "ChunkedTextureManager". This sub-system loads an image from disk and uploads it to the graphics card as seperate textures which describe regions no more than 256x256. In this way, a potentially huge image can be loaded into graphics hardware, well over and above the maximum supported texture size. Of course, the downside here is that to render this "image", you have to render multiple textures (and live with the texture swaps etc) which can be very costly if abused.
A "packed" image-map does a similar thing in that it loads an image from disk but it doesn't upload lots of fixed-size textures. An image-map will first calculate where the frames are (as described by the image-map mode/arguments) and then it calculates the best way to arrange (pack) these logical areas into a minimal set of supported (by the current hardware) texture sizes. When it has this list, it then copies these regions from the original image into the respective texture pages. This process is fast and is much more efficient than what the chunked-texture tries to achieve.
Of course, the "packed" image-map is there not to allow massive frames (that are not supported by the current hardware) to be rendered but rather to ensure that the minimal texture space is used as well as removing the neccessity to conform to the power-of-two restriction on some cards. Also, the "pack" routine can be made more intelligent for different hardware that does allow non-power-of-two etc.
If you want to render very large imagery into a TGB scene and have that image moving, you'll still need to use the chunked-sprite but if you just want a background then the core "GuiChunkedBitmapCtrl" is probably better. The difference is that the chunked-sprite uses an image-map whereas the "GuiChunkedBitmapCtrl" uses a direct reference to the image.
I believe the chunked-sprite was deprecated because its functionality simply overlapped the core "GuiChunkedBitmapCtrl" but this was based upon the assumption you wouldn't want to move the background or use zoom on it. It's also a very costly object to use and we saw many instances of it being abused or being simply confused with what the image-map packing was trying to achieve.
It's possible that deprecating it might not be the best thing to do but we'd need to evaluate the situation here and possibly come up with a better way of supporting such behaviour.
Hope this helps,
- Melv.
#13
The code will still exist in the engine and can be used by anyone that wants to load huge images in that particular (and expensive) manner (perhaps with a bit of update / port / maintanence work). However, as Melv points out, chunked bmp ctrl is an okay alternative for many scenarios, and there are other t2d objects that work too. Tilelayers, multiple sprites, etc. There will be a better solution down the road.
Speaking of which, Michael, if you want to take a first crack at extending the image map system to allow it to effectively chunk source images into hardware-specific sub-textures and then reference those appropriately for rendering, that could be very cool. The system would also need to output a console warning that it's chunking stuff up and that that could lead to performance problems for the game. We can discuss it over email, and I'd certainly give you a bounty for it. This would serve as a nice stop-gap. (Likely won't be able to get this into the official 1.1 release, but we'll roll it in as soon as possible afterward, if you get it done. :)
Thanks for asking, this is something we meant to clarify some time ago. :)
04/27/2006 (1:42 pm)
Good q Michael, as always. :) I deprecated chunkedsprite because it was confusing for most people. And it's just not a very clean way to do things. What the system ought to do is just have the capability to chunk up big source images as you see fit... really got nothing to do with whether its a sprite or not. The code will still exist in the engine and can be used by anyone that wants to load huge images in that particular (and expensive) manner (perhaps with a bit of update / port / maintanence work). However, as Melv points out, chunked bmp ctrl is an okay alternative for many scenarios, and there are other t2d objects that work too. Tilelayers, multiple sprites, etc. There will be a better solution down the road.
Speaking of which, Michael, if you want to take a first crack at extending the image map system to allow it to effectively chunk source images into hardware-specific sub-textures and then reference those appropriately for rendering, that could be very cool. The system would also need to output a console warning that it's chunking stuff up and that that could lead to performance problems for the game. We can discuss it over email, and I'd certainly give you a bounty for it. This would serve as a nice stop-gap. (Likely won't be able to get this into the official 1.1 release, but we'll roll it in as soon as possible afterward, if you get it done. :)
Thanks for asking, this is something we meant to clarify some time ago. :)
#14
thanks for the explanation. I remember stumbling across the ChunkedTextureManager in the source code. Until you mentioned it I totally forgot about the texture swaps :(
And I agree: the GuiChunkedBitmapCtrl can be a good solution but if you want something not so static you need something else.
Josh,
thanks for the offer. I will consider it. I want to take a more in-depth look at the problem and the image map/rendering system as it stands now before I can decide if I see myself capable of doing this. But I'll contact you about this during the next couple of days. And I will probably send you a mail too, Melv.
04/27/2006 (2:47 pm)
Melv,thanks for the explanation. I remember stumbling across the ChunkedTextureManager in the source code. Until you mentioned it I totally forgot about the texture swaps :(
And I agree: the GuiChunkedBitmapCtrl can be a good solution but if you want something not so static you need something else.
Josh,
thanks for the offer. I will consider it. I want to take a more in-depth look at the problem and the image map/rendering system as it stands now before I can decide if I see myself capable of doing this. But I'll contact you about this during the next couple of days. And I will probably send you a mail too, Melv.
Torque Owner Tom Bushby
:) or, maybe, :(