Jump to content
The Dark Mod Forums

Hamlet

Member
  • Content Count

    24
  • Joined

  • Last visited

  • Days Won

    4

Hamlet last won the day on January 2 2017

Hamlet had the most liked content!

Community Reputation

15 Neutral

About Hamlet

  • Rank
    Member
  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 differen
  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
  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 o
  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_C
  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
  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
  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 ‘
×
×
  • Create New...