Itches, Glitches & Anything Else...

[Komag]

Ah shoot, I hate when crap like that happens.

 

I'll just mention that guru3d.com is a great place to find TONS of driver sets. It can be confusing which ones to download, but I think it's worth trying them.

[Fidcal]

Yeah, it's been a bad day - several sessions and not achieved anything at all today. zero. The drivers for the FX5900 card on guru3d seem to be 3 years old. Searched google. Another timewasting website at driverfiles.net. The FX5900 page claims a latest driver of 6th July, 2007. Oh yeah! right! What a coincidence. They just put it in today especially for me. File size 0 bytes. No actual download link that I can find only misleading other links. They just generate these pages to get click throughs. Oh well, that rounds off a useless day perfectly. :angry:

 

And of course none of this guarantees it would solve the problem anyway!

[New Horizon]

Aside from the Nvidia chipset, who made your vid card? Aopen, XFX? They may have drivers on their sites too.

[Komag]

You don't look on Guru3D by the card, you just get some NVidia "Forceware" drivers for your operating system (such as WinXP 32 bit)

 

Try this page:

http://downloads.guru3d.com/download.php?id=10

 

try a set, see if it works, if not just uninstall and try another, and hopefully you'll get lucky! I've done just this sort of thing with guru3D many times over the past 5 or 6 years, probably half a dozen different cards.

 

Or try an older set, one or two years back. Something in the newer drivers may have broken something.

 

And you're right, it may have nothing to do with the drivers, but now that your custom settings are all screwed anyway, it's pretty easy to try out driver sets, just takes a few minutes really.

[Fidcal]

OK, thanks for suggestions. Went back to guru3d and got the forceware drivers but I still get the error with the grass texture. The card itself was made by prolink at http://www.prolink.com.tw/ - they do have drivers but they are the same version I got last February from the nvidia site.

 

[gloom]

I'm inclined to leave this problem for now as I'm sick of it. I do have another better non-Nvidia card but it needs a psu upgrade I need to search and research and a different type of power cable I've not been able to identify. I had already wasted half a day on that trying to find info some weeks ago and I can't face another day like yesterday too soon. I once estimated I spend greater than 75% of my computer time maintaining/fixing the hard/soft/ware and less than 25% actual leisure or productive work. Those are the good days.[/gloom]

 

For the time being I'll experiment with opening doom before DR or starting with a blank map in DR when I open doom. The problem seems to only be with a map with grass on it actually open in DR when doom is launched. Once doom is running OK then it seems alright I think. I assume there must be other textures that cause the error so I'll watch for that. This may explain various inexplicable crashes over the months I've blamed M$oft memory mismanagement on before.

[Fidcal]

Undo after rotating model causes DR to crash. Quick look on bug tracker shows a similar issue with lights that was resolved but can't see one about models. Is it known? Or shall I add it?

[greebo]

It works fine in my latest SVN build (I'm mapping for a few days now, so I surely would have noticed this). I will upload a new snapshot for you. Will be up in a few minutes.

 

edit: New build is up.

[Fidcal]

Yes - its' fine now thanks.

[Fidcal]

I can get this super slowdown problem in either Doom or in Dark Radiant. I'm sure now I've had this before but dismissed it as a memory glitch. If anyone else gets this problem, the 'rules' to avoid it seem to be...

 

. It may or may not be Nvidia graphics card related.

 

. It only affects the loading phase of either Doom or Dark Radiant.

 

. So far I've only noticed it if a grass texture is being used but I'm sure certain other textures will have the same effect.

 

. Always open doom first BUT DON'T OPEN AND SHOW A MAP IN WINDOWED MODE (ie, if you DO open a map then go to the Dark Mod menu so it does not show.) THEN open Dark Radiant.

 

. If you should open Doom first in windowed mode and also open and show a map in Doom and then open Dark Radiant then Dark Radiant might slow down so close it, switch Doom to the Dark Mod menu and THEN re-open Dark Radiant.

 

. If you accidentally or for whatever reason open Dark Radiant before Doom with a map showing then select 'new' map from the file menu and (IMPORTANT) use the 'flush and reload shaders' button on the texture browser and THEN open Doom. When Doom is running then re-open the map in Dark Radiant.

 

 

Once both are running OK then there seem to be no further problem so it's workable.

[greebo]

Also sometimes when you use the copy texture you and paste texture, you have to copy it and paste it twice in order to paste the x,y,z,scale attributes.

@jdude: I think I finally found that bug that let you click twice in order to paste from a face to any target object. There was a loopback going on which reset the ShaderClipboard to "Shader" instead of "Face" after a single MMB click.

 

I will upload a new snapshot soon, so you can try it out. http://darkradiant.sourceforge.net/snapshot.php

[greebo]

@OrbWeaver: The "Select All" command is taking a VERY long time in large maps (I suspect there are loops running for each selection change). Can this behaviour be investigated using a profiler? If yes, what do I have to do to get the profiler running? Or do you have time to do some tests?

[OrbWeaver]

Yes, I noticed that. I can do some profiling if required, since I'm moderately familiar with the process (I'm also a bit stalled on the OrthoView profiling, since the existing View class seems to be entwined with the selection system in ways which I can't decipher, meaning that I can't simply replace it with the more efficient OrthoViewVolume as yet).

 

