Jump to page: 1 24  
Page
Thread overview
interfacing C bitfield structs
Mar 17, 2006
Wolfgang Draxinger
Mar 17, 2006
Kyle Furlong
Mar 17, 2006
Wolfgang Draxinger
Mar 18, 2006
Lucas Goss
Mar 18, 2006
Wolfgang Draxinger
Mar 18, 2006
Regan Heath
Mar 18, 2006
Wolfgang Draxinger
Mar 18, 2006
Walter Bright
Mar 18, 2006
Wolfgang Draxinger
Mar 20, 2006
Walter Bright
Mar 20, 2006
Don Clugston
Mar 20, 2006
Chris Miller
Mar 20, 2006
Wolfgang Draxinger
Bitfield structs and suggestion
Mar 20, 2006
Miles
Mar 21, 2006
Don Clugston
Mar 21, 2006
Miles
Mar 22, 2006
Don Clugston
Nov 23, 2007
Richard Bradley
Nov 23, 2007
dominik
Nov 23, 2007
Daniel Keep
Nov 23, 2007
Regan Heath
Nov 23, 2007
Janice Caron
Nov 23, 2007
Richard Bradley
Nov 23, 2007
Janice Caron
Nov 23, 2007
Robert Fraser
Nov 24, 2007
Nick B
Nov 25, 2007
David B. Held
Nov 28, 2007
Martin d Anjou
Nov 29, 2007
Janice Caron
Nov 29, 2007
Leandro Lucarella
Nov 23, 2007
Richard Bradley
Nov 24, 2007
0ffh
Nov 24, 2007
bearophile
Dec 04, 2007
Nick B
Nov 28, 2007
Walter Bright
Nov 29, 2007
Craig Black
March 17, 2006
I'm currently writing D includes for several game and graphics related libraries (OpenGL, OpenAL, DevIL, SDL, cairo, Freetype2).

Now with SDL I've encountered a problem: SDL makes use of serval bitfields and I've no idea, how to interface them to D.

Has somebody an idea how I best interface with it elegantly?

Greetings

Wolfgang Draxinger

March 17, 2006
Wolfgang Draxinger wrote:
> I'm currently writing D includes for several game and graphics
> related libraries (OpenGL, OpenAL, DevIL, SDL, cairo,
> Freetype2).
> 
> Now with SDL I've encountered a problem: SDL makes use of serval
> bitfields and I've no idea, how to interface them to D.
> 
> Has somebody an idea how I best interface with it elegantly?
> 
> Greetings
> 
> Wolfgang Draxinger
> 

I would just like to make you aware of the fact that all these have been interfaced to D already. You can find many of these bindings (and more) on www.dsource.org under a few projects: bindings, terra, and derelict.
March 17, 2006
Kyle Furlong wrote:

> I would just like to make you aware of the fact that all these have been interfaced to D already. You can find many of these bindings (and more) on www.dsource.org under a few projects: bindings, terra, and derelict.

I know, but they failed to work for me, last time I checked. Don't know how it's unter Windows but I need it for Linux. Additionally I made bindings to GLEW so that you can use OpenGL extensions with a breeze; due to some heavy use of macros I haven't yet added interfaces to the GLEW multi context function. This requires for every extension function either a template wrapper or intermediary function built around, that calls the function pointer from a context struct.

-- 
Wolfgang Draxinger

March 18, 2006
Wolfgang Draxinger wrote:
> I'm currently writing D includes for several game and graphics
> related libraries (OpenGL, OpenAL, DevIL, SDL, cairo,
> Freetype2).

Me too :)

> Now with SDL I've encountered a problem: SDL makes use of serval
> bitfields and I've no idea, how to interface them to D.
> 
> Has somebody an idea how I best interface with it elegantly?

Not sure what problem you are having.

Kyle Furlong wrote:
> > ...You can find many of these
> > bindings (and more) on www.dsource.org under a few projects:
> > bindings, terra, and derelict.

> I know, but they failed to work for me, last time I checked.

Well I know derelict works on linux. But if you don't want to take that approach (the dynamic loading), Anders has sdl bindings here:
http://www.algonet.se/~afb/d/

Which you can use or might help point you in the right direction.

