Darkplaces has the capability to look exactly like quakespasm, too.

Don't be daft. Quake engines shouldn't need user-made particle fonts or shaders to look like Quake. 

Quake engines shouldn't need user-made particle fonts or shaders to look like Quake.

I agree with that 100%. Darkplaces should look vanilla out of the box (still puzzled as to why it doesn't). Fortunately, that vanilla look is five minutes of tweaking away. The 'misinformation' that I was referring to was that Darklpaces inherently looks like this. 

would you be interested in making a package consisting of the necessary config settings, modified particle.tga files etc. etc. that people can just download to have DP up and running in a non-eye-rapingly-offensive way? 

because looking at effectinfo.txt - that is not a 5 minute fix unless you know exactly what you are doing, and the casual player most certainly will not. 

good idea, putting that on my list. I just did a little test and it turns out I was wrong, you don't need to touch effectinfo.txt. Just drop an any color/size image called particlefont.tga (i used 4x4, black) into id1/particles. However, I would mess around with effectinfo just to get it a little more "quakey". 

 

Cheers killpixel, yeah a "DP-no-ass" package that can be slapped in the title post of the engines thread would be pretty useful.

Out of interest does DP run ad_sepulcher? Last I checked DP hasn't been updated since 2014 :p 

DP has had development since then and has automated builds posted to https://icculus.org/twilight/darkplaces/files/?C=M;O=D

(doubt it can do sepulcher tho)

For me, because DP also changes some behaviors of lighting and physics, it doesn't seem worth fiddling with for "normal" Quake stuff (i.e. not taking advantage of DP-specific features). 

@Kinn - DP-no-ass. I imagine that would be painful. But yeah, I would have liked such a mod before QS came around.

@Johnny Law - Yeah, same here. MarkV and Quakespasm fulfill my quake needs.

anyway, I won't clutter this thread with DP related suff anymore (apologies). 

DP has had development since then

Good to know. The latest Windows 10 update has completely trashed mouse input in the 2014 DP build (same way it trashed mouse input in earlier versions of QS, but the latest QS has that fixed), so if the latest DP has fixed that, that's welcome.

But yeah, as a player, I can't really think of a reason why I should use anything other than Quakespasm. It feels right, it looks right, has proper controller support, and runs cooler on my laptop than any other engine by far - seriously, the fan doesn't even come on ever with QS, whereas it's blowing like a jet engine with every other engine I've tried - what's with that? 

- A digs map.
- Release one or two maps myself.
- Halo Forerunner-themed mapjam
- Silent Hill Otherworld-themed mapjam
- uhhhh.... 

More solo releases. From myself or others.

Shorter jams with stronger themes(not that theyve been lacking lately). More than "use this texture set"

Id love to see people talk more openly about their design process. I included a changelog in my xmasjam entry and this is something Ill continue to do and then some. 

Isn't the other issue people have with using DP the fact that it's pretty incompatible? Like, aren't there a bunch of cvars you need to change to get it to behave sorta like regular Quake, physics wise?

Something I want to do in 2018 is release a map that I'm proud of the gameplay for, and not just the visuals. Preferably as a solo release. 

An improved model format. I don't want fancy features, just better (preferably floating point) accuracy on both vertices and texture coords. Normals can be easily reconstructed if needed (the original code in modelgen.c is a good base to work from).

What I'm talking about here is the equivalent of a BSP2 for MDLs. BSP2 had no fancy-dan features meaning it was easy to implement, meaning it actually *was* implemented, meaning it succeeded. Adding extra features - "can we have skeletal animation/multipart models/detachable limbs/32-bit skins/etc" - just increases the complexity of implementing. There are already plenty other formats that support those features - go implement one of those instead. What I'm talking about is a format that does what MDL does, does no more than what MDL does, but with better accuracy and raised limits. 

Yea for me this is why MD3 would be a good one or IQM which has bone support! As for some new format be careful because that can get tricky with supporting proper exporters for various art authoring tools. Something that can convert an FBX file to this new format would be a good middleground since tons of software can export to FBX. 

#24 Retroquad 1.0

Definitely not happening in 2018.

#26 Lightmaps on liquids

I've tried encouraging other engine coders to implement this in their engines, I've showed how to properly detect if a map was compiled with lit liquids, EricW coded full support for lit liquids in his compilers, but other engine coders were against it.

Mappers were also against it, by shutting down my suggestion of enabling lit liquids by default in EricW's compilers because not all engines supports it, despite there being no side effects in engines that doesn't support it. Interestingly, not all engines supports translucent water either, but nobody complains about translucent water being enabled by default.

Darkplaces does support it, and FTEQW probably does too. What's funny is, even if someone maps for DP, they'll never casually find out that DP does support lit liquids, because the map compilers won't lit the liquids by default.

If lit liquids were enabled by default, we'd have dozens of new maps using it already, and people would start to figure out how to take advantage of it in their maps.

So, it's not going to happen. People are against it. 

No, please. Give me lit water. My maps look like ass without it. 

is your engine going to be released in 2018? 

Well he calls it retroquad... so looks like a nope for 2018 release. 

Yes, that's what I'm thinking too. Easy change to the engines. Easy change to the mdl exporters. Just mdl with better precision. 

Engine stuff:

I guess weather supported across the engines. An implementation where you can just stick a weather entity in a map and tell it to either rain or snow! QSS works really well of course!

Another vote for fog brushes.

Maps:

I'd also like to see less huge hub-like maps and more dense and original designs. Small episodes or just plain ole medium sized individual maps would be a fun change of pace. I also agree with some people saying about more focused jams with strong themes vs texture usage or one gimmick.

Themes:

Hmm I don't know, the fun part about that is mappers constantly come out with crazy cool ideas. So I suppose let's just keep doing that! I know I would like to release at least one episode myself personally. The Episode Jam will be a nice early year treat I hope! ;O 

I'd love to see an engine/mod support parenting or 3D skyboxes, ideally both.
Not exactly 3d skyboxes but one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense. 

There's always a stick in the mud somewhere, especially when it comes to engine or mod coding, it seems.

I hope we do get to see lit water in 2018, especially since on paper a lot of the issues have been sorted out. Perhaps we'll see it in a QS fork, or perhaps even in QS itself...

I wonder how much of the pushback against it is because it's supported by DP and no one wants to be on the same side of an issue as DP ;p 

...one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes...

I'd love to see that. I brought it up during RMQ development but it was shot down at the time. The idea I had was that you could have 2 or 3 layers of skyboxes and blend between them, so you might have a rotating "clouds" layer and a static "scenery" layer, or whatever.