Jump to content
The Dark Mod Forums

[Obsolete] VC++ 2010 Express and No MFC configurations (+ Sys_GetVideoRam bug on Windows)


pelvis_presslays

Recommended Posts

Hello.

 

I've attached a patch file which is a diff between my local working copy of the trunk and a clean copy of the trunk (latest revision: 5670).

 

This patch brings the following changes, all in one:

  • Support for compiling idLib, TypeInfo, the game DLL and the Engine (EXE) with "Debug Without MFC" and "Release Without MFC" solution and project configurations
  • A fix for the Sys_GetVideoRam function which had a bug on Windows (at least on my dev environment)

For the MFC stuff, I have

  • split the _Debug.props into _Debug.props and (the new) _MFCDebug.props (needed to isolate the linking to nafxcwd.lib into _MFCDebug.props alone)
  • split the _Release.props into _Release.props and (the new) _MFCReleaseprops (needed to isolate the linking to nafxcw.lib into _MFCRelease.props alone)
  • excluded from the build a bunch of .cpp files related to editors (which are almost the sole uses of the MFC stuff) for those configurations
  • modified BuildDefines.h for taking into account the NO_MFC defined for not defining the ID_ALLOW_TOOLS define
  • added the GetVideoRam_f function and its companion new console command getVideoRam in Console.cpp (explained below)
  • added the " [Debug]", in case of a debug build, and " [No MFC]", in case of compilation without MFC support, tags in the both the console version string (Console.cpp) and the game window title (win_glimp.cpp)
  • reimplemented the Sys_GetVideoRam function without using MFC's CComPtr, CComBSTR and CComVariant classes; using MSVC's "native" _COM_SMARTPTR_TYPEDEF, _bstr_t and _variant_t macros and types; though I've left the original implementation in case of standard build (using the other configurations) as a better-safe-than-sorry approach (some reference material I looked up for the MFC-free conversion: http://edndoc.esri.com/arcobjects/9.1/arcgisdevhelp/developmentenvs/com/vcpp/SmartTypes.htm - http://msdn.microsoft.com/en-us/library/417w8b3b%28v=vs.100%29.aspx - https://groups.google.com/forum/?fromgroups=#!topic/microsoft.public.win32.programmer.directx.video/f8rscRiEGqw )

I compile and run on a 64-bit Windows 7 using Visual C++ 2010 Express which doesn't ship with the MFC (among other things).

 

Ok, for the Sys_GetVideoRam bug. I know my video adapter (nVidia GT 530) has 2 GB of on-board (DDR3) RAM and, when looking for replacing the MFC-based stuff that function uses, I wanted to have a check that it was doing what it was intended for. Hence, I added the new "getVideoRam" command, 'cause I couldn't get the info from the log file. "qconsole.log" seems to log too late in relation to the primary system analysis performed by the Win32-specific portion of the engine.

 

Instead of getting the expected 2048 (MB) value, I kept getting -2048 thrown at. Negative 2048. After debugging, and looking into some documentation over at the MSDN, I found that's because in Sys_GetVideoRam, the system does return the value through a VARIANT type of which the Int value is taken (which is of INT type), that's a signed integer. Then, it gets divided by "1024 * 1024" (signed as well) and the result is stored in an unsigned int (which is then returned as an int, hum hum).

 

The MSDN states that the "AdapterRAM" property of the "Win32_VideoController" class is to be read/parsed as an UInt32.

 

In the debugger, without any fix, the value after division and storing in the unsigned int was well over in the 4,000,000 range. When printing using common->Printf() and the "%i" format specifier, it would print "-2048". With the "%u": the same value as in the debugger. The fix is simple:

 

retSize = static_cast< unsigned int >(varSize.intVal) / ( 1024u * 1024u );
 

 

instead of

 

retSize = varSize.intVal / ( 1024 * 1024 );
 

 

After the fix, it reports the expected "2048" value.

 

As a side note, the patch also this coupe of lines:

 

-# Visual Studio 2010
+# Visual C++ Express 2010
 

 

I couldn't get rid of them using the diff command. Also, I might have messed up the properties for the Dedicated-related configurations. Sorry about that :(

 

For the trivia, I had originally bought the Doom 3 BFG Edition pack but only then learned it wouldn't work with TDM. So, after much frustration recompiling some Doom 3 GPL fork (dhewm3 and the vanilla Doom 3 GPL), I've set out to finally buy the original Doom 3 and was relieved to see TDM come to life :)

 

I hope this patch will be of some use. I know you've got a lot of work for a small team of core (code) developers, so NoMFC-compatibility isn't something you especially need (with a high priority) but I thought I would still contribute this, at least.

 

I've played the tutorial and been playing the Tears of Saint Lucia mission so far. I love all the feel to it. Please pardon if my English is a bit broken in places but I'm not a native English speaker.

 

