I've always thought that "sound/cdtracks" was a little bit of an odd choice, to be honest. "music" at least is standardised with Q3A and the like (so it's got a higher probability of being what players will expect to be able to use), plus it keeps background music tracks separated from in-game sounds in the directory tree. Which seems to me to make more sense.

I can understand the perspective of someone who may already have a bunch of files in the one and not wish to create a duplicate copy in the other (although you could just symlink one to the other). But overall I think the reasons for preferring "music" win out. 

 

I'm certainly not alone when I say I think most people paying attention to Quake engine development are really encouraged by what has been going on the last couple of years.

And Quakespasm has been a major force in making better engines and I love the sheer thought in the changelog.

Ironically, back in 2005 I did not at first see the beauty of FitzQuake but once I got into engine coding the impact first slowly and then as learned more *quickly* became uber-impressed.

And Metlslime really polishes up his work (maybe only Jozsef ... JoeQuake ... is in his league on the testing/polish thing ... btw JoeQuake is still in development).

This post is getting a bit wordy now, but the body of work that Metlslime, aguirRe, Tyrann and Sleepwalker produced has created a solid foundation for people like the Quakespasm team, MH, myself and others to play around with.

And the thing I think is particular neat about the Quakespasm team is the non-Quake centric experience of the team.

And it is important to not forget Spirit's public lobbying and encouragement of map community wants and the Remake Quake guys for the testing lab for experimental game play ideas.

Yeah, too wordy ... but needless to say, I prefer an engine modification environment of thriving ideas and implementation that RELATE TO REAL WORLD SINGLE PLAYER WANTS ... versus, say, the old Quakesrc.org days that focused on "neato" features.

I am not dismissing the importance or value of the wild and crazy Quakesrc.org days or their contribution as the backbone of some of the things we have today.

I'm just saying that important and relevant features that can be very hard work to address complex authentic multi-platform Quake user and mapper problems matter quite a bit and in the old days those appeared to be ignored.

Anyways, awesome release guys! 

Are forthcoming, still trying to iron out possible bugs in the PPC build. 

Didn't realise dp supports music/ too. Yeah, I like that directory better. Would be great if you would add support for any filenames to be supported and the "cd play" command.

Baker, you ought to prepare some random generator for that kind of recurring posts... ;) 

Yep, dp supports music/ already.

As for a console command, I didn't change "cd play" behavior, however I added the new "music" series of commands:

- music <filename> : Start playing the requested music file.
Example: music mymusic1
Notice that you don't type the file extension: The requested music will be searched with ogg, mp3, and then with a wav extension, automatically. If you do specify the file extension like "music mymusic1.wav", then it will honor your your wish and try only the given type (which is good for testing/comparing the same music in different formats and mappers can even use that feature.)
- music_stop : Stops the playing music.
- music_pause : Pauses the playing music
- music_resume: Resumes playing the music if it was paused
- music_loop 1: Makes the background music to loop (default behavior)
- music_loop 0: Makes the background music to play once and then stop

As for supporting any filename, I am not sure what is required, but the code supports and can handle multiple audio formats concurrently. The map-dictated music, i.e. the cd-music, is always searched by the order of searchpath priority, whereas the a music request from a "music" commond uses the music format preference order unless the file extension is specified.

If you are interested in support for multiple music directories as alternatives to each other, like "music" and "sound/cdtracks" thing of dp, no sir, that's not going to happen :) 

My perspective on engine development is mostly from the rather tame 2008 perspective.

I am genuinely pleased with how things have evolved since then.

Sure I get a bit excited about it and talk too much, but there is something to seeing a list of challenging problems one by one get knocked off.

Back in 2008, it seemed like too much to hope for.

Since 2008:

1. FitzQuake 666 protocol
2. Quakespasm guys solve problem caused by "disc".
3. Quakespasm guys solve x64 processor problem.
4. Texture dump in FitzQuake 0.85
5. MH writes new colored light tool
6. Willem does the multi-core vis tool.
7. Avirox writes QW version of true rotating brush. LH adds rotating brush support to hmap2.

And on and on and on ..

Yes, I am very pleased. 

Add support for mouse buttons 4 and 5

