Hello,

The primitives my application needs to draw are always pretty much the
same.

The primitives could be setup up once in for example displays lists or
maybe newer extensions like vertex arrays.
(This would prevent a massive ammount of little calls/cpu overhead).

The only problem is that each primitive has a single color.

The color does have to change but not the form/coordinates.

So the shape itself can stay the same... but the color has to change.

Does OpenGL have any optimization tricks to setup primitives/objects
once and only change their colors via some fast way/trick ?

One trick which comes to mind is setting up the primitives to use some
form of texture mapping... so that only the texture itself has to be
changed in a sort of weird form of flat shading...

However texturing map itself could be expensive for the gpu/power
consumption and at the same time slow for software rendering...

So if I had to choose between texturing map and doing massive ammount
of little calls what would I choose ? hmmm... currently I am looking
for ways to untask the cpu... so maybe texturing map would be the way
to go... unless it would make the gpu run hot like crazy... and
ofcourse for software rendering texture mapping would be shit/
overkill. Texturemapping does make it a bit more difficult... having
to deal with textures and all... flat shading nice and simple...

For now I am gonna stick with flat shading/direct mode... unless
ofcourse somebody knows a nice opengl trick ? ;) :) I doubt it
though...

Then later I could give texture mapping a try and see how that works
out... kinda dangerous though.. my app can't really monitor the gpu
heat ? ;) :)

Bye,
  Skybuck.

Maybe

glMaterial
glColorMaterial

Can do this... further investigation required ;) :)

Bye,
  Skybuck.

"Skybuck" <skybuck2000@hotmail.com> wrote in message 
news:7c90f4f4-c134-4de1-a1fb-eff38cad349e@l14g2000yql.googlegroups.com...
> Hello,
>
> The primitives my application needs to draw are always pretty much the
> same.
>
> The primitives could be setup up once in for example displays lists or
> maybe newer extensions like vertex arrays.
> (This would prevent a massive ammount of little calls/cpu overhead).
>
> The only problem is that each primitive has a single color.
>
> The color does have to change but not the form/coordinates.
>
> So the shape itself can stay the same... but the color has to change.
>
> Does OpenGL have any optimization tricks to setup primitives/objects
> once and only change their colors via some fast way/trick ?
>
> One trick which comes to mind is setting up the primitives to use some
> form of texture mapping... so that only the texture itself has to be
> changed in a sort of weird form of flat shading...
>
> However texturing map itself could be expensive for the gpu/power
> consumption and at the same time slow for software rendering...
>
> So if I had to choose between texturing map and doing massive ammount
> of little calls what would I choose ? hmmm... currently I am looking
> for ways to untask the cpu... so maybe texturing map would be the way
> to go... unless it would make the gpu run hot like crazy... and
> ofcourse for software rendering texture mapping would be shit/
> overkill. Texturemapping does make it a bit more difficult... having
> to deal with textures and all... flat shading nice and simple...
>
> For now I am gonna stick with flat shading/direct mode... unless
> ofcourse somebody knows a nice opengl trick ? ;) :) I doubt it
> though...
>
> Then later I could give texture mapping a try and see how that works
> out... kinda dangerous though.. my app can't really monitor the gpu
> heat ? ;) :)
>
> Bye,
>  Skybuck. 

"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote in message 
news:b736c$4c51002e$54190f09$2176@cache1.tilbu1.nb.home.nl...
> Maybe
>
> glMaterial
> glColorMaterial
>
> Can do this... further investigation required ;) :)

Hmm I don't see how this can be used... it has something
to do with light model/shading... so probably not very usefull
for what I wanted it to do..

Bye,
  Skybuck. 

(See below for "massive parallel lookup hardware idea, inspired by the old 
vga cards")
(The idea is: instead of writing lookups to the graphics card/video 
memory/monitor... the lookups become available to the cpu/applications).

There might be a way to do what I want with performance benefits all over...

OpenGL has the ability to seperate vertex, normals, color, texture 
coordinates information into individual arrays.

glColorPointer could be used to specify a color/rgba array (for rgba mode)
glIndexPointer could be used to specify a color/index array (for palette 
mode)

The nice thing could be that this was part of opengl 1.0 or opengl 1.1...

I am not sure if windows 95 came with opengl 1.0 or opengl 1.1

The dll is called opengl32.dll at least on my system...

Microsoft seems to provide opengl95.exe as well... I am not sure what that 
is ? it does say 1.1 is it an update to 1.0 ? I am not sure...

Delphi's old opengl unit does seem to have these two methods which 
officially seem to be slight extensions... so even 1.0 or 1.1 had these 
extensions already
in place... delphi has a strange way of including these:

The function name seems to be:

PFNGLCOLORPOINTEREXTPROC

Which is really weird looking ;) apperently at the time glColorPointer might 
not have been standardized yet ?!?

The unit seems to be from 1991-1993 at least the copyright notice shows... 
so seems plausible...

The oldest date I have seen so far is 1981... kinda funny that opengl is 
already so old ! ;)

My windows 95 computer is now shutdown... so I can't try this function out 
yet... but my bet is it is supported.

This would be great since then I can "upload" all of my vertices just 
once... and only have to re-upload the color
as it changes... and then I can do some further optimization tricks.

To-be-continued/investigated ;) :)

Also I am curious if index-mode might work faster on a software rendering... 
from what I remember from the dos days writing
to a memory plane was about setting the color index if I remember 
correctly... the palette would also be set in hardware..

The hardware takes care of looking up the color indexes and turning them 
into actual colors... so at the time... no cpu lookups had to be done.

Quite amazing really since nowadays lookups are a pain/slow... ofcourse they 
not really lookups... they are more "writeups"... nothing is returned
to the user/application... instead the lookups are written to the graphics 
cards/monitor... so it's more like a "look and write up" ;) :)

I wonder if special hardware could be made for massive ammounts of 
lookups... since cpu/memory don't work so well for it...

Maybe some kind of massive-parallel lookup hardware, it will surely be 
usefull for something ?! ;) :)

Bye,
  Skybuck ;) =D 

This is the webpage that showed that the array/pointer methods could be part 
of the older opengl 1.1 or so...it mentions it on the bottom...

http://glean.sourceforge.net/state.html#ReadPixels

Functions grouped according to state... it's more like an object oriented 
view on opengl... pretty handy/nifty ;)

Bye,
  Skybuck. 

Also this webpage might also have had something to do with it ;)

http://www.songho.ca/opengl/gl_vertexarray.html

Bye,
  Skybuck. 

Indeed, this page explains it further:

http://opengl.org.ru/docs/pg/0206.html

OpenGL 1.0 had no vertex arrays though some implementations implemented it 
as an extension.

OpenGL 1.1 does have vertex arrays.

Now the big question is what version came with Windows 95 ?

Unfortunately opengl itself has no "version" information ?

The version string itself is for the renderer/vendor and seems unrelated to 
what the actual supported opengl implementation is ?!?

Ultimately it might not matter... even if windows 95 comes with opengl 1.0 
maybe it also have the extension ?! ;)

Time will tell.

At least Delphi had it... so that's a good sign ;)

Bye,
  Skybuck. 

Am Tue, 27 Jul 2010 18:03:07 -0700 (PDT)
schrieb Skybuck <skybuck2000@hotmail.com>:

> Does OpenGL have any optimization tricks to setup primitives/objects
> once and only change their colors via some fast way/trick ?

Google for

glColorMaterial(...);
glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(...);

And again: Plase stop abusing c.g.a.opengl as your personal blog. Or
more generally speaking: Stop using the whole Usenet and other web
forums as your personal blog. I did a bit of googleing on your screen
name and it doesn't look good.
--=20
CIP-Rechnerbetriebsgruppe
Fakult=C3=A4t f=C3=BCr Physik - LMU M=C3=BCnchen
Schellingstrasse 4, 80799 M=C3=BCnchen

It's is often said that opengl is a big state machine.

The question is does this extend/apply to user provided data as well, like 
verteces for example ?!?

If so then in theorie the following should work:


// rendering loop:
while true do
begin
    glClear; // perhaps... clear could be skipped as well.

    if mFirst then
    begin
        // supply vertex data to opengl state machine only on first frame
        glVertexPointer
    end;

    // supply color information for each frame.
    glColorPointer

    // draw vertex array.

    // flush.
end;

So far the theory...

The question is... will this work in practice ?!?

Or will it not work and will opengl become confused ?!?

Is the call to glVertexPointer necessary for each frame (static data) ? 
hmmm.

Time will tell, since sometime it will make an example or implementation of 
these idea's ;)

I suspect it won't work... but it would be great if it did ;) :)

I give it a 50% of working and 50% of not working.

Bye,
  Skybuck ;) :) 

Am Thu, 29 Jul 2010 11:47:59 +0200
schrieb "Skybuck Flying" <IntoTheFuture@hotmail.com>:

> It's is often said that opengl is a big state machine.

Yes. It's been defined that way.
=20
> The question is does this extend/apply to user provided data as well,
> like verteces for example ?!?

If those vertices are stored in an OpenGL object (Display List, Vertex
Buffer Object), then yes.

> // rendering loop:
> while true do
> begin
>     glClear; // perhaps... clear could be skipped as well.

Why could you skip it? There's still the content of the previous frame
here.

>=20
>     if mFirst then
>     begin
>         // supply vertex data to opengl state machine only on first
> frame glVertexPointer
>     end;

Not the vertex data is supplied here, but the information, where the
vertex data can be found. I think the function suffix -Pointer should
make this pretty clear.

>     // supply color information for each frame.
>     glColorPointer
>=20
>     // draw vertex array.
>=20
>     // flush.
> end;
>=20
> So far the theory...
>=20
> The question is... will this work in practice ?!?

Not this way. Well, you can of course use vertex arrays, and adjust the
data in the color pointer array continously. Since
gl{Color,Vertex,Normal,Attrib}Pointer don't upload you can do this even
on the fly, while the pointer is set.

If you want to upload stuff to the GPU use Vertex Buffer Objects. To
replace a portion of the VBO you can use glBufferSubData just like
you'd to with glTexSubImage.

> Or will it not work and will opengl become confused ?!?

The only one confused here, is you.

> Is the call to glVertexPointer necessary for each frame (static
> data) ? hmmm.

gl{Vertex,Color,Normal,Attrib}Pointer isn't uploading stuff. It doesn't
work like glTexImage. It's just setting a variable in OpenGL to where to
find the vertex data when instanciated by glDrawElements/glDrawArrays.
In the case VBOs are used instead of a pointer into process memory it
sets an offset in the buffer data. There's example code at the end of
http://www.opengl.org/registry/specs/ARB/vertex_buffer_object.txt

> Time will tell, since sometime it will make an example or
> implementation of these idea's ;)

For god's sake: Just read the documentation. It's all written down
there in very clear form. It's not archeology or historic research,
where you've to develop theories. Everything has been exactly specified.


Wolfgang
--=20
CIP-Rechnerbetriebsgruppe
Fakult=C3=A4t f=C3=BCr Physik - LMU M=C3=BCnchen
Schellingstrasse 4, 80799 M=C3=BCnchen

