Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'vs 2010'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 1 result

  1. 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.
×
×
  • Create New...