DarkRadiant 1.5.0 pre-release sanity check

[Serpentine]

Can I have that specific map where this is happening?

 

Just got home, so I'm gonna try reproduce it now.

 

BD, I thought I kept forgetting to save my changes, really didnt understand what was going on and how I'd fixed the same wall 3/4 times and never managed to save aftwards. Makes a lot more sense now!

[Fidcal]

That is worrying because I'm working on my main map with over 14,000 brushes and patches so I'd probably not notice if some disappeared.

[Serpentine]

Ok, the problem seems to be on map loading, it's skipping the brush(es) during parsing or for some reason excluding them.

 

In 1.40 the same map opens and the brush is placed correctly.

 

This is a texture test map which shows the problem, so if you're not using the svn version everything shows as default textures. The tiled floor infront of the cam, with the lantern bug on it is not there in 1.50 and there in 1.40.

[greebo]

Thanks for digging that up, I'll look into it.

[Bikerdude]

What exactly do I have to do to reproduce that? I just left a brush selected when exiting and there's no crash (release x64 here).

It might be the map, so will keep an eye on it. i will be working on a different map soon and if dosent happen on that then we are ok.

[greebo]

Ok, the problem seems to be on map loading, it's skipping the brush(es) during parsing or for some reason excluding them.

I could reproduce the problem. This is what I've found so far:

 

- The brush is created in memory, but it's getting placed at the origin with its yz bounds set to a huge/infinite values.

- It doesn't occur in a debug build.

- It occurs in the release build, but only the first time you load the map. If you load the map again without exiting DR the issue is gone.

- It doesn't occur in a VC++ 2008 build, only in builds compiled with VC++ 2010.

- It occurs regardless of whether a debugger is attached or not.

 

So right now, it's specific to the first map load in the session in a VC++ 2010 release build. Hooray, sounds like something is going on at the lower levels.

[_Atti_]

My map was missing brushes too.

 

One of my big roof-part dissappeared, i noticed it right after booting radiant , felt like an incompatibility during load, but then i thought i just deleted it accidentally, because i then reloaded the map twice or trice and it was there..

 

But today just as i fired up DR and loaded my map the same exact brush was gone again..

loaded again: still missing

loaded for a third time: it's there and fine..( EDIT: i did quit DR for the second load so thats why it was still missing)

 

EDIT: Yes, the above post systematics of the error is true, it happens only on first load, if reloaded without exiting DR its fine.

 

the brush is a wordspawn brush and its quite complexly clipped., its textured with stone and rooftilings, no special texture. It's a top piece of a tower.

Edited December 10, 2010 by _Atti_

[greebo]

After digging into this it seems this is an issue introduced by the compiler's optimisations. When switching off optimisations (/Od) the problem goes away. Looking at the assembly code I see that the compiler is expanding my while loop twice, and somewhere along these lines the stack is messed up (there are a lot of callbacks going on after the first plane is added to the first brush, and when the instruction pointer returns to the parser's frame the plane values do not get assigned correctly anymore. I don't think I've done anything wrong from the C++ code's point of view, so this smells like a compiler issue (although one always needs to triple check before pointing one's finger to the compiler).

[Bikerdude]

sooooo.. easy fix..?

[Fidcal]

greebo, would you advise me to stop working on my map until this is fixed or does it seem like any lost brushes will automatically recover? I have no way of knowing if I've lost any brushes except by chance.

[Bikerdude]

Fids Ive gone back to 1.4.0, if you need anoher pair eyes to do a sanity check on yer map, you know where I am.

[greebo]

greebo, would you advise me to stop working on my map until this is fixed or does it seem like any lost brushes will automatically recover? I have no way of knowing if I've lost any brushes except by chance.

The brushes definitely won't recover themselves. At this point I can only recommend not to use the pre-release builds for production use and advise to use backups and snapshots extensively - I'm working on a fix in the meantime. I've also been searching the MS knowledge bases for a similar issue as this one, and there are a few user reports about x64 optimisation bugs in VC++ 2010. So far, there's the VC++ 2010 Service Pack 1 (Beta) available, I'm going to give that one a test run to see if it resolves the issue.

 

Failing that, there's the possibility to switch off the compiler optimisation for the mapdoom3 module, or to fall back compiling in VC++ 2008.

[Fidcal]

OK, thanks greebo. I'll revert to an earlier save. I have a pretty good idea of all the work I've done with this version I can save out as a prefab and reload. I just need to check which was the last backup with the old version.

 

Thanks Biker but it's not realistic to go through a map this size. Even I wouldn't necessarily notice if a brush was missing.

[Fidcal]

Second thoughts. I thought this was a couple of days but it's a week and my backup just before then seems I've done more work than I thought, ie, into the realm of unknown work.

 

I'm inclined to do a rough sanity check for any obvious missing brushes and then chance it and restore any if I find some later. So these brushes can be any old brushes or only new brushes made since this version installed do we know?

[greebo]

As the bug only occurs on the first brush being loaded in a DR session, it's usually the first worldspawn brush: Entity 0, Brush 0.

[Fidcal]

Ah good. That one's OK so that's reassuring.

[greebo]

Ok, the bug didn't go away with Service Pack 1 - seems like I'll have to switch optimisation off for that module or method.

[Bikerdude]

Greebs, what impact will this have for the end user? will loading maps be a little slow etc or something else...

[greebo]

You probably won't notice anything, as during map load the most time is spent on loading the textures and models.

 

There's a new pre-release build with disabled optimisation for the brushDef3 parser.

 

32 Bit: http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.5.0pre12.exe

64 Bit: http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.5.0pre12.x64.exe

 

Can somebody confirm this build is behaving better?

[OrbWeaver]

Is there perhaps a single optimisation you can switch off, for example loop unrolling (if this is what it is doing)?

[greebo]

Is there perhaps a single optimisation you can switch off, for example loop unrolling (if this is what it is doing)?

There are a bunch of optimisations to configure, but I couldn't get it to work unless I switched it off completely. I particularly tried the "favour size over speed" setting, but this didn't work out.

 

It's not a huge deal, I could fix it by disabling optimisation for one single method, and I doubt the difference can even be measured in a real-world environment. I'm rather annoyed having to fix something like that in the first place, and I'm hoping there is no other bug cropping up because of the optimiser.

[Serpentine]

Working perfectly here

 

Map load speed does not differ on any larger maps on my side either.

[Bikerdude]

I dont know if anyone else hads this with the any of the pre-release versions, but all of the FS in a map Im working on had an erroneous arg added to them

 

"func_static_4:func_static_4"

 

I have just spent the last 2 hours removing all these.....

 

@Greebo - this was prior to days update..

Edited December 11, 2010 by Bikerdude

[Bikerdude]

testing latest version now...

[Bikerdude]

64 Bit: http://www.dramtheth....0pre12.x64.exe

 

Got another bug, that I have had on 3 different maps.

 

I cant select or unselect items of objects within DR - this effect both items in ortho and menus.

 

1st time: I couldnt unselect an item I have shift-cliked on in ortho.

2nd: pressing escape had no effect on selected items in ortho.

3rd: could click on the light colour button

Edited December 12, 2010 by Bikerdude