Wolfgang.Draxinger wrote:
> Am Thu, 29 Jul 2010 11:47:59 +0200
> schrieb "Skybuck Flying" <IntoTheFuture@hotmail.com>:
>> Time will tell, since sometime it will make an example or
>> implementation of these idea's ;)
> 
> For god's sake: Just read the documentation. It's all written down
> there in very clear form. It's not archeology or historic research,
> where you've to develop theories. Everything has been exactly specified.

In another words : RTFM

http://www.opengl.org/sdk/docs/

"Vladimir Jovic" <vladaspams@gmail.com> wrote in message 
news:i2s1qs$4mt$1@news.albasani.net...
> Wolfgang.Draxinger wrote:
>> Am Thu, 29 Jul 2010 11:47:59 +0200
>> schrieb "Skybuck Flying" <IntoTheFuture@hotmail.com>:
>>> Time will tell, since sometime it will make an example or
>>> implementation of these idea's ;)
>>
>> For god's sake: Just read the documentation. It's all written down
>> there in very clear form. It's not archeology or historic research,
>> where you've to develop theories. Everything has been exactly specified.

If it was:

glSetColorPointer then it would have been clear what it ment...

but just glColorPointer could mean anything...

You guys are quite amuzing... like you never supplied a buffer pointer to a 
windows api...

Gje... I wonder what would happen ;)

Bye,
  Skybuck :)) 

Actually it's quite amuzing that opengl needs a whole page to explain that 
apperently a pointer is being set and that's all... at least according to 
you guys... not that I necessarily believe you guys... an implementation 
could do anything after all.. and even if all implementations did the same 
it could still change in the future...

It's also quite amuzing how I only need 3 letters to clearify what it does:

"Set"ColorPointer...

No big (confusing) manual page needed.

Maybe OpenGL api designers should first learn and understand the basics of 
language before they go babbling some words ! ;) :)

But I will cut them some slack... since I sucked at programming in 1980... I 
WAS A BABY BACK THEN ! LOL.

Even in 1990 I kinda sucked... but hey I didn't go on designing an api ! ;) 
:)

But ok.

Now-away-days I expect better from people ! ;)

Don't just go babbling some words like a baby... try to add some 
language-like meaning to it...

It's quite crazy and amazing that they decided to cut out those 3 little 
letters as if that's too much to TYPE ! LOL.

Bye,
  Skybuck ;) :) 

On Thu, 29 Jul 2010 10:46:51 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> Now the big question is what version came with Windows 95 ?

It doesn't matter which version is shipped with the OS. The only thing
that matters is the version implemented by the driver.

> Unfortunately opengl itself has no "version" information ?
>
> The version string itself is for the renderer/vendor and seems
> unrelated to what the actual supported opengl implementation is ?!?

It's this version string, that's mandatory. It doesn't matter, which
version is implemented by the DLL that ships with Windows. Anything
that goes beyond that DLL is done via the extension mechanism.

> Ultimately it might not matter... even if windows 95 comes with
> opengl 1.0 maybe it also have the extension ?! ;)

It comes with 1.1, and yes it supports the extension mechanism.


Wolfgang

On Thu, 29 Jul 2010 17:33:36 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> If it was:
> 
> glSetColorPointer then it would have been clear what it ment...
> 
> but just glColorPointer could mean anything...

Almost every OpenGL function (except those for immediate mode) has
glGet... counterparts. I think this makes it quite obvious what the
non glGet... does.

API names should not be overly verbose, that just makes them tedious to
read. The same rule applies to variables, hungarian notation should be
outlawed.

Also good APIs have the nice property that the functions' signatures
provide usefull additional information to the coder, which then can be
saved on the identifier. Of course if a function has multiple
variants taking the core data by different types (double, float,
integer), then this MUST be somehow reflected by the function
identifier (C and export tables can't overload function names).

Now take a look at "void glVertexPointer(GLint vertexsize, GLenum type,
GLsizei stride, GLvoid const *pointer);" Just by looking at this
signature you can tell, that nothing will be copied, because a crucial
information is missing. I give you a few moments to think about what
that is. As a hint, look at glTexImage, which does copy and has this
information.

Scroll down for the solution, but please take a moment to think for
yourself.

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

To be able to actually copy something, the amount of data, i.e. the
dimensions of the buffer need to be specified. Now look at glTexImage,
it has 5 parameters, width, height, border, format and type, which
together allow to calculate the size of the buffer:

(width + 2*border) * (height + 2*border) * number_of_components(format)
* sizeof(type)
 
> You guys are quite amuzing... like you never supplied a buffer
> pointer to a windows api...

You're not seriously taking the Windows API as a guiding example for
API design? It's an abomination, the Frankenstein-Monster of APIs one
can find. And believe me: I know the Windows API, and by that I mean
the whole thing, even the most obscure parts, almost nobody reads the
documentation for.


Wolfgang

Ah yes, here you clearly demonstrate the weakness of opengl's state
machine principle.

You are under the clear illussion that the routine could actually not
trigger a copy.

How wrong you are... if there is an api somewhere else which already
specified the length of the array than it's game over for your useless
theory/assumption ;)

Not mentioning the possibility of null terminators and such and other
wacky ways of copieing arrays ;)

Now I will let it be up to you to examine the ENTIRE OPENGL SPEC to
find if such a function exists ! Good luck with that ! ;) :)

OpenGL's state machine is like "global variables"... a very bad
programming style.

Now it's up to you to find if there is a global variable somewhere in
that entire state which actually describes the size of the
array ! ;) :)

Bye,
  Skybuck.

On Thu, 29 Jul 2010 11:47:59 +0200, Skybuck Flying wrote:

> Is the call to glVertexPointer necessary for each frame (static data) ? 
> hmmm.

No. And even if you modify the array, you don't need to call
glVertexPointer() again (likewise for the other glSomethingPointer()
functions).

OpenGL remembers the pointer as client-side state (hence you need
to use glPushClientAttrib() rather than glPushAttrib()). Each call to
glDrawArrays() etc reads the required elements from the array via the
stored pointer.

There is one caveat: when using glArrayElement(), if you modify the array
contents between glBegin() and glEnd(), the results are undefined.

On Thu, 29 Jul 2010 18:48:10 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> Ah yes, here you clearly demonstrate the weakness of opengl's state
> machine principle.

Like any programming method, state machines also have their caveats.
Nobody claimed that the state machine concept being superior to other
models. However one must accept that the state machine concept far
better reflects how a hardware implementation works, than a object
based system like DirectX Graphics.
 
> You are under the clear illussion that the routine could actually not
> trigger a copy.

It must not trigger a copy. It's been specified that way.

> How wrong you are... if there is an api somewhere else which already
> specified the length of the array than it's game over for your useless
> theory/assumption ;)

Well there isn't.
 
> Not mentioning the possibility of null terminators and such and other
> wacky ways of copieing arrays ;)

Terminator tokens can't be applied universally. For example in C
strings are null terminated. Because of that you must not process files
with the str... functions of the libc: Files may contain zero bytes
anywhere, and with a usefull meaning, too. File contents can only be
processed properly using the mem... functions, because they don't use
terminators.

Now tell me: Can you think of a float value that can be used as
universal terminator?
 
> Now I will let it be up to you to examine the ENTIRE OPENGL SPEC to
> find if such a function exists ! Good luck with that ! ;) :)

There isn't. Period.

> OpenGL's state machine is like "global variables"... a very bad
> programming style.

OpenGL's state machine isn't global. The state is bound to the context.
Bind another context and you have another state. Compare ...MakeCurrent
to, say the "with" keyword of JavaScript.

And just for the record: The avoidance of global variables is a advice
given to novice programmers, so that they avoid the problems associated
with them, which they don't have the skill and experience to deal with
it. But global variables aren't bad per se, and they actually are a
design pattern in object oriented programming, namely the "singleton
pattern".

> Now it's up to you to find if there is a global variable somewhere in
> that entire state which actually describes the size of the
> array ! ;) :)

There isn't, and there will never be, because that's how OpenGL has
been designed. Like I already mentioned: Programming is not a kind of
empirical, explorative science where you form and test theories. It's a
form of mathematics, where everything has been laid out in a set
of definitions and theorems. Of course you (sometimes) measure stuff,
but only because it's more often than not very hard to derive side
effects from the theory. But technically you could, it's just more
productive to profile things.

Oh, and before you dig up some of the semantics of vertex buffer
objects and how you specify buffer sizes there: Different situation, a
VBO works like a texture. You allocate some memory within the OpenGL
context. That's different to gl{...}Pointer, where you just tell, where
in an already prepared range of address space stuff may be found. In
fact later versions of OpenGL thrive to unify the buffer concept, so
that there's only a single buffer API, contents uploaded with it may be
bound to textures, render targets, vertex arrays etc.

However gl{...}Pointer is not integral part of the buffer system. It's
used for (relative) addressing vertex data, either in process address
space or in (abstract) buffers.


Wolfgang

On Jul 29, 11:06=A0am, "Wolfgang.Draxinger"
<Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> Am Tue, 27 Jul 2010 18:03:07 -0700 (PDT)
> schrieb Skybuck <skybuck2...@hotmail.com>:
>
> > Does OpenGL have any optimization tricks to setup primitives/objects
> > once and only change their colors via some fast way/trick ?
>
> Google for

Since when is google official documentation for opengl ?! ;) :)

> glColorMaterial(...);
> glEnableClientState(GL_COLOR_ARRAY);
> glColorPointer(...);

You've been bitten again by opengl.

There seem to be two different versions of glVertexPointer and
glColorPointer.

Ofcourse I am referring to the opengl 1.1 extension which used to be

glVertexPointerEXT and glColorPointerEXT

These are still in the opengl, though I have seen one crappy dlg
library mention that it's deprecated ?!?

Now you seem to be referring to VBO which is something completely
different.

The prototype you mentioned seem to be for VBO which ofcourse can't
work with opengl 1.1 since it didn't have it back then me thinks/
assumes ?! ;) :)

Furthermore enabling the vertex_array_ext is down with

glEnable and not with glEnableClientState as you say...

So clearly your opengl skills are lacking and have been confused by
opengl ! ;)

Good luck with that ! ;) :)

None the less some of your posts have been mildly helpfull but I take
them with a grain of salt ;) :)

Bye,
  Skybuck.

On Jul 29, 6:45=A0pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> On Thu, 29 Jul 2010 10:46:51 +0200
>
> "Skybuck Flying" <IntoTheFut...@hotmail.com> wrote:
> > Now the big question is what version came with Windows 95 ?
>
> It doesn't matter which version is shipped with the OS. The only thing
> that matters is the version implemented by the driver.

Ofcourse it does matter because otherwise DLL loading will fail if
it's statically bound.

None the less the vertex array ext needs to be loaded with wgl
function it seems.

>
> > Unfortunately opengl itself has no "version" information ?
>
> > The version string itself is for the renderer/vendor and seems
> > unrelated to what the actual supported opengl implementation is ?!?
>
> It's this version string, that's mandatory. It doesn't matter, which
> version is implemented by the DLL that ships with Windows. Anything
> that goes beyond that DLL is done via the extension mechanism.
>
> > Ultimately it might not matter... even if windows 95 comes with
> > opengl 1.0 maybe it also have the extension ?! ;)
>
> It comes with 1.1, and yes it supports the extension mechanism.

