Not sure how it would react to a BSP2 map. Could you link me one? Just got textures working and would love to give it a whirl.

On the topic of textures, I have them reconstructed correctly. I went full old-school and created textures by using the indexs from the .bsp into the genuine palette.lmp. I'm sure I could have dumped the textures and done some kind of substitution, but with how every Q1 .bsp has its texture data embedded, it'd be a shame to not be able to just load any .bsp and use what's already included. Plus it's more authentic this way, ensures that the texture colors are pixel perfect.

What's not pixel perfect is the scale of the textures. I've used the dotproduct to generate the texture coords for the verts, and they are rotated correctly, and their scale does change how it should when I adjust it in trenchbroom, but they still need to be scaled up, there are too many tilings of a texture on any given surface.

I noticed that it says to divide the result of the dotproduct by the texture width. Could you elaborate on this a little bit? I'm trying to do that, but I end up with a strange minecraft-esque texture. 

Screenshot showing ivory.bsp loaded:

http://imgur.com/DukiW4C

Not going to be able to rely on Unity's batching to save me, since all the textures are generated at runtime. Will think of something clever, I'm sure. 

https://www.quaddicted.com/reviews/something_wicked.html 

I have textures working perfectly now. Scaled and everything. The Ivory Tower is looking much better!

http://imgur.com/ueMK4Qa

The only bug I'm running into now is when I try some maps from Quaddicted. Some (most older) maps don't load because I end up with invalid texture dimensions.

Newer maps are working fine. Here's Q-Deck.

http://imgur.com/dt9JFcW

Some old maps work fine. Like this one: https://www.quaddicted.com/reviews/deso.html

I've noticed in maps that don't work that there are textures that start with z that seem to be the only ones getting incorrect data pulled. An example is https://www.quaddicted.com/reviews/fmb6.html

Anyone have any insight into this? It doesn't seem to be me reading the wrong size data, as the textures in the map that don't start with z read correctly, and show sane dimensions and offsets. It's only the "z" textures that are screwy. 

Here's the github for this if anyone is interested. Just like the Q3 version it's free to fork/copy/whatever.

https://github.com/mikezila/uQuake1 

For the thousandth time, tronyn's is NOT BSP2, it's 2PSB. 

(Think I'll let the weird Spanish translation stand for that one)

ALLCAPS, I can send you a true bsp2 map in a couple of hours; back to the office today.

Do you just need the bsp? 

Yes, just the .bsp itself. 

The dropbox folder (mail etc. sent).

The BSP inside 'should' always be a fullviz, if that matters to the port process.

If not then I can upload one quickly enough - it takes about 10 minutes to compile, using Tyrann's tools. 

Vis data is not used (or even parsed) currently, so that won't matter. I do plan to implement it in some capacity, but haven't yet. Trying to tackle the performance of loading big maps first, so that I don't end up having to refactor a bunch of stuff. I suspect implementing vis will cause/require me to change how I generate my objects, and before I do that I want to see what performance gains I can get. 

What's in there should definitely work as a decent benchmark then. 

If your meshes were grouped together better, then I'm sure you could use unity's occlusion culling feature (pro unity only tho) 

In theory you could just skip adding mesh colliders to the faces as you made them, and then create meshes from the bsp brushes in the map, and a collider to them, and skip adding a renderer, so you have an invisible clipping brush. That would be needed for sure on some maps, where simplified collision stops the player getting hung up on detail in the map.

If you have access to the .map file, and use the brushes in the .map file to generate the collision meshes, then a couple of things occur to me:

1) You could detect which brushes are essentially boxes (probably a lot of them), and use box colliders for them instead of mesh colliders.
2) The non-box brushes are still guaranteed to be convex, so you can enable the convex flag on their mesh colliders, which I'm sure helps. 

Hmm. Doesn't the .bsp have primative bounding boxes in it for fast collision testing? Maybe I'm thinking of the wrong thing. I didn't mean to use the .map to create boxes from brushes, I thought they were in the .bsp. I think I used the word "brush" when I shouldn't have, causing confusion.

I hadn't even thought about marking the mesh colliders as convex. That's a great point. I'm about to start doing some System.Stopwatch tests to see what takes the longest and what is worth it to optimize and what isn't.

Still haven't looked into lightmaps, but from a cursory glance it looks like they're not going to be simple; at least not as simple as Quake 3's were. 

no. bounding boxes in bsps are for frustum culling. they're not useful for collisions as the bsp tree will cull all that effectively enough anyway. 

Trying to parse the vis data, and I'm trying to verify that I correctly understand the run-length encoding used. Consider:

10100010

Would that RLE to

1010310
or
10100310

Some places say that Quake vis data only does RLE on runs of zeros, but the only doc I have is the one that has proven to be very outdated. 

Can a face be part of more than one leaf? 

I've sped up start up dramatically. Replaced all remaining Lists with length initialized arrays. This cut startup time on ivory.bsp (which as become my benchmark) from two and a half minutes to two and a half seconds.

I also detect clip/skip faces and don't render them, which makes maps a lot more fun to fly around!

Here is a build for you guys to test out and play with:

https://dl.dropboxusercontent.com/u/5408868/qtest.7z

I've included Sock's ivory.bsp as the default map because it is awesome, and I used the spectacular rockwork to test/verify my texture creation/application was working right, which it is.

If you'd like to try a different map, open the "assets/resources/maps" folder and name the map you'd like to try "map.bsp" and it'll be used. The camera will spawn at the world origin. Mouse1 will move you forward, Mouse2 backwards. No WASD, just mouselook.

Currently there is no vis consideration at all, so what is being rendered is up to Unity. This isn't ideal at all, so the map might chug if your video card isn't up to it. Give smaller maps a try!

Currently only BSP29 maps are supported, but BSP2 support will be trivial to add. I'll do it next session I think, to take a break from fighting with vis data. 

Could you explain, what the main purpose of that uQuake util 

Doesn't run on my rig 

not a valid Win32 application apparently. 

Sorry forgot to mention that build is 64-bit only. I'll build a 32 bit version.

Honestly I'm not sure what the ultimate purpose is/will be. Really I'm just doing it because it's fun to make. Though Unity runs almost everywhere (Windows, OS X, iOS, Android/Ouya, web browser, Windows Store/Phone, etc) so if I can pull it off the end result will be a (free) Quake engine for a bunch of devices. Really now I'm just doing it as a programming project based around one of my favorite games. 

You might also need the Visual C++ runtime on 64 bit, which is here (it's tiny) http://www.microsoft.com/en-gb/download/confirmation.aspx?id=14632 

Not had much chance to get things on my blog recently, but put out a short article today.

http://tomeofpreach.wordpress.com/2013/10/19/random-entities-find/

It's a combination of a neat mathematical trick and a little bit of glue code which allows you to select one entity at random from find or findradius result sets. There's also a pattern at the end for writing find loops, so you don't have to repeat your find code at all. Whether it's an actual improvement or not is up for discussion... 

Sorry for the 64-bit snafu. Also sorry for using Dropbox, it's not the best for sharing public files. Lets try Github instead.

https://github.com/mikezila/uQuake1/tree/master/Builds

Pick your favorite flavor, 32 or 64. You might need the Visual C++ 2010 runtime if it complains about Mono.