DGL
https://delphigl.com/forum/

OpenGL 1.5-Header
https://delphigl.com/forum/viewtopic.php?f=19&t=2207		 Seite 1 von 2
Autor:  Sascha Willems [ Mi Nov 19, 2003 11:51 ]
Betreff des Beitrags:  OpenGL 1.5-Header
This is the support-thread for our official OpenGL1.5-Header for Delphi, that supports all extensions up to the new ones that come with v1.5 of the OpenGL.

Since many people use Mike Lischke's OpenGL12.pas, we designed our unit so that a transition from Lischke's to our unit will be easy (as we also have the same types and helper functions). But please also read the contained "How to use.txt" where you can read how to use the unit.

So if you have any problems, concerns or feedback about this unit, don't hesitate to speak it out in this thread!

The newest version of the header can always be grabbed here.
Autor:  Gast [ Do Nov 20, 2003 08:13 ]
Betreff des Beitrags: 
Apparently it was based on an old version of OpenGL12.pas without the fixes, which means some errors are still in, like the 1.2 core functions (f.i. glDrawRangeElements) being loaded via a GetProcAddress instead of the correct wglGetProcAddress (all functions beyond 1.1 must be bound via the extension mechanism, the MS DLL is stuck at 1.1 and as such does not expose these functions directly).

Eric / [url]GLScene.org[/url]
Autor:  Mars [ Do Nov 20, 2003 10:34 ]
Betreff des Beitrags: 
dglOpenGL loads all OpenGL functions (1.1 core, higher versions, extensions) via the following code:

Code:
  1. function glProcedure(ProcName : PChar) : Pointer;
  2. begin
  3. Result := NIL;
  4. if Addr(wglGetProcAddress) <> NIL then
  5.  Result := wglGetProcAddress(ProcName);
  6. if result <> NIL then
  7.  exit;
  8. Result := GetProcAddress(LibHandle, ProcName);
  9. end;
  10.  


this means that GetProcAddress is only used, if either wglGetProcAddress or the returned adress is NIL - it's just a fallback option, if all other alternatives fail.
Maybe you got an old version of the library?
Autor:  Sascha Willems [ Do Nov 20, 2003 10:51 ]
Betreff des Beitrags: 
Yes, Mars is right, GetProcAddress is only used if wglGetProcAddress won't give a valid address to the procedure. The only procedures getting loaded via GetProcAddress are the glu-ones and that shouldn't make any problems.

And moreover our unit has been made from scratch and isn't based on another Delphi-OpenGL-Unit. The only thing it has in common with OpenGL12.pas are some varnames and some names for helperfunctions to make a transition from Mike Lischke's to our unit easier.

So this is a totally new unit made from scratch that has been in testing for some monts now. But if you encounter any problems, please let us know and we'll look into it.
Autor:  Gast [ Do Nov 20, 2003 16:21 ]
Betreff des Beitrags: 
Hadn't spotted the wrapping, but the wrapping isn't helping when it happens, so the result is the same :wink:

The functions are bound in InitOpenGL, which happens while no context is active, meaning that the wglGetProc will operate on functions know to the default context only, aka MS' OpenGL32.dll which is OpenGL 1.1.
To be active, these functions must be bound with an active context (just like extensions, because that's what they are wrt to the MS DLL), and they must also be rebinded each time the pixelformat/driver changes (f.i. if you render your OpenGL to a printer or bitmap context in the app).
Try using a glDrawRangeElements, it will be nil (even if supported by the driver), same goes for the non-ARB bindings of the MultiTexture functions,
and all non-1.1 functions bound in InitOpenGL. Bind these along with extensions, and they won't be nil.

Also, if this is hidden here by the fact standard functions are bound in InitOpenGL (with no context active, and thus bound to OpenGL32.dll directly), it can be dangerous to use wglGetProc to retrieve the standard OpenGL functions and not rebind them at each context change: wglGetProc can return pointers to the actual OpenGL DLL (nvoglnt.dll for nVidia f.i.), that may not be valid for rendering to another pixelformat.

With all that is before, I'm sure you guessed that ActivateRenderingContext is incorrect in that it binds extensions and reads implementation properties only once, though it should do it each time the pixelformat changed (i.e. each time the actual opengl driver potentially changed). This becomes an incentive to trim the fat of obsolete/unused/hyperspecific extension support, since binding many functions isn't particularly fast (esp. if you have to do it many times per second). :wink:

Eric
Autor:  Sascha Willems [ Do Nov 20, 2003 16:31 ]
Betreff des Beitrags: 
First thx for you feedback and please excuse if I missed something in your post. But the glMutliTexture-functions (without ARB) and even glDrawRangeElements are working in the newest release of our header, as they get loaded via wglGetProcAddress after a valid rendercontext has been made current :

Code:
  1. wglMakeCurrent(DC, RC);
  2. if not ExtensionsRead then
  3.  ReadExtensions;
  4. if not ImplementationRead then
  5.  ReadImplementationProperties;

And I've also assured that all supported functions/extensions have valid funtionspointers, as there was a problem with it in the old version of our header.

And on the incorrect ActiveRenderingContext : Yes, I'm aware that it isn't the best way how it's done now, and that the extensions need to be reloaded after changing the DC/PFD. But those functions are only quick implementations to help in the transition from Mike Lischke's header to ours, so they'll change in future realeases. But for now I didn't want just to copy his functions ;)

