Image sizes and subimages
BlitzMax Forums/BlitzMax Programming/Image sizes and subimages
| ||
| With OpenGL being used to rendering images, this means that images are promoted to powers of two in each direction. As such, there's a much stronger incentive to pack frames into a single image, to avoid wasting large amounts of space. (For example, a 129x129 image turns into a 256x256 image internally.) Unfortunately, this makes it so you can't easily rotate and scale images--and have multiple frame handles--unless you break down and write your own system using OpenGL commands. 'twould be nice to have some native support for packing images together in BMAX. |
| ||
| loadanimimage ?? |
| ||
| loadanimimage only supports a grid of equal-sized rectangles, which is not the same as packing arbitrary images into a single super-image. For example, if you have a ten frame explosion effect, and the largest frame is 100x100 and the smallest frame is 10x10, then you don't want to use a 100x100 slot for each of them. |
| ||
| not equal sized stuff can't just be packed together ... this can become quite tricky and complicated ... especially the commands you will have to use to define the position on the "pack texture" |
| ||
| Yes, I've done it before, Dreamora. Packing them is tricky, but then all you need is an array of structures indicating the UV coordinates of each frame. The space savings can be huge. In short, you take each frame that you're concerned with, strip out all the surrounding transparent space, then put it in its own image, packed into the upper left corner. You need to take care to adjust the image offset properly. Sometimes this alone can drop an image down by an entire power of two. Then it's fine to use a naive algorithm to combine images into a single frame. In terms of drawing them, it's probably easiest to use OpenGL commands. Blitz seems geared toward "one image = one frame" or having a grid of frames in an image. This is perfect for small games, not so for big ones. You can cut your vram requirements by 2 to 4 by packing. |
| ||
| BTW, we don't know for a fact that LoadAnimImage doesn't simply break up an image into a bunch of smaller images, each of which has its dimensions rounded up to powers of two. |
| ||
| Why not just use a timage array then, instead of loadanimimage? |
| ||
| LoadAnimImage currently breaks up images into little seperate textures causing a hit on the framerate - see my other threads which investigate this issue in depth. |
| ||
| i've done this sort of thing for blitz3d - packing images into one large image (or texture) then saving the pack with a definitions file which indicates where all the individual images are within the larger image. the image packer was written for a single-surface sprite sytem. see link ... |
| ||
| Why not just use a timage array then, instead of loadanimimage? They're equivalent: one rounded-up in size texture per image. There needs to be a standard way around this, outside of using raw OpenGL calls. Perhaps something as simple as specifying a rectangle in the source image, and then the 2D engine will automatically use the handle as a position in that rectangle. |
   |