Jump to content
The Dark Mod Forums

Hamlet

Member
  • Posts

    24
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Hamlet

  1. I successfully run with version 2.05 (downloaded binaries), and with compiled sources (with some patching, up to commit r6834).
  2. 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?
  3. 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?
  4. 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.
  5. 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?
  6. 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...
  7. 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.
  8. 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.
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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).
  14. 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.
  15. I have entered sheep mode some posts ago, and I am comfortable with that. I am writing this just to clarify that I have no idea of what the purpose of this test is, so I hope somebody knows. I am glad to provide information, but in the end except for a non-reproduced abortion and a non-reproduced strange A.I. quirk, I am not noticing anything strange. Ok, back to business. I have restored the "official" version of executable and shared library (that is gamex86.so) and run the two commands. I realise I did not remove the special material for the light gem that is needed for a future revision... I hope that does not affect your conclusions. The following is the log from the training mission. And this is the one from William Steele the Third: In addition to the previous information, I add that the video board mounts a Radeon HD 7870 chip.
  16. If may be of help... I felt my virility diminished by the fact that Ubuntu uses GCC 6.2 and I do not, so I installed the latter and now my psychic balance is restored. Compilation by GCC 6.2.0 of The Dark Mod with a set of patches that worked with GCC 5.4 went fairly well, except for one point. After all, you cant reasonably expect to get away with redefine'ing private into public. I am attaching a patch (gcc6-TypeInfo.patch.txt) that addresses the specific problem I encountered by including the "problematic" header before that redefinition happens. If other libraries (on any compiler) trigger the same problem in TypeInfo.cpp, the same approach can be used.
  17. I am not sure I understand the request, but I will try. Tell me if and how I misunderstood you. I started the mission "William Steele 3: Cleighmoor" (I was playing Saint Lucia before) via graphic interface, then I quit and run: ./thedarkmod.x86 +developer 1 +map ws3_cleighmoor +developer 1 +logfile 2 which I inferred from somewhere in the post you linked. Then I played a bit with my room lights on, which is good when you want William to end up sliced soon. William ended up sliced soon. Then I quit. Again no crash. Peeking in the darkmod/fms/ws3_cleighmoor I found a darkmod.txt and a qconsole.log (that in the attachment magically becomes qconsole.txt). I was not stricken with meaning after reading them, but you know better. By the way, I remember Quake having some demo mode... does Doom 3/The Dark Mod have anything similar? Playing a demo may be invaluable to perform this type of diagnosis across different people and platforms. darkmod.txt qconsole.txt
  18. (this is a follow up from a question in My experience with The Dark Mod under Linux) I am writing a new post on a question that I think is better to follow its own thread. If this is against the policy or the custom, I apologise - please let me know in that case. I had not tried. I am not very willing to play that mission since I haven't played the previous two (and my skill are shaped so far only by the training mission), but I can do some testing. At this point it's relevant that I know what I am looking for. I downloaded it and started it. first time: looked at the introduction, spent a few minutes to realise I needed to click on the bottom arrow to get the next part of the introduction, then toward the end of the introduction I was slammed at the command prompt, no evidence of crash. Strange... second time: I tried to skip the introduction; I found William in a dark tunnel, very very dark, my desk lamp not helping. So I asked him to turn on his lantern... fortunately he had one. Then I made a few steps forward to reach an intersection, just to hear a person passing in front of me, dressed like a guard. He ignores me and keeps muttering despite my light gem is white surrounded by red surrounded by ringing bells and an orchestra playing Richard Strauss. I assume that he just has nothing against me. After all, not always we are the suspect types. When he gets at the turn of the tunnel, maybe ten meters away, it suddenly realise that somebody was playing Strauss and he has no iPod, and becomes suspicious. I douse my lantern, I let him look for me for a while and then I quit. No crash at all this time. third time: I duly waited for the intro to transition into the mission, and when it did not happen for long enough I clicked on the X at the bottom. The mission started, and I led William to wander around the sewers until a guard caught and sliced him. No crash.What else should I check? Summary: self-compiled The Dark Mod: Gentoo Linux, 64 bit system with 32 bit libraries availableGCC 5.4.0Boost 1.62.0Scons 2.5.0OpenAL 1.17.2FreeALUT 1.1.0The Dark Mode SVN trunk, commit #6731 plus custom patches documented in thread My experience with The Dark Mod under Linux
  19. Hello Nightstalker, since I am a newby here, I consider myself excused for behaving like one, and posting lengthy answers line by line. Here is one. Let me stress one point: my "work" was with a totally amateur approach, aimed to "make it work". I did "waste" some time, mostly due to my inability to find and/or understand the documentation (I went through compiling and installing DarkRadiant believing it was a newer version of The Dark Mod, I let you imagine my surprise when I started it... at least it explained the different style and level of the code). I am ashamed to admit, I actually quite enjoyed the process. Yes. I did not use yours because when I started that work, one week ago, I had no account on this forum and therefore I would be denied access to your attached files . You decided to make the extern inline static inline, I just made them inline. It's a subtle difference, and I am used to a different pattern completely where those functions are either defined only in their library and only declared in the header, or defined in the header as inline. Anyway, I suggest you not to waste your time with this patch of mine. Note that that patch alone will not be enough. I believe the lack of a forwarding header for string as there is iosfwd for iostream is a known "problem" (cf. http://www.gotw.ca/gotw/034.htm), but that would not help neither. My understanding of the problem is: the precompiled Boost libraries want the type of std::string that was where they were compiled (I grasped Ubuntu 10.10, maybe?), while the program uses the system ones. The code was declaring std::basic_string as in the distributed Boost, my patch as the system one; but the discrepancy is still there and will come out at link time. Boost and C++ STL are very tightly bound, and the best option is rely on the system one for both. It comes with a price, since Boost interface is not exactly stable. Distributing both Boost and STL would be madness though. Which brings us to your comment that... ... if I read your text right, it's not a different tack at all, it's exactly the same. I have used Boost 1.62.0, and it worked amazingly well. But my "shell patch" hard-codes the path of the libraries in my system, so it's no good. My best bet would be to tell the linker nothing about where they are, and expect them in the standard library directories which are always checked. The reason I added that was I saw a complaint "that file does not exist", and I though "why not to touch it in that case". But I admit I can't reproduce that message with the head version. The number of jobs patch is good to go and I endorse its merging. The other is good for me and you, but not for a distributed binary. If the librarian builds the executable for the processor that has become available tomorrow, and my PC is five years old, I won't be able to run it. Ok, pentium3 is maybe a bit too conservative... I stress one last time the "caveat emptor" message and the fact that they are not great stuff. But once a direction is chosen some of that stuff can be made well. I think especially to the decision about Boost.
  20. Yes, I did need that. Thank you so much! Care to explain, or point to explanation? I naively thought that the gem was an overlay bitmap, a piece of head up display. Surely nothing made of a "material". Now I am tempted to think it as a 3D object rendered using quite sophisticate ray tracing and refraction effects.
  21. I have compiled The Dark Mod on Gentoo Linux (I detailed my experience in another post). I have a problem: the light gem is always completely dark. Guards will react to noise and to touch, but I could stand in front of them making faces and they will politely ignore my presence. I have bisected the commits and tracked back the problem to commit #4379. Reverting that single commit fixes my problem. Not surprisingly, I do not understand that commit. I can try things though. I should assume this does not happen on Windows. Is this material for a bug report?
  22. I am reporting here my experience with compiling TheDarkMod from sources on Linux. I am going to attach some patches, but beware that especially the ones related to build may be specific to the system.I have used a Gentoo Linux distribution, with multilib enabled (that means that I have a lot of libraries compiled also in 32 bit version).Relevant packages:GNU compiler: 5.4.0Boost libraries: 1.62.0The Dark Mode: SVN trunk (2.06+, last commit: 6731, Dec 15, 2016). Finally, I am new to this program and I have gone mostly from scratch, likely ignoring a big deal of lore that may demonstrate some of this as obsolete, non-optimal or plain wrong and dangerous. I'll try to catch up with the threads developing on the subject. I downloaded the sources with: git svn clone --stdlayout https://svn.thedarkmod.com/publicsvn/darkmod_src thedarkmod git tag FromSVN # to keep track of my own changes (because I am the GIT type), and it took long. Nothing I am writing here depends on using GIT instead of SVN anyway. First, I should have applied immediately NightStalker's patch. I didn't, and I regret. It's from this forum, at http://forums.thedarkmod.com/topic/18544-time-saver-build-fix-for-sconslinux-compilation. Also, I did some tuning on the build scripts, that are good for general purpose but not for distribution (the distribution plays safe and assumes Pentium3). I enabled as many CPUs as available and the "native" instruction set (build_tuning.patch.txt). IDLib tries to forward-declare std::basic_string, which is a standard C++ class; unfortunately its declaration is an implementation detail, and the one in PUGIXML turns out to be incompatible with the one shipped by GCC: error: reference to ‘basic_string’ is ambiguous std::basic_string<char, std::char_traits<char>, std::allocator<char> > PUGIXML_FUNCTION as_utf8(const std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >& str); And the system string class from GCC 5 is different from the one that was used to build the Boost libraries that are shipped. Sadly, the only thing I could manage was to hard-code the system Boost libraries in the build paths. In my case they are at /usr/lib32, so the magic took the form of: grep -r -l -e 'lib/libboost' * | xargs sed -i -e 's@/usr/local/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g' -e 's@#.*linux/boost/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g'boost_link.sh.txt (note the "/usr/lib32/" path in two places). This, and changing PUGI header (pugi_strings.patch.txt) did the job. Now, there are linking problems with duplicate definitions. I really do not understand how that thing was supposed to work, but anyway I changed the definition of INLINE for GCC so that it avoids emitting multiple definitions for the same functions. Also I had to manually fix a couple of places for the same reason (inline.patch.txt). Next, a recent commit added a source file (idlib/geometry/RenderMatrix.cpp) but it did not add it to the source list for Linux build. There is also some piece that is Windows specific and that needs to be disabled (RenderMatrix_in_Linux.patch.txt). After this, running ./linuxBuild.sh produces gamesx86.so and thedarkmod.x86, which I copied manually into the directory where I had a downloaded installation (2.04), and that makes it a 2.06. The updater has still Boost link problems, so I use the shipped one. Just that. Now compilation works to me all the way from commit 6600 to 6731, with some exceptions here and there. The first commit works well enough that I could actually start playing Saint Lucia. The latter, though, is buggy in that my character is always considered in deep darkness: convenient for him, but not for my gameplay. More about this in another post, I guess. If you want to give these patches a try, you can run patch -p1 < patchname.patchin the main source directory (the attached patches should be renamed, with .txt removed; the shell script operates the substitution above).
  23. I applied the patch and compiled on an area which had already everything compiled. It correctly did not compile anything more. Excellent!
×
×
  • Create New...