Adam D. Moss wrote:
If these are features that you want, go for it. There are some issues with turning arbitrary pixel data into textures (standard OpenGL textures are limited in maximum size [there are still surviving cards with a 256x256 pixel upper limit] and powers-of-two dimensions), but this can all be worked around (at worst you have to split your image across several textures taking aliasing at the seams into account, and stitch them back up when it comes to drawing).
Yes, this is all true in principle.
I think the era of 256x256 texture limitations is vanishing fast.
There can't be that many Voodoo-1's and -2's still remaining in your
target audience...but if you really do care about those people - then
splitting the texture into 256x256 pieces is workable. They may suffer
some small artifacts at the seams - but that's the price they pay for
having obsolete hardware.
Modern cards (nVidia and ATI) have also done away with the power-of-two
texture limitation - although not without some new hassles.
However, that issue at least doesn't have to be a problem. Unless you
are horribly short of graphics card memory for some reason, you can
set up your target texture at the next higher power of two and send
only the part that changed (ie your non-power-of-two image region).
Since you can also render only a part of a texture onto the target
polygon, you can pretend that you have a non-power-of-two texture
for all practical purposes *except* the RAM you waste because of it.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----