1) The QMB trails. Yeah, those sometimes they get confused. Inherited from the JoeQuake implementation. At some future date I'll fix that. It is hard to reproduce, annoys me too. It is more frequent with non-Microsoft compiler (Mac version has it happen more often).

So could be the compiler doing it. On longer term list.

2) Blue particles become orange ... yeah, I hear you. Likely similar issue to #1. Also I noticed Shambler charge up has slight checkerboarding and doesn't in JoeQuake -- tried to unearth the reason, couldn't figure it out.

Those little nuisances will dealt with at a future, but I think I inherited from JoeQuake implementation or compiler related or compiler optimization.

My mana bar is too low for me to take that on right now. 

The shambler thing doesn't actually look bad....


Wow, super ugly effect in DX with:

vid_hardwaregamma 0
chase_mode 2
chase_active 1

and swing the camera outside the wall. Doesn't occur in GL.

gl_clear 1 fixes it.

Is there any reason why someone would want gl_clear 0 [default]? 

Decided to add support for multiple replacement crosshair textures.

Dot crosshair (currently crosshair 2), will become crosshair -1.

@gunter - gl_clear 0 is faster and you don't have to redraw the status bar every frame (if the status bar is solid like original Quake and not transparent or see through). 

Replacement crosshair texture names will be named

gfx/crosshairs/crosshair_1.tga
gfx/crosshairs/crosshair_2.tga
gfx/crosshairs/crosshair_3.tga
gfx/crosshairs/crosshair_4.tga

Expected 32 x 32 texture with alpha channel.

A JoeQuake/ezQuake/Qrack crosshair is likely to work if it is a .tga

I named the texture names slightly different than DarkPlaces which doesn't have the underscore, because I don't know what rules/sizes DarkPlaces expects for a crosshair texture and it may suppport things like huge sizes, which I would not be willing to do. 

Is "gl_clear 0 is faster" just academic at this point, on modern hardware? Even on my ancient netbook, I can't tell any difference in performance. 

Yeah, gl_clear 0 is rather academic usually.

@gunter - I may have fixed the QMB trails being jumpy. Maybe. Looks good so far.

Crosshairs in next version

Changed my mind. Per weapon crosshairs so if someone makes a single player release with a weapon they want special crosshair available, automatically takes effect.

Like if someone were to make a crossbow (Drake), could use custom crosshair for that weapon.

Crosshair details

// Yes, sadly it appears 24 weapons are possible. Quoth plasma gun is 24, as far as I can tell.

gfx/crosshairs/weapon_1.tga to
gfx/crosshairs/weapon_24.tga

gfx/crosshairs/default.tga // user's crosshair

scr_weapon_crosshair - defaults on. Use a single player release's crosshairs. Set to 0 to not use them.

crosshair 0,1,2 from previous builds continue to work as-is.

I've seen some mods that do stuffcmd ("crosshair 4") and it's just bad design. What the mod typically wants is per weapon crosshair anyway.

This will let single player releases provide crosshairs for crossbows (Drake) or even a empty texture for axe (no crosshair) or maybe a funky one for a high tech weapon. 

Build 1013 - Windows Open GL | DX8 | WinQuake

1) QMB trails being jumpy possibly fixed (gunter)
2) Per weapon crosshairs replacement texture support (c0burn)

scr_weapon_crosshair, defaults on -- allows single player releases to provide per weapon crosshairs. So if a mod has a crossbow like Drake (A Roman Wilderness of Pain, Something Wicked and a few others right?) or a high tech weapon and wants a special crosshair, it can do that.

User can set scr_weapon_crosshair 0 to not use the single player release's crosshair and just use normal crosshair. Player can still use gfx/crosshairs/default.tga to have a texture replaced crosshair.

Still tuning func_illusionary mirrors -- func_illusionary mirrors is not in the above build. 

Another fine catch.

When I rewrote QMB particles, I missed something. Should be able to make the behavior proper. 

If you are using using TE_GUNSHOT as a particle effect in splash1.dem, QMB modifies that into an effect. 

Should be the final temp build

Build 1014 - Windows Open GL | DX8 | WinQuake

Addressed some issues mostly reported by gunter and a few small things I noticed, like drawing external crosshairs slightly wrong.

func_illusionary mirrors is not in the above build.

func_illusionary mirrors will be in next build now that I finally have closed out all bugs reported. Needed to have a clean and stable base before putting in the complex changes for func_illusionary mirrors. 

