.. sorry. As I said, not a very good day for me ;)
As for the problem, as far as I can see there is no problem, just the annoying bzztt sound from the broken lamps in the map ;) 

Experiencing the same statusbar problem with that engine too.
I'm linking to a screen of the problem. Look to the right and left of the statusbar. I have fullscreen and my full resolution of 1440 x 900 set and also viewsize "100.000000". This appears in Fitzquake and it's derivatives.
http://www.imagebam.com/image/b6bf... 

 

http://tinyurl.com/6gkfhu8 

I compiled quakespasm 0.85.3 from source on my x86_64 Debian Linux 5.0 box. It works great except for the mouse; even with free look enabled and mouse speed set to the minimum possible slider setting, my mouse is unusable - any movement causes the player camera to point straight down and wildly spin in circles. I have to use the keyboard to move the player camera up and down.

My Debian install has libsdl version 1.2.13-2. 

I noticed that the RMQ engine has an widescreen fov option, yet Quakespasm does not. Can this be added in the next version? 

New version 0.85.4 is out. 

The "replacement" audio track support is incompatible with the existing Darkplaces implementation. It would be nice if you could either adjust to that or get in contact with LordHavoc to make DP support your way.

ericw's branch does this: https://github.com/ericwa/Quakespasm
I've been using it every now and then and it worked well.

Minor nitpick about packaging: I really dislike generic filenames like README.txt. I know many use them. But imagine John Doe extracting straight into his Quake directory. For him, it should be quakespasm.txt or quakespasm.readme or something like that.

Great work! 

 

I believe what you're interested in is the music file directory which is <gamedir>/music in quakespasm, and darkplaces already supports that, so I'd like to understand your concern. OTOH, I am not interested in supporting multiple-alternative music file directories like dp which adds more complexity than it's actually worth. 

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.