All I know about darkplaces and being related to quakeworld is that it can connect to quakeworld servers. That being said, it must have the capability to use quakeworld prediction, but I don't know if it is a serverside setting or a client side setting.

Hi Pie
I seem to recall Spike did something similar with his FTE engine so that he can nconnect to netquake servers. I suspect there are many players who would like to see some opening up of these boundaries so your engine of choice could connect to any quake server regardless of whether it is a Netquake or Quakeworld box. It would be good to bring the 2 sides together too especially given the current player base. Personally I'd like to understand this "predecition" a little better as I don't like the thought of servers helping players hit their target (I'm not suggesting that is what QW does).


Hi UB,
Maybe if you talk nicely to Spike, our resident Quakeworld expert , he could find the time fill in some of the gaps here from a techical perspective.

Kind regards

Monty

Yeah Spike is a genius. I've just found an older thread where he answers most of my questions:

http://quakeone.com/forums/quake-tal...uakeworld.html

There is a quakeworld progs which stitches singleplayer and deathmatch together here:

http://zquake.sourceforge.net/eng/download.htm

However, whenever I attempt to run it, darkplaces ignores it. How do I force darkplaces into quakeworld mode? I tried: "sv_progs qwprogs.dat" but it crashes out. The error message suggests to me that it's expecting a standard progs.dat. I think what I am trying is not possible, as darkplaces is a netquake client which allows you to connect to a quakeworld server, but it doesn't support quakeworld in client mode.

For quake curators, there is a thread here which explains the physics differences between quakeworld and netquake:

QuakeWorld.nu - QW physics vs NQ physics: everything you ever wanted to know

I know very little about Darkplaces but I wonder if adding the -game [ProgsFolderName] command line flag might help?

Nope, tried that.

DP doesn't support qwprogs.dat
DP servers don't support the qw protocol.
Any qw support is strictly clientside.

Use FTE if you want a promiscuous engine.

Ahhh ok, well thanks for that. Judging by the performance of Xonotic, and the way they've done their physics in quakec, it seems that dial-up based optimisations might mean little in the grand scheme of things anyhow.

I keep looking at fteqw from a distance, but she isn't dressed the way I prefer. How is IQM support?

Do you have a list of features? I read somewhere that you can easily make a glsl type shader and attach it to a q3.shader. But without documentation it's really difficult to know what I can or can't do. It's hard enough with darkplaces - but there's a lot of info here on quakeone. Is there an equivalent to effectinfo.txt?

This tech demo looks very impressive - do you know if there is a .bsp/.map of it available? -:

https://www.youtube.com/watch?v=sgeexDlkb1A

DPP7 reimplements many of the things quakeworld does. The important things, anyway.
Once you have sequences and other stuff, anti-lag stuff isn't that hard to implement, basically just a log of positions. QW is a little more complex here because clients predict other players too, while dp predicts only the local player. This means you can get away with adding an array or so and implement it yourself. Its a little messy in that you have to move lots of ents around in order for traceline to function correctly, so the QW version where its built in (just add an extra traceline flag, or set a cvar to force it on all) is much easier to deal with (despite the actual logic being more complex).

The biggest thing from vanilla qw that dp lacks is multicast support. you can argue that only the worst case scenario is important, but I'd personally argue that its still wasteful, and rare for the worst case to actually be that extreeme.
DP also doesn't support userinfo, which is kinda annoying. You can work around it, sure, but the versatility of it is awesome for c2c stuff (like using rgb player colours instead of just 14 options).

IQM works fine in FTE. It uses glsl to animate etc. I recently fixed it up so it works with (wasteful) models exported by noesis where dp fails. This is more of a noesis issue than anything else of course, but its quite handy to converting various formats into something quake engines can use.

regarding particles, see FTE QuakeWorld / Code / [r4967] /trunk/engine/partcfgs/high.cfg
rename to something like quake/$gamedir/particles/foo.cfg, set r_particledesc foo, then load a map. for debugging, you can just keep execing it after editing (or just paste the updated effects into the console, but beware comments)
note that that particular line given is the start of the teleport effect, which contains an embedded shader with some embedded glsl. this does some weird screen ripple effect thing rather than actual particles.

the map in that video is just some TF map. its not interesting/modified.
'r_telestyle 3' will add that effect to teleporters. its really just a refraction+reflection shader (read: the altwater shader) with the fresnel term technically being broken (its in surface space instead of model space, read: up instead of side) resulting in it reflecting when you look directly into it (instead of using the refraction sample / looking through it).
you can find the various built-in glsl bits here: FTE QuakeWorld / Code / [r4967] /trunk/engine/shaders/glsl
you can find a complete .shader with embedded glsl here: http://triptohell.info/moodles/junk/shadertoy.shader - just stick it in your quake/$gamedir/scripts/ directory and load up dm2 or some other map with the muh_bad texture.

I tried it out briefly. Love the performance, over 400fps at times. But on the very max settings, dropped to 4fps xD I'm guessing it's because I didn't have a custom rtlights and it's therefore setting arbitrary lights in the map? Love the editable console with copy/paste. I like the projections, especially stereographic. Not seen that before, and found it to feel quite natural. However, it drops me from 340~400fps to 60~100fps. It also keep freezing-up and I have to terminate it. It's fteglqw64 on Windows 7 64bit. Ask me for what details you need if you're bug-hunting.

Are there any books/tutorials/things that you recommend? I want to learn everything about 3D rendering, especially in quake based engines. How did you learn, and what resources can you recommend? I don't care if it's some shabby little engine you learnt from, or some crappy tutorial - it doesn't have to be a set of boring academic textbooks. Anything. What I mean to say is, that for me, I learnt C by following a set of tutorials online, written by some webuser a long time ago. It was a crappy grey website, but the content was good. I actually learnt C from that, before I even knew about the K&R book on C. It's little things like that which I'd rather learn from. Although saying that, the K&R book is definitely not an academic textbook, and earns its reputation for being down to earth and pragmatic. But I digress.

rtlights require drawing parts of the world a number of times.
water requires drawing large swathes of the world two extra times.
bizzare projections require drawing the world up to 6 times (with a post-process thing after, read up on cubemaps).
and offsetmapping can be quite expensive with all the dependant reads and overdraw from the rtlights.
and cl_splitscreen 3 will also hit your framerates quite a lot too...
use them all at once and you can get very low framerates, yes. DP should also suffer in the same ways - at least with the ones it supports.
really its the water that really destroys framerates because its these that you don't have so much control over (you can always edit rtlights, while water is either really expensive (when combined with lots of other lights), or really cheap). presumably it should be possible to use screenspace reflections or something which would significantly simplify that, but they have their own issues. I should also disable the reflection or something if the camera is too far away from the surface plane or something. that might also help.
I don't really support 64bit builds 1) they don't seem to get quite the same framerates (64bit has more registers, but also more cache misses, and x86 is generally pretty good at determining shadow registers etc anyway or something). 2) third party libraries tend to not support them so well (no truetype fonts, using fte as a 64bit quake2 client is near impossible, etc). 3) windows compiler toolchains don't support them as well as they support 32bit (so I personally test 64bit only very infrequently).

