If you have any requests for features to add to it, now is a good time.

1) Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) .. Despite not having stencil, in theory mirrors should work in DX8 (without stencil, so glitches particular for the sky), but the wrapper hates me when I try and it doesn't work -- probably fighting an optimization.

2) 8x multitexture (which was easy, even for me), GL_TEXTURE_MATRIX (which I have zero chance of doing myself). "Combine".

3) The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one. 

Mirror func_illusionary doesn't work for me in the latest release as well. I should have mentioned that these are AD func_illusionary, though I doubt they have any difference with the regular ones. I tryied both every side mirror texture brush and one face with with mirror texture and the rest covered by skip texture. Neither of them work.
I'll try to do that in vanilla quake and let you know if it works. 

No obligation and separate issue - but you've written controller support before and no one else does Microsoft Direct X type of coding on your level ... and XInput is probably similar ...

I've looked at the XInput tutorials from Microsoft and my head about exploded all the monotonous steps involved and not necessarily even understanding what is going on for sure.

Multiple controller support (hell even single controller) where each controller can be read separately once per frame.

-----
No obligation, but since that kind of thing falls in your wheelhouse, I thought I'd bring the topic up as an example of something nigh impossible for me, but that falls into one of your primary strengths categories. 

Haven't updated the version yet, got to audit the code, etc. I'll do I "New Version" kind of post after I update it. Might be 2 hours. 

I see. I've even made a special test map for it. Can upload it for you for easy testing. 

Exactly! Yeah, everyone's beta testing and the level of detail has been incredible. Best experience as an engine coder ever.

And your unique perspective as an active QuakeC coder running a server has been an invaluable contribution.

Very nice that everyone has been bringing some unique perspective to the table. 

Yes, do that! 

http://www.quaketastic.com/files/test_mirror.zip 

...XInput is probably similar...

It's not unfortunately; XInput is actually very different.

I'm not certain what tutorials you've looked at, but IIRC XInput is just 10 or so lines to initialize, then another 5 or so to read the input. Everything else is translating input data from XInput format to Quake format (i.e. button mapping, etc).

Quake's joystick code is NOT DirectInput - ignore what it says in the comments in in_win.c; it's NOT DirectInput, it's actually a totally different Windows multimedia controller API. DirectInput joystick code looks a little like the DirectInput mouse code.

I wouldn't touch multiple controller support with a 10 foot pole. You need support for multiple clients first, and that's not a light undertaking. I know you're getting requests for splitscreen, but it's not something you can just easily patch in. I think your time is better spent elsewhere. 

It's all good. I thought I'd ask.

(@fifth: eta = very murky. I will promise that it will happen at some point. Maybe spring. It's important to me.)

/Yeah, I know joystick in Quake isn't DirectInput but multimedia. 

The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one.

Done.

I just need to sanity-check my bottom-left-is-origin to top-left-is-origin conversion, but otherwise - done.

An interesting FitzQuake bug arose while doing this, that's specific to a GL vs D3D difference.

In GL the current viewport doesn't affect glClear calls.

In D3D the current viewport does affect IDirect3DDevice9::Clear calls.

So in other words, in D3D the clear is bounded to the viewport dimensions.

This came up because FQ sets a smaller viewport to draw the warp images, but doesn't unset it before clearing; that small viewport is therefore the only cleared region. A "GL_SetCanvas (CANVAS_DEFAULT)" was needed in R_Clear to work around this. You could probably also put it in R_UpdateWarpTextures.

This wouldn't affect D3D10+ where the clear is done directly on a render target view, and I have no idea if it affects D3D8-. 

Odd what MH is saying, you had a video with multiple clients and splitscreen?

I don't have much choice but to wait... us non-coder guys are at the mercy of whatever you guys decide tbh. :P 

pulsar - this doesn't have func_illusionary mirrors. I'm putting that in separate 1012 build in case I messed up something ...

Build 1011 - Windows only GL|DX8|WinQuake

Everything except func_illusionary mirrors, in case func_illusionary mirrors explode something.

@fifth - I multitask extremely poorly. Can't get into deep discussion with MH about that without jeopardizing what I'm doing now. If I mess up 1 line of code ... you get the point. 

I also multitask poorly but am less disciplined about it, so I'm heavily dependent on people just backing off. :) 

Yeah, ...

This func_illusionary mirrors thing is cool, but has several points of modification. Don't want to unleash an exploding build.

/Ok .. concentration time ... 

Implemented WGL_EXT_swap_control - vsync no longer needs a mode change and works perfectly. 

Hah... it's cool guys, I'm probably one of the few people in the community that is even bothered about that stuff.

If I had it my way every classic 90's shooter with multiplayer would have splitscreen in it ;) 

Do you have any plans to allow for a custom crosshair graphic when crosshair = 2? 

So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist. 

@pulsar - carry on knowing the feature will exist in a few hours ;-)

I'm slowboating a little because I noticed some scenarios I didn't consider and uncovered what might explain why all my attempts at adding alpha masked textures in the software renderer failed while looking through the mirror code, which doesn't matter right now but has me slightly annoyed at myself.

So I'm walking through the several pieces to make sure I didn't make any mistakes. 

Already supported for crosshair 1, but I sense you may know that since you said crosshair 2.

Crosshair 1 is gfx/crosshairs/default.tga, which I am thinking is the same as DarkPlaces, but I can't really remember and I know DarkPlaces supports many crosshairs.

I never anticipated a reason that someone would want to substitute for the dot crosshair, but I am guessing you have a scenario in mind like an alternate gun crosshair or something?

/If you have a good scenario, I'll put it the eventual to-do list because I suspect even 2 crosshairs would not suffice. As soon I get pulsar func_illusionary mirrors ironed out, Mark V version 1.1 is wrapped and I plan on taking a break for a few weeks (I'm kinda burnt out). 

So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist.

Could you identify which ones? I thought I got them all, but maybe not? 

Is it just a 2nd crosshair for a gun?

If you tell me what DarkPlaces expects the replacement texture name to be, I'll see if I can add an alternate crosshair 2 to version 1.1

And I'll change the dot crosshair to be crosshair -1 (or something). 

Like version 1.1 is the one I'm wrapping up now. 

#274 above -- what should be blue particle splashes sometimes come out as orange sparks (watch the splash.dem in the zip I linked to).

Even when they are not sparks, the blue QMB particles just appear then vanish without moving outward, as they do with QMB disabled.


The other issue wasn't really about particles, but about how an effect trail thinks it started where the last one ended if you are near that position; screenshots in #414 above. I found this quirk also happens with the rocket launcher trail, but it's faster moving and harder to reproduce. Try shooting a wall (like the one in the position of the screenshots), then move next to the wall and fire your next rocket, with the point of impact of the previous rocket still in your view. The rocket trail will originate from the previous impact point. Same with the trails from lava balls and knight spikes.