FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

More Solid OpenGL Extension Support

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun Jan 07, 2007 9:57 am    Post subject: More Solid OpenGL Extension Support Reply with quote

I did more research on OpenGL extensions and learned that the two sources I was using, a version of glext.h and the online registry, weren't necessarily accurate. For example, some extensions were missing from one or the other, or some marked as incomplete in the registry were actually implemented.

As a result, I went through the OpenGL specification to ensure that support was implemented for all ARB extensions listed there. I also added support for every extension that was eventually incorporated into each version of OpenGL from 1.2 on. I also implemented any missing support for GL_EXT extensions present on my card that never made it into any verison of OpenGL. The result is several modules were added for GL_EXT extensions, as well as one each for GL_ARB, GL_NV, GL_HP, GL_SGI, and GL_SGIS.

Also, one extension was named GL_EXT_texture_compression_dxtc1 in the registry, but is actually named GL_EXT_texture_compression_s3tc. I corrected and renamed the corresponding module accordingly.

To see just which extensions were added, you can look here:

http://www.dsource.org/projects/derelict/changeset/212

I'm confident that GL_ARB, GL_EXT and GL_ATI are solid now. I will round out GL_NV next.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
quartz



Joined: 02 Jul 2006
Posts: 35
Location: Florida, US

PostPosted: Mon Jan 08, 2007 8:08 am    Post subject: Reply with quote

Question on derelictfiying ODE:

What do we do if the library could have been compiled using either float or double? ODE doesn't have a function, areYouCompiledUsingDouble().

For example, this bit of code in common.h

Code:

/* floating point data type, vector, matrix and quaternion types */

#if defined(dSINGLE)
typedef float dReal;
#elif defined(dDOUBLE)
typedef double dReal;
#else
#error You must #define dSINGLE or dDOUBLE
#endif


would I translate that into common.d as:
Code:

version (ODE_USING_DOUBLE) {
   alias double dReal;
} else {
   alias float dReal;
}


Any suggestions or guidelines? What would we do in these situations?

Cheers.
_________________
-Will (Quartz)
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Mon Jan 08, 2007 10:45 am    Post subject: Reply with quote

quartz wrote:
Question on derelictfiying ODE:

What do we do if the library could have been compiled using either float or double? ODE doesn't have a function, areYouCompiledUsingDouble().

For example, this bit of code in common.h

Code:

/* floating point data type, vector, matrix and quaternion types */

#if defined(dSINGLE)
typedef float dReal;
#elif defined(dDOUBLE)
typedef double dReal;
#else
#error You must #define dSINGLE or dDOUBLE
#endif


would I translate that into common.d as:
Code:

version (ODE_USING_DOUBLE) {
   alias double dReal;
} else {
   alias float dReal;
}


Any suggestions or guidelines? What would we do in these situations?


Sometimes this sort of thing can be annoying, for sure. In this case, I think your solution is a decent one. I would change the version statement, though, to something like version(DerelictODE_UsingDouble), or DerelictODE_DoublePrecision, perhaps.