Lucas
March 18, 2006
On Fri, 17 Mar 2006 23:50:39 +0100, Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote:
> I'm currently writing D includes for several game and graphics
> related libraries (OpenGL, OpenAL, DevIL, SDL, cairo,
> Freetype2).
>
> Now with SDL I've encountered a problem: SDL makes use of serval
> bitfields and I've no idea, how to interface them to D.
>
> Has somebody an idea how I best interface with it elegantly?

I don't know if you'd call this elegant but here is what I did. The important thing is using a type which is the correct size for the bitfields and then creating some way to interface the bits you need.

struct DCB {
    DWORD DCBlength;       /* sizeof(DCB)                     */
    DWORD BaudRate;        /* Baudrate at which running       */
    uint BITS;
    //bit fBinary;           /* Binary Mode (skip EOF check)    */
    //bit fParity;           /* Enable parity checking          */
    //bit fOutxCtsFlow;      /* CTS handshaking on output       */
    //bit fOutxDsrFlow;      /* DSR handshaking on output       */
    //bit[2] fDtrControl;    /* DTR Flow control                */
    //bit fDsrSensitivity;   /* DSR Sensitivity              */
    //bit fTXContinueOnXoff; /* Continue TX when Xoff sent */
    //bit fOutX;             /* Enable output X-ON/X-OFF        */
    //bit fInX;              /* Enable input X-ON/X-OFF         */
    //bit fErrorChar;        /* Enable Err Replacement          */
    //bit fNull;             /* Enable Null stripping           */
    //bit[2] fRtsControl;    /* Rts Flow control                */
    //bit fAbortOnError;     /* Abort all reads and writes on Error */
    //bit[17] fDummy2;       /* Reserved                        */
    WORD wReserved;        /* Not currently used              */
    WORD XonLim;           /* Transmit X-ON threshold         */
    WORD XoffLim;          /* Transmit X-OFF threshold        */
    BYTE ByteSize;         /* Number of bits/byte, 4-8        */
    BYTE Parity;           /* 0-4=None,Odd,Even,Mark,Space    */
    BYTE StopBits;         /* 0,1,2 = 1, 1.5, 2               */
    char XonChar;          /* Tx and Rx X-ON character        */
    char XoffChar;         /* Tx and Rx X-OFF character       */
    char ErrorChar;        /* Error replacement char          */
    char EofChar;          /* End of Input character          */
    char EvtChar;          /* Received Event character        */
    WORD wReserved1;       /* Fill for now.                   */
}
alias DCB* LPDCB;

private import std.intrinsic;

void fBinary(DCB* dcb, uint b)           { (b) ? bts(&dcb.BITS,0) : btr(&dcb.BITS,0); }	
void fParity(DCB* dcb, uint b)           { (b) ? bts(&dcb.BITS,1) : btr(&dcb.BITS,1); }
void fOutxCtsFlow(DCB* dcb, uint b)      { (b) ? bts(&dcb.BITS,2) : btr(&dcb.BITS,2); }
void fOutxDsrFlow(DCB* dcb, uint b)      { (b) ? bts(&dcb.BITS,3) : btr(&dcb.BITS,3); }
void fDtrControl(DCB* dcb, uint b)       { (bt(&b,0)) ? bts(&dcb.BITS,4) : btr(&dcb.BITS,4); (bt(&b,1)) ? bts(&dcb.BITS,5) : btr(&dcb.BITS,5); }
void fDsrSensitivity(DCB* dcb, uint b)   { (b) ? bts(&dcb.BITS,6) : btr(&dcb.BITS,6); }
void fTXContinueOnXoff(DCB* dcb, uint b) { (b) ? bts(&dcb.BITS,7) : btr(&dcb.BITS,7); }
void fOutX(DCB* dcb, uint b)             { (b) ? bts(&dcb.BITS,8) : btr(&dcb.BITS,8); }
void fInX(DCB* dcb, uint b)              { (b) ? bts(&dcb.BITS,9) : btr(&dcb.BITS,9); }
void fErrorChar(DCB* dcb, uint b)        { (b) ? bts(&dcb.BITS,10) : btr(&dcb.BITS,10); }
void fNull(DCB* dcb, uint b)             { (b) ? bts(&dcb.BITS,11) : btr(&dcb.BITS,11); }
void fRtsControl(DCB* dcb, uint b)       { (bt(&b,0)) ? bts(&dcb.BITS,12) : btr(&dcb.BITS,12); (bt(&b,1)) ? bts(&dcb.BITS,13) : btr(&dcb.BITS,13); }
void fAbortOnError(DCB* dcb, uint b)     { (b) ? bts(&dcb.BITS,14) : btr(&dcb.BITS,14); }

