Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...