The question was ofcourse, does it support vertex_array_ext.

And no ofcourse it does not...

It's never mentioned in the extension string on windows 95.

None the less... I tried it anyway and the loading with wgl fails.

So unfortunately glVertexPointerEXT is not available on the software
renderer that came with windows 95 ?!

None the less it does come with Windows XP ! ;) :) so I should be able
to code different paths depending on if it's available or not for
extra speed ups on windows xp ! ;) :)

Plus maybe even VBO's... but what adventage VBO offers over vertex
array has to be further examined ;)

Best to support all three paths in case older graphics cards don't
support VBO but do support vertex array ext ;)

Bye,
  Skybuck.

Well excuse me as a newby for confusing the way vertex buffer objects
work with vertex arrays... it almost seems as the same thing...
apperently there is a difference in the way it is stored or not ?!?

You pretty much brough the whole subject up of where the copy is
actually kept or made... as far as I can tell from the opengl 2.1
reference documentation... these kinds of details are not specified...

Perhaps for driver implementors... but not for the end user... at
least not in the docs I have seen so far...

A great short coming of the documentation !

It would be very helpfull if every api function explained what it does
cpu and gpu wise... for hardware implementations that is...

Ofcourse documentation writers will quickly say: "it's implementation
dependant"

So then this whole conversation quickly becomes a mute point.

Unless you can point me towards documentation/specifications which
actually state what needs to happen where/when.

Until I see such documentation/specs I am gonna cut this discussion
short because it's just a waste of time ! ;) :)

Bye,
  Skybuck.

Am Fri, 30 Jul 2010 03:12:47 -0700 (PDT)
schrieb Skybuck <skybuck2000@hotmail.com>:

> Well excuse me as a newby for confusing the way vertex buffer objects
> work with vertex arrays... it almost seems as the same thing...
> apperently there is a difference in the way it is stored or not ?!?

Vertex Arrays are a means of _access_ for vertex data. Vertex Buffer
Objects are a means of _storage_. Vertex Array access can be either
directed to process address space or into GPU address space.

> You pretty much brough the whole subject up of where the copy is
> actually kept or made... as far as I can tell from the opengl 2.1
> reference documentation... these kinds of details are not specified...

It is clearly stated, that vertex array access does not create a
persistent OpenGL state (like for example you can't create Display
Lists with glDrawElements/glDrawArrays).

> Perhaps for driver implementors... but not for the end user... at
> least not in the docs I have seen so far...

I'm doing OpenGL for >10 years now. And guess what: I learnt everything
from the official documentation, i.e. the Official Programming Guide
(Red Book), reading example code and most importantly using my brain.
But I didn't start as a novice, I had some experience with graphics
programming, mainly implementing raytracers and rasterizers. And I was
backed up by programming experience and some experience in reading
technical documentation.

> A great short coming of the documentation !
>=20
> It would be very helpfull if every api function explained what it does
> cpu and gpu wise... for hardware implementations that is...

This is done in the specification. Of course one must be able to
properly read it, and not expect redundant information to be spread
across the whole thing. Every piece of information within the spec
affects the whole thing, but is written only there where specified.

> Ofcourse documentation writers will quickly say: "it's implementation
> dependant"

Not for OpenGL. An implementation must exactly follow the spec, to
claim itself to be "OpenGL".

> Unless you can point me towards documentation/specifications which
> actually state what needs to happen where/when.

OpenGL is defined in terms of an abstract rendering machine. The way
this machine works and behaves is specified in all details in the
specification (not the reference!)

Here you find the spec for OpenGL 2.1 which is today something like the
smallest common denominator of current implementations.
http://www.opengl.org/registry/doc/glspec21.20061201.pdf

What you call "lack of documentation" I'd call "lack of understanding
and ability to read technical documentation by the reader".


Wolfgang
--=20
CIP-Rechnerbetriebsgruppe
Fakult=C3=A4t f=C3=BCr Physik - LMU M=C3=BCnchen
Schellingstrasse 4, 80799 M=C3=BCnchen

On Fri, 30 Jul 2010 00:59:32 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> On Jul 29, 11:06=C2=A0am, "Wolfgang.Draxinger"
> <Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> > Am Tue, 27 Jul 2010 18:03:07 -0700 (PDT)
> > schrieb Skybuck <skybuck2...@hotmail.com>:
> >
> > > Does OpenGL have any optimization tricks to setup
> > > primitives/objects once and only change their colors via some
> > > fast way/trick ?
> >
> > Google for
>=20
> Since when is google official documentation for opengl ?! ;) :)
>=20
> > glColorMaterial(...);
> > glEnableClientState(GL_COLOR_ARRAY);
> > glColorPointer(...);
>=20
> You've been bitten again by opengl.
>=20
> There seem to be two different versions of glVertexPointer and
> glColorPointer.

No, there are only those.

> Ofcourse I am referring to the opengl 1.1 extension which used to be

Vertex Arrays have been part of OpenGL since version 1.1, and not as an
extension. The opengl32.dll shipped with Windows is OpenGL 1.1 so you
can use them directly w/o going through the extension mechanism.

> glVertexPointerEXT and glColorPointerEXT
>=20
> These are still in the opengl, though I have seen one crappy dlg
> library mention that it's deprecated ?!?

Those are EXT, thus not the version the ARB has choosen to be included
in later versions. Some very old programs may still rely on those,
that's why current implementations still ship them. But you should not
use them.

It are ARB extensions, that eventually become part of a later OpenGL
version proper.

> Now you seem to be referring to VBO which is something completely
> different.

VBO =3D storage
Vertex Array =3D access method.
=20
> The prototype you mentioned seem to be for VBO which ofcourse can't
> work with opengl 1.1 since it didn't have it back then me thinks/
> assumes ?! ;) :)
>=20
> Furthermore enabling the vertex_array_ext is down with
>=20
> glEnable and not with glEnableClientState as you say...

Vertex Arrays are a client state, because the vertex data is on the
client side (process address space), not the implementation side.

> Good luck with that ! ;) :)
>=20
> None the less some of your posts have been mildly helpfull but I take
> them with a grain of salt ;) :)
>=20
> Bye,
>   Skybuck.

You know, I could just killfile you. But I don't because I still
haven't given up on you. But so far you've prooven to be an excellent
case of the Dunning-Kruger effect.


Wolfgang

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:20100730141002.3947b86e@narfi.yggdrasil.draxit.de...

> Dunning-Kruger effect.

Haven't heard of that before. It explains a lot about a lot.

I'll shut my mouth before I fall foul of irony, the fifth fundamental force

-- 
Charles E Hardwidge  

On Fri, 30 Jul 2010 03:12:47 -0700, Skybuck wrote:

> Well excuse me as a newby for confusing the way vertex buffer objects
> work with vertex arrays... it almost seems as the same thing...
> apperently there is a difference in the way it is stored or not ?!?

Buffer objects may be stored in video RAM, which need not be part
of the application's address space.

> smallest common denominator of current implementations.http://www.opengl.org/registry/doc/glspec21.20061201.pdf

You call that a spec ?

I call that a fairy tail story.

Beheheehehehe.

Take a look at a real spec like Win32 api.. everything one needs to
know is in there. Call by Call, Concept by Concept, Hardware issue by
Hardware issue.

Not some intermangled crap.

Bye,
  Skybuck.

On Fri, 30 Jul 2010 14:19:43 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> > smallest common denominator of current
> > implementations.http://www.opengl.org/registry/doc/glspec21.20061201.pdf
> 
> You call that a spec ?
> 
> I call that a fairy tail story.

Then you're reading it the wrong way. I can't help you with that, but
maybe it helps you, if you read some other specs - you know, for
exercise. I recommend you the "Single Unix Specification"
http://www.opengroup.org/onlinepubs/009695399/
and after that a nice bunch of RFCs
http://www.rfc-editor.org/rfcxx00.html

> Take a look at a real spec like Win32 api.. everything one needs to
> know is in there. Call by Call, Concept by Concept, Hardware issue by
> Hardware issue.

Tell THAT the guys who develop Wine. Either they will slap you in the
face, or they will laugh off their asses. The Windows API in large
parts does not, what's written in its documentation. I for example have
quite a think binder in which I collected notes how to work around
certain bugs, or which non-documented steps had to be taken to make
things work.

Here's one for you. Open a serial port and set parameters solely by
using CreateFile and SetCommDCB, not using BuildCommDCB. BuildCommDCB
won't help in in special cases, like if one requires asymmetric baud
rates - yes this is possible and I got some devices that require
this).

> Not some intermangled crap.

You opinion, not mine. And given the fact, that there are much more
OpenGL implementations (at least NVidia, AMD and Intel on Windows,
Linux, FreeBSD, MacOS X, the OpenGL ES versions of the PlayStation
series, Nintendo with the DS, PowerVR on iOS, Android) than, say
DirectX I'd say, real programmers have no difficulty reading and
implementing it.

But you in numerous occasions showed clearly your disability to
properly read documentation.


Wolfgang

Kinda strange how my own messages from google newsgroup don't even arrive at 
this newsgroup... gje I wonder why ?! ;) :)

Anyway... back to outlook express now that the newsserver is working again.

I was just at my mommy's house... and guess what...

The radeon 9000 doesn't even support opengl 1.1 vertex arrays ?!? Holyshit 
?!

And it also doesn't support vertex array extension ?!? Holyshit ?!?

Or is something wrong with the test program ?!? I don't think so ?!?

But how the hell can Quake3 work on that machine ?!?

Since Quake3 does seem to use vertex arrays ?!?

Perhaps Quake3 has a fall-back mechanisme to immediate mode... or perhaps 
it's using VBO's ?!?

This definetly requires more investigation and spying on quake3 opengl api 
calls thanks to
glIntercept tool or so !?!

Unfortunately I had to leave my mommy's house to go do something.

But rest assured... this investigation will continue !

TO-BE-CONTINUED ! =D

Bye,
  Skybuck >=D 

On Sat, 31 Jul 2010 13:28:38 +0200, Skybuck Flying wrote:

> The radeon 9000 doesn't even support opengl 1.1 vertex arrays ?!? Holyshit 
> ?!
> 
> And it also doesn't support vertex array extension ?!? Holyshit ?!?
> 
> Or is something wrong with the test program ?!? I don't think so ?!?

I think so.

Maybe you should clarify what you mean by "doesn't support".

Are you getting link errors relating to glVertexPointer?

> Perhaps Quake3 has a fall-back mechanisme to immediate mode... or perhaps 
> it's using VBO's ?!?

VBOs didn't exist when Quake 3 was released.

Hmmm... I sent an e-mail to myself to acquire the radeon 9000 extensions... 
I am examining it now... and strangely enough vertex array extension does 
seem present

but now it's called ext_vertex_array instead of vertex_array_ext... probably 
doesn't matter but strangely enough my test program couldn't find it... very 
strange:

See ***

It also has something called:

"
WGL_EXT_extensions_string
"

What the hell is that ? hmm...