this probably means i'll never be able to use another engine now. well, until they add this too. 

Most actually do. 

news to me. 

It's very common. ProQuake, Qrack, DirectQ, JoeQuake, DarkPlaces, FTE to name a few all support a minimum of 5 mouse buttons and have done so for years. It's really only Fitz and Aguirre's that still only support 3. 

most of those crash on my machine and directq (as we've discussed) has pretty serious performance issues on my machine and darkplaces has performance issues for other reasons.

sor really only fitz and aguirre's that i've used. hence, news to me. :) 

I thought it was the DirectFitz port from here http://quakeone.com/mh/ you were talking about. 

both, which is why i didn't make a big fuss over directfq. i just figured it was something linked with direct x 8 itself. 

You're calling it "DirectFQ" but yet you say both? If you mean one of the engines available here: http://quakeone.com/mh/ then yes, they're slow, but their intended audience is people who have trouble with OpenGL (speed was not an objective). If you mean the engine available here: http://directq.codeplex.com/ then no, it's lightning-fast, and something else is making your 3D card perform worse than a low-end integrated Intel, which doesn't make sense. 

The former use DX8, the latter uses DX9 which adds to my confusion... 

Could produce faster engines than those initial ones in 2009. Which have performance issues for reasons that have been solved since then (flashes using video hardware gamma instead of just drawing an alpha-blended poly).

Case in point, the Direct3D8.1 wrapper version of ProQuake gets 80% of the performance of GL ProQuake (equivalent of stock GLQuake rendering).

And GL ProQuake gets 600 frames per second on some CPU + video card combinations *and* ProQuake's render is NOT as fast as FitzQuake's entirely rewritten renderer.

The DirectQ engine ... MH's main project ... can get 5000 FPS (no kidding) on id1 maps.

I do understand that people who are not active follower's of MH's work don't know how incredibly powerful his DX9 rendering engine is.

But ...

1. FitzQuake modification and experimentation is a bit fragmented right now. You've got a lot of different FitzQuake forks that "matter" including the RMQ Engine/Quakespasm and some things that FitzQuake could do natively in Windows like some of my experiments and mods. This is all good ... several independent laboratories sorting out the "good stuff". Maybe at some future point metlslime will decide on the features for FitzQuake 0.90 or even FitzQuake 1.0 ;)

2. No one is being stopped from single player goodness right now. Even though there may not be a single option, there are plenty of options that are quite similar to each other. So no urgency. 

both directfq and directq run slowly. since it's clearly not a programming problem, the problem lies with directx or hardware. but since i have no problems with normal opengl fq (or qs in this case), i don't want to invest time into finding out what's up.

i find proquake is a terrible engine. mainly because when it crashes, it screws up the gamma settings in windows and i have to run through colour calibration to get gamma back to normal. it also has that old really annoying bug that glquake has where each time you run it, it moves all the windows down and to the right so that eventually after a few starts, all your windows are cowering in the corner.
also, it doesn't have extra edicts (or i couldn't figure out how to get it working) so it doesn't load any of the maps i make. 

since you guys seem to know all the 'big names' these days, you should post up a list of them somewhere. finding custom engines (and trying to test them, never knowing if they are abandoned or not) is really hard for me. you engine guys need to work on market penetration! :P 

...but DirectQ currently gets maybe 2000 downloads per month. I reckon it's got market penetration. ;) 

ok then. 

I maintain ProQuake but wouldn't recommend it for single player over FitzQuake any day of the week.

Anyway, yes we are in a time of a bit of engine flux due to a great many authentic baseline improvements being littered all over the place.

But as long as someone is able to play single player releases with some preferred and quality engine, there is no emergency ... and in time all this will sort itself out.

I myself would prefer to live in a world with a lot of general interest experimentation that "matters" going on. And regardless of preference or not, it is, in fact, exactly what is happening ;) 

did you guys really implement fog interpolation? or was that always there and i never knew?

cause it's pretty fucking cool. and also annoying because only a few weeks ago i wrote qc to handle fog interpolation with a complicated system to get ftos to output more than 1 decimal. :P 

it was always there :) 

queue "fuuuuuuu" on my part. :D