Irrlicht module: first unofficial preview release

**ErosOlmi** · 05-05-2007, 07:36

Ken,

I'm not aware of the inner details, maybe Roberto will give you more details on Monday (he is out for 2 days).
What I know is that we always try to give functionalities easy to use and understand, al least we try. This means that many times a thinBasic function does what other languages do in many lines of code. The main reason is because thinBasic is an interpreter so the less lines of code, the better in terms of execution speed. But also because an interpreter must give results immediatelly with few lines of code because, as a user, if I'm working with an interpreter one of the reasons is that I want to see some results quite soon

Ciao
Eros

**kryton9** · 05-05-2007, 07:56

Yep, so far it is doing that Eros. I looked in the include file and there is a user type that has smgr, and other values returned from the device class to irrlicht. It seems Roberto combined numerous device returned values from methods within Device class and those values are either structures or classes themselves, I am not sure, but in thinBasic IRR, it knows how to handle each one by using the one pointer. SO it is neat coding that I can sort of see, but I don't understand and would like too. Will wait for Roberto to comment on it when he gets back.

Irrlicht has lots of what we need. Maybe Petr can get in with Roberto and make it happen. There is ODE and other physics engines that work with it, they have tools for creating levels and light maps. I guess we should not try to reinvent the wheel when such a nice one exists as irrlicht and Petr can evaluate it and tell us what it might still need.

To make games we need tools, and maybe we won't have to create so many as we thought if any now. I guess Petr and Roberto should go over what all will be in this new great addition and how we should proceed.

If you look at the irrlicht site, he has tools for xml, sound and many more things. I will do some reading tonight and brush up. I looked at irrlicht seriously a while back and liked what I read. Well will study it more in detail that is for sure now.

Petr chime with your thoughts as well as Mike and of course you too Eros and any other guys on the forums into this stuff.

**ErosOlmi** · 05-05-2007, 08:22

Ken,

please attention to not compare Petr work on TBGL with Roberto work with Irrlicht. They are compete different things not in competition.

TBGL is a OpenGL wrapper that let use OpenGL functionalities inside thinBasic. More, TBGL simplify and add unique fucntionalities to OpenGl allowing users to experiment with OpenGL in a quick and easy way but at the same time it remain very close to the main spirit and logic of OpenGL.

Irrlicht wrapper is another thing. It is a specific module wrapping a specific 3D engine specifically designed for games (and other aspects).
Of course with Irrlicht you will have a lot of new options because it is a 3rd party library used by many people that have developed a lot of material during those years. So, if your target is to try to create games, now you will have a new options.

As thinBasic developers, Roberto and I have to remain open to all opportunities. Roberto think that with Irrlicht module there is the possibility we will be able to bring more attention to thinBasic community. Well, I hope so especially because I know Roberto is a master in C and C++ development and because he wants to make a quite complete wrapper and not just few functions and equates. So, the more users here, the better for all of us I hope.

Ciao
Eros

**Michael Hartlef** · 05-05-2007, 09:08

Kent, Irrlicht is just the graphic part. There is no sound or physics or whatever. This stuff is added via other libs, that would need to be converted/modulized too.

**kryton9** · 05-05-2007, 21:12

Eros, I didn't mean my post that way if it sounded like that, sorry.

Mike, I thought once we had the irrlicht engine it could hook up to those modules, but I see now it can use them, but they still need to be converted. Thanks for pointing that out.

**RobertoBianchi** · 07-05-2007, 13:29

Hi Kryton9,

in order to handle multi device but in the same time keep easy the module use and speed up the calls I choose to create a structure that holds device, video driver, scene manager, GUI environment and event receiver and pass a pointer it during module API calls.
The side effect is that for each device you can have only one video driver, scene manager, GUI environment and event receiver, but actually this seems not be a limitation.
Please let me know what you think.

Regards,
Roberto