Noclipped
#1230 posted by dB_Audio on 2014/09/20 15:17:37
i used noclip to go over the floor to the gold door without triggering the stairs to continue.
Linux/Unix Homedir Support Should Be Documented Properly
#1231 posted by Pekka on 2014/09/20 15:17:40
The Quakespasm.txt compilation instructions say you can enable home directory support on Linux with the homedir_0.patch. However, a recent change turned this into a Makefile option. The current way to enable the feature can be found here.
http://sourceforge.net/p/quakespasm/code/1013/
You should update Quakespasm.txt section 4.1 to include this information. It is in the Changes section already, but some people might read 4.1 first and wonder where the patch file has gone.
@Pekka
#1232 posted by szo on 2014/09/20 16:00:38
That's Weird
#1233 posted by ijed on 2014/09/20 16:14:59
I must have done something bad in the qc, but never saw the issue myself or from testers. I did see a similar one, but it was just a broken relay as spike says.
It's All Good
#1234 posted by dB_Audio on 2014/09/20 18:44:40
i'm just a grateful fan of the masters who keep quake alive. thank you.
Is This A Known Issue?
#1235 posted by Pekka on 2014/09/28 11:24:26
I noticed a cosmetic visual glitch while playing the Rubicon Rumble Pack's map by Hrimfaxi. In a certain location a lift is not visible from outside a room.
If you are careful, you can catch it a couple of seconds after the timestamp into the VOD by Daz. The lift support pillar is invisible for a small while when he first runs up the steps toward the lift room.
http://www.twitch.tv/tddaz/c/5131707?t=51m10s
I have a save game at this location and a short demo that showcases the glitch. Before packing them up and submitting a bug report, I thought to ask whether this is already a known issue. Should I upload more details for people to look over carefully?
It could be a vis problem instead of an engine issue. It doesn't have any effect on gameplay. The room just looks strange if you happen to backtrack and notice it.
Just Downloaded The Latest Build
#1236 posted by dooomer on 2014/09/28 14:56:19
and was very disappointed to find that it no longer works with my way of launching a mod.
I place my mod files in C:\Quake\Addon\RPP (using Rubicon Rumble Pack as an example), and launch it via a commandline like:
Quakespasm.exe -game addon/rpp
It has worked well for me, as this keeps C:\quake folder tidy without too many mod folders to clutter it.
But it seems that since a few versions back, Quakespasm has introduced some mechanism to prevent using a path as an command line parameter.
Can any one revert its behavior back? Thanks.
Also, is it possible to introduce the capability of using multiple "-game" parameters? In that way, I may even place such folders as quoth into C:\quake\addon, reducing the clutter further.
Re: Is This A Known Issue?
#1237 posted by Barnak on 2014/09/28 15:01:46
I confirm the visual glitch. I noticed before that sometimes, a part could be invisible, then be rendered when the player is close enough.
I firstly noticed this rendering problem on a Cecerello map (jam2).
Pekka
#1238 posted by ericw on 2014/09/28 21:03:19
Thanks for the report.. I can reproduce it. It's the MAX_ENT_LEAFS limit. I just put in a fix to quakespasm as discussed in this i3d thread: http://forums.inside3d.com/viewtopic.php?f=1&t=5554
#1239 posted by Baker on 2014/09/29 12:54:07
Does the Mac version have multisample? If so, how do I enable it?
#1240 posted by szo on 2014/09/29 12:56:43
Does the Mac version have multisample? If so, how do I enable it?
-fsaa x (x == 0, 2, 4, 8)
#1241 posted by Baker on 2014/09/29 14:16:48
I had tried that. It doesn't work :(
2011 Macbook Pro running Mavericks - ATI Radeon 6490M
I have GL_ARB_multisample in the list of extensions available.
#1242 posted by szo on 2014/09/29 15:18:23
I had tried that. It doesn't work :(
2011 Macbook Pro running Mavericks - ATI Radeon 6490M
I have GL_ARB_multisample in the list of extensions available.
Might be an SDL issue. Does the SDL2 version behave the same for you?
(See the latest builds at http://quakespasm.sf.net/devel/?C=M;O=D )
#1243 posted by Baker on 2014/09/29 15:31:46
I was using the SDL 2 build, 1068.
#1244 posted by szo on 2014/09/29 15:54:04
I was using the SDL 2 build, 1068.
The latest is 1071, but it won't make a difference wrt FSAA.
FWIW, my situation is similar, both with SDL1.2 and SDL2: It reports that the multisample window creation succeeded but the jaggies are there, so no fsaa for me either.
Eric? Kristian?
Hmm
#1245 posted by ericw on 2014/09/29 17:33:12
-fsaa works on both SDL and SDL2 builds work on both of my macs (2009 macbook w/ nvidia 9400m, 2012 retina MBP w/ nvidia 650gt).
Try with "-bpp 32" - according to this post, "FSAA only works with a 24 Bit depth buffer on ATI cards" http://www.gamedev.net/topic/382035-sdl-and-multisampling-aa-does-not-work/#entry3526799
What does the "video mode (...) initialized" line in the console look like?
#1246 posted by Baker on 2014/09/29 17:56:20
Adding -bpp 32 didn't work ("-bpp 32 -fsaa 8"). Still have the jaggies. I use E1M1 as the test map.
I don't have a "video mode" line in the console when I scroll up.
#1247 posted by ericw on 2014/09/29 18:05:57
Ok, thanks for trying that.
Hm, really no "video mode" line? the top of the console should look like:
UDP Initialized
Exe: 21:43:21 Sep 28 2014
250.0 megabyte heap
Video mode 1920x1080x32 (24-bit z-buffer, 0x FSAA) initialized
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
...
It should also print it if you do vid_restart. I'm just wondering what the "(24-bit z-buffer, 0x FSAA)" part is for you. I guess we'll have to put in more debugging logging, though it seems like an sdl bug atm.
#1248 posted by Baker on 2014/09/30 04:14:01
It doesn't print the 24 buffer 0x FSAA.
Just "Video mode 1440x900x32 initialized"
Ah
#1249 posted by ericw on 2014/09/30 04:24:11
That must be an old version of QS without FSAA or 24-bit depth-buffer support, then. Try szo's r1071 build from here? http://quakespasm.sourceforge.net/devel/
#1250 posted by Baker on 2014/09/30 06:35:43
It works now.
Settings For 144hz Monitor?
#1251 posted by DaZ on 2014/09/30 22:10:37
I am unsure how to setup QuakeSpasm (or any Quake engine I guess) to run on a 144hz monitor.
Currently I am using vsync off with a host_maxfps of 144. I can't see any setting in Quakespasm to set a refresh rate of 144hz but it appears the monitor defaults to that already. Negke mentioned that changing host_maxfps might do weird things to the Quake physics so I'm wondering if there is another setting I need to change to set the max fps to 144 to get the benefit of the screen and no image tearing or input lag from vsync on.
#1252 posted by Spiney on 2014/09/30 22:23:57
What monitor if I might ask? I've been wanting to get one of those 144hz 'lightboost' monitors.
Good Question
#1253 posted by ericw on 2014/09/30 23:00:24
AFAIK the only controls you have in Quakespasm are host_maxfps, and vsync on/off. And negke is right, changing host_maxfps from 72 is probably a bad idea, physics goes nuts (you bounce on lifts, for one). So without messing up physics, currently you're stuck at 72fps.
There is some stuff on inside3d about doing framerate independent physics, IIRC, MH implemented it in RMQEngine and maybe DirectQ. So maybe we could implement that in a future QS release.
How does the default host_maxfps 72 look, with vsync on and off?
#1254 posted by metlslime on 2014/09/30 23:20:18
vid_refreshrate doesn't exist anymore? Is it because SDL doesn't support it?
|