What's new features for Irrlicht 1.6

FreakNigh · Post by **FreakNigh** » Thu Dec 18, 2008 4:49 am

That would be great, but have you ever heard of pthreads. I'm sure that could help you in the meantime.

Ya I do and they're not a solution because they are not native for windows.

Halifax · Post by **Halifax** » Thu Dec 18, 2008 4:54 am

FreakNigh wrote:
That would be great, but have you ever heard of pthreads. I'm sure that could help you in the meantime.
Ya I do and they're not a solution because they are not native for windows.

Could you use the Win32 API directly? It's almost a direct correlation to the pthread API, very easy to learn.

FreakNigh · Post by **FreakNigh** » Thu Dec 18, 2008 5:06 am

well I mean it's similar to saying why provide a delay function in irrlicht. Windows has Sleep() and linux has sleep(). It's just convenient to have one crossplatform function instead of seeking out another library or using #ifdef statements everywhere. But I agree with hybrid, wait for someone else to provide it like boost then i'm assuming just "steal" it.

I was just at work using irrlicht for a short crossplatform demo when I needed threads and thought to myself, damn now I have to get pthreads ... it'd be nice if irrlicht provided thread functions like SDL does.

Dorth · Post by **Dorth** » Thu Dec 18, 2008 7:02 am

Wyrmage, it was discussed, was a VERY hot topic, both side pretty much with daggers, a small majority in favor of refactoring, however, all brought to a moot point by a comment made by hybrid pretty similar to the one he made here, aka, for a patch to be included, it'd need to emulate the way irr::containers works instead of the other way around. Not being the only one to not want and do a useless half-baked solution, we let it rest until a major irr update would allow a compatibility break. I'm hoping whichever version will see threading appear or Dx8 or software renderers disappear will also be the one seeing the stl containers replace the irr ones.

hybrid · Post by **hybrid** » Thu Dec 18, 2008 8:18 am

Well, IMHO the one where SW renderers disappear could be the one for STL replace the Irrlicht containers. Because that would obviously a time where I would have left Irrlicht, otherwise the SW renderers will stay

Dorth · Post by **Dorth** » Thu Dec 18, 2008 8:21 am

Heh, then keep a close eye on rogerborg

But honestly, burning's one I can understand, but can't we do without the other one?

hybrid · Post by **hybrid** » Thu Dec 18, 2008 8:29 am

Well, if your time won't allow for any maintenance of either one of the SW renderers we'll accept that, but I guess everyone else is free to devote his spare time to the things he wants to do. This does hold true for the dev team members at least

Dorth · Post by **Dorth** » Thu Dec 18, 2008 8:40 am

But of course, but of course. As long as they don't delay new features or impair development for compatibility's sake, heh, I'm all for it. But that's actually the part I'm afraid of. What happen as the SW renderers start to fall more and more short of the HW ones?

hybrid · Post by **hybrid** » Thu Dec 18, 2008 9:14 am

Doesn't really matter, as it has inherent shortcomings. The actual number doesn't really matter, though it's nice to keep it small.

christianclavet · Post by **christianclavet** » Sun Dec 21, 2008 7:01 pm

Hi, Guys!

First, Congratulation on releasing 1.5! There's a huge list of improvement done you've done a wonderful work there.

Here is my wish list for the following versions:

- Axis Aligned billboards, (Ability to use them also as "Decals" on meshes)

- Impostors

- A Lightmanager

- Defining an upvector for the camera control animator (mouse/joystick/keyboard input coordinates could be aligned on a upvector)

- cubemaps, spheremaps (used as environnement reflections)

- Some kind of occlusion culling (Portals?). Using the current OCCTREE's system could serve for occlusion/portaling calculation...

- Mapping for international characters (So multilingual application could be made easily)

- Very nice to have an .obj saver.. Would also be nice in the future to have a animated mesh saver (.b3d saver?)

- zip file system, that could open encrypted zip. creation of zip archive, adding files to a zip filesystem, etc. Function to retrieve the list of drives from a system (would be nice for our filerequester to have a specific list of drives)

- Little demos showing the new features implementations (could re-use the same assets to keep the IRRlicht distribution small), could made folder structure with each version features demos (1.4 ,1.5 ,1.6 etc.)

- Function to scale a mesh and it meshbuffer version so the collisions are still working properly

matgaw · Post by **matgaw** » Sun Dec 21, 2008 9:06 pm

christianclavet wrote:- zip file system, that could open encrypted zip. creation of zip archive, adding files to a zip filesystem, etc. Function to retrieve the list of drives from a system (would be nice for our filerequester to have a specific list of drives)

Or at least addZipFileArchive which could use the IReadFile* instead of string with name. This would allow to load the file manually into memory, decrypting it in any chosen way and then createMemoryReadFile from this.

Also, FileSaveDialog would be a nice, still missing, feature.

MasterGod · Post by **MasterGod** » Sun Dec 21, 2008 10:27 pm

How about adding the famous Grid Scene Node into the lib?

Editor style Grid SceneNode [Updated: Oct. 23, 2008]

Halan · Post by **Halan** » Sun Dec 21, 2008 11:24 pm

Static Text supporting a scrollbar would be nice if the text is bigger than the field.

kburkhart84 · Post by **kburkhart84** » Wed Dec 24, 2008 9:23 pm

I honestly would like to see the particle system addons by Dark_Kilauea added. I know we can use these regardless, but it would be something useful for a lot of people.

We also need work done on the art pipeline. I think we all have had trouble getting a good animated mesh out of our favorite program and into Irrlicht without a hitch. As of now, I saw the beginnings of an irrmesh format, which may or may not be a good solution. I don't think we have to have our own format, rather a good one with a good exporter from the modelling programs. I recommend the .x or .b3d formats since those appear to support the most options and also happen to be the closest to completion formats for Irrlicht at the time. The idea of the irrmesh is not so bad, but it would be less work to use a format that is already created.

I would also like improvements to the animation system. If we want to blend animations right now, we have to have two different meshes, animate each separately, then directly modify the bones on one from the other, manually combining the animations. I know this would take some work, which I don't think I'd have the capability to do, but it would be worth it for almost any game genre.

twilight17 · Post by **twilight17** » Wed Dec 24, 2008 11:37 pm

I agree with kburkhart84, we should have at least 1 format that's completely supported, be it irrmesh or .x (or any other format). Irrlicht's current support is iffy. You have to go through trial and error to find a format that works for your needs.