C interface as core feature

[jacmoe]

I think I'll take RPythonic for a spin, Hartsantler.

And probably use it as a base for this C interface thing.

[voyvf]

I think I'll take RPythonic for a spin, Hartsantler.

And probably use it as a base for this C interface thing.

Not certain if you've had any luck with RPythonic, but I've just cloned your repo here and added D2 bindings to LLCOI (and thus to OGRE and OIS) in a new "contrib" directory at the root of the project (wasn't sure where to put it, to be honest.) They've currently been tested using DMD 2.059 and DMD 2.060HEAD, but only using Linux as I don't have a Windows machine here.

I'm not sure how to issue a pull request via google code (I'm used to bitbucket and github) but you're more than welcome to include it in your project using LLCOI's license.

Thanks to everyone for all of their hard work.

[drwbns]

Out of curiousity, what's the status of this project?

[Houdini]

I'm curious as to the status of this project as well. I have already wrapped many of the Ogre classes into C functions for my Ogre3D port to GameMaker and I may be interested in contributing to this project. Wouldn't be too hard to write an app to rename my functions, etc, to change the interface to match an existing project.

- Houdini

[Mind Calamity]

I don't know what the status of the project is, but I recently tried running it with the latest version of OGRE, and there were no problems, it works perfectly fine. The wrapper doesn't wrap all of OGRE, though. So you'll need to wrap some functions you need yourselves. The project is perfectly fit for use as an example of using OGRE in C applications. (At least that's what I used it for )

[spacegaier]

And if anyone wants to extend the project best to contact jacmoe directly. Link to the repo is now in the first post of this thread.

[galaktor]

Just became aware of this.
I made some quick n dirty efforts to write a (non-pure) C-compatible wrapper for Ogre, so I can interop Ogre with golang.
See post here: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=71944

I'd hate to reinvent the wheel. I'm no expert C programmer, but if there is anything I can do to keep the ball rolling, let me know. Thanks to you guys for getting this going. I'll play with what's in the repo and see if it's better than what I hacked up (it probably is).

Some questions I mentioned in that other thread:

• does it compile to a single dll?
• what are the dependencies for building the wrapper? it shouldn't be more than the used ogre header files, yet from looking at CMakeLists.txt, it seems to be doing more
• can I link to it using just ogre_interface.h? that would be very convenient
• is it being used/maintained at all? Last checkin was March 2011...

[Mind Calamity]

• does it compile to a single dll?
  - Yes
• what are the dependencies for building the wrapper? it shouldn't be more than the used ogre header files, yet from looking at CMakeLists.txt, it seems to be doing more
  - OGRE only. There's an optional OIS alternative for input (for the test program) which is Allegro, but it's entirely optional, and the wrapper itself only needs OGRE.
• can I link to it using just ogre_interface.h? that would be very convenient
  - Yes, ois_interface.h is optional for using OIS for input.
