News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
 
even when you do it 'properly' you still have weirdness when people disconnect or change teams (TF spies... grr, or worse: TF's animated+coloured teleport pads). 
 
could the corpse then still use the live player's already recolored texture in memory

You still have to keep track of what corpses go with what player. What if a player disconnects? What if a player grabs an invisibility ring? And if you ignore those, you still have to actively monitor any entity to be a corpse and change stuff in the texture manager. And there can be models with invalid skin numbers.

Doing it poorly isn't much easier than doing it right. Even doing it poorly is hard.

There aren't any easy answers for this one, but one of the older Mark V source codes has the changes marked in a straightforward manner. 
 
i've found that assigning a corpse's colormap to the player to work.

if ((gl_color_deadbodies.value) && (ent->model->modhint == MOD_PLAYER))
{
if (ent->colormap > 0)
{
texture = (playertextures) + ((ent->colormap - 1));//Colored Dead Bodies
fb_texture = fb_skins[(ent->colormap - 1)];
}
else
{
texture = (playertextures);
fb_texture = fb_skins[0];
}

Though, i'm getting black skins when someone is culled via cullentities...but the corpse suddenly 'color corrects' itself when the owner of the corpse comes into view.

And for 24bit skins i use ent->pantscolor ent->shirtcolor and run a pass twice over the model for shirt and pants; which DOESNT have any issues at all. 
 
edit:

in world.qc in the bodyque
we already have
bodyque_head.colormap = ent.colormap;

so we are already 'tracking' the color of the owner in quakec. 
Oops Cant Edit Post... 
here's how im assigning the shirt & pants in cl_parse

if ((i > 0 && i <= cl.maxclients) && (ent->model) && (ent->model->modhint == MOD_PLAYER))
{
ent->shirtcolor = (cl.scores[i - 1].colors & 0xf0) >> 4;
ent->pantscolor = (cl.scores[i - 1].colors & 15);
ent->colormap = i;
Fog Rendering Strangeness 
I have linked an image comparison of three views of jam5_hypnos.bsp.

http://i.imgur.com/WIAAvmL.png

It shows how the fog looks in Darkplaces versus Quakespasm 0.90. You will see that if I look across the grimy water in QS the fog colors all of its surface light blue even near me. However, if I walk right to the edge and look down, the liquid texture appears in place of the fog color. In other words, the direction I am looking affects how the liquid surface looks, which is weird.

I'm not sure what is going on here. Could I be using some odd fog setting accidentally that makes it work this way? Does anyone else see this, or does it look more like the Darkplaces screenshot to you in Quakespasm too? 
Further Info 
The rendering effect I described above happens when I have r_oldwater set to 0. If I enter r_oldwater 1 in the console, the scene looks similar to the DP screenshot.

So if you try to reproduce, see if the two different r_oldwater settings have the same effect for you. 
Primal 
Hmm, thanks for the report. At first glance I can't reproduce that, with QS 0.90.0 r_oldwater 0/1 look the same (except the slight difference in water quality). Here's r_oldwater 0:
https://www.dropbox.com/s/z4n1kibgu13qr2i/primal1.jpg?dl=0

I have a guess at what's happening from you screenshot - with "r_oldwater 0" the water texture gets drawn on the screen between frames and copied back to a texture, it looks like it's picking up the fog there.

Would you mind checking whether you get the same issue with fitzquake 085? http://www.celephais.net/fitzquake/

Also, what's your graphics card? 
Same With Fitzquake 
I ran fitzquake with Wine and got the same result when I set r_oldwater to 0 in the console. Same thing with the water texture coming out when looking downwards too.

I have 64-bit Ubuntu on my laptop with an integrated gfx card. Here are some lines from my glxinfo.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30 
 
There are like 3 or 4 different fog implementations in engines and that sucks. 
Here Is A Video 
Here is a little bit of video that shows how looking down changes the appearance of the slime.

I'd like to add that I can simply set r_oldwater to 1 and not worry about this glitch at all. So please don't spend too much time on this as long as it is just my system which has this problem.

http://i.imgur.com/7EhYPvi.gifv

(I should know by now how to record windows without including the header bit, but I forgot to do it right again while making this one. Derp.) 
Thanks Primal 
I will have a look, I should be able to fire up ubuntu on a Haswell laptop. 
Yeah 
happens for me too, Ubuntu 14.10,
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.0 Mesa 10.3.0

Will poke around a bit more 
 
The problem seems to be mesa is choosing to use vertex fog, which it is allowed to do in OpenGL. I tried adding glHint(GL_FOG_HINT, GL_NICEST) but still get vertex fog.

The other half of the problem is, there's a water textured func_illusionary stretching across the whole map; water doesn't get cut up by qbsp, so there are two giant triangles. Since the corners of the triangles are so far away they get fogged to solid white. You can see the issue if you do r_drawworld 0, r_oldwater 0, r_showtris 1, and noclip up above the map. "r_oldwater 1" avoids the issue because it chops up the water surface into smaller triangles that look ok with vertex fog.

So there's not much we can really do... I was thinking of upgrading the fitzquake "r_oldwater 0" effect to glsl at some point, and that would fix the problem since we can force per-pixel fog in the shader. 
Thanks 
Thanks for looking at this, EricW. 
Anyone Here Aware Of Quakespasm Rift? 
Yes... 
cause I posted it on my quakeguy blog ;) 
Software Renderer 
So, i just downloaded Quakespasm source and i'm curious about the software renderer. Has it been removed? Is it possible to compile the engine without GL? 
Yep It's Removed 
QS is OpenGL only, which dates back to Fitzquake.

Check out Fitzquake Mark V which re-adds the software renderer to Fitzquake. 
 
@ericw ... when you modified how the map is drawn by removing DrawSequentialPoly, did you discover any side-effects? And did you fix them?

I recall someone saying something about alpha or sorting --- perhaps alpha entities or water in some odd situations could be wrong. 
 
I don't think there were any issues with the final version of the patch.. the overall draw order is the same as before (opaque entities, world water, transparent entities). Only real difference is, within a particular entity, instead of drawing the faces in the order from the bsp file, they're now sorted by texture.

Maybe it was mh or metlslime pointing out that fitz doesn't depth-sort all of the alpha surfaces. So in your example, fitz and qs should always draw transparent entities on top of water.. this will look wrong if you have a transparent window underwater, viewed from above. MH's engines do sort every transparent surface properly, I looked at that but it's a bit of work to set up.

I do have a test map for checking weird cases like water textured bmodels, fullbrights on transparent bmodels, alpha bmodels in water, etc. Was meaning to upload it but forgot about it. I'll dig it out and upload it tomorrow. 
 
Yeah, it's quite a bit of work to sort all the alpha surfaces properly and even more if you want to add sorting for other stuff like alpha MDLs, sprites, particles, etc. Particles in particular are a bitch; you need to add a second level of "emitters", "active_emitters" and "free_emitters", otherwise you're measuring distance and sorting for every individual particle.

I think the payoff is worth it but it's not something you can just drop in quickly. 
 
Of course even then intersecting surfaces won't work.

People have been asking for a programmable blend stage for years and programmable blending would go a long way towards proper per-fragment fast order-independent translucency. Being able to select between "src + (dst - src) * alpha" or "dst + (src - dst) * alpha" based on a depth comparison should do it. 
 
@Baker here you go:
http://quaketastic.com/files/misc/rendering-testmap2.zip
It's a quoth map, it uses mapobject_custom to load an external bmodel (crates.bsp). There's lots of unusual stuff, I don't remember exactly but the .map is included. Make sure to play with different wateralpha values.

MH, yeah, I'd like to fix it in QS sometime. It's not really uncommon to have the issue show up in maps, either. The teleporter behind you at the start of telefragged.bsp is a good example, it's just a free-floating liquid brush, but QS draws the rear surface in front of the front one. 
 
Interesting, I'll check it out. 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.