"Non POT bitmap loaded" ?

#1 Usually, this message means that the engine has loaded a Non-Power of Two image into memory. Graphics cards prefer to have their textures/images with dimensions that are a power of two, like 64x64, 128x128, 256x256, 512x512, etc. Torque 2d allows you to load images into video ram regardless of wether or not they are Power of Two (POT) because it converts the image into POT for you. Basically, it adds empty space onto your sprite to make it POT, thereby wasting a small amount of ram in the process (because of the empty space it had to create). I may have gotten some of this wrong, but thats the impression I was under..

Not sure what the deal is with it reporting a negative value. What are the dimensions of the images you are loading?

#2 Ah, now that I know POT = Power of Two the error makes a lot more sense. Thanks for the reply, I'll have to go resize them.

The images in question were only 40x10px.

#3 I had that happen with a couple of sprites as well, and it took me a few minutes to figure out what it meant.

But it did leave me wondering, if T2D pads out the sprite to make into a PoT, does it end up taking up as much RAM as it would if you'd made it a PoT image to start with?

#4 Hehe...

The reason this is funny because we were debating the best way to handle the non-POT issue and there were calls from boths side. One to do it behind the scenes automatically and one to enforce POT textures. Supporting non POT textures was definately the best call but the warning stayed.

You guys are quite correct, graphics cards need POT textures to work correctly. Recently, more modern cards don't require POT textures and if I recall, OpenGL 1.5+ has this in the spec.

T2D pads the textures or to be more accurate, the underlying platform does. We originally were going to enforce POT textures but it ended-up causing so much confusion that we decided that would be bad.

I would always recommend using POT textures, at least that way it's obviously the video-ram usage otherwise, let T2D pad them for you, it'll take an identical amount of video ram either way.

T2D will take the difference between the bitmap and the resultant texture into account when acquiring frames from imagemaps so you don't really need to worry.

I put the message in there because I though it would be good to highlight that something automagical is happening behind the scenes and I wanted it to be clear. Looks like that process is working but is perhaps a little too distracting. Find the fact that its giving negative values quite funny. It's only an approximation but not that bloody approximate. ;)

Uploading a 1025x257 bitmap wouldn't be apparent that the card ends up with a 2048x512 texture, almosty quadrupling what you'd expect to be using. Being aware of the bitmap sizes is very important if you want your games to run on as many systems as possible. That's what the chunked support is for, it splits up larger images into seperate 256x256 textures that should run anywhere although they don't support animation.

If this was on a fixed platform like the XBox, we wouldn't have to add these kind of limits or complexities. It just the nature of trying to get a product to run on systems you've never seen.

@Ben: Could you send me one of those graphics you're loading so I can see why it thinks the ram-usage is negative?

Thanks.

- Melv.

#5 *edit: All hail Melv, master of the forums!

#6 Sent you a sample Melv, it is a funny little bug.

Thanks for the very complete reply and for all the work on T2D so far. :)

#7 Thanks Ben.

Yeah, it's just a typo on my part....

"fxImageMapDatablock2D.cc" (Approx Line 188) ...

U32 bytesWasted = pImageMapBitmap->bytesPerPixel * ((mTextureWidth-mBitmapWidth)*(mTextureHeight-mBitmapWidth));

... should be ...

U32 bytesWasted = pImageMapBitmap->bytesPerPixel * ((mTextureWidth-mBitmapWidth)*(mTextureHeight-mBitmapHeight));

This will be in the next update. Thanks for the info guys.

- Melv.

#8 Just thought I'd mention something from above that might be misleading to those who don't know...

The POT texture thing doesn't mean it has to be square so you don't have to have 256x256 when 256x32 will do. As long as each axis is POT, it'll be fine but as stated above, you can quite happily ignore this if you want. As long as you know it'll internally pad the texture, it's actually easier to manage your graphics in a non-POT format as you can quite easily see the bounds of where you can draw.

- Melv.

#9 Just to chime in here as well, Melv and I will be making the final decision on how exactly to handle all this POT stuff real soon here, and an implementation will follow soon. We are debating back and forth on it, which is our usual way, and we should hopefully come up with another slick solution for this system. ;) Eventually, you won't have to worry about POT-ness at all (except with a little bit of wasted memory, but that'll be kept to the absolute minimum allowed by hardware).

