Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

Cool. Glad it was nothing more serious. For the next release this kind of pain won't happen (promised) as I already have an idea for a simple upgrading system that's not too hard to implement.

 

@Orbweaver: could you edit this task into the todo-list in the programming forum? (Or am I able to do this myself, I don't know?)

 

I also got some news for the vector.h refactoring: I have added most of the operators to the Vector3 class (*, *=, +, +=, -, -=, /, /=, inner product) and already replaced all deprecated vector3_dot() function calls. I won't commit it yet, however, as I want to wait till DR 0.7.0 is released.

Link to post
Share on other sites

I have added the version stamping to the list of tasks. Something you might consider doing is applying a "version" property to each node, rather than the file as a whole, which would mean that custom colour schemes etc. could be given a higher version allowing them to be merged in rather than overwritten.

 

I am surprised that ascottk is getting an assertion failure on a release build, all assertions should be compiled out in release builds.

Link to post
Share on other sites

I just accidentally committed the .cdtproject and .project files (I meant to tick them off but obviously forgot this). How can I revert such a change on the server? The files are made for my Windows environment, so you don't want to update now, I guess.

 

Do I have to revert the change to revision 83 and re-commit the files?

Link to post
Share on other sites

I use a different binary parser and such. They won't fit for Linux environments, I'm afraid.

 

edit: Hm. Update to Revision works for my local copy, but it doesn't let me commit the reverted copies.

Link to post
Share on other sites

That's true, Windows needs the PE Binary parser or something.

 

I wouldn't worry about it, any time I check out afresh from SVN I have to set all the project settings anyway, no matter what gets committed in the .project and .cdtproject.

Link to post
Share on other sites

I'm glad you've started on this, those C functions were long overdue to be removed. I'm also fairly sure that the mystical "infinite loop with Windows inlining" bug was caused by some of these functions, which means we can be even more hopeful it won't manifest itself once this is done.

 

Just a couple of notes:

 

1. You don't need to specify members as inline if they are defined in the class declaration, since methods defined in this way are automatically considered inline. You may notice that this implicitly requires all templated methods to be declared inline, which is in my view a particularly ugly piece of language design (and one of several reasons why I personally dislike templates).

2. I don't think there is any point in defining operator* or operator/ in ways that are not mathematically defined, unless there is actually code which requires them. Is there any code which needs an elementwise multiplication or division of two vectors? I would be quite happy to have operator* overloaded as a dot product operation, however.

Link to post
Share on other sites
I'm glad you've started on this, those C functions were long overdue to be removed. I'm also fairly sure that the mystical "infinite loop with Windows inlining" bug was caused by some of these functions, which means we can be even more hopeful it won't manifest itself once this is done.

No problem, I could have been faster, but I took my time, because I didn't want to break anything. The Vector2 and Vector4 classes are to follow.

 

1. You don't need to specify members as inline if they are defined in the class declaration, since methods defined in this way are automatically considered inline. You may notice that this implicitly requires all templated methods to be declared inline, which is in my view a particularly ugly piece of language design (and one of several reasons why I personally dislike templates).

I don't understand this entirely. Do you mean that the inline keyword can be skipped here?

 

2. I don't think there is any point in defining operator* or operator/ in ways that are not mathematically defined, unless there is actually code which requires them. Is there any code which needs an elementwise multiplication or division of two vectors? I would be quite happy to have operator* overloaded as a dot product operation, however.

Unfortunately, there is code that requires the vectors to be multiplicated in this mathematically incorrect way. I would have gladly removed this, but I didn't want to stir too much dirt up here. :)

Link to post
Share on other sites
No problem, I could have been faster, but I took my time, because I didn't want to break anything. The Vector2 and Vector4 classes are to follow.

 

Excellent.

 

I don't understand this entirely. Do you mean that the inline keyword can be skipped here?

 

Yes. If you declare a class in a header file like this:

 

class MyClass {
public:
 void myMethod() {
 // do something here
 }
};

 

The myMethod() is implicitly declared inline because its body is present in the class declaration (rather than being defined separately in a .cpp file as MyClass::myMethod()).

 

Unfortunately, there is code that requires the vectors to be multiplicated in this mathematically incorrect way. I would have gladly removed this, but I didn't want to stir too much dirt up here. :)

 

Fair enough.

Link to post
Share on other sites
Yes. If you declare a class in a header file like this:

 

class MyClass {
public:
 void myMethod() {
 // do something here
 }
};

Do I get this right: as soon as I put the implementation of a member function into the class declaration it becomes an inline function, even without the keyword inline. Do templated functions need to be implemented in the header file or is it possible for them to be moved into the cpp file?

 

(I can imagine that these vector functions are "important" enough to have them inlined as they are used a lot and should be fast, so I probably wouldn't want to move them in a cpp file, but I just want to understand this right.)

 

I will remove the inline from the declaration keyword, then.

Link to post
Share on other sites
Do I get this right: as soon as I put the implementation of a member function into the class declaration it becomes an inline function, even without the keyword inline.

 

Correct. Although it is up to the compiler whether it actually inlines it or not (and you can override this behaviour with a GCC option), but the effect of putting the implementation in the class declaration is semantically identical to using the inline keyword.

 

Do templated functions need to be implemented in the header file or is it possible for them to be moved into the cpp file?

 

They have to be implemented in the header file, because the compiler needs to see the entire definition of the function in order to instantiate the template when it is used. Normally the compiler would only need to see the method's signature (the undefined method that you normally put in a header file) in order to generate a symbol which is linked by the linker, but it cannot do this for templates because depending on what template parameters you use, there may not be any matching instance of the template to link to.

Link to post
Share on other sites

Unfortunately yes. I saw a BasicVector3 at least once, which was causing a compiler problem with accessing the member variables of the -Vector in the methods. I got around this by accessing the components via other.x() instead of static_cast(other.m_elements[0]).

 

This happened with the += operator, so I guess there is a vector addition with a double vector out there somewhere. I couldn't be arsed to go into detail and investigate if the double was necessary, so I changed the implementation.

 

edit: it's radiant/winding.h and libs/math/plane.h that use such a type.

Link to post
Share on other sites

There is a good argument for using doubles internally anyway, for precision reasons. Perhaps a good future task would be to convert everything to use double, and then de-template the BasicVector3 class into a single Vector3 which holds doubles internally.

Link to post
Share on other sites
The myMethod() is implicitly declared inline because its body is present in the class declaration (rather than being defined separately in a .cpp file as MyClass::myMethod()).

 

Is this standard? I always thought that you have to use the inline option to actually make it so.

Gerhard

Link to post
Share on other sites
There is a good argument for using doubles internally anyway, for precision reasons. Perhaps a good future task would be to convert everything to use double, and then de-template the BasicVector3 class into a single Vector3 which holds doubles internally.

Shouldn't this work by just changing the Vector3 definition to BasicVector3?

Link to post
Share on other sites
Is this standard? I always thought that you have to use the inline option to actually make it so.

 

Yes, it's standard. If this wasn't the case, you would get a linker error when you included the header file into multiple .cpp files and tried to link them together, because there would be a duplicate definition of the function. If a function is "inline", this signifies to the linker that all definitions are identical and it can just pick one.

 

Shouldn't this work by just changing the Vector3 definition to BasicVector3<double>?

 

Yes, but if everything uses the same kind of Vector (or can be converted to do so) we might as well scrap the template.

Link to post
Share on other sites
Yes, but if everything uses the same kind of Vector (or can be converted to do so) we might as well scrap the template.

Ok, I'll look into it. Is there a difference between double and float in terms of speed?

Link to post
Share on other sites
Ok, I'll look into it. Is there a difference between double and float in terms of speed?

 

Possibly, but probably not in practice. The details depend on your implementation, but for the most part the floating point operations will not be the bottleneck, and the avoidance of precision-based problems down the line should make up for any (minor/small/negligible/non-existent) differences in performance.

Link to post
Share on other sites

Ok, thought so. I don't know if there are any precision-critical applications in DarkRadiant.

 

Another thing: I found that the Vector2 class is only used by patch.cpp a few files. Should I split the generic/vector.h into parts (generic/vector2.h, etc.)?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...