code to scale a texture GL compliant (2^N * 2^N)
Torsten Mohr
has anybody got some C code that gets a 2D input region (image)
(RGB or RGBA, unsigned byte) and its dimension and converts
it to an image that can be used for textures (has dimensions
2^N * 2^N)?
The conversion should be done in high quality (bi-linear or
bi-cubic filtering).
Something like:
void convert(
void* src,
int type,
int width_src,
int height_src,
void** dest,
int* width_and_height_dest,
);
By the way, how is bi-linear scaling done at the edges any way,
when i access points outside of the source, do i just take the
color value of the border?
Thanks,
Torsten.
yooyo
int APIENTRY gluScaleImage (
GLenum format,
GLint widthin,
GLint heightin,
GLenum typein,
const void *datain,
GLint widthout,
GLint heightout,
GLenum typeout,
void *dataout);
Torsten Mohr
i didn't know that one, i think that's what i need.
Thanks,
Torsten.
Wolfgang Draxinger
> Check this one....
>
> int APIENTRY gluScaleImage (
> GLenum format,
> GLint widthin,
> GLint heightin,
> GLenum typein,
> const void *datain,
> GLint widthout,
> GLint heightout,
> GLenum typeout,
> void *dataout);
>
Argh, gluScaleImage has a few really messy bugs. Don't use it!
There are other file image scaling functions out there.
--
+------------------------------------------------+
| +----------------+ WOLFGANG DRAXINGER |
| | ,-. DARKSTAR | lead programmer |
| |( ) +---------+ wdrax...@darkstargames.de |
| | `-' / GAMES / |
| +----+'''''''' http://www.darkstargames.de |
+------------------------------------------------+
Ruud van Gaal
<wdrax...@darkstargames.de> wrote:
>yooyo wrote:
>> Check this one....
>>
>> int APIENTRY gluScaleImage (
>> GLenum format,
>> GLint widthin,
>> GLint heightin,
>> GLenum typein,
>> const void *datain,
>> GLint widthout,
>> GLint heightout,
>> GLenum typeout,
>> void *dataout);
>>
>
>Argh, gluScaleImage has a few really messy bugs. Don't use it!
>There are other file image scaling functions out there.
Incredible that this hasn't been fixed at some point, and we're
already at OpenGL1.4 something (theoretically).
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
Wolfgang Draxinger
> Incredible that this hasn't been fixed at some point, and we're
> already at OpenGL1.4 something (theoretically).
>
Problem is, that glu != OpenGL, so it hasn't been updated since OpenGL
1.1 ...
Charles E Hardwidge
Strictly speaking it is as to qualify for use of the OpenGL name an
implementation must include GL and GLU, which is one of the reasons why 3Dfx
got into hot water over their standalone OpenGL drivers and had to rename
them "Quake compatible." Why they never bothered to supply a GLU executeable
escapes me to this day.
--
Charles E Hardwidge
http://www.hardwidge.org.uk
fungus
>>Problem is, that glu != OpenGL
>
>
> Strictly speaking it is as to qualify for use of the OpenGL name an
> implementation must include GL and GLU, which is one of the reasons why 3Dfx
> got into hot water over their standalone OpenGL drivers and had to rename
> them "Quake compatible." Why they never bothered to supply a GLU executeable
> escapes me to this day.
>
I could be wrong but I think glu just calls OpenGL
functions - any old glu will do, it doesn't have to
be part of the driver.
In fact I recall reading an article on this where
people were complaining that gluNurbs couldn't be
done in hardware because glu wasn't part of the ICD.
--
<\___/>
/ O O \
\_____/ FTB.
Charles E Hardwidge
>functions - any old glu will do, it doesn't have to
>be part of the driver.
The 3Dfx standalone drivers were never part of the ICD mechanism. That is
why they had to supply GLU to claim the name OpenGL. Because they were too
lazy (or greedy) to bother doing it the driver had to be renamed to "Quake
compatible."
I can't remember clearly now. But, I think some of the function calls were
different so the system glu or mesa glu was useless. You had to build a
version specifically linked against it.
After 3Dfx started pulling stunts with ropey drivers and leaving customers
of cards that weren't the latest model out in the cold, I decided from that
point on never to support a proprietary 3Dfx feature ever again.
Coincidently they went bust within the year.
>In fact I recall reading an article on this where
>people were complaining that gluNurbs couldn't be
>done in hardware because glu wasn't part of the ICD.
I remember seeing an item on opengl.org last year where some IHV was
flogging an accelerated GLU implementation. Never heard of it again.
Replacing the system GLU with an IHV GLU is a bit naughty. Although it would
have to be aware of what implementation was running, I don't see why it
couldn't be done.
My own position on the OpenGL ICD issue is that Microsoft should be forced
to allow anyone who wants to produce a graphics API have free and fair
access to the underlying driver mechanism without being wrapped in NDA's. I
don't see it any differently to the Java/Netscape issue.
They're using their monopoly control of the Win32 platform to stifle
competition of their own competing (D3D) product. Following on from this,
the cost to developers and customers of the D3D version mess is most likely
measured in the hundreds of millions.
Torsten Mohr
> Argh, gluScaleImage has a few really messy bugs. Don't use it!
> There are other file image scaling functions out there.
thanks for that warning.
At the moment i use OpenIL for scaling an image, but that's a lot
of overhead for just rescaling an image (though OpenIL is a very
useful thing).
What is your preferred solution for scaling?
Regards,
Torsten.