#10 Maybe a silly question, but why does the default white Torque 2D background not give a POT warning? It's 800 x 600. This really confused me as I put my own background in and got the warning. Thanks to this thread, I now understand that warning, though... thanks!

ah, nevermind... I didn't just replace "background.png"... I actually had made a sprite and used it as a background. If I take away that sprite and just replace "background.png" with the new image, I don't get the POT warning.

#11 If you do want to use sprites as backgrounds then you can always use the chunked-one, it's designed for that purpose and you can do cool stuff like having it rotate and scale etc for interesting effects.

- Melv.

#12 Whats the advantage of using POT over Chunked... since chunked does not need to worry about size?

#13 The chunked stuff does just that, it splits images up into 256x256 'chunks' that will work on almost any graphics card. The downside is that they render slightly slower because we have to handle rendering seperate textures at the correct locations.

We're going to try to make all this transparent in the near future so that you can just specify some graphic and go and not worry about how the hardware should best deal with it. That'll be T2Ds job.

This'll mean that there probably won't be a special chunked-sprite class or imagemap.

- Melv.

#14 Sorry to resurrect an old thread-

I am creating art assets right now and would like to not worry about Power-Of-Two sizing so much. Melv can you let us know what T2D 1.1 is going to offer in terms of bitmap loading/resizing etc? Will it still be a good general truth that: the more our artwork aligns to Power-Of-Two sizes, the faster & more efficient the game will run on low-end graphics cards. Or is that not true any more because T2D will manage all that for us?

Thanks in advance.

#15 It's always best to smartly align and size your textures...the best T2D can do for you is to inflate to the next largest PoT size, so if you are using 129x257 for example, either you can drop it down manually to 128x256, or T2D can inflate it to 256x512.

#16 Stephen you will read this as me being argumentative but really I am NOT.. I am merely trying to make the best use of my time.

Melv said

Quote:Were going to try to make all this transparent in the near future so that you can just specify some graphic and go and not worry about how the hardware should best deal with it. Thatll be T2Ds job.

@Melv: If I can safely ignore power-of-two sizing then that's one less thing to take up my time now. Even as I write this I realize that trimming memory usage is an optimization, and with my game, it is a premature optimization. Another reason to ignore power-of-two sizing, for me, right now. Thanks in advance.

#17 That's what I was getting at :) You can certainly leave them alone and the next version will handle it for you (assuming that the specific feature made it in. I have no reason to think it didn't, but don't have a list in front of me).

However, when optimization time comes, it would be good to keep sizing in mind (as well as your design). What I was getting at in my post above is that the engine isn't going to cut down the size of an image for you if you are close to the boundary for example...that type of behaviour might work for some, but not for others, so it's not something that we like to do in engine tech in general.

#18 OK I understand. Thanks Stephen

#19 T2D Image-Maps are much more sophisticated now. In-fact, I've just spent four days typing-up the documentation for them which amounts to 25 pages of information and a few dozen images.

The POT issue is related to your graphics card, not T2D so ultimately, T2D can only support a frame if it's supported by the hardware. What T2D can do is internally reorganise your frames so that they are compatible, offer better performance and reduce wasted texels. This, of course, doesn't alter your artwork, it's an automatic process within T2D.

When I say automatic, it sounds like the developer is out of the loop but that most definately isn't the case. As Stephen pointed out, you always need to be aware of what's going on. Part of the job is to organise your artwork in the most efficient way so that your target hardware performs best. What we've done with T2D image-maps is to provide a facility so that novices don't have to worry at all, T2D will do it automagically for them. For verterans, T2D image-maps now have many options that allow you to 'get involved' in the image-map process. They now also provide a wealth of information as well as completely resolving numerous issues that went before such as filtering artifacts.

It's 8pm here and I've just finished the last 6 hours of typing the T2D image-map doco and getting it into the repo so I'm about to pour-out a whisky and kick back in front of the TV with my wife. :)

- Melv.

#20 Awesome! Thanks Melv. Enjoy that scotch :-)