thanks for the link. yes, i'm attempting to port quake to plan 9 (the 9front fork actually) for fun. 

so you can run it on a raspberry pi?
I�m exited! 

Apparently, it doesn't work well. The hires sounds are sounding low res in QS.

And what about the textures I was talking about ? 

i believe you need to put them into a pak file for the sounds to work. make a pak2.pak and then mirror the folder structure. 

Eww !

And how do I make a pak file on OS X ?

There should be an option in QS to friendly use custom sounds... 

this is how the quake engine works. in ID1, it will always favour pak files.
The alternative is to put the sounds in a mod folder and run with -game. 

The sounds are now working great (and they're awesome), as a "sounds" mod.

But what if I want to play a normal mod ?

How can I turn the "sounds" mod into a pak (on OS X) ?

A long time ago, there was an application on OS 9 (depacker) to unpack packs on the Mac, but it doesn't work anymore on OS X without the Classic environment (Fuck You, Apple !). 

Here's a link to the sounds set (about 22.1 MB, zipped), so one of you could turn it into a pack file :

http://fsgregs.startlogic.com/Public_Files/Cham/Pictures/sounds.zip 

i believe quakespasm allows multiple mod directories, so you can just do -game soundMod -game actualMod.

note that the order that you put the mods in will affect what files are retained. the first mod will have it's files overridden by the second mod and so on.

make a shortcut to always start the game with your sound mod. 

Use http://winebottler.kronenberg.org/ (it's easy) and https://www.quaddicted.com/files/tools/pakscape-011.zip

You use Wine Bottler on the .exe and you can run it on your Mac.

It's pretty easy, although you may need to install X11 (I don't think that comes with Mavericks). 

EWW ! Man, such complicated emulation stuff just to use an utility, it isn't for me. I'm trying to make my life simple.

Someone could convert the sound files I gave above to a pack and publish it back here ? 

http://quake-1.com/mods/barnak.zip 

It's working great !

Thanks a lot !

I'm now wondering about the textures I talked above. Where should I put them ? 

QS doesn't support external model/sprite textures, afaik, just replacement textures for the bsp 

If you can install SDL, -> Quakespasm should be easy as anything i would have thought ???
Just edit the Quake/Makefile and disable all the fancy sound stuff.

Otherwise ... TyrQuake ? 

it may be possible to play doom on 9front on the rpi, that was already ported. i'm doing this as an exercise for the 64 bit kernel. 

New prerelease builds uploaded at http://quakespasm.sf.net/devel/

win32:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r958_windows.zip

win64:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r958_win64.zip

macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.85.10-macosx-r958.zip 

 

Almost all of the changes are cross-platform, no osx-specific changes. Since you asked, here is a summary of changes since r947:
- speedup of tga and pcx external images
- further slight speedup for lightmap loading
- change sv_aim default value to 1 (i.e. turn off autoaim)
- add 'prev' and 'next' keywords to the 'cd' command
- work around a linux cdrom issue (playback might not start for a while after a stop).

You can follow the development history from http://sf.net/p/quakespasm/code/ 

 

I guess I missed mentioning Eric's sound mixer (lowpass filter) work that went in: http://sf.net/p/quakespasm/code/952/ 

 

I looked through some of the Quakespasm changes and have 2 thoughts:

1) MAX_MSGLEN has been increased from 32000 to 64000. FitzQuake protocol 666 has a MAX_MSGLEN of 32768.

As I understand it, due to this change you aren't actually using protocol 666 any more, but have modified it and, as I understand it, it is now possible to record demos or host a server using protocol "666" that in isn't actually compatible with the standard.

[I could be wrong, but I don't think I am]

2) sv_aim 1 as a default makes playing with the keyboard really hard. Probably the reason id software didn't default it to 1. 

1) You're right, you can record demos that will be marked as protocol 666 but an engine with MAX_MSGLEN set to 32768 like Fitz 0.85 won't be able to play (but this would only happen in cases where Fitz wouldn't be able to load or run the map anyway.)

I can see the argument that MAX_MSGLEN should be considered as part of the protocol, but there's good precedent for bumping this limit without changing protocol numbers; DirectQ, Darkplaces, and RMQEngine all use 65536 regardless of protocol, and I think Fitz allows 32768 bytes messages even for protocol 15 (same kind of limit bump).

The background behind this is I wanted to support a map ijed is working on (bsp2); the snapshot I have has 2855 edicts at startup, which gives a 43392 bytes signon buffer.


2) That's also true. But I assume nearly everyone plays PC FPS's with mouselook, so it's a good default? QuakeSpasm (in the upcoming release) defaults to +mlook turned on, as long as you use the quakespasm.pak, which is why I wanted autoaim to default to off.

I figured anyone who wants to do a "1996 night" and play quake with keyboard aiming can look up the original default sv_aim 0.93 and enter that in the console.

An option would be something automatic where turning mlook on or off automatically updates sv_aim to 0.93 or 1; I think negke suggested this, and that could be a good option too. 

I feel like those sorts of limits are a grey area where they are not directly part of the protocol, but obviously affect which clients can handle what the server is sending them.