The entire community coalescing around a single engine is ultimately a good thing; there's still room for the maverick outliers, but so long as you do-what-Quakespasm-does you'll get support for pretty much anything released.

The obvious con is that the quirks and idiosyncracies of that single engine become enshrined as part of a standard. That can cause harm - e.g. FitzQuake and earlier versions of Quakespasm had very poor performance with dynamic lights. That can hold back content authors from using dynamic lights, and at one point led to the ridiculous situation where disabling multitexture was touted as a performance tweak.

Fortunately Quakespasm these days is really rather good. 

Regardless of the largely unfounded criticism for Arcane, it has done a lot to reignite interest in this game, arguably alongside some other big releases like Orl's Ter Shib and jam9. On the mapping side, Trenchbroom 2 and dumptruck's tutorials have done wonders in terms of drawing in new mappers. They even got community veterans to finally map after 20 years.

I don't know if the scene is better than ever because I don't know what it was like before. It still seems quite niche to me but it's also doing considerably better than most other classics out there. The number of mappers who turn everything that they touch to gold is still quite small. I'm worried that when they retire, there won't be many people to carry the torch. Many of them already seldom post here or elsewhere.

On the other hand, this has resulted in mappers whom I greatly admire being more accessible. I've gotten tons of advice and insights directly from mappers whom I aspire to match in skill even if only in the smallest capacity.

Targeting a single engine is not a good thing. There are still a bunch of source ports that are actively maintained, and the devs each have different goals. Some of those goals might align with more with specific users. Even if most people are using Quakespasm, there are still a great many who might prefer using Mark V, QSS, Qrack, FTE, and others. There should be some effort made towards supporting multiple ports to a reasonable extent, and there are more reasons in addition to users simply preferring the features of one port over another. 

 

 

AND TOOLS! 

A teleporter, who shows me how he played with a blurry screen in the earthquake in the nineties, threw me into the limelight with quadro-sound grenades and missed voreballs.

Uhm, my old 486 still does it, but I mean the surprise that such a comic strip film can mesmerize me like that.
What else would I like to improve? 

hey guys, been away for a while, not 20 years but a while.

never heard of Quakespasm, what's it do better than the other engines? and who is the whole community that's now using it? can you name some names?

qmaster mentioned tools, what tools are you guys using?

darkplaces and fte are my preferred engines, but fitz is still good for the classic look.

tenebrae was all set to be a great engine, I don't know why they quit developing that one or nobody picked up its source to continue it. 

Is practically Fitz v1.5. 

Tools::
==================
Mapping:
Trenchbroom level editor(fantastic)
JACK level editor (upgraded Worldcraft clone)
ericw's utils for compiking maps with cool lighting, {fence texture transparent support, water alpha, bsp2 oversized, the works

Code (QC):
fteqccgui.exe latest version with lots of great features, arrays, better checks for warnings, support for GIANT progs.dat, csqc support, etc.

Modeling:
Blender 3D with qmdl exporter
Preach's qmdl java applet for adding skins, Skingroups, framegroups, etc.

Textures:
Oh sorry, still stuck with Wally and Adquedit here.
Texmex is alright depending who you ask.
Gimp 2.10 if you like going back and forth a lot into Wally or Texmex and like to fight pallet conversions.

Sprites:
Fimg
Wally plus Adquedit

Lumps (e.g. colormaps, hud icons in gfx.wad):
Fimg
Adquedit 

Quakespasm is a continuation of Fitz that's been heavily adopted by the SP mapping community. Namely on this website but also Quaddicted, which has promoted it as their recommended engine over the past seven years. It has some new features, but it's primarily a faster, cleaner, cross-platfrom version of Fitz/GLQuake with increased limits.

Quakespasm-Spiked is awesome if you want an updated version of Fitz with enhanced networking, modding and mapping capabilities. 

Quakespasm = bog standards plus fence texture support, alpha on any entity, bsp2 map size support, fog, skyboxes, colored lighting.

QuakespasmSpiked (QSS) = Quakespasm plus awesome features Spike added plus support for high framerates above 72fps, e.g. for 144hz monitors.

MarkV = same as Quakespasm for the most part but with better HUD options, cool map and mod loading features, excellent coop support, mirrors

FTE = you know better than I. As far as I know it is DarkPlaces plus the stuff Quakespasm has and a few extra awesome things Spike came up with that I don't understand yet :P

DarkPlaces = cool graphics options. TERRIBLE WATER!! Buggy physics outside of standard hulls. Loads of mod features. 

If you want anyone to play your map, target Quakespasm, otherwise GLWT. 

the main reason is frogbot support, not sure why , but sometimes QS refuses to properly launch that mod