Note: The commented types shown in the struct were an attempt to use D's bit type. They were originally C bitfields.

Regan
March 18, 2006
Regan Heath wrote:

> I don't know if you'd call this elegant but here is what I did. The important thing is using a type which is the correct size for the bitfields and then creating some way to interface the bits you need.

I had the same idea and solved it this way. Doesn't seem elegant to me though.

> Note: The commented types shown in the struct were an attempt to use D's bit type. They were originally C bitfields.

The same crossed my mind, too, but I was unsure how data alignment would interfere with this.

-- 
Wolfgang Draxinger

March 18, 2006
Lucas Goss wrote:

> But if you don't want to
> take that approach (the dynamic loading), Anders has sdl
> bindings here: http://www.algonet.se/~afb/d/

Nice, eventually I even use his bindings.

Eventually I put my GLEW bindings over his.

My GLEW bindings are up and running, without multicontext support though. I still must write a small script the generates the D template functions for this.

If compiled with multitexture supprort GLEW expects the user to supply a function GLEWContext *glewGetContext(). This is used in macros like

#define glActiveTextureUnitARB
GLEW_GET_FUN(__glewActiveTextureUnitARB)

And GLEW_GET_FUN is a macro

#ifdef GLEW_MX
#define GLEW_GET_FUN(x) glewGetContext()->x
#else
#define GLEW_GET_FUN(x) x
#endif

So far the only way I know to bring this to D is to do something like this

version(GLEW_MX)
{
template glActiveTextureUnitARB(unit){ GLvoid
glActiveTextureUnitARB(unit) { return
__glewActiveTextureUnitARB(unit); } }
}
else
{
alias __glewActiveTextureUnitARB glActiveTextureUnitARB;
}

I'm using templates since using normal functions would eventually be compiled not as inline, which is preferred.

This got me to an idea for a new D feature, that would allow to use aliases as a replacement for macros, if I could have written

template glActiveTextureUnitARB(...) function { return
glewGetContext().__glewActiveTextureUnitARB(...) ; }

It would be much more readable. I mean, that by adding the keyword 'function' after the template definition you don't have to repeat the template name to make it a function template and the ellipsis '...' as a placeholder for an arbitrary long parameter list, eventually supporting some scheme to extract a certain parameter.

But so I have to extract the parameter list and the return type from the extension functions definition and generate template worms for it.

-- 
Wolfgang Draxinger

March 18, 2006
"Regan Heath" <regan@netwin.co.nz> wrote in message news:ops6lu2fsx23k2f5@nrage.netwin.co.nz...
> I don't know if you'd call this elegant but here is what I did. The important thing is using a type which is the correct size for the bitfields and then creating some way to interface the bits you need.
>
> struct DCB {
>     DWORD DCBlength;       /* sizeof(DCB)                     */
>     DWORD BaudRate;        /* Baudrate at which running       */
>     uint BITS;
>     //bit fBinary;           /* Binary Mode (skip EOF check)    */
>     //bit fParity;           /* Enable parity checking          */

Add two member functions for each:

    bool fBinary() { return BITS & 1; }
    bool fBinary(bool b) { BITS |= b; return b; }

    bool fParity() { return (BITS & 2) != 0; }
    bool fParity(bool b) { BITS |= b << 1; return b; }

and then, because functions work like properties, you can use them as if they were properties.


March 18, 2006
Walter Bright wrote:

> Add two member functions for each:
> 
>     bool fBinary() { return BITS & 1; }
>     bool fBinary(bool b) { BITS |= b; return b; }
> 
>     bool fParity() { return (BITS & 2) != 0; }
>     bool fParity(bool b) { BITS |= b << 1; return b; }
> 
> and then, because functions work like properties, you can use them as if they were properties.

These set functions won't work if b==0, since it's just an OR. What's needed is

BITS = (BITS & ~(1<<n)) | b ? 1<<n : 0 ;

Anyways that's a cool idea to do it. Just looks a bit strange.

-- 
Wolfgang Draxinger

March 20, 2006
"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message news:dvi5gv$qtg$1@digitaldaemon.com...
> These set functions won't work if b==0, since it's just an OR. What's needed is
>
> BITS = (BITS & ~(1<<n)) | b ? 1<<n : 0 ;

You're right.


« First   ‹ Prev
1 2 3 4