Assuming float values by default seems a safe bet. We can also assume that in many cases developers will know which particular build of ODE they are targeting. In the Linux world, of course, one rarely ships shared libraries with the binary (and for open source apps it doesn't matter a whit), depending instead on what is already on the end-user's system. In that case, the problem is not unique to D and is the same in C -- if I build using floats, how can I be sure that the end user has a version of ODE compiled with floats?

Even if there is a mismatch, the only result will be a loss in precision going from one side to the other. For the large majority of developers that likely won't matter. Those that do care about it will need to take extra measures anyway.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
quartz



Joined: 02 Jul 2006
Posts: 35
Location: Florida, US

PostPosted: Sat Jan 13, 2007 11:49 pm    Post subject: Reply with quote

Hey aldacron,

I have integrated ODE into Derelict and I'm now testing it.

In the process I have run into my first issue involving ODE's error messaging callback framework such that I am getting segfaults. Note: So far I have successfully called other methods that worked but this is the first where ODE is calling back to a message function.

Here is the deal, you can set a message callback using:
dSetMessageHandler(dMessageFunction*);

then trigger it using:
dMessage(int, char*, ...);

When ODE's method actually calls back to D everything seems fine except when the function ends I get a segfault (I am using linux at this time, I will test under windows next).

I basically back tracked eliminating possible causes --out of both ODE and Derelict ODE code--to the point where ODE simply turns around and calls D back, but I still get a segfault only when the function "dMessage()" ends.

This is the code that calls Derelict back (note: I put printfs in it to see if it was segfaulting in ODE):

Code:

static dMessageFunction *message_function = 0;

extern "C" void dSetMessageHandler (dMessageFunction *fn)
{
  message_function = fn;
}

extern "C" dMessageFunction *dGetMessageHandler()
{
   return message_function;
}

extern "C" void dMessage (int num, const char *msg, ...)
{
  printf("ode dMessage\n");
  va_list ap;
  va_start (ap,msg);
  printf("ode here\n");
  if (message_function)
     message_function (num,msg,ap);
  else
     printMessage (num,"ODE Message",msg,ap);
  printf("ode done\n");
}


And this is Derelict's callback function to match method signature:
Code:

void myMessageFunction3(int num, char* msg, va_list ap)
{
   //writef("(Message ?s, ?d: ", msg, num);
   //vprintf(msg, ap);
   //writefln(")");
   //dSetMessageHandler(null);
}


This is the test code:
Code:

dSetMessageHandler(cast(dMessageFunction*)&myMessageFunction3);
writefln(&myMessageFunction3);
dMessageFunction* mf = dGetMessageHandler();
writefln(mf);
dMessage(666, "bye", 7, 8, "bummer");
writefln("Test complete");
return 0;


This is the output:
804BDB8
804BDB8
ode dMessage
ode here
ode done
Segmentation fault

As you can see it is segfaulting just after dMessage() finishes because I am not seeing "Test complete". As I mentioned, other functions are, for example the matrix and printing stuff is working.

How do handle callbacks from the other libraries? Any ideas? Rolling Eyes
_________________
-Will (Quartz)
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun Jan 14, 2007 2:05 am    Post subject: Reply with quote

quartz wrote:

And this is Derelict's callback function to match method signature:
Code:

void myMessageFunction3(int num, char* msg, va_list ap)
{
   //writef("(Message ?s, ?d: ", msg, num);
   //vprintf(msg, ap);
   //writefln(")");
   //dSetMessageHandler(null);
}



Try this:

Code:

extern(C) void myMessageFunction3(int num, char* msg, va_list ap)
{
}


Because the callback will be called from the C side, it needs to have C linkage.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
quartz



Joined: 02 Jul 2006
Posts: 35
Location: Florida, US

PostPosted: Sun Jan 14, 2007 9:21 pm    Post subject: Reply with quote

Yup. That fixed it. Thanks. Smile
_________________
-Will (Quartz)
Back to top
View user's profile Send private message
Zweistein



Joined: 21 Mar 2007
Posts: 19

PostPosted: Wed Jul 04, 2007 4:25 pm    Post subject: Reply with quote

Hi!

Very nice Work with the Extension thing! I never used Extensions. I will give it a try! Smile

My first Problem is that:

In my OpenGL Book, there is a Tutorial on how to use GL_ARB_Multitexture. To give the TexCoords you use:

glMultiTexCoord2fARB(GL_TEXTURE0_ARB, 0.0f, 0.0f);
glMultiTexCoord2fARB(GL_TEXTURE1_ARB, 0.0f, 0.0f);
glVertex3f(-1.0f, -1.0f, 1.0f);

per Example. But the Compiler says:

TowerDefense\GameSystem.d:69: Error: expected 2 arguments, not 3

But i think, there should be 3 arguments.

bye
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Jul 04, 2007 7:22 pm    Post subject: Reply with quote

Zweistein wrote:

In my OpenGL Book, there is a Tutorial on how to use GL_ARB_Multitexture. To give the TexCoords you use:

glMultiTexCoord2fARB(GL_TEXTURE0_ARB, 0.0f, 0.0f);
glMultiTexCoord2fARB(GL_TEXTURE1_ARB, 0.0f, 0.0f);
glVertex3f(-1.0f, -1.0f, 1.0f);

per Example. But the Compiler says:

TowerDefense\GameSystem.d:69: Error: expected 2 arguments, not 3

But i think, there should be 3 arguments.


It appears that most of the function declarations in that module are incorrect. I'll get it fixed shortly. Thanks for reporting it.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Fri Jul 06, 2007 10:39 am    Post subject: Reply with quote

Fixed in the trunk.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group