Windows VS2017 project for DXX-Rebirth
#1
I want to make a working project (from contrib/broken-vs2017) that will compile on Windows, in VS 2017 (with some compile-time switch like _MSC_VER in the code), for now, downloaded the latest code, fixed obvious errors like missing files and headers, downloaded dependencies (PhysFS and SDL, having the following errors :  
1>mve_audio.cpp
1>..\..\d2x-rebirth\libmve\mveplay.cpp(13): fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory
1>..\..\d2x-rebirth\libmve\decoder16.cpp(83): error C2661: 'con_puts': no overloaded function takes 1 arguments
1>..\..\d2x-rebirth\libmve\decoder16.cpp(83): error C3861: 'DXX_ptrdiff_cast_int': identifier not found
1>..\..\d2x-rebirth\libmve\decoder8.cpp(33): error C2661: 'con_puts': no overloaded function takes 1 arguments
1>..\..\d2x-rebirth\libmve\decoder8.cpp(33): error C2664: 'void con_printf(con_priority_wrapper,const char *,...)': cannot convert argument 1 from 'const char [78]' to 'con_priority_wrapper'
1>..\..\d2x-rebirth\libmve\decoder8.cpp(33): note: No constructor could take the source type, or constructor overload resolution was ambiguous
1>..\..\d2x-rebirth\libmve\decoder8.cpp(35): error C2661: 'con_puts': no overloaded function takes 1 arguments
1>..\..\d2x-rebirth\libmve\decoder8.cpp(35): error C2664: 'void con_printf(con_priority_wrapper,const char *,...)': cannot convert argument 1 from 'const char [78]' to 'con_priority_wrapper'
1>..\..\d2x-rebirth\libmve\decoder8.cpp(35): note: No constructor could take the source type, or constructor overload resolution was ambiguous
1>..\..\d2x-rebirth\libmve\decoder8.cpp(38): error C2661: 'con_puts': no overloaded function takes 1 arguments
1>..\..\d2x-rebirth\libmve\decoder8.cpp(38): error C2664: 'void con_printf(con_priority_wrapper,const char *,...)': cannot convert argument 1 from 'const char [78]' to 'con_priority_wrapper'
1>..\..\d2x-rebirth\libmve\decoder8.cpp(38): note: No constructor could take the source type, or constructor overload resolution was ambiguous
1>..\..\d2x-rebirth\libmve\decoder8.cpp(40): error C2661: 'con_puts': no overloaded function takes 1 arguments
1>..\..\d2x-rebirth\libmve\decoder8.cpp(40): error C2664: 'void con_printf(con_priority_wrapper,const char *,...)': cannot convert argument 1 from 'const char [78]' to 'con_priority_wrapper'
1>..\..\d2x-rebirth\libmve\decoder8.cpp(40): note: No constructor could take the source type, or constructor overload resolution was ambiguous

D:\Code\dxx-rebirth-master\common\include\byteutil.h(73): error C2065: 'DXX_WORDS_BIGENDIAN': undeclared identifier
1>D:\Code\dxx-rebirth-master\common\include\byteutil.h(73): error C2975: '_Val': invalid template argument for 'std::integral_constant', expected compile-time constant expression
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\xtr1common(22): note: see declaration of '_Val'

Those are fixed; sys/time.h put under !_MSC_VER,
DXX_ptrdiff_cast_int defined as cast ot int,
con_printf replacid by variable-arg list printf.
DXX_WORDS_BIGENDIAN defined to 0

The ones that I cannot fix :

>mve_main.c
1>..\..\d2x-rebirth\libmve\mve_main.c(24): error C2061: syntax error: identifier 'g_palette'
1>..\..\d2x-rebirth\libmve\mve_main.c(24): error C2059: syntax error: ';'
1>..\..\d2x-rebirth\libmve\mve_main.c(76): error C2065: 'g_palette': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(76): warning C4047: '=': 'unsigned char *' differs in levels of indirection from 'int'
1>..\..\d2x-rebirth\libmve\mve_main.c(108): error C2065: 'g_palette': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(108): error C2109: subscript requires array or pointer type
1>..\..\d2x-rebirth\libmve\mve_main.c(111): error C2065: 'g_palette': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(111): error C2109: subscript requires array or pointer type
1>..\..\d2x-rebirth\libmve\mve_main.c(114): error C2065: 'g_palette': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(114): warning C4022: 'memcpy': pointer mismatch for actual parameter 1
1>..\..\d2x-rebirth\libmve\mve_main.c(156): error C2065: 'MVE_videoSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(156): error C2146: syntax error: missing ';' before identifier 'vSpec'
1>..\..\d2x-rebirth\libmve\mve_main.c(156): error C2065: 'vSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(164): error C2065: 'g_palette': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(164): warning C4022: 'memset': pointer mismatch for actual parameter 1
1>..\..\d2x-rebirth\libmve\mve_main.c(166): warning C4013: 'MVE_sndInit' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(167): warning C4013: 'MVE_memCallbacks' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(168): warning C4013: 'MVE_ioCallbacks' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(169): warning C4013: 'MVE_sfCallbacks' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(170): warning C4013: 'MVE_palCallbacks' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(172): warning C4013: 'MVE_rmPrepMovie' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(174): warning C4013: 'MVE_getVideoSpec' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(174): error C2065: 'vSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(176): error C2065: 'vSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(176): error C2224: left of '.truecolor' must have struct/union type
1>..\..\d2x-rebirth\libmve\mve_main.c(178): error C2065: 'vSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(178): error C2224: left of '.screenWidth' must have struct/union type
1>..\..\d2x-rebirth\libmve\mve_main.c(178): error C2224: left of '.screenHeight' must have struct/union type
1>..\..\d2x-rebirth\libmve\mve_main.c(178): error C2198: 'SDL_SetVideoMode': too few arguments for call
1>..\..\d2x-rebirth\libmve\mve_main.c(180): error C2065: 'vSpec': undeclared identifier
1>..\..\d2x-rebirth\libmve\mve_main.c(180): error C2224: left of '.truecolor' must have struct/union type
1>..\..\d2x-rebirth\libmve\mve_main.c(182): warning C4013: 'MVE_rmStepMovie' undefined; assuming extern returning int
1>..\..\d2x-rebirth\libmve\mve_main.c(187): warning C4013: 'MVE_rmEndMovie' undefined; assuming extern returning int
1>Done building project "d2x-rebirth.vcxproj" -- FAILED.


Trying to include palette_array_t definition in palette.h
causes this strange errors in STL header:

>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2061: syntax error: identifier 'std'
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2059: syntax error: ';'
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2449: found '{' at file scope (missing function header?)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(49): error C2059: syntax error: '}'

If I comment the whole mve_main.c with #if 0, the following erroors that I've seen earlier appear :

movie.cpp
1>d:\code\dxx-rebirth-master\d2x-rebirth\main\movie.h(29): fatal error C1083: Cannot open include file: 'd2x-rebirth/libmve/mvelib.h': No such file or directory (compiling source file ..\..\d2x-rebirth\main\movie.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: ',': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: '>': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2062: type 'unknown-type' unexpected (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2143: syntax error: missing '>' before ';' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2976: 'valptridx_specialized_type_parameters': too few template arguments (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: ',': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: '>': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2062: type 'unknown-type' unexpected (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2143: syntax error: missing '>' before ';' (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2976: 'valptridx_specialized_type_parameters': too few template arguments (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\escort.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: ',': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: '>': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2062: type 'unknown-type' unexpected (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2143: syntax error: missing '>' before ';' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2976: 'valptridx_specialized_type_parameters': too few template arguments (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2833: 'operator integral_type' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(192): note: see reference to class template instantiation 'valptridx<managed_type>::magic_constant<constant>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(193): note: see reference to class template instantiation 'valptridx<managed_type>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\main\inferno.h(49): note: see reference to class template instantiation 'std::integral_constant<::size_t,13>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\3d.h(311): note: see reference to class template instantiation 'std::integral_constant<::size_t,100>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2059: syntax error: 'newline' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2334: unexpected token(s) preceding '{'; skipping apparent function body (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(43): error C2955: 'valptridx_specialized_type_parameters': use of class template requires template argument list (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(44): note: see reference to class template instantiation 'valptridx<dcx::segment>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(19): note: see reference to class template instantiation 'std::integral_constant<::size_t,9000>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(45): error C2955: 'valptridx_specialized_type_parameters': use of class template requires template argument list (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(45): error C3210: 'valptridx_specialized_type_parameters': access declaration can only be applied to a base class member (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(73): error C2955: 'valptridx_specialized_type_parameters': use of class template requires temp

D:\Code\dxx-rebirth-master\common\include\valptridx.h(283): note: see declaration of 'valptridx<managed_type>::array_managed_type' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\main\newmenu.h(536): error C2833: 'operator decltype' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\main\newmenu.h(550): note: see reference to class template instantiation 'menu_bit_wrapper_t<T,B>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(113): note: see reference to class template instantiation 'std::integral_constant<::size_t,7>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\main\newmenu.h(536): error C2059: syntax error: 'newline' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\main\newmenu.h(537): error C2334: unexpected token(s) preceding '{'; skipping apparent function body (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): warning C4346: 'integral_type': dependent name is not a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): note: prefix with 'typename' to indicate a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(953): note: see reference to class template instantiation 'valptridx<managed_type>::basic_ival_member_factory<Pc,Pm>' being compiled (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): warning C4346: 'valptridx<managed_type>::integral_type': dependent name is not a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): note: prefix with 'typename' to indicate a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): error C2061: syntax error: identifier 'integral_type' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(909): error C2065: 'v': undeclared identifier (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(909): error C2061: syntax error: identifier 'A' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(668): warning C4002: too many actual parameters for macro 'static_assert' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(667): error C2429: language feature 'terse static assert' requires compiler flag '/std:c++latest' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(2053): note: see reference to class template instantiation 'std::vector<_Ty,_Alloc>' being compiled (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(2681): warning C4002: too many actual parameters for macro 'static_assert' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(2680): error C2429: language feature 'terse static assert' requires compiler flag '/std:c++latest' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(3297): note: see reference to class template instantiation 'std::vector<bool,_Alloc>' being compiled (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-player.h(82): error C2589: ',': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-player.h(82): fatal error C1003: error count exceeds 100; stopping compilation (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>..\..\d2x-rebirth\main\gamepal.cpp(72): error C3861: 'DXX_ptrdiff_cast_int': identifier not found
1>..\..\d2x-rebirth\main\gamepal.cpp(90): warning C4245: 'argument': conversion from 'int' to 'uint_fast32_t', signed/unsigned mismatch
Reply
#2
It would be nice if you could wrap the error messages in [code] tags since it is program output, and also possibly easier to track this as a Github issue. (Where I could edit your post to add Markdown equivalent of [code] tags, as well as use some of Github's other repository integration special markup.) Since we're here, we can stay here.

I suspect most of your con_ errors are related to preprocessor problems. If possible, set your preprocessor to C99 mode.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>..\..\d2x-rebirth\libmve\decoder16.cpp(83): error C2661: 'con_puts': no overloaded function takes 1 arguments
Could you post the post-processed result for this line?
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>..\..\d2x-rebirth\libmve\decoder16.cpp(83): error C3861: 'DXX_ptrdiff_cast_int': identifier not found
Your solution of casting to int is probably correct here. That is what is used on platforms with sizeof(ptrdiff_t) > sizeof(int). For platforms where sizeof(ptrdiff_t) == sizeof(int), the cast is sometimes unnecessary, but only wrong if the compiler warns for "useless" casts and considers the cast to be useless. Go with your cast for now, but be prepared for a warning later if the Win32 target (rather than Win64 target) decides this to be a useless cast. If that happens, it will need to be preprocessed to nothing. See https://github.com/dxx-rebirth/dxx-rebir...ruct#L2337 - #L2365 for how this is generated in SConstruct.

I would put defines like this in the manually maintained contrib/broken-vs2017/dxxsconf.h.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>..\..\d2x-rebirth\libmve\decoder8.cpp(33): error C2664: 'void con_printf(con_priority_wrapper,const char *,...)': cannot convert argument 1 from 'const char [78]' to 'con_priority_wrapper'
Argument 1 should be a con_priority, which can be converted to a con_priority_wrapper. Could you post the post-processed result for this line?
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
D:\Code\dxx-rebirth-master\common\include\byteutil.h(73): error C2065: 'DXX_WORDS_BIGENDIAN': undeclared identifier
Your solution is correct.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote: con_printf replacid by variable-arg list printf.
This is incorrect. con_printf writes to stdout (which is usually lost on Windows), to gamelog.txt, and to the in-game console accessible via Shift-Escape. Replacing it with standard printf prevents writing to the latter two destinations.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
>mve_main.c
mve_main.c should be unused, at least from the perspective of the main game. It is not built by SConstruct. However, it appears that the vsproj in the repository tries to build it. This is an error in the repository.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote: Trying to include palette_array_t definition in palette.h
causes this strange errors in STL header:
Code:
>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2061: syntax error: identifier 'std'
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2059: syntax error: ';'
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(9): error C2449: found '{' at file scope (missing function header?)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\cstdint(49): error C2059: syntax error: '}'
If I comment the whole mve_main.c with #if 0, the following erroors that I've seen earlier appear :
Yes, fully disabling use of mve_main.c is correct. Ignore any errors you encountered trying to build it.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
movie.cpp
1>d:\code\dxx-rebirth-master\d2x-rebirth\main\movie.h(29): fatal error C1083: Cannot open include file: 'd2x-rebirth/libmve/mvelib.h': No such file or directory (compiling source file ..\..\d2x-rebirth\main\movie.cpp)
The top-level source directory must be in $CPPPATH. SConstruct does this, but apparently the Visual Studio project does not.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: ',': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2589: '>': illegal token on right side of '::' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2062: type 'unknown-type' unexpected (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2143: syntax error: missing '>' before ';' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(26): error C2976: 'valptridx_specialized_type_parameters': too few template arguments (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
This is an unfortunately complex macro. Could you post the post-processed result for this line? Also, if possible, please turn on column numbers in the error output. This is enabled by default in recent versions of gcc. I do not know if Visual Studio can do this. This line is sufficiently complicated that identifying the error solely from what is shown so far will be tedious.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2833: 'operator integral_type' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
gcc and clang accept this without issue. integral_type is a type from the enclosing class. Curiously, Visual Studio had no issue with using integral_type as the type of the template non-type parameter for this inner template class, but then refuses to recognize it as a type inside the class. Does this work if you s/integral_type/valptridx<managed_type>::&/? gcc still accepts the qualified form (though this obviously reduces maintainability a bit).
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2059: syntax error: 'newline' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2334: unexpected token(s) preceding '{'; skipping apparent function body (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
I think this is just noise from the compiler becoming confused by the earlier error.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(43): error C2955: 'valptridx_specialized_type_parameters': use of class template requires template argument list (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>D:\Code\dxx-rebirth-master\common\include\cpp-valptridx.h(169): note: see declaration of 'valptridx_specialized_type_parameters' (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(44): note: see reference to class template instantiation 'valptridx<dcx::segment>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
1>d:\code\dxx-rebirth-master\common\main\fwd-segment.h(19): note: see reference to class template instantiation 'std::integral_constant<::size_t,9000>' being compiled (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
This makes no sense. The use of valptridx_specialized_type_parameters inside valptridx_specialized_types already has template parameters. Perhaps the post-processed output of expanding DXX_VALPTRIDX_DECLARE_SUBTYPE would help.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(45): error C3210: 'valptridx_specialized_type_parameters': access declaration can only be applied to a base class member (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
The base class has such a member. I think this is just noise from the compiler becoming confused by the earlier error.

I think there was a copying error here. You have an error message that cuts off in the middle of the line, then a blank line, then a note: with no appropriate preceding error:.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\main\newmenu.h(536): error C2833: 'operator decltype' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
This is a weird little failure. It managed to follow the typedef to the underlying decltype, but then not resolve the decltype into an actual type. The expected type of M is the result of operator & (T1, T2): bit-and an instance of the first argument with an instance of the second argument. This has a subtlety that the inputs need not be directly usable with bit-and, provided that they implicitly convert to types that are usable.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): warning C4346: 'integral_type': dependent name is not a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(907): note: prefix with 'typename' to indicate a type (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
I seem to recall a similar error from a prior attempt with a version of Visual Studio. Surprisingly, adding typename as suggested has no adverse impact on the gcc build. It would be interesting to know which compiler is standard-conforming on this point: should typename be required, be optional, or be forbidden for the type portion of a template non-type parameter, when the type comes from a dependent base type?
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(909): error C2065: 'v': undeclared identifier (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>D:\Code\dxx-rebirth-master\common\include\valptridx.h(909): error C2061: syntax error: identifier 'A' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
I think this is just noise from the compiler becoming confused by the earlier error.
(01-21-2018, 04:00 PM)AlexanderBorisov Wrote:
Code:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(668): warning C4002: too many actual parameters for macro 'static_assert' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(667): error C2429: language feature 'terse static assert' requires compiler flag '/std:c++latest' (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\vector(2053): note: see reference to class template instantiation 'std::vector<_Ty,_Alloc>' being compiled (compiling source file ..\..\d2x-rebirth\main\bmread.cpp)
Could you post the post-processed result for these lines?
Reply
#3
About con_printf, maybe we can leave this implementation, then
void con_printf(con_priority_wrapper level, const char* format, ...)
{
va_list args;
va_start(args, format);
char str[4096];
vsprintf(str, format, args);
con_puts(level, str, strlen(str));
va_end(args);
}
because I think it is a minor issue anyway, if you don't like it I will later look on pre-processed file and find the offending line, but I suspect VS does not support any of variable argument macros, and we can hardly do anything about it.
Using C99 preprocessor, I guess, is the default for VS 2017, as well as using the latest C++ language extensions.
I don't know how to enable column numbers in error list; probably not possible in VS, at least it gives an offending symbol and an explanation (sometimes completely screwed up by previous errors, however).
About some headers not found, for now I just put in the relative path in each cpp, should work. Also had to disable some warnings (2 or three) in project options that prevent STL and windows.h from compiling.

So I fixed all those minor issues by small changes, If smth is a bit wrong can be further corrected later. I suggest now focusing on errors that are really hard to fix (at least for me), because if we would fix minor ones and run into smth that will require changing a lot of code and worse yet, not fixable, it will be lost time. Namely those errors with valptridx macros in cpp_valptridx.h, valptridx.h,  fwd-segment.h and so on. For now you can briefly explain to me what are those files and macros, there are no comments in the code and I don't think anyone can understand them. At least I see such coding paradigm for the first time in my life and to say I am puzzled is too little to express it.... And I am the one that most of my coworkers hated for excessive use of macros... A bit later I will send you the preprocessed files and try to figure out where the compilation fails on them.

Today I got everything to compile in pre-process mode, meaning all the header references are fixed, SDL_mixer installed, but I encountered the following problems -
resource file not found, I copied it from similar/arch/win32 to d2x-rebirth\arch\win32 and changed icon name inside to d2x-rebirth.ico, and afxres.h to windows.h, then it compiled. But still gives the error
error LNK2001: unresolved external symbol _WinMainCRTStartup
it cannot find program entry point (I believe it is always _main or _tmain in console app and WinMain on Windows subsystem). Where it should be and what is the entry point name for Windows for DXX? And is this copying of resource file correct?

EDIT : here is the pre-processed line that does not compile (the first one) : fwd_segment.h line 26
DXX_VALPTRIDX_DECLARE_SUBTYPE(dcx::, segment, segnum_t, MAX_SEGMENTS);

here is the preprocessed file :
#line 17 "d:\\code\\dxx-rebirth-master\\common\\main\\fwd-segment.h"

namespace dcx {
constexpr std::integral_constant<std::size_t, 9000> MAX_SEGMENTS{};
using segnum_t = uint16_t;
}

namespace dcx {
struct segment;
}
template <> struct valptridx_specialized_types<dcx:: segment> { using type = valptridx_specialized_type_parameters< segnum_t, MAX_SEGMENTS, valptridx_untyped_utilities::report_error_style:: , valptridx_untyped_utilities::report_error_style::  >; };
#line 28 "d:\\code\\dxx-rebirth-master\\common\\main\\fwd-segment.h"

Nothing after :: is highly suspicious, and I'd say dcx:: segment the space is suspicious, too. But I don't understand what this structure is and what is it for.

Another error is for
D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2833: 'operator integral_type' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
which is true, this operator does not exist...

Lets deal with those two, other errors can be induced by those.
Reply
#4
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: About con_printf, maybe we can leave this implementation, then
What is wrong with the current con_printf definition? The problem is that Visual Studio mishandles calls to con_printf due to the macro expansions involved. None of your output indicates it mishandles compiling con_printf.
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: I suspect VS does not support any of variable argument macros, and we can hardly do anything about it.
Using C99 preprocessor, I guess, is the default for VS 2017, as well as using the latest C++ language extensions.
I think these statements conflict. As I understand it, variadic macros are supported in the latest standard. If Visual Studio does not support variadic macros, then it does not perform according to the latest standard. (I think it handles basic variadic macros correctly. It only has trouble with macros that expand to provide commas.) Similarly, as I understand it, C99 macro processing requires the results that gcc/clang produce. Visual Studio produces a different result here than gcc/clang produce. Therefore, if I am correct that C99 requires the semantics that gcc/clang show, then Visual Studio, at least as presently configured, is not running in a C99 mode.
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: For now you can briefly explain to me what are those files and macros, there are no comments in the code and I don't think anyone can understand them.
You should look at some of the earlier valptridx iterations. It was once much worse. I moved as much as I could out of the macros because this was easier to maintain. Briefly, DXX_VALPTRIDX_DECLARE_SUBTYPE defines a template specialization of valptridx_specialized_types; this specialization is used by valptridx<T> to obtain various types and constants associated with type T. This allows the main definition of valptridx<T> to be simple to reference and be defined without use of a massive macro.
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: resource file not found, I copied it from similar/arch/win32 to d2x-rebirth\arch\win32 and changed icon name inside to d2x-rebirth.ico, and afxres.h to windows.h, then it compiled.
This is probably a stale reference in the vsproj file. That resource moved from separate to similar at some point.
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: But still gives the error
error LNK2001: unresolved external symbol _WinMainCRTStartup
it cannot find program entry point (I believe it is always _main or _tmain in console app and WinMain on Windows subsystem). Where it should be and what is the entry point name for Windows for DXX? And is this copying of resource file correct?
The entry point is main, which is macro-remapped to SDL_main, then SDL provides the entry point that the CRT wants.
(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: EDIT : here is the pre-processed line that does not compile (the first one) : fwd_segment.h line 26
DXX_VALPTRIDX_DECLARE_SUBTYPE(dcx::, segment, segnum_t, MAX_SEGMENTS);

here is the preprocessed file :
#line 17 "d:\\code\\dxx-rebirth-master\\common\\main\\fwd-segment.h"

namespace dcx {
constexpr std::integral_constant<std::size_t, 9000> MAX_SEGMENTS{};
using segnum_t = uint16_t;
}

namespace dcx {
struct segment;
}
template <> struct valptridx_specialized_types<dcx:: segment> { using type = valptridx_specialized_type_parameters< segnum_t, MAX_SEGMENTS, valptridx_untyped_utilities::report_error_style:: , valptridx_untyped_utilities::report_error_style:: >; };
#line 28 "d:\\code\\dxx-rebirth-master\\common\\main\\fwd-segment.h"

Nothing after :: is highly suspicious, and I'd say dcx:: segment the space is suspicious, too. But I don't understand what this structure is and what is it for.
Whitespace around namespace qualifiers is fine. The missing token after the :: is probably another case of macro mishandling. The missing token is supplied by:
Code:
            DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_DISPATCH(    \
        DXX_VALPTRIDX_REPORT_ERROR_STYLE_mutable_##MANAGED_TYPE,    \
        DXX_VALPTRIDX_REPORT_ERROR_STYLE_default_##MANAGED_TYPE,    \
        DXX_VALPTRIDX_REPORT_ERROR_STYLE_mutable_default,    \
        DXX_VALPTRIDX_REPORT_ERROR_STYLE_default)    \
See common/include/cpp-valptridx.h.

(01-22-2018, 05:14 PM)AlexanderBorisov Wrote: Another error is for
D:\Code\dxx-rebirth-master\common\include\fwd-valptridx.h(191): error C2833: 'operator integral_type' is not a recognized operator or type (compiling source file ..\..\d2x-rebirth\main\gamepal.cpp)
which is true, this operator does not exist...

This is an operator to convert to type integral_type. I interpret this to mean that the compiler cannot resolve integral_type to a type. Does it help if you remind the compiler that this type exists in the enclosing class?
Reply
#5
I've read about C99 support in VS2017 compiler, and yes, it supports C99, but not completely. There are bugs with variadic macros support, as I suspected. And I am not sure Microsoft will fix them soon. So only way is to modify (I mean : further simplify) them in some way for VS compiler. Or create special version of them for Microsoft compiler. Or use templates instead of macros. Should be perfectly possible for con_printf, but what do you think about the others? What should we do? And what is the funtionality behind this valptridx thing, seems original game did just fine without it, are they so important and have some real new game features behind them? It would be very pitiful if code that only used for error reporting or simplifies type conversion blocks compilation on the other platform...

I'll get to the rest when we decide what to do with this - as everything else seems more easy to fix.
Reply
#6
While I cannot say that Visual Studio's variadic macro support is or is not perfect, this is not a variadic macro problem. It is an order of evaluation problem. I chose macros over templates in this case because macros satisfied the requirements and seemed likely to be less work for the compiler than layering in more templates. I expect con_printf cannot be solved by using more templates, but I would be happy to be demonstrated wrong on this point.

For con_printf, the macros are pure debugging. They can be omitted, at the risk that Visual Studio users might write patches that the macros properly reject, and submit those changes without realizing that the patches are bad.

For the valptridx exception dispatcher, that could probably be redone using templates. It could also be omitted entirely and require Visual Studio users to use some hardcoded default, without the ability to readily change it with a preprocessor macro.

For the type confusion, I don't know how to solve some of those. (Some can be solved by adding otherwise unnecessary typedefs to guide the compiler. That decltype failure does not seem solvable while retaining the flexibility it provides.) I believe the compiler is wrong to reject them.

The original game used very ugly constructs because it lacked valptridx. It routinely converted integers to pointers and pointers to integers, even when it could have easily passed both together. That is what valptridx wraps. Use of valptridx also provides strict bounds checking. The original game almost never checked that array indices were in bounds before use. Valptridx always checks it, and the presence of one of the subtypes assures that your caller has already checked it, so it need not be checked again.

Personally, since free functional compilers exist for all the major targets, I'd be inclined to declare Visual Studio 2017 to be unusable and revisit the issue in the next Service Pack (or next VS release, if necessary). Remember, this does not block compilation on Windows nor compilation for Windows. It only blocks compilation with Microsoft's compiler. MinGW handles this fine, both in native and cross-compile modes.
Reply
#7
I don't understand why macros are less work for the compiler compared to templates in this case. I don't understand also why you say that all 3 issues at hand are solvable, but propose to wait the next release of VS. Yes I think it will support the lastest standard in some distant future, but since it is a big commercial product it is always at least 2-3 years behind the standard changes. And I think it is a good thing, more testing, less bugs. Another thing that can make it worse, using macros like this is discouraged everywhere, and I didn't knew a single fellow programmer who did is that way. During my more than 15 year work in different big projects in several big companies. This does not necessarily imply that this approach is bad in your case, but it means that very few people in the world will see those VS macro compilation bugs, and they will be extremely low priority to fix.

About ugly constructs, lack of bound checking - heard it million times during my work, too, in any project, "ugly code" became a cliche already, my experience is that it is completely personal preference thing and actually does not influence the code quality. I personally work more on math and low level optimized stuff and use completely different coding paradigm than many of my co-workers. But it is impossible to make the code one or two orders of magnitude faster without it. So for me converting integers to pointers and back, complex bit operations, and other tricks, are nothing special, if used well and commented well-and you know what you are doing. Never had many problems or hard to find bugs because of it, logic errors are always the worst ones. One can write good and well structured code even in assembly or intrinsics if necessary. About bound checking, I simply place asserts everywhere, don't see why it is impossible to take original game and add those. But I cannot really argue about the particular valptridx macros (can they be done with templates or other way, is it better or not), because I still don't understand what they do; and why you cannot do without constructs not compilable by Microsoft compiler. Anyway it is your code and you decide how to write it.

But what I can say for sure that original game code is much easier to understand for "normal" experienced software developer, and contribute to it. And it should compile everywhere. And this is a big PRO about it. I believe this is very important, the game can become better if there were more contributors (at least me and Sirius wanted to look at/fix bugs - both on Windows - and I think there are others). Even DX-XL is compilable with VS! A lot of people work in Windows, are used to modern IDEs (like VS) with powerful integrated debuggers and code check tools (that make those bounds checking and memory corruption problems no more diffucult to find and fix than minor compile errors), and in this case you can only work with the code from command line, and debug via console logging. So installing MinGW on Windows is not an option, it is harder and more complex than installing Linux on other HD or on virtual machine, and does not provide the debugging functionality of VS. There is an option of installing QT IDE for Windows but it is bad idea - hard to make it work, extremely buggy, lacking important functionality, etc, I had a lot of pain working with it even on Linux.

So I am really willing  to solve the issues and contribute to bug fixing, but not on Linux... Sad if we will be unable to make it work in VS.
Reply
#8
Macros are simple text processing, and discard the unwanted branches earlier in the process. Also, they often generate little or no trace in the debug information compared to an equivalent set of templates. This can be a notable benefit in popular headers. I propose to wait for Visual Studio to improve because that is by far the easiest course of action for me. All the major platforms work today on free compilers. Visual Studio doesn't work under Wine, meaning I can't do anything with it except on rare occasions when I have access to a Windows system. Many people see these Visual Studio macro bugs. Every time I've wanted to refer to them, I can quickly find posts, going back many years, and never the same set of posts, about problems caused by the macro order-of-evaluation. The second easiest course of action for me is for me to review your proposed Visual Studio compatibility changes, rather than try to develop them on my own, particularly since I can't readily test any of those changes in Visual Studio. It is good that Microsoft made Visual Studio free to download. It would be better if they made available a download that could be run under Wine.

The old approach of converting freely to/from pointer was not merely ugly. It generated bad code because it was written with the idea that pointer subtraction would be cheap. Later maintainers (before my time) made the structures larger, which made pointer math less cheap. It was not a major slowdown for modern hardware, but it generated substantial avoidable code bloat. Compare the text segment size of 0.58.1-d2x against tip with the same compiler options. Despite added features and tremendous numbers of additional runtime sanity checks, the new code was (at last check) notably smaller than the old.

I am disappointed to hear that you consider the core code not to be understandable by typical developers. I have intentionally refrained from various constructs because I expected them to scare off contributors. If the code is already impenetrable without those constructs, I lose nothing by allowing more complex constructs. As I said above, the game does compile everywhere.

As best I can recall, Sirius has never contacted me about this. Aside from the person who provided the Visual Studio projects, you are the only person whom I can recall ever expressing an interest in a Visual Studio target. More generally, looking at a list of contributors doesn't suggest much outside activity, nor do I recall any contributors that I turned away.
Code:
$ git shortlog -s -n --since=2015-01-01 --no-merges --pretty=oneline github/master
  3418  Kp
   120  Chris Taylor
   118  zico
    43  Bradley Bell
    20  derhass
     6  John Ackerman
     2  BuildTools
     1  Conn O'Griofa
     1  Lukasz Pawelczyk
     1  Matt Vandermeulen
     1  kreatordxx
Note that kreatordxx is an alias for Chris Taylor, so it ought to be folded into his upper line. BuildTools is an alias for John Ackerman. From this, we see that only a tiny number of contributors are responsible for almost all the work on the project in the last three years. (As an aside, there are some long time community members who have made substantial non-code contributions in the form of testing or other research, who are not acknowledged above despite providing valuable work.) Would others have contributed if I managed the project differently? Maybe, but they've never spoken to me to complain about how this runs now. I suspect Bradley would have been more involved if the code were handled differently (notably, he revived the old d2x project in early 2016, but that seems to have stagnated). I don't know how differently it would've needed to be to keep him on Rebirth, or whether his issue was with the code or with my style. I don't know if anyone else feels similarly.

I would love to have Visual Studio be supported for Rebirth. I just don't feel like spending my very limited development time guessing how to work around compiler bugs. Since I can't run Visual Studio, that's all my changes in response to your problem reports would be: guesses. For some easy things, like the project using files it should not or accessing files that have since moved, I can fix those blind. For subtle issues like the typedef handling, that needs testing before I push it.
Reply
#9
I know that macros can be very useful when you need to cut down compile time (because templates instantiate in every obj file for each cpp they are visible in),
still I believe the compiled executable/library stays the same no matter what you use. Templates are  just more flexible, but as for me, I tend to avoid both. Debug info size is usually not an issue, Microsoft compiler places it into the separate file always. And it should not be hard to install VS on a virtual machine with Windows, yes it is unfortunate that VS does not work on Linux natively or on Wine.

What you mean by this pointer subtraction thing? Usually for the compiler there is no difference what you subtract, it generates smth like sub rax, rbx instruction anyway, maybe you mean that if those are pointers to structures the result of the abovementioned instruction should be divided by structure size (which is a slowdown indeed)?
I cannot compare code size of course, because I am unable to compile it. And probably all those new checks are not compiled in release build(which should be so), so they should not inluence the exe size at all...

I can drop a line Sirius to look at this thread, let's see if he still wants it to be compilable in VS, too, and wishes to fix bugs. About people writing posts on VS macro support bugs, surely there are some of them amongst millions of developers in the world. But I don't know any of them personally and never heard of such people. So it is hard to judge whether such posts influence anything, also it depends whether those people are large scale project developers or just do smth for fun.

About managing the project, I think going using "esoteric" compiler features is not the best way to go (even apart from VS compilation issue), you trigger the negative feedback loop : less contributors, less complaints, less improvements... Few people complain about things, if one cannot understand the code it is natural just to avoid working with it... And I am dead serious, all developers in our current software team, or ones from our former team at Intel (I worked there for 10 years), would not understand those new macros, and some simply laughed when I asked them about variadic macro support several days ago.  Not to say that I "really hate" those macros as some of the developers do, should at least understand them before expressing any opinion. Could vbe interesting in fact, and maybe there is a valid use case here.

About the real help that I ask from you, it is not guesses how to fix things in Visual Studio (as I know VS better and should be able to do it), but only to explain how things work in current Rebirth implementation (still don't understand the functionality of valptridx macros for example), and - optionally - possible ways to simplify it. If we decide to work on it, first I should understand every offending macro to bits, what it does and how it works, and come out with suggestions how to change it to be compilable in VS. The changes should be minimal, of course - and here you probably could recommend smth as you understand those macros better. And I don't believe it can lose flexibility or any functionality from it. How to test/integrate it, probably we should think when it will compile in VS. Waiting for VS updates/fixes could take years, and we always have this options anyway. They are tracking recent standard changes, but do it very slowly.

Also that D2X boss bug (Magnacore boss glitch) really drives me up the wall, there is no workarounds, it manifests in all Rebirth version, and you simply cannot have normal boss fight for some bosses! And worse yet once it happened it stays in any saved game and any further attempts on the same - or even the next - level (until you reload the game)!
Reply
#10
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: And it should not be hard to install VS on a virtual machine with Windows, yes it is unfortunate that VS does not work on Linux natively or on Wine.
When last I tried that, it was extremely painful because Visual Studio 2017 was not available for download. Rather, Microsoft made available a Windows-only downloader that would download the actual program when run. This was justified on the basis that Visual Studio was simply too customizable and that no one would want all the features, so it was best to force you to download only the specific features you wanted, rather than the more traditional approach of downloading a single monolithic installer and choosing which pieces it copied to the drive. This is not a bad idea in principle, but the inability to wget the required files made this unnecessarily difficult.

All that aside, you're assuming I have a Windows virtual machine. The newest Windows VM I have is Windows XP, which Visual Studio 2017 cannot run on.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: What you mean by this pointer subtraction thing? Usually for the compiler there is no difference what you subtract, it generates smth like sub rax, rbx instruction anyway, maybe you mean that if those are pointers to structures the result of the abovementioned instruction should be divided by structure size (which is a slowdown indeed)?
Yes, exactly. When subtracting one pointer from another, the result is the offset, so it must be divided by size-of-element. Classic Parallax code had (or at least claimed to have) power-of-2 structure sizes to make this small and cheap. By the time I took up Rebirth, that power-of-2 relation was not true, so the division was no longer a simple arithmetic right shift.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: I cannot compare code size of course, because I am unable to compile it.
You cannot compile 0.58.1 in Visual Studio because there are no Visual Studio project files for it, nor can you compile current in Visual Studio because of the problems in this thread. Both can be built in gcc, and that is where I derived my measurements, which you can cross-check using MinGW.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: And probably all those new checks are not compiled in release build(which should be so), so they should not inluence the exe size at all...
It depends on the setting of various macros. Generally, I include those checks because they have caught so many bugs. Whether they are enabled or disabled in any given build is up to the person building them.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: I think going using "esoteric" compiler features is not the best way to go (even apart from VS compilation issue), you trigger the negative feedback loop
In the abstract, you are right. In practice, there seems to be no loop, or it has already run its course.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: And I am dead serious, all developers in our current software team, or ones from our former team at Intel (I worked there for 10 years), would not understand those new macros, and some simply laughed when I asked them about variadic macro support several days ago.
That is surprising. These macros are not even complex. I have worked with software that was much worse.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: Not to say that I "really hate" those macros as some of the developers do, should at least understand them before expressing any opinion. Could vbe interesting in fact, and maybe there is a valid use case here.
If you can produce a template-equivalent of the valptridx error reporting macro, go ahead. The only ways I can see to rewrite it still require C99-conforming macro expansion, just at a less complex level. Visual Studio does not have that, so even the rewritten versions I considered would not work for you (though they would likely be clearer to people who do not read macros well).

The key feature you need is: given a macro parameter, which you then paste with a literal string, test whether the resulting pasted token is defined as a macro. You cannot use defined() inside a macro expansion, so you need a way to fake it. That is what this macro trickery does, by exploiting comma parsing order to generate a comma when the token is defined and no comma when it is undefined.
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: About the real help that I ask from you, it is not guesses how to fix things in Visual Studio (as I know VS better and should be able to do it), but only to explain how things work in current Rebirth implementation
I drafted the below as a potential explanatory comment to add to cpp-valptridx.h for this macro. If you think this sufficient, I will commit it. If you have further questions, I will clarify it before committing it.
Code:
diff --git a/common/include/cpp-valptridx.h b/common/include/cpp-valptridx.h
index 0ea05be07..934876ed1 100644
--- a/common/include/cpp-valptridx.h
+++ b/common/include/cpp-valptridx.h
@@ -256,6 +256,55 @@ public:
#endif

#define DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH(A)    DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH_##A
+/* This approximates the ability to test defined-ness of a macro
+ * argument, even though `#if defined(A)` cannot portably be used when
+ * `A` is a macro parameter.  A Python function that does the same (but
+ * more cleanly and safely) as this macro would be written as:
+ *
+ * ```
+ *    def DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_DISPATCH(A,B,C,D):
+ *        for candidate in (A, B, C, D):
+ *            if cpp_macro_defined(candidate):
+ *                return cpp_macro_expand(candidate)
+ *        return ''
+ * ```
+ *
+ * Each of the four arguments evaluates, after macro expansion, to one of five values:
+ * - `undefined`
+ * - `trap_terse`
+ * - `trap_verbose`
+ * - `exception`
+ * - anything else
+ *
+ * Pass each argument to a separate
+ * DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH.  If the argument is one of
+ * the four recognized values, then after pasting, it will be one of the
+ * four DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH_* macros, and will
+ * expand to contain a leading and trailing comma.  If it is
+ * unrecognized, it will not expand[1] and will therefore contain no
+ * commas.  After expansion, the arguments to
+ * DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_UNPACK_ARGS are:
+ *
+ * -    0-or-more garbage non-comma tokens resulting from arguments that
+ *        were "anything else"
+ * -    comma from the first matched argument
+ * -    token from the first matched argument (which will be one of the
+ *        four accepted types)
+ * -    another comma from the first matched argument
+ * -    0-or-more tokens from later arguments, which may or may not have
+ *        been "anything else" and may or may not include more commas
+ *
+ * The call to UNPACK_ARGS then drops everything up to and including the
+ * first comma from the first matched argument and everything at and
+ * after the second comma from the first matched argument.  It passes
+ * through the non-comma token from the first matched argument, yielding
+ * one of the four recognized types.
+ *
+ * [1] Assuming no definitions for
+ * DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH_* other than the four
+ * above.  For proper operation, no other macros should be defined with
+ * that prefix.
+ */
#define DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_DISPATCH(A,B,C,D)    \
    DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_UNPACK_ARGS(    \
        DXX_VALPTRIDX_INTERNAL_ERROR_STYLE_BRANCH(A)    \
(01-25-2018, 06:09 AM)AlexanderBorisov Wrote: Also that D2X boss bug (Magnacore boss glitch) really drives me up the wall, there is no workarounds, it manifests in all Rebirth version, and you simply cannot have normal boss fight for some bosses! And worse yet once it happened it stays in any saved game and any further attempts on the same - or even the next - level (until you reload the game)!
That is very interesting. To be sure I understand, each of these lists are true?
  1. Start Rebirth from desktop.
  2. Play game.
  3. Save game.
  4. Boss exhibits bug.
  5. Load saved game. Boss will continue to exhibit bug.
  6. Quit Rebirth. Start Rebirth from desktop.
  7. Load saved game. Boss will not exhibit bug.
  1. Start Rebirth from desktop.
  2. Play game.
  3. Boss exhibits bug.
  4. Save game.
  5. Load saved game. Boss will continue to exhibit bug.
  6. Quit Rebirth. Start Rebirth from desktop.
  7. Load saved game. Boss will not exhibit bug, even though it was present when the game was saved.
  1. Start Rebirth from desktop.
  2. Play game.
  3. Boss exhibits bug.
  4. Finish level. Proceed to next boss.
  5. Next boss is guaranteed to exhibit bug.
If so, this sounds like a stale global (<sarcasm>which I find absolutely shocking, because this game has never had bugs with stray globals before</sarcasm>).
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)