#1206 posted by Baker on 2014/09/12 02:50:34
I didn't do a timedemo, btw. On both maps, I just stood still at the start for about 20 seconds.
On roman1, doing gl_fullbrights 0 has no fps change (still 19-20 fps).
r_drawentities 0 it goes up to 53 fps. (Older Quakespasm, gets 46 fps with that ... so this is a +7 fps gain)
Weapon Model Position
#1207 posted by DaZ on 2014/09/14 12:27:17
Yo, I am just reposting this comment from my youtube here as I don't know the answer to his questions :
"quakespasm best quake engine that I know of overall, but it still has some glaring flaws in my opinion. The biggest issue for me is the way it handles- or rather doesn't handle- weapon models.
In quake, just like in doom, weapon models were placed in the center of the screen intentionally to be used as aiming sights. This mechanic, for me at least, is a crucial tenant of the classic doom and quake experience, and it goes completely out the window in quakespasm, as the engine doesn't compensate for the absence of a status bar and draws a microscopic weapon model at the bottom of the screen, about two miles from the center of the screen. The only way to compensate for this is to jack the field of view way up to say 130, which brings the weapon up to where it should be, but seems to stretch it vertically, and of course comes with all the issues that come with a grotesquely large field of view.
If anyone has an idea for fixing this within quakespasm, let me know."
#1208 posted by Joel B on 2014/09/14 14:36:07
I posted a question about this general thing on I3D a while back; there's some discussion about the issue in the thread: http://forums.inside3d.com/viewtopic.php?f=3&t=5527
...but as far as solutions for a player to change things, I don't think so.
#1209 posted by Joel B on 2014/09/14 14:43:56
They might like using Fitzquake Mark V with r_viewmodelhackpos = 1?
A Workaround
#1210 posted by Orl on 2014/09/14 15:41:12
You can use the "scr_ofsx" console command to move the weapon model further into view of the player. By default it is set to 0. A positive value draws the weapon in closer, and a negative value pushes it out further.
I personally use -4 as my value, but give different numbers a try and see which one suits you best.
Cool
#1211 posted by DaZ on 2014/09/14 19:56:14
I will post this to them, thanks.
Yeah
#1212 posted by ericw on 2014/09/14 21:32:14
sometimes I feel it's too low on the screen when playing with the statusbar partially transparent. It could be nice to have an option where the gun position doesn't move down when you make the statusbar transparent.
Thx for the link Johnny.
#1213 posted by necros on 2014/09/14 21:42:40
it might look ugly though. the ssg is particular doesn't have much more to its model besides what's already on the screen.
New Builds (0.85.10-r1032)
#1214 posted by szo on 2014/09/15 12:08:16
New prerelease builds uploaded at http://quakespasm.sf.net/devel/
win32:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032_windows.zip
win64:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032_win64.zip
macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.85.10-macosx-r1032.zip
source:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032.tar.gz
Linux users can build from the source for themselves.
Changes since the previous r980 test builds from Aug. 29 include:
* SDL2 support. Disabled by default, 'make USE_SDL2=1' to enable it.
* Unix/Mac user directories support. Disabled by default,
'make DO_USERDIRS=1' to enable it.
* Revised/improved the 'game' command, i.e. on-the-fly mod changing.
It now accepts an optional second argument for mission packs or
quoth support i.e. -hipnotic, -rogue, or -quoth. For example, for
WarpSpasm: "game warp -quoth"
* Command line: "-game {quoth/hipnotic/rogue}" is now treated the
same as -quoth, -hipnotic, or -rogue.
* Console speed now resolution-independent.
* Disabled gl_zfix, which caused glitches and is undesirable for new
maps. Replacement .ent files to fix z-fighting for several id1 maps
added to quakespasm.pak.
* PF_VarString buffer bumped to 1024, avoids truncated centerprints
from the 'In The Shadows' mod.
* Support for OpenGL vertex buffer objects (VBO) for world and brush
models.
* Dropped support for GL_SGIS_multitexture
For more detailed list of changes see the README file, or browse the
svn history.
Nice Changes
#1215 posted by ptoing on 2014/09/15 20:03:38
As far as 'game' goes. If you start a new mod without any of those 3 variables does it default to no vanilla quake?
@ptoing
#1216 posted by szo on 2014/09/15 20:07:12
As far as 'game' goes. If you start a new mod without any of those 3 variables does it default to no vanilla quake?
'game xxx' loads the xxx mod on top of bare id1.
Builds Ok And Runs, But
#1217 posted by bogworth on 2014/09/15 21:45:15
gl_texturemode only seems to take effect on the viewmodel. What's up with that?
@bogworth
#1218 posted by szo on 2014/09/15 22:04:10
gl_texturemode only seems to take effect on the viewmodel.
Can't reproduce here: the rubicon rumble pack mod (http://celephais.net/board/view_thread.php?id=61077) has gl_texturemode as GL_NEAREST_MIPMAP_LINEAR by default, changing it to GL_LINEAR_MIPMAP_LINEAR "beautifies" things for me, and going back to its original restores the mod's original setting.
Eric?
Never Seen That Before
#1219 posted by ericw on 2014/09/15 22:36:07
Which OS / GPU / gfx driver are you running?
Found It
#1220 posted by bogworth on 2014/09/15 22:42:43
It's anisotropy. The combination of GL_TEXTURE_MAX_ANISOTROPY_EXT with values greater than 1 and GL_NEAREST appears to have vendor-specific behaviour - in my case, GL_NEAREST is ignored.
Hapless users are unlikely to understand this, so perhaps you should consider some workaround.
Uh, More Detail
#1221 posted by bogworth on 2014/09/15 22:50:02
The problem appears for textures that are mipmapped (eg, not models), when gl_texture_anisotropy is greater than 1 and gl_texturemode is 1, 2 or 3.
I'm on Debian with an Intel 82G965 running the usual Intel driver. (A fallback - the fan on my real card stopped spinning, sigh.)
Ah Thanks For The Info
#1222 posted by ericw on 2014/09/15 23:14:40
Makes sense I guess that anisotropy + no filtering is undefined, We can detect that case and print a warning at least
Gamma
#1223 posted by AAS on 2014/09/18 12:29:46
gamma adjustment doesnt work (nothing happens at all when you change its value) in r1034 (x32 binary) on win 8.1 x65 nvidia gtx 560 @ 340.52 driver.
VBO Version
#1224 posted by mh on 2014/09/19 01:33:12
It's reasonably normal with lower polycounts to get the same, or even a slightly lower, framerate. What's important to realise is that VBOs (and batching) are an optimization for high polycounts. In general you want any optimization to have benefit in that area. Don't sweat the id1 maps; if you see an increase in the big maps then it's doing it's job.
I suggest a move to regular vertex arrays in system memory for MDLs. That will work with any GL 1.1 or better driver (so you don't even need to special-case it) and being able to take each MDL in a single draw call will be of significant benefit. Where you need to multipass you'll also get benefit as you'll only need to do the vertex setup once.
With MDLs and frame interpolation you can't really use VBOs unless you also have vertex shaders (or GL_ARB_vertex_blend which virtually no driver supports) but old-style vertex arrays will work nice.
Be careful that the current colour is undefined after using glColorPointer so you need an explicit glColor3f/4f call for the next immediate mode stuff you're drawing.
Stack Overflow
#1225 posted by dB_Audio on 2014/09/20 02:18:21
in telefragged, shortly after collecting the gold key, i experience a 'stack overflow.' what do i do?!?!
P4 3.4 GHz, 3 GB RAM, Nvidia GT240, vista, quake injector using the required quakespasm engine (quakespasm svn r980), console screenshot, if it works:
https://drive.google.com/file/d/0BwH0NjAbvI9vTzFDSmZzN0FkMUU/edit?usp=sharing
Nothing
#1226 posted by ijed on 2014/09/20 03:20:14
Excessive happens at that time, so it is probably just memory overflow. How much ram have you got?
#1227 posted by Spike on 2014/09/20 04:01:24
that has nothing to do with ram, that's a QC stack overflow.
looks some trigger (trigger once/multiple/secret) triggering itself without any delay (presumably via other similar triggers).
essentually an infinite loop.
New Builds (0.90.0-r1036)
#1228 posted by szo on 2014/09/20 11:27:15
Wrong Thread.
#1229 posted by dB_Audio on 2014/09/20 14:33:33
3GB RAM
command line parameters: -width 1280 -height 720 -bpp 32 -winmem 1024 -heapsize 655360
i'll try the 0.90-r1036 build of the engine.
thanks for the help and info. i meant to post this on the Rubicon Rumble Pack thread. should i repost this over there?
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.
|