This is not an engine issue, the original id maps do not have transparency visibility calculations, so the engine reads the map file and sees that there is nothing behind the water when you are on the other side of it. You will need to find the patch that either recompiles the maps with transparency, comes with maps already compiled or has .vis files (i think it's .vis?) that has new visibility calculations (fitzquake engines do not support that afaik, so this isn't an option if you want to use this engine, you will need replacement maps). 

What necros said, plus: if you want to fix this in a hacky way, set r_novis to 1. This will make your framerate worse on large maps, but will fix the visual issue. 

Are these UV problems different when compared to other engines? Does GLQuake do it wrong too? 

r_novis 1 works, but the moving brushes are not visible through the water. They show up only when you enter the water. Secret door in E1M2:

http://s29.postimg.org/agce9rf07/spasm0000.jpg 

Looks like GLQuake has the same problem. I made a few shots to illustrate.

WinQuake:
http://i.imgur.com/TqDpxj0.png

Quakespasm:
http://i.imgur.com/NRFNIGg.png

GLQuake (Bengt Jardrup's build, but it was the same in vanilla):
http://i.imgur.com/6A0d4bx.png

DirectQ:
http://i.imgur.com/fbLkr1O.png

Look at the weapon's clip. WinQuake and DirectQ shots represent the way it's supposed to look. 

Mark V supports .vis files 

With a very odd error;

QUAKE ERROR: SZ_GetSpace: overflow without allow overflow set

Googling around, all I can get is this;


if (!buf->allowoverflow)
Sys_Error ("SZ_GetSpace: overflow without allowoverflow set");


Which is engine code and I think means "map is too big"

Most of the explanatory stuff I could find is either 404 or related to Quake2 config files being over 8k.

The map I'm working on is actually close to finished, I hoped to have the beta ready for tomorrow. Anyone on the QS team able to lend a hand?

It is a very big and complex map, but compiles in about 25 minutes and was last running in the engine this morning :[

The dropbox folder is updated with the broken bsp if anyone who already has the link to that wants to take a look. 

mind firing me the dropbox link? email's in my profile.

It seems to be a generic "buffer filled up" error, but it should be obvious from seeing the stack trace exactly what limit is being hit. 

There were more edicts than would fit in the signon buffer (in SV_CreateBaseline).

Bumping these constants fixed it:

net.h:
-#define NET_MAXMESSAGE 32000 /* johnfitz -- was 8192 */
+#define NET_MAXMESSAGE 65536 /* johnfitz -- was 8192 */

quakedef.h:
-#define MAX_MSGLEN 32000 // max length of a reliable message //johnfitz -- was 8000
+#define MAX_MSGLEN 65536 // max length of a reliable message //johnfitz -- was 8000

I got the larger values from RMQEngine. Searching for uses of these constants, it looks safe to bump them; i.e. doesn't seem to break the protocol. 

 

65k? owowowowow!

the actual limit is a bit lower than 65k due to header overhead of 8 bytes, so the protocol limit is actually 9 below that (ignoring limits not imposed by data types).

make sure you don't try sending a datagram that big. datagrams larger than 1448 bytes will always be problematic.
not that you have a choice, but whatever. 

ok, thanks for the info. Fyi the numbers for ijed's map are:

2130 edicts
32176 byte signon buffer 

ijed, is there no way to delay spawning some entities? That's the usual way of solving signon buffer problems. Either with delay spawn monsters or if you've got lots of map models or some such, you could spread out the setmodel() calls after 1 second a bit with random thinks so the engine doesn't have to do everything on the first frame. 

Yes, I need to look into that next. The qc is pretty standard and therefore not really optimized for this type of large map. I'll be putting in some random delays to spread the load before release. 

Committed. But i'm always weary of limits on 2^N. If there is an off by 1 error, they arent always easy to catch. (2^N)-1 is easier for me to take. I'm not much of a C guru, laugh. 

Lowered those to 64000 (see Spike's post #725.) I am not happy with this limit bump at all, but let's see how it will turn out.. 

http://quakespasm.sourceforge.net/devel/quakespasm-r898.zip

Sorry, but i still havent tested that wheelmouse hack on windows (rev 884). It is still in subversion, but if it has nasties it should be removed.

Come winter maybe i'll get the chance to play through some of tronyn's pre-quakespasm mods, which only ever crawled along on my boxes with darkplaces. 

]save pak0.pak
Saving game to /home/me/.quakespasm/id1/pak0.pak...

and on the next start:
QUAKE ERROR: ./id1/pak0.pak is not a packfile

Please always append .sav to savegames if the user-supplied name does not already end in .sav 

 

 

Imagine getting that stuffcmd'd from an evil server. :)

I guess it is an old original bug that most engines are vulnerable to. 

Never have thought such a way of shooting myself in the foot... 

I posted a few patches on: https://sourceforge.net/p/quakespasm/patches/

The most substantial one is the brush model drawing rewrite to use the world drawing code. This should fix the problem necros mentioned in the screenshots thread, where large brush models kill fps. In the unreleased telefragged.bsp, the patch doubles my fps in one place, from 18 to 36. The downside is a divergence from the original fitzquake drawing code.

The other one that's interesting is the lightmap fix for mfx's map. It turns out the dimensions of the lightmap data for each surface are calculated via a fragile floating-point calculation (something like a dot product of vertex coords and texture coords). The engine and light compiler need to do the floating-point math exactly the same.. more so than C guarantees. If my understanding is correct, this affects all engines and all compilers. For anyone compiling a map compiler, make sure it's not using SSE2 floating point, which it probably is if you build a 64-bit executable! 

skip removal tools operate differently on brushmodels than world models, relying on the fact that engines draws them differently. If you don't traverse the Surfaces list on brushmodels, and instead use Marksurfaces, skipped polygons may end up getting drawn on brushmodels. Have you checked this in any maps with known skip textures on brushmodels? 

thanks for the warning - I left the loop over the model's surfaces in R_DrawBrushModel the same as before (just replaced the call to R_DrawSequentialPoly with a new R_ChainSurface), so that still works correctly, and just verified it in a test map.