C interface as core feature

[jacmoe]

@Zonder:
It's good to know that we're not the only mad people here.
Wrapping Ogre by hand is actually not that crazy.
As So0os says:
The goal is to create a binding you'd actually enjoy using by itself.

I think all lowercase and underscore (instead of PascalCase or camelCase) is more C-like.
And - important to me - it makes it look a lot like Lisp.
One of the reasons why I wanted to do this was to be able to use Ogre from Lisp/Scheme.
Like this (in Scheme):

Code: Select all

(set! *light-node* (ogre:create-scene-node "light-node"))

[syedhs]

I like Camera_setNearClipDistance better. My feel good factor could be different, but my feel good is this: I should always be able to guess the corresponding Ogre-C function provided I know the class name and the method. And underscore should only be used to separate class and function name, so that means there should be only 1 underscore per function.

[jacmoe]

We're trying to be a C interface.
But, I know that it's a matter of taste.

SDL uses caps prefix and pascal case:

Code: Select all

SDL_CreateRGBSurface

Most (old school) C code uses all lower case with underscore, though.
Allegro:

Code: Select all

   al_clear_to_color(al_map_rgb(0,0,0));
   al_flip_display();
   al_rest(10.0);
   al_destroy_display(display);

What's easier to read ?
This->

Code: Select all

sdl_create_rgb_surface

Or this?->

Code: Select all

SDL_CreateRGBSurface

It's Camera_setNearClipDistance versus camera_set_near_clip_distance.
A matter of taste.
But interesting.

I think if the interface is kept consistent, it doesn't really matter.

underscore should only be used to separate class and function name, so that means there should be only 1 underscore per function.

Since there is no notion of the concept of 'Class' in C that would be an alien rule.
At that level, it's only functions, structs and void pointers.

[jacmoe]

Boost, STL and PHP uses underscores. thats_just_so_much_easier_to_read, compared to camelCaseInMyHumbleOpinion.
But there's pro's and con's:
http://www.codeproject.com/Articles/697 ... ntion.aspx
IMO, it's a refreshing breath of fresh air from the coding style we all know and love: Ogre3D code.

[jacmoe]

I found the article I should have linked to in the first place:
camel_case_sucks

If you want it all, go Lisp!
this-is-also-a-lot-easier-to-type than this_which_requires_you_to_hold_down_shift..

[so0os]

Yes, underscores are future!

Also, I agree with jacmoe. Trying to make C programmers imagine they are using classes is not a good idea. We will be consistent in the approach, which hopefully will create a consistent enviroment to work with ogre_3d without classes.

[so0os]

I added FrameListener binding today. I was thinking how to solve having 3 event in one listener and came up with that:

Code: Select all

void add_frame_listener(FrameListenerEvent frame_event,int frame_event_type);

where FrameListenerEvent is a function taking (float time_since_last_event,float time_since_last_frame,int event_type).
frame_event_typeis a bitmask, so you can have one function listening to three events
Also, it doesn't return a handle, since functions are statically based in C, so to remove a frame listener, simply pass the function to remove_frame_listener

I was thinking of getting rid of the silly time_since_last_event thingie, since I've never found myself using it, but someone might have, and it doesn't hurt having it, does it?

I'll try and hook up doxygen tommorow.

[Zonder]

It is better by hand imo as well I did consider writing a generator at the time but you can make things alot nicer by hand.

The only reason for the class_function naming and casing is it copied ogres so you could reliably look at the ogre api docs to use the method. The ctor bit yes I agree using Camera_Create / Camera_Destroy would be alot nicer.

On the pro/con camel / pascal / _ / - or what ever you like...... I just go with the flow

It was a shame I lost the stuff I had covered quite a bit you could do most things fine, I got quite a few samples going. (Yes I forgot to backup HDD died, everything on RAID 5 now )

I was the one who originally asked for the renderoneframe because of the api nature, using a callback was not a good idea in a C style API as you can't guarentee the language accessing the API could handle it. Also some people like more control like in editing apps

[jacmoe]

Nice work, So0os!

I just got Allegro window and input working on Windows.
Works a treat.
I will test it back in Linux, but there should be minimal changes between them.

[so0os]

Thanks

It's all starting to shape pretty well. Also, I think allegro guys would be interested in that too!

[jacmoe]

I got it working.
Unfortunately, since Allegro is handling the window, and Ogre doesn't have any concept of a parent window in fullscreen mode, it means that we can never leave windowed mode - which is bad.
We need input which takes the device context instead of managing the window.

[so0os]

CAn't it be done the other way round? create windows with ogre and let allegro use it?

[Wolfmanfx]

What is with external window?

[jacmoe]

