Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

I just tried to upgrade MinGW to 3.4.5 but there seems to be no gcc with the same version (just a 3.4.2 and it produces a load of errors).

 

I will google after this some more. Perhaps MinGW supports _isnan instead of isnan.

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

The lockup problem is now fixed -- it was the inline call that did it. Separating out the calls so that sqrt() is called with constant/variables only did the trick.

 

I wouldn't worry about isNaN to be honest, since the current implementation will work on any platform it is probably better to use it than have separate functions for each environment.

Link to post
Share on other sites

I went for a challenge and moved the clipper code into a module. In the same sweep I made some changes to the preference system so that modules can more easily add preference settings.

 

Could you check if everything is compiling fine on your end, Orbweaver?

Link to post
Share on other sites

A new module, fantastic. It seems to work OK this end (although you inadvertently checked in your .project/.cdtproject which confused my Eclipse a bit due to the merge conflict markers). EDIT: these files are now removed from SVN and added to svn:ignore so they should not appear on your commit list. You are advised to back them up before updating in case they get deleted by SVN.

 

Did you design the module interface from scratch or was it already a module in the main Radiant binary and you just split it out to a separate DLL?

Link to post
Share on other sites

I noticed about the .cdtproject files, and I know and swear that I removed them from the list of files to be committed, this has to be some TortoiseSVN weirdness. Anyways, now that the files are ignored, this should not happen again, sorry for that.

 

I recently moved nearly all of the clipper-related functions into a ClipperManager class, afterwards it was easy to extract the methods that need to be defined in the interface, so it was more or less from scratch.

 

However, there is one part of the clipper code (namely that doing the actual clipping using scene::walkers), that is not yet in the module because the brush/face interface classes aren't written so far. There are some BrushNode creations and face operations that I could not define them without changing many parts of the existing brush system (although admittedly, I tried to do this, ended up with changing almost every file in the brush/ folder but in the end I failed and reverted the changes).

 

Ah, and one more thing: I didn't have a lucky hand naming the interface, global module and module implementation classes, so feel free to suggest some naming convention. At the moment the clipper interface is called "Clipper", the inlined accessor function "GlobalClipper()", and the actual implementation in the module is called "BrushClipper". Do we have some guidelines about this?

Link to post
Share on other sites

I'm currently hunting after another crash that occurs after closing any XYview and going into freelook mode in the camview (latest SVN). The crash happens as soon as the freelook mode is enabled so there may be some handler still attached. I don't know exactly where it happens, so this may take a while.

 

Edit: I think I have an idea where this could be happening.

 

Edit²: fixed.

Link to post
Share on other sites

There were some problems with the grid not reacting to the hotkeys, so I rewrote the grid code into a separate module. Please check, if everything is compiling, or if I forgot something.

Link to post
Share on other sites

Compiles and runs fine, I also tested the grid size changing and that is also still working.

 

That looks like a good module, with a nice clean interface and obvious purpose. I am confused though, what is GridItem for? It looks like a class that just holds an enum and a pointer back the module, which is a bit strange. Wouldn't it be simpler to just store the GridSize enum in the map directly?

Link to post
Share on other sites

It also hold the callbacks to connect them with the EventManager. At the moment, only function calls with no arguments can be connected, therefore I decided to create a set of GridItem instances that provide such a callback.

 

Do you suggest to implement something different?

Link to post
Share on other sites

OK, I think I understand now. Because the event manager cannot call a function with arguments but can call a member function of an object, you have to create a series of objects and call the member function on the relevant one?

 

I like the RegistryKeyObserver interface you have written, it is good to have classes able to register an interest in monitoring a particular key. What happens if a class wants to monitor more than one key -- can this be done (I am only wondering, I don't actually need to do this at the moment)?

Link to post
Share on other sites

Glad you like it. :) It's perfectly safe to observe several keys, the XMLRegistry maintains a multimap like this containing all the RegistryKeyObservers:

 

typedef std::multimap<const std::string, RegistryKeyObserver*> KeyObserverMap;

 

Currently there are approximately 30-40 KeyObservers registered at runtime, some even observing the same keys.

Link to post
Share on other sites

I have ironed the small issues I mentioned in the other thread concerning the keypress events not being passed to the EventManager when the top-level dialogs are in focus (Entity Window, Surface Dialog, etc.).

 

These dialogs can now be connected via connectDialogWindow() and get a chance to process "their" keypress events before the global shortcuts are fired by them.

Link to post
Share on other sites

I hate to say it, but I noticed a crash (in the latest SVN). If one destroys an xyview and types a few times on Ctrl, Alt or Shift (haven't tested with other keys, but this is bad enough), DarkRadiant bails out.

 

As the number of times I have to press the keys till the crash is actually happening is not the same each time, I suspect this is GDK-related, and I hopefully will find the source.

 

edit: I could find the source, fix is in progress and is committed soon. Looks like the GtkRadiant WindowObservers weren't designed to be actually deleted during runtime.

 

edit2: fixed.

Link to post
Share on other sites

I have just compiled the Windows build for 0.8.0, and have noticed a serious problem with geometry displaying in maps. Here is an example (askave.map) -- the same thing happens with mansion_alpha.map.

 

drbadhf5.th.png

 

This looks like what I would expect to see if world geometry and entities were filtered out, but no filters are active. Is this a problem you have ever seen before?

Link to post
Share on other sites

I have this problem, especially in large maps. Sometimes everything is gone completely, sometimes things appear if I zoom out and disappear if I zoom in again (this also depends on the area I'm looking on, this is more likely to happen if there is more on the screen) and sometimes only the cam view is screwed (depending on the viewing angle, everything disappears/reappears). I usually reload the map a few times until everything works fine again.

I don't know what could be causing this, but I thought it could be a graphics card/driver issue.

Link to post
Share on other sites

Oh great, another stupid Windows-only bug. I will have to fight against the slowness of Windows in order to find out where this is happening, since it doesn't appear on Linux.

 

First guess - something to do with volume culling and bounding box calculations. I wonder if one of those Windows-specific floating-point errors is in there somewhere.

Link to post
Share on other sites

I've done quite some changes to the EventManager plugin and the MRU handling. Do you want me to wait with committing this to SVN until the display bug is resolved or can I go ahead and send the files?

Link to post
Share on other sites

Next bug: I was working on my bonehoard entrance model, which I export from Blender into ASE using Goofos exporter script. After splitting the model into separate objects (still within the same ASE), some parts started disappearing in DarkRadiant, and finally the model doesn't appear at all.

 

I suspect that the number of subobjects is the cause here, is there a limit concerning the maximum number of objects or textures within a single model?

Link to post
Share on other sites

Thanks. I can confirm that the model shows up with 0 vertices and does not display anything in the preview window. Unfortunately this means I will have to dig into the picomodel library, which is horrible C code (actually it's not bad as C code goes, but it's still C).

Link to post
Share on other sites

I wanted to drop a note here, that I've been doing some mapping/modelling recently in order to help angua release her next Bonehoard preview. Hence the little progress on my DarkRadiant coding, just in case you're wondering. :)

 

We both have two exams on January 29th, so it may well be that my output curve will stay low for a bit, but I'll try to do what I can.

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