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. 

that sounds right for brush-models, but what about static mesh models such as ase, md3, md6 or whatever models quakespasm is using? pretty sure it only uses one lightmap per polygroup or per shader or something along those lines 

models are lit using the value on the lightmap below its origin, or something to that effect. so a large piece of terrain as a mdl would look odd.

you could export it to obj then use a tool maintained by khreathor called obj2map.

bal has used it with success in his xmasjam2017 map. theres also an instance of it in otps jam9 map.

obj2map + phong can create some really nice looking terrain. 

Quake engines these days are very much focused on the look and feel of the original game but with as much quality/fidelity as possible. Replacement content, etc is of considerably lower importance than the original look and feel being as high quality as possible. If you want replacement content then this site is not going to be so helpful. "Pimp my Quake" doesn't really live here. 

Lightmapped terrain can mostly be done using _phong in ericw's light tool when compiling the map. That should smooth it out for you. Also the _dirt setting can add something similar to SSAO baked into the lightmap. 

i think you are describing vertex lit models muk? lightmap should behave differently. you can usually specify the lighting type in the shader it uses.

also if i recall, there might be a key like _origin which allows you to light the model in one place and let it spawn in another?

yeah i know there are quake-purists don't want to change the look of anything, but the water was never meant to be transparent, no colored lights were meant to be had here, and etc. where do we draw that line? is it too much to ask for some quality lightmaps and models? if we aren't using original bsp file or texture wads why do we have to stay with original alias mdl models? how have i overstepped the line here mh? :) 

No need to be sensitive about overstepping lines. mh is merely pointing out the preferences of many of the mappers here. There are plenty of exceptions. No one is stopping you from using features you want if they actually are supported. You just might be limiting your audience as engines like QS and Mark V are slow to adopt new features by circumstance or design.

In other words: you do you.