What I expect from Irrlicht 1.4

elvman · Post by **elvman** » Mon Aug 20, 2007 8:56 pm

I know that once somewhere in this forum was a thread like this, but I couldn't find it, so I made another one.
So what I expect from Irrlicht 1.4:

I expect function parameters to be const &. For example:
IGuiEditBox::setMax(const irr::s32& max);
1. When coding, user sees that the parameter is const, so that the value will not be changed
2. This code is faster because function doesn't make a local copy of the parameter
3. It is harder for user to mistype something
4. There are a lot of additional advantages which I will not discuss here.
I expect that finally I will not have to include the irrXML.cpp in my project, but the functions will be defined like createDeivce:
IRRLICHT_API IrrXMLReader* IRRCALLCONV createIrrXMLReader(const char* filename);
I hate wchar_t and a lot of programmers hate them too. Even big games and companies don't use them. They are so nasty, you always have to convert from char to wchar_t. Why does Irrlicht use them if there are such character encodings as UTF-8? It is not so hard to implement, but it would be much easier for developers to program with Irrlicht.
Finally - cubemaps! Where are they? That is not the hardest-to-implement feature and I don't beleave that nobody knows how to implement them. I could do this and almost all programmers here could, but I am sure no one will let us to do that (IrrSpintz is a great example)
A minor feature - password mask for edit boxes

You are welcome to post your thoughts and expectations of Irrlicht 1.4.

Klasker · Post by **Klasker** » Mon Aug 20, 2007 9:29 pm

Don't know why this is in Bug Reports - I think Open Discussion would have sufficed. Anyways, I'll contribute to the thread. Right after a comment on your post.

I expect function parameters to be const &. For example:
IGuiEditBox::setMax(const irr::s32& max);
1. When coding, user sees that the parameter is const, so that the value will not be changed
2. This code is faster because function doesn't make a local copy of the parameter
3. It is harder for user to mistype something
4. There are a lot of additional advantages which I will not discuss here.

I couldn't care less if the function changes its local copy of my argument. And if you declare it const & it will just create a pointer to the value instead of copying it; so if the argument is 32-bit or smaller there is no performance gain in using const &.

So here is my wishlist for 1.4.

Include the new animation system (goes without saying I guess).

Support for custom vertex types, 32-bit indices, and vertex attributes by adding the following methods to IVideoDriver. This is pretty easy to implement (at least in OpenGL), does not break backward compatibility, and it very flexible (decouples video driver from vertex types).

Code: Select all

// Sends vertex positions to the GPU
void sendVertexPositions(const core::vector3df* positions, s32 stride, s32 count);

// Overloaded for other coordinate types.
void sendVertexPositions(const core::vector2df* positions, s32 stride, s32 count);

// Sends vertex colors to the GPU.
void sendVertexColors(const video::SColor* colors, s32 stride, s32 count);
// Overload sendVertexColors with SColorf, too.

// Sends texture coordinates to the GPU.
void sendVertexTexCoords(const core::vector2df* texCoords, s32 index, s32 stride, s32 count);

// Sends vertex normals to the GPU.
void sendVertexNormals(const core::vector3f* normals, s32 stride, s32 count);

// Sends vector3df vertex attributes to the GPU.
void sendVertexAttributes(const core::stringc& name, const core::vector3f* pointer, s32 stride, s32 count);
// Overload that for every vector type; s32 and f32, matrix4, and SColor.

// Draws the vertices sent to the GPU.
void sendIndices(const u16* indices, s32 count);

// Overloaded with u32. 32-bit indices support without breaking API or 16-bit support :)
void sendIndices(const u32* indices, s32 count);

You don't need to remove the traditional drawIndexedTriangleList methods; you can just leave these methods for advanced users to begin with. I have used the exact same approach in an engine of my own and it works flawlessly.

Get rid of core::position2d. Use core::vector2d instead. I think this will cause issues with the core::rect constructor, but it will be worth it. core::position2d is just such a pain in the ass every time it comes up.

elvman · Post by **elvman** » Mon Aug 20, 2007 9:45 pm

Another feature, I believe, everybody is waiting is VBO's in OpenGL. Without them the performance of the OpenGL driver is sow low (FPS<3) tha I have to develop my game on Direct3D.

hybrid · Post by **hybrid** » Mon Aug 20, 2007 9:48 pm

