powers of 2

#1 You don't have to make your images a POT if you're using celled or keyed because the image-map will attempt to arrange the frames such that they fit within a POT image. That said, if you already ensure that they fit in a POT image then you can guarantee that you've already got a good fit.

To answer your question, no, the actually frames can be anything. When a sprite is rendered, it just renders the portion of the texture defined by the frame-area. It's whole texture that must be (with the existing engine) a POT in size.

Hope this helps,

Melv.

#2 I'm having some glitches on the screen (vertical black lines) from time to time and not always on the same spot. It only occurs when the player is moving. This vertical line appears on all screen, meaning that affect more than a single art element at the same time.

I have art that isn't on POT, can this be the problem?

#3 No, you probably need to use "padding", this sounds like the classic bilinear filtering issue. The graphics card samples the neighbours around a texel to detemine what goes on screen therefore it can sample a single texel outside of your artwork frames. Because it interpolates, you'll still have a problem if your surround texels are completely transparent.

Padding is an automatic feature that surrounds each frame with a copy of the existing border in that frame thus ensuring that this problem goes away. The downside is that every frame occupies 2 texels in both width/height in the resultant texture. This is dealt with automatically but you should always check that you're not forcing the texture to be the next POT in size which could make it unecessarily large.

This can show more/less depending on where exactly you render it being as TGB allows you to render to fractional positions e.g. not locked to pixels.

TDN Image-Map Tutorial

Melv.

#4 Thanks Melv for quick reply.

Melv the "padding" feature only apply to CELL and KEY imagesMaps? I create a map without CELL or KEY imagesMap and I'm the still having that glitch.

