Max texture size using BindTexture...
news.cis.dfn.de
In the un-accelerated mode (no HW accel), i had no troubles using textures
as big as 1024x1024...
But, when i used the HW acceleration, when textures are bigger that 512x512
it draws garbage in the texture image... I'm verifiying the
GL_MAX_TEXTURE_SIZE flag, and it says 1024.... so, what's happening?
textures are in RGB. unsigned bytes.
It looks like it's some sort of memory problem, because if i don't use
glBindTexture and pass the image on every frame, the garbage is gone... So,
my other question: How can i tell how much GPU memory is available for a
texture? or how big can be textures be when they r resident...
Other thing: OpenGL 1.2 comes on winXP, and 98SE, right? How can i tell?
where can i find documentation about which OpenGL versions comes on which
windows system?
Thanks everyone
Emi
--
____
soft...@gosierra.com
Espen Ruud Schultz
news:bajfug$eoic$1...@ID-44132.news.dfncis.de
I was just told the disturbing news that Windows only support OpenGL 1.1.
Everything higer then 1.1 is being handled by the hardware and its driver
through extensions or actually pointers or something like it...
, Espen
fungus
> Hi everyone...
>
> In the un-accelerated mode (no HW accel), i had no troubles using textures
> as big as 1024x1024...
> But, when i used the HW acceleration, when textures are bigger that 512x512
> it draws garbage in the texture image... I'm verifiying the
> GL_MAX_TEXTURE_SIZE flag, and it says 1024.... so, what's happening?
> textures are in RGB. unsigned bytes.
Sounds like a bug in your graphics card driver.
> Other thing: OpenGL 1.2 comes on winXP, and 98SE, right? How can i tell?
> where can i find documentation about which OpenGL versions comes on which
> windows system?
>
No. All versions of Windows come with OpenGL 1.1.
Extra functions can be supplied by the graphics
driver as OpenGL extensions. Most graphics cards
these days will supply OpenGL 1.2 or later.
glext.h declares everything you need.
http://oss.sgi.com/projects/ogl-sample/ABI/glext.h
To use an extension, put a function pointer in
your program (use the types in glext.h) and call
wglGetProcAddress() to get a pointer to it.
You should do this after every call to wglMakeCurrent().
--
<\___/> For email, remove my socks.
/ O O \
\_____/ FTB. The Cheat is not dead!
fungus
>
> I was just told the disturbing news that Windows only support OpenGL 1.1.
> Everything higer then 1.1 is being handled by the hardware and its driver
> through extensions or actually pointers or something like it...
>
You still haven´t mentioned what the actual
problem with this mechanism is...
...apart from the fact that you're too lazy
to type wglGetProcAddress() a couple of times.
news.cis.dfn.de
latest driver and get back to you...
It got me thinking... i downloaded the doomIII leaked demo... (just for
research purposes, i've already deleted it because IDsoftware deserves it),
and in my voodoo5500 textures have the same garbage that i had using
bindtextures...
> Most graphics cards these days will supply OpenGL 1.2 or later.
Most graphic cards is not good enough... but now my question is, does
glBindTexture come in OGL1.1 ? Because if it doesn't i will have to send my
textures to GL_TEXTURE_2D every single frame(FPS consuming).... am i wrong?
> call wglGetProcAddress() to get a pointer to it.
Yep.. i was already doing it... thanks anyway.
thanks a lot 4 your answers..! you keep this newsgroup alive.... although
Bill is helping a lot...
news.cis.dfn.de
Why would you use only GL1.1 functions anyway? they come in older cards
and un-accelerated modes... The disturbing thing is that GL1.1 in windows
has an awfull performance... GDI is even faster than the generic
implementation of GL1.1...
fungus
> in my voodoo5500 textures have the same garbage that i had using
> bindtextures...
>
"Voodoo"? Say no more...
>
>>Most graphics cards these days will supply OpenGL 1.2 or later.
>
> Most graphic cards is not good enough... but now my question is, does
> glBindTexture come in OGL1.1 ?
Yes.
fungus
> The disturbing thing is that GL1.1 in windows
> has an awfull performance...
Only the software version.
Luckily we didn't have to rewrite everything when
hardware came along (unlike the Direct3D users).
> GDI is even faster than the generic
> implementation of GL1.1...
>
GDI is hardware.
news.cis.dfn.de
> hardware came along (unlike the Direct3D users).
Thats what happens when you rely on mr Bill....
The president of General Motors once told mr. Bill:
We'll do as Microsoft.. we will build a new high tech car, but you will
have to rebuild all the oads and highways and learn how to drive again.....
(not in those exact words)
Alex Mizrahi
You wrote on Fri, 23 May 2003 10:04:17 -0300:
ncd> GL1.1 in windows has an awfull performance... GDI is even faster
ncd> than the generic implementation of GL1.1...
Microsoft Software OpenGL renderer is not slow when you don't use textures
and blending. in this case it will even beat (with CPU, let's say, about
1GHZ) some rasterizers like Riva 128 zx. T&L in this case is almost same as
T&L of that rasterizing-only hardware, and rasterizing itself is not very
slow.
With best regards, Alex Mizrahi aka killer_storm.
news.cis.dfn.de
What a coincidence! i just tried that configuration one hour ago.
This is not true... i've been using it long time ago....
It doesn't beats Riva 128 with textures of 1024x1024... it is hell of a lot
slower.. i just saw it... (without blending and linear filtering...)
fungus
>>Microsoft Software OpenGL renderer is not slow when you don't use textures
>>and blending. It beats Riva 128.....
>
> It doesn't beats Riva 128 with textures of 1024x1024... it is hell of a lot
> slower.. i just saw it...
>
Um, he said "when you don't use textures"...
:-)
Alex Mizrahi
You wrote on Fri, 23 May 2003 18:20:47 -0300:
>> Microsoft Software OpenGL renderer is not slow when you don't use
>> textures and blending. It beats Riva 128.....
ncd> What a coincidence! i just tried that configuration one hour ago.
ncd> This is not true... i've been using it long time ago....
ncd> It doesn't beats Riva 128 with textures of 1024x1024... it is hell
ncd> of a lot slower.. i just saw it... (without blending and linear
ncd> filtering...)
surely it's slower, because riva128 has memory optimized for texturing, when
your system memory is not. when such texturing is done, memory access is
almost random. and, you know, random system memory access(when it is not
cached) is about 10 times slower than several floating-point computations
applied to same amount of data.
news.cis.dfn.de
i need some cof'fee..
Emi