Oh my... yes, FTE certainly does seem to have a ton of options. And the GL version runs just fine for me.

At the "nice" preset, I get 70 FPS, but at the "real-time" one I get like 4 FPS -- it may be one of the effects like that oldwater thing like in Quakespasm, but I don't know the setting to toggle it in FTE.

Is there lots of documentation about all the console variables so I can test stuff? Or I guess I'll have to go in and see what all the menu settings do....

The MP3 music seems to start up without delay... though it doesn't seem like it's playing the same tracks. hmm.

I will play around with this and see if I can get it set up how I like. I could sure use some exhaustive documentation! *searches around FTE site* 

There's a wiki for it that has some information.

http://fte.triptohell.info/wiki/index.php/Main_Page 

Setting my Contrast really high makes most things look really good -- the colors are vibrant and the walls aren't all bland. And it allows me to use a lower Gamma setting.

However, any fullbright textures become completely crunched and actually lose their contrast -- they just appear as one (way too bright) color, mostly, except for in the most contrasting areas (for example, torches).

gl_fullbrights 0 fixes the problem, making the torches (and any other fulbrights) again look nice even with high contrast, but of course that turns off the neat fullbright effect.

I already have both gl_overbright settings at 0

So, to keep the fullbrights from looking nasty, I have to crank the Gamma up higher to make things bright enough, but that tends to make things look a bit washed out and bland...


I saw above you said, "at some point I'll try to implement a sneaky tactic of shoving gamma+contrast into the textures (and hope it looks right). But that's for the future. "

Was that implemented? If so, the easy fix would seem to be to NOT have contrast affect any fullbright textures. Then everything would look good. I don't know if it would otherwise be possible to have "contrast" not affect fullbright textures if contrast is being controlled by hardware....



Also, just a thought (for potential future fixing): sure, the shadows are a hack, but a tweak that would improve them is to make sure they are not drawn at all if the distance to the model is greater than a certain amount. This would stop them from dancing around on surfaces way below where the model is actually standing (this is one of the common issues with the hacked shadows). 

I'll keep that in mind for future consideration.

Spike has caused the need for a Mark V update with ipv6 and (likely) ProQuake with ipv6, by making the code easily available and saving me a lot of time.

It'll need tested and one main concern I have is Windows XP.

Not sure when it will happen, but I expect it to be soon.

Because metlslime pointed out a quick way to solve your DirectX + model transparency thing, seems likely I can put that in there.

And if I am lucky, your clipboard interfering evil characters fix/scrub because that should be a 2 minute fix (probably a char codes 128-160 dequaked (-128) to control chars issues).

Can't say exactly when. I don't really have any time, but I've been sizing it up. 

Maybe sooner than I thought.

I just used Mark V to connect to "Quakespasm Spiked" R4 via ipv4 and then ipv6. 

