Smaller DLL suggestion

Luben · Post by **Luben** » Tue Apr 24, 2007 8:57 pm

zenaku's opinion

I prefer big executables.

Keep it Simple, Stupid

Frodenius · Post by **Frodenius** » Wed Apr 25, 2007 9:27 am

well normally you split your dlls according to your module structure. the problem is: irrlicht is ONE module. if you dont want to have irrlicht's gui support for your game, its not really hard to exclude it from source and then compile your own irrlicht.dll... the magic word is: refactoring..

sudi · Post by **sudi** » Wed Apr 25, 2007 9:51 am

yeah splittin the engine would be cool. u could get updates on things without exchaging all functions...so i could stay up to date with the meshloaders without redoing the gui everytime.
i did the same with my game engine....i got one big dll which has the core features and then a game.dll a server.dll and a client.dll. that way i can programm every module without taking care of the other ones....

anylo · Post by **anylo** » Wed Apr 25, 2007 12:23 pm

It would be really cool if Irrlicht would use proper autoconf/-make tools...

Code: Select all

./configure --disable-gui --disable-dx8 --disable-dx9 --disable-sw --enable-static-lib

Of course, this is just a "nice to have" feature.

rogerborg · Post by **rogerborg** » Wed Apr 25, 2007 1:45 pm

zenaku wrote:
monkeycracks wrote:
zenaku's post
I guess it would be better to have one big, monolithic file called Game.exe, right? Why even have a dll? Static link! No directory structure, no media files. Just bundle it all into one huge Game.exe Lol

Why "Lol"? For a game application it's almost certainly better than linking to a monolothic DLL, as the linker can discard any unused components (if the internal referencing is done correctly), bring the file size and memory footprint down, and avoid thunk overhead.

Not that that's really an issue with desktop machines, but if you're targetting any embedded platfom then static linking (to libraries that are unlikely to be used by any other application) is the way to go.

[UPDATE] Sorry, I meant: "LOLLZORZ D00D!!!!!"

zenaku · Post by **zenaku** » Wed Apr 25, 2007 4:31 pm

Ok, I see your points on static linking, although I disagree with 'thunk overhead'. Once the loader has loaded and relocated the dll, an asm call instruction is still a call instruction. There is zero function call overhead with using dynamic over static linking; only a marginal startup time increase.

You are right though about the linker throwing out unused methods when you statically link. It can't do that with the DLL. Static linking gives you finer granularity with what is included and what is not. Right now, every method is included in the DLL. If it was broken up into DLL modules, you'd still have to use whole DLL modules, not just methods in the modules. With static linking, exactly those methods referenced are included, no more, no less.

And besides, who's targeting embedded?

If they are, how the hell does their embedded device support irrlicht class 3d graphics but not simple dynamic libraries?

I dunno. It just seems cleaner design to me to have separate modules. It would really, really sadden me to find out that irrlicht has not embraced separate modules precisely because ogre has.

hybrid · Post by **hybrid** » Wed Apr 25, 2007 4:36 pm

I do target embedded devices. And the overhead with dynamic linking can be quite annoying on those systems.

zenaku · Post by **zenaku** » Wed Apr 25, 2007 6:16 pm

Couldn't we have the best of both worlds? Separate modules and the option to compile the separate modules as static libs as well as dlls?

When you build with gcc, you get libirrlicht.a (static) or if you use sharedlib target you get libirrlicht.so (dynamic). It could just as easily be split up into libirrlicht.core.a and libirrlicht.core.so, etc. Separate modules, dynamic or static linking which is optional to the user.

hybrid · Post by **hybrid** » Wed Apr 25, 2007 8:02 pm

Use the Makefile: 'make sharedlib' or 'make staticlib' for Linux, or the same targets with _win32 postfix (i.e. sharedlib_win32) for Windows. This is currently possible with gcc only, maybe I can add targets for other compilers...

pinballwizard · Post by **pinballwizard** » Thu May 10, 2007 7:05 am

zenaku wrote:
monkeycracks wrote:
zenaku's post
Then you'd have doodoo loads of .dll's in your main game executable location...That's not exactly nice-looking or anything.
I guess it would be better to have one big, monolithic file called Game.exe, right? Why even have a dll? Static link! No directory structure, no media files. Just bundle it all into one huge Game.exe Lol

Actually that's exactly what I want to do: everything (and I do mean everything) in a single game.exe file.

Why? To understand, first I should say that my target is creating shareware games for download or simple games for my friends.

Then with one monolithic game.exe file, I can tell my (non-geek) friends "just download and run this file". No install, no directory structure, no media files, no DLL's, no NOTHING. Literally just click, and run.

Isn't that cool that you can do this with Irrlicht (and IrrLua)?

Of course, for HUGE games with multiple DVD's of full-motion video, etc, you obviously can't go the single-huge-game.exe route, but for simple download-from-the-web games, I think there's a lot to be said for a single huge no-install game.exe file.

Irrlicht Engine

Smaller DLL suggestion

Compiling Irrlicht into single huge GAME.EXE