If you want to use gprof yourself, you just need to compile with the BUILD=profile option (making sure you do a COMPLETE rebuild), which will cause DarkRadiant to write out a gmon.out file after every execution. You then process this data file with a command like

 

$ gprof -b darkradiant gmon.out > profile.log

 

which will analyse the data and generate the text file.

[Fidcal]

I'm seeing phantom caulk blocks appearing for a second or so while saving the map in DR. I'm aware that while saving, entities (I think) are not rendered revealing what is behind - presumably just because the rendering process performance is compromised while saving. This is only a niggle during autosave and I am not too concerned. But the phantom blocks make no sense. I can detect no such blocks behind where I see them (around the garden gate.) Again, they are no problem but need I be concerned that there is some forgotten obsolete brush somewhere that might come back to haunt me later?

[greebo]

@Fidcal: During the saving process, all the child primitives of func_statics are being moved towards the origin (because they have to be saved relatively to the origin). Not very beautiful to watch, but it works. We could disable the screen updates during map saving to avoid the flickering.

 

@OrbWeaver: I guess I will try that. There must be something stupid going on. A single scenegraph traversal is generally very quick, so it's definitely related to the selection code. It badly needs refactoring, but I really ought to do some SDK coding in the next few days.

[Fidcal]

OK, thnks.

 

How do I scale a texture on a patch? I've just searched the net and as far as I can tell it should be possible the same as a brush but the surface inspector always feints out and disables scaling at 0.25. Pressing the inc/dec buttons seems to have some effect but I'm not certain what as I am working on a tiny cylindrical patch and the values remain at 0.25.

[greebo]

You can't set a uniform texture scale on patches by entering a value in the Inspector, you can only change it relatively. Just hit the arrow buttons in the Surface Inspector and it will increase/decrease the scale by the specified step size.

 

The entry widget is greyed out because there is no way to determine for DarkRadiant whether a patch texture is uniformly scaled or distorted.

[OrbWeaver]

It appears to be maths functions causing the selection slowdowns, at least with my 192-model test map.

 

											 <spontaneous>
[1]	 78.2	0.10   15.16				 SelectionVolume::TestTriangles(VertexPointer const&, IndexPointer const&, SelectionIntersection&) [1]
			0.46   10.28 2048640/2048640	 matrix4_clip_triangle(Matrix4 const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector4<double>*) [2]
			0.99	3.06 2048640/2048640	 BestPoint(unsigned int, BasicVector4<double>*, SelectionIntersection&, clipcull_t) [4]
			0.06	0.02 2051712/2051712	 IndexPointer::end() const [116]
			0.03	0.04 4097280/4097280	 IndexPointer::iterator::operator+(unsigned int) [127]
			0.04	0.02 2048640/2048640	 IndexPointer::iterator::operator+=(unsigned int) [128]
			0.05	0.00 6145920/6145920	 VertexPointer::operator[](unsigned int) const [138]
			0.03	0.03 2051712/2051712	 IndexPointer::iterator::operator!=(IndexPointer::iterator const&) const [140]
			0.04	0.00 6145920/6145920	 IndexPointer::iterator::operator*() const [147]
			0.00	0.00   27648/18465411	 BasicVector4<double>::BasicVector4() [16]
			0.00	0.00	3072/3072		IndexPointer::begin() const [1442]
-----------------------------------------------
			0.46   10.28 2048640/2048640	 SelectionVolume::TestTriangles(VertexPointer const&, IndexPointer const&, SelectionIntersection&) [1]
