Jump to content
  • Advertisement
Sign in to follow this  
solenoidz

OpenGL API design

This topic is 2333 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have some wavering about what API design I should follow for a simple 3D engine.
I have some requirements :
Be accessible through every language that can call C-style APIs, including script languages.
Have relatively small list of API functions.
Be able to utilize an IDE code completion and restrict the possible options to the current context.
Be restrictive to the parameters and deny compilation if they do not make sense to the context.

The header file should be simple and easily translate-able to other languages, so probably pure C interface like OpenGL, OpenAL etc.

basically I think there are several approaches to such an API design. For example the first one.
include the needed operation in the API function name

SetEntityPosition3f(Entity* ent, float x, float y, float z) ;

this set only the entity position and can't set the entity scale by mistake, but unfortunately leads to very bloated API list - for every single operation -a different function.

Another approach is make something like (OpenAL/OpenGL) etc.


#define AL_POSITION 0x1004
alSource3f( ALuint sid, ALenum param, ALfloat value1, ALfloat value2, ALfloat value3 )


And the usage
alSource3f(0 , AL_POSITION,x,y,z);

But unfortunately the user could make a mistake and write
alSource3f(0 , AL_STOPPED,x,y,z);
which will compile just fine - ALenum is just an int. Also using the code completion would be hard to find the right parameter - AL_...are many and 'global"

Another approach is to use something like :
in the header


struct TransformType
{
enum Param
{
Position,
Rotation,
Scale

};


};

EntitySetTransform3f(Enitity* ent, TransformType trans, float x, float y, float z) ;


And usage

EntitySetTransform3f(entity, TransformType::Position , 10,10,10);


Here code completion will list only the transform parameters, but header is polluted with structs with enums
and I'm not sure how they could be translated to different languages.

Which one do you prefer the most ?

Share this post


Link to post
Share on other sites
Advertisement
I prefer the first one for clarity of operation and not requiring any additional defines and enums.

However, if your library is C++ internally, and you're internally doing entity->SetPosition(x, y, z) I'd recommend also exposing the C++ API.

Share this post


Link to post
Share on other sites
Thanks for the reply.
Yes, I thought so about the first one, but then I realized that the functions count rapidly goes up and probably will become uncomfortable to support such a huge list of functions in an editor, in scripts etc. For example, I need to register all those functions in the script in order to call them, as opposed to register only small list of functions and call them with the right parameters.
For example with the method of OpenAL , I can choose the right operation by index [color=#000000][size=2]

alSource3f(0, Index,...) ; and with the first method I need to call a function explicitly by it's name.

[font=arial, sans-serif][size=1] [/font]

Share this post


Link to post
Share on other sites
Just expose an object oriented api. Flat C might sound l33t but that's pretty much it. It's not like you'll have to deploy it in a nuclear plant or anything. I hope you have considered using a standard scripting language first.

Share this post


Link to post
Share on other sites
Consider using a scripting language where exposing functions can either be automated, or is rather painless even manually (for example AngelScript).

For an editor you probably want an object attribute/introspection system, but that can be different from the actual programming API.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!