Itches, Glitches & Anything Else...

[greebo]

Ok, reuploaded the file, it must have aborted yesterday.

[Fidcal]

Still not got the new feature. This snapshot I just downloaded says 0.9.2 June 212007 17:11:46. Is that the right one?

[greebo]

This seems too old. I uploaded a new snapshot ZIP today so it should state June 24th. I'll check the archive on the server if something weird happened.

[greebo]

The archive linked to by the snapshot page is ok. The about dialog still shows an old date, because this part of the application hadn't been recompiled (the scons tool is only compiling the changed files), so don't worry about that date. It is the most current version.

[Fidcal]

Yet the texture browser text still overruns...

[greebo]

You can change the max string length where the texture browser starts to ellipsize the shader names in the preference settings ("P" > Settings > Texture Browser).

 

However, this won't work for all shaders, as some textures are really narrow and provide horizontal space for two characters only.

[Fidcal]

OK, got it now. Firstly I didn't look closely but just saw the text overrun. Then when I looked again I could see the ellipsizing was taking place but some still overran. So I've tried different thumbnail sizes and different text ellipsizing and got it pretty good. I don't see how you can do any more. I set the thumbnails big - 360 so I just get one on a row (for the dialog width I want), even if there are two narrow ones (well, I don't know what the minimum is but probably) and set the text to max 100. I now see all the text and it works fine. And you can right click back to the texture in the media browser. I'm happy with that.

 

Thanks also for the reduced minimum camera movement. I can now fine tune and creep up on that moon. I now see why it was even more difficult last time than the first time I did it. The moon box and that other box are not rendered except for that one face. So it's not even a tiny box but a tiny face close up to and facing another face! Maybe I inadvertently changed the textures to nodraw or something.

[SneaksieDave]

Ah crap. I crash on startup with the new snapshot. I even tried the 'rename your config and restore defaults' option at the beginning and it still crashes. Log doesn't seem to indicate any issue, but note that I am running my work machine right now. Have there been any changes to rendering needs in this snapshot (the one from a few days ago worked fine)? This system has some onboard intel piece of shit video card.

[greebo]

Please delete the clipper.dll from the modules/ subfolder, it's crashing the app. The new snapshots don't need this DLL anymore, but it still gets loaded >> crash.

[SneaksieDave]

Woot, that's got it, thanks. Nice fixes too.

[Komag]

Fidcal, I've always seen a little cube for the moon, no problem. It was easy to find and select once I hid all the stuff around it, even with the 50 movement. Maybe you have some other setting on, or you were doing it with F3 lighting on?

[Fidcal]

When I did it the first time it was a cube - but still very difficult to view the moon surface because there is only a tiny place from which you can see the inner surface and one touch on the mouse or keys and I'd overshoot by 50 units. But I did it eventually.

 

The next time was after the texture realignment and there is no visible cube there now but only the one surface for that moon cube. It's possible at some point I have accidentally retextured it nodraw but certainly not intentionally. So long as it works I'm not bothered at this point but I might want to move the moon later to get good lighting. I assume I just move that cube.

[Komag]

In the 3D view I just selected the cloud deck, hit H, select the light, hit H, etc, until only the moon cube was left in the whole room. Then you can select the moon face from far away. I can even do it with the camera on 290 (I wish it could go even faster sometimes!)

[Fidcal]

I didn't know about 'H' - presumably that filters out that one brush/entity? I'll have a look tomorrow if I remember.

[Komag]

It's in the "View" menu, Hide/Show - Hide Selected and Show Hidden. I use them all the time. If I go to select something from the top view and forget about my ceiling brush (which I've just accidentally selected), instead of moving the view around or whatever I just quicky hit H, then try again to select what I originally wanted. After I'm done I just hit Shift-H to restore anything I've hidden.

[Fidcal]

So much packed into DR I doubt I'll ever learn it all. I'll certainly try to remember this one. I could have used it yesterday when I wanted to see the far slope of my wall better from beyond the sky box

[OrbWeaver]

"Slugs" removed from the map loading code:

 

1. The activeShadersChangeNotify was being called for every new shader during map load, which in turn results in a whole load of calculation and positioning operations for the textures window. A new option in the ShaderSystem disables the change notification during the loading of a new map.

2. There is a stupid, stupid, stupid class called UnsortedSet which provides a set-like interface but is implemented as a linear list with O(n) searches. I have removed the call to find() which was buried inside an assert statement called every time a new node was added to the set, but the class remains for now.

 

Unfortunately even after removing these monstrosities, loading the Bonehoard does not seem noticeably faster. It appears that every time you remove one slug, you find another one right behind it.

[greebo]

Be careful with that UnsortedSet, I once changed something which looked quite harmless but it somehow got back to me (I think it was the InstanceSet, but I might be wrong). Anyway, removing the assertion should be safe in this case, especially if it is slowing down the process.

 

Sometimes (but admittedly rarely) these assertions can help if you refactor other parts of the code, they are usually an indication that my refactoring isn't 100% compatible with the old classes, so I often leave them. But I really don't like that UnsortedSet neither.

[OrbWeaver]

Yeah, I didn't remove the class because I couldn't figure out its purpose and didn't want to break anything. If there is really a need for a container which retains insertion order but also ensures unique elements, this would need to be implemented using both a list (to retain order) and a map associating objects with their list position (to provide quick access to known elements).

 

I suspect, however, that the only reason this class exists is because the developers couldn't be bothered to define an ordering over the Node objects, which is required for std::set presumably, and somehow didn't notice that their solution was going to be appallingly slow.

[greebo]

These custom classes are sometimes hard to remove. I already attempted to remove the Array class and I failed, but I think I know now what I did wrong, so I could try again soon (I think I made another, unrelated error while refactoring).

 

The Array class behaves identical to std::vector (at least I'm confident about this), but as a new coder like me you don't know that of course when you first encounter it - that's what standard containers are for in the first place... if you don't know that class you won't use it.

[Komag]

I'm just grateful that brighter minds than mine are on the case! Really, I read some of these posts and just feel little inside.

 

Keep up the great work, especially this sort of "deep behind the scenes" junk that people don't notice much even though it's important.

[greebo]

Heh, thanks for that, Komag.

[greebo]

I did some tests in the mapdoom3 plugin with regard to the loading speed. As it seems, most of the time is spent on 1) the progress dialog and 2) loading shaders.

 

While we can't do much about 2), the progress drawing can be optimised a bit, so I added an interleave variable to the registry. Setting it to 40 (only every 40th primitive triggers an update of the progress meter) cuts down the load time of my local bonehoard version from 42 sec down to 25 sec (all shaders cached in memory, hardly any HDD activity).

 

I'll experiment a bit more (reducing the update cycle during entity loading) and will commit my progress.

 

edit: 21 secs after interleaving the entity load progress. The default interleave value is 50 (user/ui/map/loadStatusInterleave).

[OrbWeaver]

How did you do the analysis? With a profiler, or ad-hoc time printouts?

 

I actually suspected that the progress dialog was a bottleneck, but the profiler never indicated it.

[greebo]

The map loading code is already equipped with a ScopedTimer, so I just tested it with a few runs:

 

1. Close all other applications (I only have 1 GB RAM)

2. Open DarkRadiant

3. Load Bonehoard (non-lighting mode)

4. New Map

5. Flush & Reload Shaders (to clear the shader memory)

6. Load Bonehoard again

7. Note time