SteveL

They look great! NB Patches get smoothing done on the gpu for free, so you don't need that many polys for the result to look perfectly smooth in game.

That's the same article that I discussed with grayman and greebo when we were first discussing the bugs in our MSVC2013 port back in January. Except that the article's had more info added since then. It didn't have any mention of _controlfp_s or FLT_EVAL_METHOD at the time. I suspect those could fix our 2013 compile without needing us to rewrite any code. I don't know whether those switches can help us with our 64-bit build in MSVC -- the chart in the article suggests not -- so we might still have to bite the bullet and track down the sensitive lines of code. That'd be something I can at least help with... I don't know enough about compilers and OS environments to try to tackle it from the other end.

idVec3 exposes its internal data through its ToFloatPtr() method. That gets passed to openGL a lot, so clearly the code wasn't designed with portability in mind. It's pretty much locked down to the original compiler architecture. The map size issue isn't a problem for TDM, where our biggest map extends less than 10k units from the origin. @motorsep do you get the same issues with patches in your huge maps, or is it just brushes? Patches use vertex coords instead of plane-normal format, so they should be unaffected by distance precision issues, but it might all be the same once they've been converted to collision models.

Do fire arrows toggle extinguishables on a direct hit? Possibly an oversight. I agree it'd make sense for them to always leave the flame burning.

I (eventually!) implemented this as atdm:target_itemremove, found under "targets" in DR. The old func_itemremove was completely broken and hadn't been used in any published map, so it'll be gone with 2.04. The new target_itemremove supports removing unique items, stackables, and ammo. Yes (@Tels) the naming could have been tricky, so I settled on: Unique items: the "name" of the item as set in DRStackables: the "inv_name". The help text in DR spells it out: copy the "inv_name" from the item you want to remove, whether that's "#str_02435" or something custom. Ammo: you have to name the ammo, as it's known in the def files. That would be trickier for the mapper, so the help text lists all the standard options: broadhead, firearrow, gasarrow, mossarrow, noisemaker, ropearrow, vinearrow, waterarrowYou can also set the amount or use 0 to mean "remove all of them". Lastly, there's a checkbox option "drop_in_world", so the mapper can sopecify whether the item is to be removed from the world, or dropped at the player's feet. If the player drops 5 arrows or stackables, a single item spawns which adds the right amount to the inventory when picked up. All the options are set in the entity def to show up in DR when the entity is first created, without needing to click on 'inherited spawnargs', and they all have help text.

That'd help us catch all examples where a float gets truncated, but wouldn't tell us which ones are significant. We probably have no way to know which are significant unless we see bugs caused by them. ID_INLINE idVec3 &idVec3::Cross( const idVec3 &a, const idVec3 &b ) { x = a.y * b.z - a.z * b.y; y = a.z * b.x - a.x * b.z; z = a.x * b.y - a.y * b.x; return *this; } That's the function that my example came from. The tiny difference in outcome quickly multiples into something significant because the cross product is used to define a plane that then gets fit through a distant point. Thinking about it, only a small subset of float calculations could ever suffer from loss of 80-bit intermediate precision. Only those that (1) have multiple steps in the same line, and (2) involve a subtraction. I'm not 100% sure about (2), but I should think you could add or multiply as many floats as you like, and as long as you don't compare them, the loss of intermediate precision won't be significant. A subtraction is effectively a comparison, and that's what's giving us the different outcomes with lower-precision intermediates.

Ta. I'd love to get the brush and pan out and make a major assault on these compiler warnings some time. This is a start!

http://forums.thedarkmod.com/topic/14832-modular-building-technique/

Models are better for the task, and yes you could swap them out later just by updating the model as long as the size and origin are the same. Keep your modules in a separate map so you can update them. There's a script in DR that exports as a model, but I'm not sure it'll be able to handle embedded models. It might work only for fs made of worldspawn only. Sotha made a tutorial thread for this technique I think...

Good luck, I'll be delighted if you find a fix. My pessimism was only at the thought that it could be a tuning-of-constants thing rather than a logic error that you can properly fix. We'd like to make all floating point precision explicit of course, so we're not constrained on compiler setup. Any idea how we could track down all the places in the code that rely on greater intermediate precision? Or any other way round it? The resulting bugs are hard to rep reliably and tough to pin down to a single line of code. We'd not find them all by pre-release play testing.

Thanks again, and to Tels for testing. What's the scripting language in the sconscript? It looks like python but it appears to be case-insensitive on keywords like import and return.

Feel free to PM me your test map with any materials + models needed if it's not working. Your material looks ok except for the bumpmap, and no you don't change the [inverse]vertexcolor keywords. I don't know about modfelling, but I do have a debug build of the engine and should hopefully be able to see why it's not blending.