Edit [2013-01-02]: Can't upload the patch file ("Error You aren't permitted to upload this kind of file"). I've made a pastebin ticket out of it (http://pastebin.com/MSeyRxAe). I hope it won't mangle the file (embedded UTF-8 BOMs and all). If requested, I could still upload the original file to some file/media sharing site.

 

Edit [2013-01-07]: Edited out all the unrelated/useless junk I originally put in.

Link to comment
Share on other sites

Hey, I dont really plan on using this.

 

At the moment I'm transitioning everything to cmake, which will make your life a whole load easier - but this will be useful in the mean time while I try find time to fight our horrible game code mess into something more orderly.

 

The cmake merge also brings in most of the nice parts of dhewm3, so we should end up with amd64 and all the niceness.

 

Thanks for the patch tho, I'm not entirely sure that the MFC stuff is completely cut out in my current stuff - as I've been testing on nix + clang/gcc/icc, but its likely you'll save me a bit of time figuring out the windows side of things when that time comes :)

Link to comment
Share on other sites

Thanks! And Welcome!

 

We already had the option of building the DLL w/o MFC. Do your changes replace those changes? Being able to build the engine w/o MFC would help me, because I also only use the Express version of MSVS, and have limited my work to DLL changes only because of that.

 

Hopefully someone familiar with the areas you've changed will be along soon to assess your patch.

 

Ninja'ed by Serps, who's the person most familiar with the underpinnings.

Link to comment
Share on other sites

Also toot toot, I'm 60% through hand fixing the headers(i.e includes, since throwing away the pch and cleaning the large game_local) for game code. Compile times are down, but there's a lot of boost stuff that still needs to be verified. Boost murders the compile time, as well as it just being generally painful :/

 

Soon my pretties!

Link to comment
Share on other sites

Hey, I dont really plan on using this.

 

At the moment I'm transitioning everything to cmake, which will make your life a whole load easier - but this will be useful in the mean time while I try find time to fight our horrible game code mess into something more orderly.

 

The cmake merge also brings in most of the nice parts of dhewm3, so we should end up with amd64 and all the niceness.

 

No problem :)

 

I've read in some other forum post that there was plan to migrate to CMake as a (meta) build system. Cool to see it comes to life, I'm impatient to benefit from it instead of having to rely on system-specific MSVC's cumbersome project+solution+props system :)

 

Thanks for the patch tho,

 

You're welcome :)

 

I'm not entirely sure that the MFC stuff is completely cut out in my current stuff - as I've been testing on nix + clang/gcc/icc, but its likely you'll save me a bit of time figuring out the windows side of things when that time comes :)

 

If it can be of any help, it's fine. If you need some additional/specific help/testing and I'm available, I'll volunteer gladly ;)

 

Thanks! And Welcome!

 

Thank you :)

 

We already had the option of building the DLL w/o MFC. Do your changes replace those changes? Being able to build the engine w/o MFC would help me, because I also only use the Express version of MSVS, and have limited my work to DLL changes only because of that.

 

Hopefully someone familiar with the areas you've changed will be along soon to assess your patch.

 

Ninja'ed by Serps, who's the person most familiar with the underpinnings.

 

Yes, it brings in the possibility to build not only the game DLL but also the engine EXE with these changes. Basically, it excludes any editors-related stuff (which are entirely based on MFC) from being built (into the EXE; it does no change to the source files in this respect, it's just project configuration-related), fixes a header definition (BuildDefines.h) and provides an alternate MFC-free implementation of Sys_GetVideoRam (the Windows version of it).

 

I don't know it if it's clear but I would like to highlight that, included in this patch, there's also a fix for a bug in the Windows implementation of Sys_GetVideoRam.

 

Lastly, I'd forgetten to mention that it drops the sys/msvc/properties/_DoomDLL.props file, in the engine.vcxproj project file, and instead uses the (new) sys/msvc/properties/_TDMExe.props file which is exactly the same save for the file name and the property sheet name in VS ("Doom III Executable" renamed to "The Dark Mod Executable"; how funny they had ended up naming their property sheet "Doom III Executable" and its file "_DoomDLL.props"). But this chunk will become obsolete as soon as Serpentine will be done with the CMake migration ;)

 

Also, there's a bug report by Tels in which he says that .props file should be deleted, they ain't needed. It'll be true when the CMake build system will be ready but for now, it's in use by the vcxproj VS project files. Sorry, I can't find back the bug report in question and don't find any suitable search feature on the bug tracker.

Edited by pelvis_presslays
Link to comment
Share on other sites

  • nbohr1more changed the title to [Obsolete] VC++ 2010 Express and No MFC configurations (+ Sys_GetVideoRam bug on Windows)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...