Hamlet

I successfully run with version 2.05 (downloaded binaries), and with compiled sources (with some patching, up to commit r6834).

Thank you for the answer.

O, I see... I think. The updater log reports updating to version 2.05, and SVN code requires "assets" newer than that. My peruse of the forum search suggests that the assets repository is not public. Anything I can do to work around that?

Hello all, I am trying to compile and play The Dark Mod under my platform (Gentoo Linux). After patching the patchable to make it compile, it turns out that no rendering is shown on screen at all: black screen (with resolution change), mouse is responsive and I can hear the reaction of the GUI to its movement (clicks and all); also the background music (soothing, charming, beautiful... but that you know already) cuddles my ears. I started the bisection of the code from version 2.05 (I think... it was r6753) to r7203. It took me a while (none of the commits compiles out of the box, and different ones require different patches), and in the end I found that r6834 works for me (at least the menu screen!), while r6835 does not any more (as above). I have the output to screen of two runs. In thedarkmod-r6834.txt, I started it with no arguments, and then quit. In thedarkmod-r6835.txt, I started it with no arguments, then I switched to a text console and killed it (because I could not see the GUI to quit). The only files that changed between the two runs are thedarkmod.x86, gamex86.so and tdm_game02.pk4. Any suggestion for me to have this work?

I can use either an empty function, void GLimp_DeactivateFrontendContext() {}or a function similar to what you suggest in the quote: void GLimp_DeactivateFrontendContext() { assert( dpy ); qglXMakeCurrent( dpy, None, NULL ); } (this is actually the same as Linux implementation of GLimp_DeactivateContext())... Where should I look for failure when testing? Just to be clear: I have no clue what I am doing, here. Actually, I can't because I have another army of missing functions after this one... but that's for another thread, since it's from a different commit.

I am trying to compile The Dark Mod (r7203) under Linux. It appears commit r7128 calls GLimp_DeactivateFrontendContext() (framework/Session.cpp line 3017), whose implementation is not provided for Linux (sys/linux/glimp.cpp), while it is provided for Windows (sys/win32/win_glimp.cpp). Any solution to this?

And, about people late at the party: when I run with a dual monitor configuration, I believe my gamma settings got applied to one of the monitors only. If that may be of any use, when I get hold again of a second monitor I can try to investigate further and spit out the details of my configuration. After all, it might be anything: kernel, X, window manager, graphic drivers...

This is the kind of question hard for one like me with no experience in anything of The Dark Mod to answer. In fact, I was hoping some other reader could connect more dots. My contemplation of the code tells me that "AF" is Articulated Figures, which I may think objects which are not rigid. In this sense, it makes sense to have constraints between the rigid parts of the figure, which is what both enumerators enumerate. The issue is shown in idAF::Load(idEntity *ent, const char *fileName), which suggests it's trying to load data from a file. It is in a double loop where constraints are deleted from a physics object. So I guess what could happen is that the wrong constraints are deleted and the object does not react like it should to being dragged around.

My understanding is too small to answer the first question: I learned what LWO means after reading the previous post. I also don't know what a "clip" is. The main reason of my post is to see if the experts have anything to add to the picture, that might predict a type of failure or to connect this to an already observed one. I can see the dubious function being called when a ID_RIMG or ID_TIMG is found, in code that looks like a parser. The former seems related to reflection effects on a surface, the latter ends in the parameters of a texture. Maybe there might be effects related to clipping of these surfaces and textures? Just wildly guessing here. About the patch: I do not claim to have tested it properly yet, and as always I personally recommend not merging it into anything official until that happens.

This is another report originating from a GCC warning, in this case the comparison of two different enumerators. This works by converting each of the two enumerators into a numeric value, and comparing them instead. In general, an enumerator is better used in a way that does not depend from its value at all. If the value is needed, constants are generally better suited. The relevant one of the two warnings comes from idAF::Load() in game/AF.cpp (line 910), where a variable of enumerator type declAFConstraintType_t from framework/DeclAF.h: typedef enum { DECLAF_CONSTRAINT_INVALID, DECLAF_CONSTRAINT_FIXED, DECLAF_CONSTRAINT_BALLANDSOCKETJOINT, DECLAF_CONSTRAINT_UNIVERSALJOINT, DECLAF_CONSTRAINT_HINGE, DECLAF_CONSTRAINT_SLIDER, DECLAF_CONSTRAINT_SPRING } declAFConstraintType_t;is compared with a variable of enumerator type constraintType_t from game/physics/Physics_AF.h: typedef enum { CONSTRAINT_INVALID, CONSTRAINT_FIXED, CONSTRAINT_BALLANDSOCKETJOINT, CONSTRAINT_UNIVERSALJOINT, CONSTRAINT_HINGE, CONSTRAINT_HINGESTEERING, CONSTRAINT_SLIDER, CONSTRAINT_CYLINDRICALJOINT, CONSTRAINT_LINE, CONSTRAINT_PLANE, CONSTRAINT_SPRING, CONSTRAINT_CONTACT, CONSTRAINT_FRICTION, CONSTRAINT_CONELIMIT, CONSTRAINT_PYRAMIDLIMIT, CONSTRAINT_SUSPENSION } constraintType_t;The comparison of values from two distinct enumerator types should be avoided because it requires the enumerator modifications to be synchronised, but it's very tempting to add an element to one forgetting about the other. If this comparison is really required, there should be a single enumerator type. Judging from the enumerator names, this departure from synchronisation has already happened (I would except a DECLAF_CONSTRAINT_SLIDER to be equivalent to a CONSTRAINT_SLIDER, and instead it's compared to a CONSTRAINT_HINGESTEERING). The two definitions are in different parts of the code and do not apparently share headers. But more to the point, for what I know these numerical values might be serialised, and changing them would break saved data. My recommended suggestions would be: if possible, manage to have a single enumerator for both usesif not, abandon direct comparison and use a slower multiple-choice comparison function.I provide a patch implementing the latter suggestion, which is expected not to break any serialised data, by not changing the enumerator values. Note that this function relies on the heuristic logic of my brain to match the elements from the two enumerators. Somebody with some understanding should cross check it. The patch also addresses the other enumerator comparison, which is more subtle and is caused by the fact that enumerators defined in a template class yield one different enumerator type for each template instantiation. enumCompare.patch.txt

