Jump to content
The Dark Mod Forums

namespace

Member
  • Posts

    44
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

390 profile views
  1. I'm experiencing the same problem as described above. My system is a a 64bit Arch Linux. Here are some stats: Linux xen 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 glibc: 2.12.2-1 This might help (the devs): https://bbs.archlinux.org/viewtopic.php?id=50230
  2. Strange, we used VC2k5 in the past development phase and for the release build. Did you download the gtkr-dependency package?
  3. Gtk comes with already setup VC2k5 projectfiles, what are the problems?
  4. So gcc is implementing dynamic_cast<> in an unreliable way? I can't believe it. Well I think they made it as reliable as possible, I have no idea how a compiler should store the required metainformation that type X inherits from type Y that is implemented elsewhere.
  5. This seems to be one of the issues why C++-rtti was avoided in the first place. I never experienced these problems my self, this is a surprise for me too. I did some googleing and found, aside from many many bug reports, some example code for gcc 3.3 that exposes a dynamic_cast bug: class cFoo { ... }; class cBar : public cFoo { ... }; cFoo* pfoo = CreateBarInDLLAndCastToFoo(); cBar* pbar = dynamic_cast<cBar*>(pfoo); // pbar is zero Since we work alot with shared libraries, a similar scenario would be possible... In my opinion, a cast mechanism that "might" work is unacceptable, we should try to implement our own cast-mechanism.
  6. Thanks, it compiles now. Starts up nicely, but crashes when I try to create a bursh. I'll wait until the transition from the ugly cast-system is complete.
  7. A compiling darkrd on Ubuntu would be cool and would it make possible for me to do some little changes (vbos etc) myself. So far I always got a scons related error: scons: Building targets ... scons: *** Directory /home/cc/Projects/darkradiant/trunk/darkradiant/libs/string found where file expected. scons: building terminated because of errors. I searched the forums and the suggested way to fix this is to install an older version of scons. However, this is no option for me since two of my projects rely on the recent (96.92) scons-version.
  8. A failed dynamic_cast on a references throws a std::bad_cast exception, dynamic_cast on a pointer returns 0. I think it was done this way to evade exceptionhandling.
  9. The cube-grid is just a additional structure and can't be a replacement for the real scene-graph, so it can be added later. The uniform-grid makes some things really clean and fast. Example, we spawn an entity and have to upgrade the cube-grid: Assumption: We have small list for each entity which stores in which cubes this entity is in. Put the entity in cube[x / 256 + 256][y / 256 + 256][z / 256 + 256] See if the entity interects the neighboring cubes, if so, add the entity to these cubes as well. This information has to be updated when the entity: - moves - resizes - gets deleted (The cool thing this is that these conditions only relate to this entity, there are no "outer"-circumstances which would make a regeneration of this information neccessary) Assuming that most entities are way smaller then 256³, the reasonable worst case would be an entity intersecting 3 cubefaces, generating 3 "cube-links" instead of just one.
  10. Divide your radiant-space (2^16 x 2^16 x 2^16) into cubes of uniform size (256 x 256 x 256) and sort your brushes and entities into these cubes. If a bounds-selection has to be performend, check which cubes would be affected by the selection-volume and then check the objects inside these cubes (-> all other entities and brushes get ruled out in a few operations). An octree works similiar, but is abit more complicated. An octree recursevly subdivides the cubes into smaller cubes until a specific object-count for each cube is reached. We won't need that. If there should be too many objects per cube (how many entities can you stuff into 256x256 ?) then we could just switch to a uniform 128x128x128 cube-grid. BSP-Trees and kD-Trees are of no use here (imho) since we work on dynamic data.
  11. Yeah, but I question that the amount of callbacks is the slowdown. As far as I remember, radiant doesn't have any intelligent datastructure that organizes the scene in a way that would make it possible to easily reduce the amount of objects that need to be checked for a selection. *votes for uniform cell partitioning*
  12. Fantastic news! Another weird radiant interface bites the dust
  13. Yes, this special type of casting was introduced in the beginning of 1.5 because the early C++ compilers had crappy rtti support, some still have. I don't know on which pattern, if any, this system is based. In my opinion, the real problem is the wrong usage of this mechanism, many classes have installed casts which just return a reference to a membervariable. This messes with the semantics of inheritance and delegation, a delegation should be treated as such and not be hidden as pseudo-inheritance. So far performance was never been kept in mind when writing 1.5, it was more playing catchup with featuresets and bugfixing most of the time. Sad, but true. If you feel the urge to implement a new rtti-system, I could post some source of my engine which has its own rtti-sys as "inspiration"-source. It works with dispatching based on virtual and static functions and does not requiere any variables per instance, just one integer per-class.
  14. Yes. Concerning the other people who were involved in 1.5: Spog: Haven't seen him for half a year in the channel, I guess he does different things now. Shaderman: I chat with him everyday, atm he extends my brushplug to support materials. In general he as no intentions to continue development, he just does it for fun. LordHavoc: He helped alot GPLing 1.4 but he hates the 1.5 code so I don't think that he would pick it up. Yes, he does most of the linux ports for id games, gamepatches and other stuff. He worked on GtkR 1.4 as open source coder and got hired by ID. (at least thats what I could figure out, can be wrong)
  15. Yes. It doesn't make any sense to continue development as a "one man army" fighting against a chaotic codebase. I think helping you guys and working on my project would be a far better use of my sparetime then reimplementing "select tall" in 1.5 because some zealots can't live without it. Edit: Have a look at qeradiant.com. You'll notice, apart from the release message, that their isn't any other content on this page and I guess there will never be. TTimo can't find his backup and of course he didn't check for it before he deleted the old page. In case of the backup beeing found some day then it would have been my job to port the data into the new wiki system. At least thats the way TTimo planned it... without asking me. I don't want to sound bitchy but this guy was more of a constant annoyance then a help during development.
×
×
  • Create New...