Ok, I'll answer now, before my postings will become far too long...
Constifications will be done. The things that make the code faster is enhanced compiler optimizations. And the possibility to use constants in other places, too.
wchar_t will stay. Ever tried to develop a working UTF implementation? Why UTF-8, there are also UTF-16, UTF-32-LE and -BE, ... I guess there are as many people hating somee of those variants as there are people hating wchar_t. But in case you have a working implementation which does not cause massive memory usage we'll see...
Who would not allow cubemaps? You have a working implementation?
while I cannot promise that the new animation system goes into the next release - depends on feedback - it will be definitely included, it's almost done. But I'm pretty sure that the sending methods won't be part of 1.4, but maybe a later release.

CuteAlien · Post by **CuteAlien** » Tue Aug 21, 2007 8:13 am

elvman wrote:I know that once somewhere in this forum was a thread like this, but I couldn't find it, so I made another one.
So what I expect from Irrlicht 1.4:
I expect function parameters to be const &. For example:
IGuiEditBox::setMax(const irr::s32& max);

Bad example - for a s32 it wouldn't really offer any advantages, but would even have the disadvantage that you could no longer use constants. Besides that you're certainly right and like hybrid mentioned the team is working on that anyway.

elvman wrote: [*]I hate wchar_t and a lot of programmers hate them too. Even big games and companies don't use them. They are so nasty, you always have to convert from char to wchar_t. Why does Irrlicht use them if there are such character encodings as UTF-8? It is not so hard to implement, but it would be much easier for developers to program with Irrlicht.

I've worked in a few game companies and they used wchar_t's. They have disadvantages (mostly the different sizes on linux, windows) but I wouldn't like to work with UTF-8 in memory. That is a very good format for loading&saving text, but internally it's a lot easier to work with wchart_t's.

So the only thing that would certainly be nice would be a way to allow UTF-8 saving (loading partly works) in irrXML. And I suppose someone will write that some day (I have that on my wishlist for months, but also never found time for it so far).

elvman wrote: [*]A minor feature - password mask for edit boxes[/list]

Aggreed.

omar shaaban · Post by **omar shaaban** » Tue Aug 21, 2007 11:21 am

# I expect that finally I will not have to include the irrXML.cpp in my project
i agree on this!

JPulham · Post by **JPulham** » Tue Aug 21, 2007 12:11 pm

theres already a password box on the code snippets... maybe I should make a patch

I'll do that now I think

VBOs would be cool

GameDude · Post by **GameDude** » Tue Aug 21, 2007 3:45 pm

Does anyone have a rough guess of when 1.4 will be released?

rogerborg · Post by **rogerborg** » Thu Aug 23, 2007 10:41 pm

JPulham wrote:theres already a password box on the code snippets... maybe I should make a patch
I'll do that now I think

Don't bother; I've had a patch for that in the sourceforge tracker since 17th November 2006.

BlindSide · Post by **BlindSide** » Fri Aug 24, 2007 2:05 pm

rogerborg wrote:Providing a patch? Upload it to the tracker.

LOL @Your signature...

Btw.... what happened to that multi lighting patch of yours

Ok I will *wish* for some things from the Irrlicht fairy too

- Cubemaps, yes!
- Custom vertex types, yes!
- Can modify texcoords of vertices individually somehow! (Ok I think this is already possible so I will go give it a try first

)
- Hardware buffers, hardware skinning, multipass, multilighting.

We are not asking for hard out effects like HDR or whatever, simply the means to implement them (eg. floating point textures).

(PS this is all wishing, you dont have to reply.)

Cheers

JonLT · Post by **JonLT** » Fri Aug 24, 2007 4:07 pm

I think that a setEventRecievier method in the gui elements would be a usefull feature.
Or an useEventReceiver method in the event receiver.

hybrid · Post by **hybrid** » Fri Aug 24, 2007 5:18 pm

Now that SpotLights are supported we can think about a light manager again. This was just postponed until the LightSceneNode was finished. And it is now, besides making the Position and Direction private and friend of the drivers or something like that.

alexionne · Post by **alexionne** » Fri Aug 24, 2007 7:49 pm

I examined svn log of Irrlicht today, and what it seems is that there are number of bugfixes & improvements. So, what can we expect from 1.4 - much more stable version of Irrlicht. Good work, hybrid, bitplane, and others!

Except of new feature which usually introduce new bugs and incopatiblities

GameDude · Post by **GameDude** » Sun Aug 26, 2007 10:03 pm

Will the new animation system support the .blend file from blender?

hybrid · Post by **hybrid** » Sun Aug 26, 2007 10:06 pm

No, definitely not. .blender is no useful scene/mesh exchange format, it's merely a Blender-internal and use-only-for-Blender format. But blender features several good exporters which use interoperable file formats...

Irrlicht Engine

What I expect from Irrlicht 1.4

What I expect from Irrlicht 1.4

Re: What I expect from Irrlicht 1.4