separated Irrlicht suggestion

[Emil_halim]

just a thought, if we separate the engine or divide it inot 3 patr, one for Directx9,
one for DirectX8 , and the final for OpenGl.so if i prefer directx9 then i will use
the one that for Dx9 and so on...,so i have not to restricted to particular one.and
the engine will be more samll in size.

what is the point here to mix all in one.

it is just my own opinion.

[Guest]

Well, I suppose you could already do that by compiling Irrlicht on your own.
I don't know if there are some standard #defines that you can do to build the engine with only support for the 3D API you want.

The point behind including all three is that you give the user the choice. If you want to use D3D9, you'll restrict users to using D3D9 compatible 3D cards. Older cards won't do. And even in D3D8 mode the frame rate is likely to be higher. OpenGL may work better on a user's computer.

If the engine was split (presumably still using the same sources, but split into separate dlls), it would be one hell of a task to combine them again for people who do want to give their users the choice.

[Emil_halim]

The point behind including all three is that you give the user the choice. If you want to use D3D9, you'll restrict users to using D3D9 compatible 3D cards. Older cards won't do. And even in D3D8 mode the frame rate is likely to be higher. OpenGL may work better on a user's computer.

If the engine was split (presumably still using the same sources, but split into separate dlls), it would be one hell of a task to combine them again for people who do want to give their users the choice.

but when we split it into 3 DLL,the choice still existes so the user could
chose which one he wants to use.

when we do that, what is the reason to join them again,you could provide
the 3 DLL in the same zip file.

another point,i think if we split the engine it will wrok faster .

[hybrid]

but when we split it into 3 DLL,the choice still existes so the user could
chose which one he wants to use.

when we do that, what is the reason to join them again,you could provide
the 3 DLL in the same zip file.

another point,i think if we split the engine it will wrok faster.

If there are three libraries you won't be able to include all three into one app due to lots of shared code. This would be a major problem for app designer - they would have to provide three apps.
And the engine will not run faster, only when loading the dll it could be faster, and when branching depending on the chosen driver. But you won't notice the difference, it's maybe a dozen cycles you will save each frame.

[Emil_halim]

why you have to include the 3 DLL in one app, it is so simple, you make your application
(the exe file) then you offer the DLL separatly so the usr will decide which one he want,
and in the view point of designer ,he will write one code that will work with any one of
DLL,as he does now,he will not have to write 3 application for each dll no only one application,and i think that in a real game the designer will need to save each cycles of
processing for make a smooth game.

any way that was my own opinion.

[Joe_Oliveri]

but when we split it into 3 DLL,the choice still existes so the user could
chose which one he wants to use.

when we do that, what is the reason to join them again,you could provide
the 3 DLL in the same zip file.

another point,i think if we split the engine it will wrok faster .

If you place 3 DLL files compiled seperatly in to the ZIP it will end up being more work for you. Rember not everything work corrently in a ZIP file. Also the size of 3DLL's would be greater then 1 so that defeats the whole idea.

[katoun]

Hey people , take a look at OGRE.
It has the diferent drivers separate in 3 dll and the programer can choose witch one he want for doing that you must export CVideoDirectx8 in saparate dll as well as DirectX9 and Opengl and you must have an other dll (logicaly Irrlicht.dll) witch is the base and includes all other dlls an initializes the Device hold the Scenemanager bla.bla bla...
Now thinking it is not that dificult as it seems and it would be mucht beter somthing like in a config file specify with of those you want to be linked(ex. #pragma comment(lib,"CVideoDirectX8.lib") ) and went you call CreateDevice(
videodriver=.......) you can chose one of those.

[katoun]

Hey like that we can add more plugins to Irrlicht:
In the include directory we hav the base of the
engine(math.h,ISceneManager.h.....) witch specifies abstract classe
defining the standard form for the classses.
And outside the Irrlicht.dll we can ad a new dll that has for instance a new ParticleSistem and we call a function in Irrlicht.dll to ad that Plugin and so we can use that new PrticleSistem.:D:D

Pesonaly I think this would be a very wize think to do cause we wount have to recompile Irrlicht.dll to just add lets say MD3 loader.

[Emil_halim]

this is what i want, and think about that , why i have to keep a code that i will not use
it in the DLL Engine.so if i will use DX9 why i have to load code for DX8 and OpenGL.

[MikeR]

If you want it that way, just make it.
Personally, I prefer Irrlicht the way it is. I can set which driver I want in my main.

[hybrid]

why you have to include the 3 DLL in one app, it is so simple, you make your application
(the exe file) then you offer the DLL separatly so the usr will decide which one he want,
and in the view point of designer ,he will write one code that will work with any one of
DLL,as he does now,he will not have to write 3 application for each dll no only one application,and i think that in a real game the designer will need to save each cycles of
processing for make a smooth game.

any way that was my own opinion.

Ok, maybe my text was a little too short to get all details. So in case you put #ifdefs into Irrlicht to be able to strip some driver, you could create three libraries which allow to use either DX8, DX9 or OpenGL. But you cannot link all three to one app because they share lots of code and thus a large number of common symbols. If you want to let the user choose on startup and load the library only upon choice you would have to fight with dynamic loading - definitely not nice.
The solution using plugins is quite promising, in particular for better extensability. But you have to be very careful when stripping parts of Irrlicht from the library. All methods which rely on some decision which driver is used have to become part of the plugin and need to be called appropriately. So it would need a good architecure.

NB: You will never ever realize that a few cycles are wasted if you copy a texture from memory to your gfx adapter as a next step. And if the plugin system is working you won't need these if's but use the virtual functions instead. Might be cleaner, but also slightly less efficient.

[niko]

Before I wrote Irrlicht, I thought about placing every driver in a separate dll, and load them during runtime, just like Ogre does. It is no problem to do this, and it would be quite easy to change the current Irrlicht so that it works like that. But I desided not to do it because of one single stupid reason: I wanted everything in one small, easy redistributable dll. There are no real benefits or drawbacks (no, it would not run faster the other way), so I would like to keep it the way it is. But feel free to mod Irrlicht the way you want.

[Emil_halim]

so could you please enlight me how to do it, or give little hints please. so that i may do it later.

[niko]

Create a dll for every driver and an interface for it. I would suggest simply using the IVideoDriver interface as it is and one single exported function like createDevice(). Or maybe an additional function for querying informations about the implementation. In this way, it would be possible to add/remove other renderer implementation without the need of changing irrlicht.dll.

[Emil_halim]

thanks Niko,

keep up your good work