[2]	 55.1	0.46   10.28 2048640		 matrix4_clip_triangle(Matrix4 const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector4<double>*) [2]
			0.20	6.09 2048640/2048640	 homogenous_clip_triangle(BasicVector4<double>*) [3]
			0.40	3.30 6145920/6145920	 matrix4_transform_vector4(Matrix4 const&, BasicVector4<double>&) [5]
			0.17	0.00 24583680/61507028	 BasicVector4<double>::operator double*() [31]
			0.12	0.00 18437760/54338909	 BasicVector3<double>::operator double const*() const [38]
-----------------------------------------------
			0.20	6.09 2048640/2048640	 matrix4_clip_triangle(Matrix4 const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector3<double> const&, BasicVector4<double>*) [2]
[3]	 32.3	0.20	6.09 2048640		 homogenous_clip_triangle(BasicVector4<double>*) [3]
			0.61	0.33 2048640/2048640	 Vector4ClipPolygon<Vector4ClipGT<IntegralConstant<0> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [10]
			0.70	0.24 2048640/2048640	 Vector4ClipPolygon<Vector4ClipGT<IntegralConstant<1> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [11]
			0.67	0.26 2048640/2048640	 Vector4ClipPolygon<Vector4ClipGT<IntegralConstant<2> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [12]
			0.56	0.30 2048640/2048640	 Vector4ClipPolygon<Vector4ClipLT<IntegralConstant<2> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [13]
			0.68	0.17 2048640/2048640	 Vector4ClipPolygon<Vector4ClipLT<IntegralConstant<1> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [14]
			0.57	0.21 2048640/2048640	 Vector4ClipPolygon<Vector4ClipLT<IntegralConstant<0> > >::apply(BasicVector4<double> const*, BasicVector4<double> const*, BasicVector4<double>*) [15]
			0.78	0.00 18437760/18465411	 BasicVector4<double>::BasicVector4() [16]

 

This is the call graph for the top three functions, with each "child" line showing first the time spent in the function itself, and then the total time spent in the function and all children.

[greebo]

Did you drag a selection rectangle over the map or did you choose "Invert Selection" or "Select All"? The latter two shouldn't involve any math functions at all, but still take ages.

[OrbWeaver]

This was with a selection rectangle. I am sure there is some optimisation possible, since if the model's AABB is fully enclosed there should be no need to test the triangles.

[greebo]

That's right.

 

Could you make another profile of the "Select All" command? It is also very slow and I'm curious what the reason is.

[OrbWeaver]

I had a look, but I cannot find any "Select All" command on the menu and pressing Ctrl-A did nothing. I tried with invert selecton (I key) but this was very quick.

[greebo]

Could you have another go at the bonehoard or graveyard.map (both are on SVN)? It takes at least 7 - 10 seconds to take the "Invert Selection" to take effect in the smaller one of these two.

 

(You're also right about the Select All command - it doesn't exist.)

[Fidcal]

Texture copying aligns with reference to the world. Sometimes I want to copy with reference to the surface. Is that possible? For example, two panels side by side. Panel 1 has a texture A ... Z

 

Panel 1...Panel 2

ABCD..................

 

Paste 1 to 2 you get...

 

ABCD.....GHIJ

 

But what if you want...

 

ABCD.....ABCD

 

I got round this by moving Panel 2 to the position of Panel 1, pasting and with Texture Lock moving it back.

[greebo]

Your workaround is probably the way to go. There is no easy way to clone the textures from faces, because they can be completely different (imagine pasting from 4 sided to 8 sided faces - no exact copy is possible). However, if the faces have indeed the same number of edges, a subsequent translation of the shader coordinates could do the trick, I'll have to check that.

 

Track it and it might get looked into.

[Fidcal]

OK, will do - though I'm not sure yet how often it would be needed (I'll know in a year's time!) so don't know how much effort it is worth.

 

While I'm here - another thing that is starting to bug me. I've mentioned before about the camera speed for fine tuning and you kindly reduced the minimum to 1. Now I'm finding I am frequently switching between high speed and low speed as I am spending more time mapping. I can't imagine how people manage with one speed. Is there any way to have some sort of shortcut? Maybe two speed settings and a hot key to switch between? Or maybe better, just the one speed setting as now but slider keys like the keys that zoom in and out the grid size, to increment/decrement the camera speed.