While analysing the warnings emitted by GCC 6, I was pointed to this piece of code in renderer/Model_lwo.cpp (comment added): int sgetI1( unsigned char **bp ) { int i; if ( flen == FLEN_ERROR ) return 0; i = **bp; if ( i > 127 ) i -= 256; flen += 1; *bp++; // <== warning: unused value return i; } short sgetI2( unsigned char **bp ) { short i; if ( flen == FLEN_ERROR ) return 0; memcpy( &i, *bp, 2 ); BigRevBytes( &i, 2, 1 ); flen += 2; *bp += 2; return i; } Starting from the second function, sgetI2(), it appears that it receives as argument a pointer to an unsigned character, passed by reference in C style (that becomes a pointer to the pointer).It copies two bytes in a short, swap them as needed (handling little/big endian, I suppose), then it makes the pointer *bp point after the copied data and returns the value read. There is a sgetI4() which does the same with 4 byte data. Back to the first quoted, I was assuming sgetI1() would do the same. GCC complains that the statement *bpp++ produces an unused value. It turns out, the postfix increment operator (a++) has the highest priority among C and C++ operators, and it gets executed before the dereference operator. That means that I would expect the code to operate like (*bp)++, equivalent to *bp += 1, similarly to sgetI2(), but I get instead a *(bp++). This means that the local variable bp (unsigned char**) is increased (while the unsigned char* pointer *bp is not), and then the value it was pointing to before the increase is taken and ignored. All in all, it means that when it's called as sgetI1(&ptrToBuffer), it returns the value at the current value of ptrToBuffer and, on the next call, sgetI1(&ptrToBuffer), it returns again the same value, since ptrToBuffer is not increased. The same construct appears in sgetU1() and in add_clip() on nclips (a simple pointer int*), where it might have more serious consequences: *nclips++; clip->index = *nclips; since the an index is assigned from the cell of memory next to nclips (nclips is first increased).I can't find any place where the former two are used, while add_clip() is pulled in from LoadLWO() in renderer/Model.cpp (at which point I stopped tracking). I attach a trivial patch that removes these warnings by just doing the thing that would be usually expected (increase the pointed value) (it also removes the other instance of it, not mentioned in this text). Edit: discovered that syntax highlight for C/C++ works with code type "auto", even if it does not show in the preview. UnusedValue.patch.txt

Why not to push it in a branch now? That would give willing people the chance to test it easily without compromising trunk, and after it's proven that it compiles in the other supported platforms, you can merge it to trunk.

I have learned a few other things from reading (and "fixing") the warnings. Of the "bug candidate" type. Which would the more proper place/way to discuss them be? P.S. I have not investigated the memset change yet.

If this project is really considering to require the compiling users to provide Boost (32 bits) from their own system, then it's probably time for me to scratch my head and my search engine to find a good Boost installation macro for AutoConf. The one you ship failed miserably on my system, and there might be some better ones. Also I suppose that Windows and OSX users already pick Boost from the system? Anyway, let me know. Note that the first word in my statement is a true if. This project may decide that it's too much to ask to the users, or that it's too much of a burden to suddenly have to cope with the less-than-stable Boost interface in the wild. My personal opinion is that it's worth, but I might even be... wow, wrong! Last word for NightStalker: we all have a real life, we all take our time. I don't think you'll be blamed for that, and I am sure you shouldn't be. Newcomers (that is me!) typically have a burst of enthusiasm... I am sure I'll calm down soon. (also I am not going to commit anything, and thrice-especially not on trunk).

Hello all, this is not exactly a generic offer for help... While compiling The Dark Mod with GCC on Linux I have witnessed an endless stream of warnings. I would like to resolve those warnings so that the code becomes standard C++. And I would like to know if the project is interested in the resulting patches. I have started already. Just because, believe it or not, for me that's somehow fun. I have enabled all warnings and pedantry, identified about 30 types of warning, and I am bashing them one by one. An example of motivation: GCC (6.2) tells me: renderer/Model_ase.cpp: In function ‘void ASE_KeyGEOMOBJECT(const char*)’: renderer/Model_ase.cpp:724:37: error: argument to ‘sizeof’ in ‘void* memset(void*, int, size_t)’ call is the same expression as the destination; did you mean to dereference it? [-Werror=sizeof-pointer-memaccess] memset( ase.currentMesh, 0, sizeof( ase.currentMesh ) ); ^ That is: it finds a bug (or at least it looks so to me), and it even tells the right solution. And this warning hasn't been noticed because swamped in others that are surely harmless. Of course this example shows also the limit of the approach: what if that unusual statement was intentional? I would be introducing a bug instead. So I may need to ask some questions along the way. I intend to direct my effort to ISO C++ 2003 compliance first, and then consider ISO C++ 2011, if the project thinks it's ok. But that will be far from now. I also do not intend to touch the C code, because I am not as fluent there. This also means that the result should be welcome by any compliant compiler on any platform, and by now I suppose even MicroSoft compilers are compliant to C++03. I can imagine the project would rather see this energy devoted to other items in the to-do list... but in my mind this one is a necessary step toward bug fixing. Ball in your field, comments are welcome.