Reckless and Mh's TDM optimizations...

[nbohr1more]

I've been in communication with a couple of coders over at Inside3d forums.

 

"Reckless" appears to be a junior C++ coder with a lot of enthusiasm for experimenting while "Mh" is a well known Quake engine coder. I wont go crazy and get any hopes up but Reckless claims to be working to merge Mh's and his own latest engine optimizations into the TDM sources.

 

I will post the results here should they be viable.

 

That said, Reckless felt that he should share the following code regarding the DLL loader:

 

 

/*
==============
Sys_Mkdir
==============
*/
void Sys_Mkdir(const char *path)
{
  int      ret;
  char   *dup, *c;

  ret = _mkdir(path);

  // if it allready exists no need to recreate it.
  if (!ret || (errno == EEXIST))
  {
     return;
  }
  dup = _strdup(path);

  c = dup;

  // unix path magic
  if (*c == '/')
  {
     c++;
  }

  while (*c)
  {
     if (*c == '/')
     {
        *c = '\0';

        ret = _mkdir(dup);

        if (ret && (errno != EEXIST))
        {
           Sys_Error("ERROR: Can not make path %s %s (%s)\n", dup, path, strerror(errno));
        }
        *c = '/';
     }
     c++;
  }
  ret = _mkdir(dup);

  if (ret && (errno != EEXIST))
  {
     Sys_Error("ERROR: Can not make path %s (%s)\n", dup, strerror(errno));
  }
}

 

I noticed you used boost for some unix path magic in the DLL loader so heres a mkdir that also handles that

 

I'll keep this thread cooking as long as the replies are forthcoming...

[Tels]

Does this mean this code from his replaced a bit of boost code? That would be cool, one step towards getting rid of boost.

[nbohr1more]

Yes, his reply is a little unclear but it seems that's what he's saying. He is stream-lining the process by writing it natively rather

than relying on boost.

[Tels]

Sounds good to me. But apparantly my opinion regarding these things doesn't count for much these days, so I don't know how to proceed from here.

[New Horizon]

Rather than bemoan your perception of a lack of status, perhaps you could ask greebo why he feels it is neither necessary nor wise to strip boost. You have to be willing to listn if you also wish to be listened to.

[Bikerdude]

@Tels, you already know why. So can we move on already...

[nbohr1more]

Well, I hate to bring any contentious topics to the fore but I am genuinely curious about the merits

and pitfalls on either side. From what I gather, Boost has a lot of pre-made thread safe MP code

that would be tough to write from scratch. OTOH, I do recall a discussion at work about code bloat in modern

apps and that the general consensus was that reliance on lots of large libraries for small code segments

was one of the prime culprits. Though I guess that's not what is really driving the contention here...

[i30817]

Removing 'bloat' will not make your code faster.

[STiFU]

Using basic functions is always better than relying on libraries, that might become outdated or obsolete eventually. However, the problem here was that boost was responsible for compiling issues under linux a couple of times. That's all. But to my understanding, getting rid of boost is not a quick and easy thing to do.

 

By the way, I had been meaning to ask whether Sikkpin is working on the D3 code as well. I would love to see some engine improvements from his side.

[Tels]

Using basic functions is always better than relying on libraries, that might become outdated or obsolete eventually. However, the problem here was that boost was responsible for compiling issues under linux a couple of times. That's all.

 

It is much more than "compiling problems". The boost library is tied to the compiler version and libraries you use.

 

So if you:

 

* compile TDM on a long-term support (5 years!) Kubuntu/Ubuntu version, it will run there, but not on anything 2 years newer

* if you compile TDM on the newest Ubuntu/Kubuntu, it will run there, but (very likely) not on the version released next year, and definitely it won't run on the long-term support version from 3 years ago, or maybe even not on the Ubuntu from last year (we already had exactly that problem with v1.08)

* if you compile it on a version from last year, there is a good chance it will run on the long-term, the current and hopefully not break next year (what we did with v1.08)

 

The basic problem is that it is a moving target, you always have to recompile, to choose the system for recompiling, and it will still break next year, anyway. And by break I mean "not even start".

 

This is just Ubuntu, other linux archs like Arch, Gentoo etc all complicated this even further, because they might use older and/or newer boost libraries on the system.

 

Yeah, removing boost might not be easy, but since original D3 lives entirely w/o it, I don't see why we can't. But don't blame me for adding it, because I'd never started using it inthe first place. It's not that I want to re-invent everyting, but using such a huge library (the include/boost library of TDM is roughly 220 Mbyte with the .svn overhead) which needs constant maintaince is just not worth it. You safe some time not implementing some features, and spent a lot more time baby-sitting the failures afterwards... Just my 0.02€, of course.

 

(That we do have some bugs that are caused by boost code and that we can't really fix is another matter. They are not that important compared to "TDM will not run", tho).