i like the MV fancy features, tool_ etc, qmb

the FOV adjusting feature 

cannot recall any significant release this year, other than sham1m1 

a concern of mine is that with quakespasm it means you have to use the BSP2 map format, and not FBSP or a Q3 or even newer format which has more features.

FBSP has higher res lightmaps and lightstyles support, maybe some other differences that i can't remember.

from mh:
The objective of BSP2 is to address some limits in the stock BSP29 format. -- BSP2 is not a radical revision of the format. You won't find RGB lightmaps, detail brushes, 32-bit textures
or any such major overhaul here. These are left for other already standardised ways of providing such
content.

i'm interested to know if detail hint and skip brushes can indeed be used for BSP2. also how to create these RGB lightmaps? i thought colored light was only done with rtlights. can q3 style bezier patchmesh be used? can high-res lightmaps be created for BSP2 which are as big as FBSP? are we talking 2k maps or 4k or ?

another benefit to FTE (and i believe also dp) is it supports IQM/IQE model format, i can't find any document saying if quakespasm supports it or not. 

Some excerpts from EricW Tools doc:


QBSP:

This version of qbsp supports detail brushes which are similar in concept to Quake 2’s detail brushes. They don’t seal the map (previous versions did).

...

SKIP
Any surfaces assigned a texture name of skip will be compiled into the bsp as invisible surfaces. Solid surfaces will still be solid (e.g. the play can’t walk or shoot through them) but they will not be drawn. Water, slime and lava surfaces can be made invisible using the texture names *waterskip, *slimeskip and *lavaskip respectively.

HINT
Hint surfaces cause a bsp split and portal to be generated the on the surface plane, after which they are removed from the final bsp - they are neither visible, nor structural. Strategic placement of hint surfaces can be used by a map author to optimise the PVS calculations so as to limit overdraw by the engine (see also: vis(1)).

Use a texture with the name hintskip on any surfaces of a hint brush which you don’t want to generate bsp splits or portals. All surfaces of a hint brush must use either the hint or hintskip texture name.

LIGHT:

"_color" "r g b"

Specify red(r), green(g) and blue(b) components for the colour of the light. RGB component values are between 0 and 255 (between 0 and 1 is also accepted). Default is white light ("255 255 255").

All of which are compatible with Quakespasm. 

Eh well, some of those things are possible with various engines, some aren't, some have been tried and don't look great in Quake-like content. I won't try to enumerate the details (muk has tackled some of that, and maybe someone else will also jump in), but a couple of general things I'll throw out into the thread:

For developers, if you're going to make a new game in 2018, a Quake1-based engine is unlikely to be the best choice.

For players who are specifically interested in playing Quake and Quake-like content, new features are not always needed. I'm not suggesting "no new features" is the right answer, but from a player's perspective it's not necessarily an issue when a Quake engine doesn't have a particular bolt-ons buzzword. 

the q1 standard for RGB lightmaps is .lit files, which most modern light tools can produce. These files can be used in conjunction with normal quake BSP files and also BSP2 files. 

the only stuff in your list that you *can't* do with bsp2, ericw tools, and quakespasm - is q3 bezier patches (which isn't really a big deal).

Higher res lightmaps we're trialed (.lit2) but I don't know if that's supported in the main quakespasm build, someone else has to answer that one. 

and it doesn't support a fancy model format yet. 

It's up to the mappers to decide whether they want to use the new features made possible in DP and FTE. In this community (i.e. the mappers based mainly in this forum) they tend not to. If the content is there, more widespread engine support will follow. The content isn't there though. 

...I think the main reason mappers don't want to target FTE/DP is because the players (who are basically also the mappers), don't want to play quake under FTE/DP for various pretty understandable reasons (don't like the physics, don't like all the aesthetic stuff it changes etc. etc.) 

thanks everyone for all the info. this doesn't look as restrictive as i first thought. i would not do a whole game, more like a little partial conversion.

so if you were to create a terrain made of mesh, is the collision handled well? is it computed via the vertices of a separate collision mesh?

how good would the light look on it? this is a main reason why large lightmaps are useful to me. since large models need more lightmap.

i'm also interested about animation support of the models for making animated map models or making new monsters.

are any of the engines going to support realtime radiosity / raytracing? graphic cards this year are going to bring this feature, and it will become the standard going forward in games i think. 

Quake creates one lightmap per face (atlassed into fewer, larger textures at map load), so a large terrain made of many faces does not need large lightmaps -- it will just use many small ones.

In terms of how good it will look, there have in the past been bugs with visible lightmap seams at the edges between too faces, especially with odd angles. Not sure if those are solved with modern versions of the tools. But when the system works, you will not see the seams.