But nonetheless thanks for your input and btw. is Mike still working on his headers? (If my brain servers right, you're working with him on glScene, aren't you?)
Autor:  Gast [ Do Nov 20, 2003 17:51 ]
Betreff des Beitrags: 
hmm... I'm not sure where your latest version is, I just followed the link (files are dated 19/11 in the zip... current enough?), and the binding bug is still in.
Take f.i. glDrawRangeElements, it is bound only in InitOpenGL, not in ReadExtensions, and ReadExtensions does not invoke InitOpenGL, so its values remains at what InitOpenGL assigned it, ie. nil (you can try it in a small proggy).

> is Mike still working on his headers?

Not for a long time...

> you're working with him on glScene, aren't you?

More like taken over, haven't seen Mike in the OpenGL... scene :roll: for a long long time. The OpenGL12 unit has been renamed in GLScene, and I've changed the focus & spirit a bit: OpenGL1.1 funcs are statically bound, the rest is dynamically bound, obsolete/useless extensions are getting culled out... helps reduce the bloat and increase performance.
Autor:  Sascha Willems [ Do Nov 20, 2003 18:03 ]
Betreff des Beitrags: 
Anonymous hat geschrieben:
hmm... I'm not sure where your latest version is, I just followed the link (files are dated 19/11 in the zip... current enough?), and the binding bug is still in.
Take f.i. glDrawRangeElements, it is bound only in InitOpenGL, not in ReadExtensions, and ReadExtensions does not invoke InitOpenGL, so its values remains at what InitOpenGL assigned it, ie. nil (you can try it in a small proggy).


That's very suspicious, since I just used my GL15-Template and checked (after calling InitOpenGL and after creating and activating the RC) if glDrawRangeElements is assigned, and it was.
Code:
  1. InitOpenGL;
  2. DC := GetDC(Handle);
  3. Doublebuffering)
  4. RC := CreateRenderingContext(DC, [opDoubleBuffered], 32, 24, 0, 0, 0, 0);
  5. ActivateRenderingContext(DC, RC);
  6. ...
  7. if Addr(glDrawRangeElements) = nil then
  8.  halt(0);


The program won't halt, so glDrawRangeElements must be assigned, same for glMultiTexCoord*f (without ARB). But perhaps there are some differneces between NVidia and ATI (I'm developing on a Radeon9700) and all members of the GL-Portteam also use ATI. So thanks for that input, I'm gonna check it out on my second PC that has a GeForce4 in it.
Autor:  Gast [ Do Nov 20, 2003 18:36 ]
Betreff des Beitrags: 
:oops: there was actually a messup in the file downloads, the .pas somehow got write-protected and the unzipper didn't complained about not being able to overwrite... Not nil now. :)

PS: it loads the DLLs multiple times but doesn't "FreeLibrary" for each "LoadLibrary"... and the N+1th times, it doesn't honour library names (reverts to default).
Autor:  Michael Brooks [ So Aug 08, 2004 00:54 ]
Betreff des Beitrags:  Minor code fix
Thank you very much for the headers!

However, a statement within the TrimAndSplitVersionString sub-procedure of the ReadImplementationProperties procedure caused an exception. The sub-statement:

(Buffer[Separator] in ['0'..'9'])

within the following lines of code:

// Find last non-numeric character before version number.
while (Separator > 0) and (Buffer[Separator] in ['0'..'9']) do
Dec(Separator);

cause an exception when evaluating the following "Buffer" value:

'1.5.4454 Win2000 Release'

I believe the problem occurred because my Delphi compiler has "early evaluation" disabled. This caused the "Buffer[Separator]" to go out of range with the "Separator" variable set to 0.

To fix this I changed the code to this:

// Find last non-numeric character before version number.
while (Separator > 0) do
if (Buffer[Separator] in ['0'..'9'])
then Dec(Separator);

in theory the unaltered code would also fail with Microsoft's generic renderer version string:

'1.2.2.0 Microsoft Corporation'

Also, I thought about changing this code:

// Find first non-numeric character after version number
while (Separator <= Length(Buffer)) and (Buffer[Separator] in ['0'..'9']) do
Inc(Separator);

however, doing so broke the logic... so I left it alone.

Just thought you should know and might consider incorporating this change into your published code.

Just for reference I'm running Windows 2000 SP6 with an ATI 9800 Pro using ATI's "wxp-w2k-catalyst-8-03-040610a-016126c.exe" driver which I think is Catalyst version 4.8.

Thanks Again,

Michael

