C interface as core feature

What it says on the tin: a place to discuss proposed new features.
Post Reply
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

C interface as core feature

Post by jacmoe »

What I would really like is a C interface to Ogre, maintained as a core feature.

That would be lovely. :)

It would allow us to generate bindings for Lisp, Delphi, Scheme, Lua, Python, .NET, whatever.

I admit openly that I am moving my Lisp/Scheme programming to Horde3D because it's got a C interface. :wink:

Binding C++ is just so error prone and fraught with problems.

Having an official C interface would allow Ogre to reach a much broader audience.

And it would (hopefully) unite the people who have been forced to fork Ogre in order to maintain various C interfaces (.NET, Delphi, ...).


I don't usually file feature requests, but now I did. :wink:

// EDIT by spacegaier: Link to hosted code: http://code.google.com/p/llcoi/
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: C interface as core feature

Post by Wolfmanfx »

Have you ever tried swik? Maybe its something for you. I am using swig to generate a C# binding its working really good.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

I remember the Python/SWIG nightmare ages ago..
No need to repeat that.

This shouldn't mean a lot of extra work - once the interface has been written - because when the interface changes, the C interface changes with it.

Manually created interface, mind you.

C++ is the big problem here.
And SWIG (because of C++) is extremely error-prone.
Ask the Python-Ogre team about SWIG..
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
betajaen
OGRE Moderator
OGRE Moderator
Posts: 3447
Joined: Mon Jul 18, 2005 4:15 pm
Location: Wales, UK
x 58
Contact:

Re: C interface as core feature

Post by betajaen »

You've been playing with C again haven't you Jacmoe? ;)
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

No. Not really.

C is great because anything can talk to it.

Nothing can talk to C++. :)

The problem is that once you want to use Ogre using a different language than C++, you face the monster: the C++ ABI.
You need to drop to C (and choose another engine which has a C interface instead, maybe).
Lua, Delphi, C# - .NET in general, Lisp, Scheme - you name it. :wink:
<edit> Forgot Ruby. </edit>

My choice of a scripting language is Angelscript because that's the only language out there which can deal with C++ (without resorting to hacky code wrangling generators like SWIG, etc.)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

Horde3D has it as a strong feature:
Strong modularity and high abstraction through flat C-style DLL API (also makes it possible to use Horde3D from virtually any programming language)
Why not Ogre3D ?

I will look into how the maintain that C API, because that is indeed a very good feature.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

betajaen wrote:You've been playing with C again haven't you Jacmoe? ;)
How about Ruby, Betajaen?
Think about how much easier it would be to drive Ogre from your favorite language. :wink:

I don't expect anything - just planting some seeds (for now)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
so0os
Bugbear
Posts: 833
Joined: Thu Apr 15, 2010 7:42 am
Location: Poznan, Poland
x 33

Re: C interface as core feature

Post by so0os »

I totally support this idea with all my coding strength, count me in!

I was thinking about this a while back, but it's just not possible for one man to do this, since Ogre is a class-hell. I guess for being usable, apart from being working, it needs to be worked out pretty much different in many fields than the usual Ogre way. Anyways, I can led a hand, and I guess C programmers are pretty much extinct (and more so, ones that know Ogre) so I can actually be of use this time.
Sos Sosowski :)
http://www.sos.gd
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: C interface as core feature

Post by CABAListic »

Creating and maintaining a C interface to a (class-heavy) C++ library is, in my experience, a tedious and boring affair. I really don't think it is appropriate to lay this onto the Ogre team. If you want it, gather a team that's willing to create and maintain it :)
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

It looks like they're doing it by hand:
http://horde3d.svn.sourceforge.net/view ... iew=markup

Maybe the trick is to start simple and build from there.
Also, since Ogre is much bigger, it would make sense to have several C DLLs.
And o3dMain.cpp in each, and then a collection of headers with the interface (like Horde3d).

I think it would be worth the effort.
But - I really hope it could be transplanted right into the core of Ogre.

If the Horde3D developers think it's worth it, why not Ogre?
Despite what you *personally* think..
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

If anyone knows of hand-rolled C interfaces for Ogre floating around, could you post them here? :)

I know of VGE:
https://trac.v2.nl/browser/vge/trunk/VGE?rev=3486
Look in 'base'.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

Project llcoi (Low Level C Ogre Interface) initiated...
llcoi.png
llcoi.png (18.69 KiB) Viewed 48199 times
Might need some help later. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
betajaen
OGRE Moderator
OGRE Moderator
Posts: 3447
Joined: Mon Jul 18, 2005 4:15 pm
Location: Wales, UK
x 58
Contact:

