C API

[rweichler]

#21

I wouldn't merge this just yet - there are a few ugly hacks in this. Wanted to run some ideas by you first.

So, the first thing is that I had to redefine all of the structs and typedefs. This is because they're scattered throughout the codebase in files with C++ code. My suggestion is that these structs and typedefs are instead put in some sort of XXX-Structs.h file or something.

Also, for many of the structs, I had to strip out the C++ convenience functions:

typedef struct q3Mat3
{
    q3Vec3 ex;
    q3Vec3 ey;
    q3Vec3 ez;
        // C++ convenience functions were here
} q3Mat3;

This would be an easy fix, just add #ifdef __cplusplus things around the convenience functions.

I was also not able to properly expose the classes to C, since classes aren't supported in C. I had to typedef them to void to get it to work:

// bootstrapped types

typedef void q3Body;
typedef void q3Scene;
typedef void q3BoxDef;
typedef void q3Quaternion;
typedef void q3ContactListener;
typedef void q3Render;

I might suggest changing these classes into structs, since it seems like OOP isn't being used anyway.

This last one I don't have any idea on how to tackle. Basically, I wrote the C API functions using a bunch of macros that basically called the original function in C++ (the EXPOSE macro). However, there's a bit of an issue with the pass-by-reference functions (with the & in the arguments). I can't generate them using EXPOSE. So I wrote a workaround for if the function had only pass-by-reference arguments (the PXPOSE macro, P for pointer). But unfortunately there were about 5 or 6 functions that had mixed pass-by-reference and pass-by-value, which I'd have to write by hand (and would be hell to maintain in the future).

My request is that all functions get rid of this pass-by-reference functionality and instead use regular pointers, unless if there's another solution I haven't thought of.

[rweichler]

BTW, I should clarify, this compiles and works. But it's ugly.

Also I only exposed q3Scene, q3Body, and q3Box, which is all I need for my use case.

[RandyGaul]

Hi there! Very cool, I'm glad you took some time to make this. I'll have some time next week to look into it in detail. You're right, OOP is not used and so all member functions can be either hidden away or just converted to C code fairly easily. I think the idea of adding in a structs header is a good idea, but it might not be necessary if the opaque typedefs work out.

As for pass by value/reference, I actually really don't like references and would be completely happy to see them gone. Passing pointers and strictly by-value everything else would be a positive change.

[rweichler]

No problem! Thanks for this awesome library :D

And cool, I'll start implementing these when I have time. This C API works for my use case so it may be a while before getting around to it.

[RandyGaul]

Took a closer look. The macros look practical, but I would not want to pull them in in the current state. I think a proper solution would be to just re-write some of the source files in C form. This would be more or less a C port at that point, and someone is working on a C port right now for the Citro3D library (https://github.com/tommai78101/citro3d/tree/physics/source/physics). Personally I don't think I can dedicate time to a C port, and since you got it working for your purposes, all seems well for now :)

[tommai78101]

@rweichler I would encourage you to continue with your own C implementation port. My C implementation is not meant for targeting the PC platform.

@RandyGaul Quick update, the C port has been moved to its own repository: https://github.com/tommai78101/Pica. Reason is the original repository gives the wrong impression that the graphics library will be getting a physics engine, which goes against the original developer's wishes. Therefore, I separated my codes away from Citro3D, so it is truly an extension, rather than an integration of it.