duzenko
-
Posts
4159 -
Joined
-
Last visited
-
Days Won
50
Posts posted by duzenko
-
-
I have no way to compile under Windows, though. So if anyone who has that capability could make sure that nothing breaks under Windows (compile-wise at least and, ideally, run-time-wise) that would be very much appreciated.
Compiles to me in vs2013 with your patch.
TRUNK! TRUNK! TRUNK!
-
It sounds like in this case, the GCC compiler is more capable than the Windows compiler, even though this bug (and make no mistake, this is a bug!) affects all OSes. I have a feeling that, overall, the GCC compiler may be much more thorough than the Windows compiler, but I have no hard evidence for this, only my experience over many years of the GCC suite getting better and better at finding problems in my (and others') code. If the Windows compiler has the equivalent of the GCC compiler options "-Wall" ("enables all the warnings about constructions that some users consider questionable") and/or "-Wextra" ("enables some extra warning flags that are not enabled by -Wall"), then it might be wise to enable them (assuming they aren't already), to see what folks compiling under Windows may have been missing for a while. In fact, I'd ask anyone compiling TDM under Windows (duzenko, maybe?) to check: Did it warn about this particular "memset()" call?
With EnableAllWarnings (/Wall) MSVC swallows Model_ase.cpp quietly.
the Dhewm branch has removed the memset. That's a pretty good endorsement for it's removal.
Agree.
-
I don't like warnings-laden code as well.
However in that particular example with sizeof, what would be the fix?That looks like a bug - but who knows what the fix is - clear the pointer, dealloc mem or zero fill ? Or maybe comment out that line altogether?
-
I think Windows build has the boost libs in TDM svn:
src\win32\lib
-
Actually, I believe that Hamlet's patch in the post immediately above yours will help.
Oops, that hurt
.It kinda compiles for me now
. Didn't test how it runs because I'm on a VM and you guys run it on real hardware.Here's my svn patch that combines the changes from multiple Hamlet's patches.
I think we're at the point where it should be applied to trunk.
Index: game/gamesys/TypeInfo.cpp =================================================================== --- game/gamesys/TypeInfo.cpp (revision 6735) +++ game/gamesys/TypeInfo.cpp (working copy) @@ -17,6 +17,29 @@ ******************************************************************************/ +// As stated below, the trick of defining "private" and "protected" is pure evil. +// We pay for it in class definitions that implicitly declare private members +// without using the (default) private visibility declaration. +// This becomes a real problem in code like the one found in GCC 6.2, along the lines: +// +// class Class { +// struct PrivateStruct; // forward declaration +// // ... +// private: +// struct PrivateStruct {}; // actual definition +// }; +// +// In this case, PrivateStruct is implicitly declared private, and then defined as +// "private", that after our trick becomes "public". Joy ensues. +// We import all the things like that before the trick takes places. +// We loose access to some variable inspection, but we gain in compilability +// (and a bit in sanity). +#if defined(__GNUC__) && (__GNUC__ == 6) +// these were observed in GNU GCC 6.2.0 (not in 5.4.0): +#include <sstream> + #endif // if GCC 6+ + + // This is real evil but allows the code to inspect arbitrary class variables. #define private public #define protected public Index: game/pugixml/pugixml.hpp =================================================================== --- game/pugixml/pugixml.hpp (revision 6735) +++ game/pugixml/pugixml.hpp (working copy) @@ -17,6 +17,9 @@ #include "pugiconfig.hpp" #ifndef PUGIXML_NO_STL +#if defined(__clang__) || defined(__GNUC__) +#include <string> +#else namespace std { struct bidirectional_iterator_tag; @@ -43,6 +46,7 @@ template <> class char_traits<char>; #endif } +#endif // if not clang nor GCC #endif // Macro for deprecated features Index: idlib/geometry/RenderMatrix.cpp =================================================================== --- idlib/geometry/RenderMatrix.cpp (revision 6735) +++ idlib/geometry/RenderMatrix.cpp (working copy) @@ -40,11 +40,13 @@ #include "../bv/Bounds.h" #include "RenderMatrix.h" -//anon begin -- just comment this out to disable intrinsics -#define USE_INTRINSICS -#include <intrin.h> -#include "sys_intrinsics.h" -//anon end +//anon begin -- just comment this out to disable intrinsics +#ifdef _MSC_VER +#define USE_INTRINSICS +#include <intrin.h> +#include "sys_intrinsics.h" +#endif // if MicroSoft Compiler +//anon end // FIXME: it would be nice if all render matrices were 16-byte aligned // so there is no need for unaligned loads and stores everywhere Index: include/devil/IL/devil_internal_exports.h =================================================================== --- include/devil/IL/devil_internal_exports.h (revision 6735) +++ include/devil/IL/devil_internal_exports.h (working copy) @@ -24,7 +24,7 @@ #ifndef NOINLINE #ifndef INLINE #if defined(__GNUC__) - #define INLINE extern inline + #define INLINE /* extern */ inline #elif defined(_MSC_VER) #define NOINLINE #define INLINE Index: include/devil/il_bmp.h =================================================================== --- include/devil/il_bmp.h (revision 6735) +++ include/devil/il_bmp.h (working copy) @@ -71,11 +71,11 @@ ILboolean ilReadRLE4Bmp(BMPHEAD *Info); ILboolean iGetOS2Bmp(OS2_HEAD *Header); -#ifdef IL_BMP_C +/*#ifdef IL_BMP_C #undef NOINLINE #undef INLINE #define INLINE -#endif +#endif*/ #ifndef NOINLINE INLINE ILvoid GetShiftFromMask(const ILuint Mask, ILuint * CONST_RESTRICT ShiftLeft, ILuint * CONST_RESTRICT ShiftRight) { Index: include/devil/il_endian.h =================================================================== --- include/devil/il_endian.h (revision 6735) +++ include/devil/il_endian.h (working copy) @@ -56,36 +56,36 @@ #define BigDouble(d) iSwapDouble(d) #endif -ILvoid iSwapUShort(ILushort *s); -ILvoid iSwapShort(ILshort *s); -ILvoid iSwapUInt(ILuint *i); -ILvoid iSwapInt(ILint *i); -ILvoid iSwapFloat(ILfloat *f); -ILvoid iSwapDouble(ILdouble *d); -ILushort GetLittleUShort(); -ILshort GetLittleShort(); -ILuint GetLittleUInt(); -ILint GetLittleInt(); -ILfloat GetLittleFloat(); -ILdouble GetLittleDouble(); -ILushort GetBigUShort(); -ILshort GetBigShort(); -ILuint GetBigUInt(); -ILint GetBigInt(); -ILfloat GetBigFloat(); -ILdouble GetBigDouble(); -ILubyte SaveLittleUShort(ILushort s); -ILubyte SaveLittleShort(ILshort s); -ILubyte SaveLittleUInt(ILuint i); -ILubyte SaveLittleInt(ILint i); -ILubyte SaveLittleFloat(ILfloat f); -ILubyte SaveLittleDouble(ILdouble d); -ILubyte SaveBigUShort(ILushort s); -ILubyte SaveBigShort(ILshort s); -ILubyte SaveBigUInt(ILuint i); -ILubyte SaveBigInt(ILint i); -ILubyte SaveBigFloat(ILfloat f); -ILubyte SaveBigDouble(ILdouble d); +inline ILvoid iSwapUShort(ILushort *s); +inline ILvoid iSwapShort(ILshort *s); +inline ILvoid iSwapUInt(ILuint *i); +inline ILvoid iSwapInt(ILint *i); +inline ILvoid iSwapFloat(ILfloat *f); +inline ILvoid iSwapDouble(ILdouble *d); +inline ILushort GetLittleUShort(); +inline ILshort GetLittleShort(); +inline ILuint GetLittleUInt(); +inline ILint GetLittleInt(); +inline ILfloat GetLittleFloat(); +inline ILdouble GetLittleDouble(); +inline ILushort GetBigUShort(); +inline ILshort GetBigShort(); +inline ILuint GetBigUInt(); +inline ILint GetBigInt(); +inline ILfloat GetBigFloat(); +inline ILdouble GetBigDouble(); +inline ILubyte SaveLittleUShort(ILushort s); +inline ILubyte SaveLittleShort(ILshort s); +inline ILubyte SaveLittleUInt(ILuint i); +inline ILubyte SaveLittleInt(ILint i); +inline ILubyte SaveLittleFloat(ILfloat f); +inline ILubyte SaveLittleDouble(ILdouble d); +inline ILubyte SaveBigUShort(ILushort s); +inline ILubyte SaveBigShort(ILshort s); +inline ILubyte SaveBigUInt(ILuint i); +inline ILubyte SaveBigInt(ILint i); +inline ILubyte SaveBigFloat(ILfloat f); +inline ILubyte SaveBigDouble(ILdouble d); #ifdef IL_ENDIAN_C #undef NOINLINE -
Crinkelite: If you have not already done so:
duzenko: When you return:
I would encourage you both to take a look at Hamlet's patches, specifically the 'pugi_strings.patch.txt' patch. I think it will further your compilation attempts under Ubuntu 16.10.
I would be interested to hear your results if you get a chance to try it.
Pugxml has stopped complaining with that patch. It's good to be applied to trunk IMHO.
Now I have this access redeclaration error. AFAIR it was mentioned somewhere already but can't remember where and whether it has been sorted out.
P.S. Great job so far, Hamlet, NightStalker
-
1
-
-
Don't give the issue any more thought or worry -- kick back, relax, and enjoy your time away. I'll be ready when you get back.
SVN revision: 6735
-
2
-
-
OKWhenever you're ready, please develop a patch to test for the appropriate GL capability, set a flag accordingly, and replace the "if (1)" check with "if ({flag-name})". Shoot me the patch, I'll test it out thoroughly, and check it into SVN when it's working. Sound good?
-
Probably not worth trying.No. I'm running 304.132 (circa 26 Sep 2016). The latest is 304.134. I'd already downloaded it 2 days ago but haven't installed it because the changelog between 304.132 and 304.134 has only 2 entries, neither of which seemed to be relevant to this issue. At some point, I will upgrade the video driver, but I didn't want to do that in the middle of testing. Something I did do (but failed to mention) -- I removed the 2nd video card (the 640GT), but it offered no improvement. I left it out for now anyway.
...
Thanks for the suggestion. I will try that at my next opportunity and report back.
They have stopped supporting 7600gt years ago, so Sep 2016 is as good as any other.
And EXT_pixel_buffer_object is not in the ext list either.
...
I wonder how many people run TDM on gt7000 generation gpu's.
I used to own one and it was great until it burned.
Happy for them if they run TDM under windows so that the pixel pack thingy is functional.
I wish there was a way to enable it under Linux but regret nVidia decided to screw the Linux guys on this one.
-
I'm no OpenGL guru but I think that's something else.GL_EXT_packed_pixels
I think we should be looking for one of these: ARB_pixel_buffer_object and EXT_pixel_buffer_object.
Apparently your Linux driver is not advertising any of these even though the hardware is probably capable so technically it's correct and the fault is in my code.
My excuse is
1 - none of the pixel pack examples on web are doing the ext check
2 - 7600gt is really old
3 - windows driver supports this ext and 7600 gt is known to be 2.1 compatible
4 - most of people with dual card system run their 3d games on the newer card
But it's still my fault of course.
Here's how it looks for me (intel 515)
-
So in the end it's what appears to be a driver bug.As an aside, I also tested with the same exact hardware, but using 2.05-beta under Windows XP. It runs fine there, which tends to make me suspect a video driver issue rather than the video hardware. Regardless, the patch needs hardening.
Is your driver the latest for this GPU?
What is the reported opengl version? I think it should be 2.1 for pixel pack.
I absolutely agree that there should have been more checks on glGetError.
I will fix that when I'm back unless someone fixes it before.
...
What happens if you replace GL_PIXEL_PACK_BUFFER with GL_PIXEL_PACK_BUFFER_EXT?
-
Will do, ETA 27.12.16.
-
Sadly, while this change did offer a nice little performance boost, it was completely blown out by Duzenko's awesome
"Pixel Pack Buffer" optimization which offered a HUGE performance boost.
Thus relegating my fix to thecategory of "a minor improvement".
Pixel pack may show more difference on a fully-clocked system, but my laptop CPU throttles all the way to 1.1GHz under full load and your optimization makes a better job in that case.
-
2
-
-
Can't comment on Baal's error since I don't have access to that forum and Baal is not posting here.
R_ParseImageProgram_r is old code that has not been changed for years. Problem could be in code that executes before that, e.g. idImage::GenerateImage but since neither you nor me can repeat the error then we can't prove it is fixed.
VC was short for videocard. I think the 640 you have as secondary output is way newer and more powerful than 7600gt.
My suspicion here is that 7600gt may not fully support the pixel pack feature on the hardware level.
So running TDM on 640 would tell us if TDM maybe is not properly checking if the driver/hardware supports the required feature before using it.
I will be traveling for the next 7 days and will be AFK most of the time. I hope it's not going to be a big inconvenience for you. I just want you to know that Linux build is priority #1 right now for me when it comes to TDM.
-
Yes, but I have no idea what version of GCC comes with Ubuntu 16.10. Can you please run 'gcc --version' and report that (both now and anytime you switch to another Linux distro for compiling)?
Thanks for the URL. It looks like it will be useful at some point.
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
-
Where to from here?
Has the svn access been granted finally?
Should I ifdef this in the mean time?
...
Nightstalker,
you mentioned you have 7600gt as primary and a newer one as secondary.
I'm curious if recent TDM crashes when running on a newer VC monitor?
-
Parts of this discussion are not really technical IMHO and would be irrelevant flood in there
-
I did not put cvar because I did not expect any blowback and did not have access to svn
Still need to confirm that's it.
Not sure if cvar is optimal solution if it works on windows and not on linux - ifdef?
The if (1) is just a toggle-able alternative to //
I used it in a couple more places since then.
-
As for the memcpy crash.
There is one memcpy in the code I contributed:
void idRenderSystemLocal::CaptureRenderToBuffer(unsigned char* buffer)
Does it crash if you toggle the
if (1)
in there?
-
In fact, I've gone beyond that, bisecting the source code backwards from the latest SVN and building TDM many times, to try to identify the change(s) that cause the crash. But I gave up in frustration (and exhaustion) after finding a reference point (SVN #6642) that successfully compiled but, sadly, failed to actually run a mission. Since I obviously didn't make any of those SVN commits between 2.04 and 2.05 (let alone between 2.04 and latest SVN), I'm not best qualified to determine what broke the build. And I stated as much in my post about all this.
When Baal asked (on Dec 8th) for the 2.05-beta source code, which is something I was 1 breath away from doing myself, he's told to "PM taaaki". Both he and I PMed taaaki for access to the source code, myself on 10 Dec 2016. Today, 9 days later, I still have not gotten a reply to that PM.
I'm still waiting Taaki to answer my month-old request
It's not like he ignores you only. #6642 crashes for you - how about #6640 or #6637?
I could probably upload a particular svn branch if you aren't granted access in the next hours.
P.S. I really appreciate your efforts, and I admire the "do it now" spirit a lot. AFAIR Grayman warned that he has really little time this time of year.
-
NightStalker,
It's ubuntu 16.10 32-bit, default gcc that comes with it.
My web searches resulted in this
I had no time to test this just yet
One thing I should probably mention is that Compilation guide did not exactly work for me.
sudo apt-get install g++ scons libglew1.5-dev libpng12-dev libjpeg62-dev
threw errors beyond my understanding so I dropped 1.5 and 12 and 62.
-
I was going to apply it in trunk w/o testing but I was confused by people in this thread who said they had applied it.
Now I leave it to Grayman.
So, umm... Hamlet, Crinkelite, you compiled 2.04, or 2.05, or trunk?
-
NightStalker,
Can you try image_mipmapMode 0?
I also have this error when compiling trunk under 32-bit ubuntu:
In file included from game/script/Script_Doc_Export.cpp:26:0: game/script/../pugixml/pugixml.hpp:1070:2: error: reference to ‘basic_string’ is ambiguous std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > PUGIXML_FUNCTION as_wide(const char* str); ^~~ In file included from game/script/Script_Doc_Export.cpp:26:0:
-
Hm, if you had 3 fps on HD4250 before then 9 fps on 720 must absolutely feel smooth
Getting 2.05-beta To Compile and Run Under Linux
in TDM Tech Support
Posted
I think 6735 should be merged to 2.05 for the reasons listed in #27
6736 probably best left for 2.06