Jump to content
Site Stability Read more... ×
  • Advertisement
Sign in to follow this  

OpenGL API design

This topic is 2763 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



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
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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!