Is there another way to record footage (mostly singleplayer) from different perspective, or even better with moving cameras?

And a little side-question:
Could the same thing be possible in Quake 4?
This would be awesome too... 

in the quakeworld community, mvd demos allow free-floating cameras, or freely switching perspective mid-demo.
It requires server support. 

Did something like this, adding a second client that followed the player around, recording from different positions (chase cam and fixed).

This was supported in AguirRe's engines, but also needed qc. 

I ported Spike's BSP2 patch for Fitzquake mark V to quakespasm. Tronyn's nyar2 and wicked seem to work. Only played a few minutes though.

It's on the patch tracker here:
http://sourceforge.net/p/quakespasm/patches/11/ 

Now that's an advent calendar entry. 

I'll let oz know, hopefully he's fine with integrating this into the mainline. 

That is awesome news! :D 

I can execute that! 

Having bsp2 support in QuakeSpasm (and in official top-of-tree Fitzquake MV for that matter) would be a true Christmas Miracle. 

diff points out difference in the written code.
New vs old version. By now, you have to compile it for yourself:(
Binaries anyone? 

awesome! sound resampling upgrade patch next please ;) 

onetruepurple: oh fucking what
onetruepurple: Host_Error: Mod_LoadLeafs: 34523 leafs exceeds limit of 32767.
ijed: yeah
ijed: thats the crash, if I remember rightly
ijed: it's not enough to just add the format
ijed: all limits need to be raised
ijed: didn't mention it on func
ijed: because wasnt sure 

the patch doesn't work? 

Although the fix should be relatively simple.

All this engine strife should go away soon, there are a number of engines in the works now. 

 

ijed, your level works now :-)
I had to raise MAX_MAP_LEAFS (now 65535), and change the surface indices from unsigned shorts to unsigned ints in mnode_t.

https://sourceforge.net/p/quakespasm/patches/11/ 

nice. 

The patch is applied in teh svn repo as of rev.881. 

Cheers for this. Half-way through Something Wicked and it's going fine.

If no-one else puts up a windows binary, i will when i sort out my build environ. 

Dont think you beat me Oz... I was just doing some 'testing'. 

Now merge ericw's sound resampling! 

like the vertex lighting code from reQuiem. And the light source code for rockets and grenades etc. Couple that with the nice corona effects from DirectQ and we're cooking with gas! Actually DQ has the best menu out of all the engines IMO, get that in there too x 

Freshly built Win32, Win64 and OSX versions from svn r881:
http://quakespasm.sf.net/devel/ 

Thanks, guys.

A question: now that bsp2 support is in, would it be feasible and/or desirable to add support for protocol 999 (RMQ), however rudimentary? And how about 10002 and 10005, the ones from BJP's enhanced GLQuake. Perhaps there are even some others that only slightly derivate from the common standards. I presume DP protocol would be out of the question, though.

The reason is having an engine port that supports a wide(r) range of existing protocols would make demo playback (among other things) a lot more convenient for the general user. As it stands, the several different protocols create quite a bit of a mess, and only relatively few people know their way around it. You could say, another step towards a general purpose engine.

Not necessarily an actual feature request, more wishful thinking really. 

If you already have 666, 999 is a superset that gives support for .scale and extensions for coord+angle precision, so its likely going to be needed at some point in the future even if its not used by default.
DPP7 support has a lot of merit, but full compatibility with DP is a major undertaking, but then you don't need full compat for it to be useful.
Also needs mvd+qwd playback! :P

999 would be a good idea though, its the simplest way to get larger coords.