greebo
-
Posts
16733 -
Joined
-
Days Won
51
Posts posted by greebo
-
-
Hm, would it be too radical to kick the support for multiple game files? Would there be disadvantages for us?
(It seems that the .game files are needed before the modules to load the game-specific shortcuts.ini and local.pref from e.g. ~/.darkradiant/doom3.game folder.)
EDIT: woah, I tried to move the game file loading process after the DLL ModuleLoad and I get even more crashes now. But it's possible that there is something screwed with my .dll, as soon as I try to call a test method (e.g. Globalregistry().dump(), which does exactly nothing, I commented everything out) the program bails out. I checked if the module is loaded correctly (it is).
EDIT^2: Ok, I probably missed something: I just tried to implement a module named "testmodule" to test if I'm capable of installing any module (it has just one method called echo() that writes to std::cout) and it compiles, loads but still crashes on the echo() call. Any directions or common mistakes I could check?
-
I've turned the XMLRegistry into a module now, but I found this problem:
In main.cpp there is the g_GamesDialog.Init(); call that loads the appropriate game file. The problem is that this function already expects the XMLRegistry to be setup correctly, but it isn't as all the modules are initialised in Radiant_Initialise() in mainframe.cpp which is quite a few lines below the former call.
What is the plan? I don't know how deadly it is to change the order of these calls as the shader module for example expects the game file to be already located.
Should I try to implement some kind of load() method to the game file dialog, so that the actual loading is done when the modules are initialised?
-
Yes, this is another thing I want to understand, I will take a look at this! If it's easily accomplished, I will convert the XMLRegistry soon, let's see...
-
When I'm trying to stretch the texture across a brush then accidentally get to 0.00000, DR freezes.
This happens when using Vertical or Horizontal stretch using the Surface Inspector.
I had this problem once, it was with my first DarkRadiant compile (July, I guess around version 0.5.0). The stretch value accidentally hit zero and the program immediately crashed.
Can you give more detailed instructions (I guess you're using the 0.7.0 release?) and perhaps a map or something?
-
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.
)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...
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.
-
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.
-
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.
-
If you want to get a feeling what working for TDM is about, you should take a look at the game Doom 3 itself and try to do some Level Editing, Modeling, Texturing or whatever you're talented in, this really depends.
There are a lot of Tutorials on www.doom3world.org, its Forums and also on DarkWiki.
Generally speaking, it's never too late to do the first step, as I myself started modding in July this year. It's just a matter of interest and dedication, so I can really encourage everyone who is interested to try.
-
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.
-
If you're looking for a free forum software, you might want to take a look at phpBB: http://www.phpbb.com
This is most probably the best forum you can get without paying license fees. If you don't need it right now, I would suggest waiting for the new version 3.0, which is a huge step forward in comparison to the current phpBB 2.2.
edit: Redface was faster, it seems
-
I really doubt that my processor or the size of my RAM does matter in this case, but it's a Athlon XP 2500+ with 512 Megs of RAM. The process that is responsible for this behaviour takes (according to ps aux) 40% and around 50% of RAM. However, the hard drive is constantly accessed, I believe to recognise some kind of pattern in the accesses (though I could also be imagining this).
I'm somehow disappointed that the Linux multitasking performance is so weak on my system, and in comparison to my Windows XP partition it's lame (although the hard drive where Windows XP is installed, is an 80GB drive, to be fair).
I will try to re-install Linux (6.06 to be precise
) at some time, but somehow I'm not really motivated to mess around with such kind of things, I really have better things to do with my freetime. Perhaps I will look into this after I've finished my diploma. -
Now that really sucks: I just tried to compile DarkRadiant on my Ubuntu 6.10 and everytime it hits brushmanip.cpp it eats up my system (mouse pointer moves every now and then, system clock stops, can't even open a console window to kill the process). The only way to stop the compiler is to have a console opened before I start compiling and be on my toes to find out the process number before the system stops responding at all. Hmpf, didn't have something like that with Ubuntu 6.06 but I can't be sure if it's the Ubuntu upgrade alone.
Does anybody know whether the compiler version has been changed within edgy eft?
-
Happy Birthday!
-
Not having direct access to doom 3 in Dark Radiant is a bit of a hassle, so I was wondering if we could work around this by somehow assigning the Doom 3 default F2 key, to basically pass this command to the doom 3 executable?
(In Windows) I have setup my Doom 3 icon with a keyboard shortcut like Ctrl-Alt-D, which is also possible in Linux (haven't checked, but I'm positive). I also have shortcuts for my texteditor (Ctrl-Alt-E) and DarkRadiant (Ctrl-Alt-R), this way I only need one hand to fire up these apps.
It would be good if there was some way to pass commands to a running D3 executable, because then we could put a Build option in which would just call "dmap" in the Doom 3 game. There is an autoexec.cfg in the Doom 3 folder and I tested it once if it's possible to drop a testmap bonehoard in there. I think it worked, although I can't remember right now.
Perhaps this is the place to start looking for such a feature. -
Ok, all of the deprecated vector2_bleh functions are gone. I'm afraid this is enough for today, I will try to achieve more of this the next days.
-
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/? -
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.)?
-
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?
-
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
? -
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.
-
Ok, thanks for explaining, highly appreciated!
I'm off to working on BasicVector2 now...
-
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.
-
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.
-
Ok, then.
I've changed a lot files btw, most of the deprecated vector3_yyyy functions are history now.
edit: Ah, found it, the changes are reverted now.
A Better Filter System
in DarkRadiant Feedback and Development
Posted
Gah, I will let this rest until I have some better ideas how to solve this. I just copied over your filters.cpp file and changed the absolute minimum and it still crashes the second I call the echo() method. The point where I call the echo() method is located at the bottom of Radiant_Initialise() in mainframe.cpp where everything should be loaded.