#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?
More ideas for IrrCompileConfig.h
why would i want to change irrlicht into a 2d engine????
just go with some real 2d engine really.
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.
@Sudi well look at the tutorial 6
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).
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).
Compete or join in irrlichts monthly screenshot competition!
Blog/site: http://rex.4vandorp.eu
Company: http://www.islandworks.eu/, InCourse
Twitter: @strong99
Blog/site: http://rex.4vandorp.eu
Company: http://www.islandworks.eu/, InCourse
Twitter: @strong99
Re: More ideas for IrrCompileConfig.h
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_ANIMATORS
#define _IRR_COMPILE_WITH_SCENENODES
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_COLLISION
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_SHADERS
This is already disabled if you compile without zlib.Jacky_J wrote:#define _IRR_COMPILE_WITH_ZIPREADER
This would break scene loading and saving, gui loading and saving, the collada reader, and probably other stuff.Jacky_J wrote:#define _IRR_COMPILE_WITH_XMLREADER
#define _IRR_COMPILE_WITH_XMLWRITER
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.
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.
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.
-
- Posts: 44
- Joined: Wed Dec 26, 2007 11:42 pm
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.Jacky_J wrote:adding those #defines would not hurt. You already some defines, why not more? It would just give people more options.
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