Quote:Original post by Toadhead
Can't you use DirectPlay? DirectPlay is a part of DirectX which is only aimed on input right?
You meant DirectInput; DirectPlay was DirectX's networking interface.
Non-SDL Input?
You meant DirectInput; DirectPlay was DirectX's networking interface.
Quote:Original post by ZorbfishQuote:Original post by Toadhead
Can't you use DirectPlay? DirectPlay is a part of DirectX which is only aimed on input right?
You meant DirectInput; DirectPlay was DirectX's networking interface.
oepsie, yeah I ment DirectInput.
Well, if using SDL for him is overhead, then probably DirectInput will be too. I don't know how much space it takes since I've never used it, but probably it isn't tiny.
Btw, when you're so concerned about code size, have you tried to strip off unused symbols from .exe and pack it with UPX afterwards? Ie, after such operation, my previously bloated 2MB exe was taking 265 KB, and I'm using SDL, OpenGL, SDL_Image, SDL_TTF and TinyXML. Ohhh, and FMOD also :-)
-----
Uhm, I was going to send it, but then I saw that disscussion was not about exes, but dlls. But you know, I'm too lazy to delete all that stuff... ;-)
Btw, I've heard there is GCC tool which allows for merging exe with dlls. Maybe you could do that, and then - pack it with UPX...?
You can just UPX the dll, no need to merge the dll with your exe. My sdl.dll is 86kb, I don't know how that could possibly be considered "overhead".
Quote:Original post by Anonymous Poster
You can just UPX the dll, no need to merge the dll with your exe. My sdl.dll is 86kb, I don't know how that could possibly be considered "overhead".
Packing libraries with *dynamic* unpackers is ...m-m-m... how to say it politely... the worst thing you can do with a shared library. It not only takes time to unpack, but also takes *much* more memory (for those, who do not understand why: read about file mapping, it is used when loading shared library or executable), which is a lot more important than just some disk space, which is almostly infinite.
About original post. You know, when you meet a person which asks "I want to shoot myself in leg, can you give me some advices on how to do this?" will you give him instructions where to get a gun, or will you ask him, why does he need to do it?
Quote:Original post by Generic Guest
About original post. You know, when you meet a person which asks "I want to shoot myself in leg, can you give me some advices on how to do this?" will you give him instructions where to get a gun, or will you ask him, why does he need to do it?
If you had actually asked him why he needed to do it, I wouldn't be concerned. Instead, you said "Holy shit, people! Now 400 kb of code are an *overhead*?!" which is much less constructive. And comparing shooting yourself in the leg with removing a library dependency from your program is a very poor analogy.
Quote:Original post by Kylotan
If you had actually asked him why he needed to do it, I wouldn't be concerned. Instead, you said "Holy shit, people! Now 400 kb of code are an *overhead*?!" which is much less constructive.
Ok.
Author
Ah well,
Thanks for your, er, input everyone. I might look into some of the things that have been raised in this thread.
I guess that I should probably justify my reasons for wanting to drop SDL somewhat, just to clear some stuff up here. The project that I'm working on compiles to around 1mb with debug symbols and whatnot. But it currently uses so many external dl libraries [fmod, angelscript, SDL_ttf?, custom SDL_image, libpng, zlib, and a couple of inhouse libraries and probably a few more] that all add up. I'm currently trying to get rid of a bunch of them, but input was the most difficult bit to replace.
The actual data that's being moved with the application is minimal, so content could feasably take less room than the executable. It is a library, currently for use within a small team, but we'd like the option of sharing it with others. More DLL files - or even an unnessecarily large code size - are all things which would make the library itself look more amateur than it's attempting to be.
Similarly, we're moving away from LGPLed stuff [long story] and to licences where we can simply state the licence terms together in one place [except for in the relevent source], simplifying the legal burden of actually needing to read and comprehend what you can do with each particular bit before you can actually use the library for anything.
In addition, I currently use maybe 10 input specific SDL functions [and a touch of windowing/font/conversion to my own texture format stuff]. So I'm not going to be losing too much functionality. I've also read that the MSVC optimise for size stuff tends to run better than the optimise for speed stuff too, . Oh, and it's fun to learn a new library :P.<br><br>I hope that this begins to clarify why I may possibly be wanting to move away from SDL Input. I'm not saying that SDL isn't any good or anything, it's just that it's not for me, not for this project - for many reasons.<br><br>But no, this GLFW looks promising, as does leaving unused symbols out , and I'll certainly take a look at UPX, I think that we may have been going to use file mapping for interprocess communication anyways - and the init, uninit time isn't so critical… [edit: and who knows, I might end up going with DirectInput after all (unfortunately everything else should more or less run crossplatform, but the way things are going…)]<br><br>Anywho,<br>Thanks,<br>CJM
Thanks for your, er, input everyone. I might look into some of the things that have been raised in this thread.
I guess that I should probably justify my reasons for wanting to drop SDL somewhat, just to clear some stuff up here. The project that I'm working on compiles to around 1mb with debug symbols and whatnot. But it currently uses so many external dl libraries [fmod, angelscript, SDL_ttf?, custom SDL_image, libpng, zlib, and a couple of inhouse libraries and probably a few more] that all add up. I'm currently trying to get rid of a bunch of them, but input was the most difficult bit to replace.
The actual data that's being moved with the application is minimal, so content could feasably take less room than the executable. It is a library, currently for use within a small team, but we'd like the option of sharing it with others. More DLL files - or even an unnessecarily large code size - are all things which would make the library itself look more amateur than it's attempting to be.
Similarly, we're moving away from LGPLed stuff [long story] and to licences where we can simply state the licence terms together in one place [except for in the relevent source], simplifying the legal burden of actually needing to read and comprehend what you can do with each particular bit before you can actually use the library for anything.
In addition, I currently use maybe 10 input specific SDL functions [and a touch of windowing/font/conversion to my own texture format stuff]. So I'm not going to be losing too much functionality. I've also read that the MSVC optimise for size stuff tends to run better than the optimise for speed stuff too, . Oh, and it's fun to learn a new library :P.<br><br>I hope that this begins to clarify why I may possibly be wanting to move away from SDL Input. I'm not saying that SDL isn't any good or anything, it's just that it's not for me, not for this project - for many reasons.<br><br>But no, this GLFW looks promising, as does leaving unused symbols out , and I'll certainly take a look at UPX, I think that we may have been going to use file mapping for interprocess communication anyways - and the init, uninit time isn't so critical… [edit: and who knows, I might end up going with DirectInput after all (unfortunately everything else should more or less run crossplatform, but the way things are going…)]<br><br>Anywho,<br>Thanks,<br>CJM
Quote:Original post by CJM
But it currently uses so many external dl libraries [fmod, angelscript, SDL_ttf?, custom SDL_image, libpng, zlib, and a couple of inhouse libraries and probably a few more] that all add up. I'm currently trying to get rid of a bunch of them, but input was the most difficult bit to replace.
No problem, your project - your choice :-)
My engine also uses SDL, OpenGL, FMOD, SDL_TTF, SDL_Image and TinyXML (and will be using AngelScript after few days), and counting all dlls size gave me 1,1MB. But, if you can live without png and jpeg support in SDL_Image, you can recompile lib without them - just comment defines like LOAD_JPG, and you'll end with 375kb less.
Quote:Original post by CJM
[edit: and who knows, I might end up going with DirectInput after all (unfortunately everything else should more or less run crossplatform, but the way things are going...)]
And one last thing - SDL on each platform uses its native input methods. AFAIK on Windows it's using DirectInput, so more or less, you'll end reinventing wheel...
Just my two cents and may be untrue for current versions of GLFW.
If you are doing development of action game (say, FPS, TPS etc.), which is going to be run on X11 (Linux, FreeBSD etc.) you should think carefully about using GLFW as it does not support dga, which is used for disabling mouse acceleration (it annoys many players). No, it's certainly easily modifiable to get the needed support, but the standard binaries would not support it.
And as for the licenses: LGPL license is really loose. You can modify SDL as you want (you will probably want to rip all unneeded pieces, like threads, audio, cdrom etc.) and just make this modified code available on some site.
If you are doing development of action game (say, FPS, TPS etc.), which is going to be run on X11 (Linux, FreeBSD etc.) you should think carefully about using GLFW as it does not support dga, which is used for disabling mouse acceleration (it annoys many players). No, it's certainly easily modifiable to get the needed support, but the standard binaries would not support it.
And as for the licenses: LGPL license is really loose. You can modify SDL as you want (you will probably want to rip all unneeded pieces, like threads, audio, cdrom etc.) and just make this modified code available on some site.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
