C interface as core feature
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
C interface as core feature
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.
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.
// EDIT by spacegaier: Link to hosted code: http://code.google.com/p/llcoi/
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.
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.
// 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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: C interface as core feature
Have you ever tried swik? Maybe its something for you. I am using swig to generate a C# binding its working really good.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
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..
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Moderator
- Posts: 3447
- Joined: Mon Jul 18, 2005 4:15 pm
- Location: Wales, UK
- x 58
Re: C interface as core feature
You've been playing with C again haven't you Jacmoe?
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
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.
<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.)
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.
<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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
Horde3D has it as a strong feature:
I will look into how the maintain that C API, because that is indeed a very good feature.
Why not Ogre3D ?Strong modularity and high abstraction through flat C-style DLL API (also makes it possible to use Horde3D from virtually any programming language)
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
How about Ruby, Betajaen?betajaen wrote:You've been playing with C again haven't you Jacmoe?
Think about how much easier it would be to drive Ogre from your favorite language.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Bugbear
- Posts: 833
- Joined: Thu Apr 15, 2010 7:42 am
- Location: Poznan, Poland
- x 33
Re: C interface as core feature
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.
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
http://www.sos.gd
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
Re: C interface as core feature
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
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
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..
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
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'.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
Project llcoi (Low Level C Ogre Interface) initiated...
Might need some help later. You do not have the required permissions to view the files attached to this post.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Moderator
- Posts: 3447
- Joined: Mon Jul 18, 2005 4:15 pm
- Location: Wales, UK
- x 58
Re: C interface as core feature
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.jacmoe wrote:How about Ruby, Betajaen?betajaen wrote:You've been playing with C again haven't you Jacmoe?
Think about how much easier it would be to drive Ogre from your favorite language.
But, Yes, Yes I like Ruby.
-
- Bugbear
- Posts: 833
- Joined: Thu Apr 15, 2010 7:42 am
- Location: Poznan, Poland
- x 33
Re: C interface as core feature
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
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
http://www.sos.gd
-
- Greenskin
- Posts: 111
- Joined: Sun Dec 04, 2005 5:17 pm
- Location: Russia
- x 5
Re: C interface as core feature
it would be nice to have, but only automatically generated. otherwise only jacmoe will be able to answer C interface questions.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
I think I will try both approaches.
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.
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.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Bugbear
- Posts: 833
- Joined: Thu Apr 15, 2010 7:42 am
- Location: Poznan, Poland
- x 33
Re: C interface as core feature
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.
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
http://www.sos.gd
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
I think I'll do a simplified (read: abstracted) interface first.
Example will be posted in a day or two.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Bugbear
- Posts: 833
- Joined: Thu Apr 15, 2010 7:42 am
- Location: Poznan, Poland
- x 33
-
- OGRE Moderator
- Posts: 3447
- Joined: Mon Jul 18, 2005 4:15 pm
- Location: Wales, UK
- x 58
Re: C interface as core feature
Jacmoe, you inspired me a little.
Took little effort to pull this off.
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.
Took little effort to pull this off.
Code: Select all
require_relative "NxOgreLib"
world = NxOgreLib::World.createWorld
world.advance(0.125)
NxOgreLib::World.destroyWorld
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.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
This is what I have at the moment:
The interface itself:
As you can see it's still in the very early stages..
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.
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();
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);
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Moderator
- Posts: 3447
- Joined: Mon Jul 18, 2005 4:15 pm
- Location: Wales, UK
- x 58
Re: C interface as core feature
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).
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.
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?
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
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
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?
-
- Bugbear
- Posts: 833
- Joined: Thu Apr 15, 2010 7:42 am
- Location: Poznan, Poland
- x 33
Re: C interface as core feature
I just LOVE the style of that code (apart from textureManager_setDefaultNumMipmaps, it just doesn't fit ) 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.
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
http://www.sos.gd
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
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.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: C interface as core feature
I think that any auto-generation would ruin such an interface - it would be a totally different thing.
Let's see..
Let's see..
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.