News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
Re: Vsync Setting Is Behaving Strange 
That's a bug you found there. I just pushed a change to svn (r778) that should fix it. Can you test it and report the results? (My card doesn't support vsync toggling so I can't test it myself.) 
@ Svdijk 
would be glad to help, but unfortunately i'm not familiar with code compiling at all =( 
 
Raspberian (I guess from Debian actually) repo has some patches you guys might consider bug reports (linking and some minor hurd things): http://archive.raspbian.org/raspbian/pool/main/q/quakespasm/ 
@pat0gen 
@pat0gen 
@ Svdijk: Vsync Bug 
nope, didn't work for me. everything is like before, had to use nv control panel to disable vsync permanently.
new console message appears on startup, however: "Cvar_Set: variable vid_vsync not found" 
Re: Vsync Bug 
That message appeared in r778 because of a sloppy mistake of mine, but it shouldn't be occurring in the updated r779 that I posted; did you try that second link? 
Re: Vsync Bug 
oops, missed the update somehow, my bad. but no, r779 hasn't solve the problem either. 
Re: Vsync Bug 
OK, one more: http://quakespasm.sourceforge.net/tmp/qs_r780_win32.zip

If this doesn't fix it, is there anywhere off-forum where I can contact you so we can stop spamming this thread? 
Re: Vsync Bug 
all the same with this rev(
here, my postbox:
seraph[dot]divine[dot]sd[at sign]gmail[dot]com 
 
Trying to save in its (http://www.celephais.net/board/view_thread.php?id=60875) gives me a segfault: https://pastee.org/s6a23

Built from SVN a while ago:
QuakeSpasm 0.85.9 (c) Ozkan Sezer, Stevenaaus
Exe: 12:41:37 Nov 14 2012
FITZQUAKE 0.85 SERVER (38429 CRC) 
 
Yeah 
same here. Relevant portion of stack trace:


0 libsystem_kernel.dylib 0x00007fff895ad212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff91413af4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff91457e9e __abort + 159
3 libsystem_c.dylib 0x00007fff9141971d __chk_fail + 35
4 libsystem_c.dylib 0x00007fff914198f8 __sprintf_chk + 201
5 net.sf.quakespasm.QuakeSpasm 0x000000010004e9da PR_UglyValueString + 170
6 net.sf.quakespasm.QuakeSpasm 0x000000010004f3e2 ED_WriteGlobals + 194
7 net.sf.quakespasm.QuakeSpasm 0x000000010004a0b9 Host_Savegame_f + 761
8 net.sf.quakespasm.QuakeSpasm 0x00000001000402b4 Cbuf_Execute + 196
9 net.sf.quakespasm.QuakeSpasm 0x0000000100044682 _Host_Frame + 82
10 net.sf.quakespasm.QuakeSpasm 0x000000010005dd85 SDL_main + 549 
@Spirit, @SleepwalkR 
Save crash should now be fixed in the svn as of rev. 791. 
 
What is your command line ?
Can't you save game at all ? I can't reproduce this. 
Ta Oz 
Interesting looking mod :) 
@stevenaaus 
Not dependent on command line, depends on compiler. The crash was due to long global strings from the progs not fitting into an 256 chars long array (a stupid sprintf crash.) Grep your saves for "STORY_??" and see.
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=791 
Re: Traceline Crash When Using Player Lightning Hack 
You said it was a QC error in my dev progs, but it's definitely a bug in the Quakespasm code. I just tested my new map in several other mods (including ID1 1.01) and it's reproducable in all of them, albeit not at every instance of the hack. No other source ports have a problem with it.

I also noticed a slightly teleporter and monsterjump behavior in comparison to Fitz085. Monsters teleported into a monsterjump trigger that worked fine in Fitz would either be kind of pushed out of the teleport destination and miss the trigger, or not be pushed in the same way (speed/height). This may or may not have to do with the fact the jump triggers are point entities using the bounds of another ent. I didn't examine this behavior in detail, though, just adjusted the entities until it worked in both ports. 
Soundtrack Music Sounds Fuzzy/muffled? 
I'm wondering if this is a known issue or if there are some relevant console settings I could tweak.

I've ripped my Quake CD to OGG and MP3 forms. When the soundtrack files are played using DarkPlaces, Fitzquake Mark V, or DirectQ, they sound "right". With QuakeSpasm though they don't.

My usual test track is the first one ("Aftermath") that plays during the intro demo as well as on DM4. In the "DA NA NA - DA NA NA NA" hits, correct playback has some high frequencies in there that give those hits some prickly edges, but in QuakeSpasm they just sound kindy sludgey. 
Re: Soundtrack Music Sounds Fuzzy/muffled? 
That's because the tracks are downsampled to 11025 Hz by default. With "-sndspeed 44100" they'll sound as expected. 
 
Thanks!

I've also run across the sndspeed "controversy" in the Fitzquake Mark V thread now. 
+Some Features For Anyone Interested ... 
(Source only ..)

After making sure I was aware of all the Quakespasm changes, I carefully added a few Mark V features that I really miss when using Quakespasm on my Macs.

10 changed source files which go in Quake folder of Quakespasm source OR ... alternatively changes .diff file

The diff changes the version to "0.85.9" just so I could be certain that I was using the right one during testing.

Dynamic light speedup, record demo at any time, widescreen correction (as far as I know Quakespasm doesn't have this), and making the gun the same size regardless of the fov. 
 
...making the gun the same size regardless of the fov.

This. I guess this feature should be implemented in all engines currently active - at least as a cvar. Nice thought. 
Is That MH's Fix? 
 
Gun Size 
r_gunangle
or
r_viewmodelfov

Usually does the trick... mine is set to this in the autoexec.cfg -

r_gunangle 2
or
r_viewmodelfov 110 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.