if you want to learn about 3d rendering, especially quake-based engines, then grab a quake engine and port it to gles or to a gl core profile, or possibly even some d3d version.
either way just set yourself a goal that requires you to use the stuff you want to learn about and you'll learn it as you try to reach that goal. you won't get the whole picture otherwise. :s
at least that's basically how I learnt - actually trying to use it. I tend not to remember stuff otherwise.

I just tested out cl_splitscreen, presuming that it meant what I thought it meant. That is something that I was going to add to darkplaces, once I'd got some experience. That is a big step towards me possibly jumping to fteqw - I'm pretty excited about that. Is it robust or still experimental? I'm a bit upset actually, as I wanted to do that as a learning challenge. There just aren't enough games that do that - focusing instead on 12yo CoD multiplayer. I remember the days of golden axe/streets of rage with envy, playing at the side of my friend in coop, not screaming down a microphone at someone from the across the world.

Coincidentally, I wanted to port glquake to my windows phone. Then that would be a perfect way for me to get my head in and hopefully not drowned. Are there any techniques that you can share for porting? Should I just comment out large blocks of code until I can get it compiling (stubbing), and then slowly translate function by function? Testing each function with a test case as I go along? (I can't think how else I'd test it as I port it)

I'm very tempted by fteqw now. Is there any reason that I wouldn't jump? Something that darkplaces has over it still? I'm making complex q3bsp maps with high resolution lightmaps and realtime lights together, as in the source engine. Does it support most of q3's shaders? I'll be making lots of models with animations - some of which might be quite complex. I want something similiar to grass-lod. I'll want physics eventually, but it doesn't have to be havok-quality. I'm making an independent commercial game, inspired by quake, but it doesn't have to keep compatability whatsoever. The game's success will mean cash injection into everyone that helps me make it.