Vendor:
ATI Technologies Inc.
Renderer:
RADEON 9000 DDR x86/MMX/3DNow!/SSE
Version:
1.3.1008 WinXP Release
Extensions:
GL_ARB_multitexture
GL_EXT_texture_env_add
GL_EXT_compiled_vertex_array
GL_S3_s3tc
GL_ARB_occlusion_query
GL_ARB_point_parameters
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_window_pos
GL_ATI_element_array
GL_ATI_envmap_bumpmap
GL_ATI_fragment_shader
GL_ATI_map_object_buffer
GL_ATI_texture_env_combine3
GL_ATI_texture_mirror_once
GL_ATI_vertex_array_object
GL_ATI_vertex_attrib_array_object
GL_ATI_vertex_streams
GL_ATIX_texture_env_combine3
GL_ATIX_texture_env_route
GL_ATIX_vertex_shader_output_point_size
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texgen_reflection
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_mirror_clamp
GL_EXT_texture_object
GL_EXT_texture_rectangle

***
GL_EXT_vertex_array
***

GL_EXT_vertex_shader
GL_HP_occlusion_test
GL_NV_blend_square
GL_NV_occlusion_query
GL_NV_texgen_reflection
GL_SGI_color_matrix
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SUN_multi_draw_arrays
GL_WIN_swap_hint
WGL_EXT_extensions_string
WGL_EXT_swap_control

Bye,
  Skybuck. 

The only explanation I can think of is that the ati/radeon 9000 driver only 
supports the extension for a single rendering context... but that sounds 
pretty hard
to believe...

Bye,
  Skybuck. 

Only other explanation I can think of is:

Maybe first EnableClientState( vertex array etc) has to be enabled before a 
call to wglProcAddress... to load the extension ?

However this is not necessary for nvidia cards.

Bye,
  Skybuck. 

On Sat, 31 Jul 2010 13:40:33 +0200, Skybuck Flying wrote:

> Hmmm... I sent an e-mail to myself to acquire the radeon 9000 extensions... 
> I am examining it now... and strangely enough vertex array extension does 
> seem present

Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. You
don't need to use an extension.

Maybe you should try the Mesa/GLUT/"red book" demo programs.

On Jul 29, 6:45=A0pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> On Thu, 29 Jul 2010 10:46:51 +0200
>
> "Skybuck Flying" <IntoTheFut...@hotmail.com> wrote:
> > Now the big question is what version came with Windows 95 ?
>
> It doesn't matter which version is shipped with the OS. The only thing
> that matters is the version implemented by the driver.

You seem pretty foolish to believe that it doesn't matter.

Extensions in opengl 1.1 will need to be acquired via wglProcAddress.

If those extensions become part of the opengl 2.0 standard then they
will need to be acquired with GetProcAddress.

Therefore it does matter what kind of opengl dll is being used.

Seems pretty self-evident to me ! ;) Also seems to be the practice.

Bye,
  Skybuck.

I was curious the way the opengl 3.0 api unit in Delphi acquires the
pointer to glVertexPointerr...

The dgl unit first tries GetProcAddress and if that fails it does
wglProcAddress.

The strange thing is that the delphi unit fails the GetProcAddress
while the dwg unit does not fail the GetProcAddress...

The problem is the delphi opengl unit that came with it links
statically... if doesn't actually acquire all routine pointers...
there is no library handle available.

So I tried loading the DLL again manually... and that's when the
GetProcAddress failed for glVertexPointer.

I now believe loading DLL's twice might produce strange results ?!? Or
maybe something else is going on...

It did seem to appear to load the library... but it did not appear to
load the function pointer.

Kinda strange... best thing for me to do is make my own tiny little
opengl unit and solve all little problems.

Bye,
  Skybuck.

Show me some documentation which says that "client side" is cpu side
and that "server side" is gpu side.

Never seen it.

The contrary is actually true... I just scanned for "server" it
actually says "server code" can be executed/waited on on cpu or
hardware side.

The opengl documentation is very abstract which means it's open for
interpretation. Crazy things like remote desktops and all that
stuff... or gpu hardware...

Until there exists opengl documentation solely written for the
performance of gpu acceleration you have no right to question my
doubts on the documentation ! ;) :)

Bye,
  Skybuck.

On Jul 31, 6:00=A0pm, Nobody <nob...@nowhere.com> wrote:
> On Sat, 31 Jul 2010 13:40:33 +0200, Skybuck Flying wrote:
> > Hmmm... I sent an e-mail to myself to acquire the radeon 9000 extension=
s...
> > I am examining it now... and strangely enough vertex array extension do=
es
> > seem present
>
> Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. Yo=
u
> don't need to use an extension.

So are you saying that glVertexPointer is part of the OpenGL 1.3
standard ?

What does it mean when a routine becomes part of the standard ?

I think I know the answer.

But perhaps you would like to explain it to the Wolfgang guy...

He seems confused and unaware of it ;)

Bye,
  Skybuck.

On Jul 31, 6:00=A0pm, Nobody <nob...@nowhere.com> wrote:
> On Sat, 31 Jul 2010 13:40:33 +0200, Skybuck Flying wrote:
> > Hmmm... I sent an e-mail to myself to acquire the radeon 9000 extension=
s...
> > I am examining it now... and strangely enough vertex array extension do=
es
> > seem present
>
> Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. Yo=
u
> don't need to use an extension.
>
> Maybe you should try the Mesa/GLUT/"red book" demo programs.

The Radeon 9000 driver does not support the glVertexPointerEXT which
is weird.

Why would it remove such an extension ? It breaks backwards
compatibility first of all.

Second of all it does not support glVertexPointer via the
wglGetProcAddress again very weird and again breaking backwards
compatibility it seems.

My advice to driver writes is:

Support all routine pointers via GetProcAddress and especially
wglProcAddress... simply keep older extensions available otherwise
older apps will break.

My application is nice example of that, even if it's kinda
whacky ;) :)

None the less I will have to adept it so it tries both ways...
GetProcAddress and wglProcAddress...

Why ARB wants to hussle all these pointers through each other at each
new standard is beyond me and weird...

If they wanna push compliance they can simply say:

"These and these extensions are required in Opengl 4.0".

And done with it... everything can stay the same...

But noooooo... now suddenly all the pointers need to be removed,
moved, duplicated etc... it gets messy !

Bye,
  Skybuck.

On Sat, 31 Jul 2010 10:14:34 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> The Radeon 9000 driver does not support the glVertexPointerEXT which
> is weird.

You don't need an extension. Vertex Arrays have been part of core
OpenGL for a *very* *long* *time*.

> 
> Why would it remove such an extension ? It breaks backwards
> compatibility first of all.

Because it's been superseeded by the core Vertex Array functionality,
which uses a slighty simplified interface. Nobody uses
GL_EXT_vertex_array anyway.

> Second of all it does not support glVertexPointer via the
> wglGetProcAddress again very weird and again breaking backwards
> compatibility it seems.

YOU DON'T NEED TO wglGetProcAddress IT. IT'S PART OF CORE OpenGL, JUST
USE IT!

> My application is nice example of that, even if it's kinda
> whacky ;) :)

Fix your app to use the core vertex arrays. If that DLL you use for
Win95 doesn't support them, well. Windows 95 is from 1995, at that time
OpenGL 1.1 didn't exist yet. That was 15 years ago.


Wolfgang

It truely does become messy and it's very annoying.

I can't simply go on and try GetProcAddress followed by
wglGetProcAddress on failure of the first one.

Simply because some functions need to be loaded first before
wglGetProcAddress can be done... if the "Get" letters are actally
missing sue me or sue them... would be another nice inconsistency
there ! ;)

Anyway now it's hard to tell what functions are actually *garantueed*
to always be found with GetProcAddress... I will have to take a guess
and say: everything from OpenGG 1.1 but that sure as hell ain't
true... at least not according to the microsoft win95 renderer...
maybe that renderer just incomplete...

The thing I will acquire via GetProcAddress only... I will try to
limit that to basic initialization only... like wglGetProcAddress,
wglCreateContext... as part of library "pointer initilization"... and
then all other pointers will get the dual treatment hoping that it
will work.

There is another problem... now I can't simply find out if it's an
extension or if it's a standard...

Perhaps the version string could be used to find out what kind of
opengl it is... I like to do things correctly and also provide the
user with information if I so desire.. and the information has to be
correct... and not some big mess like dwg unit example is... mess
leads to problems leads to bugs.

Also just basing conclusion on an extension string is pretty stupid...
it should be based on actual pointers... if they still nil then
clearly something went wrong.

Bye,
  Skybuck.

Perhaps I didn't load the function pointers correctly for the
standard. This is were the opengl confusion is at it's best... even
wolfgang is confused/unaware by it...

The extension ofcourse need to be loaded with wglGetProcAddress.

But what about "standard" functions ?!?

Sometimes wglGetProcAddress seems to work for standard functions as
well...

But I have a feeling that GetProcAddress is to be used for standard
functions which is something entirely different.

If GetProcAddress is to be used than that means the routines
prototypes/headers actually became part of the DLL... which is a big
difference compared to the extensions which are being supplied via a
special mechanisme it seems.

Thus I now believe I should have used GetProcAddress for the standard
functions ?!? At least for the RadeOn...

Now the question is will this also work on nvidia ?

Was the failure because I tried to load the library twice... or is
something else strange going on...

Time will tell ;)

I have a feeling it will all prove to be a big mess, since I see no
reason why loading a DLL twice would lead to these kinds of weird
problems ;) then again might have something to do with it... me not
sure about that... so also time will tell ;) :)

Bye,
  Skybuck.

On Sat, 31 Jul 2010 10:05:12 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> So are you saying that glVertexPointer is part of the OpenGL 1.3
> standard ?

Yes!!! It's part of OpenGL since version 1.1 (in words: One Dot One).

> What does it mean when a routine becomes part of the standard ?

It means, that if glGetString(GL_VERSION) returns you that version,
those functions must be made available to you. Since opengl32.dll /
libGL.so are not part of the driver and thus can't determine the
version, any function that goes beyod a certain version (1.1 in the
case of Windows) must be used through wglGetProcAddress. Now Windows
does support OpenGL 1.1 by default, so everything in there can be used
directly.

> He seems confused and unaware of it ;)

The only one confused here is you.

I was thinking about it, and now I do it. I AM CHALLENGING YOU: I
bet, that for every task you give me in OpenGL, I can give you a
solution within a day, as long as it's not about an unsolved part of
computer science (so don't request from me a program that solves P = NP
using OpenGL or similar) or a overly complex problem (like a fully
featured graphics engine). I mean tasks solely focusing on OpenGL. Like
those tutorials on nehe.gamedev.net. WARNING: I'm facing some deadlines
in the next weeks: August 4th I've to deliver my current project. From
August 11th to 19th I'm on a conference, so let's exclude those from
the challenge. But for anything else I'm free. You got an OpenGL
question and want a custom tailored tutorial program? This is your
chance!

