Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

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

 

All mathematical operations are precision-critical; you don't want your nice rotation matrix suddenly collapsing into something else because all of the incremental precision losses during successive modifications have become significant. I wouldn't be surprised if many of the "infinitely thin" or "infinitely stretched" problems are caused by the collapsing of a single-precision result to 0 (but they may also be because of stupid GTKRadiant code design).

 

When studying Java, the guideline was that float should ONLY be used in things which really don't need any precision and do not take part in iterative calculations, such as specifying the intensity of a pixel from 0.0f to 1.0f.

 

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

 

Better make it Vector2.h, consistent with out naming conventions for classes.

Link to post
Share on other sites
  • 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

All mathematical operations are precision-critical; you don't want your nice rotation matrix suddenly collapsing into something else because all of the incremental precision losses during successive modifications have become significant. I wouldn't be surprised if many of the "infinitely thin" or "infinitely stretched" problems are caused by the collapsing of a single-precision result to 0 (but they may also be because of stupid GTKRadiant code design).

 

When studying Java, the guideline was that float should ONLY be used in things which really don't need any precision and do not take part in iterative calculations, such as specifying the intensity of a pixel from 0.0f to 1.0f.

Ok, after this clean-up I will try to change the Vector3 definition and see what the compiler has to say about this... :)

Better make it Vector2.h, consistent with out naming conventions for classes.

This was my plan. :) Is generic/ the right folder for this in the first place? Shouldn't this go to math/?

Link to post
Share on other sites
Ok, after this clean-up I will try to change the Vector3 definition and see what the compiler has to say about this... :)

 

Be careful with OpenGL, many of its functions do expect floats (any function name ending in f), which can be converted implicitly from doubles but it will be important to keep an eye out for problems.

 

This was my plan. :) Is generic/ the right folder for this in the first place? Shouldn't this go to math/?

 

I agree that math/ is better for this.

Link to post
Share on other sites

EDITED

 

C++ was complaining:

In file included from bleh, bleh, libs/math/matrix.h: In member function `Vector4 Matrix4::transform(const Vector4&) const':
libs/math/matrix.h:288: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
libs/math/Vector4.h:83: note: candidate 1: Element BasicVector4<Element>::operator[](size_t) const [with Element = float]
libs/math/matrix.h:288: note: candidate 2: operator[](const float*, int) <built-in>

 

I already found the problem, there was another operator defined in Vector4 that I've missed.

Link to post
Share on other sites

Yeah, that can happen when you provide both an operator float* and an operator[] on the same object, since float* has a built in operator[] for array access.

 

I think with Vector3 I just went with the operator* and skipped the operator[] entirely (since it did the same thing).

Link to post
Share on other sites

Yes, this is exactly what solved the problem.

 

I've almost replaced all of the BasicVector4 methods and I'm currently splitting the Vector definitions into separate files. This week was very busy, but I should be able to commit this soon.

Link to post
Share on other sites

I've just committed the following changes:

 

- generic/vector.h and math/vector.h are gone

- separated BasicVector classes into files: math/Vector2.h, math/Vector3.h, math/Vector4.h

- removed all deprecated Vector2, Vector3, Vector4 functions

 

Tomorrow I will look into the selection.cpp file again and see if I can do something about the draggable light center.

Link to post
Share on other sites

I can take a look at that if you'd like - my exams are over so I can finally start contributing again. :)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites

On the other hand, if you have some insight into this thing already, feel free... man, this code is fugly. <_<

 

Seems like the thing to do might be to make a LightCenter class that inherits from Selectable, Renderable, and whatever else it needs, then reference it from the light object (I forget its name). Find an appropriate place to make it render, and figure out how to make the existing selection code work with it. Once that's done, it needs to be draggable, and it needs to affect the light_center property on its parent entity when it moves.

 

There's a whole bunch of stuff related to "instancing"; not sure if that's something it will need to handle. (As far as I can tell, it was implemented just to make the code more complicated. :rolleyes: )

 

 

Edit: Doh - I forgot, there already is a light center class (for the rendering). It's been a while... let's see if we can adapt this to be selectable as well.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites

I don't understand instancing at all, from the small amount of information I gleaned from IRC chat logs on #qeradiant, it seems that you can have a node with more than one parent, and each "path" down from the top counts as a separate instance.

 

However I cannot imagine a possible situation where a node would have more than one parent, since the tree is only three levels deep (root, entities, brushes), and a brush cannot be a part of more than one entity.

Link to post
Share on other sites
On the other hand, if you have some insight into this thing already, feel free... man, this code is fugly. <_>

 

There's a whole bunch of stuff related to "instancing"; not sure if that's something it will need to handle. (As far as I can tell, it was implemented just to make the code more complicated. :rolleyes: )

Edit: Doh - I forgot, there already is a light center class (for the rendering). It's been a while... let's see if we can adapt this to be selectable as well.

Well, I don't really have that much insight yet, I still didn't understand where exactly the things do happen in the code, it's so nebulous. My approach was to cut these huge files into small pieces and try to understand what the heck they do (I started with selection.cpp, but I'm not finished yet).

 

In other words, if you'd like to do it... :rolleyes: I still can't say if it is too much for me or not. You've got much more experience than me, so I guess the problem would be solved much faster if you would do it.

 

However, I will continue to disentangle the files, just drop me a note, if you need exclusive access to selection.cpp so that we can avoid any conflicts.

Link to post
Share on other sites
In other words, if you'd like to do it... :rolleyes: I still can't say if it is too much for me or not. You've got much more experience than me, so I guess the problem would be solved much faster if you would do it.

 

With most coding tasks you will probably find that implementing it is easy, but finding out what you need to implement is the harder part.

 

If the task as a whole is too large to tackle easily, then I suggest breaking it into smaller tasks - such as "understand and document the Selection System" or similar. If we can document subsystems on the Wiki then this will make future changes a lot easier (I need to do this with all of my changes in fact).

Link to post
Share on other sites
Cool! How did it go?

Not too bad, thanks for asking. I think I passed maths. :)

 

greebo: Not to worry, I'll work around your changes.

 

Note to self: Fire up D3Ed and see how what I'm supposed to be implementing is actually supposed to function. :P (e.g. is the light centre actually selectable as such, or does one just select the light itself and can then drag on the light centre to move it?)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites

I found some time today to look again into moving the XMLRegistry into a module. So far I was able to avoid any nasty crashes (which is an achievement for me, believe me :P), but there still remains the problem that the registry should already be loaded when the stack of Radiant Dependencies is instantiated.

 

It seems to me that there is no way to reliably place the registry's importFromFile() calls between those instantiations, so I believe the only solution would be to pass the actual AppPath to the registry constructor, so that the registry can handle the load on its own during its instantiation.

 

I see two problems:

 

- The registry would have to figure out of its own where the actual doom3.game file is located, unless we could place this information within the user.xml. And I'm afraid that the abiltiy for multiple game files would somehow be lost. Don't know if we need this in the first place.

 

- The AppPath_get() function is out of reach for the XMLRegistry, so I would have to implement its own function to determine the "root" directory of Radiant. (The question here would be: is there a standard, platform-independent method of doing this, apart from the one Radiant has built in?).

 

Or is there another possibility to pass the AppPath string (or any structure) to the GlobalModuleRef instantiation?

Link to post
Share on other sites

You don't have to use the dependencies, that is an just easy way of allowing modules to provide a list of what they require to be instantiated before them.

 

You could do something like this in Radiant_Initialise()

 

// Initialise module server
GlobalModuleServer_Initialise();

// Load the modules from disk
Radiant_loadModulesFromRoot(AppPath_get());

// Instantiate the registry module before anything else
GlobalRegistryModuleRef ref;

// Load default values for darkradiant, located in the game directory
GlobalRegistry().importFromFile(std::string(AppPath_get()) + "user.xml");

// blah

// All other modules get instantiated in Radiant_Construct
Radiant_Construct(GlobalModuleServer_get());

Link to post
Share on other sites

I finally managed to implement this, I had to add the command

 

GlobalModuleServer::instance().set(GlobalModuleServer_get());

right before instantiating the GlobalRegistryModuleRef. It took me quite a while to figure this out, but now everything is working.

 

I will now do a full checkout and add my changes to the clean version. My working copy is cluttered with debug output :)

Link to post
Share on other sites

Just wanted to drop a note here, that I changed the name of _QER_FuncTable_1 to RadiantCoreFunctions and added some documentation to qerplugin.h. If there should be a problem with renaming the struct, I will revert it of course, just tell me.

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