TDN seems to be down :(. I'll look to your link later when it goes up.

#5 TDN is definately up. Have a look at the link when you can.

Perhaps what you're seeing isn't this then. Hard to say what it is from the description so far.

Probably best to get some images of it and post it on a thread.

Melv.

#6 So if we turn 'filter pad' on, should we make our image file 126x126 rather than 128x128? What size should I pick?

#7 Yes. If you have filter pad on and you texture width was 126 then the resultant texture width would be 128. If your width was 127 then the resultant width would *not* be 129 but 256 (the next POT).

This, of course, only applies when you're using "FULL" mode. If you've got smaller frames within your source texture then the packing routine will rearrange them to fit into the smallest possible size but it still adds that padding border around every frame (if you ask for it).

The Image-Map tutorial goes into lots of detail about this but I'm happy to answer any questions here.

Melv.

#8 I want to use key imagemaps so that my frames can be different sizes. But can I also incorporate transparency in my .png? The frames for the key example in the mentioned imagemap tutorial do not have transparency within the frames.

#9 You're asking the question so I presume you've tried and had a problem? 32-bit PNG work fine, they're used in most of the examples.

#10 Hello there,
if in CELL mode I turn on the filter pad (to avoid unintended "border" lines)it makes that the fps during the execution is so reduced, I'm not an experienced TGB developer (yet) for this reason I like to know ¿what are the best practices to load the images? practices like "...for tile maps you have to configure the source tileMap without the cell padding...", "...for sprites with few frames you can put the cell pad on..." or things like these.

Regards.
Thanks.

PS.-I have to read deeply the imageMap tutorial too.

#11 There's no special practices for loading images really. Adding a "pad" pixel around your frames increases the resultant size of the texture (you're adding pixels). Really though, you should try to do this during the development of the art as TGB is just doing this when you start your game. Remember this isn't an artefact caused by TGB but an artefact caused by the hardware texture sampling on your GPU.

If you add padding then the resultant texture size may need to be increased to the next power-of-two. I explain this in the image-map doco I wrote on TDN. Your GPU may find using the larger sized texture harder and therefore slow things down. If you start with a texture that's already a POT (say) 512x512 and you add padding then it's going to end-up increasing in size to 1024x1024 which is 4 times bigger.

Really though, this is something to consider when making you are making your game e.g. the target system spec, the padding around your sprites in the sprite-sheets etc.

#12 Hi Melv,
thanks for your response.
But to understand it better consider this example: imagine I make a simple black (or white) square to build a chess board ¿what I have to do, (or how I have to draw it) to avoid that extra lines appear? (this happened to me... and still happens).
Thank you again.
Kind regards

#13 The image-map tutorial explains this, I'm not sure I can add any more than what's already explained in detail in that tutorial.

If you don't want to use padding in T2D then add the gaps between your frames yourself when you create the art. It isn't a case of just turning options on or off, you need to understand WHY it happens. I explain that in the tutorial.

Remember this: when your graphics card samples a "pixel" in your image-map, in "SMOOTH" mode, it doesn't just use that "pixel" to determine the colour/alpha, it uses a sampling of the neighbour "pixels". Therefore, if you surround your frames with a copy of whats in the pixel inside the frame then this won't matter as the hardware will see the same "pixel".

If you have (say) purple surrounding your frames then you'll get a purple-tint to the outer "pixels" because of this hardware sampling that your GPU does.

Padding automatically does this but by doing so, it obviously increases the texture size and this is something I stated above and go into great detail in the tutorial doc.

RULE: If you're going to use padding to remove this problem then be aware of what it actually does e.g. adds new single-width border around every frame thus expanding your texture. Knowing this, make sure you understand that the texture will get bigger because of this and be aware of the new size.

If you want to visualise what's happening then use "$pref::T2D::imageMapDumpTextures=true". This will dump all image-maps (post-processed) to a folder named "imageMapDump" and you can see for yourself. Note that some image-maps may be split into multiple textures. This is all explained in the tutorial doc.

Hope this helps,

Melv.

#14 This helps, Melv, this helps.
Let's knee deep in the tutorial.
Thanks again.

#15 Melv,
For key imagemaps, all the examples I see don't have transparency within the frames. But I may have missed something.

So I want to make 3 different sized cells from this image:

(ok, this isn't real transparency b/c it's a screen grab from Photoshop so you can see what I mean. The real png appears to have a white background when in a web browser, but it's actually has an alpha channel like the top image appears to have:



you can see I tried something like this:


... with pixel (0,0) the key color. but it doesn't work.

ty

#16 The image-mode has nothing to do with transparency and I'm sure you're getting confused.

Try producing a single image like the table and use FULL mode. Draw it. Is the background transparent? All the mode does FULL, CELL, KEY is provide TGB with a clue where the frames are, it doesn't touch or process the transparency differently, that's done in the core.

Can you actually show me an screenshot of it NOT working? I mean in-game.

#17 These work no problem as full or celled in terms of transparency, etc. But to take advantage of frames, but ones that are not the same size, you need to use key mode, if I'm understanding it right.

In torque, the 3rd image above (remember the white areas are actually transparent) goes blank as an imagemap when in key mode. And the frames are listed as "1/0".

But, you're right, I am confused because your example in the tutorial works in my game (those gui buttons and sliders) but neither of these do:

(the white here is actually transparent!)

no transparency, but, again, in key mode the imagemap is blank.

#18 You can't just place frames anywhere, that's not what keyed mode is about. Have you read the image-map tutorial? You need to follow the instructions as described there. That explains how TGB scans the images in this mode.

The first step it (TGB) takes is to determine a row to scan across to look for the top-left of your frames. It does this by scanning down the left-most column for a color that isn't the color-key. As you can see, if it does this, it'll encounter the top-left of frame 0 (marked with the green pixel). When it's found this, TGB then scans along the row to the right until it finds the color-key. As you can see, this will be the cyan pixel in frame 0. Now TGB knows the top-left of the frame and its width so it only needs to determine the frames height and it can extract the frame. It does this by scanning-down from the top-left of the frame (marked with a green pixel) until it reaches the bottom-left of the frame 0 (marked with a blue pixel). Now TGB has the top-left, width and height of the frame so it extracts it!

What happens next is very important. TGB starts scanning from just past the top-right of the last frame (marked with a cyan pixel) until it reaches a non-color-key pixel. When it does this, it finds the top-left of frame 1 (marked with a green pixel). It continues to find the width and height of this frame exactly as it did the previous frame. TGB then extracts the frame and repeats finding frames until it hits the right-side of the image.

Okay, let's continue to extract more frames. After TGB has extracted the first 3 frames and has hit the right-side of the image, it moves straight back to the left-side of the image and continues scanning for more frames. The next frame it encounters will be the top-left of frame 3 (marked with a green pixel). TGB then repeats the procedure outline above. TGB will continue extracting frames until it hits the bottom of the image.

Before we go any further, let's show some of the rules with what we've learned so far. First, it should be obvious that you need to put your color-key in pixel (0, 0) e.g. the top-left. Because TGB scans down the leftmost column looking for non-color-key pixels, you should place the left of your frames against the left of your image. Also, TGB will totally ignore the first row of the image. When TGB encounters a frame, it scans rightwards capturing frames in-between non-color-key pixels. For this reason, you should align the top of all your frames. Frames can be any size but all frames must be no higher than the first frame extracted from that row. When TGB is scanning either down the first columns looking for rows to scan or actually scanning rows, it doesn't matter how many color-keys are between frames.

Phew! You may need a little time to absorb that but it shouldn't be that bad after you've read it a few times. As a summary, here are the rules to follow when creating "KEY" images:

* First, it should be obvious that you need to put your color-key in pixel (0, 0) e.g. the top-left.
* Because TGB scans down the leftmost column looking for non-color-key pixels, you should place the left of your frames against the left of your image.
* TGB will totally ignore the first row of the image.
* When TGB encounters a frame, it scans rightwards capturing frames in-between non-color-key pixels. For this reason, you should align the top of all your frames against the first one in that row.
* Frames can be any size but the next row of frames must be below the tallest frame in the previous row otherwise part of the tall frame will be extracted as part of the next row.
* When TGB is scanning either down the first columns looking for rows to scan or actually scanning rows, it doesn't matter how many color-keys are between frames.
* Although not essential, it's a good idea to "fill" non-frame space with your color-key.

#19 Thank you. I know you've (re)explained your tutorial many times at this point, so thanks again.