Early Z means that the GPU can reject polygons based on depth before it gets to the fragment shader stage; hardware that doesn't support early Z can only reject after the fragment shader. No overdraw, the only overhead is in the vertex shader and primitive assembly, all good stuff. I believe that if you've got hardware T&L then you've also got early Z.

Loading from the map file would be great; you get no surface subdivision so there's none of that horrible heavy tesselation that Quake maps have, and that is a huge cause of slowdown. I believe HL2 stores the original map brushes in the BSP for exactly this reason, and it's something I'd be very in favour of if the community ever did get around to discussing proposals for a replacement BSP format.

Another neat trick - you can turn off backface culling for the world and all brush models. Quake backface culls in the engine anyway, so it's a completely unnecessary test for the GPU. Very small performance gain. 

Can someone with access to Hammer convert those arcanum sources to standard map format? Without the extended rotation shiznit? 

i couldn't load them in 1.6, so i guess it's the hl2 hammer? 

Especially when you land on the giant angel statues and they break ;) 

that was a nice touch. i was pretty surprised when it happened cause i was really focused on trying to make the jump from the spiral stairs to the platforms across the room. :P 

> if the community ever did get around to discussing proposals for a replacement BSP format.

It will. 

Read a bit about the 220 map format, and if I understand correctly, you can't really convert it to standard map format without loss of information. The texture axes stored in the map file cannot be reproduced in Quake because Quake uses a combination of two axes of the world coordinate system for the textures (hence the limits to texture rotation lock in standard Quake). Or do the extended compilers that come with the Quake adapter for WC 3.3 do some extra magic here? 

WC can export to .map. Are there differences between the Arcanum .rmf and the .map sources apart from the junk Hammer inserts? Which format corresponds to the bsps? 

"that seems pretty much impossible, I can't imagine how that could happen, fuck. In a month when I'm back I'll find the vised ones if anyone still cares I guess."

ReRelease it for QuakeExpo :D 

arc5: xvyyrq fbzr mbzovrf naq fpentf, "1 zber gb tb" ohg gurer vf abguvat ncneg sebz Fuhool (jub V'ir gevrq gb xvyy). Jung abj? 

If you don't find anything, there may be a spawning issue. 

You make the map in .rmf, then you export it to .map, then you compile the .map using txqbsp or any other compiler which has support for valve 220 texture format. If you want to edit the source you have to edit it in .rmf (because if you load the .map file into an editor many of the textures will become mis-aligned. But if you just want to re-compile then you should be able to just use the .map files included in to source. 

That's cool, so the textures do not get misaligned if you compile the map with a compatible compiler, then play in Quake? In other words, no oddly stretched textures on faces that are not on the coordinate planes anymore? 

tbh Valve 220 format needs to die, it causes unnecessary problems with the workflow when cooperating / teamworking etc.

Just my opinion. Quake is messy enough already. 

I'm still wondering whether it actually fixes the texture alignment / stretching problems in Quake or not. 

Without it texture lock wouldn't work and it would take a lot longer for (me) to make maps. 

 

about the doomishness that Negke noted - I felt that way too. It was a good feeling.

Also, though I found it initially frustrating, I really like the 1st map, and I feel like it's getting weirdly picked apart. I mean, look at that second screenshot - I'd be proud if I had made that area. And the part with the blood was awesome!
Other than being way to hard in the beginning, I feel like Arc1 is a very nice 'little' map. 

You mean texture lock would not work without Valve 220, right? Just to make that clear. So the texture coordinates that compilers (which understand Valve 220) generate using the texture axes stored in a 220 map file are perfectly fine for stock Quake?

I'm asking because (TADA) I'm working on an level editor for OS X and I'm wondering whether I should support Valve 220. And if the above is true, it looks as if I should. 

from my brief time working in HL2, i recall the hammer 3.3 texture alignment was more accurate in some ways. you could rotate a face by strange angles (3, 86) etc, and the textures would never move. there were also texture alignment helpers that were not present in quake editors. for example, you could align a texture across multiple faces that were not on parallel planes.

otoh, this could just be down to poor coding on quake editors? i have no idea how tex alignment works but it seemed like the quaternion thing gave extra info that helped do complex tex alignment. 

It may be possible in standard Quake map format, I'll have to investigate, but my feeling says it isn't.

And there are no quaternions in 220. The map format allows you (or the editor) to specify arbitrare texture axes. In standard Quake, it always uses the two coordinate axes that have the largest angle to the face normal. Textures are then parallel projected onto the faces, which also leads to the skewed textures you see on faces that are not parallel to the coordinate planes. 

what standard QBSP does. It generates texture coordinates from that, so it might be possible that extended compilers allow proper texture application without a change to the engine. This alone would be a big improvement. 

And there are no quaternions in 220

oh ok, i just saw [0 0 1 0] in the .map file and assumed it was that. 

So did I at first, but it's the offset plus the coordinate axis for X / Y. 

I dont really know the inner workings of it, or whether or not it is possible to make a completely accurate texture lock without it, I just know that the texture lock in Worldcraft 3.3 and 3.5 works better than any other i've used. But if you made an editor which could load a '220 map and than save it into a standard .map format so that you could then load that .map file into any other editor - that would be very useful :)