Size of jHeretic and jHexen libraries on Windows (vc++ toolkit)
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Games, jDoom, jHeretic, jHexen, Windows.</i>
I have just noticed that in recent Windows builds (vcbuild, vc++ toolkit) that the physical size of the compiled jHeretic and jHexen game libraries have practically doubled in size compared previous versions. Noteably, the size increase of the jDoom library is roughly comparable to previous versions. I cannot yet confirm if this issue is apparent with *NIX or MacOS builds (or different compilers).
After a bit of investigation it appears that the m_ctrl.h headers which include the default control bindings and controls menu declarations are to blame. The recent addition of the "convenience headers" used by jHeretic and jHexen make the issue far more apparent...
It would appear that vc++ toolkit doesn't seem to understand that we want only 1 global instance of:
<pre>static const Control_t controls[] = {...};
static const MenuItem_t ControlsItems[] = {...};</pre>
As I mentioned earlier, I have reorganised the menu data so that <a rel="nofollow" href="http://www.dengine.net/blog/?p=72">menu pages are registered at runtime</a> so ControlsItems[] no longer exists in its present form (as of SVN 3435), as such it is no longer an issue.
Moving controls[] to a game specific control_bindings.c (name?) seems like the appropriate course of action to me. Ideas anyone?
BTW: I plan to set myself up with Cmake etc, to try the new cross-platform build system this weekend. Perhaps MinGW/Cygwin will show different results.
I have just noticed that in recent Windows builds (vcbuild, vc++ toolkit) that the physical size of the compiled jHeretic and jHexen game libraries have practically doubled in size compared previous versions. Noteably, the size increase of the jDoom library is roughly comparable to previous versions. I cannot yet confirm if this issue is apparent with *NIX or MacOS builds (or different compilers).
After a bit of investigation it appears that the m_ctrl.h headers which include the default control bindings and controls menu declarations are to blame. The recent addition of the "convenience headers" used by jHeretic and jHexen make the issue far more apparent...
It would appear that vc++ toolkit doesn't seem to understand that we want only 1 global instance of:
<pre>static const Control_t controls[] = {...};
static const MenuItem_t ControlsItems[] = {...};</pre>
As I mentioned earlier, I have reorganised the menu data so that <a rel="nofollow" href="http://www.dengine.net/blog/?p=72">menu pages are registered at runtime</a> so ControlsItems[] no longer exists in its present form (as of SVN 3435), as such it is no longer an issue.
Moving controls[] to a game specific control_bindings.c (name?) seems like the appropriate course of action to me. Ideas anyone?
BTW: I plan to set myself up with Cmake etc, to try the new cross-platform build system this weekend. Perhaps MinGW/Cygwin will show different results.
Comments
As to the name, I would go for g_ctrl.c, or perhaps m_ctrl.c (depending on whether it's related to the "game" or the "menus").
<blockquote>I plan to set myself up with Cmake</blockquote> I'll also try the Cmake build on the Mac when I get a chance, possibly later during the week.
As to the name, I would go for g_ctrl.c, or perhaps m_ctrl.c (depending on whether it's related to the "game" or the "menus").</blockquote>
Done. I went for g_ctrl.c as it's only contents are the default control bindings.
My local build now produces the following:
<pre>jDoom.dll - reduced from <strong>581,632 bytes</strong> to <strong>561,152</strong> bytes.
jHeretic.dll - reduced from <strong>962,560 bytes</strong> to <strong>548,864</strong> bytes.
jHexen.dll - reduced from <strong>929,792 bytes</strong> to <strong>507,904</strong> bytes.</pre>
<pre>/opt/beta4/lib# ls -lh *.so.0.0.0
-rwxr-xr-x 1 root root 29K Jul 27 10:53 libdpdehread.so.0.0.0
-rwxr-xr-x 1 root root 84K Jul 27 10:53 libdpmapload.so.0.0.0
-rwxr-xr-x 1 root root 35K Jul 27 10:53 libdropengl.so.0.0.0
-rwxr-xr-x 1 root root 9.1K Jul 27 10:53 libdsopenal.so.0.0.0
-rwxr-xr-x 1 root root 12K Jul 27 10:53 libdssdlmixer.so.0.0.0
-rwxr-xr-x 1 root root 629K Jul 27 10:53 libjdoom.so.0.0.0
-rwxr-xr-x 1 root root 646K Jul 27 10:53 libjheretic.so.0.0.0
-rwxr-xr-x 1 root root 599K Jul 27 10:53 libjhexen.so.0.0.0
and
ls -lh *.so
-rw-r--r-- 1 root root 29K Jul 27 10:52 libdpdehread.so
-rw-r--r-- 1 root root 84K Jul 27 10:52 libdpmapload.so
-rw-r--r-- 1 root root 35K Jul 27 10:52 libdropengl.so
-rw-r--r-- 1 root root 9.0K Jul 27 10:52 libdsopenal.so
-rw-r--r-- 1 root root 12K Jul 27 10:52 libdssdlmixer.so
-rw-r--r-- 1 root root 630K Jul 27 10:52 libjdoom.so
-rw-r--r-- 1 root root 645K Jul 27 10:52 libjheretic.so
-rw-r--r-- 1 root root 608K Jul 27 10:52 libjhexen.so</pre>
Which is in line with my expectations.