Some boundary conditions: The last time I actively coded in Delphi was
12 years ago. So let's stick to C, C++ and Python (I doubt you'd
understand solutions in Haskell or OCaml anyway, and OpenGL + Java is
a PITA) - maybe we could include JavaScript/WebGL, but then solutions
depend on a working browser. So only contemporary OS and
hardware/drivers are considered; if the resulting program doesn't work
<= Win2k, MacOS 9, Linux 2.4 / XFree86 v4 that's not my problem. I
develop for the future, not the past. Also challenges on non ARB
extensions won't be accepted. Not that I couldn't solve them; but
despite all the cool/old hardware I have piled up, I don't have them
all, so I can't test for every EXT or vendor specific extension.

BRING IT ON!


Wolfgang

On Sat, 31 Jul 2010 10:02:49 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> Show me some documentation which says that "client side" is cpu side
> and that "server side" is gpu side.
> 
> Never seen it.
> 
> The contrary is actually true... I just scanned for "server" it
> actually says "server code" can be executed/waited on on cpu or
> hardware side.

We're talking the X11 client/server model here. The "server" is
everything responsible for actually displaying stuff (OpenGL driver,
graphics hardware, display device), the "client" is anything that
connects to the server to have things displayed. Of course of server
and client run on the same machine then the implementation/driver is
at liberty to move certain operations into the client for better
utilization. This is then called "direct rendering" and it's status can
be queried with the GLX API.

> The opengl documentation is very abstract which means it's open for
> interpretation. Crazy things like remote desktops and all that
> stuff... or gpu hardware...

Yes. OpenGL is abstract, because it's meant to be Open (hence the
name). It's trivial to do OpenGL over networks, if you're using it in
X11: X11 is network transparent, the OpenGL in X11 protocol (GLX) thus
can traverse networks, too. On a Linux box:

~ $ ssh -X foobar@example.com glxgears

glxgears will run on example.com, OpenGL commands will be carried over
IP and rendered on your local X11 scree.

> Until there exists opengl documentation solely written for the
> performance of gpu acceleration you have no right to question my
> doubts on the documentation ! ;) :)

OpenGL doesn't care about GPUs. OpenGL is specified in terms of an
abstract graphics machine, and an implementation follows the rules of
that machine. Kinda like how C is specified. And similar how JavaVM is
mapped to actual hardware. That is unlike DirectX, which has a
close mapping to hardware capabilites (hence terms like "DierctX 10
class GPU").


Wolfgang

On Sat, 31 Jul 2010 09:48:35 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> You seem pretty foolish to believe that it doesn't matter.

I don't just believe, I *know* that it doesn't matter.

> If those extensions become part of the opengl 2.0 standard then they
> will need to be acquired with GetProcAddress.

YOU DON'T USE GetProcAddress ON opengl32.dll. Always use
wglGetProcAddress. Keep in mind you need an active OpenGL context for
wglGetProcAddress to work.

Explanation:
Say you got two different GPUs in your machine, like an NVidia and an
ATI. Depending on which screen your OpenGL program is started it will
use a different driver and the function pointer returned by
wglGetProcAddress will thus be different (it points into driver code!).
The functions obtained directly from opengl32.dll are silently patched
with by the ICD with calls into the actual driver code and
automatically adjusted when changing the context.

The function pointers returned by wglGetProcAddress are only
valid within the rendering context that was active when
wglGetProcAddress has been called, so you need to maintain a list of
function pointers for each rendering context.

If there wasn't the software fallback, opengl32.dll doesn't actually
contain any OpenGL code. It's more like a placeholder loaded into
processes, which is replaced by the ICD (OpenGL driver). That's also
why GetProcAddress on extension functions is not reliable: You're not
loading anything from that DLL. What happens is a lot more interesting.
There are a number of names for it, but the most common is "virtual
page mapping": The operating system kernel (and any driver) can inject
code into a process' address space, that's how system calls and the
like are implemented. Most of this code is accessed by interface
libraries (like kernel32.dll, system32.dll and the like, opengl32.dll
belongs, to them too): What they do is providing some levers to your
programm to access those virtual pages in a portable way. If you'd knew
the locations of those virtual pages, you wouldn't need kernel32.dll &
Co and could access them directly. Now opengl32.dll only brings so much
levers, namely the ones for OpenGL1.1, but the ICD has so much more.
But it also has wglGetProcAddress, which allows your program to
retrieve the location of something in a kernel mapped virtual page.
This virtual page may lie outside of the mapping of opengl32.dll and
thus GetProcAddress may fail, because GetProcAddress can only see
what's in the DLL. Some ICDs also patch into GetProcAddress to also
allow access through that, but that's an ugly hack, done to get
programs written by morons like you (Skybuck) to work.

> Therefore it does matter what kind of opengl dll is being used.

There's only two versions of the opengl32.dll, namely the one Microsoft
shipped since Windows NT 4. Windows Vista brought a slightly updated
version, supporting OpenGL1.4, but that's still OLD. 


Wolfgang

Hi,

Skybuck wrote:
> Ah yes, here you clearly demonstrate the weakness of opengl's state
> machine principle.

No, here you demonstrate your inability to read technical documentation.

>
> You are under the clear illussion that the routine could actually not
> trigger a copy.
>
> How wrong you are... if there is an api somewhere else which already
> specified the length of the array than it's game over for your useless
> theory/assumption ;)

No, his - as you call it - "theory" wouldn't be in danger, even if such
a stupid thing as you propose here would exist in GL.

> Not mentioning the possibility of null terminators and such and other
> wacky ways of copieing arrays ;)
>
> Now I will let it be up to you to examine the ENTIRE OPENGL SPEC to
> find if such a function exists ! Good luck with that ! ;) :)

You would not need to search the whole GL spec for such a function.  As
you are proposing the GL should keep a copy of that array in it's server
state, you just would need to scan through the OpenGL state tables in
the spec to find it.	

But that is still besides the point. The key point is what actually *IS*
written in the spec. And it is very clear about all these issues. The
spec *requires* that the gl*Pointer functions set the client state. And
it defines that client state down to such details as the data types. 

The main point - which finally breaks the neck of your copy theory - is
the specification of the drawing functions itself. There are sentences like
"The command void ArrayElement( int i ); transfers the ith element of
every enabled array to the GL". So if an implementation had already made
a copy, it *MUST* assure that it is up to date here. The only way it
could do this would be either a) compare and update on demand or b)
update it nonetheless or c) - the only thing any sane person would do - skip
that whole early copy time waste and dereference the pointers at the
only time they can be dereferenced, if the spec's requirements are to be
met.

In my description, there is still the possibility that the GL implementation
might do that useless copy (as well as it might do a ten second sleep after
every 42th gl command). But I would go so far as to claim that
it MUST NOT dereference a vertex pointer except at those few vertex array
drawing functions. There is simply no statement in the whole GL spec allowing
it to access client memory at will; I would expect supplying a vertex pointer
lying outside of the process' address space to work, as long as I make sure
that either the drawing functions are never called or there is a big enough
buffer mapped to that address whenever they are called. 

> OpenGL's state machine is like "global variables"... a very bad
> programming style.

No, it explicitely encapsulates its state in contexts. There's just a 
thread-local current context.

> Now it's up to you to find if there is a global variable somewhere in
> that entire state which actually describes the size of the
> array ! ;) :)

This is not really hard; these state tables in the OpenGL spec are there for a
reason. And please don't pull the extensions card. No extension would break the
compatibility with the OpenGL core as long as no extension-specific state is
actively set by the client.

If there would be an extension defining a vertex array size state variable, it
would not change anything to the core features as long as no-one actually calls
glEnable(GL_WEIRD_AND_USELESS_VERTEX_ARRAYS_SKYBUCK).

>
> Bye,
>   Skybuck.

Regards,
	Marcel, last try before you'll populate my killfile.	

-- 
Marcel Heinz | <marcel.heinz@informatik.tu-chemnitz.de> | PGP-KeyID: E78E9442
 
"Perfection is attained not when there is nothing more to add,
 but when there is nothing more to remove."  -- Antoine de Saint-Exup�ry

Skybuck wrote:
> Perhaps I didn't load the function pointers correctly for the
> standard. This is were the opengl confusion is at it's best... even
> wolfgang is confused/unaware by it...
>
> The extension ofcourse need to be loaded with wglGetProcAddress.
>
> But what about "standard" functions ?!?
>
> Sometimes wglGetProcAddress seems to work for standard functions as
> well...
>
> But I have a feeling that GetProcAddress is to be used for standard
> functions which is something entirely different.
>
> If GetProcAddress is to be used than that means the routines
> prototypes/headers actually became part of the DLL...

Yes, Microsofts opengl32.dll actually exports some functions, mainly the
OpenGL 1.1 core functions + wgl. That's the whole point of a .dll.

> which is a big
> difference compared to the extensions which are being supplied via a
> special mechanisme it seems.

Only on windows, because of microsofts opengl32.dll dispatcher approach.
The real implementation sits in a ICD dll supplied by the driver vendor.

>
> Thus I now believe I should have used GetProcAddress for the standard
> functions ?!? At least for the RadeOn...

You could just link agaoinst that dll. But manually querying the function
pointers should also work, of course.

> Now the question is will this also work on nvidia ?

nVidia/ATI/whatever has nothing to do with this, as you are supposed to
use microsoft's opengl32.dll on windows. But besides of that, any OpenGL
implementation will export at least the core OpenGL functions of the
version it is implementing.

> Was the failure because I tried to load the library twice... or is
> something else strange going on...

Whatever you're doing, I get the feeling that it can't be good.

Regards,
	Marcel
-- 
Marcel Heinz | <marcel.heinz@informatik.tu-chemnitz.de> | PGP-KeyID: E78E9442
 
"Perfection is attained not when there is nothing more to add,
 but when there is nothing more to remove."  -- Antoine de Saint-Exup�ry

Hi,

Wolfgang Draxinger wrote:
> On Sat, 31 Jul 2010 10:14:34 -0700 (PDT)
> Skybuck <skybuck2000@hotmail.com> wrote:
>> My application is nice example of that, even if it's kinda
>> whacky ;) :)
>
> Fix your app to use the core vertex arrays. If that DLL you use for
> Win95 doesn't support them, well. Windows 95 is from 1995, at that time
> OpenGL 1.1 didn't exist yet. That was 15 years ago.

Well. I may be wrong, but I remeber using vertex arrays on the win95 software
renderer.

http://www.opengl.org/wiki/History_of_OpenGL claims OpenGL 1.1 was released in
1992, so my memory might even be correct... 

Regards,
	Marcel
-- 
Marcel Heinz | <marcel.heinz@informatik.tu-chemnitz.de> | PGP-KeyID: E78E9442
 
"Perfection is attained not when there is nothing more to add,
 but when there is nothing more to remove."  -- Antoine de Saint-Exup�ry

On Sat, 31 Jul 2010 18:58:39 +0000 (UTC)
Marcel Heinz <marcel.heinz@informatik.tu-chemnitz.de> wrote:

> > Fix your app to use the core vertex arrays. If that DLL you use for
> > Win95 doesn't support them, well. Windows 95 is from 1995, at that
> > time OpenGL 1.1 didn't exist yet. That was 15 years ago.

Sorry my bad. What I probably thought of was, that there haven't been
1.1 implementations for non-SGI systems. IIRC the whole thing was
opened to other vendors not until 1994.

