Horde3D

hello,

I would use Horde with F-Script on OSX ... basically what is needed is to rewrite opengl windowing and context-creating code and then those class-wrappers in obj-C around the Horde-API. F-Script can operate on cocoa-objects ( both class nad instance) and is a smalltalk variant.

Is anybody doing a mac port ? Or should I try it myself.

Hello,

several people already had the idea to do a port but I am not aware of any which has been realized up to now. Actually porting the engine shouldn't be too hard since most of the code is pretty standard. I would really appreciate if you want to give it a try.

The Mac port is complete, and available from here. Testing and bug reporting would be most welcome...

As far as window/context creation, Horde doesn't have any, and leaves that up to the client app. In the samples, SDL is used for this, but it is perfectly feasible to do this with Cocoa instead. If you need any help with this, drop me a line - I am considering working up a Cocoa-integration sample to be included in the Mac SDK.

Great, good work!

Quai has quickly tested the binary Knight sample and it seemed to run correctly!



There is a utility function to init OpenGL but it still has to be ported to Mac and Linux (currently it is Windows only).

That particular function doesn't make much sense on the Mac, which has no similar concept of Window Handles (and a great number of different windowing frameworks).

Really niiice to have osx -fraemwork here now ...

I just start tinkering where to start with wrapper code to build cocoa objects with obj-C++ .
One choice is this App - class which basically communicates with the Horde egMain-object - to be obj-C++ I guess. But even better would be to have that egMain class ( and maybe Main for Horde Utils functions) -which exports the engine interface - to be itself a cocoa-object too ??? Then App-class to define the application would be already pure obj-C (and model object in MVC-paradigm)

That would reduce the overhead.

In order to use F-script there has to be cocoa-object which wraps horde interface.

SDL is a matter of choice - instead of main there can be MVC-stuff where controller mediates instantiate context and NSOpenGL events to horde ...

To start with -only the ability to have a scene with boxes and textures is needed

Any suggestions ?

It has been a while since I used Cocoa, so bear with me

To start with, you will want to create a custom subclass of NSView, which sets up an OpenGL context, and then initialises Horde in the init method. This needs to be an Objective-C++ class to access Horde, so it needs the file extension '.mm'.
Then you need to override the drawRect: method to make the view's OpenGL context current, and then call Horde3D::render().

That is enough to use Horde from Objective-C++, but if you want to use more features - or use it from FScript - then you will have to create a singleton wrapper class for the Horde API. This isn't too hard, but if you are having trouble, I can whip a basic one together in a few days.

If you don't want FScript, you might want a plain C wrapper instead, for performance.

Why do I have to call Horde::render ? if I call makecurrent fo OGL-context in drawrect?
I thought Horde::render is event driven ..and called internally in the engine also.

If I understood correctly Horde is singleton because it is the interface to client.

The less c++ the better - obj-C++ is THE gluecode to instantiate new cocoa-object-interface for Horde. The final goal is to use maximally F-Script and minimally obj-C++.

Otherway round Horde does not have scripting layer so why not F-Script in OSX platform?

My wish eventually is to have a special design language for architecture with F-Script.Something similar than GL-scripts are for ArchiCAD but with focus to define the whole scene and how geometry-primitives relate to each other.

By the way with F-Script any of the OSX framework is accessible.

Not quite - you need to make sure that the right openGL context is in place, and then tell Horde to render.


Yes, but you will have to use Objective-C++ to create an Objective-C wrapper around the Horde API, and this wrapper will have to be a singleton Objective-C class.

There seems to be in Knight sample in the application client that mainloop(fps) where Horde:render is called for every fps or timetick. mainLoop() is called until the program is running.

In OSX cocoa side it may be that this explicit loop ( while running) is not needed at all because the NSOpenGLView or controller has it build update mechanism?

This drawRect of NSOpenGL is called for example always when the window is resized and then Horde:render is indeed inevitable.

So - either having the Horde:render in some explicit loop or calling it from cocoa based overridden event-method like drawRect.

Ah, the App class from the samples. You could reuse this, but since you want Objective-C, etc. I would just ignore this and use Horde directly (as I am doing).


Horde::render() has to be called from within drawRect:, to allow the AppKit to setup the contexts. You can however call the 'display' method on the view as often as you like to redraw (hook this up to a timer to approximate a loop setup).

Just that

The Application class in the examples has the client role but I think for cocoa side this could be the document based obj-C++ glue .In addition to that we need cocoa controller which mediates the events fro view to Horde and NSOpenGlView for use rinterface.

have to decide if this Horde:render() is called also from controller. First of all is has to be wrapped -preferably in that glue class (singleton) where the essential part of the hoder interface is wrapped.

Would be nice to have controller and view pure cocoa classes.

I think you may be taking the MVC paradigm a little too literally, but that is entirely up to you

As a renderer, Horde belongs exclusively in the view layer of MVC, and as such you can derive an NSView subclass called Horde3DView that handles all the Horde interactions.

By restricting Horde to the view layer, you also have no need for the NodeAttachment class (which would be a right pain to bind across the Objective-C++ bridge), as all information flows in the opposite direction (i.e. from the model and controller to the view).