ipv6 ain't hard to support, its just a different/bigger sockaddr structure with corresponding different address family value.
name resolution is a little more involved (in part because colons are used in ipv6 numeric addresses, which necessitates square-brackets where ports were normally specified with colons).
operating systems have annoying hybrid socket support defaults, so you need to be explicit about that in order to not conflict with ipv4 sockets (and xp doesn't support hybrid sockets at all, so I went with dual sockets with qss).
broadcast doesn't work with ipv6, its all multicast, so instead of flagging a socket as able to send broadcasts, you have to flag a socket as willing to receive multicast packets to various addresses.
that's about it, really. the rest is just datatypes and glue.

really though, right now ipv6 only gets you support for public addresses when servers are behind ipv4 cgnats (but with their own globally routable ipv6 address).
mobile phone versions of quake may need ipv6 (iiuc, apple mandate that ios apps support ipv6).
other than that, no non-mobile isp would dream of skipping ipv4 yet, making ipv6 support nice but in no way necessary.
single-socket-servers on the other hand... 

was added to quakespasm and it is a very good implementation, could this also be added to mark_v? 

Anything is possible in the 2nd half of 2017, but Mark V is not SDL based like Quakespasm, it isn't like it could use the existing code in any shape or form.

re: 360 controller

They don't make those anymore -- the xbox 360 controller died when the xbox 360 died.

They'll never manufacture them again. 

I'm sure you can get a second hand one. Personally when I need a gamepad on PC, I use a Dual Shock 2 with a Madrics Superbox 3 Pro - yeah, fancy name for a little plastic thing. Works good and I prefer the shape of PlayStation pads. 

Just another way of saying xinput support. That's the standard controller library that's replaced directinput on windows for the past few years, you'd be hard pressed to find a PC-compatible gamepad that didn't use it. Supporting the 360 pad is supporting gamepads in general, at least on Windows. 

90% of the work in implementing QS's controller support was stuff that is independent of the SDL2 gamepad api - Subjective stuff like deadzones, easing functions, choosing good defaults and playtesting them. Also making the menus usable with the controller. So this code could still be useful if you like how I did it.

SDL2's gamepad API was, I believe, largely a clone of whatever the modern windows API for gamepads is (Xinput?)

re: 360 controllers dead
true but I don't think this affects software much if at all. 

It would be great if you could include some kind of error logging in a new release, so that we could get some idea of why the GL version crashes instantly as soon as I try to load a map (it runs fine up top that point... in the console and menus).

And maybe also see why the DX version crashes intermittently....

Quakespasm, FTE, Qrack, etc., all work fine in GL for me. I really hope Mark V can be fixed to work in GL for me too. 

They have them at Newegg. I was just looking at it the other day. It's on sale for $30 with "free shipping". 

@ericw - I think your code is pretty tight and well written. Mark V doesn't do DirectInput or XInput, so would be hella lot of work for Mark V support. Definitely not part of a group of 4 small updates, each that don't take too much time.

@gunter - I don't have much time, we'll see. I private suspect your graphics card can't do anything except 16-bit color, are you actually able to use, say, Qrack or Quakespasm in 32 bit mode?

@others - All I am saying is that my interest in a discontinued controller limited to pawn shops, ebay, second hand sales is "meh".

If someone knows of a worthy controller that actually has a future ... 

xinput is the future (for now). The specific type/brand of controller using xinput shouldn't matter much. 

I don't understand, seems like un-needed hostility? Maybe I'm misinterpreting your tone though.

You can still get 360 pads brand new here in Europe, they're marketed as a 360/PC controller.

They're pretty much THE standard controller for playing games on PC, even more than the xbone, PS4 or any number of PC-Specific pad.

You could have just said "it's too much work, sorry" or "it's not a priority". 

Supporting xinput, as far as I know, will allow you to support basically every logitech controller for the past few years, the Xbox One controllers, and the generally established hacks for the DS4. So, basically all the controllers.

Speaking of hacks; aside from the tricks people are pulling to get the DS4 to work on PC, there are also plenty of wrappers out there that will make a DirectInput controller work like an xinput one for most purposes, so there's not much need to support an (actually dead) second system of controller.

Honestly though... how necessary is controller support? Does anyone here, or anyone that someone here knows, actually use it in QS? I certainly don't, and I can't say I see the appeal either... 

Isn't it pretty much the standard for PC controllers because of support built into Windows?

http://www.newegg.com/Product/Product.aspx?Item=N82E16826105438&ignorebbr=1 

The only Quake engine that seems to report the BPP in the console is Quakespasm, and it tells me "24-bit" when I try set it to 32 bpp (either in the menu or by command line).

Of course it reports "16-bit" when I change to that....


How would I verify that any other engine is running in any certain bpp?

Well, I can do more than 16 bpp in any case... (what is it, the stone age? :) 

when I just want to sit in front of the TV playing games I whack on some Quake.

I know KB+M is the best way to play but I originally used to play the game keyboard only when I first got the game... :P 

@gunter - that clears up possible causes of the issue.

@fifth/@rick - I'm not against gamepad support.

As long as the controller support code works with current/future devices (@johhny). 

 

I don't claim to keep up with consoles ...

Does the Quakespasm controller support work with an XBox One Controller? 

According to this reddit post the xbox one controller should work with any game that uses XInput, which SDL2 is wrapping, so it should work in QS. I don't know if anyone has tested it though.

Anything listed here should work out of the box with qs, there is also a community mapping file for more support. 

Ok, that clears up things quite a bit -- it supports a wide array of devices.

When I hear "xbox 360 controller" immediately I think "But the XBox One came out back in 2013?"