> Well. I may be wrong, but I remeber using vertex arrays on the win95
> software renderer.

The original Windows95 had no OpenGL support. This was added later
(1996) with Windows Plus, together with the Windows NT 4 release. One
could copy the opengl32.dll of that into a Win9x system and it would
work in SW rasterizer mode, only (Plus shipped the same DLL for SW
raster only). SGI also had their own implementation of OpenGL for
Windows and for some time it was not clear, which of them would become
the standard/default; they both provided interfaces to hardware drivers,
but were incompatible, but the SGI version had the advantage, that it
could deliver HW support on Win9x systems. If you still have an original
version of Quake2 (IIRC) lying around, on the CD you'll find a small
helper program, automatically selecting the proper OpenGL version for
which hardware/drivers you had in your system.

> http://www.opengl.org/wiki/History_of_OpenGL claims OpenGL 1.1 was
> released in 1992, so my memory might even be correct... 

The 1.1 specification was released in 1992, but actual implementation
were not around on anything else than SGI for some time. IIRC the very
first non-SGI release of 1.1 was 1994 for NeXT and the first Windows
release was 1995 or 96. 1.2 was released 1998, but the first
time being usable in Windows must have been around late 1999/early
2000 (implemented by NVidia TNT). At that time I had a Permedia2 which
already supported some subset of OpenGL1.2 but not the whole thing.
Among things missing were multitexturing (and mip-mapping IIRC).


Wolfgang

On Sat, 31 Jul 2010 22:34:12 +0200
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote:

> > http://www.opengl.org/wiki/History_of_OpenGL claims OpenGL 1.1 was
> > released in 1992, so my memory might even be correct... 
> 
> The 1.1 specification was released in 1992, but actual implementation
> were not around on anything else than SGI for some time.

I dug deep into my collection of papers and specifications. What was
released in 1992 was the very first draft of the OpenGL 1.1
specification. The final version was released March 4th 1997.


Wolfgang

Ok, Mr OpenGL-knows-it-all-But-actually-knows-nothing..

You are asking for it.

I wouldn't hold that conference if I were you because you making an
ass out of yourself ! ;) :)

Anyway your challenge is simple. I'll give you two challenges for you
to ponder on:

1. Radeon 9000 challenge: Make an application which uses vertex arrays
and renders a triangle.

(Full compiled/testable source code required for verification/
examination)

2. Windows 95 challenge: Maken an application which uses vertex arrays
and renders a triangle.

Shouldn't be too hard for ya ? Should it ?! LOL.

And here's the catch/conditions/rules for the challenge:

You must create your own little small opengl api unit/code which loads
the library manually, frees the library manually, and loads all
necessary functions manually.
(So no usage of pre-made opengl units/source code allowed, prototypes
may be copied, constants may be copied, but initialization code must
be written by yourself. ).

Bye,
  Skybuck.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.07.31.16.00.24.703000@nowhere.com...
> On Sat, 31 Jul 2010 13:40:33 +0200, Skybuck Flying wrote:
>
>> Hmmm... I sent an e-mail to myself to acquire the radeon 9000 
>> extensions...
>> I am examining it now... and strangely enough vertex array extension does
>> seem present
>
> Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. You
> don't need to use an extension.

Did you deduct that from the version string? ;)

Bye,
  Skybuck :) 

Ok, Mr Prime-Example-of-Dunning-Kruger,

that weren't even 2 hours, which I mostly spent writing boilerplate...
boring, now plus 10 minutes uploading it to my server and writing this
shit here.

On Sat, 31 Jul 2010 17:05:01 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> 1. Radeon 9000 challenge: Make an application which uses vertex arrays
> and renders a triangle.

I didn't yet test on a Radeon, cause I didn't yet bother to reboot my
my machine. Short question, which exact Radeon series to you mean? Some
of the old Radeon9x00?

Unfortunately my Radeon 9800 is broken (corrupt video RAM), but it
should be still good for test if the thing fires up properly (should
do, because it's the same DLL everywhere, except maybe your Win95
version), just need a machine with an AGP slot, should have one of
those still around somewhere.

> (Full compiled/testable source code required for verification/
> examination)

Here you go, it has no dependency on any OpenGL include files or linker
libraries. Everything loaded at runtime. And as you can see by the
__my_ prefix I could not even trick the linker (and there are no C
preprocessor tricks to backreplace __my_ with empty strings)

http://dl.wolfgang-draxinger.net/skybuck_challenge/001.cpp

Like I told you already, Vertex Arrays are core part of OpenGL1.1 thus
it's not an extension and thus part of the opengl32.dll core, therefor
must be loaded using ordinary GetProcAddress. wglGetProcAddres is for
extensions, but some implementations may choose to expose core
functions also through wglGetProcAddress. I already told you that.

Didn't bother to clean the boilerplate VisualStudio created into a
plain ANSI C file, so compile with a C++ compiler. I made this using
Visual Studio 2005, File->New->Project => Win32, Win32-Project.
In the created project replace the project's main cpp file with mine,
and switch off precompiled headers otherwise the compiler will complain
(or add a #include "stdafx.h" at the beginning of my source code)

> 2. Windows 95 challenge: Maken an application which uses vertex arrays
> and renders a triangle.

Didn't I say, that I won't write for Win95? How the heck am I supposed
to test the whole thing, if I don't even have a Win95 CD lying around
to install (well, maybe I still got one on the attic) it in a VM?

> And here's the catch/conditions/rules for the challenge:
> 
> You must create your own little small opengl api unit/code which loads
> the library manually, frees the library manually, and loads all
> necessary functions manually.
> (So no usage of pre-made opengl units/source code allowed, prototypes
> may be copied, constants may be copied, but initialization code must
> be written by yourself. ).

*yawn* Was that all?


Wolfgang

I am close to getting it working myself.

I have developed a new opengl api unit/library/package from scratch in
just the few last hours... ofcourse I did copy and paste and modify
some code from another unit/library.

My own opengl api library now at least supports opengl 1.0 and opengl
1.1... now glu functions yet though... I probably won't be needing
those.

I also decided to stay away from TWinControl/TCustomControl/
TOpenGL(control) since I believe those could be buggy.

So instead used my own TWindow class for now... later I might still
try TCustomControl a try/chance to try and integrate my own code with
the Delphi VCL so that it gets all the extra's like splitter support
and what not... but before I do that it would be wise to first try out
TGraphicControl inheritance and simply try to embed my own window
class directly into the underlieing windows/framework/windows as child
window and not support vcl framework... to at least have some reliable
window to draw on and see/check if it all works ok...

So far everything working... all return codes return success that
includes cleaning up.

glVertexPointer is supported on windows 95... I won't tell you how
just yet because you seemed confused... first I wanna see if you can
do it... I see you posted a new posting (with link to cpp file...) I
will check it out after this posting ! ;) :)

The only thing which is not working yet which is kinda funny is
palette support... fortunately windows 95 is apperently smart enough
to detect it and do something about it... Originally I set background
to green and triangle to red... windows makes it black background and
white triangle... so at least I saw that it was working.

Only thing left to do now is implement palette support... but I am
already pretty happy that it's working at least on windows 95... which
is a very good sign... and ofcourse my own dream pc...

Soon I will test it out on RadeOn 9000.

Anyway if inheritance is the way to go I am not sure yet... it's kinda
strange and could get a bit nasty with all the extensions... but I
guess I could implement one extension layer somewhere maybe even
multiple... but hundreds would be weird... so just one extension layer
where all extensions are attempted to be loaded or so... and then some
booleans will be set...

However performing object inheritance on opengl was kinda nice... it
nicely seperates the versions...

The drawback is it becomes a little bit harder to view all routines at
once... since they now fragmented over multiple units... but that's
kinda what I wanted...

The one big unit was kinda driving me nuts... hard to scroll by... and
quickly find the code I want...

The fragmented approach has slight initialization overhead because of
multiple initialize routines.. but that's mostly acceptable... since
that just has to occur once.

So bottom line is: If you want something done right, do it
yourself ! ;) :)

> I didn't yet test on a Radeon, cause I didn't yet bother to reboot my
> my machine. Short question, which exact Radeon series to you mean? Some
> of the old Radeon9x00?

9000000000000000000000000000000000000 ! LOL.

What part of 000 did you not understand LOL ?! ;) :):):):):):):):)


> Unfortunately my Radeon 9800 is broken (corrupt video RAM), but it
> should be still good for test if the thing fires up properly (should
> do, because it's the same DLL everywhere, except maybe your Win95
> version), just need a machine with an AGP slot, should have one of
> those still around somewhere.

Excuses excuses excuses.

> http://dl.wolfgang-draxinger.net/skybuck_challenge/001.cpp

Didn't even bother to check it yet because of your comments below...
apperently
you did learn something from me !

About time FOOL ! ;) =D

> Like I told you already, Vertex Arrays are core part of OpenGL1.1 thus
> it's not an extension and thus part of the opengl32.dll core, therefor
> must be loaded using ordinary GetProcAddress. wglGetProcAddres is for

AH ! Did you finally get it ?! Usually GetProcAddress only works if
routines were added
to the opengl dll ! Yet you did mention some silly IDC/L or whatever
trick to patch up the GetProcAddress...

If that's true remains to be seen.

And many people in this thread said that wglGetProcAddress was
necessary... well they were false/incorrect weren't they ! ;) :)

> extensions, but some implementations may choose to expose core
> functions also through wglGetProcAddress. I already told you that.

Why ?! It's stupid. I'll check later your comments one more time... it
sure is stupid.

> Didn't bother to clean the boilerplate VisualStudio created into a
> plain ANSI C file, so compile with a C++ compiler. I made this using
> Visual Studio 2005, File->New->Project => Win32, Win32-Project.
> In the created project replace the project's main cpp file with mine,
> and switch off precompiled headers otherwise the compiler will complain
> (or add a #include "stdafx.h" at the beginning of my source code)
>
> > 2. Windows 95 challenge: Maken an application which uses vertex arrays
> > and renders a triangle.
>
> Didn't I say, that I won't write for Win95? How the heck am I supposed
> to test the whole thing, if I don't even have a Win95 CD lying around
> to install (well, maybe I still got one on the attic) it in a VM?

LOL, amateur ! ;) :)

> > And here's the catch/conditions/rules for the challenge:
>
> > You must create your own little small opengl api unit/code which loads
> > the library manually, frees the library manually, and loads all
> > necessary functions manually.
> > (So no usage of pre-made opengl units/source code allowed, prototypes
> > may be copied, constants may be copied, but initialization code must
> > be written by yourself. ).
>
> *yawn* Was that all?

Bleh ! ;) :P*

Now I go check out your code and it better work ! ;) :)

Otherwise you going down into the BUCKET OF HELLSHIT ! ;) :)

Bye,
  Skybuck =D

> http://dl.wolfgang-draxinger.net/skybuck_challenge/001.cpp

What's this code doing in your code:

BOOL load_OpenGL_extensions(void)
{
	if( !__my_wglGetProcAddress ||
		!__my_wglGetCurrentContext())
		return FALSE;

#define __MY_GL_LOAD(x) ( (__my_##x =
(__proc_my_##x)__my_wglGetProcAddress(#x)) || (MessageBox(NULL,
_T("Function not retrieveable by wglGetProcAddress, not a core
function! \n" ) _T(#x), _T("Missing Extension Function"), MB_OK |
MB_ICONERROR),0) )
	if(
		0
		)
		return FALSE;
#undef __MY_GL_LOAD

	return TRUE;
}


Seems like you got confused again ?! ;) :)

And what an ugly code it is ! Dirty macro's ! Behehehe you not a C
programmer... you a MACRO programmer ! LOL. The lowest of the lowest,
the least skilled of the skilled ;) :) You better of writing Microsoft
Word MACRO'S ! HAHAHAHA LOL.

Anyway your Visual Studio 2005 program is a BIG FAIL ! It doesn't run
on Windows 95 ! LOL.

You get yourself a nice machine emulator... and install windows 95 !
And try to fix your program ! and then we'll talk again ! After you
got rid of/over your extension/wglGetProcAddress confusion ! LOL.

I can own your *ss on windows 95 any day and any flavor of the week !
LOLOLOLOLOLOLOLOLOL.

I did find this thread slightly motivating... I shall unban fungus and
you for now...

Bye,
  Skybuck ;)  :)

Your first build failed with some missing DLL on windows 95 (I added
the include stdaff crap etc).

To be fair to you I decided to give it one more try, and simply see if
it would build without the stdafx crap... and yes it does build and
yes it does run on windows xp...

But again not on windows 95:

This time it says:

"a device attaching to the system is not functioning" in one dialog
message.

And in another it says:

"linked to missing export KERNEL32.DLL:IsDebuggerPresent."

And this was a release executable ?! behehehehehehe.

Now you know what you can do with your Visual Studio 2005 !!!!!

You can shove it straight up your ass where it belongs !
>;)> ;)> ;)> :)  >>>> =DDDDDDD >>>:PPPPPP***

YEAHAHAHAHAHAHAHAHAHAHAHAH

IT'S HORSE/WOLFGANG-SHIT LOL.

Bye,
  Skybuck.

On Sun, 1 Aug 2010 01:52:58 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> Your first build failed with some missing DLL on windows 95 (I added
> the include stdaff crap etc).
> 
> To be fair to you I decided to give it one more try, and simply see if
> it would build without the stdafx crap... and yes it does build and
> yes it does run on windows xp...

I told you explicitly to disable precompiled headers, otherway funny
things would happen. Geez, please for one time in your life, read what
people write.

> "a device attaching to the system is not functioning" in one dialog
> message.

It's not my problem if your machine is borked.

> "linked to missing export KERNEL32.DLL:IsDebuggerPresent."

Since all I gave you was a source code file, not an executable or a
whole projects, and I told you, what to enable/disable this was clearly
your fault.


Wolfgang

On Sun, 1 Aug 2010 01:38:14 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> > http://dl.wolfgang-draxinger.net/skybuck_challenge/001.cpp
> 
> What's this code doing in your code:

Saving me some boring writing work - computers are there for doing the
boring and repetetive tasks for us.

> BOOL load_OpenGL_extensions(void)
> {
> 	if( !__my_wglGetProcAddress ||
> 		!__my_wglGetCurrentContext())
> 		return FALSE;
> 
> #define __MY_GL_LOAD(x) ( (__my_##x =
> (__proc_my_##x)__my_wglGetProcAddress(#x)) || (MessageBox(NULL,
> _T("Function not retrieveable by wglGetProcAddress, not a core
> function! \n" ) _T(#x), _T("Missing Extension Function"), MB_OK |
> MB_ICONERROR),0) )
> 	if(
> 		0
> 		)
> 		return FALSE;
> #undef __MY_GL_LOAD
> 
> 	return TRUE;
> }
> 
> 
> Seems like you got confused again ?! ;) :)

Confusion doesn't write you macros, lets you use boolean operator
execution order to display a error information in case of fail and
still have the outer if clause evalute true for "not true" by clever
use of the C comma operator.

Especially not at 03:33AM and being slightly loaded.

> And what an ugly code it is !

That's debateable. Did you expand the macros and compare (gcc command
line switch -E)?

> Dirty macro's ! Behehehe you not a C programmer... you a MACRO programmer !

The C preprocessor is an integral part of the C standard. Using it
means using C. Anyway, being the great programmer you claim to be, how
would have you done it: Write a non-macro function in a statically
compiled, statically typed language, that populates an identifer with a
corresponsing value retrieved by string, both string and identifier
being deduced from the very same argument. (I explicitly exclude
scripting languages from the list, as you can do it there with either
eval or duck typing).

> LOL. The lowest of the lowest,
> the least skilled of the skilled ;) :) You better of writing Microsoft
> Word MACRO'S ! HAHAHAHA LOL.

Macros are there to be used. If you know what you're doing one shall
use them. Did you even bother to expand one of them in your head? I'll
do for you with glClear:

__MY_LOAD_GL(glClear) in the first variant expands to

((__my_glClear = (__proc_my_glClear)GetProcAddress(hOpenGLDLL,
"glClear")) || (MessageBox(NULL, _T("Function not found in DLL, not an
extension! \n" "glClear"), _T("Missing Core Function"), MB_OK |
MB_ICONERROR),0 ) )

Now imagine how ugly that code would have become, if I had written this
for every function to load. Of course I also could have written a small
script to generate that code for me externally, but, unh, that's
exactly what macros are for.

> Anyway your Visual Studio 2005 program is a BIG FAIL ! It doesn't run
> on Windows 95 ! LOL.

I clearly stated from the very beginning, that I will not code for
Windows 95. I don't have it, and I don't support it. WTH should I, it
died sometime back around 2001, when hopefully every Windows user
switched to WinXP. And if you run some critical equipment, which must
not be changed on Win95 you can't be helped anyway, should be instantly
delivered to an asylum where you get nice drugs for the rest of your
life.

> You get yourself a nice machine emulator... and install windows 95 !

If that Win95 CD crosses my way I shall do, but I won't go for a hunt of
it now.

> I did find this thread slightly motivating...

I consider it actively education at most, although the people educated
are those, who stay passive and just read this shit. I bet they're
through their 5th large bin of popcorn right now; sorry guys for
dragging it along, where shall I send the replenishments?

> I shall unban fungus and you for now...

Speaking about people: I'm wondering how the person's like, I'm dealing
with here. I have a coarse idea, but I may be utterly wrong:
- Gender: Male
- Education Status: High School, maybe some college.
- Employment Status: unemployed, probably applied for some jobs at
  some IT companies, failed the tests, rationalized into "they're too
  stupid anyway."
- Age: Between 14 and 20 years old

In true "Quid pro Quo" fashion I shall honestly tell my profile, if
you honestly tell yours (be warned I can smell liars even over IP).
That's among one reason, why I post with my real name: People can use
Google on it and that way make themself a less biased picture of me.

I did that on your pseudonym, and, well, it doesn't look good. So far
you managed to piss of every newsgroup and forum you bumped into,
insulted the mostly skilled people there and told some guys they
wouldn't understand some standard, while it were exactly those guys who
wrote or collaborated on that particular standard.


Wolfgang

On Sat, 31 Jul 2010 10:05:12 -0700, Skybuck wrote:

>> > Hmmm... I sent an e-mail to myself to acquire the radeon 9000 extensions...
>> > I am examining it now... and strangely enough vertex array extension does
>> > seem present
>>
>> Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. You
>> don't need to use an extension.
> 
> So are you saying that glVertexPointer is part of the OpenGL 1.3
> standard ?

glVertexPointer() is part of OpenGL 1.1 and later.

> What does it mean when a routine becomes part of the standard ?

It means that it's available in any implementation of that version.
There's no need to query for availability.

On Sat, 31 Jul 2010 18:58:39 +0000, Marcel Heinz wrote:

>> Fix your app to use the core vertex arrays. If that DLL you use for
>> Win95 doesn't support them, well. Windows 95 is from 1995, at that time
>> OpenGL 1.1 didn't exist yet. That was 15 years ago.
> 
> Well. I may be wrong, but I remeber using vertex arrays on the win95 software
> renderer.

Win95 didn't have any version of OpenGL until the OSR2 release.

OpenGL 1.0 didn't even have glBindTexture(), so it never really got much
traction. OpenGL 1.1 was the first version which anyone other than SGI
really bothered with.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.08.01.11.44.01.797000@nowhere.com...
> On Sat, 31 Jul 2010 10:05:12 -0700, Skybuck wrote:
>
>>> > Hmmm... I sent an e-mail to myself to acquire the radeon 9000 
>>> > extensions...
>>> > I am examining it now... and strangely enough vertex array extension 
>>> > does
>>> > seem present
>>>
>>> Radeon 9000 supports OpenGL 1.3, which includes glVertexPointer() etc. 
>>> You
>>> don't need to use an extension.
>>
>> So are you saying that glVertexPointer is part of the OpenGL 1.3
>> standard ?
>
> glVertexPointer() is part of OpenGL 1.1 and later.
>
>> What does it mean when a routine becomes part of the standard ?
>
> It means that it's available in any implementation of that version.
> There's no need to query for availability.

That's assuming static linking, at I think that's what you mean ;) :)

Static linking is a bit dangerous... if the opengl32.dll is missing or 
damage the whole app stops...

Dynamic linking is thus better... and can be recovered from...

It does require using either window's GetProcAddress or opengl's 
wglGetProcAddress...

And when something is standardized I would assume it becomes part of the DLL 
*somehow* and can be queried/acquired via GetProcAddress...

Though some say maybe wglGetProcAddress still required for some stuff for 
some drivers... time will tell ;) :)

But the coming days I am going to play Starcraft 2 me thinks ! ;) :)

So don't count on any updates soon ! ;) =D

Bye,
  Skybuck =D =D =D =D ;) :)

(Hmm does it use opengl or direct x? probably dx me thinks ;) ?! ;) :) 

(Though I didn't see starcraft 2 install any dx distributables... so maybe 
it's opengl based... who knows...
well me too tired now.. gonna hit the sack... :) goooodbye :))

May the sun light your path :)

Bye,
  Skybuck ;) =D 

On Sun, 1 Aug 2010 01:52:58 -0700 (PDT)
Skybuck <skybuck2000@hotmail.com> wrote:

> Now you know what you can do with your Visual Studio 2005 !!!!!

On a side note. If you read the specs of Visual Studio 2005, all
Windows versions not based on the NT kernel (Windows 95, Windows 98,
Windows ME) are not supported explicitly.

So if you want to use it on Windows 9x/ME you need Visual Studio 6 or
earlier. Guess what: I actually found that Win95 CD. Today I have
to finish some slides for a talk on interferometry, but tomorrow
evening I shall even bother to make it work on Win95. And I'm sure to
about 80% that the one code I already posted will even work without
changes on Win95, if compiled with VisualC++ 5.

However I will not publish some executable file, because if you
executed it on your computer and something broke you'd probably blame
me. No sir, I'm not gonna do you that favour.


Wolfgang

On Sun, 1 Aug 2010 18:47:56 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> That's assuming static linking, at I think that's what you mean ;) :)

