''Regular'' vs. Quad sprites?
Blitz3D Forums/Blitz3D Programming/''Regular'' vs. Quad sprites?
| ||
| What is the actual difference that makes the kind of sprites SpriteControl 'manually' builds (adding vertexes) be QUAD, whereas regular ones (CreateSprite(..) are...? |
| ||
| WillKoh, Surface Count! You can add QUADS to a single surface manually. Unlike, a single surface for each SPRITE. It has proven that lower surface counts improve rendering performance. |
| ||
| But the sprite-control uses only one surface... |
| ||
| sprite-control uses only one surface... Not sure what you mean, please elaborate. |
| ||
| There's also the possibilty blitz sprites use point sprites in dx..which means each sprite is only 1 vert of data to feed the gpu, rather than 4/6. |
| ||
| I've ran performance test in the past that proved time and time again that single surface systems to be faster than Bltiz Sprite based systems which is why i'm moving my reactors (particles), grass, decals, and gui systems over to a single surface. |
| ||
| Sprites are slow if your going to be using alot of them. Even when using copyentity. Mind i'm talking like 50 or more onscreen :o) Single surface is miles faster :o) |
| ||
| There's also the possibilty blitz sprites use point sprites in dx..which means each sprite is only 1 vert of data to feed the gpu, rather than 4/6. They don't. Point sprites weren't introduced until DX8. Sure would be nice to have point sprites though. |
| ||
| Last time I checked, Blitz sprites didn't mirror properly. Another point against 'em. |
| ||
| What is a QUAD, really? |
| ||
| two adjacent triangles that form square/rectangle polygon. |
| ||
| Sprites are handy since you don't have to orient them to the camera manually. But they don't support Fog, so in some cases you'll be forced to use quads anyway (eg. smoke in a landscape with fog). I first had Sprites for the HUD in my engine, but then replaces them with Quads after the introduction of the underwater mode that contains cameraFog. The number of surfaces surely matters. If you have 20'000 Sprites, this will be VEEEEERY slow, because the Renderer has to handle 20'000 Materials. It seems like the hardware uses Materials as the basement of a partial mesh: it takes a material and asks "ok, what Plygons belong to this material", so a surface is a kind of material plus the Trianlges that are using this material. You see, the more materials, the more complicated the whole process is for the hardware. But keep in mind you shouldn't reduce the surface count at all costs! Best would be to use clusters of surface-sharing Quads. This way any cluster that is behind the camera or is out of the camerarange could be ignored and skipped from rendering. Because IF your Mesh is a singlesurface mesh and is all around you, everything will be rendered, also the parts behind your back or those that are out of range. |
| ||
| That's what I figured (*please* look at 'My SpriteControl' post, btw) but how else would you make a sprite? What strange method does blitz use? |
| ||
| Blitz doesn't use a strange method it create a quad for each sprite. The 'problem' being that each quad has its own surface which is a kind of 'state change' for the gpu. When you roll your own sprite system you can pack many sprites onto the same surface which is much quicker. |
| ||
| >Aha. So how do you determine which is showing? The original sprite control (as well as my attempt) creates a surface (and mesh) for each sprite as far as I can see, though they're attached to a single pivot. |
| ||
| Not sure what you are asking. If you are creating a new surface for each quad then the chances are your system will be slower than Blitz's. Attaching them to a pivot simply gives you all the disadvantages of a single surface system and non of the advantages (speed). |
| ||
| so, aree we talking about making one large sprite, with a texture of moving particles (eg: manually coded)? |
| ||
| No. We are talking about one model (mesh) where pairs of triangle form rectangles (quads) and are moved independantly so they appear to be separate objects. |
| ||
| PointSprites have/had a lot of restrictions... when we used them in 3DMark2001 they couldn't be bigger than 128*128 on screen (some cards), and of course they all have same rotation etc. so there are only very few cases where they are actually usable. |
| ||
| Are single-surface sprites possible with pixel-perfection? |
| ||
| No. We are talking about one model (mesh) where pairs of triangle form rectangles (quads) and are moved independantly so they appear to be separate objects. Of Course! I'd never thought of that... Using individual sprites IS far too slow, but this would speed up in many terms. |
| ||
| Was the No in reply to my Q? Quads as such do not prohibit pixel-perfection you know.... |
| ||
| How could he have answered your question before you asked it? He's not THAT good. |
| ||
| Are single-surface sprites possible with pixel-perfection? Yes. skidracer posted a 'pixie' demo with pixel-perfect quads.I incorporated that into my SpriteMaster routines. See Image Packer link. |
| ||
| >>How could he have answered your question before you asked it? He's not THAT good<< Sorry, I didn't notice "No(...)" was quoted... [JimB]: does it (pixie/imagepacker) use *multiple* quads, all of which can be shown pixel-perfect, but all of them attached to the same surface? That would be something to implement in 'my version' of sprite control (or something to that effect). Another thing is that i'd like "custom isolate" meaning that the visible portition can be changed to any (in pixels) rectangular area of a quads' texture, (rather than only changing x,y-"frame") while maintaining pixel-perfection. |
| ||
| does it (imagepacker) use *multiple* quads, all of which can be shown pixel-perfect, but all of them attached to the same surface? Yes. SpriteMaster (included with ImagePacker) uses packs of images. A pack is simply a texture full of images with a reference file which tells SpriteMaster where each image is located in the texture. Every sprite (quad) you extract from the pack shares the same surface. i'd like "custom isolate" meaning that the visible portition can be changed to any (in pixels) rectangular area of a quads' texture You can do this in SpriteMaster by supplying optional 'region' parameters.A few commands have these 'region' parameters to allow you to target a specific part of the image. Here is an example which is included in the ImagePacker zip:  You can also use ChangeSprite to change the image of an existing sprite to that of another image within the texure, again, targeting a 'region' with optional parameters. |
| ||
| Are there actually multiple quads or is it just that you 'isolate' a particular part of the texture to display that as the image/sprite? The latter *is* of course exactly what I said I wanted - I know - but I've imagined using both, were one quad could be one bunch of images (or a single big-one, depending on how you treat it) and other would be another bunch of images. Then it struck me - there's no way to texture a particular quad, is it? |
| ||
| Multiple quads. The quad does isolate an area of the texture. Basically, this is what happens: Using ImagePacker you gather all of your sprites into ONE image (texture). This 'pack' of images is saved as a standard image with a definitions file. With SpriteMaster you load the pack and extract whatever image you want. The image is displayed via a quad which shares the surface of the packs texture. The quad merely points to the area in the texture containing the image (using UV offsets). You save on memory this way by only having ONE texture loaded but hundreds/thousands of quads each showing a portion of the texture. The optional 'region' parameters above simply allow you to pick a small part of an image. |
| ||
| This might help visualise things a litte better. Here is a saved pack of images from ImagePacker (scaled from 512x512):  With SpriteMaster you can extract as many images from that pack as you like:
pack=LoadPack("pack1.png")
sprite1.smSprite=GetPackedSprite("sun",pack)
sprite2.smSprite=GetPackedSprite("rock",pack)
sprite3.smSprite=GetPackedSprite("dice",pack)
PositionSprite sprite1,100,200
PositionSprite sprite2,140,245
PositionSprite sprite3,300,100
All of the extracted images share the same surface. The definitions file saved along with the texture tells SpriteMaster whereabouts the referenced image is located (as well as animation and border settings). |
| ||
| SpriteMaster seems great, it does do all I want except it relies on PNG for alpha. I made something with a separate "alpha-indicator-image", because I got no good freeware PNG editor (you know of one?). Btw, something made me wonder: Can particular surfaces be textured separately? Just trying to get everything about 3D I can... Can I use ImagePacker/spritemaster/other tools on the page of that link without paying anyone, even if a should make a commercial product? |
| ||
| Yup. They are free to use. Just a mention in the credits will do for me. |
| ||
| I'm seeking a easy to use single surface sprite/quad lib. A Library with functions equivalent to Blitz's Entity Commands (ie: EntityTranslate, EntityRotate, etc). Any and all suggestions will be appreciated. |
| ||
| I use GIMP for editing PNG images. Its free and cross platform. www.gimp.org |
| ||
| Hi Frank. I have tried to make SpriteMasterPro commands/functions easy to remember. PositionSprite RotateSprite ResizeSprite FlipSprite etc ... The hard part I suppose is understanding how packs work and extracting the sprites you require. There are lots of examples to play with though. |
| ||
| JimB, SpriteMaster looks very good. I will provide more feedback after checking it out more thoroughly. Great Editor and Documentation. Excellent Work!!! SpriteMaster Lib will have to modify to support 3D coords, for 3D particles. Are the future plans to add this functionality? |
| ||
| ... |
| ||
| Jim SpriteMaster renders 3D sprites pixel perfect. The clarity is unbelievable. There is a performance impact when positioning the sprites. Seeking some optimization routines. |
| ||
| Quick questions for JimB: Just started trying SpriteMaster - very nice. But I do have a few questions ... I can't seem to set the draw order of the sprites using "EntityOrder Sprite\c\mesh, Order". They just seem to draw in their own order regarless of what I set. And attempts to hide / show sprites using "HideEntity Sprite\c\mesh" and "ShowEntity Sprite\c\mesh" cause all sprites to vanish for a second then re-appear - I presume this is an artifact of it using a single surface. Should I just free and re-create sprites instead? Other that that it's very nice indeed :-) |
| ||
| Hello HappyCat, I can't seem to set the draw order of the sprites ... Yep. A common question. Check this thread With regards hiding/showing sprites ... The quick way to hide/show a sprite is to move it off screen and back to it's location. Or, as you say, free it up and extract it again. Doing the latter will make the sprite pop in front of the others sharing the surface though. SpriteMaster Lib will have to modify to support 3D coords, for 3D particles. Are the future plans to add this functionality? Mmm... I don't know. There are so many particle librarys around. There is a performance impact when positioning the sprites In SpriteMaster PositionSprite adjusts 4 verticies in a mesh. I read somewhere it may be quicker to clear the surface then add all the sprites again. Apparently, adjusting the verts requires the whole mesh to be re-sent to the graphics card. Not sure. |
| ||
| Thanks. I've (sucessfully) used the "move it offscreen" approach - great :-) Next thing I came across was - I'd set the blend mode of some of the sprites to additive blending, but upon creating the 3rd such sprite they all lose their additive blending. Any ideas? |
| ||
| Image Packer & SpriteMaster will make an appearance in PPF2K4. I have made some modifications to the library (mostly label name changes) so the library can integrated into the engine without conflict. I have made additions to extend 3D functionality for particles, lensflares, and decals. There are some performance issues in translating 'smSprites' that will have to be addressed. More to come. |
   |