• is it being used/maintained at all? Last checkin was March 2011...
  - It's achieved it's goal from what I can see: provide a basic C wrapper for OGRE. You can easily extend and modify this to fit your needs. (If it doesn't already.)

[galaktor]

sounds good.
I'll give it a spin soon.
The SWIG interface looks interesting, too.

[galaktor]

is there any intention to integrate the C interface into the core codebase to maintain it with the evolving cpp code?
Should be fairly trivial to do now that the bulk is there.

[CABAListic]

No, there isn't, at least not at the moment. Integrating it into the core codebase would basically equal a promise to keep it up to date, which is problematic, because far as I'm aware no core team member is currently invested in a working C wrapper. So this adds another responsibility when we already have a pretty ambitious roadmap towards 2.0.

Besides, for the most part I don't see much of a disadvantage in keeping it in a separate repository.

[galaktor]

I understand. The advantage that I see is pretty much that - it would always be up to date. I would think that given that the interface is fairly slim, keeping it up to date would be trivial when kept close to the actual Ogre code; having it separated from the Core code base means realizing that the interface changed X major versions ago, and would surely make it much more work to fix.

Currently it comes pretty much for free (it's already there and seems to work, according to some more recent posts in this thread). Letting it drift away would be a shame. And maybe it could morph into a more comprehensive C API for Ogre at some stage. The ground work seems solid.

Don't get me wrong, I appreciate that you guys are loaded with work and I'm grateful for Ogre as it is - but this appears to me as a relatively tiny bit of work compared to the very ambitious tasks on the roadmap.

[CABAListic]

Except it's not, because to keep it up to date it means that every developer would have to constantly verify that his changes / additions to the C++ codebase don't break or outdate the C wrapper. Otherwise the advantage is pretty much lost.
Given that personally I don't care for C at all, I'm really not looking forward to maintaining a C wrapper in that way, so for me at least it would be a burden. I'd much rather leave it in the capable hands of people actually interested in the wrapper.

Of course, we can happily endorse it officially if a group of people steps forward to maintain it. Links on the Ogre page etc., whatever you need.

[Nauk]

Great stuff, love the idea D2 and Ogre going to work without big headache soon ++ for the effort Jacmoe! Not sure if that has been posted yet and/or it makes sense at all, but not long ago I had a thought about rewriting the automated Mogre wrapper to do exactly that.

[voyvf]

Great stuff, love the idea D2 and Ogre going to work without big headache soon ++ for the effort Jacmoe! Not sure if that has been posted yet and/or it makes sense at all, but not long ago I had a thought about rewriting the automated Mogre wrapper to do exactly that.

I actually got D2 to cover a rather extensive amount of Ogre via my fork of the LLCOI code - the D2 wrapper is here, and my LLCOI fork is here. There's also a Bullet wrapper for C and D2 if you're feeling adventurous

That said, I haven't had much time lately to work on it. It's also only fair to note that I've found that using a C++ library via a C wrapper has one insanely annoying downside, in that if the C++ library throws an exception, you're toast, as the entire program will crash. This isn't so much Ogre's fault (or for that matter, any other library) but just that C doesn't play well with C++ exceptions - Boost.Python suffers from the same issue, as does LuaBind if I recall correctly.

[Nauk]

Great stuff, love the idea D2 and Ogre going to work without big headache soon ++ for the effort Jacmoe! Not sure if that has been posted yet and/or it makes sense at all, but not long ago I had a thought about rewriting the automated Mogre wrapper to do exactly that.

I actually got D2 to cover a rather extensive amount of Ogre via my fork of the LLCOI code - the D2 wrapper is here, and my LLCOI fork is here. There's also a Bullet wrapper for C and D2 if you're feeling adventurous

That said, I haven't had much time lately to work on it. It's also only fair to note that I've found that using a C++ library via a C wrapper has one insanely annoying downside, in that if the C++ library throws an exception, you're toast, as the entire program will crash. This isn't so much Ogre's fault (or for that matter, any other library) but just that C doesn't play well with C++ exceptions - Boost.Python suffers from the same issue, as does LuaBind if I recall correctly.

Awesome Offtopic, may I ask what tool chain you are using? - *Edit* Nevermind that question, I just read back and saw the post a bit further up.

[jacmoe]

This is sort of on the back burner - but not scrapped.
I think I want to take the Python powered C wrapper generator for a spin to see how it can help in producing a working set of C files.
At least before carrying on.
This project needs some loving care.

The main reasons for this project would be to generate C bindings for other languages, like Python, Lua, Lisp.

My stack of things to do is not currently in need of a C interface, but will soon (read: in 6 months time).

[jacmoe]

If people want to be added to the project, just drop me a PM, or message me on Bitbucket.

[jacmoe]

Which reminds me that I should move the project to Bitbucket RSN..

[galaktor]

I can't seem to get a hold of you (tried bitbucket, forum pm, llcoi issues...). I imported llcoi to Bitbucket, needed to get it working with ogre 1.8.
https://bitbucket.org/galaktor/llcoi/src

[jacmoe]

I am busy!

Add me to the project if you like - you beat me to moving the project to Bitbucket.

[galaktor]

I figured you're busy

I made you an admin on the project. Didn't mean to "beat you" though, just need to make changes and I prefer to do them in a collaborative/public manner. It's still your work, and it's helping me a lot.
Open source rocks.

Have a look at my (fairly minor) changes when you get a chance.

[galaktor]

update:
I integrated voyvf's repo into mine: https://bitbucket.org/galaktor/llcoi
The CMake build is probably broken (I compile using g++, without CMake), but otherwise it looks to be working fine and is quite extensive (thanks to Jeremy's work).
I'll continue to sanitize it a bit, there are quite a lot of inconsitencies at the moment (i.e. naming of functions, usage of handles/singletons, forward declarations etc).

[jacmoe]

I tried to follow a C/Python/Lisp naming convention - ie lower case underscore, like 'create_camera', etc.

Structs and function pointers would be one possible improvement, I think, for some things:
camera.rotate, etc.

I'll see about fixing the CMake build script when I get some time.

[galaktor]

I've no problem with the chosen convention (class_function_name works fine for me), but it's not consistently applied, that's all.

I was thinking the same wrt pseudo-classes using structs and func ptrs. I want to get what's there into a cleaner state and tag a 0.1 version, first.

If you could look at CMake that would be great - somehow me and CMake don't get along very well.