@motorsep: I'd try the compiler switches that NagaHuntress has already suggested. That looks almost impossible to track down any further. It's one bad result in a billion calculations that use epsilons, and it took you a while to rep it in the vid so it'd be very hard if not downright impossible to isolate the bug in the code.

noShadows 1

The idTech4 code is over 10 years old, but we're still weeding out occasional outright bugs in it still, which is to be expected. This isn't a bug in the traditional sense, it's just bad design or an oversight that unfortunately restricts our compiler options Thanks, I'll test whether that works with MSVC too. When we discovered the problem, I spent some time looking for compiler switches that might restore the old higher-precision intermediates, as did grayman and greebo, but we didn't find any. I didn't try fiddling with SSE. Especially when you don't even need to care about performance. Debug functions output at most once per frame, so there's no excuse for not safely copying the string. There are a few rough edges like that, including a heap of compiler warnings (mostly from the original code) that I'd love to get round to clearing up one day. The idTech4 code has its hairy side. Those string library functions that return pointers to released memory, for example. But it also has some lovely code, especially in the front-end renderer where all the geometry gets done.

Thanks again for another patch. Committed at rev 6529. I can't test-compile code hidden from my MS system by compiler switches, but I'll ask grayman for the release packaging software so I can check the build works with any changes. I'm a bit clueless around OSes.

CVAR_INTEGER in the flags. But I see from the tracker update that NagaHuntress got to it already.

The material looks ok except that you have no bumpmap. You do need a bumpmap in a material to activate the light interaction drawing. Just use bumpmap _flatfor each stage if you don't want / have a real bumpmap. I'm not sure what bit of code is painting those cubes right now, but if you add a bumpmap it'll make sure it's the right bit. The stretching looks like your UVs are messed up. I take it they look ok in the modelling program? The engine occasionally generates its own UVs (texgens) but it shouldn't be doing that in your material. There's a slight chance that the lack of a bumpmap is making some other part of the code that uses texgens kick into action... but that's a long shot.

Thanks for this work. And kudos for your super-speedy bug hunting. It makes sense that all that could be down to the same cause: the skybox only gets drawn in a frame if the player can potentially see it.

Mappers can make that happen with a spawnarg and a script. But I take your point, in the situation you describe it'd be good for it to happen always. I'm not sure we can change the default behaviour. There might be maps where manoeuvering something into position is important, rather than just "using" the target location. Plus, the "using" mechanism needs a world object that the player can frob-highlight. Target locations can be invisible, nonsolid and unfrobbable.

Nice diagnosis. I've seen those string pointers misused before and winced, but only in debug code. Lots of ::Print() functions return a pointer to freed memory too. Debug print functions tend to pass the pointers uncopied to the console, which'll try to access them later. You occasionally see garbage on the console as a result if you have debug logging on. Thanks for the patch, that's an elegant way to fix it. I see idStr's constructor explicitly copies the internal data of the string.

Thanks very much. To be clear, I was only waiting for the nod from you to say you'd done working on it for now. The small chance of a bug in the circs you describe is much less impact than the current situation, that locks the mouse to the game all the time.

Guys, should this be the main release build for Linux? If so we should draw grayman's attention to the thread. I'm not sure what he does to do to package up the release, but obviously it'll be affected. There are some things we do have to test with any replatforming, that a couple of people have hinted at: collision problems, visportal problems, light-interaction problems, possibly (but unconfirmed) ai pathing. The light interaction problems are specific to MS Visual Studio. The VP and collision problems are down to different floating-point architecture in MSVS 2012 and above. Prior to msvs2012, the intermediate results of 32-bit floating point calculations were 80-bit. From 2012, they are truncated to 32-bit. You can see the difference with this bit of test code: float a = -272.514099f; float b = -272.514160f; float c = -93.7499619f; float d = -93.7499771f; float e = d * a; // Result: 25548.1914 float f = b * c; // Result: 25548.1914 float g = e - f; // Result: 0.0f float h = d * a - b * c; // Result in 2013: 0. // Result in 2010: -0.00156380842 That's a real example I tracked down in a map where a visportal was glitching, when we experimented with using the vs2013 compilers. We need to check the result of that test code in any new compiler setup. There are parts of the game and engine that rely on the greater intermediate precision. That problem stalled our work on the 64-bit build during 2.03 development. We could fix the problem for any given line of code by using doubles, but we have no way to track down all the places that need the fix. The resulting bugs are rare and hard to rep.

No, we can set it up in an entity def, so the mapper just places the entity and the LOD settings come by default.

That sounds like it wants a fix. How *do* mappers currently make sitting sleeping AI then? Do you use the pathing system?