sprite lighting differences - these are just drawn fullbright, so I don't see how there can be any difference. that goes for particles too, but to a lesser extent obviously. overbrights are not normally used on either of these, so no idea. comparing screenshots show the sprites at the same lighting level. maybe its just your imagination on account of dlight colours?

These shots show what I mean - all particles are brighter and sprites get their colours blown out.

https://i.imgur.com/XFRHlYv.png
https://i.imgur.com/JJOlj7m.png
https://i.imgur.com/qqJKqAm.png

quakespasm has double-brightness models (seriuosly, I check relative to glquake)

glquake has dull models. FitzQuake (and descendents) changed the model lighting to resemble the original software quake. However.....

https://i.imgur.com/LYXwYIH.png

The above is really interesting - it shows QS is pretty close to vanilla software quake (but is actually a little bit too bright), but FTE is a bit too dark in comparison and the models do disappear into the scenery. I don't mind it too much, but some custom models that are designed with QS in mind (like some of the AD models, e.g. pickup items) tend to disappear a bit sometimes.

But what about from the back?

https://i.imgur.com/dE5NhAm.png

FTE is very close now (in accordance to what you said about the models only being too dark from certain angles). QS is like the front shot - close but actually a little bit too bright.

I'll answer the rest of your points tomorrow (I have to go bed now) but I still can't get the dynamic lights non-orange, or the controller to work (which I'm sure is more my fault than yours) 

http://celephais.net/board/view_thread.php?id=60133&start=35&end=43

It would appear that Fitzquake, and therefore Quakespasm, (in its emulation of the original Winquake), ended up making overbright models slightly too bright than intended. 

WinQuake uses a variable amount of ambient lighting, plus a fixed amount of directional lighting.

The amount of directional lighting is very small, just enough to give the model some depth without evidencing the direction of the light. They made it this subtle because since the lightmaps doesn't store any angles, there was no quick way to rotate the directional lighting of the models towards the origin of the lights.

Plus, WinQuake also ensures a minimum ambient light value of 20 to viewmodels only. I don't remember if this minimum value is clamped or added, though. 

There's something on the FTE website that my ISP doesn't like. I have to use a proxy to even visit. It gets flagged as dangerous from Virgin. 

dlight colours - use r_dynamic 2

Doesn't seem to make any difference - it's still orange. All I'm talking about is an option of reverting to the white light of vanilla quake. Minor quibble, but the orange just feels a bit out of place in classic maps.

underwater sound - switch audio driver to alsa or directsound, or anything other than openal

Thanks - setting it to directsound via the menu seemed to fix that. Is there a command I can put in my config file for that?

in_xinput 1;in_restart

Didn't know about that, but in any case I can't get it to work with my XBox 360 controller. All that does is make the screen vibrate crazily and lock my view to the floor.

menu / fonts - I may talk about that another time, it's not terribly important. 

Tried to use delete to remove binds but it hard crashes to desktop.

Why doesn't FTE use an external .cfg file? I want to know what I am editing.

I also get the same problem as Kinn. My view shakes and locks to the floor. Control input is broken as far as I can tell. When I try to rebind in the menu it doesn't allow it. 

DPAD = movement up/down/left/right

Left Stick =
moving left or right throws the view down, if you push up or down very lightly you can turn left or right.

Right Stick = pulling back moves diagonal forward, pushing forward moves diagonal back. RS also controls swim up/down respectively.


Right Trigger = Stops the view shaking

Nothing is bound to shoot, jump, change weapon, view center (centerview command is also not recognised despite being a default game command).


Yeahhhhhh.... Maybe steal EricW's controller input and allow binding for separate pads in the rebind menu? 

Why doesn't FTE use an external .cfg file

I just discover FTE dumps a ton of cfg stuff in C:\Users\[you]\Documents\My Games\FTE QuakeWorld

instead of the traditional place where you installed your quake 

That last one is particularly egregious. I hate it when software thinks it's ok to hide data in other folders.

Does FTE support fence textures?
Does FTE support Orl maps?
Does FTE support AD Sepulchre and Swampy?
Does FTE have an option to use standard Quake physics instead of Quakeworld physics?

I thought QS and this QSS were the only engines that supported AD fully and the Orl megamaps? 

I dislike that behavior that too. maybe -nohome or -disablehomedir 0 will do the trick. 

 

Hopefully the controller feedback can be taken on-board. Splitscreen is one of those things that I have been wanting to use for years.

I just have no idea how this is supposed to work with pads in FTE, what am I doing wrong here?
If I am not doing anything wrong then how can it be fixed? 

if you want to use fte's features then use fte.
if you don't do so then you're showing that it doesn't mean much to you.
[...]
and its actually kinda rude for people to keep asking for only a fraction of my stuff.

I really know that feeling.

I was really happy when QBism forked Makaqu 1.3 into Super8, and actively worked on it. That kind of thing is very rare to happen.

More often than not, other coders just looked at the engine from the surface, and only copied the features that were too evident to miss. There are tons of little improvements that are too subtle to be noticed without analyzing the code or which belongs to parts of the engine that most people don't care enough to notice.

And then we get people trying to solve things which we had already solved in our engines, but they didn't know because the only thing they cared about in our engines was just a couple of features.

After years of seeing this happen, I've realized that there was no reason to try to code my improvements in a minimalistic way to ensure ease of portability to other engines, because the truth is that almost no one will ever care.

When the Quake engine source code was released, everyone was curious to know how many kinds of cutting-edge features people could add to it, to make it not seem old in comparison to more modern games. Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

There isn't much of an audience for technological innovations in Quake anymore. Rather than getting excited by them, people will usually get annoyed.

menus - not clunky enough? too small? or what? mouse support! zomg! or just so cluttered that noone has a clue what's actually in there... if it helps I hate designing UIs.

Well-designed UIs can have lots of options without feeling cluttered. The key is to figure out how to better categorize the information and organize its flow so the user don't get lost.

But yeah, designing UIs is an art form in itself, which requires lots of boring practice. 

Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

That's an excellent observation and I think it's spot on. The community has transitioned from adding flashy stuff to Quake to wanting original flavor Quake - but in larger doses. Huge maps, fast rendering, quicker compiling, and so on, while still maintaining the software rendered look that makes Quake what it is.

I guess it's somewhat like car enthusiasts who covet classic cars. Eventually things become old enough that you get people who want the original again. 

It feels like a natural progression.

The Commodore 64 scene progressed in the same way. Initially there were add-on boards and such that added speed and memory to the base computer but, over time, demo scene coders transitioned back to the base machine and starting extracting as much power as they could from it.

There's stuff being done today on that machine that I never would have guessed possible. 

@FifthElephant, Kinn
I had PrimalLove take a look at the xinput stuff (I don't have a controller myself, hence the prior b0rkedness). Hopefully it should be more acceptable now.
Note that you may still need to do 'cvarreset joy*' if any previous settings got saved to a config. Be sure to use a test release (ie: 5197+).

@Kinn
I found a bug in the defaultmodel.glsl code where it was computing a value and then discarding it, resulting in extra darkness, so that should be fixed now. It should be much closer to sw rendering (especially with r_softwarebanding enabled).

@Kinn
The double-brightness particles+sprites I couldn't reproduce.
the r_dynamic 2 setting not working is only a thing with the 'stable' build from 6 months ago - give the testing build a go instead, where its actually supported.




In other news (that's actually on topic), I have a QSS build that can run CSQC.
It has a number of intentional limitations that make it simpler to implement, but it should be ideal for custom huds/scoreboards/intermission/menus (read: 2d-only CSQC_DrawHud entry point, instead of CSQC_UpdateView with all its 3d nonsense).
When I get around to releasing it, I'll include an example hud, with some extra code to deal with DP's different expectations (FTE will be promiscuous).
For now though, there's still a number of issues that I need to resolve, primarily in the input handling stuff (for custom menus - quakespasm's mouse logic is not being too friendly). The current issue is how/whether to deal with fte's splitscreen feature - not that this is really a Quakespasm issue of course, I just want to avoid shooting myself in the foot as it were.
Probably nothing will come of it due to whatever, but without hope all we have is despair, or something *starts mumbling*. 

Cheers, I've just tried the latest FTE test build and the models look identical to WinQuake now (I even did a super-pedantic screenshot test). Sprites and particles also appear correct too. So, right now, I can make FTE look closer to WinQuake than any other hardware-powered engine I think!

I'll have a look at the controller stuff when I get home. 

Even software rendered engine that added flashy stuff to be on hardware engine level get ignored in the end. super 8, engoo, makaqu all dead 

 

you mentioned once that CSQC for custom HUDs could be coming for QSS - is this still planned?
I've committed what I have to github. It should mostly work (if you compile it yourself), but its not perfect.

For it to be useful, it needs a clean example/base mod that people can use to do cool stuff without needing to figure it all out from scratch. I don't plan on releasing updated engine binaries only once that's actually done, because I don't see any real point without and it would risk people complaining about obvious already-fixed bugs.
Really it just needs polish. Lots of it. Hence why I haven't bothered to do anything with it for a while now. 

Cheers for the info. I'll have a tinker at some point. 

Get it from here:
http://fte.triptohell.info/moodles/qss/
(linux+mac users will need to compile their own).

This release adds support for a cut-down version of CSQC that allows for mod-created huds (but not fancy 3d stuff). Requires a compatible hud however.



Boring technical junk:
I uploaded a preliminary(read: probably buggy) qc dev-kit to that site too. Inside you can find a simplecsqc/src/csprogs_simple.src file.
Compile that with fteqcc (set up a file association or something) and you'll get a csprogs.dat that'll be understood by QSS+FTE+DP (cl_sbar 0 for a qw hud, or 2 for n64quake style, as an easy way to see that its actually doing something new). You can edit the csqc_hud_vanilla.qc file to do your own mod-specific things.
You can use clientstat from ssqc to register custom stats (starting from slot 32) in order to provide mod-specific fields to your csqc that can then be read with getstatf. You'll probably want to share your constants between both modules... Magic numbers are evil.
(I also knocked up some other files to provide hipnotic/rogue huds too. I guess that might be useful to quoth perhaps but probably noone else will care.)
Alternatively, you can just directly add the csqc_hud_vanilla.qc to the end of your ssqc src. Doing so will not give you a working hud in DP (so I don't recommend this), but will work in QSS+FTE (unless there's an explicit csprogs.dat, which takes precedence). Don't expect to be able to directly poke ssqc data though, it might be the same .dat but its a different qcvm.

Constructive feedback welcome. 

I will give this a rumble as soon as I can.

Just want to say thanks, this really opens up the possibilities. 

Hi, I'm afraid I'm getting a little crashette when I load up AD in this new build and fire the shotgun. I assume particle related? 

It's great to see this updated again. I'm prepping a video on source ports so I will add this to the mix. Questions tho. Is QSS a side project or is it starting to take over FTE? I'd just like to know a bit more history and have more context so I can communicate that in the video. And BTW the video is a few weeks away but on the to-do list.