Re: C interface as core feature

Post by betajaen »

jacmoe wrote:
betajaen wrote:You've been playing with C again haven't you Jacmoe? ;)
How about Ruby, Betajaen?
Think about how much easier it would be to drive Ogre from your favorite language. :wink:
Ogre in Ruby would be awful, it would be a huge bottleneck, unless you have a C/C++ side that handled the game loop, and anything by Ruby/Ogre was caused by event functions.

But, Yes, Yes I like Ruby. ;)
User avatar
so0os
Bugbear
Posts: 833
Joined: Thu Apr 15, 2010 7:42 am
Location: Poznan, Poland
x 33

Re: C interface as core feature

Post by so0os »

I just realised that whole Math package would need to be rewritten to compensate for loss of operators.

EDIT: I just realised that string interface is useless in C

EDIT2: I just realised that half of the methods have overloads

Conclusion: only solution is to redo it OR make a heavy interface, that will not have much in common with actual Ogre API
Sos Sosowski :)
http://www.sos.gd
kornerr
Greenskin
Posts: 110
Joined: Sun Dec 04, 2005 5:17 pm
Location: Russia
x 5
Contact:

Re: C interface as core feature

Post by kornerr »

it would be nice to have, but only automatically generated. otherwise only jacmoe will be able to answer C interface questions.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

I think I will try both approaches. :wink:

There must be a good reason why PyOgre and OgreDotNet failed to produce (they were SWIG powered), and why Ogre.rb moved away from SWIG, as did Python-Ogre.

I would prefer a hand-rolled C interface.
Bullet does feature a C API, and Horde3D (as I harped on about earlier).
They are handwritten.

Also, the Lisp wrapper for Ogre (can't remember the name off-hand) first used SWIG, then most probably gave up and moved on to something else?
(I need to confirm that)

About Ogre Math:
OgreDotNet (or so it seems) wrote their own Math classes (for some reason).

So, what's the deal with SWIG? :)

If someone is willing to donate a bunch of SWIG interface files - the license is MIT - then we could get started faster.

Otherwise I'll just steal the files from OgreDotNet - but have a license problem..
Maybe I should try and contact the original project owner for a re-license..

As said before, I'll try to do both.
I have a feeling that the handwritten one would be more enjoyable in use. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
so0os
Bugbear
Posts: 833
Joined: Thu Apr 15, 2010 7:42 am
Location: Poznan, Poland
x 33

Re: C interface as core feature

Post by so0os »

Handwritten is bound to be better, but is it possible to actually create such thing in finite time.

And second of all, is the aim to mimic original Ogre OO behaviour, or actually make it useable, and at least in some fields, totally detached from how you do things with C++ Ogre.
Sos Sosowski :)
http://www.sos.gd
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

I think I'll do a simplified (read: abstracted) interface first. :)
Example will be posted in a day or two.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
so0os
Bugbear
Posts: 833
Joined: Thu Apr 15, 2010 7:42 am
Location: Poznan, Poland
x 33

Re: C interface as core feature

Post by so0os »

Let me know if you need a hand ;)
Sos Sosowski :)
http://www.sos.gd
User avatar
betajaen
OGRE Moderator
OGRE Moderator
Posts: 3447
Joined: Mon Jul 18, 2005 4:15 pm
Location: Wales, UK
x 58
Contact:

Re: C interface as core feature

Post by betajaen »

Jacmoe, you inspired me a little.

Took little effort to pull this off.

Code: Select all

require_relative "NxOgreLib"

world = NxOgreLib::World.createWorld
world.advance(0.125)
NxOgreLib::World.destroyWorld
That's Ruby code, accessing the NxOgre DLL via a light DLL wrapper "ffi" through extern "c".

Although I doubt it would be fast enough for heavy physics usage, I have some other plans that I needed Ruby and NxOgre with - webserver plans. ;)
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

This is what I have at the moment:

Code: Select all

    engine_options options;
    default_engine_options(&options);
    options.renderer_s = "Direct3D9";
    options.window_title = "Renderwindow from C";

    init_engine(options);
    
    add_resource_location("../media/materials/scripts", "FileSystem", "General");
    add_resource_location("../media/materials/textures", "FileSystem", "General");
    add_resource_location("../media/models", "FileSystem", "General");
    
    create_camera("mycam");
    
    camera_set_position("mycam", 0, 0, 80);
    
    camera_lookat("mycam", 0, 0, -300);
    
    camera_set_near_clip_distance("mycam", 5);

    add_viewport("mycam");

    textureManager_setDefaultNumMipmaps(5);
    
    initialise_all_resourcegroups();
    
    create_entity("OgreHead", "ogrehead.mesh");
    
    create_child_scenenode("headNode");
    
    attach_entity_to_scenenode("OgreHead", "headNode");
    
    set_ambient_light_rgb(0.5f, 0.5f, 0.5f);
    
    create_light("mainLight");
    
    light_set_position("mainLight", 20, 80, 50);
    
    render_loop();

    release_engine();
The interface itself:

Code: Select all

typedef struct
{
    char* renderer_s;
    char* plugin_folder_s;
    char* window_title;
    char* log_name;
    int width, height, auto_window;
} engine_options;

DLL void release_engine();

DLL void default_engine_options(engine_options* options);

DLL void init_engine(const engine_options options);

DLL void load_ogre_plugin(const char * plugin);

DLL void create_camera(const char* name);

DLL void camera_set_near_clip_distance(const char* camera_name, double d);

DLL void camera_set_far_clip_distance(const char* camera_name, double d);

DLL void camera_set_auto_aspect_ratio(const char* camera_name, int on);

DLL void camera_set_fovy(const char* camera_name, float angle);

DLL void camera_set_frustum_offset(const char* camera_name, const int offset_x, const int offset_y);

DLL void camera_set_focal_length(const char* camera_name, double fl);

DLL void camera_set_position(const char* camera_name, const float x, const float y, const float z);

DLL void camera_lookat(const char* camera_name, const float x, const float y, const float z);

DLL void add_viewport(const char* camera_name);

DLL void render_loop();

DLL void add_resource_location(const char* location, const char* type, const char* group);

DLL void initialise_all_resourcegroups();

DLL void create_entity(const char* entity_name, const char* mesh_file);

DLL void create_child_scenenode(const char* node_name);

DLL void attach_entity_to_scenenode(const char* object_name, const char* node_name);

DLL void set_ambient_light_rgba(const int r, const int g, const int b, const int a);

DLL void set_ambient_light_rgb(const int r, const int g, const int b);

DLL void create_light(const char* light_name);

DLL void light_set_position(const char* light_name, const float x, const float y, const float z);

DLL void textureManager_setDefaultNumMipmaps(int number);
As you can see it's still in the very early stages.. :wink:
And it could use an expert C programmers skills.
I will work on it a bit more, and then - if anyone is interested - I will ask for help later on.
Need to find a consistent style first.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
betajaen
OGRE Moderator
OGRE Moderator
Posts: 3447
Joined: Mon Jul 18, 2005 4:15 pm
Location: Wales, UK
x 58
Contact:

Re: C interface as core feature

Post by betajaen »

