Doom3.gpl (TTimo) and VS 2013.5 community edition

[The Happy Friar]

getting a little farther with 2015 community... in addition to "math.h" header, you also need to include "cmath".  Some things were moved there in 2015 vs 13.

Now I'm having

Code Select Expand

"Severity    Code    Description    Project    File    Line    Suppression State
Error    C2039    '_file': is not a member of '_iobuf'    TypeInfo    G:\doom3.gpl-master\neo\framework\FileSystem.cpp    3644   
" error.  :/  Looking online says  2015 changed the file IO stuff for some reason.

[bitterman]

Not related question - do I need a MBCS package to compile D3 with MSVC2015CE?

[The Happy Friar]

I think I installed that, forget atm.  I installed most options.

Still can't get it to compile in 2015 CE.  It's because they changed header files between 2013 & 15 (Win 8.1/10) SDK.  I'm thinking that if I installed 2013 CE first, then 15, I would of had the original SDK & I would of been ok.  Ugh, I don't want to download & install 2013 & then 2015 again.  :p

[kat]

Sorry for the necrobump but this is literally the only topic on the entire Internet that speaks in plain tongue about compile issues with source. Anywho just kind of throwing this information out there to see if any of you chaps know what's what...

Compiling Doom3GPL (Ttimo) the following crops up; the source files as provided seem like they able to compile in Visual Studio 2013 so long as the MFC pack linked in an earlier post is loaded (if not the LNK errors occur) with the exception of this error in "xkeycheck.h" line 250; "324 error C1189: #error :  The C++ Standard Library forbids macroizing keywords. Enable warning C4005 to fine the forbidden macro".  There is some info floating around the Internet on this but it's not clear how it's used (won't link to the sites as they all seem to be traffic harvesters). Has anyone figured out a fix for this.

Second issue. Compiling the same source code with Visual Studio 2015 throws up a lot of errors (between 30 and 60 depending on how messed up the code gets after changing things around), some of which are discussed in some of the earlier posts in this topic, and again they seem to relate mainly to making sure the MFC language library's and SDK's are installed.

The "S_COLOR_RED" error crops up and can be fixed as per Friar's post, but the "SOURCE_CODE_BASE_FOLDER" persists. In the *.h file that's listed as "../"SOURCE_[...]" which is supposed to be referencing "/neo", the source code folder. But what is that path relative to, the "[drive]:\" location? Should it be "../../"SOURCE[...]" or "/"SOURCE[...]" indicating a different local relative to VS? In other words, the relative path to the source files is wrong so it throws up the error.

With regards to "math.h" versus "cmath" and VS 2015, the default code doesn't use cmath and that seems like a big task to correct, but reading up on the "abs" errors thrown up it appears Doom 3 source should be using "fabs" because the code is using 'floating variables' (which seems to be what 2015 is expecting). Using "fabs" doesn't fix the problem as might be expected though. So not sure what's going on there.

As an incidental side note: the instructions on the ModdDB page are confusing a hell and a lot of it seems to cause more problems than it solves for 2013 and 2015 (can't speak for 2010) - if those are installed correctly there's no need to add the absolute paths to VC and/or DirectX SDK etc., because VStudio is supposed to pull that info in automatically from system paths.

[kat]

O....M....G sorted. To solve the xkeyword.h error right-click "Game" select "Properties". In "Configuration Properties" expand "C/C++" and select "Preprocessor". Select "Preprocessor Definiations" and add "_XKEYCHECK_H;" between "NDEBUD;" and "%(PreprocessorDefinitions)";

Code Select Expand

NDEBUD;_XKEYCHECK_H;%(PreprocessorDefinitions)
P.S. wrote instructions up here

[bitterman]

kat

Hi! Are you that guy from katsbits?

Great site, indeed.

[kat]

Yes, tiz I. 

[The Happy Friar]

Ok, I forgot what I did to fix the C2039 error for the file is not a member of thing.  Anyone remember?  I didn't post in this thread.  I'm trying to compile in MSVC Community 2017. 

This is still the ONLY thread on the internet that address these issues. 

[kat]

What's the full error "C2039: Class is not a member of Namespace" or similar? Most resources suggest something is missing or there's a circular logic going on - file A refs file B, file B refs file A.

[The Happy Friar]

Yeah, same error I'm having in the post above ( http://idtechforums.fuzzylogicinc.com/index.php?topic=284.msg4062#msg4062 )

I just don't remember what I did to eliminate it.

[kat]

Don't know if this helps but if you look at _iobuf at line 3644(?) does it list _file as a property or function? If it does, that error appears to point to an undeclared association somewhere, so you'll likely need to add "_file" to something or remove it.

If you figure it out remember to write up what you did this time! lol

[The Happy Friar]

hovering my mouse pointer over "_file" in the offending line I get the popup that says "class '_iobuf' has no member '_file'".

Where's _iobuf?  A header perhaps?

[kat]

The error refers to it as a "class" so it'll likely be declared in a file rather than being one. The "io" part looks to be input/output. Can't say much beyond that unfortunately as I'm not running the same specs as you so likely not seeing exactly the same data (a quick source search didn't ping anything up for me).

[The Happy Friar]

This is the same GPL stock code I've compiled in MS Community 2013 & 15.  I looked online and all I could find was that after Community 2013 some headers changed.  Which is what I said a while ago. 

Maybe I did just go back to Community 2013.  I forget. 

[kat]

Yeah at a guess something else is being done with the switch to 2017 that's not being properly declared. If there wasn't a specific reason for upgrading to 2017 I'd agree on using 13 or 15, at least that way you know there isn't necessarily a core source issue..