3D Sprite addons

[Kaeru Gaman]

Greater economy memory, rare switching of textures = so faster put, etc.

sorry, definitely wrong.

in your example each part has a real lot of frame.
this has to be kept in the VidMem, too.
if you cut this into 65 single sprites, you can leave all the frames out,
wich means you will need much less VidMem.

thus I also recommend not to use this as a tileset and not use clipsprite,
but use 65 single sprites for these tiles. (if not using Sprite3D)

and about the speed...
I think it's rather unimportant if the VidCard switches to other u/v coordinates on the same texture or to another texture right next to it....


additionally, concerning your request:
I would prefer to order the u/v coords for each of the four vertices of a Quad (= Sprite3D)
rather then to be bound to some horizontal/vertical clipping,
what is no big advantage compared to how it is now.

[Psychophanta]

I'm confused (due to the languaged used), what is being requested?

Is it a function to create a 3D sprite from a clipped 2D sprite? Or is it to create a non-square 3D sprite? Or is it something else?

I need 1 texture = much sprites.

See illustration:

1 texture = 65 sprites.

...

@zxtunes.com, please don't call that as "texture" because it leads to confusion. That is not a texture.
Call it SpritesMap, TilesMap or so...

[zxtunes.com]

Greater economy memory, rare switching of textures = so faster put, etc.

thus I also recommend not to use this as a tileset and not use clipsprite,
but use 65 single sprites for these tiles. (if not using Sprite3D)

This no possibly, i need rotation and blending effects.

And i need alpha channel for all sprites.
Color key this anachronism, actualy very rare.

in your example each part has a real lot of frame.
this has to be kept in the VidMem, too.
if you cut this into 65 single sprites, you can leave all the frames out,
wich means you will need much less VidMem.

This not true. I test and calculation. You forget that everyone 3D sprite should be " The texture must be a square of one of the following dimensions: 16*16, 32*32, 64*64, 128*128 or 256*256. Other sizes may work on some specific cards, but not all. "

See, i have sprite of Crab, average size 90x85, if i use 3D sprite i need create texture size 128x128. And i have 30 sprites 30 * 128*128 * 4 (RGBA)= 1.9Mb VS one texture (30 sprites on one texture)- 1 * 512x512 * 4 = 1.04 MB

Economy almost in 2 times!

[zxtunes.com]

@zxtunes.com, please don't call that as "texture" because it leads to confusion. That is not a texture.
Call it SpritesMap, TilesMap or so...

I get terminologia from HGE, this false?

[Kaeru Gaman]

[ You forget that everyone 3D sprite should be " The texture must be a square of one of the following dimensions: 16*16, 32*32, 64*64, 128*128 or 256*256. Other sizes may work on some specific cards, but not all. "

well ok, your calculation is correct.

on the other hand, I wonder how outdated this information is anyways.
I think it was the ATI pendand of the GForce4-generation what was
the last VidCard to have problems with non-standard textures...

anyhow, I would prefer setting the u/v coordinates individually,
if such a function should be implemented.
just forwarding from whole-texture to another-rectangular-hor/vert-matrix-workaround is no advantage.

[djes]

No, there's problems on a lot of GFX cards with non-square textures.
I was a bit annoyed too by these limitations, but... What's the point? By now, the smallest GFX card have at least 128Mb. Even 32Mb is sufficient for your purpose. And with 3d sprite you have rotation, alpha, zoom. I'm only using 2D sprites for panel/text and background.

zxtunes.com>Nice GFX

[Psychophanta]

Yes, congratulations if you have done those graphics.
In HGE engine as long as i see, there seems that is very different things "Texture" and "TextureRect", since GetTextureRect() function does not receive any texture handle (HTEXTURE). Sincerely, looks like there are very confusing terms... at least i miss some points.
Anyway:
http://en.wikipedia.org/wiki/Texture
http://en.wikipedia.org/wiki/Texture_%2 ... raphics%29

[Demivec]

This not true. I test and calculation. You forget that everyone 3D sprite should be " The texture must be a square of one of the following dimensions: 16*16, 32*32, 64*64, 128*128 or 256*256. Other sizes may work on some specific cards, but not all. "

See, i have sprite of Crab, average size 90x85, if i use 3D sprite i need create texture size 128x128. And i have 30 sprites 30 * 128*128 * 4 (RGBA)= 1.9Mb VS one texture (30 sprites on one texture)- 1 * 512x512 * 4 = 1.04 MB

You can break up a sprite into smaller pieces. Your 90x85 sprites can each be broken up into a 64x64 sprite and 5 32x32 sprites giving the equivalent of a 96x96 sprite.

Code: Select all

001  ;0 is the area covered by the 64x64 sprite, 1-5 are the smaller 32x32 sprites
002
345

This gives you 30*96*96*4 =1.10MB Vs one texture (30 sprites on one texture)- 1 * 512x512 * 4 = 1.04 MB. That's only 6% more.

You may also find it more useful to construct the sprite from parts (i.e. torso, head, legs, etc.) if you do not have too many of them to render at once.

[zxtunes.com]

Code: Select all

001  ;0 is the area covered by the 64x64 sprite, 1-5 are the smaller 32x32 sprites
002
345

This gives you 30*96*96*4 =1.10MB Vs one texture (30 sprites on one texture)- 1 * 512x512 * 4 = 1.04 MB. That's only 6% more.

You may also find it more useful to construct the sprite from parts (i.e. torso, head, legs, etc.) if you do not have too many of them to render at once.

Such compound sprites it is very difficult to rotate/zoom and there will be most likely defects.

[Demivec]

Code: Select all

001  ;0 is the area covered by the 64x64 sprite, 1-5 are the smaller 32x32 sprites
002
345

This gives you 30*96*96*4 =1.10MB Vs one texture (30 sprites on one texture)- 1 * 512x512 * 4 = 1.04 MB. That's only 6% more.

You may also find it more useful to construct the sprite from parts (i.e. torso, head, legs, etc.) if you do not have too many of them to render at once.

Such compound sprites it is very difficult to rotate/zoom and there will be most likely defects.

I agree, I had been negligent in overlooking the need to position those parts correctly in those processes.