That's a different approach to what I've to in NxOgre. I realise that Ogre and NxOgre are very different things, but the style of C++ API between the two is very similar. Anyway, this is what I have in NxOgre for the World Object (like Ogre's Root).

Code: Select all

#if NXOGRE_C_API == 1

extern "C"
{
 
 struct NXC_WorldDescription
 {
  int assertion_policy;
  unsigned int cooker_thread_mask;
  unsigned int hardware_maximum_convex;
  unsigned int hardware_page_size;
  unsigned int hardware_maximum_page;
  int no_hardware;
  int per_scene_batching;
  unsigned int gpu_heap_size;
  unsigned int mesh_cache_size;
 };
 
 NXOGRE_C_FUNCTION void* NXC_WorldCreate(NXC_WorldDescription* d)
 {
  NxOgre::WorldDescription desc;
  desc.mAssertionPolicy = (NxOgre::Enums::PhysXAssertionPolicy) d->assertion_policy;
  desc.mCookerThreadMask = d->cooker_thread_mask;
  desc.mGPUHeapSize = d->gpu_heap_size;
  desc.mHardwareMaximumConvex = d->hardware_maximum_convex;
  desc.mHardwareMaximumPage = d->hardware_maximum_page;
  desc.mHardwarePageSize = d->hardware_page_size;
  desc.mMeshCacheSize = d->mesh_cache_size;
  desc.mNoHardware = d->no_hardware;
  desc.mPerSceneBatching = d->per_scene_batching;
  return NxOgre::World::createWorld(desc);
 }
 
 NXOGRE_C_FUNCTION void NXC_WorldDestroy()
 {
  NxOgre::World::destroyWorld();
 }

 NXOGRE_C_FUNCTION NXC_WorldDescription* NXC_WorldDescriptionNew()
 {
  NXC_WorldDescription* desc = new NXC_WorldDescription();
  desc->assertion_policy = NxOgre::Enums::PhysXAssertionPolicy_Continue;
  desc->cooker_thread_mask = 0;
  desc->gpu_heap_size = 32;
  desc->hardware_maximum_convex = 2048;
  desc->hardware_maximum_page = 256;
  desc->hardware_page_size = 65536;
  desc->mesh_cache_size = 0xffffffff;
  desc->no_hardware = true;
  desc->per_scene_batching = true;
  return desc;
 }

 NXOGRE_C_FUNCTION void NXC_WorldDescriptionReset(NXC_WorldDescription* desc)
 {
  std::cout << "Reseting\n";
  desc->assertion_policy = NxOgre::Enums::PhysXAssertionPolicy_Continue;
  desc->cooker_thread_mask = 0;
  desc->gpu_heap_size = 32;
  desc->hardware_maximum_convex = 2048;
  desc->hardware_maximum_page = 256;
  desc->hardware_page_size = 65536;
  desc->mesh_cache_size = 0xffffffff;
  desc->no_hardware = true;
  desc->per_scene_batching = true;
 }

 NXOGRE_C_FUNCTION void NXC_WorldDescriptionDelete(NXC_WorldDescription* desc)
 {
  if (desc)
   delete desc;
 }
 
 NXOGRE_C_FUNCTION void NXC_WorldAdvance(NxOgre::World* world, float time)
 {
  world->advance(time);
 }

 NXOGRE_C_FUNCTION NxOgre::World* NXC_WorldSingleton()
 {
  return NxOgre::World::getSingleton();
 }
 
 NXOGRE_C_FUNCTION void NXC_WorldSetAssertionPolicy(NxOgre::World* world, int policy)
 {
  world->setPhysXAssertionPolicy((NxOgre::Enums::PhysXAssertionPolicy) policy);
 }
 
 NXOGRE_C_FUNCTION int NXC_WorldGetAssertionPolicy(NxOgre::World* world)
 {
  return world->getPhysXAssertionPolicy();
 }
 
}

#endif
I suppose my way is more of a direct wrapper, each function represents a classes method, which the first argument is a pointer to that method. The differences though, is that I'm using an int for a boolean value and enums. I've also mirrored the WorldDescription class which has constructors/destructors and methods to an aggregate struct called NXC_WorldDescription.

The second part is particularity useful as, I can duplicate the struct in Ruby code and just pass the pointer of that instance directly into NxOgre. My Ruby wrapping of the code is quite straight forward, it just turns the C API back into a Ruby OO API.

Code: Select all

require 'ffi'

module NxOgreLib

    extend FFI::Library
    ffi_lib 'NxOgreDebug.dll'
    ffi_convention :stdcall

    attach_function 'NXC_WorldCreate', [:pointer], :pointer
    attach_function 'NXC_WorldDestroy', [], :void
    attach_function 'NXC_WorldAdvance', [:pointer, :float], :void
    attach_function 'NXC_WorldSetAssertionPolicy', [:pointer, :int], :void
    attach_function 'NXC_WorldGetAssertionPolicy', [:pointer], :int
    attach_function 'NXC_WorldDescriptionNew', [], :pointer
    attach_function 'NXC_WorldDescriptionReset', [:pointer], :void
    attach_function 'NXC_WorldDescriptionDelete', [:pointer], :void

    class Enums
     PHYSXASSERTIONPOLICY_CONTINUE = 0
     PHYSXASSERTIONPOLICY_IGNORE = 1
     PHYSXASSERTIONPOLICY_BREAKPOINT = 2
     PHYSXASSERTIONPOLICY_EXCEPTION = 3
    end

    class WorldDescription < FFI::Struct
          layout      :assertion_policy, :int,
                      :cooker_thread_mask, :uint,
                      :hardware_maximum_convex, :uint,
                      :hardware_page_size, :uint, 
                      :hardware_maximum_page, :uint,
                      :no_hardware, :int,
                      :per_scene_batching, :int,
                      :gpu_heap_size, :uint, 
                      :mesh_cache_size, :uint
          def initialize
            self[:assertion_policy] = Enums::PHYSXASSERTIONPOLICY_CONTINUE
            self[:cooker_thread_mask] = 0
            self[:gpu_heap_size] = 32
            self[:hardware_maximum_convex] = 2048
            self[:hardware_maximum_page] = 256
            self[:hardware_page_size] = 65536
            self[:mesh_cache_size] = -1
            self[:no_hardware] = 1
            self[:per_scene_batching] = 1
          end
    end

    class World

        def self.createWorld!(world_desc)
            @@singleton = World.new(world_desc)
            return @@singleton
        end

        def self.destroyWorld!
            @@singleton.shutdown
        end

        def self.instance
            return @@singleton
        end

        def advance(deltaTime = 0.16667)
            NxOgreLib.NXC_WorldAdvance(@world, deltaTime.to_f)
        end

        def initialize(world_desc)
            @world = NxOgreLib.NXC_WorldCreate(world_desc)
        end

        def shutdown
            NxOgreLib.NXC_WorldDestroy
        end

        def setAssertionPolicy(policy)
            if policy == :continue
                NxOgreLib.NXC_WorldSetAssertionPolicy(@world, Enums::PHYSXASSERTIONPOLICY_CONTINUE)
            elsif policy == :ignore
                NxOgreLib.NXC_WorldSetAssertionPolicy(@world, Enums::PHYSXASSERTIONPOLICY_IGNORE)
            elsif policy == :breakpoint
                NxOgreLib.NXC_WorldSetAssertionPolicy(@world, Enums::PHYSXASSERTIONPOLICY_BREAKPOINT)
            elsif policy == :exception
                NxOgreLib.NXC_WorldSetAssertionPolicy(@world, Enums::PHYSXASSERTIONPOLICY_EXCEPTION)
            end
        end


        def getAssertionPolicy()
            policy = NxOgreLib.NXC_WorldGetAssertionPolicy(@world)
            if policy == Enums::PHYSXASSERTIONPOLICY_CONTINUE
                return :continue
            elsif policy == Enums::PHYSXASSERTIONPOLICY_IGNORE
                return :ignore
            elsif policy == Enums::PHYSXASSERTIONPOLICY_BREAKPOINT
                return :breakpoint
            elsif policy == :exception
                return :exception
            end
            return :continue
        end

    end

end
In the end the NxOgre Ruby API is quite similar to NxOgre's, except I'm using symbols instead of enumeration values. I'd like to automate this somehow, perhaps make some sort of meta-language to generate the C and Ruby wrapping code for me.


I do like your approach though, it's different to what I first imagined, I thought you was going to do it like mine. How are you going to handle pointers and accessing objects? Multiple SceneManagers?
User avatar
so0os
Bugbear
Posts: 833
Joined: Thu Apr 15, 2010 7:42 am
Location: Poznan, Poland
x 33

Re: C interface as core feature

Post by so0os »

I just LOVE the style of that code (apart from textureManager_setDefaultNumMipmaps, it just doesn't fit :P) Pretty clean and easy to read.

Some of my thoguhts:
- things like camera_set_near_clip_distance doesn't really need camera_, do they?
- I would grammer-swizzle stuff, like set_light_position instead of light_set_position, it's trivial, but easier to read.
- make functions accept both, class pointer/handle and const char*. I even have an idea for that.
- go inline, or #define with everything applicable, calls through 8 dlls won't be that fast, and I'm not sure if _fastcall are exportable (e.g. if lua could 'talk' to a _fastcall)
- create math system from scratch, and make it faster than ogre's
- no explicit singletons, but that's pretty obvious
- go static, it's just a wrapper, making it a 8kb DLL, that is bound to create a call table everytime it loads is pretty much useless, also optimising stuff for inline and defines, would end up with a 100kb header and 16kb source

It looks way better than I expected. I'm still looking forward to doing this!

EDIT:
One more thing that pops into my mind, is
- use set_current_* approach for stuff that isn't changing much, e.g. scenemanagers, cameras, etc., this way would remove the need for each-time lookup.
Sos Sosowski :)
http://www.sos.gd
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

I am happy that you like it! :)
Am definitely going to add you to the project once it's ready for that.

About 'camera_set_position' instead of 'set_camera_position' or 'position_set_camera' is because of completion:
You write 'camera_' and then all camera related functions should (ideally) pop up in the auto-complete box.
Like 'camera_get_xx', 'camera_set_xx', etc.

It's a lot of work, of course, but if it's taken bit by bit, it's actually doable.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: C interface as core feature

Post by jacmoe »

I think that any auto-generation would ruin such an interface - it would be a totally different thing.
Let's see.. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Post Reply