Page 1 of 1

More ideas for IrrCompileConfig.h

Posted: Fri Jan 30, 2009 8:35 pm
by Jacky_J
#define _IRR_COMPILE_WITH_ANIMATORS
#define _IRR_COMPILE_WITH_COLLISION
#define _IRR_COMPILE_WITH_SCENENODES
#define _IRR_COMPILE_WITH_SHADERS

#define _IRR_COMPILE_WITH_PAKREADER
#define _IRR_COMPILE_WITH_ZIPREADER
#define _IRR_COMPILE_WITH_XMLREADER
#define _IRR_COMPILE_WITH_XMLWRITER

All these could make irrlicht a swell 2D Engine. Of course the 2D would need some work, namely adding functions that support scaling/rotating (yes, i have seen patches in the forum for this, i'm talking about adding them to the irrlicht trunk)

Thoughts?

Posted: Fri Jan 30, 2009 10:26 pm
by sudi
why would i want to change irrlicht into a 2d engine????
just go with some real 2d engine really.

Posted: Fri Jan 30, 2009 10:54 pm
by Strong99
@Sudi well look at the tutorial 6 8)

But I also think like Sudi that for a real 2d engine you have to look further. Some more functions for images would be great although its still an 3d engine which uses 2d for textures and such. But it laks real 2d engine features not needed for the 3d engine (2d collisions, 2d scenenodes or something).

Re: More ideas for IrrCompileConfig.h

Posted: Fri Jan 30, 2009 11:36 pm
by bitplane
Jacky_J wrote:#define _IRR_COMPILE_WITH_ANIMATORS
#define _IRR_COMPILE_WITH_SCENENODES
Yes, it may make sense to have an option to compile without the default node and animator factories.
Jacky_J wrote:#define _IRR_COMPILE_WITH_COLLISION
This is also possible I guess, but most people would want at least picking, which would be impossible without the collision manager.
Jacky_J wrote:#define _IRR_COMPILE_WITH_SHADERS
I don't really see a point in this, it would make more sense to open the materials up to 2d drawing.
Jacky_J wrote:#define _IRR_COMPILE_WITH_ZIPREADER
This is already disabled if you compile without zlib.
Jacky_J wrote:#define _IRR_COMPILE_WITH_XMLREADER
#define _IRR_COMPILE_WITH_XMLWRITER
This would break scene loading and saving, gui loading and saving, the collada reader, and probably other stuff.

Thinking of ideas for IrrCompileConfig.h, it would be nice if we could split it into two parts, one to handle the user options and another to do the dependencies. Like how burning's renderer does it.

Posted: Sat Jan 31, 2009 6:53 pm
by Jacky_J
http://code.google.com/p/choria/

My choria irrlicht.dll is down to 1.0mb, but it could be a lot smaller if i took out all the unnecessary 3D stuff in irrlicht.

irrlicht has a decent GUI system, plus it comes with all the necessary window management (no need for something like SDL).

Do you know of any 2D engines that have the following all in one package?
- GUI System
- Texture management / texture splitting (for images > 512x512)
- Cross-platform
- Input handling
- Window management
- Font support
- zlib license

irrlicht is nice because it has all of that in one dll. It just needs a few more steps to be perfect for my needs.

@bitplane
If people use a physics engine, they would most likely use the engine's collision system, not irrlicht. (see irrlamb)

I don't need shader support in choria.

CZipReader.cpp still has most functions defined regardless of zlib.

adding those #defines would not hurt. You already some defines, why not more? It would just give people more options.

Posted: Sat Jan 31, 2009 7:43 pm
by grafikrobot
Jacky_J wrote:adding those #defines would not hurt. You already some defines, why not more? It would just give people more options.
Actually it does hurt. The more options there are, the more variables that need to be taken into consideration for testing and coding. Although I must admit I would like to add more of those options :-\ But something I would like to see before that happens is to split IrrCompileConfig.h into two headers. One for user options, and another for everything else. There are things in there now, like detecting the platform or (un)setting defines based on the options, that a user never needs to see.

Posted: Wed Feb 04, 2009 1:43 pm
by Mel
Nowadays, most of the 2D routines in graphics card are done entirely with polygons, and textures, it is simply faster to use polygons, you can rotate and scale them without the need of complex routines, aside the rendering ones.