thought I would report it just in case.

vis.c: In function �LoadPortals�:
vis.c:1120:9: warning: ignoring return value of �fscanf�, declared with attribute warn_unused_result [-Wunused-result]
fscanf(f, "\n"); 

Using independent surface caches for texture & lighting, and combining them in realtime.

The drawing routines of liquid textures (and now, of power-of-two textures too) were mixed with the drawing routines of regular surface-cached routines, combining the texture & lighting in realtime before blending the result into the framebuffer.

It's not difficult to do, just really tedious. Involves modifying and rewriting a lot of code. 

@ericw: I'm curious if it would be possible to add support for func_viscluster brushes in order to negate large open spaces. I'm of course assuming that vis leafs automatically chop up empty space into leafs every 1024 units. https://developer.valvesoftware.com/wiki/Func_viscluster

Spikespasm:
Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000. 

AFAIK, there is no chopping of space every 1024 units in this qbsp, that feature was added in quake 2's.

func_viscluster - this sounds like purely something to speed up the vis computation. It's probably possible to add to Q1 tools, it wouldn't help with reducing the number of leafs though. 

This just popped up now as I'm working on my map. Bounce lighting started generating random black spots in this one room of my level:
screenshot 1
Here's how it looks with bounce lighting turned off:
screenshot 2

Any idea what's causing this? I was changing my light entities around, but I can't figure out what I did that caused this. Has anyone even seen this before? Help would be greatly appreciated :s 

At least somebody's happy about this...

I tried running the map through 0.15.5 and the issue went away. I'm guessing then that this is an issue caused by the new approximation methods in 0.15.7... 

I hate making a third post like this, but I tend to write in a very "stream of consciousness" manner... Anyway, I tried the -novisapprox flag on the command line and the issue persisted, so that's not the problem. 

I've never seen that, definitely a bug. mind sending me the bsp? 

Sure, I just shot off an email.

I'm guessing it is some kind of regression from 0.15.5, although I couldn't say what other than that it seems to be bounce-related. 

I got an email back from eric and the bug was fixed. Thanks for the quick response! :) 

Could somebody help me with this little thing that annoys me so much :

https://drive.google.com/file/d/0BwxYkKdSD855Mzhuc3ViNVo5YzA/view?usp=sharing 

can you turn off texture filtering in game and see if this still happens? 

bilinear filtering -- the last row of pixels blends with the first row of pixels, since it's a tiling texture. 

In the black/red colored view it looks like the texture is mirror imaged. Is it one continuous surface going from from red to black or is it actually two different brushes? 

It is same exact texture but one of axis is mirrored "-1" it is 128x128pxl, and those brushes are exactly 128x128 and next to each other.. so filtering is making this to happen, that is looks like it is.. like 0.5 pixels or something? 

..so filtering is making it to look, like it is 0.5 pixels off or something* 

get up close and toggle between gl_nearest and gl_linear and you'll understand what's happening. You'll need to hide this pixel-wide blend by not using the full width of the texture on that polygon. Either scale it up slightly or make the polygon slightly smaller. 

Thanks metslime, I haven't tried scaling up yet - maybe that will work. 

Any time there is a difference between the textures on adjoining surfaces there will be a noticeable line if GL filtering is used.

I call them GL seams, and any kind of rotation, x/y shift, flip, mirror, etc. will cause it. Even just pixel color differences will cause it. 

It is interesting.. it really looks like there isn't different pixels in this case, if I understood what you meant by that. I have no clue how GL filtering works, so basically I can't avoid these things to happen.

For example I should create texture that points out on every main angle? Then I should have seamless street texture to fill everything in middle.. I was trying to create streets which has some messy garbage on both sides but middle is a lot cleaner. It really seems like that brown/black line in middle is like texture's starting pixel line, because its end and beginning has different pixel colors. The way GL filtering works.. does it look every texture individually and doesn't care about rotation, x/y shift, flip, mirror at all and that is why something like this happens sometimes? 

Does it try to blend blend pixels with next pixels.. if I offset it by 1 it is already in beginning, so it tries to blend with those pixels? 

What I did when making a series of similar textures was to create one common frame to use for all. Basically just the outer 1 pixel border of a 64x64 square. I used that to make different variations where the middle part was different but the pixels around all four edges are exactly the same for all.

For 128x128, I just repeated the 64x64 frame. Textures made this way have no GL filter seam/line as long as they meet at the 64 unit boundaries.

To make sure no weird texture alignments happen, I never use texture lock. I only turn it on if I really need it. 

I thought we would have moved on from GL filtering as a society by now. Horrible concept really. Yay filtering. Let's blur all the textures. No glasses for you and contacts thrown away for you and baske in the glory that is nearsightedness on a screen.

</endrant>
(P.S. I'm nearly blind and need powerful contacts so I may be biased.)

Also this blending is not a compiler issue. The adjacent face has a different texture alignment and therefore is split into a separate face for blending purposes but thats the extent of compiler related. 

I might have used texture lock too much.. sometimes it was just left pressed down. Checking something like that multiple times, especially when placing lamps and such things confuses a bit.

I must be weird, because in some cases I want to have more control over things how wide/high some brushes should be.. and if there is only texture available that is 32x32 for example, but I want it to be 16x32 or 32x16 I have to cut it and offset other half so 'borders' are in right place. Creating new textures sounds like, I would probably fail at trying, I'm not an 2d artist by any mean. 

You could split an existing texture in two halves in PhotoShop, then use them in your maps. This way you wouldn't have to offset your textures, which can be tedious.