Announcement

Collapse
No announcement yet.

Compiling the SDK

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • smacfan
    replied
    A couple of things:

    1. The "/EHsc" switch on the "Other Options" screen, under "Build Options" for the "Final Release" target, can be replaced in CodeBlocks with the "Enable C++ Exception Handling [/GX]" switch on the "Compiler options" tab instead. "/GX" (according to the VC++ help output) is equivalent to "/EHsc". Checked by rebuilding and comparing the size of the outputs, got the same 3756KB size with "/GX" as with "/EHsc".

    2. In the project file, the optimization for the "Final Release" target is "Maximize Speed [/O2]". By chosing "Minimize space [/O1]" instead, the DLL became only 3132KB instead of the 3620KB of the 1.61 patch or the 3756KB of the SDK build with "Maximize speed [/O2]".

    I don't intend to run the "Minimize space" version, since like everyone else I would far rather "Maximize speed"! However, it's an interesting difference nonetheless.

    Now to actually start looking at some code!

    smacfan

    [edit] -- Checked the compiler switches in the VC++ help output, and there do not seem to be switches to turn off any "default" debugging info that might be generated in an SDK build. There are some switches I won't claim to understand, but I guess the bottom line is that the SDK build seems to work OK, even if it isn't *exactly* what they released.

    Leave a comment:


  • smacfan
    replied
    Originally posted by kato-uke
    136 KB sounds almost exactly like the default debug info VC/VC+ adds if you don't turn that off. on binaries at least, no idea about libraries.
    Interesting. I'll check the VC++ "/help" output to see if there is a switch other than just not specifying the debug one I know about.

    On a second item, the choppiness of the movies, especially the intro movie:

    I have discovered that it is choppy (or not) depending on the resolution I use. On my desktop system I normally play at 1600x1200 (19in monitor), but on my 1280x800 laptop the movies are not choppy at all.

    SO, I reduced the desktop game graphics to 1280x800, and lo and behold, no choppiness.

    I guess the 128K video memory in my Radeon X300 isn't quite enough for non-choppy movies at 1600x1200 resolution.

    At least I have an explanation, and it isn't the rebuilt SDK I'm now using. That's the good news.

    smacfan

    Leave a comment:


  • kato-uke
    replied
    136 KB sounds almost exactly like the default debug info VC/VC+ adds if you don't turn that off. on binaries at least, no idea about libraries.

    Leave a comment:


  • smacfan
    replied
    Originally posted by Peter Triggs
    That must be the switch that (now) builds a program database file:

    http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx
    Many thanks, that eases my worries.

    Now, if I (we) can figure out how the Fireaxians created a DLL that's 136KB smaller than I (we) can create out here in the wild, I would have no worries at all.

    Can we ask Soren or Thamer to chime in on this, please?

    Pretty please? With a cherry on top?

    smacfan

    Leave a comment:


  • Locutus
    replied
    I never said it was easy

    Leave a comment:


  • Gramphos
    replied
    Originally posted by Locutus


    Sure, but you'll have to make your own makefile.
    The exported function names has to be decorated in the same way as MS compilers decorartes them. This makes it difficult, but not impossible to use other compilers. (You will most likely have to assign the export names for the functions yourself.)

    Leave a comment:


  • Locutus
    replied
    Originally posted by Mirakle
    Is it possible to compile with another compiler than Visual C++ ?
    Sure, but you'll have to make your own makefile.

    Leave a comment:


  • Mirakle
    replied
    Is it possible to compile with another compiler than Visual C++ ?

    Leave a comment:


  • Peter Triggs
    replied
    That must be the switch that (now) builds a program database file:

    A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program.
    http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx

    Leave a comment:


  • smacfan
    replied
    Sorry to answer my own post, but I tried a build without the Linker "/debug" switch, this reduced the "Final Release" DLL to 3756KB in size, vs 3620KB for the released 1.61 patch DLL. I would presume that the Linker switch was including debug libraries even though compiler debugging had been turned off.

    However, it is still not identical in size, which worries me a little.

    Can anyone tell what that "/pdb:..." switch in the original "vcproj" project file was intended to do? I deleted it per the instructions, but I hate to do things without knowing the reasons for doing it.

    WRT the size difference, could it be differences in the MS SDK or .NET SDK libs that cause the difference?

    Oh, and the rebuilt DLL runs the game just fine (so far, not really thoroughly tested yet on my games in progresss, but I'll get around to it, sooner or later... )

    smacfan

    Leave a comment:


  • smacfan
    replied
    Compiling the SDK to match 1.61

    OK, per the post by PJayTycy in the 1.61 patch thread (about 2/3 of the way down on this page: http://www.apolyton.com/forums/showt...9&pagenumber=2) I have installed the MSVC 2003 stuff, Platform SDK, .NET SDK, .NET libs, plus CodeBlocks, made the compiler & linker dir and option changes, saved the project file and ran a build. Substituting my DLL for the 1.61 DLL, first thing I notice is that the intro graphics and movie are even choppier than they were with the 1.61 release version.

    So, what can we do in building the DLL to fix the choppiness of the movies? I noticed a linker switch in the Final Release target, "/debug", does this need to be deleted? I also notice that the newly built DLL is about 1 MB bigger than the released patch version. How did they do that?

    To prevent the same question from being asked again, yes I am building the "Final Release" target, and *not* a debug target. Checked and double-checked.

    TIA for any help you can provide.

    smacfan

    Leave a comment:


  • MMC
    replied
    meh... just because the services packs are free, why should they change the operating policy that seems to have worked for them for 20 odd years? :P

    DOS never had 'service packs'. You had to buy the next version to fix problems or get new features.

    Leave a comment:


  • Nacht
    replied
    So microsoft incorporates bugs just to make sure that we download service packs that are free anyway?

    Leave a comment:


  • MMC
    replied
    Ok... Although I have been able to compile Source (ie Half Life 2) on VC++ 2005, and that's not supposed to work either. Maybe I have a weird version of VC++ that doesn't have all the bugs in it that M$ use to make you need the service packs.

    Leave a comment:


  • Locutus
    replied
    Originally posted by MMC
    The SDK converts to Visual C++ 2005 (8.0) as long as you remember the ensure that no files are read-only. I haven't tried compiling it yet, so I can't say about possible stability issues, but I don't think there should be many (VC++ 2003 -> 2005 shouldn't have anywhere near as many problems as VC++ 6 -> 2003 is famous for).
    Nope, 2005 doesn't compile. There's some problem with something in the Boost Python code IIRC (which is outside the SDK). This may well be fixed in the XP (no promises though), but for this SDK it's too late.
    Last edited by Locutus; April 13, 2006, 18:28.

    Leave a comment:

Working...
X