World: r3wp

Benjamin's COM lib

Max said "with callbacks (devices?), there is no need to keep bugging 
Carl about A LOT of things people keep complaining about.  :-)" - 
my question is - how callbacks/devices allow you to plug-in different 
scenarios into REBOL?


Let's take multimedia timers for e.g. AFAIK, events are part of Host 
code, not a device. So how can you e.g. create device, which allows 
you to replace inbuilt timers?


OK, maybe timers are not good example. We have networking being done 
as a device. Can you easily replace REBOL's built in networking device 
with your own one, to try some different networking aproach for e.g.?

Hmm, events seems to be implemented as Device model too? http://www.rebol.net/r3blogs/0084.html

yes... the DLL will trigger code based on how its hooked into the 
OS.... so if you used multimedia timers, they will trigger when you 
ask them to.  if we have callbacks, then Rebol code can be run as 
a consequence of that trigger.


tcp sockets use triggers to tell you when connection, data, etc occurs... 
you could very well use C sockets directly by opening a lib and calling 
its funcs... I don't know if the fact that the rebol task already 
opens up a tcp socket lib would cause some interference, its quite 
possible that it would work.


DB drivers often use callbacks for the "response" aspect of DB requests 
since most well designed DB interfaces should be async.


Events & callbacks simply allow applications to live in the wait... 
and be asynchronous in nature.  its the "better" model since it means 
the task is never busy waiting.  There is a large effort in the linux 
world to make every app behave "properly" in this regard, and its 
a good thing... if every app is silently waiting on triggers, the 
whole system has a significant boost in responsiveness.

the OpenGL,  GLut lib, for example, has its own windowing system. 
 so any application can VERY easily create OpenGL apps which respond 
to keyboard mouse and window events.  its ported on all OS, so your 
code runs just about the same everywhere.


If R3 had callbacks, my OGL GLass engine will be ported to all platforms 
without any extra effort.


GLut might not have all the fancy events (I haven't gone over it 
in detail) but its a good basis to develop, being so easy to use.

callbacks are also required for any serious windows api programming, 
so many systems use them.  timers, gui, disk, low-level gfx.

(oops strike disk from that list)

btw the capacity to open tcp sockets directly in C must be available 
in R3 extensions... I don't see why it would'nt work, but some systems 
require very specific TCP settings... one example is that the various 
buffers used can have drastic effects on performance in some circumstances 
and platforms.

ComLib: Using it quite often to control XLS. I hope to find the time 
to bite-the-bullet and givetti a try with a R3 extension. The current 
ComLib is good but fragile.

Overall R3 should have a /Library interface. IMO adding a way to 
Rebol so that more c-ish datatype can be handled would make life 
a lot easier. And of course, provide a way to handle callbacks. Maybe 
via a proxy stub on the C side that transforms these callbacks to 
TCP socket requests.

yet another possible target for extension integration  :-)

http://www.ogre3d.org/

and its licensing is switching to MIT  :-)

I actually will give this engine a look, its ported to all 3 platforms, 
and can render over OGL OR Direct3D which is pretty nice.

it even has an iphone port  :-) this is starting to be really interesting.

OMG... its HUGE!

(http://www.ogre3d.org/docs/api/html/hierarchy.html)  but extremely 
well documented...

the most interesting feature: "Currently OGRE runs on Windows, Linux 
and Mac OSX using plugins to drive the underlying rendering API (currently 
Direct3D or OpenGL). Applications use OGRE at the abstract level, 
thus ensuring that they automatically operate on all platforms and 
rendering subsystems that OGRE provides without any need for platform 
or API specific code."


and its open source, and the quality of graphics is quite impressive.

Interesting question on R3 Chat - is it possible to transfer opened 
file handle from REBOL to extension, or does file have to be reopened 
in extension and worked on from there?

maxim yeah like the name said it's an ogre

Ogre3D is the probably the best open source 3d rendering engine there 
is .. I followed it's path a long time..  his simpler "follower" 
is irrlicht .. maybe there are some new ones now I am not sure , 
since I am not actively following this area any more

http://www.devmaster.net/engines/

Maybe OpenAL and OpenCL could get extensions too.

like this one ... it seemed very intreresting and with pure c interface 
so it's meant for embedding 

http://www.horde3d.org/

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

can Extension output e.g. its image/video buffer into View face?

not now, but it will when the image! datatype is supported (in next 
extensions update).  This is the easiest way to integrate image applications 
into rebol, but also the slowest.

for video, I'm not sure... it would have to use callbacks, cause 
the synchronisations and refresh stuff is so complicated.  But maybe 
we could be able to open up ActiveX or other supported OS controls 
which can render directly within window rasters, as long as the host 
code knows how to link them into their windows.

so some changes in the view engine would have to be done for FMV 
to be added natively in its windows AFAIK.

horde doesn't offer all of what I need for the quality.

I'm also thinking that I could build a flat C SDK for Ogre which 
would make its integration into R3 much simpler after... basically 
storing stucts and pointers to things internally and using a few 
simple and fast generic scene query calls.

yes, ogre is really "topnothch" .. maybe you could reuse, maybe the 
ones who made python/lua/... bindings already made a c overlay

ah good idea.. will see their approach as a reference for mine.

so far, the way I understand it, its possible that callbacks aren't 
necessary for Ogre.  Not for simple scene creation and interaction 
AFAICT.

there are at least python / java / .NET / lua bindings that I am 
aware of .. making something like python-ogre for rebol would be 
awesome

but also quite a task .. maybe you could geenrate rebol binding or 
part of it from some othe binding programatically .. I know some 
folks did something like that for GTK / WxWidgets from haskell to 
ocaml

and the actuall download isn't insane... it ~45MB.  for a full-featured 
cutting-edge 3D engine this is very small.  We have to remember that 
3D and image aren't just functions, they actually require data which, 
because of the array aspect of them, requires a lot of memory... 
so I am thinking that a large part of the 45MB is in fact source 
data which is needed, in order to populate the actual scene.

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

very cool, as I said this is not a minor task but if you do it it 
will be very awesome!

I Will, I need it  :-)

what will you be making?

ElixirOS and some other commercial stuff which needs serious scalable 
views rendering tens of thousands of objects in real-time.

the first piece of the cake is building GLASS with whatever 3D engine 
I can extension.

GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.

I

Max

(Oops).  Max, I experimented with OGRE in Purebasic a few years ago. 
 Frederic Laboureur built a very nice interface to it, which comes 
built in native to Purebasic.  He'd likely be a good person to chat 
with, and he's very active on the purebasic forums...

noted  :-)  I'm starting to really look into this right now... taking 
a break from my "serious" programming.

will start by playing around with the C++ stuff, basically building 
a simple scene.... when that is working, I'll try to build an extension, 
allowing me to do the same calls via R3

btw, some of the picks from apps make with Ogre are damned beautifull!