AFR setups will generally require gl_clear 1 in order to activate properly, while other setups won't really care too much.

why numbers for crosshairs, and not filenames? 

why numbers for crosshairs, and not filenames

I'm guessing you mean model names? Like gfx/crosshairs/v_axe.tga or soemthing to that effect?

Here is just my thoughts ...

cl.stats[STAT_ACTIVEWEAPON] == (1 << i)

cl.stats[STAT_ACTIVEWEAPON] is a bit flag with 24 possibilities (but not 32? Because QuakeC is floating point, can't do unsigned?).

I used what sbar.c knows about the weapon, which is the weapon number.

Never thought of the idea of using the model name, that being said isn't it true that QuakeC could set anything it wanted as the view model weapon (including none!!)?

So QuakeC itself does not know the concept of a view weapon model, as far as I know. Someone could write some QuakeC where a fully charged weapon uses different model? 

I meant for the crosshair cvar. 

Which just reminded me. There are 25 possibilities, not 24. Because 0 is typically the axe (weapon 1). Makes Quoth Plasma gun weapon #25 (24th bit possibility) and Quoth sword weapon #13.

/Add to the model name thing ... hipnotic or rogue uses same model for a few weapons doesn't it? Like lava nails gun is same as nail gun, but different skin? Another possible example of how might be more confusing to use weapon model name -- if that is what you meant ... and might not have been. 

qc can't change the viewmodel's skin. so they're different models if they have different skins.

the exception being .viewmodelforclient, but your engine doesn't support that... yet? 

Ok, Mark V ...

crosshair 0 (none)
crosshair 1 (Quake +)
crosshair 2 (dot)

That's it. I was briefly going to change to implement to number system like DarkPlaces.

Then I thought it about some more, and decided to tie it to the weapon number instead. Beats passing around "stuffcmd crosshair 1" -- I hate stuffcmd.

Mark V crosshair remains simple system .. crosshair 0, crosshair 1 (+), crosshair 2 (dot) are only possibilities.

But if a mod contains any weapon crosshairs (scanned on gamedir initialize), it will display the weapon crosshair unless user sets scr_weapon_crosshair 0 to override. 

No extensions and still pure Quake at the moment.

At a future unknown time, I anticipate making another run at acquiring more Spiked Quakespasm's features. 

also, STAT_ACTIVEWEAPON is sent as a byte in vanilla quake, and is thus normally limited to 9 different values, only 8 of which might be present in vanilla.
but that doesn't mean that they might be set on the server anyway, or that you'll never have more than one bit set.
hacking it to support more weapons is one of the first things that many mods need to achieve. you're better off using STAT_WEAPON.
unless you're making a new addition for ezquake anyway. other engines should avoid those hacks like the plague, but its too late for poor ezquake. 

2nd reason I implemented the per weapon crosshair system instead.

I very well know some people will end up making per model crosshairs for certain mods because now it requires zero QuakeC support.

You could just make a crosshair for the Drake crossbow in Something Wicked and name it appropriately and do it in 30 seconds or so. 

STAT_WEAPON

Hmmm ... looked. I can't do that.

It's a model index. cl.model_precache[cl.stats[STAT_WEAPON]]

A gun model index might be 23 or 47 depending on the precache order, as I understand it. I mean "player.mdl" and "eyes.mdl" --- if I recall are guaranteed to be the first 2 precaches (if I recall correctly, which is no sure thing).

So 1 and 2 sure can't be weapons, if I am correct above. 

(Haha ... I wish I could unpost that after re-reading ... sigh) 

(Now I wish I could unpost my wish to unpost, because I think I'm correct on 2nd re-read). 

Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) ..

Stencil is done.

I suspect that depth-splitting problems are due to differences in how GL and D3D handle the depth range state. In D3D depth range and the viewport are part of the same state. In GL they're separate states. The current wrapper code just assumes a depth range of 0 to 1 when setting the viewport, so therefore viewport will overwrite depth range.

Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up. 

Stencil is done.

Very nice!

Fifth: Mark V already split screen

@mh ... fifth is in, in fact, correct ... haha.

video

I literally only need multiple controller support. I'm just pointing that out for clarity. Not trying to get you to change your mind or anything. Just wrapping up unfinished loose end from yesterday. 

Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up.

Ah ... I see. No wonder I couldn't get it to work.