P.S. I had to use a "German to English" translator to figure out which button to click and what to fill into the text boxes even though I believe I'm in the "English" version of the forum.
Autor:  Michael Brooks [ So Aug 08, 2004 07:38 ]
Betreff des Beitrags:  Another minor code fix
In addition to the problem I mentioned above, I found another problem with the extension checking code. I get a "range check error" when the "Extension" string is the last string being searched for within the Buffer. For example:

'GL_EXT_paletted_texture'

within:

'GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture'

The error occurs in the CheckExtension sub-procedure of the ReadImplementationProperties procedure, within this statement:

(Buffer[ExtPos + Length(Extension)] in ['_', 'A'..'Z', 'a'..'z'])

within the following lines of code:

// Now check that it isn't only a substring of another extension.
if Result then
Result := ((ExtPos + Length(Extension) - 1) = Length(Buffer)) or
not (Buffer[ExtPos + Length(Extension)] in ['_', 'A'..'Z', 'a'..'z']);

Like last time I believe this problem occurs because I have "early evaluation" disabled and "range checking" enabled.

To fix this I changed the above code to this:

if Result then
begin
Result := ((ExtPos + Length(Extension) - 1) = Length(Buffer));
if not Result then
Result := not (Buffer[ExtPos + Length(Extension)] in ['_', 'A'..'Z', 'a'..'z']);
end;

Again I thought you should know and might consider incorporating this change into your published code.

For reference I discovered this while testing my own code with the Microsoft Windows 2000 GDI Generic Sofware Renderer that supports OpenGL 1.1.0.

Thank You,

Michael
Autor:  Gast [ So Aug 08, 2004 07:50 ]
Betreff des Beitrags:  Re: Minor code fix
Thank you very much for the headers!

However, a statement within the TrimAndSplitVersionString sub-procedure of the ReadImplementationProperties procedure caused an exception. The sub-statement:
Code:
  1. (Buffer[Separator] in ['0'..'9'])

within the following lines of code:
Code:
  1.  
  2.   // Find last non-numeric character before version number.
  3.   while (Separator > 0) and (Buffer[Separator] in ['0'..'9']) do
  4.     Dec(Separator);
  5.  

caused an exception when evaluating the following \"Buffer\" value:

'1.5.4454 Win2000 Release'

I believe the problem occurred because my Delphi compiler has \"early evaluation\" disabled. This caused the \"Buffer[Separator]\" to go out of range with the \"Separator\" variable set to 0.

To fix this I changed the code to this:
Code:
  1.  
  2.   // Find last non-numeric character before version number.
  3.   while (Separator > 0) do
  4.     if (Buffer[Separator] in ['0'..'9'])
  5.       then Dec(Separator);
  6.  

in theory the unaltered code would also fail with Microsoft's generic renderer version string:

'1.2.2.0 Microsoft Corporation'

Also, I thought about changing this code:
Code:
  1.  
  2.   // Find first non-numeric character after version number
  3.   while (Separator <= Length(Buffer)) and (Buffer[Separator] in ['0'..'9']) do
  4.     Inc(Separator);
  5.  

however, doing so broke the logic... so I left it alone.

Just thought you should know and might consider incorporating this change into your published code.

Just for reference I'm running Windows 2000 SP6 with an ATI 9800 Pro using ATI's "wxp-w2k-catalyst-8-03-040610a-016126c.exe" driver which I think is Catalyst version 4.8.

Thanks Again,

Michael

P.S. I had to use a "German to English" translator to figure out which button to click and what to fill into the text boxes even though I believe I'm in the "English" version of the forum.
Autor:  Sascha Willems [ So Aug 08, 2004 09:28 ]
Betreff des Beitrags: 
@Fixes :
Thanks for the hints, but normally both of the functions you mentioned should work as they do (that may be because the option you mentioned is by default enabled). I for one am using a Radeon 9700 under WindowsXP and the version string is almost the same, but there are no problems. But we'll look into this, and if necessary, update the header.

@German :
If you register, you can choose english language in your profile, so that the buttons and most important strings are in your native language and not in german.
Autor:  Mars [ So Aug 08, 2004 14:25 ]
Betreff des Beitrags: 
Wenn die vorgeschlagene Änderungen eingebaut wird, sollte sie so lauten

Code:
  1.   // Find last non-numeric character before version number.
  2.   while (Separator > 0) do
  3.     if (Buffer[Separator] in ['0'..'9'])
  4.       then Dec(Separator);
  5.     else
  6.       break;


Ansonsten hängt man in einer Endlosschleife, sobald es sich beim ersten Zeichen um keine Ziffer handelt.

Allerdings gehe ich z.B. in meinen eigenen Bibliotheken auch davon aus, dass "full boolean evaluation" ausgeschaltet ist, da man so viel effizienter mit AND und OR arbeiten kann - ansonsten könnte man zu auch irgendwo am Anfang der Bibliothek ein {$B-} einfügen.
Autor:  Mirage [ Mo Mär 21, 2005 19:36 ]
Betreff des Beitrags:  Linux headers
Hi all!

Is there a Linux version of these great OpenGL headers? For Free Pascal.
Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/