Moriarti

esselfortium said:

M.A.C. does not stand for anything.

You've never heard of Make-up Art Cosmetics, aka MAC?

Unless you set the FPU to single precision mode, all your floats are going to be converted to doubles when they get loaded into registers, so the only thing you save by using floats is space, not time. (Caveat: Direct3D normally sets the FPU to single precision mode unless you tell it not to. Is DB2 using D3D or OpenGL for 3D mode?)

In regards to flags, why represent them as a bitfield at all? Why not make each flag its own boolean field? This would simplify the map format so a reader wouldn't need to parse a flags string to extract each property out of it. Instead, it just sets a bit in its own internal flag(s) field(s) as it encounters a flag. Presumably any flag that doesn't appear as a field will default to off.

So the example from the opening post could be better written as:

thing 245 { easy = 1; normal = 1; hard = 1; ambush = 1; }

Ajapted said:

That makes the structures a lot bigger though.

Why not move them out of the thing and linedef records and make them properties instead? Most entries probably don't even need them. And why not make the individual flags properties too? Then you don't have to worry about allocating bits for different flags to different ports.

ZDBSP has an option that controls how hard it tries to avoid splitting segs. Try adding --split-cost=16 to the command line and see if that makes the warning go away. If not, try larger numbers until you find one that works.

In this message board thread, a poster named SimmerD claims to have publicly described this technique before Creative patented it. Therefore, there is prior art, and the patent should be null and void. Can anybody comment on that?

Is this extended node format dead? Nobody's talking.