I am going to take OpenInput for a spin.
And then, just bite the bullet and port OIS - or rewrite it in C. (It's basically just wrapping C code anyway..)
OpenInput hasn't been updated in 3 years, but so what?
Input hasn't really changed much.

I think it's silly to rely on beasts like Allegro (nice beast none the less) or SDL when all we really need is input for the samples (sounds familiar? )

The only bad thing about OpenInput (aside from the fact that it's not maintained) is the license.. But SDL is just as bad.
Allegro is nice, but they still don't have the option of passing it a window handle.

Code: Select all

    // Placeholder for the event
    oi_event ev;
    // Initialise
    oi_init("c:0 s:0 w:0", OI_FLAG_NOWINDOW);
    // Wait for an event
    oi_events_wait(&ev);
    // Print something to the screen
    printf("Hello OpenInput event!\n");
    // Cleanup after ourselves
    oi_close();  

And giving it the window handle is easy:

Code: Select all

HWND hwnd;
char hook[40];
hwnd = CreateWindow("Hello OpenInput", ..., ...);
sprintf(hook, "c:0 s:0 w:%u", (unsigned int)hwnd);
oi_init(hook, 0);

If it's not too horrible, I'll rather use that instead of the 'monsters'.

[syedhs]

Trying to make C programmers imagine they are using classes is not a good idea. We will be consistent in the approach, which hopefully will create a consistent enviroment to work with ogre_3d without classes.

Well we can tell the C programmer that it is object we are talking about. Specifically, the object is camera and then corresponding action on it is setNearClipDistance, which to me is pretty neat. But yes I agree it is a matter of taste.

[jacmoe]

It's almost the same now anyway, except not using camelCase:

Code: Select all

camera_set_near_clip_distance(handle, distance);

I think that's acceptable.

About OpenInput: it actually builds on Windows, so now I am going to build it on Linux with CMake.
I'll probably produce a working OpenInput driven llcoi demo in a couple hours.

[betajaen]

What about?

Code: Select all

void set_camera_near_clip_distance(handle, distance);

[jacmoe]

Allegro has been replaced by OpenInput which is much, much more lightweight.
Works in windowed and fullscreen modes.
Need to test in Windows, but I can't see any reason why it shouldn't.

[jacmoe]

OpenInput code looks like:

Code: Select all

// After Ogre is fully initialised and ready to render, tell OpenInput to use the window
#if defined(PLATFORM_LINUX)
    disp = XOpenDisplay( NULL );
    scrn = DefaultScreen(disp);
    sprintf(openinput_window_params, "c:%u s:%u w:%u", (unsigned int)disp, (unsigned int)scrn, windowHnd);
#else
    sprintf(openinput_window_params, "c:%u s:%u w:%u", 0, 0, windowHnd);
#endif
    
    oi_init(openinput_window_params, 0);
    
    //render_loop();
    while (keep_going)
    {
        // ask oi to wait for events
        oi_events_poll(&evt);
        switch(evt.type)
        {
            case OI_QUIT:
                // Quit
                keep_going = 0;
                break;

            case OI_KEYDOWN:
                // Keyboard button down
                keep_going = 0;
                break;

            default:
                break;
        }
        // Pump window messages for nice behaviour
        pump_messages();
        // Render a frame
        render_one_frame();

        if (render_window_closed())
        {
            keep_going = 0;
        }
    }

    oi_close();

[so0os]

What about?

Code: Select all

void set_camera_near_clip_distance(handle, distance);

i thought set_near_clip_distance, it's pretty obvious it's not anything but a camera we're talking about.

Also, allegro 4.4 can use external window handle AND handle input without a window, I succesfully used it alongside Ogre3D handling input and rendering to texture. I'll try to hook it up later this evening (since it's friday).

It's like this:

Code: Select all

      allegro_init();
      install_timer();
      install_keyboard();
// win
      win_set_window(HWND hwnd);
// linux
      xwin_set_window_name(const char *name, const char *group);
// macos ???

Also, I find it pretty hard to keep up your pace, jacmoe. I hope I won't slow things down.

[jacmoe]

I just committed FindALLEGRO and FindOPENINPUT so that we can choose which one to use. Allegro is on by default, otherwise OpenInput is used. (For the demo).
Don't worry about not keeping up - I really appreciate not being the only one in the project.
Didn't take you long to cook up the framelistener.
I would probably have committed something far less useful in longer time.

I'll see if I can get Allegro 4.2 (installed it by my Linux Mint package manager) going on Linux - feel free to hook it up on Windows.

[jacmoe]

I am not too keen on Allegro input actually: http://www.allegro.cc/forums/thread/605430
They simply don't understand why you'd use it without a window.
So OpenInput will be the default, but you can switch to Allegro by means of a CMake flag.
Since OpenInput is basically a rip-off of SDL_Input, *someone* could actually rip off the Allegro input so that it becomes standalone.
What's good about Allegro is that tons of people know about it - OpenInput has zero users (or so it seems).

/* Enough plogging already - back to work. */

[jacmoe]

Also, allegro 4.4 can use external window handle AND handle input without a window, I succesfully used it alongside Ogre3D handling input and rendering to texture. I'll try to hook it up later this evening (since it's friday).

Did you try that on Linux?

[so0os]

Did you try that on Linux?

Nah, I'm a strict windows guy

[voyvf]

Wrapping Ogre by hand is actually not that crazy.

It's not crazy, but I know for a fact that it is quite time consuming (even when you have a good support library available.)

For example - and I know LOC isn't the best metric - this is what I've got from a partial wrapping of Ogre:

Code: Select all

devbook:~/Desktop/repos/hg/python_ogre_bindings$ sloccount src/ogre_python_bindings/* include/ogre_python_bindings/*

Categorizing files.
Finding a working MD5 command....
Found a working MD5 command.
Computing results.

SLOC	Directory	SLOC-by-Language (Sorted)
3748    top_dir         cpp=3748

Totals grouped by language (dominant language first):
cpp:           3748 (100.00%)

Total Physical Source Lines of Code (SLOC)                = 3,748
Development Effort Estimate, Person-Years (Person-Months) = 0.80 (9.61)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.49 (5.91)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 1.63
Total Estimated Cost to Develop                           = $ 108,176
 (average salary = $56,286/year, overhead = 2.40).

Generated using David A. Wheeler's 'SLOCCount'.

My fingers can still feel each and every enum.

So yes, a C interface that can then be used as a base for $LANGUAGE_X would be awesome.