Static linking means, the code of the library is included in your app's
executable. Thus it gets completely independent of any library. However
you can't static link opengl32.dll

> Static linking is a bit dangerous... if the opengl32.dll is missing
> or damage the whole app stops...
> 
> Dynamic linking is thus better... and can be recovered from...

If DLL X is a dependency of your app, and it's missing, it doesn't
make a big difference on the outcome. Loading it manually by
LoadLibrary + GetProcAddress had the disadvantage, that the library
missing is not detected until you try to load it. Which can be a very
long time after the program has been started and may even have done
some expensive initialization. Dynamically linking it by the operating
system's executable loader using the import table has the big
advantage, that the program's entry function isn't even called if not
all prerequisites are met.

If the DLL is damaged, well, then you're fucked either way.

> It does require using either window's GetProcAddress or opengl's 
> wglGetProcAddress...

Which is not a problem if you know which you have to use on what.

> And when something is standardized I would assume it becomes part of
> the DLL *somehow* and can be queried/acquired via GetProcAddress...

It wont. Since Microsoft left the ARB it's extremely unlikely, that any
further features will be included into opengl32.dll.

> Though some say maybe wglGetProcAddress still required for some stuff
> for some drivers... time will tell ;) :)

Newer features are to be accessed through wglGetProcAddress. Get over
it.

> But the coming days I am going to play Starcraft 2 me thinks ! ;) :)
> 
> So don't count on any updates soon ! ;) =D

I'm crossing my fingers that it may be this way.
 
> (Hmm does it use opengl or direct x? probably dx me
> thinks ;) ?! ;) :) 

Who cares, most games that come out today use OpenGL, because that's
the 3D graphics API of
* Sony PlayStation2
* Sony PlayStation3
* Nintendo Wii
* Nintendo DS
* iPhone and iPad
* Android
* Symbian

Summed up those comprise a far bigger market than Windows + XBox.


Wolfgang

Wolfgang Draxinger wrote:

> On Sun, 1 Aug 2010 18:47:56 +0200
> "Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:
> 
> > That's assuming static linking, at I think that's what you mean ;)
> > :)
> 
> Static linking means, the code of the library is included in your
> app's executable. Thus it gets completely independent of any library.
> However you can't static link opengl32.dll

There is another definition of static linking (compared to dynamic
linking). Static linking, in that context, is when you specifiy the
functions to be imported from a DLL at design time, instead of at
runtime. IOW, this kind of import:

  procedure Bla(<params>); external 'somedll.dll' name 'Bla';

is often referred to as static linking, while dynamic linking is what
you do when you use LoadLibrary() or LoadLibraryEx() and
GetProcAddress() for each of the functions you want to load.

Note that Delphi does not have .lib files, so your kind of static
linking does not exist in Delphi. There is something similar though, in
that units are compiled into the executable by default, but you can
also use them from an external package (.bpl file). No one calls that
static linking, in this context, though.
-- 
Rudy Velthuis        http://rvelthuis.de

"Common sense is the collection of prejudices acquired by age 
 eighteen." -- Albert Einstein

On Sun, 01 Aug 2010 19:55:30 +0200, Rudy Velthuis wrote:

>> > That's assuming static linking, at I think that's what you mean ;)
>> > :)
>> 
>> Static linking means, the code of the library is included in your
>> app's executable. Thus it gets completely independent of any library.
>> However you can't static link opengl32.dll
> 
> There is another definition of static linking (compared to dynamic
> linking). Static linking, in that context, is when you specifiy the
> functions to be imported from a DLL at design time, instead of at
> runtime.

IMHO, that's a "misuse" rather than an alternate definition.

It's preferable to talk about "linking" versus "run-time loading" if
you're dealing with the possibility of GetProcAddress(), dlopen(), etc.

Or "build-time linking" if you really need to prevent misunderstandings.

Nobody wrote:

> > There is another definition of static linking (compared to dynamic
> > linking). Static linking, in that context, is when you specifiy the
> > functions to be imported from a DLL at design time, instead of at
> > runtime.
> 
> IMHO, that's a "misuse" rather than an alternate definition.

No, it isn't. It simply depends on your context. Fact is that "static
linking" means different things to different persons.
-- 
Rudy Velthuis        http://rvelthuis.de

"You know your god is man-made when he hates all the same
 people you do."
 -- [Usenet]

Hi,

Nobody wrote:
> On Sat, 31 Jul 2010 18:58:39 +0000, Marcel Heinz wrote:
>
>>> Fix your app to use the core vertex arrays. If that DLL you use for
>>> Win95 doesn't support them, well. Windows 95 is from 1995, at that time
>>> OpenGL 1.1 didn't exist yet. That was 15 years ago.
>> 
>> Well. I may be wrong, but I remeber using vertex arrays on the win95 software
>> renderer.
>
> Win95 didn't have any version of OpenGL until the OSR2 release.

Yeah, this could be. http://support.microsoft.com/kb/154877/en is
supporting that possibility. But to be true, I simply can't remeber the
details. I switched to linux in 1998 and try hard to forget the dark
ages of using DOS / WfW3.11 / Win95...

Regards,
	Marcel
-- 
Marcel Heinz | <marcel.heinz@informatik.tu-chemnitz.de> | PGP-KeyID: E78E9442
 
"Perfection is attained not when there is nothing more to add,
 but when there is nothing more to remove."  -- Antoine de Saint-Exup�ry

Am Sun, 1 Aug 2010 01:16:07 -0700 (PDT)
schrieb Skybuck <skybuck2000@hotmail.com>:

> What part of 000 did you not understand LOL ?! ;) :):):):):):):):)

Due to your inability to be specific I just asked for clarifications.
Just FYI, Radon 9000 is both the name of a certain product, but also
the whole product line originating from that.

And about my broken 9800: Well sorry I upgraded to PCI-Express 4 years
ago and thus never had any need to use that old thing ever again. It
spent the rest of its life in a media center, and after it died a
GeForce6600 followed its steps (we'll see how long that one lasts,
after that I got a GeForce6800 to fill the gap).

> AH ! Did you finally get it ?! Usually GetProcAddress only works if
> routines were added to the opengl dll!

GetProcAddress is not some magic bullet to get access to functions,
that were "added" to a DLL. It's just another way to do a task, that's
otherwise done by the operating system for you. Furthermore it doesn't
make additional functions appear in DLLs. GetProcAddress can only give
you, what has been written to DLLs export table upon creation of the
DLL. I treat you to a small experiment: Find an old installation of
Windows NT 4. Find and copy the opengl32.dll of that one (you are now
certain, that this is a way old DLL, never being updated). Now copy
this one to your fully patched and updated Windows XP (32 Bit version,
64 Bits is incompatible obviously) with the most recent drivers for your
brand new top of the shelf GPU (I don't know if this works with Windows
Vista or 7, never tried it out) overwriting the opengl32.dll of that
one (also make sure you purge the driver and the DLL cache, and
protected file restauration may get in the way, too, but all this can
be overcome). Now start a really demanding OpenGL program. One that
exhausts all the capabilites, requires all extensions. It will work.
Why? Because opengl32.dll never changed during all those years.

> Yet you did mention some silly IDC/L or whatever trick to patch up
> the GetProcAddress...

IDC is the acronym for "Installable Client Driver", i.e. the proper term
for what's commonly known simply as "OpenGL driver". What we're talking
about here, are so called (syscall) trampolines:
http://en.wikipedia.org/wiki/Trampoline_(computers)
But why do I even bother trying to explain you concepts of advanced
system programming.

In this context, talking about DLLs and such, may I give you another
treat: In your opinion, by your (as you claim superior) knowledge would
you say it is possible to load and use a DLL as you would do using
LoadLibrary, FreeLibrary and GetProcAddress, but without any operating
system function other then reading a file's contents, allocating memory
and setting memory locking parameters. I.e you may use only the
following functions of the Windows API:

CreateFile
ReadFile
VirtualAlloc
VirtualLock
VirtualProtect

Your opinion, if it is possible using only (and really only) that.

After you answered this question I'll tell you the URL which has
this SHA1 hash f7a6eb3bb3ef72bf3b44ee1bc1a5f60564b839e2
I hope you'll find the reading there enlighting.

> If that's true remains to be seen.
> 
> And many people in this thread said that wglGetProcAddress was
> necessary... well they were false/incorrect weren't they ! ;) :)

They weren't. They told you exactly the differences between which and
when to use what. You use GetProcAddress for everything that
opengl32.dll exports: Namely this are the functions as specified by
OpenGL 1.1 (among them also the stuff for Vertex Arrays). Anything that
goes beyond OpenGL 1.1 is not, and never will be part of opengl32.dll.
All this stuff is provided by the driver. And wglGetProcAddress is the
way to get access to those driver specific functions, which are and
never will be part of opengl32.dll.

On the question why it's not included in opengl32.dll. Well, you have
to ask Microsoft why they refuse to do so. It's not the fault of
OpenGL. On other operating systems, OpenGL core functionality also is
exported directly. But most programs use glxGetProcAddress. The main
reason is, that this gives you consistent code paths on all platforms.

> LOL, amateur ! ;) :)

Why? Because I threw that junk where it belongs, the trashcan?

> Now I go check out your code and it better work ! ;) :)

Speaking of code:

I've never seen you posting some fully functional piece of your code
anywhere. Care to share?


Wolfgang

> Who cares, most games that come out today use OpenGL, because that's
> the 3D graphics API of
> * Sony PlayStation2
> * Sony PlayStation3
> * Nintendo Wii
> * Nintendo DS
> * iPhone and iPad
> * Android
> * Symbian
>
> Summed up those comprise a far bigger market than Windows + XBox.
>
> Wolfgang

Yeah well, let's get back on topic shall we...

Show me some application on windows, which actually use opengl,
multiple windows, one thread, and work bugfree.

I remain unconvinced that opengl is the choice for applications.

Bye,
  Skybuck.

In article <0fd8c4b6-2a2a-4326-b47a-0600748f9f72
@q22g2000yqm.googlegroups.com>, skybuck2000@hotmail.com says...

....

> Yeah well, let's get back on topic shall we...
> 
> Show me some application on windows, which actually use opengl,
> multiple windows, one thread, and work bugfree.
> 
> I remain unconvinced that opengl is the choice for applications.

Google sketchup uses openGL.  I don't know about the multiple windows 
single-thread issues, though.

Am Wed, 4 Aug 2010 06:33:52 -0700 (PDT)
schrieb Skybuck <skybuck2000@hotmail.com>:

> Show me some application on windows, which actually use opengl,
> multiple windows, one thread, and work bugfree.

Blender 2.5

--=20
CIP-Rechnerbetriebsgruppe
Fakult=C3=A4t f=C3=BCr Physik - LMU M=C3=BCnchen
Schellingstrasse 4, 80799 M=C3=BCnchen

> Speaking of code:
>
> I've never seen you posting some fully functional piece of your code
> anywhere. Care toshare?

Do you have a Delphi compiler or Free Pascal handy ?

If not I would be wasting my time mostly, unless you install it into
the far future... :)

Bye,
  Skybuck ;) =D