I'd like to say that splitscreen was robust, but it doesn't get enough testing (particuarly multiple gamepads etc as I don't have any). It does break support for [view|external]modelforclient fields though, and csqc needs to be aware of the additional seats otherwise it just draws the first player. I'm sorry if this makes you upset, but hey, it could at least be better, so there's a ray of light in an otherwise stormy sky!
If you do still want to scream down a microphone, FTE does support VOIP (another problem with splitscreen, which tracks only a single microphone)...

regarding windows phone, microsoft don't support opengl. I feel that this quote from their header sums it up quite well: 'Copyright (c) 1985-96, Microsoft Corporation'
I don't know about previous versions of windows phone (each one has basically been completely incompatable), but the current versions only support d3d11.
Again, I'm sorry if this upsets you, but FTE does already have a d3d11 renderer. It should work well enough for quake-level content, but it is glitchy with rtlights and lacks a fair number of other features that you might expect from the gl renderer (there are no downloadable builds with the d3d11 renderer because it doesn't like mingw, and the d3d9 renderer tends to be faster anyway).
if you want to port (vanilla) glquake, I'd start by stubbing out audio (vanilla has loads of foo_null.c files), then focus on getting a window open, then get your d3d11 context up, then get your hlsl compiled then loaded, then get the console/2d stuff visible before moving on to the world/sprites/models. You'll probably want to do the d3d11 (as opposed to dxgi) parts in windows. you can set up some debug layers to force it to the d3d9 featureset or whatever they call it that's normally found on phones.
Regarding darkplaces, iirc it assumes that various parts of 3d state are separate and independant, which would likely make it hard to target d3d11 without rewriting significant portions, but hey, that's what you'd be doing with vanilla too (just while trying to not break gl/d3d9 at the same time - working with vanilla can feel wonderful because you don't have to care about breaking anything!).
I wouldn't recommend porting function by function because that will often end up suboptimal, rather you should have a plan for each module (even if you don't tackle the entire module in one go).

Features that DP has over FTE isn't something I can really answer on account of not using DP often enough to know.
There are a number of things that both engines have but that are mutually incompatible. Particle systems being the chief example - naturally FTE's is more versatile (and more complicated), while there are more extant particlesets for DP. This is a recurring theme.
There's one tweak that I need to make with q3bsp's lightmaps to boost performance that I keep putting off because my first attempt broke a solitary q1bsp.
FTE's level of q3shader support depends upon the backend being used, specifically specific glsl/hlsl requires a backend that supports said shading language, while using legacy (read: vanilla q3) shaders requires a backend with fixed-function support (read: not gles2 nor d3d11) - often these sorts of shaders have problematic interaction with rtlights anyway.

Thanks for all the help. Yeah I expected such a monopolising thing from Micro$oft. That's why I was thinking more of an opengl to directx wrapper. Or would that we a bit too deep? As I would need to understand both API's. I'm a competent C programmer, just not experienced in anything other than software rendering.

Quick question: How do I access a vector's x,y,z members when it is inside a struct? This gives an error:-
Something I want, is to have peeling paint and rusty surfaces (My game will be very gritty and dirty). The problem of course is the amount of time it will take to do such a thing in level design, as-well-as the number of triangles. I've thought about how I could use surfacemodel in the q3 shaders, which darkplaces supports. I was thinking that it would be relatively easy to add a shader parameter (I'm talking about q3 shaders here btw, which are really materials, but you know that ofcourse) which lets me set multiple models and to keep them from the edges, and for them to be lod'd. I could have 3 lod's, one with the highest triangles, one with much less, and then a third as billboard or decal. The actual model can be a flat mesh with the underlying texture on it (say brick or an under-paint or another layer of metal) and triangles curling out to be the rust/paint peeling off, making sure that it is on a higher z order to stop z-fighting.

been a while but something like

h1.va[x] = 100;

?