I did say you were a quality beta-tester. ;-)

At some point in the future I will refine the namemaker to commit the change "all at once", but it is better than the old system of committing the name "all at once" and having to choose "Accept" and accidentally hitting ESC and losing the name you spent a few minutes making. It's always been on the todo list to make that less spammy. 

I don't suppose you could give me some kind of test build that would spit out some error messages when it crashes (or save it to a file)? Because it crashes a lot! Well, tonight it seemed that way.... But sometimes it goes for quite a while without crashing, seeming to run just fine. It seems to like to crash right when a map first loads, after exiting the previous map. Perhaps some maps seem to trigger it more than others, like e3m2 seems mighty prone to crashing.

Sometimes it just exits, and other times I'll get a Windows error box asking if I want to report it... and I can check more details about that, but it's mostly incomprehensible gobbeldygook.

It'd also be nice to figure out why the GL version crashes right away too... 

Well, we have back to the old catch-22.

I don't have time to commit to engine development now (engine development is extremely time consuming), nor will I have that kind of time in the near future either.

Maybe some time in the 2nd half of 2017 I will.

This engine is in beta, and is not being actively developed at the present time.

It's not the first big gap of non-development of the engine either.

Quakespasm is a stable release. There's also Qrack and such as options.

You might try FTE, it's pretty damn nice.

http://triptohell.info/moodles/win32/fteqw.exe

You can tell Spike that "nqconnect quake.shmack.net" isn't working in this build I linked :(

On 2nd thought, nevermind. I forgot you have an Intel 845, FTE is pretty big on the shaders and such, althought it does have a Direct3D version too.

http://triptohell.info/moodles/win32/fted3dqw.exe

What would Spike say? "Your mileage may vary" ;-) 

You can tell Spike that "nqconnect quake.shmack.net" isn't working in this build I linked :(
What would Spike say? "Your mileage may vary" ;-)
I would also say 'works for me'...
(I actually bothered to test that just now!)

(also, you can drop the 'nq' from 'nqconnect' if you want to explicitly specify the port, hurrah for nq+qw using different default ports! or just use the server browser, but whatever)
(also that first build contains both gl+d3d9 renderers, you can switch between them in the menus, and yes with basic settings it should still work without glsl, but certain features obviously will not). 

Sorry, I have 10 copies of FTE in my Quake folder. I blew it, the "fteqw.exe" in my folder is out of date and quite old.

@gunter: FTE supports external textures and if you like options, compared to FTE, Qrack doesn't even have any options.

The number of features FTE has is off the charts.

And should have almost every possible feature you have ever seen. 

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