More ideas for IrrCompileConfig.h

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
Jacky_J
Posts: 55
Joined: Fri Apr 27, 2007 5:01 am

More ideas for IrrCompileConfig.h

Post 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?
sudi
Posts: 1686
Joined: Fri Aug 26, 2005 8:38 pm

Post by sudi »

why would i want to change irrlicht into a 2d engine????
just go with some real 2d engine really.
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
Strong99
Admin
Posts: 687
Joined: Fri Mar 31, 2006 7:06 pm
Location: Netherlands
Contact:

Post 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).
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Re: More ideas for IrrCompileConfig.h

Post 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.
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
Jacky_J
Posts: 55
Joined: Fri Apr 27, 2007 5:01 am

Post 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.
grafikrobot
Posts: 44
Joined: Wed Dec 26, 2007 11:42 pm

Post 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.
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Post 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.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Post Reply